MADS relocatable code problem

[ebiguy]

Hi,

I would like to make a resident program for SpartaDos X with MADS.
This resident program will make use of RAM in cartridges like MyIDE II or The!Cart (yet to receive !).
Most of the code will be put in SRAM of the cartridge.
A new symbol is defined so a program from the command line can call the resident software using this symbol.
I need an entry point for my resident which should be accessible anytime thus located in low RAM (and being resident)
This small code then switches bank so the SRAM of the cartridge appears at $A000
The real code is called at $A000 and when it gives back control, the original bank at $A000 is restored.

So the software has 3 parts:
The first part located at $0480 is used to check for running condition, initialize and install the resident.
The second part located at $A000 contains the real code of the software.
The third part is the entry point which stays resident in low memory make bank switching and call the code at $A000

This quite a long introduction to be sure everyone understand the technical details.

Of course I could have a source file like this

BLK Sparta $0480
; here is the init code

BLK Sparta $A000
; here is the real driver which should reside in SRAM of the cartridge and run at $A000

BLK Reloc Main *$0670 *Num:1 Mem:$00
; here is the resident part located in low memory

BLK Update Addresses
BLK Update Symbols

But this does not work because loading a block of code at $A000 is where SDX reside.
So the first idea which comes is to relocate code.
The second block should be assembled at $A000 but loaded at, say, $4000

The only syntax I know with MADS to do that is using ORG instead of BLK.
I could replace the second block header (BLK Sparta $A000) with this one

ORG $A000,$4000

Then I assemble and I get the error :
resident.fas (33) ERROR: Illegal instruction at RELOC block
The problem is that the ORG directive comes in a BLK Sparta block.
So I change the first BLK to use also an ORG directive like this

ORG $0480
; here is the init code

ORG $A000,$4000
; here is the real driver which is loaded at $4000 and relocated to $A000 by the init code

BLK Reloc Main *$0670 *Num:1 Mem:$00
; here is the resident part located in low memory

BLK Update Addresses
BLK Update Symbols

The I assemble the program without any error : Yes !
But No ! Because now the directive BLK Update Addresses does not resolve symbols like PRINTF in the two ORG blocks.

I also tried to assemble at $A000 then edit the generated binary file to hack the header of the second block and change 00 A0 into 00 40
But it does not work either.
You guessed why ? (This one is really tricky !!!)
Because SpartaDos X loads the second block at $4000 but, when updating symbols references (PRINTF,...), it tries to do so at $A000 !

Anybody knows if there is a way to have a BLK with both a RUN and a LOAD address AND having SpartaDos X resolve symbols correctly ?

For those who want to try any changes in the code, I put here a simplified version, reduced to that relocation problem only.


; compile with MADS

icl 'osequ.icl'
icl 'sdxequ.icl'
icl 'sdxsmb.icl'

RESIDENT_LOAD = $4000
RESIDENT_RUN = $A000

; ************************************************
BLK Sparta $0480
start:
ldx #0
?relocate:
jsr ?restore_original_bank
lda RESIDENT_LOAD,x
jsr ?select_resident_bank
sta RESIDENT_RUN,x
inx
bpl ?relocate
jsr ?restore_original_bank
; the resident code is relocated. exit with a msg
jsr PRINTF
.byte 'Resident installed',$9B,0
dec INSTALL
; call resident code a first time to check if OK
jsr MYSYMBOL
rts

; ************************************************
BLK Sparta RESIDENT_RUN
resident_code:
; display a message to do something !
jsr PRINTF
.byte 'From %s code',$9B,0
.word ?the_title
rts
?the_title:
.byte 'RESIDENT',0

; ************************************************
BLK Reloc Main *$0670 *Num:1 Mem:$00
;
MYSYMBOL:
jsr ?select_resident_bank
jsr resident_code
jmp ?restore_original_bank
; switch bank to make resident_code appears in left cartridge space
?select_resident_bank:
rts
; restore SDX in left cartridge space
?restore_original_bank:
rts
;
BLK Update Addresses
BLK Update Symbols
BLK Update New MYSYMBOL 'MYSYMBOL'

[flashjazzcat]

Tricky one. I'm not sure there's any facility to assemble a non-relocatable block with a relocation offset (for manual relocation after loading). Hacking the headers probably didn't work because the fixups still referred to $Axxx. Can you not just load the $A000 part from a separate file (assemble it as a headerless blob at $A000, then load the file into a transient buffer, turn off the cart, then move the code to $A000)?

[ebiguy]

Tricky one. I'm not sure there's any facility to assemble a non-relocatable block with a relocation offset (for manual relocation after loading). Hacking the headers probably didn't work because the fixups still referred to $Axxx. Can you not just load the $A000 part from a separate file (assemble it as a headerless blob at $A000, then load the file into a transient buffer, turn off the cart, then move the code to $A000)?

 

Thank you for your suggestion, FJC.

I found the sources of MADS (thank to the author(s) for providing them on the website).

So I added a second address in the BLK Sparta directive. Now I can write :

 

BLK Sparta $A000,$4000

 

When specifing a load address, the header of the block is changed and offsets in the Update Symbols bloc also uses the load address.

If anyone need this patch, I can provide it as binary (mads.exe) and sources (mads.pas)

[flashjazzcat]

Good work. Taking things into your own hands is usually the most effective way. Are you aware of MADS' proprietary relocatable format (separate to the SDX format)? How difficult do you think it would be to lift the limitation of a single relocatable block per project (for example, allowing for a fixed block, MAIN relocatable block, and EXTENDED relocatable block in the same file)?

[ebiguy]

Good work. Taking things into your own hands is usually the most effective way. Are you aware of MADS' proprietary relocatable format (separate to the SDX format)? How difficult do you think it would be to lift the limitation of a single relocatable block per project (for example, allowing for a fixed block, MAIN relocatable block, and EXTENDED relocatable block in the same file)?

Hi FJC,

I am not aware of MADS relocatable format.

I use MADS only to make drivers or resident programs for SDX.

But what is the use of this format on Atari computers ?

I mean are there any OSes or DOSes which could load such binaries ?

 

Understanding MADS.PAS source is quite difficult for me because (almost) all names and comments in the source are in Polish (I am French).

But if you provide me with a source with the syntax you would like to see supported, I can try to do it if you really need that feature.

This would be a way for me to thank you for the MYIDE2.SYS driver I use on a daily basis.

[flashjazzcat]

I am not aware of MADS relocatable format.

I use MADS only to make drivers or resident programs for SDX.

But what is the use of this format on Atari computers?

I mean are there any OSes or DOSes which could load such binaries?

I'll need to write a relocating, linking loader for the GUI. Now, the MADS proprietary relocatable format looked attractive, since it allows for things like Lo/Hi relocation ("LDA #< label", etc), and the header format is quite clearly documented, but unfortunately it's not possible to have multiple relocatable segments. This would be essential if - for example - one wanted to write a driver which loaded part of itself in low memory, and part of itself in extended memory (both relocated). The loader needs some way to distinguish between the different segments. SDX's relocation format of course allows for exactly this kind of multi-segment file, as well as non-relocatable segments. Unfortunately the only drawback is that "LDA #<label" must be replaced with "LDA label_p / LDX label_p+1" where label_p = .word label. Nevertheless, in the short term the SDX relocatable format would probably have to do, since the proprietary MADS format isn't really suitable at the moment.

 

I have asked Tebe about multiple segments and such, but there may be communication problems there, or perhaps he (understandably) views the requests as low-priority, since it is I alone who require changes to support plans which exist only on paper. Obviously as time goes on, however, plans will turn into code and we'll need GUI application support in one compiler or another.

 

Understanding MADS.PAS source is quite difficult for me because (almost) all names and comments in the source are in Polish (I am French).

But if you provide me with a source with the syntax you would like to see supported, I can try to do it if you really need that feature.

This would be a way for me to thank you for the MYIDE2.SYS driver I use on a daily basis.

I have the additional handicap of not understanding Pascal so well. Let me look again at the issues at hand and get back to you. As said above, it's possible to use SDX relocatable binaries if necessary, but I don't see this as a satisfactory long-term solution. I have skeletal loaders for both relocatable formats already. In any case, thanks in advance!

Edited April 30, 2014 by flashjazzcat

[ebiguy]

That's exciting !

Fell free to give me a source with multiple reloc blocks to compile with mads.

I can not be sure of the result but I can try...