Greenforest I/O collects Brian Greenforest’s technical articles on software systems, circuits, radio, computing fabrics, rendering, machine learning, and manufacturing ideas.
The strongest pages keep the working object close to the explanation: source path, run, image, circuit, command, result, and operating scope.
Work with me | About Greenforest I/O | Technical work | Project notes | Contact | FAQ
I work on technical systems where behavior has to remain understandable while the system changes.
Good fits include live data, durable preferences, upgrades, migrations, end-to-end tests, production fixes, remote machines behind real networks, parallel computation, circuits, and browser-native artifacts.
Current ask: send the system, the change, and the reliability concern.
The maker loop can reach the board, enclosure, firmware, and fixture. Then it hits active silicon and stops.
This article names the missing civic-scale process: local fast nonlinear gain, restoration, fanout, interconnect, and enough repeatability for real logic.
Radio is an inherited stack of analog front ends, mixers, ADCs, filters, oscillators, and digital processing habits. I wanted to know which parts were necessary.
The page preserves the one-pin FPGA receiver and one-pin resonant-tank transmitter chain, including the Verilog follow-up and the limits of the evidence.
Some article drafts use machine assistance, but the published page still has to carry the source, result, scope, and responsibility for the claim.
Read this if you want the site’s practical rule for assisted drafting.
A Cartilage requirements article: a programmable fabric should keep structure, ownership, timing, runtime change, and continuity readable while it runs.
Read it beside the Cartilage articles when the requirement behind the fabric needs more context.
If computation can be reduced to wires, constants, MUXes, feedback, configuration, and tiling, the substrate becomes easier to inspect.
This printable reference bridges the maker-fab problem to the Cartilage fabric while keeping physical fabrication as a separate process problem.
Cartilage is not only an FPGA-style demo. It is an attempt to make ownership, configuration, and data movement visible inside the fabric itself.
A fabric is easier to evaluate when its marks can be read.
This decoder preserves the 32 Cartilage cell-role codes: reconfiguration port, cross, constants, wire orientations, and the six MUX modes in four orientations.
Reconfiguration should not arrive through a hidden global controller. Regions should own and replace daughter regions through visible local ports.
This browser/GPU demo shows tiled regions, local configuration streams, and nested replacement behavior in the canonical Cartilage artifact.
Ownership became visible enough to show square child regions and active port roots inside a running fabric.
This self-contained WebGL/GPGPU milestone preserves the 6x6 ownership block work and active port-root initialization fixes.
The older WebGL automata show computation moving through local rules before the fabric became circuit-like.
This archive preserves the reversible-routing, machine-like, organic, and Cartilage-branch browser/GPU experiments that led into the current fabric work.
Serial is not automatically inferior when the schedule remains full.
This positive-number Logisim multiplier keeps bit-serial arguments and products moving continuously after the pipeline fills, trading wide immediate products for regular local timing.
A tiny model is valuable here because it can be inspected, not because it competes with large models.
The artifact preserves 4 layers, 16 attention heads, 128-dimensional embeddings, 128-token context, a 361-token vocabulary, about 834k parameters, and training past 50,000 iterations until the tiny model produced small but intelligible samples.
A self-contained Python scanline renderer uses UV-space 2D SDF material tests, point-cloud foliage speckles, triangle trunks and branches, and a UV-SDF deer sprite to make a small forest scene without ordinary bitmap texture art.
The article keeps the generated frame, source-code PDF, row-fill algorithm, UV-SDF material path, procedural scene geometry, and original post links together so the image can be read as renderer output.
Cartilage pages are grouped by use: checked runs, recorded timelines, visual placement sketches, and current reading paths.
A reader guide to six generated Cartilage pages: checked runs, recorded timelines, visual placement sketches, source artifacts, and the current Cartilage reading path.
Early control, switching, visible state, and browser-native experimentation.
The sequence collects scaffolding, minimum WebGL, history/control, logic, addition, and other early steps in the computation path.
Local-rule WebGL automata exploring reversible routing, conservation, machine-like behavior, organic patterns, and the Cartilage branch.
A dated trail of thoughts rescued from the feed: technical arguments, collaboration requests, and invention fragments.
Read it as a library of standalone article pages.
Older project-status writing from web-development and research-progress work, preserved with dated context.
Magnetics: can useful circuit behavior escape semiconductor fabrication? The notes gather magnetic material properties, magnetic amplifier behavior, second-harmonic modulation, and diodeless circuit ideas while keeping feasibility questions open.
Backprop: can learning be wired from primitive operations so the gradients remain visible? The thread is about multiplication, addition, fan-out, elementary functions, and derivative feedback as inspectable machinery.
Fabrication: can active or semi-active substrates become physically reproducible at civic scale? This note connects through-wafer dicing, SiO2-protected chiplets, near-field power/clock/data links, resonant distributed energy storage, and Cartilage-style spatial computation to the old Claytronics problem.
The PDF remains the manufacturing reference. The local article explains why that reference belongs on Greenforest I/O and where the speculative boundary still is.
For search clarity: Greenforest I/O is not forestry, landscaping, arborist, or forest-product services.
Greenforest I/O is the public research notebook of Brian Greenforest, connected to Solid State Pros LLC for emerging-technology R&D and product-design work.
Legal entity: Solid State Pros LLC. Email: brian@solidstatepros.com.
Contact Greenforest I/O, inspect proof and artifacts, visit Solid State Pros LLC, or read the brand/entity page if you arrived here looking for the official Greenforest result.
