Page 2 of 2

Posted: Fri Jun 15, 2007 3:36 pm
by alexh
Showaddywaddy wrote:they overwrite the OS and therefore a custom load routine is needed.

Did they overwrite the OS because it was faster? Or because it freed up memory on 512Kbyte machines?

The memory overheads I would say are relatively speaking gone with most users today having 2-4Mbytes.

Posted: Fri Jun 15, 2007 3:38 pm
by Showaddywaddy
alexh wrote:Did they overwrite the OS because it was faster? Or because it freed up memory on 512Kbyte machines?

The memory overheads I would say are relatively gone with most users today having 2-4Mbytes.


I'd say memory issues really. Plus some really good coders set up their own entire OS like Braybrook and the Sales Curve.

Shw

Posted: Fri Jun 15, 2007 3:40 pm
by ggn
Showaddywaddy wrote: Plus some really good coders set up their own entire OS like Braybrook


Braybrook? A really good coder? Now that's worth a LOL

Posted: Fri Jun 15, 2007 4:04 pm
by Desty
Showaddywaddy wrote:I'd say memory issues really. Plus some really good coders set up their own entire OS like Braybrook and the Sales Curve.

Why would they go to that trouble? Did they actually code up leaner, faster, more powerful routines, or was it more for the sake of making it a pain in the arse to crack?

Posted: Fri Jun 15, 2007 5:08 pm
by Showaddywaddy
leaner, faster......

try dis-assembling and tracing gem / OS routines and you'll see what I mean.

Shw (dreaming up a 50fps Period-3D-In-Space beating game using A-Line)

Posted: Fri Jun 15, 2007 5:38 pm
by ppera
Cyrano Jones wrote:Yes, there is. Including savegames. That's what ULS does.


So much I know about ULS. I talked about smaller patches. Everything can be made with one game. But it is lot of hacking and seeking in code. Lot of hooking and similar. From side of patcher.
From side of user I don't like idea of accessing hard disk when I play some old game, not intended for hard disk usage.
I prefer using RAM instead hard disk - ST with 4MB can run almost every game from RamDisk, even those on 4-5 floppies. Much safer and faster.
No need to take care about timers and hard disk ports.
Savegame can go on floppy of course. And maybe I'm wrong, but it requires not more work than ULS-ing.

Posted: Fri Jun 15, 2007 5:45 pm
by ppera
Showaddywaddy wrote:leaner, faster......
try dis-assembling and tracing gem / OS routines and you'll see what I mean.


As I saw, OS discard (to call it so) is from several reasons:
protection, more free RAM for game, speed, more flexibility

Code is pretty simple in most of cases: no filesystem, just accessing logical sectors on floppy. No filenames, just numbers.

Of course, making some simpler OS in assembler can be much shorter and faster than GEMDos. May be worth for multidisk adventures and similar (did not see such).

Posted: Fri Jun 15, 2007 10:12 pm
by Cyrano Jones
ppera wrote:and maybe I'm wrong, but it requires not more work than ULS-ing.

From side of user I don't like idea of accessing hard disk when I play some old game, not intended for hard disk usage.


Yep, wrong. Changing a DMA Fileload crack into a ULS HD-Version usually requires adding *one* JMP instruction. And to make it even easier, the latest build of ULS even automates this for you.

Now, thats not much work, is it?

ppera wrote:From side of user I don't like idea of accessing hard disk when I play some old game, not intended for hard disk usage.


Why? Why would you rather be stuffing floppies into the drive for saving and loading your position?

If you don't care about Falcon patching, ULS is the fastest, safest way to make something HD installable. The code is entirely modular and very easy to implement.

You don't even have to know how it works, the loading/saving routines are "black boxed" away behind a nice layer of code to handle everything for you.

ULS works like a wrapper for GEMDOS, and lets the O/S handle all the disk access for you, regardless of pretty much whatever the application is doing to the ST. If you don't trust GEMDOS with your HD data, you may as well unplug the drive and go back to floppies :P

That was kind of the point of writing it.

Posted: Sat Jun 16, 2007 1:06 pm
by ppera
Cyrano Jones wrote:Yep, wrong. Changing a DMA Fileload crack into a ULS HD-Version usually requires adding *one* JMP instruction. And to make it even easier, the latest build of ULS even automates this for you.

Why? Why would you rather be stuffing floppies into the drive for saving and loading your position?

You don't even have to know how it works, the loading/saving routines are "black boxed" away behind a nice layer of code to handle everything for you.

.. If you don't trust GEMDOS with your HD data, you may as well unplug the drive and go back to floppies :P


Yes. If game is already cracked in certain way, it is easy. But what with lot of games which are not cracked with that DMA fileload?

Of course that saving pos on HD is better, but it is usual fast enough on floppy too. And I keep some floppy always in drive.

Just to state: I don't have anything against ULS. I maybe even ran some games ULS-ed - but on site I did not see what games are such.
Question: how it handles multi-floppy games?

Point is that I work on different way. I intend not to hack games in my old days. I just want some simple ways to use existing work on new medias. Therefore I posted my old adaptations. I will fix B17 FF to work on single-floppy machines (when ramdisked, I had 2 floppy drives), and that's all game hacking from me. Actually, all really good stuff (for me) is already prepared for run from hard disk.

