Language…
8 users online: Aeon, dacin, DashGamer, DixyNL, MegaSonic1999, Nemesis1407,  Segment1Zone2, toady - Guests: 235 - Bots: 390
Users: 64,795 (2,376 active)
Latest user: mathew

.

Link Thread Closed
Originally posted by byuu
It's an extremely difficult problem. Doing the SA-1's bus handler the right way would make even bsnes run probably five times slower than it does now. So obviously, I can't do that.

There's also a dozen features in that chip that no commercial games have ever used. So all of that code is untested.

If we ever get a flash cart capable of using the official SA-1, I suspect a lot of SA-1 homebrew won't work on it. So, be forewarned.

On modern hardware, BSNES-acc isn't much of a big deal to run. I'm running a laptop, to which I assume BSNES doesn't even use the multiple cores, and my computer still runs it at a constant 60fps without a hitch.
Perhaps a computer like mine would chug a bit with the 5x slower thing, but I'm sure many people here with gaming computers and the such wouldn't even notice the rough performance.

What I'm saying here is that it would likely be worth it to release a BSNES/Higan profile specifically for testing SA-1, if it means we can have hardware compatibility and understand the real limits of what we can do.
I've become very grumpy these last few years, and have been biting my tongue here in SMWC's forums quite a bit. I just want to let you all know that if ever I come off as harsh, I still care about you all. You guys are great.

