Binary Load Files - calling from within another program

[jacobus]

First off, my apologies for asking this question again, but I was unable to solve the issue before and I’m hoping a better description (and a clean thread) may help.

 

I need help launching a binary load file, specifically a Rasta-Converter self-executing image. I want to be able to execute the RC binary from within my (running) program – more or less duplicating the functionality of DOS’s Binary Load.

 

My Environment

• Standard 64K XL and SD disk
• DOS 2.0 initially, overwritten by my program
• QUICK Development language
• No free memory in my host program – hence the need to call out to an separate executable
• Virtually zero assembly skills and a mediocre programmer at best

 

If I understand the Binary load function properly, it would need follow these steps:

1. Read first 2 bytes (FFFF)
2. Read next 4 bytes – use these to determine start load address and length of segment (end-start)
3. Read next X (segment length) bytes
4. Call start address
5. Read next two bytes – if FFFF assume new segment and start back at step 2

 

Thanks to FJC’s help I have managed to create a small assembler routine that can load a sequential series of sectors, placing them sequentially in memory and then call a specific address. The idea was to load the RC executable into RAM and then execute it. Unfortunately, it fails – no doubt due to a segmented executable not being handled correctly.

 

Can someone please help by either:

1. Suggest a method to adapt my existing code to follow the Binary load steps above
2. Point me at an existing solution that would allow me to successfully launch this RC image. (preferred solution)

 

 

Thank you!

 

 

P.S. This request is part of the Dungeon Hunt II project - now massively overdue, but still alive!

 

[mono]

If I understand the Binary load function properly, it would need follow these steps:

1. Read first 2 bytes (FFFF)
2. Read next 4 bytes – use these to determine start load address and length of segment (end-start)
3. Read next X (segment length) bytes
4. Call start address
5. Read next two bytes – if FFFF assume new segment and start back at step 2

 

It would be better to:

1. Set RUNAD ($2E0) address to 0.
2. Read first 2 bytes (FFFF).
3. Read next 2 bytes - use to determine start load address
4. Set INITAD ($2E2) address to 0.
5. Read next 2 bytes – use to determine end of block address (to be honest this is address of last byte of block) and length of segment (end+1-start).
6. Read next X (segment length) bytes.
7. Call INITAD address (if it has value different than 0).
8. Read next two bytes – if FFFF assume new segment and start back at step 3, in the opposite case assume it as a start of new block address and go to step 4.
9. Call RUN address (if it has a value different than 0) when End Of File met.

The problem is that the only first block must be prepended by $FFFF identifier - it's optional for every following blocks. So we can have following file structure:

 

$FF $FF $00 $40 $FF $5F

$xx... - $2000 bytes because $5FFF+1-$4000=$2000

$00 $20 $7F $20

$xx... - $80 bytes loaded at $2000

$FF $FF $E2 $02 $E3 $02

$00 $20 - INIT addres is $2000 beause it's loaded into INITAD ($2E2) vector

$E0 $02 $E1 $02

$00 $40 - RUN address is $4000 because it's loaded into RUNAD ($2E0) vector

EOF

 

It's possible to have many INIT and RUN blocks, but every INIT should be executed when just loaded, and the only last RUN block is executed on EOF.

[Alfred]

Not quite clear on what you want. An example of a binary loader that uses DOS calls to read bytes from the file. Code that reads a DOS 2.0 disk and loads the file starting from a directory entry say. Code that binary loads data from a fie stored as a bunch of sequential sectors on a disk. Or something else ?

[mono]

My apologies. I've read your post too quick and thought your main problem is loading the binary file.

[phaeron]

I would hardcode the loader specifically for the pictures instead of using a generic executable loader. If you modify the RC template used by the generator, you should be able to get it to assemble as a solid block at a fixed address without exe headers. That'd allow you to just pull it in as one big block. Also, you could pull out the BASIC disable stub, which is the only use of init segments.