Future Hardware with Animal Names
Yesterday’s post mentioned some hypothetical marsupial-themed hardware: WiFi Wallaby, Video Platypus, and others. While these were meant as a joke, they got me thinking about what exactly a “Video Platypus” and friends might do, and I’m outlining some possibilities below. These are all tied loosely into vintage Macintosh hardware, although other ideas of interest to the general Arduino/RPi audience would be nice too.
Video Platypus
This might be a way of providing video out for compact Macs like the Plus and SE. I’ve discussed a few potential methods for doing this before. One approach is to directly tap the CRT video and synchronization signals and resample/convert them to a standard format. Another possibility is sniffing the address and data bus to watch for CPU writes to the framebuffer region of main memory, then use that to construct a new video signal.
Video Platypus could also be a converter or upscaler for the Mac II series and later machines. VGA adapters for these machines are inexpensive and easy to find, but VGA itself is a slowly dying standard. It would be nice if I could get a direct HDMI or DVI-D output from my 680X0 or PowerMac. Probably this wouldn’t need to be Mac-specific – it would just be a VGA to HDMI converter with a different physical connector to support the Mac. Something like this must surely exist already?
Disk Kangaroo
An external fileserver would be nice for old Macintosh computers: a device you plug into the computer and that appears as a large local or remote disk. Floppy Emu already serves this purpose when it’s configured in HD20 hard disk mode, but only a small number of Macintosh models support HD20 and have the necessary external floppy connector.
Disk Kangaroo could be something like a Floppy Emu for LocalTalk. Just plug it into the Mac’s LocalTalk port (the printer port), and it would appear as a fileserver. You wouldn’t be able to boot from it the way you can from Floppy Emu, but it would work on virtually every Mac model and system software version. The I/O speed would be about the same as Floppy Emu, I think.
The same idea could be applied to a SCSI disk instead, so the device would appear as a local disk and the computer could boot from it. This would be similar to SCSI2SD, except instead of formatting the whole SD card as a Macintosh disk, the SD card would contain a library of disk images to choose from, just like Floppy Emu. This would make it easier to set up and use for file transfers to and from an internet-connected PC.
Both the SCSI and LocalTalk disks could also use remote storage instead of an SD card. The files could be served from a PC on the same LAN, which would might require some special software on the PC, or the device could potentially do Appletalk-to-Samba translation. Or files could be served directly from a cloud storage account like DropBox.
WiFi Wallaby
Everybody loves the ESP8266 for connecting oddball things to WiFi. What might this do for a vintage computer? Most old Macs are capable of Ethernet networking, although many require an add-in networking card that’s now rare. I’m not sure if it’s easy or even possible to go from that to a wireless network connection.
What might you use this wireless connection for – general web surfing, email, and FTP? Or for connecting to other vintage Apple computers and printers wirelessly with Appletalk?
Maybe this could be like a WiFi version of Farallon PhoneNet. Connect a WiFi Wallaby to each of your computers and printers and they’ll auto-connect and form an Appletalk network. Same idea as the phone cables in PhoneNet, but wireless.
Printer Koala
A clever microcontroller board with the necessary physical connector could emulate an Imagewriter II or other 80’s – 90’s Apple printer. What would be the point of that? Maybe it could act as a print server or translator, enabling the old Macs to use modern printers. The need for printer drivers could make that difficult, though. Or maybe “printing” could perform another function like converting the document to PDF and storing it on an SD card or on a cloud-based server. Or it might implement a print-to-Facebook or print-to-Twitter feature.
Working in the opposite direction could be interesting too: a device that connects to an Imagewriter II or Stylewriter or LaserWriter. The device could put these classic printers on a network so that modern computers could print to them from Windows, OSX, or Linux. There would be a question of printer drivers again, but for relatively simple printers like the Imagewriter that might be doable.
Read 13 comments and join the conversation13 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Printer emulator? What you really want is to make a localtak-ethernet bridge and sell it with a cheap arm board preloaded with netatalk 2.x (3.x dropped appletalk support) and macipgw…. that way you get file/print/time server all in one + an internet gateway, most of this stuff already exists…it just isn\’t easy to use / packaged in a very friendly manner. I\’d even go as far to say that you could roll the Wifi Wallaby idea in with this as well. Host a web server configuration page on it… perhaps derived from openwrt\’s configuration pages etc… I tbink it should be possible to build something like that for $50-60 or so worth of hardware $10 for a basic arm board, $20 for your adapter board, and $10 for case + power supply.
https://mac68k.info/forums/thread.jspa?threadID=275&start=135&tstart=0
Video Platypus, well… I\’d go the SCSI framebuffer route if I were you… you\’d probably get the NetBSD guys interested as well in adding driver support for other machines too. There were the Scuzzygraph I and II or SuperMac SuperView.
To be honest I never quite understood what MacIPgw is for. Back when this stuff was current hardware, I was able to get my Mac on the internet with no trouble, so why is a special gateway required now? Is it only relevant for Macs that lack an ethernet adaptor, and *only* have LocalTalk?
Good point about SCSI graphics. I hadn’t considered that, since I usually aim for hardware that can be used without any special drivers or software. But an updated+improved Suzzygraph might be nice.
MacIPGW and A2SERVER are both Linux distros with Netatalk 2.x pre-setup for file sharing. They also have what is known as a MacIP Gateway, which encapsulates TCP/IP packets into AppleTalk….. which is required to run TCP/IP over a LocalTalk connection. Some of the higher end Localtalk-to-Ethernet bridges have this function built in (Shiva FastPath, Cayman Gatorbox), but those are hard to find these days. Moving the MacIP gateway into software allows one to use a cheap and easy to find Localtalk-to-Ethernet bridge usually meant for printers, or a Mac running Localtalk Bridge.
Regarding classic hardware ideas…..
Video Platypus: The OSSC can act as a simple analog VGA to DVI converter using its “pass-thru” mode. The problem is the monitor on the other end may not be happy with out-of-spec video signals (some 68k Macs output 640×480@67Hz, many monitors expect 60Hz). Luckily most Macs can be forced to output standard VGA/VESA refresh rates and video modes.
Printer Koala: Right now the GSport emulator implements an emulated ImageWriter LQ that can be “connected” to a virtual serial port. It interprets the ESC sequences outputted from the emulated IIgs and “prints” to a bitmap file, which can be routed to a printer, image, or postscript file. Its written in a way that it can easily be ported to other uses. Such a hardware device could be based off a RPi style platform with a serial and/or parallel input port. The rest is mostly a software thing and it could emulate more than an ImageWriter. Epson ESC/P2, PCL, and PostScript can be supported too (the latter two are already available in the form of GhostScript/GhostPCL). If you want to print the output to a modern printer, CUPS+GutenPrint can handle the driver end of things.
I’m still not quite getting it, sorry. Why bother with a LocalTalk to Ethernet bridge and special gateway software, when you could just put an ethernet card directly in your Mac instead? Wouldn’t that eliminate the need for all of this? If your goal is to get the Mac online for web browsing, email, and FTP, that seems like a much easier solution.
Compact Macs are limited to either expensive Ethernet cards (SE,SE/30) or SCSI Ethernet adapters. Some may not want to fill their LC series machine’s PDS slot with Ethernet if they have another card. Also keep in mind the Apple IIgs supports LocalTalk as well, the Ethernet cards (which aren’t always available) don’t support file sharing.
LocalTalk-To-Ethernet bridges are cheap and commonly available, as are newer Macs with built-in Ethernet to use as a bridge.
It makes no sense to use the PDS slot that has your accelerator or video adapter in it… for Ethernet unless there is pass though… which is very expensive to buy off the shelf even then localtalk is probably more convenient than cramming things inside the case.
Very interested in Video Platypus. I have a Mac Classic II and would love to turn it into an ancient Mac Mini. I had probed the output signals before and found them to be quite different from standard VGA. I believe an adapter for the old B&W Macs should probably sniff the address and data bus and manage it’s own video buffer. You only need 22 KB to store a single frame. I’d love to have something that enables DVI output, but VGA would be fine as well.
The new Lattice iCE40UltraPlus FPGA is ideally suited to implement a Video Platypus. It’s $5-6 in 1000’s quantities. The unique thing about it is its 128 kbytes of internal SRAM. No other FPGA in its class has anywhere near that much RAM. I recall it being organized into four banks of 32k. Perfect for four frames. This part would be the cheapest way to do it.
The difficulty is of course in the asynchronity between the clock domains of the Mac and the desired video signal.
No suitable resolution/timing has an hsync rate close to that of the Mac (or an integer multiple), so line-by-line synchronization is impossible. (Of course, pixel-synchronicity is impossible as well.) We are stuck buffering something on the order of a frame at least.
It would be nice to lock the vertical sync rates together. A VGA monitor will happily sync up with the Mac’s 60.15 Hz vsync rate, so in theory, it’s possible. The issue is that you can’t use a PLL to multiply 60.15 Hz to get a pixel clock some one million times faster.
So forget even frame-synchronicity; there has to be a proper synchronizer and every once in a while you drop or repeat a frame. So you build a bank-switching type in the iCE40UP I mentioned… or…
Before I knew about that part, I figured the cheapest way would be to use a microcontroller with two SPI peripherals (to read in and send out the black and white data) and a PLL (to synthesize the output pixel clock). Something with enough ram to double or triple buffer the frames. New ARM micros always have multiple asynchronous clock domains, so they have the synchronization circuitry required to synchronize the incoming pixel bit rate with the output pixel clock, along with enough internal memory to hold a few frames and internal program memory. So that’s the other single-chip solution.
I can’t think of any more ways as simple.
Good analysis, thanks. Which version of the ICE40 Ultra are you referring to? At DigiKey the largest has 81920 bits of RAM (10 KBytes).
I think that a bus sniffer design may be easier than a true video signal converter, as it avoids the whole issue of asynchronicity.
The OSSC doesn’t have a frame buffer and has locked vertical sync output. The reason is that it is strictly a line-doubler (it also does 3x,4x,and 5x the original scan rate depending on the source). At most it needs to buffer a few lines of video. The trade-off is you are usually stuck with a non-standard video signal that some TVs/monitors will balk at (particularly using 3x,4x, and 5x output modes). So using the device, a compact mac’s 512×342 video will be output at a lined doubled 1024×684, no lag, no frame dropping/adding. Most monitors will sync to that, but some get grumpy at signals that are not 100% VESA timings.
For the full frame buffer approach, it exists in the form of the Micomsoft XRGB-mini Framemeister. That can scale to any output resolution you want, zoom the video, etc. The trade-off with a full frame buffer is there is some input lag, but much more flexibility on how one can process the video.
Steve, it’s the iCE40 UltraPlus in particular. They’ve got the 80kbits of ram mixed in the FPGA fabric you mentioned in addition to the big block rams. The other distinguishing thing about the series is that they are relatively light on I/O. The most full-featured variant comes in a QFN-48 package. Currently their availability is pretty limited. I have only seen them for sale in 1000’s quantities but they are new as of 2017, so I expect that to change.
About the bus-sniffing approach, there is still some problem of asynchronicity, since the video pixel clock and the Mac’s clock will probably have to come from different crystal oscillators. And then of course there is the problem of attaching it to the Mac. Each machine will demand a different implementation.
Chris, I considered the line-doubling approach, but rejected it since I figured no monitor would accept the 1024×684 resolution, not even multisync type. Do you really think it’d work?
Hi Steve,
Greetings from Indonesia, I received the Floppy Emu I ordered recently. I would really love to see WiFi Wallaby in the future! Although it’s super fine without WiFi, as long as I get connected to the net. It’s really challenging for me to find a LocalTalk bridge DB-8 to Ethernet (such as AsanteTalk). Looking forward!