Managing St Disk Images

[0-bake]

hi,

i'm looking for a tool, which can handle disk images easily.
i mean, the automation disk images are very good, because of the auto boot menu, but i don't want every game combinition like they are on the images.
i like to make my own compilations (mostly to save space) but i want to have an auto bott menu, too.

how can i do it? is there an boot-menu-creater program for the ST?

thanks...

 

[frolik]

I doubt it, those disks were all tweaked and hacked up by 1337 Atari ST dudes. Best thing you can do is find a disk with single games on, but some of them expect you to extract the files to an ST hard disk which isn't supported. There really isn't any reason why you shouldn't just use the compilation disks though

 

[skeezix]

Some crack groups liked to make up cool menus; others just 'filed' the games, so they coudl be run from anywhere (hard drive or floppy). There was a menu creation proggy for the ST, but it wasn't really good (There were piles of floppy organizers and such, but you' dbe hard pressed to find them nowadays..)

Filed menus might be okay to work with; a lot of the SuperGAU is like that. its an enormous collection, and you cna drag them around as you see fit.

I do hope to look into hard disk support one of these days; it'll take some doing to get right I imagine, but I've been wanting to tackle it, since it'd be damned cool

jeff

 

[0-bake]

hm...ok, i see.
it would be nice, because it's a waste of the limited smc-space, if you just use the half of the games of the compilation images.

btw skeezix, did you try to enable the high resolution mode? you said something like that some time before.
it would be really cool, because almost every game i played in the past where on a black/white monitor in high resolution and i can't play them now. i don't know what it will look like, but many of these games had simple graphics, so i hope they will be playable.....

 

[skeezix]

hmm, didn't add it yet; didn't see much purpose, since it'd look nasty and any text would be unreadable. For mono I did coding, and some graphics stuff with Cad3d.. but gaming I always did in low/med res

jeff

 

[frolik]

Wow hard disk support would be amazing

Sorry to be on your case so much lately, Skeezix, you're doing a sterling job.

 

[DaveC]

hi,

i'm looking for a tool, which can handle disk images easily.
i mean, the automation disk images are very good, because of the auto boot menu, but i don't want every game combinition like they are on the images.
i like to make my own compilations (mostly to save space) but i want to have an auto bott menu, too.

how can i do it? is there an boot-menu-creater program for the ST?

thanks...

​

I have asked the exact same thing awhile ago. Sadly I got nowhere. It would be nice to have a utility that could read files off of one ST disk image and store them on the PCs hard disk. Then with the utility you could just pick the files you want from your PC and put them on a new disk image that you make with just the files that you want. It sounds like a simple and logical utility that you would think SOMEONE would have written, but no one has for some reason. You have to use several programs and PC ST emulators to do this and it is a real pain in the ass.

I have taken some one parted games off of the automation disks and they do work but you have to rename them and add an .exe extension too them. They got clever and renamed the files so that you can't execute them directly. If you just re-name them many will work. Unfortunately you have to put these files back onto a disk image because Castaway has no HDD support. It can be a bit of a pain.

It would be nice if CaSTaway had an option like the C64 emu where you could load these single files directly into the emu and run them without having to have them on a disk image. I guess this needs HDD support which is complicated?

 

[skeezix]

ITs multiple issues as you pointed out.

You can't just 'load up a file' per se as in a C64, since the ST is a much more advanced machine. Just shoving stuff into RAM won't make it work

The harder part is getting the games. ie: Almost all of them were protected in some form or another, so to get them at all these days we live off the cracked versions, and those are as described above.. either menu'd or filed'd. So the trick is always getting the files..

ie: Hard drive support or not, you still have to get the games in a file'd format if you want to mess with them. Hard disk support just saves you from worry about disk images, for those games that can boot from a hard drive after being cracked (which isn't all of the, thats for sure)

For making disk images of your own, its not too hard; fire up STeem or other ST emus on the PC and drag files around from ST hard drive to your blank ST disk images. Takes minutes.

Adding hard disk support is nifty, but its not going to change the world for anyone.

jeff

 

[DaveC]

