OSDev.org

[attachment deleted by admin]

You are overwriting the bios

Mov Ax,1
Mov Ds,Ax
Mov Es,Ax


Mov Bx,DiskBuffer


DiskBuffer ???equ???0

The destination is ES:BX so 0001:0000 (or 0x00010). The IVT starts at 0000:0000 at the BIOS data area follows it. The first "clear" spot is 0x0600 (0060:0000)

crazybuddha wrote: Mov Ax,1
Mov Ds,Ax
Mov Es,Ax


Mov Bx,DiskBuffer


DiskBuffer ???equ???0

The destination is ES:BX so 0001:0000 (or 0x00010). The IVT starts at 0000:0000 at the BIOS data area follows it. The first "clear" spot is 0x00600 (0060:0000)

I don't understand this really... The Interrupt Vector... isn't it at the first segment? I try to copy to the second by setting Es to 1... So I shouldn't write over the IV... this is weird...

-----

Oh... I didn't read to the end :-[ Hadn't thought about the BIOS Data Area... Oki then... Thanx.

Peter_Vigren wrote: I don't understand this really... The Interrupt Vector... isn't it at the first segment? I try to copy to the second by setting Es to 1... So I shouldn't write over the IV... this is weird...

Forgive me if I'm wrong, but you may confused about segments. They are not mutually exclusive chunks of 64k. If you have 0x0001 is ES and 0x0000 in BX, then the actual location in memory is 0x10 (or 16), with each location being one byte. The IVT is 256 four-byte entries, so it runs all the way to 0030:00FF. The BIOS data area starts at 0040:0000 and runs to 0050:00FF.

You have from 0060:0000 to 0900:FFFF to play with, although if you need anything in the bootloader, it is stuck at 07c0:0000, so best not to overwrite that if you do.

To find a memory byte, shift the segment 4 bits to the left (one spot in hex), then add the offset.

[attachment deleted by admin]

I made the following modifications. It prints a '0' followed by a '1'.

Bits 16
Org 7C00h

mov AH, 0eh
xor BX,BX
mov AL,'0'
Int 10h

Mov Ah,0
Mov Dl,0
Int 13h

Mov Ax,0x60 ; CHANGE
Mov Ds,Ax
Mov Es,Ax

Mov Ah,02
Mov Al,1 ; CHANGE
Mov Cl,2
Mov Ch,0
Mov Dl,0
Mov Dh,0
Mov Bx,DiskBuffer
Int 13h

mov AH, 0eh
xor BX,BX
mov AL,'1'
Int 10h

; CHANGE deleted some code here

   jmp $ ;CHANGE to loop

DiskBuffer   equ   0

Nothing   times   510 db 0 ;CHANGE
BootSig         db   0x55, 0xAA

crazybuddha wrote: Forgive me if I'm wrong, but you may confused about segments. They are not mutually exclusive chunks of 64k. If you have 0x0001 is ES and 0x0000 in BX, then the actual location in memory is 0x10 (or 16), with each location being one byte. The IVT is 256 four-byte entries, so it runs all the way to 0030:00FF. The BIOS data area starts at 0040:0000 and runs to 0050:00FF.

You have from 0060:0000 to 0900:FFFF to play with, although if you need anything in the bootloader, it is stuck at 07c0:0000, so best not to overwrite that if you do.

To find a memory byte, shift the segment 4 bits to the left (one spot in hex), then add the offset.

What??! Aren't all segments 64 kb each????? Now I'm _really_ confused... Since everywhere I have read about real mode segments it said that every segment is a 64 kb area in memory...

They only have the *potential* to be 64k, if the offset goes to 0xFFFF.

-------------------
The following code is a trick to reset the CS:IP, but you don't have a stack set up to be PUSHing onto, and (unless I'm mistaken) you don't have any code at 0060:0000 to execute, so the IP will just be happily incrementing through your memory until it happens to hit a sequence of bytes it might interpret as being meaningful.


Push Word 60h
Push Word 0
Retf

Hlt

crazybuddha wrote: They only have the *potential* to be 64k, if the offset goes to 0xFFFF.

I have to think about that a little while... *confused*

crazybuddha wrote: The following code is a trick to reset the CS:IP, but you don't have a stack set up to be PUSHing onto, and (unless I'm mistaken) you don't have any code at 0060:0000 to execute, so the IP will just be happily incrementing through your memory until it happens to hit a sequence of bytes it might interpret as being meaningful.


Push Word 60h
Push Word 0
Retf

Hlt

But the int13 read should have placed the code at 0060:0000 since the buffer pointed to that position, didn't it? But the stack pointer must point somewhere, must it not? Wait... *checking HelpPC*

"30:00 256bytes Stack area used during post and bootstrap"

Doesn't the stack pointer point to that location?

And by the way... the only "real" changes to the code you did was the infinite jump and decreasing the sectors to be read to only 1, am I correct?

Yes. Those were the only "real" changes (except for setting ES = 0x60).

Yes. SS:SP point somewhere. But you might want to be concerned about using them without checking/setting them.

If the second sector on your floppy contained executable code, then you would be okay (although there shouldn't be any need for HLT if so).

-----------------------------

Regarding segment:offset, this weird scheme was meant to accomodate a 20-bit address bus, but the registers were only 16-bit. So fill the "leftmost" nibbles of the address bus with the segment register value, then add on the offset. This is how real mode is able to access 1 meg (20 bits). It's pretty clever, but as they say...

"Intel puts the 'backwards' in backwards compatible".

to make it clear once for all, when you use [segment:offset] you're in fact addressing [segment*16+offset] absolute address. As offset is a 16 bits register, you can address 64K of contiguous bytes without changing your segment register, but

[segment:offset] is also
[segment+1:offset-16] and [segment+2:offset-32], [segment-1:offset+16], ... as long as you don't go in negatives or >64K offsets. Thus you have virtually 4096 ways to address the same byte in IA-32 (if i'm counting well: 65536/16)

Eh... is it only me that thinks that sound a little crazy (surely true but... crazy)?

Anyway... the code doesn't work... As I wrote, a zero is displayed and after that "10" is added in an endless loop...

Peter_Vigren wrote:
But the int13 read should have placed the code at 0060:0000 since the buffer pointed to that position, didn't it? But the stack pointer must point somewhere, must it not? Wait... *checking HelpPC*

"30:00 256bytes Stack area used during post and bootstrap"

Doesn't the stack pointer point to that location?

And by the way... the only "real" changes to the code you did was the infinite jump and decreasing the sectors to be read to only 1, am I correct?

about INT13: yes, it *should*, but it's common knowledge that an average of 3 attempts for INT13 sector reading on a floppy are necessary to get the correct sector, especially when turning the motor on. This suxx (really), but that's the way it is for some hardware reasons ... So i hardly suggest you to check the error status of INT13 and re-try your load until it works ...
For now, you jump to your buffer that is probably full of 00 (add al,[si+bx] or something alike and then hit your bootsector again...

about the stack, i feel this one is *VERY* close to interrupt vectors, so a stack overflow could have very nasty results. The BIOS engineers have probably spent coffie-nights trying to find out a way to stay in these 256 bytes in any interrupts configurations, but it's good practice to setup another stack in a less risky place (using a segment that won't override anything, etc.) that you fully control.

Pype.Clicker wrote: For now, you jump to your buffer that is probably full of 00 (add al,[si+bx] or something alike and then hit your bootsector again...

I will reread the sectors 3 times then... but I'm not sure... I think that I tested the code so it hlt (or rather jmp $) after the readingprocess... from what I remembered I never tried to do the real jump away... And if that's true then... But I will check that out... I hope that's it... or else I will go mad