Current Status FAQ

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

syntax_
New Member
Posts: 8
Joined: Sun Oct 21, 2007 4:24 am

Post by syntax_ »

what I'm getting at is since its been suggested FX and SA emulation being un-realistic at least in bsnes and perhaps high system requirements for the re-coded zsnes; maybe if at all possible use ASM optimized code for the co-processor emulation reducing the overhead.
I should also note that I have started on SuperFX emulation, as some will inevitably see said code in my source releases. What I have now is nothing more than a skeleton implementation, and absolutely nothing using it is playable yet. I am making absolutely no promises that I will ever be able to emulate this chip. It will take at least several months of work, and even then, the speed will probably be too slow to reach 60fps on any system
the quote above is from the bsnes homepage and since its been suggested the new core in zsnes will have much higher system requirements and FX emulation requirements being even higher wouldn’t it be practical to code these co-processors in a code that could potentially reduce the requirements needed?

the 32x is a more powerful duel processor based megadrive upgrade, this compared to the Super FX chip, yet kega (which also emphasizes accuracy) requires very little when compared to just emulating the SNES under bsnes. another emulator written in pure C++ nestopia also in contrast to the system emulated has a high system requirement (recommended 1.4ghz). Portability I understand is a key factor and that is noble in that it does cater to the minority using operating systems other then windows/linux, but if emulation comes to a standstill because of current hardware restrictions’ doesn’t that create a necessity to use code that could potentially allow for accuracy and playability? what position does this place those with computers/consoles that lack the technology to use/port the emulators in the first place?

I wouldn’t bring this up if I wasn’t intrigued by the future plans on zsnes and work being done with bsnes for that matter. I mean will my 3000+ Athlon64 be enough when it comes to the added extra chip support with zsnes? my apologies if this comes across as rather curt and my intentions are only of the positive nature; admittedly I'm not much of a programmer besides some basic TI calculator games and XML.

thanks
byuu

Post by byuu »

what I'm getting at is since its been suggested FX and SA emulation being un-realistic at least in bsnes and perhaps high system requirements for the re-coded zsnes; maybe if at all possible use ASM optimized code for the co-processor emulation reducing the overhead.
Most of ZSNES (especially the core parts) are in assembler now anyway. The rewrite isn't going to change that, except for blargg's stuff they're adding: the SMP and DSP, which aren't particularly resource intensive to begin with.
the 32x is a more powerful duel processor based megadrive upgrade, this compared to the Super FX chip, yet kega (which also emphasizes accuracy) requires very little when compared to just emulating the SNES under bsnes.
To what degree does Kega emphasize accuracy? Right, hard to say isn't it? It's easy for an emulator author to say his emulator is accurate. Note that I'm not downplaying Kega's accuracy, I've never used it. Hell, I wouldn't even call my emulator accurate (because S-PPU timing is a total joke). Just moreso than current emulators. It's more of a focal point and goal for me than something I've realized.

The accuracy I'm talking about is a different problem than the language used: I focus on the level of precision that chips running in parallel can talk to each other, and how precise that communication is.

On a PC, you can only emulate one processor at a time, but the SNES has lots and lots of processors. And many of them talk to each other quite frequently. And before you ask: no, multicore processors won't help at all. The overhead of context switching there is way too high. The overhead in bsnes mostly comes from the fact that it switches between different processors to execute no more than one cycle at a time. I'm also a lousy programmer so that's part of the problem there.

Anyway, I'd be seriously impressed if Kega synchronized this frequently. And to answer your question, I don't think writing in assembler will help things very much. My thread switching code is already written in assembler.
syntax_
New Member
Posts: 8
Joined: Sun Oct 21, 2007 4:24 am

Post by syntax_ »

bsnes is a work of art, imo snes emulation wouldn’t be where it’s at today if it wasn’t for your expertise/determination/further reverse engineering and open source distribution. all I have is respect for the work being done on both emulators.
byuu wrote:To what degree does Kega emphasize accuracy? Right, hard to say isn't it? It's easy for an emulator author to say his emulator is accurate. Note that I'm not downplaying Kega's accuracy, I've never used it.
I agree there is no definitive way to tell if kega is as accurate as said to be especially given the source code is closed (no third party verification). however there are other ways to make this determination, first and foremost it emulates not only the sega genesis/megadrive but also emulates the 32x and segacd in parallel meaning it can run games that require both 32xCD, there is no other emulator that can do this besides a non-functioning attempt by the emulator known as ages. the barebones is 2x motarola 68000 cpus (one in the megadrive itself) & 2x 32bit SH-2 32x processors running in conjunction. I'm certain kega requires synchronization, there is a perfect sync option for the two 68000 cpus. compatibility is seemingly 100% (minus virtua racer, it uses an internal chip yet to be reversed engineered, sms/gg emulation isnt perfect). its the only 32x emulator that doesnt require the bios files; requires around 1ghz for full speed emulation.
before you ask: no, multicore processors won't help at all.
I don't have a duel core and have no plans at least in the near future of building a new system. :(
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

