HDTenEightyP/NetNews huggingface dataset:
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:42:10 GMT


Talking of bugs in Cv4, Help! I'm stuck on this one....

!DDT repeatedly address exceptions on me, I've tracked this down to
probably being Acorn C v4.00 generating incorrect debug info
(specifically the line number info)

Look at the output of decaof -g for one of my program modules.

How do I get around this apparent bug in Cv4?

Andy


** Identification

Norcroft RISC OS ARM C vsn 4.00 [May  3 1991]

** Header

AOF file type: Relocatable object code
AOF VSN:   150
No of areas:     5
No of symbols: 534


** Area C$$debug, Alignment 4, Size 50200 (0xc418), 1386 relocations
        Attributes: Data: Read only: Debugging tables

00000000 --- Section
00000002 Length = 40
00000004 Language: C
00000005 Flags: line number info, local variable info
00000007 Debugging table version: 1
00000008 Code address 0x00000000 (Relocation offset 0x00000008)
0000000c Data address 0x00000000 (Relocation offset 0x0000000c)
00000010 Code size = 0x0000f7a4
00000014 Data size = 0x000011cc
00000018 File info offset = 0x0000af90 (AREA offset 0x0000af90)
0000001c Section size = 50200
00000020 Section name: "c.term"
00000028 --- Type

.. etc..

0000c398 Line 7060, statement 1 at code address 0x0000f792
0000c39a Line 7061, statement 1 at code address 0x0000f7a2
0000c39c Line 7062, statement 1 at code address 0x0000f7aa
0000c39e Line 7063, statement 1 at code address 0x0000f7b2
0000c3a0 Line 7064, statement 1 at code address 0x0000f7be
0000c3a2 Line 7065, statement 1 at code address 0x0000f7ca

..etc...

0000c3a4 Fragment 3 (size = 19661112)
0000c3a8 First line = 19661112
0000c3ac Last line = 19661104
0000c3b0 Code address 0x01100230 (Relocation offset 0x0000c3b0)
0000c3b4 Code size 0x03e70000
0000c3b8 Line 19661112, statement 1 at code address 0x01100230
0000c3ba Line 19661112, statement 2 at code address 0x01100234
0000c3c0 Line 19661136, statement 1 at code address 0x01100234
0000c3c6 Line 19661136, statement 2 at code address 0x01106a3c

...etc...

00012932 Line 29139522, statement 10 at code address 0x017d6c8d
00012938 Line 29139522, statement 11 at code address 0x017d6c8d
0001293e Line 29139522, statement 12 at code address 0x017d6c8d
00012944 Line 29139522, statement 13 at code address 0x017d6c8d
0001294a Line 29139522, statement 14 at code address 0x017d6c8d
00012950 Line 29139522, statement 15 at code address 0x017d6c8d

I seriously doubt my program has 29139522 lines, and more than 10
statements per line. I've tried fiddling the source around, rearranging
it etc. but to no avail, please tell me whats wrong, its driving me mad!
From: crj10@phx.cam.ac.uk (Clive Jones)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Hard disc formatters! HELP!
Date: 4 Oct 92 15:31:47 GMT
Organization: 6am Digital Playground
Telephone-Messages: +44 223 33 4900
Address: Christ's College, Cambridge CB2 3BU, ENGLAND.

