Your desire for HDMI will limit your options quite a bit. First, you'll need a video card (or built-in video on the motherboard) that has either an HDMI port or DVI-D port (you would then need a DVI-to-HDMI adapter). Most recent PCI-E cards have HDMI, and you can go back as far as AGP cards that have DVI ports.

You could also convert a VGA signal on an older computer to HDMI using an external device.

Next, you could run DOS on bare metal using an older CPU/Motherboard platform, but you'll need to find a compatible sound card. I have only one card, an AOpen AW744-L with a Yamaha YMF744, that works on any computer with a chipset newer than the Intel 800-series. The 800-series and older motherboards can use a variety of PCI sound cards and even ISA sound cards in many cases.

Finally, newer CPUs will cause a number of timing issues with older DOS games on bare metal. It's hit and miss which would work best with relatively fast CPUs.

In my case, my Haswell-based Asrock Fatal1ty H97 Performance computer with the AOpen sound card can play a few DOS games on bare metal. I can get HDMI output on both my GeForce GTX 750Ti or the motherboard's video out. I have to say, though, that both tend to distort the screen image in text mode and certain low resolutions.

I don't know quite how you can address the wireless controller. I'm not sure how you can do that in DOS on bare metal. You could use a second wireless router as a relay to a wired network card that would work with DOS.

fosterwj03 wrote on 2020-12-08, 19:39:

Your desire for HDMI will limit your options quite a bit. First, you'll need a video card (or built-in video on the motherboard) that has either an HDMI port or DVI-D port (you would then need a DVI-to-HDMI adapter). Most recent PCI-E cards have HDMI, and you can go back as far as AGP cards that have DVI ports... I can get HDMI output on both my GeForce GTX 750Ti or the motherboard's video out. I have to say, though, that both tend to distort the screen image in text mode and certain low resolutions.

Assume that a fundamental principle of this console is a custom video output path to ensure correct frame timing and scaling over HDMI. This project will not use off-the-shelf video cards plugged into expansion slots in a case. The video chip will be either integrated into the SoC or soldered directly to the mainboard.

fosterwj03 wrote on 2020-12-08, 19:39:

Next, you could run DOS on bare metal using an older CPU/Motherboard platform, but you'll need to find a compatible sound card.

All three paths anticipate using a real sound chip. Since this would be a fully integrated project, the whole world of new-old-stock chips is possible, including PCI chips like the Yamaha YMF740 or ISA chips like the Yamaha YMF719 or the ES1868F. (For the last one, I would also add a true OPL3 chip, since ESFM is not exactly accurate.)

fosterwj03 wrote on 2020-12-08, 19:39:

Finally, newer CPUs will cause a number of timing issues with older DOS games on bare metal. It's hit and miss which would work best with relatively fast CPUs.

I'm not just looking at recent CPUs; there are some embedded CPUs that are only Pentium class that I'm considering. Regardless, as a console system with a launcher, each game would use a preconfigured profile that, if necessary, adjusts the CPU multiplier / L2 cache or runs a slowdown utility.

fosterwj03 wrote on 2020-12-08, 19:39:

I don't know quite how you can address the wireless controller. I'm not sure how you can do that in DOS on bare metal.

If using bare metal (path 1), there are two ways I've thought of:

1. Put a microcontroller with bluetooth support on the board and wire it up to the ISA / LPC bus. As far as DOS programs are concerned, they're talking to a real joystick port, AT keyboard, or serial mouse. Would work with all DOS software, requires writing a bunch of microcontroller code.
2. Write a TSR that listens for accesses to legacy IO ports (joystick) and keyboard interrupts, and interface with a bluetooth HID chip that way. Would work for any DOS game that is compatible with EMM386 / virtual 8086 mode, which is most of them.

I'm very interested to see which path you pursue. I don't have much to contribute other than the idea of a legacy PCI/ISA NIC that connects to a modern WiFi network by way of a RPi Zero or something similar built into the case is a good idea. It would be cool to make a RPi SD image that works for this purpose. I could see myself wanting to WiFi enable some of my retro machines and I think this would be a good way to handle it.

blougaville wrote on 2020-12-08, 20:24:

I don't have much to contribute other than the idea of a legacy PCI/ISA NIC that connects to a modern WiFi network by way of a RPi Zero or something similar built into the case is a good idea.

Indeed. That would fall into the second path I laid out, where a modern chip (like that in a RPi) handles connectivity to the modern world. If I went that way, I would let the RPi handle bluetooth as well.

LightStruk wrote on 2020-12-08, 18:10:

[*]Reconfigurable wireless controller that can play almost all DOS games without compromises (means mapping keyboard keys, not just a 4-axis 4-button joystick)

Remember to write some sort of on-screen keyboard for those games that rely on stuff like a text parser and can't be controlled by setting up a series of macros. Basically, if you have ever used the Steam big-picture mode, imagine that, but for DOS. Oh, and it would need to sit "outside" the DOS the game runs on.

LightStruk wrote on 2020-12-08, 18:10:

[*]Ethernet required, WiFi that connects to modern networks highly desirable

Not sure if there is any form of Wireless setup that supports actual pure DOS, but atleast for Windows 98 you'll be limited to WEP encryption (no support for WPA or WPA2) which is considered so unsafe, that even by law here it's not considered "effective protection" (in case your neighbor decides your network is better for his warez than his own)

LightStruk wrote on 2020-12-08, 18:10:

HDMI video output, works for both 60 Hz and 70 Hz (VGA mode 13h) games with no tearing. (Requires a display that supports either Variable Refresh Rate or 70 Hz input)

Remember that you need to stretch 320x200 into a 4:3 aspect ratio (like 1600x1200 for a native 5x and 6x integer scaling) while also keeping it at 70 Hz, oh, and an option to enable the stretch per game, as some were designed with it in mind and others expect to stay un-stretched.

For the OS....

LightStruk wrote on 2020-12-08, 18:10:

1. Run DOS on bare metal. Making a pretty GUI is challenging with old dev tools and libraries, handling networking is much, much harder (modern SSL/TLS on DOS? WPA2 WiFi networks?). Requires tweaks to the BIOS and writing new TSRs to configure HDMI video output and to work with the game controller.

No WPA2 afaik, with much luck WEP. Also remember to write all those drivers in a way, that you can load them outside of base memory. Building a GUI isn't the issue, but keeping it small so you have enough room for the actual game left. Also DOS doesn't know SATA, USB, NTFS, ExFAT, PCI express, controllers that go beyond what the Gameport supports, etc. so all that stuff needs to be translated into something DOS itself understands, in a way that doesn't let it run out of memory, so putting in tons of drivers might be an issue.

LightStruk wrote on 2020-12-08, 18:10:

[*]Put two CPUs in the box - one legacy x86 to play DOS games and talk to authentic hardware, and another, more modern SOC (x86 or ARM) to handle talking to the modern world. The software challenge is smaller than the first one, but the hardware challenge is much bigger. (If you really want to go down a rabbit hole with this option, take a look at the Vortex86EX2 SoC...)
[*]Run Linux on bare metal with a recent x86 CPU, and virtualize DOS. Use IOMMU to drive real sound hardware directly from the virtual DOS environment. Networking is now trivial, bluetooth game controller input is free, and all modern UI toolkits are on the table for making the GUI. Modern conveniences like save states become possible. No extra work needed to drive an HDMI display.[/list]

The Linux setup would probably be the easiest to implement. As you said many modern conveniences, support for HDMI, network, input, etc. And you can work around the fact that many, especially early, DOS games require the right CPU speed or they will run too fast. You could also use the Linux host to take care of the controller setup/OSD and disk swapping. Basically having a DOS VM that runs on a Linux host, which the user doesn't see until they deliberate boot into it (Like going into the CMOS setup on a PC BIOS, or the firmware GUI on consoles like a PS2 or 3DS when you start them without game)
You'd need to setup a library that prepares all the settings so that a user doesn't has to setup everything manually, but can still configure stuff further, if desired. A bit like changing a DOSBox or GZDoom config file, that can be ran for each game/mod in case they need different setups, or use the general one. DOSBox config files can be set up that they start directly into the game without even seeing the DOS command prompt.

Not sure how well Linux can manage handover of real hardware into the "DOS VM", but I've seen people setup SNES emulators with the actual console to use the real, hardware, sound chip instead of emulating it.

