Is possible to optimize and/or trim CPR images? Because almost all have 256 or 512 kB when data is sometimes far less.
Yes, they can be truncated. Somewhere there is software in this forum.
Quote from: GUNHED on 10:49, 25 July 24Yes, they can be truncated. Somewhere there is software in this forum.
Can You say more about this?
Quote from: Solo Kazuki on 10:04, 24 July 24Is possible to optimize and/or trim CPR images? Because almost all have 256 or 512 kB when data is sometimes far less.
I used to do it a few times to put more than one game on a (multi-)cartridge and the following process worked for me:
- convert CPR back to a pure BIN with CPR Tools
- check with a hex editor that this file doesn't have any data above 128K or 256K.
- Once that is verified, just cut the BIN to the right size (if not possible with the hex editor, then using a file splitter)
I think when you convert the reduced BIN now back again to CPR the file size should stay close to 128K or 256K (with a bit of overhead).
May I ask why you want to do that?
Quote from: eto on 13:07, 25 July 24May I ask why you want to do that?
To trim CPRs that they would be closer in size to exact data contained.
Quote from: Solo Kazuki on 16:50, 25 July 24To trim CPRs that they would be closer in size to exact data contained.
Sure... but where does this help? Even a 4GB USB Stick or SD-Card is providing much more space than a full set of all available CPRs would ever need.
Quote from: eto on 17:25, 25 July 24Quote from: Solo Kazuki on 16:50, 25 July 24To trim CPRs that they would be closer in size to exact data contained.
Sure... but where does this help? Even a 4GB USB Stick or SD-Card is providing much more space than a full set of all available CPRs would ever need.
And tell me what does help completely useless empty data in CPR images? Less is better in this case, if trim is possible.
I can even pay someone for such tool, if it's needed. Some Patreon, or kickstarter, or even direct payment when required.
What is it that you cannot do with the tools Eto mentioned above?
Besides, there's no automatic way to detect where's the end of the data. Suppose you have a block of empty data that is used by the program, and that crosses the 128KB boundary.
If you trim that and put it into a 128KB chip, it wouldn't work because it would be missing data supposed to be there.
Sure, those are edge cases, but also there's no reliable way to do that.
Quote from: Solo Kazuki on 12:16, 25 July 24Quote from: GUNHED on 10:49, 25 July 24Yes, they can be truncated. Somewhere there is software in this forum.
Can You say more about this?
As eto told: CPR tools (couldn't remember the name before). :) Just give it a try. :)
seems it's not that easy to find with Google:
http://www.cpcmania.com/cprtools/cprtools.htm
Quote from: eto on 17:24, 26 July 24seems it's not that easy to find with Google:
http://www.cpcmania.com/cprtools/cprtools.htm
I found this already, but it's only converter, not optimizer/trimmer to CPRs. But thanks anyway for Your efforts.
If it's just a matter of storage space on the medium, you can simply enable compression in the file system. (At least on Windows)
Quote from: Fessor on 18:19, 26 July 24If it's just a matter of storage space on the medium, you can simply enable compression in the file system. (At least on Windows)
No, it's not matter of storage space. It's matter of empty useless data in CPRs.
I was taking a look at the Masarat Khatira .cpr file, and it contains large areas of 0xE5 bytes (which are probably because the file was created from a disk image), and 0xFF bytes, which would be the empty space.
Maybe we could trim those 0xFF bytes, but the question is, would these files still be recognizable and usable by emulators and hardware devices?
Quote from: Solo Kazuki on 17:31, 26 July 24I found this already, but it's only converter, not optimizer/trimmer to CPRs. But thanks anyway for Your efforts.
That's why the process I told you has several steps. Step 2 is to use a HEX editor and identify, if you can trim the file. If that's the case, you can save a subset of the file or - if your hex editor is not capable of this - use a file splitter (e.g. https://github.com/dubasdey/File-Splitter sounds promising).
The last step then is to create a CPR again.
Quote from: robcfg on 22:35, 26 July 24I was taking a look at the Masarat Khatira .cpr file, and it contains large areas of 0xE5 bytes (which are probably because the file was created from a disk image), and 0xFF bytes, which would be the empty space.
Maybe we could trim those 0xFF bytes, but the question is, would these files still be recognizable and usable by emulators and hardware devices?
Why not? Good example is Hexavirus v0, where CPR have 49kB
https://www.cpc-power.com/index.php?page=detail&num=17197
If You made such trimmed image, I can check it with M4 board if this works.
Quote from: Solo Kazuki on 06:35, 27 July 24Quote from: robcfg on 22:35, 26 July 24I was taking a look at the Masarat Khatira .cpr file, and it contains large areas of 0xE5 bytes (which are probably because the file was created from a disk image), and 0xFF bytes, which would be the empty space.
Maybe we could trim those 0xFF bytes, but the question is, would these files still be recognizable and usable by emulators and hardware devices?
Why not? Good example is Hexavirus v0, where CPR have 49kB
https://www.cpc-power.com/index.php?page=detail&num=17197
If You made such trimmed image, I can check it with M4 board if this works.
I suspect Hexavirus was written specifically as a Plus cartridge, whereas the vast majority of CPRs are auto conversions from disk. It's possible they need to replicate all the disk structure to be guaranteed to work (or it might just have been the most convenient mechanism for faking disks). It's also possible the data is scattered across ROMs as a result of this and some emulators will fail to load a CPR if not all ROMs are in sequence (even though the CPR format allows it).
Quote from: andycadley on 08:18, 27 July 24t's possible they need to replicate all the disk structure to be guaranteed to work (or it might just have been the most convenient mechanism for faking disks)
While theoretically possible it is really unlikely that you will ever have an issue.
The sectors of the DSK are copied sequentially to the CPR. If there is no data in a sector it is unlikely that it will ever be accessed at any time by the game. Especially with the cracked versions used in those CPRs which just load the game via firmware and not via their own routines.
I shrunk several CPRs from 512K to 128K or 256K and - as long as they did only contain empty sectors beyond the 128K/256K barrier, they perfectly worked.
Hey,
@Solo Kazuki , care to try this one?
Quote from: robcfg on 22:02, 27 July 24Hey, @Solo Kazuki , care to try this one?
It works ok on M4 board. Someone with C4CPC should also check this.
Quote from: eto on 15:01, 27 July 24Quote from: andycadley on 08:18, 27 July 24t's possible they need to replicate all the disk structure to be guaranteed to work (or it might just have been the most convenient mechanism for faking disks)
While theoretically possible it is really unlikely that you will ever have an issue.
The sectors of the DSK are copied sequentially to the CPR. If there is no data in a sector it is unlikely that it will ever be accessed at any time by the game. Especially with the cracked versions used in those CPRs which just load the game via firmware and not via their own routines.
I shrunk several CPRs from 512K to 128K or 256K and - as long as they did only contain empty sectors beyond the 128K/256K barrier, they perfectly worked.
This is nice step forward, these CPRs are half or even quarter of previous version.
Maybe further optimization is possible?
Could You share with those trimmed CPRs?
Quote from: Solo Kazuki on 09:42, 28 July 24Could You share with those trimmed CPRs?
I did not make CPRs but created binaries to build onto multi-game cartridges, so unfortunately the last step (BIN to CPR) was not done.
But if you follow my explanation you can create a reduced CPR easily within a few minutes from the original CPR.
The test I send him is of a small command-line program I wrote some years ago, to which I added the trimming of the unused part of the rom.
Now, I can try to tell it to accept a certain trim value as parameter, like 0xFF for the unused rom space.
Obviously up to the user's discretion. I'm not gonna try to develop heuristics or any fancy algorithm.
Ok guys, probably I get it how trim could be done. I just cut some CPRs with hxd editor and... it works! Without any converting or so.
It was done by cutting from first empty cb?? block (where ?? is number) to the end. By empty it can be either FF or E5 hexadecimal value.
I'll implement the byte value to trim and make the code available.
Ok, did a version of the CPR that takes away the trailing 0xFF bytes of empty rom and also the trailing 0xE5 bytes from the embedded disk image.
Please let me know if it works.
Quote from: robcfg on 22:41, 28 July 24Ok, did a version of the CPR that takes away the trailing 0xFF bytes of empty rom and also the trailing 0xE5 bytes from the embedded disk image.
Please let me know if it works.
No, You cut too much. Version which works should have 209KB. Check version which I cut manually, it should work ok.
Ok, so I fixed a small error in my program where it would skip the las full chunk of data and seems to be working.
If you trim the 0xE5 bytes from the disk image, the Masarat Khatira file goes under 200KB.
Please try the attached file.
Nope, not working. I have just "Bad command" error after start cart.
Interesting. It does work on RetroVirtualMachine...
But this highlights the problem I told you earlier we could have.
So it seems that trimming the disk image itself yields errors. Would be good to know why.
If I just trim the 0xFF bytes does it work? (Try the attached file, please)
It depends on the emulator I would say; the CPR has a header for example;
@robcfg you say "trim", so I don't know how are you doing it.
I'm not sure I see the point of all this TBH :D but if I wanted to make a smaller CPR, with my tools you can: https://github.com/reidrac/cpr-tools
1. use cprdump.py to generate 16kb bin chunks
2. remove any bin files that are all 0xff (or 0x00; that's what my tools use for padding), starting from the last and going backwards -- stop when a block has other data that is not 0x00 or 0xff!
3. use mkcpr.py to build the CPR back with the remaining bin files (by default the tool won't pad the CPR)
The resulting CPR should be valid and work everywhere; although I recall that the padded version (which is without trimming) is recommended for higher compatibility. That's what I used in Hyperdrive, for example.
(if this is how you did it, apologies for the noise!)
Hi
@reidrac , thanks for your feedback!
What I do is take the binary and just trim the 0xFF bytes at the end and, if you tell me to, the following 0xE5 bytes at the end after that.
I don't think it makes much more sense than to use the closest rom size (64,128,256,512KB) to the data, but I just had this small program of mine and could easily add the required functionality.
Quote from: robcfg on 13:34, 01 August 24I don't think it makes much more sense than to use the closest rom size (64,128,256,512KB) to the data, but I just had this small program of mine and could easily add the required functionality.
I believe it is important. The CPR is a RIFF file, if you don't follow the spec, some emulators may decide the file is corrupt instead of processing it properly
See: https://cpctech.cpcwiki.de/docs/cprdef.html
QuoteIf a emulator encounters a block with less than 16k, it should fill the rest of the range with 0's, if a emulator encounters a block with more than 16k, it should stop reading at 16k and ignore the remaining data.
Do all emulators follow this? I guess they don't! :)
Thing is, I trim the source data, and then I write the proper RIFF structure.
That's why it works on RVM.
For me the interesting thing would be knowing why that would fail on a real machine. Maybe it's an issue with the device being used to supply the CPR?
Hi,
joining the party a bit late, but anyway... What CPR are you trying to trim? Was it a pure ROM / Cartridge dump file before it got made into a CPR? And what format do you need it to be (ROM for ROMboard or Cartridge)?
I've always done this manually with a HEX editor. If you can send me the file in question, I can look at why a real machine doesn't like it.
Bryce.
I'm playing with the Masarat Khatira CPR conversion from this post: https://www.cpcwiki.eu/forum/index.php?msg=241585
I don't remember what device is
@Solo Kazuki using.
Quote from: robcfg on 18:26, 01 August 24I'm playing with the Masarat Khatira CPR conversion from this post: https://www.cpcwiki.eu/forum/index.php?msg=241585
I don't remember what device is @Solo Kazuki using.
Ok, so I've just looked at the (UK).CPR file: The part I've marked in red needs to be removed, but... The Byte I've marked green is also wrong. The value 00 would indicate to a real CPC, that the ROM is a background ROM (such as BASIC). For a game that needs to be started with a bar command, this value should be 01 and the value right after it should be the address of the command table for the ROM. So you not only need to remove bits, but also correct these values for it to work properly.
Bryce.
A CPR is not a straight binary dump of ROMs, it's a RIFF based file and that has it's own header (which appears to be what you're looking at)
I mentioned earlier that:
QuoteThing is, I trim the source data, and then I write the proper RIFF structure.
That's why it works on RVM.
I wrote the program to convert from raw binary data to cpr format and viceversa in 2008, and the cpr file specs have been out there since forever.
What is being discussed is that if the unused data, whether empty rom space or empty embedded disk image space, thus making the resulting files smaller, and if that would work on several devices that accept this kind of files.
@Bryce : Thanks for the info! I wasn't aware of that bit (no pun intended). Does that work the same on a Plus machine?
Quote from: robcfg on 21:30, 01 August 24@Bryce : Thanks for the info! I wasn't aware of that bit (no pun intended). Does that work the same on a Plus machine?
No, that's kind of what I meant. You can't assume a cartridge ROM is going to follow the firmware specs. And, if you want to be compatible with all the emulators out there, you need the ROMs to be in order and without any gaps (despite one of the points of using RIFF in the first place was to allow that) and if you're doing that the first ROM in the file would be the firmware ROM itself, which also doesn't follow the rules of upper ROMS (because it isn't one)
Quote from: robcfg on 18:26, 01 August 24I don't remember what device is @Solo Kazuki using.
M4 board with 6128 plus.
Quote from: robcfg on 21:30, 01 August 24I mentioned earlier that:
QuoteThing is, I trim the source data, and then I write the proper RIFF structure.
That's why it works on RVM.
I wrote the program to convert from raw binary data to cpr format and viceversa in 2008, and the cpr file specs have been out there since forever.
What is being discussed is that if the unused data, whether empty rom space or empty embedded disk image space, thus making the resulting files smaller, and if that would work on several devices that accept this kind of files.
@Bryce : Thanks for the info! I wasn't aware of that bit (no pun intended). Does that work the same on a Plus machine?
There is an older thread somewhere here, where multiple people were converting tape games to work on a standard ROMBoard, some of which required the game to be spread across more than one ROM IC. There was a lot of discussion there about the formats and compatibility back then, maybe you can find some useful info there? From memory (which mine isn't always great), they all worked on Plus cartridges too. I think they were mostly using the noca$h converter to create the files.
Bryce.
Thanks for the tip!
Though I suspect it may be more some strict handling of the cpr files by the M4 (or any other device).
The two issues that crop up the most , I think, are:
Cartridge blocks out of order or missing - a few implementations assume that the first block will be for cb00, the second for cb01 etc without bothering to actually parse the block headers. So stripping out a ROM midway through or reassembling the cart in the "wrong" order can cause failures.
ROMs that aren't exactly 16KB - again the spec is supposed to allow for this, filling the remainder of the ROM with 0, but there are implementations that assume every ROM will be exactly 16KB and (again) ignore what the header actually says (including potentially assuming the header of the next block is part of the ROM etc)
Nice!
The order of the chunks is not an issue, because I make sure they are always ordered, and I also have a note on the code reminding me of it :D
That the chunks are not exactly 16KB in size could definitely be a problem. I think the devices should support the full spec of the files, but it's way easier to make my code just fill up (or not trim) the last chunk, which is always the one that could get in that situation.
I've trimmed some CPRs, please test it!
Part 1:
Part 2:
Part 3:
Well, I never understood why to use CPRs instead of ROMs directly. A CPR file has no advantage (or has it one?), but just fills in some bytes for no gain. What do you think?
Suggesting to move to read ROM content in general! :) :) :)
Quote from: GUNHED on 13:28, 18 June 25Well, I never understood why to use CPRs instead of ROMs directly. A CPR file has no advantage (or has it one?), but just fills in some bytes for no gain. What do you think?
Suggesting to move to read ROM content in general! :) :) :)
IMO You are viewing this from a developer's perspective.
From a user's point of view, it makes perfect sense to me to have a dedicated file format for cartridges.
One for tapes, one for discs, one for cartridges, one for ROMs.. all good.
And it's much much easier to handle one single CPR instead of dealing with 8, 16, 32 or what ever number of single 16K ROM files.
And CPR contains information about how the ROMs need to fit into slots, which pure binary ROMs require the user to understand.
Quote from: GUNHED on 13:28, 18 June 25Well, I never understood why to use CPRs instead of ROMs directly. A CPR file has no advantage (or has it one?), but just fills in some bytes for no gain. What do you think?
Suggesting to move to read ROM content in general! :) :) :)
Advantage, you can gainz some bytes on a 16 cores / 64Gb RAM machine with 32TB HDD ...
Compared to single 16K ROMs agreed.
But for cartridges what is the benefit of a CPR compared to simple, binary 128K, 256K or 512K ROM file? For what was the format established in the first place?
The only hypothetical benefit I see is that unused parts do not "waste" space on a hard drive. And this benefit is barely used as almost all CPRs I have ever seen are 512K CPRs even if the content is a lot less. Even if it would be used, on a typical 4GB SD Card, we still can put 8000 512K ROMs.
Or are there any potential future updates of the format?
Btw: where is the format defined? The one on e the Wiki is quite vague and the link to the original is dead.
There's no requirement for cartridges to be linear (and there are potential advantages to them not being linear). Furthermore, since it's based on RIFF, it's a lot easier to extend if people wanted to, say to include instructions or to support NES style "mapper" arrangements.
And the overhead of RIFF compared to a straight binary is minimal. Admittedly a lot of DSK->CPR conversions are probably massively bloated, but that's really the fault of the tools used to do the conversion rather than the CPR format, you'd still end up with a massively unnecessary file if they'd been writing raw binary.
Quote from: andycadley on 16:36, 18 June 25There's no requirement for cartridges to be linear (and there are potential advantages to them not being linear).
Do you have an example in mind? From what I know about physical cartridges and how they have been built I don't see how cartridges would not be linear or what advantages that could have.
Quote from: eto on 21:44, 18 June 25Quote from: andycadley on 16:36, 18 June 25There's no requirement for cartridges to be linear (and there are potential advantages to them not being linear).
Do you have an example in mind? From what I know about physical cartridges and how they have been built I don't see how cartridges would not be linear or what advantages that could have.
Off the top of my head, the GX and Plus treat Physical Page 3 differently: A Plus will page it in when ROM 7 is requested, a GX will not. So a small cartridge might only need a lower ROM (Physical page 0) and a second ROM that can be used to identify the model (Physical page 3).
More importantly, at the time the format was defined, nobody really knew what "real" GX cartridges might be like - so the format was defined to be flexible enough to cope with anything and extensible enough should the need arise (to avoid the problems with a myriad of other emulator "formats" that actually have multiple different specs to cope with weirdness that was discovered later).
Quote from: GUNHED on 13:28, 18 June 25Well, I never understood why to use CPRs instead of ROMs directly. A CPR file has no advantage (or has it one?), but just fills in some bytes for no gain. What do you think?
Suggesting to move to read ROM content in general! :) :) :)
Because CPR is much easier to handle for me than ROM in M4board. I can have ROM (M4FE in my case) and CPR (games) at once. Changing from M4FE to game and back to M4FE after is not comfortable - You can just "eject" CPR and You have M4FE back then.
So CPR HAS advantage for me.
Quote from: Prodatron on 13:59, 18 June 25And it's much much easier to handle one single CPR instead of dealing with 8, 16, 32 or what ever number of single 16K ROM files.
A ROM file for the 6128plus consists ouf of one(sic!) file exactly. :) It's super easy!
Quote from: andycadley on 15:21, 18 June 25And CPR contains information about how the ROMs need to fit into slots, which pure binary ROMs require the user to understand.
There is nothing special to understand, The ROM file address &000000 starts at ROM &80. That's it. :)
Quote from: roudoudou on 15:37, 18 June 25Quote from: GUNHED on 13:28, 18 June 25Well, I never understood why to use CPRs instead of ROMs directly. A CPR file has no advantage (or has it one?), but just fills in some bytes for no gain. What do you think?
Suggesting to move to read ROM content in general! :) :) :)
Advantage, you can gainz some bytes on a 16 cores / 64Gb RAM machine with 32TB HDD ...
Oh, you got a neat CPC setup then. ;)
Quote from: GUNHED on 19:07, 28 June 25Quote from: andycadley on 15:21, 18 June 25And CPR contains information about how the ROMs need to fit into slots, which pure binary ROMs require the user to understand.
There is nothing special to understand, The ROM file address &000000 starts at ROM &80. That's it. :)
And how does that work when you have gaps in the slots? Or mapper chips in future carts? What would be the point of making a new cartridge format that is less flexible when the current one is already trivial to support?
Quote from: andycadley on 01:13, 29 June 25And how does that work when you have gaps in the slots? Or mapper chips in future carts? What would be the point of making a new cartridge format that is less flexible when the current one is already trivial to support?
CPR is not flexible at all. At least not in a useful way. Sure, you can say "this 16K block goes at position 12 and this at position 1" but what's the point of this? I have a (up to) 512K ROM in a cartridge which I dump to a CPR - why should I rearrange the 16K blocks in the CPR?
CPR just maps up to 32 16K blocks into a 512K ROM space of a physical cartridge ROM. Nothing else. Treatment of pyhsical page 3? Not part of the CPR. Mapping to ROM &80 => not done in the CPR. The only "benefit" is if inside of those 512K there would be a gap of let's say 16K so that you don't "waste" space. But a) this is completely pointless with nowadays mass storage solutions, b) if you compress the CPR there is close to none difference to a compressed ROM and c) it's theoretical as the only scenario I have seen in cartridges are empty blocks at the end of a 128k or 256K ROM in a 512K CPR which could be solved by just having a 128K or 256K ROM (and weirdly enough you still find 16K blocks with only 0s in the CPR - so the CPR is still a full 512K+).
CPR as it's being used today imho only adds overhead over pure ROM cartridge files. I don't even think that mapper chips in future cards might change that as it doesn't matter if the cartridge holds 512KB or 1MB - it's the hardware that will take care of switching to the right 16K rom bank in the 1MB EPROM.
Quote from: eto on 18:33, 29 June 25The only "benefit" is if inside of those 512K there would be a gap of let's say 16K so that you don't "waste" space. But a) this is completely pointless
The argument against CPR was that it "wastes space". If you take the point of view that disk space is cheap (which is a perfectly valid argument) then that argument no longer makes sense and you might just stick to CPR.
Quote from: eto on 18:33, 29 June 25CPR as it's being used today imho only adds overhead over pure ROM cartridge files. I don't even think that mapper chips in future cards might change that as it doesn't matter if the cartridge holds 512KB or 1MB - it's the hardware that will take care of switching to the right 16K rom bank in the 1MB EPROM.
The hardware would do the actual bank switching, but for emulation you need to describe what that mapper chip is. And so you need a file format that can contain some variety of metadata - a single linear dump of ROM space is not that, which is why basically every cartridge format on every system doesn't just use that.
Quote from: andycadley on 01:13, 29 June 25Quote from: GUNHED on 19:07, 28 June 25Quote from: andycadley on 15:21, 18 June 25And CPR contains information about how the ROMs need to fit into slots, which pure binary ROMs require the user to understand.
There is nothing special to understand, The ROM file address &000000 starts at ROM &80. That's it. :)
And how does that work when you have gaps in the slots? Or mapper chips in future carts? What would be the point of making a new cartridge format that is less flexible when the current one is already trivial to support?
Ah... Not a new format... Just having a 1:1 copy of the chip inside the Cartridge, and that's a (EP)ROM with linear address.
Well, of course I'm wrong in case Amstrad (somebody) will release something on a Cartridge with new technology - but in this case new computers will be needed too.
Nice to have some fantasies, but let's stay realistic. :)
Quote from: andycadley on 19:30, 29 June 25The hardware would do the actual bank switching, but for emulation you need to describe what that mapper chip is. And so you need a file format that can contain some variety of metadata - a single linear dump of ROM space is not that, which is why basically every cartridge format on every system doesn't just use that.
But that's exactly my point. Unlike other cartridge based systems on the GX4000 there is nothing you need to add. By definition the target of a CPRs content is a linear 512K address space. Nothing else is specified.
I did a bit of research a while ago and I tried to find any CPR that would use the block number feature, as I wondered what it could be used for. But I couldn't find any. Even worse ... the typical CPR file is >512K while they often only had 128K or 256K of ROM in it. So even the argument that it saves some space is moot as obviously nobody ever cared about the saving space feature. It's actually funny that the only "feature" of a CPR that it can save space is not used and leads to the situation that having used ROM files instead would have required less space on disk.
Agreed, in the future we might need a format to cover special mapping chips (let's see if that will ever happen - and if it happens, if it happens more than once) but why on earth was that format defined as it is 20 years ago?
PS: to be clear I don't argue to abandon the CPR file format I only try to understand why it was created in the first place. There must have been some idea what it could be used for. Somebody must have thought that it's a good idea to shift around the 16K blocks. And there must have been a reason why this was thought to be a good idea. I'd love to understand what those reasons were.
Quote from: eto on 21:33, 29 June 25But that's exactly my point. Unlike other cartridge based systems on the GX4000 there is nothing you need to add. By definition the target of a CPRs content is a linear 512K address space. Nothing else is specified.
Bubble Quest, if it ever gets released, was targeting a 2MB cartridge. The extra paging inside the cartridge is, essentially, a form of mapper chip. If other larger cartridges get released, they may follow the BQ scheme but they may use something else. To emulated these you will need some way in the format to indicate what additional hardware is in the cartridge (you don't necessarily need the logic there just a byte or two to say "use this mapping scheme - like NES ROMs do)
Quote from: eto on 21:33, 29 June 25PS: to be clear I don't argue to abandon the CPR file format I only try to understand why it was created in the first place. There must have been some idea what it could be used for. Somebody must have thought that it's a good idea to shift around the 16K blocks. And there must have been a reason why this was thought to be a good idea. I'd love to understand what those reasons were.
1) Nobody had done any analysis on GX cartridges, the only one ripped at the time was Burnin' Rubber / BASIC. Maybe every other cartridge had "holes" in the address space. Best to start with a format that could handle it.
2) Things like Gamebase were becoming popular. Being able to embed Screenshots, Artwork, Instructions, POKEs etc in the same file format as the game might have become useful (such things have fallen from favour so never got defined)
3) Nobody thought generic disk->CPR tools had any use. People openly mocked the idea anyone would build programmable carts for the GX. Thus the target usage was preserving the 27 original cartridges and possibly supporting the odd crazy developer who wanted to use Plus features in emulator only programs. So worrying about minor overheads for automated tools was pointless.
4) Disk space was less cheap 20 years ago, the idea your complete GX game collection was the best part of 15MB seemed nuts. The assumption was the carts would get ripped, analysed, reduced down to what was necessary and then nobody would ever produce any more.
5) The original tool for ripping carts was built for the Amiga and IFF is basically how the Amiga handles all its native file formats, so it became the easiest format to use (since it is inherently extensible). Just be thankful it wasn't XML.
Quote from: eto on 21:33, 29 June 25I only try to understand why it was created in the first place. There must have been some idea what it could be used for.
A CPR file replaces many individual 16K ROM files. It's much more practical to use a single container file for larger software than to have to mess around with dozens of small ROM files.
Is there another format that bundles multiple ROMs into one file? I only know of CPR.
Or have I misunderstood something?
And if people convert cartridges to CPRs and don't pay attention to remove unused 16K slots, that's not the format's problem I would say.
Quote from: Prodatron on 09:05, 30 June 25A CPR file replaces many individual 16K ROM files. It's much more practical to use a single container file for larger software than to have to mess around with dozens of small ROM files.
If that is possible: immediately agreed. I've never seen something like that, do you have an example?
I might have not fully understood the specification but imho there's no information about mapping a 16K ROM into a specific ROM slot. Just as an example: try to create a CPR where a ROM is in slot 5 or slot 12. Afaik this is not possible. The CPR only allows to map the 16K ROM to an address inside of a (virtual or physical) 512K ROM chip. So if you are using a CPR for an application your program would appear (as with all other CPRs) at slot 0,1, 7 and then at 128. You have to assemble your app specifically for use in a CPR so it finds the ROM content at ROM slot 128 and above (and this is again not even visible in the CPR as in the CPR you have to define it to be in block 0-31).
Quote from: eto on 09:51, 30 June 25Quote from: Prodatron on 09:05, 30 June 25A CPR file replaces many individual 16K ROM files. It's much more practical to use a single container file for larger software than to have to mess around with dozens of small ROM files.
If that is possible: immediately agreed. I've never seen something like that, do you have an example?
I might have not fully understood the specification but imho there's no information about mapping a 16K ROM into a specific ROM slot. Just as an example: try to create a CPR where a ROM is in slot 5 or slot 12. Afaik this is not possible. The CPR only allows to map the 16K ROM to an address inside of a (virtual or physical) 512K ROM chip. So if you are using a CPR for an application your program would appear (as with all other CPRs) at slot 0,1, 7 and then at 128. You have to assemble your app specifically for use in a CPR so it finds the ROM content at ROM slot 128 and above (and this is again not even visible in the CPR as in the CPR you have to define it to be in block 0-31).
That's because it specifies a Plus cartridge and the Plus cartridge cannot do that.
However you can choose which slots in the cartridge ROMs go into and three of them are "special" because they get mapped onto the Lower ROM, the BASIC ROM and AMSDOS ROM respectively. Also the first 8 can be paged differently to subsequent cartridge slots.
I think what you are missing is that there is no requirement in the Plus hardware for the ROM space to be contiguous. It's entirely possible to have a cartridge with three physical 16K ROMs in slots 0, 1 and 130 if you really wanted and the CPR format was designed to cope with this (and it is not the same as having a bunch of 0 bytes throughout the 'gaps')
Quote from: andycadley on 09:57, 30 June 25That's because it specifies a Plus cartridge and the Plus cartridge cannot do that.
Exactly my point. CPR is not a good format for ROM applications as it does not support standard ROM applications like in a ROM board. If you go for CPR to distribute your application it's again not different from using a linear binary.
Quote from: eto on 11:58, 30 June 25Quote from: andycadley on 09:57, 30 June 25That's because it specifies a Plus cartridge and the Plus cartridge cannot do that.
Exactly my point. CPR is not a good format for ROM applications as it does not support standard ROM applications like in a ROM board. If you go for CPR to distribute your application it's again not different from using a linear binary.
CPR is not intended for ordinary sideways ROMs, it's for cartridges which completely replace the OS.
That's a bit like saying DSK isn't a suitable replacement for CDT tape images, because it can't represent a tape file. It's not the intended purpose.
Quote from: eto on 11:58, 30 June 25Quote from: andycadley on 09:57, 30 June 25That's because it specifies a Plus cartridge and the Plus cartridge cannot do that.
Exactly my point. CPR is not a good format for ROM applications as it does not support standard ROM applications like in a ROM board. If you go for CPR to distribute your application it's again not different from using a linear binary.
Exactly!!! :) :) :)
QuoteCPR is not intended for ordinary sideways ROMs,
That's what I said in #69 and #71.
Quote from: eto on 16:57, 30 June 25QuoteCPR is not intended for ordinary sideways ROMs,
That's what I said in #69 and #71.
But a CPR is still a container for multiple ROM files. They are not sideways ROMs that go in the lower slots and used by BASIC, but cartridge ROMs that go in the 128+ slots (except for the special cases mentioned above). There is absolutely no requirement in the hardware that these slots are filled consecutively - it just does not work like that.
Well, I guess you miss the point...
A Cartridge contains a memory chip. ONE memory chip!
So the most best and easy way is just to dump that chip in a linear way.
The CPR format was created for something that never happened imho.
Quote from: andycadley on 13:53, 30 June 25Quote from: eto on 11:58, 30 June 25Quote from: andycadley on 09:57, 30 June 25That's because it specifies a Plus cartridge and the Plus cartridge cannot do that.
Exactly my point. CPR is not a good format for ROM applications as it does not support standard ROM applications like in a ROM board. If you go for CPR to distribute your application it's again not different from using a linear binary.
CPR is not intended for ordinary sideways ROMs, it's for cartridges which completely replace the OS.
My regular cartridge contains the native OS, Basic and Burnin Rubber. And that's probably true for most 6128plus computers.
Well, well, therefore it's better to use a straight dump of the memory chip or the Cartridge / any Cartridge. Such a simple dump can mirror any Cartridge 100%