bsnes v0.033 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
byuu

Post by byuu »

Make that b-saturn/ maybe
Do you really want me to work on a Saturn emulator? :P

In all seriousness, I'd obviously focus on dynarec and speed, given the demands of the system. The problem is that I know absolutely nothing about 3D. I barely understand sin and cos, so there's no way I could pull off a Saturn emulator, much as I'd love to.

I would like to work on a new emulator to get a fresh perspective, but not many other systems interest me much. The ones that do all have really accurate emus already (Kega / Regen for Genesis / Sega CD, gambatte for GB/C, Nestopia / Nintendulator for NES.) Wonderswan would be neat, but the linker is impossible to find, and there's not much for the dead system anyway.
Might as well keep focusing my efforts on the SNES, no need to be a jack of all trades (and a master of none.)
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)
Yeah, I don't quite understand why there are literally like 100 active NES emulators, and nobody working on SNES research :/
But to be fair, most of the NESdev people simply aim to pass test ROMs from others, and don't actually run hardware tests to emulate new stuff (or is there even anything left? :P)
Understandable, as the hardware is very hard to get ahold of.

---

Oh, and Dullaron, I don't know why it doesn't work in an old release. New release will be out very shortly, please be patient :D
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

No problem man. Take your time.

I just trying it out. That all.
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Snark wrote: 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.
It's premature to speculate, but the NES hardware has some similarities to the SNES, it's more popular for homebrew, it's slower and has no special chips, hiro and libco are already written, existing documentation is better than the SNES, and byuu himself is better. It wouldn't be anywhere near the struggle bsnes was. You're right that a lot of good emulators already exist, but I'm spoiled by the bsnes gui. It's hard going back to "Are you sure you'd like to exit?", no multiplier eyeball stretching, etc. You'd think these people would learn, but they won't.

The Saturn would be tough, especially from a testing standpoint since it used CDs. Nobody really documents those, so you'd be chasing phantom bugs from bad rips all day. The NES does have nuances, its roms don't have internal checksums or a sensical pcb mapping system, but bootgod is doing a real god job verifying data these days.

To get the thread back on track, though, I really dig the optimization on the SPC7110. All speed drops are gone now. I couldn't reproduce anything in Street Racer, so I'm taking it off the list. I should offer a bounty at this point to anyone who can find another bug that isn't PPU based.

Two minor things that have probably been forgotten in all this excitement that could make the next release: libui is still not changed to "hiro" in the license, both online and text based. And mudlord wanted to be added to the contributors for his OpenGL stuff.
Snark
Trooper
Posts: 376
Joined: Tue Oct 31, 2006 7:17 pm

Post by Snark »

FitzRoy wrote:You're right that a lot of good emulators already exist, but I'm spoiled by the bsnes gui. It's hard going back to "Are you sure you'd like to exit?".
I'm pretty sure you only need to turn this off once in the gui in Nestopia..
I want to fry~~ Sky Hiiiiiiiiigh~
Let's go-o-o-O~ togeda~
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Snark wrote:
FitzRoy wrote:You're right that a lot of good emulators already exist, but I'm spoiled by the bsnes gui. It's hard going back to "Are you sure you'd like to exit?".
I'm pretty sure you only need to turn this off once in the gui in Nestopia..
Once too many. That's not exactly my only complaint for that particular emulator, I was just trying to make my point succint. I'm going to do a writeup one day UIs even if no one reads it. There's some seriously weird bloat out there.
byuu

Post by byuu »

New WIP, probably not worth downloading.

