TI99/4 (non-A), Looking for checksum of main ROM.

[Ben Boldt]

I have a TI99/4 (non-A) that is not working.  I spotted this other thread here and I plan to go through it carefully:

 

 

When I got my TI-99, the power supply was bad.  This may have wiped a bunch of stuff out...  I have repaired the power supply with all new caps and it works properly now.  There may have been a bad diode or cracked trace too, I can't remember now.  Also, the system clock was not working.  It seemed that the crystal oscillator inside the TIM9904 couldn't excite the crystal, even when I replaced the crystal.  I built an oscillator circuit around my new crystal and kludged it in.  Not sure exactly what I all did but the TIM9904 does produce the 4 "high voltage" clock phases properly now.

 

But anyway, it has a known-good power supply and CPU clock at this time.  The TI99/4 still does not work though.  It screeches when you turn it on, so something isn't booting up enough to initialize the sound chip.  Finally I found the inspiration to come back to this and try to fix whatever else is still wrong with it.

 

I am used to 6502 and found that this is quite a bit different.  I started by wiring A0-A14 and D0-D15 out to some pin headers and hooked it up to a logic analyzer to get some clues.  I am aware of the backwards numbering of these signals.  I also found out that ROM should exist at locations $0000 - $1FFF, and the reset vectors for WSP and PC are stored at $0000, $0001.  Though it isn't exactly the first thing it does, the CPU does fetch from these locations.  Most notably, all of the fetches from $0000 to $1FFF were unstable, so this tells me that there is a problem accessing the ROM.

 

Next I looked at /ROMEN, and sure enough it was always high.  Looking with an analog probe, I found the signal came just a little bit lower when it should have been driving all the way low to enable the ROMs.  I found that U504 was broken; I replaced it with an ancient 74LS138 that I happened to have, and then /ROMEN worked properly after that.  However, it still screeches and the data bus still isn't stable when accessing ROM...  So next I figured that the ROMs were bad.

 

I removed the ROMs and dumped them with my ROM burner.  The closest chip my ROM burner supports was TMS2732, which has pins 18 and 21 swapped versus the TI99's 2532 pinout, so I made an adapter and dumped them.  They DID appear to dump correctly, which leads me to think that there is a bus conflict, i.e. something else trying to talk at the same time as the ROMs causing the data bus to be unstable.  I will continue by removing other chips and seeing if the ROMs can then speak their reset vectors when asked.

 

---

 

The reason I came here, what I need your help with:  I am not finding any TI99/4 (non-A) ROMs on the internet.  I would like to verify that my ROM dumps are good, but I have nothing to compare to.  Here are my checksums as computed by HxD:

 

Low ROM (U611)
CRC-16: 605E
MD-5: D6474438455419A5F172E792A881D8C4

 

Hi ROM (U610)
CRC-16: CFD5
MD-5: D4BEB51D6267270FC1E3917E076DFA55

 

Per the /4 dumps, similar but different compared to /4A stuff I have found:

 

Reset vectors:

WSP = $83E0

PC = $0012

 

Level 1 Interrupt:

WSP = $83C0

PC = $0A4C

 

Level 2 Interrupt:

WSP = $83C0

PC = $0A12

 

If anyone could verify this for me, I would appreciate it.  If you need/want the files let me know.

[Tursi]

I can't guarantee they are "correct", but they have operated in Classic99 for decades without any complaints:

 

CON4R0.ROMCON4G2.GRMCON4G1.GRMCON4G0.GRM

 

The GRMs are the three GROMs, the ROM is both ROMs together, interleaved so that they appear in memory they way they would to the CPU. In the real hardware, they are 16-bits wide, so one of the two ROMs is even bytes, and the other is odd. To do a proper comparison you'll need to split CON4R0.ROM.

[+arcadeshopper]

mame has the 4 roms and groms

 

[UsagiElectric]

3 hours ago, Ben Boldt said:

I am not finding any TI99/4 (non-A) ROMs on the internet. 

There's a nice little ZIP file here that has a full suite of ROMs and the console ROMs in there are good. I dumped my 99/4 ROMs and tested the hex against those and sure enough, they were identical.
https://www.retrostic.com/roms/mame/ti-99-4-home-computer-54278

Also attached my console ROMs here too for good measure! These are the ROMs as dumped on my homemade ROM reader. I had two TI-99/4 motherboards and both sets of console ROMs dumped identically and matched to the ROM files in the link above.

 

As far as checksums go, here's what HxD calculates:

High ROM
CRC-16: CFD5

MD5: D4BEB51D6267270FC1E3917E076DFA55

Low ROM
CRC-16: DA50

MD-5: 1BEC408D2D5CC964E66AB285BA4A7887

 

The High ROM looks to be the same as yours, but the Low ROM looks pretty dramatically different. I'd do a full data comparison between the two files to get an idea of what's going on. You could very well have a bad low-byte ROM. If you do, you can make an adapter from a modern EEPROM moderately easy with a little inventive wiring. I attached a picture of how to wire up a 28C64 EEPROM that should work, although it's best to double check. I wargamed the possibility of a bad ROM, but didn't ultimately end up needing this.

 

Let me know if there's anything else i can check on the system to help!

 

Cheers,

David

CR_C994_LOW.BIN CR_C994_HIGH.BIN

[+Ksarul]

Note also that if you need a fully compatible ROM set, @atrax27407 can also provide programmed TMS2532s for the ROM slots for a reasonable price.

[Ben Boldt]

Thanks for all the help!  I compared my low ROM and I found the following differences:

 

Address | Mine | 994_rom_lb.u611

 

200 e6 06
300 09 c9
500 c0 80
600 ee ce
700 c7 07
900 47 07
a00 42 f3
b00 c0 00
d00 4e 2e
e00 50 b8

 

All differences are at address $x00.  It is interesting, some bits are incorrect high, some incorrect low.  I dumped it again with turning down the speed on the ROM burner (TOP9000), and I still get the same result.  I am guessing that the ROM is broken.  I attached my files in case they are interesting to someone.  Anyway, I am seeing "mostly" $41E0 on the data bus when the CPU is accessing address $0000.  That would be a correct low byte and an incorrect high byte.

 

I also attached a scope shot when the CPU is accessing address $0000.  When Channel 2 (/ROMEN) goes low, it should have $83E0 decoded on the data bus.  I have a 1.4V logic threshold selected for TTL levels.  The low byte $E0 sort of works but I don't see anything like $83 on the high byte.  Neither of them look too good I guess.  I am going to put sockets in the motherboard and see if I can get some 2532 EPROMs.

 

ti99_roms_faulty.zip

[Tursi]

The TI is really noisy and there's a lot of circuitry to response times a bit slow. The CPU samples at the rising edge of MEMEN, so that's when it needs to be stable.

 

It's interesting that your ROM seems to be trending towards 0 instead of 1, but I don't really know the failure case of mask ROMs. Definitely worth getting a new one in there to be sure.

 

 

[Ben Boldt]

I did a little experiment, I swapped the high and low ROM chips in opposite places.  I got $7041 with them reversed, versus $41E0 originally.  Seeing the $41 as the high byte pretty much confirms that low ROM does work and there isn't something else jamming up the high byte of the data bus.

 

I was looking at your pinouts UsagiElectric, because I have a ton of 27C512 chips (same pinout), however, the longer chip would be bumping into the CPU and/or the other ROM if I tried soldering it directly that way.  I wanted to put sockets for both ROMs and I didn't want to run a bunch of wires, so I ordered a few 2732 EPROMs from China.  In a few weeks when they get here, I will erase, program, do the pin swap 18/21 and give them a try.  Then we can see what else that bad power supply may have wiped out.

[+Ksarul]

3 hours ago, Ben Boldt said:

I did a little experiment, I swapped the high and low ROM chips in opposite places.  I got $7041 with them reversed, versus $41E0 originally.  Seeing the $41 as the high byte pretty much confirms that low ROM does work and there isn't something else jamming up the high byte of the data bus.

 

