Date : Mon, 25 Jul 2011 00:40:20 +0200
From : rick@... (Rick Murray)
Subject: Risc PC (Was 'Minitel in France')
On 24/07/2011 20:45, Tom Walker wrote:
> 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...
> I was assuming you weren't using a multisync. Mode 21 on an A3000
> (even an ARM3 one) seems positively insane ;)
No, I never got an adaptor for the old-style VGA socket, so it was just
hooked to a TV-res display (an AKF12).
> I think the key here is really the difference between only keeping
> legal interfaces going (ie keeping the OS 'correct'), and actually
> putting the effort in to keeping programs working, no matter what.
We need a balance. Acorn should have done more (esp. regarding stuff
like UpdateMEMC) but...
> The latter I suspect is a fairly big reason why Microsoft are so
> successful, as they do actually put the effort in to keeping user
> programs running.
...I think Microsoft is an example of how it can go wrong. I reckon half
of DLL hell is due to bending over backwards to keep old software
running. Case in point being .Net - at one time my computer had *three*
different versions installed, each of which had periodic updates. [three
side by side? compatibility fail!]
It was nice Win95 could run Win3.1 programs, but perhaps this should
have been dropped when XP came out? I think they finally got around to
getting rid of this sort of stuff for Win7; perhaps given that modern
computers are capable enough to run Win3.11 under emulation...
> systems to run applications, and if said applications stop working on
> an upgrade then they get pissed off.
Yup. But, then, read mailing lists and forums. Users get pissed off
about pretty much anything nowadays if they can vent on the internet. ;-)
> After all, why should the end user care if a program uses legal
> interfaces or not?
They shouldn't. It's the programmer's problem. But the end users are the
ones who will suffer. Kinda like the bankers screw up, and we pay for
it. So nothing new there then.
> And in many cases, it seems some people here (mainly JGH) seem to
> think coders deliberately set out maliciously to have their programs
> work on only one configuration.
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.
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...
> Of course, Acorn adding system calls like "OS_UpdateMEMC" doesn't
> help.
Just 'cos it is there doesn't mean it is for playing with. ;-) Ditto
"OS_SetMemMapEntries" and ones with exciting names containing words like
"Delink", "Release" and "Claim".
> And then are amazed when people use it, they change the hardware
> (ie moving to slower ROMs) without compensating at all, and then
> loads of software stops running.
In fairness, the PRM (1-373) states only that UpdateMEMC fiddles around
with bits in the MEMC's control register. It does not say setting bit 6
is a cool way to gain a speed boost. I guess somebody discovered it, it
got published in AcornUser, then everybody thought "yeah!".
> Self-modifying code was hardly 'illegal' before 1996.
No, it wasn't. But then self-modifying code has never exactly been
something that wasn't frowned upon. I'm sure there are highly specialist
uses for self-modifying code, but to my mind once you're outside of core
kernel and low level device drivers, such things just make a simple job
difficult.
> 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?
> Technically this one's not Acorn's fault either, though they probably
> should have started the 32-bit transition a lot earlier.
Yes... like RISC OS 4 (which would have been what we now know as RISC OS
3.5, only in a 32 bit reworking).
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? Perhaps even they didn't think it as
being different enough to warrant a new number?
> Thankfully they went back to the drawing board, and ARM9 is what ARM8
> should have been - just several years later.
Ah, yes. I see. Well, that's good. I've a TI DSP chip in my PVR, runs an
ARM926 with some other number-cruncher stuff, and while it isn't quite
up to full frame PAL (it *can* handle it, just not while running an OS
as well, duh!), it records quite nicely in 640x480 with AAC [*] sound
(128kbit) and up to 2500kbit H.263 video. It's a nice bit of kit. I'm
not sure how much the ARM handles, and how much is DSP work, but it's
pretty impressive to think a DSP at ~100MHz and an ARM clocking twice
that can handle reasonable quality video recordings. I'm slaving the
thing of my satellite's S-video lead, so it actually records better than
I see when watching live on my computer (as the computer capture box
takes comp-sync).
The next generation of the same idea (bigger DSP, ARM at ~800MHz) is my
Android phone.
So I'm pleased to see the legacy which started with some 6502 design
considerations is doing so well in the world.
* - it can do MP3 too, but I find AAC better captures the audio.
> 1999 I believe (RISC OS 4). Though this is more crap design than
> anything else, and Acorn not showing a lot of forethought.
;-)
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!
>> 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?
One that used to annoy me was it was possible to decode a 1900-era time
from a FileStore with a failed battery. I'm not sure what or how, given
such a time is "illegal" in the Econet sense, however:
SYS "NetFS_DoFSOp", 16, fstime%, 5, 5
SYS "NetFS_ConvertDate", fstime%, rotime%
would cause a failure. The FileStore shouldn't return bogus dates, but I
guess it can. I'd like to think DoFSOp would sanitise results, but I
rather suspect it just passes data to and accepts from without much
intervention. I wonder if/how the 6502 MOSs cope with this.
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...