SarahWalker wrote:I wouldn't spend time on anything to do with the 8-bit blitting code, it's going away soon.

Well, I guess eventually this could be modified to be done on a per-card level, though that would introduce code duplication.

1. I cannot get the "iso" button on my danish keyboard to work, it does nothing at all(this was also an issue with the earlier build, but not the Windows build). I wasn't sure whether it is actually called iso, but that is the only term I know to describe it. On this grid view of an iso k...

Shouldn't the config parser do sanity checks, and either auto-correct values to valid ones or show a message box and then terminate the emulator? It would certainly be better than a potential crash.

- Katakis: She was asking that question to me, asking me why I haven't reported any of those bugs on this forum. :p

- SarahWalker: The OS/2 bug was reported here on this forum two years ago, you said it affects all accelerated cards (which is wrong - we tested the Virge and its drivers do not glitch OS/2) and that was it, and I suspect the Apple Rhapsody font glitches are related to this bug. The NT 3.51 bug I wa...

The whole long list of Trio64 bugs/glitches I just mentioned, affects not only the Number Nine and Phoenix Trio64 emulation, but also the Phoenix Trio32 emulation and the Paradise Bahamas 64 (S3 Vision864) emulation, which is no surprise since all of them use the same emulation core, which is Sarah's.

The 9FX Vision driver might be using blitter features that are not implemented. It's by far not the only thing that doesn't work right - OS/2 has graphics glitches, Windows NT 3.51 caused the video BIOS(!) to be written to the VRAM when I ALT+ENTER the console from window to full screen mode so long...

Based on my tests, the SVGA return changes of 0xFF to 0x00 are not needed, I have tested with them back at 0xFF, but the rest of the patch still applied, and the bug is still gone.

You can use the official version, the Phoenix S3 Trio64 was added, along side the Trio32, per a patch from me, in late 2014. :p

- basic2004: PCem uses OpenAL for audio, which on Windows runs on top of DirectSound.

- Katakis: You can find the BIOS for the Phoenix S3 Trio64 easily by Googling. :p

But in any case, the 9FX Vision emulation is not really complete from what I know as it seems to differ in ways from a stock Trio64.

The emulator should still automatically create the directories it needs (nvr and config) in case they're not present.

Known bug with the SiS 496/497 BIOS used by PCem, which is revision 1, as well as a few other Award BIOS'es. For some reason, it expects a 720k drive to be 40-track instead of the correct 80. For the SiS 496/497, revision 3 of the BIOS fixes the problem.

You're right. :p Well I just opened a bug report thread about that. I should have done that back then already.

It's an add-on for CopyIIpc (a floppy disk copier) that allows you to copy floppy disks to images (in its own special format) and back. It works on PCE and real hardware (808x to 386/33) and PCE but not PCem. According to this article on Trixter's website , it relies on the correct operation of the ...

- SarahWalker: I reported it to you on IRC last year and you said you'd look into it. But if needed, I'll create a thread too.

It says Fatal error, MSCDEX corrupted, with this in the log:

Can't load from CRx

I think CRx support is needed.

- basic2004: If you could PM me the specific CUE/BIN you're having problems with, and how to reproduce the problem, I'll try it.

- bit: My fixes might fix that actually, though I'm still awaiting response from another user who reported a similar problem to see if they do.

Lotus 1-2-3 v4.0 for DOS hangs on splash screen, but this happens with all models and CPUs in PCEM, I tried a copy of the same virtual hard disk in Virtualbox and there runs OK... Yeah the CPU emulation is far from perfect. There's also another issue that affects all emulated CPU's from 808x to 386...

- bit: At least in Windows 95 OSR 2.x, I still can't read the mounted ISO's. Edit: You're writing, into the TOC, the data track and a seemingly failed second track (attr 0x00), but not a lead out track (attr 0x16). Edit #2: This is how to fix the ISO's: 1. In image_get_last_block(), change: address ...

- bit: I got a report from a Korean site that data tracks after the first one are not loaded correctly from CUE/BIN, please look into what happens.

- SarahWalker: I certainly am. :p

Doesn't early OS/2 use 286 protected mode? That would make it a good candidate for testing.

What chipset does the System 200 use anyway? PCem uses the generic at_init() for it, but that may or may not be correct.

You don't need to. Just look under image information in WinImage. In fact, we can safely assume it's two sides and with 512-byte sectors, so all we need to know is sectors per track and the image's size in bytes, then the rest can be calculated.

I actually agree with removing or at least commenting out the Dell System 200.

- ppgrainbow: I wouldn't be surprised if it was caused by Win32s, as that's known to be an unstable mess.

- ppgrainbow: It's a bug with the specific Trident card. Why not try the Phoenix S3 Trio64 (which incidentally, also had a VLB version) and see if the same corruption happens.

That means nothing. I am quite sure a VLB version of the TGUI9440 existed. The card is just poorly emulated right now. It is quite unclear to me how you made the logic jump from "the bug occurs on a specific card only" to "the bug occurs because the card is not compatible with ISA-onl...

- ppgrainbow: More like I suspect that graphics card's (Trident TGUI 9440) BIOS is messing things up, it might be a video BIOS bug as well. Or, alternately, something in that card's code is writing out of bounds and causing other parts of the emulator to get trashed. That card is definitely not PCI-...