I felt the need to separate GOG game installs from DOS games I’ve got that I’ll be setting up manually or through Steam. The great thing about GOG (Good Old Games) games is that they do a lot of the legwork for getting old games to run on modern systems. However, they’re not always great – they sometimes have issues, or occasionally lack content I’ve got on my original CDs or floppy images I’ve saved off. Plus, I may want to run these with a different version of DOSBox, since a lot of the GOG games come packaged with DOSBOX 0.74-XXX. I’d like to try some of these with DOSBOX-X and take advantage of save states and shaders which seem to be better supported there.

Nevertheless, they’ve tweaked a lot of the DOSBOX settings for CPU cycles and such on their end already, so that should save me some heavy lifting and fine-tuning… hopefully.

Here are some of the software / utilities I used when bringing in some GOG games:

GOG install and personal tweaks to GOG’s DOSBOX

So, I installed GOG Galaxy, linked my account, and found the myriad of games I’ve purchased over the years. First stop, a personal favorite – Heroes Of Might and Magic. I’m going to focus on the first of the series, which uses DOSBOX.

Now, my personal flavors on DOSBOX gaming are that I’d like full screen (I’d prefer borderless window but that’s not something I’m sure I can do with DOSBOX) at the host machine’s resolution, so I don’t encounter a crap ton of resolution switching on my monitor if I want to look at manuals or reference cards.

In the past, I would manually tweak a GOG games unique DOSBOX config to my liking, with generally these settings:

[sdl]
fullscreen=true
fullresolution=desktop
output=opengl

[render]
aspect=true

GOG stores the main dosbox config for each game in the game’s dosbox<abbreviation>.conf file. So for Heroes of Might and Magic 1, that ends up being dosboxHOMM1.conf. I may automate some of these changes, but for now I’m manually doing these to see how things play out first. In fact, each GOG game gets its own DOSBOX copy stored underneath the game’s main directory:

The game loads up fine, though I do find it annoying that if I alt-tab out to look up a page in the manual and go back, DOSBOX reverts to the window, I have to hit alt-enter to go back to full screen. At least I don’t have the monitor itself changing resolutions on top of it. DOSBOX-X, thankfully, doesn’t do that, but we’ve not converted our GOG HOMM to DOSBOX-X yet.

DOSBOX-X install and initital configuration

Now, I’ve installed my generic DOSBOX-X copy in a single directory under my D:\Emulators path:

Now, as far as DOSBOX-X goes, I’ve edited the dosbox-x.conf that comes with the download and tweaked to my liking.

[sdl]
output=opengl
fullscreen=true
autolock=true
autolock_feedback = none

[render]
aspect         = true
aspect_ratio   = 4:3
glshader       = crt-lottes-krystof.glsl

You may notice the glshader entry in there. That’s a custom one I was tweaking – you can make your own or point to one of the built in defaults under the glshaders directory. Definitely something to play around with.

Swapping HOMM’s DOSBOX for my DOSBOX-X

If I run dosbox-x.exe, it works, and everything is happy. Now, the question I have… Can I somehow swap out the DOSBox that my GOG Heroes of Might and Magic usses to use my global DOSBox-X directly? It leads me to other questions:

• How do we point a GOG game to use my dosbox-X under D:\emulators\dosbox-x? What about configs?
• If we can swap a GOG’s dosbox to dosbox-x, can one dosbox-x config handle all the GOG games? Probably not
• How do we have a common config and allow overrides as needed with dosbox-x?
• How can we take a GOG’s customized DOSBOX-.74 config and overlay them on top of my global DOSBOX-X config?

First off, the manual approaches. Even if this works for one game, that doesn’t mean it will work for all, so I anticipate having to come back and make changes. Perhaps I can automate some of them.

HOMM GOG’s DOSBox has multiple configuration files:

The launcher link also calls this, and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

So we can see they’re already using overrides – the ‘single’ conf file overrides their HOMM global config file. We also have some relative paths in there, going to the parent directory (which is the HOMM install). The ‘single’ file seems to be more of the autoexec related work, and doesn’t try to override much in the way of rendering, though it does shut ipx off.

