Search Results

A quick guide to the Microsoft Compatibility administrator and how it helps to run those older legacy games. This is based on my limited experience with Compatibility administrator, so if there's something unclear, confusing or just plain wrong, please let me know. What is it? It is a serious professional tool meant to help business run their existing software on a Windows 10 platform, so it can seem a bit daunting if you've never used it before. There are two, Compatibility administrators named (32 bit) and (64 bit). The 32/64 bit part of the name refers to the software/game to create the fix for. For example, the Windows versions of Jane's AH-64D Longbow are 32 bit games, so we would use the Compatibility administrator (32 bit) . It does NOT  refer to the 32/64-bit platform of Windows, Windows 10 being a 64 bit OS. When you've downloaded apps in the past, if there was a 32/64 bit choice, you've probably picked the 64 bit version. It's a confusing way to name the Compatibility administrators, if you've never used them before. Terminology The individual fixes are sometimes called shims, from Wikipedia: The Microsoft Windows Application Compatibility Toolkit (ACT) uses the term to mean backward compatible libraries. Shims simulate the behavior of older versions of Windows for legacy applications that rely on incorrect or deprecated functionality, or correct the way in which poorly written applications call unchanged APIs The ACT was replaced by the Microsoft Assessment and deployment kit (ADK). Installing Download and install the Microsoft Assessment and deployment kit   (ADK). This installs the Compatibility administrator apps. If you want to read up on the ADK and Compatibility administrator, take a look at the documentation . A brief tour There are 4 main sections shown in the left hand panel: System Database A catalogue of compatibility modes and fixes. The most interesting part of the catalogue are the Applications. There are thousands of pre-configured application fixes and there are quite a few games listed, so it looks like someone at Microsoft understood the importance of making sure our older games still ran on Windows 10! Installed Databases This is a list of the manually applied compatibility fixes. If you manually create a compatibility fix and install it, it will appear in this list. Per User Compatibility Settings This is a list of automatically applied compatibility fixes, ordered by username. The first time you run an older app/game and quit, you may have seen Windows display a dialog box saying something like 'Compatibility fixes have been applied'. This only happens the first time you run the software and you won't see the dialog box again, and it's pretty easy to forget about. After running the software, Windows has trawled the System Database, found your software, applied the fixes and stored them. The next time you run the game/app it'll quietly apply these fixes. If you list the fixes, in this section, you'll probably be surprised by just how many are being applied! All of this has been happening behind the scenes and now it's visible with the Compatibility administrator! Custom Databases Each time you start the Compatibility administrator you'll see a new untitled database. This can be thought of as your workspace for creating new fixes. None of the other sections are editable, just this one. Once you create a fix in the Custom Databases section and install it, it will appear in the Installed Databases section. Previous fixes As a retro sim fan, (or retro gamer in general) you may have already used Compatibility fixes, if you've downloaded fixes created by others, e.g. some nGlide patches use a sdb file. Compatibility fixes are saved as a AppCompat Database (.sdb) file. They are normally supplied with a couple of batch files, to install/uninstall the fix without the need for the Compatibility administrator: PatchInstall.bat (or similar), which runs a utility to install the sdb file. PatchUninstall.bat (or similar), which runs the same utility with an uninstall option on the sdb file. You can see what you may have already installed in the past, in the Installed Databases section. Creating a fix: an example In this example the following fixes/shims will be applied to the Longbow Gold executable, libwin.exe : EmulateCreateFileMapping GlobalMemoryStatusLie IgnoreException Go to the Custom Databases, highlight the New Database and click on the Fix icon, to bring up the first fix dialog box. Complete the text fields (the vendor is optional) and click next. In this example we don't want to specify any compatibility modes, so click next to skip. In the next dialog, check the boxes of the 3 fixes we want to use (it's a big list of 437 entries but they are listed alphabetically) and click next. The matching dialog, is used to match the executable to the fix. It'll use the executable filename by default, but if there were multiple versions with the same name, you can add further criteria (like a checksum) to pick that exact version. You can also add files so it will check for the existence of additional files in the same location (with their own optional criteria). You can also Auto-Generate a set of criteria. Adding additional criteria allows you to create a specific portable fix that 'should' work on any Windows 10 machine with Longbow Gold, as the criteria should be the same on every machine. Depending on the criteria chosen, it 'should' allow it to match on Longbow Gold only, while leaving other versions, e.g. Longbow Anthology unaffected. Click finish and the fix is complete. Now you need to highlight and save the New Database, give it a better name e.g. Longbow Gold and you'll get the save dialog box. Pick a filename to save it as, and a location to save it to, it normally defaults to the game install folder and save. The fix is saved as a AppCompat Database (.sdb) file. Now all you need to do is right click on the custom database and install it. The fix will appear in the Installed Databases section. Job done! Why do we save/install/uninstall a database? Remember the Compatibility administrator is a professional tool for use in business. In the example we have created a single fix for a single game, added it to a database and installed it. However a business using lots of apps may want to create multiple fixes across multiple apps, add them all to the same sdb database and install that database once, fixing all their apps at the same time. How do you know how to fix a game? The short answer is, through the kindness of strangers. I'm not a Windows developer or expert in the Windows OS internals. However, there are some amazing experts out there helping to get some great games running as well as possible on modern hardware. The VOGONS forum is one such place, game specific Discord servers, the famous PC Gaming Wiki another. The forums of specific games or game genre websites ( combatsim.com ) yet another. Populated by amazing people willing to use their skills to get games running and share their knowledge with the rest of us, I for one, am very appreciative of the help they provide.

