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
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 becausethe 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 expensiveones 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,
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.