[stella] Steller Track kernel alignment

[stella at casperkitty.com]

>>
> Incidentally, it might be interesting to take advantage of the "HMOVE 
left
> 8" trick (using cycle 74 HMOVEs) so that the sprites shift left and  right
> eight pixels instead of seven.
 
That sounds like a great idea! But does it work consistently on all 
versions 
of the 2600? I've heard that some tricks don't work as expected  on, say,
the 
2600-jr, or something like that, but I can't remember the  details.
<<

I don't know the exact details of the 2600jr issue, but my understanding is
that on SOME late-model Juniors it is necessary to use different HMOVE
values when doing cycle 73 and/or cycle 74 HMOVEs.  These Juniors actually
provide somewhat greater versaility on their HMOVEs than a "classic" 2600,
though there's really no practical way to capitalize on that.

>>
Oddly enough, I was just thinking about working on a letter-oriented game  
for the 2600, and I'm planning to use a "flicker-blinds" kernel for it-- if
I  
understand that term correctly. Does it refer to spacing the three-copy
players 
 as follows?
<<

Your diagram came across a bit messed up (why can't email clients properly
deal with normal TTY format text anymore!?) but I think you understand it.

>>
My plan is to use that method, and draw letters that are 5x10, with a blank

pixel between each letter, which would allow 16 letters across (96 pixels  
divided by 6).
<<

Two major caveats:

-1- I don't know how you'll manage it without using extra RAM.  If your
font is 8 dots high, you'd need 48 bytes to hold the necessary bitmap. 
Further, you'll need quite a few scan lines before each row of text to
prepare the bitmap.

-2- The second character in each group of three will have a visible "seam"
in the middle of it that may prove distracting.

>>
And if necessary, the missiles can be positioned alongside each player to 
create  a "9-bit wide" player, to help eliminate gaps.
<<

Unless you want an extra pixel after each group of three characters, you'll
need to shift sprites left and right by 8 pixels rather than 7 to avoid
gaps.  Missiles won't help because you won't have time to enable/disable
them mid-line.

>>
But two possible ways 
to  provide a large number of puzzles might be (1) to use a larger amount
of 
ROM to  store the puzzles in (i.e., a 32K cartridge rather than a 4K
cartridge); 
or (2)  to use the MemCard to store puzzle data, so that either new
"volumes" 
could be  released-- i.e., buy the game cartridge for the main game engine 
and the initial  set of puzzles, then (if desired) buy a MemCard programmed
with 
additional  puzzle data-- or players could create their own puzzles and
save 
them on a  MemCard. Does that sound like something that could be doable
with 
the MemCard?  (I'm still kind of ignorant about it.)
<<

The Memcard should be workable for that.

>>
Then again, it would be 
more  difficult to use the playfield pixels to create blocks between the
words, 
so  maybe I should stick with just 12 letters per row after all? Hmm, it
looks 
like  I've got some rethinking to do. :(
<<

Twelve characters per row is apt to be much more practical.  It should be
noted that Realsports Tennis uses a 5x5 font (+1 dot horizontal) for player
names, allowing eight charcters to be entered, BUT it does it by using 30
bytes of RAM for a bitmap buffer.  Tennis doesn't need a whole lot of RAM
for other things, but your game probably would.


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .