It's an interesting take on retro; gives the user the feel of a retro computer without all the gnarly period-accurate hardware. Also amusing that the STM32 supporting CPU has far more power than the main Z80 CPU.
Nothing will replicate the same feeling I had when I wrote my first machine code program by poking into RAM, and discovered the world of million+ operations per second, rather than thousands from the land of BASIC. It was like a glimpse of blinding light through the narrowest of cracks.
Those were the days, I programmed in assembly language for at least two years without an assembler.
As you say poking bytes into RAM, via the lookup table in the computer manual. Writing them down on paper, and trying to leave space in the code so I didn't have to recalculate all the relative JMP-offsets if I tweaked my program over a few days.
> Also amusing that the STM32 supporting CPU has far more power than the main Z80 CPU.
I believe some Commodore drive already had two processors identical to the main processor of the computer -- effectively giving the drive more processing power than the actual computer :)
One of the fun things on my Z80 CP/M machine was a 20MB Seagate SCSI hard drive with a 680000 controlling the drive electronics. Which is why I've never really understood people who focus on one chip to "define" a system, it really is about all the parts playing in harmony.
That's funny - My 68000 based Amiga 2000 had a SCSI card in it with a Z80 on it.
That machine was a real monster - I had a bridge-board in it: the A2000 had both ISA and Zorro-II (Amiga proprietary) buses, with one ISA and one Zorro-II slot in line so that you could buy a bridge-board that held an 8086 etc. on it to basically give you a "PC in a window" on your Amiga.
I'd then bolted a 286 accelerator board onto it, and a 68020 accelerator board onto the Amiga-side (I think both were of the type that slotted into the CPU socket andwhere you re-seated the CPU in the accelerator in case you wanted to switch to the slower CPU for compatibility reasons)
On top of that the Amiga 2000 and Amiga 500's used an 6502-compatible SOC with onboard RAM and PROM as their keyboard controllers.
So that one machine had a 68000 (though not usually running), 68020, 8086 (not usually running), 80286, Z80 and a 6502-compatible. I found it quite pleasing to have one machine with representatives of four of the most common CPU families at the time in it.
> Which is why I've never really understood people who focus on one chip to "define" a system, it really is about all the parts playing in harmony.
It was about identity in a sense when so much was done in assembler on the main CPU, and most people are never aware of those auxiliary CPU's.
Well, unless you can run programs on your hard disk controller, that's not the chip you use to define how fast the system is.
Yes the speed of your computer is more than just the CPU, but the CPU, the RAM, and GPU are far more influential that what speed your disk's controller runs at.
The 8250 (the equivalent disk drive for the PET) had two 6502s inside!
In today's language, one was the application processor running DOS and the other was a DSP that did the low level hardware monkeying; they were connected up to a shared data bus. Because the 6502 only does bus accesses on one phase of the clock, by inverting the clock for one processor, it was safe to connect them both up to the bus simultaneously with no loss of speed...
The really fun thing about these was that you could actually download code to them and run it, so if you did have code that was small enough and CPU intensive enough and required little enough IO, you could in fact use them as an accelerator of sorts (but limited by a slow serial port and 2KB(?) I think of RAM on the drive)
I know of various code that downloaded code to it, but usually loaders or just to do things like blink the leds - I've never seen code that actually used the extra CPU for anything serious. I'm really curious if any exists.
It worked by transferring the "live" GCR-encoded data from the 1541's disk head to the C64 and simultaneously doing a fast checksum. Part of the checksumming was done on the 1541, part was done on the C64. There simply weren't enough cycles left on either side! Most of the transfer happened asynchronously by adjusting for the slightly different CPU frequencies and with only a minimum number of handshakes. This meant meticulous cycle counting and use of some odd tricks.
A GPU isn't really comparable to the modern CPU sitting beside it, since it lacks many of the CPUs features, eg. virtual addressing, while in the other instances mentioned the processors were pretty much the same, feature-wise.
GPUs do, like most peripherals, contain additional CPUs that control them -- in the case of GPUs these are proprietary architectures specifically designed just for scheduling and sequencing tasks on the GPU and are said to be quite potent, for a device control processor.
Similarly hard drives had multi-core MIPS and ARM processors for quite a while (ditto for SSDs, in both cases they are ASICs, the actual data juggling isn't done by the CPU cores), and they even have quite a bit of RAM -- the cache -- that they'd normally share with the DMA engine, plus some of their own...
The control processors in most other peripherals are usually much weaker, though. They're pretty much just microcontrollers.
Some models of LaserWriter also had an undocumented PostScript command which would print a La Costeña order form for you to fax in. I always appreciate super-obscure Easter Eggs like that.
Sorry I'm late seeing your comment, but I'll tell you what I know for posterity. I heard the story third-hand: a prior manager of mine, Mark "The Red" Harlan (of Clarus the dogcow fame), used to be a DTS manager at Apple back in the late 80's/early 90's. He also hosted a MC'd at WWDC each year called "Stump the Experts," where the audience got to challenge a panel of Apple engineers with the most obscure questions possible. One audience member asked about this PostScript command, and one of the engineers admitted to the fax-in burrito order form. Sorry I don't remember the engineer's name or which WWDC year, but I'll ping Mark.
Kurzweil Music Systems produced the 150 additive synthesizer around the same time that also used a 12 MHz 68k. Do you know if this faster variant was encumbered in some way that made it less suitable for use in a "general purpose" computer, or was it simply a cost consideration?
I'm not sure how you think it would be encumbered, but from the Wikipedia page, my guess is it was mostly cost. The faster variants (like 12 Mhz) were only available later, and I would guess that was due to improved production processes and binning that enabled them.
https://dekunukem.wordpress.com/
It's an interesting take on retro; gives the user the feel of a retro computer without all the gnarly period-accurate hardware. Also amusing that the STM32 supporting CPU has far more power than the main Z80 CPU.