New hard disk adapt releases, updates

[ParanoidLittleMan]

In last weeks I went through all those my hard disk adaptations, checking compatibility of old ones, especially with iTOS.

Most of it (99%) works very well as is, some don't have exit to Desktop, state saves, some eat too much disk space (lot of short files), so I updated half dozen of quality games:

 

Bubble Bobble

Hero Quest

Gunship

F-16 Combat Pilot

Galdregon's Domain

Forgotten Worlds

Zak Mckracken and the Alien Mindbenders - 3 lang. versions: De, Fr, En .

New:  Pole Position

 

They are at top of DL table by default.

There were some problems with game Forgotten Worlds - it is not so well coded, and tends to write in high RAM, what destroys HAGA cache and other.

So, it is still with old GAMEX system, what has direct access to hard disks (with mine and couple other drivers only). And this one is tested until end.

Others may wanting that you do it ?

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

 

 

[TheNameOfTheGame]

Thanks so much for all your work on the adaptations!

[TheNameOfTheGame]

Is there a list of games that have been tested to completion?  I know you always ask people to test your adaptations and obviously it is a time-consuming process.

 

Maybe you could get a group of users to test different groups of games?  Sort of break up the task into smaller chunks? Like one person work on games that start with 'A' and one person do  'B', etc.

 

And then some games are not easy to complete like adventures and rpg (i.e. captive).  So those would be excluded for the meantime.  Just an idea.

[ParanoidLittleMan]

On DL page with table there is field 'Val' . C there means completed, checked thoroughly (as is explained below).

There is 180 of such, so over 10% .

I was thinking about something similar - dividing games by category, start letters, and then volunteers could select what to test. Of course, it is not so simple - much more games starting with S than with Z, for instance. There are popular games, genres, known games, not known games ...

Things are that there are few people who do it from time to time, so I got few days ago in e-mail:

"Hi, I played Curse of the Azure Bonds to the end, STE TOS 1.62 4 mb Ultrasatan.
Thanks, it was unplayable on floppies when I tried 30 years ago.
Mark Keeling"

 

With this tempo, I guess we will have 50% somewhere around 50th wave of covid - 2040 . Yeah, not optimistic. It's up to you folks to make me optimistic ?   And under 'folks' I meant politicians too .

[Sporny Kun]

Thanks for your dedication.

[.mad.]

Thanks for updates, they are aways welcome!

 

As for testing games to completion.

Arcade style games with trainer modes should be easy to run through.

I guess most can be completed in 1-2 hours.

Any major faults should appear quite quickly.

 

stategy /RPG games can take months to complete.

so like you said, it would take years to test all those without a cheat mode and walkthough.

 

Emulator save states are handy when trainer modes are unavailable.

However emulators need to catch up with adapated code in a few games.

 

Atomic RoboKid can sometimes bug without player movement on loosing a life.

so using a trainer would miss that kind of problem.

This seems to happen more frequenty with Hatari.

Steem passed the same point when retesting, but maybe i was just lucky?.

 

[ParanoidLittleMan]

Yes, arcade, shooter games can be finished with cheat often pretty fast, but that depends from many things. Just one example:  bosses - to kill them player might need some stronger weapon, and if did not pick up it, that can be stuck.

Some games are very hard even with cheat, so beside unlimited lives unlimited health can be useful. 

And I would add platformers to relative easy to finish, but that again may be not just simple walk through.

I needed plenty of time to finish Dungeon Master, but it was partially because very slow game load and start from floppy, lack of experience with such games.

 

There are state saves in most of my adaptations, so it is not only emulators where it can be used.

 

Then, saying that "emulators need to catch up with adapated code in a few games"

Sorry, but that's nonsense. Emulators need to emulate accurately HW, CPU, and then they will executing well any code (better said accurately, so if code is bad it will fail with emulators too).

"adapted code" - that's not what I mean under 'adaptation' .  There is more than just changing some parts of code in game, so that will work from hard disk. Since 2010 there is TOS 1.04 core in RAM for games using TOS (calls), for better compatibility, easier changes in game code - and joystick, mouse read is something what is problematic in many case, so it is easier to correct it for only 1 specific TOS version.

TOS in RAM costs not extra RAM ,  because hard disk run already needs min 1 MB RAM in most case (512KB with floppy games), and it takes only some 100 KB (only GEMDOS part, without AES, Desktop) .

+ it was used for fast, direct hard disk access from games which do not use TOS (calls) - floppy access replaced with hard disk access - but TOS in machine is deactivated ( or as some like to say 'killed', 'kicked off' ) so need somehow to solve hard disk file access, and OS is needed for that (well, part of it, still some 60 KB) .

 

So, that 'code adapting' in games, what is called often 'patching' is in big part change of floppy access parts. May need other changes because of RAM handling, then copy protection removal, and in last time very important - removing completely any floppy access - so it work on machines without attached floppy drive. It is not so easy to spot all floppy access parts, and floppy code is often real nightmare and head-ache cause (Captive).

Then there is making it work with Falcon and TT - usual problem is code not compatible  with 68030 CPU - stackframe and pipeline sensitive code needs corrections. .Then, it might need to slow it down, because is unplayable on 4x faster machine ..

 

To finish this: you should contact authors of Hatari about that Atomic RoboKid problem. Never had problems with it in Steem (regular v. 3.2) .

And: one of main problems with games is poor input reading code - keyboard,   joystick, mouse read - what is actually read of IKBD chip, and there is protocol for that. I had at very beginning (1987) pretty good literature for that - Atari ST ProfiBuch, with detailed description of modes, code sequences, even timing.  But it was not complete, what was missing is for instance how to properly read joystick via TOS functions - and that part was never present in Atari DOCs, even if whole thing should fit on half page (together with mouse and keyboard read via TOS) . I needed to rewrite whole mouse read part in game Tracker (works only with TOS 1.00). Keyboard code in Unreal is really a mess - I guess they needed to guess what commands to use there ?  .