Doing game hard disk adaptation

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Post Reply
Petari
Posts: 129
Joined: Tue Nov 28, 2017 1:32 pm

Doing game hard disk adaptation

Post by Petari » Fri Dec 22, 2017 12:09 pm

This will be some kind of blog.
It may be that this will be my last game adaptation. People just can not imagine how slow and demanding process can it be.There is no enough feedback. Some say: 'it is easy to do hard disk patches' - then how that nobody except me deals with it in last 3-4 years ?

So, here is the case of Doodle Bug - that game is on my site for 8 years. Only this days I got report/message that it crashes after level 3 or 4.
Played it with heavy cheat, and yes, it crashed after level 3 - actually debug screen appeared with lot of numbers. I used then as source ICS crk.
Now STX is available, and I tend now to not use crks as source if possible. So, I went in doing new release yesterday.
First thing is to examine STX file, see can it be converted to ST image, are there regular files, etc.
It can be converted, there are regular files, and there is almost regular Rob Northen Copylock, later version. All it suggested what will be TOS calling program. But no - it bootloads, has some strange code at start, then jmp $400 .... So, TOS is killed, and it must using own, direct FDC accessing code.
Still, not big deal. I see 72 files for game, not counting starting file.
R.N. protection was overriden in couple minutes, then I need to see how game's file loader works. And that was hard part in this case. Something weirdest, most inefficient what I seen - and I seen really a lot. For instance it will load root DIR of floppy before every file access again and again, and so, that always 1-1 sectors, always on same address. Hmmm - maybe they used Spectrum with 16KB before, and learned how to work with little RAM :D
So, I spent some 1-1.5 hours while realized how loader works. That is slow for me, believe me.
Game using RNC packer, and that is not supported in usual depackers for Atari ST. And is very slow. So, I will repack all files with some better and faster one. And that is what will take maybe couple days - there are 72 files, or 78 ?? There is mismatch in file count visible on floppy, and in file catalog what is in game code. I unpacked so far some 8 files, this is some kind of rest now :lol:
To be continued ...

Petari
Posts: 129
Joined: Tue Nov 28, 2017 1:32 pm

Re: Doing game hard disk adaptation

Post by Petari » Sat Dec 23, 2017 7:53 pm

Further depacking and examining resulted in abandoning idea to repack all files. Game depacks some immediately, some stores in RAM packed, and depacks later, some are even unpacked. And I have no good solution for packing short files. So, decided to repack only 2 longest files, because their depacking is what is too long. After that, it went pretty much usual way - except that I needed to edit by hand much more than in other games - complete new file table. There were some places in code to patch, to ensure correct load of some files.
And it works now. I reached 'Fortress of Fear' level.
http://atari.8bitchip.info/TestMe/DOODLEBT.ZIP

Time spent on usual things: getting and examining STX - 5 mins
Overriding copy protection - 5 mins
Understanding game's floppy code - 2 hours
Dealing with game files - 5 hours
Doing necessary code for replacing load from floppy with hard disk access, and other things - 2 hours
Trianer, gamex - 15 minutes (already had trainer locs)
Testing - so far about 1 hour ....

Petari
Posts: 129
Joined: Tue Nov 28, 2017 1:32 pm

Re: Doing game hard disk adaptation

Post by Petari » Sun Dec 24, 2017 1:04 pm

Playing further, then after Fortress Fear - crash. Examination showed that there is high RAM corruption during gameplay, what destroys cache content. What means that 1 file in cache getting corrupted. Fixed it with different file layout. Then it appeared that time is too short on later levels - so 1 cheat more - unlimited time. It is too hard even with unlimited energy cheat, and is just too slow at 8 MHz. So, played at 14 MHz in Steem - much better, approx as on Mega STE . And finally, finished.
Verdict: nice, big levels, not repeating too much. But slow, too hard without trainer. Play on Falcon, Mega STE if can.
If DL-ed before, DL again from same loc (post above) - corrected v. is now there.

+ time spent:
Fixing memory corruption problem - 1 hour
Testing, other fixes - like Falcon IDE port disabled by bad PSG Mixer settings of game - 3 hours
Making YouTube video - 1hour .
So, totally about 15 hours of effective time is spent for this (actually more, because I had some things done in first release). More than average time, but there were some games needing much more time.

Petari
Posts: 129
Joined: Tue Nov 28, 2017 1:32 pm

Re: Doing game hard disk adaptation

Post by Petari » Mon Dec 25, 2017 8:02 am

My point in this thread, much more is needed in fact. The testings - there are some really nice games like Ishar, Mystical ... but I just don't have time to make some stronger progress in them - and that is just a must - to reach all those locations where manual protection will pop up. Sadly, it seems that Ataricrypt is too busy this weeks too :D So, those games are just put aside, waiting miracle :lol:

Now, some of common bad coding practices in games, which make them incompatible with some HW, some TOS versions. And not to blame only game coders for them, poor docs and some changes in HW are responsible too.

PSG chip mixer settings, port 14 settings - upper 2 bits in PSG mixer define are ports A & B input or output. That just must be intact - both must be outputs, especially port A.
Mega STE and Falcon use upper 2 bits of port A in special purposes - if floppy code change them program will crash, or IDE port on Falcon will not work.
That was case with mentioned game here - Doodle Bug, and with many others.

Was it ever noted in Atari docs that do not change those bits ? Or better said: general rule to not change those bits in any HW register which are 'reserved' - better said, to consider all those unknown ones as reserved ? I don't see it in Hichhiker's Guide. What I see is:

"The Guide's intended audience:
Application writers (who will find some of the functions and hints here invaluable);
Those wishing to make use of some of the ST's hardware-specific features
(hacking palette colors, configuring the RS232 port, and so on);
Those writing device drivers, videogames, or cartridge-based applications;
The habitually curious (including trivia trippers, information junkies, and document-
ation addicts).

For many reasons this should still be considered a preliminary document. A whole host of
things remain undocumented, many GEMDOS issues have not even been approached by
our friends at Digital Research, and there are a whole lot of features we'd like to add to the
software."
Above actually explains a lot. And is from 1990, not 1985 .

Patching those incompatible code parts in games, so they work well on Mega STE, Falcon may take pretty much time.

Other HW incompatibility is Falcon's PSG port shadow address range - there is no such actually. While in ST(E), TT it is $FF8800-$FF88FF, on Falcon is only up to $FF8803. Then they added so called STE bus compatibility mode, what results in not getting bus error when accessing some address $FF8804-$FF88FF - but you will not get sound at all ! Really lame.
Again, needs patching, and it usually fits not in place, so some jumps to code that must be placed in by game not used area (what is another problem, to find such) .

So much for this, not ordinary day. Atari is just as bad kid - we still love him :lol:

Post Reply