14

Suppose you wanted to take a 286 PC and replace the CPU with a 68000, not at the initial design stage, but actually modifying the finished machine, on the theory that they both have 24 bits of address and 16 bits of data bus so it's not obviously hopeless. What would be the obstacles?

First, most obviously, they are completely incompatible at the software level. All 286 code in ROM or on disk would have to be replaced with suitably equivalent 68000 code.

The packages are different. The 286 is in a square package whereas the 68000 is in a DIP; something would have to be done to physically wire up the replacement chip.

The pins are in different positions, but do they have functional equivalents? Connecting e.g. D4 on one chip to where D4 on the other was connected, would be straightforward enough, but are there pins in one that don't have an equivalent in the other?

x86 is little-endian and 68k is big-endian. Does that matter, once you've replaced the software?

Let's say for the sake of argument we are talking about 8 MHz clock speed in both cases, so that shouldn't be an issue.

What else am I missing?

  • 4
    DRAM refreshing. Support chips - typically there is a closely related family of chips for handling common I/O, memory management, etc. Interrupt handling. Probably a few other things I haven't thought of. I am a mostly software person - and I think the software (starting at the BIOS level) would actually be the easy part. – manassehkatz Dec 28 '17 at 19:20
  • 4
    The other way around existed, putting x86 CPUs in MC68K computers to be able to run PC software. For example, this i286 daughterboard for ATARI ST computers, fitted on the MC68000 socket : atarimagazines.com/startv5n7/at_speed.html, atariage.com/forums/topic/… – TEMLIB Dec 28 '17 at 20:27
  • 3
    @TEMLIB there have been also several 68k boards for the PC. But isn't his question rather about replacing the main CPU? – Raffzahn Dec 28 '17 at 20:41
  • 2
    You already have good answers, so I'll just put this aside in a comment here: you've hit on a major divide between processors. There are basically two main designs of bus, which you can think of as Intel and Motorola types. It's probably actually easier to attach a processor with a different bus width to a board of the same type than the other way around -- plugging a Z80 into a PC or an 8086 into an S100 bus, perhaps. – Jules Dec 29 '17 at 11:27
  • 1
    Ca. 1985 I remember seeing systems where you could swap different mobos in and out to get a 68k or z80 system. This was with cp/m. – Ben Crowell Dec 30 '17 at 2:47
29

No, there is no simple one-to-one mapping for the pins. (Bolded signal names will be active-low.)

For example, while the 286 has two physical pins for interrupts (INTR and NMI), 68000 has three (IPL0, IPL1 and IPL2), encoding a total of 7 interrupt levels. So the interrupts are handled differently, and also the signaling for acknowledging an interrupt at the hardware level is different.

The 286 also has a concept of I/O address space: a 64 KiB range of addresses that are completely separate from normal memory addresses and must be accessed using separate machine language instructions. On a 68k, you would probably have to map this to some part of the real address space. For extra fun, the M/IO signal used on 286 to tell the regular address space and I/O address space apart is also used when acknowledging an interrupt.

I think you would need quite a bit of extra logic to adapt the signals intended for 286 to suit the inputs of the 68k and the outputs of the 68k to the system designed for 286.

Then there is the matter of different reset behaviours: at reset, the 68k reads two 32-bit values from the very beginning of the address space. The first will be used as the initial stack pointer, and the second as the initial program counter value, i.e. the address where the processor will start executing code. You'll need the system to provide some boot ROM or other meaningful data at these addresses on reset.

On the other hand, the 286 will execute its first instruction after a reset at memory address 00FFFF0h (16 bytes below 1 MiB), just like the grand old 8086 did. And that's where the BIOS ROM is on PCs.

  • 4
    Welcome to Retrocomputing Stack Exchange. Thanks for the great answer; I hope you continue to make such contributions to the site. – wizzwizz4 Dec 29 '17 at 10:34
  • 3
    AbsExecBase is a pointer to the exec library base, no executable code there. The RAM is unmapped at reset and replaced by a shadow copy of the ROM. – Simon Richter Dec 29 '17 at 15:31
  • Looks like my memory is rusty after all these years. Noted. – telcoM Jan 1 '18 at 0:27
16

Most obvious question first: why not puting itn on a ISA Card and take over the bus instead? Given, there would be still some work to be done after asking for DMA and pulling /MASTER, but way less than emulating a totally different CPU protocoll. More like adapting to a weired memory subsystem.

But for your points

First, most obviously, they are completely incompatible at the software level. All 286 code in ROM or on disk would have to be replaced with suitably equivalent 68000 code.

Or add a 286 emulation :)

The packages are different. The 286 is in a square package whereas the 68000 is in a DIP; something would have to be done to physically wire up the replacement chip.

Standard way would be a daughterboard anyway.

The pins are in different positions, but do they have functional equivalents? Connecting e.g. D4 on one chip to where D4 on the other was connected, would be straightforward enough, but are there pins in one that don't have an equivalent in the other?

More important, the bus protocoll is different. It will take quite some glue logic to fully emulate the Intel bus.

x86 is little-endian and 68k is big-endian. Does that matter, once you've replaced the software?

Not realy. There aren't many 16 bit ports. Beside, swaping low and hi-byte on the daughter board could solve this. But since all I/O software has to be rewritten anyway, this isn't a big deal.

Let's say for the sake of argument we are talking about 8 MHz clock speed in both cases, so that shouldn't be an issue.

Clock speed will be your least concern. It's not possible to simple tie a 68k bus to an x86 system and expect the same behaviour. Where the 68k uses AS, R/W and TACK, the 286 hardware wants to see the bus status signals S0/S1, COD/INTR and M/IO (not to mention HOLD and HOLDA and several other) Thats why every 80286 (usually) got a 82288bus controller attached. The 82288 again generated ALE, RD, WR which again are nothing the 68k generates - but the bus expects. Did I already mention the 82284 for READY, SRDY and ARDY?

What else am I missing?

What about that the 80286 got an additional I/O address space of 64 KiB? Where you want to put them within the 24 Bit 68k Address space without giving up access to some of the 80286 address space?

I don't say it's not doable, but it's definitely not just wiring up some signals - it's stitching two different components together to make them work - system design as an art form.


P.S.: This question is a bit like someone asking "To use a CPAN module in Visual Basic, wouldn't that just require aligning the parameter fields?"

  • 2
    "Beside, swaping low and hi-byte on the daughter board could solve this." It really isn't that simple. I used to design 680x0-based motherboards for Apollo Computer, some of which had an ISA-compatible expansion bus that could accept cards designed for PCs. The byte-swapping logic ends up being moderately complex, because whether you need to swap or not depends on whether you're transferring bytes or words. – Dave Tweed Jan 18 '18 at 20:30
  • I have a 68EC040 card for ISA-Bus PCs that does exactly that: qlwiki.qlforum.co.uk/doku.php?id=qlwiki:qxl_card – tofro Aug 1 '18 at 10:43
  • @tofro Nice, that's one I'm still looking to find. Let allone to dissect the communication and make it working ain true parallel. – Raffzahn Aug 1 '18 at 10:58
1

There were 80286 and 68000 MultiBus system boards. At the bus level they could be interchanged.

  • 4
    Yes, but all such bus architectures had multiple processor cards available. That was largely the point of them. Each card however could not have its processor changed for a different architecture. So this doesn't really address the question. – Chenmunka Aug 1 '18 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.