Emulation and arbitrarily sized ROMs

0 users browsing Emulation. | 1 bot

Main » Emulation » Emulation and arbitrarily sized ROMs

Pages: 1

KingMike

Posted on 19-04-14, 17:13

Post: #18 of 36
Since: 12-21-18

Last post: 1207 days
Last view: 115 days

So there's a guy on RHDN who was released a few SNES hacks.
He just expands it to whatever oddball size it comes out. (say like Final Fight, but with say 150 bytes added on)

SNES9x does not like that and his response is like "sorry SNES9x sucks use higan". (after being told the first time just like "It's probably a good idea to expand your ROM to a more sane size first. WindHex can do it in a couple clicks...")
Too me it sounds like a bad idea, at least in stability to not expand to a certain size (what does SNES9x expect, to at lesat a full bank?) because you know, when writing code, you will screw up something somewhere.

But I wonder if you know, just how bad the potential for out-of-bounds errors with incomplete ROM banks.
I would guess the rest of CPU space is just random garbage?

I thought I should ask the principle to you, byuu, the one who defines Spectre as a 7mbit game? Is there any reason it shouldn't be 6.98731 mbit or whatever the used data comes out to? :)

BearOso	Posted on 19-04-14, 18:02 Hi.
Post: #72 of 175 Since: 10-30-18 Last post: 1451 days Last view: 1451 days	No, it's not sane. You'd need to expand to something like 32k boundaries at least, but something that could be represented by an actual layout of memory chips and mapping would be correct. icarus is probably smart enough to guess it's a partial bank or something. Snes9x seems to use 8k chunks internally, but truncates. Don't know if it'll resolve said insanity, but I'll fix that to round up.

creaothceann	Posted on 19-04-14, 19:08 Hi.
Post: #116 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day	I'd just reject any such ROM. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Near

Posted on 19-04-15, 01:32 (revision 1)

Burned-out Genius Developer
Post: #29 of 51
Since: 10-30-18

Last post: 1419 days
Last view: 1342 days

> He just expands it to whatever oddball size it comes out. (say like Final Fight, but with say 150 bytes added on)

Most images from the SNES copier / early demoscene era were like this, which is why bsnes can load these images. Although few will run properly because I don't also zero-fill RAM like old copiers did, and most of those games also don't initialize RAM or registers first. But I do intend to offer a compatibility mode at some point.

> "sorry SNES9x sucks use higan"

Now there's a statement I never thought I'd hear >_>

> But I wonder if you know, just how bad the potential for out-of-bounds errors with incomplete ROM banks. I would guess the rest of CPU space is just random garbage?

higan uses a function (hat tip to Nach for the idea) to presume any arbitrary file is comprised of increasingly smaller ROM chips, that are all powers of two, and then mirrors them up from there.

So say you had an 11mbit game: 0123456789a----- You could say this is an 8mbit + 2mbit + 1mbit cart. So keep doubling the size of the smallest ROM until it fills the space. So 1mbit->2mbit of a = a a. So then we have 0123456789aa----. Now it's as if we have an 8mbit + 4mbit game. Do the same thing again, 4mbit->8mbit. 89aa 89aa. So the result is 0123456789aa89aa. If you had a 9mbit game, it'd be 0123456788888888. You go until the ROM size is a power of two.

If you have a real ROM chip, it may not truly be a power of two. There are single-ROM chip games on the SNES that are actually 24mbit. The datasheets list them as 3072kbit chips. But from an electronics perspective, there will be a set number of pins. And the total addressable values will always be 1 << address lines. Or 2^address lines. The ROM chips themselves simply ignore the second-most address bit when the highest address bit is set. So it's the same as with the algorithm above.

This actually would be a problem if people made RAM chips this way: writing to one address would modify two readable locations. But in the 25 systems I support, I've yet to encounter a RAM, EEPROM, or Flash chip that wasn't a power of two. I know they exist however.

> I thought I should ask the principle to you, byuu, the one who defines Spectre as a 7mbit game? Is there any reason it shouldn't be 6.98731 mbit or whatever the used data comes out to? :)

I can't tell the difference between the same game released as 1x 32mbit with 8mbit mirrored, 1x actually a true 24mbit chip, and 1x 16mbit + 1x 8mbit boards. And when you run my algorithm above, it produces the same file either way. So ***it doesn't matter at all***. My PCB scans show you the ROM chips, and if they have part#s, you can try to confirm it. But a lot of the later Majesco 1x 32mbit boards do not.

You all know how incredibly obsessive my interest is with the SNES and getting everything absolutely perfect. You all know why I'm like that. And if I'm telling you it doesn't matter, then ... maybe trust me on that one :P

Absolutely everyone who ever maintained a ROM database agrees that a 24mbit game is 24mbit, and that 32mbit with 8mbit mirrored is an overdump.

The reason my Spectre dump is 7mbit is because the tool I wrote to remove overdumping stops at a 1mbit boundary. I chose 1mbit because it's the smallest whole number in SNES unit sizes (every SNES game is referred to in megabits.) That's all. It was completely arbitrary, and it bothers me a bit that my decision resulted in confusion like this:
https://datomatic.no-intro.org/index.php?page=show_record&s=49&n=3336
"Overdumped according currently ROM hash information from byuu"

I don't know what the community consensus was, but in hindsight it sounds like most people think 4mbit (0.5MiB) is the gold standard?

But you're right, it's arbitrary. If the very last two bytes were repeated, you could cut just one of them off if you stopped at the byte boundary.

I really don't care, and I would be very happy if I never had to address this topic again :P

> No, it's not sane. You'd need to expand to something like 32k boundaries at least

