Hello,
I also tried your patch (MacOs 12, QT 5.10, MacBook Pro). It works except that hostfs will not work if I use the default ~/Library/Application Support.

i have to change to another path directly in the sources to make it working.
My Fench keyboard is not that bad mapped. Q is A, and so on, but correctly mapped. More over, with RiscOS 4, you can select a french keyboard, then, everything is at a relativly good place and easy to use, even things like |.
I saw that preferences was not saved with patch 1, so will try patch 2, but as I started my own patchs, need to work a little bit.
I’m trying to add in the prefs panel a way to configure the working directory, so I can have more than one RPCemu directory with differents versions.
Plus I hate to put things in Application Support (as it’s hidden by default).

Your patch doesn’t work woth the current state of the Mercurial repo of RPCemu. They changed a lot of things in the keyboard handling, wich are not compatible with your patch. You should work on it. I tried, unsuccessfull.

Last edited by jvernet on Wed Oct 10, 2018 8:42 pm, edited 1 time in total.

pittdj - I'm working on a fix for those keyboard issues, though it's more complicated than I anticipated. I haven't seen the clock issues myself.

jvernet - I am aware that the patch won't work with the current state of source control - it's for 0.9.0, as stated in the title of this thread and in the file name of the patch. I will redo it when the next release comes out (please don't use the word "should" - it's for me to decide what I do with the patch, and when). It's easier for people to test the patch if they don't have to wrestle with Mercurial, and I would prefer for the time being to work with a code base that's not changing. 0.9.0 is stable, easy for people to download and is known to compile without issue. If this means more work for me in the longer term, so be it.

I don't like things creating random folders in other places (e.g. "Documents"), and I figured that if people are willing to use the command line, they're not scared by "Application Support". On a Mac, settings and support files are stored in the library folder - it's not like Windows where things create folders and copy files into your user directory almost at random.

Does anyone else have any views on where the emulator should store its files? It would be nice one day to have a proper compiled version that people can download as a DMG (that maybe installs into /Applications for you, and also installs the other the other files and folders needed).

Last edited by VincentVega on Thu Oct 11, 2018 4:11 pm, edited 3 times in total.

Sorry for the "should", I'm french, appologize, it may not mind exactly what I want to say. "You may" have been better ? That's what I wanted to say.

I don't like things creating random folders in other places (e.g. "Documents"), and I figured that if people are willing to use the command line, they're not scared by "Application Support". On a Mac, settings and support files are stored in the library folder - it's not like Windows where things create folders and copy files into your user directory almost at random.

Setting and support files the apps manipulate, yes, but not live data that the user need to access from Finder (like hosfs folder). Things like ROM may be loaded from the app and put in roms folder within Library/Applicatoin Folder.
A way to chose wich set of ROM should be a cool option.

Sorry for the "should", I'm french, appologize, it may not mind exactly what I want to say. "You may" have been better ? That's what I wanted to say.

May is a better [sic] choice of word, yes. At this juncture, I'm only supporting people on the version specified in the title of the thread. If you want to use it with a different (non-released) codebase, you're on your own, I'm afraid. As nice as it would be to have a patch for the latest HEAD version, it would mean more work for me checking the patch works whenever the source code changes, and potentially more patch releases.

Setting and support files the apps manipulate, yes, but not live data that the user need to access from Finder (like hosfs folder). Things like ROM may be loaded from the app and put in roms folder within Library/Applicatoin Folder.
A way to chose wich set of ROM should be a cool option.

