Atari Falcon serial transfer pt.2: Shells from hell

A continuation of the Atari Falcon/ST file transfer topic.

I've found Atari terminals to be clunky and none would do exactly what I'd want them to. Ansiterm fared the best so far, the terminal is good enough for using the command line remotely, and a Zmodem transfer will be automatically recognized when using sz from Linux end.

However, on the minus side it's one more program to launch, necessitating video mode adjustment to ST-LOW and setting up the xyz.ttp. This also distances you from the Falcon end of things.

Although this was an ok solution for one longer session, I didn't exactly like to access my Linux command line through a terminal.

As long as I can use a command line shell on the Atari end, I should also be able to call up a file via that command line. Previously, this meant launching xyz.ttp at Atari end and then typing the sz at the Linux end.

Now I tried a fun way to improve this a bit.


Mupfel shell

At Falcon end I have used the Mupfel shell, which is bourne-like enough for doing relatively complex scripts and redirecting of input/output.

I could make a small script that sends commands to the Linux by serial port, activating the sz Zmodem transfer and running the xyz.ttp Zmodem receive program at the Atari end.

But it took a while to get the Mupfel shell up and running properly, as I couldn't find that much information about how to use the shell.

Then it struck me that as the shell is a Bourne clone, people must have assumed it's nearly general knowledge anyway. So, after reading some sh guidance...

If the program file mupfel.ttp is at D:\comms\mupfel then the shell expects to find a file called 'profile' from there.

echo Mupfel
echo xyz,zip,lzh,edit,emacs
echo
PS1='%p> '
alias xyz=c:\xyz202b\xyz.ttp
alias zip=c:\stzip\zipjr.ttp
alias lzh=c:\packers\lharc\lharceng.ttp
alias edit=d:\comms\memacs\me311ata.tos
export TERM='VT52'
PATH='c:\;d:\comms\mupfel\bin\;e:\;f:\;.'
HOME='d:\comms\mupfel\'
SUFFIX='prg;app;acc;tos;ttp;mup;sh;'
LINES=30
ROWS=30

The above is an example of my 'profile' which connects various programs with aliases. The line with PS1='%p> ' makes the prompt a bit friendlier, showing the current path.

I use MicroEMACS for editing text files inside Atari, there are not many options for editors that would work well within the Atari shells. If only I'd find the way to bind those arrow-keys...

MicroEMACS requires that the environment parameter TERM is not empty, so I have 'VT52' there. Suffix should tell which files are executable but frankly it doesn't seem to do much. Not sure if LINES/ROWS are meaningful to any programs.

Well, off to the file-transfer-mobile.


The 'get' script at Atari

D:\comms\mupfel\bin\ is a good place to put a script. Mupfel scripts end with .mup extension.

From the command line, doing

echo Hello>>AUX: 

sends characters to the serial.

Saving the following as get.mup

echo get $1 >>AUX:;xyz

is enough to send over a 'command'. The characters 'get ' are sent, followed with the argument passed from the command line, and after that the shell runs xyz.

Here in my case xyz is an alias for xyz=c:\xyz202b\xyz.ttp as defined in the profile above. I guess the 'get' could be an alias too.

I spent some time making a Processing sketch that reads the serial input, sniffed for that 'get' statement and used a system call to send the required file using sz. Clunky but it worked.

However, after a bit of a think I felt this could just as well be done as a Linux bash shell script.


The 'server' script at Linux

At my Linux end, I can use a script somewhat like this:

#!/bin/bash

DEV=/dev/ttyUSB0
stty -F $DEV 57600

echo "Serial is on"
echo "use get at Atari"

while :
do
 echo -n "WAITING>";
 IFS=' ' read COMM ARG < $DEV
 if [ "$COMM" == "get" ]; then
  echo "GET:" $ARG 
  sz $ARG > $DEV < $DEV
 fi
done

The script sets the serial port to 57600 and waits for a line of characters to arrive via the serial.

