Talk:Motorola 68000/Archive 2

Archive 1

Archive 2

Content from Amiga virtual machine (AFD)

The article Amiga virtual machine has come to my attention as it was proposed for deletion today. While my take is that it should be deleted, I think it contains some useful information, and I've proceeded to add some of it (namely, the section originally titled Bytecodes) to the 68k article (is that a good name for an article, by the way?). Only later did I realize that this is possibly a more appropriate place for such content. However, at this point, I prefer to avoid further roaming of content until someone else reviews it and discusses about the most appropriate placement for it. LjL 20:16, 16 May 2006 (UTC)

68020 addressing modes influenced by printer applications?

I'm rather dubious of the claim added by Wayne Hardman that the addressing modes of the 68020 were influenced specifically by printer applications. Can anyone cite a reference? It seems much more likely that Motorola chose new addressing modes based on a survey of compiler-generated code for a wide variety of applications, and that some of those addressing modes happened to be fairly useful in printers (or graphic rendering in general). --Brouhaha 23:07, 21 August 2006 (UTC)

I question the premise that the new addressing modes are useful. This sort of feature creep is typical of microcoded CPUs and doesn't necessarily reflect any measurable benefit. Coldfire dumped the new modes (except for the scaled index feature). Mirror Vax 00:03, 22 August 2006 (UTC)

Obviously Motorola thought at the time that they would be useful. What I question is whether they were thought to be especially useful for printer applications. If no one can cite any reference for that, the sentence should be removed. --Brouhaha 22:23, 22 August 2006 (UTC)

I agree that the claim about 68020 addressing modes being influenced by printer applications is dubious, and even if true, it would be more appropriate for the 68020 article. I removed it as part of some other edits. --Colin Douglas Howell 03:31, 20 September 2006 (UTC)

From old Mac OS days, I remember most, if not all, of the addressing modes getting generated by the compiler with at least fair frequency on general OO code. As to how much faster it went or denser it was as a result, I don't know :v) . But can we all agree it's still less wacky than x86? Potatoswatter (talk) 08:31, 6 December 2007 (UTC)

I think that it is more likely that the bitfield instructions were introduced with printers in mind. They were also useful for image display manipulation, though. — Preceding unsigned comment added by 87.149.189.47 (talk) 12:41, 23 June 2015 (UTC)

Ti-calculators with M68k

Some Ti-calculators (Texas Instruments) uses the Motorola 68000 e.g. the Ti-89 Titanium (or original) and Ti-92 Voyage. How about adding info about them? --Red_Hat_Eagle 03:31, 30 October 2006 (UTC)

TI graphing calculators are already mentioned briefly, but I agree that a bit more detail should be added. --Colin Douglas Howell 06:39, 31 October 2006 (UTC)

I've added more detail on the 68000's use in TI calculators. --Colin Douglas Howell 22:19, 1 November 2006 (UTC)

History section needs to be restructured

The History section is currently too long and contains a mix of general historical info about the 68000 and descriptions of specific 68000 applications. I confess that I've recently made the problem worse. The section needs to be split into separate History and Applications sections, or something along those lines, but I'm not sure how best to go about this. There doesn't seem to be any agreed-upon structure for Wikipedia articles on microprocessors. (I know "Be Bold" is the Wikipedia motto, but I'm naturally oriented towards caution rather than boldness.) --Colin Douglas Howell 22:38, 1 November 2006 (UTC)

OK, I just went ahead and did it. There's still room for further improvement, of course. --Colin Douglas Howell 05:02, 2 November 2006 (UTC)

Nice work. Chris Cunningham 09:05, 2 November 2006 (UTC)

Article has vague "cheerleading" statements which need eliminating

This article has some vague statements with a sort of "cheerleading" tone. The earliest version of the article seems to have been written by a fan of the 68000 and contains a number of such statements, some of which are still in the current article. While I agree that the 68000 was a well-designed processor, I think that such POV expressions are out of line here; it's better to describe and explain the processor's advantages in a clear, unbiased way.

Sadly in regards to the 68000 and Amiga platforms both are Wikipedia poison for attracting inaccurate evangelising. Wikipedia is shot-through with people who apparently still want to work in 68000/Amiga sales. I would in fact like there to be a more pointed effort from independent editors to correct or remove cheerleading, inaccuracy, and misleading product comparisons introduced far too often by their respective fan-base. The propensity for technical inaccuracy, dishonesty and irrelevance makes them the least desirable fan base of any platform. Vapourmile (talk) 12:51, 27 October 2020 (UTC)

Here's one example which I've just removed, referring to uses of the 68000: "It also sees use by medical manufacturers and many printer manufacturers because of its low cost, convenience, and good stability." The 68000 is certainly cheap now, but no more so than many other processors and microcontrollers competing for these markets. Whether it is "convenient" can depend on all sorts of factors, such as "which microcontrollers contain the particular devices we need?" and "what architectures are our embedded programmers most fluent in?" As for "good stability", I'm sure that applies to most microcontrollers; the embedded market has little tolerance for flakiness. (I felt free to remove the sentence because the uses in medical and printer fields are now also mentioned elsewhere.) --Colin Douglas Howell 19:02, 3 November 2006 (UTC)

Another one I've just eliminated claimed that the 68000 family was popular in the Unix world "because the architecture so strongly resembles the Digital PDP-11 and VAX, and is an excellent computer for running C code". It's certainly true that 68000-based Unix systems were popular, but these reasons for this popularity are hard to support. The 68000 did not "strongly resemble" either the PDP-11 or the VAX. True, it was a general-register architecture like those others, but there were lots of differences in detail. For example, the PDP-11 was purely 16-bit, had no separate address registers, and included the program counter as a general register. The VAX, on the other hand, had 16 general registers and was a three-address machine rather than a two-address machine like the 68000 and PDP-11. You could say that the 68000 had some limited general similarity to the PDP-11 and VAX, but it's not clear that was important for its popularity in Unix systems.

As for "an excellent computer for running C code", that statement doesn't even seem meaningful. The 68000 was no better for running compiled C code than many other architectures. It's true that C programmers on the 8086 and 80286 might have had to worry about far and near pointers, but even that deficiency was eliminated with the 80386. In any case, architectural issues are normally the C compiler's problem, not the user's, and again it's not clear whether such concerns were important in the popularity of 68000-based Unix. --Colin Douglas Howell 21:12, 3 November 2006 (UTC)

I agree with your statements about the 68000 in general but not so much the C code thing. Some CPUs are much better than others for targeting C code to because the resultant machine code uses fewer instructions. The 68000 supports stack frames and uses considerably fewer instructions for the retrieval and manipulation of stack-based parameters than other CPUs of its time, such as the 8086, Z80 or 6502 or the later 8051. Try writing the assembler and see :-) It's not true that it becomes the compiler's problem: it's the programmer's problem if they can't get the required performance from their CPU because the C compiler is slowing it down too much over hand-tuned assembly source. We can debate the pros and cons of C over assembly but the fact remains that in those days, performance was hard to come by.ToaneeM (talk) 13:23, 4 May 2017 (UTC)

Removed unverifiable statement about recent Hitachi 68000 production

I've removed this statement: "As of 2001, Hitachi continued to manufacture the 68000 under license", because I can't find any information backing it up. Although I know that Hitachi made 68000 versions, I can't find anything about 68000 production on their web sites, either on the current pages or in the Internet Archive. If someone could find some sources of information about this, it would be a big help. --Colin Douglas Howell 07:09, 19 November 2006 (UTC)

Same pinout as ever?

Just wondering if today's 68K is the same size as the monster was in my Mac and Genesis? --24.249.108.133 23:42, 28 December 2006 (UTC)

'Todays' 68K CPUs are not pin compatible. They changed in the 68020.— Preceding unsigned comment added by 24.141.181.146 (talk) 13:03, 4 January 2007 (UTC)

It looks like the DIP package is discontinued, with only pin grid array and quad edge packages produced. You can still find the old chips on the surplus market, though the price is now higher. Chip package evolution is driven by board process evolution (it's more expensive to use a "monster" chip, so if you did you'd upgrade your factory and buy the new package), and environmental regulations (the newer packages are less toxic). Potatoswatter (talk) 08:40, 6 December 2007 (UTC)

Usefulness of PC-relative mode

The article makes the statement:

   * 16-bit signed offset, e.g. 16(PC). This mode was very useful.

Very useful for what? It seems like it'd be useful for position independent code, but not much else. Since it's usefulness is non-obvious, should this be called out, or should we remove this editorialization? --Mr z 20:15, 9 August 2007 (UTC)

Amiga 500 processor

The Amiga 500 article makes a very precise but unsourced claim of 7.15909 mhz for the 68000, but this article makes no mention of the 68000 being manufactured at this speed. Is this correct? Miremare 18:20, 13 August 2007 (UTC)

Slight underclocking. NTSC Color Subcarrier Frequency is 3.579545 MHz , the CPU speed (on NTSC models) exactly twice that. (83.245.252.197 22:47, 31 August 2007 (UTC))

