RE: [stella] Reflex: Source of PAIN!

Subject: RE: [stella] Reflex: Source of PAIN!
From: "Lee Fastenau" <stella@xxxxxxxxxxxxxxx>
Date: Mon, 5 Apr 2004 12:02:23 -0500

Thank you for taking the time to pour over the source code.  Truth is, I had
been itching to make this code more modular since I began this project, and
it means a lot to me that a veteran such as yourself thinks it's a worthy
reference for beginners.

> It is very clear and well written, and an excellent example of how to code
> things properly.  Intuitive use of subroutines, logical grouping of
> functions and clear and easy to understand code.  This is an
> excellent piece
> of code for use as a "how to".  It is also tackling a game
> concept which is
> interesting, yet not too difficult as to be too tricky as a first project.
> So, i admire the style - not to mention the speed of development.  Some of
> that is due to the style, of course.

The change in coding style is relatively new.  I tore the program down and
put it back together as subroutines that revolve around a series of game
"states."  It gives me much more flexibility as a programmer.

> Looks to me like you're a Delphi/Pascal programmer, judging by your
> first-letter lowercase, following words capitalised first letter format :)

Actually, that's our standard casing for JavaScript and VBScript where I
work.  But I do have a Pascal background.  It was my first compiled

> I'd say comments are a tad sparse -- especially for
> beginners.

Maintaining comments in a block of code as I'm working on it can get
tedious.  I will dedicate some time each week to add/update comments.

> The use of the standardised macros (eg: CLEAN_START) is pleasing.

Why reinvent the wheel? :)

> The use
> of 'subroutine' to identify subroutines -- totally not necessary, but
> extremely good style because it aids readability.  The use of local labels
> within subroutines -- again, not necessary, but does prevent unexpected
> branches to inside routines, and clarifies the scope of labels/loops.

I even have subroutines with labels that aren't referenced anywhere else,
but they do help tremendously with keeping track of everything.  Local
labels are great and I think the way DASM implements them is very intuitive.
Merlin for the Apple II, by contrast, implements local labels in a rather
unintuitive and confusing manner.

> The
> variable declarations are of a style I don't myself like (byte,
> word) -- but
> that's just a style issue.  Overall, it's clear that you're a particularly
> cautious programmer.

There are a few different ways to declare variable space, so I picked what I
thought was the cleanest.  I just hope it's not too difficult for people to
port it to other assemblers.

> However (and there's always a however!), it is not always going to be
> possible to code this way.  I wouldn't like people to think that
> this style
> of coding is the norm and all the other programs are poorly written.  When
> you are pushing the very limits of your ROM size, and you need to fix one
> more bug, and you have 10 bytes left and you NEED 20, you find yourself
> sacrificing clarity, readability and sanity to get those extra bytes.
> Suddenly your structure goes to pieces and you start to realise the real
> value in sphagetti code.... destroy the structure and run the threads of
> execution in a knotted mess to save a byte?  sure, go for it!

I completely agree, and stated almost the same in a previous reply to Kirk.
This breakout concept has allowed me to code with a more traditional
(high-level) programming structure.  I mean, even the game section of the
display kernel is a single, simple module.  I don't think I could have
picked a better project to begin with.  It's allowing me to code in a
familiar way, doesn't require too many TIA tricks, and (above all) it's
appealing to gamers!

> Sometimes, even 2 levels of subroutines are just too expensive.
> Sometimes,
> the extra 12 cycles required for a subroutine call/return are out of the
> question.  Now that you are very close to mastering the
> fundamental "how to"
> program the '2600 (and, again, great job!) -- it will be interesting
> watching you 'push the envelope' which is, of course, your next challenge.

It's been a blast so far, and I can never spend enough time coding.  It may
not be the tightest or most elegant way to build a game for the Atari 2600,
but it's certainly been educational.  I'm already thinking about ideas for a
followup project.  I'm not going to say I want a "greater" challenge because
I think each and every program has its own unique challenges.  I just hope
to make another game that's fun to build and play!

> Overally, I don't have anything to criticise in this effort.
> You've clearly
> studied other people's code and suggestions, and the stella posts
> carefully.

This list and everyone that participates in it ... words can't describe.
This has been some of the best programming collaboration I've ever

> Well done!

Thank you!

> PS: I would love to see this program's source code included on
> the AtariAge
> "2600 Programming for Newbies" forum as an example of clear and
> understandable source code for beginners to learn from, or even on the
> companion CD to my "Programming the '2600" book.

I'll followup on this. :)

Again, thanks!

PS: Yeah, I thought about the uppercase constants ... maybe the next
project. :)

Archives (includes files) at
Unsub & more at

Current Thread