The Curious Case of Coleco Copy Control

I was talking to a friend about the game Risky Rick- a new homebrew for the Colecovision produced by Arcadevision. Specifically, he dumped the game so he could play it on his Atarimax flash cart without having to put wear on the original cartridge. After dumping, the game worked but would mysteriously prevent you from completing level 1. You could play through level 1, and at the end where you crawl through a small gap to the next level, the game will not let you progress at the edge of the screen.

Checking the Atariage forum thread about this game revealed that several people have had this same mysterious bug with the game… even playing the legit cartridge. Arcadevision’s reply was simply the game is not designed to work on “modified” Coleco systems, and those people were basically on their own.

After many pages of back and forth between people who couldn’t get the game they purchased to work properly on their Colecovisions, someone discovered that if pin 13 on the cartridge was grounded, the game would work!

Reading the thread some more , Arcadevision declared that the game had no DRM, and it was just the “modified” systems’ fault. Not to pass up a detective story this good, I obtained the current ROM dump, I promptly disassembled it and went through the code.

On first inspection, the game appeared to have no copy protection, detection routines, mappers, or anything like that. It was just a flat 32K ROM image. Sure enough, you get stuck at the end of level 1. Interestingly, there’s quite a bit of what looks like wasted space near the end of the ROM with a repeated data structure.

At this point, I smelled a rat and figured everything was wrapped up in pin 13 of the cartridge. Checking a pinout here: reveals that pin 13 is a ground. The schematic for the Colecovision shows that this isn’t really a true ground- it’s a “shield ground”. It is only connected to ground through the metal shielding that covers the PCB.

The commercial Coleco cartridges do not connect pin 13 on the cartridge at all- pin 29 is the actual circuit ground which is connected to the chips on the cartridge. This means, the game could be using pin 13 to determine if you had an “modified” system or not!

Pin 13 was measured with the power on, and showed 5V. This means the pin is connected! A normal cartridge would show nothing here. After grounding pin 13 and redumping, the data was totally different from the first original dump, confirming that there are two ROMs in the one cartridge- the “demo” version of the game, and the “full” version of it.

This explains why people who did the “5V RAM” modification to their Coleco to fix the VRAM had issues with the game. The mod itself was a red herring, and the real reason was they replaced the RAMs and didn’t bother to put the shielding back on. I don’t blame them, either. It’s a big pain to remove and install it. At least one person had a stock Coleco that was untouched, and the ground tab from the shield was bent so it didn’t make contact, and only being able to play the demo is the result.

Apparently, the common Coleco cartridge dumpers do not connect pin 13, which means when dumped this way, you will get the demo ROM and not the full game. Grounding pin 13 on the dumper fixes that problem.

Once the “real” game’s ROM image was obtained, it did not work on the Atarimax cartridge, or emulators. A disassembly of the new ROM showed that there was now some extra code added to the front before the game code itself! At this point, I knew Arcadevision was lying about not including DRM with the game.

The TL/DR version is that there’s a routine that first detects emulators by testing RAM. It does this by checking adjacent bytes of RAM. If there are 256 or more adjacent bytes, the game will crash/lock up. Interestingly, hitting reset will bypass this test- it only does this check once on reset.

The second check is a bit more insidious, and I know at least one person where this test falsely flags their Colecovision as unclean, and the game won’t run at all. The check works by testing the Coleco RAM at boot for 8 consecutive ASCII characters. If they are found, it will crash/lock up. This works by checking each byte of RAM for the value 0x20-0x7b or so. If 8 consecutive bytes are in this range, it’s game over.

This test is pretty poor because there can be a high chance of 8 bytes being in this range in order somewhere in the 1024 bytes of RAM. I am fairly convinced this test is specifically for the Atarimax flash cartridge. The game refuses to run on it no matter what.

If you wish to bypass all the copy protection, change byte 0x000a in the ROM from 0x25 to 0x74.

Conclusion: Arcadevision released a homebrew that had three forms of DRM in it, while denying it had any. The pin 13 trick is absolutely brilliant and I have to give them credit for figuring that out. The unfortunate thing is now that the cat’s out of the bag, it was a one shot deal and that DRM will never work again. Two of the software checks were kind of a dick move and can get triggered even on legit systems.

If you’re interested in the software protections, here’s an in-depth.

