+Cafeman #1 Posted January 2, 2003 I have many questions about just how some of the more advanced 2600 games were coded. I just don't understand the nature of the 2600 'kernel' I guess. I'm familiar with the 5200/8bit Display List w/interrupts which also features the Vertical Blank Interrupt and a main loop for the game-code. Perhaps the best way to ask is to mention specific games. Enduro -- the road borders -- are these 2 missiles? And the cars -- are they a Player? Each car is its own color. I imagine that there must be some kind of dynamically changing settings for just where the Player is split into each car. For example, say that on Enduro you can see 5 cars coming down the road. I am assuming all are made from the 2nd Player and that between each car, during a scanline the HPOS is altered and the color is altered and the proper 'size' of the car is drawn. So there have to be 5 of what I would call "DLI's" if I were coding the 5200/8bit, but in Enduro these are not frozen to a particular scanline; they instead move down the screen in relative position to each car. I have no idea how to program this since I've never coded or even seen code for a 2600 kernel. However, this method seems much more powerful than just simply using DLI's -- unless I could dynamically change the Display List data, which I've never tried. Hypothetically, if I wanted to program an Enduro-style game on the 5200, would I be better off to ignore ANTIC and the Display List and code a kernel? Or would a dynamically changing Display List be possible, where I would have 5 pointers into the Display List memory, and change these every frame to 'move' with the descending cars? I have more questions but rather than over-saturate this, I'll stop here. Feel free to post anything in response to my statements/questions! Quote Share this post Link to post Share on other sites
Nukey Shay #2 Posted January 2, 2003 I think that you might be overthinking it. You know that the 8-bit programs use display lists to set everything in place for a screen to be displayed. The 2600 has no display list (since it has no display memory). Everything that happens goes right up on the screen. So if you wanted to change a color or player00's location...you would just do it. No interrupt needed...since you are not interrupting anything (the display is being created regardless). As long as you have enough cycle time to carry out your instructions, the changes will go up on the screen. I prefer to think of Lucy in the chocolate factory when I think of the 2600's processing How you keep all of these changes in order...that is where the kernal comes in. Quote Share this post Link to post Share on other sites
EricBall #3 Posted January 2, 2003 Each 2600 game kernel is specific to the game. There is no DLI concept, although some games may make use of a simplified form to handle multiple full motion sprites. For a full understanding of the 2600 display, you should track down the "Stella Programmer's Guide". But basically the 2600's TIA is a 1-D graphics processor with two 8-bit player sprites, two missile sprites, a ball sprite and a 40-bit (half-screen) playfield. Any changes to the display have to be made by the kernel on the fly. Quote Share this post Link to post Share on other sites
DEBRO #4 Posted January 2, 2003 However, this method seems much more powerful than just simply using DLI's -- unless I could dynamically change the Display List data, which I've never tried. You can change the display list dynamically. When doing this you have to store your display list in RAM instead of leaving it in ROM. I was doing this in my 5200/8-bit demo/game I never finished Hypothetically, if I wanted to program an Enduro-style game on the 5200, would I be better off to ignore ANTIC and the Display List and code a kernel? Or would a dynamically changing Display List be possible, where I would have 5 pointers into the Display List memory, and change these every frame to 'move' with the descending cars? You would only need one DLI (at the start of the list) and use VCOUNT in your DLI to determine which scan line was being displayed. Quote Share this post Link to post Share on other sites
Thelen #5 Posted January 2, 2003 on the 8 bit you can change the player's color on every scanline, you'll have to make a sort of kernel like this : LDA PLAYERY ; Y POSITION PLAYER STA VC ;STORE IT IN VARIABELE VC LSR VC LDA VC TAY INY UNTIL STA WSYNC ;WAIT TILL OFF SCREEN CPY VCOUNT ;ARE WE AT LINE TO BEGIN CHANGING BNE UNTIL LDX #0 LOOP LDA COLTABP0,X STA COLOPM0 INX CPX #27 STA WSYNC BNE LOOP there is a register, vcount where a value is stored on what line the atari is drawing, if it's the line where the player is you can change color the example above can give a player 27 different colors, and the colors are stored at coltabp0 Thelen Quote Share this post Link to post Share on other sites
+Cafeman #6 Posted January 2, 2003 thelen: I understand the concept and the code. But with that method, wouldn't it lock up the processing until the scanline was hit? Say that I had one DLI which I entered on scanline one, then went into your loop. Say that the player was near the bottom of the screen. What would be the effect of my main loop of code while the DLI 'waited' to get to that scanline? It seems to me that I'd have to have all my code in the Vertical Blank Interrupt, or else I'd run into problems. Or am I overthinking things? Quote Share this post Link to post Share on other sites
DEBRO #7 Posted January 2, 2003 thelen: I understand the concept and the code. But with that method, wouldn't it lock up the processing until the scanline was hit? Say that I had one DLI which I entered on scanline one, then went into your loop. Say that the player was near the bottom of the screen. What would be the effect of my main loop of code while the DLI 'waited' to get to that scanline? It seems to me that I'd have to have all my code in the Vertical Blank Interrupt, or else I'd run into problems. Or am I overthinking things? That's pretty much what I gathered. Read the De Re Atari section on kernels. It should explain it all. Quote Share this post Link to post Share on other sites
+Cafeman #8 Posted January 2, 2003 Another question I have concerns 2600 Reactor. Are all those little sprites actually BG graphics, or a reused player? I detect no flicker. Yet the little particles seem too high-res to be bg graphics. Quote Share this post Link to post Share on other sites
DEBRO #9 Posted January 2, 2003 Another question I have concerns 2600 Reactor. Are all those little sprites actually BG graphics, or a reused player? I detect no flicker. Yet the little particles seem too high-res to be bg graphics. I never looked at Reactor before This is definately outside my scope You've got me interested now. I'll post a question on the Stella list and see if anyone bites. A quick disassembly shows they use missiles and balls but the ball has to be the same color as the PF. Quote Share this post Link to post Share on other sites
Jetboot Jack #10 Posted January 2, 2003 Kernals a la 2600 sure do slave the CPU - but there is still VBI and HB time to do stuff (for simple games like Enduro)... One alternate method would be to say do an Enduro style display in Antic E - enable DLI's on every modeline where the track and cars are to be, rather than use a kernal that locks the CPU to waiting for vcount. And then use a table drive when to call the appropriate DLI or not, create patterns to play back of car positions and the road's curves (done with horizontal scolling) or similar and then you could still perform plenty of code that way... Take a look at Great American Cross Country Road Race - Enduro for the 8bit basically... sTeVE Quote Share this post Link to post Share on other sites
Christopher Tumber #11 Posted January 2, 2003 Re: Reactor Uhhm, am I missing something - It seems pretty straightforeward? There's the player (presumably P0 or P1) and three particles which could be any 3 of P1, M0, M1 or B. Everything else is playfield graphics, except the rods which are whatever's left over of P1/M0/M1/B, flickered. Chris... Quote Share this post Link to post Share on other sites
Christopher Tumber #12 Posted January 2, 2003 >A quick disassembly shows they use missiles and balls but the ball >has to be the same color as the PF So change COLUPF [Playfield colour] mid-scanline? Chris... Quote Share this post Link to post Share on other sites
DEBRO #13 Posted January 3, 2003 Re: Reactor Uhhm, am I missing something Nah Chris, I think I'm missing something here...like a good working knowledge of Stella But I'm learning everyday. It just seemed like a lot of processing to me but I guess if that's what you have to do... Quote Share this post Link to post Share on other sites
Christopher Tumber #14 Posted January 3, 2003 >I think I'm missing something here...like a good working knowledge of >Stella Shrug, you seem to be getting by okay... >It just seemed like a lot of processing to me but I guess if that's what >you have to do... Ah, not really. There are huge open space on the playfield. Plenty of time to be messing around. All the kernal needs to do during a screen draw is: write to PF0/PF1/PF2 (Once - It's a symetrical playfield), determine if the Player/Particles/Rods need to be drawn and switch the playground colour back and forth (timing on that would be a little tricky as it needs to be adjusted as the core expands). Oh, yeah and draw the decoy if needed, but it flickers so it's probably multiplexed with the rods or something... Quote Share this post Link to post Share on other sites
+Cafeman #15 Posted January 6, 2003 I am adding to my own existing thread here, rather than gunk up the forum with another thread. My question today involves your opinion on scrolling (on 5200/Atari 8bit again). I'm not asking how to do it, since there seems to be adequate info available at the Atari Archives and De Re Atari etc, and I haven't really gotten down to the nitty gritty yet. However, I recall reading that either horizontal or vertical is easier to do than the other is. Any comments about this? Because for my first project, I definitely want to do it the easier of the two ways. I am assuming that Vertical is easier. I like scrolling, believe it or not I attempted some of it in Koffi Yellow Kopter but I was unsuccessful. Quote Share this post Link to post Share on other sites
DanBoris #16 Posted January 6, 2003 Vertical scrolling is much easier. To scroll vertically you just change the pointer to the start of video memory in the display list. This will give you course vertical scrolling, and you can use this along with the VSCROL register to do fine scrolling. With horizontal scrolling you have to setup each mode line in the display list to load a new memory pointer, then change all these addresses to scroll the screen. Horizontal also requires a slightly more complex layout of you video memory. Dan Quote Share this post Link to post Share on other sites
Heaven/TQA #17 Posted January 6, 2003 my 2 cents: re: enduro... there are many ways leading towards rome... so the easiest way is using 1 DLI per frame... : f.e. DLI pha txa pha loop lda player0_xpos_tab,x sta wsync sta hposp0 lda player0_color_tab,x sta colpm0 inx cpx #191 bcc loop pla tax pla rti and in the VBL you generate all necessary tables including updates... so you just need 1 DLI... if you like... i must say that you block the CPU nearly 192 scanlines with this "kernel"... so enduro is no problem... have a look into Activision's the great american cross country road race... which is an excellent game and i would it call "enduro deluxe"... as it has all the enduro features and a lot of more... even saving time scores... re: scrolling... dan, on atari it doesn't matter... both are easy... except that in vertcal scrolling you haven't think in "longer" scanlines..... but that's all... here is my new/old scrolling demo which i hacked together when i played around with the paralax scrolling... XASM... start equ $4000 ;start adress * hardware register dlistv equ 560 nmien equ $d40e dliv equ 512 vblv equ 548 wsync equ $d40a org start init jsr wait_vbl mva #0 nmien mwa #dlist dlistv mwa #vbl vblv mva #34 559 ;32 bytes per scanline - narrow screenmode mva #$40 nmien mva #$0f $d017 mva #0 $d01a loop jsr wait_vbl jmp loop wait_vbl mva #8 540 wait0 lda 540 bne wait0 rts vbl jsr scrolling jmp $e462 scrolling lda shscrol beq scroll2 dec shscrol lda shscrol sta $d404 rts scroll2 lda #3 sta shscrol sta $d404 inc lms rts shscrol dta 3 dlist dta $70,$70,$70,$52 lms dta a(scrolltext) dta $41 dta a(dlist) scrolltext dta d" this is a fucking scrolldemo....................." scrollend dta d" " run start hve Quote Share this post Link to post Share on other sites
Nukey Shay #18 Posted January 6, 2003 Such language for just a demo! Shame on you Quote Share this post Link to post Share on other sites
Heaven/TQA #19 Posted January 6, 2003 oops... i forgot... atari age is an american site.... sorry for that... we in germany have freedom of speech... ;) (just kidding...) hve Quote Share this post Link to post Share on other sites
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord