PGX v1 Proposal - aka Chunked PGX

[cydo]

Kernel and BASIC Updates 2020-04-11 brought us the PGX format (v0), thank you @PJW.

I'll hereby suggest the next version of the PGX format - the "chunked" PGX format v1:

PGX header:
Bytes 0--2: the ASCII text "PGX", serving as a signature.
Byte 3: the byte 0x11. The upper 4 bits are the PGX file format version (1), and the lower 4 bits are the CPU code (1 for 65816).

Chunk header:
Bytes 4--7: the destination address in little endian format.
(until this point it's the same as v0, except for the updated pgx version)
Bytes 8--11: the chunk size. A chunk size and destination address of 0 indicates the end of the chunk chain.

Chunk data:
Bytes 12--(12+chunk size): Data to load to the destination address.

..and repeating the next chunk header and chunk data until both chunk size and destination addresses are set to 0.

So it's the nearly the same as v0 but with an additional chunk size field and following chunk data with optionally any
number of chunk header+data blocks.

While specifiying the end of the chunked data with a chunk address and size of 0 instead of just the end of the file
would allow to put arbitrary data at the end of all of the directly loaded chunk data which could be loaded on demand via code -
thus multiple code & data blocks loaded into memory and following code-loadable data resulting in a single file format.

The starting address would be the first chunk address (same as in v0) - but it would be possible to start with a runable code chunk at
e.g. address $03:0000 and then following a data chunk at a lower address (e.g. $02:0000) than the initial run code chunk.

[cydo]

while browsing the SDOS.asm I've stumbled across these lines

; Formats to be supported:
; PGX -- First four bytes contain the loading address
; FNX -- multi-segmented file format with multiple addresses
; BIN -- Generic binary requiring a destination address

looks like FNX will be my proposed chunked PGX

[stef]

while browsing the SDOS.asm I've stumbled across these lines

; Formats to be supported:
; PGX -- First four bytes contain the loading address
; FNX -- multi-segmented file format with multiple addresses
; BIN -- Generic binary requiring a destination address

looks like FNX will be my proposed chunked PGX

Sounds great, I proposed something in the past but after discussion with @PJW, we have put it on the back burner but lately there has been some resurgence for the need of a more packetized file format. I guess it comes down to who is going to do the work.

Please feel free to do it if you want!

Cheers

Stefany

[cydo]

One of the reasons it would be a great idea of having the latest kernel always updated on github - I for sure won't to interfere with already work in progress.
And I surely need some more time to understand the kernel system in order to include my proposed version - and yes, of course I need to
be a bit more fluent in 65816 assembly as well

Some update to my proposed PGX v1 standard:
Instead of having a 4 byte chunk size I'd just use a 2 byte (aka 1 bank) size. This would limit a chunk to 64k - and
it would be easier to include with the current pgx v0 code.

[stef]

One of the reasons it would be a great idea of having the latest kernel always updated on github - I for sure won't to interfere with already work in progress.
And I surely need some more time to understand the kernel system in order to include my proposed version - and yes, of course I need to
be a bit more fluent in 65816 assembly as well

Some update to my proposed PGX v1 standard:
Instead of having a 4 byte chunk size I'd just use a 2 byte (aka 1 bank) size. This would limit a chunk to 64k - and
it would be easier to include with the current pgx v0 code.

PJW is really at the center of all of this and it would be a lot easier to engage in this conversation on Discord.

Normally, it would always on Github, but again, a lot of changes are being implemented and will be released in due time. (sooner than later I suppose).

Again, you being on Discord (I am assuming that you are not at this point) would make those interactions easier to get the information you need right now.

Regards,

Stefany