-4

Is there was any microprocessor older than Intel 8086 (e.g., Z80, Intel 8080) which can run The Microsoft Windows 1.0 and at least display the GUI without glitches?

Also, using software mods, binary modifying* and hardware modifications** is allowed.

* Binary Modifying means translating opcodes to CPU's correct opcodes, or changing hardware settings to match correct CPU, if there was no non-supported instruction in code.

** Any modification of hardware to be compatible with new software, but no modifications to CPU, while adding customized hardware to cover features of new hardwares which is essential to run Windows is not allowed.

Improve this question
6
  • 12
    If you're going to allow 'translating opcodes to the CPU's correct opcodes' then basically every (Turing-complete) CPU can run it (as well as all software that has ever existed or will ever exist in the future). Just very slowly in some cases. Commented Jun 6 at 19:53
  • 4
    The question seems not well thought true. Using unclear terms like 'glitch' or 'mod' doesn't help either. Commented Jun 6 at 21:32
  • 5
    I think your conditions allow an emulator. If a C64 with a memory expansion can emulate a RISC CPU to run Linux kernel, indeed someone could write a 8086 emulator to run DOS Windows on 6502 or any other machine/CPU given there's enough memory or emulated memory like disk space provided in hardware. Commented Jun 6 at 21:34
  • Not without going to such extreme lengths as youtube.com/watch?v=nEwmYOZ-xME did. And probably not even then. Commented Jun 7 at 8:12
  • @user3840170 Which still asks for "a simple 32 Bit MCU" as minimum requirement :)) Commented Jun 7 at 10:29

3 Answers 3

Reset to default
11

Not without going to extreme lengths.

The first problem is RAM. In general, "8-bit" microprocessors had a 16-bit address bus. That limits you to a maximum of 64 KB of directly addressable memory: a quarter of the minimum RAM requirements for Windows 1.0 (and that is before you consider ROM and graphics RAM). You could extend this by building a bank-switching system but then the software has to be aware of how to use that bank-switching system.

You could argue that a bank-switching system could be designed that was similar to the segmented memory model on the x86. But the difference is that on x86 you can have multiple segments selected at once, with each segment having access to a full 64 KB. Whereas with bank switching, if you want multiple banks accessible at once those banks would have to be smaller than 64 KB.

The second problem is that while the 8086 instruction set bears some resemblance to that of the 8080, there are substantial differences. The 8080 and Z80 were primarily 8-bit processors with a very limited selection of 16-bit instructions, while the 8086 was a full 16-bit processor with virtually every instruction existing in a 16-bit form.

These differences are way beyond what could be papered over with small patches. You would be looking at either practically rewriting the code, or running the code under an emulator.

Improve this answer
4
  • 1
    +1 — regarding the instruction set, there are also more registers on the 8086 than on the 8080 and Z80 (and even more so the 6502), which complicates things further. Commented Jun 6 at 20:14
  • @StephenKitt Then again, number of registers isn't so much of an influence. Sure, a 6502 has its quirks, but an 1802 with even more registers than a 8086 wouldn't do much better. Of course, with capable mostly symmetric CPUs (and lots of free registers) holding emulated registers in real registers may help, but the gain isn't as great as one thinks at first. Commented Jun 6 at 21:48
  • @Raffzahn what I had in mind was that it complicates binary translation, or at least forces you to give up any hope of decent performance (especially going from 16-bit registers to 8-bit). Ironically the 6502 has an advantage there with its page zero! I take your point about the gain not being as great as I imagine, I suppose the benefit of mapping registers is mostly lost as soon as an exception path is involved (for example to handle an instruction that can’t be mapped directly). Commented Jun 7 at 8:23
  • @StephenKitt Yes, I didn't want to say you're wrong. Just that it's way less than most assume. Using register variables in tight loops is a great thing, but an emulator (or binary translation) is rarely about tight loops. For cases like this I always imagine translation to a /370. A quite capable CPU also having 16 32 bit registers, but it would fare extreme bad with translated 8086. for one, almost no instruction maps direct and then there is the '86es compact variable length encoding and the resulting high number of addressing modes. Commented Jun 7 at 9:11
