[Coco] I think you'll like this (especially Allen)

[Andrew Ayers]

Juan,

You mention quite often in this series "things they could have easily 
fixed" in/on the CoCo 3.

Maybe you already know this...but they (Microware) likely couldn't, not 
without modifying the BASIC.

If they could've modified the BASIC, they very well might have done just 
that - along with a host of other things:

1. Extending SCREEN (and/or PMODE), PCLS, PPOINT, LINE, etc - to support 
the new graphics

2. Extending POKE/PEEK to support the extra address space (though I 
don't see why they would have gone beyond 0xFFFFFF; that's a 16 megabyte 
space...and back then, an ordinary Radio Shack customer buying a CoCo 3 
would not likely have had the money for that amount of memory - 
especially for an 8-bit machine; nor was there any hardware to support it)

3. ...and anything else.

The reason being, as I understand it...Microsoft wouldn't allow them 
(Tandy/Radio Shack) to change any of the underlying code of the 
interpreter...which is likely why Microware was only able to add new 
commands (and they were probably lucky to be allowed to do that much).

Basically, I think Microsoft was "washing their hands" of any further 
involvement with their 8-bit BASIC; maybe they would've done it for a 
particular price, but if that was the case, Tandy didn't take them up on 
the offer. Probably whatever was needed to extend it was all the leeway 
they got from Microsoft (or the existing contract allowed for it).

Microsoft likely at that time was moving forward rapidly with Windows 
(not sure if it was still Windows 1.0, or something else), and DOS, and 
PCs...they likely wanted out of the 8-bit hobbyist market (it was on 
it's "last legs" - had Tandy/Radio Shack made the CoCo 3 a 16-bit 
machine, that might've made a difference to Microsoft).

Today, I really doubt that Microsoft cares at all what happens to the 
BASIC in the CoCo (or elsewhere). What I think would be neat, would be 
an updated ROM image that fixes all those bugs, plus adds whatever it is 
you're doing (I'm sure you have a good reason for it), plus maybe some 
of the extras...maybe an extension of ADOS, or something else?

A interesting alternative - one that would break things, though - would 
be a "re-imagining" of the entirety of the BASIC on the CoCo 3; like, 
what if Microsoft had decided to extend the BASIC "properly", what would 
they have done? Like, could we get some of the features of other BASICs 
around that era?

I'd vote for something like a mashup between parts of the BASIC for the 
BBC (bus manipulation commands to make it easier to use, beyond PEEK and 
POKE, might be fun), plus parts of some of the other minicomputer (PDP 
line, perhaps) BASICs that existed (like maybe matrix operation 
keywords, or extensions to the existing operators, that could somehow 
know when A and B were arrays, so you could do things like "DIM A(10), 
B(10,10), C(whatever)" then set the arrays, and "C = A * B"; how cool 
would that be?

As long as I'm "blue skying" here, what about fixing DRAW so that it 
could have arbitrary rotations (and not the fixed ones it has)? That 
way, you could do "turtle graphics" fairly easily, or something akin to 
the "shapes" the Apple IIe (I don't recall versions on this)...

There's probably a ton of other things that could be done; whether they 
could all fit into the "allotted memory space" is a different matter, of 
course...

Heh...what about extending the PLAY command to allow access to the 
Orch-90 cartridge (or better, the SSC)?

Oh - here's another one: Allow the definition of "textures" for PAINT 
(and BF?) to use; add in a "TRIANGLE" kind of command - that would be 
icing on the cake for 3D stuff in BASIC (something I always hated; if 
you wanted "filled in" triangle polys, you had to draw the lines in one 
color, "fill-in" with another, then re-draw the lines in the fill color 
- to make a solid triangle that would overlap/overdraw stuff already on 
screen - and not use that one "border" color anywhere else).

Of course, the new TRIANGLE command would be a rasterized version; maybe 
you could just extend the LINE command to something like 
"LINE(x1,y1)-(x2,y2)-(x3,y3),BF" or such - and if only two coords were 
passed, it could just split the rectangle up into two triangles; it 
would of course depend on whether a 2-pass triangle thing is smaller 
than having two independent routines, along with maybe speed issues - or 
maybe the rasterizer could be augmented in some manner?

Of course, all of that is just because I played around with Lee Adams 
"High-Performance Interactive Graphics" series of books back then on the 
CoCo 3 and HSCREEN 4 - I would've loved such routines (also, some way to 
do easy page flipping and double-buffering would've been nice, even if 
it had to be limited to a 512K machine).

:)

Andrew L. Ayers
Glendale, Arizona
phoenixgarage.org
github.com/andrew-ayers