Maybe a disk image editor utility would be the answer then. Something where you can just drag and drop files from one disk image to another, or from the HDD to disk images etc. Kind of like a Windows explorer type interface would be good.

I had trouble trying to do this through GEM on the STeem emus. It got flakey trying to read from my PC and the interface is kind of clunky.

 

[trooper]

But aren`t the the files hard coded (for want of a better word) into the disk images with the menu etc. The size of the files probably vary from game to game, So getting the games you want to fit on to each disk image maybe a nightmare at best. What about the frontend menu`s, How are they going to be edited to reflect what games the disk images actually contain ?. It would`nt suprise me if alot of the stuff contained on the disk images ie, menu system, packers, music etc, Was done in highly optimised c or even assembler (after all they were hackers/crackers), So they could cram as much as they did on to those disk as they could.

I`m no coder, I could just be sprouting shit, But what i said above does seem plausible.

Just my ten pence.

Trooper

 

[DaveC]

But aren`t the the files hard coded (for want of a better word) into the disk images with the menu etc. The size of the files probably vary from game to game, So getting the games you want to fit on to each disk image maybe a nightmare at best. What about the frontend menu`s, How are they going to be edited to reflect what games the disk images actually contain ?. It would`nt suprise me if alot of the stuff contained on the disk images  ie, menu system, packers, music etc, Was done in highly optimised c or even assembler (after all they were hackers/crackers), So they could cram as much as they did on to those disk as they could.

I`m no coder, I could just be sprouting shit, But what i said above does seem plausible.

Just my ten pence.

Trooper

​

I started messing with the Automation disks. I stopped because of the lack of a good 1 program solution for a disk image manager as described above. It was not bad doing 1 or 2 disks the hard way through STeem etc but doing hundreds of files that way got old fast.

If you look at them many of the files were just re-named by taking the .exe extension off and they may be called something weird like a number or something. If you view the menu program with a hex editor you can see what file the menu calls up and then just rename that file to the real name like Plutos.exe etc. It is then possible to hex edit the menu to call up the renamed file. Many of these games were one-parted so the whole game was in one file. A few had data files and that is where it gets tricky knowing what data file goes with which game.

It is possible to do what we want but without a good editor utility it will be ALOT of work.

It is kind of strange because I wanted EXACTLY what O-bake wanted and for the same reason a year ago. I wanted to make my own compilation disks with the decent games on them and weed out the dodgy games and duplicates to save space. I scoured the 'net far and wide looking for such a utility. I was suprised when I found that none exist.

 

[skeezix]

The one-filed ones always amazed me; I never looke dinto the asm to see what they did, but making a game that uses datafiles into a one file one woudl take a little work.. surprised they'd do it. Unless someone made a tool that did it automatically, which is entirely possible since all the system calls would be easy to spot... I'll have to look into it someday. Why they did it was easy .. made it easy to put them on hard disks and load them. If they opened data files, it'd break when run from there.

It'd be easy to make a new menu system..

The cheesie way..

1) Lay out the icons in a window right (either with filename tricks to space them right, or multiple single windows sized and placed just so); then 'save desktop' and voila.

2) Just write a simple C program to show a menu and run the program; or even a GFA Basic program.. yeah, that'd be only a few lijnes of GFA. I'd even write it, since it'd be fun to fire up my old favourite basic compiler

So writing a launcher program would be easy I imagine.

jeff

 

[skeezix]

You know, its this sort of (nerd) chatter about my favourite old machine that makes it worth writing this emu Ah, those were the days.

jeff

Didn't think I'd have an excuse to pull out GFA Basic again, after 15+ years

 

[DaveC]

You know, its this sort of (nerd) chatter about my favourite old machine that makes it worth writing this emu Ah, those were the days.

jeff

Didn't think I'd have an excuse to pull out GFA Basic again, after 15+ years

​

Yeah it is kind of fun hacking around on the ST, even though it isn't a real one I kind of liked going in and hex editing menus to get stuff working on my own compilations etc. I would do more if moving the files around was quicker but it is still interesting. If you had a menu with GFA I might look into ripping more games from the menu disks and make my own l337 compilations