shmups.system11.org

It looks common:
https://market.samm.com/gert-vga-666-gpio-to-vga

Very good. Although that board was not specifically designed for the OSSC Pro (and it currently says "out of stock" in that webshop you linked, although I've seen that it's an open source design), a cursory glance suggests that it could be usable. I've seen that there also exists at least one design for a Raspberry Pi VGA Board for which you wouldn't have to discard 6 out of 24 RGB bits. However, it has to be noted that, before such a board is usable with the OSSC Pro, the OSSC Pro firmware must be extended so that the video data is sent to the pins of the expanson port—the current public revision cannot do this. I'm confident that this will happen eventually.



What you're suggesting is not impossible to output, the clockgen should manage that. However, the purpose of the adaptive line multiplication mode is to generate compatible output resolutions. You're suggesting to diverge from compatible resolutions, which is at odds with that purpose. Perhaps another output mode would be better suited for the application you're thinking of (if you had a specific one in mind).

https://texelec.com/product/lo-tech-rpi-vga-board/

This is the 24bit VGA hat you were thinking of btw, Blacksheep!

Indeed that is the one.

To slightly clarify, to get from 24 bits RGB to 18, you don't have to clamp—instead downscaling to the new quantization space or dithering would be better.

For 480i/576i -> 1080i, there's no other mode (or device, I think) that can be used without deinterlacing, scaling, and a frame+ of additional input lag.

I think a 1440x1080i option would make more sense than 1920x1080i for the majority of PC CRT and HD CRT owners. 1080i output is almost exclusively going to be used by 33.7 kHz CRT owners anyway, but 1920x1080i would mean windowboxing or squashed pillarboxing of 720px wide video (which is the majority of 480i/576i content) in most cases. It would be useful for hi-res N64 games but that's about it, I think.

I'd also suggest a 1440/1920x960i mode for PC CRT owners, but I don't want to chance my arm

Is this really so exotic? I've never attempted it, but it shouldn't be that difficult.

Have you tried a DVDO? Should be able to use Game Mode line double and output 1080i.

A modded GBS with custom firmware should also be capable of line doubling 480i and outputting 1080i.

Less than half a frame of latency in both situations.

Appearently you cannot line-double an interlaced signal. You have to multiply with an odd number, so the smallest possible integer multiple is 3. This is why the OSSC has a 3x laced mode for 480i content and cannot linedouble the signal to 960i.

Don't the DVDOs have some real trouble with resolution switches? 1080i has never been a big priority for me, but if there was a good implementation with the OSSC Pro, I'd be interested to try it (or 960i) on a PC CRT over bob deinterlaced 480p, and 1440x1080i just makes more sense to me for 480i/576i (though both 1920/1440 have their uses).

Of course you can. The fields are doubled to fill the blank lines when you line double.

Line doublers were invented to handle upscaling interlaced video.

Multiple misconceptions. First, I don't understand the use of 1440x1080 for this. 1920x1080 instead of 1440x1080 does not imply pillarboxing on CRTs at all, this is again a case where the reasoning mixes up analog and digital video conceptually. If you convert to analog, the number of horizontal samples or pixels does not matter for that. An analog CRT will simply spread that out over its horizontal. With 1920x1080, you can have more samples than with 1440x1080, which will even give better quality. And going from 1920 to 1440 horizontal does not do anything to avoid letterboxing if the active line counts cannot be matched by integer line multiplication.

You would need scale mode for converting 480i or 576i to 960i because:



What. Ever heared of bob deinterlacing?



You have to multiply with an odd number if you want the output to stay interlaced. 480i/576i is just 240p/288p with a line shift, so line doubling that just changes the i to a p.

240p is ~262 total, 288p is ~312 total, 480i is ~262.5 per field (the point is it is noninteger) and ~525 per frame, 576i is ~312.5 per field (the point is it is noninteger) and ~625 per frame. So if you double the fields, you have progressive, if you triple, you have interlace again, if you quadruple, you have progressive, and so on. But if you triple, meaning e.g. ~262.5 * 3 for 480i, you have ~787.5 * 2 = ~1575 per frame total, which boils down to 1440i.

I understand the difference between analogue and digital video.

1440x960 is a perfect 2x scale of 720x480. If you want to embed that within a 1920x1080 frame (which is how I understand this adaptive line multiplier mode works, feel free to correct me), black bars will be encoded in the output signal regardless of whether it's converted to analogue from there. You can sample the console signal at a different rate to make a 3x horizontal scale of 640x480 that fills the horizontal space, but that's not ideal.

If the console signal is meant to be displayed in 4:3, then it won't matter whether it's 1440x1080 or 1920x1080 on 16:9 displays, but for all integer scaled 720x480 video on 4:3 displays and 16:9 content on 16:9 displays, there would be no way to manipulate the active 1.5:1 1440x960 frame embedded within a 1920x1080 signal to preserve the intended aspect ratio.