This is a guide about the most common Glide wrappers, asks and answers questions, 'Can they coexist together?', 'How do you use one instead of the other?' and then covers use cases with games and DOSBox-X. What is Glide? Glide was the API used by old games to send requests to 3dfx graphics cards to make the graphics look pretty and run smoothly as opposed to pixelated and slower, if the game was doing the graphics itself. What is a Glide wrapper? Your modern Nvidia/AMD/Intel graphics card is a barely believable pinnacle of engineering magic, able to take DirectX, OpenGL and Vulkan API requests and render graphics at a speed and fidelity that would make Leonardo Da Vinci weep. However when it comes to Glide API requests, it's as dumb as a pile as bricks. What's needed to make Glide games run on modern hardware is some kind of tool to take Glide requests and convert them into modern DirectX/OpenGL/Vulkan requests, and that's exactly what a Glide wrapper does. It can be thought of as a wrapping around a Glide game, intercepting Glide API calls and converting them into the modern day equivalent, hence the term wrapper. The two most popular Glide wrappers are dgVoodoo2 by Dege and nGlide by Zeus. It's worth noting that dgVoodoo2 is not just a Glide wrapper but also converts DirectDraw, D3D3/5/6/7, D3D8 and D3D9 into their modern equivalents, but this article will only be discussing the Glide side of things. How does nGlide work with old games? If you download and install nGlide it adds files to Windows folder, effective becoming the 'system' Glide wrapper. It will intercept Glide calls from games no matter where they are installed on your system. nGlide uses a utility, nGlide configurator to put nGlide config settings in the Windows registry. This means the configuration is global for all games according to this forum message from Zeus. This has important implications going forward. How does dgVoodoo2 work with old games? dgVoodoo2 takes a different approach, you download a release as a zip file, unzip it into a folder and then copy the Glide files, config file and config utility into a specific game installation folder. dgVoodoo2 can be thought of as a game specific or 'local' Glide wrapper that will only be used when the specific game with dgVoodoo2 files, makes a Glide call. Other Glide games will be ignored. Will nGlide and dgVoodoo2 coexist together? Yes and quite happily without issue. Assuming nGlide has been installed and dgVoodoo2 was downloaded, a game will use the system Glide wrapper, nGlide by default. To switch to dgVoodoo2 simply copy the required dgVoodoo2 files to the game folder, configure it and dgVoodoo2 will handle the Glide requests instead. To switch back to nGlide, simply remove the dgVoodoo2 files from the game folder and nGlide will be used by default again. Can different versions of dgVoodoo2 coexist together? Yes, and you might want to do this if you had Glide games, FlightSim1 and FlightSim2 which run well under the latest version X. However, the Glide game, SpaceSim doesn't run smoothly or crashes with version X, but ran perfectly well under an earlier version Y. It should be clear this is possible by: Downloading version X and Y of dgVoodoo2. Copy version X files into the FlightSim1 and FlightSim2 folders. Configure dgVoodoo2 separately for FlightSim1 and FlightSim2. Copy version Y files into the SpaceSim folder and configure dgVoodoo2 for SpaceSim. Each game uses its own local Glide wrapper with it's own config. FlightSim1 uses a local version X wrapper, FlightSim2 uses its own local version X wrapper while SpaceSim uses its local version Y wrapper. Can different versions of nGlide coexist together? Yes, but it's going to take a bit of management. Most Glide games work perfectly well under the latest version of the Glide wrapper. However there may be a specific game, let's call it FlightSim3 that used to crash less often or perform better with an earlier version of nGlide. We can download the earlier version of nGlide and instead of running the installer, we can extract the files from the installer, with a utility like 7zip and extract those files into the game folder, creating a local, game specific FlightSim3 nGlide wrapper. So far, so good, however the nGlide config is global! There aren't a lot of config options so if the local nGlide wrapper works, without changing the config, all good. However, the configurator options changed in later nGlide versions, so if you need to apply some different config options then you'll need to: Keep a note of the system nGlide config options. Keep a note of the local, game specific config options. Apply the local nGlide settings with the local configurator, as and when needed. Apply the system nGlide settings with the system configurator, as and when needed. If we want to replace a local nGlide wrapper with a local dgVoodoo2 wrapper, then we have to: Remove the local nGlide wrapper files from the game folder. (I recommend moving to a different folder, rather than deleting in case you want to go back to the local nGlide wrapper). Copy the required dgVoodoo2 files into the game folder. Configure dgVoodoo2. If we want to replace a local dgVoodoo2 wrapper with a local nGlide wrapper, then we have to: Remove the local dgVoodoo2 wrapper files from the game folder (or move them to another folder if you might want to re-apply them later). Extract the nGlide files from the installer into the game folder (or if you took my advice above, move them back into the game folder). Take a note of the system nGlide config BEFORE you set the local nGlide config, if required. I'd suggest keeping a 'Glide settings.txt' document on your desktop. DOSBox-X When it comes to DOS Glide games and Glide wrappers, we need to talk about DOSBox-X and why it's still my preferred DOSBox app for DOS Glide games. There have been a few DOSBox apps that have included Glide support, DOSBox 0.74 with Glide/3dfx patches, DOSBox Staging and DOSBox-X. Each of these support a virtual 3dfx card which can play Glide games, but the support is in software, with the CPU having to do all the heavy lifting, with a corresponding hit on performance. However DOSBox-X has an additional option, Glide passthrough and this is a game-changer. With Glide passthrough enabled, DOSBox-X does the equivalent of throwing the Glide requests over the garden fence for someone else to deal with. That someone else will be the Glide wrappers. They will convert the request into a modern equivalent and fire it over to the GPU to do all the heavy lifting, a far better situation (after all that's what it's there for!) As far as Glide wrappers are concerned, DOSBox-X is just another Glide game sending out Glide requests to intercept and convert. How would DOSBox-X use nGlide? This is probably the most common use case. DOSBox-X would be installed as usual and Glide passthrough would be enabled within the DOSBox-X configuration file for a DOS Glide game, One of the latest (if not the latest) nGlide versions would be installed as the system Glide wrapper. A glide call from within the DOS game wouldn't be handled by DOSBox-X, but passed through to the nGlide wrapper, to be converted and passed over to the GPU (via the Windows OS). As long as DOSBox-X and nGlide is installed, Glide passthrough enabled in the DOSBox-X game config file (.conf) and the nGlide config options are suitable for that DOS game, it should all 'just work'! And in fact it does, I have my copy of JetFighter III (a DOS glide game) configured in DOSBox-X to use Glide passthrough and it just works! If you want to stop using Glide passthrough, simply disable it in the DOSBox-X game config file (.conf) and DOSBox-X will start dealing with Glide requests. Can DOSBox-X use different versions of nGlide? Yes, but it's a bit of an extreme use case and this is my subjective recommendation. A potential scenario is that all of your DOS Glide games work well with your installed version of nGlide, except one that's tricky to get working and needs an earlier nGlide version. Assuming the latest version of nGlide is the system Glide wrapper and you want to use the earlier nGlide v0.97 in DOSBox-X, I'd suggest taking a copy of your DOSBox-X folder (I'll assume C:\DOSBox-X) and renaming the copy to: DOSBox-X with nGlide e.g. C:\DOSBox-X with nGlide0.97 Then nGlide v0.97 would need to be downloaded and the files extracted into this DOSBox folder as a local, game specific (or in this case, DOSBox-X specific) Glide wrapper. You would need to change the desktop game shortcut or whatever game library manager you use, to run the copy of DOSBox-X in the 'C:\DOSBox-X with nGlide0.97' folder, rather than the standard 'C:\DOSBox-X' folder. Again, you'd have to manage and set the global nGlide config using the appropriate nGlide configurator, as and when needed. In fact there's nothing to stop you using as many different nGlide versions as you want with DOSBox-X, as long as you're careful in managing the global config! This is an extreme example and you may want to try dgVoodoo2 as the Glide wrapper (as described below), so you don't have to manage the global nGlide config. How would DOSBox-X use dgVoodoo2? Again, the potential scenario is that all of your DOS Glide games work well with your installed version of nGlide, except one (or nGlide isn't installed as the system Glide wrapper), but this time we want to try dgVoodoo2. Again my subjective recommendation would be to copy your DOSBox-X folder and rename the copy with Glide wrapper info, such as: DOSBox-X with dgVoodoo e.g. C:\DOSBox-X with dgVoodoo2.82.4 Then dgVoodoo2 v2.82.4 would need to be downloaded and the files extracted into this DOSBox folder as a local, DOSBox-X specific Glide wrapper. You would need to change the desktop game shortcut or whatever game library manager you use, to run the copy of DOSBox-X in the 'C:\DOSBox-X with dgVoodoo2.82.4' folder, rather than the standard 'C:\DOSBox-X' folder. Can DOSBox-X use different versions of dgVoodoo2? Yes, there's nothing to stop you using as many different dgVoodoo2 versions as you want with DOSBox-X, just use the advice above. Be sure to use a sensible naming strategy, so you know what you've got and where! Issues In addition to the global nGlide config that's already been covered, the only other issue would be a new release of DOSBox-X. In order to install a new DOSBox-X release: Download and install the release to your existing DOSBox-X folder (I'll assume C:\DOSBox-X), effectively replacing the old version. Copy the files and folders in 'C:\DOSBox-X' and paste into each of the folders named: C:\DOSBox-X with As long as you followed the advice above there should be no Glide wrapper files in 'C:\DOSBox-X', so pasting should only replace the DOSBox-X files and folders, leaving the Glide wrapper files untouched. In conclusion It's turns out that Glide wrappers are a pretty peaceful & harmonious bunch and can coexist quite happily. In fact you could have every single version of them, all on the same machine (not recommended!) and as long as you can manage the nGlide global config, it should just be smooth graphics and blistering performance!

