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:

Apple II	ANSI
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.

█ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ ▄ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ P O I N T S P E P A D D L E L E

█ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ P O I N T S P E P A D D L E L E

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ P O I N T S P E P A D D L E L E

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."