Live data from Hacker News

Uxn

100r.co

41–50 of 102 posts

Re: Uxn

#41

Earlier quoted context omitted.

I don't want to go to Chel-C - https://news.ycombinator.com/item?id=31705239 - June 2022 (124 comments) is sorta-related, since it's a rebuttal.

That is a savage savage critique beautifully written and demonstrated. I don’t even like small ‘simple’ systems and I’m smarting a bit reading it. Thanks for the link.

It seems a bit off target, though. It's not entirely wrong; it's true, for example, that Uxn doesn't lend itself to writing an efficient implementation easily. It's also true that the existing implementations are all on hardware that still requires a substantial amount of power, 2000 milliwatts or more, as well as being fairly inefficient in absolute terms.

On the other hand, on my laptop, the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead. And you can run it on a GameBoy Advance, so it's definitely a step in the right direction if you're looking for a frugal write-once/run-anywhere platform. It's the first attempt at the problem that's good enough to criticize, and it's something you can download applications for today.

It's easy to see ways to improve it, but to my knowledge the critiquing savage in question has not written a better system yet, although their critique is indeed informative.

Re: Uxn

#42

Earlier quoted context omitted.

The idea is that it's a standard and stable runtime environment. 100 years from now we'll still be able to run NES games, but running old windows programs may be nearly impossible. uxn is trying to be like the NES in that regard, but for more general use cases than just games. Write a uxn program once, and it can run anywhere, any time (on any device that can host uxn).

I totally get your point but we are great at running old windows now with dosbox and wine.

For now, but maintaining DOSBox and especially WINE continues to require substantial engineering effort, in part because the platforms they're running on change. Implementing Uxn/Varvara is many orders of magnitude easier than implementing Win32, as evidenced by the fact that many more people have done it despite the much smaller base of applications they can then run. It seems likely that many Win32 applications will execute incorrectly on versions of WINE that are current in 02124, unless they themselves are running on top of something like Uxn.

Probably not Uxn itself, though, because a 16-bit memory space is not a practical way to emulate Win32. Dmitry wouldn't be dissuaded, I suppose.

Re: Uxn

#43
post #36

Earlier quoted context omitted.

How would you hook up 64K of RAM to an 8008? Through some shift registers?

SPI RAM bit-banged via some IO ports is pretty easy, same as here: http://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Awesome, thanks for the link! I didn't remember that aspect of the 4004 project.

This would be a pretty amazing project. I wonder if you could get existing Uxn/Varvara applications like the Left text editor or Orca to run fast enough to be usable. Presumably for Orca you'd want to hook up external sound hardware rather than trying to bitbang the sound on the 8008, and I guess the same is even more true of a framebuffer.

If you were bitbanging RAM access at 7kbps it might be hard to get it to run instructions fast enough to be usable, though.

Re: Uxn

#44
post #43

Earlier quoted context omitted.

SPI RAM bit-banged via some IO ports is pretty easy, same as here: http://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Awesome, thanks for the link! I didn't remember that aspect of the 4004 project. This would be a pretty amazing project. I wonder if you could get existing Uxn/Varvara applications like the Left text editor or Orca to run fast enough to be usable. Presumably for Orca you'd want to hook up external sound hardware rather than trying to bitbang the sound on the 8008, and I guess the same is even more true of a framebuff…

i think 8008 would be much faster :)

i'll look into this

Re: Uxn

#46
post #17
post #13

Earlier quoted context omitted.

Electron is slow when your code is crappy .

Yea that must be why the original electron authors abandoned it and are now working on an editor in Rust.

Is Github working on a new editor?

Re: Uxn

#48
post #17

Earlier quoted context omitted.

Yea that must be why the original electron authors abandoned it and are now working on an editor in Rust.

Is Github working on a new editor?

The team who create Atom, Electron and tree sitter are working on zed: https://github.com/zed-industries/zed

Re: Uxn

#49
It is an amazing project ! You can develop and run uxn apps in the browser with https://exaequos.com. There are uxnasm, uxncli and wayvara, a Wayland varvara emulator that supports graphics. There are some compiled roms in /usr/local/share/roms
Post reply on HN