I think that hostfs should be configurable, yes, but anything else (which you don't need to access as often) should be in Application Support, simply because that's what every other well-behaved Mac application does.

As a workaround for the "hostfs" folder, you can create a symbolic link to whatever folder you want. I'm sure you know how to do that anyway, but here are some instructions for anyone else who would find this useful. Make sure RPCEmu isn't running. In my example, let's assume that the folder I want to share as the root for hostfs is "/Users/XXX/Documents/RPCEmu/hostfs" (where "XXX" is my user name).

1. Using the Finder, go the parent directory of the relevant folder (i.e. "/Users/XXX/Documents/RPCEmu").
2. Right-click on the folder and click on "Make Alias".
3. The Finder will create a symbolic link for you. Its name will consist of the folder name you clicked on, plus " alias" (note leading space).
4. Open another Finder window, at "/Users/XXX/Library/Application Support/RPCEmu".
5. Drag the alias from step 3 to the newly-opened "RPCEmu" folder in "Application Support".
6. In the "RPCEmu" folder in "Application Support", rename the alias to "hostfs".

To check it worked, double-click on the renamed "hostfs" in "Application Support/RPCEmu". It should open the underlying folder, i.e. "/Users/XXX/Documents/RPCEmu/hostfs".

Incidentally (and this is to everyone), thank you all very much for your testing feedback so far. And apologies for the bugs found so far.

Nope, nor the Finder way to make an alias nor the unix way work for me if RPCEMU is in Library/Application Support folder... It does see the roms and config file, but hostfs do not work.
:/
Work if changed to Documents/RPCEMU/ in rpc-machdep.

HostFS works fine for me if it's in "Application Support" (as a proper directory). RPCEmu does log HostFS activity to the standard C error log (stderr). If you right-click on the application (e.g. "RPCEmu-interpreter-debug"), choose "Show Package Contents" (below "Open" on a UK Mac), click on "Contents, then "MacOS" and double-click on the program file in there, it'll open up a Terminal window as well as the usual application window, and if you do HostFS things, you should see them listed.

I have a new release ready for test - version 3. This reworks a lot of the code that interacts with the QT side of things, particularly communication between the main window and the emulator itself. There were some threading issues that Peter found when he looked at version 1 after I'd eventually submitted it, which I hope I've fixed in this version. I've also reorganised the Objective C stuff and split it up to make things easier to maintain.

You can download the patch from here. Build instructions are as before, though change the version number of the patch file accordingly:

This release should hopefully resolve the issue found by pittdj where the keyboard acts strangely when switching from one space back to the space with RPCEmu running.

I have also implemented support for different keyboard layouts, with the beginnings of a French keyboard layout. This is in the "qt5/keyboard_macosx.c" file. I've added some comments to explain how it works. At the moment, the French layout just swaps "Y" and "Z", as I just wanted to make sure the code worked correctly.

There is an additional tweak to HostFS support - previously it would show the hidden special ".DS_Store" directory (the bane of many a network share) in the RISC OS Filer. This will now be hidden, like it is in the Mac Finder.

As ever, any feedback on this version of the patch would be greatly appreciated.

I've just tried V3 of the patch on High Sierra and it seems to be working fine. I haven't done a whole lot of testing other than booting RO 3.71, launching a few of the pre-installed apps and running one small binary copied into the emulator using HostFS, which seems to be working fine. I also tried v2 of the patch last night, which also worked okay for me, hostFS included.

One thing I have noticed is that it uses quite a bit of CPU even when it's not doing anything, 113% according to activity monitor. I'm running rpcemu-recompiler.app.

In anycase, it's really great to have this running so easily on my mac. Thanks for taking the time to make the patch and post the instructions. Much appreciated.

Thanks very much for patch 3. It's GREAT to finally have the emulator suppress those irritating /DS_Store files — that's a surprisingly helpful improvement in its own right!

Regarding the mouse lag that I'm experiencing, I've limited time to really investigate this in detail right now, but I'll certainly delve further as soon as I can. What I can say, though, is:

1. It only happens when I'm running RPCEmu 0.9.0.

2. It actually affects the Mac pointer as well, though to a lesser degree compared with the RISC OS one. I noticed just now that when I opened a menu off the Mac's menu bar, while RPCE 0.9.0 was running, the highlighting of the menu items trailed the movement of the pointer appreciably, and in fact I ended up clicking the wrong menu by accident because of it.

3. The same effect is no exhibited AT ALL by the previous version 0.8.14 of RPCEmu, and if I run both 0.8.14 and 0.9.0 at the same time, the older one is VERY much better than the new in terms of pointer tracking. (Which is a shame because in all other respects, the new version is a big improvement.)

4. Other than using the latest SteerMouse, I'm not aware of running any other Mac software that I'd expect to have any influence on the pointer.

As a matter of interest, what version of Qt are people generally using to build this? I simply downloaded the latest one (5.12.0), which is technically a beta, I think. Would I be better off using an older, more stable version?

Anyway, this iMac is running Sierra, and this is the only machine I've tried using RPCEmu 0.9.0 on so far. My laptop has High Sierra installed, so I'll try that soon, when I get time. And I intend to upgrade one or both of them to Mojave once there's been at least one update (I never install the first version of any new macOS update… – even though Mojave doesn't seem to have any major issues that I've heard about). So I'll see if the problem persists beyond this one machine, at least.

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

There's something I'd like to mention, just as general information about all versions of RPCEmu running on the Mac, which is particularly useful to know given the current lack of support for networking.

As Mac users are aware, the Mac supports alias files – as described in some messages earlier in this thread. They're very useful, and it's a good idea to make an alias to the contents of HostFS so that you can access them easily from the Mac desktop. However, alias files are often seen as files by applications, and are not always followed as though they were folders in situations where you'd want them to be.

What's a little less well known, though, is that the Mac also supports Unix symbolic links. I won't waste time explaining the difference here, but the point is that they're a lot like aliases but much more likely to work as folders in other applications.

This turns out to be particularly useful if you're using RPCEmu on a Mac, especially because of the lack of support for networking. If you have a small home network of machines like I do, you can STILL access your networked files by using symbolic links. For example, I have a NAS device on my network so that I can store all my main work files on it and access them from whichever machine I want to use, and on this NAS unit I have my RISC OS work files. I can access it from either of my Macs or from my Iyonix, so they all have equally easy access to the exact same files. So I have a local boot drive for each RISC OS system (real or emulated), but then the important work files are all on the NAS.

If I were trying to do this via RISC OS's networking features, obviously it wouldn't work… but with symbolic links created on the Mac to point to the root of my RISC OS storage area on the NAS, it works totally invisibly.

The only awkward aspect is that there's no user interface for creating Unix symlinks provided on the Mac, unfortunately, so you either have to fiddle about at the command line or use a third party utility.

For ease, I personally use TinkerTool System 5. It's a very handy general system utility in any case, from a reliable author, and although it's shareware it's a very worthwhile purchase. But there are probably free alternatives to do this job. Anyway, the Files pane of TinkerTool System has a very handy drag-and-drop interface for creating symlinks.

Patch 3 does stop CTRL characters appearing. The repeated characters are still happening here on the Mojave iMac but oddly not on a virtual Mojave on VMWare Fusion! I have updated to Qt 5.12.0 beta but that reports itself as not fully optimised for macOS 10.14. I am a bit stuck for now, and may have to wait for Qt to catch up with Mojave.

This implements a setting that tells the emulator where to find the root for HostFS, so you're not restricted to having it in "Application Support" or wherever you've put it. It doesn't even need to be called "hostfs". You can click on the "..." button and it'll allow you to browse for a folder. Alternatively, you can type one in directly.

The "Show hidden files" checkbox will toggle whether files with a dot at the start of their name are displayed in HostFS or not. There can be quite a few of these, especially in the root of your user folder (e.g. /Users/XXX). ".DS_Store" files will always be hidden, as they are system files, which you shouldn't (in theory) need to access.

This is a change that will (when finished) apply to Linux and Windows users as well, not just Macs. I'll post a link to the patch when it's ready.

What would be really nice is if the HostFS filer menu in the RISC OS Desktop had an "Open host folder" (or some such) item that would make a call to the host machine to open up the appropriate folder. The emulator already picks up SWI calls made by the HostFS filer and the networking, so it would (hopefully) be trivial to extend this to add an additional call. The source for HostFS is available, but is in ARM assembler, and it was probably 1998 when I last did any of that. You can cross-compile it on a Mac/PC/Linux box, interestingly.

I may also get round to making a binary, so you don't all have to keep compiling things all the time. There's one person on the mailing list who seems interested in trying the patch out, but is put off by the need to install gigabytes worth of compilers and IDEs.

Last edited by VincentVega on Sat Oct 13, 2018 8:29 pm, edited 4 times in total.

What would be really nice is if the HostFS filer menu in the RISC OS Desktop had an "Open host folder" (or some such) item that would make a call to the host machine to open up the appropriate folder.

I'd personally urge you not to implement it in that way; or, if you do do it that way, make it do something else!

The point is that I think this proposal is mixing the environments in a confusing way. If there's a new menu item in the RISC OS desktop's HostFS filer to open the parent (host) folder, then as a user I'd expect it to open that folder as a filer window on the RISC OS desktop, not to have a folder open belonging to the parent OS. Besides, it may well be that it's more useful to access that folder via RISC OS. So if I were you, I'd simply make it an 'Open parent' menu item that opens the HostFS parent folder. (Assuming that's actually a legal thing to do, given that it would represent the emulator straying out of its 'sandbox', as it were.) The main RISC OS filer already has an 'Open parent' option on the main menu, of course, which might be used; or there could maybe be a new option on the icon bar menu, much like ResourceFS has "Open '$'".

If you do simply want to open the folder containing the HostFS structure on the Mac side of things, then I'd argue that the option to do that should be in the Mac's interface, not part of RISC OS. Simply have a 'Reveal HostFS in Finder' menu item on the File menu, for example, to open the appropriate Finder window.

As an aside, within my HostFS directory structure I've created hard links to a few external places, such as the Mac desktop, so that I can access them easily (e.g. when I want to print, I often generate a PDF directly on the Mac's desktop and then print it from Apple Preview). It's very useful – and your new option to show/hide hidden files will potentially be very helpful when doing things like that, which involve accessing the Mac's hard drive.

I may also get round to making a binary, so you don't all have to keep compiling things all the time. There's one person on the mailing list who seems interested in trying the patch out, but is put off by the need to install gigabytes worth of compilers and IDEs.

That would be very welcome too. Not that I personally object to building my own copy each time there's a new patch (it's easy enough), but I did have to download and install Qt specifically for that purpose, and have no other use for it at present. So it's a 3GB overheard. Not a massive problem on today's huge hard drives, but even so, a pre-built RPCEm would obviously be preferable.

NB If you decide to go ahead with this, but don't want to bother with both Interpreter and Recompiler versions every time, please provide the Recompiler! I have't encountered any drawbacks yet from using it compared with the Interpreter, and the speed improvement makes a huge difference. I'm surprised that the Interpreter is the default, unless you take specific action to build the Recompiler. I'd have thought that the default build would be the one that's about four times the speed of the other…

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

