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.
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!
-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 ...
@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.
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)
... 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.
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.
... 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:
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.
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?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube