6 ms·

> The ITRON specs can be downloaded from the TRON website I had seen that, but many things (including many of the older stuff) seems to be missing. However, s

> The ITRON specs can be downloaded from the TRON website I had seen that, but many things (including many of the older stuff) seems to be missing. However, some stuff I had found elsewhere (not from TRON website), and I had been able to partially figure out from the Japanese documentation and had been able to write a program that can partially parse the TRON Application Databus format. However, many things I could not figure out very well. I had also found what seems to be some document of TRON instruction set (I have some interest in the instruction sets of some older computers, not only TRON), but is Japanese and also seems that some files are missing, anyways. So, I don't know its working anyways. (I also found some English documentation but it does not actually explain much, although there is a few minor explanation of them.) > CTRON appears to have been based on OSI-I see references to FTAM and MOTIS (the X.400 mail transport protocol) However, I think X.400 uses ASN.1, and ASN.1 does not have a TRON string data type (I had once also wanted to use this in something else (unrelated to X.400 mail and CTRON), so I used the octet string type instead). > I can’t find any references to actual specs for MTRON. I am wondering if it was ever actually specified, or if it was just vapourware That was my guess as well, but I don't know either. > You don’t need a whole operating system for that. It could just be a library which supported converting TRON code to other character sets, displaying text in TRON code, etc. You are right, I do not need a whole operating system for that (see below). But, the operating system design is helpful for many other things. The use of TRON character code is only one of its features; it also has many other features, many of which are difference from POSIX and other systems (although some things are similar to other systems). (I had written elsewhere about my ideas of operating system designs, too.) I had done some of the other stuff relating to TRON code in Linux too (although it is incomplete). I have written some programs that can display text, I had made fonts with TRON character set (although not all planes are implemented), and some programs that can convert some character codes (including e.g. EUC-JP, EUC-CN, EUC-KR). I had also been able to write partial English documentation from what I could figure out (which I documented on Just Solve The File Format Problem Wiki), although much of it is difficult. (One of the problems I have is the way the GT fonts are coded; they are several TrueType fonts, that use an improper Unicode mapping that does not seem to have anything to do with the actual Unicode characters that those numbers are supposed to correspond to (except font 1, which does correspond correctly to Unicode), and the mapping of improper Unicode into TRON code is given in a large PDF file, and the mapping seems to not have any sort of reasonable order, and that I could not figure out how to handle automatically. If I could figure out how to handle it properly then I could implement a file that can use them with the TRON code directly; someone who is Japanese and is able to compare the characters to figure out how to make up your own bitmap fonts with the GT character set, could do that too, I suppose.)

skissane 2y ago
The main selling point of the TRON character code, from what I understand, is CJKV speakers who disagree with Han unification. But it sounds like you don’t know Japanese. Do you know another CJKV language? If not, what makes the TRON character code attractive to you? Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas. But the TRON character code doesn’t really, since as a non-CJKV speaker, the debate about Han unification has no practical relevance, but rejecting that is the main selling point of the TRON encoding.
- zzo38computer 2y ago
  > But it sounds like you don’t know Japanese. Actually, I do know a little bit, but not very well. (I still don't like Han unification though. Also, that is not the only problem with Unicode (and some other character sets) anyways. Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.) > Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas. I am also interested in it for this reason, too. (I also have interest to learn of some old Japanese computer systems, too.) (As you could see, I did mention stuff other than TRON character code, too)
  - skissane 2y ago
    > Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.) There are a number of libraries in existence for converting between character sets. ICU is one of the most famous but it is Unicode-centric (it supports many character sets but wants to use Unicode as a lowest common denominator.) But older libraries such as iconv or recode lack ICU’s Unicode-centricity, so might be more appealing to you. Have you thought about doing something like contributing TRON support to recode? https://github.com/rrthomas/recode https://github.com/rrthomas/recode - I always called it “GNU recode”, but https://www.gnu.org/software/recode/ https://www.gnu.org/software/recode/ says it isn’t a GNU package, even though for a long time the GNU website hosted it. (I think maybe it is “ex-GNU”: the GNU project maintainer retired, and the new maintainer who took over wasn’t willing to abide by the GNU project’s policies.)

skissane 2y ago

The main selling point of the TRON character code, from what I understand, is CJKV speakers who disagree with Han unification. But it sounds like you don’t know Japanese. Do you know another CJKV language? If not, what makes the TRON character code attractive to you? Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas. But the TRON character code doesn’t really, since as a non-CJKV speaker, the debate about Han unification has no practical relevance, but rejecting that is the main selling point of the TRON encoding.

zzo38computer 2y ago
> But it sounds like you don’t know Japanese. Actually, I do know a little bit, but not very well. (I still don't like Han unification though. Also, that is not the only problem with Unicode (and some other character sets) anyways. Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.) > Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas. I am also interested in it for this reason, too. (I also have interest to learn of some old Japanese computer systems, too.) (As you could see, I did mention stuff other than TRON character code, too)
- skissane 2y ago
  > Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.) There are a number of libraries in existence for converting between character sets. ICU is one of the most famous but it is Unicode-centric (it supports many character sets but wants to use Unicode as a lowest common denominator.) But older libraries such as iconv or recode lack ICU’s Unicode-centricity, so might be more appealing to you. Have you thought about doing something like contributing TRON support to recode? https://github.com/rrthomas/recode https://github.com/rrthomas/recode - I always called it “GNU recode”, but https://www.gnu.org/software/recode/ https://www.gnu.org/software/recode/ says it isn’t a GNU package, even though for a long time the GNU website hosted it. (I think maybe it is “ex-GNU”: the GNU project maintainer retired, and the new maintainer who took over wasn’t willing to abide by the GNU project’s policies.)