HDTenEightyP/NetNews huggingface dataset:
From: /G=Rhodri/S=James/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk
Subject: Re: TeX/Wimp/Morley SCSIFS/keyboardhandler
Organization: Yale CS Mail/News Gateway
Date: Wed, 30 Dec 1992 13:08:15 GMT

altman@cryton.demon.co.uk (Hugo Fiennes) writes:

>In article <ARM200-921222012210-5D147CDB*@MHS>
/G=Rhodri/S=James/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk writes:

[...]
>>It's possible I'm being very thick here, but what's the problem with just
>>issuing a Message_FilerOpenDir at the root of the relevant disc and letting
>>FileCore sort the mess out?

>Ah, but how do you get the nice disk name in the title of the filer window?
>You have to read it, then issue a opendir scsi::diskname.$ ... having
>windows topped with scsi::4.$ is a bit nasty, innit?

Ah, mea culpa.  I had been peeking at the NexusFiler source and thought the
Nexus_DescribeDiscs call was doing something important.  Sorry.

PS: Merry Christmas and a Happy New Year to everyone who hasn't been bored
silly by us!

---
Rhodri James                   *  Disclaimer:  These opinions are shareware,
SJ Research Ltd, Cambridge     *    and may only be used if you send off
Rhodri.James%gb.INTERSPAN.sj   *    $100 registration fee in used fivers.
            @mhs-relay.ac.uk   *    SJ Research is not registered with me.
   or                          *
rmj10@phx.cam.ac.uk            *             Wombats are go!
Newsgroups: comp.sys.acorn.tech
From: altman@cryton.demon.co.uk (Hugo Fiennes)
Subject: Re: Trouble with Morley SCSI card under RISC OS 3.10 
Distribution: world
Organization: The Serial Port
Reply-To: altman@cryton.demon.co.uk
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Fri, 25 Dec 1992 21:17:25 +0000

In article <724857612.3795@minster.york.ac.uk> mhw@minster.york.ac.uk writes:

>I've got slightly later versions of the software (1.08, 1.07 and 1.06
>from memory) on the support disk that comes with the card, but I can't
>seem to replace the modules downloaded from ROM with copies from the
>hard disk. The newly loaded SCSIFS just refuses to recognise the disk,
>giving "Please insert disk '...'" messages. Any ideas how to replace
>the older modules at boot time?
Yes: load them in this order:

rmload scsi::4.library.scsidriver
rmload scsi::4.library.scsifs
rmload scsi::4.library.scsifiler

Note the use of full pathnames and *no disknames* - when you load scsifs
it will have the effect of dismounting all SCSI disks, hence the insert
disk messages. Also, you have to load scsidriver than scsifs (or rmreinit
scsidriver then load scsifs) as scsifs locks your drive IDs so nothing
except scsifs can access them - reiniting scsifs ends up with scsifs not
being able to issue calls to scsidriver as it doesn't have the right access
key.

The latest versions are something like 1.10 for scsidriver, and 1.09 for
both the others I think.

Hugo

-----------------------------------------------------------------------------
                                     "Did I say that? My lips didn't move..."
Hugo Fiennes - The Serial Port                      altman@cryton.demon.co.uk
                                                or altman@cix.compulink.co.uk
-----------------------------------------------------------------------------
From: tjh@praxis.co.uk (Tim Huckvale)
Newsgroups: comp.sys.acorn.tech
Subject: Review: HCCS Colour Vision Digitiser
Summary: Magnus reviews a popular video digitiser
Keywords: Review HCCS video digitiser
Date: 22 Dec 92 09:42:11 GMT
Organization: Praxis, Bath, U.K.


  The HCCS Vision Digitiser produces pictures the same quality as most
digitised pictures I have seen.  The only problem I have come across is
horizontal 'lines' across colour pictures.  I think these lines have had
their Red, Green, and Blue components swopped around.  Normally you can use
!Paint to touch the image up by replacing these lines by copies of their
neighbours.  Gsrabbing the frame again sometimes lessens this effect.
  The only positive thing to be said about the software is that it works.
I appreciate that better software would be more expensive but I wouldn't
mind paying more money for better software.  Each picture can be processed
in monochrome or 2 levels of colour quality.  In mode 15 the two colour
options are indistinguishable but I suspect the difference can be seen in
mode 21.  Monochrome pictures are processed then shown, with colour
pictures you can see the picture build up line by line.  While the picture
is processing you can alter the brightness, contrast, and saturation values
- normally with the effect of making the picture look worse.  There is no
way to change Red, Green, and Blue levels, most of my pictures seem to look
too yellow - too much Red and Green.
  Pictures can be saved as a sprite or as a sprite, there is no facility
for saving un-processed pictures to be processed later, and only one frame
can be stored at a time - the only reason I mention this is that I would
like to be able to produce short animations.  The size of each sprite is
always chosen by the program (720 x 254 in mode 15, presumably 720 x 508 in
mode 21) and can only be grabbed in modes 15,21, or 28.  I needed 128 x 128
mode 13 sprites (For use in my 'demo' - The Colour of Risc - watch your PD
library) so I put the desktop in mode 13 and used !Paint to scale and
'Screenshot' the sprites.
  Documentation is not wonderful - a sheet showing how to install the thing
and a 10k 'edit' file.  The podule itself is well put together, the A3000
external one looks like an archimedies podule in a (cheap) box.  I only
call the box cheap because it has too many gaps and overlaps for my liking;
but considering that hard drive boxes cost nearly ten times as much, it is
good value for money.  On the circuit board are sockets for expansion chips
- presumably for 'HiVision' specification.
  Having said all that, I don't regret buying the HCCS vision digitiser as
more expensive digitisers are out of my budget.  The pictures are of high
enough quality for my requirements and I'm quite happy with it.

--
Magnus Huckvale

Posted by:
-- 
Tim H
From: andy@laguna.santafe.edu (Andy Mell)
Newsgroups: comp.sys.acorn.tech
Subject: Re: MicroEmacs 3.11c/RISCiX
Date: 28 Dec 92 20:59:24 GMT
Organization: Santa Fe Institute

In article <1hlfkeINNbu1@swan.doc.ic.ac.uk> mybg@doc.ic.ac.uk (M Y Ben Gershon) writes:
>RISCiX 1.21 comes with MicroEmacs 3.9.  It works in an xterm window, being
>resized whenever the window is resized.  I have tried without much success to
>get MicroEmacs 3.11c todo the same.  I can get it to work properly, but
>without responding to the xterm window being resized.  Having seen it work
>on oter systems, I cannot believe that this is a RISCiX 'exclusive'.  Does

Window resizing has nothing at all to do with termcap, you are mistaken, it
relies on a SIGWINCH signal being sent to the process when its window is
resized. The key to making microemacs refresh properly in a differently
sized window is to intercept SIGWINCH with signal() or other somesuch, 
obtain the window sizes and refresh.

It is more than likely you are not using the correct #defines, so go through
the source again, and find what #define that SIGWINCH use is conditional on.

Andy


-- 
-------------------------------------------------------------------------------
Andy Mell, Applied Physics Department,  |   andy@santafe.edu
University of Hull, Hull, HU7 6RX       |   amell@nyx.cs.du.edu
England.                                |   torq@gnu.ai.mit.edu
Newsgroups: comp.sys.acorn.tech
Subject: Re: adfsbuffers
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Tue, 22 Dec 1992 21:22:34 GMT
Organization: Computer Science Dept. University of Auckland

fl@tools.de (Frank Lancaster) writes:

>>   That is, I
>>   get the impression that setting a large value for ADFSBuffers will NOT
>>   have ANY effect on a SINGLE file, but using (e.g.) 256 buffers will allow
>>   up to 256 files to be buffered simultaneously.

>Actually adfsbuffers does have a dramatic effect on reading
>and writing a single file. Using my RISC OS tar for a large hard disc
>backup with compression, I normally set adfsbuffers to 255. Then
>writing to the disc happens in the background and the compression
>of a file can begin before the preceeding file has been completely
>written to disc. This also works under taskwindows, so you get
>somewhat better preemptive multitasking.

