Dont put !Scrap in a RAM disc
druck
recall seeing it mentioned here a few times, that people are still
putting !Scrap in RAM, and are suffering slow start up times of
applications and other problems which could easily be avoided.
Putting !Scrap in a RAM disc is an archaic practice dating back to the
use of RISC OS 2 and floppy discs, where to transfer data between
applications, you would have to reinsert the system disc containing !Scrap.
These days it's not beneficial and bad practice for at least 4 reasons:-
1) Applications mainly use RAM transfer for exchanging data between
each other, so already work faster than disc, and also faster than a
RAM disc.
2) Some applications such as Photodesk may need to store 100MB or more
of data when processing large images. A static RAM disc is unlikely
to be this large, and even if using a dynamic RAM disc such as MemFS
the memory would be far better used directly by the application. In
the image cache in the case of Photodesk.
3) The RAM disc on the Iyonix actually has a lower peak transfer rate
than the ATA 100 disc!
4) Some applications store transient data in !Scrap, which can be
regenerated, but takes additional time at startup, e.g. the rufl
font cache used by NetSurf.
---druck
Christopher Self
druck <ne...@druck.freeuk.com> wrote:
> These days it's not beneficial and bad practice for at least 4 reasons:-
> 1) Applications mainly use RAM transfer for exchanging data between
> each other, so already work faster than disc, and also faster than a
> RAM disc.
> 2) Some applications such as Photodesk may need to store 100MB or more
> of data when processing large images. A static RAM disc is unlikely
> to be this large, and even if using a dynamic RAM disc such as MemFS
> the memory would be far better used directly by the application. In
> the image cache in the case of Photodesk.
> 3) The RAM disc on the Iyonix actually has a lower peak transfer rate
> than the ATA 100 disc!
> 4) Some applications store transient data in !Scrap, which can be
> regenerated, but takes additional time at startup, e.g. the rufl
> font cache used by NetSurf.
> ---druck
None of those reasons are worth anything to a user like me. I don't even
know what the first one means.
--
Christopher Self
Rob Kendrick
Christopher Self <cs...@btinternet.com> wrote:
> In article <gvo8ub$931$1...@news.eternal-september.org>,
> druck <ne...@druck.freeuk.com> wrote:
> > These days it's not beneficial and bad practice for at least 4
> > reasons:-
>
> > 1) Applications mainly use RAM transfer for exchanging data between
> > each other, so already work faster than disc, and also faster
> > than a RAM disc.
>
> > 2) Some applications such as Photodesk may need to store 100MB or
> > more of data when processing large images. A static RAM disc is
> > unlikely to be this large, and even if using a dynamic RAM disc
> > such as MemFS the memory would be far better used directly by the
> > application. In the image cache in the case of Photodesk.
>
> > 3) The RAM disc on the Iyonix actually has a lower peak transfer
> > rate than the ATA 100 disc!
>
> > 4) Some applications store transient data in !Scrap, which can be
> > regenerated, but takes additional time at startup, e.g. the rufl
> > font cache used by NetSurf.
>
>
> None of those reasons are worth anything to a user like me. I don't
> even know what the first one means.
Then trust that druck is right. (He is, incidentally :)
B.
Chris Evans
Yes there are circumstances where having !Scrap on a RAM disc is a bad idea.
I have about 3 of the 10 odd computers here set up with !Scrap on a RAM disc
They run some things noticably faster, and as none of the circumstances
above apply there is no downside.
If you'r not sure if any of them apply to you then yes you should not put
!Scrap into RAM.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Rob Kendrick
Chris Evans <ch...@cjemicros.co.uk> wrote:
> Yes there are circumstances where having !Scrap on a RAM disc is a
> bad idea.
>
> I have about 3 of the 10 odd computers here set up with !Scrap on a
> RAM disc
>
> They run some things noticably faster, and as none of the
> circumstances above apply there is no downside.
>
> If you'r not sure if any of them apply to you then yes you should not
> put !Scrap into RAM.
They most likely won't run noticeably faster if they're Iyonixes :) My
suggestion is that if you're having to resort like hacks like this to
get performance, it might be time to upgrade.
(Plus, it means cached data cannot be used across boots, slowing down
not just NetSurf's start time, but web browsing and other things, too.)
B.
Steve Fryatt
<5063065...@btinternet.com>:
> In article <gvo8ub$931$1...@news.eternal-september.org>,
> druck <ne...@druck.freeuk.com> wrote:
> > These days it's not beneficial and bad practice for at least 4 reasons:-
>
> > 1) Applications mainly use RAM transfer for exchanging data between
> > each other, so already work faster than disc, and also faster than a
> > RAM disc.
Most apps don't use the Scrap protocol for cut and paste or drag and drop
between documents these days, instead using the RAM Transfer protocol. This
is probably more efficient, and even if it isn't, it means that moving Scrap
to a RAM disc won't actually speed up such transfers anyway since they
often don't use Scrap at all.
> > 2) Some applications such as Photodesk may need to store 100MB or more
> > of data when processing large images. A static RAM disc is unlikely
> > to be this large, and even if using a dynamic RAM disc such as MemFS
> > the memory would be far better used directly by the application. In
> > the image cache in the case of Photodesk.
If you have Scrap on a RAM disc, and something tries to store a large amount
of data in Scrap (which is one of the things that Scrap can be used for), then
it will either fail (lack of memory), or use up valuable RAM.
Another good example would be PrintPDF. This stores intermediate data in
postscript format inside Scrap. If you use it to print a "big" document on a
machine with Scrap in RAM, you could easily hit problems. Note that the
source document or resulting PDF don't actually have to be that large to give
difficulties, either -- PS files can be surprisingly big on occasion.
> > 3) The RAM disc on the Iyonix actually has a lower peak transfer rate
> > than the ATA 100 disc!
Your hard disc is faster than the RAM disc. That is, moving Scrap from your
hard disc to your RAM disc could actually slow the machine down!
> > 4) Some applications store transient data in !Scrap, which can be
> > regenerated, but takes additional time at startup, e.g. the rufl
> > font cache used by NetSurf.
Some of the data stored in Scrap can be usefully used the next time the
machine is powered up again. Deleting its contents every time, as happens
with a RAM disc, means that this data has to be recreated every time you use
the machine -- which slows you down.
> None of those reasons are worth anything to a user like me. I don't
> even know what the first one means.
Just because you don't know what they mean, doesn't mean that they don't apply
to you... :-)
And yes, I'd also suggest not deleting the contents of Scrap unless you know
what you're doing.
--
Steve Fryatt - Leeds, England
Peter Naulls
> It came to my attention in a post on the NetSurf mailing list, and I
> recall seeing it mentioned here a few times, that people are still
> putting !Scrap in RAM, and are suffering slow start up times of
> applications and other problems which could easily be avoided.
[snip]
Very sage. I took the liberty of adapting this for the riscos.info
wiki:
http://www.riscos.info/index.php/Putting_Scrap_on_a_RAM_Disc
If SF wants to reword this, he's more than welcome ;-)
druck
> Very sage. I took the liberty of adapting this for the riscos.info
> wiki:
>
> http://www.riscos.info/index.php/Putting_Scrap_on_a_RAM_Disc
Thanks, I must remember to add some things there myself at some point.
---druck
Martin Bazley
> In article <20090529135...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <URL:mailto:nn...@rjek.com> wrote:
> > On Fri, 29 May 2009 13:04:15 +0100
> > Christopher Self <cs...@btinternet.com> wrote:
> >
> > > In article <gvo8ub$931$1...@news.eternal-september.org>,
> > > druck <ne...@druck.freeuk.com> wrote:
> > > > These days it's not beneficial and bad practice for at least 4
> > > > reasons:-
> > >
> > > None of those reasons are worth anything to a user like me. I don't
> > > even know what the first one means.
> >
> > Then trust that druck is right. (He is, incidentally :)
>
> Yes there are circumstances where having !Scrap on a RAM disc is a bad idea.
>
> I have about 3 of the 10 odd computers here set up with !Scrap on a RAM disc
>
> They run some things noticably faster, and as none of the circumstances
> above apply there is no downside.
>
> If you'r not sure if any of them apply to you then yes you should not put
> !Scrap into RAM.
>
How on earth does one put !Scrap into a RAM disc anyway? Do you issue a
complex set of commands in your PreDesk file to regenerate the directory
structure each startup?
--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
Steve Fryatt
<b9ec9a63...@freeuk.com>:
> How on earth does one put !Scrap into a RAM disc anyway? Do you issue
> a complex set of commands in your PreDesk file to regenerate the
> directory structure each startup?
Pretty much, yes (although for 'complex commands', read '*Copy'). Or you
would use something like the late Paul Vigay's MiscSetup to do it for you.
Either way, I don't see that it's worth the effort.
Jim Lesurf
<ch...@cjemicros.co.uk> wrote:
> Yes there are circumstances where having !Scrap on a RAM disc is a bad
> idea.
> I have about 3 of the 10 odd computers here set up with !Scrap on a RAM
> disc
I've been copying !Scrap to ram for use at startup for years. No real
problems so far as I can tell. Easy enough to allows this to include the
files that NetSurf likes to have. Since I don't use Photodesk, and set the
ram to 100MB I haven't had any problems.
One advantage is that the size of all the bumf that otherwise tends to left
'orphaned' in !Scrap doesn't increase with time since any new items get
dumped at switchoff. Perhaps the name 'Scrap' here is a clue. :-)
> If you'r not sure if any of them apply to you then yes you should not
> put !Scrap into RAM.
Agreed. If someone finds that using !Scrap on ramdisc gives them problems,
then they should use it on their HD.
Slainte,
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Steve Fryatt
<d9b8006...@poppy-land.fslife.co.uk>:
> In message <aa2a9e63...@helvellyn.stevefryatt.org.uk>
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > On 30 May, Martin Bazley wrote in message
> > <b9ec9a63...@freeuk.com>:
> >
> > > How on earth does one put !Scrap into a RAM disc anyway? Do you issue
> > > a complex set of commands in your PreDesk file to regenerate the
> > > directory structure each startup?
> >
> > Pretty much, yes (although for 'complex commands', read '*Copy'). Or you
> > would use something like the late Paul Vigay's MiscSetup to do it for you.
> >
> > Either way, I don't see that it's worth the effort.
>
> Or use Memphis, and just tick a box...
The same reservations still apply, though. I've just printed a document that
dumped a 22M file into Scrap on its way though the printing system. Add
that to the memory requirements of the originating software (Ovation Pro)
and GhostScript to do the downstream conversion to PDF, then if that were in a
RiscPC with even 128Mb of RAM things could start to get tight quite easily.
I still don't see the point, in these days of fast, big, hard discs.
Steve Fryatt
<5063a21...@audiomisc.co.uk>:
> In article <ant29134...@client.cjemicros.co.uk>, Chris Evans
> <ch...@cjemicros.co.uk> wrote:
>
> > Yes there are circumstances where having !Scrap on a RAM disc is a
> > bad idea.
>
> > I have about 3 of the 10 odd computers here set up with !Scrap on a RAM
> > disc
>
> I've been copying !Scrap to ram for use at startup for years. No real
> problems so far as I can tell. Easy enough to allows this to include the
> files that NetSurf likes to have. Since I don't use Photodesk, and set the
> ram to 100MB I haven't had any problems.
Since you're using an Iyonix, Druck's information would suggest that this
could be slowing your machine down...
> One advantage is that the size of all the bumf that otherwise tends to left
> 'orphaned' in !Scrap doesn't increase with time since any new items get
> dumped at switchoff. Perhaps the name 'Scrap' here is a clue. :-)
Can anyone show that this 'orphaned' data actually causes problems in normal
day-to-day usage? On this machine, Scrap is a tiny fraction of the hard disc
size.
> > If you'r not sure if any of them apply to you then yes you should not
> > put !Scrap into RAM.
>
> Agreed. If someone finds that using !Scrap on ramdisc gives them problems,
> then they should use it on their HD.
I think the worry is that the problems may be subtle, and may be attributed to
other causes (giving headaches to third-party developers who could then
receive bug reports for their software as a result).
Tim Hill
<ne...@stevefryatt.org.uk> wrote:
[Snip]
> Can anyone show that this 'orphaned' data actually causes problems in
> normal day-to-day usage?
Dunno. I thought the only reason for !Scrap on a 'yonix RAM disc was to
serve some feelings of paranoia which I don't suffer from so have never
bothered. Did try doing this from Memphis out of curiosity for a while
but ended up discarding that app (Memphis) because it gave something else
indigestion. Not because of scrap though.
> On this machine, Scrap is a tiny fraction of
> the hard disc size.
If half a gig on a 114 gig hard drive is considered a 'tiny' fraction I
would agree but with only 7 gig free it may become an issue before long.
Never mind the size of a drive - it is the available free space which is
more of an issue.
[Snip]
--
Better Telecoms: http://tinyurl.com/phone-coop
Genuine and spam-proof addresses for Usenet: www.invalid.org.uk
Email address for replies: substitute postmaster@ for tim@
... "They do not love that do not show their love" Two G of V, Act i, Sc.2
Steve Fryatt
<506406...@invalid.org.uk>:
> In article <973f0364...@helvellyn.stevefryatt.org.uk>, Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
>
> > On this machine, Scrap is a tiny fraction of the hard disc size.
>
> If half a gig on a 114 gig hard drive is considered a 'tiny' fraction I
> would agree but with only 7 gig free it may become an issue before long.
150MByte on a 160GByte drive with 41GByte free. I don't think that's an
issue. :-)
druck
> I've been copying !Scrap to ram for use at startup for years. No real
> problems so far as I can tell.
We could go back over your news postings and heck...
> One advantage is that the size of all the bumf that otherwise tends to left
> 'orphaned' in !Scrap doesn't increase with time since any new items get
> dumped at switchoff. Perhaps the name 'Scrap' here is a clue. :-)
Then have a period clean out. A good time is just before taking your
backups - which of course you do regularly.
---druck
Jim Lesurf
<ma...@poppyland.plu$.com.invalid> wrote:
> In message <aa2a9e63...@helvellyn.stevefryatt.org.uk> Steve Fryatt
> <ne...@stevefryatt.org.uk> wrote:
> > On 30 May, Martin Bazley wrote in message
> > <b9ec9a63...@freeuk.com>:
> >
> > > How on earth does one put !Scrap into a RAM disc anyway? Do you
> > > issue a complex set of commands in your PreDesk file to regenerate
> > > the directory structure each startup?
> >
> > Pretty much, yes (although for 'complex commands', read '*Copy'). Or
> > you would use something like the late Paul Vigay's MiscSetup to do it
> > for you.
> >
> > Either way, I don't see that it's worth the effort.
> >
> Or use Memphis, and just tick a box...
I did it by simply creating an application directory that I called
"!RamScrap" and then put into it a Obey file with the name "!Run" that
contains the two lines
Copy ADFS::HardDisc4.$.!Boot.Resources.!Scrap RAM::RamDisc0.$.!Scrap
RF~C~V
Filer_Run RAM::RamDisc0.$.!Scrap
I then put !RamScrap in the list of apps to run at bootup.
On my Iyonix I normally have the ramdisc sized at 100MB.
For the reasons people have mentioned, I would not specifically recommend
this as you may hit snags. But it works OK for me and I've not yet seen any
problems that have made me stop using !Scrap on ramdisc.
Tim Hill
<no...@audiomisc.co.uk> wrote:
> For the reasons people have mentioned, I would not specifically
> recommend this as you may hit snags. But it works OK for me and I've
> not yet seen any problems that have made me stop using !Scrap on
> ramdisc.
However, if ever you think you find a bug in software that nobody else
seems to experience you must always consider whether your chosen location
for Scrap is the cause. Why introduce a variable which may cause problems
particularly the limit you have imposed on its size?
Though I know a motoring analogy will bring this thread to an end, ;-)
imagine you have two tankfuls of of fuel which cost the same but one will
be worse than everyone else's, run out sooner, make your car slower and
misfire occasionally. The other lasts as long as your engine does and is
faster and just as reliable as everyone else's. Which would you chose?
Why? Just to be different?
Theo Markettos
> However, if ever you think you find a bug in software that nobody else
> seems to experience you must always consider whether your chosen location
> for Scrap is the cause. Why introduce a variable which may cause problems
> particularly the limit you have imposed on its size?
There's a bug in Memphis - it works fine for a while, and then randomly
decides to give an abort whenever you try to read or write. It happens
rarely and seemingly randomly, so I've never worked out a set of
circumstances to cause it to happen. It's existed since Memphis 2 which
used the system sprite area rather than a dynamic area.
I've experienced it just downloading random zipfiles from the web - nothing
to do with !Scrap.
Theo
S G
> There's a bug in Memphis - it works fine for a while, and then randomly
> decides to give an abort whenever you try to read or write. It happens
> rarely and seemingly randomly, so I've never worked out a set of
> circumstances to cause it to happen. It's existed since Memphis 2 which
> used the system sprite area rather than a dynamic area.
Is this Memphis 3.03 (28 Apr 2005)?
--
Stewart Goldwater
http://janusg.co.nr
Bryn Evans
A simple one line utility to clean out !Scrap.
I call it "Scrape" -
Its an "Obey" file, and I use it about once a month.
The only drawback is the Font rescan next time NetSurf is used.
| Wipe Scrap files !!
|
Wipe <Wimp$ScrapDir>.* ~cfr~v
|
| from Acorn User - 980320
--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com
Chris Evans
<URL:mailto:d...@a.invalid> wrote:
> In a mad moment - druck mumbled :
>
> > Peter Naulls wrote:
> >> Very sage. I took the liberty of adapting this for the riscos.info
> >> wiki:
> >>
> >> http://www.riscos.info/index.php/Putting_Scrap_on_a_RAM_Disc
>
> > Thanks, I must remember to add some things there myself at some point.
>
> A simple one line utility to clean out !Scrap.
>
> I call it "Scrape" -
> Its an "Obey" file, and I use it about once a month.
> The only drawback is the Font rescan next time NetSurf is used.
>
> | Wipe Scrap files !!
> |
> Wipe <Wimp$ScrapDir>.* ~cfr~v
> |
> | from Acorn User - 980320
I wonder if you could put a rename[1] before and after the wipe command that
moved the relevant directory to outside Wimp$ScrapDi
[1] on the desktop it is easy but I'm not sure if rename or another command
will do this!
After a quick test I can say *rename will do this!
Theo Markettos
> Is this Memphis 3.03 (28 Apr 2005)?
Ah, no, just checked and I was on 3.00 beta 4 (5 Oct 2004). Just downloaded
3.03. Do you know if this bug has been fixed? There's mention of some
changes in the help file, but nothing that looks immediately obvious.
Theo
Tony Moore
> S G <nws...@ntlworld.com> wrote:
> > Is this Memphis 3.03 (28 Apr 2005)?
>
> Ah, no, just checked and I was on 3.00 beta 4 (5 Oct 2004). Just
> downloaded 3.03. Do you know if this bug has been fixed?
http://www.richardspencer.freeuk.com/memphis3/ says that
There have been reports of problems with the 'Imitate RamFS' option
set and system Shutdown. This occurs on RISC OS 3.7/5.0x but not RISC
OS 4/Select/Adjust. The symptom is an address exception within the
MessageTrans module followed by the Task Manager quitting when a
Shutdown is initiated. For now I suggest only using 'Imitate RamFS'
when running programs which are hardwired to 'RAM::RamDisc0.$', and
remember to OK the option off before shutting down the computer.
Hopefully for RISC OS 5 this problem will disappear when the Adjust32
MessageTrans finds its way into the source tree.
I've been using Memphis 3.03 (28 Apr 2005) since it was released, with
RO 4.39 through 6.16, and have not found any problems - however, I don't
keep scrap there.
Tony
S G
> Just downloaded 3.03. Do you know if this bug has been fixed?
Dunno, but I don't think I've seen it.
I note in passing that Memphis is Open Source.
John Williams (News)
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Do you know if this bug has been fixed? There's mention of some
> changes in the help file, but nothing that looks immediately obvious.
Never happened to me!
John
--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/ Somewhere nice to stay in Brittany? http://petit.four.free.fr/visitors/locate
Chris Evans
> Chris Evans <ch...@cjemicros.co.uk> wrote:
>
> > Yes there are circumstances where having !Scrap on a RAM disc is a
> > bad idea.
> >
> > I have about 3 of the 10 odd computers here set up with !Scrap on a
> > RAM disc
> >
> > They run some things noticably faster, and as none of the
> > circumstances above apply there is no downside.
> >
> > If you'r not sure if any of them apply to you then yes you should not
> > put !Scrap into RAM.
>
> They most likely won't run noticeably faster if they're Iyonixes :) My
> suggestion is that if you're having to resort like hacks like this to
> get performance, it might be time to upgrade.
Ah but I'm just a poor RISC OS dealer. Also I regularly use a computer both
downstairs and upstairs here at work as well as at home so I'd really need to
update 3 computers!
I wouldn't want to lose the Select features I rely on, so I'll have to wait
for the A9home's firmware update and a lottery win! As I don't do the
lottery I may have a long wait!
> (Plus, it means cached data cannot be used across boots, slowing down
> not just NetSurf's start time, but web browsing and other things, too.)
Apart from the fonts issue what other caching does NetSurf do?
I thought it was normal to clear all caches on exit, especially with
web browsers.
Rob Kendrick
Chris Evans <ch...@cjemicros.co.uk> wrote:
> > (Plus, it means cached data cannot be used across boots, slowing
> > down not just NetSurf's start time, but web browsing and other
> > things, too.)
>
> Apart from the fonts issue what other caching does NetSurf do?
> I thought it was normal to clear all caches on exit, especially with
> web browsers.
Thumbnailing certainly; I don't recall if it caches web objects like
images, etc; but many other browsers under RISC OS do.
B.
Ollie Clark
I certainly remember ArcWeb caching images and I'm pretty sure I had it
set up to cache the actual web pages as well (I've got a feeling there was
a seperate web cache application).
Theo Markettos
> http://www.richardspencer.freeuk.com/memphis3/ says that
>
> There have been reports of problems with the 'Imitate RamFS' option
> set and system Shutdown. This occurs on RISC OS 3.7/5.0x but not RISC
> OS 4/Select/Adjust. The symptom is an address exception within the
> MessageTrans module followed by the Task Manager quitting when a
> Shutdown is initiated. For now I suggest only using 'Imitate RamFS'
> when running programs which are hardwired to 'RAM::RamDisc0.$', and
> remember to OK the option off before shutting down the computer.
> Hopefully for RISC OS 5 this problem will disappear when the Adjust32
> MessageTrans finds its way into the source tree.
No, that's not it. I don't use Imitate RamFS, nor do I put Scrap there, or
have problems on shutdown, and no problems with MessageTrans. I'm fairly
sure it's corruption of the filing system, as it happened on Memphis 2. I
simply download random things using Netsurf and put them in Memphis. On a
rare occasion Memphis will refuse to let me read or write files on it,
giving an abort. Memphis keeps on running, but uselessly if you can't put
files in or out. As I say, it happens at random so I can't repeat it enough
to look into it. FWIW I'm on RO4.39.
Will try 3.03 and see how it goes.
Theo
Dave Higton
Chris Evans <ch...@cjemicros.co.uk> wrote:
> I wouldn't want to lose the Select features I rely on, so I'll have to wait
> for the A9home's firmware update and a lottery win! As I don't do the
> lottery I may have a long wait!
Oh dear. That's not a vote of confidence, is it?
Dave
Paul Stewart
Martin Bazley <mar...@bazley.freeuk.com> wrote:
> How on earth does one put !Scrap into a RAM disc anyway? Do you issue a
> complex set of commands in your PreDesk file to regenerate the directory
> structure each startup?
It's a configurable feature on Memphis.
Regards
--
Paul Stewart - Far Bletchley, Milton Keynes, England.
(msn:pauls...@phawfaux.co.uk)
Chris Evans
Err!
Correct in that I have no confidence in winning the lottery especially as I
don't enter it!
or are you meaning something else or did you missread it?
David Pitt
> In article <92fa396550...@dsl.pipex.com>, Dave Higton
> <URL:mailto:daveh...@dsl.pipex.com> wrote:
> > In message <ant02091...@client.cjemicros.co.uk>
> > Chris Evans <ch...@cjemicros.co.uk> wrote:
> >
> > > I wouldn't want to lose the Select features I rely on, so I'll have to
> > > wait for the A9home's firmware update and a lottery win! As I don't do
> > > the lottery I may have a long wait!
> >
> > Oh dear. That's not a vote of confidence, is it?
>
> Err!
>
> Correct in that I have no confidence in winning the lottery especially as
> I don't enter it!
Some of us may not have much confidence in the A9home firmware update
arriving either.
At the moment it would be quite nice to have a fully compos mentis A9home as
it finds itself in use here now given the failure of VRPC following a recent
Mac OS upgrade. (With OS X 10.5.7 VRPC may not verify its validity, it may
do so after a Mac reboot but so far today there is no such joy. The advice
is not to upgrade but I already had by the time that was issued.)
--
David Pitt
Tony Moore
> In article <92fa396550...@dsl.pipex.com>, Dave Higton
> <URL:mailto:daveh...@dsl.pipex.com> wrote:
> > In message <ant02091...@client.cjemicros.co.uk>
> > Chris Evans <ch...@cjemicros.co.uk> wrote:
> >
> > > I wouldn't want to lose the Select features I rely on, so I'll
> > > have to wait for the A9home's firmware update and a lottery win!
> > > As I don't do the lottery I may have a long wait!
> >
> > Oh dear. That's not a vote of confidence, is it?
>
> Err!
>
> Correct in that I have no confidence in winning the lottery especially
> as I don't enter it!
>
> or are you meaning something else or did you missread it?
One could infer that you anticipate a long wait for the A9home's
firmware update.
Tony
Chris Evans
Well the inference would be wrong, reference to the A9home was in a
different sentence.
With the launch of the vPod a significant technical step has been made to
bring RISC OS 6 and its new kernal to the A9home.
I do see light at the end of the tunnel:-)
Ollie Clark
>
> With the launch of the vPod a significant technical step has been made to
> bring RISC OS 6 and its new kernal to the A9home.
Could you expand on that? I don't follow.
> I do see light at the end of the tunnel:-)
Excellent! Not that I can really justify buying one with the amount
I use RO these days.
Cheers,
Ollie
Rob Kendrick
Ollie Clark <use...@ollieclark.com> wrote:
> Chris Evans wrote:
> >
> > With the launch of the vPod a significant technical step has been
> > made to bring RISC OS 6 and its new kernal to the A9home.
>
> Could you expand on that? I don't follow.
One of the moving targets for getting more "modern" RISC OSes onto the
A9 was the video abstraction layer. The Vpod and the A9 Home use the
same graphics accelerator, so one assumes they've caught up with the
target, and thus one fewer item on the to do list.
B.
Tony Moore
> In article <460d916550.old_coaster@old_coaster.yahoo.co.uk>, Tony
> Moore <URL:mailto:old_c...@yahoo.co.uk> wrote:
> > On 3 Jun 2009, Chris Evans <ch...@cjemicros.co.uk> wrote:
> > > In article <92fa396550...@dsl.pipex.com>, Dave Higton
> > > <URL:mailto:daveh...@dsl.pipex.com> wrote:
> > > > In message <ant02091...@client.cjemicros.co.uk>
> > > > Chris Evans <ch...@cjemicros.co.uk> wrote:
> > > >
> > > > > I wouldn't want to lose the Select features I rely on, so I'll
> > > > > have to wait for the A9home's firmware update and a lottery
> > > > > win! As I don't do the lottery I may have a long wait!
> > > >
> > > > Oh dear. That's not a vote of confidence, is it?
> > >
> > > Err!
> > >
> > > Correct in that I have no confidence in winning the lottery
> > > especially as I don't enter it!
> > >
> > > or are you meaning something else or did you missread it?
> >
> > One could infer that you anticipate a long wait for the A9home's
> > firmware update.
>
> Well the inference would be wrong, reference to the A9home was in a
> different sentence.
Your second sentence precludes a lottery win, leaving a long wait for
the firmware, mentioned in the first sentence.
> With the launch of the vPod a significant technical step has been made
> to bring RISC OS 6 and its new kernal to the A9home.
>
> I do see light at the end of the tunnel:-)
I'm pleased that my inference was not correct. I may well be one of your
future customers, but I would prefer to buy a finished product.
Tony
Ollie Clark
I knew that. I was wondering why it took a second product using the
accelerator to get the video abstraction layer working for it.
Unless Chris just meant that the release of the Vpod was an indicator
that they had finished the work and not that the work was done as a
result of the Vpod.
Anway, good news that the A9 will be getting RO6 in the near future.
It was a bit worrying that there weren't any machines available with
an up to date version of the OS.
Rob Kendrick
Ollie Clark <use...@ollieclark.com> wrote:
> > One of the moving targets for getting more "modern" RISC OSes onto
> > the A9 was the video abstraction layer. The Vpod and the A9 Home
> > use the same graphics accelerator, so one assumes they've caught up
> > with the target, and thus one fewer item on the to do list.
>
> I knew that. I was wondering why it took a second product using the
> accelerator to get the video abstraction layer working for it.
It didn't.
> Unless Chris just meant that the release of the Vpod was an indicator
> that they had finished the work and not that the work was done as a
> result of the Vpod.
It's certainly an indicator that they have a driver for one of the
complex parts working for the GPU in question, which is certainly
progress.
B.
Chris Evans
<URL:mailto:use...@ollieclark.com> wrote:
> Rob Kendrick wrote:
> > On 04 Jun 2009 13:16:14 GMT
> > Ollie Clark <use...@ollieclark.com> wrote:
> >
> >> Chris Evans wrote:
> >> >
> >> > With the launch of the vPod a significant technical step has been
> >> > made to bring RISC OS 6 and its new kernal to the A9home.
> >>
> >> Could you expand on that? I don't follow.
> >
> > One of the moving targets for getting more "modern" RISC OSes onto the
> > A9 was the video abstraction layer. The Vpod and the A9 Home use the
> > same graphics accelerator, so one assumes they've caught up with the
> > target, and thus one fewer item on the to do list.
>
> I knew that. I was wondering why it took a second product using the
> accelerator to get the video abstraction layer working for it.
>
> Unless Chris just meant that the release of the Vpod was an indicator
> that they had finished the work and not that the work was done as a
> result of the Vpod.
I don't understand that.
The RISC OS 6 kernal deals with hardware interrupts in a different way from
previously, all A9home hardware specific parts of the OS that use interrupts
(i.e. most if not all) needed changing.
One of the problems was that almost
To get a machine that would boot to debug all of them need changing at the
same time. Getting the video side working via vPod goes a long way towards
achieving RO6 kernal booting on the A9home.
> Anway, good news that the A9 will be getting RO6 in the near future.
> It was a bit worrying that there weren't any machines available with
> an up to date version of the OS.
>