These hypotheticals hope to teach the fundamentals of computing. They are not real projects I actually want to build, but I do enjoy toying with these ideas.
Quick tour of what’s involved in a computer recording & generating audio.
How do computers convert a 3D scene into multiple megabytes of 2D image data to be sent to your monitors 30+ times a second in realtime? This hypothetical strives to be as accurate to real hardware as public documentation allows.
Includes a segment on early arcade graphics.
Browsers from Logic Gates
How do web browsers & their underlying operating systems (including I/O, text, & networking) work? How would we build one from-scratch, starting from logic gates? While this will cover core computing concepts in a relatively simple context, it will take a while!
To keep things interesting this hypothetical device won’t support JS, thus necessitating a somewhat-typical CPU. To keep things simple I’ll focus on a happy webby codepath, you should be able to intuit error handling & e.g. Gemini support. The vital UI component of webforms will likewise be a reader exercise.
In summary I’d build hardware focused on parsing text & otherwise-binary streams to rearrange them via a callstack, possibly going through multiple passes. Making frequent use of metaprogramming for key-value mappings, caching, event dispatch, decompression codebooks, CSS stylesheets (parsed in multiple extensively-sorted passes), etc. This device would require not much more software than the standardized EBNF grammars for:
- Its own assemblers & linkers
- Hardware I/O
- IETF’s TCP/IP stack
- Transfer protocols like HTTP or Gemini
- Zip files (mounted on filesystem for hotswapped updates)
- URI schemes
- Markup languages like W3C’s XML/HTML, or even CSV
- CSS properties
- Speech Synthesis Markup Language
- Linguistic pronunciation rules (sourced from eSpeak NG)
Some of this will require non-trivial task switching; & we’d still require a minimal (I’m thinking a 16bit RISC machine, dedicated & possibly-mirrored RAM) arithmetic processor for:
- Triggering timeouts
- Generating random numbers & gathering external “entropy” for it
- Cryptography (though assymetric may require dedicated circuits)
- Parsing & serializing numbers
- Various counters
- Checksums (though dedicated CRC circuits would be cheap & handy!)
- Comparisons for sorting
- Sound effects & speech synthesis (augmented with dedicated multiply-adder between it & the speekers, referencing sine-wave generators simulating breathing)
Add in an analog AI coprocessor (energy efficient, but its durability requires to largely stick with the same few neuralnets; not a problem here!), as well as the various I/O devices we require to access the data we need & to communicate with users, & we’d have an auditory hardware-browser!
A visual browser not only requires additional parsers for images, video, & fonts but also additional hardware. One chip would take a large list of sprites to composite together into the display, caching frames for efficient static displays & video inter-frame decompression. A vectorized multiply-summer within it would aid colour-mixing, gradients, rounded corners, colour-space conversion, resizing, blurs & other convolutions, matrix transforms, etc.
I’d also include a co-processor optimized for doing 32bit arithmetic during tree traversals (binary at a hardware-level, not a software-level though) to handle the complex negotiation involved in document layout, heavily referencing lookuptables to decide how to render text & how wide that text should be. There’d be a few different languages for programming this chip. The lower-level language would be functional (compiling recursion specially), building upon a lower-level stack/concatenative language. The primary & high-level language would allow declaring formulas for CSS properties, keywords, units, etc to for the compiler (running largely on the Layout Unit) to infer a topological sort & implicit loops giving those formulas all the data they need, whilst lowering a high-level collection type. The initial pre-order loop would instead the Output Unit before introducing concurrency, taking full-advantage of the Parsing Unit, Arithmetic Core, & Layout Co-Processor for the more expensive calculations.
See the linked chapters to read in great detail how I’d achieve this!