HYPERRAM broken after mega65r4-bringup merge

[lydon42]

test_585 fails with the latest development builds. development#19 is the last build the test succeeds.

This seems only to affect fine access (32bit addr lda/sta/cmp), DMA based copies seem to be unaffected.

[lydon42]

I made some tests with non-linear write/cmps. They can be found in test_710 (tools development branch).

This show some curious results, as only testing the first bytes of $8000000 will fail:

[lydon42]

Added a bitmask as result, showing which of the 8 bytes at the location have failed the cmp. Result is that for $8000000 every even address fails (AA is %10101010, each set bit represents on of the 8 addresses failed):

[lydon42]

Using s777d7fe 30 makes the test work, doing s777d7fe 31 makes it fail again. GS $D7FE.0 CPU:PREFETCH Enable expansion RAM pre-fetch logic This maps to slow_prefetch_enable

[lydon42]

Some additional tests with changing addresses: shows that it only is an issue in the first 8 byte of hyperram. Also does not shift with every address...

[lydon42]

Invalidating slow_fetch_enabled for the first cache line does remove the problem, but it seems more like a hack than a solution to me. The actual problem must be deeper in the code...

diff --git a/src/vhdl/gs4510.vhdl b/src/vhdl/gs4510.vhdl
index 8f40dd5b..4cb7685a 100644
--- a/src/vhdl/gs4510.vhdl
+++ b/src/vhdl/gs4510.vhdl
@@ -2397,7 +2397,8 @@ begin
               slowram_cache_line_dec_toggle_int <= not slowram_cache_line_dec_toggle_int;
             end if;
           end if;
-        elsif long_address(26 downto 0) = slow_prefetched_address and slow_prefetch_enable='1' then
+        elsif long_address(26 downto 0) = slow_prefetched_address and slow_prefetch_enable='1'
+          and long_address(26 downto 3) /= 0 then
           -- If the slow device interface has correctly guessed the next address
           -- we want to read from, then use the presented value, and tell the slow
           -- RAM that we used it, so that it can get the next one ready for us.

[lydon42]

test_585 and test_710 confirm that this is fixed in latest development.