The KimKlone Microcomputer
laughtonelectronics.com
laughtonelectronics.com
The KIM-1 had a 6502, the Elf had an 1802, and the ZX81 had a Z80 processor, all 8 bit processors which were approachable for beginners.
I really had a blast with that thing. Programing the interesting ISA was fun. It almost felt like it had 16 words of RAM and several K of registers, since all memory I/O had to go through the D register. The best part was that you could use any of the 16 GP regs as the PC, so you could do primitive task switching.
The simple circuit made it just as fun to expand its hardware capability (bump to 2K of RAM, eventually 8K CMOS battery backed RAM, KC tape interface, Hex keypad, a 20ma. loop interface to a barely working Model 33, and finally I scored an 1861 to add video out)
I later got a Timex/Sinclair 1000 as a gift. Not nearly as fun from a hardware perspective (though I eventually upgraded the the external 8K RAM cartridge to 16k by piggybacking additional chips, connecting the chip select pins to the the board with flying leads). However, the Z80 was another fun CPU to program for. Much more advanced memory addressing and the shadow register bank made for some fun hacks.
Never did own anything 6502 based, which kind of bums me out since the first computer I ever programmed was 6502 based (CBM PET 2001), but I was a ways off from figuring out assembly at the time.
I wanted a C64 or a VIC, but couldn't afford one. Oh well -- once I saved up enough to buy a used CoCo I was spoiled for anything else for years to come -- the 6809 was the peak of 8-bit CPU design, IMHO.
I'm reminded of the NEC V20 which could replace the 8088 in the original IBM PC. You could pop out the 8088, pop in the V20 and get lots of interesting new opcodes.
Someone, somewhere, may well have done such a thing on some CISC machine.
CISC as a general approach lost out to RISC historically for specific reasons, but it's fun to think about.
I'm afraid my DEC assembly language study ended at the PDP-11, but it is edifying to know the VAX had such an instruction.
In some domains like numerical programming, ML, and graphics using SDF having a Calc 102 operation like a gradient op might be considered useful enough to include in a RISC instruction set, and the RISC entry on Wikipedia says this about the RISC-V architecture:
> The ISA is designed to be extensible from a barebones core sufficient for a small embedded processor to supercomputer and cloud computing use with standard and chip designer defined extensions and coprocessors.
Maybe a derivative op belongs in a math coprocessor?
You're better off; the PDP-11 was a beautiful ISA but the VAX was not, it was just a kitchen-sink approach, and is part of what motivated interest in the RISC approach.
If the VAX had simply been a clean 32 bit extension of the PDP-11, a lot of related history probably would have turned out interestingly different -- not that it would have stopped the RISC revolution, but still.
Specifically, the VAX CISC instructions overall, and the polynomial instruction in particular, were significantly slower than just using the regular VAX instructions to do the equivalent -- which was widely agreed to be unfortunate if not outright pathetic.
Nor was that particularly rare with CISC instructions. It's just a lot easier to make RISC instructions go fast, whether microcoded or not. It's typically not impossible to make CISC instructions optimally fast, but it's an extra cost in implementation and testing for the manufacturer, so it often got/gets comparatively neglected.
The Intel processor looping instructions re-fetched the instruction on every loop, so they didn't (and still don't, as far as I know) even save on the instruction fetch bandwidth.
Typical comment on that that I just found: "You should normally never use the loop instruction unless optimizing for code-size at the expense of speed, because it's slow. Compilers don't use it. (So CPU vendors don't bother to make it fast; catch 22.)" [1]
There was also a mindset issue (with both users and manufacturers) where it was viewed as a boost to assembly language programming to have fancy opcodes, although in retrospect that particular angle could have been just as easily addressed by the manufacturer with fancy assembly macros. I'm not sure why that was usually left to users.
> Maybe a derivative op belongs in a math coprocessor?
Sure, why not. Although theoretically it still needs to justify the opcode real estate and coprocessor silicon real estate and/or microcode space that it uses.
I personally like the concept of CISC, and I like things like Lisp machines, and I like GPUs, and so on. But they don't automatically justify themselves logically; it depends on the tradeoffs in each case.
[1] https://stackoverflow.com/questions/46881279/how-exactly-doe...
https://github.com/FluxML/Zygote.jl
the efficiency of autodiff might be similar to that of an opcode anyway.
So, how did DEC do on the Alpha processor? I always heard good things about it--IIRC (I didn't) it was ~~based~~ to replace the VAX, but 64 bit. I learned PDP-11 assembler at RPI, during their college program for high school students in about 1984. We hand assembled code and really got to know the architecture.
I guess everybody is gone from this post too, but I wonder if there is a fixed point corollary to Godwin's law--if you post enough off topic comments, you reach the original topic again. :)
Nobody noticed, because VGA was mostly found in '286 & '386 level machines, and TBH Windows 3.0 was not really aimed at XT-class PCs (8088 & 8086).
But the NEC V20 & V30 implemented the additional Real Mode instructions from the 80286 — so if you replaced your Intel CPU with an NEC equivalent, suddenly you could use VGA on Windows 3.0.