I's quietly proud.

As of this week, I have acquired my first minion. My friend A. has begun to write an assembler for the Ball Computer, in Haskell. An instruction-set simulator will follow shortly thereafter.

Mua-ha-ha-ha!

Teaser--the first view of the CPU

After much preparation, I've finally started to assemble the CPU. Sorry for the teaser, but this diagram is 1) completely nonfunctional; it'd just start dropping balls on the floor shortly after starting up, and 2) not an imagemap. Given that it doesn't work anyway, and most of its components are already documented, I didn't bother setting up all the links for each of the subcomponent definitions.

What I've done here is mainly just plunk down the components I've designed so far and make the obvious connections between them. The less-obvious connections, which is to say those which will vary based on the particular instruction, are still missing. As I put in the instruction decode logic, I'll be able to add and test a few instructions at a time until the CPU is complete.

As I bolt things together, I've been finding small changes that need to be made in some of the components. In some cases it's as simple as deleting functionality that's going to be taken care of more efficiently elsewhere, but generally it's just rearranging ports such that more internal information is exposed to the enclosing scope. Many of the components toss all setup balls out a single "junk" output when they're done with them, which throws away such information as "what values were input?" and "was that the last of the setup balls?". These turn out to be quite handy for the controlling state machines, who then don't need to waste time and gates maintaining the same data themselves.

Incidentally, I expect that I'll do the branch and jump instructions first [unconditional first, then the conditional ones], as it's pretty hard to test a CPU if it doesn't have a working program counter, and the PC design is fairly closely tied to the branch and jump logic.

The Shifter

OK, here's the latest version of the shifter. I've altered its carry-out behavior such that Cout holds the value of the last ball shifted off the end. This way it can be used for single-bit tests. It's going to be much faster than an ALU operation, so that might come in handy.

This shifter is basically set-up-and-flow-through. Once you've input the shift amount, shift direction, and whether the shift is arithmetic or logical, the input balls just go straight to the appropriate outputs. Balls shifted off the end get rotated all the way around, set to zero or one as appropriate to any needed sign extension, and inserted back into the byte. The only awkwardness is in the need for one extra ball input after the first bit [the MSB] of the operand; I use that to set up the sign-extension logic.

I've also made some modifications to the ALU, but haven't yet posted the new version. They're not very big mods: I've added zero-detection [which may eventually get pulled out] and changed the interface a bit. Now instead of having to pour balls into a port until being told to move on to the next phase of operation [several times], you just put one ball into each port until the last one, which always takes 11 for result readout [8 data bits, V, Z, and C].

Now I really do just have to put it all together. Yow!