TR Forums

http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

This would be of rather minor importance - it's only going to affect 16-bit processes running in V86 mode on a 32-bit OS (or memory manager, JemmEx for FreeDOS being the cited one) - if it weren't for the fact that XP and Server 2003 execute the video BIOS in that manner. Still fairly minor - nobody's running either of those OSes on the Ryzen metal - but could be annoying for someone who needs to run one of them in a VM.

My guess as to how AMD's going to fix it? If they can't fix it properly in microcode, just disable the VME bit in the CPUID. There's only one OS where that presents a problem, Windows 2000, where it assumes VME anyway, and VIA's solution (when they were shipping silicon that didn't support VME) was to distribute a patched NTVDM with the driver package.

Well with the massive cash-rich giants like Intel and Microsoft both refusing to support old OSes, I doubt AMD will have the resources or incentive to burden their new product with obsolete 16-bit legacy software support.

I suspect the solution for 16-bit software is soon going to be emulation rather than running anything natively, and I'd hope Microsoft would step up to that plate. If they don't, perhaps VMware or someone else will.

bhtooefr wrote:

http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

This would be of rather minor importance - it's only going to affect 16-bit processes running in V86 mode on a 32-bit OS (or memory manager, JemmEx for FreeDOS being the cited one) - if it weren't for the fact that XP and Server 2003 execute the video BIOS in that manner. Still fairly minor - nobody's running either of those OSes on the Ryzen metal - but could be annoying for someone who needs to run one of them in a VM.

My guess as to how AMD's going to fix it? If they can't fix it properly in microcode, just disable the VME bit in the CPUID. There's only one OS where that presents a problem, Windows 2000, where it assumes VME anyway, and VIA's solution (when they were shipping silicon that didn't support VME) was to distribute a patched NTVDM with the driver package.

Blech. Looks like I might keep my FX-8320e box around for vintage virtualization needs after all.

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

wingless wrote:

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

At this point sourcing the real hardware's just too much of a hassle. And I say this as someone who's got a 6 MB Canopus Pure3D sitting in his parts bin.

Concupiscence wrote:

wingless wrote:

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

At this point sourcing the real hardware's just too much of a hassle. And I say this as someone who's got a 6 MB Canopus Pure3D sitting in his parts bin.

Just ask Starfalcon?

Flying Fox wrote:

Concupiscence wrote:

wingless wrote:

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

At this point sourcing the real hardware's just too much of a hassle. And I say this as someone who's got a 6 MB Canopus Pure3D sitting in his parts bin.

Just ask Starfalcon?

...hmm.

I mean, I think DOSbox and a virtual machine will probably suit my needs better - and god knows if performance is a consideration, even my FX-8320e will stomp a native-era hardware solution flat - but there's something fun about a 486 running in 2017. Though I appreciate the heads up, I think I'll politely decline.

Chrispy_ wrote:

I doubt AMD will have the resources or incentive to burden their new product with obsolete 16-bit legacy software support.

But it's officially part of x86. My guess is that they'll fix it in a future core stepping.

wingless wrote:

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

Kinda weak for 98SE, no?

Concupiscence wrote:

And I say this as someone who's got a 6 MB Canopus Pure3D sitting in his parts bin.

Call it plainly. Voodoo 1!

Chrispy_ wrote:

Well with the massive cash-rich giants like Intel and Microsoft both refusing to support old OSes, I doubt AMD will have the resources or incentive to burden their new product with obsolete 16-bit legacy software support.

I suspect the solution for 16-bit software is soon going to be emulation rather than running anything natively, and I'd hope Microsoft would step up to that plate. If they don't, perhaps VMware or someone else will.

Although AMD's actually been pitching legacy support as a big advantage of their embedded platform as of late.

Of the x86 vendors selling anything reasonably modern (and by "reasonably modern", I mean at least Pentium Pro class - and this list consists of Intel, AMD, and VIA), AMD is the only one that supports ISA DMA, as one example.

And, it doesn't just affect running 16-bit userland on a 32-bit OS, it also affects booting XP and Server 2003, both natively and in virtualization. (Yes, I know, you shouldn't be running XP in 2017, but a lot of people still do. And, when Zen makes it down to the G-Series SKUs, that'll be a big issue.)

Like I said, the best bet may well be to simply disable the VME flag - it only breaks Windows 2000, and embedded applications that need NT 5 almost always work on XP or Server 2003. Every other known OS that uses VME has an alternate codepath, as far as I'm aware, for running 16-bit software.

Ryzen may be "x86 compatible" but both AMD and Intel have culled older OSes from their support list, Vista was the first OS that ditched V86 mode entirely and Ryzen is officially a Windows10-only product.

Like you say, a simple microcode change would stop it from happening. Whether AMD are even going to bother is another matter. I mean who would buy a multicore 64-bit processor to run a 32-bit OS emulating 16-bit via VM?!

Chrispy_ wrote:

Ryzen may be "x86 compatible" but both AMD and Intel have culled older OSes from their support list, Vista was the first OS that ditched V86 mode entirely and Ryzen is officially a Windows10-only product.

Like you say, a simple microcode change would stop it from happening. Whether AMD are even going to bother is another matter. I mean who would buy a multicore 64-bit processor to run a 32-bit OS emulating 16-bit via VM?!

So this "issue" is overblown then?

Chrispy_ wrote:

Ryzen is officially a Windows10-only product.

Where did AMD say that?

Chrispy_ wrote:

Ryzen may be "x86 compatible" but both AMD and Intel have culled older OSes from their support list, Vista was the first OS that ditched V86 mode entirely and Ryzen is officially a Windows10-only product.

Actually, XP x64 and Server 2003 x64 did that before Vista. And, 32-bit versions of Vista, 7, 8, 8.1, and 10 (all builds) still have NTVDM and use V86 mode, and I've got NTVDM installed on my one 32-bit Windows 10 device.

Chrispy_ wrote:

Like you say, a simple microcode change would stop it from happening. Whether AMD are even going to bother is another matter. I mean who would buy a multicore 64-bit processor to run a 32-bit OS emulating 16-bit via VM?!

While I don't think the current Ryzen SKUs will be used to run 32-bit Windows natively - they're aimed pretty firmly at enthusiasts that would be running 64-bit Windows anyway - I could easily see it being done with lower-end SKUs, or future embedded SKUs. However, I could also see 32-bit Windows being run in a VM, and that's where you could run into trouble pretty quickly - both for running 16-bit software in that VM (the niche application), and for booting 32-bit XP and Server 2003 (which use VME if it's available for executing the 16-bit video BIOS during boot).

That problem of booting XP or Server 2003 in a VM is really the biggest problem with this - actually running 16-bit user code from within a 32-bit OS (native or guest) isn't that likely in 2017 in most applications of a Ryzen system. But, a quick and dirty fix for both of those cases would be as trivial as modifying CPUID to not advertise VME - even if you take a 10% performance hit, for 16-bit code on Ryzen, you're probably still I/O bound.

As an aside, the author of the original article has suggested that it may be possible to do a proper fix in microcode, as well.

bhtooefr wrote:

Actually, XP x64 and Server 2003 x64 did that before Vista

Good point. I'd forgotten about XP64 and it's server equivalent, just because they were too early and people who tried them quickly discovered that all kinds of important hardware drivers hadn't been written yet. By the time enough common 64-bit drivers were ready for mainstream consumer use, Vista already had a bad rep and Microsoft were hastily polishing W7 to try and right their wrong

meerkt wrote:

Chrispy_ wrote:

Ryzen is officially a Windows10-only product.

Where did AMD say that?

I don't know if this is still the case, but I remember reading about this a lot....

Contradictions from AMD.

On one hand, this may suggest support (though I guess what's actually installed could vary based on the OS):

AMD Chipset Drivers 192 MB 17.10 4/28/2017

Description:
Supports Windows 10/8.1/7 (32 & 64-bit)

Package Includes:
AMD Chipset Drivers
AMD Ryzen™ Balanced Power Plan

On the other hand, here an AMD guy says it's "exclusively designed for Win10" (so no Win8 either?):
https://community.amd.com/community/gam ... -available

AMD Ryzen has chipset driver support for Windows 7, 8, 8.1 and 10. There are articles describing how to get it installed on all of these OS's. The problem is Microsoft is only officially supporting it and Intel Kaby Lake on Windows 10. So you might get short-changed on some updates if you use the older OS.

That's AMD's full chipset driver package, though, for all platforms. That doesn't say anything for what Ryzen supports.

And, Ryzen isn't compatible with Windows 8.1 either - Microsoft made the call that 8.1 won't get Kaby Lake, Bristol Ridge, or Ryzen support, even though it's in mainstream support.

meerkt wrote:

Chrispy_ wrote:

Ryzen is officially a Windows10-only product.

Where did AMD say that?

Microsoft said it when they started blocking updates on Windows 7 and 8.1.

http://techreport.com/news/31741/update ... ow-blocked

Yeah, but AMD can do whatever they want regardless of Microsoft's decisions. Windows is still open enough. For now.

That's the least convincing argument ever. Unless AMD is going to repackage Windows updates and distribute them for Ryzen systems, Windows 7 and 8.1 are dead OSes on Ryzen. Running unpatched systems is a horrible idea.

(Edit) case in point: viewtopic.php?p=1350520#p1350521

I'm talking about driver/whatever support for CPU-specific features in terms of power modes or thread scheduling.

For most use cases (i.e. all the ones that involve being connected to the Internet) that's kind of moot if you can't get OS updates.

So could this prevent running old DOS games under DOSBox? I'm still a big fan of old DOS games and those are pretty much 16-bit. Who knows, some of them may even be 8-bit like some really old titles like Dragonworld (1984).

bhtooefr wrote:

http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

This would be of rather minor importance - it's only going to affect 16-bit processes running in V86 mode on a 32-bit OS (or memory manager, JemmEx for FreeDOS being the cited one) - if it weren't for the fact that XP and Server 2003 execute the video BIOS in that manner. Still fairly minor - nobody's running either of those OSes on the Ryzen metal - but could be annoying for someone who needs to run one of them in a VM.

My guess as to how AMD's going to fix it? If they can't fix it properly in microcode, just disable the VME bit in the CPUID. There's only one OS where that presents a problem, Windows 2000, where it assumes VME anyway, and VIA's solution (when they were shipping silicon that didn't support VME) was to distribute a patched NTVDM with the driver package.

The problem lies with the INT instruction, under the conditions named above. I suspect that this is typically an instruction written in microcode. In that case it can and will be fixed.

ronch wrote:

So could this prevent running old DOS games under DOSBox? I'm still a big fan of old DOS games and those are pretty much 16-bit. Who knows, some of them may even be 8-bit like some really old titles like Dragonworld (1984).

DOSbox is not a virtual machine. In addition, if you are running in 64-bit mode, the bug does not occur.

meerkt wrote:

Chrispy_ wrote:

I doubt AMD will have the resources or incentive to burden their new product with obsolete 16-bit legacy software support.

But it's officially part of x86. My guess is that they'll fix it in a future core stepping.

wingless wrote:

I run a Pentim 200MMX on Win98SE for 16-bit software. Real DOS on real hardware is better.

Kinda weak for 98SE, no?

Concupiscence wrote:

And I say this as someone who's got a 6 MB Canopus Pure3D sitting in his parts bin.

Call it plainly. Voodoo 1!

I had a Pentium 200MMX in 1997 that we upgraded to 98SE in 1998. It had 48MB of RAM back then. Now I run it with 96MB and an CF hard drive that maxes out the IDE bus so It's plenty fast for what I use it for.

For mid to late '90s DOS gaming it's more than adequate.

wingless wrote:

For mid to late '90s DOS gaming it's more than adequate.

More speed can't hurt (and memory for Win98 uses), and I don't think it would be any less compatible.
I recall Diablo 1 had super long load times on a Pentium 90. MMX 200 would certainly be quicker, but a Pentium III even more.

ronch wrote:

I'm still a big fan of old DOS games and those are pretty much 16-bit. Who knows, some of them may even be 8-bit like some really old titles like Dragonworld (1984).

I don't think DOS ran on i8080? IBM PC started with 16-bit.

<del me?>

And AGESA 1.0.0.6 includes a microcode update to patch this issue, apparently: http://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/