*** Topic for #Bochs: Bochs Pentium Emulator .:. How is the latest release +working on different platforms? .:. Who uses Bochs anyway? .:. Bugs and +features! bochs is cool come here (although I think it just captures the upt to the current point... so +I'll save it again before I close and all will be well. first thing on my list is: how is the Bochs pre-release working for +people? no comment. anybody tried it? I haven't done a lot of testing yet, but so far so good. The RPM +loads flawlessly. Is the prerelease the RPM? Yes. I've loaded it under RH worked fine I heard someone say "I couldn't find bochs because I didn't have +/usr/local/bin in my path" ran the Linux model that was me! some docs will fix that :) Mark - you have SuSE too, right? That problem doesn't show up +there... And shucks.....I'm a hardware guy....and I still figured it out! ;-) haha No, SuSE is my email server at work.... so I haven't tried it there Ah. I use RH for my Linux work Gotcha. I wasn't sure... I was hoping to get some bug reports on 1.2.pre1 to know what needs to +be fixed before 1.2 yes... here's what's already been fixed since 1.2.pre1: - fixed compile problems in gui/nogui.cc, iodev/pci.cc - removed extra paren that broke SHOW_IPS - HALT macro in rombios.c causes a bochs panic (which can be +turned off in .bochsrc) instead of actually halting. - added additional check for null pointer in debugger exit routine - now font/vga.pcf will be installed in the RPM package. Some +systems don't have it. mostly really minor stuff What about Mark's problem? Perhaps a symlink to /usr/bin would be +good. We should put in a fix for the timing. No, it belongs in /usr/local/bin on linux. I would have been happy with finding it in a readme... timing? as in bochs takes 100% cpu? It seems that it is rather bad it installs outside the path of RH +though... and sometimes runs faster than real time. I had an idea on that one. I agree that's important, but I think not for the 1.2 I'm thinking bug fixes only, basically, but let's get the timing fixes +into CVS for the next Well, what is 1.2? Are we calling it a bugfix release of any existing feature +improvements? essentially? right. here's what I was thinking with 1.2.pre1 I thought it was a feature release we had lots of features that only the authors have tried and finally the ability to make RPMS and win32 binaries so I wanted as many people as possible to be able to try the features So I'll ask the question..... but wasn't so sure of stability, so I called it a pre-1.2 release What features? (Where do I find a list?) SMP, for one. CHANGES.txt in the source TAR file I'll paste them in now if you want. bochs-RFB I think is new in 1.2 also. not necessary....I can't run tonight anyway I'll look at the tar file there are some important ones, esp in the area of I/O (log file +output) and what you see on stderr Oh yeah, the code maintenance issues like that one. http://bochs.sourceforge.net/docs-html/changelog.html has the log of +changes too. Ugh, I'd really like to get my pit changes in, but Abigail has had +different ideas... Babies do that. :) I'm there now reading *** smapnipss (rooot@cs6668169-151.austin.rr.com) has joined channel #Bochs so I think 1.2 OFFICIAL should be 1.2.pre1 with a few bug fixes Sounds reasonable. and anything major should go into CVS snapshots and wait for 1.3 or +something Wow, already doing a feature freeze. :) Bochs going big time. :-) here's a stupid question: What kind of release schedule are we expecting here? 1.2 definitely is NOT ready for the big stuff. but, it's an incremental improvement. I should say pretty early on, I have only worked on projects of 2-3 +people before and have not done this kind of thing before, so I'm learning as +I go. so far I must say I'm REALLY impressed here though I'm participating on some much larger projects and they're no where as organized (of course I don't really know how many are participating here!!) I hope to get more people involved in making decisions like when to do +releases, but here's what I was thinking for the 1.2 thing I wanted to get binary releases out as soon as possible since that will allow the most people to try it out, and potentially +bring in more develoeprs first thought was to do binaries of bugfix3 but the I/O improvements +made such a difference that it seemed like a waste of time. Well, with the HALT bugfix in the bios... could we do a binary +release of 1.1.2 also? sure, but what about the stderr cleanup, the .bochsrc cleanup, the I/O +cleanup? What would be the advantage of a 1.1.2 binary release? there's too much that should be backported IMHO to make it worth it It would potentially run when the main problem is that HALT bugfix. ? what would run better in 1.1.2? What if we independently did a release of just the bios? I guess that's really what I'm advocating. anything is possible. we can backport anything we want. given enough time. We had at least a few messages on the list about people getting +HALT messages when things used to run fine. Can't that be stopped in bochsrc? the bug fix to HALT causes errors to be reported correctly, that's +all. from the bios fixes you recently added. *** Signoff: nolu (Read error: Connection timed out) yup, that's the problem. anything that has STOPPED working because of that was always producing +error conditions but they weren't being reported. so fixing the error reporting is causing people to see the errors that +before were silent. Does that make sense? Okay, then what about a bios version that possibly reports but +continues to run after errors occur. right I thought Bryce said the Bochsrc config allowed for this... that's easy enough, although we should eventually fix those errors +instead of ignore them :) of course but once reported, it's a possibly easy workaround. Tim, the HALTs now produce a bochs panic. In 1.2 all panics can be +turned non-fatal by changing the .bochsrc. but I don't trust any code executing after a HALT. So, that would include the ones Greg is referring to, right? Tim, yes Unles you guys are sure that wouldn't make a difference. we should distinguish between the rombios code calling the HALT macro +and a HLT x86 instruction. I agree with that That'd be very nice. I just mean have a version of the bios with HALT defined to be nop. the HALT macro was broken until 1.2.pre1, it did absolutely nothing Which was good from a user perspective, bad from a debugging one. the hlt instruction halts the bochs simulation, no question. doesn't HALT do a hlt? in 1.2.pre1, it does. I've been working on cvs, and here's what it does now: Right, and I'm just saying I don't want to have to disable all +hlts, just the one in HALT. the HALT macro causes bochs to call panic with the line number of the HALT macro (in rombios.c) and then it does NOT call the x86 hlt oh, that's somewhat better. this lets you control what happens through the bochsrc by saying +"panic: action=fatal" or "panic: action=report" do you think that's an ok behavior for a 1.2 release? Not too bad. :) You guys had talked about being able to isolate panic behavior to a +particular unit. well, a particular section of code. right Sorry, work slipping in there. Is that doable from .bochsrc? Todd's I/O code has the capability of having a different action for +each of panic,error,info,debug for each "module" where module is something like "HD", "CPU", "PIT" but there is not yet any .bochsrc syntax to specify this could we define the panics caused by the bios to be a specific +macro? macroXXXXX module I think you mean something like: panic: facility=cdrom, action=fatal panic: facility=bios, action=report ? yup. panic: facility=default, action=fatal although that's a little awkward. yes, needs work but yes, basically that. the I/O functions are all ready to do that, we just need a syntax! any suggestion? PIT: panic=fatal default: panic=fatal what about debug,info, and error though? PIT: panic=fatal, error=report, info=report, debug=ignore HD: debug=ignore sure. that seems good enough it has the added advantage of giving us some direction for +additional "module parameters" I have a feeling it will be better if the thing left of the colon can +be the same for all such statements, but I'm not sure how to make it look ok. It seems to me that the only issue for panics, etc. is the action. hmmmm... well... true but what if you wanted to log HD messages to a different file? panic: action=fatal PIT log: obj=HD, file="hdlog.txt", panic=fatal, error=report, info=report, +debug=ignore it's getting LONG :) but soon the GUI will do this for us. :) yup. just a minute, I like the log idea. hmmmm... what if we viewed these more as commands. so, we could use: log: filename="outfile", panic=fatal, error=report log: obj=PIT, filename="outfile2", panic=report, info=report that's cleaner. we'd have to decide just how to parse different things. so if you have no obj=X then it means the default? is that your point? yup. makes sense no, not just that. and later lines override settings from earlier lines we only have to specify part on a line, right right. ok, that sounds like a good start. filename would apply either only to the module. or even only to the reporting specified on that line. Is there something easy you could do to keep separate runs in separate +files? So that if you wanted to run regression it would be easy (let's continue the .bochsrc syntax on email, so that we can get to +other things too) sure mark, maybe you could put in a %d or something into the filename, and then sprintf some time stamp into the %d that's an idea there are several ways to do it. the calling program could just change the value in .bochsrc between +runs. at any rate, next topic... I had a little survey written up Maybe the GUI interface would be appropriate? oh, go ahead. but given that we have only 5-6 people... let's just take a peek at it but try to get more people to answer it +later on K. it's at http://bochs.sourceforge.net/ircsurvey.html or if it's easier I'll just paste it in let's add any number of possible responses that you can think of, and +maybe we can make this into a web survey instead (or maybe SourceForge +survey) Should I post my response here? sure!! I write bochs as a hobby. I'm more interested in getting it right +than using it. Educator/Student: to see how the computer works However, I'm also interested in getting x86 programs to run on +other OSes. For the first question (What do you use bochs for): Initially to try +out Win32, although now just for the enjoyment of running a PC in my PC. :-) Future Bug fixes: bug 1. Feature Request: feature 8. also to be able to watch the OS working (esp Linux since I can see the +source too) (Mouse problems, and emulation speed respectively) Chip Designer: Inteested in interfacign it to my new design. bad spelling. ;-) mark, are you allowed to say what you're designing? :) Sort of.... i use bochs for os development I'm working on some leading edge 1394 stuff I understand, I'm a chip designer too. wow, me too. I can say. POWER4 but I'm also interested in chipset design, and how that might play in +here I'm feeling out numbered here... I'm just a lowly web designer. We're thinking about SMP chip designs big surprise :) The web rules...;-) We just work! Anyway, long term I'm interestedin how I can use this with new chip +designs prior to tapeout... Interesting. it could certainly be made into a good driver/monitor... Were you one of the guys pushing for a more modular design? yes, driver could get deveoped in Windows. *** Signoff: smapnipss () I usually have some sort of C model for the chip hook it all together and try it out... That would be nice. Would the C code your are writting be able to be +open sourced? haha LOL :-) ;) Laugh Out Loud or Lot's Of Luck you're choice!! *** eks|x (eks@HSE-Montreal-ppp123837.qc.sympatico.ca) has joined channel +#Bochs hi guys :) sorry, I'm just trying to picture the open source chip design... +People have talked about it, but it's hard to see it happening. hi eks Hi eks! Hi eks! :) Not really.... eks: we're just talking about our answers to a little survey at +http://bochs.sourceforge.net/ircsurvey.html I worked in the IP industry before Phoenix bought us... Oh well, I guess bochs needs more speed before it needs IEEE +1394 anyway... people are starting to do open source Verilog depends on how prevalent FPGAs become in configurable consumer +electronics. Or faster platforms to run Bochs on. Anyways, we're getting very sidetracked. yes good point :) so I heard several votes for better mouse support (bug1) Definately. what I would really appreciate is having the fpu more closely related +to the debugger, aka fpu stack on cpu_dump ah, I never thought about that. Is your 'Disk Image Tools' about how to build HDs with certain OS's +and apps? bug1, bug4 eks, that should not be hard to manage. Bochs must have the values in +there somewhere, you just need printed out right? bug3 sounds like a nice one to fix too... yes, bug3 is tough though well maybe not tough, just lots of OSes out there. feature7, feature2 bryce: right Yeah, at least it would be nice on Win9x. for the cdrom support, what if we made a portable way to read from a +cdrom disk image? yes, but if we get the CDROM model right, we're done. bryce: we have some 3D computing code we try to work out in a gaming +station, we worked out out own fpu stack out code, but it would be kinda neat +to have them out on cpu_dump yakovlev: cdrom model shouldn't be too hard to implement, close to hdd +model Bryce: So that part is under feature 1? not as convenient as the real cdrom (need lots of disk space) but then +the job of reading the raw cd is left to platform-dependent tools that are +already around. that would be good, Bryce. I was surprised that wasn't there already. Would it be possible to make bochs pretend /dev/cdrom was a cdrom +image? I think we just need to understand a few of the ioctls (maybe snatch +from linux kernel code or something) to see how to read table of contents and +stuff well, it would take some looking, but basically, yes. just out of nowhere like that, any of you familiar with 'bfe' ? ;) We'd have to add the removable media controls to the CDROM +interface, but even that isn't ridiculous. eks: can you add that as a feature request on SF? otherwise I promise +I'll forget. :) it's a nice addition to bochs I think bryce: I can do that,sure :) bfe: I looked at it once, and asked the author if he wanted to +integrate it, he's not that interested. yakovlev: Could it do something similar to Win4Lin, where the guest +OS handles how the CD's are mounted? (i.e. automount, standard mount, etc.) could do that for all the physical I/O if you wanted to... well, bochs needs to know if a CD is there or not. bryce: yeah, I know, but it's a good tool, I use it often, mostly to +generate cpu-flow tracing in the history file bfe is actually what started me thinking about guis in the emulated sense. Hmm... Beyond that, it's just a file. yakovlev: one problem I see is changing the actual cd ocne bochs is +started Could it probe the CD-ROM drive every time it is requested? slow Wrong layer, guys. All bochs needs is: How's autmount do it? CDROM_INSERT(). CDROM_EJECT(). the OS interface code figures out when to call them. That'd make sense. yip cdrom would be a big help in installing new software then maybe DISK_SEEK, DISK_READ, and DISK_WRITE to complete the +set. what's the interface look like between the IDE controller and the +HD/CDROM? if I manage to make a larger-scale survey out of this, anything you'd +like to add to it? Does it run ATAPI commands? yes, ATAPI. bryce: perhaps a question on the most important feature of a new GUI? feature10: GUI for configuration and runtime control oh I see like what do you want the gui to do? Right. Answer: everything. Assuming that the GUI could have lots of different things (GUI +debugger, GUI config, etc.) Bryce, I like that answer. should we talk about guis now? Answer: everything. I want to push all the interface as far away +from bochs internals as possible. :) Notice a recurring theme in my messages? :) any of you tried simnow! ? yakolev? layering? ;) I like what Greg said in an email, that we can get separation just by +putting the GUI code and the bochs code into different libraries that are +linked together. Do I have that right? Nope. My impression is that it contains almost an entire +microprocessor worth of simulation data. Sort of. Yeah, I liked that idea too. It doesn't necessarily HAVE to be in a different library, but +that's the idea. Well, actually one should be a normal program that requires the +shared library that contains the other code, right? Also, I used "GUI code" very loosely. right, tim. no reason to require shared library, but that is one way to do it. Tim, I mean. I think that would be best. (not shared library) *** Psyon (exodus@exodus.psyon.org) has joined channel #Bochs Shared library good, but could be compiled separately. hi Don! Im here! Or rather, what I mean, is Greg's idea. I have no preference in how +it's done... I'm just thinking in terms of Perl. :-) What did I miss? HEY Hi Don! it will all be on the web site. hehe ok we're starting to talk about the GUI! well... what am I hearing about Perl? Good that is my dept? we're going reimplement all of bochs in perl. oops Yeah, if it is dynamically linked that would be good. That way the +GUI code could be switched without a recompile. I meant ! Uhh... is that a good idea? :) (that was a joke) oh ok well... You can write perl modules in C cant you? :-) Maybe... it wouldn't require a compilier then. I was told write a bochs perl module that would allow you to run bochs and have events caught by perl Anyways, I used "GUI code" to refer to any thing that interfaces +with the host system. Ahh, but then we have to port perl to MacOS. They have a Mac Perl dont they? Yeah, I think that's a good definition... so anything that could be +considered "client code" right? btw, perl is an easy to write into language, but afaik, it's never as +fast as optimized-compiled C Yeah, basically. greg, how is your model different from what Bochs already does? we have cpu, iodev, and gui all in separate libraries. Not very. iodev is pretty close to CPU. so the new model reflects the Plex86 plugin structure? Is the current GUI library dynamically loaded? so with some makefile tricks we could compile them as shared +libraries. not dynamic, no bryce: feature added on sf (fpu stack dump) eks: thanks uh, I don't know anything about the plex86 plugins, is it based on +shared libraries? That is how Plex86 does the GUI and IO dev stuff now isnt it? Right, but we may want to clean up some of the interfaces a bit. I know the GUI is