This is a quick post about Thrustmaster T-Flight Rudder Pedals (TFRP) becoming unresponsive when a Target software profile is run which includes the TFRP. Warning : Make sure your are comfortable doing this, this is for informational purposes only. I can't take responsibility for any loss or damage incurred. This is working on my particular machine and setup, your experiences may differ. Setup You have your TM hotas setup and working. You have TFRP plugged into a usb port using the supplied TFRP adapter. The TFRP adapter is correctly set to the 'flight' setting and the LED on the adapter is green. All the devices can be seen by windows and are calibrated and seem to be working. You have the latest version of Target installed and Target GUI application works without issue. The problem You create a new Target profile or update an existing Target profile in the Target GUI, adding the TFRP. You run the profile in Target GUI and it starts correctly. However when you look at the test tools available, both the Device Analyzer and Joystick Control Panel show the TFRP to be unresponsive. Moving the pedals just doesn't change anything within these test tools. You may have also noticed that the LED is not showing at all on the TFRP adapter. The TFRP has been disabled, the physical TFRP controller is replaced by the virtual controller created when running the Target profile. This is normal and all the physical TM hotas controllers will be disabled, replaced by the virtual controller. They all come back once the Target profile stops running. However the other hotas controllers remain powered on, while the TFRP seems to go into a powered off state. An update and a fix! The below workaround is not longer recommended, as an actual fix has been found for this issue, take a look at Unresponsive Thrustmaster rudder pedals in TARGET: A fix! The workaround (not recommended) Run up the profile in the Target GUI. Run the Windows Device Manager application. In the View menu, change the selected option to Devices by container . This makes it easier to find the rudder pedals. Expand the T-Rudder section. You should see a HID-compliant game controller and USB Input Device . Right click on the HID-compliant game controller and select Enable device . This should make the LED on the TFRP adapter come on and the pedals should be responsive once again. You may have to repeat this each time you run a profile with the TFRP included. If you look at the Joystick Control Panel test tool you should see the rudder pedals working in the virtual game controller normally. Some background This is a quick list of some of the things I tried before discovering the workaround, none of which resolved or reduced the frequency of the issue: Plugging TFRP into a USB 3.0 port in a hub. Plugging TFRP into a USB 3.0 port on the motherboard. Plugging TFRP into a USB 2.0 port on the motherboard. Setting the power management in Windows 10. Disabling USB device powering down in Windows 10  power management. Disabling the 'Allow the computer to turn off this device to save power' option for each USB device, USB controller and Thrustmaster device in the Device Manager. Notes: If you continually move the pedals as you run the Target profile, the pedals will remain responsive and the green LED remains on in the adapter, as soon as you stop moving the pedals they become unresponsive and the adapter LED goes out.

