Jump to content
  • 0

PRG file question


CursorKeys
 Share

Question

Hi!

 

I am sure this is a silly question, but disregard if you wish.

The X16 uses the PRG file format for executable files, but the PRG format is tied to commodore and commodore 64 with stricter limitations.

For example the X16 has graphics memory and extended memory.  Does (or will) the PRG format (the version used in X16) have any support to load large data structures in extended ram or direct into VERA memory?

 

Thanks

CKs

Edited by CursorKeys
Link to comment
Share on other sites

19 answers to this question

Recommended Posts

  • 0

The PRG format is just about loading a program into memory. Loading other things into VERA memory or banked RAM is independent of how the program got into memory. This happens by using the KERNALs API and for example loading BIN files into any memory type.

A PRG can optionally contain a small amount of graphics data which then has to be copied into VERA by the program itself.

Edited by AndyMt
Link to comment
Share on other sites

  • 0
58 minutes ago, CursorKeys said:

Hi!

 

I am sure this is a silly question, but disregard if you wish.

The X16 uses the PRG file format for executable files, but the PRG format is tied to commodore and commodore 64 with stricter limitations.

For example the X16 has graphics memory and extended memory.  Does (or will) the PRG format (the version used in X16) have any support to load large data structures in extended ram or direct into VERA memory?

 

Thanks

CKs

Not exactly. 

There is some support in the kernel for choosing to load a file directly to VERA, but you have to invoke that function yourself. So the way to handle that would be to load your "loader" program, which would then load your assets into the correct places before starting the main part of your game. 

 

Link to comment
Share on other sites

  • 0

Thanks, I was more interested if you can make 1 file programs (with no external files) that contain more then 64k of data, to be loaded direcly outside of main memory. 

But ok, multi file approach it is then 🙂

I just wish I did not
need to have SD card file images to play with multi file programs.

 

Link to comment
Share on other sites

  • 0
46 minutes ago, CursorKeys said:

I just wish I did not need to have SD card file images to play with multi file programs.

You don't. You can use the host file system for most applications, especially if you are just loading the entire file into RAM or VRAM. It is artificially fast, but that can be beneficial for speeding up your development process.

  • Thanks 1
Link to comment
Share on other sites

  • 0

And thankfully, R39 seems to work just as well with SD images and with the host FS. The discrepancies between these two "modes" was making me pull my hair out because I wasn't expecting the results I was(n't) getting in various situations. My most recent demo works just as well in either case on R39 w/o any code changes. (Thanks for all the hard work, devs!)

Link to comment
Share on other sites

  • 0

I like to return back to the prg topic (in another context).

I just read this link on how prg files are used on the c64.
http://fileformats.archiveteam.org/wiki/Commodore_64_binary_executable

Here it states that either the data of the prg will be loaded in $0810 or the first two byte of the prg are used to determine where the prg dara is loaded in memory.

This depends on if you do load "*",8 or load "*",8,1

Is the behaviour the same on X16, and is the "magic" $0801 address also the same?

Thanks

/CKs

 

Link to comment
Share on other sites

  • 0
18 minutes ago, CursorKeys said:

I like to return back to the prg topic (in another context).

I just read this link on how prg files are used on the c64.
http://fileformats.archiveteam.org/wiki/Commodore_64_binary_executable

Here it states that either the data of the prg will be loaded in $0810 or the first two byte of the prg are used to determine where the prg dara is loaded in memory.

This depends on if you do load "*",8 or load "*",8,1

Is the behaviour the same on X16, and is the "magic" $0801 address also the same?

Thanks

/CKs

 

Yes, the magic address is still $801. I believe this was done intentionally, to preserve compatibility with the C64. Also, yes - the first two bytes of the file tell KERNAL where to put the file in memory when you use the ,1 parameter. (,2 and ,3 will load the file into VERA’s bank 0 or 1).

 

 

  • Like 1
Link to comment
Share on other sites

  • 0

