Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 7 December 1992
This month I've an interesting tweak for you which really would have fitted in better with a topic covered in the Forum about a year ago.
Since this item is already two years 'late' (or one, depending on which way you look at it) I thought I'd leave the software compatibility information mentioned last month for another Forum.
ECHO OFF AGAIN
You might remember that in Volume 10, Forum discussions centred on ways of removing unwanted screen output from commands executed within batch files.
Well I've recently again come across (or found, rather) a letter which I actually received a couple of years ago from a member about this very subject. Richard prefers to remain anonymous, so I won't tell you any more about him, we'll just move on to the subject matter.
It seems that he'd been looking (quite literally) at COMMAND.COM, and had come across a block of text strings, each of which began with a "!". The particular one that raised his interest, indeed the one that was the reason for the whole exercise, was "!echo on". This, he thought, looked just like a normal manual command, but presumably the preceding "!" character meant something significant to COMMAND.COM. Could it be something perhaps like the default setting?
Before we go any further, I'd suggest that if you want to look at this yourself, and definitely if you intend to follow the exercise, then you put a copy of COMMAND.COM onto a work disc and use that version until you're satisfied everything is correct.
Throughout the following I'll assume that your current drive is A: and that it contains your boot disc plus the standard issue software. One other point to note is that none of this is any use if you're still using DOS Plus 1.2. That version of COMMAND.COM is quite different to 2.1's and the string we're interested in simply isn't there. 2.1 users read on...
If your real copy of COMMAND.COM is set to 'system' remember that you'll need to append the '/S' switch to the copy command, or you'll get a 'file not found' message. For example, to copy the file from A: to B: use:
COPY A:COMMAND.COM /S B:
Of course, if your copy of COMMAND.COM is visible on normal DIR displays you won't need to add the '/S'. When the file is on the work disc you'll probably also need to change its attributes to those of a normal file before you'll be able to update it, the command for which, assuming the file is on drive B: again and FSET is available on drive A;, is:
FSET B:COMMAND.COM [RW/DIR
This command can be issued even if you're not sure of the file's current attributes, so make sure you do it or you might get 'access denied' during the next stage of the procedure. By the way, the 'missing' right square bracket isn't a mistake; as I've mentioned before in the Forum it's not necessary.
MODIFYING COMMAND.COM
To look at the part of the file we're interested in, using EDBIN is probably the easiest method. Of course, if you have another binary editor and prefer to use it, do so by all means, but EDBIN is on issue disc 1, so everyone can follow this example.
To load the file for editing, the command is:
EDBIN B:COMMAND.COM
which will produce a display of:
Size of file = 006908 bytes
Number of bytes read = 006908
-
As you can see from the two figures, the entire file has been read into RAM so you can now examine any part of it. The '-' is an invitation to enter a command and the one we need is 'd', for display. If you want to refresh yourself on the EDBIN commands just enter 'h'. The 'd' command is followed by an offset address, which in this case is 5ddd. The format of the entry is simply as shown in figure 1, and the hex and ASCII display will be produced as soon as you press Return.
|
|
Figure 1: The area
of interest |
You can see the command '!echo on' at the start of the first line, and this is what we're going to change. You'll also notice that this command is terminated by a null, followed by '%s' then a carriage return and line feed, plus two more nulls before the DR copyright notice. Obviously if we change 'on' to 'off' we need an extra byte, and the solution to this is the obvious one, which Richard discovered: just 'pinch' one of the two nulls before the D at the end of the line.
To do this you need to use the 'e' (edit) command, followed by the address you wish the cursor to appear at. If you're not familiar with EDBIN I'd suggest you enter:
- e 5ddd
which will place the editing cursor at the beginning of the first line of the above display (just one line will appear this time), then move the cursor to the first of the two null bytes manually by pressing the right cursor key.
All you need to do now is to enter each of the hexadecimal values from the next byte on the left of the cursor position into the current byte, and then press cursor left to move to the previous byte to change that too.
For example, to 'move' the '0A' just enter 'A' then press cursor left. Next, enter 'D' followed by another cursor left, then enter '73', press cursor left and so on. When the cursor gets to the zero byte following '6E', that is, you've just amended '25' to '00' and moved to the next byte left, enter '66' and move left one byte, then repeat the same entry. Your display should now appear as shown in figure 2.
|
|
Figure 2: The amended
bytes |
When you're satisfied this is correct press Ctrl-C to end the edit (don't worry that this messes up the display, that's quite normal), and then you can save the file. If you want to check your changes before saving the file just issue the original display command again, d 5ddd, when the display will appear as in figure 1, but now showing the amended command string.
To write the file back to disc enter 'w' (write), followed by Return, then 'q' (quit) and Return to exit to DOS.
All you now need to do to try this amended version of COMMAND.COM is to prepare a new boot disc, replacing the original copy of COMMAND.COM with your modified version. Again you might need to set the destination file to read-write/directory before the copy, and to make the new version of the program disappear from DIR displays, assuming the new disc is in drive A:, is to enter:
FSET A:COMMAND.COM [RO/SYS
after the copy.
TESTING
Bear in mind that whenever you amend a piece of software based on operating principles of guesswork and inspiration but no hard facts, as is the case here, you're well advised to exercise extreme caution before you trust the new program completely. The advice is the same here, although Richard tried the amended version without trouble and I've tested it too, perhaps not exhaustively, but again with no problems. However, how soon you decide to use the amended COMMAND.COM as your live version, if you do at all, is up to you. I know of no problems, but there are no guarantees.
The amended COMMAND.COM appears to work quite normally, but by default 'echo' is off. The result is that whenever a batch file is run, none of the batch commands appear on screen unless you explicitly request it by including an echo on command. You can also, of course, turn echo off again later if you wish. If you read the previous articles on this topic there's one aspect of this 'tweak' which you might think could be a problem, but it isn't.
To illustrate, having restarted the 512 from your new boot disc, try keying in the following example batch file. The most straightforward way is to enter:
COPY CON TEST.BAT
followed by Return, then enter these lines pressing Return after each:
DIR
CLS
CHKDSK
PCSCREEN3
COLOUR 1 4
After the last Return press Ctrl-Z and then Return again. You can now run the file by entering its name 'TEST'. The result is that each of the commands executes, any output to (or effect on) the screen is exactly as normal (you'll end up with blue text if you have a colour monitor) but you don't see any of the commands themselves. OK, so what?
If you check in Volume 10 Issue 6 you'll see that there are limitations to piping screen output to NUL: or to a temporary file to avoid screen echo. The problem is that the effect of operations that should affect the screen, like CLS, PCSCREEN and so on, is also suppressed.
As you can see from our test batch file above, with the modified version of COMMAND.COM there are no such problems, the screen commands operate correctly, and the reason is very simple. When you redirect output, such as piping to NUL: or a file, you change the destination of the output data stream. By contrast, this change to COMMAND.COM is (or should that be 'seems to be'?) exactly the same as the effects of the 'echo off' command, with the benefit that the command isn't needed.
Of course this modification prevents the batch commands appearing on screen, but just like a normal echo off command it doesn't suppress the resulting output from command execution. Should you also wish to avoid that you'll still need to use piping and the previous warnings still apply. For example, if you have a file copy command but don't want to see the output from it, including the terminating 'n files copied', the command should be:
COPY FILE1.XTN FILE2.XTN >NUL:
as described before.
ODDS AND ENDS
A few issues ago I mentioned developments in processors for PCs and ended by saying the 512 was still more than quick enough for a good many jobs. I learned some interesting facts on this very point only last week.
I've been developing a complex software algorithm over the last few weeks and initially wrote the code in '86 assembler, since I'm most familiar with that these days and the 512 is (reasonably) fast. However, ultimately the technique was to be employed on an Archimedes, when it was finally fully developed and proved to work.
To cut a long story short, I had a 33K input file of test data which the 512 processed in 4.42 seconds. The program was converted to ARM code and run on an A310. With the same input data this took 6.9 seconds. The ARM code was then optimised for RISC techniques, when the run time dropped to 2.85 seconds. During last weekend I also tried the 512 program, using the same input, in an old Olivetti M24, an XT clone, which took 11.76 seconds, then in a 33Mhz 486, which took 0.76 seconds.
None of this is perhaps very useful information, but I thought it interesting that, at least in memory and processor operations, the 512 is almost three times the speed of an 8MHz XT. At the same time a 486/33 runs the same program almost six times faster (though its I/O is MUCH faster) but what frankly amazed me was that, even running highly optimised code, an ARM2 is only about 35% quicker than my 512!
The moral seems to me to be – hang onto your 512 (and your cash) for a while yet!
I had another letter from a member a while ago which mentioned an interesting way of getting some programs to run that otherwise wouldn't. It involves running them within the D86 debugger, part of the shareware assembler package I mentioned a month or two back.
It seems that some programs that normally crash the 512 will run correctly if they're run in D86. All that's needed is to load the debugger and the program in the normal way, then issue the 'g' (go) instruction. This effectively makes the debugger transparent, but when the program in question issues an interrupt call that would usually crash the 512, the debugger traps the call and executes it itself. It obviously does this by much more legal and well behaved methods, because the application doesn't crash the system.
I did say that A86/D86 is a remarkable package and this further demonstrates the fact that it's an extremely well written piece of software. However, top marks to one member for finding a method of curing some problem programs that I must admit I doubt I'd have thought of, even though I use A86 regularly. Try this on your problem programs, and it might very well work when all other approaches have failed.
As a final snippet this month, Dr. Sutton, a member from Swansea, has recently expanded the memory of his 512 and finds that FRACINT (version 15) now seems to run quite well. Previously it simply reported insufficient memory.
Dr. Sutton says he's investigated only a part of this complex program so far but, he says enough of it works (within the limits of the CGA display, of course) to be interesting.
FRACINT is shareware, but I have no further information on it. Even so, if you're interested in fractals and have enough memory you might like to give it a try.