Making Atari St (And Amiga..) Disk Picking More Sensible

[skeezix]

I just hacked this together to PM someone, but then thought I'd open it up more general, so forgive if its a total mess written too quickly.

Mostly ST focused (for Hatari), but probably just as well applies to Amiga (and other disk oriented machines where crack groups went nuts.)

--

For Hatari, I've been thinking of a mod, resembling 'sort of' something I did back in the GP32 days.

Hatari has its own custom UI code, which is pretty good; its heavily mouse (touchscreen) oriented which I'm sure annoys some folks, but its so comprehensive and useful and part of the core project, it seems silly to contemplate rewriting that per se. ie: I like the UI it has

Still, a few things could be changed (not just for Pandora's sake.) Not a fault of the emu, but due to the nature of disk based machines like the ST.

- One small nit, and easily ficked; File picker sorts directories in with files; I think directories should be sorted to the top, so they're easier to find quicker; its also more or less de facto standard.

- an "ST problem"; since each disk image could have any number of apps/games/stuff on it, theres no easy way to know whats on it - A_132.ST could be the same as another A_132.ST or something entirely different; likewise, A_132.ST could be MSA'd into A_132.MSA and thus have a different checksum, but same contents; either way, if you save something back to that disk (a savegame, data file, config change, whatever) the checksum would change again. Its not like a cart based system where savegames are well defined and don't modify the cart itself.

So when you pick a disk image, you see A_12345.ST and have to remember "oh, thats Falcon, not Populous"

- hence, theres no sensible way to know whats on a particular disk, beyond human brute force; cataloging to a file, or renaming the disk-image file to be useful. (ie: ST was generally limited to 8.3 filenames, so couldn't have done that back in the day.)

- back in the gp32 days I organized people to build a database for us, mapping disk checksums to a list of apps on them, in short readable way. Was really awesomely handy, but we only covered a few hundred or thousand disks, and theres like hundred thousand disks out there .. plus the problems listed above -- several version of each crack disk, plus MSA versyus ST versus STT versions of the same disk, plus people saving their games on the disk and suddenly losign their DB mapping of the file .. great at first, but not really a great solution.

- some projects exist to make this easier; TOSEC for example. ie: rename disk images to have their app-list in the filename, up to a point; that works well if its been done, but for all the common crack groups (pompei pirates, super gau, automation, etc) you're out of luck; "GameBase" is another approach, but I think they goofed it in a lot of ways -- using a Microsoft specific format (Access DB if I recall right) is silly; coudl try to export the data, but.. bleh, lose interest quick

- for the big crack groups, usually you have a textfile that is the table of contents; map of a filename to a list of whats in it. ie: It'd say A_132.ST was Foo, Bar, Whizzo on the disk; filename changes due to renames (ST->MSA etc) would still break it, but perhaps could just ignore file extension and still get a match. More to point, in our case, we could create out own textfile 'database', and user coudl maintain it themselves. As short or long as they like, and it would only take one person to just get all the crack groups table-of-contents and append them together, and voila.. easy file to include in the Hatari pnd!

- so, if we did make a mapping file to map filenames to disk contents (easily done; I volunteer myself to do it!), what could we do with it?

- one option is to write a program that reads that table of contents file and renames all the files to the app list; that would work if only a few things on there, but if they're long names or lots of things, would blow up; pretty tempting idea though. ie: Given existing Automation, SuperGau, etc table of content files, it might work just fine for .. 50 or 80% of the files? ie: If you have A_12345.ST, rename it to "Falcon;Populous;GFA Basic.ST"; TOSEC did a lot of this, for instance.. but what if you want to use Automaiton, or Super Gau, or Pompei Pirates, or whatever, 'unchanged' beyu0ond filename? This is one simple hack. (Mind you, I dislike the idea of renaming a file that has been the same name for 20 years. It seems disrespectful, but if I did this, I'd keep a second directory of renamed files

- another option is to build into hatari an option so that it could read this table of contents file, and then show the list of stuff beside the filename in the directory picker; since we only have so much horiaontal screen space, we could see only so much, but it might be enough; further, you could edit the table of contents file to have the good bits first on the line; ie: instead of showing "A_12345.ST", show "A_12345.ST Falcon;Populous; GFA Basic" (or as much would fit into whatever space the picker shows you.) ie: To save on the actual renaming of the files.

- physical renaming 'works forever', in every app thereafter, so is actually pretty appealing; but doing the above filename look up might not be hard either. *shrug*

- could (additionally) add an option so you hit a key and it'd pop up the list of stuff on the disk, multiple lines long (A dialog box); you may recall I did something like this on the gp32; given "A_12345.ST Falcon; Pop..." (out of space on screen), hit a key to get a dialog box listing.

The "rename" option woudl be pretty handy for _me_, maybe; copy all the supergau stuff into one directory, suck down a file and format it just so, and run a rename-job on it; then you're "done" and good forever, on any emu. But it feels weird to rename files that have been the same filename for 20 years.

Hmm.

Any thoughts?

I hate looking at "A_137.ST" and having to remember what automaiton shit is on there

So.. any thoughts, or has this problem been solved better already somewhere?

Yes, I'm aware of various scenes/groups having done renames already; like I said .. you can get some crack groups disks whov'e been renamed already, or indexed by GameBase, or get a "TOSEC set", etc; bur in my case.. I really just want a directory of Automation stuff (that I legitimately all own, of course*), shown by appropriate filename, but still being an automation group of files.

jeff

* And btw, you have no idea how fearsome a pile of stuff I have. I actually down own several hundred arcade games, several thousand ST floppies, a complete colleciton of Atari 2600 carts (excepting super rare ones sadly.), and so on; though my SNES and NES and Genesis collection of carts is relatively small as I skipped that generation of consoles. And yes, I do rip my own ROMs from carts, floppies, etc, and can dig up my blog entries or write up how-to's if you really want to know. Some of us do try!

 

[DaveC]

A database for these disks would be good for the ST. The Amiga didn't have as many of these compilations so it would probably not make as much sense there.

I was hoping for a more d-pad friendly ROM picking interface for Hatari though, the REQUIRED use of the touchscreen is very annoying. To me the disk load functions should be in a separate d-pad friendly menu. This menu would load when the emu is started. A little icon or menu option in the disk picker called "configuration" or something could take you to the touchscreen options menu that is there now. I don't have a problem with config screens using the touchscreen as you mostly just set them up once then never go back. For things that need to be changed frequently the d-pad should be an option.

 

[skeezix]

I may well write a really dumb simple file picker for the other emus, in which case I might fold it in as an option in hatari as well (ie: use the hatari normal gui picker, or use the alternative quickie one.) We'll see.

What do you think of the main idea above though? Mass renamer bad? Show mapped list, good?

jeff

 

[WhiteFalcon]

Hey Jeff, I liked the way it worked on both the GP32 and GP2X, using a DB. Does it really occur so often that the checksum differs? If saving onto the gamedisk itself is purely incidental, it can be cured by simply replacing the file with the original. And for the savefiles in the form of a whole disk, isn't it up to you to construct this disk so that you could add some info to the header to distinguish it?

Maybe you could start with the existing DB and continually expand it, having even two or more different checksums for one gamedisk if necessary (in case there are more versions of the same file).

Just my thoughs as I prefer keeping the file names intact in this case.

 

[Loon]

Hi Skeezix, the idea of a database of ST & Amiga Games from the prominent crack groups sounds great. My Quick and dirty solution is to have a text file that lists the disk numbers and games named something like '1_List' in the directory with the roms. Open the list file in mousepad, find the game & then load with the emu.

Many thanks for the Hatari port by the way, having an ST in my pocket is just awesome, one little off topic Hatari question if I may :

How do you turn off the beep on key press when using the keyboard? This is somewhat harshing my mellow when I 'play' trip-a-tron.

 

[Dunny]

A database for these disks would be good for the ST. The Amiga didn't have as many of these compilations so it would probably not make as much sense there.

Um. The Amiga had just as many - most of my 3.5" DD collection was made up of "compilation" disks, and TOSEC is chock-full of them, especially towards the start of the Amiga's life where apps and games took up less than one disk. Of course, as games got more complex (and people took more notice of them - were you around in the days of the A1000, Dave?) groups tended to "one-disk" the multi-disk games which made compilations rare to find.

And yes, the Amiga certainly has a huge amount of disks that have this problem.

Oh yes, another vote for a button-based menu too. I cannot stand touchscreens and will be avoiding using the Pandora's where possible. Mind you, I'll re-code anything that uses the touchscreen unnecessarily so you could just leave it and I'll do it myself ;-)

D.

 

[skeezix]

WhiteFalcon -- yeah, the original DB was pretty slick in a lot of ways, but strikes me we could get by just as well using the filename (sans extension); using a checksum is handy since it would correctly identify files across renames, which is what I wanted at the time; I found a lot of disks 5 or 6 different times, that werte the same disk But using filename strikes me as a lot easier - I can suck down the lists for the top 5 or 6 crack-groups, run a quick transform on them to normalize their format, and then just have the emu match by filename; in practice, filenames should be pretty accurate (ignoring upper/lower case.) In theory, I'll have to see how it goes.

On the GP32 I went so far as to do something really awesome -- there was a mode few knew about, to list by-game, and then when you ran it, it'd list off the disks you had that featured it, and you could go from there. ie: So if you had 3 disks, with 10 games, it could show you the 10 games and when you ran one, it'd figure out which disk it came from. Thats really where it shoudl go, imho, but we'll see

jeff

 

[donnyhopkins]

I just went the slow route and pulled out my favourite games/disks, renamed them and put them in a file called favourites.

Spindizzy Worlds/Speedball II disk is getting a battering.

 

[Javacat]

On the GP32 I went so far as to do something really awesome -- there was a mode few knew about, to list by-game, and then when you ran it, it'd list off the disks you had that featured it, and you could go from there. ie: So if you had 3 disks, with 10 games, it could show you the 10 games and when you ran one, it'd figure out which disk it came from. Thats really where it shoudl go, imho, but we'll see

Kind of like a MAMEesque style romset?

I'm a Acorn Electron guy who deals with tapes more than your newfangled floppy disks, so this thread doesn't apply to me but you did sore of give me an idea (which is probably what you said above)

You could do with some sort of database that lists all games, cracks, versions, etc with checksums for the different disk images.
In the emulator you then group all of the same game together, making a nice, shorter, prettier list. The user could then select whatever game they want to play and just hits go/load/chain and the emu looks up the required disks and plays one of the version available (either the latest version or from the most popular cracking group).
If the user is after a specific version of a game, when they select the game from the list they could have a "versions" option which then lists the different versions available to them and they select whichever one it is they want to play.
It'd be kind of like in MAME, where you have the main version of the game but can then go and select different bootlegs or versions of the same game.

From what people have said in this thread, it sounds as though some games saved directly to the floppy they are stored on ( :blink: ), which makes things a bit of a pain. I don't know how the emulators usually handle this sort of behaviour atm, but could you make it so that when a floppy is loaded then the emulator tracks all of the writes to it and records the changes in another file? That way you'd keep the original image 'clean' and could easily have multiple save files for the same game. (Does linux already have something built in to do this already, which could be abused in some way??)

 

[skeezix]

In most ST emus, the disk image is stored in RAM (since they're 1MB images give or take, no big deal these days , so when the game saves to current disk (say), you then either tell the emu to then save the in-ram version to a disk image on filesystem and give it a name, or they implicitly do some magic (ie: save over the original, a cardinal sin, or make up a new filename derived from the original with some extra gunk to differentiate it.) If the app is keeping its own DB then it coudl track the new file as a derivative of the old, but keeping a separate DB is pretty awful (synchronization issues etc.)

As I've basicly stopped my own ST emu (it is designed for really low spec machines, and completely killed by Hatari in pretty much every way , I'm looking at retrofitting some of my features into it; I'll look into a few options.. I do think there is some interest in this, not just for me, so I'll see what I can get time for

jeff

 

[Dunny]

As I've basicly stopped my own ST emu (it is designed for really low spec machines, and completely killed by Hatari in pretty much every way , I'm looking at retrofitting some of my features into it; I'll look into a few options.. I do think there is some interest in this, not just for me, so I'll see what I can get time for

ISTR that it was your emu on the GP2X, yes? In which case, can you please if nothing else, remove the touchscreen dependency of the emulator UI. Retain that functionality by all means, but some of use like buttons. Oh, and the only issue with the GP2X emulator was the lack of a key-repeat delay in the menus, which made choosing a disk image a game all by itself - please make sure that one is fixed

D.

 

[skeezix]

The gp2x outcast had nearly no touchscreen support (F200); for the Wiz, the timings are goofy in some of the menus since I did some really stupid stuff there and was too busy/lazy to fix it I basicly never used Gp2x/wiz touchscreen at all, since 1) gp2x was a non-touchscreen device (f200 came really late, and had worst d-pad ever), and Wiz was basicly non-touchscreen (since most of them had the big warp on right side, or severe jitters, or both) ... so you must be confusing it with something else?

But the key repeat timings, yeah, but mucky on some menus, perhaps.

jeff

 

[mafia-man]

There should be a list of every pompy, automation etc disk around some where, a simple text file parse against the file names should suffice. ["A_0135." +( "ST" or "MSA") = "Automation Disk 135 - disk contents"] disk name and contents from the file.

As you add disks it would populate the database with what you had so there isn't a lot of labels without a disk attached to it. When you start up Hatari it will scan the file names and check it against the data base if it's a new disk then take the name and details from the text file and populate the database.

Should have the option to turn of scanning every start up and include a manual scan too.

 

[DaveC]

A database for these disks would be good for the ST. The Amiga didn't have as many of these compilations so it would probably not make as much sense there.

Um. The Amiga had just as many - most of my 3.5" DD collection was made up of "compilation" disks, and TOSEC is chock-full of them, especially towards the start of the Amiga's life where apps and games took up less than one disk. Of course, as games got more complex (and people took more notice of them - were you around in the days of the A1000, Dave?) groups tended to "one-disk" the multi-disk games which made compilations rare to find.

And yes, the Amiga certainly has a huge amount of disks that have this problem.

Oh yes, another vote for a button-based menu too. I cannot stand touchscreens and will be avoiding using the Pandora's where possible. Mind you, I'll re-code anything that uses the touchscreen unnecessarily so you could just leave it and I'll do it myself ;-)

D.

I did have an A1000 in the beginning. Most games I had were 1 or more disks but I did have some compilations. It wasn't as big on the Amiga maybe because the graphics and better sound took up more space? There were some compilations and I had them but nothing like the ST Automation series of hundreds of comp disks.

Oh and if you hack emus to get rid of touchscreen dependancy please post the hacks. I hate required TS use too.

As I've basicly stopped my own ST emu (it is designed for really low spec machines, and completely killed by Hatari in pretty much every way , I'm looking at retrofitting some of my features into it; I'll look into a few options.. I do think there is some interest in this, not just for me, so I'll see what I can get time for

jeff

Hopefully you could put a little time to make Hatari a bit smoother too. It does get chuggy at times and has frame stutters as it drops frames. ST on the Pandora should be able to be full speed with no frameskip I would think.

 

[Ze_ro]

In most ST emus, the disk image is stored in RAM (since they're 1MB images give or take, no big deal these days , so when the game saves to current disk (say), you then either tell the emu to then save the in-ram version to a disk image on filesystem and give it a name, or they implicitly do some magic (ie: save over the original, a cardinal sin, or make up a new filename derived from the original with some extra gunk to differentiate it.)

How about this: Instead of replacing the file, write a list of changes to a separate file. When a disk is loaded, check for an equivalent "changes" file and overlay it. This wouldn't have to be an entire .ST file, but just a list of altered sectors, with the appropriate data. This also has the advantage of always being able to revert to the original image (useful for games that saved to the game disks, assuming that you're actually playing off backups).

--Zero