Brute Force – Duplicate DOSBOX-X and use it against the GOG HOMM’s DOSBOX 0.74 configs

How can I swap out the EXE? I could just copy all of dosbox-x and duplicate a game-unique DOSBOX install inside HOMM’s dosbox directory, which is effectively what they do. Let’s try that, and rename dosbox-x.exe to just dosbox. This means we won’t have to change the shortcut. I did that and to be sure, deleted any dosbox-x.config files in my HOMM dosbox copy. So now we have the DOSBOX-X binary being executed, but using the dosboxHOMM config files, which we know target the original DOSBOX-0.74 version. Just because we’re using DOSBOX-X binaries doesn’t mean we can assume DOSBOX 0.74 configs will just work 100% without flaw. At least I wouldn’t think so. Perhaps I have trust issues.

Result? Successful proof of concept. It worked – with a side note. I had to click into the program and heard an audible ‘click’ when I activated the window. I don’t recall that being a thing. But we aren’t taking advantage of any spiffy DOSBOX-X configs, and if there are any defaults in our global dosbox-x we set, we’re not picking them up, since we made a complete duplicate dosbox-x. It’s not what I want long term.

Next step – Overwrite dosboxHOMM1.conf with our dosbox-x global config contents.

I tried this just to see if it would still load. Now what this also means is that we would lose ANY HOMM specific dosbox configurations since we’re going to replace it with dosbox-x. So things like CPU cycle settings, sound card configs, xms,ems settings, etc. that GOG curators put in there would be lost. This probably won’t fly long term, just wanted to see how well it would work. So, I wiped did a copy and paste of the file contents of my global dosbox-x.conf into the file dosboxHOMM1.conf.

Result? Mixed but doable. We did get the shader working, but a couple of oddities. The mouse only worked in full screen mode. In window mode (for dosbox x you toggle full screen with F11-F) I couldn’t get a mouse cursor anymore. Switching back to fullscreen fixed that. To solve this, I needed to change my dosbox-x.config:

[sdl]
autolock=true
autolock_feedback = none

autolock_feedback set to none removes the ‘click’ when dosbox locks the mouse (that same audible click I heard the first attempt). Your call. You can hit CTRL-F10 to unlock the mouse again.

Dont’t forget, we copied our dosbox-x.conf contents into dosboxHOMM1.conf. That’s not a good long term solution, we’re just doing proof of concept.

So, that worked, but it worked this time... I totally expect some games to not tolerate this, because something in the game specific DOSBOX config would be lost if we did this for each game. You can see with the autolock we already had a deviation from the dosbox-x default, but in this case, I’m fine with changing it. However, it won’t always be the case – what if a DOS game wants EMS memory setup but another DOS game crashes because of it? I suspect I’ll have to handle those cases.

What would be useful is a program that parses dos box config files, looks for values that don’t match default or ignorable patterns, and reports just meaningful differences. Then we can take those differences, put them in the override dosbox config (e.g. dosboxHOMM1_single.conf), and still use our generic dosbox-x.conf as the primary for all of our games. That’d be great, because if we want a different shader, they automatically apply to all the games. We can still use the override file if we want to change it for a specific game, too.

What about those .lnk (Windows Shortcut) files? GOG is using those to launch from it’s launcher. If I import GOG games into LaunchBox, it’s going to use those .lnk files as well. I’d like to leave the link intact, but I may need to modify them if I want to try to make some global dosbox.config usable. But say I could do that, what does that look like?

Attempting to use a single DOSBOX-X install and base config for multiple GOG games

Let’s see if this even works before I worry about modifying Windows Shortcut links.

Resetting our GOG HOMM from scratch again…(Backups backups backups)

Recall our initial .lnk shortcut pointed this way and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

