Diagnostic diagnostics, or: you can Checkout Cartridge anytime but you can't leave

[leaded solder]

Hello all. Long time annoyance, short time poster. Today I've got a bit of a project.

 

VERAULT over on the VCF forums hit me up with a request to test out a mysterious "ADAM Diagnostics" cartridge on real hardware. It looks kind of like this. The cartridge maps the ROM into the 32K cartridge space and nothing spectacular is going on here.

 

 

When I fired it up on my long-suffering but relatively reliable ADAM, however, it appears to simply freeze the system. Smartwriter stops responding to keyboard input, and the screen doesn't change at all.

 

This was strange to me, so I desoldered the 27c256 ROM and dumped it in my TL866. The ROM dumped consistently back-to-back and produced the MD5 of adaf8fefa825434232bc5c44d1bb8709 which is the exact same one as the "ADAM Diagnostic Cartridge (1982) (Coleco).rom" file floating around in the collection on this excellent thread. In other words, it's the "Check-Out Cartridge."

 

 

The ROM loads fine in emulators - both CoolCV 0.7.0 and MAME 0.253 have no problem running it. A logical conclusion is that my ADAM has some fault. I tend to blame my own hardware, usually because they're all sketchy rescues, and because I'm the kind of guy who smells coolant when stuck at the light and assumes it's his car.

 

My ADAM has never had trouble running ColecoVision cartridges in the past and will happily (if noisily) load tapes. I've never noticed any kind of fault with it other than "being enormous" and "some idiot made a new power supply for it and made the power cord too short."

 

I burned another ROM of software that was labeled "for ADAM" – the "ADAM Demonstration Cartridge (198x) (Coleco) [o1].rom" from the same collection, and this seems to work fine. However, looking over the disassembly, this demonstration cartridge didn't seem to do anything exotic - no memory-mapper adjustment, no fancy DMA shenanigans, not even using a lot of RAM. So it was maybe not a fair test.

 

 

As a laugh, I decided I'd start on my own diagnostic cartridge; maybe I can narrow down something that's wrong with my ADAM's hardware and rule it in or out. RAM testing is a logical place to start, I thought. RAM goes bad all the time and I don't need to know too much about the ADAM hardware in order to write a test program for it.

 

One evening later, I had a feasible RAM test, and two evenings later I had it testing all four intrinsic-RAM modes of the ADAM's memory mapper. (Internal/external expansion RAM testing will have to wait until I make one of those units.) If you're curious you can grab the source code here and contribute patches, or just laugh at me.

 

 

Annoyingly, the RAM test passed with flying colours on my machine. It's pretty basic - just writing $55 and $aa to test alternating bit patterns in a linear march through memory space - but I think it is probably enough to rule out a bad bit somewhere.

 

Once I get back from VCFMW, my plan is to further disassemble the check-out cartridge ROM, and start writing mutant versions of it so I can figure out exactly where the machine is freezing up. I've ordered a handful of PiColeco PCBs to make this easier so I'm not spending the rest of my life in the UV eraser.

 

For your part, I would super appreciate if someone who knows more about the system could do the following homework to help make me feel less insane:

 

• Please test a cartridge containing the Diagnostics ROM on your ADAM(s). Does it freeze up there too?
• If you already have a cartridge containing the Diagnostics ROM, please dump it. Does it match the above MD5?
• Please idly speculate on what I could have missed.

Thanks! I'll post updates here when they happen. I'll also be carrying the cartridge with me to VCF Midwest, in case someone has an ADAM on their table and is willing to let me plug random hardware into it during a show. Send me a PM if you are that person.

Edited September 5 by leaded solder

[NIAD]

7 hours ago, leaded solder said:

For your part, I would super appreciate if someone who knows more about the system could do the following homework to help make me feel less insane:

I'll test it out ASAP and report... via the rom file on an AtariMax Ultimate SD Cart.

 

The ADAM Diagnostic dump in post #12 on April 6th of that thread (forgot all about that thread and the time it took to assemble all the info!) is a verified good dump. I dumped the original cart five times with an AtariMax MaxFlash Cart with CV Adapter and received the same CRC for each dump.

 

Another In-House test utility you should check out as it's much more thorough is ADAM Final Test - Menu Version (198x) (Coleco).rom and Eric Pearson has developed and released numerous test utilities that are available in Rom image, Disk image and Boot Rom image (for installation on a Slot #2 expansion card that has a Boot Prom socket) that you should check out as well depending on if you have additional hardware such as an ADE or FujiNet SD Drive and or the necessary Slot #2 card. Everything is available on The ADAM Archive in the following directories:

 

ADAM In-House Cartridges - (AdamArchive.Org) - The home for everything ADAM

ADAM Homebrew Cartridges - (AdamArchive.Org) - The home for everything ADAM

ADAM Boot Proms - (AdamArchive.Org) - The home for everything ADAM

