Hi, I found PCEm a few months back -is there a newer release than 8.1 that you're all using; or are you simply compiling from source? I haven't been able to figure out what steps I need to take to compile so I've been waiting for the next release to come out, but it sounds like there's been a lot of changes recently. Are we due yet for another release?
Either way, thanks for making such a great emulator!
wrote:Hi, I found PCEm a few months back -is there a newer release than 8.1 that you're all using; or are you simply compiling from source? I haven't been able to figure out what steps I need to take to compile so I've been waiting for the next release to come out, but it sounds like there's been a lot of changes recently. Are we due yet for another release?
Either way, thanks for making such a great emulator!
best chance is to compile the latest svn source.
wrote:wrote:Hi, I found PCEm a few months back -is there a newer release than 8.1 that you're all using; or are you simply compiling from source? I haven't been able to figure out what steps I need to take to compile so I've been waiting for the next release to come out, but it sounds like there's been a lot of changes recently. Are we due yet for another release?
Either way, thanks for making such a great emulator!
best chance is to compile the latest svn source.
Ok, getting the source is straight-forward enough; I'm not sure about compiling it, however.
I found this through a google search: http://code.google.com/p/pcem-plus/wiki/Compilation
Any opinions on it? Will it give me what I need to compile the svn code?
wrote:Ok, getting the source is straight-forward enough; I'm not sure about compiling it, however. I found this through a google searc […]
wrote:wrote:Hi, I found PCEm a few months back -is there a newer release than 8.1 that you're all using; or are you simply compiling from source? I haven't been able to figure out what steps I need to take to compile so I've been waiting for the next release to come out, but it sounds like there's been a lot of changes recently. Are we due yet for another release?
Either way, thanks for making such a great emulator!
best chance is to compile the latest svn source.
Ok, getting the source is straight-forward enough; I'm not sure about compiling it, however.
I found this through a google search: http://code.google.com/p/pcem-plus/wiki/Compilation
Any opinions on it? Will it give me what I need to compile the svn code?
yes, it will.
There seems to be a memory count bug regarding the AMI 386, AMI 486 and AMI WinBIOS 486.
PCem currently tolerates a limit of 256 MB of memory. However, if you manually edit the pcem.cfg file and change the value to mem_size = 641 or higher, the AMI 386, AMI 486 and AMI WinBIOS 486 ROMs WILL NOT be able to recognise more than 655,296 KB of tested system memory (640 MB - 64 KB) and hang with a blinking cursor below the last good tested memory count.
By manually editing the mem_size past the 256 MB limit, a 386DX or 486 based emulated computer on PCem will be able to tolerate up to 640 MB of memory at a absolute maximum and that is it. Anything higher than 640 MB and the BIOSes that I mentioned will lock up. If you manually edit the amount of memory to 1024 or higher, PCem will crash!
I suspect that this is often the case, because large memory sizes on these old BIOSes were not available at the time when they were released and I don't think that this is fixable. The 640 MB memory count bug might have been fixed in later Pentium MMX-based AMI BIOSes I believe.
Edit: In AMI 386 and AMI 486 bases BIOSes, if you set the mem_size value between 65 to 640, the BIOS will count all of the available tested RAM, but up to 64,512 KB (63 MB) of extended RAM will be usable due to the chipset limitation: http://forums.bannister.org/ubbthreads.php?ub … at&Number=92856
It seems to me that the 64 MB limit in these BIOSes is a BIOS limit in INT 15h FUNC 88h. The 64 MB bug was eliminated in the AMI WinBIOS 486 and up.
I was able to compile PCem and I got it running. If you're searching from google, here's what I did:
1) download the copy of mingw from http://code.google.com/p/pcem-plus/wiki/Compilation,
2) Copy the mingw folder to the root of your c: drive
3) Add c:\mingw\bin;c:\ingw\msys\1.0\bin;c:\mingw\mingw32\bin to your PATH.
4) download source from https://bitbucket.org/pcem_emulator/pcem
5) unpack, change to the src directory.
6) run make -f Makefile.mingw
7) c:\copy PCem.exe ..
😎 Copy alut.dll to program directory.
9) Set up roms as per normal PCem.
10) RUN
Finding a copy of alut.dll was the hardest part for me. It's often included in open source games (I had it included from my copy of the singularity secondlife viewer: singularityviewer.org), so I'd suggest rummaging around your "program files" folder and looking through apps to see if there's a copy there somewhere. I'm on win64 so installing openal didn't seem to work.
scratch that --after rebooting my computer, the compiled version of pcem won't work.
Problem signature: Problem Event Name: APPCRASH Application Name: PCem.exe Application Version: 0.0.0.0 Application Time […]
Problem signature:
Problem Event Name: APPCRASH
Application Name: PCem.exe
Application Version: 0.0.0.0
Application Timestamp: 5356d1d8
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.18247
Fault Module Timestamp: 521ea8e7
Exception Code: c0000005
Exception Offset: 00038e19
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
the ALut.dll I have is version 5.10.2914.0, from NVIDIA 2000-2002 ....
No idea bout the crash, you'd have to run it under gdb, if that mingw has a gdb.
Also:
c:\ingw\msys\1.0\bin
doesn't look right, c:\mingw.....??
wrote:the ALut.dll I have is version 5.10.2914.0, from NVIDIA 2000-2002 .... […]
the ALut.dll I have is version 5.10.2914.0, from NVIDIA 2000-2002 ....
No idea bout the crash, you'd have to run it under gdb, if that mingw has a gdb.
Also:
c:\ingw\msys\1.0\bindoesn't look right, c:\mingw.....??
I cut and pasted that from a post upthread -it had "Ming" in the paths and I deleted them and switched them with "ming" -apparently I forgot to re-add the "m" on that part of the path. I'm not sure it's going to make a lot of difference.
The ming package does include gdb, but I'd have no idea what on earth I'm looking for ("./configure&& make && make install" is the extent of my programming knowledge).
EDIT: also I took a quick stab at compiling this in linux, it puked looking for windows.h, which tells me figuring out Linux <--> Windows functions calls would be a pain in the ass (and would be beyond my skill set).
C:\Users\rliegh\Documents\src\PCem-4c95696c27d6>gdb pcem GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. L […]
C:\Users\rliegh\Documents\src\PCem-4c95696c27d6>gdb pcem
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\pcem.exe..
.done.
(gdb) run
Starting program: C:\Users\rliegh\Documents\src\PCem-4c95696c27d6/pcem.exe
[New Thread 1252.0xb38]
warning: FTH: (1252): *** Fault tolerant heap shim applied to current process. T
his is usually due to previous crashes. ***[New Thread 1252.0xa58]
[New Thread 1252.0x910]
[New Thread 1252.0x184]
[New Thread 1252.0x9f4]
[New Thread 1252.0xa14]
[New Thread 1252.0x12c]
[New Thread 1252.0x3b4]
[New Thread 1252.0xad8]
[New Thread 1252.0x968]
[New Thread 1252.0x418]
[New Thread 1252.0x4f0]
[New Thread 1252.0x368]
[New Thread 1252.0x730]Program received signal SIGSEGV, Segmentation fault.
0x77a58e19 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
(gdb) k
Kill the program being debugged? (y or n) y
(gdb)
🤷
when it crashes in gdb do a
bt
for backtrace, it'll show the order of what was calling what.
wrote:when it crashes in gdb do a
bt
for backtrace, it'll show the order of what was calling what.
a quick question, are you able to fix PCem to have ntvdm compatibility? the emulator currently lacks it when running NT (from 3.1 to 2000) as a guest.
i haven't installed NT in pcem... so no.
hmm, I have noticed that opcode 0xc4 (opLES) (about NTVDM, according to one MESS member) is only in 386_ops.h but not in the x86_ops_*.h ones.
I'm mostly playing with bochs in Linux today, but I booted windows, ran backtrace on the binary I compiled and here's the output:
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. […]
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.C:\Users\rliegh>cd Documents\src\PCem-4c95696c27d6
C:\Users\rliegh\Documents\src\PCem-4c95696c27d6>gdb pcem.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\PCem.exe..
.done.
(gdb) run
Starting program: C:\Users\rliegh\Documents\src\PCem-4c95696c27d6/PCem.exe
[New Thread 220.0x86c]
warning: FTH: (220): *** Fault tolerant heap shim applied to current process. Th
is is usually due to previous crashes. ***[New Thread 220.0x878]
[New Thread 220.0x93c]
[New Thread 220.0x94c]
[New Thread 220.0x8e8]
[New Thread 220.0x95c]
[New Thread 220.0x954]
[New Thread 220.0x96c]
[New Thread 220.0x9dc]
[New Thread 220.0x9e0]
[New Thread 220.0x9e4]
[New Thread 220.0x9f8]
[New Thread 220.0xa20]
[New Thread 220.0x9f0]
[New Thread 220.0xa38]
[New Thread 220.0x990]
[New Thread 220.0xa64]Program received signal SIGSEGV, Segmentation fault.
0x77138e19 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x77138e19 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
#1 0x77138d28 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
#2 0x69b47952 in SuspendContext ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#3 0x69b43419 in alGetError ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#4 0x004972a6 in inital ()
#5 0x00000000 in ?? ()
(gdb) bt
#0 0x77138e19 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
#1 0x77138d28 in ntdll!RtlIntegerToUnicodeString ()
from C:\Windows\system32\ntdll.dll
#2 0x69b47952 in SuspendContext ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#3 0x69b43419 in alGetError ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#4 0x004972a6 in inital ()
#5 0x00000000 in ?? ()
(gdb)
It looks like it's choking on OpenAL32.dll? I have no idea how I can fix that.
wrote:hmm, I have noticed that opcode 0xc4 (opLES) (about NTVDM, according to one MESS member) is only in 386_ops.h but not in the x86_ops_*.h ones.
http://www.ragestorm.net/blogs/?p=145
wow interesting!
wrote:#3 0x69b43419 in alGetError () from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll #4 0x004972a6 in inital () […]
#3 0x69b43419 in alGetError ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#4 0x004972a6 in inital ()
#5 0x00000000 in ?? ()
(gdb)
It looks like it's choking on OpenAL32.dll? I have no idea how I can fix that.[/quote]
compile without sound...? is that even possible?
when you rebooted something about your sound setup changed... muted? I don't know but openal is mad.
wrote:wrote:#3 0x69b43419 in alGetError () from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll #4 0x004972a6 in inital () […]
#3 0x69b43419 in alGetError ()
from C:\Users\rliegh\Documents\src\PCem-4c95696c27d6\OpenAL32.dll
#4 0x004972a6 in inital ()
#5 0x00000000 in ?? ()
(gdb)
It looks like it's choking on OpenAL32.dll? I have no idea how I can fix that.compile without sound...? is that even possible?
when you rebooted something about your sound setup changed... muted? I don't know but openal is mad.
I know it's not muted, because I can hear other sound apps (games, etc). Also the 8.1 binary starts and runs just fine.
Thanks for taking a look and giving me feedback, tho -I appreciate it! 😀
I have enabled the v86 logs on x86seg.c and this happens when opening a Win16 or DOS program on NT 3.1 (also on later releases, like 3.5, 3.51, 4.0 and 2000):
V86 IRET to 0070 9BEA 0000 0000
That looks normal.
