Approximate Specifications for the GIMMEx32 GPU
The GIMMEx32 is a 32 bit GPU clocked at 28.608 MHz that also manages the memory mapping for the four virtual x09 processors and provides some floating point capability at least on a par with the Intel 8087 and can access up to 32MB of memory.
The system that this GPU is designed for would have a 114.432 MHz master clock that divides into a 57.316 MHz "Blender Clock" that controls four blender streams a triggers the timing for the  28.608 MHz GPU on every odd cycle and provides a master clock 180 degrees out of phase from the GPU for the four virtual CPU's on every even cycle. This CPU 28.608 MHz CPU master clock provides four independent virtual CPU clocks each with a maximum clock rate of 7.152 MHz. At least three of the four virtual CPU's may also be clocked at multiples of 894 KHz from 1 to 8x. This way a 1x CPU matches the standard Coco 2 clock a 2x CPU matches the Coco3 rate a 3x approximately matches a GIMEx equipped  coco 3 the 4x rate matches Sock Masters double speed coco and the full 8x matches the theoretical maximum clock speed of a 6309 with  a cooling fan and also the Matchbox Coco's rate.
Main features of the GIMMEx32:

So lets look at more details about each feature.

VIDEO MODES

GIMEx modes also cover all traditional coco3 and coco2 video modes.

Other modes include many software compatible with matchbox coco modes eight full screen background graphics modes and special text modes such as a 40x132 16 level gray scale text mode available as a special Background overlay mode for the VGA monitor and a similar 20x66x128 color Text mode for the Composite Monitor(note this mode uses the high bit of the color byte to designate a flashing pixel) .

32MBR

The GPU has direct memory access to all of the CoCo 5's 8MB of memory and the potential to access an additional 24 MB through the Advanced Adapter Interface. Although this interface was origonally conceived of as a way to add support for monitors other then VGA or Composite it has other potential uses and perhaps could be split between two cards although they would have to share bandwidth.

Dual Monitor Support

There is dual monitor support and built into the CoCo 5 to support a third monitor the  Advanced Adaptor Add-On card must provide suitable software in its ROM otherwise adding that card will disable the  VGA port.

The Background Screen

The Background Screen Feature is a background screen upon which all other "Screens" are stacked. This screen is directly controlled by the CPU#0 and the GPU GIMMEx32. CPU #0 only gets involved to setup the data for the GIMMEx32 and then the GPU renders on it's own. It's capabilities include among other things the ability to render an animated gif directly to the background screen. There are actually two background screens VsgB for the VGA monitor and CsbB for the Composite monitor.

Virtual Screens (Defined as Windows Stacked over the Background each containing what would be a Screen on a real CoCo)

Virtual Screens are rendered by the GPU's but are managed by CPU #0. Other CPU's may make requests for specific layouts through CPU#0's
Executive Supervisory Program API thus CPU#0 has the last say and the  Executive Supervisory Program resolves any conflicting requests.

Virtual Screen and Sprite Spec Format:

ScreenGroup.LayerCode.ScreenID some examples with comments:
GA.t.SV09          Group A . top layer . ID=SV09  
                                                             (S00 is the background S01 to S08 reserved for system popups regular screens start at 9)
GA.m.SV10         GroupA . middle layer . ID=SV10 

                                                 (.m for middle layer , .t for top layer and .b for bottom layer)
GB.B.SV00          This screen exists if you have a
VGA monitor attached to the VGA out port it a the system background screen. 
GB.B.SC00          This screen exists if you have a Composite monitor attached to the Composite out port it a the system background screen.
GB.B.SA00         
This screen exists if you have a monitor attached to the Advanced Adapter out port it a the system background screen.
GB.B.SV00CC     This screen
exists if you have set the VGA screen to be a clone of the composite screen.
GB.B.SA00CV     This screen
exists if you have set the Advanced Adapter Screen to be a clone of the VGA screen.
                                                                                                                         (ie. DVI mirroring or replacing VGA.)
GB.B.SA00CC     This screen
exists if you have set the Advanced Adapter Screen to be a clone of the composite screen.
                                                                                                                      (ie. RGB monitor mirroring or replacing the composite screen.)
GC.t.SV011
        Group C . top layer . ID=SV09  
                               (Screen groups are different, non overlapping areas of the screen. )

ScreenGroup.SpriteLevelNumber.SpriteNumber.InstanceNumber

So how do we set up a set of Virtual Screens.

There are two main steps and in some cases a third:

  1. Divide the real screen into virtual screen groups.
  2. Assign virtual screens to virtual screen groups.
  3. If you have assigned screen layers to a screen group you must set the degree of transparency for each group.

Step #1 (Virtual Screen Group Setup Direct method)
There might also be an API method but we will not describe it.

Virtual Windows setup directly by CPU#0 via X prompt. (some examples)


Example #1
Suppose you want a screen layout like this.


