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.
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
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
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
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!
Last Edit: Jun 29, 2014 5:15:55 GMT by hydrophilic: Thought of a question
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.
Last Edit: Jun 29, 2014 5:42:37 GMT by hydrophilic: New Experiment
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.