bsnes v0.038 released

[FirebrandX]

Hola byuu, is there by chance a way to set bsnes to default to fullscreen on startup? Reason I ask is because I use powerstrip to automatically apply a custom resolution whenever I run bsnes (avoids software aspect correction, which I've never been a fan of).

Also, and I hate to ask since I got yelled at by a zsnes dev last time, but what exactly is not getting emulated properly that causes the bi-plane demo to fail everytime in Pilotwings? I've always been curious to learn why that particular demo fails, yet all the other ones run flawlessly.

[Jipcy]

is there by chance a way to set bsnes to default to fullscreen on startup?

The config file likely.

[byuu]

(Of course, if you claim you can, I'll be glad to pay you a visit and administer a 50 caliber hearing test.)

To be fair, you don't really start to hear the difference until you reach at least 1,356KHz / 128-bit audio. Of course, all that's worthless without a really good potentiometer to go along with it.

New changes look good. However, I think we need to clarify the semantic use of "adjust."

>_>;

Hola byuu, is there by chance a way to set bsnes to default to fullscreen on startup?

Not at present, no.

Also, and I hate to ask since I got yelled at by a zsnes dev last time, but what exactly is not getting emulated properly that causes the bi-plane demo to fail everytime in Pilotwings? I've always been curious to learn why that particular demo fails, yet all the other ones run flawlessly.

It's been asked a few hundred times now, so I'm sure you can understand the frustration of repeating it (note: I don't mind here.)

There are three revisions of the DSP-1 chip. All three are emulated to bit-perfection, but emulators use the newest revision that has important bug fixes needed by other games. Pilotwings shipped with an older revision. There's also a lack of timing for DSP-1 opcodes that probably isn't helping Pilotwings, Suzaku 8 Hours, et al.

I don't have enough time+interest to make the DSP revision selectable from the emulator, but you can compile the emulator with the change if you want on your side.

[FirebrandX]

Ah I see. So in theory, you could have all the DSP chips emulated and a built in autoselector within the emulator to use the correct one, right?

[tetsuo55]

te best way i have found currently to avoid most of the resampling is

Pre-resample to 32bit/96khz, then asio to soundcard which outputs 24/96 to the dac.

It sounds a LOT better than directsound.

I bet you can't back that with double blind testing.

Actually i always do double-blind in the form of a ABX test for this kind of things. Small group of family members take the test while i play the samples.

In the case of asioVSdirectsound they chose asio in 90% of the samples.
Maybe the diffrence should not be this obvious and something unrelated is wrong with my system causing the big difference

[funkyass]

ABX is a double blind testing tool, not a double blind test.

proper testing requires two things, a experiment and a control group. A double blind test is where the experimenter doesn't know the composition of either group, and those in both groups have no knowledge of the experimenter or the other group.

Therefore, tetsuso is unlikely to back up his claims experimentally.

[tetsuo55]

Well a control group in this case would mean that that group would only get to hear either DS or ASIO, but not the other.
Only the test group would get to hear both.

Although normally that would be a good idea i did not bother, as random friends and family have already asked about the change in sound quality eventhough they did not know about the test/changes.

But like i said its probably a hardware/software bug that causes the difference

[henke37]

Yeah, about the plugins requiring OO, just downgrade the object to a struct, it's not really a hard thing to think of.

[FitzRoy]

Ah I see. So in theory, you could have all the DSP chips emulated and a built in autoselector within the emulator to use the correct one, right?

I think this is one of those weird circumstances where a discreet internal db hack would be best. There's absolutely no way to represent the coprocessor as an external file alongside the rom. There's nothing more clean about a user pointing to something housed in the emulator through a selection box or a sanctioned header/pcb field, so it may as well be the program to save them the trouble. If it made anyone feel any better, it could be disabled/enabled as an advanced option.

>_>;

So my nitpicking finally got to you, huh? Hey, I'm just trying to prevent you from being accused of performing miracles. An image having brightness at zero brightness is some feat. Negative brightness even moreso.

[byuu]

So in theory, you could have all the DSP chips emulated and a built in autoselector within the emulator to use the correct one, right?

Code would have to be re-written, it's built with #defines so you can only select the chip version at compile time. If someone wanted to change that to run-time checks (I don't), then yes.

But like i said its probably a hardware/software bug that causes the difference

Yeah, who knows. Could definitely be software, as this is the only audio app I've ever made.

Speaking of which, belegdol, you might try buffering the samples written per block to help with Pulseaudio ... about all I can think of.

I think this is one of those weird circumstances where a discreet internal db hack would be best.

There's only 20 or so games, I'm sure Nach could make a header formula ala BS-X slotted carts to determine the DSP-1 revision, if he hasn't already :P

There's nothing more clean about a user pointing to something housed in the emulator through a selection box or a sanctioned header/pcb field

Definitely agreed there. Nobody sane is going to know which games use which revision of the chip off the top of their heads, and the 1B is probably "better" in the same way hires-mode7 was in Snes9X -- plane demos aside.

So my nitpicking finally got to you, huh?

Nah, no more than usual. I'm grateful that anyone cares enough to help clean it up. Programming and artistic design clearly do not go hand in hand (exhibit A: my website.)

I do wish we could get it perfected already, though ;)

[FitzRoy]

There's only 20 or so games, I'm sure Nach could make a header formula ala BS-X slotted carts to determine the DSP-1 revision, if he hasn't already

I imagine hardware revisions for the CPU and PPU processors will be selectable in the advanced section at some point? I think this would be a good place for DSP1 processor revisions as well. It only seems logical, it's another processor handled within the emulator. This would just be for people who want to avoid depending on headers (me) and it wouldn't be as elaborate as db hacks.

What a pain in the ass this coprocessor business is. If the rom had gone as far as to reflect the revision (DSP1A) instead of just the type (DSP1), you wouldn't have had to deal with this issue.

[Nach]

So in theory, you could have all the DSP chips emulated and a built in autoselector within the emulator to use the correct one, right?

Code would have to be re-written, it's built with #defines so you can only select the chip version at compile time. If someone wanted to change that to run-time checks (I don't), then yes.

