> I find [8086 segmentation] enormously preferable to the 65816’s bank system. The primary advantages are twofold: segment overrides may be provided to any pointer, which means that it is less necessary to juggle segment values the way it is necessary to juggle the 65816’s data bank pointer, and—even more crucially—the 8086 has two simultaneous data bank pointers (DS and ES), which allow accessing two “far” pointers simultaneously without any register juggling at all.
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).
> when an ESCAPE instruction is encountered, the 8086 processor starts executing the instruction, even though it is intended for the 8087. The 8086 computes the memory address that the instruction references and reads that memory address, but ignores the result.
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).
"One Bit Computing at 60 Hz" describes a one-bit design of my own that folks have repeatedly posted to HN. It's notable for NOT using the MC14500... (and for puzzling some of the readers!)
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. :)
Clever and interesting! But not new. FWIW, I remember repairing a PA or musical instrument amplifier in the 1990's whose power transformer featured this type of core and bobbins. Its novel appearance and intriguing construction attracted my attention immediately! :)
Probably the second-best fun I ever had was reverse engineering a discrete-TTL processor and the firmware written for it. These were embedded in some Xerox Diablo daisy-wheel printers dating from the latter half of the 20th Century. And the best fun I ever had was hacking that code to better suit the unique needs of my customer!
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].
>The MC14500B has an unusual architecture, making it more of a building block than a complete microprocessor. [... It] requires multiple external chips to make it usable.
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!
Picking up on the "three at once" theme, the 1-bit computer I built in the 1980's has an instruction that does three things.
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:
Great choice of subject matter, as usual, Ken! May I direct your attention to a one-bit machine [1] that's already something of a favorite on HN, posted for discussion in 2014 [2], 2016 [3] and 2019 [4].
"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!"
>this only tells us about the performance of this particular FORTH engine
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.
Rather than buying suction cups (for which I would subsequently have had no further use), I managed very nicely by using just a couple of strips of packing tape. Each strip formed a "handle" -- one on each side of the screen, same as you'd do with the suction cups.
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 of us must be drinking de-caff by mistake! :D When I use the search at the bottom it "corrects" the spelling, not even bothering to remark on what it did. Adding quotes was good suggestion, but now there are 0 search results.
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.
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)."
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.