Four Colors Into Sixteen: Terminal Innovation on the Atari ST

I’ve been spending a lot of time in the growing telnet BBS world lately and it’s really been a blast. I’ve been “dialing” in to my favorite BBSs by way of Paul Rickard’s WiFi232 Internet Modems (which I covered in a recent post). So far I’ve used my WiFi232s on five different systems. Among them is the Atari 520ST.

I purchased my first Atari ST back in the fall of 1986. Shortly thereafter I added an Atari SX212 1200-baud modem (my second modem, after the Prometheus ProModem 1200A on an Apple IIe) to the setup. The only terminal program I had ever used on the ST was ST Talk, a rather basic VT-52 terminal emulator program. When I reached for my 520ST to use with the WiFi232, I figured there was probably a more full-featured ST terminal program out there, so I did a YouTube search for people using the Atari ST as a serial terminal and found someone demonstrating the WiFi232 using a program called TAZ. What caught my attention was the fact that it supported ANSI emulation (with the IBM extended character set) and, more impressively, seemed to do so in 16 colors in the ST’s Medium Resolution mode. Medium Resolution on the ST is 640×200 pixels, which can display 80 column of text, but in only four colors (out of a palette of 512 colors).

So, how was it displaying 16 colors?

The Atari ST can display 16 colors onscreen in Low Resolution mode, which is 320×200 pixels, but not in Medium Resolution. So, I left a comment asking the poster what was going on. He responded, saying that the 16-color display was achieved using dithering.

Well, it didn’t look dithered; it looked rather sharp. So, I downloaded TAZ, put it on the SD card that is my 520ST’s floppy library (thanks HxC2001) and fired it up. As soon as it loaded it became clear what the developers had done here, and it was impressive. I logged into an ANSI graphics-heavy BBS and was blown away by the accurate and colorful ANSI display.

TAZ, by Neat n Nifty software circa 1994, does not use dithering in the traditional sense to achieve 16 colors. But it does use dithering of a sort — it uses what you could call temporal dithering. TAZ alternates two different palettes every frame. That means that, on a 60Hz display, TAZ‘s 16-color terminal screen is effectively 30Hz. You would think that this would introduce substantial display flicker — and you’d be right! It flickers notably but, amid the flicker, what is achieved is a very usable, 16-color ANSI terminal running on a machine limited to just four colors onscreen at a time. And the font the developers chose is particularly nice, as well.

As you can see in this quick and dirty video that illustrates the technique, white text, for instance, is generated by an alternating shade of red and blue, both colors carrying some level of green. As those colors swap in and out 60 times a second, your eye is tricked into seeing the average of the two colors. Yellow is formed by swapping out shades of red and green, and so forth. Pause the video a few times during the high framerate sections to see what’s happening more clearly.

I have seen similar approaches used in a few other places over the years, the first being the early Atari ST game, Megaroids, an Asteroids clone. In Medium Resolution mode it does a color swap every frame to smooth out the details of the asteroids and to provide a degree of anti-aliasing for the player’s ship. The second example I encountered was also on the Atari ST, in a paint program called Quantum Paint which achieves up to 4096 colors onscreen by swapping palettes every frame in Low Resolution, 16-color mode. Over the years I have run across several scenedemos that achieved effectively higher color depths using this technique, as well.

Of the systems I’ve used with the WiFi232 units, my Amiga 1000 with its true 16-color, 80-column screenmode is probably the most capable machine for color BBSing, but the cleverness of TAZ and the quick startup time of the Atari with its HxC2001 has made the 520ST my go-to BBS machine at the house, for the time being.

A big part of the enjoyment that I experience using these vintage systems has to do with what they are able to achieve with such extremely limited resources as compared to the technology of today. Seeing a system actually pushed beyond its set capabilities, so to speak, is an incredibly satisfying thing.

This entry was posted in Atari, BBS, Serial Terminal. Bookmark the permalink.

