Date : Mon, 25 Jul 2011 23:20:05 +0200
From : rick@... (Rick Murray)
Subject: Risc PC (Was 'Minitel in France')
On 25/07/2011 11:41, Tom Walker wrote:
> DLL hell was unforgivable, though understandable as to how it came
> about
Unforgivable was waiting until ME before the OS thought to protect core
modules from being overwritten, and XP for a version that actually worked.
> Modern versions of Windows have largely fixed it, I don't think DLL
> problems have been an issue for quite some time.
Can't speak for Vista/7, but I think the transition to NTFS helped. Take
a look in \Windows\system32 some time, and skuh-reeem. ;-)
That said, there are still occasional issues of installing a program
that installs some of its own resources, and you discover something like
one of the (many) CommonDialog DLLs has been replaced by a version in
<insert language>. And suddenly everything that uses it speaks <insert
language>, but only for specific dialogues.
> I'm impressed though, that most of the DOS and Win16 programs I've
> tried still work on XP at least. That's given 2 complete changes of
> operating system (DOS -> Win3.x/9x -> NT), whereas Acorn never
> changed 32-bit OS (RISC OS is still based on Arthur).
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). My own
C-based 6502 simulator fails miserably. Under real DOS, it loops through
the instructions to perform. Under NTVDM it keeps stalling until
something is written out to the display which momentarily kicks it.
Switching to DOSbox gives a magnitude speed boost.
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?
> I'm not sure why they need to split and multiply as they do these days.
Probably got different dev teams on the different branches! It is
stupid, though, to think they it can't be sanely backwardly compatible.
It'd be like having to have multiple sets of Toolbox modules loaded at
the same time.
> 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.
> 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.
> as they were lent a pre-production RiscPC by Acorn. But only for 24 hours.
Gee, that's generous!
> But the fact that it is there (and documented) means people _are_
> going to play with it.
A lot of stuff is available and documented. Just because there's an OS
call to fiddle with the MEMC, as opposed to memory pokes for the IOC,
doesn't mean it should be played with! At least not in release code!
Most of the faults I have seen are faults that depend upon a specific
arrangement of the hardware:
* Disc protection relying on 'features' of the 1770 chip used in
early machines.
* The UpdateMEMC which tweaked ROM access timings.
* Fiddling in the memory map and making assumptions as to the
data found there.
* Hacks to FIQ code or SWI intercept, or suchlike.
* And so on...
> 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. Namely when the 26
bit PC + PSR in R15 became a 32 bit PC with separate CPSRs (plus a few
SPSRs for good measure).
> The R15 change is pretty inexcusable though.
Not really, ARM *had* to move beyond the 64Mb limit. It had to address
more than a 26 bit PC could handle. It isn't their problem that Acorn
weren't willing to tackle this one head on.
Neither did ROL, until they've come to the realisation that everybody
who's going to update their RiscPC, probably has...
Castle, well, they didn't have a choice. Their CPU was 32 bit, end of.
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? I just hope the devs at ROL and ROOL
are in communication to try to keep stuff in step.
>> and 3.5. So why did Acorn now go with 4?
Argh! Typo! ^^^ not
> Were they actually intending to call it 4?
As in, why was 3.5 called 3.5, and not 4.
>> I'm not sure how much the ARM handles, and how much is DSP work,
> The bulk of that is probably the DSP.
I'd imagine so, ARM has never really done the whole "FP" thing much, has it?
> The ARM9 is a good processor though. Just a shame it was too late to
> be a desktop chip.
Aren't the early Beagles OMAP chips with ARM9 cores?
> I suppose though, the 32-bit switch was a big enough one to implement
> this sort of change. You can still _read_ from zero page though.
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...
> No specifics, but he did mention the changes to the memory management
> SWIs broke a _lot_ of software.
I assume you mean frobbing in the memory mapping, not OS_Heap?
If so, probably the underlying structure changed.
Quote from the PRMs [1-343]:
The MEMC chip controls how logical addresses (those used by programs
or modules) are mapped into the physical memory location to use.
Numerous calls are used to control how it does this, though generally
this is something that most programs would not want to do.
The descriptions in the PRM mention time and again about it being
MEMC-related. Thus, it makes sense that different hardware would not be
compatible. After all, the SetMemMapEntries says:
Any address above 32Mbyte (&2000000) makes that page inaccessible.
which is going to be somewhat outdated now.
If Acorn mucked around with OS_Heap, then I'd stand up and say
"morons!", but if this was referring to lower level memory
access/control, I'd question what was going on...
Best wishes,
Rick.
--
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...