RGB 15khz version

[dlxmax]

Apple II RGB cards are prohibitively expensive.
It looks like this could be reduced to simply outputting a 15KHZ RGB signal?
I'd love to build that model!
Old consumer-grade TV's are easily modifiable to accept RGB input, and that is my preferred way to retrocompute ;)

[markadev]

Hey there, I think that such modification would be possible. I'm not too familiar with that video mode but since the RGB signal out frequency is asynchronous from the internal Apple bus then the video output could be anything, only limited by the Pico's hardware.

The scanlines generated by the rendering firmware are doubled anyway to fill a normal 640x480 VGA screen so just getting rid of the doubling (and some of the empty scanlines for vertical padding) could get you down to 320 scan lines which, as far as I understand, is the number of lines you get in a 15KHz signal.

[markadev]

Or is 15KHz 240 scanlines 😂 ? Either way, the Apple II video out is only 192 scanlines so it would fit

[Alex-Kw]

320x240 is "normal" but 15K RGB is a pretty loose spec in practice. If you look in the MAME drivers for example you'll see all sorts of line counts.

I think I see the doubling function in pico/vga.c around line 138. If I were to try this in practice, is that the right place to look to disable that? In addition should the VGA_WIDTH and VGA_HEIGHT be halved in pico/vga.h? And as far as empty scanlines, is this handled with LINES_IN_BACK_PORCH and/or NUM_SCANLINE_BUFFERS? And then on first glance is there other applicable stuff in lines 10-18 of pico/vga.c? A lot of questions, I know.

Analog 15K RGB would be quite nice for owners of PVMs, arcade monitors, and even SCART -> component transcoders.

[markadev]

Hmm, the more I think about this, the more complicated it seems 😄

Initially I had the thought that you could just half LINES_PER_FRAME but that would end up doubling the vertical frequency from 60 -> 120 Hz so you'd need to also half the PIXEL_FREQ value or double PIXELS_PER_LINE to compensate because

PIXEL_FREQ = PIXELS_PER_LINE * LINES_PER_FRAME  * 60Hz

I wouldn't decrease PIXEL_FREQ because it could have a large ripple effect on some of the rendering functions so that leaves the option of doubling PIXELS_PER_LINE. With that there are a few other places I think would need to change:

1. LINES_IN_BACK_PORCH would need to be halved (or thereabouts)
2. All the rendering functions also skip some lines at the top to center the Apple II image in the VGA 640x480 viewport so those should be halved as well (for example). This could just be done in vga_skip_lines as I think all the rendering functions use that to skip the lines.
3. All of the rendering functions use the repeat_count field that you found in vga.c line 138 (for example). You'll never want that "scanline emulation" code to run (you got real scanlines anyway 😃) and you'll want to halve the repeat_count value.

I think those would be the necessary changes to get the basic syncing working. If you do this I would recommend to verify with a scope before connecting anything!

However, with just these sync changes then I believe the picture would be smooshed onto the left half of the screen because the PIXEL_FREQ is running 2X faster than the typical signal for your monitor, because we doubled PIXELS_PER_LINE instead of halving PIXEL_FREQ. This could be compensated for by just adding some extra delays to stretch every pixel in vga.pio.

I don't think VGA_WIDTH, VGA_HEIGHT, or NUM_SCANLINE_BUFFERS should be changed. None of theses constants affect the signal timing and are mostly used for diagnostics or data-structure sizing.

Since I don't have this hardware this is just a thought experiment for me so post back with any results if you try it!

[Alex-Kw]

Thanks for the detailed reply! If I get to it, I will dust off the oscilloscope and let you know how it goes.