Final Fight (arcade) for the Atari STE/Falcon030

[npomarede]

Unfortunately everything above the MC68010 cannot be emulated properly yet due to lack of documentation. So getting some hints from a register dump and a small stack frame is all I can do for now...

Hi
except for cycle accuracy I think that the cpu emulation in Hatari is correct, even for cpu >= 68020.
If you have some specific / reproducible cases that don't work using Hatari I can have a look.

Nicolas

[Anima]

Does this thing need a PMMU, and how much of it bangs the hw?

No, the MMU is not involved. There are nospecial functions since the game is aimed for all MC68030+ CPUs.

Hi
except for cycle accuracy I think that the cpu emulation in Hatari is correct, even for cpu >= 68020.
If you have some specific / reproducible cases that don't work using Hatari I can have a look.

Ok, thanks.

Yeah, I think there would be more reports of incompatibility if the emulation of faster CPUs is not good enough. So I need to check the code again for some weird ideas which simply doesn't work as expected.

[shoggoth]

No, the MMU is not involved. There are nospecial functions since the game is aimed for all MC68030+ CPUs.

Cool. I’m thinking it wouldn’t be that difficult to get it up and running on the V4/080, then. It has a Falcon comptible video XBIOS, and there are linewrap registers on it too (not Atari compatible ones at this point though).

How much of the OS is ”left”, was it necessary to kill all of it?

[Anima]

No, the MMU is not involved. There are nospecial functions since the game is aimed for all MC68030+ CPUs.

Cool. I’m thinking it wouldn’t be that difficult to get it up and running on the V4/080, then. It has a Falcon comptible video XBIOS, and there are linewrap registers on it too (not Atari compatible ones at this point though).

How much of the OS is ”left”, was it necessary to kill all of it?

Well, I think it'll work. Do you have some specs about that configuration? So far it basically requires a 16 bit truecolor mode (384 x 224) with virtual size capabilities (512 x 224) and a PCM "device" for samples.

[shoggoth]

Well, I think it'll work. Do you have some specs about that configuration? So far it basically requires a 16 bit truecolor mode (384 x 224) with virtual size capabilities (512 x 224) and a PCM "device" for samples.

It sports a (somewhat) TOS4 compatible sound and video XBIOS. The closest resolution would likely be 320x240 or 480x270. 16 bit TC format is equal to that of the Falcon. Just like on the Falcon, there's no API for the wrap register. The framebuffer can reside in STRAM or ALT RAM, i.e. one can use Malloc/Mxalloc() as usual.

EDIT: Right, another thing. IKBD. Right now, it has to be handled through the TOS callback vectors (Kbdvbase()), including the one introduced by Atari in TOS2 at Kbdvbase()[-4] (undocumented but used by FreeMiNT and other stuff). This may change in the future; there's an experimental branch that fake the IKBD ACIA hw registers + corresponding interrupt, but this is not something that can be relied on at this point.

[Anima]

Short update: finally some relocation problems in the Final Fight disassembly have been fixed. These wrong addresses were responsible for some nasty bugs in the "car breaking" stage and the following one where the player couldn't advance to the next stage.

I'll prepare a new test version in the next days.

[HospesSTE]

I keep my fingers crossed. And then in just a moment the Atari STe version

[Anima]

A new test version is available here: https://www.anides.de/ff_030_230516.zip

Supported systems:

• Atari Falcon 030 with 14 MB RAM + RGB-Monitor/TV
• Accelerated Atari Falcon 030 computers with an MC68030+ CPU and 14 MB ST-RAM + RGB-Monitor/TV
• Hatari, best with an appropriate configuration (e.g. Falcon 030 hardware, MC68060 CPU, 32 MHz)

[marss]

Working great when launched in low rez

[Anima]

Working great when launched in low rez

So… finally without any crash?

[marss]

Would it be possible to launch it in any rez?

[Anima]

Yes, definitely. However, this is just a test to check if there are any issues on faster CPUs.

[Xerus]

This beta version is surprisingly playable with a 68030 at 32MHz!!!
Really surprising when you consider the size and the number of sprites on the screen, bravo Anima!
Finally a fun version on a western machine and even much more fun than the SNES version which was so boring with its 3 enemies at the same time, it completely spoiled the epic side of the arcade version.

[Anima]

This beta version is surprisingly playable with a 68030 at 32MHz!!!

Sounds promising! May I ask what accelerator do you have installed?

Can you do a short video recording of a playing scene?

Edit: I guess that you've tried it on Hatari!?

[shoggoth]

I get some error/debug output on EmuTOS.

[Anima]

I get some error/debug output on EmuTOS.

Ok. I am actually testing the gameplay on Hatari with EmuTOS so on what spec did you observe the crash? Also note that ST-Zip decompression results in corrupted data sometimes but I think it's more related to a certain ZIP compressor version!?

[shoggoth]

Ah okies! I'm on EmuTOS 1.2.1. Perhaps it's my data files; I just googled 'Final Fight roms', found a file called flight.zip and used that. It seems to find it and convert data, I'm asked to press Q or Space to start the thing - then numbers.

I'm unzipping stuff on my Mac atm. ST-Zip is naughty.

[shoggoth]

Ah I'm sorry, I didn't have TT RAM enabled. It starts now!

(i.e. on my Hatari setup, it fails w o TTRAM)

