bsnes v0.033 released

[neviksti]

You'd be amazed, but 99% of SNES ROM hackers think they can just append data directly onto the end of the ROM and it'll always work.

I truly hope that was hyperbole.

Direct means whatever IC gets the read/write command gets the literal address requested. Linear means the address given starts with the value after the IC name (zero if not specified), and it increments each page by the range provided. Shadow means the same as linear, except that you don't ignore the unused portions of each bank, instead you use all 64k. Shadow is for things like how $00:8000 = $c0:8000, and $01:8000 = $c1:8000, not $c1:0000.

With these three, I've been able to support everything in bsnes thus far, and I can support SFX and SA-1 mappings easily.

I like this very much.
It would be nice to add "Mirror" so if there is something that is annoying to specify (maybe a 10Mbit rom's memory map), you only need to specify it for a couple regions and then just say something like:

40-7D:8000-FFFF, Mirror, 00-3D:8000-FFFF
80-BF:8000-FFFF, Mirror, 00-3F:8000-FFFF
C0-FD:8000-FFFF, Mirror, 00-3D:8000-FFFF

Maybe also a list of ICs. For some chips, we need to specify separately two different ROMs. And sometimes there could be two different RAM. And something to specify the RAM size, etc.

But now I'm getting off into possible details.
The point of my post was originally to say: I like the base format suggestion.


I'm so happy that this discussion/argument which has come up so very many times has finally converged on a very awesome compromise (I don't really consider it a compromise as it is better than I was hoping for originally!).

[byuu]

I truly hope that was hyperbole.

I'm sorry if that came off offensive. But based on my observations with other ROM hackers on various message boards (whom I won't name publicly), unfortunately ... I've seen the majority of them simply state that you could "just append zeroes onto the end of the ROM and use it."

But maybe I'm wrong or exaggerating. I haven't spoken to everyone, after all. And maybe they mostly know better now.

Though to be fair, they're right sometimes. Eg a 24mbit -> 32mbit hack would probably be fine, since the mapper itself would just mirror the last 8mbits before (in other words, the top address line of the 8mbit chip would just be left disconnected). But I believe for instance my DL expansion would cause problems, as (IIRC) that PCB only really maps 16mbits of data. I didn't have a PCB system in place to choose a more appropriate mapping, but emulators and copiers don't mind the expansion, and it was definitely necessary.

It would be nice to add "Mirror" so if there is something that is annoying to specify (maybe a 10Mbit rom's memory map), you only need to specify it for a couple regions

It seems to require more typing than specifying it manually, but it does point out that it's a mirror more directly to someone reading it. It may also be a bit harder to parse, but not by much. I'm happy either way.

Which reminds me, I forgot to mention that both linear and direct modes would automatically perform Nach's mirroring algorithm when you exceed the length of the ROM data.

Eg for 10mbits, you would have mirroring like this if you specified ROM for a 32mbit range:
0 1 2 3 4 5 6 7 - 8 9 8 9 8 9 8 9 -- 0 1 2 3 4 5 6 7 - 8 9 8 9 8 9 8 9 ...

That would most likely work for 100% of cases, but if not, we can break it down and be more explicit, specifying each and every bank if we have to.

An emulator would only need to parse that list one time and bind callbacks, so it's not like list size matters.

Maybe also a list of ICs. For some chips, we need to specify separately two different ROMs. And sometimes there could be two different RAM. And something to specify the RAM size, etc.

In my example, the different ROMs were merged into one linear range, and you specified the index into that after the ROM type. However, we could change that to specify the ROM#, eg:
80-8f:8000-ffff, Linear, ROM:0
90-9f:8000-ffff, Linear, ROM:1

Same for RAM. Is there really a game with two RAM chips? Well, besides the BS-X and Sufami Turbo stuff? Boy, that's going to be fun.

I'm so happy that this discussion/argument which has come up so very many times has finally converged on a very awesome compromise (I don't really consider it a compromise as it is better than I was hoping for originally!).

Likewise :D
You can see my biggest flaw, I tend to give up too easily.

[henke37]

Uhm, didn't the SFX have this access control system for the rom and ram busses too? Your proposed syntax doesn't account for this.

To join in on the fun:
What if some crazy game relies on this buss control system? Can't just make the reads work properly then.

[neviksti]

Uhm, didn't the SFX have this access control system for the rom and ram busses too? Your proposed syntax doesn't account for this.

To join in on the fun:
What if some crazy game relies on this buss control system? Can't just make the reads work properly then.

