feat: add optional CP437G code page for VGA text mode - #31
Closed
asmello wants to merge 3 commits into
Closed
Conversation
Adds a third feature tier so the crate scales down to no_std targets without an allocator. The existing no_std (alloc) tier from bonega#28 is preserved. - Cargo.toml: add an `alloc` feature gating the Cow-returning encode/decode API; `std` now implies `alloc`, so the default build is unchanged. - New allocation-free per-codepage primitives, available without `alloc`: - `encode_char(c: char) -> Option<u8>` - `decode_byte(b: u8) -> char` (complete) / `Option<char>` (incomplete) - gate the Cow API, decode helpers, and table-write paths behind `alloc` across lib.rs, encoder/decoder, and the codegen templates (regenerated code_pages match). - CI: the bare-metal job now also builds the no_std + alloc tier; the no-features build doubles as the no-allocator guard. - docs: document the three tiers; bump version to 1.5.0. BREAKING for no_std users of 1.4.0: `default-features = false` now selects the no-allocator tier. Add `features = ["alloc"]` to keep the full API.
Per maintainer review on bonega#30: the new no-allocator default-features tier is a breaking change for default-features = false users, so bump the major version. The default build is unaffected.
Adds CP437G behind an off-by-default `cp437g` feature, per the request in bonega#29. It is CP437 overlaid with the IBM-Graphics glyphs at the C0 control byte range (per unicode.org's IBMGRAPH.TXT), matching what the VGA BIOS glyph ROM renders for bytes 0x01-0x1F and 0x7F. Pairs with `encode_char`/`decode_byte` for driving a text buffer from a no_std kernel. - codegen: build the CP437G mapping by overlaying the glyphs onto CP437 - code_pages: gate the generated `cp437g` module behind the feature - tests: feature-gated round-trip and ASCII fast-path coverage - CI: exercise the feature via --all-features and a bare-metal build - docs: README section + CHANGELOG entry Glyphs that share a byte with an ASCII control (0x09 ○, 0x0A ◙, 0x0D ♪) are representable; the ASCII fast-path still encodes '\t'/'\n'/'\r' to those bytes, so callers intercept the source char if they need newline semantics.
bonega
added a commit
that referenced
this pull request
Jun 16, 2026
* feat: add optional CP437G code page for VGA text mode Adds CP437G behind an off-by-default `cp437g` feature, per the request in #29. It is CP437 overlaid with the IBM-Graphics glyphs at the C0 control byte range (per unicode.org's IBMGRAPH.TXT), matching what the VGA BIOS glyph ROM renders for bytes 0x01-0x1F and 0x7F. Pairs with `encode_char`/`decode_byte` for driving a text buffer from a no_std kernel. - codegen: build the CP437G mapping by overlaying the glyphs onto CP437 - code_pages: gate the generated `cp437g` module behind the feature - tests: feature-gated round-trip and ASCII fast-path coverage - CI: exercise the feature via --all-features and a bare-metal build - docs: README section + CHANGELOG entry Glyphs that share a byte with an ASCII control (0x09 ○, 0x0A ◙, 0x0D ♪) are representable; the ASCII fast-path still encodes '\t'/'\n'/'\r' to those bytes, so callers intercept the source char if they need newline semantics. * docs: move no_std section to the end of the README It had grown into a multi-tier feature table and code samples sitting in the middle of the Usage section, ahead of the basic examples. Move it to its own top-level section near the end and collapse the two Features bullets into one line that links to it. * release: 2.1.0 Minor release for the new optional cp437g code page (#31). Bumps version, finalizes the CHANGELOG entry, and updates README version references. * docs: clarify CP437G codegen comment The glyphs are transcribed from IBMGRAPH.TXT inline, not parsed from it, so say 'transcribed from' rather than 'per'. Also note that 0x00 is left as NUL deliberately (the VGA glyph ROM renders it blank). --------- Co-authored-by: André Sá de Mello <codasm@pm.me>
Owner
Contributor
Author
|
Perfect, thanks a lot. I meant to clean this up but haven't had a chance, glad to see you found a way around. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 2 of 2 addressing #29 — the optional CP437G code page.
What this does
Adds
CP437Gbehind an off-by-defaultcp437gcargo feature. It's CP437 overlaid with the IBM-Graphics glyphs at the C0 control byte range (0x01–0x1Fand0x7F), per unicode.org'sIBMGRAPH.TXT— i.e. what the VGA BIOS glyph ROM actually renders for those bytes (☺ ♥ ♪ → ⌂ …). Pairs naturally with theencode_char/decode_byteprimitives from #30 for driving a text buffer from ano_stdkernel.Notes
codegenby overlaying the glyphs onto CP437, and thecp437gmodule is#[cfg(feature = "cp437g")]-gated. Off by default, so no impact on existing builds.0x09○,0x0A◙,0x0D♪). yore's ASCII fast-path still encodes'\t'/'\n'/'\r'to those bytes, so a caller that needs newline semantics should intercept the sourcecharfirst. This is covered by tests and documented in the README.Testing
cargo test --all-features(unit + doctests, incl. CP437G round-trip and ASCII fast-path): passcargo clippy -- -D warningsacross the default, all-features, and reduced (--no-default-features [--features alloc|cp437g] --lib) sets: cleancargo build --no-default-features --features cp437g --lib --target thumbv7em-none-eabicd codegen && cargo runproduces no diff