Wanna deal with Atari games ? Some hints, some ways ...

[ParanoidLittleMan]

I'm trying to start something constructive here at beginning of new year.

Seen that some people is interested in this - like guy who wants to use some special controllers for better gameplay. And generally, people is curious how so called "cracking", "patching", adapting goes.

 

For start: this is not easy. Source codes are not available for some 99% of games. Most of them is coded in ASM, or partially in ASM . Beside 68000 ASM knowledge you need knowledge about Atari ST + followers (TT, Falcon, if want make it compatible with them) , and even pretty good knowledge about TOS - for instance because bigger %-age of games using TOS calls (and I know what I'm talking after dealing with over 1200 games) .

 

I will not talk here about 'cracking' copy protections. Only that it is now much-much easier when you have some STX image (or SCP), so images which hold copy protection too - with using Steem Debugger instead real Atari .

Yes, for efficient work Steem Debugger is best tool. My opinion, of course. If someone don't agree (Hatari people ) please start new thread with your version how to do this ...

All it needs time to familiarise with, of course. Plenty of time.

 

First question: what is target system ? What storage ?

Like: only Atari ST, STE. All from ST to Falcon. Only STE ... Sub question: What TOS versions ? - All regular. Regular + MagiC, Mint (even if they are not actually TOS v.)

Floppy only. Hard disk or rather Flash cards now. Both.

 

And here comes first big diff. between 'cracking' and some more up to date 'adapting' for hard disk usage. To make it work from mass storage, in most cases serious changes are needed.

 

And just crossed my mind: some prefer faithful copies of original. Well, this is not about it. Stop reading

 

For the end of this first post, I will describe already used and possible ways of replacing floppy access with hard disk access, in case of Atari ST games.

 

1. No need to do anything, except copying game files to hard disk. Some games even have installer APP for that. But that's less than 5% .

 

2. Little harder: need to copy all files to hard disk, but it will work only after changing filename + path strings in game code - to relative one.

Like: there is A:\TITLE.PI3 or a:\title.pi3 in code - obviously, it is made with floppy A only in mind. So, just need to delete that A:\ - in Hex editor by moving name self 3 bytes left (lower), and add 0 terminator to end of it. Then it may work well from any directory on hard drive. I did it in many cases. Sometimes was enough, sometimes further changes were needed.

 

3. Instead filename based access, game using XBIOS 8 floppy access (Sundog) . Then need only to copy ST image file to hard disk, and run launcher program, which will first change XBIOS 8 (floppy read) and may do same with XBIOS 9 if there is some write (for Highscore or whatever) service code, that access that ST floppy image file instead real floppy - more precisely instead FDC in Atari - since we have not HxC and Gotek devices

 

4. The hard part: games which use own (custom) direct FDC access code. That needs really good knowledge of mentioned things above.

And we have diverse solutions to replace FDC access with hard disk access:

 

A: FFLS by Superior . It used own, and only ACSI port hard disk access code + FAT16 filesystem code, but only for partitions up to 32 MB - no BigGEM partition support. It worked pretty well, and they released about 100 games with that system. It was more than 20 years ago.

 

B: ULS by D-Bug - they took principle used in Amiga WHDLOAD - what is basically swapping of RAM areas during gameplay and disk access. That makes possible to use installed hard disk driver. Of course, many other things need to be done that it work.

 

C: Mine system, used with Gamex type releases - it is actually similar with FFLS in using hard disk access code without need for RAM area swaps. It can move up PP drivers (they are PC-relative code), or install AHDI or Hddriver in high RAM with little tricky solutions. That means faster work, and lower compatibility - since other driver versions are not supported.

What about FAT16 filesystem ? Of course, 32 MB partitions are past, we need support for all what TOS 1.04 supports (as latest ST TOS version) . So, why not use TOS code self for it ?

Yes, that's how I solved it. Disassembling GEMDOS part of TOS 1.04, making modifications, and running it in high RAM. Needs about 90 KB + workspace. And disassembling of TOS 1.04 resulted in another huge benefit: solution for TOS version compatibility problems. Little different mods in it, and then that's good for games using TOS calls for floppy access. No need to 'patch' game code for different TOS versions, we can use TOS 1.04 on any machine - starting at ST with TOS 1.00 up to Falcon. Of course, will need min 1MB RAM for 512 KB games, but that's already requirement when want running games from mass storage. And there is still space for statesaves, for saving TOS workspace content - talking about ROM TOS in machine.

 

In next part comes HAGA and complete new, most efficient solution: RIA (what needs improved TOS ROM) .

 

To be continued ...

 

[ParanoidLittleMan]

D: HAGA - what is just 'hard disk gaming Atari' abbrev. Basically same concept as Amiga WHDLOAD, and closer to it than ULS - because it used common library file for usual tasks like setecting HW, RAM swap, hard disk access, statesaves, exit to Desktop - like it is in case of WHDLOAD. You may see that file named HAGA is present with almost every my new adaptation.

 

And that would be basically all, what was used so far - not entirely true. I made some special system, with RAW hard disk access about 10 years ago. That's fastest possible disk access, no need for RAM swap, but it takes some RAM, and is hard to find it in case of game what utilizes almost complete 512 KB RAM.

 

E: RIA - Raw image access - with very low level disk access, but this time in ROM. So, minimal RAM usage. It basically works with image files placed in special area (partition kind) on media. No fragmentation, all access is linear.

Of course, disk access code in ROM is not same as hard disk driver - but we don't need it in games, especially if can work faster. The goal is to have very simple access to needed data, and there may be space for some saves - like high score or even game state. Yes - this means that you can have state saves on Ataris with only 512 KB RAM !

In TOS 1.62 and 2.06 there is space for HAGA functions too. And actually in 1.04 it can be solved too. But that part of improved TOS is not done yet. I made tests with some games, and changing HAGA v. to RIA is not hard, and can be done fast in many cases. For simpler usage, there will be no diverse low level driver versions in TOM TOS, only one - like basic ACSI, ICD ACSI (UltraSatan), IDE . Yes, that means usability with only 1 type of adapter, but that will be OK for average user. Who don't like it may use TOS switcher. All depends from interest.

Related with this is using images with regular TOS FAT16 or FAT12 filesystem with Virtual Floppy feature of improved TOS . That uses same low level RIA driver.

 

This is about what I know that exists. What means not that someone, in some time can not create some new, and even better system.

 

Just few words about TT, Falcon compatibility. I already wrote about it on diverse places.

Main difference is CPU - 68030 has large stackframe, and code what is based on 6 byte long stackframe at 68000 will fail on 68030 where is is 8 bytes.

Then, there is so called 'pipeline bug' - that's term what I gave to it, and I really did not see that someone other dealt with it. Appears by games like Maupiti Islands, Parasol Stars, and especially in Infestation (several locations).

It will fail on 68030 when self modifying code performs changes in code very near to at moment executing instruction - in range of couple to some 20 bytes, ahead. Then those writes to RAM will be not read from RAM by CPU, because it is already in CPUs pipeline - which reads some 3-4 instructions ahead, to make work faster.

Of course, both cases - stackframe and pipeline need changes in game code, and that needs experience with 68xxx CPU coding.

 

TOS version problems: there is plenty of possible problems - low RAM usage, input read, C-Timer (2.06) . Usual culprit is not well written SW, But can blame Atari too for not giving good enough documentation for programmers, developers. Joystick read via TOS functions is one of most common problems, even STOS suffers from it. Just because Atari never wrote clear and accurate usage guide - of XBIOS call 34 - Kbdvbase and how accurately read joystick packets.

 

Some pages with more info, instructions, and even some ASM code:

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

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

[ParanoidLittleMan]

And in third part: improving games.

Yes, there is lot of them which could be better - with scroll for instance - Like Great Giana Sisters, very similar Hard 'n' Heavy

Using STE DMA audio instead PSG - that's especially effective when game plays sampled audio via PSG chip. Because that slowdowns game play - best visible in Prince of Persia.

Done with Dungeon Master and Chaos Strikes Back too.

Special improvement is playing audio track in background, from mass storage, with practically unlimited length - may be hours. STE, Falcon, TT only.

Then, there are games just done not well, even if their code is not that bad. Uridium has relative good scroll, but is not really playable, because slow controls, better said poor manueavrability of player's ship.

That needed lot of changes in input handling code.

OIDS had some strange solutions in screen draw, and that limited graphic and play speed too much, without good reason.

Using blitter can be really useful, and boost up screen draw. Easier case was game Road Runner.

But generally, it is really very hard and needs experience. Not to mention time. As things are now, really can not make self to even think about doing it again. Feedback and support is poor.

Instead it, list of my improvements, with links to DL:

 

Hard 'n' Heavy: http://atari.8bitchip.info/TestMe/HNH/HnH.html

Giana: http://atari.8bitchip.info/SCRSH/greatgs.html

Prince of Persia: http://atari.8bitchip.info/SCRSH/princofps.html

http://atari.8bitchip.info/ASTGA/P/princofp.php

Xenon 2: http://atari.8bitchip.info/SCRSH/xen2s.html

Cannon Fodder: http://atari.8bitchip.info/SCRSH/cannonf.html

Dungeon Master: http://atari.8bitchip.info/SCRSH/dmrd.html

Chaos Strikes Back: http://atari.8bitchip.info/SCRSH/chsbs.html

OIDS: http://atari.8bitchip.info/SCRSH/oids.html

Hey ! It can work with analog joysticks too.

Uridium: http://atari.8bitchip.info/SCRSH/uridium.html

 

All it needs good assembler/68000 coding knowledge, some searching on WEB - for instance for quality samples for some game.

And again, without Steem Debugger all it would be much-much harder.

I think that some SW, game companies would pay just like that 1 million $ in 1985-92 for something like that. And here mean only SW - where can trace everything easily, What was price of so powerful computer in those years, like what is power of some average PC in last 6-7 years ? I really have no clue. Probably min another million With that, they could develop games 10x faster.

[ParanoidLittleMan]

I will add here some thoughts, which were not planned when I started with this thread.

I see some new ST, Falcon games arrived - and that is not rare case in Xmas period.

So, there is Cometball for Falcon and Iceblox Plus for ST . Will not talk here about which game is better or about gameplay, graphic at all.

Both releases show lack of experience in TOS, Atari ST, Falcon, and even generally game programming - yeah, say me now that "shut up, you never wrote any game" .

And actually I wrote a game in 1984 . But the point is that I see so trivial problems in forum discussions - one was here, in general ST, Falcon section.

How to set specific resolution, screen mode on Falcon ? How to write to address $484 on Atari ST ? The answer is so obvious - look in literature, docs. Do some tests with tracer SW (MON), emulator. Order some Atari ST programmer book. Wait ... it's 21-st Century now ... Why to bother with it - ask in forums. Well, that worked so-so in case of Iceblox, but in case of Cometball there was refusal, and even something what programmer never should ask. Of course, I was sarcastic - today no need to order, pay literature for Atari ST (and it is not possible, of course, after so many years) . All is online, mostly for free.

 

So, those game programmers in period 1985-1992 were some super intelligent ones - they could make a game without Internet ! Without multi GHz PC and cross compiler or assembler what can do it in sec-two. They worked on low res monitors with flashy screen at 50 Hz .

I think that some were really it. Could give here some names, but this thread is not about programmers.

 

Now, some may say that I talk about need for literature, docs, while myself disregarding them - for instance that talk about how I solved detection of keyboard release in HAGA game launchers. First, they (EmuTOS team, part of them precisely) have no clue about how much I using literature. I bought Atari ST and Atari ProfiBuch in same time. And used that book regularly, until this days. It's now complete salad, but I can look some things faster than with computer. I have some comments in that book, what I added - yes, you guessed - mistakes, errors, missing details. The sad truth with Atari is that they made some things really not on level. That's not disrespect - nobody is perfect, not even some Silicon Valley Company (if Atari was really there, I dunno ) .

 

And I will list some of them here, just from top of my head:

Poor documentation - missing details, errors . Like 'Hitchiker's Guide to the BIOS" - they even self said that it may be not complete, error free. Sadly, some things were never corrected, added. Examples: lack of explanation how to read joystick via TOS functions. Error in ACSI port programming example (what was present in 1987 edition of ProfiBuch too, copied 1:1 ).

HW design error in STE - bad circuit design around Microwire chip, what can 'mix' diverse audio sources - the result is that YM sound is much louder than DMA sound. And can not set proper ratio, even if it should be possible - available doc's have details about it, but it works not as should.

STE DMA chip problems. Even if some try to deny it (by offering own solution - I guess that it's actually best way of advertising ) , that's certainly caused by not enough testings, like in case of bad sound mixing. In other words, STE is launched in rush.

Falcon's implementation of PSG (YM) chip missing shadow addresses. That caused lot of SW to crash. So, they added so called 'STE compatibility mode' - but that name is very improper . It is just 1 shadow area instead 127, and nothing more, so video is still not 100% STE compatible (in STE video modes) - but that problem causes crash or other problems in much less SW.

And something really barely known: STE's advanced joystick ports have analog inputs. But Atari never produced joystick what using them.

So, why we should wonder that audio DMA, extended colors and other things were not used much in SW ? But there is always a chance to correct this problems

[sunn1]

Really interesting read. Especially informative to learn about HAGA. About improving things: it would be nice if all future HD adaptations would support advanced joystick ports. Even with just digital dpad. I'm sure hardware would emerge if there would be bigger demand than just Jaguar users.

 

On a sidenote: here's a cool controller. Not sure what happened to it, though. http://www.retrocollect.com/News/new-atari-jaguar-controller-in-development.html 

[ParanoidLittleMan]

Adding support for all HD adaptations ?  That's something what affects only STE and Falcon users. Other machines have not such ports.

I must say that I will not deal with it for sure. My STE is broken at moment, and will be not fixed soon. I'm behind 3 moves in last 1 year, thanks to greedy, lying, low breaking people. Have lot of things to do, and improved TOS is priority now.

 

So, if someone wants to deal with adding advanced joystick support code to games - and that may be of course not only for HD adaptations, but for floppy versions too - he is welcome.

I will give support as much I can. That means that I can give my source files of hard disk launchers and some advice. But that's easier part. To be able to add some new code to existing game code pretty much knowledge is required:

68000 ASM

Atari STE HW knowledge

Being able to trace well game's machine code. Recommended is Steem Debugger.

Lot of time and patience.

 

[walter_J64bit]

6 hours ago, ParanoidLittleMan said:

Adding support for all HD adaptations ?  That's something what affects only STE and Falcon users. Other machines have not such ports.

I must say that I will not deal with it for sure. My STE is broken at moment, and will be not fixed soon. I'm behind 3 moves in last 1 year, thanks to greedy, lying, low breaking people. Have lot of things to do, and improved TOS is priority now.

 

So, if someone wants to deal with adding advanced joystick support code to games - and that may be of course not only for HD adaptations, but for floppy versions too - he is welcome.

I will give support as much I can. That means that I can give my source files of hard disk launchers and some advice. But that's easier part. To be able to add some new code to existing game code pretty much knowledge is required:

68000 ASM

Atari STE HW knowledge

Being able to trace well game's machine code. Recommended is Steem Debugger.

Lot of time and patience.

 

Too bad, there isn't an app that just patches games to make them work with the enhanced joystick ports.

Edited August 7, 2019 by walter_J64bit

[ParanoidLittleMan]

Of course that no such app. And there will be never such thing. Adding extra code to some game's code is very complex and varying process.

Must say that you have completely wrong picture about it.

It starts with sometimes very hard problem: where to place that extra code ? Not much space is needed. About 200 bytes should be enough. But game may use any RAM space - so you need lot of tests to find really unused space.

Then, every game has different input reading code. So, you need to adjust added code to it. And that's really hard, needs experience. Patching SW can do only much-much simpler things.

Not to mention that games are in many cases not with regular files. So, what to patch ?

 

[mikro]

On 1/1/2019 at 3:11 PM, ParanoidLittleMan said:

Then, there is so called 'pipeline bug' - that's term what I gave to it, and I really did not see that someone other dealt with it. Appears by games like Maupiti Islands, Parasol Stars, and especially in Infestation (several locations).

It will fail on 68030 when self modifying code performs changes in code very near to at moment executing instruction - in range of couple to some 20 bytes, ahead. Then those writes to RAM will be not read from RAM by CPU, because it is already in CPUs pipeline - which reads some 3-4 instructions ahead, to make work faster.

I presume it is not but - isn't this just a CPU cache issue? I have never heard of 68030 not being able to run SMC code with caches off.

[ParanoidLittleMan]

2 hours ago, mikro said:

I presume it is not but - isn't this just a CPU cache issue? I have never heard of 68030 not being able to run SMC code with caches off.

CPU cache is one thing. Pipeline is another thing. You can look online about how CPU pipeline works. The point is that it reads ahead multiple instructions, for faster work. Because decoding it, preparing execution needs some time. It may be called partially simultaneous execution of more than one instruction.  CPU cache is for reading it faster than from main RAM, what is slower than cache (in CPU, or special cache RAM, like in Mega STE) .

The effect in case of pipeline is, as said that writing in RAM (or cache) very near to currently executing instruction, ahead  -  will not affect it's execution, because it is already loaded in pipeline. Therefore old content will execute.

You may test it self - but I guess that will need real HW - so TT or Falcon. Doubt that Hatari emulates it properly.

[mikro]

14 hours ago, ParanoidLittleMan said:

The effect in case of pipeline is, as said that writing in RAM (or cache) very near to currently executing instruction, ahead  -  will not affect it's execution, because it is already loaded in pipeline. Therefore old content will execute.

Interesting. Anyway, fix should be easy in this case, one NOP before the read should flush the whole pipeline.

 

I can imagine how much fun was this pipelining behaviour to discover. :)

[Cyprian]

sometimes ago I tested following code on real hardware ST/TT and the final result was different than under emulators:

	lea	Kod_TEST(PC),A7
	moveq	#0,D7
	movem.l	D0-D6/A0-A6,(A7)
Kod_TEST:
	REPT	32
		addq	#1,D7
	ENDR

If I remember correctly, 68030 (all caches off) had more prefetched words than 68000

I'll recheck that after my vacations.