[Coco] RAINBOW vinyl records?

theother_bob theother_bob at yahoo.com
Sun Aug 16 01:59:35 EDT 2009






----- Original Message ----
From: Christian Lesage <hyperfrog at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Friday, August 14, 2009 8:18:28 PM
Subject: Re: [Coco] RAINBOW vinyl records?

Arthur Flexser wrote:
> my recollection is that the bugs were neither all that numerous nor
> particularly serious.  It is definitely coded more sloppily than the
> Microsoft CoCo ROMs, true, but that mostly takes the form of wasted bytes
> rather than bugs.
>  
Well, circles that don't look like circles was a very obvious and annoying bug. I dont't remember precisely what were the other ones, but I do remember I used to run a patching program upon start-up to correct the most annoying ones. All in all, it seems to me that the SECB patching project had not been taken very seriously be either Tandy or Microware... or both.
>

This was not a "bug" per-se, but a trade-off between quick/approximate/simple code and slow/accurate/complex(large) code. What did the Basic circles look like on the C-64 or other computers of the time? You could also DRAW your own circles with much smoother results.

I'm sure they *all* had their fair share of bugs and quirks in their Basic compilers.


> None of this has any bearing on people buying OS-9,  which makes no use
> whatsoever of the Microware code.
>  
Well, well... Why didn't they (Tandy and/or Microware) made SECB capable of using the whole 128KB (or 512KB) of RAM? I'm not talking about being able to LPOKE/LPEEK all the address space, but being able to load larger programs and hold larger strings. To use the CoCo 3 memory to its full potential, you HAD to buy another product... like OS9, for example,
>

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!

The CoCo is flexible enough that you really don't need those things to take advantage of it's capabilities. LPEEK and LPOKE aside, you still have the power to use any/all of the memory you have installed. HGET/HPUT buffers are the easiest thing to switch to different 8K blocks and have entire different sets of graphics available to Basic (a 128K machine has 1 unused 8K block to play with.) This would also be a good way to add ML sound effects or subroutines to Basic. 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.

theother_bob
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      



More information about the Coco mailing list