Zup wrote:

Did you change / reinstalled your OS? It seems like your config files can not be written (permissions?).

Last I checked, PCem stored its settings in a cfg file in the program's root directory, so it shouldn't be that.

gerwin wrote:

Is that problem present with all the chipsets selectable from within PC em, or just the 430VX again?

I don't even think my build has 430VX support. I'm just using the latest binary, with the AMI 486 Winbios. When I start it up, make a fresh hard drive image, and load a bootable floppy image, it'll work fine, but after the first reboot it'll refuse to boot from the floppy or the hard disk. It'll just give a message like "no rom basic detected, system halted", as if it can't find an operating system on any of the mounted disks. Switching the machine to "Generic AMI 486" doesn't help either.

oh. OH. That was a bug regarding paths. It's been fixed already

Basically the bug was if you load a floppy image from a different folder from the hard drive, it'll suddenly try to write the hard drive at the path you mounted the floppy from. like say if you had your floppy loaded from

C:\MY\REALLY\COOL\DISKETES!\Windows95BetaBootDisk!!!.ima

and your hard drive is here

D:\EMULADORES\PERSONNEL_COMPUTER'S\pcem\hdc.img

it will then erroneously read/write

C:\MY\REALLY\COOL\DISKETES!\hdc.img

leileilol wrote:

oh. OH. That was a bug regarding paths. It's been fixed already […]
Show full quote

oh. OH. That was a bug regarding paths. It's been fixed already

Basically the bug was if you load a floppy image from a different folder from the hard drive, it'll suddenly try to write the hard drive at the path you mounted the floppy from. like say if you had your floppy loaded from

C:\MY\REALLY\COOL\DISKETES!\Windows95BetaBootDisk!!!.ima

and your hard drive is here

D:\EMULADORES\PERSONNEL_COMPUTER'S\pcem\hdc.img

it will then erroneously read/write

C:\MY\REALLY\COOL\DISKETES!\hdc.img

I see. And here I was thinking that keeping my floppy images separate from my hard disk images was a good idea. 🤣
I really should figure out how to compile the latest version. 😜

leileilol wrote:

oh. OH. That was a bug regarding paths. It's been fixed already

No fix, as there isn't a bug here - PCem only supports absolute paths for hard drive images. Relative paths will cause this problem, but this only happens if you're hand editing the config file.

It'll just give a message like "no rom basic detected, system halted", as if it can't find an operating system on any of the mounted disks.

What's the bootup sequence set to in the BIOS? I think it may default to "C:, A:" in which case on a partitioned but not formatted drive it will attempt to boot up from the unformatted C: and produce that messa

oh. I never changed hard drive paths and carried my pcem cfg over many versions.

infact for every different computer I just use different PCEM folders and run the emulator by a batch file that syncs from the latest compile over to it since there's no individual cfg/profiles yet. like a pcem folder for a certain 386, a pcem folder for a certain 486, etc... a -conf parameter could help this 😀

SarahWalker wrote:

No fix, as there isn't a bug here - PCem only supports absolute paths for hard drive images. Relative paths will cause this prob […]
Show full quote

leileilol wrote:

oh. OH. That was a bug regarding paths. It's been fixed already

No fix, as there isn't a bug here - PCem only supports absolute paths for hard drive images. Relative paths will cause this problem, but this only happens if you're hand editing the config file.

It'll just give a message like "no rom basic detected, system halted", as if it can't find an operating system on any of the mounted disks.

What's the bootup sequence set to in the BIOS? I think it may default to "C:, A:" in which case on a partitioned but not formatted drive it will attempt to boot up from the unformatted C: and produce that messa

I forgot that it defaulted to "C:, A:" in the BIOS. 🤣 That's kind of suboptimal for a DOS machine if you ask me.

Haven't posted here in a while.

I've been running a lot of software mostly under the AMI WinBIOS 486 and Award SiS 496/497 drivers and most of the software works well.

With PCem v9 through r289, QEMM didn't work properly with the emulator due to the REP 32-bit instructions not working correctly. It got fixed in r290 and I'm waiting for an update.