5 Responses to Four Colors Into Sixteen: Terminal Innovation on the Atari ST

  1. Götz says:

    Interesting stuff. How’s password entry over plain-text telnet implemented? Any encryption or proper authentication possible?

  2. I was reading articles and clicked and.. there’s my BBS! That’s awesome, thanks.

    And the BBS he’s dialing into… it’s 8 bit. It’s all plain-text and non-encrypted, pretty much how it should be in 1997.

  3. Pingback: Modern-Day BBSing on the Epson PX-8 CP/M Laptop, Circa 1984 | Byte Cellar

  4. MarkP says:

    It’s weird how effective that trick is, even though it should be a horrible flickery mess much like most other attempts at field-sequential colour that operate slower than e.g. the 180+ fps of a DLP projector utilising the technique (and even those tend to switch more frequently and with higher precision using a seven-segment colour wheel – the primaries, secondaries, and white – to improve brightness and reduce flicker / colour trails). Presumably the phosphor afterglow, which appears to be fairly long even at 240fps, helps paper over some of the gaps. Also the use of red, green and cyan is a bit strange … I mean, you need that to be able to show both yellow and white without the latter being a somewhat low-intensity grey that suffers a lot of flicker by needing three frames to appear, but I do wonder how the primary blue visible on one of the screens is produced… and also how it would treat magenta?

    Maybe it’s that it is actually completely changing the palette on each frame (maybe even line by line, and by that I don’t mean row by row but every scanline, which lets you do some vertical as well as temporal dither, and is a technique I’ve seen used quite effectively on the Oric and even the CGA PC), rather than just flitting between two screenbuffers with different pixel patterns in, and there are six different colours that can appear and mix, plus the fixed black background… between them you might be able to come up with a reasonable facsimile of the ANSI 16…? Especially if dithering vertically you could still manage the already-dithered characters of the standard set by reducing their own dither to vertical bars, though maybe they would still work OK with the technique anyway?

    Still got an analogue modem in the back of the cupboard so I might have to get an image for that program and dial into a surviving BBS with my own ST when I get it working again, just to witness the effect. As well as Megaroids of course – as noted on its own post page, I’m part skeptical, part extremely curious about what’s actually going on there. It’s not palette flickering but swapping between the halves of a double buffer, that much is fairly plain, but beyond that it’s a bit of an enigma … does it actually interlace, or is it simply going for a bit of temporal anti-aliasing because the roids themselves eat up the palette entry that would otherwise be used to simply draw a pre-smoothed sprite?

    (FWIW, Quantum Paint is one of the few high-colour programs on the ST that actually does flicker between palettes, as its claim to fame was, in an era before Photochrome and various other super high colour demos, achieving “4096” colours – actually more like 3200 or so – on an original ST rather than an STe… but, it only did that to increase the colour palette depth, its more-colours-per-line, new-colours every line technique was much more mundane and similar to other programs like Canvas, Neochrome Master, Spectrum512 and indeed Spectrum4096. Those ones just swapped palettes without any interframe flicker, either line by line, or across the course of each line, throwing fresh values into the shifter’s registers as fast as the CPU (and later, blitter) could manage… mainly picking from just the regular 512, with Spectrum4096 being STe-only and still only using the static hardware-provided colours. IIRC Photochrome was the groundbreaker that combined the two techniques to give more than 48 colours per line as well as an extended master palette)

    It’d be interesting to see what a modern attempt at the same idea might be like; whether it might be possible to bring in some intra-line palette swapping to try and make as many changes as possible across a line (48 across, or maybe more like 40 in medrez when really pushing hard, might be enough alongside vertical dither and variation in where the actual swaps take place, as well as temporal dither, to give a much more convincing, genuine provision of 80 unique blocks of both foreground and background colour with less flickeriness and closer matching to the originals; and in any case, IIRC true ANSI only has 8, low intensity BG colours vs 16 foreground, so that opens up the possibility of vert-dithering with black and/or complementary colours to fake it more convincingly), maybe with a bit of border opening to use a wider font (9 or even 10 pixels per column would be possible, depending on how much overscan your monitor can handle) and get as close a match between colour switching frequency and the character rate…

    Alternatively, a different tack a bit like that used for word processors on 8-bits that didn’t have 80 column modes or cards available. Set it into low rez but use deep overscan; 400 pixels width isn’t a particular challenge for demo writers these days (in fact they can manage about 412, but those from about 404 to 408 are blanked out by the most common “stabiliser” techniques that prevent the opened borders on one line causing the next line to be garbled), and that would allow us 80 columns with a 5-pixel wide character cell, which is just about enough to be readable with a bit of finagling of the character set (some of the 8-bit “compressed” modes even used 4 pixels, though that’s really pushing it for legibility). And we can then just set and forget the colour palette. I wonder too whether it might be possible with some clever hackery to effect a half-pixel horizontal shift (find some way to write an odd number of medrez pixels then shift back to low? I have a feeling there’s a hundred reasons why that wouldn’t work, though) and use that in conjunction with double buffering to do a bit of semi-flickery *horizontal* antialiasing of the text?

    To my knowledge no-one’s tried anything like that… but it sure seems like it would be worth a go.

    Another idea I had myself ages ago was that… it strikes me that the missing shifter mode really should be a “/3” one. High is /1 (the 32MHz input clock is divided by 1, and the shifter cycle is reading in one word then shifting it out as 1-bit pixels), Medium is /2 (32MHz becomes 16, and two words are read in then shifted out as 2 parallel bits to a pixel), and Low is /4 (…I think you get the idea). On colour monitors the same ~40us active period ends up containing 320 or 640 pixels; on a mono one, only 20us is active, and again has 640 pixels (which is another argument against the possibility of a 640×400 interlace mode; it would work entirely differently to everything else, instead of just being the mono clock on a colour screen… which would itself instead create something like the Amiga’s hopeless SuperHiRez 1280×200 mode). Three of the four possible mode settings (using two bits) are accounted for, but there’s an unused slot. The input clock is fixed at 32MHz, you can only – with that generation of tech – divide by integers, the internal shift registers are only four “lanes” wide (with medium and mono using just 2 or 1 of them), and there’s only 16 colour registers anyway. So … why not a ~10.6MHz, 3-bit-pixel mode? The resulting horizontal rez is a somewhat inconvenient 426.67 pixels if we keep the exact same clock, but there’s no reason that we need to do that. For convenience it’s best if the width is divisible by 16 (our 3-word blocks are going to be 16 pixels wide because of the memory architecture, and the memory *access* cycle runs every 5.33 pixels (x3 = 16), as a read takes two CPU clocks and can only happen every four clocks, which are themselves divided by four from the 32MHz crystal). Timing is weirded a bit in terms of matching pixels to clock cycles across each line, as one CPU clock is no longer 1, 2 or 4 pixels but 4/3rds, so it’s maybe best to think in blocks of 12 clocks which are the smallest that we can reliably time and conveniently also 16 pixels wide (or in other words, just the same as how things are in hirez). The oddest thing being that line length can’t now easily be a free choice of x4 or x8 pixels (or x4 clocks) as it technically was for low and medium, but has to be x12 to not waste CPU cycles (or if we take the Amiga model of halting the entire system for between one and three clocks at the end of each line to “correct” the timing, we could have x6 or even x3 pixels, as well as even freer choices in low and medium). The 512 and 508 cycles of PAL and NTSC are no longer possible; the closest we can get are 516 or 504, which messes up the line frequency somewhat, though 504 with the early ST/STe crystals isn’t even as high as certain Japanese computers routinely ran their “15khz” modes at, and 516 with the later TT/MSTe crystal is easily close enough to ISO-PAL frequency to still work. If instead the timing is jiggled a bit to allow a x6 pixel count (maybe the CPU gets an extra 2 cycles it wouldn’t normally enjoy and the video system is paused, or the CPU is just halted for ~0.2% of the time, or that slack bandwidth is reserved for refresh, audio DMA, floppy DMA, blitting or any of a whole bunch of things down to and including a single 1bpp 16-pixel wide sprite…) we can get 510 clocks.

    Anyway, that’s bogging down in the minutiae. Upshot being we can have a minimum of 400 pixels within the normal underscan area in that mode, giving us the 5-pixel/80 column setup without any special tricks, and 8 colours to use likewise. More likely you’d go for 416 or 432 which are a little either side of normal width (equivalent to 312 or 324 low-rez pixels), and the latter allowing a variant terminal standard of 72 columns at least with a 6 pixel font. But really, if you’re reengineering the shifter at the last moment to fit this mode in, what you’d want to do is make it 480 pixels wide (equivalent to 360 low-rez). Which with a 10.7MHz clock is almost exactly as wide as the Amiga’s 320/640 pixel modes using its 7.1/14.2MHz clocks, so it would fit nicely within the limits of a typical monitor or TV, and not be so finely pixeled as to lose clarity on most of them. And with a 6-pixel-wide font, a little coarse but not the most unusual of things, there’s your 80 columns. In 8 colours, which is compatible with at least a lower flavour of ANSI. And I fancy it wouldn’t be too hard to come up with a colour switching and/or per-line dithering/palette swapping routine that could make a much more convincing, stabler facsimile of the 8-and-16-colour standard if indeed not the full 16-and-16 colour extension possible with CGA.

    Plus it’d be pretty good for other serious software. Word processors, DTP, etc. With the palette set to primary colours and liberal use of dithering you could retain reasonably good resolution as well as being able to simulate any given colour, even make a somewhat rudimentary stab at representing photographic images, as a sort of (5+ years earlier) stepping stone towards what was done later with 16 colours and somewhat higher resolution in standard VGA mode across a whole generation of Windows PCs and their software, or even the earliest Mac IIs/LCs. And unlike 640×200 mode with 8 or 16 colours on the Amiga, there’d be no slowdown (using more than 4 colours at that rez, or 16 at 320×200, steals cycles from the CPU and slows the processing down even further vs its already reduced rate compared to the ST). And it’d be fairly good for converting all manner of things from e.g. the NEC PC88 and PC98 which started out with 640×200 / 640×400 modes in 3-bit RGB (fixed as primaries, not even being able to set the colours independently at first… something actually shared with a lot of late 80s upgrade graphics cards for the PC, too… 8-colour modes often featured alongside 16s and 4s, and if you were on a TTL monitor usually that meant 1 bit for each of R, G and B…). Just have to reduce the horizontal rez somewhat. Maybe increasing the vertical a bit with simpler software overscan tricks to compensate – 480×224 would be reasonably possible on NTSC and 480×272 (same as the PSP, not far off the Mac’s actual resolution but with “full” colour, and about a quarter FullHD in each dimension, using just under 48kb…) for PAL…

    At the same time it might have been possible to put a normal/wide switch (and a normal/tall one?) in for all of the modes that could extend them out as wide as that… 720 for medium and high, 352 or 368 for low (360 doesn’t divide into 16… though you could maybe just ignore the last 8 pixels entirely or co-opt the difference for smoothscroll purposes?), eating a little extra screen memory in order to better fill the available horizontal width without quite overscanning… and without need for complicated, performance sapping software border-opening tricks… (480 would drop down to 432 instead in “normal”, I suppose – 432×200 in 3bpp still comes in under 32kb; and similarly 200/400 lines could increase to 240/480, without actually needing interlace… 240 being a bit of a compromise to ensure multiregion compatibility even though it would be decidedly overscanned in NTSC and need programmers to take care to centre their must-be-visible content, whilst still being decidedly underscanned in PAL… maximum memory take still wouldn’t be massive, just a touch over 43kb, which kinda begs the question of why didn’t they implement that option in the first place as it would be barely any more logic gates for a very useful set of functions, and the extra memory take would have been tolerable even with a 128kb machine, especially as the regular just-under-32kb modes would remain the default)

    Might have helped the machine hold its own a bit better against the Amiga, PC and Mac, getting a few more sales at its height and lasting a little longer in the market, especially if they extended the functionality somewhat in the MegaSTe to build on that and maybe do the same rez with 64 “direct” colours (or 16 register entries plus 48 shadow/highlight/inverted ones…? Or 4x4x3 direct plus 16 custom… and medrez in 16 colours, high in 4 colours or 1280×400 mono – more useful than the Amiga equivalent especially with the crispness of the mono monitors, maybe upping the tube size a bit too – and lowrez with 256 direct colours (8x8x4) or some kind of other trick mode e.g. 6x7x6 plus 8 custom colours out of the 4096, or 6x6x6/6x8x5 plus 16 custom…) with the memory, MMU and shifter accelerated x2 as well as the CPU… Ah, what could have been, just with some small changes in what decisions were made at certain crucial points…

    …also a shame more use wasn’t made of the cartridge port, especially for standalone games. I guess Megaroids’ “thing” was that it ran under GEM, so for the early machines you *had* to load it from disc anyway, but I’ve seen a few conversions of games (generally older ones, but not exclusively – the only crucial thing, unless you want to roll your own “mapper”, is that they can be made to fit within 128kb and their files arranged within the cart’s not-quite-DOS virtual filesystem) to cartridge images that can be run in emulators or burned to EPROMs and stuffed in a homebrew cart and they work quite well, with some surprising entries amongst them – Xenon, for example, which probably could have worked very nicely as a standalone cart on a discless 130ST. Megaroids might also have managed similar, with the bare core GEM routines it needed to run its menu system included amongst the code, or just converted to have a simpler, more conventional game menu that could be navigated with joystick or just keyboard meaning all you’d need to be able to play it on an (130?)STM would be the computer, power supply, TV plus RF cable, and the cartridge…

    (which thought is now annoying me by reminding me that I still haven’t been able to find our old FaST BASIC cart … I wanted to plug it in with the STF’s internal floppy disconnected – which if you power the machine up like that and without an external drive gives a near-instant GEM desktop but with no icons other than the trash – and see if the cartridge icon automatically appeared and if anything could be run from it… the thing still wouldn’t have been useful without either TOS ROMs or disc TOS plus a disc drive anyway, I expect, but it’d be interesting to try out and see what might have been the original intentions…)

  5. MarkP says:

    (oh wait … the BBS is over Telnet … OK, that probably makes things easier … I have no wifi adaptor for the ST, but I do have a USB-serial converter and a 9-to-25 null modem cable I can use to hook it up…)

Leave a Reply

Your email address will not be published. Required fields are marked *