New project: NEO GEO emulation on the Atari Falcon 030

[Anima]

OK, I have prepared a big downloadable archive (142 MiB) with 30 Neo Geo games to test/show on a real Atari Falcon (RGB/TV and 14 MB RAM required).

Is there any interest to test it on your machine and report me about this? To do so please write me a PM to get the link.

Please note that the emulator still only works on a MC68030 and so I would prefer to get some feedback from users with a MC68030 accelerator.

Cheers
Sascha

[CiH]

Dammit, not at home right now. Otherwise I would have the perfect fast 030 machine to test with.

[Anima]

Damn... I just noticed that I've forgotten to add the Neo Geo BIOS in the demo archive so the emulator won't work properly. If you already have access to the BIOS (like from your MAME collection) you only need to put the file "SP-S2.SP1" in the same folder where the "NEOGEO.TTP" resides or else please send me a PM for a download link. The archive has been updated as well so you can also download the whole package again.

Sorry for the inconvenience
Sascha

[f030]

Damn... I just noticed that I've forgotten to add the Neo Geo BIOS in the demo archive so the emulator won't work properly. If you already have access to the BIOS (like from your MAME collection) you only need to put the file "SP-S2.SP1" in the same folder where the "NEOGEO.TTP" resides or else please send me a PM for a download link. The archive has been updated as well so you can also download the whole package again.

Sorry for the inconvenience
Sascha

thanks, i started to panic

[evil]

Dammit, not at home right now. Otherwise I would have the perfect fast 030 machine to test with.

CT2 have it's own MMU-tree setup, it was a problem to get FreeMiNT memory protection working. As this emulator is setting up the MMU as well, maybe there will be some trouble. Ideal would be a 040/060 compatible MMU setup and TT-RAM awareness, things might get very playable then

Do Don Pachi on Falcon! We (deez and me) actually did a basic shooter-engine years ago to see if it was theoretically possible to run that many sprites on the 060 Falcon at full frame rate. And it sure was, the whole damn screen flooded with bullets and what not Of course it's a different matter running things through an emulator.

[Anima]

CT2 have it's own MMU-tree setup, it was a problem to get FreeMiNT memory protection working. As this emulator is setting up the MMU as well, maybe there will be some trouble. Ideal would be a 040/060 compatible MMU setup and TT-RAM awareness, things might get very playable then

I am really looking forward to get this emulator working on a faster machine. Unfortunately it's not only the MMU tree which is different on the MC68040 and MC68060 but also the bus error handling is. Especially the exception stack frame on the MC68060 provides not as much data as needed for the current emulation. But this is not an unsolvable problem.

One of the bigger problems I'm facing is that I haven't such a machine here to do some tests. At least I'll try setup an ARAnyM emulator environment to do some tests for a MC68040 version.

Cheers
Sascha

[MadMax2023]

You have a very good idea, because there is a lack of good games on atari falcon.
I am sure it will run at fullspeed on a CT60 falcon, should be amazing to make it compatible with 060 cpu.
If you want to do a 060 version i can make some tests with mine (CT63).

[Anima]

You have a very good idea, because there is a lack of good games on atari falcon.
I am sure it will run at fullspeed on a CT60 falcon, should be amazing to make it compatible with 060 cpu.
If you want to do a 060 version i can make some tests with mine (CT63).

Thanks. Especially the MC68060 version is tough to implement so it'll take some time.

Cheers
Sascha

[Moulinaie]

CT2 have it's own MMU-tree setup, it was a problem to get FreeMiNT memory protection working. As this emulator is setting up the MMU as well, maybe there will be some trouble. Ideal would be a 040/060 compatible MMU setup and TT-RAM awareness, things might get very playable then

I am really looking forward to get this emulator working on a faster machine. Unfortunately it's not only the MMU tree which is different on the MC68040 and MC68060 but also the bus error handling is. Especially the exception stack frame on the MC68060 provides not as much data as needed for the current emulation. But this is not an unsolvable problem.

One of the bigger problems I'm facing is that I haven't such a machine here to do some tests. At least I'll try setup an ARAnyM emulator environment to do some tests for a MC68040 version.

Cheers
Sascha

Hello,

I can help for testings and debugging if you want.
I have a TT (32 or 48 MHz) with a NOVA Graphic card: so the pixel encoding is close to the TrueColor mode of the Falcon, little things to change.
I have a good debugger.
I also have a Falcon CT060 when you'll be ready for supporting this CPU.

How did you program your NeoGeo emulator? (I mean: using what tools?)

Guillaume.

[Anima]

Hello,

I can help for testings and debugging if you want.
I have a TT (32 or 48 MHz) with a NOVA Graphic card: so the pixel encoding is close to the TrueColor mode of the Falcon, little things to change.
I have a good debugger.
I also have a Falcon CT060 when you'll be ready for supporting this CPU.

How did you program your NeoGeo emulator? (I mean: using what tools?)

Guillaume.

Hello Guillaume,

thanks for your help offer.

Do you have some more details about the TT specs like RAM size, etc.? Do you have any documentation about the NOVA graphics card as well?

