|
This is intented for people with some 68000 assembler knowledge, Atari ST(E), TT, Falcon, TOS knowledge. There is people interested about subject, so I will try my best to explain things and make it less hard - because it is not easy for sure. Will start from simplest case : singleparted game, which uses not TOS calls. The goal is to make adaptation (some call it patch) of game, originally distributed on floppy(es) , which will run from regular Atari format hard disk (or some Flash card), on any regular TOS version, and any Atari ST(E), Falcon, TT . Additionally, we want gamestate saving option at any moment during gameplay - what means that can continue at point where saved, by few mouse clicks. Plus simple exit from game to Desktop. Of course, some trainer options may be added. What is HAGA ? HAGA is just abbrev. of 'hard disk gaming Atari' . In fact it is special file, containing functions requred for our goal, described above. So, there is HW test function, which detects machine type, RAM size , TOS version . Function to set RAM usage, function for reading/writing from/to hard disk - what is intended to replace game's floppy access. And more ... Basically, it is same concept as Amiga WHDLoad. HAGA would be master, and launcher would be slave. Difference is that HAGA is completely free and source of it will be published soon - after some cleaning of source file and solving multiple pexec calls. What is not in VHDLoad is usage of PMMU of 68030 for faster disk access, and so called GOS - TOS 1.04 in RAM for TOS calling games. And statesaves . TOS 1.04 in RAM solves TOS compatibility problems, and more important: RAM usage problems, etc. Requred SW, Tools: You need some assembler, of course. Source files are made for Devpac 3, so best that you get it. May work in some other too, but I don't know, and will not make versions for other assemblers. Devpac 3 assembles correctly 68030 PMMU instructions for instance, what is not case by most assemblers. Steem Debugger is a must - to analyse game code, to do tests. For high-color screens displayed before game start you need to prepare BMP format pic. with some SW. I use Paint Shop Pro 9. Format is unpacked BMP, 320x228-273 px. 16 million colors. And need BMP 320x240 , 256 colors for Falcon, TT . SW for converting in HST format is supplied (thanx to Cyg for making it so good). Packer into C3 format is included. For start, simplest case: singleparted game. Template is for game Botics. You need to correct some things for your game. Most of it is easy. What is hard is to find place in game code, which reads keyboard pressings, to add exit to Desktop and savestate. I do it in Steem Debugger by setting monitoring of read from address $FFFC02 - when game runs . Then press / on NumPad - Steem Debugger (SD in further text) will stop, with code $66 readen from IKBD. Press OK, and will stop again with code $E6. We need later, because it is for released key / . That prevents some possible problems. In game code after that come usually some tests, necessary to filter mouse, joystick and keyboard commands. Of course, we need keyboard command, so to put branch little later. Usually there is something like : cmpi.b #$F6,d0 ; bcc label . Keypress code is always below $F6, so after that we may put jmp to gamex label. It may be short absolute jump if we can place our code in low 32KB of RAM. Of course, what is overwritten with that jump must be executed at exit of our gamex code - see source code. Codes are not ASCI codes, but Atari's keyboard scan codes. When everything is done, you need to test it - first in SD, of course. If it is OK, it will 99% work well on some ST, STE. Work on Falcon, TT: This is hard part, and if you don't have those machines for testing, can not be sure will it work or not. Most common problem is stackframe, what is different by 68030. Fortunatelly, there is modded version of SD to catch such errors. But other errors are possible, and they may be timer and other related - pretty hard to determine and fix. For TT, which has much faster CPU, what can not set to lower clock slowdown may be needed with some games to be playable. More about later .. Template for singleparted games, not using TOS calls, with some tools: Download SP_LA It includes launcher source template SPNOG.S (Botics) , OVSSH.S - put in include DIR of Devpac 3. higheSTcolor17.exe - converter from BMP to HST format (Windows), do.bat is for easier usage of converter. STPACKER.exe (Windows) for packing into C3 format - on ST it would be very slow. Second template, for singleparted game, using TOS calls, with regular TOS relocatible executable. By such games we use TOS 1.04 part without AES, modded for our purposes, and running in high RAM. Still no disk access after start. I just finished adapt. of game Conqueror , and it is good as template and for learning some things: Conqueror has actually 2 TOS executables - first is intro, second is game self. Intro runs game executable via pexec function, and part of intro remains in RAM during play too. Only thing what it does then is checking copy protection. As I removed it, no need to keep any part of intro in RAM when game part starts, so can use special way to run game from same RAM location as intro - see in source COLA.S . Because that, we can consider this as singleparted. However, some tricks were needed to make it work - to avoid delete of packed data, what is loaded in low 512KB - by pexec. I lowered Phystop to $40000 before running GOS (TOS 1.04 in RAM). There is no enough space in 1MB machines to load 220KB data in upper 512KB, because there goes TOS save, GOS, HAGA . Better solution would be to use start with fastload flag on, but it is not set in current HAGA version. After solving protection removal we have 2 executables - intro and main game - and main can run without intro part in RAM. Need to pack both with C3 packer. For TOS executables we need 2 launchers : first is for starting from regular Desktop, and is very similar to launcher for non-TOS games,. Second launcher is regular TOS executable, what virtually AUTO starts in GOS, and in lower RAM area than possible without GOS - address is normally $AB52 . In second launcher we depack game's executable(s), again to same location. All code can be placed in, by AUTO run wasted space between $611C and $A84E . Only Dungeon Master uses that space from games I examined (and it is not low count) . In Conqueror own code is used to read keyboard, so again need to examine it with SD (see above). But GOS has support for intercepting key pressings - if it goes in game via TOS - then it is really easy to solve Desktop exit and statesaves. Hopefully in next template (example) we will deal with such game. Download SP_GOS One more template with singleparted game, with Hi-Score load/save on hard disk : Game is Yolanda, which does not use TOS calls, except few XBIOS calls by loading. It loads in 6 sections, but can be singleparted, because after last load no more disk access while playing. Only disk access then is highscore save to floppy. Of course, we want it on hard disk. So, need to perform some jumps on proper locations to our code, which will do it on hard disk, + loading from hard disk during start. See source. May see how copy protection is fooled too. Download SP_HIS Template for multiparted game, using TOS calls, with regular file load via Trap #1 functions: Game is Pixie & Dixie - it uses regular TOS executable, and there are some 75 data files with total size about 550KB - and most is ICE packed. Game works with 512KB RAM. So, it must load some files during play. This concrete title is not copy protected, and could be fixed for hard disk run by simple editing of executable, by removing all 'a:' before filenames with dir. But we want statesaves too, so will use HAGA and GOS . Launcher is very similar to singleparted, using TOS calls. Difference is in GOS launcher file - there are filesystem functions for RAMdisk, like open file, read bytes from file, close file, and related. Why we need RAMdisk ? Because of HAGA concept, which uses installed hard disk driver. It is located somewhere in low RAM, about location $10000 . But that space is space where most of games runs too. So, we perform RAM swap between game and TOS with installed hard disk driver when some disk access is needed. It is little slow, so to avoid slow work with lot of files, file chunks, we use RAM as some kind of cache, RAMdisk. Even with 1MB machines we can have 200KB allocated for that purpose. If RAMdisk is larger than it, we use it as read-ahead cache. So, we need to make RAMdisk with all files, which may loading during game. In zip is short proggy, which will create it. You need to copy all files in freshly created DIR, if possible in order how they will read in game, and as last copy file ZZ.TOS . Then run it, and will get file FSRD which contain CAT of filenames and ther locations in RAMdisk, and RAMdisk self. Need to cut 2 parts from. In this concrete case we have actually 3 sections, as there are 3 subdirectories on floppy, but joined in one file. May see in source how code accessing proper section by looking first letter, what is first letter of DIR containing files. By most of games no separated subdirectories. There are some simplifications in compare to real FAT16 filesystem. Only 8 characters of filename are considered, without extension - because we have no same ones. If there are same filenames, with different extension, need code which compares whole filename + extension. Only 1 file handle is used, because no more than 1 file opened at once. Otherwise need code which stores file position for each opened file. And considering statesaves and exit to Desktop, all you need to do is to put 1 for label gxIkbg in file PIXHA1.TOS .Then it will use GOS keyboard code for them. If default keys / and * are not OK for game, or your taste, may change them at part: IFNE gxIkbg move.w #$E6E5,$6130.w ENDC Need to enter scancodes for released keys (scancode + $80). Download MP_GOS And this is category (type) of Atari ST game, what is most used, with some smaller variations, of course. Instead TOS relocatible executable may be executable for concrete RAM address, and it is usually pretty low set - like $CC00 - what means that you can not run such games from hard disk just like that, because game will destroy hard disk driver. This is why we need GOS and HAGA. Template for multiparted game, not using TOS calls, with custom, direct FDC access code: Game is The Untouchables - and it is good example - it is on 3 floppies, so need to find game's floppy change/detection code and serving data from proper floppy image, without need that user do anything about it. The hard part with custom floppy access code is to find and understand floppy reading rutine. It will be certainly hard without experience, but no other way . Usually, there is some subrutine, which reads from floppy area to destination RAM location, which gets parameters in CPU registers, or in some memory block. In this case in a0 is destination address, d0 holds sector count for load, d1 holds start sector (it starts by 1 on floppies) and d2 holds track # . Because floppies are with 10 sectors/track we need to multiply d2 with $1400, adding (SS-1)*$200 etc ... Because with 1MB machines no enough space to hold whole floppy image (400KB), we use read-ahead cache, what loads currently needed data from hard disk into cache if it is not in RAM. If there is some file longer than cache size, it must be loaded directly from hard disk - but that's not much present. In case of Untouchables we have additional problem - every level is with own code, so we need to find keyboard reading in all of them, and insert link in all. There is a lot of things to correct, and many links. And it is not all what I did - some corrections were inserted directly in floppy images - like changing level skip key combinations, then removing writings to Video freq. register in all levels, otherwise will lose video on TT and Falcon. Download MP_DFA With this, I covered most present Atari ST game types. Dealing with copy protections is topic for self, I will not go in this, at least not without some demand. Using cracks as base for hard disk adaptations may seem as good idea, but I avoid it. The reasons are: there are many bad, incomplete cracks around. Then, it is often easier to understand original's code than cracker's, then there are diverse packing systems, usually slow depacking, so need to repack, what is another complication, etc. Removing copy protection with Steem Debugger is not so hard as it is on real HW, and there is a lot of STX images available. There is SW for converting STX to ST format - if floppy is with regulat sectors. Then copy protection data is of course lost in most of cases, but we lose it for sure, as running from hard drive. ST image is good for our purpose - and it means less work than extracting all files separately. If game has some unusual floppy format - like trackwise data, without sectors, or special sectors then is best to use game's floppy code to make image. PP , Oktober 2013. Questions, suggestions please in e-mail or in forum(s) .
Menu Properties Quick Reference hcnt: 7193 |
