IRC logs for #opendune on OFTC at 2009-10-11
⏴ go to previous day
01:32:13 <glx> but failed on the questions
06:18:19 *** Alberth has joined #openDune
09:16:33 <TrueBrain> Xaroth: glad you are finally catching up what I have been saying all week ;)
09:24:36 <TrueBrain> G I Joe is a nice movie :) :)
09:28:21 <TrueBrain> wow, I now have a nice form of that corruption ... it was moving my whole screen from top to bottom :p
09:31:52 <TrueBrain> I thought it was the overlay manager, but that is a bit difficult, as it is really moving of data .. which he doesn't do ...
09:59:44 <TrueBrain> I can't find where Mentat fucks up .. and it is annoying me :p
10:42:49 <DorpsGek> SVN: truebrain (r230) [JIT] -Add: mapped another 0 functions (campaign 5)
11:24:11 <DorpsGek> SVN: truebrain (r231) -Update (r230): update decompiled code
12:14:07 <DorpsGek> SVN: truebrain (r232) -Update: the decompiler failed to detect branch merges in some corner cases
12:16:18 <Alberth> Program Termination: jumped to 4343:046B, which is not decompiled.
12:16:18 <Alberth> The jump was triggered at decompiled/cs__B4F2.c:1452
12:16:18 <Alberth> The jump appears to originate from B4F2:03EC.
12:16:18 <Alberth> trying to save a game again :)
12:17:05 <TrueBrain> downloaded :) And concratz on still making such crashlogs :p Ghehe :)
12:18:37 <Alberth> btw the locking up of the keys/mouse makes playing levels > 2 practically non-feasible.
12:18:47 <Alberth> I have switched to ordos level 1 ;)
12:19:02 <TrueBrain> keys mouse lockups?
12:19:05 <Alberth> assuming you didn't try that one
12:19:31 <Alberth> yeah, the game stops responding to my commands within a minute
12:20:02 <TrueBrain> never had that problem .....
12:20:11 <TrueBrain> you have a savegame or something?
12:20:33 <Alberth> (10:20:42 PM) TrueBrain: move over Options, if the button pressed, but doesn't operate, you are fucked :p <-- this problem, I mean
12:20:45 <TrueBrain> ah, but that ONLY happens when you go to Mentat
12:21:00 <Alberth> nope, also when moving units around
12:21:08 <TrueBrain> never ever happened here :s
12:21:14 <Alberth> but I play with mouse + keys at the same time.
12:22:02 <Alberth> I don't know, I have never seen you play ;)
12:23:49 <TrueBrain> it really works here ingame just fine .... bah
12:23:53 <TrueBrain> stupid input/output :p
12:24:29 <Alberth> it seems to me it is the increased number of vehicles in the game, the increased number of moving vehicles at the same time, or my frantic entering of commands :)
12:25:02 <Alberth> I don't know what else changes between level 1 and 2, and level 3 of harkonen
12:26:14 <TrueBrain> I guess I am just really lucky :p
12:26:26 <TrueBrain> I will make converting the mouse/keyboard stuff a higher prio
12:28:37 <Alberth> well, you need all the luck you can have with the project, so I wish you as much luck as possible.
12:28:47 <TrueBrain> playing O5 now for 5 minutes .. still works all erfectly ... I have it when I can't reproduce :( :( :(
12:30:17 <TrueBrain> bah, now I had a crash :p Ghehe :)
12:30:22 <TrueBrain> I was building a building that was never built before :p
12:31:41 <TrueBrain> the input buffer is kind of nasty, how it is done .. relative clever, but nasty :p So it will be a bit tricky to find this error .. even more as DOSBox doesn't have it .. but I double-checked everything, and it should be correct ...
12:32:38 <Alberth> Program Termination: jumped to 4458:01D6, which is not decompiled.
12:32:39 <Alberth> The jump was triggered at decompiled/cs__B53B.c:490
12:32:39 <Alberth> The jump appears to originate from B53B:01D1.
12:32:39 <Alberth> It appeared to hang after selecting 'ordos' just by moving the mouse. then crashed by hitting a key, I think
12:33:22 <Alberth> ie i moved the mouse towards 'ordos', and when I reached it, the screen went black
12:33:34 <TrueBrain> most likely it clicked for you :p
12:33:39 <TrueBrain> that happens a lot .. random clicks :(
12:34:04 <Alberth> yeah, quite annoying in the build menu
12:34:52 <TrueBrain> and when I monitor the mouse, it really doesn't send it .. so somehow the input buffer gets wrong .. which can either be a buffer overflow, or bad locking between reading the buffer and writing via hardware
12:39:13 <TrueBrain> I still need to validate that piece of code
12:39:51 <TrueBrain> but I guess it is safe to say it happens .. and I should silently ignore the entry
12:40:55 <Alberth> DOS doesn't really mind reading 0, does it?
12:43:30 <DorpsGek> SVN: truebrain (r233) -Fix: sometimes there is a 0000:0000 entry in the Unit Pool Cache array. No idea if it is a valid entry, but ignore it for now
12:43:34 <TrueBrain> there you go Alberth :p
12:48:21 <Alberth> all those blood stains on the precious spice ;)
12:48:50 <TrueBrain> I really love the detail in the game :)
12:50:52 <TrueBrain> glx: for your collection: f__01F7_2A06_002A_9A90 seems to open a file, and f__01F7_23CC_0013_6B52 seems to close a file. The first takes 3 parameters, of which the first 2 are a pointer to the file to open. The other the mode I guess. The last function takes 1 parameter, fileno. I don't know how it related to the File_Open you detected
12:51:45 <glx> did you see my "yeah I finished A1" ?
12:52:01 <glx> that was with mingw build
12:52:05 <TrueBrain> and that you failed the password ;)
12:52:12 <TrueBrain> so the stackoverflow is getting less? :) :)
12:52:45 <glx> if you factorised duplicated stuff that helped :)
12:53:14 <TrueBrain> can you now also finish watching the intro?
12:55:19 <TrueBrain> I am now extending the decompiler even more .. it now knows which functions are being called (and which are jumps and stuff)
12:55:32 <TrueBrain> so next I just need to start at all those start-functions, and follow jumps ...
12:58:13 <glx> so duplicated code, but no calls for jumps ?
12:58:46 <TrueBrain> no duplicated code, and gotos for normal jumps
13:00:51 <TrueBrain> well, only duplicated code if 2 functions jump to the same piece of code
13:02:10 <Alberth> Program Termination: jumped to 4343:0BBF, which is not decompiled.
13:02:10 <Alberth> The jump was triggered at decompiled/cs__B4F2.c:3771
13:02:10 <Alberth> The jump appears to originate from B4F2:0BBA.
13:02:10 <Alberth> Please send the file 'memory/crash.bin' to upstream developers.
13:02:10 <Alberth> created while running in gdb, but that should not matter
13:02:37 <TrueBrain> that doesn't matter at all, indeed :)
13:02:54 <Alberth> keycodes 8 and 7F (delete/backspace) are not recognized
13:03:06 <TrueBrain> nope .. annoying aint it? :) Same as F1 .. F10 ..
13:03:11 <TrueBrain> I still have to find the right scancode :(
13:03:42 <Alberth> and I noticed that the mouse pointer is sometimes very slow in following the normal mouse
13:03:47 <TrueBrain> that is: I know the SDL scancode, but I don't know the DOS scancode :(
13:03:59 <TrueBrain> when there is a grey 'hint', it is
13:04:10 <TrueBrain> there is an infinite loop, waiting for mouse-click ..
13:04:36 <Alberth> yes that is the most obvious one
13:04:48 <TrueBrain> and because it every time switches the interrupts off ... there is a very low chance the interrupt is handled
13:04:57 <Alberth> I also say it once (but less severe) in the build menu
13:05:27 <TrueBrain> the whole problem with DOS games, they are designed like that: put the main thread in an infinite loop, and wait for the hardware to give input
13:05:36 <TrueBrain> no idea how to solve that in a simple way ...
13:06:29 <TrueBrain> (ideas are welcome ;))
13:06:32 <Alberth> there probably isn't a simple way
13:06:51 <TrueBrain> I guess in theory the disabling of interrupt isn't needed, as it only reads
13:07:01 <TrueBrain> and it is not possible for 2 threads to make race conditions when reading a single word
13:07:15 <TrueBrain> (as it can never read the word partly)
13:07:27 <TrueBrain> under the principle: every bus is at least 16 bits
13:08:16 <glx> the battle for dune begins NOW
13:08:29 <TrueBrain> so: uint16 head = g_input->historyHead; while (g_input->historyTail == head) { usleep(0); }, should work I guess
13:08:38 <TrueBrain> Xaroth: 0.1 is on schedule ;)
13:10:40 <glx> saved and loaded game too
13:16:01 <glx> right f__01F7_2A06_002A_9A90() is related to file opening :)
13:16:49 <TrueBrain> I noticed in the overlay manager ;)
13:17:01 <TrueBrain> the overlay manager only calls that function to open a file, and gets a filenumber back
13:18:53 <TrueBrain> if (!emu_flags.zf) goto f__217E_002E_0003_5DA5();
13:18:54 <TrueBrain> goto f__217E_013A_000B_6C7A();
13:18:57 <TrueBrain> :) (ignore the () for a moment :p)
13:22:19 <glx> I followed the calls from f__01F7_2A06_002A_9A90() and indeed it create or open a file
13:22:40 <TrueBrain> good :) Now we need to give it a nice name ;)
13:23:58 <TrueBrain> well, I rather have File_Open and rename the current one to File_Core_Open, or what ever
13:24:02 <TrueBrain> I mean .. what seperates them ;)
13:25:05 <glx> I need to fully analyse the code
13:25:23 <TrueBrain> k .. well .. I hope to have more readable code in the next hour .. I need one more step :)
13:25:36 <TrueBrain> labels are in place, gotos are .. now I just need to add enough of them in 1 function ;)
13:26:55 <glx> intro passed with msvc too
13:27:26 <TrueBrain> that makes me very happy too
13:27:42 <TrueBrain> as the code duplication reduction was not something I planned ... and for sure I didn't expect such impact ...
13:27:57 <TrueBrain> but that is only more good news, meaning on 1nov we can release a version which works on most systems :)
13:27:59 <glx> less calls always helps :)
13:28:19 <TrueBrain> well, the amount of calls didn't really reduce
13:28:24 <TrueBrain> the functions only became smaller
13:28:37 <TrueBrain> (as soon as it founds a common branch, it jumps there, instead of finishing his code
13:28:43 <TrueBrain> that is why it suprises me so much ;)
13:28:49 <glx> but some jumps are no longer calls I guess
13:29:37 <TrueBrain> before: if (a) goto A; <code> <common code> goto C. label A: <common code> goto C
13:29:58 <TrueBrain> after: if (!a) { <code> } goto D; label D: <common code> goto C
13:30:12 <TrueBrain> where goto are function-calls
13:30:54 <TrueBrain> but okay, lets not complain, lets celebrate!! :)
13:31:36 <TrueBrain> the game sometimes hangs in general btw
13:31:39 <glx> option menu is pressed when I move over it, but click does respond
13:31:41 <TrueBrain> or continues after a long time :p
13:31:48 <TrueBrain> you went to Mentat :)
13:31:57 <glx> ah yes, it works again now
13:32:04 <TrueBrain> really? It never recovered for me :(
13:32:32 <glx> ha no it works by itself, but mouse doesn't respond indeed
13:32:44 <TrueBrain> known bug, affects all platforms
13:34:50 <Alberth> bah, got a duplicate crash report, do you want that? If yes, did you already copy the previous crash.bin?
13:35:07 <TrueBrain> nah, duplicates are not useful
13:35:11 <TrueBrain> and yes, I already have the last one
13:35:27 <TrueBrain> I am really happy someone is really playing the game over and over ;)
13:36:40 <Alberth> problem is that it crashes less, so I must spend more time playing :p
13:37:10 <glx> and you say it's a problem ?
13:41:28 <TrueBrain> added a nice news/topic entry to tell progress
13:41:39 <TrueBrain> now I need to finish this last step .. gr .. I am going to do it the ugly way, fuck it :)
13:42:29 <glx> f__01F7_22E8_0011_1764 is Get/Set file attribute
13:42:42 <TrueBrain> if you can send me a nice patch later today, that would be lovely :)
13:44:09 * Alberth goes searching where to stick them in the source
13:45:35 <TrueBrain> and the map seems valid yes
13:45:58 <TrueBrain> then it is a question of finding the SDL scancodes and linking them ;)
13:46:11 <TrueBrain> F keys do things like Save I believe
13:46:21 <TrueBrain> are not mapped, so will most likely crash when you try them ;)
13:50:36 <Alberth> I would expect crashes indeed.
13:52:48 <TrueBrain> okay ... the Mentat mouse-hang problem, is 100% sure a problem of my C-ifying it :p
13:52:57 <TrueBrain> when I run it with the JIT, it works fine :p
13:56:35 <TrueBrain> but okay, I was doing something else ...
14:03:56 <Alberth> Program Termination: jumped to 42B7:0BBF, which is not decompiled.
14:03:56 <Alberth> The jump was triggered at decompiled/cs__B4F2.c:3771
14:03:56 <Alberth> The jump appears to originate from B4F2:0BBA.
14:03:56 <Alberth> destination looks new
14:04:49 <TrueBrain> it is the same, it only looks different :p
14:05:02 <TrueBrain> (the 42B7 is a runtime value, for the overlays)
14:09:32 <Alberth> I cannot load a game from the main menu any more due to the above atm
14:09:40 <TrueBrain> k, will fix it in a sec :)
14:09:45 <TrueBrain> just my decompiler is currently not available :p
14:10:04 <Alberth> haha, I lost all my money while building the first energy plant :)
14:10:15 <TrueBrain> that happens in some rare cases, yes :P
14:12:38 <glx> hmm what are s, o and d for emu_get_memory ?
14:13:06 <TrueBrain> segment, offset and displacement
14:13:19 <TrueBrain> s:(o+d) & 0xFFFF is effective address
14:16:50 <TrueBrain> k, first attempt of my prettifier seems promising
14:17:00 <TrueBrain> just the order of functions is messed up, which is ugly :p
14:18:04 <glx> ok emu_File_Create seems to be called with 3 args
14:18:31 <TrueBrain> pointer to name, and mode ;)
14:19:01 <glx> there are 2 different calls
14:19:33 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, 0x8));
14:19:33 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, 0x6));
14:19:33 <TrueBrain> Create_Or_Exit and Create? Dunno .. just guessing blindly here :)
14:19:54 <TrueBrain> first two parameters of the function
14:20:01 <glx> ,...emu_xorw(&emu_ax, emu_ax);
14:20:01 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, -0x2));
14:20:09 <TrueBrain> wow, you paste slow ... :p
14:20:30 <glx> so 0 or a local variable for the third arg
14:21:06 <TrueBrain> what gives the question: what is in loc02?
14:23:38 <glx> ,...emu_xorw(&emu_ax, emu_ax);
14:23:39 <glx> ,...f__01F7_2A75_0005_BDB6(); return;
14:23:39 <glx> ,...emu_movw(&emu_get_memory16(emu_ss, emu_bp, -0x2), emu_ax);
14:23:39 <glx> ,...f__01F7_2A86_0012_8105(); return;
14:23:55 <TrueBrain> most likely there is a single other route
14:24:16 <TrueBrain> k, my labels seems to work .. now I just need to keep the order correct
14:25:12 <glx> hmm maybe it's done like that to keep zflag
14:25:33 <TrueBrain> what happens a lot is that one branch sets something to a fixed value, and continues the rest of the code
14:25:41 <TrueBrain> where another branch uses some calculated value, and merges somewhere along the line
14:26:34 <glx> ,...emu_cmpw(&emu_get_memory16(emu_ss, emu_bp, -0x2), 0xFFFF); <-- I skip that :)
14:27:01 <glx> so loc02 is -1 by default, then can be set to 0
14:27:46 <DorpsGek> SVN: truebrain (r234) -Fix: also take libs into account in the Makefile
14:27:51 <TrueBrain> forgot to credit you :'(
14:29:55 <Alberth> hmm, I broke something
14:30:16 <TrueBrain> where? what? how? :p
14:31:39 <Alberth> It says './opendune: error while loading shared libraries: libemu.so: cannot open shared object file: No such file or directory'
14:31:47 <glx> hmm it's not easy to follow stack stuff sometimes
14:32:01 <TrueBrain> Alberth: ah, yes .. :)
14:32:08 <TrueBrain> I should not just have committed your patch without checking myself :p
14:33:03 <TrueBrain> dunno why it flips over it btw ..
14:34:05 <TrueBrain> (I can't try anything :'()
14:35:51 <TrueBrain> decompiled/cs__01F7.c:21261: error: label 'l__4481' defined but not used <- LOL!
14:36:54 <DorpsGek> SVN: truebrain (r235) -Fix (r234): correctly do the Makefile change .. $^ is a nasty operator
14:39:57 <TrueBrain> I really really LOVE IO cache :)
14:45:10 <Alberth> Program Termination: jumped to 4081:0185, which is not decompiled.
14:45:10 <Alberth> The jump was triggered at decompiled/cs__B527.c:466
14:45:10 <Alberth> The jump appears to originate from B527:015D.
14:45:22 <TrueBrain> gimme the patch later on, then I will run them all, not from crash-log
14:46:12 <TrueBrain> this is weird ... I have a piece of code which does a NEAR jump, so inside the same segment .. but 2 of those jumps jump outside the segment :p
14:51:36 <TrueBrain> k, seemly 'bug' like
15:14:27 <TrueBrain> lol, I lost a patched function .. well, yeah, that is kind of tricky :)
15:16:27 <glx> hmm I don't understand something
15:16:44 <glx> before calling Interrupt_DOS, flags are pushed
15:17:53 <glx> Int21 may change them but on return, Interrupt_DOS pops flags, then the code checks cf (for example) but it's not the right one then
15:18:14 <TrueBrain> glx: interrupts change the flags in the stack
15:19:41 <TrueBrain> took me a while before I understood that ;)
15:23:16 <glx> I still don't get how it's done
15:23:34 <TrueBrain> I made that general, in the hardware interrupt handlers, the current flags are stored in the stack on return
15:23:38 <TrueBrain> so on popf they are loaded
15:23:48 <TrueBrain> all you need to know is that it happens ;) How is less important ;)
15:24:04 <glx> ,...emu_get_memory16(emu_ss, emu_sp, 4) = emu_flags_all; <-- there
15:24:28 <TrueBrain> GRR! Some jumps ARE function-calls, others are not ...
15:24:32 <TrueBrain> how to seperate ... no clue ...
15:26:10 <Alberth> hmm, pressing ESC at the build menu also causes a crash
15:26:33 <TrueBrain> Alberth: I first finish up my patching, then I will apply and run yours
15:27:00 <TrueBrain> I now have a big problem with functions in the same segment which are replaced
15:27:09 <Alberth> I want some dinner anyway
15:27:18 <TrueBrain> that sounds like a very good idea too
15:28:29 <Alberth> btw func-keys do not cause a crash here. the first few jump to mentat, build, etc. the other ones seem not to do anything
15:29:09 <TrueBrain> wow .. that is unexpected :)
15:29:46 <TrueBrain> hmm .. I need more than 32 bits ... grr
15:30:00 <TrueBrain> hmm .. even worse .. I need to feed it data at a later stage :(
15:30:13 <TrueBrain> k, dinner .. then we will see :)
15:59:59 <TrueBrain> Alberth: what keys did you add exactly?
16:08:37 <TrueBrain> okay, it seems my jump-stuff works :)
16:09:03 <TrueBrain> cut 30,000 lines :)
16:10:04 <DorpsGek> SVN: truebrain (r236) -Update: the decompiler now tries to combine functions, and use goto with labels, instead of function-calls
16:11:03 <DorpsGek> SVN: truebrain (r237) [LibEMU] -Documentation: add per row which scancodes we talk about in keymaps (Alberth)
16:12:03 <TrueBrain> Alberth: 'delete' key is 'backspace'?
16:17:15 <TrueBrain> haha, yes, sorry :)
16:17:52 <DorpsGek> SVN: truebrain (r238) [JIT] -Add: mapped another 6 functions (Fn keys, ESC in build) (tnx to Alberth)
16:23:58 <glx> Erreur,...384,...fatal error C1083: Impossible d'ouvrir le fichier source : '..\decompiled\cs__261F.c' : No such file or directory,...c1 <--msvc says you forgot a step :)
16:24:31 <TrueBrain> makes me wonder why it was removed in the first place ....
16:24:58 <glx> and mingw says there are undefined references
16:25:03 <TrueBrain> because of that, dah
16:25:38 <DorpsGek> SVN: truebrain (r239) -Fix (r236): for unknown reason SVN decided to remove a file
16:28:08 <glx> and filename is 2 args indeed
16:28:22 <TrueBrain> remember that stack works reversed
16:28:28 <TrueBrain> so +0x2 is the first parameter
16:28:32 <TrueBrain> +0x4 is the second, etc
16:29:19 <TrueBrain> depends if you base on bp or sp, but yes :p
16:31:10 <DorpsGek> SVN: truebrain (r240) -Fix (r239): unresolved calls at end of function had wrong emu_last_ip
16:32:37 <glx> how do I specify a 32bit arg in function_name ?
16:33:00 <TrueBrain> you have one? Cool ;) I often confuse a 32bit for a cs:ip pair :p
16:33:07 <TrueBrain> ds:dx is cs:ip pair (Pointer)
16:33:23 <TrueBrain> (well, most of the time anyway)
16:33:46 <glx> yes like a filename is a ds:dx pair
16:33:50 <TrueBrain> I added 'csip' to the name, but anything else that makes it clear is fine by me
16:35:56 <glx> hmm let me find args for other named functions too
16:38:47 <TrueBrain> I guess r240 also contained the update of r238 :p Oh well :)
16:39:42 <DorpsGek> SVN: truebrain (r241) [JIT] -Add: mapped another 24 functions (Save/load with more than 5 entries) (tnx to Alberth)
16:40:14 <Alberth> - . del backspace f1 - f12
16:40:22 <TrueBrain> backspace fails here :(
16:41:57 <Alberth> yeah one of them didn't work
16:42:11 <glx> hmm emu_File_Read disapeard
16:43:06 <TrueBrain> glx: then it was a partial function I guess?
16:43:10 <TrueBrain> I will restore it in a sec :)
16:43:57 <DorpsGek> SVN: truebrain (r242) [JIT] -Add: 1 more problem found by Alberth
16:44:19 <TrueBrain> Alberth: one of your crash-logs gives me a BIG backtrace .. and as there are always a few mistakes in it, I can't be sure what is wrong and what not ..
16:44:25 <TrueBrain> so I won't add it, and we will see if it happens again ;)
16:44:47 <DorpsGek> SVN: truebrain (r243) -Update (r241, r242): update decompiled code
16:45:03 <Alberth> ok, I'll try to find it again :)
16:46:07 <DorpsGek> SVN: truebrain (r244) [JIT] -Add: 1 more problem found by TrueBrain
16:46:19 <DorpsGek> SVN: truebrain (r245) -Update (r244): update decompiled code
16:48:09 <DorpsGek> SVN: truebrain (r246) -Update: always make sure named functions show up, even if they are a sub-part of a bigger function
16:49:05 <DorpsGek> SVN: truebrain (r247) [LibEMU] -Add: a few SDL scancodes -> DOS scancodes (F1 - F12, del, backspace, - and .) (patch by Alberth)
16:50:01 <TrueBrain> so I fucked up the input handler somewhere .. lets see if I can find where ;)
16:52:25 <glx> diff refreshed (I changed emu_File_Read address)
16:52:51 <TrueBrain> it is mode yes, you can remove the ? :)
16:53:05 <TrueBrain> create really first has attributes, then filename?
16:53:51 <TrueBrain> but both ar efine by me
16:54:18 <glx> and yes, create first has attributes
16:55:13 <glx> write1 and write2 are "subfunctions" so I can't really gets args
16:56:20 <TrueBrain> okay ... I think I just need to do the whole input stuff again ...
16:56:37 <Alberth> code is getting into a nice shape
16:57:04 <DorpsGek> SVN: truebrain (r248) -Add: more function names and parameters with them (glx)
16:57:13 <TrueBrain> Alberth: yeah, it becomes workable ;)
16:57:41 <Alberth> unfortunately, my cheat against the copy protectio got lost
16:57:52 <TrueBrain> I named the function ;)
16:58:01 <TrueBrain> emu_Security_ValidateAnswer
16:58:05 <TrueBrain> first if, reverse ;)
17:03:17 <TrueBrain> (a xor b), isn't that the same as (a != b)
17:03:26 <glx> ha seems File_Write1 has no params indeed
17:03:55 <glx> it's used with fixed values
17:04:36 * Alberth thinks that equality is correct
17:04:53 <glx> (01F7:0291):003D is the buffer used
17:05:01 <TrueBrain> static buffers .. hmm ... :)
17:05:08 <Alberth> except for the non-boolean result value of course
17:05:20 <TrueBrain> Alberth: how do you mean?
17:05:56 <Alberth> '15 xor 1' == '14' and not '1' or 'true'
17:06:11 <TrueBrain> ah, lol, yes, I meant boolean result :)
17:08:02 <TrueBrain> changing decompiled.h is annoying :(
17:14:29 <glx> 01F7:0295[0x17] is another error message :)
17:14:45 <TrueBrain> create a struct, and put it in there ;)
17:15:07 <glx> but I don't know it's content
17:15:33 <TrueBrain> put a printf of the location :)
17:16:27 <TrueBrain> 0295: "Runtime overlay error"
17:16:57 <TrueBrain> that is all the static text in that area
17:21:32 <glx> so refreshed the diff with a better naming
17:22:04 <TrueBrain> maybe: emu_Print_Error_Overlay
17:22:11 <TrueBrain> I like it when from left to right are the categories
17:22:22 <TrueBrain> it first of all is a print function, next is prints errors, errors about overlays, ...
17:22:45 <TrueBrain> and why Print_Error1? Do you expect a Print_Error2?
17:23:14 <glx> anyway I can try to get more info about what it prints
17:25:59 <glx> oh it prints something at 0x3D in current overlay ;)
17:26:12 <glx> ,...emu_movw(&emu_dx, 0x353F);
17:26:13 <glx> ,...emu_movw(&emu_get_memory16(emu_cs, 0x00, 0x291), emu_dx);
17:26:28 <glx> at entry point f__01F7_0000_000C_3D76()
17:26:42 <TrueBrain> it just puts the datasegment in the codesegment
17:26:50 <TrueBrain> cs:0291 becomes 0353F
17:26:59 <TrueBrain> 353F is where all the global data is
17:29:04 <glx> 353F:003D "Abnormal program termination"
17:29:23 <TrueBrain> so give it a nice name ;)
17:31:55 <glx> hmm it does many other things after printing the message it seems
17:32:44 <TrueBrain> 4C to DOS interrupt ;)
17:35:13 <glx> .,.../* Unresolved jump */ emu_ip = 0x0291; emu_last_cs = 0x01F7; emu_last_ip = 0x0291; emu_last_length = 0x0009; emu_last_crc = 0xFAE0; emu_call(); <-- this is not a jump ;)
17:35:31 <TrueBrain> comment is always correct
17:35:33 <TrueBrain> I made sure of that
17:35:38 <TrueBrain> the code after it is .. well .. internals :)
17:35:50 <TrueBrain> well, in that case the code aborted before it comes there
17:37:55 <TrueBrain> there can be a good reason a function is never called :)
17:57:43 <TrueBrain> I am trying to find the bug in the input handler, but it is hiding in a big blob of code :(
18:07:59 <Alberth> Program Termination: jumped to 1A34:2F67, which is not decompiled.
18:07:59 <Alberth> The jump was triggered at decompiled/cs__1A34.c:5614
18:07:59 <Alberth> The jump appears to originate from 1A34:2F5A.
18:08:18 <Alberth> capturing a building crashed :)
18:08:49 <glx> updated again, 2 more function names
18:24:27 <TrueBrain> lol, I got the question: if you execute a shell from a shell, how is it scheduled
18:24:33 <TrueBrain> my answer: synchronized.
18:24:58 <TrueBrain> okay .. euh .. blocked, serial, after eachother, waits for shell to return, not paralel, not asynchron, ...
18:25:09 <TrueBrain> after 15 of such descriptions I think I confused the user enough for him to walk away :p
18:25:17 <TrueBrain> never knew there were so many ways to describe that behavoir :p
18:51:51 <DorpsGek> SVN: truebrain (r249) -Fix: wrong order of parameters for InsideRegion()
18:53:48 <DorpsGek> SVN: truebrain (r250) -Fix: mouse didn't always release, leaving the game unplayable
18:55:36 <DorpsGek> SVN: truebrain (r251) [JIT] -Add: 1 more problem found by Alberth
18:55:48 <DorpsGek> SVN: truebrain (r252) -Update (r251): update decompiled code
18:56:32 <DorpsGek> SVN: truebrain (r253) -Add: more function names (glx)
18:57:39 <TrueBrain> so ... what next .. hmm ..
18:58:58 <glx> decompiled starts to be readable ;)
19:01:53 <TrueBrain> I wish there was a good way to know if 'ds' is 353F .. then I could lookup variables automaticly :)
19:04:37 <TrueBrain> I added 2 emu_Empty functions .. they are empty, and do nothing
19:04:39 <TrueBrain> you know a better name?
19:05:18 <glx> hard to get a better name
19:05:42 <DorpsGek> SVN: truebrain (r254) -Add: 2 more function names (well .. these functions do nothing, so Empty function names ;))
19:07:15 <glx> maybe they are place holders
19:08:17 <TrueBrain> most likely; many code suggests there is a possibility for debug code
19:08:23 <TrueBrain> like #if DEBUG around this
19:09:07 <DorpsGek> SVN: truebrain (r255) -Update: mov(&a, b) is always a = b;, and sets no flags. So resolve it via the decompiler
19:09:33 <glx> and the next function in this file plays a lot with global variables ;)
19:10:19 <TrueBrain> I hope r255 helps ..
19:11:07 <glx> mov doesn't even set zf ?
19:12:46 <glx> it's indeed easier to read
19:13:50 <TrueBrain> I am now trying to make the ifs more readable
19:13:59 <TrueBrain> but that fails somewhere on runtime .. for unknown reasons
19:14:12 <TrueBrain> emu_orw(&emu_ax, emu_get_memory16(emu_ss, emu_bp, 0xA));
19:14:13 <TrueBrain> - if (!emu_flags.zf) goto l__012B;
19:14:15 <TrueBrain> + if (emu_ax != 0) goto l__012B;
19:14:22 <TrueBrain> hmm .. no .. that is valid ..
19:14:31 <TrueBrain> emu_ax |= blabla .. then the check is for non-zero
19:18:51 <glx> 01F7:02F7:0007:3850,...emu_Drive_Get_Default,...# (&variable_csip) <-- is this clear ?
19:19:33 <TrueBrain> hmm .. it is not the if that prevents my savegames from loading ...
19:19:44 <glx> or just &variable meaning it's a csip
19:20:08 <TrueBrain> sooner or later someone has to make it C, and till then this is just a notepad :)
19:20:34 <TrueBrain> euh .. r255 makes loading savegames impossible :(
19:23:01 <TrueBrain> + emu_si = (int8)emu_ax;
19:23:03 <TrueBrain> small difference ;)
19:23:48 <TrueBrain> + emu_ax = (int8)emu_al;
19:23:50 <TrueBrain> that is more like it :)
19:24:39 <DorpsGek> SVN: truebrain (r256) -Fix (r255): decompiler forgot to do sign-extend when required
19:26:09 <TrueBrain> error: comparison is always false due to limited range of data type
19:26:13 <TrueBrain> how to fix those in a nice way ...
19:29:05 <DorpsGek> SVN: truebrain (r257) -Update: the decompiler can resolve certain if-statements based on the code above, to more clear comparisons
19:29:33 <DorpsGek> SVN: truebrain (r258) -Fix: the original code contains statements which trigger a warning. So no longer consider warnings errors, and wait till someone fixes the (legit) warnings
19:29:39 <TrueBrain> I wonder if MSVC likes r257
19:29:45 <TrueBrain> either way .. code should be even more readable now ;)
19:35:48 <TrueBrain> I was going to try a random function .. it turns out to be 600 lines
19:35:51 <TrueBrain> never a good thing to try :p
19:37:23 <TrueBrain> I wonder how often I can assume emu_ds points to the global struct ..
19:37:46 <TrueBrain> it is very annoying to every time lookup those values ..
19:39:07 <TrueBrain> I guess that is another optimization step: keep track of all values of registers, see if you can make those things a bit nicer for the eye :p
19:39:17 <TrueBrain> like: emu_ax = 0x353F; emu_ds = emu_ax; push(emu_ax);
19:42:48 <glx> and maybe I should silent C4102 warnings :)
19:42:57 <TrueBrain> out of range, yes please :)
19:43:31 <DorpsGek> SVN: truebrain (r259) -Add: more function names (glx)
19:43:43 <glx> 'label' : unreferenced label <-- that's C4102 :)
19:44:00 <TrueBrain> there can be a lot of cleanup in that area, but for now I don't care ;)
19:55:35 <glx> I found an unresolved jump that will stay unresolved for a long time I think :)
19:55:52 <TrueBrain> there are plenty; but do tell :)
19:56:07 <glx> in f__01F7_0773_001E_D7DA()
19:56:20 <glx> cf = 0 means it failed to seek in the file
19:56:43 <TrueBrain> we can fake that to get the required data ;)
19:57:12 <TrueBrain> it is so hard to work on functions .. I can translate them to C, but they do something I don't know .. so I don't think it is useful to do ..
19:57:50 <glx> for now I continue naming int21 calls ;)
19:57:59 <TrueBrain> it is a good start :)
19:58:05 <glx> these functions are easy to understand
19:58:08 <TrueBrain> I am just trying somewhere .. I believe Units :p
19:58:16 <TrueBrain> why not make them real C?
19:58:21 <TrueBrain> should be 'relative' easy too?
19:58:35 <glx> maybe once I named all of them
19:59:10 <TrueBrain> here I have functions of which I know they do something with Unit * .. but no idea what :p
19:59:40 <glx> already good to know "where" they work
20:09:29 <TrueBrain> emu_cmpw(&emu_get_memory16(emu_es, emu_bx, 0x56), emu_si); <- it would be so useful if it knew it was Unit * :p
20:09:35 <TrueBrain> but that is next to impossible
20:09:43 <TrueBrain> either way ... now I can't see what 0x56 is used for
20:10:11 <TrueBrain> then maybe I can figure out what it does :p
20:14:21 <TrueBrain> ah .. after long looking, I think I know what a few things mean :p
20:14:55 <TrueBrain> at least .. I think to know where in the struct of a building and airunit is which unit he is picking up (harvester in the building case)
20:15:16 <TrueBrain> building 15 and 16 .. we really need a list of that :p
20:20:20 <TrueBrain> that changes things
20:20:46 <glx> ,...emu_subw(&emu_cx, emu_cx);
20:20:47 <glx> ,...emu_subw(&emu_dx, emu_dx);
20:20:47 <glx> means cx = 0, dx = 0 or I'm wrong ?
20:21:01 <TrueBrain> yes, but in a very weird way
20:21:06 <TrueBrain> mostly they use xor for that
20:22:33 <TrueBrain> comments on the names? Better suggestions?
20:22:38 <glx> this function does even weirder ;)
20:22:59 <glx> it writes 0 bytes from ds:0 to a file
20:25:04 <TrueBrain> shall I need to add comments? Seems pretty obvious to me ..
20:29:47 <TrueBrain> I miss 4 entries in the enum, and a few buildings ..
20:29:50 <TrueBrain> but for that I need to play more :p
20:37:55 <glx> hmm int21 0x40 is not correct it seems
20:39:11 <glx> writing 0 bytes should truncate file at current position
20:40:25 <TrueBrain> that the description says, yes
20:40:28 <TrueBrain> but is that ever used?
20:40:59 <glx> f__01F7_29F4_000E_B8B9 does that
20:41:14 <TrueBrain> so extend libemu :p I wouldn't know how to do it ....
20:44:17 <glx> well we will see if it's really needed
20:44:52 <DorpsGek> SVN: truebrain (r260) -Add: figured out a few enum-values for Units / Buildings / Houses
20:45:25 <TrueBrain> so I can now guess that at :22 of the building struct is the current unit attacking
20:45:49 <TrueBrain> which makes this function something like: Unit_Died
20:48:16 <TrueBrain> Unit_LoseTarget ...
20:49:48 <glx> all functions calling int21
20:50:38 <DorpsGek> SVN: truebrain (r261) -Add: more resolved functions (glx)
20:51:05 <TrueBrain> 217E is the overlay manager
20:52:41 <TrueBrain> it calls a function which just gives the parameter back, basicly :p
20:52:50 <TrueBrain> it is the unit index .. which is just looked up
20:52:58 <TrueBrain> yes, it confirms if the unit exists ..
20:55:46 <TrueBrain> hmm .. it does something with the higher bits of the unit-number in some situations .. very weird
21:00:52 <Xaroth> TrueBrain: not catching up, more like experiencing it all at once :P
21:01:21 <TrueBrain> what were you doing there?
21:01:22 <Xaroth> 5 adults in an opel corsa on the nurnburgring
21:01:41 <Xaroth> was more fun in the audi s2
21:02:06 <Xaroth> mate's birthday tomorrow, so we went to the race track seeing he's a race freak
21:03:23 <TrueBrain> what the ... I thought I was looking at a unit, but all of a sudden it opens stuff in the building info struct ..
21:03:28 <TrueBrain> I am official confused!
21:09:03 <TrueBrain> is there an exception on a heavy factory with, say, walking a unit in it or something?
21:10:18 <TrueBrain> (I am just randomly guessing what things do)
21:13:10 <TrueBrain> ah, no, I think it is the house ...
21:26:56 <TrueBrain> so freaking annoying to see code which you can't put your finger on what it does exactly :) I only have ideas and wild guesses :p
21:32:35 <glx> ok 29E8 and 28FD int21 calls are all calls from f__1DB6_0004_000B_BFBA()
21:34:29 <glx> and they do too many things to be named
21:35:55 <TrueBrain> I don't get why index is 16bit, while it is used as 8bit all the time, and something special is stored in higher values ... :s
21:37:12 <glx> 29E8 installs/desinstalls some interrupt handlers (9 and 23)
21:37:36 <TrueBrain> ghehe, always a bitch, hex :)
21:37:57 <glx> but it does other things before installing
21:38:28 <TrueBrain> oh, most likely CTRL+BREAK
21:39:03 <glx> f__29E8_0D47_0096_3777 is interrupt 9 handler
21:40:02 <TrueBrain> it names another hardlink ;)
21:40:12 <TrueBrain> emu_Input_Keyboard_EventHandler as name please :)
21:40:18 <TrueBrain> (keeps it consistant with mouse :p)
21:40:22 <glx> I can see emu_Input_Keyboard_Translate in this function :)
21:40:53 <TrueBrain> I did some work on the keyboard already, yes
21:40:59 <glx> and emu_Input_HandleInputSafe
21:41:13 <glx> so my deductions seems correct ;)
21:42:09 <glx> is it generated or should I edit it by hand?
21:45:39 <TrueBrain> harvester find refinery is hardcoded
21:50:22 <glx> what are exactly hard links ?
21:50:38 <TrueBrain> when the hardware calls something, it needs to know which C function is attached to that (if known)
21:51:41 <TrueBrain> I dunno what is so special about harvesters that they have their own piece of code to locate a refinery
21:53:29 <TrueBrain> whoho, found the position of units and buildings :)
21:55:18 <TrueBrain> going to make a struct 'tile' for that .. as it is a 32bit value, so I suspect it is a x/y pair
21:55:50 <TrueBrain> f__0F3F_00B4_002A_89B2 <- manhattan distance :)
21:56:29 <TrueBrain> well, not really ... longest * 2 + shortest
21:56:37 <TrueBrain> what do you want to call such distance? :p
21:57:11 <glx> ok 2 hard linked functions named
21:57:58 <glx> f__01F7_0000_000C_3D76 could have been renamed sooner (emu_Entry_Point)
21:58:14 <TrueBrain> hmm .. what is 'entry' for group? :)
21:58:19 <TrueBrain> maybe emu_Game_Start?
21:58:22 <TrueBrain> emu_Application_Start?
21:58:41 <TrueBrain> but emu_Entry_Point says that emu_Entry should be a category ;)
21:59:31 <TrueBrain> still I would like a category in the name .. but I don't know what to call it :'(
22:01:36 <TrueBrain> f__0F3F_0086_0017_EA43 <- it is tile related, but what does it do? :s
22:04:58 <TrueBrain> well .. what I tihnk is a tile .. for sure it is related :p
22:05:30 <TrueBrain> I have this function, and when the unit is a harvester, it makes perfectly sense .. it first tries to find an empty, then it tries to find any
22:05:36 <TrueBrain> but for non-harvesters it is plain weird
22:06:55 <Xaroth> hm, emu_bl and emu_al o_O
22:07:11 <Xaroth> not on my note list :o
22:07:23 <TrueBrain> you really missed much the last few days :)
22:07:34 <TrueBrain> emu_bx.l -> emu_bl, emu_bx.h -> emu_bh, emu_bx.x -> emu_bx
22:08:01 <Xaroth> but i missed a lot while at customer :/
22:08:12 <Xaroth> i won the nerd of the day award though that day
22:09:45 <glx> something like (arg2 & 0xFF00) >> 2) | ((arg1 & 0xFF00) >> 4)
22:10:00 <TrueBrain> some compating of the location or something?
22:12:43 <Xaroth> I can clearly notice glx has more experience with C than me :P
22:12:53 <Xaroth> seeing I was still stuck at the xor/or 's :P
22:14:15 <glx> but that doesn't help to understand what's the goal of it
22:14:44 <glx> hmm maybe a hash for collision checks
22:15:47 <TrueBrain> after that it is given to another function
22:15:55 <TrueBrain> so that would make sense, yes
22:19:08 <Xaroth> love the forum post btw, tb
22:20:16 <Xaroth> moved it to announcement status, and revoked announcement status from the other
22:20:23 <Xaroth> so it'll be sticked to the top
22:23:09 <TrueBrain> hmm .. I am not 100% sure about this FindBuilding .. oh well
22:24:11 <DorpsGek> SVN: truebrain (r262) -Add: introduce a tile struct
22:24:34 <DorpsGek> SVN: truebrain (r263) -Add: named functions, named struct entries, fixed up aligning (because of the renaming)
22:25:53 <DorpsGek> SVN: truebrain (r264) -Add: named 2 more functions (glx)
22:27:22 <TrueBrain> slowly ... things are getting shape
22:27:55 <TrueBrain> [00:09] <glx> something like (arg2 & 0xFF00) >> 2) | ((arg1 & 0xFF00) >> 4) <- why the >> 4 btw?
22:28:32 <glx> ,...emu_orb(&emu_al, emu_bh);
22:29:34 <TrueBrain> f__0F3F_00F3_0011_5E67 <- TileIndexDiff? :)
22:30:17 <TrueBrain> I think high is the position and low is the offset inside the tile, or something
22:31:12 <glx> hmm arg1+arg3 and arg2+arg4
22:31:36 <TrueBrain> f__0F3F_0076_0008_A51E <- GetX? :)
22:33:29 <glx> but it looks crazy at first look :)
22:33:40 <glx> like call with 2 args, return the first
22:33:42 <TrueBrain> you have to realise the C behind it :)
22:34:25 <TrueBrain> ovl__34C1 <- I guess pathfinding or something simular
22:34:30 <TrueBrain> check f__0F3F_0125_000D_4868 ;)
22:35:26 <glx> f__0F3F_007E_0008_A4DE <- GetY then
22:36:42 <TrueBrain> f__0F3F_009D_0017_8464 <- the 'hash' we said above back to tile?
22:38:23 <TrueBrain> maps are never bigger than 128x128?
22:39:22 <glx> but indeed f__0F3F_009D_0017_8464 looks like the reverse of f__0F3F_0086_0017_EA43
22:40:14 <TrueBrain> struct { uint16 x; uint16 y; } s;
22:40:15 <TrueBrain> struct { uint8 ox; uint8 x; uint8 oy; uint8 y; } d;
22:40:24 <TrueBrain> any suggestions for the naming? (this is inside a union)
22:41:43 <TrueBrain> you have to type it a lot
22:42:16 <glx> s and d are in the same "type"
22:42:27 <TrueBrain> I don't think Xaroth gets the problem :)
22:42:41 <Xaroth> no, not really, but that doesn't mean I can't shout random ideas :)
22:42:49 <TrueBrain> Xaroth: there is a struct 'tile32'
22:42:57 <TrueBrain> it contains a uint32 value 'tile'
22:43:08 <TrueBrain> each 'tile' has an x and y component: struct { uint16 x; uint16 y; } s;
22:43:20 <TrueBrain> so: tile32 position; position.s.x = 12; position.s.y = 12;
22:43:29 <TrueBrain> easier than: position.tile = (12 << 16) + 12;
22:43:37 <TrueBrain> now each x and y have a 'position_x' and 'offset_x'
22:43:45 <glx> fun on big endian though ;)
22:43:58 <TrueBrain> glx: this is LE only ;) Not even going to try to port it to BE at this point :)
22:44:35 <TrueBrain> 0F3F:0037:000F:E3D8 emu_Tile_GetPosXY # (tile_tile)
22:44:37 <TrueBrain> 0F3F:0046:000C:9E1E emu_Tile_GetPosX # (tile_tile)
22:44:38 <TrueBrain> 0F3F:0052:000C:9E02 emu_Tile_GetPosY # (tile_tile)
22:44:40 <TrueBrain> 0F3F:0076:0008:A51E emu_Tile_GetY # (tile_tile)
22:44:41 <TrueBrain> 0F3F:007E:0008:A4DE emu_Tile_GetX # (tile_tile)
22:44:44 <TrueBrain> first 3: return the 'position_x'/'position_y'
22:44:51 <TrueBrain> the last 2: return the 's.x'/'s.y'
22:44:56 <TrueBrain> (including the offset)
22:46:59 <glx> hmm emu_Tile_GetPosXY doesn't clear offset it seems
22:47:39 <TrueBrain> any suggestions/ideas?
22:49:51 <TrueBrain> f__0F3F_0360_0038_97C0 <- same as Distance, but this time for the lower part only ..
22:53:07 <TrueBrain> f__0F3F_034C_0012_18EA
22:53:14 <TrueBrain> it moves the position from the Y value
22:53:18 <TrueBrain> and ors that with the X value?!
22:54:39 <TrueBrain> wait, just another way of packing ..
22:55:24 <glx> and arg1 is a 'reference'
22:55:52 <TrueBrain> no, it combines a X and Y value in a 'pack' form
22:56:11 <glx> I mean arg1 is changed as a result
22:57:00 <TrueBrain> wow, named most of them now
22:57:29 <TrueBrain> 3 ways of getting the X .. from a packed value, the position from a tile, and the complete value from a tile ...
22:59:48 <DorpsGek> SVN: truebrain (r265) -Add: name most functions in 0F3F, all Tile related
23:00:10 <DorpsGek> SVN: truebrain (r266) -Fix (r265): compile before commit
23:00:20 <TrueBrain> now that is nice progress :)
23:00:35 <TrueBrain> Xaroth: if you want to do something 'easy', 0F3F ;)
23:00:59 <TrueBrain> most functions have their right name, the struct is prepared for it .. just a matter of rewriting, and documentating ;)
23:01:53 <Xaroth> I'll have a shuffle at it tomorrow, see how it all looks like
23:02:16 <glx> it's full of magic math :)
23:02:21 <TrueBrain> it is one of those functions which I put on a todo list for: when bored :p
23:03:12 <glx> hmm mingw gives me some "always true/false"
23:06:43 <Xaroth> TrueBrain: also thinking about making a generic summary of what you posted on fed2k, more in a way of 'i could say it all in here, but i shouldn't advertise for us on these forums, just go to our site instead'
23:06:49 <Xaroth> .. in a more.. pr-like way ofc
23:09:10 <Xaroth> maybe add a hint or two that our code is slowly starting to contain 'useful' information
23:09:28 <TrueBrain> I leave the PR completely up to you :) I suck in that ;)
23:10:36 <TrueBrain> bah .. I remember why I hated those rockets thingies :p
23:10:43 <TrueBrain> they can kill your base without anyone attacking them
23:11:18 <Xaroth> and put the 'interesting-to-attack' buildings, like your repair facility, at the back
23:11:30 <Xaroth> that way they will try to march past your line of defense to get in range
23:11:40 <Xaroth> and as such, get ripped to bits by your defense :P
23:12:23 <Xaroth> I usually try to stick to
23:12:27 <Xaroth> _______ line of turrets
23:12:41 <Xaroth> +++++++ line of silos/windtraps/other useless buildings (radar, CY)
23:13:00 <Xaroth> +++++++ line of their 'to-attack' buildings, heavy factory, air factory, ix, repair facility, starport
23:13:13 <Xaroth> that way for them, to get to the last line, is to stand right next to your turrets
23:13:23 <Xaroth> and they'll be dead before they get there
23:15:59 <TrueBrain> I think it is stupid you have to build in your repair in order for units to get back where they came from
23:16:30 <Xaroth> yeh, they made a 'patch' for that on fed2k tho
23:16:39 <Xaroth> i think it's one of the script files that does that
23:19:56 <TrueBrain> stupid worm ... ate 2 of my units, and refuses to eat his
23:50:57 <TrueBrain> time to go to bed :)
23:51:01 <TrueBrain> nice job today glx :)
continue to next day ⏵