Date : Mon, 25 Jul 2011 22:49:45 +0100 (BST)
From : tommowalker@... (Tom Walker)
Subject: Risc PC (Was 'Minitel in France')
> DOS code works under NTVDM which is a sort of virtual DOS. Accordingly,
> some stuff fails (try a game that doesn't use the 4GW system).
Even the stuff that uses DOS4G/W has an impressive amount of patching done
to it, otherwise most of it would lock up. Even with a solid API (DPMI)
it was still impressively easy to get it wrong and make stuff that would,
under a multi-tasking OS, mishandle interrupt flags, mishandle memory, mishandle
timers, etc. Hence me being impressed that any of it works at all.
> Likewise, Win16 programs work under a sort of emulation layer that fakes
> a Win16 environment. I guess in its way this isn't so different to
> Aemulor?
Doesn't Aemulor do actual emulation? Win16 stuff runs natively, just with
lots of 32->16->32 bit thunking.
> > That would keep at least some of the later 3.x stuff running.
>
> Why not a virtual environment? Hell, with PortableUbuntu, I can run an
> x86 version of Ubuntu not side by side with Windows, but actually within
> the XP environment. If they can be done, I don't see why the same could
> not be done for Win16... if there was enough of a call for it.
I've heard there are actual technical reasons this hasn't been done, mainly
interoperability between the Win16 and Win32 sides. Either that or MS just
keep having nightmares about how the Win16 VM worked in OS/2 (ie badly).
> > Depends on whether the machines in question are actually available.
>
> That is what beta testing is for. Rope in some friends with different
> hardware, and check it all works for them.
I'd be impressed if you could do this with hardware that hasn't been released
yet.
> > The 26/32-bit changes have nothing to do with the SA incompatibilities
> > - it's the lack of synchronisation between code and data caches, and
> > the change in R15.
>
> !!!??? The change in R15 *is* the 26/32 bit issue.
Methinks you're getting a bit confused here :) I'm referring to the StrongARM
R15 reading PC+12 in some circumstances when older chips read PC+8.
Obviously the 32-bit change also changed R15 (more drastically), but the
SA 26-bit change was more subtle and also caused quite a few slip-ups.
> That said, we are potentially seeing a fragmentation in RISC OS from two
> disparate versions. Really, the source trees should merge, but how can
> this be done in a commercial sense?
Having worked a bit on ROS 5, and having disassembled bits of 6 to get it
running on RPCemu, I can assure you the merge is not going to happen anytime
soon.
> I'd imagine so, ARM has never really done the whole "FP" thing much, has
> it?
They're getting better. I recently had to use VFP for a uni project though,
and the compiler support was quite poor. NEON's better apparently.
> Aren't the early Beagles OMAP chips with ARM9 cores?
No, Cortex-A8. Different beast altogether (Pentium to the ARM9's 486).
> I dimly recall one of my machines (A5000?) having a small patch to block
> writes from user mode to page zero. I think it was a couple of lines of
> BASIC...
Ah, but how much software worked afterwards? ;)
> I assume you mean frobbing in the memory mapping, not OS_Heap?
I believe he was referring to OS_Heap changes. Krisalis tended to stay away
from that sort of low-level stuff, the only hardware specific stuff they
did was video related (eg split palettes).
Tom