Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.misc > #5877 > unrolled thread

Unipod query

Back to article view | Back to comp.sys.acorn.misc

Contents

  Unipod query Chris Newman <cvjazz@waitrose.com> - 2012-07-17 09:30 +0100
    Re: Unipod query "David Holden" <SpamBin@apdl.co.uk> - 2012-07-17 09:06 +0000
      Re: Unipod query Chris Newman <cvjazz@waitrose.com> - 2012-07-17 17:34 +0100
        Re: Unipod query Brian Carroll <bric-nospam@argonet.co.uk> - 2012-07-17 20:05 +0100
          Re: Unipod query Chris Newman <cvjazz@waitrose.com> - 2012-07-18 12:56 +0100
            Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-21 00:31 +0100
              Re: Resurrected RiscPC "David Holden" <SpamBin@apdl.co.uk> - 2012-07-21 05:39 +0000
                Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-21 12:29 +0100
                  Re: Resurrected RiscPC "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-21 14:05 +0100
                    Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-21 18:09 +0100
                      Re: Resurrected RiscPC Russell Hafter News <see.sig@walkingingermany.invalid> - 2012-07-21 18:56 +0100
                        Re: Resurrected RiscPC "Bruce Goatly" <ss4@goatly.co.uk> - 2012-07-21 19:19 +0100
                          Re: Resurrected RiscPC "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-21 20:26 +0100
                            Re: Resurrected RiscPC Stuart <Spambin@argonet.co.uk> - 2012-07-22 14:46 +0100
                          Re: Resurrected RiscPC Russell Hafter News <see.sig@walkingingermany.invalid> - 2012-07-21 21:39 +0100
                        Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-22 13:53 +0100
                          Re: Resurrected RiscPC "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-22 15:09 +0100
                          Re: Resurrected RiscPC Fred Bambrough <fred@[127.0.0.1]> - 2012-07-23 16:36 +0100
                      Re: Resurrected RiscPC "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-21 20:22 +0100
                        Re: Resurrected RiscPC Brian Howlett <news-spamtrap@brianhowlett.me.uk> - 2012-07-22 10:03 +0100
                          Re: Resurrected RiscPC "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-22 11:09 +0100
                Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-23 11:29 +0100
                  Re: Resurrected RiscPC John Sandford <lists@thesandfords.me.uk> - 2012-07-23 16:28 +0100
                    Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-23 18:27 +0100
                      Re: Resurrected RiscPC Steve Fryatt <news@stevefryatt.org.uk> - 2012-07-23 20:38 +0100
                        Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-23 22:25 +0100
                          Re: Resurrected RiscPC "David Holden" <SpamBin@apdl.co.uk> - 2012-07-24 06:03 +0000
                            Re: Resurrected RiscPC spampling <spam.pling@btinternet.com> - 2012-07-24 07:49 +0100
                              Re: Resurrected RiscPC Stuart <Spambin@argonet.co.uk> - 2012-07-24 12:23 +0100
                            Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-24 21:08 +0100
                              Re: Resurrected RiscPC Dave Higton <dave@davehigton.me.uk> - 2012-07-24 22:05 +0100
                                Re: Resurrected RiscPC Chris Newman <cvjazz@waitrose.com> - 2012-07-24 22:36 +0100
    Re: Unipod query Tony Moore <old_coaster@yahoo.co.uk> - 2012-07-25 16:40 +0000
      Re: Unipod query "David Holden" <SpamBin@apdl.co.uk> - 2012-07-26 08:34 +0000
        Re: Unipod query "Dave Plowman (News)" <dave@davenoise.co.uk> - 2012-07-26 10:22 +0100
        Re: Unipod query Tony Moore <old_coaster@yahoo.co.uk> - 2012-07-26 10:15 +0000
      Re: Unipod query Chris Newman <cvjazz@waitrose.com> - 2012-07-26 10:22 +0100

Page 2 of 2 — ← Prev page 1 [2]

#5899 — Re: Resurrected RiscPC

In article <ae2131b352.Brian@bhowlett.plus.net>,
   Brian Howlett <news-spamtrap@brianhowlett.me.uk> wrote:
> On 21 Jul, Dave Plowman (News) wrote:

> > IPA will be fine.

> Indeed. And there are so many nice ones to choose from!

;-)

But not strong enough for cleaning things. I've used Vodka on tape heads
in an emergency, though.

-- 
*Why don't you ever see the headline "Psychic Wins Lottery"?

    Dave Plowman        dave@davenoise.co.uk           London SW
                  To e-mail, change noise into sound.

[toc] | [prev] | [next] | [standalone]

