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

[Tursi]

It's not CRU. You haven't even touched CRU yet. That's the 9901, and it's not initialized till after the sound chip is turned off. You can safely disregard it till the sound chip is shutting up - the only thing it could possibly interfere with at this point is if it was somehow corrupting the data bus. Sniffing the data bus wouldn't hurt - we could go through the same initial bytes process and probably confirm the data coming from the GROM as well. That said, we can be quite confident that the data from ROM and data from SRAM are both valid, so it doesn't seem like there's anything interfering.

 

"Dummy read from GROM (why do a dummy read?)" -> The GROM address is set by writing two bytes to the address port. But at powerup the internal flip-flop for first or second byte is set to an indeterminate state. Reading from the data port guarantees to reset the address flipflop.

 

"Do some other magic stuff to finish loading GPL interpreter" -> just setting the start address in the GROM. Then it's finished initializing and started execution. >0070->0072 enable and disable VDP interrupts briefly to let the console interrupt routine function if an interrupt is pending, and >0074 fetches a byte from the GROM to start interpreting.

 

So software-wise -- assuming we aren't getting garbage on the data bus -- things are humming along nicely. So I recommend we next focus on those first 5 init instructions.

 

So "load speech write" is just writing a byte to >9400, which is the dedicated address of the external speech synthesizer. Per http://www.unige.ch/medecine/nouspikel/ti99/pinouts.htm#Side - pin 2 should be the speech enable pin (SBE), and it should pulse high according to the page for that write. For the sake of this diagnosis, that's all that is expected (since there's no speech synth attached, it's just a blind write.) Then the four writes to the sound chip, of course.

 

"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."

 

It should be A0, A1 and A2 that come into the first LS138, but I'd start simpler and just look at the output bit. Should be pin 11 (Y4) for the >8xxx range. I've never poked into that decode, but the output of it probably goes straight to the chip enables anyway. The Bunyard book I sent above should have 4A schematics which will be close, and I'll attach the 4 schematics I have just in case you don't already have them. I don't know how accurate they are.Schematics ti99-4 (not a)-jan-1980.pdf (I can't believe it let me post the whole thing! Thanks AA!)

 

According to this, the primary address decode (A0-A2) should be U504 (see page 6). From there pin 11 is used to feed an enable along with A15 to the second LS138 (U505) to break the address down. The sound chip enable is fed from pin 14 (Y1), and SBE is driven by both pins 10 and 11 (Y4/Y5 - for read and write on separate addresses) through a NAND gate (U506). U506 also feeds one of the enable pins on that second LS138.

 

So... if I understand - we have not really proven that the GROM circuits are working 100% - are we getting valid data back from the GROMs? Maybe if we can sniff the first cycles of data in the way you captured address, we should be able to suss that out?

 

Assuming GROM is working, verifying SBE and the sound chip selection (pin 6 of the 9919 at U511) is the next step. Verify we get output pulses from U504 pin 11 first. Looking at U505 will be trickier since it includes A15 (requiring the multiplexer to work) as well as NAND gate U506. As a start I'd probably just ensure A15 is toggling without worrying too much about whether it's toggling at the right time (seems a fault would more likely leave it stalled), and check that U506 is working.

 

Incidentally, the 138 U505 also provides the VDP decode (pins 13 and 12), so this does feel like the right area to be looking.

 

The hardware side is not my forte, so take a lot of what I say here with a grain of salt.

 

 

[Tursi]

Interesting observation from looking at the 138 at U505 - it also generates the GROM select. This makes sense (pins 7 and 9 - Y6 and Y7). This line also gates the GROM Ready line I mentioned onto the CPU READY line via U506 again. The sound chip's READY doesn't have any gating at all, it just ties direct to the CPU... but if the sound chip was holding it, then nothing would execute, so that's probably okay. But I'm really wondering about U506, knowing that NAND gates dying is not uncommon on other machines. A lot could go wrong if that wasn't working - from parts not getting their selects to the GROMs not holding the bus long enough to respond.

 

