At 11:05 AM 2/15/2003 -0500, you wrote:
There has been a lot of activity in the 2600 homebrew arena lately and I
would hate to see these vanish. Have you seen the AtariAge in
development page lately? There are now 22 known titles being worked on
for the 2600.
That's got to be a record since the homebrew scene first started up. The
previous hotspot was back in 1997 and then around the time Gunfight and
Thrust were in development. Hopefully all the titles listed really ARE in
active development
I have to say that I'm glad to see Glenn pick Death Derby back up. I'm
really interested in seeing that completed too.
I wish the circumstances in which I now find myself having more time on my
hands were different. But it's important to make the best out of a bad
situation.
I hope to be able to submit a new work-in-progress within a week or so that
is a LOT closer to a playable demo than was ever possible before Thomas
wrote the kernel. I'm making incremental progress each day.
A word of advice to programmers... Tackle one subroutine at a time. When
you reach each milestone, no matter how insignificant, be proud of
yourself, and don't be ashamed to put it aside until tomorrow. To be able
to add _any_ feature to a 2600 game in progress without breaking your
kernel or running out of resources is a cause for pride for any fledgling
VCS coder. It also pays to ruminate over the tiny details
overnight. Maybe you'll come back the next day and rewrite it to use less
ROM or fewer cycles. Don't feel the need to rush. As long as you work on
it consistently, like a regimen, it's going to come together. Since I come
from a rapid development dayjob, the temptation is to try to make huge
leaps of progress in marathon all-nighters. It's good therapy for me to
pace myself out and not expect such instant gratification. I think this
approach is closer to the XP (Extreme Programming) approach. I don't think
this works for all types of projects but I think it is ideal for the 2600
because it emphasizes testing above all else. The most important thing is
to know WHY something doesn't work as planned. It's a lot easier to deduce
the root cause when you are making only the smallest alterations to the
code at a time before testing.
In my case I'm learning how to debug 6502 at the same time (using PCAtari,
which actually runs on my system) and it REALLY PAYS to sit there and
single-step through your code side by side with a DASM source listing and
watching the registers change. I know a lot of developers try to debug in
their head and use trial and error methods. Only the very earliest 2600
coders had to do that. There is nothing more wasteful of time than trial
and error coding, trying to guess where the bugs are.
I just wish Cyberstella finally had its interactive debugger. I'd love to
be able to load a BIN and load its matching DASM source listing into an
emulator and be able to step debug over my code and see all my labels and
comments in the actual debugger.
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
