home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Guide / c-cplusplus-interactive-guide.iso / c_ref / csource3 / 132_01 / readme.doc < prev    next >
Encoding:
Text File  |  1985-08-21  |  10.9 KB  |  279 lines
  1.                         Nov. 18, 1983
  2.                         A. J. Griggs
  3.  
  4. readme.doc
  5.  
  6.     This file covers the 6809 implementation of Ron Cain's Small
  7. C compiler and a graphics driver/support package for the Radio Shack
  8. Color Computer.
  9.  
  10.  
  11.     1.0    6809 C compiler
  12.  
  13.       1.1    How to make it
  14.       1.2   How to run it
  15.          1.3   How to assemble the compiler output
  16.       1.4   How to get it into the Color Computer
  17.  
  18.     2.0    Graphics Driver
  19.  
  20.       2.1    Overview
  21.       2.2    Graphics support COLORLIB.A69
  22.       2.3    Graphics Driver Operation
  23.       2.4    Pass0,pass1,pass2
  24.       2.5    Object definition
  25.  
  26.  
  27.  
  28.  
  29. 1.0   6809 C compiler
  30.  
  31.     Pertinent Files:
  32.         canew.c        "new" version of first compiler segment
  33.         cb.c
  34.         cd.c
  35.         ce6809.c    Code generator for 6809
  36.         bldc.sub    Submit file to build compiler using
  37.         cdef.h        The required header file. BDSCIO.H is
  38.                 also required.
  39.                 BDS C version 1.41 or better
  40.  
  41. 1.1    To make it:
  42.         You must have a functioning version of BDS C on drive A.
  43.     Move the submit file bldc.sub onto drive A with this
  44.     disk in drive B. Submit bldc. If all goes without error, you
  45.     will need to answer the questions at the end of the link phase
  46.     as to which files must be searched. Input canew in response
  47.     to the first question, cb to the second, ... , ce6809 to the
  48.     fourth and the link should complete leaving canew.com on 
  49.     drive B. You will probably need double density drives (1/2 meg)
  50.     to build on drive b or will have to shuffle the compilation and
  51.     link operations.
  52.  
  53. 1.2    To run it:
  54.         syntax: canew <CR>
  55.  
  56.         The compiler will ask about defining global symbols
  57.             (say Y, it seems to work).
  58.         The compiler will ask about emitting the source lines
  59.             as comments in the assembly output. Handy for
  60.             debugging and they may be stripped out later
  61.             with STRIP.
  62.         The compiler will ask about the source file name.
  63.         The compiler will ask for the output file name.
  64.         The compiler will ask what number the assigned labels
  65.             should start at. Your choice unless merging
  66.             a previously compiled output.
  67.  
  68.         After all this information, the compiler will chug along
  69.         and emit an assembly file possibly with errors.
  70.  
  71.         The implementation on the 6809 uses the linked D register
  72.         as the primary and the X register as the secondary. The
  73.         code generator has been modified in some cases to be 
  74.         more efficient in indirect addressing which the 6809 
  75.         directly supports. If one is to seriously use this 
  76.         compiler, I would recommend that all back issues of 
  77.         Dr. Dobbs be scrutinized for bug fixes which I may have
  78.         missed. The compiler is meant to be run on an 8080/Z80
  79.         machine in the CP/M environment using BDS C. It will
  80.         not correctly self-compile into a 6809 host without
  81.         modification because:
  82.             1. Small C handles some expressions differently
  83.                than BDS C
  84.             2. The byte order for 16 bit words is reversed
  85.                on a 6809 relative to an 8080. The compiler    
  86.                assumes a certain order in some cases.
  87.         Not that it is impossible to port, but don't expect
  88.         it to work without some tinkering.
  89.  
  90.  
  91. 1.3    Assembling the compiled code:
  92.  
  93.         The first version of the compiler worked with a 6800
  94.     assembler found in a DECUS library modified to run with BDS C.
  95.     The byte order for the 6809 was correct and some of the 6800 
  96.     instructions even had the same opcodes. 6809 instructions were
  97.     built by FDB and FCB pseudo-ops. This may be seen in the
  98.     runtime package RUN6809.A69. Boy, was that tedious! Later versions
  99.     used a 6809 cross assembler (SORCIM's) which expedited the 
  100.     assembly and standardized on real 6809 opcodes. 
  101.  
  102.         You must include the run time package RUN6809.A69 in
  103.     the assembly file. You may bring it in automatically by 
  104.             #ASM
  105.             #INCLUDE  RUN6809.A69
  106.             #ENDASM
  107.     in the c code or append it to the compiler output. #INCLUDE
  108.     operations in the c code are recommended (see SHOOT1.C).
  109.  
  110.         The size of the assembled code can be problematic in
  111.     terms of disk space required and time. The utility STRIP.C
  112.     has been provide to strip out all comments. The files LIB
  113.     and RUN are merely stripped files of COLORLIB.A69 and 
  114.     RUN6809.A69 respectively. The stripped files are then run
  115.     through your assembler or may be prestripped and included in
  116.     the c code in the case of standard functions ( ie LIB and RUN).
  117.  
  118. 1.4    Running it in the Color Computer:
  119.  
  120.         Your Color Computer should have at least 16k bytes of
  121.     ram for running any reasonable C program. The demonstration
  122.     programs shoot.c and shoot1.c require 32k bytes. The lower 
  123.     16 k bytes is dedicated to the base page, stack, and two 6 kb
  124.     display pages in these programs. To down load files into the
  125.     Color Computer, the serial input bit is used with a down load
  126.     program. On the host side, you will require some sort of 4800
  127.     baud interface and a program to dump the 6809 hex object file
  128.     through this port. SERIO.C is the supplied driver on the host
  129.     side which runs with a UART. DLOAD is a 6809 assembly language
  130.     program for use on the Color Computer side. (by the by... Radio
  131.     Shack names EVERYTHING TRS-80 regardless of internal machinery.
  132.     I believe the smaller color computer uses a 6805 processor
  133.     which will not work with the supplied compiler).
  134.         The first question is "How do I get it into my color
  135.     computer?". This is (unfortunately) a Catch-22. The assembly
  136.     file DLOAD has been provided which, when assembled, will read
  137.     a Motorola "S" record hex file into the Color Computer's memory.
  138.     Once DLOAD is correctly in memory, it may be used to load
  139.     hex object files like... DLOAD. Obviously, one would save DLOAD
  140.     on cassette or disk once it was input.
  141.     You may:
  142.         1. Obtain someone's version of a loader which is 
  143.            supplied on a media you can read directly.
  144.         2. Assemble DLOAD and via BASIC poke your way into
  145.            a working loader from the assembly listing.
  146.         3. Write your own loader.
  147.         4. Give up. It really is too tough anyway.
  148.  
  149.     Having done both #2 and #3, it won't take that long to get it
  150.     rolling. 
  151.  
  152.         Make note of the runtime library COLORLIB.A69. It 
  153.     shows how to handle the clock interrupt, quickly sample the
  154.     joystick positions and fire buttons, and setup the graphics
  155.     chip (VDG). For machine debugging, the Editor-Assembler rom
  156.     pack supplied by Radio Shack is well worth it if you have
  157.     no resident tools. If you have a CP/M system (you must to
  158.     get this far!) then you do not need the Radio Shack disk.
  159.     DLOAD runs at 4800 baud and is adequate for small programs.
  160.  
  161.  
  162. 2.0    Graphics Driver
  163.  
  164.   2.1 Overview
  165.  
  166.      An object oriented graphics driver written in C with assembler
  167. support has been provided on this disk. 
  168.  
  169.     Pertinent files:
  170.             cwriter.doc -    Describes how the it works
  171.             shoot.c        Simple target demonstration
  172.             shoot1.c    Chase demonstration
  173.             pass0.c        first pass list processor
  174.             pass1.c        second pass list processor
  175.             pass2.c        last pass list processor
  176.             shoot.h        game header file
  177.             graph.h        graphics driver c header
  178.             prelude        assembly file for entry and
  179.                     exit to c code
  180.             shootini.c    Initializtion routines. 
  181.                     Primarily for driver lists.
  182.             shoot.gph    Object library
  183.             Colorlib.a69    Color computer support library
  184.                     and machine language section
  185.                     of graphics driver.
  186.             LIB        Stripped version of Colorlib.a69.
  187.             RUN6809.a69    Runtime assembly file for C
  188.             RUN        Stripped RUN6809.A69
  189.  
  190. 2.2    COLORLIB.A69
  191.     
  192.     COLORLIB.A69    contains the lowest level graphics primitives
  193. which will erase or write an object. A move is merely an erase followed
  194. by a write in the new location. COLORLIB.A69 is front ended by the
  195. application (shoot.c or shoot1.c) and the list driver (pass0-2). It 
  196. may be used by itself to splat objects on the screen with gay abandon
  197. but it will not check for overlaps and has no list processing. Test 
  198. objects are supplied in SHOOT.GPH.
  199.  
  200.  
  201. 2.3    Graphics Driver Operation
  202.  
  203.     The graphics driver acts upon the supplied lists (master and
  204. page update) and calls the various passes. This implemtation uses two
  205. display pages to avoid flicker during update. The undisplayed page is
  206. updated while the user sees a constant display on the visible page. Then
  207. they are switched and the process repeats. The master list contains
  208. all the information about what is on the screen as well as other status
  209. such as time remaining before an object is blanked or unblanked. All
  210. objects are resident in the master list and each display page list.
  211. The sequence of objects in all three lists must be identical. The intent
  212. of the master list is that it would contain not just graphic paramters
  213. such as position or object matrix but object action as well. 
  214. The sequence of operations for shoot and shoot1 is:
  215.  
  216.         1. Scan the master list and  call each procedure 
  217.            defined in the master object records. The  
  218.            procedures will update the master list.
  219.             procedure
  220.                 prcall
  221.                     <various graphic procedures>
  222.  
  223.         2. Update the undisplayed page list from the updated
  224.            master list. Wait for the desired number of clock
  225.            ticks to pass before swapping pages. The graphics
  226.            on the screen will be made to track the master list.
  227.             display
  228.                 cwriter
  229.                     pass0
  230.                     pass1
  231.                     pass2
  232.                 setscrn
  233.  
  234. 2.4    Pass0, pass1, pass2
  235.  
  236.      These are the three passes over the displayed page and master
  237. lists which update the graphic objects:
  238.  
  239.   2.4.1 Pass0
  240.     Pass0 tests if an object requires updating. Possible states are:
  241.         Blanked to Unblanked
  242.         Unblanked to Blanked
  243.         Moved.
  244.     When pass0 completes, the state of the displayed page list 
  245.     is correct for each object assuming no object interactions. A
  246.     possible interaction would be to blank or erase an object 
  247.     behind a stationary object which would erase all or part of the
  248.     foreground object. Pass0 erases objects which require update
  249.     by directly calling eraseobj().
  250.  
  251.   2.4.2 Pass1
  252.     Pass1 checks for object interactions like the one mentioned. The
  253.     degenerate case is where all objects must be erased and
  254.     rewritten. Pass1 will add to the list of objects which must be
  255.     updated due to overlap considerations. Pass1 checks each object
  256.     against every other object in the list and therefore is time
  257.     consuming. It is possible to avoid pass1 if there is 
  258.     sufficient intelligence in the higher level software to 
  259.     avoid overlaps. A possible case would be in player-missle
  260.     games where if the player and missle overlap, they are 
  261.     replaced by one object .. an explosion.
  262.  
  263.   2.4.3 Pass3
  264.     Pass3 is the calling function for object writes. It loops 
  265.     through the displayed list  and calls writeobj().
  266.  
  267. 2.5    Object Definition
  268.  
  269.     See the file SHOOT.GPH for details. Objects are dual byte
  270.     lists with a header. All objects are blocked within the smallest
  271.     enclosing rectangle. Each byte within the rectangle is 
  272.     defined for on pixels as well as masked pixels (holes). The mask
  273.     is applied by eraseobj() to only erase the active parts of
  274.     the object. The mask also allows pixels defined by multiple
  275.     bits (2-3) to be correctly erased. 
  276. d. 
  277. ased. 
  278.  
  279. ! ╖φRσ┴!@φ░╔!┘~╖(O═ α#⌡vCOLD BOOT ERROR, HALTAå@N7E├\█├X█                COPYRIGHT (C