Ineverse of RAMDAC - Analog 512x384 timings -> translation -> SE/30 A/B input?

[Trash80toG4]

Don't wanna tangentially muck up the fabulous IIsi into SE/30 thread that @zigzagjoe has running over at the MLA with this craziness.

@Bolle posted parameters of the conversion problem.
_______________________________________________________________________________

The Apple 12" 512x384 video mode has 128 pixels of blanking added to it for a total line length of 640 pixels.
The compact Mac video signal specifies 192 pixels of blanking so a total line length of 704 pixels is needed. Generating a 512x384 video signal using a total length of 704 pixels will result in a usable picture on a stock analogboard. That's what I am doing on my grayscale card for the bumped up resolution.
Feeding an Apple 12" 512x384 signal with 640 pixels total line length (after mangling the horizontal drive signal to get appropriate pulse durations) to a compact Mac analog board will result in the picture folding over. I wasn't able to shift the active area around by modifying the HSYNC pulse to get rid of the foldover.

As it seems the output resolutions are hardwired in the RBV and can't be configured from software that would prevent the use of 512x384.
_______________________________________________________________________________

Wondering if a microcontroller could be used to massage the proposed DACRAM's output into signals @Bolle is using for 512x 384.
- given feasibility of crazy DACRAM development notion
- might a microcontroller be fast enough to tack 32 pixels onto blanking period on each side of analog 12" RGB output in real time?
- WAG: doing conversion of output for next frame while converted last frame is drawing on CRT slows output by one frame = time shift?


Software/Firmware games over there are way above my pay grade, but insane notions for end runs around problems in hardware . . .

 

[Trash80toG4]

Caffeine is finally kicking in.

Time shift can only be achieved by dropping every other frame? Would this induce unacceptable flicker?

Wouldn't work on an LCD, but such wouldn't be required as it's digital to digital, no DACRAM timewarp required. However, phosphor latency of CRT might smooth things out just enough to be feasible?

Might a VGA input LCD controller be used to provide digital input for required every other frame translation?

 

[Trash80toG4]

Old project, wondering where it has gone. Full feature set here.

Features​

• CRT and LCD display support
  • 24bit Standard VGA interface
  • Separate VSYNC/HSYNC and combined CSYNC synchronization signals
  • Composite BLANK signal
  • TripleDisplay support
• 12bit Interface
  • Compatible with DVI transmitters and 12bit VGA ADCs
  • 4 different output modes
  • Can be used simultaneous with the 24bit interface
• User programmable video resolutions
• User programmable video timing
• User programmable video control signals polarization levels
• 32bpp, 24bpp and 16bpp color modes
• 8bit gray-scale and 8bit pseudo-color modes
• Supports video- and/or color-lookup-table bankswitching during vertical retrace
• Flexible master and slave interfaces
• Operates from a wide range of input clock frequencies
• Static synchronous design

_______________________________________________________________________________________________________

Clarification of question above? *****

Could something like this be run from VGA input to output 8bit GS mode signals to A/B of SE/30 or the GS harness? Could the blanking periods be adjusted in real time? Dropping HDMI video frequency from 60Hz to 30Hz seems to be a thing. Might that roughly equate to dropping every other frame of IIsi video output if real time conversion can't be attained?


***** Further muddled? I think schematic and spec pages go together? Not at all familiar with GitHub cross referencing. They seem to be linked in my duckduckgo hits?

 

[Nycturne]

Time shift can only be achieved by dropping every other frame? Would this induce unacceptable flicker?

Wouldn't work on an LCD, but such wouldn't be required as it's digital to digital, no DACRAM timewarp required. However, phosphor latency of CRT might smooth things out just enough to be feasible?

CRTs that have aged produce noticeable flicker to me at 60Hz already. I wouldn't want to try to use one at 30-40Hz at all. I once tried a Plasma TV that had to drop to 48Hz to get correct film cadence, and... just no. Some people might be able to get away with not noticing it, but I think this approach is pushing it.

That said...

Could something like this be run from VGA input to output 8bit GS mode signals to A/B of SE/30 or the GS harness? Could the blanking periods be adjusted in real time? Dropping HDMI video frequency from 60Hz to 30Hz seems to be a thing. Might that roughly equate to dropping every other frame of IIsi video output if real time conversion can't be attained?

My thinking here would be that doing this in the digital domain would be easier, as you could buffer the inputs and feed the output from the buffer. Then it becomes more a question of how much latency you introduce in the conversion. It does add other considerations/complexities though.

For a case like this where the CRT can very likely handle a refresh rate that's slightly out of the intended spec, you should be able to keep the refresh rate the same on both sides. That should simplify some aspects of converting between the two signal timings. At least at a high level it seems possible to do something like this with around a line of latency once things are dialed in.

I suspect it may even be doable with a Pi Pico using PIO to sample the input signal and generate the desired timings. Especially if the output is meant for a grayscale monitor.

 

[Trash80toG4]

