Feature request: revamping config files

Support and general discussion.
Zup
Posts: 83
Joined: Mon 30 Nov, 2015 10:47 am

Feature request: revamping config files

Post by Zup »

PCem has some lists with machine types, CPU types and so on. When new releases come, items in those lists change their order so old config can be no longer valid.

In some cases (machine type has changed) they may work. On other cases (CPU type is invalid), PCem will stuck on a grey screen or crash without warnings. So there are some features to cope with those errors:

- Validate config file before trying to run. If some item is invalid, put some error message (i.e.: CPU type not valid).
- After a configuration error is encountered, could PCem window remain opened (but not running the emulated PC) so the offending item could be changed?
- Use aliases in some items (i.e.: model = revenge, cpu = 386DX@20). If aliases are used, it wouldn't matter if machine list is changed (and as a side effect, cfg files would be more readable).

I don't know if this is documented elsewhere, but if a config file is selected (pcem --config pc200.cfg), changes to configuration are saved back to pcem.cfg. I guess it would be better that changes are saved back to selected config file.

Thanks.
User avatar
leilei
Posts: 1039
Joined: Fri 25 Apr, 2014 4:47 pm

Re: Feature request: revamping config files

Post by leilei »

Models, sound cards and video cards could be strings yes. I've had old configs produce crashing PCems due to new model additions (like having an Advanced/EV cfg before and after MR386DX were added had me adjust the config's numbers manually)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

IMHO, the best solution would be to redo the model ENUM's - ie. group them according to types. You could have PC and PC clones, starting at value 0, PCjr, Tandy, and other only partially compatibles starting at value 20, XT and XT clones starting at value 40, AT and other 286 machines starting at value 60, PS/1's starting at value 80, PS/2's starting at value 100, 386SX machines starting at vlaue 120, 386DX machines starting at value 140, and so on, so adding a machine to a specific category would not affect any existing ID's, while there would still be some order. C allows you to specific the value of any specific entry in an ENUM (and the following entries increase from that one), so that's easily doable.
Heck, it would make best sense to make the ten thousands stand for machine type (PC, XT, 286, etc.), thousands for BIOS type (Award, AMI, etc.), and hundreds for chipset (430VX, ALi, etc.), then you can have up to 100 machines for each combination of type, BIOS type, and chipset.

The same could be done with the graphics cards, sound cards, etc., though for those, maybe ordering by manufacturer would make more sense.
This would also improve the readability of the configuration files, since the numerical ID's would have some logic behind them.

Also, fatals could easily be made to issue a Message Box on Windows only (and possibly an equivalent on Linux), so the user knows what's going on. And yes, I agree that configuration-related errors should send the user to the settings window, rather than fataling the emulator.
robertsig
Posts: 10
Joined: Thu 09 Jun, 2016 1:30 pm

Re: Feature request: revamping config files

Post by robertsig »

YES! The config file architecture is very annoying. Everything defaults to pcem.cfg when saving. I've had to resort to making multiple copies of the whole folder with all extraneous rom/bios files just to accommodate different emulated PC's.

Another thing I notice is if I put in a relative path to the HDD file and save the config, it changes it to the full path. Makes moving the folder a pain, and I keep having to change it back.
Zup
Posts: 83
Joined: Mon 30 Nov, 2015 10:47 am

Re: Feature request: revamping config files

Post by Zup »

robertsig wrote:YES! The config file architecture is very annoying. Everything defaults to pcem.cfg when saving. I've had to resort to making multiple copies of the whole folder with all extraneous rom/bios files just to accommodate different emulated PC's.
Although the default saving is to pcem.cfg (and the default loading too), you can still run pcem --config pc200.cfg. There's no need to make multiple copies of pcem, altough I have a folder that holds every HDD and some boot disks on subfolders. Just remember to keep the HDD geometry at hand (I usually put it on the file name) in case you need to recreate a config file (or use that HDD with another configuration).
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

- Zup: You can run PCem like that but it will still save the changes to pcem.cfg.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

robertsig wrote:YES! The config file architecture is very annoying. Everything defaults to pcem.cfg when saving. I've had to resort to making multiple copies of the whole folder with all extraneous rom/bios files just to accommodate different emulated PC's.
Well the intention was that you'd save different configs for each emulated machine, and just load each one when you wanted to use it, and not alter the configuration all the time. I take it that this isn't how people are actually using it?
Another thing I notice is if I put in a relative path to the HDD file and save the config, it changes it to the full path. Makes moving the folder a pain, and I keep having to change it back.
Is moving the PCem folder something you do a lot? Seems like a bit of an odd use case.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

For models / sound cards / video cards / CPUs, storing the full name as text in the config seems like a sensible way to go. Extending the current enum system seems a bit odd to me - ideally the numbers shouldn't matter at all, as it would be an internal detail only that wouldn't be exposed anywhere.