This is my quick explanation and DOSBox Staging team workaround for why GOG menus created for some retro classics look fine under vanilla DOSBox bundled with the game, but look bad under DOSBox Staging and what we can do to fix this. As retro sim fans we've probably got one or more retro sim releases from GOG and some of these classic DOS games have a little DOS menu added by GOG. These menu may allow you to run an installer to set graphics and sound options, or play the game in a different language. Before we start As an example I've be using my GOG release of Subwar 2050 Complete. It has been installed using GOG Galaxy and the installation folder is found at D:\Program Files (x86)\GOG Galaxy\Games\Subwar 2050 . Obviously your installation folder may be different. If we run Subwar using the GOG added icon, vanilla DOSBox is started and we see the GOG menu. Everything looks good and we can run our game with vanilla DOSBox. DOSBox Staging But we want our aspect correct, CRT like graphics, we want our MT-32 or fluidsynth midi, we want all those extras we don't get with vanilla DOSBox. So lets create a DOSBox Staging configuration file. I created mine in D:\games\dos\Subwar 2050\conf\Subwar2050-staging.conf . So the menu is defined in the GOG DOSBox config file dosboxSUBWAR_single.conf in the Subwar installation folder. Lets take a look. Well that menu doesn't right, what's happened? The text looks ok but the double border characters look all kinds of wrong. Well it's due to character encoding. Character encoding We deal with letters, words, sentences, computers deal in numbers. All character encoding is about, is converting letters into numbers, so your pc can deal with it. And there's more than one character encoding. DOS and vanilla DOSBox uses a character encoding called codepage 437, this is the character encoding used to create the GOG menu, with the nice border, and set the yellow text and green background colours. The text editor uses a different character encoding called UTF-8. Some of the characters are the same like the alphabetic and numeric characters, but the border, text and background colour setting characters aren't, but the text editor tries it's best and shows us those weird characters instead. No problem then, we'll just copy the autoexec section from dosboxSUBWAR_single.conf into our DOSBox Staging config, change the mount commands to point to our Subwar installation folder and create a DOSBox Staging shortcut using our new Staging config, fire it up and it should all be good. For a good cause Well that kinda works, in fact it actually does work. You can choose a language option or set game settings and it works as intended, it just doesn't look as intended! It turns out that while DOS and vanilla DOSBox use codepage 437 character encoding, DOSBox Staging has switched to using UTF-8 in their configuration files. But why you ask? Well UTF-8 has an extensive set of characters, not just English characters, but characters from a multitude of languages from around the world. If a DOSBox Staging user wants to use his native language for folder names, DOSBox Staging is jolly well going to support them. Classic DOS gaming knows no international borders! Retro flight sim fans of the world UNITE! Workaround Well it turns out the DOSBox Staging team understand we want to have our free cake and eat it! So a workaround was implemented. The configuration file continues to use UTF-8 character encoding but a DOS batch file will use codepage 437 character encoding. They really are too good to us! What this means is: We can create a batch file in the Subwar installation folder, I let my imagination run wild and chose gogmenu.bat and copy the menu into this batch file. Call the batch file from the DOSBox Staging config file. So my DOSBox Staging config file now looks like this: [autoexec] # Lines in this section will be run at startup. # You can put your MOUNT lines here. mount C "D:\Program Files (x86)\GOG Galaxy\Games\Subwar 2050" mount C "D:\Program Files (x86)\GOG Galaxy\Games\Subwar 2050\cloud_saves" -t overlay c: call gogmenu.bat We use the call command as we are calling a batch file from within the DOSBox Staging autoexec (batch file) section. Now when we run DOSBox Staging with this config file we get.... SUCCESS!! References [BUG] ANSI Text Not Displaying Correctly in Latest Dev Build

