Master 512
Forum by Robin Burton
Beebug Vol. 12 No. 9 March 1994
Yet again this month we have a couple of outstanding items on back up software, plus information on the latest and final updates to David Harper's PD programs, TXTMOUSE and PCCE.
FLEXI-BAK PLUS
I did say a couple of months back that I'd comment on the latest version of Flexibak Plus, but until now haven't had the space to do it. However, I've now tried the software in my 512, though not exhaustively, and found problems.
The documentation explains that the latest version of Flexi-bak now uses a form of (I think) LHARC compression. Whether any previous version used compression or not I don't know, but I do know that at least a couple of 512 users have been using an old version of Flexi-bak regularly for some time and like many of the facilities, so obviously this is a fairly new problem.
Whatever the situation with old versions, the changes to (or addition of) compression in the most recent version means that it no longer works in the 512 so far as I can see. As I said, I didn't test it exhaustively, so perhaps an enterprising 512 user has found a fix for the problem, but if so I'm unaware of it and can only warn you of my findings.
PKZIP AGAIN TOO
There are also a couple of final points about PKZIP that it seems weren't stressed enough, so I'll cover those too now.
I have mentioned before that to run PKZIP or UNZIP version 2.04G in the 512 you need PCCE, without which the program crashes. Even so some readers either missed this point or forgot about it, so if you are one of them and have been cursing me for talking about software that doesn't run in your 512 you now know why. The problem is that, unlike earlier versions, PKZIP 2.04G uses an undocumented interrupt function for fast character output to the screen.
Not surprisingly the 512 doesn't provide this routine (it was added in MS-DOS 3, so PCs can have the same trouble), but since PKZIP now uses it by default for all screen output, if you don't avoid the problem a crash is inevitable. It happens as soon as the program tries to display the first character of its name on the screen, so even if you're only expecting the help display it crashes, which is neither encouraging nor enlightening.
Thanks again to David Harper for taking the trouble to find out what's happening in detail and for building an automatic fix into PCCE, more of which later. However, even if you don't have PCCE, you can still run PKZIP 2.04G provided you read the documentation properly.
There is a lot of documentation for PKZIP so I guess most people don't bother reading it. Anyway, back to the problem. You can tell PKZIP not to use the fast character output routine by placing the directive 'PKNOFASTCHAR' in your environment using 'SET', in which case PCCE isn't required. Of course, if you choose this method you'd be best advised to include the statement in your autoexec file so that you don't forget in future, but as usual you don't get something for nothing.
Unlike MS-DOS, in which it expands as required, DOS Plus has a limited and fixed environment space, only 256 bytes in fact. This means that using this space when you can avoid it isn't a good idea, especially if you already have other lengthy environment strings such as a very long path statement and unavoidable specialised directives for other applications.
I must confess that I've never before tried to find out what happens when the 512 runs out of environment space, but I have just done it so that I can tell you. DOS Plus is very well behaved in this case, simply reporting 'Out of environment space', so there's no harm done, although of course the new string you are attempting to add will be ignored.
Environment space isn't likely to be much of a problem for floppy users, but for winchester users it might be. I was surprised to find that in my own system I have a lot less than 100 bytes left for new variables, even though I've always been aware of the limitation and so have avoided lengthy strings wherever possible.
The other point that I must clarify was one that I only brushed on, that of PKZIP back-ups spanning multiple volumes. On checking the documentation for other things I noticed that there's a qualifying statement that this option is only available for DOS version 3 and later, so in fact it won't work in the 512 anyway. Obviously my excuse for not mentioning this fact before is that, not only did I say at the time that I don't use the option, I positively don't recommend it.
PD UPDATES
I had a letter from David Harper a few weeks ago, along with a disc containing updates to his excellent programs PCCE and TXTMOUSE. In fact, this is the second or third update I've had since I offered these programs in FORUM, but these weren't bug-fixes. Like most good programmers David usually can't resist it when he knows there's an improvement he can make to one of his programs, no matter how small the change might be.
In this case though the additions are quite significant. Although the latest changes are not guaranteed to make all DOS software work on the 512, David has addressed certain problems that can be the cause of display or system crashes.
The latest version of PCCE is now 1.22 (so you can check against yours), and two important additions have been made. The first is that multiple display pages have been implemented for modes 0/1 and 2/3. These are the CGA text screen modes which provide 40 or 80 column text in black and white or colour (see Volume 11 No.9, page 36 for DOS screen modes).
Although the 512's implementation of DOS Plus provides these screen modes, in the 512 there's only one display page for each, whereas there are up to seven in a PC depending on mode and colour. The ability to switch display pages allows applications to use multiple displays with a virtually instant swap between them. At the same time alterations to the contents of any one 'screen' (i.e. page) including cursor positioning, whether it's the currently visible display or not, have absolutely no effect on any of the others.
Clearly any program that expects to do this sort of thing in the 512 will be useless, because interrupt calls to switch pages or to write to other pages are simply ignored. They don't cause an error in the application or in DOS, but obviously the 'other' display will never appear. The result is a program that doesn't crash, but which probably doesn't seem to do anything at all.
Most programs of this sort will either fail to change the display at all, or will clear the screen then appear to freeze. In fact they're waiting for you to select or enter something, but the problem of course is that you can't see the display. Some programs, such as those that use multiple menus, may display the first menu then will fail to respond to a request for a menu (i.e. display page) change.
I've come across quite a few of these programs in my time and they can usually be identified by the fact that if you know which keys to press to exit to DOS (you DO therefore need operating instructions), the operation works perfectly normally, so obviously the program was running properly despite the absence of a visible display.
You can guess from the description that implementing multiple display pages in the 512 wasn't a trivial task. David has had to modify a number of existing ROM BIOS calls and provide several new functions, plus all the appropriate background activities such as memory management.
The second new addition to PCCE caters for programs that read the hardware timer, which they may do for various reasons such as to find out the speed of the processor clock, for example. Essentially such programs repeatedly read a memory location waiting for a change, then note how quickly it happened. Normally such programs never see any change in the 512 so they simply sit and wait for ever. This then is another definite cause of 512 'hang-ups', although in this case it's a real one and re-booting is the only way out. With PCCE many programs that read the hardware timer may now work properly, assuming there are no other problems lurking further in the application.
The change mentioned earlier to allow fast character output was made a few versions ago, but note that this failure may well afflict numerous programs. It's not specifically a PKZIP problem, so again 'across the board' applications compatibility will be improved by PCCE. Since the fix diverts the missing call to an existing routine that does work the overhead is almost nil and it will work for any program. That is why it's a better fix than adding a new application specific environment string, and it's bound to be reliable whenever it's needed.
TXTMOUSE has also now been enhanced, though in this case the changes are less dramatic. While the previous version was restricted to 80 column text screen modes the new program also works in graphics modes. David hasn't added a 40 column text mode but as he says, are there any 40 column mouse driven programs?
If you have an earlier version of PCCE or TXTMOUSE you'd be well advised to update forthwith. In view of its added capabilities, TXTMOUSE is now called the "Master 512 Mouse Driver", but if you just ask for David Harper's mouse driver everyone will know what you mean. PCCE fixes some important shortcomings in the 512's version of DOS Plus and is without doubt a far better program and a better compatibility enhancer than the only alternative. The fact that it's PD and so costs only a couple of pounds while the other used to cost £30 is simply a bonus.
AND FINALLY
And never has this heading been more poignant. I'm sure you're well aware that this is the penultimate 512 Forum. I am, and I've been dreading writing the last one for months. Well, that's my next task. What do you say? How do you say anything suitable after writing for sixty issues?
Watch this space and with a bit of luck I might have some rather surprising information to end on. See you next month.