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.

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?

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.

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

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.