Discussion:
PC boot block programming madness
(too old to reply)
Erik Larsson
2004-10-21 20:34:59 UTC
Permalink
Hello everyone.

I've just gotten into assembler programming for the pc, using NASM to try
out programming some boot-code to start from a floppy or whatever.
But it totally drives me nuts...

1. First, I want to be able to boot my program... So I write the 512 bytes
containing my code to the beginning of a floppy, and try to boot it.
Testing it in Bochs and VMware indicates that it recognizes and boots the
program, but when inserting the disk into a 'real' computer it isn't
recognized as a bootable disk.
What properties must be satisfied for the bios to recognize the disk as
bootable?

2. I want to print something to be able to see that I've actually achieved
something. As far as I understand it, you do the 'int 0x10' thing with ah =
0xE (write text teletype), bh = 0 (page number), bl = 0 (or whatever color
you want) and al = ascii code of the character to print.
This works fine in bochs, but not in vmware or in the real world. In bochs
the text is printed just as it should be, but in the real world, it seems
that it tries to print something (the cursor moves) but nothing comes out
=).

If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )

Erik
alex
2004-10-21 22:35:17 UTC
Permalink
A lot of BIOS's will check for the boot signature 0x55aa at offset 510
of the bootsector, if this is not found then you may recieve a message
saying its unbootable.

Cheers
Alex
Post by Erik Larsson
Hello everyone.
I've just gotten into assembler programming for the pc, using NASM to try
out programming some boot-code to start from a floppy or whatever.
But it totally drives me nuts...
1. First, I want to be able to boot my program... So I write the 512 bytes
containing my code to the beginning of a floppy, and try to boot it.
Testing it in Bochs and VMware indicates that it recognizes and boots the
program, but when inserting the disk into a 'real' computer it isn't
recognized as a bootable disk.
What properties must be satisfied for the bios to recognize the disk as
bootable?
2. I want to print something to be able to see that I've actually achieved
something. As far as I understand it, you do the 'int 0x10' thing with ah =
0xE (write text teletype), bh = 0 (page number), bl = 0 (or whatever color
you want) and al = ascii code of the character to print.
This works fine in bochs, but not in vmware or in the real world. In bochs
the text is printed just as it should be, but in the real world, it seems
that it tries to print something (the cursor moves) but nothing comes out
=).
If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )
Erik
Erik Larsson
2004-10-22 05:42:11 UTC
Permalink
Hey Alex...
Thanx very much for the reply, but I actually know this... and consequently
I have my 0x55aa at offset 510. Maybe I forgot to say.
This is my source code by the way (NASM-style).
--------------------------------------------------------
[BITS 16] ; Generate 16-bit code

start:

; Do a bit of looping to slow things down a bit

mlinit:
mov ax, 0xFFFF
oloop: ; Outer loop
dec ax
mov bx, 0xFF ; Fine tune this to match your processor speed
iloop: ; Inner loop
dec bx
cmp bx, 0x0000
jne iloop
cmp ax, 0x0000
jne oloop

; Finished slowing down...

print:
mov si, OFFSET+s ; Load address to the first character
printl:
lodsb ; Load string (what this acually means, I don't know yet)
mov ah, 0x0E ; Argument to i10,A. 0E = "write text teletype"
mov bx, 0x0 ; Argument to i10,A. Page 0, foreground color 0
int 0x10 ; Call the BIOS VIDEO_IO
cmp si, OFFSET+se ; End of string reached?
jb printl

; Do the whole process again, including the slowdown-loops
jmp mlinit

end: ; End of program

; Here comes the data
s:
dw "Hello world! :)"
dw 13 ; carriage return
dw 10 ; linefeed
se:

; Constants
OFFSET: equ 0x7C00 ; The place in memory where the code is loaded

TIMES 510-($-$$) DB 0 ; make sure that the 512 bytes of the
bootsector are padded with zeros
BootSignature DW 0xAA55 ; boot signature, to make BIOS detect my disk
as bootable?
--------------------------------------------------------

As you can see, the idea is to print "Hello world :)" an infinite number of
times (or at least until I press the reset button =) ) and using a simple
loop to slow the program down.
But my problems remain:
1. A real world computer won't boot from my diskette containing this
512-byte code segment at the beginning of the disk... but Bochs (x86 system
emulator) and VMWare (sort of the same thing) will boot.
2. VMWare and real world computers won't output any visible text. The cursor
moves though. Bochs outputs the text just as I would expect it to be
outputted.

So, if anyone has time to look into this, please do. I don't understand a
thing : )

Erik
Post by alex
A lot of BIOS's will check for the boot signature 0x55aa at offset 510
of the bootsector, if this is not found then you may recieve a message
saying its unbootable.
Cheers
Alex
Post by Erik Larsson
Hello everyone.
I've just gotten into assembler programming for the pc, using NASM to try
out programming some boot-code to start from a floppy or whatever.
But it totally drives me nuts...
1. First, I want to be able to boot my program... So I write the 512 bytes
containing my code to the beginning of a floppy, and try to boot it.
Testing it in Bochs and VMware indicates that it recognizes and boots the
program, but when inserting the disk into a 'real' computer it isn't
recognized as a bootable disk.
What properties must be satisfied for the bios to recognize the disk as
bootable?
2. I want to print something to be able to see that I've actually achieved
something. As far as I understand it, you do the 'int 0x10' thing with
ah
Post by alex
Post by Erik Larsson
=
0xE (write text teletype), bh = 0 (page number), bl = 0 (or whatever color
you want) and al = ascii code of the character to print.
This works fine in bochs, but not in vmware or in the real world. In bochs
the text is printed just as it should be, but in the real world, it seems
that it tries to print something (the cursor moves) but nothing comes out
=).
If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )
Erik
Charles A. Crayne
2004-10-22 06:00:26 UTC
Permalink
On Fri, 22 Oct 2004 05:42:11 +0000 (UTC)
"Erik Larsson" <***@crayne.org> wrote:

:So, if anyone has time to look into this, please do. I don't understand a
:thing : )

Does the "real computer" even spin up the floppy drive? Many current
systems no longer have the floppy in the default boot chain -- although
this can usually be changed in the BIOS settings.

-- Chuck
Erik Larsson
2004-10-22 06:48:45 UTC
Permalink
Yes, of course. And I can boot other bootable floppies, like the Win9x
bootfloppy, FreeBSD boot floppy.
The only one that doesn't boot is my own, homemade floppy.
So... =/
Thanx anyway.
Erik
Post by Charles A. Crayne
On Fri, 22 Oct 2004 05:42:11 +0000 (UTC)
:So, if anyone has time to look into this, please do. I don't understand a
:thing : )
Does the "real computer" even spin up the floppy drive? Many current
systems no longer have the floppy in the default boot chain -- although
this can usually be changed in the BIOS settings.
-- Chuck
alex
2004-10-22 08:29:59 UTC
Permalink
Code looks ok.. assembled it and took a look at it in a debugger. signature
is at the correct offset..
The only remaining explanation is, does the disk you're booting actually
contain a copy of your assembled
code? Not sure? write a bit of code to read the first sector and dump it to
a binary file, then bring it up
in your favourite debugger and see if its your code,or something else.

