Why is a newline converted to 0x9B instead of 0x0A?

Because that's genuinely how ATASCII represents end-of-line, Atari 8-bit computers use byte 0x9B (not the ASCII linefeed 0x0A) to mark the end of a line of text, so a faithful ASCII-to-ATASCII conversion has to remap it rather than passing 0x0A through unchanged.

Is ATASCII otherwise identical to ASCII?

For the printable range 32-126, yes, byte values match ASCII directly, this tool passes them through unchanged. The EOL byte is the one real, documented difference this tool implements; other control-code differences exist in the full ATASCII spec but aren't implemented here.

What happens to a control character that isn't a newline?

It's rejected. This converter deliberately only implements the printable range plus the one documented newline-to-0x9B behavior, rather than guessing at the rest of ATASCII's control-code layout.

How is this different from ASCII to Hex Converter?

For printable text with no newlines, the two tools produce identical output, since ATASCII matches ASCII byte-for-byte there. The difference only appears with newline characters: this tool maps them to ATASCII's real 0x9B EOL byte, while ASCII to Hex Converter encodes them as ASCII's own 0x0A.

ASCII to ATASCII Converter - Atari 8-Bit Character Set

Overview

Introduction

ATASCII, the character set Atari built into its 8-bit computers, is one of the more ASCII-friendly legacy encodings, matching ASCII byte-for-byte across the whole printable range, with one small but important exception around line endings.

This tool converts ASCII text to ATASCII hex byte values, implementing that one real behavioral difference, the 0x9B end-of-line byte, rather than treating ATASCII as a pure ASCII synonym.

What Is ASCII to ATASCII Converter?

A text-to-byte encoder for Atari 8-bit ATASCII, where printable characters 32-126 pass through with identical byte values to ASCII.

The one implemented divergence: ATASCII uses byte 0x9B as its end-of-line marker instead of ASCII's 0x0A (linefeed), so any newline in the input is remapped to 0x9B on the way out.

How ASCII to ATASCII Converter Works

The input is validated as strict 7-bit ASCII, then each character is checked: a newline character (\n) converts to the fixed ATASCII EOL byte 0x9B, while any character in the printable range 32-126 converts to its own code point as 2-digit hex.

Any other control character (not a newline, and not in the printable range) is rejected, since this converter deliberately implements only the one documented EOL behavioral difference rather than ATASCII's full control-code set.

When To Use ASCII to ATASCII Converter

Use it when preparing text for an Atari 8-bit program, emulator, or disk image that expects genuine ATASCII byte values, line endings included.

It's also useful for understanding exactly where ATASCII and ASCII diverge, since for most text they don't diverge at all.

Often used alongside ATASCII to ASCII Converter, ASCII to Hex Converter and Hex to ASCII Converter.

Features

Advantages

Implements the one real, well-documented ATASCII behavioral difference (the 0x9B EOL byte) precisely, rather than pretending ATASCII is identical to ASCII.
Passes the printable range through with zero unnecessary transformation, keeping the output easy to verify by eye.
Clear about scope: only the printable range plus newline handling, not a full ATASCII control-code implementation.

Limitations

Only remaps newline characters to 0x9B; other ASCII control characters (tab, carriage return, etc.) aren't mapped to any ATASCII equivalent and are rejected instead.
Doesn't implement ATASCII's other Atari-specific control codes (cursor movement, screen clear, and similar), which have no ASCII equivalent to map from in the first place.

Examples

Encoding printable text unchanged

Input

Hi!

Output

48 69 21

Printable ASCII characters pass straight through to identical ATASCII byte values.

Encoding a newline as the ATASCII EOL byte

Input

A
B

Output

41 9B 42

The newline between "A" and "B" becomes byte 0x9B, ATASCII's real end-of-line marker, instead of ASCII's 0x0A.

Best Practices & Notes

Best Practices

If your source text uses \r\n line endings, be aware only the \n character is treated as a newline here; a stray \r before it will be rejected as an unsupported control character.
Round-trip through ATASCII to ASCII Converter to confirm your line breaks survive the conversion correctly.

Developer Notes

Newline characters are special-cased to the literal byte 0x9B before the general printable-range check runs; every other control character (code point below 32, excluding \n) is rejected. atascii-to-ascii-converter imports the same ATASCII_EOL_BYTE constant so the EOL byte value can't drift between the two tools.

ASCII to ATASCII Converter Use Cases

Preparing ATASCII byte sequences for an Atari 8-bit program, BASIC listing, or disk image
Converting multi-line text so its line endings match real ATASCII EOL behavior instead of ASCII's
Demonstrating exactly where ATASCII and ASCII agree and where they genuinely diverge

Common Mistakes

Assuming ATASCII is byte-identical to ASCII everywhere; the EOL byte is a real, documented exception this tool implements deliberately.
Feeding in \r\n line endings expecting both characters to be handled; only \n is treated as the newline to remap, a lone \r is rejected.

Tips

If your output has no 0x9B bytes at all, that's expected for single-line input, since the EOL remapping only triggers on an actual newline character.
Compare against ASCII to Hex Converter's output for the same text; any difference you see is exactly the EOL byte remapping in action.

ASCII to ATASCII Converter