Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 6, 2013 Author Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 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? Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 The reboot command in bB just does a "JMP ($FFFC)" Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 Your compiled jumpy.bin jumps on my Harmony. Must be an older file of something in your compile environment. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 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? Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 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 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 I compiled your posted .bas It jumps on my Harmony also. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted March 6, 2013 Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted March 6, 2013 Author Share Posted March 6, 2013 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... Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 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" Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 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 2 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 One more thing... there is a VbB 566 version, and there is no bank 7 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted March 6, 2013 Share Posted March 6, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 DF6... = 0 gives you 1 background color DF4... = 0 gives you 1 playfield color (I had it mixed up above.) Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 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/ Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 6, 2013 Share Posted March 6, 2013 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. Quote Link to comment Share on other sites More sharing options...
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.