For the sake of completeness, I finished optimizing the SPC7110 code. I've converted the pixel buffer rotation from swaps to moves, which should double the speed of the slowest part. I've also added reverse morton lookup tables (2x8-bit and 4x-8-bit deinterleaving), which are 8-10x faster than doing it using pure bit logic, I removed the redundant comparisons from the pixel context lookup (though a compiler would've done the same anyway), and lastly I've cut the mode2 context table in half, since the refcon add bit was only set on context 1 anyway. I could've replaced the other half with 5-6 if/else statements, but I didn't see much of a point in that since it'd only make the code harder to understand.

That results in a 1-2fps speedup, at best. Really, the code is simply not a bottleneck. It's pointless to optimize anymore, as any changes from this point on will just make it harder to understand what's happening. I only added the morton tables because it does seem to aid readability.

Also added translate[] wraps around all the new status messages, and moved the two checkbox options on the paths window to the advanced options list. No sense cluttering up the UI with near-useless settings.
It's hard going back to "Are you sure you'd like to exit?", no multiplier eyeball stretching, etc.
Heh, yeah. I never understood the floating point multiplier setups in some emulators. I guess it's useful if you want your video output size to be π x e.

I thought about the "Are you sure?" thing, it'd be nice if you accidentally close the emulator, so you don't lose your save. But I quickly realized that despite using emulators for ten years, I've never once actually done that. The only point where it might be appropriate is if I add mouse / SS support, since you may want to have the cursor near the top right of the window with the menubar off in windowed mode (though you're just asking for trouble at that point, honestly.)

To be fair though, you helped design at least half the bsnes GUI, so obviously you should like it :P
I should offer a bounty at this point to anyone who can find another bug that isn't PPU based.
Super Power League 4 seems to die after an inning or two with a S-SMP crash. I still need to try screwing with the CPU/SMP scalars and try substituting with anomie's DSP core to see if it still dies. If neither of those affect it, it could very well be due to a timing issue with not emulating the delays of the SPC7110 chip or something.
If someone wants to rule out the DSP core, they could try playing a SPC dump from the game in one of the plugins that use blargg's core. I doubt it's that, personally.

The usual rules about special chips apply, but you can list it as a bug if you like. I probably will with a note. Maybe I can figure it out before release. Probably not, but who knows.

Sigh, it's always the god damn baseball and golf games, isn't it? I'd probably half-ass the game too, if it were my job to work on one.
Two minor things that have probably been forgotten in all this excitement that could make the next release: libui is still not changed to "hiro" in the license, both online and text based. And mudlord wanted to be added to the contributors for his OpenGL stuff.
Ah, thanks. Updated the license file. Decided against listing all the libraries there for now, as they're getting quite numerous.

As for credits, mudlord is already listed in the source file, and the contributors list is for people who have submitted code to the core of the emulator. It's not a good system, I admit. That obviously excludes you and tetsuo55, despite the fact that your testing has been one of the most helpful things I've received.

It's not that I mind listing people, but I don't want that window to become cluttered with 100+ names of everyone up to and including people pointing out spelling mistakes in WIPs. That would make the window really onerous to look at.
I really don't want to come off as rude here, I'm really truly grateful to everyone who has helped out even a little, and I'm happy to thank them all in some perpetual fashion (eg website thank yous tend to disappear as the news falls off the page.)

That's the second time someone's brought that list up. I was afraid that adding such a list would just end up causing problems. Maybe I should just remove the contributors list on the about screen, and put everyone in the readme.txt file, so that everyone who ever contributed anything is listed?
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: I thought about the "Are you sure?" thing, it'd be nice if you accidentally close the emulator, so you don't lose your save. But I quickly realized that despite using emulators for ten years, I've never once actually done that.
Neither have I, and I've never seen anyone request it, either. Therefore, we can logically assert that it incurs greater costs than benefits, which is my definition of a device not worth implementing.
Super Power League 4 seems to die after an inning or two with a S-SMP crash. I still need to try screwing with the CPU/SMP scalars and try substituting with anomie's DSP core to see if it still dies. If neither of those affect it, it could very well be due to a timing issue with not emulating the delays of the SPC7110 chip or something.
If someone wants to rule out the DSP core, they could try playing a SPC dump from the game in one of the plugins that use blargg's core. I doubt it's that, personally.
Damn, a horrific crash bug (not for the list, though). First two times I tried today, it died in the first at-bat. Third time it died in the second inning. Happens in .033 and the latest WIP, so it has nothing to do with changes since then, which is probably a good thing. And Koushien 2 is still fixed, I checked.
mudlord
has wat u liek
Posts: 559
Joined: Tue Sep 11, 2007 2:54 pm
Location: Banland.

