Some Video Questions for the Experts

Started by airship, September 20, 2007, 06:49 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

nikoniko

Quote from: airshipMaybe we could start with one of these? :D
Ah, I missed your nice picture there when I viewed the thread earlier. I didn't know there were any genlocks made with C64/128 in mind. Does the included software let you do titling?

airship

I have absolutely no idea. I found that pic on the Hungarian web site where the picture is hosted, which by the way has pictures of LOTS of cool C64 hardware, much of it unseen on this side of the pond. Just click on all the buttons and links. Every one seems to lead to new 8-bit magic.

http://www.freeweb.hu/bithunter/

The C64/128 genlock was an absolute shocker to me. I'd never heard of it. But, of course, now I want one so bad my eyes are all bugged out and my hands are furiously throwing money at the screen hoping one will magically appear. Hey, it works with eBay!

My research only shows that Scanntronik now make "high-quality data loggers", though in the past they made several C64-related video products, including video digitizers. Most of them are pictured on the Hungarian site above somewhere. Fortunately, the product names are generally in recognizable English, even if the descriptive text is not.

EDIT:  Wow! On this page: http://www.freeweb.hu/bithunter/ he's got the driver disks for many of his hardware items! If you've got a piece of hardware and are missing the disk, check here.
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

hydrophilic

Quote from: niknikoThe method doesn't need to know which color is background or foreground. You simply take 2/3 color of the first pixel and 1/3 of the second. That's it. I only used the words 'background' and 'foreground' out of habit.
That's a relief: there is still hope!
Quote from: nikonikoRegardless, seems the method wouldn't work unless you converted the signal to some other form such as analog RGB.
Analog RGB is a good idea if you have a 1902 or 1084 monitor.  I was thinking for digital RGB, you could use pulse-width modulation.  This assumes the monitor (or cable!) won't filter out hi-frequencies (16 * 3 = 48MHz).

RobertB

Quote from: hydrophilicA 64/128 Genlock.  That's sooooo cool.  I thought that was vaporware.
Hmm, I wonder how the Scantronnik compares with my Comgen 64.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

nikoniko

Quote from: hydrophilicI was thinking for digital RGB, you could use pulse-width modulation.  This assumes the monitor (or cable!) won't filter out hi-frequencies (16 * 3 = 48MHz).
That's an idea. I wonder if it would work.

Also I'm thinking I may have been too quick to throw out the idea of using composite instead of RGBI, or in addition to it. Having a display with many different shades of grey would actually be very nice. I've always been partial to greyscale myself.

airship

New idea:

How about using double-buffering to get 256 different colors? Switch buffers every video frame. If a pixel in the first buffer has one color, and the same pixel in the second buffer has the same color, you'd get that color. BUT if the first and second buffers each had different colors, you'd get a visual mix of both. There'd probably be a little flicker, but not anything near as bad as doing hi-res by interlacing two offset frames. You'd be interlacing for color mixes, not resolution.
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

hydrophilic

Interesting you should mention that.  I checked the documentation for the C128 Graphic Booster.  I still am not 100% what is going, but from what I read, it is doing both spatial dithering (two pixels side by side blend for 'new' color) and temporal dithering (different color on alternate frames) with both methods you can get the claimed 65000 colors.

If VIC FLI is any indication, the flicker is not too bad assuming you choose color pairs wisely.  Of course the 'problem' is highly dependant on the particular monitor, lighting environment, and user perception.

But you are talking about using a device with a frame buffer?  That would be quite a project!  In this case, I don't think there would be any flicker since the device would output a constant color on every frame (although it would take two frames to build the image).

On the same lines, the device could also combine two rasters from a VDC interlace screen and produce a non-interlaced output with more colors.  You would get a LOT of colors combining these methods (horizontal/pixel combination, vertical/interlace combination, and temporal/frame combination).

Sounds like something I would actually pay for...

Edit
Silly me.  Vertical/interlace combination is equivalant to temporal/frame combination, unless we use 4 frames to produce an output image.  That would limit output to 15fps NTSC (or 12.5fps PAL) but since the VDC is so slow anyway, this might be practical?

