logs archiveIRC Archive / Undernet / #asm / 2006 / June / 10 / 1
vml
MrAshe http://www.explosm.net/db/files/Comics/Matt/the-internet-is-full-of-liars.jpg
skyhigh-
! just d - vart tog den söta lilla flickan vägen
(Action) is away, nn, (log\on pager\on)
Int3
lo
terby
(Action) is away, butikken, (log\on pager\on)
Chiu_Lee
how do you write "mov [B800h:0],48" in AT&T syntax? (need to put that in a C source (gcc) as inline assembly for debugging purpooses)
i tried "movw %bx,0x0B800" "movb 48,%bx:0" but I get error at compile with junk after register ":0"
vml
Try movb $48, %bx:0
Before that, "movw $0xb800, %bx"
Chiu_Lee
same error
edcba
you can't write mov byte ptr [0b800h:0],48 in intel syntax
it is not a correct addressing mode
Chiu_Lee
I have an asm(".code16"); at the begining, hope that doesn't influence this
         

edcba
you still can't
Chiu_Lee
edcba, I know that, I just was too lazy to write the intermediat step with bax for the intel syntax as well ;)
s/bax/bx
edcba
but mov [bx:0] is not valid either
Chiu_Lee
right
sorry. I used es for segmenr and bx for indexing
my bad
edcba
don't use at&t syntax :)
Chiu_Lee
works now :)
I usually don't. I just wanted to make sure somehow that my C program was loaded correctly and able to access memory correctly as my external asm function that does the printing isn't doing anyting
now I have to find out why
vml
c-bot isnumeric
c-bot
vml, unsure on that one ..
vml
c-bot isnum
c-bot
vml, you tell me!
vml
c-bot isalphanum
c-bot
vml, *shrug*
vml
c-bot isalpha
c-bot
vml, here you go: isalpha - #include <ctype.h> int isalpha (int c) Classification of Characters (ISO) see - http://www.msunix.co.uk/manual/glibc-2.2.3/html_chapter/libc_4.html#SEC65
vml
digit
:_GRR
EwIck
c-bot isdigit
c-bot
EwIck, here you go: isdigit - #include <ctype.h> int isdigit (int c) Classification of Characters (ISO) see - http://www.msunix.co.uk/manual/glibc-2.2.3/html_chapter/libc_4.html#SEC65
terby
(Action) is back after 1h 50m
Chiu_Lee
I have an asm function declared as "extern void func1(char param1, char param2, char param3);" which is a 16bit function, and hence considers parameters as being 16 bit values on the stack.
since I couldn't make it run (it has to output a few stuff), I called ndisasm on the binary and got:
0000021F 666A0F o32 push byte +0xf
is there any way to force gcc to compile push for 16 bit values not 32?
EwIck
use short instead of char perhaps?
         

Chiu_Lee
same thing
I even tryed casting the constant params to short. no luck
EwIck
you're doing it wrong.
Chiu_Lee
I figured that. but what would be the correct way?
EwIck
exactly what I told you.
Chiu_Lee
I changed the function definition to using short. but same thing happens
EwIck
then maybe you're not looking at the right thing
Chiu_Lee
could be... but since it's pushing 32 bits on the stack and the function is working with 16 bit values, it makes me think that I'm looking at the right place. but I assumed that o32 forces a 32 bit behaviour. is it not?
EwIck
ain't no fu*king way gcc will push a byte on the stack when the prototype says short
Chiu_Lee
maybe ndisams isn't showing me the correct output
EwIck
or you're not looking at the right code
Chiu_Lee
I am. I changed one of the parameters, and the place I was looking at showed the change.
i'll change the asm function to assume 32 bit values on the stack just to see what happens
EwIck
I have a question
why in the world are you working in 16-bit mode
Chiu_Lee
well ... I started on this project that it's a program that runs on any intel compatible machine (no OS behind it) and works with the disk drives (maintenance mainly). so the pc starts up n 16 bit mode. it's easier for me to write all the hw routines in 16 bit (due to addressing and mainly interrupts) but gcc doesn't spit out a6 bit code, so I am using unreal mode for the "kernel" written in C.
the alternative was pmode and learn how to interface with the hw directly from pmode. since I no nothing about that, and I am running out of time, I figured I'd stay with 16 bit real mode
EwIck
heh
Chiu_Lee
16 bit unreal mode actually
EwIck
I guess you're out of luck
Chiu_Lee
I know. I had enough of it already.
yep. it's 32 bit on the stack. guess I have to change all my asm functions. damn thing
edcba
why do you use gas ?
and gcc
why not use a 16bit compiler ?
and 16bit assembler
Chiu_Lee
I use gcc and nasm. i thought about a 16 bit compiler a long time ago when I started , but I coiuldn't find a good assembler for windows (I only found 16 bit c compilers for win)
guess it was more a problem of finding the right tootls
I got tired of searchign and got to work with what I had/known
EwIck
that may be because there aren't any out there anymore
load kernel, switch to pmode, voila
that's just how it's done
Chiu_Lee
yeah, and then the hell breaks loose with interrupts not being able to be used the same way as in 16 bit mode (or so I read). and my proggy is using mainly the bios interrupts.
it's a vicious circle
vml
http://www.plaxo.be/
terby
! De lillos - Familiepappa
happyhappyhappy
yoan
:)
glad i could be of assistance.
Inode
chiu_lee: switch to unreal mode from pmode?
terby
yoan :*
yoan
;)
Chiu_Lee
Inode: I (think) i've done that. I mean I have taken some code off somehwre and run it. it supposedly bets me in unreal mode. I do that in the bootloader.
s/bets/gets
btw, what's a good way to check that unreal mode is the active mode?
Inode
well to determine you're in unreal mode as opposed to real mode, you could patch int 0Dh's entry in the ivt to point a routine that'll indicate 'real mode'... as in real mode when you attempt to use 32 bit address, trap/int 0Dh should be raised
addresses*
Chiu_Lee
seems logical. though as I saw in the code I used, it doesn't do anything with the ivt, only the gdt
but then again, I didn't spend too much time on understanding what the code did
Inode
yar you could also look at the first word (bits 16:0) and second to last byte (buts 19:16) of the gdt to see the 20 bit segment size/limit
it should be set to 0xfffff instead of 0x0ffff
bits*
15:0 and 19:16 even
the rest of that last byte is for flag usage, like page-granularity i guess
Chiu_Lee
I should first get a pointer to the existing gdt, no? because if I use the one I defined, then it should already have these values, no/
Inode
yes
but you'll probably need to determine that you're not in pmode too
because the gdt would be valid for that
Chiu_Lee
but if I'm in unreal mode, I can't be in pmode, no?
Inode
well
if you've set the segment limit/size in gdt once you're in pmode and then return to the supposed 'real' mode... that's unreal mode
the ivt patch check above, should be unnecessary but it should prove that you're in unreal
Chiu_Lee
well, maybe I'll put such a check later. I don't feel like getting my hands dirty with interrupt tables right now. this is due in 2 weeks and I am still in the first 2-3% of the project :D
thanks for the help
Inode
ok
Chiu_Lee
I now have a "hello world" like app (C&asm), that gets loaded by the bootloader. it prints some test messages. if the app is compiled to be less than 512 bytes (1 sector) everything works like a charm. if however I cross the 512 byte boundary even with one byte so that 2 sectors need to be loaded from disk, vmware is acting crazy when I call function 0 of int 10h. I came to this conclusion after putting readkeys through the code.
when I say crazy, I mean that the window is shrining horizaontally to about 100 pixels or so, and the virtual machine screen gets some sort of red display with vertical stripes
btw, I load the app at 200h
any ideas why this is happening?
I would try otehr vm's but I don't have any
and I use vmware 4.0 if it counts
Inode
well
are you talking about the pbr/mbr exceeding 512bytes?
Chiu_Lee
hm ... well, the bootloader and application are concatenaed, a filling is added of null's (to round up to a whole cluster number), resulting in a file that is now 1536 bytes big (3 clusters = 1 bootloader + 2 the app) which is used by vmware as a floppy image and the vmware system boots from it. that's bascially the current setup that crashes. now, if the app would be only 1 sector long, everything would be fine.
I am guesing that because the app is 2 sect big, the bootloader overwrites something that belongs to the bios int 10 thus causing the crash
but I can't find a decent memory map
all I find is for dos
Inode
basically at boot time, the bios will facilliate reading 512 bytes from the beginning of the boot disk and drop it off at 0x7c00 if its last 2 bytes match the boot magic
facillitate*
you'll have to deal with loading the contents of the 2nd sector directly from disk i suppose
Chiu_Lee
oh, but i've done that
and it works ok if the app is 1 sect long
i'm loading it at 200h just in case you missed that from above
Inode
why 200h?
Chiu_Lee
no reason
I needed an address which is low but not too low
so that I can allocate space for data above the app, buyt below the rest of the stuff, keeping everything below conventional mem
Inode
well
000h to 3FFh is the real mode ivt
500h to 7BFFh is unused
Chiu_Lee
you have a table with that :) it would help me. I can't find any good map on the net. guess I am not searching correctly.
Inode
http://stakface.com/nuggets/index.php?id=10&replyTo=0
Chiu_Lee
I changed the load address to 500 for a quick test. works. that was the problem :)
thanks. that map is exactly what I needed.
Inode
cool
FeRoX`gone
unlimited webspace & traffic for your homepage? just visit www.saveitfree.com
edcba
unlimited webspace ? :)
bandwidth limited ? :)
EwIck
read the small font stuff
edcba
http://en.saveitfree.com/terms.php :)
i try but my english is somewhat approximative
EwIck
"unlimited while hard disk holds. unlimited traffic starting from all popup ads have been clicked"
« prev next »