Thank you for BootLife! I explored several code-size, working-memory, and speed tradeoffs based on 86dc8d932db282097fd157e2c65051af7a3dd118, and have published the tested alternatives in a fork. I’m sharing them as an improvement proposal following the contribution guide.
The main techniques are horizontal sliding windows that reuse vertical column counts, a three-row buffer, a runtime-generated color-transition table, a 64-byte embedded binary-rule table, and paired VGA stores. All six supplied production images remain 512 bytes; original ISC notices are retained.
A few choices from the final set:
| Goal |
Variant |
Payload including embedded data |
Work RAM |
| Smallest tested finite-grid payload |
sliding |
408 bytes |
65,536 bytes |
| Low working memory |
rolling_sliding |
467 bytes |
966 bytes |
| Fastest observed kernel |
sliding_lut_word |
473 bytes |
68,096 bytes |
There is an intentional behavior change to review: these alternatives use finite dead borders, whereas the original linear neighbor addressing crosses row seams. Injected gliders are also constrained to fit within a row. They therefore are not pixel-identical replacements for the original at the edges. The byte aging/fading, palette, sparks, gliders, and BIOS timer pacing remain.
Validation boots actual NASM images through BIOS and compares every framebuffer byte against an independent model, with guard/halo, injection-boundary, generated-table, and palette checks. All six delivered versions passed clean-copy checks, and 24 production configurations rebuilt byte-for-byte.
The corrected fastest kernel measurement is about 0.000779 s/generation on QEMU 11.0.1 / single-thread TCG / Apple M5, using a Pentium instruction-set model. This is not a physical Pentium measurement or a claim of that displayed FPS: normal BIOS pacing stays around 18.2 FPS in the measured demos. The article also documents a debugger breakpoint effect that invalidated earlier timing/ranking conclusions; the corrected harness stops outside the boot-code page.
Would finite dead borders be useful upstream, and is there a code-size, low-RAM, or throughput target you would prefer for a focused contribution?
Thank you for BootLife! I explored several code-size, working-memory, and speed tradeoffs based on
86dc8d932db282097fd157e2c65051af7a3dd118, and have published the tested alternatives in a fork. I’m sharing them as an improvement proposal following the contribution guide.The main techniques are horizontal sliding windows that reuse vertical column counts, a three-row buffer, a runtime-generated color-transition table, a 64-byte embedded binary-rule table, and paired VGA stores. All six supplied production images remain 512 bytes; original ISC notices are retained.
A few choices from the final set:
slidingrolling_slidingsliding_lut_wordThere is an intentional behavior change to review: these alternatives use finite dead borders, whereas the original linear neighbor addressing crosses row seams. Injected gliders are also constrained to fit within a row. They therefore are not pixel-identical replacements for the original at the edges. The byte aging/fading, palette, sparks, gliders, and BIOS timer pacing remain.
Validation boots actual NASM images through BIOS and compares every framebuffer byte against an independent model, with guard/halo, injection-boundary, generated-table, and palette checks. All six delivered versions passed clean-copy checks, and 24 production configurations rebuilt byte-for-byte.
The corrected fastest kernel measurement is about 0.000779 s/generation on QEMU 11.0.1 / single-thread TCG / Apple M5, using a Pentium instruction-set model. This is not a physical Pentium measurement or a claim of that displayed FPS: normal BIOS pacing stays around 18.2 FPS in the measured demos. The article also documents a debugger breakpoint effect that invalidated earlier timing/ranking conclusions; the corrected harness stops outside the boot-code page.
Would finite dead borders be useful upstream, and is there a code-size, low-RAM, or throughput target you would prefer for a focused contribution?