I was Wondering when there will be a new Build Release

Anything DreamSNES-related can be asked in this forum, such as general questions about the emulator, how to burn it, etc.
Ex-Cyber
DCEmu User with No Life
DCEmu User with No Life
Posts: 3641
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Sat Feb 16, 2002 1:55 pm
Has thanked: 0
Been thanked: 0

Re: I was Wondering when there will be a new Build Release

Post by Ex-Cyber »

Stryfe wrote:I don' think it's just as simple as the processing power, special effects, capabilities difference that makes it impossible. It's the dissimilarity between the types of hardware. The playstations hardware would be more similar to the DC's hardware, no matter how different, then the SNES's compared to the DC.
That probably explains some of it. A framebuffer-based GPU doesn't generally do much to help you emulate a scanline/tile-based VDP/PPU-type processor (aside from things like scaling/filtering the rendered frame).
Stryfe wrote:There's also the fact that Bleemcast! was actually more of an interpreter, vs DreamSNES or the like being emulators.
That doesn't make any sense. An interpreter is generally a type of CPU emulator, one that AFAIK was avoided by Bleemcast for performance reasons.
"You know, I have a great, wonderful, really original method of teaching antitrust law, and it kept 80 percent of the students awake. They learned things. It was fabulous." -- Justice Stephen Breyer
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7497
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has thanked: 4 times
Been thanked: 9 times
Contact:

Re: I was Wondering when there will be a new Build Release

Post by Quzar »

Christuserloeser wrote:
Stryfe wrote:There's also the fact that Bleemcast! was actually more of an interpreter, vs DreamSNES or the like being emulators.
I never understood the difference...
An emulator (in strict terms) is designed to function exactly as the original hardware did. Each register, memory flush, and DMA timing is emulated in order to be able to recreate hardware in software. Think MAME, where the goal is more to document hardware than just to play games. Many emulators will take shortcuts in terms of speed, but typically work from the 'recreate hardware to be able to run it's software' approach.

An interpreter (which I would disagree that bleemcast is without first seeing the internals) looks at the code of the software (the game) and only tries to mimic the results. Instead of looking inside of a console to what makes things happen, it will treat the console as a black box and will simply do whatever will get the same input to give the same output as would on an original console. This is most applied to situations where a scripting engine was used, as those already disregard the hardware they run on (think SCUMMVM, Sarien, or Zork interpreters). The same kind of ideas can be applied to general software, and is seen to a large degree in N64 emulators. The N64 used various 'microcodes' to drive it's video chip, with the game sending higher-level information in micro code instructions. As such (at least last time I checked) no N64 emulator actually contains much documentation about the system's video chip but only about the micro codes that drive it. This is what 'HLE' refers to 'High Level Emulation', the extreme end of which would be an interpreter (which goes so far away from hardware that it simply tries to run the software).

Again: "Emulator:Hardware :: Interpreter:Software"
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has thanked: 0
Been thanked: 2 times

Re: I was Wondering when there will be a new Build Release

Post by Chilly Willy »

I think some folks are getting confused because you used "interpreter" for the entire emulation. Emulators use interpreters for different aspects of the emulation. The most common place is the CPU - you look at the machine code for the CPU in the emulated system and interpret it into what the results would be using the CPU in the system you are using. You look at stores to emulated hardware and interpret them into what the results would be using the CPU and IO of your system. You look at a call to the BIOS of the machine being emulated and interpret it into what the results of the call would be. The first two examples are low-level interpreters, while the last is a high-level interpreter. Any part of a machine being emulated that results in a change to the system needs to be interpreted. The higher level the interpretation, the faster the emulator will be, but the less compatible it COULD be.

