Re: [stella] VCSC.H version 1.0

Subject: Re: [stella] VCSC.H version 1.0
From: "B. Watson" <urchlay@xxxxxxxxxxxxxxxx>
Date: Tue, 27 Nov 2001 13:16:52 -0500 (EST)
On Tue, 27 Nov 2001, Glenn Saunders wrote:

> Please discuss..
> I was thinking this should have some conditional assembly in there for the
> colors.

The conditional assembly would be great... then you could put -DPAL or -DNTSC
on the dasm command line...

One consistency issue... you've got MIXED_Case, Mixed_Case, and MIXED_case
labels... I'm not going to insist on my preference (all_lower_case), but
you should probably standardize the capitalization if you're going to use
it... pick one scheme & stick with it for all the constants, or you'll
drive people nuts. Remembering what case to use for each character means
remembering twice as much information as just remembering how to spell
the label, if you use the same capitalization scheme for them all then
the programmer only has to remember that one scheme.

Better still would be to do away with mixed case and stick with all upper
or lowercase... The whole purpose of these constants is to reduce the
amount of memorization required.

Of course, there's a -i flag you can pass to dasm to make it treat labels
case-insensitively... too bad there's no way to turn on this option inside
your .asm file, then people like me could just turn it on right after the
`processor 6502' directive and other people could compile our code without
having to read it & see the comment that says `use dasm -i -f3 to compile'

I'd add a directive like this to dasm, but the general consensus here seems
to be that we should stick with what we have now, rather than create
mutually incompatible versions that all appear to be the same thing. There's
a lot of merit in this (Just look at the mess that was Unix in the 1980's..
or even today)

I know I'm probably making a bigger deal out of this than it really is, but
consider... you're creating a standard include file that everyone is going
to use (or anyway lots of people). You should make it as programmer-friendly
as possible, even if it means making it more complex. Once you standardize
on something, you're stuck with it forever (like x86 processors or the Unix
standard C library. Bad design decisions made 20 years ago are still being
paid for now...)

OK, I'll get off the soapbox now, sorry bout that....


Archives (includes files) at
Unsub & more at

Current Thread