MemberAtarian Posted August 30, 2019 Share Posted August 30, 2019 (edited) I want to do a 48 pixels wide pic for a game over screen in ASM, I have rewrote the code 4 times, but never was able to make it work. It will be a "two liner", the even lines add color while the odd lines decrase the Y as it is the counter. You can see down there the plan, but I'm now inserting only the odd line. So i made NUSIZ0 and NUSIZ1 #$03, added some horizontal fine positioning and I spent hours with changing RESP0, RESP1, HMP0, HMP1, but it had really no effect on the result, there were three kind of useless results, one with no fine positioning, so there were two black lines between the pairs, one with the first GRP1 too early, and the one you can see at the bottom, with the last GRP1 too late beacuse I had to move S to X and that takes 2 cycles. Making a 40 pixels wide picture is like a piece of cake, but why should I be satisfied with only 40 pixels? As you can see, I use all the registers for saving the values (there is not really other way since TIA goes three times faster then the CPU, so while the CPU does STA it drawns one 8 pixel wide sprite), after I saved the two very first value, I have A, X, Y for saving and S for storing. My question is, how can I rearrenge this to move S to X (since there is no way to save S directly), so I can save the last values of the picture in time? line_0 LDA Skull_00,y STA GRP0 LDA Skull_01,y STA GRP1 sleep 5 LDA Skull_02,y sta temp4 ldx Skull_03,y lda Skull_04,y ldy temp4 sty GRP0 stx GRP1 sta GRP0 tsx stx GRP1 dec temp7 ldy temp7 ldx Skull_05,y txs ldy temp7 sta WSYNC bpl line_0 lda #0 sta GRP0 sta GRP1 Edited August 30, 2019 by MemberAtarian Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted August 30, 2019 Share Posted August 30, 2019 Why don't you look at the assembly in one of your many titlescreens? My loop looks like this Ldy #logoheight Logoloop Sta wsync Sty temp1 Lda logo0,y Sta grp0 Lda logo1,y Sta grp1 Lda logo2,y Sta grp0 Ldx logo4,y Lda logo5,y Sta temp2 Lda logo3,y Ldy temp2 Sta grp1 Stx grp0 Sty grp1 Sta grp0 Ldy temp1 Lda logocolor,y Sta colup0 Sta colup1 Dey Bpl Logoloop Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 8 minutes ago, Lillapojkenpåön said: Why don't you look at the assembly in one of your many titlescreens? My loop looks like this Ldy #logoheight Logoloop Sta wsync Sty temp1 Lda logo0,y Sta grp0 Lda logo1,y Sta grp1 Lda logo2,y Sta grp0 Ldx logo4,y Lda logo5,y Sta temp2 Lda logo3,y Ldy temp2 Sta grp1 Stx grp0 Sty grp1 Sta grp0 Ldy temp1 Lda logocolor,y Sta colup0 Sta colup1 Dey Bpl Logoloop To be fair, I checked at least 3 of them. Even the simplest six digit score loops if I could modify them, the one I showed you was some kind of my experiences. Gonna check this one after I took care of a monitor the post injured for me. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted August 30, 2019 Share Posted August 30, 2019 Oh yeah now that you mention it i remember they are over complicated and use pointers and a shared 48pixel subroutine that I never understood myself Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 I understand how pointers work, but I don't think they would be neccessery for a single tanks like this. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted August 30, 2019 Share Posted August 30, 2019 What does your setup/sprite positioning code look like? Are you setting the player delay registers (VDELP0, VDELP1)? 1 Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 35 minutes ago, splendidnut said: What does your setup/sprite positioning code look like? Are you setting the player delay registers (VDELP0, VDELP1)? VDELP only helps if you are using sprites, ball and missiles around without a fixed position, so you can set thing in one line and set others is the next one. lda #0 sta WSYNC sta VBLANK sta ENAM0 sta ENAM1 sta ENABL sta COLUBK sta COLUPF sta COLUP0 STA COLUP1 lda #230 sta TIM64T ldy #41 WaitABit sta WSYNC dey bpl WaitABit sleep 31 sta RESP0 sta RESP1 lda #$d0 sta HMP0 lda #$e0 sta HMP1 LDA #$03 STA NUSIZ0 STA NUSIZ1 ldy #43 sty temp7 lda #$1e sta COLUP0 sta COLUP1 sta HMOVE sta WSYNC Quote Link to comment Share on other sites More sharing options...
alex_79 Posted August 30, 2019 Share Posted August 30, 2019 20 minutes ago, MemberAtarian said: VDELP only helps if you are using sprites, ball and missiles around without a fixed position, so you can set thing in one line and set others is the next one. This is not correct. Despite the name (VDEL stands for Vertical Delay), the delay is NOT triggered by the start of the next scanline but rather by writes to the other player GRPx register. The Stella Programmer's Guide is a bit misleading on this subject as it mostly describes VDEL in the case of its originally intended use (write to GRPx registers on alternate lines but still allow single line vertical motion). Using VDEL is the ONLY way to accomplish the 48 pixel display. Without it, there's no way you can update all the gfx in time. The code posted above by Lillapojkenpåön requires both VDELP0 and VDELP1 set to work. 2 Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 3 minutes ago, alex_79 said: This is not correct. Despite the name (VDEL stands for Vertical Delay), the delay is NOT triggered by the start of the next scanline but rather by writes to the other player GRPx register. The Stella Programmer's Guide is a bit misleading on this subject as it mostly describes VDEL in the case of its originally intended use (write to GRPx registers on alternate lines but still allow single line vertical motion). Using VDEL is the ONLY way to accomplish the 48 pixel display. Without it, there's no way you can update all the gfx in time. The code posted above by Lillapojkenpåön requires both VDELP0 and VDELP1 set to work. Tryied on my code just being curious, did not change much. Still have to work on my monitor, I will try this in the night. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted August 30, 2019 Share Posted August 30, 2019 30 minutes ago, MemberAtarian said: VDELP only helps if you are using sprites, ball and missiles around without a fixed position, so you can set thing in one line and set others is the next one. Welp... that's the last time I try to help you. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 30, 2019 Share Posted August 30, 2019 The reason the VDEL trick works and is needed is because you effectively have an extra byte stored in a buffer that you can put in place quickly. If the CPU had another register that could be used, the trick wouldn't be needed. Turning on VDELP* will also require you to tweak the timing of your routine due to the added delay. I'll make my best attempt at explaining it here. When VDELP* is enabled for both players, writing to the GRP* register actually writes to a buffer register, and whatever is in the buffer for the other GRP* register gets written to the actual register. In comments below, I'll use brackets, e.g. [GRP0] to indicate the register buffer instead of the actual register. So, your 48-pixel routine will first do the first 3 writes before anything is displayed on the line: lda whatever1 sta GRP0 ; whatever1 -> [GRP0] lda whatever2 sta GRP1 ; whatever2 -> [GRP1] -- [GRP0] -> GRP0 lda whatever3 sta GRP0 ; whatever3 -> [GRP0] -- [GRP1] -> GRP1 At this point, we have the actual GRP0 containing "whatever1", and the actual GRP1 register containing "whatever2", and "whatever3" is in the buffer for GRP0. We then load up the registers with the remaining graphics, and do the first write after the first copy of P0 is displayed: lda whatever4 ldx whatever5 ldy whatever6 sta GRP1 ; whatever4 -> [GRP1] -- [GRP0] -> GRP0 stx GRP0 ; whatever5 -> [GRP0] -- [GRP1] -> GRP1 sty GRP1 ; whatever6 -> [GRP1] -- [GRP0] -> GRP0 sty GRP0 ; [GRP1] -> GRP1 Note for the last write for GRP0, we don't care what is actually written to that register; it is only done to put the buffer value for GRP1 into the actual GRP1 register. 1 Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 (edited) 9 minutes ago, Karl G said: The reason the VDEL trick works and is needed is because you effectively have an extra byte stored in a buffer that you can put in place quickly. If the CPU had another register that could be used, the trick wouldn't be needed. Turning on VDELP* will also require you to tweak the timing of your routine due to the added delay. I'll make my best attempt at explaining it here. When VDELP* is enabled for both players, writing to the GRP* register actually writes to a buffer register, and whatever is in the buffer for the other GRP* register gets written to the actual register. In comments below, I'll use brackets, e.g. [GRP0] to indicate the register buffer instead of the actual register. So, your 48-pixel routine will first do the first 3 writes before anything is displayed on the line: lda whatever1 sta GRP0 ; whatever1 -> [GRP0] lda whatever2 sta GRP1 ; whatever2 -> [GRP1] -- [GRP0] -> GRP0 lda whatever3 sta GRP0 ; whatever3 -> [GRP0] -- [GRP1] -> GRP1 At this point, we have the actual GRP0 containing "whatever1", and the actual GRP1 register containing "whatever2", and "whatever3" is in the buffer for GRP0. We then load up the registers with the remaining graphics, and do the first write after the first copy of P0 is displayed: lda whatever4 ldx whatever5 ldy whatever6 sta GRP1 ; whatever4 -> [GRP1] -- [GRP0] -> GRP0 stx GRP0 ; whatever5 -> [GRP0] -- [GRP1] -> GRP1 sty GRP1 ; whatever6 -> [GRP1] -- [GRP0] -> GRP0 sty GRP0 ; [GRP1] -> GRP1 Note for the last write for GRP0, we don't care what is actually written to that register; it is only done to put the buffer value for GRP1 into the actual GRP1 register. I will look at it in the night. My clients will be sleeping after 11 pm. 5 hours ago, Lillapojkenpåön said: Why don't you look at the assembly in one of your many titlescreens? My loop looks like this Ldy #logoheight Logoloop Sta wsync Sty temp1 Lda logo0,y Sta grp0 Lda logo1,y Sta grp1 Lda logo2,y Sta grp0 Ldx logo4,y Lda logo5,y Sta temp2 Lda logo3,y Ldy temp2 Sta grp1 Stx grp0 Sty grp1 Sta grp0 Ldy temp1 Lda logocolor,y Sta colup0 Sta colup1 Dey Bpl Logoloop Checked this. it could be perfect, but it loads logo2 too early. I even did change it to load it as late as possible, but it can't be helped, it writes logo2 instead of logo0. Logoloop Sta WSYNC Sty temp1 Lda Skull_00,y Sta GRP0 Lda Skull_01,y Sta GRP1 Lda Skull_05,y Sta temp2 Lda Skull_02,y Sta GRP0 Lda Skull_03,y Ldx Skull_04,y Ldy temp2 Sta GRP1 Stx GRP0 Sty GRP1 Ldy temp1 Lda SkullColors,y Sta COLUP0 Sta COLUP1 Dey Bpl Logoloop lda #0 sta GRP0 sta GRP1 Edited August 30, 2019 by MemberAtarian Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 By early, I mean this. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 30, 2019 Share Posted August 30, 2019 You'd probably have more people help you, if they got the impression their help was valued. 1 Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 18 minutes ago, Andrew Davie said: You'd probably have more people help you, if they got the impression their help was valued. I always thank after a really useful idea (like Karl G telling me how VDELP0 and VDELP1 works (I read a lot steven Hugg's book but these things did not catch my attention enough, I thought it's only for delay for a standart kernel with moving objects) or Lilla's kernel seems really useful, I couldn't fit Y decrease and color change at the same scanline. But just telling me about out of the blue like about the VDELP registers is nearly like "ask the pros doing it" (that's the typical answer in my country ), I'm not a programmer in my daily life, so it's harder for me to imagine things with a system like this that gives all the hard work for the programmer. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 30, 2019 Share Posted August 30, 2019 Part of the discussion in this short topic should help you gain an understanding of 48 pixels and VDEL. 1 Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 2 hours ago, SpiceWare said: Part of the discussion in this short topic should help you gain an understanding of 48 pixels and VDEL. Thank you, gonna check it. Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 (edited) Fantastic, guys, it works! Just have to add the rolling colors. Edited August 30, 2019 by MemberAtarian 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 30, 2019 Share Posted August 30, 2019 Great! I just realized I linked directly to reply 6, which is helpful, but there was more above it on VDEL. I fixed the link in my reply to link to the topic. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted August 30, 2019 Share Posted August 30, 2019 3 hours ago, MemberAtarian said: But just telling me about out of the blue like about the VDELP registers is nearly like "ask the pros doing it" (that's the typical answer in my country ), I'm not a programmer in my daily life, so it's harder for me to imagine things with a system like this that gives all the hard work for the programmer. I'm sorry... that was not my intention to make you feel like that. Granted, my post was brief (due to getting ready for work), but I thought that by mentioning the VDEL registers, it would help you or someone else realize what the issue was. I really was trying to be helpful, but the way you responded to that really put me off. It made me feel like you were telling me that I had no idea what I was talking about (like you were already a "pro")... Similarly to how you responded when I first posted about ChaoticGrill in the Homebrew Discussion forum. Maybe it's just me... Anyways... glad to hear you figured it out. Take care and keep doing cool projects. Quote Link to comment Share on other sites More sharing options...
MemberAtarian Posted August 30, 2019 Author Share Posted August 30, 2019 2 minutes ago, splendidnut said: I'm sorry... that was not my intention to make you feel like that. Granted, my post was brief (due to getting ready for work), but I thought that by mentioning the VDEL registers, it would help you or someone else realize what the issue was. I really was trying to be helpful, but the way you responded to that really put me off. It made me feel like you were telling me that I had no idea what I was talking about (like you were already a "pro")... Similarly to how you responded when I first posted about ChaoticGrill in the Homebrew Discussion forum. Maybe it's just me... Anyways... glad to hear you figured it out. Take care and keep doing cool projects. I'm not a pro (that would be great), I'm still using the main kernel of bB, but write most of my code in ASM. After I finished Dizzy as well, I will sit on my butt and figure out the basic all-purpose kernel I need. To be honest, I just started programming last year in February. I made once a strategy game called Dystopia, but my main goal is a monocrome (ZX Spectrum-like) 12 interlaced sprites kind of kernel with only extra RAM for addition (that really is needed for TBS, I don't think the VCS would handle an RTS at normal speed). 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.