bsnes v0.033 released

[byuu]

New WIP. Adds some more HDMA timing improvements, DMA bus hold simulation, and hopefully proper detection for ST011, which should mean that every unsupported game will now notify you of that fact.

Also, I finally got around to writing that status bar message queue system I mentioned a long time ago. Should make Deathlike happy. It'll tell you whenever any UI event occurs (load, unload, reset, power cycle, UPS patch applied, unsupported chip detected, config file / locale file load, etc.)
Obviously if you turn off the status bar, you won't see them. Not a problem for me personally: if you want to see status messages, leave it on.

With that, I removed the annoyingly bland message window, and muted the terminal message printing, putting it all inside the statusbar instead.

I also got rid of some now-unused config variables, misc.status_text (it was kind of overkill to let that be customizable) and cpu.hdma_enable (it's always enabled now.)

Opinions on the new status bar system welcome.

I've also set the SNES to report itself as 2/1/3, rather than 1/1/1. Since I don't emulate things like the HDMA conflict crash, I figured I may as well set it to the CPU revision that doesn't have it.

Probably the best it's ever been, but Street Racer's track does still flicker on "Head to Head" mode.

With the above changes, I was able to eliminate the flicker in-game in all modes, as well as get rid of it ~80+% of the time on the title screen. Only once every ~5 restarts will you see it for maybe one frame.

That's really the best I can do, I'm afraid. It's so subtle I doubt anyone will even notice it now. Like Winter Olympics and Adventures of Dr Franken, I'm not going to consider it an active bug (yes, how convenient), but I'll watch the game closely with future timing changes. Hopefully it'll go away entirely with more refinements in the future.

[byuu]

And another one.

I've re-written the DMA state machine. I decided to keep it in one FSM instead of two separate ones, because they honestly share so much. But I rewrote it to be a lot cleaner, and to handle some really exceptional edge cases. Due to the design, I was even able to make the HDMA during DMA edge case "transparent", eg the same codepath is used for normal HDMA and for HDMA during DMA :D

New WIP passes the last four tests in test_hdmatiming.smc. The ROM posted doesn't validate the last four yet, so you have to compare the SRAM file to the source logged values if you care to.

That should be everything with DMA and HDMA timing now, thankfully. Really happy with that codepath for the very first time. Such an improvement from the "don't even worry about HDMA syncing" code I had a few versions ago.

I also reduced the DRAM refresh rotation from 7-lines of code testing against the NTSC color burst case to 1-line, using the DMA counter (dram_refresh_pos = 530 + 8 - dma_counter())

Lastly, I added a flush command to the status bar. Any important messages will now flush all buffered ones to display the new one. Eg load 10 games back-to-back and it'll say the name of the new game immediately, instead of scrolling through the other 9. It will still buffer lesser important ones, like unsupported chip and UPS patch applied messages. I also removed config / locale path display, because it annoyed me.

Nearing a release. I want to state machine neviksti's SPC7110 decompression code, and I should be ready on my end.

FitzRoy, I'll give you the final word. If you want controller port selection moved to "System", I'll do so.

Any show stoppers should be mentioned now. I can't fix the "crash with Unicode characters in the executable path" issue just yet, so that'll have to wait.

[FitzRoy]

FitzRoy, I'll give you the final word. If you want controller port selection moved to "System", I'll do so.

Yes, thank you (in it's own divided area between reset and exit).

Btw, I noticed that when you redid the configuration area, Controller Port A/B was changed to 1/2. Intentional or mistake?

[byuu]

Btw, I noticed that when you redid the configuration area, Controller Port A/B was changed to 1/2. Intentional or mistake?

Intentional, I noticed my SFC deck had 1 and 2 in circles on it. For some reason I thought it was A and B before ... meh.

[FitzRoy]

Btw, I noticed that when you redid the configuration area, Controller Port A/B was changed to 1/2. Intentional or mistake?

Intentional, I noticed my SFC deck had 1 and 2 in circles on it. For some reason I thought it was A and B before ... meh.

Ha, I thought it was A/B, too.

[neviksti]

Nearing a release. I want to state machine neviksti's SPC7110 decompression code, and I should be ready on my end.

While the decomp output is the same, the code I wrote up for utilities for romhackers is slightly cleaner and more consistently termed between each mode. In particular, the old code had an extra cludgey way of handling the pixel -> bitplane conversion where there were two copies of the code with extra tests and nonsense.

If you just want the conversion to be quick, you might be able to get away with making everything static variables and adding an extra parameter to the function call (a "setup" boolean) which when set does all the setup and exits, and when not set skips all the setup. (and maybe have it always decompress one more tile, and then just hand out one byte from the buffer each call till it needs to decompress another tile, etc.)

Bleh whatever. If you rewrite it instead, I'm sure you'll get much better code out of your efforts.

[byuu]

Nah, I'll be happy to use any updates you have. Do you have a link to your updated code, so I can grab it? Many thanks in advance.

And yes, I was planning to implement it as a spooling buffer that grabs small chunks of data at a time :)

[neviksti]

You probably already have it. It is the code I posted on zsnes, as opposed to the older code I posted on nesdev.

topic:
http://board.zsnes.com/phpBB2/viewtopic.php?t=11727

Source files:
for compression: mode0,mode1,mode2
for decompression: mode0,mode1,mode2

You don't need the compression stuff for the emulator of course, but it may be helpful for your FEoEZ translation project. (If you end up using these tool unmodified for the translation project, please note the hard coded limits I mention in that thread.)

[tetsuo55]

Btw, I noticed that when you redid the configuration area, Controller Port A/B was changed to 1/2. Intentional or mistake?

Intentional, I noticed my SFC deck had 1 and 2 in circles on it. For some reason I thought it was A and B before ... meh.

confirmed on my pal snes, 1 and 2

[henke37]

Here is more ways to label the ports:

• Mainport/secondary port
• left / right port
• J123 / J 124
• Joy basic / joy enhanced

My point is, it doesn't really matter that much what they are called as long as everybody knows what you are talking about.

[Snark]

Probably the best it's ever been, but Street Racer's track does still flicker on "Head to Head" mode. I have no idea why practice mode doesn't trigger it while another mode does. Both NTSC and PAL versions of the game behave the same. It's funny, when you're racing, sometimes a notice will pop up on the bottom right of the screen saying "Timing by West Bros." Nice job, West Bros, you suck!.

I don't really understand your (or byuu's) point. If the game does indeed works on 99.9% of units...on what do you base yourself to say their programming suck or that the game is "broken"? I mean, it works, it works right? I doubt the fact it would be a bitch to emulate correctly because high precision timing requirements even entered their minds