5

Is there was any microprocessor older than Intel 8086 (e.g., Z80, Intel 8080) which can run The Microsoft Windows 1.0 and at least display the GUI without glitches?

No, as 8086 introduced a new instruction set - the very one Windows written for. There was no previous CPU with the same ISA. Sure, large parts of windows were already back then written in HLL, which would help to port it to some other (earlier) CPU. But I guess that's not what you had in mind.

Also, using software mods,

Patching won't do any good, as there is no prior CPU with that instruction set to execute it, so changing some instructions wouldn't do it.

Binary Modifying means translating opcodes to CPU's correct opcodes,

Binary translation is a wide field. A static translator might be possible, but virtually impossible as it would have to be extreme tailored to Windows code base - almost more work than rewriting.

A dynamic translator is of course as well viable. But that's in the end much like running an emulator - which of course can be done with any CPU.

or changing hardware settings to match correct CPU, if there was no non-supported instruction in code.

As said, the whole instruction set was new, so there is no partitial one that can be used and extended via some trapping.

Any modification of hardware to be compatible with new software, but no modifications to CPU, while adding customized hardware to cover features of new hardwares which is essential to run Windows is not allowed.

Somehow this makes no sense. Is additional hardware allowed or not?

In the end all of this only leaves an Emulation setup.

Also, all those somewhat over specific restrictions blur a bit the point that it's not just the CPU that defines an execution environment.

Last but not least, what exactly is the timeframe asked? Really pre 8086? Building an emulation setup providing PC like hardware and speed will be tight but possible.

Then again, there was no Windows until 1985. So a realistic base date would be (pre-)1985, which would provide speeds more than enough to match a 4.77 MHz 8088 :))

Improve this answer
4
  • 1
    Windows 1.x drivers generate blit code on the fly, which would make life extremely difficult for a static translation. Commented Jun 6 at 21:34
  • @john_e True. Then again, I thing replacing a driver would be acceptable under the mod rule - also, as it woudl be other hardware, it would need a fitting driver anyway - which could be written in native code with out stretching the frame to far (Yes, the whole thing will end in an endless chain of additional changes and bending of definition - kinda typical for a phantasy question). Commented Jun 6 at 21:38
  • 1
    Far as I know, no-one outside Microsoft has source code and workflow to build Windows 1 drivers even for the 8086, let alone hypothetical other processors. Commented Jun 6 at 21:50
  • @john_e Maybe. Then again, they are not really huge. CGA is some 12 KiB EGA 15. Sure, might need a few fun filled days, but not rocket science. Commented Jun 6 at 22:04
3

In theory, if you wanted to badly enough, you could write a PC emulator to run on a "larger" machine like a DEC microPDP-11/83, using a graphics terminal for the display.

I suppose it's open to argument whether that qualifies as a microprocessor or not. On one hand, for a while most people said a "microprocessor" meant a CPU implemented as a single IC.

On the other hand, various other processors, such as most (all?) current AMDs, and various others going back to at least the Pentium Pro, have used 2 or more integrated circuit mounted into a single package. Nobody seems to think these aren't "microprocessors".

The microPDP-11/83 used the J-11 CPU, which did the same: two chips mounted together into a single package (along with a few capacitors and such).

https://hackaday.com/2016/08/22/a-pdp-11-on-a-chip/

As such, I'd say it was a microprocessor. A typical microPDP-11/83 had 4 megabytes of RAM, which should be enough to emulate a PC. Then you'd have to add a graphics terminal (or use something like an Apple II as your terminal, if you preferred).

It would be expensive, and the performance would suck, but it could be made to work. The big problem with performance would be that Windows kind of takes for granted that it has a lot of bandwidth to the display, to allow things like dumping a big bitmap to erase the background. A terminal normally has a pretty low bandwidth connection to the computer, so that's not going to work very well. But as long as you don't care about performance, there's no reason it couldn't work.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.