A primary use for USB is to connect devices for us to interact with the computer, what The USB Consortium calls a "Human Interface Device" or "HID". I'm talking about things like mice, keyboards, game controllers, accessibility devices, & so *so* much more! They needed a vague term.
So how'd I implement a driver for them on my hypothetical string-centric computer? Using the hardware/software I've been describing?
1990s USB1 speeds are nearly always as much as HIDs require to this day.
1/4?
The generic device-init routine would hand our HID driver, which would then retrieve additional structural metadata holding an array of additional metadata to retrieve, as well as a country-code primarily used for setting the keyboard driver's keymap.
The interesting metadata describes "reports" which we'll decompress to determine how to communicate with the HID.
An initial decompression would lean on our Arithmetic Core's (fast) RAM to sort properties with save/restore stack.
2/4?
The entries defining a "report" consists of a byte consisting of 2bits determining bytes follow (usually 1), 2bits for "type", & 4bits for "tag". Our Parsing & Output Units could handle some of this logic, but mostly I'd be leaning on the Arithmetic Core's couple kibibytes to track 32 properties, <16 of which are preserved on the stack.
Splitting this metadata into inputs, outputs, & configurable features might be a 2nd pass.
From here we can dynamically generate a parser & serializers!
3/5
Each input would specify its bitwidth & array-length, the numeric range, which standardized button/sensor if any it corresponds to, whether it lists sensor values or IDs, how to convert it (via our Arithmetic Core) into standard values, etc, etc.
With the fields sorted I'd compile this to code for our Parsing Unit to decode the bytes/bits, leaning heavily on its support for "pseudobytes" to aid parsing arrays, & pause parsing to output more bytes.
4/5
The results from parsing USB HID packets would be loaded into a global dictionary, whilst diffing against previous values to produce bytes to send to event handlers. Which would primarily be routed to what our window manager determines is the currently-active window.
The outputs meanwhile would be compiled to a simple per-usage Arithmetic Core programs (receiving key-value bytes) to bitpack these fields as expected by the peripheral.
5/5 Fin for today! Tomorrow: Remark on usage pages!
@alcinnz
I use HID at work for things that are very much not human interfaces. They're instruments designed to run unattended for up to several weeks, following an experimental protocol. I think they went with HID because the drivers are already installed in the OS, so it was easier to get started, and then it just stuck. It's been almost 20 years. The low bandwidth gets in the way a bit, but we make do.
