|
|
Post by VDC 8x2 on Jun 24, 2014 20:39:40 GMT
Anyone remember what trickery you had to do to get 8x1 color mode on the vdc?
|
|
|
|
Post by hydrophilic on Jun 27, 2014 23:59:39 GMT
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.
|
|
|
|
Post by tokra on Jun 29, 2014 21:07:09 GMT
I quickly copied my notes from the original CSDB-entry of VDC-FLI: "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? |
|
|
|
Post by hydrophilic on Jun 30, 2014 0:17:30 GMT
Yeah lots of useful information has vanished. I haven't heard from BDD. He was gone from c128.org for a long time then made a few posts early 2014 and disappeared again.
|
|
|
|
Post by VDC 8x2 on Jun 30, 2014 2:52:21 GMT
Is that even with the ram refresh set to zero?
|
|
|
|
Post by tokra on Jun 30, 2014 12:19:08 GMT
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. |
|
|
|
Post by TacKer on Jun 30, 2014 16:14:38 GMT
|
|
|
|
Post by willymanilly on Mar 13, 2017 6:16:57 GMT
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. |
|
|
|
Post by hydrophilic on Mar 30, 2017 7:26:47 GMT
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  |
|
|
|
Post by willymanilly on Oct 10, 2018 23:20:09 GMT
I've done some more experiments with Tokra's MDC 8x1 mode and have created a test program that proves they display with 295 raster lines. There is some jitter and CIA correction to account for but that is much less than the cycles/ scanline so can be ignored. Resulting scanlines will be the round result of the following formula: VIC cycles per VDC frame x (VDC byte cycles per second / VIC byte cycles per second)) / (VDC Horizontal total + 1). The results show the VIC cycles per VDC frame. I have a PAL C128D as my reference machine where the CPU runs at 985248 cycles/second. The VDC runs at 2000000 byte cycles/second (16,000,000 pixels/second). Basically because the screen line counter for the screen rows overflows using the trick to display 8 x 1 mode, an addition 32 lines are generated per screen. The following is a brief explanation what the program does. Look at the source for more information The first line of the results are Tokra's default values. 4819 hex = 18457 decimal. (18457 x (2000000/985248))/(126+1) = ~295 lines The second line of the results are PAL adjust values. 4CDB hex = 19675 decimal. (19675 x (2000000/985248))/(127+1) = ~312 lines - Change register 1 (Horizontal Total) to 127
- Change character Total Height to $18 instead of $07 when transitioning from character height 0. This adds and extra 17 lines to make 312 lines
For this mode change in the vdc mode mania basic program
- Change the 20th data item in line 50 from e7 to f8.
- Change the 2nd data item in line 3020 from 126 to 127.
The third line of the results are NTSC values. 4047 hex = 16455 decimal. (16455 x (2000000/985248))/(126+1) = ~263 lines. This will crops the bottom of Tokra's image in it's current format. - Change register 1 (Horizontal Total) back to 126
- Change register 4 to 223 (255-32)
- change register 6 to 222 (254-32)
- Change character Total Height back to default $07 when transitioning from character height 0.
For this mode change in the vdc mode mania basic program
- Change the 8th data item in line 3020 from 255 to 223. Change the 10th data item in line 3020 from 254 to 222.
- Make sure the 20th data item line in line 50 is set back to e7.
- Make sure the 2nd data item in line 3020 is set back to 126.
 Attachments:VDC81.asm (2.72 KB)
VDC81.prg (569 B)
|
|