As little note from personal experience with my Pentium 3 setup: I managed to get it to run with USB mouse/keyboard through the legacy USB function in the BIOS, even when I boot it directly into DOS, CD and sound (an awful SB128 PCI) works fine but still struggle with setting up the network. Using DOS 7.1 (which comes with 98 SE) gives access to FAT32 drives and 4DOS makes the actual command line a bit easier.

Good luck with your idea. In the end it could mean playing DOS games can be as easy as playing old console games on the Wii VC or one of those mini consoles with a bunch of games on them: You just get (buy) the game and launch it form a nice GUI menu.

lordmogul wrote on 2020-12-09, 06:39:

Remember to write some sort of on-screen keyboard for those games that rely on stuff like a text parser and can't be controlled by setting up a series of macros. Basically, if you have ever used the Steam big-picture mode, imagine that, but for DOS. Oh, and it would need to sit "outside" the DOS the game runs on.

For the bare metal option, it would need to be a TSR that task-switches to the on-screen keyboard. One has to be really careful saving and restoring the VGA registers, not to mention whatever the sound card is up to. Honestly, I'd rather just support an optional bluetooth keyboard for those games that simply won't fit into the buttons on the gamepad.

lordmogul wrote on 2020-12-09, 06:39:

Not sure if there is any form of Wireless setup that supports actual pure DOS, but atleast for Windows 98 you'll be limited to WEP encryption (no support for WPA or WPA2) which is considered so unsafe, that even by law here it's not considered "effective protection" (in case your neighbor decides your network is better for his warez than his own)

Asking a user to downgrade their WiFi's encryption for a retrogaming console is insane. Ethernet-to-Wifi bridges do exist, although that's not user-friendly. eeguru claims to be making an NE2000-compatible WiFi adapter with his one sound card to rule them all, which will presumably come with a custom-written setup program to configure the connection. All of these hacks go away if I don't go the bare metal route.

lordmogul wrote on 2020-12-09, 06:39:

Remember that you need to stretch 320x200 into a 4:3 aspect ratio (like 1600x1200 for a native 5x and 6x integer scaling) while also keeping it at 70 Hz, oh, and an option to enable the stretch per game, as some were designed with it in mind and others expect to stay un-stretched.

Can you give me an example of a 320x200 game that expects to be un-stretched (i.e., square pixels)? Were users expected to adjust their CRT monitors to make the game happy?

lordmogul wrote on 2020-12-09, 06:39:

Building a GUI isn't the issue, but keeping it small so you have enough room for the actual game left. Also DOS doesn't know SATA, USB, NTFS, ExFAT, PCI express, controllers that go beyond what the Gameport supports, etc. so all that stuff needs to be translated into something DOS itself understands, in a way that doesn't let it run out of memory, so putting in tons of drivers might be an issue.

If on bare metal, the GUI would be unloaded before loading the game; no worries about using up conventional memory. I wouldn't need to write SATA, NTFS, or ExFAT drivers; FAT32 (using DOS 7.x or FreeDOS) is fine, and the BIOS handles exposing a SATA disk to DOS. Don't need USB either - the only input devices for this console are supposed to be Bluetooth (which would need drivers.)

lordmogul wrote on 2020-12-09, 06:39:

Not sure how well Linux can manage handover of real hardware into the "DOS VM", but I've seen people setup SNES emulators with the actual console to use the real, hardware, sound chip instead of emulating it.

It's a feature of modern CPUs called VT-d (Intel) / AMD-Vi (AMD) with IOMMU to directly interface real hardware with a VM.

lordmogul wrote on 2020-12-09, 06:39:

Good luck with your idea. In the end it could mean playing DOS games can be as easy as playing old console games on the Wii VC or one of those mini consoles with a bunch of games on them: You just get (buy) the game and launch it form a nice GUI menu.

Thanks!

LightStruk wrote on 2020-12-08, 18:10:

Run Linux on bare metal with a recent x86 CPU, and virtualize DOS. Use IOMMU to drive real sound hardware directly from the virtual DOS environment. Networking is now trivial, bluetooth game controller input is free, and all modern UI toolkits are on the table for making the GUI. Modern conveniences like save states become possible. No extra work needed to drive an HDMI display.

What "virtualizer" are you thinking of that has save states? Generally that is exclusive to emulation.

