| |
Digger
Registered: Mar 2005
Posts: 421 |
$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. |
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Yup, basically make FLI, but use more cycles, so the bug gets pushed all the way into the right border. On the left side of the bug you'll have repeated char rows. So you won't get rid of badlines, but most (maybe all) of the DMA cycles are skipped. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
you have to do the exact opposite- create a badline condition (set d011 low bits to match those of the current raster line) before cycle 58 of the 8th line. rc will overflow to 0 in cycle 58 and if you prevent badlines afterwards the row will be duplicated. |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
Assiduous: i thought that when you do the lsb match of $d011 and $d012 before cycle 58 in rc7 , rc will be reset
to zero and vcbase will not be increment by 40.
But you still have a badline condition otherwise the charpointers will not displayed for the second time...
correct me if iam wrong..
|
| |
Digger
Registered: Mar 2005
Posts: 421 |
Hmmm, getting a bit confused now. Graham says two $d011 accesses are enough (http://noname.c64.org/csdb/forums/?roomid=11&topicid=34379#34476)
Cruzer's FLI trick worked but I am looking to save as much raster time as I can, by triggering stable timer IRQ every x lines to repeat the char row. |
| |
Digger
Registered: Mar 2005
Posts: 421 |
Ha! I think I've done it by experimenting :D Will share the source once I tidy it up. Thanks for all the suggestions! |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Testa: when rc is incremented in cycle 58 (7->0) the VIC stays in the display state. it will just use the content of the internal buffers from the last dma fetch,you dont need another dma fetch to repeat the char row. as Graham said only 2 d011 accesses are needed to repeat a char row -1 to assert a badline condition in cycles 54-57 of the line 7,the other to prevent badline when rc=7 is reached again. |
| |
fenek
Account closed
Registered: Apr 2002
Posts: 3 |
Quote: Ha! I think I've done it by experimenting :D Will share the source once I tidy it up. Thanks for all the suggestions!
You can check code in 640x800 Pirate part in "Sweet Infection".
Sweet Infection
It works as you want.
Display routine trigger IRQ every x lines to repeat the first char row and change $d018/$dd00 to get one of 25 different rows of picture.
As far as I remember when you disable badline with $d011 you must add 40-4(6) cycles, because this is long line.
|
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
assiduous: yep i see now.... but i'am still confused.
i have an old source: i repeat the first char row
al the way down with only one $d011 write each 8th line.
if i have used this trick to create 25 text swingers
upper scroll style (no linecrunch)
i remember that you also can abort the duplicated char-raw earlier then rc7.. so you can display more then 25 char-raws.. or do i mess up things here...
edit: oh see now.. i checked my source, i do line
doubeling, i display the first char row over and
over again by fetching the same 40 charpointers again.
you can also do the same without fetching the same
charpointers again. this wil give you some more
free cycles: 40 minus the lda $xx sta $d011 writes to
prevent the badline..
|
| |
Digger
Registered: Mar 2005
Posts: 421 |
@Fenek: Thanks! I've seen this part before and I was impressed! Was wondering how did you do it :) I suppose the only disadvantage is the fragmented memory you have to use 25 charset banks (only 80 * 8 = $280 bytes each though, right?) Do you use double buffering there at all? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Wizz did this in 1988:
Broken Ass!
Notice the release id nr :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Hello :-)
Before I go into trial and error mode I ask: I want to repeat full rows, but I also want badlines, and preferably the least d011 writes possible. it this possible, and how? :)
judging by cruzer's post doable, but he seemingly talks about toucing d011 every line. |
| |
Digger
Registered: Mar 2005
Posts: 421 |
@Oswald: Badline will cause to refetch the next charline, and you want to have a badline without that I presume? Why? :D |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Hello :-)
Before I go into trial and error mode I ask: I want to repeat full rows, but I also want badlines, and preferably the least d011 writes possible. it this possible, and how? :)
judging by cruzer's post doable, but he seemingly talks about toucing d011 every line.
Just trigger a badline before RC<7. If RC==7 on a badline you’ll go to the next row. This is just an FPP. You will not be able to have full 8 lines high rows, only 7. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Just trigger a badline before RC<7. If RC==7 on a badline you’ll go to the next row. This is just an FPP. You will not be able to have full 8 lines high rows, only 7.
ah ok guess this is the easy to do, you can repeat a char row after having any nr of its lines displayed.
but I really really need full 8 lines. impossible? : ( |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: @Oswald: Badline will cause to refetch the next charline, and you want to have a badline without that I presume? Why? :D
hehe, there is a neat trick (or rather plan) behind it, yes. I'll tell when the part is released :) if only 7 lines rows possible then its pointless I guess. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: hehe, there is a neat trick (or rather plan) behind it, yes. I'll tell when the part is released :) if only 7 lines rows possible then its pointless I guess.
If RC=7 then VC->VCBASE regardless of badline condition, so no, only 7 lines. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting Oswaldif only 7 lines rows possible then its pointless I guess.
Eh, I used a new instance of row 0 every 5 rasters in Jam Ball 2 to keep my framebuffer size down and thought that was reasonably worthwhile :)
Alternately (assuming you can afford to lose another 60 or so cycles) you could do two badlines at the start of every group of eight and use one charset/bitmap for the first line and another for the remaining seven. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
what if I do the "no badline" row repeat on the last pixel row of a char row, but then manually make a badline in the next raster line ? can this be done ?:P |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Sadly not. The issue is that each “no badline” row repeat secretly updates the row pointer to the next row, so the moment you do a DMA you’d get a later row than what you want,
(Useful for other effects of course, like double buffering half res d800) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
what you describe sounds like the normal behaviour ? rc to 0 and next row read up. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Yes, except it doesn't actually fetch the characters, so the internal row buffer remains unchanged. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ok while we're at it can you explain last row stretch with internal counters? I'm staring at the VIC article but the more I stare at it the less sense it makes. like RC is never incremented after reaching 7 by these rules:
"In the first phase of cycle 58, the VIC checks if RC=7. If so, the video
logic goes to idle state and VCBASE is loaded from VC (VC->VCBASE). If
the video logic is in display state afterwards (this is always the case
if there is a Bad Line Condition), RC is incremented."
so RC=7, we go to idle state, thus RC is not incremented hence it is only incremented in display state.
I'm thinking of stretching the last pixel row, to get the 8 high char line I want.
ok not possible hence my last is 7th not 8th, and that stretch only works on 8th.
only straw left is repeat 1st line but that adds only a badline, urgh. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ok I guess I get it, if *sometime later* there is badline then will we go back to display state and increment rc. whenever. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Yup, exactly.
Lft's done a nice PDF of the timing, you can find it at https://www.linusakesson.net/programming/vic-timing/ |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yup, exactly.
Lft's done a nice PDF of the timing, you can find it at https://www.linusakesson.net/programming/vic-timing/
Yes. Do read this. It takes a while to understand how to interpret it but once you learn it all VIC-tricks are easy to figure out. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
already used this pdf, but not the how rc /vc works part, that still needs a lot of thinking :)
fex, I can not explain how/why last row stretch works. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I noticed something strange, could someone explain this to me, please?
I create a badline after cycle 14 on every 4th rasterline, starting on line $30. I also opened the borders. In text mode you can see the memory wrap around: the last 5 rasterlines on the text screen start with the characters in memory locations $07e8 and so on, with colors from $dbe8 and so on.
On rasterline $30 the last byte from each character in $0400 ... is visible, but in the colors from $dbe8 and so on. This caught my attention since I expected the screen ram and color ram memory addresses to match.
If I do the same thing in hires bitmap mode, rasterline $30 now shows the colors from rasterline $f8, but in bitmap mode these colors are determined by screen ram.
So in plain text mode data from $0400 ... is shown in rasterline $30, while in bitmap mode data from $07e8 ... seems to be used.
I'm seeing this in VICE 3.5, Hoxs, and micro64. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Rastah BarOn rasterline $30 the last byte from each character in $0400 ... is visible, but in the colors from $dbe8 and so on. This caught my attention since I expected the screen ram and color ram memory addresses to match. Both addresses should match, as they're coming from one and the same counter in VIC.
It seems like you're linecrunching right from the top of the screen. When you do that, there is no badline DMA in line $30 (otherwise you'd see the first, not the last, pixel row of the characters). Instead, whatever was put in the line buffer in the previous frame is displayed.
But colours and characters should come from matching addresses. Are you sure there is a mismatch? |
| |
Martin Piper
Registered: Nov 2007
Posts: 633 |
Perhaps a picture would help? :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Yes, there is a mismatch as you can see in the pictures in text mode and bitmap mode.
https://i.postimg.cc/qvLzbQ3D/text-mode.png
https://i.postimg.cc/WbsVWVwj/hires-bitmap-mode.png
The first character row $0400 ... $0427 is filled with inverse space.
Addresses $dbe8 .. $dbff contain 0,1,2,3,4,5,7,8,0,1, ...
Addresses $07e8 .. $07ff contain 0,0,ff,ff,ff,ff,0,0,0,0,ff,ff,ff,ff, ...
The first stripe in the right border is at line $2f |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
I'd find some actual code a lot more helpful, the pictures leave open too many questions. =)
And are you sure the top line in text mode is inverted spaces ($A0)? When and from where would they be fetched? Seems more likely to me that $d018 in the top line points to some memory that's not the character generator ROM, but just $ff somewhere in RAM, with not only the colours, but also the buffered characters matching those in the bottom character row. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Yes, I put in the inverted spaces manually in Vice monitor.
I also tried other character codes.
Btw, this mismatch occurs in Vice and micro64, Hoxs seems to have matching screen and color ram addresses. So this looks like an emulator bug.
Anyway, here is some code. You can play with the colors and character codes in the monitor.
/ZP-adresses
.const irqA = 2
.const irqX = 3
.const irqY = 4
//Variables
.var IrqLijn0 = $2f
.var IrqLijn1 = 255
*=$0801
// 10 SYS2064
.byte $0B, $08, $0A, $00, $9E, $32, $30, $36, $34, $00, $00, $00
*=$0810
//set up stable raster interrupt and put something on screen
sei
cld
lda #0
sta $d015
ldy #00
l0: ldx #39
tya
m0: sta $0400,x
dex
bpl m0
clc
lda m0+1
adc #40
sta m0+1
bcc *+5
inc m0+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
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Rastah BarBtw, this mismatch occurs in Vice and micro64, Hoxs seems to have matching screen and color ram addresses. So this looks like an emulator bug.
This may well be but needs to be compared to actual hw before investigating further.
EDIT: and make sure you use a recent x64sc. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Yeah, always check on realthing before even posting about unexpected behaviour. :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I can't check on the real thing, unfortunately. |
| |
Martin Piper
Registered: Nov 2007
Posts: 633 |
Using my C64C and Vice 3.1 rev 34062M
And this code which clears most of the memory (ClearMemStart) and $d800... to expected values:
;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
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
I get the following results, which roughly match between the real and emulator, with the exception of the bottom row:
https://drive.google.com/file/d/1VO8YEHkEySVaQ5p-vq3LuSFdcVVWeB..
https://drive.google.com/file/d/1V7T2JliDT3KXjbuOrNwJG9pWWgKsTS..
https://drive.google.com/file/d/1V5TBd_lPCWkyBlNxhXJdgwA1yxivwG.. |
| |
Martin Piper
Registered: Nov 2007
Posts: 633 |
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"?
PPS. I used: acme.exe --msvc -v3 --cpu 6510 -f cbm -o c:\temp\vicbug.prg c:\temp\vicbug.a
Yes, sorry, I use ACME :) |
| |
Rastah Bar
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: 11107 |
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: 633 |
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
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
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
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: 11107 |
Interesting.... HOXS does it correctly apparently :) |
| |
Rastah Bar
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: 11107 |
My Breadbox also shows all grey in the top line.
Please make a ticket :) |
| |
Rastah Bar
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/ |
| |
Martin Piper
Registered: Nov 2007
Posts: 633 |
Quote: Interesting.... HOXS does it correctly apparently :)
Even Hoxs64 from 6 January 2013 v1.0.8.4 works right :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
funny enough, even x64 works right ... interesting bug really :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I hate bugs ;-)
But glad that I can contribute to the improvement of emulators. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
What do real C64s show in bitmap mode?
This link shows a Vice 3.5 x64sc screenshot:
https://postimg.cc/62qvYV86
and this a Vice 3.1 x64 screenshot:
https://postimg.cc/z3Vkjf75
So, probably there is a bug also in bitmap mode. |
| |
PiCiJi
Registered: Oct 2021
Posts: 2 |
Quote: 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/
I added a patch with some explanation. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I added a patch with some explanation.
Good find!
Will test this for corner cases. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
How on earth did VICE implenent it in the first place?! All adresses should be derived from ONE pointer (VCBASE). Will inspect the patch, curious! |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: How on earth did VICE implenent it in the first place?! All adresses should be derived from ONE pointer (VCBASE). Will inspect the patch, curious!
It's related to the char and color buffer in the VIC, not VCBASE. There was a race between writing (vmli) and reading this out (dmli) in an apparently rare case. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: It's related to the char and color buffer in the VIC, not VCBASE. There was a race between writing (vmli) and reading this out (dmli) in an apparently rare case.
Ahh yes ofc, I see. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrIt's related to the char and color buffer in the VIC, not VCBASE. There was a race between writing (vmli) and reading this out (dmli) in an apparently rare case. But can this be exploited for demo purposes? :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting tlrIt's related to the char and color buffer in the VIC, not VCBASE. There was a race between writing (vmli) and reading this out (dmli) in an apparently rare case. But can this be exploited for demo purposes? :)
Probably not, but never say never.
I'm not even sure these counters are separate counters in reality.
It was a long time since I wrote that piece of code, but I think part of the choice was due to trying to separate the cpu clock domain code from the dot clock domain code more cleanly. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
I've committed a fix for the bug 1627 issue in r41978 (based on the patch PiCiJi supplied).
This should really be emulated in the way described here: bug 218, but not today. :)
The committed fix passes the regression suite (thanks gpz!) but please test the current trunk with your "worst" VIC-II abuse!
Builds are here: https://github.com/VICE-Team/svn-mirror/releases |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
friendly reminder: Please run some of your tests this weekend. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
please :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: please :)
Doesn't work on Vice 2.1.. :( |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Doesn't work on Vice 2.1.. :(
anybody else want to pull some wise-guy cracks? :)
if not, it would be very helpful to get some feedback on if it's messing up your favourite effects. |
