Bell & Howell: Power test, and the outlines of a crazy plan

On the Bell & Howell front, I have now cleaned it all up, and reassembled it. In the process, I found this stamped under the keyboard, which pretty definitively indicates that I was right about this being an August, 1981, machine. (Further evidence that the “8138” really does mean “38th week of 1981,” corresponding to September 14–18, 1981. So, I guess they built the case on Monday, August 10th, and put it in a pile for five weeks, then built up the motherboard and assembled it.)

Bhiiplus keyboard date

When I plugged it in, frayed cord and all, and hit the power switch, I got nothing. No response. This means one of two things to me: either the power supply in the machine is dead, or I plugged in the leads from the backpack to the power supply wrong (which, I suppose, might also mean that the power supply is now dead as a result). I have not tested the power supply separately, but I did plug in the terrarium power supply to the Bell & Howell and got this:

Bhiiplus side powered

All keys working, power light on, everything at least initially appears A-OK. The video is running on my composite amber monitor, out of the backpack, courtesy of a BNC-RCA adapter I picked up today as well.

Bhiiplus keytest

This also rectifies the oversight from before, as I now have a picture of the game I/O port on my own machine. Here it is close up, for your viewing pleasure.

Bhiiplus gameio

Now I just need to decide what cards go in it, replace the feet with some authentic spares I have coming to me in the mail, replace the power supply (with something authentic I hope), and set up the backpack in some useful way.

My current semi-crazy but interesting plan is this, for the record: I will install a language card (to bring it up to 64K), a Super Serial card (to allow it to connect to other computers), and a Disk ][ card (with one or two drives connected). Here is an “artist’s” rendition of that, courtesy of Penultimate on my iPad:

Bhiiplus art slots

And here is my similarly skillful rendition of the AV connections I intend to make with the backpack.

Bhiiplus art av

The features of the diagrams above are as follows:

  • I will bring audio in from one or two nearby machines, to allow them to be mixed by the backpack (just to give the mixing knobs in the backpack something to do, I can’t think of any real practical use for this).
  • One video out goes to a monitor atop the machine.
  • The second video out goes to a capture card, probably the Wings personality card in the Power Mac G3. Caveat here: I need to put some kind of surge suppression mechanism in there, because otherwise the power surge over that cable when the Apple is turned on will likely kill the G3. I don’t know if I have to build this myself, or if there is something out there that can accomplish this for me.
  • The speaker out also goes to the capture card, right channel.
  • The cassette out goes to the capture card, left channel.
  • The cassette in comes from the G3, left channel.
  • The Power Mac G3 streams the video/audio to the internet for remote consumption.
  • A webcam is also placed facing the Apple so that it can be viewed that way, too, and not just through the straight video out.
  • The Super Serial Card in the Apple will be connected to some Mac capable of communicating with it and with the internet (maybe the Power Mac G3 again, maybe the Performa 6116CD).

What I will have accomplished here is, I think, the following. Presuming that I write the Super Serial Card modification to the modem driver that I discussed in an earlier post, and presuming that the Apple is set to start that up automatically upon power up, I will be able to control the Apple’s command line over the internet. I will be able to see what I’m doing both through the webcam stream and through the AV stream. I will be able to send programs not already on the machine through the cassette port, which I can get on the internet. If desired, I can also save data via the cassette port into one channel of the AV stream (though for both loading and saving, I could do this over the serial port if I made a slightly more sophisticated driver). Et voilà. Mostly controllable Apple ][ plus over the internet. Better still, using the backpack for what it adds to the machine, since the “speaker out” function wouldn’t have been available in a regular Apple ][ plus, and none of this requires additional line splitting.

Further, if I can get the Apple Cat ][ set up with X10 modules on a different Apple II that I can communicate with over the internet, I can use that to power the Bell & Howell off and on if it ever freezes or gets into a state where it needs local input that I can’t provide.

There are a lot of moving parts to this plan, but if it works, it would be very cool. And it seems like it should be technically feasible.

Apple II screen sharing

This is just me thinking out loud, but back in the day I wrote a number of modem drivers basically for the purpose of running bulletin board systems, and mostly specific to the Novation Apple-Cat ][ modem. However, it occurs to me that it was also possible with those drivers to actually get to the DOS 3.3 prompt and do things. This was possible because it hooked into the DOS read and write character routines, and DOS itself was good about always using those when sending data and retrieving input.

While the days of using modem connections over the phone are probably behind us, the basic procedure for sending and receiving characters over the serial port in a Super Serial Card is probably nearly identical, and it wouldn’t require much of a rewrite of those drivers to adapt them to SSC operation. Apple has helpfully archived some sample code for accessing the SSC. So, it seems like it would actually be a pretty small step to make it possible to, say, SSH into the DOS 3.3 prompt of an actual Apple II, with some mediating software on a machine that would accept the SSH connection and then just pass the subsequent data through the serial connection.

Having thought through it that far, it also occurs to me that for lo-res graphics, it should be possible to mimic them (sort of) on an ANSI color terminal as well. The colors don’t quite match, but this would be sort of close:

0 — black 40;0m — dark black
1 — magenta 43;0m — dark red
2 — dark blue 44;0m — dark blue
3 — purple 45;1m — bright magenta
4 — dark green 42;0m — dark green
5 — grey #1 40;1m — bright black
6 — medium blue 44;1m — bright blue
7 — light blue 44;1m — bright cyan
8 — brown 43;0m — dark yellow
9 — orange 41;1m — bright red
10 — grey #2 40;1m — bright black
11 — pink 45;1m — bright magenta
12 — green 42;1m — bright green
13 — yellow 43;1m — bright yellow
14 — aqua 46;0m — dark cyan
15 — white 47;1m — bright white

With just an ANSI terminal on the other side, the Apple could send a sequence like “^[[42;0m ” and print a dark green block. That’s still 8 characters for every block, and there are 1920 blocks in a full-screen lores screen, 1600 blocks in a split-screen lores screen. So, that’s 15360 bytes (or 12800 plus 160 more for the text part) that have to traverse the wire. Over a modem, that would be prohibitive. Over the SSC, we can go at 115,200 bits/second, so 14,400 bytes/second, so we could spit out the ANSI-enhanced blocks in about a second.

At least one downside of doing it this way is that Apple II lores blocks are actually half-height, so we’d wind up with something that is twice too tall.

██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██

The only way I can see around this, if ANSI color is to be used, is to double the width, which would then result in 9 bytes per block, so now we’re up to 17280 bytes per screen (or 14470 with the doubled text). Plus, without any good way to do the text except to space it out as above. I suppose one alternative would be to have a client that receives the data stream from the Apple and knows how to switch into “lores mode” and accept the bytes as they come, which would then only take 960 bytes to communicate. But doing that does kind of reduce the charm of this, since then we’d be getting pretty close to just doing emulation.

Even that aside, without a client to accept the lores graphics, it is not clear what purpose it could be put to. What would trigger it to send a screenshot? I suppose maybe a driver command could trigger sending a clear screen command, the ANSI representation of (page 1) of lores blocks, and then leave you back on the text command line. It could even I suppose go in continuous mode, but I can’t imagine anything going at 1fps being acceptable in terms of animation, and it would be a major trick to allow input at the same time.

As I was thinking about this, one other possibility occurred to me: perhaps I could patch the Applesoft routines by using the upper 16k, so that any attempt by a BASIC program (or any program that made use of the Applesoft routines) to use the Applesoft GR, PLOT, HLIN, VLIN, COLOR commands would position the cursor on an ANSI terminal and output appropriate blocks. While this would be even more ANSI code overhead, it wouldn’t need to send entire screen shots, I wonder if the speed would be acceptable. Doubt it, but it’s another thing to think about.

Anyway, maybe dealing with graphics is not worthwhile. Probably it isn’t. But it still seems that getting to the text-based DOS 3.3 command line should be relatively straightforward, and indeed it should be quite possible to run a BBS pretty much unmodified in this way, with just a couple of tweaks to the driver code to make it address the SSC instead of the modem, and to make it be able to detect what would count as a “ring.”

Rambling about modern usefulness of vintage machines

So, I’ve been collecting a bunch of vintage machines, mostly because of the nostalgia value, but practically speaking, what good are they? What realistically might ever lead me to turn one of them on? Some of these are just visually appealing (the G3 and G4 iMacs, the G4 Cube), or have very strong nostalgia value (the Apple ][+), but some of the others are sort of interesting but I’d still kind of like to explore the possibility that they can still be actually used for something.

As a sort of prerequisite to that, there are a couple of considerations. One is that if they are going to continue to work, they need to not have dead hard drives, and they will also probably need to connect in some way to the modern machines.

For the most part, I think I will probably run the old machines on the operating system they shipped with, or at least not with the absolute maximum operating system they can support—the newer the OS, the more demanding it will be on the hardware and the slower the experience will wind up being. Which will mostly guarantee that I wouldn’t use them. Plus, at this point, capabilities are not as much an issue as usability—if there’s something that the LC II can’t do because it’s running too old of a system, the next computer over should be able to do whatever it is.

One concern I have about operating these machines in the modern world is that they need to have access to large storage, preferably replaceable large storage. There are a couple of categories of problems to address here. The oldest of my machines, the Apple II series computers, didn’t ship with any permanent large storage, but primarily used 140K floppies. It was possible, however, to buy hard drives for these machines. This was all done with expansion cards, and the earlier operating system (DOS 3.3) was pretty limited anyway in how large a space it could keep in mind at one time, so larger storage had to be split up into “volumes” since the largest disk DOS 3.3 can imagine is 400K. The newer operating system, ProDOS, can see partitions up to 32M, and GS/OS (which I can of course only use on the IIgs) allows up to 2GB partitions. These are of course laughably small data spaces by today’s standards, but of course one doesn’t need a lot of space for the software to run these old machines. So, with respect to “authenticity,” I think it’s fair to say that, since hard drives were made for these machines, introducing a hard drive (or something that works like a hard drive) retains the authentic experience. And, really, I don’t have much nostalgia for constantly swapping floppy disks, having bad sectors crop up, etc.

For these systems, there are a few different modern solutions that involve using Compact Flash cards in newly creating interface boards, and this seems ideal. First of all, CF cards are cheap and they have no moving parts. The only problem I foresee here is that finding CF cards small enough might wind up being a problem in the future. But, even if one were outright given to me, I’m not sure I’d want a true vintage hard drive for these machines. First of all, hard drives just fail. Using a 25-year-old 20MB hard drive is likely to very soon lead to tears. And while it’s working, it’s going to be loud. The CF card solutions, on the other hand, use a medium that’s modern enough that it’s trivial to connect them via a USB CF reader connected to current Macs (or even to the built-in SD reader in my MacBook Pro, though I haven’t yet been able to locate such an adapter). Which solves one of the other big issues with working with the vintage hardware: getting data in and out of them. I plan to eventually put CF drives in all of my Apple II-era machines. I’m eagerly awaiting the second run of the CFFA3000 card, which I will certainly get at least one of. I’ve already ordered a Focus IDE HD + CF controller card, I’m just waiting for it to be built (currently I’m guessing it’ll still be a couple of weeks away). Another option in this realm is the MicroDrive IDE controller, and perhaps I’ll consider getting one of these too, just to compare them. These are not an option for the //cs and //c+, but for my three ][+-type machines, my //e, and my IIgs, one of these storage options will really make it much more likely that I’d actually use them.

One complication in the Apple II area is that many disks were actually copy protected, to make it difficult to just hand around copies to all of your friends. This led to a pretty active cracking scene, and most things were reverse engineered or imaged in various ways that led to copyable versions, although this means that the only way you can run a lot of these programs/games is to use the version with the crack screen. And also, some things could be copied using specialized copy programs (Copy II Plus, Locksmith), but the resulting copy was still just as copy-protected as the original. The issue with all of this is that in the context of a hard drive that is supposed to have the contents of many disks on it, there’s a large chunk of the software that simply can’t be used that way. The only way to use these things is to boot the floppy disks. The CFFA3000 does have some compatibility with “nibble” images, but it is still stated as being incompatible with protected floppies. I’m not sure what the best solution to this will end up being. It might really be that the best solution for these is to just use real floppy drives, but for everything else the hard drive will be a big help. There’s a considerable cost, of course. The new cards are all in the region of $150, which is in many cases more than the entire machine is worth to an ebay audience. But the usability improvement probably justifies it. I also like the CF solution better than a real hard drive solution because CF cards are cheap to replace and easy to read/write on modern machines, and even though CF drives do have a limit on the number of writes you can do to them, the Apples II are not likely to come anywhere near those limits.

This does still leave the //cs and //c+ out in the cold, however. The options here are really limited. The compact form of these machines means that there are no expansion slots in which any kind of CF or hard drive card could go, and there is no external connector other than the serial connections for the printer and modem. Given that there is also no AppleTalk, they’re really stuck with floppy disks, possibly transferred over with ADTpro, but still ultimately stored on floppies. The //c+ is capable of using 3.5″ floppies, but at least two if not all three of my //cs are ROM 255 versions, which did not have support for 3.5″ drives. The best I could hope for here, really, would be some kind of front end file transfer program that could bring in a program over the serial port from a hosted catalog (like what ADTpro does) and then run it in place (ADTpro only allows for downloading disk images to be written to physical disks). As far as I know, there is no hardware solution available to the //c that can get me any closer than that for larger non-floppy storage, and the serial loader I’m imagining here probably has yet to be written.

There is a similar issue once we get to the older Macs, at least with respect to the life expectancy of the internal hard drives, though at least these all shipped with hard drives installed and know at least something about how to deal with them. The oldest Macs I currently have are three SE/30s and an LC II, which originally shipped with an 80MB SCSI hard drive. That’s a small hard drive. If the internal drive fails, which it will surely do at some point, finding a drop-in replacement will not be easy. Furthermore, the OS prior to System 7.5 had a limit of 2GB that it could see. But even a 2GB SCSI drive is going to be hard to locate. CF cards, on the other hand, quite easily get to 2GB. A CF card in a Mac worries me a little bit more than in an Apple II, because it’s more likely to start using swap space for virtual memory, and so more likely to hit the write-limit. But artmix on ebay (the manufacturer) currently sells some SCSI CF card interfaces, and I might just go for some, at least to try. Advantages I see here primarily is that even if the CF card dies, it’ll be much cheaper to replace the CF card than it will be to try to replace an actual hard drive. And, I can periodically, if I so desired, crack open the Macs and take out the CF card to transfer data to/from them or back them up (although this doesn’t sound like a great idea for the SE/30s. The hard drive in the LC II is trivially accessible, but in the SE/30 the hard drive is tucked away under some hardware that would need to be removed before I could get at the CF card inside. I guess I could get something like this SyCard CFextend 182E and position the cable in some way so I could get at the card without disassembling removing the video board, but the thing costs over $100, so I’d have to be really sure I’d actually want to change the card often).

Once we get to IDE Macs, such as the G3 and G4 iMacs, we start getting into Mac OS X territory (potentially, though as I stated at the outset, I’d probably be running Mac OS 8 or Mac OS 9 on many of them), where disk access gets even more intense. An option here is to just get a SSD drive like the OWC Mercury Pro Legacy, but they are expensive too. They’re likely to be more resilient for this kind of use than a CF-based solution, but if they fail, an entirely new drive is required. And the ability to just extract the “hard drive” to read on a more modern machine is lost. Also, on these early Macs, the first partition of a big drive has to be no larger than 8GB, and the whole drive can’t been seen past 128GB. And even those are pretty small to expect to find these days. I think the 1MHz iMac G4 can see bigger drives, but I don’t think the earlier ones can. The MDD Mac is supposed to be able to.

Of course, the expense here starts to pile up. In the case of the Mac machines, I may well hold off replacing their hard drives until I need to do so, since many of them do have working drives in them. For those that lack hard drives altogether, though, I may consider some of these CF or SSD options.

On to the other main obstacle I can see in making these older machines usable, which is connectivity. The newer Macs have ethernet capability and, some have Airport capability, so I will probably try to ensure that those connect in the modern way. I even have an ethernet card for one of the SE/30s, but I’m not sure how useful it will be. I do not anticipate putting an ethernet card in the LC II, because it has only one PDS slot, and that slot is reserved for the Apple IIe card. Most of the older Macs can speak AppleTalk, so I expect that I’m going to try to set up a small AppleTalk network among those machines so that they can talk to one another. And, the IIgs should also be able to participate in this as well, since it has both the port and the ability to use AppleTalk in ProDOS and GS/OS. None of the prior Apples II have AppleTalk ability, although an enhanced //e can use a Workstation Card to get on an AppleTalk network (and I am not sure at the moment whether my //e is enhanced or not).

The connectivity of the Apples II is most in question at this point. I have modems for two of them, although they don’t really have anyone to talk to over the phone line these days. I suppose it’s possible that if I could get them to ignore the lack of a dial tone I might be able to get them to talk to each other, though it seems a little bit silly. Still, I have these programs written for the Apple Cat that it might be nice to see running again, but it would require a second Apple Cat and I’m not sure that it wouldn’t actually require two phone lines as well, since phone lines did provide some power that the modems may be sensitive to (meaning that just running a phone cable from one modem to the other directly most likely won’t work). I might be able to rig something up if I ignore those modem cards and convince the Apple II that it’s talking with an external modem over a serial connection when it is actually talking to one of the Macs, emulating a modem. I can’t have been the first one to think of this, some kind of solution like this may well exist out there. This would require getting Super Serial Cards for the //e and ][+es, but they are still pretty cheap and plentiful at the moment. Though I might also want to stop and ponder what exactly the connectivity is useful for, too, in these cases. The Apple Cat is capable of turning things on and off (I think—I have the expansion card that allows for this, but I’m not sure that I have or can easily get the right interfaces that would get it to an actual power outlet), so perhaps if I could make the machine with the Apple Cat in it to be somehow addressable on the network I could get it to turn things (e.g., neighboring computers?) off and on. (That would be excellent if I had it set up so that if my modern office iMac freezes badly [as it sometimes has due to some kind of lockup of the Firewire ports], I could send a signal to the Apple ][+ and turn the iMac off and on again.) The biggest file transfers will probably really happen via CF cards, though, not serial connections with the modem port. So, what else would connectivity buy me? Mainly just the ability to save small, incremental files (perhaps for use in a disk image) somewhere they could be retrieved without pulling the CF card. And so maybe it isn’t really worth it, though I have to say, the thought of an unconnected computer does really make it feel isolated and lonely.

But on to the plan, what could these things be useful for? I have pondered the possibility of using the iMac G4s for art, and writing a screen saver that runs on all 6-7 simultaneously, but that doesn’t really seem useful. However, I think there is just no way that I’m going to be able to come up with something that six machines will be useful for. Perhaps I can get some form of XGrid working on them, so they can look for extraterrestrial signals or compute fractals. Maybe if I can get a fast enough connection with them going that screen sharing is possible, such that it’s effectively six extra monitors of some sort. Even if they aren’t actually sharing the screen, it would be easy enough to put PDFs I’m trying to read up on them, and they are pretty compact. The SE/30s are capable of running A/UX, and maybe I’d set one of them up running that, or, more likely, NetBSD. Once I’ve done that, the ethernet-connected one can be a little server of some kind. Though the strength of these old machines is not going to be found in fast transfer of large amount of data, it would need to be something useful that it could do just kind of directing traffic or handling low volumes of text. Apart from that, some of the vintage machines can be used to run games of their era that no longer run on newer machines—although I don’t really have much time to play them. Microsoft Word 4.0d or 5.1 is probably really super-fast under System 6, there might actually be a use for that, except that I don’t tend to use Word, and I have to be able to get the resulting files over to a modern machine.

I think there’s some work to be done here to try to find actually useful things that these old computers can do. I’d like to think of something clever that they do better than modern machines, though I suspect much of it will just revolve around interacting with other vintage machines in a way that modern machines no longer support.

Writing drivers

I started piling some of my imaged disks onto a big ProDOS volume for use with Virtual ][, using Glen Bredon’s DOS.MASTER, since nearly everything I’d ever done was in DOS 3.3. In the process, I came across an old text file I’d written called “Writing Drivers“. Click the link if you want to see the whole thing, but it had an interesting bit of history in it concerning the Epson QX-10. I don’t know when I wrote this, but it would have been around 1985 probably, apparently it was five months after I bought my Novation Apple-Cat ][. But, here’s some of my QX-10 cred—something that I feel a bit compelled to provide, since I (unintentionally, honest!) scooped this QX-10 from @retroearl of the Retro Computing Roundtable. The first RCR podcast to air after I bought it (but which was recorded before) contains a bunch of heartbreaking discussion of how much he wanted it and how cool it was. (Sorry! Sorry!)

But, anyway:

When I started out, i had an Epson
QX-10.  They are business machines that
run CP/M and are not quite IBM
compatibles.  Since then, Epson has
come out with more in the QX series,
and the 10 is pretty much obsolete.

Anyway, it had a Comrex ComMunicator
modem, and one example program in
Microsoft BASIC.  I took the challenge,
and developed my first "driver," if
you can call it that, in Microsoft
BASIC on the Epson.  I continued, and
developed an entire board.  Shortly
after, however, I had to return the 
QX-10 to work, since I was borrowing it
from them, and they needed it back.

Because of that, i got more interested
in modems in general, and borrowed an
old acoustic modem (compatible with
the "Networker") from the school.  In
high hopes of buying an Apple-Cat, I
developed BBS software, and a machine
language driver for the networker.

Finally, about five months ago as of
the time of this writing, I got my 
Apple-Cat and converted my driver to
work with the Cat.

Success with ADTpro was surprisingly good

I took a shot at imaging some of my 5.25″ Apple floppies from the mid-80s today, using ADTpro talking to my IIgs over the modem port connected via a Keyspan dual serial adapter (driver here) to the USB port on my MacBook Pro. Two bits of good news to report: it’s actually quite quick, and it seems to be pretty fault-tolerant. ADTpro managed to read about maybe 70% of the disks I gave it without errors on either the front or back sides, which either means that ADTpro is good at retrying read errors, or that the floppies were still in pretty good shape. Many of the errors I encountered were actually ones I remembered, disks that had developed errors back when they were being used. I’m hoping that my Kryoflux, when it arrives, might be able to reconstruct some of those wayward bits as well.

Anyway, I imaged most of my highest priority floppies, mostly source code and experiments, not many of the games that already exist in disk images on the internet somewhere, but I intend to finish this first pass through the rest of them pretty quickly. The Kryoflux is not well suited to imaging the flip side of these disks, so I’m glad that the Apple is able to read most of the flip sides.

Among the things I had that I’m pleased still to have access to (because of how 1337 it makes me) is the source code to Cat-Fur. I forget the specifics now of how I acquired it, but I believe it is The Micron’s actual Cat-Fur 3.1 source code (uncommented, but with enough symbol labels that it probably isn’t just a disassembly of the binary file). I wrote a number of Cat-Fur modifications myself, which perhaps I’ll document here at some point. Cat-Fur was a huge part of my BBSing experience, but oddly it seems to have almost no representation on the internet of today, so if you don’t already know what it was you don’t have a very easy way to find out (it was a modem-specific file transfer program, designed for the special capabilities of the Novation Apple-Cat ][ modem, which had the ability to transfer at 1200 baud, but only half-duplex, so a complex handshake system was needed in order to permit two-way communication.).

Catfur src snip