In article <1992Oct3.214943.2529@csd.brispoly.ac.uk> r_voisey@csd.brispoly.ac.uk (R Voisey) writes:
>Are you using the unit as your primary drive?  I've had a lot of problems
>getting anything other than Conner units to work reliably as the first drive
>(although most units work OK as second drives).  I haven't tried a Cumulus
>drive (haven't heard of them for that matter), but most Seagate drives have
>problems.

Yes - the problem is a bug in RiscOS 3.0, which is fixed in 3.1 . The
only drives I have known to work as a master with slave attached on
the A5000 under RO3.0 are Conner and Samsung. I hear rumours that a
few more will work in a one-drive configuration.

(Gripe: Why couldn't Acorn put a few more LED slots along the fascia
of the A5000? It would be nice to have independent drive lights for
two hard discs, if you have them fitted.)

--Clive.
From: crj10@phx.cam.ac.uk (Clive Jones)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Econet timeouts
Keywords: Econet timeouts
Date: 30 Sep 92 15:23:48 GMT
Organization: 6am Digital Playground
Telephone-Messages: +44 223 33 4900
Address: Christ's College, Cambridge CB2 3BU, ENGLAND.

In article <marlow.717842425@radon.sys.uea.ac.uk> marlow@sys.uea.ac.uk (K. Marlow PG) writes:
>  I just want to ask those in the known, is the timeout for an econet
>transmit an absolute stop point or just a point at which it says the
>transmission has failed? Say if I had my timeout set to 1 second and a repeat
>count of 10, would that mean the first transmission (which is queued due to
>the network being busy) be aborted after 1 second or does it just
>decrease the repeat count & keep on with the same queued transmission?  If
>it does the first then I could see situations where a transmission doesn't
>occur because it never reaches the top of the queue in time.  This is
>something which the PRM's aren't very clear on & might explain some strange
>behaviour I'm getting..

OK. The PRMs are NOT at all clear on network behavior.

Econet's protocol is based around a four-way handshake (ignoring
broadcasts, which are a special case). The sending machine sends a
scout frame, which is *IMMEDIATELY* followed by the recipient sending
an acknowledge (if it is willing to accept a transmission from that
machine on that port of that length), in turn *IMMEDIATELY* followed
by the sending machine sending the full data, which is then
*IMMEDIATELY* acknowledged by the receiving machine. Then the network
is sent idle, and someone else takes it.

If two people try transmitting at once, then one or both scout frames
will be lost, and one or both machines will perform a random back-off.
If the scout frame gets through, the transmission is then allowed to
run uninterrupted to completion, if the two machines negotiate
correctly.

The practical upshot of this is that if a transmission is marked, at a
given instant, as failed, then no scout frame has got through. This is
equivalent to the rest of the world to your never having tried to
send. SO - trying to send for ten seconds is the same as trying to
send for one second ten times in quick succession, apart from the
small periods in which you're not trying to send.

There is no network queue as such, as previously explained.

Why do you want to do several short timeouts instead of one long one,
though? If it's just so that you can continue processing in the
meantime, you ought to use background operations (i.e.
Econet_Transmit, Econet_PollTransmit, etc. rather than Econet_DoTransmit).

>  Also what do people reckon is a sensible length of timeout to have.. 5
>seconds, maybe 10?

I tend to use a timeout of 30 seconds, but let the user press Escape.

--Clive.
Newsgroups: comp.sys.acorn.tech
From: ggasrren@nyx.cs.du.edu (Glenn Garrett)
Subject: My dead A410/1 PSU :-(
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Sun, 4 Oct 92 16:12:01 GMT

Hello everyone
A question on the Arc PSU (410/1). Recently, I managed to make that
lovely age old mistake of shorting all the power outputs to ground, which
promptly killed my PSU.
 
After having got over the initial shock of realising that the PSU was   
not going to come out of its coma easily (like an old BBC supply would),
I had to connect up an old disk drive power supply I had spare -  
fortunately it was powerful enough to power the computer and hard drive.
 
Anyway it would seem that the main power transistor is gone (short
circuit), along with R4 and the two fuses. There may be other
components too. I would like advice - should I try and get hold of
another power transistor, (but there may be other components too),
or am I going to have to shell out 50 quid for a new supply?? I am not
over well-endowed with money!
 
1. Has anyone made the same mistake as I and what repair procedures were needed?
2. Can anyone tell me the value of R4 as it is burnt to illegibility?           
3. Has anyone got a spare supply going cheap, either new, second-hand or
not working?                                                                    
                                                                                
Any help much appreciated - please mail me direct and I will post a             
summary to the group. Interestingly, my current supply does not have
-5V and the only side effect of this seems to be that the sound from
the computer doesn't work! :-( I think a 7660 IC should cure this 
though if I get time to wire one up.
 
Many thanks - Glenn Garrett, (a normally silent CSA fan).

PS Any comments on the rumour that ARM3's are soon to drop in price? 
_______________________________________________________________________________
          ._  _     _     _   __ _  _ .  .      |  Glenn Garrett (Banana Jack)
He's Here | || || || || || |   || || `|_/  He's | Janet: csc319@uk.ac.lancaster
 To Kick  |-\|-||\||-||\||-|   ||-||  | \  The  | I'net: csc319@lancaster.ac.uk
 Bananas  |_/| || || || || | \_/| ||_,|  \ Man. | AX25 Packet:   G7GLN @ GB7ULV
________________________________________________|______________________________
From: sproven@cs.strath.ac.uk (Simon B Proven IE91)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Flicker-free Icon updating
Date: 29 Sep 92 13:48:39 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

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's OS_Byte 19

>	Torben Mogensen (torbenm@diku.dk)

mad@bike

My other bike's a recumbent :)
Newsgroups: comp.sys.acorn.tech
From: amell@nyx.cs.du.edu (Andrew P.Mell)
Subject: Re: 'volatile' in Norcroft/Acorn C
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Tue, 29 Sep 92 19:28:04 GMT

In article <1992Sep29.160306.6352@infodev.cam.ac.uk> crj10@phx.cam.ac.uk (Clive Jones) writes:
>Hmm. I've just got my hands on a draft ANSI C standard, and it's quite
>clear, unfortunately, that an implementation is under no obligation at
>all to do this, however:
>

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?

A
From: marlow@sys.uea.ac.uk (K. Marlow PG)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Econet timeouts
Keywords: Econet timeouts
Date: 1 Oct 92 08:33:21 GMT
Organization: UEA School of Information Systems, Norwich, UK.

crj10@phx.cam.ac.uk (Clive Jones) writes:

>In article <marlow.717842425@radon.sys.uea.ac.uk> marlow@sys.uea.ac.uk (K. Marlow PG) writes:
>>  I just want to ask those in the known, is the timeout for an econet
>>transmit an absolute stop point or just a point at which it says the
>>transmission has failed? Say if I had my timeout set to 1 second and a repeat
>>[...]

>OK. The PRMs are NOT at all clear on network behavior.
  Ah, I'm glad someone else noticed.  :-)

[...]

>If two people try transmitting at once, then one or both scout frames
>will be lost, and one or both machines will perform a random back-off.
>If the scout frame gets through, the transmission is then allowed to
>run uninterrupted to completion, if the two machines negotiate
>correctly.

>The practical upshot of this is that if a transmission is marked, at a
>given instant, as failed, then no scout frame has got through. This is
>equivalent to the rest of the world to your never having tried to
>send. SO - trying to send for ten seconds is the same as trying to
>send for one second ten times in quick succession, apart from the
>small periods in which you're not trying to send.

>There is no network queue as such, as previously explained.
  Er, are you sure that there isn't a transmit queue?  What would happen if
I tried to start several transmits at once using Econet_Transmit?  or are you
saying that all the waiting transmits try to contend for the line at the
same time?

>Why do you want to do several short timeouts instead of one long one,
>though? If it's just so that you can continue processing in the
>meantime, you ought to use background operations (i.e.
>Econet_Transmit, Econet_PollTransmit, etc. rather than Econet_DoTransmit).

  I do do that via an EconetSupport module which implements a true event queue
which is read by the polling wimp application.  Handles all the rma &
control blocks.  This sits under an Econet C library which makes a connection
across econet look like a form of two way synchronous virtual link, gets rid
off the need for me to mess around with the econet specific bits in the
application code & allows me to write econet apps quite quickly.

  Also, you seem to imply that one long timeout is the same in effect as
several short timeouts, if that was the case I would thought that there
would have been only the one parameter?  There must be some difference in
effect.

>>  Also what do people reckon is a sensible length of timeout to have.. 5
>>seconds, maybe 10?

>I tend to use a timeout of 30 seconds, but let the user press Escape.
  Hmm, I suppose I'd better make the timeout & count parameters passed to my
Econet library, then my beta testers can play with the settings & see what
happens.

>--Clive.
--
 Keith Marlow,               *  Author of Archiboard BBS s/w, 
 Information Systems P/G,    * the only multiline fidonet BBS which operates
 University of East Anglia,  * across Econet.
 Norwich. Norfolk NR4 7TJ    *
From: arcturus@spuddy.uucp (Geoff Riley)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Hard disc formatters! HELP!
Date: 4 Oct 92 19:45:04 GMT
Organization: Spuddy's Public Usenet Domain

In article <1992Oct3.214943.2529@csd.brispoly.ac.uk> r_voisey@csd.brispoly.ac.uk (R Voisey) writes:
>Acorn sent a memo to dealers a while ago stating exactly which drives are
>compatible with the A5000 (basically just Conner drives).  Lots of other
>drives WILL work, but you have to fiddle.  This isn't really Acorn's fault - 
>IDE has a very poor specification (IMHO) and is open to interpretation.

You call that a specification???  I mean, the manufacturers cannot even agree
on a basic set of commands with any reliability...  When I was doing my IDE
interface, I based the code around specs I got for a Kyocera (sp?) drive...
worked fine until I tried it on a Connor..!  I got it working on both drives,
then I got a Quantum... Pah!  Got it working on the Quantum, then Hugo got a
100MB quantum...  I never managed to get that working at all :-(

Now I'm having hassles with serial ports :-(
-- 
Cheerio,
        |~~~      (uucp address: arcturus@spuddy.uucp)
        |__|eoff  (Fidonet address: 2:250/208)

 * Meeeow ! Call Spuddy on (0203) 638780/638693 for FREE mail & Usenet access *
Newsgroups: comp.sys.acorn.tech
Subject: Re: Flicker-free Icon updating
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Tue, 29 Sep 1992 02:45:37 GMT
Organization: Computer Science Dept. University of Auckland

SMARTIN@ESOC.BITNET writes:

>I am writing an application that requires a number of text icons to be
>updated fairly regularly (frequency definable by the user). Currently, I
>am using the SWI SetIconState with zero arguments to force an update, but
>if the update frequency is more than a few frames per second, the flicker
>is quite intolerable with or without icon borders.

Well, as others have said, you can call Os-Byte 19 / *FX19 / WAIT just before
causing update. THis works well, except near the top of the screen, and aslo
has the drawback of slowing things down a lot if you update many times a
second (especially if other programs are also WAITing... An ARM-3 machine
can do up to around 260,000 instructions in the time it takes to do a WAIT!)

Another trick that can reduce flicker substantially is to draw your info
into a sprite, and then SetIconState,0,0 the icon containing the sprite.
This should be near flicker-free without a WAIT, but a WAIT as well should
make it very good.

Minimising the area of the screen can help a lot too. If you have something
like "Reading file: 10%", all you really need to update is the percentage,
and so you can stop the flicker of the text "Reading file" completely.
As you are drawing less (2 characters only now), the redraw is faster, so
the flicker on the updated number is also reduced.

The last trick is to think about what info you are updating - does it need
to be updated so frequently? You could read the time when you update the
icon (SWI "OS_ReadMonotonicTime" TO timenow) and refuse to update the icon
until the new time is > 25 centiseconds or so, giving a maximum speed of
update of 4 updates a second... When doing a lot of stuff you can end up
continuously redrawing the icon and doing very little processing, and this
can stop that type of problem from happening.
-- 
_________________  "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: pcolmer@acorn.co.uk (Philip Colmer)
Newsgroups: comp.sys.acorn.tech
Subject: Re: More RiscOS 3 fonts to PostScript...
Date: 6 Oct 92 07:59:00 GMT
Organization: Acorn Computers Ltd, Cambridge, England

In article <1992Oct6.171413.11256@waikato.ac.nz> bwc@waikato.ac.nz (Ug!) writes:

> [problems with font downloading deleted]

 Well, it worked for me using Impression 2.17, so it *may* be that
2.16 doesn't support the new printer driver call.

 You shouldn't need to do ANYTHING with your fonts once you've got
cooperative software.

 Sorry I can't be more helpful ... try asking CC for version 2.17.

--Fil.

---------------------------------------------------------------------
        Practise random kindness and senseless acts of beauty
Newsgroups: comp.sys.acorn.tech
Subject: Message_Iconise
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Mon, 5 Oct 1992 22:23:52 GMT
Organization: Computer Science Dept. University of Auckland

I managed a riffle through the RO3 PRM's yesterday, and copied the info
about Message_Iconise and Message_WindowInfo from it so that I can add
proper support for iconisation into DSEdit...

As far as I can tell, the PRMs say the message numbers are 0x400c10
and 0x400c11 respectively. However, these numbers don't work.

Printing out the numbers of recieved messages, I get a number like
(from my somewhat colander-like memory) 0x400cc whenever I shift-close
a window...

The problem with this is that if I try replying to 0x400cc with a 0x400cd
(add one and hope ;-) I don't get the effect I'm after... This is either
because I have the wrong message numbers, or that I'm using the wrong
type of message to ack with...

Does anybody know what the numbers are supposed to be, please?
-- 
_________________  "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)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Bug found in v4 of Acorn C compiler
From: epoo1@cs.aukuni.ac.nz (Edouard Poor)
Date: Fri, 2 Oct 1992 04:26:24 GMT
Distribution: comp
Organization: Computer Science Dept. University of Auckland

In <7581@armltd.uucp> hmeekings@armltd.co.uk (Harry Meekings) writes:
>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.

Ahhh, I am sorry. I was sort of relying on the author of the codes appraisal
of what the compiler did to his source. He has since said that if one takes
the ANSI spec pedantically, then yes, you cannot reply on the ordering of
evaluation even when it comes to external function calls.

Makes me feel like a bit of a grumbo though :-\

That part of the HPACK source has, however, compiled on every other platform
and compiler its been ported too (= many). I am aware that ANSI-compliant
does no nessessarily == portable as there is a fair amount of detail left
up to the implementation. Maybe the documentation should point out the
more obvious departures from what the newer C programmer might expect? (I
am at least careful about post and pre increments etc...)

I shall now gracefully withdraw from the field declaring that a bug has
been found in the ANSI spec and therefore no-one around here can be
landed with responsability for the code not working... :-)

Edouard.
From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.sys.acorn.tech
Subject: Re: 'volatile' in Norcroft/Acorn C
Date: 30 Sep 92 12:36:51 +1200
Organization: Vooniersity fo Kaiwato

Clive Jones writes:
> It would be very nice if the compound assignment operators (+=, -=,
> *=, etc.) were atomic if applied to volatile variables.

That's a *really* good idea!  In fact, ANSI does not decree that volatile
need effect anything, but it would be nice to see it used in this
manner.  Having easy access to atomic instructions would make thinks like
high-level synchonisation possible, without getting down and dirty and
doing it in assembler (which all too often loses the meaning of the
operation).

If it hasn't been done, then I for one would also vote for this!  (as if
deciding what goes into a product is a democratic process...  boy, are we
dumb or what?)
								Ug!
