Refurb weekend: Alpha Micro Eagle 300

One of the more unusual 68000-based systems -- even a few powered by ColdFire CPUs -- are the Alpha Micros. They run a DEC-inspired multiuser operating system called AMOS and popped up in lots of vertical markets as diverse as point of sale, veterinary and medical, and even churches (I encountered my first Alpha Micro in a Salvation Army corps, where it ran the business end using its terminal-based office suite and customized menus). I have a particular fondness for these systems due to a story that I'm not quite sure I'm past the statute of limitations on, but suffice it to say I find them to be entertaining oddballs and I serve my own homage site actually on an Alpha Micro, the Eagle 300. Here it is with its rather nice AM-75 colour terminal (a modified Wyse WY-370) and an AM-401 external CD-ROM (a rebadged Toshiba XM-5401B).

This machine does 24/7 non-stop service and it occurred to me one day walking past my house's server room that there was a rather loud whine coming from it, as if a cooling fan was stripping its bearings or something. A little investigation determined that it was coming from the E300, but it wasn't the power supply fan or the single 80mm case fan: it was the hard drive, which was slowly cooking itself to death because both of those fans, the only case ventilation, had failed. The power supply was a cheapo AT (not ATX) power supply I bought off the shelf a few years ago, but the case fan looked like the original one that came with the unit when it was manufactured in the mid 1990s. It's time for a Refurb Weekend!

The first order of business is to solve the cooling problem temporarily and order new parts. Let's just take the case off so the system can run as cool as possible until supplies arrive.

Replacing the PSU fan isn't prudent in this situation because there's probably other marginal parts in it as well; at this point it's safer just to replace the whole thing. Although I could jam another AT supply in it, they're getting rarer than ATX PSUs, the currently available stock are usually of poorer quality, and AT supplies have the singularly inconvenient attribute of having an integrated hard power switch that you have to weasel into where the old one went. (Notice the bag of mounting parts from the last time.)

For the new fan I picked a high-flow Noctua NF-A8 fan (the single-RPM FLX version, since this machine is too old to have PWM control) because the concept of a high-end fan in an old school workhorse amuses me conceptually. However, for the power supply I got an off-the-shelf ATX PSU and an AT-to-ATX converter.

The fan was the easy part: the old fan has a Molex power connector, and the Noctua conveniently includes a converter for that in the box, so done and done.

The AT-to-ATX converter is a little more complicated. This takes an ATX power connector and has leads to the existing switch instead of providing one of its own, and provides power on traditional AT P8/P9 connectors. You slip its switch leads out and connect the ATX connector to the PSU, and then connect the P8/P9 connectors to the motherboard.

The advantage here is that once wired in, you don't have to deal with the motherboard power supply connectors anymore or the power switch; you just switch out the ATX side like any recent system. This is important because many later AT supplies (and, it appears, this cable) don't properly key the P8 and P9 connectors. Inserting them backwards is guaranteed to let out the magic smoke and a lot of cussing, so remember the old nerd saying that you should never have red and red together. With this cable you just get it right once and you don't have to risk stressing the connectors or shorting out the machine next time.

With the rubber mounts in, the Noctua pulls a prodigious amount of air through, and combined with the now properly functioning power supply our Refurb Weekend was completed in less than a Refurb Hour. Best of all the hard disk is no longer shrieking from heatstroke. Still, maybe a SCSI2SD is the next project for this machine.

Terminal sleep for old Macs

Even though my daily driver for almost the last two years has been a POWER9 Raptor Talos II, prior to that I used a Power Mac Quad G5 for almost 13 years. Although that system is on its second liquid cooling assembly, it still works, and any machine with that long of a service record is going to have lots of files stored you need to periodically access and old applications you need to periodically run. (And I'm still building TenFourFox on it, too, so there's that.)

For many things I'm connected to it via VNC or even just switching the KVM to its console. However, the G5 is not a particularly power-thrifty machine and I'd rather not have two big beefy computers running at the same time under my desk when it's 100 F out in sunny Southern California, so I regularly have it in sleep. Since many of my other typical tasks can be completed from the Mac OS X command line, it would be nice if I could sleep and restart it from a remote terminal login as well.

As it turns out, at least for 10.4 and up, this is relatively simple to do. To sleep the G5, I have a very simple shell script that looks like this:

#!/bin/csh -f

say "switch kvm"
sleep 5
osascript -e 'tell application "Finder" to sleep'
sleep 10
date

The magic incantation here is the AppleScript (run by osascript), which tells the Finder to sleep the system, and acts just as if you had done this from the Apple menu even if you're not actually on the console. The rest of it is oddiments of my routine: the say reminds me to switch the KVM away if I run this script from a Terminal.app session if I am using the console, since activity on USB will cause the G5 to wake up, and the two sleeps give me time to switch if necessary and give the AppleScript enough time to run. The date command is there because initially I couldn't figure out why it kept waking up (turned out to be a defective PCIe card which I pulled) and I wanted to correlate the time it awakened with the system log, but it's just handy to know anyway.

So that's sleeping — what about waking it up? The G5 will respond to Wake-On-LAN packets in sleep mode, so it's just a matter of sending it one. There are a couple of different command-line implementations; I personally rather like this simple Java one (especially since it doesn't need privileges) or this slightly more complex Perl version.

You would think you would pass these scripts the IP of the system and its MAC address, and you would be wrong. You do indeed need to know the MAC address of the destination system which you can get from arp or ifconfig, or for Power Macs from Mac OS X by going to System Preferences, Network, selecting the Ethernet interface in question, and then clicking the Ethernet tab. However, the IP address you'll send it to is actually the broadcast address for the network. ifconfig can tell you this as well if you don't know it. For many people, with this example assuming you used the Java version with javac WakeOnLan.class, that command for a typical home 192.168.1.* network would look like

java WakeOnLan 192.168.1.255 00:01:02:03:04:05

where the xy:zg:hi:jk:lm:no digits at the end are the MAC address of the destination system. Once in a great while, because this is UDP, you will need to send the packet twice if the machine fails to acknowledge it. I put this into a separate shell script on my T2 so that I just run it to wake the G5 up, shell in, sleep it when I'm done and either leave the window open (for the next time I wake it up) or just cut the connection. Now the G5 is always ready when I need it and in the way I need to access it, and not driving up my electric bill when I don't.

TFW you find the last cartridge

I don't consider myself an obsessive collector because I'd rather use my vintage systems than simply collect for them. The majority of the systems in my back office may just be toys, but I don't collect (much) junk just for display, nor do I want to accumulate junk since I don't have much additional room to have out all the systems I'd like to and I try to regularly use them to keep them serviceable.

However, the exception to this rule is the very first home computer I ever had, the Tomy Tutor (that's my personal site dedicated to it), the toy company's one and only attempt at an American home computer system. This machine, whose closest hardware relative is actually the unreleased Texas Instruments 99/8, descends from the earlier Japanese-only Tomy Pyuuta (ぴゅう太). I still have the exact computer I used as a child before we upgraded to a Commodore 64 (that's me with it in the picture in my old apartment), and it still works. I figure if I'm going to be obsessive about one system, it should be that one, and I've now crossed the threshold where I have every single cartridge for it that Tomy ever manufactured. A few small-volume tape titles still elude me along with some third-party ones that I'll probably never find, but this particular last cartridge I've been trying to track down for a long time, and a boxed one (!) finally showed up for a not-impossible price relatively recently. COVID-19 has really upset international shipping and it took awhile to get it but it finally arrived.

The last cartridge I had yet to find was the Japanese domestic demonstration cartridge with a copyright date of 1983, intended for shops exhibiting systems for sale complete with a pretty little pink box. The great irony is that it actually doesn't work properly with the (Americanized) Tutor. I expected that it would appear wrong on-screen since the American Tomy Tutor naturally lacks katakana, but the demo cartridge additionally has its own menu — which seems to defeat the purpose of being a standalone demonstration cartridge — and it wouldn't read any of the Tutor's keys. So I dug out one of my Pyuutas and plugged it in and used it as it was intended. Let's look at some grabs.

Main title screen of the Pyuuta.

Main menu of the Pyuuta; you can read more about the system specifically, but everything is either in uppercase romaji or relatively primitive katakana glyphs, even Japanese native words. Typical of early Japanese home computers, this can sometimes makes it a little tricky to translate everything and my Japanese isn't so hot but I'll do my best. Here we're selecting the cartridge.

Pretty flowers and big sprites.

The demonstration cartridge menu's "three functions," namely, "color graphic," G-BASIC (the very limited peculiar subset of BASIC common to the Tomy computers, in this case the original Japanese keyword variant), and "cartridge game." The sprites shown are from Saurusland, which is vaguely related to the Tomy tabletop Caveman, but Saurusland isn't actually demonstrated here (read on). This is where the cartridge failed on the Tutor; it wouldn't register any of the number keys. There is a way documented on the box of going into an unattended mode with the SHIFT key but I couldn't get that to work.

The color graphic(s) demo using the classic Tomy built-in GRAPHIC paintbox. The Texas Instruments 9918A graphics are pretty well demonstrated here, along with sprite animation ("In addition, it's easy to make animation on the Pyuuta").

G-BASIC (GBASIC on the Tomy). Despite the Pyuuta and the Tutor being programmed in Japanese and English respectively, the internal representation uses the same tokens, so a tokenized program is actually mutually intelligible on both systems (once you account for differences in tape encoding). The blurb says, "Pyuuta is a personal computer. Programming is done in G-BASIC. G-BASIC is Japanese. In addition, it is easy to operate. Combining G-GBASIC with Pyuuta graphics can make beautiful original software."

The Pyuuta is advertised as having 20K of ROM, 16K of RAM and a 16-bit CPU (the Texas Instruments 9995). This is in fact incorrect; the Pyuuta has 32K of ROM. The Tomy Tutor has 48K of ROM owing to having both GBASIC and regular BASIC (descended from TI Extended BASIC) but is otherwise the same. The blurb adds, "Here a G-BASIC program is demonstrated."

G-BASIC "programming" is thus shown; you can see how simultaneously terse and inefficient this BASIC dialect is. The keyword kake is transliterated into English GBASIC as PRNT. In the monitaa (monitor) we are telling the Pyuuta jikkou (execution) to run the program.

The program is a simple math table generator.

Finally, cartridges. The blurb reads, "For Pyuuta, there are a lot of cartridges as well. Just insert a cartridge to easily enjoy a video game. Not only games but also other things such as education and home finance are planned for sale." Tomy never released these, though SKUs for them were reported in at least one Japanese marketing circular; all the Japanese domestic cartridges are games, and exactly one of the American Tutor cartridges is education-related despite similar promises here.

Despite using Saurusland sprites in the demo menu, the cartridge proceeds to show off Night Flight instead ("Here just a little of this fun cartridge game is demonstrated") which is fortunately a much better game (essentially the Tutor's answer to Qix, and subsequently ported by Colpax to MSX). This game never made it to American shores, by the way. You can't actually play it but the music and the graphics are exactly as they would appear on a real cartridge.

The Japanese demonstration cartridge was significantly rewritten for the American market, and you can see grabs of that cartridge (plus other Tomy marketing material). Not only was the language changed to English, but the cartridge menu was largely dispensed with, there were some minor changes to the sprites (a satellite instead of an astronaut), a completely new and different BASIC section replaced the G-BASIC segment with a primitive non-interactive card game, and the demo cartridge was changed to Traffic Jam (in my opinion the Tutor's best).

The most interesting difference between the Japanese and American demo cartridges, however, is the very last screen. I'll reproduce them both here.

Keep in mind that the Tutor was being sold in a rather different market somewhat later in 1983. Both systems have the TV, CPU and cartridge shown, though only the Tutor advertises the Joy Stick [sic]; the Pyuuta just has the Joy Controllers. Both systems also advertise a voice synthesizer (unreleased) and the cassette Data Recorder (released), which the Tutor calls a T. RECORDER even though it was sold as the Data Recorder here too.

The other expansion peripherals are where it gets a little different. The Pyuuta's "development schematic" has an orange box labeled mazaaboodo (motherboard), which connects to a line printer, floppy disk drive and onkyou kapara (acoustic coupler modem). In the Pyuuta manual each of these connect through a bespoke interface, such as an RS-232 serial interface for the acoustic coupler and a floppy controller board for the disk drive. Presumably this idea is what evolved into the BASIC-1 peripheral for the Pyuuta, which does indeed connect to the mainboard's expansion slot rather than through the regular cartridge port on top, but it only furnishes the printer interface (plus adding Tomy's version of TI Extended BASIC). The printer, disk drive, acoustic coupler and the other respective interfaces were never released nor to my knowledge demonstrated.

The Tutor, however, shows the printer connecting directly to the system (which is impossible, as there is no interface for it, and only homebrew ones ever existed). However, the most notable difference is the presence of the TI-ADAPTER. This is in fact nothing less than Tomy's planned rebranding of the TI Peripheral Expansion Bus cage, and there are mockup pictures of Tomy's version which provided the necessary interfaces for the disk drive and printer, but it was also never released (assuming it ever existed beyond a mockup in the first place). The PEB was even less well known in Japan, which probably explains why Tomy never bothered with that there.

It's a real feeling of accomplishment to complete this piece of my collection, even if there's still a few other items to mop up, and particularly when the last item has such interesting history behind it. I'll be updating my Tomy Tutor site with some of these grabs and some of my new tape acquisitions, but for those of you unfamiliar with this odd little computer, now you can share a little of my joy.

xa 2.3.11

I've updated xa, André Fachat's venerable 6502 cross-assembler, to version 2.3.11. This contains miscellaneous bug fixes and a compilation fix for gcc 10. As usual it is tested on pretty much all of my Un*x systems here including AIX, Mac OS X (PowerPC and Intel), NetBSD/mac68k and Linux/ppc64le. This will probably be the last in the venerable 2.3 series before 2.4, in which we may do some compatibility breaks and jettison a couple long-deprecated options. More to come on that.

SAIC Galaxy 1100: finally screenshots of the unscreenshotable, part III

This is part of a series — you can read prior entries

In our last entry we were testing the Inogeni VGA2USB3 on various SunRay devices and the Apple Network Server. However, it seemed to have met its match with the SAIC Galaxy 1100 portable workstation. Or did it?

The SAIC Galaxy 1100 [updated to our later comprehensive entry] and its less powerful sibling Galaxy 1000 are MIL-SPEC portable versions of the HP 9000/712 "Gecko" PA-RISC workstation built as part of the United States Navy's $672 million TAC-4 computing initiative in 1994. Hewlett-Packard had no portable workstations in its product line at the time and subcontracted with Science Applications International Corporation to create a ruggedized, self-contained version of HP's then-most common PA-RISC desktop system. As such, Galaxys have all the features of the Gecko but also add a built-in keyboard and trackball, a really nice 1024x768 8-bit colour LCD flat panel display in the lid and two PCMCIA (!) slots. On the rear, besides Ethernet, AUI, SCSI, audio and power ports, the Galaxy systems have PS/2 connectors for an external keyboard and mouse, switches to choose internal or external devices, and a VGA out. This enables you to not only use it as a self-contained luggable but also to plug in a monitor, keyboard and mouse and operate it as a more or less conventional desktop. Sadly, there is no internal battery option, but it probably would have made it prohibitively heavy even for the military.

Given this choice of configurations, you would think that the VGA port mirrors the internal display (on a regular Gecko there's only the VGA port, and that's your only display), and, well, you (and I) would be wrong. The VGA2USB3 just displayed a blank screen no matter what was on the internal display. After messing around at the boot administration prompt and looking at the output of the monitor command, it occurred to me that the SAIC Galaxy reports two displays. Stranger still, the internal built-in display is actually treated as the alternate display, not the primary one. I selected the great common denominator of displays, 640x480 at 60Hz, for the "primary" display and left the internal display at its current setting (monitor 5 11) and told the boot admin to use the external VGA out with path console graphics (as opposed to graphics1, which turned out to be the internal display). Note this is completely unlike the Gecko with its single video port, by the way. I finished with a reset and ... we have a screen!

Again, there's no way you're grabbing this initial boot screen with anything but an external capture system. Ditto for the boot admin menu:

Sync-on-green was thus absolved as the issue; it was just an unexpected configuration. As you can see, the image is nice and sharp and captured at 1920x1200 with pillarboxing preserving the original 4:3 aspect ratio. The only flaw was a missing set of left-most pixels.

The next step was to see if I could capture the operating system's boot sequence as well. This machine usually runs NeXTSTEP 3.3, the only version that supported PA-RISC (it can also run HP/UX and NetBSD, but where's the fun in those?). NeXTSTEP wouldn't be particularly entertaining or representative of the Galaxy experience in 640x480, so at the boot admin prompt I selected mode 2 this time (1024x768 at 75Hz). When I restarted the machine, however, everything was blank again! I blindly hit ESC to get back to the boot admin prompt and set it back to mode 5, and the screen reappeared. I then methodically tried all the other non-flat panel modes and discovered exactly none of them worked except mode 5.

If you looked at the list of modes above, you may have already discovered what's special about mode 5: it's the only display mode that's 60Hz. None of the VESA modes, not even the 42Hz mode, would work either. Although the slip of paper in the box that Inogeni purports to call a manual suggests you can go to VLC's advanced settings and try to match the frame rate like so:

... it made no difference. Despite Inogeni's statements to the contrary, the capture frame rate is 60Hz or bust. (Fortunately, both the SunRays and the Apple Network Server in the prior entry were already at 60Hz, so I could grab from them just fine.) This doesn't look like a deficiency of the Linux version of VLC because the macOS version couldn't see anything either, and it's entirely plausible that this limitation might be a consequence of being vanilla USB Video Class compliant.

Since the refresh rate was now obviously the problem, my first thought was to find some sort of conversion device that, along the lines of a digital telecine, would drop or merge the frames together and put out a 60Hz signal. I'm fairly certain such devices exist but none obvious popped up with some cursory searches on eBay, and I didn't want to spend a lot of money on a professional solution that may or may not work. (I'm already out for the damn Video Ghost and this box, you know.) Eventually it occurred to me that a cheap way of figuring out if I was on the right track would be a VGA-to-composite converter, and to connect it to the CVBS input the VGA2USB3 already has. The images almost certainly wouldn't look very nice but it would at least demonstrate if the idea was feasible.

VGA-to-composite converter boxes are almost literally a dime a dozen on eBay and Amazon and come in two major types. The majority are a little squarish box (usually black or white, though the $14 one I ended up getting turned out to actually be lavender) that takes VGA and a 3.5mm audio jack on one end and has CVBS and stereo phono jacks on the other. They will output in PAL or NTSC using a tiny switch on the side and claim to work without external power, though mine didn't put out any signal until I connected it to a USB port on the Talos II. There are a billion variations of this type and they appear to all perform identically, which is to say not too good. The top image was 1024x768 at 75Hz, the second at 70Hz and the third 640x480 at 60Hz for comparison to the images before. I selected PAL for the greater number of vertical lines which fortunately the VGA2USB3 accepts.

Besides the appalling resolution, which sadly is not unexpected due to the massive downsampling of the video signal, all of these grabs have various additional technical problems. The 75Hz image had the least image distortion but had an obnoxious green cast. However, even though the 70Hz and 60Hz images showed proper colours, these warped the display at the top, and all three refresh rates had occasionally irritating flicker like an old analogue TV set not properly tuned to the right channel. Switching to NTSC mode made no difference. The "NO SIGNAL" colour bars this unit displays were stable except for some dot crawl, so it appears to be something about the VGA conversion itself.

Nevertheless, I went ahead and continued in 1024x768 at 70Hz to approximate the appearance of the internal display. Here's the NeXTSTEP bootloader:

and the boot screen:

and the login screen:

Again, there would be no way to capture these snapshots without an external system, but they're so muddy I might have done better just trying to take a picture of the screen with my mobile phone.

That said, the quality of the composite capture device matters, and it turns out the VGA2USB3 isn't particularly good at composite capture compared to other units. For capturing composite video on my Quad G5 I use a Canopus ADVC-300 over FireWire 400. While the American version of the ADVC-300 is strictly NTSC and it uses a DV-aspect ratio which is not 4:3, it manages to pull out considerably more detail. Here's the initial Hewlett-Packard logo, the NeXTSTEP boot screen and the NeXTSTEP login screen captured from the G5 instead:

This is certainly better, likely due to the ADVC-300's rather more effective comb filter, but the quality is still comparatively dire overall.

The second type of common VGA-to-composite converter is a little more deluxe. These actually have a simple on-screen display "OSD" and options for adjusting screen size and picture, and usually one or two DIP switches to set PAL or NTSC. They emit in S-video, composite and VGA, and are USB or 5V wall-wart powered (don't confuse these with similar devices that convert to VGA and may even be in the same form factor). My initial hope was that you could fiddle with the settings and get a 60Hz picture out of the VGA-out, but it turns out it's just a passthrough.

So, back to CVBS/composite. 75Hz not only had the same green cast that the cheaper box did (suggesting they may have a common designer) but had such an unstable image I'm not going to even bother showing it here. 70Hz was generally functional. Here's PAL grabs on the VGA2USB3.

Surprisingly, the detail level is not appreciably better and in some places looks a little worse, but the colour is less washed out, so I'd call it almost a draw. I then tried NTSC grabs on the ADVC-300 with the G5. This turned out to have an obnoxious issue where the picture juddered badly depending on the vertical size of the image and it reset every time the signal dropped, particularly annoying for grabbing the very first startup screen since you have to quickly adjust the image in the OSD (tip: make it as large as possible and then back down quickly until the picture converges, then turn off the OSD). However, this type of converter also offers S-video with separated luma/chroma for improved image quality, so we'll use that input on the ADVC-300 for these grabs (which the VGA2USB3 does not support).

And a shutdown image, since these are also usually impossible to get without an external capture system:

Although still poor compared to the VGA direct grabs, these are probably the highest quality images we can get from this converter.

Let's conclude with an acid test. Compare these (almost) exactly identical screens of NeXTSTEP and OmniWeb, first with the deluxe box captured by the VGA2USB3 at 72Hz, the ADVC-300 over composite at 72Hz (using the built-in zoom as a comparison), and the ADVC-300 over S-video at 72Hz, and then with the cheap box captured by the VGA2USB3 at 75Hz and 72Hz and then captured by the ADVC-300 at 72Hz:

Then compare those to this direct snapshot of the framebuffer using NeXTSTEP's built-in Grab utility:

Overall, I'd have to say the cheaper box, for all its idiosyncracies, did a better job on detail. Colours are better on the deluxe box, but even with sharpness driven all the way up the lettering is crisper on the cheaper one, and colours are easier to correct in post-processing than messing around with sharpening filters. The cheaper box is also easier to use, and, uh, cheaper. However, the cheaper box also has screen distortion, flicker and artifacting that the deluxe box doesn't, and the best image of all wasn't even taken on the VGA2USB3 itself!

Final word, since I've spent too much money and time on this for the time being: if you know your video source emits 60Hz, then the VGA2USB3 is convenient and works with anything that works with UVC devices, albeit for a significant sticker price. Composite capture is not its strong suit, but it can do both PAL and NTSC which is useful for older systems, and it's handy in a pinch. Plus, it's still working, which is more than I can say for the Video Ghost. On the other hand, if you have a weird old system that doesn't have many compatible video options, it will be little more than a frustrating doorstop, and a pricey one at that. After a little thought we were able to screenshot the apparently unscreenshotable, but with significant compromises in quality, so I'm still in the running for a box that can "just do it" and I guess if I find one it will be a future entry too.