|
|
Post by remark on Apr 18, 2017 12:53:58 GMT
This program shows how to scroll from right to left, according to the method described on page 323 in the C128 PRG. It is an adaptation from the vertical scroll program by tokra in the thread VDC Smooth scroll register "Flicker" bug (in Demoscene). The program scrolls one character to far, but i leave that to others to correct. There is no flickering. Usage: bload the program and do a sys4864. ;
;usage:
; bload"hscroll.prg"
; sys4864
;
*=$1300
lda #80 ;numbers of columns to scroll
sta cols
lda #7 ;start value of softscroll
sta soft
lda #0
sta scn_hi ;screenbase pointer ($0000)
lda #8
sta atr_hi ;attributebase pointer ($0800)
lda #0
sta scn_lo
sta atr_lo
sei
lda #80 ;set virtual screen to 160 columns (+80)
ldx #27
stx $d600
wait1 bit $d600
bpl wait1
sta $d601
main lda #$20 ;wait until really in vblank
wait2 bit $d600
bne wait2
wait3 lda #$20
bit $d600
beq wait3
lda soft ;update hor. softscroll register
ora #$40 ;enable attributes
ldx #25
stx $d600
wait4 bit $d600
bpl wait4
sta $d601
dec soft
bne flag3
lda #$07
sta soft
lda scn_lo ;increase base pointers
clc
adc #1
sta scn_lo
sta atr_lo
bcc flag1
inc scn_hi
inc atr_hi
flag1 lda scn_hi ;update screenbase pointer
ldx #12
stx $d600
wait5 bit $d600
bpl wait5
sta $d601
lda scn_lo
ldx #13
stx $d600
wait6 bit $d600
bpl wait6
sta $d601
lda atr_hi ;update attributebase pointer
ldx #20
stx $d600
wait7 bit $d600
bpl wait7
sta $d601
lda atr_lo
ldx #21
stx $d600
wait8 bit $d600
bpl wait8
sta $d601
flag2 dec cols
beq end
flag3 jmp main
end cli
rts
cols byte 0
soft byte 0
scn_hi byte 0
scn_lo byte 0
atr_hi byte 0
atr_lo byte 0hscroll.prg (188 B) EDIT: I put the attribute memory at $0800, this should have been $1000 (not corrected in source or program) |
|
|
|
Post by Pyrofer on Nov 20, 2018 12:55:32 GMT
Just to add to this, a conversation from IRC that sheds some light on the issue,
"so the smooth x register has immediate effect, but the screen pointers you have to lock in on the previous frame, just before the last line
Believe me there was a lot of WTF's with the seemingly simple logo swinger in RFO-VDC until I figured that out.
Worse, the screen pointers need to be set before the last _visible_ line of the previous frame (like row 25 of text).
IIRC, the logic is like, wait for out of vblank, set screen pointers for next frame, wait for vblank, set smooth scroll regs"
|
|
|
|
Post by oziphantom on Nov 20, 2018 13:28:17 GMT
I was just coming to ask is it doing something crazy such as this... Here is my test so I set the Low position of the Screen to be FF and Attributes to be FF so its 1 char back. I then DMA shift the screen down 1 char. This is all in the same frame. Here is what I see Change Screen Pos;Shift chars wait vblank Nothing is updated on the screen wait vblank The shifted down portion of the screen is now visible wait vblank the screen shifts over 1 char Thus updating the screen pos/attribute pos seems to have 2 frames lag?  |
|
|
|
Post by oziphantom on Nov 21, 2018 6:34:00 GMT
The plot get deeper.
The reason why it latches the offset address before VBlank is because it Also reads in at least the Char data for the first line. So if you modify something in the top row during VBlank it won't show up until the frame after...
This makes me question just how does the VDC get such data. I assumed it runs RAM at 2mhz, but it needs all of that bandwidth to grab Char data... but every 8 lines(well in standard form) it needs to get 160 (in standard form) bytes for chars and attributes, but it can't not grab char data for a line.. so when does it pull it?
|
|
|
|
Post by willymanilly on Nov 21, 2018 8:02:58 GMT
To deepen the plot even further, the latching varies depending on the smooth Y value.
I added a test in my VDC split program which I didn't end up finishing in a state for release before going on holiday. I've attached a copy without source.
Extra keyboard commands not obvious are:-
Y - adjust smooth Y L - latch test I - increase number of bytes for blockfill test
note: when latch test is enabled, initiating another test afterwards, the latching will be set to shifted latch. I will fix this before I release this program with source code.
To see the latching positons, press keyboard key L and set the delay to 3048. Adjust the split position using keys A and D to see where the latching occurs.
Adjust Y smooth using keyboard ket Y to observe other latch positions.
Latch position for different values of Y smooth are shown in following table. In summary the latching occurs y smooth number of lines before VBLANK. The first line of characters and attributes for the next frame is buffered during the display of the last visible line of characters after the latch. I've deduced this from the delays per line observed in the block fill test of my VDC split program.
Note: Press P to set VDC for correct PAL values for following values to be valid.
| Y Smooth | delay | | 0 | 3048 | | 1 | 3009 | | 2 | 2FCA | | 3 | 2F8B | | 4 | 2F4C | | 5 | 2F0D | | 6 | 2ECD | | 7 | 2E8E |
This is all emulated in Z64K.
Attachments:vdcsplit.prg (4.13 KB)
|
|
|
|
Post by oziphantom on Nov 21, 2018 13:58:37 GMT
Basically the chip designer has "saved a gate" buy not needing to make an extra event, and is just using the last line to get the first line as it needs to happen before the first line. So it would move with Y scroll for "free" still want to punch him in the face, but I know Bil already did and that is good enough for me  Also I'm doing a horizontal game  Crazy though, we make a special RGBI plug that pulls VSync and HSync out and connects them to User Port, so we can get a NMI on VSync, and we can get Timer A to count HSync pulses giving us Line Counter. |
|
|
|
Post by willymanilly on Nov 22, 2018 20:33:28 GMT
...still want to punch him in the face, but I know Bil already did and that is good enough for me Think they got a well deserved flogging for not including IRQ's either. |
|
|
|
Post by nikoniko on Nov 26, 2018 0:12:22 GMT
To deepen the plot even further, the latching varies depending on the smooth Y value. [...] This is all emulated in Z64K.
Do you think one could create a mixed-mode interlace display where even fields are bitmapped and odd are text, as long as one accommodates the VDC's latching behavior and changes parameters at the right moment before vblank? I experimented with trying to create such a mode years ago when I had my last C128 but failed and wrote it off as probably impossible to do. Now I'm wondering if I just had my timing wrong. I was switching modes during vblank rather than shortly before, and always ended up with a corrupted display. |
|
|
|
Post by willymanilly on Dec 8, 2018 21:30:49 GMT
Do you think one could create a mixed-mode interlace display where even fields are bitmapped and odd are text, as long as one accommodates the VDC's latching behavior and changes parameters at the right moment before vblank? I experimented with trying to create such a mode years ago when I had my last C128 but failed and wrote it off as probably impossible to do. Now I'm wondering if I just had my timing wrong. I was switching modes during vblank rather than shortly before, and always ended up with a corrupted display. In theory you could I suppose. However, a combination of half the text and bitmap graphics information missing and the interlace flicker would probably make this mode challenging to the eyes. If you have any test programs trying to implement this mode I'd be interested in getting a copy to compare results with Z64K compared to real hardware.  |
|
Also I'm doing a horizontal game 
