|
|
Post by Pyrofer on Sept 11, 2019 8:02:20 GMT
So here is a question. The VDC uses a 16mhz dotclock. After doing a lot of math I came to the conclusion that it has 1024 pixels per line. That includes 640 visible, 160(ish) border pixels and the rest lost in blanking and sync pulses.
However, that does not appear to be the case. Does anybody know more about the actual way the VDC pushes pixels can tell me?
I am trying to convert my scandoubler from a working "line doubler" that only does a line at a time to a full frame doubler. However, I can't get a solid image with the 1024 pixel width assumption.
I am now not sure if it's a hardware problem my end or my assumption about the VDC output is wrong.
I know there are people here who worked on C128 emulators so I would greatly appreciate their input.
|
|
|
|
Post by mirkosoft on Sept 11, 2019 10:10:14 GMT
VDC 8563 was first used in Commodore 900 and there were 2 options: 1024x800 gfx or text console.
Details about console I forgot, but I'll search in resources.
BTW - 8563 version used in C900 had dedicated 128k RAM. Why was this cutted out I'll never understand, even how was 128k VDC RAM handled.
In 64k is place (only data) max. for 1024x512.
But nice will be to see 1024px text mode, if you try it. It was overload in very old thread. I'll find link and C900 details and post it here. Of course my posts are not important in compare of emulator developers.
Miro
|
|
|
|
Post by willymanilly on Sept 12, 2019 0:16:16 GMT
Your maths should be correct for default values of a PAL c128 with newer ROM but it should be noted pixels per line will not always be a fixed number for all modes the VDC is capable of.
A simple formula to calculate pixels/line is (reg0+(SinglePixelMode?1:0)) x ((reg22>>4)+1).
For PAL c128 with new rom it would be (127+1)x(7+1)=1024
For NTSC with either ROM or PAL c128 with old rom it would be (126+1)x(7+1)=1016
The above assumes pixels/character during blanking and sync pulses is the same as the visible characters. It's been awhile since I've had some free time to play with emulator so I'll need to recheck but I think some of my timing tests I've used to explore other aspects of the VDC confirms the above formula.
|
|
|
|
Post by Pyrofer on Sept 12, 2019 8:04:04 GMT
Thanks for that!
That might be why I am having so much trouble.. I will have to remove the reliance on exact pixel counts for this to work...
|
|
|
|
Post by tokra on Sept 12, 2019 14:40:59 GMT
What is this "SinglePixelMode" you are speaking of?
|
|
|
|
Post by Pyrofer on Sept 12, 2019 20:09:22 GMT
Not really talking about 128 modes here, just how I capture the output from the VDC.
The goal is to capture every pixel perfectly, digitally so the conversion works from a perfect source of the image. That way you get a VGA signal out as if it was the original picture...
The problem of course is capturing every single pixel when you don't know HOW MANY there are lol. It seems my original assumptions about how to do it fail, but thats just how these things go. I have new, better ideas and WILL make this scandoubler work. A nice progressive scan de-interlaced VGA output from the VDC that's compatible with ANY display mode it makes? Lets try!
My new method is much more adaptive and should work with more screen modes.
I have already managed to view mode 1 mode mania in a de-interlaced VGA output and I can tell you,
It looks.. Freaking... AMAZING.
|
|
|
|
Post by willymanilly on Sept 12, 2019 20:40:53 GMT
What is this "SinglePixelMode" you are speaking of? It's just referring to the normal mode of the double pixel feature that is controlled by bit 4 of register 25. i.e. - if bit 5 of VDC register 25 is 0 SinglePixelMode =1 (VDC 80 column) - normal
- if bit 5 of VDC register 25 is 1 SinglePixelMode =0 (VDC 40 column) - double pixel
By default bit 4 is not set so SinglePixeMode would equal 1 in my formula. Another useful formula once you know the pixels/line is clock speed/pixels per line = horizontal frequency where clock speed equals 16000000 for normal mode and 8000000 for double pixel mode. e.g when pixels per line = 1024 (default PAL new rom), horizontal frequency = 16000000/1024 = 15625 Hz. |
|
|
|
Post by tokra on Sept 13, 2019 8:53:32 GMT
Ah, I see, I knew that of course ;-) The original formula was posted some years ago by hydrophilic if IIRC. I used that to adjust my VDC Mode Mania modes to be close to PAL or NTSC.
|
|
|
|
Post by Pyrofer on Sept 13, 2019 9:08:39 GMT
The total pixel count may vary but at least the pixel clock remains constant. I just need to work with watching the hsync pulses instead of counting the pixels in and out.
As I said, the advantage is that it should then deal with random modes better and push a little of the work out to the monitor connected.
|
|
