Hello Virgil,


Am 01.01.2025 um 20:49 schrieb Virgil Dupras:
>> Running all the manual tests show that keyboard support is also
>> suboptimal. For retrieving e.g. shifted arrow keys, ReadKeyStrokeEx is
>> needed, which is optional and requires fallback code. But even with
>> ReadKeyStroke you can receive normal arrow keys, function keys and
>> Escape key, which your current code does not handle.
>
> Yes I've also noticed this this morning. On my short term TODO list.
> Unfortunately, the "Ex" family of SIMPLE_INPUT is only available on UEFI, not
> EFI, so this will have to be an optional separate driver.

Hello Virgil,


Am 01.01.2025 um 14:01 schrieb Virgil Dupras:

> Thanks for testing. I don't have access to this program so my debugging
> abilities are limited, but it's good to know that it fails somewhere.
>
>  From the screenshot, it looks like failure happened before init.fs could be
> loaded, so it means it's drv/efi/blkio who's likely at fault.

It's
<https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#efi-block-io-protocol-reset>.
Calling it with ExtendedVerification=1 results in EFI_DEVICE_ERROR.

Hello Virgil,


Am 27.12.2024 um 21:55 schrieb Virgil Dupras:

> You can easily build a EFI boot media by looking at "deploy/efi".

When you encourage us to test it, of course I do. I only tested it on
two virtual environments, VirtualBox and Microsoft Hyper-V (both on
Windows 11). For Hyper-V, to make this a bit of a challenge, I chose the
"Generation 2 VM" without legacy support, so all you have here is UEFI
and some modern virtio drivers. It is known to be quite picky when
running actual OSes (apart from 64-bit Windows, 64-bit Linux and FreeBSD
most stuff does not work out-of-the box, even other BSDs), but EFI

Hello Virgil,

Am 29.12.2024 um 14:31 schrieb Virgil Dupras:
> On Sun, Dec 29, 2024 at 12:56:35AM +0100, Michael Schierl wrote:

> If I understand this thread well, any "double" boot failure would result in
> some reserved memory variable being bumped up permanently?

In some broken UEFI implementations, yes. In fact, only the first boot
needs to fail and throw you back into the OS selection menu (or fall
back to another OS automatically), the second one may succeed. I myself
have only experienced it when the second OS booted used CSM, but I won't
guarantee that. I am aware of later UEFI revisions of the same mainboard
that reset and recalculate the memory map if you reset the UEFI to

Hello,


Am 28.12.2024 um 22:51 schrieb Virgil Dupras:

> That being said, I haven't fully explored yet what this implies. EFI keeps some
> services available at runtime. Maybe everything Dusk uses could be used after
> ExitBootServices(). Also, maybe that not exiting boot services results in bad
> long term effects such as memory leaks or something. To be determined with
> usage.

IIRC, Input devices (keyboard/mouse) and disk devices are no longer
available once boot services have been exited. And for output, the only
thing that remains is a linear framebuffer if GOP provides one.

Hello polifemo,


Am 18.11.2024 um 23:08 schrieb polifemo:
> After I run make in duskos/ and generating ./dusk, I ran make in
> usermode and the build failed. It says that "asm/i386.fs path not
> found". And indeed that file is not in asm/ .
>
> REPRODUCTION STEPS
> git clone https://git.sr.ht/~vdupras/duskos
> cd duskos
> make
> cd usermode
> make

Hello Virgil,


Am 13.11.2024 um 16:30 schrieb Virgil Dupras:
> I think I'll like this ISA...

The only thing you might dislike is its immediate encoding. Bits are
shuffled to fit between the other parts, and in case your assembler
implements the "li" instruction (to load a 32-bit immediate value), it
needs to split the immediate across two instructions slots, one slot
holding the upper 20 bits (zero-extended to the right) and the other
slot holding the lower 12 bits (*sign* extended to the left, just like
regular 12-bit immediate values), which get added (not ORed). So if the
MSB of the lower 12 bits is set, the upper part needs to be corrected by

Hello,


Am 26.09.2024 um 17:26 schrieb Henk van de Kamer:

> The first "command" learnt me something. I still can't wrap my head
> around where the files are. Probably in memory? And not in a filesystem
> we are used to? Still haven't figured out how the listdir is supposed to
> work.

you can do

f<< home/sh.fs
ls /doc

Hello Virgil,

Am 26.05.2023 um 23:19 schrieb Virgil Dupras:
> On Fri, May 26, 2023, at 4:58 PM, Michael Schierl wrote:

> This changes the implicit semantic of "code", which so far meant nothing more
> than "create an entry". Now it would be "create an entry and add a prelude".
> This means that "here" doesn't point to the beginning of the code after a "code"
> call. This breaks a lot of usages for it.

Fair point.

> Also, what happens when we jump to that word instead of calling it? Currently,
> it changes nothing as it simply defers the "ret". I use this pattern quite

Hello Virgil,

Am 26.05.2023 um 21:01 schrieb Virgil Dupras:
> Hello all,
>
> People looking at Dusk's commits will have seen that I've been happily porting
> Dusk to ARM with the Raspberry Pi model 1 as a first target. Things are going
> well and the ARM architecture is interesting.

Having more than one architecture fully supported will definitely be
great for proving Dusk OS's concepts.

> One obvious roadblock is the way "calls" are made in ARM. "bl" doesn't do like
> a traditional "call", it simply saves PC to the "LR" register. To make it