Aleksandar Kuktin <ak@triklod.rs> wrote:
> But it would be better (easier on the host system) if I were able to
> perform a fseek(). I saw there are at least two other proposals for
> this. I didn't write a patch - at least not yet - but I can offer that
> it's enough to allocate another bit from the "append" byte and have
> this bit mean the writes or reads are meant to be seeks. Bit 0 would
> then be meaningless. This setup is 100% percent backwards compatible,
> observe:
> 
> 0x00 -> writes and reads start at the beginning of the file and proceed
>         linearly
> 0x01 -> write starts at the end of the file, read starts at the
>         beginning of the file and they both proceed linearly
> 0x02 -> no writes or reads are performed, instead the file pointers
>         associated with them get moved; presumably the read pointer
>         won't be able to seek beyond the beginning or end of file and
>         presumably the write pointer can't seek beyond the beginning of
>         the file but CAN seek beyond the end of the file. Writing to
>         beyond the end of the file automatically expands the file to
>         that length and fills the space with NULLs.
>      -> it's obviously possible to forbid seeks of the write pointer
>         from leaving the bounds of the file
> 0x03 -> behaves the same way as 0x20
>      -> it might be a good idea to make 0x03 undefined
> all others -> undefined

It seems that it cannot easily go backward, or do large multiples of 64K
at once. I had made my own proposal with what I think is needed (and I
have implemented it in Uxn38 but only if the -x switch is used), although
it might be possible to simplify it a bit. I have both the delete port and
append port used for other purposes, and if their values are 1 then they
will be compatible with the existing specifications, I think.

My idea about the file vector is that it should be reserved for purposes
of communication (in case an implementation somehow supports accessing
objects that are not ordinary files and so might want to wait for data),
and is not used when accessing ordinary files. Many emulators probably
will not use the file vector at all, which is probably OK.

I think that Unicode is no good, but if you want to implement that, that
is OK; since many files are Unicode now they can be displayed. However,
something I had wanted to do is the implementation of dealing with text
encoded by TRON code. I could do that, but in order to implement that,
first I would need suitable fonts, and I do not have them (or maybe I do,
but I cannot figure out how to use them). (My opinion actually is that no
universal character set (including TRON and Unicode) can ever be suitable
for everything, but TRON can be good for some things, and does have some
advantages over Unicode especially if you want to write in Japanese (but
it has its own problems too).)

-- 
Don't laugh at the moon when it is day time in France.

>On Fri, 06 Jan 2023 11:22:14 -0800
>news@zzo38computer.org.invalid wrote:
>
> It seems that it cannot easily go backward, or do large multiples of
> 64K at once. I had made my own proposal with what I think is needed
> (and I have implemented it in Uxn38 but only if the -x switch is
> used), although it might be possible to simplify it a bit.

Yes, yours was one of the two proposals I saw. I liked the ability to
multiply the seek. I also later realized in my feature request I made
no mention of seeking backwards - which is kind of needed. xD You also
added functions for opening and closing files. I'm new to uxn so I
don't know what people envisage uxn doing in the future - and because
of that I can't say anything about closing and opening of files. I
*seems* a bit fiddly, but maybe people need the fiddly bits?

> I have both the delete port and append port used for other purposes,
> and if their values are 1 then they will be compatible with the
> existing specifications, I think.

Wohoho! Repurposing a delete port! Brave! xD I wouldn't touch it for
the next 20 years - too much risk of accidentally deleting data. But
OTOH if it's going to be repurposed then now is the time - before the
current design of varvara gets too much traction for the risk to be
too great.

> My idea about the file vector is that it should be reserved for
> purposes of communication

I have no comment on that. Communication and networking is "there be
dragons".

> I think that Unicode is no good, but if you want to implement that,
> that is OK; since many files are Unicode now they can be displayed.

The question, really, is how much of a break with the current computing
you want to make, how much you can afford to make, and how much you
need to make. Let's say you want to change something in computing. OK,
now you introduced incompatibilities. A classic example of this used to
be Java applets on bank websites. They didn't work on Linux so if you
wanted to do e-banking you had to use Windows. (Or maybe Mac, I don't
know, this was before iPhone.) But sometimes the advantage of the
change you introduced overshadowed the incompatibility.

Now, everyone is going to answer this differently, but I think people
will need a way to handle Unicode for at least some decades in the
future. Too much text has already been produced that is encoded in
Unicode. I've been reading the spec for the last few days and, believe
me, I *know* it's a nightmare. xD It turns text processing from the
second fastest operation a computer does to one of the slow operations.
But in this case, I think backwards compatibility with the *data*
produced in previous computing is a worthy goal. Necessary, even.

> However, something I had wanted to do is the implementation of
> dealing with text encoded by TRON code. I could do that, but in order
> to implement that, first I would need suitable fonts, and I do not
> have them (or maybe I do, but I cannot figure out how to use them).

I'll be honest - I didn't know TRON existed before you wrote about it.
I threw a look on Wikipedia and it seems workable.

I found a prerendered font that might be useful to you too. It's called
GNU Unifont, you can find its page here: http://unifoundry.com/unifont/
You can also download it in several formats, including BDF that is
straightforward to parse for both machines and humans (plaintext all
the way) and also a funky hexadecimal format that has only the
codepoints and bitmaps.

BTW, if you want to dig deeper into BDF, there is a normative document
published by Adobe. Easy read.
https://www.adobe.com/content/dam/Adobe/en/devnet/font/pdfs/5005.BDF_Spec.pdf

It even has a section on the binary format of the font on the tapes
Adobe would apparently ship to customers. xD

At any rate, Unifont maps glyphs to Unicode codepoints, maybe you can
find a TRON-Unicode mapping somewhere and then translate Unifont to
TRON? Because of Unicode's complexity your synthetic font will probably
be incomplete, but you should be able to get at least some mileage out
of it.

-- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--