[Coco] Re: Looking for I/O specs for DECB,Nitros,.....

[farna at att.net]

Is this going to run under DECB or Nitros9? Big difference! DECB is just extensions to BASIC that allow direct access to disk functions, much as you describe with Forth. Nitros9 (and OS-9 in general), on the other hand, is a true DOS with calls. Not sure if that bit of info will help or not! Art Flexer is probably the one to speak to about DECB, Boisy Pitre about Nitros9/OS-9. Hope they have the tech info you need! 

--
Frank Swygert
Publisher, "American Independent 
Magazine" (AIM)
For all AMC enthusiasts
http://farna.home.att.net/AIM.html
(free download available!)

 -------------- Original message ----------------------

> Date: Mon, 1 May 2006 18:16:16 -0700 (PDT)
> From: Brett K Heath <hcmth019 at csun.edu>
> Subject: [Coco] Looking for I/O specs for DECB,Nitros,.....
> 
> Hi All,
> 
> Some of you may remember that I have on occasion made noises about
> "...working on a port of Laxen & Perry's f83 to the coco". Without going
> into gory details about why this project has been on hold (again) for the
> past several years (again) let me just say that a couple of weeks ago I
> managed to reassemble the components of my "development system"[1] and
> have started looking at it again.
> 
> I still have to clean up and test a few things in the compiler source
> (mostly having to do with position independence), but the meta cross
> compiler, cross assembler and most of the 6809 kernel seem to be working.
> 
> The looming obstacle is that, other than calls to the Basic rom's CIN and
> COUT routines, I have no information about the calling conventions imposed
> by any of the DOS's used on the coco. In and of itself this isn't
> particularly upsetting, but it does make it difficult to write the
> OS/Hardware specific code needed to make it useful on these systems;-)
> 
> It gets worse, part of the design goal is it be able to deal directly with
> the disk hardware (making it possible to fix corrupted boot disks etc[2]).
> Again, lack of information about the calling conventions and functions
> provided by various disk subsystems makes writing drivers something of a
> challenge.
>