SMS+SDL\DC 0.1

[emptythought]

This is a very quick port of SMS+SDL 7.1 by Gregory Montoir which was based on 0.9.4a of SMS Plus by Charles Mac Donald.

Put your .sms and .gg ROMs in /roms and burn.

The menu is a bit ugly, and not nearly as good as I'd like. There's currently no way to get back to the menu when you play a ROM - this was just a test port and I'll most likely not work on it anymore.

The ROM list code was taken from BlueCrab's SMS\GG\SG-1000 emulator, CrabEmu so all credits goes to him for that.

Downloads:
http://dchelp.dcemulation.org/downloads ... 01_bin.zip
http://dchelp.dcemulation.org/downloads ... 01_src.zip

[Christuserloeser]

I'm impressed. Runs nearly full speed with sound, FM emulation doesn't seem to work tho...

this was just a test port and I'll most likely not work on it anymore.

Too bad.

- Are you taking requests ? Nester related requests ?

[emptythought]

I'm impressed. Runs nearly full speed with sound, FM emulation doesn't seem to work tho...

Try changing Overseas to Domestic and enabling FM sound.

Too bad.

- Are you taking requests ? Nester related requests ?

I'll clean up the menu and add a way to get back to the menu if you really want it, CrabEmu is going to be better by far so there's probably no reason to look into updating it anymore.

[Christuserloeser]

Try changing Overseas to Domestic and enabling FM sound.

I think I tried that but it doesn't work. Will try again.

I'll clean up the menu and add a way to get back to the menu if you really want it, CrabEmu is going to be better by far so there's probably no reason to look into updating it anymore.

It wouldn't hurt to be able to get back to the menu, but yeah, I'm really looking forward to the next version of CrabEmu.

- Are you taking requests ? NesterDC related requests ?

[emptythought]

Try changing Overseas to Domestic and enabling FM sound.

I think I tried that but it doesn't work. Will try again.

Sorry then, I don't know what could be going wrong. It could possibly be a bug in the version of SMS Plus because I have it enabled correctly. I don't even know what games use FM sound or what sounds to listen to.

- Are you taking requests ? NesterDC related requests ?

I am looking to get more into emulators. What kind of requests do you mean?

[BlueCrab]

I'll clean up the menu and add a way to get back to the menu if you really want it, CrabEmu is going to be better by far so there's probably no reason to look into updating it anymore.

It wouldn't hurt to be able to get back to the menu, but yeah, I'm really looking forward to the next version of CrabEmu.

Its good to know that people have more trust in my programming ability than I do. Probably the only thing that CrabEmu supports that this SMSPlus doesn't in any form is the EEPROM used in the few random baseball games. SMSPlus has other things that CrabEmu doesn't, the largest of which being FM emulation (not to mention being significantly faster).

I don't wanna hijack anyone's topic, so that's about all I'm gonna say here...

[Christuserloeser]

I don't even know what games use FM sound or what sounds to listen to.

The difference is huuuge.

One could buy it as an add-on for the Mark III and the Japanese Master System has the FM chip built-in, so many Japanese games do support it.

Released in Japan featuring FM sound:

After Burner
Alex Kidd: The Lost Stars
Alien Syndrome
Aztec Adventure
Blade Eagle 3-D
Bomber Raid
Captain Silver
Cyborg Hunter
Double Dragon
Fantasy Zone II
Fantasy Zone: The Maze
Global Defense
Golvellius - Valley of Doom
Great Golf
Kenseiden
Lord of The Sword
Maze Hunter 3-D
Miracle Warriors - Seal of The Dark Lord
Out Run
Parlour Games
Penguin Land
Power Strike (Aleste)
R-Type
Shinobi
Space Harrier 3-D
SpellCaster
Thunder Blade
Wonder Boy in Monster Land
Zaxxon 3-D
Zillion II - The Tri Formation

Never released in Japan, but these still do feature FM sound:

