FAT formatted disk
Craig Joyce
Tim Robinson
news:7e5f4e39.02012...@posting.google.com...
| Does a FAT formatted floppy contain information-bytes? If yes, how can I
read it?
It depends what you mean by "information". The amount of information on a
disk depends on the number of symbols stored there and the probability of
each symbol.
Consider the bits 1 and 0. If we know that a 1 occurs with probability 0.9
and a zero with probability 0.1, a disk containing all zeros contains far
more information than a disk with all ones. In this case the amount of
information in one bit is -log2(p), where p is the probability of that bit.
Therefore, in this example, a 1.44MB disk containing all zeros contains:
-log2(0.1) * 1474560 = 4898382 bytes
However, this relies on our knowing the probability of each symbol in
advance. While this approach is OK for things like data compression, in
general we don't know in advance the probability of each symbol occurring,
so we give them equal probabilities. If p(1) = p(0) = 0.5 then our familiar
1.44MB disk again stores 1474560 bytes.
Hope this helps*. Read a textbook on information theory for more. Also look
up Claude Shannon. For a practical example of this, learn the Huffman
encoding algorithm.
--
* It probably doesn't help at all, but that's what you get for asking a
vague question. :)
--
Tim Robinson
http://www.themoebius.org.uk/
debs
On 29 Jan 2002 08:16:02 -0800, Craig Joyce spake thus:
>Does a FAT formatted floppy contain information-bytes? If yes, how can I read it?
What do you mean by information bytes?
The boot sector contains information that the file system drivers can
use to determine how many sectors are on the disk, how many are used
by the FAT, how many copies of the FAT there are, how many root
directory entries there can be, and the disk geometry.
The FAT contains information about each cluster on the disk.
The root directory (and each subdirectory) conatins infromation about
directories and files under the directory being viewed>
is that the sort of data you are looking for, or are you looking for
the data that is read by the controller when looking for the start and
end of each sector and track?
--
debs
de...@dwiles.nospam.demon.co.uk
----
Misspelled? Impossible! I have an error correcting modem.
Craig Joyce
read it.
Someone uses John Fine's Partcopy.exe to write boot sectors to a FAT
disk. He also uses it to write a small 'hello world' .COM file (that
used BIOS) to the disk at a particular location.
Now, if he can be assured that there is nothing else on the disk,
except the boot sector and the binary file, it might be easy for him
to go ahead with developing a new file-system. But I really don't know
how to go about it.
"Tim Robinson" <timothy.rem...@ic.ac.uk> wrote in message news:<a36ic0$15qtc9$1...@ID-103400.news.dfncis.de>...
David A. Caabeiro
:-) maybe the OP was refering to the BPB? (not in the theoretical sense)
Greetings,
David.
Reply to: ac AT turdera DOT com DOT ar
--
Usenet is like a herd of performing elephants with diarrhea --massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it.
-- Gene Spafford
David A. Caabeiro
> Does a FAT formatted floppy contain information-bytes? If yes, how can I read it?
Do you mean a data area such as the BPB?
In that case the info is stored in the boot sector. There you have sector
size, total number of sectors in disk, sectors per track, etc.
Get the FAT specification.
Otherwise, read Tim's post.
David.
Reply to: ac AT turdera DOT com DOT ar
--
We had Joy, We had fun, We were fork()ing on a Sun,
but the joy is all gone, 'til the processes are Done [1].
Craig Joyce
> the data that is read by the controller when looking for the start and
> end of each sector and track?
I want to know what is left on a disk when you FORMAT it as a FAT
disk--not that boot-sector b.s. I mean, the OS itself says that all
data will be erased. But something must be left-- thats what I want to
know--read by the controller.
Alexis Christoforides
http://home.freeuk.net/foxy2k/disk/disk1.htm
I think you should be able to find a specification paper @ microsoft's too.
--
Alexis Christoforides
"Craig Joyce" <naught...@yahoo.com> wrote in message
news:7e5f4e39.02012...@posting.google.com...
debs
On 29 Jan 2002 18:20:22 -0800, Craig Joyce spake thus:
When you format a disk as a FAT disk, it leave information in the boot
sector which the file system can use to determine how many sectors,
heads and tracks (or cylinders) there are. It also tells you other
information to help teh file system driver determine where your data
is stored and what parts of the disk are used to store information
that is used by the file system.
If you take a look at my boot sector, it wil show you the data
structures that are on a FAT disk, with values that are specific to a
1.44M floppy disk drive.
<http://debs.future.easyspace.com/Programming/OS/bootsect.asm>
To get more information about what the different values can be, you
will need to do a search (although I think they should be reasonably
simple to work out).
If you use a file system other than FAT, you will ahve to try reading
sectors until you find one that can't be found, then you will know
what the maximum sector number is. You will also have to do the same
for heads and cylinders (although you might assume 2 heads for most
disks, but there could be more or less than 80 tracks....).
The information that is stored between sectors and that is used to
show when sectors and tracks begin and end is only readable by the
controller (in general you don't get to see what the data is, you can
only tell the controller how much of it there is). To find a
definition of what data is in those places, take a look at the
datasheet for the uPD765a/b FDC (the layout of data on a track is
shown on the last page). You'll find a copy at:
http://www.dwiles.demon.co.uk/D0205820.pdf
Note that this is not a permanent address, I'm preparing a large
amount of documentation for upload to another site that will ahve
documentation about most standard hardware for x86 based computer
systems, and the URL above will be used for a limited set of HTML
pages (lack of space there is a major limiting factor).
When I've finished the work I'm doing on the NASM docs and my own set
of CPU related docs, I'll try to produce a web page detailing the data
used fr different disk formats. I'm not sure how much data I can
provide, but I ahve a lot of documentation to search through when
working on most things now, so I should be able to produce a fairly
comprehensive page (even if it's not comprehensible :)
Jonathan de Boyne Pollard
CJ> disk--not that boot-sector b.s. I mean, the OS itself says that all
CJ> data will be erased.
A lot of people have offered you help, describing boot sectors, FATs,
and the like, but that help isn't going to be much use to you because
they have pitched it too high. You have a fundamental lack of
understanding about the nature of magnetic disc storage media. Grab
hold of any of the various books on the market that describe the
operations of PCs (_Computers Simplified_, _How Computers Work_, and so
forth) and have a read of the chapters that describe how magnetic disc
storage works and how sectors and tracks are laid out. You should then
appreciate what a high-level format actually does, and what the meaning
of "erased" in the context of high level formatting is.
Craig Joyce
> CJ> I want to know what is left on a disk when you FORMAT it as a FAT
> CJ> disk--not that boot-sector b.s. I mean, the OS itself says that all
> CJ> data will be erased.
>
> A lot of people have offered you help, describing boot sectors, FATs,
> and the like, but that help isn't going to be much use to you because
> they have pitched it too high. You have a fundamental lack of
> understanding about the nature of magnetic disc storage media.
Sir, everybody has "a fundamental lack of understanding" about atoms,
and how electrons travel through the wires. That does not stop people
like you to show off what they know.
You manage to read data even when you don't know about all laws of
magnetism. I hope to do the same. I am not asking questions to let you
make a magnetic-storage-scientist out of me. Its a simple question,
the answer of which will let me know how I'd go about working out my
own file-system. I know there is a boot sector, and the boot sector is
of 512 bytes, and bytes are a collection of polarities on the disk. I
stop there. I go no further, and perhaps no system programmer digs
deeper than that. Because I am not trying to invent something--I am
just trying to find out how to make full use of the floppy disk
drive,and the disk.
Let me put my initial question in these forms:
"If i start reading reading a freshly-FAT-formatted-disk byte by byte,
starting from the beginning, (and ending at the last location where
bytes could be stored,) what will be read?".
The first sector is the Boot Sector, and I have learnt that the BPB is
stored in the boot-sector. Does this also mean that even when the disk
is non-bootable, we still have the BPB there, and the FAT is there
too?
Tim Robinson
| Let me put my initial question in these forms:
|
| "If i start reading reading a freshly-FAT-formatted-disk byte by byte,
| starting from the beginning, (and ending at the last location where
| bytes could be stored,) what will be read?".
|
| The first sector is the Boot Sector, and I have learnt that the BPB is
| stored in the boot-sector. Does this also mean that even when the disk
| is non-bootable, we still have the BPB there, and the FAT is there
| too?
If the documentation for the FORMAT command says that all data on the disk
are erased, then it is not telling the whole truth.
What you will find on a freshly-formatted FAT floppy disk is:
* a boot sector (containing a BPB as the first few bytes)
* a couple of FATs (initially blank apart from the first couple of entries)
* a root directory (initially blank)
Then, once you start putting files onto the disk, the FAT and root directory
will fill up.
David A. Caabeiro
> Jonathan de Boyne Pollard <J.deBoyn...@tesco.net> wrote in message news:<3C5BEF7C...@tesco.net>...
>
> "If i start reading reading a freshly-FAT-formatted-disk byte by byte,
> starting from the beginning, (and ending at the last location where
> bytes could be stored,) what will be read?".
>
> The first sector is the Boot Sector, and I have learnt that the BPB is
> stored in the boot-sector. Does this also mean that even when the disk
> is non-bootable, we still have the BPB there, and the FAT is there
> too?
Every FAT formatted disk contains a boot sector, FAT and root directory.
In case you make a system disk, the first and second entry in the root
dir are filled with the names io.sys and msdos.sys respectively, among
other stuff. The boot sector - when executed - tries to load these
files. If something goes wrong, it prints the known "No system disk"
(or similar) message.
So when you start writing files to the disk, the root dir and FAT are
updated accordingly. BTW there're two copies of the FAT, as a backup.
Greetings,
David.
Reply to: ac AT turdera DOT com DOT ar
--
The most important thing in the programming language is the name. A language
will not succeed without a good name. I have recently invented a very good
name and now I am looking for a suitable language. -- Donald Knuth
Chris Giese
>"If i start reading reading a freshly-FAT-formatted-disk byte by byte,
>starting from the beginning, (and ending at the last location where
>bytes could be stored,) what will be read?".
For a 1.44 meg floppy disk:
Sector 0: boot sector and BIOS parameter block (BPB)
Sectors 1-9: FAT
Sectors 10-18: second copy of FAT
Sectors 19-32: root directory
Sectors 33- data
The sizes of the FATs, number of FATs, and size of root directory
can all be calculated from values in the BPB.
>The first sector is the Boot Sector, and I have learnt that the BPB is
>stored in the boot-sector. Does this also mean that even when the disk
>is non-bootable, we still have the BPB there, and the FAT is there
>too?
The BPB and one or more FATs are always there, assuming a valid FAT
filesystem (FAT12, FAT16, or FAT32).
Boot code is _usually_ present in the BPB, depending on the program
that formatted the disk. If the boot code doesn't find the DOS kernel,
it prints something like
Invalid system disk
Replace the disk, and then press any key
ext2 does not have a BPB. In my opinion, it could use something like
it, if only to make it easier to boot from 1.68 meg floppies.
If the disk contains a filesystem other than FAT, it should not
have a FAT-compatible BPB in sector 0. (Meaning that you should
not put such a BPB in the boot sector of your homebrew filesystem.)
There's some read-only FAT12/FAT16 code in this archive:
http://www.execpc.com/~geezer/temp/browse.zip
Craig Joyce
There is another question troubling me, what is the BPB_RootEntCnt (as
per microsoft document regarding FAT)?
It was written that it should be a number that when multiplied by 32
should give an even multiple of BPB_BytsPerSec. But does that mean I
can use anything?
What standard value do you use for it?
Also is the number of sectors occcupied by FAT (BPB_FATSz16) always 9
for a floppy?
Then comes the Volume ID (BPB_VolID). What number should I allocate to
it?
NoEma...@execpc.com (Chris Giese) wrote in message news:<3c5cb729$0$35624$272e...@news.execpc.com>...
Tim Robinson
| per microsoft document regarding FAT)?
It's the Cnt of Root Ents; that is, the number of entries in the root
directory.
| It was written that it should be a number that when multiplied by 32
| should give an even multiple of BPB_BytsPerSec. But does that mean I
| can use anything?
No; as with everthing else on a FAT disk, the root directory must be a whole
number of sectors long.
| What standard value do you use for it?
Not sure if there's a standard; why not write a program that reads the boot
sector off a disk and displays the values there? Then you can try various
disks and see what value(s) they use.
| Also is the number of sectors occcupied by FAT (BPB_FATSz16) always 9
| for a floppy?
You can work it out from the number of sectors per cluster.
Disk size = 2880 sectors (= 1.44MB / 512)
Sectors per cluster = 1
Number of clusters = 2880 (give or take)
Bytes per FAT entry = 1.5 (FAT12)
Bytes per FAT = 4320
Sectors per FAT = 8.4375, rounded up to 9
| Then comes the Volume ID (BPB_VolID). What number should I allocate to
| it?
Some suitably random 32-bit number -- e.g. generate it based on the current
clock value.
Craig Joyce
I tried creating boot sectors, but had a few problems.
Some time ago I wrote boot sectors or downloaded them from other
people's websites and they worked fine.
Now, my computer lab computers have been upgraded in some way due to
which whatever work I do is lost when I reboot--the usual setup in
universities.
The strange thing is that the very boot sectors that used to work fine
on the machines don't function at all. I write anything in the
program, but it just fails to work. All i see is a cursor blinking. Is
it my imagination or does the setup really change with such machine
things?
the source code for the recent Boot Sector is as follows:
If you have time, please try it out and tell me if there is something
wrong with it.
================================================================================
bits 16
org 07c00h ; i also tried org 0
jmp short start
BS_OEMName db 'Nauty0.1'
BPB_BytsPerSec dw 0200h
BPB_SecPerClus db 01h
BPB_ResvdSecCnt dw 00h
BPB_NumFATs db 02h
BPB_RootEntCnt dw 0e0h ; confusion
BPB_TotSec16 dw 0b40h ; 2880 sectors
BPB_Media db 0f0h
BPB_FATSz dw 09h ; 9 sectors of FAT
BPB_SecPerTrk dw 012h ; 18 tracks per sector
BPB_NumHeads dw 02h
BPB_HiddenSec dd 00h
BPB_TotSec32 dd 00h ; external sectors
BS_DrvNum db 00h
BS_Reserved1 db 00h
BS_BootSig db 029h
BS_VolID dd 019B574D0h
BS_VolLab db 'Not really'
BS_FileSysType db 'FAT12 '
;*****************start************
start cli
mov ax, cs
mov ds, ax
mov ss, ax
mov si, msg ; Print message
call putstr
msg db 'Hello Cyberspace!', 0 ; Print a 0-terminated string on the
screen
putstr:
lodsb ; AL = [DS:SI]
or al,al ; Set zero flag if al=0
jz putstrd ; Jump to putstrd if zero flag is set
mov ah,0x0E ; Video function 0Eh
mov bx,0x0007 ; Color int 0x10
jmp putstr ; Load characters until AL=0
putstrd:
retn
times 1FEh+$$-$+1 db 0
db 0aa55h
end
David A. Caabeiro
> Hi! Thank you for helping me out.
>
> on the machines don't function at all. I write anything in the
> program, but it just fails to work. All i see is a cursor blinking. Is
> it my imagination or does the setup really change with such machine
> things?
>
Some corrections...
>================================================================================
> bits 16
> org 07c00h ; i also tried org 0
You should stick with one of them...
> jmp short start
> BS_OEMName db 'Nauty0.1'
> BPB_BytsPerSec dw 0200h
> BPB_SecPerClus db 01h
> BPB_ResvdSecCnt dw 00h
> BPB_NumFATs db 02h
> BPB_RootEntCnt dw 0e0h ; confusion
> BPB_TotSec16 dw 0b40h ; 2880 sectors
> BPB_Media db 0f0h
> BPB_FATSz dw 09h ; 9 sectors of FAT
> BPB_SecPerTrk dw 012h ; 18 tracks per sector
> BPB_NumHeads dw 02h
> BPB_HiddenSec dd 00h
> BPB_TotSec32 dd 00h ; external sectors
> BS_DrvNum db 00h
> BS_Reserved1 db 00h
> BS_BootSig db 029h
> BS_VolID dd 019B574D0h
> BS_VolLab db 'Not really'
> BS_FileSysType db 'FAT12 '
>
> ;*****************start************
> start cli
> mov ax, cs
For the org you're using (0x7c00) you'd better do xor ax, ax
so DS and SS are 0...
> mov ds, ax
> mov ss, ax
You NEED a valid stack... so you must set sp too
mov sp, 0x7c00 should be ok... just bellow your boot code...
> mov si, msg ; Print message
> call putstr
jmp $ ; otherwise your data section will be "executed"...
> msg db 'Hello Cyberspace!', 0 ; Print a 0-terminated string on the
> screen
> putstr:
> lodsb ; AL = [DS:SI]
> or al,al ; Set zero flag if al=0
> jz putstrd ; Jump to putstrd if zero flag is set
> mov ah,0x0E ; Video function 0Eh
> mov bx,0x0007 ; Color int 0x10
And where is the int 0x10 ??? This way is difficult you'll get any
output on the screen :)
> jmp putstr ; Load characters until AL=0
> putstrd:
> retn
> times 1FEh+$$-$+1 db 0
why +1 ?
> db 0aa55h
dw... it's a word...
> end
David.
Reply to: ac AT turdera DOT com DOT ar
--
Optimization hinders evolution. -- Anonymous
Craig Joyce
questions:
How do I read the FAT? I have the equations from Microsoft's Hardware
White Paper, but when I try using the BIOS int 13h, I am unable to get
it.
Is the FAT (and other data) located like this:
head 0 cylinder 0 sector 0
head 0 cylinder 0 sector 1
... ... ...
head 0 cylinder 0 sector 18
.....
....
head 0 cylinder 1 sector 0
head 0 cylinder 1 sector 1
....
....
head 0 cylinder 80 sector 18
This is how I was trying to load the FAT into memory, because earlier
it was told that FAT starts at sector 1 and ends at sector 9...Could
you please explain if I am doing it the right way? How should I
proceed to read the sectors from a FAT12 floppy disk?
debs
On 6 Feb 2002 18:29:11 -0800, Craig Joyce spake thus:
>Hi! Thank you for helping me out.
>
>I tried creating boot sectors, but had a few problems.
>Some time ago I wrote boot sectors or downloaded them from other
>people's websites and they worked fine.
Hi Craig
I can't add anything to what David said (he seems to ahve caught
pretty much all the errors for you). The only other thing I would
mention is that I have read (can't remember where, I'll document it
next time I come across it) that some PCs use something other than
0:7C00h and 07C0h:0h to get the physical address of 07C00h for the
boot sector. It seems that CS:IP can be just about anything that forms
the correct physical address, which also helps to reinforce what David
said about using a known value to set DS and ES in the boot sector.
ccr...@crayne.org
at 01:09 PM, naught...@yahoo.com (Craig Joyce) said:
:Is the FAT (and other data) located like this:
:head 0 cylinder 0 sector 0
There is no sector 0. The lowest sector number is 1.
-- Chuck Crayne
-----------------------------------------------------------
ccr...@crayne.org
-----------------------------------------------------------
debs
On 7 Feb 2002 13:09:23 -0800, Craig Joyce spake thus:
>Is the FAT (and other data) located like this:
>
>head 0 cylinder 0 sector 0
There is no sector 0. Sectors are numbered from 1 to the number of
sectors (so for a 1.44M floppy with 18 sectors per track, it would be
1 - 18).
>head 0 cylinder 0 sector 1
>... ... ...
>head 0 cylinder 0 sector 18
>.....
>....
>head 0 cylinder 80 sector 18
On a 1.44M floppy formatted with the default values as used by MSDOS,
the FAT will be on head 0, cylinder 0, sectors 2 - 10 (that's 9
sectors). A copy of it is at sectors 11 - 18 of the same track plus
sector 1 of cylinder 0 head 1.
>
>This is how I was trying to load the FAT into memory, because earlier
>it was told that FAT starts at sector 1 and ends at sector 9...Could
>you please explain if I am doing it the right way? How should I
>proceed to read the sectors from a FAT12 floppy disk?
That information someone gave you was wrong. It runs from sctor 2 to
10. Sector 1 is the boot sector. Heads and cylinders (tracks) are
numbered from 0 and sectors are numbered from 1. The BIOS will return
the wrong data if you use the wrong values, and I've never personally
tested what happend if you ask for sector 0 (although I think on some
hard drives there is a sector 0 which is used for storing some kind of
data about the drive, but it's a long time since I read about that so
it may not be entirely accurate).
David A. Caabeiro
> I am sorry to trouble you so many times, but I have a few more
> questions:
>
> How do I read the FAT? I have the equations from Microsoft's Hardware
> White Paper, but when I try using the BIOS int 13h, I am unable to get
> it.
First of all you should know the relationship between LSN (logical sector
numbers) and PSN (physical sector numbers). The first one is used by DOS,
the second one by BIOS. I think you should find the formula in one of
the papers... it's pretty simple. Look for it.
> Is the FAT (and other data) located like this:
>
> head 0 cylinder 0 sector 0
This doesn't exist. Sectors are enumerated from 1 onward.
> head 0 cylinder 0 sector 1
> ... ... ...
> head 0 cylinder 0 sector 18
> .....
> ....
This is ok...
> head 0 cylinder 1 sector 0
> head 0 cylinder 1 sector 1
No, first the head is incremented:
cylinder 0, head 1, sector 1
till "max_heads"... then head is set to 0, and cylinder incremented...
> ....
> ....
> head 0 cylinder 80 sector 18
>
> This is how I was trying to load the FAT into memory, because earlier
> it was told that FAT starts at sector 1 and ends at sector 9...Could
> you please explain if I am doing it the right way? How should I
> proceed to read the sectors from a FAT12 floppy disk?
Don't understand what you mean with "start at sector 1 to sector 9"...
You should get the info in the BPB, and then, according to the values
you get, you should read n sectors from sector x contiguously. When
I talk about sectors I mean logical sectors.
BTW, get the Ralph Brown int list. Also some introductory book on PC
won't hurt (PC internals and such). You need to know how the geometry
is used first to understand this.
Regards,
David.
Reply to: ac AT turdera DOT com DOT ar
--
Craig Joyce
Craig Joyce
debs <de...@spamfree.net> wrote in message news:<7gt56ukftgcrdrsgb...@4ax.com>...
David A. Caabeiro
> Thanks, is there a way of adjusting it? I am using NASM.
Adjust what, the loading address?? Of course not...
If you're refering to the segments, something like
%define BOOTSEG 0 ; or whatever...
mov ax, BOOTSEG
mov ds, ax
will do.
Greetings,
David.
Reply to: ac AT turdera DOT com DOT ar
--
Error, no keyboard - press F1 to continue.
-- PC BIOS message
Craig Joyce
When I format a 1.44 Mb floppy disk from windows, and look at its
properties, i see its 1.38 mb. This is when I don't copy system files.
IS the space taken up by the BPB and FAT?
Why does this happen?
nos...@turdera.com.ar (David A. Caabeiro) wrote in message news:<slrna67g2j...@terminus.foobar.net>...
debs
On 7 Feb 2002 18:05:37 -0800, Craig Joyce spake thus:
As David says, you can load DS and ES by setting AX and then using
that to set DS and ES. If you really need CS setting to a known value
(which isnt really needed if you are not moving the boot sector to
another area of memory) then a far jump will do it. It shouldn't
generally be needed though (there are a few recent posts in the
archives that will explain why, just check google if you need to know
more on that).
Jerry Coffin
naught...@yahoo.com says...
> I'd like to ask something more.
>
> When I format a 1.44 Mb floppy disk from windows, and look at its
> properties, i see its 1.38 mb. This is when I don't copy system files.
> IS the space taken up by the BPB and FAT?
No -- this is due to different definitions of "mega" -- Windows uses
the definitions that are traditional in computers -- "K" = 2^10, "M"
= 2^20, and so on. Disk drives (apparently in an attempt to inflate
the advertised size) are typically rated based on "K"=1000, "M" = 1
million, and so on.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
Maxim S. Shatskih
Am I wrong that any PC uses 7c0:0?
Max
debs
On Fri, 8 Feb 2002 18:20:35 +0300, Maxim S. Shatskih spake thus:
>> 0:7C00h and 07C0h:0h to get the physical address of 07C00h for the
>
>Am I wrong that any PC uses 7c0:0?
No, differnt BIOS implementations could use anything to get the
physical address of 0x7C00, but by far the most common are 07C0:0 and
0:07C00.
It would make life far easier if they all used the same values, but
that's half the fun :)
David A. Caabeiro
>> 0:7C00h and 07C0h:0h to get the physical address of 07C00h for the
>
> Am I wrong that any PC uses 7c0:0?
>
Yes... at least every book I read tells it loads the sector at 0:7c00,
including the machines I have here...
I didn't know about 7c0:0 until I read the messages here...
Regards,
David.
Reply to: ac AT turdera DOT com DOT ar
--
It's so fast, it can do an infinite loop in 30 seconds.
-- Brian Bechtel, on the then new Mac IIfx
Maxim S. Shatskih
> >
>
> Yes... at least every book I read tells it loads the sector at 0:7c00,
> including the machines I have here...
> I didn't know about 7c0:0 until I read the messages here...
Compaq Presario 4328 (P5-233 machine with VX chipset) uses 7c0:0
Max
Craig Joyce
Does this mean that I now have to add a checking outine to my
boot-sector to find out where it is loaded? How do you do it :(
debs
On 10 Feb 2002 09:46:18 -0800, Craig Joyce spake thus:
There have been a few threads about this recently.
You shouldn't need to know the actually values of CS or IP for code as
smalla s a boot sector, as jumps and calls can all be made relative to
the current position. The assembler will work out the relative values.
For data addresses, you ahve to set up DS and ES (and FS anf GS if you
are writing code that will only run on a 386 and later), so you set
them however you need them to be.
If for some reason you do need to know what CS:IP are, the only
realistic way of doing it will be to use a far jump into your code,
using known values for CS:IP. For example:
<----start example---->
org 0
jmp short start
nop
; insert data here (BPB for a FAT boot sector)
start:
jmp 07C0h:next
next: ; now CS will be 07C0h
; and IP is this position
<----end example---->
Another otion (if using FAT) would be to code a far jump for the first
jump, and have the first two bytes of the OS identifier used for the
segment part of the address (that will use no space to set the
registers, but will affect what you can use for the OS identifier - no
file system driver should worry what you have there, as it can be
different for all implementation). Doing that would make the first two
characters of the OS ID string "À" + BEL (IE A with a grave accent,
and the bell character). Printing it to screen would normally ping the
PC speaker on the second character :) Not a way I recommend (although
I may use that myself at some stage, just to make sure it works as
expected under varoius OS). Of course, if you can be sure of having
the values you want at some other point in your code (or in fact any
values which would give a physical address of 0x7C00) then you could
use the memory location as the operand for a far jump.
x0: add [bx+si],al ; 00 00
rol byte [bx],imm8 ; C0 07 imm8
x2: add [si+0x0],bh ; 00 7C 00
add r/m8,r8 ; 00 /r
In the first of the above, "jmp x0" would jump to 07C0:0000h. In the
second, "jmp x2" would jump to 0000:7C00h. Of course, those values
wouldn't help in a real boot sector, but they might give you an idea
of how to determine what code you might look for when attempting to
determine if there is data in your code which encodes to the address
you would want.... I haven't done that with my boot sector yet, but
it's something Im going to look at (it's not needed, but would be fun
to do, if only to confuse people - one way of finding out who looks at
my code would be to have odd things like that in there and see who
asks questions about it <G>)
I can't believe I just took the time to work out what code produces
the address of the start of a boot sector! I'm losing my marbles :)
David A. Caabeiro
No, it's not necessary. You only have to set ds, es, ss to known
values (ie. 0 if using org 7c00 or 7c0 if using org 0 ...)
Check past messages in this newsgroup, it was discussed in detail.
Regards,
David.
Reply to: ac AT turdera DOT com DOT ar
--
The trouble with computers is that they do what you tell them,
not what you want. --D. Cohen
Frank Kotler
> > Does this mean that I now have to add a checking outine to my
> > boot-sector to find out where it is loaded? How do you do it :(
>
> No, it's not necessary. You only have to set ds, es, ss to known
> values (ie. 0 if using org 7c00 or 7c0 if using org 0 ...)
I've even seen a boot-sector that was "org 100h" and loaded segregs with
7B0h. I suppose it was intended to allow parts of the code to be tested
by running as a dos .com file. The "environment" is enough different
that I can't see that this would be too useful, but I can only assume
that that was the idea of doing it that way.
The point being that, as long as the values work out to the correct
physical address, we're not limited to specific values. As to CS:IP, if
you code something where it *does* make a difference, then you'll have
to arrange it to be so - we're not guaranteed anything but that it will
resolve to 7C00h physical (and boot-drive number in dl). But generally,
you don't need to care.
Best,
Frank
David A. Caabeiro
> "David A. Caabeiro" wrote:
>
>> > Does this mean that I now have to add a checking outine to my
>> > boot-sector to find out where it is loaded? How do you do it :(
>>
>> No, it's not necessary. You only have to set ds, es, ss to known
>> values (ie. 0 if using org 7c00 or 7c0 if using org 0 ...)
>
> I've even seen a boot-sector that was "org 100h" and loaded segregs with
> 7B0h. I suppose it was intended to allow parts of the code to be tested
> by running as a dos .com file. The "environment" is enough different
> that I can't see that this would be too useful, but I can only assume
> that that was the idea of doing it that way.
Weird... as you can test it without doing such a thing... and running
as a .com has some differences: you don't have a valid DL value (generally),
you can't set the stack wherever you want, etc.
I remember seeing some years ago this multipartite viruses (you know,
boot/com/exe/etc. infectors). Maybe there it made more "sense".
Regards,
David.
Reply to: ac AT turdera DOT com DOT ar
--
The real problem is not whether machines think but whether men do.
-- B.F. Skinner
Kovacs Viktor Peter
> On Mon, 11 Feb 2002 02:06:15 GMT, Frank Kotler <fbko...@ne.mediaone.net>
> wrote:
> > "David A. Caabeiro" wrote:
> >> > Does this mean that I now have to add a checking outine to my
> >> > boot-sector to find out where it is loaded? How do you do it :(
> >> No, it's not necessary. You only have to set ds, es, ss to known
> >> values (ie. 0 if using org 7c00 or 7c0 if using org 0 ...)
> > I've even seen a boot-sector that was "org 100h" and loaded segregs with
> > 7B0h. I suppose it was intended to allow parts of the code to be tested
> > by running as a dos .com file. The "environment" is enough different
> > that I can't see that this would be too useful, but I can only assume
> > that that was the idea of doing it that way.
> Weird... as you can test it without doing such a thing... and running
> as a .com has some differences: you don't have a valid DL value (generally),
> you can't set the stack wherever you want, etc.
> I remember seeing some years ago this multipartite viruses (you know,
> boot/com/exe/etc. infectors). Maybe there it made more "sense".
The problem was in the old intel assembler, where you had some
problems with the org directive. (you had to build an .exe, then
strip it with exe2bin; on the other hand, it compiled all .com files
with org 100 and stopped with an error on anything else)
Viktor
ps:
It was v1.x or v2.x... (it was still in use for education in 1999!!!)
Yes, this is the one with the limited (32k) symbol table...
Frank Kotler
> > I've even seen a boot-sector that was "org 100h" and loaded segregs with
> > 7B0h. I suppose it was intended to allow parts of the code to be tested
> > by running as a dos .com file. The "environment" is enough different
> > that I can't see that this would be too useful, but I can only assume
> > that that was the idea of doing it that way.
>
> Weird... as you can test it without doing such a thing... and running
> as a .com has some differences: you don't have a valid DL value (generally),
Yeah, there a several significant differences...
> you can't set the stack wherever you want, etc.
Oh? You wouldn't *need* to set up a stack, but I think you *can*. No?
> I remember seeing some years ago this multipartite viruses (you know,
> boot/com/exe/etc. infectors). Maybe there it made more "sense".
Well, I looked up where I saw it - it was a CP/M-86 boot (floppy) disk,
not an "official" one, but a "patched" version. The other weird thing
about it is that the last two bytes are 1, 90h instead of 55h,0AAh.
Appears to be used as a "cp/m type"(?) or "disk type". This isn't
something I've got source to, just a disassembly - which I may have
screwed up, but I can re-assemble it to a working boot-sector. (I have
to assume it's not going to work on a bios (or bochs?) that actually
checks the boot signature, but it works on my system)
I'm definitely not suggesting that anyone *write* a boot-sector like
this. Just an oddity I noticed...
Best,
Frank
Jonathan de Boyne Pollard
You've almost certainly never formatted such a disc in your life.
The term "1.44 MB" is a bastardisation, that mixes powers of ten with
powers of two. You will notice that hardware manufacturers tend to
avoid it. I've seen floppy disc drives labelled "1.4 MB", which is
better (despite the misappropriation of the SI prefix "M" to mean
megabinarybytes). A high density 3.5 inch floppy disc, low level
formatted in the conventional manner, holds 2880 sectors, each of which
holds 0.5 KiB of actual data. This yields a total storage capacity of
exactly 1440 KiB, which is approximately 1.40 MiB and approximately 1.47 MB.
Jonathan de Boyne Pollard
DAC> dir are filled with the names io.sys and msdos.sys respectively, [...]
This is not an inherent part of the FAT volume format. It is operating
system specific. MS-DOS uses the filenames IO.SYS and MSDOS.SYS .
PC-DOS and DR-DOS use IBMBIO.COM and IBMDOS.COM . FreeDOS uses
KERNEL.SYS . For several operating systems it is more important that
the file contents be stored in consecutive contiguous clusters than that
their entries in the root directory be the first.
Jonathan de Boyne Pollard
FK> 7B0h. I suppose it was intended to allow parts of the code to be tested
FK> by running as a dos .com file. The "environment" is enough different
FK> that I can't see that this would be too useful, but I can only assume
FK> that that was the idea of doing it that way.
My educated guess is that it was not for _testing_ that that was done,
but that it was done for simplicity of development. Many linkers know
how to produce "COM" format executables, and a "COM" format executable
is a simple one-to-one image that can be written directly to a volume
boot sector with a range of tools, without having to worry about things
such as relocation fixups. Writing the boot sector so that the
linker can produce a "COM" format executable file containing the raw
image of the boot sector avoids the need for having intermediate tools
(such as, for example, EXE2BIN) that take the boot sector in some
_other_ file format and convert it to a simple binary image.
Craig Joyce
> if
> you code something where it *does* make a difference, then you'll have
> to arrange it to be so - we're not guaranteed anything but that it will
> resolve to 7C00h physical (and boot-drive number in dl). But generally,
> you don't need to care.
>
> Best,
> Frank
How about using the int 13h to load a sector to memory? This needs a
correct setting of ES:BX.
Also, the free area of memory after the computer boots up starts at
0050h, so if I need to load the sectors in free memory, how do i go
about deciding it?
David A. Caabeiro
Use int 0x12 or read the word at 0x413 to get conventional memory size,
(it's in Kb, look at RBIL) then substract the size you want to it, etc.
For example:
int 0x12 ; returns size in AX
shl ax, 6 ; convert to paragraphs
sub ax, SIZE / 0x10 ; substract SIZE paragraphs
mov es, ax ; ES:0 -> TOM - SIZE
Of course SIZE should be paragraph-aligned, otherwise, you should
round it up when defining it (this is left to you as an exercise :))
Regards,
David.
Reply to: ac AT turdera DOT com DOT ar
--
REBOOT(8) ConvexOS Man Pages REBOOT(8)
-n option avoids the sync. It can be used if a disk or
the processor is on fire.
Frank Kotler
> How about using the int 13h to load a sector to memory? This needs a
> correct setting of ES:BX.
Right. ES, DS, etc. *do* need to be set to known values. The point is
that you *don't* need to know the actual values of CS:IP to do this.
Once you've loaded your sector(s) to a known address, you'll have to use
a "far" jump to the code - if you knew the original CS:IP, you might be
able to use a relative jump.
> Also, the free area of memory after the computer boots up starts at
> 0050h, so if I need to load the sectors in free memory, how do i go
> about deciding it?
Well, 50h sounds a little low to me. I'm not sure where you got that
number. I'd use 600h or 700h as "bottom of free memory", to avoid
overwriting Bios Data Area and stuff - but it's your OS, you can
overwrite anything you want, if you're not going to use it. David showed
you how to determine "top of memory", if you want to "load high". Keep
in mind that I have *not* written an OS, so I may be way off-base on all
this...
Best,
Frank
Craig Joyce
> Well, 50h sounds a little low to me. I'm not sure where you got that
> number. I'd use 600h or 700h as "bottom of free memory", to avoid
> overwriting Bios Data Area and stuff - but it's your OS, you can
> overwrite anything you want, if you're not going to use it. David showed
> you how to determine "top of memory", if you want to "load high". Keep
> in mind that I have *not* written an OS, so I may be way off-base on all
> this...
Actually, my friends have set up a site about assembly. They have a
page http://www.geocities.com/riskyfriends/x86/os/memory_map.html. It
says that at 0050h there is free memory.
> Best,
> Frank
FYS
Hi Craig,
Frank is right, 0050h is a little bit low.
Have a look at:
http://www.cybertrails.com/~fys/rombios.htm
There are 34h (52d) bytes used by the BIOS and POST that
are at 0x00500 (0050:0000h). You could start your
code at 0x00534 (0050:0034h), but this would be a weird
starting position.
If you look at the link above, you will see that DOS 2.0+
starts at 0x00600 (0060:0000h). It is only 256 byte higher
than the previous address.
However, if you have a look a little further down the page,
and are going to support the 286 LOADALL instruction, you
will have to save room at 0x00800 (0080:0000h) for the
"LOADALL buffer".
A good place to start you OS would be at 0x00900 (0090:0000h).
Enjoy,
Ben
"Craig Joyce" <naught...@yahoo.com> wrote in message
news:7e5f4e39.02021...@posting.google.com...
Frank Kotler
Ah, yes. 0050:0000 - I thought you meant 0000:0050 !
Nice site!
Best,
Frank
Debs
On Fri, 15 Feb 2002 16:55:50 GMT, FYS spake thus:
>There are 34h (52d) bytes used by the BIOS and POST that
>are at 0x00500 (0050:0000h). You could start your
>code at 0x00534 (0050:0034h), but this would be a weird
>starting position.
Most of the bytes that are used there are either used by DOS, ROM
BASIC (which is rarely, if ever, used by an OS) or BASICA.COM. The
only byte you might want to preserve is the singel byte at 0x500, if
you will be using PRINT SCREEN before setting up your own interrupts.
If writing a DOS app, then you would have to be more careful about
which bytes you preserve in that area.
Also, RBIL indicates that 0000h:0500h (or 050h:00h) is available as a
data area. The bytes used by the POST will be available even under DOS
(as the POST has finished well before DOS is loaded).
>
>If you look at the link above, you will see that DOS 2.0+
>starts at 0x00600 (0060:0000h). It is only 256 byte higher
>than the previous address.
>
>However, if you have a look a little further down the page,
>and are going to support the 286 LOADALL instruction, you
>will have to save room at 0x00800 (0080:0000h) for the
>"LOADALL buffer".
Good point. I know I won't be supporting it (no need, with my OS being
386+), but it's useful to remember when writing code that may some day
be ported to an earlier processor :)
--
Debs
Alexei A. Frounze
Not to mention LOADALL isn't something intel kept backward compatibility for
in their CPUs.
Good Luck
--
Alexei A. Frounze
http://alexfru.narod.ru
http://www.members.tripod.com/protected_mode/