Dr_Jefyll
Juggling? Ouch! These comments reveal an apparent unawareness of the 65816's long address modes, which offer four different ways of computing a full, 24-bit address. None of the long address modes involves the "data bank pointer" (Data Bank Register), which can more appropriately and less painfully be used for legacy code (6502) and other 64K-oriented contexts.
Two of the 65816's long address modes use three-byte indirect pointers in zero-page/Direct-Page, where any reasonable number of long pointers can be simultaneously available (in contrast to only DS ES CS SS). And segment override prefixes never come into the picture.
Finally, "hitting bank boundaries" is not the excruciating issue it's made out to be, because the indexed long modes transparently span said boundaries. And note that the 16-bit index is added to a fully specified 24-bit base (not a 16-bit base inflated to 20 by shifting zeros into the LSBs).
Otherwise an interesting article -- I enjoyed it.
Intriguingly, the 65C02 also shows this behaviour. Several of the C02's undefined opcodes cause an address to be computed and a fetch to occur (whose data is then discarded). The spurious address computation wasn't intended as a feature, but an opportunity nevertheless exists. My 1988 KK Computer uses it as part of a co-processor scheme in which microcoded external logic gives the 65C02 six new registers and 44 new instructions, including ITC NEXT (as used by Forth).
Repeatedly posted to HN. :-) If anyone's interested and hasn't yet seen it... https://news.ycombinator.com/item?id=26432154
The original 2019 post by Garbage [1] attracted the most comments. But in a reply to one of the subsequent posts [2] I talk a bit about actually coding for the thing. :)
I wrote about the Diablos and their multi-axis realtime motion control here [1]. The good stuff about the hacking starts just over halfway down the page, "the Diablo proprietary processor."
HN has honored me in past by recognizing other items on the site, such as "One-Bit Computing at 60 Hertz" [2] and "the KK Computer - a radical 6502 redesign" [3].
[1]https://laughtonelectronics.com/oldsite/comm_mfg/commercial_... [2]https://laughtonelectronics.com/Arcana/One-bit%20computer/On... [3]https://laughtonelectronics.com/Arcana/KimKlone/Kimklone_sho...
Love the articles you've been posting, Ken! And yes the MC14500 requires multiple external chips to make it usable. In fact, HNers may recall the one-bit machine whose chip-count I optimized by eliminating the MC14500B itself!
One-Bit Computing at 60 Hertz https://news.ycombinator.com/item?id=20565779
The computer only has one instruction, so I didn't bother to give the instruction a name. But it performs an input, an output and a 2-way branch. I hope this is weird enough to deserve mention in this thread. :)
The project was mentioned at least twice previously on HN:
"This is not a Motorola MC14500 computer, but it was the MC14500 that introduced me to the idea of one-bit computing. Exploring ways to reduce the chip count, a series of pencil & paper designs revealed the MC14500 itself could be omitted!"
-- Jeff
[1]https://laughtonelectronics.com/Arcana/One-bit%20computer/On...
[2]https://news.ycombinator.com/item?id=7616831
Yes, exactly. Whatever its other qualities may be, I suspect this particular Forth has overlooked some pretty obvious low hanging fruit, performance-wise. In this[1] post we learn that LOOP puts a 1 on the stack then falls into +LOOP. Although there's elegance (and a memory saving) to that approach, I'm startled that they didn't provide a dedicated definition for LOOP instead. AIUI, implementing LOOP as an instance of +LOOP substantially and needlessly increases the complexity of what gets executed. Yes, I know premature optimization should be viewed with suspicion, but if profiling were performed it's hard to believe LOOP wouldn't be a hot spot! So, I constructively suggest that in this respect at least (and perhaps there are others) this Forth engine could benefit from some tuning up.
There are various ways to manage this, I suppose, but in my case each strip began as a roughly 16 inch length. I folded it 180 degrees at the halfway point and allowed the two legs to stick to each other for about 4 inches. Then the two legs part company, turning 90 degrees but in opposite directions -- and that 90 degree point is where the tape meets the surface of the glass.
Apologies. The original source code from the early 1980's is stored on a non-DOS floppy. Maybe someday I'll retrieve and publish it. But meanwhile here's a taste:
One of the tasks is to activate a solenoid to ink up the lithographic plate after a certain number of revolutions of the press. That number, range 0 to 9, is read from a 4-bit, binary weighted thumbwheel switch which has been set by the press operator.
The code uses 1 instruction to test bit0 of the thumbwheel switch. If bit0 is true, we fall through to another test that waits (jumps to self) until the tachometer pulse goes high; this eventually falls through to another test that waits for the tachometer pulse to go low. So, that's one revolution. But if bit0 of the thumbwheel switch is false, we jump past all this (ie, don't wait for one revolution).
Bit1 of the thumbwheel switch is similarly tested, except the tach must go hi-lo twice (2 revolutions); and so on for bits 2 and 3 (4 revs and 8 revs). Then, with all the counting complete, the solenoid gets turned on.
I have simplified somewhat; actually the rev-counting portion is a subroutine, called from two different places in the code. The (very primitive!) subroutine calling convention is explained in the article. HTH.
One-bit creator here. I'm surprised by how often people make comments like this. Is it the dual jump destinations which seem so confusing? All you need is to ignore one of them, assuming you'll "fall through" instead. This is noted in the article. "instructions generally do tend to get stored in sequential order, and, as a matter of coding style, conditional branches very often do specify address+1 as one of the outcomes. The assembler makes it easy to use the familiar branch, else fall through to the instruction at address+1 arrangement. "
Thanks for posting, Tomte. This and other projects of mine have appeared on HN before.
Edit: but don't use HN's search to find Dr_Jefyll. That's an f there, not a k; but HN's search seemingly can't be convinced of this.
-- Jeff
In the 2016 HN thread "Strange bug workarounds" I posted a much gnarlier problem (and oddball solution): https://news.ycombinator.com/item?id=12485921
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.
"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)."
[1]https://news.ycombinator.com/item?id=3070169
HN folk may recall a project much less ambitious than the KK Computer which, for some reason, attracted far more online attention!
One-bit Computing at 60 Hertz [2]
[2]http://laughtonelectronics.com/Arcana/One-bit%20computer/One...
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!
[1] http://laughtonelectronics.com/Service/Embedded%20Computer/e... [2] http://laughtonelectronics.com/Projects/uCtlr%20Interfacing/...
[1]https://news.ycombinator.com/item?id=3070169
The poster, 0x12, had this to summary to offer:
"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)."
A block diagram and one-page description are here: http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor...
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!)
[1] http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor...
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
>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.
Do you ever visit the forum at 6502.org? There's a smallish discussion about KK there... http://forum.6502.org/viewtopic.php?f=9&t=1487
Also I'm a Forth fan, and when when I realized the counter/timer of a 6522 could be tricked into serving as IP for a 9-cycle machine-code NEXT instruction, the idea amused me immoderately (LMFAO) and I had to build the darn thing! :oD Previous HN thread here: https://news.ycombinator.com/item?id=3070169
I'm the builder! :o)
-- Jeff
@mjhall - you're quite right; the strange, phantom 65c02 operations dramatically expanded what I could do with this project. It's extremely cooperative of the CPU to generate a memory address while leaving all registers unchanged! Although it's true I could've used the PROM to map NOPs onto CMP or BIT instructions and gotten my addresses that way, that approach preserves the registers but still stomps the Flags. In contrast, the "LDD" operations are ideal for the job -- an opportunity handed to me on a silver platter!
-- Jeff
Another revolution of course is the community of the Internet. My KimKlone project was conceived and implemented as a one-man effort, and for years it remained a de facto secret since I had no way to publicize it and almost no-one to discuss it with. These are magical times we live in, and I'm grateful to share your ideas and comments.
-- Jeff