Infinite loop after hitting GETPLT

[robus]

Got stuck on trying to get the Blackboard to load and go in my homebrew Atari emulator. This code gets stuck in an infinite loop because LDA (ADRESS),Y is returning 0 (and DMASK is also returning 0)

 

GETPLT: JSR   CONVRT
          LDA     (ADRESS),Y
          AND     DMASK
SHIFTD: LSR   SHFAMT
          BCS     SHIFT1
          LSR     A
          BPL     SHIFTD

 

During my run:

 

2022-09-09 13:04:19.504201-0500 SimAtari[16036:6342964] 0xF5A5 LDA (0x3C42),y  -> 0x0
2022-09-09 13:04:21.770797-0500 SimAtari[16036:6342964] 0xF5A7 AND 0x2A0 -> 0x0
2022-09-09 13:10:01.155249-0500 SimAtari[16036:6342964] 0xF5AA LSR 0x6F -> 0x0 
2022-09-09 13:10:14.366960-0500 SimAtari[16036:6342964] 0xF5AC BCS 0x3 (C = 0)
2022-09-09 13:10:15.976096-0500 SimAtari[16036:6342964] 0xF5AE LSR -> 0x0
2022-09-09 13:10:16.591118-0500 SimAtari[16036:6342964] 0xF5AF BPL 0xFFFFFFF9 (N = 0)

 

So obviously something's gone wrong somewhere in the setup. All the init code seems happy along the way though. Just wondering if anyone has an insight into this area?

 

[robus]

Some more exploration is revealing that the issue seems to be in CONVRT:

 

The DMASKT index referred to here "TMPLBT IS NOW THE INDEX INTO DMASKTB" in the source is 0, which is $00 in the mask array:

 

DMASKT: .BYTE   $00,$FF,$F0,$0F
          .BYTE $C0,$30,$0C,$03

 

So it all falls apart.

 

I guess I'm confused about what is supposed to happen when ROWCRS is 0. This logic all assumes that there is something other than 0 to work with?
 

LDA     ROWCRS ;PUT 10*ROWCRS INTO MLTTMP
STA     MLTTMP
LDA     #0
STA     MLTTMP+1
LDA     MLTTMP ;QUICK X8
ASL     A
ROL     MLTTMP+1
STA     HOLD1 ;(SAVE 2X VALUE)
LDY     MLTTMP+1
STY     HOLD2
ASL     A
ROL     MLTTMP+1
ASL     A
ROL     MLTTMP+1
CLC

 

Mapping the ATARI says it can be 0 though, so how does it avoid getting into the infinite loop I have in the first post?

Quote

ROWCRS
Current graphics or text screen cursor row, value ranging from zero to 191 ($BF) depending on the current GRAPHICS mode (maximum number of rows, minus one). This location, together with location 85 below, defines the cursor location for the next element to be read/written to the screen. Rows run horizontally, left to right across the TV screen. Row zero is the topmost line; row 192 is the maximum value for the bottom-most line.

 

Edited September 9, 2022 by robus
More clarification

[robus]

Oh and DINDEX is 0 because we're in Mode 2:

 

;
; ANTIC CODE FROM INTERNAL MODE CONVERSION TABLE
;
;   INTERNAL            ANTIC CODE               DESCRIPTION
;        0                  2                   40X2X8  CHARACTERS

So it's zeros everywhere.

[dmsc]

i!

6 hours ago, robus said:

Got stuck on trying to get the Blackboard to load and go in my homebrew Atari emulator. This code gets stuck in an infinite loop because LDA (ADRESS),Y is returning 0 (and DMASK is also returning 0)

 

GETPLT: JSR   CONVRT
          LDA     (ADRESS),Y
          AND     DMASK
SHIFTD: LSR   SHFAMT
          BCS     SHIFT1
          LSR     A
          BPL     SHIFTD

 

During my run:

 

2022-09-09 13:04:19.504201-0500 SimAtari[16036:6342964] 0xF5A5 LDA (0x3C42),y  -> 0x0
2022-09-09 13:04:21.770797-0500 SimAtari[16036:6342964] 0xF5A7 AND 0x2A0 -> 0x0
2022-09-09 13:10:01.155249-0500 SimAtari[16036:6342964] 0xF5AA LSR 0x6F -> 0x0 
2022-09-09 13:10:14.366960-0500 SimAtari[16036:6342964] 0xF5AC BCS 0x3 (C = 0)
2022-09-09 13:10:15.976096-0500 SimAtari[16036:6342964] 0xF5AE LSR -> 0x0
2022-09-09 13:10:16.591118-0500 SimAtari[16036:6342964] 0xF5AF BPL 0xFFFFFFF9 (N = 0)

