* Re: [TUHS] 68k prototypes & microcode @ 2021-02-13 1:06 Jason Stevens 2021-02-13 2:30 ` Gregg Levine 0 siblings, 1 reply; 29+ messages in thread From: Jason Stevens @ 2021-02-13 1:06 UTC (permalink / raw) To: 'Michael Parson', The Eunuchs Hysterical Society You might find this interesting https://twitter.com/i/status/1320767372853190659 <https://twitter.com/i/status/1320767372853190659> It's a pi (arm) running Musashi a 68000 core, but using voltage buffers it's plugged into the 68000 socket of an Amiga! You can find more info on their github: https://github.com/captain-amygdala/pistorm <https://github.com/captain-amygdala/pistorm> Maybe we are at the point where numerous cheap CPU's can eliminate FPGA's? -----Original Message----- From: Michael Parson [SMTP:mparson@bl.org] Sent: Friday, February 05, 2021 10:43 PM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] 68k prototypes & microcode On 2021-02-04 16:47, Henry Bent wrote: > On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton@gmail.com> wrote: > >> I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, >> and >> I still like it a great deal. Admittedly register-starved (well, >> unless >> you consider the zero page a whole page of registers), but...simple, >> easy >> to fit in your head, kinda wonderful. >> >> I'd love a 64-bit 6502-alike (but I'd probably give it more than three >> registers). I mean given how little silicon (or how few FPGA gates) a >> reasonable version of that would take, might as well include 65C02 and >> 65816 cores in there too with some sort of mode-switching instruction. >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be >> fun? >> Throw in an onboard MMU and FPU too, I suppose, and then you could >> have a >> real system on it. >> >> > Sounds like a perfect project for an FPGA. If there's already a 6502 > implementation out there, converting to 64 bit should be fairly easy. There are FPGA implementations of the 6502 out there. If you've not seen it, check out the MiSTer[0] project, FPGA implementations of a LOT of computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, and 32 bit systems from the 70s and 80s along with gaming consoles from the 70s and 80s. Keeping this semi-TUHS related, one guy[1] has even implemented a Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux, NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of the "official" MiSTer bits (yet?). -- Michael Parson Pflugerville, TX KF5LGQ [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki [1] https://temlib.org/site/ [2] https://temlib.org/pub/mister/SS/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-13 1:06 [TUHS] 68k prototypes & microcode Jason Stevens @ 2021-02-13 2:30 ` Gregg Levine 0 siblings, 0 replies; 29+ messages in thread From: Gregg Levine @ 2021-02-13 2:30 UTC (permalink / raw) To: Jason Stevens, The Eunuchs Hysterical Society An amazing idea. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Fri, Feb 12, 2021 at 7:51 PM Jason Stevens <jsteve@superglobalmegacorp.com> wrote: > > You might find this interesting > > https://twitter.com/i/status/1320767372853190659 > <https://twitter.com/i/status/1320767372853190659> > > It's a pi (arm) running Musashi a 68000 core, but using voltage buffers it's > plugged into the 68000 socket of an Amiga! > > You can find more info on their github: > > https://github.com/captain-amygdala/pistorm > <https://github.com/captain-amygdala/pistorm> > > Maybe we are at the point where numerous cheap CPU's can eliminate FPGA's? > > -----Original Message----- > From: Michael Parson [SMTP:mparson@bl.org] > Sent: Friday, February 05, 2021 10:43 PM > To: The Eunuchs Hysterical Society > Subject: Re: [TUHS] 68k prototypes & microcode > > On 2021-02-04 16:47, Henry Bent wrote: > > On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton@gmail.com> > wrote: > > > >> I'm probably Stockholm Syndrommed about 6502. It's what I grew > up on, > >> and > >> I still like it a great deal. Admittedly register-starved (well, > > >> unless > >> you consider the zero page a whole page of registers), > but...simple, > >> easy > >> to fit in your head, kinda wonderful. > >> > >> I'd love a 64-bit 6502-alike (but I'd probably give it more than > three > >> registers). I mean given how little silicon (or how few FPGA > gates) a > >> reasonable version of that would take, might as well include > 65C02 and > >> 65816 cores in there too with some sort of mode-switching > instruction. > >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus > be > >> fun? > >> Throw in an onboard MMU and FPU too, I suppose, and then you > could > >> have a > >> real system on it. > >> > >> > > Sounds like a perfect project for an FPGA. If there's already a > 6502 > > implementation out there, converting to 64 bit should be fairly > easy. > > There are FPGA implementations of the 6502 out there. If you've not > seen > it, check out the MiSTer[0] project, FPGA implementations of a LOT > of > computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, > and 32 > bit systems from the 70s and 80s along with gaming consoles from the > 70s > and 80s. > > Keeping this semi-TUHS related, one guy[1] has even implemented a > Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux, > NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of > the > "official" MiSTer bits (yet?). > > -- > Michael Parson > Pflugerville, TX > KF5LGQ > > [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki > [1] https://temlib.org/site/ > [2] https://temlib.org/pub/mister/SS/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode @ 2021-02-13 4:34 Jason Stevens 2021-02-13 6:05 ` Toby Thain 0 siblings, 1 reply; 29+ messages in thread From: Jason Stevens @ 2021-02-13 4:34 UTC (permalink / raw) To: 'Gregg Levine', Jason Stevens, The Eunuchs Hysterical Society Apparently they are getting 68040 levels of performance with a Pi... and that interpreted. Going with JIT it's way higher. -----Original Message----- From: Gregg Levine [SMTP:gregg.drwho8@gmail.com] Sent: Saturday, February 13, 2021 10:30 AM To: Jason Stevens; The Eunuchs Hysterical Society Subject: Re: [TUHS] 68k prototypes & microcode An amazing idea. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Fri, Feb 12, 2021 at 7:51 PM Jason Stevens <jsteve@superglobalmegacorp.com> wrote: > > You might find this interesting > > https://twitter.com/i/status/1320767372853190659 > <https://twitter.com/i/status/1320767372853190659> > > It's a pi (arm) running Musashi a 68000 core, but using voltage buffers it's > plugged into the 68000 socket of an Amiga! > > You can find more info on their github: > > https://github.com/captain-amygdala/pistorm > <https://github.com/captain-amygdala/pistorm> > > Maybe we are at the point where numerous cheap CPU's can eliminate FPGA's? > > -----Original Message----- > From: Michael Parson [SMTP:mparson@bl.org] > Sent: Friday, February 05, 2021 10:43 PM > To: The Eunuchs Hysterical Society > Subject: Re: [TUHS] 68k prototypes & microcode > > On 2021-02-04 16:47, Henry Bent wrote: > > On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton@gmail.com> > wrote: > > > >> I'm probably Stockholm Syndrommed about 6502. It's what I grew > up on, > >> and > >> I still like it a great deal. Admittedly register-starved (well, > > >> unless > >> you consider the zero page a whole page of registers), > but...simple, > >> easy > >> to fit in your head, kinda wonderful. > >> > >> I'd love a 64-bit 6502-alike (but I'd probably give it more than > three > >> registers). I mean given how little silicon (or how few FPGA > gates) a > >> reasonable version of that would take, might as well include > 65C02 and > >> 65816 cores in there too with some sort of mode-switching > instruction. > >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus > be > >> fun? > >> Throw in an onboard MMU and FPU too, I suppose, and then you > could > >> have a > >> real system on it. > >> > >> > > Sounds like a perfect project for an FPGA. If there's already a > 6502 > > implementation out there, converting to 64 bit should be fairly > easy. > > There are FPGA implementations of the 6502 out there. If you've not > seen > it, check out the MiSTer[0] project, FPGA implementations of a LOT > of > computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, > and 32 > bit systems from the 70s and 80s along with gaming consoles from the > 70s > and 80s. > > Keeping this semi-TUHS related, one guy[1] has even implemented a > Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux, > NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of > the > "official" MiSTer bits (yet?). > > -- > Michael Parson > Pflugerville, TX > KF5LGQ > > [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki > [1] https://temlib.org/site/ > [2] https://temlib.org/pub/mister/SS/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-13 4:34 Jason Stevens @ 2021-02-13 6:05 ` Toby Thain 0 siblings, 0 replies; 29+ messages in thread From: Toby Thain @ 2021-02-13 6:05 UTC (permalink / raw) To: Jason Stevens, 'Gregg Levine', The Eunuchs Hysterical Society On 2021-02-12 11:34 p.m., Jason Stevens wrote: > Apparently they are getting 68040 levels of performance with a Pi... and > that interpreted. Going with JIT it's way higher. Before we get too breathless, this is roughly what was achieved with a PowerPC 601 emulating 68K ...approximately 28 years ago. --T > > -----Original Message----- > From: Gregg Levine [SMTP:gregg.drwho8@gmail.com] > Sent: Saturday, February 13, 2021 10:30 AM > To: Jason Stevens; The Eunuchs Hysterical Society > Subject: Re: [TUHS] 68k prototypes & microcode > > An amazing idea. > ----- > Gregg C Levine gregg.drwho8@gmail.com > "This signature fought the Time Wars, time and again." > > On Fri, Feb 12, 2021 at 7:51 PM Jason Stevens > <jsteve@superglobalmegacorp.com> wrote: > > > > You might find this interesting > > > > https://twitter.com/i/status/1320767372853190659 > > <https://twitter.com/i/status/1320767372853190659> > > > > It's a pi (arm) running Musashi a 68000 core, but using voltage > buffers it's > > plugged into the 68000 socket of an Amiga! > > > > You can find more info on their github: > > > > https://github.com/captain-amygdala/pistorm > > <https://github.com/captain-amygdala/pistorm> > > > > Maybe we are at the point where numerous cheap CPU's can eliminate > FPGA's? > > > > -----Original Message----- > > From: Michael Parson [SMTP:mparson@bl.org] > > Sent: Friday, February 05, 2021 10:43 PM > > To: The Eunuchs Hysterical Society > > Subject: Re: [TUHS] 68k prototypes & microcode > > > > On 2021-02-04 16:47, Henry Bent wrote: > > > On Thu, Feb 4, 2021, 17:40 Adam Thornton > <athornton@gmail.com> > > wrote: > > > > > >> I'm probably Stockholm Syndrommed about 6502. It's > what I grew > > up on, > > >> and > > >> I still like it a great deal. Admittedly > register-starved (well, > > > > >> unless > > >> you consider the zero page a whole page of registers), > > but...simple, > > >> easy > > >> to fit in your head, kinda wonderful. > > >> > > >> I'd love a 64-bit 6502-alike (but I'd probably give it > more than > > three > > >> registers). I mean given how little silicon (or how > few FPGA > > gates) a > > >> reasonable version of that would take, might as well > include > > 65C02 and > > >> 65816 cores in there too with some sort of > mode-switching > > instruction. > > >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit > address bus > > be > > >> fun? > > >> Throw in an onboard MMU and FPU too, I suppose, and > then you > > could > > >> have a > > >> real system on it. > > >> > > >> > > > Sounds like a perfect project for an FPGA. If there's > already a > > 6502 > > > implementation out there, converting to 64 bit should be > fairly > > easy. > > > > There are FPGA implementations of the 6502 out there. If > you've not > > seen > > it, check out the MiSTer[0] project, FPGA implementations > of a LOT > > of > > computers, going back as far as the EDSAC, PDP-1, a LOT of > 8, 16, > > and 32 > > bit systems from the 70s and 80s along with gaming > consoles from the > > 70s > > and 80s. > > > > Keeping this semi-TUHS related, one guy[1] has even > implemented a > > Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, > 5, Linux, > > NetBSD, and even the Sparc version of NeXTSTEP, but it's > not part of > > the > > "official" MiSTer bits (yet?). > > > > -- > > Michael Parson > > Pflugerville, TX > > KF5LGQ > > > > [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki > > [1] https://temlib.org/site/ > > [2] https://temlib.org/pub/mister/SS/ > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [TUHS] AT&T 3B1 - Emulation available @ 2021-01-29 10:49 Arnold Robbins 2021-02-03 7:53 ` emanuel stiebler 0 siblings, 1 reply; 29+ messages in thread From: Arnold Robbins @ 2021-01-29 10:49 UTC (permalink / raw) To: tuhs Hello All. Many of you may remember the AT&T UNIX PC and 3B1. These systems were built by Convergent Technologies and sold by AT&T. They had an MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS was System V Release 2 vintage. There was a built-in 1200 baud modem, and a primitive windowing system with mouse. I had a 3B1 as my first personal system and spent many happy hours writing code and documentation on it. There is an emulator for it that recently became pretty stable. The original software floppy images are available as well. You can bring up a fairly functional system without much difficulty. The emulator is at https://github.com/philpem/freebee. You can install up to two 175 Meg hard drives - a lot of space for the time. The emulator's README.md there has links to lots of other interesting 3B1 bits, both installable software and Linux tools for exporting the file system from disk image so it can be mounted under Linux and importing it back. Included is an updated 'sysv' Linux kernel module that can handle the byte-swapped file system. I have made a pre-installed disk image available with a fair amount of software, see https://www.skeeve.com/3b1/. The emulator runs great under Linux; not so sure about MacOS or Windows. :-) So, anyone wishing to journey back to 1987, have fun! Arnold ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-01-29 10:49 [TUHS] AT&T 3B1 - Emulation available Arnold Robbins @ 2021-02-03 7:53 ` emanuel stiebler 2021-02-03 7:59 ` arnold 0 siblings, 1 reply; 29+ messages in thread From: emanuel stiebler @ 2021-02-03 7:53 UTC (permalink / raw) To: Arnold Robbins, tuhs On 2021-01-29 05:49, Arnold Robbins wrote: > Hello All. > > I have made a pre-installed disk image available with a fair amount > of software, see https://www.skeeve.com/3b1/. Thanks for doing & making the disk images, was an easy start! Do you remember, ho to set up the system to have four disk drives? Cheers & thanks again! ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-02-03 7:53 ` emanuel stiebler @ 2021-02-03 7:59 ` arnold 2021-02-03 8:53 ` Ed Bradford 0 siblings, 1 reply; 29+ messages in thread From: arnold @ 2021-02-03 7:59 UTC (permalink / raw) To: tuhs, emu, arnold emanuel stiebler <emu@e-bbes.com> wrote: > On 2021-01-29 05:49, Arnold Robbins wrote: > > Hello All. > > > > I have made a pre-installed disk image available with a fair amount > > of software, see https://www.skeeve.com/3b1/. > > Thanks for doing & making the disk images, was an easy start! You're welcome. It's a fun side project. I think I finally get the enjoyment of retrocomputing with emulated versions of systems one used in one's youth. :-) > Do you remember, ho to set up the system to have four disk drives? > > Cheers & thanks again! I don't think it can support more than 2 drives. Certainly the emulator cannot. I don't know about real hardware. You can split a big drive into partitions when formatting with the diagnostics disk, but I don't think that's what you're asking. Sorry, Arnold ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-02-03 7:59 ` arnold @ 2021-02-03 8:53 ` Ed Bradford 2021-02-03 8:58 ` arnold 0 siblings, 1 reply; 29+ messages in thread From: Ed Bradford @ 2021-02-03 8:53 UTC (permalink / raw) To: arnold; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 1355 bytes --] It seems to me today's 2GHz processors should be able to emulate a 3B (*3B or not 3B, that is the question*) at a performance that far exceeds an actual 3B. Is the instruction set definition and architecture of a 3B available anywhere? Just wondering. I did such emulations for 68K machines and Cray machines. Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree. On Wed, Feb 3, 2021 at 2:00 AM <arnold@skeeve.com> wrote: > emanuel stiebler <emu@e-bbes.com> wrote: > > > On 2021-01-29 05:49, Arnold Robbins wrote: > > > Hello All. > > > > > > I have made a pre-installed disk image available with a fair amount > > > of software, see https://www.skeeve.com/3b1/. > > > > Thanks for doing & making the disk images, was an easy start! > > You're welcome. It's a fun side project. I think I finally get the > enjoyment of retrocomputing with emulated versions of systems one > used in one's youth. :-) > > > Do you remember, ho to set up the system to have four disk drives? > > > > Cheers & thanks again! > > I don't think it can support more than 2 drives. Certainly the emulator > cannot. I don't know about real hardware. > > You can split a big drive into partitions when formatting with the > diagnostics disk, but I don't think that's what you're asking. > > Sorry, > > Arnold > -- Advice is judged by results, not by intentions. Cicero [-- Attachment #2: Type: text/html, Size: 2459 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-02-03 8:53 ` Ed Bradford @ 2021-02-03 8:58 ` arnold 2021-02-03 10:13 ` Ed Bradford 0 siblings, 1 reply; 29+ messages in thread From: arnold @ 2021-02-03 8:58 UTC (permalink / raw) To: egbegb2, arnold; +Cc: tuhs The 3B1 had an MC 68010. I don't truly remember how fast the real system ran. The emulated system seems to run more or less the same as the hardware did, taking my poor memory into account. The 5620 used the same processor as the 3B2, IIRC. There are emulators for both (maybe done by the same guy, I don't remember). I don't know of emulators for the 3B5 or 3B20. Arnold Ed Bradford <egbegb2@gmail.com> wrote: > It seems to me today's 2GHz processors should be able to emulate a 3B (*3B > or not 3B, that is the question*) at a performance that far exceeds an > actual 3B. Is the instruction set definition and architecture of a 3B > available anywhere? > > Just wondering. I did such emulations for 68K machines and Cray machines. > > Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree. > > > On Wed, Feb 3, 2021 at 2:00 AM <arnold@skeeve.com> wrote: > > > emanuel stiebler <emu@e-bbes.com> wrote: > > > > > On 2021-01-29 05:49, Arnold Robbins wrote: > > > > Hello All. > > > > > > > > I have made a pre-installed disk image available with a fair amount > > > > of software, see https://www.skeeve.com/3b1/. > > > > > > Thanks for doing & making the disk images, was an easy start! > > > > You're welcome. It's a fun side project. I think I finally get the > > enjoyment of retrocomputing with emulated versions of systems one > > used in one's youth. :-) > > > > > Do you remember, ho to set up the system to have four disk drives? > > > > > > Cheers & thanks again! > > > > I don't think it can support more than 2 drives. Certainly the emulator > > cannot. I don't know about real hardware. > > > > You can split a big drive into partitions when formatting with the > > diagnostics disk, but I don't think that's what you're asking. > > > > Sorry, > > > > Arnold > > > > > -- > Advice is judged by results, not by intentions. > Cicero ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-02-03 8:58 ` arnold @ 2021-02-03 10:13 ` Ed Bradford 2021-02-03 14:58 ` Clem Cole 0 siblings, 1 reply; 29+ messages in thread From: Ed Bradford @ 2021-02-03 10:13 UTC (permalink / raw) To: arnold; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 3039 bytes --] Hay, Arnold, MC 68K was created in 1980 or thereabouts. We talked about 10's of Megahertz, I think, in those times. I was involved (slightly) with the Zilog Z80,000 which would have competed with the 68K, NS32K and the Intel 80386. Of the instruction sets (architectures) I was most happy with, the Zilog 32-bit processor architecture was to me, the most minimalist and thorough. At the time, I managed software development for the Zilog company's Z8000 computers. It was a fun era. I bought a z8000 system and developed a CRAY simulator on it when I left Zilog and went to work for American Supercomputer Company (another interesting Silicon Valley story). The 1980's were a very interesting time in Silicon Valley. One of the saddest stories I recall is when "Eagle Computer" went public. The CEO died on the IPO day after he had become a very rich person when he crashed a Ferrari during a test drive. Eagle Computer died with the CEO. Ed On Wed, Feb 3, 2021 at 2:59 AM <arnold@skeeve.com> wrote: > The 3B1 had an MC 68010. I don't truly remember how fast the real > system ran. The emulated system seems to run more or less the same as > the hardware did, taking my poor memory into account. > > The 5620 used the same processor as the 3B2, IIRC. There are emulators > for both (maybe done by the same guy, I don't remember). I don't know > of emulators for the 3B5 or 3B20. > > Arnold > > Ed Bradford <egbegb2@gmail.com> wrote: > > > It seems to me today's 2GHz processors should be able to emulate a 3B > (*3B > > or not 3B, that is the question*) at a performance that far exceeds an > > actual 3B. Is the instruction set definition and architecture of a 3B > > available anywhere? > > > > Just wondering. I did such emulations for 68K machines and Cray machines. > > > > Ed Bradford ex-BTL, ex Silcon Valley, and ex IBM retiree. > > > > > > On Wed, Feb 3, 2021 at 2:00 AM <arnold@skeeve.com> wrote: > > > > > emanuel stiebler <emu@e-bbes.com> wrote: > > > > > > > On 2021-01-29 05:49, Arnold Robbins wrote: > > > > > Hello All. > > > > > > > > > > I have made a pre-installed disk image available with a fair amount > > > > > of software, see https://www.skeeve.com/3b1/. > > > > > > > > Thanks for doing & making the disk images, was an easy start! > > > > > > You're welcome. It's a fun side project. I think I finally get the > > > enjoyment of retrocomputing with emulated versions of systems one > > > used in one's youth. :-) > > > > > > > Do you remember, ho to set up the system to have four disk drives? > > > > > > > > Cheers & thanks again! > > > > > > I don't think it can support more than 2 drives. Certainly the emulator > > > cannot. I don't know about real hardware. > > > > > > You can split a big drive into partitions when formatting with the > > > diagnostics disk, but I don't think that's what you're asking. > > > > > > Sorry, > > > > > > Arnold > > > > > > > > > -- > > Advice is judged by results, not by intentions. > > Cicero > -- Advice is judged by results, not by intentions. Cicero [-- Attachment #2: Type: text/html, Size: 5042 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] AT&T 3B1 - Emulation available 2021-02-03 10:13 ` Ed Bradford @ 2021-02-03 14:58 ` Clem Cole 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore 0 siblings, 1 reply; 29+ messages in thread From: Clem Cole @ 2021-02-03 14:58 UTC (permalink / raw) To: Ed Bradford; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] On Wed, Feb 3, 2021 at 5:14 AM Ed Bradford <egbegb2@gmail.com> wrote: > Hay, Arnold, > > MC 68K was created in 1980 or thereabouts. We talked about 10's of > Megahertz, I think, in those times. > The original X series part was originally unnumbered but a sticker was later set for the lids that said X68000 (I had one on my desk - which was used for the Tektronix Magnolia prototype).[1] The X series ran at 8 Mhz, but the original released (distributed - MC68000) part was binned at 8 and 10 as were the later versions with the updated paging microcode called the MC68010 a year later. When the 68020 was released Moto got the speeds up to 16Mhz and later 20. By the '040 I think they were running at 50MHz [1] I think I still have the draft list of issues in my files. There was a halt and catch fire style error you had to be careful about (I've forgotten the details - but if you executed it in supervisor mode, the ucode turned on the address drivers in such a manner that they stopped working after that and the chip was ruined). I only did that once ;-) when we were debugging Magix (the OS for Magnolia) [-- Attachment #2: Type: text/html, Size: 2138 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-03 14:58 ` Clem Cole @ 2021-02-04 0:41 ` John Gilmore 2021-02-04 0:52 ` Al Kossow ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: John Gilmore @ 2021-02-04 0:41 UTC (permalink / raw) To: Clem Cole; +Cc: UNIX Heritage Society Clem Cole <clemc@ccc.com> wrote: > > MC 68K was created in 1980 or thereabouts. Wikimedia Commons has a pic of a 1979 XC68000L: https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg https://en.wikipedia.org/wiki/File:XC68000.agr.jpg After a USENET posting pointed me at them, I browsed the Sunnyvale Patent Library to bring home the patents for the Motorola 68000. They include a full listing of the entire microcode! I ended up copying it, taping the sheets together to reconstitute Nick Tredennick's large-format "hardware flowcharts", and hanging them in the hallway near my office at Sun. Fascinating! I never saw X68000 parts; Sun started in 1981, so Moto had production parts by then. But Sun did get early prototypes of the 68010, which we were very happy for, since we and our customers were running a swapping Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run the BSD UNIX that we were porting from the Vax. Later, I was part of the Sun bringup team using the XC68020. We built a big spider-like daughterboard adapter that would let it be plugged into a 64-pin 68010 socket, so we could debug the 68020 in a Sun-2 CPU board while building 32-bit-wide boards for the Sun-3 bringup. We had it successfully running UNIX within a day of receiving it! (We later heard that our Moto rep was intending to give that precious early part to another customer, but decided during their meeting with us to give it to us, because we were so ready to get it running.) When the 68000 was announced, it was obviously head-and-shoulders better than the other clunky 8-bit and 16-bit systems, with a clean 32-bit architecture and a large address space. It seems like the designers of the other chips (e.g. the 8088) had never actually worked with real computers (mainframes and minicomputers) and kept not-learning from computing history. Some of my early experience was in APL implementation on the IBM 360 series. I knew the 68000 would be a great APL host, since its autoincrement addressing was perfect for implementing vector operations. In the process of designing an APL for it (which was never built), I wrote up a series of short suggestions to Motorola on how to improve the design. This was published in Computer Architecture News. For the 68010 they actually did one of the ideas, the "loop mode" that would detect a 1-instruction backward decrement-and-branch loop, and stop continually re-fetching the two instructions. This made memory-to-memory or register-vs-memory instruction loops run at almost the speed of memory, which was a big improvement for bcopy, bzero, add-up-a-vector-of-integers, etc. I'll append a USENET posting about the 68000 patents, followed by my addendum after visiting the Patent office. John From decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue Mar 15 16:55:28 1983 Subject: 68000: 16 bits. With references Newsgroups: net.micro.68k With due respect to Henry Spencer I feel that I must correct some of his statements regarding the 68000. He is correct in saying that the 68000 is basically 16 bits wide; however, his explanation of the segmented bus is incorrect. The datapath of the 68000 is divided into three pieces, each of which has two busses, address and data, running through it. Six busses total. There are muxes which can be switched so that all address busses are connected and all data busses are connected. The three sections of the datapath are the data section (includes low 16 bits of all data registers and ALU), the "low" section (contains the low 16 bits of address registers and the low half of the Address Adder(AAU)), and the "high" section (contains high 16 bits of all address and data registers and the upper half of the AAU). Theoretically they could do 6 16 bit transfers simultaneously, but in looking through the microcode I don't remember seeing more than three transfers at a time. The "low" and "high" sections can be cascaded to provide a 32 bit arithmetic unit for address calculations. 32 bit data calculations must be done in two passes through the ALU. For the masochists out there, you can learn more than you ever wanted to know about the 68000 by reading Motorola's patents on it. They are available for some nominal fee (~ one dollar) from the Office of Patents and Trademarks in Arlington. The relevant patents are: 1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two Level Control Store for Data Processor", Tredennick, et al. First design of 68000 which was scrapped? 2 - #4,296,469 "Execution Unit for Data Processor using Segmented Bus structure", Gunter, et al. All about the 16 bit data path 3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor", Gunter, et al. Boring. 4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data Processor", Gunter et al. Bonanza! Full of block diagrams and everything you ever wanted to know. Includes complete listing of microcode with Tredennick's "hardware flowcharts". Hope this clears things up. Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056 My [gnu] notes on additional 68000 patents: Pat # Appl # Filed date Issued date Inventors 4,338,661 041,201 May 21, 1979 Jul 6, 1982 Tredennick & Gunter Conditional Branch Unit for Microprogrammed Data Processor 4,342,078 041,202 May 21, 1979 Jul 27, 1982 Tredennick & Gunter Instruction Register Sequence Decoder for Microprogrammed Data Processor and Method 4,312,034 041,203 May 21, 1979 Jan 19, 1982 Gunter, Hobbs, Spak, Tredennick ALU and Condition Code Control Unit for Data Processor 4,325,121 041,135 May 21, 1979 Apr 13, 1982 Gunter, Tredennick Two-Level Control Store for Microprogrammed Data Processor Bonanza! Full of block diagrams and everything you ever wanted to know. Includes complete listing of microcode with Tredennick's "hardware flowcharts". 4,296,469 961,798 Nov 17, 1978 Oct 20, 1981 Gunter, Tredennick, McAlister Execution Unit for Data Processor Using Segmented Bus Structure All about the 16 bit data path 4,348,722 136,845 Apr 3, 1980 Sep 7, 1982 Gunter, Crudele, Zolnowsky, Mothersole Bus Error Recognition for Microprogrammed Data Processor 4,349,873 136,593 Apr 2, 1980 Sep 14, 1982 Gunter, Zolnowsky, Crudele Microprocessor Interrupt Processing 4,524,415 447,721 Dec 7, 1982 Jun 18, 1985 Mills, Moyer, MacGregor, Zolnowsky Virtual Machine Data Processor 68010 changes to 68000 4,348,741 169,558 Jul 17, 1980 Sep 7, 1982 McAlister, Gunter, Spak, Schriber Priority Encoder Used to decode the bit masks for MOVEM. XXXXXXXXX 446,801 Dec 7, 1982 Crudele, Zolnowsky, Moyer, MacGregor Virtual Memory Data Processor XXXXXXXXX 447,600 Dec 7, 1982 MacGregor, Moyer, Mills Jr, Zolnowsky Data Processor Version Validation About how bus errors store a CPU mask version # to prevent their being restarted on a different CPU mask in a multiprocessor system XXXXXXXXX 961,796 Nov 17, 1978 Tredennick et al Microprogrammed Control Apparatus for Data Processor (continued into 4,325,121, probably never issued) XXXXXXXXX 961,797 Nov 17, 1978 McAlister et al Multi-port RAM Structure for Data Processor Registers 4,307,445 961,796 Nov 17, 1978 Tredennick, et al Microprogrammed Control Apparatus Having a Two Level Control Store for Data Processor First design of 68000 which was scrapped? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore @ 2021-02-04 0:52 ` Al Kossow 2021-02-04 1:10 ` Arthur Krewat ` (2 subsequent siblings) 3 siblings, 0 replies; 29+ messages in thread From: Al Kossow @ 2021-02-04 0:52 UTC (permalink / raw) To: tuhs On 2/3/21 4:41 PM, John Gilmore wrote: > Clem Cole <clemc@ccc.com> wrote: >>> MC 68K was created in 1980 or thereabouts. > > Wikimedia Commons has a pic of a 1979 XC68000L: > > https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg > https://en.wikipedia.org/wiki/File:XC68000.agr.jpg > > After a USENET posting pointed me at them, I browsed the Sunnyvale > Patent Library to bring home the patents for the Motorola 68000. They > include a full listing of the entire microcode! I ended up copying it, > taping the sheets together to reconstitute Nick Tredennick's > large-format "hardware flowcharts", and hanging them in the hallway near > my office at Sun. Fascinating! Oliver Galibert's work on re the 68000 https://og.kervella.org/m68k/ http://gendev.spritesmind.net/forum/viewtopic.php?t=3023 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore 2021-02-04 0:52 ` Al Kossow @ 2021-02-04 1:10 ` Arthur Krewat 2021-02-04 1:33 ` Larry McVoy ` (2 more replies) 2021-02-04 1:14 ` Clem Cole 2021-02-04 14:56 ` John Cowan 3 siblings, 3 replies; 29+ messages in thread From: Arthur Krewat @ 2021-02-04 1:10 UTC (permalink / raw) To: tuhs On 2/3/2021 7:41 PM, John Gilmore wrote: > When the 68000 was announced, it was obviously head-and-shoulders better > than the other clunky 8-bit and 16-bit systems, with a clean 32-bit > architecture and a large address space. The 68K always reminded me of the VAX. art k. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:10 ` Arthur Krewat @ 2021-02-04 1:33 ` Larry McVoy 2021-02-04 1:47 ` Al Kossow ` (3 more replies) 2021-02-04 1:35 ` Clem Cole 2021-02-04 2:18 ` Dave Horsfall 2 siblings, 4 replies; 29+ messages in thread From: Larry McVoy @ 2021-02-04 1:33 UTC (permalink / raw) To: Arthur Krewat; +Cc: tuhs On Wed, Feb 03, 2021 at 08:10:58PM -0500, Arthur Krewat wrote: > On 2/3/2021 7:41 PM, John Gilmore wrote: > >When the 68000 was announced, it was obviously head-and-shoulders better > >than the other clunky 8-bit and 16-bit systems, with a clean 32-bit > >architecture and a large address space. > The 68K always reminded me of the VAX. I'm not sure if that is a compliment or not. The NS320XX always reminded me more of the PDP-11 (which is by *far* my favorite assembler, so uniform, I had a TA that could read the octal dump of a PDP-11 like it was C). I wasn't that good but I could sort of see what he was seeing and I never saw that in the VAX. 68K was closer but I felt like the NS320xx was closer yet. Pity they couldn't produce bug free chips. Someone mentioned Z80000, I stopped at Z80 so I don't know if that was also a pleasant ISA. The x86 stuff is about as far away from PDP-11 as you can get. Required to know it, but so unpleasant. I have to admit that I haven't looked at ARM assembler, the M1 is making me rethink that. Anyone have an opinion on where ARM lies in the pleasant to unpleasant scale? --lm who misses comp.arch back when CPU people hung out there ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:33 ` Larry McVoy @ 2021-02-04 1:47 ` Al Kossow 2021-02-04 1:57 ` Al Kossow 2021-02-04 7:23 ` Arno Griffioen ` (2 subsequent siblings) 3 siblings, 1 reply; 29+ messages in thread From: Al Kossow @ 2021-02-04 1:47 UTC (permalink / raw) To: tuhs On 2/3/21 5:33 PM, Larry McVoy wrote: > Anyone have an opinion on where ARM lies in the pleasant > to unpleasant scale? Don't look at how they implemented bit manipulation ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:47 ` Al Kossow @ 2021-02-04 1:57 ` Al Kossow 0 siblings, 0 replies; 29+ messages in thread From: Al Kossow @ 2021-02-04 1:57 UTC (permalink / raw) To: tuhs On 2/3/21 5:47 PM, Al Kossow wrote: > On 2/3/21 5:33 PM, Larry McVoy wrote: >> Anyone have an opinion on where ARM lies in the pleasant >> to unpleasant scale? > > Don't look at how they implemented bit manipulation > https://spin.atomicobject.com/2013/02/08/bit-banding/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:33 ` Larry McVoy 2021-02-04 1:47 ` Al Kossow @ 2021-02-04 7:23 ` Arno Griffioen 2021-02-04 11:28 ` Toby Thain 2021-02-04 15:47 ` Arthur Krewat 2021-02-04 21:55 ` Dave Horsfall 3 siblings, 1 reply; 29+ messages in thread From: Arno Griffioen @ 2021-02-04 7:23 UTC (permalink / raw) To: tuhs On Wed, Feb 03, 2021 at 05:33:56PM -0800, Larry McVoy wrote: > I have to admit that I haven't looked at ARM assembler, the M1 is making > me rethink that. Anyone have an opinion on where ARM lies in the pleasant > to unpleasant scale? 'Different' is what I would call it.. Years ago I did a bunch of assembly hacking on the original ARM2 used in the Archimedes A3000, which was an amazingly fast CPU for the time. The thing that stood out on these CPU's to me, which was wildly different to what I was used to (M68K, 6502, Z80/8080, VAX), was the fact that many instructions were (somewhat) composeable. Aka. you can/could add varuous logical operations like AND, OR, etc. 'into' an instruction like a load or store and it would take the same number of clock cycles to execute it all in 1 go. That was great for doing data manipulation at very high rates for the time compared to the common CISC CPU's as you did not need to go through multiple fetch and modify cycles. Reminiscent of some VLIW setups, but still more 'human readable' :) The original ARM1/2/3 design did have some oddities like status bits being encoded in the top of the (23) address bits, which meant that later versions of the original design had to do some memory tricks to use a bigger address space and keep compatilibity to the original code. I suspect the current common ARM revisions since the move to the StrongARM (ARM4) architecture, when DEC got involved and ARM became a standalone chip design firm, have long fixed those oddities. Probably still retains the way in which it encodes it's instructions to make a lot of common logic operations while shuffling data more efficient though.. Having said that.. (and bringing it more back to TUHS instead of COFF ;) ) The ARM2 and ARM3 based machines could already run UNIX with Acorn selling RISC iX for a short time, which was a 4.3BSD port done in the late 80's and early 90's. Very few of those were ever used/sold though as the Acorn Archimedes series of machines were quite a bit more expensive than more widespread CISC machines. Most were found in the UK and often in universities and the like. Bye, Arno. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 7:23 ` Arno Griffioen @ 2021-02-04 11:28 ` Toby Thain 0 siblings, 0 replies; 29+ messages in thread From: Toby Thain @ 2021-02-04 11:28 UTC (permalink / raw) To: tuhs On 2021-02-04 2:23 a.m., Arno Griffioen wrote: > On Wed, Feb 03, 2021 at 05:33:56PM -0800, Larry McVoy wrote: >> I have to admit that I haven't looked at ARM assembler, the M1 is making >> me rethink that. Anyone have an opinion on where ARM lies in the pleasant >> to unpleasant scale? > > 'Different' is what I would call it.. > > Years ago I did a bunch of assembly hacking on the original ARM2 used in the > Archimedes A3000, which was an amazingly fast CPU for the time. > > The thing that stood out on these CPU's to me, which was wildly different > to what I was used to (M68K, 6502, Z80/8080, VAX), was the fact that > many instructions were (somewhat) composeable. > > Aka. you can/could add varuous logical operations like AND, OR, etc. 'into' an > instruction like a load or store and it would take the same number of clock > cycles to execute it all in 1 go. That is immediately reminiscent of DG Nova, PDP-8 (and to a tiny extent, PowerPC). > > That was great for doing data manipulation at very high rates for the time > compared to the common CISC CPU's as you did not need to go through multiple > fetch and modify cycles. > > Reminiscent of some VLIW setups, but still more 'human readable' :) > > The original ARM1/2/3 design did have some oddities like status bits being > encoded in the top of the (23) address bits, which meant that later versions of > the original design had to do some memory tricks to use a bigger address > space and keep compatilibity to the original code. > > I suspect the current common ARM revisions since the move to the StrongARM > (ARM4) architecture, when DEC got involved and ARM became a standalone chip > design firm, have long fixed those oddities. > > Probably still retains the way in which it encodes it's instructions to make > a lot of common logic operations while shuffling data more efficient though.. ARM MCUs also have the "bit manipulation engine" for a similar goal, I think. --Toby > > Having said that.. (and bringing it more back to TUHS instead of COFF ;) ) > > The ARM2 and ARM3 based machines could already run UNIX with Acorn selling > RISC iX for a short time, which was a 4.3BSD port done in the late 80's > and early 90's. > > Very few of those were ever used/sold though as the Acorn Archimedes series > of machines were quite a bit more expensive than more widespread CISC machines. > Most were found in the UK and often in universities and the like. > > Bye, Arno. > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:33 ` Larry McVoy 2021-02-04 1:47 ` Al Kossow 2021-02-04 7:23 ` Arno Griffioen @ 2021-02-04 15:47 ` Arthur Krewat 2021-02-04 16:03 ` emanuel stiebler 2021-02-04 21:55 ` Dave Horsfall 3 siblings, 1 reply; 29+ messages in thread From: Arthur Krewat @ 2021-02-04 15:47 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1007 bytes --] On 2/3/2021 8:33 PM, Larry McVoy wrote: >> The 68K always reminded me of the VAX. > I'm not sure if that is a compliment or not. Neither, more of an observation than anything. Post/pre decrement/increment, 32-bit everything, it was an easy move, mentally, from VAX to 68K. I cut my teeth on a PDP-10, but also VAX, and a sprinkling of microprocessors such as the 8080, Z80, 6502 and of course, 8088/86. Back around the mid 80's, a friend and I built a 68020 prototype computer from spare parts, all wire-wrapped, fast static RAM (it was free), and I wrote a cross-assembler in C (on a 80386 PC) and we went to town. And then, as they say, life happened. It was much easier to get access to, or take home, powerful enough computers that we didn't need to build our own. My friend still has the thing. I still have the cross-assembler too, but sadly no actual code I wrote at the time. It would have been worth a laugh or two ;) I still have a Sun 3/280 laying around here somewhere... art k. [-- Attachment #2: Type: text/html, Size: 1518 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 15:47 ` Arthur Krewat @ 2021-02-04 16:03 ` emanuel stiebler 0 siblings, 0 replies; 29+ messages in thread From: emanuel stiebler @ 2021-02-04 16:03 UTC (permalink / raw) To: Arthur Krewat, Larry McVoy; +Cc: tuhs On 2021-02-04 10:47, Arthur Krewat wrote: > Post/pre decrement/increment, 32-bit everything, it was an easy move, > mentally, from VAX to 68K. I worked with 11s and VAX at this time the 68k came out, and as a student, the 68k was the only way to get a decent machine for less. And it really felt like the real thing ... ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:33 ` Larry McVoy ` (2 preceding siblings ...) 2021-02-04 15:47 ` Arthur Krewat @ 2021-02-04 21:55 ` Dave Horsfall 2021-02-04 22:11 ` Steve Nickolas 3 siblings, 1 reply; 29+ messages in thread From: Dave Horsfall @ 2021-02-04 21:55 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 3 Feb 2021, Larry McVoy wrote: >> The 68K always reminded me of the VAX. > > I'm not sure if that is a compliment or not. The 68K was fairly clean; the VAX not so much... I got the impression that it was designed by a committee i.e. everybody wanted to have their own instruction/feature, and it showed. I do admit though that paging the page tables was a stroke of genius. > The NS320XX always reminded me more of the PDP-11 (which is by *far* > my favorite assembler, so uniform, I had a TA that could read the octal > dump of a PDP-11 like it was C). I wasn't that good but I could sort of > see what he was seeing and I never saw that in the VAX. 68K was closer > but I felt like the NS320xx was closer yet. Pity they couldn't produce > bug free chips. I used to be a whiz on the 360 :-) As part of our final CompSci exams we had to hand-assemble and disassemble some code, and I hardly ever referred to the "green card". > Someone mentioned Z80000, I stopped at Z80 so I don't know if that was > also a pleasant ISA. The Z80 was quite nice; I wrote heaps of programs for it, and I even found an ANSI C Compiler for it (Hi-Tech as I recall; BDS-C was, well, you could barely call it "C")[*]. I compiled a number of Unix programs... > The x86 stuff is about as far away from PDP-11 as you can get. Required > to know it, but so unpleasant. The x86 architecture is utterly brain-dead; I mean, what's wrong with a linear address space? I think it was JohnG who said "segment registers are for worms". > I have to admit that I haven't looked at ARM assembler, the M1 is making > me rethink that. Anyone have an opinion on where ARM lies in the pleasant > to unpleasant scale? I've been looking at the ARM; it seems quite nice at first glance. > --lm who misses comp.arch back when CPU people hung out there Indeed. I gave up on USENET when the joint got flooded by spammers; I still have my "cancel" script somewhere. [*] I think it was Henry Spencer who said (in an unrelated matter): "Somehow to be called a C compiler, I think it ought at least be able to compile C". -- Dave, who ran aus.radio.amateur.* ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 21:55 ` Dave Horsfall @ 2021-02-04 22:11 ` Steve Nickolas 2021-02-04 22:39 ` Adam Thornton 2021-02-04 22:56 ` Richard Salz 0 siblings, 2 replies; 29+ messages in thread From: Steve Nickolas @ 2021-02-04 22:11 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 5 Feb 2021, Dave Horsfall wrote: > The Z80 was quite nice; I wrote heaps of programs for it, and I even found an > ANSI C Compiler for it (Hi-Tech as I recall; BDS-C was, well, you could > barely call it "C")[*]. I compiled a number of Unix programs... Well, it *was* "Braindead Software" C. <snip> > The x86 architecture is utterly brain-dead; I mean, what's wrong with a > linear address space? I think it was JohnG who said "segment registers > are for worms". The 65816 doesn't have the screwed-up bitshifted segment stuff but it's also a segmented architecture and is also braindead. And I'm a 65C02 fan. -uso. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 22:11 ` Steve Nickolas @ 2021-02-04 22:39 ` Adam Thornton 2021-02-04 22:47 ` Henry Bent 2021-02-04 22:56 ` Richard Salz 1 sibling, 1 reply; 29+ messages in thread From: Adam Thornton @ 2021-02-04 22:39 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2505 bytes --] I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, and I still like it a great deal. Admittedly register-starved (well, unless you consider the zero page a whole page of registers), but...simple, easy to fit in your head, kinda wonderful. I'd love a 64-bit 6502-alike (but I'd probably give it more than three registers). I mean given how little silicon (or how few FPGA gates) a reasonable version of that would take, might as well include 65C02 and 65816 cores in there too with some sort of mode-switching instruction. Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be fun? Throw in an onboard MMU and FPU too, I suppose, and then you could have a real system on it. 32-bit SPARC was kind of fun and felt kind of like 6502. The 6502 wasn't exactly RISCy...but when working with RISC architectures, understanding the 6502 seemed to be helpful. I really liked the 68000, but in a different way. It's a nice, regular, easy-to-understand instruction set without many surprises, and felt to me like it had plenty of registers. Once the 68030 brought the MMU onboard it was glorious. Post-370 (which is to say 390/z IBM mainframe architectures) went wild with microprogrammed crazy baroque very, very special purpose instructions. Which, I mean, OK, cool, I guess, but not elegant. I don't really know enough about the DEC architectures. It is my strong impression that the PDP-11 is regular, simple to understand, and rather delightful (like I find the 68000), while VAX gets super-baroque like later IBM mainframe instruction sets. Although I've worked with emulated 10s, 11s, and VAXen, I've never really done anything in assembly (sure, you can argue that C is the best PDP-11 preprocessor there is) on them. On Thu, Feb 4, 2021 at 3:12 PM Steve Nickolas <usotsuki@buric.co> wrote: > On Fri, 5 Feb 2021, Dave Horsfall wrote: > > > The Z80 was quite nice; I wrote heaps of programs for it, and I even > found an > > ANSI C Compiler for it (Hi-Tech as I recall; BDS-C was, well, you could > > barely call it "C")[*]. I compiled a number of Unix programs... > > Well, it *was* "Braindead Software" C. > > <snip> > > > The x86 architecture is utterly brain-dead; I mean, what's wrong with a > > linear address space? I think it was JohnG who said "segment registers > > are for worms". > > The 65816 doesn't have the screwed-up bitshifted segment stuff but it's > also a segmented architecture and is also braindead. > > And I'm a 65C02 fan. > > -uso. > [-- Attachment #2: Type: text/html, Size: 3121 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 22:39 ` Adam Thornton @ 2021-02-04 22:47 ` Henry Bent 2021-02-05 14:42 ` Michael Parson 0 siblings, 1 reply; 29+ messages in thread From: Henry Bent @ 2021-02-04 22:47 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 957 bytes --] On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton@gmail.com> wrote: > I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, and > I still like it a great deal. Admittedly register-starved (well, unless > you consider the zero page a whole page of registers), but...simple, easy > to fit in your head, kinda wonderful. > > I'd love a 64-bit 6502-alike (but I'd probably give it more than three > registers). I mean given how little silicon (or how few FPGA gates) a > reasonable version of that would take, might as well include 65C02 and > 65816 cores in there too with some sort of mode-switching instruction. > Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be fun? > Throw in an onboard MMU and FPU too, I suppose, and then you could have a > real system on it. > > Sounds like a perfect project for an FPGA. If there's already a 6502 implementation out there, converting to 64 bit should be fairly easy. -Henry [-- Attachment #2: Type: text/html, Size: 1391 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 22:47 ` Henry Bent @ 2021-02-05 14:42 ` Michael Parson 0 siblings, 0 replies; 29+ messages in thread From: Michael Parson @ 2021-02-05 14:42 UTC (permalink / raw) To: The Eunuchs Hysterical Society On 2021-02-04 16:47, Henry Bent wrote: > On Thu, Feb 4, 2021, 17:40 Adam Thornton <athornton@gmail.com> wrote: > >> I'm probably Stockholm Syndrommed about 6502. It's what I grew up on, >> and >> I still like it a great deal. Admittedly register-starved (well, >> unless >> you consider the zero page a whole page of registers), but...simple, >> easy >> to fit in your head, kinda wonderful. >> >> I'd love a 64-bit 6502-alike (but I'd probably give it more than three >> registers). I mean given how little silicon (or how few FPGA gates) a >> reasonable version of that would take, might as well include 65C02 and >> 65816 cores in there too with some sort of mode-switching instruction. >> Wouldn't a 6502ish with 64-bit wordsize and a 64-bit address bus be >> fun? >> Throw in an onboard MMU and FPU too, I suppose, and then you could >> have a >> real system on it. >> >> > Sounds like a perfect project for an FPGA. If there's already a 6502 > implementation out there, converting to 64 bit should be fairly easy. There are FPGA implementations of the 6502 out there. If you've not seen it, check out the MiSTer[0] project, FPGA implementations of a LOT of computers, going back as far as the EDSAC, PDP-1, a LOT of 8, 16, and 32 bit systems from the 70s and 80s along with gaming consoles from the 70s and 80s. Keeping this semi-TUHS related, one guy[1] has even implemented a Sparc 32m[2] (I think maybe an SS10), which boots SunOS 4, 5, Linux, NetBSD, and even the Sparc version of NeXTSTEP, but it's not part of the "official" MiSTer bits (yet?). -- Michael Parson Pflugerville, TX KF5LGQ [0] https://github.com/MiSTer-devel/Main_MiSTer/wiki [1] https://temlib.org/site/ [2] https://temlib.org/pub/mister/SS/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 22:11 ` Steve Nickolas 2021-02-04 22:39 ` Adam Thornton @ 2021-02-04 22:56 ` Richard Salz 2021-02-04 23:14 ` Steve Nickolas 1 sibling, 1 reply; 29+ messages in thread From: Richard Salz @ 2021-02-04 22:56 UTC (permalink / raw) To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 178 bytes --] On Thu, Feb 4, 2021, 5:12 PM Steve Nickolas <usotsuki@buric.co> wrote: Well, it *was* "Braindead Software" C. > Braindamaged software. I knew Leor; he sold me his motorcycle. [-- Attachment #2: Type: text/html, Size: 739 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 22:56 ` Richard Salz @ 2021-02-04 23:14 ` Steve Nickolas 0 siblings, 0 replies; 29+ messages in thread From: Steve Nickolas @ 2021-02-04 23:14 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thu, 4 Feb 2021, Richard Salz wrote: > On Thu, Feb 4, 2021, 5:12 PM Steve Nickolas <usotsuki@buric.co> wrote: > >> Well, it *was* "Braindead Software" C. > > Braindamaged software. I knew Leor; he sold me his motorcycle. Close enough that my point can stand - but I stand corrected. -uso. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:10 ` Arthur Krewat 2021-02-04 1:33 ` Larry McVoy @ 2021-02-04 1:35 ` Clem Cole 2021-02-04 2:18 ` Dave Horsfall 2 siblings, 0 replies; 29+ messages in thread From: Clem Cole @ 2021-02-04 1:35 UTC (permalink / raw) To: Arthur Krewat; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1432 bytes --] No, that was the 16032 from nat semi. I believe at least Nick and Les had been building oil drilling controll systems using pdp11s and custom TTL For Schulmerger before they came to Moto. They were definitely pdp11 fans. But they had used 360 systems at UT in college. So they idea of a 24 bit pointer stored in a 32 bit word they took from it. Remember the chip was a 16 chip inside. It has 16 bit Barallel shifter and All 32 bit operations took 2 ticks. And int was naturally 16 bits which is what it was in my compiler. I think it was Jack Test's compiler from MIT that was the first one ILP32 one for the 68k. I used to commute to work at Stellar with Les and he told me many of the stories btw. One of them I remember was they were worried about the Barallel shifter because it was one of the pieces that was different between the TTL prototype and the MOS implementation and it was the largest pattern on the die. It was one of the few parts of the chip that had full spice simulation. Clem On Wed, Feb 3, 2021 at 8:18 PM Arthur Krewat <krewat@kilonet.net> wrote: > On 2/3/2021 7:41 PM, John Gilmore wrote: > > When the 68000 was announced, it was obviously head-and-shoulders better > > than the other clunky 8-bit and 16-bit systems, with a clean 32-bit > > architecture and a large address space. > The 68K always reminded me of the VAX. > > art k. > > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 2061 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:10 ` Arthur Krewat 2021-02-04 1:33 ` Larry McVoy 2021-02-04 1:35 ` Clem Cole @ 2021-02-04 2:18 ` Dave Horsfall 2021-02-04 15:53 ` Arthur Krewat 2 siblings, 1 reply; 29+ messages in thread From: Dave Horsfall @ 2021-02-04 2:18 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 3 Feb 2021, Arthur Krewat wrote: > The 68K always reminded me of the VAX. Pretty much the same instruction set, but on steroids :-) -- Dave, wondering whether anyone has ever used every VAX instruction ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 2:18 ` Dave Horsfall @ 2021-02-04 15:53 ` Arthur Krewat 2021-02-05 2:16 ` Dave Horsfall 0 siblings, 1 reply; 29+ messages in thread From: Arthur Krewat @ 2021-02-04 15:53 UTC (permalink / raw) To: tuhs On 2/3/2021 9:18 PM, Dave Horsfall wrote: > -- Dave, wondering whether anyone has ever used every VAX instruction Or every VMS call, for that matter. ;) art k. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 15:53 ` Arthur Krewat @ 2021-02-05 2:16 ` Dave Horsfall 2021-02-05 2:53 ` Larry McVoy 0 siblings, 1 reply; 29+ messages in thread From: Dave Horsfall @ 2021-02-05 2:16 UTC (permalink / raw) To: The Eunuchs Hysterical Society [ Directing to COFF, where it likely belongs ] On Thu, 4 Feb 2021, Arthur Krewat wrote: >> -- Dave, wondering whether anyone has ever used every VAX instruction > > Or every VMS call, for that matter. ;) Urk... I stayed away from VMS as much as possible (I had a network of PDP-11s to play with), although I did do a device driver course; dunno why. -- Dave ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-05 2:16 ` Dave Horsfall @ 2021-02-05 2:53 ` Larry McVoy 0 siblings, 0 replies; 29+ messages in thread From: Larry McVoy @ 2021-02-05 2:53 UTC (permalink / raw) To: Computer Old Farts Followers; +Cc: The Eunuchs Hysterical Society On Fri, Feb 05, 2021 at 01:16:08PM +1100, Dave Horsfall wrote: > [ Directing to COFF, where it likely belongs ] > > On Thu, 4 Feb 2021, Arthur Krewat wrote: > > >>-- Dave, wondering whether anyone has ever used every VAX instruction > > > >Or every VMS call, for that matter. ;) > > Urk... I stayed away from VMS as much as possible (I had a network of > PDP-11s to play with), although I did do a device driver course; dunno why. Me too, though I did use Eunice, it was a lonely place, it did not let me see who was on VMS. I was the only one. A far cry from BSD where wall went to everyone and talk got you a screen where you talked. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore 2021-02-04 0:52 ` Al Kossow 2021-02-04 1:10 ` Arthur Krewat @ 2021-02-04 1:14 ` Clem Cole 2021-02-04 1:20 ` Clem Cole 2021-02-04 14:56 ` John Cowan 3 siblings, 1 reply; 29+ messages in thread From: Clem Cole @ 2021-02-04 1:14 UTC (permalink / raw) To: John Gilmore; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 9250 bytes --] Hey John. Bad cut/paste. I did not say 1980. That was from Eds msg. I said we got what would become X series parts in winter 79. As I understand it from Les; he, Nick and Tom built try the TTL prototype in Early 78 with Les and Tom turning it into Si later that year while Nick was writing ucode and all of the writing AVTs we high ran against then TTL system. Les says Tom did a masterful job of keeping management out of their hair such they they stayed under the radar. From what I understand there was so much focus on countering the Z80 with the 6809 that management thought they were just experimenting with a more 16 bit 6809. But what they were doing was an AD experiment. The fact that it worked was amazing. On Wed, Feb 3, 2021 at 7:41 PM John Gilmore <gnu@toad.com> wrote: > Clem Cole <clemc@ccc.com> wrote: > > > MC 68K was created in 1980 or thereabouts. > > Wikimedia Commons has a pic of a 1979 XC68000L: > > https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg > https://en.wikipedia.org/wiki/File:XC68000.agr.jpg > > After a USENET posting pointed me at them, I browsed the Sunnyvale > Patent Library to bring home the patents for the Motorola 68000. They > include a full listing of the entire microcode! I ended up copying it, > taping the sheets together to reconstitute Nick Tredennick's > large-format "hardware flowcharts", and hanging them in the hallway near > my office at Sun. Fascinating! > > I never saw X68000 parts; Sun started in 1981, so Moto had production > parts by then. But Sun did get early prototypes of the 68010, which we > were very happy for, since we and our customers were running a swapping > Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run > the BSD UNIX that we were porting from the Vax. Later, I was part of > the Sun bringup team using the XC68020. We built a big spider-like > daughterboard adapter that would let it be plugged into a 64-pin 68010 > socket, so we could debug the 68020 in a Sun-2 CPU board while building > 32-bit-wide boards for the Sun-3 bringup. We had it successfully > running UNIX within a day of receiving it! (We later heard that our > Moto rep was intending to give that precious early part to another > customer, but decided during their meeting with us to give it to us, > because we were so ready to get it running.) > > When the 68000 was announced, it was obviously head-and-shoulders better > than the other clunky 8-bit and 16-bit systems, with a clean 32-bit > architecture and a large address space. It seems like the designers of > the other chips (e.g. the 8088) had never actually worked with real > computers (mainframes and minicomputers) and kept not-learning from > computing history. > > Some of my early experience was in APL implementation on the IBM 360 > series. I knew the 68000 would be a great APL host, since its > autoincrement addressing was perfect for implementing vector operations. > In the process of designing an APL for it (which was never built), I > wrote up a series of short suggestions to Motorola on how to improve the > design. This was published in Computer Architecture News. For the > 68010 they actually did one of the ideas, the "loop mode" that would > detect a 1-instruction backward decrement-and-branch loop, and stop > continually re-fetching the two instructions. This made > memory-to-memory or register-vs-memory instruction loops run at almost > the speed of memory, which was a big improvement for bcopy, bzero, > add-up-a-vector-of-integers, etc. > > I'll append a USENET posting about the 68000 patents, followed by my > addendum after visiting the Patent office. > > John > > From decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue > Mar 15 16:55:28 1983 > Subject: 68000: 16 bits. With references > Newsgroups: net.micro.68k > > With due respect to Henry Spencer I feel that I must correct > some of his statements regarding the 68000. He is correct in > saying that the 68000 is basically 16 bits wide; however, > his explanation of the segmented bus is incorrect. > > The datapath of the 68000 is divided into three pieces, each of > which has two busses, address and data, running through it. Six > busses total. There are muxes which can be switched so that all > address busses are connected and all data busses are connected. > The three sections of the datapath are the data section > (includes low 16 bits of all data registers and ALU), the > "low" section (contains the low 16 bits of address registers and > the low half of the Address Adder(AAU)), and the "high" section > (contains high 16 bits of all address and data registers and > the upper half of the AAU). > > Theoretically they could do 6 16 bit transfers simultaneously, > but in looking through the microcode I don't remember seeing more > than three transfers at a time. The "low" and "high" sections can > be cascaded to provide a 32 bit arithmetic unit for address > calculations. 32 bit data calculations must be done in two passes through > the ALU. > > For the masochists out there, you can learn more than you ever wanted > to know about the 68000 by reading Motorola's patents on it. They are > available for some nominal fee (~ one dollar) from the Office > of Patents and Trademarks in Arlington. The relevant patents are: > > 1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two > Level Control Store for Data Processor", Tredennick, et al. > > First design of 68000 which was scrapped? > > 2 - #4,296,469 "Execution Unit for Data Processor using Segmented > Bus structure", Gunter, et al. > > All about the 16 bit data path > > 3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor", > Gunter, et al. > > Boring. > > 4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data > Processor", > Gunter et al. > > Bonanza! Full of block diagrams and everything you ever wanted > to know. Includes complete listing of microcode with > Tredennick's "hardware flowcharts". > > Hope this clears things up. > > Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056 > > > My [gnu] notes on additional 68000 patents: > > Pat # Appl # Filed date Issued date Inventors > > 4,338,661 041,201 May 21, 1979 Jul 6, 1982 > Tredennick & Gunter > Conditional Branch Unit for Microprogrammed Data Processor > > 4,342,078 041,202 May 21, 1979 Jul 27, 1982 > Tredennick & Gunter > Instruction Register Sequence Decoder for Microprogrammed > Data Processor and Method > > 4,312,034 041,203 May 21, 1979 Jan 19, 1982 > Gunter, Hobbs, Spak, Tredennick > ALU and Condition Code Control Unit for Data Processor > > 4,325,121 041,135 May 21, 1979 Apr 13, 1982 > Gunter, Tredennick > Two-Level Control Store for Microprogrammed Data Processor > Bonanza! Full of block diagrams and everything you ever > wanted > to know. Includes complete listing of microcode with > Tredennick's "hardware flowcharts". > > 4,296,469 961,798 Nov 17, 1978 Oct 20, 1981 > Gunter, Tredennick, McAlister > Execution Unit for Data Processor Using Segmented Bus Structure > All about the 16 bit data path > > 4,348,722 136,845 Apr 3, 1980 Sep 7, 1982 > Gunter, Crudele, Zolnowsky, Mothersole > Bus Error Recognition for Microprogrammed Data Processor > > 4,349,873 136,593 Apr 2, 1980 Sep 14, 1982 > Gunter, Zolnowsky, Crudele > Microprocessor Interrupt Processing > > 4,524,415 447,721 Dec 7, 1982 Jun 18, 1985 > Mills, Moyer, MacGregor, Zolnowsky > Virtual Machine Data Processor > 68010 changes to 68000 > > 4,348,741 169,558 Jul 17, 1980 Sep 7, 1982 > McAlister, Gunter, Spak, Schriber > Priority Encoder > Used to decode the bit masks for MOVEM. > > XXXXXXXXX 446,801 Dec 7, 1982 > Crudele, Zolnowsky, Moyer, MacGregor > Virtual Memory Data Processor > > XXXXXXXXX 447,600 Dec 7, 1982 > MacGregor, Moyer, Mills Jr, Zolnowsky > Data Processor Version Validation > About how bus errors store a CPU mask version # to > prevent their being restarted on a different CPU mask > in a multiprocessor system > > XXXXXXXXX 961,796 Nov 17, 1978 > Tredennick et al > Microprogrammed Control Apparatus for Data Processor > (continued into 4,325,121, probably never issued) > > XXXXXXXXX 961,797 Nov 17, 1978 > McAlister et al > Multi-port RAM Structure for Data Processor Registers > > 4,307,445 961,796 Nov 17, 1978 > Tredennick, et al > Microprogrammed Control Apparatus Having a Two Level > Control Store for Data Processor > First design of 68000 which was scrapped? > > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 11138 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 1:14 ` Clem Cole @ 2021-02-04 1:20 ` Clem Cole 0 siblings, 0 replies; 29+ messages in thread From: Clem Cole @ 2021-02-04 1:20 UTC (permalink / raw) To: John Gilmore; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 9673 bytes --] Bad iPhone autocorrect sigh... They all ran the AVTs on the TTL prototype. On Wed, Feb 3, 2021 at 8:14 PM Clem Cole <clemc@ccc.com> wrote: > Hey John. Bad cut/paste. I did not say 1980. That was from Eds msg. I > said we got what would become X series parts in winter 79. As I > understand it from Les; he, Nick and Tom built try the TTL prototype in > Early 78 with Les and Tom turning it into Si later that year while Nick was > writing ucode and all of the writing AVTs we high ran against then TTL > system. > > Les says Tom did a masterful job of keeping management out of their hair > such they they stayed under the radar. > > From what I understand there was so much focus on countering the Z80 with > the 6809 that management thought they were just experimenting with a more > 16 bit 6809. But what they were doing was an AD experiment. The fact > that it worked was amazing. > > On Wed, Feb 3, 2021 at 7:41 PM John Gilmore <gnu@toad.com> wrote: > >> Clem Cole <clemc@ccc.com> wrote: >> > > MC 68K was created in 1980 or thereabouts. >> >> Wikimedia Commons has a pic of a 1979 XC68000L: >> >> https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg >> https://en.wikipedia.org/wiki/File:XC68000.agr.jpg >> >> After a USENET posting pointed me at them, I browsed the Sunnyvale >> Patent Library to bring home the patents for the Motorola 68000. They >> include a full listing of the entire microcode! I ended up copying it, >> taping the sheets together to reconstitute Nick Tredennick's >> large-format "hardware flowcharts", and hanging them in the hallway near >> my office at Sun. Fascinating! >> >> I never saw X68000 parts; Sun started in 1981, so Moto had production >> parts by then. But Sun did get early prototypes of the 68010, which we >> were very happy for, since we and our customers were running a swapping >> Unisoft UNIX because the 68000 couldn't do paging and thus couldn't run >> the BSD UNIX that we were porting from the Vax. Later, I was part of >> the Sun bringup team using the XC68020. We built a big spider-like >> daughterboard adapter that would let it be plugged into a 64-pin 68010 >> socket, so we could debug the 68020 in a Sun-2 CPU board while building >> 32-bit-wide boards for the Sun-3 bringup. We had it successfully >> running UNIX within a day of receiving it! (We later heard that our >> Moto rep was intending to give that precious early part to another >> customer, but decided during their meeting with us to give it to us, >> because we were so ready to get it running.) >> >> When the 68000 was announced, it was obviously head-and-shoulders better >> than the other clunky 8-bit and 16-bit systems, with a clean 32-bit >> architecture and a large address space. It seems like the designers of >> the other chips (e.g. the 8088) had never actually worked with real >> computers (mainframes and minicomputers) and kept not-learning from >> computing history. >> >> Some of my early experience was in APL implementation on the IBM 360 >> series. I knew the 68000 would be a great APL host, since its >> autoincrement addressing was perfect for implementing vector operations. >> In the process of designing an APL for it (which was never built), I >> wrote up a series of short suggestions to Motorola on how to improve the >> design. This was published in Computer Architecture News. For the >> 68010 they actually did one of the ideas, the "loop mode" that would >> detect a 1-instruction backward decrement-and-branch loop, and stop >> continually re-fetching the two instructions. This made >> memory-to-memory or register-vs-memory instruction loops run at almost >> the speed of memory, which was a big improvement for bcopy, bzero, >> add-up-a-vector-of-integers, etc. >> >> I'll append a USENET posting about the 68000 patents, followed by my >> addendum after visiting the Patent office. >> >> John >> >> From decwrl!decvax!harpo!npoiv!npois!houxm!houxa!houxk!tdl (T.LOVETT) Tue >> Mar 15 16:55:28 1983 >> Subject: 68000: 16 bits. With references >> Newsgroups: net.micro.68k >> >> With due respect to Henry Spencer I feel that I must correct >> some of his statements regarding the 68000. He is correct in >> saying that the 68000 is basically 16 bits wide; however, >> his explanation of the segmented bus is incorrect. >> >> The datapath of the 68000 is divided into three pieces, each of >> which has two busses, address and data, running through it. Six >> busses total. There are muxes which can be switched so that all >> address busses are connected and all data busses are connected. >> The three sections of the datapath are the data section >> (includes low 16 bits of all data registers and ALU), the >> "low" section (contains the low 16 bits of address registers and >> the low half of the Address Adder(AAU)), and the "high" section >> (contains high 16 bits of all address and data registers and >> the upper half of the AAU). >> >> Theoretically they could do 6 16 bit transfers simultaneously, >> but in looking through the microcode I don't remember seeing more >> than three transfers at a time. The "low" and "high" sections can >> be cascaded to provide a 32 bit arithmetic unit for address >> calculations. 32 bit data calculations must be done in two passes through >> the ALU. >> >> For the masochists out there, you can learn more than you ever wanted >> to know about the 68000 by reading Motorola's patents on it. They are >> available for some nominal fee (~ one dollar) from the Office >> of Patents and Trademarks in Arlington. The relevant patents are: >> >> 1 - #4,307,445 "Microprogrammed Control Apparatus Having a Two >> Level Control Store for Data Processor", Tredennick, et al. >> >> First design of 68000 which was scrapped? >> >> 2 - #4,296,469 "Execution Unit for Data Processor using Segmented >> Bus structure", Gunter, et al. >> >> All about the 16 bit data path >> >> 3 - #4,312,034 "ALU and Condition Code Control Unit for Data Processor", >> Gunter, et al. >> >> Boring. >> >> 4 - #4,325,121 "Two-Level Control Store for Microprogrammed Data >> Processor", >> Gunter et al. >> >> Bonanza! Full of block diagrams and everything you ever wanted >> to know. Includes complete listing of microcode with >> Tredennick's "hardware flowcharts". >> >> Hope this clears things up. >> >> Tom Lovett BTL Holmdel harpo!houxk!tdl 201-949-0056 >> >> >> My [gnu] notes on additional 68000 patents: >> >> Pat # Appl # Filed date Issued date Inventors >> >> 4,338,661 041,201 May 21, 1979 Jul 6, 1982 >> Tredennick & Gunter >> Conditional Branch Unit for Microprogrammed Data Processor >> >> 4,342,078 041,202 May 21, 1979 Jul 27, 1982 >> Tredennick & Gunter >> Instruction Register Sequence Decoder for Microprogrammed >> Data Processor and Method >> >> 4,312,034 041,203 May 21, 1979 Jan 19, 1982 >> Gunter, Hobbs, Spak, Tredennick >> ALU and Condition Code Control Unit for Data Processor >> >> 4,325,121 041,135 May 21, 1979 Apr 13, 1982 >> Gunter, Tredennick >> Two-Level Control Store for Microprogrammed Data Processor >> Bonanza! Full of block diagrams and everything you ever >> wanted >> to know. Includes complete listing of microcode with >> Tredennick's "hardware flowcharts". >> >> 4,296,469 961,798 Nov 17, 1978 Oct 20, 1981 >> Gunter, Tredennick, McAlister >> Execution Unit for Data Processor Using Segmented Bus Structure >> All about the 16 bit data path >> >> 4,348,722 136,845 Apr 3, 1980 Sep 7, 1982 >> Gunter, Crudele, Zolnowsky, Mothersole >> Bus Error Recognition for Microprogrammed Data Processor >> >> 4,349,873 136,593 Apr 2, 1980 Sep 14, 1982 >> Gunter, Zolnowsky, Crudele >> Microprocessor Interrupt Processing >> >> 4,524,415 447,721 Dec 7, 1982 Jun 18, 1985 >> Mills, Moyer, MacGregor, Zolnowsky >> Virtual Machine Data Processor >> 68010 changes to 68000 >> >> 4,348,741 169,558 Jul 17, 1980 Sep 7, 1982 >> McAlister, Gunter, Spak, Schriber >> Priority Encoder >> Used to decode the bit masks for MOVEM. >> >> XXXXXXXXX 446,801 Dec 7, 1982 >> Crudele, Zolnowsky, Moyer, MacGregor >> Virtual Memory Data Processor >> >> XXXXXXXXX 447,600 Dec 7, 1982 >> MacGregor, Moyer, Mills Jr, Zolnowsky >> Data Processor Version Validation >> About how bus errors store a CPU mask version # to >> prevent their being restarted on a different CPU mask >> in a multiprocessor system >> >> XXXXXXXXX 961,796 Nov 17, 1978 >> Tredennick et al >> Microprogrammed Control Apparatus for Data Processor >> (continued into 4,325,121, probably never issued) >> >> XXXXXXXXX 961,797 Nov 17, 1978 >> McAlister et al >> Multi-port RAM Structure for Data Processor Registers >> >> 4,307,445 961,796 Nov 17, 1978 >> Tredennick, et al >> Microprogrammed Control Apparatus Having a Two Level >> Control Store for Data Processor >> First design of 68000 which was scrapped? >> >> -- > Sent from a handheld expect more typos than usual > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 11818 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [TUHS] 68k prototypes & microcode 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore ` (2 preceding siblings ...) 2021-02-04 1:14 ` Clem Cole @ 2021-02-04 14:56 ` John Cowan 3 siblings, 0 replies; 29+ messages in thread From: John Cowan @ 2021-02-04 14:56 UTC (permalink / raw) To: John Gilmore; +Cc: UNIX Heritage Society [-- Attachment #1: Type: text/plain, Size: 1251 bytes --] On Wed, Feb 3, 2021 at 7:42 PM John Gilmore <gnu@toad.com> wrote: > It seems like the designers of > the other chips (e.g. the 8088) had never actually worked with real > computers (mainframes and minicomputers) and kept not-learning from > computing history. > Hence the description of Windows 95 as "a 32-bit extension to a 16-bit patch to an 8 bit OS originally for a 4-bit chip written by a 2-bit company that doesn't care 1 bit about its users." On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm@mcvoy.com> wrote: The NS320XX always reminded me more of the PDP-11 (which is by *far* > my favorite assembler, so uniform, I slightly prefer the MIPS-32. > The x86 stuff is about as far away from PDP-11 as you can get. Required > to know it, but so unpleasant. > Required? Ghu forbid. After doing a bunch of PDP-11 assembler work, I found out that the Vax had 256 opcodes and foreswore assembly thereafter. Still, that was nothing compared to the 1500+ opcodes of x86*. I think I dodged a bullet. On Wed, Feb 3, 2021 at 9:18 PM Dave Horsfall <dave@horsfall.org> wrote: > -- Dave, wondering whether anyone has ever used every VAX instruction > AFAIU, some of them were significantly slower than their multi-instruction equivalents. [-- Attachment #2: Type: text/html, Size: 3069 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2021-02-13 6:05 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-13 1:06 [TUHS] 68k prototypes & microcode Jason Stevens 2021-02-13 2:30 ` Gregg Levine -- strict thread matches above, loose matches on Subject: below -- 2021-02-13 4:34 Jason Stevens 2021-02-13 6:05 ` Toby Thain 2021-01-29 10:49 [TUHS] AT&T 3B1 - Emulation available Arnold Robbins 2021-02-03 7:53 ` emanuel stiebler 2021-02-03 7:59 ` arnold 2021-02-03 8:53 ` Ed Bradford 2021-02-03 8:58 ` arnold 2021-02-03 10:13 ` Ed Bradford 2021-02-03 14:58 ` Clem Cole 2021-02-04 0:41 ` [TUHS] 68k prototypes & microcode John Gilmore 2021-02-04 0:52 ` Al Kossow 2021-02-04 1:10 ` Arthur Krewat 2021-02-04 1:33 ` Larry McVoy 2021-02-04 1:47 ` Al Kossow 2021-02-04 1:57 ` Al Kossow 2021-02-04 7:23 ` Arno Griffioen 2021-02-04 11:28 ` Toby Thain 2021-02-04 15:47 ` Arthur Krewat 2021-02-04 16:03 ` emanuel stiebler 2021-02-04 21:55 ` Dave Horsfall 2021-02-04 22:11 ` Steve Nickolas 2021-02-04 22:39 ` Adam Thornton 2021-02-04 22:47 ` Henry Bent 2021-02-05 14:42 ` Michael Parson 2021-02-04 22:56 ` Richard Salz 2021-02-04 23:14 ` Steve Nickolas 2021-02-04 1:35 ` Clem Cole 2021-02-04 2:18 ` Dave Horsfall 2021-02-04 15:53 ` Arthur Krewat 2021-02-05 2:16 ` Dave Horsfall 2021-02-05 2:53 ` Larry McVoy 2021-02-04 1:14 ` Clem Cole 2021-02-04 1:20 ` Clem Cole 2021-02-04 14:56 ` John Cowan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).