Just how fragile is the EXEC ROM?

[+intvsteve]

Lately been on a bit of a "FIX ALL THE THINGS!" kick, and recently restored a system that had a bad RA-3-9600 RAM chip and replaced the system's RF modulator to get a pretty nice system back up and running.  I traded this for a non-working system that was a bit scruffy (one controller cord was RIPPED from the controller!) as part of a deal that resulted in a restored-to-working-order Bally Astrocade.

 

Anyhow, while restoring the system that eventually was sent off as a 'thank you', I harvested the RAM from a bare 'sarcophagus' system that I got 20 years ago really cheap and dug out of its tomb in the garage.  That board was 'BSOD' but the RAM tested as good. (Thanks for that SRAM test program, @intvnut!)

 

With the trade-in system I received, the controller repair was just a mechanical job (the cord is 3" shorter now, and some bad traces on the controller matrix have been fixed).

 

But the system itself was also BSOD - with some occasional nice pastel colors, light blue, sometimes green, sometimes purple.  Once even a bunch of characters and other data appeared on the TV.  Systematically testing each chip, the most likely suspects all tested fine... SRAM, STIC, CPU, and the color chip.  Finally, it go to the point of … what the heck, check the EXEC.  Wouldn't you know, the RA-3-9502-11 that was in the system, when placed in my test bed, would not boot!

 

The fun part though, is that if you left everything powered on for a few minutes and then cycled power, it all worked, and the MTE-201 passes with flying colors!  If you let things cool down, the behavior repeats.

 

Since this reminded me of the other "dead" bare-bones mainboard-only system that just sacrificed its SRAM, I popped its corresponding part of the EXEC -- and saw very similar behavior!  This one also tested out as "good" after "warming up" a short time.

 

Putting a "known good" RO-3-9502-11 into the newly arrived system cures its ills, and it works!

 

All of this finally leads up to the question:

Are the EXEC chips more prone to failure than some of the others?  Based on the chip documentation, it seems this one in particular is critical for the boot process to work properly.  In my test cases, in which all the socketed chips are 'Known Good' and this particular one (the 'DUT') is bad, it usually manifests as a black screen, somewhat frequently as a screen showing only one color, occasionally changing from black to one solid color, and rarely as "garbled" (typically a bunch of GROM characters).

 

Not sure if this is useful to any other troubleshooters, or perhaps this is already on the list.

[intvnut]

If the IAB bus phase doesn't produce the right vector at reset, then the machine won't boot.  That's a nice single-point-of-failure right there.  IAB is supposed to return $1000 right after reset, and $1004 subsequently.  It only knows about reset thanks to ~MSYNC.  So, if its ~MSYNC pin is damaged...

 

Basically, if ~MSYNC is damaged and IAB causes the ROM to output the interrupt vector ($1004) rather than the reset vector ($1000), things are unlikely to go well from there, as the stack pointer isn't initialized, the RAM interrupt vector at $100/$101 isn't initialized... it'll send the CPU on a jump into some random location, most likely $FFFF.

 

Since ~MSYNC is a pin that's also exposed on the cartridge port, I suppose that's a likely candidate for ESD strikes and damage.

 

[+intvsteve]

All this poking around ended up a dead end.  Well, some of the EXEC ROM chips do seem a little wonky w.r.t. booting up, but they are inevitably working.  The console I was testing them in only worked the one time... I'd about given up when, before packing it up with a note about possible ~MSYNC signal issues, I accidentally found out more.  I was testing w/ a random cart, and with LTO Flash!.  With LTO Flash! connected you get more interesting behaviors because of its attempts to reset the system.

 

So I did what any 12-year-old would do and started wobbling the cart around in the port a little bit... Guess what! Yep... Dodgy cartridge port!  A little downward pressure and system boots up and tests just fine.  Did a little cleaning and checking of the springiness of the connections... Eventually, this system should get a new cartridge port and the left controller needs a good cleanup and it should be right as rain.  The right controller got a full buff what with its cord being ripped away and all...

 

Once again, the resilience of old electronics is pretty amazing.  Just like us, it's the mechanical parts that seem to break down soonest.

[HunterZero]

Speaking of the RA-3-9600... In my experience this is the most common failure, it would be really good to develop some sort of adapter PCB so that a modern RAM chip could be used as a replacement.

 

Similar for the EXEC PROM/SROM/GROM chip adapter boards, allowing replacement with newer flash EPROM. This would have the side effect of enabling things such as custom firmware and graphics mods.

 

- J

[intvnut]

What you really want, if you're going to do that, is a daughtercard that replaces the RA-3-9600 and has a socket for the STIC.  With that, you could easily add a 20x24 character mode, double vertical-res text, multi-color background tiles, 256 GRAM tiles, full access to all 512 tiles in FG/BG mode (at least for the background; MOBs would still be limited), etc.

 

With a little more elbow grease, you could also probably manage to do higher-vertical-res MOBs as well, just by curating the STIC's experience.  Imagine a max-height MOB (128 scanlines?) that actually had different bitmap data on each scanline?  That could be used to add a lot of detail to a scene when combined with higher-res BACKTAB.

 

At some point, though, you have to ask yourself:  Is it still Intellivision?  I mean... look at this "TI-99/4A" demo, which is really just showing off the 100MHZ TMS9900 clone + DMA engine inside the F18A FPGA.  At what point does it stop being an Intellivision and start being an Intellivision controller interface for something completely different?

 

(Skip to 2:30 for where it gets really ridiculous.)

 

 

Edited December 12, 2019 by intvnut
Add note to skip to 2:30 on the video.