3 ms·

> That means that variations in colour and sound were not used when recording data. That sounds like a massive waste of space, no? Wouldn't at least using RGB

> That means that variations in colour and sound were not used when recording data. That sounds like a massive waste of space, no? Wouldn't at least using RGB and within that only using three luminosity levels essentially dramatically increased the capacity with little increase in error rate which could have been addressed with a level of redundancy?

dfox 3y ago
VHS stores the chrominance information heavily subsampled (even more than normal analog composite video) and the chroma signal noticeably bleeds into the luminance signal as the chroma carrier has lower frequency than in normal broadcast signal. So, using the chroma signal is not really worth the complication. Doing something multilevel PAM purely in the luminance signal is probably better approach, but one has to take into account that the overall level of the video signal tends to get "averaged-out" by various ALC circuits in the VCR. Also the cards appears to be largely software driven (it is too simple to do any real HW acceleration), so the main limitation of the bitrate probably is the performance of CPUs at that time.
- orbital-decay 3y ago
  >the cards appears to be largely software driven (it is too simple to do any real HW acceleration) Both redundancy encoding and DMA were hardware-accelerated by an onboard FPGA (although DMA had lots of motherboard compatibility issues)
  - dfox 3y ago
    I meant the 1020 card with discrete TTL. Although there is that EPROM, which is apparently used in the datapath somehow (some kind of LUT for encoding/decoding?). Interesting aspect of the card is that it seems to be purely interrupt and DMA driven, as it has entire address bus left unconnected. I suspect that there is some clever abuse of i8237 DMA controller involved, which would explain the compatibility issues.
    - nnevod 3y ago
      EPROM stored codes for controlling video recorder - the card has IR receiver and blaster, you record t-e codes from remote voa receiver, then the card controls the recorder.
      - dfox 3y ago
        It is an EPROM (apparently 8x8KB 2764 in particular), EPROMs are not really intended to be in system (re-)programmed, so storing the IR codes in it does not really make sense. Proximity of pair of ALS193 to that EPROM makes me thing that it contains data for some kind of fixed pattern (by rough approximation the 64kbits work out quite neatly to the horizontal resolution of the "Arvid 1020" text on the spacer pattern shown in the article). [Edit: alternatively it is possible that the EPROM contains some kind of "microcode" that serves as sequencer for rest of the circuitry, which is probably more likely] Another interesting things are the 4 wide DIPs at the bottom edge of the card, these are clones of AM29705, which is 16x4bit dual port SRAM, apparently this serves as some kind of minimal buffer between whatever the rest of the card is doing and the DMA activity. As there is no IO except DMA I suspect that the card continually samples input and produces output, probably with the IR input and output being interleaved into the "video" data in some way (as one of the 16 bits?).
actionfromafar 3y ago
Composite video encoding uses most space for the luma, i.e. the black and white portion of the image. So, to answer the question, it's a waste of space, but not a massive waste of space. Edit: what dfox said.

dfox 3y ago

VHS stores the chrominance information heavily subsampled (even more than normal analog composite video) and the chroma signal noticeably bleeds into the luminance signal as the chroma carrier has lower frequency than in normal broadcast signal. So, using the chroma signal is not really worth the complication. Doing something multilevel PAM purely in the luminance signal is probably better approach, but one has to take into account that the overall level of the video signal tends to get "averaged-out" by various ALC circuits in the VCR. Also the cards appears to be largely software driven (it is too simple to do any real HW acceleration), so the main limitation of the bitrate probably is the performance of CPUs at that time.

orbital-decay 3y ago
>the cards appears to be largely software driven (it is too simple to do any real HW acceleration) Both redundancy encoding and DMA were hardware-accelerated by an onboard FPGA (although DMA had lots of motherboard compatibility issues)
- dfox 3y ago
  I meant the 1020 card with discrete TTL. Although there is that EPROM, which is apparently used in the datapath somehow (some kind of LUT for encoding/decoding?). Interesting aspect of the card is that it seems to be purely interrupt and DMA driven, as it has entire address bus left unconnected. I suspect that there is some clever abuse of i8237 DMA controller involved, which would explain the compatibility issues.
  - nnevod 3y ago
    EPROM stored codes for controlling video recorder - the card has IR receiver and blaster, you record t-e codes from remote voa receiver, then the card controls the recorder.
    - dfox 3y ago
      It is an EPROM (apparently 8x8KB 2764 in particular), EPROMs are not really intended to be in system (re-)programmed, so storing the IR codes in it does not really make sense. Proximity of pair of ALS193 to that EPROM makes me thing that it contains data for some kind of fixed pattern (by rough approximation the 64kbits work out quite neatly to the horizontal resolution of the "Arvid 1020" text on the spacer pattern shown in the article). [Edit: alternatively it is possible that the EPROM contains some kind of "microcode" that serves as sequencer for rest of the circuitry, which is probably more likely] Another interesting things are the 4 wide DIPs at the bottom edge of the card, these are clones of AM29705, which is 16x4bit dual port SRAM, apparently this serves as some kind of minimal buffer between whatever the rest of the card is doing and the DMA activity. As there is no IO except DMA I suspect that the card continually samples input and produces output, probably with the IR input and output being interleaved into the "video" data in some way (as one of the 16 bits?).

actionfromafar 3y ago

Composite video encoding uses most space for the luma, i.e. the black and white portion of the image. So, to answer the question, it's a waste of space, but not a massive waste of space. Edit: what dfox said.