After the single topic of the last issue I thought we'd have a change, with rather a mixed bag this month.
Thanks again for your letters; they provide both inspiration and information. The good news is that because of your enthusiasm 512 Forum is to become a regular column. Unlike some publications, BEEBUG does respond directly to its readers, so if you want the Forum to continue keep the letters coming. I was pleasantly surprised by the number in January, but this means it's time for some guide-lines.
Inevitably, some letters relate to highly specific points which may not be suitable for general inclusion in the Forum. That's OK, I'll try to reply to letters personally in these cases, but you please do quote your membership number in all correspondence, while an SAE does help if you want a direct reply.
I'll try to answer queries, but clearly I don't know every package. Several readers have again raised the idea of a software compatibility list. Although I've mentioned this before, let's see what can be done.
Acorn have for some time compiled a list of known software and the latest version will be included in the Dabs 512 User Guide (to be published shortly). The trouble is that such a list is never complete. This is where you come in. If you have definite knowledge that a package does or doesn't run, or you know what's needed to make one work that otherwise doesn't, let me know about it. As the data accumulates we'll publish updates and additions in the Forum.
This can continue indefinitely, but it's up to each of you to pass on your knowledge for the benefit of fellow 512 users. My view is this – apart from 512 support by BEEBUG and Dabs Press we're virtually on our own, so we have to help each other. Over to you.
Next, updates on items from December's Forum. Thanks are due to both G.R. Smith for his letter and to Richard Grant for his extra efforts on your behalf in clarifying the situation on Digital Research manuals.
The 'official' line, as stated in December, had been checked with Digital, but, it seems that a different result is possible if your enquiry is unofficial or private. Richard suggests, however, that you may need to be fairly persistent (and ideally speak to a lady called Patricia – won't she be pleased?).
Although DOS+ is not a current product and therefore is no longer officially supported by DR, they can supply manuals after all. The user guide for example, is £17.50 in loose sheet A5 form, plus £6.50 for the optional hard cover ring binder.
Programmers References are also available, but at rather higher cost, since there are two parts, one for CP/M and one for DOS Plus. These will only be of interest if you write your own code, and the contents are exactly the same as the Glentop book mentioned previously (BEEBUG Vol.7 No.7), so check the prices carefully. A System Reference Guide is also available, again at higher cost, but be warned this is intended for system implementers and as such is of even more limited interest, even to programmers.
Having kindly been lent by Acorn the Winchester on which all the 512 software was developed, I can also tell those of you that do program that several standard documented CP/M and DOS+ interrupts have been deleted from the 512 implementation, by no means for obvious reasons in some cases. If you write your own code don't be surprised if some of the documented interrupts don't work! By the way, if you didn't understand these comments you don't need the last three manuals.
To pursue these manuals phone Digital Research on Newbury (0635) 35304 and ask for Customer Support. I'm told they take credit cards, so payment is simple.
Now for some other news, unfortunately not so good. I have again checked with Solidisk, and the latest on the PC+ is that the last batch consisted of 25 units and that they have no plans to produce any more. These were priced at about £120 because of the small quantity, and all had been sold within a fortnight. It looks like that's the end of the matter as far as the PC+ is concerned.
The reasons given are the current high cost of RAM – STL's existing RAM stocks are exhausted and new supplies would now cost twice as much, meaning that the PC+ would retail at over £200. In addition, STL are moving out of the Acorn market, and I've been told that they have no further interest in Acorn add-ons. It's a pity: although I don't have a PC+, I do know that it is well made and works reliably.
It looks like the only way you'll be able to expand your 512 to a megabyte from now on will be to build the memory extension detailed in the Dabs 512 Technical Guide.
I must confess to a mistake in the December issue, concerning the Dabs 512 utilities disc. The disc catalogue program 'DTYPE' allows you to catalogue DOS+ discs from ADFS, not the the-other way round. Sorry, I obviously wasn't working very well that day because I didn't notice at the time.
There is no problem cataloguing an ADFS or DFS disc from DOS+ by means of the 'STAR' command, as many of you will know, but this provides an excuse to cover a topic that has been raised in several letters.
Specifically, why is it that programs like BBC screen dumps or other routines can't be used, or crash the system if called from DOS.
First, if you're not too familiar with 'STAR' just try the following. Start at the normal DOS prompt, with a disc containing 'STAR.CMD' in drive A. Enter 'STAR' and press return.
You will find the screen clears and a '*' prompt replaces the DOS prompt, appearing near the bottom of the screen. You have now connected yourself directly to the BBC's OS command line interpreter, and can issue many BBC star commands from DOS, including some filing system commands. Be careful though, you can't do everything.
Try putting an ADFS disc in drive B and then try the following commands, pressing Return after each one:
mount 1
cat
in.*
map
free
You'll see that the disc is accessible using completely normal ADFS commands. You can also change directory, 'type' or 'dump' files and so on. Note that you needn't enter a star before each command, but if you do so out of habit it's harmless. To exit to DOS just press Return without an entry.
DFS discs can be accessed in a similar way (on the Master) by means of the temporary filing system. You can also issue FX calls and theoretically other * commands to ROMs in the host machine. If you decide to experiment a bit, don't do it if there's data in the 512, because much of the BBC's software will crash the system.
The thing you must avoid is altering either the host's or the 512's memory. For example '*LOADing' a BBC file will transfer the file contents to the 512's memory, not the BBC's, unless the file's load address is prefixed by &FFFF. Loading a BBC file will therefore corrupt DOS, even if it's not instantly obvious.
If you want to see how delicate things can be when you start experimenting, enter 'STAR FX13,4'. Be warned, it's the last thing you'll do before re-booting the system. Try it and see.
*FX13,4 turns off event 4, the screen vertical synchronisation event in the BBC. In an otherwise 'idle' machine, event 4 isn't even enabled normally. It is for DOS though, and if you disable it you'll instantly paralyse the entire system.
The reason for this simple but dramatic demonstration is to warn you against making assumptions about what you can do. The cost could be hours of work if you attempt something unusual or untested with data in the 512.
The point is that most BBC service ROMs and all languages must alter various OS settings or vectors in the host to suit themselves or to carry out their functions, and many also expect to be able to use memory too. DOS+ is no different, so these actions, if carried out by other software, crash the system when DOS is active. Here's why.
First, booting DOS always turns shadow RAM off, unless you have a non-standard shadow set-up in a model B. Of course starting DOS with a hard break normally turns shadow off in these cases (if you insist that shadow stays on you only get a blank screen in DOS anyway, not much use!).
Also, DOS+ intercepts four vectors in the BBC, generates two unknown events, and changes several other MOS settings too. Running the tube and disc software uses practically all the BBC's available RAM including that reserved for screen display (&3000 upwards).
I haven't bothered to work it out, but I'd guess there are in total perhaps about 500 to 1000 unused bytes in the BBC host when the 512 is running. The unused bytes aren't all together in one place either.
It's easy to see that if BBC routines can't use main RAM, can't intercept vectors and may neither enable nor disable events there's really not much they can do. If DOS+ is to continue to run, software must be specially and very 'legally' written to permit this. The simple fact is that most native BBC software isn't written that way, so for example preventing the screen clearing in 'STAR' would not be enough to allow, say, a BBC screen dump to work.
Restrict 'STAR' to things like 'FX6' to enable or disable printer line feeds, 'TV0,1' followed by 'pcscreen' to enable or disable interlace, or 'FX5' if you switch between serial and parallel printers. Used like this you'll have no problems. Try something more adventurous and you might well run into trouble.
'STAR' can also be issued as a composite command with a tail for one-off operations. For example, as the FX13 is above, or to stop line feeds being sent to the printer you could enter:
star fx 6,13
Used for single commands like this 'STAR' is automatically followed by an immediate return to the DOS prompt.
I'll close with a simple but neat idea from Gordon Sweet for Master owners, also using 'STAR'. Having cancelled the micro's line feed in DOS by using 'STAR' in his start-up 'AUTOEXEC.BAT' file, Gordon has gone a step further, automating the exit from DOS with another batch file, like this:
star
fx6,0
configure notube
echo Now press CTRL/BRK
Call the file 'FINISH.BAT' (or anything suitable, but NOT 'exit', that's a DOS command) then to leave DOS simply enter the command – 'finish', pressing Ctrl-Break when instructed. The batch file can also contain a 'BYE' to park hard disc heads if required and as Gordon says, can include other *configure commands (e.g. to select DFS instead of ADFS, internal/external tube etc) all of which come into effect immediately you carry out the hard-break.