Not that I mind with my 4MB STE, but a friend was asking why games like 'Escape...Robot Monsters' require 4MB of RAM to run from HD.  I didn't have a proper answer (other than the fact that the game is depacted into RAM?), and was wondering if one of you DBug guys could explain how the whole HD/Falcon patching system works?

I assume (probably wrongly) that the data is uncompressed and loaded into RAM, and then the Atari requires yet more RAM to actually run the game...

First things first: why doesn't your pal sign up here and post his question himself? ;)

Secondly, Escape from the planet of the robot monsters does work with 2mb memory, so we'll correct that in the page, thanks for bringing that up to our attention :). Like you, all of our machines have 4MB of RAM and above, so we can't test them in anything else except STEEM. The best thing you can do is try running the game in STEEM with 1 or 2mb and see if it works ;). If it does, we'd be more than happy to change our info page.

As for your question: generally the patched games roughly as much memory the game's file size plus 0.5mb (or 1mb in some cases) extra. The data is in memory packed and is unpacked when needed.

P.S. I did a whoopsie with Badlands :(, it should be possible to work with 1mb ram! I'll try to fix that when I get back home.

Yes, you'll find quite a number of our patches do run with 2mb machines.

In fact making the game Falcon compatible doesn't effect the amount of memory the game needs. It's making the game hard-drive installable that eats away ram. As basically we load the entire games data into memory before the game runs. As the majority of games over write the systems memory which deals with file i/o.

Shw

Thanks for the comprehensive answer guys :)

Just updated the page and the zip, tested under steem in 1mb, works :)

Hi

There are currently two ways of HD patching a title:

[1] The conventional way  

 As mentioned above - load all the data into the upper part of memory, patch the loader to copy it from there instead of going to disk, and let the game run in the lower part of memory - so for these you will requires 512k+size of all data (packed)+say 2k for patching routines.   This is the way most things are done to fix for HD.  The down side to this is that ALL I/O has to be killed, which means no high score saves or savepoints.

[2] Universal Loading System [ULS] conversion

 This is our stubloader code that is basically our version of WHDLoad on the Amiga (But works in a completely different way!)  The Atari's O/S is given its own "virtual environment" to run in and is swapped in and out every time an I/O request is needed.  These patches will all need at least 1Mb ram to provide the O/S the environment it needs to run in, alongside the memory that the game will use.

  ULS is currently *not* my prefered method for patching as it eats memory and causes slower loading than RAMdisking titles. However it is the only way to have a true HD-save game or high score save version, so it still has its uses.

 It is currently under development to give it full functionality on the Falcon using the PMMU to provide the game title with the virtual RAM, instead of the O/S running virtually, which will make it a lot more useful and stable - but thats a long while off and will require motivation ;-)

 We are also playing with a 3rd option which would allow any .msa disk image to be mounted and booted directly from an Atari HD - even titles doing direct disk access work using this method.  As we have stated many times previously, this is still a long way from being released, but it has been lab tested ;-)  Some working titles for this project are:  "ImpossiLoad", "NotImgRunner" and "ItJustWorks"

 Just for information, version 0.0001 of U.L.S. was called TOSoff (Because you can load with TOS disabled) - but Showaddywaddy made me rename it.  I still don't know why....

 Hope this helps answer your shy friends questions :-)

I like the sound of "ImpossiLoad".  It really sounds like a great utility.  Keep up the sterling work lads.

CJ wrote on 04.12.07 at 22:57:48:

We are also playing with a 3rd option which would allow any .msa disk image to be mounted and booted directly from an Atari HD - even titles doing direct disk access work using this method.  As we have stated many times previously, this is still a long way from being released, but it has been lab tested ;-)  Some working titles for this project are:  "ImpossiLoad", "NotImgRunner" and "ItJustWorks"

Wow, this intrigues me. I can understand you can intercept OS IO calls and redirect them to a virtual mounted floppy, but how do you prevent that programs (usually games and demos) executed from the mounted floppy, overwrite the memory area where the virtual floppy driver is living. And more difficult how do you intercept direct calls to the floppy controller registers of programs (usually demo disks) that skip the OS for doing IO.
But it would be the ultimate Atari ST utility now my floppies are rotting away. Keeping them as disk images on HD would be great. I hope it gets released sometime.

Regards,

Robert

I *guess* that this method will require at least 2MB to use (but more likely 4MB) so that the disk image can be stored in the otherwise unused upper memory and the game/program can use the regular lower memory (the first MB+).  But I'm probably way off the mark and oversimplifying things a bit!

wrote on 05.09.08 at 10:22:11:

......but how do you prevent that programs (usually games and demos) executed from the mounted floppy, overwrite the memory area where the virtual floppy driver is living. And more difficult how do you intercept direct calls to the floppy controller registers of programs (usually demo disks) that skip the OS for doing IO.

With a lot of cunning...  despite what others might tell you, it can be done :)  Not saying its easy tho!