[Coco] 64k memory limit (was) CP/M emulator for OS9/6809

Sun Apr 27 20:33:26 EDT 2014

> the 6309 is put in native mode during boot and never changes back to 6809.
> IRQ/FIRQ are not compatible between modes as you have more registers pushed in 
> native mode.
> and each application has a 64k window you cannot extend that without cheating.

This is not quite so. You can go beyound 64k very easily with common "legal" OS9 system calls. Though it doesn't extend the 64k workspace for the actual "program size", You can move all buffers and data storage out of the of the 64k and into "virtual memory". Also, by calling "fragged subroutines", you can extend program length to "unlimited" with limitations only by your Coco's physical memory. And it's all done without "cheating".

Right now, my MShell project is sitting at (with all subs included) $16297 (90755) bytes of "compiled" program. It's using 128k of memory for workspace (2x64k). It's also utilizing a 16k workspace for manipulating graphics directly (no cgfx lib used), and a full 16k, 80 col, 2 color graphics screen for the display. The data area bounces between 48k and 256k (normally) determined by how large the directory listings are that are loaded into memory at any given time. It will use up to the Coco's full memory if needed. In Vcc running with 2 meg, I have used the full memory for data.
And this is a "running" program, not a projected idea for a program. There are certain restrictions on just what a subroutine can do, or what size your subroutine is, but the number of subroutines used is only limited by how much hardrive space you have :-) The data area can hold anything you want to put in it, accessable by fast "index pointer" oriented calls to map the buffers into memory as needed. I can copy "full" program modules into memory as "data" and make "single pass" copies !

The one thing I've found so far is that it will not work with Roger's "DrivePak". His OS9 driver implementation is too "non-standard" and doesn't seem to "play well with others".

The "fragged subroutine" routines could most likely be used even in OS9 Level 1 if done right. I've yet to experiment with it, but I plan to. I just have too much going trying to get MShell to do what I intend for it to do. This would expand Level 1 beyound 64k without even having more than 64k physical memory!!

For now, I have MShell reading/scrolling dual directories from "any" file system my Coco & NitrOS9 can read (soon my PC server's actual HDs as well, not "just" the VHDs).
I can have one panel view an RSDOS partition on a DW4 vhd while the other panel is viewing my "/dd" or floppy drive. Files can be copied between the two with a couple of clicks. It will view any directories on the system using the keyboard OR mouse. Basically similar to "Windows Explorer" (not "Internet Explorer"). Open new dirs by clicking on them. View 42 files in each (2 col) panel (both on one screen). Switch between panels with a click.

And the whole thing will update itself with any new versions from the internet... from the Coco (via dw4).

Even if I do say so myself... It's amazing to watch it work :-)
And it's pretty fast too... on a "real" 6809 Coco 3 w/1-meg (or 512k... I checked :-).
It also runs on Vcc 1.4.3b.... in 6809 or 6309 mode... 512k-2meg
I could release a demo of it now, but I want to put in a little more "error trapping" before I release the demo to the public.

I do need a "beta" tester or two... 
System requirements are:
Coco 3 512k (or better) OR Vcc 1.4.3b
NitrOS-9 w/CoWin or CoGrf, Pipes, DW4 drivers w/ "/Xx" and "/Nx" descriptors (standard in the NOS9 distribution disks)
An OS9 hard drive system (real or virtual). It may run from floppy, but really isn't practical. If so, 2 drives would be best.
DriveWire4 is not actually required, but it is preferred. It "should" run without DriveWire though I haven't tested this. The program checks for DW4 on startup and disables DW features if not found.

Any "takers"?

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: Retro Canada <retrocanada76 at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sun, Apr 27, 2014 5:49 pm
Subject: Re: [Coco] CP/M emulator for OS9/6809

On Apr 27, 2014, at 5:26 PM, Nick Marentes <nickma2 at optusnet.com.au> wrote:

> On 28/04/2014 7:13 AM, Retro Canada wrote:
> if you run os-9 level 2 in 6309 it's already in native mode which is 30% 
faster on average. this is what i do at home. there are some instructions that i 
could benefit from 6309 but dont think it would make any major impact. i made it 
for 6809 to not restrict the audience.
> 
> what could really speed up would be using lookup tables for some instructions 
byt this would take more memory than the coco itself could handle.

But because the OS is 6309, does that translate to all programs?

I know you can turn on 6309 and get faster execution of all codes but the speed 
boost is obtained from writing 6309 native and utilizing some of the extra 
commands.

This is my understanding and what I was referring to for Luis's CPM emulator.

As it stands, it's not really practical to use any CPM programs because of the 
speed. Shame because Luis has done a great job of making it run at all. Just 
needs that little bit of extra speed to put the icing on the cake.

Also, doesn't Level 2 OS-9 utilize more memory or are applications still 
restricted to a 64K memory space?

Sorry for my lack of knowledge in OS-9, hence the many stupid questions.   :)

Nick

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco