[Coco] A Humble Proposal Re: M/L Disk I/O and CoCo Game "Construction Sets"

[Joel Ewy]

First off, let me say that I'm well aware that computer culture is a
meritocracy, and my few, feeble contributions to the CoCo / MM/1
software library hardly qualify me to make grand proposals.  I've seen
software and hardware project ideas posted to this list responded to
with something like "Yeah, if you think it's so easy, why don't you do
it yourself?"  And that's not an unreasonable response.  Still, the
CoCo's relative simplicity, and its "diamond in the rough" character
have always made it an ideal platform for learning and stretching one's
capabilities.  While my list of programming accomplishments is pretty
small at this point, and my degree is in Philosophy, I do have a bit of
technical knowledge, and even some formal, college-level computer
science (Data Structures, Computing Algorithms, Computer Systems,
Digital Electronics & Computer Architecture, Software Design &
Development).  Maybe just enough to make the following suggestion:

Why not start building a collaborative, open source library of assembly
language routines for the CoCo/(D)(S)ECB that will facilitate writing
games, utilities, or whatever, and which will mimic to some extent the
system calls of (Nitr)OS-9?  This could morph into a full-blown game
toolkit, or just be one component of it, if it gets that far.  I'm not
talking about complete compatibility -- the routines can be jumped or
branched into instead of accessed with an SWI.  And there's no reason to
try to completely re-implement all of OS-9 under RS-DOS.  That's not at
all the point.

The idea is just that if there's a library that provides basic file I/O,
or other services that are also provided by (Nitr)OS-9, there would be
significant benefit to doing it in a way that can easily be translated
to/from OS-9.  For instance, there should be an equivalent to the I$Open
system call, and it should take a pathname (for RS-DOS, something like
"MYFILE.DAT:0") and return a pointer to a vaguely
OS-9-path-descriptor-like data structure including a sector buffer. 
Internally, it should find the file if it exists, and set things up for
future calls to an I$Read or I$Write equivalent.  There are a lot of
OS-9 calls that would be totally irrelevant, and those need not be
implemented here.

The goal is not really compatibility, but reasonable portability.  The
CoCo world is too small to be completely divided between (Nitr)OS-9 and
RS-DOS.  Anything that can be done to facilitate cross-OS portability
can only strengthen both environments, and the CoCo as a whole.  Of
course it may not be feasible to port Donkey Kong to OS-9, or Flight
Simulator II to DECB  (or it may be, I don't know).  But there are lots
of programs that could be written in such a way that they could fairly
easily be ported.  (Of course it would be easier to go from OS-9 to
RS-DOS unless you are very careful to write mostly relocatable code for
RS-DOS...)  It would be a shame if a new code library was written that
was obtusely incommensurate with OS-9 system calls just because nobody
put any thought or care into it.

Even if it doesn't result in direct code compatibility, providing
OS-9-similar functions for non-OS-9 CoCo M/L programs would make it much
easier for programmers to move back and forth between the two
environments, which can't be anything but good for the CoCo.

I know Roger Taylor is going to suggest that it be done with Rainbow
IDE.  :-)  And he has already suggested a code repository.  I think
that's very cool, and Rainbow IDE should definitely be able to use this
code.  But I would be very disappointed to see it locked in so it
couldn't also be used in Toolshed, EDTASM+, or some scungy homebrew
assembler.  Just my two cents.

JCE