Post by mudlord »

Do you really want me to work on a Saturn emulator? :P

In all seriousness, I'd obviously focus on dynarec and speed, given the demands of the system. The problem is that I know absolutely nothing about 3D. I barely understand sin and cos, so there's no way I could pull off a Saturn emulator, much as I'd love to.
Yes! It will be quite a interesting thing to see a Saturn emu from you. And plus you will learn alot about 3D in the process. 8)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

mudlord wrote:
Do you really want me to work on a Saturn emulator? :P

In all seriousness, I'd obviously focus on dynarec and speed, given the demands of the system. The problem is that I know absolutely nothing about 3D. I barely understand sin and cos, so there's no way I could pull off a Saturn emulator, much as I'd love to.
Yes! It will be quite a interesting thing to see a Saturn emu from you. And plus you will learn alot about 3D in the process. 8)
I just read that the Saturn has two CPUs at 28mhz, and six other processors... and that it's complexity was one of the reasons it wasn't successful. Good luck!
King Of Chaos
Trooper
Posts: 394
Joined: Mon Feb 20, 2006 3:11 am
Location: Space

Post by King Of Chaos »

It's actually easier to emulate the Dreamcast than the Saturn.
[url=http://www.eidolons-inn.net/tiki-index.php?page=Kega]Kega Fusion Supporter[/url] | [url=http://byuu.cinnamonpirate.com/]bsnes Supporter[/url] | [url=http://aamirm.hacking-cult.org/]Regen Supporter[/url]
bdmosky

Post by bdmosky »

Might as well make an Atari Jaguar emulator while you're at it. Another multiprocessor bitch of a system to emulate ;)
Snark
Trooper
Posts: 376
Joined: Tue Oct 31, 2006 7:17 pm

Post by Snark »

FitzRoy wrote:
mudlord wrote:
Do you really want me to work on a Saturn emulator? :P

In all seriousness, I'd obviously focus on dynarec and speed, given the demands of the system. The problem is that I know absolutely nothing about 3D. I barely understand sin and cos, so there's no way I could pull off a Saturn emulator, much as I'd love to.
Yes! It will be quite a interesting thing to see a Saturn emu from you. And plus you will learn alot about 3D in the process. 8)
I just read that the Saturn has two CPUs at 28mhz, and six other processors... and that it's complexity was one of the reasons it wasn't successful. Good luck!
Not successful?
Segata Sanshiro

Certainly not successful in North America and probably not Europe but it was very successful in Japan. 2D wise, the Saturn was (well 'is' as I have a very functional unit) way ahead the PSX.

edit:

sniff :(

but yeah, an extreme b*tch to emulate for certain. probably not possible to emulate accurately and get anywhere near playable level framerates...

edit2: on a more positive ending note
Last edited by Snark on Sat Aug 09, 2008 8:26 am, edited 1 time in total.
I want to fry~~ Sky Hiiiiiiiiigh~
Let's go-o-o-O~ togeda~
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

byuu wrote:http://img379.imageshack.us/img379/982/ ... tapbk3.jpg

...

Hard to say, but the adapters are dirt cheap on eBay. If someone really wants it figured out, cover the cost + shipping and I'll pick one up.
Alright, I give up. Here's a write up of all I figured out so far (including data on some controller port details that I couldn't remember and had to test):
http://neviksti.com/SNES/TribalTap.txt

If you, or anyone else that has the means to try to figure this thing out, and wants one to run tests on, please let me know. I'll paypal you the money to get one on Ebay.

I can't believe we figured out a compression chip, but I got stumped by this simple little thing. It's got to be something simple I'm overlooking.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Snark wrote: Not successful?
Sales-wise for the same target audience. The PS1 outsold it 105 million to 17 million. In fact, the PS1 outsold every Sega console combined by about 40 million.
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