Where each color block above repersents an assignment of that section to a different "Screen Group" and the Dark Blue is unassigned.
The command to achieve this layout would be:
X>SCREEN VGA="BBBG,AAAC, AAAC,AAAC,AAAC,HJOR"
seems rather abstract but  but lets look at the alternative way of doing the same thing supposing that we start with a completely unassigned screen.
This screen would show only the background picture and when the
system mouse hovers over the bottom of the screen the STATUS and X> lines.

OK using the command   X>SCREEN LAYOUT VGA     you get this
screen poping up the Status line turning to a help line and the X>
changing to an S> prompt.

clicking the mouse over fourth box in the top row
and typing the key sequence below,
G→AAAC→AAAC→AAAC→AAAC→HJORX
what does this mean
first understand that each block here is a 320x113 block of the screen
the first G says assign this block to "Screen Group G" since you are at
the end of a row must be pressed to move the cursor to the next row
pressing A to set this block as part of "Screen Group A" the cursor will
automatically move to the next entry in the row so AA assigns the next
two screen sections to "Screen Group A" as-well, the C→ assigns the
next section of screen to "Screen Group C" and then moves the cursor
to the next row. The final X is to close the screen setup window and exit
to the S prompt.
At the S prompt the command VGA S or VGA SHOW will pop up the
screen layout window which looks like this.

gets you a temporary screen setup that you can use right away but
that you will loose after you power down.
But the command VGA SAVE at the S prompt will save your changes
to NVR. After saving VGA SHOW will show

   
As you can see the lower case letters are the setup currently in use
while the upper case letters indicate what is stored in NVR Settings.
Finally at

Example #2
Again Suppose you want a screen layout like this.

But this time will make some mistakes and then show how to correct them.
Once again we will start with nothing assigned to the screen.
If you have been following this as an exercise the commands
X>SCREEN VGA="BBBB,BBBB,BBBB,BBBB,BBBB,BBBB"
X>SCREEN VGA SAVE
will get you back to an unassigned (Background Only) screen.
X>SCREEN VGA S
will show this layout.

Now suppose you type at the x prompt.
X>SCREEN LAYOUT
you will get the S prompt
S>

Type
S>VGA
of course you could have typed X>SCREEN LAYOUT VGA
you would come to the same place.
Now clicking on the fourth cell in the first row and typing
G→AAAC→AAAC→AAAC→AACC→HJORX at this prompt
screen will come up looking like.

Oh Oh not what you wanted. So how to fix ?
just type  S>VGA you will get this

The area surrounded by the red flashing border contains the mistake.
If instead or typing
G→AAAC→AAAC→AAAC→AACC→HJORX
G→AAAC→AAAC→AAAC→AAAC→HJORX
you would have had what you wanted so now to fix it just click on
the cell 5 rows down and 3 columns over and then type
AX so now you have the proper setup.
What if you don't have a USB mouse attached.
In that case every time you type S>VGA or S>CMP
you get the cursor flashing in the top row first column and in this
case the key sequence →→↓↓↓↓AX will get the problem cell fixed.
In this second case you are saying
NEXT column NEXT column NEXT row NEXT row NEXT row NEXT row Assign Cell to Screen Group A Exit
Ok hopefully that is enough description that you understand what I have in mind to assign various sections of the screen to a screen group.
Lets summarize the codes you use in the screen layout editor:
ACDEFGHJKLMNOPQRST are codes to (assign  to up to 18 different screen groups A --> T)
B is the code to assign a screen area to the System Background.
I is the code to display enhanced info about each screen area.
U is the code to undo last change.
is the code to skip to next entry in row leaving the current entry unchanged and also the code to continue to the start of next row if you are already at the end of a row.
is the code to go pack to the previous entry.
is the code to go down to the next row staying in the current column.
is the code to go up to the previous row staying in the current column.
V is the code to verify that all chosen screen areas are rectangular and that a screen area has been uniquely defined .
W is the code to write the current screen areas to NVR
X is the code to exit applying all changes as a temporary screen setup.
Yd is the code to yank a whole screen area to the d provided no existing screen areas are in the way d refers to the direction you want to yank and can be any of .so Y would mean yank "screen group A" to the right if it was keyed in while the current entry is A.
Zsa is the code to zero out screen(s) sa so ZHJO← would eliminate screen groups HJ and O. The syntax is Z followed by one or more screen group identification letters the screens disappear as you type and you can type U to undo a mistake.

Step #2 (Assign virtual screens to virtual screen groups Direct method)

Ok so far we have divided the screen into sections but how do we run programs or send graphics to these sections ?