Sure sector 0 on the disk you are using isnt bad?

In my utility that replaces sector 0, I do the write twice, as some writes
can fail
on the odd occasion (using int 13h), often because a write is initiated when
the motor isnt quite
up to speed yet

If its none of these. I am out of ideas

Cheers
Alex
Post by Erik Larsson
Yes, of course. And I can boot other bootable floppies, like the Win9x
bootfloppy, FreeBSD boot floppy.
The only one that doesn't boot is my own, homemade floppy.
So... =/
Thanx anyway.
Erik
Post by Charles A. Crayne
On Fri, 22 Oct 2004 05:42:11 +0000 (UTC)
:So, if anyone has time to look into this, please do. I don't understand a
:thing : )
Does the "real computer" even spin up the floppy drive? Many current
systems no longer have the floppy in the default boot chain -- although
this can usually be changed in the BIOS settings.
-- Chuck
Frank Kotler
2004-10-22 08:18:09 UTC
Permalink
This post might be inappropriate. Click to display it.
Erik Larsson
2004-10-22 18:31:03 UTC
Permalink
It's booting!
Man, you're my god! Thanks a lot =)
You know what was missing to get my computer to recognize it as bootable? It
was actually the 'jmp short' instruction that had to be present at the
beginning of the code.
So now you know about a bios that cares about the "jmp short xx"/"nop"...
It's in a Compaq Deskpro EN 700 MHz =)
Ridicilous! =)
I'm glad you point out errors in my code, and I would just like to add that
I'm a total newbie in x86 assembly programming. : ) I just want to get
started somewhere.
Anyway, going to test out what's wrong with my print code, and correct
errors in my code....
I'll get back you you...
Once more: THANX =)
Erik
Post by Frank Kotler
Post by Erik Larsson
Hey Alex...
Thanx very much for the reply, but I actually know this... and consequently
I have my 0x55aa at offset 510. Maybe I forgot to say.
The other thing that a bios *might* be looking for is for the code to
begin with either "jmp short xx"/"nop" or "jmp xxxx". I don't think I've
ever *seen* a bios that cared about this...
Post by Erik Larsson
This is my source code by the way (NASM-style).
--------------------------------------------------------
[BITS 16] ; Generate 16-bit code
; Do a bit of looping to slow things down a bit
mov ax, 0xFFFF
oloop: ; Outer loop
dec ax
mov bx, 0xFF ; Fine tune this to match your processor speed
iloop: ; Inner loop
dec bx
cmp bx, 0x0000
jne iloop
cmp ax, 0x0000
jne oloop
; Finished slowing down...
mov si, OFFSET+s ; Load address to the first character
lodsb ; Load string (what this acually means, I don't know yet)
It loads al from [ds:si] and increments si to point to the next byte.
Your code assumes that ds is zero. This may not be the case. I'd set it
explicitly at the top of my code.
Post by Erik Larsson
mov ah, 0x0E ; Argument to i10,A. 0E = "write text teletype"
mov bx, 0x0 ; Argument to i10,A. Page 0, foreground color 0
If you really got foreground color zero, it would be hard to read! :) My
bios doesn't seem to use the color provided in bl (or the page specified
in bh, either). In case you encounter a bios that does, you might want
"mov bx, 0x7". (or try some other color)
Post by Erik Larsson
int 0x10 ; Call the BIOS VIDEO_IO
cmp si, OFFSET+se ; End of string reached?
jb printl
; Do the whole process again, including the slowdown-loops
jmp mlinit
end: ; End of program
; Here comes the data
dw "Hello world! :)"
dw 13 ; carriage return
dw 10 ; linefeed
Whoah! You want "db" on all three of these lines, not "dw".
Post by Erik Larsson
; Constants
OFFSET: equ 0x7C00 ; The place in memory where the code is loaded
This is an unusual way to do it, but it ought to work, I think.
Post by Erik Larsson
TIMES 510-($-$$) DB 0 ; make sure that the 512 bytes of the
bootsector are padded with zeros
BootSignature DW 0xAA55 ; boot signature, to make BIOS detect my disk
as bootable?
--------------------------------------------------------
As you can see, the idea is to print "Hello world :)" an infinite number of
times (or at least until I press the reset button =) ) and using a simple
loop to slow the program down.
1. A real world computer won't boot from my diskette containing this
512-byte code segment at the beginning of the disk... but Bochs (x86 system
emulator) and VMWare (sort of the same thing) will boot.
I'm not familiar with Bochs or VMWare. Do they boot from an actual
floppy, or from a "disk image"? Is it possible that your code isn't
really being written to the floppy where you expect it?
Post by Erik Larsson
2. VMWare and real world computers won't output any visible text. The cursor
moves though. Bochs outputs the text just as I would expect it to be
outputted.
This is probably the result of ds being set to zero when your bootsector
gets control in Bochs, but not in VMWare or the real computer.
Post by Erik Larsson
So, if anyone has time to look into this, please do. I don't understand a
thing : )
I'd mess with it, but my floppy drive's dead :(
Here's a simple example that "worked the last time it worked". Doesn't
have any "slowdown" code in it - just prints once and hangs. That's a
terrible way to do a slowdown loop, by the way - totally processor
dependant. You're still in real mode, you could use the "tick count"
(18.2/second) at 0000h:046Ch to get a consistant slowdown - or... mmmm,
from memory, int 15h, ah=83h....
Best,
Frank
;------------------------------------
; nasm -f bin -o boot01.bin boot01.asm
; dd count=1 if=boot01.bin of=/dev/fd0
; or debug or rawrite...
;-------------------------------------
org 7C00h
section .text
jmp short overdata
nop
db 'MyOS ' ; OEM id
dw 200h ; bytes/sector
db 1 ; sectors per cluster
dw 1 ; sectors before FAT
db 2 ; number of FATs
dw 0E0h ; max rootdir entries
dw 0B40h ; total sectors
db 0Fh ; media descriptor
dw 9 ; sectors per FAT
dw 12h ; sectors per track
dw 2 ; number heads
times 0Ah db 0
db 29h
db 0EFh
db 7
db 10h
db 24h
db 'LINUX BOOT FAT12 '
; guess where I cribbed this part :)
;----------------------------
xor ax,ax
mov ds,ax
mov es,ax
; should probably set up a sane stack here, too.
mov si,msg ; "our dear string"
mov bx,7
mov ah,0Eh
lodsb
or al,al
jz blackhole
int 10h ; since we're still in RM, we can use bios.
jmp msgloop
jmp blackhole
msg db "We be bootin'!",0
times 510-($-$$) db 90h ; don't think it matters,
; but we'll use NOP.
db 55h,0AAh ; boot sector signature
;-------------------------
Dirk Wolfgang Glomp
2004-10-22 10:00:05 UTC
Permalink
Post by Erik Larsson
Hey Alex...
Thanx very much for the reply, but I actually know this... and consequently
I have my 0x55aa at offset 510. Maybe I forgot to say.
This is my source code by the way (NASM-style).
--------------------------------------------------------
[BITS 16] ; Generate 16-bit code
; Do a bit of looping to slow things down a bit
mov ax, 0xFFFF
oloop: ; Outer loop
dec ax
mov bx, 0xFF ; Fine tune this to match your processor speed
iloop: ; Inner loop
dec bx
cmp bx, 0x0000
jne iloop
cmp ax, 0x0000
jne oloop
; Finished slowing down...
mov si, OFFSET+s ; Load address to the first character
lodsb ; Load string (what this acually means, I don't know yet)
Load "al" from "ds:si"
and increase/decrease(controlled by direction flag) "si" by one
(like: mov al,[si] + inc/dec si).
Post by Erik Larsson
mov ah, 0x0E ; Argument to i10,A. 0E = "write text teletype"
mov bx, 0x0 ; Argument to i10,A. Page 0, foreground color 0
int 0x10 ; Call the BIOS VIDEO_IO
cmp si, OFFSET+se ; End of string reached?
jb printl
I dont use Nasm,
but is this corect to put a "+" between the OFFSET and address-label,
like "OFFSET+s" and "OFFSET+se"?

Dirk
Erik Larsson
2004-10-24 18:02:22 UTC
Permalink
Yep, that is correct =)
It just adds the address of the label s with the constant OFFSET. Nothing
strange there.
Thanx for the reply anyway.
Erik
Post by Dirk Wolfgang Glomp
I dont use Nasm,
but is this corect to put a "+" between the OFFSET and address-label,
like "OFFSET+s" and "OFFSET+se"?
Dirk
Frank Kotler
2004-10-24 20:35:15 UTC
Permalink
Post by Erik Larsson
Post by Dirk Wolfgang Glomp
I dont use Nasm,
but is this corect to put a "+" between the OFFSET and address-label,
like "OFFSET+s" and "OFFSET+se"?
Dirk
Yep, that is correct =)
It just adds the address of the label s with the constant OFFSET. Nothing
strange there.
Thanx for the reply anyway.
Erik
The reason Dirk would be concerned is that, in most assemblers, "offset"
is a "keyword", and "offset+N" would most definitely be a syntax error.
"offset" is just an "identifier" to Nasm, so it's perfectly okay, but
you *might* want to choose another name for this constant, just to avoid
confusion...