It is not possible to have a 0 in SHFAMT in the real Atari, it is setup at the end of CCA:

00F5F4  1  BE 9D EE             LDX     TRSC,Y
00F5F7  1  BD 04 FB             LDA     TMSK,X
00F5FA  1  25 55                AND     COLCRS          ;and in low cursor column
00F5FC  1  65 66                ADC     OPNTMP
00F5FE  1  A8                   TAY
00F5FF  1  B9 AC EE             LDA     TDSM-1,Y        ;display mask
00F602  1  8D A0 02             STA     DMASK           ;display mask
00F605  1  85 6F                STA     SHFAMT
00F607  1  A0 00                LDY     #0

 

With DINDEX (at Y) zero, A is 0 (from TRSC and TMSK), the and gives 0 and OPNTMP is #1 (initialized at start), so Y = 1, and the table reads $FF, writen to SHFAMT.

 

So, at the first iteration, the LSR sets carry and the BCS skips the loop.

 

Have Fun!

[phaeron]

7 hours ago, robus said:

2022-09-09 13:04:19.504201-0500 SimAtari[16036:6342964] 0xF5A5 LDA (0x3C42),y  -> 0x0

 

Check your CPU emulation, this disassembly is bogus -- should be LDA (zp),Y, not LDA (abs),Y.

[robus]

Thanks, I’ll check into all those.

 

I may have messed up my copy/paste/editing on the questionable LDA line, because it would be weird to get this far with a bug like that, but not impossible

[robus]

19 hours ago, dmsc said:

It is not possible to have a 0 in SHFAMT in the real Atari, it is setup at the end of CCA:

I'm looking at my OS source listing and I'm not finding this bit of code? TRSC, for example, is not mentioned.

 

I'm using this as a source reference

 LIST X
; THIS IS THE MODIFIED SEPTEMBER ATARI 400/800 COMPUTER OPERATING
; SYSTEM LISTING. MODIFIED TO ASSEMBLE ON THE MICROTEC CROSS
; ASSEMBLER.
; THIS VERSION IS THE ONE WHICH WAS BURNED INTO ROM.
; THERE IS A RESIDUAL PIECE OF CODE WHICH IS FOR LNBUG. THIS
; IS AT LOCATION $9000 WHICH IS NOT IN ROM.
;
; THIS IS THE REVISION B EPROM VERSION
.PAGE
;
;
;
;
;
;
PALFLG  =        0
;
COLLEEN OPERATING SYSTEM EQUATE FILE

Which is tracking the NTSC Rev B OS ROM I've loaded into my Sim.

[robus]

19 hours ago, phaeron said:

Check your CPU emulation, this disassembly is bogus -- should be LDA (zp),Y, not LDA (abs),Y.

Ah the address I was showing is the contents of the zp address with the Y added. Sorry for the confusion. In my disassembly I wanted to see what the calculated address was for easy peeking - but I should print out the input as well as the output.

 

[dmsc]

Hi!

5 hours ago, robus said:

I'm looking at my OS source listing and I'm not finding this bit of code? TRSC, for example, is not mentioned.

 

I'm using this as a source reference

 LIST X
; THIS IS THE MODIFIED SEPTEMBER ATARI 400/800 COMPUTER OPERATING
; SYSTEM LISTING. MODIFIED TO ASSEMBLE ON THE MICROTEC CROSS
; ASSEMBLER.
; THIS VERSION IS THE ONE WHICH WAS BURNED INTO ROM.
; THERE IS A RESIDUAL PIECE OF CODE WHICH IS FOR LNBUG. THIS
; IS AT LOCATION $9000 WHICH IS NOT IN ROM.
;
; THIS IS THE REVISION B EPROM VERSION
.PAGE
;
;
;
;
;
;
PALFLG  =        0
;
COLLEEN OPERATING SYSTEM EQUATE FILE

Which is tracking the NTSC Rev B OS ROM I've loaded into my Sim.

You can download an archive of all (reconstructed) OS sources from https://seriouscomputerist.atariverse.com/pages/resource/resource.source.htm , by Tomasz Krasuski.

 

I quoted from version BB000001 Rev. 2, as that is what came with my 800XL. In OSB the code is different, but the result is the same, it is setup at CONVRT, at the end also:

 

