I've had related thoughts. In my ideal dream free time to
screw around fun in a barrel world, I would write a coolass
little development toy that let you write 2600 games in
C----. The catch is that the kernel(s) would be prewritten.
You'd pick which ones you wanted to use for which portions
of the screen (for starters, some standard score-display kernels
and a main screen kernel). You could then design your sprites and
backgrounds in a GUI tool (as we've seen several of lately) and write
your *game logic* in C----.
And that is doable, because there's some significant time (in 2600 terms)
to actually "think" about what the next frame's sprite positions and so on
should be during vertical blank and overscan. The programmer would be
given three main functions to write: init() (executed before the game
kernel gets underway as anything but black screen), and then
vblank() and overscan() which would be invoked on every frame. We'd
stub in helpful comments explaining that this is where game logic can go...
and if your display goes awry, move more code to the other function;
and if your display still goes awry, you have too much code. (:
(We can't always or even usually tell them in advance that they
have too much code -- halting problem. But we can drop hints.
As long as the actual kernels are written in native 6502, I think this is
viable. Give people byte variables a-z and a single byte array A[]
plus constants and constant arrays and they will produce
some cool things -- think Level 1 BASIC's constraints but with a sane C-like
syntax. There's no shortage of smarts available at *compile time*, it's
only at runtime that we're hurtin' so bad. We could let people
name variables anything they like of course and we could let them
have more than one array as well, but I think the Level 1 BASIC
comparison is helpful in thinking about what's possible.
We do want to require strict declarations up front so that the compiler
can decide exactly what address each variable lives at and break the bad
news at compile time when (not if (: ) the naive programmer
exceeds what the hardware can do.
Java has taught us a lot about how much the compiler can do
to guarantee that only a certain amount of memory will be used.
We don't actually need the full smarts of a Java compiler here!
But that, and the impressive little language offered by
the TICkit embedded PIC programming system, got me thinking
about what can be done here.
Of course we can't guarantee that subroutines won't crush the
stack, but we could produce helpful reminders at compile time
("you wrote a subroutine! good! please tell us it's not recursive!").
We'd want workhorse kernels that did a tolerable job of rendering
more than two sprites, with flicker ideally only when things overlap
vertically and force flicker.
Now I know that the resulting games would not be as groundbreaking
and distinctive as all-from-scratch 2600 games. But as you say, it would
broaden the hobby. And the actual creating of the tool itself
would be *very* groundbreaking and distinctive, since everyone has
taken it as an article of faith that it Can't Be Done. (:
I'd love to get in on writing this. A partner (or more than one!) would
help. I've realized I don't have the time to write it all myself.
Plus, not having written a complete 2600 game, I'm probably
not the ideal candidate to write the workhorse kernels. But I *can*
write recursive descent compilers and I do know my way around the
instruction set and the 2600 guts (I wrote an emulator once many
years ago, which was able to start up Adventure, and I put in some
time on a 2600 game this past fall). So I'm not just blowing
smoke here.
--
Thomas Boutell
Boutell.Com, Inc.
http://www.boutell.com/
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
