[Coco] Nitros9 high speed mode

[Joel Ewy]

Robert Gault wrote:
> ...
>
> It is possible for user programs to revert to 1MHz and emulation mode
> with one important caveat. You can't let the system regain control
> until you return to 2MHz and native mode. That means all IRQs should
> be turned off, vectors saved, vectors redirected, speed and mode
> changed, and IRQs restarted. This completely defeats the point of
> using OS-9. You might as well write a stand-alone ml program to run
> from Disk Basic.
>
Well, I wouldn't say it completely defeats the point.  Or maybe it
doesn't defeat all the points of using OS-9.  You still have a better
file system with real hard disks, rather than just a bunch of floppy
images that happen to be stored on a hard drive.  You can write your
program in C, BASIC09, or even Pascal (though some would seriously
question whether the latter is any improvement over DECB <insert
programming language religious war here>).  This assumes you can arrange
to get the system back in a fit state to run system code any time you
need to access library code or OS routines.

If your program produces some kind of data file, having that file in the
OS-9 environment means you can then proceed to massage it with all kinds
of wonderful programs and utilities that likely don't exist under DECB.

I once wrote a program to take 3 DS-69B Digisector video digitizer files
containing the individually digitized Red, Green, and Blue components of
an image, and write a 15-bit Targa high-color image from them (leaving
the LSB empty).  I think I also did a version that made a .vf3
flicker-vision picture, or something like that.  I wrote the program in
C under OS-9 because it was a much better development environment (at
least for this kind of thing) than DECB.  But it was a pain to use the
agonizingly slow RSDOS utility to copy each image file from an RS-DOS
floppy disk to OS-9.  I did a little work on trying to reverse-engineer
the DS-69 software in hopes of writing an OS-9 device driver for it. 

I suspect that I would have had to break all kinds of OS-9 rules to make
that hardware work in OS-9, and would probably have had to mask
interrupts for a long time while digitizing a scene.  Maybe not.  I
didn't get far in the process to tell for certain.  But it would have
been worth it if I had been able to digitize a picture in OS-9, even if
I lost minutes of RTC time and couldn't multitask a thing while
digitizing.  It would have been so much easier just to do something like:

digisector /ds0 256 16 >/dd/image_r.vef
digisector /ds0 256 16 >/dd/image_g.vef
digisector /ds0 256 16 >/dd/image_b.vef
merge /dd/image_r.vef /dd/image_g.vef /dd/image_b.vef >image.vf3

And you could certainly argue that the regular (halt-mode) floppy driver
is almost as bad as what you describe above, though it doesn't have to
go through so many contortions to achieve basically the same effect: 
hogging the whole system for inordinate amounts of time while nothing
else can run.

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