"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.
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.
I somewhat understand what's going on, but it might be helpful to have an example or two of what you actually used this for. Like... what kind of functions did you add to the printing press?
Is the tradeoff here if you use a "simple" 1-bit processor, you have to have more complex data/instructions? Meaning, because you only have 1-bit, there is a lot of jumping around. This means that for everything that you'd want to compute, you'd have to have the instruction flow in memory, instead of relying on more OP codes/instructions for the microprocessor?
This all sounds really interesting, but I'm having trouble completely wrapping my head around it.
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.
I'm glad someone posted this again, since a couple weeks ago I was trying to remember exactly how it worked! (Not for any particular purpose, but I had just remembered it being a nice design for a combinatorial feedback loop.)
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.
Well, that's because you haven't made any submissions. The search only searches for stories (i.e. submissions) by default. Change the pulldown menu field that reads "stories" to read "comments" and it finds all of your comments.
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