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

[DanBoris]

See next post...

Edited May 28, 2023 by DanBoris

[DanBoris]

3 hours ago, Tursi said:

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.

 

Looking at the reads starting at 200, it is definitely executing the data at 0000 as if it was opcodes. 

[DanBoris]

Could it be that the 0080 bit and 0200 bit are reversed on the logic analyzer? If they were, then you would see this behavior if the 0080 signal is not making it to the ROM.

[HOME AUTOMATION]

...You say ...you've done this before.

[JasonACT]

10 hours ago, Tursi said:

(there should be both a read and a write - are we filtering writes? Maybe MEMEN didn't toggle.)

https://www.unige.ch/medecine/nouspikel/ti99/wait.htm

 

Quote

Solving the Acquire-after-write problem

It took me weeks to figure that one out! But I finally got it: you may remember from the introduction that, after a write cycle, Memen* stays low for the next instruction acquisition (read) cycle. This means that the 74LS194 is not reset after a write! With the original TI design it didn't matter because the 74LS194 counts up to six anyhow. Its last state is L L H, so shifting once more gives L L L, which is the same as a reset.

 

[UsagiElectric]

On 5/27/2023 at 3:21 PM, Tursi said:

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

Okay, so, found the problem with >0080, I had a bent pin on one of the SRAM chips. Easy fix, but did not fix the boot issue, just made it... different.

 

Here's the new data, there are a few minor changes throughout that I'm still trying to understand. Lines with different data are noted by a "**".

 

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 0000 - GROM read - (In this instance the random value was 0000)
    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
**  817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)
    
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 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4)
    
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)

** From here on out, it's quite different, but still looks like RESET

0000 83E0
0002 0012
0012 020D
83FE 0000
0004 83C0
83E0 0020
83FE 0000
0006 0A4C
83F8 01F0
83F8 1F00
0008 83C0
83E0 0020
83FE 0000
000A 0A12
83E4 01F1
83E4 03E2

 

The lines that are different are:

**  9800 0000 - GROM read

>> I think this one reads random data, and in this case, the data was randomly 0000. This is of no real consequence.

 

     006E 837C - read immediate address 837C
**  817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)

>> This one is interesting. An immediate read of 837C is returning 817C? But, execution after this seems to chug along just fine, so maybe this one is alright?

 

    83F2 40F0 - read from R9 - got expected >40 (lsb unimportant, but matches the RBW above)
** 83E8 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4)

>> This one was originally 83E8 4AF4, which didn't raise any red flags on the previous disassembly, but now it's 00F4, which is quite different. A change from 4A to 00 is big and indicative of more than one line...

 

Then we get into what looks like reset and it's all chaos from there.

 

I'm not sure if this answers questions or creates more questions, haha.

 

Cheers,

David

 

[DanBoris]

1 hour ago, UsagiElectric said:

Okay, so, found the problem with >0080, I had a bent pin on one of the SRAM chips. Easy fix, but did not fix the boot issue, just made it... different.

 

Here's the new data, there are a few minor changes throughout that I'm still trying to understand. Lines with different data are noted by a "**".

 

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 0000 - GROM read - (In this instance the random value was 0000)
    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
**  817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)
    
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 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4)
    
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)

** From here on out, it's quite different, but still looks like RESET

0000 83E0
0002 0012
0012 020D
83FE 0000
0004 83C0
83E0 0020
83FE 0000
0006 0A4C
83F8 01F0
83F8 1F00
0008 83C0
83E0 0020
83FE 0000
000A 0A12
83E4 01F1
83E4 03E2

 

The lines that are different are:

**  9800 0000 - GROM read

>> I think this one reads random data, and in this case, the data was randomly 0000. This is of no real consequence.

 

     006E 837C - read immediate address 837C
**  817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)

>> This one is interesting. An immediate read of 837C is returning 817C? But, execution after this seems to chug along just fine, so maybe this one is alright?

 

    83F2 40F0 - read from R9 - got expected >40 (lsb unimportant, but matches the RBW above)
** 83E8 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4)

>> This one was originally 83E8 4AF4, which didn't raise any red flags on the previous disassembly, but now it's 00F4, which is quite different. A change from 4A to 00 is big and indicative of more than one line...

 

Then we get into what looks like reset and it's all chaos from there.

 

I'm not sure if this answers questions or creates more questions, haha.

 

Cheers,

David

 

