IRC logs for #opendune on OFTC at 2010-02-05
⏴ go to previous day
01:13:28 <SmatZ> hmm now how can I get over that "copy-protection check" after first mission
01:13:37 <SmatZ> when I can't type capital letters :-x
01:23:16 <SmatZ> oh, I don't need capital letters, I was just spelling it wrongly :-p
02:43:30 <glx> it skips case and spaces ;)
07:52:55 <TrueBrain> And now, now it is time to make an exam .. brrr
07:53:01 <TrueBrain> went out yesterday ... trouble ....
08:51:24 *** Xaroth is now known as Xaroth|Work
08:52:37 *** Xaroth|Work is now known as Xaroth
08:52:56 *** Xaroth is now known as Xaroth|Work
08:53:26 *** Xaroth|Work is now known as Xaroth
08:56:19 *** Xaroth|Work has joined #openDune
08:56:19 *** ChanServ sets mode: +o Xaroth|Work
10:42:11 <TrueBrain> concratz ... I think
10:43:53 <TrueBrain> dunno .. are you happy with it?
10:44:26 <Xaroth|Work> backup connection for when my home connection fails :P
10:46:16 <Xaroth|Work> I'm currently working out a business plan for the T2 prints we're currently not running
10:46:32 <Xaroth|Work> see if we can get any profit from that (read: something 'easy' for me to do :P)
10:47:22 <TrueBrain> I wonder if there is anything 'easy' for me to do :p I am bored ...
10:48:05 <Xaroth|Work> well you can fly a drake now
10:48:08 <Xaroth|Work> i'd say L2/L3 missions
10:48:20 <Xaroth|Work> get your standings up with caldari navy or something
10:48:33 <Xaroth|Work> get caldari navy missile launchers/ammo for yer drake
10:48:53 <TrueBrain> yeah .. why not .. being in empire and all
10:49:02 <Xaroth|Work> once we're done with the LFA crap we can worry about new interesting things
10:49:02 <TrueBrain> is everything moved already?
10:49:27 <Xaroth|Work> think most of it is yeh
10:50:25 <TrueBrain> lets see if someone can pass me a drake after DT: )
10:56:34 <TrueBrain> PM Xaroth|Work .. or we have to find us another channel for this ;)
13:21:24 <glx> The jump was triggered at decompiled/cs__2756.c:1337 <-- nice line number ;)
13:24:07 <Xaroth|Work> glx wins the line of the day :)
13:33:04 <glx> ,...emu_get_memory16(emu_ss, emu_bp, 0x2) = 0x2756;
13:33:39 <glx> why they didn't use a more direct solution?
13:33:56 <TrueBrain> this is very special indeed :)
13:34:44 <TrueBrain> you cant address ss:sp from assembly, that is why this is used
13:34:56 <TrueBrain> but on +2 is the ip? or cs?
13:35:06 <TrueBrain> so .. arent you looking at the overlay manager? :p
13:36:09 <glx> push something and immediately replace the something with a fixed value
13:36:41 <TrueBrain> it sets ss:sp+2 to 0x2756
13:36:46 <TrueBrain> which is not the normal stack
13:37:32 <TrueBrain> it puts bp safe, then it sets bp to sp, then it sets ss:bp+2
13:37:38 <TrueBrain> which is the return cs
13:38:10 <glx> no it's the value pushed before the bp push
13:38:40 <TrueBrain> most likely pop'd later
13:38:51 <TrueBrain> it is also pushed there
13:38:56 <TrueBrain> so it sets the return cs:ip
13:39:28 <glx> it's f__2756_0C0B_0021_873C
13:39:36 <glx> it just set args for a call
13:39:38 <TrueBrain> isnt it the overlay stuff?
13:40:15 <TrueBrain> ss:sp always contains the return ip, ss:sp+2 the return cs, and ss:sp+4 the former sp
13:40:35 <TrueBrain> no, the emu_push(emu_ax) is not used in this piece of code :)
13:40:38 <TrueBrain> you confuse me :p :)
13:41:41 <TrueBrain> the last pop only restured the stackframe of the last function or something
13:41:45 <TrueBrain> which is a bit weird
13:42:29 <TrueBrain> euh, wait, I am mixing sp and bp .. let try this again
13:42:36 <TrueBrain> ss:sp + 2 becomes bp
13:42:46 <TrueBrain> ss:sp + 4 becomes 0x2756
13:42:55 <TrueBrain> and then it is poped in bp
13:43:35 <glx> anyway there's a problem with this function return cs:ip is wrong
13:44:18 <TrueBrain> from where is the function called?
13:45:00 <TrueBrain> owh, bp is normally restored :)
13:45:37 <TrueBrain> I should have seen that earlier :)
13:45:51 <TrueBrain> yes, it is a push of 0x2756
13:46:24 <TrueBrain> stack afterwards is like: ax, ??, 0x2756, and the SP is set to the ?? value
13:46:57 <TrueBrain> well, or something like that :p
13:48:01 <TrueBrain> dirty tricks to access stuff you shouldn't be able to access
13:53:10 <glx> stack is CS, IP, BP, 0x2756, 0x0888, 0x2756, 0x0C2C before the f__2756_04F8_0009_907D call (so 2 args)
13:53:21 <glx> the problem is emu_sp += 6 after the call
13:56:54 <glx> it "poped" 3 param when the call was done with 2
13:58:10 <TrueBrain> it most likely has a reason ...
13:58:17 <TrueBrain> as that would fail on any machine :)
13:58:46 <TrueBrain> (and in fact would crash OpenDUNE every single time :p)
13:58:56 <TrueBrain> be aware of ghost functions btw
13:59:06 <TrueBrain> not all functions are really called, but are a bugged instance of the decompiler :)
13:59:43 <glx> maybe 2756 is full of those :)
14:00:07 <TrueBrain> well .. if it is called from outside 2756, it most likely is not
14:00:40 <TrueBrain> well .. just follow the chain of events ;)
14:01:10 <glx> Program Termination: jumped to 0EC6:0CC8, which is not decompiled.
14:01:10 <glx> The jump was triggered at decompiled/cs__2756.c:1337
14:01:10 <glx> The jump appears to originate from 2756:0CC2.
14:01:10 <glx> Please send the file 'memory/crash.bin' to upstream developers.
14:01:12 <glx> Crash-dump in 'memory/crash.bin'
14:01:34 <glx> the jump should be 2756:0CC8
14:01:43 <TrueBrain> I assume it is because you modified stuff? :)
14:02:18 <TrueBrain> well .. yeah ... the problem with the sound drive stuff is, that it is unpredicatable
14:02:28 <TrueBrain> only later I realised that: we used the JIT on 2 types of sound driver
14:02:35 <TrueBrain> this can never be a good thing ;)
14:02:45 <TrueBrain> they are loaded at the same place .. producing double data :p
14:03:06 <TrueBrain> so I tihnk any sound stuff has to be reversed from 1DD7 I believe?
14:03:16 <TrueBrain> or we have to redo that somehow for only 1 driver
14:03:22 <TrueBrain> but that means someone has ot add it in LibEMU :p
14:03:42 <glx> sound drivers are handled by opendune itself
14:03:56 <glx> it loads the file, then execute it
14:04:58 <TrueBrain> yes, and the JIT decompiles that :)
14:05:01 <TrueBrain> which went a bit wrong :p
14:05:58 <glx> IIRC I gave you a dune.cfg with more than one driver set
14:06:14 <TrueBrain> yes ... as I said: now we have 2 drivers decompiled
14:06:18 <TrueBrain> in a mix of eachother :p
14:06:34 <glx> sound and music are the same btw :)
14:06:54 <glx> but there are 2 types, .DRV and .ADV
14:08:21 <TrueBrain> if you really want the sound and stuff .. we need to find a better approach
14:08:48 <glx> I'm trying to understand how the sound files are read
14:09:08 <glx> so I can implement a clean player
14:09:16 <TrueBrain> 1DD7 is the wrapper, not?
14:09:29 <TrueBrain> so that should give you the entry point
14:09:37 <TrueBrain> but .. you have no idea about the format of course :)
14:09:59 <glx> all except .ADL have similar format
14:12:09 <glx> but I need to be able to follow calls to find where it's "decoded"
14:12:28 <TrueBrain> I will see what happened to 2756 a bit later :)
14:12:41 <TrueBrain> if you give me your dune.cfg, I can see if the JIT runs the code correct?
14:12:52 <glx> I should try to build JIT in a linux VM
14:14:14 <TrueBrain> nothing says it does work, but there is a chance :p
14:17:07 <TrueBrain> k, got it, will check in a few minutes
14:17:14 <TrueBrain> hmm .. it is just 1515 .. thought it would be like 1700 ...
14:31:44 <glx> grr vmware remote console doesn't work in FF 3.6
14:32:09 <glx> luckily it should work in IE
14:32:11 <Xaroth|Work> I was HOPING it was 1700, TrueBrain :P
14:40:00 <glx> is there somewhere instructions to get and compile JIT ?
14:40:20 <TrueBrain> but 'make' should be sufficient
14:44:57 <glx> of course I need 32bit libstdc++
14:45:15 <TrueBrain> everything in 32bit, yes :)
14:49:36 <glx> but -m32 should tell the compiler to look at the right place for libs, no?
14:50:38 <glx> then why does it look in x86_64
14:51:06 <glx> unless -m32 is not passed to ld
14:52:23 <TrueBrain> there is no such thing as a dir called x86_64 :p
14:52:35 <TrueBrain> but it should try both /usr/lib64 as /usr/lib32
14:52:45 <TrueBrain> for debian it is multilib you need
14:53:11 <glx> it's gcc internal search path
14:54:27 <glx> ha I had gcc-multilib but not g++-multilib :)
15:09:01 <glx> fun thing is a linux VM is as fast as native linux install, while OSX VM is slow as hell :)
15:11:16 <TrueBrain> you got it working?
15:11:44 <glx> it should be in packages but I don't find it :)
15:11:52 <TrueBrain> you need a newer version anyway
15:11:55 <TrueBrain> so download the source ;)
16:02:04 <glx> how to build a 32bit tcc ?
16:03:17 <TrueBrain> I believe I edited the Makefile to include -m32
16:06:22 <glx> --extra-cflags=-m32 is enough it seems :)
16:08:38 <glx> stupid me I forgot the -dev one
16:11:07 <glx> ho ncursesw is not ncurses
16:32:03 <glx> and I can run opendune in the VM (which is not possible in OSX VM ;) )
16:32:43 <TrueBrain> be always careful with JIT, it produces false files when resuming a memory file
16:32:47 <TrueBrain> (the return-path to be exact)
16:33:42 <glx> well I compile toc, libemu and opendune, but I guess there's a hidden step ;)
16:34:05 <TrueBrain> and .. you may need to comment out pic_resume() in src/pic.c when resuming a memory :)
16:34:09 <TrueBrain> nope, no hidden step
16:34:18 <TrueBrain> starting OpenDUNE is then done by preloading the jit, that is all
16:34:30 <TrueBrain> LD_PRELOAD="libjit.so" LD_LIBRARY_PATH=".." ./opendune
16:34:35 <TrueBrain> or where ever libemu.so is ;)
16:35:15 <glx> ln ../libemu/libemu.so ;)
16:35:26 <TrueBrain> so adjust LD_LIBRARY_PATH to the demands :)
16:40:08 <glx> hmm libjit.so cannot be preloaded
16:41:58 <glx> ERROR: ld.so: object 'libjit.so' from LD_PRELOAD cannot be preloaded: ignored.
16:42:12 <TrueBrain> ln -s ../toc/libjit.so
16:42:22 <TrueBrain> or point to the path it is in
16:42:30 <TrueBrain> I have symlinked all 3 .sos in the opendune dir
16:42:41 <TrueBrain> so for me it is LD_PRELOAD="libjit.so" LD_LIBRARY_PATH="." ./opendune
16:44:40 <glx> hmm maybe it's because libemu and opendune are not -m32
16:44:43 <TrueBrain> what does: file libjit.so say?
16:44:49 <TrueBrain> yes, that will be the reason ;)
16:44:52 <TrueBrain> all have to be 32bit :)
16:48:44 <glx> grr I hate doing 32bit on 64bit
16:56:51 <SmatZ> glx: pass -m32 to linker
16:57:31 <SmatZ> cc -m32 -o libemu.so objs/src/bios_asm.o objs/src/bios.o objs/src/call.o objs/src/int10.o objs/src/int13.o objs/src/int15.o objs/src/int16.o objs/src/int1a.o objs/src/int21.o objs/src/int2a.o objs/src/int2f.o objs/src/int33.o objs/src/libemu.o objs/src/math.o objs/src/mov.o objs/src/pic.o objs/src/register.o objs/src/timer.o -Wl,-m32
17:03:46 <glx> ok it's just LDFLAGS:="-m32" removed the -shared
17:06:04 <glx> same bug for CFLAGS it seems
17:08:00 <glx> ok "CFLAGS=-m32 LDFLAGS=-m32 make" works
17:09:59 <SmatZ> I think it's how Makefiles are designed
17:10:12 <SmatZ> make CFLAGS=xxx overrides any assignment to CFLAGS inside Makefile
17:11:17 <glx> I used "make CFLAGS:=xxx" and that doesn't work as I expected :)
17:11:34 <SmatZ> yeah, I was surprised by that behaviour not long time ago :)
17:13:27 <glx> arg I don't have 32bit SDL
17:27:02 <TrueBrain> nobody said it was easy :p
17:27:26 <glx> but I have it theorically
17:31:05 <glx> oh it's not libSDL but libSDL-1.2
17:33:22 <glx> now it doesn't find libtoc.so, but that's a clear error (and easy to fix)
17:55:29 <glx> hmm libjit is totally unsafe :)
17:56:00 <TrueBrain> not really .. when done correctly :)
17:56:04 <glx> it does fopen then fwrite without checking for validity
17:56:35 <TrueBrain> got to go, sorry ..
20:21:17 <TrueBrain> and, got it to work? :)
20:32:17 <TrueBrain> JIT is fairly stable, as long as it can write its files :)
20:34:38 <glx> new function recorded, jump from ... recorded, segfault
20:35:12 <TrueBrain> then it has issues writing the files I guess :)
20:35:18 <TrueBrain> make sure you don't load a memory dump
20:35:27 <TrueBrain> (which it doesnt by default :p)
20:36:01 <glx> without memory dump I get a tcc error
20:36:19 <TrueBrain> I mean: don't execute: ./opendune memory/<bla>.bin
20:36:22 <TrueBrain> that will fail in most cases
20:36:29 <TrueBrain> (return stack is corrupted at that point)
20:36:38 <TrueBrain> only execute ./opendune
20:36:43 <TrueBrain> (with the LD_ stuff in front :p)
20:36:43 <glx> <string>:9: function pointer expected
20:36:52 <TrueBrain> make sure include/ has the right files
20:37:02 <TrueBrain> which are correct, the ones in SVN
20:37:39 <TrueBrain> 'hg tip' in toc, gives you which revision?
20:39:08 <TrueBrain> but okay, that is all I guarantee ;) It works here :p
20:39:23 <TrueBrain> it seems my decompiler is accepted as bachelor project .. then maybe I pay more attention to workability :p
20:43:56 <TrueBrain> glx: ps, make sure to use the OpenDUNE libEMU :)
20:46:06 <TrueBrain> that is why I say that :)
20:47:04 <glx> so I need to recompile libjit ?
20:48:13 <glx> then the right libemu is used I think (I symlinked in opendune root)
20:48:59 <TrueBrain> the one in ToC is heavily outdated :p
20:49:20 <glx> I don't use the one in toc anyway
20:49:35 <TrueBrain> I have a few good ideas for a redesign of ToC
20:49:38 <TrueBrain> which should all makes it more stable
20:49:40 <TrueBrain> but .. bitch of a work :p
20:52:51 <glx_> copy/paste between VM and host is not nice
20:53:47 <glx_> loic@ubuntu:~/opendune$ LD_PRELOAD="libjit.so" LD_LIBRARY_PATH="." ./opendune [JIT] Unknown function, starting with JIT. [JIT] New function 01F7:0000; recorded [JIT] Jumped from 0000:0000 to 01F7:0000; recorded [JIT/TCC] ERROR: <string>:9: function pointer expected
20:55:36 <glx> and that is with an empty txt dir
20:56:14 <glx> but the error is the same with latest extra/jit/txt
20:58:14 <TrueBrain> in toc/libjit/call.c, there is an #if 0, in which between is a fprintf
20:58:28 <TrueBrain> now it will give you the function it wants to compile
20:58:34 <TrueBrain> maybe that gives a bit of insight
20:58:50 <TrueBrain> also, made sure tcc can compile on your system / for your system?
21:03:35 <glx_> loic@ubuntu:~/opendune$ tcc -run test.c
21:03:41 <glx_> test.c:9: function pointer expected
21:03:52 <glx> even in command line it fails :)
21:04:33 <glx> test.c contains what libjit tries to compile
21:06:24 <TrueBrain> code in JIT is different :)
21:08:48 <glx> but emu_movwm doesn't exit
21:09:29 <TrueBrain> you are right: it does not exist AT ALL
21:09:37 <TrueBrain> so ... how on earth can it be generated for you? :p
21:10:41 <TrueBrain> I only have traces of that in an old version
21:11:02 <TrueBrain> and in the new libemu code
21:12:07 <TrueBrain> mercurial is not nice
21:12:48 <TrueBrain> glx: update to r346
21:12:57 <TrueBrain> somehow it doesn't tell me I am not using tip :s
21:13:40 <TrueBrain> r347 is the glue to use the new libemu
21:17:03 <TrueBrain> mercurial refuses to tell me which version I have loaded .. so I hope it is r346 .. cant be sure :p
21:17:11 <TrueBrain> what code does it generate now?
21:18:15 <TrueBrain> sorry about that .. toc is becoming a bit messy :)
21:18:41 <TrueBrain> k, that should work
21:18:43 <TrueBrain> does tcc compile that?
21:19:16 <TrueBrain> then it should just work :(
21:19:18 <glx> and JIT segfault when executing the result
21:20:10 <TrueBrain> I am very tempted to start this weekend cleaning up everything ...
21:20:19 <TrueBrain> but I can only do one thing .. dunno if it is the best thing to spend my time on :)
21:24:20 <glx_> [JIT/TCC] ERROR: tcc: file '/usr/lib32/tcc/libtcc1.a' not found
21:24:30 <TrueBrain> yeah, you might want to fix that ;)
21:24:59 <TrueBrain> I already planned to remove TCC from ToC in any next rewrite :p
21:25:34 <TrueBrain> it simply isn't required
21:35:08 <glx> but you can also disable the check :)
21:35:15 * SmatZ was expecting that reply :)
21:35:51 <glx> it's very easy to do now :)
21:35:52 <SmatZ> will openDune always need the manual?
21:36:38 <glx> replace opendune.c:189 with emu_ax = 1
21:37:41 <SmatZ> oh, there's another check after 7th mission :)
21:37:42 <glx> or comment the if (emu_ax == 0) block
21:38:34 <glx> as I said it's easy now :)
21:39:06 <glx> the old way was to modify emu_Security_Main directly
21:43:19 <glx> hmm strange, it found many new stuff, but most of it is not written to disk
21:44:30 <TrueBrain> SmatZ: www.google.com -> dune2 manual :p
21:44:49 <glx> ho "svn st" was not verbose enough
21:45:10 <TrueBrain> txt is in another dir ;)
21:46:06 <glx> no I mean it just said ? AB00 without showing all the files in AB00
21:46:32 <TrueBrain> SmatZ: but glx' method is easier :)
21:46:53 <TrueBrain> although that will be the last time I will say that officially :)
21:50:42 <glx> I guess fuzzy returns are not good
21:50:49 <TrueBrain> there should be one
21:51:10 <SmatZ> well, I wasn't searching for the way how to get over the protection because I was lost
21:51:15 <TrueBrain> fuzzy returns are not auto-corrected
21:51:20 <SmatZ> I was rather curious how "the devs" do that ;)
21:51:29 <TrueBrain> and by now have savegames for all levels :p
21:51:42 <glx_> Fuzzy return at depth 2. Expected 01F7:022D, but got 01F7:0138 from 01F7:0230
21:51:53 <TrueBrain> patches.c fixes that :)
21:52:13 <glx> SmatZ: it's my linux VM clone :)
22:01:25 <TrueBrain> but yes, it was expected to be weird
22:02:35 <glx> an kate order files in open dialog like windows does it in explorer
22:04:27 <glx> which is a stupid sorting choice
22:05:46 <glx> ,.../* Return from this function */
22:05:53 <glx> of course it does something weird ;)
22:05:58 <TrueBrain> yup .. faking return addresses :)
22:06:03 <TrueBrain> pretty common in the 16bit world :(
22:06:09 <TrueBrain> I was already happy Dune2 didn't do it that often :)
22:06:37 <glx> what to do with all the txt ?
22:07:17 <TrueBrain> well, if it is all correct, you can commit it, but .. is it all correct? Can you show me 'svn status' output?
22:08:02 <TrueBrain> and if you commit the decompiled stuff, make sure to revert src/main.c, and add stdio.h in decompiled/decompiled
22:08:05 <TrueBrain> (svn diff will show you)
22:09:04 <glx> I have nothing decompiled
22:09:17 <TrueBrain> then show me the status of txt :)
22:10:31 <TrueBrain> the B4 changes suprise me
22:10:34 <TrueBrain> why would they change?
22:12:14 <TrueBrain> well, run the decompiler, I say :)
22:12:46 <TrueBrain> are in the M files, any non AB or 1D references?
22:16:22 <TrueBrain> oh well, just commit it
22:16:24 <TrueBrain> when it is wrong ... :p
22:16:27 <TrueBrain> you do need to fix whitespaces
22:22:25 <glx> how to run the decompiler?
22:22:46 <TrueBrain> ./toc --static trunk
22:23:03 <TrueBrain> 'trunk contains 'src', 'txt', etc
22:23:22 <TrueBrain> ./toc has to be in that root
22:23:59 <glx> so I need to copy toc from toc to opendune?
22:28:40 <TrueBrain> make sure there are only valid .txt files in trunk/txt/
22:28:44 <glx> I removed all uneeded files
22:31:54 <TrueBrain> keep src/main.c and decompiled/decompiled.h in mind :)
22:32:13 <TrueBrain> and show me a diff before commit please, just to make sure nothing went wrong :)
22:32:18 <TrueBrain> (ToC is not so robust :p)
22:42:17 <glx> ToC likes to shuffle lines :)
22:42:44 <TrueBrain> yeah .. the sorting is in my patch
22:42:52 <TrueBrain> but not in the mercurial
22:43:35 <glx> ok I need to fix decompiled.h and svn add some stuff :)
22:45:54 <TrueBrain> should fix stdio :p
23:06:03 <glx> decompiled/cs__2B6C.c change seems strange
23:06:17 <glx> and of course ignore Makefile change
23:19:55 <TrueBrain> all looks good to me; make sure you remove all unneeded stuff before commit
23:20:13 <glx> decompiler forgot a function
23:20:16 <TrueBrain> and apply my patch and run decompiler again :p
23:20:31 <TrueBrain> it does too many, but never too little ...
23:20:45 <TrueBrain> else apply the JIT, and I will fix the decompiler tomorrow
23:21:07 <TrueBrain> oh, I was going to bed :) Nightynight :)
23:31:19 <glx> oh there was a missing From (dunno why)
23:33:31 <glx> hmm and now the missing function is present in double
23:39:08 <glx> weird it runs under JIT but crashes without it
23:46:19 <glx> looks like a patch is needed
continue to next day ⏵