I'm confused.. if the MMU is allocating 500ns to CPU, then 500ns to VIDEO Um, no. I said that there is a (potential) Shifter cycle every 500 ns. There's also a (potential) CPU cycle every 500 ns. But those two are intertwined; there is a RAM access every 250 ns. the shifter could only get data betw...

So, compared to the original MMU... a) the delays are too short and b) they seem to have 16 MHz clock granularity (272 ns - 216 ns ≈ 62.5 ns) instead of a 8 MHz (125 ns) one. c) Also, in the 68 ns delay shot, the first LOAD pulse is shortened. Most likely more than one issue remaining with the MMU r...

MMU loads data into the Shifter every 4 cycles (= 500 ns). There's no mechanism to synchronize Glue to the MMU's internal cycles.¹ Therefore, there are four different possible timings of Glue-generated signals (such as DE) in relation to the MMU-generated signals (such as LOAD). Troed et al. explain...

The important thing is that with an original MCU in the ST you can only ever have 3, 4, 5 or 6 cycles (@ 8 MHz clock = 125 ns) delay between DE and LOAD. Yes, the mapping of delay to the numbers WSn of the wake states is not logical, but it's like it is. In the end, the WSn designators are only arbi...

How about tackling this issue from a pure HW perspective, for a change? Another way to determine the wake state is measuring the delay between DE getting high and the first pulse on LOAD. The attached scope shots show examples for WS1 (750 ns, 6 cycles) and WS4 (500 ns, 4 cycles). See http://www.ata...

In very high-level terms, I explained what it does in this other thread: viewtopic.php?f=80&t=2478&start=10#p33642

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 preci...

exxos wrote: ↑

Fri Feb 14, 2020 9:12 pm

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.

I cannot explain it, then. What YAART checks when returning that error is that the screen memory is at the very upper end of RAM. I.e. that PHYSTOP = SCREENMEMORY + $8000. Your SYSINFO screenshot shows me that this is the case. Since you're the only person reporting this error so far, I'm pretty sur...

Be sure that nothing is started at boot: No accessories, no AUTO folder programs, no code from a floppy disk boot sector, preferably also no hard disk driver.