I'm also thinking of re-ordering the machine list; it's currently intended to be roughly in order of increasing performance, but it's ended up as a complete mess. My current thoughts are of separating machines based on CPU/socket, then ordering alphabetically within each class.
robertsig
Posts: 10
Joined: Thu 09 Jun, 2016 1:30 pm

Re: Feature request: revamping config files

Post by robertsig »

SarahWalker wrote:
robertsig wrote:YES! The config file architecture is very annoying. Everything defaults to pcem.cfg when saving. I've had to resort to making multiple copies of the whole folder with all extraneous rom/bios files just to accommodate different emulated PC's.
Well the intention was that you'd save different configs for each emulated machine, and just load each one when you wanted to use it, and not alter the configuration all the time. I take it that this isn't how people are actually using it?
Another thing I notice is if I put in a relative path to the HDD file and save the config, it changes it to the full path. Makes moving the folder a pain, and I keep having to change it back.
Is moving the PCem folder something you do a lot? Seems like a bit of an odd use case.
1) I do fiddle with PCem constantly when I am using it, yes.

2) Not a lot, but I also don't see why refreshing the config when I save it would change that. It would just be nice... ;)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

SarahWalker wrote:For models / sound cards / video cards / CPUs, storing the full name as text in the config seems like a sensible way to go. Extending the current enum system seems a bit odd to me - ideally the numbers shouldn't matter at all, as it would be an internal detail only that wouldn't be exposed anywhere.
But using logically structed numbers would bloat the code far less than storing and reading strings. You'd require either a long chain of strcmp's or a function to find a given string in an array, to handle all the models. Using restructured numeric ID's would be far more efficient, especially if the logic behind the ID's is documented.

This is my draft proposal: http://pastebin.com/kpxwgLGp .
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

You only need a function to find model number from string on config load, and lookup string from model number on config save. Hardly a big deal, and also has the bonus of making the config files more readable.
Zup
Posts: 83
Joined: Mon 30 Nov, 2015 10:47 am

Re: Feature request: revamping config files

Post by Zup »

I'd use alias instead of full strings. I mean, using "pcxt" (the rom directory) is less prone to errors than "Generic XT clone".

Also, getting the index from an array of strings is not so complex and performance is not a concern (it will be done only at startup).
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

Good idea - that's exactly what I've done; see rev 651.
User avatar
gen_angry
Posts: 127
Joined: Sat 25 Feb, 2017 6:48 am

Re: Feature request: revamping config files

Post by gen_angry »

For the meantime, I've worked around this issue by creating a "RUN ME.bat" file that works anywhere.

Code: Select all

@echo off
e:
cd\pcem
del pcem.cfg

:START
cls
@echo.
@echo   1. Boot 486DX4-100Mhz with MSDOS 6.22
@echo   2. Boot Pentium MMX 233Mhz with Windows 95 OSR2
@echo   3. Boot 286-8Mhz (IBM AT) with MSDOS 3.3
@echo.
choice /M "Choose PC to boot: " /C 123
if errorlevel 3 goto 286
if errorlevel 2 goto P233
if errorlevel 1 goto 486
goto START

:P233
pcem --config P233.cfg
copy pcem.cfg P233.cfg /y
exit

:486
pcem --config 486.cfg
copy pcem.cfg 486.cfg /y
exit

:286
pcem --config 286.cfg
copy pcem.cfg 286.cfg /y
exit
Can just modify to suit your needs until multiple config handling gets released :)
User avatar
gen_angry
Posts: 127
Joined: Sat 25 Feb, 2017 6:48 am

Re: Feature request: revamping config files

Post by gen_angry »

Similarly related question with multi-config: any chance we could have the BIOS saved data stored in separate roms as well?

For example: Im using the 430VX chipset for both a P75 machine and a P233MMX machine. The BIOS settings are "shared" between the two machines, so I can't make any drastic changes to one or the other.

Not sure if this would be possible.
robertsig
Posts: 10
Joined: Thu 09 Jun, 2016 1:30 pm

Re: Feature request: revamping config files

Post by robertsig »

Has a remedy to the multi-config files been pushed to any dev update by chance? That feature would be a life-saver for me. It would allow me to build my different classic PC's without stomping on each other.
User avatar
KingDaveRa
Posts: 22
Joined: Thu 06 Oct, 2016 9:00 pm
Location: UK
Contact:

Re: Feature request: revamping config files

Post by KingDaveRa »

Personally (just IMHO) I'd like something more like how Virtualbox or VMWare Workstation handles it, insomuch as the emulation isn't launched when I run the executable, rather it asks which config to load, then goes from there (or create a new one). A few times I've launched it and not managed to load/reconfigure fast enough and it's started booting into an existing disk image with different config.
ecksemmess
Posts: 183
Joined: Wed 18 Mar, 2015 5:27 am

Re: Feature request: revamping config files

Post by ecksemmess »

Yeah, I've got to say--I've always found it a little odd the way PCem starts booting a machine immediately upon launch. Given that most users will be juggling multiple emulated machines, it would really make a lot more sense to have a config selector come up first as the default behavior. The ability to run a specific config directly via command line switch will ensure that anyone who does want to boot straightaway will still be able to do so, using batch files. This is a change that should be seriously considered, I think.
User avatar
leilei
Posts: 1039
Joined: Fri 25 Apr, 2014 4:47 pm

Re: Feature request: revamping config files

Post by leilei »

ecksemmess wrote: The ability to run a specific config directly via command line switch will ensure that anyone who does want to boot straightaway will still be able to do so, using batch files. This is a change that should be seriously considered, I think.
It's already there. pcem.exe --config C:\emulators\pcem\mycool486.cfg

I don't think a selector window could work, though a virtual power button/switch could
ecksemmess
Posts: 183
Joined: Wed 18 Mar, 2015 5:27 am

Re: Feature request: revamping config files

Post by ecksemmess »

Sorry, I wasn't clear. I know about the --config switch. I was just saying that, because we've got that switch, the proposed change wouldn't prevent people from booting straightaway at launch if that's what they want to do. I don't really see why a selector window or "home screen" of some kind couldn't work. It could list all config files in any given folder, for example, with a user setting for which folder to use for that, double-click any entry to boot. I think that would work quite nicely and be very intuitive. Separately, though, I do like your idea for a "virtual power button". In fact, for a long time now, I've wished there was a "Power on/off" next to "Hard reset" in the menu. If that were to be added, with the power state defaulting to "off" at startup, I suppose the config selector wouldn't be as necessary (though would still be nice to have, of course).
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

I've created a new branch 'new_config' in the mainline repo, with what I understand the desired config behaviour to be - select a config file on startup, all changes go to that file instead of the default pcem.cfg (which no longer exists).

People who have been complaining about this - can you give this a try, and let me know if this is more or less the behaviour you'd like? There are a number of issues as-is - it's Windows only, non-emulation related settings are also stored in each config that should probably be in a central config, there are probably some bugs with switching configs on the fly.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

Wouldn't just fixing what configuration file things are saved into and then making a separate program to manage configuration files and load PCem on demand be a better solution?

Edit: And the best way to do that would be to name the separater program PCem.exe while naming the main executable something like PCem-Core.exe. That way people would run the emulator with the same executable as always, but they'd be dropped in the new configuration manager instead of directly inside the emulator itself, with the only change to the actual emulator's executable being fixing what configuration file settings are saved to.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

I don't see why that would be better...
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

- SarahWalker: You'd need to change far less things in the emulator's main executable, and it would allow for people to make third-party configuration managers of their own as well.
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: Feature request: revamping config files

Post by SarahWalker »

I'd rather just create a config system that works properly and matches how people actually want to use it, than try to just hack something on the top.
User avatar
MeshThe2nd
Posts: 2
Joined: Tue 02 May, 2017 8:02 pm

Re: Feature request: revamping config files

Post by MeshThe2nd »

It seems rather weird to run PC-em edit just a few things, have it load up BIOS, then reset it again after a few simple edits. A power/reset button when you first load up PC-em, would be welcome, so it doesn't load up to BIOS as soon as you run it. Possibly at that window, a drop down list of available configs to chose from?
It's now safe to shut off your computer.
szadycbr
Posts: 295
Joined: Mon 21 Nov, 2016 6:23 pm

Re: Feature request: revamping config files

Post by szadycbr »

The power buton is good idea, i think. Personally it bothers me a litlle when i fidlle around with config and often PCem start to boot, which leaves me no choice than wait and close windows, or reset and risk losing some data , and scandisk will run everytime after reset. Just that, BTW Thank You Sarah, especially for HDD diode and option to switch it off/on, also resizeable window is usefull very much, nice.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: Feature request: revamping config files

Post by Battler »

SarahWalker wrote:I'd rather just create a config system that works properly and matches how people actually want to use it, than try to just hack something on the top.
I thought people want a configuration manager that launches the emulator on demand, which my solution would provide them with? After all, no big product (VIrtualBox, VMWare, Virtual PC, etc.) has the manager and the machine core in the same executable.
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Feature request: revamping config files

Post by waltje »

Bad idea, Sarah. Although often separating the two is a good idea, in this case, with an ever-changing (so, very dynamic) code and feature set, you'd be splitting up knowledge about that into two programs, and that is going to be asking for trouble.
waltje
Posts: 13
Joined: Wed 15 Mar, 2017 10:17 pm
Location: Fort Wayne, IN
Contact:

Re: Feature request: revamping config files

Post by waltje »

Correction: Bad idea, OBattlet, for reasons I just explained to you...

It would be good if the Configurator (which usually is a GUI) 'compiles' the resulting configuration data into a machine-readable optimized data set (binary, structured ASCII text, etc) so that the APplication itself can just blindly read it. App should also write any changes back to that same file. Knowledge about configuration values should be in a single shared piece of code to avoid mishaps as mentioned in my first reply.

The current config file is horrid, a nightmare even, but right now, you're on the right track I think.
Post Reply