Is that why Sega Dreamcast went into retirement?
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
byuu

Post by byuu »

Trying to at least find the source of the SPL4 freeze.

Seems to be happening here:

Code: Select all

//$02f0=hi
..083c mov   a,$02f0+x         A:00 X:00 Y:00 SP:012d YA:0000 nvpbhiZC

..083f mov   y,a               A:23 X:00 Y:00 SP:012d YA:0023 nvpbhizC
//$02e0=lo
//->$234b
//should be $1700-$1aff

..0840 mov   a,$02e0+x         A:23 X:00 Y:23 SP:012d YA:2323 nvpbhizC

..0843 movw  $000,ya           A:4b X:00 Y:23 SP:012d YA:234b nvpbhizC

..0845 mov   y,#$00            A:4b X:00 Y:23 SP:012d YA:234b nvpbhizC
//$234b = f0

..0847 mov   a,($000)+y        A:4b X:00 Y:00 SP:012d YA:004b nvpbhiZC

..0849 incw  $000              A:f0 X:00 Y:00 SP:012d YA:00f0 NvpbhizC

..084b cmp   a,#$d0            A:f0 X:00 Y:00 SP:012d YA:00f0 nvpbhizC

..084d bcc   $0858             A:f0 X:00 Y:00 SP:012d YA:00f0 nvpbhizC

..084f sbc   a,#$d0            A:f0 X:00 Y:00 SP:012d YA:00f0 nvpbhizC

..0851 asl   a                 A:20 X:00 Y:00 SP:012d YA:0020 nvpbHizC

..0852 mov   $004,x            A:40 X:00 Y:00 SP:012d YA:0040 nvpbHizc

..0854 mov   x,a               A:40 X:00 Y:00 SP:012d YA:0040 nvpbHizc

..0855 jmp   ($1491+x)         A:40 X:40 Y:00 SP:012d YA:0040 nvpbHizc

..0d71 mov   x,$004            A:40 X:40 Y:00 SP:012d YA:0040 nvpbHizc

..0d73 mov   a,($000)+y        A:40 X:00 Y:00 SP:012d YA:0040 nvpbHiZc

..0d75 incw  $000              A:f0 X:00 Y:00 SP:012d YA:00f0 NvpbHizc

..0d77 mov   $0210+x,a         A:f0 X:00 Y:00 SP:012d YA:00f0 nvpbHizc

..0d7a mov   a,($000)+y        A:f0 X:00 Y:00 SP:012d YA:00f0 nvpbHizc

..0d7c incw  $000              A:0f X:00 Y:00 SP:012d YA:000f nvpbHizc

..0d7e mov   $0340+x,a         A:0f X:00 Y:00 SP:012d YA:000f nvpbHizc

..0d81 jmp   $0845             A:0f X:00 Y:00 SP:012d YA:000f nvpbHizc

..0845 mov   y,#$00            A:0f X:00 Y:00 SP:012d YA:000f nvpbHizc
//$234c = fe (fe-d0=2e) (2e<<1=5c)

..0847 mov   a,($000)+y        A:0f X:00 Y:00 SP:012d YA:000f nvpbHiZc

..0849 incw  $000              A:fe X:00 Y:00 SP:012d YA:00fe NvpbHizc

..084b cmp   a,#$d0            A:fe X:00 Y:00 SP:012d YA:00fe nvpbHizc

..084d bcc   $0858             A:fe X:00 Y:00 SP:012d YA:00fe nvpbHizC

..084f sbc   a,#$d0            A:fe X:00 Y:00 SP:012d YA:00fe nvpbHizC

..0851 asl   a                 A:2e X:00 Y:00 SP:012d YA:002e nvpbHizC

..0852 mov   $004,x            A:5c X:00 Y:00 SP:012d YA:005c nvpbHizc

..0854 mov   x,a               A:5c X:00 Y:00 SP:012d YA:005c nvpbHizc