When it comes to configuring DOSBox, we'll want to take a look at the joystick section: [joystick] joysticktype = auto timed = true swap34 = false deadzone = 10 These settings will take some trial and error as they'll depend on your controllers and on your personal preference. You need to try some test flights, to see if they need to change. I set my joystick type to 4axis. If you experience controller drift as you fly you might want to try setting timed to false. After a few tests flights my controllers were ok so I left this setting at the default. If the throttle/collective acts as the rudder and the rudder acts as the collective you can swap these axes. During my first test flight, this happened so after quitting the sim and DOSBox I had to swap axis 3 and 4 by changing swap34 to true. I also prefer a smaller deadzone but that's just personal preference. In my case I ended up with the following settings: [joystick] joysticktype = 4axis timed = true swap34 = true deadzone = 1 In DOSBox-X the deadzone option doesn't exist, instead there's a mapper section immediately following the joystick section, with a deadzone option for each joystick and axis: [mapper] joy1deadzone0- = 0.60 ... joy2deadzone7+ = 0.60 I tend to set mine to 0 but you can tweak them to your personal preference. DOSBox Keymapper Also known as just the Mapper in DOSBox Staging. This utility allow you to assign buttons to keys and shows you which of your controller axes are mapped to the 4 axes in DOSBox. If you aren't using profiling software, this utility will allow you to rebind DOSBox axes to your controller axes. Each axis is split in half into a negative and positive area. Clicking on the box representing a joystick axis shows the current axis mapping. Depending on your controller(s) you may want to rebind the axes if you're not using your HOTAS profile utility or you don't have one. You have the ability to del ete the current binding and then add  a new one. Once you click the add button, move the controller in the appropriate direction. Setup the game You'll probably have to return to the game setup to configure and calibrate your controllers. First flights So it's time to fire up the flight sim and kick off free flight or a training mission. The aims of these tests will be to ensure the controller(s) behave as expected. So get up into the air (if you can) and test each of the axes you have configured. Might also be worth ensuring your disabled axes are actually disabled! When I first set up pedals, the pedals controlled the collective and the rudder pedals controlled the collective, so I had to quit the game and swap axis 3 and 4 in my DOSBox config before trying again. Once the testing is over you're done, now go enjoy all that hard work!

