IRC logs for #opendune on OFTC at 2009-10-28
⏴ go to previous day
00:10:34 *** ChanServ sets mode: +v Xaroth
00:10:34 *** ChanServ sets mode: +v Yexo
07:13:23 *** boekabart has joined #openDune
07:31:13 *** boekabart_ has joined #openDune
07:31:13 *** boekabart is now known as Guest79
07:31:13 *** boekabart_ is now known as boekabart
07:53:06 *** boekabart_ has joined #openDune
07:53:06 *** boekabart is now known as Guest81
07:53:06 *** boekabart_ is now known as boekabart
08:06:12 <boekabart> TrueBrain: Close file using FCB doesn't 'free' the _int21_filemap entry
08:31:15 <Xaroth> I don't think you'll see much of him today, seeing he went to bed straight after sesamestreet last night, being sick and all.
08:46:15 <Xaroth> that sesame part was because he compared me with PeterT...
08:46:21 <Xaroth> and yes, be glad you don't know him.
08:46:38 <boekabart> I've seen him active on the openttd forums
08:46:52 <Xaroth> that's nothing compared to how annoying he is on IRC :P
08:47:16 <boekabart> at first I thought it was peter1138's new nick (he's gone, btw??)
08:47:43 <Xaroth> er, no idea, cba bothering either :P
08:48:05 <Xaroth> he's pissed me off once too often :)
08:48:37 <Xaroth> yes, after that one time people cross a line with me, I never let them get close to any line :)
08:49:24 <boekabart> ok, finished installing the Asrock ION i bought for my father.. REALLY cool little thingy that is!
08:50:20 <boekabart> he has a fullHD tv, but watching lowres videos on his xbox(1) still
08:50:31 <boekabart> so for his 60th b'day we bought him this
08:50:47 <boekabart> plays 720p @ 13% cpu! (CUDA)
08:52:00 <Xaroth> both blu-ray and hd-dvd reader? :o
08:53:39 <Xaroth> that's not an expensive piece of gear either :o
08:53:59 <boekabart> well we got the one with just DVD (he's never going to pay for BR discs anyway)
08:54:28 <boekabart> and its smaller than it looks in the pictures
08:56:58 <Xaroth> I'm tempted to get one of them sata docking stations, saves me having to buy external hard drives constantly
09:54:47 <Xaroth> I'd hoped I could spend some time writing out concepts/ideas for the 'goals' for the project
09:54:59 <Xaroth> terms are plenty, concepts few :/
09:55:57 <Xaroth> then again, it's turning out more as a 'todo' list rather than a goal list :p
10:12:37 <DorpsGek> SVN: truebrain (r431) [LibEMU] -Update: synchronize LibEMU with latest from ToC project
10:16:55 <TrueBrain> what gave it away? :p
10:17:14 <TrueBrain> hmm .. suprisingly :p
10:18:39 <boekabart> TrueBrain: is that the fclose fix?
10:18:49 <TrueBrain> well, fclose was there
10:18:53 <TrueBrain> just not releasing of the pointer :p
10:19:21 <boekabart> I was thinking, re ega
10:19:28 <boekabart> I don't think we need 100% support
10:19:37 <TrueBrain> yesterday I realised I really should start over with all this, and remove the JIT, and do things right :p
10:19:50 <boekabart> since the goal of libemu is to get a recompiled version _in order to convert to real code_ right?
10:20:07 <boekabart> so... change ega code to SDL code after decompilation, and done we are
10:20:11 <TrueBrain> well LibEMU is a bit bigger, but it should support ToC, yes
10:20:35 <TrueBrain> never found a better name :p
10:20:37 <Xaroth> TrueBrain: starting over? O_O
10:20:46 <TrueBrain> Xaroth: not with OpenDUNE, no worries :)
10:20:48 <boekabart> ToC stands for To C ...
10:20:57 <TrueBrain> boekabart: I would love a better name :)
10:21:14 <TrueBrain> Xaroth: well, maybe if it is done, but that would be relative much easier, as in my new idea, every OS can run the decompiler
10:21:22 <boekabart> Well its goal is to 'revive' 'resurrect' maybe you can do smth with that
10:21:50 <Xaroth> TrueBrain: yeh, but will the new decompiler's generated code be similar to what we use now :P
10:22:06 <TrueBrain> only more C, but yes, of course
10:22:07 <Xaroth> it kinda ruins the point if we have to re-convert all the converted stuff
10:22:18 <TrueBrain> the code can only be decompiled in one way
10:22:26 <TrueBrain> itis not that a xor(ax, ax) changes in a or(ax, ax) :p
10:22:43 <TrueBrain> the decompiled code is just a C representation of the bytecode :)
10:23:00 <TrueBrain> but the project now has some design flaws with respect to code that self-modifies
10:26:37 <TrueBrain> also, in a rewrite, we could allow XMS to work, which means allowing sounds to work in Dune2 :p
10:28:59 <Xaroth> btw, I'm making a post on the priv forum for a concept for the suggestion forum/wiki
10:29:24 <boekabart> haha, i can play FP now
10:29:47 <boekabart> some gfx still not OK
10:29:54 <boekabart> but, mainly it works
10:30:16 <TrueBrain> I have been thinking .. if I would to rewrite this .. LibEMU should be split I guess .. 3 ways: the 8086 assembly handlers, the 8086 hardware handlers, and DOS handlers
10:30:48 <Xaroth> osi layers, only different :P
10:30:50 <boekabart> DOS handlers being all BIOS calls (int calls)?
10:31:21 <boekabart> my gut say: all ints
10:31:33 <TrueBrain> no, a lot of INTs are hardware
10:31:41 <TrueBrain> INT10 has nothing to do with DOS
10:31:50 <boekabart> no, they are not. the code is all in the BIOS
10:32:00 <TrueBrain> in fact ... all INTs besides INT21 has nothing to do with DOS :P
10:32:08 <boekabart> some are GENERATED by hardware (like int9) but not handled by it
10:32:21 <boekabart> but there's not much difference between DOS ints, and BIOS ints
10:32:28 <boekabart> and VIDEO-bios ints
10:32:37 <TrueBrain> as I said: DOS only handles INT21
10:32:42 <TrueBrain> (well .. it takes over INT21 :p)
10:32:51 <boekabart> so see DOS as a bios extension
10:32:54 <TrueBrain> DOS is just a TSR, from that point of view :)
10:33:07 <boekabart> just like BIOS in fact
10:33:10 <TrueBrain> but okay, what is your point there?
10:37:38 <TrueBrain> (sorry, I didn't get what you were aiming at :))
10:38:44 *** ChanServ sets mode: +v Yexo_
10:38:51 <TrueBrain> I am wondering if it would be possible to emulate a Windows95 application .. I am guessing that would be slightly impossible ;)
10:40:16 <boekabart> well from a EMU p.o.v., i'd say : emulate hardware (certain memory addresses, inp/outps) in1 'layer'
10:40:16 <boekabart> implement all ints in another one
10:40:16 <boekabart> 1 part implements all inb, outb and memwrite/memreads
10:40:19 <boekabart> 1 part all int(*.*)
10:40:38 <TrueBrain> for sure inb and int can be related
10:40:42 <boekabart> and 1 part all other calls like.. mov stuff
10:40:47 <TrueBrain> but my point of splitting is to allow other things to be emulated
10:40:50 <TrueBrain> your splitting doesn't :)
10:41:02 <TrueBrain> say I want to emulate OS/2
10:41:11 <TrueBrain> in that case, you take away the DOS LibEMU, you put in OS/2 LibEMU, and tada
10:41:21 <TrueBrain> therefor, a seperate piece needs to do the DOS INT21 shit
10:41:22 <boekabart> fine, than split BIOS into BIOS part and DOS part
10:41:39 <boekabart> but in/out and memory writes ...
10:41:48 <boekabart> should be on another level. hardware emu.
10:41:57 <boekabart> and inp.oupt and int are not related:
10:42:08 <TrueBrain> inb 3c4 is much related to int10 :p
10:42:22 <boekabart> the cga/ega/vga bios just translate int10 calls into the right outp's and memwrites
10:42:57 <boekabart> helper fns, just like int21 are all just helper fn's so you don't have to make the hardware calls to the ATA hardware
10:43:11 <TrueBrain> but okay, my idea is the make a low level framework, which allows you to bind on memory pages (read/write trapping), handles IO access, stuff like that
10:43:34 <TrueBrain> then you plug on that other LibEMU parts which take over a portion
10:43:35 <boekabart> that's what I see as the hardware emu
10:43:37 <TrueBrain> one being a 8086 BIOS
10:43:53 <boekabart> but bios doesn't trap I/O and memory access....
10:43:56 <TrueBrain> maybe even split the BIOS part in: video-handler
10:44:19 <boekabart> (hm, I found the full source to an XT/CGA bios online a couple of days ago... )
10:44:59 <TrueBrain> BIOS also has IO handlers, and also needs to know when a piece of memory is accessed (BIOS-page)
10:45:09 <TrueBrain> mostly to avoid polling the memory all the time (which is very expensive)
10:45:30 <boekabart> dosbox also has: 'hardware' (serial, sound, vga, cmos, dma, iohandler, keyboard, joystick, memory)...
10:46:08 <boekabart> 'ints' ( int10, int13 (disk) ...)
10:46:14 <TrueBrain> that is at source level
10:46:20 <TrueBrain> if you check the code you see they are intermangled A LOT
10:46:28 <TrueBrain> INT10 is a redirect to hardware/vga most of the time
10:46:38 <TrueBrain> the IO traps are ALL OVER THE PLACE (to get sick about)
10:46:40 <boekabart> well that's an optimization...
10:46:49 <TrueBrain> 3C4 handling is put in a whole other section for example
10:46:56 <boekabart> of result of a non-complete refactoring of course
10:46:58 <TrueBrain> DOSBox has one of the worst codebase I have seen in a long long time :)
10:47:25 <boekabart> XMS is handled on the same level as BIOS, DOS: as INT handler
10:47:25 <TrueBrain> but okay .. if I do this over, I also want to be able to emulate ATARI, and GBA, and ...
10:47:51 <TrueBrain> DOSBox uses, in some weird way, what I suggest: a framework which handles IO and memory, and things 'plug' over it
10:48:07 <TrueBrain> (you tell via functions which IO you want to monitor, and which memory pages)
10:48:12 <boekabart> but anyway: I see read_p3c4 in the VGA source code
10:48:28 <TrueBrain> yeah, now check 3CE :)
10:48:34 <TrueBrain> totally related, in a whole other section
10:49:30 <TrueBrain> but you also see there exactly what I suggest: it tells DOSBox lower level that it wants to monitor IO 3C4 read access (and write, later on)
10:49:31 <boekabart> _seq vs _gfx because they handle a different logical part of the VGA
10:50:04 <boekabart> but what I get at: the int10 handlers call out on the VGA registers all the time
10:50:35 <TrueBrain> where do I suggest that is not possible? Just as long as there isn't 1 library doing both INT10 and INT21
10:50:46 <TrueBrain> as that defeats the idea of being able to plug in other OSes ;)
10:50:54 <boekabart> but eg how keyboard handling is done now:
10:51:32 <boekabart> there's no nice split between smth emulating the kb hardware, and the int16/int21 calls there
10:52:10 <TrueBrain> LibEMU is a mess, as the only goal was to get it to work ;)
10:52:14 <boekabart> IRL, the BIOS just implements a default int9 handler that fills the kb buffer; and some DOS calls read it
10:53:09 <boekabart> For a nice emu, I think basically we should have this. and *maybe* it's possible to decompile the actual INT handers from BIOS and DOS, so that you really only have to emulate hardware
10:53:13 <TrueBrain> so, more specific suggestion: 1 layer to do only IO and memory mapping, 1 layer which does hardware and IO (per module, VGA, keyboard, file, ...), 1 layer which does things like the BIOS INT 'shortcuts', the DOS INT21, ...
10:53:32 <TrueBrain> that smells like bochs :)
10:53:47 <TrueBrain> much more difficult
10:53:53 <TrueBrain> file access becomes VERY difficult
10:54:03 <TrueBrain> (and hard to make cross-platform)
10:54:22 <TrueBrain> that is why I think it is good to make it in C89, DOS and BIOS interrupts :)
10:54:42 <TrueBrain> but yes, you are right, an application can survive without ever doing a INT call
10:54:59 <boekabart> easier, yes, but harder also because many apps sometimes go around bios and do stuff directly : mainly keyboard stuff, timer stuff and vga stuff
10:55:20 <TrueBrain> well, in the end the goal is to have a library which makes porting to real C easier
10:55:28 <TrueBrain> in the end, OpenDUNE should not depend on LibEMU
10:55:50 <TrueBrain> but I guess you can do both levels here .. make the BIOS INTs real C, and still have the IO stuff in case something falls back on it
10:55:59 <TrueBrain> (which is much harder to make into real C)
10:56:50 <boekabart> maybe a good balance would be: BIOS+VGA hardware emu with decompiled BIOS, rest (int13, int21, xms and the likes) implemented on int-level
10:57:19 <boekabart> but good EGA/CGA support is IMO almost impossible without doing it completely on I/O level
10:57:21 <TrueBrain> but okay, if I would to redesign this, I also want to support things like GBA, just because I can :)
10:58:00 <TrueBrain> btw, you can do parts of VGA on BIOS level, parts in IO .. like VGA 256 colours is easy in the INT :)
10:59:52 <boekabart> what if page-flipping is going to be done?
10:59:55 <TrueBrain> I want to be able to decompile games like Zelda! :p
11:00:22 <boekabart> i don't think you can do wolf3d now
11:00:29 <boekabart> very basic 256c vga is easy, but still apps can do funky stuff by going around int and doing some outbs here and there: and I think design-wise you shouldn't be going to do stuff in the INT layer from the I/O layer
11:00:53 <TrueBrain> Dune2, when a building is destroyed, should shake the screen (by a IO memmove)
11:00:55 <boekabart> do you think you could decompile a bios?
11:00:58 <TrueBrain> it is kind of lacking that now :p
11:01:04 <TrueBrain> I don't know if it is useful
11:01:19 <boekabart> of course it is: you have all the int10 calls implemented for you!
11:01:20 <TrueBrain> but bochs for sure has one, and DOSBox has one partly
11:01:50 <boekabart> you're going to want it decompiled calling your own-style IO and memory calls
11:02:11 <TrueBrain> well, I dunno what language such compiled versions ar ein
11:02:15 <TrueBrain> if it is 8086, there is no problem
11:02:30 <boekabart> well bios always is in real mode, right?
11:02:54 <boekabart> whole deal with EFI is to keep the proc in protected mode from the start
11:03:05 <boekabart> well not the whole deal :)
11:03:14 <TrueBrain> EFI is much more about drivers in the current state :p
11:03:32 <boekabart> bios is 1 big driver
11:03:46 <boekabart> nice calls (ints) to drive hardware isn't that the def. of driver?
11:03:50 <TrueBrain> I like EFI btw, if it catches on, it will make things MUCH easier
11:03:58 <boekabart> but gotta go, Beekse Bergen company-trip!!
11:10:05 <Xaroth> TrueBrain: posted somethign on priv forum
11:10:11 <Xaroth> not sure if you saw it already
11:11:48 <Xaroth> to provide some more 'open-ness' to the public
11:24:41 <TrueBrain> reading the NES specs .. also very basic memory and IO handlers are required to emulate that :)
11:28:23 <TrueBrain> even found enough MSX docs to emulate that :p
12:35:18 <glx> somebody forgot the topic ;)
12:35:57 *** Xaroth changes topic to "Teaser-2 released || Websites *.opendune.org: www, forum, bugs, wiki, svn || T-4d"
13:48:16 <Xaroth> TrueBrain: I think I'll make a mockup for 0.1 on the frontpage, keep it unpublished.. seeing that I'll probably be not on most of nov1
13:48:28 <Xaroth> that way it only needs the proper links, and a push on the publish button
14:02:01 <TrueBrain> can you also play the game with latest trunk a bit? Dunno how much it is done lately :)
14:05:32 <TrueBrain> although I believe I read yesterday that glx finished A5,and as I still haven't seen a crashlog, I think that is a good thing ;)
14:05:52 <glx> right no crashes nor hangs :)
14:06:01 <glx> and I'm currently in A6 :)
14:06:17 <glx> worms were not nice in A5 :)
14:06:30 <TrueBrain> they are never nice :)
14:06:32 <TrueBrain> and good to hear :)
14:06:37 <TrueBrain> well, I am off dancing .. have a good one all
14:06:43 <glx> suddenly they disappeared
14:06:58 <glx> and after some time one reappeared
14:08:34 <Xaroth> they chase enemies then :)
19:43:22 * Xaroth rolls boekabart around :o
19:47:47 <Xaroth> TrueBrain: I'll start from A1 then, see how far I go without crashes
20:21:33 *** ChanServ sets mode: +v Yexo
23:12:40 <TrueBrain> Xaroth: today I am really happy I am at Evo, not at EasyNet :p
23:12:51 <TrueBrain> (we almost went there, but decided Evo would be a better choice on the long term)
continue to next day ⏵