EDIT: For fun I also tried it on my Vampire/V4. It complains about insufficient STRAM (it's got 12 megs STRAM, 500 megs TTRAM).

[EvilFranky]

This is great, has it been optimized?? Seems quite a bit faster than before.

Had to enable fast ram in Hatari to get it to run.

[shoggoth]

It allocates 1k of fastram (judging by the disassembly)

[Anima]

Ah I'm sorry, I didn't have TT RAM enabled. It starts now!

(i.e. on my Hatari setup, it fails w o TTRAM)

EDIT: For fun I also tried it on my Vampire/V4. It complains about insufficient STRAM (it's got 12 megs STRAM, 500 megs TTRAM).

Uh, Vampire would be worth a try. In fact it'll work with 12 MB ST-RAM for sure but I am looking for 14 MB specifically, doh!

This is great, has it been optimized?? Seems quite a bit faster than before.

There's some kind of a "throttle" logic which is not perfectly tuned for faster machines and I yet have to find the optimal standard values for it.

[shoggoth]

Uh, Vampire would be worth a try. In fact it'll work with 12 MB ST-RAM for sure but I am looking for 14 MB specifically, doh!

At this point, no VIDEL/SHIFTER video hw regs. So it's either VsetScreen(-1,phys,-1,-1)/VsetMode(mode)/Physbase()/Vset/setRGB() etc, or use SAGA hw registers directly:

#define SAGA_VIDEO_PALV4SA *(volatile ULONG*)0xdff388 /* only 1 register format : IRGB where I is index on 8 bits */
#define SAGA_SET_VIDEO_MODE *(volatile UWORD*)0xdff1f4 /* set video mode */
#define SAGA_GET_VIDEO_MODE *(volatile UWORD*)0xdfe1f4 /* get video mode */
#define SAGA_SET_VIDEO_MODULO *(volatile UWORD*)0xdff1e6 /* set video modulo */
#define SAGA_GET_VIDEO_MODULO *(volatile UWORD*)0xdfe1e6 /* get video modulo */
#define SAGA_SET_VIDEO_PHYSBASE *(volatile ULONG*)0xdff1ec /* write chunky plane ptr */
#define SAGA_GET_VIDEO_PHYSBASE *(volatile ULONG*)0xdfe1ec /* read chunky plane ptr */

Note that there's only a single palette register; upper byte is the palette index, palette is write only. Separate registers to read/write physbase, modulo, mode.

Video mode as follows:

Code: Select all

       +-------+----------+-------------------------------------------+
         | BIT#  | FUNCTION | DESCRIPTION                             |
         +-------+----------+-----------------------------------------+
         | 15.08 | Resolution  | $00                                  |
         |       |               $01 = 320x200                        |
         |       |               $02 = 320x240                        |
         |       |               $03 = 320x256                        |
         |       |               $04 = 640x400                        |
         |       |               $05 = 640x480                        |
         |       |               $06 = 640x512                        |
         |       |               $07 = 960x540                        |
         |       |               $08 = 480x270                        |
         |       |               $09 = 304x224                        |
         |       |               $0A = 1280x720                       |
         |       |               $0B = 640x360                        |
         |       |               $0C = 800x600                        |
         |       |               $0D = 1024x768                       |
         |       |               $0E = 720x576                        |
         |       |               $0F = 848x480                        |
         |       |               $10 = 640x200                        |
         |       |               $11 = 1920x1080                      |
         |       |               $12 = 1280x1024                      |
         |       |               $13 = 1280x800                       |
         |       |               $14 = 1440x900                       |
         +-------+----------+-----------------------------------------+ 
         | 07.00 | Pixelformat | $00                                  |
         |       |               $01 = 8bit CHUNKY (indexed)          |
         |       |               $02 = 16bit R5G6B5                   |
         |       |               $03 = 15bit 1R5G5B5                  |
         |       |               $04 = 24bit R8G8B8                   |
         |       |               $05 = 32bit A8R8G8B8                 |
         |       |               $06 = YUV                            |
         |       |               $07 =                                |
         |       |               $08 = PLANAR 1BIT ATARI              |
         |       |               $09 = PLANAR 2BIT ATARI              |
         |       |               $0A = PLANAR 4BIT ATARI              |
         |       |               $0B = PLANAR 8BIT ATARI              |
         +-------+----------+-----------------------------------------+ 

Note: Not sure 8bit Atari planar is available yet, it's in the pipeline (perhaps it's already in the latest firmware, has yet to be tested).

VsetMode()/VsetScreen() either use Falcon/VIDEL/TOS4 format, or SAGA-specific format (0x4000 | SAGA_MODE_VALUE) (equals hw reg value above).

EDIT: SDMA-XBIOS APIs are available, but again no SDMA hw regs.

[Anima]

Uh, Vampire would be worth a try. In fact it'll work with 12 MB ST-RAM for sure but I am looking for 14 MB specifically, doh!

At this point, no VIDEL/SHIFTER video hw regs. So it's either VsetScreen(-1,phys,-1,-1)/VsetMode(mode)/Physbase()/Vset/setRGB() etc, or use SAGA hw registers directly:
[...]

Thanks for the info. This needs definitely some work to get it running. However, it seems to be doable for sure.

[Estrayk]

Tested in real Falcon 030 14mb. RGB. It works! (impressive work Anima! btw)

Tested in real Falcon 060 ct60e. RGB. Doesnt work, when I press space bar, the computer sometimes reset or somethign show this screen.

By the way, I made a video capture running from 030 stock, mostly in case anyone is curious to see it working on a real machine to 16Mhz.

https://www.youtube.com/watch?v=29ZBzyFMDko

[Anima]

Tested in real Falcon 060 ct60e. RGB. Doesnt work, when I press space bar, the computer sometimes reset or somethign show this screen.

This particular crash seems to be located (again) at the sprite drawing routines. Interestingly I cannot reproduce it using Hatari. Well, thanks for the screenshot.