Doing game hard disk adaptation

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

Moderator: Petari

Petari
Posts: 174
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: 174
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: 174
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: 174
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:

stephen_usher
Posts: 40
Joined: Mon Nov 13, 2017 7:19 pm

Re: Doing game hard disk adaptation

Post by stephen_usher » Tue Apr 17, 2018 10:12 pm

I've downloaded a number of HD enabled games from what I think is your site, atari.8bitchip.info and it's an impressive number which work on the TT!

One game I like to try to play badly is "Virus" but your conversion has a problem (both on my STE and TT) and that is that the ship is far too slow. In the welcome screen the ship rotates quite slowly, a similar speed to the ships in Elite, whereas it should be spinning around very quickly. When the game starts the demo mode the ship seems like it's in treacle so the demo doesn't work properly as the ship never catches up with the baddies and never gets to the next level.

Maybe it's the original cracked version which is the problem, I don't know.

If you're interested in fixing it I can help test things for you.

Similarly, if there are any other games you'd like tested on a real TT I'd gladly help, though I can only transfer files on a floppy (HD) as my NetUSBEE-lite doesn't work on the TT.

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

Re: Doing game hard disk adaptation

Post by Petari » Wed Apr 18, 2018 8:17 am

I have original disk of Virus, and adaptation is based on it. Copy protection was really simple, and I played it pretty much at time (around 1988) .
What causes slower rotation of ship at start is added flicker remover, and that's noticeable especially on TT. The goal is to have normal screen generation, without artefacts and tearing, prevent too fast gameplay, and not that ship rotate fast :D Flicker remover is used in many games, and not only by me/ Latest example is Gauntlet. To explain: video generation must be syncronised with draw of the screen on TV/monitor. If you change content of screen in middle of draw on TV, it will be ugly, 2 different (partial) contents will appear on 1 screen. To prevent it, we syncronise screen generation with vertical refresh (what is actually start of 1 screen draw on TV). That will of course slowdown it little, but that's actually good - because it will make it run at more constant speed. Otherwise simpler scenes, where generation is faster may play too fast.
Things are that lot of Atari ST SW has no any measures to make play speed constant, because they expected that it will be played only on 8 MHz ST(E)s.
And code is such, that it dictates speed.
So, I don't see that I need to change here anything. But if you want, I can make v. without that flicker removal.
Considering testing on TT: you are welcome to test everything. At moment I don't have TT here (I had at time when done Virus), so basically, nothing done above 2013 is tested by me on TT.
I'm not sure that everything can work on TT from floppy. Those longer ones not for sure. I'm little surprised you don't have some hard disk or some SD card solution. UltraSatan or Satandisk work well on TT. Should really get some of it ...

stephen_usher
Posts: 40
Joined: Mon Nov 13, 2017 7:19 pm

Re: Doing game hard disk adaptation

Post by stephen_usher » Wed Apr 18, 2018 10:01 pm

The strange thing is that the slow down only affects the player ship. It doesn't affect the NPC ships. It's not only the rotation in the welcome screen but the maximum rate at which the ship moves, irrespective as to whether there is land in view or not. It also happens on a plain ST and STE which I would guess would not use the anti-flicker code.

The slow down seems to be about a factor of two.

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

Re: Doing game hard disk adaptation

Post by Petari » Thu Apr 19, 2018 8:35 am

I looked it better. DL-ed STX image from Atarimania - and it is different/later version of game, what just runs faster.
Flicker fix. is not activated on ST(E), right.
But will add it to new release, as later version flickers too on faster CPU clock.

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

Re: Doing game hard disk adaptation

Post by Petari » Thu Apr 19, 2018 3:38 pm


stephen_usher
Posts: 40
Joined: Mon Nov 13, 2017 7:19 pm

Re: Doing game hard disk adaptation

Post by stephen_usher » Thu Apr 19, 2018 6:45 pm

Thanks! I'll take a look.

Post Reply