New project: NEO GEO emulation on the Atari Falcon 030

[Anima]

I've just run it on my Falcon with RGB output, an works exactly the same as on the Youtube video. Great work!

Great.

Uh... thanks for the hint: the demo is RGB/TV only.

Cheers
Sascha

[simonsunnyboy]

Technically a very interesting project, in case of teh keyboard I'll probably wait for a more advanced version.
Will VGA be supported in the future?

[dma]

Ahahah, so some dreams can really come true, amazing.
(remembering old times discussions : "But it's the same main CPU type, so emulation could probably be done, with help from DSP and all...")

Thanks for your work on these things Anima.

[Anima]

Technically a very interesting project, in case of teh keyboard I'll probably wait for a more advanced version.
Will VGA be supported in the future?

Yes, VGA will be supported as well.

Cheers
Sascha

[christos]

As always, great work Anima. Looking forward to you completing this and the mega drive as well.

[dma]

Cool thing is that if you can do Genesis emulation, including the Z80 co-processor, Master System and Game Gear could be easy, especially as those use a YM2149 soundchip type, which is also present on Falcon... (and ST)

Which brings me to my next point... Could Master System and Game Gear emulation be done... on ST(e)?

[AtariZoll]

Am I only one here, who sees some irreal expectations ? Seriously, Z80 emulation on ST ? It is not enough fast for that.

Considering running on Falcon: expect stackframe problems because different CPU. You can not solve it without changing/fixing code of problematic SW. And there are other incompatibilities between CPUs.

[Anima]

Cool thing is that if you can do Genesis emulation, including the Z80 co-processor, Master System and Game Gear could be easy, especially as those use a YM2149 soundchip type, which is also present on Falcon... (and ST)

Please note that the current approach is limited to MC68000 family systems so don't expect to have other CPU architectures emulated as well.

Cheers
Sascha

[dma]

Am I only one here, who sees some irreal expectations ? Seriously, Z80 emulation on ST ? It is not enough fast for that.

OK, thanks for your input on this.

[Anima]

Considering running on Falcon: expect stackframe problems because different CPU. You can not solve it without changing/fixing code of problematic SW. And there are other incompatibilities between CPUs.

"Stackframe modifications" / "self modifying code" / "24 bit addresses with high byte data storage" are indeed potential problems. However, so far it seems to be unlikely that all these tricks are being used by the game ROMs. E.g. "Self modifying code" is not very common when running a program in ROM and having only a limited space of work RAM. In fact, I was referring to "dirty tricks used on the MC68000" in the original post to address this issue.

Except for stack frame issues - do you have some other examples for CPU incompatibilities between the MC68000 and MC68030?

Cheers
Sascha

[Anima]

A short update: I am currently testing other games for incompatibilities.

Please note: due to the sprite memory requirements even the running games won't give you a good experience running on the emulator yet. This is just a test for detecting "dirty tricks" or other problems.

Results so far (potentially playable / attract mode only or freezes later on / freezing):

• Metal Slug
• Neo Bomberman
• Viewpoint
• King of Fighters '94

Cheers
Sascha

[dma]

By the way i came across this thread, confirming AtariZoll statement : http://www.ticalc.org/community/articles/17.html

Well, I WRITE Z80 emulator on TI89. Actually it will emulate ZX Spectrum, popular Europe machine. It is still buggy, but some machine code routines can work. The result is that this 3.5 MHz machine works at about 50% of speed of the original when emulated on 10 MHz TI89. I have great expirience in ZX Spectrum emulators, and
used all possible optimization tricks.

(TI89 is 68000 based)

[AtariZoll]

"24 bit addresses with high byte data storage" - this is what is possible to fix with PMMU. I did it for TT, where it is really necessary. Regular Falcons have 24 bit address bus too, so it should be not problem.
There is another incompatibility between 68000 and 68030, what I named pipeline problem/bug. If self modding code writes ahead to very close RAM loc., inside following 3 instructions, it will execute not properly, since CPU already fetched it, so will execute wrong code/data. This is rarer case than stackframe problem, and of course not possible with code running from/in ROM. Examples: ST games Voyager, Vroom.
I can imagine cases when some parts of code executes in RAM, even if it runs from ROM - there is such in TOS for instance. Why execution in RAM ? It may be faster if code runs in lowest 32KB of address space, + may be self modding (some programmers like it). But chances for pipeline problem with ROM games are indeed pretty low.

[dma]

It seems there are some interesting emulators on 68000 based TI calculators by the way, with available source code, see these:
- TI-83 Plus (Z80) : http://www.ticalc.org/archives/files/fi ... 38820.html http://www.ticalc.org/cgi-bin/zipview?8 ... README.txt
- GameBoy : http://www.ticalc.org/archives/files/fi ... 36950.html

[shoggoth]

