Three diffrent emulators show three diffrent outputs

[Ycep]

Hi, now when my OS got little bit complexier (But still boots for less than a second), every emulator have three diffrent outputs for my OS:
Bochs(PARTIALLY FIXED)

• reading first LBA sector 0 just gives 512 zeros.

VirtualBox (PARTIALLY FIXED)

• PIT is too slow; 50 miliseconds durates 1 second, and 1 second durates ~2-3 minutes.

• reading first LBA sector 0 just gives 512 zeros.

PCem 10.1
It don't boot; halts at floppy controller initialization.
Floppy driver:
http://forum.osdev.org/viewtopic.php?f= ... 23#p260323

Any solution?

[BenLunt]

All emulators are not perfect, and can not emulate exact hardware. However, as for the three items you mention below, they emulate them well enough.

You must have multiple items causing multiple problems, which is a pain when trying to narrow down to what it actually happening.

If I were you, I would choose one problem, write some code to test only that problem, deactivating any other code, until you have solved
that particular thing.

Without more information, we here can only speculate.

Good luck and let us know (with more detail please) how we can help,
Ben

[Octocontrabass]

reading sector 0 of cylinder 0 of head 0 gives two panics

You can't read a nonexistent sector. Perhaps you need to read more about CHS addressing.

[BrightLight]

Hi, now when my OS got little bit complexier (But still boots for less than a second), every emulator have three diffrent outputs for my OS:
Bochs
It boots; keyboard works; reading sector 0 of cylinder 0 of head 0 gives two panics : logical sector out of bounds and could not perform lseek() to -512 on floppy image file.
VirtualBox
It boots; keyboard doesn't work.
PCem 10.1
It don't boot; halts at floppy controller initialization.

You can't expect us to guess what is wrong; where is your code? As Octocontrabass has already mentioned, you can't read a non-existent sector. In CHS addressing, heads and cylinders and numbered from 0, while sectors are numbered from 1, as opposed to LBA addressing, in which sectors are numbered from 0.
The PS/2 keyboard is probably the simplest device to program; how is it you have written a floppy driver without a proper keyboard driver?

[Ycep]

Hi, now when my OS got little bit complexier (But still boots for less than a second), every emulator have three diffrent outputs for my OS:
Bochs
It boots; keyboard works; reading sector 0 of cylinder 0 of head 0 gives two panics : logical sector out of bounds and could not perform lseek() to -512 on floppy image file.
VirtualBox
It boots; keyboard doesn't work.
PCem 10.1
It don't boot; halts at floppy controller initialization.

You can't expect us to guess what is wrong; where is your code? As Octocontrabass has already mentioned, you can't read a non-existent sector. In CHS addressing, heads and cylinders and numbered from 0, while sectors are numbered from 1, as opposed to LBA addressing, in which sectors are numbered from 0.
The PS/2 keyboard is probably the simplest device to program; how is it you have written a floppy driver without a proper keyboard driver?

Read whole topic. I posted that code already.

[Ycep]

reading sector 0 of cylinder 0 of head 0 gives two panics

You can't read a nonexistent sector. Perhaps you need to read more about CHS addressing.

Thanks, sectors start with 1, not zero. But now i have another problem : why is that sector full with zeros?

My keyboard code if anyone finds out problem (i shortened the code):

Code: Select all

void updateled(bool num, bool caps, bool scroll)
{
	extern void puts(char* str);
	while((inb(0x64)&2)!=0);
	outb(0x60,0xED);
	while((inb(0x64)&2)!=0);
	char x = num<<7|caps<<6|scroll<<5;
	outb(0x60,x);
}
void ReadKey()
{
	lastkey=0;
	if(inb(0x64) & 1)
	{
		char c = inb(0x60);
		int key = scancode[c];
		int tkey = tscancode[c];
		if(c&0x80)
		{
			c=c-0x80;
			switch(key)
			{
				case KEY_RCTRL:
				case KEY_LCTRL:
					CtrlKey=false;
					break;
				case KEY_LALT:
				case KEY_RALT:
					AltKey=false;
					break;
				case KEY_RSHIFT:
				case KEY_LSHIFT:
					ShiftKey=false;
					break;
			}
		}
		else
		{
			switch(key)
			{
				case KEY_RCTRL:
				case KEY_LCTRL:
					CtrlKey=true;
					break;
				case KEY_LALT:
				case KEY_RALT:
					AltKey=true;
					break;
				case KEY_RSHIFT:
				case KEY_LSHIFT:
					ShiftKey=true;
					break;
				case KEY_CAPSLOCK:
					if(CapsKey)CapsKey=false;
					else CapsKey=true;
					updateled(0,CapsKey,0);
					break;
			}
			if(ShiftKey) lastkey=tkey;
			else if(CapsKey&&key>96&&key<123) lastkey=key-32;
			else lastkey = key;
			if(c!=0)KeyReaded=false;
			****:;
		}
	}
}
void KeybInit()
{
	lastkey=0;
	CtrlKey=false;
	ShiftKey=false;
	AltKey=false;
	CapsKey=false;
	updateled(false,false,false);
}
char GetChar()
{
	ReadKey();
	if(!KeyReaded)return lastkey;
	else return 0;
}

Problem?
(please do not use sell my keyboard driver )

[Brendan]

Hi,

Read whole topic. I posted that code already.

I read the whole topic. You haven't posted any code for PS/2 keyboard.

For floppy, your code is "reckless". For some examples:

• Nothing ever checks for or handles any of the many possible error conditions, either from the caller (e.g. bad parameters) or from the device (e.g. disk not in drive, read error, etc).
• There are no time-outs for anything at all.
• There's no code to detect if a floppy drive exists, no code to detect if a floppy disk is in the drive and no code to detect the media format a disk uses (is it a 720 KiB floppy, a 1440 KiB floppy, a 1680 KiB floppy?).
• It turns a floppy motor on and doesn't give the drive any time to reach operating speed (assumes the drive can go from 0 RPM to 300 RPM in zero microseconds) before issuing commands that can't work properly when the drive hasn't reached its operating speed (and then assumes the command worked, including assuming that you always successfully read sectors from a disk drive that doesn't even exist).

Cheers,

Brendan

[Brendan]

Hi,

My keyboard code if anyone finds out problem (i shortened the code):

Compare this:

Code: Select all

void KeybInit()
{
	lastkey=0;
	CtrlKey=false;
	ShiftKey=false;
	AltKey=false;
	CapsKey=false;
	updateled(false,false,false);
}

To the initialisation sequence described here. Can you see any differences?

For a start, you're assuming the PS/2 controller exists, assuming the PS/2 controller hasn't been told to use IRQs, assuming a PS/2 keyboard is plugged in, not separating "PS/2 controller code" from "PS/2 keyboard code", assuming any/all data received by the controller came from the keyboard (and didn't come from a PS/2 mouse), not checking for or handling any of the many possible errors, etc.


Cheers,

Brendan

[Schol-R-LEA]

Hi,

Read whole topic. I posted that code already.

I read the whole topic. You haven't posted any code for PS/2 keyboard.

For floppy, your code is "reckless". For some examples:

To be fair to the OP, it is safe to say that the drives in question are emulated, and thus not bound to the limitations imposed by mechanical engineering. I agree that it is a poor practice, but it is an understandable short-cut when starting off, where you know that you are never going to run outside of emulation. More to the point, since it is emulated, it is unlikely that these flaws are relevant to the problem at hand.

However, this leads to the opposite question of, why develop a floppy driver at all? I have not seen a new PC with a built-in floppy drive in over a decade, and haven't seen a floppy disk in real life in almost as long. Unless you are rolling your own boot loader that only works for floppies, and then have to support said emulated disk afterwards, this is pretty much pointless; even if that is the case, you would then have to consider if it isn't worth writing a more general boot loader, instead.

It doesn't save you any real effort, either. While it is indeed easier to write a boot sector for a floppy drive than for a hard drive or most other kinds of disks, writing a fully-functional protected mode driver for a floppy disk drive is not. Indeed, for real hardware it is actually slightly harder, in part because you need to do many of the control and test operations manually (specifically the ones that Brendan mentioned) rather than being able to rely on the drive controller for most of them, as well as the problem of detecting when the user has mounted and unmounted a disk (this was especially true in the 5.25" drive days, but even 3.5" drives didn't always detect or report a disk change). It becomes a lot of work for supporting hardware you are unlikely to ever encounter outside of the emulator.

Now, it may be that you have a specific reason to support floppy drives, in which case I will withdraw my objection. However, if it is simply because you see them as easier to work with, I think you will find that you are mistaken about that.

[Ycep]

Anyways, i fixed my floppy driver already (Woohoo! Yay!), but it still do not work on PCem and noticed that sectors begin from 1, not from 0, but my keyboard is only problem i have now.
I don't use keyboard IRQ's. I made ReadKey() so it only checks keyboard when it need to check.
I know guys, i don't check for any errors because they would never appear (except on hammer-smashed keyboard/FDC chip, but my OS isn't designed for that keyboards/archiceture )
I didn't inited and even enabled PS/2 mouse, so it isn't threat for now.

[Ycep]

However, this leads to the opposite question of, why develop a floppy driver at all? I have not seen a new PC with a built-in floppy drive in over a decade, and haven't seen a floppy disk in real life in almost as long. Unless you are rolling your own boot loader that only works for floppies, and then have to support said emulated disk afterwards, this is pretty much pointless; even if that is the case, you would then have to consider if it isn't worth writing a more general boot loader, instead.

Oh ok, when i began with OS developement i should firstly make bootloader for CDs (just sarcasm).
I do things from floor to roof.
Anyways if i want to write operating system for CDs i would have to make bootloader for that and entire new driver for CDs (not in 0.0.2. version).
And yes, don't tell me something like "U can use grub".

[Schol-R-LEA]

Oh ok, when i began with OS developement i should firstly make bootloader for CDs (just sarcasm).

I was thinking in terms of writing a boot loader for a hard drive, actually. The emulators in question are all capable of emulating a hard disk using a file as the virtual drive. Writing one for CD-R is no wiser than writing one for a floppy, indeed I would say it is worse given that it is a write-once medium.

In an emulated environment, there is no real advantage to targeting removable media, unless you expect to move immediately to live hardware - a very, very bad idea all around. Unless your goal is to support a specific, unique real-time platform, focusing on live hardware is more of a distraction at this stage of development. While some would argue that it helps you avoid over-reliance on quirks of the emulators, this only shifts the problem; unless you are testing on several different systems with notably different hardware, you risk falling into the same kind of platform specificity.

I am not going to tell you to use an existing boot loader - I don't intend to, for my own reasons, after all - but I am curious as to why you don't want to. While I think that the boot loader is a useful exercise when starting out, in the long run it is a distraction from writing the OS itself. You don't have to have any reason beyond, say, wanting full control of the system (building it from floor to roof, as you put it - though I would not be straining that analogy if I were to say that the boot loader is less like the foundation of a house and more like the cement truck that pours that foundation), but it would help us help you if we knew your motives a bit better.

[Brendan]

Hi,

Anyways if i want to write operating system for CDs i would have to make bootloader for that and entire new driver for CDs (not in 0.0.2. version).

No. You can boot from CD without having a CD driver (in the same way that you can boot from floppy or hard drive or network without having drivers) because you can use the firmware (e.g. BIOS functions) to get everything you need into RAM before starting your kernel.

Also note that you can use "El Torito floppy emulation" to boot from CD; which means that if you already have a boot loader for floppy it should be relatively trivial to boot from CD (you wouldn't need to write another boot loader).


Cheers,

Brendan

[Brendan]

Hi,

For floppy, your code is "reckless".

To be fair to the OP, it is safe to say that the drives in question are emulated, and thus not bound to the limitations imposed by mechanical engineering. I agree that it is a poor practice, but it is an understandable short-cut when starting off, where you know that you are never going to run outside of emulation.

Emulators are supposed to emulate real hardware (and emulate limitations imposed by mechanical engineering). If someone is taking short-cuts like this then they are relying on bugs in emulators.

More to the point, since it is emulated, it is unlikely that these flaws are relevant to the problem at hand.

More to the point; with decent error handling the OP probably would've solved half the problems themselves without having to ask. The floppy controller provides useful information that (e.g.) makes it obvious what the problem is if you try to read a sector that doesn't exist. It's easier to figure out what the problem is with more information (e.g. where you get a time-out) instead of less information (e.g. "my floppy driver hangs (but I don't know where or why because there's no error handling)").

Now, it may be that you have a specific reason to support floppy drives, in which case I will withdraw my objection. However, if it is simply because you see them as easier to work with, I think you will find that you are mistaken about that.

Floppy is easier to write a driver for - one common "floppy controller" standard, fixed resources (IO ports, IRQs, etc), easy to find/read documentation and example code, etc. For hard drives there's multiple controller types and modes ("legacy mode PATA", "native mode PATA", AHCI, the entire unexplored "RAID controller" territory), a few variations of DMA controller, about 9 different transfer modes; then about 7 variations of "ATA specs" (for the hard drives themselves) with various optional features (locking, secure erase, native command queuing), different sector sizes, etc. For USB you have to start with PCI (enumeration, BARs); then there's several controller types; then USB device enumeration - all before you can start the USB storage device driver.

I was thinking in terms of writing a boot loader for a hard drive, actually. The emulators in question are all capable of emulating a hard disk using a file as the virtual drive. Writing one for CD-R is no wiser than writing one for a floppy, indeed I would say it is worse given that it is a write-once medium.

One of the nice things about floppy and CD is that you don't have to bother with partitions.

In an emulated environment, there is no real advantage to targeting removable media, unless you expect to move immediately to live hardware - a very, very bad idea all around. Unless your goal is to support a specific, unique real-time platform, focusing on live hardware is more of a distraction at this stage of development.

Eventually everyone wants to try their OS on real hardware; and if you rely on emulators and nothing else what happens is that as soon as you try it on real hardware you get bombarded by a massive number of problems and get so overwhelmed by how much your OS sucks that you're forced to throw everything away and start again from scratch. It's far easier to test regularly on real hardware (on as many different machines as you can get your hands on) and find the problems while you're working on the code, and prevent the "flock of failures" later.

While some would argue that it helps you avoid over-reliance on quirks of the emulators, this only shifts the problem; unless you are testing on several different systems with notably different hardware, you risk falling into the same kind of platform specificity.

If you test on no real computers and 4 emulators you'll find about 25% of problems. If you test on 1 real computer and 4 emulators you'll find 80% of problems; which is a massive improvement (mostly caused by emulators not emulating a lot of things properly; typically including things like device timing, caches, TLBs, SMP, CPU features like performance monitoring, power management, etc).


Cheers,

Brendan

[Ycep]

Hmmm, seem that my floppy driver isn't right. When it read sector it give only 512 zeros.
I'm currently diagnosing and trying to fix that.