That means dosboxHOMM1_single.conf is referencing paths from the standpoint of our GOG HOMM’s DOSBox directory. So we must start our command there just like the link does. But if we want to use a global DOSBOX config in our D:\Emulators\dosbox-x, we’re at a bit of an impasse.

So, in a command line prompt, I switched to the GOG HOMM DOSBOX directory and ran this command line instead from the GOG HOMM DOSBOX dir:

D:\GOG Galaxy\Games\HoMM\DOSBOX> d:\Emulators\dosbox-x\dosbox-x.exe -conf "d:\Emulators\dosbox-x\dosbox-x.conf" -conf "../dosboxHOMM1_single.conf"

This actually worked. I was surprised, since I half expected it to not find my custom shader, but it looks like dosbox-x is looking in it’s folders appropriately. But what about any DOSBOX junk in the GOG HOMM folder left over? We’re not actually using that DOSBOX anymore, we’re just starting in that directory so the relative paths in our dosboxHOMM1_single.conf work.

My current plan is as follows for each GOG game, and summarizes the plan based on our results above:

• Modify the .lnk to point to our DOSBox-X base config, but still utilize the game-specific override config
  • I”ll look at this GitHub repo and maven artifact: https://github.com/DmitriiShamrikov/mslinks which seems to allow me to edit windows shortcuts programmatically.
  • Using that, I now have some throwaway-ish Java code that does the following:
    • Spin through GOG games via network share to my retro machine
    • Look for a shortcut in each game root folder
    • If shortcut has dosbox in its target, make backups of the GOG DOSBOX config files.
    • Point the first config in the shortcut to our dosbox-x global config under D:\Emulators\dosbox-x instead of the GOG game specific primary dosbox.config
    • Change the shortcut target to point to our dosbox-x.exe in D:\Emulators\dosbox-x
• If a game doesn’t ‘just work’ with DOSBox-X: Look at the now abandoned ‘GOG-specific’ dosbox config and determine if anything unique to that GOG game needs to be put in the override config. See if we can automate this looking for the most common reasons a DOSBox game would have issues (e.g. cpu cycles)
  • I’ll have to find a DOSBox properties parser or roll my own. We need to support [bracket] sections and retain linefeeds and comments. I searched around a bit and though I found some INI file parsers, they didn’t handle the DOSBOX autoexec section very well (since they’re not key-value pairs). Ended up rolling my own simple parsing mechanism that gets the job done.

Progressing through my GOG installs

After figuring out how to do this for Heroes of Might and Magic 1 and 2 (the rest in the series are native windows apps from GOG), I continued on with my other GOG installs. Anything of interest noted below:

DOSBOX Settings I take from the GOG install and put into the override file before pointing a GOG game at DOSBOX-X

My thought is that I only want to take certain settings out of GOG’s DOSBOX-0.74 config and put them into the override file. If I take everything, it would overwrite full screen and shader settings that I want to utilize with the DOSBOX-X binaries and my global config.

I thought it’d be an interesting exercise to look at ALL GOG DOSBOX configs at once and count occurrences of unique key value pairs. Here’s the raw dump:

