| |
| |
| |
|
Comments:
<0> MrAshe http://www.explosm.net/db/files/Comics/Matt/the-internet-is-full-of-liars.jpg
<1> ! just d - vart tog den sta lilla flickan vgen
<2> lo
<3> how do you write "mov [B800h:0],48" in AT&T syntax? (need to put that in a C source (gcc) as inline ***embly for debugging purpooses)
<3> i tried "movw %bx,0x0B800" "movb 48,%bx:0" but I get error at compile with junk after register ":0"
<0> Try movb $48, %bx:0
<0> Before that, "movw $0xb800, %bx"
<3> same error
<4> you can't write mov byte ptr [0b800h:0],48 in intel syntax
<4> it is not a correct addressing mode
<3> I have an asm(".code16"); at the begining, hope that doesn't influence this
<4> you still can't
<3> edcba, I know that, I just was too lazy to write the intermediat step with bax for the intel syntax as well ;)
<3> s/bax/bx
<4> but mov [bx:0] is not valid either
<3> right
<3> sorry. I used es for segmenr and bx for indexing
<3> my bad
<4> don't use at&t syntax :)
<3> works now :)
<3> 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
<3> now I have to find out why
<0> c-bot isnumeric
<5> vml, unsure on that one ..
<0> c-bot isnum
<5> vml, you tell me!
<0> c-bot isalphanum
<5> vml, *shrug*
<0> c-bot isalpha
<5> vml, here you go: isalpha - #include <ctype.h> int isalpha (int c) Cl***ification of Characters (ISO) see - http://www.msunix.co.uk/manual/glibc-2.2.3/html_chapter/libc_4.html#SEC65
<0> digit
<0> :_GRR
<6> c-bot isdigit
<5> EwIck, here you go: isdigit - #include <ctype.h> int isdigit (int c) Cl***ification of Characters (ISO) see - http://www.msunix.co.uk/manual/glibc-2.2.3/html_chapter/libc_4.html#SEC65
<3> 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.
<3> since I couldn't make it run (it has to output a few stuff), I called ndisasm on the binary and got:
<3> 0000021F 666A0F o32 push byte +0xf
<3> is there any way to force gcc to compile push for 16 bit values not 32?
<6> use short instead of char perhaps?
<3> same thing
<3> I even tryed casting the constant params to short. no luck
<6> you're doing it wrong.
<3> I figured that. but what would be the correct way?
<6> exactly what I told you.
<3> I changed the function definition to using short. but same thing happens
<6> then maybe you're not looking at the right thing
<3> 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 ***umed that o32 forces a 32 bit behaviour. is it not?
<6> ain't no ****ing way gcc will push a byte on the stack when the prototype says short
<3> maybe ndisams isn't showing me the correct output
<6> or you're not looking at the right code
<3> I am. I changed one of the parameters, and the place I was looking at showed the change.
<3> i'll change the asm function to ***ume 32 bit values on the stack just to see what happens
<6> I have a question
<6> why in the world are you working in 16-bit mode
<3> 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.
<3> 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
<6> heh
<3> 16 bit unreal mode actually
<6> I guess you're out of luck
<3> I know. I had enough of it already.
<3> yep. it's 32 bit on the stack. guess I have to change all my asm functions. damn thing
<4> why do you use gas ?
<4> and gcc
<4> why not use a 16bit compiler ?
<4> and 16bit ***embler
<3> 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 ***embler for windows (I only found 16 bit c compilers for win)
<3> guess it was more a problem of finding the right tootls
<3> I got tired of searchign and got to work with what I had/known
<6> that may be because there aren't any out there anymore
<6> load kernel, switch to pmode, voila
<6> that's just how it's done
<3> 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.
<3> it's a vicious circle
<0> http://www.plaxo.be/
<7> ! De lillos - Familiepappa
<7> happyhappyhappy
<8> :)
<8> glad i could be of ***istance.
<9> chiu_lee: switch to unreal mode from pmode?
<7> yoan :*
<8> ;)
<3> 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.
<3> s/bets/gets
<3> btw, what's a good way to check that unreal mode is the active mode?
<9> 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
<9> addresses*
<3> seems logical. though as I saw in the code I used, it doesn't do anything with the ivt, only the gdt
<3> but then again, I didn't spend too much time on understanding what the code did
<9> 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
<9> it should be set to 0xfffff instead of 0x0ffff
<9> bits*
<9> 15:0 and 19:16 even
<9> the rest of that last byte is for flag usage, like page-granularity i guess
<3> 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/
<9> yes
<9> but you'll probably need to determine that you're not in pmode too
<9> because the gdt would be valid for that
<3> but if I'm in unreal mode, I can't be in pmode, no?
<9> well
<9> 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
<9> the ivt patch check above, should be unnecessary but it should prove that you're in unreal
<3> 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
<3> thanks for the help
<9> ok
<3> 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.
<3> 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
<3> btw, I load the app at 200h
<3> any ideas why this is happening?
<3> I would try otehr vm's but I don't have any
<3> and I use vmware 4.0 if it counts
<9> well
<9> are you talking about the pbr/mbr exceeding 512bytes?
<3> 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.
<3> 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
<3> but I can't find a decent memory map
<3> all I find is for dos
<9> 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
<9> facillitate*
<9> you'll have to deal with loading the contents of the 2nd sector directly from disk i suppose
<3> oh, but i've done that
<3> and it works ok if the app is 1 sect long
<3> i'm loading it at 200h just in case you missed that from above
<9> why 200h?
<3> no reason
<3> I needed an address which is low but not too low
<3> so that I can allocate space for data above the app, buyt below the rest of the stuff, keeping everything below conventional mem
<9> well
<9> 000h to 3FFh is the real mode ivt
<9> 500h to 7BFFh is unused
<3> 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.
<9> http://stakface.com/nuggets/index.php?id=10&replyTo=0
<3> I changed the load address to 500 for a quick test. works. that was the problem :)
<3> thanks. that map is exactly what I needed.
<9> cool
<10> unlimited webspace & traffic for your homepage? just visit www.saveitfree.com
<4> unlimited webspace ? :)
<4> bandwidth limited ? :)
<6> read the small font stuff
<4> http://en.saveitfree.com/terms.php :)
<4> i try but my english is somewhat approximative
<6> "unlimited while hard disk holds. unlimited traffic starting from all popup ads have been clicked"
Return to
#asm
or
Go to some related
logs:
muiedinamo
#php
lataifas.ro
#chatzone
imperatorce
#linuxhelp
#java
12WHAT IS THE SMALLEST MAMMAL?
#c++
#apache
|
|
