Dr_Jefyll

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

Otherwise an interesting article -- I enjoyed it.

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

Repeatedly posted to HN. :-) If anyone's interested and hasn't yet seen it... https://news.ycombinator.com/item?id=26432154

"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. :)

[1] https://news.ycombinator.com/item?id=7616831

[2] https://news.ycombinator.com/item?id=20565779

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

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

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

One-Bit Computing at 60 Hertz https://news.ycombinator.com/item?id=20565779

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:

https://news.ycombinator.com/item?id=12469790

https://news.ycombinator.com/item?id=7616831

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!"

-- Jeff

[1]https://laughtonelectronics.com/Arcana/One-bit%20computer/On...

[2]https://news.ycombinator.com/item?id=7616831

[3]https://news.ycombinator.com/item?id=12469790

[4]https://news.ycombinator.com/item?id=20565779

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

[1] http://forum.6502.org/viewtopic.php?p=76849#p76849

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.

> it might be helpful to have an example or two

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.

>I think I would get a headache "programming" it

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.

Thanks for posting, Tomte. This is a project that's been discussed on HN on the past.

-- Jeff

https://news.ycombinator.com/item?id=7616831

https://news.ycombinator.com/item?id=12469790

Thanks, JdeBP, for remembering the KK :-)

I was delighted at being able to cite an independent source saying such a thing was possible!

In the 2016 HN thread "Strange bug workarounds" I posted a much gnarlier problem (and oddball solution): https://news.ycombinator.com/item?id=12485921

Glad to see confirmation of using a rubber band to fix an IBM mainframe. Been there done that, but the story is so loony I wondered if anyone would believe me. http://laughtonelectronics.com/oldsite/comm_mfg/commercial_i...

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

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

[3]https://news.ycombinator.com/item?id=12469790

Yup. And the triple 8080's contributed a lot to the character of the thing, too.

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!

[1] http://laughtonelectronics.com/Service/Embedded%20Computer/e... [2] http://laughtonelectronics.com/Projects/uCtlr%20Interfacing/...

A prior HN thread [1] about this was entitled, "The KimKlone: a radical 6502 redesign"

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

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!)

[1] http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor...

> autodidact != crank

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.

Thank you for posting. A PCB would be fun but I'd be inclined to do a shrink, moving away from all the jelly-bean logic. I'm pretty sure a KimKlone clone (!) could be done with just a 128 macrocell CPLD, a '574 and the 2 uCode EPROMs, plus the VIA, the CPU, and the stock memory complement (RAM/ROM).

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

I was in my twenties, I was hugely turned on by the electronics I was learning, and I was bursting with creativity! There's a little bit of Back Story explained here, especially the "my KIM" section at the bottom of the page. http://laughtonelectronics.com/Arcana/KimKlone/BrideOfSon%20...

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

Right -- not a 65c816. There's a summary and block diagram here: http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor...

I'm the builder! :o)

-- Jeff

Sorry about the TLDR situation; it's on my list to revise the article by prepending an abstract. BTW suggestions and questions about the article are welcome.

@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

Thank you, 0x12 and all of you, for your interest in my quirky creation. Naturally I follow modern FPGA technology avidly, but I guess it's obvious that my project predates that sort of thing. 2901 style Bit-Slice components were the wonder of wonders not so long ago! But modern programmable logic brings us to another level altogether.

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