Just Jeff

I'm glad to hear people saying this. This has been my approach- do it manually otherwise I'll never learn it. Also the reason I skipped over Batari Basic.

Overscan: sta WSYNC inx cpx #52 bne Overscan 52 lines of overscan? Then you fall into more routines after that? Also your VBLANK is missing again..

OK I'll check those out in a bit. And correction.. cycle 48. Thanks. So it is done then? I need consistent lines I suppose. If I recall from the Collect series, the .byte $2C trick keeps the cycles consistent with the bcs DoDraw branch time right?

tschak909....Appear, not move. So I'd store either zero or the playfield data right at cycle 38 for the right side. Most other times for the left.

Good Afternoon, I want to do a reflected asymmetrical playfield where PF2 sometimes appears left of center, sometimes right. Is that possible or practical? Should i just try PF1 instead? Or don't even try reflected asymmetrical? Thanks for the help!

No tool but I use this because it also shows some other useful stuff: http://www.6502.org/tutorials/6502opcodes.html#BIT and this TIA timing chart: http://atariage.com/forums/topic/29326-session-18-asymmetrical-playfields-part-2/

Hello.. I stuck this routine in my kernal to draw the ball. Is it efficient enough (20 cycles) or should I do something else? Same question for missiles: Ball: lda #BALL_HEIGHT-1 ; 2 2 dcp BallDraw ; 5 7 bcs DoDrawBall ; 2 9 lda #0 ; 2 11 .byte $2C ; 4 15 DoDrawBall: ; lda #2 ; 2 17 sta ENABL ; 3 20 Thanks!

Its working fine for me in Stella already, but I moved your VBLANK here and it still worked. VerticalBlank sta WSYNC inx cpx #37 bne VerticalBlank lda #0 sta VBLANK

Not sure if it matters but I think you are turning off VBLANK before your vertical blank loop starts

OK.. Let me know what to do. I have the manuals too..

Still need any of these?

Nah- I'm not familiar with C. I'd like to be, though. Same for Linux. I saw Draconian on YouTube and was blown away so I thought I'd look into the DPC+. But given what you've told me, I should probably complete at least one functioning 2K game first, before looking into it again. That will give you more time to finish as well Thanks!

Interesting... Is it really 128K? Its strange that a 6K .asm would produce that.

Hi.. I came up with 166 cycles- what to you have? Also, I prettied up your .asm a little. I think it helps to line up the comments and add nice big headers. Maybe put in where you think line 2 starts. And I added the cycle counts. I assure you there are errors (sometimes I can't tell if I'm doing something to the accumulator or the operand) so don't replace anything you have with it.. Its just an example. Maybe someone can take a look at it and correct. Also, you have a nop in there. You could probably get rid of it by shuffling stuff around- a nice reason to have those cycle counts right there in the .asm. dodgeballedit.asm

That was fun. Berzerk never gets old.

Yeah that's what I was looking for. Is this for any machine in particular?

Hmm I'm tempted to try this but it may get me off track. Do you think this helps the novice Stella programmer by adding capability and flexibility? Or do the added complications just make it too difficult?

I know the .bin is on his blog..

Nice look!

I found this a few years back and found it to be fascinating. https://www.youtube.com/watch?v=wc6CYLFjKoo

Cool.. I've been looking for something like this. But this one isn't for Stella... Is there one?

I like it!

Interesting- so assume this is to avoid having to cross a page boundary which can cause timing issues- right?

Hi... Close.. I'm using Collect Mini so that isn't in there. I did manage to figure it out though.. This program has 5 separate bands in the kernal which are mostly identical for now. This issue is in band (#3) where I added a DoDraw routine for the playfield. So this only appears in band #3: lda #PILL_HEIGHT-1 ; dcp PillDraw My first 2 bands didn't dec PillDraw so it only started decrementing in band 3 and therefore thought it was at the top of the screen. This whole time I was thinking that since the Y register was decrementing in all of the bands I was fine. Thanks again!

So I tossed it and started over. I put the graphics in ROM instead of RAM, and copied the technique for displaying the players verbatim. I even duplicated the player graphics for the playfield graphics. I figured I'll start there and then try to switch to RAM and do the other things later. Its working better, except for 2 things For some reason the Y axis is different than the players so it started low and got cut off- so I put in different values until it showed up more in the center. (I just realized this is that same line that Omegamatrix told me to look at before- still having a problem there I guess.) The line works for the players so I don't know why its such a problem with the playfield. Also, as you can see, the bottom of the playfield player gets cut off and stuck on his head.