If I get to the position of having to use just a laptop, the chances
of it running windows natively are about the same as it running RISC
OS natively. It will be  Macbook, almost certainly. Windows in a
virtual machine if needed and RISC OS in another if available, (but
certainly not in a VM within a VM).

RISC OS has a great user interface and is very good for certain tasks,
however it is not good enough to be worth suffering windows for.

There's also an issue with the VM's JIT cache: JITing JITed code never
results in good performance, as it's a pain to cache.

I also suspect that, if they are free to choose, most RO users will
move to MacOS rather than Windows for the same reason. (Not all have
that choice, of course.)

Therefore I am puzzled as to why there is such a reluctance for
'porting' (if that's the right word) RO software to Mac. I'd have
thought it would be logical (i.e more lucrative) to do that /before/
porting to Windows.

It's strange, and quite frustrating, to have some RO products on
Windows and not on Mac. Mac is a smaller market but with a bigger
willing customer base for such things.

So my plea to all active RO software authors is to consider the
motives of people buying a Mac, against those buying a Windows system.
Financially, it must be a better bet as most Mac users don't have cost
as the major reason for buying.

So, to my mind, both Aaron and Paul (VA and OPro) are missing huge
opportunities with their work by ignoring MacOS, and our loved RISC OS
suffers for it.

Jeremy.

Might I add that I only bought a Mac because a program I had been using
on a PC was abandoned by its owners and development ceased.  But the
original program continued on a Mac and development continues, so I
bought, and migrated that activity to, a Mac.  I sometimes have to turn
the PC emulator on on the Mac but the PC here has not been turned on for
months now.

I will buy a VA for Mac tomorrow!

It was first previewed on Mac on PowerPC so there was the issue of the JIT
needing to be ported to a different processor which was a big job, but now
MAC is on Intel this task has evaporated as the x86 JIT code can be used.

---druck

There's a lot more to get working that just that though - things like
printing, and reliable host file system access etc need to be done as
well, and last time I asked anybody about this, this was precisely the
work that needed to be done.

I'm still hoping somebody will put the work into making RPCemu less
repugnant than it is, and adding a JIT to it, such that we have a nice
free alternative to use should ROOL ever actually manage to do anything.

The advantage of qemu is that it's a JIT and quite cross-platform (runs on
x86, x86_64, PowerPC, SPARC, Alpha, etc CPUs and Windows, Linux, MacOS,
Solaris, etc).  It also has quite a lot of emulated hardware - full network
support, including an internal Samba server to serve local filesystems,
serial/parallel/floppy all implemented (just need wiring into the right
places for the RPC emulation), USB (OHCI, not sure if this matches Simtec or
Castle).  I think it'd be fairly trivial to bring across RPCEmu's HostFS
too.

Currently it gets as far as booting RISC OS and displaying an abort message.
It looks like there's something wrong with either the timers or the CPU
emulation - the 26 bit CPU model was written for this port so there's quite
possibly something amiss, and there may still be holes in qemu's upstream 32
bit ARM emulation (RISC OS tends to use more varied instructions than ARM
Linux does, which finds bugs not exercised by GCC's ARM output).

I had a look and found a few bugs, but ran out of time.  If anyone wants
help in understanding the code I'm happy to show them round.

And... If you have a version of VRPC installed on the Win-PC you have a
double advantage.

Dave S

Or was that a typo?

John