weird issue with a 4/a

[+arcadeshopper]

I have a console here that will immediately screen-save timeout when it boots up. You get the color bars for maybe a second..and then blank..

does it with the 9918a and the F18a so it's not the vdp or vdp ram. any ideas?  maybe it's the cpu? cpu/stack ram?

 

hitting any key causing a reset causes it to work normally btw..  either with a finalgrom reset button or fctn = 

 

Greg 

 

[+OLD CS1]

My guesses:

1. Since the count-down to blank is stored in CPU RAM, I would imagine there is a problem with the CPU RAM or accessing it.
2. The count-down to blank is run by the ISR every 1/60s, so is it possible the interrupt is continually firing?

[+InsaneMultitasker]

Wild guess along lines of #2 maybe a hyperactive 9901 or issue with a component/trace attached along the vidint pathway.

[+arcadeshopper]

4 hours ago, OLD CS1 said:

My guesses:

1. Since the count-down to blank is stored in CPU RAM, I would imagine there is a problem with the CPU RAM or accessing it.
2. The count-down to blank is run by the ISR every 1/60s, so is it possible the interrupt is continually firing?

1 yeah my thought too

2 wouldn't it then fire all the time once i reset?  it goes back to normal behavor after a reset..its almost like it's expecting cpu ram to have a value at startup and it's different

[+OLD CS1]

39 minutes ago, arcadeshopper said:

2 wouldn't it then fire all the time once i reset?  it goes back to normal behavor after a reset..its almost like it's expecting cpu ram to have a value at startup and it's different

Yeah, it seemed like a long shot, maybe something to concede at the bargaining table. If the interrupt was firing constantly I expect the ISR would consume all CPU time.

[Keneg]

Maybe a faulty ROM isn’t initializing the timer correctly?

[+arcadeshopper]

Maybe a faulty ROM isn’t initializing the timer correctly?

Maybe I don't see a rom test in ti diags

Sent from my LM-V600 using Tapatalk

[HOME AUTOMATION]

The self authored program, CONROMO(program name RUN) will dump >0000, thru >1FFF, to filename DSK1.CONROM.

 

I tested this by dumping Classic 99's console ROM. Next, I viewed the CONROM file with TI99dir. Then copied the viewed data to NOTEPAD.

 

Then did the same again using Win994a.

 

Next, I compared the two text files using a HEXEDITOR.

 

Sure enough, there was a difference at >0908 ...>0460, vs. >04CC.

 

You should be able to do this procedure, using the console in question, vs. a known good console...

...Perhaps revealing any issues.

 

However, if the issue is in GROM ...I don't do GROMS. That'll cost ya. Ha!

 

 

CONROMDUMP.DSK

Edited November 5, 2020 by HOME AUTOMATION

[+mizapf]

If you have a writable cartridge that allows configuring with an auto-start, maybe you can set up a program for the cartridge to dump the ROM and the scratch pad to some RAM area to investigate further. The cartridge ROM will be executed early enough so that one might see something interesting.

[Tursi]

On 11/5/2020 at 7:19 AM, HOME AUTOMATION said:

Sure enough, there was a difference at >0908 ...>0460, vs. >04CC.

Is it an offset issue, or just that one word?

 

>04CC is "CLR R12", and >0460 is "B @>" (absolute branch)... pretty big difference.

 

>0908 is near the start of the interrupt routine, clearing the CRU base. The next instruction is supposed to test for cassette interrupt. Changing it to >0460 sounds like someone replaced the interrupt routine...

 

[HOME AUTOMATION]

5 hours ago, Tursi said:

Is it an offset issue, or just that one word?

 

>04CC is "CLR R12", and >0460 is "B @>" (absolute branch)... pretty big difference.

 

>0908 is near the start of the interrupt routine, clearing the CRU base. The next instruction is supposed to test for cassette interrupt. Changing it to >0460 sounds like someone replaced the interrupt routine...

 

Classic99: >0460 >094C