or does using virtualization (not emulation) make it no more compelling than RetroArch?

In the end, the question is: who are you trying to "compell"?

If you're trying to envision a marketable product here, then it seems there are two ways to go: an enormously expensive niche product targeting a very narrow audience, like Analogue's products, or a vastly cheaper device for people who just want to play games and could not care less about what is going on "under the hood", like Nintendo's new mini consoles.

LightStruk wrote on 2020-12-09, 13:58:

It's a feature of modern CPUs called VT-d (Intel) / AMD-Vi (AMD) with IOMMU to directly interface real hardware with a VM.

VT-d (and very possible AMD-Vi) are sh*t to passthrough hardware to DOS, specially for Video hardware, which do memio in a very troublesome way. Limitation is on-silicon, so can't be fixed by code.
https://github.com/intel/haxm/pull/199#issuec … mment-527340774
https://github.com/intel/haxm/issues/164

It would also possess a problem for ISADMA. VT simply wasn't designed with this usage in mind. It expects the OSs running inside behaving in very specific ways, which is the case with NT, *nixes, and any obscure or hobbist OS developed around a VM.

Jorpho wrote on 2020-12-09, 18:05:

What "virtualizer" are you thinking of that has save states? Generally that is exclusive to emulation.

VMware actually do an excellent job doing saving states since ages. Unfortunately I can't say the same of VBox cr*p.

hyoenmadan wrote on 2020-12-09, 18:56:

VMware actually do an excellent job doing saving states since ages. Unfortunately I can't say the same of VBox cr*p.

I suppose, but isn't that mostly for just suspend-and-resume? Does it let you save an arbitrary number of states for each virtual machine? And surely saving and loading is not comparable to the nearly instantaneous process people are accustomed to in most emulators?

On that note, I suspect fast-forward and rewind is a very useful feature people have grown accustomed to having in emulation, and that certainly isn't available in virtualization, if I'm not gravely mistaken.

hyoenmadan wrote on 2020-12-09, 18:56:

VT-d (and very possible AMD-Vi) are sh*t to passthrough hardware to DOS, specially for Video hardware, which do memio in a very […]
Show full quote

VT-d (and very possible AMD-Vi) are sh*t to passthrough hardware to DOS, specially for Video hardware, which do memio in a very troublesome way. Limitation is on-silicon, so can't be fixed by code.
https://github.com/intel/haxm/pull/199#issuec … mment-527340774
https://github.com/intel/haxm/issues/164

It would also possess a problem for ISADMA. VT simply wasn't designed with this usage in mind. It expects the OSs running inside behaving in very specific ways, which is the case with NT, *nixes, and any obscure or hobbist OS developed around a VM.

Thank you for bringing this to my attention. If I'm reading these two links correctly, the issue is that DOS VGA performance using HW virtualization sucks, and they can't pass through the calls to a real VGA card, primarily because of memory-mapped I/O. Sound cards don't use MMIO, they use x86 I/O regs, DMA, and IRQs. You're saying that it would also be an issue for ISA DMA (at least on Intel), but even if that turns out to not be a problem, I still need VGA performance that doesn't suck. Looks like I would need to build a true prototype just to know for sure whether a modern CPU and a PCI sound chip with PC/PCI or an ISA sound chip will work using IOMMU, and even then need to make sure the video performance is still good.

Even with VT-d current CPUs can execute basic instructions differently from older CPUs if undefined behaviour is invoked, which some games rely on.

jmarsh wrote on 2020-12-10, 01:28:

Even with VT-d current CPUs can execute basic instructions differently from older CPUs if undefined behaviour is invoked, which some games rely on.

That's relevant. Can you provide some examples?

LightStruk wrote on 2020-12-09, 13:58:

lordmogul wrote on 2020-12-09, 06:39:

Remember that you need to stretch 320x200 into a 4:3 aspect ratio (like 1600x1200 for a native 5x and 6x integer scaling) while also keeping it at 70 Hz, oh, and an option to enable the stretch per game, as some were designed with it in mind and others expect to stay un-stretched.

Can you give me an example of a 320x200 game that expects to be un-stretched (i.e., square pixels)? Were users expected to adjust their CRT monitors to make the game happy?

^^ Jazz Jackrabbit

