Making 48 pixels wide picture, saving the last 8 bits?

[MemberAtarian]

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

[Lillapojkenpåön]

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 

 

 

[MemberAtarian]

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.

 

[Lillapojkenpåön]

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 

[MemberAtarian]

I understand how pointers work, but I don't think they would be neccessery for a single tanks like this.

[+splendidnut]

What does your setup/sprite positioning code look like?  Are you setting the player delay registers (VDELP0, VDELP1)?

[MemberAtarian]

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

[alex_79]

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.

 

[MemberAtarian]

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.

[+splendidnut]

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.

[+Karl G]

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.

[MemberAtarian]

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

[MemberAtarian]

By early, I mean this.

[+Andrew Davie]

You'd probably have more people help you, if they got the impression their help was valued.

[MemberAtarian]

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.

 

[+SpiceWare]

Part of the discussion in this short topic should help you gain an understanding of 48 pixels and VDEL.

[MemberAtarian]

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.

[MemberAtarian]

Fantastic, guys, it works!  Just have to add the rolling colors.

Edited August 30, 2019 by MemberAtarian

[+SpiceWare]

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.

[+splendidnut]

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. 

[MemberAtarian]

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).