From: bab@doc.ic.ac.uk (B A Batacharia)
Newsgroups: comp.sys.acorn.tech
Subject: Problem with memory...
Date: 5 Oct 1992 08:56:24 +0100
Organization: Department of Computing, Imperial College, University of London, UK.
Distribution: world
NNTP-Posting-Host: oak50.doc.ic.ac.uk

I have an A3000, with a Watford (I know, I know) 2 Meg upgrade, and an Oak
SCSI card. So shoot me...
Until recently, all was fine, but a few days ago a few things stopped working.
Long programs stopped compiling, long files stopped loading (Abort on data
Transfer, somewhere in Module area, FileCore in use), and large RAM disks
stopped working.

It turns out that all memory works fine, except for just 16k, I think, right
at the beginning of the 2nd Meg. This is really (and I mean REALLY) annoying
me at the moment, as a program I'm writing has decided it won't fit in the
memory I've available. (I'm using the bottom Meg for stuff like fonts, sprites
and system workspace, and the top Meg-16k for working with. I have a cunningly
placed RAM disk.)

So, to the question ...
Presumably the Watford memory upgrade has 8 1Megabit RAMS. (Well, I know it 
has 8, I'm assuming the 1-bit...) How likely is it that 16k (1 page) in all of
these has gone for a walk? I'm guessing that it's far more serious, and that
somehow my MEMC's gone wrong (to put it mildly). After all, a RAM test comes
up with an 'Abort On Data Transfer'...

Any ideas, help, or words of comfort would be much appreciated ...

Bob Batachara

bab@uk.ac.ic
From: bdb@cl.cam.ac.uk (Brian Brunswick)
Newsgroups: comp.sys.acorn.tech
Subject: Re: Disrupting program flow of control from interrupts
Date: 6 Oct 92 01:05:21 GMT
Reply-To: bdb@cl.cam.ac.uk (Brian Brunswick)
Organization: U of Cambridge Comp Lab, UK

In article <1992Sep27.234759.24911@infodev.cam.ac.uk> crj10@phx.cam.ac.uk (Clive Jones) writes:
>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.
Isn't this precisely what callbacks are for?
Use OS=SetCallBack, presumably.
Brian.Brunswick@cl.cam.ac.uk  Disclaimer.  Short sig rules!