+
+
+
+19:58:25 Jan_B_A: Hello Daniel
+19:58:38 danielg4: hello
+20:01:05 cbothamy: hi
+20:02:22 Jan_B_A: Hi Christopher.
+20:06:08 cbothamy: it's 19:10 UTC, maybe we can start
+20:06:25 Jan_B_A: So, am I tonights newbie in this forum? Has you all taken part in similar "meetings" before?
+20:07:21 cbothamy: ok, Jan is here, Daniel also, who else ?
+20:07:42 cbothamy: Jan_B_A: last meeting was logged, see http://bochs.sourceforge.net/irc-20021013.html
+20:10:10 Jan_B_A: Thanks - I am looking at it now.
+20:11:05 Jan_B_A: FYI, I am a newcomer to Bochs. My main interest in Bochs is as a platform for running old MS-DOS and Win9x games. Some of my games run fine in DOSBox (an DOS emulator) but some don't. I hope that Bochs will eventually allow me to run anything.
+20:12:44 Jan_B_A: I have absolutely no knowledge of x86 programming. Assemblywise I am fluent in 6502, and a bit rusty in PDP-11 and 68000.
+20:13:09 Jan_B_A: My webmastering skills are mainly restricted to handcrafting HTML code using Vim (a vi-clone). But what I do not know, I learn!
+20:13:41 danielg4: I'm fluent in 68000 and rusty in x86 and 6502.
+20:14:07 danielg4: never did pdp-11
+20:15:14 Jan_B_A: Daniel, if you are fluent in 68000, you will feel right at home with PDP-11. Addressing modes, op-codes, etc - they are so close that they could be cousins!
+20:16:02 danielg4: that's a bit OT because bochs will be ported to neither
+20:16:40 Jan_B_A: Okay, back on topic then - which is?
+20:16:43 cbothamy: Jan_B_A: Jean-Michel Poure offered to help on the website. I'll tell him to contact you, ok ?
+20:18:10 Jan_B_A: Sure. Any idea what you would like to see happening? Any urgent changes needed? Or do me and Jean-Michel just look it over, and make a internal version for approval by ???
+20:19:42 cbothamy: There is no urgent changes needed. I guess a lot of links are wrong now, and new links could be added.
+20:21:50 Jan_B_A: Okay. I/we will look it over and see what needs to be updated.
+20:21:52 cbothamy: Also the source code used to be viewable on the website. The latest version available is 1.4pre1. Maybe we can remove the feature and link straight to sourceforge
+20:22:51 danielg4: The only source I saw was ViewCVS.
+20:23:01 cbothamy: or add the newer versions.
+20:23:52 cbothamy: url is http://bochs.sourceforge.net/cgi-bin/lxr/source
+20:24:17 cbothamy: Jan_B_A: do you know how to update the website ?
+20:24:38 Jan_B_A: I have just opened up the "Web Site Request" tracker at SourceForge - Whew! I think the first line of action is to review those requests, get them closed or prioritised, and assigned to someone.
+20:25:48 danielg4: I just checked http://bochs.sourceforge.net/cgi-bin/lxr/source. Wow, is it old!
+20:25:50 Jan_B_A: cbothamy: I do not have a clue (yet!). But I am confident that I will figure it out.
+20:27:25 cbothamy: Jan_B_A: absolutely, I'll check if you have admin rights on the tracker items
+20:28:35 cbothamy: Jan_B_A: I'll write a document and send it to you. I'll also update the developer's guide at the same time
+20:29:30 cbothamy: Jan_B_A: I think you have Admin rights
+20:29:40 cbothamy: on the tracker items
+20:30:06 danielg4: I know I do.
+20:30:56 Jan_B_A: Fine.
+20:31:14 danielg4: hello, Frank
+20:31:30 fcorneli: hi
+20:33:13 cbothamy: ok, Bochs 2.1.1 is still not out. I'm waiting for anybody to confirm the floppy dialog works or not on win2k.
+20:33:22 Jan_B_A: One of the items discussed recently was a new/better format for the .bochsrc file. How do you feel about going XML with it? To start with perhaps just a frontent that uses XSL to convert it into the old form?
+20:34:44 danielg4: I don't think that's necessary for the forseeable future.
+20:35:15 cbothamy: Jan_B_A: I'm not sure about XML. It has been discussed once before. I don't see any benefits in using xml for a properties file.
+20:35:38 danielg4: cbothamy: I think Volker made a second patch regarding the floppy browse.
+20:35:56 Jan_B_A: No Win2K license here. I might be able to borrow a CD from a friend, just for testing, but it would be easier if someone with W2K already installed could test it.
+20:36:19 fcorneli: problem is that you'll need a portable xml parser that is available on all supported platforms... is there a good portable xml parser?
+20:37:25 danielg4: Such a parser is likely to be GPL, rather than LGPL.
+20:37:41 Jan_B_A: The Apache project has something. The developers at my work use a lot of that stuff. Xerxes is the name I think.
+20:38:08 fcorneli: yes, there is also the gpl vs lgpl problem...
+20:38:26 cbothamy: gnome has libxml2, that is released under the MIT license
+20:38:45 fcorneli: compatible with lgpl?
+20:42:15 cbothamy: I think so. But I think we a java-properties-like configuration file would be good enough.
+20:42:47 danielg4: I just took a quick look at the Apache license. Doesn't look compatible.
+20:45:03 cbothamy: ok, so you all have read the roadmap document http://marc.theaimsgroup.com/?l=bochs-dev&m=107550424808607&w=2
+20:45:10 fcorneli: XML-izing the config file can wait... but anyway, the config system needs some work... e.g. the main menu is static while it could be generated at run-time...
+20:47:31 danielg4: I'd have to reread the LGPL.
+20:47:44 fcorneli: Chris, how about letting the file ROADMAP live in the Bochs CVS tree? Would be a good guide for developers...
+20:48:38 cbothamy: that's a good idea. What we could also do is use the tasks system of source forge.
+20:49:04 danielg4: They're not mutually exclusive.
+20:50:49 cbothamy: fcorneli: "main menu is static" that's the menu when you press the "config" button ?
+20:50:57 fcorneli: yes...
+20:51:25 fcorneli: the main menu text lives somewhere in a file... while it should be generated at run-time by iterating the main menu objects
+20:51:45 fcorneli: AFAIK currently this is not the case...
+20:52:32 danielg4: That would certainly solve the problems with hot-swapping virtual drives.
+20:52:47 fcorneli: This stopped me from adding an extra menu for my pcidev...
+20:52:58 cbothamy: ok, I'll add a paragraph in the roadmap about config files and dynamic config menu
+20:54:23 fcorneli: yes, the menu menu definitely be generated a run-time so it can be changed at run-time as needed...
+20:56:09 Jan_B_A: As I wrote earlier, I am no big coder, so my efforts wrt. the roadmap will be in the "housekeeping" category. E.g. going through the User Guide, check for a new release of FreeDOS, make a new image, etc, and get the web site/download area updated.
+20:57:39 Jan_B_A: If Cygwin is suitable for compiling Bochs, I might take a stab at extended the 'boot:' option to take a prioritised list of devices to boot from.
+20:58:03 fcorneli: How many people are actually actively developing on Bochs?
+20:58:24 cbothamy: Jan_B_A: this is fine. We definitely need to keep our website and disk images up to date.
+20:58:36 danielg4: Another thing that should be in the ROADMAP is bringing the BIOS into conformance with Ralf Brown's INT list.
+21:00:07 cbothamy: fcorneli: between 5 and 10.
+21:01:56 Jan_B_A: The roadmap also talks about speed.... The DOSBox people seems to plan to add some kind of Just-In-Time compiler to their emulator. Anyone been following that?
+21:02:27 cbothamy: danielg4: this is a huge task. what we usually do is to wait for bug reports stating that a specific functions is missing.
+21:03:36 danielg4: If we continue to do that, the BIOS will grow larger than the max size.
+21:04:05 fcorneli: About that JiT, GNU Lightning could be an option... It's not that good (no peephole optimizations) but at least it's portable.
+21:04:23 cbothamy: danielg4: right, Volker and I think we should rewrite parts in asm to shrink its size.
+21:06:08 danielg4: And at the same time, introduce jump tables with all the Ralf Brown functions as placeholders.
+21:08:06 cbothamy: for jit-compiling there is also qemu. The dynamic compiler module is lgpl. it seems to be working quite well, the can boot win98 with the latest version.
+21:08:44 danielg4: I thought qemu only ran Linux binaries...
+21:09:35 cbothamy: it's got two modes, one without mmu for user mode, and one with a mmu for entire systems
+21:09:48 danielg4: If the JiT compiler module in it is LGPL, I think we should adopt it.
+21:11:24 cbothamy: danielg4: at least we have to give it a look, to check the feasability. Now the problem is who want to do it ?
+21:13:02 cbothamy: I add "jump tables place holders" in the bios section of the roadmap.
+21:14:33 fcorneli: The advantage of having two modes (user mode and full system) for the CPU is that you can binary search for bugs in the instructions in user mode.
+21:15:33 fcorneli: I once developed a 'virtual cpu' that could be detached at run-time, allowing for binary searching of bugs... it would be nice to have the same functionality for the Bochs CPU.
+21:15:34 danielg4: That's how the 68000 works :)
+21:16:57 cbothamy: fcorneli: I'm afraid I don't get it.. How does is work ?
+21:17:22 Jan_B_A: *also confused about the term 'binary search for bugs'*
+21:17:34 fcorneli: Check out: http://www.elis.ugent.be/~fcorneli/downloads/vcpu-README
+21:20:16 Night: hi, all
+21:20:31 cbothamy: hi Stanislav
+21:20:38 Night: I see I too late
+21:21:17 Night: Somebody could post be the log of dicussion ?
+21:21:46 fcorneli: `echo /dev/random` :)
+21:21:58 fcorneli: I mean cat...
+21:23:15 Night: I see I didn't missed anything ? ;)
+21:23:34 danielg4: You did, alittle.
+21:24:21 cbothamy: log is here http://cbothamy.free.fr/projects/bochs/freenode-%23bochs.log
+21:24:39 danielg4: Is that live?
+21:24:53 cbothamy: hi Volker
+21:25:00 fcorneli: Binary searching for bugs in instruction implementations is only possible when you can detach the emulation and let the user space take over.
+21:26:01 fcorneli: Source code available at: http://www.elis.ugent.be/~fcorneli/downloads/vcpu-0.1.1.tar.gz
+21:27:28 vruppert: Hi Christophe. After adding a new feature in the win32 runtime dialog I started testing gaim.
+21:27:43 Night: ok, i am reading the log now
+21:29:35 rO|: made an OS disk image, 2cts only, but maybe you like to offer it though..
+21:30:28 cbothamy: vruppert: do we know if the win2k dialog bug is fixed ?
+21:32:09 vruppert: I don't know. Is someone here using Bochs on Win2k ?
+21:32:24 Night: i am
+21:32:46 Night: I could check, just say that ;)
+21:34:27 Night: cristophe, your log is broken between 19:09 and 19:42 or nobody really did say a word ?
+21:34:43 Jan_B_A: Night: Physical diskettes in Win2K - can you test that too?
+21:35:25 Night: What should be with diskettes ?
+21:35:54 cbothamy: Night: this is local time. 19h00 utc is 20h00 local
+21:36:10 danielg4: Night: It's the timecode that's broken, not the log.
+21:38:01 danielg4: It is now 20:45 UTC
+21:38:44 Night: ok
+21:40:38 cbothamy: ok for Stanislav and Volker, we have been talking about Bochs improvements : website, config files, JIT, updating the bios, and Frank presented his virtual cpu
+21:40:54 Jan_B_A: Sorry - I could be mixing things up - The issue with Win2K is just the dialog for handling diskettes? Not actually reading them. I think I got this mixed up due a message in the Help forum where someone had problems with diskettes in XP.
+21:41:28 danielg4: Jan_B_A: yes
+21:42:47 Jan_B_A: *blush*
+21:42:50 Night: I got CVS version from yesterday. When I clicking Browse button I get "ComDialogExtendedError return 0x3002" error message
+21:43:54 danielg4: vruppert: Does that help?
+21:43:55 Night: with physical diskettes it working fine
+21:44:10 vruppert: Night: That means "illegal filename"
+21:45:05 Night: very informative ;)
+21:45:40 rO|: is there any reason why a normal w95 bootcd shouldn't work in bochs?
+21:47:03 Night: when I starting from empty "path" field it looks working. I have no disket images so I could not check at all
+21:47:53 vruppert: The floppy dialog sends the path stored in the parameter to the file open dialog. It works here if the parameter contains an image filename.
+21:48:12 Night: can you change the "ComDialogExtendedError" message to normal "Illegal filename" ?
+21:48:37 Jan_B_A: rol: No reason. I installed Win95 fine on Bochs 2.1 running on WinXP.
+21:49:08 vruppert: If the path is a raw device it seems to fail. We have to find a workaround for this case.
+21:50:49 rO|: someone trying yesterday on OS X had probs installing a w95 bootcd
+21:51:23 Night: that about APIC and SMP support in 2.1.x ? We already have 3 patches for APIC in "patches" folder.
+21:51:46 Night: Is any of them gets Bochs closer to WinNT SMP boot ?
+21:53:11 vruppert: I have to leave the channel now. Tomorrow I will read the log and try to find a workaround for the win32 floppy dialog problem.
+21:53:29 cbothamy: ok, bye volker, see you around
+21:54:36 cbothamy: Night: Sorry I have not tried any of those patches. I add an item in the roadmap about apic and winnt smp
+21:56:08 danielg4: Linux-smp might be easier to get to run.
+21:58:05 Night: now I am working on FPU code replacement with softfloat lib.
+21:58:23 Night: It looks faster and free of bugs
+21:59:13 cbothamy: right, I've seen your post in the mailing list
+21:59:24 Night: the last problem is transcendential instructions (log, sin/cos/tag, exp and etc). Any ideas how to implement them ?
+21:59:36 wli: power series
+21:59:43 danielg4: cbothamy: That was Scott Duplichan.
+22:00:55 Night: do you think standard C/C++ math.h functions could help ?
+22:01:50 danielg4: Not for transcendental funcs.
+22:02:00 Night: I see no functions with 'long double' parameter ;(
+22:03:12 danielg4: Not all platforms have a long double.
+22:04:22 danielg4: On PowerPC, for example, it's the same as double, but there is also a 'double double.'
+22:08:33 danielg4: The disadvantage to softfloat is that it doesn't use the host's FPU.
+22:09:47 Night: on x86 you could execute an instruction itself and on other platforms you will have a problems with handling of numeric exceptions and etc
+22:10:52 Night: host fpu could not produce you for example "precision" exception and you will miss it. for me accuracy of emulation is the first task.
+22:14:10 danielg4: Perhaps softfloat could be used for transcendental funcs and math.h for arithmetic?
+22:14:49 Night: btw, how about multithreading/multiprocessing in bochs ? I mean if Bochs will be able to run any device and cpu in separate thread ...
+22:16:07 danielg4: I agree. Giving the CPU its own thread sould be the first step. Perhaps an FPU thread next?
+22:16:14 cbothamy: Night: the problem with multithreading is to be portable.
+22:17:00 danielg4: There are standard C funcs for it, AFAIK.
+22:17:34 Night: not more problematic than GUI or devices. I sure there are portable libraries which provide threads/semaphores services
+22:24:51 Jan_B_A: Hello??
+22:25:34 danielg4: I'm going to need to leave pretty soon, but I'll leave the irc client running & read it later.
+22:27:04 danielg4: bye bye
+22:27:16 cbothamy: bye daniel
+22:27:20 fcorneli: bye
+22:27:38 Jan_B_A: If there is nothing else to discuss (the math problems was over my head) I was going to leave too. Will start working on the site asap.
+22:28:14 cbothamy: ok I'll have to go soon as well. What I'm going to do is upload the roadmap in the cvs, and open tasks ans subtasks on sourceforge.
+22:29:02 Night: cristophe, add to the roadmap that we should find some ideas to check correctness of instructions emulation, especially system instructions
+22:29:56 cbothamy: ok
+22:29:58 Night: arithmetic instructions could be validated with simply random testing
+22:31:15 Night: ok, I also leave now ...
+22:31:22 Night: bye
+22:32:03 fcorneli: I'm leaving too, see you all later around, and happy hacking... bye bye
+22:32:28 Jan_B_A: bye bye
+22:32:41 cbothamy: bye Frank. Thanks for being here
+22:33:06 fcorneli: no prob. cul
+
+
+
+
+
+
+
+Last Modified on .
+
+
+
+
+