The PAL version ran at 8/5 of the PAL carrier (4.43361875MHz) at 7.09379MHz. Both versions used an 8MHz part. —Preceding unsigned comment added by 193.27.220.14 (talk) 12:25, 6 August 2008 (UTC)

With only 56 instructions the minimal instruction size was huge for its day at 16 bits.

What does this mean? The Strela, 1953, had a minimum instruction size of 36 bits. The PDP-10 (from early 60's) also. PDP-11 instructions are always 16 bit (because everything is always contained in one word - 1 opcode, up to 2 operands each including a register and an addressing mode)... I need to regards this statements as a mistake, unless it is supposed to say that the minimum opcode length is 16 bits, which sounds unplausible.

History section dispute

Theaveng, Intel and the 68000 are not analog to the VHS and Betamax and comparisons between those two products don't go into details non-techies can't follow.

Let's take a closer look at the current history section and I'll tell you some of my troubles with it.

The 68000 grew out of the MACSS (Motorola Advanced Computer System on Silicon) project, begun in 1976. One of the early decisions made was to develop a new "no compromise" architecture that paid little attention to backward compatibility. This was a gamble because it would mean adopters of the chip would have to learn the new system entirely from scratch. In the end, the only concession to backward compatibility was a hardware one: the 68k could interface to existing 6800 peripheral devices, but could not run 6800 code. However, the designers built in a tremendous amount of forward compatibility, which paid off once 68k expertise had been gained by end users. For instance, the CPU registers were 32-bits wide, though address and data buses outside the CPU were initially narrower. In contrast the Intel 8086/8088 were 16-bits wide internally.

With the exception of the register file the 68000 was also 16-Bit wide internally. Also, this is a typical throwaway statement that don't quite fit. Making random comparisons with Intel CPUs just diffuse what the article actually is trying to tell. Also note that the word tremendous is a clear case of POV.

At the time, there was fierce competition among several of the then established manufacturers of 8-bit processors to bring out 16-bit designs. National Semiconductor had been first with its IMP-16 and PACE processors in 1973-1975, but these had issues with speed. Texas Instruments was next, with its TMS9900, but its CPU was not widely accepted. Next came Intel with the Intel 8086/8088 in 1977/78. However, Motorola marketing stressed the (true) point that the 68000 was a much more complete 16-bit design than the others. In fact, it is an implementation of a 32-bit architecture on a 16-bit CPU. This was reflected in its complexity. The transistor cell count, which was then a fairly direct measure of power in that era, was more than twice that of the 29,000 of the 8086.

Okay, but centers a bit too much on 'other CPUs'. Let's split this up into two paragraphs, one discussing all the other CPUs and another for 68000 marketing. As for the transistor count comparison, the article has already touched upon transistor count, delving back onto this topic is a typical armature mistake. And why are we comparing with the two year older intel architecture? The Z8000 was closer in age, 16-Bit and like the 68000 not 'backwards constrained'.

The simplest 68000 instructions took four clock cycles, but the most complex ones required many more. An 8 MHz 68000 had an average performance of roughly 1 MIPS.

Nice to know, but it's just a random technical dribble that's not discussed further. Should be cut away if it improves the article's readability.

On average, the 68000's instructions in typical program code did more work per instruction than competing Intel processors, which meant that 68000 designs both needed less RAM to store machine code and were faster.[citation needed] Additionally, the 68000 offered a "flat" 24-bit addressing system supporting up to 16 MB of memory; at the time, this was a very large memory space. Intel chips instead used a segmented system which was much more difficult to program.

much more difficult is clearly POV. The RAM/Faster statement is uncited, vague and only seem to exist to tell us that the 68000 CPU was better than competing Intel CPUs (which is wrong - later Intel CPUs were faster). It says nothing about other CPU archs and leave it up to the reader to figure out what historical impact this had.

Also, keep in mind that the 68000 had strong competitors in the Z8000, NS162032, iAPX 432 and other contenders to the title of CPU of the eighties. The article as it currently stand does a poor job of detailing how the 68000 faired technically against these CPUs. Why single out the Intel 8086? The 8086 was two years older, had starkly different design goals, and would have faded away if it didn't get on the IBM rocket ship.

That said, I say again that technical details should not be the focus of the history section. The history of the 68000 CPU can be discussed without readers knowing about bit width, transistor count, address range, clock cycles, etc. These are technical terms that flies over many people's heads - rightfully so - and we should make an effort to keep those to a more technically focused section of the article. If we do feel the need to mention, say, clock cycles then we should (within reason) give a short explanation just what it means.

--Anss123 22:41, 2 October 2007 (UTC)

Well then EDIT it to eliminate words like "massive" and anything else you think seems biased. And move the technical stuff out of history & into a sub-suection titled technology. I'd have no objection to that. ----- But what you did was basically excise half the article (including the Intel comparisons, which I liked), and I object to throwing away information so indiscriminately (it's such purges that led to the loss of early BBC tv shows & early silent movies) (because someone carelessly through them in the trash). EDIT to improve; don't do massive deletions is the wiki mantra.

Also I suggest you take a look at the Betamax article. It does indeed do technical comparisions to VHS (comparing different video resolutions and frequencies). And I love that article, because it's a great resource. So too is this 68000 article. Please don't turn it into a worthless fluff piece that has no technical value whatsoever. - Theaveng 13:51, 3 October 2007 (UTC)

It's okay now but a while ago I read this page and I noticed how much fanboyism was in this page. A few seconds ago I read the page and I noticed that all the fanboyism already got taking out. I'm sorry I deleted your page and put my oppinion about it. It's just that it was not the best processor out there like the artical said it was back a few months ago. I'm sorry I did not reread it to see if it already got edited. I thought it was the same old fanboy-made article that was here back in September.

What I'm sick of hearing is Sega fanboys claming that their processor was like god and Nintendo's processor was a peice of poop. I hear that all day long and I'm sick of it. Wikipedia supporting their oppinion makes it even worse.

Thankyou for fanboy-proofing your article.

By the way the "4 cycles to add bytes, 8 cycles to add words, 4 cycles to access memory, not at the same time" stuff is true and is a major hit for it's CPU performance. Most other CPUs at it's time (ex: 6502, 65C816, Z80, 6809, ARM etc) didn't have those cycle limitations. This makes this processor very weak compared to others.

the 65C816 is one of the most underrated processors of all time. Sure the 68000 has a lot more internal registers; but it has the above performance problem. 65C816 doesn't have that problem with performance so it's able to access external memory faster than the 68000 could even access internal memory.

Nintendo is as fast as Sega because of the above 68000-only "bandwidth" limitation that almost no other processor, including 65C816, had.

—Preceding unsigned comment added by 75.58.34.62 (talk) 02:47, 24 November 2007 (UTC)

Yes those evil Sega fanboys! That said, the SNES CPU is slower. At full speed the SNES CPU runs at 3.5 MHz - less than half of the Genny, but when accessing ROM, Video or other hardware it slows down to 1.5 MHz or 2.5 MHz depending on what it accesses. Further troubling it is it limited register set, resulting in programs often needing more instructions to be equivalent with the 68000. Worse, there's a 2 cycle penalty for fetching 16-bit words on the SNES (8-bit data buss) whereas the Genny might pull it off in one cycle with a little luck. At the end of the day the Genny CPU is significantly faster, even if some Genny games suffer from slowdowns.

--Anss123 (talk) 10:25, 24 November 2007 (UTC)

Stop just stop!!! You didn't read my post the 68000 takes four clock cycles to access memory and do addition to bytes and connot do both at the same time. the 65C816 takes only one cycle to do both and can do them simultaniously

and all this "drops down to 2.5 megahertz when accessing certain parts of memory" proves nothing because a good programmer would avoid using that part of memory anyway

plus it has an H-DMA chip that does all the raster interept VRAM loading so the CPU doesn't have to worry about it. Something Sega Genesis doesn't have.

and let me rimind you that the snes uses a specialized version of the 65C816 that has two buses that can be used at the same time and many extra "external registers" built on the inside of the chip so it can access them even faster.

edit: by the way, can you tell me, one way you could possibly pull off something on 68000 in 1 cycle when the shortest opcode takes 4? —Preceding unsigned comment added by 75.58.75.4 (talk) 19:59, 24 November 2007 (UTC)

I was talking about fetching 16-bit words. A genny can pull that off in one cycle as it has a 16-bit data buss, whereas the SNES has a 8-bit data buss and need at the very least two cycles.

The two address busses in the SNES are not data busses. When you say both can be used at the same time I believe you referee to when the SNES does DMA. Both busses are in use then, with the system running at 2.5 MHz. If you use the 8-bit address bus the CPU slows down to about 1.5 MHz, used for reading the controller and audio chip among other things.

Early SNES games ran the system at 2.5 MHz so that they could use cheaper ROM chips. Later games allow the CPU to run at 3.5 MHz, but not when accessing video hardware, audio hardware, etc....

