Getting started with the DPC+ Kernel

[Cybearg]

The jumpy.bin displays 262 lines. Where does it bounce on you? Does it bounce on real hardware?

 

I dun geddit. jumpy.bin runs at a rock solid 262 for me. I forget, is that a bad number?

 

That's what I've been trying to say. The game is rock solid at 262 lines, even before I cut everything else out.

 

But the very first frame (which I could only see by using the reboot command) hits 270 scanlines. That's my only hint as to a reason of why the playfield bounces on real hardware.

 

EDIT: Note, it hits 270 scanlines on the first frame even if I do a drawscreen immediately after my kernel options are set on the first bank.

 

Maybe you can see my frustration now. ;P

Edited March 6, 2013 by Cybearg

[RevEng]

Reboot always throws off the scanline count. Honestly it hasn't been a problem for any game that used it for years. As I said, the TV will lock on your normal frames almost immediately.

 

The jumbled mess appears to be a bug introduced in 1.1d. I'm looking at that right now.

 

I suspect your bouncing is another bug. It wasn't in 1.1c, which I've been using.

[Omegamatrix]

That's what I've been trying to say. The game is rock solid at 262 lines, even before I cut everything else out.

 

But the very first frame (which I could only see by using the reboot command) hits 270 scanlines. That's my only hint as to a reason of why the playfield bounces on real hardware.

 

EDIT: Note, it hits 270 scanlines on the first frame even if I do a drawscreen immediately after my kernel options are set on the first bank.

 

Maybe you can see my frustration now. ;P

 

You don't need to worry about the first frame. If you try different games on your Harmony cart you will notice they all bounce when you start them up. When I was talking before about initializing the timer... well that is just my thing where I try and get the game into a good state as quickly as possible. I'm really trying to make the bounce as short as possible. But whether or not I do it ultimately won't matter after the first frame anyhow, so don't sweat it.

[+Atarius Maximus]

Atarius Maximus, you're right about vblank, but in recent versions of the DPC+ kernel there's no useful time left in vblank. It's a moot point to the bouncing issue, because he's not trying to use vblank time.

Good point, he's not using it either way. Didn't know about there being no useful time left in vblank regardless. Thanks for pointing that out.

[Cybearg]

Don't get distracted by the fact that I used reboot to check to see what the first frame was. I didn't hit the reset button on a real 2600 and in the example above, the code to reboot isn't even there, yet there is still bounce.

 

So unless there's something I did wrong in how I initialized my playfield there, I don't see why it should bounce. It's not even being called every frame--just the first (since it's not being cleared, that shouldn't be an issue).

 

I really have no clue why it's not working.

 

I suspect your bouncing is another bug. It wasn't in 1.1c, which I've been using.

Are you saying that you just tried compiling the code I posted with 1.1c and testing it on a Harmony and it worked fine without the bounce?

Edited March 6, 2013 by Cybearg

[Omegamatrix]

Don't get distracted by the fact that I used reboot to check to see what the first frame was. I didn't hit the reset button on a real 2600 and in the example above, the code to reboot isn't even there, yet there is still bounce.

 

What exactly do you mean by "reboot". Describe how you are re-booting please.

 

Edit: I just looked in Stella, and I see no reboot button. What do you mean by re-booting the rom?

[Cybearg]

What exactly do you mean by "reboot". Describe how you are re-booting please.

 

It doesn't matter in the context of my problem.

 

But bB has a "reboot" command. I checked the Assembly for it, since you asked. It's this:

 

JMP ($FFFC)

 

... So it just jumps to the first line in the entire code, apparently.

Edited March 6, 2013 by Cybearg

[RevEng]

The reboot command in bB just does a "JMP ($FFFC)"

[iesposta]

Your compiled jumpy.bin jumps on my Harmony.

Must be an older file of something in your compile environment.

[Omegamatrix]

The reboot command in bB just does a "JMP ($FFFC)"

Now I understand. I don't think you will be able to avoid a bounce in this case as there seems to be alot of time spent in the initialization. Actually it looks like a lot of time is spent in the clear loop. You might be able to cut that down at the expense of few bytes though. I'm not sure if it would be a good fix but it might help.

