Aleksandar Kuktin <ak@triklod.rs> wrote:
> 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.

Yes, I thought of that too, so I hoped to make it urgent due to this.
(At least, urgent to not delete the file if a value other than 1 is
written to the delete port.)

> 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.

I do not deny that. It is worth having a implementation of Unicode, for
the reasons that you specify, but this does not mean that implementations
of anything else should be avoided.

However, I do not want to use Unicode for everything, and in my own
software and files and protocols I try to avoid it as much as possible.
(Unfortunately, I see too often programs that try to insist the use of
Unicode, even though in many cases it is unsuitable for various reasons.)

> 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.

I do know the TRON-Unicode mapping, although this is only possible for
plane 16 and 17. Some other planes include some characters that are not
present in Unicode, and TRON also doesn't use Han unification while
Unicode does, which means that the mapping isn't accurate anyways. It
will be necessary to make a font with the characters of large Chinese
character collections such as Dai-Kan-Wa-Jiten, rather than of Unicode.

I know the file formats used by GNU Unifont; that isn't the problem. The
problem is the Han unification of Unicode, as well as possibly the use
of character properties which do not match that of JIS (although I am
not entirely sure about this one). And, I was even unable to find any
suitable JIS fonts, for making plane 1, even!

It isn't plane 16 and 17 that I am mainly intending to make the TRON
fonts of, but rather the first fifteen planes, mainly. (I had found the
partially plane 9 in GlyphWiki.)

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

Hi all!

Sorry for the delay, I've been pretty swamped with non-computery
things lately, but I'm getting to the end of it soon so at least I'll
be able to work on this soon.

I've seen fseek requested over and over again, and while I'm
personally not too keen on reading large files, it's becoming clear
that we'll need this in one form or an other.

Modifying the append port and renaming it to something that needs a
magic number is not the worst idea, and if your application absolutely
needs it, then implement it and make some apps with it.

But think about it this way, Uxn is meant to be a limited playground
and Unicode might just be beyond what Uxn can do. The way I've handled
multi-lang support is to include a different dictionary file based on
the language I'm targeting and only include the assets needed for that
one language, ideally your rom should try to avoid hosting/requiring
assets that will not be shown on screen.

You might be better off splitting the file to load in smaller chunks
and seeking in uxntal itself. That's what I do in potato:

https://git.sr.ht/~rabbits/potato/tree/main/item/src/potato.tal#L411

One thing I'd like to mention, a while back the success port was the
offset port, we just wrote a number between 0-ffff, and the file
reading or writing started with that offset. I wouldn't mind exploring
that too.

--

Varvara is meant to be customized, if you want to make something
totally different, you can always just embed the rom in the emulator
and use that. You don't have to suffer the limits of the specs, think
of the specs on the wiki as the MVP for the thing.

I'd love to see the application that you're building that needs
unicode support, maybe you'll find that making a Unicode device will
be the better way to do this, since unicode ties with assets and might
not play well with the screen's sprite drawing routine. There's no
shame in that, I use a polygon/vector drawing device myself all the
time in Varvara, so ;)

>On Sun, 8 Jan 2023 09:07:39 -0800
>Hundred Rabbits <hundredrabbits@gmail.com> wrote:
>
> Hi all!

o/

> Sorry for the delay, I've been pretty swamped with non-computery
> things lately, but I'm getting to the end of it soon so at least I'll
> be able to work on this soon.

Honestly, I just thought you were sailing the Pacific again. :) As is
obvious, I'm also sometimes slow in replying.

> But think about it this way, Uxn is meant to be a limited playground
> and Unicode might just be beyond what Uxn can do.

I might be a limited playground, but it's a pretty good design, from
what I've seen to date. And real hackers delight in making computers do
things nobody thought they might do. :)

My real interest in uxn is in that it seems to span over a lot of
complexity, but is itself simple. In other words: it makes complicated
stuff like GUIs accessible. It takes a lot of wisdom to make something
like that.

