1.0 is ready to go!

I've now completed the Ball Computer v1.0. Woot!

Check it out in all its nearly-incomprehensible glory!

Let's have a quick review of the steps to getting it built, so that you can understand how far along I am, and how much further I have to go. Here's the old version of the steps to getting it built. I'm going to update that, as plans have changed a little and I want to flesh out what I've done a bit more than I did the last time.

1. Prove it's possible by planning out the basic logic architecture.
2. Write the tool [BCD] needed for the design [ongoing, but it had to get good enough to use before starting step 3].
3. Design all the major components of the CPU, such as the ALU and RAM. Build a state machine that tests each solo component to my satisfaction.
4. Hook the components together with additional logic to implement the instructions. Write short tests that validate each individual instruction.This is what I've just completed.
5. Add a 3D interface to BCD so as to be able to show off what it might look like, do placement, and figure out how big it's going to be.
6. Prototype designs for all the physical gates.
7. Write a decent instruction test suite for real design verification. [I may see if I can outsource this or adapt an existing suite if there's anything close. Also, I'll have to improve BCD such that I can run a large suite efficiently via automation.]
8. Redesign everything for parallel operation [multiple balls in flight at a time, necessary for reasonable speed]. Here the test suite helps validate that nothing broke in the redesign.
9. Write a time+cost estimate for construction. The size estimate from the 3D model helps here.
10. Find someone who wants one and someone to pay for it.

I see that I keep adding steps ahead of me, and have managed to put off any physical prototyping a bit longer. That's a bit disturbing, but I'll keep an eye on it.

Multiply, Mac

OK, a bit of debugging and test-code writing later, I now have functional MUL, SMUL, MAC, and SMAC instructions:


MUL 1111 1 dest srcB 0 0 srcA
SMUL 1111 1 dest srcB 1 0 srcA
MAC 1111 1 dest srcB 0 1 srcA
SMAC 1111 1 dest srcB 1 1 srcA

They all write their result's low byte back to the destination register at completion. This does take time, so it might not be a good idea for MAC/SMAC, but it was simplest to do them all the same way, and this is all going to have to be redone when I parallelize the cpu anyway.

There's currently no way to get at the top byte of the accumulator; that's going to be accessible through IO space, the one part of the machine as yet unimplemented. Most of the machinery for it is already there, though; it's sharing most of the memory access logic, state machines, and instruction decode apparatus.

Step 3 is dangerously close to complete.

Yes, I'm still alive

I haven't got any new diagrams to show you, but I have actually done a little work on the machine since my last post oh-so-long ago.

In November I put in a long-needed randomizer, so that simulated gates get set to a random position at startup if not explicitly set to a value. This of course shook out a few bugs [generally of the "I completely forgot to hook that gate up" type], and it also pointed out some UI improvements that BCD needed in order to make it clear what was initialized to zero and what was just defaulting to zero.

Yesterday I dug back in to familiarize myself with the system, then did a bit of cleanup of the load immediate instruction's implementation.

Today I implemented the 4 multiply instructions [mul/mac/smul/smac], but have yet to begin debugging them. I wrote a quick test ROM for mul, and it failed, but I'm not going to start debugging tonight. That seems like a good place to start next time.