Hearing from my software heroes

Using the terminal program "ANSITerm" within the "Hatari" Atari ST emulator to write a message on a BBS.

Using the terminal program “ANSITerm” within the “Hatari” Atari ST emulator to write a message on a BBS.

I spent much of my teenage life inside the confines of the Atari ST terminal program “ANSITerm” by Timothy Miller of Two World Software.

I have mentioned the program before on the blog, and I even described it briefly when I was a guest on the Bobby Blackwolf Show podcast. But I’ve never really given it its due.

Well, Timothy Miller found one of those little mentions from last year (in my post Emulation is Time Travel) and he left a comment.

That is amazing to me. Twenty years after my Atari and BBSing heyday, I now have comments on my blog from the three software authors whose products probably meant the most to me: Miller (ANSITerm), Amit Patel (Solar Realms Elite), and Eric March (FANSI).

So, what was ANSITerm? It was a terminal program for the Atari ST with a killer feature: it emulated the PC’s 16-color “ANSI” mode.

The Atari ST could only display 4 colors in its 80-column medium resolution mode. So to perform this nifty trick, Miller designed ANSITerm to run in the Atari’s low resolution mode, which supported 16 colors. Since it was low resolution, he created his own 3-pixel-wide font with all the PC ANSI pipes and shaded blocks.

I got my start in BBSing on my 8-bit Atari 130XE using “BobTerm.” But I quickly outgrew 40 columns and 300 baud, and I took over my dad’s 520ST. I tried terminals like VanTerm or Freeze Dried Terminal (FzDT was particularly nice), but none of them could deliver the genuine PC ANSI experience.

My BBS dialing directory in the terminal program "ANSITerm" for the Atari ST.

My BBS dialing directory in the terminal program “ANSITerm” for the Atari ST.

Once I found ANSITerm, I was hooked. I used that program for about 8 years until I finally sold my Atari computers.

How much time did I actually spend using ANSITerm? I’m not sure, but I did spend many, many, many hours BBSing as a teen. And if I was BBSing, I was in ANSITerm.

ANSITerm let me write macros, which I used to add custom ANSI signatures to the bottom of my message board postings. It also had a capture buffer, which I sometimes used to save SRE messages, or emails from friends. Unfortunately I didn’t have a hard drive at the time, so I was constantly deleting or overwriting these; only a few have survived to the present day. I would also use the buffer to learn a little bit about ANSI and VT-52 and the codes that made the artwork work.

My Atari ST desktop, as seen in the Hatari emulator.

My Atari ST desktop, as seen in the Hatari emulator.

So, thanks, Tim, for writing ANSITerm all those years ago. I got so much out of it.

And I know people are still using it today to call BBSes. In fact, last year I learned how to use it inside of Hatari to telnet to present-day BBSes!

The FANSI title screen

The FANSI title screen

Now, I have written at great length about what Solar Realms Elite meant to me, and I have even interviewed Amit Patel, so I won’t add to that today. But Amit’s work also meant a lot to me. I spent hours playing SRE, and it sparked my imagination enough that I began writing stories based on it.

But what about FANSI? I have also mentioned it on the blog in the past, but I’d like to say more about it now.

What ANSITerm was for calling PC BBSes on the Atari ST, FANSI was for creating ANSI artwork. FANSI was a 16-color ANSI art editor, and March used the same low-resolution, custom font trick as Miller used with ANSITerm.

I was mesmerized by the amazing work that came out of the ANSI art scene, or by the fancy logon screens I would find on some local BBSes.

I wanted to try my hand at it, and FANSI was a good place to start: an ANSI editor that ran natively on my Atari machine. The only alternative was to fire up the PC-Ditto emulator so I could use “TheDraw,” which was the gold standard for ANSI art. But that was slow.

I never become any sort of ANSI artist, but I did spend a lot of time creating advertisements for my favorite BBSes (particularly “Something in the Attic” and “Flash”), and also advertisements for my aforementioned SRE stories. And I did it in FANSI.

FANSI saved files in its own .FAN format, but would also export traditional .ANS files. It also had pretty spectacular intro and outtro screens/animations. I wonder how much time March spent putting those together.

March mentioned in a comment on the “Emulation is Time Travel” piece that big plans for FANSI upgrades: font and shape libraries, layers, and such. It’s too bad they didn’t come to fruition, but it’s also not surprising. The Atari ST was a dying platform, and BBSing was a dying hobby.

An ANSI advertisement for the Toronto Atari Federation, as seen in the FANSI editor.

An ANSI advertisement for the Toronto Atari Federation, as seen in the FANSI editor. This ad was bundled with FANSI as an example of what you could create with the program.

Again, thanks Tim, Eric, and Amit for all you contributed to my teen years — and for visiting this blog!

