Jump to content
IGNORED

Extended Basic and bitmap


Vorticon

Recommended Posts

Hi. I'd like to run an XB program, go into bitmap mode, do stuff in that mode, then come back to XB so I can chain another XB program.

Going into bitmap mode from XB is straightforward, but the coming back bit is where I need guidance as I'm not sure what I need to save and restore prior to jumping into bitmap and when coming back...

The launch program will really only consist of the usual CALL INIT, CALL LOAD AND CALL LINK to access an ML program in low memory, and ends with a RUN command to chain another standard XB program. I know Tursi has created such a program with embedded assembly code which I have used in my projects previously, but I'd like to avoid embedded code if I can and also learn how to do this.

One related question: is the ML program loaded  with CALL LOAD still be accessible from the chained XB program or will I need to issue the whole loading sequence again?

Link to comment
Share on other sites

7 hours ago, Tursi said:

My program left the system pretty messed up too... it /worked/, but I wouldn't recommend it if you are trying to do it right ;)

 

Do you think you could give me pointers as to which areas of the VDP I need to save and restore after bitmap mode to return to XB? I'm guessing it's not just a matter of adjusting the VR registers for graphics mode ? Is there a good reference on this somewhere?

I'm thinking maybe I can save those areas to the expansion RAM then restore them...

Edited by Vorticon
  • Like 1
Link to comment
Share on other sites

I am not totally sure what memory locations need to be saved, but here are a few things to try:

You know that the bit mapped mode is going to overwrite >0000 to >17FF and >2000 to >37FF plus another >300 for the screen table which is >00 to >FF  repeated 3x. This can be at >1800.

With the default CALL FILES(3) the disk buffering area starts at >37D8 which is used by bit mapped graphics. CALL FILES(2) gets around that problem. Or you can store that memory area, then restore it before you try to run the next program. >8370 points to the highest available address in VDP. With CALL FILES(3) that is >37D7, although with the CF7 and perhaps other devices, that will be lower by 4 bytes if I am remembering right. You should have no trouble if you save and restore 16 bytes from VDP ram pointed to by >8370.

For the return to XB, you must restore the color table at >0800 and the character definitions. This is usually done with 2 GPLLNKs to load the upper case and lower case letters. Plus you should restore the cursor and edge character at >03F0. Clearing the screen is optional and not needed if your XB program does CALL CLEAR.

 

You can test out whether this works with a simple assembly program that:

1-saves 16 bytes of VDP ram pointed to by >8370

2-clears vdp memory from >0000 to >17FF  (to be sure, you may want to write >FF to these memory areas as well)

3-pauses for a few seconds (optional)

4-restores the color table, character patterns, and 16 bytes of stored disk information

5-returns to XB with LWPI >83E0 and B @>006A

 

If all goes well, assuming your XB program is 10 CALL INIT::CALL LOAD("DSK1.BITMAP.OBJ")::CALL LINK("BITMAP")::RUN "DSK1.PROGRAM2" this should run DSK1.PROGRAM2

Because you are running another program, RUN will reset most of the XB pointers and you should be able to get away with this.

If it fails, you can try saving and restoring the Extended BASIC system area from >0370 to >03C0.

(Edit) Although it only restores characters 32 to 95, CALL CHARSET might suffice for your testing

 

Edited by senior_falcon
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

For testing purposes, even quicker would be:

CALL FILES(2)

then your assembly sub clears memory from >0000 to >37FF then returns to XB where it (hopefully) encounters RUN "DSK1.XBPROGRAM"

then the XB program does CALL CLEAR::CALL CHARSET, then uses CALL COLOR to reset the color tables.

 

Also, if you want to use the scratchpad for your workspace(s) then you should save the contents and restore when returning to XB.

Edited by senior_falcon
  • Like 3
Link to comment
Share on other sites

The following shows proof of concept. It stores 80 bytes from v0370, then trashes VDP ram up to >37FF, then restores v0370

Must use CALL FILES(2). Follow my recipe in post #7 for a more complete implementation.

 

Program 1 - save as WALIDTEST1
10 CALL INIT :: CALL LOAD("DSK1.WALIDTEST.OBJ"):: CALL LINK("BITMAP"):: RUN "DSK1.WALIDTEST2"  

---------------------------------------------------------------------------------------

