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

[Joel Ewy]

Roger Merchberger wrote:
> Rumor has it that Joel Ewy may have mentioned these words:
>> 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.
>
> Sounds like me... I'm just an idiot in search of a village... ;-)
>
>> Why not start building a collaborative, open source library of assembly
>> language routines for the CoCo
>
> I've actually started that, but last fall this thing called "Life" got
> in the way - and I'm not talking about the board game.
>
Probably safe to say we've all experienced something like that...
> However, my little project was centered around "Getting rid of" SECB -
> I wanted fully autonomous routines that doesn't rely on the ROM
> whatsoever. This was not only "not portable" as it was designed around
> the CoCo3 hardware only and prolly wouldn't be (easily) portable to
> NitrOS-9 - I was thinking more for embedded applications.
>
Actually, it sounds to me like what you have started and what I'm
proposing could be largely complementary.  You are talking about
back-end stuff (which will obviously need some kind of programming
interface) and I'm talking about a programming interface (which will
obviously need some kind of back-end, whether that be calls to the
CoCo's ROM routines, entirely new code, or some combination of the two.)

One possibility I could see is starting off with some simple wrapper
code that puts an OS-9 face on existing ROM routines.  I suspect that at
this late date we wouldn't have to worry about Tandy adding new features
to DECB, so even undocumented routines should be fair game.  Gaps in
existing ROM functionality (such as good disk file handling routines,
sprites, collision detection, and sound sample playing) could be filled
in with new code.

When that's all tested and debugged, you would have a nice API under
which to lay your work, along with some file handling routines, etc.  If
we start with an API written against the existing ROM code, there'll be
something solid to push up against while testing and debugging.  Then
people can write programs to that API, and your code could be hooked in
to an interface that already has working programs.
> What I do have (admittedly not much) will create & clear a 80x28
> screen, set screen colors & palettes, output characters & strings, and
> I started on a keyboard input routine - I got as far as scanning the
> keyboard matrix & getting "multiple unencoded character codes" (up to
> 5) out of the keyboard (where you could see both the shift, F1 & "Q"
> keys were pressed) - but I didn't have any lookup tables set up yet
> that would convert the character codes converted into ASCII, and I got
> rather "stuck" trying to figure out an algorithm for a key-repeat system.
>
> The other "plus" is as I was writing it, I was commenting it as best
> as I could... with actually meaningful comments, not examples like:
>
> loop at 1          LDA     #100    ; load A accumulator with 1
>                                ^^^^^ Bad commenting practice ^^^^^
>
> Each code module had overall comments for input/output parameters,
> etc... it was fairly modular the way I wrote it, but again, compared
> to Sockmaster's work, this was rather sophomoric.
>
> This was all to be open source, but as it was nowhere near ready for
> primetime, I haven't published any of it yet. I would be happy to
> publish what I have done, if people would like to see it.
>
I don't think anybody'd make fun of you for it.  :)

JCE
> Laterz,
> Roger "Merch" Merchberger
>
> -- 
> Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
> zmerch at 30below.com
>
> What do you do when Life gives you lemons,
> and you don't *like* lemonade?????????????
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>