Re: [hatari-devel] test needed on a 4MB STF

[Christian Zietz <czietz@xxxxxxx>]

Nicolas Pomarède schrieb:

>  From an HW point of view, I don't know if the MMU doesn't generate any 
> RAM signal, I guess it's the case.

Unfortunately, due to other "obligations" during this time of year, my
Ataris have to be reassembled and stowed away soon. So, I can't do any
measurements on the MMU to confirm that indeed no signals are being
generated until next year.

> If RASx/CASxL/CASxH are not generated with the correct timing of the 
> "read cycle" chronogram for example (as detailed in the OKI 41256 
> datasheet), does it mean the ram modules doesn't change its previous 
> output state, which would mean the 16 RAM modules would keep their 
> latest Dout value ? (usually this is the last word prefetched by the 68000)

Without RAS/CAS the RAM chips won't drive the data bus; see the "read
cycle" diagram in the datasheet you mentioned. However, due to the
capacitance of the bus lines, these will keep their previous value for a
short while. So it's likely -- but not 100% guaranteed -- that the value
previously on the data lines will be read back in this case.

I guess this is what manifests itself as strange scrolling patterns in
your test program?

If so, then I also see the "hole" in the 40000 -> 80000 region on my STF
with the Ricoh MMU. I don't know how to reproduce your test case on the
STF with the IMP MMU, though, given that it doesn't support different
bank sizes between banks 0 and 1.

> Might be some bit combinations again that are supposed to work when we 
> go beyond total ram, but that triggers in some unexpected cases too.

Again, the circuitry inside the MMU that decides which bank is accessed
is very complex. Thus, it's hard to say, but probably it doesn't cover
all combinations of bank sizes properly.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA