Re: Shutdown/restart
Ralph Corderoy <[EMAIL PROTECTED]> writes: > > The reason I enquire is that both the Mac OS X port and (IIRC) the > > Windows port are multithreaded, with a GUI thread and an emulator > > thread. What I'd like to be able to do is have the GUI perform a hard > > reset of the emulator by having the child emulator thread terminate, > > then I can start a second one. > > That's not a hard reset though, is it? That's a `start a new > emulation'. No, but it's sufficient for what I want - the user has modified their preferences from the GUI and wants the emulator to take the new changes into account. > Given that, I think the current, manual, `quit arcem and start it again' > is the most realistic method the user has; they won't be confused over > what it is and isn't doing. Not on a Mac it isn't. It's totally unacceptable for a Macintosh application to require the user to quit and restart just to make it notice a change in preferences (e.g., you change the ROM file location, or hard disk configuration). This should be achievable from within the application. > I think all the various resources aren't allocated privately to the > thread. What I'm trying to say is they aren't automatically freed when > the thread dies. And there's little code to free the resources since I > guess it was never intended. No, I know that, and hence why my checkin says that I've not finished, it was just a start to test that I could do what I wanted. The next stage is to make sure everything gets freed up properly. Just because the program was poorly designed from a shutdown point of view doesn't mean this shouldn't be done. It should simply be fixed. I know it's a pain, but if ArcEm is to be hosted on multiple platforms it does have to conform to the local standards, and this will require some parts to change to suit a non-(standard-unix) way of doing things, like this and the way preferences are sorted. -- Michael Dales --- email: [EMAIL PROTECTED] --- tel: +44 141 330 6297 Department of Computing Science, University of Glasgow, Glasgow, G12 8QQ --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ arcem-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/arcem-devel
arcem working directory
Hi there, I'd like to suggest a small change to the way ArcEm finds files - made a bit more relevant due to hostfs stuff. Currently the default assumption is that ArcEm looks for files in the current working dir. On Mac OS X and Windows this is a broken assumption, as users will click on an icon. I'd like to suggest that ArcEm looks in a directory specified by a user configuration file. And in the X11 version it just forces the user to cd before they run arcem. Instead we should have the user's specified launch directory as a parameter in the user's config file (e.g., .arcem on unix). Then looking for things like the ROM file, hostfs dir, etc. they can be help there. Any objections? The other thing rjek and I discussed was creating a platform independent wrapper for getting info from config files - on X it would read ~/.arcem, and Mac OS X it would look in ~/Library/ Preferences/arcem.plist and so on. On most OSs this would just be a wrapper for that platform's API for doing such things. For most of what arcem has I imagine a simple key/value string interface should suffice. Any thoughts? -- Michael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: arcem working directory
On 10/31/05, Rob Kendrick <[EMAIL PROTECTED]> wrote: > On Sun, 2005-10-30 at 21:12 -0700, Peter Naulls wrote: > > In message <[EMAIL PROTECTED]> > > Michael Dales <[EMAIL PROTECTED]> wrote: > > > > > Hi there, > > > > > > I'd like to suggest a small change to the way ArcEm finds files - > > > made a bit more relevant due to hostfs stuff. Currently the default > > > assumption is that ArcEm looks for files in the current working dir. > > > On Mac OS X and Windows this is a broken assumption, as users will > > > click on an icon. I'd like to suggest that ArcEm looks in a directory > > > specified by a user configuration file. And in the X11 version it > > > just forces the user to cd before they run arcem. > > > > It's correct under Windows due to the way app launching normally works. > > I don't have any strong views about the matter, but clearly if it's > > going to break things on Mac OS X, it ought to be addressed. > > Certainly, short cuts to executables can also define their default > working directory. > > My stance on this is that from a purity sense, you should store user > configuration and such in the user's profile directory, as they may not > have write permissions to where ArcEm is installed. Certainly I've thus far used macosx specific things in arcem for locations, and I've also hardwired where it looks (~/arcem) but the user might not want it there for asthetic reasons or whatever. And then having defs for every platform becomes a bit mad. I think just abstracting things like this out is a good thing. I need to look at Rob's suggested interface and check it maps reasonably well to Mac OS X's config file handling primatives. -- Michael --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: ArcEm port to GP2X
Perhaps then it's time to fork some stuff then. There's active development in getting ArcEm to support RISC OS better at the moment - I'm not aware of anyone who's using NetBSD putting in a lot of effort. We already have hostfs support in there which is through a module hack (excellent work by those involved). I think getting the Internet module hack in there would be good, and a lot less effort and (one assumes) slow down than trying to emulate a network card. Particularly in getting ArcEm more noticed/immediately usable. I understand the idea of keeping it pure, but then users (at least from the mail I receive for the Mac OS X ArcEm port) want features not purity. I see nothing wrong with adding module based short cuts for RISC OS in ArcEm, these can be conditionally enabled through #defines or such if necessary. It doesn't negate doing a pure emulation of network hardware at some point, but it would seem the easier route given the limited developer resources. Perhaps there even needs to be some kind of fork - a pure version of ArcEm and a RISC OS enhanced version. I appreciate I'm a very minor contributed to the project, but having chatted with flibble and rjek about it (I'll master real life names at some point) this seems to be the obvious immedate path. -- Michael On 2/27/06, Ralph Corderoy <[EMAIL PROTECTED]> wrote: > > Hi Matthew, > > Off-list you wrote: > > I have also been experimenting with implementing networking in a > > couple of different ways: Either emulating a real network card (an > > Ether1 looks promising), or writing a RISC OS module that implements > > DCI4, and passes network packets directly to the Host. I haven't got > > very far with either of these ideas yet, as I have been working on > > other things. > > I'd prefer emulating a real network i/f podule since that would support > other OS better, e.g. NetBSD. > > http://www.netbsd.org/Ports/acorn26/ > > I think it would be nice for arcem to continue to support Linux/ARM26 > and NetBSD would be nice to add. > > However, I thought in the past that a RISC OS module presenting a DCI4 > interface may be easier and have a copy of > > DCI-4 Functional Specification > Drawing Number: 0284,036/FS > 25 Jul 2000 Issue 4 > > if that's of help. > > Cheers, > > > Ralph. > > > > > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > arcem-devel mailing list > arcem-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/arcem-devel > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: ArcEm port to GP2X
On 2/27/06, Ian Jeffray <[EMAIL PROTECTED]> wrote: > Ralph Corderoy wrote: > > Hi Michael, > > > > > >>Perhaps then it's time to fork some stuff then. > > > > > > Can we avoid top-posting on this list please. > > Can we avoid CCing everyone on everything if we're also > using the list? :-) Interesting issue, as I've missed Ralph's posting my reply :) Not in my spam filter either :/ Perhaps it'll turn up at some point :) > >>Perhaps there even needs to be some kind of fork - a pure version of > >>ArcEm and a RISC OS enhanced version. > > > [snip] > >The only reason for a fork in arcem I can see > > would be a political one, and it would be to the detriment of all. > > I'd agree. Forking is always terribly bad, and especially in this > instance I don't see why it's required at all. > > (Example of terribly bad forking - Nettle vs NettleSSH) Okay, I think Ralph missed my point. I'm not proposing a Mac OS X only fork, but rather a way of handling the difference between "pure" emulation of the hardware and a version of ArcEm that uses module based shims to cut through to functionality embedded in the emulator. All ports should come from the same source tree as they currently do. Not forking is fine, I'm just pointing out though that the active developer base at the moment do not agree with Ralph's original statement that we should stick to pure emulation of hardware. I'm not the most active developer on the project, but in talking to Rob and Peter we all seem to agree that modules that shim onto ArcEm (as done already with hostfs support) is the way forward. I've proposed that we can use configuration options to select whether those are compiled or not, and if people are cool with that then there is no need for a fork. But the issue is a technical one not a political one - there's two wasy of implementing networking (and other things), and we're (I apologise to Rob and Peter if I'm mis-representing their feelings) interested in pursuinghte Module based approach over a full emulation approach. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: ArcEm port to GP2X
Hey there, So chatting to Peter it appears that half the list has been left out on some private discussion as to how and why things are done in ArcEm. So... 1) Ralph: Sorry for arguing about something that was apparently already clear - in that you appear to already be doing the both approach in one tree rather than forcing hardware emulation only approach, which is how I (and I don't think I was alone) interpreted the first post to the list on the matter. Without any context it appeared that rulings were being made from upon high without anyone's consultation. I now see that's not the case, but I only got that from an IRC privmsg, so... 2) Is there a point to this mailing list? If half the developers are going to decide things in private it's hardly surprising that those of us left out get the wrong end of the stick. If you want to declair some people are "core developers" and leave the rest of us out, that's your choice, but be up front about it please. Otherwise can people please use the mailing list to ensure all of us that try and contribute (however infrequently - a dig at me rather than anyone else) understand where things are going. People seem to appreciate the Mac OS X port, and I don't mind doing it, but I'm not going to bother if those developing ArcEm can't be bothered to keep me informed about the project. -- Michael --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
Re: Minimum hardware emulation needed to boot a OS on ARM?
Hi Michael, For my PhD I wrote a different ARM simulator (called SWARM) that was minimal enough to run uLinux - a micro controller linux implementation. It was a few years ago now, but as I recall I needed to emulate very little hardware. Particularly as uLinux does not use virtual memory, so no VMM hardware support was required. I think in addition to the ARM ISA I implemented only a few other thing: 1) A simple interrupt controller based, if I remember correctly, on that of the ARM7TDMI, that other software devices in the simulator could drive. 2) A timer device that could generate interrupts - the OS will need this for things like process scheduling. 3) A simple UART for I/O, though I have to confess that for a lot of things I cheated and had some magic SWIs that would all into the simulator to do I/O You can find SWARM and some documentation here: http://www.cl.cam.ac.uk/~mwd24/phd/swarm.html I don't suggest using it, but it should give you an idea of what the minimum you can get away with is. I suspect it no longer compiles as g ++ has changed quite a bit since 2.95.x :) -- Michael On 11 May 2007, at 15:25, Michael Baer wrote: > Hi Ralph, > > thanks for your answer! I'm really happy to receive such a quick > response. > > Yes, Pearcolator instruments a JVM to perform Dynamic Binary > Translation. For ARM, I translate the ARM instructions into a > stream of Pearcolator's intermediate instruction format and then, > those intermediate instructions are compiled to machine code for > the host platform. Currently, Pearcolator simulates a linux > environment by intercepting system calls and handling these, as if > the binary was running on linux. > > However, I would like to extend that research project so that > Pearcolator can also simulate enough hardware, to actually boot a > simple operating system instead of "only" intercepting the system > calls. Currently, I am simulating all ARM instructions, but no > additional hardware at all. Therefore, I was wondering what kind of > hardware I would actually have to simulate to get a basic linux > running - is simulating a memory mapped serial interface enough or > do I also need a DMA controller, HD controller or ...? > > The reason I was asking here is that you seem to be experts on > simulating hardware, considering arcem is able to emulate quite a > lot. I knew about QEMU, but until know I though they would also > only intercept the system calls - but according to your interesting > links, they also seem to be able to simulate a bit of hardware, too. > > On your homepage, you are also offering an ARMLinux ROM image > (http://arcem.sourceforge.net/linuxrom.zip). Do you know what kind > of hardware emulation is required to run this image? > > Bye, > Michael > > Original-Nachricht > Datum: Fri, 11 May 2007 14:47:05 +0100 > Von: Ralph Corderoy <[EMAIL PROTECTED]> > An: "Michael Baer" <[EMAIL PROTECTED]> > CC: arcem-devel@lists.sourceforge.net > Betreff: Re: Minimum hardware emulation needed to boot a OS on ARM? > >> >> Hi Michael, >> >>> I am a student at the University of Manchester and as part of a >>> project, I am extending the Java Dynamic Binary Translator >>> Pearcolator >>> (pearcolator.sourceforge.net) to support the ARM instruction set. >>> Sorry to start my first posting to your list with a question, but it >>> would be really nice if any of you could give me a hint on the >>> following topic: >>> >>> I am very impressed with the work that you have done on Arcem. >>> Though >>> Pearcolator is not targetted to perform full system emulation, I >>> would >>> really like to look into that topic a little bit. Therefore, I was >>> wondering what the minimal necessary hardware emulation is to run an >>> ARM-based operating system like ARMLinux or RiscOS. I am currently >>> emulating ARM's Angel Debug Monitor SWI commands, but there's >>> probably >>> much more hardware emulation is needed? >> >> RISC OS does need much more, and a lot of it these days isn't >> useful to >> anything but RISC OS. I'd recommend going for Linux/ARM or a BSD >> as I >> believe these require a lot less hardware to be emulated in order >> to get >> a kernel going talking to a "serial" console. >> >>> It would be really nice, if you could give me a hint about where to >>> start emulating software, possibly just to get a console of some >>> kind >>> running? >> >> I don't quite understand what pearcolator is. Is it a framework for >> writing a dynamic binary translator in? And you're using it to >> take ARM >> machine instructions, turn them into JVM instructions, and then run >> them, emulating whatever surrounding system they expect? >> >> Have you looked a Qemu? That may be a better thing to study than >> arcem. >> In particular, see what cut-down minimal OSes they run. Various >> people >> have written about running ARM Linux on Qemu. >> >> http://909ers.apl.was
Re: ArcEm OS X port
Hey there, For reference, I did the original port way back when. I suspect the easier thing to do would be to start the Xcode project afresh. The way the original project was built I suspect wasn't great, as Xcode wanted really to be at the root of the project, but I was directed to ensure all the mac specific stuff was in it's own folder. This made for a slightly contrived setup. Xcode has changed an awful lot in the last ten years, so I'd be tempted to start over Xcode wise, and reimport things. I'd have a look, but I'm pushed for time at the moment. All the best, -- Michael On 27 May 2012, at 10:28, Jerome Vernet wrote: > Le 27/05/12 11:10, Alex Macfarlane Smith a écrit : >> I'd hazard a guess that lines 42-45 are relevant: >> >> 42PDD_Name(x) >> 43- Macro used to convert symbol name 'x' into an >> instance-specific version >> 44of the symbol. e.g. >> 45"#define PDD_Name(x) MyPDD_##x" >> >> May be worth looking at seeing what other builds/platforms define this to >> (and where). I haven't downloaded the arcem source to have a look, that >> was just from browsing CVS on Sourceforge :) >> >> Alex. >> >> > The Makefile found on the CVS do not work either on Mac, so I don't know > wich define are really needed. > I found these one: > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > -DHOSTFS_SUPPORT -DEXTNROM_SUPPORT > > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > -- > arcem-devel mailing list > arcem-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/arcem-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
