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

[ Thread Index | Date Index | More Archives ]

Le 20/12/2016 à 17:10, Christian Zietz a écrit :
Christian Zietz schrieb:

During column addressing, the following happens:
A11 ... A20 -> CAS0 ... CAS9 (with 2 MiB),
A10 ... A18 -> CAS0 ... CAS8 (with 512 kiB),
A9 ... A16  -> CAS0 ... CAS7 (with 128 kiB).

This explains why you can see A9 on both RAS8 and CAS0 with 128 kiB
configuration. I'd have to recheck what happens to CAS8/CAS9 when 128
kiB or 512 kiB are set.

OK, found it: In 512 k mode, CAS9 interestingly is A19, in 128 k mode
CAS8 and CAS9 are A17 and A18, respectively. Hence, the mapping becomes:

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

Again, currently only checked for the IMP MMU.


using my method of analyzing the change in the pixels pattern on screen, I can confirm that I get the same bits mapping on my STF with non IMP MMU (ie bank0 can be != bank1).
SO, IMP and non IMP have the same bit mapping when changing bank sizes.

With that, I have now a version of Hatari that supports changing bank sizes and gives the same translation results as a real STF.

But I noticed another parameter that I have to hard code for now : when accessing bank 1, the CAS/RAS signal are not necessarily the same as when accesing bank0 for a similar location inside the bank, some kind of offset is added.

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 guess there some binary combination between logical address and bank sizes to get MAD signal and bank_sel signal (as I don't think the MMU really does some "<" comparisons), which might sometimes make addresses wrap at a different location than 0.


Mail converted by MHonArc 2.6.19+