Tokra could give more details, but as I recall you have to momementarily switch it to 8x2 and then back to 8x1 each frame. Because the VDC doesn't have an IRQ, you basically have to sit in a wait loop checking for V-Blank, and then kick the VDC in the head (otherwise it forgets to output in 8x1 mode). Assuming you have something else for the CPU to do, besides sit around waiting to kick the VDC, then you would need to synchonize a CIA timer with VDC frame rate, like Risen From Oblivion.
This switch from 8x1 to 8x2 and back to 8x1 screws up internal pointers of the VDC display. I spent a few hours playing with it before I could get it to work. And I still can't really describe how this memory re-alignment really works. I suspect it is critically involved with the size of the image and *when* (i.e., which part of the frame the VDC is currently drawing when) you decide to slap the VDC in the face.
Its been a while since I ran Tokra's VDC Mode Mania, but I believe it has at least one image in 8x1 mode. The viewer is in BASIC so it is pretty easy to understand. As far as bonking the VDC on the head, I think he used READ/DATA/POKE to install the ML program. In other words you would have to run the demo until at least that part, and then you could use MONITOR to examine the code.
"This mode came about trying to figure out how the (brilliant) "Risen from Oblivion"-demo does its own FLI-mode. By hardware the VDC only supports a maximum of 8x2 color-blocks by setting register 9 of the VDC to two rasterlines. If you try to set it to 1 rasterline to get an 8x1 mode the VDC won't activate the display and you only get a blank screen. The trick to force the VDC to display is to watch bit 5 of$d600 (VBLANK) and switch register 9 to one rasterline right after the VLANK-period has finished and back to any other value once VBLANK starts again. This fools the VDC into displaying the 8x1 mode. However since the VDC now has to fetch the character- as well as the attribut-byte for every rasterline you can only address a screen of 60 chars wide (=480 pixels), otherwise the screen gets garbled. The register 9-switcher is realized as a quick and dirty 47 byte assembler routine. If you want to do it proper you will have to set up a VDC-raster-interrupt and for that you first need to measure your specific VDC-chip's speed. That is what "Risen from Oblivion" does when you start it."
Too bad the commodore128.org-forum seems gone for good together will all the discussions :-( Anybody heard from BDD?
However since the VDC now has to fetch the character- as well as the attribut-byte for every rasterline you can only address a screen of 60 chars wide (=480 pixels), otherwise the screen gets garbled.
Is that even with the ram refresh set to zero?
Yep, RAM-refresh just will get you one or two more characters. I remember specifically testing this when I created the VDC-FLI mode. I think without RAM-refresh set to zero you will only get 58 or 59 characters width.
I've got the 8x1 color mode Tokra uses working correctly on my emulator! I created a test program that uses both of the CIA2 Timer measuring transitions of VBLANK to try and confirm the size of the frame for Tokra's VDC-FLI 480x252 Non Interlace 8x1 mode and it appears to be 295 raster lines/frame. I concluded this by using the formula (2000000*18546)/(985248*127). The test was using old roms. 2000000=VDC clock speed, 985248=CIA clock speed, 18546 = (65535-46988)+11 65535=default CIA timer value. 46988 =read timer value after timer stopped when VBLANK is cleared. 11= cycle count correction from when timer stopped. Tests were done in 2MHz mode.
I have a lot of data I am still deciphering but it seems the VDC forces a v sync signal and starts fetching graphics data if VBLANK is set and the character row counter = 0. This causes the VDC to skip 34x60 (2040) bytes of graphics data and 1x60 bytes of attribute data before displaying the image. 60 is the value in the horizontal display register. My conclusion so far is the 34 is from overflowing the character row counter. In short, my model implements this by overflowing the character row counter to the maximum value of 31 and counts back to zero.
I haven't looked at the source to Risen from Oblivion but it doesn't appear to get triggered by this method and only skips 3 bytes of graphics data before displaying the 8x1 FLI image. This is emulated as well.
I will try and give a more detailed explanation once I analyse the data from my real C128 in more depth. For now you can see the results of VDC-FLI for yourself by downloading the latest version of my emulator here ==> www.z64k.com and loading up VDC Mode Mania.
Thanks, WillyManilly... that is the most progress I've seen in yeaars... Tokra found some cool video modes, but I won't pretend to understand them... Thanks for sharing your discovery with us... now I have to mentally "conglomerate" all this info