-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
How does the upscaling work for the Apple TV Tuner Card?
- Thread starter noglin
- Start date
zigzagjoe
Well-known member
Are these ASIC datasheets collected anywhere online?
NJRoadFan/Arbee great! "6100/7100/7100 AV cards, using Quadra 660/840AV video circuitry + PPC to '040 bus translator'"
What video circuitry did this have? Did it include the DSP that the Quadra had? (found some info on that chip, attaching). I suppose the NuBus X100 AV machines could view upscaled video (at 640x480), did the DSP do it perhaps?
Arbee: amazing document. Where/how do you find these? The "page mode" and "double buffer" is great, one could also use the quickdraw acceleration with a tweaked rowbytes to get an interlaced mode (640x240 -> 640x480 interlaced) . So this is for the 7200/8200, right?
Arbee: would you have any such detailed information on the 52XX/62XX machines? I already have Valkyrie upscale/page-flip working, but one thing that bothers me is that the current back video buffer is in cache write-through/or inhibited mode, so clearing cannot be done with dcbz, and compositing (read current pixel value to e.g. do transparency) costs a trip to ram. If it was possible to change the caching mode on the video buffer that is currently the back buffer, that would help a lot. I am not sure if MacOS sets it to cache write-through just because it is vram, or if it is limitation of some sort by design? If it is only MacOS doing it, then somehow getting supervisor mode and changing it would help performance. Perhaps there is some way one could get supervisor mode?
What video circuitry did this have? Did it include the DSP that the Quadra had? (found some info on that chip, attaching). I suppose the NuBus X100 AV machines could view upscaled video (at 640x480), did the DSP do it perhaps?
Arbee: amazing document. Where/how do you find these? The "page mode" and "double buffer" is great, one could also use the quickdraw acceleration with a tweaked rowbytes to get an interlaced mode (640x240 -> 640x480 interlaced) . So this is for the 7200/8200, right?
Arbee: would you have any such detailed information on the 52XX/62XX machines? I already have Valkyrie upscale/page-flip working, but one thing that bothers me is that the current back video buffer is in cache write-through/or inhibited mode, so clearing cannot be done with dcbz, and compositing (read current pixel value to e.g. do transparency) costs a trip to ram. If it was possible to change the caching mode on the video buffer that is currently the back buffer, that would help a lot. I am not sure if MacOS sets it to cache write-through just because it is vram, or if it is limitation of some sort by design? If it is only MacOS doing it, then somehow getting supervisor mode and changing it would help performance. Perhaps there is some way one could get supervisor mode?
zefrenchtoon
Well-known member
These documents are archived on archive.org. You have to use the right keywords to find them. 
But all of them are not there.
But all of them are not there.
The x100 AV does not include the DSP, but it does have the Civic video chip, Singer audio chip, and the Phillips audio and video encoders and decoders.
I have no info on the original Valkyrie or the 52XX/62XX (or 580/630) machines in general. I reverse-engineered Valkyrie and the ATA interface to make the 580 and 630 run in MAME, and this thread actually has given me some more info about Valkyrie. Bungie obviously had an ERS or something similar back in the day, but I'm sure nobody there knows what a Quadra is anymore.
I have no info on the original Valkyrie or the 52XX/62XX (or 580/630) machines in general. I reverse-engineered Valkyrie and the ATA interface to make the 580 and 630 run in MAME, and this thread actually has given me some more info about Valkyrie. Bungie obviously had an ERS or something similar back in the day, but I'm sure nobody there knows what a Quadra is anymore.
Trash80toHP_Mini
NIGHT STALKER
My observations back in the day would indicate that everything takes place on the Video Card itself.The Apple TV Tuner Card is 320x240 and it up-scales to 640x480 (in hardware, I'm quite sure). Perhaps there is someone hardcore here that has some insights how that works?
A while ago, I tried to systematically write to all locations in VRAM (1MB, I could not reach the very first 32 bytes if I recall correctly but the rest I could write) while I had the Apple Video Application running, I had kind of hoped I would miraclously see that I could overwrite the video signal and get free 2x scaling
Very curious if anyone has some insights on how the Apple TV Tuner Card gets its data to the screen upscaled.
I tried to do a screenshot of a composite signal and wound up with a blank window. Therefore Video output never hits VRAM on the MoBo.
This lead me to believe the Mac side software does the window mechanics only.
If it's using a key color to selectively show video pixels, then those pixels must remain as the key color. So video output doesn't write to VRAM but something needs to read the VRAM to check for key color pixels. That something could be the same thing as the rasterizer that outputs pixels to the display so that the VRAM doesn't need to be read by something else? The pixels being sent to the display could be substituted at that time.
Video on Power Mac 8500/8600 uses DMA to VRAM and another DMA channel for clipping mask.
So I actually have a quite deep understanding of this now. Thanks to the references and comments in here. I'll share it and hopefully it will help others that might be curious and need a summary rather than the code/technical references:
The video card takes the analog signal and converts it to digital YUV format (so not RGB, the advantage is that this has a better perceptual encoding of the video signal, as we are more sensitive to luminance than to different colors). It will write data to VRAM at 320x240 in 16bpp (but not in RGB, it will write in YUV).
That's pretty much what the video card does.
The actual upscaling and converstion from digital YUV pixels to signals to the monitor is performed by the Valkyrie chip and RAMDAC (which is on the motherboard regardless if you have a video card or not).
The Valkyrie chip needs ~1MB vram to accomplish this upscaling to 640x480. This is how it does it:
- it has a main buffer of 640x480x8 (256 colours), this is where MacOS draws to. One specific color of these is used as a special color for video to be "seen through".
- it has two back buffers of 320x240x16 (can be either RGB or YUV, but when the TV tuner is used it is set to YUV format)
The video card will send data to one of these back buffers.
The Valkyrie chip, to send out signals to the monitor will accomplish the following:
- at the current pixel location, it will check the main buffer (640x480x8), if that pixel is a "see through" pixel, it will read the corresponding pixel in the currently active back-buffer (320x240x16) and output it twice (2x scale) and convert it to RGB, otherwise it will just use the pixel it read from the main buffer, and then this gets sent to RAMDAC which will convert the RGB to an analogue signal for the CRT
Why it is "only 30 FPS" though I am not sure, probably a "limitation" of the video card, as I can get higher than that when I draw myself to the 320x240 buffers and page flip.
Either a limitation of the TV card, or something they just decided as more than 30 would probably be overkill as movies/TV:s are typically 24fps)
This can't work without a buffer to store the pixels that will substitute the key color since the display and the video input won't have the same pixel clock or refresh rate.
I presume the following is what happens:
- video card writes to the back-buffer (a)
- system software gets a hint that the video card is done and tells Valkyrie to change current back buffer (from a to b)
- video card starts write to back buffer (b)
whatever is in the completed buffer is what Valkyrie is using during scan-out of pixels
The timing differences you mentioned could explain why the video is at most 30 fps.
NTSC is interlaced: Frames are input at 30Hz. Each frame consists of two fields - one for odd lines and another for even lines. The fields are input at 60Hz. Each field is temporally separate (16 ms) and spatially offset (1 scanline) which lead to interlaced artifacts.
Power Mac 8500/8500 has a few options for video input:
- capture both fields at full resolution. You may see interlaced artifacts (combing).
- capture both fields into separate frames. This is a 60Hz mode with either half the full resolution (if you capture all the horizontal pixels) or a quarter of the full resolution (if you capture only half the horizontal pixels to maintain aspect ratio). This mode may have flickering.
- capture one field. This is a 30Hz mode with either half the full resolution (if you capture all the horizontal pixels) or a quarter of the full resolution (if you capture only half the horizontal pixels to maintain aspect ratio). This mode won't have flickering or combing. This is probably the mode that Valkyrie uses.
Arbitrary scaling is supported by skipping scan lines - just DMA them to a through-away region if necessary. You can choose to capture the vertical blanking area or throw it away. The vertical blanking area has the closed captioning (teletext or EIA-608, etc.) EIA-608 is only 2 bytes per frame.
I suppose one could use a convolving technique to mix info from both fields (comb filter?). I think video output from Power Mac 8500/8600 had a convolving mode but not sure about video input.
That's interesting! I had not researched this aspect very much as my main goal was to figure out if I could use the Valkyrie for upscaling what I am drawing in a 320x240x16.
That makes sense. Although I don't recall feeling it was "less resolution" on e.g. SNES plugged into my 5200 vs SNES plugged into a CRT. It is very late here in Spain but tomorrow I think I will have to hook it up and try
The Valkyrie chip isn't drawing the output from the TV tuner card at all. The video is being painted onto the Valkyrie's display by a nifty overlay function. Think of it as two screens, the Valkyrie frame buffer with your desktop, and a black screen with just the video output, perfectly sized to match the window on the video player. The video display is mixed with the Valkyrie output and sent to the RAMDAC. Its how countless ISA TV tuner and MPEG decoder cards worked and gets around the bandwidth limitations inherit in early computer systems.
This is why taking a Cmd-Shift-3 screenshot of the video never works. You get a black box (or pink which is a common key color on Windows) in your saved screen shot where the video appears on the screen. You can even see this in action you you drag the video window to another place on the screen. For a split second, the video is still in the old location before it starts drawing at the new location. Most TV tuner viewers have a dedicated snapshot function if you want to save a frame of video to disk.
This is why taking a Cmd-Shift-3 screenshot of the video never works. You get a black box (or pink which is a common key color on Windows) in your saved screen shot where the video appears on the screen. You can even see this in action you you drag the video window to another place on the screen. For a split second, the video is still in the old location before it starts drawing at the new location. Most TV tuner viewers have a dedicated snapshot function if you want to save a frame of video to disk.
Where does that overlay function reside if not on the Valkyrie chip?
Attachments
Trash80toHP_Mini
NIGHT STALKER
IIRC, that makes all the sense in the world. Video screenshot was how I was able to cut and paste VidCap window contents into the blank window of the CMD-Shift-3 VRAM screenshot.
I was playing games on the Laser128, feeding its output thru the VidCap card driving the Radius TPD of my main workstation. This was back in the Snitz days of the early 68KMLA and wanted to post a pic of it here.
Great discussion, gang!
Read the description in the LC 630 tech note on Page 8 (PDF page 22). Also:
The overlay function mixes the output of the video data frame buffer and the graphics data at the output stage (RAMDAC). They never share memory or otherwise interact with each other. A 68040 based machine can't handle capturing uncompressed full motion video (even at 320x240) over the bus. You need a fairly fast PowerPC machine with a modern bus (PCI, or its native processor bus).
NJRoadfan,
We are probably saying more or less the same thing.
"mixes the output of the video data frame buffer and the graphics data at the output stage"
Yes. Although I say this is happening on the Valkyrie chip. I might be wrong, but I don't think so.
Here is why I believe it is happening on the Valkyrie chip itself:
- valkyrie has a register that stores the 8-bit value used for mixing (i.e. if a screen pixel matches this 8-bit value, then in this output stage, the source will be the current video buffer, otherwise the screen buffer)
- valkyrie has a control register that decides which video buffer is active, and if that video buffer should be filled from the video card or not
- valkryie's control register also has a flag one can set to get 2x output (which would also happen conveniently at this output stage, just output two of the same signals from the video buffer from the appropriate row
- valkyrie has a mode that sets the two video buffers either in RGB mode or in YUV mode. And Apple's documentation says they treat the video input in YUV.
Now, if this output stage did not happen within the Valkyrie chip, it means this output stage would have to be deeply connected to the Valkyrie cheap (fast access to its registers, read VRAM (screen, and the currently active video buffer, etc). It is possible, but I think it is more plausible all this is within the Valkyrie chip.
Further proofs:
- when I start Apple Video Player, and I print out continously the value of Valkyrie's vide mode, I can see that the current video buffer alternates between the two.
- I can also see (I wrote a small program) that if I initiate the two video buffers to all zero, and then start the video buffer and then sum up the values, they are non-zero => the video is being written, alternating between these two buffers.
I can also explain the "screenshots do not show the video", this is because MacOS is copying the *screen* framebuffer, and the screen pixels where video is displayed are set to that special value that causes the output stage to select video. You can try this: take a screenshot, open that picture and then drag that window so it covers the Apple Video Player, now magically you will see the video playing right through on the Screenshot.
And, you *can* capture the actual video (Apple Video Player -> Show Controls Window, click the oldskool Camera and then "Capture Picture" Freeze or Save). This will naturally copy the video buffer content (which is also in vram).
If something above is incorrect, would love to hear it. And I should add, that all my experiments are on a 5200 (and should be the same on a 6XX series as it has the same Valkyrie chip).
Actually just got an interesting hack to work, I am now able to modify the displayed video, I modify half the window.
I'm posting it here, but it is *unstable* (I'm abusing Valkyrie) and for me it crashes my mac 3 out of 4 times, use at your own risk (open Apple Video Player, and then run it).
Also attaching a video recording in case you (understandably) do not want to run it
Early computers and gaming consoles would just output the same image in the odd and even field of an interlaced frame, so their vertical resolution is half the resolution of the frame.That's interesting! I had not researched this aspect very much as my main goal was to figure out if I could use the Valkyrie for upscaling what I am drawing in a 320x240x16.
That makes sense. Although I don't recall feeling it was "less resolution" on e.g. SNES plugged into my 5200 vs SNES plugged into a CRT. It is very late here in Spain but tomorrow I think I will have to hook it up and try
I'm not sure if it was always the exact same image. It would be if the image wasn't moving. If the fields are drawing at 60 fps, then you could have interlaced artifacts for moving objects. The only way you wouldn't get artifacts is if there was some kind of buffering or if one of the fields was not being drawn (always black) which may be the case with some of the systems.
Apple II: 280x192 or 560x192
Commodore 64: 320x200
Atari 2600: 160x192
ColecoVision: 256x192
NES: 256×240
SNES: 256x224
etc.
Similar threads