I may also get round to making a binary, so you don't all have to keep compiling things all the time. There's one person on the mailing list who seems interested in trying the patch out, but is put off by the need to install gigabytes worth of compilers and IDEs.

That would be very welcome too. Not that I personally object to building my own copy each time there's a new patch (it's easy enough), but I did have to download and install Qt specifically for that purpose, and have no other use for it at present. So it's a 3GB overheard. Not a massive problem on today's huge hard drives, but even so, a pre-built RPCEm would obviously be preferable.

It's a bit of an issue when you have a MacBook Air with only 128GB of storage. Yes, I can upgrade it, but only to 256GB. However, I will be soon upgrading to my Father-in-Law's MacBook Pro with a 500GB hard drive, so this will no longer be an issue.

This implements a setting that tells the emulator where to find the root for HostFS, so you're not restricted to having it in "Application Support" or wherever you've put it. It doesn't even need to be called "hostfs". You can click on the "..." button and it'll allow you to browse for a folder. Alternatively, you can type one in directly.

I don't think that this would be a good idea - I like the HostFS folder to be in the same directory as the rest of the files for the OS. This way, if I wanted to switch to another version of RISC OS, I just repoint RPCEmu to a whole another folder, which includes the OS and HostFS specific for that OS.
What I would like to see would be an option on start up to pick the model (as Red Squirrel did/does on Windows).

The "Show hidden files" checkbox will toggle whether files with a dot at the start of their name are displayed in HostFS or not. There can be quite a few of these, especially in the root of your user folder (e.g. /Users/XXX). ".DS_Store" files will always be hidden, as they are system files, which you shouldn't (in theory) need to access.

I like. I get fed up with all these Apple system files...although I do have an application which will remove them.

I'd personally urge you not to implement it in that way; or, if you do do it that way, make it do something else!

Agreed, on second thoughts it would be confusing. I'll think about adding a menu item to Mac side of things, which has the side benefit of not requiring me to get to grips with assembler again(!).

That would be very welcome too. Not that I personally object to building my own copy each time there's a new patch (it's easy enough), but I did have to download and install Qt specifically for that purpose, and have no other use for it at present. So it's a 3GB overheard. Not a massive problem on today's huge hard drives, but even so, a pre-built RPCEm would obviously be preferable.

I spent too much time yesterday trying to build a proper installer. Strangely for a company that's quite focused on the visual side of things, there is no longer a proper GUI thing supplied by Apple for building installers - you have to faff about with command-line tools instead. I managed to get an installer up and running, but half the time it wouldn't actually install anything, though it claimed to have. The binary will instead be a simple DMG that has the "RPCEmu" folder for copying into "Library/Application Support" and probably both interpreter and recompiler versions of the emulator.

NB If you decide to go ahead with this, but don't want to bother with both Interpreter and Recompiler versions every time, please provide the Recompiler! I have't encountered any drawbacks yet from using it compared with the Interpreter, and the speed improvement makes a huge difference. I'm surprised that the Interpreter is the default, unless you take specific action to build the Recompiler. I'd have thought that the default build would be the one that's about four times the speed of the other…

