Hi, On Tue, Jul 15, 2003 at 03:44:43PM +0200, Koala GNU wrote: > 2) Another step is to move the parameters table from 0x78:0 to > 0x9000:0x4000-12. WHat are > the info contained in this table? Can you send me a link to a site that > specify these info? 0:0x78 (physical address 0x00078) is really an address to an entry of the Interrupt Vector Table (IVT). Each entry in this table simply consists of a segment:offset pair specifying the entry point of the corresponding interrupt handler. Hence each entry is 4 Bytes long (16-bit segment + 16-bit offset). Interrupt 0x1E (0x78/4 = 0x1E) is an exception to this rule. It contains the address of the so-called Disk Initialization Parameter Table (DPT) Vector. An elaborate book on PC hardware should explain its details. So bootsect.S moves 12 bytes from the offset specified at 0x00078 (assuming segment 0?) to 0x93ff4 (right above the recently set up real mode stack). The following code then sets byte 5 (offset 4) of our new DPT to 36, as explained in the comment above the code. Instead of manipulating the original DPT, its address is simply updated to offset %di (0x3ff4) and segment %es (INITSEG=0x9000): > movb $36, 0x4(%di) # patch sector count > movw %di, %fs:(%bx) > movw %es, %fs:2(%bx) I hope that helps. By the way, there is still a line in the bootsect.S code I do not understand. In the kernel sources of version 2.4.18 it is line number 318: # here %cx contains the number of sectors read 312 shlw $9, %cx # %cx * 512 = number of bytes read 313 addw %cx, %bx # bx + bytes_read = new buffer offset 314 jnc set_next_fin # segment overflow? 315 movw %es, %ax # increment %es 316 addb $0x10, %ah # to point to 317 movw %ax, %es # next segment 318 xorw %bx, %bx # reset %bx??? 319 set_next_fin: 340 ret This code segment is part of the set_next procedure, which updates the buffer address (%es:%bx) for successive reads from the diskette. In case of a segment overflow the buffer segment %es is incremented appropriately, while the offset %bx is set to 0, although IMHO it should already contain the correct offset into the next segment. I guess it doesn't really matter, because the number of setup sectors needed for an overflow like that would have to be above 2^(16-9)-1 = 127 sectors, but SETUPSECTS is currently only 4. Still I would like to know whether I am right or wrong. So if there is anybody out there who is interested in discussing the floppy boot-record code, please contact me. with kind regards, Clemens Buchacher -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/