Raspberry Pi w/ Sony HiScan

The place for all discussion on gaming hardware
Post Reply
User avatar
vol.2
Posts: 2435
Joined: Mon Oct 31, 2016 3:13 pm
Location: bmore

Raspberry Pi w/ Sony HiScan

Post by vol.2 »

I know these sets get lots of hate from the retrogaming community, but I finally found a perfect use case scenario for my 4:3 Sony HiScan. Going into the DVI port on the back at 480p from the Pi gives a really clean progressive scan image. I haven't tried any scanline stuff yet, but VGA PC titles are fantastic. Here's a couple of shots I took of Dark Forces (I'm not an expert in CRT photos)
Spoiler
Image
Spoiler
Image
Anyways, it's difficult to get it across with a photo, but it looks really good. I think they would make great arcade-setup CRTs, and they can had cheap. I got mine for $30 off Craigslist.

Any thoughts?
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Raspberry Pi w/ Sony HiScan

Post by mikejmoffitt »

From your image, I can see that the lines of the source 240p image aren't being perfectly 2:1 doubled, so there are some ugly transitional pixels that are losing their precision. However, that sounds like a raspberry pi problem.

I can not speak for your exact model, but I had a Sony 4:3 HD CRT a few years ago. It had a DVI port as well. I'm going to guess your set supports 1080i, 720p, and 480p (and I guess 480i and 240p through an internal scaler)? I think the model was HS-510.

In short, the "DVI" input on these is a bit goofy. First and foremost, that DVI port does nothing but strap a DAC on that emits component video, which then goes to the same switching matrix as the other component video inputs. With that out of the way, we can address how the different resolutions are supported.

In my set, I discovered the hard way that the CRT only ever natively scans at one rate, which is the rate for 1080i or 540p. It never switches syncs! In order to accomplish other modes, some silly things are done:

1080i: This runs natively, no need for scaling. Just the usual interlacing by starting the vertical retrace mid-line.

720p: Rather ugly scaling, then physically the same scanning as 1080i.

480p: This is the stupid one.

The CRT scans physically at the same horizontal rate as 1080i, but without interlacing. It becomes effectively 540p.

After that, the vertical size is increased, such that active lines are overscanned!

The 480p input (be it component, DVI, or the output from the scaler for 240p/480i) is digitized, and rendered to an internal framebuffer. It is double buffered, and usually locked with Vsync. There are exceptions. Expect 1-2f of lag.

The 480p image is centered in a 540p framebuffer, and the vertical stretch brings it back to the correct scan size for the centered 480p image.

The end effect is 1-2f lag for any of the cases where one would care about it, and the usual caveats from digitization of an analog signal. However, it is a pretty good digitization from my experience.
Image
User avatar
vol.2
Posts: 2435
Joined: Mon Oct 31, 2016 3:13 pm
Location: bmore

Re: Raspberry Pi w/ Sony HiScan

Post by vol.2 »

mikejmoffitt wrote:From your image, I can see that the lines of the source 240p image aren't being perfectly 2:1 doubled, so there are some ugly transitional pixels that are losing their precision. However, that sounds like a raspberry pi problem.

In my set, I discovered the hard way that the CRT only ever natively scans at one rate, which is the rate for 1080i or 540p. It never switches syncs! In order to accomplish other modes, some silly things are done:

1080i: This runs natively, no need for scaling. Just the usual interlacing by starting the vertical retrace mid-line.

720p: Rather ugly scaling, then physically the same scanning as 1080i.

480p: This is the stupid one.

The CRT scans physically at the same horizontal rate as 1080i, but without interlacing. It becomes effectively 540p.

After that, the vertical size is increased, such that active lines are overscanned!
edit: mike, I just read like a whole tome worth of HiScan threads from the early 2000s and found out that the 540p-480p transition and the DRC are completely separate in those sets. bypassing the DRC circuit in the service menu prevents the ADC-DAC-ADC processing (and lag) for anything at the native scan rate. In any case, the vertical compression from 540p should be transparent to the viewing experience as it's just an overscan adjustment. do you really think it makes a difference, or is it just crt-masterclass propaganda?

Also, apparently, you can send 480p resolutions to the set with 540p timings and it entirely bypasses the DRC and plops the image right in the center. It works because the DRC bypass in the service menu turns off the processing for anything that scans at 33kHz.
User avatar
mikejmoffitt
Posts: 629
Joined: Fri Jan 08, 2016 7:26 am
Location: Tokyo, Japan

Re: Raspberry Pi w/ Sony HiScan

Post by mikejmoffitt »

vol.2 wrote: edit: mike, I just read like a whole tome worth of HiScan threads from the early 2000s and found out that the 540p-480p transition and the DRC are completely separate in those sets. bypassing the DRC circuit in the service menu prevents the ADC-DAC-ADC processing (and lag) for anything at the native scan rate.

Also, apparently, you can send 480p resolutions to the set with 540p timings and it entirely bypasses the DRC and plops the image right in the center. It works because the DRC bypass in the service menu turns off the processing for anything that scans at 33kHz.
Perhaps you can bypass it for native scan rate things, but 480p content is not native scan rate. Visually, it should do okay at 1080i and 540p, but at 480p it must go through an ADC in order to be drawn on that framebuffer. Doing anything else would be tantamount to time travel.

By "480p resolutions to the set with 540p timings", do you mean performing the generation and centering of 480p content within a 540p frame on your source device (e.g. raspberry pi)? If so, that is probably okay. Asking the TV to do it for you implies the use of sampling and a buffer.
vol.2 wrote:In any case, the vertical compression from 540p should be transparent to the viewing experience as it's just an overscan adjustment. do you really think it makes a difference, or is it just crt-masterclass propaganda?
Visually the 480p solution it comes with is generally fine, but there is going to be a frame of delay.
Image
User avatar
vol.2
Posts: 2435
Joined: Mon Oct 31, 2016 3:13 pm
Location: bmore

Re: Raspberry Pi w/ Sony HiScan

Post by vol.2 »

mikejmoffitt wrote: By "480p resolutions to the set with 540p timings", do you mean performing the generation and centering of 480p content within a 540p frame on your source device (e.g. raspberry pi)? If so, that is probably okay.
Yes, that's what I mean.
One must increase the blanking intervals to get it in the center of the screen, and do so on the source. Normally, when 540p/1080i signal is input, it gets passed into the DRC to be "cleaned up." There is a service option which turns off this "extra" processing of the native resolutions. The fact that 540p works is not by design, it's an unintended effect of the way the set bins resolutions "to be processed" by lumping them into horizontal scanning rates.

I'm not sure if this works for 480i stuff. I'm going to hunt around a bit to see if it's plausible. I think it would entail discovering a way to turn off the automatic vertical compression for 1080i material.
Visually the 480p solution it comes with is generally fine, but there is going to be a frame of delay.
Okay. Thanks. :)

btw, what's you avatar from?
Post Reply