Weeel, I have gotten to the point where all the main timing is figured out, so the next and last step is to thoroughly poke the video chip in an attempt to suss out all the edge cases and other weirdness.
To perform this task, I have made a second perf board that plugs into the “video” part of the Video Brain. This board contains a PIC18F452 and a MAX232 serial level translator, and will take the place of the F8 CPU, 3853, and everything on the lower board. I can now poke the registers directly using the PIC, and I did not have to write any F8 code. score. Also, the PIC is muuch faster at poking the UV201. Also, it is in circuit programmable, I do not have to burn EPROMs (or flash ROMs), and I don’t have to figure out how to use the BIOS and all that. So I spent me 1.5 hours making the board instead of learning the ins and outs of the F8 code on the system.
Before seeing that, though, I had to hack the VB to slow down its clock, since I was being buffaloed by propagation delays. These delays made it very difficult to figure out exactly what was going on, so now that they are gone things are working much better.
The changes from last time are the addition of the clocking circuitry on the left under the video plug-in area (lower left corner), and I have the game EPROM installed into its socket now. I made several other fixes and changes but they are not visible.
Here’s the bottom side in case anyone was curious. The black things are rubber feet so it won’t scratch the hell out of my table (or skitter off it for that matter). The two wires on the right side are 12V in. black marker’ed wire = ground, other is +12V. There’s a 5V buck regulator to generate 5V to run everything.
And here’s the new addition. This PIC board replaces the F8 CPU, and gives me an in-circuit programmable microcontroller and serial port so I can dork with the UV201′s registers in near real time. I can just type some commands in PUTTy and it will change the register values. The PIC takes care of reloading the UV201 registers every frame (it reloads all of them) so that any changes are instantly picked up. The cable on the left is the programming cable, one on the right is RS-232.
And, what it’s all about. The PIC is driving the UV201 now, instead of the F8 CPU. I used the logic analyzer to snag the register writes to the UV201, and just duplicated those readings in my program for testing. The graphics for this game are pulled out of its cartridge ROM directly, except for the two players for some reason. Those are coming out of RAM, and that’s why they show up as two random blobs. I will be loading checkerboard patterns into RAM and using that for testing, so I can make sprites of any size and move them around and see what happens when they collide with one another. (We know basically what happens, but I don’t think anyone has any clue what happens at the edge cases. How close to the edge can an object be? can they be touching, or does there have to be at least a 1 pixel space? and other such questions).
I should be able to finish up my document now using the information gained from this.
Woot, I seem to have fixed the problem with the crashing carts. First the cart crashing. I pulled BA12 down with a 1K resistor and that stopped all the crashing. I am not totally satisfied with this, but it seems to have done the trick. I tweaked the RGB mod I made a little bit, and the video quality is extremely sharp now. I am thinking of doing a few other minor tweaks like EGA did to turn the dark yellow into a brownish-orange, and maybe whiten up the light blue. I dunno yet. I think it looks really good as-is.
So, on with the pictures:
Gladiator came out pretty good. I really like that “random data” effect on the barriers. I thought that looked sharp. The graphics on this game are about tops for the system. I had a little trouble with blooming when I took the picture and I stopped the camera down as far as it’d go. Also, I found it amusing that the lion looks like it’s caught inside a clear plastic box, which gave it perfectly vertical sides.
Pinball and Checkers here. The white bloomed a bit. blah. Also I noticed on the screenshots of this, that most of the colours were blown out and almost white. I think this looks so much better, but that is subjective.
Sorry about morie patterns. My camera’s CCD likes to heterodyne with the aperture grille on the monitor. In real life it’s extremely sharp. The pictures are a disappointment.
And finally the music teacher cart and the colour test. I compared the colour test with the single picture of it I found, and I seem to think that this is kind of what they were going for. Just the lack of precision resistors and adjustments sorta put the kibosh on it. Your opinion most likely will vary from mine.
So now that it’s finally working properly, I will start doing some testing to suss out how DMA and everything else operates.
Well, I did it. I got ‘er working. Mostly! Thanks to the people on the Videobrain/Channel F list for their help. The problem that prevented it from working was dumb. There were two pins swapped to the UV201. Pins 35/37 on the schematic to be exact. I figured this out using an Excel spreadsheet of the chip connections that was done by Sean Riddle. I was comparing the schematic to the spreadsheet and found the problem. After swapping those two pins, things started looking much better. Almost fine in fact, on the logic analyzer. It was no longer hanging up and the video pins seemed to have some activity too. Soooo, I hooked the monitor up and was prodding the R-Y and B-Y and Y outputs from the video circuit, and got some recognizable text on the screen! Score! Looks like the ‘brain can do 16 colours maximum (unless there’s something I missed), since all video data must come out of pins 2, 3, 4, 5 on the UV201. Pins 19/20 on the UV202 appear to be composite synch and blanking it looks. So enough of that, how does it look?
WOOT! Look at that! I got the best looking Videobrain evar, in RGB no less. I know colours aren’t 100% correct, but we’ll get to that later. I need to translate the 16 colours it can do into RGB values then devise a circuit to produce this. One thing I found interesting is the Videobrain appears to output interlaced video. Fan-cee.
I played around with the text editor doodad and typed some random stuff. Interestingly, if you press shift, the screen goes all wonky in places, and stays that way until you press shift again! Only while shifted does it screw up- and interestingly it will screw up on every screen if the system is “shifted”. If you press shift again, video is fine. I am not sure if this is an ASIC issue, or a hardware one (i.e. the final version of the system was fixed up somehow to prevent this issue).
Here’s that screwy thing going on. You can see 5th through 7th rows are all wonky. The pixel data randomly “shifts” up and down. There’s no apparent pattern to the shifting.
Lol. Who’d want a clock or alarm on this thing? I can’t quite figure that out. Oh well, that seems to work in any event.
And finally the colour test. Yep it looks a bit hosed up. I am using 3 of the ASIC pins inverted to generate RGB into the monitor. This is just a hack so I can play around with it. So that’s it for now- I got it working (mostly) and I will be testing the games out soon. I have them all burned onto a single EPROM with some jumpers to select a game.
Yep, I broke out the logic analyzer! I have hooked it up to the Videopain as I have come to call it. There’s about 90 probes hooked up. I used 6 pods which have 16 lines each and a clock. I can’t quite save the data off the analyzer yet but I am working on it. This thing is GREAT. I could watch the code run, and then the CPU died. I discovered too, that the RAM’s Din and Dout pins were swapped. The schematic shows Din and Dout swapped so that meant I had to move a bunch of wires on the SRAM chips. After doing this, I could see the SRAM clearing routine run ONCE at powerup now, instead of each reset. On subsequent resets it reads the signature byte out of RAM and knows that RAM was initialized already.
After some more RAM writing, and other various things, the CPU writes to the UV201 ASIC and gets hung up. I tried multiple ASICs, but they all do the same thing. I have come to the conclusion that I’m fairly certain the schematic has some kind of error on it, which is preventing this from working. Interestingly the RAM writes, which also stop the CPU work fine. But when the ASIC is written to, it never resets the flipflop and the CPU stays frozen forever. Here’s some handy-dandy captures with some code to illustrate this:
Here you can see a normal RAM write. Watch the “RAM WR” signal. When it goes low, the clock to the CPU (XTAL) stops, which has the effect of stopping the CPU’s output clock below it (PHI0). As usual, click to embiggen pictures. This works fine and you can write to RAM as many times as you like, as the RAM init shows. The logic signals here relate to the following code:
LM ; 43cf 16
XDC ; 43d0 2c
ST ; 43d1 17
DS (IS) ; 43d2 3c
BF $4,A43ce ; 43d3 94 fa
PK ; 43d5 0c
43D1h is the ST(ore) instruction, which writes to RAM. DC is pointing to 0FE8, which is the address it writes to.
And here is where it wedges. It doesn’t crash, it just goes to sleep and never wakes up. This is the first write to the ASIC. The code for this is:
DCI $0850 ; 4763 2a 08 50
LIS $4 ; 4766 74
SL 4 ; 4767 15
LR $8,A ; 4768 58
LI $ff ; 4769 20 ff
A476b: ST ; 476b 17
The ST instruction at the end writes to (DC) which is pointing to 0850h, one of the ASIC registers. Check out the trace: The address bus is stuck on 0850h, data bus is 0ffh (which is what it’s writing, from that LI $FF), RAM WR pulsed low to indicate the write, the CPU stops, and that’s it.
At this point I am fairly sure it’s an error in the schematic and I am kinda stuck until I can get a Videobrain to poke, or someone to confirm a few things on the schematic. I am not quite sure why writing to the ASIC is doing this, while writing to other things does not. That part is kind of a mystery. The next step is to see if I can solve THAT mystery. If not I dunno what to do except some external help with tracing some paths on the system.
I need something to poke on my logic analyzer of doom, so I thought I’d make up a Videobrain. For those that don’t know, this is an ill-fated home computer that was released in 1978, and by 1979 it was already being sold at liquidation prices. There’s a bit more information about it at the wikipedia article:
Basically it is a computer that uses a Fairchild F8 CPU and two custom ASICs along with a mess of TTL chips. There’s a diminutive 36 key keyboard which apparently is tough to touch type on, a weird “top loading” style cartridge slot, and no less than 4 joystick ports. Each joystick unfortunately is analog, with pots on the X and Y direction and a single fire button. That’s the overview. Awhile back I ran across 10 sets of the ASICs so I decided to make a perfboard version of the ‘brain because buying one is pretty much out of the question. When they show up on ebay, which is rare, they fetch prices in the several hundred dollar range. I figured with a bit of time I could build my own for much less. So far, I think I have spent about $25-30 on the project.
After buying a few things on ebay (perf board and pin headers mainly), and collecting chips (I actually had almost all of the chips, I only had to buy the 2101 SRAMs and the 3850 CPU and 3853 SRAM interface chips), I put it all together. Total assembly time was 4 days. I followed the schematic directly and simply reproduced it on the perf board.
The first order of business was to make the “keyboard”. I had a whole bunch of these little rubber dome push buttons which were perfect for the job. I laid them out approximately like they are on the real unit. The white connector at the top plugs into another similar board with most of the logic on it.
After that, I added the 3850 CPU, the 74LS05′s for the joystick reading and the keyboard matrix wiring. I added a 4050 buffer for the keyboard since the buttons have a fairly high resistance- around 500-1000 ohms when pressed. The buffer then drives the port on the 3850. The pin header lets me poke the various joystick inputs and the DB-9 connector. The empty space in the lower left corner is for eventual DIN-5 and the DB-9 connectors if I feel like adding them.
At this point, the 3853 SRAM interface and one of the EPROMs is on, and I finished wiring everything. The 555 timer in the upper left corner reads the joysticks and the 74LS74 for audio is present too.
Unfortunately, I thought I took more pics of the progress of the top board but apparently not. In any event here is the top board done,which contains the two ASICs (UV201, UV202) and all the miscellaneous TTL stuff and the 8 SRAM chips. Two of the sockets are individual pins, which are seen below each ASIC. These hold one of the EPROMs and a larger 27C010 EPROM which can store all the games at once for testing. These helped with wiring because I can simply run wires between the pins to save space. The three 6 pin black connectors and that conspicuous empty space are for a plug-in video board. The empty space will be for the chips that control the 27C010 to make it into a menued multicart if I get that far.
The video board is plugged in now and installed. It’s mainly all those resistors and two transistors that convert the digital outputs of the ASICs into the component video that the modulator chip likes. The 2 caps and TO220 above that is a switching 5V regulator. I feed 12V into the board which supplies 12V to the 4 40 pinners and the buck regulator drops it down to 5V for everything else. At this point, I break out the multimeter and verify every connection on the two boards- every pin of every chip is verified to make sure it is going to the correct place. This takes about 2 hours and I did find a few wiring flubs. These were fixed, and I reverified connections.
And here’s everything all plugged together. At this point I powered it up, and started probing chips with my calibrated finger to make sure nothing was getting too hot. After that passed, I broke out the oscilloscope and started poking the oscillators. The 14.3181MHz crystal pins were dead on the UV202. I tried a few things, including a resistor across the pins but it just wouldn’t wiggle. I could see inverter action on the pins though, so I knew there was indeed an inverter in there. I tried another UV202 and now the crystal wiggles. At this point I get kind of a sinking feeling, thinking that these ASICs might ALL be bad, and were pulls from a repair depot or similar. I sure hope not.
At this point, I poke the 4MHz crystal to see if it’s working, and it is indeed oscillating. The clock line to the CPU is dead, however. I press the reset button, and the clock bursts into life for a few milliseconds then dies again. Repeated pressings of reset result in a similar thing happening. At this point I am not quite sure what is going on, and some more prodding and poking later I check out the 4MHz crystal oscillator again. Well, turns out it isn’t exactly 4MHz. It’s more like 2.6MHz !! Turns out the 4001 I chose to replace their 74C02 isn’t up to the task at 5V. I drop in a 74HC02 and swap pins 1/3 and 11/13 since two of the four gates are “Backwards” from each other. Now, I am getting a decent solid 4MHz on the crystal. I check the CPU’s clock and it is indeed 2MHz, while it is running.
But again, it only runs for a short time before dying. I am pretty much out of ideas at this point and I need to really hook the logic analyzer up to do any more debugging, since this appears like it is going to be a difficult job. I tried a few more of the UV201′s and 202′s and get the same result with each so it’s possible that chip that didn’t oscillate was a fluke, but I don’t know.
Well, after putting the analyzer back together, I had to clone the HD before I used it (I didn’t want to disturb anything on the drive by even powering it up first). You’d think this would be a simple project…. but oooh no.
Let me recount the fail and eventual success.
First things first, I removed the drive from the analyzer almost as soon as I got it. I put in a junk 4.3 gig SCSI drive of similar form factor so I could play around with the analyzer. I plug a keyboard I had laying around in, and an IBM mouse I had. I fire up the analyzer and it’s working fine. When powered on the analyzer will show a black screen, then about 15 seconds later it changes the scan rate, then the numlock LED on the keyboard lights, another 5 seconds of black screen and the boot screen appears.
It’s unhappy about the harddrive not being formatted how it would like it, but otherwise it’s fine. I try to boot of the CDROM, which is done by typing BO <some other stuff> to BOot the machine. Well, the B key on the keyboard doesn’t work! I tried to enter it using the alt-numpad trick.. nope this isn’t a PC so that doesn’t work. I take the keyboard apart, and trace the membrane. Turns out there’s some microcracks in about 5 or 6 traces on the membrane… it’s unfixable so I extract the little tiny PCB and cable for use later and chuck the balance.
Because my keyboard is dead and I don’t have another, I decide that it’s time to go into work to pick up another from our computer “boneyard”. One Dell PS2 keyboard later, I’m back to try my luck again. Plug it into the analyzer… fire it up… and nothing!! Screen stays black, LED on keyboard never lights. The keyboard works, I was using it earlier on another machine.
After trying to boot it several more times, I am wondering if I somehow broke it or if somehow it’s not happy with the keyboard. So I grab the pcb and wire from the dead one and plug it in and turn it back on. This time the analyzer boots just fine and turns the numlock LED on, so I plug the Dell keyboard back in and turn it on. Nothing. Sooo, it doesn’t like the keyboard. Great.
I figured at this point it’d be a good idea to clone that harddrive. So I plug it all in, as seen in the picture above. After burning an Ubuntu Rescue Remix CD, I pop it into the CDROM on the machine, start it up and it says “Booting from CD…” then nothing. The drive’s light illuminates, the motor starts, disc spins… then nothing. 5 more reboots confirm that it is not going to work. My friend figures it could be the BIOS being so ancient is preventing the CD from booting, and I agreed. No problem, we’ll just update its 1998 BIOS to a more modern one last modified in 2004.
Get out the floppy disks, download the bios, pop the disk into the drive, click “my computer”… and hey, the A drive is missing! Greeeat, this machine’s floppy is dead and the other machine with a floppy drive is currently dressed like a deer with its guts hanging out, and in no condition to boot into its usual OS.
The solution is to email the bios file to work (After renaming the zip file, because Gmail does not allow exe’s even in ZIP files. grrrrr), then drive in and write it to two floppies. I do not trust the data halflife of the 3.5 inch floppy disk. Several times the disk fails to read properly and I’m stuck trying to copy data onto another to give it another try. Fast forward to work- I got my floppy in the drive, hit a: in DOS and the drive makes very unhappy “I can’t even find the directory” sounds. great. “Abort, Retry, Fail?” I pop in another floppy, and the same thing. A third also results in the message and accompanying clunks and groans from the drive. At this point I was wishing there was a “Pee in Drive Door” option to the fail prompt.
This means yet another trip to the “boneyard” to harvest a hopefully working 3.5″ drive to put into this machine. A suitable donor was found, and it was grafted into place, and the machine rebooted. THIS drive was liking my disks a bit better, and I managed to write the files I needed onto them. I also changed out the Dell keyboard for a more ancient PS2 keyboard with the larger full size DIN and a converter to get it down to the smaller mini-DIN that computers use these days. Great.
Rushing back home, I try the keyboard on the analyzer… It works! great! That’s one more problem out of my hair. So, I plug the keyboard and its adapter into my test machine, plug the mouse… uh… PLUG THE MOUSE… DAMNIT! nope. I cannot plug the mouse in: The adapter and the mouse’s overmolded ferrite bead is interfering and I cannot plug both in at the same time. I briefly thought about hitting the ferrite with a hammer then cutting the overmolded plastic off to extract the shattered ceramic but decided against it. Turns out I don’t need the mouse anyways. Mice are for wusses.
Going keyboard only, I pop in my floppy disk and boot into DOS and run the BIOS flashing program. Amusingly, this goes without incident. No problems. I check the new BIOS to make sure the boot order is CD first, and it is. Hitting reset, after putting my Rescue Remix in the drive, and waiting for the SCSI card’s gyrations, the drive spins up and I hear seeking! joy! But it was not to be.
“image checksum error, sorrx… <symbol>
boot fahled: press a key to retsy…”
“fahled”? “retsy”? “sorrx”? What was this black magic appearing on my monitor?! I am mad I didn’t take a picture of this, it would’ve been nicer. But anyways, I reboot 3 more times and get some variation of the above. On examination of the errors, they are all “off by one” errors- “sorry” vs. “sorrx” and so on- each wrong character has an issue with D0. So, as can be seen in the above picture (waay up there), I have a second CDROM drive sitting on top of the machine.
After replacing the drive, it boots! Rescue Remix is loading, which takes a long time. It gets through to the end nearly and then croaks. ClamAV (who ordered up virus scanning? I didn’t) is whining that there isn’t enough RAM to load itself. Great. I had 128 megs in there, which apparently wasn’t enough. So I rummage around and find another 64 megs and pop it in and reboot. It does the same thing. greeeat. After more rummaging, I cannot find anything else except a 256M stick that has my writing on it: “BAD” it says… Well when I wrote that I was having other issues with the machine so maybe it wasn’t so bad after all?
Plug the possibly bad RAM in, boot it up and run memtest86+. After letting it gyrate and jitterbug on the RAM for 20-30 minutes, I deemed it good and rebooted into Rescue Remix. So far so good- it is not whining about clamAV being out of memory any more. A command line! Great! After doing some Linuxy things to mount the dump drive the data’s going to, a quick run of ddrescue gets me copying my junky 4.3 gig test drive to the 20 gig IDE drive.
Well, it’s copying but the drive definitely sounds very unhappy. In fact, it sounds like a coffee grinder someone threw pebbles in! Terrible grinding and buzzing noises. They appear to be coming from the head actuator, though, and it seems to be reading. After it was all said and done, there were 8 unreadable sectors. I didn’t care though, this was the dry run and a test to see if everything would work. Turns out it did. The drive had hiphop MP3s on it, as I found out. I dunno who put them on there or where they came from though, the drive was given to me ages ago.
Elated that it finally is working, I power down and swap in the analyzer’s drive and fire back up. After the 3-4 minute bootup, the prompt appears. Unfortunately it is also locked up! After 3 or 4 more cycles of this, I start mashing the keyboard as it’s getting ready to drop me to the command line and whatever I did worked (or the phase of the moon was just right)- the command line is open for business.
Woot! It’s copying!!! The copy goes absolutely uneventful, except for a minor flub at first that caused it to start copying the drive to a RAMdisk. This got the full 20Mbyte/second until it filled up. Whoops. Copying to the proper destination was a bit slower, somewhere around 5Mbyte/second which is the maximum rate for that drive apparently (an old 20 gig IDE one). The copy goes by and I take the drive out and put it back in the analyzer. It only took me the better part of a day to do this.
YEAY! It’s booting! And it likes my ancient keyboard! I had to blow away the root password and make another, and I poked around a little in the file system, then rebooted it and let it load and start up the main application.
Yeay, that works. I have to log in as root at this point since I am unsure about how else to do it. I think there’s a default user named “logic” but I haven’t read up about it. At this point, the GUI starts and we’re poking around in it. There’s just one problem. The mouse is not working. GRRRR. Nope, it doesn’t like the damn mouse either! After getting into a CLI window and poking around, I tried to start DOOM. Yes, this logic analyzer ships with DOOM from the friggin’ factory!! I find it and try to launch it but it whines and won’t start. At this point I shut it down and tried some other mice. I had two more mice and it liked the second one (an old Microsoft ball mouse).
WOOT! SUCCESS! It likes the mouse, and I start up DOOM and play a few levels! Excelllent. I wonder how many engineers were playing DOOM instead of debugging circuits? The world may never know. This sure beats the “Bugs” (a “Centipede” clone) easter egg game on my HP scope! Oh yeah, I checked out the rest of the analyzer and everything seems to be in good shape, so I am ready to use it!
Yep, after waiting awhile, I got an HP16700B logic analyzer. I decided I needed one to help me efficiently reverse engineer stuff. I can stuff a bunch of pins onto some chip leads on a PCB and then connect the probes and go to town. This particular unit I got has three acquisition cards in it. These babies have 2 sockets on each card which connects to a cable that ends with two cables for connection to the probe pods. Each pod has 17 inputs on it, so that means across the three cards I can monitor up to 204 signals at once! (3 cards * 2 plugs each * 2 cables per plug * 17 signals per cable). I seriously doubt I will ever need this much, but if I do I am set.
This bad boy can record signals up to 667MHz and apparently do some very complicated state based capturing, though this is slower, around 150MHz or so. Since I am only going to be reverse engineering things like videogame systems with it, this should be more than plenty. After seeing what’s inside I feel kinda guilty too. This will be like swatting a fly with an ICBM.
I have yet to turn it on or hook it up but I just HAD to open it up and poke around inside to see what makes it tick. As such, I took a bunch of pictures…. Sooo here it is!
Here’s the beast with the cover off. I have already removed the harddrive at this point, a 9.1GB ultra 3 SCSI drive. The date on the drive is July 2000. I like the cable routing on here- everything is extremely well laid out and the cables are all nicely bent at 90 degree angles to take up the slack.
The riser boards have been removed, showing the CPU board and the interface board.
The CPU board is pretty interesting. That HP branded ASIC in the corner is actually a ceramic QFP. You don’t see very many of those. Also interesting to note is this DOES have GPIB; it’s on the header in the upper left corner, but it does not get connected. The GPIB chips can be seen on the bottom (right top corner on the bottom). There’s a piece of black tape on the PCB where the square cutout is for the ethernet jack (to the right of the GPIB connector). I couldn’t quite figure this out at first- the magnetics are present for this phantom ethernet port as is the PHY and stuff. I’m guessing on-board ethernet is 10 base-t. Mine has a riser with 10/100 base-t on it, so I guess they didn’t want the metal part of the jack on the riser to touch it and short it out. The small heatsunk chip is the video controller, and there’s 2 QFP RAMs under it on the bottom side for it. The backup battery is kinda lame, it’s a BR2325 which is a crappy size and worse capacity than the more common CR2032. I am going to just stuff a CR2032 in there since it has more ma/h too! 240mah for the CR2032 vs. 165mah for the br2325.
These are the three option boards. There’s an ethernet board, extra RAM (they call this “option 003″ which is the top left board, and then the smaller board is either cache RAM or more video memory. I am not sure which. These just simply plug in the top and use some plastic pegs along with the connectors for support.
This is the SCSI controller. It’s a pretty impressive board, with two Xilinx FPGAs and an Altera one. I wonder if the FPGAs fight, being from different makers and all? There’s a ceramic PLCC on here which is pretty rare, too (a non-windowed one that is) and a PCI chip. There’s two threaded standoffs mounted on the interface board and this board plugs in and screws down. When I got it, the standoff was the wrong size and it had been cranked down, which bent the corner of the board about 2-3mm. I hope this didn’t break anything. It appears to have been done at the factory though, so I assume it’s fine.
This is the interface board. It connects the card board to the CPU board and various other things. There’s another FPGA on here and some random TI chips and various buffer chips, too. There’s also a round blue piezo feeper. The bottom of the board had some flux or something on it which looked kinda nasty, on that silver pad area, so I cleaned it off with some alcohol. It appears to have been flux from where those two through hole diodes were soldered on.
Here’s the bottom. There’s two .025″ pitch ribbon cables connecting it to the interface board. I really liked the copper thieving on this board. This is the little rectangles on the board. These are used to equalize copper usage so that when the board is made it is less likely to warp or delaminate during soldering, because the copper area vs. etched areas are equalized. The other interesting thing is there are spark gaps built onto the board, too! These are probably hard to see in the picture, but are on the connector connections on the bottom. very small traces next to each other with the mask pulled back.
Here’s the slot board. Not much going on here, though those three huge diodes are kinda neat. I dunno why they have these here, they are reverse biased in normal operation, guess they wanted to check possible negative excursions on power. The copper thieving is again evident on here. The pattern isn’t very regular either. The three large white minifit jr. plugs connect to the power supply.
HP16715A Acquisition card. This is the beast that does the digital damage. The specs are:
167MHz state667MHz timing
2Msample/channel depth
68 channels, or 34 channels with 4M/channel depth.
Up to 5 of these cards can be cascaded for 340 channels!!! Oh, and if that is not enough, you can get an HP16701 expansion chassis, for a total of 780 channels. Sheesh. I wonder what you’d need that many for. To be fair though, you can get other types of cards to plug into this beast- 2 channel oscilloscope, function/waveform generator and I’m sure others. There’s also some much faster cards which most likely use ECL devices.
Looking at the board, it’s got a metric assload of SOIC RAM chips on here… 34 to be exact. There’s two HP ASICs with heatsinks, an Actel FPGA and four HP level comparator chips on the inputs to detect logic levels. The little QFP near the bottom middle is an octal voltage DAC, doubtlessly being used to set the threshold voltage. I looked it up and that’s a $50 part. (sorry, can’t remember the part number. It’s made by Analog Devices. I would check but I slid the cards back in already).
Two of the cards were ganged when I got it. This is how that works:
There’s two little flex cables that connect near the ASICs… there’s a connector on both the top and bottom, and 5 ribbon cable slots on each board. What happens is you can connect up to 5 boards daisy chain fashion using the flex cables, then run the ribbon cables- 2 from the top 2 boards, 2 from the bottom 2 boards and connect them to the middle board which is then the master.
It’s a right pain to insert two of these together into the analyzer, I’d like to see the contortions needed to do all five! Those connectors are BGA also, so I wouldn’t want to break them.
Last up is the power supply. This supply is an absolute thing of beauty. It’s also an insane power beast capable of up to 700W. This is pretty surprising for something made in 2000. I am guessing that most of this power is for the cards, however. There’s no less than two 120mm fans blowing directly on the sides of the card cages, and a third 120mm fan to cool the rest of the guts (and two little fans on the supply). The supply is also a modular one…
Removing the top cover reveals that it’s what amounts to a voltage doubler/rectifier and what appears to be a power factor corrector. Everything in this supply is absolutely top notch quality. All Panasonic caps, FR4 PCB, excellent heatsinks and magnetics… the works! I like the little connector PCB on the end.
The supplies simply drop onto the mainframe and screw down, connecting with .1″ headers… which are carrying 360V. The supplies are connected to give out 5.1V at 35A, -5.2V at 35A, 3.3V at 70A, -3.3V at 35A, 12V at 5A and -12V at 5A. This is a lot of power. I was kinda amused to see that they wired up some of those supplies “backwards” to get the negative voltages- I guess they are isolated output, so why not? Each supply has a pot to tweak the voltage, and two of the 3.3V supplies are tied together with a short jumper, presumably because both of their outputs are connected together. This should allow them to load share properly. Each supply (except the 12/-12V one) has a separate 2 pin connector coming off of it for what I assume is a power good signal. There’s a 4 pin rainbow ribbon that comes off the mainframe board which I believe controls soft power. There’s no “hard” AC power switch on this, the little rocker on the front panel for power is low current.
And finally, the back panel. Sorry quality isn’t the greatest but it’s all I got.
In the next post, I will show off the cables and test pods and maybe some software things. I need to hack it first before I can use it, because there’s a password on it. This should be fairly easy to get rid of, however. I am going to clone the drive before I start dorking with it, in case there’s anything useful or interesting on it. I managed to get the install CD for it so I will most likely start with a clean install before I start using it.
Yep, it’s been a long time since I’ve posted anything on here, so I hope to remedy that by posting some updates of the various projects.
First on the list is the NANDputer. What is a NANDputer? it’s a computer made out of nothing but NAND gates of course! I dunno why, but I thought it’d be fun to make this. I first had to work out how various parts of a CPU would be made out of NANDs, did a bunch of tests and went to town.
The design took about 2 months to come up with and make. At the bottom of the post is a few statistics on gate usage and count of each type (2 input, 3 input, 4 input, etc). As I suspected, the quantity vs. gate input count follows a pretty steep curve, with most gates being 2 inputs, and the fewest being 13 input gates.
Everything on the design is made out of NAND gates, even the 7 segment decoding. The last PCB though has a few non-NAND gate chips like an NES PPU and a serial chip and stuff, but it’s just a peripheral board and is not part of the NANDputer proper. (Eventually I want to make a NAND UART and replace that peripheral board).
The basic architecture of the computer is actually fairly conventional. There’s an accumulator, instruction skipping (like on PIC) for decision making, a full ALU (and, add, or, xor, subtract, add with carry, subtract with borrow, set all bits, clear all bits, shifting), 8 bit registers, separate RAM/ROM areas (harvard arch), and bit set/clearing. There’s a 3 level stack, and even an interrupt!
While the CPU architecture is fairly conventional, the way it is implemented isn’t. I went with a bit-serial setup on here to save gates. The ALU for example is only 1 bit, with a “latching” carry so operations are performed a bit at a time on the 8 bit registers/memory. The program counter is also bit-serial, and on the first youtube video you can see the carry propagating during the incrementing of it.
The downside of course is that this is much slower than a parallel architecture, but this way takes vastly fewer gates. It takes 96 clock cycles to run a single instruction: There’s 16 “T” states and 3 non-overlapping clocks generated using a 6 stage johnson counter with some NAND decoding. (The flipflops that form the johnson counter are made from NANDs too). Thus, it’s 16*9 or 96 cycles per instruction. The clock runs at 10MHz, so this is a bit over 100KIPs (thousands of instructions per second). This sounds really slow but it isn’t TOO slow. It’s faster than a TMS1000, and it’s only 2-3x slower than a Commodore 64 which I estimate at 250-300kips when it runs at 1MHz (3 and 4 cycle instructions being some of the more common ones).
I eventually want to load a text adventure game on it, then hook it up to the internet and let people telnet into it and play it! So far, I have gotten a few test programs to run on it using my 8 word “bogorom”:
8 word test ROM
This is made of 32 16 position rotary dip switches, which form 8 words of ROM (program ROM is 16 bits wide). Each LED by that particular row lights up when it is being accessed. This plugs into the ROM port. It’s just 32 switches, 128 diodes, two 74HC245′s, a 74138, and a 74123 astable multivibrator chip to add wait states (this is mainly for testing- I want to use some more exotic ROM some time).
Quick overview of the various PCBs:
Timing board
Timing board
First stop is the timing board. It generates the 16 T state phases and has the johnson counter to produce the three nonoverlapping clock phases, denoted phi0 through phi2. To latch data into a register, one of these clock phases is NANDed with one of the T states. The crystal oscillator is on the timing board along with the single stepping and animate oscillator. Interestingly, the crystal I selected was a 3.6864MHz one, but the NAND oscillator is slllightly overdriving it and it’s actually running at 3x this! About 11MHz as shown on the frequency counter. I will eventually change it out to see how fast it’ll go. To quote photonicinduction, I will “Crank ‘er up till she pops” and it quits functioning properly. I might be able to get it up to 20MHz before the CPU malfunctions.
Program counter high
Program counter low
Next up is the program counter. Each board handles 8 bits of it. There’s the basic program counter latches, the 1 bit half adder to increment it, and the 3 level stack. The stack takes up most of the two boards. There’s not much more to it.
ROM and misc. logic
This board contains the ROM, and a header for a cable (not on this picture). The added header runs to the bogoROM board. A bunch of the random logic is on here- interrupt handling and JSR instruction (jump to subroutine, aka “call”) stuff. The EPROM is a 64K*16 bit model. The NANDputer supports 64K words of program ROM, in 16 4K banks. The program counter only increments the lower 12 bits, while the upper 4 are latched. This is mainly due to running out of T states to increment all the bits. If I extended the T state count, I could’ve incremented all 16.
Indexer’s bad hair day
Indexer done
Next is the indexer. Its job is to perform relative addressing, for reading or writing arrays in memory using the index register (X). The first picture of it is complete, but the wires have not been “dressed” nicely to make it look nice and tidy. It’s mainly some multiplexing and stuff.
The RAM board is next, and gets most of its inputs from the indexer. I have an 8K*8 bit SRAM on here. The empty spot on the board is for a RAM header to use external RAM devices. I hope to use core memory or a delay line memory for RAM, eventually.
ALU
The ALU is after the RAM board. Its job is fairly obvious. It can add, subtract, rotate left, rotate right, increment, decrement, AND, OR, XOR, set all bits, clear all bits and set/clear individual bits. I have not dressed the wires since I was still working on it. I think I have it fully debugged. This was the hardest part to debug and design due to the convoluted logic I employed.
The IO board isn’t very NAND-ey but this is peripherals. I don’t think making an audio or video chip would be terribly easy to do out of NAND gates. I will probably eventually replace this with a board with a NAND made UART, however. On this board are two 82C55 triple 8 bit parallel ports, 82C51 UART, 82C54 triple timer, 29F002 2Mbit 8 bit flash ROM (for storing data), RP2C02 NES PPU with 32K of SRAM, SP0256-AL2 speech chip, SN76489 sound chip, and a YM2413 FM chip. There’s also an AY-3-8912 sound chip, too.
All Nandputer boards installed into the backplane
To hook it all together is a backplane. The backplane ties all of them together, and the display board plugs into this, too.
The display board plugs into the front of the backplane, and shows what’s going on. The LED descriptions:
Top row is the program counter address and the 16 bit instruction word at this address.
The next three rows of LEDs (16 per row) are the 3 levels of the stack. Under this is the halt LED (left) and the 16 T states
Then next row is 13 LEDs. the first 12 LEDs are the RAM address (12 bits) and an unused LED.
The bottom row is the accumulator (left 8 bits) and status bits (carry, sign, zero, interrupt and an extra).
Switches on the very bottom left to right are: reset, instruction / T-state, run/stop, free-run/animate, and single step. The pot adjusts the speed at which it animates (automatic single step).
An early video of it running the program counter (note how the address “settles” down as the carry propagates up the bits making up the program counter.)
The other video is running a small 8 step program that causes the accumulator to shift a bit back and forth in “Knight Rider” fashion. The BogoROM is used to store the program.
Here’s the down and dirty on the gate and chip counts:
Well, I have deemed the FPGA Synthesizer “done”, at least in its current revision. I have still not lit up the MIDI port, but I don’t think I want to write a bunch of MIDI code in 6502 asm, so for now I have put the project on ice. It has exceeded all my expectations at this point.
So far, it plays the following stuff (all in hardware):
.NSF (complete with support for NES, VRC6, VRC7, FME7, N106, MMC5, FDS expansion audio)
.SID (complete, with quad-SID support, filters, RSID, PSID, and Compute! Gazette MUS format)
.GBS (complete, with normal Gameboy and Gameboy Colour support)
.SAP (complete, with dual POKEYs)
.SGC (complete, with support for SN76489, Colecovision, SMS, Gamegear modes)
It also plays a variety of FM music formats through a Verilog’d OPL3 (.CMF, .RAW, .IMF, .WLF, .D00)
Internally the following sound chips are written in Verilog by me:
6581/6582/8580 SID (quad, with full filters, full combined waveforms, proper ADSR w/ original bugs, 95% of a C64 to run RSID tunes, hardware filters)
RP2A03G NES (all expansion chips supported: VRC6, VRC7, FME7, N106, MMC5, FDS)
POKEY (As found on the Atari 8 bit line)
SN76489 (used for GG/SMS/Coleco)
AY-3-8910 (Written, but not used by a replayer yet)
OPL3 (FM support, can play OPL2 music also)
There’s around 70 or 80 separate sound channels that eventually get mixed down inside to the final DAC outputs. Most outputs have full user control of volume and channel selection, and if it gets filtered by the hardware filters or not.
The packaging was finally finished, along with the capacitive touch panel for the user interface. Battery charging and control are likewise finished, and I ended up implementing a first order derivative for the end of charge detection. Voltage depression isn’t very detectable on NiMh cells, so I couldn’t use that easily. The PIC’s ADC was too noisy to pick up the changes, so I went with delta temperature over delta time. When temp rise hits 3 degrees/minute, the charging is terminated. It works very well and doesn’t detect false ends of charge. There’s also a maximum temperature cutoff and a maximum time cutoff in case of some other kind of failure.
This is the UI PCB, it is a capacitive touch based affair.
Front of the finished synthesizer.
Side view.
Back view, showing power button and charge LED.
The guts.
So that’s the finished result. It didn’t come out too bad after all, but I did have to hack up the UI PCB some to make it work- Specifically I had to mount it on the top of the box and run wires to a cut up PCB inside that has the touch chip on it. The plastic was just way too thick on the enclosure for it to work through the plastic, unfortunately. But, the end result is pretty nice and the capacitive touch stuff works extremely well, so in the end it all worked out.
I will be working on a new synthesizer sometime in the future, which will be programmed in C, making development alot easier. Midi’s being reserved for that time.
Well it’s been awhile. I haven’t been lazy, far from it. Been so busy I haven’t had much chance to update the blog! I spent the last 2 months learning verilog, and then performing a 100% conversion of my project from schematic entry to 100% verilog! I didn’t know anything about verilog until having a little discussion with someone about it, and it seemed like a good time to learn it. I already had a working project in schematic entry (around 150 schematics all linked together in this case) and figured it’d be a good learning experience to port it to verilog.
Long story short, the conversion was a success, and I ended up fixing a few bugs and adding some features along the way. I ended up 100% redoing my OPL3 core, and vastly simplified and improved it, reducing device resource usage immensely. To date, I have full support for the following sound chips: SID (quad), POKEY (quad), OPL3 (full support), NES audio, N106 (8 chan wavetable), VRC6 (3 channels), VRC7 (FM synth), MMC5 (two squares+digi), FME7 (3 squares), and FDS audio (1 chan wavetable). The wishlist of additions is: Atari 2600 with extended range, Gameboy sound, and coleco/SMS sound (SN76489). These shouldn’t be too tough, but before I can implement those I need to emulate the target CPUs which are Z80 and GBCPU.
This leads me to the current work: I created a small RISC CPU for the FPGA which can emulate other 8 bit CPUs with cycle accuracy. I figured that emulating the 8 bit CPUs would be by far more resource efficient on the FPGA, since to change the emulated CPU I only have to change the code in the block RAM. Thus, 6502, Z80, GB CPU, etc. can be accomodated without sacrificing accuracy or speed, while only requiring one peice of hardware. Ironically, the RISC CPU is smaller than the 6502 it will replace in FPGA resources. The only minor downside is the 4K of blockRAM I used, but that’s a small price to pay ultimately for what it can do.
The specs on the CPU are: 18 bit instruction word, single cycle instructions, 32 bytes of RAM, single and dual byte address modes, and a few special instructions to make CPU emulation easier such as jump tables and bit setting and clearing. I named it the “KevRISC” CPU
