True, true, true and true. But some things are a bit off.
I've been programming the 68xxx series through many years. Especially on the Atari ST, I wished I could move data faster than 400k/sec.
But here's what is not mentioned in the above "video":
With an 8-bit CPU, you can't write 16 bits in one go. You have to write two halves, which a 20MHz Atmel microcontroller can't do, unless you use a latch.
And it's wrong to say that 32bits were not needed for calculations. I used that *very* often.
Very interesting! So the 68000 may not have been the only high grade CPU that turned out to actually be low grade.
Could you do a vid of pointing out the strengths and weaknesses of the HuC6280 and how it compares to the 68000? I would be very interested to see the results.
Not use 32-bit arithmetic? Sooo you don't use floppy disks? hard drives? files bigger than 65535 bytes? Even the lowly 180k single-sided five inch diskette is storing 2.8x a 16-bit value worth of data. Or I guess that's just 360 blocks to you..
I'll see your 65816 or 6809 and raise you a 68060. Two integer ops per clock!
If you use LSR.B instead of ROR.W you save 8 cycles for the second AND because LSR fills with zeros from the left .. of course its slower but thats a very constructed example .. If you like something like that .. take your 6502 and reverse 512K 32bit values in memory in thier order and lets see which CPU is cycle faster now ;)
You have to think about that when the 68000 was released it's memory access TIME was 312.5ns at 8MHz, including address decoding and busdriver logic that leaves about 250ns for memory .. there was now memory much faster than that in this time ..
@DL3CE (now = no) .. as everytime, it depends much on the application which CPU is faster. The 68k is clearly weak at "simple" tasks, because of its overhead. If the tasks get more complex, it gains advantage because of its powerful adressing modes and big set of internal registers. If you take a closer look at the architecture you see clearly that it's strongly inspired by the PDP-11. It was constructed to work in multi-user/multi-tasking enviroments..
@DL3CE (even if protected virtual memory wasn't realized until the 68010, on the 68000 there were some design faults which allowed a user application easily to put itself in the supervisor mode and gaining full access to the whole system that way). In such enviroments the features it provided where essential and so the overhead was accepted.
@DL3CE The 65816 and all the small 8bit CPUs (except for the 6809 which at least provided 2 Stackpointers, but no protection of the system stack) didn't implement any of this features like a protected "user mode". Sure, of course you don't need that on gaming consoles .. but gaming consoles aren't everything. If you read publications of the time, the 68k was definitly targeted to multiuser/multitasking systems .. and designed that way.
Back in the day, 6502 topped out at 2mhz, 68000 was available at 12mhz. A 6 times advantage for 68000.
The use of more clock cycles made system buses easier to design. The 68000 could slow down to allow more time for slower EPROM or dynamic ram refresh.
32 bit math IS useful! Just because you only have a hammer does NOT mean everything is a nail!
Finally these are ALL ancient old chips, NOT holy religions! Get a life!
Compared to 16-bit X86 the 68K was more elegant to program but nowadays most 32-bit CPUs including intel in protected mode are straightforward and elegant. You might appreciate the ARM in particular that shares some of the Motorola philosophy.
You show a strong arguement, however the proof is in the pudding. When the 68K was released back in 1979 muti-user multi-tasking systems was based on the 68K running Unix or Unix-liked OSes. Soon after, home computers like the Amiga was released with its awesome abilities (for its time). Compare this to the 6502 systems, C64, Apple IIe and a host of others using the Z80.
You mentioned something like "what if those cpus were also running at 10Mhz"
"32-bit arithmetic and logic are completely useless! You never need to use any numbers that high!" - which planet are you on? I need to use 32-bit arithmetic all the time.
@pepshog "I need to use 32-bit arithmetic all the time."
I think he meant on the kind of systems the 68000 was originally installed in. When the amount of RAM you had was only a handful of kB, what kind of math functions would you be performing on such a system that would need 32-bit computation?
Look those other CPUs had either 8 or 16 bit registers, but I'd still go with the M68K. With an 8 bit register, the largest number you can add and any given time is 256. 32 bit is around 4.4 billion. I usually use numbers like that. In programming, most people use "int" as the standard variable for storing things. This a 32 bit signed number and can be operated upon with one instruction by a 32 bit CPU, 4 for an 8 bit. Also, the Linux kernel supports the M68K.
The 68K is extremely convenient to program, but it could've benefitted from better instruction encoding and code density of course. Considering how near orthogonal it was it probably would've been a huge task to improve this though.
Having 8+8 registers and powerful addressing modes is convenient and if you preload pointers and constants etc. you can get alot of work done in few instructions.
Out of curiosity, what CPUs available in 1979 outperformed the 68K at an equal clock frequency?
Of course in the end, you could always argue by unrolling every f*cking loop on the 6502. So much for the argument how the 68000 wastes memory by having 16bit opcodes... ;)
The 6502 may have a better cycle efficiency, but on the other hand, its severely limited amount of registers requires lots of memory loads and stores, and seperate operations to modify pointers in indirect addressing modes, where 68k has pre-post incrementing/decrementing. If you want to access more than 64K, you need bakswitching. Your rave about not needing 32bit arithmetic and logic is ludicrous. If I can manipulate 8 or 32 pixels per instruction on a bitmap is surely a big difference.
@porcorosso81 i agree, you made an importnt point. Imagine the apple lisa or macintosh on the 6502. let lone the supervisor mode or the interrupt response time
sure the 68000 has its flaws, like on bus error conditions, but all in all it was pretty advanced for its time.
by the way i love the enthusiasm of the guy who made the video...i could talk about that tech stuff all day long, everybody has different arguments and perspectives, makes it exciting
Clearly, the 68k was developed as a CPU being used in workstations, while the 6502 brought computing to the masses. From a coder's point of view, the 68k is a dream and easily my favourite CPU. Yet, if I had the task back then to create a cost effective, yet powerful video game console (like the PC-Engine), I probably would also have preferred the 6502. The most effective use of the fast 6502 cycle performance is probably the Atari VCS game console. Now that's a design for coders!
Quite often people select things that are comfortable and over things that perform better. Example is usb vs firewire, windows vs unix , c vs assembly, c# cs c, .net vs win32 etc etc... people picks stuff they are comfortable with.
Personally I like 68K assembly but these days I program in C (not c++/c# etc).
Reading your post here I can't help thinking you are obsessed by this processor for some odd reason. if you don't mind me asking - why on earth are you so extremely "into" this?!
I'm the only one with enough sense to not be brainwashed by people into thinking the 68000 (aka Adolf Hitler) is King Shit and everything else is tremendously underpowered.
The 65816 has MUCH better cycle efficiency than the 68000 if you REALLY knew how to program the 65816 to it's full potential. The problem is that everybody fails miserably with the 65816, simply because they are brainwashed in college to program every CPU like a 68000, and that the 68000 is tremendously overpowered and everything else is dogpoop.
The 65816 is a fair comparison because it was used in th Super Nintendo, while the 68000 was used in the Sega Genesis.
Everybody thinks the Super Nintendo's cpu is slow as shit, just because it is clocked slower and didn't have those stupid 32-bit instructions the 68000 has.
Nintendo originally was going to go with an 68000 but it would have made the SNES cost too much so they went with a weaker slower CPU. Nintendo knew it's CPU wasn't as good as the Genesis's, but they tried to compensate with better graphics.
And the better graphics co-processor plus what was it 24 bit audio made the SNES win in the long run. I can remember cutting grass and selling as much of my NES stuff as I could and low and behold got one of the 1st 5 SNES's in Houston from toys R Us. They use to be all about the console releases.. It was months before Target or Walmart could get them in the store. And a 6 button controller? Wow! ;)
SNES sound is 16-bit, not 24-bit. It has an 8 channel ADPCM chip. Genesis on the other hand has a 6 channel FM Synthesis chip with 2 PCM channels and 4 PSG channels. And while SNES can do more colors and Mode 7, it's graphical superiority pretty much ends there. Genesis can have more on screen sprites, more layers of parallax scrolling, and can produce much faster games. A good example of this is Thunder Force 3, on Genesis it never slows down, on SNES it slows down every time you shoot.
Usually the 68000 is cycle faster than the 6502, but sometimes the 6502 is cycle faster than the 68000. Here is a code to separate two nibbles from one byte. lda byte and #$0F sta first_nibble lda byte ror ror ror ror and #$0F sta last_nibble 24 cycles for 6502
That's true but it's not "always" like that. Half the time, the 68000's address registers are only used as an alternative to it's slower absolute addressing mode, when repetative addressing is needed. On the flip side, the 6502 is faster at absolute addressing than address register addressing, especially on zero page addressing. So you can do something this: lda $30 sta $40 lda $31 sta $41 lda $32 sta $42 lda $33 sta $43 and finish up in 24 cycles.
Have a look at the TMS9995. It is also 16 bits, and also required multiple cycles to execute an instruction, however, while an instruction was being pushed through the chip, it could fetch and decode the next instruction at the same time. Early instruction pipelining. A *very very* good processor, and has a completely unique architecture, as do all the 9900 range processors.
Yes, 8 bit transfers on 16-bit bus take as long, but flipside is that you can pack them- you can have two variables in one 16-bit word.
4. Instruction set
Instruction set wasn't huge. 68000 has few tens of instructions. But almost all of them can be used in many adressing modes and it is the number of combinations that is huge. It doesn't take much to remember instructions, adressing modes and exceptions to be comfortable with 68000 assembly.
Yes, 6502 can access memory in smaller number of cycles, but that was for 1MHz clock. My measly 68008 was working on 7.5MHz at the time. If you use 1T memory fetch assumption on 6502 and 4T on 68000, that means 1MB/s vs 4MB/s bandwidth peak- ie 4x better result for 68000.
I have written graphic routines for my Sinclair QL and I can tell you that thing was FAST even though it was just 68008 on a 8-bit bus, heavilly burdened with video generation of 32KB picture frame.
True, true, true and true. But some things are a bit off.
I've been programming the 68xxx series through many years. Especially on the Atari ST, I wished I could move data faster than 400k/sec.
But here's what is not mentioned in the above "video":
With an 8-bit CPU, you can't write 16 bits in one go. You have to write two halves, which a 20MHz Atmel microcontroller can't do, unless you use a latch.
And it's wrong to say that 32bits were not needed for calculations. I used that *very* often.
68HC060 2 weeks ago
Very interesting! So the 68000 may not have been the only high grade CPU that turned out to actually be low grade.
Could you do a vid of pointing out the strengths and weaknesses of the HuC6280 and how it compares to the 68000? I would be very interested to see the results.
Shrapnoid72 1 month ago
From what I've seen, it worked like this:
Intel 8080 and 8086 failed. Everything else was pretty good.
TheFlyingJester 3 months ago
Not use 32-bit arithmetic? Sooo you don't use floppy disks? hard drives? files bigger than 65535 bytes? Even the lowly 180k single-sided five inch diskette is storing 2.8x a 16-bit value worth of data. Or I guess that's just 360 blocks to you..
I'll see your 65816 or 6809 and raise you a 68060. Two integer ops per clock!
LordRenegrade 5 months ago
If you use LSR.B instead of ROR.W you save 8 cycles for the second AND because LSR fills with zeros from the left .. of course its slower but thats a very constructed example .. If you like something like that .. take your 6502 and reverse 512K 32bit values in memory in thier order and lets see which CPU is cycle faster now ;)
DL3CE 5 months ago
Comment removed
DL3CE 5 months ago
You have to think about that when the 68000 was released it's memory access TIME was 312.5ns at 8MHz, including address decoding and busdriver logic that leaves about 250ns for memory .. there was now memory much faster than that in this time ..
DL3CE 5 months ago
@DL3CE (now = no) .. as everytime, it depends much on the application which CPU is faster. The 68k is clearly weak at "simple" tasks, because of its overhead. If the tasks get more complex, it gains advantage because of its powerful adressing modes and big set of internal registers. If you take a closer look at the architecture you see clearly that it's strongly inspired by the PDP-11. It was constructed to work in multi-user/multi-tasking enviroments..
DL3CE 5 months ago
@DL3CE (even if protected virtual memory wasn't realized until the 68010, on the 68000 there were some design faults which allowed a user application easily to put itself in the supervisor mode and gaining full access to the whole system that way). In such enviroments the features it provided where essential and so the overhead was accepted.
DL3CE 5 months ago
@DL3CE The 65816 and all the small 8bit CPUs (except for the 6809 which at least provided 2 Stackpointers, but no protection of the system stack) didn't implement any of this features like a protected "user mode". Sure, of course you don't need that on gaming consoles .. but gaming consoles aren't everything. If you read publications of the time, the 68k was definitly targeted to multiuser/multitasking systems .. and designed that way.
DL3CE 5 months ago
Back in the day, 6502 topped out at 2mhz, 68000 was available at 12mhz. A 6 times advantage for 68000.
The use of more clock cycles made system buses easier to design. The 68000 could slow down to allow more time for slower EPROM or dynamic ram refresh.
32 bit math IS useful! Just because you only have a hammer does NOT mean everything is a nail!
Finally these are ALL ancient old chips, NOT holy religions! Get a life!
PeterCCamilleri 6 months ago
Compared to 16-bit X86 the 68K was more elegant to program but nowadays most 32-bit CPUs including intel in protected mode are straightforward and elegant. You might appreciate the ARM in particular that shares some of the Motorola philosophy.
isreasontaboo 7 months ago
You show a strong arguement, however the proof is in the pudding. When the 68K was released back in 1979 muti-user multi-tasking systems was based on the 68K running Unix or Unix-liked OSes. Soon after, home computers like the Amiga was released with its awesome abilities (for its time). Compare this to the 6502 systems, C64, Apple IIe and a host of others using the Z80.
You mentioned something like "what if those cpus were also running at 10Mhz"
Well, they weren't. They would've if they could.
expert25 11 months ago
Take the 68000 and build a better board and GUI / operating system than the original Macintosh 68000.
gbowne1 1 year ago
This has been flagged as spam show
Don't trust a dumb-head who cannot tell the difference, or use appropriately, between the words "its" and "it's".
MrLegarcia 1 year ago
This has been flagged as spam show
Don't trust a dumb-head who cannot tell the difference, or use appropriately, "its" and "it's"
MrLegarcia 1 year ago
Don't trust a dumbass who cannot tell the difference, or use appropriately, "its" and "it's"
MrLegarcia 1 year ago
Don't trust a dumbass who cannot tell the difference, or use appropriately, "its" and "it's"
MrLegarcia 1 year ago
"32-bit arithmetic and logic are completely useless! You never need to use any numbers that high!" - which planet are you on? I need to use 32-bit arithmetic all the time.
pepshog 1 year ago 2
This has been flagged as spam show
@pepshog "I need to use 32-bit arithmetic all the time."
I think he meant on the kind of systems the 68000 was originally installed in. When the amount of RAM you had was only a handful of kB, what kind of math functions would you be performing on such a system that would need 32-bit computation?
cadmus98 1 month ago
68000 vs 8086 would be an interesting comparison
after how long, AMD64 finally added extension to 16 logical registers
68000 was a forward looking architecture.
shame it died while the 8086 was pushed onward into the present day.
it would be nice to imagine how a modern day 680x0 with SIMD, OOOE, multicore etc would have turned out.
walter0bz 1 year ago
68008 was pathologically bad sure.
but the registers were extremely usefull r.e. minimizing instruction count to get things done.
ARM blows 68000 away though, with half the transistor count (at expense of needing a 32bit bus)
walter0bz 1 year ago
Look those other CPUs had either 8 or 16 bit registers, but I'd still go with the M68K. With an 8 bit register, the largest number you can add and any given time is 256. 32 bit is around 4.4 billion. I usually use numbers like that. In programming, most people use "int" as the standard variable for storing things. This a 32 bit signed number and can be operated upon with one instruction by a 32 bit CPU, 4 for an 8 bit. Also, the Linux kernel supports the M68K.
linuxrobotdude 2 years ago
The 68K is extremely convenient to program, but it could've benefitted from better instruction encoding and code density of course. Considering how near orthogonal it was it probably would've been a huge task to improve this though.
Having 8+8 registers and powerful addressing modes is convenient and if you preload pointers and constants etc. you can get alot of work done in few instructions.
Out of curiosity, what CPUs available in 1979 outperformed the 68K at an equal clock frequency?
RJLeffmann 2 years ago
Of course in the end, you could always argue by unrolling every f*cking loop on the 6502. So much for the argument how the 68000 wastes memory by having 16bit opcodes... ;)
porcorosso81 2 years ago
The 6502 may have a better cycle efficiency, but on the other hand, its severely limited amount of registers requires lots of memory loads and stores, and seperate operations to modify pointers in indirect addressing modes, where 68k has pre-post incrementing/decrementing. If you want to access more than 64K, you need bakswitching. Your rave about not needing 32bit arithmetic and logic is ludicrous. If I can manipulate 8 or 32 pixels per instruction on a bitmap is surely a big difference.
porcorosso81 2 years ago 13
@porcorosso81 i agree, you made an importnt point. Imagine the apple lisa or macintosh on the 6502. let lone the supervisor mode or the interrupt response time
sure the 68000 has its flaws, like on bus error conditions, but all in all it was pretty advanced for its time.
by the way i love the enthusiasm of the guy who made the video...i could talk about that tech stuff all day long, everybody has different arguments and perspectives, makes it exciting
Serpico261 11 months ago
@Serpico261
Clearly, the 68k was developed as a CPU being used in workstations, while the 6502 brought computing to the masses. From a coder's point of view, the 68k is a dream and easily my favourite CPU. Yet, if I had the task back then to create a cost effective, yet powerful video game console (like the PC-Engine), I probably would also have preferred the 6502. The most effective use of the fast 6502 cycle performance is probably the Atari VCS game console. Now that's a design for coders!
porcorosso81 11 months ago
Quite often people select things that are comfortable and over things that perform better. Example is usb vs firewire, windows vs unix , c vs assembly, c# cs c, .net vs win32 etc etc... people picks stuff they are comfortable with.
Personally I like 68K assembly but these days I program in C (not c++/c# etc).
Reading your post here I can't help thinking you are obsessed by this processor for some odd reason. if you don't mind me asking - why on earth are you so extremely "into" this?!
Slurfs 2 years ago
I'm the only one with enough sense to not be brainwashed by people into thinking the 68000 (aka Adolf Hitler) is King Shit and everything else is tremendously underpowered.
clownhorse 2 years ago
The 65816 has MUCH better cycle efficiency than the 68000 if you REALLY knew how to program the 65816 to it's full potential. The problem is that everybody fails miserably with the 65816, simply because they are brainwashed in college to program every CPU like a 68000, and that the 68000 is tremendously overpowered and everything else is dogpoop.
clownhorse 2 years ago
The 65816 is a fair comparison because it was used in th Super Nintendo, while the 68000 was used in the Sega Genesis.
Everybody thinks the Super Nintendo's cpu is slow as shit, just because it is clocked slower and didn't have those stupid 32-bit instructions the 68000 has.
clownhorse 2 years ago
Nintendo originally was going to go with an 68000 but it would have made the SNES cost too much so they went with a weaker slower CPU. Nintendo knew it's CPU wasn't as good as the Genesis's, but they tried to compensate with better graphics.
SegaFanatic5188 2 years ago
Comment removed
txfirehawk 2 years ago
This has been flagged as spam show
And the better graphics co-processor plus what was it 24 bit audio made the SNES win in the long run. I can remember cutting grass and selling as much of my NES stuff as I could and low and behold got one of the 1st 5 SNES's in Houston from toys R Us. They use to be all about the console releases.. It was months before Target or Walmart could get them in the store. And a 6 button controller? Wow! ;)
txfirehawk 2 years ago
SNES sound is 16-bit, not 24-bit. It has an 8 channel ADPCM chip. Genesis on the other hand has a 6 channel FM Synthesis chip with 2 PCM channels and 4 PSG channels. And while SNES can do more colors and Mode 7, it's graphical superiority pretty much ends there. Genesis can have more on screen sprites, more layers of parallax scrolling, and can produce much faster games. A good example of this is Thunder Force 3, on Genesis it never slows down, on SNES it slows down every time you shoot.
SegaFanatic5188 2 years ago
clownhorse 2 years ago
clownhorse 2 years ago
Then you have the 65816, which is the 16-bit upgrade to the 6502 and that could do the same with.
lda $30
sta $40
lda $32
sta $42
16 cycles, just as long as it was already in 16-bit mode.
clownhorse 2 years ago
Have a look at the TMS9995. It is also 16 bits, and also required multiple cycles to execute an instruction, however, while an instruction was being pushed through the chip, it could fetch and decode the next instruction at the same time. Early instruction pipelining. A *very very* good processor, and has a completely unique architecture, as do all the 9900 range processors.
NotMarkKnopfler 2 years ago
I'm not saying the 68000 isn't fast, I'm just saying a 10 Mhz 6502, 65816, 6809, and 6309, would be capable of doing better than a 10 Mhz 68000.
1. I was comparing equally clocked chips. Yeah, sure a 7.5 Mhz 68000 could beat a 1 Mhz 6502. What about a 7.5 Mhz 6502?
2. I don't know. I need to test a multiplication subroutine to confirm that.
3. Yes, but I already stated that a 16-bit bus accessing memory every 4 cycles, is like an 8-bit bus accessing memory every 2 cycles.
4. Yes.
clownhorse 2 years ago
Your right with the 32-bit multiplication. The 68000 beat the 6309 (which is superior to the 6502, 65816 and 6809) at this.
The 6309 still beats the 68000 when it comes to 16-bit multiplication though.
clownhorse 2 years ago
Wait, I just researched it!
68000 does NOT have 32-bit multiplication?
clownhorse 2 years ago
3. Bus granularity
Yes, 8 bit transfers on 16-bit bus take as long, but flipside is that you can pack them- you can have two variables in one 16-bit word.
4. Instruction set
Instruction set wasn't huge. 68000 has few tens of instructions. But almost all of them can be used in many adressing modes and it is the number of combinations that is huge. It doesn't take much to remember instructions, adressing modes and exceptions to be comfortable with 68000 assembly.
Brane212 2 years ago
2. Opcode size
Yes, instruction opcodes are wider on 68000, so they eat more of the bus bandwidth. But they are immensely more powerful.
Try for example 32-bit multiplication or division.
On 68000 its one instruction with few tens cycles execution time ( it depends on actual operands).
Yes, you could do it manually, but it would take you quite a few more cycles and memory acesses.
MC ha used a few extra gates to make it easier, since they couldn't give you a barrel shifter within budget.
Brane212 2 years ago
1. Memory bandwidth
Yes, 6502 can access memory in smaller number of cycles, but that was for 1MHz clock. My measly 68008 was working on 7.5MHz at the time. If you use 1T memory fetch assumption on 6502 and 4T on 68000, that means 1MB/s vs 4MB/s bandwidth peak- ie 4x better result for 68000.
Brane212 2 years ago
Have you ever tried to actually use the chip ?
I have written graphic routines for my Sinclair QL and I can tell you that thing was FAST even though it was just 68008 on a 8-bit bus, heavilly burdened with video generation of 32KB picture frame.
Brane212 2 years ago