I've done an example with the "Sprite Plotter with Movement" project from the Wiki. This initially loaded the code at $1900 and ran it from there. I've now written it so that the code is loaded at 1900 and relocated down to E00.
I'll explain some of the details in a minute but first why are you building at 0F00 if you want to relocate down to 900 from 1100 ? Also be careful about loading in at $1100, is this above the disk input buffer workspace ? If not you'll have problems. The disk interface on a model B uses memory from E00 to $18FF. But a lot of this space is buffers and you can obviously use the output buffers if your only reading from disk. I can't remember the specific addresses off hand but if it's all output type stuff above 1FFF you should be fine.
Ok, that aside here's what I've done to my example to make it work on a model B even though the code runs from E00.
First I changed the .org statement in my single block of code from
.org 1900
to
.org E00
As it is eventually going to be in that location when executed, so the assembler needs to assemble to that position. This is in the file "SpritePlotter".
I then created a additional project item called "Relocate". This has it's org set to $880 (The printer buffer). It's this code that will relocate the code and call the start of it.
The boot file was altered to this;
Code:
OSCLI "LOAD MASK 900"
COLOUR 128 : REM Change to any background colour you wish (values from 128 to 135)
OSCLI "LOAD SpriteP 1900"
OSCLI "RUN Reloc"
So the changes were to Load the main program"SpriteP" (not to run it) at address $1900 (above disk workspace). Even though this code has been assembled to run from E00. Then we load and run the relocation routine. This consists of the following code;
Code:
.org $880 ; printer buffer
Main:
; we have loaded the code at 1900 but it's been assembled to run from E00, so just copy
; the code from 1900 down to E00. We know it's length of the block we've loaded as Swift
; will tell you this from the properties of the "SpritePlotter" source file. You can
; also find it out by examining the disk image created.
.alias LastAddress $1900+1713 ; 1713 is the size of our code,just setting address
; that we stop copying at when we reach it.
CopyFrom:
lda $1900
CopyTo:
sta $E00
inc CopyFrom+1 ; lo byte
bne NoCarry ; Not gone to zero, so effectively no carry
; If we get here however....
inc CopyFrom+2 ; add in the effective carry (note we use BEQ above to
; detect for rolling over from 255 to 0 as the command
; INC does not effect the carry flag.
NoCarry:
; we now do the same increment for the copyto position
inc CopyTo+1 ; lo byte
bne NoCarry2 ; Not gone to zero, so effectively no carry
; If we get here however....
inc CopyTo+2 ; add in the effective carry (note we use BEQ above to
; detect for rolling over from 255 to 0 as the command
; INC does not effect the carry flag.
NoCarry2:
; now wecheck if we've copied all the bytes
lda CopyFrom+2 ; check hi byte first
cmp #>LastAddress
BNE CopyFrom ; Go back to start of loop if not equal
; high byte is equal, check lo byte
lda CopyFrom+1
cmp #<LastAddress
BNE CopyFrom ; if no equal, carry on copying
; we've finished copying all the bytes, run the code at the new address
JSR $0E74 ; start of code to run (actually you could just use a JMP here)
RTS ; and you don't really need this !
This copies all the bytes from 1900 to E00 then calls my main program code at $E74. The address to call was found out by simply looking at the label values in Swift for the label "Main" in the "SpritePlotter" source. The size of the code 1973 (decimal) was gained from the properties window of the "SpritePlotter" item. Although the code must be assembled at least once to get this information.
Rememeber that although Swift may set certain load and execution addresses you don't have to adhere to them, you can still load your code anywhere into memory that you wish by stipulating the address.
Attached is the Swift project file for this example; Note this will only load correctly into the latest version of Swift.
