Master 512
Forum by Robin Burton
Beebug Vol. 9 No. 4 August/September 1990
This month I'll carry on with the topics that were to follow the article of two months ago. The delay has proved beneficial, because since then I've had a letter from a Forum reader which included a very useful tip.
CD AGAIN
Towards the end of the June Forum on the subject of directory and path names, I had mentioned the change directory command, 'CHDIR', or 'CD' for short. That there's more to say about this subject will be obvious to most of you, but there's a good reason why I didn't go further at the time. At this point perhaps I should explain how the content of each issue of the Forum evolves.
Usually (though I must admit, not always) as I sit down to write each Forum I have a pretty clear idea of the topics for the month. At the same time there is rarely a detailed plan, all I have in mind are the main points I want to raise. The truth is, therefore, that more often than not I "make it up as I go along". The result of this technique (and I use that word in its loosest possible sense) is that I begin with the thought that I'm going to run out of ideas before I reach the end of the article, but the reverse is more often the case and I run out of space before I've covered everything I want to include, like this month, hence the 'extra bit' (thanks Mike).
So it was two months ago. I'd like to have developed the use of 'CD' further and intended to do so, but last month's digression delayed this. In the time since then I've learned of another use of 'CD', one which I freely admit I'd never tried, so all credit to the author. Before I give you this tip I'd better cover the points I had intended to go on to, otherwise it might not be understood by some of our newer 512 converts.
PATH
Some of you will be familiar with the floating drives, N:, O: and P:, though these are much more likely to be used in hard disc systems where the number and structure of sub-directories is unavoidably more complex than on floppy disc. I've mentioned floating drives before in the Forum, but even so I know that some of you aren't sure how they work, particularly as DOS reference books won't mention them because they're actually a CP/M facility.
The 'floating' drives are not physical disc drives, but are notional drive identifiers which can be allocated by the user to real drives or directories. For example you might have a longwinded directory path to which you frequently need to refer. The format of the allocation, using drive N: as our example is:
CD N:=DIRECTORY PATHNAME
where the directory pathname can be any you wish to access.
By using the floating drives you can therefore allocate a single 'shorthand' name to any directory, which the system will recognise and translate accordingly when the short name is given. Practical problems will perhaps show the benefits of this facility better.
Suppose that you have several long directory names that you use frequently and therefore need to type fairly often. Sometimes such names can be included in a 'PATH' command, but the major problem of 'PATH' (as I explained in Forum Vol.8 No.3) is that all the separate paths you want to specify must be given together in a single command.
This is because every new 'PATH' setting always entirely replaces any paths set up by the previous 'PATH' command. The obvious implication is that the total length of all the pathnames you wish to specify must all fit within the length of a single DOS commandline command, 127 characters. Given that each directory name can be up to eight characters and the directory names in any path must be separated by a '\' character and are usually preceded by a drive identifier, you can see that it's quite easy to run out of space if you're setting multiple paths.
Are you limited therefore to very short directory names, or constrained to set only a very few paths?
Well, not necessarily, but to overcome these space limitations you might try attacking the problem from a slightly different angle and this is where 'CD' and floating drives become extremely useful (you see, I got there in the end).
CD PLUS PATH
In my 512 I have a number of pathnames and floating drive settings in my 'AUTOEXEC.BAT' file. Some of them, of course, are short and present no problems. For example, I permanently run a RAMdisc to which I copy all the most frequently needed standard DOS utilities such as COMMAND, FSET, SDIR, CHKDSK, DISK, SHOW, FORMAT, PRINT and so on. All these need loading from disc every time they are called, but from the RAMdisc they operate so fast that they operate just like permanent DOS commands. Also, because access is so rapid, Drive D: is always the first entry in my PATH setup. If any file isn't in drive D: the delay of checking it is so short it's undetectable.
I also run some files from the root of drive C:, mostly with the system attribute set so that they won't clutter the root directory display. These are also general utilities, the ones which aren't used very frequently, but which, even so, might be needed at any time. Therefore C:\ is the next path setting.
The next path I set is the directory holding my word processor applications software, a directory called 'PCWRITE' which is in my main applications directory, 'SOFTWARE', also in drive C:. The full pathname specification is therefore:
C:\SOFTWARE\PCWRITE\
I also use PCTOOLS from Central Point Software as enough of it works correctly in the 512 to justify the megabyte or so it occupies on disc. This too is in 'SOFTWARE', and its path is called:
C:\SOFTWARE\PCTOOLS\
The next directory I include contains my own machine code programs, and its full path is:
C:\ES\PROGRAMS\
I also regularly use an 80186 assembler / debugger which also has its own directory, called:
C:\SOFTWARE\A86\
I have several other regularly used paths, so by now you must be getting the idea. If I tried to specify all these pathnames together in one PATH command I'd probably run out of room. The important point here is that 'PATH' won't tell you there's a problem, you find out later when something doesn't work.
If the convenience of setting paths can't be done by the direct approach, the answer is to use floating drives with the 'CD' command.
The most sensible way is to substitute the floating drive names for the longest pathnames that you manually refer to most frequently, thus saving the most space and effort. The pathnames for the word processor and PCTOOLS are the longest, but I rarely need to explicitly 'CD' to them. There are others though that I often use, but which, without a shortcut need a lot of typing. One example is my source directory, the path of which is 'C:\ES\SOURCES\'. However, by using the command:
CD N:=C:\ES\SOURCES\
in my batch file, when I want to specify this path I can simply call it N:. Sometimes this facility can also be used in 'PATH', so as an example, for the PCWRITE pathname, using drive O: I can likewise shorten that path to O:, and P: for PCTOOLS. Now, using my first four pathnames for illustration, in my AUTOEXEC.BAT file, instead of:
PATH D:;C:;C:\SOFTWARE\PCWRITE\;C:\SOFTWARE\PCTOOLS\
I can simply use:
PATH D:;C:;O:;P:
which as you can see is considerably shorter, and leaves plenty of room for more paths.
The main advantage of floating drives though, is using them when you will need to regularly change directories manually. Although there are only three floating drives and I have used two of them in the batch file, I always reserve one, N:, to point to my working directory, whatever that is at the time. Let me explain.
In the 512 I perform one of two main jobs. One is writing text for various purposes, the other, and the most frequent is writing machine code programs. Taking the latter as the example, all my source code is in a directory called '\ES\SOURCES\' in drive C:. By allocating drive N: to this path when I'm doing this job, I can simply type 'N:' and I have virtually automatically performed:
CD \ES\SOURCES
To edit a source program I just type:
ED PROGRAM.SRC
ED being the main word processor module, and PROGRAM.SRC being the name of the program I'm working on at the time. After editing I can then exit to a DOS shell, type:
ASSEMBLE PROGRAM.SRC
and the COM file is assembled into \ES\PROGRAMS\ by my batch file, ASSEMBLE, with an automatic change of directory to the program directory at the end so that I can immediately test the program. As frequently happens I then need to go back to the source directory to correct or change something I've found during de-bugging, so all I need enter is:
N:
and I'm back in the source directory. This is followed by:
EXIT
to leave the DOS shell and return to my word processor, which still has the source code loaded ready for instant edit.
Not everyone will have such a repetitive operation as this of course, but if you do it's well worth the effort of setting it up for maximum convenience like this. With this setup I can temporarily exit my word processor to a DOS shell, assemble a program, check a specific point in the debugger and return to the source code in the word processor in under half a minute, with the absolute minimum of typing and hence little chance of error.
PROBLEM AREAS
Unfortunately it's not a perfect world and there are a couple of potential problems lurking in these techniques which may become obvious only when you've tried them. The first concerns the way you specify pathnames, and applies whether you use floating drives or not.
You'll have noticed that I specified all the pathnames in full, starting with the drive and the root directory. The reason is that each path will be searched in isolation by DOS, so you can't for example specify '\SOFTWARE\' as one path and have, for example '\PCWRITE\' and '\PCTOOLS\' as alternatives or 'subpaths' within the first. 'PATH' just isn't that clever, so unless you're positive that a pathname will always be within your current directory in the current drive when it's needed you must supply full path specifications.
The second possible problem concerns the use of floating drives only, but it is even less obvious and potentially harder to diagnose. Whether it's a problem or not depends on the software you're using at the time. Some applications will work, others might not so some investment in trial and error may be needed before you can decide when to use floating drives.
If an application uses separate definition files for its configuration options, as many commercial packages do, depending on how it reads path settings it might or might not be able to find these files if you're not in its own directory at the time.
The problem is that the application will load wherever it's called from, because DOS Plus controls that process and of course DOS Plus correctly translates floating drive specifications. However, the reading of configuration or definition files will be done by the program itself, after the main module has begun execution. Since floating drives are a CP/M facility (i.e. not DOS) there's a good chance that many applications will complain they can't find a file, or may alternatively resort to built-in defaults at this point, because they can't translate the floating drive path correctly.
ASSIGNING DRIVES
You can see that with floating drives and the less publicised features of 'CD', there's a lot of scope to customise your 512 for specific operations. Even so there's one variation I've never used.
Colin Price wrote to me from Reading as a result of the June Forum (Vol.9 No.2) to point out another very useful facility of 'CD'. I'd said in that issue that there's no 'ASSIGN' command in DOS Plus, but there are other ways round the problem. Colin wrote to remind me of one of them. CD is capable of providing such a facility.
The general format of the command is:
CD target-drive=substitute-drive
where 'target-drive' is the drive a package may want to access, but 'substitute-drive' is the real drive you want it to use. This looks reasonable given the other uses of CD, that is, to assign directory paths to floating drives, but even so I've never used it quite like this.
To run a package which insists on drive C: when you only have floppies you can therefore type:
CD C:=A:
after which accesses to drive C: will be redirected by DOS Plus to drive A:.
A LAST WORD
As you know I wrote in the March issue about the progress (or lack of) of the 512 Technical Guide, but that things didn't go according to plan is obvious by now. In the event I didn't get the final page proofs until the end of May.
The reasons are academic at this stage, but one fact that isn't is that I really can promise you that the book will be appearing within a couple of weeks of this issue unless the printer has a fire (perhaps I shouldn't have said that)!