On the demo version of the game, the game code starts at address 8025:

8025: CD 83 83 CALL 8383
8028: 21 00 00 LD HL,0000
802B: 11 00 40 LD DE,4000
802E: 3E 00 LD A,00
8030: CD 82 1F CALL 1F82
8033: 21 00 20 LD HL,2000
8036: 11 20 00 LD DE,0020
8039: 3E F0 LD A,F0
803B: CD 82 1F CALL 1F82
803E: CD 85 1F CALL 1F85
8041: CD 7F 1F CALL 1F7F

This has a pretty well defined structure, calling some BIOS routines to clear memory and such. We can see this same code on the full version of the game, but it’s shifted down in memory.

8074: CD D2 83 CALL 83D2
8077: 21 00 00 LD HL,0000
807A: 11 00 40 LD DE,4000
807D: 3E 00 LD A,00
807F: CD 82 1F CALL 1F82
8082: 21 00 20 LD HL,2000
8085: 11 20 00 LD DE,0020
8088: 3E F0 LD A,F0
808A: CD 82 1F CALL 1F82
808D: CD 85 1F CALL 1F85
8090: CD 7F 1F CALL 1F7F

As you can see, the code has been shifted down 0x4f bytes vs. the demo.

The protection code is in two parts. There’s some fancy footwork to calculate an address and push it on the stack for use later. This is just pure obfuscation, and pretty poor obfuscation at that.

The BIOS code looks like this starting at the reset vector:

A0000 LD SP,Stack ; Initialize stack pointer
x JR L006E ; Go to rest of cold-start code
L006E LD HL,(0x8000) ; Check first word of cart for 55AAH
x LD A,L ; 8000=55H and 8001=AAH
x CP 55H
x JR NZ,L0081
x LD A,H
x JR NZ,L0081
x LD HL,(0x800A) ; If 55H/AAH, jump into cartridge
x JP (HL)

Then the protection code start:

8024: 11
8025: 11 2A 00 LD DE,002A
8027: 00 NOP
8028: 19 ADD HL,DE
8029: E5 PUSH HL ;add 002a to 8025, store onto stack (804f)
802A: D9 EXX
802B: 3A 24 80 LD A,(8024)
802E: 21 FF 73 LD HL,73FF ;check 11 from 8024 against a RAM byte at 73FF
8031: BE CP A,(HL)
8032: C8 RET Z ;if they are the same, jump to 804f

Address 0x800A holds 8025, which is where execution will start. The first thing the code does is adds 0x2A to the HL register, which is set to 0x8025 in the BIOS routine that points HL to the code start. This means HL will hold 0x804F. This is pushed onto the stack.

The EXX is just misdirection, and not used by anything. Next, HL is loaded with the last byte of RAM, which is used to determine if this is a warm or cold boot of the system. The byte is read from ROM (which is 0x11, from address 8024) and then compared against the last RAM byte.

If the value matches, the RET Z is run, which jumps to 0x804F and skips the first protection check. Otherwise, execution continues at 0x8033 for the first check:

8033: 77 LD (HL),A ;not the same, save it to RAM
8034: 01 00 04 LD BC,0400 ;bytes to test
8037: 21 00 70 LD HL,7000 ;RAM pointer
803A: 11 00 00 LD DE,0000 ;detection count
803D: 7E LD A,(HL) ;get a byte of RAM
803E: 23 INC HL ;increment RAM pointer
803F: BE CP A,(HL) ;compare to the next byte of RAM
8040: 20 01 JR NZ,8043 ;if the bytes do not match, skip the INC DE
8042: 13 INC DE ;increase detection count
8043: 0B DEC BC
8044: 78 LD A,B ;OR B and C registers together, this sets us up to check BC for 0
8045: B1 OR A,C
8046: 7A LD A,D ;put D into A
8047: 20 F4 JR NZ,803D ;we test all 1024 bytes.
8049: B2 OR A,D ;A holds the upper byte of the detection count. OR with itself will check it for 0
804A: C8 RET Z ;if 255 or fewer matches, jump to 0x804F by using RET
804B: 10 E7 DJNZ 8033 ;fall through otherwise.. this will wedge/crash
804D: C5 PUSH BC
804E: C9 RET