Still doesn't matter much.
The DSP code we have is quite dumb that instead of using data from within the data ROM for many of the functions, the same tables and values are hard coded into arrays and variables elsewhere, and used.
The code would have to be rewritten to either have the code properly pull those tables from the data ROM instead of our own hard coded tables, or make them a pointer which points to the correct spot.
Once that's done, then we can actually change the data ROM.

There's only 20 or so games, I'm sure Nach could make a header formula ala BS-X slotted carts to determine the DSP-1 revision, if he hasn't already

You really are missing the point.
The code may seem magic to those who never read Nintendo's header specs, or bothered to see the meaning for each of the values.
You may like to ignore what it says, but these headers have dates, and memory sizes, and keywords written in them which are quite sufficient most of the time.

I can't make code like the BS-X carts to determine DSP-1 revision, such data isn't there.

However, there is Nintendo DSP data written in the carts, which are not the same between them. If you read the ZSNES board way back when, and multiple versions of the DSP was being discussed, you'll recall I posted some algorithms for telling them apart. However, at the time, I didn't know what interleaving was, and I had the luck that the person who gave me DSP-1B ROM images to inspect had all of those interleaved. Based on my noticing something fishy about all those carts, I was able to determine they were all DSP-1B, once learning they were interleaved though, all that work had to be scrapped, and instead became interleave detection. I haven't found anything set to determine which DSP-1 flavor was used, probably because it's not supposed to matter, half the various games were shipped with several versions throughout their life span, and the early games all boot on DSP-1B.

However, if Pilotwings does in fact matter, it is the only "LoROM" DSP-1 game. It doesn't say much though, also if it is determined that Suzuka 8 Hours is also affected. However such problems could be timing related, not data ROM related, so not much of a point of going wild with anything till the exact cause of the issue is pinpointed.

Furthermore, I can easily convert any normal "LoROM" game to "HiROM", and my program handles Pilotwings just fine.

[byuu]

You really are missing the point.

No, I understand the difference. But we still use a lot of magic in our ROM loading code: header location scoring, Ys 3 vs Fire Emblem: Thracia 776 SRAM mapping detection, etc.

And strictly speaking, the data in the ROM does not matter. It doesn't matter that Nintendo enforced a set of rules. It's still data. If you modify that data and replace the ROM chips, it will still run. Hardware doesn't look at it, and it sucks to me that emulators do.

I like the alternative idea of a massive database for every game even less, though.

half the various games were shipped with several versions throughout their life span, and the early games all boot on DSP-1B.

In that case, default to the newest revision observed in the wild, and allow the user to select all older versions that we've also observed on real carts. Sloppy, definitely.

I don't think it's a big deal, but we'll keep getting asked the question over and over again until we get Pilotwings mapping to the DSP-1 somehow :/

If any of us made a commitment to accurate special chip emulation, then it would be cause for concern. Since we all treat the DSP-n chips as magic quantum machines that can compute any 3D calculation instantaneously, it's really a moot point to bother with chip selection at all at present.

I really, really hate these damn special chips. I want to work on the base SNES, I've wasted months on roughly a dozen chips, and people still aren't happy because I don't implement the two most complicated chips around.

Furthermore, I can easily convert any normal "LoROM" game to "HiROM", and my program handles Pilotwings just fine.

Any normal one less than or equal to 2MB, at least :P
Neat idea, though.

[neviksti]

And strictly speaking, the data in the ROM does not matter. It doesn't matter that Nintendo enforced a set of rules. It's still data. If you modify that data and replace the ROM chips, it will still run. Hardware doesn't look at it, and it sucks to me that emulators do.

I like the alternative idea of a massive database for every game even less, though.

This argument continues to poke its head up. Nach feels the rom is enough to determine what the cartridge hardware is. It is my understanding that you and I feel that while this is in practice possible for known games, it is a heuristic and we are literally guessing what the cartridge hardware is ... and one needs to tweak and fiddle with the heuristic until it works well. To claim this is more than guessing using an intelligently designed heuristic is what always pushes my buttons on this issue.

I liked that in Overload's emulator I could tell it exactly how to map the cartridge rom, and it was the only emulator I could use to debug the SDD1less StarOcean hacks. It is a shame that something which runs on the real system as a simple static map couldn't be run on other emulators because I couldn't fit it into the heuristic that was built up. (By the way, where are people getting that hack from? I don't see it in any online repository, nor do I know of existing links to it, but I still get questions every month or so from people trying to use it on the SNES.)

Laugh or not, when I first started working on the snes there were some people that believed the SNES memory map somehow was selected by these values in the header. To finally separate the cartridge memory map from the SNES memory map I feel was a great step (this seemed to happen in earnest when open bus and such was emulated correctly).

--

Look, when it comes to the "correct approach", the multitude will never agree. But there is no denying that the emulators are currently being fed only part of the cartridge, and they are expected to guess the rest.

Luckily Byuu and Nach came to a great compromise last time this came up. I don't know how much my opinion matters since, while I've helped with research at times, I never code the final implementation in emulators ... but even I, on the more 'hardware oriented' side of the argument, thought the compromise you guys came up with was a great "roadmap" for how to forge ahead.

Can I humbly suggest we take advantage of this common ground, and start working towards ending this problem?
How about we start open discussion on the cartridge format to be used in this roadmap.
Byuu's suggestion looks great, but it would be nice to hear from another romhacker than byuu (say Nightcrawler), and maybe another hardware person (say d4s, who also does homebrew) ... so that we don't get too commited before we see a subtle problem with the setup.

[Nach]

You really are missing the point.

No, I understand the difference. But we still use a lot of magic in our ROM loading code: header location scoring, Ys 3 vs Fire Emblem: Thracia 776 SRAM mapping detection, etc.

And strictly speaking, the data in the ROM does not matter. It doesn't matter that Nintendo enforced a set of rules. It's still data. If you modify that data and replace the ROM chips, it will still run. Hardware doesn't look at it, and it sucks to me that emulators do.

With this brought up over and over again a million times on every little detail, I think the points are being missed.

Nintendo dictated certain bits should be set in various cases within the image. Nintendo also had a form filled out when a game was submitted to them to be made into cartridges. I don't know their exact process, but I can guess that based on that data, most of the decisions involved in selecting a suitable board, and setting up the assembly were made. Meaning for mass produced carts, a game would match whatever parameters the process used.