Thanks. 

On another topic I am still (somewhat a lost cause, I know 🙂 )  hoping they could somewhat extend the prg "format".
Maybe first two bytes have $ffff reserved. If $reserved then prg v2 format.  Which would be something like

byte1 byte2 (load ram  type and address of next chunk, some magic here to have 2 bytes both specify the address and the type of ram, or something....)

byte3 byte4 (size of chunk)

.....

(next chunk)

Anyway, one can keep dreaming, but it would be so cool, if single prg file could load stuff into base ram, banked ram, or vera ram, or most likely a combi, and also prgv2 files size would be not limited 🙂

 

 

Edited by CursorKeys
Link to comment
Share on other sites

  • 0
2 minutes ago, CursorKeys said:

Anyway, one can keep dreaming, but it would be so cool, if single prg file could load stuff into base ram, banked ram, or vera ram, or most likely a combi, and also prgv2 files size would be not limited 🙂

It can be, and I made a video about it: 

 

  • Thanks 1
Link to comment
Share on other sites

  • 0
1 minute ago, CursorKeys said:

I am curious how the simple prg format could cater for this

In a nutshell, there are two ways: make a big PRG file that can be loaded into contiguous RAM and then copied out to other parts, or just have multiple PRG and BIN files and one executive PRG that does all the loading so that the user only has to load the one file, while the others sit in the same directory.

Link to comment
Share on other sites

  • 0
7 minutes ago, SlithyMatt said:

In a nutshell, there are two ways: make a big PRG file that can be loaded into contiguous RAM and then copied out to other parts, or just have multiple PRG and BIN files and one executive PRG that does all the loading so that the user only has to load the one file, while the others sit in the same directory.

ok, like that.

No this is not what I was talking about. I know that this can be done. What I am "dreaming" about, is being able to load a >64kb single pgm file, by having the X16 guys redefine the pgm format to the next level, so different parts of this same file can be redirected to separate parts of the ram (vera, banked or normal) 🙂  Also the Kernel would need to support it.  But then again, it's not that complicated.

I agree, it may have limited use, but yeah, to me it would be a "cool" improvement.  Making the X16 one step more modern. (of course what is too modern is a question of taste)

 

I'll still check out the the vid though, it looks interesting.

Link to comment
Share on other sites

  • 0
1 minute ago, CursorKeys said:

What I am "dreaming" about, is being able to load a >64kb single pgm file

Well, then that would have to be something other than a PRG file. One could have a special loader program in memory that could open such a file and load its segments appropriately. But deployment of separate program and assets is just a much better way to deliver software, especially when you don't have the horsepower or RAM to load and decompress a large file. I think the common deployment strategy will be a zip file that you then decompress with a modern computer into an SD card directory, if you aren't buying a pre-loaded SD card (which I intend to produce for my games).

  • Like 1
Link to comment
Share on other sites

  • 0
1 minute ago, SlithyMatt said:

Well, then that would have to be something other than a PRG file. One could have a special loader program in memory that could open such a file and load its segments appropriately. But deployment of separate program and assets is just a much better way to deliver software, especially when you don't have the horsepower or RAM to load and decompress a large file. I think the common deployment strategy will be a zip file that you then decompress with a modern computer into an SD card directory, if you aren't buying a pre-loaded SD card (which I intend to produce for my games).

Yep, that's what I was after. The "special" loader, would be a small adjustment to the Kernal.  And the file, in my mind, could still be a PRG file, just a new version of it. (but that could be discussed all night :))

But indeed, the interesting thing is what is going to be the deployment strategy for the X16.  Buying a preloaded SD cards, sounds like a reasonable proposal to buy a game, but it would not really fill up a 4GB or larger SD card.

And I probably would come to the conclusion that most games would just use only a few percent of the SD disk, so, I would want to collect several on a single SD disk, skipping the swap SD card step.   In that case, a single file may be a good way to manage assets. 

