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.