Haha, in a very superficial way yes, although it's not parallel, it follows the VERY sequential puredata bang paradigm of flow-based programming where events are triggered one after the other when a message is received, but it is an orchestrator of all these different CPUs that leverage Uxn's superwide IO bandwidth.
I'm not sure tho if I could really do like a transputer and distribute atomic tasks from within one of the runtimes.
@millihertz @vertigo This looks super promising! Can you please tell me more about that "superwide IO bandwidth", though? I've started implementing opcodes for CSP (Communicating Sequential Processes) channels & buffers in my cooperative multitasking VM. For exchanging larger data blocks between tasks/processes & devices, I've also been thinking about using (managed) shared memory regions and/or DMA-like approaches (controlled via CSP channels to a virtual DMA controller)... Hoping to share some progress soon!
so, linux pipes are stdin/out/err, I wanted a system that was a bit more like named pipes, so you could do "I'm sending a cursor change, or a sprite, etc.. " that hooks directly to the application's event system, imagine a kind of POKE(), that triggers vectors.
The uxn programs are written to respond to these events normally, but being able to trigger these from other programs is what is going on in this video.
@millihertz @vertigo That's great, thank you! 😀 I guess, your new "OS" layer is then responsible to manage and choose/assign which of these "pipes" to use for each newly requested connection (i.e. when draw "wires"). That's at least how I'm dealing with my CSP channels right now, which are similar in purpose, but using (potentially) blocking I/O, rather than being directly evented. A task can create any number of these channels (up to a global limit, likely 256/512 too, will see) to communicate, but I'm not sure yet about overhead/perf... Context switching is super fast, but my VM's underlying model is cooperative multitasking, so throughput all depends on what other tasks are up to, hence my interest in combining it with some DMA stuff..
From what you wrote, I gather your message passing/event handling is all synchronous & depth-first, correct? I.e. you poke a contr
... show more
@millihertz @vertigo That's great, thank you! 😀 I guess, your new "OS" layer is then responsible to manage and choose/assign which of these "pipes" to use for each newly requested connection (i.e. when draw "wires"). That's at least how I'm dealing with my CSP channels right now, which are similar in purpose, but using (potentially) blocking I/O, rather than being directly evented. A task can create any number of these channels (up to a global limit, likely 256/512 too, will see) to communicate, but I'm not sure yet about overhead/perf... Context switching is super fast, but my VM's underlying model is cooperative multitasking, so throughput all depends on what other tasks are up to, hence my interest in combining it with some DMA stuff..
From what you wrote, I gather your message passing/event handling is all synchronous & depth-first, correct? I.e. you poke a control address, this triggers an event, it gets processed immediately etc. That'd be similar to https://thi.ng/rstream, only much more low-level. Food for thought!
Last questions (if I may): Are all these diff apps/processes running at the same time sharing the same 64KB? Relocatable code? Also, how does the "window" compositing work here? Are you giving each process a virtual screen device/memory region (of desired window size), then composite everything externally (i.e. via the emulator)?
(No pressure answering — these are just v. similar questions/issues I've been dealing with myself recently... =:-]
@toxi your message passing/event handling is all synchronous & depth-first, correct?
yup, events happen immediately. It's a single user system. Right now there's a tiny bit of detection that handles what the system thinks the rom is trying to do so you don't have to hand-pick the ports to connect to. Like, if the rom has a vector event registered at the mouse device, then it's a mouse event, etc..
Are you giving each process a virtual screen device/memory region (of desired window size), then composite everything externally (i.e. via the emulator)?
Pretty much, each instance has its own cached screen buffer, so I can only redraw what changed. Ask me anything! But, I'm a total newb with this stuff tho, mileage may vary.
Thanks for this & the links!!! I did not know about Vavara using paging, yet another crossover! 😀 Also know I really should do some more RTFM, but: 1) I've only recently reanimated this old 2015 VM project of mine (rewriting/updating it in Zig) and 2) I've intentionally stayed away from Uxn to not get too side-tracked and influenced too much by Vavara's design decisions. Though the more I see about it, the more I realize you too have been integrating some of the same great concepts from older retro's & micro's like 6502's zero-page, hardware/device/coprocessor control registers/ports, bank switching... I remember how magical the latter felt on my Atari XL (with handsoldered 256KB RAM ext) and without it I couldn't even fit the Assembly source code for my game into the main RAM...
Looking v. forward to see where you're taking this all! 🤌
@toxi likewise, I think it's a good idea to stay away from Uxn in this case. It's unlikely that our needs will overlap, you already know all this stuff and uxn is an educational platform, plus, I think you can come up with a brilliant design that will likely inspire me in return.
You might want to have a look at Maxime's UVM, it's not stack machine programming proper, but has lots of good idea and the scope is a bit more modern. https://github.com/maximecb/uvm
Oh, this is all totally educational for me too! Maybe at some point for others as well... 🤷♂️ There's a lot to be gained from cross-pollinating ideas in this space and there's obviously some conceptual overlap (also w/ some shared goals), even though I've been aiming for configurable specs (but also aiming to keep lowest common denominator for those as low as feasible)...
Vertigo #$FF
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Vertigo #$FF • • •leah & glitches & bits, oh my!
in reply to Devine Lu Linvega • • •wait, have you just turned uxn into a virtual transputer?
@vertigo
Devine Lu Linvega
in reply to leah & glitches & bits, oh my! • • •Haha, in a very superficial way yes, although it's not parallel, it follows the VERY sequential puredata bang paradigm of flow-based programming where events are triggered one after the other when a message is received, but it is an orchestrator of all these different CPUs that leverage Uxn's superwide IO bandwidth.
I'm not sure tho if I could really do like a transputer and distribute atomic tasks from within one of the runtimes.
Karsten Schmidt
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Karsten Schmidt • • •so, linux pipes are stdin/out/err, I wanted a system that was a bit more like named pipes, so you could do "I'm sending a cursor change, or a sprite, etc.. " that hooks directly to the application's event system, imagine a kind of POKE(), that triggers vectors.
The uxn programs are written to respond to these events normally, but being able to trigger these from other programs is what is going on in this video.
There's 256 bytes of io, instead of just 3.
Karsten Schmidt
in reply to Devine Lu Linvega • • •@millihertz @vertigo That's great, thank you! 😀 I guess, your new "OS" layer is then responsible to manage and choose/assign which of these "pipes" to use for each newly requested connection (i.e. when draw "wires"). That's at least how I'm dealing with my CSP channels right now, which are similar in purpose, but using (potentially) blocking I/O, rather than being directly evented. A task can create any number of these channels (up to a global limit, likely 256/512 too, will see) to communicate, but I'm not sure yet about overhead/perf... Context switching is super fast, but my VM's underlying model is cooperative multitasking, so throughput all depends on what other tasks are up to, hence my interest in combining it with some DMA stuff..
From what you wrote, I gather your message passing/event handling is all synchronous & depth-first, correct? I.e. you poke a contr
... show more@millihertz @vertigo That's great, thank you! 😀 I guess, your new "OS" layer is then responsible to manage and choose/assign which of these "pipes" to use for each newly requested connection (i.e. when draw "wires"). That's at least how I'm dealing with my CSP channels right now, which are similar in purpose, but using (potentially) blocking I/O, rather than being directly evented. A task can create any number of these channels (up to a global limit, likely 256/512 too, will see) to communicate, but I'm not sure yet about overhead/perf... Context switching is super fast, but my VM's underlying model is cooperative multitasking, so throughput all depends on what other tasks are up to, hence my interest in combining it with some DMA stuff..
From what you wrote, I gather your message passing/event handling is all synchronous & depth-first, correct? I.e. you poke a control address, this triggers an event, it gets processed immediately etc. That'd be similar to https://thi.ng/rstream, only much more low-level. Food for thought!
Last questions (if I may): Are all these diff apps/processes running at the same time sharing the same 64KB? Relocatable code? Also, how does the "window" compositing work here? Are you giving each process a virtual screen device/memory region (of desired window size), then composite everything externally (i.e. via the emulator)?
(No pressure answering — these are just v. similar questions/issues I've been dealing with myself recently... =:-]
Devine Lu Linvega
in reply to Karsten Schmidt • • •@toxi your message passing/event handling is all synchronous & depth-first, correct?
yup, events happen immediately. It's a single user system. Right now there's a tiny bit of detection that handles what the system thinks the rom is trying to do so you don't have to hand-pick the ports to connect to. Like, if the rom has a vector event registered at the mouse device, then it's a mouse event, etc..
Devine Lu Linvega
in reply to Devine Lu Linvega • • •@toxi
Are all these diff apps running at the same time sharing the same 64KB?
They each have one page of 64kb per rom.
https://wiki.xxiivv.com/site/varvara.html
Are you giving each process a virtual screen device/memory region (of desired window size), then composite everything externally (i.e. via the emulator)?
Pretty much, each instance has its own cached screen buffer, so I can only redraw what changed. Ask me anything! But, I'm a total newb with this stuff tho, mileage may vary.
https://git.sr.ht/~rabbits/porporo/tree/main/item/src/porporo.c
XXIIVV — varvara
wiki.xxiivv.comKarsten Schmidt
in reply to Devine Lu Linvega • • •Thanks for this & the links!!! I did not know about Vavara using paging, yet another crossover! 😀 Also know I really should do some more RTFM, but: 1) I've only recently reanimated this old 2015 VM project of mine (rewriting/updating it in Zig) and 2) I've intentionally stayed away from Uxn to not get too side-tracked and influenced too much by Vavara's design decisions. Though the more I see about it, the more I realize you too have been integrating some of the same great concepts from older retro's & micro's like 6502's zero-page, hardware/device/coprocessor control registers/ports, bank switching... I remember how magical the latter felt on my Atari XL (with handsoldered 256KB RAM ext) and without it I couldn't even fit the Assembly source code for my game into the main RAM...
Looking v. forward to see where you're taking this all! 🤌
Devine Lu Linvega
in reply to Karsten Schmidt • • •@toxi likewise, I think it's a good idea to stay away from Uxn in this case. It's unlikely that our needs will overlap, you already know all this stuff and uxn is an educational platform, plus, I think you can come up with a brilliant design that will likely inspire me in return.
You might want to have a look at Maxime's UVM, it's not stack machine programming proper, but has lots of good idea and the scope is a bit more modern.
https://github.com/maximecb/uvm
GitHub - maximecb/uvm: Fun, portable, minimalistic virtual machine.
GitHubKarsten Schmidt
in reply to Devine Lu Linvega • • •Justin Miller
in reply to Karsten Schmidt • • •Devine Lu Linvega
in reply to Justin Miller • • •radioactive isosoph
in reply to Devine Lu Linvega • • •>more than four colors on screen at once
huh..
Devine Lu Linvega
in reply to radioactive isosoph • • •