write to LCD displayer

[asmboozer]

okaaay. now i understand better ...

I suppose you have good reasons to whish to be in 320x200x256 (!) by that time, and i guess you already know that this mode has no hardware support for characters. Just pixels (hence 'graphic').

I fear your BIOS provider assumed that nobody uses BIOS to display text in graphic mode nowadays and thus they just skipped that part in their implementation to gain place for PNP, large IDE disks, USB, PCI etc. support... If this is so, you'll have to write your own character display routines ...

Or maybe you see single-coloured bars when displaying text, which would mean both foreground and background colors are identical. If so, you should try to reprogram the palette to get nice colors...

i remember that I once got a symbol char (using the int 10h ah =0 al=? service) but not the text i want displayed.
now nothing appears on the displayer.

do u mean that bios does support it? why win98 bootdisk can have boot msg displayed?

[Pype.Clicker]

win 98 boot message is in text mode ... or uses custom font rendering (if not just a bitmap with text drawn on screen).

If you could show how you initialize the screen and how you send a string to it, probably things would become clearer ...

[asmboozer]

win 98 boot message is in text mode ... or uses custom font rendering (if not just a bitmap with text drawn on screen).

If you could show how you initialize the screen and how you send a string to it, probably things would become clearer ...

the code i used is from "Daniels NASM Bootstrap Tutorial"
the link is
http://mitglied.lycos.de/programmier_pa ... smBoot.htm
it works other crt displayer. but not mine

[Pype.Clicker]

Code: Select all

   org 0x7C00      ; This is where BIOS put me

; ---------------------------------------------------------
; Main program
; ---------------------------------------------------------
;+ PYPE : enforce cs = 0 
jmp 0x0000:start

start:
   ; Setup the stack.
   ; We can't allow interrupts while we setup the stack
   cli         ; Disable interrupts
   mov ax, 0x9000      ; Put stack at 0x90000
   mov ss, ax         ; SS = 9000 and
   mov sp, 0         ; SP = 0000 => Stack = 90000
   sti         ; Enable interrupts

;+PYPE : enforce DS = 0
       xor ax,ax
       mov ds,ax

;+PYPE : enforce video mode == text 80x25
       mov ax,0x0003
       int 0x10

   ; Remember the bootdrive information provided in DL
   mov [bootdrv], dl

   ; Load a program
   call load

   ; Jump to the loaded program
   mov ax, 0x1000
   mov es, ax
   mov ds, ax
   push ax
   mov ax, 0
   push ax
   retf

should be more reliable ...

[Candy]

i remember that I once got a symbol char (using the int 10h ah =0 al=? service) but not the text i want displayed.
now nothing appears on the displayer.

Well, if you can get a char, but not the one you present to it, are you sure you are using the right pointer?

[asmboozer]

to Pype.Clicker,
Candy:
the problem is I didn't enforce DS =0, maybe in some bios , after load into 0x7c0:0000, ds defaulted to 0, while others not. boch must be the 1st case.

[asmboozer]

another question , if i don't use org 0x7c00 statement, how could i make it in the code?
can I just do in below methods:
1: mov ax,0x7c0
mov cs, ax
2: jmp 0000:0x7c00
if the above two all wox, which is better? or why not?

one question again:
the text for display defined as msg db ' hello world',13,10,0
when the code wants to use it, like the instruction mov esi, msg , what's the msg 's offset in ds?is it greater than 0x7c00?
how load program knows it?

[Schol-R-LEA]

I don't believe that this would work; if there is no org statement in code assembled as raw binary, the origin is assumed to default at zero. As a result, the labels would all be assembled for the wrong locations.

[asmboozer]

I don't believe that this would work; if there is no org statement in code assembled as raw binary, the origin is assumed to default at zero. As a result, the labels would all be assembled for the wrong locations.

but after the bios read into memeory, the code is already in 0x7c0:0000, then the bios will execute the code, rite?
if so, if there is no data in the code, is it right?

[Schol-R-LEA]

Whther there is data in the code or not is irrelevant, though certainly the text message would count as such. The issue is primarily in regards to the labels, which generate the same thing for both code and data: addresses which the assembler has calculated for the given locations. To demonstrate, here is an example of the actual object code from a simple program:

Code: Select all

address(in hex)   opcode   argument
---------------------------------  
00000000         BA   00 00
            mov dx, address of hellomsg (from start of the data section)

00000003   B4      09
      mov ah, 9 hex (same as 9 decimal, of course)

00000005   CD   21
      INT   21 hex

00000007   B8   00 4C
      mov AX,   4C00 hex - note that the bytes are reversed!

0000000A   CD   21
      INT   21 hex
 
0000000C   48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0D 0A 24     
      H  e  l  l  o  ,     W  o  r  l  d  !  CR LF $

If the origin of the code doesn't match the actual location where the code has been loaded into, then these addresses will be incorrect.

[Pype.Clicker]

oh, and please, try to write in something that look like 'correct english' ... words like 'wox, rite, memeory' are 'complex decode' instruction and therefore they break my read/parse/translate/understand/reply pipeline ...

[asmboozer]

okay, i will try better

[asmboozer]

Whther there is data in the code or not is irrelevant, though certainly the text message would count as such. The issue is primarily in regards to the labels, which generate the same thing for both code and data: addresses which the assembler has calculated for the given locations. To demonstrate, here is an example of the actual object code from a simple program:

Code: Select all

address(in hex)???opcode???argument
---------------------------------  
00000000      ???BA???00 00
      ??????mov dx, address of hellomsg (from start of the data section)

00000003???B4      09
??????mov ah, 9 hex (same as 9 decimal, of course)

00000005???CD???21
??????INT???21 hex

00000007???B8???00 4C
??????mov AX,???4C00 hex - note that the bytes are reversed!

0000000A???CD???21
??????INT???21 hex
 
0000000C???48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0D 0A 24     
??????H  e  l  l  o  ,     W  o  r  l  d  !  CR LF $

If the origin of the code doesn't match the actual location where the code has been loaded into, then these addresses will be incorrect.

in the tutorial,
http://www.osdev.org/osfaq2/index.php/BabyStep2

AsmExample:

mov ax, 0x07c0
mov ds, ax

mov si, msg
ch_loop:lodsb
or al,al ;zero=end of str
jz hang ;get out
mov ah,$0e
int $10
jmp ch_loop

hang:
jmp hang

msg db 'Welcome to Macintosh', 13, 10, 0
times 510-($-$$) db 0
dw 0xAA55

why can it ?

[Pype.Clicker]

woooo ... dude! you're diggin' out a 1-year-old post ...

why can it ?

Why can who do what ?
You mean "Why isn't there any 'ORG xxx' in baby Step #2 ?" ?

No 'ORG xxx' is needed when you make sure your code is loaded from offset 0 in the segment. That's what Crazy Buddah did : DS is loaded with 0x7c0 (so the first byte of the boot sector is at DS:0) and all the jumps are relative (e.g. no jmp far or whatsoever), so the actual value of CS don't care.

However, having non-zero datasegment makes the process of building/loading descriptor tables harder, so we usually prefer to have "mov ds,0" and "org 0x7C00" ...

[asmboozer]

woooo ... dude! you're diggin' out a 1-year-old post ...

why can it ?

Why can who do what ?
You mean "Why isn't there any 'ORG xxx' in baby Step #2 ?" ?

No 'ORG xxx' is needed when you make sure your code is loaded from offset 0 in the segment. That's what Crazy Buddah did : DS is loaded with 0x7c0 (so the first byte of the boot sector is at DS:0) and all the jumps are relative (e.g. no jmp far or whatsoever), so the actual value of CS don't care.

However, having non-zero datasegment makes the process of building/loading descriptor tables harder, so we usually prefer to have "mov ds,0" and "org 0x7C00" ...

I think it is the code is already loaded at 0x7c0:0000, so cs does not need to be initialized, ie. there is no requirement for CS as long as something (I am not certain which it is) is right.

but DS should be. otherwise the data could not find the right offset.