Seems like I missed this news from yesterday.

The ZX Spectrum 128 / ZX Spectrum 48 emulator EmuZGL has been updated.

»» http://zx.pk.ru/showthread.php?t=7527 [Release Thread]

Thanks to our affiliate, AEP-Emulation, for the news!

Yeah it felt a little strange to debug a program in dos in 2008... I had to use dosemu for that, but it worked rather well. It won't be useful for many people, I think it should be useful to only 1 person actually...

 

Anyway bad news first, there are some bugs inside. Normaly the only major bug is the emudx support which is completely broken in this version. It's because the dx2 files are intended for sdl, and it would be a big trouble to add support for these files in allegro. So the easiest solution is to use 0.42.4 in dos for emudx !

 

Except that compared to 0.42.4 :

- about 30 more games

- obviously the infamous allegro bug which made the 0.43 versions unusable is fixed

- fixed a few memory issues too, it should be much better in low memory situations, and should not write a crash dump anymore when you quit !

- Compiled with gcc 4.2.2 (when 0.42.4 had been compiled with 3.2.2 !!!), so it should be a little better.

- has the numerous fixes included since 0.42.4, it's exactly the same code as 0.50.13 except for the part specific to allegro.

 

The archive is much bigger, because the exe contains useless stuff like hq2x/hq3x which can't be enabled from the gui, but I didn't bother to remove it from the link neither. I'll update the source later.

There won't be a neoraine for dos though, it wouldn't be able to read mp3 tracks, which would make it much less interesting.

>> Get it HERE.

Now, on a personal note, this is my last regular newspost at 1emulation, as I'm taking a well-earned break after 3 years. Don't worry, 1emulation will continue posting the newest news!

[This thread is constantly updated throughout the week with the latest related releases for the newest version of MAME!]

EMULATORS

=========

MAMEUIFX32 0.125u4 released

MameUI64 .125.4, 64bit version for 64bit Windows OSes [XP64, Vista64]

MameUI32 .125.4, 32bit version for 32bit Windows OSes [Win98/ME/2000/XP/Vista]

MameUI Source code

SDLMAME 0.125u4 released

MAME Plus! 0.125u4

SDLMAME for OS X Universal Binaries

MAME Plus! 0.125u4a

Mame Plus Multi J.E.T. v0.125u4a

MameUI64 .125.4.1, 64bit version for 64bit Windows OSes [XP64, Vista64]

MameUI32 .125.4.1, 32bit version for 32bit Windows OSes [Win98/ME/2000/XP/Vista]

MAMEXT32 0.125u4

MAMEXT32 0.125u4 (All in One)

MAME Plus! XT 0.125u4

MAME Plus! XT 0.125u4 (All In One)

AgeMAME 0.125u4

SDLMAME 0.125u4 (Ubuntu)

LogiqX

=======

MAME v0.125

MAME SuperSet v0.125

MAME SuperSet (Fully-merged MAME Supplement) v0.125

MAME SuperSet (Split-merged MAME Supplement) v0.125

Various Emulators (Fully-merged SuperSet Supplements) v0.125

Various Emulators (Split-merged SuperSet Supplements) v0.125

MAMEScore

==========

Story.dat / mamescore.ini / default.el

DATS

====

MAMEINFO.DAT 0.125u4

CLRMAME PRO DAT (CM): 0.125u4 (MAMEXT32 0.125u4)

EXTRA

=====

MAME32 0.125u4 Category-, Version and Alltime inifiles

Catlist 0.125u4 (cat32, deluxe32, catver.ini, genrev)

MAME32 Plus! 0.125u4a Japanese Game List

NOTES

=====

Updated to MAME 0.125u4 - MAMEUI 0.125u4

Added option to the core and the GUI to enable/disable hiscore.dat support.

 

NOTE: Cheat core is reverted back to 0.125 code because the new code doesn't work at all with official cheat database.

Updated to MAME 0.125u4. Added 0.125u4 Source/Listinfo changes. Newest Bugs (6th Jun). Added RAINE 0.50.13 infos. Fixed Mameinfo.dat infos (Version 0.124u1-u5).

updated Simplified Chinese list (0125u4_0606) [kof2112]

added CPS2 Phoenix Edition: sgemfd [kof2112]

[MAME] sync with 0.125u4 [Emuman]

[MESS] sync with 0.125u4 svn r2822 [Emuman]

added CPS2 Phoenix Edition: ssf2tbd,ssf2xjd [kof2112]

removed MESS menu bar, now it's only used for launching console games [Emuman]

fixed resolution switching [Emuman]

fixed full screen mode on second monitor [Emuman]

updated Japanese list (jplist0125u3_0531.zip) [mamelist jp]

Games added:

 

NEOGEO

The King of Fighters '98 (Boss hack like NGCD v1.2 (KOF hackteamwork))

The King of Fighters '98 (NBC eight gods version)

The King of Fighters '98 (XI Flash version)

The King of Fighters '99 (Boss hack like DC v1.2f (KOF hackteamwork))

The King of Fighters '99 (Evolution special)

 

CPS1

Cadillacs and Dinosaurs (Hack by Pipi899)

 

CPS2

Street Fighter Alpha 3 (Revision hack by Dodowang (ECGC))

Street Fighter Zero 3 (Boss hack by Yumeji)

Street Fighter Zero 3 (Hack by Pipi899)