To do that we must assign a Virtual Screen or Virtual Screen(s) to each screen group we wish to use.
There are two versions of the assign command:

  1. S>ASSIGN Tsgx #cpu.qualifier where:
    • T is either V for the VGA screen or C for the Composite screen.
    • sgx is the screen group identifier  one of A C D E F G H J K L M N O P Q R S or T.
    • #cpu  #1 #2 or #3 if in Tri-CoCo Mode only #2 or #3 if in Dual-CoCo Mode (Optional)
    • IF which means display current screen "In Focus" this must be used if #n not used.
    • .qualifier is a further refinement of what to show, this qualifier is optional and not to be used with IF.
      available qualifiers will be described later in the examples section.  
  2. S>ASSIGN ADVANCED command where the command is one of:
    • FOCUS              Display only the content in "Focus" on advanced monitor auto scales to use display effectively. 
    • MIRROR VGA    Mirror the Display for VGA very important if you have no VGA monitor.
    • MIRROR CMP    Mirror the Display for the Composite monitor.
    • NATIVE @addr   Use a driver written for support of that specific card at ROM address addr this requires an additional ROM.
    • NATIVE OS9      Use a driver written for support of that specific card that loads from OS9 you will have to start from another monitor or headless until the driver loads.

Examples

Example 1. In this example we will assume that we are in TriCoCo mode with CPU#2(CoCo GREEN) in Coco 3 mode have:
We will also assume that we initially have no virtual screen groups assigned.

The VGA screen which for this example is  720 vertical pixels by 1280 horizontal  pixels looks like this.

Note illustration above at 3'4 scale, CPU#0 is selected focus and that STATUS & AUTO-HIDE are OFF.

Ok so lets set up the screen groups for a 720x1280 SVGA system.
X>SCREEN VGA="ACCC, ACCC,DCCC,DCCC,FCCC,FCCC"
This gives us this screen layout.

