News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Solo Kazuki

Optimize and/or trim CPR images

Started by Solo Kazuki, 10:04, 24 July 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

norecess464

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.
My personal website: https://norecess.cpcscene.net
My current project is Sonic GX, a remake of Sonic the Hedgehog for the awesome Amstrad GX-4000 game console!

Prodatron

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.

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

andycadley

And CPR contains information about how the ROMs need to fit into slots, which pure binary ROMs require the user to understand.

roudoudou

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 ...

eto

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.

andycadley

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.

eto

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.




andycadley

Quote from: eto on 21:44, 18 June 25
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.




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).

Solo Kazuki

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.

Powered by SMFPacks Menu Editor Mod