... you don't think, perhaps, that the significant improvement is due to
the fact that you are reading multiple files and writing to 1? And
that the more buffers you have, the more files can be buffered before
buffers have to be flushed?
Remember that read-buffers should make a difference if you're using a
FS that supoprts read-ahead...

Perhaps ADFSBuffers IS able to use more than 1 "1kB buffer" on a single
file (i.e. actually use a 256kB write buffer for a single file), but this
is not aparrent from the help on the configure option...

(Also, I would think that tar would be slightly different anyway, as it's
a C program, and if it uses stdio then it's likely that C would be
providing buffers, in which case, I would assume you're using setvbuf()
to allocate large I/O buffers in order to improve the throughput...)

Also, I have found with that sort of disc operation (reading, writing are
interleaved a lot) that a slight increase in buffer size can be all that
is needed to drop below the 'thrashing' threshold, and the amount of seeking
necessary drops considerably, thus speeding up the process a lot.
(With !CBAdecode, the difference between 4kB buffers and 16kB is amazing)
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)
From: fl@tools.de (Frank Lancaster)
Newsgroups: comp.sys.acorn.tech
Subject: Re: ObjAsm: Conditional Includes
Date: 21 Dec 92 13:45:57 GMT
Organization: Tools GmbH, Bonn, Germany
NNTP-Posting-Host: pierre.tools.de
In-reply-to: troeste@Mari.Unit.NO's message of Fri, 18 Dec 92 21:25:09 GMT


In article <1992Dec18.212509.7375@ugle.unit.no> troeste@Mari.Unit.NO (Trygve R|ste) writes:

>   There is a switch on cc (Acorn/Norcroft C) which turns off compilation
>   and linking, i.e. the preprocessor is the only part involved.
>   Then cc can be used as a preprocessor for ObjAsm files:
>
>    cc -E -o tmp.asmfile s.asmfil

I think Acorn's cc always inserts #line statements into the
preprocessed code. I wanted to use the preprocessor only mode
for something different than c but had to use a cpp on unix
instead because I couldn't use the #line statements.

-- Frank Lancaster, fl@tools.de
Newsgroups: comp.sys.acorn.tech
From: alla0008@student.tc.umn.edu (Graham Allan)
Subject: Re: adfsbuffers
Organization: University of Minnesota
Date: Wed, 30 Dec 1992 06:14:28 GMT

In article <FL.92Dec21130356@pierre.tools.de> fl@tools.de (Frank Lancaster) writes:
>
>Actually adfsbuffers does have a dramatic effect on reading
>and writing a single file. Using my RISC OS tar for a large hard disc
>backup with compression, I normally set adfsbuffers to 255. Then
>writing to the disc happens in the background and the compression
>of a file can begin before the preceeding file has been completely
>written to disc. This also works under taskwindows, so you get
>somewhat better preemptive multitasking.

I noticed this! Having just upgraded to RO3.1, I managed to do my
long-delayed HD backup with tar in a taskwindow. The best part was, it got
through all 70 floppies without a hitch! Under RO2, the machine would
always hang at some really annoying moment, like disc 20. It was also
noticably faster than under RO2.

Graham


Newsgroups: comp.sys.acorn.tech
From: /G=Rhodri/S=James/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk
Subject: Re: adfsbuffers
Organization: Yale CS Mail/News Gateway
Date: Tue, 22 Dec 1992 01:23:26 GMT

csudp@csv.warwick.ac.uk (Mr R E Broadley) writes:

>I have an A5000 with R3.0. I was told to set my adfsbuffers to 0K due to a bug
>in the OS, but this caused floppy disk read/write to be much too slow. What
>should I have my adfsbuffers set to?

0K due to a bug in the operating system.  You can set it to anything else if
you want to, but if you end up with a write-only filing system they did at
least tell you so.

As to why your floppy disc read/write should be slow, I'm not sure.  What is
your ADFSDirCache configured to?  How slow is "slow" anyway?  More
information, please!

