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.

Thanks for the comprehensive answer guys

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

CJ wrote on 04.12.07 at 22:57:48:


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

Quote:


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