OSDev.org

iansjack wrote: ↑Wed Jul 30, 2025 2:57 am

kerravon wrote: ↑Wed Jul 30, 2025 2:34 am It's not just the initial release price that matters. It's what happens after that. The price came down.

Yes - the Amiga 500's price went down to £399. The same price as the Amstrad, but you also had to buy a monitor for the Amiga - still more expensive. And still lacking software compared to the PC.

No it wasn't. I bought an Amiga 500 myself. Not as soon as it hit the shelves, but when the price came down.

We've already covered that mistruth.

No we haven't. You only provided the price that the Amiga 500 was introduced as.

The Amiga was always more expensive than the cheapest PC compatible.

You know worldwide prices, do you? Around 1987 I bought a Commodore PC 5 with 20 MB hard disk and monochrome monitor for AUD$2000. About a year later I bought an Amiga 500. I don't remember the price, but as far as I can remember it was much cheaper (otherwise I wouldn't have bought it). I likely paid around AUD$500. I bought an Amiga 500HD I think it was called (just the hard disk) sometime later (I think), and that was probably another AUD$500. I used a TV instead of a monitor as far as I can remember. I don't remember Amstrad PCs even being available.

This is not America - you can't just make up the numbers.

You're the one claiming to know worldwide prices for two different machines at all times that they were available for sale, not me.

THIS IS THE PROBLEM I AM TRYING TO SOLVE!!!

And I have been trying to solve it for 30 years with PDOS.

I thought we were talking about why the Amiga didn't sell as well as the PC.

Not really. I already know that - the software wasn't available.

A bit late now to solve the problem when PCs are so cheap and any Amigas you can buy are so expensive. We have to work with the world the way it is, not how we wish it had turned out.

I'm not trying to get Amigas to outsell PCs in 2025. I'm trying to understand what software (or culture) was absent in the 1980s that prevented people from seamlessly moving to an alternative CPU, and then trying to make that software available (or make the appropriate cultural changes).

The big problem with the Amiga is that you were tying yourself in to proprietary hardware.

What difference does that make? If the owner of the proprietary hardware tries to screw you price-wise, you just seamlessly switch again to different hardware.

The joy of the Amiga was its novel operating system;

And you can choose to use that if you wish. But you risk tying yourself down to the Amiga.

why would I want to replace that with some MS-DOS or Windows imitation?

Not replace, so much as - run alongside.

And the reason? So that your software suite can be transferred back to a PC (or some other machine - like the Atari) at the drop of a hat. That's (one of) my goal.

Well, I did provide you the reduced price of the Amiga (£399 as opposed to the original £499). And it’s true that I only provided UK prices rather than telling you the relative costs in Fiji. But even if you disregard the original cost of a monitor (a TV was fine for games, but in a business setting?) the fact remains that the Amiga was not cheaper than the cheapest PC clones. Those Amigas, such as the 2000 or the 4000 that were aimed at the same market as PCs were considerably more expensive.

You are 100% correct about what happens if the owner of proprietary hardware screws you - you change hardware. That’s what people did; they chose the PC rather than the Amiga.

All of this is far less important nowadays as the growth of open source means that I can get quality software maximized to run on my choice of hardware rather than relying on some crippled version designed to run on any machine. Otherwise I just virtualize another OS if the vendor only supports a particular OS. I actually use that most proprietary of hardware - a M4 Mac for my day-to-day work with virtualized Linux for some specialized applications.

Thank goodness for open-source software.

eekee wrote: ↑Wed Jul 30, 2025 9:40 am I wonder how long complex CJK scripts would last, post-collapse? They are as they are due to an excessively powerful scribe class. Korean in particular was badly fouled up by such a scribe class after a king introduced a beautifull simple and practical alphabet.

For the record - did you mean "beautiful" or "beautifully"? I was about to correct the quote to the latter, which I thought was grammatically correct. But not necessarily.

BTW - sorry for the delay - I did a chaotic move from Australia to the Philippines.

