[Coco] OS9 vs MS Win

[Bill Pierce]

In my current project, "MShell", I make extensive use of the "fragged" subs that Mike Knudsen used for Ultimuse3. I also use another of his techniques in that I "fork" a module from the main that inherits all STDOUT and in effect, handles all graphics and text output from any module in the system since any module called/forked/chained will inherit the redirected paths. To use the "fragged" subroutines, you have to make sure that you have at least 8k (frags cannot exceed this 8k) in your workspace. On compilation, all globals are stored in a single file and compiled into the main. Once that is done, the global file is then reassembled and stripped of any "string initiators" also, any needed routines from the main are added as pointers to the globals. Doing this, you must keep the main a certain size so it always has the same pointer offsets. Also Mike developed a special fake "dstart.c" to replace the standard "cstart" for the subs. This assures the globals are not reassigned after stripping the file therefore being nothing but a "pointer' to the existing globals.
There are a lot of limitations as you're still dealing with a 64k workspace but it gives you an 8k area for unlimited subs being called in and out. Couple this with the text/graphics handler having it's own workspace and using virtual memory (outside the 64k) for data/array storage and access, the main need only to handle the linking of the subs, menus, and system stuff like keyboard, mouse, and accessing the v-mem etc.
These techniques allow for a massive software suite only limited by the size of your HD and total memory on your Coco (for v-mem).

The memory map (in sizes) for the system is something like:

First 64k Workspace:
Main - $9E00
Globals - $2000
Mapped-In get/put buffer - $2000
Fragged Sub area - $2000 (shares above globals)
System - $200

Second 64k Workspace:
Graphics/Text handler - $7E00
Globals - $4000
16k Screen Area Mapped in for direct access - $4000
System - $200

Fragged Subs are kept at or below $2000 (no globals or DP)
Get/Put Buffers are called in 8k blocks ($2000)

Of course if the Main is kept smaller, then globals and/or frags can be larger. But you must keep sizes consistent

To init it all, the Main first calls the forked routine to establish a display and pipe the stdout. Then you map in the get/put buffer so it's address will remain constant so the array pointers always point to your mapped in buffer (no matter how many times you swap it out). Then you call the fragged sub to establish the sub links and set up the globals. This gives the sub area pointers a permanent home.
The main uses F$NMLOAD to first load the sub into system mem, then F$LINK to link it. With this double link, the sub remains in system mem after being unlinked allowing for faster load time on the next call to that sub. If the number of subs exceed system mem, the oldest sub is unlinked to make room for the needed sub. This also allows unlimited subs.

The whole system does NOT use the GFX7 library and makes minimal use of C libs by calling most things direct with get/setstat. The standard OS9 Hires graphics fonts, patterns and pointers are not used. The program creates all it's own graphics routines.

It's pretty easy once you have it all set up, but there are a lot of limitations to the fragged subs as in what libraries you can call, the number and size of local variables etc. Some C libraries will cause the fraggie to exceed the 8k. You cannot "malloc()" any memory as there is none :-)
You can allocate as many get/put buffers as you have total free memory

On my 1-meg Coco,, with 2 windows open, MShell running, I have about 744k left for virtual memory buffers to use at my leisure.
In VCC running a 2-meg system, 3 windows open, MShell running, a 360 sector ramdisk I have about 1664k of v-mem :-)

You gotta LOVE OS-9 :-D

Bill Pierce

"Today is a good day... I woke up" - Ritchie Havens
 

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com




-----Original Message-----
From: L. Curtis Boyle <curtisboyle at sasktel.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Thu, Feb 27, 2014 7:40 am
Subject: Re: [Coco] OS9 vs MS Win


Actually, there were subroutine modules (at least in level 2)... I wrote a 
machine language module for some special functionality for Printronix P300 
printers that we called from BASIC09 programs all the time. From what little I 
remember, you had access to the calling programs data area (in this case, 
BASIC-09 or RUNB), and you could do local storage with the stack (which I used 
in this case).

Sent from my iPhone