If you have DESQview/X, could you install it in PCem v9 r290 to see if it works or not?

Update: DESQview/X finally works in r291 and higher now! 😁

Oh and by the way...do we have any emulation for Phoenix 80286, 80386 and 80486 ROM BIOSes to use under PCem?

Thanks.

The Amstrad MegaPC is a Phoenix 80386 IIRC, not generic though.

leileilol wrote:

The Amstrad MegaPC is a Phoenix 80386 IIRC, not generic though.

Thanks for telling me. However, the MegaPC is only configured to a 80386 SX processor at 25 MHz speed. And on page 14, roytan1 mentioned the generic version of the Phoneix 80386 ROM BIOS PLUS as the user played around with other BIOSes that do not fully work under PCem. I bet that it would be difficult to dump the ROM from a old computer with a Phoenix BIOS and implement them for use under PCem.

Update: r307 includes support for the Phoenix 80386 clone now. 😀 The machine is not 100% perfect and it will hang if you try to use user defined type 48 or type 49 hard disks in the CMOS setup. nerd73 is trying to work on the Phoenix 80486 emulation. However, there are bugs that will eventually need to be ironed out.

Has anyone here messed around with PCem-X? It seems to be based on one of the newer builds, and while it has a nice feature set, it runs like a dog on my system when I have it set to emulate a 430VX chipset, with Win95 running on it. It appears to use some sort of a dynamic core, but I'm not certain. Any suggestions?

If anyone else wants to try it, it requires WinPCap to work.

mr_bigmouth_502 wrote:

Has anyone here messed around with PCem-X? It seems to be based on one of the newer builds, and while it has a nice feature set, it runs like a dog on my system when I have it set to emulate a 430VX chipset, with Win95 running on it. It appears to use some sort of a dynamic core, but I'm not certain. Any suggestions?

If anyone else wants to try it, it requires WinPCap to work.

Although PCem-X has been updated through GitHub, it hasn't been updated via release since early January of this year. Also, PCem-FX, which includes shader support hasn't been updated since r72. 🙁

The good news is that Neozeed has implemented preliminary SLiRP and Pcap networking though it will not officially make it in PCem v10. So far, I got internet access using the Arachne web browser on the AMI WinBIOS 486 machine and using internet browsers on the Award SiS 496/497 machine running Windows NT 3.51. 😀

Right now, OS/2 Warp 3 does not work at all with PCem, with preliminary networking support, PCem quits unexpectedly when attempting to install the operating system. Even with no networking support, OS/2 Warp 3 bombs on the first installation disk! I became aware of this issue when attempting to install Warp 3 on the Intel Premiere PCI (75 MHz Pentium) machine.

mr_bigmouth_502 wrote:

Any suggestions?

Just stick to the official PCem tree. September is hardening bugfixing month so trying and reporting on the head there is important. The other fork there is more "you wont take my duplicate effort of floppy reading code? Fine ill make my own pcem with blackjack and hookers" motivated

leileilol wrote:

mr_bigmouth_502 wrote:

Any suggestions?

Just stick to the official PCem tree. September is hardening bugfixing month so trying and reporting on the head there is important. The other fork there is more "you wont take my duplicate effort of floppy reading code? Fine ill make my own pcem with blackjack and hookers" motivated

🤣...I'm with you on this one. Right now, OS/2 Warp 3 operating system emulation is being fixed and some progress has been made so far. One good bugfixing example is that we're reporting erratic behaviour when trying to load or include anything within the UMB segment address B000-B7FF in the CONFIG.SYS file.

It's obvious that there will be no new features added until after the official release of PCem v10 sometime next month. Trying to add new features may only complicate and hinder development efforts.

leileilol wrote:

mr_bigmouth_502 wrote:

Any suggestions?

Just stick to the official PCem tree. September is hardening bugfixing month so trying and reporting on the head there is important. The other fork there is more "you wont take my duplicate effort of floppy reading code? Fine ill make my own pcem with blackjack and hookers" motivated

Dumb question, but how would one build the latest version on Windows? I'm assuming MinGW would be one of the requirements.