My thinking here would be that doing this in the digital domain would be easier, as you could buffer the inputs and feed the output from the buffer. Then it becomes more a question of how much latency you introduce in the conversion. It does add other considerations/complexities though.

Looks like we might keep it digital on a IIsi board reload for SE/30?

The video signals are generated by the Apple custom RAM-Based
Video (RBV) chip and are driven through a combination color
lookup table (CLUT) and video digital to analog converter (VDAC)
chip. Each monitor identifies itself by grounding certain pins on the
RBV causing it to automatically select the appropriate pixel clock and
sync timing parameters.

Dunno how Sync Sign works, but bits 0-8 of Video output from RBV Might be hijacked and VDAC removed from the schematic? No need for CLUT in a dedicated B&W or grayscale system, no? RBV is the Achilles heel of current efforts over at the MLA. If something like the circuit above can be wedged into the Block Diagram of the IIsi in place of VDAC. we might get there? Might we adjust the blanking period of 12" RGB output in real time at that juncture in real time?

If not possible, redrawing "every other frame" on the CRT a second time whilst adjusting the blanking periods of the next "other frame" is accomplished would halve the actual frame rate, but might be fine in grayscale for everything but demanding gaming?



edit: wouldn't need to excise VDAC so much as to just ignore it? Assumption would be that Address/Data on left side of VDAC only relates to CLUT?

 

[Nycturne]

Looks like we might keep it digital on a IIsi board reload for SE/30?

<SNIP>

Dunno how Sync Sign works, but bits 0-8 of Video output from RBV Might be hijacked and VDAC removed from the schematic? No need for CLUT in a dedicated B&W or grayscale system, no? RBV is the Achilles heel of current efforts over at the MLA. If something like the circuit above can be wedged into the Block Diagram of the IIsi in place of VDAC. we might get there? Might we adjust the blanking period of 12" RGB output in real time at that juncture in real time?

If not possible, redrawing "every other frame" on the CRT a second time whilst adjusting the blanking periods of the next "other frame" is accomplished would halve the actual frame rate, but might be fine in grayscale for everything but demanding gaming?

I mean, if you can reverse engineer and/or bypass the right components, you can pretty much do whatever you want once you have the raw pixel data and use whatever timings you like. That's the easy part in the digital domain. You can spit out DVI/HDMI for that matter. This gets into the space of the sort of RGB/HDMI mods that vintage game consoles do. Not something I have experience with myself, but it's doable. But replacing the whole RBV might be overkill if it's enough to hijack the digital data coming off the RBV and reclock it yourself on the back end. Might be easier that way as well. But the foundations of what you are trying to do are basically the same as any digital output mod for something like an NES/SNES or the like. Just you want to produce an analog signal on the back end still, which itself is quite doable. This just might require some software running on a microcontroller of some kind, and be fast enough to keep up with the signals being flung around.

I still believe that thinking in terms of reducing refresh rate to make the problem simpler is not the right way here though. Consider how folks have built upscalers/etc that take in composite/VGA/etc and can spit out anything from frame rates in sync with the input signal, or even very specific frame rates like 60Hz HDMI. These are absolutely capable of spitting out different pixel clocks on the other end and using different approaches to minimizing latency, and how to deal with inputs that are slightly faster/slower than the intended output. In your case, you actually have it a bit easier since CRTs are a bit more flexible than a modern display, and so you don't have to worry as much about refresh rates being exact.

The trick here is that you ultimately have data coming in at one pixel clock, and you want it going out at a faster pixel clock so you can add a longer back porch to it (assuming same number of lines, same refresh rate, you need to spit out more pixels in the same timeframe even if the extra pixels are just black). So the simplest way is to buffer some of the data, and spit it out in some well-defined chunk. Buffering by the line is the easiest here, as you can capture just the active pixels in the buffer, and setup the exact line timings you want for the output. Buffering a line just means you don't start sending the line to the SE/30 monitor until you've read in a whole line from the logic board's circuit. So that adds some amount of latency, but not enough for anyone to notice. It's still "real-time" for the purposes here.

 

[Trash80toG4]

The every other frame notion is a worst case, last resort kinda deal. Spitballing every nasty approach I can possibly come up with here.

Vampire Video in the IIsi is a well and truly diabolical affair:
- was wondering about bit-banging the DRAM frame buffer to do an end run around RBV entirely?
- if memory check is turned off, might a quartet of 8bit VRAM ICs be addressed as the buffered portion of DRAM in Bank A?
- something along the lines of the IIsi RAM-Muncher INIT might isolate the frame buffer in dedicated VRAM?
- thinking RBV and VDAC need to be there for POST, but hoping to find some slack in an unchecked memory setup?
- dual port nature of VRAM might allow a "Lamprey Video" setup to suck the life blood from the frame buffer on its way to ignored RBV? ***

Dual port SRAM probably won't work for increased bandwidth? Might snag a tick or two to use for front/back porch additions? Thought of that when concerns came up about DRAM based VRAM refresh incompatibility with IIsi DRAM refresh setup?


*** truly clutching at straws in adult beverage consumption mode here.