Beyond that, certain standards were also followed, perhaps optionally, but serial numbers on games internally don't seem to be picked randomly, but reflect design decisions of the board, among other things.

Alongside that, certain coprocessors also only functioned alongside other settings/maps on the cart. A SuperFX 1 wouldn't be used with a ROM image large than 1MB. SA-1 was always "LoROM". Other things would only be "fast" or "slow" ROM.

Now after the fact that all this is said and done, how the SNES itself functioned was based on the hardware fed to it, and not anything to do with the header (unless of course the game itself read the header).

We also know that no one had a gun pointed to their head when a cart was made, and certainly no optional requirement was necessarily upheld. And certainly, any cart I make myself, or any software I craft to run in an emulator can have whatever the heck I want in the header, and ignore every optional and mandatory standard out there.

That doesn't mean at the end of the day that data which is being provided and freely given to me I should just throw out the window because it's not provided in ideal stimulatory test conditions.

It'd be ideal if the SNES emulator also had a full cart passed to it (which we'll hopefully have as an option in the not so distant future), but when you have less than ideal, you make do with it.

In the theoretical field, tests are ran in carefully controlled test environments. Take many of these scientists and give them a real world test case, when they see something external enter the mix which wasn't planned for in their tiny controlled environments, their little hard wired brains explode all over the pavement. Sadly, it seems some of the people of our community are those scientists.

For some reason, I was the only one who decided to start doing deep research and study into the headers which are being given to us at no cost. With careful research, it becomes obvious that all the data we need is in fact there in >85% of the commercial carts. No funny fuzzy logic required.

Beyond that, as I described above that certain setups were only made one way, such as SA-1 only being "LoROM", which can be recognized with just a little bit of statistical research, you get another ~10% of needed data. Granted this is a bit fuzzy, since we ourselves can craft other setups. But remember, some simple factory in middle of nowhere doesn't just have the capability to make whichever cart because one company decided to go out on a limb, the controls for the process were probably very primitive with few options. You can probably map their entire logic into a flowchart with a dozen or so diamonds.
Yes it may seem weird that all carts over 2MB of ROM or 16KB of RAM or whatever happened to all use the same mapper that other carts don't, but probably very logical if you saw the flow chart used for shoddy factory controlling software.

From things like this, only two cases that I've dealt with bother me. The first being the larger ROM/RAM thing. The other being DSP-3 detection. I said to detect DSP-3 by seeing if Bandai is the manufacturer and trying to use a Nintendo DSP. Bandai was one of the only companies to have the audacity to make their own hardware for the SNES without permission from Nintendo. However, I view the Bandai+NDSP==DSP-3 to be somewhat of a hack, which is unfortunate, it's the only place I felt compelled to do something so drastic.

If you want to bash the large ROM/RAM idea, fine, I can accept that too.

