Falcon, blitter in Hog mode, and 68030 cache

[chicane]

I'm attempting to have a go at making my new STE game compatible with Falcon 030 before I release it in a couple of weeks time.

The game makes heavy use of the Blitter in HOG mode, and works flawlessly on a real STE and on Hatari in STE mode. It also works as expected on Hatari in Falcon 68030 mode, provided that the "Cycle-exact with cache emulation" option is disabled:

falcon-ok.png

(Ignore the incorrect colours - I understand that these are caused by incomplete Videl emulation and I have already confirmed on a real Falcon that the colours display correctly).

If I remain in Falcon 68030 mode and enable "Cycle-exact with cache emulation", the graphics rendered by the Blitter become rather garbled. This also appears to be the case on a real Falcon from testing others have performed on my behalf:

falcon-corrupted.png

From reading around, I'm inclined to think that the culprit may be the 68030 instruction cache. This old post from DML was especially helpful:

Remember the Falcon has i-cache, so it can coast onwards and do stuff even if the bus is apparently blocked. That mainly affects HOG mode (e.g. assuming the CPU stopped when you enable blitter HOG) but it's worth noting you need to be extra careful using blitter on the Falcon in any case.

With this in mind, I figured that I'd have a go at writing some code to disable the 68030 caches on startup with the intention that doing so would have the same effect as starting Hatari with "Cycle-exact with cache emulation" option disabled (i.e. the graphics will display correctly).

The page at https://bus-error.nokturnal.pl/atari_co ... /chap5.htm suggests that on 68030 I should be able to write the value #$a0a to the CACR register when in supervisor mode to flush and disable both caches:

Code: Select all

    move.l #$a0a,d0
    movec d0,cacr

I've added this code in at game startup, and confirmed that Hatari is executing it, but it unfortunately appears to have no effect in correcting the garbled graphics. Perhaps the 68030 emulation in Hatari Falcon mode isn't sufficiently fleshed out to support such an operation, but my perception is that it's quite complete. I've not yet asked anybody to test on a real Falcon to see if it makes any difference.

Given that the 68030 and associated caches/MMU is an entire area of expertise in itself, is anybody able to assure me that my described approach to the problem is reasonably correct before I start digging any further into this rabbit hole?

Thanks in advance.

[Cyprian]

I wouldn't be surprised it this Falcons part hasn't been emulated properly in Hatari yet.
Unlike BLiTTER in ST/STe , where Hatari is alined with the real hardware.

[mikro]

Also, there's no need do disable the instruction cache.

[chicane]

Also, there's no need do disable the instruction cache.

Thanks for your response. So do you think the cause of the graphics corruption is something other than the instruction cache?

My use case is very much in line with the old comment I've quoted from dml - instruction cache enabled and Blitter used in Hog mode. I'm thinking it may be the case that the instruction cache being enabled results in the 68030 executing writes to Blitter registers while the Blitter is already active with an existing blit. This wouldn't happen on the 68000 or 68030 with instruction cache distabled as starting a Blit in Hog mode would effectively stop the CPU while the blit is in progress.

[npomarede]

Hi

Enabling or disabling data/instr caches in Hatari for 68030 is supposed to work, CACR register is correctly supported and writing #$a0a should disable both of them.

There could be an error in Hatari but it would be interesting first to confirm on a real Falcon that you also have garbage in the gfx or not when writing to CACR.

In case you use TOS system calls, it might be possible that TOS turns cache ON again at some point (but I'm not sure of that)
A small test could be to write #$a0a to CACR at the beginning of every VBL interrupt and see if it makes any differences.

Nicolas

[chicane]

Hi

Enabling or disabling data/instr caches in Hatari for 68030 is supposed to work, CACR register is correctly supported and writing #$a0a should disable both of them.

There could be an error in Hatari but it would be interesting first to confirm on a real Falcon that you also have garbage in the gfx or not when writing to CACR.

In case you use TOS system calls, it might be possible that TOS turns cache ON again at some point (but I'm not sure of that)
A small test could be to write #$a0a to CACR at the beginning of every VBL interrupt and see if it makes any differences.

Nicolas

Thanks for your response. I've put the same code at the top of my VBL but it seemed to make little or no difference.

Stopping the code at any random point states that the current CACR value is 00000202 but not sure whether or not that's what it should be!

Code: Select all

  D0 00000002   D1 00000010   D2 00000008   D3 0000FFFC 
  D4 00042446   D5 0000003B   D6 00000008   D7 00000008 
  A0 000E71B0   A1 003E4140   A2 003E0AD0   A3 00042A7A 
  A4 00016EA4   A5 00016F32   A6 000140D2   A7 000EB9B0 
USP  000CC494 ISP  000EB9B0 SFC  00000000 DFC  00000000 
CACR 00000202 VBR  00000000 CAAR 00000000 MSP  00000000 
SR=2300 T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IM=3 STP=0
Prefetch 00015034 000e71a6 (1) 3039 (MOVE) 000e (ILLEGAL) 71a6 (ILLEGAL) Chip latch 00000000
00015030 6AF8                     bpl.b #$F8

I have somebody lined up to test on real Falcon hardware and will report back with results.

[npomarede]

Thanks for your response. I've put the same code at the top of my VBL but it seemed to make little or no difference.
Stopping the code at any random point states that the current CACR value is 00000202 but not sure whether or not that's what it should be!

OK, so it means that it's unlikely CACR was enabled back somewhere else at some places, it seems caches remain disabled

I have somebody lined up to test on real Falcon hardware and will report back with results.

Let's wait for the result then

[1st1]

I hope, if you disable the 68030 cache, before exit the game back to desktop, that you reenable the cache.

And the same if you change the screen resolution for your game, please restore the video mode back from where the game has been started.

Such neat liitle things make us Falcon users using the reset button less than the left mouse button.

[Eero Tamminen]

Hatari Git version has separate option to disable data cache, in case the issue is with that instead of instruction cache.

Or if you do not want to use Git version of Hatari, you could try 020 emulation, as 020 has only instruction cache, whereas 030 added also data cache.

(I assume Hatari's WinUAE CPU core is accurate enough to emulate this difference.)

[chicane]

Thanks all for the feedback. I've now had somebody to test this on a real Falcon for me.

Whilst attempting to disable the 68030 caches seemed to make little difference on Hatari, it's made a much bigger difference on real HW. There are still a number of glitches but I can see that the majority of calls to the Blitter are happening when and how they're supposed to be happening.

I guess this is about as far as I'll be able to go with Hatari for the purpose of testing further changes!

A video of the game running on real Falcon HW can be seen at https://x.com/RetroRacing/status/1862846047682215943

fasterfalcon.png

[npomarede]

Hi
if you have a binary version of the game that shows the problem on Hatari (even a stripped down / smaller version, not the whole game if you prefer) the nI could have a look and see if sthg can be changed to bette match real HW.

If you don't want it to be publicly distributed, you can send me a PM, I won't share the binary.

[chicane]

if you have a binary version of the game that shows the problem on Hatari (even a stripped down / smaller version, not the whole game if you prefer) the nI could have a look and see if sthg can be changed to bette match real HW.

Many thanks. If you still have time to look into this, the game has now been released and can be downloaded from https://retroracing.itch.io/faster-atari-ste. The screenshots I've seen so far of people running it on their own Falcons suggest that the graphics are much less glitched (but not perfect) on real Falcon HW.

I think the code I've put in to disable the caches appears to have much more of an effect on real HW than it does in Hatari.

[npomarede]

Hi
I saw the game was released this week end at SV 2024 WE, but as the page noted it was "not compatible with falcon" I thought it would require a different version of the game.
I will have a look.

Nicolas

[chicane]

Hi
I saw the game was released this week end at SV 2024 WE, but as the page noted it was "not compatible with falcon" I thought it would require a different version of the game.
I will have a look.

Nicolas

Thanks! "Not compatible with Falcon" felt somewhat easier than trying to convey that it might sorta work on a stock '030 but with graphical glitches, and might in fact be completely broken on any other non-030, enhanced or modified variant.

[Eero Tamminen]

Many thanks. If you still have time to look into this, the game has now been released and can be downloaded from https://retroracing.itch.io/faster-atari-ste. The screenshots I've seen so far of people running it on their own Falcons suggest that the graphics are much less glitched (but not perfect) on real Falcon HW.

I think the code I've put in to disable the caches appears to have much more of an effect on real HW than it does in Hatari.

Which version of Hatari you're using?

Except for the palette issue (Hatari VIDEL emulation lacking support for raster effects like palette switching) I do not see any glitches like in Faster screenshots, with Hatari Falcon emulation, even with caches enabled. This is with the Faster v1 release + EmuTOS 1024k v1.3, both with latest Hatari Git version, and some pre-v2.5 devel snapshot.

There is a difference between game car engine sounds under Falcon emulation between those two Hatari versions though...

[chicane]

Thanks for your feedback Eero.

I've just tried again to be absolutely sure about my earlier claims.

I'm running Hatari 2.5.0 on a Mac with Emutos 512k, Falcon mode, 68030 CPU and 4 megs RAM.

If I run with the "Cycle exact with cache emulation" option unticked, everything looks and runs as I'd expect it to, with the exception of the aforementioned palette issues resulting from incomplete Videl emulation:

faster-pf.png

If I run with the "Cycle exact with cache emulation" option ticked, the graphics are quite badly messed up. My hunch is that it's not fully observing the write to the CACR that I'm making and that either the instruction cache or data cache aren't being fully disabled:

faster-ce.png

The reality on actual Falcon hardware seems to be somewhere in between the two screenshots above, with minor screen corruption but nothing nearly as bad as what happens under Hatari.

fasterfalcon.png

If necessary I can have a go at compiling the latest trunk of Hatari and see if that makes any difference.

[czietz]

This is how it looks for me: Hatari 2.5.0 under Windows, "Cycle exact with cache emulation" active, EmuTOS 512k current snapshot:

grab0010.png

grab0011.png

grab0012.png

grab0013.png

[czietz]

And this is with EmuTOS release 1.3.0:

grab0014.png

[Eero Tamminen]

If I run with the "Cycle exact with cache emulation" option ticked, the graphics are quite badly messed up. My hunch is that it's not fully observing the write to the CACR that I'm making and that either the instruction cache or data cache aren't being fully disabled:

One can see from Hatari statusbars in the screenshots that the same options (CE=cycle exact, no MMU, 50Hz, 4MB, EmuTOS 1.3) are used by everybody, and all should be on same Hatari v2.5 version (or in my case, devel versions both before and after v2.5 release).

Everything works fine with the Linux and Windows versions, but with Mac version there's corruption. It's clearly related to emulation, not e.g. Mac SDL port.

I think Apple uses LLVM, and that both Linux and Windows versions are compiled with GCC. So my current suspicion is it being an issue with the Mac toolchain and its optimizations breaking something in Hatari CPU core.

If necessary I can have a go at compiling the latest trunk of Hatari and see if that makes any difference.

Try first whether enabling MMU has any impact on it, as that uses a different code path for cache emulation. I did not see any difference, but maybe Mac build has.

If that does not change anything, then it makes sense to build latest version. If that shows the same bug, try whether Cycle-exact or data-cache option gets rid of it. If not, try building Hatari with lower optimization level (-O2 if it was -O3), or different compiler.