---
Rhodri James                   *  Disclaimer:  These opinions are shareware,
SJ Research Ltd, Cambridge     *    and may only be used if you send off
Rhodri.James%gb.INTERSPAN.sj   *    $100 registration fee in used fivers.
            @mhs-relay.ac.uk   *    SJ Research is not registered with me.
   or                          *
rmj10@phx.cam.ac.uk            *             Wombats are go!
Newsgroups: comp.sys.acorn.tech
From: /G=Rhodri/S=James/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk
Subject: Re: TeX/Wimp/Morley SCSIFS/keyboardhandler
Organization: Yale CS Mail/News Gateway
Date: Tue, 22 Dec 1992 01:22:10 GMT

altman@cryton.demon.co.uk (Hugo Fiennes) writes:

>In article <1992Dec16.101159.26305@gate.esat.kuleuven.ac.be>
tytgat@esat.kuleuven.ac.be writes:

>>4. Has anyone noticed this "bug" in the Morley SCSIFS :
[...]
>>   Morley claims that the drive must be mounted each time the user clicks
>>   on the iconbar.  But ADFS doesn't mount the disc...
>>   Can anyone shed some light on this.  Is the behaviour of the Morley card
>>   normal ?
>It's the way morley do it - obviously they execute a dir or similar command
>to mount the disk, whereas the best way of causing filecore to mount the
>disk but not set the CSD is to do something like read the attributes of
>the $ directory object (what our filers do). I didn't know the morley
>software did it, I'll shout at Gary today, I have to call him anyway....

It's possible I'm being very thick here, but what's the problem with just
issuing a Message_FilerOpenDir at the root of the relevant disc and letting
FileCore sort the mess out?

---
Rhodri James                   *  Disclaimer:  These opinions are shareware,
SJ Research Ltd, Cambridge     *    and may only be used if you send off
Rhodri.James%gb.INTERSPAN.sj   *    $100 registration fee in used fivers.
            @mhs-relay.ac.uk   *    SJ Research is not registered with me.
   or                          *
rmj10@phx.cam.ac.uk            *             Wombats are go!
Newsgroups: comp.sys.acorn.tech
From: gtoal@cursci.demon.co.uk (Graham Toal)
Subject: TeX/Wimp/Morley SCSIFS/keyboardhandler 
Distribution: world
Organization: Current Drugs
Date: Wed, 23 Dec 1992 20:08:42 +0000


In article <1992Dec16.101159.26305@gate.esat.kuleuven.ac.be> tytgat@esat.kuleuven.ac.be writes:
>1. Is it possible to modify TeX so, that it uses the Risc OS
>   outline fonts ? I want to be able to convert a TeX file to
>   something readable without needing the whole TeX font set as
>   it takes up lots of space.

Yes, have you got a lot of TeX experience and two months spare?

You have to effectively turn TeX into a postscript version of TeX (actually,
it's worse than that because you don't have the full postscript font
layout - you have to turn TeX into an ISO8859/1 version of TeX) which
will take you a month, even starting with something like PSLatex,
then you'll have to modify the previewer.  This is actually the easier
bit because the previewer already uses native fonts (the approach I took
was to convert the TeX fonts to RiscOS rather than use a traditional
TeX bitmapped previewer).  You'll have to hack a IntMetrics->tfm
converter too.  But it can be done.  I'd say two weeks if you're keen.

Good luck.

Graham
PS Don't ask me for help.  The sources you need are all out there; anything
else I may have had is now gone.
From: blacka@logica.co.uk
Newsgroups: comp.sys.acorn.tech
Subject: Re: High res Colour Printing in RISC OS 3.1
Date: 21 Dec 92 23:41:58 GMT

As the instigator of this discussion, I would like to thank
everyone who's replied to it.  It has been an interesting
discussion, and I have learnt a lot about the subject.
I have  sucessfully set up the control codes for 360x180 
colour printing.  I accept that it takes a long time and
only use if when I feel it is needed.

A couple of points remain however :

- Owen is concerned about the ribbon becoming dirty 
  because of overprinting.  I would guess this is only a 
  problem with Y-interlace - for X interlace the driver
  does the two yellow passes, etc ending with black.  Am
  I correct here.

- I am confused as to whether and XB24 printer really prints
  to   360 resolution (or whether it skips a dot immediately
  after another dot).

  My XB24 manual is contradictory on this point.   In the 
  table of control codes (p58 if anyone has a copy) it 
  gives the impression that you can print every dot, whereas
  the spec on page 106 claims "Adjacacent dots not printable
  in these modes".   I suspect the latter is the case - 
  does anyone have any hard evidence.

Final point - I have noticed that the quality of Outline
Font printout is better under RISCOS3.1 than 2.  Previously
I found 180x180 was poor, 360x360 was needed.  Now I  find
that 180x180 is acceptable, and 360x180 when I need high
quality.  Could Owen shed any light on what has  be done
to obtain this  improvent 


Andrew Black
Newsgroups: comp.sys.acorn.tech
From: altman@cryton.demon.co.uk (Hugo Fiennes)
Subject: Re: TCP/IP 
Distribution: world
Organization: The Serial Port
Reply-To: altman@cryton.demon.co.uk
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Sun, 20 Dec 1992 22:21:43 +0000

In article <BzGryI.74s@cen.ex.ac.uk> CDLatham@cen.ex.ac.uk writes:

>In article <ARM200-921214130212-4DA1D7C*@MHS> /G=O
>wen/S=Smith/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk writes:
>
>[ ... about TCP/IP software problems ... ]
>

Another VT220 problem I saw was with the PF1-PF4 keys - eg key '#' (PF4)
This sends the PF4 code, then a # (not much use on a VAX....). If you
keep holding it, it just sends '#'es. mmmm.

Hugo
-- 
-----------------------------------------------------------------------------
                                     "Did I say that? My lips didn't move..."
Hugo Fiennes - The Serial Port                      altman@cryton.demon.co.uk
                                                or altman@cix.compulink.co.uk
-----------------------------------------------------------------------------
From: fl@tools.de (Frank Lancaster)
Newsgroups: comp.sys.acorn.tech
Subject: Re: adfsbuffers
Date: 21 Dec 92 14:03:56 GMT
	<1992Dec20.011534.5366@cs.aukuni.ac.nz>
Organization: Tools GmbH, Bonn, Germany
NNTP-Posting-Host: pierre.tools.de
In-reply-to: jwil1@cs.aukuni.ac.nz's message of 20 Dec 92 01:15:34 GMT

In article <1992Dec20.011534.5366@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:

>   That is, I
>   get the impression that setting a large value for ADFSBuffers will NOT
>   have ANY effect on a SINGLE file, but using (e.g.) 256 buffers will allow
>   up to 256 files to be buffered simultaneously.
>   A value like 8 or 16 will probably be plenty - this will allow pretty much
>   all the files you ca expect to be open at any time to be buffered.

Actually adfsbuffers does have a dramatic effect on reading
and writing a single file. Using my RISC OS tar for a large hard disc
backup with compression, I normally set adfsbuffers to 255. Then
writing to the disc happens in the background and the compression
of a file can begin before the preceeding file has been completely
written to disc. This also works under taskwindows, so you get
somewhat better preemptive multitasking.

Alas there seems to be some kind of bug in the filing system as
it sometimes causes the machine to hang (and that gets really awful
if the disc maps are just being written). So if I'm doing a complete
backup of my hard disc I use the raw disc writing option in tar
which uses ADFS_DiscOp and avoids adfsbuffers.

-- Frank Lancaster, fl@tools.de
Newsgroups: comp.sys.acorn.tech
From: /G=Owen/S=Smith/O=SJ-Research/ADMD=INTERSPAN/C=GB/@mhs-relay.ac.uk
Subject: Armadillo 16 bit sound sampler
Organization: Yale CS Mail/News Gateway
Date: Sat, 19 Dec 1992 21:30:22 GMT

