HDTenEightyP/NetNews huggingface dataset:
From: smb@cs.nott.ac.uk (Simon Burrows)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: Need help with the newcastle info-server
Date: 5 Nov 92 11:12:19 GMT
Organization: Nottingham University

In article <1d88sdINN1oq@oak7.doc.ic.ac.uk> ijp@doc.ic.ac.uk (Ian Palmer) writes:
>
>It's on Simon Burrows' armpdlist :
>
>!AGP            advanced graph plotter v1.62 [260K]...............Ben Harris
>
>so I guess that it must be PD/Shareware, but it's not available on any
>servers that I know of.

It's quite a neat desktop graph plotting program, although it only does
relatively simple stuff (the author is currently doing A-Levels). It
includes the documentation in text file and Impression format.

I'll dig it out and post a copy to the relevant places.

Simon/
------------------------------------------------------------------------------
Simon Burrows   smb@cs.nott.ac.uk  psyhsmb@unicorn.nott.ac.uk  +44 533 712030
------------------------------------------------------------------------------
From: rsxdp@unicorn.nott.ac.uk (D.Pead)
Newsgroups: comp.sys.acorn.advocacy
Subject: Replay vs. Quicktime
Date: 5 Nov 92 10:25:12 GMT
Organization: Shell Centre for Maths Education , University of Nottingham

I'm currently at work re-writing an educational package  designed for
LaserVision to run on the Arc using Acorn  Replay, so I've been mildly
interested in the QuickTime  vs. Replay flame war.
  

Well, I've just seen a demonstration of QuickTime 
and it really is an excellent product, with just two minor  problems:

1: It can't display full-motion video, and
2: It can't display full-motion video.

I know that, strictly speaking, that is only one point,  but I thought
that it was so fundamental that I'd mention  it twice. :-)

Quicktime has a lot going for it:

* You can buy a VideoSpigot card into which you can plug a  video camera
and use wonderfully friendly software to grab  and compress your own
movies.  You can't do that using  Replay.

* You can edit your movies and add effects, wipes  soundtracks and
titles with lovely bits of software like  Adobe Premiere.  The only
thing I've seen that comes close  to this on the arc is the Eidos
editing system, which is  an expensive system aimed at video editors
and doesn't (as  yet) use Replay.

* Quicktime multitasks, buttons on the screen are still  active, you can
overlap quicktime windows and choose from  several image sizes.  You
can even paste movies into  WordPerfect.  (I can't for the life of me
think WHY you'd  want to do this, but you can).

I'd even say that the picture quality in Quicktime movies  - at least,
the quality of the individual frames - was  better than Replay, probably
because of the better colour graphics on macs.

But, even on a Quadra 900 running from hard disc, the  picture was
being updated too slowly to produce convincing  motion video.  A
person walking across the room moved in a  series of jerks.  A person
speaking to camera looked  ridiculous - although technically the sound
was in step,  there was no sense of "Lip-Sync" whatsoever.  When the 
picture was enlarged to any more than thumbnail size, you  could
actually see the screen being updated from top to  bottom.

The people demonstrating QuickTime were working on the  educational
possibilities of  pupils creating multimedia  presentations, possibly
incorporating their own videos.   As far as I know,  QT is the only
economical way of doing  this at the moment.  Sending video off to a
compression  agency at 100 quid a minute is not an option.

I'm trying to produce a package which incorporates  professionally
produced  film (FILM!!!)  on CD.  For this,  having the computer
update the picture when and if it has  a spare moment is not an
option. 

I think the point here is that QuickTime and Replay are really 
designed for different jobs.
From: microsoc@ox.ac.uk (Robin Watts)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 13 Nov 92 10:41:31 GMT
	<1992Nov9.001953.23918@cs.aukuni.ac.nz>
	<1992Nov9.163934.18398@news2.cis.umn.edu>
	<2xKgM-j025n@khantazi.welly.gen.nz>
Organization: /u3/microsoc/users/rjw/.organization
In-reply-to: banksie@khantazi.welly.gen.nz's message of 11 Nov 92 23:47:31 GMT

In article <2xKgM-j025n@khantazi.welly.gen.nz> banksie@khantazi.welly.gen.nz (Philip R. Banks) writes:

>      I suspect this is the case. However it would be nice if the timeslicing
>   with TaskWindows only occured on Null events. The backgrounding would be
>   much smoother.
>
>       Philip

I spent a fun few hours poking round inside TaskWindows the other day, using
Sarah[1]. As far as I can make out the only messages TaskWindow receives are

1) Nulls
2) Key Pressed
3) Mouse Clicked
4) Messages (17,18,19) - Only the Taskwindow specific ones.

