New project: NEO GEO emulation on the Atari Falcon 030

[Anima]

Hello guys,

another year with another experiment.

This time it's different to the last one in many respects. The Galaga 88 and PacMania ports from the X68000 required to have the original code being disassembled correctly; now you can use the original code so it's a true emulation of the NEO GEO and so it is easy to get more games running.

The first demonstration for a proof of concept is available. This demo is also available as a video showing Metal Slug running on my unaccelerated(!) Falcon on YouTube.

Edit: second demo upload.

Here is a big archive with the most recent version of the Neo Geo emulator including 50 games. The archive itself is about 230 MiB in size and expands to about 730 MiB on the harddisk.

Requirements: Atari Falcon 030 with a MC68030 CPU and 14 MB RAM. Avoid loading too many accessories or other memory residing applications before starting the emulator (e.g. hold CONTROL while booting). The emulator works on RGB/TV and VGA monitors.

Start NEOGEO.TTP and enter the folder name of the game (like MAME and being shown in the videos).

Beware: not all the games will work.

Edit: details added.

Well, the main and most important feature used by this emulator is the MMU and the "Bus Fault Recovery" capability (please refer to the "MC68030 User's Manual", Section 8.2) so you need at least a MC68030 or better. Actually this emulator will currently run only on a MC68030 because the MMU handling is different on the other CPUs.

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:

- know the accessed address.
- know the data size (byte, word, long).
- know the "to be written" data value.
- know if it was a read or write access.
- chance for a recovery from the exception (return the required "to be read" data to the original program and continue the execution).

In fact, all those features are available on a MC68030 just because they are necessary to implement a virtual memory system. So in conclusion the the real system emulator is the bus error handler.

However, there are still some other things to consider like the different interrupt handling, the fact having a Z80 CPU as a coprocessor and hoping that no dirty tricks have been used on the MC68000. Luckily the NEO GEO system is a rather simple and very clean designed machine so this was not a problem. For example it uses almost only one interrupt: the VBL and the Z80 is only used in a "fire and forget" manner. The sprite system is also a simple implementation and the sprite data is totally separated from the main system.

To be continued...

I hope this gives a first good overview on how it works. Feel free to comment and ask about details.

Edit: demo upload.

The Metal Slug demo archive is now available for download (as shown in the video). Please note that you need a real Falcon with 14 MB. You also have to start it with lots of free RAM and have it connected to a TV set or RGB monitor. Beware: only one in-game action is shown properly in the attract mode due to the RAM limitations.

Edit: game test results added.

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 (video)
• Metal Slug (video)
• Metal Slug 2 (*)
• Neo Bomberman
• Nightmare in the Dark (bootleg)
• Puzzle Bobble
• Pulstar (*)
• Sengoku
• Sengoku 2
• Aero Fighters 2 / Sonic Wings 2 (video)
• Aero Fighters 3 / Sonic Wings 3 (video)
• Top Hunter (video)
• Viewpoint (stack frame modifications)

• Burning Fight
• Ghost Pilots
• Kabuki Klash
• Kizuna Encounter: Super Tag Battle
• King of the Monsters
• Samurai Shodown 2

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

Cheers
Sascha

[joska]

Wow! This is very impressive! Do you expect it to be usable on plain Falcons?

[Anima]

Wow! This is very impressive! Do you expect it to be usable on plain Falcons?

At least that was my initial goal. Probably with a lot of good optimizations this could be achieved but don't bet on it. However, less graphic demanding games are probably a better candidate for a better experience like "NeoBomberman" or "Neo Mr. Do".

Cheers
Sascha

[shoggoth]

I'd love to see this on a CT2/AB040/CT60.

omg.

[dml]

I was wondering when you were going to announce this one

Wow - looks like it has really progressed from the earlier tests you sent me! Great work.

BTW apart from the potential optimizations, a half-resolution version might be more manageable as a starting point for a stock Falcon? For this type of game anyway. I suppose it depends on the game and what it needs - but it's one of those things that might not be too hard at the emulation layer if affects everything at once, and might be ok for some games which need faster movement but less detail.

[Anima]

I was wondering when you were going to announce this one

Well I was running into a lot of nasty bugs and debugging without a debugger was really hard.

Wow - looks like it has really progressed from the earlier tests you sent me! Great work.

Thanks. Yes, now the sprites are almost perfect (except for scaling). Unfortunately the compiled sprites require too much memory for a complete attraction mode demo.

BTW apart from the potential optimizations, a half-resolution version might be more manageable as a starting point for a stock Falcon? For this type of game anyway. I suppose it depends on the game and what it needs - but it's one of those things that might not be too hard at the emulation layer if affects everything at once, and might be ok for some games which need faster movement but less detail.

Agreed. At least moving less data on the bus would be a good idea for a speedup. In fact, this would help also with the memory issue.

Cheers
Sascha

[dml]

Well I was running into a lot of nasty bugs and debugging without a debugger was really hard.

I'll bet! And it will drop a few jaws when everyone finds out how the thing actually works!! ;-P

[EvilFranky]

Crazy!

[dml]

Crazy!

It is nuts, yes. I'm going to shut up now, in case he wants to keep the really good bits secret.

[EvilFranky]

The last 18 months have been incredible for the Falcon

[Anima]

It is nuts, yes. I'm going to shut up now, in case he wants to keep the really good bits secret.

Well, like I told you before: the emulation is a rather simple implementation so that I was really shocked why no one else has done this before.

