In the list of applications of the 6502 architecture there is one big missing entry. Good old phone line modems using Rockwell chipsets (Hayes modem) that went up to 56Kbit/s. The central controller of the Rockwell chipset was an embedded MPU based on 65C02 kernel that were clocked to up to 75MHz (that's the fasted I had seen). The fact is relatively unknown as NDA with Rockwell were extremely tight.
Less impressive, but something which was still fun to me when I had an Amiga: At least some Amiga keyboards used a SOC with a 6502 core.
One of my Amiga's had 4 CPU families: A 6502 core on the keyboard, a Z80 on the SCSI controller, an x86 on a bridge board (the Amiga 2000 had ISA slots, and one of them was in-line with a Zorro slot so you could get a board that let you run x86 software using a window on the Amiga desktop as the output; I don't remember if the bridge board itself was an 8088 or 8086, but I upgraded it with a 286 accelerator card) and of course the 68000 (+ a 68020 expansion)....
The 1541 floppy drive for the C64 used a 6502, almost the same as the C64’s 6510 CPU. Some C64 software co-opted the floppy drive’s 6502 as a coprocessor.
I've seen that one before, but always love seeing this. And particularly love the touch of not using pre-prepared cables but casually unplugging the C64 and cutting apart and splicing the cables with the equipment on...
The 4040 drive for the Commodore business line had TWO 6502 equivalent CPUs. I used to tease a friend who owned one that his floppy drive was smarter than his computer.
> Some C64 software co-opted the floppy drive’s 6502 as a coprocessor.
In that sense, the 8-bit Commodores were a bit like mainframes - one could load a data transform program to run on the floppy drive and run it without bothering the host. I believe it goes a bit further than the Atari family in that.
Now I got curious: I have the impression the 2000 wouldn't be able to see the ISA bus unless a bridgeboard with an x86 was there. Is that so or could the 2000 see the ISA boards regardless of the bridge board?
That is correct, power only. Even with the bridge board installed the Amiga bus could not talk directly to the ISA side, any communication went through dual port ram on the bridgeboard - signals were in no way multiplexed between the two buses directly.
Such a missed opportunity... It'd have allowed Amigas to easily tap the graphics hardware becoming available to ISA machines. Even a plain (and cheap) bridge board with just the bus interfaces would be a huge enabler that could take the Amiga out of its multimedia (and NTSC-timings) niche.
There is an even bigger missing entry: toys. The Chinese company Sunplus/GeneralPlus has had a near monopoly on toy microcontrollers for over two decades at this point and the vast majority of their lower-end offerings are based on trimmed down 6502 derivatives, usually expanded with dedicated hardware for tasks like audio playback. Notably, the original Furby [1] and many Tamagotchi models [2] use such chips.
There are also some very questionable statements in the articlle like saying that 6502 instructions only need one cycle. It's 2 to 7 in reality.
Over the years the comparison between 6502 vs Z80 tend to show that you have to clock the Z80 at about twice the frequency of the 6502 to get the same performance. 8088 having a slight edge over the Z80 it is clear that a 5 MHz will be quite faster than a 1 MHz 6502 (C64 was even under 1MHz as the VIC chip would steal some cycles every 8th display line)
A C benchmark on the 6502 seems suspect to me given that the 6502's architecture tends to make writing stack-based language compilers for it more complicated than other platforms. Some of the difference may be just because the object code generated for the 6502 isn't efficient.
That said, any 16-bit optimizations the 8088's compiler could take advantage of, well, that's fair game.
That's really interesting, and for me a totally unexpected name, having never seen that nomenclature before - would be interesting to see how consensus around that was arrived at - but hey, we gotta call it something!
(But not DoubleQuadWord please ... )
Yes, and that was exactly my point (yes, I wrote that SO answer). The indirect addressing mode that were introduced with 68020 are insane. Most people don't know them, as they didn't exist in 68000/68010/68008 and most compilers did not implement them as they were slower to use than using simpler composed addressings.
It is interesting to see what Motorola cut from the instruction set when they defined the Coldfire subset (for those who don't know, the coldfire family of CPU used the same instruction set as 68000 but radically simplified, the indirect addressing methods, the BCD mode, a lot of RMW instructions, etc. were removed. The first coldfire after 68060 which was limited to 75Mhz, ran at up to 300MHz).
BCD modes only take a few gates to implement; their biggest cost is probably the instruction encoding space they occupy. On a chip as small as the 6502 it makes sense that some users would want to avoid the expensive decimal/binary conversions and do arithmetic in decimal.
Take an Atari ST and you can see what a m68k PC could have been. Its operating system GEMDOS was a derivative of CP/M with comparable features of MS_DOS. The syscall even use the same numbers (trap #1 calls to GEMDOS map 1:1 on int 21H MS-DOS calls).
This said, several hardware PC-emulators on the Atari did exactly the thing that article describes. PC-Speed added a NEC V30 that was soldered on the 68000 and could takeover the bus and the emulation only consisted on simulating the peripherals. It worked like a charm and thanks to the generous memory of the ST could even do some things better than real PC's (for example the 640K limit was in reality a 736K limit). Later versions used 286 and even 386sx cpu's.
GEMDOS was written from scratch (by Digital Research) and doesn't share any code or data structures with CP/M. Many of the BIOS and system calls were the same, but GEMDOS had recursive directories, etc.
Hah, funny, I just posted effectively the same comment elsewhere in this thread.
Though as sibling comment correctly points out (and he'd know more than most, BTW) GEMDOS is more a CP/M-alike than a CP/M itself. There's really no or very little code shared in common with CP/M68k (both are under GPL now so you can go and look). I think the only thing shared between the two is the program loader source, and I might even be wrong about that.
But yes I feel like this machine in this article should boot to a COMMAND.COM running on GEMDOS. Or at least CP/M68k. The source is available to make that happen fairly easily.
People often forget that 'ab' or '1ert' multi-char immediate are allowed in C. They are almost unusable as they are highly un-portable (because of endianess issues between the front-end and the back-end).
This is once in a while kinda useful, aside from the data layout issue for stuff like a FourCC.
Rust has e.g. u32.to_le_bytes() to turn an integer into some (little endian) bytes, but I don't know if there's a trivial way to write the opposite and turn b"1ert" (which is an array of four bytes) into a native integer.
Edited to Add: oh yeah, it has u32.from_le_bytes(b"1ert"). I should have checked.