It looks like a reset but it's definitely executing that data as if it was code. If you disassemble 0000 you get:

 

0000: 83E0 0012     C    @>0012,R15

 

0004: 83C0             C   R0,R15

 

From your trace:

0000: 83E0  C (compare) opcode

0002: 0012  compare operand

0012: Read value at 0012 

83FE: Read R15

0004: 83C0 C (compare) opcode

83E0: Read R0

83FE: Read R15

So it looks like bit 0080 is not going high when it is supposed to. There are other reads where it is high so it's not being pulled to ground all the time.

 

Edited May 28, 2023 by DanBoris

[JasonACT]

2 hours ago, DanBoris said:

So it looks like bit 0080 is not going high when it is supposed to. There are other reads where it is high so it's not being pulled to ground all the time.

Yeah, the times when it works, it's at address >83Ex or >83Fx (and we know bits 007F are all working) so it looks like there's a short circuit from address bit 0080 to 0100 or 0200 (where ground wins).

 

Edit: This would show the short is between 0080 and 0200 - ground won.

817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)

Edited May 29, 2023 by JasonACT

[+retroclouds]

 

[+OLD CS1]

 

 

[UsagiElectric]

8 hours ago, retroclouds said:

YT Vid

Yeah, that was filmed when we were still about halfway down page 1 of this thread, haha.

I'm not a huge fan of how that episode came together, it seems like I'm flailing about and just replacing things without thinking about the why, but there was actual logic behind the choices I made.

 

Notably, it takes about an hour to sit down with a logic analyzer and determine if an IC is working correctly in circuit. It takes about 20 minutes to desolder, socket and replace that same IC, so from a time management perspective, if an IC was even remotely suspect, it was faster to just rip it out and replace it. Knowing what we know now about the disassembly, I think we're finally starting to hone in a bit on where a potential fault might be though, so hopefully the next episode comes together a lot better!

 

15 hours ago, DanBoris said:

So it looks like bit 0080 is not going high when it is supposed to. There are other reads where it is high so it's not being pulled to ground all the time.

13 hours ago, JasonACT said:

Yeah, the times when it works, it's at address >83Ex or >83Fx (and we know bits 007F are all working) so it looks like there's a short circuit from address bit 0080 to 0100 or 0200 (where ground wins).

So, I did actually check for a short between A8 and A6 (0080 and 0200... I think... I hope) and it didn't show up on the multimeter beep out, but maybe there is enough resistance to not kick off the beep test. I believe 0080, 0100 and 0200 would be A6, A7 and A8, so I'll go check all three of those at each SRAM, ROM and the CPU for low resistance or shorts. If nothing shows up there, I wonder if it could be the LS367 at the end of the line (U509). It had an internal short that only crops up when powered on, it could be causing interesting failures as well.

 

Hopefully, some time spent with the multimeter today will help us narrow it down a bit!

 

Cheers,

David

[UsagiElectric]

22 minutes ago, OLD CS1 said:

"Never give up, never surrender!"

I'm not necessarily a smart man, but I'm stubborn as hell, we'll get there!

[Duewester]

When I was on submarines in the late 70's early 80's, we had an early microcontroller system. The first step in the trouble shooting was to verify +5vdc +- .01. If not in tolerance, replace the system.

The second step was verify -5vdc +- .01. If not in tolerance, replace system.

[+arcadeshopper]

57 minutes ago, UsagiElectric said:

So, I did actually check for a short between A8 and A6 (0080 and 0200... I think... I hope) and it didn't show up on the multimeter beep out, but maybe there is enough resistance to not kick off the beep test. I believe 0080, 0100 and 0200 would be A6, A7 and A8, so I'll go check all three of those at each SRAM, ROM and the CPU for low resistance or shorts. If nothing shows up there, I wonder if it could be the LS367 at the end of the line (U509). It had an internal short that only crops up when powered on, it could be causing interesting failures as well.

Hopefully, some time spent with the multimeter today will help us narrow it down a bit!

 

shorts can be so small they don't show up on the meter.. been there done that had to get someone with a bigger microscope to find it

[DanBoris]

1 hour ago, UsagiElectric said:

Yeah, that was filmed when we were still about halfway down page 1 of this thread, haha.

I'm not a huge fan of how that episode came together, it seems like I'm flailing about and just replacing things without thinking about the why, but there was actual logic behind the choices I made.

 

