Right, I thought I'd start a new thread for this as I wasn't entirely sure which previous post to whack it in.

Anyway.

I'm currently in the process of setting up all my emus using the stuff that a lot of the guys on this forum have put together (cheers guys). This is fine for stuff such as SNES/MD etc, but one of my favourite systems is the Amiga which is a bit of a pain in the bum...

And on to the reason for this thread...

I'm not sure if any of you are aware of WHDLoad (I know some are, I've seen it mentioned here and there) but it's a way of installing Amiga games to a Hard Drive, removing copy protection and implementing bug fixes. So, for xbox emulation purposes, it's essentially a way of running games without the need to swap disks or fiddle about (too much) with specific configs.

I currently work on a project called KGWHD where I've installed every single Amiga game which has a WHDLoad install. My current site is here: http://whdownload.com/kgwhd/ (working on the latest update as we speak).

The problem with this is... all my files are in zip format (as this is easiest for use on a real Amiga). Unfortunately for us, WinUAEX does not support mounting of zip files as hard drives. (WinUAE does but this was implemented a lot more recently).

So, the best option is HDF files. And this is my plan (which is currently working nicely on my xbox).

(Bear with me if you don't know much about the Amiga).

The game HDF has it's device name set to "game:" and inside the hdf the game's icon (used to load the game) is named to game.info.

I've created a small amiga exe which will load an icon file by using it's default tool (in this case WHDLoad) and it's tooltypes (the slave name, preload etc.) This, along with the Workbench files, WHDLoad itself, kickstart files etc. will be stored in a separate HDF (called _whdload.hdf). And the startup-sequence will simply do:

cd game:
kgiconload game.info

This will load the game with all the tooltypes you have setup in the game's icon. Tadda!

In WinUAEX when we load a game we need to put _whdload.hdf in dh0, and then the game.hdf into hd1. This only needs doing once. Then we can just load them up from the menu every time.

So, we have a method to load the game. The next problem is getting all of these games into HDF format.

I've created a script, it currently works absolutely fine but it needs tweaking to make it a little more robust. I batch converted all of my zip files and it only took about 30 mins.

I will be hosting all of these hdf files on my website alongside the non-hdf versions as soon as I'm happy with them.

Alongside this I also have screenshots for 90% of the games which I'll be hosting too, and I'm working on some boxart (which I've been allowed to use from the GameBase project).

The text above may be subject to change, I'll need to take a look at it when I'm not so busy

Why not just combine your whdload and the whd.hdf file into one and call it a day? If you have the kickstart set to 2.03 it should autoboot when you select the hdf file. That's what I do. Sure it takes up a little space, but it's all neglible in the long run.

Oh, and good luck with your project. I've been slowly working through the whd set I have. Got a ways to go though.

Combining the whdload and game hdf into one was indeed an option I looked into, but I decided against it as I didn't want to update every single game hdf when a new version of whdload was released.

You are right though that it does make it easier to configure the games in the emu...

Hmm...

I suppose it's where you want the effort to be taken up...

Single hdfs:

Easier to load, but if you want to stay up to date (you don't necessarily HAVE to, but the dats will change everytime a new whdload is released because I would be updating them) you'd need to redownload the whole romset again.

Two hdfs:

Harder to setup, but only need setting up once. If there is an update you simply update the _whdload.hdf file.

I'll have a think about it. Anyone else got any preference?

I'd say whatever is the easiest to set up. Anyone who's kept up with MAME knows what it's like to have to redownload roms all the time and it's worth it in my opinion.

I'm wired a bit different than other people though. I think I get more out of actually collecting and setting things up than I do playing the games, so I might not be in the majority on this one.

What's the deal with configs and stuff in the SAVE directories?

Can that be downloaded and used between different xboxes?

If so, I think I may go with the double hdf files and set up some consistent files which can be downloaded the first time you want to play WinUAEX.

I presume this would also allow keys to be setup in the saves too, so games like pinball games can be setup as default to use the triggers, and up can be used for jump etc.

Yep... they can be uploaded and put on another XBox. It is the configs for setting up the XBox and for making the controller configurations among other stuff.

I think it would work fine for your purposes here. I uploaded the Colecovision saves on my drive so people wouldn't have to configure all of those games from scratch.

Ah excellent...

I think I'll def go with that method then. Cheers for the info.

Sure... just don't go crazy with the save states before you upload them. You'll upload every game you ever save as well as the configurations unless you go in and figure out which files you can delete. Probably the best way to purge them would be to find out it's file extention and then do a search on it in the saves folder and just delete all the ones that come up.

I'd probably back it up before I messed with that though.

Later,
~Rx

Good point

Unfortunately for the amiga emulator the config file stores the absolute address of the HDF files. So (for example) if your HDF game is in "D:\amigadisks\whdload\c\cannon fodder.hdf" then the other use would have to have their .hdf file in the same location as well.

We ran into that little issue when I sent some config and .hdf files to RessX.

I've never followed the whdload updates to know what advantages are typically offered from one to the next. But I would think if it functions for a particular title, what is the advantage of updating it?

But you line of thinking does kinda make sense.

Hmmm.

Absolute addresses is a bit of a pain in the ****.

It wouldn't be hard to create a small program that adjusts all of the paths before transferring, or what would be better is if someone edited the source code of the emu

As for updating them, WHDLoad tends to only get updates every now and then, but there are functions (such as the newly added global save directory for highscores/gamesaves [not savestates]) which would make it worth updating.

It's also worth noting, that whilst I would be willing to host all of the games from my whdload site, I wouldn't be willing to host them if they contained kickstart images. The Amiga scene is a strange one where companies actually actively seek out kickstart sharers and cause them trouble. I've had a little trouble in the past with similar issues.

I know it wouldn't be hard to get them shared elsewhere but my main aim was to whack them all on my site, and then just share the whdload.hdf elsewhere.

Well I did modify WinstonX so that if a .zip file had a "hardisk.zip" within it that it would auto unzip that file and boot off of it. So maybe I could do something with Winuaex to make it easier.

I found that using zipped hdf files in winuaex caused problems so I stuck with plain hdf files.

If WinUAEX could be fixed to run hdf files from zips, you could possibly then check inside the zip file to see if a text file called "whdload.txt" was in the zip, then boot _whdload.hdf in dh0: and the current hdf in dh1:

Or something similar, you get the idea.

That'd save time configuring.

It'd also mean that configurations wouldn't need to be downloaded as well, unless you wanted to of course.

Hmmm...

Well tell you what. I'm not sure when I'll be able to get to it. But I'll put the winuaex source on my pooter and see if I can modify it to do that. It shouldn't be too hard (hopefully). I can then send it to you and you can be a guinea pig for testing it.

Hey, as long as it doesn't involve needles I'm up for testing anything!

Good to hear you're taking a look

I also use the Amiga Emu on the xbox, but always find messing about too much to get games working too.

I do not know enough about the WMLOAD thing, but would love to see a emulator just select and run the game. I also seem to find having to mess about with the screen size on various games, having to strech it to the screen to display, but maybe its just be using a older version.

I never knew about WMDLOAD on df0 and the game on df1, is that what I need to do always. I just load the disk on df0

A dummies guide or a set of instruction 1-10 would really be appreciated. Thanks in Advance.. to any one who can help- (I know there is load of stuff out there to read, but very confusing too)

ok cool. I'll need one test image (plus boot disk/hdf). Are any up on your site? Once I get that working I'll hand it over to you.

I might look into the crazy screensize issue as well. If it doesn't look too involving I might be able to fix it real quick. I'm thinking that since the user can "size" the window that maybe x-port chose not to mess with it? What are the most common sizes for games? It's been a while..

320x200 non-interlaced
320x400 interlaced
640x480 interlaced..

I'll have to peek in winuae's setup tabs.

If you do add those screen settings, PLEASE do not remove the current way of sizing it, as I like my pixel perfect screens (The settings are posted on a few threads on here, plus the awesome external website I can't remember the name of off the top of my head).

eilz, whdload doesn't use df0: at all, wHDload (the HD stands for Hard Drive) are loaded into DH0 and DH1.

You are probably used to adfs.

Once I've converted my HDFs using my new script and winuaex has been tweaked I'll setup a nice easy guide.

Most Amiga games use 320x256 by the way

Before I forget to ask about it. Is there anyway you can set up your script so if the user is pressing a certain button (for example left mouse button) that it will go straight to the workbench? Alot of the WHD stuff I has comes with game documentation, hints, etc, and it would be nice to be able to access that somehow.

Actually the only other catch is a few of them have multiple versions (like OCS, AGA, CDTV)...

If you wanted to load it with workbench you'd need to replace the whdload.hdf with a workbench hdf of some sort. I'm not really fussed about booting in to workbench within WinUAEX myself. If I want to look at docs I'll just go on the computer/internet and take a look Just like I would do on Neogenesis, MekaX etc.

Not sure why you think that AGA/OCS/CDTV versions are a "catch". Each of the whdload zips only contains one version of the game. If you want to load the AGA version you simply load the AGA version

The whd's that I have just happened to be put together that way (multiple versions with documentations files) so that was why I was asking.

Ah I see.

Well ignore those

To be honest most AGA whdload games don't run all that great in WinUAEX anyway, they run far too slow and jerky so I may not even include them (the pinball games seem fine however).

No problem. Just keep doing what you were doing. My only concern is unzipping the files, as you said. I'm thinking that if maybe the file is too big it may cause issues with locking (as you said). Mainly cause from what I understand winuaex is pushing the memory limitations of the xbox.

Well...

How about something a little simpler

I rename all the whdload hdf files to "GameName.whd"

That should remove the need to unzip them, remove the need to check for a text file, and make it obvious that they are not plain hdf files than can be loaded on their own.

Sounds good to me!

Good idea. I like it. Congratulations you just created your own extension type.

Anyways sounds like a plan. When I get to fooling with winuax I'll set it up like that.

I have about three emulators I need to update to dual skin first..

Excellent!

Well let me know when you start on it and I'll help out

How do you guys prevent winuaex from losing the proper timing in 60hz? I'm on NTSC and 720p and stuff like the workbench seems to work just fine, but most games (pal games I presume) just keep stuttering.

Hmm

I've never seen this stuttering..

I've run WinUAEX on 1080i / 60Hz and it's been fine.

What settings do you have?

I'll need to check my settings on my xbox at the weekend.

Was sifting thru the winuaex code last night kinda cleaning things up. I'm hoping I can find some way to be able to implement movie previews considering the tight memory issues. So far it seems (from what I read) that JIT does not provide any real advantage except in certain cases.

Anyways if there was someway you could get the whdload boot disk to me and maybe one of your "converted" games that I can tinker with, that'd be great! I'm still trying to decide which way to go (mount the .hdf file) or just unzip to the utility drive (like I do with WinstonX).

There are a fair amount of things I wanted to do with winuaex. Some more time consuming then others. For example I wanna modify it so it doesn't overwrite the drive mounts on exit. That just messes things up when the user goes back into the game. The drive information is saved with each savestate so savestates will still be ok.

Possibly combine the "mount disk in drive 1-4", "create blank disk" options into one menu..

I also wanna go thru the preconfigurations and make sure they match winuea.

Other things would be, possibly restructuring the mappings to be more generic (aka useful). I'm not real familar with the typical keys used by most games, or for that matter the CD32. But if anything I would do like I did with atarixlbox. Have 2 or 3 "pre controller configs".

Oh and also try to create a game config system similar to the one used in atarixlbox. That way the user can have a bunch of preset configs for games. This would only consist of the hardware config (not controller) for now.

Anyways. Like I said some of those items are kinda time consuming so I'm gonna try and stick to the simpler stuff for now.

For whdload games JIT is useless, it causes more problems than the benefits it offers.

For stuff like Workbench however (the Amiga's OS) and non-whdload games that need the horse power (mostly 3D stuff) JIT can come in very handy.

I personally never use JIT in WinUAEX as I only use WinUAEX to play old school games. Even AGA WHDLoad games struggle so I doubt I'll want to play any complex 3D games (even if it will run them).

I'll sort you out the whdload.hdf file (and game file) as soon as possible, might end up being next week some time though as I'm pretty tied up from now until then.

I'm not a big fan of the default keymappings. I have a USB mouse and keyboard so I don't need the mouse being mapped to the analog stick. I've also completely changed the keymaps so that both the DPad and left analog stick are registered as a joystick (only the dpad is by default).

A good option for a few configs would be:

Joystick - standard 2 button
CD32 Pad - with all 6 buttons mapped correctly
Pinball - the amiga had quite a few decent pinball games, so mapping F1 to start, and the two shift keys to the triggers would be a good idea (or something similar).

On a normal Amiga the red button on the CD32 pad would work as the standard button on a joystick, although in WinUAE/WinUAEX the two things are separate (i.e. if it's set to Red, it will not work in games which do not have CD32 pad support).

Yeah that was the impression that I got about JIT when reading about it in regards to whdload and useage. I figured most people would be using winuaex for games. Worst case scenario I release a 2nd (no movie previews) edition.

On configurations. Not very many people are gonna have mouses. Even I only have one cable which I usually plug a keyboard into. But maybe if I go the preset configs route it can take the mouse mappings into consideration. The biggest fluke with that is, even without a mouse some games/titles want the user to press the mouse button.

I'll have to look into that red button issue, although I'm not sure if there is any point other than accuracy. Since the user really should be assigning the joystick buttons in non CD32 titles anyways.

Here are the standard emulator definitions for winuaex.. (32 entries)



Mouse 1 button 1 = Y
Mouse 1 button 2 = black
Mouse 1 button 3 = white

Dpad is mapped to Joy 2
Joy2/Mouse 2 button 1 = A
Joy2/Mouse 2 button 2 = B
Joy2/Mouse 2 button 3 = X

Joy2 green (CD32) = A
Joy2 yellow (CD32) = Y
Joy2 red (CD32) = B
Joy2 blue (CD32) = X

Now I always figured that Joy1 on a CD32 would be the default stick mapped as player 1. Is that not the case?

I typically unmap joystick 2 buttons 2-3 (do any games uses 2?) and mouse 1 button 3.
Then..

Joy 2 up = B (since alot of platform style games use up for jump).
Mouse 1 button 2 = Y.
Space = white (since alot of games seem to use it).
F1 = Start (since some games use this to start).

That generic setup seems to work pretty well for me.

I really have to wonder the point of having mappings for joystick 1 (two player games?).
Also the last three entries (enter, 0, and 1) are at least questionable.

Anyways I need to come up with a default setting that is as generic as possible. Let me know what you think of my above settings and any thoughts on that. I suppose mapping the mouse to the right analog stick and the dpad to the left analog stick might come handy as a setting.

All the rest could be set-up as pre-set configurations (as you suggested).

Lemme know what you think. Oh one other possibility (didn't see many games use it though) is mapping the dpad to the arrow keys. It was useful for atarixlbox. But so far I have not run into many Amiga titles that seem to rely much on the arrow keys.

With the help of this great screen aspect compilation - tutorial I found my prefered values for Winuaex in 1080i video resolution.
They are brutaly :> scaled to fit the whole screen - so circles will not be round, but I can live with that because the aspect ratio is scaled proportionally, and finding the correct 4:3 values should not be hard. Important thing is that there are no jagged edges or other scaling artefacts.

For most Games it's:

2497x1404

Games using a higher resolution with overscan tricks or something or just in full pal/ntsc mode require:

2270x1248

(Battle Isle is one of those)

screen position in X/Y could differ between tvs, mine were X:-320 Y:-20


All kudos go to Cospefogo for his research in proper scaling. I just did the calc.exe thing. :>

And this seems to have landed in the wrong thread. ;>

ok. Did some work today on this with my own made up stuff. Here is what I did.

If the file selected has an extension of ".whz" then the emulator will unzip that file to the "Z:whdload" drive. It will mount that drive as "DH1:" with the volume name of "game". It will then mount on "DH0:" the file "_whdload.hdf" which must be located on the "D:\" drive with a volume name of "WHDload".

Although I didn't wanna do it cause I knew it would be a big pain in the neck (traversing directory tree's is not fun). I wrote a function to clear the files in the "whdload" directory off of the "Z:" drive when the user exits.

At this point all the emu does is display a message when the user picks a file with a ".whz" extension. Later on, if you wish, I'll modify it so if the user picks a ".whd" extension it will do the same (aside from unzipping anything). Seems to me this does not have to be done now that I have it unzipping the file.

If you could tell me what configuration settings you use for you WHDload stuff, that'd be great. Also, please still send those test files I requested so I can make sure they seem to work ok.

Going on the earlier topic regarding preconfigured mappings I forgot to mention that I also wanna unmap all the emulator interface buttons except for ( in game options menu, keyboard pop-up, and fast forward). The rest, from my experience tend to get in the way so no love lost.

That sounds perfect to me mate, if it's all unzipping correctly that should work a treat.

I do exactly the same with the interface mappings, can't stand it when you accidentally change the filter and stuff

I'll endeavour to get those files to you ASAP mate, I'll let you know straight away.

Nice work mate seriously

I'm concerned with this issue as I 'm preparing a package of settings. Did you change something about this ?

B U M P

Still no answer ?

Sorry... I have not had a chance to put a whole lot of thought into how changing this would impact anything because Winuaex, and apparently a couple other emulators, do this very same thing.

It would probably be easier for me to go the atarixlbox route and modify Winuaex so it checks a database of configuration files rather than mess with the Path's. The way it would work is it would check the CRC of the selected ROM (aka disk) and look for a match in the configuration database and if one is found it would let the user select it.

The other option is to have it remove the directory path info. But that may create a problem for who use a combination of .hdf, .adf, and virtual hard drives since they probably store those in seperate directories anyways. Maybe I could just have it ask the user if they wish to keep the directory path info or not.

Well, paths of course are important because of disk swapping and configs with hard drive files. But anyone can easily correct them. My concern is that I actually don't know what happens when a user tries to load a winuaex config with wrong paths, does it crash or is he allowed to edit the settings ?

I think the most sensitive aspect is the "Amiga's settings" as they can appear very obscur for newcomers.



If you're planning to build a database then I'm your man. I've been testing and setting games for weeks now. I removed and replaced the bad disk with the good from various sources (Tosec, Gamebase, Lemon...). At the end, their number will be close to what is available in Gamebase Amiga. All games run perfect (full speed, loading fine and stable from crack intro to in-game) with the current Winuaex and they are also easy to find.



I think prompting for a directory would be a good idea.

At the moment my games are ordered like Gamebase, in alphabetical folders. But I'm thinking to change to make categories like RX does (AGA enhanced, language, public domain, pr0n... ^^) .
That's one of the reasons why I asked.

This whole process is kinda wonky and a bit confusing... But a few things I can tell you..

1) Whatever file is selected by the user (on first load/configuration), whether it is in a zip file or not, for drive 0 is remembered, path and all..

2) Everything you mount on drives. hard files, etc are remembered as well on exit. Whatever is in DF0: on exit is stored but overriden by the one mentioned in (1).

3) If one of the above files is missing on a 2nd load (where the configuration already exists) the emulator will still remember the filepaths for everything. The emulator will load as usual but won't do anything because there is nothing mounted.

4) If a configuration exists and the file stored in (1) is there it will mount that file to drive DF0:. Regardless of what game the user selected (or what file in a .zip) that matches the configuration name.

So it looks like they only time a user will have an issue is if the file that should be mounted in drive 0 is named different from the one you created the configuration with. In all other cases the user can go in and change everything else to point to the correct files and everything will be ok.


I'd like to go this route if your willing to help. In fact I'd like to re-verify possibly vamp up the game configuration screen a little. Some of the stuff to me just seemed a bit off (especially with the auto config when selecting a machine). So I would like to run thru the options and make sure they make sense (0k of ChipMem?, not possible)... But my memory is a bit fuzzy from my Amiga days.

Uggh the more I think about this the more it becomes a coding nightmare... I'd like to find a way around this, cause DosXbox has a similar issue and when I moved my games from drive E to F all my configurations were pretty much foobared because of path issues.

Well if your up to it maybe we can get something going. It's something I've been wanting to do but I knew it would be too big of a task for me to conquer on my own. I would like to make Winuaex as accessible as I had made atarixlbox. I was hoping to get something going with killergorilla, but he seems to have dissappeared for the moment...

I'm OK with it.

I will send you stuff this weekend and expose you what I was planning. You'll see, it's compatible with you ideas.

Let's go for a first collection based on floppies and then I'll do a selection for HD games.

Alright. Would you also like to work on creating some "pre-mapped" joystick configurations as well. I kinda briefly mention it in the first message on page 3. Basically the idea would come up with 1,2, maybe 3 "pre-mapped" configurations of typically used Amiga keys..

For example I noticed alot of games typically use the same keys for certain things.

The other possibility is to create a system similar to the auto configuration where the user can select a "pre-mapped" configuration for specific games.

I didn't know if you went so far as to add mappings for some games that rely on certain keyboard commands. Like for example in "Star Raiders" for the Atari computer "S" is shield, "G" brings up the galaxy map, etc. So for a game like that I would create a pre-defined configuration where certain "hot-keys" would be mapped to buttons on the stick.

Just let me know what aspects you'd like to work on...

KillerGorilla mentioned a few examples earlier in this thread.

At the moment, I worked these aspects:
- Screen resolution: 908*624, point filtering, no hardware filter, correct centering.
- Optimal Amiga configuration (processor, memory, chipsets etc.) to be sure the game runs 100%. Means full speed 50fps PAL and no glitches, no crash.
- All disks are verified so the swap is OK.
- All the set is compatible with Winuaex and it was often tested with good old Winuae 0.8.27

Still have near 200 games to correct/replace these days.

- Only a few games are remapped, like the Turrican serie and some I don't remember right now.

I agree with you suggestion, it's important. There's a need to add buttons for games and yes, there can be a model similar to the one KG suggested.
So when I'm finished with this package, I will set special mappings for games. I was already planning to do that.

Oh I forgot.

I have also made screenshots.

ok well here is what I'm thinking for the pre-made generic controller configs for now...


I typically map these as well...

Joy 2 up = B (since alot of platform style games use up for jump).
Mouse 1 button 2 = Y.
Space = white (since alot of games seem to use it).
F1 = Start (since some games use this to start).

I think that leaves the black button and the back button free. What do you think would be good generic keys? Esc and Enter?

I'm not sure what killer gorilla meant by having the CD32 pad mapped correctly. Is he referring to matching the colors or trying to match the physical location of the buttons as close as possible. I'll have to dig up a picture of the CD32 controller and a CD32 game. I have a bunch somewhere. Any recommendations?

Anyways just let me know when you got something for me to tinker with. If there are certain games that use special keys that you've set up just let me know which ones they are. I would have to work up some type of system for storing them so a user can import them if they wish.

Just so you know I've already upgraded Winuaex to all the latest dual preview, movie preview stuff that exists in MednafenX-NES. Plus Gilles made a dynamic skin for it. It seems to function pretty well. I default JIT to 0, I fixed the issue with DF0: showing up as DF0??? (sorta), and I tweaked the "Clip excess video borders" so it works a little better. If you wanna give it a go. It seems to work pretty comparable to the last x-port release of Winuaex. I've been having Gilles tweak the skin a little so it uses up less memory than the usual Dynamic skins..

I did a try for mapping, playing Hybris.

I configured this way thinking it would be good for joystick centered games:

back: 1
start: F1
(these are for starting games, one player mode)

Left thumbstick and d-pad for directions.

Right thumbstick for mouse.

White: Left mouse button
Black: Right mouse button
(we only need mouse to exit cracktro and for trainer menus)

A: Fire Button
B: UP (jump)
X: Return (sometime used. Like for transforming your ship in Hybris)
Y: Space (for special combo like smart bombs in shmups)

I removed the CD32 button in emulator definition to assign specific keyboard keys like P for pause, numpad 1-2-3 for language select (concern a few game, see spread sheet) etc...

Mouse centered games config is basically the same with mouse buttons mapped to X & Y and mouse directions to left thumbstick. Note that there are games that uses both mouse and joystick like Walker.

Then we'll need to assign LEFT SHIFT and RIGHT SHIFT keys to triggers for pinball games. And we could assign fast forward to the back button and F1 to the start button.

I wonder if it's possible to assign horizontal mouse movement to left and right triggers for breakout games like Arkanoid. But I don't think so. Then using the left thumbstick should be enough.

I noticed a few games using cursors. If I remember, it concern some AD&D type of adventure games and Hired Guns. I'll look to the spreadsheet.

For CD32, I remember it uses two buttons and Amiga games like Bubba & Stick used to detect CD32 pads. I suppose other emulator defined buttons were on the control panel . I'll see that after, have to transfer CD32 games as I never use them (depressing console, I flew to the land of the SNES at the time).

ok cool.. I was thinking of setting it up so the user can save keyboard configs as files and pick the name as well as select them when configuring a game (or in the "in game" menu).

Unlike atarixlbox where I had three specific configs and that is it.

I think this will make it more flexible and useful.

Plusatarixlbox I had it copy the config files over to the saves directory if they did not exist there but were in the "D:" directory. Thus allowing the user to edit them.

Good to see you're planing to add control options to the emu, man.

I have updated the spreadsheet. Please check the "mappings" tab.
I defined controls for joystick, mouse, cursors and pinball games.

I can't send you the STG files right now neither I can verify them and then update the spreadsheet because I will only have access to my xbox this weekend.

I tried two player mode and it works ok if I set controls type for the two players from the start in the configuration panel. If I do this once the game is launched, player2's controls bug. Maybe I'm doing something wrong, maybe It's related to the emulator, I don't know. But I remember you could swap controller in-game on real amigas, was useful back in the days if a trainer menu was present before the game (anyway, who needs to cheat on a 2 players game ? Left mouse button/player 2 joystick button is enough to quit).

Btw, happy new year.