From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
> Nick's vcs.h is missing a few things, and Ekhard's doesn't have any
> register value constants, which I find makes source more readable when you
use.
>
> That's why I thought people should start using the merged version I put on
> the Death Derby homepage. Or maybe have a separate header called
> vcs_constants.h and make Ekhard's the standard.
This is an ongoing nuisance-level problem. I've run into the missing
stuff in Nick's vcs.h several times, yet many people use this file.
If I put my own equ's in, as I've been doing, it will generate a
double-definition error should one use a complete vcs.h.
It doesn't help that all these files are named vcs.h, never nickvcs.h
or atarivcs.h. BTW, what did the original Stella designers at Atari
and their competitors use? This habit must have become enshrined
in the very early days, yet it's a wheel that has been reinvented
several times.
I'd think we should insist on a complete vcs.h that has all the registers
describbed in the stella manual. Yet there is a whole legacy of folks
who started out with "how to draw a playfield" and are still using
Nick's vcs.h. While I agree that (1) it makes the code more readable
to put the definitions in an external file and (2) it makes the code more
readable to use value constants, which should also be in an external
file, with the constants you have no standardization. One can at
least compare vcs.h with stella.pdf and say "well, that should be in
there but it isn't."
The stella manual tells us what the registers are named, so there
is no ambiguity. You have no excuse for deciding to call HMP0
P0_Horiz_Motion. This is not the case with value constants.
Suppose I decide P_TwoMedium should be P_2MED or
P_Dbl_Med? There is no authority to say "that's wrong,"
so these definition files could end up doing the Darwin's Finch
thing.
My suggestions would be:
1. If the vcs.h you used is on the web, include the URL in the
source. This has the drawback that it could go away one day,
especially if it's not on your own website.
2. If you use a constants file, make it separate from vcs.h and
always post it with the source, or post a URL with the source.
This means you must keep the files together, or again maintain
the web link for the life of the file.
3. You could attach these files to all postings along with the
source. They're not very long, but it's still an annoying and
redundant waste of bandwidth.
4. DASM doesn't require declarations to be at the beginning of
the file. If you want to be sure the recipient can compile it,
include these universal definitions in the source but put them at
the _end_ so you don't have to skip past them to get to the code.
This wastes just as much bandwidth as #3 but isn't as
in-your-face about it.
One thing I have noticed about using vcs.h is that, among its
other annoying habits, DASM lumps "unused" and "unresolved"
vars together in the listing. Since most vcs.h constants aren't
used in any particular program, it makes this DASM feature
worthless for finding unresolved vars that you misspelled or
forgot to target. I have been scrolling through the -L3 list file
looking for zeroes in the object code to find these errors.
Just my US$0.02 on the situation.
--Roger Williams
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