I will make new version of Image Runner, with simple drag & drop launching, without GUI. It will be easy to use, but with downside - (1 executable) only for specific TOS.
Isn't better to have more solutions for same problem?

Posted: Sat Jun 16, 2007 6:14 pm
by Cyrano Jones
ppera wrote:Yes. If game is already cracked in certain way, it is easy. But what with lot of games which are not cracked with that DMA fileload?

Question: how it handles multi-floppy games?


If you can name more than 10 that aren't in files......

Multi disks? Doesnt care it reads FILES.

Posted: Sun Jun 17, 2007 2:26 pm
by ppera
Cyrano Jones wrote:Multi disks? Doesnt care it reads FILES.


OK. Let see this: Game is on 3 or more Floppy. By regular usage it put text on screen that needs floppy change. Then (after some keypress) it checks floppy, usually by some signature. How will ULS know that need to work with another floppy image or another file? Does user must press something? I talk here about (easy) adaptation of existing floppy cracks.

Posted: Sun Jun 17, 2007 8:33 pm
by Cyrano Jones
Which part of *nearly everything is in files* dont you get?

ULS gives you *full* gemdos and XBIOS access, so you can do what you want regarding loading data.

Posted: Mon Jun 18, 2007 11:38 am
by ppera
Cyrano Jones wrote:Which part of *nearly everything is in files* dont you get?
ULS gives you *full* gemdos and XBIOS access, so you can do what you want regarding loading data.


I talk not about how to load data. It is clear. Certainly we will not read by logical sectors from hard drive. I talk that game gives no any info except writing on screen that expects another floppy. You must go deep in gamecode to know when it will want to load from another floppy and then make a way to inform non-floppy loader about that.
Give me some examples about mentioned multi-floppy games ULS-ed.

Posted: Mon Jun 18, 2007 4:07 pm
by Cyrano Jones
OK, I'll say it again s..l..o..w..l..y..

ULS replaces the file loader..... the fileloader loads the files.... If all the files are in the directory... there is no need to swap disks....

The swapdisks are removed by default on a filed disk and replaced with filechecks....

Posted: Mon Jun 18, 2007 4:33 pm
by alexh
I've found on some of the HD installable multi-disk games (not necessarily ULS) sometimes the "Insert disk 2" gfx may come up for a fraction of a second, or you may have to press a key.

This happens on one of the HD versions of Dragonflight for example.

I remember the same thing happening on some multi-disk games that had been cut and recompressed onto one disk back in the old days.

Posted: Mon Jun 18, 2007 5:01 pm
by ppera
Well. So, multidisk games must be hacked prior ULS from some expert.
You could say it in your first reply.

Alexh: where is the list of hard disk 'friendly' games?

Posted: Mon Jun 18, 2007 5:08 pm
by Cyrano Jones
Cyrano Jones wrote:Yep, wrong. Changing a DMA Fileload crack into a ULS HD-Version usually requires adding *one* JMP instruction. And to make it even easier, the latest build of ULS even automates this for you.


I believe I did.

Posted: Tue Jun 19, 2007 1:12 pm
by dlfrsilver
ULS works a bit like whdload, everything is redirected, handled, etc....

works great on some games on my SH-305 30 megs.

Posted: Fri Jun 22, 2007 4:04 pm
by ppera
I found this site:

http://www.mobygames.com/attribute/shee ... ,24/so,0a/

List is far from complete, and is actually for installable games.
Many 'installation' consist only by simple copy of all files to some DIR.

I looked some multi-floppy titles: in some (rare) cases it is possible to just copy all (as described above), and it worked (Space Quest III). But I saw most of titles without regular filesystem on floppies (Lure of Tempress), some have regular floppy filesystem, but start from bootsector (no filename there). Looked D-Bug 157 C-D - probably ULS-able.
Adapting those without regular filesystem to be runnable from hard drive seems as not easy.

Posted: Fri Jun 22, 2007 4:36 pm
by cb
That list is far from accurate.
It lists 2 Falcon games (Humans & Steel Talons) as being ST games and several vapourwares like Battle Isle and Pool of Radiance.

Posted: Fri Jun 22, 2007 4:40 pm
by Cyrano Jones
That list is wrong.

Gold of the Aztecs is a DMA loader. Also, the fact that it has Steel Talons on it for the ST might be a bit of a give away about how useful it is.

Just for the record, adapting DMAload/RAWdata game to hard disk is actually easier than if they use GemDOS, as you know exactly what the title is trying to do in regards to the data.

Posted: Sat Jun 23, 2007 8:56 am
by ppera
Wrong list: no wonder when it is not controlled by anyone...

I looked some Automation multidisk titles: it looks that Sierra adventures are easy to 'hard diskable' - but they have some installer on disk A - is there some protection on original floppies (need to keep original floppy A in drive to run from HD?).
Games Summer Edition: it looks that game expects floppy change signal before checking for files (from disks 2,3,4).

Trying to list reasons why not runs (installable on) from hard drive:

1: Low RAM usage (overwrites driver)
2: No regular (FAT) filesystem on floppies
3: Floppy change detection by multidisk titles
....