nikoniko

Quote from: airshipHow about using double-buffering to get 256 different colors? Switch buffers every video frame.
I've tried that in VICE before, and it's acceptable as long as there isn't too much contrast between the first frame and the second. (Eg. Don't try to mix white and black). On a real 128 and appropriate monitor, the effect should be even better since (I think) the phosphors would have a bit more persistence(?).

nikoniko

Hmm... if my very rusty math is right, then n items, taken r at a time, with order being unimportant and no repetitions allowed, gives us

   n!
----------   combinations
r!(n - r)!

For 16 colors mixed over two frames gives us 120 possible colors. That would be reduced by some combinations being too flickery to be useful, but I imagine that would probably still leave at least 60 decent colors if not more. It might not be 256, but hey, it's still better than 16. :)

airship

I'm counting on both phosphor delay and persistence of vision. Between the two, it ought to look just fine.

Hadn't thought about the whole luminance issue. While colors that are far apart WOULD blend, they'd flicker more and look crappy. Closer colors should work better. I was initially thinking that yellow/white would make a nice light yellow, dark red/light red would make for a medium red, etc. But it would be interesting to see how far you could stretch it.

If I remember what Bil Herd has said on the C64 color palette, most of the colors are diametrically opposed pairs. There's a site somewhere with a color wheel that would show which were closest, and therefore would blend best.

And I hadn't thought of using temporal and spatial dithering together. Though slow, it might work okay for static images.
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

nikoniko

Hmm... I wonder how bad it would look to do two frames with one set of color attributes, followed by one frame of a different set. Lather, rinse, repeat. If human vision would accept it, that would accomplish something similar to the 2/3 + 1/3 mixing I proposed earlier, thus allowing many more colors to be created, but my gut tells me it would look like crap.

I've seen it done with 100Hz refresh on a PC before and it was perfectly fine, but 60Hz and especially 50Hz would almost surely be pushing it too far. :/

airship

I dunno. 60hz makes for really flickery interlace if the contrast is high. But with the screens overlaid on one another, 30fps it might not be too bad, especially with both phosphor and vision persistence working together for you.

Maybe one of you hotshot coders should whip out an assembler? :)
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

airship

Some code I found on The Fridge that pops the C128 into 2MHz mode when the 40-column display scan is in the border area:

; 2 mhz 40 column 128 mode interrupt routine
; This will enable the 40 column mode of the c128 to run at almost 2MHz!
; The trick is to turn on the 2MHz mode in the borders, and turn on the
; 1MHz mode while in the 40 column screen.
; This also illustrates the technique of interrupt handling and VIC-II
; massaging by handling the raster interrupts.
; By Todd S. Elliott

; Equates
iirq = $0314; IRQ Vector for interrupt handling
mmucr = $FF00; MMU Configuration Register
vicirq = $D019; VIC-II Interrupt Register
raster = $D012; Raster compare register
clkrat = $D030; Adjusts the speed of the 8502 chip
crti = $ff33; Common interrupt return vector

; set up the irq routine
two'mhz sei
  lda   sta iirq
  lda >twomhz
  sta iirq+1
  cli
  rts

; the irq routine to handle the 2 mhz speed output

twomhz lda #$00:sta mmucr; switch to bank 15 first
  cld; required by irq routine
  lda #$01
  sta vicirq; prevent normal raster clear-interrupt
  lda raster
  cmp #248; check to see which scanline we're at
  bcc +
  ldy #$05
- nop; a little timing tweak to finesse the raster interrupt
  dey; (NTSC timing)
  bne -
  lda #49
  sta raster
  lda #$01
  sta clkrat; turn on 2 mhz mode
  bne ++
+ lda #$00
  sta clkrat; switch back to 1 mhz mode
  lda #249
  sta raster; store in bottom scanline
  jsr $f5f8; update timer
  lda $dc0d; clear CIA interrupts
  jsr $ff9f; check keypress
+ jmp crti; return to normal irq exit routine

; end of 2 mhz routine
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine