Not able to jmp to kernel at sect2

[FORTRANS]

Hi,

   I modified Dave's boot sector code, and got rid of the error
messages in Windows 2000.  The following code block shows
the last change that fixed things.

Code Select Expand


;---------------------- branch to executable code

        ORG     0

Boot0:  jmp short Boot1
        NOP     ;           Mods to deadndave's code: Win2K error fix
;---------------------- OEM identifier

        ORG     3


Regards,

Steve N.

[dedndave]

i ORG'ed to 7C00h in the boot sector dis-assembly because that is "real-world" - lol
there are a couple ways to handle the problem
one way is to create an offset EQU and add it to all the variable addresses
example:

Loader_Offset EQU 7C00h
.
.
.
        ORG     3

BW7C03  DW 512  ;bytes per sector
.
.
.
.
        MOV     AX,Loader_Offset+BW7C03

another approach is to create dummy labels

        ORG     7C03h
BW7C03  LABEL   WORD
        ORG     7C05h
BB7C05  LABEL   BYTE

notice that they do not use DW ? or DB ?
with masm v 5.10, it tried to create data for DW and DB, even if it was a "?"
i had to use LABEL
i don't know how that works out with masm 6.1+ yet - haven't got that far
here is the thing, Steve
even if we place the bootloader in the floppy data area, we have to be able to access sectors directly
so that we can insure it is written in successive sectors (assuming it is eventually larger than 512 bytes)
if we can't use INT 13h under XP, we need to try INT 26h
INT 25h and INT 26h are a little tricky - they leave the pushed flags on the stack
you could pop them off without altering the desired flags by using

        INT     26h         ;DOS absolute sector write
        POP     [SP-2]      ;similar to ADD SP,2, but does not alter the flags

if INT 26h doesn't work, we need to find a way to tell XP we need permission
i guess i could disassemble FORMAT.EXE, but that is a lot of work - lol
it's not just data sectors, either
we may need to examine and update the root directory and FAT's directly in order to write consecutive sectors

[MichaelW]

