Hi all, I've just released version 0.97 on the website (no changes since beta5). Thanks for all the feedback!
Recently I've been trying to emulated the IBM Music Feature Card, a music synth that Sierra intended to use on its games before settling for the Roland MT-32. I thought the only DOSBox build that could emulate it was Scali's, but it seems DOSBox Staging is emulating it too on its last betas.
With this in mind, I think an IMFC option should be added to the Audio - Experimental settings.
EDIT: This seems to be the relevant section from the DOSBox.conf file:
[imfc] # imfc: Enable the IBM Music Feature Card (disabled by default). # imfc_base: The IO base address of the IBM Mus […]
[imfc]
# imfc: Enable the IBM Music Feature Card (disabled by default).
# imfc_base: The IO base address of the IBM Music Feature Card (2A20 by default).
# Valores posibles: 2a20, 2a30.
# imfc_irq: The IRQ number of the IBM Music Feature Card (3 by default).
# Valores posibles: 2, 3, 4, 5, 6, 7.
# imfc_filter: Filter for the IBM Music Feature Card output:
# on: Filter the output.
# off: Don't filter the output (default).
# <custom>: Custom filter definition; see 'sb_filter' for details.imfc = false
imfc_base = 2a20
imfc_irq = 3
imfc_filter = off
Sure thing, added in 0.98 beta1!
Cool! Thank you!
(And let's hope they don't change that CONF section anytime soon)
I have tried to do my own research on this, but I am left with a couple questions and comments:
Thanks for any help you can provide. It seems like you have a solid base product, and I hope my feedback can help close the gap between your intentions and execution, as well. This space is hurting for quality, flexible, straightforward to use offerings, and with a little refinement, it looks like DGBL could be king.
Since DOSBox builds started creating their own DOSBox.conf files in Users\<Username>\Appdata things have gotten a bit confusing.
Personally, I prefer to create a full DOSBox.conf in the folder of every DOSBox build, and DBGL doesn't seem to have ny problems with that.
To do that, run every DOSBox.exe (or DOSBox-X, or whatever) and enter config -wcp from the DOSBox prompt.
The ARM version doesn't seem to work on MacOS Ventura 13.3. I tried to trash the settings file, the database, no success.
JollyWizard wrote on 2023-04-08, 16:29:Where is the proper place to discuss this software for development? Support? Here? The site seems to indicate we should just email the dev?
Here at Vogons is just fine, and so are DMs or email.
JollyWizard wrote on 2023-04-08, 16:29:Are there any source repos available? Like an actual repo with push/pull and versioning, not a code package `zip`.
I have been using a private git repo since 2006. Everything you need in order to contribute to DBGL, is in the zip. The website has archives of all source code and a changelog since DBGL version 0.2 .
JollyWizard wrote on 2023-04-08, 16:29:Are there any instructions for setting up DosBox-Staging and DosBox-X?
Not specifically. Only the official DOSBox releases are supported by DBGL, I simply cannot support each and every fork, especially since they seem to be in a state of flux, usually. Having said that, using them in DBGL should not be any different from the official DOSBox version; just add them in the DOSBox version list, and associate them to your profile(s).
JollyWizard wrote on 2023-04-08, 16:29:I can only get staging to boot, and both complain about the lack of proper .conf files. For X, it just says it hates the file and wants to correct it. Scared to do this, because that's the only DB I have that I can manage as a single app with a GUI.
Sorry, don't know what's up with that. Will have a look.
JollyWizard wrote on 2023-04-08, 16:29:For Staging, my current install provides no conf file. I tried to pick a txt file to overwrite; it loads but never stops complaining on boot. So I specify a non-existent file and it never creates it, and loads the game, but error dialogs every single time.
If these conf files can be generated in any way, or even ignored, then why are they a mandatory entry in the profile config?
Also, why doesn't the system indicate it is aware of the usage patterns of altBoxes, if the altBoxes are supported.
Eh, I'm having trouble understanding your comments.
JollyWizard wrote on 2023-04-08, 16:29:The version specification is only in terms of classic DB versions. There is no family specification.
Correct, only the official DOSBox versions are supported. There is no such thing as a DB 'family' AFAIK.
DBGL will use a DOSBox version's default configuration file to determine its 'capabilities'. Such a .conf file can usually be created by starting said DOSBox version and executing the command config -writeconf 'dosbox.conf'.
Then, whenever you associate a DBGL profile with this DOSBox version, DBGL will inspect the dosbox.conf to see if certain [section]-items are defined. If so, DBGL will consider the feature available and make them configurable in the interface.
DBGL will use incremental config files by default. What this means, is that your game profiles (and templates) only store the differences compared to the main dosbox.conf file, resulting in smaller and simpler .conf files. Another advantage is that it will allow you to make manual changes in dobox.conf that will affect all profiles using that DOSBox version.
Please note that dosbox.conf is never manipulated in any way by DBGL, but DBGL does provide a button for launching a text-editor so you can manually edit the file. Changing the dosbox.conf settings is generally not recommended since its defaults are wisely chosen. But system-specific settings - such as the output setting - may be changed from the default if that works better for a particular videodriver/platform combination.
Upon running the profile, DOSBox is started with dosbox.conf as its 'base' settings file, together with [ID].conf containing overrides and autoexec commands to run the game, like so:
DOSBox-0.74-3\DOSBox.exe -conf DOSBox-0.74-3\dosbox.conf -conf profiles\15.conf
JollyWizard wrote on 2023-04-08, 16:29:Clearly the dosbox-x.conf is incompatible in some way? It seems there is some hackiness to make this work, but I can't find instructions.
I don't see why that would be the case. Maybe there has been a recent regression, that is always possible. But I think there are some (mostly Windows) DBGL users using the DB forks, so it would be surprising if these don't work in DBGL.
JollyWizard wrote on 2023-04-08, 16:29:Are there any other online instructions / resource hubs? The provided learning resources on the website are skimp, and did not help with my altBox setups.
The `learn more` link on the web page is deceptive, because it only jumps you a couple pixels to the site brochure, which doesn't actually include a lot of learning resources.
Mostly everything is in this Vogons thread, or on the website. There is nothing deceptive about the 'learn more' link, it's called single-page-design, and I've tried to keep the information brief. But if you think essential information is missing on the website, I'll gladly add it.
JollyWizard wrote on 2023-04-08, 16:29:Thanks for any help you can provide. It seems like you have a solid base product, and I hope my feedback can help close the gap between your intentions and execution, as well. This space is hurting for quality, flexible, straightforward to use offerings, and with a little refinement, it looks like DGBL could be king.
Thanks,
Ronald
mr_space wrote on 2023-04-10, 21:44:The ARM version doesn't seem to work on MacOS Ventura 13.3. I tried to trash the settings file, the database, no success.
Sorry to hear that mr_space, unfortunately I do not have access to an actual ARM Mac for testing, as it stands. I thought some Vogons user reported an earlier ARM version to be working though. Can you maybe try to run the dbgl startup script in a terminal to see if you get a crash stacktrace?
rcblanke wrote on 2023-04-11, 17:53:mr_space wrote on 2023-04-10, 21:44:The ARM version doesn't seem to work on MacOS Ventura 13.3. I tried to trash the settings file, the database, no success.
Sorry to hear that mr_space, unfortunately I do not have access to an actual ARM Mac for testing, as it stands. I thought some Vogons user reported an earlier ARM version to be working though. Can you maybe try to run the dbgl startup script in a terminal to see if you get a crash stacktrace?
I indeed found nothing that could help in the console history.
I'll try, anyway, I mostly use Dominus Applescript to launch the conf files, I use DBGL for installs ans testing, thanks for your hard work!
So, I did what you asked:
no swt in java.library.path: /Users/nemo/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
Can't load library: /Users/nemo/.swt/lib/macosx/x86_64/libswt-cocoa-4956r13.jnilib
Can't load library: /Users/nemo/.swt/lib/macosx/x86_64/libswt-cocoa.jnilib
Can't load library: /Users/nemo/.swt/lib/macosx/x86_64/libswt.jnilib
Can't load library: /Users/nemo/.swt/lib/macosx/x86_64/libswt-cocoa-4956r13.jnilib
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:346)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:255)
at org.eclipse.swt.internal.C.<clinit>(C.java:19)
at org.eclipse.swt.widgets.Display.<clinit>(Display.java:110)
at org.dbgl.gui.Launcher.main(Launcher.java:51)
Java is installed but no in my User Library, in the HD one, sorry, I'm French!
Strange, DBGL seems to be trying to load the x64 (intel/amd) SWT version. Please make sure you're using https://dbgl.org/download/dbgl097-x86.dmg when using an Intel-based Mac, and https://dbgl.org/download/dbgl097-arm.dmg when using an M1 or M2-based Mac!
Please try removing the existing '.swt' directory in your home folder '/Users/nemo'; DBGL should re-create it on initial startup with the correct files based on your platform.
I try to us the ARM version on my Mini M2, strange indeed! 😀
Edit, it's working now, I had an old X86 version on java installed, I use Dosbox-Staging so a lot of options are missing, thanks anyway!
Hello!
I have a couple of questions/sugestions about DBGL. I've been using the software for some time and it works great, but now I'm making a clean up of unwanted games and would be great that DBGL would have the option to enable the deletion of the game folder in dosroot when the profile is deleted, I don't know if this has been requested before but I think it would be useful.
Another thing I'm going to do is to add all my DBGL games to my existent retro collection in Launchbox, I've searched but couldn't find in the documentation any mention to command line usage, correct me if I'm wrong but now the only method would be to use the "create shortcut" option and import the created shortcuts in Launchbox isn't it?
Hi jophran,
Not being able to delete actual game files using DBGL has been a specific design-choice on my part, because it can be unclear what files exactly should then be removed. Some DOS(Box) games store files in multiple directories, or even in the C root folder. Also, some games can be run from within a disk or CD image, with additional game files somewhere on the C drive. And some games come with additional documentation files, for example. I decided it is probably best to have the end-user decide which files should be removed, manually.
Hmm, good question about Launchbox. I must say I haven't looked at Launchbox for ages and I do not know what features it has to import DOS games. Importing DBGL desktop shortcuts might work, I don't know. I will have a look at Launchbox soon-ish to see what might work.
Regards,
Ronald
Hi,
had anybody success with adding dosbox-x on MacOS to DBGL 0.97? Just can't add it to DBGL, with regular dosbox 0.74 it's working perfectly. But as dosbox-x is running natively on my M2 Mac Mini now and has some other advantages i really would love to be able to use it with DBGL as well.
Kind regards
Jan
janosch wrote on 2023-04-16, 18:52:Hi, […]
Hi,
had anybody success with adding dosbox-x on MacOS to DBGL 0.97? Just can't add it to DBGL, with regular dosbox 0.74 it's working perfectly. But as dosbox-x is running natively on my M2 Mac Mini now and has some other advantages i really would love to be able to use it with DBGL as well.
Kind regards
Jan
It's not my default but it runs fine in DBGL here on an Intel Mac Mini. I only use it to occasionally boot into Windows 3.1 or 98 to attempt to play something there. Only issue I have with it is it loads any machine below VGA with a blue background and the 'ugly' CGA palette heh. Change the machine to sVGA or anything above EGA and it works fine. Can't figure that one out yet, otherwise works fine. The palette thing isn't a DBGL issue though, it does that when I run it on its own too.
Monotremata wrote on 2023-04-22, 04:43:It's not my default but it runs fine in DBGL here on an Intel Mac Mini. I only use it to occasionally boot into Windows 3.1 or 98 to attempt to play something there. Only issue I have with it is it loads any machine below VGA with a blue background and the 'ugly' CGA palette heh. Change the machine to sVGA or anything above EGA and it works fine. Can't figure that one out yet, otherwise works fine. The palette thing isn't a DBGL issue though, it does that when I run it on its own too.
How did you add it to the Dosbox Versions availble in DBGL? And which version of DBGL are you using?
janosch wrote on 2023-04-23, 09:04:How did you add it to the Dosbox Versions availble in DBGL? And which version of DBGL are you using?
There's a button right at the top of the screen to 'Add Version'. Its been in every DBGL release I can ever think of.
Thanks, should have been more specific. 😉 Of course I found that button, but when adding Dosbox-X through this button I got a magnitude of errors about "no executable found", "no dosbox.conf" found, "invalid path" and so on.
I tried again yesterday and after fiddling around for a while I got It solved and pointed alle required paths to a location/file inside the dosbox-x bundle.
Thanks a lot for letting me know that it does work, otherwise I probably would just have give up! 😀