Fun fact: the current emulator binary is less than 8 kB in size. You can see it in the video and this includes a small trace monitor a sprite compiler as well.

So the best part about the emulation is that I can also think of having a Sega Mega Drive emulator on the Falcon as well. Not to mention that other MC68000 based consoles and arcade machines are now also good candidates for this kind of emulation.

Cheers
Sascha

[CiH]

I'd love to see this on a CT2/AB040/CT60.

omg.

Seconded!

[bod/STAX]

So the best part about the emulation is that I can also think of having a Sega Mega Drive emulator on the Falcon as well. Not to mention that other MC68000 based consoles and arcade machines are now also good candidates for this kind of emulation.

A 68000 specific version of MAME perhaps?

[jvas]

What do you think: can it be adapted to run on a TT too?

[Anima]

What do you think: can it be adapted to run on a TT too?

Yes, the core game would run for sure but I have no idea on how to emulate the sprite display properly using the TT graphic modes. The true colour mode of the Falcon has clearly a big advantage emulating 16 colour hardware sprites.

Cheers
Sascha

[Anima]

A 68000 specific version of MAME perhaps?

Well, sort of... maybe. Depends on some system specifications (see the details in the first post).

Cheers
Sascha

[Eero Tamminen]

Well I was running into a lot of nasty bugs and debugging without a debugger was really hard.

Is MMU emulation in (WinUAE CPU version of) Hatari good enough to run it? [1]

That should definitely help debugging it, and some MMU debugging help could even be added to Hatari for things like this.

[1] I guess it's a bit unlikely, as currently at least handling of the 68030's Special Status Word (SSW) isn't complete (due lack of clarity on documentation of it). It is needed for the exception stack frame for bus and address errors.

[dml]

Yes, the core game would run for sure but I have no idea on how to emulate the sprite display properly using the TT graphic modes. The true colour mode of the Falcon has clearly a big advantage emulating 16 colour hardware sprites.

There are at least some well explored possibilities for that sort of problem. But a lot of work for somebody.

In any case it would almost certainly benefit from an extra team member to try a TT version - it seems like quite a lot of trouble as a 'sidetrack project' to the emulator itself and getting games to work in the first place.

I suppose you could get a quick 'template' TT version going by replacing the sprite compiler with a normal pixel plotting block, with a 16bit->8bit colour reduction translation table in the middle (even a greyscale one), and use 8plane c2p to get it on the screen. It would be very slow, but it would let somebody get the other areas TT friendly. OTOH probably only worth doing if somebody with a TT volunteers to do the rest .

[Anima]

Is MMU emulation in (WinUAE CPU version of) Hatari good enough to run it? [1]

That should definitely help debugging it, and some MMU debugging help could even be added to Hatari for things like this.

[1] I guess it's a bit unlikely, as currently at least handling of the 68030's Special Status Word (SSW) isn't complete (due lack of clarity on documentation of it). It is needed for the exception stack frame for bus and address errors.

I need to check that but I think it'll fail for the reason you already mentioned: the SSW is a core element used by the bus error handler to do the recovery.

The important SSW flags in use are: DF, RW and SIZE. The emulator routine clears the DF in order to emulate the functionality. For example in case of a read access (RW == 1) it writes the desired data value (of size SIZE) to the appropriate stack frame address and returns normally with RTE. So fixing at least the behaviour of these flags would probably a good idea to get it working on Hatari.

Cheers
Sascha

[dml]

...and some of these 'big crazy port' projects would definitely benefit from large pools of TT ram made available by Hatari, even if it's just used as 'developer ram' until big things are made to fit in a sensible space!

(Hatari feature request hint! )

[Anima]

The Metal Slug demo archive is now available for download (as shown in the video). The first post has been updated as well.

Cheers
Sascha

[Anima]

There are at least some well explored possibilities for that sort of problem. But a lot of work for somebody.

In any case it would almost certainly benefit from an extra team member to try a TT version - it seems like quite a lot of trouble as a 'sidetrack project' to the emulator itself and getting games to work in the first place.

I suppose you could get a quick 'template' TT version going by replacing the sprite compiler with a normal pixel plotting block, with a 16bit->8bit colour reduction translation table in the middle (even a greyscale one), and use 8plane c2p to get it on the screen. It would be very slow, but it would let somebody get the other areas TT friendly. OTOH probably only worth doing if somebody with a TT volunteers to do the rest .

To be honest it would be nice to have some help. Of course the current code needs some cleanup but the emulation implementation provides a very clean interface for different kind of graphics emulation on different machines.

Cheers
Sascha

[simonsunnyboy]

The Metal Slug demo archive is now available for download (as shown in the video). The first post has been updated as well.

Cheers
Sascha

Is this actually playable to some extend, or only the attract mode?

[Anima]

Is this actually playable to some extend, or only the attract mode?

Well, yes and no. There's a very awkward test keyboard routine which allows you to emulate actions like insert coin, select one player, start the game and player movement. Unfortunately you won't see much because the sprites in the first level are not compiled for this demo. I'll fix the keyboard routine and prepare a new demo later on where you can play the first mission in a limited way.

Just in case you want to try it anyway:

5: insert coin.
1: one player start.
Arrow keys: move player.
SHIFT: fire.
CONTROL: jump.

In order to start the game you need to press the keys 5, 1 and SHIFT.

Please note: due to the awkward routine you're able to press only one key at a time.

Cheers
Sascha

[jvas]

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