Question about Aurora Memory Mapping.

[RalfR]

I know Tony Tebby wrote an Atari High Resolution mono screen driver, for Atari ST, but do you know if the Colour verdion existed?

As Tofro said, there is no one. I think, because the QVME was developed in the first place for the STE, also usable with the TT. Aurora was far away in these days and for the TT you had to buy the Monochrome driver with SMSQ/E.

Now, SMSQE.PRG contains the monochrome driver, otherwise you wouldn't see anything on TT and Hatari.

In theory, you can modify some of the other colour driver for use in a graphics card like the "Crazy Dots" or "SANG Megavision 300". But who has these cards and who would modify the driver.....

[aalea]

Thanks Your so much Nasta (and other) for the aditional information, now I understand clearly how the memory is accesses in Aurora (and GC/SGC).

Only one doubth:

When Aurora is used with SGC, the whole 256k of it's video RAM can be accessed (on SGC this is $4C0000 to $4FFFFF) but the video circuits are limited to displaying data within the first 240k, by the programming of the SCAN EPROM on the Aurora.
The reason the last 16k is left unused is that once the Aurora is present, expansion by any other hardware would be limited to the same as on the GC, which is essentially the ROM port, so the last 16k is available for something like a QUBIDE. If it is installed (and it's jumpers set to $FC000 - to the SGC this will look like $CFC000), it will disable the last 16k of the Aurora video RAM and take those addresses for itself.
One side effect of the last 16k being available as RAM if no expansion card has taken that space, is that you could load an expansion ROM image into those addresses, and after resetting the QL, it will still remain there and will be recognized as a ROM

I understand that this (the last 16K being available as RAM) is after mod the aurora, as Prof indicate, that there are notes on how to do this.

For a brand new Aurora, is only 240Kb, right? I can not found any reference to this in the Aurora Manual, or hardware detail documents, or any about this last 16Kb.

[Nasta]

SGC does reads and writes on J1 to the motherboard IO area at addresses $18000..$1BFFF, only reads to the ROM slot addresses at $C000..$FFFF, and the entire ROM area at $0000..$FFFF (as appears on J1) appears once more as $400000..$40FFFF to the SGC but read-only. That last one is a damn shame...

Thank you a lot for such a detailed information.
Nasta, I'm working in something very particular that is related with it.
If you could write in ROM area, that would be interesting for other projects?
...Does this limitation comes from the own OS (ROM) ? cause if it is due a const, it may be changed to accept the whole rank editing the code of the ROM, is it too naive from me to consider that idea?

Thanks a lot!

The SGC simply does not let writes to the ROM area appear on the bus, which means no write signal and no write data, so nothing on the bus could know that something has to be written.
Otherwise, having the ROM area writeable could be used in a few different ways but keep in mind that the _actual_ ROM addresses ($0000..$FFFF) from the standpoint of the SGC processor, is actually in SGC RAM, either having been copied from the actual ROM chip(s) or loaded from some media (like when loading SMSQ/E). The actual ROM chip can always be read at $400000..$40FFFF (this includes the ROM slot), but only read. These addresses appear the same as the original ROM addresses on the J1 connector. If writing was enabled, the ROM would not respond of course, but additional hardware could disable the motherboard ROM and replace it with something writeable. Alas, write does not even appear on the bus.

[Nasta]

Thanks Your so much Nasta (and other) for the aditional information, now I understand clearly how the memory is accesses in Aurora (and GC/SGC).

Only one doubth:

When Aurora is used with SGC, the whole 256k of it's video RAM can be accessed (on SGC this is $4C0000 to $4FFFFF) but the video circuits are limited to displaying data within the first 240k, by the programming of the SCAN EPROM on the Aurora.
The reason the last 16k is left unused is that once the Aurora is present, expansion by any other hardware would be limited to the same as on the GC, which is essentially the ROM port, so the last 16k is available for something like a QUBIDE. If it is installed (and it's jumpers set to $FC000 - to the SGC this will look like $CFC000), it will disable the last 16k of the Aurora video RAM and take those addresses for itself.
One side effect of the last 16k being available as RAM if no expansion card has taken that space, is that you could load an expansion ROM image into those addresses, and after resetting the QL, it will still remain there and will be recognized as a ROM

I understand that this (the last 16K being available as RAM) is after mod the aurora, as Prof indicate, that there are notes on how to do this.

For a brand new Aurora, is only 240Kb, right? I can not found any reference to this in the Aurora Manual, or hardware detail documents, or any about this last 16Kb.

As far as I remember, when an Aurora is used, the whole 256k shows as RAM to the SGC CPU, in that you can write data and it will retain it so you can read it back. But the video hardware is configured not to show this on the screen.
However, Aurora still follows the decoding scheme the original motherboard does, if some address it is using is required by an external hardware, the /DSMC signal has to be pulled high by the external hardware when that address is detected, and the Aurora will not respond, so the external hardware can instead. Since Qubide is 'external hardware', when set to the top 16k, it will replace the top 16k of the 256k with it's own hardware, so 240k will still remain for all the supported resolutions to be displayed.