Some people may remember the joys of trying to boot Linux on an 8-bit AVR microcontroller, which was an absolute exercise in patience. In comparison [He Chunhui]’s Tiny386 emulator running on an ESP32-S3 MCU is positively zippy when it boots and runs Windows 95. The provided video (also embedded below) makes clear that while you can comfortably waddle off to prepare and pour a fresh cup of tea, it’s actually borderline usable.
The source code can be obtained via GitHub, which contains not just the basic emulated 80386 CPU written in C99, but also peripherals borrowed from TinyEMU and QEMU, along with a SeaBIOS ROM. In addition to the Windows 95 demo it’s claimed that Tiny386 should be able to run most 16/32-bit software.
Right now the ESP32-S3 version targets the JC3248W535 board, which is a roughly $30 development board featuring a built-in display with touch screen and an ESP32-S3 module. Although it has a USB-C port, it appears that this one is just for programming and not for the USB peripheral of the ESP32-S3. With the USB OTG peripheral used, one could conceivably make a small 386 system based around an ESP32-S3 that features a USB hub to plug a keyboard, mouse, etc. into.
Considering that the Tiny386 emulator is a very simple and straightforward approach to emulating an early-90s PC, some optimization might enable a pretty zippy general purpose PC for early 90s software. Quite a boost from watching Linux struggle into a command line on an AVR, indeed.
i suppose even a VIC-20 could run Windows 95 if you gave it enough bank-switched RAM and had the patience of an oak tree.
Propaply, if the timings were changed for the emulation.
If the system timer is emulated at real-time (normal),
then the loops would take to long and the Win95 watch-dog might halt the system because “Windows is not responding” anymore.
The time scale must be changed in short.
Within the emulation the passing of time must be different to the real world.
Speaking of timings, this emulation feels as if the emulated 386 ran at 6 MHz.
I have seen 386SX-16 system running Windows 95 more smooth, at least.
With something like an slow, unaccelerated OAK OTI-67 SVGA graphics card.
Windows 3.1 on a 286-10 with 4 MB of RAM ran way smoother, too.
Even in Hercules graphics mode on a Hercules card (known to be slow).
An 4,77 MHz V20 PC running Windows 3.0 in VGA was about same speed as in the video, I think.
That’s when you see the individual GUI elements being drawn step by step.
It takes C64 40 hours to boot into Linux https://www.youtube.com/watch?v=g-36d07DfgI&list=PLFBAnRI8OY7aJqgeZeABOfHzrQkEwK70a
Well done! 😎👍
Please just everyone keep in mind that this won’t rival a proper vintage PC
such as an 386DX-40 PC with 16 MB RAM, 500 MB HDD, an Cyrix math co.,
an accelerated ISA graphics card (ET4000/W32i, WD90C31 etc) and an AWE32 soundcard with EMU 8000 synth.
It’s not meant as an criticism whatsoever. In fact, I am impressed! 😃
I’m just writing this in defense of the real thing,
before anyone starts to glorify smartphones and modern microcontrollers.
The port is impressive and Win95 is usable for lightweight tasks for sure.
But unless Hover runs smooth as silk in the emulation, it’s not on same level as a real 386/486 of the 90s.
Quite impressive (even if not usable :D). Maybe for some old DOS games or even Windows 3.11…
Hi! Windows 3.1x wouldn’t be that much faster, though, maybe even slower.
That’s because GDI has changed between Windows 3.1x and 95 (for the better).
In 3.x, the graphics driver contains large portions of GDI itself,
while Windows 95 drivers merely use a mini driver for hardware-specific things and most of GDI is on the OS side.
Still, Windows 95 can fall back to use Windows 3.1x driver model.
I’m mentioning this because the emulator uses a generic VGA emulation.
That’s period-correct, I think, but also very slow.
Windows 3.1 already had introduced the concept of “Windows accelerators” or “GDI accelerators” to fix that.
These were originally ISA-bus based SVGA graphics cards that had a fixed-function 2D accelerator that could do bit-blit, zooming and basic graphics primitives (shapes), do filling and so on.
They were cheaper approachs than using earlier IBM 8514/A or TIGA,
which used intelligent, programmable graphics chips that reduced CPU load and could do things like drawing text or drawing the Windows GUI elements from their graphics memory.
So once emulator gets period-correct 2D acceleration,
the laggyness will be reduced.
Otherwise, the 16c Standard VGA driver attempts “dirty-rectangle” method at best.
Here, merely the parts of the screen which have changed are updated in video memory.
On slow PCs, this can sometimes be seen on older Windows 3.1 systems,
when large parts such as the wallpaper will be drawn in steps.
Emulating an ISA/VLB-based predecessor of the S3 Trio32/64 would be an solution, too.
DOSBox uses it. It’s an S3 graphics Vision 864, if memory serves.
The 2D core is an 8514/A derivative. The ATI Mach 8 or ATI Mach 32 are other fine candidates here.
Using XGA or XGA2 is another possibility, I guess. Not sure it’s already being emulated somewhere, though.
XGA was the intended successor of VGA (according to IBM).
Other settings are already fine for Windows 95, though.
On the Github page, the default setting is 32 MB of RAM, it seems. That’s okay, it reduces swapping.
Ideally, an SCSI controller or Ultra DMA capable controller would be available for HDD access, which would reduce CPU load.
Or it would help to make sure that the Windows 95 HDD driver is used, rather than DOS/BIOS for accessing the HDD.
Because that happens if no supported IDE controller is used.
The system will only see an int13h device.
Windows 95 (like 3.1x without FastDisk enabled) will then then try to use DOS (int21h) or BIOS (int13h) routines.
Which means that Windows will have to rely on Real-Mode code to access the HDD, rather than its own Protected-Mode HDD driver (ESDI_504.PTR port driver)..
Windows 3.1x and WfW 3.11 had their own 32-Bit Protected-Mode driver, known as FastDisk.
It merely worked with old WD1003 compatible HDD controllers, though.
Which were pre-IDE (they were from mid-80s) and merely newly available as an emulation inside IDE HDDs by 1992.
Thus, third-party drivers such as the MicroHouse driver were needed to make Windows 3.1x use modern HDDs at the time.
Makers of DDOs, Dynamic Disk Overlay software, also bundled FastDisk compatible drivers.
Anyway, this is not intended as criticism, but to tell how to further improve the emulation eventually.
By adding some of these things, Windows could be made run more smooth without requiring more raw CPU power for emulation.
For DOS games, the emulation might be good enough already, I imagine.
32-Bit games using DOS4GW DOS Extender will run fine, I think.
Point and Click games, for example. Or turn-based games.
For action games or SVGA graphics, an ET-4000AX emulation might help.
back in the day, i had a 386-16 with 4MB of RAM that i netbooted over a SLIP link and i set up swap over NFS (i found a patch to enable that) and i had it build a linux 1.2.13 kernel just to prove it really worked (it took more than a day). never again.
Not exactly Win95, but I’ve long thought about toying with just plain vanilla MS-DOS or FreeDOS on ESP32. I suspect even C3 would be enough for simple/straightforward things, though, porting x86 code to extensa code might not be something easy.
I’ve seen emulators, and they run perfectly fine, but the bare metal code could be just fun to try. No point really other than curiosity.
I’d recommend checking out theFabGL project. It’s an emulator, but I like that it has the source for everything including the bios in there; and you can really get a feel for the system architecture. I’ve played with extending it a bit; I almost have Tandy sound working but the noise channel is beyond my understanding.
Oh, and there’s been hardware for it cloned (not copied) to death everywhere. SD card slot, speaker connection, VGA port, 2x PS/2.
Thank you for sharing, and this will be just the rabbit hole for the next weekend (this one is already booked full).
I happen to have spare/unused PS2 keyboards and mice, together with old VGA displays (thankfully, LCD kinds) sitting sadly for some long while, so they will be back in business shortly. There are some old MS-DOS programs that I wrote way back when, and perhaps I’ll even fire up Borland C++ that I still have.
Looking around the archived browser links, found LiliGo’s FabGL board, might as well order a pair, good going. That way I won’t need to figure out the adapters, they are already included on the board itself.
BTW, one of the kewl forks I have is DosBox happily running inside SymbOS. SYmbOS runs on RaspPi Zero2W< which is quite overengineered for such a task. It literally boots up in less than a half second. Awesome possum.
ok why not 3.11?
Why not Windows CE.