One I sometimes use as an example is "label: jmp label"... "label", too,
is valid in Nasm, but a keyword to other assemblers. Another identifier
- "target" or something - might be better...

(thanks for the confirmation that some biosen *do* care about starting a
bootsector with "jmp"... I thought that was kind of a longshot...)

Best,
Frank
Erik Larsson
2004-10-25 19:14:29 UTC
Permalink
Oh. I see. That makes sense.
I'll consider that about the possible keywords 'offset' and 'label' in the
future then =) Just to avoid confusion.
Erik
Post by Frank Kotler
Post by Erik Larsson
Post by Dirk Wolfgang Glomp
I dont use Nasm,
but is this corect to put a "+" between the OFFSET and address-label,
like "OFFSET+s" and "OFFSET+se"?
Dirk
Yep, that is correct =)
It just adds the address of the label s with the constant OFFSET. Nothing
strange there.
Thanx for the reply anyway.
Erik
The reason Dirk would be concerned is that, in most assemblers, "offset"
is a "keyword", and "offset+N" would most definitely be a syntax error.
"offset" is just an "identifier" to Nasm, so it's perfectly okay, but
you *might* want to choose another name for this constant, just to avoid
confusion...
One I sometimes use as an example is "label: jmp label"... "label", too,
is valid in Nasm, but a keyword to other assemblers. Another identifier
- "target" or something - might be better...
(thanks for the confirmation that some biosen *do* care about starting a
bootsector with "jmp"... I thought that was kind of a longshot...)
Best,
Frank
s***@crayne.org
2004-10-22 06:55:26 UTC
Permalink
Post by Erik Larsson
Hello everyone.
I've just gotten into assembler programming for the pc, using NASM to try
out programming some boot-code to start from a floppy or whatever.
But it totally drives me nuts...
1. First, I want to be able to boot my program... So I write the 512 bytes
containing my code to the beginning of a floppy, and try to boot it.
Testing it in Bochs and VMware indicates that it recognizes and boots the
program, but when inserting the disk into a 'real' computer it isn't
recognized as a bootable disk.
What properties must be satisfied for the bios to recognize the disk as
bootable?
2. I want to print something to be able to see that I've actually achieved
something. As far as I understand it, you do the 'int 0x10' thing with ah =
0xE (write text teletype), bh = 0 (page number), bl = 0 (or whatever color
you want) and al = ascii code of the character to print.
This works fine in bochs, but not in vmware or in the real world. In bochs
the text is printed just as it should be, but in the real world, it seems
that it tries to print something (the cursor moves) but nothing comes out
=).
If you really have bl = 0 (black) this is exactly what you would
see. Try bl = 7 (white).
Post by Erik Larsson
If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )
Erik
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Erik Larsson
2004-10-22 08:30:06 UTC
Permalink
I've actually tried all values between 0x0 and 0x7 for bl, and nothing seems
to make any difference at all.
Perhabs because the default video color mode is black/white?
Thanx anyway...
Erik
Post by s***@crayne.org
If you really have bl = 0 (black) this is exactly what you would
see. Try bl = 7 (white).
Post by Erik Larsson
If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )
Erik
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Steve Dubrovich
2004-10-23 02:42:48 UTC
Permalink
Post by Erik Larsson
Hello everyone.
I've just gotten into assembler programming for the pc, using NASM to try
out programming some boot-code to start from a floppy or whatever.
But it totally drives me nuts...
[snip]
Post by Erik Larsson
If anyone has experience with boot-programming or can supply me with a
working nasm source code example that I can play around with... that would
be great. : )
Erik
Here's a great example I ran across, in nasm:

http://www.geocities.com/mvea/bootstrap.htm

His strategy utilizes fat12 file system _structure_ to find and load
'LOADER BIN', so you maintain ordinary diskette access to _your_ test
assembly file loader.bin - from msDos or Winxx for development.

