Print repeats twice?

Index > OS Construction > Print repeats twice?

Author

Thread

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

rhyno_dagreat 17 Mar 2007, 00:21

Hey, I wrote an operating system where it should only print a loading string once, then after it loads the OS it should show a welcome message once and after that call a DIR function for my own filesystem. But what it does is show things in this order:

Loading Message
Welcome Message
Loading Message
Welcome Message

And it never gets to the dir command. I've compared this PrintF function to print functions of other OS tests I have done, and it's literally the same bit of code, yet the other ones don't repeat.

Here's the code in case any of you need/want to look at it:

Code:

use16
org 7C00h
jmp Start

LoadMsg db "Loading RhynoOS...", 10, 13, 0

;FileSystem Setup
MaxSectors  equ 64

bSectorsRead db 0
bSectorNum   db 0
bSectsOnDisk db 0
bFileName    db 0

Start:
        xor ax, ax
        mov ds, ax
        mov si, LoadMsg
        call PrintF

        mov ax, 0060h
        mov es, ax
        mov bx, 0000h
        mov ah, 02h ;BIOS read sectors into memory
        mov al, 01h ;read in 1 sector
        mov ch, 00h
        mov cl, 02h ;second sector
        mov dh, 00h ;head number
        ;mov dl, 00h ;not needed 'cause drive number is
                     ;automatically loaded in dl from boot

        int 13h

        jmp 0060h:0000h

DirCommand:
        pushad
        Lbl1:
                cmp [bSectorsRead], MaxSectors
                je DirDone
                mov ax, 0060h
                mov es, ax
                mov bx, 0000h
                mov ah, 02h
                mov al, 01h
                mov ch, 00h
                mov cl, [bSectorsRead]
                mov dh, 00h
                mov dl, 00h
                int 13h

                add bx, 2
                cmp [bx], byte 0xBF
                je FileFound
        Lbl2:
                add [bSectorsRead], 1
                jmp Lbl1


FileFound:
        inc bx
        PrintFileName:
                cmp [bx], byte 00h
                je Lbl2
                mov si, bx
                lodsb
                mov ah, 0Eh
                int 10h
                jmp PrintFileName


DirDone:
        popad
        ret


PrintF:
        lodsb
        cmp al, 0
        je Done
        mov ah, 0Eh
        int 10h
        jmp PrintF

Done:
        ret

times 510-($-$$) db 'X'
dw 0xAA55

org 0600h
jmp OS_Loaded

;data goes right here
WelMsg db "Welcome to RhynoOS!", 10, 13, 0

db 0xBF, "Kernel", 10, 13, 0

OS_Loaded:
        mov si, WelMsg
        call PrintF
        call DirCommand

        Halt:
                jmp Halt

times 1455616-($-$$) db 'X'

Thanks for your time!

-Ryan "Rhyno" Lloyd

EDIT: I forgot to mention, I'm using BOCHs to run it if that could be part of the problem.

17 Mar 2007, 00:21

Mac2004

Joined: 15 Dec 2003
Posts: 314

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
mov es, ax

secondary file code:

Quote:

org 0600h
jmp OS_Loaded

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

17 Mar 2007, 04:18

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

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.

17 Mar 2007, 14:19

gdev

Joined: 04 Mar 2007
Posts: 13

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 Wink

This is just my interpretation, I didn't check it. Hope that will help.

18 Mar 2007, 19:35

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

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. Confused

19 Mar 2007, 00:58

Dex4u

Joined: 08 Feb 2005
Posts: 1601
Location: web

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.

19 Mar 2007, 02:39

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

rhyno_dagreat 19 Mar 2007, 05:28

Thanks for the tip, I'll look more into it in the morning when I wake up.

19 Mar 2007, 05:28

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

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.

19 Mar 2007, 15:48

gdev

Joined: 04 Mar 2007
Posts: 13

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 Wink

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) Smile

20 Mar 2007, 15:49

rhyno_dagreat

Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau

rhyno_dagreat 09 Apr 2007, 01:45

It works! Hmm... I wonder why it screws up at 0x0600 though... Either way, thanks man!

09 Apr 2007, 01:45

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum