From: K2H (Ron BOYCE)
Subject: LOTTERY and POOLS (Issue53)
After sending the above Program to
Chris I accidentally discovered that
the Program was NOT picking numbers
at random.
I tried various ways to correct this
without success. I even enlisted
Chris's help, but his solution was
equally unsuccessful!
After looking at page L2.59 in the
Reference Manual Part 2 I found the
answer! Adding a new line 1042 solves
the problem:-
1042 dummy=RND(-TIME):REM: Re-seed
the generator 'randomly'
My apologies for this error. As I am
only 76 I hope to improve my
Programming capabilities in time!!!
From: 20G (Roy Dickens)
Subject: The improved SNIB by
Paul Clucas (K6X)
It was a good idea of Paul's to do a
View format to print out the extra
help and a grid. The main program I
feel could be improved by having the
grid in a 'window' and just the
guesses scrolled.
Subject: LOTTER8 by R.Boyce (K2F)
This is a well presented program
giving another random number getter.
Take away random numbers and then use
the rest. That's different.
Subject: YULE LOG by J. Davis(K2F)
A nice warm looking fire for
Christmas showing us how to do it in
Mode 5. Alas it was an illusion because
the glow would not toast my bread but
it did warm up my 'chips'!
From: D5B (Jon Ripley)
Subject: Red & Blue Colour Messages!
Just a quick comment to all those
8BSers out there! The colours Blue and
Red cannot be seen properly (or even
at all) on some TV's and monitors.
(Especially the mono/b&w ones!)
From: D5B (Jon Ripley)
Subject: Timekeeping
I've tried Chimpanzees but just get
toungue-twisted after a while,
elephants are a bit too swift for my
liking and I find that the most
accurate (alcohol free!) is this...
1...1000...2...1000...3...1000...
Those with inbuilt clocks can do
better of course with the old
favourite...
1...and...2...and...3...and...4...
Perhaps the BBC itself could be asked
which method it uses!
From: D5B (Jon Ripley)
Subject: MOS Plus Instructions
Instructions for the Dabs Press MOS+
Rom featured in issue 3 of BUG
magazine. (Out on September 30th)
From: D5B (Jon Ripley)
Subject: In Issue 3 Of BUG.
Here is an overview of what is in
issue 3 of BUG...
Part 3 in the continuing series
covering the memory maps of the BBC
series of computers, covering
locations &C000 to &DFFF.
A new series of articles and programs
by Gordon Horsington covering all
aspects of the DFS filing system.
Another excellent graphics demo from
the keys of our favourite authors.
Issue 3 out on 30th September 1996.
If you would like to subscribe to BUG
then please contact me at the address
below (or phone me).
The issues come out every seven weeks
and cost just `1 if return postage
and packing and a formatted disc are
supplied. The issue is availiable in
both ADFS and DFS formats. Both DFS
and ADFS issues are identical and I
prefer if members request DFS issues.
Each issue of BUG complements other
issues and the magazine will build up
into a reference work for your BBC.
Games, demos, music and utilities also
feature on each issue!
If you would like all 3 issues then
please send payment, 3 formatted discs
and return p+p to the below address:
Jon Ripley, BBC User Group, 56
Longstone Road, Eastbourne, East
Sussex, BN21 3SJ.
Or phone (anytime): 01323 732597
Cheques should be made payable to
J Ripley.
From: 3WU (Fred Price)
Subject: PRINTOUTS
It is very handy when you want to
have a copy of a message printed out
in front of you to study, but I find
on printout it has one big curse; on
overlap it prints out the last few
letters on the next line, then carries
on to the next line, meaning it wastes
a lot of lines and it is not a neat
and tidy job at the end.
Is it not possible to shorten the
line length a little to make it
printout line by line? That would
improve the present system even more.
So how about it lads and lasses, get
your thinking caps on and sort this
one out.
Fred Price 3WU
From: E2G (Derek Hill)
Subject: Christmas greetings
Thankyou to OE7 (F.W.Nevin) and
20G(Roy Dickens)for your greetings and
good wishes, and your very attractive
Mode 7 screen Roy. It was nice to get
them on my first disc as a new member.
All the best to you too for 1997.
To: D6E
From: E2G (Derek Hill)
Subject: Labels by D6E(Richard Harker)
Perhaps like me, you want to know
the history of the disc? Where did it
come from? How many places has it
seen? People has it met? Programs and
text has it held? How many hours of
labour has it been part of? Ah! what
tales it might tell! Knowing all this
someone might even like to write an
"An Ode to a Disc". I'm sure it
could be a gutsy tale.
But now all it has are labels
stuck on it, old and messy with use.
To cover with yet another label
only seems to extend the problem, and
the mess I've got into trying to get
them off......!
I notice you can get nice
expensive ones now that either peel
off easily (so they say) or you can
wipe/rewrite the label. Either way,
history is lost for ever.
So why not thinks I, put a
post-it note on the pocket to carry
the details? (Don't forget a key of
course to link disc and pocket.)
These notes can be saved, and
in the latter days the story of the
disc will be there for all to see.
And a comic book of disc adventures
writ, to exercise someone else's wit!
Thanks Richard for sparking off
some thoughts. Bye for now,
Derek.
ReplyTo: K6N (Brian Raw)
From: K8G (Jonathan Harston)
Subject: Diary 1997
Quite a good program, but I suggest
some modifications. These are
contained in the program on the disk.
1: In setting up X% and Y% to call an
OS function, you don't need to set X%
MOD 256 as the call only uses the
bottom byte anyway. A more concise
phrasing would be:
X%=W%:Y%=X%DIV256
2: In PROCload and PROCsave, OSFIND is
called directly. Why? There are
functions already in BBC Basic to do
that for you, OPENIN, OPENOUT and
OPENUP. The following is PROCload and
PROCsave rewritten:
DEFPROCload
IFP%<7ANDdfs%:*DRIVE 0
IFP%>6ANDdfs%:*DRIVE 2
F%=OPENIN($W%)
PROCdisc(4,&398)
PRINTTAB(2,2);
VDU23,1,E%;0;0;0;
CLOSE#F%
ENDPROC
:
DEFPROCsave
IFP%<7ANDdfs%:*DRIVE 0
IFP%>6ANDdfs%:*DRIVE 2
F%=OPENUP($W%)
T%=0
IFE%:PROCdisc(2,&398)
CLOSE#F%
F%=OPENOUT":0.$.DIDATA":PRINT#F%,
L%,P%,epson%,sysclk%:CLOSE#F%
ENDPROC
3: You should never abbreviate
*commands within a program. You may
know what's in your machine when you
use them from the command line, but
how do you know what *DR. will match
to in somebody else's machine?
4: TIME$ is useful, but it is only in
BASICs in the Master series and later.
Earlier BASICs don't have it, even
though the MOS may provide a real-time
clock. The recommended way to read
the clock within a program is to call
Osword directly:
T$=FNtime
and
DEFFNtime:X%=B%:Y%=X%DIV256:A%=14
?X%=0:CALL&FFF1:IF?X%=0:="" ELSE
=$X%
5: J.Ripley's disk format checker
takes a bit of time, and the user
could think the program has crashed.
If something pauses, generate some
output so you know what's going on.
From: K8G (Jonathan Harston)
Subject: Messaging system
Has anybody noticed that the
information about the messaging system
has f8 and f7 the wrong way round?
I've written a small program that
produces a function key strip with the
key functions on; program MesgKey.
Also, why do some programs, like this
one, set the colours to start on f0
instead of f1 as the MOS uses? Red is
colour 1, white is colour 7; it gets
confusing subtracting one every time.
Also, I find it more natural to have
the colours on Shift-fn and Ctrl-fn;
these programs put the colours on
Normal-fn and Shift-fn. I've modified
my personal copy of SendMes to use Red
on Shift-f0 instead of Normal-f0.