Program 2 - save as WALIDTEST2 (EDIT) changed to use CALL FONT and clear the first sprite. XB 2.8 G.E.M. only.

20 CALL FONT(2):: CALL CLEAR :: CALL COLOR(ALL,2,8):: CALL POKEV(768,208)
50 FOR I=1 TO 10 :: PRINT I,"BACK IN XB" :: NEXT I

---------------------------------------------------------------------------------------

assembly support - save as WALIDTEST.TXT and assemble to WALIDTEST.OBJ

N.B. You must use XB 2.8 G.E.M. if you want to use REFs in XB.

 

    REF VSBW
    REF VMBR
    REF VMBW
    DEF BITMAP
    
BITMAP    LI R0,>0370
    LI R1,BUFFER
    LI R2,80
    BLWP @VMBR
    
    CLR R0
    SETO R1
LOOP    BLWP @VSBW
    INC R0
    CI R0,>3800
    JLT LOOP
    
    LI R0,>0370
    LI R1,BUFFER
    LI R2,80
    BLWP @VMBW
    
    B @>006A

BUFFER BSS 80
    
    END

 


 

 

Edited by senior_falcon
  • Thanks 1
Link to comment
Share on other sites

So my intention was to load pattern and color data files from disk to display on the bitmap screen, but it looks like DSRLNK is not supported by the XB environment... Is there an alternative way to access disk files from ALC within the XB constraints?

A bitmap image will consist of a pattern and a color file, each 6K in length (12K total). If I loaded those into memory with XB prior to accessing the ALC program, is there a way to know where they would be located in the expansion RAM so I can retrieve them?

Edited by Vorticon
Link to comment
Share on other sites

GPLLNK and DSRLNK are built into XB 2.8 G.E.M. 

CALL INITG
INITG does the CALL INIT routine, loads two additional support routines for GPLLNK and DSRLNK, then clears the interrupt hook at >83C4.
GPLLNK is at >24F4 and DSRLNK is at >253A.

You can REF GPLLNK and REF DSRLNK

 

Or you can add it to your code:

 


*******************************************************************************
*GPLLNK AND DSRLINK FROM THE SMART PROGRAMMER
********************************************************************************
 
GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1	MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00
       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

 

  • Like 2
Link to comment
Share on other sites

What VDP addresses are the 2 GPLLNK routines for re-loading the upper and lower-case characters (>16 and >18 respectively) expecting to see in the FAC?

I'm not clear if they also load punctuation and other characters as well.

As a matter of fact, what is the default VDP map for XB? 

Sorry for all the questions, but it's all in the name of science ?

Edited by Vorticon
Link to comment
Share on other sites

So I made some progress. As a matter of fact I'm very close: I am able to display a bitmap image, wait for a keypress, then go back to XB and chain another XB program. Unfortunately the display of the latter is garbled although it runs fine otherwise. Sprites seem unaffected. When I break out of the program, the display is restored to the standard XB mode and I can see that the characters on screen were plotted correctly.

Below is the ALC program. It takes an image files (pattern and color - attached) and displays the image in bitmap. I used the code for DSRLNK and GPLLNK per senior_falcon's instructions.

* Bitmap splash image display from XB (XBBMP)

       DEF  SPLASH
VWTR   EQU  >2030
VMBW   EQU  >2024
VSBW   EQU  >2020
VMBR   EQU  >202C
KSCAN  EQU  >201C           
GPLSTS EQU  >837C
FAC    EQU  >834A
       
PABC   DATA >0500,>2000,>0000,>1800,>0009
       TEXT 'DSK1.KP_C'
       EVEN
PABP   DATA >0500,>0000,>0000,>1800,>0009
       TEXT 'DSK1.KP_P'
       EVEN
BUF1   BSS  80
BUF2   BSS  16
ANYKEY BYTE >20
       EVEN

SPLASH LI R0,>0370             * SAVE XB CURSOR AND EDGE CHARACTER
       LI R1,BUF1
       LI R2,80
       BLWP @VMBR
	   
       MOV  @>8370,R0          * SAVE DISK BUFFER SPACE
       LI   R1,BUF2
       LI   R2,16
       BLWP @VMBR   
	   
       LI   R0,>A000
       MOVB R0,@>83D4          * SAVE VR1'S NEW VALUE IN INTERPRETER WORKSPACE
       LI   R0,>01A0           * INITIALIZE VR1 WITH SCREEN BLANKED
       BLWP @VWTR
       LI   R0,>206            * SIT ADDRESS AT >1800
       BLWP @VWTR
       LI   R0,>403            * PDT ADDRESS AT >0000
       BLWP @VWTR   
       LI   R0,>3FF            * CT ADDRESS AT >2000
       BLWP @VWTR
       LI   R0,>0536           * SPRITE ATTRIBUTE LIST ADDRESS >1B00
       BLWP @VWTR
       LI   R0,>1B00           * MARK START OF SPRITE TABLE AS INVALID
       LI   R1,>D000
       BLWP @VSBW
       LI   R0,>1800           * INITIALIZE THE SIT
       CLR  R1
       LI   R2,3
SITINI BLWP @VSBW
       INC  R0
       AI   R1,>100
       JNE  SITINI
       DEC  R2
       JNE  SITINI
       LI   R0,>1B02           * VDP ADDRESS OF PABP
       LI   R1,PABP            
       LI   R2,19
       BLWP @VMBW              * TRANSFER PATTERN DATA PAB TO VDP
       LI   R6,>1B0B           * POINT TO FILE DESCRIPTIOR IN PAB
       MOV  R6,@>8356           * REQUIRED BY DSR
       BLWP @DSRLNK            * LOAD PATTERN DATA INTO PDT
       DATA 8
       LI   R0,>1C00           * VDP ADDRESS OF PABC
       LI   R1,PABC
       LI   R2,19
       BLWP @VMBW              * TRANSFER COLOR DATA PAB TO PDT
       LI   R6,>1C09           * POINT TO FILE DESCRIPTOR IN PAB
       MOV  R6,@>8356
       BLWP @DSRLNK            * LOAD COLOR DATA INTO CT
       DATA 8
       LI   R0,2
       BLWP @VWTR              * START BITMAP MODE
       MOVB R0,@>83D4
       LI   R0,>01E0
       BLWP @VWTR              * TURN SCREEN ON
       
SCAN   CLR  @GPLSTS            * WAIT FOR KEYPRESS
       BLWP @KSCAN
       LIMI 2
       LIMI 0
       CB   @ANYKEY,@GPLSTS
       JNE  SCAN   
	   
       CLR  R0                 * RESTORE GRAPHICS MODE
       BLWP @VWTR
       LI   R0,>E000
       MOVB R0,@>83D4          
       LI   R0,>01E0
       BLWP @VWTR
       LI   R0,>0203
       BLWP @VWTR
       LI   R0,>0320
       BLWP @VWTR
       LI   R0,>0400
       BLWP @VWTR
       LI   R0,>0506
       BLWP @VWTR
       LI   R0,>0600
       BLWP @VWTR
       LI   R0,>0717
       BLWP @VWTR	   
	   
       LI R0,>0370             * RESTORE XB CURSOR AND EDGE CHARACTER
       LI R1,BUF1
       LI R2,80
       BLWP @VMBW
	   
       MOV  @>8370,R0          * RESTORE DISK BUFFER SPACE
       LI   R1,BUF2
       LI   R2,16
       BLWP @VMBW

       CLR  @FAC               * RESTORE CHARACTER SET   
       BLWP @GPLLNK
       DATA >16

       LWPI >83E0              * RETURN TO XB
       B    @>006A             

*****************************
* FROM THE SMART PROGRAMMER *
*****************************
  
* GPLLNK AND DSRLNK

GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1 MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00
       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

       END

Here are the 2 XB programs for testing:

1 REM PROGRAM TEST1
10 CALL CLEAR
20 CALL INIT
30 CALL LOAD("DSK1.XBBMP")
40 CALL LINK("SPLASH")
50 RUN "DSK1.TEST2"
1 REM PROGRAM TEST2
10 CALL CLEAR
20 PRINT "UPPER AND lower case!"
30 DISPLAY AT(1,1)BEEP:"THIS IS A TEST"
40 GOTO 40

It appears that GPLLNK >16 loads both the upper and lower case characters all in one shot.

What am I missing???

Image.zip

  • Like 1
Link to comment
Share on other sites

