abs and rom std sizes and bank switching

[OzzyOuzo]

heey

 

What is the std ram (abs) and rom sizes that make a 'stock compatible' Jaguar proggy ?  which means running on a 4MB rom size.

I'm assuming that the generated .abs file must be <= 2048 and .rom file <= 4096.

 

Is 4MB really the maximum rom size available? If anyone can point me to documentation on Jag's rom and memory, that would be great

 

I've heard ppl speaking about bank switching here and there .. how does this work exactly ? Is it possible to use it with Jagstudio to break the 4MB rom limit ?

Would it be supported by vjaguar emulator ?

any documentation on this ?

 

Thx

 

 

Edited November 14 by OzzyOuzo

[Zerosquare]

The hardware has 6 MB of address space mapped to cartridge ROM ($800000 ~ $DFFFFF). Without bank-switching, that's how large your ROM can be (well, since 6 MB ROMs don't exist, you'd use a 8 MB one and end up with 2 MB unused).

 

There's no official bank-switching method. If you need more than 6 MB of ROM space, then you'll need either a Skunkboard or a JagGD cartridge, and check their documentation on how to bank-switch (it may be supported in JagStudio already, I haven't checked). Except for those two, I don't believe there's any publicly available hardware that supports more than 6 MB. I think either Virtual Jaguar or BigPEmu has had support for them added - @CyranoJ can probably answer that.

Edited November 14 by Zerosquare

[+Gemintronic]

At some point you may consider making physical copies of your game.  Anything that uses more ROM than typical has a chance of being harder for you (or others) to make.

 

Coupled with the fact that you're gonna be relying on your own skills dealing with unusual ROM sizes and how well the tools accommodate that.

 

 

UPDATE:  I should clarify this is a general hot take.

[Sporadic]

JagStudio will automatically create a 2 MB ABS or a 2/4/6 MB ROM for you depending on the size of your game and asset locations.

 

The next version of Jagstudio (coming soon)  supports bank switching and GD SD card asset reading. However, as said above, this will limit your game to the GD Cart only. Although the Bank switching will work in BigP with GD emulation enabled in it's settings. 

Edited November 14 by Sporadic

[OzzyOuzo]

Allright thx for all the explanations  

 

Next GD / SD card improvements seem awesome.

 

So for a physical copy on a typical cart i would be good to go with 2MB ABS and 6MB ROM sounds good enough.

 

[Sporadic]

An abs isn't put onto a cart. It would be a 2 MB ROM. 

[42bs]

On 11/15/2024 at 7:10 AM, OzzyOuzo said:

Allright thx for all the explanations  

 

Next GD / SD card improvements seem awesome.

 

So for a physical copy on a typical cart i would be good to go with 2MB ABS and 6MB ROM sounds good enough.

 

You can't have both. Your limits are: 2MB RAM and 6MB ROM. During certain times of your game parts of the ROM are copied to RAM (for speed reason). And of course 2MB is the total amount. You need space for screen objects as well.

[Seedy1812]

I can only speak about Raiden , Bubsy ,DinoDudes and Iwar, To keep costs down we were restricted ( by costs ) to 2 Megabyte Roms, but all the 99% of the data ( and program ) was compressed onto rom. The uncompressed sizes are ( in Megabytes)

 

Raiden 8.16
DinoDudes 5.77

Bubsy 7.54

I-War 4.68



 

 

[42bs]

5 hours ago, Seedy1812 said:

I can only speak about Raiden , Bubsy ,DinoDudes and Iwar, To keep costs down we were restricted ( by costs ) to 2 Megabyte Roms, but all the 99% of the data ( and program ) was compressed onto rom. The uncompressed sizes are ( in Megabytes)

 

Raiden 8.16
DinoDudes 5.77

Bubsy 7.54

I-War 4.68



 

 

With modern compressions even more. Packing the packed Raiden with lz4 gives another 11%

 

Compressed 2097152 bytes into 1861278 bytes ==> 88.75%

Edited November 17 by 42bs

[Seedy1812]

15 hours ago, 42bs said:

With modern compressions even more. Packing the packed Raiden with lz4 gives another 11%

 

Compressed 2097152 bytes into 1861278 bytes ==> 88.75%

As the compressed files do not fill the whole rom if that space is repetitive then you will get more compression.

The rom does not start until address 0x2000 then a gap 0x23b0 to 0x9000 has some code and data (0x260a0 -> 0x2985 ) ( out of date ) 

For 0x9000 onwards is the rom file table ( about 0x1f2cf0 bytes + size of the file table)  then from 0x1fc410-4  you get the repeated pattern of  int32's -1,-1,0,0,0,0,-1,-1 until the end of the rom.

Even if you use 7zip on top of that - then the .jag file comes out as 1,700,901 but if you use it on the unpacked extracted files then that comes down to 897,637 bytes
 

 

[42bs]

7 hours ago, Seedy1812 said:

As the compressed files do not fill the whole rom if that space is repetitive then you will get more compression.

The rom does not start until address 0x2000 then a gap 0x23b0 to 0x9000 has some code and data (0x260a0 -> 0x2985 ) ( out of date ) 

For 0x9000 onwards is the rom file table ( about 0x1f2cf0 bytes + size of the file table)  then from 0x1fc410-4  you get the repeated pattern of  int32's -1,-1,0,0,0,0,-1,-1 until the end of the rom.

Even if you use 7zip on top of that - then the .jag file comes out as 1,700,901 but if you use it on the unpacked extracted files then that comes down to 897,637 bytes
 

 

Well, yes. Did not look inside