Or are you saying the game works on hardware by fluke, and that the programmers didn't know, for the most part, what they were doing?


edit: good job for ironing out the the hdma and mecarobots issues Guess we're back to zero known bugs!

[FitzRoy]

I don't really understand your (or byuu's) point. If the game does indeed works on 99.9% of units...on what do you base yourself to say their programming suck or that the game is "broken"? I mean, it works, it works right? I doubt the fact it would be a bitch to emulate correctly because high precision timing requirements even entered their minds

I figure being the last out of a few thousand games to work right should get you some kind of award. You've also got Adventures of Dr Franken needing a dot-based PPU for its title screen. If you can't figure out why that's stupid just because it works on hardware... it's like being given a choice of bb gun or a magnum to kill a mouse, and you choose the magnum.

[byuu]

I wish I could post the new WIP, I really need it tested. But it looks like vstech.net (cinnamonpirate.com's host) got sucked into a black hole, literally. You can't even nslookup it. So ... sorry.

What I did today was:
- remove an unnecessary ternary condition in HDMA CPUsync (no visible effect on emulation or speed.)
- move controller ports from settings to system.
- rewrite SPC7110 decompression engine from scratch.

The last one obviously the most important. I took neviksti's most recent decompressor code, made the essential variables static, added a bool init parameter you can use to start a new decompression sequence, and built up a dual-indexed (read+write cursor) ring buffer to stream byte sequences. I set the buffer to >= 32 bytes at a time. I also simplified a few parts, like the swap sequence for pixel ordering; and I took out the end of each function that computes length, since that's no longer needed (nor is bot.)

The result is you can stream an infinite number of bytes safely from decompression, and nothing will ever go out of bounds of the data ROM.

Speed results on Core 2 Duo E6600 @ stock 2.4GHz:
FEoEZ cart riding sequence - 91fps (was 40fps)
MDH title screen - 111fps (was 29fps)
SPL4 title screen with players running across screen - 118fps (was 35fps)

For comparison, Star Ocean in-game gets ~95fps.

I didn't think we would need that many optimizations to get SPC7110 support running at full speed (how complex could a low-cost IC from 1995 be?), good to see I was right.

As soon as vstech comes back (hopefully tomorrow), I'll post the PD / BSDL source, and get it sent over to GIGO. Hopefully he can add it to SNESGT.

Speaking of which ... neviksti:
In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15, but it should be 30. I'm guessing it runs fine in isolation (memory initializes to zero and all that), but when mode 2 ran and set contexts up to 32; only clearing 15 was resulting in corrupted graphics all over. No big deal, just mentioning it.

I don't really understand your (or byuu's) point. If the game does indeed works on 99.9% of units...on what do you base yourself to say their programming suck or that the game is "broken"? I mean, it works, it works right?

This is the problem I have with the black-and-white "bug" label ... it implies a game is broken to a casual observer, or there is at least noticeable corruption on at least one screen.

