18 replies to this topic

[maudib]

Hi, i saw a article about the atari homebrew scene on a website last friday...

i have some spare time (exams are over)...so i thought finding into the 2600 would be a nice idea...

i have alot experience in programming...also some ppc and x86 assembly...
and i've read yet most documents bout the 2600 i found...
(so don't trade me as an complete idiot please)

today i started writing my first kernel...everything is fine...nice background and so on...

so i thought a text scroller like in the ole c64 times would be cool....

my first idea was to have the player sprite display a line of the first character...then moved along the x axis and quickly changes to the next character and so on and so on....i think it's pretty clear

but unfortunally i haven't found a suitable method of doing this job...

because: i would have to change the sprite + position in 3cpu cycles (8colour cycles for the character + 1colour cycle for the space between the characters)

any ideas??


ps: i saw the text scroller on http://www.qotile.net/minidig/ but it was just to small...i want to have it over the full screen (or atleast half of it)

[maudib]

hm...i'm so stupid...sorry for this post...

hitting the resp0 is the easy solution (

anyway...that's gonna be nasty and ugly...

[Thomas Jentzsch]

It's quite simple: You can not do a wide text scroller with sprites. 48 pixels is the maxium.

The best full screen solution is using the playfield graphics. Quite blocky, but at least large enough.

[Andrew Davie]

maudib said:

because: i would have to change the sprite + position in 3cpu cycles (8colour cycles for the character + 1colour cycle for the space between the characters)

Correct, and since it would take you an *absolute minimum* of 4 cycles just to load the shape of the next character into the accumulator -- PLUS another three cycles to store the shape to GRP0.... and add in indexing so you can distinguish between characters... which means you'd probably have to use an indirect addressing mode, adding at least another two cycles... you're already going to need 9 cycles per character when you correctly calculated you have three. That's all without repositioning the sprite(s) which would take you at least another three cycles!

As Thomas said, it can't be done! But trying will teach you a lot, so have fun

[maudib]

Hi, i saw the demo of this homestar rpg...

and there were characters over the half screen....

does anybody know how he managed to do that?

[Tom]

maudib said:

does anybody know how he managed to do that?

flickering. say you want to display 12 sprites in a row, but you can really only do 6, so you could display six sprites in odd frames, and the other six sprites in even frames:

0 = player 0

1 = player 1



odd frame  0 1 0 1 0 1    

even frame  0 1 0 1 0 1   (sprites shifted 8 pixels to the right)



and on the screen you will see



001100110011

now this flickers awfully. homestar seems to alternate the sprites on each scanline, which gives a better result. but then you have the problem that you have to move the sprites every scanline either 8 pixels to the right or to the left, but using HMOVE you can only move max. 7 pixels to the left (8 to the right is possible). anyway, moving 8 pixels to the left can be done using early HMOVE trickery.

[Tom]

btw, if you look at the run_z26.bat which comes with the hsr demo then you'll see that z26 is started with the -f switch, which causes it to blend between frames. this simulates the afterglow of a tv screen, which makes the flickering less apparent.

[Paul Slocum]

Eckhard did a nice text scroller:

http://www.biglist.c...7/msg00006.html

I quit using the flickering text since we now have a routine that displays 13 characters without flicker. And with the last two characters are separated it's able to display up to 15 characters!



-paul

[maudib]

kk...

ok i started
writing some text functions

i try it currently this way:
both player sprites repeat 3 times...
they are moved like:
P0 P1 P0 P1 P0 P1 (i gave the players different colours so you can see it better)

and i have 2 problems:(look at the attachment)

1) theres something wrong with the first "A" ....dunno why...not that important

2) somehow i can't switch fast enought! the 4th character should be an "R"...

my question: is my way of doing the thing wrong, or probaly only the implementation??




paul: btw nice music

Attached Thumbnails

• 

[Nukey Shay]

I would guess that it's still not happening fast enough...the R character appears to be a mixture of R and T bitmaps. You might want to try transferring the bitmap data to a register prior to needing it (like transferring it to the stack pointer at the top of the loop and then pulling it off again). Also, double-check that none of your data tables are crossing pages (which would cause the read instructions to take 1 cycle longer when a page break is crossed).

[maudib]

ok here are some simple calculations:

i have 16 colour clocks for changing the register
that means ca 5 cpu cycles:

lda (Sprite),y

