Question about Aurora Memory Mapping.

[aalea]

I'm trying to understand how aurora graphics work, and if will be possible to implement in the QL Cores for FPGA.

But there is a think that I can't catch:

- Aurora has a 256Kb RAM in his board, of this 240Kb are used for Video Memory, the other 16Kb it's not clear, but I don't care by now.

- Aurora mirror (not alwais, depend on configuration) the $20000 and $280000 internal memory (the video memory) as write-only in this memory, I think interleaved.

- But I'm not able to understand is that indicate that this is mapping in the $4C0000 , this is about the position of the 19Mb of memory, far from the 2Mb or 4Mb of the super or gold card.

¿how is possible to access to this memory space? this memory is not available for goldcard, I think this is because goldcard tied A19 and A18 to 0V on the edge conector (acording to tetroid schematic) I do not have the supergold card schematic, but in any case the A20 - A24 lines of the 68020 are wired to the edge conector, so there is no way that Aurora know that the 68020 is accessing to this area of the memory to give acces to the memory chip.

What I'm missing? The only Idea is that SuperGold card maped this area as the top 256Kb of the fist megabyte (wiring QL's A19 to A24 and QL's A18 A21*A20) or something like this.

[tofro]

I'm trying to understand how aurora graphics work, and if will be possible to implement in the QL Cores for FPGA.

But there is a think that I can't catch:

- Aurora has a 256Kb RAM in his board, of this 240Kb are used for Video Memory, the other 16Kb it's not clear, but I don't care by now.

- Aurora mirror (not alwais, depend on configuration) the $20000 and $280000 internal memory (the video memory) as write-only in this memory, I think interleaved.

- But I'm not able to understand is that indicate that this is mapping in the $4C0000 , this is about the position of the 19Mb of memory, far from the 2Mb or 4Mb of the super or gold card.

¿how is possible to access to this memory space? this memory is not available for goldcard, I think this is because goldcard tied A19 and A18 to 0V on the edge conector (acording to tetroid schematic) I do not have the supergold card schematic, but in any case the A20 - A24 lines of the 68020 are wired to the edge conector, so there is no way that Aurora know that the 68020 is accessing to this area of the memory to give acces to the memory chip.

What I'm missing? The only Idea is that SuperGold card maped this area as the top 256Kb of the fist megabyte (wiring QL's A19 to A24 and QL's A18 A21*A20) or something like this.

That simply is internal to the SGC. The Aurora doesn't see (cannot, the address lines are not there) the "4" in the $4c0000 address (it sees $c0000). For the SGC CPLD, the "4" is the signal "needs to go to the expansion bus". Consider it that way: For the SGC, the QL system bus (i.e. what appears on the expansion connector) is not "the system bus", but rather an "I/O bus with limited address lines and some other added limitations - like A19=A18". The internal addresses are similar, but not the same on both buses. And whether an address on the 68020 bus goes to the expansion port or not, and if yes, how, is decided on the CPLD. For a normal QL expansion, the expansion is on the left, the "system" on the right. Once you put an SGC into the system, this is turned around (That is also true when you connect an SGC to the QL: The QL is then reduced to an I/O card).

[aalea]

What I'm missing? The only Idea is that SuperGold card maped this area as the top 256Kb of the fist megabyte (wiring QL's A19 to A24 and QL's A18 A21*A20) or something like this.

That simply is internal to the SGC. The Aurora doesn't see (cannot, the address lines are not there) the "4" in the $4c0000 address (it sees $c0000). For the SGC CPLD, the "4" is the signal "needs to go to the expansion bus". Consider it that way: For the SGC, the QL system bus (i.e. what appears on the expansion connector) is not "the system bus", but rather an "I/O bus with limited address lines and some other added limitations - like A19=A18". The internal addresses are similar, but not the same on both buses. And whether an address on the 68020 bus goes to the expansion port or not, and if yes, how, is decided on the CPLD. For a normal QL expansion, the expansion is on the left, the "system" on the right. Once you put an SGC into the system, this is turned around (That is also true when you connect an SGC to the QL: The QL is then reduced to an I/O card).

OK, so:
- A Gold Card has A18=A19=0 and, can access the first 256Kb of the QL as mapped on $400000
- A Super Gold Card has A18=A19=A18*A19 and, can access the first and last 256Kb, of the QL as mapped on $40000 and $4C0000

And this is the reason of that you shall configure the Qbide on $0C000, because this area is also mapped on 040C000. in GC and SGC.
And this is the reason of Aurora is located on $C0000, because this area is also mapped on 04C0000. and also the reason it's only available in SGC.

Is this Right? is the mapping on 256Kb blocks?

This arise me some questions:

- As aurora indcate that use only 240Kb, shall be posible to configure another interface (I was thinking on the QSOUND) as $FC000 so will be available to SGC as $4FC000 ?
or as $10000 as this area is empty, and available in GC and SGC.
- is Gold card accessing the I/O (ZX8301 and ZX8302, etc...) on the $418xxx memory I/O? or are also mapped in the original $018xxx address. (I suppouss yes, because of back-compatibility, but this is limited to the $018000 16Kb I/O, or more?

[Pr0f]

Think of the Aurora as being the same addresses as the QL has in the bottom part of the 1M memory map of a QL - notably ROM area, the QL I/O area and the 64K of video RAM that's in a standard QL AND also as having 240 K in the top 256K, but not in the 1M memory map - the A19=A18 line is actually used by the SGC to say - place it at the top 256K of the 1M of memory above $400000 e.g. $4C0000 - you will notice that the very last 16K is not decoded for the Aurora Video RAM, and so it is available for a 16K I/O card - such as Qubide.

When the SGC boots, it boots from it's own ROM, and then copies the contents of the QL's ROM to the RAM at $00000, and patches it, then after that's done, the original QL ROM is available at $400000.

There are some notes for the Aurora that explain how if you alter the Logic programming - the video RAM can use the full 256K, allowing some extension of video sizes.

Also note that the 64K of original QL video area is remapped into the Aurora Video RAM if the video mode and screen are selected - so access to the original QL video area will actually be written to the Aurora video RAM and generate a QL video screen.

With the Gold card (not super version) - the extended video modes are not supported, as there is no way to address them.

So just to add about I/O for SGC:

The original ROM slot area at $0C000 is available
The top most 16K at $4FC000 is also available

And for GC - only the area at $0C000 is available

[tofro]

So just to add about I/O for SGC:

The original ROM slot area at $0C000 is available
The top most 16K at $4FC000 is also available

And for GC - only the area at $0C000 is available

Writes to $20000 (where the original QL's screen used to live) will write to both the (S)GC memory (at $20000) and be re-mapped to $c0000 on the aurora to implement the original QL modes. Reads from those addresses will only access (S)GC memory (that basically holds a screen copy there).

[Nasta]

OK, let's see if I can clear this up a bit...

First, the Aurora was made for two reasons:
1) Make it possible to run a QL on a VGA monitor (since at that time monitors based on the TV standard were already getting scarce and expensive)
2) Add more resolutions and colors to the QL

The first part is done by making a new video controller from scratch, but the second is more complicated because more screen space and more colors require more RAM to hold the image data - and this has to be added externally. In total up to 256k of extra RAM must be added.
The problem here is that te maximum number of addresses available on the J1 expansion connector is 1M (1024k) and on a normal QL this holds everything, ROM, motherboard RAM, expansion RAM, any expansion boards such as floppy and IDE etc.
In other words, there is a shortage of available addresses.
The GC was the first widely available board to tackle this, together with adding a faster CPU. The way it does this is by using only those addresses on the J1 expansion connector that are connected with essential QL hardware on the motherboard - most of the stuff addressed on the GC (such as 2M of RAM) do not appear on the J1 connector at all.
In the case of the GC, only the ROM (initially), ROM slot, motherboard IO and screen RAM addresses are used, and in the case of the screen addresses, only for writing (the significance of this will become apparent later on).
While the original 68008 CPU can only has a total of 1M address range, the one on the GC has a 16M range, but only 2M was used, and none of the remaining 14M were available to the user, especially on the J1 connector, so this was kind of a missed opportunity on the GC, that was mode available on the SGC.
The SGC can also access the top 256k of addresses ($C0000..$FFFFF) on the J1 connector.
It is important to note that addresses on the J1 connector are not always the same as what the CPU on the SGC sees, in other words, there is a sort of 'address translation' from the CPU to external bus.
In the case of the SGC, it can access several addresses on the J1 conenctor, ROM and ROM slot, motherboard Io area, screen 0 and 1, and finally, what was originally specified as an IO expansion area, the top 256k, which appears on the J1 connector as $C0000..$FFFFF.
That being said, from the point of the SGC, this appears at $4C0000..$4FFFFF, hence this is where the Aurora video RAM can be seen by the SGC.
In order to also be compatible with the old screen areas at $20000 and $28000, part of the Aurora video RAM appears also at these addresses (these are the same from the point of the SGC as on the actual J1 connector). The Aurora actually does a similar thing to what the SGC does but in reverse, when accessed at he old QL screen areas, it re-maps this into it's video RAM so that the old scr0 accesses actually go to $4Cxxxx. This however only happens when mode 4 or 8 is selected, and only one way (old screen to new screen RAM), so it is used to test for Aurora presence in the driver - write a long word zero to $4C0000, then a long word with a key value to $20000, read long word from $4C000, if it is the key value, Aurora is present.

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

