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

[Christian Zietz <czietz@xxxxxxx>]

Hello,

Nicolas Pomarède schrieb:

> Good news, this might be useful too for other project like MIST or 
> similar which try to re-build a complete STF/STE with VHDL and require a 
> low level description of each chip.

Here are the results of my reverse-engineering work of the MMU's bank
selection logic. This is for the non-IMP/Ricoh STF MMU. Note: It was
pointed out to me that while MMU chips labeled C025912-38 were made by
Ricoh, the manufacturer of the older MMU chips C025912-20 is not known.
The -20 version is found in the very first 520STs, afaik. I don't know
if the versions -38 and -20 differ on a functional level. The IMP MMU
C100109 will probably have a much simpler circuitry for bank selection
as it doesn't support different bank sizes. However, I have yet to have
a look at this part of the IMP MMU.

In the following paragraphs I'll describe how the MMU decides whether to
address memory bank 0 (with the signals /RAS0, /CAS0L, /CAS0H) or bank 1
(/RAS1, /CAS1L, /CAS1H) based on the CPU address bus (bits A21..A17) and
the contents of the memory configuration register at $FF8001 (bits
RS3..RS0).

For bank 0, the selection is easy. It only needs to take into account
the size of bank 0, obviously, i.e. the bits 3 and 2 in the MMU bank
size register. I'll call these bits RS3 and RS2.

An access to bank 0 is generated,

A.1. when RS3..2 = 10 (2 MiB bank size) and A21 = 0,
A.2. when RS3..2 = 01 (512 kiB) and A21..A19 = 000,
A.3. when RS3..2 = 00 (128 kiB) and A21..A17 = 00000.

This is exactly as expected, nothing special to note.


For bank 1, the selection logic is much more complicated. It takes into
account all nine (3 x 3) possible combinations of bank sizes -- and does
so correctly with one exception. Some of the cases overlap, but of
course it doesn't matter if more than one condition applies.

So, when is bank 1 accessed?

Let's start with bank 0 sized 2 MiB, i.e RS3..2 = 10:

B.1. RS1..0 = 00 (bank 1 = 128 kiB) and A21..A17 = 10000,
B.2. RS1..0 = 01 (bank 1 = 512 kiB) and A21..A19 = 100,
B.3. RS1..0 = 10 (bank 1 = 2MiB) and A21 = 1.

The cases where bank 0 is 128 kiB, i.e. RS3..2 = 00:

C.1. RS1..0 != 11 (all bank 1 sizes) and A21..A17 = 00001,
C.2. RS1..0 = 01 (bank 1 = 512 kiB) and either A21..A17 = 00100 or
A21..A18 = 0001,
C.3. RS1..0 = 10 (bank 1 = 2 MiB) and either A21..A17 = 10000 or
A21..A19 = 001 or A21..A20 = 01.

Finally the cases with bank 0 = 512 kiB, i.e. RS3..2 = 01:

D.1. RS1 = 0 (bank 1 = 128 or 512 kiB) and A21..A17 = 00100,
D.2. RS1 != RS0 (bank 1 = 512 kiB or 2 MiB) and A21..A19 = 001,
D.3. RS1..0 = 10 (bank 1 = 2 MiB) and either A21..A19 = 100 or A21..A20
= 01.


If you have a look at the configuration bank 0 = 128 kiB and bank 1 = 2
MiB, you can see that cases C.1. and C.3. apply. However, there is one
address range missing, A21..A18 = 0001, which corresponds to the "hole"
observed in the address map from $40000 to $7FFFF. All other
configurations are handled fine.

This doesn't look to me like a conscious decision not to support said
special memory configuration but more like an oversight. I can only
speculate, but maybe it wasn't deemed worthy to fix, given that this
special configuration wouldn't be used anyway. Later on, the possibility
of even having that configuration went away with the IMP MMU, anyway.

I hope that at least someone found this very technical text interesting.

Regards
Christian

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