6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Jun 26, 2024 8:32 am

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Tue Dec 14, 2021 4:25 pm 
Offline

Joined: Sun Nov 28, 2021 7:38 am
Posts: 8
Hello,

I am so frustrated and exhausted :shock: Hope some good developer can help me…

I have made a simple VIC-20 program (attached), which waits for the raster beam, changes the color once the line is detected and on the next line it changes it back, so it draws a line. And it should stay like that. It loops forever, but sometimes SOMETHING goes wrong, so the background is filled with line color and itn result it blinks.

I cannot find what can possibly go wrong. Or could that be caused by the VICE emulator (I have not tested it on real VIC-20)?

I have recorded a video: https://youtu.be/Df-67EqRFkY

Here is the code:
Code:
*=$1001

  BYTE $0B, $10, $0A, $00, $9E, $34, $31, $30, $39, $00, $00, $00

SCREEN_COL_BORDER equ $900F     ; Screen and border register
RASTER_BEAM_LINE  equ $9004     ; Currently drawn raster beam line

program_init:

        lda #%01011011          ; Black background and border
        ldy #%00001011          ; Red background and border
loop:
        ldx #50                 

red_line:                       ; Draw red line
        cpx RASTER_BEAM_LINE    ; Wait for raster line 50
        bne red_line
        sty SCREEN_COL_BORDER   ; Set the red color

        ldx #51

rest_black:                     ; Fill rest with the black color
        cpx RASTER_BEAM_LINE    ; Wait for raster line 51
        bne rest_black
        sta SCREEN_COL_BORDER   ; Set the red color
        jmp loop               ; Go tot start


Last edited by stenlik on Tue Dec 14, 2021 4:55 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 14, 2021 4:37 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10834
Location: England
Hi! I'm no expert, but I'll chip in with the observation that by waiting for the very next line, you might be in a race against time. Might an interrupt come in and take a lot of time, such that waiting for line 51 (or 31 according to your comment) is going to wait almost a whole frame, because the line is past?

I'd suggest trying for a 10 or 20 line band and see if that works any better.

(Or, change the branch so it's a relative comparison rather than a comparison for equality.)


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 14, 2021 5:03 pm 
Offline

Joined: Sun Nov 28, 2021 7:38 am
Posts: 8
Hello BigEd,

Thanks for the answer. See my comments:

Quote:
but I'll chip in with the observation that by waiting for the very next line, you might be in a race against time.

I have tried it, but it did not help... I am using the VIC-20 PAL emulator version with 1.108.405 Hz 6502 CPU. Given the PAL is 50Hz and there are 371 lines per screen it gives me 1.108.405/ (50*371) = 71 cycles per line, which even if the line start is detected with few cycle delays immediately should be sufficient.

Quote:
or 31 according to your comment

My bad sorry - I have fixed the comment.

Thanks a lot
Petr


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 14, 2021 5:51 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10834
Location: England
Right, 71 cycles is a lot for your code, but what might an interrupt handler take? If you disable interrupts, is your program more reliable?


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 15, 2021 4:38 am 
Offline

Joined: Sun Nov 28, 2021 7:38 am
Posts: 8
Hi BigEd,

Quote:
Might an interrupt come in and take a lot of time, such that waiting for line 51 (or 31 according to your comment) is going to wait almost a whole frame, because the line is past?

Quote:
Right, 71 cycles is a lot for your code, but what might an interrupt handler take? If you disable interrupts, is your program more reliable?

I should have read your comment more carefully in the first place !! You are right - interrupt routines from KERNAL are still set and handled. Calling SEI just helps to make my example wor.

You made my day. :D :D :D :D

Quote:
Or, change the branch so it's a relative comparison rather than a comparison for equality.

Please -what do you mean by that, please? I am curious to learn something new.

Thanks a lot
Petr


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 15, 2021 5:48 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1938
Location: Sacramento, CA, USA
stenlik wrote:
Quote:
Or, change the branch so it's a relative comparison rather than a comparison for equality.

Please -what do you mean by that, please? I am curious to learn something new.

Thanks a lot
Petr

Hi, Petr. I think Ed is talking about possibly deleting the ldx #51 and changing the bne rest_black to bcs rest_black to limit the damage to just a line or two instead of a whole frame if an interrupt causes you to miss your trigger. It's the assembly language way to change the wait loop from while (RASTER_BEAM_LINE!=51) ; to while (RASTER_BEAM_LINE<=50) ; in the C vernacular.

A beq rest_black should also work, changing the wait loop to while (RASTER_BEAM_LINE==50) ;.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 15, 2021 8:18 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10834
Location: England
Thanks Mike - indeed, I was thinking of BCS or BCC, but couldn't quite be bothered to figure out exactly which. The idea is to ask if we are at, or past, the target, rather than asking if we are exactly at the target.

Such a change will also give you a visual flicker which will allow you to estimate how long those interrupt routines run for!


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 15, 2021 3:46 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1938
Location: Sacramento, CA, USA
BigEd wrote:
Thanks Mike - indeed, I was thinking of BCS or BCC, but couldn't quite be bothered to figure out exactly which.

I know what you mean. It took me several edits to get it to where I felt confident enough to leave it and go to bed, and I must admit that I'm still only 90% sure I got it right. I think the beq proposal burns fewer brain cells and still gets the job done.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Last edited by barrym95838 on Wed Dec 15, 2021 3:52 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 15, 2021 3:49 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10834
Location: England
Hey, it starts at 50/50, so 90% is pretty good!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 67 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: