Gaming on Atari ST(E), Falcon ...

[Petari]

  Gaming on Atari ST (and compatible) computers in 2011

We have some pretty good emulators, but nothing can replace the real thing. And some people may not having PC, MAC, capable to emulate.

 First problem:  where to get games

Well, in shops it goes not today :-)
But there is cheaper & faster way, and almost everything is available on Internet.

DL sites - curently best:  http://www.thegamearchives.com    http://www.planetemu.net


 Floppy images:
 Image is exact copy of floppy disk content as regular file.   It serves preservation and possibility to write content on another floppy
 - (copying).

 Usual image file formats in Atari World:
  ST - it is in fact RAW format, what means just sector contents in order, without any extra info, header about disk geometry (physical format).

  MSA - little better as contains header with geometry info.

  STT - used by Steem, not much known, and abandoned. Supports some simpler protections.

  STX (Pasti) - special format for protected stuff. Usable only with emulators (at moment). Can not write to floppies.

 Floppy format:
We can talk about physical and logical format.  Physical format is 'geometry' of floppy disk:  Number of cylinders (called tracks too), heads (sides in fact) and sector/track.  Multiply of this 3 gives total sector count on disk.

Sector size is usually 512 bytes, with rare exceptions (only by protections)

 Logical format:
The way how data is organised on floppy. There is only one type used by TOS:  FAT12 . It holds relevant parameters in bootsector very first sector on disk)  about geometry, then comes file allocation tables (FAT), and root directory.

 In case of ST image format geometry may be readen from boot sector. But not always. Then user self need to set correct geometry in SW.  Therefore is recommended to use MSA format for such floppies.

 My experiences with floppy image files available on the WEB:

There is a pretty mess with all this. Actually, simplest is with STX (Pasti) images. Only way to make Pasti (STX) image is by using original SW on some Atari ST(E) machine. It will do self practically all, without much to set.
 Best place to DL Pasti images is at moment atarimania.com . Over 1000 games. But STX is not suitable for running SW on real Ataris.
Plus, it takes more space, works slower. So, is recommended only if there is really copy protection.
 There is a lot of Pasti images made of games which are not copy protected - for instance Flight Simulator 2 .

  ST & MSA images on WEB:
 Available on many places, but some sites disappear by time, and new ones appear. But one thing remains same: too many image files with practically same content, same errors. 3-4 variants of same title, only bootsector or filesize or 'cracker' is different.

 Of course, most of stuff is cracked - as 95% of games were on copy protected floppies. Currently, it seems that cracking self is not
problem - even game publisher WEBsites have cracked versions available for DL (likely because no other usable copy of game).  But there may be bad cracks, where worst case is when errors appear only at later gameplay. Then, crackers often spoiled game by writing own names, messages on inproper places. Even info about cracker is unreliable as it was common to 'rip' crack :-)
I don't care much about who done it. But like to see game complete and intact.
 Another problem by ST & MSA images is oversizing: you will see a lot of images of 840KB and similar. It should be then floppy with
84 tracks (cylinders). But in reality on extra tracks, over 80 is usually nothing. I even never saw original floppy where tracks over 80
were used - with good reason: it is non standard and floppy drives may be unable to read it. But people who made archives did imaging of floppies on base: what is sure is sure, let image tracks over 80 for case. Problems may appear when writing such image onto floppy which supports not extra tracks - like destroying correct data on track 79 with trash what comes after.

 Playing on real Atari from floppies:

After DL-ing games or getting them from other source in image form, user needs to write them onto floppies.  First problem is getting
floppies self. It is not easy today as we need DD (double density, or '720KB') ones. Best is to get old floppies from some Atari user or looking E-bay, second hand shops ... In case of need new HD floppy may serve. But it is usually less reliable, as floppies self are of bad quality now, plus old DD floppy drives are not best in reading HD disks.  In any case, you need to cover hole at right side before putting such floppy in PC floppy drive, then it will be recognised as DD.

  Writing image files onto floppies on PC:
You need special SW for that. What to use depends from OS. In case of currently most used Windows XP ( and Vista, 7 ) Floppy Imager
(FloImg) is practically only choice. In case of DOS best is MAKEDISK. Linux : ---- .

Unfortunately imaging will work good only on PCs with built in floppy drives. and will not work on USB attached floppy drives. This is pretty bad now, as internal floppy becomes obsolete. But there is no solution, it seems. The problem is in fact same as with Windows XP floppy driver SW. Only regular DOS/Win formats are supported, so imaging something like 800KB floppy, what is most used on Atari is not possible. USB floppy drives have hardcoded floppy parameters, so support only 720 and 1440KB formats (some only 1440).

I will not go here in details about SW usage. Read manuals, usage. Ask on forums if it helps not. But some basic knowledge will save you from problems. So, read begin of this article, if you skipped it :-)


 I did everything correct, but game runs not:

The usual reasons are:  TOS version incompatibility. Mostly stays for TOS 2.06 or 2.05. But for some games even 1.04, 1.02 is not good enough. The solution is to try other crack or find version which solved TOS compatibility problems (what is noticed usually).  
STE and older games: generally, STE is very compatible. If some game works not it is usually TOS version problem, and can be fixed. Or is just bad programming, so can be fixed too. For instance game Grand Monster Slam has bug in color palette writing which does nothing harmful on ST, but on STE will screw display. Changing only 1 byte in code fixes it (concrete error is writing overshot because bad loop count set).

Other usual problem is bad floppy quality and/or unreliable writing/reading. Problems happen with old, dirty, scratched disks, when floppy drive (heads) is dirty and similar. May be that floppy drive in PC and in Atari have different set head positions - later is solveable only by changing one of drives or adjusting drive mechanic.  What user can do is cleaning - best with alcohol. Watching messages of imaging SW about errors by writing. Trying to format disk with regular formatting SW - then will get infos about bad sectors.

 More comfortable way of playing 'floppy' games:
With HW floppy emulator. It is device attachable on Atari instead floppy drive, and will act exactly as it. Instead disks, data is in floppy images. 2 variants are avaiable: 'stand alone' - where images are on SD card. PC based - images are on PC hard disk, and we have USB connection between PC and emulator device. Look for HxC floppy emulator online ...
This is more reliable and comfortable than using floppies. But still need 'manually' to change floppy images when SW asks it.
 For not much more than HW emulator costs (or even for less) we can now get rid from playing DJ :




  Playing Atari games on machines equipped with hard disk:

Or 'playing from hard disk'. Today we are in very good situation with this - may place thousands of old games on 1 small and cheap storage media, like SD or CF card.
Well, storing self is easy, but running games is not. The reason is that 99% of Atari ST games is not intended (programmed) to be runnable from hard disk, only from floppies. Ground lies mostly in copy protection + RAM usage. And fact that hard disk were very expensive in 80-es.

What beginner can do is to DL adapted (patched) versions of games from sites of people specialised for it. Over 500 games are vailable at moment, mosty best and better ones.
Then comes transfer onto Atari hard disk, flash card. It can be done in many ways. Some use cable connection between PC and Atari - serial, parallel port based. The problem is that PC SW is little obsolete and runs not (well) under new Windows versions. Using floppies for filetransfer is not elegant way, and is slow and unreliable. + with longer files need to use file splitting, joining etc. Not recommended.
Best way is to copy files directly on PC, with attached Atari hard disk or flash card on.  Of course, it is easy only in case of CF, SD
cards.
Then comes new problem: PC recognises not partitions on Atari disk.
This is long subject ... But if Atari storage media is partitioned wisely, TOS/DOS compatible, then transfer is really easy and fast. Only
thing to care is to not using long filenames, and avoid deleting to recycle bin from attached Atari media. TOS can not properly handle long filenames, and you will have only troubles with such files on Atari. If see some long filenames on Atari medias, delete them on PC, permanently, (not in recycle bin). Recommended is usage of Total Commander in Windows, where can set usage of DOS 8.3 filenames by copying, for instance.


 Solving running from hard disk:  

A: Simplest possible case:  taking floppy and copy all files in some directory on hard disk, then running from there.
It works in max some 5% of cases - Sierra adventures, most of by Atari published games .
Some games will work on one machine, and not on another. The reason is usually in different RAM amount allocated by TOS and hard disk driver, + possible other resident SW. Here we came to first rule: use clean system, with only necessary SW installed. So, no desktop ACCessories, unnecessary drivers etc. Only hard disk driver, nothing else. It is important too that hard disk driver self do not allocate too much RAM - it will help not much in speed, but will make some games to not run.
 The concrete example case:  Flight Simulator 2 . As above mentioned, it is on unproteced floppy. If copy all files into some DIR on hard drive it may run from there, or may crash. Will run on systems where not much low RAM is occupied. It is usually TOS 1.04 - 1.62 and well set hard disk driver. On Falcon will not run for sure. The reason is that Falcon TOS allocates most of low RAM. Concrete reason by FS2 is that game has relocatible code, which can run in any RAM position, but screen is fixed right below 512KB pos. So, if code is placed too high, it may conflict with screen data - crash, boom.

http://atari.8bitchip.info/playfhd.html     http://atari.8bitchip.info/plafh.html

  Running games with help of Floppy Image Runner:

Floppy image Runner is special program, similar to CD emulators on PC. It works from hard disks and with regular ST and MSA floppy image files. TOS will see installed  floppy image as floppy A, of course ROOT of it. So, regardless from which DIR we run Image Runner and floppy image it will be always as A.
Second benefit:  no hard disk driver install after 'reset', so no low RAM occupation - actually it is same as by running without hard disk, so FS 2 problem with too much RAM usage by hard disk driver is out. Of course it stays for many other games, menu disks.
Unfortunately program can not help with every game - it works only with regular FAT12 floppy formats, and only if there is no direct floppy access in code, no copy protection. I guess that some 40-50% of cracks works, more success with older games.