You're going to hate my Devil's Advocate here, but ... you could make a 2k SNES game. In fact, I have one. blargg modified a sports game cart to map RAM in place of ROM for me, and I used that as a devcart to launch my USART serial loader prior to the 21fx by defparam. The 2k would just be mirrored to fill 8000-ffff, so if you only have 0000-1fff, then your vectors would go at 1fxx. There is nothing preventing a 1-byte SNES ROM, other than it not being terribly useful. 21fx is 124 bytes and is obscenely useful to me.

In practice, the smallest licensed SNES game I know of is 256k for Space Invaders. Some of the Nintendo Power releases were very odd sizes like 5mbit and padded with FF bytes.

Lastly, I'll just add that since it doesn't seem likely SNES9x will ever support DSP LLE, you might want to consider how appended coprocessor firmware behaves in SNES9x, for the six people in the world who agreed with me on that one who may try running those games in SNES9x. They work according to my own testing, but if you change how things mirror, then I don't know. Just mentioning it, you're free to handle this however you like, or not at all.

BearOso

Posted on 19-04-15, 01:43 (revision 1)

Post: #73 of 175
Since: 10-30-18

Last post: 1451 days
Last view: 1451 days

Posted by byuu

You're going to hate my Devil's Advocate here, but ... you could make a 2k SNES game. In fact, I have one. blargg modified a sports game cart to map RAM in place of ROM for me, and I used that as a devcart to launch my USART serial loader prior to the 21fx by defparam. The 2k would just be mirrored to fill 8000-ffff, so if you only have 0000-1fff, then your vectors would go at 1fxx.

I figured there might be a counterexample, but I stand by my statement: that’s still insane. Plus, the OP is about ROM size, not RAM size. :-)

*edit* I’ll check appended firmware to make sure it still works.

Near

Posted on 19-04-15, 10:59

Burned-out Genius Developer
Post: #30 of 51
Since: 10-30-18

Last post: 1419 days
Last view: 1342 days

> I figured there might be a counterexample, but I stand by my statement: that’s still insane.

There's nothing folks on the internet do better than "well, actually..."

We should make sure every child has food. Internet: "well, actually..."
We should research cures for deadly diseases. Internet: "well, what about..."

I'm not above it, apparently :P

But yes, it's completely insane. If you're willing to reject the ROMs, I'd be willing to consider doing the same in higan.

CaptainJistuce

Posted on 19-04-15, 12:11

Custom title here

Post: #406 of 1164
Since: 10-30-18

Last post: 63 days
Last view: 13 hours

Posted by byuu

> "sorry SNES9x sucks use higan"

Now there's a statement I never thought I'd hear >_>

You're winning! Another decade or two and you may be number one!

This actually would be a problem if people made RAM chips this way: writing to one address would modify two readable locations. But in the 25 systems I support, I've yet to encounter a RAM, EEPROM, or Flash chip that wasn't a power of two. I know they exist however.

I know of some systems that do that, but at a board-level rather than chip-level.

(In fact, the scratchpad RAM on my 99/4a is that way. There's a 1K block reserved for the scratchpad RAM, but they only installed 256 bytes because SRAMs were expensive, and the same quarter-K is readable and writable at all four "slots" in the reserved address block.)

--- In UTF-16, where available. ---

BearOso

Posted on 19-04-15, 16:40

Post: #74 of 175
Since: 10-30-18

Last post: 1451 days
Last view: 1451 days

Posted by byuu

But yes, it's completely insane. If you're willing to reject the ROMs, I'd be willing to consider doing the same in higan.

It's easier to just accept them for now. I tested some appended firmware and it seems to still be fine. The DSP firmware is 8k, so it would have been mapped and not truncated even with the prior behavior, so I don't think it's going to break anything except the checksum.

Near

Posted on 19-04-15, 19:44

Burned-out Genius Developer
Post: #31 of 51
Since: 10-30-18

Last post: 1419 days
Last view: 1342 days

> You're winning! Another decade or two and you may be number one!

I have a strong feeling neither bsnes nor Snes9X will be in the top spot in a decade. We'll see.

> There's a 1K block reserved for the scratchpad RAM, but they only installed 256 bytes because SRAMs were expensive, and the same quarter-K is readable and writable at all four "slots" in the reserved address block.

That's easy mode, it's still a power of two so you just mask the address. But if it's 3072 bytes in a 4096 byte space, you have a real problem. Not even a painful modulo will work because that'll make 0xc00=0x000 instead of 0xc00=0x800.

If it's part of the system you can hard-code this in a lot of ways. But when it's a cartridge, it will be very annoying to support. higan/bsnes' SNES mapping code can do it because it's byte-level, but that's the most heavy-handed solution possible for the problem.

> The DSP firmware is 8k, so it would have been mapped and not truncated even with the prior behavior, so I don't think it's going to break anything except the checksum.

I have code to detect all of the firmware files being appended. I have a rule that copier headers and firmware aren't compatible, so that gives us:

https://gitlab.com/higan/higan/blob/master/icarus/heuristics/super-famicom.cpp#L412

  if((size() &  0x7fff) ==   0x200) return removeCopierHeader();
  if((size() &  0x7fff) ==   0x100) return size() -   0x100;  //Super Game Boy 1&2
  if((size() &  0x7fff) ==   0xc00) return size() -   0xc00;  //Cx4
  if((size() &  0x7fff) ==  0x2000) return size() -  0x2000;  //DSP-1,1B,2,3,4
  if((size() &  0xffff) ==  0xd000) return size() -  0xd000;  //ST010 & ST011
  if((size() & 0x3ffff) == 0x28000) return size() - 0x28000;  //ST018

Well anyway, it's not important. It failed to get any kind of adoption and I gave up so much on trying that I just re-added DSP HLE support instead.

Pages: 1

Main » Emulation » Emulation and arbitrarily sized ROMs

bboard