I was under the impression that 1080i being offered as an output option in the adaptive line multiplier mode would make it trivial enough to offer a 960i option for 480i. Obviously, that can't be offered with a straight synchronous line doubler like the standard OSSC, but if the ALM mode could ignore the half lines at the end/start of each field... ? Maybe that's too complicated outside of a full scaler though.

Also, I think it's fairly obvious SuperSpongo meant you can't line double an interlaced signal while keeping the output interlaced (which is true in the case of a basic line multiplier like the standard OSSC) considering it was in response to a query about line doubling 480i to 960i/1080i.

For 480p input (it does not make sense for 480i, see below) a suitable sampling method can be chosen, 1920x1080 out introduces no pillarboxing or changes in aspect ratio over 1440x1080 when converted to analog and output to a CRT, I don't know where you take that from. I would say try it yourself when the device is out. You're right that quality will not be ideal if the output mode's number of pixels per line is not an integer multiple of the number of dots per line from the console, although 1920x1080 can provide better quality over 1440x1080 in the general case.



It would not be a big untertaking to offer 960i out in ALM, but how to push 480i/576i into that, which you were asking about, in a way that actually makes sense? 480i doubled is 480p and 480i tripled is 1440i, 576i doubled is 576p and 576i tripled is 1728i. You also cannot simply switch between interlace and progressive like that in a twinkling as you wonder. If you line double the 480i and then re-interlace by putting the resulting 480 lines per frame into 960i's 480 line fields, it will look disfigured because the vertical interlace shift would not match the content anymore. And 960i is still not a very compatible line number/scan mode mix.

Which is what was discussed or asked above.
So yes, I have heard of Bob Deinterlacing, but it is exactly that, deinterlacing.



Correct, thank you.

So, you want each 480i field to be upscaled without deinterlacing and return a repeating pattern of two (offsetting) active image lines followed by two blank lines?

First of all, that isn't 960i; you'll need 960p. Second, that will flicker like crazy.

Next, you want to take that flickering mess and interlace it? How do the image lines map to 1080i? You want a boxed output and a 1:1 relationship between the 960p and the 1080i output? That will create a repeating pattern of: one line of image data and *three* blank lines each field after you interlace it.

I'm not sure that is something that most users would enjoy.

Edit: My apologies, it will drift and display many different patterns--still assuming we are doing frame rate conversion to handle the earlier DVDO signal dropout complaint when signals change.

I'm still not clear on why you wouldn't deinterlace 480i before you process it.

240p<->480i mode switches caused by the console incur a refresh rate change equivalent to half a line. That will indeed not work with adaptive line multiplication anyway—seamless mode switch needs scale mode with disabled framelock.


About 480i to 960i or 1080i, look, 480i to 1080p is simply Line4x bob, so 960p within 1080p (letterboxed). OK.

Then, 480i to 1080i is 240p restore and Line2x. It does not work with usual 480i, it scrambles line order:



You would need scale mode for converting usual 480i to 960i, without that it only works properly with rare 240p content that is output as 480i. Example:



And this 960i is then simply embedded into 1080i (letterboxing). Allright so far?

Also sorry you all, I will try to be more considerate/less pedantic.

Thanks, folks, that makes sense. I was thinking about how HD CRTs convert 480i to 960i (or 1080i or what have you), but clearly there’s more going on there than just line doubling which makes it less of an attractive deal. Didn’t even think of the obvious artefacts that would create from the line shifting. Sorry for clogging up the thread!

Please don't say that I'm "incorrect" if your idea of a solution is to throw out portions of the data. That isn't a legitimate solution. What even is the point of line doubling then. In your first example, even if you could losslessly scale a 1280 wide analog source you're still limited by the OSSC in outputting a 1920 wide digital signal that the display will then have to stretch into non-square pixels.

You didn't bring up any argument as to why 16:9 intended 720p can't be line doubled, or why 1280x720 can't be line doubled to 1920x1440. I explained how both is possible. Whether these solutions are "legitimate" is purely a matter of opinion—nowhere did I deny that 2560x1440 output could improve on that.

Why are you looking for an argument? I didn't think it was necessary to say, but: 1280 x 2 > 1920. I was simply throwing out there why splurging for a 2560x1440 mode would be a useful addition to me. As others have already expressed, if this is a "Pro" model that will exist alongside the standard OSSC, I am putting in my vote for the upgraded components and adding my voice to those not bothered by the increased cost that would necessitate.



Okay, let's check the tape...



Emphasis mine. Seems like you're shooting down the need for the upgrades here by equating the two without explaining the caveats which I think are kind of important. Fine if you think it's a matter of opinion, but it could be misleading to people. Personally, I see no point in line doubling if the digital signal has to be degraded in any way to fit through a bottleneck in the hardware.

Seems similar to the confusion we had up thread about how 720x480 can be integer scaled on both axes to 1920x960 if you simply change the premise of the argument, or extend it to such a degree that the original intent is lost.