Overkill

Space Station Oblivion

Cybersphere (and plenty of other Amiga ports)

There are lots of examples out there. I also *distinctly* remember a game that started with a splash screen that said "please adjust your monitor until the square is square and the circle is a circle", but that one's been eluding me for years. Thats probably an edge case though. Toggling between 16x10 and 4x3 would cover 99.99% of all cases. (And don't forget oddball modes like 256 line modes or 360x350 etc. had no particular target aspect ratio & people used them in all kinds of ways.)

Just wanted to throw this into the discussion, but for the amount of expense that would go into some kind of hybrid new\old system, it is probably most cost effective (and flexible) to simply use a high end gaming-oriented scan converter so that you can just use an old computer on a newer display, and then accept the limitations. Turning it into a product is simply not feasible, for a great number of reasons. The biggest problem is that you can't sell a commercial (as in, manufactured, not used) device running Microsoft software without licensing that, assuming you want it to run any Windows games. So right out the door, you're hoping that Microsoft will allow someone to make and sell a product running software that they no longer support... which is just not going to happen. The alternative is asking for users to set it up themselves, which is going to count out basically anyone who would buy a DOS console rather than just use an old computer.

I had some experience with using an older system on a modern display just last week actually.

The other day I surprised my wife and daughter with a brand new, sealed big-box copy of My Little Pony: Friendship Garden for PC (1998). My wife had this fairly rare game as a child in the late 90s and loved it. To make it easy for them to play it (since it didn't work in Windows 10... too bad) I hooked up my old Gateway G6-400 running Windows 98SE to the TV in our living room using a PCI Geforce 6200 with a DVI to HDMI adapter, and it worked but there were lots of overscan and stability issues. 1920x1080 in Windows 98 looked amazing, but almost every other resolution had issues and the drivers were too limited to fix them. One awesome thing I learned though, was that Logitech Unifying receivers work fine in Windows 98SE with the built in drivers, so I was able to use the same wireless mouse and keyboard (with touch pad!) that we use on our HTPC.

To solve the video issues, I just got out a basic VGA to HDMI converter box I picked up for a dollar when the local Radioshack closed. I took out the 6200 PCI, went back to the onboard Riva 128 8MB (plenty for our needs), hooked the VGA to HDMI converter to it and once the computer was in Windows, it worked fine. As far as I can tell, it only supports 800x600, 1024x768 and some other common resolutions, which means that the BIOS and DOS screens do not show up, but I'm sure there are other converters that support more resolutions. 70Hz will still be an issue, but you're never going to get 70Hz on a display that doesn't support it without using a device that drops frames or something.

If I used this in conjunction with the TVOne Corio VGA scaler I picked up on ebay a few years ago, I'm sure I could set that up to scale all resolutions to 1024x768, which would make the HDMI converter and the TV much happier. I can't remember how it handles different refresh rates though.

So, that solves part of the problem if your main goal is to just get an old PC to work on a modern TV... but we aren't trying to get it to connect to our wifi or use modern wireless controllers, etc.

Beyond that point though, I have to be honest... I feel that interacting with the old hardware is half the experience. The satisfying clunk of an old power switch, clack of an old keyboard, click of an old mouse, hearing the drives running (though solid state is worth the trade off for everyday use).... and the best part is using a CRT! No modern screens will look 100% authentic, because DOS games were never meant for sample and hold displays (LCD, OLED, etc.). The closest you can get is using one of the rare monitors that can support single-strobe backlight strobing for blur reduction at low refresh rates, like a BenQ XL2720Z (which I bought for that reason 5 years ago). But even then, you aren't going to get the refresh rate and resolution flexibility of a CRT, or even a "vintage"LCD from the early to mid 2000s.

What I'm getting at is, if you modernize 90% of the experience, then the expensive and rare old hardware hooked up to the modern stuff will feel no more authentic than an emulator. If you're wanting DOS or Windows 3.1 games, for $50 you could pick up a 10 year old laptop (duct tape the whole thing inside an empty old PC tower if you want it to look retro), set it up to run DOSBox at startup, and with the right setup (blank Windows splash screens, etc.) it will likely feel no less authentic than having all the same modern equipment (TV, modern peripherals, wifi, etc.) running on an extremely complex and expensive retro-to-modern conversion setup.

Summary:

*For DOS and 9x games, try just using a Windows 98SE system (with USB support), with a VGA scaler and an HDMI converter, and accept that some things aren't going to be perfect, the display is not going to look 100% authentic, the input devices will be limited to what works on the old PC, and you'll have to use a flash drive or ethernet (for FTP) to transfer stuff to the computer.

*For DOS only, if you aren't a purist, just use DOSbox on something newer. Countless hours and many dollars saved and it will work fine on your TV with all your modern gear.

*For the most authentic experience, avoid modern stuff as much as you can justify. Pick up old stuff, learn how to use it, and accept that retro PC gaming is really not couch friendly, and is just as much about troubleshooting as it is about playing games.

*If you want it to be a couch-friendly console like device: Good Old Games has already taken a stab at making retro PC gaming a couch-ready thing, and their versions tend to work fairly well using a mix of emulation and custom modified software to run on modern computers so you don't have to know the ins and outs of computers from several different eras just to play a few games. This means that any kind of retro PC gaming console would need to offer at least that kind of experience to be competitive. In other words: Who will set up the games for people and where will they get them? Often times, computers need to be tweaked a little bit for each game to work right, which is a tough sell for anyone that isn't into retro computing as a hobby. On top of that, no commercial product can be sold running MS-DOS or Windows without support from Microsoft (or breaking the law) because the games rely on MS software to work... unless you use an MS-DOS alternative, and forego Windows... but you've just limited the system's usefulness to pre-1997 games, and there are likely to be more setup headaches for each game.

The absolute best chance at making something like this feasible would be to convince GoG to help support the development of a console that runs their store\launcher. Anything less than that is just kind of building a new computer to struggle with the same old problems that people let behind in the 90s (unless they're weird, like us).

I have two systems with that specs.

One platform is the Intel one on a P3B with BX chipset and ISA slot populated with an AWE64 Gold. CPU is a P3 700.
The graphics card is an AGP GeForce 6200 with a DVI connector.
Both sound card and graphics card are connected to a TV. Happily the TV plays the sound from analogue input from the AWE while receiving video from the HDMI which is converted by a passive DVI to HDMI adapter.

Second platform is an AMD one with a MVP3 chipset and the ISA slot populated with an AWE64 and a GUS classic. CPU is a K6-2+ 570.
The graphics card is an AGP GeForce 5200 with a DVI connector.
Unfortuneately I do not have another big TV, but the situation is similar to the scenatio above.

However, this is done with real hardware.

Ethernet?
Use an access point in client mode.

I recently stumbled across the Pi KVM project and it had me thinking along the same lines. Creating a version of the Pi KVM project that works with retro hardware could potentially accomplish all of the stated goals. It seems to me one of the big challenges is the video capture. I have an idea, but I don't know if it's just trading a difficult problem for another difficult problem. If we have the luxury of integrating the modern hardware with the retro hardware, then rather than converting a VGA signal to HDMI, or finding a Goldilocks card with a DVI output, why not capture the VGA memory/registers/buffer directly from the video adapter?

Jazz Jackrabbit is not a 320x200 game, it's a 320x240 game (square pixels) that uses letterboxing to achieve an active display area of 320x199.

More feasable will be a bare metal PCem 86box machine. But yeah a SOC motherboard, comptible VGA and a ISA based SB PRO clone single board computer could be nice, and the HDMI scan converter addon would be nice. But a wifi, this is overkill. You can just add a cheap Realtec NIC in there, it has even DOS drivers.

Ozzuneoj wrote on 2020-12-10, 05:02:

On top of that, no commercial product can be sold running MS-DOS or Windows without support from Microsoft (or breaking the law) because the games rely on MS software to work... unless you use an MS-DOS alternative, and forego Windows... but you've just limited the system's usefulness to pre-1997 games, and there are likely to be more setup headaches for each game.

I think between HX DOS Extender, BoxedWine, WineVDM, and Lutris, it's quite feasible to get Windows games running without Windows these days if one is sufficiently determined.

Of course, it's rather absurd to go to extreme lengths to guarantee that you're running x86 code on an x86 processor an i64 processor running in x86 mode (for whatever baffling reason) and then not provide an authentic execution environment.