[UsagiElectric]

“It's not CRU. You haven't even touched CRU yet.”

> Yeah, that's what I was thinking, and it doesn't appear to be wrecking the bus from catastrophic failure either, so I think we can safely eliminate that.

 

“Reading from the data port guarantees to reset the address flipflop.”

> Ah, that makes sense!

 

“So software-wise -- assuming we aren't getting garbage on the data bus -- things are humming along nicely.”

> I think the next step is definitely going to be for me to hunt down enough clips to sniff the address bus and the data bus simultaneously. Once I get caught up on video editing (or get sick of it), I’ll jog back out to the garage and give that a shot and see if that gives us a bit more insight.

 

“It should be A0, A1 and A2 that come into the first LS138, but I'd start simpler and just look at the output bit. Should be pin 11 (Y4) for the >8xxx range.”

> You’re right, I got my numbers mixed up, I’ve been staring at this thing too long, haha. I did probe the output pins of U505, the second LS138, and the 8xxx lines (14, 13, 12) never get hit. Which means either it’s a bad address coming in, or something never triggers the correct enables at the right timing.

 

“So... if I understand - we have not really proven that the GROM circuits are working 100% - are we getting valid data back from the GROMs?”

> I have two copies of 99/4 GROMs and I’ve tried both in the board and both react the same way. I also tried both in the working 4A, knowing they wouldn’t work, but hoping to see something different. And both get the machine as far as a cyan screen, so I’m guessing that up to that point the GROMs are indeed good. Now, we could still have a fault in some of the circuitry around the GROMs, or the GROMs themselves could be bad and the 4A was just able to push them a little further.

 

“Assuming GROM is working, verifying SBE and the sound chip selection (pin 6 of the 9919 at U511) is the next step.”

> I’ve actually confirmed this one, but not at the sound chip, rather at the LS138. Pin 6 of U511 is connected to pin 14 of U505 (the second LS138), and that pin never toggles. So, we aren’t getting that far.

 

“But I'm really wondering about U506, knowing that NAND gates dying is not uncommon on other machines.”

> I’m starting to get to the shotgun approach, lol. It’s actually faster for me to just desolder and socket an IC than it is to try and diagnose whether that IC is good, marginal or bad. (I can desolder, socket and replace an IC in about 20 minutes). So, I replaced U506 and U508 for good measure, but no change.

 

And speaking of the shotgun approach, we’re rapidly getting to a point where there aren’t any ICs involved in the boot process I haven’t swapped or replaced. I attached some pictures of the schematics with the ICs I’ve swapped highlighted on it.

 

U607 and U613 are involved in the generation of A15, which is toggling, but maybe not quite right? U603, U606 and U612 are all NAND gates and could potentially have gone awry. U614, U615 and U616 are the 16-bit to 8-bit conversion ICs, but that really feels like the wrong place to look since all the boot process is pure 16-bit life.

 

And… that’s about it? Except for passives maybe. We could have a bad decoupling cap somewhere that’s causing a chip to be unstable, but that seems like it’d be even harder to track down. I’ll jog back out and get a shot of the address bus and data bus (if I can find enough clips), and maybe that’ll give us a bit of insight into what the data bus is doing, or maybe it’ll highlight a chip that’s misbehaving which might point us in the right direction for hunting down a bad passive.

 

I feel like we’re so, so close to a working system!

 

Thanks again!

 

Cheers,

David

[Tursi]

Thanks for the extra data, I'll look at the schematics a little more closely tonight, but as an initial comment - you don't need to capture the entire address and data bus together. We already know the boot starts successfully, so if you can capture the data bus at the CPU and just 2 or 3 address bits (A14-A12, for instance), we know what data we SHOULD see and should be able to piece together where its executing.

 

[+FarmerPotato]

I've been following along with interest.. 

 

You've  proved that the ROM executes, but that GPL is not getting the right GROM data, or it would have toggled the 74LS138  pins for VDP/SOUND. 
 

( you did find the second 138 pin Y4, Y5 are  toggling, for GROM enable, right?)
 