Altered Beast
California Games
Casino Games
Cloud Master
Galaxy Force
Game Box Série Esportes Radicais (BR)
Golfamania
Mônica no Castelo do Dragão (BR)
Out Run 3-D
Poseidon Wars 3-D
Rampage
Rastan
Rescue Mission
Scramble Spirits
Shanghai
Tennis Ace
Time Soldiers
Turma da Mônica em: O Resgate (BR)
Ultima IV
Vigilante
Wonder Boy III: The Dragon's Trap

Source: http://www.smspower.org/forums/viewtopic.php?t=8714



- Btw, I just noticed that MEKA is open source now: http://www.smspower.org/meka/download.shtml

MEKA was mostly programmed by me, in C language, with few parts in x86
assembly. It is being hand optimized since a long time, but some things
still aren't very fast.

[...]

Otherwise, MEKA's fairly accurate emulation may be a reason why it is slower
than some older emulators. Eg: Graphic refresh, palette and collision
detection are all handled on a scanline-by-scanline basis. Of course it
includes other features not helping to make emulation faster, either.

I am looking to get more into emulators. What kind of requests do you mean?

viewtopic.php?p=992639#p992639 - Basically updating Nester DC SE with the GUI from v7.x. That would fix all of the problems that people have with SE:

• no support for hacks + translations + prototypes + homebrew (or any games that aren't recognized by the version of GoodNES used)
• CD Builder depending on Windows 32 (no Mac or GNU/Linux support at all and not compatible with the most recent Windows versions)
• potentially damaging your GD-ROM drive due to frequent reading from disc (see az_bont's post in above link)

[Christuserloeser]

Its good to know that people have more trust in my programming ability than I do. Probably the only thing that CrabEmu supports that this SMSPlus doesn't in any form is the EEPROM used in the few random baseball games. SMSPlus has other things that CrabEmu doesn't, the largest of which being FM emulation (not to mention being significantly faster).

Well, CrabEmu has a very nice GUI - That is something!

Regarding the speed: I am really surprised that it's that fast. I mean isn't SDL dependency something that would usually cause a port to be slower than releases that avoid using SDL ?

I don't wanna hijack anyone's topic, so that's about all I'm gonna say here...

Since we're talking about SMS/8-bit emulation I don't think it's really OT to talk about CrabEmu.


Btw, what about updating SMSplusDC ? I have uploaded a source code collection to DCEvo's FTP a while back:

viewtopic.php?f=34&t=85547 (scroll down a bit)

Among other stuff, there's is a .elf file included that Heliophobe sent me to demonstrate his custom FM renderer (optimized for speed).

I am looking to get more into emulators.

I am glad to hear that. There are so many old emulators for Z80 based systems that could be updated with FAZE, e.g. DCGNUboy, and of course SMSplusDC

[Quzar]

viewtopic.php?p=992639#p992639 - Basically updating Nester DC SE with the GUI from v7.x. That would fix all of the problems that people have with SE:

• no support for hacks + translations + prototypes + homebrew (or any games that aren't recognized by the version of GoodNES used)
• CD Builder depending on Windows 32 (no Mac or GNU/Linux support at all and not compatible with the most recent Windows versions)
• potentially damaging your GD-ROM drive due to frequent reading from disc (see az_bont's post in above link)

It would also remove the biggest feature of NesterDC SE.

The killing the GD-ROM drive is a myth. People have been saying the same crap about all CDs on the DC since the start of these forums. Early on it was rampant just because of the large defect rate and people who couldn't understand how to burn a CD (just like how everyone thinks they have one of those magical non-MIL-CD compatible DCs). I had a DC GD drive stop on me while playing Rez (off a whitelabel), does that mean that whitelabels are bad for the drive? Of course not.

At this point, looking at a 10 year old CD drive the wrong way should make it stop working, especially when you're using a program that many people dug their DCs out of cold storage to use.

FAZE would not yet benefit any of these. In order to properly emulate the SMS, you need scanline-level emulation, which means a cycle accurate cpu core. Not to defame faze in any way, but unless it fixed problems already in raze on top of just copying it well, it won't yet cut it. As it is, SMSPlus isn't all that optimized, but what it is is written for kos 1.2.0. I tried working with it a while back, and although at first it upported easily, but after a few kos and gcc updates, it simply stopped. I think that it had to do with the fact that it uses streaming sound (which I've never had luck with for anything but sfx), but couldn't prove it.

<rambles on about pointless things>

[Christuserloeser]

The killing the GD-ROM drive is a myth. People have been saying the same crap about all CDs on the DC since the start of these forums. [...]

At this point, looking at a 10 year old CD drive the wrong way should make it stop working, especially when you're using a program that many people dug their DCs out of cold storage to use.

All of what you're saying is true. Personally I think that any usage of your DC will eventually lead to it not recognizing a CD/GD anymore (not sure what's first). My brother bought his DC right when it came out, and never ever used a single CD-R / MIL-CD and yet it stopped reading GDs after a year or two. The manufacturing quality of the Dreamcast isn't exactly the best. The hardware itself was and is a real beast, but I guess they had to make cuts somewhere.

Now regarding NesterDC SE: from what I remember it really puts your Dreamcast's GD-ROM drive to work. Booting the thing up and loading the GUI takes quite a while. The sound the drive makes when browsing through the library isn't exactly pleasant. I can really understand that people get nervous because of that.

Funny enough that the v7.x releases had the exact opposite problems: The GUI introduced in v7.0, while miles away from that of SE, works and looks significantly better than that of v6.0, but v7.x suffers from serious problems in terms of compatibility - even when compared to v6.0.

I really wish Scherzo would update SE with an OpenBoR-like PAK file system that holds the goodies, and a builder that would allow to manually add games, screenshots and nsfs (instead of skipping those not in the database) and wouldn't rename them to numbers. But it didn't sound like he would be very interested in putting any more work into it. - I can understand that, but it also means it probably wouldn't be a bad idea for anyone interested in updating the emulator to just kick out the GUI and allow free browsing again, as that would get rid of the problems most people have with this otherwise perfect emulator.

Of course a proper update of the GUI would do Scherzo's hard work more justice, but I am not sure if it's that easy. If I remember correctly everyone could edit the GUI to a degree due to it using DreamScript. I only took a quick look at it when it's been released, but I was completely overwhelmed by the complexity of both the language and the structure. I thought maybe someone with a bit more patience than me would be more successful and I know there were people that played around with it, but until now no one seems to have achieved something.

FAZE would not yet benefit any of these. In order to properly emulate the SMS, you need scanline-level emulation, which means a cycle accurate cpu core. Not to defame faze in any way, but unless it fixed problems already in raze on top of just copying it well, it won't yet cut it.

FAZE did a fairly good job in speeding up vbt's SMSplus for Saturn. It's almost exactly as fast as SMS+SDL/DC. It probably uses a hardware VDP renderer and a highly optimized PSG core I assume, but when it's been using CZ80 it was slower (and less compatible).

http://www.dcemu.co.uk/vbulletin/showthread.php?t=79905

This new release uses the famous and incredible Faze by Fox68k. Some games like Sonic run 30% faster than before.

So, have a look at it but be aware that the Faze port to the Saturn may not be completely finished. Well, the compatibility is quite high.

As it is, SMSPlus isn't all that optimized, but what it is is written for kos 1.2.0. I tried working with it a while back, and although at first it upported easily, but after a few kos and gcc updates, it simply stopped. I think that it had to do with the fact that it uses streaming sound (which I've never had luck with for anything but sfx), but couldn't prove it.

Interesting. - Did you ever release the source ? Maybe someone else can help ?

[BlueCrab]

Its good to know that people have more trust in my programming ability than I do. Probably the only thing that CrabEmu supports that this SMSPlus doesn't in any form is the EEPROM used in the few random baseball games. SMSPlus has other things that CrabEmu doesn't, the largest of which being FM emulation (not to mention being significantly faster).

Well, CrabEmu has a very nice GUI - That is something!

Regarding the speed: I am really surprised that it's that fast. I mean isn't SDL dependency something that would usually cause a port to be slower than releases that avoid using SDL ?

Heh... The GUI in CrabEmu, other than looking nice (thanks to PSPdemon for that) was pretty much thrown together in less than 20 minutes or so. I put just about no work into it whatsoever.

As for the SDL question, Using SDL would in theory slow down the emulator. Comparing CrabEmu to SMS+SDL for this though is like comparing apples to oranges. CrabEmu is simply slower. When I was writing CrabEmu, I was more worried about accurate emulation than fast emulation. The one place in the code where this really shows is in the VDP emulation. If you ever took a browse through the SMSPlus source code, you'd see a VERY simple renderer. There's very little code there. Its fairly accurate, but at the same time, has had years of optimization. I'm trying to attain the accurate part of that equation, optimized will come later.

I don't wanna hijack anyone's topic, so that's about all I'm gonna say here...

Since we're talking about SMS/8-bit emulation I don't think it's really OT to talk about CrabEmu.

Okie doke, then we can continue. I always hate dragging topics off topic!

I am glad to hear that. There are so many old emulators for Z80 based systems that could be updated with FAZE, e.g. DCGNUboy, and of course SMSplusDC

Remember though, with DCGNUboy, there's going to have to be some changes made to FAZE internally. The "Z80" in the original Game Boy and GBC was more like an extended 8080 than a reduced Z80. Both processor architectures are similar, but Z80 does a lot more than the 8080.

[Quzar]

FAZE would not yet benefit any of these. In order to properly emulate the SMS, you need scanline-level emulation, which means a cycle accurate cpu core. Not to defame faze in any way, but unless it fixed problems already in raze on top of just copying it well, it won't yet cut it.

FAZE did a fairly good job in speeding up vbt's SMSplus for Saturn. It's almost exactly as fast as SMS+SDL/DC. It probably uses a hardware VDP renderer and a highly optimized PSG core I assume, but when it's been using CZ80 it was slower (and less compatible).

The keywords there are assume and probably. The Saturn is a much slower system. Try out the compatability of vbt's SMSPlus vs the DC's. I got CZ80 running in smsplusdc and it broke a LOT, simply not accurate enough when doing scanline emulation. The DC is more than capable of doing everything while optimizng other portions.

http://www.dcemu.co.uk/vbulletin/showthread.php?t=79905

This new release uses the famous and incredible Faze by Fox68k. Some games like Sonic run 30% faster than before.

So, have a look at it but be aware that the Faze port to the Saturn may not be completely finished. Well, the compatibility is quite high.

As it is, SMSPlus isn't all that optimized, but what it is is written for kos 1.2.0. I tried working with it a while back, and although at first it upported easily, but after a few kos and gcc updates, it simply stopped. I think that it had to do with the fact that it uses streaming sound (which I've never had luck with for anything but sfx), but couldn't prove it.

Interesting. - Did you ever release the source ? Maybe someone else can help ?

It was a one week thing, after I first got it running, I tried the next month, but had updated my setup and could never get it running again. I had talked to pascal about it during the time via his site.

All I know is what I've read from the raze and faze documentation. Just like fame, it's no magic bullet.

[Christuserloeser]

Heh... The GUI in CrabEmu, other than looking nice (thanks to PSPdemon for that) was pretty much thrown together in less than 20 minutes or so. I put just about no work into it whatsoever.

See, little work for you, magic for me

I always hate dragging topics off topic!

I usually don't feel great about it too, but it doesn't get us anywhere not to talk. Plus I think that we're not that far OT at all. If we were to talk about something entirely different, then it'd be something... well, entirely different.

Remember though, with DCGNUboy, there's going to have to be some changes made to FAZE internally. The "Z80" in the original Game Boy and GBC was more like an extended 8080 than a reduced Z80. Both processor architectures are similar, but Z80 does a lot more than the 8080.

I wasn't aware of that. - Regarding the changes that would have to be made: I am sure we can ask Fox and I don't doubt that he will help with updating and implementing it, but I think he's very busy with RL stuff atm.

DCGNUboy is already close to perfect. From what I remember it's main problems aside from the missing .zip support were that you couldn't turn off the bilinear filtering and that it crashed after loading about twenty ROMs (crashed = loading another ROM isn't possible). This probably indicates that the games aren't unloaded from RAM properly or at all. Speed isn't really that much of an issue but it's not actually full speed with certain (GBC) games, so a slight speed boost wouldn't hurt.

[BlackAura]

FAZE would not yet benefit any of these. In order to properly emulate the SMS, you need scanline-level emulation, which means a cycle accurate cpu core.

Emulating an SMS absolutely does not require cycle-accurate emulation.

The level of accuracy required for the video emulation has absolutely nothing to do with how accurate the CPU emulation is. They're two completely things. Rendering the video output once per scanline, instead of once per frame, certainly doesn't require a cycle-accurate CPU emulator.

There are no cycle-accurate SMS emulators. There are a number of SMS emulators with near perfect compatibility though (Meka, for example). They all emulate the CPU for one scanline, then draw a single scanline of video.

RAZE is certainly accurate enough to handle an SMS emulator. Just about every PC SMS emulator from around 6 years ago used it.

[Quzar]

FAZE would not yet benefit any of these. In order to properly emulate the SMS, you need scanline-level emulation, which means a cycle accurate cpu core.

Emulating an SMS absolutely does not require cycle-accurate emulation.

The level of accuracy required for the video emulation has absolutely nothing to do with how accurate the CPU emulation is. They're two completely things. Rendering the video output once per scanline, instead of once per frame, certainly doesn't require a cycle-accurate CPU emulator.

The reason I drew a line between the two is that if you execute cpu cycles in the style cpu_run(700) vs cpu_run(400000) it makes a much larger difference if 4-5 extra cycles get executed per call to cpu_run. AFAIK the less you emulate per run, the more accurate the cpu core needs to be so as to not manifest timing errors.

[BlackAura]

Then you keep track of the number of cycles that were actually executed, and use that to adjust the number of cycles to execute next time. For most CPU emulators, that'd be something like:

Code: Select all

cycles_to_execute += 700;
cycles_actually_executed = cpu_run(cycles_to_execute);
cycles_to_execute -= cycles_actually_executed;

That way, the timing errors don't accumulate, and will generally correct themselves. As far as I know, most emulators already do this. I believe that SMS Plus does, for example.

[Quzar]

Then you keep track of the number of cycles that were actually executed, and use that to adjust the number of cycles to execute next time. For most CPU emulators, that'd be something like:

Code: Select all

cycles_to_execute += 700;
cycles_actually_executed = cpu_run(cycles_to_execute);
cycles_to_execute -= cycles_actually_executed;

That way, the timing errors don't accumulate, and will generally correct themselves. As far as I know, most emulators already do this. I believe that SMS Plus does, for example.

Ah, but that only keeps the average number of cycles fixed, from accumulation errors. What it doesn't solve is if something were to happen in those last few cycles that needed to happen in the next cpu slice/scanline, which is much more likely to happen the smaller the amount you execute.

[BlackAura]

Yes, but that's going to be a maximum of exactly one instruction.

If an interrupt is triggered, the Z80 will finish executing whatever instruction it's executing first, then service the interrupt. So there's no timing problems there. The interrupt might be triggered a couple of cycles late, but there's no way that's going to make any difference to any game.

It is possible that the last instruction might be reading something from the VDP registers, which would be changed at the end of the scanline. In this case, yes, it'll get the wrong value. But this is an SMS, not a SNES or an Atari 2600 - no games require this level of emulation accuracy, and there are no cycle-exact SMS emulators.

On that note, there are no stand-alone cycle-exact Z80 emulators either. A cycle-exact emulator is, by it's nature, inseparable from the emulator for which it was written. Any Z80 core you'll find, from RAZE / FAZE to MAME's Z80, or Meka's, or Marat Fayzullin's, or CZ80, will be instruction-accurate at best.