Page 7 of 8

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 4:08 pm
by DavidCooper
Have a look at this thread, and in particular the second last post:-

http://forum.osdev.org/viewtopic.php?f= ... 1&start=45

In this case it was a USB flash drive, but a USB hard drive should behave the same way.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 4:16 pm
by DavidCooper
guyfawkes wrote: Should that not be

Code: Select all

  TIMES 510-($-$$) DB 0

	  DW 0xAA55
But than again, i use fasm.
I wouldn't know, but Bochs should have objected if the boot sig was in the wrong place, unless Romfox went to the trouble of ticking a well-hidden box to tell it to ignore it.

Edit: looks like I misunderstood that - I'm guessing it actually means he's filling the sector with 510 nops (144) followed by the boot sig before anything else gets written on it, and you're suggesting changing it to 0s. That shouldn't make any practical difference then.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 4:56 pm
by romfox
I'm sure it is 512 bytes, and I posted all my code. Writting to the USB HDD I use dd as I said.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:05 pm
by DavidCooper
I missed that bit:-
I use copy /b boot.bin+kernel.bin OS32.img
And dd if=OS32.img of=\\.\g: (cause Windows)
I don't understand it though (which doesn't imply that I think it's wrong in any way - it's just beyond my knowledge). What I still want to know is, where on the disk is your bootsector being written by this? Is it going into an ntfs partition?

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:10 pm
by romfox
No this is what "dd --list" tells me about my HDD : "Mounted on \\.\g:" and I have tested it overwrittes 1st sector and MBR. So it's not writting to any partition.

Edit : it is the same that "dd of=/Dev/sdc" by example.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:15 pm
by DavidCooper
So it should probably behave like a floppy disk. If that's the case, do you have BPB values which fit with it being a floppy disk, and have you split the loading code to 17 sectors the first time, then 18, then 15?

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:24 pm
by romfox
I don't understand what you said. I don't want to use a BPB now as someone told me it's not necessary on HDD emulation. Now it doesnt boot anything and launch Windows...

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:28 pm
by DavidCooper
Something you might want to try is testing your machine with other people's code, such as the code I pointed you to on these pages:-

http://board.flatassembler.net/topic.php?t=12389

http://forum.osdev.org/viewtopic.php?f= ... 1&start=45 (2nd last post).

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:31 pm
by DavidCooper
romfox wrote:I don't understand what you said. I don't want to use a BPB now as someone told me it's not necessary on HDD emulation. Now it doesnt boot anything and launch Windows...
If you write your bootsector over the MBR, most machines will treat the disk as if it is a floppy drive, and a BPB will probably be required because it's communicating via USB. If you were writing your bootsector code into a partition instead and leaving the MBR intact, it would then be treated as a hard drive and a BPB might not be required.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:35 pm
by romfox
So I have to let the MBR created by formatting and write after it?

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:44 pm
by Combuster
Let's get this whole mess of stupid suggestions over with:

Code: Select all

%define KSIZE   17 ; nombre de secteurs a charger
Reads can not cross track boundaries, so I turned it down to 17 (sectors 2-18)

Code: Select all

; initialisation des segments en 0x07c0
Comment has not been updated

Code: Select all

;    mov esp, 0x9F000
    mov esp, 0x1000
Get out of the bios area

Code: Select all

;    mov [edi], bl
    mov [di], bl
GPF with the top 16 bits of edi being nonzero. In other words, your debugging code was breaking more stuff.

Anyway, that fixed it for floppy boot. USB boot will probably work with those changes as well.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 5:49 pm
by DavidCooper
As soon as this became a loading issue, it went beyond my knowledge, so all I can do is point you towards solutions that other people have come up with - if you follow the links I gave you you'll find out how they did it, though one of them only gives a solution which treats the drive as a floppy, and I'm guessing that that would restrict you to using just 1.44MB of it.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 6:09 pm
by romfox
Using EXACTLY the code I posted on page 4, it doesn't spawn anything now, how can it do that ?? Gonna burn my computer x_x.
Adding the Combuster's tips (don't know the correct word), it do the same (don't spawn enything, even my boot message x_x).

='( Is that a solution that my computer hates me ? Cause before (before all my post), all was working nice, I was creating keybd driver and others. And from a day to another, it didn't work... And now it do the same...

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 6:14 pm
by DavidCooper
Combuster wrote:

Code: Select all

;    mov esp, 0x9F000
    mov esp, 0x1000
Get out of the bios area
Many EBDAs start at 9F000 - I assumed that Romfox had checked this with his machine as he'd chosen this very specific value. Even if that's the case, he will indeed need to put the stack somewhere else if he intends to run his code on other machines.

Re: Problem on real hardware

Posted: Wed Dec 07, 2011 6:16 pm
by DavidCooper
romfox wrote:Using EXACTLY the code I posted on page 4, it doesn't spawn anything now, how can it do that ?? Gonna burn my computer x_x.
Adding the Combuster's tips (don't know the correct word), it do the same (don't spawn enything, even my boot message x_x).

='( Is that a solution that my computer hates me ? Cause before (before all my post), all was working nice, I was creating keybd driver and others. And from a day to another, it didn't work... And now it do the same...
Hey, don't get angry with the machine - it's giving you a great workout and teaching you how to debug. You're lucky to be having such difficulty. Probably best to put it away for now and have another go tomorrow.