--Anss123 (talk) 21:30, 24 November 2007 (UTC)

give me a link to that information please about it slowing down to 1.5 MHz when accessing the video and audio chips. And NO wikipedia articles are NOT proof because they can be manipulated by anyone and especially you. You'll never find detailed hardware level information about it because you made that up. I'll find detailed hardware information on snes's memory map and it will completely agree with me.

and you still fail in naming me an 68000 opcode that takes less than four cycles.

edit: I found real proof before you found your own bs. www.romhacking.net/docs/memmap.txt

there you go, BUS-B is on fast speed. The only slow part of memory is the W-RAM which is the part that saves game files. These registers only have to be written to after levels.

I did not say it slowed down to 1.5 MHz when accessing the video chip, I said it slowed down to 1.5 MHz when using bus the 8-bit buss to access the controllers and audio chip. When working with the video chip you generally want to perform memory copies, and that is most efficiently done with DMA. When doing DMA the system is slowed to 2.5 MHz, the CPU is actually halted. I believe romhacking is used as a source for this on Wikipedia, the document you referenced is written by the same user that wrote the Wikipedia stuff (user:Anomie).

Oh, and about that Opcode. Why are you insisting that I name a one cycle opcode? I never claimed there was a one cycle opcode. I did claim that a 68K can perform a 16-bit fetch in one cycle, whereas the SNES needs two cycles. This due to Nintendo's decision to use a 8-bit data buss on the SNES, the 65C816 can be used with a 16-bit data buss too - but not on the SNES.--Anss123 (talk) 13:34, 25 November 2007 (UTC)

Yeah, there is no one cycle opcode in it's entire instruction set. The shortest opcode takes four. Yes, theoretically it can access 16-bits per cycle, but in reality it can't because there is no opcode that enables it to do that. I don't want to break your fantasy but the chip's microcoding is really bad. Sure Motorola could've did a lot of nice stuff with the same architecture but the microcode didn't utilize it's own hardware.

The 65C816's microcode did a much better job at utilizing the it's own hardware it's running. The 65C816 chip does actually accesses memory every cycle. The 68000 can only access memory every 4 clock cycles because of the poor decisions in microcoding.

Please stop using this theoretical philosophy, because we do not live in a theoretical world.

case closed, good night —Preceding unsigned comment added by 75.57.173.83 (talk) 03:39, 26 November 2007 (UTC)

Anon dude: if either the 68000 or the 65816 were that bad, they wouldn't both have so many design wins. The 68000 accessed the bus every 4 cycles, but it was clocked faster, finally over 60 MHz, and has better compilers. In the end it was used in more applications, notably the Palm series of PDAs and the TI calculators in this decade.

It is generally pointless (and thus unencyclopaedic) to compare competing products on aesthetic merits. The marketplace does that for us, and decides what aesthetics actually matter. (That marketplace consists of engineers who decide which chip is better for actual applications.) Nintendo chose the 65816. Sega chose the 68000. Apple chose both but knew one was a dead end. Behind each of those decisions was a broad discussion including the issues you've brought up. So let's make use of the research of others and stop clogging this talk page. Potatoswatter (talk) 04:15, 26 November 2007 (UTC)

Hmm, I don't want to enter the useless debate. Just a few technical corrections. The 68000 can't access 16-bits per cycle, not in practice and not in theory. This has nothing to do with the microcode or opcodes. As already said by others, a 68000 bus cycle takes 4 clock cycles. No external access can take less than that.

It is interesting you think the 68000 microcode is bad. Either you are trolling, or most of the industry didn't (and doesn't) agree with you. And again, the 4 clock cycles per bus cycle has nothing to do with microcode.

It is also wrong that it can't perform math operations and memory access at the same time. It can.Ijor (talk) 05:00, 6 December 2007 (UTC)

The thing I'm asking is why does everybody think the "every four cycles" limitation as such a very tiny and uneffective problem. It makes it FOUR times slower than every other 16/32-bit processor, giving it the equivilant performance of a 4/8-bit processor.

because then the clock rate gets increased. And that's not how bits work. Potatoswatter (talk) 00:02, 15 December 2007 (UTC)

And what makes you think it's pros are sooooooooo bigger than it's cons? I made a list of pros and cons of both cpus that you deleted because you think I'm trolling you. I am most certainly not trolling you. Your the one who is trolling. My post was perfectly unopinionated and you came here and deleted my post because you think your opinion is always the best, while I only displayed mathematically proven facts, and even gave you an overlooked fact about the Sega licsense programming quality control policy that stated that every game developed on Sega Genesis had to be cycle counted or else no release. I read that from an old Nintendo Power magazine from 1995. Thankfully I have my pro and con list saved on my computer. here it is:

65816 PRO: it can access memory every cycle

68000 CON: it can access memory only every four cycles

here it seems like the 65816 goes 4 times faster but I'll go on.

65816 CON: it only has an 8 bit data bus

68000 PRO: it has a data bus 16 bits wide

Okay now the 68000 is twice as much as a forth of a 65816 which means it's half as fast.

65816 CON: it runs at 3.5mhz in snes

68000 PRO: it runs at 7mhz in sega

Now the 68000 is running at twice as fast as half as fast as 65816, which means that a they are both running at the same speed now.

65816 PRO: even though the real bandwidth is the same, this chip can use it's accessed bits more wisely. Such as:

-instructions are 8-bit long

-data words can be 8-bit or 16-bit long

-addresses can be 8-bit, 16-bit, or 24-bit long.

It takes much shorter time to load instructions, data, and addresses, because they can be a smaller amount of bits than the 68000.

68000 CON: it just can't get as much information out of it's bits as much as 65816 can.

-instructions take up 16-bits

-data words take up 16-bits

-addresses take up 32-bits.

Because they use more bits, they take more time to load.

Ouch, 68000 just isn't very good at utilizing it's bytes like the 65816 does but there is still one more thing to talk about:

65816 CON: has an accumulator, two other multi-purpose register, a stack pointer, a few page/bank select registers, a program counter and THAT'S IT?

68000 PRO: it has 8 multipurpose registers, 7 address registers, a stack pointer, and a program counter.

The 68000 has more registers and the 65816 has better bandwidth. End of story —Preceding unsigned comment added by 75.58.58.238 (talk • contribs)

It wasn't Potatoswatter who removed your post, it was me. Not because it was opinionated, which is fine, but because of its overly confrontational tone and use of labels such as "stupid idiots" and "freakin idiots" to describe users who disagree with you and "crap" to describe their opinions. Please see WP:CIVIL and WP:NPA. Miremare 00:48, 17 December 2007 (UTC)

I'd like to correct the misunderstanding that the 65816 uses microcode. One of the reasons it can access the bus every cycle lies in the fact that it does not utilize microcode. The PLA performs both state tracking and state decoding using a fairly sizable and/or matrix. -- Samuel A. Falvo II, 2010 July 11. —Preceding unsigned comment added by 173.11.86.21 (talk) 16:35, 11 July 2010 (UTC)

Optimized code

Maybe it would be an idea to add more information about assembly instructions that achieved the same thing but faster?! e.g. if I remember correctly sub.l d0,d0 was much faster than clr.l d0 but I don't know this for sure! —Preceding unsigned comment added by 80.213.173.129 (talk) 16:52, 23 November 2009 (UTC)

Counting general registers

Currently the infobox says 8 general registers which is imho fairly misleading. The address registers, while not omnipotent are still much more "general" than "general registers" of most RISC CPUs. They can be used as source or destination op in complex arithmetic expressions and load/store values from memory with few restrictions (much fewer than typical RISC general register). Opinions? Richiez (talk) 09:57, 6 February 2011 (UTC)

I agree that D0-D7 and A0-A7 are general purpose registers by any sane definition of the term.

Right now the page reads...

gpr = 8 × 32-bit + 7 address registers also usable for most operations + stack pointer.

Before it was simply...

gpr = 8 × 32-bit

I think it should be...

sr/ccr = 1 x 16 bits

ssp = 1 x 32 bits

msp = 1 x 32 bits (68020 and higher only)

gpr(total) = 16 × 32-bits, consisting of:

gpr/data = 8 × 32-bits

gpr/address = 7 × 32-bits

gpr/usp = 1 x 32 bits

It has been a while since I programmed a 68000, but I believe the register count is as follows:

8 x 32-bit registers, D0-D7, usable as data or general purpose registers

7 x 32-bit registers, A0-A6, usable as address or general purpose registers

1 x 32-bit register, A7, usable as a user stack stack pointer or general purpose register

1 x 32-bit Interrupt Stack Pointer AKA System Stack Pointer (not usable as a register or accessible in user mode)

(68020 and higher) 1 x 32-bit Master Stack Pointer (not usable as a register or accessible in user mode)

1 x 32-bit (only 24 bits are used to generate RAM addresses) Program Counter

1 x 16-bit Status Register / Condition Code Register (16 bits accessible in supervisor mode, lower 8 bits accessible in user mode)

Corrections/comments are welcome. In particular, did any of the 68000 parts use memory management to make use of the top-bits of the program counter?

