[mod.os.os9] OS-9 Discussions, V2 #6

os9@cbosgd.att.com (11/19/86)

OS-9 Discussions         Tuesday, November 18th 1986         Volume 2 : Issue 6

Today's Topics:

                             COCO3 GIME chip specs.

[Generally, I try to avoid repetition of information which is distributed
 in other newsgroups.  However, this information seemed particularly
 timely.  I've also been hearing from individuals that they are not always
 receiving the newgroups but those on the mailing list do receive their
 digest.   Since I am keeping old issues you may request any you have
 missed. -- JDD]
--------------------------------------------------------------------------

Date: Fri, 14 Nov 86 14:24:28 est
From: ihnp4!ihwpt!knudsen

John: here is a 5-page map of the new Coco-III MMU/graphics chip
that many hackers will find useful.  Its authors are identified
in its original header, and I've added some things here & there.
It may be too big for mod.os.os9, or maybe it should be one
posting by itself.  There has been nothing here from mod.os.os9
for two weeks or so, but then ihnp4 tends to "blink" a lot and miss
what's going by.

PS: Latest rumor is that OS9 Level II for the Coco-III won't be out
until Feb '87.
Several sources to fix up older OS9 for the Coco-III (ramdisk,
boot fix) have come thru on comp.sys.m6809 (the new net.micro.6809.

------- Reposted article starts here --------
>From ihnp4!chinet!draco (Kent D. Meyers) Sat Nov  8 21:49:06 1986
Newsgroups: net.micro.6809
Subject: COCO3 GIME chip specs.

This information was gathered by Kevin K. Darling.
Edited and commented some more by Mike Knudsen.
This is a text for you to use to study the capabilities of the CoCo-3.
Some minor parts may be in error (??).  Insiders should clue us in on these.
Purpose of release is to show some of the extra thought in the machine.
In NO way should it be construed as an "official map".
Now have fun! -- Kevin
* Many Thanks from All of Us to the Contributors who shall remain UnKnown!

--------------------------------------------------------------------------
I     COCO-3 MEMORY, and GIME REGISTER MAP   (1 Sept 86)  KD ver1        I
--------------------------------------------------------------------------

SYSTEM MEMORY MAP:
 RAM      00000 - 7FFFF (512K bytes)
 ROM      78000 - 7FEFF when enabled
 I/O      XFF00 - XFFFF I/O space and GIME regs

64K PROCESS MAP:
 RAM       0000 -  FEFF (possible vector page FEXX)
 I/O       FF00 -  FFFF (appears in all pages)

Note: the same page of Vector Page RAM at 7FE00 - 7FEFF (when enabled),
 will appear instead of the RAM or ROM at XFE00 - XFEFF. (see FF90 Bit 3)

  XFF00-0X  PIA0       (not fully decoded)
  XFF10-1F  reserved
  XFF20-2X  PIA1       (not fully decoded)
  XFF30-3F  reserved
  XFF40-5F  SCS        see note below (usually Disk Controller)
  XFF60-7F  undecoded  (for current "legal" peripherals)
  XFF80-8F  reserved   (This time we'll believe it, right?)
  XFF90-BF  New GIME Features (Modes, MMU, and Palette)

NOTE: If MC2=0, then XFF50-5F is SCS, and XFF40-4F is internal to CoCo.
This helps to reject non-RS disk controllers.
--------------------------------------------------------------------------

 FF90  INITIALIZATION REGISTER 0	(And ... CocoMax's Mouse!)
        Bit 7 - CoCo Bit  1= Color Computer 1|2 Compatible 
        Bit 6 - M/P       1= MMU enabled
        Bit 5 - IEN       1= GIME IRQ output enabled to CPU
        Bit 4 - FEN       1= GIME FIRQ  "      " 
        Bit 3 - MC3       1= Vector page RAM at FEXX enabled
        Bit 2 - MC2       1= Standard SCS
        Bit 1 - MC1       ROM mapping  0 X - 16K int, 16K ext (Old 1|2)
        Bit 0 - MC0        "    "      1 0 - 32K int          (New 3 pwr-up)
                                       1 1 - 32K external     (New)
CoCo bit set = MMU disabled, Video address from SAM,
    RGB/Comp Palettes => CC2.
Clearing MC3 SHOULD let us run programs that clobber FEXX, no??
--------------------------------------------------------------------------

 FF91  INITIALIZATION REGISTER 1
        Bit 6 -           0=64K chips, 1 = 256K chips
        Bit 5 - TINS      Timer INput Clock Select:  0= 70 ns, 1= 63 us
        Bit 0 - TR        MMU Task Register Select (0/1 - see FFA0-AF)
--------------------------------------------------------------------------

 FF92  IRQENR    Interrupt Request Enable Register (IRQ)
 FF93  FIRQENR   Fast Interrupt Request Enable Reg (FIRQ)
   (Note that the equivalent interrupt output enable bit must be set in FF90.)
   Both registers use the following bits to enable/disable device interrupts:
       Bit 5 - TMR        Timer
       Bit 4 - HBORD      Horizontal border
       Bit 3 - VBORD      Vertical border
       Bit 2 - EI2        Serial data input
       Bit 1 - EI1        Keyboard.  Does this really work??
       Bit 0 - EI0        Cartridge (CART)

   I have no idea whether both IRQ & FIRQ
     can be enabled for a device at same time.
--------------------------------------------------------------------------

 FF94  TIMER MSB    Write here to start timer.
 FF95  TIMER LSB
  Load starts timer countdown. Interrupts at zero, reloads count & continues.
  Must turn timer interrupt enable off/on again to reset timer IRQ/FIRQ.

 FF96  reserved
 FF97  reserved
--------------------------------------------------------------------------

 FF98  Alpha/graphics VIDEO MODES, and lines per row.
        Bit 7 = vidmode  0 is alphanumeric, 1= bit plane (graphics)
        Bit 6 = na       ...
        Bit 5 = DESCEN   1= extra DESCender ENable
        Bit 4 = MOCH     MOnoCHrome bit (composite video output) (1=mono)
        Bit 3 = H50      50hz vs 60hz bit
        Bit 2 = LPR2     Number of lines/char row:
        Bit 1 = LPR1      (Bits 2-1-0 below:)
        Bit 0 = LPR0
                         000 - 1 line/row         100 - 9
                         001 - 2                  101 - 10
                         010 - 3                  110 - 11 (??)
                         011 - 8                  111 - 12 (??)
--------------------------------------------------------------------------

 FF99  VIDEO RESOLUTION REGISTER
        Bit 7 - na     ...                            (bits 6-5):
        Bit 6 - LPF1   Lines Per Field:       00= 192 lines  10= 210 lines
        Bit 5 - LPF0     "    "    "          01= 200 lines  11= 225 lines
        Bit 4 - HR2    Horizontal Resolution
        Bit 3 - HR1         "        "
        Bit 2 - HR0         "        "        (see below for HR, CRES bits)
        Bit 1 - CRES1  Color RESolution bits
        Bit 0 - CRES0     "      "
 ---------------------------------------------
 TEXT MODES:

 Text: CoCo Bit= 0 and FF98 bit7=0.  CRES0 = 1 for: use attribute bytes.

                      HR2 HR1 HR0    (HR1 = don't-care for text)
        80 char/line   1   X   1 
        64     "       1   X   0 	(not in BASIC)
        40     "       0   X   1 
        32     "       0   X   0  

 ---------------------------------------------
 GRAPHICS MODES:
         X   Colors   HR2 HR1 HR0  CRES1 CRES0	Kmem
H4      640    4   -   1   1   1      0   1	32
H3      640    2   -   1   0   1      0   0	16

(not    512    4   -   1   1   0      0   1	24
BASIC)  512    2   -   1   0   0      0   0	12  

H2      320   16   -   1   1   1      1   0	32    Other combo's are
H1      320    4   -   1   0   1      0   1	16      possible, but not
(no     320    2   -   0   1   1      0   0	 8      supported.
 ...
support 256   16   -   1   1   0      1   0	24
 ...    256    4   -   1   0   0      0   1	12
in      256    2   -   0   1   0      0   0	 6    Like PMODE4
 ...
BASIC)  160   16   -   1   0   1      1   0	16

 Old SAM modes work if CC Bit set.  Then HR and CRES bits are Don't-Cares.
 Note the correspondence of HR2 HR0 to the text mode's bytes/line.
 Also that number of colors = 2 * (2 ^ CRESbits).  No 8-color modes??
--------------------------------------------------------------------------

 FF9A  BORDER PALETTE Register RGBRGB (XX00 0000 = CoCo 1|2 compatible)
 FF9B  Reserved

 FF9C  VERTICAL FINE SCROLL 
 FF9D  SCREEN START ADDRESS Register 1 (bits 18-11)
 FF9E  SCREEN START ADDRESS Register 0 (bits 10-3)
 FF9F  HORIZONTAL OFFSET Register	(And ... MultiPak's Ghost!)
        Bit 7 = horizontal offset enable bit = 128 char width always 
        Bit 6 = X6  ... offset count (0-127)
        Bit 0 = X0

 Note that video start address can be given to nearest 8 bytes, not 512!
 If Bit 7 set & in Text mode, then there are 128 chars (only 80 seen)/line.
 This allows an offset to be given into a virtual 128 char/line screen, 
  useful for HORIZONTAL HARDWARE SCROLLING on wide text or spreadsheets.
  And for moving 40-char windows around on 80-char screens??
--------------------------------------------------------------------------

 FFA0-AF  MEMORY MANAGEMENT UNIT (MMU)
  FFA0-A7  Task #0 DAT map   (8K block numbers in the 64K map;
  FFA8-AF  Task #1 DAT map    task map in use chosen by FF91 Bit 0)

 Each register has 6 bits into which is stored
  the block number 0-63 ($00-$3F)
  of the Physical 8K RAM block (out of 512K) that you wish to appear at the
  CPU Logical address corresponding to that register.
 Also can be shown this way: the 6 register bits,
  when the Logical Address is in the range of that register,
   will become the new Physical RAM address bits:
         18  17  16   15  14  13 

  MMU Register:          CPU:
  Task0  Task1   Logical Address / Block#
   FFA0   FFA8    0000 - 1FFF      0
   FFA1   FFA9    2000 - 3FFF      1
   FFA2   FFAA    4000 - 5FFF      2
   FFA3   FFAB    6000 - 7FFF      3
   FFA4   FFAC    8000 - 9FFF      4
   FFA5   FFAD    A000 - BFFF      5
   FFA6   FFAE    C000 - DFFF      6
   FFA7   FFAF    E000 - FDFF      7

 -------------------------------------------------------------------
 Ex: You wish to access Physical RAM address $35001. That Address is:

 A- 18  17  16  15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
    .....3....  .......5......  .......0......  .......0......  .......1......
     0   1   1   0   1   0   1   0   0   0   0   0   0   0   0   0   0   0   1

 Taking address bits 18-13, we have: 0 1 1 0 1 0, or $1A, or 26. This is the
 physical RAM block number, out of the 64 (0-63) available in a 512K machine.

 Now, let's say you'd like to have that block appear to the CPU at Logical
  Block 0  (0000-1FFF in the CPU's 64K memory map).

 You would store the Physical Block Number ($1A) in either of the two Task Map
  registers that are used for Logical Block 0 (FFA0 or FFA8). Unless your pgrm
  that is doing this is in the Vector RAM at FEXX (set MC3 so ALWAYS there),
  you would want to use your current Task Map register set. If the TR bit at
  FF91 was 0, then you'd use MMU register FFA0 for the $1A data byte.

 To find the address within the block, use Address Bits 12-0 plus the Logical
  base address (which in this case is $0000):
 Now you could read/write address $1001, which would actually be $35001.
--------------------------------------------------------------------------

 FFB0-BF  COLOR PALETTE Registers

  Reg bits- 5  4  3  2  1  0
  CMP ...  I1 I0.P3 P2 P1 P0    Intensity and Phase (16 colors x 4 shades)
  RGB ...  R1 G1 B1.R0 G0 B0    Red Green Blue      (64 RGB combo's)

  When CoCo Bit is set, and palette registers preloaded with certain default
values (ask, if you need these), both the RGB and CMP outputs appear the same 
color, supposedly.

  40/80 Column Text Screen Bytes are Even=char, Odd=attribute, in memory. 
  Characters selected from 128 ASCII.  NO text graphics-chars.

  Char Attributes- 8 bits...  F U.T T T.B B B
       Flashing, Underline, Text foregrnd, Backgrnd colors 0-7.
--------------------------------------------------------------------------

 FFC0-DF  SAM : same as before (mostly compatible Write-Only Switches)
  FFD8 = CPU .895 MHz   (no address-dependent speed)
  FFD9 =     1.79 MHz
  FFDE = Map RAM/ROM    (RAM accesses use MMU translations)
  FFDF =     all RAM
--------------------------------------------------------------------------

Comments by MJK:
Seems that BASIC's power-up initialization doesn't do as much as it could
  to insure Coco 1|2 compatibility.  In FF90, should set Bits 7 and 2,
  and clear Bits 6 and 3.  Would allow continued use of FEXX page.
BASIC is giving us only a fraction of the powers inside the GIME;
  hope OS9 Level II does better (not till Feb. '87??).
RS disk controllers "ghost" all of FF4X at FF5X, and some software is said
  to use FF5X addresses instead of official FF4X.
  FF90's MC2 bit probably was intended to accomodate such code,
  but nothing (??) can save DISTO controller, which uses FF5X for
  add-on hardware features.

How many of these registers and bits are Read/Write, not just Write-Only??
  MMU (FFA0-AF) and Palette (FFB0-BF) read correctly.
  Attempts to read FF90-9F show all 7E with a couple 40s.
  POKEs to FF90 have momentary effect (screen flashes), but BASIC seems
  to refresh most of the GIME registers after each timer interrupt
  or some such interval.  Hopefully the refresh values are kept in
  low system RAM, maybe C0 and up -- so POKE values in there and let
  BASIC put them into the GIME for you.  Meanwhile, block 6809 interrupts
  to play with the GIME.

<The End>	-30-	Fine.	--MJK

 
-------------------------------------
The views expressed in OS-9 Discussions are those of the individual authors
only.
------
Moderator:  John Daleske   cbosgd!cbdkc1!daleske    daleske@cbdkc1.ATT.COM

Submissions should go to   cbosgd!os9               os9@cbosgd.ATT.COM
Comments to the moderator
 or to join the mailing    cbosgd!os9-request       os9-request@cbosgd.ATT.COM
 list.

*********************
End of OS-9 Discussions
*********************