00F988  1  BC A5 FE     CONVR2: LDY     DIV2TB,X    ;NOW DIVIDE HCRSR TO ACCOUNT FOR PARTIAL BYTES
00F98B  1  A5 55                LDA     COLCRS
00F98D  1  A2 07                LDX     #7          ;* TRICKY *
00F98F  1  88           CONVR3: DEY
00F990  1  30 0A                BMI     CONVR4
00F992  1  CA                   DEX
00F993  1  46 56                LSR     COLCRS+1
00F995  1  6A                   ROR     A
00F996  1  6E A1 02             ROR     TMPLBT      ;SAVE LOW BITS FOR MASK
00F999  1  4C 8F F9             JMP     CONVR3
00F99C  1  C8           CONVR4: INY                 ;SO Y IS ZERO UPON RETURN FROM THIS ROUTINE
00F99D  1  18                   CLC
00F99E  1  65 66                ADC     MLTTMP      ;ADD SHIFTED COLCRS TO MLTTMP
00F9A0  1  85 66                STA     MLTTMP
00F9A2  1  90 02                BCC     CONVR5
00F9A4  1  E6 67                INC     MLTTMP+1
00F9A6  1  38           CONVR5: SEC                 ;* TRICKY *
00F9A7  1  6E A1 02     CONVR6: ROR     TMPLBT      ;SLIDE A "1" UP AGAINST LOW BITS (CONTINUE TILL X=-1)
00F9AA  1  18                   CLC
00F9AB  1  CA                   DEX                 ;AND FINISH SHIFT SO LOW BITS ARE
00F9AC  1  10 F9                BPL     CONVR6      ;RIGHT JUSTIFIED.
00F9AE  1  AE A1 02             LDX     TMPLBT      ;TMPLBT IS NOW THE INDEX INTO DMASKTB
00F9B1  1  A5 66                LDA     MLTTMP      ;PREPARE FOR RETURN
00F9B3  1  18                   CLC
00F9B4  1  65 64                ADC     ADRESS
00F9B6  1  85 64                STA     ADRESS
00F9B8  1  85 5E                STA     OLDADR      ;REMEMBER THIS ADDRESS FOR CURSOR
00F9BA  1  A5 67                LDA     MLTTMP+1
00F9BC  1  65 65                ADC     ADRESS+1
00F9BE  1  85 65                STA     ADRESS+1
00F9C0  1  85 5F                STA     OLDADR+1

00F9C2  1  BD B1 FE             LDA     DMASKT,X
00F9C5  1  8D A0 02             STA     DMASK
00F9C8  1  85 6F                STA     SHFAMT

00F9CA  1  68                   PLA
00F9CB  1  85 56                STA     COLCRS+1
00F9CD  1  68                   PLA
00F9CE  1  85 55                STA     COLCRS
00F9D0  1  68                   PLA
00F9D1  1  85 54                STA     ROWCRS
00F9D3  1  60                   RTS

 

Here, SHFAMT is setup with $FF from DMASKT, as at $F9C2 X is 1 when DINDEX is 0.

 

The code is more complicated, but you can see that at CONVR6 the ROR shifts a 1 into TMPLBT (from the SEC just above), so TMPLBT is always > 0, in the case of DINDEX=0, the loop is executed 7 times, so at the end TMPLBT is 1.

 

Have Fun!

Edited September 11, 2022 by dmsc

[robus]

2 hours ago, dmsc said:

The code is more complicated, but you can see that at CONVR6 the ROR shifts a 1 into TMPLBT (from the SEC just above), so TMPLBT is always > 0, in the case of DINDEX=0, the loop is executed 7 times, so at the end TMPLBT is 1.

Thanks, I see that. Going to step through my code to see what happens there. Might have a bug in my ROR logic. I’ll check my tests for it first though!

[robus]

And I had a bug in my ROR/ROL logic. I was feeding the Carry flag with the result of the rotate before feeding the current Carry flag into the value.

 

C -> [76543210] -> C

 

Isn't the most clear description of the logic (one could imagine the Carry flag is being used to ferry the exiting bit around to the other end, as I did ) 

Edited September 11, 2022 by robus

[robus]

With that bug eliminated, I'm now back to the more interesting work of getting POKEY to handle some disk IO as my emulator attempts a disk boot (which is of course going to fail, but isn't yet as it's stuck in transmission waiting for some kind of send status response ).

Edited September 11, 2022 by robus