Super Street Fighter 2 Turbo (French by NEOARC Traduction) work now

Super Street Fighter 2 Turbo (French parody Cigarette Patch) work now

Super Street Fighter 2 X (Gouki edition hack by Yumeji)

Super Street Fighter 2 X (Original Color FGCH hack) work now

Vampire: The Night Warriors (Boss hack by Yumeji) work now

X-Men: Children of the Atom (Boss hack by Yumeji) work now

 

SNES

Super Mario World (Big island adventure demo)

Super Mario World (Bowser's forest)

Super Mario World (Darkness approaches v1.0 demo)

Super Mario World (Great quest v1.0)

Super Mario World (Luigi's adventure v0.2 demo)

Super Mario World (Luigi's adventure v0.27 demo)

Super Mario World (Mario and Luigi: the last straw)

Super Mario World (Time travel crisis v1.0)

Super Mario World (Toad town stories v0.52)

 

GENESIS

Sonic The Hedgehog (Oergomized v0.5)

Sonic The Hedgehog (Oergomized v0.5f)

Sonic The Hedgehog (Oergomized v0.7)

Sonic The Hedgehog (Oergomized v0.

Sonic The Hedgehog (Oergomized v0.8c)

Sonic The Hedgehog (Oergomized v1.1)

Sonic The Hedgehog (Oergomized v2.0 mbu)

Sonic The Hedgehog (Oergomized v2.0 pre beta)

All the new games from mainline MAME (including some H8 CPU ones, which is the same CPU series as EPOCH).

 

There's also a start on some IMPACT improvements, based on something I was sent by Dialtone.

- ######## LATEST EMULATION NEWS WILL APPEAR BELOW ######## -

Makaron, a dreamcast emulator, had a WIP (work in progress) update today.

I've finally completed the new GD-ROM module, though ultimately it turned out to be very similar in design to the last one. With the new code I can freely choose what ATA/ATAPI commands are to be executed immediately and what can be offloaded to helper thread.

Unfortunately a thread is not a very good substitute for a real-time device. In typical multitasking OS there's a sheduler that decides when things will happen, there's no guarantee that the helper will start processing given request right away. Simply put, it can start immediately or only after some tens of miliseconds has passed. I could run the code in a tight loop to reduce this lag but that would waste too much CPU power, always needed elsewhere. Not to mention OS can (and eventually will at some point) interrupt any running process if it's required, so this approach would not solve the problem completly, just reduce the odds of ecountering it. Same thing goes for messing with thread priorities - that's not exactly foolproof and is also very inelegant.

 

Now, why would mere miliseconds ever pose a problem? In a well-designed system the consumer would just wait a bit for the producer to come up with data and occasional lag wouldn't even be noticable. Some Dreamcast software however (BIOS including) doesn't really check if the data has arrived, rather assume it must be so after a certain amount of time has passed.

This isn't that much of a problem for GD-ROM commands that return small amounts of redily available data - those can be simply executed at the moment they arrive, so there is no lag. Disk reads are another story though, those take time to complete and the whole idea was to run them concurrently so that virtual CPU would not be stalled waiting in the first place.

 

It gets more interesting at this point. A real Dreamcast GD is not anywhere near as fast as modern hard drives, so why doesn't it work in emulator if it works on an inferior system? The answer, again, is timing. It's simply very crucial to get it right - and you can have accurate emulator, or fast emulator, but not both. And you've guessed it right, I'm aiming for fast at this point. It has to be noted that should the original GD/CD media become too scratched or the laser detoriates beyond certain point, the problems I'm having will manifest themselves on Dreamcast as well - so I still say it's simply bad coding on games part.

What are the options... For starters, I will continue to play with the DMA code and try to mimic Dreamcast behaviour as closely as possible. And if all else fails, there's still the "ideal" DMA mode, that is to make transfers always block to be sure the virtual CPU always gets all the data it asks for. This of course causes jerkiness and audio stuttering, mostly to be felt in games using sequenced music or sound effects very closely timed to video.

 

This whole re-write took quite some time and didn't really help as much I hoped, but thanks to all that work I'm now much more aware of what has to be done yet. I've a few ideas, it's just that every attempt at fixing one thing breaks other stuff. Sometimes very badly I still need to figure out what upsets so much the MPEG library used on demo GDs and some MIL-CDs.

 

PS. Why didn't anyone tell me Giana's Return got broken with the addition of MMU-capable recompiler?!

PPS. I'm SOOO behing with testing Yuki's stuff now... I'm going to capture & post few screenshots later today. If I get the games to work with the new GD code that is

 

UPDATE:

No screens yet. I had a bug that prevented most of the images from booting properly, that's fixed now. But there's a bigger problem - the new module is actually even less compatible, timing-wise, than the old one. I'll have to run more tests but now I'm beginning to suspect that some games require GD DMA processing to be done way more often. Which is bad because it seriously affects emulation speed.

At this point one begins to wonder what exactly is good about this new code Well, it is more reliable now. I was hoping that alone would be enough but apparently I was too optimistic...

 

UPDATE 2:

A bit closer, still not there.

 

 

This is starting to seriously annoy me. DMA changes helped with some tiles but not all of them. Then I inserted a few debug statements into the code and even though it reduced emulation speed, it actually made things more stable. And this is the only lead I have so far...

»» http://dknute.livejournal.com/ [Makaron WIP Release Blog]

Thanks to EmulationHQ for the news!