The first thing that happens is 0x11 is written to the last byte of RAM, so next time the system is run, this first check will be skipped. This means there’s a 1 in 256 chance that a typical Coleco will never run this check, or only run it some times.

Next, BC is loaded with the byte count (1024 bytes), HL is loaded with the start of RAM, and DE is cleared. DE holds the “match count”.

Next, the first two bytes of RAM are compared against each other. If they match, DE is incremented. The next two bytes are tested, and so on. All 1024 bytes are tested, then the upper byte of the detection count is checked. If it’s 0, the protection passes. Otherwise the DJNZ and such is run, which will wedge/crash the system.

Assuming the check passed (or the user hit reset) the next check is run:

804F: 21 00 70 LD HL,7000 ;start of RAM
8052: DD 2E 00 LD IXL,0 ;detection count
8055: 01 00 04 LD BC,0400 ;1K of RAM
8058: 7E LD A,(HL) ;read RAM byte
8059: 23 INC HL
805A: FE 20 CP 20
805C: 38 0E JR C,806C ;jump is the RAM byte is <= 20 (this detects ASCII) 805E: FE 7B CP 7B 8060: 30 0A JR NC,806C ;jump if the RAM byte is > 7B
8062: DD 2C INC IXL ;increment detection count
8064: DD 7D LD A,IXL ;check IXL against 8
8066: FE 08 CP 08
8068: 28 E5 JR Z,804F ;if we detect 8 ASCII chars in a row, jump back to the start of the detection code and wedge
806A: 18 03 JR 806F ;ASCII char, but we didn't find 8 yet
806C: DD 2E 00 LD IXL,0 ;reset count if we hit a non-ASCII character
806F: 0B DEC BC
8070: 78 LD A,B
8071: B1 OR A,C ;decrement and check byte count
8072: 20 E4 JR NZ,8058 ;do all bytes. fall through into the game code if it passes

This next check is interesting, because they use the lower 8 bits of IX as an 8 bit register. They are using “undocumented” opcodes for this. There is absolutely no reason, other than to obfuscate the code, or to cause issues with emulators that do not implement those opcodes.

The check here is fairly straight forward- it scans through the RAM and increments IXL if the value is in the range of 0x20-0x7B, which is the ASCII range. This range occupies a bit less than 50% of the ‘byte space’, i.e. the values 0x00-0xFF. This means, there’s roughly a 1 in 512 chance that a particular Coleco can falsely trigger this check. The bad news is, RAM data on boot isn’t 100% random, and certain locations can have the same or very similar value each power on. It is determined by the small differences in each chip, and this means you might have an “unlucky” Coleco that always or mostly always falsely triggers it.

The fix is simple to bypass the protection, changing byte 0x000a in the ROM from 0x25 to 0x74 is it. This works because it changes the start address to 0x8074, which is the start of the game code.

Hope this was informative. It sure was fun to work all this stuff out.

Tektronix PS2521G Power Supply Teardown


Weellll, I needed a good bench power supply, so I finally broke down and bought one.  I got a Tektronix PS2521G.  This doodad has three isolated outputs.  This means that each of the three outputs can be wired in series or parallel with the others, and can float above ground or the other supplies.   There’s two identical 0-20V at 0-2.5A outputs and a single 0-6V at 0-5A.  Giving this supply a total of 130W it can output if all the outputs are going full bore.




Finding a triple output power supply at all was fairly difficult.  There’s only really two good ones to choose from.  This model and an Agilent/HP one (E3631A).  The problem with the Agilent is you’re stuck with ground referenced supplies, and a mandatory +/- supply.  This Tek one has similar ranges (and higher current) but the supplies are all isolated so you can connect them in any fashion you desire.


Anyways, on with the teardown!


Front Panel (After I cleaned it)

First a quick going over of the front panel.  There’s three sets of output binding posts and another “earth ground” binding post that is connected directly to the chassis ground and 3rd pin on the AC line plug.  The small 7-segment display on the left is the memory number (there’s 99 supposidly to remember various configurations), the current limit and the voltage limit for the selected channel.  Buttons include a usual 10-key interface and buttons to set current or voltage.  The supply has a cool feature where it can put supplies 1 and 2 into either series or parallel mode using relays, to get more voltage or more current out of them.  In fact, all three supplies can be series or paralleled to get even more voltage or current.