Unless you go and make/hack your own cartridge that adds in an extra layer of control, all that really has been done "cart hacking" wise for these chips is just swapping rom (well, I guess that isn't technically true, but no one expects emulators to run what bizarre creations TheDumper, I, or others created solely for snes game special chip hardware tests). So whether or not rom or ram is connected, and how much, is all that needs to be known for these "extra bus" special chips.

Going beyond that "just in case" seems extreme.

[tetsuo55]

And without the ridiculous XML red tape:

Code: Select all

# SPC7110 (cheating example, SRAM needs to go thru SPC7110 chip to support SRAM disable command)
00:6000-7fff, Linear, RAM
00-0f:8000-ffff, Shadow, ROM
30:6000-7fff, Linear, RAM
50:0000-ffff, Direct, SPC7110
80-8f:8000-ffff, Shadow, ROM
c0-cf:0000-ffff, Linear, ROM
d0-ff:0000-ffff, Direct, SPC7110

Code: Select all

# BSC-1A7M-20
00-1f:8000-ffff, Linear, ROM
20-3f:8000-ffff, Linear, ROM, 100000
70-7f:0000-7fff, Linear, RAM
80-9f:8000-ffff, Linear, ROM, 200000
a0-bf:8000-ffff, Linear, ROM, 100000
c0-ef:0000-ffff, Direct, BSX-Flashcart
f0-ff:0000-7fff, Linear, RAM

Direct means whatever IC gets the read/write command gets the literal address requested. Linear means the address given starts with the value after the IC name (zero if not specified), and it increments each page by the range provided. Shadow means the same as linear, except that you don't ignore the unused portions of each bank, instead you use all 64k. Shadow is for things like how $00:8000 = $c0:8000, and $01:8000 = $c1:8000, not $c1:0000.

With these three, I've been able to support everything in bsnes thus far, and I can support SFX and SA-1 mappings easily.

i'm going to reply to this from several perspectives.

From a snes only viewpoint : Cool i love it, simple plain text and it works for every case except multi-slot cards i think, but that shouldn't be too hard to add.

From a multiplatform viewpoint: It seems fine for snes but not for other platforms, its basically another way of doing it added to the confusing mix

From a dumper viewpoint: Why can't all these damn headers(data collected besides the raw binary data) be the same.

From a frontend creator/user viewpoint: If a universal file was made i would only have to parse the data once, and end users wouldn't have to use xxx folders with add-ons and i wouldn't have to think of ways of getting the data in 1 view.

-----

A universal format is going to take more time to be developed, what you suggests works fine for the snes. There is not reason why the upcoming universal file can not be stored next to the pcb.id file in the same zip file right?


Byuu the suggested format on mess tries to achieve the following:
The file basically makes the zip file immitate the media the console is expecting, the file connects to the pinout, or drive of the console.
Some games have cpu's built in or slots built in. The file maps those too, so after loading a game, every useable built in hardware is available for use.

This means that a zip file could contain a slotted game, and a slot-addon, all pre-mapped by the file, same could be done for the snes-gameboy-addon (if the gb part was ever emulated).

Also emulator logic could simply be updated to ask if you want to put something in the newly available slots, you can either choose no or choose one of the add-on cards

Do you think this is possible with the example you gave?

Uhm, didn't the SFX have this access control system for the rom and ram busses too? Your proposed syntax doesn't account for this.

To join in on the fun:
What if some crazy game relies on this buss control system? Can't just make the reads work properly then.

Unless you go and make/hack your own cartridge that adds in an extra layer of control, all that really has been done "cart hacking" wise for these chips is just swapping rom (well, I guess that isn't technically true, but no one expects emulators to run what bizarre creations TheDumper, I, or others created solely for snes game special chip hardware tests). So whether or not rom or ram is connected, and how much, is all that needs to be known for these "extra bus" special chips.

Going beyond that "just in case" seems extreme.

This is exactly the type of thing that can easily be done with the proposed format over at mess.

PS does anyone know a better way of storing all the needed and optional information in a different standard than XML?

[creaothceann]

From a multiplatform viewpoint: It seems fine for snes but not for other platforms, its basically another way of doing it added to the confusing mix

Yeah, but we're emulating only one system here, right?

PS does anyone know a better way of storing all the needed and optional information in a different standard than XML?

I've posted one, imo...

[FitzRoy]

Also emulator logic could simply be updated to ask if you want to put something in the newly available slots, you can either choose no or choose one of the add-on cards

You can already do that through bsnes' file loading mechanism, and that's exactly how it should be done it other emulators. Requiring people to move their files and modify a text file every time just to accomplish some kind of auto-loading seems even more laborious and stupid.

pcb.id

My understanding was that we would also be able to identify the boards from the outside filename. Most boards DID have names, and that's what they should be identified as, not coprocessors or what have you. Ex:

BSC-1A7M-20.pcb

[tetsuo55]

From a multiplatform viewpoint: It seems fine for snes but not for other platforms, its basically another way of doing it added to the confusing mix

Yeah, but we're emulating only one system here, right?

PS does anyone know a better way of storing all the needed and optional information in a different standard than XML?

I've posted one, imo...

I am a multi-emulator guy myself, i have retired all my hardware into a display. I'm also a datter/dumper and i have been waiting for a single way of storing data for every platform for quite some time now.

i just scrolled back to your post, i like that way of storing data better than XML too

Also emulator logic could simply be updated to ask if you want to put something in the newly available slots, you can either choose no or choose one of the add-on cards

You can already do that through bsnes' file loading mechanism, and that's exactly how it should be done it other emulators. Requiring people to move their files and modify a text file every time just to accomplish some kind of auto-loading seems even more laborious and stupid.

pcb.id

My understanding was that we would also be able to identify the boards from the outside filename. Most boards DID have names, and that's what they should be identified as, not coprocessors or what have you. Ex:

BSC-1A7M-20.pcb

it gives you the option to edit the files ,by default for the end user nothing would change from the current loading options. How ever i do not see any problem with making emulators a little smarter though.

I fully agree with the file name!!

[FitzRoy]

I am a multi-emulator guy myself, i have retired all my hardware into a display. I'm also a datter/dumper and i have been waiting for a single way of storing data for every platform for quite some time now.

I don't live in an SNES vaccum either, and it ought to be generic enough for each system to adopt it, a pcb is a pcb. The important thing right now is that it just gets done and implemented to prove how awesome and simple it is, and how stupid we were for putting up with proprietary header formats all these years. I suspect that once more emulators adopt pcb, dumpers other than myself (the bulk of which dump the data and nothing more) will finally start documenting this stuff when they see their emulators using it. That's the only reason they aren't doing it. It pisses me off to see rare $150 carts getting acquired and dumped and sold, and the dumper never bothered to document the cart or pcb serials when he had the chance.

[byuu]

With the compromise Nach and I were discussing, the PCB ID would be stored in eg the NSRT database. The emulator would just get the mapping.

Although maybe if I promise to ignore it in the emulator, I can convince him to include the name of the board as an optional comment in the PCB text file. It would be nice as a quick reference, and to display under a "Cartridge Info ..." option.

That has the problem that an end user's real cart might have a different PCB, but it does at least say which one we are using.

But we would be including a filename.pcb for each filename.sfc, and not a PCB database for each mapper.

He makes a good point as well, it keeps knowledge of cartridges outside of the emulator, and that's a really good thing. We won't have to release PCB "packs" to get games running, nor will we have to hard-code stuff a hardware emulator really shouldn't know anyway.

---

Anyway, as for a universal format ... I didn't work on MESS because I don't care for trying to hammer every last peg into a square hole. An SNES cart is not an arcade board -- we should use what's appropriate for SNES carts. If we can come up with something that will appease universal format people, great. But I don't intend to over-complicate this format for its sake.

[FitzRoy]

Although maybe if I promise to ignore it in the emulator

I'm not asking you to "recognize" the serials for anything. All the emulator needs to do is recognize that a file with the .pcb extension is present with a rom and use its contents. But the name, for sanity's sake, should be the name of the documented board for that game. When NSRT is creating these files, the file should not be named something arbitrary or generic like the NES mapper system. Yes, I realize that two different PCB names could have the same mapping. Do not take that redundant operation between them to mean that you now must now try to simplify reality by renaming them both to "Mapper1" or an equivalent. If you name the pcb file the name of the game itself, not only can we not see what pcbs the game had just by looking at the filename, but it won't work with a name that doesn't match the filename. But as long as you detect the pcb file regardless of the filename, I can distribute the files the way I want regardless of what NSRT does. That would make me very happy.

[byuu]

Seems we have a misunderstanding.

You would have chrono.sfc + chrono.pcb. You can put them both in a ZIP or something if you really want. But it has to be chrono.pcb, because otherwise if you extract it, you'll have no way to cross-reference chrono.sfc with SHVC-EXAM-PL.pcb.

Inside chrono.pcb, we may have a line that tells you what board it is as a comment, but we'll definitely have the actual raw mapping that the emulator can make direct use of, which would be like the examples above: 00-3f, 8000-ffff, ROM; etc.

The hardest part of this would be different emulators handling special chips differently. Eg you probably don't want to map SPC7110 SRAM directly, because the SPC7110 regs can disable write access to it.

Some emulators may want direct mapping for DSP-1 MMIO range, some may want linear mapping. We'll have to work this out.

[FitzRoy]

You would have chrono.sfc + chrono.pcb. You can put them both in a ZIP or something if you really want. But it has to be chrono.pcb, because otherwise if you extract it, you'll have no way to cross-reference chrono.sfc with SHVC-EXAM-PL.pcb.

If the emulator detects multiple pcb files in the archive or folder, trigger a selection prompt. Problem solved, people can name these anything they want. And that's good, because these files are pcbs, not games. They're not unique like the games. Many games shared the same kind of pcb.

[byuu]

... so what if the user has 4,000 games and 50 PCB files in a big ROM folder? Now they get a list of 50 boards to choose from, and only roughly one half of them will run the game they want :/

Many games shared the same kind of pcb.

True. I would've preferred the games just say what PCB they want and go with that for that reason. But that means the emulator needs to understand the PCB, or you need another folder full of PCB->raw mapping lookups. Either way, you end up making your emulator require database info that it really shouldn't, which is Nach's point.

So by storing chrono.pcb, it contains the raw info the emulator needs. Yes, it will be redundant, having all of the mapping for all 4k games, but it will only be 1kb per file at best.

[FitzRoy]

... so what if the user has 4,000 games and 50 PCB files in a big ROM folder? Now they get a list of 50 boards to choose from, and only one half of them will work :/

Which could be referenced, but I'm assuming the use of archives. But if someone didn't want to use archives for some reason, yes, that's still better than the alternative of 8,000 total files in one folder, all of which must be named exactly the same as their corresponding rom. That's not easy... unless you use an elaborate program like NSRT or Goodtools and concede to their tags and naming scheme.

[byuu]

That's not easy... unless you use an elaborate program like NSRT or Goodtools and concede to their tags and naming scheme.

Do not mention NSRT. How's the weather, by the way? And "GoodTools" in the same sentence, please D:<

But yes, you have a point. Those who store their ROMs uncompressed will be in trouble. And it'll force me to build all of my WIPs with archive support.

But we have to support romname.sfc + romname.pcb together, it will be necessary for anyone working on their own game or a hack to be able to change the mapping without needing to re-zip files constantly.

I mean, I'll tell you now, it would be really annoying writing my SNES testing programs, if I had to keep making maps and adding the ROM+PCB to ZIP files before I could test them.

[FitzRoy]

But we have to support romname.sfc + romname.pcb together, it will be necessary for anyone working on their own game or a hack to be able to change the mapping without needing to re-zip files constantly.

No, they'd just have to create a subfolder and plop them in there.

[creaothceann]

Right. If the directory exists, use that, otherwise search for the zip.

[wertigon]

Great work on the SPC7110 chip.

So, any plans on the SA-1 and SuperFX chips, yet? Or would that require like, a ten gigaflop super computer to emulate?

[byuu]

Alright, new WIP. Added a new feature so people will stop harassing me about it :P

Try and guess what it is.

[tetsuo55]

Alright, new WIP. Added a new feature so people will stop harassing me about it

Try and guess what it is.

I won't spoil the surprise just yet!

Thanks byuu!!!!!!!!!!!!!!!!

[Snark]

Great work on the SPC7110 chip.

So, any plans on the SA-1 and SuperFX chips, yet? Or would that require like, a ten gigaflop super computer to emulate?

Someone correct me but aren't supercomputers just multiples computers that works together to combine their powers? So if we presently can't take advantage of multiple cores to gain speed (for accurate Snes emulation anyway) it should be the same with "supercomputers".

That would sorta of rock though.. "Bsnes: too demanding for today's fastest supercomputer"

[DOLLS (J) [!]]

Alright, new WIP. Added a new feature so people will stop harassing me about it

Try and guess what it is.

Where does one get the WIP?

[FitzRoy]

Right. If the directory exists, use that, otherwise search for the zip.

Well, treat a zip archive like a folder. Autodetection is only done in the "folder" where the loaded rom is, if that's what you mean.

Alright, new WIP. Added a new feature so people will stop harassing me about it

Try and guess what it is.

Let's see, special controllers were brought up yet again in a somewhat unrelated debate, and it is by far the largest request. I won't be able to check till Monday night, though.

[I.S.T.]

Alright, new WIP. Added a new feature so people will stop harassing me about it

Try and guess what it is.

Interesting addition.