He loads it to Segment 0050:, but the first word in segment 0050: is
used by the RomBios Data area [That area starts at segment 0040:] for
the 'print screen' flag & LPTn, so I'd change 0050: to at least 0051:
[I used 60: because that's what I've found in a Hard Drive bootstrap,
they may be using 0060: because the modern bios's also have an
eXtended RomBios data area, one's patterned after the ps/2 bios's,
they also generally reserve either 1 or 2k at the top of conventional
memory (A000:0000h -1), if you call the bios's 'get memory size' it
will return an equivalent 638 or 639k on such a system instead of the
full [i.e. max] 640k, it's an ancient call to size conventional
memory, but still supported]. You don't want to overwrite that area
with your primary or secondary bootstrap code, or your realmode code.

Steve
Florian Liebig
2004-10-25 17:24:38 UTC
Permalink
hi erik!
you don't need that signature at the end of the loader as well you don't need
the starting bytes as someone posted you in a reply.
the only reason for those few bytes is that any foreign os may read out that
disquette because it contains a media ID byte a.s.o.
so, if you want that disquette to be readable under MS or linux or whatever
without getting an error message like "sector 0 is bad" or "sector 0 mark not
found" , you need the given information at beginning of your loader as someone
posted to you.

Florian.
Erik Larsson
2004-10-25 19:14:26 UTC
Permalink
I think I've proved you wrong in that, and you would know if you'd read my
earlier posts. =)
Actually those starting bytes (if you were referring to the jump/nop
instructions in the beginning) were the key to making the diskette boot in
my compaq PIII 800Mhz PC. It just wouldn't recognize the diskette as
bootable unless the first read bytes were jmp/nop.
Not sure if the trailing bytes are needed, but hey, they aren't in the way,
so I'll just go with them.
Thanks for taking your time anyway.
Erik
Post by Florian Liebig
hi erik!
you don't need that signature at the end of the loader as well you don't need
the starting bytes as someone posted you in a reply.
the only reason for those few bytes is that any foreign os may read out that
disquette because it contains a media ID byte a.s.o.
so, if you want that disquette to be readable under MS or linux or whatever
without getting an error message like "sector 0 is bad" or "sector 0 mark not
found" , you need the given information at beginning of your loader as someone
posted to you.
Florian.
Florian Liebig
2004-10-28 17:16:58 UTC
Permalink
hello erik!
I really do not want to anger you too much but let me have an interruption on
your words right now.
I do not know if you are going to develop something os-independant like me, but
if you are, the things i've told you were right up to the income of your mail
and that really pisses me off !!!
so these were my theses:
1st) you won't need a starting jump
2nd) you won't need a BiosParameterBlock
3rd) you won't need to worry about 0x1FE significance
since i'm developing an os-independant boot manager that works with every OS
product, and, shall work on every bios loading strategy, I had to do some
research on different systems from 486 to P4. But when you tell me that on your
COMPAQ P3 this won't be the same, i'm afraid.
this means to me, that thos COMPAQ bios romcodes aren't builded to work with my
code !!
Because of this, I'd like to send you a short example out of my source that
works fine on both: a) floppies and b) ide's.
but it's definitely now being designed to make a floppy bootable and as you
will see, no JMP and no other signs are put in.
on all systems that i've tested up to now, and i'd like to swear about that,
they're not needed up to now!!
perhaps you've got the time to make that being assembled and written down to
one of your floppies in order to have me a short mail 8^] !!
The only thing i could not do for you is to make it be NASM compatible.
I use borland's turbo assembler with /m2 switch.

greetings from over here in rainy cold -but good old germany,
Florian.

So here you go:
;ÛßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßÛ
;Û code written by f. liebig Û
;Û loader.asm Û
;ÛÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÛ
; DEFINITIONS for boot_loader
;
; written by F. Liebig
;+-->include loader.inc
;v
STACK_SEG equ 01000h
KERNEL_SEG equ 01000h
KERNEL_OFF equ 00200h
LOADER_SEG = KERNEL_SEG
LOADER_OFF equ 00000h
HD0_SEG = KERNEL_SEG
HD0_OFF = 0FFFFh - STACK_SIZE - SECTOR_LEN
HD0_LABELS = 0FFFFh - STACK_SIZE - SECTOR_LEN - 4*16 - 4*8
BUF = 1024 * 32
FONT_SEG = 02000h
FONT_OFF = 00000h
STACK_SIZE = _i8086_minimum_framesize * _numberOF_nested_function_calls

_i8086_minimum_framesize = 8 * WORD_SIZE
_numberOF_nested_function_calls = 0200

WORD_SIZE = 2h
SECTOR_LEN = 512

IO_TRIES = 00Fh
;now the originally loader code follows
;ideal directive only used for borland's turbo assembler
ideal

segment _loader byte public use16
p386
assume cs:_loader, ds:_loader, es:_loader, fs:_loader,gs:_loader
cli
xor ax,ax
dec ax
mov sp,ax
mov ax,STACK_SEG ;have one here on your self
mov ss,ax
; ss:sp is now set for my further use!
mov ax,7c0h
mov ds,ax
mov es,ax
; ds is ready for use only while this startup_code_functios
mov ax,0b800h
mov fs,ax
xor bx,bx
mov cx,80*25
mov ax,203h
@cls0:
mov [fs:bx],ax
inc bx
inc bx
loop @cls0

jmp short @printsth
label _cr0
_copyright_ db '(C)&written by F.Liebig',0
label _cr0e
label fb0
firstmsg db '** FL loader (2+400æ)x10^3 **', 0h
label fb0e
@printsth:
mov dl,7
call near setcol
mov dh,0
mov dl,40- ((_cr0e-_cr0) SHR 1)
call near setpos
mov bx,offset _copyright_
call near printstr
mov dh,12
mov dl,40- ((fb0e-fb0) SHR 1)
call near setpos
mov bx,offset firstmsg
call near printstr
call near getkey
jmp last_but_not_least

label hello_world
db 'hello world! greetings from germany/ns! @8^)',0
label hello_world0
label further_on
db 'further on: were posting around in news://news.comp.lang.asm.x86',0
label further_on0
label quietplease
db 'I would like to make even more outputs but we will halt this system now
!',0
label quietplease0
last_but_not_least:
mov dh,22
mov dl,40-((hello_world0-hello_world) SHR 1 )
call near setpos
mov bx,offset hello_world
call near printstr
call near getkey

mov dh,23
mov dl,40-((further_on0-further_on) SHR 1 )
call near setpos
mov bx,offset further_on
call near printstr
call near getkey

mov dh,24
mov dl,40-((quietplease0-quietplease) SHR 1 )
call near setpos
mov bx,offset quietplease
call near printstr
call near getkey
jmp short shutdown

