Hello,
This is my first non-trivial contribution to Dusk OS. I am still trying
to create a web emulator (wasm or JavaScript) for Dusk OS, but I first
want to try to understand the system better and reduce the complexity
for my emulator.
Dusk OS currently depends on both a Grid and a Screen driver to be able
to use all applications. Therefore, I decided to start implementing a
Grid driver that runs as a framebuffer on the Screen driver.
While doing so, I encountered a few small documentation glitches that I
fixed as well.
Also I reintroduced the compile fix for Cygwin.
After loading the framebuffer driver, you can run "fbgrid$" to activate
graphics mode and switch the grid over to the framebuffer.
Tested in my own (still very broken and slow, therefore unreleased)
emulator, as well as in qemu. It is (as expected) slower than the native
vga grid driver, but supports higher resolutions and ged is (on my
machine) still usable.
Regards,
Michael
On Tue, Apr 25, 2023, at 6:29 PM, Michael Schierl wrote:
> Hello,>>> This is my first non-trivial contribution to Dusk OS. I am still trying> to create a web emulator (wasm or JavaScript) for Dusk OS, but I first> want to try to understand the system better and reduce the complexity> for my emulator.>> Dusk OS currently depends on both a Grid and a Screen driver to be able> to use all applications. Therefore, I decided to start implementing a> Grid driver that runs as a framebuffer on the Screen driver.
This is super slick! You've obviously done your homework, all the right parts
are at the right place. It's great to see someone else's style using constructs
I've created. The only tiny mentions I'd make is to signal the existence of
2rdrop and to1+ (this one is brand new).
Nested loops of course offer their challenges, elegance-wise, but I don't see
obvious ways around it.
Since you've obviously been using the documentation, I'd be really interested to
know if there were pain points or confusions other than the fixes you've made
already.
And of course, if you have comments about the system in general, I'm all ears.
> While doing so, I encountered a few small documentation glitches that I> fixed as well.
Thanks!
> Also I reintroduced the compile fix for Cygwin.
Sorry about that. I moved quite a few things around in the HAL rewrite.
> After loading the framebuffer driver, you can run "fbgrid$" to activate> graphics mode and switch the grid over to the framebuffer.>> Tested in my own (still very broken and slow, therefore unreleased)> emulator, as well as in qemu. It is (as expected) slower than the native> vga grid driver, but supports higher resolutions and ged is (on my> machine) still usable.
It's a good idea to have this around. It might also be useful for systems that
don't have a native text mode. Again, good work!
Regards,
Virgil
Hello,
Am 26.04.2023 um 01:49 schrieb Virgil Dupras:
> On Tue, Apr 25, 2023, at 6:29 PM, Michael Schierl wrote:> Since you've obviously been using the documentation, I'd be really interested to> know if there were pain points or confusions other than the fixes you've made> already.
I probably should have used the documentation more. I mainly grepped for
words in the whole code base, and when documentation showed up, I read
it first before reading the code results. Those files I read were clear
to me. I stumbled a bit with one case which probably would have been
clear to a more experienced Forth user, but resolved quickly after
looking at usages of structbind word. Maybe you are explaining it in
some documentation file, I just did not find it with my "sledgehammer"
approach to documentation, and finally I think my way was faster than
reading *all* of the documentation.
The confusion stems from the fact that the immediate word ' has the
compiled word ['] as its compiled counterpart, while other compiled
words like if have [if] as their immediate counterpart.
So when copying a line like
screen :activate FbGrid :new ' grid rebind
which "worked" on the REPL to inside of fbgrid$ word, although there
were no "be cautious" words in brackets, you have to know to replae the
' by ['] or weird things will happen. (In hindsight, I understand *why*
the other variant does not work, but as you know, hindsight is 20/20.)
> And of course, if you have comments about the system in general, I'm all ears.
What also cost me some time: I started with the POSIX VM and tried to
hack a (non-portable) framebuffer UI onto it. Once the grid was working,
I was surprised that some commands did not work without showing an error
message. Until I noticed that some errors (e.g. word not found or stack
underflow) are not output via emit but directly to the stdout console
(which I did not see any more at that time).
But also totally understandable: The POSIX VM is not supposed to support
anything else than stdout, so why bother routing all the error output
through the (emulated) Forth layer?
Regards,
Michael
On Wed, Apr 26, 2023, at 4:11 PM, Michael Schierl wrote:
> Hello,>> Am 26.04.2023 um 01:49 schrieb Virgil Dupras:>> On Tue, Apr 25, 2023, at 6:29 PM, Michael Schierl wrote:>>> Since you've obviously been using the documentation, I'd be really interested to>> know if there were pain points or confusions other than the fixes you've made>> already.>> I probably should have used the documentation more. I mainly grepped for> words in the whole code base, and when documentation showed up, I read> it first before reading the code results. Those files I read were clear> to me. I stumbled a bit with one case which probably would have been> clear to a more experienced Forth user, but resolved quickly after> looking at usages of structbind word. Maybe you are explaining it in> some documentation file, I just did not find it with my "sledgehammer"> approach to documentation, and finally I think my way was faster than> reading *all* of the documentation.
Whatever works the best :) I'm glad the docs were adequate for this usage.
> The confusion stems from the fact that the immediate word ' has the> compiled word ['] as its compiled counterpart, while other compiled> words like if have [if] as their immediate counterpart.
' is not an immediate, ['] is. The symbolic logic is that "['] foo" is the
equivalent of doing "[ ' foo litn ]", so "[']" makes sense as a symbol, which
means "drop to interpret mode and compile the next word lookup as a literal".
I agree that there's a discrepancy with "if" and "[if]" because the relation
between these two words is not the same as with ' and [']. It's rather "do like
if, but in interpret mode". However, I can't think of a better name for this.
Also, if my memory serves me right, I think I saw this usage in other Forths,
so I went "meh, let's name it thus".
I *could* add a check for compile flags in "if" and have "if" and "then" work in
interpret mode, but the way [if] and [then] work is completely different, and
I'd have to write in the documentation: "if and then work in interpret mode, but
none of the other flow words do". I feel like it would add confusion.
> So when copying a line like>> screen :activate FbGrid :new ' grid rebind>> which "worked" on the REPL to inside of fbgrid$ word, although there> were no "be cautious" words in brackets, you have to know to replae the> ' by ['] or weird things will happen. (In hindsight, I understand *why*> the other variant does not work, but as you know, hindsight is 20/20.)>>> And of course, if you have comments about the system in general, I'm all ears.>> What also cost me some time: I started with the POSIX VM and tried to> hack a (non-portable) framebuffer UI onto it. Once the grid was working,> I was surprised that some commands did not work without showing an error> message. Until I noticed that some errors (e.g. word not found or stack> underflow) are not output via emit but directly to the stdout console> (which I did not see any more at that time).>> But also totally understandable: The POSIX VM is not supposed to support> anything else than stdout, so why bother routing all the error output> through the (emulated) Forth layer?
That's the idea, yes. Even more so than with Collapse OS' CVM, which has more
feature parity with real ports. For a while, I wasn't sure that the CVM could
have a functional DuskCC backend, so at that point, I decided to make the CVM a
second class citizen, purely just for building real ports. Now that I know that
DuskCC can compile just fine under the CVM, this decision could be revised, but
for now, that's the design.
Regards,
Virgil