sta GRP0

takes me 8 cycles right?

pla

sta GRP0

takes me 7 cycles...i've just saved 1 cycle...

so i still need 2 cycles less...


what the hell is my problem?

is it just my stupidity?

[Thomas Jentzsch]

Check the [stella] mailing list for 48 pixel routine explained:
http://www.biglist.c...4/msg00137.html

Warning: It is very tricky, you have to understand quite a lot about the 2600 hardware :!:

[Thomas Jentzsch]

Paul Slocum said:

[maudib]

Thomas Jentzsch said:

Check the [stella] mailing list for 48 pixel routine explained:
http://www.biglist.c...4/msg00137.html

Warning: It is very tricky, you have to understand quite a lot about the 2600 hardware :!:

hm...my DNS can't resolve that adress...

would anybody be so nice and post it here?

thx

[CPUWIZ]

In a burst of frustration at my invaders program (can't find the cycles to
make the invaders look like anything but Super Breakout rejects), I figured
out the scores routine. I dunno if this has been done before, but the lack
of comments on the code to draw the text in Greg Troutman's game
(everything else is highly commented) and in the 48-pixel highres routine
in Okie Dokie's source indicate that nobody quite understands it yet.

The key is the vertical delay registers, and the fact that they don't do
vertical delay at all. As the "big file" says, there are actually TWO
graphics registers for each player.. I'm going to call them GRP0, GRP0A,
GRP1, and GRP1A. Again as the "big file" says, bit 0 of VDELP0 toggles
between whether GRP0 or GRP0A is used for the player 0 display, and VDELP1
toggles using GRP1 or GRP1A for the player 1 display. For this routine,
both vertical delay registers must be set, so GRPxA will always be used.

The tricky part lies in when GRP0A and GRP1A load. When GRP0 is written to
(with any value), GRP1A receives the contents of GRP1. When GRP1 is
written to, GRP0A becomes equal to GRP0.

You're "supposed" to write GRP0 and GRP1 at the beginning of alternating
lines, so when the vertical delay register is set, any write to GRP0 does
not take effect until a write to GRP1 occurs, which occurs on the next
scanline.

Here's the code for it again (from Okie Dokie). GRHEIGHT is the number of
scanlines for which we want to do this. Player 0 has been set to pixel 123
(including horz blank) and Player 1 has been set to pixel 131. So the
digits begin at pixels 123, 131, 139, 147, 155, 163. A series of six
16-bit pointers to the digits reside at GRTABLE, in RAM. In the table on
the right, D# means digit number # of the score. (if you're using a
windows mail reader, make sure to use a fixed-width font or the table will
be even messier than most 2600 code)

Cycles Pixel GRP0 GRP0A GRP1 GRP1A