I've built Günter Woigks' (KiO) 68k-assembly Z80-core on GAS. It sort of works for a typical spectrum emulator (which is what I've used it for). Let me know if this could be of interest (it should however be noted that my modifications to get it running on GAS were nasty and I never cleaned them up).

[Anima]

I've built Günter Woigks' (KiO) 68k-assembly Z80-core on GAS. It sort of works for a typical spectrum emulator (which is what I've used it for). Let me know if this could be of interest (it should however be noted that my modifications to get it running on GAS were nasty and I never cleaned them up).

Well, that's Interesting. To complete the emulation it's surely necessary to have a good Z80 emulation - at least this will be an option for the accelerated machines so I might get back to you soon.

However, I think that the sound could be emulated in a more simplifyed way on the stock Falcon. Actually, the game logic sends only short commands to the sound system (Z80) via the memory mapped address so basically the functionality is like: "play this song" or "play that sample". TBH I am not really sure if this will work but all you have to do is to replace the command by calling an own sound driver routine which plays atari music and/or samples. Of course this assumes that we have someone who composes all the sounds and samples.

Cheers
Sascha

[dma]

However, I think that the sound could be emulated in a more simplifyed way on the stock Falcon. Actually, the game logic sends only short commands to the sound system (Z80) via the memory mapped address so basically the functionality is like: "play this song" or "play that sample". TBH I am not really sure if this will work but all you have to do is to replace the command by calling an own sound driver routine which plays atari music and/or samples. Of course this assumes that we have someone who composes all the sounds and samples.

For information, sound on Genesis is synthesized, FM type : YM2612

[calimero]

The MMU table is used to reproduce the NEO GEO memory map so that the game code runs in the original place (of course). The NEO GEO specific hardware registers are also mapped appropriately but they are marked as "invalid" MMU descriptors. Accessing those addresses will cause a bus error. So all you wish for is a smart bus error handler which emulates the behaviour of the register functions. To do so it requires the following features:

do you know any other emulator that works in this way?

impressive work!

[dml]

do you know any other emulator that works in this way?
impressive work!

It is really a kind of virtual machine - with emulation of devices - and it's a great way to use the 68030 MMU!

[Anima]

do you know any other emulator that works in this way?

No and I was really surprised that it works out so well.

Cheers
Sascha

[shoggoth]

However, I think that the sound could be emulated in a more simplifyed way on the stock Falcon. Actually, the game logic sends only short commands to the sound system (Z80) via the memory mapped address so basically the functionality is like: "play this song" or "play that sample". TBH I am not really sure if this will work but all you have to do is to replace the command by calling an own sound driver routine which plays atari music and/or samples. Of course this assumes that we have someone who composes all the sounds and samples.

Yup, that's a much better idea. It's better to have a playable emulator than to accurately emulate every single aspect of the original machine. In my SMS+ port (060+) I emulate the PSG using a simple PSG->YM wrapper. The chips are similar enough to make this work well for most games. Sampled sound doesn't sound right though, but apart from that the result is fairly convincing.

You could use MP2 (DSP) for music and the YM for sound effects, perhaps. Maybe DSPMOD could be used, iirc it offers SFX channels + "MOD" capability.

[shoggoth]

do you know any other emulator that works in this way?

Basilisk 2 contains a rudimentary virtualization mechanism; it changes the VBR and virtualizes supervisor mode, so the virtual Mac basically runs in user mode despite using privileged instructions. It doesn't change the MMU mapping though. On the Atari, it would some additional MMU tricks and/or changes to the FreeMiNT kernel (if multitasking is required).

IIRC Mr Pink used the MMU to speed up Z80 emulation in GodBoy, and perhaps he did something similar in GodlyNES as well. Dunno.

[dml]

Yup, that's a much better idea. It's better to have a playable emulator than to accurately emulate every single aspect of the original machine. In my SMS+ port (060+) I emulate the PSG using a simple PSG->YM wrapper. The chips are similar enough to make this work well for most games. Sampled sound doesn't sound right though, but apart from that the result is fairly convincing.

You could use MP2 (DSP) for music and the YM for sound effects, perhaps. Maybe DSPMOD could be used, iirc it offers SFX channels + "MOD" capability.

Yes I think it's the right thing to concentrate on making a select subset of games playable and worthwhile, rather than trying to implement an accurate emulator for everything, and end up with no playable games. So abstracting some devices and services (like music etc.) is sensible.

[Anima]

Another game tests update (I will update the OP as well).

Status colour codes as follows:

• Game is potentially playable (game starts and the player is controllable).
• Game crashes when started/while running the attract mode.
• Game crashes (even attract mode doesn't run).

Tested games so far:

• Blazing Star (*)
• The King of Fighters '94
• Last Resort
• Metal Slug
• Metal Slug 2(*)
• Neo Bomberman
• Nightmare in the Dark (bootleg)
• Puzzle Bobble
• Pulstar (*)
• Sengoku
• Sengoku 2
• Aero Fighters 2 / Sonic Wings 2
• Aero Fighters 3 / Sonic Wings 3
• Top Hunter
• Viewpoint (stack frame modifications)

(*) Game graphics ROM size is >16 MiB.

Cheers
Sascha

[CiH]

That's an impressive list already