Forum unknown
· Hardware
#68030
29 messages in this thread
I just read an article on the 68030 in the latest EE Times. The main
differences are the on chip MMU, and a data cache in addition to the
instruction cache of the 68020. The MMU allows mapping without the >= 1
cycle delay of external MMU's. It is equivalent to one of the existing
Motorola MMU chips (68851?). The OLT blurb was misleading on dates. Next
spring is for first silicon with samples available in the summer. The
writer citing past experience thinks actual date for samples will be over a
year from now after allowing for usual slippages.
So the MMU supports protection and virtual memory (demand paging, etc.)?
Or just some sort of address remapping? Too bad the '386 precedes the '030
by so much. Just like the 8088 before the 68000, which lead to the whole
Intel dominance mess… – Bela
Bela– Here is some more info on the 68030.
The new stuff for the 68030 includes: data cache as well as the 68020's
instruction cache, built in MMU that is program compatible with the 68851,
and an enhanced bus controller. The data cache works the same as the 020's
instruction cache with the addition of data write through for writes. The
MMU is a paged MMU with the same functionality of the 68851 but without the
1 cycle or so speed penalty you get with the seperate 68851 chip. The bus
controller can support a burst mode that works with DRAMs out now that have
a nibble mode. They give the first data in normal access time but then can
hand over up to 3 more bits from sequential addresses using the chip's
nibble mode. At max bus speed the 030 can fetch 16 bytes in 5 clock cycles
(200ns). This is used to advantage for cache misses to catch up and get
ahead of cpu again. Memory accesses go in parallel to the MMU and the
caches. If the cache hits the MMU memory access is aborted. The CPU can
simultaneously calculate the effective addresses of a data operand and the
next program stream fetch, as well as execute a data manipulation operation
in the ALU. At the same time the CPU may also be fetching a data operand
fom the data cache and an instruction word from the instruction cache. All
five of these events plus a bus interface unit write to external memory may
occur at the same time. The only time the MMU causes any time delay is if
it fails to hit the paging cache. (they predict 99% hit ratio for typical
operation). All of this from a Motorola article in Oct 1 Electronic
Products mag. They quote samples available now for $350 with production
quantities in the spring. I don't know whether to believe this or the EE
Times article on schedule.
That sounds good. By nybble mode, do you mean the "page mode" that the
Programmer's Journal guys are always talking about? From my vauge
hardware-level understanding, standard dynamic RAM chips are accessed by
feeding them seperate row and column addresses, then retrieving the data.
"Page mode" RAMs let you give them a row address, then repeatedly give them
column addresses and retrieve data, until you need data from a different
row. (I may have rows & columns reversed…) Anyway, this greatly improves
the speed because setting whichever of the two addresses that's eliminated
is a costly operation. Or something like that. Is that what the '030
supports? Do you have a quick description of the 68851? I don't know
anything about it, that's why I was asking what the MMU does. I suppose I
could find a data sheet somewhere, but you are surely more
understandable… <grin> I still think that the 68020 and the 80386,
running at the same clock speed, are of very similar power. The '386 isn't
trailing the '020 by that much in terms of release time. It's possible
that in a year, a significant portion of engineering workstations will be
using '386s simply because they're cheaper (price dragged down by the PC
arena, where 100s of Ks of '386s will be used as fast 8088s). Or maybe a
debugged 32532 will suddenly appear (hah). (Come to think of it, I don't
know why Intel doesn't forget all this new crud and just come out with a
simple 8086 that runs FAST… faster than the '386 emulating one, because
that's its whole job. I guess that's up to NEC…) Oh, BTW (from the
ancient past)… I'm still using the version of DIFF that I got from you
(with a few insignificant modifications). Thanks! – Bela
If you have access to a Usenet node, look in net.micro.68k for a set of
benchmarks run by the University of Rochester comparing the 68xxx family
with the 80xxx family. It shows relative performance for several
benchmarks (the ones from EDN) written in assembly for each processor. In
each benchmark, the fastest cpu was rated 1.0. The only benchmark that the
80386 outperformed the 68020 (with cache enabled) was the string
manipulation benchmark. In that one the 80386 was 1.00 and the 68020 rated
1.02. In all the rest (bit manipulation, indirect addressing, qsort, etc)
the 68020 rated 1.00 to the 80386's 2.nn or greater! The overall average
showed the 68020 at 1.02 and the 80386 at 1.89. Timings in seconds were
also posted but I don't have them handy. If anyone is interested I can
upload the article. Rick Schaeffer
If you have access to a Usenet node, look in net.micro.68k for a set of
benchmarks run by the University of Rochester comparing the 68xxx family
with the 80xxx family. It shows relative performance for several
benchmarks (the ones from EDN) written in assembly for each processor. In
each benchmark, the fastest cpu was rated 1.0. The only benchmark that the
80386 outperformed the 68020 (with cache enabled) was the string
manipulation benchmark. In that one the 80386 was 1.00 and the 68020 rated
1.02. In all the rest (bit manipulation, indirect addressing, qsort, etc)
the 68020 rated 1.00 to the 80386's 2.nn or greater! The overall average
showed the 68020 at 1.02 and the 80386 at 1.89. Timings in seconds were
also posted but I don't have them handy. If anyone is interested I can
upload the article. Rick Schaeffer
If you have access to a Usenet node, look in net.micro.68k for a set of
benchmarks run by the University of Rochester comparing the 68xxx family
with the 80xxx family. It shows relative performance for several
benchmarks (the ones from EDN) written in assembly for each processor. In
each benchmark, the fastest cpu was rated 1.0. The only benchmark that the
80386 outperformed the 68020 (with cache enabled) was the string
manipulation benchmark. In that one the 80386 was 1.00 and the 68020 rated
1.02. In all the rest (bit manipulation, indirect addressing, qsort, etc)
the 68020 rated 1.00 to the 80386's 2.nn or greater! The overall average
showed the 68020 at 1.02 and the 80386 at 1.89. Timings in seconds were
also posted but I don't have them handy. If anyone is interested I can
upload the article. Rick Schaeffer
If you have access to a Usenet node, look in net.micro.68k for a set of
benchmarks run by the University of Rochester comparing the 68xxx family
with the 80xxx family. It shows relative performance for several
benchmarks (the ones from EDN) written in assembly for each processor. In
each benchmark, the fastest cpu was rated 1.0. The only benchmark that the
80386 outperformed the 68020 (with cache enabled) was the string
manipulation benchmark. In that one the 80386 was 1.00 and the 68020 rated
1.02. In all the rest (bit manipulation, indirect addressing, qsort, etc)
the 68020 rated 1.00 to the 80386's 2.nn or greater! The overall average
showed the 68020 at 1.02 and the 80386 at 1.89. Timings in seconds were
also posted but I don't have them handy. If anyone is interested I can
upload the article. Rick Schaeffer
Yes, the DRAM nibble mode supported is as you described. I don't have a
data sheet on the 68851. Perhaps I'll call Motorola office here to get one
as I'm curious too what it looks like.
My reasoning on the relative speeds of the 68020 and 286/386 is… From
various comparisons I've done the 286 and 68000 seem to be about the same
speed for equal clocks. ie my 12Mhz 68K is 2x a 6Mhz 286. The 386 takes the
same nb of clocks as a 286 for instructions that are the same between the
two. Any speed up comes from the faster 386 clock (16Mhz) and better code
possible due to 32 bit ops and additional address modes. An overall gain of
2-3 would be as much as I'd expect between 286 & 386 and I don't believe
Intel claims much more than this anyway.
The 68020 takes a lot fewer clock cycles than a 68000 in most cases. For
example, the 4 instructions for the loop in the code contest loop takes 42
cycles on 68000 and 27 (cache case) on 020. This is for garden variety
move, add, dbra ops. Others have much greater differences such as muls
(70/27) and divs (158/44). Several 20Mhz 0 wait state VME bus 020 boards
are available and I just saw a Plessey ad for a 25Mhz 0 wait board. Factor
in the higher clock speed of the 020 as well as the 020's new instructions
and addressing modes and it runs MUCH faster (~4x) than a 68000 and a 286
and still somewhat faster than a 386. For floating point the 68881 is a lot
faster than the 287. I don't know if there is a 387 yet or how fast it is.
I've seen no claims on the ratio between the 020 & 030 but it must be non
trivial given the new cache and bus interface.
I don't remember exact dates but the 68020 has been available in qty for
8-12 months longer than the 387. A long time in this business. It's been
less than 2 years since I sent you the DIFF program.
A coworker suggests that as soon as someone makes an 030 board to plug into
a 020 socket that I get the CSA 020 upgrade for my 68000 and then plug the
030 upgrade into that! That would make the old Amiga move right along. 🙂
Yes, the DRAM nibble mode supported is as you described. I don't have a
data sheet on the 68851. Perhaps I'll call Motorola office here to get one
as I'm curious too what it looks like.
My reasoning on the relative speeds of the 68020 and 286/386 is… From
various comparisons I've done the 286 and 68000 seem to be about the same
speed for equal clocks. ie my 12Mhz 68K is 2x a 6Mhz 286. The 386 takes the
same nb of clocks as a 286 for instructions that are the same between the
two. Any speed up comes from the faster 386 clock (16Mhz) and better code
possible due to 32 bit ops and additional address modes. An overall gain of
2-3 would be as much as I'd expect between 286 & 386 and I don't believe
Intel claims much more than this anyway.
The 68020 takes a lot fewer clock cycles than a 68000 in most cases. For
example, the 4 instructions for the loop in the code contest loop takes 42
cycles on 68000 and 27 (cache case) on 020. This is for garden variety
move, add, dbra ops. Others have much greater differences such as muls
(70/27) and divs (158/44). Several 20Mhz 0 wait state VME bus 020 boards
are available and I just saw a Plessey ad for a 25Mhz 0 wait board. Factor
in the higher clock speed of the 020 as well as the 020's new instructions
and addressing modes and it runs MUCH faster (~4x) than a 68000 and a 286
and still somewhat faster than a 386. For floating point the 68881 is a lot
faster than the 287. I don't know if there is a 387 yet or how fast it is.
I've seen no claims on the ratio between the 020 & 030 but it must be non
trivial given the new cache and bus interface.
I don't remember exact dates but the 68020 has been available in qty for
8-12 months longer than the 387. A long time in this business. It's been
less than 2 years since I sent you the DIFF program.
A coworker suggests that as soon as someone makes an 030 board to plug into
a 020 socket that I get the CSA 020 upgrade for my 68000 and then plug the
030 upgrade into that! That would make the old Amiga move right along. 🙂
Yes, the DRAM nibble mode supported is as you described. I don't have a
data sheet on the 68851. Perhaps I'll call Motorola office here to get one
as I'm curious too what it looks like.
My reasoning on the relative speeds of the 68020 and 286/386 is… From
various comparisons I've done the 286 and 68000 seem to be about the same
speed for equal clocks. ie my 12Mhz 68K is 2x a 6Mhz 286. The 386 takes the
same nb of clocks as a 286 for instructions that are the same between the
two. Any speed up comes from the faster 386 clock (16Mhz) and better code
possible due to 32 bit ops and additional address modes. An overall gain of
2-3 would be as much as I'd expect between 286 & 386 and I don't believe
Intel claims much more than this anyway.
The 68020 takes a lot fewer clock cycles than a 68000 in most cases. For
example, the 4 instructions for the loop in the code contest loop takes 42
cycles on 68000 and 27 (cache case) on 020. This is for garden variety
move, add, dbra ops. Others have much greater differences such as muls
(70/27) and divs (158/44). Several 20Mhz 0 wait state VME bus 020 boards
are available and I just saw a Plessey ad for a 25Mhz 0 wait board. Factor
in the higher clock speed of the 020 as well as the 020's new instructions
and addressing modes and it runs MUCH faster (~4x) than a 68000 and a 286
and still somewhat faster than a 386. For floating point the 68881 is a lot
faster than the 287. I don't know if there is a 387 yet or how fast it is.
I've seen no claims on the ratio between the 020 & 030 but it must be non
trivial given the new cache and bus interface.
I don't remember exact dates but the 68020 has been available in qty for
8-12 months longer than the 387. A long time in this business. It's been
less than 2 years since I sent you the DIFF program.
A coworker suggests that as soon as someone makes an 030 board to plug into
a 020 socket that I get the CSA 020 upgrade for my 68000 and then plug the
030 upgrade into that! That would make the old Amiga move right along. 🙂
Yes, the DRAM nibble mode supported is as you described. I don't have a
data sheet on the 68851. Perhaps I'll call Motorola office here to get one
as I'm curious too what it looks like.
My reasoning on the relative speeds of the 68020 and 286/386 is… From
various comparisons I've done the 286 and 68000 seem to be about the same
speed for equal clocks. ie my 12Mhz 68K is 2x a 6Mhz 286. The 386 takes the
same nb of clocks as a 286 for instructions that are the same between the
two. Any speed up comes from the faster 386 clock (16Mhz) and better code
possible due to 32 bit ops and additional address modes. An overall gain of
2-3 would be as much as I'd expect between 286 & 386 and I don't believe
Intel claims much more than this anyway.
The 68020 takes a lot fewer clock cycles than a 68000 in most cases. For
example, the 4 instructions for the loop in the code contest loop takes 42
cycles on 68000 and 27 (cache case) on 020. This is for garden variety
move, add, dbra ops. Others have much greater differences such as muls
(70/27) and divs (158/44). Several 20Mhz 0 wait state VME bus 020 boards
are available and I just saw a Plessey ad for a 25Mhz 0 wait board. Factor
in the higher clock speed of the 020 as well as the 020's new instructions
and addressing modes and it runs MUCH faster (~4x) than a 68000 and a 286
and still somewhat faster than a 386. For floating point the 68881 is a lot
faster than the 287. I don't know if there is a 387 yet or how fast it is.
I've seen no claims on the ratio between the 020 & 030 but it must be non
trivial given the new cache and bus interface.
I don't remember exact dates but the 68020 has been available in qty for
8-12 months longer than the 387. A long time in this business. It's been
less than 2 years since I sent you the DIFF program.
A coworker suggests that as soon as someone makes an 030 board to plug into
a 020 socket that I get the CSA 020 upgrade for my 68000 and then plug the
030 upgrade into that! That would make the old Amiga move right along. 🙂
That sounds good. By nybble mode, do you mean the "page mode" that the
Programmer's Journal guys are always talking about? From my vauge
hardware-level understanding, standard dynamic RAM chips are accessed by
feeding them seperate row and column addresses, then retrieving the data.
"Page mode" RAMs let you give them a row address, then repeatedly give them
column addresses and retrieve data, until you need data from a different
row. (I may have rows & columns reversed…) Anyway, this greatly improves
the speed because setting whichever of the two addresses that's eliminated
is a costly operation. Or something like that. Is that what the '030
supports? Do you have a quick description of the 68851? I don't know
anything about it, that's why I was asking what the MMU does. I suppose I
could find a data sheet somewhere, but you are surely more
understandable… <grin> I still think that the 68020 and the 80386,
running at the same clock speed, are of very similar power. The '386 isn't
trailing the '020 by that much in terms of release time. It's possible
that in a year, a significant portion of engineering workstations will be
using '386s simply because they're cheaper (price dragged down by the PC
arena, where 100s of Ks of '386s will be used as fast 8088s). Or maybe a
debugged 32532 will suddenly appear (hah). (Come to think of it, I don't
know why Intel doesn't forget all this new crud and just come out with a
simple 8086 that runs FAST… faster than the '386 emulating one, because
that's its whole job. I guess that's up to NEC…) Oh, BTW (from the
ancient past)… I'm still using the version of DIFF that I got from you
(with a few insignificant modifications). Thanks! – Bela
That sounds good. By nybble mode, do you mean the "page mode" that the
Programmer's Journal guys are always talking about? From my vauge
hardware-level understanding, standard dynamic RAM chips are accessed by
feeding them seperate row and column addresses, then retrieving the data.
"Page mode" RAMs let you give them a row address, then repeatedly give them
column addresses and retrieve data, until you need data from a different
row. (I may have rows & columns reversed…) Anyway, this greatly improves
the speed because setting whichever of the two addresses that's eliminated
is a costly operation. Or something like that. Is that what the '030
supports? Do you have a quick description of the 68851? I don't know
anything about it, that's why I was asking what the MMU does. I suppose I
could find a data sheet somewhere, but you are surely more
understandable… <grin> I still think that the 68020 and the 80386,
running at the same clock speed, are of very similar power. The '386 isn't
trailing the '020 by that much in terms of release time. It's possible
that in a year, a significant portion of engineering workstations will be
using '386s simply because they're cheaper (price dragged down by the PC
arena, where 100s of Ks of '386s will be used as fast 8088s). Or maybe a
debugged 32532 will suddenly appear (hah). (Come to think of it, I don't
know why Intel doesn't forget all this new crud and just come out with a
simple 8086 that runs FAST… faster than the '386 emulating one, because
that's its whole job. I guess that's up to NEC…) Oh, BTW (from the
ancient past)… I'm still using the version of DIFF that I got from you
(with a few insignificant modifications). Thanks! – Bela
That sounds good. By nybble mode, do you mean the "page mode" that the
Programmer's Journal guys are always talking about? From my vauge
hardware-level understanding, standard dynamic RAM chips are accessed by
feeding them seperate row and column addresses, then retrieving the data.
"Page mode" RAMs let you give them a row address, then repeatedly give them
column addresses and retrieve data, until you need data from a different
row. (I may have rows & columns reversed…) Anyway, this greatly improves
the speed because setting whichever of the two addresses that's eliminated
is a costly operation. Or something like that. Is that what the '030
supports? Do you have a quick description of the 68851? I don't know
anything about it, that's why I was asking what the MMU does. I suppose I
could find a data sheet somewhere, but you are surely more
understandable… <grin> I still think that the 68020 and the 80386,
running at the same clock speed, are of very similar power. The '386 isn't
trailing the '020 by that much in terms of release time. It's possible
that in a year, a significant portion of engineering workstations will be
using '386s simply because they're cheaper (price dragged down by the PC
arena, where 100s of Ks of '386s will be used as fast 8088s). Or maybe a
debugged 32532 will suddenly appear (hah). (Come to think of it, I don't
know why Intel doesn't forget all this new crud and just come out with a
simple 8086 that runs FAST… faster than the '386 emulating one, because
that's its whole job. I guess that's up to NEC…) Oh, BTW (from the
ancient past)… I'm still using the version of DIFF that I got from you
(with a few insignificant modifications). Thanks! – Bela
PS: people >are< starting to use '286 protected mode, and I've seen one
group port a '286 UNIX to the '386 in two weeks. That's not to say that
it's ready for market, but they didn't have any trouble getting it to
function… – Bela
PS: people >are< starting to use '286 protected mode, and I've seen one
group port a '286 UNIX to the '386 in two weeks. That's not to say that
it's ready for market, but they didn't have any trouble getting it to
function… – Bela
PS: people >are< starting to use '286 protected mode, and I've seen one
group port a '286 UNIX to the '386 in two weeks. That's not to say that
it's ready for market, but they didn't have any trouble getting it to
function… – Bela
PS: people >are< starting to use '286 protected mode, and I've seen one
group port a '286 UNIX to the '386 in two weeks. That's not to say that
it's ready for market, but they didn't have any trouble getting it to
function… – Bela
Bela– Here is some more info on the 68030.
The new stuff for the 68030 includes: data cache as well as the 68020's
instruction cache, built in MMU that is program compatible with the 68851,
and an enhanced bus controller. The data cache works the same as the 020's
instruction cache with the addition of data write through for writes. The
MMU is a paged MMU with the same functionality of the 68851 but without the
1 cycle or so speed penalty you get with the seperate 68851 chip. The bus
controller can support a burst mode that works with DRAMs out now that have
a nibble mode. They give the first data in normal access time but then can
hand over up to 3 more bits from sequential addresses using the chip's
nibble mode. At max bus speed the 030 can fetch 16 bytes in 5 clock cycles
(200ns). This is used to advantage for cache misses to catch up and get
ahead of cpu again. Memory accesses go in parallel to the MMU and the
caches. If the cache hits the MMU memory access is aborted. The CPU can
simultaneously calculate the effective addresses of a data operand and the
next program stream fetch, as well as execute a data manipulation operation
in the ALU. At the same time the CPU may also be fetching a data operand
fom the data cache and an instruction word from the instruction cache. All
five of these events plus a bus interface unit write to external memory may
occur at the same time. The only time the MMU causes any time delay is if
it fails to hit the paging cache. (they predict 99% hit ratio for typical
operation). All of this from a Motorola article in Oct 1 Electronic
Products mag. They quote samples available now for $350 with production
quantities in the spring. I don't know whether to believe this or the EE
Times article on schedule.
Bela– Here is some more info on the 68030.
The new stuff for the 68030 includes: data cache as well as the 68020's
instruction cache, built in MMU that is program compatible with the 68851,
and an enhanced bus controller. The data cache works the same as the 020's
instruction cache with the addition of data write through for writes. The
MMU is a paged MMU with the same functionality of the 68851 but without the
1 cycle or so speed penalty you get with the seperate 68851 chip. The bus
controller can support a burst mode that works with DRAMs out now that have
a nibble mode. They give the first data in normal access time but then can
hand over up to 3 more bits from sequential addresses using the chip's
nibble mode. At max bus speed the 030 can fetch 16 bytes in 5 clock cycles
(200ns). This is used to advantage for cache misses to catch up and get
ahead of cpu again. Memory accesses go in parallel to the MMU and the
caches. If the cache hits the MMU memory access is aborted. The CPU can
simultaneously calculate the effective addresses of a data operand and the
next program stream fetch, as well as execute a data manipulation operation
in the ALU. At the same time the CPU may also be fetching a data operand
fom the data cache and an instruction word from the instruction cache. All
five of these events plus a bus interface unit write to external memory may
occur at the same time. The only time the MMU causes any time delay is if
it fails to hit the paging cache. (they predict 99% hit ratio for typical
operation). All of this from a Motorola article in Oct 1 Electronic
Products mag. They quote samples available now for $350 with production
quantities in the spring. I don't know whether to believe this or the EE
Times article on schedule.
Bela– Here is some more info on the 68030.
The new stuff for the 68030 includes: data cache as well as the 68020's
instruction cache, built in MMU that is program compatible with the 68851,
and an enhanced bus controller. The data cache works the same as the 020's
instruction cache with the addition of data write through for writes. The
MMU is a paged MMU with the same functionality of the 68851 but without the
1 cycle or so speed penalty you get with the seperate 68851 chip. The bus
controller can support a burst mode that works with DRAMs out now that have
a nibble mode. They give the first data in normal access time but then can
hand over up to 3 more bits from sequential addresses using the chip's
nibble mode. At max bus speed the 030 can fetch 16 bytes in 5 clock cycles
(200ns). This is used to advantage for cache misses to catch up and get
ahead of cpu again. Memory accesses go in parallel to the MMU and the
caches. If the cache hits the MMU memory access is aborted. The CPU can
simultaneously calculate the effective addresses of a data operand and the
next program stream fetch, as well as execute a data manipulation operation
in the ALU. At the same time the CPU may also be fetching a data operand
fom the data cache and an instruction word from the instruction cache. All
five of these events plus a bus interface unit write to external memory may
occur at the same time. The only time the MMU causes any time delay is if
it fails to hit the paging cache. (they predict 99% hit ratio for typical
operation). All of this from a Motorola article in Oct 1 Electronic
Products mag. They quote samples available now for $350 with production
quantities in the spring. I don't know whether to believe this or the EE
Times article on schedule.
Your concerns over 386 vs 68030 are somewhat misplaced. It's Intel that is
behind. The 68020 has been out so long that with the current 386 hype
people forget that the comparison is between the 68020 and the almost as
powerful 80386. True the 386 has an MMU and the 020 doesn't but who is
using the protected mode of the 286 let alone the 386. 680xx programmers
have been writing 32 bit software for years with the same architecture.
Intel cpu programmers now have a machine with new registers and
instructions that allows them to finally start writing 32 bit code. As a
side benefit it allows them to run their old 8086, 80286 code as well. In
the MSDOS market Intel is king and due to SW mass is unlikely to be
deposed. In the industrial, workstation, and Unix markets the 68000, and
now the 68020 have an overwhelming lead. Nobody used an 80286 because of
the 64K segments which forced Unix back to PDP-11 modes of operation.
Reading electronics magazines or attending trade shows all you see is VME
bus HW. Multibus I and II are conspicuous by their absence. For quite a
long time now 680×0 and VME bus have been the only 32 bit game in town.
Now that Intel finally has a 32 bit cpu the only 80386 machines I've seen
so far are designed as somewhat faster 80286's which are in turn used as
fast 8086's.
Your concerns over 386 vs 68030 are somewhat misplaced. It's Intel that is
behind. The 68020 has been out so long that with the current 386 hype
people forget that the comparison is between the 68020 and the almost as
powerful 80386. True the 386 has an MMU and the 020 doesn't but who is
using the protected mode of the 286 let alone the 386. 680xx programmers
have been writing 32 bit software for years with the same architecture.
Intel cpu programmers now have a machine with new registers and
instructions that allows them to finally start writing 32 bit code. As a
side benefit it allows them to run their old 8086, 80286 code as well. In
the MSDOS market Intel is king and due to SW mass is unlikely to be
deposed. In the industrial, workstation, and Unix markets the 68000, and
now the 68020 have an overwhelming lead. Nobody used an 80286 because of
the 64K segments which forced Unix back to PDP-11 modes of operation.
Reading electronics magazines or attending trade shows all you see is VME
bus HW. Multibus I and II are conspicuous by their absence. For quite a
long time now 680×0 and VME bus have been the only 32 bit game in town.
Now that Intel finally has a 32 bit cpu the only 80386 machines I've seen
so far are designed as somewhat faster 80286's which are in turn used as
fast 8086's.
Your concerns over 386 vs 68030 are somewhat misplaced. It's Intel that is
behind. The 68020 has been out so long that with the current 386 hype
people forget that the comparison is between the 68020 and the almost as
powerful 80386. True the 386 has an MMU and the 020 doesn't but who is
using the protected mode of the 286 let alone the 386. 680xx programmers
have been writing 32 bit software for years with the same architecture.
Intel cpu programmers now have a machine with new registers and
instructions that allows them to finally start writing 32 bit code. As a
side benefit it allows them to run their old 8086, 80286 code as well. In
the MSDOS market Intel is king and due to SW mass is unlikely to be
deposed. In the industrial, workstation, and Unix markets the 68000, and
now the 68020 have an overwhelming lead. Nobody used an 80286 because of
the 64K segments which forced Unix back to PDP-11 modes of operation.
Reading electronics magazines or attending trade shows all you see is VME
bus HW. Multibus I and II are conspicuous by their absence. For quite a
long time now 680×0 and VME bus have been the only 32 bit game in town.
Now that Intel finally has a 32 bit cpu the only 80386 machines I've seen
so far are designed as somewhat faster 80286's which are in turn used as
fast 8086's.
Your concerns over 386 vs 68030 are somewhat misplaced. It's Intel that is
behind. The 68020 has been out so long that with the current 386 hype
people forget that the comparison is between the 68020 and the almost as
powerful 80386. True the 386 has an MMU and the 020 doesn't but who is
using the protected mode of the 286 let alone the 386. 680xx programmers
have been writing 32 bit software for years with the same architecture.
Intel cpu programmers now have a machine with new registers and
instructions that allows them to finally start writing 32 bit code. As a
side benefit it allows them to run their old 8086, 80286 code as well. In
the MSDOS market Intel is king and due to SW mass is unlikely to be
deposed. In the industrial, workstation, and Unix markets the 68000, and
now the 68020 have an overwhelming lead. Nobody used an 80286 because of
the 64K segments which forced Unix back to PDP-11 modes of operation.
Reading electronics magazines or attending trade shows all you see is VME
bus HW. Multibus I and II are conspicuous by their absence. For quite a
long time now 680×0 and VME bus have been the only 32 bit game in town.
Now that Intel finally has a 32 bit cpu the only 80386 machines I've seen
so far are designed as somewhat faster 80286's which are in turn used as
fast 8086's.
So the MMU supports protection and virtual memory (demand paging, etc.)?
Or just some sort of address remapping? Too bad the '386 precedes the '030
by so much. Just like the 8088 before the 68000, which lead to the whole
Intel dominance mess… – Bela
So the MMU supports protection and virtual memory (demand paging, etc.)?
Or just some sort of address remapping? Too bad the '386 precedes the '030
by so much. Just like the 8088 before the 68000, which lead to the whole
Intel dominance mess… – Bela
So the MMU supports protection and virtual memory (demand paging, etc.)?
Or just some sort of address remapping? Too bad the '386 precedes the '030
by so much. Just like the 8088 before the 68000, which lead to the whole
Intel dominance mess… – Bela