18:09 < Daeken> Pirogoth: so, i had an idea i think you'll like
18:09 <@Pirogoth> Let's hear it.
18:10 < Daeken> been thinking about what you guys were saying about wanting a simpler emulation project than the gamecube
18:10 < Daeken> doing nes, genesis, etc is way too hard, but i missed what'd be easier than anything else for us: x86
18:10 < Daeken> i want to build effectively dosbox on silverlight+ironpython
18:10 <@Pirogoth> o.O x86 is easier?
18:10 <@Pirogoth> Oooh, ok, that might be fun.
18:11 < Daeken> doing 16-bit is... 32-bit adds some complexity, but even that's not very complex
18:11 < Daeken> i've built complete x86 processor emulators before
18:11 < Daeken> it's mainly the hardware emulation that takes work, and doing just enough to run DOS and early versions of windows is easy.
18:11 < Daeken> plus be able to run some games with soundblaster emulation and such, obviously
18:12 < Daeken> anyway, in addition to that, i think we can get MS's permission to distribute ms-dos 5 and some early versions of windows, maybe
even up to 95
18:12 < Daeken> they're looking for silverlight demos, and this would be an awesome demo for them and not cost them a cent.
18:12 <@Pirogoth> o.O Think there is a chance in hell they'd allow that?
18:12 < Daeken> i honestly don't see why not
18:13 < Daeken> wouldn't cost them a thing and it'd be an awesome demo for silverlight, which they're currently pushing hard.
18:13 < Daeken> they want anything that will give them an advantage
18:13 <@Pirogoth> True enough.
18:13 < Daeken> and even if they don't, we can easily ship freedos and a bunch of cool shareware games like doom.
18:14 <@Pirogoth> That's true. Alright, sounds like a plan. Emulating x86, via .NET. Sounds like a cool project.
18:14 < Daeken> word
18:15 < Daeken> another thing i've been thinking about is that trying to go from an idea straight for a flexible emulation platform is...
effectively impossible
18:15 <@Pirogoth> How so?
18:15 < Daeken> i think we need to build this without any concern whatsoever for other platforms, just get it working as well as we can in the
most logically designed way we can, and then once it's working, redo it in a generalized way
18:15 < Daeken> there's just faaaaaaaaar too much to consider to do it all at once
18:16 <@Pirogoth> Fair enough.
18:16 < Daeken> most traditional emulation logic doesn't at all apply here... it's more akin to building a new implementation of a .net
programming language than building an emulator
18:16 <@Pirogoth> And we'll be writing all this through ironpython then?
18:16 < Daeken> so we need to develop a first pass then go from there
18:16 < Daeken> yep
18:16 < Daeken> honestly, i could see us having DOS working in a matter of days. there's so little there
18:16 <@Pirogoth> Alright. I'll start learning x86 on Wednesday (Christmas is on Tuesday, right?)
18:16 < Daeken> correct
18:17 < Daeken> (fcvo working, that is)
18:17 < Daeken> if we can run the first screen of the setup program, i'll be happy.
18:17 <@Pirogoth> I'll get on that immediately then.
18:17 <@Pirogoth> XD
18:18 < Daeken> seriously, though, there's very little to do. get segmented memory access working, write the handlers for the ~100 instructions
involved, write the graphics backend and the keyboard input->interrupt mapper, and write the image loader.
18:18 < Daeken> we can use the bochs or qemu bios, so that cuts out the majority of the work.
18:19 < Daeken> hardest part i see is getting silverlight working, and that's just because i fail miserably at frontend shit... so if you want to
handle that, you're more than welcome to it ;)
18:19 <@Pirogoth> I'd be happy to do that part. I've been planning on diving into silverlight over the vacation anyway.
18:20 < Daeken> cool
18:20 < Daeken> i'm going to cream myself if we can get win2.0 running (i say that rather than 3.0/3.1 or 95, since they're 32-bit)
18:20 < Daeken> that'd be sooo fuckin' cool.
18:21 < Daeken> and once we get an alpha working, we can easily generalize the platform and advance it from there
18:22 < Daeken> one thing i'm really aiming for with this is a complete separation of instruction format from logic
18:24 < Daeken> every instruction on x86 is a combination of the following things: moving data between registers/memory, arithmetic, comparing,
and branching
18:24 <@Pirogoth> Right.
18:24 < Daeken> so rather than writing a handler for every opcode explicitly, you write the code that takes those building blocks and translates
them into codedom objects
18:24 < Daeken> then you can just combine those blocks into opcode handlers
18:25 < Daeken> so take opcode 0x33: XOR Gv,Ev
18:27 < Daeken> Gv means a general register (selected by the reg field of mod r/m) with a size that depends on the operand size attribute, and Ev
means a general register or memory address with size specified by the operand size attribute
18:28 < Daeken> sooo... the Gv,Ev shit is generic -- that gets handled entirely by the instruction decoder... so all we care about is working on
the operands
18:28 < Daeken> assuming our list of opcode handlers is a dictionary, the following would handle it:
18:29 < Daeken> 0x33 : ('Gv,Ev', lambda D, S: BlockMove(D, BlockArithmetic(XOR, D, S))),
18:30 < Daeken> the first element of the tuple gets handed off to the instruction decoder. the decoder figures out what each operand refers to
and returns the appropriate codedom object (representing the register or memory address) and passes them to the function referred
to in the second element of the tuple
18:30 < Daeken> that lambda function calls the building blocks as necessary and returns another codedom object from them
18:31 <@Pirogoth> Sweet
18:31 < Daeken> hehe, it gets even better ;)
18:32 < Daeken> i wrote a script a while back that screenscrapes sandpile.org's x86 documentation ( index at http://sandpile.org/ia32/index.htm ,
but one-byte opcodes are most important right now: http://sandpile.org/ia32/opc_1.htm ) and returns 33 == 'XOR Gv,Ev' for instance
18:32 < Daeken> we can adapt that script to write all of our opcode handlers for us.
18:32 < Daeken> with the exception of a few that we'll need to write by hand
18:32 <@Pirogoth> Awesome
18:33 < Daeken> yep, so that covers the entire instruction execution side of things
18:33 < Daeken> so all we have to do on the CPU is the mmu, context switching, interrupt handling, etc.
18:34 < Daeken> what blows me away is that no one has thought of doing this before, to my knowledge. it seems like everyone in emulation is
content with doing everything in the least reusable way possible
18:35 < Daeken> but i have to wonder if that has a lot to do with the limitations of the tools available
18:35 < Daeken> for instance, doing something like this in C would be a bitch... you could write up a script to generate the C, but it'd still be
a _ton_ more work
18:36 < Daeken> i keep thinking that because no one has done it, there's some fundamental problem with it, but i've talked to a bunch of people
and thought about every portion of this, and i can't find any flaw
18:36 < Daeken> i mean, there are still problems like polymorphic code, but those are problems with every emulator
18:37 < Daeken> it seems like this makes building an emulator as easy as popping together legos to build a castle
18:38 <@Pirogoth> XD
18:39 < Daeken> soo... any questions, ideas (however insane), concerns, etc?
18:40 <@Pirogoth> Nope. Seems to all make sense to me right now. And fairly straight forward actually. o.O I'm sure I'll be pestering you with
questions after Christmas. =P
18:40 < Daeken> k
18:40 < Daeken> and yea, it's remarkably straightforward
18:40 < Daeken> there is one problem i see, though, and that's timing
18:41 <@Pirogoth> Alright, well I have a bunch of things to wrap, and other things that need to be done.
18:41 < Daeken> i dunno how to slow it down XD
18:41 <@Pirogoth> XDDD
18:41 < Daeken> the main loop of the emulator looks like this:
18:41 <@Pirogoth> Timing? Let me think on that. That should be fairly simple.
18:42 < Daeken> do { func = recompile(eip); eip = func(); } while(1);
18:42 < Daeken> that way it can handle branches without having functions calling each other recursively
18:42 < Daeken> so what i'm thinking is maybe put a sleep() in there
18:42 < Daeken> buut... a given function could represent 10 instructions or 10000
18:42 <@Pirogoth> Hrmm. I'll have to think about it a bit later, I gota go do some stuff.
18:42 < Daeken> wait a second, i got it.
18:43 < Daeken> keep track of how many instructions are in a given block and adjust the time accordingly
18:43 < Daeken> duh :/
18:43 <@Pirogoth> =P
18:43 < Daeken> anyway, have fun man, talk to you later
18:43 <@Pirogoth> Will do. ;) Take care.
18:45 < Daeken> you too