ZedRipper: A 16-core Z80 laptop
chrisfenton.com
chrisfenton.com
https://www.ijcai.org/Proceedings/81-2/Papers/071.pdf
>ZMOB: A NEW COMPUTING ENGINE FOR AI. Chuck Rieger, Randy Trigg, Bob Bane
>ABSTRACT: A new research multiprocessor named ZMOB is described, and its significance to AI research is surveyed and characterized. ZMOB, under current construction and scheduled for completion late Fall 1981, is a 256 processor machine with a high speed, interprocessor communications system called the "conveyor belt", a non-blocking, 20 megabyte/second message switcher. Because of its large number of processors, high computational throughput (100 million instructions/sec), large cumulative high speed memory (16 megabytes), high interprocessor communications bandwidth, and external communications and sensing channels, ZMOB opens some new areas of exploration in object-oriented modeling, knowledge-based and domain expert systems, intelligent sensing and robotics, and distributed perceptual and cognitive modeling. The paper attempts to blend a description of ZMOB's hardware with ideas about where and how it fits into various types of AI research.
https://retrocomputing.stackexchange.com/questions/5080/fast...
>The fastest Z80 computer ever designed and built was almost certainly ZMOB, a 256 node Z80A cluster designed and built at University of Maryland as part of NASA NSG-7253. That's a total of 1GHz of Z80 power.
By far the most important feature of ZMOB was that each board had four differently colored software blinkable LEDs, all arrayed behind the smoked plexiglass cover of the rack they were all plugged into. It looked really cool and was great for hypnotizing and mesmerizing people, which was how we got a big NFS grant (which we spent on Vaxen and Suns and Xerox workstations).
https://news.ycombinator.com/user?id=bane
Here's a photo of some UMD people in front of ZMOB in the Department of Research Simulation, with some white Xerox file servers and black Sun server in the background:
https://www.cs.umd.edu/sites/default/files/zelkowitz-report....
Laboratory for Parallel Computation and Z-MOB Around 1980, Dr. Charles (Chuck) Rieger (Figure 3.12) designed a computing system to run as a network of processors. The initial design consisted of 256 Z80A processors. Each contained 64K memory, linked together on a “conveyor belt” (a 48-bit wide slotted ring architecture), as packets of information were passed from one processor (or “moblet”) to another. This “mob of Z80s” soon became known as Zmob. The system was programmed and controlled by a host VAX 11/780 computer. An Air Force Office of Scientific Research grant was obtained for building the basic Zmob hardware.
It was apparent to both Minker and Basili (after addressing the crush of student majors) that to be a top department, we needed more equipment. Minker was behind the acquisition of the VAX 11/780 (Mimsy) in 1980, which was a good start, but was insufficient. We needed terminals on every desk, additional machines like Mimsy, and a laboratory under our own control. Computers were our technology and if we couldn’t have and control our own machines, our research in this area would always be hampered.
In 1982 Basili organized a proposal team, consisting of Agrawala, Minker, Rosenfeld, Stewart, and Weiser. They met and came up with the idea of a parallel computation laboratory, using some of the ideas in Zmob as a starting point. A Coordinated Experimental Research (CER) proposal was written to NSF, and in 1983 it was funded as a 5-year $4.3M grant. This grant greatly expanded the departmental laboratory, purchasing machines tove, gyre and gymble, as discussed earlier.
PRISM, under the direction of Minker, was the core of the CER project. It was conceived as the software system designed to run on Zmob, and was run as a simulator on the VAX. It used Horn clause logic (similar to the design of Prolog) to implement AND/OR parallelism. Users could specify the number of problem solving machines (i.e., moblets) to use, the number of database machines to use, and the number of machines to handle executable procedures. Statistics were collected to determine how effective the search strategy was. Users could also run PRISM in a sequential Prolog-like manner.
Continued Zmob research was funded by this grant and a version consisting of 128 moblets was built and installed in the Department laboratory (Figure 3.13). Moblets were accessed by physical address or by pattern matching. Programming in Prolog like languages was seen as the mechanism for using Zmob. Mobix was the operating system designed to run on Zmob, which would hide many of the complexities of the Zmob hardware.
Due to inexperience in hardware design, Zmob ran, but not as reliably as desired. The Z80s were 8-bit processors and became obsolete too soon. 16 bit and 32 bit versions of Zmob were designed, and a 16 node ring of 16-bit processors using the Motorola 68010 processor, called McMob, was built and used for several years. Initial design work for a further advancement, called Chessie, was started, but a prototype Chessie was never built. Work continued for several years, but after the NSF grant that suppported most of the development ended, work slowly stopped on that activity.
Mark Weiser’s foot “mole” of 1986 was another interesting idea that grew out of the CER grant. Instead of using a mouse controlled by the hand, a foot pedal was developed, eliminating the need to move the hands off the keyboard in order to control the screen. Several variations were built and tested on Sun workstations, but the concept never became fully operational. Unfortunately for the Department, Weiser soon left for a research position at Xerox Palo Alto Research Center and this activity also ended.
[0] https://twitter.com/eismcc/status/1201310140416217089?s=20
I got as far as getting BASIC to run, but struggled porting FORTH to z80. Existing Z80 forth interpreters I found need almost 64k but wiring up some static-RAM hasn't yet given me a functional system so I'm hazy on what is wrong; either my real-RAM or the interpreter itself.
You probably didn’t do something that silly though.
Is that where the Mill architecture has the belt concept from? I think i heard some belt concept in the Mill's architecture's context.
The belt is more a temporal view of the bypass network instead of a register file.
Too bad, lost interest. Only a few years later with 16bit and MSDOS and faster CPU it became practical and I could have been the first such product to market but I was stupid.
I also had written a Turbo Pascal TSR program (using a 3rd party TSR toolkit) that was like strace on linux, writing system calls to disk in the background. I used it to troubleshoot many application program mysteries.
Having no patience to wait for games to load, I linked the two together via the parallel printer interfaces and wrote some Z80 code on either end to allow the TRS80 to store CPC464 programs.
I seem to remember only being able to use 6 of the bits for data, and using a couple of the others to signal as "clear to send" between them. The transfer was very quick, much faster than tape, but wasn't very reliable due to the dodgy connectors on the TRS80.
Using an SD card with the old micros would be miles better.
If you haven’t seen it already, the 8 Bit Guy has a fun video about working in AST’s tech support in the 90’s:
(I couldn't remember what the sixth function was, turns out it's "new compact size." http://chiclassiccomp.org/docs/content/computing/AST/000490-...)
I'm amazed that people can build homebrew computers using Z80, MOS 6502/6510, or Motorola 68k series microprocessors.
I could buy one of those homebrew Z80 kits and assemble it, but I don't think I'll gain much real understanding just from the act of assembling the kit.
I have long wondered how things work down to the bare-metal level. What does it take to be able to design (and program?) a homebrew computer? Let's say I leave out the FPGA route and only focus on using real, off-the-shelf ICs.
I'm mostly just a software guy (I write Python, I've learned automata theory at University) but I haven't learned any real electronics beyond things like Ohm's law, KCL, KVL, capacitance, impedance as a complex number. I don't even know my transistors or diodes.
The Elements of Computing Systems / From NAND to Tetris https://www.nand2tetris.org/
The first six textbook chapters (all the hardware stuff) are available on the website in the 'Projects' tab, you should buy the book for the other six. All 12 chapter assignments are available on the website. The Software section has a hardware simulator to test your designs.
From there it's not a tall order to start interfacing SRAMs and some EPROMs and a UART chip and you can get a machine you can connect to over serial.
Just try! It's worth it!
https://www.youtube.com/watch?v=nFIviiwPrLI
The Z80 has RAM-refresh support built-in, and can be hand-clocked if you wish making it one of the simplest processors to run - in terms of required external components.
Going after things at a really low level, books like The Art of Electronics take you from transistors (and through things you probably don't care about, like power supplies and amplifiers) to digital electronics, to simple computer system design. You can probably find value by skimming the component-level stuff, skipping the goopy analog chapters, and just reading the digital electronics sections. (This is more or less how I started with personal computers in 1974 or so).
Can you give some examples and why/in what respect they are better than (David) Patterson's books? Or are those "better texts" the Ars Technica CPU reviews and manufacturer datasheets that you mentioned in the subsequent sentence?
The websites I mentioned have hobbyist-level details that are pretty interesting (but in general won't teach you much about things like concurrency hazards and branch prediction and so forth).
The TRS80 Technical Reference Manual (1978). This had the full schematics of the computer, explanations, timing diagrams, fault finding tips etc.
Understanding Microprocessors (1979). This taught basic TTL gates, how flip-flops worked, shift-registers, adders and all the other basics.
In my opinion learning this stuff gives you a better understanding of coding, especially with low level languages.
Is that a skill that's related to how you do optimisation in certain puzzle games? E.g. TIS-100, Opus Magnum, Factorio. Or not really?
The big breakthroughs were the ability to simulate hardware for larger circuits at higher frequencies realistically to determine how to make those circuits stable rather than to get them to oscillate wildly at the frequencies they operate at. Once you develop a bit of appreciation for what is required to make a 100 gates work reliably at 10 MHz or so you can begin to understand the black magic required to make billions of transistors work reliably at frequencies in the GHz.
So the skill is not at all related to puzzle games, but it is a puzzle and the tools and knowledge required were usually hard won. At those frequencies and part sizes anything is an antenna, there is no such thing as a proper isolator, coils, resistors and capacitors all over the place even if you did not design them into the circuit (parasitics).
If this sort of stuff interests you I highly recommend the 'Spice' tutorials, and/or to get an oscilloscope and some analog parts to play with.
https://hackaday.com/2019/01/24/video-putting-high-speed-pcb...
Dont remember the exact video, but Bill Herd mentioned many times about on site last minute fab fixes involving prodding the product on a hunch of where the problem might be.
Today you can simulate and measure pretty much everything, plus automated design rule tools will warn you of potential problems beforehand.
For my own project I have a PicoRV32 RISC-V core running at 150mhz, with HDMI output, character set generator, sprite graphics generator, bitmap graphics output, and a UART all in under 8000 LUTs...
> As I’ve mentioned before, all of the logic so far is
> pretty lightweight, occupying a mere 7% of on-chip
> logic resources
I switched from 8-bit (Z-80B) hardware to 16-bit (i386) hardware once the 16-bit PC could emulate the Z-80 faster than any physical Z-80 processor could run. I feel fortunate to have skipped the 8088 and 80286 PCs which all ran slower than my Z-80B for most things.
I kept one of my old CP/M machines in my parent's garage for 10 years, and then tried to resurrect it. It was an IMSAI 8080 with CompuPro hardware that I had modified to allow the front panel to work while allowing the system to run at 4MHz. I had also implemented software configurable baud rate and start/stop/parity selection by hacking the hardware and customizing the BIOS.
Unfortunately when I resurrected it, it booted and ran for only a short time before the ST851 hard drives scraped the oxide coating from the system disks. (I destroyed all of the backups while troubleshooting.)
I gave the whole system away before I discovered that they are actually still quite valuable, but I have no regrets. I much prefer a more modern computer.
https://en.wikipedia.org/wiki/Zilog_eZ80
My TRS-80 Model 4 back in the day (circa 1988, I think) had been upgraded with a HD64180 CPU, which apparently could run at least at 10 MHz -- although I'm pretty sure the third-party expansion board I was using ran it at 6.144 MHz.
Good ol' Z80s are still in active production as well, and you can buy a 20MHz chip in a DIP, LQFP, or PLCC package.
Anyone who is interested should check out the RC2014 and retrocomp google groups. Lots of discussion there, and there are a few people selling Z80 and Z180 computer kits.
https://groups.google.com/forum/#!forum/rc2014-z80 https://groups.google.com/forum/#!forum/retro-comp
Isn't the i386 the first 32-bit x86 processor, not 16-bit?
> Think of it in the same context as the 8088 vs. 8086.
Yes, both of those are 16-bit but the 8088 is a later low-cost version with an 8-bit data bus, but an identical execution unit to the 8086.
Same for the 8088 - that was still a 16-bit chip like the 8086 (almost identical, in fact), but with a smaller (8-bit) external data bus so 16-bit requests to/from memory had to be split in two.
Imagine an 8088 running at 4.77MHz trying to keep up with a Z-80 running at 4MHz. The Z-80 always won because of the memory bandwidth issue.
But the "386SX was a 16-bit CPU capable of 32-bit operations" is simply an incorrect statement, which we are correcting. The 386SX was a 32-bit CPU with a 16-bit data bus.
Your new Z80 comparison seems flawed too: while it supports some 16-bit operations over paired 8-bit registers, including 16-bit load & save, the Z80 is generally considered to be an 8-bit CPU (so it is an 8-bit CPU capable of 16-bit operations) and in any case it has an 8-bit data bus (see the diagram in https://www.petervis.com/electronics/CPU_Processors/Zilog_Z8..., note that there are only 8 data lines, D0 through D7) so it can't pull/push 16-bits at once externally any more than the 8088 can.
I might believe that compared to an 8088 running at 4.77 Mhz like in the original PC but the 286 is in another league entirely.
https://en.wikipedia.org/wiki/Scott_Adams_(game_designer)
The Scott Adams adventure game series was published around 1978-83, and started on the TRS-80 Model I. I don't know if there were ever official CP/M ports, but they were certainly of that era.
I guess this was a port of the classic Adventure game to Tandy. I had the CP/M version (550 point Colossal Cave Adventure). I had played it even earlier on RT-11 where it took about half an hour to load from two 8" floppies.
‘Bureacracy’ seemingly wasn't: https://en.wikipedia.org/wiki/Bureaucracy_(video_game)
...but like HHGttG it targets the Z-Machine, and third-party interpreters for Z-Machine files have been written for probably every platform under the sun. It's also possible that executables from HHGttG can be repurposed. This post seems to support the latter approach: https://retrocosm.net/2011/01/03/z-machine-interpreter-for-c...
Both games are maddeningly hard, btw. I don't think I finished either of them.
Actually, it's the BBC controlling us from London.
https://www.intel.com/content/www/us/en/programmable/product...
$129 for an Artix 7 development board is a steal [1].
[1] https://store.digilentinc.com/arty-a7-artix-7-fpga-developme...
I mean this stuff would have seemed absolutely incredible to my 18 year old self. And so very cool to see a reference to MP/M. Though I seem to recall needing to use 8080 mnemonics to work on MP/M?
Bless them, they sent it, and that's how I got started learning microprocessor architecture.
If I was smart enough to know how to post a photo to HN then I would do so :)
May the gods help any kid that tries to learn Intel CPU architecture that way these days. :-)
I'll always have a soft-spot for Z80 assembly, and have started to work on raw Z80 processors myself now - after spending the past year or two playing with Arduino and ESP8266 devices.
My latest experience is with AVR assembly. What is it about Z80 that makes you prefer it? Wider variety of practical instructions? Cleaner design?
This blog got me curious about looking into Z80. Not a chip I ever learned anything about. I started out as an Amiga guy and I would occasionally come across books and stuff about 6502. Z80 is just a name I heard from time to time.
https://blog.steve.fi/how_i_started_programming.html
The instruction set is simple, and clean. The fact that you don't need much supporting circuitry to drive it is a nice bonus, but mostly I remember coding the thing when I was 12 or so, and now I know what I'm doing for real :)
I really liked it, and I absolutely hated x86 assembly when I tried that later. x86 seemed so quirky to me, with its segment registers and the naming of assembly instructions just didn't seem as nicely organized as for 68000, which almost felt like high level language in comparison.
x86 turned me off assembly for years. I have gotten some interest again these last years by playing around with AVR. I like AVR for the simplicity and low price.
Perhaps you could sell me on Z80, how does it compare to using AVR chips?
Like the 68K, the Z80 had great mnemonics, was really easy to understand. In many ways I think it was at least a spiritual predecessor to the 68K. I mean, Z80 was an 8 bit CPU and 68K was much more capable 16 bit CPU. My guess is that if you liked the 68K you'd probably like the Z80.
Intel mnemonics always sucked :) 8086 and 80286 put me off assembly language too.
I don't know the AVR... don't get to play with CPUs much any more :(
The only C compiler I had on CP/M was BDS C. It was fairly limited and had no floating point support whatsoever. Maybe that's the one you're thinking of?
I learned Zilog first and agree with you. I had to keep an 8080 manual handy for a while to make any sense out of that compiler output.
Good(?) times.
Close up of disk drives and an instance running Wordstar:
I added a physics engine and started working on a demo with a jet/ship thing controlled with a C64 assembler program but it had a lot of work left and I will have to go back to it after I get more basic stuff going.
I integrated color VT100/ANSI support into the terminal emulator and had basic TCP/IP network working with a simple telnet+zmodem client as well. So you could log into BBS's on the Internet and download files to the CP/M systems:
https://i.imgur.com/6V97v57.png
https://i.imgur.com/fhqef4c.png
https://i.imgur.com/K44GT1W.png
Mine was really a prototype, since then I've been working on a 68000 based emulator and an OS for it which I might integrate back into UE4 day. The other issue I ran into was how to go about simulating the spaceflight part of it. Somebody gave me a pointer about that though earlier today so I might have to get back into it.
Geekiest accomplishment: A disk loader for Spindizzy. The game was too large for the main memory with the disk driver loaded.
Had to use the video buffer to load the game in two parts and splice them together (overwriting the disk driver). Fun times!
I would not pay $1000 for experience, but some more reasonable amount, totally.
TrackPoint (2011) (microsoft.com) [Buxton Collection]:
https://news.ycombinator.com/item?id=9437780
https://www.microsoft.com/buxtoncollection/detail.aspx?id=60
Some stuff I wrote about the Trackpoint and relative input devices in general:
https://news.ycombinator.com/item?id=18340403
>Input devices should allow users to configure a velocity mapping curve (which could be negative to reverse the motion). X-Widows had a crude threshold-based mouse acceleration scheme, but it's better to have an arbitrary curve, like the TrackPoint uses, that can be optimized for the particular user, input device, screen size, and scrolling or pointing task at hand.
>https://wiki.archlinux.org/index.php/Mouse_acceleration
>One of the patented (but probably expired by now) aspects of the Trackpoint is that it has a very highly refined pressure=>cursor speed transfer function, that has a couple of plateaus in it that map a wide range of pressures to one slow or fast but constant speed. The slow speed notch is good for precise predictable fine positioning, and the fast speed notch is tuned to be just below eye tracking speed, so you don't lose sight of the cursor. But you can push even harder than the fast plateau to go above the eye tracking plateau and flick the cursor really fast if you want, or push even lighter than the slow plateau, for super fine positioning. (The TrackPoint sensor is outrageously more sensitive than it needs to be, so it can sense very soft touches, or even your breath blowing on it.)
Ted Selker demonstrated an early version of the "pointing stick" in 1991:
https://www.youtube.com/watch?v=6hhnlaUxsL8
Ted always reminds me of another distinguished "Button Man": Mr. Lossoff from Nero Wolfe's "Mother Hunt". Those Button Men can be pretty intense!
Maybe you could even learn the curve by counting pointing error (measure the overshoot before clicking), and maybe make it two dimensional (i.e. the sensitivity and acceleration are different based on the direction).
I use a program called BrightML to do automatic screen brightness control. It's innovative in that it accounts not only for time of day, location, and ALS if you have it; but also considers which application is focused when you set the brightness. If there is an application which you always turn down the brightness for when it's focused, it'll turn it down in anticipation.
A similar thing could probably be done for the TrackPoint acceleration.
Ted wrote some amazing stuff about adaptive curves and other cool ideas he tried, at the end of his whirlwind exposition to Bill Buxton:
https://www.microsoft.com/buxtoncollection/detail.aspx?id=60
>The ones that got away are more poignant. I designed adaptive algorithms we were exploring- we were able to raise the tracking plateau by 50% for some people, and if we had had the go ahead we could have made that stable and increased performance tremendously. It seems some people used tendon flex to improve pointing- we found this looked like overshoot and we had trouble making the adaptive algorithms stable in the time box we gave it. We made a special application that was a game people played to improve their pointing –as their game play improved the transfer function improved too! We made a surgical tool that used a Trackpoint to allow tremor-free use of a camera from a laparoscope. We made a selector for the FAA to do ground traffic control that saved a multihundred million dollar contract for IBM with the government. I would have loved the product to change cursor movement approach for form filling, text editing and graphical applications; again that could probably double performance. Yes, I s till want to do it NOW. We built a gesture language into the Trackpoint that can be accessed in the firmware; the only aspect the driver exposes is Press to Magnify or Press to Select. We created probably two dozen haptic feedback Trackpoint designs. They improved novice performance and were loved by the special needs community. I did a preliminary study that showed how novices selected faster with it; the product group saw no need to spend the money for that. We made a science experimental test bed to teach physics that never shipped; we made many versions of multi-Trackpoint keyboards that never shipped. We made many other things too- a versatile pointing device for the table called Russian tea mouse allowed for full hand, thumb, finger, or in-the-palm use. We made pen like stalks that allowed selection without taking hands off the keyboard. We made devices that used one set of sensors to run two input devices. We made an electormechanical design used by one special user. We found that brushing th e top instead of pressing it could give amazing dynamic range, at the expense of having to cycle the finger for long selections. The joystick for this had no deadband, it had an exquisite sensitivity and control … we never made an inkeyboard device that shipped with this alternative set of algorithms and scenario. I designed better grippy top ideas that never made it; also better sensitivity solutions that never made it too. And I hate to say it but there are many other improvements that I made or would like to make that I could elaborate further on but will stop here…..
While I'm not sure if this video of the 1995 New Paradigms for Using Computers workshop actually shows a dual-nippled Thinkpad, it does include a great talk by Doug Engelbart, and quite a few other interesting people!
https://www.youtube.com/watch?v=oD9NUWDCyHI
The multi-Trackpoint keyboard was extremely approachable and attractive, and everybody who saw them instantly wanted to get their hands on them and try them out! (But you had to keep them away from babies.) He made a lot of different prototypes over time, but unfortunately IBM never shipped a Thinkpad with two nipples.
That was because OS/2 (and every other contemporary operating system and window system and application) had no idea how to handle two cursors at the same time, so it would have required rewriting all the applications and gui toolkits and window systems from the ground up to support dual trackpoints.
The failure to inherently support multiple cursors by default was one of Doug Engelbart's major disappointments about mainstream non-collaborative user interfaces, because collaboration was the whole point of NLS/Augment, so multiple cursors weren't a feature so much as a symptom.
Bret Victor discussed it in a few words on Doug Engelbart that he wrote on the day of his death:
http://worrydream.com/Engelbart/
>Say you bring up his 1968 demo on YouTube and watch a bit. At one point, the face of a remote collaborator, Bill Paxton, appears on screen, and Engelbart and Paxton have a conversation.
>"Ah!", you say. "That's like Skype!"
>Then, Engelbart and Paxton start simultaneously working with the document on the screen.
>"Ah!", you say. "That's like screen sharing!"
>No. It is not like screen sharing at all.
>If you look closer, you'll notice that there are two individual mouse pointers. Engelbart and Paxton are each controlling their own pointer.
>"Okay," you say, "so they have separate mouse pointers, and when we screen share today, we have to fight over a single pointer. That's a trivial detail; it's still basically the same thing."
>No. It is not the same thing. At all. It misses the intent of the design, and for a research system, the intent matters most.
>Engelbart's vision, from the beginning, was collaborative. His vision was people working together in a shared intellectual space. His entire system was designed around that intent.
>From that perspective, separate pointers weren't a feature so much as a symptom. It was the only design that could have made any sense. It just fell out. The collaborators both have to point at information on the screen, in the same way that they would both point at information on a chalkboard. Obviously they need their own pointers.
>Likewise, for every aspect of Engelbart's system. The entire system was designed around a clear intent.
>Our screen sharing, on the other hand, is a bolted-on hack that doesn't alter the single-user design of our present computers. Our computers are fundamentally designed with a single-user assumption through-and-through, and simply mirroring a display remotely doesn't magically transform them into collaborative environments.
>If you attempt to make sense of Engelbart's design by drawing correspondences to our present-day systems, you will miss the point, because our present-day systems do not embody Engelbart's intent. Engelbart hated our present-day systems.
That's ok for games that implement their own toolkit, or use one you can easily bolt on and hack, but not for anything that needs to depend on normal built-in system widgets like text editors, drop-down menus, etc. (And if you roll your own text fields instead of using the system ones, you end up having to reimplement all kinds input methods, copy/paste/drag/drop, and internationalization stuff, which is super-tricky, or just do without it.)
I implemented multi-player cursors in SimCityNet for X11 (which opened multiple X11 displays at once), but I had to fix some bugs in TCL/Tk for tracking menus and buttons, and implemented my own pie menus that could handle being popped up and tracking on multiple screens at once. TCL menus and buttons were originally using global variables for tracking and highlighting that worked fine on one X11 display at once, but that caused conflicts when more than one user was using a menu or button at the same time, so it needed to store all tracking data in per-display maps. It doesn't make sense to have a global "currently highlighted button" or a "current menu item" since two different ones might be highlighted or selected at once by different people's cursors.
And I implemented special multi-user "voting" buttons that required unanimous consent to trigger (for causing disasters, changing the tax rate, etc).
I had to implement multi-user cursors in "software" by drawing them on the map manually, instead of using X11 cursors.
I wrote about that earlier in a discussion about Wayland and X-Windows:
https://news.ycombinator.com/item?id=19732733
And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users.
>https://tronche.com/gui/x/xlib/input/XGrabPointer.html
For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software".
Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected.
So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map.
Multi Player SimCityNet for X11 on Linux:
https://www.youtube.com/watch?v=_fVl4dGwUrA
>Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins.
X11 SimCity Pie Menus:
https://www.youtube.com/watch?v=Jvi98wVUmQA
Multi-user menu tracking (added "@$screen" parameterizations):
https://github.com/SimHacker/micropolis/blob/master/micropol...
Opening multiple X11 displays (multiple toplevel "head" windows per screen, each with a unique id, using $win parameterization):
https://github.com/SimHacker/micropolis/blob/master/micropol...
It's my older thinkpad I keep around to ssh into things. They were completely and utterly surprised by the presence of the trackpoint and found it to be extremely unusual.
All IBM's original patents on TrackPoint must surely have expired by now, so it always surprised me that we didn't see other OEMs start offering it as an option. There are a couple that have, but only on a few models, and by all accounts non-IBM/Lenovo TrackPoint implementations aren't quite as good for some reason. Disappointing!
If I had time to add 1000Hz polling to the thing, I'd probably still be using it.
Yeah. After many years with old X- and T-series IBM/Lenovo Thinkpads i got a Dell Latitude recently. It's pretty decent but the trackpoint (they call it "pointing stick") sucks in comparison. Also it's not red.
I thought about using at least the IBM dome on it, but they aren't compatible – IBM/Lenovo dome is higher and the square hole is bigger: https://i.vgy.me/u1SUKm.jpg
Mentally adds the ZedRipper right after Leon and RiscV
I definitely want to see if I can bring something like this up on one of the many FPGA boards I have in my junk drawer!
https://www.researchgate.net/publication/309254446_Adaptive_...
https://archive.org/details/bitsavers_inteldataBrsManual_570...
Awesome 74xx/40xx series logic quick reference
https://www.mouser.com/catalog/supplier/library/pdf/STLogic....