bedrock-js, branch mainBedrock emulator and assembler for webpages
https://code.benbridle.com/bedrock-js/atom?h=main2025-09-12T19:50:48ZUpdate version to 1.1.12025-09-12T19:50:48ZBen Bridleben@derelict.engineering2025-09-12T19:50:48Zurn:sha1:c11603d463ab5e5975954ce9342d251abd6c0ca5Fix draw operations failing at the start of a program2025-09-12T19:50:11ZBen Bridleben@derelict.engineering2025-09-12T19:20:51Zurn:sha1:8de8a05ffbd622810cc23f6ae818c3bd6cfcf8a0
The emulator screen panel is designed to stay hidden until it's needed,
so that headless programs don't have a large black canvas taking up
space on the page. The issue was that the screen content won't be
rendered to the canvas if the screen isn't 'dirty', and the screen will
only be marked dirty if there's been a draw operation in-bounds, and
the size of the canvas determines what counts as in-bounds, and the
size of the canvas remains zero until the layout engine has a chance to
resize it during the next browser render tick. This is all fixed by
breaking the current evaluation loop, yielding control back to the
browser, and having the updateScreenSize function queued up to act on
the newly-resized canvas element. Evaluation will then continue as
normal.
Implement the FORK and RESET device signals2025-09-12T19:50:11ZBen Bridleben@derelict.engineering2025-09-12T19:19:05Zurn:sha1:39af042fbcc7cf900493df33f69281a39dee4a51
These were implemented before version 1.1.0, but I hadn't gotten around
to implementing them again during the big restructure in commit 19c5679.
The main change here is that the existing `reset` method was renamed to
`end`, and a new `reset` method was created that only affects the core
and devices.
Zero the cycle counter in WASM core on reset2025-09-12T19:50:11ZBen Bridleben@derelict.engineering2025-09-12T18:28:59Zurn:sha1:b452cc1a0afdfe863b5dd92b8bd9d05fd9e347a8
This was incrementing higher and higher each time the program was
re-run after halting.
Update version to 1.1.02025-09-12T05:28:54ZBen Bridleben@derelict.engineering2025-09-12T05:28:54Zurn:sha1:60bfb4f0f675ab4cb9b07d6fcd772d46d6b7222aImplement a faster core in WebAssembly2025-09-12T05:28:44ZBen Bridleben@derelict.engineering2025-09-12T05:20:19Zurn:sha1:19c5679b8be4fe879e165576e97f96b85f5b5044
This is a massive commit that restructures a lot of the library. The
primary change is the implementation of a second Bedrock core using
WebAssembly, which performs much better than the existing JavaScript
core. The JavaScript core has been retained as a fallback for browsers
that don't support WebAssembly.
Benchmarking both cores using the numbers benchmark and with all of the
devices stubbed out in the emulator demonstrates a 40x speedup for the
WebAssembly implementation (going from 4800ms to 120ms).
Measure run performance2025-09-07T07:04:41ZBen Bridleben@derelict.engineering2025-09-07T07:04:41Zurn:sha1:4c67a10f265dde1c3aa430cb851062a38646d6f2Improve transmission rendering performance2025-09-07T06:47:51ZBen Bridleben@derelict.engineering2025-09-07T06:46:29Zurn:sha1:53fa574c9af4095f07f4883547939a25522f81e6
Previously, the DOM would be updated every time a complete character
was pushed to the transmission parser by the stream device. This caused
frequent re-renders of the transmission panel and massively slowed down
the emulator.
To fix this, the contents of the transmission parser are now only
flushed to the transmission panel when the state panel updates, which
is currently every 10_000 cycles.
Show assembled bytecode when checking program2025-09-07T06:43:07ZBen Bridleben@derelict.engineering2025-09-07T06:43:07Zurn:sha1:e09013621b3c26945d16d7f2a621bd18f1e814e4
Clicking the CHECK button will open the bytecode panel if the program
assembles successfully, displaying the assembled bytecode.
Adjust scale factors used for scroll input2025-07-08T05:49:45ZBen Bridleben@derelict.engineering2025-07-08T05:49:45Zurn:sha1:ba13eb2771cbab72a9de8e834536cb957aff38ad