However, there is our last case, things which are done, which are obviously intentional, even though not explicitly stated. Such as Nintendo using a certain keyword in a serial number with a particular type of hardware, or not setting a satellite download date when the cart was physically distributed in stores. Using data from this last series of cases, we get the last 5% (minus a few exceptions I'll detail below).

If you want to bash data which is directly gleaned, or this last case where it is quite obvious, just because you haven't done the research is ridiculous.

I don't appreciate taking a snipped of code which deals with the first set of cases, or the last set of cases, and then say it's just pure voodoo because you don't anything about the values being looked at, or bother to follow the code at all.
How would emulator authors feel if I'd paste a bit of code from an emulator perhaps where a register is handled and say, oh no, it checks if bit 0 is on in this particular register, now vblank is allowed, It's PURE VOODOO I TELL YOU!!!

If you want to complain that no one was forced into setting things up exactly that way, or in our second series of cases, things seem a bit too convenient and we really need to get the idea of passing a cart to the emulator and not just the ROM image, I'm fine with that, and I endorse that idea.

But it is just plain rude to keep saying over and over again that me or my code is inherently wrong or evil or something along those lines, because it doesn't meet our ideal circumstances, or because you're not knowledgeable enough, or intelligent enough to understand the first and third set of cases, and the code to deal with them (however, if there is desire to comment them better, I'm all for it). I'll also reiterate that myself am not happy about two of the second set of cases, but am upset if they're used as examples to condemn the rest of the process.



Now the few exceptions I referred to above are the Seta DSP, Nintendo DSP-1, and stuff like special controllers.

Both firmwares available on the Seta DSP are marked the exact same way within the header. The hardware itself makes no difference in capabilities based on the two firmwares, there is no change in ROM speed required, or significant mapping differences, nothing which says "Hey, I act differently than my friend here in ways other than blackbox logic I/O". I can't see determining between the two without some kind of hack, which is why NSRT labels both of them as "Seta DSP", although emulators will need to take some kind of step to say which firmware to use.

Same goes with the various iterations of the DSP-1, the game ROM itself has no significant changes. Hence no way I've seen to differentiate between them. I've also yet to see any convincing evidence to suggest that there needs to be a differentiation between them. I'm still waiting for someone to tell me what happens on that one test when an actual DSP-1B is soldered into a Pilotwings cart.

Regarding special controllers, although games may go nuts in their boot up routine if a certain controller isn't plugged in, there doesn't appear to be any markings in the header to indicate any such requirements in the game, since it makes no difference at all in the fabrication process.

In cases like these, it is offensive to tell me to just come up with some pattern anyway - since it's all just hackery like everything else. It's not just random patterns, and I'm not just going to make up patterns when there is no discernible pattern at all, and no rhyme or reason for there to be a pattern invented for such a thing.

If you want to bash my code, go bash code anywhere that uses a regex. Go bash emulators that read and set some registers without heavy commenting and call it all voodoo. Also go take a hard look at the world we live in.

As I said before, it's not ideal, and we can attain close to an ideal if we put a lot of work into our virtual cartridges, but what is done is actually quite close to how all software works today. Noticed how your OS/Windowing Manager/Program bases so much on the last few characters of the filename even though you can technically change the last few characters, and still force the OS/Windowing Manager/Program to handle it properly? It's not like your PDF reader uses ".pdf" when it's running to do anything. So why does your OS pass .pdf to your PDF reader?

Even so called superior systems like MIME, which the internet is based on, which looks at a file itself to determine its type, that uses regexes, and a small portion of the time even fails to determine it properly (MagicMIME library sees CSS files as text/plain instead of text/css).

Turning around and giving me verbal/written abuse is hypocritical when all who do in fact use Operating Systems or the internet. It'd be nice to be appreciated for once for taking a really dismal situation and turn it into something which we're able to work with, aside from wanting to implement an even better solution.

Oh, and for those who just read this and realized that hey, we have a problem in our OSs, consider fighting to get our file systems for all media to support built in MIME types in file metadata, which can be set by programs which create the files, so we can hold file type recognition to the same standards we'd like to hold our cartridges to.

Furthermore, I can easily convert any normal "LoROM" game to "HiROM", and my program handles Pilotwings just fine.

Any normal one less than or equal to 2MB, at least
Neat idea, though.

Well yeah, <=2MB, since otherwise it ends up breaking the 4MB barrier...
It'll also cause issues with some games that rely on the smaller than 2MB mapping.
I made the program (really easy) to test some of my crazy mapping experiments, and see how far some games are willing to be flexible, or how many really rely on their mapping we assign them.

[FirebrandX]

I imagine hardware revisions for the CPU and PPU processors will be selectable in the advanced section at some point? I think this would be a good place for DSP1 processor revisions as well. It only seems logical, it's another processor handled within the emulator. This would just be for people who want to avoid depending on headers (me) and it wouldn't be as elaborate as db hacks.

I agree. An advanced option to toggle the DSP chip selection sounds great to me for the time being, but I of course don't actually expect byuu to hassle with that right now. I just support the idea.

[byuu]

This argument continues to poke its head up .. To finally separate the cartridge memory map from the SNES memory map I feel was a great step (this seemed to happen in earnest when open bus and such was emulated correctly).

The basic gist is everyone was around and going strong up until 2003-2004. Then everyone pretty much vanished except anomie. I came by for a year, bugging him to death and catching up. Spent a year after that improving.

Then after that ... nothing. Sans something cool every 6 months or so, we're at a stand-still. So that leaves us all to repeat the same things over and over again ad nauseum:
- "Why is bsnes so slow?"
- "Why can't you support savestates?"
- "Why don't you support the SuperFX and/or SA-1?"
- "What's up with Pilotwings?"
- "Why does Linux audio support suck so badly?"
- "Accuracy or performance?"
- "Databases or headers?"

Kind of depressing, but my own fault for not doing more research. Pretty burned out there.

How about we start open discussion on the cartridge format to be used in this roadmap.

I would like that very much. My main concern is it'll sit for two years while I keep asking and asking people for info, then immediately after I say it's set in stone and release it, a million people will complain about crazy short-comings and not use it (hello, UPS format.)

Agree with me on a spec and I'll happily implement it.

With this brought up over and over again a million times on every little detail, I think the points are being missed.

You're right that I do not have any idea the amount of work you've put into your algorithms and heuristics. And that you don't get nearly enough credit for it. You're right that your work has lead to our currently only working solution, and it requires no database for literally every single game ever released. That's a very, very impressive feat.

And after reading your post, you're right that I'm brushing it off too dismissively. I apologize for coming off offensive, that wasn't my intention. I'll be honest, I disagree with your approach, as I'm sure most ZSNES devs disagree to my emulation approach. I do absolutely respect and appreciate the work you have done. Work nobody else has.

But I completely understand your line of reasoning. Honestly. I know there were rigid standards for the data in the header. I know they conform to hardware designs. I know that sans a few incomplete betas and such, that the header data is very accurate in 99.8% of cases. I know I'm talking about hypothetical non-existent "carts" that don't mean shit in the grand scheme of things.

I don't know what to tell you ... I'm just passionate about getting things as idealistic as possible within my own very narrow definition of reason.

To me, reasonable is an emulator that runs on current top-of-the-line hardware, to structure the software to act as much like hardware as is possible within those constraints. To me, I see that the SNES doesn't read the header, and I see a problem when an SNES hardware emulator is doing something the real system doesn't.

I know it's stupid and hypocritical. The real SNES doesn't draw a menubar, it doesn't read controller input from USB ports, it doesn't adjust gamma. I know I don't take it as far as is possible, like the circuit-level 1978 Pong simulator that gets 2fps on 3GHz systems.

I know it's software and there's some difference. I know nobody's making new hypothetical games to take advantage of these special chips. I know only d4s is making anything new at all, period.

With limited time, we pick and choose things of interest to us. And to me I value absolute preservation of carts, as they're what emulation is really all about. Hardware is great, but with no software, why not emulate an Altair instead?

I want to know exactly where each bit should go into the memory map, with no exceptions. I want the cart to tell the emulator 100% of the mapping and hardware info, with no exceptions. No "0x02 at offset 0xCAFE means map 64kb SRAM to $70:0000" -- make it say "map 65,536 bytes of SRAM to $70:0000", plain text if you have to.

I don't care even if the headers turn out to be 100% perfect for all 4,000 games. I want to test and verify them all anyway. I want RSA 4096-byte hash + private-key signed certificates with the dumper's name to validate each and every image dump. I worry about hardware failing in 30 years from now, and some new unforeseen problem comes up, where we kick ourselves for not capturing the data when we could. I want to make sure our grandkids can be 100% certain their SNES images that they've never heard of or care about while playing their PS7's or Xbox 16,796,160,000's are bit-perfect.

I see small developments with minor inconveniences and it bugs me a lot looking forward:
- Tales of Phantasia broke our old 32mbit mapping world
- neviksti's Star Ocean hack only runs on Super Sleuth
- Star Fox 2 required new mapping, IIRC
- new BS-X dumps from Matthew Callis continue to only work on some emulators with our current info

All that said, it's the same as where I want to make sure things like the ALU hardware delays are supported, even though we have yet to find a single game that requires that.

For all intents and purposes ... between other emulators' SuperFX+SA-1+BS-X support and my own emulator, we have zero known bugs in any titles. They all run, they're all visibly bug-free. But I don't want to call it quits. I think we can keep going, and I think we can improve the way we treat SNES ROM cartridges.

Again, I'm sorry to have come off putting down your hard work: it truly is appreciated by me, and I'm honored that you've helped me so many times in the past to improve that. I wouldn't have the compatibility I have now without your help.

I remember a time when everyone thought all games were either LoROM or HiROM, period. Then along came "FuckROM" in ROM hacker lingo (Tales, Daikai II, ...), and so on. Then came your research. Now, I'd like to build on that even more and have solid, manual guarantees of exactly how carts work, bit-for-bit; without requiring any work by emulators.

It's not like your PDF reader uses ".pdf" when it's running to do anything. So why does your OS pass .pdf to your PDF reader?

<offtopic>

Like SNES emulators using .smc, .sfc, .swc, .fig, .078, .gd3, .gd7, .bin, .ufo, .st, .bs, .bsx, .etc? Heh ... maybe we should start encoding all the mapping info into the file extensions, lord knows we have enough of them for it :P

[Nach]

byuu:
A point which you missed, I'm not happy with the situation either. I want to be able to support SuperFX+SA-1+BS-X all with 64MB of ROM. I was the first person who mentioned we need our own header format in the first place, instead of the copier junk. I want to have a more realistic cart.

I just keep on getting bashed for giving us an interim solution which made a lot of sense out of the madness we've had several years ago. And at the same time, I keep on getting completely ignored when I keep saying I want a better solution, and even made a few proposals as early as 6 years ago, and people keep putting words into my mouth saying, that I think internal header is adequate, when it's obvious anyone can make anything, and that I'm against having a proper cartridge setup.

For those that keep missing it, I'M WORKING ON A BETTER SOLUTION. Sheesh, how many times do I have to say it?

And for the record, we didn't have to change the map for Star Fox 2.

[byuu]

For those that keep missing it, I'M WORKING ON A BETTER SOLUTION. Sheesh, how many times do I have to say it?

Ah, awesome! Want to work together on that? Can use my emulator as a testbed, see what neviksti et al think about it.

What are your thoughts on the plain-text .pcb format idea? Human readable, easy to parse in any programming language, seems easily capable of representing all known hardware.

Downside is that it's meant to store only cart mapping info, and not supported controller data and such. I think the latter is better for something like NSRT, and I'm not opposed to a link-up to share this info between NSRT and emulators somehow, eg the current header setup. Much as I dislike headers, at least they'll be useful for something for a change.

[grinvader]

Another advantage of having the map info with the ROM: new emulators become much easier to write.
Might look minor, but...

[tetsuo55]

Glad to hear Nach is also working on cart-simulation

As an end user i also want to thank Nach for his work, because without it i probably would not be able to play my clean-headerless games.

If by any chance some of you where so busy programming you did not notice. The current dev cycle of MAME/MESS now has a semi-working pcb format, for both games and hardware.

It would need some work but its now theoretically possible to have the snes, cart and the included special-chip emulated seperately like the real thing, without the need for any kind of heuristics, everything is noted in the XML file that is included with te zipped rom.

NOTE, although all MAME systems have been converted to this system, the games have not, only TI on the MESS side has partial support for the xml system

I'm not saying we NEED the xml system, but at the very least we could look at it and maybe borrow some ideas

[FitzRoy]

I don't like this direction, we could just as easily argue for the base processor code to all be externalized to allow easier customization of that. But an emulator emulates popular, finite, licensed hardware. That's what it is, the second it goes beyond that it becomes an emulator of everything, because there are infinite ways to make it more capable. And if you're one of these unlicensed developers who doesn't like the restrictions of the hardware, why wouldn't you just go develop for more capable hardware directly? It would be 1000x faster than developing for for imaginary emulated extensions of a 1990 Nintendo console.

I still think that a single, external xml database file with checksum entries and known boards for each game is probably the way to go. That gets us the customizable detection we need and avoids all kinds of hassle on the rom management end. No thousands of new files, no need for another program. Just open a single xml file to edit or look at entries. It could be maintained and edited by anyone, as long as it is constructed in the way the emulator is expecting. Furthermore, the file could be expanded to add custom columns ignored by the emulator, but useful for the information they provide (special controller support, etc).

[byuu]

Hmm, okay how about this?

Brightness / Contrast / Gamma leave "adjust" off, but display the numbers more like they were meant to: eg show %, 100 = "100%", 5 = "5%", etc. 100% = center = no adjustment. We can also modify the centered text to say "Normal" for all of these, if you'd prefer.
Frequency Skew <-???, ... None, ... +???>

And I still need to add configuration options for blargg's NTSC filter. The main setting needed is "merge fields", useful only with 60hz + vsync.

There's also hue, saturation and tone(?) settings ... but if I offer those, I'd rather they be available to all filters and done through the color table. Not too convinced of their usefulness, but it'd help calibrate to YUV / YIQ TV colors definitely.

Lastly, there's signal quality settings. There's some nice quick presets for quality level: RGB, S-video, composite, RF, etc. Might be nicer to offer that as a drop-down rather than a bunch of sliders.

We can either put them on the video settings tab inside a group box or something (maybe another next to it for scanline filter settings?), or make a new listbox-entry panel for it specifically.

I don't like this direction, we could just as easily argue for the base processor code to all be externalized to allow easier customization of that.

Base processor? Obviously an SNES emulator would internally contain the S-CPU, S-SMP, etc.

External co-processors would be a nice theory, but too impractical. Those things need way too many hooks into the core (S-DD1 hooks S-CPU DMA MMIO registers to monitor their values -- other emulators would do that differently), and cross-platform dynamic linking capabilities aren't all that great (eg try it on the NDS.)

It would certainly be nice if we could separate the cart co-processors from the emulator, it's just not practical like it is with cart mapping.

Cart mapping info ... I think it'd be easier to have a PCB list inside the emulator so that you only have to say "cart A uses SHVC-FOO-BAR", but that creates a rather inflexible emulator that can't handle any cart.

By externalizing the mapping info, we allow for any conceivable mapping. Nice for things like new beta dumps or ROM hacking when you need more than 48mbits of storage. Still very possible to run those hacks on hardware using devices like the Game Doctors, or through PCB mods ala d4s' fan-made carts. Very nice because supporting new titles doesn't require a new emulator release. Also very nice because I don't have to manually specify 40+ PCB maps inside the emulator directly.

And realistically, no SNES emulator in at least the next ten years will be able to exist without a cart header parsing backup mechanism.

And if you're one of these unlicensed developers who doesn't like the restrictions of the hardware, why wouldn't you just go develop for more capable hardware directly? It would be 1000x faster than developing for for imaginary emulated extensions of a 1990 Nintendo console.

Ask d4s why he writes new games for the SNES, or ROM hackers who make completely new games through old titles (eg Dragoon X Omega). Personally, I like the portability. An SNES game runs on a dozen emulators for every hardware device imaginable. A PC game runs on one device, and has to be compiled and ported to each OS. Java is bloated shit with only one -- maybe two -- complete implementations, and wasn't really designed specifically for games.

I think there's real potential for using the S-DD1 / SPC7110 in other games: free streaming real-time ~50% decompression can make a ROM hack with limited space that much better. But definitely, nobody's taking advantage of them yet.

[creaothceann]

Lastly, there's signal quality settings. There's some nice quick presets for quality level: RGB, S-video, composite, RF, etc. Might be nicer to offer that as a drop-down rather than a bunch of sliders.

How would dropdowns be better than what ZSNES is currently using?


EDIT Sorry for sounding so negative... I like the rest of what you're saying.

[Gil_Hamilton]

I don't like this direction, we could just as easily argue for the base processor code to all be externalized to allow easier customization of that. But an emulator emulates popular, finite, licensed hardware. That's what it is, the second it goes beyond that it becomes an emulator of everything, because there are infinite ways to make it more capable.

That's one HELL of a slippery slope argument.

In theory, the emulator should do exactly what the original system does.
Certainly, we can make an emulator that runs all the officially licensed commercial games flawlessly and stop.
But it's worthless for running real, existing software that isn't licensed, as well as development of new software and hacks to old software(how many current translation patches glitch to hell on a real SNES?).

And if you're one of these unlicensed developers who doesn't like the restrictions of the hardware, why wouldn't you just go develop for more capable hardware directly? It would be 1000x faster than developing for for imaginary emulated extensions of a 1990 Nintendo console.

How did we get from nonstandard ROM mappings and Super Noah's Ark 3D to recreating the SNESCD?