A bit more memory

[olivier.jan]

Sorry if this post is a bit naive, I’m not too familiar with the ST chipset.
I’ve always wanted to get a little more memory on the ST to experiment with Mint and other kind of memory hungry software.

I was wondering, as there is a 16MB SIMM on the H5, how difficult it would be to use a bit more of this memory.

So far, I can see 2 options but it seems “too simple” to be the right solutions.
Both options would be based on interception of A20-A23 and modifying MAD10 depending on these addresses if it’s within the 0x400000 - 0xCFFFFF.
So by grabbing the address lines + AS + CAS + RAS and changing MAD10, extra RAM would be available, but from the MMU point of view, there would only be 4MB.
I mentioned 2 options as I don’t know how the GLUE would behave with such setup.
If it’s fine for the GLUE, then it’s a very simple setup and we even have DTACK generated for us.
If on the other hand, the GLUE is not happy with addresses in this range (I seem to remember that it tends to throw BERR if an address in this range is addressed), then I would need a small interposer board under the CPU and “hide” these Address lines when needed, so the GLUE will also think we’re in the 0-4Mb address space (and gently generate DTACK too).
Both solutions sounds too simple to be true, what did I miss ?

[exxos]

There is a circuit floating around that's supposed to give you more ram but I don't know if it was ever tried. But seemed a lot of effort and hacking about. Likey will still have DMA issues like using TTram does as well.

Generally it's why things like the ST536 exist as it gives you 64MB RAM.

Alternatively, just wait for the FPGA replacement we are working on as it will give you like 14MB ST RAM.

The Phoenix Platform is designed to not need massive amounts of hacks on everything. We are replacing the GLUE and MMU with better ones which solve all the shortfalls of the original ST chips.

[ijor]

No, it is not that simple. I can't elaborate here about all the issues related to this. Some things I don't remember exactly without double checking, and I'm afraid I don't have the time right now for this. I will just clear up some basic concepts.

GLUE doesn't generate DTACK for any RAM access. I don't know why people think that GLUE is the universal DTACK generator. It is not. GLUE generates DTACK only when accessing GLUE itself, or when accessing devices that can't generate their own DTACK, like ROM or the PSG. For a RAM access, MMU is the one that asserts DTACK; and at the right time, that is only known by MMU.

For the same reason, GLUE doesn't (automatically) assert BERR for any address at all. GLUE asserts BERR as a result of a timeout condition. If GLUE detects that AS is asserted for 32 consecutive cycles, it asserts BERR. Otherwise it would be very complicated to add new devices to the main bus.

GLUE does provide the RAM signal to MMU. This is the way that MMU "knows" that this is a RAM bus cycle. The RAM signal is asserted for all valid RAM accesses. Any access outside the 4MB range is not considered RAM and GLUE will not assert the RAM signal.

[olivier.jan]

Thanks for your answers, it’s much clearer now. As I wrote it was too simple to be true.
I did some further reading and understood the mistake: doing it that way would present the extra RAM as ST RAM, but with the MMU only able to see 4MB, this would cause all kind of issues with DMA related access.
Unless you had a lot of logic to handle DMA counters etc, which makes it a more complex mod.
So, yes better wait for a new MMU design or add an accelerator with ALT-RAM.

[frank.lukas]

Richter Distributor and DIGISHOP from Vienna or Martin Wevelsiep had 14MB-15MB real ST Ram extensions back in these days ...

The Wevelsiep extension works in such a way that it manages 8 individual 2MB RAM banks for the standard Atari ST MMU.



ST Version ...

Martin Wevelsiep 16MB ST Ram.jpg

MegaSTE Version (10MB max) ...

Erweiterung_totale.jpg

laeuft.jpeg