The way the Aurora screen RAM is displayed as an image on the screen depends on the mode chosen, and there are 4 in total. In the standard mode 4 or 8 the pixels map to bits in the video RAM the same as on the original QL except the size of the bitmap is 1024x1024 in mode 4, and 512x1024 in mode 8. In the 16 color mode (which was unfortunately never used), the bitmap is 1024x512, and in the 256 color mode it's 512x512. This always remains that way as far as the hardware capability goes. On top of that, the chosen resolution and the last 16k being reserved limit what is actually displayed. If the chosen resolution is smaller than the bitmap, then the requested resolution is positioned in the top lefthand corner of the bitmap. If the chosen resolution is larger than the bitmap, the resolution will be limited to the size of the bitmap, in either x or y direction as applicable. Also, because the last 16k of video RAM is reserved, the maximum usable size of the bitmaps is limited to 960 rows in modes 4 and 8, and 480 rows in modes 16 and 256.

Now back to how the original QL screen memory area is handled:
Aurora does not support the second screen option (scr1). This is because writes to the first screen (scr0) are remapped into the Aurora RAM so that it appears as a 512x256 (mode 4) or 256x256 (mode 8) pixel area in the top lefthand corner of the larger bitmap, but only if mode 4 or mode 8 is used. The problem is that under normal operation (no scr1) the RAM addresses used for scr1 are used as normal RAM, including a bunch of system data structures, so remapping writes into Aurora video RAM would corrupt the screen in any of the higher resolution or color modes.

It should be noted that the SGC does a lot of it's own tricks when the old scr0 or scr1 are accessed, in particular only writes to those addresses are done to the J1 connector so that the data ends up in the original motherboard RAM, for the 8301 ULA to display it on the screen. At the same time it is written to the same addresses in the SGC on-board RAM. It is only ever read (and MUCH faster) from the SGC on-board RAM. In fact, there is an option to switch off writing to scr1 if it is not used as it speeds up access to system data structures at those addresses, as the SGC does not have to wait for the slow write to old motherboard RAM to complete.
There are other tricks:
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, in fact the hardware would have been simpler if the full bottom 256k on J1 appeared at $40000..$43FFFF to the SGC with full read and write, as many interesting things could have been done, including being able to use re-writable flash ROMs instead of the original QL ROM or EPROm chips. Unfortunately, since the ROM can only be accessed for read, and there is no write function, there can be no writes to a flash chip that could be used instead of an EPROM.

[Popopo]

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, in fact the hardware would have been simpler if the full bottom 256k on J1 appeared at $40000..$43FFFF to the SGC with full read and write, as many interesting things could have been done, including being able to use re-writable flash ROMs instead of the original QL ROM or EPROm chips. Unfortunately, since the ROM can only be accessed for read, and there is no write function, there can be no writes to a flash chip that could be used instead of an EPROM.

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?

I guess (by what I understood now from you) the writing function doesn't allow to write in the ROM area, but... what if it would be possible using a loaded procedure into RAM for that purpose?
Imagine that the ROM is writeable as you described like EEPROM or another kind (I am doing it with RAM and I hope to publish it soon) it uses RAM instead ROM, who cares? QL doesn't. So since it is RAM it is writeable in RT. Crazy huh?

How could be that used to improve QL capabilities?
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!

[RalfR]

In the 16 color mode (which was unfortunately never used)...

If TT had written such a driver, we would also have 16 colours on the Atari TT without QVME, as the TT is able to show them in 640x480.

[Derek_Stewart]

In the 16 color mode (which was unfortunately never used)...

If TT had written such a driver, we would also have 16 colours on the Atari TT without QVME, as the TT is able to show them in 640x480.

Hi Ralf,

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

[tofro]

In the 16 color mode (which was unfortunately never used)...

If TT had written such a driver, we would also have 16 colours on the Atari TT without QVME, as the TT is able to show them in 640x480.

Hi Ralf,

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

Never, I think. There are drivers for the Emulators, but none for the native color resolutions (not for the ST, as its vertical resolution was considered too low, and not for the TT, because QVME.)