Dynamic Recompilation of the emulated CPU code is still interpretation - the code is just interpreted ONCE and then that code is remembered (by placing it in a buffer somewhere) for the next time it is called (or the buffer gets flushed). The advantage of DR is that 1) you don't need to interpret the code every time it's called, and 2) you can look at more instructions at once to determine if shortcuts can be applied to the interpretation to make it faster (for example, check to see if processor flags don't need to be computed/checked).
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7497
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has thanked: 4 times
Been thanked: 9 times
Contact:

Re: I was Wondering when there will be a new Build Release

Post by Quzar »

Chilly Willy wrote:I think some folks are getting confused because you used "interpreter" for the entire emulation. Emulators use interpreters for different aspects of the emulation. The most common place is the CPU - you look at the machine code for the CPU in the emulated system and interpret it into what the results would be using the CPU in the system you are using. You look at stores to emulated hardware and interpret them into what the results would be using the CPU and IO of your system. You look at a call to the BIOS of the machine being emulated and interpret it into what the results of the call would be. The first two examples are low-level interpreters, while the last is a high-level interpreter. Any part of a machine being emulated that results in a change to the system needs to be interpreted. The higher level the interpretation, the faster the emulator will be, but the less compatible it COULD be.

Dynamic Recompilation of the emulated CPU code is still interpretation - the code is just interpreted ONCE and then that code is remembered (by placing it in a buffer somewhere) for the next time it is called (or the buffer gets flushed). The advantage of DR is that 1) you don't need to interpret the code every time it's called, and 2) you can look at more instructions at once to determine if shortcuts can be applied to the interpretation to make it faster (for example, check to see if processor flags don't need to be computed/checked).
You're talking about an interpreting CPU core. I'm talking about a script 'interpreter' ala SCUMMVM. I assumed that's what the OP was referring to when he said that bleemcast was more akin to an interpreter than DSNES is.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Re: I was Wondering when there will be a new Build Release

Post by BlackAura »

A framebuffer-based GPU doesn't generally do much to help you emulate a scanline/tile-based VDP/PPU-type processor (aside from things like scaling/filtering the rendered frame).
Aside from using it as a simple blitter, no. It's no help at all. Genesis Plus uses the Dreamcast's 3D hardware as a blitter, and it's very fast. However, since it can only draw whole tiles, and there's no way to map the Megadrive's VDP effects to the PVR's drawing operations, there are lots of things that it just can't do.

The SNES PPU is far more complex that the MD's VDP, and a larger proportion of the available games use the extra effects or drawing modes. In principle, you could use the DC's PVR as a blitter in a SNES emulator, but compatibility would be far worse than it would be for a Megadrive emulator.
You're talking about an interpreting CPU core. I'm talking about a script 'interpreter' ala SCUMMVM. I assumed that's what the OP was referring to when he said that bleemcast was more akin to an interpreter than DSNES is.
Not really. Bleemcast is a proper PlayStation emulator. It just does a lot of things differently. I would assume that it uses some kind of dynamic recompilation scheme (there's no other way to reasonably emulate a 33MHz MIPS on a 200MHz SH-4), uses the PVR for rendering, and the DC's sound system for sound playback.

While it's true that the PlayStation and Dreamcast are more similar, and that should allow a number of shortcuts (like being able to offload rendering and sound playback to the hardware) which aren't possible for a SNES emulator, the PlayStation is also a hell of a lot faster than a SNES, and has many more pieces that would need to be emulated.

It's not like the N64 either. The N64 had a complex 3D system, which had something that's more-or-less equivalent to modern day vertex shaders (RSP microcode). However, Nintendo provided a standard set of libraries to interface with all of the hardware, and initially forbade developers from hitting the hardware directly. Developers were especially forbidden from messing around with the RSP microcode. Early N64 emulators didn't even attempt to emulate much beyond the CPU. Instead, they located Nintendo's standard library, and replaced it with native implementations of the same functionality.

On the PlayStation, Sony provided a development kit, but it was kind of useless, so almost everybody skipped it and hit the hardware directly. There's no standard library to intercept, so a PlayStation emulator has to emulate most of the system's hardware as well.
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7497
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has thanked: 4 times
Been thanked: 9 times
Contact:

Re: I was Wondering when there will be a new Build Release

Post by Quzar »

BlackAura wrote:
You're talking about an interpreting CPU core. I'm talking about a script 'interpreter' ala SCUMMVM. I assumed that's what the OP was referring to when he said that bleemcast was more akin to an interpreter than DSNES is.
Not really. Bleemcast is a proper PlayStation emulator. It just does a lot of things differently. I would assume that it uses some kind of dynamic recompilation scheme (there's no other way to reasonably emulate a 33MHz MIPS on a 200MHz SH-4), uses the PVR for rendering, and the DC's sound system for sound playback.
I'm aware of this. I didn't mean to say that the OP was correct in saying that bleemcast was an 'interpreter', but if he was only familiar with those two terms, he was close as you could almost put a script interpreter and a pure hardware emulator on opposite ends of a scale. If so then bleemcast, using dynarec and (we assume) an amount of HLE would fall closer to the interpreter side than DSNES would.

Obviously bleemcast wasn't an interpreter though (in any sense).
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
Stryfe
Psychotic DCEmu
Psychotic DCEmu
Posts: 577
Joined: Mon Aug 11, 2008 9:34 am
Location: Nowhere U.S.A.
Has thanked: 0
Been thanked: 0

Re: I was Wondering when there will be a new Build Release

Post by Stryfe »

Okay I guess I was dead wrong about the interpreter part then. I haven't looked at the technicals of Bleemcast, and I'm not sure about the legalities of those who claimed to have.

I based my conclusion off of reading forum posts by people who were discussing the technicals of bleemcast. Maybe even a thread or two from here.

But at the end of the day even if the DC can emulate the SNES fullspeed with a minimum of frameskip/compatibility issues, there are no coders interested in doing it. Again it comes back down to no future build releases, and most likely no alternative SNES projects either.

Homebrew scenes have all sorts of stuff to play with, like the DS, Xbox 360, Wii, etc...

I think the bigger emulation projects have moved on to other systems.
ImageImageImageImage
BlackAura
DC Developer
DC Developer
Posts: 9951
Joined: Sun Dec 30, 2001 9:02 am
Has thanked: 0
Been thanked: 1 time

Re: I was Wondering when there will be a new Build Release

Post by BlackAura »

I think it's a balance between the amount of effort required to make a good emulator, expectations about what a good emulator actually is, and how desirable the end result is.

PC emulators from the days when PCs had CPUs as powerful as the Dreamcast's weren't actually that good. In the early days of SNES emulation, basically nothing worked, and what did work tended to be buggy, slow and inaccurate. And silent, more often than not. Same goes for Genesis emulation.

SNES emulation didn't become viable until you got CPUs around the 150MHz mark, and a 166MHz Pentium is faster in some respects than the Dreamcast's SH-4. Doing it well (reasonable accuracy, speed, and sound) requires something more like a 233MHz Pentium 2. And that's for ZSNES - an emulator written from scratch, in assembly, with speed as it's highest priority, over the course of several years. Snes9x (written in C, with portability in mind) requires more like 500MHz to work well, and bsnes (more recent, cycle-exact emulator, written with absolute accuracy in mind) requires something more like 2GHz.

The problem is that DreamSNES wouldn't be compared with old versions of ZSNES, Snes9x, and so on running on old PC hardware. They'd be compared with current versions of ZSNES, Snes9x or bsnes, running on CPUs that are easily ten or twenty times as fast as the Dreamcast's. So it has to be not only very fast, but also very accurate.

There's also the comparison to other platforms. Many other platforms can run easily portable emulators (Snes9x, for example) at pretty much full speed with almost no problems. Those platforms also have many more users than the Dreamcast, and you can deliver a much better experience on those platforms with much less effort.

And there's the problem. You can spend months picking away at the thing, and eventually release something. A tiny number of people will get to see it. Of that tiny number, the majority will compare it with emulators on more powerful platforms, and decide that it sucks. That knocks out one major motivating force.

Since nobody really needs a Dreamcast for emulation anymore, the end result isn't even that desirable anymore. The only real reason to keep going on an emulator project is for self interest (the "I enjoy working on this because it's hard" motivation). I'm fairly sure that's why Gens4all is still going, for example.

I think cross-platform stuff is probably more interesting at this stage. With something that's cross-platform, you can get more user interest, perhaps some more contributors working on it, that kind of thing. That pretty much excludes emulation though, since cross-platform stuff isn't going to be fast enough to emulate anything that's not already been done on a Dreamcast.

So, homebrew games, basically.
Post Reply