proc getkey
xor ah,ah
int 16h
retn
endp
proc shutdown
hlt
retn
endp
;PUT IN HERE CODE that you'd like to insert very much
;+-|printc|-----------------------------------------------------------------+
;| dl = ascii - value (character)
;|
;| prints single character on screen and updates cursor
;+--------------------------------------------------------------------------+
proc printc
jmp short @printc_main
TXTSEG equ 0b800h
x db 0
y db 0
clr db 0
@printc_main:
cmp [x],80
jb short @doprint
mov [x],0
inc [y]
cmp [y],25
jb short @doprint
mov [y],0
mov [clr],4
@doprint:
cmp [status],0
jz short @txtstring
mov bh,[y]
mov bl,[x]
mov ah,dl
mov al,10h
int 80h
jmp short @printc_done
@txtstring:
mov ax,TXTSEG
mov fs,ax
mov ax,80
mul [y]
add al,[x]
adc ah,0
shl ax,1
mov bx,ax
@dostring:
mov [fs:bx],dl
mov dl,[clr]
mov [fs:bx+1],dl
@printc_done:
inc [x]
retn
endp

;+-|setcol------------------------------------------------------------------+
;| dl = value
;|
;| set text-mode-attribute (color_bits)
;+--------------------------------------------------------------------------+
proc setcol
mov [clr],dl
retn
endp setcol
;+-|setpos|------------------------------------------+
;| dx: dh=Y pos; dl=X pos
;|
;| set absolute position of text-mode-printings
;+-----------------------------------------------------+
proc setpos
cmp dh,25
jae @setpos_e
cmp dl,80
jae @setpos_e
mov [x],dl
mov [y],dh
@setpos_e:
retn
endp setpos
;+-|printstr|------------------------------------+
;| bx=*string pointer
;|
;| prints null-terminated-string to screen
;+------------------------------------------------+
proc printstr
mov dl,[bx]
or dl,dl
jz short @printstr_end
push bx
call near printc
pop bx
inc bx
jmp short printstr
@printstr_end:
retn
endp
status db 0h
ends
end
Steve Dubrovich
2004-10-29 02:20:57 UTC
Permalink
Post by Florian Liebig
hello erik!
I really do not want to anger you too much but let me have an interruption on
your words right now.
I do not know if you are going to develop something os-independant like me, but
if you are, the things i've told you were right up to the income of your mail
and that really pisses me off !!!
1st) you won't need a starting jump
2nd) you won't need a BiosParameterBlock
3rd) you won't need to worry about 0x1FE significance
since i'm developing an os-independant boot manager that works with every OS
product, and, shall work on every bios loading strategy, I had to do some
research on different systems from 486 to P4. But when you tell me that on your
COMPAQ P3 this won't be the same, i'm afraid.
this means to me, that thos COMPAQ bios romcodes aren't builded to work with my
code !!
Because of this, I'd like to send you a short example out of my source that
works fine on both: a) floppies and b) ide's.
but it's definitely now being designed to make a floppy bootable and as you
will see, no JMP and no other signs are put in.
on all systems that i've tested up to now, and i'd like to swear about that,
they're not needed up to now!!
That (1,2,3) has been my experience as well, from an original ibm PC,
xt-clone, 486-clone, Dell P-II, Dell P4. However, Compaq has always
been abit different. AFAIK, the were the first to use a 2nd HD
Partition for the OS, as a diagnostic partition.

My thesis is this- the jump may be required in order to flush the
instruction prefetch queue on the Compaq. After all, we do not know
the machines' state prior to the boot sector load. The machine may be
in protected mode already, and exercising the bootstrap as a
supervised real mode process.
KVP
2004-10-29 07:01:42 UTC
Permalink
Post by Florian Liebig
hello erik!
I really do not want to anger you too much but let me have an interruption on
your words right now.
I do not know if you are going to develop something os-independant like me, but
if you are, the things i've told you were right up to the income of your mail
and that really pisses me off !!!
1st) you won't need a starting jump
False, some bioses do check the short jump + nop pair. (bytes 0 and 2)
Post by Florian Liebig
2nd) you won't need a BiosParameterBlock
True, this is only for fat formatted floppies. Other oses don't use it.
You can just leave it out without problems.
Post by Florian Liebig
3rd) you won't need to worry about 0x1FE significance
False, all pc compatible bioses should check this. Apparently, most machines
from bigger manufacturers (non asian ones) check this. (Ibm systems tend to
silently skip the floppy during the boot sequence, when they don't see the
0xaa55 flag.)

The only major os that was missing this feature was sco unix, and grub has
a specific workaround built-in, just to enable this buggy os to boot.
Post by Florian Liebig
since i'm developing an os-independant boot manager that works with every OS
product, and, shall work on every bios loading strategy, I had to do some
research on different systems from 486 to P4. But when you tell me that on your
COMPAQ P3 this won't be the same, i'm afraid.
this means to me, that thos COMPAQ bios romcodes aren't builded to work with
my code !!
Yes, they follow the standard. You should add the 3 bytes to the start, and
the 2 bytes to the end. (jmp short + nop and dw 0aa55h) It means that you
loose 5 bytes from the 512, but you will have a compatible loader.
Post by Florian Liebig
Because of this, I'd like to send you a short example out of my source that
works fine on both: a) floppies and b) ide's.
but it's definitely now being designed to make a floppy bootable and as you
will see, no JMP and no other signs are put in.
on all systems that i've tested up to now, and i'd like to swear about that,
they're not needed up to now!!
perhaps you've got the time to make that being assembled and written down to
one of your floppies in order to have me a short mail 8^] !!
The only thing i could not do for you is to make it be NASM compatible.
I use borland's turbo assembler with /m2 switch.
You should really read Ralph Brown's Interrupt List, since the video bios
already have a put character and advance cursor function, so your entire
code could be reduced to about 16 bytes. And the 'boot code' doesn't seem
to have a disk read function, so when you finally write it, you should
support both the old and the new disk interface. (the old chs for floppies
and old bioses, and the new lba for new harddisks)

Viktor
Florian Liebig
2004-10-30 21:19:47 UTC
Permalink
Post by KVP
You should really read Ralph Brown's Interrupt List, since the video bios
already have a put character and advance cursor function, so your entire
code could be reduced to about 16 bytes. And the 'boot code' doesn't seem
to have a disk read function, so when you finally write it, you should
support both the old and the new disk interface. (the old chs for floppies
and old bioses, and the new lba for new harddisks)
Viktor
hi viktor!
i know ralph browns list since a couple of years now, but on the other
hand - since
i'm developing os independant things, or for protected mode environment
- that list
isn't useful any longer.
the other words to say is that I modified that code in this case to be
exactly 512 bytes long. i removed the 2nd level loader, because no
kernel is needed in that example.
in the original code, a bios loader is implemented.
further on, you said, i could use video int's.
that cannot be done any longer when in prot.-mode. i don't use v86 mode.
the other thing is that the code works in a graphics mode with an own
font server as
well as in text modes (seen by the status byte, that holds informations
about
graphics mode). when you have a look at the 'printc' function, you'll
see, that text outputs are done via direct memory access to text mem, or
via int 0x80.
int 0x80 is where my font server resides.
so, with this given informations, you'll see that bios ints really cant
be used any longer, even if i hardly would like to do that.