There are a few of rules I'd advise you to follow: You don't have to set everything up all at once. I almost never do. I usually set up the joystick and throttle and only later, once I'm happy with the config, will I start on adding rudder pedals into the setup. If you're not confident, start with your stick, then later add the throttle and finally add the rudder (pedals). Change one thing and test. Don't try and change too much, there are a lot of parts to all this, trying to figure out what's gone wrong after changing a lot of things will get very frustrating very quickly! Calibrate your controllers! Or least check they are well calibrated, lets eliminate one source of problems before we start on this journey! This process is going to depend on your particular pc and controllers, so it'll be different for everyone! Remember it's probably going to be an iterative process, tweaking settings and discovering issues during the first few test flights! The first time you do this, it may be a bit of pain, but it does get easier once you've done it a few times and you understand the emulator (DOSBox, PCem, SheepShaver, QEmu, MAME, etc.) and your controller setup.

In the old DOS days of yore you might have a joystick, sometimes a joystick and throttle and if you were very lucky a joystick, throttle and rudder pedals. One controller would act as a 'hub' and the rest would plug into it (usually with some proprietary cable) and a Gameport cable would run from the hub controller into a Gameport socket in your soundcard. You might have had 2 or 3 controllers but as far as your pc was concerned it was a single Gameport device. You'd plug it all in, calibrate the controllers in the game and away you would go. Fast forward a few years and the Gameport has gone, to be replaced by USB. Later USB controllers like the Saitek X45 or Logitech X52 Pro would continue to use a similar design. One controller would be the hub and the rest would plug into it (still with a proprietary cable). Now a USB cable runs from the 'hub' controller into a USB port. But as far as your pc was concerned it was still a single USB device. These days we'll often find that the mid/high end controllers are USB devices in their own right. My Warthog stick, throttle and rudder pedals are each a USB device, this has some important implications for retro flight sims. DOS Flight sims Most (if not all) DOS flight sims will support a maximum of 4 axes. I can't think of a DOS based sim requiring more than 4 axes, and some games will only support fewer. Those 4 axes will be: The joystick X/Y axes. The throttle (collective for helicopter sims) axis. The rudder axis. Windows 10/11 (I'm assuming that's the platform most of us are using) has a limit of 8 axes per USB device. So a USB HOTAS controller should be able to supply enough axes for our DOS flight sim. Emulators would really like to see is a single device with 4 axes or fewer. It'll be ok with a single device with between 4 and 8 axes, but it's probably not a fan of multiple USB devices. If I just try and use DOSBox-X with my joystick, throttle and pedals connected. It'll happily ignore the stick and pedals and only pick up the throttle as a 4-axis device. Controllers, devices and axes. So the question we need to ask is: Given the controllers I wish to use, how many devices and axes is that? If it's a single USB device with 4 axes or fewer then an emulator like DOSBox should find them all. There may still be to be some configuration but they are available. If it's a single USB device with 4 -8 axes then an emulator like DOSBox should find the device but you may have to tell it which axes you want to use. If it's multiple USB devices and/or 8 axes or more then we need to take a look at virtual controllers. With my Warthog stick, throttle and rudder pedals I have a total of 3 devices and 10 axes (I think). In my case I need to create a virtual device for my Warthog devices and rudder pedals.