#5911 — Re: Resurrected RiscPC

In article <a6utk4FggjU1@mid.individual.net>,
   David Holden <SpamBin@apdl.co.uk> wrote:

> On 21-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:

<snip>

> > I've got a RiscPC working after a fashion. 
> > Memory test failed Phase 1 fail at &00ABB430 with &98612D2D instead of
> > &B8612D2D There were &00000053 failures in total
> >
> There's your problem. You've either got duff RAM, dirty contacts or C32
> still present on a series 1 or 2 motherboard. You're wasting your time
> faffing about with anything else until you sort this out.

Thanks, Dave. It was duff RAM. Now sorted. What a weird collection of faults
that gave rise to. Even Paint doesn't ask for the colour picker now, Why duff
memory should stop a module loading I have no idea. No matter. All seems well
now.

What still puzzles me is that the drives that originally reported errors that
everybody told me marked their death, I can now access quite happily & will
use them as back ups.

I didn't have a c32. My motherboard number is 1208. Is there a way of
matching these numbers to which series the motherboard is? Had a Google but
couldn't find a list.

I've sorted System variable not found - USBDeviceDriver$Path (internal error
code 120). I had forgotten to tick the options in Configure USB when I
installed Adjust for the second time.

I now seem to have a fully working RiscPC. Fingers crossed!!!!

Many thanks to all who offered advice along the way.

-- 
Chris Newman

[toc] | [prev] | [next] | [standalone]

#5913 — Re: Resurrected RiscPC

Chris Newman <cvjazz@waitrose.com> wrote:

> In article <a6utk4FggjU1@mid.individual.net>,
>    David Holden <SpamBin@apdl.co.uk> wrote:
> 
> > On 21-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:
> 
> <snip>
> 
> > > I've got a RiscPC working after a fashion. Memory test failed Phase 1
> > > fail at &00ABB430 with &98612D2D instead of &B8612D2D There were
> > > &00000053 failures in total
> > >
> > There's your problem. You've either got duff RAM, dirty contacts or C32
> > still present on a series 1 or 2 motherboard. You're wasting your time
> > faffing about with anything else until you sort this out.
> 
> Thanks, Dave. It was duff RAM. Now sorted. What a weird collection of
> faults that gave rise to. Even Paint doesn't ask for the colour picker
> now, Why duff memory should stop a module loading I have no idea. No
> matter. All seems well now.

Modules load into memory ! as does all the applications/data you use.


-- 
John Sandford
home

[toc] | [prev] | [next] | [standalone]

#5916 — Re: Resurrected RiscPC

In article <mpro.m7mdo3000bx0y04eo.lists@thesandfords.me.uk>,
   John Sandford <lists@thesandfords.me.uk> wrote:
> Chris Newman <cvjazz@waitrose.com> wrote:

> > In article <a6utk4FggjU1@mid.individual.net>,
> >    David Holden <SpamBin@apdl.co.uk> wrote:
> > 
> > > On 21-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:
> > 
> > <snip>
> > 
> > > > I've got a RiscPC working after a fashion. Memory test failed Phase 1
> > > > fail at &00ABB430 with &98612D2D instead of &B8612D2D There were
> > > > &00000053 failures in total
> > > >
> > > There's your problem. You've either got duff RAM, dirty contacts or C32
> > > still present on a series 1 or 2 motherboard. You're wasting your time
> > > faffing about with anything else until you sort this out.
> > 
> > Thanks, Dave. It was duff RAM. Now sorted. What a weird collection of
> > faults that gave rise to. Even Paint doesn't ask for the colour picker
> > now, Why duff memory should stop a module loading I have no idea. No
> > matter. All seems well now.

> Modules load into memory ! as does all the applications/data you use.

Only one bank of the memory was duff - 32 out of the 96MB. Wouldn't they use
the bit that was still available? Also, if you have memory SIMMS of different
values, does it matter which goes in which slot? Likewise, does it matter
with ROMS?

Yours in ignorance,

-- 
Chris Newman

[toc] | [prev] | [next] | [standalone]

#5917 — Re: Resurrected RiscPC

On 23 Jul, Chris Newman wrote in message
    <52b3e32898cvjazz@waitrose.com>:

> Only one bank of the memory was duff - 32 out of the 96MB. Wouldn't they
> use the bit that was still available?

