I am a big fan of 86box for my retro PC hobby. Some neat things I've used it for:
* Log virtual POST codes to a text file for a physical motherboard I'm troubleshooting to see where it's hanging up
* Install an old OS to a .img file which I can then extract and pull bit-perfect files from
* Create a virtual hard drive with matching CHS values to a real hard drive, install an OS, then write the image to a real disk and boot it on real hardware
* And of course, play around with old hardware, software, and games in fairly accurate simulated way :)
exikyut 3 hours ago [-]
> Log virtual POST codes to a text file for a physical motherboard I'm troubleshooting to see where it's hanging up
That sounds awesome but my brain can't follow today.
What did the setup look like here?
My brain's looking at a test motherboard, then at 86Box (which would presumably run on your main system), and I can't figure out how to connect the dots.
rasz 2 days ago [-]
>Log virtual POST codes to a text file for a physical motherboard I'm troubleshooting to see where it's hanging up
I went as far as simulating defects by modifying individual hardware blocks in 86Box source code, recompiling, and checking resulting POST code because that seemed faster than carefully tracing BIOS :)
That's awesome, rasz! It's amazing how 86box allows us to peer into hardware we otherwise couldn't easily access. 8)
rasz 11 hours ago [-]
I was blown away how easy and fast whole process was. I posted about my plan at 14:33 and results at 16:55. I even commented at the time how "setting up build env and compiling 86Box was a breeze".
rougka 3 days ago [-]
wow, the screenshots attached to each release on github are deeply nostalgic
86box seems to be the successor of PCem, a GUI Emulator that is capable of emulating full Hardware (incl. Settings and BIOS/firmware) via GUI selection. I use it for old games, because emulating of 3dfx and similar is also possible in an easy way.
Maybe this can be done with blink, but probably not by selecting a few dropdowns and clicking some buttons...
nubinetwork 3 days ago [-]
Pcem is still being actively developed, even though Sarah Walker said she wasn't working on it anymore.
snvzz 3 days ago [-]
Successor or fork?
I am not sure about the details, but I seem to remember it was not a very amicable fork.
Found this pretty interesting how to use in practise.
powerhugs 3 days ago [-]
Not at all. Blink according to themselves is:
> blink is a virtual machine that runs x86-64-linux programs on different operating systems and hardware architectures.
Where 86Box is, according to themselves:
> 86Box is a low level x86 emulator that runs older operating systems and software designed for IBM PC systems and compatibles from 1981 through fairly recent system designs based on the PCI bus.
snvzz 3 days ago [-]
Blink seems to be closer to qemu-user or box86/box64[0].
This is an excellent piece of software - use it almost every day. It’s the best way to run basically any operating system from the pre-USB era. It includes a very good emulation of the IBM PC _jr_, a whole host of other ISA, VESA Local Bus, MCA, and PCI based machines. It also has CPU modes good enough to run troublesome programs that don’t function in DOSBox or dosemu2.
sebazzz 2 days ago [-]
I do occasionally run into stability issues, especially with 3D games. The emulation is not 100% perfect.
memsom 3 days ago [-]
This is a nice project. I use it to emulate BeOS on an Apple Silicon Macbook.
3 days ago [-]
forty 3 days ago [-]
Is this needed because recent x86-64 processors / hardware are not able to run older 32bits binaries anymore?
memsom 3 days ago [-]
Getting any legacy OS to run on modern hardware is very hard. For example, in my case, BeOS has no EFI boot capability, has a serious RAM restriction, doesn't really like anything past a P4, and has no drivers for anything but legacy hardware (like, no modern storage drivers - IDE only, no SATA unless there is legacy BIOS emulation.) A lot of this is able to be worked around with various hacks, but with 86Box, it will run the OS as is it was on the actual hardware, so it just makes it a no brainer. You can then also use it to emulate old PC hardware on other processor architectures - like ARM.
xcv123 3 days ago [-]
It runs on other CPU architectures and it emulates older PCs which include other hardware besides the CPU.
forty 3 days ago [-]
Ah yes, they have ARM binaries indeed in the download section. I got trapped by the "minimum requirements": Intel Core 2 or AMD Athlon 64 processor or newer, which made me think it only ran on x86
sedatk 3 days ago [-]
Did you mean 16-bit binaries?
rnd0 3 days ago [-]
Strictly speaking, no. It's primarily developed (as I understand it) for cases (gaming, mostly, but some hobby/dev use) where emulating hardware accurately (think timings) is desireable.
In a sense it's also a history preservation project, though I doubt they would characterize it as such themselves. They don't do the documentation that pcjs does; but I think it's similar in spirit, if not in implementation specifics.
rnd0 3 days ago [-]
I should clarify that when I say that, I don't mean documentation about the emulator (which is coming along nicely), but documentation about the computers being emulated. I was specifically thinking of things like this ( https://www.pcjs.org/machines/pcx86/compaq/portable/ ) when I was writing that comment.
userbinator 3 days ago [-]
AFAIK that's a software limitation, not a hardware one (yet).
dfox 3 days ago [-]
Technically it is an hardware limitation, amd64 in long mode has only vestigal support for memory segmentation (enough to implement Win32/ELF i386 TLS ABI and that's it), so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform.
rep_lodsb 2 days ago [-]
To add to what userbinator said, you can have 16-bit code segments in long mode. I've played around with this a bit, and made a minimal proof-of-concept "DOS emulator": an INT 21h from the 16-bit segment causes a SIGSEGV, which is intercepted by 32-bit code and turned into the corresponding Linux INT 80h syscall. All running on a standard 64-bit kernel with no dependency on any external libraries.
(I'm not planning to publish this, and it's very minimal: the only supported syscalls are read, write and exit, and the program needs to have exactly two segments, CS and DS=initial SS as defined in the EXE header. But it should be theoretically possible to make something more elaborate that can run at least a few "well-behaved" normal DOS programs, as long as they don't do any arithmetic on segment registers.)
What's no longer available in long mode is the virtual 8086 mode, for that you'd need to use either the more modern virtualization features (with "unrestricted guest" support), or a software emulator.
userbinator 2 days ago [-]
so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform.
I don't know who has been spreading FUD (likely MS, just like they did with "32-bit Windows can't use more than 4GB of RAM") but that's not true.
There's another article I can't find at the moment which discusses this in a lot of technical detail, making references to using the "unrestricted guest" virtualisation feature on CPUs that have it (quite new at the time) which essentially runs 16-bit code as a VM, or classic modeswitching that jumps between 16, 32, and 64-bit mode as needed. Nonetheless, it is quite irritating that despite the hardware being perfectly capable of 16-bit, 32-bit, and 64-bit operation, the designers made it harder than necessary to do so.
dfe 1 days ago [-]
In the absence of VM extensions, which the earliest AMD64 CPUs did not have, once the CPU is in long mode, the base address of segments other than FS and GS doesn't work, it must be 0.
That's not such a problem for 32-bit segments whose base is normally 0 anyway (flat 32), but most 16-bit protected mode Windows code expects the linear address of its code and data segments to be something other than 0, and even might expect to be able to use multiple data segments with different base addresses.
So, sure, you can run 16-bit protected mode code with a base address of 0, but that's not very useful.
Also there's no virtual 8086 mode when in long mode to support real mode code.
With VM extensions it's possible to virtualize the CPU in regular (not long) mode, at which point the virtualized CPU will indeed support non-zero segment base addresses and virtual 8086 mode.
In theory this can be done with an extremely light virtual machine layer, but the entry/exit to/from the 16-bit code, or even for that matter any code needing to use 16-bit data segments is going to require more than it would if the CPU weren't in long mode. And this is assuming you have virtual mode extensions. If you don't then you need a CPU emulator.
My guess is that Microsoft felt it just wasn't worth writing all of this extra code needed to do this. There's a big difference between technically possible and makes even remote economic sense to do it.
rep_lodsb 1 days ago [-]
When the manual says that the segment bases are ignored in long mode, it is only referring to 64-bit code. As far as I remember, the terminology goes like this:
64-bit OS, running 64-bit user code -> "long mode"
64-bit OS, 16/32-bit user code -> "compatibility mode"
16/32-bit OS -> "legacy mode"
Also I've personally tested that it works, without any virtualization required (see sibling comment). Wine also does it in order to run 16-bit Windows programs, or at least it used to at one time - IIRC, there was some discussion on the Linux kernel mailing list about it.
NikkiA 3 days ago [-]
Intel dropped the "x86s" project to focus on a more collaborative approach with amd and others, so it's probably been shifted a few years out anyway.
powerhugs 3 days ago [-]
It allows you to emulate MS-DOS or other legacy 16/32-bit operating systems on any supported hardware, such as ARM.
* Log virtual POST codes to a text file for a physical motherboard I'm troubleshooting to see where it's hanging up
* Install an old OS to a .img file which I can then extract and pull bit-perfect files from
* Create a virtual hard drive with matching CHS values to a real hard drive, install an OS, then write the image to a real disk and boot it on real hardware
* And of course, play around with old hardware, software, and games in fairly accurate simulated way :)
That sounds awesome but my brain can't follow today.
What did the setup look like here?
My brain's looking at a test motherboard, then at 86Box (which would presumably run on your main system), and I can't figure out how to connect the dots.
I went as far as simulating defects by modifying individual hardware blocks in 86Box source code, recompiling, and checking resulting POST code because that seemed faster than carefully tracing BIOS :)
"Modified 86Box to break RTC always returning 0 or 0xff. POST_7 freeze." https://www.vogons.org/viewtopic.php?p=1041079#p1041079
https://github.com/86Box/86Box/releases
[1] https://github.com/jart/blink
Maybe this can be done with blink, but probably not by selecting a few dropdowns and clicking some buttons...
I am not sure about the details, but I seem to remember it was not a very amicable fork.
It's instructive to look at the activity level of pcem (their forum, and their github account: https://github.com/sarah-walker-pcem/pcem/commits/dev/) versus 86box ( https://github.com/86Box/86Box/commits/master/ )
86box has a vibrant community around it (pop in the discord some time!) which PCEM really doesn't as far as I'm able to tell.
Yes, there is a lot of bad blood -but I would suggest taking any stories that you hear (but did not witness yourself) with a huge grain of salt.
https://www.youtube.com/watch?v=mWEE2RJj3YI
Found this pretty interesting how to use in practise.
> blink is a virtual machine that runs x86-64-linux programs on different operating systems and hardware architectures.
Where 86Box is, according to themselves:
> 86Box is a low level x86 emulator that runs older operating systems and software designed for IBM PC systems and compatibles from 1981 through fairly recent system designs based on the PCI bus.
0. https://box86.org/
In a sense it's also a history preservation project, though I doubt they would characterize it as such themselves. They don't do the documentation that pcjs does; but I think it's similar in spirit, if not in implementation specifics.
(I'm not planning to publish this, and it's very minimal: the only supported syscalls are read, write and exit, and the program needs to have exactly two segments, CS and DS=initial SS as defined in the EXE header. But it should be theoretically possible to make something more elaborate that can run at least a few "well-behaved" normal DOS programs, as long as they don't do any arithmetic on segment registers.)
What's no longer available in long mode is the virtual 8086 mode, for that you'd need to use either the more modern virtualization features (with "unrestricted guest" support), or a software emulator.
I don't know who has been spreading FUD (likely MS, just like they did with "32-bit Windows can't use more than 4GB of RAM") but that's not true.
https://www.dkia.at/en/node/180
There's another article I can't find at the moment which discusses this in a lot of technical detail, making references to using the "unrestricted guest" virtualisation feature on CPUs that have it (quite new at the time) which essentially runs 16-bit code as a VM, or classic modeswitching that jumps between 16, 32, and 64-bit mode as needed. Nonetheless, it is quite irritating that despite the hardware being perfectly capable of 16-bit, 32-bit, and 64-bit operation, the designers made it harder than necessary to do so.
That's not such a problem for 32-bit segments whose base is normally 0 anyway (flat 32), but most 16-bit protected mode Windows code expects the linear address of its code and data segments to be something other than 0, and even might expect to be able to use multiple data segments with different base addresses.
So, sure, you can run 16-bit protected mode code with a base address of 0, but that's not very useful.
Also there's no virtual 8086 mode when in long mode to support real mode code.
With VM extensions it's possible to virtualize the CPU in regular (not long) mode, at which point the virtualized CPU will indeed support non-zero segment base addresses and virtual 8086 mode.
In theory this can be done with an extremely light virtual machine layer, but the entry/exit to/from the 16-bit code, or even for that matter any code needing to use 16-bit data segments is going to require more than it would if the CPU weren't in long mode. And this is assuming you have virtual mode extensions. If you don't then you need a CPU emulator.
My guess is that Microsoft felt it just wasn't worth writing all of this extra code needed to do this. There's a big difference between technically possible and makes even remote economic sense to do it.