maudib Posted May 30, 2004 Share Posted May 30, 2004 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) Quote Link to comment Share on other sites More sharing options...
maudib Posted May 30, 2004 Author Share Posted May 30, 2004 hm...i'm so stupid...sorry for this post... hitting the resp0 is the easy solution ( anyway...that's gonna be nasty and ugly... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 30, 2004 Share Posted May 30, 2004 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 31, 2004 Share Posted May 31, 2004 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 Quote Link to comment Share on other sites More sharing options...
maudib Posted May 31, 2004 Author Share Posted May 31, 2004 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? Quote Link to comment Share on other sites More sharing options...
Tom Posted May 31, 2004 Share Posted May 31, 2004 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. Quote Link to comment Share on other sites More sharing options...
Tom Posted May 31, 2004 Share Posted May 31, 2004 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. Quote Link to comment Share on other sites More sharing options...
Paul Slocum Posted May 31, 2004 Share Posted May 31, 2004 Eckhard did a nice text scroller: http://www.biglist.com/lists/stella/archiv...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 Quote Link to comment Share on other sites More sharing options...
maudib Posted May 31, 2004 Author Share Posted May 31, 2004 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 Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted May 31, 2004 Share Posted May 31, 2004 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). Quote Link to comment Share on other sites More sharing options...
maudib Posted May 31, 2004 Author Share Posted May 31, 2004 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? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 31, 2004 Share Posted May 31, 2004 Check the [stella] mailing list for 48 pixel routine explained: http://www.biglist.com/lists/stella/archiv...4/msg00137.html Warning: It is very tricky, you have to understand quite a lot about the 2600 hardware Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 31, 2004 Share Posted May 31, 2004 Quote Link to comment Share on other sites More sharing options...
maudib Posted May 31, 2004 Author Share Posted May 31, 2004 Check the [stella] mailing list for 48 pixel routine explained:http://www.biglist.com/lists/stella/archiv...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 Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted May 31, 2004 Share Posted May 31, 2004 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 =) Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted May 31, 2004 Share Posted May 31, 2004 Whoops, forgot the quotes around it, that is the text from the link. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted May 31, 2004 Share Posted May 31, 2004 You also forgot to disable smilies Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted May 31, 2004 Share Posted May 31, 2004 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. Quote Link to comment Share on other sites More sharing options...
maudib Posted May 31, 2004 Author Share Posted May 31, 2004 thanx alot... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.