A guide to organising midi roms and soundfonts for DOSBox use. When using midi roms or soundfonts it's all too easy to stick them in whatever folder is handy at the time. After a while you have midi roms and soundfonts everywhere and then you have to track them down to find the ones you want. We'll take a look at organising the Roland roms and soundfonts. You'll want to have DOSBox Staging installed, to determine the rom version. The first step is to create a folder to hold all our roms and soundfonts. I choose Midi as this folder on my D: drive: D:\Midi Roland MT32 and CM32L roms Now, things have moved on since the early days of DOSBox and there are now versioned (new style) and un-versioned (old style) roms. The version of the roms you have can affect the gameplay experience as some games can sound a bit odd if you aren't using the optimal version. The VOGONS wiki has a very useful page List of MT-32-compatible computer games for deciding which version is the optimal one. A complete set, optimal for any game, will be CM32L (CM series), MT32 new and MT32 old roms. Un-versioned (old style) The un-versioned (old style) roms for the MT32 and CM32L don't give us any version information. Un-versioned roms can be used by DOSBox-X or DOSBox Staging. They are normally named: MT32_CONTROL.ROM MT32_PCM.ROM CM32L_CONTROL.ROM CM32L_PCM.ROM However to determine the version of the MT32 roms we can add them to our Midi folder and point DOSBox staging at it, in a config file with: [mt32] romdir = "D:\Midi" You may want to use one of your existing config files to do this as changing the default config file can be a bit tedious given it's location (in Windows): C:\Users\\AppData\Local\DOSBox\ We can run up DOSBox Staging and issue the command: mixer /listmidi DOSBox Staging will show us all of the CM32L and MT32 roms it knows about and more importantly, the ones it has detected. If you have all four files mentioned above it should have found a CM32L version and an MT32 version. The filenames are unimportant to DOSBox Staging as it checks the version based on the file contents. It'll also choose a version to use (highlighted) but that's unimportant for this test. MT32 old roms are v1.04 - v1.07 MT32 new roms are v2.03 - v2.07 'bluer' is the Blue Ridge rom, based on v1.07 which doesn't provide anything extra, except a bug that can crash your game. Move the CM32L roms into a CM32L folder and the MT32 roms into a MT32 old or MT32 new folder depending on what DOSBox Staging found. So you might have: D:\Midi\CM32L D:\Midi\MT32 old or D:\Midi\MT32 new Versioned (new style) Versioned roms are normally grouped together in a single collection and zipped up for distribution. Versioned roms can only be used by DOSBox Staging (at time of writing). Example files may include: ctrl_cm32l_1_02.rom ctrl_mt32_1_07.rom ctrl_mt32_2_04.rom pcm_cm32l.rom pcm_mt32.rom To use them you would unzip the collection to a suitable folder, in my case I chose: D:\Midi\Versioned If you are missing a particular un-versioned rom you can use the versioned rom. For example if you were missing the un-versioned MT32 new rom, you could use the versioned v2.04 rom by: Creating a suitable folder, eg. D:\Midi\MT32 new Copy ctrl_mt32_2_04.rom into the folder and rename it MT32_CONTROL.ROM Copy pcm_mt32.rom into the folder and rename it MT32_PCM.ROM This would result in an MT32 new rom that could be used by DOSBox-X. Soundfonts If you're feeling adventurous, you can try a soundfont. DOSBox-X and DOSBox Staging have a fluidsynth component built in. You can specify the fluidsynth component as your midi device and supply a soundfont, a file in a .sf2 format. A soundfont can make old DOS game music sound amazing, really really weird or somewhere in between. If you're interested, the midi section of the DOXBox-X wiki  and the DOSBox Staging Wiki Midi page are both good places to start and well worth a read. I chose the following folder for soundfonts: D:\Midi\Soundfonts I've picked up a few including: Arachno FatBoy FluidR3 Timbres Of Heaven Any you wish to use will be down to personal preference. The final Midi folder My final midi folder now looks like this: D:. \---Midi +---CM32L +---MT32 new +---MT32 old +---Soundfonts +---Versioned DOSBox-X DOSBox-X can use the un-versioned roms or soundfonts, an example config might look something like this: [midi] mididevice = mt32 mt32.romdir = "D:\Midi\CM32L" # or "D:\Midi\MT32 new" # or "D:\Midi\MT32 old" # or mididevice = fluidsynth fluid.soundfont = "D:\Midi\Soundfonts\FluidR3_GM_GS.sf2" DOSBox Staging DOSBox Staging can use un-versioned roms, versioned roms or soundfonts, versioned roms being easier to use. An example config might look something like this: [midi] mididevice = mt32 # or fluidsynth [fluidsynth] soundfont = "D:\Midi\Soundfonts\FluidR3_GM_GS.sf2" [mt32] model = auto # or cm32l, mt32_old, mt32_new romdir = "D:\Midi\Versioned" With all the roms and soundfonts in one place there is no reason other applications can't reference them from this location, eg. ScummVM.

This is an update to an earlier blog post: Failing successfully: A SheepShaver random startup error . Some good news, the latest version of SheepShaver for Windows has fixed (or at least massively reduced) the ' Cannot map SheepShaver Data area: No error ' error. The current version (at time of writing) is SheepShaver-Windows-25-02-2024, which implements this fix. You can find a link to this version on the Emaculation SheepShaver forum, SheepShaver for Windows post . Farewell weird SheepShaver error!

If you spend a lot of time running the SheepShaver emulator there's a really weird error that occurs randomly. The emulator fails to start, which is weird, as it may have started fine yesterday, an hour ago or even 5 minutes ago. You haven't made any changes, what's going on? It turns out you've done nothing wrong. It's just that SheepShaver can be a bit finicky about the memory it wants and in this case, another windows process has nabbed the memory SheepShaver had it's eye on. SheepShaver complains and doesn't want to play, so you see this error. It's an easy fix, in the words of Roy from the IT crowd, 'Turn it off and on again'. Just restart Windows, in nearly all cases this will fix it. Very very occasionally I've had to restart Windows twice before SheepShaver got what it wanted and started. At time of writing the latest version is SheepShaver-Windows-27-08-2023-framebuffer and the error is still present and occurring randomly in this version.

