08:46:37.125 [err] [fps] 4.0 (12 frames in 3.0s)
08:46:40.225 [err] [fps] 1.0 (3 frames in 3.1s)
08:46:41.224 FIRM | * ASSERTION FAILED: ASSERTN
08:46:41.443 [err] DEBUG post-reset: halted=0 stopped=1 R13=0x20002170 R15=0x080001b4 thumb=1
08:46:42.123 [err] clktree_recalc_output_freq: Clock PCLK1 output frequency (32000000 Hz) exceeds max frequency (30000000 Hz).
found an assertion just by clicking up/down. doesn't seem too stable.
cpfleming 1 hours ago [-]
Yeah that happens when trying to go up into the timeline.
donohoe 34 minutes ago [-]
Any way to load a local watch-face? Am hoping there is and I didn't see it. This would be very helpful for testing.
mmmlinux 2 hours ago [-]
Should I be getting more than .2 FPS?
davsti4 2 hours ago [-]
I'm not even getting that - its stuck at:
10:26:18.027 Downloaded SPI flash: 16777216 bytes
10:26:18.027 [config] icount: off
10:26:18.028 [status] Loading QEMU WASM module (17MB)...
hemmert 39 minutes ago [-]
Pretty impressive!
KetoManx64 4 hours ago [-]
I'm blow away at what Devs are able to do within a browser nowadays.
bossyTeacher 2 hours ago [-]
More that browsers have gotten sprouted downwards and obtained all sorts of low level access than older browsers didn't use to have. I believe this is partially why tools that were meant to just render markup have gotten so complex to build that a small team of devs is not enough to build a modern browser anymore. And by that I mean from scratch, not just piggybacking on Chromium or Gecko.
idle_zealot 29 minutes ago [-]
> I believe this is partially why tools that were meant to just render markup have gotten so complex to build that a small team of devs is not enough to build a modern browser anymore.
Isn't it basically the opposite? The hard parts of the browser are layout, styling, and multimedia stuff that goes into rendering markup compliantly. Then there's the infinite sink of optimization work for a JS engine, the high-level scripting language for that markup. The low level access that something like this emulator use is comparatively easy; a WASM runtime and Canvas blitting pixels from some shared buffer.
Or am I mistaken that a WASM engine is much easier to build than a performant JS engine?
zb3 2 hours ago [-]
Probably could be made faster by:
- using native exception handling
- getting rid of asyncify (but it would require JSPI)
found an assertion just by clicking up/down. doesn't seem too stable.
Isn't it basically the opposite? The hard parts of the browser are layout, styling, and multimedia stuff that goes into rendering markup compliantly. Then there's the infinite sink of optimization work for a JS engine, the high-level scripting language for that markup. The low level access that something like this emulator use is comparatively easy; a WASM runtime and Canvas blitting pixels from some shared buffer.
Or am I mistaken that a WASM engine is much easier to build than a performant JS engine?
- using native exception handling
- getting rid of asyncify (but it would require JSPI)
See my experiments with TempleOS here: https://zb3.me/qemu-wasm-test/