It's been a while since I worked on RPCEmu for any length of time, but I seem to remember that the recompiler version either didn't work or was unstable on Macs when I tried it before. It doesn't take long to build either version on my iMac, and it's easy enough to write build scripts to automate the process.

I don't think that this would be a good idea - I like the HostFS folder to be in the same directory as the rest of the files for the OS. This way, if I wanted to switch to another version of RISC OS, I just repoint RPCEmu to a whole another folder, which includes the OS and HostFS specific for that OS.

Not everyone is comfortable with "Library/Application Support" (they're hidden by default, after all), which is why I'm implementing a UI to allow people to change the directory. It'll default to a folder called "hostfs" inside "Library/Application Support/RPCEmu", so if you want to operate how you describe, you can leave the setting alone.

Out of interest, how do you switch between different versions? Do you use symbolic links and the like, or do you move/rename folders?

What I would like to see would be an option on start up to pick the model (as Red Squirrel did/does on Windows).

Cue thinking out loud/flight of fantasy mode: it sounds like you'd like to be able to have different profiles for different versions of RISC OS and be able to define and switch between them from the UI, and maybe have an option to display a dialogue at start-up that lets you choose what profile to use (similar to the way that VMware Fusion and its ilk allow you to set up different virtual machines). Each profile would let you choose a ROM image, hard drive image(s), HostFS root, and configure the memory/CPU/etc settings like the current preferences dialogue.

Now that we're finally away from Allegro, thanks to Peter and Matthew's sterling efforts, it's nice to have RPCEmu sitting on top of a proper, modern UI framework, so this sort of thing would certainly be possible (though a fair bit of work).

I get fed up with all these Apple system files...although I do have an application which will remove them.

There's also a command-line tool called "dot_clean" that comes standard with OS X that does the same thing. It comes in handy when you're copying files to a CF card for use in a Beeb and the files don't show up because of the weird way that Apple does things. That's caught me out plenty of times.

I have made a stab at building a binary distribution, which can be downloaded here. It's about 33MB in length and consists of both the interpreter and recompiler versions, plus the "RPCEmu" folder that belongs in "Application Support". The actual emulator itself isn't very large, but the QT frameworks on which it relies are fairly weighty. The file is a standard DMG - double-click on it to open it in the Finder. You do not need to install QT, Xcode or anything else.

There is a file named "README-Mac.txt" in the root of the DMG that provides some brief instructions on how to get the emulator up and running.

This release has version 3 of the patch, which provides a working keyboard (subject to issues listed previously), as well as the tweak to HostFS that hides ".DS_Store" files. It does not include the patch for configuring HostFS (mainly because it's not finished and I fancy a break from RPCEmu), but you can create a symbolic link as a workaround if you want to use a different folder.

I've only done a little testing on this binary release, just to make sure the emulated machine starts and goes beep. It works fine on my iMac with 10.12.6 and RISC OS 3.71, and should in theory work with High Sierra and Mojave, though I haven't tested it myself. I would advise you to keep backups of anything important.

As ever, all feedback would be appreciated, even if it is just to confirm that the application does actually start.

I assume you're using the Caliston build, then? I've not used it before, hence my original question.

Yep - I've only ever used the MacOS binaries which are on the RPCEmu website. When I installed RPCEmu on a Windows PC, it confused me as to what this Recompiler and Interpreter was, and which to use (I still don't know!!), and the obvious not being able to switch OS as easily.

Cue thinking out loud/flight of fantasy mode: it sounds like you'd like to be able to have different profiles for different versions of RISC OS and be able to define and switch between them from the UI, and maybe have an option to display a dialogue at start-up that lets you choose what profile to use (similar to the way that VMware Fusion and its ilk allow you to set up different virtual machines). Each profile would let you choose a ROM image, hard drive image(s), HostFS root, and configure the memory/CPU/etc settings like the current preferences dialogue.

That would indeed be an extremely welcome feature.

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

Cue thinking out loud/flight of fantasy mode: it sounds like you'd like to be able to have different profiles for different versions of RISC OS and be able to define and switch between them from the UI, and maybe have an option to display a dialogue at start-up that lets you choose what profile to use (similar to the way that VMware Fusion and its ilk allow you to set up different virtual machines). Each profile would let you choose a ROM image, hard drive image(s), HostFS root, and configure the memory/CPU/etc settings like the current preferences dialogue.

That would indeed be an extremely welcome feature.

Don't worry, it's one the primary reasons for the Qt rewrite. I demoed a mockup version of this at ROUGOL a couple of months ago.

Don't worry, it's one the primary reasons for the Qt rewrite. I demoed a mockup version of this at ROUGOL a couple of months ago.

Do you have a roadmap anywhere? It would be useful to know what is planned for the emulator, to avoid duplicating work. I did spend some time mocking up a UI in QT's designer, but if that's already something that's been worked on, I'll put it to one side.

Incidentally, have you ever thought about moving the code to Github? It would be easy to see any bugs that people have raised, make requests for enhancements and so on.

Last edited by VincentVega on Wed Oct 17, 2018 9:21 am, edited 1 time in total.

I actually can't remember why I even bookmarked this thread (I don't use RPCemu) but since I'm working on bringing BeebEm Mac into some semblance of "up to date" no doubt there's something here that I thought would be useful to remember earlier on, probably on page 1.

