Assembly on the 99/4A

[RXB]

1 hour ago, Vorticon said:

So basically those CALL LOADs are moving the VDP stack to the low expansion memory?

Yes TML does that so it can load BIT MAPPED graphics or TEXT mode Graphics.

[+Vorticon]

37 minutes ago, TheBF said:

I believe it's moving it to the higher end of VDP memory.

Isn't >3818 in the low memory expansion area?

[+Vorticon]

37 minutes ago, TheBF said:

I believe it's moving it to the higher end of VDP memory.

Isn't >3818 in the low memory expansion area?

[+Vorticon]

So my next question then is: what is the function of the VDP stack in relation to XB?

[+TheBF]

22 minutes ago, Vorticon said:

Isn't >3818 in the low memory expansion area?

VDP Ram is 16K addressed from 0 to >3FFF

[+TheBF]

7 minutes ago, TheBF said:

VDP Ram is 16K addressed from 0 to >3FFF

To be clear, VDP RAM is not connected directly to the CPU address lines, but is accessed like an I/O device via "magic" addresses selected by the designers for this function. 

That is why the LOW RAM and the VDP RAM appear to have conflicting addresses but in fact do not conflict.

[+Vorticon]

8 minutes ago, TheBF said:

To be clear, VDP RAM is not connected directly to the CPU address lines, but is accessed like an I/O device via "magic" addresses selected by the designers for this function. 

That is why the LOW RAM and the VDP RAM appear to have conflicting addresses but in fact do not conflict.

Ah yes of course. One has to use the transfer utilities (VMBW and its relatives) to access the VDP RAM. Thanks for pointing that out. 

So I still don't understand the VDP stack function. I know how stacks work, so I assume the LOAD statements just have it moved to a higher address in order to keep it from being overwritten by the bitmap mode which takes up a large chunk of the VDP. I suspect the VDP stack keeps track of some basic XB functions such as the location of the currently executable statement or something along those lines? Is there a reference about that stack somewhere?

[+TheBF]

21 minutes ago, Vorticon said:

So I still don't understand the VDP stack function.

 

 

I know how stacks work, so I assume the LOAD statements just have it moved to a higher address in order to keep it from being overwritten by the bitmap mode which takes up a large chunk of the VDP. I suspect the VDP stack keeps track of some basic XB functions such as the location of the currently executable statement or something along those lines? Is there a reference about that stack somewhere?

I am pretty sure you are correct about moving the stack because bit-map mode needs a lot of VDP RAM. I spent some time on that a few months back. 

 

I am no expert on the BASIC system but it will need a stack somewhere to handle things like subroutines calling subroutines and a stack is always handy for temporary storage of misc. values as well. 

This might be it. Rich will chime in here a some point I hope to clarify it for us both. 

[apersson850]

The stack is needed for calculations too. You can't compute things like 2*3+4*5 without stacking 2*3 while you compute 4*5, for example.

And it's needed for subroutines (GOSUB) to keep track of where to return to. FOR-NEXT loops need some way of keeping track of where to go back when you encounter NEXT.

 

Some systems use a single stack for everything. Like the p-system.

Some have separate stacks for different purposes. Like Forth, which typically has a "normal" stack and a "return" stack. The latter dedicated to subroutine tracking.

Unlike Rich I don't know exactly how Extended BASIC does. But the fact that the stack is in VDP RAM is of course that there's not enough of other RAM, when you miss the memory expansion.

Edited March 30, 2023 by apersson850

[RXB]

18 hours ago, Vorticon said:

Isn't >3818 in the low memory expansion area?

HEX >3818 = Decimal 14360

VDP memory is from >0000 to >3FFF

Using a TI99/4A Console only with FinalGROM and RXB shows you exactly what is going on when you type:  SIZE

[RXB]

18 hours ago, Vorticon said:

So my next question then is: what is the function of the VDP stack in relation to XB?

VDP stack work like Forth Stack and it does as stated by BF pushes values or subroutines onto the stack to be popped off later

like for number calculations or FOR/NEXT loops or DEF routines.

[+Vorticon]

I saw a mysterious B @>70 instruction in that XB bitmap listing. What is pointed at by >70?