one tiny suggestion: what about U615, the 74LS245 that gates GROM data up to the high byte data bus? EN toggles?
 

and this remark sticks with me: "the GROMs are poor line drivers, at best". (Bunyard, I think.) 

If anything is stuck causing contention on the data lines behind the 245,  GROM will not be able to drive output data. 

 

Maybe something else around  the GROMs? That pesky diode that pulls   Vsomething to -0.7 V, is that in the 99/4? 

 

[DanBoris]

If it helps any, I ran a trace of the boot process using the debugger on MAME/MESS. This is from a TI99/4 but I am not sure if there are different versions of the BIOS rom which might lead to it not being an exact match. 

ti994.zip

[DanBoris]

On 5/24/2023 at 2:54 PM, UsagiElectric said:

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

I tried matching the logic analyzer dump to the trace I did and some of it matches but then goes off the rails

 

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

 

0000: 83E0     ;Initial WP
0002: 0012  ;Reset vector        ;0002 

0012: li   R13,>9800               ;0012, 83FA
0016: li   R0,>0020                 ;0016, 83E0
001A: jmp  >0034                   ;001A
0034: movb *R13,R4               ;0034, 83FA, 9800, 83E8
0036: mov  R0,R6                   ;0036, 83E0 83EC
0038: jmp  >0060                   ;0038
0060: movb R6,@>0402(R13)  ;0060 83EC 83FA 0062 9C02
0064: movb @>83ed,@>0402(R13)    ;0064 0066 83EC 83FA 0068 9C02 
006A: szcb @>0047,@>837c     ;006A 006C 0046 006E 837C 
0070: limi >0002                      ;0070 0072

 

Up to this point everything looks good, but then the next address is 0076. If that was an opcode read it would be reading 0000 which is an illegal opcode. The next read is then 0079 which I assume can't be an opcode read since it's not an even address. I guess there could be a difference in the ROM.

0074: limi >0000
0078: movb *R13,R9

 

 

Here is get's back on track
007A: jlt  >0086            ;007A
007C: movb R9,R4         ;007C 83F2 83E8 83E8

 

then somehow we end up at 200. This is not an exact match, looks like the same code but different registers . 

0200: D7E0 83E7      movb @>83e7,*R15   ;0200 0202 0012 83FE
0204: 0263 4000      ori  R3,>4000             ;0204 83E0 03FE 0206 03F8 83F8
0208: D7C3           movb R3,*R15              ;0208 83E0 83FE

020A: D145           movb R5,R5                  ;020A 83E4 83E4
020C: 1303           jeq  >0214                   ;020C 83F4

[Tursi]

It's difficult to get a 100% rock solid trace off the TI bus, so it's not surprising that it's a little off. The address 0079 is impossible per the criteria given, for instance, because A15 was tied to ground. Likely there were some poor contacts or sampling noise, but it's too early not to chalk that up to sampling error. The data sniff will give some collaboration.

 

[HOME AUTOMATION]

10 hours ago, DanBoris said:

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

With a few minor changes, this makes a BIT more sense...

 

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 0074 0078 83FA 9800 83F2 007A 007C

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

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

 

I'm guessing 0200, is where the Interrupt Handler begins.

[DanBoris]

2 hours ago, HOME AUTOMATION said:

With a few minor changes, this makes a BIT more sense...

 

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 0074 0078 83FA 9800 83F2 007A 007C

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

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

 

I'm guessing 0200, is where the Interrupt Handler begins.

200 is not an interrupt handler in the version of the ROM I am running. In the logic analyzer dump I would also expect to see a read from the IRQ vector at 0004, although maybe this is something the logic analyzer missed. Does seem to be the most logical explanation of how it suddenly gets to 0200. 

[DanBoris]

I know limi set the interrupt mask register, but is 0070: limi >0002  enabling or disabling interrupts?

[HOME AUTOMATION]

1 hour ago, DanBoris said:

I know limi set the interrupt mask register, but is 0070: limi >0002  enabling or disabling interrupts?