Edit: I am using Vincent Rivière's m68k-atari-mint cross-tools assembler with Eclipse on the PC in combination with a Null modem cable.

Cheers
Sascha

[shoggoth]

The Nova doesn't have an XBIOS API to set screenmodes etc. Basically you need to either A: program the VGA chipset directly or B: rely on the current graphics mode and get the screenbase using Logbase() or Physbase(). Data is possibly byte swapped depending on the card, iirc.

[dml]

The Nova doesn't have an XBIOS API to set screenmodes etc. Basically you need to either A: program the VGA chipset directly or B: rely on the current graphics mode and get the screenbase using Logbase() or Physbase(). Data is possibly byte swapped depending on the card, iirc.

I remember having to do something to support Nova, and it just assumed the current video mode and physbase were already set up. i.e. just colour format (byteswapped 16bit or 24bit BGR IIRC). I think there were some HW addresses also, but I'd have to look at old code to see what they were for - maybe just video address space.

If I find anything I'll post.

Unfortunately the Nova was on loan at the time, I don't have one now to test with.

[Anima]

Thanks shoggoth and Doug for the info. Getting some examples would be appreciated.

Cheers
Sascha

[dml]

Found a bit more info... I made some video driver plugins for Apex v3 and there seem to be 5 of those.

NOVA.15B
NOVA.16B
NOVA.24B
NOVA.32B
VIDEL

This offers a clue to the display formats supported. I'll dig out the source later and see what they are, but I expect its easy to guess in any case

[dml]

D'oh... there's a readme.txt next to my drivers which explains the formats. No need for source.

Code: Select all

The various drivers are described in the following subsections:

VIDEL
-----

Pixel format: %RRRRRGGG:GGGBBBBB (Motorola/big-endian 16-bit)

The VIDEL display driver is designed to make use of the Falcon's
built-in 16-bit (65536 colour) video hardware. This should be used
as the default driver, since it works on all Falcon machines.

You can modify the actual display resolution used with a suitable
screen enhancer, particularly our own VIDELITY package, although other
equivalent programs such as BlowUP, Videl Inside (VI) and FalconScreen
(FS) can be used to do the same job - each with their own set of
special limitations (see manual). ScreenBlaster I, II & III cannot be
used with the driver unless truecolour mode is selected from the
Desktop before running the program. This is due to restrictions in the
SB software. All other screen enhancers will allow the program to be
run from any Falcon video mode, which will switch to truecolor mode
automatically.

NOVA
----

These display drivers are designed for Falcons equipped with the Nova
or SuperNova video cards, allowing the program to take advantage of
the large truecolour video modes available with such hardware.

The video card should be operating in the appropriate colour mode
before use with any of these drivers, simply because the program
cannot change resolution on-the-fly with a video card connected.
Attempting to use a 16-bit driver in a 24-bit display mode for
instance will not work, resulting in a screen full of garbage.

The currently supported drivers are as follows:

* NOVA.15B

Pixel format: %GGGBBBBB:xRRRRRGG (Intel/little-endian 15-bit)

This driver is for use with 15-bit truecolour, allowing up to 32768
simultaneous on-screen colours. This colour mode is very fast, but
can suffer from noricable colour banding artifacts on finely shaded
images.

* NOVA.16B

Pixel format: %GGGBBBBB:RRRRRGGG (Intel/little-endian 16-bit)

This driver is for use with 16-bit truecolour, allowing up to 65536
simultaneous on-screen colours. This colour mode is almost as fast
as the 15-bit version, but has the advantage of much less noticable
colour banding on images.

This is by far the best mode for use with this program. It is very
quick, and allows very large resolutions on a standard card. It is
also as close as you can get to 24-bit without paying in terms of
memory or performance.

* NOVA.24B

Pixel format: %BBBBBBBB:GGGGGGGG:RRRRRRRR (Reverse R,G,B)

This driver is for use with 24-bit truecolour, allowing up to 16
million simultaneous on-screen colours. The 24-bit display format
is very inefficient, which can impact on performance during screen
redraws. Although it is considerably slower than the 15 & 16 bit
colour modes, it has the advantage of causing no colour banding.
It does however require 50% more video memory than any equivalent
sized 15 or 16-bit display, limiting your maximum available screen
resolution.

Don't use 24-bit colour modes if you can get the resolution you
want with 32-bit colour instead, since it is considerably faster
for some screen operations.

* NOVA.32B

Pixel format: %RRRRRRRR:GGGGGGGG:BBBBBBBB:AAAAAAAA (Std R,G,B,A)

This driver is for use with 32-bit aligned truecolour, allowing up
to 16 million simultaneous on-screen colours (identical to 24-bit).
The 32-bit display format is a more efficient layout than 24-bit,
which makes it faster for some screen operations. Although 32-bit
produces no colour banding problems, it requires 33% more video
memory than and equivalent 24-bit modes - placing a tighter limit
on the maximum available resolution.

If you can achieve the resolution you want in 32-bit colour, use it
instead of 24-bit for smoother operation.

