TI-99/4A Console Tester

[Shift838]

I have successfully been able to reproduce the TI-99/4A Console Tester originally designed by Geoff Trott.  Luckily, I had a working one on loan from Dan Eicher, which was a good thing as I found a few errors in the released schematic compared to the real board.

 

I have verified this one functions exactly as the original one that Dan sent me.

 

I decided for the second go around for the prototype (had to fix a couple of things, well more than a couple!) to go with a complete through-hole design to make troubleshooting it and replacing any component that may fail later much easier.  It has increased the cost a few dollars to make but not enough to worry about.

 

These will be sold for around $50 +/- a few bucks assembled and tested.

 

I will be throwing up a preorder soon and will post it in the regular forum probably by the end of the weekend.  I want to go through testing it more just to make sure.  But so far I have run it for about 3 hours while running the original at the same time on another system.  Both performing the same exactly.

 

 

 

 

[JasonACT]

Is the DSR ROM and/or any extra software available anywhere?

[JasonACT]

Ok, there's no additional software, just the DSR ROM (it's not actually a DSR, it's high(est)-memory for the LOAD interrupt vector, and there's a note to remove any internal console 32KB RAM expansion before testing).  The device and its algorithm are fully described in the TIsHUG April 1987 newsletter.  I actually found that by searching here.  The circuit is pretty simple too, and can be made even cheaper by deleting the LOAD interrupt dual-flip-flop.  You would only need that if you were expecting to return to where you came from, and that's not what this device will ever do.  I didn't notice anything out of the ordinary with the schematic, but if there's a typo or two, it's still pretty clear how it works.

 

It's interesting he says the most common fault is the low-ROM chip failing, I wonder if that isn't because you can write to ROM and cause a bus conflict which eventually kills the chip(s).  In the same newsletter they have an article that says another common fault (for mid '83 consoles) is the choke on the power supply for the VDP crystal soaking up moisture.  That's the brown component next to the crystal, who knew?  Anyway, this device pretty much tests scratchpad RAM, VDP RAM, ROM checksums, GROM checksums (in a far too hard to read format) along with saying the VDP interrupt is tested but you'll only notice a problem if the tests stop.

 

I think I'll write a DSR ROM from scratch for my PicoPEB that implements his algorithm, but also checks which address lines are being made active (a dead address line has been a previous fault reported on the site here) along with a data lines test by the DSR running and the Pico checking.  That would be a more complete test suite I think.

 

It would still be interesting to see the ROM contents, but I don't expect any real surprises.

[+dhe]

@JasonACT - I'm glad you asked about the DSR! Would you be willing to lead a DSR dis-assembly effort so we could have not only the schematics, but we could look at the source and know exactly what it is doing?

 

Many many thanks to @Shift838 for reverse engineering this. Consoles are only going to get more buggy as time goes on and any kind of diagnostics that can be done before cracking the case is awesome!!

[JasonACT]

44 minutes ago, dhe said:

Would you be willing to lead a DSR dis-assembly effort so we could have not only the schematics, but we could look at the source and know exactly what it is doing?

I don't think that would take much effort, so sure, sounds like a good plan.

[Gary from OPA]

3 hours ago, JasonACT said:

Ok, there's no additional software, just the DSR ROM (it's not actually a DSR, it's high(est)-memory for the LOAD interrupt vector, and there's a note to remove any internal console 32KB RAM expansion before testing).  The device and its algorithm are fully described in the TIsHUG April 1987 newsletter.  I actually found that by searching here.  The circuit is pretty simple too, and can be made even cheaper by deleting the LOAD interrupt dual-flip-flop.  You would only need that if you were expecting to return to where you came from, and that's not what this device will ever do.  I didn't notice anything out of the ordinary with the schematic, but if there's a typo or two, it's still pretty clear how it works.

 

It's interesting he says the most common fault is the low-ROM chip failing, I wonder if that isn't because you can write to ROM and cause a bus conflict which eventually kills the chip(s).  In the same newsletter they have an article that says another common fault (for mid '83 consoles) is the choke on the power supply for the VDP crystal soaking up moisture.  That's the brown component next to the crystal, who knew?  Anyway, this device pretty much tests scratchpad RAM, VDP RAM, ROM checksums, GROM checksums (in a far too hard to read format) along with saying the VDP interrupt is tested but you'll only notice a problem if the tests stop.

 

I think I'll write a DSR ROM from scratch for my PicoPEB that implements his algorithm, but also checks which address lines are being made active (a dead address line has been a previous fault reported on the site here) along with a data lines test by the DSR running and the Pico checking.  That would be a more complete test suite I think.

 

It would still be interesting to see the ROM contents, but I don't expect any real surprises.

Good idea. But just remember it's not a DSR this is LOAD interrupt program that runs at the f000 space with ram like at the e000 space.

 

The whole idea of a console tester is for an external program that can runs when you press the button, because if the groms, scratchpad, console ROMs are fucked up you will never get to a boot up stage that a DSR or a CALL could be issued.

 

This console tester similar to TI official RAMtrap is designed to work independently of anything program wise in the 4a motherboard itself.

[Artoj]

Great work and team effort, saves me trying to build one from scratch, I did see Geoffs card in action at many meetings. I have 3 consoles that have many problems one works but has issues at times, too unreliable to use. I think my TI PEB Disk Controller card has issues as well, I would also suggest a side port card that tests the DSR/CRU.. etc of the PEB cards similar to the Console Tester but from the other direction, this would make trouble shooting a breeze.

[+dhe]

A super big thanks to @JasonACT for taking the binary and making very readable, well commented source code!

 

Awesome work!

 

 

TMS2764@DIP28.dis

[JasonACT]

Possible improvements I see with the code:

 

.It's not reading the VDP status register to reset the VDP address latch (this could be an issue) 

.It's not setting the VDP into 16KB mode before testing VRAM (this could report working memory when it's bad)

.It's not doing a dummy GROM read to reset the GROM address latch (this test repeats, so isn't a big deal)

 

If you see any errors on the first run, it would be best to press the LOAD button a 2nd time.