FAT12 driver and a command line.

[DrLink]

Before I begin, I'd like to say: This post screams "Lino Commando" (for those of you who don't know exactly what I mean, http://wiki.osdev/org/Lino_Commando should answer your question)...

So, the n00b is back, and he needs to know where to start on reading a FAT12 floppy disk before anything else.. The OS is built into the FAT floppy disk I want to read. I already have successfully added support to detect the type of floppy disk drive installed (or at least if there even is a floppy drive)... I also have some basic keyboard support. Much like that Lino Commando article I linked to above, my goal is to have that God-forsaken command line working and then from there gain basic FAT12 file system support. I'm stuck when it comes to reading articles on the wiki, and in my previous iteration of my OS's kernel, I received a nice General Protection Fault each time I'd type a character at the supposed "command line" that I attempted. Since trial and error doesn't work for me (and rarely does), I decided to come running here, because there seems to be nowhere else.

It would really be helpful to me if someone could point me to some tutorial(s) or article(s) about doing things like this, or if you have time, some example code...

The command line is my top priority. Reading the FAT12 file system on the floppy disk the kernel has booted from is my second priority... so providing articles, tutorials, examples, etc. for this would also be nice.

And before you reply, please take into account that reading technical specifications of file systems and articles written to that kind of tone really don't help me, because I honestly don't have enough attention span to read those kinds of writings. I'm not (and never will be) an "RTFM" Nazi like some people in the programming world are.

[Troy Martin]

Loop a "get keypress" thing and check for backspace and enter.
Do a series of "strcmp"-like things where you loop cmp and check for a null termination.
Act on input.
Go back to start.

Seriously, that's pretty much it. If you're in real mode you can call the BIOS. If in pmode, you have to read the keyboard ports. CMP is always the same.

[Combuster]

And before you reply, please take into account that reading technical specifications of file systems and articles written to that kind of tone really don't help me, because I honestly don't have enough attention span to read those kinds of writings. I'm not (and never will be) an "RTFM" Nazi like some people in the programming world are.

You can't expect everybody to read the manuals for you, do the work for you, feed the answers for you. If your span of attention is a problem then you should work on that problem, you'll need that skill anyway.

And typing in red shows that your span of attention is bad enough to not read the forum rules which tells you not to. I have to copy-paste it to see what it actually reads. It is also not an excuse to not RTFM since this is begging anybody to just shout that in your face (self-fulfilling prophecy it seems ).

Fact is most people who react like this just didn't do so.

[neon]

And before you reply, please take into account that reading technical specifications of file systems and articles written to that kind of tone really don't help me, because I honestly don't have enough attention span to read those kinds of writings.

How do you expect to write anything low level then? i.e., Device drivers, kernels, etc...? This is kind of needed for most operating systems

[Troy Martin]

And before you reply, please take into account that reading technical specifications of file systems and articles written to that kind of tone really don't help me, because I honestly don't have enough attention span to read those kinds of writings. I'm not (and never will be) an "RTFM" Nazi like some people in the programming world are.

http://wiki.osdev.org/FAT
http://www.eit.lth.se/fileadmin/eit/cou ... iption.pdf

That'll be three dollars for your RTFMs. Come back tomorrow, we have a two for one special on PDF files!

[DrLink]

Now that I've made a good fool of myself and got a basic command line running, take a look at my kb.c and tell me why the upt command doesn't respond with the uptime, because I'm up late at night, not thinking straight, and continuing to wonder why this code doesn't return the uptime, but absolutely nothing:

Code: Select all

#include <system.h>

unsigned char kbdus[128] =
{
    0,  27, '1', '2', '3', '4', '5', '6', '7', '8',	/* 9 */
  '9', '0', '-', '=', '\b',	/* Backspace */
  '\t',			/* Tab */
  'q', 'w', 'e', 'r',	/* 19 */
  't', 'y', 'u', 'i', 'o', 'p', '[', ']', '\n',		/* Enter key */
    0,			/* 29   - Control */
  'a', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', ';',	/* 39 */
 '\'', '`',   0,		/* Left shift */
 '\\', 'z', 'x', 'c', 'v', 'b', 'n',			/* 49 */
  'm', ',', '.', '/',   0,					/* Right shift */
  '*',
    0,	/* Alt */
  ' ',	/* Space bar */
    0,	/* Caps lock */
    0,	/* 59 - F1 key ... > */
    0,   0,   0,   0,   0,   0,   0,   0,
    0,	/* < ... F10 */
    0,	/* 69 - Num lock*/
    0,	/* Scroll Lock */
    0,	/* Home key */
    0,	/* Up Arrow */
    0,	/* Page Up */
  '-',
    0,	/* Left Arrow */
    0,
    0,	/* Right Arrow */
  '+',
    0,	/* 79 - End key*/
    0,	/* Down Arrow */
    0,	/* Page Down */
    0,	/* Insert Key */
    0,	/* Delete Key */
    0,   0,   0,
    0,	/* F11 Key */
    0,	/* F12 Key */
    0,	/* All other keys are undefined */
};

// Command line stuff. A 256 character buffer holding each character entered to
// be compared with the commands.
// THIS SPOT IS A LIKELY CULPRIT
unsigned char *cmdbuff[255];
unsigned int cmdbcnt = -1;

// COMMAND LIBRARY
unsigned char *uptime[2] = { 'u', 'p', 't' };