ADAM EOS Disk/DDP - (AdamArchive.Org) - The home for everything ADAM

ADAM CP/M Disk/DDP - (AdamArchive.Org) - The home for everything ADAM

 

and don't forget some of the ColecoVision only test programs as they can help pinpoint issue(s) seeing as there is an enhanced CV board in the ADAM:

 

CV In-House Cartridges - (AdamArchive.Org) - The home for everything ADAM

CV Homebrew Cartridges - (AdamArchive.Org) - The home for everything ADAM

 

If you do come across a RAM issue in your system, here is something that you might find interesting made by John Lundy along with all his other CV & ADAM products:

 

ADAM Delta DRAM to SRAM Converter - Lundy Electronics

 

[leaded solder]

Short update: at VCFMW, I dropped by the FujiNet booth and hijacked their ADAM display for a bit. It appears that their ADAM, which is probably rock solid considering it must have run for at least 18 hours that weekend, also locked up in a similar way to mine while booting the mystery cartridge.

 

I haven't had a chance to sit down and think about it (Midwest was my first VCF and it was great!) but as far as I can tell the crash has been reproduced.

 

Thanks to Thom and Jeff for the opportunity to do debugging the way our ancestors have since the dawn of time: while demoing it to the general public.

[Shawn Merrick]

Hello,

 

Best clever thread title in some time.  Well done!

 

I've tested this 1982 ADAM CHECKOUT CARTRIDGE ROM (must be MD5 of ef707c8045afc26e3e4d09c03aba5de6) tonight on my standalone ADAM system with an ATARIMAX Ultimate SD and it worked properly.  You might already be aware that running this ROM or real cartridge requires pressing ColecoVision RESET so SmartWriter should no longer be on screen.  However, SmartWriter will come up initially at ADAM power-on or if pressing the ADAM RESET and it did not hang on my system while active.

 

This leads me to think there is a fault in that physical cartridge or something in your ADAM unit beyond the ability of the cartridge.  Given the issue also happened on another ADAM unit, I would examine the cartridge contacts very carefully.  Additionally, there are a number of other genuine Coleco diagnostic ROMs with various strengths and abilities.  This 1982 one is not particularly good except it has a graphical interface making it LOOK better.  Each diagnostic ROM requires a working game board (or ColecoVision unit) for reliable results.  This is why I start with ColecoVision Final Test ROM and then follow up with Gamma Debug ROM and finally ADAM Final Test Menu Version ROM.  There is no point using disk or tape based dumps of these titles as they are severely limited compared to the ROM versions.

 

Incidentally, the symptom of SmartWriter hanging is often due to ADAMNet hardware or cabling faults and may be sometimes induced by having a disk drive (or drive emulator) attached without drive also being powered on.

 

I realize you are checking out the individual cartridge for VERAULT and I tend to think it is bad rather than the ADAMs.

 

EDIT: I just found out that MD5 you gave does NOT work on my ATARIMAX and leads to a blank screen on a real ADAM.  It still does not hang SmartWriter, but that is probably worked around due to the ATARIMAX having additional processing not on the dedicated cartridge you have.  The WORKING version of CHECKOUT CARTRIDGE has an MD5 of ef707c8045afc26e3e4d09c03aba5de6 and is titled ADAM Diagnostic (1982) (Coleco).ROM at www.adamarchive.org 

Edited September 11 by Shawn Merrick
Added Content

[leaded solder]

Thank you Shawn! I think you've cracked it. I was at VCF Midwest over the weekend, what a great party.

 

As I posted over on VCF just now, I had a chance to throw the two ROMs through vbindiff. This revealed that there were a small handful of differences (and not all off by one bit: there's one, for example, that goes from $08 to $0d, that's worrying). This is consistent with the theory that it's a bad dump.

 

It's a very strange pattern for a bad dump; I would have expected more bits to be bad. My active theory is that the EPROM on the original cartridge was bit-rotting to start with.

 

I threw both through z80dasm and compared the disassembled listings, and it does seem to affect some kind of constant getting written into the accumulator, but I haven't had a chance to figure out in context what this affects. This will probably have to wait a couple days until I can get enough straight time to read both listings and figure out where and why it diverges. I wonder if we'll discover something weird about the hardware?

 

In the meantime, I will burn a ROM with the "good" image and test it on real hardware.

Edited September 12 by leaded solder

[leaded solder]

Got a chance to test it - as expected, this second ROM (ef707c8045afc26e3e4d09c03aba5de6) is working on my ADAM. I will investigate further as to exactly what is different between these two, but not for a little while.

 

Thank you again, Shawn!

[Shawn Merrick]

1 hour ago, leaded solder said:

Got a chance to test it - as expected, this second ROM (ef707c8045afc26e3e4d09c03aba5de6) is working on my ADAM.

