[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