[Cybearg]

Now I understand. I don't think you will be able to avoid a bounce in this case as there seems to be alot of time spent in the initialization. Actually it looks like a lot of time is spent in the clear loop. You might be able to cut that down at the expense of few bytes though. I'm not sure if it would be a good fix but it might help.

Meaning that there's not enough cycles to initialize the playfield?

 

If it was just that there aren't enough cycles to draw the playfield, that would be no problem; I'd just have to have a drawscreen command before the playfield is drawn, but that doesn't fix the bounce. I could drawscreen before the playfield and after the playfield and it would still bounce. (I know because I've tried it.)

Edited March 6, 2013 by Cybearg

[Cybearg]

Your compiled jumpy.bin jumps on my Harmony.

Must be an older file of something in your compile environment.

Have you tried compiling the code I posted earlier to see if it jumps for you?

 

Would anyone be willing to send me a zipped copy of all the kernel files that are confirmed working with DPC+? Can anyone confirm that bB 1.1d works with DPC+ on 2600 hardware?

[Omegamatrix]

Meaning that there's not enough cycles to initialize the playfield?

 

I was looking at the cycles goobled up by the clear loop, really. If you look at what BB does, and actually most games do as well, then you'll see the first thing the programmer usually does is clear all of his ram and set the TIA registers to a known state. This took about 36 scanlines roughly. I made a quicker clear loop here that uses way more bytes, but takes roughly 10 lines or so. It can be made to quicker still, but you have to try to strike a balance between the byte usage vs cycle savings.

 

Anyhow I have to go now, but you can play around with it and see if it helps for "reboot". You'll probably have to get RevEng or someone else who knows assembly to stick it in the start-up routine. He will also know how to modify it further if need be. The old clear loop started at $18E5 and took 8 bytes. This takes 19 bytes, but will gain you about 26 scanlines during reboot hopefully. It really also comes down to the timer values, and the way that BB works this cycle saving routine might actually take longer than before if the timer transition is missed. You'll have to try and see. If the scanlines are still too much then you might have to update the timer too.

 

 

    lda    #0
   ldx    #$2C
   txs
.loopClear
   pha
   pha
   pha
   pha
   pha
   pha
   tsx
   cpx    #$7E
   bne    .loopClear
   ldx    #$FF
   txs

[Cybearg]

