| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Misaligned Char reads ?!
I was just fooling and found this.
the code does this:
near but well before the left border edge :
lda $d012 ;8
clc ;10
adc #$02 ;12
and #7 ;14
ora #$18 ;16
sta $d011
and 8 cycles after that:
lda $d012 ;8
clc ;10
adc #$00 ;12
and #7 ;14
ora #$18 ;16
sta $d011 ;20
as I add #2 to d011 in the first write I thought this could be used to rotate the characters, because the misalignment is exactly 2 lines, but the misalignment stays 2 even if I write 3 to d011 (while trying 0-7 in the 2nd d011 write, well most cases results in fld), or change starting rasterline 1 line lower, etc.
anyone can explain this?
yeah.. only tested in emulator. 3.3 x64sc has same results as older vice and non sc. |
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
What does it do on real hardware? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
results are some on real hw. btw the code does run only every 2nd line as indicated by the raster coloring. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Looks to me like a mix of last line repeat, fld and linecrunch... in this order.
Last char line is repeated then 1 line fld is inserted then vic restart draw "next line" with "old data" but crunching first line of the new char...
...if this make some sense... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"crunching first line of the new char."
thats still something that was never seen before. cant be fld because there would be empty lines between. the misalignment is also present in bitmap mode:
 |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Can you post the prg?
There is also what looks like a 0xff glitch on the top chars STU which is interesting. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
+1 for prg. also source please, this looks like a good candidate for a regression test :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
as is, this was originally ment to test if repeating 2 lines from the top char row endlessly is possible. Long after achieving the goal I returned to it with some random hacking and stumbled upon the result above.
d018tab = $1e00
dd00tab = $1f00
ysize = 200
*= $1000
sei
lda #$7f
sta $dc0d
lda #$01
sta $d01a
lda $dc0d
lda $dd0d
lda #$1b
sta $d011
lda #$36
sta $d012
lda #$35
sta $01
lda #<irq1
sta $fffe
lda #>irq1
sta $ffff
ldx #$00
- txa
sta $db00,x
dex
bne -
.for ue=0,ue<25,ue=ue+1
lda #$28+ue
sta $0410+ue*40
.next
;jmp *
lda #3
sta $dd00
u
ldx #200
- txa
and #%00000001
sta d018tab,x
dex
bne -
ldx #$27
- txa
sta $0400,x
dex
bpl -
lda ($01,x)
bit $eaea
cli
jmp u
irq1
pha
txa
pha
tya
pha
inc $d019
inc $d020
lda $d012
- cmp $d012
beq -
ldx #12
dex
bne *-1
nop
nop
nop
;nop
ldx #$00
rloop ldy d018tab,x ;4
lda $d012 ;8
clc ;10
adc #$04 ;12
and #7 ;14
ora #$18 ;16
sta $d011 ;20
sty $d020 ;24
;bit $eaea ;28
;bit $eaea ;32
;bit $eaea ;36
;bit $eaea ;40
;bit $eaea ;44
;bit $ea ;47
;bit $ea ;50
;bit $eaea
;bit $ea
;bit $ea
;nop ;52
ldy d018tab,x ;4
lda $d012 ;8
clc ;10
adc #$00 ;12
and #7 ;14
ora #$18 ;16
sta $d011 ;20
sty $d020 ;24
;bit $eaea ;28
;bit $eaea ;32
nop
nop
bit $eaea ;36
bit $eaea ;40
bit $eaea ;44
bit $eaea ;48
bit $eaea ;52
bit $eaea ;56
bit $eaea
inx ;58
cpx #ysize/2 ;60
bne rloop ;63
dec $d020
lda #<irq2
sta $fffe
lda #>irq2
sta $ffff
lda #$ff
sta $d012
inc $d020
pla
tay
pla
tax
pla
rti
irq2
pha
txa
pha
tya
pha
inc $d019
inc $d020
lda #$1b
sta $d011
lda #$2
sta $d020
lda #<irq1
sta $fffe
lda #>irq1
sta $ffff
lda #3
sta $dd00
lda #20
sta 53272
lda #$33
sta $d012
pla
tay
pla
tax
pla
rti
|
| |
Scan
Registered: Dec 2015
Posts: 111 |
I don't have an explanation for what I'm looking at, but I only looked briefly and will examine closer using C64Debugger in the evening. But I see something off in the comments with the cycle counting.
ldy d018tab,x ;4
lda $d012 ;8
clc ;10
adc #$00 ;12
and #7 ;14
ora #$18 ;16
sta $d011 ;20 (introduce badline condition)
sty $d020 ;24
;bit $eaea ;28
;bit $eaea ;32
nop
nop
bit $eaea ;36
bit $eaea ;40
bit $eaea ;44
bit $eaea ;48
bit $eaea ;52
bit $eaea ;56 This part will introduce a badline, but the cycle counting in the comments assumes it's not a badline and that the VIC won't stall the CPU.
 |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
dont rely on the comments, they are leftovers, garbage, random lines were insterted etc. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
The lda ($01,x) could introduce introduce memory read, CIA or VIC ack, issues.
However probably not related to this effect.
I'm currently puzzled. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
* this originally repeated top 2 pixel lines of the first char row, the 2nd d011 write was an lda before I came back to this, what I've changed was to reinstall the 2nd d011 write and I removed the delay between those 2 d011 writes. then some random hacking of d011 values, maybe delay too dont remember.
My current theory is that there is 2 chars of vsp and maybe that can be connected to 2 lines of misalignment in the char reads. tho I dont rule out that whats visible is just a mere mix of already known VIC effects. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
This appears to be a combination of repeated char rows and FLI, in this order.
Note that the apparent misalignment is 1 rasterline (not 2), such that a char seems to be rotated upwards by a line, with its first line displayed at its bottom.
Emphasis on "seems", as there is neither actual rotation nor misaligned char reads.
Look at the first and second char rows. The chars in the first row are displayed normally, while the first rasterline of the second char row shows the first line of the chars in the first row. Which means there are 9 rasterlines with the content of the first char row at the top of the screen.
Now, when going from a char row to the next, there is no badline initially, and the chars are repeated for the first rasterline of a char row.
In the next rasterline, DMA is forced by triggering a badline condition, but late enough to trigger FLI rather than a normal badline (note the 3 $ff chars).
Starting with the second rasterline of a char row, updated content is displayed, i.e., the new char row.
The first line will finally be displayed in the next char row. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
How about these few lines of apparent 0xff?  |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
FLI DMA is triggered a few cycles later there.
The timing is off for a few lines until it eventually settles thanks to repeated FLI DMA triggering (which can be used for stable raster purposes).
Note that you can control the amount of repeated chars (the first two columns in the original picture) and thus move the 3 $ff chars by adding or removing cycles in the loop. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ah Gunnar you got it ! :) row doubling cancelled by fli. |