In truth, bsnes has a few visible bugs. Street Racer will flicker one frame on the title screen, but only one time, and only once every ~4-8 runs. Adventures of Dr Franken and Winter Olympics show one black scanline because the games update OBSEL at very unusual points mid-frame.

And there are countless "anti-bugs", eg Battle Blaze on the fighter select screen is supposed to show some garble up at the top due to mid-scanline PPU writes. Because bsnes renders an entire scanline at once, you don't see this. Lots and lots of games will have 1-16 pixels on one scanline at the left (usually not even visible on TVs) that flicker due to writing PPU regs past the end of hblank.

BoF2 German detects emulators by reading the division register early. Since no emulator supports that, you don't see the anti-piracy splash screen.

All of those could be considered bugs to varying degrees.

I suppose what would be nice is a bug severity ranking system. "Severe" if it's game ruining, "Moderate" if it's more than one scanline / frame that glitches graphics or something, and "Minor" for the stuff 95% of people probably won't even notice. Or something like that. My point is that it doesn't make a lot of sense to work on the minor stuff. Most of that will probably go away with a cycle-based PPU anyway, and the rest will probably continually appear and disappear with infinitesimal timing changes.

[neviksti]

Speaking of which ... neviksti:
In your updated DecompMode0.c file, you declare NUM_CONTEXTS as 15, but it should be 30. I'm guessing it runs fine in isolation (memory initializes to zero and all that), but when mode 2 ran and set contexts up to 32; only clearing 15 was resulting in corrupted graphics all over. No big deal, just mentioning it.

Hmm... I wonder how that passed the tests. It looks like it should be overwriting the input data. Strangely, the CompMode0.c file has it listed as 32 (not 30 nor 15)... I wonder at what point I changed any of that.

Thanks for pointing that out.

EDIT: I just checked and the old code said "#define NUM_CONTEXTS 30". I have no clue why, or at what point, I typed over that. Weird.)

[tetsuo55]

This is why the snes needs a list of bugs-that-are-not-emulation-bugs AND a list of emulation bugs.

it's not all bad though, Bsnes accurately emulates the 1 scanline bug in the titlescreen of Zombies ate my neighbours

[ShadowFX]

I wanted to make a small request here... is it possible to allow key combinations when assigning a key to, say, fullscreen (Alt+Enter)?

Thanks and keep it up!

[byuu]

Okay, host is back up. WIP posted.




SPC7110 emu source:

Code: Select all

http://byuu.cinnamonpirate.com/files/spc7110emu.zip

Not as fast as Nach / _Demo_ / anomie's, but it's PD or BSDL (your choice.)

Strangely, the CompMode0.c file has it listed as 32 (not 30 nor 15)... I wonder at what point I changed any of that.

Well, having it greater than the needed number doesn't seem to hurt anything. I just use 32 for everything so that I can share the initialization code easier. Not exactly a bottlenecked area of code.

I notice you copy/paste a good bit, though: "shift refence pixel b value to top"

Heheh, sorry. Don't mean to nitpick :P

is it possible to allow key combinations when assigning a key to, say, fullscreen (Alt+Enter)?

Unfortunately not. I've always had trouble reading those kinds of key combos using various APIs, and the input parsing code is not at all suited to working like that. Sorry about that.

[Dullaron]

I try that updated source out and I get a black screen here.

Any idea?

[Snark]

You've also got Adventures of Dr Franken needing a dot-based PPU for its title screen. If you can't figure out why that's stupid just because it works on hardware... it's like being given a choice of bb gun or a magnum to kill a mouse, and you choose the magnum.

I understand the difficulty raised perfectly. But you're thinking in terms of emulation... There's no gun to choose or mouse to kill to speak of with the original hardware, regardless of whether the game is one of the last game being emulated correctly on a given emulator: It works right out of the box. The argument that "it's stupid" because it need dot-based PPU isn't true. It just appear that way to you because most games happened to work with a scanline base renderer, which as you know, isn't how the hardware works at all.

