VirtualAcorn Tech Support
More from Aaron's tech support notebook
Rather than my usual batch of low level moaning about customer support, I decided for this issue to cover the more amusing stories relating to customers placing orders. October is always our busiest month so I can urually expect a few strange things to happen in the ordering process...
The postal strikes near the start of the month caused total chaos, especially given that they coincided with the proper launch of the VirtualAcorn on-line ordering system. The result was that we had customers placing orders but their goods not arriving promptly. I sent a large batch of items out on Wednesday the 10th of October (the first day after the strikes were over) but they took three weeks to arrive. This is totally out of my control but I got complaint after complaint from people who hadn't got their goods. This I can understand, but they've been sent and I have the proof of posting vouchers to show it. The common issue wa that "..the strike is over...", yes, it is, but it will take weeks to get back up to speed. Most people were very understanding but one particular person got very abusive. We were accused of "...ignoring the order...having no intention of sending the goods..." etc. In his case the order was processed on the 8th and posted on the 10th. Did he not know there had been a strike? "Yes, it's delayed our post..." So things you have sent have not turned up? "...er...yes...but the strike's over now and you should send another copy at once..." No. I've spoken to Royal Mail and been told that customers need to wait until the start of November before the backlog will be cleared.
He kept on complaining but I wouldn't budge. Good job too, as the missing VirtualRPC turned up two days later. So what's the point of the story. Well it's this. Small companies like VirtualAcorn rely on the RoyalMail to deliver the goods people order. If goods don't turn up then people are (quite rightly) going to want their money back. Most people were very understanding and, once we had confirmed that their order had been processed and dispatched, understood the problems. A couple didn't, oh well. Any business relies on being able to provide the goods/services in a timely manner and part of this is being able to trust in a fast, reasonably priced and reliable delivery method. In our case, and the case of thousands of other companies, that's Royal Mail. Normally the service is excellent, but in October it fell well below the minimum standard. It hasn't done any long lasting damage to us (everything seems to have arrived) but I know of other companies that have had items disappear and have had to re-send them. This costs money.
Royal Mail need to understand that the dispute should never have been allowed to get to this stage. If they can't provide a decent reliable service then they need to have their monopoly removed and let someone who can do it take over.
Anyway, on a lighter note here is another amusing little tale. A Dutch user of VirtualRPC-SE e-mailed me last week to ask about the cost of an upgrade to a StrongARM version. I explained that the cost was £34.00 (including P & P). He sent me an e-mail back a couple of days later saying that he had returned the CD and quoting my e-mail with the price. He also said that he was including payment of £25.00, but it was OK as I could keep the extra £1.00.
Adding modules to the RISC OS ROM
If you are undertaking the following then please note that it's entirely at your own risk and that VirtualAcorn will not offer any support or assistance with adding modules to the RISC OS ROM.
The Windows versions of VirtualAcorn have a useful little undocumented feature. It's possible to include extra modules so that they appear in the RISC OS ROM. We included support for this some years ago in order to allow us to include special VirtualAcorn versions of some modules to replace those in the standard ROM. Building a full ROM isn't a trivial process. Lots of items need to be linked together, lookup tables generated etc and only RISCOS Ltd have the facilities to do it. So if we wanted to test something we would have to send the module off, wait until a ROM was built, then test it. This could be very time consuming.
RISC OS already supports a method for adding items to the main ROM. It's called a podule. You will no doubt have noticed that when you add a podule (expansion card) to a "real" RISC OS machine it will almost always come with a set of driver modules on a ROM chip on the card. When you insert the card in the machine, then start the machine up you get extra modules being added to the main ROM. We decided that this was potentially a good method for including our own versions of modules to overwrite those in the RISC OS ROM. So we implemented a "virtual" software podule that could contain any modules we wanted.
Before going further with a description of how to add modules it's worth explaining what RISC OS does with podules (either real or virtual). When RISC OS starts up and before it's displayed anything on screen it scans down the podule bus to see what it's got. Each podule will report what it is and be given the opportunity to run some initialisation code if it needs to. The podule can also report the names of any modules it contains.
If the podule has a module with a name that is different to any of the main modules in the RISC OS ROM then the module will be loaded and will appear in the *modules list as though it was part of the main ROM.
If the podule contains a module that has the same name as one already in the RISC OS ROM then the version numbers are compared. If the version number of the module on the podule is the same or lower than the version number in the RISC OS ROM then it is not loaded. Only if the module has a higher number than the one in the main ROM is it loaded and added to the modules list.
So first things first. Before trying to add extra modules to the RISC OS ROM you firstly need to make sure that your particular copy of VirtualAcorn supports the facility. If VirtualAcorn is running then quit it. Then, using Windows Explorer navigate to the location where VirtualAcorn is installed. This will normally be C:\Program Files\VirtualAcorn\VirtualRPC-xxx where xxx is the particular version of VirtualAcorn that you are running.
You will see something that looks something like this:
The part of VirtualAcorn we need to look at is in plugins, so open the plugins folder:
The section we are now interested in is called HostServices. If your copy of VirtualAcorn doesn't include this then it's quite (very) old and needs to be updated. It can be updated free of charge by downloading upgrades from the downloads section of the VirtualAcorn website. If you do need to upgrade your copy then you must carefully follow the instructions on the particular download page for your product.
Assuming you have the HostServices folder you need to open it. You will then see this:
Any replacement modules will live in the Chunks folder so open that:
You will see that at least one module is already present. In the example above it's the VirtualAcorn version of the Portable module. This is used by the power management system, so don't remove it. As you can see instead of having a normal Windows file extension it has ,ffa on the end of the filename. As I am sure you have realised FFA is the RISC OS filetype for a module and the modules that are stored in Chunks are compatible with the files that are already stored in the HostFS HardDisc folder that you can see in figure 1.
So lets say that you want to take a module from the current RISC OS Boot sequence and add it to the RISC OS ROM. From Windows you will need to navigate into the VirtualAcorn HardDisc4 folder. The inside of it will look something like this:
You can open up your RISC OS Boot sequence (from Windows) just by double clicking on it, you don't need to hold down the Shift key. You can then navigate your way down through to the !System folder. This can also be opened with a normal double click. You can then find the particular module you want to transfer to the ROM. As a note of caution don't try to transfer a folder, you should only copy modules that have a ,ffa extension on the end. Having selected the module you want to put in the ROM you can now copy it to the Chunks folder next to the Portable module.
Now load VirtualAcorn. If it doesn't load properly then you have done something wrong. Go back and delete everything except the Portable module from inside Chunks. Then check VirtualAcorn loads OK, then try copying the files again.
Assuming VirtualAcorn does load and enters the desktop correctly you can now make sure that the new module is loaded in the ROM. To do this simply press F12 and type *RomModules. You will see a list of ROM modules. Your new module should appear at the bottom of the list on a podule (typically Podule 3, but it does depend on your particular setup):
In the example above you an see the Portable module is showing on Podule 2. Once you are happy that the module is loading correctly you can then remove the duplicate copy from the RISC OS Boot sequence. The best idea is to move it out of the Boot sequence somewhere safe rather than just deleting it.
So what can you do with this facility? Well here are some ideas:
- Force a certain version of the SharedCLibrary to always be present.
- Make a module containing extra components to be added to the RISC OS Resources folder.
- Ensure that a particular module is always present, even if !Boot isn't run.
- Test modules you are building to make sure they run correctly in ROM.
VirtualAcorn's facility to add modules to the RISC OS ROM in this way is also being used to support 8Mb of VRAM under RISC OS 6. A special VirtualAcorn VIDC video driver is being tested at the moment I was hoping it would be ready in time for this issue, but we have hit a nasty snag and it's going to take a bit longer than we had hoped.
VRPC for the Mac Config files
I have had a few people ask me how they can edit the config files in VirtualRPC-AdjustSA for the Mac. On the Windows versions of VirtualAcorn the files can easily be seen and edited. On the Mac version of VirtualRPC the config files are all inside the main VirtualRPC-AdjustSA "package". However it's still easy to get at the files if you know how. I should, as a note of caution, advice that messing about with the files unless you are 110% sure you know what you are doing can cause VRPC to stop working.
To edit a config file by hand you need to go and find the VirtualRPC-AdjustSA application on your Mac harddisc. It will normally be in Applications/VirtualAcorn/VirtualRPC-AdjustSA. Now right click on the VirtualRPC-AdjustSA application and click on Show Package Contents. A window will open with a Contents folder. Navigate to Contents/Resources/Models and you will see the three folders for the three different ARM processors supported by VirtualRPC-AdjustSA. If you open one of these models you will find a .cfg file. This contains the VirtualRPC-AdjustSA configuration for the particular model. The file is in human readable text format and can be loaded into TextEdit. You can then see all the options that are set.
There will be more from me next issue...
Aaron