But I agree, then compression comes in play.....  Well, maybe...  But not so much for saving space perhaps, since SD cards are huge compared to the memory size of the X16. Why compress? So the goal maybe would be speeding up load times, although that is maybe also not really a big bonus, since decompressing also takes time...

Interesting, to compress or not.  On the c64 it was a no brainer.  The 1541 disks were super tiny compared to a modern SD card, and any type of content was filling up the disk quickly.  But now with SD technoglogy... 

Link to comment
Share on other sites

  • 0
54 minutes ago, CursorKeys said:

Thanks. 

On another topic I am still (somewhat a lost cause, I know 🙂 )  hoping they could somewhat extend the prg "format".
Maybe first two bytes have $ffff reserved. If $reserved then prg v2 format.  Which would be something like

byte1 byte2 (load ram  type and address of next chunk, some magic here to have 2 bytes both specify the address and the type of ram, or something....)

byte3 byte4 (size of chunk)

.....

(next chunk)

Anyway, one can keep dreaming, but it would be so cool, if single prg file could load stuff into base ram, banked ram, or vera ram, or most likely a combi, and also prgv2 files size would be not limited 🙂

 

"they" is "us." Mike, the person making the KERNAL changes already has a full pipeline. He can't do more than he already is, so it's up to us and other users like us to add new features like this. 

I've written a specification for this. It's still out there in the forums (I believe I called it "Advanced PRG Format"), and it's still possible to implement. But right now, I'm a bit burned out on everything, and I just don't have the time and energy to put into Commander coding. 

Edited by TomXP411
  • Like 1
Link to comment
Share on other sites

  • 0
1 hour ago, SlithyMatt said:

Well, then that would have to be something other than a PRG file. One could have a special loader program in memory that could open such a file and load its segments appropriately. But deployment of separate program and assets is just a much better way to deliver software, especially when you don't have the horsepower or RAM to load and decompress a large file. I think the common deployment strategy will be a zip file that you then decompress with a modern computer into an SD card directory, if you aren't buying a pre-loaded SD card (which I intend to produce for my games).

It can be a PRG file... you'd just set the load address to $FFxx to trigger the hypothetical advanced loader.. This is an impossible load address, since that's ROM space, and so an advanced PRG loader would know to switch to advanced mode and start reading segments, rather than treat the file as a flat file.

I chose $FF16, to designate this as a Commander X16 program. Likewise, we could have $FF08 for a Commander X8 program.

 

Edited by TomXP411
  • Like 1
Link to comment
Share on other sites

  • 0
4 minutes ago, TomXP411 said:

 

"they" is "us." Mike, the person making the KERNAL changes already has a full pipeline. He can't do more than he already is, so it's up to us and other users like us to add new features like this. 

I've written a specification for this. It's still out there in the forums (I believe I called it "Advanced PRG Format"), and it's still possible to implement. But right now, I'm a bit burned out on everything, and I just don't have the time and energy to put into Commander coding. 

Cool, I did not know that.

I have not been 100% aware of who does what on the Kernal.  But it makes sense, it is "us", not "they".

But yes, I can understand the burnout feeling.  For me, I am just over it, so I am ready for a fresh dose of X16, this is why all the questions 🙂
(I am right now trying to squeeze 60kb of data into a single prg file just now, with compression, so I am more or less just wishing, I could just read the whole thing in chunks into Vera and normal memory in one go....
But no need to take my request seriously though, I can perfectly live without it, but I like the idea of extending things. (Hence my obsession with double Petscii) 🙂

Anyway, I'll stop whining, and go back to my compression algorithm for now (Yes, I am a little obsessed of making 1 file programs, I am sure I'll get over it some time) 🙂
 

Link to comment
Share on other sites

  • 0
21 minutes ago, TomXP411 said:

....................I've written a specification for this. It's still out there in the forums (I believe I called it "Advanced PRG Format")...................


Just for future reference, I think this is the one you meant 🙂
 

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use