Florian.
wolfgang kern
2004-10-31 12:33:18 UTC
Permalink
Florian Liebig wrote:

| ... that bios ints really cant be used any longer,
| even if i hardly would like to do that.

If you hardly like to... :)
My (KESYS) Os got a linker to true RM which returns to the
caller regardless of 16 or 32 bit PM.

Even this switches are just a few lines of code,
the whole story, including IRQ-service during RM and PM
without loosing a single event, wont fit one HD-sector.

But if you don't care to disable IRQs during RM-access,
all what's required is:
adjust segments to point to identical areas (I use HMA here)
for both RM and PM segments (inclusive stack-seg of course).


__
wolfgang
Steve Dubrovich
2004-11-07 17:52:37 UTC
Permalink
Post by KVP
Post by Florian Liebig
hello erik!
I really do not want to anger you too much but let me have an interruption on
your words right now.
I do not know if you are going to develop something os-independant like me, but
if you are, the things i've told you were right up to the income of your mail
and that really pisses me off !!!
1st) you won't need a starting jump
False, some bioses do check the short jump + nop pair. (bytes 0 and 2)
Post by Florian Liebig
2nd) you won't need a BiosParameterBlock
True, this is only for fat formatted floppies. Other oses don't use it.
You can just leave it out without problems.
Post by Florian Liebig
3rd) you won't need to worry about 0x1FE significance
False, all pc compatible bioses should check this. Apparently, most machines
from bigger manufacturers (non asian ones) check this. (Ibm systems tend to
silently skip the floppy during the boot sequence, when they don't see the
0xaa55 flag.)
The only major os that was missing this feature was sco unix, and grub has
a specific workaround built-in, just to enable this buggy os to boot.
I'll have to eat some crow. I've found that the Seagate SCSI ST-01
H.D. Controller's bios does check for 0xAA55 at the end of a floppy's
boot sector. It won't load the sector.

Using a Future Domain SCSI Controller allows the floppy boot w/o the
signature word. There's a difference in the controller bioses,
obviously.
Florian Liebig
2004-11-08 21:34:04 UTC
Permalink
Post by Steve Dubrovich
I'll have to eat some crow. I've found that the Seagate SCSI ST-01
H.D. Controller's bios does check for 0xAA55 at the end of a floppy's
boot sector. It won't load the sector.
Using a Future Domain SCSI Controller allows the floppy boot w/o the
signature word. There's a difference in the controller bioses,
obviously.
thank you for that information.
i'll rely on that, because my and all your research works say that 0xAA55 HAS to be present. a few hours
ago, i've read some antique books in our university that all say the same. even ide & scsi controller's
handbook ..
I update my loader code for all future uses.

Florian
Steve Dubrovich
2004-11-10 02:19:28 UTC
Permalink
Post by Florian Liebig
Post by Steve Dubrovich
I'll have to eat some crow. I've found that the Seagate SCSI ST-01
H.D. Controller's bios does check for 0xAA55 at the end of a floppy's
boot sector. It won't load the sector.
Using a Future Domain SCSI Controller allows the floppy boot w/o the
signature word. There's a difference in the controller bioses,
obviously.
thank you for that information.
i'll rely on that, because my and all your research works say that 0xAA55 HAS to be present. a few hours
ago, i've read some antique books in our university that all say the same. even ide & scsi controller's
handbook ..
I update my loader code for all future uses.
Florian
HAS to be present for floppy boot, no. Sould be for widespread
acceptability, yes. Has to be present for Hard Drive boot, hmm,
probably.

As a practical matter I'll point out that I've used cp/m-86 OS,
booting it from floppy, on a wide number of x86 computers without a
booting problem. That OS uses the last byte of the boot sector as a
media byte, which is never a part of word 0xAA55. I've booted it on
xt-clones, 286 epson, 486 EISA clone, dell P2, dell p2 laptop, dell
P4HT. [cp/m-86 is an antique OS designed for ibm PC, and XT.] The
modern port to 3 1/2 1.44m media uses 0x9001 [the word], and 3 1/2
720kb media formatted as 320k uses 0x01E5 [actually only uses 0x01 the
byte], as the last word of the boot sector.

The ST-01 controller exception, mentioned previously, was on an XT
clone. It is an odd occurence because, apparently the controller
cards' bios revectors int13h for floppy requests as well as HD
requests, and checks for 0xAA55 on both.

I think if you check the MBR code [on the hard drive] you will find
that the code, itself, checks for 0xAA55 as a validation word for the
MBR, but that is not RomBios code in itself.
Florian Liebig
2004-11-13 03:10:50 UTC
Permalink
Hello, sir.
So far, so good.
someone tried boot-up-code on a P3 with ->COMPAQ<- (!!) bios,
that takes no care of 0x1FE significance like 0xAA55 and on the other hand, I've seen many bootstraps that use

CLI
MOV SP,word
MOV AX,word
MOV SS,AX
...
instead of JMP SHORT xx or JMP NEAR xx in the beginning of the loader code.
Without this knowledge, I proceeded on developing a bootable loader for HD and DD.
So I came to the result, that those must-have-infos are kind of obsolete.
Works very fine on all models, EXCEPT compaq bios'ed computers, as Mr.Erik Larsson said in a letter some days
ago and this is the main reason, I've been skipped off those theses.
I now worry about the fact, that no one of my friends has a COMPAQ pc in their houses, to test some code on it
- but doesn't matter. I now use a 4-byte-update to my loader, what ain't be to be badlier than non-bootable
Post by Steve Dubrovich
HAS to be present for floppy boot, no. Sould be for widespread
acceptability, yes. Has to be present for Hard Drive boot, hmm,
probably.
ask Mr.Larsson !
Post by Steve Dubrovich
As a practical matter I'll point out that I've used cp/m-86 OS,
booting it from floppy, on a wide number of x86 computers without a
booting problem. That OS uses the last byte of the boot sector as a
media byte, which is never a part of word 0xAA55. I've booted it on
xt-clones, 286 epson, 486 EISA clone, dell P2, dell p2 laptop, dell
P4HT. [cp/m-86 is an antique OS designed for ibm PC, and XT.] The
modern port to 3 1/2 1.44m media uses 0x9001 [the word], and 3 1/2
720kb media formatted as 320k uses 0x01E5 [actually only uses 0x01 the
byte], as the last word of the boot sector.
perhaps you should have a try on a COMPAQ with that disquette! (mail me your results!!)
Post by Steve Dubrovich
The ST-01 controller exception, mentioned previously, was on an XT
clone. It is an odd occurence because, apparently the controller
cards' bios revectors int13h for floppy requests as well as HD
requests, and checks for 0xAA55 on both.
I think if you check the MBR code [on the hard drive] you will find
that the code, itself, checks for 0xAA55 as a validation word for the
MBR, but that is not RomBios code in itself.
I can't get the point, that you're trying to point out, but I think, checking for 0xAA55 in my installed
loader mustn't be.

Florian.
Erik Larsson
2004-11-13 19:00:08 UTC
Permalink
Just a small note. This thing with the starting bytes (jmp/nop) is really
needed on my Compaq PIII... But I also own an earlier Compaq PII computer,
and that computer boots up fine withot jmp/nop in the beginning.
So just testing your code on any Compaq won't do.. =/
Erik
Post by Florian Liebig
Hello, sir.
So far, so good.
someone tried boot-up-code on a P3 with ->COMPAQ<- (!!) bios,
that takes no care of 0x1FE significance like 0xAA55 and on the other
hand, I've seen many bootstraps that use
Post by Florian Liebig
CLI
MOV SP,word
MOV AX,word
MOV SS,AX
...
instead of JMP SHORT xx or JMP NEAR xx in the beginning of the loader code.
Without this knowledge, I proceeded on developing a bootable loader for HD and DD.
So I came to the result, that those must-have-infos are kind of obsolete.
Works very fine on all models, EXCEPT compaq bios'ed computers, as Mr.Erik
Larsson said in a letter some days
Post by Florian Liebig
ago and this is the main reason, I've been skipped off those theses.
I now worry about the fact, that no one of my friends has a COMPAQ pc in
their houses, to test some code on it
Post by Florian Liebig
- but doesn't matter. I now use a 4-byte-update to my loader, what ain't
be to be badlier than non-bootable
Post by Florian Liebig
Post by Steve Dubrovich
HAS to be present for floppy boot, no. Sould be for widespread
acceptability, yes. Has to be present for Hard Drive boot, hmm,
probably.
ask Mr.Larsson !
Post by Steve Dubrovich
As a practical matter I'll point out that I've used cp/m-86 OS,
booting it from floppy, on a wide number of x86 computers without a
booting problem. That OS uses the last byte of the boot sector as a
media byte, which is never a part of word 0xAA55. I've booted it on
xt-clones, 286 epson, 486 EISA clone, dell P2, dell p2 laptop, dell
P4HT. [cp/m-86 is an antique OS designed for ibm PC, and XT.] The
modern port to 3 1/2 1.44m media uses 0x9001 [the word], and 3 1/2
720kb media formatted as 320k uses 0x01E5 [actually only uses 0x01 the
byte], as the last word of the boot sector.
perhaps you should have a try on a COMPAQ with that disquette! (mail me your results!!)
Post by Steve Dubrovich
The ST-01 controller exception, mentioned previously, was on an XT
clone. It is an odd occurence because, apparently the controller
cards' bios revectors int13h for floppy requests as well as HD
requests, and checks for 0xAA55 on both.
I think if you check the MBR code [on the hard drive] you will find
that the code, itself, checks for 0xAA55 as a validation word for the
MBR, but that is not RomBios code in itself.
I can't get the point, that you're trying to point out, but I think,
checking for 0xAA55 in my installed
Post by Florian Liebig
loader mustn't be.
Florian.
Erik Larsson
2004-10-29 18:59:11 UTC
Permalink
Hey =)
This is the way my compaq computer works. I'm sure compaq isn't world famous
for obeying standards, but my compaq PIII won't even try to read in the 512
bytes from the floppy unless they start with those jmp/nop starting bytes. I
guess you'd better take that into account when writing your boot manager.
However, I could test your code, but I don't have borland turbo assembler.
Is that a commercial product, or can I fetch it from somewhere for free?
Maybe you could send me a binary 512 byte file that I could write to a
floppy instead? ***@telia.com will do.
Greetings from an even colder, darker but maybe not rainier Sweden. : )
Erik
Post by Florian Liebig
hello erik!
I really do not want to anger you too much but let me have an interruption on
your words right now.
I do not know if you are going to develop something os-independant like me, but
if you are, the things i've told you were right up to the income of your mail
and that really pisses me off !!!
1st) you won't need a starting jump
2nd) you won't need a BiosParameterBlock
3rd) you won't need to worry about 0x1FE significance
since i'm developing an os-independant boot manager that works with every OS
product, and, shall work on every bios loading strategy, I had to do some
research on different systems from 486 to P4. But when you tell me that on your
COMPAQ P3 this won't be the same, i'm afraid.
this means to me, that thos COMPAQ bios romcodes aren't builded to work with my
code !!
Because of this, I'd like to send you a short example out of my source that
works fine on both: a) floppies and b) ide's.
but it's definitely now being designed to make a floppy bootable and as you
will see, no JMP and no other signs are put in.
on all systems that i've tested up to now, and i'd like to swear about that,
they're not needed up to now!!
perhaps you've got the time to make that being assembled and written down to
one of your floppies in order to have me a short mail 8^] !!
The only thing i could not do for you is to make it be NASM compatible.
I use borland's turbo assembler with /m2 switch.
greetings from over here in rainy cold -but good old germany,
Florian.
;ÛßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßÛ
;Û code written by f. liebig Û
;Û loader.asm Û
;ÛÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÛ
; DEFINITIONS for boot_loader
;
; written by F. Liebig
;+-->include loader.inc
;v
STACK_SEG equ 01000h
KERNEL_SEG equ 01000h
KERNEL_OFF equ 00200h
LOADER_SEG = KERNEL_SEG
LOADER_OFF equ 00000h
HD0_SEG = KERNEL_SEG
HD0_OFF = 0FFFFh - STACK_SIZE - SECTOR_LEN
HD0_LABELS = 0FFFFh - STACK_SIZE - SECTOR_LEN - 4*16 - 4*8
BUF = 1024 * 32
FONT_SEG = 02000h
FONT_OFF = 00000h
STACK_SIZE = _i8086_minimum_framesize * _numberOF_nested_function_calls
_i8086_minimum_framesize = 8 * WORD_SIZE
_numberOF_nested_function_calls = 0200
WORD_SIZE = 2h
SECTOR_LEN = 512
IO_TRIES = 00Fh
;now the originally loader code follows
;ideal directive only used for borland's turbo assembler
ideal
segment _loader byte public use16
p386
assume cs:_loader, ds:_loader, es:_loader, fs:_loader,gs:_loader
cli
xor ax,ax
dec ax
mov sp,ax
mov ax,STACK_SEG ;have one here on your self
mov ss,ax
; ss:sp is now set for my further use!
mov ax,7c0h
mov ds,ax
mov es,ax
; ds is ready for use only while this startup_code_functios
mov ax,0b800h
mov fs,ax
xor bx,bx
mov cx,80*25
mov ax,203h
mov [fs:bx],ax
inc bx
inc bx
label _cr0
_copyright_ db '(C)&written by F.Liebig',0
label _cr0e
label fb0
firstmsg db '** FL loader (2+400æ)x10^3 **', 0h
label fb0e
mov dl,7
call near setcol
mov dh,0
mov dl,40- ((_cr0e-_cr0) SHR 1)
call near setpos
mov bx,offset _copyright_
call near printstr
mov dh,12
mov dl,40- ((fb0e-fb0) SHR 1)
call near setpos
mov bx,offset firstmsg
call near printstr
call near getkey
jmp last_but_not_least
label hello_world
label hello_world0
label further_on
db 'further on: were posting around in news://news.comp.lang.asm.x86',0
label further_on0
label quietplease
db 'I would like to make even more outputs but we will halt this system now
!',0
label quietplease0
mov dh,22
mov dl,40-((hello_world0-hello_world) SHR 1 )
call near setpos
mov bx,offset hello_world
call near printstr
call near getkey
mov dh,23
mov dl,40-((further_on0-further_on) SHR 1 )
call near setpos
mov bx,offset further_on
call near printstr
call near getkey
mov dh,24
mov dl,40-((quietplease0-quietplease) SHR 1 )
call near setpos
mov bx,offset quietplease
call near printstr
call near getkey
jmp short shutdown
proc getkey
xor ah,ah
int 16h
retn
endp
proc shutdown
hlt
retn
endp
;PUT IN HERE CODE that you'd like to insert very much
;+-|printc|-----------------------------------------------------------------
+
Post by Florian Liebig
;| dl = ascii - value (character)
;|
;| prints single character on screen and updates cursor
;+--------------------------------------------------------------------------
+
Post by Florian Liebig
proc printc
TXTSEG equ 0b800h
x db 0
y db 0
clr db 0
cmp [x],80
mov [x],0
inc [y]
cmp [y],25
mov [y],0
mov [clr],4
cmp [status],0
mov bh,[y]
mov bl,[x]
mov ah,dl
mov al,10h
int 80h
mov ax,TXTSEG
mov fs,ax
mov ax,80
mul [y]
add al,[x]
adc ah,0
shl ax,1
mov bx,ax
mov [fs:bx],dl
mov dl,[clr]
mov [fs:bx+1],dl
inc [x]
retn
endp
;+-|setcol------------------------------------------------------------------
+
Post by Florian Liebig
;| dl = value
;|
;| set text-mode-attribute (color_bits)
;+--------------------------------------------------------------------------
+
Post by Florian Liebig
proc setcol
mov [clr],dl
retn
endp setcol
;+-|setpos|------------------------------------------+
;| dx: dh=Y pos; dl=X pos
;|
;| set absolute position of text-mode-printings
;+-----------------------------------------------------+
proc setpos
cmp dh,25
cmp dl,80
mov [x],dl
mov [y],dh
retn
endp setpos
;+-|printstr|------------------------------------+
;| bx=*string pointer
;|
;| prints null-terminated-string to screen
;+------------------------------------------------+
proc printstr
mov dl,[bx]
or dl,dl
push bx
call near printc
pop bx
inc bx
jmp short printstr
retn
endp
status db 0h
ends
end
Frank Kotler
2004-10-25 19:20:05 UTC
Permalink
This post might be inappropriate. Click to display it.
Steve Dubrovich
2004-10-29 01:43:42 UTC
Permalink
Post by Frank Kotler
Post by Florian Liebig
hi erik!
you don't need that signature at the end of the loader as well you don't need
the starting bytes as someone posted you in a reply.
the only reason for those few bytes is that any foreign os may read out that
disquette because it contains a media ID byte a.s.o.
so, if you want that disquette to be readable under MS or linux or whatever
without getting an error message like "sector 0 is bad" or "sector 0 mark not
found" , you need the given information at beginning of your loader as someone
posted to you.
Hi Florian,
Unless I'm mistaken, there are two issues in play here. As you point
out, the "boot parameter block" or "bios parameter block" - I don't know
the "correct" name... the stuff the "jmp" jumps over - is only necessary
if you want the "development OS" to recognize the floppy. I find this
convenient, but it isn't necessary.
Bios Parameter Block is the correct reference, this is found on
msDos/IBMdos formatted media.
Post by Frank Kotler
The other issue is what the bios will boot, and when it'll display a
"system not found" error, or continue looking for bootable drives and
boot "drive C:". On *my* machine, the bios is a "slut" - it'll
apparently load any old thing, regardless of a "jmp" at the start or the
sig at the end. I discovered this by examining a bootsector for CPM-86,
which uses the last byte as a "disk type" parameter of some sort - 0,
45h, and 90h were valid, IIRC. But from what Erik's posted, his bios
*does* care about starting with a "jmp" (and presumably the 0AA55h sig,
as well - might be interesting to experiment further...)
CP/M-86 uses a 2 stage boot loader, i.e. the boot sector loads the 2nd
half of a 8 sector/track 5 1/4 floppy, sectors 5-8 contain the
secondary boot strap program. The last byte of the boot sector is the
'media' flag, if 00h then the diskette is SSDD, if 01h it is DSDD.
The port to more modern media, 3 1/2 diskettes, use other values for
media detection.

