flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
Mac2004 17 Mar 2007, 04:18
Hi Rhyno!
I just took a quick look at your source. Did you notice that you actually point your es segment to the same location in memory where you load your secondary file. in boot code: Quote: mov ax, 0060h secondary file code: Quote: org 0600h In short you set your es to point 60h and then you load your secondary file to the same location and jump to it. regards, Mac2004 |
|||
![]() |
|
rhyno_dagreat 17 Mar 2007, 14:19
Hey! I know that I do that because that's what I did in my other test OS that loads a program, here's the code for it:
Code: use16 org 0x7C00 jmp Start ;FILESYSTEMDATA FileNumber rb 5 FileAddr rw 5 SectorSize db 512 FileSize db ? FileName dw ? ;DATA msg db "Hello World!", 13, 10, 0 ;13 = Carriage Return, 10 = New Line, 0 = End of String err db "Error!", 13, 10, 0 hur db "Hurrah!", 13, 10, 0 buffer dw 0 Sectors db 1 Start: mov si, msg call PrintFunction ;call ConsoleFunction ;Reserved for later use mov ax, 0060h mov es, ax mov bx, 0000h mov ah, 02h mov al, [Sectors] ;Sectors to be read mov ch, 0 mov cl, 2 mov dh, 0 int 13h jmp ReadFileStart Hang: jmp Hang ReadFileStart: cmp byte [bx], 0xFD je GotoFile inc bx jmp ReadFileStart GotoFile: mov [FileAddr], bx inc bx jmp bx ;CONSOLE RESERVED FOR LATER USE ConsoleFunction: mov ah, 00h int 0x16 mov bp, buffer ;cmp ah, 0x1C ;je Check cmp ah, 0x01 je Done mov ah, 0x0E int 0x10 mov [bp], al inc bp jmp ConsoleFunction PrintFunction: lodsb cmp al, 0 je Done mov ah, 0x0E int 0x10 jmp PrintFunction Done: ret ;Fill in emptyness with X's times 510-($-$$) db 'X' dw 0xAA55 org 0600h FHeader db "SOS1","Hello World", 0, 0xFC, "prg", 0, 0xFD FData: jmp ProgStart HelloMsg db "Hello world from Small 16-bit OS!", 13, 10, 0 ProgStart: mov si, HelloMsg call PrintFunction ;FEnd db "FEND" times 512-($-$$) db 'X' And this works fine. If there's something I'm slightly looking over that can make a huge bit of difference, please let me know. -Ryan "Rhyno" L. |
|||
![]() |
|
gdev 18 Mar 2007, 19:35
Here are my thoughts for the first code you posted:
you start the program as usual at 0x7C00 and CS=0 so all you first sector fits in the range 0x7C00,0x7C00+512 and in particular all the functions are at a physical address in this range, let's denote 'a' the address of PrintF and 'b' the address of DirCommand. So to call those functions the segmented addresses are respectively 0:a and 0:b. Your first call are correct as CS=0 indeed. Then you copy the second sector at the physical address 0x600 and you _jump_ there with a long jump 0x60:0 meaning that now CS=0x60. So when you call PrintF and DirCommand, you call in fact 0x60:a and 0x60:b instead of 0:a and 0:b... So the behavior of the program may indeed be eratic and that's surprising you fall on the pattern you describe (I think it could be worse)...or I'm completely wrong which is possible too ![]() This is just my interpretation, I didn't check it. Hope that will help. |
|||
![]() |
|
rhyno_dagreat 19 Mar 2007, 00:58
I tried moving the Dir Function to the new place after the program is run, and made a special copy of the print function for the program and it still acts the same way. I really don't know what to do.
![]() |
|||
![]() |
|
Dex4u 19 Mar 2007, 02:39
Here are some pointers, 1. first you can only load max 18 sector (1 track) like this, then you need to move head, then inc CH, etc.
2. A sector is 512bytes in size, you are loading to the same place twice and each sector your only adding 2 to address. 3. How do you think you will find 0xbf ?. 4. You should alway test after read/write for error and try at least 3 times. Why it does not crash, i do not know. |
|||
![]() |
|
rhyno_dagreat 19 Mar 2007, 05:28
Thanks for the tip, I'll look more into it in the morning when I wake up.
|
|||
![]() |
|
rhyno_dagreat 19 Mar 2007, 15:48
Well... I've thought about it, and the most logical error is it's a bug with BOCHs, so I'm not too worried about it all.
|
|||
![]() |
|
gdev 20 Mar 2007, 15:49
hmmm, if you do think this is the emulator that is buggy, the right thing to do is to test the
program with another emulator, like qemu, in general, assuming that the problem comes from the platform/library or anything else that support the program execution is the very last possibility to think of, because all those tools are widely tested and checked. Besides, your program do not do anything exotic that could suggest a bug from bochs (but well, this is indeed a tiny possibility). Did you try to replace the 'jmp 0060h:0000h' by 'jmp 0x600' in order to avoid rewriting CS, simply? Except if I missed something, there is no need for a far jump (or long jump, how is it called?) because all your code loaded in memory fits in the first segment [0,64K]... If you assume that this is the emulator fault without further investigation, it's simply blinding yourself in order to not see the bugs ![]() I tried to play a bit with your code but unfortunately, I'm using nasm and it doesn't support multiple ORG directives in a file, so I couldn't make it work without heavy modifications and it's pointless. As a last advice, If i were you I would drop this idea to load the second sector at 0x600 (at least temporarily) and test everything by loading it right next the first sector (0x7C00+512). So you remove the second org directive, the long jump and the reference to 0x600 (replacing it by a segment of 0 and an offset of 7C00+512) in the copy function and ...it should work, because it was probably done a few thousand of times by the O/S guys in this forum (thus you cannot assume this is a bochs bug in this case) ![]() |
|||
![]() |
|
rhyno_dagreat 09 Apr 2007, 01:45
It works! Hmm... I wonder why it screws up at 0x0600 though... Either way, thanks man!
|
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.