boot-sector and bochs problems

[saltlamp]

I am simply trying to read from the data-region of the disk (which is, in fact, 33 sectors from the start. I am using a floppy-disk), and the boot-disk works, but is just a blank screen.

Is my use of segmentation off? shouldn't 0050:0000 and 0000:0500 be interchangeable?

Am I not reading from the correct part of the disk? I can open the image in a hex editor, and at offset 0x4200 (0x4200 / 512 (decimal) is 33 (decimal) is the exact same code found in the IO.ASM file that I wrote.

Also, as a sidenote: Using the bochs (GUI) debugger, when ever a 'mov cx, ...' or instruction happens, CX never changes its value in the debugger. (at least for me). is something wrong with my build of bochs, or is this correct behavior? same with the SP register. Only increments (INC, DEC, ADD, SUB, etc), change its value (on my end), never anything else. I don't know why lol

And please, forgive me if I am making one heck of a mistake and overlooking something important...

Code: Select all

NULL	EQU 0

BOOTSEG	EQU 07C0H 
LOADSEG	EQU 0AE0H ; ignore; not used

	JMP  SHORT RSTREG
	NOP

	DB "PEDOS1.0"
BPBV00:	DW 512		; Bytes per Disk-sector
BPBV01:	DB 1		; Disk-sector per disk-cluster
BPBV02:	DW 1		; Reserved disk-sectors
BPBV03:	DB 2		; how many FATS are on the disk
BPBV04:	DW 224
	DW 2880
	DB 0F0H
BPBV05:	DW 9
BPBV06:	DW 18
BPBV07:	DW 2
	DD 0
	DD 0
	DB 0
	DB 41
	DB 0
	DB "           "
	DB "FAT12   "

	ORG 7C00H
	
RSTREG:
	XOR  AX, AX
	MOV  DS, AX

	MOV  AX, WORD BOOTSEG
	CLI
	MOV  SS, AX
	MOV  SP, 1024
	STI
	
;	XOR  DX, DX
;	INT  13H
;

	PUSH 0050H
	POP  ES

	MOV  AX, 201 ; AH=02, AL=01; correct?
	MOV  CX, 33 ; CH=00, CL=33; correct?

; read the bochs sidenote: not sure if its related to actual hardware ; or just a bug in the ;debugger softare.

	XOR  DX, DX 
	XOR  BX, BX
	INT  13H
	JC   SHORT DSKERR

	PUSH 0000H
	PUSH 0500H
	RETF

;
; If any errors have occurred during boot up,
; then alert the user, and halt the system, and
; retstart the system if requested.
;

DSKERR:
	LEA  SI, [ERRMSG]
PRNSTR:
	LODSB
	OR   AL, 0
	JZ   DSKHLT
	MOV  AH, 14
	MOV  BX, 7
	INT  16
	JMP  PRNSTR
DSKHLT:
	XOR  AX, AX
	INT  22
	INT  25

ERRMSG:	DB "Non-System disk or disk error...replace and try again when ready."
	DB NULL

DOSFLE:	DB "SHELL   SYS"
IOSFLE:	DB "IO      SYS"

	TIMES 510 - ($	- $$) DB 0

;
; End of the boot-sector.
;
	DW 0AA55H

Thanks for anything!

[nullplan]

Is my use of segmentation off? shouldn't 0050:0000 and 0000:0500 be interchangeable?

No, they aren't. They do resolve to the same linear address, though. But if you use CS-relative addressing in the loaded code, or if you copy CS into DS, you better get that segment correct to the value needed by the code.

Code: Select all

   MOV  AX, 201 ; AH=02, AL=01; correct?

It would be if the 201 was hexadecimal. As it stands, however, you set AH to 0 and AL to 201, or 0xCB. According to RBIL that means you ordered a disk system reset.

Even if you had not made that blunder, though, you are deleting DX, and with that, DL, which BIOS gave you as the drive number to boot from. Don't do that. Preserve the DL!

Also, with NASM, you can directly order a far jump like this:

Code: Select all

 jmp 0:0x500

No need to fiddle with stack and far returns. You get to do that enough once you start with protected mode.

And one last thing before I go: The error message is misleading. You only print it if there was a disk error. So there is no possibility of the message occurring because its content was wrong.

[Octocontrabass]

Am I not reading from the correct part of the disk?

You are not. Well, you're not reading from the disk at all, but see the above post.

After you fix that, you should start getting disk read errors. That's because the sector you want to read is LBA 33, but you need to convert that value to CHS before you pass it to INT 0x13. For the standard formatting of a 1.44MB floppy disk, the geometry is (80,2,18). You can take that geometry and your desired LBA and put it into a calculator like this one to come up with the correct parameters. (Assuming the 1.44MB floppy disk, you want to pass (0,1,16) to INT 0x13.)

And please, forgive me if I am making one heck of a mistake and overlooking something important...

What's up with your ORG statement? I'm not familiar with every x86 assembler out there, but you probably want it at the top since the very first byte of your boot sector will be loaded to linear address 0x7C00.

What's up with your stack? It's only 512 bytes, that's not a lot of space.

Is there any particular reason you're using decimal for so many of your numbers? It's a bit jarring when comparing your code with BIOS documentation that almost exclusively uses hexadecimal. (Unfortunately, there's just enough inconsistency that it's hard to say you should always use one or the other...)

[MichaelPetch]

NASM's ORG is peculiar. You can only have one of them in a file (if you are outputting as bin format) and it doesn't matter where you place it in the file, it will act as if it was placed at the very beginning.

[saltlamp]

Am I not reading from the correct part of the disk?

You are not. Well, you're not reading from the disk at all, but see the above post.

After you fix that, you should start getting disk read errors. That's because the sector you want to read is LBA 33, but you need to convert that value to CHS before you pass it to INT 0x13. For the standard formatting of a 1.44MB floppy disk, the geometry is (80,2,18). You can take that geometry and your desired LBA and put it into a calculator like this one to come up with the correct parameters. (Assuming the 1.44MB floppy disk, you want to pass (0,1,16) to INT 0x13.)

And please, forgive me if I am making one heck of a mistake and overlooking something important...

What's up with your ORG statement? I'm not familiar with every x86 assembler out there, but you probably want it at the top since the very first byte of your boot sector will be loaded to linear address 0x7C00.

What's up with your stack? It's only 512 bytes, that's not a lot of space.

Is there any particular reason you're using decimal for so many of your numbers? It's a bit jarring when comparing your code with BIOS documentation that almost exclusively uses hexadecimal. (Unfortunately, there's just enough inconsistency that it's hard to say you should always use one or the other...)

Very, very sorry for late replies! But I can answer a few of your questions.

I'm using decimal for certain values that I find easier to interpret in decimal, rather than hex. such as, 1024, 512, and if I use hex, it's mostly for numbers that I find are more fitting to be in hex, such as, 200H. I now realize that I was not doing it correctly with the disk-read interrupt being 201 in decimal. For some reason, I was thinking that the 2 in 201 would be in AH, and 1 in AL. But that's only true if I had the value in hex, so that was completely my bad.

I was using a 512 byte stack because I figured that 512 was plenty. It's not like it's overriding my boot-code. in all honesty, though, I really don't have anything special going on that would require more than that, so it's easier for me to recognize 1024 (1 KB)and work with that number. Plus, I've never encountered a problem.

And like Micheal pointed out, it doesn't matter 'org' is, since it's sort of a 'pre-processor' directive, kinda.