3 thoughts on “Hearing from my software heroes

  1. Eric March

    Hi, Josh! Great post. ANSIterm was in fact the inspiration for FANSI. We had a good full-colour ANSI terminal program, but the only native ST applications — and there were two that I was aware of — to make ANSI screens were in medium res, and therefore limited to 3 colours. So I wanted to correct that. A few little tidbits about FANSI:

    – FANSI debuted in, I think, July 1994 at the Toronto Atari Federation meeting (hence the TAF screen I bundled with the app — I wanted something personal to show off to TAF members). It was demoed on the club’s Falcon030, the only Atari machine that could be hooked up natively to a digital projector. The demo went quite well — lots of oohs and ahhs. I was actually in development right up to a couple hours before hte meet, with the last hour before I left spent making copies to sell at the meet. I didn’t sell any — nobody at the meet was into designing ANSI screens. 🙂
    – The 4×8 character set used was literally ripped directly from ANSITerm. I figured it would be easier than doing it myself. (Miller was okay with this.)
    – The UI design was inspired by the art application CrackArt, which is what I used to design the UI.
    – All of the dialogs were created from scratch. I wanted a unified design, and it always bugged me from an aesthetic point when a nice-looking application used the system file selector or other drab built-in UI elements. That did draw a few complaints from people who would have preferred using UIS III or similar, but those wouldn’t support custom search mask buttons, so I had to design my own.
    – The method I used internally to create the registration key was based on the syllabic password system for getting through the laser doors in one of my favourite RPGs on the ST, Captive, by the awesome Anthony Crowther. I even used many of the same pre-defined syllables, but also added my own.
    – The icon presented on the dialog box when exporting to an ANSI file is random; there were about half a dozen of them — sandwich, cup of coffee, cigarette, etc.
    – Speaking of exporting to ANSI, the routine to do that was one of those rare things-just-coming-together moments where it was a big block of code and it actually worked almost perfectly the first time. The only issue was that if the user put anything on the 80th column it would cause unwanted line breaks. The version 1.01 update fixed that by preventing you from accessing column 80 when creating your screen.
    – Speaking of 1.01, one of the more critical reasons I released the update was because I accidentally left a development hook in the application that would allow you to download the unregistered version of FANSI, go to the registration dialog, and press one of the unused F keys to generate a registration key from the serial number. I used this to test the keygen routine and forgot to take it out before releasing it. Oops.
    – The intro and outro took a couple of hours each to design, and maybe another hour collectively or so to code the animations.
    – I made a total of about $250 in registrations. This wasn’t surprising though given that it was a niche application to begin with, combined with the dying platform and burgeoning Internet replacing the good ol’ BBS. It was cracked not long after it was released – surprisingly not because of the leftover development hook; it was actually, properly cracked. I wasn’t surprised though — I expected it to be. That’s life in the software biz. FANSI was mostly a passion project anyway.

    I also just realized that FANSI is turning 20 in a couple of months. Damn, I feel old. 🙂

    Reply
  2. Timothy Miller

    Early versions of ANSITerm couldn’t keep up with 9600 baud. The input buffer would overflow, and data would get lost. Both character rendering and scrolling were just too slow, and both the character renderer and memory copy routines were written in some seriously optimized assembly code.

    The trick for character rendering was to do multiple at once. The ST’s framebuffer was organized in planes. For 16 colors, there would be a 16-bit word of bit 0 (or 3, I forget) from the first 16 pixels, then 16 bits of the next bit plane, etc. This made rendering easy because I could just AND and OR shifted bits from the font into the bit planes, and the combination of planes filled indicated the colors. The trick to speeding that up was to render four characters at a time, aligned, as long as the foreground and background colors were the same for all four. There were enough registers that I could have a pointer to each character, grab a row from each, shift and OR them together, and drop into the screen memory. Among other things, this eliminated a ton of masking and read-modify-writes on the screen and sped up rendering dramatically (more than a factor of four, IIRC). When there were a lot of color changes, it could bog down using the single-char routine, but the VT102 escape sequence overhead slowed down the rate at which rendering was needed.

    For scrolling, I allocated a huge framebuffer and just repositioned the hardware display pointer to scroll. This is why the menu bar flickers when scrolling, because when you scroll, I had to re-render (or copy, I forget) the menu bar down one line. Now, when you finally got to the bottom, I had to copy the visible screen back up to the top, and that took long enough that data could STILL get lost, so I also had to re-allocate the RS232 receive buffer, increasing it to 32K. Another interesting thing: I had to maintain an internal character array for the characters on the screen so I knew what was where for things like rendering the cursor, blinking, etc. Scrolling that took a surprising amount of overhead, so I solved that problem by maintaining an array of pointers to character row buffers, and scrolling was done just by reordering the pointers.

    Ah, the days when compute resources were so tight, you had to really think about every clock cycle. 🙂

    And isn’t it interesting how some of the things I remember most clearly were esoteric micro-optimizations I had to do? The rest of it’s a total blur!

    In case you’re wondering what I’ve been up to since I graduated high school, here’s my home page, which I desperately need to update: http://www.cs.binghamton.edu/~millerti/

    Reply
  3. Timothy Miller

    BTW, it’s nice to have you maintaining this blog. It brings back memories and makes me feel like some things I did just for fun when I was a kid were really useful to other people.

    Reply

Leave a Reply to Eric March Cancel reply