Yes, it looks like the IRQ Handler is at A4C.
We do end up at 200, a few times during boot-up ...but always from jumps to 01F8, ...C ...E.

So, yes ...how did we get here at this juncture?

LIMI 2 (ON)
LIMI 0 (OFF)

[UsagiElectric]

Hey all!
Just a heads up, I got delayed a bit because our idiot of a cat stepped on a rattlesnake and got bit twice in the leg. Been a fun two days, but she's back home now and recovering!

Planning on getting out tomorrow morning to grab a Logic Analyzer shot of the data bus and address bus.

 

Thanks again for all the help y'all!

 

Cheers,

David

[+OLD CS1]

43 minutes ago, UsagiElectric said:

cat stepped on a rattlesnake and got bit twice in the leg

Lucky cat.  Only eight lives left, kitty.

[Stuart]

With talk about the interrupt handler, time to replace the TMS9901 in case it is producing spurious interrupts?

[JasonACT]

I was gifted a very nice printer (PIO interface) because it no longer worked, turned out being a 1 of 4 NAND gate gone bad (not that hard to detect with what I had at the time, a rubbish analog multimeter, far less sophisticated than the one I use today).  I replaced the 74LS00 chip and.......  My year 12 teacher requested I return it, now it was working (1989).  He arranged some payment well above what I thought the effort was that I put in.

 

Amazing a single logic gate made the thing useless.

[UsagiElectric]

Alright, back in the saddle again!

 

On 5/25/2023 at 5:52 PM, FarmerPotato said:

Maybe something else around  the GROMs? That pesky diode that pulls   Vsomething to -0.7 V, is that in the 99/4? 

FarmerPotato, I think you may be right in that something around the GROMs isn't quite right. I did check the VSS pin on the GROMs that is pulled to -0.7V by the diode, and they're actually right on -0.7V, so hopefully that's good to go.

The 245 might also be another thing to look into. I actually tried the piggy back method on the 245, thinking that if it were weak, a piggybacked chip might jump start it enough, but no luck.

 

On 5/26/2023 at 5:41 AM, DanBoris said:

If it helps any, I ran a trace of the boot process using the debugger on MAME/MESS. This is from a TI99/4 but I am not sure if there are different versions of the BIOS rom which might lead to it not being an exact match. 

Dan this is awesome work, thank you! I think once we get a bit more information on what the address and data bus is doing, we can start closely comparing to this boot process and find discrepancies.

 

1 hour ago, JasonACT said:

Amazing a single logic gate made the thing useless.

Oh yeah, the trick is finding that single logic gate! The old 99/4 here is giving us a proper run-around!

 

12 hours ago, OLD CS1 said:

Lucky cat.  Only eight lives left, kitty.

She's doing immensely better today, even starting to put weight on the leg again. She'll be right as rain in a few weeks thankfully!

 

[UsagiElectric]

20 hours ago, Tursi said:

The data sniff will give some collaboration.

It's data sniff time!

I got the Logic Analyzer hooked up and managed to have enough clips for the full data bus and full address bus. A15 is still tied to GND and we're triggering on the falling edge of MEMEN, but it looks like it's making sense. Here's the transcribed data updated with your notes from the previous disassembly.

 

ADDR DATA
FFFE FFFF - Junk
0000 0000 - Reset
0000 0000 - Reset
83FE F73A - SRAM access, setting up workspace registers?
83FA F73A - SRAM access, setting up workspace registers?
83FA 34EE - SRAM access, setting up workspace registers?
0002 34EE - Reset vector, fetch program counter (should get 0012)
0012 34EE - LI R13,>9800, first instruction
83FA 34EE - SRAM access to R13
0016 9800 - LI R0,>0020, store GROM start address of 9800 into R0
83E0 9800 - SRAM access to R0
001A 0018 - jmp >0034, jump to 0034
0034 0018 - MOVB *R13,R4, dummy read from GROM to get to known state
83FA 0018 - SRAM access to R13
9800 0020 - Read data from GROM (dummy)
83E8 5000 - SRAM acces to store to R4
0036 50F4 - mov r0,r6, prepare to load GROM address
83E0 00F4 - SRAM access, read value of R0
83EC 0020 - SRAM access, store data in R6
0038 0026 - jmp >0060, jump to 0060
0060 0026 - movb r6,@>0402(R13), entry point to GPL interpreter
83EC 08F0 - SRAM access, read value of R6
83FA 08F0 - SRAM access, read value of R13
0062 9800 - ROM access, read immediate value (0402)
9C02 0020 - GROM access, write GROM address
0064 0000 - movb @>83ed,@0402(r13), get the LSB of R6
0066 0000 - ROM read symbolic address (83ED)
83EC 0000 - SRAM access, read requested data - R6
83FA 0000 - SRAM access, read value of R13
0068 9800 - ROM read immediate value (0402)
9C02 2000 - GROM write GROM address
006A 2000 - szcb @>0047,@>837C, clear a bit in memory for GPL status
006C 0000 - ROM read symbolic address (0047)
0046 0000 - ROM read requested data
006E 0000 - ROM read symbolic address (837C)
937C 20D1 - SRAM access, update the RAM
0070 01F0 -
0072 01F0
0074 01F0
0076 01F0
0078 01F0
83FA 01F0
D800 21F0
83F2 4000
007A 40F0
007C 40F0
83F2 00F0
83E8 40F0

 

It looks to me like everything is humming along smoothly right up to 0064 0000. The data bus seems to really go off the rails from that point on. So, maybe that's indicative that the GROMs aren't successfully asserting the data bus? Maybe the buffer is dead or perhaps the GROM enable pins aren't hitting at the right time?

 

GROM enable looks like it comes from the DBIN pin of the CPU through U602, an inverter (probably an LS04). GRMCLK comes directly from the VDP which is a known good IC, but I haven't confirmed the traces between the two are good yet. I'm not quite sure I understand how Q500, the NPN transistor on the pull down resistor network next to the GROMs, is supposed to work. But I suppose it could be having an issue causing GROM data to look broken?

 

If it is indeed a problem of the GROMs not asserting data to the data bus, there isn't that much in that area that can be wrong, so it might help really narrow down the fault.

 

Cheers,

David

 

[Tursi]

I still think you should sample the rising edge of MEMEN - the falling edge is the beginning of the cycle and the CPU won't read till the rising edge. I've seen random bits on the bus during the setup time before, short as it is! (Or am I remembering wrong and MEMEN is active high? Sample at the end of the cycle.) I think some of the things we're seeing may be caused by this - cause as listed they'd just crash the system, and it operates correctly for at least those first few.

 

For instance, the reset vector contains >83E0, >0012 -- we don't seem to see those reads for some reason. We see their results, so they must be happening. Further support for the above theory - sampling too early.

 

ADDR DATA
FFFE FFFF - Junk
0000 0000 - Reset >> expected to see data 83E0
0000 0000 - Reset >> expected to see data 83E0
83FE F73A - SRAM access, setting up workspace registers? >> top of WP (83E0), so that previous read must have worked!
83FA F73A - SRAM access, setting up workspace registers? >> expected to see address 83FC and any different data
83FA 34EE - SRAM access, setting up workspace registers?
0002 34EE - Reset vector, fetch program counter (should get 0012) >> expected to see data 0012 - it must work cause we jump there
0012 34EE - LI R13,>9800, first instruction >> data should be 020D
83FA 34EE - SRAM access to R13 >> data should be 9800
0016 9800 - LI R0,>0020, store GROM start address of 9800 into R0 >> data should be 0200, but it's the 9800 from previous..

 

