Search Results

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.