After such a thing arrives, the string is split using spaces between words. The first part will be the 'command' and the latter part a 'filename' for that command.

If the command is seen to be equal to 'get' then zmodem send (sz) is launched to send the file, with a filename based on the second part of the line received from the serial port.

In the meantime the tiny get.mup script at Atari end ensures that xyz202b.ttp is launched, waiting for the Zmodem transfer.

After the file has been transfered, the Mupfel shell resumes normal operation while the script at Linux end is looping another cycle, waiting for further instructions.

So, typing get /home/user/Downloads/atarifile.zip on the Atari end the file will be received to the current folder.

I added a 'put' command for uploading files from Atari and a 'say' command for simply sending a bunch of characters to be displayed, for testing purposes.

echo put>>AUX:;xyz -u $1

and

echo say $1>>AUX:

and the respective portions to be added to the Linux bash script:

    if [ "$COMM" == "put" ]; then
        echo "PUT:"
        rz > $DEV < $DEV
    fi
    if [ "$COMM" == "say" ]; then
        echo "SAY:" $ARG
    fi



Vice Versa

Now, it might be handy for the Atari to be waiting for the files whereas the typing stuff is done on Linux? How to do the opposite of the above?

Again, in Mupfel:

while :
do
IFS=' ' read COMM ARG <AUX:
if [ $COMM = 'put' ]
then
echo 'RECEIVING'
xyz
fi
if [ $COMM = 'end' ]
then
echo 'QUIT'
exit
fi
done