Removing the case involves removing the 6 screws on the sides (3 per side) and removing the handle.  Then the top just comes off.  The very large transformer absolutely dominates the inside, along with the interesting heatsink/air tunnel doodad that is directly cooled by the fan.  That transformer seems to have at least 11 windings on it for the various supply voltages.


Back showing the “wind tunnel”

What’s interesting about the “wind tunnel” heatsinking is that it’s actually made up of four separate heatsinks with small baffles between them for insulation and air tightness.  This was done because the large TO-3 transistors are directly mounted to the heatsinks, without any insulating pads.

supply2 supply3

Here’s the inside view looking down from above.

There’s a GPIB board (I think this was an option you could buy) in the lower right of the rightmost picture, which allows someone using i.e. Labview to change the settings on the supply from an application on a computer (i.e. for automated testing).  I think an RS-232 option was also available.


Right side, showing 6 regulators; three of them heatsunk

On the right side, there’s a riser board which contains no less than 6 regulators.  The three on heatsinks are all 7805’s while the other three are a 7805, 7815? and 7915 I think for the 0-6V supply.  The relays and big .3 ohm resistors are for current sensing and emitter swamping.  The ribbon cable connects to the CPU board in front from the GPIB slot.


Left Side, supplies 1 and 2.

On the left, supplies 1 and 2 are hiding.  The circuit for all three supplies is pretty much identical;  There’s an AD7541 12 bit DAC for each supply, which appears to be analog sample and holded to get 3 or so separate outputs.  This DAC costs $46 at Digikey and there’s 3 of them on here.  The three outputs are Vset, Iset, and I think overvolt voltage.  Interestingly I could not find any voltage sensing apparatus on here, for when the current regulation kicks in for example (or to show how many amps a load is drawing).  I am wondering if they are doing some kind of self-made ADC using dual slope or similar since there’s an awful lot of 40xx analog multiplexers on here.


CPU Board

The CPU board is quite simple- just an 8031, 2K of NVRAM, 32K EPROM, a few latches/decoding chips and an 82C79 which is a single chip keypad reader / LED display driver.  There’s 5 optoisolaters per channel too, for a total of 15.  Notice how the ground/power planes are pulled back underneath them.   I have dumped the EPROM and the sumcheck matched.  I also socketed and dumped the NVRAM since it was made in 2000, and I don’t trust its 13 year old battery.  If the NVRAM goes, I think the calibration information goes with it.

So that’s what’s inside the power supply.  I was pleasantly surprised that they used NO custom parts at all, save the transformer which is unavoidable.  Every chip and transistor inside is a standard off the shelf part, so fixing it shouldn’t be much of an issue, and since the NVRAM is dumped I don’t have to worry about that dying and having to recalibrate this thing.


FPGA Videobrain is Done

I finished up the FPGA Videobrain now.  Most of the work was reverse engineering the original system, which took forever.  I have completed that work and the document I wrote, “Videobrain Unwrapped” is available here:

Videobrain Unwrapped


Not much more to say about it, other than I verilogged (is that a word?) the Videobrain and stuffed it into an FPGA.  Everything seems to work fine including joystick reading, which I have made work with a D-pad.  This is not 100% optimal since most games actually DO use the analog nature of the stick, but it gets it working for now.  Dropping in “analog” values in the future will require no more than 5 minutes, because I am properly emulating the joysticks.


Here’s a youtube video of it in action, playing a few games:

Next up: FPGA Arcadia 2001!

Videobrain RGB and fix

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.

Perfboard Videobrain Fail

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.

Setting up the Logic Analyzer

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!

More updates as I get to that point.

I Got a Logic Analyzer, woot!

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.

hp16700_cpu_top hp16700_cpu_bot

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.


hp16700_options_bot hp16700_options_top

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.


hp16700_scsi_top hp16700_scsi_bot

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.

hp16700_interface_bot hp16700_interface_top

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.


hp16700_chassis_bottom hp16700_bottom_top hp16700_bottom_bot

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.


hp16700_slot_top hp16700_slot_bot

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:

hp16700_acq_connect hp16700_connector hp16700_acq_connected

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.

hp16700_psmounted hp16700_supply_nameplate


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…

hp16700_supply_open hp16700_supplies_end

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.

hp16700_supply_mainframe hp16700_supply_units

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.

hp16700_back hp16700_empty_chassis

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.