The Hall SC-VGA-2 video processor, the Atari ST and NeXTSTEP: more tales of the unscreenshotable

A periodic fascination on this blog is figuring out better ways to get better screenshots of our classic systems, which often hail from the Wild Wild West/East in terms of video standards (read all entries in this series). Naturally the best way is a bitwise direct grab of the framebuffer, but that's only possible if there's sufficient operating system support. This support is obviously absent for things like boot messages (especially important when investigating NetWare on the Power Mac 6100), so we need to figure out a way to capture that information. My capture box of choice is currently an Inogeni VGA2USB3, which is small, self-contained, USB-powered, highly compatible and makes high quality grabs of anything you can wire into composite or a VGA HD-15 connector up to 1080p, but is limited to 60Hz refresh rates. Various solutions like the OSSC exist, but these are more oriented to arcades and consoles rather than (our primary interest) workstations, and the Pro in particular isn't cheap.

While you might be able to trick the hardware into emitting a compatible signal, that's not good enough or even possible with several of my machines. Previously my problem child was astro, my SAIC Galaxy 1100, a modified PA-RISC HP 9000/712 crammed into a MIL-SPEC portable case with a fabulous built-in flat panel. These machines ran HP-UX 10.10 in their original heyday, but this particular system runs NeXTSTEP 3.3 for PA-RISC during the brief period of time NeXT supported the architecture and was a big hit at the Vintage Computer Festival West a few years ago. Its flat panel runs at an odd 62Hz and the external VGA port only generates a 60Hz signal for 640x480 (all other resolutions use different refresh rates), which is hopeless for running NeXTSTEP. However, now I have a new candidate I'd like to get some grabs off: a particularly problematic member of the Atari ST family which has been the subject of a long-running and highly frustrating extended Refurb Weekend. You'll get to meet this bad girl soon enough. The standard ST high resolution mode is 640x400 — at 71.2Hz. I can get a picture from it with my trusty NEC flat panel, but not with the Inogeni.

The usual solution to this is a scan converter, but those can be expensive and inconvenient. Here's one I picked up used on eBay for $2. Yes, really. It cost more to ship it.

This is the Hall Research Technologies SC-VGA-2, sold as a "VGA/HDTV Video Processor." In addition to slicing, dicing and pureeing, apparently, it will take any of a bundle of input formats and both rescale and resample them on the fly into the VGA or HDTV signal you desire, including 60Hz rates. This came from a seller specializing in teleprompter equipment and Hall still sells an HDMI version with additional resolutions ... for around US$500. However, this or the slightly newer SC-VGA-2A and SC-VGA-2B are all relatively common devices and found substantially cheaper used. Let's try it out and show some sample output, including those delicious NeXTSTEP system messages and some ST grabs.

The reason I got the SC-VGA-2 so cheap, and I actually ordered two, was it was sold untested (no power supply). It looked like a robust device in a metal enclosure, so I figured it probably did work, but an extra $2 for a spare to hedge my bets seemed good insurance. Both of them do in fact work.

Input is a single VGA connector. Power is a regular 5.5mm barrel jack, 12 volt centre positive.

Output is also a single VGA connector, but instead of DIPs or other hard switches, it has an on-screen menu controlled with MENU, - and + buttons. Settings are stored in non-volatile RAM. A really nice feature is that if you accidentally put it into an incompatible output mode, holding down - and + together will force a reset to 60Hz 1024x768 (it calls this mode "XGA-60"). This saved my bacon a few times. There is a similar option with MENU and - for "480p" which is actually 720x480 at 60Hz.

