OSDev.org

Octocontrabass wrote: It works!

It seems like sometimes one of the shift keys gets stuck, and num lock affects keys that it shouldn't, but the keyboard is usable now.

Hello again,

I've released the new version 0.9.1 which includes improvements in the keyboard driver and, in order to close that issue with your old i386, I'd like to make sure that it no longer gets stuck with this new version.

Just let me know.
Thanks.

This new version takes about an hour to boot on either 386. Nearly all of that time is spent probing for hard disks. You really should do something about that.

As far as the keyboard driver is concerned, the shift keys still occasionally become stuck, and num lock still affects keys that it shouldn't. There seems to be a connection between the two: if num lock is on and I press one of the arrow keys or the insert/delete/home/end/pageup/pagedown keys, shift becomes stuck. Pressing either shift key returns it to normal.

Octocontrabass wrote:This new version takes about an hour to boot on either 386. Nearly all of that time is spent probing for hard disks. You really should do something about that.

Yeah, I think I'll have to differentiate the IDE delay time between different CPUs ... based on the speed (in HZ) for example. I mean, for slow CPUs the IDE delay time should be shorter than with faster CPUs.

Octocontrabass wrote:As far as the keyboard driver is concerned, the shift keys still occasionally become stuck, and num lock still affects keys that it shouldn't. There seems to be a connection between the two: if num lock is on and I press one of the arrow keys or the insert/delete/home/end/pageup/pagedown keys, shift becomes stuck. Pressing either shift key returns it to normal.

OK, seems like this also need some love.
Thanks a lot for your feedback!
Best regards.

Mikaku wrote:Yeah, I think I'll have to differentiate the IDE delay time between different CPUs ... based on the speed (in HZ) for example.

You probably want to use something like the PIT to keep track of timeouts. (For example, your driver tells your scheduler it wants to yield until a timeout expires, and the scheduler uses the PIT or some other time source to determine when the timeout expires. For a disk driver, you'll probably also want to cancel the timeout and resume execution immediately if a disk IRQ occurs.)

Yeah, this is how it's working (IRQ and PIT to detect timeouts). No, what I meant is about how long must be the loop while waiting the IDE device to be ready before selecting the drive, or before doing a reset, etc. You know, in faster CPUs such loop might need to be a bit longer than in slower CPUs.

In fact, this is already fixed and now my two old 386 are booting in less than 2 minutes.

Thanks anyway.

Hello again,

I've released the new version 0.9.2 (aka 1.0.0RC).

This is hopefully the last version before the final 1.0.0, that's why it's also called the 1.0.0 Release Candidate. The kernel is now stable enough to be installed from either a floppy drive or an IDE/ATA CDROM drive. It's also enough advanced to be able to compile itself, which means that it reached the long-awaited state of self-hosting.

Fiwix v1.0.0 is expected to be released on 23th April of 2018.

Stay tuned!
Thanks.