One more piece of information. After returning to XB but before running the chained program, any CALL functions result in the error SUBPROGRAM NOT FOUND, like CALL CLEAR or CALL CHARSET for example. Clearly the XB environment is not quite restored yet but I don't know where the issue might be unfortunately.

  • Like 1
Link to comment
Share on other sites

In the Zoom meeting, you showed CALL LOAD running out of memory. You hypothesized that a 2nd CALL INIT doesn't free up the memory from before. 

 

The E/A manual p. 274 describes the E/A module and TI BASIC environment. Here CALL INIT wipes out the previous program (not actually zeroing it out).

 

The XB manual gives the same claim on p.101.

 

 

Here are the free memory pointers I was thinking of.

On p 263 the E/A manual. More goodies from UTLTAB on page 265.

 From the E/A environment:

       REF UTLTAB

FSTHI  EQU UTLTAB+2
LSTHI  EQU UTLTAB+4
FSTLOW EQU UTLTAB+6
LSTLOW EQU UTLTAB+8

 

From extended Basic I don't recall if they work at all the same. For starters there is no UTLTAB equate.

These pointers *must* exist somewhere, for the loader to work at all.

 

I seem to recall the first free address in low memory is a little past >24E0, definitely before >2500 (I used CALL LOAD(9472,X) or >2500 as an argument passing area.)

 

 

 

 

 

 

 

Link to comment
Share on other sites

This relates to the Pattern Definition Table areas loaded by GPLLNK routines >16, >18 and >4A located in GROM 0. This is information from several sources (Heiner Martin, E/A Manual and Thierry’s site).

  • >16  (“Standard Character Set”—Characters used on title screen)
    • Copies 512 pattern bytes for ASCII 32 ( ) – 95 (_).
    • These characters use all 8 dot rows so there is no inter-row space.
  • >18  (“Small Capital Character Set”—Characters used in both Graphics and Text modes)
    • Copies 512 pattern bytes for ASCII 32 ( ) – 95 (_).
    • The first dot row of each character is >00, which provides the inter-line space.
  • >4A  (“Lower Case Character Set”, actually, very small caps—Characters used in both Graphics and Text modes)
    • Copies 248 pattern bytes for ASCII 96 (`) – ASCII 126 (~).
    • The first dot row of each character is >00, which provides the inter-line space.

For XB:

  • Routine >18 (or >16, if you insist) should find >0400 in FAC. >0400 is the start of the pattern for <space>.
  • Routine >4A should find >0600 in FAC. >0600 is the start of the pattern for <back tick>, i.e., (`).
  • The Sprite Attribute Table starts at >0300. Store >D0 at >0300 to disable all sprites.

...lee

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

You have moved the goalposts. From your first post:

"The launch program will really only consist of the usual CALL INIT, CALL LOAD AND CALL LINK to access an ML program in low memory, and ends with a RUN command to chain another standard XB program."

What I described will to that.

From your post #20:

"After returning to XB but before running the chained program, any CALL functions result in the error SUBPROGRAM NOT FOUND, like CALL CLEAR or CALL CHARSET for example. Clearly the XB environment is not quite restored yet but I don't know where the issue might be unfortunately."

Now you are trying to do more than simply CALL LINK("BITMAP")::RUN "DSK1.PROGRAM2"

You cannot trash the vdp ram with bit mapped graphics and then expect the program to pick up where it left off. You can get away with RUN because the XB program is in CPU ram and when it runs it will reset most of the data in the VDP ram. The solution is simple: put the CALLs in the new program.

 

Follow Lee's advice on how to use GPLLNK to load the character patterns. You also need to load the cursor pattern and edge character to >03F0. The cursor and edge pattern is: >007C,>7C7C,>7C7C,>7C7C,>0000,>0000,>0000,>0000