Anyway, I did download the package last night and had the following thought: rather than having to have the user put your stuff in "Application Support", why not just have it all in the same folder as the emulator and allow the user to simply drag that folder from the DMG to wherever they wish to install it? Sure, it's not the "Apple Way" but unless you are shooting for a product that will be in the Mac App Store, the "Apple Way" is less important than ease of use for the end users IMO.

BeebEm Mac does it this way and I've been able to produce a DMG that is fully signed and apart from triggering the "downloaded from the internet" warning like any non App Store application will it is entirely drag and drop. For example, given it is not a pure single folder bundle app I tend to drag the folder to "/Users/<home>/Applications" to try to keep the main applications folder a bit tidier. LaunchPad still happily finds it so I can still launch it from LaunchPad. It does also trigger the "Not optimised for this Mac" notice too but that has nothing to do with packaging. That's because it's still 32bit which is another story entirely and part of the upgrade task.

The process of creating the signed DMG was not exactly trivial, but once worked out it wasn't overly complex either and I have since scripted it so I can just repeat at will.

Anyway, I did download the package last night and had the following thought: rather than having to have the user put your stuff in "Application Support", why not just have it all in the same folder as the emulator and allow the user to simply drag that folder from the DMG to wherever they wish to install it? Sure, it's not the "Apple Way" but unless you are shooting for a product that will be in the Mac App Store, the "Apple Way" is less important than ease of use for the end users IMO.

I see. Why should this application get to ignore all the well-established conventions for applications running on a Mac? It's running on an Apple computer, therefore it should try and do things the Apple way. Making up your own rules is arguably more confusing than putting things in "Application Support".

Personally, I don't like having files all over the place (my desktop has no files on it), all my applications belong in /Applications and I never use Launchpad.

If anyone else has views on my use of "Application Support", then please let me know - if the prevailing view is that people would rather me use something else, then I'll change the patch.

The Windows/Linux versions of RPCEmu will load the support files from the same directory as the executable. On a Mac, this would actually be inside the application itself, namely in the "Contents/MacOS" folder, which is why I changed it. From looking at the source, Caliston builds look like they prompt you for a data directory on first start-up - would this be a better approach?

I'd like to report an important problem. It's a trivial but actually very important thing: I can no longer put spaces in filenames. Regardless of what you may think to this, I've always been a pretty heavy user of Alt-Space to put hard spaces in filenames. Especially in a long filenames context, it's tremendously useful. Under the latest emulator build, unfortunately it no longer works. Files that have spaces in their names already can still be used, thankfully, but unfortunately you can't create new ones. Presumably a HosfFS bug. This didn't apply to the previous version 0.8.14, which was fine in this respect.

I hope a fix isn't too big a problem, because it'd be really helpful to have this put right.

Also, a word of thanks…

I've just been using ArtWorks under the new 0.9.0 for a potentially important job, and I'd like to say what a BIG improvement the new version is, in terms of overall usability. They keyboard was increasingly becoming a problem in the old version, not to mention the need to hold down important keys to gain Adjust/Menu functionality on the mouse. Now the keyboard and mouse work exactly as expected, including things like holding Alt down to switch modes temporarily, and keyboard shortcuts that never used to work in the past do now work. So THANK YOU to VincentVega and everyone who's been involved in working on this; it's a great step forward. The mouse lag is still a big problem for me (haven't had time to investigate its cause yet), but even with that problem, this emulator is now considerably more usable than ever before.

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set