http://atari.8bitchip.info/imgrun.php

  Following is for little more advanced Atari users :

There are visible files on floppy, so it is FAT12, but after copying to hard disk it demands files from floppy A. Usual reason is that game code loads from absolute location, and not relative, and it is set to A:\  . In many cases it is solveable with some good Hex editor:  editing executable and removing A:\  before filenames - it would be actually simplest case of hard disk adaptation. More details here:  link .
Other way is to add small code to Trap #1 calls, where A:\  or \ will be removed. Of course, it is for experts.

  The low RAM conflict:

TOS uses low RAM at bottom (adress 0) for own purposes - there are variables, vestors, buffers etc. It is hardcoded, so can not be moved in some higher area. But many game is coded so, that uses that very low RAM too. It is not problem by running from floppy, as games have own (usually short) code for floppy access. But by running from hard disk, and need to load or save some data from/to hard disk - usually it is loading of new level, audio and similar,   we are in trouble. TOS works not, hard disk driver is destroyed by game ...  There are solutions made, of course :


The solutions used:
1:  Using RAMdisk for storing floppy data - but not exactly in same way as by Image Runner. Here reading of data from RAMdisk goes not via remapped system calls, but directly from modified (adapted, patched) game floppy loading code - where access to floppy is replaced with access to RAMdisk. Once adaptor gets game's floppy loading + disk change detection system it is pretty simple. Of course, all it requires RAM, and may be a lot of it, in case of multifloppy games.
But works fast, and no low RAM conflict.  I think that some games were fixed in that way already in 1980-es. And it was good not only for hard disk owners, but to avoid floppy swaps by multifloppy games. Probably most used by crew Superior.

2: FFLS - made by crew Superior, combined with RAMdisk option usually. The point is in usage of own filesystem driver for accessing files on hard disk. That driver is placed in high RAM, so conflict is solved.  Unfortunately, it is pretty limited and now outdated:  works only with partitions up to 32MB, and only with ACSI attached hard disks.  I guess that FFLS is actually floppy file Link modified for FAT16 and hard disks.

3: WHDLoad:  it is used by Amiga, not Atari ST, but I think that should be mentioned here, because problems with hard disk adaptations are prectically same. It resolves RAM conflict like:  before game start low RAM including OS workspace, hard disk driver is saved in high RAM area, state is saved too. Then must modify floppy access parts in game, so they will access file(s) on hard disk.  When game performs data reading request it will go to special code which will perform RAM content swap between low RAM (now occupied with game) and high RAM area where OS is saved. Then may load needed data. After it must again perform same RAM swap, and game may continue. Of course, it is just simplified description, there is much more thing in it...  So, it needs some RAM space too, but it is usually less than by RAMdisk solution. However, RAM swaps of couple hundred KB twice by each disk access take samo time, so system may be slow by too frequent disk accessing (many short file). There is some caching used against, according to WHDLoad author, but I don't know exact details. in any case, cache needs again some RAM. As I know WHDload is only for 32-bit Amigas, not for 16-bit ones. Likely nothing works with it on some Amiga 500 with 1MB RAM .

4: ULS - it is according to author WHDload ported to Atari ST, so same concept. It is good in case when no many short disk access. Same problem as by WHDload.
ULS means Universal Loading System . But I found it misleading - all what ULS does is RAM swapping and using regular TOS calls and installed hard disk driver. Nothing from announced easy game 'patching' - except cases where floppy crack is done with 'fileing' in known way.

5: Gamecache on hard disk - idea is to use special, gamecache area on hard disk, where simple data access by location is performed, so simple code can do it - no need for filesystem. Before game start need to fill gamecache with proper content, then may ran game. Data access is very similar to RAMdisk-wise, as code is simple. I made drivers for IDE and ACSI hard disks. I achieved that some games can be run from hard disk on machines even with only 512KB - F1GP for instance. But it looks that it is not relevant, and no people with hard disks on Atari and less than 1MB. Of course, downside is need for special area on hard disks, but it is not big deal for someone making hard disk drivers    This is abandoned in meantime in favor for :

6: Gamex, GOS 4-5 .
  Gamex is my system where may abort gameplay and permanently save current gamestate, then continue later at same point. It is combined with GOS (gaming OS), which is actually GEMDOS 0.15 (So part of TOS 1.04) reassembled, modified to run in high RAM. With it, low RAM conflict is resolved and we can  have fast hard disk access, without huge RAM swaps.  But it is not only benefit. GOS 4 resolves TOS incompatibility problems too, in most of cases. With it, games as Iron Lord, Skychase etc. run well on machines equipped with TOS 2.06 (Mega STE) , Falcon , TT . I said 'equipped with' instead 'under ...', because in fact then games run under TOS 1.04, which is in RAM .




More follows ....