OSDev.org

Octocontrabass wrote:It doesn't hang anymore, but it still does something that makes the keyboard completely unresponsive until the BIOS resets it. Since the keyboard is unresponsive, I can't do anything after the OS boots. The same keyboard on the other 386 has no issues.

Octocontrabass wrote:On both machines, I see floppy disk seek errors near the end of boot. This doesn't happen in Bochs, so it might just be a problem with the disk I'm using.

zaval wrote:i think it's just a taste and personal preference. if it was driven by the logic, the first ultimate FS to choose for this kind of stuff, would be ... the FAT family of course! it's interoperable AF, it's simple, it's fast, it's easy to implement. For every intelligent being in the whole Universe. not only for the weird "unix" world.

Mikaku wrote: Well ... you know, the FAT filesystem was not a choice, it is not suitable for UNIX-like operating systems. Looks like a toy.

zaval wrote:ah. so you have chosen a "suitable" FS with "maximum size of each filesystem is 64MB". doesn't look like a toy. this must be that famous "unix philosophy".

Mikaku wrote:Good to know that it no longer hangs on boot, but still worried that the keyboard gets unresponsive after a complete boot. I've never experienced that problem in all PCs where I tested Fiwix. Perhaps this is just an incompatible feature in that specific PC.

Mikaku wrote: No, as I said, the decision was to have a simple and UNIX-like filesystem. This is a double requirement. FAT is only simple, not UNIX-like. And also, the Minix FS is just temporary, this permits me to advance the kernel quickly. Then, as I also said, the EXT2 FS will be probably implemented to have more space in the FS.

Octocontrabass wrote:I was able to make the original kernel work by patching your keyboard_wait() function, so I don't think it's a problem with the hardware. From what I saw when I was creating that patch, your code to communicate with the keyboard has some issues. For example, you try to send and receive a lot of data through the keyboard controller without making sure it's ready. (Only your IRQ handler can do that, since the IRQ indicates that the keyboard controller is ready for you to read some data.)

zaval wrote:okay. the only question, just of curiosity, don't you think that a FS should not give a sh!t what your OS is "like"? I mean isn't it stupid to confer an entity with attributes which aren't (shouldn't) even closely be relevant to it? what's a "unix-like" FS? Or whatever-like FS? Is this a design which is impossible to reproduce on a non-whatever-like system? Is it where the design and implemenation are twisted into incomprehensible spagetti, where non-FS concepts are unnecessarily pulled into a FS? If so, then it's a garbage-like design. imho.

Mikaku wrote:

zaval wrote:okay. the only question, just of curiosity, don't you think that a FS should not give a sh!t what your OS is "like"? I mean isn't it stupid to confer an entity with attributes which aren't (shouldn't) even closely be relevant to it? what's a "unix-like" FS? Or whatever-like FS? Is this a design which is impossible to reproduce on a non-whatever-like system? Is it where the design and implemenation are twisted into incomprehensible spagetti, where non-FS concepts are unnecessarily pulled into a FS? If so, then it's a garbage-like design. imho.

At user-level you're right, the FS should be transparent enough that the user is not able to distinguish what kind of system is working behind that FS. But the FS is intrinsically bound (at low level) to the kernel, and so it must cooperate in a way that both worlds must understand each other.

Mikaku wrote:Do you know of a document with a functional example of a keyboard reset?

bool send_to_keyboard( uint8_t byte_to_keyboard )
{
    while( /* timeout */ )
    {
        if( !(inport_b( 0x64 ) & 0x02) )
        {
            outport_b( 0x60, byte_to_keyboard );
            return true;
        }
    }
    return false;
}

bool receive_from_keyboard( uint8_t * byte_from_keyboard )
{
    while( /* timeout */ )
    {
        if( inport_b( 0x64 ) & 0x01 )
        {
            byte_from_keyboard = inport_b( 0x60 );
            return true;
        }
    }
    return false;
}

Mikaku wrote: I just sent a RESET command (0xFF) and then there was an infinite 'while()' waiting for the byte 0xAA (RESET OK).

Octocontrabass wrote:I don't think there's anything wrong with the reset commands you're sending to the keyboard. The problem is how you're using the keyboard controller to send those commands and receive the responses. Before every read from or write to port 0x60, you must read port 0x64 to see if the keyboard controller is ready. Bit 0 is set when you can read from port 0x60. Bit 1 is clear when you can write to port 0x60.

stevewoods1986 wrote:You need to port a few GNU packages like Binutils, GCC and Nano. If you add NASM as well, I might be using your OS for my OS

stevewoods1986 wrote:Is your code open source? I would love to contribute.

Mikaku wrote:Test the latest patch I uploaded in the Fiwix web site http://www.fiwix.org/fiwix-0.9.0p3.img.gz, and let me know if you still have problems with that old 386 you have there.

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.