[Anima]

D'oh... there's a readme.txt next to my drivers which explains the formats. No need for source.

Thanks Doug, that are good news so far.

Do you know if the graphics memory is directly mapped into the TT RAM and if you can you define virtual screen sizes as well?

Cheers
Sascha

[dml]

IIRC the video display for Nova is mapped into the Falcon address space but I don't remember where. I thought it was in the hardware register area but it seems too small for that. Probably very high in TT ram then.

Physbase() should return the correct address. Asking the AES/VDI for the workstation dimensions will get you the screen size. I think that's all I did with it. I'll look more closely later to see what the details were.

[shoggoth]

Nova on the Hades actually allows you to change the screen base using Setscreen(-1,base,-1). If there's enough memory on the card, you might be able to do page flipping this way (I did). Screen memory allocation isn't a big deal, since Nova doesn't care about it. I wouldn't change the logical screen base.

[dml]

One more thing about Nova - if it is detected (I think it used a cookie - again I'll check) you can shut down the Videl to prevent it fetching from STram. This recovers a bunch of CPU bus cycles, especially useful when comparing performance of Nova vs native 16bit Videl modes. It's particularly helpful with Nova because chances are there is no FastRam fitted alongside Nova (unless its on top of an accel board) and plenty of stuff will be executing/copied from STram.

The easiest way to do this is probably to make a minimal Videl mode (1 plane, 1 or 0 scanlines?) in ScreenPain and execute the asm code it produces for that. There's probably a more precise way but it would do Just make sure the vertical refresh continues to function normally.

[Moulinaie]

The Nova doesn't have an XBIOS API to set screenmodes etc. Basically you need to either A: program the VGA chipset directly or B: rely on the current graphics mode and get the screenbase using Logbase() or Physbase(). Data is possibly byte swapped depending on the card, iirc.

No XBIOS : yes.

But there is a call to set the screen mode ! You can find it through the installed cookie.
I know how to do that, I used it in my VidiST program (my own driver for that video digit card).

The video memory is mapped into the VME space address of the TT. You can directly read/write to it.
The only problem is that this memory is slower than the ST/TTRam.
The best would be to work in TT Ram and just copy the screen at once.

Guillaume.

[Anima]

Some short news: here's a new video of "Top Hunter" running on the emulator (VGA).

Cheers
Sascha

[CiH]

In amongst all the great news from Doug, nice to see this still going.

Have you managed to get the Neo Geo stuff tested on a faster Falcon yet?

[dml]

The emulation looks accurate. I think I saw a non-reflected sprite but I'm not sure. When you have to look hard to find problems it must be going well Great!

[Anima]

Have you managed to get the Neo Geo stuff tested on a faster Falcon yet?

Not yet but I would like to know who has a MC68030 based accelerator and is willing to test it.

Of course there are still a lot of things to do. For example the exception handling is slowing down the game too much (it's too slow even without any graphics emulation as Mikro alread pointed out).

So I am about to implement a function to replace the instructions with NOPs and LINE-A calls to speed it up. The advantage of this method is that the resulting program would work on MC68040+ as well because the MC68030 specific exception handling is not needed anymore. However, the game needs to be completely fixed by running on the MC68030 first.

I also would like to implement the sprite scaling but that will result in another performance degration for sure.

The emulation looks accurate. I think I saw a non-reflected sprite but I'm not sure. When you have to look hard to find problems it must be going well Great!

Thanks. Some notes about the sprite engine: I am tracking the usage of the sprite IDs and store it in the "sprite usage bitmap" to keep the memory usage for compiled sprites low. Sometimes not all sprites are tracked due to frame skipping so these sprites are (partly) invisible and need to be recompiled by deleting the "compiled sprites" file and restarting the emulator.

Cheers
Sascha

[EvilFranky]

Have you managed to get the Neo Geo stuff tested on a faster Falcon yet?

Not yet but I would like to know who has a MC68030 based accelerator and is willing to test it.

Of course there are still a lot of things to do. For example the exception handling is slowing down the game too much (it's too slow even without any graphics emulation as Mikro alread pointed out).

So I am about to implement a function to replace the instructions with NOPs and LINE-A calls to speed it up. The advantage of this method is that the resulting program would work on MC68040+ as well because the MC68030 specific exception handling is not needed anymore. However, the game needs to be completely fixed by running on the MC68030 first.

I also would like to implement the sprite scaling but that will result in another performance degration for sure.

The emulation looks accurate. I think I saw a non-reflected sprite but I'm not sure. When you have to look hard to find problems it must be going well Great!

Thanks. Some notes about the sprite engine: I am tracking the usage of the sprite IDs and store it in the "sprite usage bitmap" to keep the memory usage for compiled sprites low. Sometimes not all sprites are tracked due to frame skipping so these sprites are (partly) invisible and need to be recompiled by deleting the "compiled sprites" file and restarting the emulator.

Cheers
Sascha

Someone with a CPU and BUS accelerated Falcon would be a good first choice, before asking the CT2 owners