BTW, http://en.wikibooks.org/wiki/68000_Assembly is available under the Creative Commons Attribution-ShareAlike License, so we can lift anything we want (with attribution) from it and use it here. Guy Macon 20:07, 6 February 2011 (UTC)

My change was just a quick fix to the infobox, later noticed that 68k family page has something else yet.. does not seem in any way uniform across the various architectures. So it should be at least informative - and consistent with M68k. Not sure what exactly you mean with memory management in the top bits of PC, many systems of the time abused the bits for some purpose which turned out incompatible with later changes. Otherwise your list seems correct but not sure if it fits into the infobox. Richiez (talk) 00:42, 7 February 2011 (UTC)

All CPU's are 8 bit

"8 × 32-bit + 7 address registers also usable for most operations + stack pointer"

It can't be. There should be 8 32-bit address registers and 7 32-bit data registers. But if to be honest, all datasheets after very firsts are nonsenses. Only those very first are correct, in my opinion. More and more nonsense put into newer and newer CPU manuals (like cache, which don't exist; no wonder 486 have 8k of cache, which mean 8 registers and k can be equal to 1, so lieing). There is very important thing, that if there is 8 bit data bus, then you can use address bus of 16 bits or 32 bits and it will work with not doing changes to instructions at all! So thats why I think all CPU must be 8 bits (have 8 bits data bus). Coprocessor like intel 8087 to intel 8086 CPU have 80 bits data bus with memory or 64 bits data bus with memory. So big possibility that the same memory module (of 16 chips) have half chips for CPU and half chips for coprocessor. And CPU with coprocessor comunicating also through 8 bits data bus. Only after data loaded to coprocessor registers (and then maybe to coprocessor memory RAM) it is in 80 bits or 64 bits format. CPU registers are 16 bits for most CPUs like Intel 8080, but data bus is 8 bits (need two cycles to load data to CPU register).

Here good proposal what cache can be (page 73 for Acrobat Reader or 61 on list; 5.6 ZERO PAGE ADDRESSING). This is about 6502 CPU, which (or similar) used in NES. So 6502 CPU have 16 bit address bus and 8 bit data bus. For addressing memory need sent lower address 8-bits (after opcode) through data bus and in third cycle (first cycle for opcode) need sent higher address 8-bits. So if in second cycle bits are 00000000, then memory accessed faster (need only two cycles, instead 3 cycles). So memory have 256 pages and each page 256 8-bit empty spaces. So page, which accessed with address 00000000 can be in my understanding as cache, because it is recommended to use first page (00000000) for frequently used instructions or constants. So from this not hard to see, that if you have memory with bigger pages, you have faster instructions or programs execution. Maybe this is also meaning of DDR SDRAM (DDR double data rate [for first page]).

Even 64 bit CPU like Core i7, have 16 bit segment and 64 bit offset. So 16 bit to choose memory (RAM) page and 64 bits for address in chosen page. And if page address is 0000000000000000, then it also 1 cycle faster. Maybe this is what cache is about. Or maybe cache is on [CPU] chip RAM pages? Maybe instead of first RAM pages, CPU puts all data into caches, and when pages address is too big, then it is not cache on CPU chip, but external RAM.

Also interesting thing that 6502 RAM address 0-21845 using for RAM; address 21845-43690 using for I/O; address 43690-65536 for ROM. — Preceding unsigned comment added by Paraboloid01 (talk • contribs) 21:00, 15 September 2012 (UTC)

Please not that this discussion page is for discussing improvements to the article. It is not a general forum for discussing the subject in general. 86.130.168.254 (talk) 12:22, 17 September 2012 (UTC)