I've recently written my first MAME plugin 'MacFlight'. It's job is to turn a relative axis into an absolute one. It does this by looking for the X and Y axes of a joystick controller, translates this into a position on screen which is then converted to a mouse input. This means the your joystick controls the mouse and the mouse operates like a joystick. This is what you need for retro Mac flights sims! Background From an earlier blog post: Joystick axes are normally absolute axes, they report exactly where they are. For example, if you use Win10 joy.cpl to test moving your joystick x-axis then moving your stick to the right would cause the pointer in the axes box to move to the right but releasing the stick would cause the pointer to jump to the centre position again. This is what we want in flight sims. But a mouse uses relative axes, you move your mouse to the right the mouse pointer moves right, you stop moving the mouse and the pointer stays exactly where it is. This is what you want from a mouse. As retro Macs treated their joysticks like a mouse device it used relative axes. So if you release a Mac joystick it doesn't snap back to a centre position. This is not what we want in Mac flight sims! When trying to fix this I came across, an interesting utility ajoy2mouse on aminet. Used with the Mac emulator Shapeshifter on the Amiga, it does for the emulator what the Gravis applets did for their joysticks. How it works MacFlight works by first identifying the joystick devices MAME can see, If there is only one it uses it, otherwise it searches for the first device called joystick. It then finds the x and y axes of this device. If you are running a profile for a number of devices (eg. joystick and throttle), the profile software may create a virtual device which appears as a single device to MAME. It may not be called joystick so if there's only one joystick device, MacFlight uses it. It then identifies the screen resolution, which is used to calculate the mouse position and then waits 45 seconds for the emulated Mac to start, before getting the MAME memory manager for the emulated Mac. This gives the emulated Mac time to complete initialising before MacFlight starts sending mouse position data. Sending data before the Mac has started can cause it to fail. Each time a frame is rendered the x and y axis of the joystick device is read and a new mouse position calculated. This calculated mouse x and y position is then sent by the MAME memory manager to the location used by the emulated Mac to store the mouse x and y co-ordinates. The memory locations are dependant on the configured memory of the emulated Mac. Prerequisites MAME v0.260 with a working emulated Quadra 800 configured with 32M of memory. Different memory configurations may not work due to a different memory location used to store the mouse co-ordinates. Update: MacFlight v1.2 now supports 32, 64 or 128M memory configurations. Installation Download the MacFlight plugin and extract into the MAME plugins folder. There should be a macflight folder containing 2 files: init.lua and plugin.json . Running Run MAME with the following command: mame macqd800 -hard1 mac761.chd -ramsize 32M -cheat -plugin macflight Note: your hard disk image may have a different name. After 45 seconds the mouse pointer should jump to the middle of the emulated Mac screen and the mouse pointer should be controllable with the joystick. You may want to use MAME input settings to add a joystick button to the mouse click action, otherwise you still have to use your mouse button to click! Debugging To see the joystick that MacFlight found, run MAME with the following command: mame macqd800 -hard1 mac761.chd -ramsize 32M -cheat -plugin macflight -w -console This opens the emulated Mac in a window ( -w ) and also opens a console window ( -console ) within the console you should see the joystick device and x/y axes found along with the emulated screen resolution. If the emulated Mac needs longer to start, open init.lua in a text editor and search for the following: -- time to wait (in seconds) for machine to start local WAIT = 45; Change WAIT to a larger amount of time, save the file and restart MAME. To run MacFlight with the debugging overlay enabled, open init.lua and search for the following near the bottom of the file: -- debugging overlay -- emu.register_frame_done(draw_overlay, 'frame') Uncomment the second line: -- debugging overlay emu.register_frame_done(draw_overlay, 'frame') Restart MAME, you should now see the debugging info and joystick axes position. Download MacFlight v1.3 plugin. Supports multi-monitor 640x480, 832x624 or 1152x870 resolutions (only at 128M memory). MacFlight v1.2 plugin. Now supports ram sizes 64M and 128M in addition to 32M. MacFlight v1.1 plugin. Now supports resolutions 832x624, 1024x768, 1152x870 in addition to 640x480. Refactored screen resolution handling as MAME will always start the Mac in 640x480 before changing resolution. Will now list all joystick devices and device items on the console, if an x or y axis can't be found. MacFlight v1.0 plugin. Future enhancements The mouse pointer memory locations seem to be dependant on the configured memory, add locations for common memory sizes (eg. 64M 128M, etc). Hopefully they don't change with a 32M setup! The joystick device and axes selection was based on my own setup, not sure how robust it is as other devices may report themselves to MAME differently. Not sure how it works with an emulated multi-monitor setup, that still needs testing/fixing.