Advanced PRG File Format

Lorin Millsap · Post by **Lorin Millsap** » Sat Jan 02, 2021 4:34 pm

It does seems useful to me but it's more important to (hopefully) get some small bugs ironed out in the rom code that exists now (there are a few pull requests on github already that I think are pretty easy and important to include...)

So use the GEOS headers.

Sent from my iPhone using Tapatalk

desertfish · Post by **desertfish** » Sat Jan 02, 2021 4:35 pm

Geos headers? Sorry, I don't follow.

hth313 · Post by **hth313** » Sat Jan 02, 2021 8:24 pm

If seeking is not available then ELF is out. I do not think is practical to read several program header structures, not knowing how many they are.

I still think it is a good idea to be able to load a file into memory and have banks populated automatically. Can someone explain how GEOS helps to load a banked program at power on when I get the READY prompt?

aex01127 · Post by **aex01127** » Mon Jan 04, 2021 11:39 am

I think a loader like this is a good thing to have. I know I can make it up by separating each bank into separate files, but then I need to redistribute several files to accomplish the same goal. One file is much cleaner and safer.

The ROM portion of this will not be much as the ROM loader only will handle the segments that the loader can handle. The limit we have today with the PRG files is that it has to fit into memory.

The ability to have the usercode also work with the file is a plus (loading additional resources). For me it is not that important but as since there does not seem to be any extra cost (complexity/code) for the ROM based loader I think this is a good addition. It can make things easier for some people.

I also think that a relocatable file creates too much complexity/overhead and is not needed (at least for most use cases).

My vote is on this project.

Fnord42 · Post by **Fnord42** » Mon Jan 04, 2021 2:00 pm

I just had an idea: It might be enough to have a very simple file format that does not require us to load the whole file at once. This way you could implement all the loader code in your program and keep the additional rom usage at a minimum.

Something like: 2 bytes format identifier (illegal address), 1 byte flags (see below), 2 bytes target address, 2 bytes number of bytes to read (size of loader), loader code, other data

One bit in the flags would determine if the kernal should jump to the start address upon finishing (so you wouldn't need to type RUN and could omit the basic-sys-header stuff).

The loader code in the file could then reopen the file and load all the rest of the data as needed. Lacking the possibility of seeking, it would have to read and ignore the loader code before it can get to the rest of the data. I don't know how fast that would be, but I think it might not be that much of a problem. (Or an incentive to keep the loader code compact. ;-)) Another thought: Is it possible for the kernal to leave the file opened, so the loader could just continue reading at that point? This could then be controlled with another bit in the flags.

What do you think?

kktos · Post by **kktos** » Tue Jan 05, 2021 5:10 pm

On 1/1/2021 at 1:43 AM, TomXP411 said:

Block header:

01: 01 - Main Memory, 02 - VERA

02-03: Block length. Two bytes, little Endian

03-04: Unused

05: Bank number (VERA or high memory bank)

06-07: Load Address

I guess the address is little endian, right ?

Therefore, I would rather go for:

05-06: Load Address

07: Bank Number

kktos · Post by **kktos** » Tue Jan 05, 2021 5:12 pm

On 1/1/2021 at 5:14 AM, Lorin Millsap said:

... when your program can handle its own data just fine and can just put all its relevant stuff in the same directory....

I think that's precisely what we're trying to avoid here ;oD

To be able to focus on our code, on the added value of our code and not to reinvent the wheel each time just to load some data.

kktos · Post by **kktos** » Tue Jan 05, 2021 5:15 pm

On 1/1/2021 at 5:14 AM, Lorin Millsap said:

Also technically parts of GEOS are in ROM and GEOS can do much of what you are describing. We have done some tests and while more work needs to be done in simplified terms we can run GEOS software.

if we can legally use GEOS, that's a way.

Also, to be more precise, I'm thinking about using some functions of GEOS here, without fully using it.

Let's say I'm writing a game, I want my own game system and to be able to use some system functions, like load data. Nothing more.

Lorin Millsap · Post by **Lorin Millsap** » Tue Jan 05, 2021 5:16 pm

And BLOAD doesn’t work because?

Sent from my iPhone using Tapatalk

kktos · Post by **kktos** » Tue Jan 05, 2021 5:19 pm

On 1/1/2021 at 1:43 AM, TomXP411 said:

$80 Custom loaders will be implemented via a jump table. The jump table will consist of 3 bytes per entry, as follows:

$80 21 42 If block format is $80, jump to address $4221

$93 96 42

$00 Null terminates the jump table.

Why the 16bits address and not 24bits ? (bank + address)