An example of how uxn makes life better: for a long time now, I've been
working on making a good computer. Over a decade ago, I started using
Linux because I want my computer to be my own. But then it turned out
"my computer" isn't mine unless I also have control over hardware. So I
started making it using FPGAs. You can find remnants of a failed
attempt on https://github.com/akuktin/special_snowflake . I'm currently
working on a redesign, but I always had a problem with graphics. I can
make a hardware framebuffer and a basic video card, but how do I fill
it with pretty GUIs and pictures? Porting something giant like X11 is
mostly out of the question, but what else can I do? Well, in comes
uxn/varvara and now I know. I can make an emulator of uxn with
varvara-compatible virtual peripherals and the roms will take care of
the rest.

It's a perfect system. The only thing it needs is elbow grease. :)

> The way I've handled multi-lang support is to include a different
> dictionary file based on the language I'm targeting and only include
> the assets needed for that one language, ideally your rom should try
> to avoid hosting/requiring assets that will not be shown on screen.

If I were in control of the entire content the application is supposed
to show, that would be a worthwhile approach. Sadly, I decided that I
should begin by making an email client - and I don't have control
over the content of emails. :) And maybe you or others are wondering
why email client. Basically, it's an incredibly important piece of
software (for me at least), and I want to detach my email client from
modern systems. The only email client that works for me is Claws-mail,
but it's very slow (on slow CPUs) and utterly dependent on X11 and
modern Unices. I tried looking for other options, but the only email
client that might work in a "lotech" environment is mutt. Yet mutt is
also dependent on Linux, and its VT102-compatible console. Seriously, I
tried running it on FreeDOS. It doesn't work. It needs Linux or
something even bigger, and you know how big Linux's footprint is. Does
ANYBODY know what GCC does?

So I decided to really put uxn to the test and write an email client
for it. If it survives this, it will survive everything else. xD And
also, let's get rid of Zawinski's Law immediately so we can then focus
on other more interesting things. xD I'm positive almost everything can
fit into 64 kiB of RAM - even much, much less - but the databases for
Unicode, the font and the email database will have to stay outside.
That's OK.

BTW, it won't be a complete email client, only the non-network parts of
it. Basically, fetching, sending and possibly sorting of the mail will
be done outside of this rom, on the host system or similar. Those parts
aren't difficult to make - they don't require a GUI or TUI or any real
UI. That is just program logic. But the actual email renderer and editor
for sending - it's those bits that are complicated, and that need to be
divorced from the modern overly bloated systems.

> You might be better off splitting the file to load in smaller chunks
> and seeking in uxntal itself. That's what I do in potato:
> 
> https://git.sr.ht/~rabbits/potato/tree/main/item/src/potato.tal#L411

Yes, I will do something like this in the first iteration. Today I've
been messing with the font and I figured out I can fit all the bitmaps
for the Base Multilingual Plane into 27 files each under 64 kiB. That's
good enough. And the map from Unicode codepoints to the glyphs will eat
another 8 files of 64 kiB. I can live with that. It's not glamorous but
it's the first iteration.

> Varvara is meant to be customized, if you want to make something
> totally different, you can always just embed the rom in the emulator
> and use that. You don't have to suffer the limits of the specs, think
> of the specs on the wiki as the MVP for the thing.

IIII... didn't think of that. Now I'm glad I asked on this list because
it would take me a decade to come up with that idea on my own. In
practice I won't be going that route this time because the rom I'm
writing is ultimately supposed to end up in a generic emulator on
low-spec hardware. It can (and hopefully will) end up in all other
kinds of places, but I can't allow myself the luxury of shipping the
frilly emulator as the application. :)

> I'd love to see the application that you're building that needs
> unicode support, maybe you'll find that making a Unicode device will
> be the better way to do this, since unicode ties with assets and might
> not play well with the screen's sprite drawing routine. There's no
> shame in that, I use a polygon/vector drawing device myself all the
> time in Varvara, so ;)

