Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Hdmi output via Raspberry Pi.

Reply to topic
Author Message
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Hdmi output via Raspberry Pi.
Post Posted: Sun Sep 19, 2021 10:11 am
Last edited by wasup on Sun Sep 19, 2021 11:00 am; edited 1 time in total
Has anyone come across this interesting project and looked into?

https://github.com/hoglet67/RGBtoHDMI/wiki
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sun Sep 19, 2021 10:28 am
I guess it is likely to introduce some latency to the signal, which is a big deal for certain games.

Edit: it seems not bad: https://github.com/hoglet67/RGBtoHDMI/wiki/Lag-Measurement
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Post Posted: Sun Sep 19, 2021 11:04 am
Maxim wrote
I guess it is likely to introduce some latency to the signal, which is a big deal for certain games.

Edit: it seems not bad: https://github.com/hoglet67/RGBtoHDMI/wiki/Lag-Measurement


I guess potentially the display/tv its plugged into could do some sort of processing and add extra delay too.

I thought it was an interesting approach anyway.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sun Sep 19, 2021 12:28 pm
It seems more like the CPLD is doing the critical conversion work but the RPi is doing the more softwarey work of changing the timings correctly. One other thing that often plagues these conveyers is speed to adjust to display mode changes, especially things like Mega Drive switching between 256 and 320 wide mode, or later systems switching between 240p and 480i modes. TVs can handle this with no issue but a scaler has to reconfigure and sync itself.

Most TVs now have a game mode where they minimise lag between the signal and the display, but it’s fundamentally impossible to be zero, whereas CRTs literally light up the phosphor exactly as the pixels are emitted by the video chip. For some games this makes a big difference. Emulators suffer the same, or worse, lag problem in most cases.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Nov 2015
  • Posts: 143
Reply with quote
Post Posted: Sun Sep 19, 2021 12:39 pm
Maxim wrote
It seems more like the CPLD is doing the critical conversion work but the RPi is doing the more softwarey work of changing the timings correctly. One other thing that often plagues these conveyers is speed to adjust to display mode changes, especially things like Mega Drive switching between 256 and 320 wide mode, or later systems switching between 240p and 480i modes. TVs can handle this with no issue but a scaler has to reconfigure and sync itself.

Most TVs now have a game mode where they minimise lag between the signal and the display, but it’s fundamentally impossible to be zero, whereas CRTs literally light up the phosphor exactly as the pixels are emitted by the video chip. For some games this makes a big difference. Emulators suffer the same, or worse, lag problem in most cases.

Maxim did you notice the same in new hardware such as MiSTer or similar ?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sun Sep 19, 2021 6:25 pm
The same as in outputting HDMI or as in doing time travel emulation?
  View user's profile Send private message Visit poster's website
  • Joined: 25 Nov 2015
  • Posts: 143
Reply with quote
Post Posted: Sun Sep 19, 2021 8:15 pm
Maxim wrote
The same as in outputting HDMI or as in doing time travel emulation?

I mean about lags.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Sep 20, 2021 8:19 am
I’m sure there’s some tests out there. RetroRGB has some good videos on the subject and via his site I found this for MiSTer: https://rpubs.com/misteraddons/inputlatency
  View user's profile Send private message Visit poster's website
  • Joined: 25 Nov 2015
  • Posts: 143
Reply with quote
Post Posted: Mon Sep 20, 2021 9:23 am
Maxim wrote
I’m sure there’s some tests out there. RetroRGB has some good videos on the subject and via his site I found this for MiSTer: https://rpubs.com/misteraddons/inputlatency

Thank you. I suppose original hardware latency is 0... or not ?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Sep 20, 2021 10:16 am
Almost games have a loop in this form:

Check inputs
Update game state
Update screen
Update sound

The screen update part is usually done in the VBlank (between frames being sent to the TV). However many games run at less than 60fps so the time from pressing a controller input to seeing it on the screen could be less than a frame (see results in the next frame) or several frames (if the game is slow). However you should never see frames after you press a button that don’t reflect your button press.

In terms of the latency between the video chip outputting voltages to say “this pixel should be white” and the electron gun in the CRT powering up and lighting the phosphor in white - that will be almost zero. However, if you plug into a TV you will see more significant delay on getting the signal there. Timing sensitive games in the HDMI era have had to add calibration screens to allow them to compensate for this (while also becoming unable to have super responsive gameplay - if the game has to check for the button compared to the game state from 200ms ago then it has to wait 200ms before showing the result). My TV in game mode shows 20ms lag on a component input, which is less noticeable.

So, there are multiple views on latency and ultimately time from button press to visible screen update is the whole chain. The game is responsible for part of it, but video signal conversion definitely adds to it.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Nov 2015
  • Posts: 143
Reply with quote
Post Posted: Mon Sep 20, 2021 11:12 am
Maxim wrote
Almost games have a loop in this form:

Check inputs
Update game state
Update screen
Update sound

The screen update part is usually done in the VBlank (between frames being sent to the TV). However many games run at less than 60fps so the time from pressing a controller input to seeing it on the screen could be less than a frame (see results in the next frame) or several frames (if the game is slow). However you should never see frames after you press a button that don’t reflect your button press.

In terms of the latency between the video chip outputting voltages to say “this pixel should be white” and the electron gun in the CRT powering up and lighting the phosphor in white - that will be almost zero. However, if you plug into a TV you will see more significant delay on getting the signal there. Timing sensitive games in the HDMI era have had to add calibration screens to allow them to compensate for this (while also becoming unable to have super responsive gameplay - if the game has to check for the button compared to the game state from 200ms ago then it has to wait 200ms before showing the result). My TV in game mode shows 20ms lag on a component input, which is less noticeable.

So, there are multiple views on latency and ultimately time from button press to visible screen update is the whole chain. The game is responsible for part of it, but video signal conversion definitely adds to it.


Thank you very much for the detailed answer! I still prefere real hardware on fpga-emulated stuff :)
  View user's profile Send private message
  • Joined: 27 Jun 2020
  • Posts: 212
Reply with quote
Post Posted: Wed Sep 22, 2021 1:34 pm
https://github.com/ramapcsx2/gbs-control

There's this as well.

It's by the guy who took over PSNEE and made the Xstation which is an optical drive emulator using a simple friggin ESP32!

I'm a recommended installer (tee hee hee)

Recently grabbed one to make for fun, already have OSSC. Retrotink 5x is like 500 bucks by the time it gets to Australia.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!