Eero Tamminen wrote:Ah, you meant the drive head alignment or something similar. That's indeed annoying.
Yes just another example of my bad luck with transfer media!
Eero Tamminen wrote:Using zmodem over serial could work and might even be faster than using floppies.
'Anima' has described a nice version of this which he uses for Falcon dev on Galaga88 etc. When I get more time to play with kit and software I'll try moving to that.
Eero Tamminen wrote:If you look to the end of the src/cpu/newcpu.c file, there are functions for both instruction and data cache, for 020, 030 and 040. And complaints about trickiness of implementing data cache for 030...
Note that these are enabled only when you've enabled cycle exact mode (which is default in latest Hatari WinUAE configuration).
Strangely, the behaviour I am seeing is exactly as if the data cache is turned off all the time. I made a test for this effect and it seems to prove the d-cache is getting 100% miss rate, but I haven't studied the reasons why yet. I also see significantly lower FPS in Hatari vs a real Falcon and the data cache might be the reason.
Or perhaps the d-cache is just off by accident due to a UAE config issue, or a Falcon/TOS emulation problem?
Eero Tamminen wrote:Looking at the sources, I'm not completely sure this happens when you have MMU enabled, but I would assume the code *eventually* to fall into going through the prefetch stuff that does icache check.
I'm still using Hatari 1.6.2 on Windows and have all CPU param checkboxes ticked except '040 MMU emulation'. However it is the WinUAE build (hatari_falcon.exe) so presumably this has the 030 MMU support enabled?
...confirmed by printing CACR inside the app (ienab/denab bits enabled), a test with denab turned on and normal textures vs 1-pixel textures and a separate test with denab bit forcibly disabled... all cases result in exactly the same render time so the d-cache emulation must be off/bypassed somewhere in UAE...