Re: Continue with SVHS/Composite?

there's some processing time with the xrgb no matter what even if it's only 1 frame if i'm correct on the mini

See http://retrogaming.hazard-city.de/framemeister.html

52 (edited by JimDrew 2016-04-13 16:23:51)

Re: Continue with SVHS/Composite?

Geez people, 1 or 2 frame is NOT noticeable.  A movie theater uses a 3:2 pull-down at 24fps.  That's 41.66ms per frame.   HDSDI video is under 30fps (33ms per frame).  So, we are talking less than 1/2 of that in latency for buffering the image at 60Hz with a single frame.

53 (edited by gouky 2016-04-13 16:43:47)

Re: Continue with SVHS/Composite?

It is, add that to the led/lcd response time...

You should talk with some hardcore retro nerd and die hard shmuper

Anyway, as long as it's an option there's nothing to be worried about :-P

Re: Continue with SVHS/Composite?

The lag is mostly in the TV - several frames usually. Personally, I don't think I would notice a frame.

Re: Continue with SVHS/Composite?

Any reason why we can't just use a line-buffer instead?

56 (edited by JimDrew 2016-04-13 20:56:05)

Re: Continue with SVHS/Composite?

Mike, that is very likely the issue.  I know that several TVs have triple buffering (especially the 240Hz versions).   At any rate, an option to have it (and not require its use) would certainly increase compatibility by being able to use industry standard DVI monitor frequencies no matter what the source frequency might be.  This would also give the ability be able to rotate the display, something that things like Pacman and other stand up arcade machines really need.  So, working this into the Replay's framework is the best place for this (probably).

Re: Continue with SVHS/Composite?

Chris,
I've been working on a line buffer - it seems the monitors are most sensitive to clocks per line being "wrong".
For this to work though, I need to calculate and lock the clocks such that the line rate matches (or use a few line stores).
This is what Wolfgang's VideoConverter does (used in Galaga), so we have the technology.

Now I have the RTG clock switching in place for the Amgia core, it should be possible to add.

Re: Continue with SVHS/Composite?

Yes remove composite and Svhs so old Skool. We can use this space for more useful things like say double header vert usb on board that would be much more useful. Possibly a vertical dvi and hdmi option in future if it fits. But yes, comp/svhs nice but long since past RIP.

59 (edited by JimDrew 2016-04-18 01:31:18)

Re: Continue with SVHS/Composite?

Well, let's put it like this... I am back ordered over 100 units with DVI/SVHS and only 13 that are DVI only.  On the waiting list (separate from web pages back order) with several hundred people is the same ratio So, the people in the U.S. are still using composite - it is making a huge comeback here.

Re: Continue with SVHS/Composite?

We'll keep it. HDMI cannot be used due to licensing issues with the connector, but you can connect the DVI socket to a HDMI input.

61

Re: Continue with SVHS/Composite?

The lag is mostly in the TV - several frames usually. Personally, I don't think I would notice a frame.

most half decent modern TVs have an extra "gaming" mode which removes the lag (down to the inevitable 1 frame) - and for a good reason. one frame vs 3 or 4 frames (typical delay with all filtering crap enabled) is very noticeable on fast paced games.

62

Re: Continue with SVHS/Composite?

MikeJ wrote:

Chris,
it seems the monitors are most sensitive to clocks per line being "wrong".


tldr;Back in the analog days, you could only use hfreq, vfreq, hsyncs pr vsync to quickly identify a source. There are probably leftovers of this in bad digital monitors. You could not measure clocks pr line.

We have been discussing this on a few occations, but maybe time to write something down. Maybe this post belongs to some other topic, but tbh, I have lesser overview.

I think the answer to this behaviour lies in the analogue [VGA] history. I have be involved in writing firmware to recognize VGA signals and map them to a digital device, and know the lazyness that was involved at the time. Back then we used tables preloaded with common modes, but also indexes in the same table to store special modes. When the digital interfaces appeared, it was common practice to just use the same software to recognize the signal either it was analog or later digital. A lot of the information was now there for free, but since both analog and digital were supported on the same platform, not much work were put into using the new digital-only parameters.

The first challenge with a VGA signal was to find its pixelrate. Since there was no direct pixelrate to find, we had to guess, then guess the active window. Also we needed to [try to] tune the phase of the sample, so the sample point ended on a stable [ideally flat] top of the pixel.

To guess the rate, the frequency of the syncs were measured. Also sync polarities, but not necessarily used for identification. Instead of vsync freq, you could also use the # of hsyncs pr vsync. The sample phase varied from time to time (temp,cables used) and were not easy to control.

The PLL setting (pixels pr hsync) was pretty much unique for the commonly used resolutions at the time, but there was always some deviation that needed special attention. I guess the cheapest monitors didn't care much about those.

For the known sync frequencies it was a LUT to lookup hstart,hres,vstart,vres,but with some margin of course. This was enough to get something visible, then you could add effort to fine tune.

For the digital ports that appeared later, the pixel rate and phase is already present, so we could skip this step, but the rest of the validation logic stayed, just because it was still valid with the common digital sources.

Re: Continue with SVHS/Composite?

It will be interesting to make a core with some odd pixel counts, but valid line/frame timing and see if the problem monitors still reject them. I think it will (as that's what I'm seeing with the Amiga core) - the sync timing is perfectly valid, just the pixel rate it a bit odd.