[Coco] RAINBOW vinyl records?

[Christian Lesage]

theother_bob wrote:
> Well, circles that don't look like circles was a very obvious and 
> annoying bug.
>
> This was not a "bug" per-se, but a trade-off between quick/approximate/simple code and slow/accurate/complex(large) code. 
Call it a bad implementation instead of a bug if you prefer. IIRC, 
BASIC09 and the GFX2 module *could* draw good looking circles...

Do you agree that they could have done a better patching job? They had a 
lot of free ROM space (more than 6KB) to hold more and better patches.

> What did the Basic circles look like on the C-64 or other computers of the time? 
If you read the first message I posted under this thread, you will see 
that I consider ECB to be better than the BASIC on the C64. That being 
said, mediocrity is not an example to follow. I also said in my first 
post that one of the CoCo's strengths (before the CoCo 3) was its BASIC 
interpreter; the poor CoCo didn't do well in the sound & graphics area, 
so it had to offer something else to compensate for this handicap.

Don't forget the CoCo 3 was released in 1986, and by then there were 
better competitors than the 1982 C64 (which still surpassed the CoCo 3 
in some aspects). The 8-bitters were definitely on the downward slope. 
More advanced computers like the Amiga, the Atari ST, and the PC AT were 
already on the market.

When Tandy introduced the CoCo 3, boasting about its whopping 128KB of 
memory, I genuinely thought that I would be able to really benefit from 
the extra memory with the new, "Super" ECB. It turns out that this extra 
memory was only available for graphics purposes.

> Welcome to marketing 101. They wanted to sell more aftermarket products, not make the basic unit so powerful that you didn't think you'd NEED additional power!
>   
That "marketing" scheme left people in a twisted kind of situation where 
to be able to use the available 128KB in a sensible way to write larger 
BASIC programs, they would have to purchase a disk drive, OS-9 and a 
512KB memory board (in order to be able to run BASIC09 with a decent 
amount of free memory).

> The CoCo is flexible enough that you really don't need those things to take advantage of it's capabilities. [...] It's one POKE (not LPOKE) to swap a block of RAM. Then EXEC a subroutine and another POKE to restore RAM. The 8K blocks can be predefined and saved to disk by other Basic programs, just like modern software makers.
>   
Well of course, you can use assembly language (which implies you first 
have to learn it, and also buy an assembler) to program the CoCo 3 and 
make it do tricks you normally can't do with BASIC, but what if you just 
want to program in plain vanilla BASIC? When a BASIC programmer has to 
manage the computer's memory "by hand" using a bunch of POKEs, PEEKs, 
and EXECs, I say the BASIC implementation he's using is not well 
designed. My opinion is that SECB did not live up to the expectations 
and was a weak attempt at enhancing Extended Color BASIC.