|
Post by pierregtt on Feb 21, 2022 13:25:29 GMT
Hello,
As per my understanding 384Kbytes Hucard where built from 2 separate chips: 256KB+128KB rather than one single 512KB one. This is because back in the days, memory was costly and HuCard manufacturer couldn't afford wasting 128KB of unused ROM.
Second point is that for some reason, those 2 chips couldn't be mounted coutiguously by mean of physical address space : a 256KBytes hole had to reside between. Does anyone know why it had to be done this way? A way to simplify Chip Select generation as only one chip had to be selected at a time?
As a consequence, to match this specific mapping, there were TAM instructions in the game which set up banks $40 to $4F for accessing the upper 128K of ROM residing at $80000-$9FFFF physical addresses.
So even if Flashing such games to a single chip, the 256KB hole has to be respected to keep compatible with the TAM instructions or the MPRx would point to unspecified region above the first 512KB of physical space. Resulting ROM file will thus be 640KB.
With emulators such as mednafen, upon detecting a 384KB rom, a 640KB image is automatically created which again is not an issue as it will match the bank mapping.
Only issue is when designing games which are exactly 384K in size, if the developper does not mind that specificity about mednafen (the designer would map upper 128K to $20-$2F, leading to a branch to the 256K hole).
|
|
|
Post by elmer on Feb 21, 2022 15:26:28 GMT
Yep, the construction of 384KB HuCards in that way is a strange piece of history!
We hit this on a homebrew project a few years ago, which is why HuC now defaults to padding the output ROM size to a power-of-two, and why PCEAS spews out a warning message when you choose to produce a 384KB ROM anyway.
|
|
|
Post by pierregtt on Feb 23, 2022 17:40:46 GMT
OK, nice to hear a workaround has been made available from pceas and HuC.
|
|