Date : Mon, 25 Jul 2011 10:41:05 +0100 (BST)
From : tommowalker@... (Tom Walker)
Subject: Risc PC (Was 'Minitel in France')
> > I'll agree it wasn't a big deal in 1991, but it did fail to 'future
> > proof' the machine in any way.
>
> MEMC was designed way before 1991...
But Acorn consciously decided to keep using it instead of developing a new
chip. Along with VIDC. Both of which I think shortened the A5000s life.
> ...I think Microsoft is an example of how it can go wrong.
DLL hell was unforgivable, though understandable as to how it came about
(largely due to Win16 having a shared address space and a central DLL store).
Modern versions of Windows have largely fixed it, I don't think DLL problems
have been an issue for quite some time.
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).
I do think with APIs they've lost the plot recently though - .NET being
a good example. DirectX showed a reasonably good way of having multiple
API versions available simultaneously, I'm not sure why they need to split
and multiply as they do these days. MS aren't the only guilty party though
- Android seems to be pretty much the same.
> It was nice Win95 could run Win3.1 programs, but perhaps this should
> have been dropped when XP came out?
I think there was still a lot of 16-bit code being used in various businesses
at the time. The 32 -> 64 bit switch is when they killed Win16 support, and
probably a more sensible time. I wonder if Win32s is still supported? That
would keep at least some of the later 3.x stuff running.
> I'm not sure I'd say maliciously, but I've known a few coders who were
> lazy, tested their code on their machine, and just "assumed" it would
> work for everybody else.
Depends on whether the machines in question are actually available. In a
lot of the RISC OS cases code will have been tested on a wide spread of
machines, but then something completely new (RiscPC) comes out and changes
all the rules, with no way to predict what seemingly innocent code will now
fail. The Krisalis example I gave earlier is an exception, as they were lent
a pre-production RiscPC by Acorn. But only for 24 hours.
> Easy test - switch your machine to use System Font and see if the
> templates still work, or if its all messed up. Okay, it isn't a critical
> issue, but it shows how easy it is for a developer to cut corners along
> the way...
Or simply not realise that some things might be an issue.
> Just 'cos it is there doesn't mean it is for playing with. ;-)
But the fact that it is there (and documented) means people _are_ going to
play with it.
> > more Digital not intending for SA to run 'legacy' code.
>
> Intentional, or again somebody noticing that a 64Mb barrier was going to
> be something of an impediment?
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. Digital aren't the only guilty party of the former - Motorola had
similar problems with the 68040 IIRC. The R15 change is pretty inexcusable
though.
> Seriously - I think *technically* the change between RISC OS 3.7 and
> ROL's original 4/Select is smaller than the change between 3.1 and 3.5.
> So why did Acorn now go with 4?
Were they actually intending to call it 4? All the dev versions were 3.8,
but I don't know if that was temporary or not.
The other 'big change' was 3.6 -> 3.7 - there are a lot more changes in the
latter (particularly in the kernel) than the version number suggests.
> I'm not sure how much the ARM handles, and how much is DSP work,
The bulk of that is probably the DSP.
The ARM9 is a good processor though. Just a shame it was too late to be a
desktop chip.
> Just fired up RedSquirrel running a ROM dump from my RiscPC
> (3.7).
>
> --8<--------
> *BASIC
> >!8 = 0
>
> --8<--------
>
> Yup, froze it solid. I *thought* it was done RiscPC era. I guess not.
> Way to go Acorn!
Just done some testing with RPCemu. RISC OS 5 is the only version that write-protects
zero page! Even 6.16 freezes. Wonderful. So change my '1999' to '2003. Maybe.'
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.
> >> Unless very tight control is kept over system interfaces,
>
> ...which there's no reason Acorn couldn't have done this...
>
> I wonder if he posted any examples?
No specifics, but he did mention the changes to the memory management SWIs
broke a _lot_ of software.
Tom