The 80 bytes at >0370 have nothing to do with the cursor. That is the XB system area which has pointers needed by XB.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Thank you all, both those who responded here or on the Zoom call last night (that was fun ?). I combined all the input and advice received and finally managed to get it all working perfectly. Below is the ALC program. To recap, the steps needed to go into bitmap from XB and back are as follows:

  • Save the XB system area (80 bytes) at >0370
  • Save the disk buffer space (16 bytes) pointed to by >8370
  • Save the color table (32 bytes) at >800
  • Save the sprite attribute list (128 bytes) at >300. I tried putting a >D0 at >300 when trying to go back to XB, but I was still getting sprite screen corruption with the chained XB program. Not sure why. So saving and later restoring the SAL was the safest way to do it.
  • Go into bitmap and do stuff
  • Restore graphics mode with VDP registers 0-7 
  • Restore the color table back to >800
  • Restore the sprite attribute list back to >300
  • Restore the XB system area back to >0370
  • Restore the cursor and edge characters (>007C,>7C7C,>7C7C,>7C7C,>0000,>0000,>0000,>0000) to >03F0
  • Restore the disk buffer space back to the address pointed by >8370
  • Restore the upper case characters (32 - 95) using GPLLNK >18 with >400 in the FAC
  • Restore the lower case characters (96 - 126) using GPLLNK >4A with >0600 in the FAC
  • Return to XB with LWPI >83E0 and B @>006A
* Bitmap splash image display from XB

       DEF  SPLASH
VWTR   EQU  >2030
VMBW   EQU  >2024
VSBW   EQU  >2020
VMBR   EQU  >202C
KSCAN  EQU  >201C           
GPLSTS EQU  >837C
FAC    EQU  >834A
       
PABC   DATA >0500,>2000,>0000,>1800,>0009
       TEXT 'DSK1.KP_C'
       EVEN
PABP   DATA >0500,>0000,>0000,>1800,>0009
       TEXT 'DSK1.KP_P'
       EVEN
BUF1   BSS  80
BUF2   BSS  16
BUF3   BSS  32
BUF4   BSS  128
ANYKEY BYTE >20
CURSOR DATA >007C,>7C7C,>7C7C,>7C7C,>0000
       DATA >0000,>0000,>0000
       EVEN

SPLASH LI R0,>0370             * SAVE XB SYSTEM AREA
       LI R1,BUF1
       LI R2,80
       BLWP @VMBR
	   
       MOV  @>8370,R0          * SAVE DISK BUFFER SPACE
       LI   R1,BUF2
       LI   R2,16
       BLWP @VMBR   
	   
       LI   R0,>800            * SAVE COLOR TABLE
       LI   R1,BUF3
       LI   R2,32
       BLWP @VMBR
	   
       LI   R0,>300            * SAVE SPRITE ATTRIBUTE LIST
       LI   R1,BUF4
       LI   R2,128
       BLWP @VMBR
	   
       LI   R0,>A000
       MOVB R0,@>83D4          * SAVE VR1'S NEW VALUE IN INTERPRETER WORKSPACE
       LI   R0,>01A0           * INITIALIZE VR1 WITH SCREEN BLANKED
       BLWP @VWTR
       LI   R0,>206            * SIT ADDRESS AT >1800
       BLWP @VWTR
       LI   R0,>403            * PDT ADDRESS AT >0000
       BLWP @VWTR   
       LI   R0,>3FF            * CT ADDRESS AT >2000
       BLWP @VWTR
       LI   R0,>0536           * SPRITE ATTRIBUTE LIST ADDRESS >1B00
       BLWP @VWTR
       LI   R0,>1B00           * MARK START OF SPRITE TABLE AS INVALID
       LI   R1,>D000
       BLWP @VSBW
       LI   R0,>1800           * INITIALIZE THE SIT
       CLR  R1
       LI   R2,3
SITINI BLWP @VSBW
       INC  R0
       AI   R1,>100
       JNE  SITINI
       DEC  R2
       JNE  SITINI
       LI   R0,>1B02           * VDP ADDRESS OF PABP
       LI   R1,PABP            
       LI   R2,19
       BLWP @VMBW              * TRANSFER PATTERN DATA PAB TO VDP
       LI   R6,>1B0B           * POINT TO FILE DESCRIPTIOR IN PAB
       MOV  R6,@>8356           * REQUIRED BY DSR
       BLWP @DSRLNK            * LOAD PATTERN DATA INTO PDT
       DATA 8
       LI   R0,>1C00           * VDP ADDRESS OF PABC
       LI   R1,PABC
       LI   R2,19
       BLWP @VMBW              * TRANSFER COLOR DATA PAB TO PDT
       LI   R6,>1C09           * POINT TO FILE DESCRIPTOR IN PAB
       MOV  R6,@>8356
       BLWP @DSRLNK            * LOAD COLOR DATA INTO CT
       DATA 8
       LI   R0,2               * START BITMAP MODE
       BLWP @VWTR 
       LI   R0,>E000	   
       MOVB R0,@>83D4
       LI   R0,>01E0
       BLWP @VWTR              * TURN SCREEN ON
       
SCAN   CLR  @GPLSTS            * WAIT FOR KEYPRESS
       BLWP @KSCAN
       LIMI 2
       LIMI 0
       CB   @ANYKEY,@GPLSTS
       JNE  SCAN     
	   
       CLR  R0                 * RESTORE GRAPHICS MODE
       BLWP @VWTR
       LI   R0,>0200
       BLWP @VWTR
       LI   R0,>0320
       BLWP @VWTR
       LI   R0,>0400
       BLWP @VWTR
       LI   R0,>0506
       BLWP @VWTR
       LI   R0,>0600
       BLWP @VWTR
       LI   R0,>0707
       BLWP @VWTR	  

       LI   R0,>800            * RESTORE COLOR TABLE 
       LI   R1,BUF3
       LI   R2,32
       BLWP @VMBW	   
	   
       LI R0,>0370             * RESTORE XB SYSTEM AREA
       LI R1,BUF1
       LI R2,80
       BLWP @VMBW
	   
       MOV  @>8370,R0          * RESTORE DISK BUFFER SPACE
       LI   R1,BUF2
       LI   R2,16
       BLWP @VMBW

       LI   R0,>400            * RESTORE UPPER CHARACTER SET
       MOV  R0,@FAC               
       BLWP @GPLLNK
       DATA >18
	   
       LI   R0,>0600           * RESTORE LOWER CHARACTER SET
       MOV  R0,@FAC               
       BLWP @GPLLNK
       DATA >4A
	   
       LI   R0,>3F0            * RESTORE CURSOR AND EDGE CHARACTERS
       LI   R1,CURSOR
       LI   R2,16
       BLWP @VMBW
	   
       LI   R0,>300            * RESTORE SPRITE ATTRIBUTE LIST
       LI   R1,BUF4
       LI   R2,128
       BLWP @VMBW

       LWPI >83E0              * RETURN TO XB
       B    @>006A             

*****************************
* FROM THE SMART PROGRAMMER *
*****************************
  
* GPLLNK AND DSRLNK

GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1 MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00
       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

       END

As senior_falcon pointed out, nothing should be done with XB upon return from bitmap mode except running another XB program. No need for any special commands for the chained program as everything is taken care of by the ALC routine. This routine works with standard XB and XB GEM 2.8. Should also work with other flavors of XB.

That said, I would be curious to know what would be needed to be able to *completely* restore the XB environment upon return from bitmap so that one could continue using XB without chaining another program.

Edited by Vorticon
  • Like 1
Link to comment
Share on other sites

12 hours ago, FarmerPotato said:

In the Zoom meeting, you showed CALL LOAD running out of memory. You hypothesized that a 2nd CALL INIT doesn't free up the memory from before. 

 

The E/A manual p. 274 describes the E/A module and TI BASIC environment. Here CALL INIT wipes out the previous program (not actually zeroing it out).

 

The XB manual gives the same claim on p.101.

 

 

Here are the free memory pointers I was thinking of.

On p 263 the E/A manual. More goodies from UTLTAB on page 265.

 From the E/A environment:


       REF UTLTAB

FSTHI  EQU UTLTAB+2
LSTHI  EQU UTLTAB+4
FSTLOW EQU UTLTAB+6
LSTLOW EQU UTLTAB+8

 

From extended Basic I don't recall if they work at all the same. For starters there is no UTLTAB equate.

These pointers *must* exist somewhere, for the loader to work at all.

 

I seem to recall the first free address in low memory is a little past >24E0, definitely before >2500 (I used CALL LOAD(9472,X) or >2500 as an argument passing area.)

It actually turned out that I had taken out the CALL INIT from the chained program while testing and forgot to put it back in. Problem solved and it appears to be as you said that CALL INIT does indeed wipe out the previous ALC program in low expansion memory.

In the TI XB ALC Programmer's Guide, the First Free Address is  at >2002 and the Last Free Address is at >2004. FYI. This could come in handy.

Edited by Vorticon
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...