Occurences of keys/values across all dosbox GOG configs:
83	 cpu.core.auto
4	 cpu.core.dynamic
3	 cpu.core.normal
9	 cpu.core.simple
1	 cpu.coretype.auto
5	 cpu.cputype.386_slow
5	 cpu.cputype.486_slow
86	 cpu.cputype.auto
1	 cpu.cputype.pentium_slow
3	 cpu.cycledown.100
88	 cpu.cycledown.1000
1	 cpu.cycledown.10000
2	 cpu.cycledown.20
1	 cpu.cycledown.50
2	 cpu.cycledown.500
2	 cpu.cycledown.5000
1	 cpu.cycles.10000
1	 cpu.cycles.100000
1	 cpu.cycles.11000
1	 cpu.cycles.15000
2	 cpu.cycles.19000
2	 cpu.cycles.20000
1	 cpu.cycles.300
1	 cpu.cycles.3000
1	 cpu.cycles.35000
1	 cpu.cycles.4000
3	 cpu.cycles.500
2	 cpu.cycles.5000
1	 cpu.cycles.50000
1	 cpu.cycles.7500
2	 cpu.cycles.8000
1	 cpu.cycles.80000
1	 cpu.cycles.9000
29	 cpu.cycles.auto
2	 cpu.cycles.auto limit 16000
1	 cpu.cycles.fixed 10000
1	 cpu.cycles.fixed 12500
2	 cpu.cycles.fixed 14000
1	 cpu.cycles.fixed 15000
2	 cpu.cycles.fixed 30000
1	 cpu.cycles.fixed 35000
1	 cpu.cycles.fixed 6000
1	 cpu.cycles.fixed 60000
1	 cpu.cycles.fixed 7000
1	 cpu.cycles.fixed 8000
33	 cpu.cycles.max
2	 cpu.cycleup.10
3	 cpu.cycleup.100
88	 cpu.cycleup.1000
1	 cpu.cycleup.10000
1	 cpu.cycleup.50
2	 cpu.cycleup.500
2	 cpu.cycleup.5000
1	 dos.automount.true
2	 dos.ems.false
97	 dos.ems.true
1	 dos.files.127
93	 dos.keyboardlayout.auto
6	 dos.keyboardlayout.none
99	 dos.umb.true
99	 dos.xms.true
98	 dosbox.captures.capture
98	 dosbox.language.
98	 dosbox.machine.svga_s3
1	 dosbox.machine.vesa_nolfb
83	 dosbox.memsize.16
9	 dosbox.memsize.30
3	 dosbox.memsize.32
3	 dosbox.memsize.63
1	 dosbox.memsize.8
1	 dosbox.vmemsize.4
1	 glide.glide.true
1	 glide.grport.600
1	 glide.lfb.full
3	 gus.dma1.3
3	 gus.dma2.3
96	 gus.gus.false
2	 gus.gus.true
96	 gus.gusbase.240
93	 gus.gusdma.3
93	 gus.gusirq.5
7	 gus.gusrate.22050
89	 gus.gusrate.44100
3	 gus.irq1.5
3	 gus.irq2.5
96	 gus.ultradir.C:\ULTRASND
1	 innova.innova.false
1	 innova.quality.0
1	 innova.samplerate.22050
1	 innova.sidbase.280
2	 ipx.Connection.0
2	 ipx.Enable.0
7	 ipx.ipx.false
98	 joystick.autofire.false
64	 joystick.buttonwrap.false
34	 joystick.buttonwrap.true
1	 joystick.joysticktype.2axis
97	 joystick.joysticktype.auto
95	 joystick.swap34.false
3	 joystick.swap34.true
6	 joystick.timed.false
92	 joystick.timed.true
1	 log.bios.true
1	 log.cpu.true
1	 log.dma_control.true
1	 log.dosmisc.true
1	 log.exec.true
1	 log.fcb.true
1	 log.files.true
1	 log.fpu.true
1	 log.gui.true
1	 log.int10.true
1	 log.io.true
1	 log.ioctl.true
1	 log.keyboard.true
1	 log.logfile.
1	 log.misc.true
1	 log.mouse.true
1	 log.paging.true
1	 log.pci.true
1	 log.pic.true
1	 log.pit.true
1	 log.sblaster.true
1	 log.vga.true
1	 log.vgagfx.true
1	 log.vgamisc.true
4	 midi.config.
4	 midi.device.default
94	 midi.midiconfig.
94	 midi.mididevice.default
98	 midi.mpu401.intelligent
1	 midi.mt32rate.auto
87	 mixer.blocksize.1024
10	 mixer.blocksize.2048
2	 mixer.blocksize.4096
98	 mixer.nosound.false
6	 mixer.prebuffer.20
3	 mixer.prebuffer.240
68	 mixer.prebuffer.25
1	 mixer.prebuffer.30
4	 mixer.prebuffer.40
1	 mixer.prebuffer.512
16	 mixer.prebuffer.80
5	 mixer.rate.22050
93	 mixer.rate.44100
1	 mixer.swapstereo.false
1	 ne2000.macaddr.AC:DE:48:88:99:AA
1	 ne2000.ne2000.true
1	 ne2000.nicbase.300
1	 ne2000.nicirq.3
1	 ne2000.realnic.list
1	 parallel.parallel1.disabled
1	 parallel.parallel2.disabled
1	 parallel.parallel3.disabled
1	 printer.docpath..
1	 printer.dpi.360
1	 printer.height.110
1	 printer.multipage.false
1	 printer.printer.true
1	 printer.printoutput.png
1	 printer.timeout.0
1	 printer.width.85
73	 render.aspect.false
26	 render.aspect.true
1	 render.char9.false
99	 render.frameskip.0
1	 render.linewise.false
1	 render.multiscan.false
1	 render.scaler.hardware2x
2	 render.scaler.none
96	 render.scaler.normal2x
1	 sblaster.dma.0
98	 sblaster.dma.1
1	 sblaster.hardwarebase.220
99	 sblaster.hdma.5
1	 sblaster.irq.10
33	 sblaster.irq.5
65	 sblaster.irq.7
4	 sblaster.mixer.true
4	 sblaster.oplemu.compat
89	 sblaster.oplemu.default
1	 sblaster.oplemu.old
96	 sblaster.oplmode.auto
2	 sblaster.oplmode.opl3
7	 sblaster.oplrate.22050
91	 sblaster.oplrate.44100
99	 sblaster.sbbase.220
94	 sblaster.sbmixer.true
93	 sblaster.sbtype.sb16
6	 sblaster.sbtype.sbpro1
98	 sdl.autolock.true
99	 sdl.fulldouble.false
5	 sdl.fullresolution.
74	 sdl.fullresolution.desktop
20	 sdl.fullresolution.original
99	 sdl.fullscreen.true
70	 sdl.mapperfile.mapper-0.74-2.map
16	 sdl.mapperfile.mapper-0.74.map
1	 sdl.mapperfile.mapper-SVN.map
2	 sdl.mapperfile.mapper.map
10	 sdl.mapperfile.mapper.txt
1	 sdl.output.OpenGL
5	 sdl.output.ddraw
1	 sdl.output.direct3d
5	 sdl.output.opengl
84	 sdl.output.overlay
3	 sdl.output.surface
1	 sdl.overscan.0
1	 sdl.pixelshader.none
98	 sdl.priority.higher,normal
95	 sdl.sensitivity.100
3	 sdl.sensitivity.500
98	 sdl.usescancodes.true
98	 sdl.waitonerror.true
99	 sdl.windowresolution.original
1	 serial.serial1.disabled
97	 serial.serial1.dummy
97	 serial.serial2.dummy
1	 serial.serial2.nullmodem port:23
98	 serial.serial3.disabled
98	 serial.serial4.disabled
1	 speaker.disney.false
97	 speaker.disney.true
9	 speaker.pcrate.22050
89	 speaker.pcrate.44100
98	 speaker.pcspeaker.true
98	 speaker.tandy.auto
9	 speaker.tandyrate.22050
89	 speaker.tandyrate.44100
1	 vsync.vsyncmode.off
1	 vsync.vsyncrate.75

