PCem v9

PCem v9

From the main page:

PCem v9 released. Changes from v8.1 :

  • New machines – IBM PCjr
  • New graphics cards – Diamond Stealth 3D 2000 (S3 ViRGE/325), S3 ViRGE/DX
  • New sound cards – Innovation SSI-2001 (using ReSID-FP)
  • CPU fixes – Windows NT now works, OS/2 2.0+ works better
  • Fixed issue with port 3DA when in blanking, DOS 6.2/V now works
  • Re-written PIT emulation
  • IRQs 8-15 now handled correctly, Civilization no longer hangs
  • Fixed vertical axis on Amstrad mouse
  • Serial fixes – fixes mouse issues on Win 3.x and OS/2
  • New Windows keyboard code – should work better with international keyboards
  • Changes to keyboard emulation – should fix stuck keys
  • Some CD-ROM fixes
  • Joystick emulation
  • Preliminary Linux port

Thanks to HalfMinute, SA1988 and Battler for contributions towards this release.

Very excellent!

22 thoughts on “PCem

  1. In my implementation, the ne2000 is complete and emulable on PCem, but I need some help regarding the bridgding between the host network and the guest network with winpcap. With DHCP enabled on win95 inside PCem gets an address of

  2. will you help me out for this networking project on PCem, I can put an updated version of my project (now uses slirp, but I don’t know how to implement it, too complex at least for me).

    • In your pcap_open you have an extra parameter from the pcap open I know about.
      This is what I have:
      char *device, int snaplen,int promisc, int to_ms, char *errbuf)

      which is passing a NULL to the error buff… Also you have 65535 for the packet length, maybe try 1516 nothing that runs on PCem will do jumbo frames.

      You should also check if you are blocking or not, as you could be passing empty frames into the NE2000

      I dont know why my attempt to integrate the patch failed but this is from a quick observation.

  3. well, the the extra parameter is about the auth (the NULL one), which, in the winpcap function website, can be set to NULL if it’s not a remote capture.

  4. damn, now there’s a bigger problem in my implementation of the ne2000 and networking in general, it’s about coding a handler for the poll and buffers for the ne2000 (practice present in the sound one, though)

    • Mutexes and queues are the way I solved that.

      As you read your packet stuff it into a queue. Don’t process it, as that takes time.

      Then when the NE2000 checks for packets dequeue and pass them up.

      Remember to set a filter, or you’ll pass reflecting packets and stuff destined for the host.

  5. Found the issue, but I don’t know how to fix it.
    The issue is about TX Transmit events which is missing from my ne2000 implementation, but on dosbox-x it relies on PIC_AddEvent, which is too dosbox specific to be ported

  6. Tom did a awesome job on doing PCem v9.

    The only problem that irks me is that when I try to run DesqView/X, PCem v9 automatically reboots itself. I’m wondering if updating to QEMM97 does the trick. 🙂

    I’m glad that SA1988 got the networking implemented in PCem v9; however, it doesn’t appear to be working too well and needs a lot a work.

    I sure hope that networking is implemented and workable in PCem v10! 🙂

    • well, my only issue with the ne2000 is a configurable mac address, for now, a fixed one hardcoded into the source code is there.
      And my latest github release can bring PCem to the Internet
      (For information purposes, the ne2000 code I have done in my branch is from dosbox with some additions from qemu)

      • Good for you! Qemu already has SLiRP networking which was then ported to Bochs.

        I’m wondering if there is a way to port Qemu SLIRP networking to PCem. If it is possible, it might not be too easy thing to do.

        By the way, updating to QEMM97 didn’t fix the auto-reboot issue in PCem v9 as it did in PCem v8.1.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.