[+TheBF]

16 minutes ago, Vorticon said:

I saw a mysterious B @>70 instruction in that XB bitmap listing. What is pointed at by >70?

>0070

Main entry point into the GPL interpreter.

 

 

www.unige.ch/medecine/nouspikel/ti99/roms.htm

[HOME AUTOMATION]

1 hour ago, Vorticon said:

What is pointed at by >70?

B @>70, starts the GPL interpreter, which executes the instruction pointed to by the GROM WRITE ADDRESS register.

 

24.11.3 Other Returns

 

16.5 GROM ACCESS

[+Vorticon]

Ah ha! Thank you guys!

[+Vorticon]

What is the best way to return to the title screen from assembly?

[+Lee Stewart]

30 minutes ago, Vorticon said:

What is the best way to return to the title screen from assembly?

 

I just do the following:

 

       CLR  @83C4    clear ISR hook
       BLWP @0       branch to reset vector

 

...lee

[+Vorticon]

That worked. Thanks!

[+Vorticon]

There seems to be an issue using the SAVE opcode for the PAB (>06) and DSRLNK. In the following snippet, only the second save operation actually works, while the first one does nothing even though it's completely valid. Now if I duplicate the first save code section, then both saves work. It took me several hours of head banging to figure this out, although I haven't the slightest clue as to why this is happening. Could this be related to the TIPI?

 

.
.
PABP   DATA >0600,>0000,>0000,>1800,>000E    CAPTURE IMAGE PATTERN DATA PAB. PDT @0
       TEXT 'DSK1.CAPTURE_P'
       EVEN
PABC   DATA >0600,>2000,>0000,>1800,>000E    CAPTURE IMAGE COLOR DATA PAB. CT AT >2000
       TEXT 'DSK1.CAPTURE_C'
       EVEN
.
.

** SAVE IMAGE DATA

* FIRST SAVE OP
       LI   R0,>1F1A          VDP ADDRESS FOR PAB
       LI   R1,PABP           POINT TO PATTERN DATA PAB
       LI   R2,24             LENGTH OF PAB
       BLWP @VMBW             TRANSFER PATTERN PAB TO VDP
       LI   R6,>1F23          LOAD R6 WITH PATTERN DATA FILE DESCRIPTOR LENGTH POINTER
       MOV  R6,@>8356         REQUIRED BY DSRLNK
       BLWP @DSRLNK           SAVE TO DISK
       DATA 8                 REQUIRED BY DSRLNK

* SECOND SAVE OP
       LI   R0,>1F1A
       LI   R1,PABC           POINT TO COLOR DATA PAB
       LI   R2,24
       BLWP @VMBW             TRANSFER COLOR PAB TO VDP
       LI   R6,>1F23          LOAD R6 WITH COLOR DATA FILE DESCRIPTOR LENGTH POINTER
       MOV  R6,@>8356
       BLWP @DSRLNK           SAVE TO DISK
       DATA 8

 

[Stuart]

59 minutes ago, Vorticon said:

There seems to be an issue using the SAVE opcode for the PAB (>06) and DSRLNK. In the following snippet, only the second save operation actually works, while the first one does nothing even though it's completely valid. Now if I duplicate the first save code section, then both saves work. It took me several hours of head banging to figure this out, although I haven't the slightest clue as to why this is happening. Could this be related to the TIPI?

 

Do you need to close each file, using the CLOSE opcode?

[+Lee Stewart]

23 minutes ago, Stuart said:

Do you need to close each file, using the CLOSE opcode?

 

SAVE does not require OPEN, so it should not require CLOSE.

 

...lee

[+TheBF]

What is in the first byte of the PAB (in VDP RAM) after the operation completes in each case?

[+Vorticon]

48 minutes ago, TheBF said:

What is in the first byte of the PAB (in VDP RAM) after the operation completes in each case?

I'll have to dust off one of the debuggers as I am working on real hardware here. It's been a while... The first nibble should have an error code, if any.

[+InsaneMultitasker]

I know you mentioned you are working on real hardware but are you able to try the save routine on Classic99?  Its debug/log may tell you something that isn't obvious with the code snip shown above. 

[Asmusr]

Do you have LIMI 0?