Belongs in the halls of honour alongside all the cursed Aliexpress adapters.

We did a legit evaluation matrix against all the other major options and even just past 1.0, it beat out Go and everything else we could throw at it for a mobile library.

All of this gives you the beautiful amber (or green!) glow and the crisp font of a VT420.

What I find amazing is how the video hardware of the VT420 seems to be able to decode this messy font situation without any real stress!

The worldwide terminal loads approximately ~400 characters into RAM, in both 80 and 132-column versions for whatever sizes are active. These get reshuffled into the various NRC and other language/technical character sets.

But not quite enough! Instead, the 48-line custom font of screen 2 gets unceremoniously shoved into video RAM along with the page memory. 10x16 and 6x16 fonts get dedicated areas of video RAM, but the other custom font sizes are interleaved between the currently-loaded smaller on-screen font.

The fonts (built-in and custom-downloaded ones) are interesting as well. There's _almost_ enough RAM to store them all in a single 0x8000 block of RAM that gets mapped over top of SRAM.

I believe there are 108 "live" page-data rows in VRAM + 9 paged into unused space + 27 rows in SRAM, give or take a bit. Each row has 72 chars of 5-bit character + 3-bit attribute data, plus another 60 chars of the same, and finally 132 spaces of additional 2-bit data.

There isn't enough RAM to hold every single one of the 144 lines of page data in Video RAM. Instead, the VT420 "pages" some of it out to an unused portion of the row memory and SRAM as you scroll. There's 9 lines stored in the middle of each text row, and the rest of the lines get paged out to SRAM

I started working on a visualization of the VT420's Video RAM for anyone interested in how it works. The way that it packs data into 64kB is fascinating. _Most_ of Video RAM is fonts or line buffers, but it's not straightforward.

I've only heard a few things about Salsa but I would love to know more about their experience with it.

Most uses come down to env initialization, libc or C FFI calls for setup, registration via functions, or collection of function pointers, at least the last time I looked.

I need to see if any new patterns showed up in the new dependent crates!

There are a lot of cool macro crates that incorporate it internally as a way to perform function registration -- napi is one IIRC.

I looked through the dependent crate list and now I'm terrified about making any changes to the crate. I think ctor was recently picked up as a dep in a few bigG crates

Disappointed there was no spoiler option for changing the language grammar to Go-style types.

The trick is that it has just enough proc macro to delegate to a standard macro where the heavy lifting is done.

The ctor name is basically stolen from the ELF section it generates.

That's my crate! And despite that, I really hope one day the Rust core team subsumes it into a proper Rust compiler feature.

This is my crate. :) The proc macro is entirely hand coded, no syn, so it runs in almost no time at all.

YouTube video by Paleotechnica What's that other port for on the JetKVM?

Short video this month: building a little JetKVM accessory to turn a computer on and off! www.youtube.com/watch?v=32uR...

I did this on rust-ctor for a bit, but reverted to a stub proc macro that delegates to a real macro after a while. I think it's a worthwhile idea but the lack of a "cargo gen" command is what kills it IMO.

I suspect I'll find a use for this. Nice crate!

I think this VT420 emulator might actually be going somewhere.

Sooooo long story short it was actually a bug in my 8051 emulator

There's a point in every emulator's life where you've got enough emulated that you can actually start to see the whole thing working together. Say hello to Blaze, a VT420 emulator written in Rust!

Ah! I misunderstood. Totally makes sense.

FWIW I think it would be awesome if rustdocs _could_ generate a stable JSON output format for other shenanigans, however. :)

Isn't it just diagnostics though, not the actual rustdocs? IIRC there is at least one project out there that does codegen this way, but it slipped my mind, hah

Good guess! You're right that it's a bit problem. It's somewhere in my emulator but I don't know for sure. I suspect there's something really weird about how bits are allocated to chars onscreen.

That's an ... interesting failure mode.

The only syntax thing I dislike is shift operators alongside 'as' - gets kinda bracket heavy - but I grew to love the turbofish.

Always