You, see, I calculated number of wires going to each of 16 chips of RAM (DDR2-800 [400MHz] in my case). So number of wires is, hard to tell, maximum 31-40 wires (but it's unrealistic, because I almost half from over side counting as not the same, so 40 is supermaximumimaginary) and minimum about 16-20 wires. So to exploit design of 64-bit data bus and 64-bit Address bus, TO EACH CHIP [of 16] must go 64 wires for address bus and 4 wires for data bus (4*16=64). So my computer is with 64-bit CPU and DDR2 is also for 64-bit CPU. And in intel datasheet it also says, that instead 16 bit segment selector and 32 bit offset, there is 16 bit segment selector and 64 bit offset to address memory [in 64 bit mode]. So you see it appears that in 64 bit mode need more cycles to address memory, than in 32 bit mode (like Pentium, Pentium II, Pentium III, Pentium 4). So maybe everything is OK, need just waist for initialization more cycles in 64 bit mode than in 32 bit mode, but this is not that should correspont to intel datasheet. BTW old RAM chips (for Pentium II) have more than 36 wires (actually I counted only more than 36 pins of old RAM chips, but number of wires looks quite convincing) each of 16 chips (for 32 bits RAM 32 wires is for address and 4 wires for data per each chip of 16; actually combination like 4 chips [RAM] and 32 wires for address and 16 wires for data bus is also correct). So maybe there really is 8-bit data bus and 8 bit address bus even on most new RAM (RAM address is chosen sending through data bus 8 bits two times, so addressing 2^(8+8)=65536 bytes). Maybe now Bill Gates phrase "nobody will need more than 64 KB of memory" doesn't sounds so funny? — Preceding unsigned comment added by Paraboloid01 (talk • contribs) 17:08, 9 October 2012 (UTC)

One explanation I found, is that for 32 bit CPU you can store or 2^32=4294967296 of 8-bit integers or 4294967296 16-bit integers or 4294967296 32-bit integers or 4294967296 64-bit integers. Do not matter what you storing (8 bit integers or 64 bit integers), there still is only 4294967296 places (I don't counting of using 16 bit segment selector). So if don't use segment selector, then on 32 bit CPU you can store 4294967296(addresses)*64(bit)=274877906944 bit of data or 274877906944/8=34359738368 bytes = 32 GB (32*1024*1024*1024 bytes). So I have only 1 GB DDR2 RAM module (thus it is 16 chip of 64 MB each). So 1 GB = 8 Gb and so 8192(Mb) / 64(bit) = ~128 millions of addresses. And 2^27 =134217728 addresses. So it turns out that no matter if your CPU is 32 bit or 64 bit, 27 wires is enough. So then such combination 27 wires for address bus and 4 wires for data bus for each chip (each chip of 16 MUST have 27 wires for address bus). This gives 27+4=31 wire if not counting GND (-) wire. So simply there maybe just don't need more wires for address bus if memory don't have such number of address (I mean if memory don't have 2^32=4294967296 addresses, but have 2^27 addresses, like in mine 1GB RAM memory module case). This theory of 31 wire looks very convincing, but I fell like there is about 16-24 wires per chip, maybe I wrong, or maybe there really is just 8bit CPU or 3 cycles with 10-bit directory, 10-bit something in directory and 12-bit something with page and it is 10+10+12=32, only don't know how this explain for 64-bits addressing RAM. Something maybe not with segment and offset, but then why they don't make up they mind what they trying to say about linear to physical address and then again about segment selector and offset, which then is true (and then how they do compatibility with older CPUs like 8086/8080, if they trying to go away from 16-bit segment selector and 32-bit offset, instead 8-bit segment selector and 8-bit offset for 8080, or 16-bit segment selector and 16-bit offset for 286)? — Preceding unsigned comment added by Paraboloid01 (talk • contribs) 19:02, 9 October 2012 (UTC)

BTW 286 theory with 16-bit two times passing for address and 16-bit data bus looks quite convincing. Then it can address 2^32 addresses or 2^32 *64=274877906944 Gb=34359738368 GBytes= 32GB. Now maximum memory (RAM) module is 8 GB. And then for each chip 1 wire for data to form 16 bit data bus. So then (16+1)=17 wires (18 wires with minus or 19 wires with "+" and "-" power supply) for each RAM chip of 16 chips is convincing (but 8-bit CPU then looks still more convincing from phylosophical or GOD point of view, because if cheat then cheat everywhere, beginning from intel8080, Z80, Motorola6800, MOS6502, even 8086 can be part of cheating with they coprocessor 8087).

Actually 286 can have then maximum 2^32 *16=68719476736 bits of RAM or 8 GB. But 287 (the coprocessor of 286) operating on 64-bit data (integers etc), so then maybe 287 using RAM and need for 287 coprocessor for 64-bit data bus 16+4=20 wires (or 22 wires with "+" and "-") for each chip of 16 (16 chips *4 wires =64 bit data bus for 287). — Preceding unsigned comment added by Paraboloid01 (talk • contribs) 19:39, 9 October 2012 (UTC)

Re: "All CPU's are 8 bit" See mPD6124A / 6600A Datasheet. I'm just saying. --Guy Macon (talk) 16:49, 27 March 2021 (UTC)

6808

If I remember correctly the 6808 was used in the Radio Shack Color Computer and was originally developed to use in the development of operating systems. — Preceding unsigned comment added by 75.174.60.52 (talk) 21:11, 24 September 2013 (UTC)

The Radio Shack Color Computer used a 6809E. Totally different processor and unrelated to the Motorola 68000. — Preceding unsigned comment added by TMorita (talk • contribs) 07:51, 30 November 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Motorola 68000. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20130516004618/http://www.highbeam.com/doc/1G1-8581526.html to http://www.highbeam.com/doc/1G1-8581526.html
• Added archive https://web.archive.org/20130516055858/http://www.highbeam.com/doc/1G1-10706635.html to http://www.highbeam.com/doc/1G1-10706635.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 05:51, 27 August 2015 (UTC)

Neither of those worked, and they don't seem to be available anywhere obvious on the Intertubes, so I just got rid of the links. Guy Harris (talk) 21:43, 14 September 2017 (UTC)

X68000 hatnote

I don't think the fact that the X68000 uses this CPU is enough to make the confusion plausible. Any objections if I remove the hatnote? Or does someone want to cite a source that gives an example of such confusion? --SoledadKabocha (talk) 04:12, 20 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Motorola 68000. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://mot-sps.com/press/html/PR961118B.html
• Added archive https://web.archive.org/web/20090113224358/http://archive.comlab.ox.ac.uk/cards/m68kfaq.html to http://archive.comlab.ox.ac.uk/cards/m68kfaq.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:31, 14 September 2017 (UTC)

Example Code

Hi, I noticed that the example code opcodes seem to be wrong compared to the output from an assembler. For example, 'link' was set to CE56 which has the top 2 bits set but the 68000 instruction set specifies the top bit is unused for that operation. I've corrected these but let me know if that's a mistake - especially user AnotherUniqueName who modified one of the opcodes before me. Thanks! Loweredtone (talk) 11:34, 1 March 2018 (UTC)

Transistor count citation - a product of citogenesis?

An IEEE Spectrum article was used as a citation for the transistor count on the MC68000 being 68000 transistors, with the edit summary being "Assuming the number of transistors is correct, and they didn't just take the number from here. IEEE should at least usually be credible."

Unfortunately, the number might, indeed, have been taken from here, in an example of citogenesis. The picture of the 68000's die and the picture of a packaged chip both link to images from Wikipedia, so the writer might have consulted Wikipedia when writing the story.

For what it's worth, the last version of the comp.sys.m68k FAQ I found on the Wayback Machine gives a transistor count of 68000 for the MC68000 and 70000 for the MC68008; it's not inconceivable that the 68008 has 2000 more transistors, but, given that the 68008 is allegedly a 68000 with an 8-bit data bus, would that be 2000 extra transistors just to do more bus cycles? Guy Harris (talk) 16:29, 12 October 2019 (UTC)

Given that the 68008 was a later, smaller-bus version of the 68000, it's possible that it requires additional logic to emulate a 32-bit bus internally.

However, the transistor count of 68,000 for the MC68000 was propagated by Motorola themselves, and even occasionally doubted back then. Short of some expert actually counting or seriously estimating the number from the die, we have to believe it I guess (I remember reading "more like 62,000" some time around 1985 but can't locate a source now, of course). [...] The oldest source I can find is Microprocessor Architectures and Systems: RISC, CISC and DSP by Steve Heath from 1991 that says the exact same. --Zac67 (talk) 16:59, 12 October 2019 (UTC)

OK, I went with the second edition of that book (in which the quote saying it had approximately 68000 transistors isn't split between pages); that's still old enough that he obviously didn't crib it from the Wikipedia article. Guy Harris (talk) 17:32, 12 October 2019 (UTC)

The Motorola 68000 is internally and externally 16bit, you say?

• "Motorola 68000 (MC68000) is the first member of 680x0 line of microprocessors. Internally the 68000 is a 32-bit microprocessor - it has 32-bit data and address registers. Externally the processor has 16-bit data bus and 24-bit address bus, which limits the size of addressable memory to 16 MB. Motorola also made 68008 - a version of 68000 CPU with 8-bit external data bus."[1]
• "The industry's lowest cost 32-bit microprocessor, the MC68000 offers an excellent low cost entry point to the M68000 Family. The MC68HC000 is a CMOS version of the original MC68000. The MC68HC001 is also a CMOS version of the original MC68000 with 8-/16-bit selectable data bus."[2]
• "The Atari ST was a home computer released by Atari in June 1985. The letter "S" and "T" were short for "Sixteen/Thirty-Two," a reference to its 16-bit bus and 32-bit CPU; the Motorola 68000."[3]

--Guy Macon (talk) 16:32, 27 March 2021 (UTC)

Oh look, somehow the entire talk section has mysteriously disappeared and all that's left of it is this argument, after I was threatened with having my own account limited after removing a mere section of the previous huge talk page for not establishing anything. How strange, I wonder why that is? :rolleyees:

The first quote is unreliable: Internally the 68000 does have 32bit areas, reserved for the register storage, but even on-die register-to-register moves take 4 clock cycles. It also has a 16bit ALU, so the claim "Internally the 68000 is a 32-bit microprocessor" is based merely on total space allocated to the register compartments, which are placed on a separate section of the CPU die to the 16bit ALU. This does not make for a chip which is internally 32bit.

The second document merely states the 68000 is 32bit, it doesn't say where this estimation comes from. The 68000 has a 16bit data bus and a 16bit ALU, so it clearly cannot be reliably classed as a 32bit microprocessor. The post above is just cherry-picking, "This document says what I want to hear".

The third document is mere advertising. On this third count you could hardly want for a less impartial source besides fan-base evangelism. All the post above reads like the outcome of a Google search followed by a cut&paste of any random thing on the internet which states what the person posting them wants to hear, irrespective of how poorly founded or how obviously it has vested interests in upping the outcome.

Finally: Even if we assume total ignorance of the topic, as per our previous discussion, the sole independently observable features you currently have are the external address and data busses, and neither of them are 32bit. Vapourmile (talk) 11:07, 30 March 2021 (UTC)

For the record, the "mysteriously disappeared" sections are the result of this edit[4] which archived years-old WP:BLUDGEONING. --Guy Macon (talk)

Oh? And how do you explain the fact the first comment that mysteriously appeared was written by you, about this from which, after making overtures about "reliable secondary sources" uses no sources which are both authoritative and independent, and crucially none those sources you chose provide a technical explanation for their conclusion. Certainly none to match the physical technical explanation for my conclusion which I have provided over and over again for two years? Also, if you really believe register size uprates the CPU rating then when you are going to start policing the Intel pages ensuring all the Intel CPUS are upgraded according to their register size to ensure Wikipedia isn't in breach of its own impartiality rules? I have already provided you the primary source showing Intel downrated their 16bit CPU to 8bits despite the fact it is entirely 16bit internally based on nothing but the reduction of the data bus to 8bits. If the 68000 is 32bit then why in the 8088 8bit? Your argument is obviously not technically consistent with facts across different architecture. Mine is. You are not an impartial judge, I am. If you can't get past your emotional investment in Motorla then we are just as well to keep in the family: The 68020 is 32bit, the 68000 is 16bit. As I have already said: Everything else is just fog posted by the 68000 fan base. If you want the 68000 upgraded based on its die, then upgrade everything else too. Vapourmile (talk) 15:25, 30 March 2021 (UTC)

@Vapourmile: We've already agreed to disagree. (I'm totally fine with "16"/32-bit".) Can you please leave this be? --Zac67 (talk) 13:38, 30 March 2021 (UTC)

Why didn't you address that comment to Guy macron? It wasn't me who deleted all 160,000+ characters in this talk section except to throw mud at this wall again. If the 68000 is 16/32bit then the Intel AVX512 extensions make that CPU 32/512bit. Is that what you think it is? Is that what anybody thinks? No, nobody thinks that because it doesn't make sense. I'm happy to continue correcting people. If you want an agreement, agree that 16bit is the only designation that makes any technical sense for the 68000 else we have to go back and rethink every other CPU which can have any-feature-you-want introduced into the debate. The standard way to measure the rating of a CPU is through the bus. It's a 16bit data bus, attaching to a 16bit CPU socket, fitting 16bit motherboards with 16bit RAM. Any operation performed on the chip enters the real-world 16bits at a time. Ergo: There is no valid route from that to "but it isn't 16bit". "Oh but we found something, there's a 32bit register space"? So what? The AVX512 extensions are a 512bit register space. Are the Intel Core-X CPUs 512bit? Let me help you with that: No they aren't. So why change the rules just for the 68000 but for nothing else? As I said to Guy.... if you want to argue the 68000 is somehow 32bit, based on nothing but on-chip register space, then why don't you start policing the Intel pages, changing all the bit ratings according to their register size too? I'll tell you why you don't do that: Because you aren't an independent witness. With my proposal, all CPUs are rated the same way. The same way the industry had always rated them for years, until Motorola's marketing brains came along and cooked up the idea we should change the rules uniquely for the benefit of the 68000. With the "16/32bit" route we have a special unique set of rules which only apply to the 1979 68000 and nothing else, drawing from the details on the CPU die. If you think that's a valid argument then it becomes a valid argument for the extended register sizes on the entire Intel range too, and you have a lot of editing ahead of you uprating the entire Intel product range from the 8088 upwards to protect Wikipedia impartiality. As I've said many times, the argument the 68000 is in any way 32bit is like saying a motor vehicle engine with 6 cylinders is a 6/12 cylinder engine because of some other feature you've identified unrelated to the cylinder count. If you want to settle then either settle on the fact the 68000 is not 32bit or start editing every Intel CPU released since the 8088 to match. Personally, I'd go with the version which isn't dishonest and accept the 68000 has a 16bit ALU, a 16bit RAM interface (meaning .l instructions from main memory move 16bits at a time, because it's 16bit) and it fits into a 16bit motherboard (the principle chip rating criteria of its era borne of physical computer systems engineering considerations, not fan theories) and it talks through a 16bit data bus, hence, it is 16bit. Motorola fans: "Yeah but it's 32bit somehow anyway". If you want to settle, settle on the fact it is a 16bit microprocessor, because that's what it is. Vapourmile (talk) 15:25, 30 March 2021 (UTC)

Vapourmile, the talk page content was not deleted. It was archived by user:HandThatFeeds . It's all still there. See Talk:Motorola 68000/Archive 1 and Talk:Motorola 68000/Archive 2. The only editor who has recently attempted to delete content from the talk page is you. Meters (talk) 03:26, 31 March 2021 (UTC)

At nearly 200 170 k the talk page was almost four-times more than three times the size of the entire article, and some of it was 18 years old. It was long past time it should have been archived. If you think that some of the archived content should be restored then please take it up with the archiver. Meters (talk) 03:33, 31 March 2021 (UTC)

Vapourmile, quite simply MC68000 is 32/16 bit CPU because it's 32 bit ISA implemented in 16 bit hardware. And no, you can't call Intel CPU 512 bit because AVX512 is an extension of ISA, not ISA itself. Same way as you can't refer to FPU data width or format too. Intel CPUs have 64 bit ISA implemented in 64 bit hardware so they are 64/64 bit.

There are other examples like this. PDP-8 was 12 bit ISA, but had both 12 bit and 1 bit serial implementations. So we could say that serial PDP-8/S was 12/1 bit, but definitely not 1 bit machine. Similarly there were PDP-11 CPU implementations on 8 bit hardware, making them 16/8 bit CPUs. Also, would you call Z-80 an 8 bit CPU? I guess yes, obviously. However do you know it had 4 bit ALU internally? In this case, only ISA matters.

So, if hardware width doesn't match ISA width, it's quite reasonable and clear to use both numbers. Like 32/16 for 68000. — Preceding unsigned comment added by 194.187.155.245 (talk) 11:55, 7 April 2021 (UTC)

The copy immediately above is just straw-clutching nonsense. Quoting the same person above on one of their own edits "There were no 32 bit busses in 68000. The actual data bus used with data registers was 16 bit wide, same as ALU". Yes, and that is what makes it a 16bit CPU. Talk about "The ISA" should be disregarded, it isn't relevant. The 68000 instruction word-length is also 16bit and the operands are retrieved from main RAM a maximum of 16bits at a time, because it is 16bit. Vector processors can have instructions which take theoretically any number of system words from main RAM, anything more than 16 bits on a 68000 is NOTIONAL *NOT* PHYSICAL. Guy Harris was utterly obsessed with talking about "the ISA" and older computers so if I was a gambling man I'd bet this was Guy Harris, piping up with the save nonsense again, not signing so as to conceal his identity. "The ISA" as you keep calling it, has absolutely no relevance because (and read this really carefully): *It is NOT a PHYSICAL, nor behavioural, characteristic the processor*. There are 32bit assembly languages for the 6510, it just daft to try to argue it has some relevance to underlying CPU classification. So stop going around in circles saying the same impertinent thing dozens of times in a row, as is what happened in the archived discussion. It is an irrelevance. It is clutching at straws. It is shooting in the dark. The operational characteristics of the 68000 are 16bit. Nothing else is relevant. "Also, would you call Z-80 an 8 bit CPU? I guess yes". Yes, it's 8bit because its classification is consistent with the same explanation for how CPUs are classified I have been giving you unaltered for weeks. "And no, you can't call Intel CPU 512 bit because AVX512 is an extension of ISA, not ISA itself", wrong, the 512bit instructions are *definitely* among the instructions, it's a contradiction to deny it. That is both incorrect and NOT the reason an Intel Xeon is NOT 512 bit. It's you again Guy, isn't it? Because once again the topic is the 68000 and once again you want to talk almost exclusively about old mainframes and various topical irrelevances. You want to talk about things that are irrelevant or wrong or both, that's Guy's MO. Vapourmile (talk) 20:26, 8 April 2021 (UTC)

"It's you again Guy, isn't it?". No, it isn't. I don't live in Ukraine, I am not currently in Ukraine, and am not using any technology that would make it appear as if my IP address was an address from WestNet in Ukraine. Guy Harris (talk) 21:54, 8 April 2021 (UTC)

Vapourmile, I am close to my limit putting up with your behavior. Knock it off and start treating other editors with respect and civility or there will be consequences. --Guy Macon (talk) 23:24, 8 April 2021 (UTC)

Consequences? What are you going to do? Stop me adding corrections so that the only people allowed to comment are those who so fundamentally don't understand the subject that they don't even understand when their comments are not even about the subject? Your limit? If it isn't having to contend with people arguing about CPU classifications who don't understand how CPU classification works then it's additional unjust threats of account restrictions which appear to constitute nothing better than aggravated coercion. I think it would be far better if you started issuing threats of account restrictions to the people who are the source of the problem, or if not then at least accept you don't really understand the issue sufficiently to be here acting as judge. The problem is people with internet connections who can use Google to read for long hours on their hobby-interest but don't know what to look for or what's relevant in this context but still want to hold forth on the content of their reading. If you're looking for something to administrate over then why don't you start directing threats at people commenting who can't even tell what's on topic? This is like having a row on a Harley Davidson page about how many cylinders there are in a 1969 Harley Davidson Shovelhead with people who mainly want to talk about McNaught engines and can't even determine that this isn't the place. Your comment constitutes an unjust threat. WP:ADMINACCT WP:NEUTRALVapourmile (talk) 07:56, 9 April 2021 (UTC)

Vapourmile, the accusation of sockpuppeteering is a serious allegation. I'd urge you to reconsider your statements. --Zac67 (talk) 06:13, 9 April 2021 (UTC)

"the accusation of sockpuppeteering is a serious allegation". Show me the Wikipedia guideline which says this. Meanwhile, here are just a few reminders of the Wikipedia policies on sock-puppetry and meat-puppetry. This is not an accusation. Just useful information on what the policy guides actually do say. WP:SOCK WP:EWLO WP:CRONY WP:NEUTRAL WP:BOOMERANG Vapourmile (talk) 07:56, 9 April 2021 (UTC)

@Vapourmile: Thank you, you've just confirmed that you're being rude without necessity and not amenable to reason and good advice. Maybe you should have read WP:CIV. Don't bother replying, I've read enough from you and will ignore you in the future. --Zac67 (talk) 09:27, 9 April 2021 (UTC)

Vapourmile, no, I'm not Guy. And don't forget, if you fail to understand something, it doesn't necessary mean that it's a nonsense. You see, I'm not trying to persuade you to change your mind. I'm only explaining you why it is most commonly accepted that 68000 is a 32/16 and not 16 or 32 bit CPU. The reasons and examples I have mentioned illustrate other ambiguous cases when commonly accepted classification is made similarly in one way or another. There is no explicit rule how to classify these machines. The one you've made up for yourself is subjective.

"Yes, and that is what makes it a 16bit CPU" - no, this is necessary but not sufficient to call CPU 16 bit. It is sufficient however for CPU to be not 32 bit. And it is not. It is 32/16bit.

"The 68000 instruction word-length is also 16bit" - instruction word length is never used for CPU bit width classification. Transputer T414 is a pure 32 bit CPU with 8 bit instruction word. Even IA-64 has arguably 8 bit instruction word.

"operands are retrieved from main RAM a maximum of 16bits at a time" - data bus can't be used either. Unless you consider 68008, 8088, T-11 to be 8 bit, and Pentium to be 64 bit.

"Vector processors can have instructions" - sure they can, and that's why they are called vector. 68k is not one of them though.

""The ISA" as you keep calling it, has absolutely no relevance" - ISA is a common abbreviation for Instruction Set Architecture. Sorry, I thought you are aware of it. And yes, you may think it's irrelevant. That is your opinion. But it's not the most commonly accepted one.

"It is NOT a PHYSICAL, nor behavioural, characteristic the processor" - First of all, this statement is false. In fact ISA in some cases is the only behavioural characteristic of CPU. Secondly, CPU is not a blender, it processes information not physical substance, so it has not only physical characteristics. And it's actually impossible to objectively say which one is more important. So in most cases when one is not matching the other, there's an ambiguity.

"There are 32bit assembly languages for the 6510" - you don't quite understand what ISA is, do you? Assembly, or any other language, is not a CPU instruction set.

"The operational characteristics of the 68000 are 16bit" - give me strict definition of the "operational characteristics" that you use, this may be interesting.

"I have been giving you unaltered for weeks" - not me. This is my second message here.

"wrong, the 512bit instructions are *definitely* among the instructions, it's a contradiction to deny it." - really? Then address bus is among CPU busses, isn't it? And what about microinstruction width? These are all among physical properties of CPU. In reality it's easier to specify what ISA extension is, than to specify which CPU units should be ignored. For example, Pentium has 64 bit data bus, it has 80 bit registers and execution unit including ALU and a bus. But it's still 32 bit CPU. And only because of ISA, and because 80 bit part is only used by ISA extension. Now, ISA extension is part of instruction set that can't be used to write any possible program. You can write any program with commands that use 32 bit registers for IA-32, but you can't do this using only FPU or any other extension data types. In case of 68000 you can use 32 bit data types with all instructions. So it's not an extension to ISA. So it's actually determined by ISA what parts of CPU hardware we look at to figure out it's bit width. — Preceding unsigned comment added by 194.187.155.245 (talk) 09:26, 9 April 2021 (UTC)

Vapourmile stated: Oh look, somehow the entire talk section has mysteriously disappeared and all that's left of it is this argument, after I was threatened with having my own account limited after removing a mere section of the previous huge talk page for not establishing anything. How strange, I wonder why that is? :rolleyees:

Please assume good faith. I came here after seeing a dispute on ANI, and saw that the talk page hadn't been archived in years, and was incredibly large. I decided to archive every discussion which had begun prior to our current year, as it's considered inappropriate to resurrect months-old discussions anyway. This had nothing to do with your debates themselves, only the fact that I felt the old discussions needed archiving so we could have a fresh start.

For the record, I've made a personal project out of archiving old Talk page discussions & setting up an ArchiveBot to automatically take care of archiving afterwards. This is nothing new for me, see User:HandThatFeeds/ArchiveProject.

That said, you're free to discuss the issue with others once again, and refer to the Archives for points previously made. I am not weighing in on the debate itself, just cleaning up this Talk page. — The Hand That Feeds You:^Bite 13:34, 31 March 2021 (UTC)

As Meters wrote at ANI:

"...what appears to be a false statement in the opening justification in this request for action against Guy Macon. After the full comments section was subsequently archived, Guy was the first to remark on the talk page, immediately rekindling the same unproductive argument. is false. Guy posted to the page at 16:32 [5] and at 16:49 [6], the page was archived at 19:00 by user:HandThatFeeds [7], and the next content edits were two days later, by Vapourmile [8]. Note that Vapourmile appeared to be aware that he was starting the discussion up again rather than replying to subsequent comment as Vapourmile started off with "Oh look, somehow the entire talk section has mysteriously disappeared and all that's left of it is this argument"

So, factually incorrect as well as not assuming good faith. See Wikipedia:Administrators' noticeboard/Incidents#I would like to officially complain about the editor Guy Macon. --Guy Macon (talk) 22:27, 14 April 2021 (UTC)

Here are those sources once again

• "Motorola 68000 (MC68000) is the first member of 680x0 line of microprocessors. Internally the 68000 is a 32-bit microprocessor - it has 32-bit data and address registers. Externally the processor has 16-bit data bus and 24-bit address bus, which limits the size of addressable memory to 16 MB. Motorola also made 68008 - a version of 68000 CPU with 8-bit external data bus."[9]
• "The industry's lowest cost 32-bit microprocessor, the MC68000 offers an excellent low cost entry point to the M68000 Family. The MC68HC000 is a CMOS version of the original MC68000. The MC68HC001 is also a CMOS version of the original MC68000 with 8-/16-bit selectable data bus."[10]
• "The Atari ST was a home computer released by Atari in June 1985. The letter "S" and "T" were short for "Sixteen/Thirty-Two," a reference to its 16-bit bus and 32-bit CPU; the Motorola 68000."[11]

Can we discuss these sources without any personal attacks, please? Are there any reliable sources that don't call the 68000 "32-bit" or "16/32 bit"? Please focus on what the sources say, and not on the reasoning of individual editors (also known as WP:OR and WP:SYNTH). --Guy Macon (talk) 22:33, 14 April 2021 (UTC)

• As on my user talk page, I'll start you off:
  • Bacon, Jean (1986). The Motorola MC68000: An Introduction to Processor, Memory, and Interfacing (7th ed.). Prentice-Hall International. p. 13. ISBN 9780136041092. The 68000 is called a 16-bit microprocessor because it fetches data 16 bits at a time from memory.
  • Veronis, Andrew M. (1988). The 68000 Microprocessor. Springer Science & Business Media. p. 2. ISBN 9780442288426. a powerful 16-bit microprocessor — the Motorola MC68000 — will be referred to from time to time
  • Rafiquzzaman, M. (2005). "Motorola MC68000". Fundamentals of Digital Logic and Microcomputer Design (5th ed.). John Wiley & Sons. p. 457. ISBN 9780471733492. The MC68000 is Motorola's first 16-bit microprocessor.
  • Swaine, Michael (1981-11-30). "16-bit revolution, pt. 1: Defining/confining terms". Infoworld. Vol. 3, no. 28. pp. 38–39. ISSN 0199-6649. What determines whether the microprocessor, and hence the microcomputer built from it, is a 16-bit […] machine is the size of the data bus. […] The MC68000 […] and TMS99000 […] use a 16-bit data bus.
• Mohamed Rafiquzzaman is a Ph.D in electrical engineering. This is Michael Swaine. We know who Jean Bacon is. Andrew M. Veronis was a Professor in the Department of Computer Science at the University of Maryland. Gennadiy Shvets doesn't say what xyr qualifications are, and isn't Gennady Shvets.

  Veronis is actually a source that I recommend, because Veronis 1988, p. 5 goes on to support the multiple ALUs part. But, with the exception of Swaine, these are all good sources for the rest of the article which has a dearth of sourcing. Why except Swaine? Because Swaine was really talking about 16-bit microcomputers, of which the CPU was just one part, and making a case for a "16-bit revolution" happening. Elsewhere in the article xe does talk about address buses and register widths, though. The professors et al. are writing detailed technical documentation in textbooks with publishers of good repute.

  Personally, I think that it's right to just explain the different parts, and then state how the processor was described by the manufacturer, and not get into what the "bitness" is of a system whose different parts have different word widths. Readers want to know what the manufacturer said, and what the precise details are. Anything else on the general nomenclature of microcomputers, as is clearly evident from Swaine 1981, applies to far more than just this microprocessor and doesn't belong here.

  Ironically, the datasheet one hyperlink away from your NXP page has Motorola calling it an "8-/16-/32- Bit Microprocessor", and what this article says (with no supporting source) about what Motorola called it probably needs adjusting, datasheet in hand and cited as a source.

  Uncle G (talk) 10:49, 15 April 2021 (UTC)

  • Excellent, now we're getting somewhere. While I don't fully agree with those source, they seem to be RS and mine isn't. How about this lede then:

    The Motorola 68000 (sixty-eight-thousand; also called m68k, Motorola 68k, sixty-eight-kay) is a 16-bit complex instruction set computer (CISC) microprocessor, introduced in 1979 by Motorola Semiconductor Products Sector. Motorola termed it a 8/16/32-bit processor. [source]

    The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[2] The address bus is 24-bits and does not use memory segmentation, which made it popular with programmers. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[2] and has a 16-bit external data bus.[3]

  • --Zac67 (talk) 11:00, 15 April 2021 (UTC)
  • PS: The April 1983 MC68000 Advance Information datasheet, subtitled "16-BIT MICROPROCESSOR" begins with The MC68000 is the first in a family of advanced microprocessors from Motorola. Utilizing VLSI technology, the MC68000 is a fully-implemented 16-bit microprocessor with 32-bit registers, a rich basic instruction set, and versatile addressing modes. --Zac67 (talk) 11:20, 15 April 2021 (UTC)
    • I think the main problem is the idea of stuffing this in the lead at all. It's the same problem that hits biographies on Wikipedia when people try to argue about who is "British-Irish-American-Samoan-French^{[1][2][3][4][5][6][7][8][9][10]}". The very problem is in trying to make the introduction into a Micropaedia and then make the first part of said introduction a Nanopaedia. I suggest this as a way forward: Don't go into all this detail in the introduction. Just have Motorola's description from the data sheet there. Then actually have something under the main "Architecture" sub-heading. Uncle G (talk) 11:56, 15 April 2021 (UTC)

Draft content

• "the three arithmetic logic units (ALUs) in the chip that do the address and data computations are all 16-bit." - strictly speaking this is not quite correct. It has one 16-bit ALU and two 16-bit Arithmetic Units (they can't do logic operations so can't be called ALU). Also, the arithmetic units work as a single 32-bit adder (they perform 32 bit addition in one microinstruction). Motorola call them ARITHMETIC UNITS and both as a single "limited arithmetic unit" in the patent US4325121A (https://patents.google.com/patent/US4325121A/en)

  Quotation from the patent:

  "A limited arithmetic unit is located in the HIGH and LOW sections, and a general capability arithmetic and logical unit is located in the DATA section. This allows address and data calculations to occur simultaneously. For example, it is possible to do a register-to-register word addition concurrently with a program counter increment (the program counter is located adjacent to the address register words, and carry out from the ARITHMETIC UNIT LOW 26' is provided as carry in to ARITHMETIC UNIT HIGH 38')."— Preceding unsigned comment added by 194.187.155.245 (talk • contribs) 2021-04-15T12:31:13 (UTC)

  • Patents are written by patent lawyers. Whereas it is conference papers that are written by engineers. ☺ Uncle G (talk) 14:38, 15 April 2021 (UTC)
    • ☺ Well, maybe, but this description matches actual die schematics and microcode. The arithmetic units indeed can't do any logic operations. So ALU is a wrong name for them by definition. And they do 32-bit additions in one microinstruction, as used at least once in every instruction. The output of the arithmetic unit low CLA is directly connected with input of the arithmetic unit high CLA (carry look ahead). There's no other carry input for the high word unit. Since I can't use the actual CPU schematics and microcode listings as a source for this information, the patent description part is probably the closest thing to reality that we can refer to. The patent also incudes microcode listings. Anther reverse engineered microcode listings may be found here: http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=2962 And the actual die schematics here: https://og.kervella.org/m68k/schem/ 194.187.155.245 (talk) 15:17, 15 April 2021 (UTC)
      • Alas, the above is an example of why we have problems on this page; Original research. Even if we are right we are not to draw our own conclusions based upon patents, microcode, or schematics. That is standard practice when doing engineering or technical writing, but an encyclopedia is different; we only include material that can be verified by a citation to a reliable secondary source. BTW, that post on spritesmind.net is a self-published source and cannot be used. --Guy Macon (talk) 15:38, 15 April 2021 (UTC)
        • Yes, of course, I fully understand and appreciate the problem of original research. That's why I'm not suggesting to use it as a source. As you can see, I was originally referring to the patent. And I'm not quite sure why you don't like it. After all, it doesn't really contradicts anything mentioned here, only adds more details. And I suppose, unless we can prove that the patent is wrong, we can't simply ignore it, can we? Please explain. Thank you. 194.187.155.245 (talk) 18:17, 15 April 2021 (UTC)
          • Re: "Please explain"; either you have a reliable secondary source that explicitly states something or you don't. If you do, post it and we will all work to make sure that the article reflects the source. If you don't have a reliable secondary source, please stop wasting our time talking about primary sources such as patents. I am not saying that you are wrong. I am saying that you either don't understand or are not willing to accept how Wikipedia works. I suggest that you take an entire evening and study WP:V and WP:RS. --Guy Macon (talk) 19:49, 15 April 2021 (UTC)
            • @Guy Macon: Thank you. But could you please be more specific about why exactly this particular primary source can't be used? Primary sources are not forbidden WP:PRIMARYNOTBAD, and there's one already referred here: "MC68000 8-/16-/32-Bit Microprocessors User's Manual". Here's what is said about primary sources: WP:PRIMARYCARE "primary sources may only be used on Wikipedia to make straightforward, descriptive statements that any educated person—with access to the source but without specialist knowledge—will be able to verify are directly supported by the source." And the citation I have provided from the patent is exactly that. Isn't it? It's a perfectly straightforward and simple description of the arithmetic and logic units used, that any educated person can easily understand. Don't you agree? Thanks. 194.187.155.245 (talk) 20:20, 15 April 2021 (UTC)

• @Uncle G: Disagree. They still provide valuable technical information so we can cite them. --AXONOV (talk) ⚑ 16:13, 15 April 2021 (UTC)

• They provide technical information run through the distortion function of patentese and legalisms. This is a good case in point about doing the research properly. Don't rely upon your personal decoding of a patent when two engineers from Motorola actually presented a conference paper on the processor design! This article has been around for twenty years and this is the first time that it's about to be cited. Uncle G (talk) 17:30, 15 April 2021 (UTC)

• @Uncle G: Lawyers can't distort information in this specific case. Otherwise such distortion would cause inconsistency and render patent irrelevant. The term «arithmetic unit» is perfectly possible to use. Every ALU component may be utilized separately. --AXONOV (talk) ⚑ 19:35, 15 April 2021 (UTC)
• @Uncle G: So you assume that patent is incorrect. But can you prove this assumption in any way? Why do you think that the conference paper contains more correct information than the patent? Even if you see any contradiction, and there's actually none, except for technically wrong terminology, which is not really a big deal, what prove do we have to support the conference paper and discard the patent? I have checked the patent, and it's correct. Have you checked the article? Was that article even supposed to be technically correct and complete? After all it's not a specs sheet or documentation of any kind. At least patent is fully official technical document. And it contain way more specific information about this CPU architecture than any other source cited here. So I think it would be very useful. BTW, there's a lot of other interesting details that could be cited here.194.187.155.245 (talk) 18:17, 15 April 2021 (UTC)
• @194.187.155.245: Please, use {{re}} tag to refer to a proper party and use correct indentation. Thanks. --AXONOV (talk) ⚑ 19:35, 15 April 2021 (UTC)

• @Alexander Davronov: Sorry, my fault. Fixed it. 194.187.155.245 (talk) 19:46, 15 April 2021 (UTC)

• The draft looks fine to me. --Guy Macon (talk) 13:19, 15 April 2021 (UTC)
• oppose (conditional) - @194.187.155.245: [… remove bitness paragraph and eliding the remaining paragrams of the introduction …] I object this part. This proposal would be contrary to what MOS:INTRO says. Can you elaborate on highlighted part? Is that one that starts with words "The design implements a 32-bit instruction set, ..."? --AXONOV (talk) ⚑ 16:13, 15 April 2021 (UTC)

This is a bit of off topic --AXONOV (talk) ⚑ 12:59, 16 April 2021 (UTC)

@Alexander Davronov:The part about removing paragraph was added by Uncle G, not me. 194.187.155.245 (talk) 11:07, 16 April 2021 (UTC) @194.187.155.245: Yeah? Well, I've explained myself below then. Just wanted to let you know that I actually support the proposal above as long as it doesn't remove anything. Don't you mind to remove that clause so I can actually support the rest? --AXONOV (talk) ⚑ 11:13, 16 April 2021 (UTC) @Alexander Davronov:The only change I am proposing here is the clarification about ALUs. All other proposals, including removals etc, are not mine. So I can't remove that clause. Thanks. 194.187.155.245 (talk) 11:55, 16 April 2021 (UTC) Oh yeah, I see, my fault. Thanks. --AXONOV (talk) ⚑ 12:59, 16 April 2021 (UTC)

• • This is exactly the wrongheadedness that I'm talking about. We don't make introductions into Micropedias. Introductions introduce and do not have to be a condensed recitation of everything in the rest of the article. This is what leads to the "British-Irish-American-Samoan-French^{[1][2][3][4][5][6][7][8][9][10]}" nonsense and suchlike. Ironically, people have in the last few years have finally cottoned on to this, and if you follow some of the ethnicity and other debates that happen, you'll see that not trying to summarize complex stuff in a sentence out of a robotic adherence to summary style is now regularly given advice for cutting the Gordian knot.

    If something is complicated, introduce the subject and put the complicated stuff in the body. It's enough to just say what Motorola said in the introduction, and go into details in the "Architecture" section, which didn't have any of this at all, in stark contravention of the very style manual that you are waving around.

    And that's compound irony, because also ironically, the idea here is that it goes in a section that, were one a true adherent to summary style, one would object to for itself having no summary. But summary style is best only vaguely followed, you are already only vaguely following it in the sections, and good writing, that introduces and flows, is always better. Put the complex stuff about the architecture into the section with that as its very title, and don't go down the route that leads to "16-bit^{[1][2][3][4][5][6][7][8][9][10]}". This isn't a newspaper; we don't have nut 'graphs.

    Uncle G (talk) 17:30, 15 April 2021 (UTC)

    • @Uncle G: Well.. I think you have to take this into a relevant WP:VPPOL discussion. We have to comply with the WP:LEDE because it overrides any local consensus as per WP:ARBCOM's principles Wikipedia:Arbitration/Index/Principles#Levels of consensus. I'm sure you are aware of this. I also think that current lede is relatively short.--AXONOV (talk) ⚑ 19:35, 15 April 2021 (UTC)
    • @Uncle G: I propose to keep the current lead (merging it with your draft's version) and clarify that we are talking about CPU family so I can fully support this draft. The WP:OVERCITE should be dealt with by {{Refn}}. --AXONOV (talk) ⚑ 12:59, 16 April 2021 (UTC)