I'm glad to hear this worked for you. I am not sure why there are bad dumps still available for download but I suspect that the ADAM community would rather have extra ROM dumps then risk losing forever any possible valid files. After all, ADAM was orphaned shortly after 1 year of production and there are some rarities that surface from time to time.  It is somewhat disappointing that a cartridge was manufactured by a third party using a bad dump that clearly had not been tested on real hardware! 

 

If there is anything else I can do to help just ask. I have been an ADAM owner and programmer since January 1985.

[leaded solder]

Ah - VERAULT asked me to check on real hardware, which is what started this whole thing  He was (rightfully so) afraid of a bad dump and didn't have a working ADAM setup on hand. I'll ping you if anything else comes up, especially if I get confused about what the divergence points made it do.

 

As for my own tester, I think I'll add a joystick testing feature (I'm working on a new stick and need to make sure I wired it right) and call it a day until I have some other suspicious failure.

Edited September 12 by leaded solder

[+nanochess]

6 hours ago, leaded solder said:

Thank you Shawn! I think you've cracked it. I was at VCF Midwest over the weekend, what a great party.

 

As I posted over on VCF just now, I had a chance to throw the two ROMs through vbindiff. This revealed that there were a small handful of differences (and not all off by one bit: there's one, for example, that goes from $08 to $0d, that's worrying). This is consistent with the theory that it's a bad dump.

 

It's a very strange pattern for a bad dump; I would have expected more bits to be bad. My active theory is that the EPROM on the original cartridge was bit-rotting to start with.

 

I threw both through z80dasm and compared the disassembled listings, and it does seem to affect some kind of constant getting written into the accumulator, but I haven't had a chance to figure out in context what this affects. This will probably have to wait a couple days until I can get enough straight time to read both listings and figure out where and why it diverges. I wonder if we'll discover something weird about the hardware?

 

In the meantime, I will burn a ROM with the "good" image and test it on real hardware.

It's a dump that could work with expansion RAM. I mean, instead of using a test cartrdge, it loaded from a disk or tape into RAM, then the $08-$09 values are valid.

 

However, for a cartridge the correct values are $0c-$0d

 

Got this data from page 53 of https://wiki.console5.com/tw/images/b/b5/Coleco_ADAM_Technical_Reference_Manual.pdf

 

[Shawn Merrick]

2 hours ago, nanochess said:

It's a dump that could work with expansion RAM. I mean, instead of using a test cartrdge, it loaded from a disk or tape into RAM, then the $08-$09 values are valid.

 

However, for a cartridge the correct values are $0c-$0d

 

Got this data from page 53 of https://wiki.console5.com/tw/images/b/b5/Coleco_ADAM_Technical_Reference_Manual.pdf

 

Thanks for that information.  I remember some of these Coleco in-house diagnostic programs first ending up in user hands as disk or tape versions.  These were of far less usefulness than the ROM cartridge versions since hardware experiencing faults may already be crippled beyond the ability to load from disk or tape. 😬 The primary requirement of the ROM version is just a working ColecoVision or game board. 🙂

Also, ADAM software in ROM format usually has significant file differences due to storage I/O versus memory bank I/O.  Thanks again for the tips!

[NIAD]

3 hours ago, nanochess said:

It's a dump that could work with expansion RAM. I mean, instead of using a test cartrdge, it loaded from a disk or tape into RAM, then the $08-$09 values are valid.

Yes, some of the Coleco In-House cartridge test utilities that were dumped and assembled in CP/M format might require a 64K Memory Expander to function correctly. It's been so long that I don't recall all the details and haven't given it much consideration since I was able to acquire most of these carts and make good rom dumps of them.

[leaded solder]

Yeah, I also believe it must be loaded from tape or disk into RAM and then run from there. I'm not sure what "SmartPack" was a marketing term for, but it makes me think about the Digital Data Packs, so it may well have been written to tape and distributed that way originally.

Thanks all! I'm glad to have worked this out in the end. I'll probably make a blog post and introduce my sketchy little RAM tester, but I don't plan on doing much more (other than maybe a joystick tester.)

 

I also made a video of the software running on my real hardware, if anyone is extremely bored. 

 

[NIAD]

10 hours ago, leaded solder said:

Yeah, I also believe it must be loaded from tape or disk into RAM and then run from there. I'm not sure what "SmartPack" was a marketing term for, but it makes me think about the Digital Data Packs, so it may well have been written to tape and distributed that way originally.

Yes, some of these Coleco utilities were dumped from cartridge and then assembled as EOS self-booting programs on data pack or disk as well as CP/M rom images and or executable COM files. Where issues arose later was with these versions in CP/M as some were taken off their disk or data pack collection and headers removed from the file. It's nice to have these software based versions, but then again if a system is experiencing issues, there is more of a chance that they can't be loaded compared to cartridge based.

 

The SmartPack series was supposed to be a series of utilities that Coleco planned to release... but obviously never did.