From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : An enquiry and a suggestion from Hugh Williams
In connection with Hugh's DIRlock utility; Hugh was thinking of getting
the program to execute itself within the DFS file buffer workspace (not
exactly "legal", but...) in order to avoid the incompatibility problems
with programs which use pages &9 and &A. However, this workspace can start
at several different memory locations, depending on which other paged ROMs
have requested workspace first. (For example, Hugh's DFS file buffer
starts higher in memory because his ADFS file buffer is below it). Can
anyone find a way of writing a program which will find out where the
workspace for each ROM starts?
I think that's what he said, anyway. Hugh can be contacted via the 8BS
messaging system (see Issue 20) or direct on 0873 810162.
Hugh has also suggested that anyone who codes additional supporting
functions/procedures for the Small C Compiler should send them in for
publication in 8BS, so that everyone else can make use of them as well.
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Resolve Communications bulletin board
John Carpenter (user I.D. 53B) has asked me to mention that his renowned
bulletin board (930 users) will soon be back on-line. The number is 0438
832824, 24 hours a day, speeds are V23/V21/V22/V22bis.
From : 15A (Steven Flintham)
To : 999 (All members)
Re : 68000/80286 processors
Following D.G. Shimmin's mention of the 68000/80286 "code bit" in sideways
ROM images, I just thought I'd mention that I can remember reading in an
article somewhere (I think it was about the time that the original ARM
second processor was released) about Acorn developing a 68000 second
processor for their internal use. It was never made publicly available, of
course, but I can't see the point in having a "code bit" in ROM's anyway,
as you wouldn't get much 68000 code in one!
-- Well...you could fit quite a lot of code in two 32K ROMs, considering
the original 68000 Apple Mac was only 128K - or perhaps Acorn just added
it for the sake of completeness after including bits to designate code for
other processors.
From : 15A (Steven Flintham)
To : 999 (All members)
Re : Electron BASIC
He also asked which version of BASIC the Electron used. Well, I still have
my original #199.00 Electron (those were the days - it was the first
computer I ever owned!), and I can say with confidence that the BASIC is a
version of BASIC II - it supports OSCLI and doesn't seem to have the
obscure INSTR bug in BASIC I.
-- Thanks for the info - this makes Electron-compatibility a more likely
possibility for future issues (see elsewhere). Incidentally, can you
believe the Electron was the extra-cheap version of the BBC B and yet the
ZX Spectrum still underpriced it by #20.00? (Not quite as many features
on the Spectrum, but 10K more RAM, a Z80A processor, and MUCH more
software available, especially games).
From : 15A (Steven Flintham)
To : 999 (All members)
Re : Astronomy programs, copyright of routines published in books
I have written a suite of astronomy programs, concentrating mainly on
solar system astronomy, which I would like to submit to 8BS, probably for
inclusion in the TBI. The problem is that they were written around
versions of the routines presented in Peter Duffet-Smith's "Astronomy with
your personal computer" - does anyone know what the copyright position is,
either on this specific book or on other similar situations in general? I
don't want to make any profit from the book's routines, but then again it
could be argued that I'd be denying the publisher sales by "distributing"
the routines, albeit in a limited form. Can anyone help?
I can be contacted at: 6 Laythorpe Avenue, Skegness, Lincolnshire, PE25
3BX, or via the 8BS messaging system - the latter might be preferable as
it seems that the answer might be of general interest, due to the
innumerable books providing "libraries" of routines.
-- I have no specific information on this, but presumably anyone
publishing a book purporting to supply useful routines for readers to
incorporate in their own programs can hardly complain if these routines
are then used! (Unless any publication states otherwise specifically).
To : 999 (All members)
From : 709 (H.S. Williams)
Re : Electro_rock, video wanted, PBM games
Has anyone out there heard of a new group called 'The Ministry', they're
supposed to be a cyberpunk (William Gibson) influenced electro_rock group
with an album called 'Psalm 69' or something. Any info?
Also has anyone got a copy of, or can get hold of a copy of 'A Clockwork
Orange', Stanley Kubrick's film of Anthony Burgess' book, on VHS video
please (Good money paid).
Is there anyone who plays any of the following Play By Mail games: Serim
Ral, The Keys of Medokh, or Avalon 500 Chronicle of Kings. If so get in
touch to exchange ideas, information, etc...
-- To add to the list of PBM games; if anyone plays Crisis, It's A Crime,
Golden Realm II, Delta Nine or Star Cluster they might want to get in
touch (I have just won Game 18 of Star Cluster, by the way!) Incidentally
the articles on PBM gaming will be included fairly soon; perhaps Hugh
would like to make a few comments on the games he is in? (And anyone else
who plays PBM games?)
From : C83
To : 999 (All members)
Re : AMX Stop Press, EPROMs
I own a BBC B issue 7 and have AMX Stop Press. It takes up 2x16K ROMs &
sockets. I was wondering if it would be possible to blow both ROMs onto
one 32K EPROM so I have an extra socket free for another ROM?
-- I imagine this would definitely work on a Master (at the cost of two of
your SRAM banks), but I am not at all sure that the BBC B has any 32K
romslots - you certainly can't plug a 32K ROM into a 16K romslot - can
anyone say for certain? Queries concerning paged ROMs occur quite
frequently, as the Acorn manuals don't give much, or very clear,
information. See below for a question of my own concerning this.
From : C83
To : 999 (All members)
Re : DIY hardware projects
Has anybody made/got any DIY hardware projects for the BBC? If so could
you tell me which ones you have and if you would be willing to give me a
copy of the circuit diagrams etc.?
-- I will recommend Maplin Electronics - they often do add-on projects for
home computers - but you probably know that already. They have sent me a
circular about their latest catalogue (the first time they have written to
me in five years!) which looks the same as all their other catalogues;
large and full of electronics.
From : YJ2
To : 999 (All members)
Re : Last Ninja 2
Has anybody managed to complete Last Ninja 2? I have reached the last
level many times, but keep on dying in the dark room, how do you get past
it??? Also what is the red object on level 1 near the wall you have to
climb up with the hook (ice axe?) ??
Incidentally, if anybody is stuck and can't get past the fans which appear
on numerous levels, all you need to do is to hold down 'J' (Large Jump),
keeping as close to the fan as possible until you reach the ladder or door
at the other side.
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Co-processors & paged ROMs
HiBASIC and HiEDIT on my 65C102 co-processor have to be loaded from disk
each time I want to use them. Does anyone know how to get them into an
EPROM (they are only 16K each) in such a way that they will go into the
right place (&B800) in the co-processor automatically, so that I could
(for example) configure HiBASIC as the start-up language, and call HiEDIT
straight from ROM? I suppose I could put both of them on ROM as
machine-code programs, but this would not allow me to select them as
start-up languages.
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : EDIT technical details
Sorry for bombarding VIEW etc. users with more rubbish about EDIT ... Does
anyone know where it stores the "Current filename" and cursor position, as
I am thinking of writing a little utility for it? (Either for EDIT or
HiEDIT or both).
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Using HiBASIC/HiEDIT
Although BASIC IV has the command EDIT, it DOESN'T load BASIC code into
HiEDIT if you have it available. To get round this, use EDIT <RETURN> from
BASIC as normal, then select COMMAND LINE (f1) and type *HiEDIT (ensuring
that your library disk or whatever to load it from is in place), then use
OLD TEXT (f9) to get the text back again. Incidentally, if anyone knows a
(simple) way of doing this without entering EDIT first, I would like to
know! (Because of buffer sizes etc.)
Similarly, to take text from HiEDIT (or even EDIT) straight into HiBASIC,
select RETURN LANGUAGE (shift-f4) and enter HiBASIC as the language name
rather than BASIC (again ensure that the disk/directory/whatever to load
HiBASIC from is in place).
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Co-processor incompatibilities
The problems my co-processor has with high-tech games are only to be
expected, and not really a problem anyway (some games are very hard
running at twice normal speed!) However, it is annoying when helpful
utilities fail to work.
The Master UtilROM provides *AS, which reads the filename you want to save
a BASIC program as from a REM statement at the start (using something like
"SA.$(PAGE+7)"). When used in a co-processor, this command seems to read
the string from the wrong memory (presumably the I/O processor) and hence
can't find the string (it supplies the error message "REM format
incorrect" even though it's not). Does anyone have a solution?
Similarly the UtilROM's *WIPE for ADFS fails to work, though *BVERIFY is
O.K.
Finally, although *FX200,3 followed by CALL!-4 will force a hard reset
normally (useful for installing ROMs automatically from a !BOOT file),
with the co-processor running the effect is to quit BASIC and return to
the command line, but no hard break. Can anyone suggest anything?
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Enquiries to PD libraries
Jamie Hosker of Mad Rabbit PD (user I.D. 21H) has asked me to mention that
if you are writing to a PD library for their catalogue you should always
enclose an SSAE, as he has had a lot of letters from enquirers who
haven't, and this causes prices to rise unnecessarily. Most 8BS members
usually remember to, but if you know people who don't, remind them - they
will probably not get a reply otherwise.
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Master Advanced Reference Manual
Does anyone have, or know anyone who has, a copy of the Master Advanced
Reference Manual they would be willing to sell me second-hand? (That's the
MASTER Advanced Ref. Manual, NOT the New Advanced User Guide NOR the BBC
Micro Advanced User Guide!) I'll pay between #7.50 and #10.00 (plus
postage) depending on whether I'm in a good mood or not.
From : 483 (D.G. Shimmin)
To : 999 (All members)
Re : Possible ADFS bug
I have recently discovered that a (correctly-coded) program of mine fails
to work under my ADFS 1.50, but works perfectly under ADFS on Hugh
William's BBC B, and also under ANFS. This perhaps indicates some sort of
problem with ADFS 1.50.
If anyone is interested, the problem concerned *EXECing a !BOOT file which
CHAINed a BASIC program (part of a larger system) in the directory above;
any PRINT or INPUT commands in the program then produced a "Channel on
channel 56" (or similar) error. Surprisingly, the error NEVER occurred if
the BASIC program was CHAINed without *EXECing the !BOOT file. Considering
the nature of the problem, perhaps there is something up with my BASIC
(IV) as well.
Even more weird, the program was initially developed on the same machine
(between late 1991 and early 1992), and never showed any problems under
ADFS. It was then copied onto ANFS for further development and
Econet-testing, and I only discovered the bug when I copied it back to
ADFS in about April 1992; earlier versions (never transferred to ANFS)
displayed the same bug. It can't be my co-processor because I bought it
after June 1992, and it can't be physical damage because I only opened the
case once before June 1992, to replace the internal battery in December
1991; the program still worked fine for weeks after that date. Perhaps
some sort of power spike or something caused damage, but surely if it
affected the inside of a ROM chip the whole of the rest of the PCB would
have been scrambled as well?
Anyway, I will put a copy of the problem program on all the ADFS issues if
I remember, so that everyone with ADFS can check it out on their machines.
It isn't really serious (the system in question is only for Econet anyway,
and I've found no other problems with my ADFS), but worth looking into.
From : 15A (Steven Flintham)
To : 999 (All members)
Re : Dr A.J. Travis' Small C Compiler
It's been quite a while since I got a copy of this from BBC PD, and almost
as long since I last used it. Does anyone have, or is anyone prepared to
put together, a list of "supported" features so that I might be able to
use it to learn C programming on until I get a cheap second hand copy of a
commercial C? Is Small C a "defined" standard, or does it just signify
"cut down?" And secondly, (I know this is not strictly an 8-bit issue, but
it is vaguely related and I'll keep it brief...) is there anyone with an
Archimedes reading this who can help me to get it to run under emulation
on the Arc? - I've only got 40T S/S disc drives on my BBC B and Master 128
and although it can just be persuaded to run on the Master under ADFS,
it's very fiddly with lots of file swaps.
Editor's (rather lengthy) note:
The Small C Compiler, available via the TBI pool, also includes a massive
quantity of additional notes on the commands supported, and installation
notes, written by Jonathan Harston of "HADFS" fame (who used to be member
W79, and contributed to fairly recent 8BS issues, but has not replied to
my letter inviting him to re-join; any information on his whereabouts
(Hong Kong?) would be very helpful). I have sent the relevant parts of
this to Steven.
The compiler documentation, although it includes a considerable amount of
sample sourcecode for the user to learn from (including the C sourcecode
for the compiler itself), does not aim to teach C, so members should
either get a book on it, or the C tutorial from the XBI pool (disk 48 of
BBC PD for non-ADFS users).
With the same aim as Steven, i.e. learning the basics of C before moving
onto a more powerful/complete compiler, I have found the compiler fairly
easy to use at a simple level in conjunction with EDIT (to write the
sourcecode files) and the book "Learning to Program in C", by Noel
Kantaris (thanks Alex). C has a fair number of advantages - it is almost
as easy to write as BASIC, and is supposedly more structued, but compiles
direct into machine code for extra-fast execution, and is also compatible
with any machine with a C compiler (so, for example, you could write a
program on the Beeb and then run it on any PC or even a mainframe!).
The disadvantages are that you can't simply type RUN while half-way
through coding a program to test it, but have to compile it then run it -
with Small C this takes a couple of minutes for a practice program with 15
or so lines, but a lot longer with something more lengthy. Also it takes
up a fair amount of memory - the Small C compiler inserts about 7.5K of
supporting code of its own to accompany any stand-alone routine compiled,
although this is hardly a problem unless you are writing something that
will produce more than about 8K of object code - that's a lot of pure
machine code! See the article by Stephen Mumford for more detail about C.
In his documentation Dr.Travis quotes several books as his source for
"Small C", but I think his implementation depends more on the things he
had time/space to put in rather than a full implementation of a rigidly
defined standard; Hugh Williams has commented that the range of
commands/functions supported is VERY limited. However, I would very much
encourage all members to get hold of the Small C Compiler and have a go
with it, whether you are fed up with the limitations of BASIC and the
difficulty of assembler or have never bothered learning either - it is an
extremely cheap way to start learning a powerful universal language.
As for emulating a Beeb on an Arch, we all know the Beeb is superior to
the Arch in every possible way, and you can't replace it with some clever
emulator. (I'm not just being sarcastic - the 6502 emulator on the A3000
is no match for even a BBC B in speed, lacks shadow RAM, and quite often
fails to work). Actually the compiler won't run on my 65C102 co-processor
either, which is extremely annoying. Does anyone have any answers?
Messages to you: