HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.sys.acorn
Subject: Re: Bugs, Bollocks and the truth about RO3.1
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Sat, 3 Oct 1992 05:19:45 GMT
Organization: Computer Science Dept. University of Auckland

gilbertd@p4.cs.man.ac.uk (David Alan Gilbert) writes:

>OK - there seems to be a lot of comments going about RO3.1,
>well could I suggest that someone keeps a list of bugs,
>and if they have been substantiated or not, and any
>workarounds for them.  That way we wont have to fall
>over them the hard way!

Well, to whomever decides to keep such a list (I suspect Acorn
may be interested in doing this ;-) I feel I should ask if !Paint
just runs wrong on my machine, or is it, like, wrong in all 3.10's?

If I bring up the 'Snapshot...' dialogue from the main menu and
click "ok" (so that I get a "copy a portion of the screen right now"
action) and then drag (very carefully) the eored rectangle around the
border of a window (to get a picture of said window for a user manual),
the sprite I get is only *approximately* related to the area I dragged.

To be more precise, it includes about 4 to 8 pixels of the desktop on
the left hand side of the sprite (i.e. 4-8 pixels *extra* outside the area
I dragged), and seems to behave almost randomly at the other side -
sometimes working perfectly, sometimes a few pixels off.

This discrepancy, to ensure I'm being clear, is that the grabbed sprite area
is different from the eor'd drag-rectangle that Paint draws on the screen.

I'm also very impressed that Edit's inability to redraw its windows has not
been compromised by 3 years of progress! ;-)

I'm very pleased with RISC OS 3.10 overall, but I've noticed about 10
little niggly bugs already and that's after only 1 day of use.

Perhaps when Acorn are gearing up to release RISC OS 4.00 they would care
to let me play with it for a day or two and point out all the obvious bugs?
They seem to have got all the really really obscure bugs out, but obvious and
silly bugs seem plentiful... (keeps things interesting, though! ;-)

Anyway, thanks to the guys at Acorn anyway: Risc OS 3 version 3.10 is
*miles* better than RISC OS 2. *heaps* better. Bloody marvellous in fact!
(Oh, excuse me, I'm drooling at the thought of it again... ;-)
-- 
_________________  "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)
Xref: sparky comp.sys.acorn:8825 comp.sys.acorn.tech:211
From: cjr@inf.rl.ac.uk (Chris Robey)
Newsgroups: comp.sys.acorn
Subject: BeebDOS
Date: 5 Oct 92 07:41:32 GMT
Organization: Rutherford Appleton Laboratory, Informatics Department, U.K.

Hello

I am looking for a program called beebDOS, which I have been told is capable
of making a PC read BBC formated disks. I have been told that this is a commercialpackage and that I would have to buy it? Has anyone heard of it? And if they have
can they tell me the address of the manufacturer? Actually, ANY information would
be greatly appreciated.


This is what I actually want to do ........

I have a standard text file on a BBC B and I want to transfer it to a PC!		

That is my problem - can anyone (please) suggest an answer?

Cheers - Chris
Newsgroups: comp.sys.acorn
From: gtoal@pizzabox.demon.co.uk (Graham Toal)
Subject: Source: [UNIX, C] Spark de-archiver for UNIX 
Distribution: world
Organization: Cuddlehogs Anonymous
Date: Mon, 28 Sep 1992 21:28:31 +0000

Small bug in spark.c guys - you should open most of the files
in modes "rb" or "wb", not "r" and "w".  Systems with newline
translation (eg DOS & Mac) will get it wrong.

g
From: stj@p4.cs.man.ac.uk (Grimthorpe)
Newsgroups: comp.sys.acorn
Subject: Formatting ADFS floppy discs
Summary: How do I format an ADFS disc on a b+ with 1770 DFS/ADFS
Keywords: ADFS, Formatting, B+
Date: 28 Sep 92 16:39:32 GMT


  I have tried to format some ADFS discs on a B+ with the formatter supplied
on the master welcome disc. Is there any real reason why it doesn't work,
or is it that I need a 65C12 (or whatever) to use the program

  Otherwise, is it possible to format a disc by talking direct to the
1770?
-- 
+--------------------------------+------------------------------+
| Grimthorpe the well UglyMUGger | email:   stj@uk.ac.man.cs.p4 |
+--------------------------------+------------------------------+
Error - /dev/null full. Please empty the bit bucket
From: kortink@cs.utwente.nl (John Kortink)
Newsgroups: comp.sys.acorn
Subject: Re: Yes, more .....
Date: 6 Oct 92 00:52:54 GMT
Organization: University of Twente, Dept. of Computer Science

jkreyka@cs.vu.nl (Kreijkamp J) writes :

>[...]
>Assembler only wins in
>
> - Speed.
>   but nowadays compilers have very good optimalisation, and processors
>   are faaaaastttt....

Logically, this is not correct. There is never enough speed for some
specific tasks, and this is where assembler shows its great value. You
still would not accept, say, to wait for a picture to translate in 30
seconds, when it can be done in 10. And in a text editor, you'd hate
your screen update (scrolling, throwing text around) to need to catch
up with you when it can be split-second.

Great processor speed is not an excuse to waste it ... Never as far
as I'm concerned.

And please could people step off this idea of 'very good optimization'.
Really, if you look seriously at what a compiler can do (I have, as
part of my graduation project), you'd be disappointed. In addition,
you should have a good idea of what *is* possible with hand-coding.
Frankly, I think this little phrase has been raised too many times by
a lot of people very possibly not actually knowing what can be achieved
by optimizing compilers. Yes, it's automatic and useful, but it is very
limited.

> - Size.
>   Again there are good compilers which optimise very good, and the
>   shared-libraries concept (like CLib on the arch) can reduce code
>   size dramaticaly in a multiprocess environment (RiscOs apps)

It depends on how many apps are using the code. Then there's this
enormously big shared resource used by ARM code (and C some C code)'
called the OS ... And a large variety of modules ...

>So in _my_ opinion assembler should not be used or only for writing
>very short time critical routines.

I would hate Acorn to have done this with RISCOS. Thankfully they
haven't.

Warn me if this is getting boring.


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

Help!
From: jhma@ukc.ac.uk (J.H.M.Aldridge)
Newsgroups: comp.sys.acorn
Subject: Re: Deskjet 500 confusion...
Date: 29 Sep 92 08:55:22 GMT
Reply-To: jhma@ukc.ac.uk (J.H.M.Aldridge)
Organization: Computing Lab, University of Kent at Canterbury, UK.

In article <1992Sep28.131921.16395@aisb.ed.ac.uk> ainsjc@aifh.ed.ac.uk (Steffan) writes:
>I've had a Deskjet 500 printer for 6 months now and have constantly been
>annoyed by the fact that it leaves a large margin (approx. 32mm) at the
>bottom of the page, on which you cannot print.

...

>So I have four questions:
>
>1. Am I right in thinking that the bottom margin on a Deskjet printer
>should be about half an inch (or three quarters with perforation skip
>on) rather than the 32mm I'm getting?

Certainly on my Deskjet the bottom margin is only about half an inch.

>2. What are the correct settings of (all) the DIP switches on my printer for
>use with an Archimedes.

On my Deskjet (original version, not a 500 or anything fancy!) the DIP switch
settings are as follows (this may not be the same for the '500)

   _ _ _ _ _ - _ -   - - _ _ _ _ _ _
   1 2 3 4 5 6 7 8   1 2 3 4 5 6 7 8

First bank:

	1-4 Language Select
	5,6 Paper Size (A4)
	7   CR = CR only
	8   Perf skip off

Second bank:

	1   Text scale on
	2   Graphics 300 dpi
	3-8 Serial interface setup

I seem to remember when I first set my printer up that it was the text scale
switch which caused problems although it was a long time ago now and I can't
remember the exact symptoms.

>3. I tried setting the perforation skip on by sending a command from the
>computer, and then printing a file from Impression, but this made
>absolutely no difference - still no top margin. (i.e. everything came
>out 11mm higher on the paper than it was shown on the screen). My explanation
>for this is that the printer driver probably reset the printer before it
>started printing. Do RISC OS printer drivers do this?

Almost certainly.

>4. Has anyone got any ideas of how to test for sure whether there is a
>fault.

If the above link settings don't work then I don't know what to suggest.

>Thanks a lot for any help.
>
>Steffan.

Good Luck,

James
Newsgroups: comp.sys.acorn
From: mjw19@cl.cam.ac.uk (M.J. Williams)
Newsgroups: comp.sys.acorn
Subject: Re: 'volatile' in Norcroft/Acorn C
Date: 3 Oct 92 20:33:05 GMT
Reply-To: mjw19@cl.cam.ac.uk (M.J. Williams)
Organization: The National Society for the Inversion of Cudddly Tigers

In article <9210020117.AA11778@ucbvax.Berkeley.EDU> lithgow@usl.com (Malcolm Lithgow) writes:
>I'm not sure why SWP is even mentioned in this discussion since it is
>only needful for multi-processor shared-memory systems (even if the
>memory shared is only a tiny block of spin-locks).  I'm pretty sure the
>Norcroft compiler only compiles for a single processor, and I'm equally
>sure that MP Arch's don't exist yet (commercially, at least).

Perhaps no commercial MP ARM-based machines exist yet because manufacturers are
waiting for a C compiler that can handle shared-memory 8-).

SWP is presumably mentioned as it is the only instruction for shared-memory
that the ARM provides in user mode. Turning off and on interrupts around
critical regions would be a bit wasteful of processing as such an operation
needs at least a SWI to get into SVC mode.

As mentioned elsewhere, the Norcroft compiler does not compile for a single
processor -- in a sense. The basic compiler is portable, and needs only new
code-generators for porting to a new architecture (this is in fact not true,
but is a good approxiamation). The front-end is portable. Hence if any code
generator is to support shared memory then the front-end does. I do, however,
suspect that those nice people at Codemist (one of whom I have to go to a
lecture from on Thursday as term is about to start)-8, have hopefully thought
of this in their datastructures/intermediate code.

Any way, my point is that there is no point in not implementing something in a
portable program just because the intended target won't support it. If you can
do it then do it. If it may degrade performance then do it, and have it as an
option (either at run- or compile-time), but do make programs as useful as
possible...

_______________________________________________________________________________
 \   ^   / Michael Williams                     Part II Computer Science Tripos
  |\/|\/\  MJW19@phx.cam.ac.uk                          University of Cambridge
  |  |(__) Cymdeithas Genedlaethol Traddodiad Troi Teigrod Mwythus Ben I Waered
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Thu, 1 Oct 1992 19:35:12 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.

In article <9210011556.AA01360@ucbvax.Berkeley.EDU> nicho@vnet.ibm.com writes:
>In <BvG26F.L82@comp.vuw.ac.nz> Gavin Flower writes:
>>It was never stated that "C", should, or would, always be used for
>>major applications!
> Umm excuse me, but that is _exactly_ what was stated.



???   I always thought that "generally", meant "most, but not all" -
      am I mistaken   ???

The original posted definitely used the word *generally*, and I
repeated this, in my followup to it.  At no stage did it say that
they always should be written in "C", as far as I recall.

However, the main principle, is that major applications are usually
best written in a high level language, so that they can readily be
adapted to new processors as they come out - a portability issue, if
if restricted to ARM and Risc-OS.  Once a compiler is available that
has support for the new processor built in, *all* programs written in
that language, can be recompiled to make use of its architectural
innovations (where relevant).  However, every single assembler program
would have to have varying degrees of work required - just look at
what is involved in going to make use of the 32 bit mode, in the
ARM6xy!!

There are also a lot of additional issues that mandate the use of high
level languages for large projects that are designed to be supported
for many years.  Still other issues relate to potentially wider market
penetration on other platforms.

I also thought my previous post on the subject, was very clear that a
case can be made for using assembler, at least part of the time!

Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******
From: steve@acorn.co.uk (Steve "daffy" Hunt)
Newsgroups: comp.sys.acorn,comp.sys.acorn.tech
Subject: Re: PostScript printing (was Re: RiscOS 3.1, Risc Development IDEFS)
Date: 30 Sep 92 13:18:37 GMT
Organization: Acorn Computers Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Philip Colmer (pcolmer@acorn.co.uk) wrote:
: If the application *doesn't* know how to tell the printer driver what
: fonts are being used, ie *no* calls whatsoever are made to the new SWI
: (see below) after the initial call to PDriver_SelectJob but before any
: calls to PDriver_GiveRectangle, then the printer driver includes in
: the PostScript a definition of EVERY RISC OS font you have on your
: machine that does not have a PostScript equivalent defined.

This is not quite right; for one thing it would almost guarantee to
run your printer out of memory!

Under these circumstances the printer system takes the intersection of
the Font Manager's font list and !FontPrint's font list.  PostScript
versions of the fonts occuring in both lists are produced by a cheap
renaming or re-encoding operation, using the outlines resident in the
printer.  Full-blown downloads don't happen unless the app declares
its fonts.

Ideally we'd like to simply download fonts when they are first used
inside the print job.  Unfortunately the rules of PostScript document
structuring and the nature of the save/restore mechanism prevent this.
The only real answer is for applications to declare the fonts they
want to print with.

(I see Philip has already posted a corrected version of the SWI
description.)

-- Steve
-- 
				Steve Hunt	steve@acorn.co.uk
From: pcolmer@acorn.co.uk (Philip Colmer)
Newsgroups: comp.sys.acorn
Subject: Re: AKJ03 - Risc OS PRM
Date: 6 Oct 92 07:33:44 GMT
Organization: Acorn Computers Ltd, Cambridge, England

In article <2NE7itj025n@bridge.welly.gen.nz> julian@bridge.welly.gen.nz (Julian Wright) writes:

|gilbertd@p4.cs.man.ac.uk (David Alan Gilbert) writes:
|
|| On a completely different subject, a friend is thinking
|| of getting an A4, but apparently PC keyboards
|| are a bit limiting - what limitations are imposed by
|| using a PC keyboard,
|
|You have the option of plugging in either an I*M AT keyboard or
|an Archimedes keyboard. I don't know if the reset button on the
|Arc keyboard will function, but all the keys will...

NO! An Archimedes keyboard is NOT guaranteed to work. Apparently, BBC
Acorn User tried it and it seemed to work, but the port on the A4 is
only intended for use with an IBM keyboard.

--Fil.

---------------------------------------------------------------------
        Practise random kindness and senseless acts of beauty
From: DWallin@acorn.co.uk (Dick Wallin)
Newsgroups: comp.sys.acorn
Subject: Re: Archimedes Demo *Competition* [Any one interested?]
Date: 28 Sep 92 13:26:16 GMT
Organization: Acorn Computers Ltd, Cambridge, England

You certainly find them, Simon!

Dick
From: smb@cs.nott.ac.uk (Simon Burrows)
Newsgroups: comp.sys.acorn
Subject: Re: Archimedes Demo *Competition* [Any one interested?]
Date: 27 Sep 92 15:27:50 GMT
Organization: Nottingham University

In article <1992Sep24.161051.10322@rdg.dec.com> cadwallader@forty2.enet.dec.com () writes:
>
>Anyway, FULL CREDIT to Acorn, the A3010 in Dixons was running a demonstration
>program that was really impressive (256 cols 640*256 I think), which
>demonstrated various aspects of the system and the games potential was
>emphasized strongly. This demo went on for several minutes before looping,
>looked good! :-)
>

Good news. Don't think that all Dixons/Currys stores are like this though.
I went into one last week & the A3010 was connected to an out-of-focus cheap TV
set on the opposite side of the stand. The machine had crashed in the desktop,
and the only disc in sight was the dealer-training disc, which they had
apparently been trying to put on display to the public. This gave away all
of Acorn's marketing secrets :=) V.A.L.U.E. eh?

The A3010 and TV set and training disc were the only Acorn items on display.
Nowhere did it say how much the machine costs, nor give any details of its
capabilities or the extra items supplied free with it.

Hopefully most stores are as good as the one which you describe.

Simon B.
Xref: sparky comp.sys.acorn:8822 comp.sys.acorn.tech:208
From: mcg@waikato.ac.nz
Newsgroups: comp.sys.acorn,comp.sys.acorn.tech
Subject: Re: RiscOS 3.1, Risc Development IDEFS
Date: 29 Sep 92 03:13:57 GMT
Organization: University of Waikato, Hamilton, New Zealand

]In article <1992Sep29.115639.11080@waikato.ac.nz>, bwc@waikato.ac.nz (Ug!) writes:
> Well, I've just installed RiscOS 3.1 -- no problems with speed (unmodified
> A3000, 20MByte internal IDEFS).
> 
> Some problems that I'd like some discussion on:
> 
> PostScipt printers -- finally, they download fonts!  That's right!  So long
> as
> (a) you want them downloaded permanently!
> (b) you want *every* font downloaded *every* time -- not just the ones you
>     use.
> 
> Because of option (a), you need to know the password for the printer.
> 
> Now what I would like to know is: does RiscOS 3.1 have some way of doing
> temporary downloads that last just for the extent of the job?
> 
-----------------8<----------------------8<-----------------8<-----------------
For *everyone* out there trying to print using RO3.x printer manager, (this 
advice is direct from CC):-

 #1   MAP as many fonts as possible to the target system printer that you're 
