OSDev.org

Brendan wrote:Hi,

Code: Select all

BITS 32

Code: Select all

mov ax, 13h
int 10h

When you tell the assembler to generate 32-bit code it generates 32-bit code. If the CPU is actually executing 16-bit code then it decodes/interprets the instruction very differently and you end up executing trash.

Executing trash leads to unexpected results.


Cheers,

Brendan

NunoLava1998 wrote:So i thought 32bit code was backwards compatible with 16bit and it generated trash that my forced my hardware to literally combine text, VGA and VESA in one.

Brendan wrote:Hi,

Code: Select all

BITS 32

Code: Select all

mov ax, 13h
int 10h

For reference, this is what the CPU sees when it executes your code:

Code: Select all

00000000  668CC8            mov eax,cs
00000003  8ED8              mov ds,ax
00000005  66B81300CD10      mov eax,0x10cd0013
0000000B  66B800A08EC0      mov eax,0xc08ea000
00000011  EB00              jmp short 0x13
00000013  66B81E0066BB      mov eax,0xbb66001e
00000019  1400              adc al,0x0
0000001B  66B9400166F7      mov ecx,0xf7660140
00000021  E166              loope 0x89
00000023  01D8              add ax,bx
00000025  6689C7            mov edi,eax
00000028  B20C              mov dl,0xc
0000002A  2667881566B80100  mov [dword es:0x1b866],dl
00000032  66BB010066B9      mov ebx,0xb9660001
00000038  40                inc ax
00000039  0166F7            add [bp-0x9],sp
0000003C  E166              loope 0xa4
0000003E  01D8              add ax,bx
00000040  6689C7            mov edi,eax                                                                                                           
00000043  B208              mov dl,0x8
00000045  26                es
00000046  67                a32
00000047  8815              mov [di],dl
00000049  F4                hlt
0000004A  EBC7              jmp short 0x13

Brendan wrote:Hi,

Code: Select all

BITS 32

Code: Select all

mov ax, 13h
int 10h

When you tell the assembler to generate 32-bit code it generates 32-bit code. If the CPU is actually executing 16-bit code then it decodes/interprets the instruction very differently and you end up executing trash.

Executing trash leads to unexpected results.

Schol-R-LEA wrote:

Brendan wrote:Hi,

Code: Select all

BITS 32

Code: Select all

mov ax, 13h
int 10h

When you tell the assembler to generate 32-bit code it generates 32-bit code. If the CPU is actually executing 16-bit code then it decodes/interprets the instruction very differently and you end up executing trash.

Executing trash leads to unexpected results.

In case it isn't clear, the problem Brendan is pointing out is that you are invoking an interrupt vector which isn't going to be present in protected mode - or if it is, it is one which you set up, not the standard BIOS interrupt vector which would have been in the IVT if this were real mode - in p-mode, the IVT isn't there at all, and it would be using the IDT you created instead.

Or, conversely, you are running code assembled for 32-bit p-mode while running in real-mode. I doubt I need to elaborate on why this isn't going to work. If you are using 16-bit instructions, then most of the generated code will be the same, but not all of it, which means some of it will work and some won't.

So, unless you are in p-mode and have set up an interrupt vector in your IDT that mimics the BIOS interrupts (or redirects to a virtualized BIOS call), then... well, frankly I am surprised it didn't triple-fault outright. This is far less dramatic than it probably could have been.

Can you explain a bit more about what you were trying to do?

Schol-R-LEA wrote:

Brendan wrote:Hi,

Code: Select all

BITS 32

Code: Select all

mov ax, 13h
int 10h

EDIT: I just notice the ORG 0000 part. Just how are you running this? In real mode, this would put the code at the start of the current segment; the same holds in p-mode, of course, but it isn't typical to use multiple segments in p-mode (the usual practice is to give each process a flat virtual memory space and using paging hardware to control RWX access).

bits 16
ORG 0x7c00      ; Bootloader starts at physical address 0x07c00

    ; At start bootloader sets DL to boot drive

    ; Since we specified an ORG(offset) of 0x7c00 we should make sure that
    ; Data Segment (DS) is set accordingly. The DS:Offset that would work
    ; in this case is DS=0 . That would map to segment:offset 0x0000:0x7c00
    ; which is physical memory address (0x0000<<4)+0x7c00 . We can't rely on
    ; DS being set to what we expect upon jumping to our code so we set it
    ; explicitly
    xor ax, ax
    mov ds, ax        ; DS=0

    cli               ; Turn off interrupts for SS:SP update
                      ; to avoid a problem with buggy 8088 CPUs
    mov ss, ax        ; SS = 0x0000
    mov sp, 0x7c00    ; SP = 0x7c00
                      ; We'll set the stack starting just below
                      ; where the bootloader is at 0x0:0x7c00. The
                      ; stack can be placed anywhere in usable and
                      ; unused RAM.
    sti               ; Turn interrupts back on

reset:                ; Resets floppy drive

    xor ax,ax         ; AH = 0 = Reset floppy disk
    int 0x13
    jc reset          ; If carry flag was set, try again

    mov ax,0x07e0     ; When we read the sector, we are going to read to
                      ;    address 0x07e0:0x0000 (phys address 0x07e00)
                      ;    right after the bootloader in memory
    mov es,ax         ; Set ES with 0x07e0
    xor bx,bx         ; Offset to read sector to
floppy:
    mov ah,0x2        ; 2 = Read floppy
    mov al,0x1        ; Reading one sector
    mov ch,0x0        ; Track(Cylinder) 1
    mov cl,0x2        ; Sector 2
    mov dh,0x0        ; Head 1
    int 0x13
    jc floppy         ; If carry flag was set, try again

    jmp 0x07e0:0x0000 ; Jump to 0x7e0:0x0000 setting CS to 0x07e0
                      ;    IP to 0 which is code in second stage
                      ;    (0x07e0<<4)+0x0000 = 0x07e00 physical address

times 510 - ($ - $$) db 0   ; Fill the rest of sector with 0
dw 0xAA55                   ; This is the boot signature

NunoLava1998 wrote: "move random registers around and change eax to 0xb9660001"
the code i provided is very similar to what NASM produced (sarcasm)

mov ax, 1234h

Schol-R-LEA wrote:Pop quiz: in the original code (show below), what does the line mul cx do, and why are you doing it?

Code: Select all

vga:
    ; Draw pixel in middle of screen
    mov ax, [ycoord]
    mov bx, [xcoord]
    mov cx, 320
    mul cx
    add ax, bx
    mov di, ax
    mov dl, [color]
    mov [es:di],dl

Given that you repeat this code (sans the indirections; by making your loads immediates, without giving them equates to name the constants, you have made the whole less readable) in a way that makes the multiply pointless (as you are multiplying by one in the second repetition), I am not convinced you know. I am not even convinced you know what the original code was meant to do, for that matter (hint - one of the comments says it explicitly).

Similarly, can you tell me why you are using mode 0x13, rather than some other mode? There is a reason in the original, I am wondering if you can tell me what that reason is.

Can you tell me what you expected it to display? I would love to hear it.

EDIT: I want you to understand that I am not doing this to pick on you, but to make a point about how you are coming across to us, and how many problems you will have if you keep trying to Frankenstein together other people's code into a system without really understanding what the code does. The Sewage Overflow copypasta approach does not work in OS dev. There is no substitute for understanding here, and, to paraphrase Euclid, no royal road to OS dev.

Schol-R-LEA wrote:BTW, was this the source of your code, Dr. Frankenstein? Unless that was your post - and your command of English suggests otherwise - you really need to take code like this as a guide to writing your own code, not copypasta it without understanding what it is doing.

Also, what is this part for?

Code: Select all

jmp KMAIN
KMAIN:

While there once was a reason why you might do a JMP FAR at the start of the first-stage boot sector (to regularize the origin, something that used to be a problem with non-compliant BIOS loaders but has long since ceased to be an issue), there is no justification I can think of for doing this, certainly not after the first few instructions of the first stage. Can you give any reason for this beyond "it is what the code I copied it from did"?