I did this just to get a quick look at how many configs really change between all the GOG Games. As I suspected, we find a wide variety of cpu section settings. We had 2 that turned off EMS memory, and a few that changed the memsize. Quite a few twists in the joystick section, and a few other oddities here and there. So just by looking at this, I changed my program to take some additional overrides.

So, the little local snippet of code I wrote looks at my DOSBOX-X main config and each GOG’s DOSBOX config and compares the following, taking the GOG config and overriding just for that game.

While HOMM worked just fine without taking [cpu] settings, the next game I tried was Alone in the Dark, and with default DOSBox-X settings, it slowed to a crawl. Turns out GOG had tweaked their primary Alone in the Dark DOSBOX-0.74 config:

core -> simple
cputype -> pentium_slow
cycles -> 11000
cycleup -> 1000
cycledown -> 1000

This is why [cpu] is one of the sections I take from GOG’s curated game-specific configuration.

Game specific tweaks I had to make

Here’s the log of games I installed and any interesting tweaks I had to make to convert them to use my DOSBox-X install.

The post Retro Gaming PC Build Log Part 3 : PC Games with GOG appeared first on Krystof.IO.

Figured I’d start off with my favorite system – The Commodore 64. Here are the key software components I used:

Nibconv and .NIB disks

I have some disk images that are already the D64 or G64 type, and some that are .NIB. I need to convert those using the nibconv from the Nib Tools package first. A simple batch file that worked for me (drop it in the folder where you have nibconv.exe and .NIB files and it will handle the rest. It deletes the G64 file first since mine would lock if the file already existed.

for %%f in (*.nib) do (
	del "%%~nf.g64"
	nibconv "%%~nf.nib" "%%~nf.g64"
)
pause

VICE install

VICE doesn’t install – it just unpacks into a directory. I put mine in a common emulators folder D:\Emulators\SDL2VICE-3.6.1-win64. Underneath there are all sorts of binaries and such but the primary one is x64sc, and that’s what I’ll be configuring as I test out some games.

First LaunchBox import and adding VICE as an emulator

I put my Bruce Lee G64 file in a temporary directory just to try this out. I’m going to let LaunchBox manage the Commodore 64 ROM files necessary, so it will ‘move it’ into the LaunchBox Games directory on import:

Now here is where I may deviate from most. I like the idea of RetroArch, and perhaps I’ll revisit it in the future, but I found while I can create global configurations to be shared across multiple emulators, I really liked having features in the later versions of emulators that don’t have an updated RetroArch core, or the core has crippled some features I desire. So in general, I rarely use RetroArch at this time.

For starters, all I’m populating is the name (VICE 64) and the location to x64sc.exe (The VICE C64 binary)

I let it populate all the checkboxes for both LaunchBox and EMU Movies.

I leave these options as default:

After searching the online databases for media, I now show Bruce Lee in my LaunchBox main view:

Testing the first game – Failure and Fix

Double clicking on Bruce Lee does… nothing. I see nothing. I got nothing. What gives?

I decide to launch the emulator directly (x64sc.exe in the VICE directory) and it worked fine:

I then decided to load the G64 image directly through VICE, bypassing LaunchBox. Result:

Okay. So now I now there’s something up with LaunchBox dealing with VICE. I’m actually used to loading VICE first on my RetroPie and loading the image directly. So this means I’ve got a command line argument issue. Turns out LaunchBox tried to force my hand with RetroArch even though I wanted to configure the emulator manually!

Perhaps I should have set the emulator up first, but if you run into this, you’ll see in your emulator config under ‘associated platforms’ a WIDE list of items, and they also populate well known RetroArch cores.

I missed the little ‘pop up’ that stated it populated RetroArch for me. I wish it hadn’t done that, it caused me a small headache. So I went back into my VICE config and wiped out ALL of the associated platforms, left that tab, went back to an empty one (so it doesn’t show the RetroArch core column), and added one entry for Commodore 64 like so:

After that, VICE finally launched from LaunchBox properly:

Configuring VICE on Windows

Great, now we know we can launch at least one game from LaunchBox using VICE. Now I need to configure it to my tastes. First off, it’s a tiny window in the center of the screen, and not full screen. There are plenty of other things I like to configure for VICE, and here is where I’ll record those ‘default’ settings I immediately set into the VICE configuration when I first install VICE. I may tweak this over time but the settings below are my current reference settings of choice.

First off, VICE by default is storing it’s settings in C:\Users\<userid>\AppData\Roaming\vice. Underneath there is a sdl-vice.ini after saving the first time and vice.log for any interesting execution log statements. Good to know.

Side note: Try out wireless gamepads for the PC (Like XBOX controllers). Luna loves chewing cables.

Here are the highlights for my VICE 3.61 Windows SDL version’s settings that deviate from the known defaults.

• SDL audio instead of WMM – Things sounded horrendous otherwise.
• NTSC Mode vs Pal- I had NTSC, but sometimes images I have require PAL. So I set up both
• I set the VICE snapshots directory to the Snapshots directory I created underneath my C64 LaunchBox game folder for easier visibility.
• I set the drive sound emulation to 1. It’s just music to my ears.
• Joystick – I set by default, Joystick 2 to my game controller (a generic gamepad), and Joystick 1 to the numeric keypad. VICE by default sets my A button to Joystick firing, B button to bring up the VICE menu. I manually set the Y button to toggle WARP speed on and off, and the X button to ‘swap’ the Joystick ports. I also set the left trigger to the ‘Load snapshot’ menu, and the right trigger to ‘Save snapshot’ menu.

What I ended up doing was creating two emulator profiles – one for NTSC and one for PAL. The two config files allow me to tweak the two ‘versions’ of C64 emulation differently, and sometimes I just need to do that for some games.

VICE 64 – NTSC setup example (points to NTSC config)

VICE 64 PAL – PAL setup example (points to PAL config)

Current reference settings:

sdl-vice-ntsc.ini:

[C64SC]
SDLStatusbar=1
SoundDeviceName="sdl"
VirtualDevice1=1
MachineVideoStandard=2
IECReset=1
CIA1Model=0
CIA2Model=0
KernalRev=-1
VICIIFullscreen=1
VICIIModel=3
SidModel=0
JoyPort10Device=0
JoyPort9Device=0
JoyPort8Device=0
JoyPort7Device=0
JoyPort6Device=0
JoyPort5Device=0
JoyPort4Device=0
JoyPort3Device=0
JoyDevice1=4
EventSnapshotDir="D:\LaunchBox\Games\Commodore 64\Snapshots\"
GlueLogic=0
DriveSoundEmulation=1

sdl-vice-pal.ini:

[C64SC]
SDLStatusbar=1
SoundDeviceName="sdl"
VirtualDevice1=1
IECReset=1
CIA1Model=0
CIA2Model=0
KernalRev=-1
VICIIFullscreen=1
VICIIModel=0
SidModel=0
JoyPort10Device=0
JoyPort9Device=0
JoyPort8Device=0
JoyPort7Device=0
JoyPort6Device=0
JoyPort5Device=0
JoyPort4Device=0
JoyPort3Device=0
JoyDevice1=4
EventSnapshotDir="D:\LaunchBox\Games\Commodore 64\Snapshots\"
GlueLogic=0
DriveSoundEmulation=1

LaunchBox specific settings:

Command line parameters:

• -chdir “D:\LaunchBox\Games\Commodore 64” (Sets the autostart image directory to our games folder)

Game Specific Settings

Game specific tweaks and oddities

The post Retro Gaming PC Build Log Part 2 : Commodore 64 appeared first on Krystof.IO.

The Goal

It seems when I’m able to come anywhere near close to dusting off some retro gaming work, I boot up whatever RetroPie or Windows based system I’ve set up for some retro gaming years back and can’t for the life of me remember how I set things up from either a taxonomy standpoint, controller setup, emulator configurations, and more. I’m using these build logs to document my thought processes at the time and ‘Figure it out’.

The Hardware

Now, I’m not a retro gaming purist. I’m at best retro gaming purist adjacent. This means I love playing games on the older hardware, but with limited space, I can’t set up all the things. I can set up some retro systems here and there, but I can’t set up everything in one big retro corner. I’ve taken up enough corners in this house with my hobbies. In fact, I’m fresh out of corners. So, I’m going to emulate quite a bit, whether it’s Stella for the Atari 2600 or DOSBOX for Ultima Underworld. I very much enjoy playing games on the original hardware when I can – but when it comes to easily streaming live content or looking up videos and articles about the game, it is very much easier to do it on a PC running emulation software. Plus, I get to compare how the emulators compare to the real deal at my leisure.

Most of the time you don’t need a fancy machine to emulate old retro games – look at RetroPie for example. You can emulate a metric crap ton of games on a Raspberry Pi. The machine I chose is a bit beefier than I would need, but that’s because it’s available to me. Why not a Pi? I have a lot of DOS and Windows games as part of my ‘Bucket List‘ which rules out the Pi right quick – the Pi is great for certain computer and console emulation, but starts to have some issues in retro libraries of later eras (like Windows 9X games). Plus, some of those may require some video acceleration – and for that I’ve an NVIDIA card to take care of the heavy lifting. It’s not for the latest and greatest, but it will do for the oldest and greatest just fine.

It’s a 2018 ASUS GR8 II-6GT024Z VR Ready Mini PC Gaming Desktop with Intel Core i7-7700 and GeForce GTX 1060 6G Video Card. All things considered it’s a powerhouse when it comes to what I need for retro gaming, even if it’s not available for purchase anymore and won’t be supported by Windows 11.

Here are the basic specs:

Processor	‎4.2 GHz core_i7
RAM	‎16 GB DDR4
Hard Drive	‎1 TB SSD
Graphics Coprocessor	‎NVIDIA GeForce GTX 1060
Chipset Brand	‎NVIDIA
Card Description	‎Dedicated
Graphics Card Ram Size	‎6 GB
Wireless Type	‎802.11ab
Number of USB 3.0 Ports	‎4

So, while I type this, I’m performing that fresh Windows 10 install to start from scratch and begin the documentation process. While we wait for that, let’s talk about the primary front end I’ll be using.

Don’t forget to pack your LaunchBox

I’ve tried a few front ends over the years, and most of the time they’re targeting specific emulating systems (MAME for example, has plenty of front ends, but that’s assuming you’re primarily dealing with MAME things). I really adored HyperSpin in the mid 2010s, but I haven’t checked it out lately. I think I’ll still use HyperSpin for a dedicated MAME cabinet (Project Pedestal), but I’m not considering it for this round.

I played around with LaunchBox quite a few years ago when it was in the early years, and I’ve been enjoying seeing the updates and enhancements (like BigBox) since then. With the inherent support for multiple platforms and the capability for me to examine the datafiles (they’re stored in XML files inside the LaunchBox directory) easily, I can use LaunchBox to store configurations for the various games and I can also export that data to my ‘Bucket List‘ database, and from there I can auto populate my Twitch stream with box art, game metadata, and my personal high scores and playtime.

I also wanted to be able to have some custom data points, which LaunchBox supports. For example:

• Series Index – I use a field I call Series Index to indicate what order I should play a game when it’s part of a series. Sometimes the titles aren’t an indicator (looking at you, GoldBox RPGs), and while I could use release date, I liked having a dedicated data-point.
• Port Indicator – I don’t do this for all the games, but for some where I want to try out different versions, like say ‘BurgerTime’ on Atari 2600, Intellivision, Commodore 64, etc. – I use this to link together individual game/platform combinations together.

LaunchBox also has created a database to pull a lot of metadata down for recognized games, along with EmuMovies integration for video and additional art. We can also pull down manuals, which is a big help so I don’t have to find the ASCII text files or open my game boxes up needlessly.

So, I head over to the LaunchBox site, purchased a lifetime license, and went to work on the install. You can of course install the free version, but I purchased it a looooong time ago, so I’m going to use my permanent license.

I’m leaving some hard drive space for the OS, but most of my stuff will be installed on a D: drive so I can keep some parts separated from the main OS. We’ll see how well that works – ideally nothing should FORCE me to stay on the C: drive but you never know. Personal preference, really – I could do all this on C: if I really wanted to.

After launching LaunchBox, I attached my GOG profile and my EmuMovies account subscription for future game and metadata downloads.

That’s it for this round. Next chapters will probably be platform specific as I set up emulators and related utilities.

The post Retro Gaming PC Build Log Part 1 : Host PC and Front End appeared first on Krystof.IO.