| |
Digger
Registered: Mar 2005
Posts: 447 |
$d011 trickery duplicated text lines
Does any one know the $d011 trick to repeat the first char row? I am trying to cancel badlines on the 8th line of each charline (between cycles 54-57) but it doesn't work. The first line gets duplicated but only twice. |
|
... 57 posts hidden. Click here to view all posts....
|
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Thanks for testing it on the real thing! I used the latest MacOs x64sc from https://vice-emu.sourceforge.io/macosx.html
The color of that one $ff-byte on rasterline $30 is green on the emulator, but white on the real C64, is that right?
If so, then there is an emulator bug.
Quote:
PS. I'm not exactly sure why the C64C bottom row is showing different "T" chars with colours compared to the Vice emulator which shows the usual "black $FF char"?
I think what it shows is what is in memory locations $07e8 ... $07ff with colors from $dbe8 ... $dbff.
You could change the colors and characters in these memory locations and in $0400 .. $0427 and $d800 ... $d827 and see what happens. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
Quote:The color of that one $ff-byte on rasterline $30 is green on the emulator, but white on the real C64, is that right?
If so, then there is an emulator bug.
make sure to test this on different C64s - and make sure to use the matching VICII type in x64sc. This sounds to me like one of those things that isnt fully understood AND which is not consistant across individual chips either - perhaps this is related: https://sourceforge.net/p/vice-emu/bugs/218/ |
| |
Martin Piper
Registered: Nov 2007
Posts: 739 |
Updated code, to clear the zeropage+extended zeropage, screen $700- and colour $db00- areas to a known pattern. Emulation now matches real C64C
The bottom line does seem to be the "sprite register" area for the chars, but not the colour RAM...?!
;ZP-adresses
irqA = 2
irqX = 3
irqY = 4
;Variables
IrqLijn0 = $2f
IrqLijn1 = 255
*=$0801
; 10 SYS2064
!by $0B, $08, $0A, $00, $9E, $32, $30, $36, $34, $00, $00, $00
*=$0810
;set up stable raster interrupt and put something on screen
sei
lda #%100000
sta $01
ldx #0
.clm1 stx ClearMemStart
inx
inc .clm1+1
bne .clm1
inc .clm1+2
bne .clm1
lda #%110111
sta $01
; Clear everything else :)
ldx #0
.clm2
txa
sta $0002,x
sta $0102,x
sta $0202,x
sta $0302,x
sta $0700,x
sta $db00,x
dex
bne .clm2
cld
lda #0
sta $d015
ldy #00
l0: ldx #39
tya
m0: sta $0400,x
m1: sta $d800,x
dex
bpl m0
clc
lda m0+1
adc #40
sta m0+1
bcc *+5
inc m0+2
clc
lda m1+1
adc #40
sta m1+1
bcc *+5
inc m1+2
iny
cpy #25
bcc l0
lda #100
sta $0404
lda #1
sta $d804
lda #$7f
sta $042b
lda #3
sta $d82b
lda #86
sta $042f
lda #7
sta $d82f
ldx #7
stx $dbeb
ldx #5
stx $dbec
ldx #13
stx $dbed
jsr setTimer ;stabilize raster
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$01
sta $d01a
lda #IrqLijn0
sta $d012
lda #$1f
sta $d011
lda #<irq0
sta $fffe
lda #>irq0
sta $ffff
lda #$35
sta $01
lda #$55
sta $3fff
lda #$01
sta $d010
inc $d019
cli
jmp *
;Raster irq every 4th line
irq0:
sta irqA
nop
lda $dc06
eor #7
sta *+4
bpl *+2 ;Note: make sure there is no page boundary crossing!
lda #$a9
lda #$a9
lda $eaa5
stx irqX
sty irqY
ldx $d012
inc $0200 ;for delay purposes only
inc $d020 ;show current line in right border
dec $d020
inc $0200
;badline on next rasterline
inx
txa
and #$07
ora #$18 ;$38
sta $d011
txa
clc
adc #$03 ;irq every 4th line
cmp #$f8
bcs endscrn
sta $d012
inc $d019
ldy irqY
ldx irqX
lda irqA
rti
endscrn:
;open the border
lda $d011
and #$f7
sta $d011
bit $d011
bpl *-3
lda #$1f ;$3f
sta $d011
lda #IrqLijn0 ;IrqLijn1
sta $d012
inc $d019
ldy irqY
ldx irqX
lda irqA
rti
;Stabilize raster
setTimer:
;Via badline detection with timer
lax $dc04
sbx #51
sta irqA
cpx $dc04
bne setTimer ;Note: make sure there is no page boundary crossings!
;wait till cycle 54 with setting $dc0f
ldx #8
dex
bne *-1
bit $ea
lda #8
sta $dc06
stx $dc07
lda #$11
sta $dc0f ;This instruction should happen on cycle 54
rts
ClearMemStart
https://drive.google.com/file/d/1VbVSzfuim_4hGvyv5R-czXCQW-od-A..
https://drive.google.com/file/d/1Vi5oj9pKd-ITsQtTQm4rCUwjrwomQi..
https://drive.google.com/file/d/1VeKQfqqTMbuxvlivwCYRxN9CHf5_kr.. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Thanks again for testing.
Quoting Martin PiperEmulation now matches real C64C
No, it doesn't.
The one $ff byte that is visible in the beginning of rasterline $30 is white on the real C64C, but green on the emulator.
This very same byte is also visible in the last rasterline after the four black '@' characters. In the code you can see that #100 is put in $0404, in the color white. It is the last byte of that character's gfx that you are seeing.
If you would put reverse spaces in memory locations $0400 ... $0427, you would see that on the real thing they would have the colors that are in $d800 ... $d827, but the emulator will show them in the colors that are at the bottom of the screen. See the first picture that I posted. The bug is that the screen ram and color ram memory locations do not match in the very first rasterline. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quote: Quote:The color of that one $ff-byte on rasterline $30 is green on the emulator, but white on the real C64, is that right?
If so, then there is an emulator bug.
make sure to test this on different C64s - and make sure to use the matching VICII type in x64sc. This sounds to me like one of those things that isnt fully understood AND which is not consistant across individual chips either - perhaps this is related: https://sourceforge.net/p/vice-emu/bugs/218/
To me it looks like a plain emulator bug. The VIC fetches 12 bits at once in the c-accesses, therefore I expected screen ram and color ram memory addresses to always match. But they don't in the emulator on rasterline $30 for the code posted in this thread, while they do on the real C64C. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Quoting Martin Piper
The bottom line does seem to be the "sprite register" area for the chars, but not the colour RAM...?!
Since a line crunch is happening, the VIC will fetch from memory beyond the visible screen. So the bottomline (as far as it is not hidden by the FLI bug) will show characters in memory locations $07e8 ... $07ff and then wrap around to $0400 again. It should do the same for the colors, that is, fetch from $dbe8 ... $dbff and wrap around to $d800 again.
So, the first four black '@' characters on the bottom row are stored in $0400 ... $0403 and $d800 ... $d803.
Here is some code that might show the bug more clearly:
//ZP-adresses
.const irqA = 2
.const irqX = 3
.const irqY = 4
//Variables
.var IrqLijn0 = $2f
*=$0801
// 10 SYS2064
.byte $0B, $08, $0A, $00, $9E, $32, $30, $36, $34, $00, $00, $00
*=$0810
sei
cld
lda #0
sta $d015
sta $d021
lda #%10101010
sta $3fff
ldy #01
l0: ldx #39
tya
m0: sta $0428,x
lda #$0e
sta $d828,x
dex
bpl l0+2
clc
lda m0+1
adc #40
sta m0+1
sta m0+6
bcc *+8
inc m0+2
inc m0+7
iny
cpy #25
bcc l0
//Mid grey characters #123 on first character row
ldx #39
l1: lda #123
sta $0400,x
lda #12
sta $d800,x
dex
bpl l1
/Put some chars and colors in $07e8 ... $07ff and $dbe8 ... $dbff
ldx #$fe
l2: txa
sta $0701,x
sta $db01,x
dex
cpx #$e6
bne l2
jsr setTimer
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$01
sta $d01a
lda #IrqLijn0
sta $d012
lda #$1f
sta $d011
lda #<irq0
sta $fffe
lda #>irq0
sta $ffff
lda #$35
sta $01
lda #$55
sta $3fff
lda #$01
sta $d010
inc $d019
cli
jmp *
irq0:
sta irqA
nop
lda $dc06
eor #7
sta *+4
bpl *+2
lda #$a9
lda #$a9
lda $eaa5
stx irqX
sty irqY
ldx $d012
inc $0200
inc $d020
dec $d020
inc $0200
//Badline on next rasterline
inx
txa
and #$07
ora #$18
sta $d011
txa
clc
adc #$03
cmp #$f8
bcs endscrn
sta $d012
inc $d019
ldy irqY
ldx irqX
lda irqA
rti
endscrn:
//open border
lda $d011
and #$f7
sta $d011
bit $d011
bpl *-3
lda #$1f
sta $d011
lda #IrqLijn0
sta $d012
inc $d019
ldy irqY
ldx irqX
lda irqA
rti
setTimer:
//Via badline detection with timer
lax $dc04
sbx #51
sta irqA
cpx $dc04
bne setTimer
ldx #8
dex
bne *-1
bit $ea
lda #8
sta $dc06
stx $dc07
lda #$11
sta $dc0f
rts
Result in Vice 3.5 for model C64C:
https://i.postimg.cc/2yLFNCc0/text-mode2.png
One would expect the gfx in rasterline $30 to be mid grey on a real C64, but the emulator uses the colors from the bottom row (memory locations $dbe8 ... $dbff). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
Interesting.... HOXS does it correctly apparently :) |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Yes, while micro64 shows the same thing as Vice. Should I submit a ticket to sourceforge or should I wait until this has been tested on more real C64s? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
My Breadbox also shows all grey in the top line.
Please make a ticket :) |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Ticket submitted, feel free to edit if you think it isn't explained clearly or if something is missing.
https://sourceforge.net/p/vice-emu/bugs/1627/ |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