Grab some MinGW w/ GCC, grab some dx9 headers (allegro's site is a good place to snag without going whole hog on an SDK download), and grab some OpenAL headers. Extract them to include/. When that's all said and done, make some batch file that set paths to the mingw's bin folder, runs mingw32-make on makefile.mingw and then a pcem.exe is grown!

There's not much Windows/DOS gaming being tested evidently, just niche OS/2 allocation issues that only 2 people will be affected by. so more testing and bugfinding would be grand

leileilol wrote:

mr_bigmouth_502 wrote:

Any suggestions?

Just stick to the official PCem tree. September is hardening bugfixing month so trying and reporting on the head there is important. The other fork there is more "you wont take my duplicate effort of floppy reading code? Fine ill make my own pcem with blackjack and hookers" motivated

Actually, PCem-X's FDC code is really a lot better than vanilla PCem. PCem-X also has a lot of other rewritten code, either to fix bugs, or to add features. Plus, there's also the issue of Sarah sometimes completely mangling code she adds from elsewhere, such as the PCjr sound chip basically being a complete and utter mess.

We're also working on more accurate 386 emulation in general, since I've already added limit checks to all memory accesses in one branch. I have already made sure that Windows 98 SE works on it, so that's a start. Battler has also made Pentium emulation more accurate, by GPFing on invalid MSR accesses, just like a real processor.

- leileilol: Can I ask what's your problem? Have you even tried PCem-X, and I mean a recent compile to which I can quite gladly provide a link, not an old release from January or February? Because you sure like spreading misinformation about it around.
First, my FDC code is for the most part better because it's based on countless sleepless nights spent reading datasheets and other sources of information. It also has full 3-mode floppy support for the chipsets that support that feature, as well as other goodies. And yes, it lacks PCem's support for copy-protected floppies, but that's in the works. Sure you may not care about whatever PCem-X's FDC code does that PCem's doesn't, but that doesn't give you the right to demean my work.
Second, there is a lot more things in PCem-X that lack in PCem. There's a whole load of more chipsets emulated, there's the basic Pentium Pro and Pentium II emulation alongside the 440FX chipset, including all i686-specific CPU instructions, there's ongoing improvements to IDE/ATAPI emulations, there's the networking which now also has SLiRP as a possibility, SA1988 is working on emulation of SCSI CD-ROM drives and hard disks, and Alegend45 is working on Riva128 and Cirrus Logic Laguna3D graphics card emulation. And for the future, there's in plans to add in the emulation of Japanese PC-compatibles such as the IBM PS/55 as well as AX machines, as soon as documentation and BIOS'es become available.
It seems to me, leileilol, that you seem to be a fanboy of Sarah's PCem and refuse to tolerate anyone disagree with you or Sarah the slightest. You've been going around attacking me and my emulator in multiple places, here, PCem forum, Reddit... and you even have a tendency of posting snide remark about anything you don't care about. Getting OS/2 to run? You don't care about it, so people shouldn't bother with it. Pre-release software? You don't care about them, so any request to make them possible to run (which simply requires the ability to set back the BIOS date/time, something PCem-X also allows, unlike PCem) should be dismissed. Someone makes a PCem patch that adds something you don't care about? You call it stillborn and berate me for giving it a chance PCem-X.
Just who on earth do you think you are? Do you really think you're the end all and be all of PC interests and that only things *YOU* care about have the right to be focused on and only software *YOU* happen to be a fan of is allowed to be developed? Well, I hate to break it to you, but you're not. If you have constructive criticism of PCem-X, you're welcome to post it, and I'll gladly listen. But please stop your continuous attacks on my work and assumptions that I know nothing and pull things out of my rear end (like you insist on saying about my optimization flags, for example, despite me continuously telling you they are a result of *TESTING*). Good? Good. Now let's stop fighting.

🙄 No comment.......

but I can mention I did report a bunch of video related bugs which got dealt with

🤣

This isn't Battler from the MagicBall Network by any chance, is it?

Alegend45 wrote:

Plus, there's also the issue of Sarah sometimes completely mangling code she adds from elsewhere, such as the PCjr sound chip basically being a complete and utter mess.

That's really quite offensive.