Three diffrent emulators show three diffrent outputs

[Schol-R-LEA]

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).

Brendan, I know you are one of the ones who have some delusion that someone other than yourself will use your operating system one day, but frankly, for most of the people here, their code will never run on live hardware, nor should it. And yes, that includes myself. This is a hobby, not life and death. Anyone who thinks otherwise, thinks that they will ever write something of consequence in this space, is fooling themselves. To the best of my knowledge, the only person here who has done anything like that is rdos, and even that's being incredibly generous. Even the ones that actually got some attention elsewhere such as SkyOS and MorphOS were seen as novelties by outsiders, not something anyone would actually use.

I would love to see my own ideas spread, my own system run by others, but guess what? Chances I am never even going to get it written at all, never mind get to a release stage. And do you know what else? If you do any better, I will be amazed.

Having said that, I think it would be best if I drop out of the group, at least for a while. Not exactly a rage-quit, as the only one I am really angry at is myself for letting my frustration get the better of me, but I couldn't blame anyone for seeing it as one. The fact is, participating in this group is actually interfering with my OS development hobby, and that is the point where I have to ask myself if I really want to continue with any of this.

[Brendan]

Hi,

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).

Brendan, I know you are one of the ones who have some delusion that someone other than yourself will use your operating system one day, but frankly, for most of the people here, their code will never run on live hardware, nor should it. And yes, that includes myself. This is a hobby, not life and death.

The fact is that almost everyone hopes their code will run on real hardware one day; and this is why they choose platforms like 80x86 (which is full of "warts" due to backward compatibility, etc). It has nothing at all to do with any delusion of other people using the OS. It has everything to do with the challenge of dealing with reality, and taking pride in what you've achieved.

If people only want their OS to run inside an emulated virtual machine, then it'd be far more sensible to choose virtual machine without all the hassles that real hardware (especially 80x86) has - e.g. maybe Java's virtual machine (and not 80x86 PC).


Cheers,

Brendan

[Ycep]

After repairing PIT (Yay!) i finally fixed my driver for keyboard in VirtualBox, but my PIT seem to make IRQs very slow. 50 miliseconds durates 1 second and 1 second durates about 2 to 3 minutes.

And my biggest problem is : floppy. I updated my code for floppy, can anyone just look at it?

[Brendan]

Hi,

After repairing PIT (Yay!) i finally fixed my driver for keyboard in VirtualBox, but my PIT seem to make IRQs very slow. 50 miliseconds durates 1 second and 1 second durates about 2 to 3 minutes.

You don't say which emulator/s are running slow. For Bochs; it's relatively common for people to misconfigure the emulator (e.g. set it up as "deterministic, real time != virtual time" and get their "IPS" wrong) and end up with what they asked for (e.g. virtual time happening much much slower than real time). Other emulators aren't as (mis)configurable, so if PIT is running slow in those (or on real hardware) it's more likely to be a bug in your code.

And my biggest problem is : floppy. I updated my code for floppy, can anyone just look at it?

In theory; given enough time, anyone can probably hack into your computer or break into your house, search through all your stuff, and end up looking at your updated floppy code. In practice nobody will bother to do this because it's too much work (until/unless you make it much easier for anyone to see the updated code - e.g. by posting the code and/or providing a link).


Cheers,

Brendan

[Ycep]

Brendan,
Sorry i forgot to post which emulator in my reply, but it's in post. It's name is VirtualBox.

Updated floppy driver is in post. Why do you skip pages? Check page 1 and scroll up. There is small text which says:

Floppy driver:
http://forum.osdev.org/viewtopic.php?f= ... 23#p260323

It's standing here almost from beginning of this post. Every time i change my floppy driver code i post it at that address. It's updated.

None doesn't need to break in my house and most of people here are living in USA/Deutschland/مصر, which is pretty far from me (Except deutschland) ;

[Brendan]

Hi,

You don't say which emulator/s are running slow.

Sorry i forgot to post which emulator in my reply, but it's in post. It's name is VirtualBox.

Is it VirtualBox and none of the others, or VirtualBox and all of the others, or...?

If it's VirtualBox and none of the others then I can't think of a likely explanation. If it's VirtualBox and other emulators then it's possible you set the PIT frequency higher than the computer can handle. In either case; I haven't seen any of the code, don't know what frequency you've set the PIT to, can't know if something completely unrelated is disabling IRQs for a long time (and causing timer IRQs to be missed), etc; so I can only make "random" guesses.

It's standing here almost from beginning of this post. Every time i change my floppy driver code i post it at that address. It's updated.

Then stop doing that. Nobody knows that's what you've done, or when you've edited, or why you've edited; and by changing old posts you break older topics because the old replies from other people are now talking about code that is gone and/or significantly different.

So far I've seen 2 different descriptions for "floppy driver problems". The first (in a different thread) was caused by a typo (wrong IRQ number) and is solved. The second (from this thread) was trying to read a sector that didn't exist (sector 0) and is solved. I have no idea what problem we're looking for now.

Note that your new floppy code is still "reckless" and still contains most/all of the problems I already mentioned. Because the code does no error checking at all; I doubt you're capable of describing the symptoms of the problem you're having in a way that is actually useful. For example, rather than being able to say something like "the floppy controller status says "address mark not found" after I try to read a sector" or "I get a time-out from the "WaitIRQ()" during floppy driver initialisation/reset" (which provides everyone including you with important clues to diagnose the problem) you're saying things like "it hangs" and "there's a problem" (with no useful information). If you can't describe the symptoms of the problem properly (because you don't have any information because your code is reckless and does no error checking), then it ends up being like (e.g.) ringing the police department and saying "A crime happened" and hanging up without saying what, or where, or...

In other words, you're asking us to do a lot of extra work to find a problem (because there's no clues/information) simply because you're too lazy to fix code that you've already been told needs to be fixed.


Cheers,

Brendan

[Ycep]

OK, i get it. I knew that none would see that!
Only VirtualBox has slower PIT. I just put frequency to 100hz, that isn't big amount (Isn't it?). If i set bigger it's still slow for VirtualBox - like it override that setting - but if it override, how could PIT actually work? Did anyone had similar issues with VirtualBox?
The problem is that i can't find what's problem with my floppy driver reading a LBA/CHS sector.
It only return 512 zeros. How could i know what's problem when most of FDC commands don't share the error - maybe i put functions at wrong place, so check it:

• Select drive

• Recalibrate

• Seek to required track and head

• Initialize Floppy DMA to 131072, since i don't use that part of memory

• Set DMA channel to 2

Code: Select all

SendCommandByte(Read|MT|SK|MF);
SendCommandByte((Head<<2)|CurDrive);
SendCommandByte(Track);
SendCommandByte(Head);
SendCommandByte(Sector);
SendCommandByte(2);
SendCommandByte(Sector+1);
SendCommandByte(0x27);
SendCommandByte(0xff);

• Wait for IRQ

• Read data byte 7 times "to make FDC happy" since it isn't required

• Return 131072 as address

[Ycep]

Seem i put true instead of false in WaitIRQ();
However, now seem that IRQ won't fire while reading a sector - but it fire at initiailization!
There is definetely not problem in PIC - it works for everything else!
Code updated.

[Brendan]

Hi,

Only VirtualBox has slower PIT. I just put frequency to 100hz, that isn't big amount (Isn't it?).

100 Hz should be fine (not too fast). I still can't see the code for this; and can't (e.g.) check if something completely unrelated disables IRQs for a very long time.

It only return 512 zeros.

Emulators are supposed to emulate real hardware. The correct behaviour for real hardware is for the floppy drive controller to return a read error because the disk isn't spinning fast enough (because you turn the motor on and don't give it time to reach operating speed), and to read no data from disk at all. In this case the zeros you think you're reading would be zeros that were in memory before you failed to read anything.

Mostly; the symptoms you describe are exactly what should happen on real hardware, and therefore exactly what should happen on emulators. With that in mind, maybe VirtualBox is "more correct" than the other emulators; and you should be asking why your code doesn't do the same on the other emulators.

Note that floppy disks are "notoriously unreliable" and (even for correct code) you'd want to do 3 retries before giving up (rather than giving up after the first error, and rather than assuming everything worked perfectly after the first error).


Cheers,

Brendan

[Ycep]

Thanks Brendan but what about waiting for IRQ?
I set it to wait 2 seconds for small floppies (3.5) and 3 seconds for big floppies (5.25). No diffrence.
I accidentally put "true" instead of "false" and that's the reason it probally readed 512 zeros. Now when i fixed that, waiting IRQ always time out, except at initialization.
I'm 100% sure that PIC works perfectly, since it works for Usermode, PIT, IDT, Keyboard, etc.
I'm 100% sure that my PIT isn't working perfectly since it's very, very slow on VirtualBox and excellent on Bochs.
So basically, my problem is : Floppy IRQ.
Now trying to find what's wrong with it...

[Brendan]

Hi,

So basically, my problem is : Floppy IRQ.
Now trying to find what's wrong with it...

Try changing this:

Code: Select all

static bool IRQFire = false;

To this:

Code: Select all

static volatile bool IRQFire = false;

Cheers,

Brendan

[Ycep]

Nah. If anyone else doesn't see problem, can anyone give me some resource for CD drivers, including for real mode?
Also, which filesystem CDs use?

[neon]

Filesystem parsing has nothing to do with file formats. You need to be able to know the format of the executable file and how to parse it. Your boot loader already does this - so what do you intend to do when/if there is a bug?

CD's use ISO 9660 which is much simpler to work with then FAT since you have 2048 byte sectors and all files are contiguous since the file system is read only (no need for an allocation table. Just get start sector and read it in.)

The Wiki of course has good information that you can look at. If I find a copy of my vbr, I can provide a link to it as well for your reference. Note that if you decide to go this route, you will need to implement ISO 9660 support in both the boot record and boot loader, followed by the kernel.

To support CD's in your kernel, you need ATAPI (assuming the CD device isn't SATA.)

"Just please don't give me anything hard" -- You are making an operating system. It is always going to be hard at first. And as long as you keep skipping things (How do you not know how to parse a PE yet have a working boot loader that does just that?) its going to continue being hard.

[Ycep]

No - oh sorry, i wrongly wrote my reply. I meant just documentation for real mode and protected mode. I know that filesystems doesn't depend on file formats, and it's easy to make it load PE executable.
I understand whole bootloader, don't make that assumptions. I accidentally added that "bootloader for PE files"
As i always mention : "Just forget it."
If i even don't understand and don't know, it's still just a little bit better than using Grub, isn't it?
I don't copy paste your demos since 1 month or more. I write it by myself - and most things from demo got rewritten by me until version 0.0.1 was released.
P.S. just readed wiki page for ATA/ATAPI using DMA - Wow, this seems lots easier than floppy driver!

[Ycep]

Is there any possibility to read CD ATAPI through interrupts in real mode?
I'll try to find the problem of floppies for one week, and will be waiting if anyone else finds it out...