home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / NDK / NDK_1.3 / Read-Me1.3 / A2024Docs / A2024 < prev    next >
Encoding:
Text File  |  1988-02-11  |  14.0 KB  |  359 lines
  1.  
  2.  
  3.  
  4.               FUNCTIONAL SPECIFICATION AND PROGRAMMERS' REFERENCE
  5.                         PRELIMINARY: CONTENTS MAY CHANGE
  6.                      Copyright 1988, Commodore-Amiga, Inc.
  7.                                 January 7, 1988
  8.  
  9.  
  10.           1.  OVERVIEW
  11.  
  12.           The A2024 Monitor is a grayscale display device.  It con-
  13.           tains a frame buffer which can accumulate and display video
  14.           data from an Amiga RGB port in several ways.
  15.  
  16.           In its "normal" operation mode, it will "deinterlace" an
  17.           interlaced Amiga display.  Thus a four-hundred line inter-
  18.           laced display will be presented non-interlaced, and without
  19.           the corresponding flicker.  It can present up to 8 discern-
  20.           able gray scales in normal mode.
  21.  
  22.           In its "extended" modes, the A2024 assembles several frames
  23.           of data from the Amiga into a display larger than the Amiga
  24.           is normally capable of generating.  Displays of 1008x800
  25.           pixels of two or four gray levels are supported.  PAL sys-
  26.           tems may support slightly taller displays.
  27.  
  28.           The remainder of this document presents more information on
  29.           the characteristics of the device and its use.  This prelim-
  30.           inary version will be a little heavier on the "what" rather
  31.           than the "how." A revision with more procedural detail will
  32.           accompany the first beta release of the software provided
  33.           with prototype hardware.
  34.  
  35.  
  36.           2.  A2024 EXTENDED MODES
  37.  
  38.           The two extended modes we support are "15 Hertz" and "10
  39.           Hertz" modes.
  40.  
  41.           In normal operation, the Amiga sends out 60 frames (fields)
  42.           of video data, typically 200 lines high, every second.
  43.  
  44.           In "15 Hertz" mode, four different frames are sent alterna-
  45.           tively, and the A2024 assembles them into a large image.
  46.           This results in a complete update of the A2024 frame buffer
  47.           fifteen times a second.  To accomplish this output, the
  48.           Amiga video hardware runs in its "hi-res" mode, presenting
  49.           data equivalent to a four bitplane display.  This requires
  50.           using considerable display DMA bandwidth and causes serious
  51.           performance penalties, particularly to memory operations in
  52.  
  53.  
  54.  
  55.                                 January 7, 1988
  56.  
  57.  
  58.  
  59.  
  60.  
  61.                                      - 2 -
  62.  
  63.  
  64.           Chip RAM.
  65.  
  66.           In "10 Hertz" mode, the display is presented in six pieces,
  67.           with a complete update ten times a second.  This is
  68.           equivalent, from a video bandwidth point of view, to a four
  69.           bitplane "low-res" display.  This rate supports uncontested
  70.           access to Chip RAM by the processor.
  71.  
  72.           The communication of operating mode from the Amiga to the
  73.           A2024 is done in the vertical overscan, just before top of
  74.           each (Amiga) frame, by short bursts of color.
  75.  
  76.  
  77.           3.  PROGRAMMERS' MODEL
  78.  
  79.           The graphics programmer need not be concerned with the
  80.           patchwork way that displays are being generated, because the
  81.           system preserves the basic programmers' model.
  82.  
  83.           A Screen (or ViewPort) for display in an A2024 extended mode
  84.           uses a contiguous 1008x800 raster.  Normal rendering and
  85.           blitter operations apply.  There is nothing new about a
  86.           large RastPort.
  87.  
  88.           We support both Custom Screens and the Workbench Screens in
  89.           A2024 extended modes.
  90.  
  91.           Mapping from RGB color scheme to grayscales is provided, and
  92.           may be accessed via the standard SetRGB4() graphics func-
  93.           tion.  For extended modes, the mapping function follows.
  94.           The values R, G, and B may be from 0 to 15, and the output
  95.           is a number from 0 (black) to 3 (white).
  96.  
  97.           The function is:
  98.               Gray Level = (77 * R + 150 * G + 29 * B + 128)/1024
  99.  
  100.           Several features of the Amiga graphics and animation
  101.           hardware do not operate normally, however.
  102.  
  103.           -    User Copper Lists will be merged in and executed for
  104.                each (of four or six) panels as they are sent out of
  105.                the Amiga.  Normal copper operations, such as loading
  106.                the color table or modifying the display control regis-
  107.                ters could cause visual problems.  We cannot envision a
  108.                desirable, supportable purpose of User Copper Lists so
  109.                their use is not presently supported, yet it is not
  110.                prevented.
  111.  
  112.  
  113.  
  114.  
  115.                                 January 7, 1988
  116.  
  117.  
  118.  
  119.  
  120.  
  121.                                      - 3 -
  122.  
  123.  
  124.           -    Simple Sprite 0 is available and used in its standard
  125.                way.  Other sprites, and attached sprites, are not sup-
  126.                ported.  Since Intuition uses SimpleSprite 0 for its
  127.                pointer, the functions SetPointer()/ClearPointer()
  128.                operate normally.  The color mapping for the sprite is
  129.                the same as earlier described.
  130.  
  131.           -    Beam synchonization via WaitTOF(), and QBSBlit() will
  132.                trigger relative to one of the four (15 Hz) or six (10
  133.                Hz) panels.  Thus the functions operate, but are not
  134.                suitably synchronized.
  135.  
  136.                WaitBOVP() will return at the completion of the current
  137.                display portion, and so is not suitable for use for
  138.                synchronization in an A2024 extended ViewPort.
  139.  
  140.           -    ScrollVPort() is not supported.  Although there is
  141.                potential for double buffering of single bitplane
  142.                displays within the A2024 frame buffer, no double
  143.                buffering is supported in extended mode.
  144.  
  145.           -    The View/ViewPort positioning in extended mode is res-
  146.                tricted.  A2024 extended mode screens may not be
  147.                dragged, but only moved front to back.  Normal mode
  148.                screens may be dragged up and down, but extended
  149.                screens will not be made visible unless they are the
  150.                frontmost screen.
  151.  
  152.           -    Dual-Playfield support has not been investigated yet.
  153.  
  154.           -    System Alerts, although functional, will not slide an
  155.                extended screen down when they are presented, but will
  156.                always appear in a black display by themselves.
  157.  
  158.           -    The standard aspect ratio handling (using GfxBase-
  159.                >NormalDPMX and NormalDPMY) cannot describe both normal
  160.                and extended mode ViewPorts.  A new function (or exam-
  161.                ple) will provide substitute values on a ViewPort-by-
  162.                ViewPort basis.
  163.  
  164.           4.  JUMPSTART AND MEMORY USAGE
  165.  
  166.           To provide interim support for the A2024 extended mode, new
  167.           versions of three system libraries are provided (Exec,
  168.           Graphics, and Intuition).  These libraries are loaded into
  169.           RAM and specially marked to be used after a reboot.  The
  170.           system is reset and these libraries are subsequently used.
  171.           This is called the "Jumpstart" operation.
  172.  
  173.  
  174.  
  175.                                 January 7, 1988
  176.  
  177.  
  178.  
  179.  
  180.  
  181.                                      - 4 -
  182.  
  183.  
  184.           Of these libraries, Exec must be loaded into Chip memory
  185.           (approx.  16 KBytes), and the others (approx. 125 KBytes)
  186.           are loaded into fast memory, if available.
  187.  
  188.           Large rasters take considerable memory.  Each 1008x800 bit-
  189.           plane is 100,800 bytes of Chip memory.  In contrast, a
  190.           640x200 bitplane is 16,000 bytes large.
  191.  
  192.           "Smart Refresh" windows are saved off-screen when obscured.
  193.           Since these windows (including the CLI windows) will prob-
  194.           ably be used in larger sizes, in the worst case they can,
  195.           each, use another 100,800 bytes for each bitplane, when at
  196.           their largest size and completely obscured by other windows.
  197.  
  198.           System Copper Lists are considerably more complicated and
  199.           larger than normal, but this is an insignificant memory con-
  200.           sideration compared to the dominating factors listed above.
  201.  
  202.           It is hard to precisely estimate the total difference in
  203.           memory usage when the A2024 is in use in its extended modes,
  204.           considering, for example, that smart refresh windows will
  205.           probably be larger.  We can see that on a system with a
  206.           two-bitplane Workbench (four gray levels) running after
  207.           Jumpstart there will be about 315,000 bytes less user
  208.           memory--about 185,000 bytes of that from chip memory--before
  209.           any smart refresh windows are opened (and obscured).
  210.  
  211.           5.  WORKBENCH ON THE A2024
  212.  
  213.           Via a revised Preferences program, the user will be able to
  214.           specify that the Workbench screen is to be opened in one of
  215.           the extended modes.
  216.  
  217.           It will not be necessary to reset the machine to facilitate
  218.           the requested mode change in the Workbench screen.
  219.  
  220.           Programs which open windows on the workbench screen should
  221.           continue to operate normally.  Providing, of course, that
  222.           they do not make use of the unsupported features listed
  223.           above, which would not have been proper on the Workbench
  224.           screen to begin with.
  225.  
  226.           Two areas that programmers must recognize for their work-
  227.           bench programs to operate correctly:
  228.  
  229.           1)   The Workbench Screen may be much larger than normal,
  230.                and it might have only one bitplane.  Using GetScreen-
  231.                Data() to determine the dimensions and depth of the WB
  232.  
  233.  
  234.  
  235.                                 January 7, 1988
  236.  
  237.  
  238.  
  239.  
  240.  
  241.                                      - 5 -
  242.  
  243.  
  244.                screen is still the preferred method for handling this.
  245.  
  246.           2)   As part of the new support, we will be allowing the
  247.                system font to be chosen from fixed width fonts which
  248.                may be larger than 8 or 9 points (pixels).  There is a
  249.                section on fonts below.
  250.  
  251.           6.  EXTENDED MODE CUSTOM SCREENS
  252.  
  253.           Memory permitting, Custom Screens may be opened in an A2024
  254.           extended mode.  An example accompanies this document.  There
  255.           are two issues: the general method of extending the NewS-
  256.           creen data for OpenScreen() and the information specific to
  257.           the A2024 modes.  We will attempt to remain binary compati-
  258.           ble with the example, although both issues are under review.
  259.  
  260.           The function OpenScreen() will fail if an extended mode is
  261.           requested but the system doesn't believe an A2024 monitor is
  262.           attached.  A way of detecting the system's belief before
  263.           attempting OpenScreen will be provided.
  264.  
  265.           7.  FONTS
  266.  
  267.           To date, only two fonts may be used as the system default
  268.           font, Topaz 8 and Topaz 9.  The Workbench screen always uses
  269.           the current system default font.  To run on the Workbench
  270.           screen, or in a Custom Screen which was opened with the
  271.           default font, it is not safe to assume that the font used
  272.           will always be 8 or 9 lines high.
  273.  
  274.           As a rule, IntuiText structures should never use the default
  275.           font (Font = NULL), unless run-time calculation is made for
  276.           suitable position and dimension of them and of objects which
  277.           contain them (such as gadgets).  General text layout,
  278.           Boolean Gadget with text labels, Requesters, String Gadgets,
  279.           and Menus should all be calculated with respect to the font
  280.           dimensions of the font that will actually be used.
  281.  
  282.           The FontHeight field in Preferences should not be used to
  283.           determine the default font height, since it is only a
  284.           request.  The system may someday allow requests for
  285.           FontHeight that cannot be satisfied. In this case the
  286.           closest available size will be used, but the Preferences
  287.           FontHeight will continue to reflect the user's preference,
  288.           albeit unrealized.
  289.  
  290.           The correct way to determine the characteristics of the font
  291.           depends on the situation.  The most typical are:
  292.  
  293.  
  294.  
  295.                                 January 7, 1988
  296.  
  297.  
  298.  
  299.  
  300.  
  301.                                      - 6 -
  302.  
  303.  
  304.           -    If you are going to render through a RastPort that
  305.                already exists, consult the font information in that
  306.                RastPort.
  307.  
  308.           -    If you are going to open a window on the Workbench
  309.                screen, use GetScreenData() to examine the Workbench
  310.                screen RastPort to get font information.
  311.  
  312.           -    If you are going to open a custom screen with the
  313.                default font, you can consult GfxBase->DefaultFont to
  314.                see what font will be used when the screen is opened.
  315.  
  316.           -    For tricky uses, it is sometimes necessary to realize
  317.                that ALL gadget text rendering is done through the
  318.                Screen->BarLayer->rp RastPort, with the exception of
  319.                editing string gadgets, done through (a copy of) the
  320.                Screen RastPort.
  321.  
  322.           Some special support will be provided to minimize problems
  323.           in the most frequently mishandled areas.
  324.  
  325.           String Gadgets
  326.                Until string gadgets are enhanced to support a font
  327.                specification, they are tricky to handle.  Intuition
  328.                will check to be sure that the gadget dimensions are
  329.                large enough to contain the font to be used.  If not, a
  330.                smaller Topaz font will be used.
  331.  
  332.           AutoRequests
  333.                AutoRequests require that the programmer specify the
  334.                exact dimensions and layout, although they are often
  335.                rendered in the default font.  Intuition will examine
  336.                the Font specification in any text contained in an
  337.                AutoRequest.  If it is the default value (NULL), the
  338.                positioning and dimensions of the text within the
  339.                requester--as well as the dimensions of the requester
  340.                itself-- will be taken as advice, and Intuition will
  341.                substitute more suitable values where appropriate.
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.                                 January 7, 1988
  356.  
  357.  
  358.  
  359.