void keyboard_handler(struct regs *r)
{
    unsigned char scancode;

    scancode = inportb(0x60);

    if (scancode & 0x80)
    {
    // TODO: Shift, alt, ctrl support
    }
    else
    {
        putch(kbdus[scancode]);
        // command parser!
	cmdbcnt++;
	cmdbuff[cmdbcnt] = kbdus[scancode];
        // THIS SPOT IS A LIKELY CULPRIT
	if (kbdus[scancode] == '\n') {
		if (!kstrcmp(*cmdbuff[0], *uptime[0]) && !kstrcmp(*cmdbuff[1], *uptime[1]) && !kstrcmp(*cmdbuff[2], *uptime[2])) {
			puts("Uptime: ");
			puts(uptime_days);
			puts(" days, ");
			puts(uptime_hours);
			puts(" hours, ");
			puts(uptime_minutes);
			puts(" minutes, ");
			puts(uptime_seconds);
			puts(" seconds.\n\n");
		}
        cmdbcnt = -1;
	}

    }
}

void keyboard_install()
{
    irq_install_handler(1, keyboard_handler);
}

[eddyb]

1: unsigned char *uptime[2] = { 'u', 'p', 't' }; an array has values with indexes from 0 to n. well, your array has three elements, and when you declare it you should say how many elements is has. that means n+1 or 3 in your case.
2: !kstrcmp(*cmdbuff[0], *uptime[0]) && !kstrcmp(*cmdbuff[1], *uptime[1]) && !kstrcmp(*cmdbuff[2], *uptime[2]) this is equivalent to: (cmdbuff[0] == uptime[0]) && (cmdbuff[1] == uptime[1]) && (cmdbuff[2] == uptime[2]) so, if you want to compare strings: have a strcmp function like this:

Code: Select all

int strcmp(const char *s1, const char *s2) 
{
        char x;
        for(;;) 
       {
                x = *s1;
                if(x != *s2)
                        break;
                if(!x)
                        break;
                s1++;
                s2++;
        }
        return x - *s2;
}

and use !strcmp(cmdbuff, uptime);

[DrLink]

kstrcmp() is a strcmp clone.

Apologies for my stupidity. Coding late at night (and breaking a yearlong streak of not using C, but PHP, which rots the brain) is not necessarily a good idea.

Oh, and to those who said I wanted other people to do the work for me... no. When I said technical manuals, I was referring to things such books containing nothing more than the Intel x86 ASM opcodes. A book telling me opcodes isn't going to make much sense to me until I've seen each opcode used in different contexts to know exactly how it works. Things like that don't work for me, so I learn through example and when I'm coding, sometimes through trial-and-error.

[Troy Martin]

Apology accepted. Here are all 20 MB of the current Intel manuals:

http://download.intel.com/design/proces ... 253665.pdf
http://download.intel.com/design/proces ... 253666.pdf
http://download.intel.com/design/proces ... 253667.pdf
http://download.intel.com/design/proces ... 253668.pdf
http://download.intel.com/design/proces ... 253669.pdf

They should come in handy!

Oh, and BTW, Combuster can seem a little cold sometimes, but the way he puts the points across is actually a good way (except this time was a little overboard.)

[DrLink]

Now that my OS is back on its feet with a successful command interpreter, I've got the right idea where to go from here. I think...

I'm going to take those links as a joke, Troy.

Anyways, my next priority is to take said command line and add character removal (and not DOS style character removal, because that was hell for me to understand in the golden days). I'll also be looking more into the FAT12 driver. The kernel now knows how to detect floppy drives, now I need a direction to go in to do the following:

Detect a floppy drive: Check.
Send the appropriate signals to the floppy drive to detect the filesystem: Maybe I know what I'm doing. I think a document would help here.
Once FAT12 is detected, make the disk accessible (mount it) and load a directory listing: No idea.
Display said directory listing: That's the easy part... I hope.

At this point, I've explained myself thoroughly, so all I can say here is: help?

[Troy Martin]

Don't treat the manuals as a joke, they really do come in handy. I've referred to them a lot while working on my OS.

Ask anyone!

[DrLink]

Oh, you know what I mean! They're great if you already have a little bit of experience.

[pcmattman]

Coding late at night (and breaking a yearlong streak of not using C, but PHP, which rots the brain) is not necessarily a good idea.

Then maybe do it when you're not so tired?

I was referring to things such books containing nothing more than the Intel x86 ASM opcodes

The Intel Manuals are not books full of opcodes, contrary to how it seems you view them. Volumes 2A and 2B are the opcode reference, Volume 1 is the basic architecture (which is like a basic summary), 3A and 3B are the "System Programming Guide". In 3A and 3B you find a wealth of information about practically everything relating to the CPU.

I'm going to take those links as a joke, Troy.

And then you ask for help? Take what you're given, and maybe try and do some research for yourself. You might be surprised with the result:

Send the appropriate signals to the floppy drive to detect the filesystem

Google "floppy driver osdev" and you'll almost be able to find one for free. Take some time to look around. Also, floppy drives don't know what a filesystem is.

I think a document would help here.

Google it. Look around on osdever.net if Google's too hard.

Once FAT12 is detected, make the disk accessible (mount it) and load a directory listing

No idea!? You know precisely what you're looking for: FAT12! Search for documentation relating to FAT! Google, again, will help here.

so all I can say here is: help?

STFW, RTFM, and do something for yourself.