News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Increasing rom size and resultant bugs  (Read 3905 times)

Daimoth

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Increasing rom size and resultant bugs
« on: August 19, 2014, 12:06:50 am »
Bloated a rom up to 4096 bytes on a whim without adjusting anything and encountered a bunch of bugs. The vanilla rom is just over 2mb and I was really just fiddling aimlessly rather than planning to put all that extra space to immediate use.

I just reverted back to an older copy and the problems went away, but would someone mind explaining why this happened? Does it have something to do with pages or registers? I did read that anything over 4mb will cause problems with some emulators.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7102
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #1 on: August 19, 2014, 02:17:09 am »
Name and console are important information.

But from reading your other post, I see you are probably talking about Demon's Crest.
That game is known to have copy-protection activated by expanding the ROM.
I don't know the details exactly but it tries to detect mirroring. (that is, it tries to read the expanded ROM space not physically present on the cart, which on a real console with a real copy of the game would return data from another part of the ROM)
"My watch says 30 chickens" Google, 2018

Revenant

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #2 on: August 19, 2014, 02:47:14 am »
If this is about Demon's Crest, I actually documented its copy protection a while ago when exploring various Capcom SNES games for material which I've been too lazy to put on tcrf.net (but will eventually, I promise...)

Basically the game checks for SRAM and expanded ROM at two different times. I'll just paste my short notes below:

Code: [Select]
80875A: if $701FFF is mapped, set byte at $7E0EEB to $FF (during capcom logo)
829B33: if byte at $80FFC0 != 40FFC0 (mirroring), set byte at $7E0EED to $FF (when ???)
cannot pause/view menu

80E561: if $701FFF is mapped, set byte at $7E0EEC to $FF (when taking damage)
BEE356: if byte at $80FFC1 != 40FFC1 (mirroring), set byte at $7E0EEE to $FF (when ???)
opening boss (or all bosses/all enemies?) invincible

In an unheadered US ROM (don't know about other regions) you can change the bytes at 011B3E and 1F6361 from FF to 00 to get rid of the ROM-based protection, if that's what's causing your problems, otherwise feel free to post any other important details.

(For anyone interested, I also documented a similar but much crazier protection in Mega Man X here. I plan to add this stuff to TCRF and maybe YouTube at some point, but I'm lazy :P)

henke37

  • Hero Member
  • *****
  • Posts: 643
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #3 on: August 19, 2014, 04:36:52 am »
In other words, you accidentally changed the memory map, removing a mirrored region. This in turn was detected by the copy protection.

Daimoth

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #4 on: August 19, 2014, 10:56:17 am »
Sorry, I assumed slapping on a bunch of empty space would cause issues in general. It's rough being a newb.

I understand that changes to rom size would throw off the memory map, but I don't understand mirroring. I'm reading docs that look like they might contain information about it, but searching for "mirror" or "mirroring" yields nadda. In general, mirroring is writing the same data on multiple drives to ensure reliability. Is that the case here?

henke37

  • Hero Member
  • *****
  • Posts: 643
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #5 on: August 19, 2014, 02:29:29 pm »
Mirroring means that the same data is mapped into multiple places at once. As Reveant tried to say, both address 80FFC0 and address 40FFC0 access the same underlaying memory here.

Daimoth

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #6 on: August 19, 2014, 02:47:38 pm »
Just to clarify, that means that the same data can be referenced from more than one address, not that it's physically there twice, right?

Learning more about memory mapping is what I need to do next, it seems.

Also, why is data mirrored in the first place? Is it done intentionally, or something that happens regardless? If it's an intentional design decision, why is it useful?

I appreciate the patience, especially if this stuff is really old hat.
« Last Edit: August 19, 2014, 03:16:09 pm by Daimoth »

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7102
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #7 on: August 19, 2014, 03:15:36 pm »
Probably something to do with their being only so many pins on the cartridge board (thus number of bits) that a ROM uses, but when the CPU tries to read it's going to get SOMETHING back.

Code: [Select]
16 megabit = 2 MB = 2,097,152 bytes = max address 1FFFFF, so only 21 bits are used, the other 3 are not part of the ROM address.
01FFFF =
00011111 11111111 11111111 11111111 11111111 11111111
   ----- -------- -------- -------- -------- --------
80FFC0 =
10000000 00000000 11111111 11111111 11000000 00000000
   ----- -------- -------- -------- -------- --------
40FFC0
01000000 00000000 11111111 11111111 11000000 00000000
   ----- -------- -------- -------- -------- --------

so 1FFFFF
00011111 11111111 11111111 11111111 11111111 11111111
   ----- -------- -------- -------- -------- --------
and 3FFFFF
00111111 11111111 11111111 11111111 11111111 11111111
   ----- -------- -------- -------- -------- --------
are the same number if you ignore the first 3 bits

But with 4MB, you have the maximum ROM address 3FFFFF, using 22 bits
00111111 11111111 11111111 11111111 11000000 00000000
Now only the first two bits are ignored, and they aren't the same number.

I know that's not EXACTLY correct, but hopefully it gives an idea of what mirroring is.
"My watch says 30 chickens" Google, 2018

Daimoth

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #8 on: August 19, 2014, 04:29:12 pm »
So increasing rom size throws off mirroring because addresses no longer "wrap around" at the same point as before?

Code: [Select]
80875A: if $701FFF is mapped, set byte at $7E0EEB to $FF (during capcom logo)
829B33: if byte at $80FFC0 != 40FFC0 (mirroring), set byte at $7E0EED to $FF (when ???)
cannot pause/view menu

80E561: if $701FFF is mapped, set byte at $7E0EEC to $FF (when taking damage)
BEE356: if byte at $80FFC1 != 40FFC1 (mirroring), set byte at $7E0EEE to $FF (when ???)
opening boss (or all bosses/all enemies?) invincible

Not sure if this is useful information, but your inventory becomes disabled when the hippogriff fight begins. The invincibility kicks in at the beginning of the Arma fight and persists afterward. The destructible pot nearby becomes unkillable, as an example. I didn't check the spider things, though.

Also, if you have any other information about Demon's Crest offsets or anything else, would you mind sharing them with me?
« Last Edit: August 19, 2014, 06:27:59 pm by Daimoth »

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7102
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #9 on: August 20, 2014, 09:15:52 am »
So increasing rom size throws off mirroring because addresses no longer "wrap around" at the same point as before?
That about sums it up.
"My watch says 30 chickens" Google, 2018

Daimoth

  • Jr. Member
  • **
  • Posts: 9
    • View Profile
Re: Increasing rom size and resultant bugs
« Reply #10 on: August 20, 2014, 09:36:01 am »
Then I'll have to break the mirroring checks, then. I hope there's only two like Revenant said!