Back in the day (late 1980's) there was ample motivation as I had no knowledge of or access to the 65816. Programmable logic has changed the landscape since then -- and btw I have whimsically contemplated a modern re-issue of the KK. (I've also contemplated some KK-ish hacks that would yield an improved 65816!) But I agree the scope for practical application has shrunken. In the first place you'd need to be committed to the 65xx family, because alternative, modern processors offer compelling advantages not featured by 65xx.
That said, KK has features not present on the 65816, and in certain applications these could be pivotal. Obvious examples include the NEXT instruction and the new addressing mode. Less obviously, KK preserves the 65C02's bit-manipulation instructions, which can be a boon in I/O-intensive code. The '816 sacrificed these opcodes to make room for alternative, also-worthy objectives.
Thanks for posting, ingve (and 0x12). 0x12's HN thread [1] about my project included the following TLDR:
"Guy expands 6502 to 16M address space by intercepting the databus and re-mapping unused opcodes and clever use of the spurious signals generated by the cpu when executing other undefined opcodes, adds a few registers to make the whole thing transparent from an assembler programmers point of view. In other words, there is no difference to the programmer between native and newly minted instructions.
On top of that he boosts the speed of his forth interpreter by concentrating on a frequently used construct called 'NEXT' in a way that should make anybody that has tried to optimize the inner loop of some VM or language proud. After all, what better way to optimize in such a situation than to be able to mold the instruction set to your desire.
He then uses this home-brew Frankenstein contraption as his benchtop computer for multiple years to do real work (instead of just shooting some pretty pictures and calling it a day)."
Regardless of its quirks, I loved the 6502 when I was writing my revision of the onboard ROMs. Easy to get the scope of the instruction set, etc. Having this set of expanded capability would have been game changing... maybe a riff off GEOS, or writing an Echelon clone with Minecraft size worldmap...
The mind boggles, and wonders if I just started my retirement project planning.
In the 1980's I had a client that manufactured cheques, and the typesetting was done by four or five "Wescode 1420M" systems. These technological marvels used an 8" floppy drive to input order data -- the customer name, account number and so on. The output was rendered onto a single web of fan-fold material which successively threaded its way through two Diablo daisy-wheel printers. The key point is it was a pipeline, with multiple orders in flight simultaneously.
Floppy swapping was a normal part of the work flow, and there was an obscure vulnerability in this regard. In some circumstances if the disk was changed at an incorrect time it was possible for data to leak between orders. (For example, Ted's cheques might bear Alice's account number! To call this intolerable is putting it mildly.) Disk-swap prompts were displayed on a terminal for the operator's benefit, but the environment was hectic and humans are fallible.
Did I alter the software so it'd preview the data and verify that every disk change occured as prompted? No. The 1420M computer featured three 8080 microprocessors mucking around in shared memory, and the code was a spaghetti monolith written in assembly language. I've reverse-engineered lots of stuff before -- there are a coupla stories here [1][2] -- but some challenges you need to walk away from. The time frame would've been open-ended, and that wasn't acceptable.
What I did was supply the client with a gory hack. No apologies -- it was the best way to serve their needs! On each 1240M I installed an 8741 microcontroller that monitored program status by eavesdropping on the RS232 line that carried text strings to the terminal. If those messages failed to agree with observed disk-change activity (relayed by the Door_Open signal on the floppy drive) the microcontroller would yank the 1240M Reset line low. This would crash the pipeline and force the operator to reboot -- a considerable nuisance... and yet, enormously preferable to allowing the error to go undetected!
"Guy expands 6502 to 16M address space by intercepting the databus and re-mapping unused opcodes and clever use of the spurious signals generated by the cpu when executing other undefined opcodes, adds a few registers to make the whole thing transparent from an assembler programmers point of view. In other words, there is no difference to the programmer between native and newly minted instructions.
On top of that he boosts the speed of his forth interpreter by concentrating on a frequently used construct called 'NEXT' in a way that should make anybody that has tried to optimize the inner loop of some VM or language proud. After all, what better way to optimize in such a situation than to be able to mold the instruction set to your desire.
He then uses this home-brew Frankenstein contraption as his benchtop computer for multiple years to do real work (instead of just shooting some pretty pictures and calling it a day)."
Thanks for your interest in my projects, 6502nerdface. You've linked to the "chatty" KK article but there's kinduva TLDR version, which folks may prefer, here [1]. In particular the block diagram covers a lot of ground.
Regarding the One-bit computer: although that writeup is a few years old, it so happens that I tweaked a rewrote a few bits just few days ago! I'm pleased by how much attention it has attracted since it was first published. (At the same time it's startling that the mere mention of MC14500 left some apparently inattentive readers with a false impression. What I built is NOT a '4500 machine!)
This. Unless you consider Charles Darwin, Oliver Heaviside, James Watt and Thomas Edison cranks. And that's just the tip of the iceberg, as you can see here:
https://en.wikipedia.org/wiki/List_of_autodidacts
>Eight 74172s provide eight 16-bit registers in a three-port register file. This file may simultaneously write one register ("A"), read a second ("B"), and read or write a third ("C"). In a single clock cycle, the following occurs:
>a) one register is output to the Address bus and the ALU's A input;
>b1) another register may be output to the Data bus and the ALU's B input; or
>b2) data from memory may be input to another register;
>c) an ALU function is applied to A (and perhaps B) and the result is stored in the first (address) register.
I consider the 74172 a FOUR port register file, since it can simultaneously perform two reads and two writes. Exploiting all four data paths can really turbocharge a design, even a so-called "Pathetic" Instruction Set (PISC) machine like this.
Dunno if 74172's are generally available nowadays but I have several dozen purchased in the 20th century for a yet-unbuilt design of my own.
-- Jeff
https://news.ycombinator.com/item?id=7616831
https://news.ycombinator.com/item?id=12469790