How does the OS know that it's duff?  Unless it were to do a full write-read
check (which takes as long as MemCheck, and therefore isn't practical) then
it has no idea.

> Also, if you have memory SIMMS of different values, does it matter which
> goes in which slot?

No.

> Likewise, does it matter with ROMS?

Yes, IIRC.

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[toc] | [prev] | [next] | [standalone]

#5919 — Re: Resurrected RiscPC

In article <mpro.m7mp8d01xmn7401ju.news@stevefryatt.org.uk>,
   Steve Fryatt <news@stevefryatt.org.uk> wrote:
> On 23 Jul, Chris Newman wrote in message
>     <52b3e32898cvjazz@waitrose.com>:

> > Only one bank of the memory was duff - 32 out of the 96MB. Wouldn't they
> > use the bit that was still available?

> How does the OS know that it's duff?  Unless it were to do a full write-read
> check (which takes as long as MemCheck, and therefore isn't practical) then
> it has no idea.

I take the point. Although it always seemed to be the same modules failing so
they must always be trying access the same bit of memory ie the duff bit.

> > Also, if you have memory SIMMS of different values, does it matter which
> > goes in which slot?

> No.

Ta.

> > Likewise, does it matter with ROMS?

> Yes, IIRC.

IIRC, my 3.7 ROMS weren't numbered or differentiated in any way but the
Adjust 4.39 were.

-- 
Chris Newman

[toc] | [prev] | [next] | [standalone]

#5920 — Re: Resurrected RiscPC

On 23-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:

> IIRC, my 3.7 ROMS weren't numbered or differentiated in any way but the
> Adjust 4.39 were.

That's because Acorn never intended them to be a 'user upgrade' unlike all
the ROL ROMs and RO 3.1 so they just had a part number instead of ROM 1, ROM
2, etc. Though, of course, they did become an upgrade when people fitted
Strong ARMs to their RPC 700s.

If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01. Similarly
with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#5922 — Re: Resurrected RiscPC

In article <a76s5hF4seU1@mid.individual.net>, David Holden
<SpamBin@apdl.co.uk> wrote:
> If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01.
> Similarly with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.

Only to new RISC OS users, the rest tend to have varifocal lenses these
days - me included.

-- 

Steve Pampling

[toc] | [prev] | [next] | [standalone]

#5923 — Re: Resurrected RiscPC

In article <52b42c82dfspam.pling@btinternet.com>,
   spampling <spam.pling@btinternet.com> wrote:
> In article <a76s5hF4seU1@mid.individual.net>, David Holden
> <SpamBin@apdl.co.uk> wrote:
> > If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01.
> > Similarly with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.

> Only to new RISC OS users, the rest tend to have varifocal lenses these
> days - me included.

I'm on bi-focals but with a single prescription pair to the "reading"
prescription, which I wear most of time when I'm at home.

-- 
Stuart Winsor

Only plain text for emails
http://www.asciiribbon.org

[toc] | [prev] | [next] | [standalone]

#5925 — Re: Resurrected RiscPC

In article <a76s5hF4seU1@mid.individual.net>,
   David Holden <SpamBin@apdl.co.uk> wrote:

> On 23-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:

> > IIRC, my 3.7 ROMS weren't numbered or differentiated in any way but the
> > Adjust 4.39 were.

> That's because Acorn never intended them to be a 'user upgrade' unlike all
> the ROL ROMs and RO 3.1 so they just had a part number instead of ROM 1, ROM
> 2, etc. Though, of course, they did become an upgrade when people fitted
> Strong ARMs to their RPC 700s.

> If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01. Similarly
> with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.

Thanks, Dave. Just as a belt & braces check, which goes in which slot?
No 1 should be in the rear slot in all versions?

-- 
Chris Newman

[toc] | [prev] | [next] | [standalone]

#5926 — Re: Resurrected RiscPC

In message <52b475b87fcvjazz@waitrose.com>
          Chris Newman <cvjazz@waitrose.com> wrote:

> In article <a76s5hF4seU1@mid.individual.net>,
>   David Holden <SpamBin@apdl.co.uk> wrote:
> 
> > On 23-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:
> 
> > > IIRC, my 3.7 ROMS weren't numbered or differentiated in any way but the
> > > Adjust 4.39 were.
> 
> > That's because Acorn never intended them to be a 'user upgrade' unlike
> > all the ROL ROMs and RO 3.1 so they just had a part number instead of ROM
> > 1, ROM 2, etc. Though, of course, they did become an upgrade when people
> > fitted Strong ARMs to their RPC 700s.
> 
> > If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01.
> > Similarly with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.
> 
> Thanks, Dave. Just as a belt & braces check, which goes in which slot? No 1
> should be in the rear slot in all versions?

If it's going at all, you've got them the right way round.

Dave

[toc] | [prev] | [next] | [standalone]

#5927 — Re: Resurrected RiscPC

In article <dff27ab452.DaveMeUK@my.inbox.com>, Dave Higton
<dave@davehigton.me.uk> wrote:
> In message <52b475b87fcvjazz@waitrose.com> Chris Newman
>           <cvjazz@waitrose.com> wrote:

> > In article <a76s5hF4seU1@mid.individual.net>, David Holden
> >   <SpamBin@apdl.co.uk> wrote:
> > 
> > > On 23-Jul-2012, Chris Newman <cvjazz@waitrose.com> wrote:
> > 
> > > > IIRC, my 3.7 ROMS weren't numbered or differentiated in any way but
> > > > the Adjust 4.39 were.
> > 
> > > That's because Acorn never intended them to be a 'user upgrade' unlike
> > > all the ROL ROMs and RO 3.1 so they just had a part number instead of
> > > ROM 1, ROM 2, etc. Though, of course, they did become an upgrade when
> > > people fitted Strong ARMs to their RPC 700s.
> > 
> > > If you look at the numbers, ROM 1 is 191-01 and ROM 2 is 192-01.
> > > Similarly with RO 3.6 it's 101-01 and 102-01. Pretty obvious really.
> > 
> > Thanks, Dave. Just as a belt & braces check, which goes in which slot? No
> > 1 should be in the rear slot in all versions?

> If it's going at all, you've got them the right way round.

Still some problems with icons but I'm tracking those down to MenuBar &/or
Larger so seemingly no problem with ROMS.

Cheers,

-- 
Chris Newman

[toc] | [prev] | [next] | [standalone]

#5932

On 17 Jul 2012, Chris Newman <cvjazz@waitrose.com> wrote:

[snip]

> Is there any speed (or other) advantage to having the main Hard Disc 4
> connected via my Unipod as opposed to the main mother board? I looked
> in Archive for an article about the Unipod and any comparative data
> but couldn't find one.

I've now been able to test my RiscPC/Unipod. Identical Seagate 40GB
ST340015A drives are installed on the motherboard ADFS, and on the
Unipod IDEFS. The results, below, were produced by HDspeed v1.30.

   Byte access test,                          ADFS    IDEFS    IDEFS
   large file size = 8 MB                    c-sec    c-sec    /ADFS

      Read 50K sequential bytes                  8.9     33.4   3.75
      Write 50K sequential bytes                41       61     1.49
      Read 500K sequential bytes               297      342     1.15
      Write 500K sequential bytes              645      631     0.98
      50 KB file read 1,000 random bytes        28      276     9.86
      50 KB file write 1,000 random bytes      358     1657     4.63
      Large file read 1,000 random bytes       950      907     0.95
      Large file write 1,000 random bytes     2711     1650     0.61
                                                       Mean     2.93

   Block Load/Save,                           ADFS    IDEFS    IDEFS
   large file size = 8 MB                   KB/sec   KB/sec    /ADFS

      Save 50Kb file                           956     1543     1.61
      Load 50Kb file                          1515     1612     1.06
      Save large block file                   1624     2507     1.54
      Load large block file                   1890     2832     1.50
      Save/load 50 KB file                    1179     1865     1.58
      Save/load 512 KB file                   1473     2216     1.50
      Save/load large block file              1743     2661     1.53
                                                       Mean     1.48

The first group of tests show that, for byte access, IDEFS is, on
average, more than 60% _slower_ than ADFS.

The second group of tests show that, for load/save operations, IDEFS is,
on average, about 50% faster than ADFS.

Tony

[toc] | [prev] | [next] | [standalone]

#5937

On 25-Jul-2012, Tony Moore <old_coaster@yahoo.co.uk> wrote:

[results not reproduced for brevity]

> The first group of tests show that, for byte access, IDEFS is, on
> average, more than 60% _slower_ than ADFS.
>
> The second group of tests show that, for load/save operations, IDEFS is,
> on average, about 50% faster than ADFS.

The byte access speed increase is well known and is because ADFS has
buffered byte read/write.

With our IDE interfaces we did address this with a version which had
buffering and this was a bit faster than ADFS. However this caused problems
with high speed access, and proved incompatible with DMA, so we reverted to
unbuffered in/out. This gives maximum data transfer for larger files, i.e.
95% of stuff, and if someone is using a program which does a lot of byte
access and which they use frequently then if maximum speed is important just
put the data files for that program on an ADFS disc.

We did make a special buffered version with no DMA available at one time for
people for whom this was the primary requirement.

I presume similar problems were encountered by Simtec with the Unipod.

BTW the results I get for larger file transfer on a Unipod are quite a bit
faster than the ones you show.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#5939

In article <a7cdovFtmqU1@mid.individual.net>,
   David Holden <SpamBin@apdl.co.uk> wrote:
> BTW the results I get for larger file transfer on a Unipod are quite a
> bit faster than the ones you show.

How does Unipod compare with Blitz? I have two similar machines, one with
Unipod, one with Blitz. Blitz *seems* faster in general use. But I don't
have a test prog to prove it.

-- 
*I don't have a solution, but I admire your problem. *

    Dave Plowman        dave@davenoise.co.uk           London SW
                  To e-mail, change noise into sound.

[toc] | [prev] | [next] | [standalone]

#5940

On 26 Jul 2012, "David Holden" <SpamBin@apdl.co.uk> wrote:
> On 25-Jul-2012, Tony Moore <old_coaster@yahoo.co.uk> wrote:
>
> [results not reproduced for brevity]
>
> > The first group of tests show that, for byte access, IDEFS is, on
> > average, more than 60% _slower_ than ADFS.
> >
> > The second group of tests show that, for load/save operations, IDEFS
> > is, on average, about 50% faster than ADFS.
>
> The byte access speed increase is well known and is because ADFS has
> buffered byte read/write.

Thanks for the explanation.

> With our IDE interfaces we did address this with a version which had
> buffering and this was a bit faster than ADFS. However this caused
> problems with high speed access, and proved incompatible with DMA, so
> we reverted to unbuffered in/out. This gives maximum data transfer for
> larger files, i.e. 95% of stuff, and if someone is using a program
> which does a lot of byte access and which they use frequently then if
> maximum speed is important just put the data files for that program on
> an ADFS disc.

Where is likely to be the best location for !Boot?

> We did make a special buffered version with no DMA available at one
> time for people for whom this was the primary requirement.
>
> I presume similar problems were encountered by Simtec with the Unipod.
>
> BTW the results I get for larger file transfer on a Unipod are quite a
> bit faster than the ones you show.

Could the difference be explained by fragmentation? My IDEFS 40GB drive
is a mirror of the ADFS 40GB drive, and both are about 55% full, having
been in use for several years. I carried out the speed tests twice, each
time with near identical results.

Tony

[toc] | [prev] | [next] | [standalone]

#5938

In article <a07fe6b452.old_coaster@old_coaster.yahoo.co.uk>,
   Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 17 Jul 2012, Chris Newman <cvjazz@waitrose.com> wrote:

> [snip]

> > Is there any speed (or other) advantage to having the main Hard Disc 4
> > connected via my Unipod as opposed to the main mother board? I looked
> > in Archive for an article about the Unipod and any comparative data
> > but couldn't find one.

> I've now been able to test my RiscPC/Unipod. Identical Seagate 40GB
> ST340015A drives are installed on the motherboard ADFS, and on the
> Unipod IDEFS. The results, below, were produced by HDspeed v1.30.

>    Byte access test,                          ADFS    IDEFS    IDEFS
>    large file size = 8 MB                    c-sec    c-sec    /ADFS

>       Read 50K sequential bytes                  8.9     33.4   3.75
>       Write 50K sequential bytes                41       61     1.49
>       Read 500K sequential bytes               297      342     1.15
>       Write 500K sequential bytes              645      631     0.98
>       50 KB file read 1,000 random bytes        28      276     9.86
>       50 KB file write 1,000 random bytes      358     1657     4.63
>       Large file read 1,000 random bytes       950      907     0.95
>       Large file write 1,000 random bytes     2711     1650     0.61
>                                                        Mean     2.93

>    Block Load/Save,                           ADFS    IDEFS    IDEFS
>    large file size = 8 MB                   KB/sec   KB/sec    /ADFS

>       Save 50Kb file                           956     1543     1.61
>       Load 50Kb file                          1515     1612     1.06
>       Save large block file                   1624     2507     1.54
>       Load large block file                   1890     2832     1.50
>       Save/load 50 KB file                    1179     1865     1.58
>       Save/load 512 KB file                   1473     2216     1.50
>       Save/load large block file              1743     2661     1.53
>                                                        Mean     1.48

> The first group of tests show that, for byte access, IDEFS is, on
> average, more than 60% _slower_ than ADFS.

> The second group of tests show that, for load/save operations, IDEFS is,
> on average, about 50% faster than ADFS.

Oooh! Swings & roundabouts, what?
Thanks for doing that. Most interesting. I wonder which would be better for
overall use. I suppose it would depend on what you mostly use the machine for.

Regards,

-- 
Chris Newman

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.misc

csiph-web