Slow RAM detection & JIT

[BlankVector]

I'm currently improving Slow RAM detection in EmuTOS with WinUAE 4.2.0 64-bit, and I suspect a WinUAE bug with JIT and cache.
Basically, presence of RAM is detected by writing a single LONG at the start of an address block, and reading it back.

I used the documentation below as reference:
https://www.amigacoding.com/index.php/Amiga_memory_map

Here is what I understood. Please correct me if I'm wrong.

- If present, Slow RAM starts at $00C00000.
- It normally ends at $00D80000, for a maximum of 1.5 MB.
- Some extension boards have a "Gary adapter" which adds additional 256 KB at the end, for a total of 1.75 MB (called "1.8 MB" by WinUAE). In such case, the Slow RAM ends at $00DC0000. As this overrides the Gayle IDE address space, this kind of extension is incompatible with the Gayle chip present in A600/A1200.

So if Gayle is not detected (A600 IDE and PCMCIA disabled in WinUAE), I try to detect Slow RAM up to $00DC0000 (exclusive). Typical setup is A4000 (no Gayle) + 1.5 MB of Slow RAM.

My problem occurs at address $00D80000 (just after the end of official 1.5 MB Slow RAM).
- With 68030 + instruction cache enabled by software + data cache disabled by software + more compatible + no-JIT: OK, no RAM is detected at $00D80000, as expected.
- With same setup but with JIT enabled, some RAM is detected at the very same address. I don't know how much, as I only test the first long word.
- With same setup, JIT enabled but instruction cache disabled by software, it works again.

So it seems there is a bug in WinUAE with the following configuration:
- 68030
- instruction cache enabled by software (CACR = $00000001)
- JIT

As there is no cache management in my RAM detection routine, the issue could come from the presence of data cache. But as data cache is disabled both in WinUAE settings and CACR, this should not happen. And there should be no difference between JIT and non-JIT.

I suspect some kind of incorrect correlation between instruction cache and data cache when JIT is enabled. Strangely this does not happen if I setup only 1MB of Slow RAM (ends at $00D00000).
Other possibility would be incorrect handling of $00D80000 address when JIT is enabled.

Any hint will be welcome.

Of course, I can provide a testcase if necessary.

[Toni Wilen]

Is is very simple reason: JIT does not like non-power of 2 memory regions.

It is still allowed because it mainly affects illegal accesses (outside the memory but inside if it would be power of 2) and KS ROM "slow ram" memory detection is run when caches are off, it is very early check.

[BlankVector]

Thanks for this explanation, Toni.
However, I still don't understand how 512 KB of Slow RAM is successfully detected with that very same setup, as the end address is $00C80000, which is still not a power of 2

EDIT: Maybe the size (not address) must be power of 2, not the address?

[BlankVector]

I solved that issue by adding proper data cache management in EmuTOS memory detection routine (flush/invalidate). Slow RAM is now detected as expected, in any case.
I still wonder if this is a robust fix or if it works by chance with WinUAE JIT.

[Toni Wilen]

Yes, size must be power of 2.

I wouldn't care too much, >1M "slow ram" ($c00000) is A500 only in real world. Use of JIT with A500 configs isn't recommend anyway, even if CPU is 68020+.

It probably is safe as long as JIT hasn't translated the memory test code yet = it is first RAM test after reset and RAM test checks it using 256k block size to keep it getting translated too soon. JIT only translates code if same code has been run at least 5 times (or more, I don't remember exact value).

EDIT: Only guaranteed way is to keep CPU instruction cache off. It also disables JIT.

[BlankVector]

Thanks for those precisions.

Originally Posted by Toni Wilen

EDIT: Only guaranteed way is to keep CPU instruction cache off. It also disables JIT.

Would it be OK to enable the instruction cache at startup, disable it before memory test, and re-enable it afterwards?

[Toni Wilen]

It probably is safest option but cache flush should be also enough if you can guarantee memory test code loops less than 5 times after cache flush

[BlankVector]

In the meantime, I found another workaround :

*p = testvalue;
call_any_function();
if (*p == testvalue) ...

It seems that a simple function call between write and read (even a simple jmp to rts) defeats the JIT and fixes the algorithm
(of course I checked the generated assembler code to avoid any C issue such as volatile, etc.)

As my actual function call is to flush/invalidate the data cache (which is supposed to be disabled, anyway), I cross my fingers and hope that it still continue to work reliably