Page 2 of 3
Re:write to LCD displayer
Posted: Wed Feb 11, 2004 4:36 am
by asmboozer
Pype.Clicker wrote:
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?
Re:write to LCD displayer
Posted: Wed Feb 11, 2004 7:24 am
by 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 ...
Re:write to LCD displayer
Posted: Wed Feb 11, 2004 8:31 pm
by asmboozer
Pype.Clicker wrote:
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
Re:write to LCD displayer
Posted: Thu Feb 12, 2004 4:55 am
by 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 ...
Re:write to LCD displayer
Posted: Thu Feb 12, 2004 7:56 am
by Candy
asmboozer wrote:
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?
Re:write to LCD displayer
Posted: Sun Feb 15, 2004 6:47 pm
by 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.
Re:write to LCD displayer
Posted: Sun Feb 15, 2004 8:37 pm
by 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?
Re:write to LCD displayer
Posted: Sun Feb 15, 2004 11:45 pm
by 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.
Re:write to LCD displayer
Posted: Sun Feb 15, 2004 11:58 pm
by asmboozer
Schol-R-LEA wrote:
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?
Re:write to LCD displayer
Posted: Mon Feb 16, 2004 2:50 am
by 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.
Re:write to LCD displayer
Posted: Mon Feb 16, 2004 3:09 am
by 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 ...
Re:write to LCD displayer
Posted: Mon Feb 16, 2004 3:38 am
by asmboozer
okay, i will try better
Re:write to LCD displayer
Posted: Sun May 15, 2005 9:27 am
by asmboozer
Schol-R-LEA wrote:
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 ?
Re:write to LCD displayer
Posted: Tue May 17, 2005 1:06 am
by Pype.Clicker
woooo ... dude! you're diggin' out a 1-year-old post ...
asmboozer wrote:
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" ...
Re:write to LCD displayer
Posted: Tue May 17, 2005 12:37 pm
by asmboozer
Pype.Clicker wrote:
woooo ... dude! you're diggin' out a 1-year-old post ...
asmboozer wrote:
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.