On 3/18/02 at 9:14 AM Tony Firshman wrote: >> a) 'Regular' memory is generally quite substantially faster >> than screen memory
> Wasn't it 30%? I forgot to answer this one - actually, it's closer to 50% when compared to true no-wait-state RAM on a standard QL. Things quickly get worse once any sort of 'accelerator' is fitted. For GC and SGC memory shadowing is used so only writes are generated into the screen RAM ($20000-$2FFFF if both screens are enabled). since the CPU is so much faster, the slow screen RAM appears that much slower - the efficiency is 12.5% for regular RAM writes for GC, and about 4% on SGC - reads proceed at full 100% in both cases. Based on the logic definitions for the GF, it is a bit more difficult to calculate because of extra tricks used, but for successive writes, the efficiency is 1% AT MOST running the QL end of things faster than standard - it is less than 0.5% on average. All of this is simultaneously better and worse for Aurora. Aurora video RAM accesses are nearly zero wait, so there is no speed penalty compared to _standard_QL_ - this means write efficiency for GC and SGC when accessing SCR0 and SCR1 addresses, is doubled. In theory, the increase could be fivefold if the GC/SGC were aware of there being an Aurora, and not thinking they are still running connected to a QL motherboard with a ZX8301 ULA on it. And that's the problem. When the extended resolutions/modes are used with SGC, it is not aware that the Aurora uses it's IO expansion area as screen memory. Because of this, the SGC does not use any memory shadowing for the extended screen memory and it performs reads from it as well as writes. As a consequence, operations with extended resolutions on Aurora are actually slower when a lot of reading is required from the screen memory, such as scroll/pan. While the write efficiency is increased from 4% to 8%, read efficiency is reduced from 100% for the shadowed SCR0 and SCR1 addresses, to 8%. This penalty would dissapear for the case of the drivers performing all their operations into the save areas. The screen sweep task is write only to the screen so there would be no more read penalty (write penalty unfortunately must remain) Low efficiency both for read and write would be completely unacceptable with GF, so it implements a few extra tricks, and a flexible shadowing mechanism. It also uses the full Aurora bandwidth (about 2.5x compared to an Aurora/SGC combo). Nevertheless, write efficiency still remains at 5% at most - the 68060 is just so fast! >> b) The address of the screen memory can really be anywhere, >> only the 'sweeper' task needs to know where. >How does the second screen concept fit into all this? Not directly, but it could. It would enable updates to be performed into the screen that is currently not visible, once done, the screens would be 'flipped' - this would prevent flicker or frame shear, but with a task devoted to screen updates, there are other mechanisms that can be used for the same effect. The independance of the actual screen address from the drivers is a great plus for any expansion of hardware or even adding extra features to emulators. The reason is simple - the original two screens are already at the bottom of usable memory and cannot expand without moving system variables up, which has already been proven to be a problem. Because of this, any new hardware has to be located in some kind of IO area above the highest usable RAM addresses. As RAM increases, these tend to move. For instance, on a regular QL, that's the top 256k out of the 1M address space ($C0000 and up). On SGC, there is 4M of RAM which means what used to be the IO area is now RAM, and the IO area is now the top 256k of the 5th megabyte, $4C0000 to $4FFFFF - signifficant because with an Aurora, this is used as the screen area. The same thing occurs on the Q40/60, but this time the screen has a dedicated area at very high addresses. On the GF even the original SCR0/1 and the ROM slot are moved up to very high addresses, which however depend on what shadowing and caching option is chosen for screen RAM. The move signifficantly simplifies logic and it alowes selectable caching, shadowing and serialization (nothing to do with serial ports!) options in the first place. With the new concept of screen drivers, the screen address changes in ONE place only, as do all the other parameters that would otherwise have to be changed in the drivers, and sometimes even in the applications. NAsta