I was looking at your pinouts UsagiElectric, because I have a ton of 27C512 chips (same pinout), however, the longer chip would be bumping into the CPU and/or the other ROM if I tried soldering it directly that way.  I wanted to put sockets for both ROMs and I didn't want to run a bunch of wires, so I ordered a few 2732 EPROMs from China.  In a few weeks when they get here, I will erase, program, do the pin swap 18/21 and give them a try.  Then we can see what else that bad power supply may have wiped out.

You can also get TMS2532s and 2732s from Unicorn Electronics for a not-too-brutal price. They are a US source that generally has original chips and ships fast too.

[Ben Boldt]

Sooo, at long last I have replaced the U610 and U611 ROM chips.  I got some 2732s from China and they were bad...  I could not fully program them.  Anyway, I just ended up replacing them with 2 AT49F040's.  I attached them with PLCC32 sockets and wires.  I do get the CPU reading location $0000 with $83E0 on the data bus.  Slightly noisy but not too bad.  So that part seems to be fixed now but the system still screeches and when I turn it on, so there is still something wrong.

 

In the TI99/4A manual, I noticed the "Items to check during debug" list.  Right away I found that the +READY pin of the CPU stays low.  In some cases, it goes high immediately at power on, then when the delayed reset signal goes high it makes the ready signal go low.  Always when /RESET is high, +READY stays constant low.  That sounds like a problem to me, though I have no idea how +READY works or what it is supposed to do.  The manual just says to check it, not what it means.  Could anyone offer a suggestion for this?

[Stuart]

READY indicates that the memory is ready to be read. READY can be held low for a couple of clock cycles if accessing a slow memory device. Try removing the TMS9919/SN94624 sound generator and see if it boots. It is one of the devices that controls the READY input to the processor, and it is socketed so is easy to remove. You might be lucky ...

[Ben Boldt]

Sorry, I was not probed up correctly.  I believe I was looking at WAIT instead of READY.  My READY signal actually appears to be working correctly.  I will keep poking at this and referring to UsagiElectric's thread and I will let you know any updates or peculiar things I find.

 

Also, the AT49F040 chips I used I know are WAY bigger than the original EPROMs, to almost silly proportions.  However, I wanted something that would fit in the space and be socketed and these seemed to be a reasonably good fit.  They are CMOS parts but V(IH) is reportedly 2.0V, so that tells me that they are TTL compatible hopefully.  I connected A12,13,14,15,16,17,18 all to +5V, and then programmed the ROM code to range $7F000 - $7FFFF on each chip.

 

I attached a photo of my rework.  Also you can see where I kludged a new oscillator into the TIM9904 system clock chip (something I mentioned earlier).  The TIM9904 could no longer oscillate a quartz crystal, even when I replaced the crystal with a new one.  The little board contains its own oscillator and outputs a digital signal that I believe that I just fed right into the TIM9904 after removing the loading caps, etc.  It seems to be generating those 4 clocks OK at least for now.

[atrax27407]

I salute your ingenuity! The fix is a relatively simple one, however. TI made the EVEN and ODD byte console ROMs (in both the 4 and 4/A) pin-compatible with their TMS2532 EPROMs. As a result, the EPROMs are direct "drop ins" for the ROMs. However, 2732 EPROMs do not work without an adapter so even were you able to program them, they wouldn't have worked. Remove the defective ROMs and solder in a 24-pin socket for each. Then, simply insert a programmed TMS2532. The repair is complete without any additional wiring or other extraordinary efforts.

[+Ksarul]

On 7/25/2023 at 8:33 PM, Ben Boldt said:

Also, the AT49F040 chips I used I know are WAY bigger than the original EPROMs, to almost silly proportions.  However, I wanted something that would fit in the space and be socketed and these seemed to be a reasonably good fit.  They are CMOS parts but V(IH) is reportedly 2.0V, so that tells me that they are TTL compatible hopefully.  I connected A12,13,14,15,16,17,18 all to +5V, and then programmed the ROM code to range $7F000 - $7FFFF on each chip.

The 49F040 works fine in a TI. There are about 500 UberGROM cartridge boards out there using them on the ROM side. . .I got a good sized bunch of them many years ago and the UberGROM was the perfect board to use them in. I'm actually at the point where I may need to hunt down some more to restock. . .