..0855 jmp   ($1491+x)         A:5c X:5c Y:00 SP:012d YA:005c nvpbHizc
//this code never before hit

..0d4f jmp   $0845             A:5c X:5c Y:00 SP:012d YA:005c nvpbHizc
It's never supposed to index into the table at $5c, apparently. Every time it hits $0d4f, the game dies soon after. If I force it to jump from $0d4f to $0bc7 (a point it does jump to every now and then), I can clear the game with ~14 redirects:

Image

My best game yet! I'm the away team (bottom row.)

Things I've ruled out:
- fails with either blargg's or anomie's S-DSP core
- fails with S-DSP echo writes disabled
- fails regardless of CPU<>SMP skew, but the greater the skew, the quicker the failure
- fails even with some BSed delays in SPC7110 decompression reads (especially those that have indexes > 0 into decompression.) Though it's still possible it's just really timing sensitive and needs to be much more accurate to work
- doesn't appear to be any kind of obvious S-SMP bug, and it's extremely unlikely to be a timing bug in the core, due to passing blargg's extensive cycle-testing SMP test program
- doesn't appear to be a flag bug, due to tests from myself, Overload and possibly in blargg's test program
- game also doesn't appear to use any complex SMP opcodes, all standard fare stuff. If there were bugs in them, it would show up in other games.

Very strange ... so basically I still have no idea what's wrong. Tracing back the code is just leading me through infinite looping recursions. I've gone back 6-7 routines, and I keep picking the wrong forks in the code, forcing me to go back some more toward the crash.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

Is there a confirmed good dump of SPL4, or is it just a single dump?
byuu

Post by byuu »

It's supposedly confirmed, but I'm not sure by who. I imagine John Weidman, as he was the one who dumped the other SPC7110 games, including SJnS.

Of course the odds of there being one bad byte that just happens to crash the S-SMP and affect nothing else is quite unlikely :/

It doesn't appear that I'm going to be able to trace back the source of this problem. The code is forking repeatedly on me. For instance, right now it gets into a bad path with $015 != 0 and $02e0,$02f0 == #$2348. At the same spot, there are cases when either $015 != 0 or $02e0,$02f0 == #$2348, where the code works fine.

How am I supposed to know what to look for? Where $015 is set to non-zero, or where the address is set to #$2348? I'm already tens of thousands of opcodes from the guaranteed point of failure backward into the code.
byuu

Post by byuu »

End game, sigh.

http://byuu.cinnamonpirate.com/temp/spl4_notes.txt

The code sets $000 to #$233f in both good and bad paths, and increments whilst setting up for a transfer. It stops at #$2347. Then it runs some code, and checks $f4 (APU I/O port #0). If not zero, it runs the good code that ends up writing to ($002+x), which resolves to $000. This seems to be some sort of transfer of data. However, on the bad path, when it checks $f4, it is zero. This causes it to skip the code that resets $000.

At the end of the routine when the code paths merge back, it increments one more time, giving you #$0001 (good) and #$2348 (bad). It then writes that data to $02e0,$02f0. Later on it uses that data to set $000 again. It then reads a couple of values and then uses one as an index into a jump table. Because it ends up reading from #$23xx, it gets a bad value and jumps to an entry that ends up locking up the system. The jump it hits varies, so it's never the same codepath where things eventually die.

So in summation, if the S-CPU doesn't write a certain value to the APU I/O port in a narrow window of time, the game ends up dying. That virtually rules out any bugs in the S-SMP, and makes it most likely to be a timing issue.

With the S-CPU and S-SMP timing as accurate as they are now, and with the SPC7110 in play and its timing not emulated at all, that gives us a solid dead-end.

I'm completely unable to fix this bug without using a hack.
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

Time to emulate add on cpu's as their own entity then, then they can run with their own mhz and the delays will be accurately emulated.
byuu

Post by byuu »

