Ooh... that's somewhat... disappointing.
It's of course nice to see some good works by 2600 artists, but I think
there should be something possible much better than that...
>Well, I'll give you the stats on the last version I did, which switches the
>data which is read between two different memory sections. The idea was to
>create a cart that maximizes data space.
Ah, yeah, right... but I think maybe adding some code would have saved some
data space which is unusable now...
I would have done this a different way. I remember back in 1987, I ripped a
scrolling engine off a C-64 crackers' intro and put it into two of my own
intro's... to "Sailing" (coupled with the Rod Stewart song), and "Sinbad"
(coupled with the song "So cold the night" by the Communards).
The intro in its original form basically scrolled a magnified text across
the screen (20 characters at one time, each 8 pixels wide), as this cart
does, but it used the entire screen width.
As I had to alter the text, I analyzed what the program did and realized it
was using sprites for displaying the characters.
And the text was stored as text, not as graphics like here.
Since I analyzed the code of that intro, I can tell you what it did:
It had a character set (64 or 128 chars, I don't exactly remember), and an
"offscreen buffer" of the text height.
Basically, it used 7 sprites next to each other (remember, each sprite on
the C-64 is 3 bytes long). The first 8 lines of every sprite display the
text, the remainder's empty. On every scrolling cycle, each sprites' content
(the visible lines only, of course) is shifted 1 pixel to the left, and the
pixel "lost" gets shifted to the next sprite on the left. For the rightmost
sprite, the shifted bit comes from the "offscreen buffer", which gets filled
with a new character every 8 scrolling cycles.
I thought this had to be doable on the 2600 too. You could display a
standard 6-digit score display and feed it from the "scrolling region" which
is in RAM. This region could be set up so that it's easy to scroll it, such
as:
Line 1: $90,91,92,93,94,95,96 (96 not visible)
Line 2: $97 through 9D (not visible)
... and so forth until line 7 or 8.
To speed things up, the bytes of one line are scrolled with an instruction
each, instead of doing a loop, such as:
ROL $96,X
ROL $95,X
ROL $94,X
ROL $93,X
...
where X would be decreased by 7 after each line. (I don't know if ROL was
the right command, but I think so).
The idea would basically be to display the content of the scroll buffer
(without the rightmost byte of every line) like a score counter, and update
its content while the beam is offscreen. This way you need 56 bytes of RAM
for the data (calculating with 8 pixel high letters), and this is both
fittable into the 2600's RAM and also fast enough to scroll in an offscreen
cycle. There could occur some trouble with the character table, but even the
C-64's character table (256 chars x 8 pixels) is only 2K long, and you'd in
return only use up 1 byte per character of text you write. And you could of
course further compress the character table to 64 or 128 characters which
should be enough for most purposes.
I also think there are some faults in the following:
>For the final version, the program took up the entire 4K-- there are -200
>bytes of actual code which does the computations, and since each letter is
>7 pixels high, I have data from between $F200 and $F8FB (each $100 is for
>one seventh of the character), and from $F900 to $FFFB. For scrolling
>action, there has to be 24 bytes of $00s on each side of the text (so that
>the text will scroll offscreen. This is because I used a 4-digit graphics
>routine).
What's a 4-digit graphics routine? And what are the 24 $00's on every side
for? I tried the ROM image with z26, and it displays only 2 players (16
pixels wide), so 2 bytes on every side, in my opinion, should be enough.
>So this makes 256 bytes per line (ie -F200 to -F300) minus 4
>bytes for the startup vector and minus 48 bytes for the $00s on both sides.
Due to my calculations, it should be 256 - 4 for startup vector - 4 for 00
bytes = 248 bytes on each line.
>I did end up losing another 24 bytes due to an overlapping
>difficulty in the other memory section. So this makes 204 + (204-24) bytes
>= 384 bytes total for the entire 4K. So, since each letter on a keyboard
>ends up being approximately 4 pixels across, that leads to about 96
>characters possible. Whew!
Ouch!!! There's a huge mistake in here! Even if you can only use 384 bytes
on every line, it still means every line is 384 bytes wide, isn't it?...
BYTES, not bits! 384 bytes are 3072 bits, which divided by an average 4
pixels per character still give 768 characters possible. I'm afraid you just
junked away 7/8 of your available memory space. This is definitely not what
should be done in a 2600 program... (even if some PC programmers seem to be
used to it meanwhile)
OK, if you feel your cart is really finished, then go ahead and market it...
but there's a definite risk of someone like me coming up with a much better
version... so maybe you want to re-think that... ;-)
With love (and many letters scrolling on the screen),
Kurt Woloch
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