Now because of this surely we don't mind it taking a time slice on each of
these, with the possible exception of KeyPressed and Mouseclicked. I suspect
the major slow down is through using Edit to display the output, but we will
soon know, as !Zap[2] is to have a taskwindow mode...

As a matter of interest, can anyone tell me why Taskwindow needs to get
Keypressed and Mouseclicked messages? Surely these are unnecessary because
of the way the system works?

Robin

[1] Sarah: Incredibly useful module - Disassembles, and allows you to track
through Arm Code, plus loads of other lovely useful stuff.

[2] Zap: Text-Editor extrordinaire - Loads in about 38K as a module, and
does everytyhing any other editor does on the Arc, with redefinable keys,
with faster redraw than the wimps block-copy functions...

Both of the above are by Dom Symes, and are available off newcastle.
Newsgroups: comp.sys.acorn.advocacy
From: davism@uhura.aston.ac.uk (Mik Davis)
Subject: Re: The ARM Club
Organization: Aston University
Date: Fri, 13 Nov 1992 17:18:16 GMT

About co-operative vs Pre-emtive multitasking...

  What would happen if someone were to try and come up with a system which had
a RiscOS-like front end (i.e. co-operative) but which had a pre-emptive back-end
for chucking jobs into the background or running a "batch" job?


-- 
___________________________________________.
 Mik Davis at Aston University, Birmingham |   .  .  __          .
                                           |   |\/|  | \  _,_  _  _
E-Mail: davism@uhura.aston.ac.uk           |   |  |. |_/ |_| \/ |/_'
From: banksie@khantazi.welly.gen.nz (Philip R. Banks)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: Tue, 10 Nov 1992 11:17:47 +1300
Reply-To: banks_p@kosmos.wcc.govt.nz
Organization: My Arc.

sproven@cs.strath.ac.uk (Simon B Proven IE91) writes:

> One program I would like to have is a program which monitors the load of
> all currently running processes, and thus can provide an easy way to
> see which programs take lots of time, and when.  This would then allow
> programmers to optimise their code for the GUI better.  Maybe I'll write
> it myself one of these day....

   Try Ran Mokady's Useage program for RO3. It lists every task currently
activte whether they are 'blocked' or not (I think, it has been a while
since I read the help file) and how much CPU it uses. Ran made a minor
mistake with it when he released it, it requires a wimpslot of 32k *not* 16k
as indicated in the original run file. If you give it exactly 16k it doesn't
work.

    Philip

--
Philip R. Banks  Syntax: mail < banks_p@kosmos.wcc.govt.nz >            @@@@@/|
Moving swiftly throught the waters, Cannons blazing as she came,        @@@@/#|
Brought a might metal War Lord, Crashing down in sheets of flame,       @@@/##|
Thinking fortune must have smiled, People started cheering,             @@/---|
"Come on Thunder Child!" ---"Thunder Child"                             @/    |
Newsgroups: comp.sys.acorn.advocacy
From: jkh@esel.lotus.com (Jordan K Hubbard)
Subject: Pre-emptive multitasking vs Cooperative - knock it off!
Organization: Lotus Ireland
Distribution: comp
Date: 11 Nov 92 20:00:27

Look, folks, this comes up everytime someone tries to "justify" why
cooperative multitasking is a good thing but the basic fact is that
cooperative multitasking is done for the simple reason that it's
EASIER to implement, not because it possesses any special set of
technical merits!

From a purely market-driven perspective, it's interesting to note that
of the 3 popular systems that currently use cooperative multitasking
(the Macintosh, the Atari and the Acorn) all of them have a migration
to pre-emptive multitasking in the works - this should tell you
something if nothing else does.  Why?  Because PMT is the ONLY way to
guarantee robust system behaviour, regardless of what processes are
running, and the situation is fast becoming one where users (even
power users) aren't willing to accept anything less.

As far as response time is concerned, it IS possible to have all the
"instant megafast response" with PMT that people are claiming is the
exclusive domain of CMT - that's the kernel's job.  When someone wants
to "move a window", there's nothing to prevent the kernel from
favoring that process (even exclusively) until the move is done.  You
don't have to "downgrade" all other processes, as folks are
suggesting, you simply need to set the priority of the "greedy"
process artificially high for the duration of the operation.

Basically, processes shouldn't have to know or care about their
priorities.  Those that really really do should be able to express
their preferences in purely "relative" terms, e.g. "increase my
priority to 12 (where "12" is defined as something reasonable for,
say, I/O responsive processing)".

I think the point is moot in any case, CMT systems are on the way
out and PMT is the emerging de-facto standard.

					Jordan

Newsgroups: comp.sys.acorn.advocacy
From: torrie@cs.stanford.edu (Evan Torrie)
Subject: Re: Replay vs. Quicktime
Originator: torrie@Xenon.Stanford.EDU
Organization: CS Department, Stanford University, California, USA
Date: 11 Nov 92 18:40:01 GMT

rsxdp@unicorn.nott.ac.uk (D.Pead) writes:

>I thought that I'd made it quite clear that Quicktime was good for
>video editing.  The problem is it can't display motion video at more
>than about 5-6 frames per second without the sort of pricey hardware you
>mention.

  Here is a recent posting to comp.multimedia by Lawrence D'Oliveiro 
on the speed of QuickTime V1.5 (this is using the software-only
Compact Video codec at a frame size of 320 x 240).

>In article <1992Nov5.101030.11961@waikato.ac.nz>, I posted the following
>playback frame rates which were achievable using the new Compact Video
>compressor in QuickTime 1.5, at a frame size of 320*240 pixels:
>
>Mac model   Display depth     Processor       Playback rate
>LC             8 bits        16MHz 68020      10.1 +/- 0.1
>PB170          8 bits        25MHz 68030      21.0 +/- 1.0
>IIcx           8 bits        16MHz 68030      14.7 +/- 0.6
>IIcx          24 bits        16MHz 68030      10.5 +/- 0.4
>IIfx           8 bits        40MHz 68030      13.2 +/- 0.3
>
>Today I found a Quadra 950 with a colour screen (on-board video, no
>acceleration), and came up with the following additional figures:
>
>Q950          16 bits        33MHz 68040      42.0 +/- 3.0
>Q950           8 bits        33MHz 68040      55.0 +/- 5.0
>
>The large variations were probably due to the fact that the machine had
>file sharing turned on (though there were no users connected). Initially
>I was getting even higher rates, but then I found that the file system
>cache was set up to 256K; I dropped it to 32K, which was the same setting
>as I had on the next-fastest machine, the PowerBook 170. For comparison, the
>size of the test movie file was 186K.
>
>Conclusion: a 33MHz 68040 has no trouble reaching or exceeding a playback
>rate of 30 frames per second at 320*240 resolution. Even a 25MHz 68040
>(Quadra 700/900) should be able to do 30 frames per second.
>
>Lawrence D'Oliveiro                       fone: +64-7-856-2889
>Computer Services Dept                     fax: +64-7-838-4066
>University of Waikato            electric mail: ldo@waikato.ac.nz
>Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
Embrace rationalism, reject superstition.           Break away from the past.
"...there is only one thing worse than having marketing people on a project,
 and that is having no marketing people on a project."  - Larry Tesler.
From: alla0008@student.tc.umn.edu
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 6 Nov 92 16:54:48 GMT
Article-I.D.: news2.1992Nov6.165448.10184
Organization: University of Minnesota

In article <20023@acorn.co.uk> steve@acorn.co.uk (Steve "daffy" Hunt) writes:

>Response time in a co-operative system is completely at the mercy of
>all the other programs running.  Each "co-operating" task has
>absolutely no way to determine how much work it should do before
>relinquishing control.  In general it is an impossible task to write
>code for a background operation that maximises its own performance
>without taking an unacceptable toll on system throughput.

Out of interest, can anyone say how the Taskwindow module determines how
much work it should do per cycle? In particular, when there's more than
one Taskwindow task active, does each one reduce its timeslice to keep the
co-operative cycle time about the same? Also, when a Taskwindow is idle
(say, just sitting with a CLI prompt), it takes no CPU time - how does it
know not to?

Graham						allan@mnhep8.hep.umn.edu
						gta@st-andrews.ac.uk
Newsgroups: comp.sys.acorn.advocacy
From: alla0008@student.tc.umn.edu (Graham Allan)
Subject: Re: The ARM Club
Organization: University of Minnesota
Date: Mon, 9 Nov 1992 16:39:34 GMT

In article <1992Nov9.001953.23918@cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (TMOTA) writes:
>steve@acorn.co.uk (Steve "daffy" Hunt) writes:
>
>>Response time in a co-operative system is completely at the mercy of
>>all the other programs running.  Each "co-operating" task has
>
>Yup. So long as everyone *cooperates*, it runs fine.
>
>>absolutely no way to determine how much work it should do before
>>relinquishing control.  In general it is an impossible task to write
>>code for a background operation that maximises its own performance
>>without taking an unacceptable toll on system throughput.
>
>Hmmm... I think that's a load of bollocks, but if I say that you'll get
>upset... ;-)
>
>Firstly, there IS a way to determine "how much work...before relinquishing
>control". You give yourself a TIMESLICE. That is, your own program
>pre-empts ITSELF (or pretends to). A timeslice is also a good idea, as
>TIME is constant on all processors, while instructions-per-second isn't.
[rest deleted to save space]

This works fine if only one process is doing work in background, but if
two or more tasks are doing this, each one still takes its timeslice and
the desktop response gets very slow. The only way to keep the desktop
response good would be to try and keep the time of the complete polling
loop below some critical value - and I don't see how any individual task
can manage this, without knowledge of other tasks' timeslices. It has to
be centrally co-ordinated by the OS (or something with overall knowledge
of the system load).

As for the 'too-long' timeslice of TaskWindows, I agree in principle, but
probably they perform a lot of saving/restoring of state on task switches,
which would become an unacceptable overhead with shorter slices.

Graham						allan@mnhep8.hep.umn.edu
						gta@st-andrews.ac.uk
From: ppxpmd@unicorn.nott.ac.uk (P.Debenham)
Newsgroups: comp.sys.acorn
Subject: Re: Copyright on Games Passwords
Date: 12 Nov 92 17:25:09 GMT
Organization: Cripps Computing Centre, University of Nottingham

Simon,
   They would have a very hard job in proving damages even if the copyright
was upheld.  Copyright is a CIVIL offence so damages would only be awarded
if Krysalis could prove to a court that it had lost money due to such a list
being published.  If they has[D    have no intention of publishing such a list
themselves as a profit making enterprise they would have a difficult time of
it (They woudl have to prove tht such a list culd reasonably be expected to
make a profit etc.)
  Now that is IF the copyright is upheld which is extremely uncertain.
Copyright exists on the manner that ideas are expressed not on the factual
information contained within such an expression.  So a novel is copyright
because it is the way that things are expressed which make up the product.  A
scientific paper is copyright in what language is expressed but not in the
faxts that it expresses (you should not be publishing or should be obtaning a
patent if you want to keep control of these).  Phone compainies have found that
they have no copyright on the directory listings information that they produce.
If someone wants to copy all the information and reproduce it in machine
readable form they are entitled to do so .  This is why electronic media
often acarry fut   further restrictions on copying beyond copyright because it
would otherwise be simpple to extract the information you want, change its
format and then resell.  A contract specifically banning you from doing this
though does leave you open for damages, but for breach of contract not for
breaking copyright.  I somehow doubt whether Krysalis have done more than
attempt to assert coptyright so again does not apply.
  DISCLAIMER  I am not a solicitor.  Take the abov to a solicitor if you want
              to use it as a basis of a defence.  I take no responsibility if
              it is wrong.

Peter D
Excuse malfunctioning editor for bad typos
Newsgroups: comp.sys.acorn
From: tytgat@rilke.esat.kuleuven.ac.be (John Tytgat)
Subject: Re: RISC OS 3 Impression...
Organization: K.U.Leuven, Belgium
Date: Tue, 10 Nov 1992 12:58:38 GMT

In article <27916@castle.ed.ac.uk> ainsjc@castle.ed.ac.uk (Steffan Corley) writes:
>
>Doe anyone know (or care to speculate on) whether and when CC are likely
>to release a fully RISC OS 3 version of Impression.

Charles Moir told me at the BAU that there will be a major new version of
Impression around Christmas.  We'll see...

John.
tytgat@esat.kuleuven.ac.be (do not thrust my e-mail address in the header)
BASS
Newsgroups: comp.sys.acorn.tech
From: smb@cs.nott.ac.uk (Simon Burrows)
Subject: Re: RiscOSLib for ISO-Pascal
Organization: Nottingham University
Date: Tue, 10 Nov 92 13:12:06 GMT

In article <BxDLw7.DHH@ibmpcug.co.uk> gtoal@ibmpcug.co.uk (Graham Toal) writes:
>
>I was wondering though - it des *not* seem to have been well publicised.
>Why don't you arrange with one of the magazines (BAU?) to publish it
>as a cover disk?  That would be a major coup for a magazine and excellent
>publicity for Acorn.

Remember that these magazines are independent of Acorn, and it does create
friction if they feel that one magazine gets preferential treatment, for
obvious commercial reasons.

Besides, if it is published with Acorn's name on it, users will expect all
the usual support from Acorn, including bug fixes.

Risc User recently published its own DDE frontend for the ISO Pascal. 
I haven't compared this with the Acorn one.

Simon
------------------------------------------------------------------------------
Simon Burrows   smb@cs.nott.ac.uk  psyhsmb@unicorn.nott.ac.uk  +44 533 712030
------------------------------------------------------------------------------
Organisation: European Space Operation Centre (E.S.O.C)
Date: Tuesday, 10 Nov 1992 11:38:18 CET
From: <SMARTIN@ESOC.BITNET>
Newsgroups: comp.sys.acorn.tech
Subject: Re: Receiving message 0x502, and win' Work Area flags...
 <1992Nov9.005325.24603@cs.aukuni.ac.nz>

In article <1992Nov9.005325.24603@cs.aukuni.ac.nz>, jwil1@cs.aukuni.ac.nz
(TMOTA) says:
>An easy test to do is to put a debugging 'printf' into your message handler
>and print out the recieved message numbers... I use
>
>bbc_vdu(26); bbc_vdu(4); /* get the cursor in VDU4 mode at top left of scren*/
>printf("Message number: %x", blah);
>
>or you could just use the printf, and redirect your programs output to
>a file
>(in !Run, change
>  Run <Obey$Dir>.blah
>to
>  Run <Obey$Dir>.blah > <Obey$Dir>.output
>)
>
>This way, you'll know *what* messages you're actually recieving, which is
>always a good place to start working out why nothing's happening...

How about using fprintf ? I always find this much simpler.

-----------------------------------------------------------------
Stuart Martin (Logica at ESOC)     smartin@esoc.bitnet

Any opinions expressed in the above posting are in no way intended to
represent the official opinions of either Logica or ESOC.
From: ijp@doc.ic.ac.uk (Ian Palmer)
Newsgroups: comp.sys.acorn.tech
Subject: ADFS maps
Date: 9 Nov 1992 10:54:27 -0000
Organization: Department of Computing, Imperial College, University of London, UK.
NNTP-Posting-Host: oak6.doc.ic.ac.uk

Now I have a problem, to which I know of *a* solution to, but I don't
want it to be the *only* solution.

Over the weekend I suddenly (well over the period of a few mins) lost
3.5Meg of my hard disc free space. I was archiving some files and what
appeared to happen is that every time a new file was placed in the
archive (producing a copy of the archive temporarily) the old one at
the end was NOT being added to the free space map (or is it taken
away?) on my IDE (A5000) hard disc.

The consequence is that I went from 3.5meg free to zilcho all for a
500k archive. A further consequence is that *checkmap reports that the
map is inconsistent with the directory tree.

Now my question is, is there some easy way of getting that 3.5 meg
back without having to re-initialise my hard disc and reinstal all the
data?

What I find hard to understand is that *checkmap obviously creates
what it consideres to be the actual map of the disc during it's
directory scan in order to compare it with what is stored as the map
on the disc. So why then can it not just replace the disc map with
this correct map?

I guess there must be a reason, because in the review of the
disc recovery program in a recent Archive magazine it states that it
can't do any more than *checkmap does (or words to that effect) on the
new map discs (ie. it can't recreate the map by scanning the disc),
but I can't understand why this should be the case.

Ian

-- 
                            E-mail : ijp@doc.ic.ac.uk
 ___           __       Snail mail : Department of Computing, Huxley Building,
  /  _   _    /_/ _   / _ _   _  _   Imperial College, 180 Queens Gate,
_/_ (_|_| )  /   (_|_(_| ) )_|/_)    London. SW7 2BZ. England.