View unanswered posts | View active topics It is currently Tue Sep 17, 2019 2:56 am



Reply to topic  [ 120 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Current Status FAQ 
Author Message
New Member
User avatar

Joined: Sun Oct 21, 2007 4:24 am
Posts: 8
Reply with quote
Post 
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.

Quote:
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


Mon Oct 22, 2007 4:14 am
Profile
Reply with quote
Post 
Quote:
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.

Quote:
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.


Mon Oct 22, 2007 7:15 am
New Member
User avatar

Joined: Sun Oct 21, 2007 4:24 am
Posts: 8
Reply with quote
Post 
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.

Quote:
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. :(


Mon Oct 22, 2007 8:33 am
Profile
Seen it all
User avatar

Joined: Mon Jan 03, 2005 5:04 pm
Posts: 2302
Location: Germany
Reply with quote
Post 
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


Mon Oct 22, 2007 9:06 am
Profile WWW
Inmate
User avatar

Joined: Mon Dec 06, 2004 7:47 am
Posts: 1751
Location: WA
Reply with quote
Post 
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?

_________________
Image


Mon Oct 22, 2007 10:08 pm
Profile
Zealot

Joined: Tue Nov 27, 2007 7:03 am
Posts: 1325
Reply with quote
Post 
I believe the link in the first post is broken.


Fri Dec 07, 2007 6:06 pm
Profile
-Burninated-
User avatar

Joined: Mon Sep 10, 2007 11:33 pm
Posts: 871
Location: Unspecified
Reply with quote
Post 
Yep, that link is broken alright

_________________
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...


Sat Dec 08, 2007 5:16 am
Profile
Zealot

Joined: Tue Nov 27, 2007 7:03 am
Posts: 1325
Reply with quote
Post 
Is this gonna get fixed? It's been broken for nearly two months at the very least...


Fri Dec 21, 2007 3:18 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
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.


Sun Dec 30, 2007 9:20 pm
Profile
Zealot

Joined: Sun Sep 26, 2004 8:36 pm
Posts: 1142
Location: Place.
Reply with quote
Post 
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).

_________________
Procrastination.
Hard Work Often Pays Off After Time, but Laziness Always Pays Off Now.


Sun Dec 30, 2007 10:57 pm
Profile
Regular
User avatar

Joined: Thu Jul 29, 2004 8:55 am
Posts: 265
Location: The Netherlands
Reply with quote
Post 
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.

_________________
"Change is inevitable; progress is optional"


Mon Dec 31, 2007 12:22 am
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
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.


Mon Dec 31, 2007 12:31 am
Profile
Reply with quote
Post 
Quote:
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.

Quote:
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.

Quote:
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.)

Quote:
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 :)

Quote:
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.

Quote:
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.


Mon Dec 31, 2007 2:23 am
Locksmith of Hyrule
User avatar

Joined: Sun Aug 08, 2004 7:49 am
Posts: 3634
Location: 255.255.255.255
Reply with quote
Post 
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.

_________________
Image
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.


Mon Dec 31, 2007 3:09 am
Profile YIM WWW
Inmate

Joined: Thu Jan 11, 2007 4:28 am
Posts: 1485
Location: Salem, Oregon
Reply with quote
Post 
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.

_________________
byuu wrote:
Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? >:(


Mon Dec 31, 2007 4:31 am
Profile WWW
Hero of Time
User avatar

Joined: Fri Jul 30, 2004 2:49 am
Posts: 2646
Location: In front of the monitor
Reply with quote
Post 
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


Mon Dec 31, 2007 7:59 am
Profile WWW
Zealot

Joined: Tue Nov 27, 2007 7:03 am
Posts: 1325
Reply with quote
Post 
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?


Mon Dec 31, 2007 12:58 pm
Profile
Hazed

Joined: Mon Dec 24, 2007 2:03 am
Posts: 51
Location: Russia
Reply with quote
Post 
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:?

_________________
quake2xp audio engineer


Mon Dec 31, 2007 3:17 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
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.


Mon Dec 31, 2007 6:45 pm
Profile
-Burninated-
User avatar

Joined: Mon Sep 10, 2007 11:33 pm
Posts: 871
Location: Unspecified
Reply with quote
Post 
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!

_________________
俺はテメエの倒す男だ! 宜しく! お前はもう死んでいる...


Mon Dec 31, 2007 10:07 pm
Profile
Lurker

Joined: Mon Jul 02, 2007 9:10 pm
Posts: 152
Location: Virginia
Reply with quote
Post 
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.


Tue Jan 01, 2008 12:08 am
Profile YIM WWW
Locksmith of Hyrule
User avatar

Joined: Sun Aug 08, 2004 7:49 am
Posts: 3634
Location: 255.255.255.255
Reply with quote
Post 
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?

_________________
Image
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.


Wed Jan 02, 2008 12:17 pm
Profile YIM WWW
Official tech support dood

Joined: Wed Jan 25, 2006 7:57 am
Posts: 2086
Reply with quote
Post 
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.


Wed Jan 02, 2008 2:11 pm
Profile
Locksmith of Hyrule
User avatar

Joined: Sun Aug 08, 2004 7:49 am
Posts: 3634
Location: 255.255.255.255
Reply with quote
Post 
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?

_________________
Image
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.


Thu Jan 03, 2008 10:09 pm
Profile YIM WWW
Reply with quote
Post 
Quote:
..you mean there's REALLY a TCPM chip in the mac hardware?


Yes, there absolutely is.

Quote:
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.


Thu Jan 03, 2008 10:23 pm
Display posts from previous:  Sort by  
Reply to topic   [ 120 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.