Advanced PRG File Format

[TomXP411]

7 hours ago, Lorin Millsap said:

And BLOAD doesn’t work because?





Sent from my iPhone using Tapatalk

BLOAD doesn't allow you to load to non-contiguous memory. For example, load a 20K core and 32K of data into banked RAM. Right now, you'd have to save your data as a separate file and load each segment from your program. The APRG format allows for different parts of the program to be loaded to different places in memory, all in one file. This makes software distribution super clean and neat: you give the customer a single APRG file, with the code and data all in a single file. 

This doesn't seem like a big thing, but looking at all the different ways Commodore 64 software is bundled, I thought having a single container format from the beginning would make more sense and allow for better compatibility across different programs. 

I also was hoping this would be a way to coalesce a common set of standards, like SID and Koala were for the Commodore 64, or GIF and JPG are on the PC. By using a common image format with standardized metadata, we can create a common sprite, tile, and bitmap format that everyone can use in their games. Other things also benefit: music sequences (aka "SID" files) are another prime example. If everyone writes to a common audio format, then game makers can just use the pre-made loader, rather than having to roll their own.

This frees up developers to work on their games, rather than spending all their time building tooling. 

So the whole point is really sharing code - we write code once, and then everyone coding games and applications get to take advantage of that.

 

 

[TomXP411]

7 hours ago, kktos said:

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

Code in one bank can't directly access data in another bank. 

If the code is in the same bank as the data, then you don't need to worry about the bank register, because it's already set by the loader. And if the code is in low memory, which is unbanked, you don't need a bank number. 

It doesn't matter, though - with the addition of the Directory block, custom loaders are moot, so I took that out. 

Now, if you need to load data at runtime, such as overlays, maps, or assets, you would consult the directory and load the target block on-demand. It's a cleaner approach from the application perspective, even if it adds a little complexity to the loader itself.