Japan tried to build an operating system for the entire world, then the US government intervened

It was an ambitious undertaking; he wanted a vertically integrated computing architecture that Japan could build its entire digital infrastructure on, from the microcontroller in a washing machine to the workstation on a desk to the telecom switch in a central office. The project had five sub-architectures: ITRON for embedded real-time systems, BTRON for personal computers, CTRON for mainframes and telecom switching, MTRON for cross-system coordination, and STRON, a hardware implementation of the real-time kernel. The project designed its own CPU architecture, the TRON VLSI CPU, which Hitachi manufactured as the Gmicro/200 series. Hitachi actually produced and sold it, and it ended up powering some Japanese workstations and embedded systems throughout the late 1980s. Sakamura's team also drew up its own TRON keyboard layout, designed for efficient Japanese text input alongside programming symbols, and a real-time peripheral bus called micro-BTRON, based on IEEE 802.5 and intended as an alternative to MIDI for connecting "electronic stationery" peripherals, though that bus never shipped in a commercial product. The idea was that every layer, from silicon to user interface, would be designed together, with no compatibility debt to existing platforms. The character encoding system, TRON Code, was arguably the most ambitious part. It supported multi-plane character switching via 0xFE escape codes, with 31 defined planes of 48,400 characters each, giving a theoretical capacity of 1,500,400 characters. By 1999, B-right/V R2 shipped with roughly 130,000 characters across 14 defined planes, covering JIS levels 1 and 2, Chinese GB 2312, Korean KS C 5601, Unicode's non-CJK range, and the Mojikyo collection of rare historical characters, and users could register new characters for free through the TRON Character Resource Center. To put that in perspective, Unicode 1.0 in 1991 defined 20,902 unified CJK ideographs, and TRON's CJK coverage exceeded Unicode's for well over a decade. A large part of that count came from Mojikyo, though, which separately encodes variant glyphs that Unicode unifies into single code points. You can see the ambition from the very beginning, as the 1996 demo release includes a character-code viewer that lists its planes side by side: Japanese basic, Japanese supplementary, Chinese GB, Korean KSC, and 6-dot Braille. Braille is there as a first-class plane rather than an accessibility add-on bolted on later, and Unicode didn't encode Braille patterns at all until version 3.0 in 1999. For its time TRON Code was the best answer anyone had to a problem the rest of the industry was years from solving. The project was backed by an actual organization: the TRON Association, established in 1986. Its members included Hitachi, Mitsubishi, Fujitsu, NEC, Matsushita, and Toshiba... basically every major Japanese electronics company of the era. On top of those domestic companies, foreign companies could join too, and several did. TRON was royalty-free and its specifications were open, which was a deliberate choice that would later allow ITRON to spread. The Japanese government, through MITI, supported the project as a national technology strategy, giving it the kind of institutional backing that most operating system projects could only dream of. On top of all this, BTRON proposed something radical for desktops. BTRON's desktop was decades ahead of where computing actually went The file and the application were implementation details BTRON's core idea was that the user-visible primitive on a desktop computer shouldn't be a file or the application, but the typed document part. In other words, a block of content with a stable identity and a declared type. Parts can contain other parts, and the same mechanisms that embed a figure in a report can also embed a report in a workspace, meaning that there was no special case for a top-level file. This model could be found across the interface as well, and you can browse a container in 1B/V3 and see each entry carries its type in parentheses after the name. For example, a document called 中国・韓国料理ガイド（図形）, meaning "Chinese and Korean Cuisine Guide (Graphics)", describes this file as an image. In comparison, DOS would have given you an extension. Parts were connected by typed links, stored in a system-managed link store rather than fragile string paths. Links survived renames, edits, and reorganizations, and applications weren't owners of files but handlers for part types. According to the BTRON3 specification, the first two halfwords of an application ID are the data type it applies to, and only the third distinguishes rival handlers for the same type. When a document contained writing, a table, and a figure, opening those parts made the system launch each one's registered handler to draw its own content inside the parent document's window. If no handler exists, or the handler fails to draw, the system strikes a diagonal line through the region where the content should have been. BTRON also used a file system model called real-body/pseudo-body, which replaced the tree-structured directory hierarchy with an arbitrary directed graph. Files can exist in multiple locations without duplication, linked by the system rather than by symlinks or shortcuts, and the dictionary that powers Japanese text input is addressed the same way a cooking guide would be. Here, the TRON Application Databus format carries structured data between applications using a chunked segment structure with a common header, so a spreadsheet cell and a paragraph of text could be composed into the same document without the user ever having to think about file formats. Applications can skip data types they don't support, making interoperability a core aspect of the system. Arguably, this is the same concept that tools like Roam, Logseq, and Obsidian have been rediscovering over the last decade. But BTRON proposed it as the fundamental OS abstraction in the mid-1980s, paired with a custom CPU and a real-time microkernel underneath. It's not that BTRON's implementation would feel smooth by modern standards, because the hardware it ran on was too slow for that, but the architecture was doing something conceptually different from anything that shipped commercially in the West at the time. 1B/V3 comes with a number of sample documents that show exactly this concept. One demonstration is a Microscript figure, which is a drawing canvas holding a green ball and a sloped surface, each a named object, with a text section dubbed SCRIPT in the same space. You can open the script and see "DEFINE 半径（ボール．W／2）", defining a radius as half the ball's width, then "SET 新Y ボール．Y+半径+速度Y／4" which advances the ball's position on each step. The script addresses the figure's contents as "ボール．X" and "斜面．W", meaning object and property, and the entire file is a single document rather than a program loading data files. Sure, a bouncing-ball simulation is a small thing to build, but the point is that it's a typed part inside the document instead of a dedicated application that owns it.