(Avatar by http://reyleias.tumblr.com/, butchered by me)
The thing is, I'm meaning 5x slower on the accuracy profile.

I get around 125fps right now on my i7-2600K, and that drops to around 80fps for SA-1 games.

The thing about the SA-1 is it has this memory controller that allows both the SNES CPU and the SA-1 CPU to access the same memory (ROM, BW-RAM, I-RAM) at the exact same time. Obviously, this is impossible. So what happens instead is if the SA-1 sees the SNES CPU trying to access the same bus, it will stall the SA-1 CPU until the SNES CPU stops trying to access the memory.

This ... this is psychotic to emulate. Reads can get disrupted in the middle, and DMAs could potentially block the CPU indefinitely ... maybe. It's kind of untested.

To emulate this, we would basically have to step the SA-1 CPU and SNES CPU the minimum one-clock tick at a time, and store the bus values, and have the SA-1 testing what the SNES is accessing on every single cycle.

The overhead would be absolutely psychotic.

There are probably smarter ways to do it. Fancy priority queues (binary min-heap arrays) with timestamps and lots of funky math to calculate cycle times for each access.

But not only would it be really hard code to write, and very error-prone, but I don't currently own any SuperFX or SA-1 dev boards to try and test things with. So it'd all be conjecture.
I guess the best we can do at this point, then, is figure out all the ways where higan and a real SNES differ in SA-1 handling and make sure not to write any code that only works with (or takes advantage of) the incorrect timing.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
I guess the best we can do at this point, then, is figure out all the ways where higan and a real SNES differ in SA-1 handling and make sure not to write any code that only works with (or takes advantage of) the incorrect timing.

I want to preface this by saying that I don't know much at all about processor architecture or the sort, so keep in mind that I may be wrong here.

It sounds to me like the first step is to create a distinct 'barrier' between what we do in SA-1 processing and SNES processing so that the SA-1 and SNES aren't directly trying to read and write to each other. Doing this obviously introduces some problems, but it may be possible to have some sort of shared data table where necessary information can be stored and the SA-1 can safely be 'stalled' while still running its standard data loop. This way, the SA-1 would be used more for physics and graphics calculations, while changes in variables which affect these things would happen on the SNES CPU.

That seems to me like the best solution given the information that's out in the open, but as always, I am a scrub, so take my advice with a pinch of salt.
I've become very grumpy these last few years, and have been biting my tongue here in SMWC's forums quite a bit. I just want to let you all know that if ever I come off as harsh, I still care about you all. You guys are great.

(Avatar by http://reyleias.tumblr.com/, butchered by me)
Yeah, the lack of real tests with SA-1 is something to worry about. While the bus handler wouldn't be something really worrying, since its function is to allow SA-1 and SNES access the same place without side effects (aside from CPU pause/speed change), there's always one or another undocumented odd effect on CPU/MMIO behavior that may cause major problems.

Someone told me that he could try hacking a SA-1 cart somewhere in summer so my hope is to we collect everything possible and adapt the patches if needed before another Addmusic episode happens.

Personally, I'm optimist about any possible issue since unlike previous Addmusics, at least the memory spaces were respected (like character conversion DMA area) and everything should be initialized properly.

I'm curious on what should be the real maximum BW-RAM size, the official doc says 2 Mbit (256 KB) but that's not possible without using bml/xml mappers and that bus handler too, but more about what's the effective SA-1 speed when paralleling in ROM with SNES for example.

Hopefully my patch is pretty flexible and upgradeable, including for finished hacks so on worst case I can patch the current SMW SA-1 hacks if anything.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by byuu
Is there really an option to block it? I never knew about that.

No, I got something mixed up. The ZSNES source code contains no such thing. Snes9x does, I must've been confused by a discussion about its default value.

Quote
I'm sure mine is even lower than before, since I went nuts with the UI and game folders and all.

And I believe it's slightly higher than last time. There are more bsnes users than your download numbers say; some use older versions, some download from other websites, some use ZMZ (it's libretro, you can run bsnes in it if you want - I've even tested it with VisualBoyAdvance), some use other things.

There's only one way to know.

Quote
That is what the real thing does, yes.

Weird that it's not open bus or last read value or something.

But you know that stuff better than me.

Quote
It was mainly a wrestling game's splash screen.

Let me guess.


Quote
If you were to shunt all CGRAM writes to palette color 0, it would "work" for that title at least.

Then I request that you do exactly that, at least until we find a game where it breaks. You did something similar with some invalid OAM access (Ridge Racer?).

Neither is accurate to how the hardware does it, and (assuming no games write to other colors with the screen enabled) neither makes any existing games work worse or better, but hardcoding it to zero will break ROM hacks before it's too late. I do believe we all agree that the worst kind of broken ROM hacks is the ones that work in some emulators.

I requested exactly that on your boards a long time ago, but I think we misunderstood each other and got nowhere.
<blm> zsnes users are the flatearthers of emulation
> No, I got something mixed up.

Oh, whew. Was afraid I might owe some people an apology.

> There's only one way to know.

Here's to hoping the discussion doesn't end up as negative as last time. Although HFD was right, things seem a whole lot nicer here now.

> Weird that it's not open bus or last read value or something.

Yes, it's very weird. They chose to block only VRAM, but not OAM or CGRAM. I can understand doing them all, or doing none of them. But it makes no sense to only block one.

Had they not blocked VRAM, I could have used software to figure out the PPU internal timing patterns. Because they do, and I don't know how to use a logic analyzer, the dot-based PPU renderer is still far from perfect.

> Then I request that you do exactly that, at least until we find a game where it breaks.

I do much better and send the writes to the currently fetched pixel in the dot-based PPU. I used to do it for the scanline-based renderer, but I have it disabled by an "if(1 || regs.display_disabled)" block. Unfortunately, I don't remember why I did that now :/

> You did something similar with some invalid OAM access (Ridge Racer?).

It's Uniracers!! Uniiiiiiiiiiiiiiracers! Remember that one?

> I requested exactly that on your boards a long time ago, but I think we misunderstood each other and got nowhere.

I'm terrible at misunderstandings, so that seems likely.

I do agree though. I'd rather an emulator disallow something that should work, rather than allow something that shouldn't. Better to be defensive about this.

I've seen a few posts here about stuff working on bsnes, but not hardware. If anyone here ever narrows down what exactly the cause is, I will absolutely fix it in bsnes, or tell you why it's impossible. So please do let me know if you find things. Just note that I don't have the time to debug entire ROM hacks, so I need help narrowing down the specific causes.
Originally posted by byuu
Although HFD was right, things seem a whole lot nicer here now.

Yes, the haters are mostly gone by now. Didn't notice when it happened, it's hard to notice when something bad slowly disappears. It's easier for you, you're only here once a year or something.

Quote
I do much better and send the writes to the currently fetched pixel in the dot-based PPU. I used to do it for the scanline-based renderer, but I have it disabled by an "if(1 || regs.display_disabled)" block. Unfortunately, I don't remember why I did that now :/

Yes, the accuracy PPU should be doing exactly what it's currently doing. That one is hardware accurate (or close enough, at least), changing that would be foolish. I'm only interested in the perf/bal PPUs, some of our users believe testing in -bal is enough to guarantee hardware compatibility.

Maybe you did find another game that does stupid CGRAM writes. You've got some highly dedicated fans on your boards, perhaps one of them could remember or figure it out?

Quote
It's Uniracers!! Uniiiiiiiiiiiiiiracers! Remember that one?

Not really. Some random racing game nobody really cares about, close enough.

e: okay kaijyuu, maybe someone does care. And apparently Ridge Racer wasn't even a SNES game.

Quote
I've seen a few posts here about stuff working on bsnes, but not hardware.

Yes, here's one of these reports. Let's hope someone can figure it out, those bugs are always confusing.

I've also seen some reports of this one containing SRAM-related breakage.
<blm> zsnes users are the flatearthers of emulation
How dare you. I loved Uniracers as a kid :(
Just going to toss this out since it was mentioned by byuu in the thread at one point:

True and I are planning on creating a very basic flash cart for SA-1 testing. It will of course need donor carts for the SA-1 chip, but there are a few cheap enough ones out there.

This cart will not go public -- I don't want to see an influx of people cannibalizing more carts than necessary. That said, hopefully we will able to produce a few to get them to the most prominent hackers and developers in the SA-1 field. It really all depends on what I can afford to do, college is eating money faster than I can make it -- but thats a whole different rant.

Development won't fully get started until I can buy a few donor carts and start confirming pinouts. There are a few documents online, but they seem to be inconsistent at best, so I want to verify it myself. At this point I just have a rough sketch and a speculative materials list.

I don't suppose you know off hand how many SA-1 versions are floating around in the wild do you? Specifically as reported by $230E. Because if there are significant revisions (I've yet to read of any) I want to make sure to mount the SA-1 in a QFP socket so that we can test the different versions without needing more than one cart.

This is the plan anyways, the goal is to try and get things done by august or so. I'll keep you posted if you're interested, byuu.
Originally posted by byuu
I've seen a few posts here about stuff working on bsnes, but not hardware. If anyone here ever narrows down what exactly the cause is, I will absolutely fix it in bsnes, or tell you why it's impossible. So please do let me know if you find things. Just note that I don't have the time to debug entire ROM hacks, so I need help narrowing down the specific causes.

(possibly) mid-screen interlace. see this post of mine, and this post for results. it may have been an error on the tester's end, or on my end, but i wouldn't know unless more people tested

also, learn to use the quote button you baka #thp{=0}
> It's easier for you, you're only here once a year or something.

The way to go is to make your own forum. Then you get to set the rules and make sure you don't have to put up with anyone you don't want to. "It's good to be the king!"

> some of our users believe testing in -bal is enough to guarantee hardware compatibility

Mmm, that's not good. I think I would cry if bsnes became the next ZSNES one day. But that is somewhat unlikely: there may be another super-accurate SNES emulator on the horizon one day soon (and no, it's not ZSNES v2.0)

> I don't suppose you know off hand how many SA-1 versions are floating around in the wild do you?

I'm not aware of there being more than one version.

> I'll keep you posted if you're interested, byuu.

I would be extremely interested in buying one or two of them, thank you!

qwertymodo made me a Cx4 flash cart, which I really need to get around to performing tests on.

An SA-1 cart would definitely go a really long way toward improving SA-1 support. The one thing I would ask is that the ROM be replaced with a SRAM chip as well, and hopefully we could find a way to write to it (the SA-1 may not connect the /WR line to ROM at all), that way we can test for any differences between ROM and BWRAM. It can be a tiny SRAM chip.

Currently, it may be possible for me to use a cart-swap trick to test SA-1 code in BWRAM, but the SA-1's internal CIC blocks that trick. I have a console made by ikari that lets me do this, but I used it for dumping the entire US game set, so now it's starting to fail on me. I'll probably try and push it to dump all the Japanese SA-1 carts and then put it to rest.

> (possibly) mid-screen interlace.

Hmm. I know you can toggle that mid-screen, but there's a trick to it: the actual selection of even or odd lines to draw to on the television is selected at the start of the frame; so if you just turn it on in the middle of the display, it's just going to screw up the tiledata Y indexing, so your tiles will be interleaved on a progressive display or vice versa.

But I emulate that, so I wonder if maybe the point where you're toggling interlace is the problem. I don't know the exact point where hardware caches this yet, just that it does.

> also, learn to use the quote button you baka

Takes too long :P

I need that extra time to reply to more threads get work done.
Alright, I'll be sure to let you know when its ready. Doing an SRAM version should also be totally viable, I'll keep that in mind, anything else that would be useful?
Originally posted by byuu
Hmm. I know you can toggle that mid-screen, but there's a trick to it: the actual selection of even or odd lines to draw to on the television is selected at the start of the frame; so if you just turn it on in the middle of the display, it's just going to screw up the tiledata Y indexing, so your tiles will be interleaved on a progressive display or vice versa.

looking at the code, apparently i have interlace enabled in NMI, then disable it the first chance possible during screen rendering (irq on first scanline), then reenable it sometime after on another scanline (then disable it again later, until NMI reenables yay loop). would the same still apply in this case?

edit: another hardware test (on Torchkas' PAL system) shows the same flicker happen, so i guess its not an edge case
> anything else that would be useful?

Nothing off the top of my head, but thanks!
Be sure to ping me on my board or through e-mail.
I don't really stop in much here, unless someone links me.

> would the same still apply in this case?

Possibly, yes. Can't say for sure since I don't know when the CPU caches the interlace flag for the actual screen rendering.

If that ROM of yours only displays the one screen and nothing else, and you can post the source of it too, then we can post it up on my board and whenever someone has time, we can look into it.

EDIT: okay yeah, nice that it's just one screen then.

I put up a topic here:
http://board.byuu.org/phpbb3/viewtopic.php?f=4&t=446&p=9576#p9576

No promises we'll fix it; but could you provide commented source for this? Makes it easier than using a disassembler.
Originally posted by byuu
I put up a topic here:
http://board.byuu.org/phpbb3/viewtopic.php?f=4&t=446&p=9576#p9576

No promises we'll fix it; but could you provide commented source for this? Makes it easier than using a disassembler.

will finally use my byuuforum account for something useful #thp{>_<2}

and yeah, i'll go fix up my code before posting it there. thanks
Originally posted by RanAS

ZMZ - ZSNES interface with the accurate emulation of other SNES emulators


Ok, thank you for the suggestion. I have been finding of late that ZSNES has been acting quite unstable and unreliable, so I figure I should retire it. In its place I will certainly try out ZMZ as you suggested.

And yet most hacks actually work with ZSNES than ZMZ or Snes9x.


Originally posted by Erikas0012
And yet most hacks actually work with ZSNES than ZMZ or Snes9x.


Please, do not bump. This thread is over 3 years old. Closing this.





Dream team (feed them, please):






Link Thread Closed