Excellent work, EluanCM! This is great to see, and something I've been looking forward to ever since you first brought up your interest in it many months ago. Thanks for sticking with it. Hopefully Sarah will commit this patch after she returns from her much-deserved break...

Very, very cool to see work being done on this. Thanks for tackling it, leilei.

Does this same commit improve the issue of the recompiler choking at the Windows desktop, DOS prompt, etc.? Can't compile the latest version to check at the moment, but I'm curious. If so, that's a huge step forward!

Thanks Sarah, great to finally have this sorted!

Count me as yet another who would love to see this! I really do hope that at least some level of basic 8087/287/387 support gets onto the to-do list for v14. Also, does anyone know if the FWAIT issue Scali mentioned above has ever been fixed?

What a nice surprise, thanks for this!

Are you saying that the number entered is being treated as MB despite being labeled KB? For example, in your screenshot, would PCem improperly attempt to give the system 512 MB of RAM instead of the expected 512 KB? Or are you just saying you find it strange that the AMI 386SX asks for a RAM amount ...

omarsis81 wrote:Is this a 386 SX?
Be careful! 386 SX models count memory as KB in the configuration dialog where it should be in MB

Not familiar with this issue but this sounds important, can you elaborate on where the problem is?

Thanks, that does help.

Sort of related: I've struggled quite a bit with the 50 message limit for the PM Inbox and Sent folders. I know it's trivial to save copies of the messages for long-term storage, but I still find it a lot more helpful to be able to access old messages within the forum itself. Would it be possible to...

Even if it's just caused by a poorly patched ISO, isn't it still a bad sign that PCem itself is crashing/fataling? The failure should be contained within the emulated system, so there's still something amiss to troubleshoot here, right?

I'd think that the UI should certainly make it very obvious to the user which settings will be applied globally and which will be applied per-machine. Lots of potential for confusion there.

Thanks, ender! That's exactly the kind of explanation I was looking for.

Looks good.

The render thread count is per-card, so you can have 4 render threads in total (plus 2 FIFO threads). So you will need at least a Core i7 to run it flat out. If you just want the resolution though, setting 1 render thread per card is often fast enough on quad core systems. I'm a bit confused by the...

That last uncommitted patch is the one that fixed the major problem that killed non-Software-renderer performance for iwasaperson across the board on all emulated machines, right? Seems like something that will have to be re-incorporated somehow, possibly with a setting to allow the user to choose b...

Sounds about right. Something like that would be great to have in mainline PCem.

This is great to see! Thanks to Sarah, neozeed, and everyone else who's worked on this.

Quick question: can someone very briefly summarize the relative advantages and disadvantages of slirp vs. pcap in the specific context of how they've been implemented here?

leilei wrote:Works here.

Nice-looking screenshot, leilei. What shader settings are those? Have you applied anything other than the curvature?

If the Olivetti GO481 only came in a 256K version, then it's not unreasonable to expect the user to know that or look it up. The fact that the PVGA1A itself supported 512K and 1M boards doesn't really seem relevant here. In any case, if we were to decide that it's worth making the memory size explic...

The amount of memory is surely 256K B , not 256K b (32KB), right? I know it's a minor detail, but I can see some potential for user confusion here, so it should probably be corrected. And for that matter, isn't it a bit inconsistent to be listing the memory amount right in the displayed name of the ...

SarahWalker wrote:I should probably add a 'Card Default' option, similar to the waitstate controls, with a VERY rough estimate of performance, but I haven't done that yet.

Yeah, this is kind of what I was getting at. I'm very much in favor of this.

Something I've always wondered about: why is the video speed user-selectable? Won't there always be a single most sensible value for that setting for any given board choice and machine configuration? As such, wouldn't it make more sense for PCem to simply work out which video speed setting is approp...

Excellent work! I like the structural changes to the timing tables as well.

basic2004: the tweaks shown in your latest post definitely look better to me--good work! :) However, I should warn you that I'm not enough of an expert to be able to tell whether it still needs more tweaking or not. VileRancour is much more knowledgeable about this stuff than probably anyone else yo...

Great work, basic2004! Should the amber really be as red as that, though? My recollection, which is seemingly consistent with what I can see in screenshots and on YouTube, is a bit different from the palette you've chosen--I'd say every shade on the amber should be moved a few notches closer to yell...

Apologies if I'm missing something obvious here, but why is the IBM ESDI Fixed Disk Controller marked "is_mfm" for PCem's purposes, while the Western Digital WD1007V-SE1 ESDI controller is not? Is this related to what was mentioned a bit upthread about the IBM controller being limited to t...

If I'm not mistaken, it looks like this last patch that fixes the OS/2 Warp 4.0 installer was committed at rev 787?

That's actually not a half bad idea--in the config, we could have fields where the user enters the horizontal and vertical dimensions of their host system's screen in inches, and PCem could then use that to calculate the window dimensions in pixels that would correspond to various standard classic m...

This looks great! Thanks again for all your work on this Sarah, we've really come a long way.