Today I upgraded a friend's A310 (4MB RAM, ARM3, Watford ST506, Acorn SCSI 
+ CDFS, IOTA Scanner, Watford ArchiTablet) to RISC OS 3.10. Most things 
work fine, but one thing that doesn't is the Armadillo 16 bit sound 
sampler. According to Malcom, Armadillo went out of business some time ago 
so he can't ring them up to ask them about it. The symptoms are that when 
starting !Highnote, you either get a total machine hang, a "Branch through 
zero at location &3812CA4", or an "Internal error". (You have to start it 
in mode 12 to even get this far.) Does anyone know what the problem is, 
how to fix it, or know of anyone who might know? Has any other company 
picked up the rights to the Armadillo kit?

The Watford ArchiTablet doesn't work either (it claims the tablet isn't
plugged in to the serial port) but Malcolm is going to contact Watford 
about that.

Owen.
From: fl@tools.de (Frank Lancaster)
Newsgroups: comp.sys.acorn.tech
Subject: Re: adfsbuffers
Date: 23 Dec 92 15:14:47 GMT
Organization: Tools GmbH, Bonn, Germany
	<FL.92Dec21130356@pierre.tools.de>
	<1992Dec22.212234.2185@cs.aukuni.ac.nz>
NNTP-Posting-Host: pierre.tools.de
In-reply-to: jwil1@cs.aukuni.ac.nz's message of Tue, 22 Dec 1992 21:22:34 GMT


In article <1992Dec22.212234.2185@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:

>   ... you don't think, perhaps, that the significant improvement is due to
>   the fact that you are reading multiple files and writing to 1? And
>   that the more buffers you have, the more files can be buffered before
>   buffers have to be flushed?
>   Remember that read-buffers should make a difference if you're using a
>   FS that supoprts read-ahead...

No. I'm reading one file and writing another. The writing process is improved
a lot. Especially performance when large files are written to the archive 
is improved. If I have set adfsbuffers to 255 and a file of 100KB is written to
the archive, the writing routine returns immediately and the next file gets
read and compressed while the writing process to the archive continues
in the background.

The C file routines obviously at some point get translated to OS_GPBP
calls, so they are also influenced by adfsbuffers.

-- Frank Lancaster, fl@tools.de
Newsgroups: comp.sys.acorn.tech
From: amclintock@cix.compulink.co.uk ("Cray Communications, Alex McL")
Subject: Re: Draw -> DXF Conversion
Reply-To: amclintock@cix.compulink.co.uk
Date: Thu, 24 Dec 1992 10:53:00 +0000


>  draw->dxf ???

> please respond to Glenda Graham <GGraham@acorn.co.uk>
> or Alvi Fernandez <AFernandez@acorn.co.uk>

Hey I thought Acorn did dxf import into Draw! Of course
I have never seen it work - even though I have tried
several times. Surely someone in Acorn knows enough
about dxf to do one themselves....

Isn't it one big case statement? bet you could 
write it in awk or perl  ;-)

AlexMC
From: mybg@doc.ic.ac.uk (M Y Ben Gershon)
Newsgroups: comp.sys.acorn.tech
Subject: MicroEmacs 3.11c/RISCiX
Date: 27 Dec 1992 23:52:46 -0000
Organization: Department of Computing, Imperial College, University of London, UK.
NNTP-Posting-Host: swan.doc.ic.ac.uk

RISCiX 1.21 comes with MicroEmacs 3.9.  It works in an xterm window, being
resized whenever the window is resized.  I have tried without much success to
get MicroEmacs 3.11c todo the same.  I can get it to work properly, but
without responding to the xterm window being resized.  Having seen it work
on oter systems, I cannot believe that this is a RISCiX 'exclusive'.  Does
anyone know what flags i ought to be setting to get it to work?  Before you all
say use TERMCAP, you ought to know that it doesn't work, as the xterm and avc
termcap entries both have li and co commented out, and MicroEmacs responds
with a message that the screen is too small.  I guess that some interreaction
with termcap is likely, as the binary distributed with RISCiX has the Micro-
Emacs termcap file compiled.

Manybe someone at Aocrn who knows about RISCiX can help?

Michael Ben-Gershon
mybg@doc.ic.ac.uk

Newsgroups: comp.sys.acorn.tech