Stack problem

[beyondsociety]

Does the location of the stack depend on the location that you load the program from.

cli
mov ah,0x9000 ; does this
mov ss,ax
mov sp,0xFFFF ; and this
sti

mov ax,0x1000 ; depend on this
mov es,ax
mov bx,0x0000 ; and this

[Schol-R-LEA]

Does the location of the stack depend on the location that you load the program from.

cli
mov ah,0x9000 ; does this
mov ss,ax
mov sp,0xFFFF ; and this
sti

mov ax,0x1000 ; depend on this
mov es,ax
mov bx,0x0000 ; and this

No, it shouldn't, so long as the loaded data doesn't stomp on the stack (e.g., you set the stack to 0x9000 and then for some unimaginable reason that seemd like a good idea at the time, you set the extra segment to 0x9E00, with the result that the loaded data overwrites the stack) or vis versa. The code sample you've given looks OK, AFAICT. Wherever the problem you solving lies, I don't think it is here.

[beyondsociety]

[attachment deleted by admin]

[frank]

Code: Select all

 bsOEM       db "NYAOS1.0"               ; OEM String
 bsSectSize  dw 512                      ; Bytes per sector
 bsClustSize db 1                        ; Sectors per cluster
 bsRessect   dw 1                        ; # of reserved sectors
 bsFatCnt    db 2                        ; # of fat copies
 bsRootSize  dw 224                      ; size of root directory
 bsTotalSect dw 2880                     ; total # of sectors if < 32 meg
 bsMedia     db 0xF0                     ; Media Descriptor
 bsFatSize   dw 9                        ; Size of each FAT
 bsTrackSect dw 18                       ; Sectors per track
 bsHeadCnt   dw 2                        ; number of read-write heads
 bsHidenSect dd 0                        ; number of hidden sectors
 bsHugeSect  dd 0                        ; if bsTotalSect is 0 this value is
                                         ; the number of sectors
 bsBootDrv   db 0                        ; holds drive that the bs came from
 bsReserv    db 0                        ; not used for anything
 bsBootSign  db 29h                      ; boot signature 29h
 bsVolID     dd 0                        ; Disk volume ID also used for temp
                                         ; sector # / # sectors to load

isn't that all useless...?!?
this is the bootsector... not filesystem informatinon

Code: Select all

 mov [bootdrv],dl

huh? you didn't tell the bootsector where ds is yet...

put this in your code (after begin:)
xor ax,ax
mov dx,ax

why do you do cli ... sti? you didn't switch to pmode...

Code: Select all

mov dl,0      ;Drive (0 is floppy)

floppy can be 1 too....
use [drive].
mov dl,[drive]

[beyondsociety]

The Information after the start label is so partcopy won't override the dos boot record. Thus if I didn't add this, I wouldn't be able to access the floppy drive or be able to put anything on it.

xor ax,ax
mov dx,ax

Shouldn't it be:

xor ax,ax
mov ds,ax

Or am I wrong?

[frank]

> The Information after the start label is so partcopy won't override >the dos boot record. Thus if I didn't add this, I wouldn't be able to >access the floppy drive or be able to put anything on
huh? so without that you can't access the floppydrive?
why not use rawrite then ?


>Or am I wrong?
nope

[beyondsociety]

Cause I like to use partcopy. The only time I use rawrite is to copy a .img file to the floppy like when creating a bootdisk.

So I was right?

[frank]

>So I was right?

yup,
ofcourse it is ds instead of dx..
typing-mistake

[beyondsociety]

Should I leave the push cs and the pop ds in my bootsector or do I not need it because I added xor ax,ax and mov ds,ax instead.

[frank]

>Should I leave the push cs and the pop ds in my bootsector or do I >not need it because I added xor ax,ax and mov ds,ax instead.

do a jump to start, that will iniitialize cs automatically

[Schol-R-LEA]

The Information after the start label is so partcopy won't override the dos boot record. Thus if I didn't add this, I wouldn't be able to access the floppy drive or be able to put anything on it.

Actually, this 'extra' data has nothing to do with what program you use to write the boot block with. The BIOS Parameter Block (BPB), also called the Disk Information Block (DIB), is a data structure used by FAT filesystems to identify crucial structures on the disk, such as the number, location and size of the File Allocation Tables. It is necessary to include it if you intend to read the disk from a conventional FAT FS, regardless of how you write it to the disk.

Note, however, that certain fields of the DIB (notably the Reserved Block Size) do not offer the facilities that they would appear to. Also, if you write a new DIB to a disk that is already MS-DOS FAT12 formatted, you'd better be sure that the important information is the same in the new one as in the old, or you're disk is sure to get corrupted...

[Krom]

Hey read the thread "First i cant link, now i cant enter pmode" there is my boot sector, the file is "RFBOOT.ASM" take a look to it

[df]

one thing, never set the stack to an odd number, its not a hard rule, but safer to use -2 0xFFFE instead of -1 0xFFFF

[beyondsociety]

Why is this so?

[Curufir]

Maybe something to do with only being able to push 16 and 32 bit registers/memory onto the stack. Means you need it divisible by 2 bytes. Or at least that's my first instinct. I'm as curious as you what the real reason is