Hi Geo,
> OK did a quick peek and most of them are in x86 assembly hmmm
Yeah. Basically calls to the 'cpuid' instruction to question the CPU for
its parameters.
> I see, so it means it got stuck somewhere on the checking, would it be
> possible to be inside an infinite loop?
I believe that the 'cpuid' instruction cannot loop or crash. Rather, I
suspect that for some reason the following messages are not printed
because the CPU got into an unknown state.
> it possible to have a debug mode for PilOS that it will not overwrite
> the messages?
Yes. What I did usually during development is inserting more 'print'
messages, similar to
mov $LongMsg, %si
call print
and and/or stopped the CPU with
jmp stop
so that the blue VGA screen of PilOS doesn't overwrite the boot screen.
Even easier is, if you re-use some existing message, e.g. "Loading
PilOS" (which is in 'LoadMsg') and then jump directly to 'bootError'
which will output the message and stop the CPU.
So if you insert
mov $LoadMsg, %si
jmp bootError
after e.g. the first 'cpuid' call, and you see "Loading PilOS" appearing
a second time, you are sure that the boot got this far.
The problem is that this is a bit tedious (unless using e.g. qemu)
because you have to put the test onto the USB-stick each time and reboot
the test machine with it.
> This is done via> BIOS interrupt 0x13:
>
>https://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D42h:_Extended_Read_Sectors_From_Drive
> I think VirtualBox doesn't support this interrupt call.
> I see, ok noted. But still this can be reworked right?
Hmm, perhaps, but I don't know how. Because we *need* to read the
sectors from the stick, don't we?
Perhaps there is another way to format the boot partitions and/or use
another BIOS call. I just don't know about it.
Also, it would be good to know if VirtualBox *really* doesn't support
this BIOS call, or if there is some other reason why it fails.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
