[Coco] SECB (was:Re: RAINBOW vinyl records?)

[Paul Fitch]

I remember when I got my 1st Coco, my roommate got a Vic-20.  He then
immediately upgraded to a C-64 as soon as he could.  I remember their basic
listings having so many pokes in them, I thought "Whats to point of trying
to learn basic on this machine, when you can't figure out what all the pokes
are doing when you read the listings?" 

> -----Original Message-----
> From: coco-bounces at maltedmedia.com 
> [mailto:coco-bounces at maltedmedia.com] On Behalf Of theother_bob
> Sent: Sunday, August 16, 2009 2:34 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: [Coco] SECB (was:Re: RAINBOW vinyl records?)
> 
> 
> 
> 
> 
> ----- 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
> 
> 
> 
>       
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>