Question on vasm -devpac ORG directive

[TheNameOfTheGame]

I have some game code I have extracted and rebuilt in vasm (devpac compatibility).

The original code was run at $800 and has a lot of .w address operands so won't assemble normally without using an ORG to set the PC lower.

My understanding of using ORG (org $800) is that absolute addresses would be assembled to work once the code was loaded at $800 but only exactly at $800. Is that correct?

So am thinking of two ways to get the code to $800.

1) Have a short PC-relative stub at the beginning which would copy some code up higher in RAM and jump to it which would then move the game code down to $800 and jump past the stub code to run the target code. (this would leave the stub code there at $800 after moving though)

2) Have some loader code which would run first and load the assembled binary code to $800 and jump to it.

Are either of these strategies better than the other or is there another way to possibly do it?

[Cyprian]

My understanding of using ORG (org $800) is that absolute addresses would be assembled to work once the code was loaded at $800 but only exactly at $800. Is that correct?

correct

So am thinking of two ways to get the code to $800.

1) Have a short PC-relative stub at the beginning which would copy some code up higher in RAM and jump to it which would then move the game code down to $800 and jump past the stub code to run the target code. (this would leave the stub code there at $800 after moving though)

2) Have some loader code which would run first and load the assembled binary code to $800 and jump to it.

2) looks nicer

one remark, TOS 1.02 occupies RAM till $ca00. Therefore your code will not be compatible with the OS.

[SToS]

My understanding of using ORG (org $800) is that absolute addresses would be assembled to work once the code was loaded at $800 but only exactly at $800. Is that correct?

Absolute-ly yes!

Maybe there is a packer that could do the relocation for you? I don't know one off-hand myself you would have to look into it.
A quick search brings about PackFire v1.2k which alleges to be able to specify an absolute unpack address.
The only thing is that the packer itself is a Windows .EXE, but it comes with ST 68000 unpacking routine source code.
http://neural.untergrund.net/
http://www.pouet.net/prod.php?which=54840

The other route would be to load the data via a boot loader straight off the disk, obviously only if you are going down the floppy image route.

[TheNameOfTheGame]

one remark, TOS 1.02 occupies RAM till $ca00. Therefore your code will not be compatible with the OS.

Ok, thanks, I had it straight then. Hmm, well this is just for testing things out. Of course I could load it higher then be done with TOS calls and move it down to $800 I guess.

Absolute-ly yes!

Maybe there is a packer that could do the relocation for you? I don't know one off-hand myself you would have to look into it.
A quick search brings about PackFire v1.2k which alleges to be able to specify an absolute unpack address.
The only thing is that the packer itself is a Windows .EXE, but it comes with ST 68000 unpacking routine source code.
http://neural.untergrund.net/
http://www.pouet.net/prod.php?which=54840

The other route would be to load the data via a boot loader straight off the disk, obviously only if you are going down the floppy image route.

Thanks, yes, I could pack it and relocate it, but this just for testing some routines out. I'll keep it simple and just load it and move it down to $800.

[Cyprian]

one remark, TOS 1.02 occupies RAM till $ca00. Therefore your code will not be compatible with the OS.

Ok, thanks, I had it straight then. Hmm, well this is just for testing things out. Of course I could load it higher then be done with TOS calls and move it down to $800 I guess.

I heard here that someone used a cool trick - it was simply swapping this memory before and after TOS call

[TheNameOfTheGame]

Ah that would be neat. Well, I wrote the loader already and is working good.

Do you know if there is a switch to write raw binary object file from vasm? I am using -Felf flag and it has a 52 byte header before the code.

I just use a "dd bs=1 skip=52 if=TEST.O of=TEST.BIN" to strip the header bytes and that works fine, but it would be nice to have vasm just assemble raw bytes to an object file.

[SToS]

Do you know if there is a switch to write raw binary object file from vasm? I am using -Felf flag and it has a 52 byte header before the code.

-Fbin

[TheNameOfTheGame]

Nice, thanks, I saw that in the vasm manual but wasn't quite sure if it was what I wanted. Works perfect.

[ThorstenOtto]

Although you have already written a loader, something like this should theoretically also work:

Code: Select all

_start:
   ; write the usual TOS startup code here,
   ; then some routine that copies everything from codestart to codeend to $800
   ; and jump to $800

   org $800
codestart:
   ; your actual code here
codeend:

Then compile it as a normal TOS binary.

Also don't forget that memory from $800 to about $ca00 is not only used by TOS, but also by some interrupts, so you may have to disable them.

[TheNameOfTheGame]

Although you have already written a loader, something like this should theoretically also work:

Code: Select all

_start:
   ; write the usual TOS startup code here,
   ; then some routine that copies everything from codestart to codeend to $800
   ; and jump to $800

   org $800
codestart:
   ; your actual code here
codeend:

Then compile it as a normal TOS binary.

Also don't forget that memory from $800 to about $ca00 is not only used by TOS, but also by some interrupts, so you may have to disable them.

Ah, thanks, that's a good alternate way to do it. I might change it to that. Yes, the first thing the code does is stub the vector table out and put in its vbl, timerb and ikbd routines. I turn off interrupts in the loader prior to moving the code to $800.