N64, I already wrote that I should have added "up to 60Hz" and "isomorphic 16:9 720p with compromises" to the post. I did that now. I did not intend to distract from the fact that 1280x720 can not be line doubled and fit into 1920x1440 out without drawbacks while 2560x1440 out will not entail any of these drawbacks. I merely intended to indicate that even in case the OSSC Pro wouldn't be upgraded (to output 2560x1440) for whatever reason, there would still be ways to Line6x 240p, Line3x 480p, and Line2x 720p (by outputting 1920x1440). Also, there was no ill will or hidden agenda or anything like that.

I hope that clears up any misunderstandings.



It was never claimed or implied that 720x480 can be integer scaled on both axes to 1920x960, please point out where you think that was done. Perhaps you are just missing info/illustration in order to understand, like you did with the 480i to 960i conversion in adaptive line multiplication mode.

I just came here to bump this.

I don't care about the price, but the one thing I will be doing the most with this device is downscaling from any modern games to any old CRTs, the ones that usually have just composite input at best. Those are my favorite TVs!

Just to make sure though, from what I understand, I could connect for example an NES Classic through the HDMI input, use an add-on Composite+S-video Output module, and play on any CRT that has those inputs with the games being displayed in 240p, with any necessary horizontal stretching being done by the user on the OSSC Pro. Is this correct?

Uh, someone correct me if I'm wrong, but was downscaling support confirmed at any point, or just wishful thinking?

It was confirmed here:
https://videogameperfection.com/forums/ ... -ossc-pro/

I had a feature idea for the OSSC Pro, but I'm not sure if it would be possible. The feature relates to an annoying problem I have when playing Sega 32X games. My Genesis' video signal has a sampling phase of 0 degrees. My 32X has a sampling phase of 247 degrees. What this means is that in a 32X game that composites video from both machines, like Star Wars Arcade, it's impossible to set a sampling phase that results in the entire image being sharp. Either the 2D elements generated by the Genesis are sharp, or the 3D elements generated by the 32X are sharp.

So that got me thinking, would either of the following features be possible with the OSSC Pro:

1. Connect the Genesis to the SCART connector (RGBS) and the 32X to the VGA connector (RGBS). The OSSC Pro would then digitize both analogue inputs (with the correct phase for each) and perform the composite itself and output over HDMI.

2. Digitize the Genesis using the original OSSC and output via HDMI. Then feed that HDMI into the OSSC Pro along with the 32X connected to the SCART connector (RGBS). The OSSC Pro would then perform the composite of the HDMI and SCART inputs.

I hope this makes sense! It would be great to solve this "multi-phase" problem with the Genesis and 32X.

Many thanks,
Andy.

Interesting question/idea :D A few thoughts:


The video digitizer chip used by the OSSC Pro, the ISL51002, has three input channels, but can only digitize one of those at a time. So that's probably not going to be possible unfortunately, outside of using an expansion module that can digitize a second source. Then the two could be synchronized/combined on the FPGA and finally be output over HDMI.


In principle that could work, if the inputs are synchronized accordingly on the FPGA, as both would have free-running clocks with respect to each other.

It's crucial though that the game code has control over when the Mega Drive/Genesis has priority, and when the 32X has priority (can be changed mid-frame). [1, pp. 46, 50] Therefore it's probably impossible/impractical, or at least impossible/impractical to do correctly in every case.


Speaking of ideas, with the right cable between the DOL-001 digital A/V port and the OSSC Pro's expansion port, it could be possible to port GCVideo-DVI to the Cyclone V and have it running on there. Since the OSSC Pro already has UI facilities, the core would suffice. That could render dedicated GCVideo hardware (outside of a custom cable) unnecessary for OSSC Pro users in the DOL-001 use case, and may save a small bit of power too.

Insurrection Industries had somebody make connectors for them, but those are not available/sold anymore as far as I know. [2] There are STLs for a 3D-printable connector [3] [4] [5], although going by the description it doesn't seem to be a particularly undemanding print and the recommended way to get pins for it is to pull them from a PCI connector, apparently they can be tedious to install.

Thank you for the superbly detailed post, my lack of knowledge about the details of how the Genesis and 32X interoperate shows how naïve my suggestion was.

Without wanting to derail this thread, do you have any recommendations for how I might explore "phase shifting" the video output of my Genesis to bring it in line with my 32X? Where might be a good place to talk about the modifications you would need to make to a Genesis in order to have some sort of adjustable phase circuity?

You're welcome! Hmm, I suppose one could try running the signals through analog video delay lines, something like the EL9115 or an ISL5992x. At least that's what I'd try, I've never done something like this though, so maybe there's a better option - any other suggestions @all? At this point it'd probably be better to open a dedicated thread for it though.

Those chips don't have packages one can easily solder wires to or work with on a breadboard, so a QFN-20 to DIP adapter (e.g.) may help with testing (didn't find an existing project offhand).

Thank you again for the advice, I should probably create a new thread to discuss this.