Since it stores settings internally, I cracked it open to make sure there wasn't a leaky battery I had to worry about. Fortunately, there is none; it seems to store settings in flash. I strongly suspect this is actually a two-CPU system, though I didn't want to damage the machine by prying off the heat sink off the biggest QFP chip (I'll do that if it quits working). However, scraping off the label on the chip in the PLCC socket reveals a SyncMOS SM8958A, a member of our old friend the Intel 8051 family (we last met 8051s in the Data General/One and the ULI successor to the AtariLab). Technically this is an 8052-type microcontroller with 1K of on-chip RAM and 32K of on-chip flash for program memory, though it must also have some means of storing settings internally since there are no other obvious sources of NVRAM. This particular part is rated up to 40MHz, but the crystal next to it is 11.052MHz, which still sounds pretty quick until you recall MCS-51 chips take about 12 cycles per instruction (compare to a 6502 that ranges from two to six). It seems to drive the unknown video ASIC using its on-board serial port which was not an unusual mechanism for the time; see, for example, the Focus FS401LF.

The other, smaller chip near the input port is an MStar MST9883, which is an overgrown A/D converter sampling analogue pixel data and emitting a serial stream of digital RGB and clock for the video ASIC. It can sample up to 140MHz and doesn't appear to use the 14.31818MHz crystal next to it, which seems to be used by the ASIC.

I don't think Hall designed this board; it seems to be Taiwanese based on the board markings, chip manufacturers and some Engrish in the Hall manual which was clearly from an image grab of something else. Other vendors may produce an equivalent version of this device, so if you know of one, post it in the comments.

The reason I suspect this is a two-CPU system is the large amount of framebuffer RAM on the underside wired to the video ASIC. These are TMC TM50S116T-7G SDRAM chips, each having two 512Kword banks of 16-bit words (i.e., 2MB), so with three we have 6MB of working RAM. This can only be for the video ASIC since the SM8958A has no means to use it. Thus, the SM8958A handles the user interface and the ASIC handles the actual resampling and rescaling using the SDRAM as its buffer. Many of these video conversion ASICs have various embedded CPU cores.

When reassembling it don't forget to slide the non-conductive plastic sheet it sits on back under it, or it will short itself out with the case metal!

Our first stop will be the SAIC Galaxy 1100. We connect the SC-VGA-2 to its output, connect the Inogeni to the SC's output, and connect that to the Raptor Talos II over USB 3. All grabs were taken in VLC with Fedora Linux 41 and have not been post-processed. I forced the Galaxy to external video by pressing ESC for the boot menu, then path console graphics (graphics1 is the "alternate" on-board flat panel) and reset.

The system remains in 640x480 mode from before, shown directly connected to the Inogeni without the Hall box.

This choice comes from its boot menu list of resolutions, of which only mode 5 is the only 60Hz mode. To match the flat panel we'd really like one of the 1024x768 modes, offered at 70Hz or 75Hz. The Hall manual gives these input and output modes as supported:

I hooked up the SC-VGA-2 and tried 75Hz first (monitor 2). Despite being listed as supported, this caused a black screen, so I (blindly) reset the Galaxy and switched back to mode 5, and then tried mode 3.

This works!

And here we are at the boot menu in the larger resolution. Let's explore the SC-VGA-2's interface a little more before continuing.

The MENU button brings up the on-screen display. This is slow, but now that we've seen how the system works, we understand why: the SM8958A has no access to the framebuffer RAM, so it has to pass pixel data to the video ASIC over serial to overlay it.

SYSTEM INFO causes the machine to identify itself as a SC-VGA-2C. I don't know what this means and Hall doesn't mention it as a separate SKU. The input is "XGA-70" and the output is "XGA-60."

OUTPUT SETUP is where you select the output resolution and refresh rate.

My preference is to match actual resolution and captured resolution for as close to 1:1 pixel data as possible, but you can upscale as well as downscale. I couldn't make the SC-VGA-2 happy with the 1280x1024 75Hz mode the Galaxy can also generate, but it was happy to upscale 1024x768 70Hz to 1280x1024 60Hz. I should note that I don't know if the Galaxy video modes are standard, so I can't say if this is the Hall box's fault or not.

PICTURE ADJ. lets you change typical adjustments like colour, contrast and brightness. These are the factory defaults but it's possible to use these settings to, say, colourise monochrome output.

H V ADJUST controls positioning on screen. This is generally done for you but I needed to mess with this for good grabs of the Atari ST. More a little later.

Similarly, INPUT SETUP lets you control how many horizontal samples are taken per line (this seems to be based on a 32x multiplier to generate the 1024-pixel lines here), phase controls the sample timing, and H-ADV sets the horizontal advance in case the left edge is cut off and you need to start sampling earlier. You can also force YPbPr instead of RGB, though we'll be strictly using RGB mode with these systems.

There is also an AUTO ADJUST option which generally works most of the time, and an OSD ADJUST option. I won't be exploring those here either.

Here's our resolution list, showing mode 3 as selected.

Booting NeXTSTEP. The bootloader pauses here briefly to allow you to interrupt the boot or pass options.

If we do nothing, then NeXTSTEP uses a standard graphical boot. If you remember earlier versions of Mac OS X back when it was Mac OS X, this will look very familiar (same for Rhapsody):

But, of course, we'd like to see more of the guts, so we'll restart and try again.

This time we'll enter -v for a verbose boot.

These initial messages loading the kernel show up on a graphical boot, however quickly.

Next it loads basic configuration for the console, in this case Artist graphics and the built-in "Gecko" keyboard, which is internally PS/2. On a system with an HP-HIL keyboard connected, you'd see that driver here also. LASI I/O was already initially configured by the bootloader.

The kernel version is 3.3, the only version publicly released for PA-RISC, dated July 9, 1999. This unit has 128MB, the most RAM supported in the Galaxy 1100.

Bringing up disks and audio (the "disk" in this unit is an old SCSI2SD).

And finally network (details of my internal wired network suppressed). The boot is complete.

Let's log in.

Now, at this point, you could indeed get a grab of the framebuffer using Grab, and this is how I take pictures of OmniWeb 2.7 running Crypto Ancienne for TLS 1.3. But let's compare that with a similar Grab shot:

Because Grab has to be running, notice that it disappeared from the tiles on the right (it makes itself invisible). This is sharper than the analogue grab because it's an exact bitwise copy of the framebuffer. But it still has its artificialities.

And we can go totally meta and capture (with the Hall/Inogeni) Grab saving its own capture. This would probably be really tricky with Grab itself.

We also can't capture the system shutting down with Grab — and certainly not after we've logged out.

So let's capture the system shutting down.

Bye.

One last thing about the NeXTSTEP bootloader is the help text. And yes, we can grab that too. This series of images should completely document a normal NeXTSTEP PA-RISC boot-up and shutdown.

Let's briefly turn to our problem Atari ST-family machine before we conclude. This is using a regular passive ST-to-VGA converter plugged into the 13-pin rear video port. Remember, this was Tramiel's Atari, so we got things like 13-pin video with wacky connectors and ACSI instead of SCSI. The converter is passive, so there is no scan conversion.

Impressively, the Hall box accepts the 71.2Hz refresh rate, calling it "VGA-70." However, the image the ST generates is 640x400 and the odd refresh rate is probably why it's shifted. Phase and clock changes didn't really make any difference but we can still frame the image better directly from the on-screen menu.

After a couple false starts (overscan and underscan didn't make any difference), I arrived at this pleasing framing which suffices for direct capture. It's unfortunate that the 50% pixel hatching on the background is apparently too high-frequency for the Hall box to convert; I messed with the phase and clock here but only just got different periodic "beats" in the video. But it's legible and works.

Indeed, it's good enough to grab this early boot screen, showing the hard disk driver and mouse accelerator as the onboard ROM TOS brings up the system.

The SC-VGA-2 is not the perfect does-everything-box; like the LCDT600 I use for PAL composite capture, it requires an intermediary step with its own power supply and introduces a further amount of lag into the system. It also doesn't seem to display all the modes it advertises, though I have not yet determined who's really at fault for that. But it's a true scan converter that isn't very large, really does work, and seems reliable and well-built. I certainly got my $2 worth, by golly.