+Vorticon Posted September 24, 2021 Share Posted September 24, 2021 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? Quote Link to comment Share on other sites More sharing options...
RXB Posted September 24, 2021 Share Posted September 24, 2021 Use the TML (The Missing Link) or some other utilities that do this. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 24, 2021 Author Share Posted September 24, 2021 1 hour ago, RXB said: Use the TML (The Missing Link) or some other utilities that do this. I'd rather learn how to do it. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 24, 2021 Share Posted September 24, 2021 2 hours ago, Vorticon said: I'd rather learn how to do it. Spoken like a '99er 3 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 25, 2021 Share Posted September 25, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 25, 2021 Author Share Posted September 25, 2021 (edited) 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 September 25, 2021 by Vorticon 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 25, 2021 Share Posted September 25, 2021 (edited) 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 September 25, 2021 by senior_falcon 2 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 25, 2021 Author Share Posted September 25, 2021 Thank you! I'll do some testing and see how that works out. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 25, 2021 Share Posted September 25, 2021 (edited) 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 September 25, 2021 by senior_falcon 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 25, 2021 Share Posted September 25, 2021 Yeah, @senior_falcon is your expert, not me. I never really mixed XB and assembly, to me they are separate worlds! But I did write full docs for my little program including the stuff I ran into. Offered in case it's useful but with no expectation it's correct: JustTheNotes.zip 1 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 26, 2021 Share Posted September 26, 2021 (edited) 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 September 26, 2021 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 26, 2021 Author Share Posted September 26, 2021 (edited) 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 September 26, 2021 by Vorticon Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 26, 2021 Share Posted September 26, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 26, 2021 Author Share Posted September 26, 2021 (edited) please ignore Edited September 26, 2021 by Vorticon Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted September 26, 2021 Share Posted September 26, 2021 19 minutes ago, Vorticon said: please ignore I could never ignore you, tall, dark, and brutal! 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 26, 2021 Share Posted September 26, 2021 (edited) 3 hours ago, Vorticon said: please ignore Ignoring...zzzzz but just this part.. definitely not ignoring you... ? Edited September 26, 2021 by GDMike 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 26, 2021 Author Share Posted September 26, 2021 (edited) 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 September 26, 2021 by Vorticon Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 26, 2021 Share Posted September 26, 2021 (edited) 54 minutes ago, GDMike said: Edited September 26, 2021 by GDMike Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 26, 2021 Author Share Posted September 26, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 26, 2021 Author Share Posted September 26, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted September 27, 2021 Share Posted September 27, 2021 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.) Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 27, 2021 Share Posted September 27, 2021 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 1 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 27, 2021 Share Posted September 27, 2021 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. 1 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 27, 2021 Author Share Posted September 27, 2021 (edited) 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 September 27, 2021 by Vorticon 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 27, 2021 Author Share Posted September 27, 2021 (edited) 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 September 27, 2021 by Vorticon 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.