> 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.
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.