...and in this land of liberty, we'll make our living at poetry...(you'll starve - DH)
Welcome back to the Foundation RISCWorld letters page. The merger of the two magazines, Foundation RISC User and RISCWorld seems to be going down fairly well with our readers, although it has raised a few questions...
Having finally made it from Nippon to Aotearoa (Japan to New Zealand for those who insist on sticking to English), in one piece as far as I can tell, I have at last got into Vol. 9 Iss. 1 of what is now Foundation RISCWorld - on my shiny new Mac, since the RPC is still on the ship.
All I can say is that this stands to be a useful combination of resources, and if past performance of its parents is anything to go by, we, your readers, can look forward to an interesting and useful publication (not to say a list of vehicles to avoid buying at all costs). My initial reaction is, so far, so good.
The manner in which the Foundation half ceased to exist on its own raises the question of whether those who subscribed to both will receive some form of recompense for issues not received - an appropriate extension of our FRW subscriptions, perhaps? I hasten to say that I have not been tallying missing issues, and don't propose to attempt to do so, so I shan't be checking.
In response to the question you probably haven't bothered asking, I haven't tried my Vol. 8 Iss. 1-6 CD that I asked about last time in the Mac's drive for the simple reason that it, too, is still on the boat.
Kia-ora, and all the best for the future of FRW.
Thanks for the letter. We hope that by combining the two magazines we can seriously improve them. At the moment the magazine is more "RISCWorld" than "RISC User", but in part this is because I work a long time ahead (believe it or not I already have stuff lined up for Volume 10). Another reason why the new magazine is more "RISCWorld" is that we've had difficulty contacting some of the old RISC User authors. So if anyone out there used to write for RISC User and would be interested in writing for Foundation RISCWorld (in exchange for money) then please do get in touch.
With regard to subscriptions for Foundation RISC User, I'm sorry but there isn't a great deal we can do at the moment. We know that there were a few people who were still owed issues by RISCOS Ltd and they obviously haven't had them. We are talking to RISCOS Ltd about this and the current proposal is for a "special" bonus CD to be sent to all those who had Foundation subscriptions when the merger took place. I can't really say a great deal more at the moment as things are still a bit up in the air.
I hope that you finally manage to get all your stuff off the boat and into your new house. We only moved 150 miles when we came to Derbyshire and that was stressful enough, moving from one country to another and transporting stuff on a container via a ship doesn't appeal to me.
Moving on Foundation RISCWorld regular Martin Carrudus has been busy again...
At the risk of bombarding you, hot off the press, yet another Acorn RISC OS application. There was an algorithm (method) I learnt a long time ago, called The 'Quine-McCluskey' Method, but I am not even sure of its spelling - it's not in any of my Maths reference books.
Anyway, I have implemented the Method, for what it's worth, as it's rather academic. Please find attached !QuineMcC, zipped, all to do with logic simplification.
This is my 55th Acorn application so far:-) No doubt, I'll find some bug, and have to resupply...
Thanks for sending a copy of this, but I'm sorry to say that it's gone straight over my head, with plenty of clearance. Having said this I have been having a play and setting up the grid of numbers and trying to predict the resulting equation is actually quite fun (although I know that's not the intended use).
Now let's take a look at one of my "favourite" subjects, technical support...
I've just finished reading, in RISCWorld 8-6, your little rant-ette about customers who need support & don't communicate well or explain the problem properly. I have the same problem (& a couple of others) since installing RISC OS 6 so here goes.
I bought a stand alone version of RISC OS 6 at the South-West show.(Select 4.issue 2 April 2007). I'm not in the Select scheme.
I installed it on my laptop so it is now softloaded over my VirtualRPC-SA (ser. no. 20245-VRP). Everything works well except for 3 problems.
1. Since installing RISC OS 6, there is a directory in HostFS::HardDisc4.$ called SelectSupport. Within this is a directory - VRPCFeatures. Within this is a !Boot file which contains a little program !VAShuDwn. It's supposed to make returning to Windows easy. The fullpath is:- VRPCFeatures.!Boot.Choices.Default.Boot.Tasks
On merging this with your Boot sequence, it gives you, on shutdown, a new window with a choice of "Restart RISC OS" or "Return to Windows". Clicking on the latter gives an error message "Bad Command 12". The only way to get back to Windows is to use Ctr+Alt+Delete.
2. The caps lock is on at startup & I have to press caps Lock to get back to normal operation. No matter what I do in Configuration; keyboard, it is always thus. If I return to Widows without pressing Caps Lock, Caps Lock is also now on on the Windows side.
3. The floppy drive now constantly reports empty when there is a disc in it & the same happens when I return to Windows.
Hope I've given enough info.
Can you help, please
Thanks for the letter. I think that I might be able to help, at least a bit. Firstly the "SelectSupport" folder was always present, as it's part of the default VirtualRPC disc build. It's nothing to do with the RISC OS 6 install, secondly you didn't need to install it, it's designed for versions of RISC OS 4, not RISC OS 6 (when the components were put into the VirtualRPC builds RISC OS 6 didn't exist). So the first thing to do is go delving into your "Boot sequence and then remove the !VAShutDwn application as you don't need it and it won't work with RISC OS 6, as you have discovered.
Moving on the the Caps lock problem, I don't have a solution for this, although I have seen it happen. I suspect it's because the two versions of RISC OS, the RISC OS 4 that boots up and the RISC OS 6 that gets soft loaded, store their settings in different place in the RISC OS CMOS RAM. If you try booting into RISC OS 4 (rather than RISC OS 6) does the Caps Lock status get correctly reported?
The floppy drive failing to work after a copy of Select has been installed is a well known problem. It seems to be caused because under a VirtualRPC the soft load happens very quickly, certainly far quicker than a real machine. So the floppy gets interrogated by RISC OS 6, before it's spun down again after having been interrogated by RISC OS 4. Whenever a copy of RISC OS loads it always spins the floppy drive (you will see the light come on). The "solution" is to make sure that you have a floppy disc in the drive before you load VirtualRPC. This alters the behaviour of the drive and RISC OS 6 gets the "correct" information when doing its interrogation.
Hopefully the above will solve at least two of the problems. Talking of problems here's one that left me scratching my head...
Having just started subscribing to Foundation RISCWorld I was very interested to read your remarks about the attachments problem with MPro in your Technical Support article.Apologies for the delay in replaying - I've been busy polishing off the next issue.
You may recall that I raised this with you a few months ago, and you referred me to Paul Beverley's solution. My own experience since then has been rather different, so I thought it worth reporting.I do recall - what gets me is that there are 100's of people using MessengerPro on VRPC without any apparent problems.
Firstly I should say that when I mentioned it to Andrew Rawnsley he warned me against booting VA from ADFS rather than HostFS, as it would ruin UniPrint, which I use a lot.It's easy enough to avoid this problem - by getting Uniprint to save its print job into the "old/unused" boot sequence that will still be on the HostFS drive.
In the simplest terms my experience with sending attachments is as follows. I have two alternative configurations:-
A. Running ADFS::IDEDisc4.$.!Scrap at start up.B. Omitting this from running at start up.
Whichever configuration is set at first booting, sending e-mail with an attachment always fails and VA freezes. I can always "unfreeze" it by rebooting having first changed the run at start-up to the alternate configuration, i.e., if the original configuration is A., change to B., and vice-versa. So far this has never failed to unfreeze VA. Thereafter I can continue sending e-mails with attachments during the same session, but of course if I switch off and re-boot I am back to square one.I wonder if it's something daft with the name of the current Scrapfolder? This is derived from the state of the network when RISC OSboots...what's the name returned by:
Suppose you implicitly set this (assuming MessengerPro uses it and you will need to ask R-Comp which Scrap variables it uses) to a fixed file. It could simple be that Mpro doesn't like something in the Scrap path?
At least I can now send e-mails with attachments, but it is a bit tedious, involving:
1. Exiting VA2. Rebooting3. Editing !Boot to change configuration4. Rebooting again
I hope this may provide clues to what is going on. Can you suggest any way in which this procedure could be simplified?
This one still has me stumped, because, as you say, there are hundreds (or more likely thousands) of people using Messenger Pro on VirtualRPC with no problems at all. I have spoken to R-Comp about this at some length, but we are none the wiser, but at least they are better informed. Firstly R-Comp have told me that MessengerPro doesn't actually use the Scrap directory, it keeps stuff in it's own directory inside Choices, which of course is part of the !Boot sequence. As such I am heading towards the conclusion that "something" is wrong with your RISC OS !Boot sequence.
We know that Messenger Pro works on VirtualRPC. We know that the vast majority (certainly well over 99%) of people don't have any problems, so it must be something specific to your set up. As such my advice is as follows:
- Quit VirtualRPC.
- From Windows navigate to C:\Program Files\VirtualAcorn\VirtualRPC-xxx\HardDisc4.
- Rename the folder called !Boot to OldBoot (note the lack of the ! character).
- Install another copy of VirtualRPC in C:\Program Files\VirtualAcorn\Temp\VirtualRPC-xxx.
- Move the !Boot folder from the new "temp" VirtualRPC into the old one.
- Now start up VirtualRPC and see how it behaves.
- Note that you will need to re-set the screen resolution and some other settings that are stored inside !Boot.
This will replace the current !Boot sequence with a new copy. You can always revert to the old !Boot as we didn't delete it, we just renamed it. I suspect that with this change Messenger will now function correctly. If it does we know that the problem was in the "old" !Boot sequence.
Having, hopefully, fixed the above problem it seems that Andrew isn't the only one who's had an "issue" or two...
Yes, it's him again! I was not happy with Quine-McCluskey, because it found ALL the logic expressions that fitted in the TRUE area, and they very often overlapped and reduplicated themselves i.e. It was not finding the most efficient Boolean representation.
What I did was to make it look back through all the expressions generated by Quine-McCluskey and eliminate those that were overlapping and not essential to the logic expression. It was all going pear-shaped, and I thought, "Nice Try, " until I studied my code again, and found I was mixing up my rows and columns. That was why it crashed on one occasion, because it was trying to access rows/columns that didn't exist!
I am VERY pleased with the result now. It still, on occasion, doesn't choose the most obvious solution, but it's doing MUCH better than it was in finding the simplest representation of the Boolean expression (i.e. there are less things ORed together).
So, I have pleasure in attaching Version 2.00. I have tried to test it out asbestos I can, so I hope I needn't bother you again, unless I dream up something new to program up.
Thanks for the updated version. I am including this one in the Letters section of the Software directory on this issue. Any feedback from users should be sent directly to Martin, all the contact details are in the documentation in the archive with the main application.
To contact the RISCWorld letters page please e-mail us using the following e-mail address. The deadline for letters being published in the next issue is the 10th of November.