Re: [ql-users] Drawing in the save area (SMSQ improvement)
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 ($2-$2 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 ($C 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, $4C to $4F - 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
Re: [ql-users] Drawing in the save area (SMSQ improvement)
On Sun, 17 Mar 2002 at 18:17:21, ZN wrote: (ref: [EMAIL PROTECTED]) Joachim wrote: As I already mentioned, I am willing to volunteer for the following changes in SMSQ. - have all windows draw their contents in the save area - background update of windows (same mechanism) Ye! :-) In general I propose the following changes. - Application should not draw onscreen, but in the save area. When they properly use the iow.xtop call as exists at the moment, nothing needs to be done, except that the use of iow.xtop will no longer be necessary (the call now gives the address with the screen base, so that makes things easy). In practice the applications which work in extended resolutions will not need any changes. Exactly. Also, emulation for applications that need to use the original screen areas would actually be easyer to implement. They would effectively get one save area that just happened to be at $2. Further important side effects: a) 'Regular' memory is generally quite substantially faster than screen memory Wasn't it 30%? 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? ... sorry if you said but there was a _lot_ of text (8-)# It is a long time since I have seen this (now I use SGC) but if memory was short, TT used the visible screen area as a working area. Quite entertaining to watch. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname,demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Drawing in the save area (SMSQ improvement)
How does the second screen concept fit into all this? ... sorry if you said but there was a _lot_ of text (8-)# It is not considered. However, this could easily be emulted by swapping the save area for another one and setting all the changed flags. Question is, whatfor? Which program needs this? Also, I don't think it was supported by PE. Even more so, the second screen and swapping is normally used to have a screen drawing buffer which is not displayed to prevent flicker. As I propose you can disable update for a screen, this should never be a problem. Joachim
Re: [ql-users] Drawing in the save area (SMSQ improvement)
Joachim wrote: As I already mentioned, I am willing to volunteer for the following changes in SMSQ. - have all windows draw their contents in the save area - background update of windows (same mechanism) Ye! :-) In general I propose the following changes. - Application should not draw onscreen, but in the save area. When they properly use the iow.xtop call as exists at the moment, nothing needs to be done, except that the use of iow.xtop will no longer be necessary (the call now gives the address with the screen base, so that makes things easy). In practice the applications which work in extended resolutions will not need any changes. Exactly. Also, emulation for applications that need to use the original screen areas would actually be easyer to implement. They would effectively get one save area that just happened to be at $2. Further important side effects: a) 'Regular' memory is generally quite substantially faster than screen memory b) The address of the screen memory can really be anywhere, only the 'sweeper' task needs to know where. - When switching jobs, the picture on screen does not have to be copied to the save area. But it has to be copied from the save area to the screen. This does make things slower but also FAR more flexible. The most important side effect is that the actual hardware organization of the screen doesn't need to have anything in common with the format of the save area - although of course, if it does, it can make things a bit faster. The great advantage is that: c) Applications can be written to be compatible across platforms regardless of the actual hardware - even using modes that do not yet exist in hardwre d) Extra operations can be performed when a save area is copied to the actual screen, such as palette operations to convert shalower color depth save areas to a deeper screen, or dithering to convert a deeper save area to a shallower screen - A scheduler task needs to be written. This should run through the window pile and for all windows check whether the contents has changed, and update the lines where the changes took place. In principle it should be straightforward to write the routines which does this under the assumption that everything needs to be updated. The drawing routines should be adjusted to set a bit to mark the line in the save area which has changed. (Optionally, it might also be good to mark the save area as changed.) If these bits are stored in a separate vector, they could be tested using 32 rows at once and consume little extra memory. Even for huge windows there would hardly be a problem with the memory requirement as only one bit is needed for every row. In fact, the concept could be extended to 'tiles' instead of rows. Dividing the save area into fixed size tiles which can actually be quite large, can already substantially speed up things at next to no cost in additional data structures that keep track of what has changed. However, one has to keep in mind that the maximum number of pixels that ever needs to be updated by the 'sweeper' is the number of the pixels on the screen. At a later stage, this approach could be extended to allow save areas to have a shallower bit depth than the screen, thus saving even more memory. I think this is quite important even at an earlyer stage, simply because variable depth save areas mean variable save area 'mode', which in turn provides rather desireable 'device independence'. To make programs run on other platform, of course the required mode drivers have to be present - but this is easy if they already exist on other platforms! - and the real difference is only really in the 'sweeper' task, which has to convert the mode of the save area into the actual screen mode. I should point out that these changes will eventually have to be reflected in the UI (PE). For instance, there is no reason why a program should not use a save area larger than the screen, or one that is partially 'off-screen'. Managing windows with these and many other properties (palette, color conversion...) is not present in the UI yet - in fact, it could be left entirely to the UI and not be something for the application to manage. Nasta
