PCem

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.

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)

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.

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.

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).

- Zup: You can run PCem like that but it will still save the changes to pcem.cfg.

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.

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.

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...

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 .

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.

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).

Good idea - that's exactly what I've done; see rev 651.

For the meantime, I've worked around this issue by creating a "RUN ME.bat" file that works anywhere.
Can just modify to suit your needs until multiple config handling gets released

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.

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.

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.

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.

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

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).

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.

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.

I don't see why that would be better...

- 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.

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.

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?

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.

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.

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.

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.