TI99-4 (Non A) - Hitting dead end on troubleshooting

[UsagiElectric]

Hi All,

 

I've been working on a TI-99/4 and it's giving me the proper run-around (picture attached of system in question).
It's a dead system, black screen and sound chip screaming. In my initial round of testing, I found two bad transistors in the video circuit (weird, but they definitely weren't amplifying) and a bad DRAM (all have now been replaced with 4164s modified). There is effectively no change in the failure mode.

 

There is data on the data bus, addresses on the address bus, none of the data or address lines look to be stuck low or high, all four clocks look good, voltages are not perfect but close (4.9V, -5.2V, 11.4V).  I have a spare 99/4 parts donor (it's a rusty nightmare, so no guarantee the parts are good) and a spare 99/4A parts donor (it was also a non-booting machine though), so I've been swapping chips from those machines to test stuff out. So far, I've confirmed the following:
- Swapped CPU for two different CPUs, all three behave the same (all three came from non-working systems though...)
- DRAM is good, though I think the failure happens before we even get that far (VDP never receives CSW or CSR)
- Swapped VDP for three different ones, all four behave the same (generates a video signal, but there's not data in it)
- Swapped console ROMs (both) for two different ones, all three pairs behave the same (one pair is from parts donor, the other pair are 28C64s in adapters)

- Swapped the GROMs (all) for the spare ones from the parts donor, same behavior

- Replaced the 74LS138s on the right edge of the board, no change (this was at the behest of the manual)

I'm starting to run low on things it could be. I've tried to follow the TI-99 new technician manual troubleshooting procedure, but it's not getting me there. I'm down to thinking it's either the SRAM chips or the the 16-bit to 8-bit conversion chips (LS245, LS373, LS244). I would kind of expect one line to be stuck high or low if it were the SRAM chips, though I suppose they could fail high impedance? Also thinking that maybe the board is just really picky on voltages? The 4.9V is well within spec, but the 11.4V is right on the bitter edge for the TMS9900. It could still be CPU as well, all three of the CPUs I have tried came out of non-working systems, but I feel like they shouldn't all fail in the exact same way. It could also still be the GROMs, but I'm not sure how to test those in such a way that it rules them out.

Of interesting note, if there's a cartridge in the slot, it stays in reset for about a full second longer than if there isn't one. Not sure if that's indicative of anything.

If y'all have any other ideas, I'm all ears!
 

[+acadiel]

I don’t know if this helps or not (it doesn’t answer your tech question), but here are some of the later tech reference documents I scanned for @matthew180 - see if these might help any:

 

this is the last TI technical manual for the /4A, but a super late 83 version:  https://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/TI994A_HC_Servicing_Manual_Oct_1983.pdf

 

Sams Computerfacts /4A:

https://ftp.whtech.com/datasheets and manuals/Hardware/computerfacts/Sams TI994A ComputerFacts.pdf

 

If you’ve swapped everything out, and are still getting the screeching sound chip, the very beginning of the system isn’t initializing and the sound chip isn’t getting one of the very first instructions to “shut up.”

 

From John Guion’s console repair guide:

 

A. TMS9900 CPU resets and addresses low ROM locations. 

 

B. TMS9900 initializes. 

 

C. TMS9900 sets up workspace registers in MCM6810 RAM. 

 

D. TMS9900 begins GROM read. 

 

E. TMS9900 enters delay loop for about 1/4 second. 

 

F. TMS9919 sound chip is disabled. 

 

G. TMS9918A VDP chip is initialized. 

 

H. 4116 VDP RAM is initialized(requires about 1 second). 

 

I. Title screen is loaded into VDP. 

 

J. TMS9919 sound chip emits beep. 

 

K. TMS9900 CPU enters keyboard scan. 

 

L. System is ready for use.

The only copy I could find is here:  https://ftp.whtech.com/articles/limanews/CONSOLE.TXT

 

Good luck!!!

[+Ksarul]

Note, here is the 99/4 technician's troubleshooting guide for the 99/4. It gives you the fault trees for just about every known failure mode. . .it is in two parts in the linked directory. Note--this one is specific to the 99/4 and very comprehensive, unlike some of the later ones for the /4A.

[UsagiElectric]

24 minutes ago, acadiel said:

I don’t know if this helps or not (it doesn’t answer your tech question), but here are some of the later tech reference documents I scanned for @matthew180 - see if these might help any:

this is the last TI technical manual for the /4A, but a super late 83 version:  https://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/TI994A_HC_Servicing_Manual_Oct_1983.pdf

Sams Computerfacts /4A:

https://ftp.whtech.com/datasheets and manuals/Hardware/computerfacts/Sams TI994A ComputerFacts.pdf

If you’ve swapped everything out, and are still getting the screeching sound chip, the very beginning of the system isn’t initializing and the sound chip isn’t getting one of the very first instructions to “shut up.”

From John Guion’s console repair guide:

The only copy I could find is here:  https://ftp.whtech.com/articles/limanews/CONSOLE.TXT

 

Good luck!!!

Thanks for the links!
I hadn't seen John Guion's guide before, I'll start with, maybe I'll have a bit better luck with that troubleshooting procedure!

[UsagiElectric]

3 minutes ago, Ksarul said:

Note, here is the 99/4 technician's troubleshooting guide for the 99/4. It gives you the fault trees for just about every known failure mode. . .it is in two parts in the linked directory. Note--this one is specific to the 99/4 and very comprehensive, unlike some of the later ones for the /4A.

This is the one I've been following actually.
I keep ending up at a dead end with the manual telling me to replace the LS138, but replacing it didn't change anything.
I'll keep plugging away at it!

[+acadiel]

1 hour ago, UsagiElectric said:

Thanks for the links!
I hadn't seen John Guion's guide before, I'll start with, maybe I'll have a bit better luck with that troubleshooting procedure!

John’s guide was extensively used by the Dallas TI group, which I used to belong to.  They had several members there who were very proficient with oscilloscopes and logic probes, and could follow John’s abbreviated guide with a schematic.  
 

Just adjust for any 99/4 peculiarities, there’s probably not too many differences, hopefully.  Your GROMs and ROM will be different on the /4 along with the 9918 vs the 9918A vs a /4A.  I think everything else is likely pretty close.

(@Ksarul likely can give you the part number differences.)

[Stuart]

The 6810 RAMs have been known to fail. My money is on one of them. They're pretty crucial from the very start.

Edited May 23, 2023 by Stuart

[Tursi]

Second the SRAM as my top candidate at this point. Without that, not much is going to execute since there will be no CPU registers.

 

Without the multiplexer, my gut feel is the system should get somewhere... the ROM and the RAM are both on the 16-bit bus, and so is the VDP. I've never tried though! You already did the 138, and that's the other chip I'd be suspicious of.

 

Also pull the sound chip for at least one test. The system doesn't need it to boot, but it is capable of holding the CPU. You might also take a look at the READY line on the CPU - it's kind of complex in the TI with circuits that gate it to various chips at appropriate times only (like the GROMs). Since you see address toggle it's probably not that, but doesn't hurt to check. (Likewise, the multiplexer can hold the CPU, but since you don't see it held, it doesn't feel that's it.)

 

As for the GROMs -- the only one you need in the system is GROM0. The other two are TI BASIC. Unfortunately, I don't have a 4 anymore to tell you which one is GROM0 - it'll be a different part number than the 99/4A version. (In the picture of my last 4, it looks like the GROMs are numbered CD2003, CD2004 and CD2006. I'd bet the 4 and 6 are TI BASIC, that matches the addresses they load at. 3 doesn't, but... it's TI.  )

 

 

Edited May 23, 2023 by Tursi

[Geoff Oltmans]

My bet would be on the SRAMs as well.

[+acadiel]

5 hours ago, Tursi said:

Also pull the sound chip for at least one test. The system doesn't need it to boot, but it is capable of holding the CPU. You might also take a look at the READY line on the CPU - it's kind of complex in the TI with circuits that gate it to various chips at appropriate times only (like the GROMs). Since you see address toggle it's probably not that, but doesn't hurt to check. (Likewise, the multiplexer can hold the CPU, but since you don't see it held, it doesn't feel that's it.)

 

Yep, I've seen shorted out sound chips before.  I'm glad they're socketed.  They will keep the system from powering up!  (John Guion's guide goes into that).

 

From Jim's list I found on here:

 

CD2003           /4 Console GROM 0+1501392-7

CD2004           /4 Console GROM 1+1501392-8

CD2005           /4 Console GROM 2

CD2155           /4A Console GROM 0

CD2156           /4A Console GROM 1

CD2157           /4A Console GROM 2

 

ROM part numbers from Mainbyte:

 

99/4:

1501392-7

1501392-8 

 

99/4A (and apparently QI?)

1501392-26

1501392-27

 

TI sure did like that 1501392 part number.

 

 

[UsagiElectric]

Thanks for all the ideas all!

 

Okay, a bit of an update.

I have a good working 4A, so in an effort to end up with no good working machines, I took it apart and socketed the CPU and one of the SRAMs on it so I could test chips. Thankfully, I didn't bork it and I was able to test some chips.

 

For the 4A, here's the current status.

 

Confirmed good:
CPU, VDP, SRAMs, DRAMs
Should be good, but not sure how to test:

GROM, SOUND, ROMs

 

I tested GROM 1 in the 4A, and of course it didn't boot, but it did initialize the VDP and get to a blue screen, which is further along than the same GROM in the 4 gets, so I'm fairly certain the GROM is alright. I have three different copies of 99/4 ROMs, two are pulls from original 4 motherboards (ROMs are socketed on the 4, so easy to pull), and one is a 28C64 on an adapter. Between the three copies, I would have expected one to work, but perhaps that's not the case? I suppose I could have two bad original ROMs and my adapter isn't correct, but triple failures is... uncommon.

 

That leaves just the CRU or some other logic fault. I checked the inputs to the LS138 that should be selecting VDP CSR and CSW, and the correct combination of 3-bit address and chip select pins just never happens, but none of the pins are stuck. I don't think a bad CRU can prevent a boot unless it shorts one of the A10 to A14 address pins to high or low, but those addresses aren't stuck as confirmed by the logic analyzer. Which would leave either a logic selection fault or a bad trace on the motherboard somewhere. It was a literal barn find, so that's not completely out of the question, but I'm not sure how to start hunting for that. I keep thinking tracing the VDP CSR and CSW backwards is a good idea, but that just dead ends me in the LS138 combo, which has activity coming into it, but the activity doesn't make sense.

 

The activity coming into the LS138 combo is from A0 ~ A5, A15, MEMIN, and DBIN. All except A15 come from the CPU which is tested good. A15 comes from... somewhere, the schematic isn't super clear on this one. Perhaps it has a typo or something because it looks like it comes from a junction of inputs, which can't be correct.

I may throw in the towel on this one for a bit and let the subconscious chew on it. I've been burning the candle at both ends trying to get this one solved and it's just whipping my butt, haha.

Cheers,

David

[HOME AUTOMATION]

From the /4A ...shows A15 generation ...somewhat...

[+Ksarul]

3 hours ago, acadiel said:

ROM part numbers from Mainbyte:

 

99/4:

1501392-7

1501392-8 

 

99/4A (and apparently QI?)

1501392-26

1501392-27

 

TI sure did like that 1501392 part number.

 

 

1501392 was the base number for the Mask ROM chip. The numbers following the dash identified the specific applied mask.

[Geoff Oltmans]

How long does it stay in reset at power on before coming out of reset?

 

[Geoff Oltmans]

Chip selects to the RAM, ROM strobing?

[Tursi]

A15 is the least significant bit, and it's generated by the multiplexer - the 9900 only has 15 adddress bits.

 

Pretty sure you can make it to boot without the CRU. There will be no interrupts so tones will play forever, and no keyboard, but it should at least init the system.

 

The 138 just splits the memory space into 8k regions.

 

0000-1FFF should select the ROM

2000-3FFF is not connected in the console (expansion RAM)

4000-5FFF is not connected in the console (DSR space)

6000-7FFF is connected to the cartridge port - but this may or may not be so in the 4, I don't know. The 4 doesn't support booting ROM carts but I assume it can read them...

8000-9FFF is split up among the memory mapped I/O - VDP, GROM, Speech (through the side port) as well as the internal SRAM from 8000 to 83FF. Obviously there is further decoding to split the space up, and each device gets two ports, 1k apart (one for reads and one for writes).

A000-FFFF (3 more lines) are not connected in the console (expansion RAM)

 

So as a start, I guess, you should be seeing the 138 select the first and fifth outputs as its coming up. It should be hitting both of them constantly as the ROM executes, the SRAM is used for registers and interpreter storage, and access to GROM for the actual boot process.

 

It might be educational to see if the GROMs are getting any accesses. The console ROM literally only sets a few RAM parameters and then starts interpreting GPL from the GROMs. Even muting the sound chip happens from GPL. Theirry has a page on GROM theory here: http://www.unige.ch/medecine/nouspikel/ti99/groms.htm

 

This is literally all the CPU code that is executed before it starts hitting the GROMs:

 

0000 83E0 (reset vector, load workspace of >83E0)
0002 0012 (reset vector, load program counter of >0012)
0012 020D LI R13,>9800  - will store "9800" at scratchpad RAM >83FA - 9800 is the access base for GROM hardware

0014 9800
0016 0200 LI R0,>0020 - will store "0020" at scratchpad RAM >8300 - will be used later as the GPL start address

0018 0020

001A 100C JMP >0034

0034 D11D MOVB *R13,R4 - read a byte from GROM and store it at scratchpad RAM >8308.

 

This is a short enough sequence that you might be able to capture it with your logic analyzer watching the data bus and a couple of logic/address lines. If you can confirm that much is happening, and that the GROM is actually being hit, that will go a long way. I included the data bytes there for that reason.

 

So by this point, there should have been 8 (16-bit pure) hits to the CPU, and one to the GROMs. And 5? to the scratchpad RAM. Remember it's 16-bit no waitstate so no multiplexer.

 

If the scratchpad SRAM is dead, then the MOVB opcode may happen, but it won't read from GROM. R13 will probably be 0000 or FFFF, and it'll read from there instead. If the address bus hits the right address but the GROM isn't selected, then you only have a couple of traces to follow over to the 138.

The actual byte read from GROM here will be random. GROMs need to be primed with a dummy read after powerup and that's all this is doing. It continues with this:

 

0036 C180 MOV R0,R6 - copy two bytes from >8300 to >830C

0038 1013 JMP >0060

0060 DB46 MOVB R6,@>0402(R13) - move the MSB of R6 (00) from >830C to R13+0x0402 (>9C02- GROM Address write) - this sets the first address byte. Remember all accesses are 16 bit, so there will be a read/modify/write sequence at the target.

0062 0402

0064 DB60 MOVB @>83ED,@>0402(R13) - move the LSB of R6 (20) from >830D to R13+0x0402 (>9C02- GROM Address write) - this sets the second address byte.

0066 83ED

0068 0402

 

So by this point we've got two more GROM accesses and 7 more CPU ROM reads. Maybe 7? more scratchpad accesses.

 

[quote]CD2005           /4 Console GROM 2[/quote]

Huh.. I guess that could be a 5 in my photo... it's not quite as sharp as I'd hoped when I took it. 

 

 

[UsagiElectric]

10 hours ago, Tursi said:

This is literally all the CPU code that is executed before it starts hitting the GROMs:

 

0000 83E0 (reset vector, load workspace of >83E0)
0002 0012 (reset vector, load program counter of >0012)
0012 020D LI R13,>9800  - will store "9800" at scratchpad RAM >83FA - 9800 is the access base for GROM hardware

0014 9800
0016 0200 LI R0,>0020 - will store "0020" at scratchpad RAM >8300 - will be used later as the GPL start address

0018 0020

001A 100C JMP >0034

0034 D11D MOVB *R13,R4 - read a byte from GROM and store it at scratchpad RAM >8308.

 

This is awesome information, thank you so much!

I hooked the Logic Analyzer up this morning (just to the Address bus for the moment) and tried to get a shot at startup. I had to add in some qualifiers for single shot because it only stores 1024 traces and it was getting all 0000 during reset. Also, it was seeing some minor activity for like 5 clock cycles before seeing 0000 again for more than 1000 clock cycles. So, in these shots, it ignores any address that is 0000.

 

But, the Addresses just don't make any sense to me.
It's entirely possible that I've got something setup wrong on the LA (A15 as the LSB and A0 as the MSB, 0V is 0, 5V is 1), but it seems like the adresses bus doesn't really share anything with what we should be seeing?

 

To avoid posting 1,000 pictures (since I don't have a HPIB interface) here's the first few address changes:

FEFF 0001 83FF 93FD 83FB 0003 0013 0015 83FB 0017 0019 83E1 001B 0035 83FB 9801 9800 9801 83E9 0037 83E1 83ED 0039

 

I can kind of see some logic in there with the 0001, 0003, 0013, 0015, 0017, 0019 count up showing up intermittently. And 9800 showed up for a *lot* of clock cycles. So that might be the machine trying to store it into scratchpad RAM?
I didn't get the data bus in on this one just yet because I have to go scrounging for enough clips. But, if it's looking like the address bus is making some sort of sense and we can maybe figuring out where we're losing the plot, I'll go on a treasure hunt to see if I can find enough clips to get the full 16-bit data bus as well.

 

Cheers,

David

 

 

[Tursi]

Couple of addressing errors in my description there -- all the registers are based on >83E0, but from habit my head based all but the first one on >8300.

 

Hmm. Try monitoring direct from the CPU if you aren't, and ditch A15. The ROM and RAM accesses won't trigger the multiplexer circuit, so may be causing confusion. (The GROM accesses will trigger it but anything else you see on A15 is spurious.)

 

The 9900 doesn't have a byte mode on the hardware side. Every access is always 16-bits wide, and the discrete circuitry turns it into two 8-bit accesses when needed.

 

It might be meaningless to try and decode those addresses, but... I can certainly align some of those bits to the expected accesses. You can gate on MEMEN so that you're only getting valid cycles. TI's chips tend to change state slowly, and I think some of what you're seeing in that capture is just the bits changing (for instance, from 0001 to 83FD - 83FD is an address we expect to see.

Like, a lot of it doesn't make sense, but 0001 does, 83FD does, 0003 does, 0013, 0015, 0017, 0019 all do, and they are in the correct order. So yeah, let's try and eliminate test setup.

 

Do you have the datasheets? Probably silly of me to ask, but I tend to overwhelm with information and hope you can pick what you need out of it.

 

9900_Microprocessor_Data_Manual_May76.pdf
bunyard-hardware-manual-for-the-texas-instruments-994a.pdf

[Tursi]

Maybe also useful... these are some captures I took years ago from a 4A of various memory cycles. I don't capture very many pins - my goal was just to see how long things took. But maybe it'll help.

 

https://docs.google.com/document/d/16seTZczVk_We9FNbwMp2q5hLOKgwkVJitHrRKoH4VAo/edit?usp=sharing

 

[Tursi]

One more, sorry.

 

"And 9800 showed up for a *lot* of clock cycles."

 

9800 is the GROM access - GROMs hold the system for 25-30 cycles every access by pulling READY low (I think low is the halt). The GROM chips themselves are /always/ low except during actual access, and there's TTL circuitry to map that to the CPU only during GROM access.

 

At any rate, that you saw that is promising.

 

[UsagiElectric]

1 hour ago, Tursi said:

One more, sorry.

 

At any rate, that you saw that is promising.

 

Okay, sounds like we're frighteningly close to a booting system!

Thanks for the links and the help!

 

I made some changes like you suggested and grabbed another Logic Analyzer shot.

A15 is now just connected to ground, so will always be 0. The Logic Analyzer is using the falling edge of MEMEN as the clock for latching in the address. I attached a photo, but here's the first few addresses I got.

(I think the FFFE, 0000, 0000 is just some junk it caught. The second time I ran it I got the exact same collection of addresses only without those three at the beginning, but I kept them listed just in case.)

 

FFFE 0000 0000 83FE 83FA 83FA 0002 0012 83FA 0016 83E0 001A 0034 83FA 9800

83E8 0036 83E0 83EC 0038 0060 83EC 83FA 0062 9C02 0064 0066 83EC 83FA 0068

9C02 006A 006C 0046 006E 837C 0070 0072 0076 0079 83FA DE00 83F2 007A 007C

83F2 83E8 83E8 0200 0202 0012 83FE 0204 83E0 03FE 0206 03F8 83F8 0208 83E0

83FE 020A 83E4 83E4 020C 83F4

 

We see the 9800 again of it trying to get to the GROMs. Then we see a bunch of 83xx, notably 83FA, but these should be something in the SRAM, right? There's a couple of 83Ex hits as well, which should specifically be the CPU registers in the SRAM, right?

I do find it interesting that we can see a clear count up from 0002, 0012, 0016, 001A ~ 0206, 208, 020A, 020C.
I feel like the problem is there in that code somewhere, I'm just not quite smart enough to find it yet. I got a lot of reading and absorbing of information to do!

 

Thank you again for all the help!

 

Cheers,

David

[+jedimatt42]

I believe FFFE is the address of the non-maskable interrupt vector, probably not always triggered on power up, not sure.

 

Then reset should occur, and 0000 should be read for setting the initial WS register. Which would set it to 83E0, address of R0.

 

Then the accesses to 83FE, a.k.a. R15, and 83FA, a.k.a. R13 is likely reset initialization, before the first instruction has been read. 

 

Then access to 0002 loads the PC with address 0012, the location of the first instruction. ... 

 

@Tursi, seems like he should be able to follow the disassembly from the classic99 4 emulation mode, but Sunday, I couldn't get it to breakpoint on these early accesses... 

[Tursi]

It should breakpoint if you use (0000-1fff) - I do that to catch any ROM access. But it won't breakpoint mid-exception... it'll have to get to the vector. ISTR the first instruction might not break either, but the second should. I'm using it too, just to see what the startup on the 4 looks like (but in my case I breakpointed for <G(0000-1fff) - ie: first GROM hit 

 

I just tested here and confirm, Classic99 will breakpoint at 0016. Still usable. 

 

Yeah, if the NMI is being hit it's probably just a glitch in the startup circuitry... though fascinating it can't override the reset anyway.

 

So let's see what you got... while it doesn't make perfect system, the system is operating and running GPL, almost certainly. That would seem to prove out the CPU, SRAM and GROM. This is what I make of the trace:

 

Spoiler

 

FFFE    garbage
0000    reset vector - fetch workspace address (should get 83E0)
0000    I'd expect to see 0002 here... maybe the reset is level based and triggered multiple times... (the NMI is)
    83FE    SRAM - This is register R15 on the new workspace - I wonder if reset loads R15/R14/R13 like other exceptions?
    83FA    SRAM - This is R13... since it's hit twice, I wonder if the address setup wasn't quite right yet. Sample on rising MEMEN?
    83FA    SRAM - R13 again... if it's loading the exception vector as theory above, we'd see R15/R14/R13. Assuming that.
0002    reset vector - fetch program counter (should get 0012)

0012    first instruction - LI R13,>9800 - loads base address of GROM into R13
    83FA    SRAM - access to R13, likely the store operation

0016    LI R0,>0020 - store GROM start address into R0
    83E0    SRAM - access to R0, as expected

001A    jmp >0034

0034    (as expected) MOVB *R13,R4 - dummy read from GROM using R13 as the address and store result in R4
    83FA    SRAM - get value of R13
    9800    GROM - read data from GROM (dummy data)
    83E8    SRAM - store into R4
    
0036    mov r0,r6 - prepare to load GROM address
    83E0    SRAM - read value of R0
    83EC    SRAM - store data in R6
    
0038    jmp >0060
 
0060    (as expected) This is the entry point to the GPL interpreter with address in R6. It takes 2 writes to load the address.
        movb r6,@>0402(R13) - >0402 is the offset from the GROM base to the GROM address register, so it's added to R13
    83EC    SRAM - read value of R6
    83FA    SRAM - read value of R13
    0062    ROM - read immediate value (0402)
    9C02    GROM - write GROM address
    
0064    movb @>83ed,@0402(r13) - this is to get the LSB of R6. TI was fond of treating addresses and registers 
                                 as equivalent to save one instruction... 
    0066    ROM - read symbolic address (83ED)
    83EC    SRAM - read requested data - R6 - remember since all memory accesses are 16-bit, we can't directly hit 83ED anyway
    83FA    SRAM - read value of R13
    0068    ROM - read immediate value (0402)
    9C02    GROM - write GROM address
    
006A    szcb @>0047,@>837C - clears a bit in memory used as the GPL status register
    006C    ROM - read symbolic address (0047)
    0046    ROM - read requested data (again, only even access is possible)
    006E    ROM - read symbolic address (837C)
    837C    SRAM - update the RAM - there should have been two hits here - a read and then a write
    
0070    limi 2 - enable VDP interrupts
0072    limi 0 - disable VDP interrupts - at this point we are in the GPL interpreter. Everything made sense, so pausing here.

 

 

 

At this point, TI Intern will help a bit - it has a full disassembly of the 99/4A GROMs. The bad news is that it's not the same as the 99/4 GROM, but the good news is there's also a lot that is the same, so it should help with things like the order of initialization and how many instructions it takes. Every time the CPU comes back around to >0070, a new GPL instruction is starting (it's fetched by >0078 - movb *R13,R9).

 

But like I say, CPU, ROM and SRAM must be working, or we wouldn't see that much. GROM is likely working too, since you see the long delays when it's accessed. According to TI Intern, the very first thing that happens in GPL is the clearing of the sound chip, so that's probably the easiest thing to focus on first.

 

0020 : BR GROM@>004F Power-up routine (branch instruction)
...
Power up routine
004F : DCLR @>83CE Clear sound bytes (SRAM write - software flag)
0052 : ST @>9400,>70 Load speech write (hardware write - SBE on side port toggles)
0057 : ST @>8400,>9F Set sound generators (four sound chip writes - this is to mute all four channels)
005B : ST @>8400,>BF
005F : ST @>8400,>DF
0063 : ST @>8400,>FF
0067 : DST @>8372,>FF7E Load data/substack (SRAM write)
006B : MOVE >0007 TO REG>01 FROM GROM@>044E Load VDP register (14 address writes to VDP)

 

Okay, speech is first.. you could check the speech enable pin on the side port to see if it toggles. But the four writes to the sound chip (>8400) might be easier to spot. The last line I pasted there writes 14 bytes to the VDP (in address mode) in order to load the VDP registers, which if nothing else should set the screen to cyan. After that, it clears scratchpad RAM (256 bytes at >8300) and sets the default CRU bits in the 9901. This should all be fairly similar in the 99/4... I don't know if we have a disassembly of it.
 

Frankly, if you can confirm those I/O devices being hit I'd be at a loss why it doesn't boot... so we want to see how far into that sequence it gets, or whether any of it hits the hardware. Unfortunately you can't track the GROM addresses, as they are internally managed (and auto increment!), so you'd need data bus sniffs to infer where in the GPL it is.

 

Edited May 24, 2023 by Tursi

[Tursi]

tiintern.pdf

[UsagiElectric]

Thank you so much again for all the disassembly!

 

Ok, let me see if I can follow along with what's happening here:

Hit reset vector

Setup working registers in SRAM

Get GROM base address and start address
Dummy read from GROM (why do a dummy read?)

Jump to entry point of GPL interpreter

Do some other magic stuff to finish loading GPL interpreter

 

Once the GPL interpreter is loaded, we can start reading from the GROMs and executing the instructions in them. And the first instructions that get run out of the GROM are:

Clear sound bytes

Load speech write

Set sound generators (which would shut the chip up)

 

But, since the chip isn't shutting up and it's making a wonderful screech noise, we're losing the plot somewhere before the "set sound generators" instructions. I've actually confirmed this by checking A3, A4 and A5 as well as the chip enables coming into the LS138 that decodes that into 8400 for writing to those sound generators on the sound chip. The address never hits, and it never gets written.

 

But, if we've successfully loaded the GPL interpreter and are into the GROM, there's not a whole lot that could go wrong.

"Clear sound bytes" is writing to the SRAM, which we know is working (partially because we made it this far and partially because I've confirmed the SRAM chips are good in a working 4A)
"Load speech write" is... I don't actually know what this is? Is it related to the CRU? I ask because it's at an address that the CRU could respond to I believe (based on what the address pins the CRU has as inputs)

 

If it is CRU related, could a bad CRU be causing our downfall here? It's the one chip I haven't touched yet on the machine, and it would be a hilariously twisted fate if the last big chip that I decided to skip is the one that's borked.

Having said that, I'm not entirely sure it is CRU related because the CRU seems to primarily look at the keyboard and cassette port. Speech seems to be a 9919 sound chip thing? And if the sound chip is bad, shouldn't removing it alleviate the problem and allow the system to boot? (Which I've tried to no avail.)

 

If it is looking like the CRU could be responsible, I'll desolder that bad boy and replace it with a salved piece from a 4A in a heartbeat though!

 

Thanks again for all the help!

 

Cheers,

David