When I try and create cool colour bars, using timing, they seem to go thicker. Coders World wasn't a help at all. I put this listing inside an IRQ loop before JMP $EA31.

LDA #$38
LOOP CMP $D012
BNE LOOP

LDX #$00
BAR1 LDA colours,x
LDY timing,x
DELAY DEY
BNE DELAY
INX
CPX #$1F
BNE LOOP

When I enter this listing it displays a raster screen, reading the timing, but I get enormous flickering raster bars. Please can anyone help?

U need to either adjust your "Y" delay timer or use NOPs as they are more acurate than a simple loop.
Sometimes its where you set the interupt to start depending on the likes of music playing, scrollers etc. For example if the music was the problem then change its JSR routine to somewhere else in the interrupt.

oh my god...this was the system how I was coding rasterbars when I first coded them..

now I would use something like this..

ldx #$numberofbars
mainloop: lda $tableofcolors,x
ldy $d012
loop: cpy $d012
beq loop
sta $d020
sta $d021
inx
cpx #$20
bne mainloop

which probably would flicker though

so I could aslo use the trick (works for europe... american pipul add 2 cycles more ;-)

Bad Scan Line (we in dmagic call it Caroline ;-) - has 23 cycles
normal scan line has 63 cycles

nop is 2 cycles
lda $color,x is usually 4 cycles
sta $d020 is 4 cycles
cpx #$20 is 2 cycles
bne is as far remember right 3 cycles (just look it up in table of insturctions, it's necessary for such purposes)

construct the routine of nops and other instructions so every 8th line will have 23 cycles routine and the rest 7 lines will have 63 cycles routine..

for precise raster bars it's always good to have instruction table where you can see how many cycles routine eats..

sorry for lousy info but I work from memory now and as I'm musician I quite hate hardcore coding (but don't tell it to anyone pleeze ;-)))

Roman

LDA #$38
LOOP CMP $D012
BNE LOOP

LDX #$00
BAR1 LDA colours,x
LDY timing,x
DELAY DEY
BNE DELAY
INX
CPX #$1F
BNE LOOP <----This should be "BNE BAR1" (or am I just being pedantic, as usual! Maybe just a BIG typo or a lapse into forgetfulnes, Rich And to be more even pedantic, you missed out the STA$D02x's underneath the "BAR1" label! But, I guess you must have them in the code to actually see anything happening at all! )

Anywayz, I can't see anthing else wrong with it, really!! Apart for adjusting the code, as Roman says, to take into account the bad lines. (I have tried in vain, for many years, to make rainbow bars bigger than 8 lines, with solely a timing table - on the bad lines, there is always (I have found) too many cycles. Even with the value of 0 in the timing table for the bad lines, and BEQ (for X reg) before the DEX in the routine, doesnt work either! It seems impossible!)
_________________

This is a 100% working color raster made in Turbo Assembler

*=$1000
sei
lda #$50
sta $0314
lda #$10
sta $0315
cli
ever
jmp ever ;(Can be replaced with rts)

*=$1050
ldx #$00
lda #$3b
start
cmp $d012
bne start
nop
nop
nop
nop
nop
nop
loop
ldy timer,x
lda color,x ; (can be replaced with lda $0400,x
sta $d020 ; so that you can edit the colors direct
sta $d021 ; on the top of the screen)
delay
dey
bne delay
inx
cpx #$18
bne loop
jmp $ea31

*=$1100
timer
.byte $08,$08,$08,$08,$08,$08
.byte $08,$01
.byte $08,$08,$08,$08,$08,$08
.byte $08,$01
.byte $08,$08,$08,$08,$08,$08
.byte $08,$01
.byte $08,$08,$08,$08,$08,$08
.byte $08,$01

*=$1200
color
.byte $01,$00,$01,$00,$01,$00
.byte $01,$00
.byte $01,$00,$01,$00,$01,$00
.byte $01,$00
.byte $01,$00,$01,$00,$01,$00
.byte $01,$00
.byte $01,$00,$01,$00,$01,$00
.byte $01,$00

No flicker... no 8th line bugs... just straight fine lines....
_________________

This is a way cool site!

Just to help on rasters...and this is from memory from around 15 years ago...

A timing table may not work from one piece of code to the next IF you put you table of delay values over a page limit (I think each page is 255 bytes).

The reason for a shorter delay (if I remember rightly) is because every 8 scanlines the C64 rom goes away and updates the char set (and other housekeeping stuff).

So...make sure you put your code AND your timing table within the same 255 byte area and you should be okay.

I think someone mentioned this but don't put sprites over your rasters. Again this is because the ROM/VIC chip has to do housekeeping for each sprite on the screen.

Let me know if this helps...I've still got a C128 and loads of disks in my cupboard and I can get them out if you need.

The above "perfect" raster routine was very interesting. I found a way to reduce it by 4 bytes by applying the following optimizations. (Not tested though.)

1. LDX# takes 2 cycles, just like NOP, but NOP takes only 1 byte, LDX# takes two. NOP+NOP occupies two bytes with four cycles; LDX#+NOP occupy three bytes with four cycles. Since the LDX# is needed before the loop but not before the "start" check, it can be "moved" down to "NOP space". Thus, LDX#+"start"+NOP+NOP takes four bytes with four cycles (I'm only counting post-start cycles here), but "start"+LDX#+NOP takes three bytes with the same four cycles; 1 byte is saved and the timing is not screwed up.

2. If the LDX# was LDX #$18 instead of LDX #0, the INX+CPX #$18 could be changed to just DEX because of the BNE (2 bytes savings). However, 2 important cycles would be lost if that was the only change. Simply have the BNE branch to the NOP that precedes the loop (for this reason, any NOP can be replaced with the moved LDX#, except the last one). If I understood correctly, NTSC requires two additional cycles, in this case, branch to the second-to-last NOP before the loop. (You can modify the setup routine to decrement the BNE address if NTSC was detected... although maybe it would kill the point of having reduced 4 bytes in the first place...)

3. Now I am left with five NOPs. The last two should be untouched for the previous item to work. I can crunch the remaining three (six cycles) by substituting it with a "CMP (<zero-page address>, X)" of two bytes and six cycles as well (not to mention that no important state changes). That's one byte savings. (Actually, I can not find a better substitution even if neither of the above two items were applied. Any ideas?) Since the opcode for such a CMP is $C1, try using "CMP ($C1, X)". Thus, two consecutive $C1 in machine language *may* be "cruncher-friendly".

As was mentioned before, it is assumed that everything lies in the same page (the high byte of all addresses are the same) for the timings to work.

Furthermore, can the value for the LDA #$3B be raised and thus crunch the NOPs even more? A total of 5 bytes can end up being saved if one can raise this value so that I can delete two NOPs off the list (assuming trick #3 was not used). However, I know little about rasters in practice...