Re: Open hardware AV to digital conversion

From: silverdr_at_wfmh.org.pl
Date: Sat, 10 Jan 2015 00:46:35 +0100
Message-ID: <54B0685B.9020302@wfmh.org.pl>
On 2015-01-08 22:40, Ingo Korb wrote:

>> That's the problem. The first stage I want to do is to keep the 64 being
>> a 64, meaning it can still be connected to whatever it was before,
>> /plus/ those to which it couldn't over the same pins/cables.
>
> I do not think this is a reasonable constraint. S-Video is already quite
> far on its way out, composite seems to be following (see below) and I
> refuse to consider analog RF. While composite is still an option for
> now, it's not the best quality you can get from the C64. Once
> again... Why settle for something okay-ish when you have the chance to
> build something great?

That's where our definitions differ a bit. I very much prefer the 
"great" thing, rather than "another, more or less okay-ish". S-video is 
the best what you get from the VIC-II. You don't get a better signal 
from it. No component, no RGB, no SDI, ... This means you don't jump 
over its limits. You can make it still slightly better by filtering out 
things, which are not inherent limitations of the s-video or PAL/NTSC 
norms. That's what I want first. Then I digitise and filter/quantise it 
in the digital domain. At this stage I should have the signal, which is 
best possible at all. From there I envisoned two paths. First I go DAC 
(which is relatively easy and inexpensive to do well) and give the 
cleanest possible s-video and composite out, presuming that whatever is 
connected to the other end, will do a good job further processing it and 
displaying. This keeps the compatibility with everything that worked 
before but buys us some time by removing excuses of non-standard signal. 
Then the second path is not to trust the devices but to go further 
digital and decode the s-video into best possible RGB, suitable for 
streaming out via DVI/HDMI ourselves. This (decoding) seems 
substantially more difficult to me now and will take more time to do it 
right.

> If you just keep the existing signals without modifications on the
> existing outputs and add a new one you gain the flexibility to choose
> output video formats without being constrained to SD and without being
> limited to the lowest common connector.

The new one has to be digital, the old one is to be kept for 
compatibility and - frankly - those machines' feeling is still 
unbeatable on a good CRT. I prefer hi-res broadcast studio displays but 
even a well preserved 1084 will give better "feel" of the picture than 
upscaled, lagged, artefacted one on a typical flat panel. Provided it 
shows something at all in the first place.

>> I do, because I want it to remain 100% compatible with what was there
>> before.
>
> If it worked before, it can just continue working by not modifying the
> signals that it used before.

Except that I want to make it much cleaner.

> [...] I didn't expect that you would even consider outputting composite or
> S-Video signals though because the AD video decoder chip that was
> mentioned previously included color decoding, so its output would be RGB
> or possibly YCbCr. What is your plan to turn that back into the
> S-Video-like signals the VIC outputs?

That's the misunderstanding. We discussed at Marko's place how to 
digitise the signal and we both did some research later on. Marko 
eventually posted information on this chip, which possibly can do the 
job. But..

- we don't know if it will accept the signal (a kind of similar ones are 
probably in many devices, which don't work)

- it's a specialised ADC, which will sooner rather than later get phased out

- it already converts to different colour spaces - again: we know that 
even those devices that show something, often don't show the quality 
we'd be happy with. This is most probably the result of the work of this 
or similar chip inside them.

I wanted the design to use a generic approach so that full control over 
the process is possible and dependency on specialised hardware is 
eliminated. Meaning it either uses generic components like ADC, RAM, .. 
or implements those by itself inside an FPGA, so that the dependency on 
(potentially soon) obsolete, specialised elements is out of the equation.

>>> Which reminds me: How do you propose to shift the signal timing enough
>>> that you can add[1] half a line to change the timing from 240p to 480i?
>>
>> The same as the "regular" devices do.
>
> Yes, but... "regular" devices have a slightly different video timing. If
> I'm not mistaken the C64 outputs half a line less per frame, exactly
> that half line that is needed to signal an interlaced picture.

I want the solution to reconstruct the sync pulses itself but what you 
say has to be double-checked. If you say that I may run out of the 
VBLANK time to get the proper timing and remain in sync with the source 
then this would indeed pose a problem, solving which would make the 
whole thing more difficult. I think, however that this is not the case.

>> I count the fields and I delay each line (out of VBLANK area) as much
>> as is required for processing whenever I process/output odd fields and
>> I do the same plus properly timed half-line period for lines
>> constituting even fields. At a flip of a bit I skip the extra delay
>> for even fields.
>
> I think if you do that you end up with a signal where each of the two
> fields has a different number of lines.

Not really - the standard frame (both PAL and NTSC) has anyway an odd 
number of active lines so fields have to be defined as having xxx.5 
lines differing where they start and end. Timing-wise the first starts 
at the edge. The second in the middle. AFAIU it's only the timing that 
matters.

> Are you sure that such a signal
> is acceptable to modern TVs?

Well - that's the norm. I want to reconstruct the norm signal with 
digital accuracy so that those TVs/upscalers/adapters/etc. don't have 
any excuse for saying "no signal" or displaying garbage.

> I haven't tried something like that with
> interlaced signals yet, but when I accidentally generated a 480p signal
> where two consecutive frames were differing by one or two lines, I
> mostly saw the familiar "No Signal" message.

I guess it's understandable in such case as the signal must have seemed 
inconsistent to the receiver.

[...]

> You always have the option to make a cheaper external device. It would
> also increase your possible market size, thus increasing the number of
> units sold and reducing the cost of the parts if you can order them in
> larger batches.

As we all know - it's not what will make me or anyone here a good 
retirement ;-) So yes, cost is an important factor but what I envision 
is a combination of VIC riser and RF modulator replacement. This gives 
ample space for all processing stages I described. In the end I'd be 
happy to see an unbeatable quality signal on both the original DIN and 
an HDMI socket located more or less in the middle of the former RF 
modulator's length.


> Fun little idea on the side: Are "C64-incompatible" displays also
> usually incompatible with consoles like the SNES or Megadrive/Genesis?
> Those two also use a 240p/288p video mode in the majority of games, but
> if their signal is acceptable to a display while the one from the C64 is
> not, simpler approaches may be viable like regenerating just the sync
> pulses without modifying the video signal itself.

That was the very first idea I talked about with Gerrit - I wanted to 
reconstruct the sync pulses only but later on I thought that this 
approach, even if it worked, would be only a kind of workaround. Or 
using your terms Okay-ish in some cases only, leaving room for excuses 
in other.

>
> -i 'the constraints are getting weirder ;)' k
>
>         Message was sent through the cbm-hackers mailing list
>

-- 
SD!

       Message was sent through the cbm-hackers mailing list
Received on 2015-01-10 00:00:03

Archive generated by hypermail 2.2.0.