IRC logs for #opendune on OFTC at 2009-10-30
⏴ go to previous day
07:30:08 *** boekabart has joined #openDune
08:07:21 <Xaroth> forgot to set topic yesterday :/
08:07:31 *** Xaroth changes topic to "Teaser-2 released || Websites *.opendune.org: www, forum, bugs, wiki, svn || T-2d"
09:03:28 <Xaroth> TrueBrain: deleted some users that never completed registration for over 3 weeks, most likely bots judging by their profile... not banned ips or anything.
10:36:07 <Xaroth> gotta love esx from time to time
10:36:16 <Xaroth> installing 3 nearly-identical servers at the same time
11:08:47 <TrueBrain> virtualization for the win!
11:13:58 <boekabart> i suppose he's not talking about Essex Junction, Vermont
11:14:36 <boekabart> so TrueBrain, how's libemu coming along? I see you already fully support 286 and 386? :)
11:17:43 <TrueBrain> I had some catching up to do :)
11:18:40 <DorpsGek> SVN: [LibEMU] truebrain (r6) -Fix (r5): somehow the rename failed .. who knows why .. who cares why .. it is Subversion!
11:21:06 <TrueBrain> and now I am first going to watch FlashForward :)
12:10:40 <TrueBrain> so then ... music ... now lets get to work :)
12:13:39 <TrueBrain> boekabart: it turns out to be tricky to have all memory access via set_memory ...
12:14:09 <boekabart> my version of current libemu does so
12:14:12 <TrueBrain> well .. should be doable ..
12:14:16 <TrueBrain> boekabart: I am very sure it doesn't ;)
12:14:42 <TrueBrain> you will have &emu_get_memory8 entries as first parameter
12:15:01 <TrueBrain> another example: emu_andb(&emu_get_memory8(..), value);
12:15:33 <TrueBrain> k, fair enough, you did the movsw :)
12:15:37 <TrueBrain> now the emu_andb above ;)
12:15:47 <TrueBrain> I slowly start to remember why I didn't have a set :p
12:16:48 <TrueBrain> the only solution I can think of, makes most of the code very ugly: emu_set_memory8(.., emu_andb(emu_get_memory8(..), value));
12:16:58 <boekabart> indeed it seems that those won't currently work on EGA segment :)
12:16:58 <TrueBrain> and: emu_ax = emu_andb(emu_ax, value);
12:17:17 <boekabart> or emu_getmemoryref8 ?
12:17:26 <TrueBrain> then you still don't see a write to it
12:17:47 <boekabart> anyway the real 286 does a read, and, write, right?
12:17:57 <boekabart> it's just a programmer help that saves the use of a register
12:18:33 <TrueBrain> 'a programmer help'
12:19:13 <boekabart> so what's so bad about decompiling andb( address, value) to *address = *address & value ?
12:19:23 <boekabart> (well with the memset and metget ..)
12:19:24 <TrueBrain> the latter is not possible
12:19:57 <TrueBrain> emu_and needs to set flags
12:20:04 <TrueBrain> so those 2 statements are vastly different in result
12:20:23 <TrueBrain> emu_flags_sfb(*dest);
12:20:24 <TrueBrain> emu_flags_zf (*dest);
12:20:26 <TrueBrain> emu_flags_pf (*dest);
12:20:44 <TrueBrain> in fact, the only command not affecting flags, is mov :)
12:20:57 <boekabart> so decomile andb as such ?
12:21:24 <boekabart> (pass seg + offset, not uint8 *)
12:21:25 <TrueBrain> sorry? You want to publish C code which reads: emu_ax = emu_ax & 0xF; emu_flags.sf = ..; emu_flags.zf = ...; ...
12:21:53 <boekabart> no: andb( ds, dx, 0x85 );
12:22:13 <TrueBrain> either you desynced somewhere completely, or you just don't make sense to me :) Either way, I don't follow :)
12:22:35 <boekabart> wait I don't get andb
12:22:52 <boekabart> not a CPU instruction
12:22:57 <TrueBrain> it is a CPU instruction
12:23:02 <TrueBrain> written in C of course
12:23:39 <boekabart> in asm: and al, 0xf0 ?
12:23:57 <boekabart> ok that has nothing to do with memory so far...
12:24:16 <TrueBrain> in every instruction you can replace a register for a memory entry
12:24:19 <TrueBrain> (well, in almost all)
12:24:34 <boekabart> well decompile as a different emu_and i'd say
12:24:50 <boekabart> one that you pass register *, one that you pass seg, offset ...
12:25:06 <boekabart> ... hm that would go for almost all of them, right ...
12:25:15 <TrueBrain> shitload of work :p
12:25:47 <boekabart> well I don't really see a better option atm...
12:26:08 <TrueBrain> well, emu_ax = emu_andb(emu_ax, 0x0f)
12:26:31 <TrueBrain> and emu_set_memory8(ds, dx, 0, emu_andb(emu_get_memory8(ds, dx, 0), 0x0f))
12:26:34 <boekabart> right... but then you get what you wrote before.
12:26:37 <TrueBrain> but that is not really pretty I am afraid :p
12:26:46 <TrueBrain> emu_set_memory is not pretty in all cases :p
12:26:52 <boekabart> no, emu_andb(ds, dx, x0f) is nicer
12:27:06 <TrueBrain> well, it would need 4 parameters, but okay
12:27:23 <TrueBrain> but moves alone .. emu_set_memory8(ds, dx, 0, emu_bx)
12:27:25 <boekabart> i don't get the 3rd param of _set_memory anyway...
12:27:35 <TrueBrain> it is how 16bit CPUs work :)
12:27:39 <TrueBrain> segment, offset, displacement
12:28:31 <TrueBrain> struct access is like: es:bx+<offset>
12:28:39 <TrueBrain> avoids a silly: add(bx, <offset>)
12:28:51 <boekabart> anyway: especially in stuff like those EGA fancy modes, writes followed by reads don't necessarily result in the same value... because _set does some arithmetic
12:29:08 <TrueBrain> that is the idea yes :)
12:29:28 <boekabart> (and I have no idea how to implement a get :) )
12:29:47 <TrueBrain> but okay ... a LibEMU rewrite causes me to heavily alter ToC
12:29:52 <TrueBrain> that is not so much fun .. as it is a bitch to do
12:32:16 <TrueBrain> btw, LibEMU currently emulates a 8086, not even a 286 :p
12:33:10 <TrueBrain> hmm .. does the opcode: emu_pop(emu_get_memory()) exist ..
12:35:25 <boekabart> indeed... anyway why can't emu_pop rust return a uint16 ?
12:35:50 <TrueBrain> because: emu_ax = emu_pop() is more ugly then emu_pop(&emu_ax);
12:36:14 <TrueBrain> and: emu_set_memory16(es, bx, 0, emu_pop())
12:36:16 <TrueBrain> is completely unreadable
12:36:49 <boekabart> it's not pretty but is it more readable than emu_pop(emu_get_memory()) ?
12:37:07 <TrueBrain> no, the latter is more readable when reading massive amount of such pages
12:37:08 <boekabart> well, the action comes first, at least
12:37:18 <TrueBrain> simple psycology: the first word you read gets the highest accent
12:37:46 <boekabart> how about passing a function pointer in?
12:37:46 <TrueBrain> so reading: emu_pop as first, you know what is going on. Trying to find it between the garble of the rest of the line, not so easy
12:38:06 <TrueBrain> in C you can't give parameters to such function pointer
12:38:18 <TrueBrain> like: emu_andb(&function(es, bx), 0xF)
12:38:29 <boekabart> right.. so then the other option is again the splitting: emu_pop( dx, ds, disp );
12:38:45 <TrueBrain> yup .. which is not really pretty .. (again :p)
12:39:22 <boekabart> OR emu_pop( memory(ds, ds, disp ) )
12:39:59 <boekabart> and 2 implementations of it: uint16* (for regs) and uint32 (for addresses)
12:40:27 <boekabart> reads even nicer than emu_pop( get_memory_16( .... ) )
12:40:33 <TrueBrain> first, overloading is not part of C
12:41:07 <TrueBrain> not as far as I am aware, but I am sure nsz can tell you exactly :)
12:41:21 <TrueBrain> but overloading is a C++ thing as far as I know
12:41:32 <TrueBrain> second, I hate overloading :p
12:41:38 <TrueBrain> but okay, that is easy solvable
12:41:41 <boekabart> ok - so emu_pop and emu_pop_mem ( ... :(
12:41:58 <TrueBrain> rather: emu_pop and emu_popm
12:42:03 <TrueBrain> the latter was long coming anyway :p
12:42:08 <TrueBrain> emu_andb and emu_andbm :p
12:42:11 <boekabart> _ to indicate that m is not part of the opcode
12:42:25 <TrueBrain> it is part of the opcode ;)
12:42:35 <boekabart> the _original_ opcode
12:42:37 <TrueBrain> as much as b vs w vs ws is
12:42:42 <TrueBrain> even the original opcode :)
12:42:54 <boekabart> well I could say the same thing about those
12:43:05 <TrueBrain> /* 0x32 */ { &Node_Asm_Alu::Create }, // Reg1 ^= Reg2/Mem (Byte)
12:43:06 <TrueBrain> /* 0x33 */ { &Node_Asm_Alu::Create }, // Reg1 ^= Reg2/Mem (Word)
12:43:26 <TrueBrain> Reg2/Mem means that the bits following either indicate a Register, or a Memory (which follows in 2 classes)
12:43:32 <TrueBrain> but as you can see, it is very much part of the opcode :)
12:43:38 <boekabart> yeah yeah. the _orignal_ _human-readable_ opcode
12:43:54 <TrueBrain> the [] immediatly says: memory :p
12:44:23 <boekabart> out dx, ax or out dx, al, not outw, outb
12:44:32 <TrueBrain> yup, but not always
12:44:39 <TrueBrain> in that case, it is: out dx, ax and out dx, byte ax
12:45:08 <TrueBrain> assembly has more than often a 'byte' or 'word' indicator .. very annoying, as it could deduce your meaning :p
12:45:24 <boekabart> are they obligatory?
12:45:50 <boekabart> fricking NOISY awacs are practicing touch-and-go's here...
12:46:11 <boekabart> cool to see but so loud
12:47:19 <TrueBrain> k, a simple wrapper emu_memory in cpu_x86_i286, which makes a uint32 flat address out of it .. that sounds like a good idea
12:47:27 <TrueBrain> well, a 20bit address of course, but okay, you get the point
12:47:56 <TrueBrain> I should have said 8086
12:48:23 <TrueBrain> I still wonder how to make it easy to make a i286, i386, ..
12:48:42 <TrueBrain> as big big big portions are shared
12:49:01 <boekabart> it just adds a H file and a C file
12:49:08 <boekabart> and ToC includes them or not
12:49:12 <TrueBrain> #include "../cpu_x86_i286/math.c"
12:49:43 <TrueBrain> no, I really mean the .c :p
12:50:07 <TrueBrain> I guess it will soon become: a cpu_x86_common, and the others including from there what they need
12:52:27 <TrueBrain> what my point is here, in 286 the memory access changed a bit with respect to 8086, that it no longer wraps after 0xFFFFF
12:52:38 <TrueBrain> but it is useless to copy all 8086 code to the 286 dir, and change only that
12:52:46 <TrueBrain> that is only asking for problems like DOSBox is having :)
12:56:51 <TrueBrain> "je bent wel van de werkverschaffing boekabart :p :p :p"
12:57:58 <TrueBrain> emu_core_memory_write16(emu_memory(emu_ss, emu_sp, 0), v1);
12:58:37 <boekabart> emu_memory or 8086_memory( ?
12:58:57 <TrueBrain> well, that is my point of above
12:59:13 <TrueBrain> emu_memory, because now I can in the i286 redefine emu_memory, include math.c, and everything works in i286 mode
12:59:27 <TrueBrain> void emu_popm(uint32 address) {
12:59:29 <TrueBrain> emu_core_memory_write16(address, emu_core_memory_read16(emu_memory(emu_ss, emu_sp, 0)));
12:59:29 <boekabart> that's a bit nasty!
12:59:39 <TrueBrain> well, you have a better suggestion to avoid code duplication?
13:00:18 <TrueBrain> I would really love to hear them, but this is the best solution I can think of without copy/pasting
13:00:20 <boekabart> just don't define it in layer1
13:00:31 <TrueBrain> haha, no, it is inside the CPU module :)
13:00:34 <boekabart> layer1 knows only flat
13:00:59 <TrueBrain> void emu_pop(uint16 *v1) { *v1 = emu_pop_i(); }
13:01:01 <TrueBrain> void emu_popm(uint32 address) { emu_core_memory_write16(address, emu_pop_i());
13:01:12 <TrueBrain> I guess I have to make a lot of _i functions (_i meaning _internal)
13:01:21 <TrueBrain> or maybe call it _emu_pop ..
13:01:31 <boekabart> too bad C doesn't know byref
13:01:33 <Xaroth> _i makes it sound like _integer
13:01:44 <boekabart> emu_pop(emu_al) would be nicer
13:01:53 <TrueBrain> boekabart: lol .. I don't agree with you :)
13:01:59 <TrueBrain> I very much hate byref like that
13:02:03 <TrueBrain> MAGIC things happen :)
13:02:15 <TrueBrain> emu_pop(&emu_ax) <- much more clear what might happen :)
13:02:27 <TrueBrain> but that is personal opinions ;)
13:02:32 <boekabart> you REALLY don't like C++ right?
13:02:41 <TrueBrain> I like C++, just not some parts of it
13:02:44 <TrueBrain> this is one of them
13:02:52 <TrueBrain> overloading another ..
13:03:00 <boekabart> ( I personally prefer C# too, but that might not be the language-of-choice for libemu )
13:03:09 <TrueBrain> euh, no :p But Xaroth would be happy ;)
13:03:30 <Xaroth> but I'm very much aware of the limitations that comes with .net
13:03:35 <boekabart> in 't kader van werkverschaffing: maybe make language plugins in ToC ...
13:04:10 <TrueBrain> I wrote that a few years ago (with igor2)
13:04:39 <TrueBrain> stupid igor2 .. he still hasn't publish the documentation
13:04:45 <TrueBrain> oh well .. I gave up on asking :)
13:04:51 <Xaroth> something tells me igor2 made the site design :P
13:04:57 <TrueBrain> Generic Package Module Interface
13:05:18 <TrueBrain> it has a pluggable system for packages and modules, where you can control all packages via a lot of scripts (and via C/C++, ....)
13:05:33 <TrueBrain> scripts = script languages
13:05:41 <TrueBrain> but don't think that is anything for ToC :p
13:06:34 <TrueBrain> xchg .. another tricky one .. hmm ..
13:06:34 <boekabart> (he NEVER answers back in dutch!!)
13:06:53 <boekabart> lots of options there I guess
13:07:11 <boekabart> m<>reg , reg<>m, m<>m, reg<>reg ?
13:07:22 <TrueBrain> but if I read the opcodes correctly, memory can only be the first parameters
13:07:31 <boekabart> well BOTH of the first 2 seem overkill
13:07:47 <boekabart> so no mem,mem xchg?
13:08:04 <TrueBrain> not in the 80386 instruction set anyway
13:08:12 <TrueBrain> and others are a problem of higher levels :p
13:08:21 <boekabart> excellent. That makes only 2, just like the rest of them
13:08:41 <TrueBrain> well, there are also the 'b' and 'w' variant
13:09:11 <boekabart> but b and w you don't really need for the one with the reg, since you can tell by looking at the param
13:09:24 <TrueBrain> euh .. darling .. how? :)
13:09:50 <TrueBrain> besides, no overloading :)
13:09:56 <boekabart> ah, overloads... gotta lover them
13:09:57 <TrueBrain> (even with overloading you can't do that :p)
13:10:12 <boekabart> wtf? uint8* != uint16*
13:10:17 <TrueBrain> in overloading you can't differ between uint8* and uint16*
13:10:43 <TrueBrain> I believe MSVC was the one bitching about it :)
13:13:32 <TrueBrain> gcc can differ between them too?
13:14:08 <TrueBrain> does running also yield the wanted result? :p
13:14:13 <boekabart> of course I haven't RUN the code :)
13:15:43 <TrueBrain> all I remember last time I tried something like this, some compiler was bitching .. but I am not known for my C++ skills :p
13:16:22 <TrueBrain> well, you need to read a bit between the lines
13:16:30 <TrueBrain> in reality the /86 is always translated to r/m, r
13:16:45 <TrueBrain> (or the other way around, dunno :p)
13:17:09 <TrueBrain> there is not enough room in opcodes to have r/m as first parameter I believe
13:17:37 * boekabart knows next-to-nothing about that
13:17:53 <TrueBrain> I only wonder when it would take 5 clock cycles ...
13:18:17 <TrueBrain> xchg a, b is of course equal to xchg b, a
13:18:24 <TrueBrain> so having both would be very pointless :)
13:18:49 <boekabart> i'll take more cycles in libemu anyway
13:19:07 <TrueBrain> inr eturn the CPU is much faster :p
13:20:46 <TrueBrain> hmm .. I believe I removed all the signed versions in ToC by doing that in a slightly more clever way ..
13:21:57 <TrueBrain> not 100% sure I did all cases ..
13:22:07 <boekabart> TrueBrain: You understand I'll be recompiling Digger, after change, in order to run in on my 10 mhz 8088!
13:22:24 <TrueBrain> good luck; I doubt it will run :p
13:22:33 <boekabart> run or be playable?
13:22:46 <TrueBrain> you would need to port it to DOS :p
13:23:34 <boekabart> I have NO idea how to compile C to real mode anyway, Turbo C 1 or so?
13:23:48 <TrueBrain> I also have no clue :)
13:23:57 <boekabart> wasn't Rb doing that, trying to make a DOS port of ottd?
13:24:10 <TrueBrain> yes, via Allegro and DJGPP I believe
13:24:13 <TrueBrain> the latter takes care of most shit
13:24:33 <boekabart> "for Intel 80386 (and higher) PCs running DOS"
13:24:55 <boekabart> so.. real mode is really dead?
13:25:53 <boekabart> the HW emu layer for it is quite easy :)
13:26:16 <boekabart> asm { out emu_dx, emu_al } ;)
13:27:35 <boekabart> Microsoft Visual C++ 1.52 ...
13:29:36 <boekabart> openwatcom can do it
13:31:10 * glx checked out new libemu :)
13:50:25 <TrueBrain> 2 files done .. ALU file left ... one big ass file .. grr ..
13:54:12 <TrueBrain> something like that?
13:56:00 <boekabart> that's instead of _i ?
13:56:48 <boekabart> re 'static' : isn't it so, that one might want to inline shit like this at some point?
13:56:59 <boekabart> or are you depending on link-time codegen?
13:57:01 <TrueBrain> any sane compiler will
13:57:24 <boekabart> this will be C or H?
13:57:26 <TrueBrain> in my experience, a compiler mostly knows best what to inline and what not :)
13:57:49 <TrueBrain> euh, this is the content of the .c files of course
13:57:58 <TrueBrain> emu_add should never be inlined
13:58:06 <TrueBrain> (and will, most likely :p)
13:58:15 <TrueBrain> because it is a library
13:58:29 <boekabart> that's my Q, if that's desirable...
13:58:52 <TrueBrain> ah; no, it is both not desirable (makes developing much harder, it makes compiling much slower), and the netto gain is almost nothing
13:58:56 <boekabart> choose a target,and includes its ALU h file ... but LTCG will solve it anyway
13:58:59 <TrueBrain> in return, the binary size explodes
13:59:25 <boekabart> but, re the patch, you have my blessing :)
14:00:14 <TrueBrain> pff .. a hell to do all alus ..
14:00:16 <TrueBrain> there are so many :(
14:03:04 <boekabart> LOL! when building for 16 bit dos, assert_compile(sizeof(uint32) == 4); fails!!
14:03:17 <TrueBrain> aren't you happy we have those asserts? :)
14:04:09 <boekabart> E1118 ***FATAL*** segment too large
14:04:31 <boekabart> well, it CAME from 1 segment ...
14:05:01 <boekabart> but q is ...problem is here, that 1 fn cannot be so big? or, that 1 code file cant....
14:05:23 <TrueBrain> I think that the fact we make a memory segment of 1M is the part that is too big :p
14:06:13 <boekabart> in fact: what 'part' of the memory is used by smth like digger?
14:06:22 <boekabart> where do you load the .com in ToC ?
14:06:31 <TrueBrain> euh .. I believe at 0x1E7
14:06:44 <boekabart> is that what came into your head?
14:06:50 <boekabart> when you had to choose?
14:06:57 <TrueBrain> nope, it is what DOSBox showed when loaded in DEBUG
14:07:04 <TrueBrain> and in the beginning I compared DOSBox output with my output
14:07:09 <TrueBrain> to iron out a few nasty bugs
14:07:37 <glx> doesn't link with mingw :)
14:07:55 <TrueBrain> why am I not suprised? :)
14:07:55 <boekabart> you 'd think that 0070:: would be OK
14:08:32 <TrueBrain> boekabart: nope, the interrupts are at 70
14:08:40 <TrueBrain> I put them there, but okay
14:08:48 <TrueBrain> I believe the first free spot is around 0x100
14:08:54 <TrueBrain> glx: like which one?
14:09:13 <boekabart> why don't you put the interrupts where they belong, at 0?
14:09:18 <glx> the 3 functions called in glue.c
14:09:23 <TrueBrain> boekabart: there is the IVT
14:09:26 <TrueBrain> there is a difference
14:09:42 <boekabart> so what are interrupts in this case?
14:09:58 <boekabart> "70:00 I/O drivers from IO.SYS/IBMBIO.COM "
14:10:14 <TrueBrain> you can move it to the far end, I don't care (FFF0 or something)
14:10:22 <TrueBrain> but 70 was the first freesegment I could find at that time
14:10:30 <TrueBrain> and the IVT needs to point to 16bit memory
14:10:34 <boekabart> yeah, 70 IS the first non-reserved area
14:10:44 <TrueBrain> and at those locations is a syscall
14:10:44 <glx> missing emu_ prefix I guess
14:11:05 <TrueBrain> glx: possible .. I thought I fixed that, but okay .. on linux it doesn't complain, as you can have missing references (kind of annoying :p)
14:13:41 <boekabart> ah i see, called from makefile
14:14:38 <boekabart> me or glx should write a msbuild script...
14:14:48 <TrueBrain> it will all change anyway
14:14:52 <TrueBrain> so don't bother right now
14:14:55 <glx> boekabart: I'll do (with the project files
14:15:17 <glx> but I think it's too early
14:15:18 <TrueBrain> I need to find a nice method to avoid 2 CPUs in a single shared library
14:15:33 <boekabart> manually edit makefile :)
14:15:42 <TrueBrain> well, I have a few ideas about it
14:15:46 <TrueBrain> but I first need something to test it on
14:15:54 <boekabart> What, you don't want to support multiprocessor!?
14:16:05 <TrueBrain> no, that is why I use the word: avoid
14:16:16 <boekabart> he doesn't get it :)
14:16:36 <boekabart> "(copie de travail)"
14:17:35 <boekabart> So TrueBrain, you see CGA, EGA and VGA as (dependent/stacked) separate modules?
14:17:36 <DorpsGek> SVN: [LibEMU] truebrain (r7) -Fix: forgot emu_ prefix in glue generation (patch by glx)
14:17:43 <TrueBrain> they should be stackable I guess
14:17:52 <TrueBrain> but only for certain CPU types
14:17:56 <boekabart> but, 1 module just for video
14:18:10 <boekabart> CGA is not x86 specific i'd say
14:18:28 <TrueBrain> take NES, it doesn't read at b800
14:18:48 <boekabart> right, but still it's more platform than CPU
14:19:01 <TrueBrain> yeah, CPU is not the word, but that is all we have to go on I guess
14:19:04 <boekabart> so-build or final app has to pick the right pieces together
14:19:15 <glx> it's an expansion card plugged at a certain address ;)
14:19:16 <TrueBrain> yup; but there should be some validation I guess
14:19:24 <boekabart> PowerPC exists with VGA i'm sure
14:19:30 <TrueBrain> anyway, I don't know if splitting EGA and VGA is a good idea
14:19:41 <boekabart> no, that's not what I was getting at
14:20:11 <TrueBrain> it only works if you can make a common library which they all use, and then plug on it ..but I doubt it has any real use
14:20:22 <TrueBrain> the only reason I want to split CPUs, is because it does matter for the application
14:20:36 <TrueBrain> well, I guess games can also care if there is a EGA or CGA adapter ..
14:20:53 <boekabart> for CGA it's tinily different; for example, EGA and VGA board don't allow mode-switching by writing the CGA mode register, that's why digger.com doesn't work on EGA/VGA boards (even dosbox must be put in CGA mode in order for it to work)
14:21:17 <boekabart> still could be a switch
14:22:00 <TrueBrain> not sure .. depends .. if it can be made in different modules without code dupliation, that is always better
14:22:22 <boekabart> but at least, the module will have it's own video memory?
14:22:43 <TrueBrain> all plane-modes have to, yes
14:23:08 <boekabart> well full VGA emu also; vga has 256 KB and A000->BFFF is 128
14:23:21 <TrueBrain> current full VGA doesn't
14:23:44 <boekabart> but it doesn't support pageflipping
14:23:53 <TrueBrain> yup; but I don't see why we talk about this
14:23:54 <boekabart> because dune2 doesn't
14:24:36 <boekabart> I think the DOS memory module should have 640k ram, and video it's own ram.
14:25:10 <TrueBrain> no, cpu_i286 reserved 1M of memory
14:25:16 <TrueBrain> and the video overrides parts of it
14:25:48 <glx> the well known memory hole in bios config ;)
14:25:50 <boekabart> but all memory above 0xa000 is either video ram (mapped by video adapter) or ROM or non-existent
14:26:22 <TrueBrain> boekabart: even so, it really doesn't matter :)
14:27:03 <boekabart> says mr. I-have-tons-of-ram-in-my-machine-I-can-spare-the-384k
14:27:20 <TrueBrain> well, then we don't reserve the 384k
14:27:26 <TrueBrain> I really don't care .. why am I wasting my time on this :(
14:27:43 <boekabart> wait a tick: cpu sets memory space to 1M ; but that doesn't alloc 1m of ram yet
14:27:54 <TrueBrain> now he catches on :p
14:28:06 <TrueBrain> boekabart: how about I just finish this first draft, and we talk then?
14:28:21 * boekabart wanted to start on implementing vga
14:28:31 <TrueBrain> you first need something to test it on :)
14:28:43 <boekabart> trust me, I can write in the dark
14:28:53 <TrueBrain> yeah .. but we first need to make sure this framework can and will work :)
14:29:09 <boekabart> that's what we need the VGA for :) how else can you tell :P
14:29:32 <TrueBrain> pff ... 'or' done ..
14:29:37 <TrueBrain> took me an hour already
14:29:48 <boekabart> because you keep getting distracted
14:30:00 <TrueBrain> yeah ... and who is doing that? :p
14:30:09 * boekabart is playing annoying customer
14:30:35 <boekabart> you never can tell with customers, can you?
14:32:17 <glx> TrueBrain: feature request for WT3: first, prev, next, last for search result edition :)
14:32:43 <TrueBrain> huh? You can already go to prev and next, not?
14:32:48 <TrueBrain> oh, you mean in the edit mode?
14:33:05 <TrueBrain> can someone confirm for me: NEG opcode for 80386, what is going in the 'of' flag
14:33:56 <glx> I mean I do a search and I'd like edit mode for this subset
14:34:07 <TrueBrain> glx: see the wish-list at bugs.openttd.org ;) It is on it :)
14:35:20 <boekabart> TrueBrain: 80386? YAGNI?
14:35:36 <TrueBrain> I rather play scrabble
14:40:29 <Xaroth> Nyer still doesn't get it...
14:40:43 <TrueBrain> Xaroth: like he ever wills :)
14:41:02 <TrueBrain> but it was nice to read that even MrFribble finds him annoying
14:41:03 <Xaroth> and I think provy also missed out a vital step :P
14:41:46 <Xaroth> adding scale2 and lot while we're not going to 'modify' dune2 until conversion is done :P
14:41:56 <TrueBrain> we already scale up :p
14:42:07 <Xaroth> would be funny to see tho, dune2 in 1600x1200...
14:42:26 <TrueBrain> boekabart: I really wonder why you can tell me I am not going to need to of flag for NEG ... but okay :)
14:43:07 <boekabart> well I thought for a second that NEG was a 80386 instruction
14:43:14 <boekabart> since you mentioned it so explicitly
14:43:24 <boekabart> or rather, that it behaved differently on 386
14:43:39 <TrueBrain> nope; I only need to know the filling for of flag
14:43:41 <boekabart> but, in general "The overflow flag is set when the Most Signfigant Bit (MSB) is set or cleared."
14:43:53 <TrueBrain> yeah, very useful, tnx :p
14:44:05 <TrueBrain> next time I won't ask a specific question, so you can answer with the general answer :p
14:44:07 <boekabart> well since there is no specific documentation
14:44:28 <boekabart> for behaviour of OF for NEG, and it IS affected in a _defined_ matter, must be this
14:44:30 <TrueBrain> maybe .. just maybe .. there is something weird going on in this case, and I need someone to confirm it, without me telling what is weird, as that would defeat the idea of a double-validation ;)
14:45:01 <boekabart> all the NEG specs I can find, refer to a 'default' behaviour
14:46:03 <boekabart> ( but I could also understands if one expects that it only is set when trying to NEG -128 or -32768 ...)
14:46:36 <TrueBrain> well, if any of you have the time, please validate the behavior via DOSBox or something
14:50:34 <TrueBrain> I will tell you the conflict: normal documentation says you have to set OF when the resulting value overflows (so negative value). Now for NEG I read that it is set if the ORIGINAL value was a negative value
14:50:52 <boekabart> so only if the SMB was reset
14:50:53 <TrueBrain> or more exact: if the original value was 0x8000
14:51:01 <TrueBrain> not even negative .. exactly that value
14:51:27 <TrueBrain> which makes totally no sense to me .. so I need it validated outside of the regular crappy documentation :)
14:51:36 <boekabart> THAT actually makes a lot of sens
14:51:47 <boekabart> since -0x8000 = 0x10000 => overflow
14:52:14 <boekabart> 0x8000 would be 0x8000 also
14:52:31 <boekabart> cant be (stuttering)
14:52:42 <boekabart> so I guess it goes to 0x0000 with overflow set
14:52:47 <TrueBrain> and that is why I didn't want you to tell what was the problem, as now we are to speculating instead of confirming :)
14:56:14 <boekabart> give me the test cases you want
14:56:34 <TrueBrain> no, I need to know how to calculat eit :p I don't have test cases :)
14:57:29 <TrueBrain> move the 'e' to 'calculat'
14:58:46 <boekabart> 8000 SET 0F000 CLEAR 7FFF CLEAR 0000 CLEAR 1000 CLEAR
15:00:11 <boekabart> gotta go for 20 min
15:01:35 <TrueBrain> whoho, math.c compiles
15:05:34 <TrueBrain> k, last step, 'call.c' ... which is a pain in the ass ..
15:14:13 <DorpsGek> SVN: [LibEMU] truebrain (r8) -Fix: also remove glue.o at 'make clean'
15:14:44 <DorpsGek> SVN: [LibEMU] truebrain (r9) -Add: first version of x86/i286
15:20:13 <DorpsGek> SVN: [LibEMU] truebrain (r10) -Fix: missing newline (weird ..)
15:31:43 <TrueBrain> it misses all declares of registers, yes :)
15:32:12 <DorpsGek> SVN: [LibEMU] truebrain (r11) -Add: declare all registers and flags in x86/i286
15:39:10 <TrueBrain> okay .. what next .. hmm ..
15:40:34 <TrueBrain> this is becoming tricky ...
16:01:49 <Xaroth> Can it make me tea? :o
16:02:09 <TrueBrain> I just asked, but it laughed at me :(
16:02:27 <Xaroth> then going out for dinner
16:05:31 <TrueBrain> owh, look, a smatz!
16:05:51 <SmatZ> for a long time I thought \o/ means lol
16:06:05 <TrueBrain> no, a person putting up his hands
16:06:08 <TrueBrain> only insane people use it
16:06:32 <SmatZ> I was wondering why they are laughing at him
16:12:28 *** boekabart has joined #openDune
16:12:45 <boekabart> traffic these days...
16:13:36 <TrueBrain> I wonder about syscall (the real interrupt call)
16:13:43 <TrueBrain> when I keep that like: emu_syscall(0x21)
16:13:51 <TrueBrain> it is hard to capture .. the x86/i286 needs a handler, registers, blabla
16:14:00 <TrueBrain> so .. what if I make the decompiler output that like: emu_syscall_21
16:14:06 <TrueBrain> or maybe even: emu_int_21
16:14:17 <TrueBrain> that way there can only be 1 handler, that is a downside I guess
16:14:24 <TrueBrain> but nothing has to manage the interrupts
16:14:50 <TrueBrain> (and then I don't mean the IVT, that will still work, this is pure C-side of it)
16:16:25 <DorpsGek> SVN: [LibEMU] truebrain (r12) -Add: add in[bw], out[bw] handlers, and fix mw(s) versions of all instructions
16:16:48 <DorpsGek> SVN: [LibEMU] truebrain (r13) -Add: a temporary module for backwards compatibility with old LibEMU, to make testing a lot easier/faster
16:17:49 <TrueBrain> I just have to fix the syscall, and all the emu_get_memory entries :)
16:18:17 <boekabart> syscall being the x86 syscall/sysenter instruction?
16:19:10 <TrueBrain> syscall being linux like syscall
16:19:23 <TrueBrain> I explained that to you earlier today ...
16:19:34 <TrueBrain> if you call an interrupt, it checks the IVT where to jump
16:19:42 <TrueBrain> it jumps to 0070:<something> in the current case
16:19:48 <TrueBrain> there is code which generates a syscall(interrupt)
16:19:53 <TrueBrain> syscalls are always given to the LibEMU
16:20:03 <TrueBrain> where interrupts can be overriden by the applications
16:21:37 <TrueBrain> that is the problem with interrupts, in the 'real world' it is pure 8086 code .. we don't want that, so somewhere we have to capture the call and bring it to our side
16:21:59 <TrueBrain> like in linux syscall brings you to the kernel :)
16:22:08 <TrueBrain> better explained this time? :)
16:22:23 <boekabart> (also read en.wikipedia)
16:22:56 <TrueBrain> but either way, either we need some module to keep track of all registers interrupts from the libemu layer3, or we just do the trick I sgugested above, and let the compiler handle it :)
16:24:12 <boekabart> what if an app registers an interrupt, basically it puts its own address in IVT, and only its 'fallback' case will jump to libemu syscall, right?
16:24:35 <boekabart> (if it falls back at all)
16:25:13 <boekabart> even if we use decompiled bios / dos code, it will sit in 'emu space' not 'jit' spacve
16:26:20 <TrueBrain> you can always put the BIOS in the memory, and it will be decompiled like any other piece of code
16:26:47 <TrueBrain> the BIOS shit will only use in/out, so that will be no problems then
16:26:53 <TrueBrain> but I would also like the syscalls to work ;)
16:39:12 <TrueBrain> it is very tricky to do the emu_memory stuff in libtoc, without touching all opcodes (which is a pain in the ass to do .. AGAIN)
16:43:46 <TrueBrain> well, first dinner .. maybe I have a good idea after dinner
17:10:24 <boekabart> when is make suppose to call glue.sh?
17:18:05 <boekabart> well it does at some point
17:22:18 <glx> RES := $(shell /bin/sh glue.sh $(MODULES) ) <-- there
17:22:55 <boekabart> ok, so it doesn't matter that it's never actually used (the RES)
17:23:28 <glx> it's just a way to call glue.sh outside a rule :)
17:23:32 <boekabart> it's done (msys) only when callign with WIN32=1
17:24:50 <glx> msys can't compile without WIN32=1 ;)
17:25:21 <boekabart> well this is BEFORE the compilation
17:26:07 <boekabart> somehow i had 0 modules when running it without WIN32=1, and is was OK when running with,,,
17:28:49 <glx> modules depend only on MODULES
17:29:48 <boekabart> that's why i don't get it. nevermind it's ok now
17:46:53 <TrueBrain> okay ... emu_memory problem .. hmm ..
17:47:58 <boekabart> TrueBrain: did my NEG debugging help?
17:48:09 <boekabart> ... as in, confirm what you read?
17:48:16 <TrueBrain> boekabart: a small subset of all possible variations? What do you think? :)
17:48:46 <boekabart> well i think I did get a quite representative set of them
17:48:46 <TrueBrain> I was more looking for a source which tells me it indeed is the only situation
17:48:49 <TrueBrain> or a debug on real hardware :)
17:48:57 <boekabart> i _DID_ a debug on real hardware
17:48:59 <TrueBrain> (where one just runs 65536 entries :p)
17:49:37 <boekabart> ok what instruction can I use to tell me whether OF is set?
17:49:49 <boekabart> (i just looked at the flags)
17:51:45 <TrueBrain> so something like: begin: mov cx, 0; mov ax, cx; neg ax; jo yes; print "no"; jmp next; yes: print "yes"; next: inc cx; jnz cx begin
17:56:04 <boekabart> you want the whole dump from my test?
17:56:42 <boekabart> you want me to run the 32 bit version too?
17:57:18 <TrueBrain> see, that is confirmation ;)
17:57:29 <TrueBrain> sometimes I just have really weird flag-settings
17:57:49 <TrueBrain> I implemented DOSBox for flags, so I could compare things, but sometimes there are things that just feel very weird, and goes against documentation
17:58:44 <TrueBrain> well, I assume you don't run it on a real i286, but okay, we can assume that it stayed the same :p
17:59:31 <boekabart> Sunday I'll get my XT keyboard...then i'll have a real 8088 available
17:59:50 <TrueBrain> for now I still haven't a good way to do the memory stuff ..
18:00:19 <boekabart> and for 32bit, it only returns 80000000 :)
18:00:27 <boekabart> what is the memory problem now?
18:00:48 <TrueBrain> to modify ToC in a simple way to output the right code
18:01:10 <TrueBrain> the more I look at it, the more I feel like rewriting ToC
18:06:38 <boekabart> hm, there are multple occurrences of this, right: mov reg, reg; mov mem, reg; mov reg, mem ?
18:06:58 <boekabart> what's the naming convention there?
18:07:49 <boekabart> how to differentiate between mem, reg and reg, mem?
18:08:23 <boekabart> maybe if RegMemToCStr also returns an (optional?) 'letter' to suffix to the funtion name ..
18:08:38 <TrueBrain> still means I need to change ALL WriteC
18:08:41 <TrueBrain> which is a pain in the ass
18:08:46 <TrueBrain> there are about 50 of them or so?
18:09:13 <boekabart> (calls to RegMemToCStr)
18:10:13 <TrueBrain> k .. I got something which at least corrects the ALUs in a simple way
18:12:56 <boekabart> hey, ToC can write asm too?
18:13:04 <TrueBrain> assembly is a big word
18:13:06 <TrueBrain> but something of the like
18:22:02 <TrueBrain> emu_si = emu_core_memory_read16(emu_memory(emu_ss, emu_bp, 0x18));
18:22:07 <TrueBrain> not really more readable, but okay .. it has to do for now :p
18:22:50 <boekabart> could define a single define to combine them
18:23:08 <TrueBrain> could/should/would-not-now ;)
18:23:14 <TrueBrain> that is something for a later optimization :)
18:23:38 <boekabart> the whole "emu_core_memory_read16(emu_memory(" is 1 literal in node*.cpp?
18:23:47 <boekabart> or maybe a %s for the 16?
18:23:53 <boekabart> but not more complex?
18:24:24 <TrueBrain> no, it is not one single string
18:24:31 <TrueBrain> things are, as always, much more complex
18:24:37 <TrueBrain> hence my temptation to rewrite
18:27:37 <TrueBrain> emu_ax = emu_core_memory_read16(emu_memory(emu_ds, 0x00, 0x59F));
18:27:38 <TrueBrain> emu_core_memory_write16(emu_memory(emu_ds, emu_bx, 0x497), emu_ax);
18:27:40 <TrueBrain> brr .. unreadable :)
18:28:06 <boekabart> but easy to replace in a 2nd pass or so
18:28:50 <boekabart> that's how I did my set_memory patch (well, using msvc regexp, but similar)
18:29:04 * boekabart is going to check the rest of the family for a bit
18:34:00 <TrueBrain> k, emu_syscall is all that is left in the list of complaints :p
18:36:06 <TrueBrain> [ EMU:L1:Core ] Initializing ...
18:36:07 <TrueBrain> [ EMU:L1:PIC ] Initializing ...
18:36:09 <TrueBrain> [ EMU:L2:x86:i286 ] Initializing ...
18:36:10 <TrueBrain> okay .. that is getting there :)
18:37:10 <DorpsGek> SVN: [LibEMU] truebrain (r14) -Fix: bugs in x86/i286
18:38:07 <TrueBrain> okay ... now the most painful part .. in the old method, there was created a memory.bin which is loaded at startup, which is the whole memory
18:38:48 <TrueBrain> this included IVT, PSP, but okay things the BIOS writes .. I guess that is wrong now, and at startup it should load the executable in the memory, and let the rest load everything how it should
18:39:15 <TrueBrain> and I absolutely don't feel like doing that right now :p
18:40:49 <TrueBrain> k, boekabart, I updated ToC. The code is a bit ugly but okay. the JIT will fail, but okay. The produced code does work with the latest libemu
18:41:07 <TrueBrain> so you now need 2 ToCs, one from before r347, and one after
18:41:25 <TrueBrain> the first gives you the JIT to produce txt files, the other produces decompiled code with which the latest LibEMU can work
18:42:21 <TrueBrain> no real memory is allocated in any way ... nothing is loaded ... that all has to be done :)
18:43:06 <TrueBrain> but I have this weird feeling tomorrow I will start with doing ToC from scratch :p
18:53:45 <DorpsGek> SVN: [LibEMU] truebrain (r15) -Add: layer1/timer, a timer scheduler at 50Hz
18:53:56 <TrueBrain> I hope it works under windows :)
18:59:43 <boekabart> if jit fails, what can i really do with toc?
18:59:59 <TrueBrain> the toc also does the decompiling
19:00:15 <TrueBrain> ./toc --static, remember ;)
19:00:34 <boekabart> so I just hg pull -u, make, ./toc --static ?
19:01:00 <TrueBrain> only for now you won't be able to play any game with the new LibEMU :)
19:01:34 <boekabart> well i'll keep the old ones too
19:01:36 <TrueBrain> I kind of wonder what will be the best approach, about filling the memory
19:02:01 <TrueBrain> if you have the static code .. at startup .. should it load the .exe in the memory
19:02:06 <TrueBrain> or should it already have an image ready?
19:02:20 <TrueBrain> as in the first case, some module has to know about the layout of a .exe in order to load (and relocate) it
19:02:20 <boekabart> that's what it does now, right?
19:02:29 <TrueBrain> now there is an image ready, yes
19:02:37 <TrueBrain> but it includes things from the BIOS, from DOS, from the hardware, ..
19:02:46 <boekabart> this is necessary for the data segments, i suppose, not for the code itself
19:02:58 <TrueBrain> and in case it reaches a point it doesn't know about yet
19:04:28 <TrueBrain> there are some positive things about loading it when you start it (so not via an image), namely that take for example stunts, it loads a small wrapper, which executes DOS EXEC, which loads the real executable
19:04:36 <TrueBrain> that then also follows the same way as the main executable
19:05:53 <boekabart> plus, you don't touch stuff in the reserved areas that might be filled/used by modules
19:06:15 <TrueBrain> a crash.bin will get a whole other layout :p
19:06:28 <TrueBrain> I then no longer can't just dump the memory
19:06:38 <TrueBrain> but I guess every module will receive a Save() and Restore() function
19:06:51 <TrueBrain> which should take care of it
19:07:44 <boekabart> yes since it can also have other state
19:08:19 <TrueBrain> 2 other functions for glue.c to generate :p
19:08:58 <TrueBrain> and then we indeed get that in layer3 there has to be a BIOS module, which has a function defined at FFF0:0, or where was it
19:09:04 <TrueBrain> which starts the loading of everything
19:10:07 <TrueBrain> hmm .. this is getting complicated this way
19:10:45 <boekabart> i have new-style digger
19:11:30 <TrueBrain> don't you just love how it jumps to 0:0? :)
19:12:37 <TrueBrain> so, it is indeed ToC which will need to output a file which indicates which modules are needed for correct working
19:12:50 <TrueBrain> so ToC needs knowledge of LibEMU, but that was coming anyway
19:13:05 <TrueBrain> then it will be a bit like: when an application uses port 3c4, the EGA/VGA module is loaded, ...
19:13:27 <TrueBrain> then in the static version, you have the list of required modules, and that you can compile into your static binary
19:13:28 <boekabart> ok' OR you set this up before starting
19:13:37 <TrueBrain> at starting you have no clue
19:13:53 <TrueBrain> yeah .... not my goal :p
19:14:01 <TrueBrain> I am not going to ask the user to define all modules :p
19:14:05 <boekabart> well you want it automatic, even worse...
19:14:06 <TrueBrain> while most things you can detect
19:14:25 <TrueBrain> maybe you have to select what platform it is in, but the rest is detectable
19:14:37 <TrueBrain> well .. you even have to select the CPU
19:14:55 <TrueBrain> but if you need CLI, CGA or VGA is easy to detect :)
19:14:56 <boekabart> if you don't want to assume 386 es
19:15:13 <TrueBrain> well, I have this test application which detects if it is a 8086, 286 or 386
19:15:18 <TrueBrain> it behaves differently for each
19:15:18 <boekabart> write to 3d8? cga. int10? vga will do fine (even if it uses just cga_
19:15:42 <TrueBrain> int10 is not the level of monitoring we can do ;)
19:15:49 <TrueBrain> layer1 will be the layer which does the detection :)
19:15:52 <boekabart> anyway at first , manual module setup will be fine i suppose
19:16:09 <TrueBrain> yeah, but I am thinking how to tell the system what binary to load at startup
19:16:16 <TrueBrain> there has to be some way in
19:16:18 <TrueBrain> some predefined, even
19:16:37 <TrueBrain> but like ToC now outputs a 'emu_andbm', because it knows that binary needs a x86/i286
19:16:56 <TrueBrain> so you say to ToC: x86/i286, DOS EXECUTABELE, fp.exe
19:17:12 <boekabart> yes, tje whole decompiler is CPU specific obviously
19:17:16 <TrueBrain> then in main() it will write something like: emu_int21_load("fp.exe")
19:17:29 <TrueBrain> or rather: emu_in21_init("fp.exe")
19:17:54 <boekabart> fp.exe _is_ already decompiled, right
19:18:08 <TrueBrain> both cases, doesn't matter
19:18:22 <TrueBrain> both in the case it isn't decompiled yet, as when it is .. in both cases it needs to load fp.exe in the memory
19:18:47 <boekabart> not all segments, necessarily, but ok
19:18:55 <TrueBrain> not all segments? Lol :)
19:19:05 <TrueBrain> it needs to load what the header indicates, yes, but that is always the truth
19:19:28 <boekabart> i was referring to the code parts
19:19:41 <TrueBrain> so? If it comes at a point it doesn't have decompiled code yet
19:19:43 <boekabart> they should, i guess, not be necess. anymore
19:19:44 <TrueBrain> it needs the memroy intact
19:20:02 <TrueBrain> so by the time you are done converting your app to 100% pure C, you can remove it yes ;)
19:20:06 <boekabart> in "final" not realy... but then again, in 'final' there won't be libEMU anymore :)
19:20:08 <TrueBrain> but as long as there is 1 unresolved jump, you need it
19:20:15 <TrueBrain> so that is gibberish
19:20:28 <TrueBrain> either way, what is now in glue.c, will be generated by ToC
19:20:29 <boekabart> no project will ever reach that stadium :D
19:20:42 <TrueBrain> that is what it boils down too
19:20:52 <TrueBrain> all inits will have (), exept one, which tells where the ROM/binary is
19:21:02 <TrueBrain> for NES it will be like: emu_cpu_WHATISIT_init()
19:21:12 <TrueBrain> emu_nes_init("zelda.bin")
19:21:52 <TrueBrain> then at crash, a chain of emu_NNN_save(FILE *fp) is called
19:22:18 <TrueBrain> and via some kind of way .. say .. euh .. yeah, why not: a single parameter, emu_NNN_restore(FILE *fp) is called
19:22:25 <TrueBrain> the latter skipping all emu_NNN_init()
19:22:41 <boekabart> sounds good and doable
19:22:44 <TrueBrain> (so the job of restore() is also to init()
19:22:59 <boekabart> restore(NULL) == init()
19:23:08 <TrueBrain> well, yeah, for example :)
19:23:23 <boekabart> but now I really should go watch a movie or so
19:23:59 <boekabart> tomorrow after I clean the garage, I hope to have time to start on the video module, if you don't mind?
19:24:15 <TrueBrain> yup; you now know the API and requirements, so please do :)
19:24:31 <TrueBrain> please do try to follow the coding style :)
19:24:36 <boekabart> so - we're going to use a 'real (bochs)' bios?
19:24:42 <TrueBrain> and if possible, make a CLI video module too :p (via SDL)
19:25:09 <TrueBrain> so yeah, you can decompile it, also fine by me :p
19:25:10 <boekabart> so video module will do I/O, Memory and INTs
19:25:23 <TrueBrain> INT is done by a layer3
19:25:49 <boekabart> check, indeed: no 'lateral' calling within each layer
19:26:11 <TrueBrain> so maybe I can try to decompile the bochs BIOS, and use that temporary as module :)
19:26:29 <TrueBrain> but I don't want normal applications to get such data :p
19:26:38 <boekabart> i'd start with the VGA bios: better chance of keeping it largely unmodified
19:26:57 <TrueBrain> show your progress often and a lot, and we will see :)
19:27:19 <TrueBrain> (so please, don't go coding for the next 2 weeks, and show in the end a complete working video module, which might completely miss every point ;))
19:27:21 <boekabart> digger is a good testbed; it doesn't call int 10 :)
19:27:33 <TrueBrain> yeah, it is a nice application :)
19:27:48 <TrueBrain> I am going to watch one too :)
19:28:07 <TrueBrain> tomorrow ;) Then I will start with some heavy ToC rewriting :p
19:28:33 <TrueBrain> it will be much more clean ... no JIT (direct LibEMU calls will do just fine :p) .. no complex static output parser .. no exe loader and handler ..
19:28:45 <TrueBrain> it is going to be much more pretty, and more important: much more flexible :)
19:29:22 <TrueBrain> hmm, yes, I am going to make a layer2/cpu_x86_i286_debug module or something, which does what the JIT does now :p
19:29:26 <TrueBrain> oh well .. bubye :)
21:10:18 <Xaroth> SmatZ: that's why I use o/ :)
21:10:27 <Xaroth> even if you look at it wierdly it'll be 'oi' :P
21:10:45 <Xaroth> right, TrueBrain, so you know as well
21:10:56 <Xaroth> missus/dad decided to give my room a makeover for my beerday
21:11:05 <Xaroth> which means that during next week i'll most likely only be online from work
21:11:33 <Xaroth> on a plus side, bigger desk, so i can place everything where i want now ;)
22:33:17 <TrueBrain> NOOOOOOOOooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
22:33:25 <TrueBrain> and it is not even your birthday
22:57:30 <TrueBrain> I am reading specs of NES, but from what I read a lot of electronic are in roms .. it even takes over a bunch of io ports
23:10:58 <TrueBrain> cool, someone made a full NES debugger :)
23:11:09 <TrueBrain> some people just did so much cool things :)
23:11:39 <TrueBrain> ghehe, in the CPU used on the NES, the 'zero' flag can be set by a move :)
23:11:45 <TrueBrain> (which is not true for 8086)
23:23:08 <TrueBrain> 256x240 .. what kind of res is that :p
continue to next day ⏵