|
|
Post by hydrophilic on Jun 28, 2014 4:55:22 GMT
Um, VDC8x2, did you delete the thread about the scroller? I can't find it now.
I just tested both versions on my C128. Well I was wrong, my VDC reports revision 1, not 2 as I thought. However this shouldn't matter much, as the differences with scrolling only pertain to revision 0.
Anyway, both the original and the updated (with attributes) version flicker. I mean it scrolls smoothly to the left, but then there is a "double post" for a jiffy when the chars and attributes get copied over by 1 byte (well, presumably). Besides reporting back, I also wanted to look at the source code again and maybe spot the problem. I imagine you just need to check VBlank... but I thought you were already doing that so who knows? If this was derived from Risen from Oblivion, then that makes it even more mysterious, because we know that works.
|
|
|
|
Post by VDC 8x2 on Jun 28, 2014 16:34:51 GMT
I didn't delete the thread. where did it go? hm reposting the attachment. Working on a 2.5 version. I will post that later with prg and source. Attachments:colorscroll.prg (305 B)
|
|
|
|
Post by VDC 8x2 on Jun 28, 2014 17:02:56 GMT
I just checked. It is in demoscene section.
|
|
|
|
Post by VDC 8x2 on Jun 28, 2014 20:16:17 GMT
The 2.0 source code for you to check
VDCADR = $D600
VDCDAT = $D601
txtptr = $a9
smooth = $ab
color = $a8
defm WaitVDC
bit $d600
bpl *-3
endm
defm poke
lda #/2
sta /1
endm
*=$1300
start poke smooth , $07
poke color , $0c
ldx #$18
jsr vdcpeekreg
ora #$80 ;set copy bit
sta vdcdat
jsr zp0
mainloop lda #$20 ;bit 5 we checking
bit vdcadr ;waiting for vblank
beq *-3
sei ;don't want to be interupted
jsr scroll
ldx #$19
jsr VdcPeekReg
and #%11110000
ora smooth
sta vdcdat ;scroll left
cli ;done so release interupts
lda #$20
bit vdcadr
bne *-3 ;waiting for start of frame
jmp mainloop
scroll lda smooth
sec
sbc #$01 ;$01 to $07 for scroll speed. $07 is the fastest
bcc movetext
sta smooth
rts
movetext lda #$07
sta smooth
ldy #$20 ;reg pair
lda #$00 ;high byte source
ldx #$01 ;low byte source
jsr VDCWORDREG
ldy #$12 ;reg pair
lda #$00 ;high byte target
ldx #$00 ;low byte
jsr vdcwordreg
ldx #$1e
lda #$4f ;copy 79 bytes
jsr vdcpokereg
ldy #$00 ;we can continue with non VDC code. rock on cpu! lol
lda (txtptr),y
cmp #$ff
bne @nopeff
jsr zp0
lda (txtptr),y
@nopeff cmp #$fe
bne @nopefe
jsr INCTXTPTR
lda (txtptr),y
sta color
jsr inctxtptr
lda (txtptr),y
@nopefe jsr IncTxtPtr
ldx #$1f
jsr vdcpokereg
ldy #$20 ;color source
lda #$08
ldx #$01
jsr vdcwordreg
ldy #$12 ;color destination
lda #$08
ldx #$00
jsr vdcwordreg
ldx #$1e ;copy 79 bytes
lda #$4f
jsr vdcpokereg
ldx #$1f
lda color
jsr vdcpokereg
rts
zp0 lda #<scrolltxt
sta txtptr
lda #>scrolltxt
sta txtptr+1
rts
VdcPokeReg stx vdcadr
waitvdc
sta vdcdat
rts
VdcPeekREG stx vdcadr ;.x reg and value returned in .a
waitvdc
lda vdcdat
rts
VDCWordreg sty vdcadr ;a/x is high/low value y is high byte of reg pair
waitvdc
sta vdcdat
iny
sty vdcadr
stx vdcdat
rts
IncTxtPtr inc txtptr
bne @end
inc txtptr+1
@end rts
scrolltxt byte $fe,$0f
text 'this is a test of '
byte $fe,$0d
text 'the '
byte $fe,$0c
text 'scrolling demo.....'
byte $fe,$1c
text 'flash '
byte $fe,$2c
text 'underline'
byte $fe,%01001010
text 'reverse'
byte $fe,%10000110
text 'charSET '
byte $ff
|
|
|
|
Post by VDC 8x2 on Jun 29, 2014 3:30:49 GMT
version 2.5 loads like a basic program now. VDCADR = $d600
VDCDAT = $D601
TxtPtr = $a9
ClrPtr = $96
smooth = $ab
color = $a8
defm poke
lda #/2
sta /1
endm
defm WaitVDC
bit $d600
bpl *-3
endm
*=$1c01
Byte $11,$1c,$de,$07,$de,$9c,$3a
byte $fe,$25,$3a,$9e,$37,$31,$38,$37
bytes $00*3
;2014 graphicclr:fast:sys7187 in basic
Start Poke smooth, $07
poke color, $08
ldx #$18
jsr VdcPeekReg
ora #$80 ;set copy bit
sta VDCDAT
jsr zp0 ;set up pointers
MainLoop lda #$20 ;bit 5 we checking
bit vdcadr ;wait for vblank
beq *-3
sei ;don't want to be interupted
jsr scroll
ldx #$19
jsr VDCPEEKREG
and #%11110000
ora smooth
sta vdcdat ;scroll left
cli ;done so release interupts
lda #$20
bit vdcadr
bne *-3 ;wait for the start of the frame
jmp MAINLOOP
scroll lda smooth
sec
sbc #$01 ;$01 to $07. 7 the fastest
bcc MoveText
sta smooth
rts
MoveText lda #$07
sta smooth
ldy #$00
lda (txtptr),y
cmp #$ff
bne @nopeff
jsr zp0
lda (txtptr),y
@nopeff cmp #$fe
bne @nopefe
lda (clrptr),y
sta color
jsr incclrptr
jsr inctxtptr
lda (txtptr),y
@nopefe jsr inctxtptr
pha
ldy #$20 ;reg pair
lda #$00 ;high byte
ldx #$01 ;low byte
jsr vdcwordreg
ldy #$12
lda #$00
ldx #$00
jsr vdcwordreg
ldx #$1e
lda #$4f ;copy 79 bytes
jsr VdcPokeReg
pla
ldx #$1f
jsr VDCPOKEREG
ldy #$20 ;color source
lda #$08
ldx #$01
jsr vdcwordreg
ldy #$12 ;color destination
lda #$08
ldx #$00
jsr vdcwordreg
ldx #$1e ;copy 79 bytes
lda #$4f
jsr vdcpokereg
ldx #$1f
lda color
jsr vdcpokereg
rts
zp0 lda #<ScrollText
sta TxtPtr
lda #>Scrolltext
sta TxtPtr+1
lda #<Colordata
sta CLRPTR
lda #>ColorData
sta CLRPTR+1
rts
VdcPokeReg stx vdcadr
waitvdc
sta vdcdat
rts
VdcPeekREG stx vdcadr ;.x reg and value returned in .a
waitvdc
lda vdcdat
rts
VDCWordreg sty vdcadr ;a/x is high/low value y is high byte of reg pair
waitvdc
sta vdcdat
iny
sty vdcadr
stx vdcdat
rts
IncTxtPtr inc TXTPTR
bne @end
inc TXTPTR+1
@end rts
IncClrPtr inc clrptr
bne @end
inc clrptr+1
@end rts
ScrollText byte $fe
text 'this is a test of '
byte $fe
text 'the '
byte $fe
text 'scrolling demo... '
byte $fe
text 'flash '
byte $fe
text 'underline '
byte $fe
text 'reverse '
byte $fe
text 'charSET '
byte $ff
ColorData byte $0f,$0d,$0c,$1c,$2c,$4a,$86Attachments:colorscroll.prg (347 B)
|
|
|
|
Post by hydrophilic on Jun 29, 2014 5:06:57 GMT
Ah now I see it! You might want to invoke your powers of Admin to merge these threads so they're all in one place.
Anyway, I didn't see anything obviously wrong with the code. So I fired up my C128 and played around, but no luck.
My first change to your code was simple update of the background color when it is doing the "char copy" (i.e., when 'scroll' underflows). On VICE, and on my real Commie this shows that the char (and attribute) transfer takes only a few rasters (maybe 8, a few more for color change). See attached pic.
Because it didn't seem to be a problem with V-Sync, I tried single stepping (i.e., scroll one pixel at a time, manually). This was mainly to assure myself that there is nothing funky with revision 1 scrolling. Everything worked fine this way. So I was still at a loss why it fails in a loop!
Next I thought maybe the VDC is very picky about *when* you update H-Scroll register; so I modified the code so that it (when needed) it scrolls the text AFTER it updates the scroll register. Again this worked fined when single-stepping the code (on a real C128 by the way), but still fails (the jerky / double-post) when run in a loop (run normally).
Now I really don't know what else would be the problem... I noticed that you just jammed the new H-Scroll into $d601 without testing for the "ready" bit. It has been my experience you don't need to check the "ready" bit unless you are accessing V-RAM (and this is not). But still... I wanted to be sure it was not the problem, so I changed the STA $D601 into a JSR WriteReg. And the results were the same: fail!
I've said it before, and I'll say it again, the VDC sure is a Piece Of Silicon!
Edit
Hey Mirkosoft, if you're reading this, you said your C128 reports revision 2. Is this with a 8568? I.e., the "new" VDC of the DCR which has the extra register of sync polarity? I was curious because I have never read what that difference between revision 1 and revisions 2 is. Well we know the "new" VDC has the extra register, so maybe that is why it is revision 2? Of course, anybody who knows about this can comment, but I thought Miro might know directly. Anyway, thanks for all respones on this sub-topic! Attachments:
|
|
|
|
Post by VDC 8x2 on Jun 29, 2014 5:18:57 GMT
would slowing down the scroll make it less jerky?
edit: I thought of another question: What if you modify the ram refresh reg to min? is it still jerky?
|
|
|
|
Post by hydrophilic on Jun 29, 2014 5:34:40 GMT
Like I said, manually scrolling (i.e., type J XXXX in the MONITOR) works fine. I think that is about as slow as you can go... humans are *infinitely* slower than the CPU.
I didn't think to change RAM refresh, but because the "copy chars" only takes a few rasters at the BOTTOM of the screen (before the next frame is drawn) I don't think it would make any difference.
P.S. I noticed in the "other thread" that Mirkosoft reported his revision 2 chip is in fact a "new" 8568 (with extra sync register). So now I'm guessing that is the difference between revision 1 and revision 2; but of course if anyone has something to contradict this, I would love to hear about (I'm sure others would too).
Edit
Since my C128 is powered up right now, I changed the RAM refresh to minimum (0) and tried version 2 again. Same results: jerky scrolling.
|
|
|
|
Post by VDC 8x2 on Jun 29, 2014 13:10:36 GMT
All I can think of adding after sleeping on it is, adding a:
bit $d600
bpl *-3
at the beginning of the mainloop.
|
|
|
|
Post by tokra on Jun 29, 2014 21:26:11 GMT
Hey Mirkosoft, if you're reading this, you said your C128 reports revision 2. Is this with a 8568? I.e., the "new" VDC of the DCR which has the extra register of sync polarity? I was curious because I have never read what that difference between revision 1 and revisions 2 is. Well we know the "new" VDC has the extra register, so maybe that is why it is revision 2? Of course, anybody who knows about this can comment, but I thought Miro might know directly. Anyway, thanks for all respones on this sub-topic! The revision number is reported by the 3 lower bits in $d600. Version 0 would be the very early 8563 with the register 25 scroll-register set up differently. Version 1 is the 8563 with register 25 set-up as we know it and the most common version in flat C128s and plastic C128Ds. Version 2 is the 8568 in the C128DCR which also came with 64K VDC-RAM. Sometimes you will see these referred to as revision 7, 8 and 9 respectively. Revision 7 was the first one going to production apparantly and as such was called version 0 and is reported as such by $d600. |
|