(And an additional delay because my new internet connection is being flagged by spamhaus so I can't post anything normally)

Anyway - thanks for the information about the "scribe class". Didn't know about that.

ASCII itself was designed for combining characters, but it never caught on because it didn't match peoples' expectations. People like capitals with accents to be lower-height. With or without that, the combiners would have to be put at different heights for upper and lower case. Huh... now I think about it, all those features could be implemented at the display end with ASCII as an internal representation. Perhaps use ^H to signify combining, a role it currently has in troff output and dumb terminal input anyway.

And thanks for this information about combining - it may come in useful when we get to Vietnamese. I'll work with Dat on options.

kerravon wrote: ↑Sat Oct 18, 2025 7:01 amAnd thanks for this information about combining - it may come in useful when we get to Vietnamese. I'll work with Dat on options.

Unicode offers both precomposed and combining characters for encoding Vietnamese text (as well as ways to convert between the two, if necessary).

Octocontrabass wrote: ↑Wed Jul 30, 2025 8:32 pm

kerravon wrote: ↑Wed Jul 30, 2025 1:14 amIf you can't write lowercase latin you presumably can't write katakana either. So this is another example where katakana folding into uppercase latin is required.

Where are you getting these ridiculous assumptions? All Japanese versions of MS-DOS allow Latin and katakana in file names. File names are case-insensitive, which means lowercase Latin letters are automatically replaced with uppercase Latin letters, exactly the same as every other version of MS-DOS. There is no concept of uppercase or lowercase for katakana, so the conversion to uppercase has no effect on them.

Spamhaus chased me away from this board for many months, but I tested it out and I'm allowed back in now.

So anyway I have a new proposal. A new C function - isequiv() - is equivalent.

kerravon wrote: ↑Wed Jul 30, 2025 1:14 amWhat I don't want is to have to change keyboards.

Why would you have to change keyboards? For that matter, which keyboards would you be changing?

What I meant was - switching layouts. Switching between "data entry using katakana" and "data entry using English". It's the same keyboard that is used.

Anyway, my proposal is that C programmers should code:

in_key = getch();
if (toequiv(in_key) == toequiv('x')) ...


This way a katakana/Greek/whatever character can be made nominally the same as an ASCII character.

Without disturbing existing toupper/tolower logic.

kerravon wrote: ↑Sat Mar 28, 2026 8:36 amSo anyway I have a new proposal. A new C function - isequiv() - is equivalent.

Equivalent in what context?

kerravon wrote: ↑Sat Mar 28, 2026 8:36 amWhat I meant was - switching layouts. Switching between "data entry using katakana" and "data entry using English". It's the same keyboard that is used.

So switching between "data entry using lowercase Latin" and "data entry using uppercase Latin" is good, but switching between "data entry using lowercase Latin" and "data entry using katakana" is bad? What's the difference?

Octocontrabass wrote: ↑Sat Mar 28, 2026 10:49 am

kerravon wrote: ↑Sat Mar 28, 2026 8:36 amSo anyway I have a new proposal. A new C function - isequiv() - is equivalent.

Equivalent in what context?

Equivalent in that if an application prints in English "press c to continue", the user only needs to enter the EQUIVALENT of the letter c, which could be let's say the 3rd katakana character. That way the user needs to memorize that when they see that English gobbledygook with a "c" they press katakana-3 and they get to continue. No need to switch to Latin layout and then switch back to Katakana.

kerravon wrote: ↑Sat Mar 28, 2026 8:36 amWhat I meant was - switching layouts. Switching between "data entry using katakana" and "data entry using English". It's the same keyboard that is used.

So switching between "data entry using lowercase Latin" and "data entry using uppercase Latin" is good,

For a uppercase letter, pressing shift does not interfere with touch-typing, for Latin input. Doing lots of uppercase does prevent touch-typing unless you switch caps-lock on. And that is indeed intrusive - but again - not normal. Normal English typing can be touch-typed.

but switching between "data entry using lowercase Latin" and "data entry using katakana" is bad? What's the difference?

Big difference. As a (theoretical) Japanese user, I have no reason to learn or use Latin. I can touch-type in Katakana perfectly nicely thankyou. I am aware that "lazy" English programmers hardcode things like 'c' (as the character to press to continue) in their code instead of properly internationalizing things. I can live with that, especially given that the code in question is usually "free", but at least use the C90+ function isequiv() so that I can type a Katakana character instead of having to care about Latin. The Romans are extinct ffs. Why do I care about Latin?

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amEquivalent in that if an application prints in English "press c to continue", the user only needs to enter the EQUIVALENT of the letter c, which could be let's say the 3rd katakana character.

In other words, you want some way to identify which key the user has pressed, and you don't care about text at all. So why are you trying to shoehorn this into a text API instead of using a keyboard API?

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amThat way the user needs to memorize that when they see that English gobbledygook with a "c" they press katakana-3 and they get to continue. No need to switch to Latin layout and then switch back to Katakana.

There's no need to memorize anything since Japanese keyboards (almost) always include labels for Latin letters. There's also no need to switch keyboard layouts if you use an API designed to identify which key the user has pressed instead of an API designed to identify which letter the user has pressed.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amAs a (theoretical) Japanese user, I have no reason to learn or use Latin.

As a (theoretical) Japanese user, I already know at least the Latin letters used for English, same as everyone else in Japan.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amI can touch-type in Katakana perfectly nicely thankyou.

I can't easily find statistics on it, but at least in my limited experience, a Japanese user would most likely type using Latin letters and rely on the computer to convert the text to kana and kanji.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amThe Romans are extinct ffs. Why do I care about Latin?

You're still using a version of their alphabet.

Octocontrabass wrote: ↑Sat Mar 28, 2026 11:26 pm

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amEquivalent in that if an application prints in English "press c to continue", the user only needs to enter the EQUIVALENT of the letter c, which could be let's say the 3rd katakana character.

In other words, you want some way to identify which key the user has pressed, and you don't care about text at all. So why are you trying to shoehorn this into a text API instead of using a keyboard API?

The programmer doesn't know what the equivalent of "c" is, in katakana or any other language. That's up to the locale for them to find something suitable.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amThat way the user needs to memorize that when they see that English gobbledygook with a "c" they press katakana-3 and they get to continue. No need to switch to Latin layout and then switch back to Katakana.

There's no need to memorize anything since Japanese keyboards (almost) always include labels for Latin letters.

I don't expect it to necessarily be a "c" they press. It may be a combination of two characters - that doesn't disrupt their touch-typing. Likely on a "moon" keyboard. Translate this:

https://ja.wikipedia.org/wiki/%E3%81%8B ... 5%E5%8A%9B

and then search for "263" or "moon". Created on 2chan.

There's also no need to switch keyboard layouts if you use an API designed to identify which key the user has pressed instead of an API designed to identify which letter the user has pressed.

C90 only deals with letters. It may have been constructed on a Japanese-equivalent VT100 terminal.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amAs a (theoretical) Japanese user, I have no reason to learn or use Latin.

As a (theoretical) Japanese user, I already know at least the Latin letters used for English, same as everyone else in Japan.

They should be in a position to stop learning English. If all they want to do is communicate in Japanese.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amI can touch-type in Katakana perfectly nicely thankyou.

I can't easily find statistics on it, but at least in my limited experience, a Japanese user would most likely type using Latin letters and rely on the computer to convert the text to kana and kanji.

Oh sure - sorry - unstated assumption. Are you aware that there are "Japanese reformers" who wish to retire kanji - presumably in favor of katakana? Well, those are the only Japanese I care about. Ones who presumably want to be able to touch-type as easily as an English-speaker. So they can stop learning kanji at the same time as they stop learning English. BTW, the same thing applies to Greek etc, but the Greeks don't need to go through the reformation.

kerravon wrote: ↑Sat Mar 28, 2026 11:06 amThe Romans are extinct ffs. Why do I care about Latin?

You're still using a version of their alphabet.

Not as a Japanese, I'm not. Or shouldn't have to.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amLikely on a "moon" keyboard.

You're going to somehow convince your hypothetical Japanese user to switch to a new keyboard layout while you yourself continue to use the keyboard layout you already know? (Or are you assuming your Japanese user will be somebody who has never used a keyboard before?)

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amC90 only deals with letters.

Correct. Since you're already inventing new APIs that aren't part of C90, this is a perfect opportunity to invent a new API for detecting keys by their location rather than by which letters they type.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amThey should be in a position to stop learning English.

I think they already tried that once.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amAre you aware that there are "Japanese reformers" who wish to retire kanji - presumably in favor of katakana?

No, and I can't imagine why anyone would want to lose access to millennia of cultural history.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amWell, those are the only Japanese I care about.

You're already limited to an extreme minority of potential developers to help you with your OS. Now you also want to be limited to an extreme minority of potential users?

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amOnes who presumably want to be able to touch-type as easily as an English-speaker.

Why do you assume they can't already do that?

Octocontrabass wrote: ↑Sun Mar 29, 2026 8:00 pm

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amLikely on a "moon" keyboard.

You're going to somehow convince your hypothetical Japanese user to switch to a new keyboard layout while you yourself continue to use the keyboard layout you already know? (Or are you assuming your Japanese user will be somebody who has never used a keyboard before?)

Ask the 2chan people - they created it, not me. I assume it's for either new users (children), or die-hard reformers.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amC90 only deals with letters.

Correct. Since you're already inventing new APIs that aren't part of C90, this is a perfect opportunity to invent a new API for detecting keys by their location rather than by which letters they type.

I don't think that is possible. It could be a remote terminal where the composed katakana comes through.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amThey should be in a position to stop learning English.

I think they already tried that once.

I'm not even suggesting they do that. They should be ABLE to do that. And it's not about just the Japanese. The software (C90+) shouldn't have an English mandate. Even if the programmers are all English-speaking. If I'm Greek I shouldn't need to learn English either.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amAre you aware that there are "Japanese reformers" who wish to retire kanji - presumably in favor of katakana?

No, and I can't imagine why anyone would want to lose access to millennia of cultural history.

Because touch-typing in the present is more important.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amWell, those are the only Japanese I care about.

You're already limited to an extreme minority of potential developers to help you with your OS. Now you also want to be limited to an extreme minority of potential users?

You'll have to speak to my marketing department about how well the Japanese reform movement is going. That's a non-technical issue.

kerravon wrote: ↑Sun Mar 29, 2026 2:17 amOnes who presumably want to be able to touch-type as easily as an English-speaker.

Why do you assume they can't already do that?

They can't. Not Kanji, anyway. My understanding is that they type the katakana pronunciation of a word, and then select the kanji from a list. Same as the Chinese and presumably Korean.

And to solve this problem of inability to touch-type, plus a ridiculous number of characters, my plan is to get behind a CJK reform movement that will get them to use their respective alphabets (they already have alphabets - all 3). That will get them to a normal SBCS. Sometimes the proper technical solution is cultural reform, not 32-bit chars.

And then they will be in the same position as the Greeks.

And then, like the Greeks, the next goal is to never have to switch to English layout, even for programs written with English text. It might help if they know a little English though, but the important thing is to not interfere with touch-typing Greek or whatever. And the correct technical solution here appears to be a toequiv(x) or perhaps isequiv(x, y).

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmI assume it's for either new users (children), or die-hard reformers.

That's a strange assumption to make, considering that alternatives to the QWERTY layout for English text are primarily used by experienced typists who want to type even faster than they already do, not new users or reformers.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmIt could be a remote terminal where the composed katakana comes through.

If it's a remote terminal, you don't know the keyboard layout, so you don't know which key on the user's keyboard corresponds to any particular Latin letter.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmThey should be ABLE to do that.

What makes you think they aren't? Do you really think they learn English just because of computers?

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmBecause touch-typing in the present is more important.

It really isn't.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmThey can't. Not Kanji, anyway. My understanding is that they type the katakana pronunciation of a word, and then select the kanji from a list. Same as the Chinese and presumably Korean.

The computer automatically selects the most likely kanji based on context and prior usage, and there are keyboard shortcuts to quickly replace the automatic selection with different options from the list in case the computer guesses wrong. I don't think it's nearly as bad as you're imagining.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmThat will get them to a normal SBCS.

And it'll have all the same interoperability problems as every other SBCS, and it'll be replaced by Unicode just like every other SBCS.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmSometimes the proper technical solution is cultural reform, not 32-bit chars.

Sometimes the proper technical solution is admitting that C90 wasn't designed to meet the needs of our modern interconnected world.

Octocontrabass wrote: ↑Mon Mar 30, 2026 11:22 am

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmI assume it's for either new users (children), or die-hard reformers.

That's a strange assumption to make, considering that alternatives to the QWERTY layout for English text are primarily used by experienced typists who want to type even faster than they already do, not new users or reformers.

I've been chatting to Gemini, and it told me the reason why they created Moon keyboard. I've forgotten the answer, but I think it was to solve a fundamental problem.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmIt could be a remote terminal where the composed katakana comes through.

If it's a remote terminal, you don't know the keyboard layout, so you don't know which key on the user's keyboard corresponds to any particular Latin letter.

Yes I do. That will be DEFINED by the locale setting. This arbitrary Katakana character is the equivalent of the letter 'c' if a programmer is requesting a 'c'.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmThey should be ABLE to do that.

What makes you think they aren't? Do you really think they learn English just because of computers?

They should be ABLE to STOP learning English if they want.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmThat will get them to a normal SBCS.

And it'll have all the same interoperability problems as every other SBCS, and it'll be replaced by Unicode just like every other SBCS.

I am disputing the replacement of SBCS. That is the technically efficient way to do things.

kerravon wrote: ↑Sun Mar 29, 2026 9:08 pmSometimes the proper technical solution is cultural reform, not 32-bit chars.

Sometimes the proper technical solution is admitting that C90 wasn't designed to meet the needs of our modern interconnected world.

I'm disputing that "modern interconnected world". I don't want to be dependent on that infrastructure. I want two Japanese people to be able to communicate with each other with no connection - not even a modem. Transferring Fidonet packets via floppy disk or some other arbitrary mechanism like USB stick or Bluetooth. Think Mad Max Beyond Thunderdome.

But anyway, there has been a change of plan after a long talk with Gemini. It started off with me clarifying Japanese, then went through other languages, and ended with reforming English. I have a 4 year old daughter and I'm thinking of trying to teach her "PDOS English" as it is apparently known. There is a summary below. But people with a "reasonable" (TM) Greek alternate character set would still need an isequiv(x,y). But others should be switching to modified-Latin as part of cultural reform. It is interesting that this is where PDOS development led me.

2. English (Phonetic PDOS)
• Vowel Format: `[Vowel][Shape][Stress]`

• Shape 0: Short/Neutral | Shape 6: Long

• Stress 2: Primary | Stress 1: Secondary | Stress 0: Unstressed

• Word Pitch: Every word ends with a terminal pitch digit (1=Falling, 2=Rising).

Examples:

• Cat: `ka02t1` (Short a, Primary stress, Falling finish)

• Cake: `ka62k1` (Long a, Primary stress)

• Thin: `t9i02n1` (Modified T, Short i, Primary stress)

• Nature: `ne62t9o7r01`

---

3. Japanese (Romaji-Numerical)
Japanese is already mostly phonetic; the numbers here primarily handle Pitch Accent and Long Vowels.

• Standard: `ha0shi1` (Bridge - Low to High)

• Standard: `ha1shi0` (Chopsticks - High to Low)

• Long Vowel: `to60kyo60` (Tokyo - Shape 6 indicates the long 'o')

---

4. Vietnamese (Quốc Ngữ 7-Bit)
Vietnamese uses numbers to replace all diacritics, ensuring 100% ASCII compatibility without losing tone or vowel quality.

• Vowel Shapes: `a8` (ă), `a9` (â), `e9` (ê), `o9` (ô), `o7` (ơ), `u7` (ư).

• Tones: 1-6 (Ngang, Huyền, Hỏi, Ngã, Sắc, Nặng).

• Example: `Phở` -> `fo73` | `Tiếng Việt` -> `ti9e9ng5 vi9e9t6`

---

5. Thai (Latin-Numerical Protocol)
Thai requires the "Double-Bolt" for vowel length and tone.

• Tone Scale: 0 (Mid), 1 (Low), 2 (Falling), 3 (High), 4 (Rising).

• Example: `m-a-0-0` (Come - Mid tone, short) vs `m-a-6-0` (Dog - Mid tone, long).

---

6. German (Hard-Logic Phonetics)
German's "Umlauts" are treated as Shape Modifiers.

• Umlauts: `a8` (ä), `o8` (ö), `u8` (ü).

• Stress: Germans have rigid word stress, usually on the first root.

• Example: `Äpfel` -> `a82p-fe0l` | `Deutsch` -> `do02yt9sh0`

---

7. Pinyin (Confirmation)
As noted, Pinyin is already a high-functioning numerical-phonetic system. PDOS adopts it as-is:

• Example: `ma1` (Mother), `ma2` (Hemp), `ma3` (Horse), `ma4` (Scold).

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI've been chatting to Gemini, and it told me the reason why they created Moon keyboard. I've forgotten the answer, but I think it was to solve a fundamental problem.

If you don't remember, it must not be important, and if it's not important, there's no reason to force people to learn a new keyboard layout.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmYes I do. That will be DEFINED by the locale setting.

How does your locale setting have any control over the keyboard layout of the remote terminal?

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmThey should be ABLE to STOP learning English if they want.

I already told you, they are able to stop. If they wanted to, they could replace all of their computers with ones that support only Japanese text. So why don't they want to do that?

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI am disputing the replacement of SBCS. That is the technically efficient way to do things.

It's only efficient if you ignore the part where users will need to waste time and effort keeping track of character sets.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI'm disputing that "modern interconnected world". I don't want to be dependent on that infrastructure.

You are writing software for a computer that wouldn't exist without that infrastructure. If the computer breaks, you won't be able to repair it without that infrastructure.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI want two Japanese people to be able to communicate with each other with no connection - not even a modem. Transferring Fidonet packets via floppy disk or some other arbitrary mechanism like USB stick or Bluetooth. Think Mad Max Beyond Thunderdome.

Why wouldn't they use pen and paper?

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI have a 4 year old daughter and I'm thinking of trying to teach her "PDOS English" as it is apparently known.

...Good luck with that...

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmThere is a summary below.

It's a phonetic system that completely loses any meaning conveyed by specific orthographic choices. That can be useful, but it's not a replacement for existing written languages.

Octocontrabass wrote: ↑Tue Mar 31, 2026 6:04 pm

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI've been chatting to Gemini, and it told me the reason why they created Moon keyboard. I've forgotten the answer, but I think it was to solve a fundamental problem.

If you don't remember, it must not be important,

That doesn't follow. It can just mean that I'm not good at remembering the intricacies of Japanese keyboards.

and if it's not important, there's no reason to force people to learn a new keyboard layout.

Tell that to the 2chan people. But regardless, as I said, I've moved to romaji.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmYes I do. That will be DEFINED by the locale setting.

How does your locale setting have any control over the keyboard layout of the remote terminal?

That's up to the PDOS infrastructure. Whether that is running a command, or recompiling the PDOS kernel.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI am disputing the replacement of SBCS. That is the technically efficient way to do things.

It's only efficient if you ignore the part where users will need to waste time and effort keeping track of character sets.

The Japanese user - even if using katakana - only needs to keep track of a single SBCS.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI'm disputing that "modern interconnected world". I don't want to be dependent on that infrastructure.

You are writing software for a computer that wouldn't exist without that infrastructure. If the computer breaks, you won't be able to repair it without that infrastructure.

I am writing for a computer that could be built in 1990 - before the internet fad thing.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI want two Japanese people to be able to communicate with each other with no connection - not even a modem. Transferring Fidonet packets via floppy disk or some other arbitrary mechanism like USB stick or Bluetooth. Think Mad Max Beyond Thunderdome.

Why wouldn't they use pen and paper?

That's exactly what I'm competing with. I can design a computer system that is superior to using a pen and paper. I'm not attempting to compete with the latest and greatest GUI from Microsoft/Linas. So anyway, try transferring a Fidonet packet using pen and paper.

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmI have a 4 year old daughter and I'm thinking of trying to teach her "PDOS English" as it is apparently known.

...Good luck with that...

It's being called PEPS now (Gemini made that up), which is "Phonetic English Proper Spelling".

kerravon wrote: ↑Mon Mar 30, 2026 11:46 pmThere is a summary below.

It's a phonetic system that completely loses any meaning conveyed by specific orthographic choices. That can be useful, but it's not a replacement for existing written languages.

According to Gemini, you're worried about "losing meaning", but I'm worried about "losing time" (time taken to get a 4 year old literate).

P.S. I am now getting:

Your IP 119.92.51.37 has been blocked because it is blacklisted. For details please see https://check.spamhaus.org/listed/?sear ... 9.92.51.37.

so I will probably be abandoning the board again soon.