Had the game not worked on even only 2% of the original consoles (let's say: units that deviated ever so slightly from official or most common specs but were otherwise perfectly functional) then yes, the game could be considered broken. But imo, not when it work (afawk) on all units.

[byuu]

I strongly suspect that you will see at least a small number of these glitches on a very small number of systems. Especially the really sensitive CPU<>SMP clock games, like Earthworm Jim 2 (E).

I do often wonder how it is that games like Death Brade and that European racing game never error out on real hardware. They rely on uninitialized RAM to contain certain values, whereas RAM init patterns are extremely random. It's quite possible any specific address can get any value.

Then again, we're all testing with flash carts (with custom BIOS mapping programs on them) and copiers, which initialize the RAM for you. It's quite possible the real carts will glitch out on occasion, too. Worst case, it'd probably be a 1:256 chance.

[FitzRoy]

You've also got Adventures of Dr Franken needing a dot-based PPU for its title screen. If you can't figure out why that's stupid just because it works on hardware... it's like being given a choice of bb gun or a magnum to kill a mouse, and you choose the magnum.

I understand the difficulty raised perfectly. But you're thinking in terms of emulation... There's no gun to choose or mouse to kill to speak of with the original hardware, regardless of whether the game is one of the last game being emulated correctly on a given emulator: It works right out of the box.

Emulation just reveals the stupidity is all. If you're the farmer hearing the news that 3,000 mice were successfully killed by 3,000 exterminators, you're happy with the end result, sure, even if you didn't see how it was done. But it wouldn't change the fact that if one person killed his with a hand cannon, they were a fucking idiot. Then if the world disappeared and God was told to create an exact replica, and one mouse died from a magnum, God would be like "What the hell, I enjoy the challenge of recreating this event, but why do I have to spend all this effort reconstructing a magnum just to get this last mouse to die the way he died before? Can't I just engineer a reverse miracle?" And the people cried "NO! There are Gods that already do that! You must recreate it exactly as it was or our old world will not be accurately documented!" "Whatever," says God, and in time, it was so.

[Snark]

Emulation just reveals the stupidity is all. If you're the farmer hearing the news that 3,000 mice were successfully killed by 3,000 exterminators, you're happy with the end result, sure, even if you didn't see how it was done. But it wouldn't change the fact that if one person killed his with a hand cannon, they were a fucking idiot. Then if the world disappeared and God was told to create an exact replica, and one mouse died from a magnum, God would be like "What the hell, I enjoy the challenge of recreating this event, but why do I have to spend all this effort reconstructing a magnum just to get this last mouse to die the way he died before? Can't I just engineer a reverse miracle?" And the people cried "NO! There are Gods that already do that! You must recreate it exactly as it was or our old world will not be accurately documented!" "Whatever," says God, and in time, it was so.

Alright, that was one of the weirdest analogy ever. I'm taking a fairly big guess here and would say that was basically a way of saying you don't see the point of adding dot-based ppu emulation.

The person who would want to recreate the world as it was isn't an idiot, but the lazy "god" who took shortcuts.

[byuu]

Emulation just reveals the stupidity is all. If you're the farmer hearing the news that 3,000 mice were successfully killed by 3,000 exterminators, you're happy with the end result, sure, even if you didn't see how it was done. But it wouldn't change the fact that if one person killed his with a hand cannon, they were a fucking idiot. Then if the world disappeared and God was told to create an exact replica, and one mouse died from a magnum, God would be like "What the hell, I enjoy the challenge of recreating this event, but why do I have to spend all this effort reconstructing a magnum just to get this last mouse to die the way he died before? Can't I just engineer a reverse miracle?" And the people cried "NO! There are Gods that already do that! You must recreate it exactly as it was or our old world will not be accurately documented!" "Whatever," says God, and in time, it was so.

... oh crap. jcaulidig2 hijacked FitzRoy's account :/ I kid, I kid :P

[FitzRoy]

Alright, that was one of the weirdest analogy ever.

I aim to please. Actually, it's giving me ideas for a movie script. I'll call it "God and the mouse that wouldn't die."

In fact, this could create a whole new paradigm in existential philosophy. What if our universe is merely a well emulated, but inherently flawed attempt of the original? From the inside, we wouldn't know the difference between an emulation bug and a glitch that was present in the original. That's right, we're all a bunch of walking talking roms, and someone somewhere is getting banned for linking to us.

See that problem Dullaron is having up there? It's a black hole.

I'm taking a fairly big guess here and would say that was basically a way of saying you don't see the point of adding dot-based ppu emulation.

No, but it is pretty ridiculous for compatibility reasons alone, and even byuu has admitted to such. In fact, he could probably create a b-nes in the time it takes to reverse engineer that fucker.

jcaulidig2

Whozat?

[Snark]

aim to please. Actually, it's giving me ideas for a movie script. I'll call it "God and the mouse that wouldn't die."

Alright just make sure it's not just about some character with god delusions in an empty room with no mouse, but with a real God... and mices from hell and zombie mices and shit, otherwise it's not interesting.

No, but it is pretty ridiculous for compatibility reasons alone, and even byuu has admitted to such. In fact, he could probably create a b-nes in the time it takes to reverse engineer that fucker.

Make that b-saturn/ maybe. With nestopia and that other nes emulator I've read is even more accurate (not to mention the other 500 or so less advanced NES emulators) I'm not sure byuu would see a point in remaking was is essentially already done.

What if our universe is merely a well emulated, but inherently flawed attempt of the original?

If a bug falls in an emulator does it make a glitch?