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

[Christian Zietz <czietz@xxxxxxx>]

Nicolas Pomarède schrieb:

> Here's an example to make it clearer on my 1 MB STF :
> 
>   - I set bank0 to 128 k and bank1 to 128k ; if I read logical addresses 
> $20000, then I access bank1. But this won't return data at physical 
> address $0 inside bank1, this will return data at address bank1+$40000
> (press F1 and F4 in my test program and press 2 to go to address $20000)
> 
>   - other case : bank0=128k bank1=512k. Then if you read logical address 
> $20000, which should be again the 1st byte inside bank1, then this time 
> you get the result of address bank1+$20000
> (press F1 and F5 in my test program and press 2 to go to address $20000)
> 
> Do you have an explanation for this ? From what I see, we get these kind 
> of offsets when bank0 < bank1 and/or when bank0=128.

I think this can be fully explained by the mapping that I posted earlier
and that you then confirmed for the non-IMP MMU -- which is made by
Ricoh, BTW.

We have:

A1 ... A10  -> RAS0 ... RAS9 (always)
A11 ... A20 -> CAS0 ... CAS9 (with 2 MiB),
A10 ... A19 -> CAS0 ... CAS9 (with 512 kiB),
A9 ... A18  -> CAS0 ... CAS9 (with 128 kiB).

So, in the first case you access $20000, i.e. A17=1 and all other
address bits are 0. The MMU, based on bank 0 size determines that the
access should go to bank 1 -- thus generating the appropriate RAS and
CAS signals. Note, however, that the MMU does not subtract anything from
the address and it doesn't mask out unneeded address bits either. Hence,
during the bank 1 access CAS8 (corresponding to A17 in 128k mode) is
asserted. Had bank 1 been configured for 512k, CAS8 would have been
mapped from A18. A18=1 is offset $40000 into that bank, exactly what you
are observing.

In the second case, again A17=1, but bank 1 is configured for 512k mode,
so this maps to CAS7, which in fact is offset $20000 into that bank. Voilà.

I suppose, Atari never wanted to support configurations where there is
more memory in bank 1 than in bank 0, so they skimped on implementing
that properly. The whole address decoding is already very complex in the
Ricoh MMU as it is. I also guess this is the reason for removing support
for different bank sizes in the IMP MMU: simplifying the circuit and
maybe removing a critical path, timing-wise.

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