IIRC there is no problem with low-level access to a floppy drive, read or write, from a DOS app running under Windows XP. I know that there is no problem with Windows 2000 (although I don't recall testing this from a limited account).

[FORTRANS]

Hi,

   Right, the DOS utility I was using does Int 25H reads, and
now works properly, given some vague definition of proper.  So
I presume other low-level access is also available as well.

Steve

[zak100]

Hi Steve,
I tried your commands. First I added nop at the point you showed and then I wrote using debug, even by changing the order. But each time I was not able to beyond 'A'. Any way thanks for your guidance. I still need more help in this regard.


Zulfi.

[FORTRANS]

Hi,

   Well this gets down to the sausage making I mentioned
in another thread.  Start adding code to see where things
go bad.  Suggestion to add in the boot sector.

Code Select Expand


;---------------------- failed 5 times - halt

;---------------------- display 'F' character
; Show the failure occured.

        mov     ax,0B800h
        mov     es,ax
        mov     DI,4    ; Move a bit to avoid the 'A'
        mov     ax,3C46H
        stosw

Halt0:  jmp     Halt0


   Suggestion for the boot load.

Code Select Expand


Start:  push    cs
        pop     es

; - - - Make it obvious that we got this far, clear the screen. - - -
        MOV     AX,3    ; Function 0, mode 3.
        INT     10H
;---------------------- writing a message on screen at startup - we can't use int 21h


   Next would be print out part of what the boot sector loaaded,
in the boot sector code, to see that it got the right stuff.

HTH,

Steve N.

[zak100]

Hi,
I am not able to understand your suggestion about boot sector. Its printing 'A',fine. We have to check whether it jumps or not. I would try something in boot loader, maybe what you have suggested. In the meantime, if any other thing clicks in your mind, let me know.

Zulfi.

[dedndave]

that is a good idea, Steve
in fact, you could write a little code to show the "data" (i.e. code) at 1000:0000 after it is read
in other words, the boot sector is working, so let's use it as a tool
after the bootloader is read into memory, you could display the first few bytes of it in hex before jumping to it

[FORTRANS]

Hi,
I am not able to understand your suggestion about boot sector. Its printing 'A',fine. We have to check whether it jumps or not.

   Exactly.  It prints the 'A', then tries to read the diskette
to load the code to jump to.  Does it succeed?  If you look
in Dave's posted boot sector in Reply #14, and look at the
comments, you should see where to put the new code I
posted to flag if the diskette read failed 5 times.

I would try something in boot loader, maybe what
you have suggested.

   Good, keep us up to date.

In the meantime, if any other thing clicks in your mind, let me know.

   Well, that is what Dave and I were talking about.  Printing
some of what is actually in the memory where it is going to
jump to.

   The code from Dave, plus the two fixes, and the change to
a 720K diskette works for me now without error.  So I can not do
much to help find the error you still have except suggest things.
When I had the same problems you reported, I could try out
various things here to try and fix things.  If the suggestions I
made don't help, I will try and find a spare 1.44 diskette, but I
doubt that is the problem.

Regards,

Steve

[sinsi]

You are still using a DOS BPB. Two options -
1. call your file io.sys and use a standard dos5+ floppy
2. ignore dos and write the second stage to sector 0/0/2

I still think you are limiting yourself by using masm.

[FORTRANS]

Hi,

   To expand on sinsi's reply, 1. IO.SYS is loaded by the
standard DOS boot sector.  Make sure you use only a
freshly formatted diskette, and copy your binary code
to the diskette as IO.SYS.  Not sure if you then need an
MSDOS.SYS as well.

   2. Writing to the second sector, as we are doing now,
screws up the FAT and a marker byte in the FAT is used
to determine if the diskette is valid to use.  So to reuse a
diskette, we now need to reformat it to copy to it.

Regards,

Steve

[z941998]

Even if a floppy has data on it you can still make it a bootable disk after this fact, because the area is reserved, so formating it, doesn't matter at this time.

Also, when writing boot sectors there are different IDs used versus the FAT IDs usage to indicated that sectors have been used.  Make sure you are using the correct ones at the correct times.

If you are overwriting the FAT area then you are writing to many bytes or starting at the wrong point.  The two reserved sector are in a fixed sized (512 bytes) format.

Peter Norton's book on assembly is a good reference for the floppy and creating a bookable diskete, no matter what os you are running / creating.

[dedndave]

when the floppy is booting up, the BIOS knows nothing about FAT's
it knows nothing about the floppy at all, really
it simply loads the first sector of the floppy to address 0000:7C00 and executes it
it doesn't even know the sector size, although all DOS floppies have always used 512 byte sectors
BIOS cannot handle sector sizes larger than 512 bytes, but they can be smaller
at that time, there is no DOS installed - no comprehension of FAT's or root directories, for that matter

the problem we are encountering is simple
newer OS's are not letting us write to the FAT area
older OS's allow it
it is an access permission issue

i was thinking we may be able to trick the OS by telling it (in the BPB) that there is no FAT
so:
1) write a temporary boot sector to sector 1 that has a BPB with FAT sectors and number of FAT's set to 0
2) reset the disk system
3) write our code to sector 2
4) write the final version of the boot sector to sector 1

the thing is, eventually we will want to write files to the data area in contiguous sectors
in order to insure that happens, we are going to want to access the FAT and root directory areas
we may have to use the same trick again

when i get some time, i want to write a new boot sector
if there is enough room, i may try to design it so that the "IO.SYS" code may be anywhere on the floppy
hopefully, the only requirement will be that its' directory entry be in the root directory
that code will have to interpret enough of the FAT to find the first couple data clusters of IO.SYS
then, we can just copy it over there and let the OS decide which data clusters to use
when IO.SYS takes over, it can start with code that reads the rest of itself into memory
i have another project that i have to finish before i can get back to playing with this

[zak100]

Thanks you guys. Actually I am getting slow on this. I have to do some urgent work. It would take atleast four days. i would try my best to try what you people have suggested during these days if I get time. But  I am not leaving this task unfinished only deferring it for sometime. Actually once i got the code using nasm. It was a 2 stage kernel and I was following the same steps which I am doing now. I dont know how it worked with nasm. I would try to send an attachment of this code also as soon as I get time.

Zulfi.

[z941998]

DeDnDave/Zara is right.  One thought, if newer systems dont allow individual sector writes as described, then how about track writes, but then you have to consider the CRC stuff inbetween the sectors also and the track flags also, which is a more difficult task to accomplish and keep under control.  Note security uses this technique to ensure a fully erased disk, because it rotates data on the disk every time it is activated.

Another option is your hardware (Floppy) has a specific chip on it.  Using that chip as a reference you can send it the commands necessary to perform the dos functions you need and therefore wouldn't need to reboot your system inbetween disk writes.  Manufacturing (Chip) info and commands are freely available, so all you have to do it figure out which one you have and then select / find the address stuff, and then bypass the OS when performing these tasks.