Fair enough I made a mistake about the 68040 being their last CPU on the 68k line thanks for correctly me but according to wikipedia the AIM alliance which lead to powerPC was formed in 1991 so idk if Motorola were part of it from the beginning or if they just planned to offer powerPC alongside 68k then killed off 68k after their bigger clients like Atari & commodore died a few years later & Apple obviously being on board with powerPC anyway they maybe saw no reason to keep it around.

@6502Assembly4NESgames Motorola never killed of the 68k series they (Freescale) are still doing 68k. The 060 was developed after PowerPC development started. The only killed off line was the 88k, Motorola's own RISC CPU. Further continuation was a matter of rather hughe investment vs. a shrinking marked for non-x86 high performance CPUs. Having two incompatible lines, PowerPC and 68k, for the same market doesn't make any sense. One had to go and going along with IBM was the right way.

"performance wise a 4.77 MHz 8088 doesn't deliver notable more processing punch than a 1 MHz 6502" - well, it was certainly much faster than my TI-99/4a! (TMS9900 @ 3 MHz)

@Raffzahn "They" are now (and have been for 5 years) NXP. nxp.com/products/processors-and-microcontrollers/…

@MichaelGraf yeah, company names/ownership change a lot nowadays...

A 1MHz 6502 may be able to perform many kinds of 8-bit computations slightly faster than a 4.77Mhz 8088, but the 8088 is only somewhat slower when doing 16-bit computations. The 8088 segmentation design was mostly great, and could have been improved if CS were handled separately from the other segment registers and it had had four registers plus CS, or if there were a flag to make SS be the default segment (so that applications which could fit the stack in the same segment as their primary data could use DS as an extra "spare" segment register).

@supercat the point isn't speed 8 or 16 bit operations but memory bandwidth - and an 8088 needs 4 clock cycles per byte accessed vs. one per byte for the 6502, putting both in the same region. And more can't be stated in high level comparsion.

@Raffzahn: Performing 16-bit arithmetic on the 6502 generally requires about twice as many instructions as performing 8-bit arithmetic, but on the 8088, both 8-bit and 16-bit operations typically require about the same number of instructions. Since instruction fetches on the 8088 generally outnumber data accesses, this means that 16-bit operations on the 8088 are only slightly slower than 8-bit ones. Since many programs do a lot of 16-bit (or longer) arithmetic, this gives the 8088 a performance advantage when running such programs.

@supercat If you're going again into speculations,you should at least use consistent logic. As you said, 8088 code uses up most of the bandwidth than on a 6502. So even with 16 bit operations it can not become considerable faster than a 6502. Fact is, it's even slower when it comes to number crunching. A 1 MHz 6502 ends up at 0.43 Dhrystone MIPS, while a 4.77 MHz 8088 delivers with 0.36 about 20% less. In real world examples it's often not as bad, especially when using the 8088's streaming instructions, but in the end, they are about the same at any real world task.

@Raffzahn: If one wishes to compute the 16-bit sum of 256 numbers, the best imaginable code on the 6502 in an unrolled loop would be lda lowTotal / adc lowBytes,x / sta lowTotal / tya / adc highBytes,x / tay. That's being very optimistic, and is 18 cycles per word not counting loop overhead. On the 8088, use a number of add ax,[byte+SI] instructions and then add si,dx and loop. I think the ADD instructions would be 16 cycles each, ADD SI,DX 8 cycles, and LOOP about 24. So for 8x unrolling, 128+8+24=160 cycles per 8 bytes, or 20 cycles/word.

@Raffzahn: Correction: I think the ADD would be 24 cycles instead of 16 because of the displacement, for a total cost of 28 cycles/word. Even so, the 8088 would still come out well ahead of the 6502 despite the relatively favorable assumptions I was making for the 6502 [e.g. the ability to use abs,x instead of (zp),y addressing, and ignoring loop overhead or the need to clear carry]. The time required for the 8088 to perform the ADD AX,[byte+SI] is between the time the 6502 would take to do one ADC abs,X and the time it would take to do two of them...

...which falls in line with the fact that reasonably-register-heavy 16-bit operations are much faster on the 8088, while some kinds of 8-bit operations are often faster on the 6502. On the other hand, both processors can do much better when given well-optimized code than given typical compiler-generated code.

@Raffzahn, that's nothing new. Between 1965 and 1975, for instance, you could have played a game of "Who's Frederico Faggin inventing groundbreaking stuff for this year :)

@supercat it's simply useless to look at single instructions or operations (Beside the add would be 22/26 clocks + plus fetch). Its all about thruput and here both are limited by memory, the 8088 more than the 6502. If you don't accept basic logic, then try world application, and you'll see it yourself. Everything else is useless talk about angles on a pinhead.

@Raffzahn: A 4.77Mhz 8088 in an IBM PC will have the same potential memory bandwidth as a the 1.19Mhz 6502 found in the Atari 2600, i.e. 1/3 of NTSC chroma frequency. The 8088 won't manage to keep memory busy on every cycle, but it will often require fewer memory accesses to perform many tasks. I owned a 4.77Mhz PC back in the day, as well as a 1.02MHz Commodore 64, and the PC was significantly faster for most common tasks. Not by nearly a factor of 4, but code written to make maximal use of the 8088's registers would generally outperform 6502 code by a substantial margin, and bulk...

...memory moves using REP MOVSW were more than three times as fast, taking 12.5 CPU cycles/byte (equivalent to just over 3 cycles on the 6502), while "LDA abs,x / STA abs,x" would take nine 6502 cycles, not counting loop overhead to copy a byte.

@snips-n-snails for one, the basic 9900 is quite on par with other CPU of the time, again due using a similar memory timing but 16 bit access. This is a bit slowed down due the 99/4A's architecture, but not as much as people often claim. Even worst case scenario (code and data in 8 bit RAM) still delivers about 50% speed, so even a worse case 16 bit MOV is done in 30 cycles or 10 µs, not much different from a 1 MHz 6502 needing anywhere be 8 to 12 to do the same. The 99/4 is an awesome (console) design with a few bad management decisions.

@BruceAbbott In reality TI99/4 structure performs way better than it sounds. GROM actually speeds up execution compared to regular, and video (data) RAM access has virtually zero delay for consecutive access or average <2µS for random. Of course, it's not a middle of the road vanilla structure, so it does need TLC, but then it can easy outperform other machines of its time.

@Raffzahn: I wonder how much better the TI could have performed if it had been designed from the start to use a pair of 512x8 SRAMs instead of 128x8? Can the video chip really manage fast access? I thought that reads or writes could only occur during horizontal or vertical blank?

@supercat It would make a difference, but not that much. There is an 8 KiB window reserved for Scratchpad and I/O with 1 KiB for RAM and much waste for all other. And while 1 KiB of RAM would offer much in terms of having critical routines in scratchpad, the most important relief comes from having the register window there. This greatly reduces the 8 bit penalty. And yes, the 9918 can provide access free of waiting during retrace, but also between lines and within. here wait up to 8 µs occurs. But due read ahead, this doe not affect continuous access like loading a sprite or writing text.