Hi, As those who read acorn misc and the 'Archive' list may know, I've recently started experimenting with rpcemu on Linux systems. Overall, I'm very impressed and have been quite successful - so many thanks to all who've developed rpcemu! FWIW I do currently plan to write something for 'Archive' magazine about rpcemu as part of a series on Linux, ROX, etc.
Thus far I've tried using DeskEdit4, TechWriter, Vector, and ArtWorks as 26 bit apps, and this morning tried out a newer 32 bit version of TW that also worked! But there are some points that have puzzled me and where I'd be grateful for advice and help. The main puzzles I have at present are in two areas. One is probably really a RO/RiscPC question but I'm not sure. The other is a baffler for me. First the minor question. I'm now using rpcemu on a laptop running Xubuntu and the machine has a 1366 x768 pixel display. However the largest screen mode I can actually use from those in the default (AKF60 I think) list is 800 by 600. There are larger modes but choosing one with a height of 768 gives a problem. Once the top-bar of the rpcemu window and the size of the Xubuntu top-panel is taken into account a rpcemu screen mode that is 768 pixels high puts the icon bar out of view below the bottom of the laptop screen! I've tried using !MakeModes to create a new monitor defn file that includes 1024 x 700 or similar (1280 x700-ish would be good) but they never work. When I put the file into the list and ask the boot screen to 'try' them I just get a blank rpcemu screen. I've had this problem before in my RiscPC days as I never could produce any screen modes with !MakeModes that actually worked. I am clearly clueless about how to ensure they are correct. So following the premable: Has anyone produced a monitor definition file that works with rpcemu and gives a size around 1024 x 700? i.e. higher than 600 pixels, but somewhat less than 768 pixels? Now the more odd puzzle... I initially tried rpcemu on an ancient laptop that I use for experimental work on the basis that I don't mind if I foul up the machine and have to re-install. This went quite well, and as described above I found that I could get the old 26 bit versions of TechWriter, DeskEdit4, Vector, and ArtWorks to run OK on it. The only oddity was that ArtWorks initially failed saying it could not run "O!RunImage". When I looked the relevant file is actually called "O_RunImage". But when I renamed the file ArtWorks would run and work OK. Having satisfied myself rpcemu was working OK I then installed it on the new laptop. This is faster, etc. (if I launch rpcemu from a terminal it reports a MIPS of 80 compared with 20 on the old machine.) In general, everything works so far just as on the old laptop... with one puzzling exception. ArtWorks doesn't start up correctly. It complains when run that it can't find "PathTool". It puts itself onto the icon bar. But it doesn't have any of the icons on its side-pane for being able to draw or manipulate paths. So is almost useless! On the new laptop I initially installed the liballegro items, etc, using apt-get. Then tried copying across the rpcemu directory from the old laptop wrapped up in a tgz. (Made and opened at each end with the 'Archive' app as I've using ROX.) This behaved as described above. So I then changed the name of the rpcemu directory I'd copied across and used svn to create and install a new one. Same ArtWorks problem. My puzzlement is why - when everything else seems to work the same OK - AW works on the old laptop but not on the new one. The old machine is using crunchband lite (installed from a Linux Format cover disc isoimage). The new laptop is using Xubuntu 9.04. In both cases for normal use I'm starting rpcemu using a ROX app. But when testing I use ,/rpcemu in a terminal so I can see the MIPS value and notice any errors, etc. Has anyone any idea why the new laptop doesn't let AW start up correctly, but the old one does? I'm using the same copy in both cases. All the RO apps were transferred using SparkFS at both ends to put a zip onto a FAT32 USB stick. Having raised my main puzzles I'll also comment on one other matter. FWIW I have BTW read some of the back postings in this group so I know this isn't new, but I'm not sure of the state of play, etc. Rpcemu seems to hog 100 percent of CPU. My new laptop has two CPUs and if I use a system monitor I can see the value jumps to 100 percent on one CPU. It only seems to drop if I get rpcemu to do something! Every 50-60 seconds the demand switches to the other CPU, so the load seems to be shared a bit. I did try the sleep BASIC program which was recommended to me on the newsgroup. But I found that this caused mouse clicks to be missed. I don't recognise the swi called by sleep. But I've been wondering if it would be possible to allow it to catch mouseclicks and pass them back to the WIMP... or something. For obvious reasons it would be better if a RO desktop WIMP that was just cycling around a set of idle polls essentially didn't take much CPU. I noticed one oddity here. That with sleep running the MIPS value seemed to 'bounce' after a mouse click. The effect is that if the mouse has not been clicked for a while then a click will be detected OK by rpcemu. But the MIPS value then varies for 5-10 seconds, and during that time clicks may be ignored. After that time they are picked up again. Can someone explain this behaviour? Is the Linux system reacting in some way? Slainte, Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
