[Coco] SECB (was:Re: RAINBOW vinyl records?)
theother_bob
theother_bob at yahoo.com
Sun Aug 16 14:33:46 EDT 2009
----- Original Message ----
From: Christian Lesage <hyperfrog at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sunday, August 16, 2009 4:07:15 AM
Subject: Re: [Coco] RAINBOW vinyl records?
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.
>
I don't think anyone would argue that SECB was the best it could have been.
>
>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.
>
Yeah, I think most of us expected it to be easier to access the additional memory.
Wonder how many product returns were due to this non-implementation.
>
>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.
>
I'm not using an assembler nor am I an ML programmer. I can look at the ROM dissassembly and figure out what it's doing though, and figure out ways to make small patches to better leverage the existing code.
You can do everything I'm doing in plain-vanilla 128K basic too. It will just take longer. I *chose* to use patches because I want better results than plain vanilla basic can deliver.
Yes, SECB has lots of flaws. It could have been better but it could have been worse. A few POKEs are not that big a deal. With minimal behind the scenes work you can fool people into thinking Basic is ML. In fact, reading the ROM dissassembly and figuring out small patches is a GREAT way to teach yourself a little something about ML, just like other people's Basic listings help you learn Basic techniques.
I also typed in a few Commodore programs back in the day, probably 60% POKEs, and that's probably why I think the CoCo's Basic (even SECB) was light-years better than others. I do wish Tandy had done a better job at the time, but it is what it is. IMHO there's *still* no better Basic to play around in.
Cheers,
Bob
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list