BEQ seems to just lock it up. Which is odd. It freezes and doesn't scroll. I will play with that. I check the status reg in a lot of places but mostly you don't actually need to. You can fill the registers without much trouble, it's only when you start writing byte after byte of data to the thing that it needs status checking. I tested that quite heavily in Boulder Dash when speeding it up. Default character height is set, so 8 pixels. The smooth scroll register seems to know about that, if you try moving extra pixels it doesn't work and just wraps back to the first. Yeah, I did basic scrolling up the screen first (which doesn't require double buffering, down does). I did it pixel smooth at first without the hardware register and it worked fine. Then I added the hardware register for pixel offset and scrolled a whole 8 pixels at a time and it jumped just like in this video. I DON'T trust VICE. I found that out with Boulder Dash. I use a real flat 64k upgraded 128 to test on (which caused ALL sorts of problems before I found out that I had to set the bit to tell it there was 64k of vram!) Does pretty much the same on real hardware as emulator for this bug. I am pretty sure VICE is representing the problem correctly and I just need to work out how to get around it. It looks to be the same issue the other guy doing a simple text scroller came accross, but in the other axis for me. (btw, for that many pixels I could smooth scroll the shit out of that text without jitter).
So. I wrote a "smooth" scroller using colour bitmap mode.
The flickering experienced when the smooth scroll register resets is horrible. It doesn't look as bad on VICE but it's terrible on real hardware. I am using a double buffered screen for scrolling with the new data being rendered into the second screen so the process of scrolling the 9th pixel is very fast, reset the smooth scroll register and then update the screen address registers. I've made wild guesses at why it flickers so much but it looks to be timing related as on VICE I get the odd smooth scroll where I presume I hit the right time "by accident". This is taken from my real flat 128 (64k upgraded) not vice.
It's possible to stop the flicker. You need a decent interrupt loop setup linked to vblank to time when to do the reset of the smooth scroll register. I have a whole screen of colour bitmap scrolling down the screen and depending on when I start the scrolling I get none, some or all flicker. When there is none it looks lovely. I need to experiment with exactly what the timing needs to be in relation to vblank so I can consistently get no flicker.
I think I am confident it's possible though. BTW, whole screen scrolling in colour bitmap.
Interestingly there IS a chip that does RGB to S-Video. I bought it and have yet to make up the board but it should work. Interesting to note is the Amiga 500 A520 Modulator does RGB to Composite if that helps at all, I think it might need odd voltages to make it work though.
Playing with other modes to see what else I can do. The flickering smooth scroll register bug is killing me atm. Been away at my parents and annoyingly the SCART TV here doesn't switch into RGB mode so I haven't done any of the testing I wanted and the VGA monitor (2 of them!) won't work with the VGAmania demo I wanted to try. I turned on my O'Scope to check the timings and it blew up. Not a good weekend. I wan't to play with VGA timings on the VDC to see if I can get it to work on most monitors and then I might do a smooth scrolling game in colour bitmap mode in VGA for the C128 VDC. Just for kicks.
I can scroll a monochrome bitmap easily and fairly quickly. I wanted colour. Now I have 2 options, either go for 8x2 mode and scroll 2 pixels at a time (faster, less smooth) or use the hardware smooth scroll offsets as tried in this scrolling text demo...
So I tried the smooth scrolling register, scrolling from the bottom up. I get the same flickering as the text demo when scrolling my colour graphics
I tried syncing it by putting a wait loop checking the vblank register but had no luck, maybe waiting a number of cycles after the vblank triggers might work but I can't be bothered to play with it anymore.
I am frustrated and angry at VICE. for all I know I have hit the working combination at least once and it wasn't emulated correctly. My real hardware does very different things to VICE and my programming has taken all day testing against an unknown moving target of vice. For all I know I had working code many times and kept changing it because of poor emulation.
I need a way to get code onto the 128 without moving SD cards around.
Correct me if I am wrong but I thought that was just to hide the edges so you don't see the new character suddenly appear on the VIC-II ? Nothing to do with the actual scrolling at all, just a cosmetic bodge to make things look nicer.
I get the feeling the smooth scroll feature is actually bugged in the VDC hardware. Has anybody tried smooth scrolling vertically yet? It would be interesting to see of both axis had the same issue, or indeed of scrolling in the other direction caused it too.
I was just toying with the idea of a vertical scrolling shooter. If I can get block copy to move the screen down quick enough and add new pixels at the top I think I could manage with 2*8 or 2*16 colour cells for speed.
The real problem comes with the lack of logical operators on the block copy so placing your character, enemies or bullets will be a PITA.
You're right of course, I am using 8x16 cells for Boulder dash to speed up drawing the screen. It works to the point the game is playable and left me with a little overhead to "finish" it. I am fighting overall speed and memory all the time but I am generally keeping the right side of both.
The problem I have with Text mode is it's not really 2 colours in 8x16, it's 1 colour in 8x16 and a background colour for the whole screen. Just a real multicolour text mode would make the whole thing look SO MUCH nicer. Sadly, even when you turn on the colour flag for bitmap it has no effect in text mode and instead of setting 2 colours in the attribute cell you set one colour and some crazy pointless attributes. If there was a secret way to hack the VDC to drop the attributes and do a second colour I would be very happy. I feel that is not the case however.