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

[L. Curtis Boyle]

On Fri, 13 Apr 2007 11:42:56 -0600, Joel Ewy <jcewy at swbell.net> wrote:

> 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.
>
Actually, that is a pretty good idea, and I don't think backporting some  
stuff between the two is impossible (although Donkey Kong would be very  
difficult)... Thexder, from looking at the disassemlbed source, WAS  
originally for OS-9, and must have been changed to cartridge format near  
the end of the project (as per Alan Dekok, who ported it back).

-- 
L. Curtis Boyle