Win994a:  >04CC >23A0

 

...on the diskfile the resultant crc/checksum differs as well. Nothing more. Curious!

[Tursi]

On 11/6/2020 at 8:29 PM, HOME AUTOMATION said:

Classic99: >0460 >094C

Win994a:  >04CC >23A0

 

...on the diskfile the resultant crc/checksum differs as well. Nothing more. Curious!

Not on MY Classic99!

 

   0070  0300  limi >0002                  (16)
   0002
   0900  0300  limi >0000                  (38)
   0000
   0904  02E0  lwpi >83e0                  (10)
   83E0
> 0908  04CC  clr  R12                   
   090A  23A0  coc  @>0032,R14            
   0032
   090E  1602  jne  >0914                 
   0910  0460  b    @>1404                
   1404

 

Are you running a replacement ROM?

[Tursi]

Double-checking suggests you have those backwards - MiniMemory in my copy of Win994A shows the branch (0460) is in its ROM. This is different from the real TI ROM. It branches to 094C directly - basically bypassing the test for CS1 and DSR interrupts (also oddly also bypassing the SBO 2 meant to acknowledge the interrupt in the 9901).

 

 

 

 

[HOME AUTOMATION]

Yes, complementation is one of my specialties! Sorry about that.

It does seem to make more sense this way, since Win994a has it's own way of dealing with the cassette interface.

 

This reminds me of the way I tapped into the LPC in the Text-To-Speech disk.

[+mizapf]

8 hours ago, Tursi said:

also oddly also bypassing the SBO 2 meant to acknowledge the interrupt in the 9901

I would suggest not to call this an acknowledgement. This is done by the operation at 0A84 (MOVB @>FC00(R15),@>837B), since it actually clears the interrupt.

 

According to the specs, doing a SBO on the interrupt inputs of the 9901 arms the interrupt trigger. Since this is after LIMI 0, nothing happens (all interrupts from the 9901 are on level 1). This SBO seems to be done in preparation of the later return from the interrupt service.

 

 The comments on SBO/Z >0002 in "TI Intern" are consistently wrong, as I found out (said the one complaining about the thousands of wrong-way drivers on the road... ? ).

[Tursi]

11 hours ago, mizapf said:

I would suggest not to call this an acknowledgement. This is done by the operation at 0A84 (MOVB @>FC00(R15),@>837B), since it actually clears the interrupt.

 

According to the specs, doing a SBO on the interrupt inputs of the 9901 arms the interrupt trigger. Since this is after LIMI 0, nothing happens (all interrupts from the 9901 are on level 1). This SBO seems to be done in preparation of the later return from the interrupt service.

 

 The comments on SBO/Z >0002 in "TI Intern" are consistently wrong, as I found out (said the one complaining about the thousands of wrong-way drivers on the road... ? ).

What's really sad is how low I hesitated on writing the single word "acknowledge" for fear someone would call me out on it, then finally decided I didn't really feel like researching deeper to replace one word.

 

Only to get three paragraphs of call out over it.

 

 

[Tursi]

((I should add no problem with the clarification -- that's why we're on a forum. I just found it ironic that I hesitated over that exact wording and what I feared happened anyway ))

 

It's worth adding, though, that you always acknowledge an interrupt while interrupts are disabled. Otherwise, they can fire again immediately and you normally don't want that. When you do, you do the acknowledge at the end of the routine, instead of at the beginning.

 

It's potentially not wrong to call the 9901 write an acknowledge, though as you note, it's not really correct either. However, the interrupt has /two/ devices in the chain - the VDP who originates it, and the 9901 who filters it before the CPU finally gets it. The 9901 doesn't really need to be acknowledged for the next interrupt to work, as most of us know, but there's also a lot of code inside the TI that seems to be based on preliminary documentation, maybe this is one of them.

 

So I'll correct myself to "oddly bypassing the SBO 2 meant for God-alone-knows-what in the 9901, but it's normally part of the interrupt handler".