exxos's Atari, Amiga & retro forum

Icky and I have been puzzling over the MMU for some days now. I suggested trying my old MEGA 4 into because its the only one I knew which used a lot of rasters... And surprisingly this behaves perfectly correctly. So I wonder if the problem is literally down to full screen operation..

Troed's Closure demo fails to detect the wait states, but I have no idea why as I am not a demo coder... I can only possibly think it may be something to do with 50/60hz switching, but I really would assume all this is done by the GLUE anyway... I'm currently stabbing in the dark as to why the MMU would cause Closure to not detect waitstates :roll: Only as far as we can tell this it may well be the last hurdle to get our FPGA MMU working correctly.

Has anyone any ideas on this, or any programs we can test to see if it gives any clues or not ??

Does re-developing the MMU in FPGA allow you the opportunity to raise the limit on total ST memory? Or is it a straight across replacement due to scarcity?

TimNaber wrote: 14 Feb 2020 21:25 Does re-developing the MMU in FPGA allow you the opportunity to raise the limit on total ST memory? Or is it a straight across replacement due to scarcity?

All of the above, we want to run RAM at 32MHz.

exxos wrote: 14 Feb 2020 21:12 Has anyone any ideas on this, or any programs we can test to see if it gives any clues or not ??

Troed's wakestate detection program is open-source and it has some fairly detailed comments what it's checking: https://github.com/troed/WSDETECT/blob/ ... WSDETECT.S.

czietz wrote: 15 Feb 2020 11:19

exxos wrote: 14 Feb 2020 21:12 Has anyone any ideas on this, or any programs we can test to see if it gives any clues or not ??

Troed's wakestate detection program is open-source and it has some fairly detailed comments what it's checking: https://github.com/troed/WSDETECT/blob/ ... WSDETECT.S.

So, from what I can see the code is using NOP instructions for timing (i.e. a NOP instruction takes x clock cycles to perform, and hence y microseconds on an 8MHz 68000).

Almost all of the timing delays are not done by NOPs (they're actually commented out, see these "dcb.w N,$4e71" lines) but by DBF (=DBRA) loops. But in the end that does not matter. From a high-level perspective, what the code does is switching between color and mono or between 50 and 60 Hz at precise moments. This is why exact timing and, therefore, counting instruction cycles is important. Then the test program calculates the video line length, i.e. how many bytes the MMU transferred to the Shifter. From that, it can infer the wakestate.

@Icky did you try it in mono ? And even 60hz ? I think the diagnostic cart can do 50/60hz switch?

exxos wrote: 15 Feb 2020 13:44 @Icky did you try it in mono ? And even 60hz ? I think the diagnostic cart can do 50/60hz switch?

I haven't. Will give that a try.

Thanks to @Icky For fixing my FPGA MMU :thumbup: just got it plugged in and it booted right up.. Currently running GB6... tests so far showing 100% as expected..


EDIT: So annoyingly Closure does not seem to run on a 512K machine :(

After faffing about I get this far now "WS ?" And the bit planes are trashed... One a normal MMU it looks fine and I get "WS 4".


EDIT:

I power down the machine and rebooted, and now I get "WS 1" odd...


The third power cycle I get "WS ?" Without a phase shifting graphics..

It is hard to read the number when the bit planes are trashed, but I think it only ever goes into "WS1" or "WS ?". I don't ever remember seeing anything other than WS2 &WS4 on a real MMU... So I am wondering if something is simply "1 line out" with the video lines or something.