loop2
ldy GRHEIGHT ;+3 63 189
lda (GRTABLE),y ;+5 68 204
sta GRP0 ;+3 71 213 D1 -- -- --
sta WSYNC ;go
lda (GRTABLE+$2),y ;+5 5 15
sta GRP1 ;+3 8 24 D1 D1 D2 --
lda (GRTABLE+$4),y ;+5 13 39
sta GRP0 ;+3 16 48 D3 D1 D2 D2
lda (GRTABLE+$6),y ;+5 21 63
sta TEMPVAR ;+3 24 72
lda (GRTABLE+$,y ;+5 29 87
tax ;+2 31 93
lda (GRTABLE+$A),y ;+5 36 108
tay ;+2 38 114
lda TEMPVAR ;+3 41 123 !
sta GRP1 ;+3 44 132 D3 D3 D4 D2!
stx GRP0 ;+3 47 141 D5 D3! D4 D4
sty GRP1 ;+3 50 150 D5 D5 D6 D4!
sta GRP0 ;+3 53 159 D4* D5! D6 D6
dec GRHEIGHT ;+5 58 174 !
bpl loop2 ;+2 60 180

At the *, the value written to GRP0 does not matter.. what does matter is
that this write triggers GRP1A to receive new contents from GRP1. A "!"
indicates that that register is being used for displaying at that moment.

Looking at it a different way:

sta GRP0 ;digit 1 -> GRP0
WSYNC
sta GRP1 ;digit 2 -> GRP1, digit 1 = GRP0 -> GRP0A
sta GRP0 ;digit 3 -> GRP0, digit 2 = GRP1 -> GRP1A
*Digit 1 (GRP0A) begins displaying
*Digit 2 (GRP1A) begins. One pixel later, the next instruction completes.
sta GRP1 ;digit 4 -> GRP1, digit 3 = GRP0 -> GRP0A
*Digit 3 (GRP0A) begins. Two pixels later, the next instruction completes.
stx GRP0 ;digit 5 -> GRP0, digit 4 = GRP1 -> GRP1A
*Digit 4 (GRP1A) begins. 3 pixels later, the next instruction completes.
sty GRP1 ;digit 6 -> GRP1, digit 5 = GRP0 -> GRP0A
*Digit 5 (GRP0A) begins. 4 pixels later, the next instruction completes.
sta GRP0 ;any value -> GRP0, digit 6 = GRP1 -> GRP1A
*Digit 6 (GRP1A) begins.

The basic idea is that we preload GRP0A, GRP1A, and GRP0 for the first
three digits well ahead of time, then load the last three digits into our
three registers and fire them off in rapid succession at the correct time..
then one more GRP0 strobe is needed to make GRP1A update one more time.
Using the "A" registers lets us preload three digits instead of two, so
that we have enough registers to hold the rest of the digits. Note that we
always update GRP0A while GRP1A is being displayed, and vice versa.

My hat's off to the programmers who came up with this thing - "Wow. The
above routine just drew the score with no cycles to spare." Now that we
know how it works (did it in fact make sense to anyone?), it could be
modified to display at different horizontal positions.

Ouch, my brain hurts now.. I think I'll go play Super Breakout =)

[CPUWIZ]

Whoops, forgot the quotes around it, that is the text from the link.

[Nukey Shay]

You also forgot to disable smilies

[Nukey Shay]

BTW here's the above with text formatting preserved...

                      Cycles  Pixel    GRP0   GRP0A   GRP1   GRP1A



loop2

 ldy  GRHEIGHT       ;+3  63  189

 lda  (GRTABLE),y    ;+5  68  204

 sta  GRP0           ;+3  71  213      D1     --      --     --

 sta  WSYNC          ;go

 lda  (GRTABLE+$2),y ;+5   5   15

 sta  GRP1           ;+3   8   24      D1     D1      D2     --

 lda  (GRTABLE+$4),y ;+5  13   39

 sta  GRP0           ;+3  16   48      D3     D1      D2     D2

 lda  (GRTABLE+$6),y ;+5  21   63

 sta  TEMPVAR        ;+3  24   72

 lda  (GRTABLE+$8),y ;+5  29   87

 tax                 ;+2  31   93

 lda  (GRTABLE+$A),y ;+5  36  108

 tay                 ;+2  38  114

 lda  TEMPVAR        ;+3  41  123              !

 sta  GRP1           ;+3  44  132      D3     D3      D4     D2!

 stx  GRP0           ;+3  47  141      D5     D3!     D4     D4

 sty  GRP1           ;+3  50  150      D5     D5      D6     D4!

 sta  GRP0           ;+3  53  159      D4*    D5!     D6     D6

 dec  GRHEIGHT       ;+5  58  174                             !

 bpl  loop2          ;+2  60  180

 sta GRP0            ;digit 1 -> GRP0

 WSYNC

 sta GRP1            ;digit 2 -> GRP1, digit 1 = GRP0 -> GRP0A

 sta GRP0            ;digit 3 -> GRP0, digit 2 = GRP1 -> GRP1A

 *Digit 1 (GRP0A) begins displaying

 *Digit 2 (GRP1A) begins. One pixel later, the next instruction completes.

 sta GRP1            ;digit 4 -> GRP1, digit 3 = GRP0 -> GRP0A

 *Digit 3 (GRP0A) begins. Two pixels later, the next instruction completes.

 stx GRP0            ;digit 5 -> GRP0, digit 4 = GRP1 -> GRP1A

 *Digit 4 (GRP1A) begins. 3 pixels later, the next instruction completes.

 sty GRP1            ;digit 6 -> GRP1, digit 5 = GRP0 -> GRP0A

 *Digit 5 (GRP0A) begins. 4 pixels later, the next instruction completes.

 sta GRP0            ;any value -> GRP0, digit 6 = GRP1 -> GRP1A

 *Digit 6 (GRP1A) begins.

[maudib]

thanx alot...