Opry99er Posted March 3, 2017 Share Posted March 3, 2017 I know seniorfalcon and Tursi have talked about things like this in the past, but I cannot find the threads. I want to know what memory locations are 'safe' from XB in either the 24k or the 8k blocks. Perhaps I should explain a bit about what I want to do first, so that I am not asking ambiguous questions. -Let's assume we only have a 32k in our PEB and no disk system. -Say I had a custom cartridge with some cool assembly routines on it that I wanted to load into the 32k RAM for use with XB. Normally I would be able to LOAD from disk and LINK to the routines in the 32k space via XB, but in this scenario, we do not have a disk system. -So we put the routines into a cartridge with the intention of copying them to 32k--and then do so. -Then, we shut off the console, leaving the 32k powered up. -Next, we insert the XB cartridge and re-power the machine. -At this point, the routines are already loaded into the 32k, and I want to LINK to them so they will be usable in the XB program. Alright... that's the scenario. My question is: What memory addresses in 32k would be 'safe' for this type of application, and would it be possible to LINK to the routines without a preceding LOAD? The XB manual states that when you do a CALL INIT, it clears the 32k of any subprograms that exist there. It also loads a set of support routines into the 32k memory expansion which allow the use of LOAD and LINK. Would it be possible to manually INIT the system from the hypothetical custom cartridge so that it would already have the necessary support routines in place to allow XB to access assembly subprograms? If so, we would not necessarily have to have CALL INIT in the program (which would immediately erradicate our custom routines) I know all this sounds wonky, but I have a reason for asking. Thanks in advance 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 3, 2017 Share Posted March 3, 2017 No Tursi on this one, XB stuff requires SeniorFalcon or Rich. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 3, 2017 Share Posted March 3, 2017 (edited) I know seniorfalcon and Tursi have talked about things like this in the past, but I cannot find the threads. I want to know what memory locations are 'safe' from XB in either the 24k or the 8k blocks. Perhaps I should explain a bit about what I want to do first, so that I am not asking ambiguous questions. -Let's assume we only have a 32k in our PEB and no disk system. -Say I had a custom cartridge with some cool assembly routines on it that I wanted to load into the 32k RAM for use with XB. Normally I would be able to LOAD from disk and LINK to the routines in the 32k space via XB, but in this scenario, we do not have a disk system. -So we put the routines into a cartridge with the intention of copying them to 32k--and then do so. -Then, we shut off the console, leaving the 32k powered up. -Next, we insert the XB cartridge and re-power the machine. -At this point, the routines are already loaded into the 32k, and I want to LINK to them so they will be usable in the XB program. Alright... that's the scenario. My question is: What memory addresses in 32k would be 'safe' for this type of application, and would it be possible to LINK to the routines without a preceding LOAD? The XB manual states that when you do a CALL INIT, it clears the 32k of any subprograms that exist there. It also loads a set of support routines into the 32k memory expansion which allow the use of LOAD and LINK. Would it be possible to manually INIT the system from the hypothetical custom cartridge so that it would already have the necessary support routines in place to allow XB to access assembly subprograms? If so, we would not necessarily have to have CALL INIT in the program (which would immediately erradicate our custom routines) I know all this sounds wonky, but I have a reason for asking. Thanks in advance Hmm all you are looking for is done in my game for RXB called "IN THE DARK" Look at the routine source in text SSPEEDUP TITL 'ENEMY ROUTINES' AORG >D000 WRKSPC EQU $ DATA 0 R0 FOOD:TRAPS RX DATA 0 R1 RXB X NX DATA 0 R2 NEW X DATA 0 R3 RXB U DATA 0 R4 SAVED U POSITION 3 DATA 0 R5 DATA 0 R6 VALUE TO CHECK 225,226,227 DATA 0 R7 INCREMENT VALUE 32 DATA 0 R8 INCREMENT VALUE 1 DATA 0 R9 DATA 0 R10 POSITIONS DATA 0 R11 1 2 3 DATA 0 R12 4 5 6 DATA 0 R13 7 8 9 DATA 0 R14 DATA 0 R15 DATA WRKSPC DATA SRCH SRCH LI R6,>C700 199 UNARMED TRAP LI R7,32 UP & DOWN LI R8,>0100 1 CHAR NUMBER SRCHL MOV R1,R2 POSITION 5 S R7,R2 POSITION 2 CB *R2,R6 EQUAL? JEQ CNG REPLACE DEC R2 POSITION 1 CB *R2,R6 EQUAL? JEQ CNG REPLACE A R7,R2 POSITION 4 CB *R2,R6 EQUAL? JEQ CNG REPLACE A R7,R2 POSITION 7 CB *R2,R6 EQUAL? JEQ CNG REPLACE INC R2 POSITION 8 CB *R2,R6 EQUAL? JEQ CNG REPLACE INC R2 POSITION 9 CB *R2,R6 EQUAL? JEQ CNG REPLACE S R7,R2 POSITION 6 CB *R2,R6 EQUAL? JEQ CNG REPLACE S R7,R2 POSITION 3 CB *R2,R6 EQUAL? JEQ CNG REPLACE CI R6,>CF00 FOOD? JEQ HV FIND A MOVE LI R6,>CF00 FOOD 207 JMP SRCHL SEARCH LOOP CNG CI R6,>C700 199 UNARMED TRAP JNE CNGF NO HAS TO BE FOOD LI R6,>DA00 218 REARM THE TRAP MOVB R6,*R2 REPLACE WITH TRAP RTWP RETURN DELAY CNGF LI R6,>8000 SPACE MOVB R6,*R2 REPLACE WITH SPACE HV LI R6,>E100 VALUES 225 226 227 HVANG MOV R1,R2 POSITION 5 DEC R2 POSITION 4 CB *R2,R6 EQUAL? JEQ GOUT YES A R7,R2 POSITION 7 CB *R2,R6 EQUAL? JEQ GOUT YES INC R2 POSITION 8 CB *R2,R6 EQUAL? JEQ GOUT YES INC R2 POSITION 9 CB *R2,R6 EQUAL? JEQ GOUT YES S R7,R2 POSITION 6 CB *R2,R6 EQUAL? JEQ GOUT YES S R7,R2 POSITION 3 CB *R2,R6 EQUAL? JEQ GOUT YES DEC R2 POSITION 2 CB *R2,R6 EQUAL? JEQ GOUT YES DEC R2 POSITION 1 CB *R2,R6 EQUAL? JEQ GOUT YES AB R8,R6 ADD 1 CI R6,>E400 228? JEQ TRAIL FIND A TRAIL JMP HVANG LOOP TRAIL LI R6,>E100 TRAIL? TRAIL2 LI R1,>2022 START OVER!!!! FIND INC R1 ADD 1 TO COLUMN CI R1,>3FDD END OF 8K? JNE FIND1 AB R8,R6 CI R6,>E400 228? JEQ GOUT3 JMP FIND FIND1 CB *R1,R6 225? 226? 227? JEQ HV RESTART HERE!!! JMP FIND NO KEEP LOOKING GOUT LI R6,>E100 225 GOUT1 CB *R1,R6 EQUAL? JEQ GOUT2 YES AB R8,R6 ADD 1 TO CHARACTER CI R6,>E300 227? JNE GOUT1 NEXT CHECK LI R6,>7F00 SET UP FOR SPACE GOUT2 AB R8,R6 ADD 1 TO CHARACTER MOVB R6,*R1 UPDATE OLD CHARATER MOV R2,R1 PUT NEW X IN OLD X GOUT3 RTWP DONE GO BACK TO RXB TITL 'FEEL AROUND ROUTINES' DATA WRKSPC DATA FEEL FEEL CLR R0 FOOD:TRAP LI R7,32 UP & DOWN MOV R3,R4 POSITION 5 S R7,R4 POSITION 2 INC R4 POSITION 3 SAVED FEEL1 LI R6,>DA00 218 TRAP BL @FCHK CHECK C R4,R2 POSITION 3? JNE FEEL1 LOOP FEEL2 LI R6,>D700 215 WALL BL @FCHK CHECK C R4,R2 POSITION 3? JNE FEEL2 LOOP FEEL3 LI R6,>CF00 207 FOOD BL @FCHK CHECK C R4,R2 POSITION 3? JNE FEEL3 LOOP RTWP RETURN TO RXB FCHK MOV R3,R2 POSITION 5 S R7,R2 POSITION 2 CB *R2,R6 SAME? JEQ FLIP REPLACE DEC R2 POSITION 1 CB *R2,R6 SAME? JEQ FLIP REPLACE A R7,R2 POSITION 4 CB *R2,R6 SAME? JEQ FLIP REPLACE A R7,R2 POSITION 7 CB *R2,R6 SAME? JEQ FLIP REPLACE INC R2 POSITION 8 CB *R2,R6 SAME? JEQ FLIP REPLACE INC R2 POSITION 9 CB *R2,R6 SAME? JEQ FLIP REPLACE S R7,R2 POSITION 6 CB *R2,R6 SAME? JEQ FLIP REPLACE S R7,R2 POSITION 3 CB *R2,R6 SAME? JEQ FLIP REPLACE RT RETURN FLIP CI R6,>DA00 218 TRAP JNE FLIP1 NEXT LI R8,>C700 199 DISARMED INC R0 ADD 1 TRAP JMP FLIP3 REPLACE FLIP1 CI R6,>D700 215 WALL JNE FLIP2 NEXT LI R8,>EF00 239 SHOW WALL JMP FLIP3 REPLACE FLIP2 CI R6,>CF00 207 FOOD JNE FLIP4 DONE LI R8,>8000 129 SPACE AI R0,>0100 ADD 1 FOOD FLIP3 MOVB R8,*R2 REPLACE IT FLIP4 RT RETURN END Now I put it at >D000 but you can change the that location to some other place. I only picked >D000 as it was well away from my XB Program size and also as I was using SAMS >2000 already for Storage instead of Assembly support. You could even after XB starts change the RAMTOP location from >A000 to >B000 but in XB this a problem as CALL INIT wipes out anything loaded in Lower 8K. This is not a problem in RXB as with RXB you do not need to do a CALL INIT to use CALL LOAD like you are forced to do so in normal XB. Also here is a video that explains the Nomal Extended Basic BUG in the XB Cart and how RXB fixed this bug, and yes IT IS A BUG! INTHEDARK.zip Edited March 3, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 3, 2017 Share Posted March 3, 2017 (edited) XB and 32k (what is 'safe'?) -Let's assume we only have a 32k in our PEB and no disk system. -Then, we shut off the console, leaving the 32k powered up. -Next, we insert the XB cartridge and re-power the machine. -At this point, the routines are already loaded into the 32k, and I want to LINK to them so they will be usable in the XB program. When you have inserted the XB cartridge, do you plan to type in or load XB program from tape then (no disk system) ? Assembly routines can be embedded in XB programs, Tursi showed me how to somewhere here on AtariAge. You have to take care though, but if you're already dealing with assembly, then this is what you have to anyway - and luckily practice makes master ... Edited March 3, 2017 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2017 Author Share Posted March 3, 2017 Thank you guys for your responses. @Rich: thank you for the info! What about the high memory? Does INIT wipe that out too @Karsten: Loading from tape was the plan. Can SYSTEX-embedded XB code be loaded from tape, or Does it need to be loaded from diskette? Quote Link to comment Share on other sites More sharing options...
RXB Posted March 3, 2017 Share Posted March 3, 2017 (edited) Thank you guys for your responses. @Rich: thank you for the info! What about the high memory? Does INIT wipe that out too @Karsten: Loading from tape was the plan. Can SYSTEX-embedded XB code be loaded from tape, or Does it need to be loaded from diskette? Ok should have mentioned a couple of things. 1. If you load a Assembly Program in upper 24K and restart XB nothing in memory changes except the pointers at >FFE7 to >FFD2 are initialized for XB use. 2. XB CALL INIIT only changes the lower 8K where it loads Assembly Support, also it wipes out the name tags for your CALL LINK's. ( Using RXB you would not have this problem of restarting XB and using CALL LOAD as my previous video showed this BUG is repaired.) 3. Tape as far as I know loads into VDP and if the program is two large it moves it into upper 24K. Of course the format it was saved in determines that. Example: SAVE CS1.IV254 in RXB will automatically make this a IV254 file on Tape or Disk or Hard Disk or any device. 4. I have no idea if SYSTEX would work or not on Tape. Edited March 3, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 3, 2017 Author Share Posted March 3, 2017 On #2: So even if the routines are in high memory, the name tables are necessarily in the lower 8? This would make the use of vanilla XB impossible for this application. I need to speak with Harry, as he has done some incredible things with embedded assembly. Perhaps tape is a possibility. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 4, 2017 Share Posted March 4, 2017 (edited) On #2: So even if the routines are in high memory, the name tables are necessarily in the lower 8? This would make the use of vanilla XB impossible for this application. I need to speak with Harry, as he has done some incredible things with embedded assembly. Perhaps tape is a possibility. Sorry no! Let me clarify this, when you do a CALL INIT XB reloads the Assembly suppport and resets the pointers for lower 8K, thus wipes out any names for CALL LINKS. This has zero effects on the upper 24K of RAM. So like I said if you had run a XB program from Tape or Disk into Upper 24K with Assembly support and restart XB having used SYSTEX any lower 8K is fine. UNLESS you do a CALL INIT the lower 8K remains unchanged, but in NORMAL XB IT IS IMPOSSIBLE TO DO A CALL LOAD WITHOUT A CALL INIT, THUS WIPES OUT LOWER 8K PROGRAMS LOADED. (But you could then use CALL LOAD to repair the damage.) So the steps you need are: 1. OLD CS1 or OLD DSK#.UR-PGM 2. EXIT XB and back to title screen 3. After XB fails at DSK1.LOAD type CALL INIT, and if you never did this previously lower 8K is fine. OR 3. OLD CS1 or OLD DSK#.UR-NXT-PGM that loads lower 8k and XB program. (Careful to not over write upper Assembly already loaded) 4. RUN program Edited March 4, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted March 4, 2017 Share Posted March 4, 2017 ... But you could then use CALL LOAD to repair the damage. ... Not really. The links to the previously loaded ALC are still not there—and, never were. The only way I see to get links to your ALC routines is to CALL INIT and manually update the link table with the links you need to your ALC. Surely the link table parameters are known. I will see what I can dig up. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted March 4, 2017 Share Posted March 4, 2017 (edited) Not really. The links to the previously loaded ALC are still not there—and, never were. The only way I see to get links to your ALC routines is to CALL INIT and manually update the link table with the links you need to your ALC. Surely the link table parameters are known. I will see what I can dig up. ...lee Hmm actually if you know the Assembly and locations you could use CALL LOAD to poke those values in the link table. I have done this and it is troublesome but doable. If you restart XB and do not do a CALL INIT in RXB you can use CALL LOAD to do this, but then that is really a stupid BUG in XB as my Video proved in the previous post. Edited March 4, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 5, 2017 Share Posted March 5, 2017 Loading from tape was the plan. Can SYSTEX-embedded XB code be loaded from tape, or Does it need to be loaded from diskette? I would think so. Tursi explains how to embed assembly in XB here. Go and read from "How does it work??. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 5, 2017 Author Share Posted March 5, 2017 I KNEW Tursi had done work on this before... Thanks for the link. I have some ideas now. THANKS!! 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted March 5, 2017 Share Posted March 5, 2017 ... Alright... that's the scenario. My question is: What memory addresses in 32k would be 'safe' for this type of application, and would it be possible to LINK to the routines without a preceding LOAD? ... Back to your original plan, Owen— Per The Smart Programmer, March, 1984, after CALL INIT has loaded the ALC support into low expansion (LX) RAM from the XB cartridge, >2002 contains the LFA (lowest free address) in LX RAM and >2004, the HFA (highest free address) in LX RAM. The HFA is also the top of the REF/DEF table, which grows down 8 bytes at a time. Before any ALC routines are loaded, the LFA = >24F4 and the HFA = >4000, i.e., no ALC references in the REF/DEF table. I don't believe that CALL INIT clears LX RAM, it simply loads the ALC routines and resets the pointers. I am not even sure that the console powerdown/powerup cycle clears it. If you really want to load your routines into LX RAM, you would need to check this. In any event, you should write the ALC routines with the AORG directive so that you know where to load them. If it transpires that you can load them in LX RAM and that is where you need them, you should probably update the LFA to the first free byte (even boundary) after getting back to XB. Loading in HX RAM is on you—there is no HX LFA. After loading your ALC routines and starting XB, issue a CALL INIT and copy your entries to the REF/DEF table. Then update the HFA (>2004) to the address of the top of the table (lowest address). This could likely all be done with a small XB program, which could finish by clearing itself from RAM. Let's say you have a set of ALC routines that are AORGed to >A000 with entry points SUB1 = >A000, SUB2 = >A100, SUB3 = >A310. These three entries can be in any order: LX RAM Routine Entry Address Name Address ------- ------- ------- >3FF8 SUB3 >A310 >3FF0 SUB2 >A100 >3FE8 SUB1 >A000 >2004 >3FE8 You would need to load these with one or more CALLs to LOAD() as a string of decimal bytes: 100 CALL INIT 110 CALL LOAD(16360,83,85,66,49,32,32,160,0,83,85,66,50,32,32,161,0,83,85,66,51,32,32,163,16,"",8196,63,232) RUN NEW ...lee Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 5, 2017 Author Share Posted March 5, 2017 Neat... I am trying to teach myself the memory map. I follow, but I have to reference the memory locations each time because I do not know them by heart yet. I really appreciate all the help, guys. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 5, 2017 Share Posted March 5, 2017 (edited) I don't believe that CALL INIT clears LX RAM, it simply loads the ALC routines and resets the pointers. I am not even sure that the console powerdown/powerup cycle clears it. ...lee No XB does not change anything in Lower 8K on power down of Console and Lee is correct it only loads the XB Assembly Support. Also it has no effects on Upper 24K other then I mentioned before it reset the pointer at >FFE7 to >FFD2 indicating free space for XB to use. And Lee also explained exactly what I said about using CALL INIT than CALL LOAD to load a new LINK Table and change pointers. Edited March 5, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 5, 2017 Author Share Posted March 5, 2017 So I need to write a test program in XB, load an AL routine as described, and try to save it to tape. Will be cool if it works. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 8, 2017 Share Posted March 8, 2017 Back from vacation, so I can give some thought to what you want to do. I am still not quite sure what you want to do. As I understand this, using Extended BASIC you want to run a program that uses assembly support. You have 32K memory expansion but no disk drive. With no disk drive or ramdisk I can only see 3 ways to get the program loaded into the TI: 1 - type it in. 2 - load it from tape 3 - load it somehow from a custom cartridge that also contains XB Am I missing anything? How large will the program be? Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 8, 2017 Author Share Posted March 8, 2017 PM sent, Falcon. Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted March 8, 2017 Share Posted March 8, 2017 3 - load it somehow from a custom cartridge that also contains XB I think Gazoo used to do that sort of thing with the XB2.7S cartridge, one example was the Bert & Ernie easter egg. I'm wondering if that sort of thing will be possible when the FinalGROM 99 comes out. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 8, 2017 Author Share Posted March 8, 2017 I think Gazoo used to do that sort of thing with the XB2.7S cartridge, one example was the Bert & Ernie easter egg.. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.