Spoiler
Spoiler
Any thoughts?
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?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!
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.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.
Visually the 480p solution it comes with is generally fine, but there is going to be a frame of delay.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?
Yes, that's what I mean.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.
Okay. Thanks.Visually the 480p solution it comes with is generally fine, but there is going to be a frame of delay.