Yeah, resample please. We're pretty close, but I don't want to chase ghosts. (Well, I do, but that's outside the TI hobby )

 

As for the GROM circuits, there is a bit in the "Bunyard" book that I posted above. That's written by an ex TI employee. Theirry Nouspikel has a rundown on how the GROM chips work, but oddly it doesn't look like he covered the interface circuit: http://www.unige.ch/medecine/nouspikel/ti99/groms.htm

 

That said, broken GROM drivers could very well be the candidate, since we have more or less proven a lot of the circuitry up until they take over. Also double check the READY line gets held for 20-30 CPU cycles during a GROM access - if the READY circuit isn't working the GROMs aren't fast enough to provide meaningful data. But I think we can reasonably infer that from the data. (However, if you want to hit the circuit first, don't mind me! )

 

[UsagiElectric]

Okay, resampling on the rising edge changes things a lot!

To the point where it's hard to connect to the previous data sniff, almost like there's more instructions happening here or maybe we're catching more?

As for access to 9800, I checked sampling on phi2, and it looks like it hits 9800 for around 27 clock cycles, which seems to be right on the money. So, our READY line getting held should be alright.

 

ADDR DATA
FE00 0000 - Junk
0000 83E0 - Reset?
83FE 0000 - SRAM access, setting up workspace registers?
83FC F57A - SRAM access, setting up workspace registers?
83FA 74EE - SRAM access, setting up workspace registers?
0002 0012 - Reset vector, fetch program counter (should get 0012)
0012 020D - LI R13,>9800, first instruction
0014 9800 - ?
0016 0200 - ?
0018 0200 - ?
001A 100C - ?
0034 D11D - ?
83FA 9800 - SRAM access to R0
9800 4A00
83E8 08F4
0036 C180
83E0 0020
83EC 08F0
0038 1013
0060 DB46
83EC 0020
83FA 9800
0062 0402
9C02 0000
0064 DB60
0066 83ED
83EC 0020
83FA 9800
0068 0402
9C02 0000
006A 5820
006C 0047
0046 D120
006E 837C
837C 21F0
0070 0300
0072 0002
0074 0300
0076 0000
0078 D25D
83FA 9800
9800 4000
83F2 00F0
007A 1105
007C D109
83F2 40F0
83E8 4AF4
007E 09C4
83E8 40F4
83E8 0004
0200 83E0
0202 0012
0012 020D
83FE 0000
0204 83C0
83E0 0020
03FE 0000
0206 0A4C
83F8 01F0
93F8 1F00
0208 83C0
83E0 0020
83FE 0000

 

[+mizapf]

28 minutes ago, UsagiElectric said:

Okay, resampling on the rising edge changes things a lot!

To the point where it's hard to connect to the previous data sniff, almost like there's more instructions happening here or maybe we're catching more?

As for access to 9800, I checked sampling on phi2, and it looks like it hits 9800 for around 27 clock cycles, which seems to be right on the money. So, our READY line getting held should be alright.

 

ADDR DATA
FE00 0000 - Junk
0000 83E0 - Reset?
83FE 0000 - SRAM access, setting up workspace registers?
83FC F57A - SRAM access, setting up workspace registers?
83FA 74EE - SRAM access, setting up workspace registers?
0002 0012 - Reset vector, fetch program counter (should get 0012)
0012 020D - LI R13,>9800, first instruction
0014 9800 - ?
0016 0200 - ?
0018 0200 - ?
001A 100C - ?
0034 D11D - ?
83FA 9800 - SRAM access to R0

 

 

 

Have a look at https://ftp.whtech.com/datasheets and manuals/Datasheets - TI/9900-FamilySystemsDesign-1stEdition/9900-FamilySystemsDesign-04-Hardware Design.pdf

pages 4-103 ff.

 

The RESET operation in the CPU is a context switch; for the 9900 this means that the current status register, the current program counter, and the current workspace pointer are saved to the new registers R15 (83FE), R14 (83FC), and R13 (83FA).

 

This can be nicely seen in the referred table. AB = Address bus, DB = data bus, NC = no change etc. See page 4-90 for the other abbreviations.

 

[DanBoris]

1 hour ago, UsagiElectric said:

Okay, resampling on the rising edge changes things a lot!

To the point where it's hard to connect to the previous data sniff, almost like there's more instructions happening here or maybe we're catching more?

As for access to 9800, I checked sampling on phi2, and it looks like it hits 9800 for around 27 clock cycles, which seems to be right on the money. So, our READY line getting held should be alright.

 

ADDR DATA
FE00 0000 - Junk
0000 83E0 - Reset?
83FE 0000 - SRAM access, setting up workspace registers?
83FC F57A - SRAM access, setting up workspace registers?
83FA 74EE - SRAM access, setting up workspace registers?
0002 0012 - Reset vector, fetch program counter (should get 0012)
0012 020D - LI R13,>9800, first instruction
0014 9800 - ?
0016 0200 - ?
0018 0200 - ?
001A 100C - ?
0034 D11D - ?
83FA 9800 - SRAM access to R0
9800 4A00
83E8 08F4
0036 C180
83E0 0020
83EC 08F0
0038 1013
0060 DB46
83EC 0020
83FA 9800
0062 0402
9C02 0000
0064 DB60
0066 83ED
83EC 0020
83FA 9800
0068 0402
9C02 0000
006A 5820
006C 0047
0046 D120
006E 837C
837C 21F0
0070 0300
0072 0002
0074 0300
0076 0000
0078 D25D
83FA 9800
9800 4000
83F2 00F0
007A 1105
007C D109
83F2 40F0
83E8 4AF4
007E 09C4
83E8 40F4
83E8 0004
0200 83E0
0202 0012
0012 020D
83FE 0000
0204 83C0
83E0 0020
03FE 0000
0206 0A4C
83F8 01F0
93F8 1F00
0208 83C0
83E0 0020
83FE 0000

 

0200 83E0
0202 0012
0204 83C0
0206 0A4C
0208 83C0

If I assume these values are reads, that is not what is at location 200-208 in the ROMS I am using, but this is exactly what is at addresses 0000-0008

[Tursi]

It looks like we are missing writes, and only have the read cycles. Knowing that, we can make sense of this. Almost all instructions do a read-before-write (LI does not), so we can see those in this capture.

 

ADDR DATA
FE00 0000 - Junk
0000 83E0 - Reset - read Workspace pointer
    83FE 0000 - SRAM access, save status register (not sure if the data is valid)
    83FC F57A - SRAM access, save program counter
    83FA 74EE - SRAM access, save workspace pointer
    0002 0012 - Reset vector, fetch program counter

0012 020D - LI R13,>9800, save address of GROM port
    0014 9800 - fetch immediate data 9800 (seem to be missing the write to SRAM)

0016 0200 - LI R0,>0020, save starting GPL address
    0018 0020 - fetch immediate data, should be 0020 (transcription error, screenshot shows it is correct)

001A 100C - JMP >0034 (0C is the offset in words)

0034 D11D - MOVB *R13,R4, dummy GROM read to reset address flip flop
    83FA 9800 - SRAM read from R13 to get GROM port (9800)
    9800 4A00 - GROM read - value 4A is random (but amusing ;) )
    83E8 08F4 - SRAM access to R4 (there should be both a read and a write - are we filtering writes? Maybe MEMEN didn't toggle.)
    
0036 C180 - MOV R0,R6, prepare to work on GPL address
    83E0 0020 - SRAM read of R0, got 0020
    83EC 08F0 - SRAM read of R6, again, we are missing the write
    
0038 1013 - JMP >0060

0060 DB46 - movb r6,@>0402(R13) - write the first byte of the address to the GROM
    83EC 0020 - read R6, we get 0020 as expected
    83FA 9800 - read R13, we get 9800 as expected
    0062 0402 - read immedate data, we get 0402 as expected
    9C02 0000 - probably read-before-write to 9C02 for grom address, but that shows the previous worked
    
0064 DB60 - movb @>83ed,@>0402(r13) - write the second byte from the assumed address of the R6 LSB
    0066 83ED - read immediate data 83ED
    83EC 0020 - read the value from 83EC (because we can't read 83ED as a byte address)
    83FA 9800 - read R13, get expected 9800
    0068 0402 - read immediate 0402
    9C02 0000 - RBW of 9C02 for grom address
    
006A 5820 - szcb @>0047,@>837C - clear a (or some) bits in 837C, used by GPL as a status register
    006C 0047 - read immediate data 0047
    0046 D120 - read word at 0046 (cause we can't read the byte address 0047)
    006E 837C - read immediate address 837C
    837C 21F0 - RBW to 837C
    
0070 0300 - LIMI >0002  (enable interrupts)
    0072 0002 - read immediate data 0002

0074 0300 - LIMI >0000  (disable interrupts)
    0076 0000 - read immediate data 0000
    
0078 D25D - movb *r13,R9 - read a GPL instruction byte into R9
    83FA 9800 - get address from R13 (9800)
    9800 4000 - read byte from GROM - >40 - this matches my GROM - BR 
    83F2 00F0 - RBW on R9
    
007A 1105 - jlt >0086 - starting instruction decode. >40 is not less than 0, so no branch

007C D109 - movb r9,R4 - prepare to work on the instruction byte
    83F2 40F0 - read from R9 - got expected >40 (lsb unimportant, but matches the RBW above)
    83E8 4AF4 - rbw on R4
    
007E 09C4 - srl r4,12 - isolate the top nibble
    83E8 40F4 - read R4
    83E8 0004 - rbw on R4 (or maybe the actual write? it's the correct value)
    
0200 83E0... Something went wrong here. There's no branch. We should be at >0080, and the value there is >C164
0202 0012
0012 020D... what's fascinating is that these three accesses look like the reset sequence, including jumping to 0012,
             but without the writes to R13/R14/R15. Also, of course, the >0200 address doesn't make sense. The subsequent
             accesses also do not match the startup.
             If I were to decode these bytes, it is C @>0012,R15, which the CPU is clearly executing.
0200 83E0
    0202 0012
    0012 020D
    83FE 0000
0204 83C0
    83E0 0020
    03FE 0000
0206 0A4C
    83F8 01F0
    93F8 1F00
0208 83C0
    83E0 0020
    83FE 0000

    
We definitely go off the rails there. It's interesting that we died at address >0080, and your sniffer picked it up as >0200. Furthermore, the reads from >0200 through >0208 match the data at >0000.

 

You show that you replaced the ROMs, so it must be the logic? 

 

We have not executed any instructions yet that require the >0080 bit to be correct. If it were messed up, the scratchpad accesses would be at the wrong address, but no conflicts have yet happened so it would appear to work.

 

I think the next step is to carefully check all paths on the >0080 and the >0200 address bits. I'm not 100% sure how to do that, but definitely check for shorts and check any of the logic that deals with them as best you can. What happened there is very "sus".

 

For what is good... we only have a sample of 1 byte from the GROM, BUT, it's the correct byte which suggests that the GROM address writes worked and that the data bus from GROM to CPU is okay.

It's like, we have confirmed that the 8 least significant address bits work (or 7 from the CPU), but the next bit is uncertain.

 

Edited May 27, 2023 by Tursi

[UsagiElectric]

Oh man, this is amazing, thank you so much Tursi!

The 0080 and 0200 lines (or 0280) are surprisingly sparse, which should make checking them relatively easily. Looking at the schematic, it seems that they just got to the ROMs, SRAM and some LS367 driver chips for the I/O port.

It could be something as simple as a broken connection between the CPU and the SRAM (but not the ROM), or maybe one of the LS367s has an internal failure and is affecting the chip in someway.

 

Other than that, there's nothing else really on those lines, and honestly, a broken trace between the CPU and SRAM but not the ROM actually makes the most sense given how that all the other ICs have been replaced.

 

Tomorrow morning, I'll film a new intro and a bit to get us up to this point, and then I'll do some diagnosis on the bus connections and hopefully we can get this thing up and going!

 

@Tursi just to double check, would it be alright to show your disassembly and mention all the work and help you've done on the video?

 

Cheers,

David

[+OLD CS1]

ITT: Quality.