going to print out on. - CC


For example the VAX mainframe here has got a Apple Laser Writer NT II, so use 
the LW NT II driver in the Apple printer directory and *MAP* as much as 
possible.


#2 If you have to file transfer to a system (i.e. your computer is not hooked 
up to the system) uuencode the POSTSCRIPT file *before* transferring (using 
FTP), and uudecode it on the target system. - ME.

 This is brutal, but effective.... 100% success rate so far using this method.
 
If Acorn could specify that the line length of the dumped fonts (i.e. the ones 
you can't map) in postscript be no longer than 80 Chars, then you shouldn't 
need to uuencode the &^%$%##$'ing stuff in order to transfer it to a 
mainframe/network via FTP (3 1/2 " disc -> network).


#3 Adobe SPECIAL Fonts, like Zapf.dingbats, MathGreek (CC) and Symbol must have 
an "Encoding" file in the Outline font directory. You must also specify adobe 
special in the !Fontprint (?? the one that maps the fonts ??) to get the 
mapping correct.

 I've hacked up some encoding files and acquired others from various sources 
(CC/Acorn [et al]), so if you're in a situation like brucie, drop me a line.


P.s. I took me 3 months of re-reading the manuals to finally click over what 
the hell the manuals were on about!!!
From Martin Glanvill		(mcg@waikato.ac.nz)

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

----------------****=====| A quote to make your day |======****-----------------
"White House carpenters have reworked the master bedroom, remodeling it so that
 Ronnie can sleep with his head in the hall.  That way, by the time he wakes up,
 somebody will have already shined his hair."
-------------------------------------------------------------------------------
Newsgroups: comp.sys.acorn
From: lorcan@cix.compulink.co.uk (Lorcan Mongey)
Subject: Re: FrontEnd module wanted
Cc: lorcan@cix.compulink.co.uk
Reply-To: lorcan@cix.compulink.co.uk
Date: Sun, 27 Sep 1992 22:41:00 +0000

In article <5615@tuegate.tue.nl> frankp@blade.stack.urc.tue.nl (Frank
van de Pol) writes:
 
>I have problems various programs that require a module named
>'Frontend'. My problem is that I do not have desktop C (C release 4),
>which is shipped with the odd module.
>Are there any other ways to achieve this module ?
 
You can get it on the Risc User monthly magazine disc for June 1992. It
costs #4.75 from Beebug.
 
Lorcan
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Sat, 3 Oct 1992 06:35:33 GMT
Organization: Computer Science Dept. University of Auckland

kortink@cs.utwente.nl (John Kortink) writes:

>It is not. In ARM code it is 100% possible to use new features. In C it
>is obviously much less as you have no low-level control over the code
>produced. This is *exactly* why people program in ARM code, TMOTA.

Well I personally just write bits of Arm-code for the odd occasions where
I need more access to low-level constructs, and link it with my C compiled
code. But if you want to make life difficult for yourself programming all
the high-level stuff that C provides for you, go right ahead.
-- 
_________________  "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: nicho@VNET.IBM.COM
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
Date: 1 Oct 92 15:46:34 GMT
Reply-To: nicho@vnet.ibm.com

In <BvG26F.L82@comp.vuw.ac.nz> Gavin Flower writes:
>It was never stated that "C", should, or would, always be used for
>major applications!
 Umm excuse me, but that is _exactly_ what was stated.

 -----------------------------------------------------------------
               ** Of course I don't speak for IBM **
Greg Nicholls ... nicho@vnet.ibm.com or nicho@cix.compulink.co.uk
                  voice/fax: 44-794-516038