It might be much easier for these systems. If the Mega Drive uses only one clock to synchronize all components (btw. I don't know if it does), then emulation could be much faster.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
sweener2001
Inmate
Posts: 1751
Joined: Mon Dec 06, 2004 7:47 am
Location: WA

Post by sweener2001 »

While not expecting WIPs or anything like that, will the FAQ become updated, or the occasional announcement made when a milestone like gui complete or core implemented occurs?
[img]http://i26.photobucket.com/albums/c128/sweener2001/StewieSIGPIC.png[/img]
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Post by I.S.T. »

I believe the link in the first post is broken.
neo_bahamut1985
-Burninated-
Posts: 871
Joined: Mon Sep 10, 2007 11:33 pm
Location: Unspecified

Post by neo_bahamut1985 »

Yep, that link is broken alright
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Post by I.S.T. »

Is this gonna get fixed? It's been broken for nearly two months at the very least...
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

We are moving away from assembly because it's not portable and there have been many advances in the field of C/C++ compilers recently that make doing most things in assembly pointless.

The main thing that will remain assembly are video filters and possibly video code to make use of MMX, but this may be ported as well to optimized instisticts (sp?).

ZSNES 2.0 is coming along nicely but it's a huge huge untertaking and I am doing most of the work myself so you guys will have to hang in there or use another good emulator, bsnes.

To be honest right now most of my problems are linux related because of the crappy way audio is handled in the OS, but I think I may have figured out how to get it working on 95% of sound cards.

Another improvement is scanlines will no longer be done in software and will be rendered in Direct3D or OpenGL, depending on the port.

Windows: DDraw/D3D9/OpenGL
Linux: SDL/OpenGL

DDraw and SDL will not contain scanlines, sorry, but it's just too much of a hassle to support this with scalable resolutions. The scanlines will also be done in a shader (if supported by the card) this speeds things up quite a bit as well. The old non shader OpenGL scanline code will remain for older cards.

Right now I am concentrating on the windows port and getting XAudio2 working nicely with it, as it is the replacement for DirectSound and renders directly to the Vista Audio Stack and supporting some UAC things in directories you don't own. I have also added the option to use the native file dialog for things if you wish, as the GUI is probably going to be replaced at some point anyway and some people like to use the open file dialog that goes along with their OS. (I am addicted to the search feature in Vista).

I am interested in who is still using Windows 2000 because it raises some compatibilty questions if I am going to continue to support it. MS officially ended 2000 support for DirectX sometime in 2005 and at the end of this year the OS will not be supported at all. So I am wondering if I should be supporting an unsupported OS so any input would be nice.
Watering ur plants.
blackmyst
Zealot
Posts: 1161
Joined: Sun Sep 26, 2004 8:36 pm
Location: Place.

Post by blackmyst »

I still use 2000, but I guess I'm gonna have to move to XP sometime soon anyway.

Though I wouldn't mind dropping certain features for 2000 to keep it working for the time being (if it is in fact that simple).
[size=75][b]Procrastination.[/b]
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.[/size]
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

If I may ask, how is the actual (accurate) emulation coming along? I'm not too sure if I should ask such questions these days... but some shots would be nice ;)

Take all the time that you think is needed, it's not like a few more months would matter here.
[i]"Change is inevitable; progress is optional"[/i]
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

Accuracy is certainly better than it was before, we are ahead in some areas compared to the traditional emulatiors and pre-1.51, some areas still need more work, particualry IRQ timings. But the CPU and SPU are now clocked properly and working together nicely as well as things like OpenBus.

The memory map still needs to be redone, I am still trying to think of a nice way of doing it. For now I am concentrating on client side code to get that working as well as possible so I don't have to deal with it later. On a side note there are no hacks left and the games that had hacks to make them work are working fine now. I still have some extreme tests that will use edge cases to work on but things are slowly progressing.

I also would like to get ahold of a Mac mini or something so I can start maintaining the Mac build of it as well.
Watering ur plants.
byuu

Post by byuu »

We are moving away from assembly because it's not portable and there have been many advances in the field of C/C++ compilers recently that make doing most things in assembly pointless.
Ah, this is very refreshing to hear. Hopefully I can contribute a little more in the future now.
To be honest right now most of my problems are linux related because of the crappy way audio is handled in the OS, but I think I may have figured out how to get it working on 95% of sound cards.
Nach, wertigon and _willow_ just wrote drivers for OSS3/4 and OpenAL, and I also have a libao driver. It's a very simple system I use (just call sample(l, r) when one is ready, the driver does the rest), and you're welcome to all of that code if you like. License is PD.

Or if you want more power, the OpenAL driver is extremely similar in concept to DirectSound, you could probably modify that to your liking. Both OAL and OSS sound really good and have very low frequency, so long as you aren't using shit ALSA drivers and the joke that is dmix.

Another benefit is that you mention XAudio2 ... while that will access the hardware directly, so will OpenAL. And OpenAL has the advantage that it works on Win2k and XP still.
I am interested in who is still using Windows 2000 because it raises some compatibilty questions if I am going to continue to support it.
Of the seven machines I have access to, only one has Win2k. But then, 2k and XP have so few differences that I can't see a compelling reason to kill off 2k support just yet, unless you're planning on axing XP support in another year or two (since it is only ~1 year older than 2k anyway.)
some areas still need more work, particualry IRQ timings
The only way I've ever gotten IRQ timing to work perfectly was to test every single clock tick. Of course, that requires a massive speed hit ... but after two full years and two dozen different algorithms trying to range test this ... ugh.

And honestly, once you try implementing it like that, the pieces fall into place in no time. My clock stepping IRQ tester was written in a single night, believe it or not.

Then again, you're a better coder than I, so perhaps you can pull it off :)
The memory map still needs to be redone, I am still trying to think of a nice way of doing it.
What's worked well for me was to set up a table with 65,536 pointers (sounds excessive, but it only eats 256k RAM) to classes that have read+write functions, one for every 256 bytes. I chose that number because it's the lowest power of two that can map even the smallest known region, which is the 768-byte SuperFX GSU region.

You end up saving RAM this way, too, as you no longer have to manually mirror the ROM to a power of two (up to 24mbit savings on DKJM2.)

Then write a few helper functions that can map blocks of memory to them, with mirroring and shadowing flags. Then, each new mapper only requires ~5-10 lines of code.

I think Nach came up with something similar, you may want to check with him, too.

Lastly, always map 00-3f|80-bf:2000-5fff to a special MMIO bank, that has 4,096 pointers to custom read/write classes. Just pass the bank byte along, as you'll need to know that for BS-X MMC mapping. If you still care about that. BS-X is just a giant clusterfuck of broken, hacked and damaged software. I'm 99% certain SNESGT has hacks for nearly every BS-X game it supports.
I also would like to get ahold of a Mac mini or something so I can start maintaining the Mac build of it as well.
I'd like to have a Mac, too, but I can't justify paying a 40% hardware markup for a TCPM chip that "grants me permission" to run the holiest of operating systems. And the funniest part is that they advertise that "their" machines will even run Windows. As if that's a selling point for their locked down product that would otherwise run just fine on "my" Core 2 system.
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

as far as I know, there's three files that aren't installed in the direct x 9c packages for windows 2000:

x3daudio1_0.dll
x3daudio1_1.dll
X3DAudio1_2.dll

I'm guessing all of these have something to do with pagefault dumping windows 2000 support right off the bat.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

good to hear news pagefault, really good.

random question, would there be any benefits to having a DX10 setting also?

I'm using XP right not, but I was just curious.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
snkcube
Hero of Time
Posts: 2646
Joined: Fri Jul 30, 2004 2:49 am
Location: In front of the monitor
Contact:

Post by snkcube »

byuu wrote:As if that's a selling point for their locked down product that would otherwise run just fine on "my" Core 2 system.
You can run Mac OS X 10.4 or 10.5 on PCs. It's just illegal to do (pretty obvious).
Try out CCleaner and other free software at Piriform
Image
I.S.T.
Zealot
Posts: 1325
Joined: Tue Nov 27, 2007 7:03 am

Post by I.S.T. »

Hell, you can find it easily on a google search... and I suck so bad at google a caveman can out-search me.

Edit: Just out of curiosity... Is the link in the first post going to be fixed?
_willow_
Hazed
Posts: 51
Joined: Mon Dec 24, 2007 2:03 am
Location: Russia
Contact:

Post by _willow_ »

XAudio2 is much better then DirectSound indeed. At least this API working on 2 platforms: WINDOWS and XBOX360. Much better then just WINDOWS.
The counter argument is i doubt XAudio2 do hardware rendering, i think it just translating calls to WASAPI or DirectSound. If you have the link to official page and it says opposite, please provide it.
Still, XAudio is a way better then DirectSound, because DS was discontinued to name it.

We have a good choice on windows, though: XAudio2, OpenAL, ASIO, WASAPI. OpenAL is known to do sources mix on hardware (sample rate conversion is the most important point here), dunno about XAudio2. ASIO is known to keep exact sample rate as the client requests. WASAPI is known to work in two modes: shared and therefore require software sample rate conversion and exclusive, which works very like the ASIO do.

And... it would be cool if ZSNES will share the same code with BSNES :D. I mean, those emulators do very alike tasks and can use similar code. May be just do up to standart the Sound Rendering API for both emulators :wink:?
[url=http://quake2xp.quakedev.com]quake2xp[/url] audio engineer
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

It's possible I will write a DirectSound plugin for 2000 people. But I am concentrating on XAudio2 because it writes directly to the hardware in Vista. In XP it wraps to DirectSound.
Watering ur plants.
neo_bahamut1985
-Burninated-
Posts: 871
Joined: Mon Sep 10, 2007 11:33 pm
Location: Unspecified

Post by neo_bahamut1985 »

Holy crap, from the looks of it, Zsnes is progressing very nicely...looking forward towards its next release, whenever that may be. Keep up the good work!
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...
Rydian
Lurker
Posts: 152
Joined: Mon Jul 02, 2007 9:10 pm
Location: Virginia
Contact:

Post by Rydian »

pagefault: I'm still using windows 2000!
On a 475mhz AMD K6-2, that's why. I really need a new machine and will be getting one soon, but most of my money goes towards important things like medical bills and food. I know very little about programming any compiled languages, but I can be a little ginuea pig if needed? Then again, other people probably have faster 2K machines.



Why not install OSX on a spare machine you have lying around, maybe? Get a spare machine from somebody?
It's not illegal, it's against the EULA, and EULAs have never been found legally binding in court.

Sure, violate it and you get no support from apple, but do you need it?
Athlon XP 2800+
765MB DDR-333
AGP Geforce 6200

Took me, what, a year to update this info?
And meh, screw legs.
Oh... puns. I get it. Shame on me.
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

byuu wrote:I'd like to have a Mac, too, but I can't justify paying a 40% hardware markup for a TCPM chip that "grants me permission" to run the holiest of operating systems.
..you mean there's REALLY a TCPM chip in the mac hardware?
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
odditude
Official tech support dood
Posts: 2118
Joined: Wed Jan 25, 2006 7:57 am

Post by odditude »

adventure_of_link wrote:..you mean there's REALLY a TCPM chip in the mac hardware?
Wouldn't surprise me in the least, as TPM chips can be found on "regular" motherboards too. Intel has been putting them on its higher end motherboards (I've seen them on D975XBXs), although the chip can be disabled.
Why yes, my shift key *IS* broken.
adventure_of_link
Locksmith of Hyrule
Posts: 3634
Joined: Sun Aug 08, 2004 7:49 am
Location: 255.255.255.255
Contact:

Post by adventure_of_link »

odditude wrote:
adventure_of_link wrote:..you mean there's REALLY a TCPM chip in the mac hardware?
Wouldn't surprise me in the least, as TPM chips can be found on "regular" motherboards too. Intel has been putting them on its higher end motherboards (I've seen them on D975XBXs), although the chip can be disabled.
We *are* talking about the same TCPM chip that supposedly doesn't allow free and open source apps to run, doesn't allow Linux to be used, controls what we can and cannot do with the computer, has 2048-bit encryption, etc etc, right?
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
byuu

Post by byuu »

..you mean there's REALLY a TCPM chip in the mac hardware?
Yes, there absolutely is.
We *are* talking about the same TCPM chip that supposedly doesn't allow free and open source apps to run, doesn't allow Linux to be used, controls what we can and cannot do with the computer, has 2048-bit encryption, etc etc, right?
It can do all of that, but Apple is only using it to prevent their OS from running on non-Mac hardware. So far.
Post Reply