[Post edited]

There's also the fact IDE hard disks generally read one sector a time, though PCem emulates multiple reads but still does a fseeko64/fread on every sector rather than on the whole batch, on the other hand, SCSI hard disks generally read entire blocks of sectors at a time, and the way I wrote the SCS...

I might have tested it and gotten that error before I applied the fix of yours that fixed LBA 2, that fix probably fixed DOSIDLE.EXE as well, I need to try it again.

If she sees someone releasing builds she might get pissed off and close the access to the code. Edit: Actually, I was wrong. She can legally close the mercurial repository and only distribute the source of the release builds as she herself does not distribute devlopment binaries of PCem. So you're ...

- SA1988: Sarah and ecksemmess are both right. This is Sarah's site, and therefore, Sarah's rules, so stop pressuring her and bringing up irrelevant points.

And yes, the time would indeed be better spent coding rather than arguing.

That won't help. Sarah is right, IDE uses PIO while the SCSI controller I emulated uses DMA, so there's considerably less waiting for transfers.

It's pretty trivial to dump your own S3 bios to use with PCem anyway. It's what I did. Not everyone can afford an actual S3 card and an actual old machine to dump the BIOS (or an ROM reader device). VIA owns S3's assets and therefore they're still "around". The S3 site's still up even. Wh...

On the emulated Pentium 75, I used Little Big Adventure 2 as reference. With NukedOPL disabled, it runs at solid 100%, while with NukedOPL enabled, it runs at 85-90%. That's a 10-15% difference. And the game doesn't even use any sort of synth music, so the mere attachment of NukedOPL to the guest ma...

Don't worry, PCem is unaffected by video card's performance, it only relies on the CPU That's false. The graphics card can and does affect the PCem. If it does Direct3D 9 badly, then PCem will be slower with that, if it also does DirectDraw badly, then you have no way of running PCem at a decent sp...

Ah, I didn't know that. Then the performance idle emulation needs to be improved, unfortunately that's going to be difficult.

- SarahWalker: No, I'm talking about the slowdown that happens when disk I/O access happens. For example, on Pentium 75, I have Duke Nukem 3D (for DOS) running at solid 100% but when on the loading screen, it goes down to 70% for a while as it's reading from the hard disk. Now if James-F is not talk...

The IDE emulation needs to be moved into its own thread. For me (on a Pentium Dual-Core), hard disk access can make the difference between 100% and 70%. On a better host CPU it's going to be less severe, but still there.

The three required files are attached. I also fixed the SB OPL volume so it uses the correct level (provided by James-F) when using both types of OPL. The nukedopl.* files go to src/dosbox . I also added the ability to not use NukedOPL which will make it fall back to DOSBox OPL3 emulation. NukedOPL ...

SarahWalker wrote:PCem does have a GPU BIOS with VBE 2.0 - the 'ATI Video Xpression (Mach64 VT2)' BIOS supports it.

Then it might be that the Mach64 VT2 BIOS you have is better than the one from VGA Museum which we use.

PCem is still in text mode while it should be in graphics mode. I have no idea why, though.

It's probably a bug in the VBL emulation. It happens with any emulated graphics card. But it's not a black screen, I still see the line mark flickering in the upper left corner.

It crashes when EMM386 is loaded. This also worked fine before the flat segment commit, but now I get the following error: EMM386: Unrecoverable privileged operation error #01 - press ENTER to reboot .

Found the right PCI.EXE, and got all the slot information right. Much better! Thanks. :p

Where can I get this PCI.EXE? It looks like I'd really need it.

- James-F: I told you to get an idle driver for DOS, as the maxing out is due to EMM386 doing things that makes the dynamic recompiler go crazy and idle drivers solve that. Edit: As for the timers, I think I told Sarah in the past that improvements are needed. For one, I noticed that they seem to &q...

- SarahWalker: Make sure though to still allow the user to select DOSBox OPL if they so desire, because at least on my Pentium Dual-Core, NukedOPL makes the emulator on average 10% slower.

- James-F: I will try to make a diff for NukedOPL later today, it should be fairly easy.

I am. And I confirmed above that with the regular 430VX BIOS, I indeed see the writes. However, with other BIOS'es I don't, at all. Maybe some register is returning a value some BIOS'es don't like?

OK, I just tried another BIOS and it works correctly. Howeveer, the fact some BIOS'es do not set those registers still means soemthing is wrong IMHO.

- SarahWalker: I commented out the pclog's, and I don't see anything. What BIOS are you using?

Basically, it never updates the registers so they always stay at 0x80, ie. disabled.

I second omarsis81's request.

Basically, start the game normally, play for a bit, suddenly it will do that and halt the PC. My EMM386 is loaded with parameters I=B000-B7FF I=E000-EFFF NOEMS . This used to work fine and the problems started appearing since that flat segment optimization commit.

- ecksemess: I took the table of colors from VileRancour's DOSBox patch, but the code to make it work on 86Box was mine (I just added these as options to the existing palettized renderer code).

- basic2004: I think SarahWalker moved the reading of the relevent variable from the configuration file elsewhere, but forgot to comment out the code in midi_reset() that reset MIDI out device to 0. Incidentally, I made the exact same mess up in 86Box, and I found and fixed it about an hour ago.

Are you sure you did this right? In your commit, I see you made the code directly put palette indexes into the 32-bit color buffer which I'm not sure is right.