home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 25 / AACD 25.iso / AACD / Utilities / FScreen / FScreen.doc < prev    next >
Encoding:
Text File  |  2001-05-12  |  10.4 KB  |  254 lines
  1.  
  2.  
  3.  
  4. Requirements
  5. ------------
  6.  
  7.   - 020+
  8.  
  9.   - v39/OS3.0+
  10.  
  11.   - a blitter free gfx system (FBlit(v3.77+), CGX, P96(perhaps))
  12.  
  13.   - an RTG icon system was required with previous version, but probably
  14.     isn't strictly necessary anymore.
  15.  
  16.   - mmu.library v42+ for MMU support (MuGuardianAngel v40.41+ if you want
  17.     to use MGA with FScreen)
  18.  
  19.   - fast RAM (lots!)
  20.  
  21.  
  22.  
  23.  
  24. Installation
  25. ------------
  26.  
  27.  Launch FScreen with 'run' some time after FBlit has been installed eg.
  28.  
  29.  'run >nil: FScreen lace delay=2 noscan'
  30.  
  31.  If you use FBlit, it will require some reconfiguration. You must use the
  32. QBSBlitPatch and un-install the Add/RemIBobPatch pair. Un-installing
  33. OSTLPatch is probably a good idea as well.
  34.  
  35.  As of v0.21 of FScreen, you no longer need to set FBlit's FAllocBitMap
  36. patch to promote displayable bitmaps, FScreen will install it's own patch
  37. to do this job. FAllocBitMap is still required to promote non-displayable
  38. bitmaps though, for now at least.
  39.  
  40.  Note: currently there is no way to stop FScreen installing it's own
  41. Alloc/FreeBitMap() patches, and there is no per-task promotion. All
  42. screens will be forced into fast RAM while FScreen is running.
  43.  
  44.  
  45.  
  46.  
  47. Options
  48. -------
  49.  
  50.  By default FScreen will use a simple refresh mode with a delay of 3/50s
  51. between cycles and the LoadView() patch installed. If requirements for
  52. MMU use are met, MMU assisted refresh will be used.
  53.  
  54.  
  55.  PRIORITY=  sets the priority of FScreen (and the refresh ATM), this
  56.             defaults to 20.
  57.  
  58.  NOLVPATCH  stops FScreen installing the LoadView() patch. This patch is
  59.             only needed for cosmetic reasons. Using this switch will just
  60.             make the display turn to garbage more often.
  61.  
  62.  DELAY=     sets the delay between refresh cycles. The actual refresh rate
  63.             depends on this value plus the time it takes to do the refresh
  64.             operation. Setting this to 0 isn't a good idea.
  65.  
  66.  LACE       makes FScreen do interlaced refresh cycles. This is twice as
  67.             fast but causes significant visual disturbance. It's only 
  68.             really usable with 'DELAY=1'. If the MMU is being used, this
  69.             switch is ignored, but it's still usefull to specify it in
  70.             case MMU cfg fails.
  71.  
  72.  NOMMU      stops FScreen from using the MMU.
  73.  
  74.  NODELTA    stops FScreen from allocating delta buffers for the display.
  75.             Setting this isn't recommended since it will slow the refresh
  76.             operation down significantly. 
  77.  
  78.  NOSCAN     stops the periodic copper scan, in which case all displays
  79.             are based purely on the results of the LoadView() patch. If
  80.             you specify both this and 'NOLVPATCH', you will have a
  81.             permanently garbage display so best not to bother really ;)
  82.  
  83.  NOASM      stops FScreen using it's assembler delta refresh code. This
  84.             is just for test purposes.
  85.  
  86.  
  87.  FScreen can be terminated with CTRL_C/break. Or it could, with v0.21 it
  88. is unsafe to quit FScreen if there are any fast RAM screens open. In that
  89. case, the system will crash whenever a fast RAM screen closes.
  90.  
  91.  
  92.  
  93. Bugs & Features
  94. ---------------
  95.  
  96.   - ATM FScreen doesn't know when bitmaps are freed, and can end up
  97.     refreshing non-existant source planes for a short time, causing a
  98.     stream of hits under MGA when screens close.
  99.     (shouldn't happen with v0.21+)
  100.  
  101.   - programmes which save the copper list, and later re-install it, may
  102.     cause refreshed screens to appear 'frozen'/corrupt. This is because
  103.     FScreen will free the chip planes as soon as they are no longer
  104.     present in the active copper list. When the old copper list is re-
  105.     installed, it will still contain pointers to these old chip plane
  106.     structures, which may still hold the old image data, or may be
  107.     more or less corrupt, and, since the copper list contains pointers to
  108.     chip memory, FScreen will not create new planes for the display.
  109.     Swapping screens (or attempting to) will cause a copper list rebuild,
  110.     and refresh will re-start.
  111.  
  112.   - OS double buffering doesn't work (it's corrupt). Best theory for this
  113.     ATM is that screen buffers aren't actually refered to by bitmap
  114.     structures in intuibase/ViewLord (or gfxbase/ActiView).
  115.  
  116.     Interestingly (or not), double buffering almost sort of half works
  117.     when using the 'NOSCAN' switch.
  118.  
  119.   - swapping screens in MMU mode, with MGA active, will crash the system
  120.     pretty quick. (fixed in the latest versions of MGA (40.41))
  121.  
  122.   - garbage displays will occur for a short time whenever a new screen
  123.     becomes visible, and at other times if the LV patch isn't installed.
  124.  
  125.   - in MMU mode certain rendering operations will not be detected and
  126.     won't appear on the visible display (except by accident). This will
  127.     include any rendering done by DMA devices (unlikely), and any
  128.     rendering done by the PPC. Nothing much can be done about that, but
  129.     there is currently another class of undetectable rendering which will
  130.     get fixed at some point.. Rendering done in supervisor mode won't be
  131.     detected (fix this in FScreen). Rendering done from a private MMU
  132.     context will work until the display changes, then it will fail
  133.     (requires a new mmu.library).
  134.  
  135.   - if an MMU assisted screen is closed, and re-opened again quickly, it
  136.     is possible for MMU cfg to fail, in which case the screen will revert
  137.     to 'normal' refresh mode (and kill system performance). Swapping 
  138.     screens again will usually get the screen back using MMU mode. Since
  139.     FScreen doesn't know when a screen closes, the associated MMU cfg may
  140.     linger for some time. During this period another screen may have been
  141.     created using some of the address range covered by the old MMU cfg,
  142.     and in this case it will be impossible to configure the MMU for the
  143.     new screen (until the old one has been freed by FScreen).
  144.  
  145.     There are other issues related to this eg. if a lot of screens are
  146.     opened and closed in a short period, chip RAM may run out. And, it is
  147.     also possible for two planes to cover the same source address range,
  148.     which can cause the wrong plane (ie. one that has been freed) to be
  149.     re-inserted in the copper list and maintained active by FScreen.
  150.     (most of this stuff should be obsolete with v0.21+, but running out 
  151.     of chip memory is still possible (indeed, more likely))
  152.  
  153.   - due to the high priority of FScreen, it can occassionally give the
  154.     impression of locking up the system for short periods, especially
  155.     when swapping screens. In the case of PPaint, this pause can include
  156.     freezing the mouse pointer, but that appears to be an exceptional case
  157.     (ClaontoScreenManager<sp> is up to some funny business I guess..)
  158.  
  159.   - since FScreen runs as a normal task, the refresh operation will cease
  160.     whenever multi-tasking is suspended (or a higher priotity task hogs
  161.     the system), effectively freezing the display until normal task
  162.     switching resumes.
  163.  
  164.  
  165.  
  166. What Happened Before
  167. --------------------
  168.  
  169. v0.21
  170. -----
  171.   - plane list access arbitration changed again. All access is done under
  172.     Forbid() (alse rewrote various functions to minimize access times).
  173.   - MMUPlaneSetUp() is no longer called from AddPlaneListElement(), which
  174.     allows LVPatch to safely(perhaps) create new planes. It is currently
  175.     called from RefreshPlanes().
  176.   - newly allocated chip planes are no longer cleared. Instead, screen
  177.     data is copied directly to the chip planes/delta buffer.
  178.   - FindPlanesBMP() now accepts the View it will search as a parameter, in
  179.     the case of LVPatch this is the View supplied to LoadView(), which
  180.     could spell trouble if a dummy View is used.
  181.   - Add/RemPlaneListElement() have become Alloc/FreePlaneListElement() ie.
  182.     they don't deal with lists anymore.
  183.   - cleared up some inconsistencies in the function prototypes!?
  184.   - added a new argument 'NOSCAN' which stops periodic copper list scans.
  185.     (also played about with stopping the periodic CleanUpPlanesList() call
  186.     but had to give up on that due to the PPaint related mouse lock up).
  187.   - all MMU assisted planes to be freed are now dealt with in one go ie.
  188.     with a single call to RebuildTree().
  189.   - rewrote pretty much everything that hadn't been re-written already.
  190.   - removed the 'scan' behaviour from LV patch.
  191.   - main loop is now halted during execution of FindFastPlanes() partly to
  192.     avoid the possibility of CleanUpPlanesList() running multiple times
  193.     before FFP() has finished, culling planes that are required later, and
  194.     partly to avoid refreshing at rather nonsensical times, making FFP()
  195.     even slower than it already is.
  196.   - added Alloc/FreeBitMap() patches and bitmap tracking
  197.   - rewrote everything again to deal with the above change, but this is
  198.     all in an intermediate state and will probably get re-written again to
  199.     remove the base planes list etc.
  200.   - added asm delta refresh routine
  201.   - added 'NOASM' switch
  202.  
  203.  
  204. v0.20
  205. -----
  206.   - changed LV patch function to use supplied gfxbase in a6...
  207.   - fixed the CleanUpPlanesList() using mln_Succ instead of mln_Pred after
  208.     removing elements bug (again ;) (thanks to Thomas)
  209.  
  210.  
  211. v0.19
  212. -----
  213.   - switched to sensei's 0.18 source
  214.   - removed context locking from MMU refresh code
  215.   - removed non-cacheable memory cfg for descriptors array
  216.   - modified copper list plane pointer to parent plane/bitmap conversion
  217.     stuff, so that cpr pointers with a -2 offset can be recognized
  218.  
  219.  
  220. v0.18
  221. -----
  222.   - changed MMU refresh code again. The refresh itself is defered so that
  223.     the MMU context isn't locked during the entire refresh cycle. (until
  224.     it becomes clear wether it is actually necessary to lock the context
  225.     for Get/SetIndirect() in the first place..)
  226.  
  227.  
  228. v0.17
  229. -----
  230.   - integrated sensei's re-coded/portable implementation of v0.14.
  231.   - changed LVPatch to use 'scan' instead of signal.
  232.   - cleanup/scan code, CleanUpPlanes() moved after FindFastPlanes().
  233.   - refresh code rewritten some more, and dragged in MMUPlaneSetUp() as
  234.     well this time. C part is finished (barring bugs), but delta(asm)
  235.     code isn't written yet.
  236.   - AccessPlaneList() rewritten for no reason.
  237.  
  238.  
  239. v0.16
  240. -----
  241.   - LVpatch now signals FScreen on copper changes (triggers cleanup/scan).
  242.   - cleanup/scan code, FindFastPlanes() is called half as often.
  243.   - refresh code (C and asm) completely rewritten to use 'nice' descriptor
  244.     access, and to make it suck a bit less (slower though, of course ;)
  245.     <unfinished> 
  246.  
  247.  
  248. v0.15
  249. -----
  250.   - mmu.library is no longer opened if NOMMU switch is specified.
  251.   - redesigned to allow MMU assist of completely non-aligned planes.
  252.   - cleanup/scan code, added activiewcpr semaphore lock.
  253.  
  254.