Neat, but, Omega, I didn't care about the reboot. I don't even plan to use the reboot command at all (I haven't up to this point--I prefer to keep the game logic running and just set a variable that returns things to the start).

 

My problem is with the playfield bouncing, which doesn't have anything to do with rebooting. I didn't want you to get stuck on the rebooting thing because I really need help with this bouncing thing and the reboot stuff if a moot point.

 

EDIT: Besides, if I wanted a more efficient clear/restart, I'd use Andrew Davie's "ultimate programmer" clearing method:

 

   ldx #0

   lda #0

Clear

   sta 0,x

   inx

   bne Clear

Edited March 6, 2013 by Cybearg

[iesposta]

I compiled your posted .bas

It jumps on my Harmony also.

[Omegamatrix]

Uh, okay. I thought you said it was rock solid and "reboot" was giving you the problem. Hence my solution.

 

That's what I've been trying to say. The game is rock solid at 262 lines, even before I cut everything else out.

 

But the very first frame (which I could only see by using the reboot command) hits 270 scanlines.

 

 

Neat, but, Omega, I didn't care about the reboot.

 

EDIT: Besides, if I wanted a more efficient clear/restart, I'd use Andrew Davie's "ultimate programmer" clearing method:

 

ldx #0
lda #0
Clear
sta 0,x
inx
bne Clear

 

Just as a side note, that routine is not the ultimate clearing method either.

[+Atarius Maximus]

Neat, but, Omega, I didn't care about the reboot. I don't even plan to use the reboot command at all (I haven't up to this point--I prefer to keep the game logic running and just set a variable that returns things to the start).

 

My problem is with the playfield bouncing, which doesn't have anything to do with rebooting. I didn't want you to get stuck on the rebooting thing because I really need help with this bouncing thing and the reboot stuff if a moot point.

 

EDIT: Besides, if I wanted a more efficient clear/restart, I'd use Andrew Davie's "ultimate programmer" clearing method:

 

ldx #0

lda #0

Clear

sta 0,x

inx

bne Clear

I was just checking one last time before I sign off, but I would be curious to see the link to where you grabbed Andrew's code. The link you posted seems to be broken. I'll be back on Thursday...

[Cybearg]

Uh, okay. I thought you said it was rock solid and "reboot" was giving you the problem. Hence my solution.

Sorry for the confusion. Those are separate things:

 

1. My game's playfield jumps around on real 2600 hardware, which is odd because:

 

2. According to Stella, the scanlines remain at 262 at all times, but:

 

3. I assumed that the scanlines must have gotten off sometime immediately when the game begins, so:

 

4. I added in the reboot command so I could check the scanlines of the first frame in Stella (by restarting the game once it was already open in debug mode), and sure enough, the first scanline (and ONLY the first scanline) was over 262, so I assumed that:

 

5. There must be something wrong in that first frame, which led me to find:

 

6. The first frame with DPC+ always goes over 262 scanlines, so I assumed that the fault was with DPC+

 

Don't mean to condescend with that, but hopefully it's a bit clearer now.

 

I really don't see what could be wrong in my code. It's about as bare-bones as it can get. Even calling a drawscreen immediately after the kernel options are initialized still results in a playfield bounce.

 

I was just checking one last time before I sign off, but I would be cuirous to see the link to where you grabbed Andrew's code. The link you posted seems to be broken. I'll be back on Thursday...

Huh... It works for me. The link is for Andrew Davie's 12th Assembly lesson, "Session 12: Initialization"

[iesposta]

I figured out the jumpy.

It is even a topic I had started and was answered about a jittery playfield.

You have to have

 

DF0FRACINC = 32

DF1FRACINC = 32

DF2FRACINC = 32

DF3FRACINC = 32

DF4FRACINC = 64

DF6FRACINC = 64

in your main loop before/with the drawscreen.

Also you have 22 pfcolors: 23 bkcolors: and 22 playfield:

(don't know if that matters)

 

You can also have DF6FRACINC = 0

and

 

bkcolors:

$00

end

 

instead of using all $00

[Cybearg]

The 23rd bkcolor is the color that goes behind the score. If I only have 22, it will be some other color I don't want.

 

Let me give this a shot and see if that fixes it, but thank God, finally there's a solution! Phew, I was starting to get really nervous.

 

Is there anything I can do to set the player or background to be all one color?

 

EDIT: That absolutely fixed it! Thank you so very, very much! Even going back to the version I had before I cut out all the game logic runs silky-smooth now. What a relief!

 

That's definitely a tip that should go in this thread, but I think we should get a mod to cut out all the extra posts and put them in a different thread, since I'm afraid I've somewhat derailed this quick-tip getting started thread.

Edited March 6, 2013 by Cybearg

[iesposta]

One more thing... there is a VbB 566 version, and there is no bank 7

[Cybearg]

One more thing... there is a VbB 566 version, and there is no bank 7

That would explain why I couldn't actually put things in bank 7, though I'm assuming it's still there, but you're just not allowed to actually place stuff in it yourself and instead the assembled code stores the actual graphics bytes in it, correct?

 

And where can one find vBb 566? I've got 565.

Edited March 6, 2013 by Cybearg

[iesposta]

DF6... = 0 gives you 1 background color

 

DF4... = 0 gives you 1 playfield color

(I had it mixed up above.)

[iesposta]

 

That would explain why I couldn't actually put things in bank 7, though I'm assuming it's still there, but you're just not allowed to actually place stuff in it yourself and instead the assembled code stores the actual graphics bytes in it, correct?

 

And where can one find vBb 566? I've got 565.

 

Here: http://www.atariage.com/forums/blog/302/entry-9759-small-update-for-visualbb/

[iesposta]

I said, "You don't need include div_mul.asm"

That statement is false. I thought it was unnecessary.

Divide by 10 will error unless you have this.