What do you do when you get a diagnostics cartridge that doesn’t work? Make your own, to make sure your computer isn’t too sick to be diagnosed. And then you can diagnose the diagnostics. Why, how do you spend your Friday nights?

I first got involved in this project because I saw a VCF forum thread asking if anyone still had a working Coleco ADAM. Of course I do: I put a new power supply on it about two years ago. Long-time poster VERAULT had made a cartridge, and wanted me to test it on real hardware and take some pictures.

After testing my machine to make sure it still worked, he sent it to me, and I dutifully plugged it into my ADAM. And… it crashed. Hung up the machine right after pulling the “cartridge reset” switch on the ADAM.

As you do, I tried this a few more times, to no different result. Once, I got some green garbage on the screen by pulling the reset switch again very quickly. Then I did my usual tests: pinout, ROM in the right way around, clean fingers, etc. No difference.

The next thing to do was to desolder the ROM and dump it. This dumped consistently (back-to-back dumps had the same md5) and it matched the md5 that VERAULT had, so the postal system hadn’t magically erased the EPROM in transit.

The ROM also loaded properly in MAME, but not CoolCV: more on this in a second.

I socketed the cartridge and then stuck in another ADAM ROM: the ADAM Demonstration Cartridge. This is a pretty, but unremarkable, slideshow demo that was clearly meant to attract shoppers at computer stores. Who could resist?

The CoolCV 0.6.6 emulator, made by Oscar Toledo, crashed as soon as I loaded the ROM. And it crashed on very similar green garbage to the garbage I had witnessed before when I was glitching the reset switch. I went to go ask him about it, and it turns out he had already seen this phenomenon with this ROM before.

The ADAM has a very crude form of page-switching; you can divide the memory map into upper and lower chunks, changing them out by writing to port $7f . Turns out that even though the ADAM documentation says that only $7f works, the actual machine decodes $60 to $7f – and the ADAM Diagnostics cartridge was writing to port $60 . Oscar had fixed it in CoolCV 0.7.0, which he gave me a copy of. Indeed, this ROM now loaded up fine in the fixed emulator.

This seemed unlikely to be the problem with my hardware: I think they only made one revision of the ADAM, and I strongly doubted that my memory-mapper IC would fail in such a way that it would work fine on everything else but fail on decoding. Still, to be sure, I disassembled the ROM, switched all the memory-mapper port writes to $7f , and then reassembled it. CoolCV 0.6.6 now ran this modified ROM properly, but the ADAM did not.

I also realized at this point that the ADAM Demonstration Cartridge was perhaps not a great test for this problem. Upon disassembling it, I realized it didn’t ever try to change the ADAM memory map! I switched to testing using TapeUtl, an internal Coleco program meant for copying tapes, which does touch the memory manager. It ran fine, although I didn’t actually try to copy any tapes.

I’m Going To Make This Weird

To rule out ADAM hardware faults, I began to write my own diagnostics. At least then I would know exactly what it was doing, and be able to hack up the software to probe at different problems. I’m calling this tester Badam and it is open source.

My first port of call was the Coleco ADAM technical reference manual, which contains a bunch of info about how to use the memory mapper. The ADAM offers a whole lot of stuff that makes it a lot more powerful than the ColecoVision. Just take a look:

That’s right. You can have 64K of RAM in this sucker without any expansions. And not just that, but you can leave it with access to the ColecoVision BIOS (OS7,) and write cartridge games with 24K of RAM without having to learn any of the new ADAM EOS APIs. That’s twenty-four times as much RAM as a stock ColecoVision has. It’s a pity they didn’t make more ADAM games to take advantage of this huge expanse of memory.

Of course, my first pieces of test code did not work properly. I could get the cartridge header read to display the ColecoVision boot screen, sure, but after that I could not write any graphics to the screen. It turns out that my VDP-writing macros (recycled from the BBC Bridge Companion and the Soggy-1000 RAM tester) had been pasted into the wrong place, and the assembler was emitting no code at all when it should have been telling the ADAM to start outputting video.

Writing the tests wasn’t too hard, although at first nothing at all worked. It turns out I was writing to port $f7 instead of $7f to try and change pages - don’t code tired.

What I’m most proud of is the ADAM upper-RAM test. Because the cartridge lives in upper-RAM, there’s no way to test the top 32K of RAM without mapping it out. But if I unmap the cartridge, there’s nowhere for the CPU to read the test program from.

What I ended up doing was this:

1. Write a small block of test code (the “kernel,” for lack of a better term.)
2. Switch the lower page to 32K of RAM. This means the ColecoVision OS7 BIOS is now unmapped, so I can’t call any BIOS functions.
3. Copy that block of test code into lower RAM.
4. Jump into that test code, so I’m fetching the program from RAM now instead of the cartridge.
5. Switch the upper page to “upper 32K of RAM,” unmapping the cartridge.
6. Run the test.
7. When it’s done, switch the upper page back to the cartridge.
8. Jump back to the cartridge.
9. Switch the lower page back to the ColecoVision BIOS.
10. Print the results of the test to the screen.

It was really hairy! I couldn’t figure out how to make ZASM correctly figure out the relative offsets, so I had to guess, and then patch up a couple of the pointers manually with an offset calculated by hand. Oh well!

I guess I’m a real assembly-language programmer now. I’m sorry mom, I failed you.

Is My Adam’s RAM Badam?

Time to test my newly-developed RAM tester on a real ADAM.

Unlike the ADAM Diagnostics ROM, I kept the ColecoVision boot screen. If you went back in time and told eight year old me that one day I’d be filling out the boot screen with my own software, he’d probably have asked me why I was still using a ColecoVision in 2024.

The tester launched shortly after that, and revealed to me that in fact my work-RAM seemed fine. For an extremely basic write-then-read test, that is.

Page-switching and the work RAM in my ADAM seem fine. So this very simple, lowest-common-denominator test shows that bad RAM is probably not why the other diagnostics cartridge is failing.

What Else Could Be Badam?

I dumped my findings in an AtariAge thread and then went to VCF Midwest. While I was at Midwest, I got to test on the FujiNet booth’s ADAM, where the cartridge crashed identically. AtariAge posters also reported that it crashed when launched from their flash cart.

While I was gone, the community figured it out for me. Like shoemaker’s elves.

After making the thread, Shawn Merrick showed up and said that it also didn’t work on his machine.

He theorized that it was probably a bad dump, or simply the wrong one for my configuration. Apparently, multiple versions of this ROM leaked out of Coleco, and were modified on the spot for specific configurations of expansion-RAM, etc. He said there was a different dump that worked on his machine, which I then immediately downloaded.

I shoved the two ROMs through a vbindiff, and found that there were a few “wrong” bytes, off by a couple of bad bits. For instance, $09 became $0d .

After disassembling the ROMs (z80dasm) and diffing the disassembly, it seems to mostly be constants getting pushed into the accumulator. It’s not different calls, control flow, or anything wildly wrong, so I started looking into it more.

I burned this new ROM and swapped it into the cartridge. The ADAM ran it fine: I didn’t have a joystick plugged in, but I was able to get to the bootscreen…

…And then the first help screen. That’s a lot better than I usually got out of this thing.

I went ahead and grabbed some pseudo-high-quality captures from my ezcap for VERAULT, and made this little video:

So: the first ROM was indeed bad. Or was it? What was it making the ADAM do?

Parallel Disassemble, Stephanie

After the initial rush of finding the answer, I began to wonder if the ROM were actually bad. It’s very odd that the two ROMs are so similar, differing only by a small smattering of bytes, and all in the same instruction.

If there were truly a bad bit on the dump, I would expect there to be much more wrong. Is it possible that this first dump is simply designed for some other hardware configuration?

I threw the two disassemblies into Beyond Compare, and immediately had my answer.

On the non-working version, it’s writing $09 into the memory mapper port, which corresponds to 0b1001; the ADAM technical manual tells us that means that it is targeting expansion RAM and 32K intrinsic RAM.

That is not gonna work, as it means the machine is paging away the very cartridge ROM that it needs to know what to do next! No wonder it crashes. This ROM was probably meant to run from tape¹ or disk, where it would be already loaded into RAM before execution starts.

By contrast, the working version writes $0d - 0b1101 - which keeps the cartridge loaded into upper memory and 32K internal RAM in the lower memory. In this scenario, the program can keep executing from the cartridge, so it doesn’t crash.

Don’t Get Madam, Get Even

This was a fun mini-adventure into the world of old ROMs lying around. It’s a good thing that VERAULT sent me the ROM to test, and I thank him for the cartridge PCB. I also want to thank the entire ColecoVision community, especially the people replying to the AtariAge thread. In particular, Shawn Merrick stepped up to find a dump that actually worked! Thank you all.

So what’s next for Badam, my sketchy Coleco ADAM memory tester? Probably nothing. I might add a joystick tester feature later, but there’s already a wealth of Coleco diagnostic software out there. It was a fun project for an evening, and I learned a little bit about ADAM programming in the process.

The whole thing has made me want to do more stuff with the ADAM, as well. I would like to do a floppy drive adapter/controller. For now, though, let’s bid adieu to the Eden of Coleco ADAM diagnostics and figure out why all my other computers aren’t acting properly.

1. If I had been thinking more clearly, this could have been more obvious to me: when the software loads, it says it’s from the “Smartpack™ software series.” Coleco really liked to use the “Pack” nomenclature for their tapes, which they liked to call Digital Data Packs. ↩