The 0AA55h signature word, as best as I could determine, is a
carryover from the original ibm PC, as the signature is also used as a
boundry start of Rom Bios Driver code on plug-in cards.

IBM instituted the hard drive Partition Table to allow for up to 4
OSes on a hard drive, and the partition table also ends with the
signature word. AFAIK, all rombioses do check the partition table for
the signature word, if present, then the table is accepted as valid
for further examination by the RomBios.
Post by Frank Kotler
It's only a tentative conclusion, but I think if you want your
bootsector to work on "any machine", you *do* need to start with either
"jmp overBPB" or "jmp short overBPB"/"nop" (I doubt if the "nop" is
strictly necessary, but the "OEM string" wants to start 3 bytes in, if
you want FAT12 compatibility), and the 0AA55 at offset 1FEh.
Fat compatibility requires the BPB as well. When we talk of 'fat' we
are talking about msDos _OS_. If there is no OS loaded, or used to
otherwise read the diskette, then the BPB is moot. As an experiment,
I've used a BPB of all nulls in a test boot sector, and Dos sees an
unformatted diskette _from within that OS_. The test boot sector
still boots and gives it message, from a cold boot state.
Post by Frank Kotler
Another interesting series of experiments would be to determine what the
*minimum* BPB would be in order to fool dos and/or Linux into thinking
it was a valid disk. As you point out, the MediaID byte, at least, ought
to be valid... My floppy drive's broken right now, so I'm not even
tempted :)
Best,
Frank
Loading...