Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!hughesmp
From: hughesmp@vax1.tcd.ie
Newsgroups: comp.sys.acorn,eunet.micro.acorn
Subject: Re: Archimedes Suggestions
Message-ID: <1991Feb13.161140.7781@vax1.tcd.ie>
Date: 13 Feb 91 16:11:40 GMT
References: <1991Feb11.124128.2990@cns.umist.ac.uk>
Organization: Trinity College Dublin
Lines: 55

In article <1991Feb11.124128.2990@cns.umist.ac.uk>, vanaards%t7@uk.ac.man.cs writes:
> 
>      There seems to be a trend in these discussions as to what we'd like
>   to see in a new Archimedes machine. Well I'll add to this :
> 
>   Presently there is NO way of undeleting a file - this is a MAJOR mistake.
>   If you're in business & you accidently delete your current work file 
>   you've no way of recovering it other that hacking the disk. But with
>   DOS based systems there's no hassle, I've seem many undelete programs.

This _is_ a major problem, I agree. Is this such a big problem with ADFS? I
don't know enough about ADFS to do anything about it, but shouldn't it be
just a case of editing a small bit of the directory to mark the file as not
deleted, or does ADFS physically delete info about the file... If not, it
would just be a case of someone who knew about ADFS writing a small utility.

>   Why place the Econet roms in the machines OS as standard ? How many users
>   actually use Econet. As Acorn consider schools,etc as their main market
>   this may seem good policy - but why not move them off to a podule ?

The machine has too few podule ports to make this a viable option IMHO. The
hardware, which would be the main cost, isn't supplied, just a small amount
of the OS. Is that such a big problem? I'm sure even still, there's some space
left over... Even if there isn't, its just a case of plugging in more ROMs, 
like RISCOS3 to put more in, so it's not actually reducing facilities
available...

>   The MEMC chip needs to be replaced, I believe that the current page size
>   is far too large - this is apparent on UNIX boxes.

Someone mentionned MEMC2... I dunno if this fixes that.

>   I'd like to see faster screen updates regardless of mode. Now I haven't
>   any sound ideas on how this should be done - perhaps a second bus and
>   screen memory, or a BLITTER chip ?

Yes, I _want_ direct screen memory access for the VIDC. On the Amiga, you
can have up to 5 bitplanes and 4 channels of music going, without impinging
on the speed of the machine at all; the relevant chips just use direct
access to the memory, and so you don't have the problems the Arc does, of
going at under half speed in a big mode, with music. A Blitter chip would
similarly need direct memory access; unfortunately however, it would have
to be a _very_ fast blitter, ie an ARM coprocessor or something, to be able
to viably compete with just getting the processor to do whatever you wanted
itself; as it is, the ARM2 can shift 4 * the memory than the Amigas blitter, 
I believe. The Amiga 3000 has a similar problem of the processor outdoing the
blitter.

The best thing I think Acorn (VLSI?) could do on a hardware scale, is get this
direct memory access thingy; it would double the speed of the Arc for a lot of
applications, without being too costly.. OSwise, there are a fair load
of things that could be done, but I reckon they did a fairly good job of it on
the whole.

T.