Notably, it takes about an hour to sit down with a logic analyzer and determine if an IC is working correctly in circuit. It takes about 20 minutes to desolder, socket and replace that same IC, so from a time management perspective, if an IC was even remotely suspect, it was faster to just rip it out and replace it. Knowing what we know now about the disassembly, I think we're finally starting to hone in a bit on where a potential fault might be though, so hopefully the next episode comes together a lot better!

 

So, I did actually check for a short between A8 and A6 (0080 and 0200... I think... I hope) and it didn't show up on the multimeter beep out, but maybe there is enough resistance to not kick off the beep test. I believe 0080, 0100 and 0200 would be A6, A7 and A8, so I'll go check all three of those at each SRAM, ROM and the CPU for low resistance or shorts. If nothing shows up there, I wonder if it could be the LS367 at the end of the line (U509). It had an internal short that only crops up when powered on, it could be causing interesting failures as well.

 

Hopefully, some time spent with the multimeter today will help us narrow it down a bit!

 

Cheers,

David

A6 also could be shorted to some other random signal instead of another address like. 

[humeur]

There is the logic comparator like the HP 10529 which allows in-circuit verification of TTL circuits

 

 

Il existe le comparateur logique comme le HP 10529 qui permet une vérification en circuit des circuit TTL

 

JL

[UsagiElectric]

Well, that's promising!

 

Measuring the resistance between address pins came up with this:

A6 to A7 -> 8M ohms
A7 to A8 -> 22M ohms
A6 to A8 -> 44 ohms

 

A6 to A8 at 44 ohms is way too low, and would account for our cross talk on those lines. So I started tracing them out, and just under the edge of one of the original TI sockets for the console ROMs (an area I have done no rework on or around), there was a piece of solder jammed in there, creating a short between two vias. And those two vias went to A6 and A8. Break the solder bridge away, and boom, successful boot! Insane, but I absolutely would not have been able to find it without the help of the disassembly telling me what was misbehaving.

 

Now, it's not all good news. It looks like hot garbage. I have to put the TV into Hi-Impedance mode instead of 75ohm, and I have to crank the brightness, contrast and the potentiometer on the motherboard to max to get a picture that is dim. There's also what looks like a massive amount of interference in the picture, I'm not sure where that's coming from. Could be some questionable passives in the video circuit, or something else entirely maybe?

 

Also, the keyboard is a pile of trash. There's so much bounce on each keypress, I sometimes get six characters for one press. I need to figure out how to pop the keycaps off so I can clean the actual keyswitch inside or something. Like, it's real bad. Took me 2 minutes to type "PRINT "HELLORLD!".

 

But, bad picture or not that is a functioning system!

Thank you guys so much for your help in getting to this point!

 

Cheers,

David

 

[Tursi]

On 5/27/2023 at 4:28 PM, UsagiElectric said:

@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?

Replying as I go, so this may be too late, but of course

 

[Tursi]

**  9800 0000 - GROM read - (In this instance the random value was 0000)

Yep, no big deal

**  817C 21F0 - RBW to 837C (Okay, this is interesting, we grab 837C but it changes to 817C?)

This suggests the >0200 bit was held low somewhere. While scratchpad will work anywhere in the range from >8000 to >83FF, the console only uses >8300 to >83FF

** 83E8 00F4 - rbw on R4 (We lost the 4AF4 and it turned into 00F4)

Remember this is the read before write -- so we are reading whatever was in R4 before. (The CPU then modifies the most significant byte and writes the entire word back). I don't think we hit R4 before this point, so I'm not too concerned about that. The important thing is that the MSB in the next instruction (the SRL) shows the 40 in the most significant byte, telling us that the write worked.

The rest of the log is still the console executing from >0000. It is a little confusing because the first accesses look so similar, but if we decode it as instructions:

 

0000 83E0   c @>0012,R15 (compare)
    0002 0012   - read ROM - immediate data >0012
    0012 020D   - read ROM - fetch data from >0012
    83FE 0000   - read SRAM - fetch data from R15
    
0004 83C0   c R0,R15 (compare)
    83E0 0020   - read SRAM - fetch data from R0
    83FE 0000   - read SRAM - fetch data from R15
    
0006 0A4C   sla R12,4 (shift)
    83F8 01F0   - read SRAM, fetch R4
    83F8 1F00   - write SRAM, new shifted value (hey, we caught a write!)
    
0008 83C0   c r0,r15 (compare)
    83E0 0020   - read SRAM, fetch R0
    83FE 0000   - read SRAM, fetch R15
    
000A 0A12   sla r2,1 (shift)
    83E4 01F1   - read SRAM, fetch R2
    83E4 03E2   - write SRAM, new shifted value

It's not a reset, because we don't see it write the vector registers.
    
So the fault is still on the address bus, except now you are sniffing different addresses. But it's still the same place - bit >0080 is not getting out onto the bus, or is being pulled low. Maybe just checking for short with the console off, right at the sniff point, would help?

 

Quote

So it looks like bit 0080 is not going high when it is supposed to. There are other reads where it is high so it's not being pulled to ground all the time.

That's an interesting point... maybe only on the ROM pathway?

 

Quote

A6 to A8 at 44 ohms is way too low, and would account for our cross talk on those lines. So I started tracing them out, and just under the edge of one of the original TI sockets for the console ROMs (an area I have done no rework on or around), there was a piece of solder jammed in there, creating a short between two vias. And those two vias went to A6 and A8. Break the solder bridge away, and boom, successful boot!

HAHA! Nice! That's surprisingly common on TI boards.

 

I'm still gonna post the above, cause hell, I did the work, but it's gratifying to see you got it working. Nice work!

 

For the video circuitry, that's all analog... but the jailbars are pretty normal. The TI board is pretty noisy, but you should be able to clean it up a bit!

 

For the keyboard - old dirty keyboards bounce like that all the time. Some spray contact cleaner and hammering each key a couple dozen times will go a long way. The fact that you get a bounce means it's one of the better mechanical keyboards.

 

[+arcadeshopper]

29 minutes ago, Tursi said:

For the keyboard - old dirty keyboards bounce like that all the time. Some spray contact cleaner and hammering each key a couple dozen times will go a long way. The fact that you get a bounce means it's one of the better mechanical keyboards.

 

On the 4 were there multiple keyboards?  I have never taken one apart that far.  I would assume it's like the 4/a keyboard where theres just two spring metal parts that meet when you push down a key and they get oxidized/dirty 

 

Greg

[UsagiElectric]

21 hours ago, Tursi said:

Replying as I go, so this may be too late, but of course

Awesome, thanks!

21 hours ago, Tursi said:

The important thing is that the MSB in the next instruction (the SRL) shows the 40 in the most significant byte, telling us that the write worked.

Ah, that makes sense! I was getting confused on order of things occurring here, but I'm following now!

21 hours ago, Tursi said:

I'm still gonna post the above, cause hell, I did the work, but it's gratifying to see you got it working. Nice work!

You get all the credit my man! Seriously, I don't think this thing would have come back to life without your help!

21 hours ago, Tursi said:

Some spray contact cleaner and hammering each key a couple dozen times will go a long way.

That did the trick, keyboard works perfectly now, and isn't quite as terrible to use as before. It's a bit like typing on a teletype, but I think with some practice and retraining of the brain, you could get fairly quick at it.

21 hours ago, Tursi said:

The TI board is pretty noisy, but you should be able to clean it up a bit!

I manged to get it a little better, but there's still a ridiculous amount of noise/interference, and it makes it straining to look at, so something is definitely funky in the video circuitry, but that's a problem for future me.

[UsagiElectric]

Oh, and this was the cause of the failure!
No clue how that piece of solder got there, it's up under the edge of an original TI socket in an area where I didn't do any rework, so could have been from me or could have been previous owner stuff. Either way, it's free and clear and alls good now!

[humeur]

42 minutes ago, UsagiElectric said:

Oh, and this was the cause of the failure!
No clue how that piece of solder got there, it's up under the edge of an original TI socket in an area where I didn't do any rework, so could have been from me or could have been previous owner stuff. Either way, it's free and clear and alls good now!

 

[Tursi]

1 hour ago, UsagiElectric said:

Oh, and this was the cause of the failure!
No clue how that piece of solder got there, it's up under the edge of an original TI socket in an area where I didn't do any rework, so could have been from me or could have been previous owner stuff. Either way, it's free and clear and alls good now!

Nice! It does look like a splash, doesn't it? Just a tiny thing like that, it's like the third time someone has posted a picture like that (that I've seen at least!)

[+acadiel]

I had to replace my video crystal on my /4.  The picture looked horrible - kind of like what you posted.  I barely had color.  Maybe that?