tetsuo55 wrote:Time to emulate add on cpu's as their own entity then, then they can run with their own mhz and the delays will be accurately emulated.
That's not going to happen, sorry. Even if I knew what the delays should be, I wouldn't want to take a major speed hit in the scheduler for all games just to fix this one. And honestly, I'm not even convinced that's the issue. But what else could it be?

I really have absolutely no idea what the hell is going wrong with this game. It's the first one since I started working on the emulator where I haven't been able to at least locate the true point of failure via back tracing.

For v035, I'll probably add address resolution to the S-SMP debugger (so you know what literal address ($002+x) is going to access), and some tracing options via keyboard bindings, and then offer a nice bounty if anyone can spot the problem.

As an aside, I was trying to work on a template function system to replace the current opcode .b->.cpp translator, but that looks like a dead end, too. It's being a real bitch with me about template arguments.

Code: Select all

template<uint8_t fn(uint8_t, uint8_t), flag &f>
void op_read_const() {
  if(f == true) uint8_t result = fn(op_read(), op_read());
}

flag pn;
struct P {
  flag n;
} p;

void (*table[256])();
//this works
table[0] = &op_read_const<op_adc, pn>;
//and yet this does not
table[1] = &op_read_const<op_adc, p.n>;
How very annoying.
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

If you ask me, I find it much less desirable for bushing to use his talent on a saturn emulator. I think that if he is going to go on a new project, one of the special chips would be a better idea. Or plain one of the other extra controllers, the multitap looks lonely in the menu ;)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote:End game, sigh.
I'll probably add something to the FAQ regarding bugs in special chip games. The best you can do is emulate something to capacity, and if it hangs, it hangs. Gundam GX crashes, too, though that one is probably because no one really finished REing the last two DSP chips.
henke37 wrote:Or plain one of the other extra controllers, the multitap looks lonely in the menu Wink
Nach said something about doing it, who knows. But it's been asked 10 times before, there's no point in asking an 11th.
byuu wrote:My best game yet! I'm the away team (bottom row.)
lol, you were doing pretty good until the 6th inning.
Jonas Quinn
ZSNES Developer
ZSNES Developer
Posts: 115
Joined: Thu Jul 29, 2004 9:51 pm
Location: Germany

Post by Jonas Quinn »

byuu wrote:End game, sigh.

http://byuu.cinnamonpirate.com/temp/spl4_notes.txt

The code sets $000 to #$233f in both good and bad paths, and increments whilst setting up for a transfer. It stops at #$2347. Then it runs some code, and checks $f4 (APU I/O port #0). If not zero, it runs the good code that ends up writing to ($002+x), which resolves to $000. This seems to be some sort of transfer of data. However, on the bad path, when it checks $f4, it is zero. This causes it to skip the code that resets $000.

At the end of the routine when the code paths merge back, it increments one more time, giving you #$0001 (good) and #$2348 (bad). It then writes that data to $02e0,$02f0. Later on it uses that data to set $000 again. It then reads a couple of values and then uses one as an index into a jump table. Because it ends up reading from #$23xx, it gets a bad value and jumps to an entry that ends up locking up the system. The jump it hits varies, so it's never the same codepath where things eventually die.

So in summation, if the S-CPU doesn't write a certain value to the APU I/O port in a narrow window of time, the game ends up dying. That virtually rules out any bugs in the S-SMP, and makes it most likely to be a timing issue.

With the S-CPU and S-SMP timing as accurate as they are now, and with the SPC7110 in play and its timing not emulated at all, that gives us a solid dead-end.

I'm completely unable to fix this bug without using a hack.
It's a problem with the $4810 register.
Snes9x is using "if((r481x & 0x07)!=0x07) return 0x00;" and this seems to fix the SMP crash and a display bug after starting a new game where you are asked to choose a pitcher.
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Dullaron wrote:Is that why Sega Dreamcast went into retirement?
Yeah. They killed the assembly lines shortly after the PS2 came out, since the PS2 launch flew past it.
...
Then pulled US units for Japan, and reopened the assembly lines.
Locked