I had to take a bit different approach (it's not bash) but in the end I got it working on the Mupfel shell.

(I preserved the command/arguments split although I don't do anything with the arguments really.)

Running this, it becomes possible to use the send commands exclusively from the Linux end and the files will arrive at the folder the script is run from.

I had some trouble breaking out of the loop so I added the 'end' command just to be able to stop the shell from outside.

Also, at least in this form the 'read' tended to take in the Zmodem control characters etc. and got into a mixed state having received bunch of codes but no newline. Sending a bunch of lines after the serial send sort of clears the situation, but also produces glitchy-looking messages.

Although a nice exercise, having the 'server' script at linux end might be the better solution after all. Running that script is no problem for that box, whereas the Atari would be tied with running that one loop.


Afterword

By the way, another Bourne-esque shell I dabbled with for a while is called Okami, which was good enough for launching that xyz.ttp, moving and exctracting files around. A bonus is that it's able to launch GEM programs, something Mupfel won't do.

The earlier version of Okami may be recommended, although it is a bit lacking. The later versions appear more comprehensive but they were buggy at least on my Falcon so it was virtually useless.

Atari Falcon SD-IDE

The Falcon August continues!

After establishing the basics of file transfer between Falcon and Linux, I wanted to replace the physical hard disk with a IDE-compatible SD card reader. There was one CF-IDE adapter lying around but my CF cards were exactly those "nameless" brand cards people always warn about so I avoided using that.

I ordered a IDE/SD card reader "SECURE DIGITAL 44 PIN 2.5 MALE IDE TO SD CARD ADAPTER AMIGA 600" off eBay. Seeing that it was advertised as fitting for Amiga sounded good enough.

When the item arrived, I thought it wasn't the correct 2,5 inch as "promised", but smaller. But after opening the Falcon (the first time) it turned out this was exactly right for the IDE cable/connector that was inside the computer.

IDE cable at centre. Note the absence of a cradle for HD.

So, I couldn't even have used my CF-IDE adapter without another adapter.

Possibly, a doohickey 90-degree adapter might exist somewhere that would get rid of the cable entirely.

For the SD card I used a Kingston 8gb HC "20x" card.

For setting up the disk I simply followed instructions, and here I'm largely just repeating what people have said elsewhere, mostly the second option in this Youtube video.


Opening the Falcon and fitting the card adapter

The Falcon cover is held together with a bunch of screws. Underneath, there is a metal panel that needs to be removed. The second metal panel (under the keyboard) can be left attached.

The topmost metal part should come off by creatively bending and wiggling it, even if it at first looks like it might not.

This Falcon did not have the original cradle for the hard disk, so I can't really comment about that.

This also meant I'm somewhat out of options as to where to put the card reader. It's so light it could just dangle at the end of the IDE cable, but the danger here is that it might hit something delicate on the motherboard.

I feel that the creators of SD card readers could make the circuit boards a bit larger just to make them easier and safer to attach inside the computer. I mean if it's supposed to replace a 2,5 or 3,5 inch hard drive, it doesn't need to be the size of a postage stamp...

For a while I kept the card like in the image below, but then I felt it might hinder the air flow. Probably not, but anyway it ought to fit more firmly into place.

In the end I turned the cable and the card "upside down" on itself and fastened a wire around the IDE cable so although the adapter isn't screwed or fastened in, it won't sail away on its own accord.


Partitioning the drive

After physically connecting the card reader using the IDE cable, the card needs to be partitioned using the Atari (not formatted).

I went for the ICD driver route, as people have reported it should work just fine with the CF cards and like. "Somebody" said SD cards might be more reliable so that's why I went there too.

I downloaded the ICDP655A.ZIP on Linux, likewise unpacked it on Linux and copied the resulting folder to a HD floppy disk that I had formatted on the Falcon.

Using ICDBOOT.PRG the relevant driver becomes present (it ought to recognize the card and  display its name even at this point). Then, using the ICDFMT.PRG the card can be partitioned.

Note again that "format" has no relevancy here. Instead, "Clear" the suggested default setting, and then use the "split" command to give a suitable number of portions.

The suggested GEM partition size tends to be overtly small, I suppose there's no sense to keep it smaller than the other partitions. Still I kept it at 20mb just to avoid cramming files there.

The partitioning should be almost instantaneous, but the program will check for bad sectors and this will take some time. After this the system will be rebooted.

You should be able to see the partitions on the desktop after running ICDBOOT.PRG and using Install Devices from the GEM menu.


Making the drive bootable

As the computer can't boot from the drive yet, you'll still have to rely on the floppy.

To make Atari drive C bootable, run the ICDBOOT.PRG again to activate the driver and then use HDUTIL.PRG for enabling the boot.

I bothered to snapshot the desktop on the Atari, a hilariously long-winded process

This part was a bit confusing, and I didn't get it right the first time, possibly because the floppy behaved a bit badly.

You can choose a partition for the boot drive, then the drive should be set for booting and the driver will be installed on that partition. It's possible to fiddle with the boot options, and I did some too.

Not sure about these. I guess I checked the "Falcon" for Boot Res and that's it.

Don't copy the ICDBOOT.PRG to the AUTO folder of the hard disk, it does nothing there.

After the boot works, You can Install Devices from the desktop menu and then Save Desktop. The Falcon should now boot to the system and show the partitions on the desktop.


Reaping the rewards

Strangely enough the disk drive (or the floppy) started working erratically during the process. But I managed to get the XYZ.TTP onboard after which I could leech off everything over the serial on 9600 speed.

After getting DRVIN.PRG, SCC.PRG, XCONTROL.ACC and SERIAL.CPX I could get the faster 57600 speed. The DRVIN.PRG, SCC.PRG and FPATCH2.PRG are to be placecd in the AUTO folder whereas the ACC files belong to the main folder. Make a CPX folder for the SERIAL.CPX, although you probably have to config the XCONTROL.ACC to find the files from there.

I've been toying around with this setup for a few weeks now, adding and adjusting things, and the card appears to work ok. More about Falcon later...

Linux->Falcon serial transfer

After having a look at the Atari Falcon 030 and using the cumbersome floppies for moving files about, I wanted to move files over the serial.

I had lost my null-modem cable and could only find a mirrored 9-pin cable with M-F connectors (what is that for anyway?). The proper null modem cables were still sold at Clas Ohlson in Helsinki. Thanks, Clas Ohlson!

Serial is quite fast for sending a few megabytes or less, which is enough as Falcon files are not that huge.

Obviously, the ports have to be set for the same speed. 115200 proved to be a bit too much, so I went for 57600, which gave a healthy ~5500 bytes per second.

First, I need to set the serial port parameters using the Control Panel. This requires the Control Panel accessory (XCONTROL.ACC) in the boot drive folder and the serial control panel extension (SERIAL.CPX) on the system, at C:\CPX\ for example.

DRVIN.PRG needs to be at the AUTO folder to gain these high speed connections for "Modem 2", otherwise you'll be stuck with the 9600. Edit: It seems the SCC.PRG should be there too. Not sure which of them or both?

If DRVIN is not there, the ACC is likely to bomb if you try to fiddle with the modem 2 parameters.

XYZ on a command line shell at Atari end

To receive files using the ZMODEM protocol, you need XYZ.TTP.

Although the xyz can be run from the desktop, I prefer to use these TTP (TOS-Takes-Parameters) programs from inside a command line shell. It's a bit neater that way and I get to see the program results and recent actions better. Moving files around the system becomes quicker too.

Still testing at 9600, hence the slow speed...

Okami shell is reasonably featured, and you can use some Unix-style parameters, like directing output to a file or a serial port. It's not developed with a Falcon in mind, but using a 2-color video mode it's pretty fast. "mupfel" is another shell, but setting it up seems a bit more involved so I'll look at it later.

I added the following line inside the Okami "profile" file, so the shell will execute it on running. This way I can run the xyz from wherever I happen to be:

xyz=c:/xyz202b/xyz.ttp

Afterwards, using

$xyz

the xyz.ttp will run and wait for a file to be sent. Yes that $ is not exactly as effective as an alias or a proper PATH but it's still far better than working every time from within that folder.

As an aside, editing that profile file is bit of a chore as there are very few choices of a shell-run text editor. I'd hate to jump between a GEM editor and the command line shell now that it's in place. I ended up using something called pro_edit for now, which is rather poor and assumes the display height is 400. ST video modes to the rescue.

But if it's only a matter of adding one line to the profile, then appending that line with echo xyz=c:/xyz202b/xyz.ttp>>profile will work.

Obviously, after the file transfer is in place text files could be transferred from the Linux... But as the point is to toy around with the Falcon, why move over all the tasks to some other computer?


sz at Linux

Unlike Atari, Linux doesn't have an abundance of strange 'terminal emulator' programs, possibly because the terminal is so integral to the system.

There's minicom, but practically minicom (or anything else) uses rz and sz for file transfer protocols, so it's better to use these from the Linux terminal command line directly.

These need to be installed first. If there is a permission problem with the serial port then the user has to be added to the dialout group.

I followed a suggestion of calling sz from a tiny script (named zsend in the example) which ensures the serial port speed is correct:

#!/bin/sh

DEV=/dev/ttyS0

stty -F $DEV 57600
sz $1 > $DEV < $DEV

The ttyS0 is the device for the serial port, in my case it's already a part of the motherboard. An USB->RS232 port is often called ttyUSB0. dmesg | grep tty reveals the device names.

Saving this script as zsend, it can be made into an executable with chmod +x zsend, after which ./zsend filename should start the transfer. If Atari is running the xyz.ttp and waiting, then the file should transfer.

A version for receiving files from the PC end, use rz instead of sz.

At TOS, xyz -u filename will upload a file, defaulting to ZMODEM.

I also tried batch uploading with *.* and although everything went fine for a file, the XYZ.TTP at Atari end complained about too many handles or something after about 16-17 files. So, for moving a lot of files it's better to zip things at that end first, no matter how slow it is.

Strangely, uploading from Atari was a bit slower, some times less than 4000 bps on average. File permissions may need altering on the Linux end and the filenames tend to be uppercase which can be a bit annoying at Linux. -LL option on zip ought to force filenames to lowercase, though.

Backing up AUTO folder and your essential system files with this method is a good idea I think!



At Atari again

Transferring zip files is much more handy than trying to send files with a folder structure, and they are obviously compacted too.

Working with the Okami shell, for added comfort I also added the zip unpacker to the Okami profile:

zip=c:/packers/stzip/zipjr.ttp

...for example. The zipjr.ttp comes out of the stzip.tos self-extracting archive, found here.

$zip -xr file.zip

In Okami, this then becomes the equivalent of running zip from its folder. It appears the zip version I have it likes explicit -xr parameters for extracting and preserving the folder structure.

Lharc (lzh) is another often seen archive format, and jaymsa18 may be used for recovering files out of .msa and .st disk images on the Atari end, if the disks play nice with file structure that is.

After all this, I can finally look at Llamazap, an apparently unfinished game by Jeff Minter that can't even be started without a very specific controller. Oh, well.

Atari Falcon 030

As an Atari STE owner back in the day, I was one of those people who drooled at the Atari Falcon before and around the time of its release in 1992. I read ST Format reports and snippets of information from Atari newsletters with great interest. The Falcon was promoted as a really bad-ass multimedia computer, beating Amiga at its own game.

When the computer finally came out, I had little chance of acquiring one, and already the magazine reports made it sound a little less than it ought have been.

Now, finally, I have some first-person experiences of this rarity.

The first physical impressions are that it weighs a ton, doesn't look that different from an ST, there's a noisy, monotonous fan inside, the keyboard is not that great and the port for the bad mouse is still below the computer (and upside down).

It also turned out that 16Mhz is not a huge leap when the new graphics modes would have needed some more heavy lifting. This is already something I recall from using a plain Amiga 1200: "Is this really it?"

Plain ST games would not demonstrate a monstrous speed increase, Frontier is now about bearable but that's it.

Frontier, one of the go-to games for testing Ataris.

The Digital Signal Processor was a saving grace for direct-to-disk recording, and with the already-established in-built MIDI ports the Falcon became a bit of a cult among musicians.

The DSP could deliver the needed punch for many kinds of games and applications, but it was not very simple to program and apart from the audio applications there was not much productivity software or games for it anyway.

More recently, skilled people have showed what can be done and there's a rather wicked-looking engine for displaying Quake 2 and Half-Life 1 levels, utilizing the DSP.

When the Landmine tried to play a sound the MP3 player messed up and did not recover.

Also, mp3 songs can be played in the background while still using the desktop. How's that for a 1992 computer?!

Theoretically, for a fleeting period in time, all the power for an Amiga-beater was inside that casing, but nothing helped people exploit the better parts of it around 1992. Then Atari computer division went down and adios, Falcon.

Oh, about the crappy photographs: I could have used a desktop accessory for making snapshot images out of the desktop at least... but I was not prepared to move and convert them around for the time being.


First things firST

Nice that I can use the VGA monitor adapter block to connect the Falcon to a modern display. The picture is not especially sharp on my display but I can live with it.

I got rid of the Atari mouse and connected a PS/2 optical mouse through a micromys adapter. (One that has C64, Amiga and Atari ST modes)

This Falcon came with IDE harddisk and 4MB of memory. I intend to look into using a Compact Flash/SD-IDE adapter but it'll have to wait a bit. Doing that and swapping the 1.44Mb disk drive to a Gotek might not only improve the computer but help reduce the weight somewhat... not that it's meant to be moved a lot.

Which brings me to a point. These days I'm a bit frightful about a computer that has physical hard drives but no "software shut down" to ensure the drives are stopped! (Ok some drivers come with head park software).

Universe-on-a-floppy

Luckily the Falcon floppy drive was in working order. After formatting a HD disk on Falcon I could copy files to it on the floppy-drive equipped Linux Mint.

I could also copy the aforementioned Frontier over to the Falcon. It didn't run just like that, I had to CONTROL-ALT-DEL from the desktop with holding CONTROL down.

Then, if you're lucky the Falcon will boot without any drivers and there will be sufficient "low" memory for running Frontier.


TOS, utter tosh?

Looking at GEM/TOS I am surprised how little has changed from the Atari STE days.

As I had a "bundle" of software ready on the IDE drive, I could have a head-start in exploring different kind of programs without having to install much.

The first impression is that the GEM/TOS is perhaps even slower than before and not that much has been done to improve it. Switch on the software-based MultiTOS and it'll get even slower.

The early-to-mid 1990s desktop experience, complete with a modplayer.

I could get the modplayers and mp3 player up an running, trying out some utility software in the meantime. It was a nice moment, but the environment did also crash and glitch a lot. The sound tended to conflict between applications like the FalconAMP and Landmine (minesweeper clone), keyboard clicks got stuck in a loop one time and so on and on.

But I have to recall that using the Workbench of the Amiga was a long process of weeding out software that didn't work, and learning my way around situations that could potentially crash the computer. So the same likely applies here: if I really had a motivation to use the Falcon for months and months the software collection and my practices of using it could develop and I wouldn't encounter these problems.

The 4MB of memory is not luxurious when it comes to using the multiTOS, I saw that at times much less than 2MB was left available when trying to run a couple of apps together.

Turning off the new-fangled GEM options using the CONTROL reset trick does show the desktop can be faster compared to an Atari STE.

Apparently more flexible video modes are possible but the desktop allows only a few combinations. Note that the Falcon modes easily eat up far more memory and speed than the 32k of ST modes. The difference between a 256-colour 640x480 and 16-color mode was about 300 kilobytes.

Instead of descriptive or explicit resolutions a somewhat confusing "40 columns/80 columns" and "double line" terms are now in use:

40 columns: 320 pixel wide
80 columns: 640 pixel wide
Double lines on: 240 pixel height
Double lines off: 480 pixel height

The higher resolutions are available as 2 or 16 colour modes, whereas the lower resolutions support 256 or even 65536 ("true") colour modes.

I recall the day when the prospect of having such a luxurious amount of colours in an image was in itself fascinating and something to be desired!

The ST-compatible legacy modes are Low resolution (320x200x16), Medium resolution (640x200x4) and High Resolution (640x400x2).


Yet...

It may sound I'm very negative about the Falcon, but in truth it's kind of growing on me.

The computer has that Atari ST feeling, a kind of simplicity and straightforwardness. Bit like when you look at MS-DOS and think "why wasn't this enough?" except it's graphical.

What I am glad about is the amount of options for connecting and transferring files. PC-compatible HD floppy, RS-232, IDE...  I'm thinking about the Apple Macintosh where you have a quite closed system and very limited choices for transferring data into it.

I also got over the somewhat clunky-looking and slow desktop, especially when I noted that using the ST compatibility modes makes it faster.

Atari 2600jr

Just think that many Atari 2600 games are now about 40 years old. I believe I encountered Atari 2600 in the summer of 1984. This Jr. version is a later acquisition, I got it alongside a bunch of computers in 2010s.

In the past I had already fixed the select/reset buttons (a common problem in Jr) with crude switches, but avoided doing the composite video mod. Except now.

As Ataris are so popular there are a gazillion mods. I followed the mod from a site that happens to be gone now, but it is pretty much same as here. I simply found my board to be similar and the instructions are very concrete.

1 x R 330
1 x R 1K
2 x R 2K2 (=2,2K)
1 x R 3K3 (=3,3K)
1 x Capacitor 100pF

The mod features a 100pF ("101") capacitor, I figured that the n10-labeled capacitors in my inventory should suffice, although I haven't seen this notation too often.

"n10" = 0,10nF = 100pF

(The 'n' denotes both the scale and the position of the comma so 1n0 would be 1,0nF and so on)

I added a tiny board where I imagined all the wires and resistors would go neatly, placing it over the pins that now make up the select/reset switch connectors. The plan fell through and I soldered the resistors directly to the chip as in the site I found. The added board was somewhat helpful for fitting the video cable that goes out of the box.

Without the audio, two solders away

I cut a couple of grooves to the right side of the case, so the video/audio cables can stick out from there. Having the grooves tight keeps the leads in place. A neater mod would have two proper connectors but I didn't have ones that would have fit. I left the RF connector as it is.

I realized I can't use my previous select/reset switches as they collide with my added board! Not much foresight here I have to admit. Also it reminds me how large the switch boxes can be.

So I removed the crappy switches and added two buttons to the top of the case. I could have removed my additions but I was lazy as usual. The new switches are connected with breadboard jumper cables at least they can be detached easily for removing the case.

I played a bunch of games installed into a Harmony cartridge. But is there something wrong with some of the colors, for example California Games has obviously a wrong palette? But games I know well such as Jungle Hunt and Space Invaders seem to have correct colors so likely it's a software version thing.


So, what to play? My own nostalgia-biased shortlist:

Jungle Hunt

A complete jungle adventure. Few corners have been cut in the conversion, but it does not detract much from the gameplay.

Space Invaders

Ok, so it gets monotonous and does not have all the subtleties of the arcade original, but this was my Space Invaders and the first game I played on the Atari 2600.

Berzerk

Ditto here, I kind of dig the chunky big graphics of 2600 conversions compared to the arcade stick figures. Switch on the Evil Otto for more difficulty.

H.E.R.O.

Even if the backgrounds are quite simple, the play appears to be as complete as in any version. Dynamite the walls, shoot the critters, always pick the route with the obstacle. Gets hard around cave 11 or so.

River Raid

The classic vertical shooting game is nearly fully featured as far as I see. Shoot the bridges, collect the fuel, shoot the fuel. Check the B-switch for proper missile behavior.

Ms. Pac-Man

Although the Pac-Man conversion has a bad reputation, the sequel delivers. A proper maze and you can even see everything.

Thrust

My best score so far.

This latter-day homebrew conversion by Thomas Jentzsch is amazing and possibly the best game altogether you can get for the Atari 2600. Considering it's one of the better games on the Commodore 64 it's surprising to see it fully functioning here!

ATARI Portfolio

Atari Portfolio is from a time when Atari was beginning an expansion towards new fields (transputer computers, CD-ROM drives, STacy, 32-bit consoles and other near-vapourware), innovating with this portable "MS-DOS compatible" hand-held computer. Luggables had been seen before, laptops were nearing acceptable sizes and Sinclair's Z88 packed some nice functionality. But here was something, that for a brief period of time, seemed like the future.

The physical design is neat, somewhat confused around the hinge when it's open and a bit thick when closed, but very cool styling altogether, cyberpunk even. A slightly smaller footprint than I expected, thicker than I expected, smaller screen than I expected. Atari compares the size to a VHS-tape (a size comparison that's bound to become extinct) and that's a pretty adequate description.

The hinge gave a fright-inducing squeak when opening and the lid refused to close fully. Perhaps I broke the guard switch, or it was broken to begin with. On the positive side the hinge has not become loose at all over the years.

Silliest thing is the area around the screen which has no other purpose than to declare "16 bit personal computer", "Portfolio" and ATARI at various places. I can imagine that in concept stage the screen might have filled some more of the lid space.


Initial impressions

The keyboard is good for the size. The keyboard is buried, the keys are profiled to slant forward and they have that characteristic 45-degree sci-fi cut in them. These features altogether improve the typing sensitivity a bit, further enhanced by the subtle electric beeper sound. No fast typing, though, I was using maybe six fingers tops. I needed to change the keyboard layout to Swedish, this from the Applications/Set up/Keyboard.

Editing, well, the EDIT.BAT, to run the APP /e command

The apps are quite well thought out. The Address book does not make too many assumptions and the editor is low-key enough to be relatively quick. The Diary I suppose is more of a calendar, but I did not look into it too much. The calculator I found to be clear but limited, no hex mode or even SIN/COS as far as I could learn from the manual.

The spreadsheet can calculate more complex things, and I suppose the calculator is more of an afterthought for simple immediate calculations. No hex though in the spreadsheet and sadly no string manipulation either.

I was horrified with the DOS-style frame window space waster in these apps. Thankfully this can be switched on/off with F5.

Eight-bit pixel calculator in worksheet, without screen frames.

DIPping into DOS

The Portfolio boots up to a stripped-down MS-DOS called DIP DOS, with a plethora of familiar commands such as DIR, CD, COPY, PATH, PROMPT etc. HELP brings a shortlist of generic commands. Batch files such as AUTOEXEC.BAT are valid too. Thankfully the OS is in ROM.

The display shows eight text lines, and the active part of the display is even slightly smaller than the physical dimensions which are small to begin with. Old MS-DOS programs should in principle work with the Portfolio, but I doubt there are many that accommodate with the 40 x 8 character display and the limited 128K memory. Part of that memory is a RAM disk, too.

Form factor: sci-fi

It's possible to use a virtual 80x25 mode, and then scroll around that space, using the view port as a window into that larger screen space. The internal apps don't respond to this, but maybe it's wiser that way. In my understanding the screen is strictly text-mode, so no plotting of graphs or sprite graphics.

Given this is an MS-DOS environment, some omissions are a bit frustrating. I can't use EDIT to run the internal text editor, for example. There's a clunky APP /e construct, and although I can create an EDIT.BAT that runs the command, APP does not take a filename as an argument. At least the applications remember the last open file.

A whole Spectrum's worth of memory! The battery sled is a bit tight.

It's a pity the RAM cards need their own battery. It's also suggested the battery be changed every six months. The battery type is CR2016 type and should be only replaced when the card is inside a powered-up Portfolio, in case you're interested in retaining your data. I didn't try my 128K card yet as I don't have the battery. When the 4 AA batteries inside the Portfolio die, I guess it's goodbye to the internal RAMdisk files if they are not backed up.

I beam myself into the future

Strangely enough, for the 2010s, in some ways the Atari Portfolio from 1989 is a worse deal than the Canon X-07 handheld from 1983 I once wrote about. This has perhaps more to do with computing trends than actual hardware specs.

The Canon had an integrated BASIC language and graphics commands, enhancing it's role as a calculator zillion-fold, whereas the PowerBASIC for Atari was sold separately. Given the esoteric nature of Portfolio's memory cards and connectors I have less chances of getting anything transferred to the Portfolio than with the Canon tape/serial interface.

BTW: Photographing the screen is annoying.

Obviously the MS-DOS connection gives Portfolio great generic potential, but this potential is difficult to put to use with an out-of-the-box device. There's no DEBUG, no file editor, of course no assembler. It's possible to hack up an executable file by ECHOing character codes directly to a file, though. A tiny program is created for slightly more handy file writing, then that file writer is in turn used for creating an even more complex program. This sounds intriguing and I'll be looking at this approach some time.

Although the Portfolio manages to cram in some nice software, this set is also very "office" oriented, showing that computing had begun to atrophy into imagined "tasks", paving way to boring PDAs. Later, high-end calculators like TI Voyage 200 better filled the niche that a Portfolio-type device might have been aiming at. (Note to self: write something about the Voyage)

Just like with all ye olde hardware, there are small existing communities, either for all things Atari or for the Portfolio itself. What I see there is no massive Portfolio cult, though, and modern additions are quite sparse. There apparently have been PCMCIA adapters for slightly more recent memory cards, and Wikipedia mentions a Compact Flash mod. If I've understood correctly neither work as a PC file transfer method as the cards will become Portfolio-specific. An SD-card adapter would be neat but I think there's none and might not be happening.

I thought I would refrain from mentioning it, as it's always brought up to the point it seems to be the only reference for this computer... But, of course Atari Portfolio is the device the young John Connor uses to hack an ATM in Terminator 2: The Judgment Day. There's some vague basis in reality for this, as the Portfolio can generate telephone dial tones from the Address book, something that might theoretically have found use in a phreaker's toolbox decades ago. However, the film clearly shows a ribbon connector.