We now  also have an S prompt. So at that S prompt we type.
As soon as we move the system mouse or Joystick or press any key
the screen layout display goes but may be brought back with the command
LAYOUT from the S prompt or SHOW LAYOUT from the X prompt.
S>ASSIGN VsgC #3,#3.1,#3.2 SCALE
this assigns the output of CPU #3 to Screen Group C and reserves the
middle and bottom layers of sgC for control by CPU#3 as well.
(The important thing to note here is that by assigning #3 to C we have directed the
standard output of virtual CPU #3)
Assuming CoCo Red has just booted we
see something like this.


Now the next step is to assign CPU #1 (CoCoBlue) to Screen Group F
We could use the command  S>ASSIGN VsgF #1 SCALE to get a screen like this:

OR we could use the command  S>ASSIGN VsgF #1 to get  a screen like this:

Now there is a program for RS-DOS on the Coco 3 out there that shows all 64 colors on the screen.
Assuming  you have that program copied to drive 1 you could type
LOADM "64: EXEC at the RS-DOS Prompt.

The 64 Colors for the chosen mode RGB CMPo or CMPe would be shown as below.

Ok lets continue we still have not assigned video outputs to Screen Groups A & D.
The following two commands will be used to make these assignments.
S>ASSIGN VsgA #2  SCALE
S>ASSIGN VsgD #2/w5 SCALE
The result will be

We note that CPU #2 is now waiting in RS-DOS and while most of Screen Group D is still showing the
system wallpaper as if it had not yet been assigned there is a notice indicating that "w5 Not Available"
because an NitrOS9 instance is not running on CPU#2. ** See Note re. Alt Views
Starting NitrOS9 with the DOS command on the CoCo Green we see.

When fully booted we still see

"w5 Not Available"  in the Screen Group D section of the screen because NitrOS9 has no /w5 is defined.
Later if we open /w5 from the Nitros9 instance on CoCoGREEN we get

Note that

S>ASSIGN VsgD #2/w5 SCALE
did not cause /w5 to fill the entire area assigned to
Screen Group D even though the SCALE option was specified.
this is because the window
/w5 created in MultiVue was not assigned the entire Screen Group D that is being mapped
into
Screen Group D.
Note if we had given the Command

S>ASSIGN VsgD #2/w5 SCALE FS
instead the screen would look the same if no other windows had been opened on that
Screen Group D but
suppose we had also opened a calculator and a clock the screen would now appear as below.



We will study this situation further when we study "FOCUS"

First we will check the Alt View commands available at the X prompt. ** See Note re. Alt View
IF we had typed X at the S prompt we would fall back into the X prompt.
         S>X
       X>SHOW SCREEN GROUPS
       X>STATUS SHOW
       X>
After typing these into the executive interface and pressing the FOCUS key until CPU #3 has focus you get 


to turn off this display mode use the commands:
    X
>HIDE SCREEN GROUPS
    X>STATUS OFF

FOCUS
Note there is always a virtual Coco in FOCUS and if it is running nitrOS9 it may have multiple windows one of which can
be in focus.
We will consider an extension of the example we have been developing where we assign all or part of a second monitor
to show a view of the virtual CoCo in "FOCUS" this will be the composite output in this case.
note this will be CoCo Blue, CoCo GREEN or CoCo RED the window assigned for showing "FOCUS" does not change
contents when your "focus" is the Executive Command Line or any of the related command interfaces.
So how do we make the assignment.
One option is to give the whole composite screen to show focus.
X>SCREEN COMPOSITE ASSIGN ALL TO FOCUS
X>
this command will temporary assign a copy of the CoCo screen in focus to the composite screen.
the alternative option involves setting up a Screen Group Map for the Composite output.
This  Screen Group Map will be smaller then the 1280x678 pixel ( 4x6 )  Screen Group Map used for 1280x720 resolution SVGA Screens.
The 720x480 NSTC or 720x576 PAL modes use a 640x452 pixel ( 2x4 ) Screen Group Map.
X>SCREEN LAYOUT CMP the following screen will appear
Now type CC→CC→RR→RR or you could have typed
X>SCREEN CMP="CC,CC,RR,RR"
to make the same changes non interactively.
You can then type X>SHOW LAYOUT to replace the Wallpaper with a layout display
in that case you should see this on your screen.

You have assigned the top half to CsgC and the bottom half to CsgR.
now Note that CsgC is in no way related to VsgC.
Having defined two screen groups we now have to assign contents to them.
X>SCREEN ASSIGN CsgC FOCUS
  S> ASSIGN CsgR OVERFLOW
Were-as we could have assigned for example S>ASSIGN CsgC #3,#3.1,#3.2 SCALE
Just as we did on the VGA monitor or we could have  S>ASSIGN VsgC FOCUS
on the VGA monitor to have VsgC follow the FOCUS.
OK so what is  OVERFLOW the OVERFLOW keyword sets up  a window to display output from a
screen group that is to small for the output it is trying to display like for example if you had a 
screen group that consisted of two cells high one cell wide on your VGA monitor that cell can display
up to 226x320 pixels so if you type WIDTH 32 or WIDTH 40 in BASIC OK but if you type WIDTH 80
you have a problem you are requesting a window that requires 192x640 pixels this will not fit in the
assigned screen group so that it cannot be displayed a  SCREEN OVERFLOW pop-up message over the
system background will display instead. If you have however assigned another virtual screen as FOCUS
then the 80 Column screen will display in the FOCUS virtual screen instead in this case the top half of
the Composite output display. But what happens when you change focus well were it not for having
assigned the bottom half of the Composite output display as OVERFLOW  the 80 Columb screen would
be invisible. The following set of screen illustration  should convey how this works.
  1. X>SCREEN CMP="CC,CC,RR,RR"  (This command lets you create the layout at the X prompt.)
  2. X>SHOW LAYOUT (This command lets you see the layout you created.)
  3. X>SCREEN ASSIGN CsgC FOCUS  X>STATUS SHOW
    Note: As yet no virtual CoCo has been in focus so there is no change on the Composite Monitor,
    Also note the Blue Status line in the Executive Interface Program Input Area.


  4. And wait 3 seconds ... Note by pressing the FOCUS-Key you change FOCUS to CPU #1 also known as CoCo Blue.
    Because of this we see updated info in the Status Bar and the CsgC region is now showing the output from the "IN FOCUS" screen.
    Also note that in this case the NVR Settings for the Composite monitor have  "Show active Screen Groups as Outline Only" set.

  5.   And wait 3 seconds ... Pressing the FOCUS-Key again we put CPU #2's last used window in focus.

  6. gets us back to the X prompt but CoCo GREEN is still "IN FOCUS" from the point of view of the screen display
    because:
    1. Focus only changes if you wait 3 seconds after pressing the FOCUS key.
    2. Screen FOCUS only changes to virtual CoCo's even when keyboard focus has changed to an Admin Screen.
    Here we type X> SCREEN ASSIGN CsgR OVERFLOW
    Note that now Screen Group Red is marked as "Overflow not in use."
  7.   And wait 3 seconds ... You have changed the FOCUS to CPU #3 also known as CoCo RED.


  8. Holding down SHIFT and pressing will put CPU #2 back in focus and you may start typing immediately which will be reflected in
    VGA screen group A intermediately but will only show initially after a 3 second delay on the Composite screen group C .
    ( Please note that after the initial 3 second delay the screen groups stay in sync with no noticeable delay between them.)


  9. Now in NitrOS9 on CoCo GREEN we type shell i=/w7&


  10.   gets us back to the X prompt and here we will type.
    X> SCREEN ASSIGN CsgC FOCUS SCALEY
    X> SCREEN ASSIGN CsgR OVERFLOW SCALEY
    to tell the screen groups to scale any screen they are showing to use the full available height.

    Note the width is not scaled by this command.
  11. And wait 3 seconds ... You have changed the FOCUS to CPU #3 also known as CoCo RED again.
    Note while the "FOCUS" window on the composite monitor now shows the CoCo RED Disk Extended Color Basic 4.5 screen the "OVERFLOW" screen
    still shows the /w7 from NitrOS9 running on the CoCo GREEN.
  12. Typing in WIDTH 80 and ENTER at the Basic OK prompt we note the effect on the VsgC and CsgC displays.
    Fig. S08

  13. will put CPU #1 in focus. Note that this time the image has been stretched to fill the full 225 pixel height of CsgC,
  14. Taping the RESET button at the back of the computer changes the screen to this.
    Notice how only CPU#1 got a SOFT reset*


    * Typing RESET #1 at the X prompt would do the same thing. Note: Our Prompt is Echoed in CsgC=Focus.
    Figure: S10
  15. At the OK prompt we type WIDTH 80  and press [ENTER] to change the screen to 80 Column.

    Note: That the VGA screen group F is only 320x226 pixels so cannot hold the 80 Column Basic text screen so instead 
    a notification "Required Resolution is 640x192 Screen Overflow !" is displayed in VsgF.
    The 80 column text screen is however available in CsgC because that screen is  640x226 pixels so can.
  16. [Shift][Clear]  - Puts the Focus on the screen with  /w7 on CoCo GREEN.

    Also notice how CoCo Blue's  80 Column Basic text screen has moved from the FOCUS screen group CsgC
    to the OVERFLOW screen group CsgR.
SUMMARY: points Screen Group Creation and Source Assignment so far we have ...
  1. Divided the 720x1280* SVGA monitor's screen into four VGA screen groups A,D and F which each use 226x320 pixels
    and screen group C which uses 678x960 pixels we see how it is done and that screen groups cannot overlap and
    that with the exception of B the Background Screen all screen groups must be rectangular.
  2. We continue by assigning the output of CPU#3 (CoCo RED) to screen group C and in this case we assign not just the
    standard output to  screen group C but also two "Hidden" layers how these are used will be described when BLENDER
    is introduced. We then go on to assign CPU #1 to F and CPU #2 to A & D where screen groups A gets the main
    (CoCo GREEN)
    output and D is tied to the output of the screen that contains NitrOS9 window /w5.
  3. From step 3 of the 16 illustrated the Status line is turned on because Context is very important for many commands.
  4. Finally since we are out of VGA screen space and have more to illustrate we define two Composite screen groups C & R
    note Composite screen group C is not the same thing as VGA screen group C. after creating these screen groups
    we use them to illustrate to other sources  FOCUS & OVERFLOW this leaves only one source type STATIC not discussed.
At this point we have covered Screen Group Creation and Source Assignment  quite well so you should be able to use these
to create a screen layout that makes for a good work flow. So now we will imagine some software that might use a complex
screen setup such as the one described here and In doing so we will introduce the BLENDER component of the GIMMEx32.

Base Colors

There are actually 3072 base colors any specific monitor must use either the Background Set or the Virtual Screen Set for its background. Only the Virtual Screen Set can be used for Virtual Screens.  

Mode Real Color Code Color Read As Notes
00 0-63 0-63 Coco3 Composite
01 64-127 0-63 Coco3 RGB
Enhanced Composite 128-191 0-63 A address in settings determines whether
standard or  Enhanced Composite is active.
10 192-447 0-255 Xterm Colors
Grayscale* 424-487 0-64 5 bit Gray
for Background Only Screen mode.
          Extra Colors 488-511  N/A Extra Colors possibly including
 Matchbox CoCo Colors.
11 512-1023 0-511 GIMEx Colors
Background Color
(Red Set)
0-1023 0-1023 10 bit Color RRRRGGGBBB
for Background Screen Only.
Background Color
(Green Set)
0-1023 0-1023 10 bit Color RRRGGGGBBB
for Background Screen Only.

* Note above Xterm Colors 231 to 255 are grey scale so we overlap those grey scale colors with the rest of the greyscale. 

Background Set refers to a set of colors that are only available only on the background layer.

These colors would be specified as 2:n for the red set or 3:n for the green set where n=0 to 1023.

Virtual Screen Set refers to a set of colors that are used by the Virtual Screen Groups that form the three layers stacked  above the background.

Background Status Bits are read from the NV-RAM settings on system startup they may be one of:
01= Virtual Set  10= Red Set  11= Green Set or  00= Grayscale

The Virtual Screen Set  is designed is actually addressable as a set of four palettes these are:
00= Coco3 Composite  01= Coco3 RGB  10=  Updated Coco3 Composite   and  11= GIMEx Colors.

This allows software written assuming various legacy hardware setups to faithfully reproduce colors in the Virtual Screen that has been assigned to them, however some colors such as  488 to 511 can only be addressed in background color mode as 1:nnn.

Further there are several different ways to specify a precise color.


"Color Blender"/Color Mixing Palette Extender

The Color Blender is a feature of the GPU that allows multiple planes stacked above the background in a WINDOW to be given opacity values from 0 to F corresponding to 0 opacity which hides a plane to F for Full opacity which would hide all planes under it and for a color in each plane to be set as transparent.

Code % Transparency

0 0.00(Hides Background)
1 6.25
2 12.50
3 18.75
4 25.00
5 31.25
6 37.50
7 43.75
8 50.00 (half)
9 56.25
A 62.50
B 68.75
C 75.00
D 81.25
E 87.50
F 100.00 (Full Transparency*)

Note Full Transparency would hide the layer in question because all it's elements would be invisible.

Now lets look at practical examples of how the Color Mixing Palette Extender works.

1. Every Virtual Screen group may consist of  one two or three layers.

For example the screen command  S>ASSIGN VsgC #3,#3.1,#3.2 SCALE
assigns three layers to VGA screen group C if we had typed just
S>ASSIGN V
sgC #3,#3.1 SCALE
then only  two layers would be assigned to VsgC and if the command
S>ASSIGN V
sgC #3 SCALE
was used then only the one screen group would bs assigned.

Now if all these layers were opaque then they would not be of much use however we can use the CBlend command to set the transparency of each layer. For example

COLOR Blend #3  8,8,0

Sets the transparency for cpu #3's Top Mid and Base layers to Half,Half and No Transparency for example. This gives you three equitably weighted layers with no effect from the background .

On the other hand

COLOR Blend #2 B,F,1

would set the layers for CPU #2 to 75% 100% and 6.25% respectively very much dimming the top layer making the mid layer completely invisible and allowing a hint of the system background to be seen through the base layer.

Another variation of the COLOR Blend command specifies a Screen Group instead of a CPU #.
For example

COLOR Blend CsgR 6
sets the Composite Monitor Screen Group R to a transparency of 6 but can only set this screen group if it only consists of a single layer and does not apply to Focus or Overflow  screen groups as these use the settings of there parent window.

For example if you used the command Assign CcgR #3.1 to set up CcgR then the CBlend CsgR 6 works but if you had used   Assign CcgR #3.0,3.1 to set up CcgR then the CBlend CsgR 6 does not work .

Another screen command is GRAB to get the color at a chosen point.

GRAB COLOR@ x,y ON m Gets the color code of the specified x,y coordinate on m= VGA or CMP and pushes that value to the color stack.
The color code is also displayed at the X prompt.

GRAB COLOR@ CLICK Gets the color code of the point clicked on and pushes that value to the color stack.
The color code is also displayed at the X prompt.

These features maybe used not only from the X prompt but also called from BASIC4 or Assembly language via the XAPI.

The next few illustrations show how such features nay be used.

For this example we will imagine a assembly language program XCanvas that runs in a BASIC4 environment making use of these advanced features. We will go back to our VGA screen group example layout to illustrate the interface. So if we are runing XCanvas on the CoCoRED ie. CPU #3 then it will be displayed
on VsgC the first illustration will just focus on what's happening in that Screen Group.


Note the "Layer Transparency" menu item does it's work by calling the XAPI that executes  COLOR Blend
it then passes the  CPU number of the calling program #3 and fills in the transparency data from the user input form 8,8,0.

As illustrated above just click on Colors in the drop-down menu and then Layer Transparency  fill out the values 8 8 and 0 and then click Change Transparency.

Now lets look at another example GRAB COLOR@ CLICK is called by XCanvas through the XAPI

when the eye-droper tool is clicked  and after clicking this eye-droper tool the system mouse can click on any
color on the whole screen to grab that color.
Notice that after clicking on Color 44 in the program runing on CoCoBlue the background of the Eye-Droper changes to that color and so  does palette entry
#16. The palette color is Pushed on the "Eye Dropper Stack" which may contain up to 20 entrys and if the stack is full the oldest entry is trashed.
There is one exception to clicking anywhere to grab a color if you click in the Color Management Area then instead of grabbing that color you will be depositing a color or colors from the stack.
In the illustration above note that after clicking on the eyedropper we click on palette entry #43 a popup appears over the View Port giving options.
If you realize that you have clicked on the wrong place then pressing the X key will abort otherwise Double Clicking or typing PX will put the eyedropper
color in palette entry #43 and pop the eyedropper color back to color it was before the most recent  GRAB. If you however wanted to place the color in
multiple palette entries you could type CX instead to copy the entry to the palette but not pop it off the eyedropper stack.
If you want to pop several colors off the  stack just repeat pressing P and each color in turn will pop off the eyedropper stack until you press X or have reached the last item in the stack. Similarly pressing C multiple times will copy multiple colors from the stack to the palette.
Finally AX pops the whole eyedropper stack onto the palette.
Note:
  1. The destination auto-increments with each POP or COPY from the eyedropper stack.
  2. The colors change just as soon as the keys are pressed.
  3. The action codes are not case sensitive ie. PX and px do the same thing.
  4. Other action codes are S to skip an entry (the eyedropper stack entry is copied to the bottom of the stack and then popped without being placed in the palette).
                                   and D to pop the item off the stack without placing it in the palette.
  5. Also note that the help popup customizes itself to reflect the palette position clicked and the range of palette entries the command would change.
  6. Note the eyedropper stack can have a maximum of 20 entries and in this example there are 14 entries that would be pasted into 43-->56 by AX.

So in summary we have introduced the screen prompt commands
COLOR Blend #3  8,8,0
GRAB COLOR@ CLICK      and    PUT COLOR@ IN PALETTE @CLICK
these commands all have XAPI versions and we have used a hypothetical advanced version of CoCo Max dubbed XCanvas 5 to illustrate the use of these commands.
One final thing to note this Disk Basic Program XCanvas is able to access the OS-9 file because CPU #2 is runing a server.

Sprites

In TriCoCo Mode each processor each processor can claim 24 Sprites. 4 Large Sprites and 20 Small Sprites.
In DualCoCo Mode
each processor can claim up to  6 Large Sprites and 30 Small Sprites.
In any case there are also four Admin Sprites available for CPU #0 ( One is used as the USB Mouse Pointer ) .

Every Sprite in use must be entered into the Sprite Directory in the "All Share" Super Block.
The Directory element consists of:

  A Sprite uses five or six memory areas these are listed below with :
  1. The Sprite Table in CPU#0's exclusive block at the top of shared memory has a 128 Byte Block that keeps track of Sprite ownership.
  2. The Sprite Directory(s)  are created by the call that provides a sprite to a cpu which works as follows:
    • Requests CPU #0 to provide a pre-saved saved sprite or to create a sprite with the provided data.
    • If the call fails the failure code is returned.
    • Otherwise if a sprite is available CPU#0 places an ownership nibble in it's 128 Byte table at nibble offset=SPRITE SYSTEM ID
    • Places the SPRITE SYSTEM ID and the address of the User Sprite Directory in the 8K exclusive block owned by that cpu at the top of shared memory.
    • Places the User Sprite Directory at the memory location requested.
    • Places a copy of the Sprite Directory  in memory managed by CPU#0 for reset access if RESET RESTORE is enabled.
    after the sprite has been setup the Sprite Directory in memory can be accessed by the cpu that requested sprite creation. If RESET RESTORE is enabled in NVRAM settings the copy Sprite Directory in CPU#0 memory will be not be updated by either the calling CPU or the GPU but only used for reset.
  3. The PALETTE Data is placed at the Palette Block Address and Offset specified in the directory and includes the following entries in this example of a 16 color palette Sprite.
    User CPU# Palette Color Depth Palette Block Address Palette Offset Address High Palette Offset Address Low Transparency Assignment
    3
    #10
    #1B
    #00
    #88
    03

    R G B R G B
    0
    0
    0
    4
    0
    1
    1
    7
    7
    1
    2
    3
    4
    5
    6
    7
    0
    0
    3
    2
    1
    0
    0
    7
    3
    1
    5
    6
    6
    2
    1
    3
    5
    7
    4
    1
    3
    1
    1
    1
    3
    6
    1
    5
    5
    5
    1
    1
    The data in the above is in italics the headings of course are not explicitly stored is requires 54 Bytes.
    The RAW DATA in Hex is as below.
     
    00 10 1B 00 84 03 00 00 00 04 00 01
    01 07 07  01 02 03 04 05 06 07 00 00
    03 02 01  00 00 07 03 01 05 06 06 02
    01 03  05 07 04 01 03 01 01 01 03 06
    01 05 05 05 01 01

    The same setup is used for two color sprites. Note if you do not want any transparency in your sprite assign #11 ie 17 as the Transparency Assignment.
    256 color sprites use a more compact code where each color is specified as two bytes the red byte and the green/blue byte. where the two byte color code consists of Odd Byte=Palette Nibble,Red Nibble and Even Byte=Green Nibble,Blue Nibble.
    If the first 16 colors of the 256 color palette were the same as those specified for our example 16 color palette example above then the first part of the resulting PALETTE Data would be:
    50 00 34 01 14 56 07 00 13 21 B0 07 03 15 06 62 81 35 87 41 03 11 31 36 01 55 05 11 ...
    Note how the header information is hidden in the high nibble of each odd byte starting with the second which contains the 3 that refers to CPU#3.
    The first nibble of the first byte is always 5 as long as only GIMEx colors are used in Sprites otherwise values of 6  and 7 would refer to the Green Set & the Red Set of 10 bit colors.
  4. The Data Block is of the following format The String SPRITE #NNN NNNxNNN DATA BLOCK followed by bit-wise palette number data to describe the Sprite's visual appearance for more info read about Sprite Types.
  5. Finally (MAYBE) the sprite game data area if there is one. If the sprites SPRITE SYSTEM ID is set between 128 and 255 the three bytes following the data block give the MMU block and offset of the start of a block for game defined attributes this could store for example code for sprite Death Sequences ie a set of frames showing the replacement images as the Sprite Instance is destroyed. 
Sprite Types
Large Sprites vs. Small Sprites vs. Instance Sprites.

Large Sprites require 1024 bytes per sprite while Small Sprites only require 256 bytes and Instance Sprites only require 30 bytes.
Large Sprites Types:
Small Sprite Types:
  •    2  Color    64x60  Pixels
  •  16  Color    32x30  Pixels
  • 256 Color    16x15  Pixels
Instance Sprites are only one type CLONE every instance sprite is the clone of an existing sprite where the only data independent of the master copy is the coordinates,velocity,rph, start angle(always 0 for the master) and health (So for example cloned fighter planes can expire independently.) Note Admin Sprites cannot be cloned.
Sprite Rotation 
Only Small Sprites and Instances of small sprites can be auto rotated by the GPU
The rotated versions of the sprite is calculated and saved in the High Def Video Memory and quick copys are made to the locations where they are being displayed.  The rotation speed is given in revolutions per hour and has a range of -32,767 to +32,767 where 0 is no rotation and maximum rotation speed is approximately 9 revolutions per second. Sprite rotation gets a low with auto skip of sprite updates when GPU load is high.
Sprite Planes Every Sprite is in a Plane 0 through 7 and may be moved under program control.
This diagram shows what is meant by these Planes.

 Note that Three Sprite Planes are above the Top Screen layer so any sprites here will hide a portion of the top layer behind them.
Suppose you were creating a game  where a drone plane could be launched from a submarine under the sea and fly up into the sky then if  the background layer showed a sea bottom picture and on Sprite Plane #1 we have the "Submarine Sprite" then "Airplane Sprites" not yet launched could hide in Plane#0 when launched they show up next to the submarine on Level #1 as they climb to Level#2 Virtual Screen Bottom Layer could show splashing waves then as the Plane Sprite rises to  Planes #3 & #4 virtual screen Mid Layer shows landscape shrinking below finally when the plane reaches Plane #5 it is above the cloud deck with clouds being handled by the Virtual Screen Top Layer where it dogfights other planes.. 
Just an example of how multi screen layers could be leveraged to achieve a game not possible on a standard color computer.

Direct Memory Access

The GIMMEx32 chip has direct memory access to all of the 8 Meg of CoCo5 memory and can also access up to an additional 24MB of memory from Advanced Adapter Add-On Cards. 
Memory on the  Advanced Adapter Add-Ons gets mapped into the High Def Video Memory in up to 16 x 96K blocks and a special Blitter command can copy the entire  High Def Video Memory  to or from an Advanced Add-On card.. Blitter commands cause 32 bit transfers either to a memory block or a VGA  screen. In the case or the memory block it is a simple transfer in the case of a screen the blitter command sends groups of three 10 Bit Color Codes to a screen where the last two bits of the 32 bit word indicate witch level each group of three is placed on.
If the last two bits are 00 the 3 pixels are for the System Background Layer if 01  VS Bottom Layer, 10 VS Mid Layer or 11 for VS Top Layer

Math

Math

The inclusion of math co-processing capabilities would be useful for programs aiming for realistic physics and for the GPU's  automatic calculation of Sprite position based on physics.
If we reserve 55 of the 255 possible single byte opcodes available for the GIMMEx32 for math co-processing instructions we could have most of the instructions of the 8087. 

Add on Cards

Add on Cards

These cards occupy the location where the RF Out would be on coco 3. 
Some possible cards could be.

Video Data Refresh/GPU/CPU Clocks (Highly Speculative)

There are two Master System Clocks @114.3 MHz we call these +MCLK and -MCLK idealy they are derived from a single 228.6 MHz. Master Clock but if not that then synced with a PLL.

In the tabels below the highest levels refer to Higher Clock Rates When there is a mini table within a table cel it means that

+MCLK master  clock divides down as as follows.

+MCLK (114.4 MHz.)

Graphics Master
Clock (57.2 MHz.)
+Blender
Clock (57.2MHz.)
GPU Processor Clock (28.6MHz.) Blitter Clock (28.6MHz.)
* * * * * * * *
*See Note #1

* Note #1: The Plus Blender Processor goes through the following cycles for each pixel each cycle at 57.2 MHz which results results at a rate of 7.14MHz these mixing are .

  1. Get Sprite Plane #7 pixel if any.
  2. Mix with Sprite Plane #6 pixel if any.
  3. Mix with Sprite Plane #5 pixel if any.
  4. Mix with Virtual Screen Level #3 (Top)
  5. Mix with Sprite Plane #4 pixel if any.
  6. Mix with Sprite Plane #3 pixel if any.
  7. Mix with the results of -Blender.
  8. Output results if VGA Pixel to VGA Monitor DAC.

-MCLK is the master  clock for the Composite system every 16 pulses are directed as follows.

-MCLK (114.4 MHz)

CPU
Clock (57.2MHz.)
-Blender
Clock (57.2MHz.)
* * * * * * * *
*See Note #2
CPU Processors
Master Clock (28.6MHz.)
Video Signal
Master Clock (28.6MHz.)
#0 #1 #2 #3
CPU Master Clocks
each @7.14 MHz.
**
VGA Composite

* Note#2:The Minus Blender Processor goes through the following cycles for each pixel each cycle at 57.2 MHx results at a rate of 7.14MHz these mixing are .

  1. Get  Virtual Screen Level #2 ( Mid )
  2. Mix with Sprite Plane #2 pixel if any.
  3. Mix with  Virtual Screen Level #1 (Bottom)
  4. Mix with Sprite Plane #1 pixel if any.
  5. Mix with  Virtual Screen Level #0 ( Background )
  6. Mix with the results of +Blender.
  7. Output results if Composite Pixel to the Composite Monitor DAC.

** Also note that while CPU#0 is allways set to 7.14 MHz. #1,#2 and #3 can take values from 1x to 7x  multiples of 894 KHz.

Note also how each CPU gets a 7.14MH Clock and how the Master VGA & Composite clocks are 14.3 MHz.