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 listReceived on 2015-01-10 00:00:03
Archive generated by hypermail 2.2.0.