Hmm... a specialized Unicode device... That *might* be a good idea. I
won't do it right away, but I'll keep it in mind.

I'll eventually post the application publicly, with sourcecode and
everything. So you will be able to study it, modify it, share it and
enjoy it - or suffer it: only history will tell which of those two. :)

-- 
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.
--

>On Fri, 06 Jan 2023 20:02:19 -0800
>news@zzo38computer.org.invalid wrote:
>
> Aleksandar Kuktin <ak@triklod.rs> wrote:
>> [...]
> 
> Yes, I thought of that too, so I hoped to make it urgent due to this.
> (At least, urgent to not delete the file if a value other than 1 is
> written to the delete port.)
> 
>> [...]
> 
> I do not deny that. It is worth having a implementation of Unicode,
> for the reasons that you specify, but this does not mean that
> implementations of anything else should be avoided.
> 
> However, I do not want to use Unicode for everything, and in my own
> software and files and protocols I try to avoid it as much as
> possible. (Unfortunately, I see too often programs that try to insist
> the use of Unicode, even though in many cases it is unsuitable for
> various reasons.)

Agreed, with all three paragraphs.

> > 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.
> 
> I do know the TRON-Unicode mapping, although this is only possible for
> plane 16 and 17. Some other planes include some characters that are
> not present in Unicode, and TRON also doesn't use Han unification
> while Unicode does, which means that the mapping isn't accurate
> anyways. It will be necessary to make a font with the characters of
> large Chinese character collections such as Dai-Kan-Wa-Jiten, rather
> than of Unicode.
> 
> I know the file formats used by GNU Unifont; that isn't the problem.
> The problem is the Han unification of Unicode, as well as possibly
> the use of character properties which do not match that of JIS
> (although I am not entirely sure about this one). And, I was even
> unable to find any suitable JIS fonts, for making plane 1, even!
> 
> It isn't plane 16 and 17 that I am mainly intending to make the TRON
> fonts of, but rather the first fifteen planes, mainly. (I had found
> the partially plane 9 in GlyphWiki.)

Uf, that does sound like a bigger problem then I thought.

I fear I can only help by offering moral support. :) TRON is a new
topic for me and I really can't offer anything more useful than what I
already did. :(

-- 
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.
--

>On Sun, 8 Jan 2023 09:07:39 -0800
>Hundred Rabbits <hundredrabbits@gmail.com> wrote:

> I'd love to see the application that you're building that needs
> unicode support, (...)

As a follow-up, the technology demonstrator for my implementation of
Unicode is public on https://github.com/akuktin/trainleave . It renders
text. :) I didn't include neither the rom nor the resource files as I
wanted to avoid putting binary content into Git. I think the code
should build easily for everyone. Two resource files, for the font and
for the Unicode character database, need to be downloaded, as they too
haven't been included.

-- 
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.
--

I've been working on a game called Oquonie, which is larger than 64kb,
and where the assets are spread over 8 pages of memory. The game will
be shipped wrapped inside its own uxnemu, but after chatting on IRC
about the idea and seeing others interested in having access to this
sort of power, I've made a rough draft public so anyone can try it
out.

oquonie: https://youtu.be/cfkrGSMsT-E

It's not quite file seeking, but it might do what you need if you just
need extra memory.

initial draft: http://wiki.xxiivv.com/site/varvara.html#system

You can think of it as a sort of expansion port, it will allow you to
run special operations to move large swathes or memory, bliting,
etc... It's more of an "advanced" feature and I doubt it will make its
way into ALL the emulators, as some of them are on quite small systems
and won't allow for more than 1-2 pages of 64kb.

Its implementation is just 9 lines, generally, the operation 1(copy),
the only one implemented and the only thing I need for Oquonie, is a
way to move memory in and out of the unaddressable pages of the rom.

It's also implemented in the stasher branch of Uxn32.  But, it's a
work in progress, I'll be using it to build the game I'm working on,
let me know if you have any question, ideas, etc :)