HDTenEightyP/NetNews huggingface dataset:
From: Philip.Banks@comp.vuw.ac.nz (Philip Richard Banks)
Subject: Re: Flicker-free Icon updating
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Date: Mon, 28 Sep 1992 19:56:01 GMT

In article <1992Sep28.140636.11131@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>You could try waiting for the vertical sync before updating. In Basic
>this is done by WAIT, but there is an Os_Byte call (I don't recall the
>number) that has the same effect.

   It is an OsByte 19 that waits for Vsync. The only problem I have found with 
this is that having the window up near the top of the screen still causes
flickers. The simple answer I think is that you can't avoid flicker entirely
in the Wimp, merely lessen it's noticability...

   Philip


-- 
 Philip R. Banks  pbanks@comp.vuw.ac.nz (An Arc owner with a mission)  @@@@@/|
    (Quite what mission I am not too sure yet. But I do have one!)     @@@@/#|
 "There may be an om in moment,but there's very few folk in focus!"    @@@/--|
	--'Hallowed be thy Name' by Emerson,Lake & Palmer.             @@/###|
From: enevill@acorn.co.uk (Edward Nevill)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Bug found in v4 of Acorn C compiler
Date: 1 Oct 92 09:39:55 GMT
Organization: Acorn Computers Ltd, Cambridge, England

In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:

>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );

The order of evaluation is not guaranteed in ANSI C. This is a bug in your
program, not the compiler.

Edward (enevill@acorn.co.uk)
From: rwe11@cl.cam.ac.uk (Richard Earnshaw)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Bug found in v4 of Acorn C compiler
Date: 1 Oct 92 09:35:32 GMT
Reply-To: rwe11@cl.cam.ac.uk (Richard Earnshaw)
Organization: U of Cambridge, England

>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );
>  The variable 'value' appeared to be getting the two bytes around the wrong
>  way...

There is *nothing* in the C specification which defines the order in which the
calls to fgetByte() should be executed; indead the specification says quite
explicitly that such behaviour is *Implementation dependent*.  This is Not a
bug: if you wish to enforce a specific order you must code the calls as 
seperate statements.

Richard
-----------------------------------------------------------------------
Richard Earnshaw
University of Cambridge Computer Laboratory
Pembroke Street
Cambridge
CB2 3QG
+44 223 334650
Newsgroups: comp.sys.acorn.tech
From: esuce@warwick.ac.uk (John Catchpole)
Subject: Re: Controlling A5000 printer port for I/O
Organization: Computing Services, Warwick University, UK
Date: Mon, 28 Sep 1992 21:22:31 GMT

In article <Bv5o01.BwE@comp.vuw.ac.nz> Philip.Banks@comp.vuw.ac.nz (Philip Richard Banks) writes:
>   I too would be highly interested in this kind of information. Also useful
>would be someway of detecting if their is a device attached to the parallel
>port other than a printer...

Me too.  Does this mean we have a way of constructing an expansion card/podule
that can use the printer port on an A4?  I'm more interested in video
digitising, but if a sound digitiser can use the printer port then perhaps a
video digitiser could, or is there a bandwidth problem?  As I've said in a
separate article, I need a portable video digitising system for a project I'm
helping with.

John.

-- 
------------------------------------------------------------------------------
esuce@uk.ac.warwick.csv, cstxqak@uk.ac.warwick.dcs       at Warwick University
------------------------------------------------------------------------------
From: gtoal@ibmpcug.co.uk (Graham Toal)
Newsgroups: comp.sys.acorn.tech
Subject: Archie monitors on DOS boxes?
Date: 25 Sep 92 09:09:09 GMT
Organization: The IBM PC User Group, UK.


Anyone know if the standard Acorn monitors (that come with 310's, 540's etc)
are usable on DOS machine.  If so, which graphics adapter and what sort
of cable would I need?  I don't care about hi-res or graphics - I just
want something that'll display text.

Thanks

Graham
--
From: amell@nyx.cs.du.edu (Andrew P.Mell)
Subject: Re: Bug found in v4 of Acorn C compiler
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Fri, 2 Oct 92 00:35:25 GMT

In article <1992Oct1.193543.11168@waikato.ac.nz> mcg@waikato.ac.nz writes:

>
>Harrumph... I suspected the optimiser was on..... 
>
>I compiled a proglet (a numerical analysis using (vectorial) Lax-Wendroff 
>F-D scheme) on the VAX with optimize on and got similar results to debugging 
>on the Archie [ made a hell of a difference when I turned the optimiser off!] 
>
Eh? I was under the impression that cc -g disabled the optimiser?

A
From: hmeekings@armltd.co.uk (Harry Meekings)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Bug found in v4 of Acorn C compiler
Date: 1 Oct 92 11:07:13 GMT
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK

In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:

>
>void startDecode( void )
>    {
>    /* Initialize the bit input routines.  Since this is dual-use code
>       we can only read in 8 bits of a possible 16 */
>
>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );
>
> ....
>
>One genuine bug.
>

Indeed so, but in the program not in the compiler.  The order of evaluation
of subexpressions is unspecified (except where there's a sequence point as with
operators such as &&).  This, by the way, is explicitly stated in K&R 1, not
an invention of ANSI.  It so happens that the Acorn compiler in this case
chooses to evaluate the right-hand call of fgetByte before the left-hand
one, for reasons which have nothing to do with the optimiser.  You have been
given one of the two values you ambiguously asked for, and can't very well
complain.

With regard to dhrystone figures, you seem to live in a different world from
the rest of us.  The ground rules for dhrystone are:
 *  - Separate compilation
 *  - No procedure merging
 *  - Otherwise, compiler optimizations are allowed but should be indicated
 *  - Default results are those without register declarations
No 'use default options' there, and indeed looking at the set of reported
dhrystone times, I don't see any which don't use at least -O; many use exotic
-O sub-options

Harry Meekings

I speak for myself alone, etc etc.
From: crj10@phx.cam.ac.uk (Clive Jones)
Newsgroups: comp.sys.acorn.tech
Subject: Disrupting program flow of control from interrupts
Date: 27 Sep 92 23:47:59 GMT
Organization: 6am Digital Playground
Telephone-Messages: +44 223 33 4900
Address: Christ's College, Cambridge CB2 3BU, ENGLAND.

I want to write a *safe* *tidy* routine that can, from interrupts,
schedule a given procedure to be called instantly in a foreground
program. The only assumptions I want to make are:
  My program is still the current Wimp task.
  My program adheres to ARM Procedure Call Standard.

In other words, I can't guarantee that the interrupt that is
triggering my code was raised while the processor was in user mode,
not supervisor mode - if it happens while in supervisor mode, I want
to wait for the operating system to become unthreaded before calling
the routine.

Basically, therefore, I want to:
  Store usr_LR onto the user mode stack
  Move the value the PC would otherwise have held immediately on user
  mode re-entry into usr_LR
  Ensure that the PC instead holds a value of my choosing immediately
  on re-entry.

The tricky bit in this is getting at the PC value!

The rest (stack R0-R3,LR, F0-F3, jump to the real routine I want to call,
and on return unstack R0-R3, F0-F3 then simultaneously restore the old
PC and LR) is comparatively easy.


So far, the only way I can think of of doing this is for my interrupt
routine to temporarily patch the IRQ and SWI hardware vectors to
include a small veneer that does what I want. This ensures that I know
the *precise* state of the registers for the various modes (the
elusive PC value has just been moved to svc_LR for me by the ARM). I
can't think of any way of getting the operating system to divulge the
information - even the TaskWindow module seems to just save off the
supervisor stack in its entirety rather than getting information such
as this out of it!

--Clive.
Newsgroups: comp.sys.acorn.tech
From: kortink@cs.utwente.nl (John Kortink)
Subject: RO3.1 and RO2 switchable for A300/400 machines
Organization: University of Twente, Dept. of Computer Science
Date: Sat, 3 Oct 1992 13:03:04 GMT

RO 3.1 ...
----------
Locate link 12, and notice hard-wired links. Cut these, place a 2x2 header,
and put jumpers on in opposite direction (1-3 and 2-4 instead of the old
1-2 and 3-4). Then you have to connect the LA19 and LA20 signals to pin 30
and 31 respectively of all the ROMs. Alas, in the A300 these are taken to
5v in one of the power planes, so there's no way of cutting them and rewiring.
What I did was bend pins 30 and 31 on all the ROMs slightly outwards, so
they are 'dangling' just outside the sockets (i.e. uncut, but straight down
because of lack of room to bend them sideways). Then loop the wires, and
connect the 30 wire to pin 17 of IC 28 (which is LA19) and 31 to pin 16
(LA20).

RO2 too ...
-----------
This is more complicated. I piggy-backed the old ROMs on the new ones, cutting
free the CS pins (20/28, i.e. 22/32) and pins 28/28 (which needs 5v). Then
also looped a wire through these, connected 28/28 to 5v, then cut the MROMCS
line. I.e. now only a switch is needed between MROMCS and either of the two
CS lines. Because I'm not a great fan of looping these high-frequency signals
through long wires, I used a 74HCT138 to do the switching, which is
B=C=C2B=0v, C2A=MROMCS, C1=5v, A taken to the switch, to take it to 0v or
5v, and Y0 to CS of the old ROMs, Y1 to the CS of the new ROMs (where MROMCS
was cut).


John Kortink

Student of Informatics at the University of Twente, The Netherlands
(God, will I ever stop doing things 'on the side' and get it done?)
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.sys.acorn.tech
Subject: Re: More RiscOS 3 fonts to PostScript...
Date: 7 Oct 92 16:16:36 +1300
Organization: Vooniersity fo Kaiwato

>Philip Colmer writes:
>  You shouldn't need to do ANYTHING with your fonts once you've got
> cooperative software.

Really?  Then how come !Draw doesn't download the fonts?!!!

Anyway, I ported the orginal Type-1 font, and clicked on the 'Keep PostScript'
box - now it downloads the PostScript Type-1 file which is stored in the same
place as the metrics and outlines.  Neat!  (except the size of the PostScript
printouts has jumped is size... you win some, you lose some...)

So the moral of the story seems to me to be: if there's a Type-1 stored with
the font, it will be downloaded, otherwise, it won't.

Now, how many users have access to the original Type-1's?
								Ug!

P.S.  The Type-1 converter doesn't work on all Type-1 fonts.  Bummer.
From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.sys.acorn.tech
Subject: Re: 'volatile' in Norcroft/Acorn C
Date: 30 Sep 92 12:32:21 +1200
Organization: Vooniersity fo Kaiwato

Andrew P.Mell writes:
> Talking of ANSI compliance are the format specifiers for strftime()
> well defined? The format specifiers for Sun cc are totally different
> to those for Acorn/Norcroft C. Its a pain when porting.
> 
> Who is right?

Hmm.  Sun CC is (or at least, the one we use is) K&R/Unix BSD compatible,
and is *not* ANSI compliant!  As far as I can tell, the differences is the
libraries are due to ANSI, not Acorn/Norcroft.

However, Huw's UnixLib may contain the variant used in the Sun libraries.

							Ug!
From: pcolmer@acorn.co.uk (Philip Colmer)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Message_Iconise
Date: 6 Oct 92 07:49:13 GMT
Organization: Acorn Computers Ltd, Cambridge, England

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

>As far as I can tell, the PRMs say the message numbers are 0x400c10
>and 0x400c11 respectively. However, these numbers don't work.
           ^^
 These two digits should be hex! ie 0x400CA and 400CB.

The three messages are:

 Message_Iconize:      0x400CA: issued by the Wimp when SHIFT+quit clicked
 Message_WindowClosed: 0x400CB: issued by the Wimp when a window is closed/deleted
 Message_WindowInfo:   0x400CC: issued by the Iconizer application

Note that if you only have the one iconized sprite you want to use,
the easiest thing is to call it ic_<task name> and don't bother
responding to any of the messages, eg ic_edit, ic_filer, ic_draw,
ic_paint. For consistency, you should use ic_? from the Wimp's sprite
pool and then usually put the small version of the filetype sprite in
the middle of it.

--Fil.

---------------------------------------------------------------------
        Practise random kindness and senseless acts of beauty
From: eopa21@festival.ed.ac.uk (R Spooner)
Newsgroups: comp.sys.acorn.tech
Subject: State Machine's extended colours: choice
Summary: How does the SM GE choose it's new colours
Keywords: colourtrans, extended palette
Date: 5 Oct 92 14:33:21 GMT

How does the State Machine's Graphic's Enhancer choose the colours
it is going to use? QD's lets you do it yourself which is no
good for practical use. If you allocate a palette entry for each
request to ColourTrans, you'll run out quickly. What should be
done about it?

Any answers gratefully received.

-	-	-	-	-	-	-	-	-	-
Roger Spooner			| The nice thing  about  standards is that
University of Edinburgh		| there are so many of them to choose from.
R.I.W.Spooner@ed.ac.uk        	|		    -- Andrew S. Tanenbaum
-	-	-	-	-	-	-	-	-	-
From: mcg@waikato.ac.nz
Newsgroups: comp.sys.acorn.tech
Subject: Re: Bug found in v4 of Acorn C compiler
Date: 1 Oct 92 19:35:43 +1200
Organization: University of Waikato, Hamilton, New Zealand

> Minor Flame Start {
> Can anyone think of any good reason why the optimiser is permanantly ON in
> the C compiler? Every other C compiler on the planet has the optimiser as an
> optional command line flag... Is it really just to make the dhrystone results
> look better (as the benchmark specifies that the compiler should be run in
> it's default state--optimiser off for everyone else, but on for the Acorn one)
> } Minor Flame End
> 


 Major Flame Start {

UG! 

Harrumph... I suspected the optimiser was on..... 

It makes debugging/tracing ARRAYS (matricies) and other such variables a 
MAJOR BUMMER. (i.e after an array as been through a function, one gets results 
1.9876735664 E+238.....)

I compiled a proglet (a numerical analysis using (vectorial) Lax-Wendroff 
F-D scheme) on the VAX with optimize on and got similar results to debugging 
on the Archie [ made a hell of a difference when I turned the optimiser off!] 

I also suspect this may be the reason the flaming debugger on the Arc changes 
the program enviroment; stuffing the &^^$$#$@#'ing results!

} Major Flame End.

From Martin Glanvill		(mcg@waikato.ac.nz)

Dept. Maths 							      @@@@@/|@
University of Waikato						      @@@@/ |@
Hamilton							      @@@/__|@
New Zealand							      @@/   |@
								      @@@@@@@@

----------------****=====| A quote to make your day |======****-----------------
Any philosophy that can be put in a nutshell belongs there.
                                        -- Sydney J. Harris
-------------------------------------------------------------------------------
From: r_voisey@csd.brispoly.ac.uk (R Voisey)
Newsgroups: comp.sys.acorn.tech
Subject: KART & RISCOS
Date: 5 Oct 92 08:55:55 GMT
Organization: Bristol Polytechnic, England

I have a query about the way in which RISCOS accesses the IOC KART.

I need to communicate with a keyboard-like device via the KART, but without
the OS intercepting my data or inserting it's own data.  I tried this two
ways:

1.  Illegal way.  Mask TxE and RxF interrupts in the IOC IMR-B, then drive
the KART in a polling fashion using ISR-B to get the status of the device.

2.  Legal way.  OS_ClaimDeviceVector for devices 14 & 15.

The first way worked, but the KART intercepted my data and attempted to
interpret it.  The data happenned to correspond with keyboard mouse position
codes, so the pointer went berserk.

The second way worked 20% of the time.  A further 20% of the time the machine
locked solid.  The remainder of the time the data rx'd from the KART was
incorrect and a strange thing happened - the pointer axis reversed.  The
mouse step was NOT changed.

My conclusion is that the KART handler in RISCOS polls the KART (perhaps on
a timer IRQ) rather than relying purely on interrupts.  Both the Arthur &
the RO2 PRMs imply that this is not the case, however.  So..  anyone know
for sure?

Cheers

Bob
-- 
  Robert J. Voisey  :  r_voisey@csd.brispoly.ac.uk
         -- Probug Software Developments --
162 Staplehill Rd, Fishponds, Bristol, Avon, England
Newsgroups: comp.sys.acorn.tech
From: Steve@klaatu.demon.co.uk (Steve Loft)
ReplyTo: Steve@klaatu.demon.co.uk
Subject: Colour composite video?
Distribution: world
X-Mailer: cppnews $Revision: 1.18 $
Organization: home
Date: Fri, 2 Oct 1992 12:32:16 +0000

I'm using the monochrome video output from my A4401/1 to drive my video
walkman.  Very useful for those games which my Taxan 875 can't cope
with.  Just a shame it's monochrome.  Is there any simple modification I
can make which will allow me to get a *colour* composite video output
from my Arc?

Steve
|  Steve Loft                                  steve@klaatu.demon.co.uk   |
|  Doncaster,                                                             |
|  South Yorks.                                                           |
Newsgroups: comp.sys.acorn.tech
From: sdaveyj@cc.curtin.edu.au
Subject: Re: Controlling A5000 printer port for I/O
Organization: Curtin University of Technology
Date: Tue, 29 Sep 1992 03:09:35 GMT

In article <gv4qbtd7@csv.warwick.ac.uk>, esuce@warwick.ac.uk (John Catchpole) writes:
> In article <Bv5o01.BwE@comp.vuw.ac.nz> Philip.Banks@comp.vuw.ac.nz (Philip Richard Banks) writes:
>>   I too would be highly interested in this kind of information. Also useful
>>would be someway of detecting if their is a device attached to the parallel
>>port other than a printer...
> 
> Me too.  Does this mean we have a way of constructing an expansion card/podule
> that can use the printer port on an A4?  I'm more interested in video
> digitising, but if a sound digitiser can use the printer port then perhaps a

A friend of mine has a 33MHz 386 PC and has a 100x100pixel 16 colour digitiser
that works through the printer port. It even grabs in real time I think

It could probably be done quite easy on the A5000

                John Davey
From: nbvs@cl.cam.ac.uk (Nicko van Someren)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Controlling A5000 printer port for I/O
Date: 27 Sep 92 21:28:37 GMT
Reply-To: nbvs@cl.cam.ac.uk (Nicko van Someren)
Organization: U of Cambridge Comp Lab, UK

In article <Bv5o01.BwE@comp.vuw.ac.nz> Philip.Banks@comp.vuw.ac.nz (Philip Richard Banks) writes:
>In article <drushall.717329957@cs.man.ac.uk> drushall@cs.man.ac.uk (David Rushall) writes:
>>The sampler  was built from a design from ST/Amiga Format a few years ago,
>>and was supposed to be compatible with any machine with a PC-like,
>>bidirectional printer port. To use it one has to toggle the Centronics
>>strobe line (I think) and then read the byte on the data lines.
>
>   I too would be highly interested in this kind of information. Also useful
>would be someway of detecting if their is a device attached to the parallel
>port other than a printer...
>

There is a SWI in the module called parallel that gives you the address
of the parallel port registers in the 82710/711.  DUmp the module to find out
the SWI name, I can't remember it at the moment.  Then all you need is either
an 82711 data sheet or a book on PC hardware.

	Nicko
+-----------------------------------------------------------------------------+
| Nicko van Someren, nbvs@cl.cam.ac.uk, (44) 223 358707 or (44) 860 498903    |
+-----------------------------------------------------------------------------+
From: crj10@phx.cam.ac.uk (Clive Jones)
Newsgroups: comp.sys.acorn.tech
Subject: BBC Basic tokenise/detokenise routine specifications needed
Date: 29 Sep 92 16:13:21 GMT
Organization: 6am Digital Playground
Telephone-Messages: +44 223 33 4900
Address: Christ's College, Cambridge CB2 3BU, ENGLAND.

I know this is in the BBC Basic manual, but it's years since I last
saw one, and the company I work for seems to have lost its copy, too.

Could some kind soul please e-mail me the specification of the
tokenise/detokenise routines exported by BBC Basic when you do call. I
can find their addresses (using the same piece of code used by !Edit
under RiscOS3), but that doesn't help me to guess what parameters they
take.

Thanks in advance,

--Clive.
From: nas20@cl.cam.ac.uk (Nick Smith)
Newsgroups: comp.sys.acorn.tech
Subject: Re: SparkFS
Date: 5 Oct 92 16:31:54 GMT
Reply-To: nas20@cl.cam.ac.uk (Nick Smith)
Organization: U of Cambridge Comp Lab, UK

In article <gilbertd.717955808@p4.cs.man.ac.uk> gilbertd@p4.cs.man.ac.uk (David Alan Gilbert) writes:
>Hi All - have any of you had problems with URD's
>in SparkFS - I can't seem to set them.
>
>Dave
>
>P.S. SparkFS is a great piece of software
>

I would guess that SparkFS doesn't support URDs (quite a few filing systems
don't), because David thought that there was no demand. A more flexible 
solution is to use something like setting My$URD to the full pathname
(including the SparkFS#ADFS## etc and using that instead) If that is not
possible, then perhaps you can convince him to add/fix URD functionality in
SparkFS - he is normally very helpful when it comes to things like that.

>
>P.S. SparkFS is a great piece of software
>
More than that - it is a *fantastic* piece of software !! I couldn't live
without it ...
--
Nick Smith, Churchill College, Cambridge, UK.  %$%  Email: nas20@uk.ac.cam.phx
sig quote wanted - must be under guarantee.   $%$  --- Usual disclaimer. ---
Newsgroups: comp.sys.acorn.tech