Mounted police, I understand, were called out to help control the raging apathy which swept England at last issue's lack of Disinformation. Your columnist was unavoidably indisposed (translation: busy writing software for corrupt personal gain), your Editor tolerant but firm (translation: the wretch moved his deadline, in the wrong direction). In future I've promised to be as swift and reliable as, well, ACTIVITY....
The shape of things to come
It seemed about time to investigate BIOS 3.1 as provided for the PC/Xi. Does it really cure ever so many bugs? Will the old programs run? If not, why not?
By and large, users of PC/Xi BIOS 2.7 won't notice much difference. One obvious point is in the included keyboard table: the special functions CALC and PRINT have migrated to the SHIFTed positions of those keys, probably a good thing when you eventually get used to it.
A few of the escape sequences for screen control seem to have changed slightly, to conform with oddities already noted on the F2 and F10. ESC M (delete line and close up) and ESC l (erase line) both fail to reset the cursor to the left, so PC/Xi programs which rely on this feature may go a little awry in screen control. ESC £ thankfully no longer crashes the PC. ESC 2 and ESC 3 still turn on and off cursor flashing, despite the unavailability of this feature on the dreaded F-series.
Presumably a change in screen handling is responsible for the fact that the venerable SETUP, KEYEDIT, FONTEDIT and DISK seem at first glance not to work! Hideous visions of a lifetime of ACTIVITY flashed before my horrified eyes.... The problem in each case is a screwed-up screen: all of the nice ladder menu appears, but in jigsaw fashion. Evidently these programs are doing some kind of screen reset which no longer works.
The solution? Write a tiny batch file which will run a program and, immediately before doing so, reset the screen properly. Thus my little X.BAT, as follows:
ECHO OFF ECHO ^[E %1The ^[ is an Escape character (inserted in SuperWriter by CONTROL Q 2 ^ ESC, in the Turbo Pascal screen editor by CONTROL P ESC, and in horrible EDLIN by CONTROL V [). ESC E will clear and reset the screen, even in BIOS 3.1. In fact you need only home the cursor with ESC H, but ESC E is tidier. The BIOS command CLS is no use here, since it doesn't home the cursor. With this teensy file on the disk, you can successfully run DISK by typing X DISK [CR], and likewise for the rest.
On the other hand....
Your mad rush to write X.BAT may be slowed by my next interesting snippet. Apricot PLC has at last relented about its compulsory and usually slothful "front end" systems, like MANAGER and ACTIVITY. Most people discard these except, reluctantly, for formatting and copying disks -- since the MS-DOS utility FORMAT was of malice aforethought not supplied.
It is now, though not with the PC/Xi. Instead, nip round to your nearest Xen user and beg copies of two very interesting files supplied in the UTILITY subdirectory of Master Disk 3. These are FORMAT.EXE (at last, MS-DOS the way it was supposed to be!) and DCOPY.EXE. Both work nicely on the PC/Xi *if* you have BIOS 3.1.
DCOPY just copies disks. FORMAT is self-documenting (type the filename alone for some eventually comprehensible info), and will format, copy system tracks, set a specified volume label, update existing systems disks, all sorts of jolly things. Farewell, ladder menus and the ACTIVITY arrow which, like Zeno's, came close to proving that motion is impossible.
I am reliably informed that both these utilities have just fallen off the back of a lorry near the Apricot File offices. So has SCOPY.EXE, Apricot's belated fix for single-drive file copying. F1 users keep complaining about corrupted SuperWriter dictionaries, and often it turns out that COPY /S is damaging files longer than 64K even as it copies them. SCOPY is supposed to fix this; it also allows multiple copying with wild cards on single-drive Apricots.
The only reason I'm nervous about adopting BIOS 3.1 for all my system disks is that Apricot File's screen accelerator, FAST.COM, now makes little or no difference. Awesome David St John Wallis of OMRC tells me that BIOS 3.1 is "far more complicated" than versions of yore, and is much harder to speed up. Almost as if Apricot resented the impudence of those who first made the improvement....
Patching the BIOS
Happily, my own little BIOS titivation seems equally effective in 3.1. Like most intelligent entities within the known universe, I am deeply irritated by the way the PRINT key invariably cranks out a whole page before printing a screen dump. If you're using continuous stationery, you waste a page; if not, you stand there holding the paper against the tug of the roller until it condescends to do some actual printing.
Clearly an improvement could be worth trying. In Apricot File Release 1.7, I described at tedious length the kind of detective work needed to work out a program patch: this time, to cheers of relief, we'll skip the police procedural stuff. As a minimum, you need a spare system disk and a copy of DEBUG. Life is much easier if you also have CHMOD.EXE from Apricot Disk No.1 (or is it 2? Please correct, boss), since the BIOS is in a hidden system file which you must first expose to the cruel light of day.
All the usual warnings apply. This patch has been tested only on BIOS versions 2.7 and 3.1. I refuse to accept responsibility if after its installation your Apricot goes into Chernobyl mode and gushes Brown Windsor Soup from every orifice. Very briefly, then:
The BIOS is contained in the hidden file IO.SYS on your system disk. Use CHMOD to convert the file attributes to "normal" and "visible": CHMOD IO.SYS /SY [CR]. Then: DEBUG IO.SYS [CR].
With DEBUG, locate the first occurrence of the pair of bytes B0 0C in the file: S 100 FFFF B0 0C [CR]. Change the second byte, which is in fact the hated "form feed" code, to a zero. For example, in PC/Xi BIOS 3.1 the byte pair is first reported at 1B1C, so the 0C can be zapped with E 1B1D 0 [CR]. Write IO.SYS back to disk with W [CR].
Then use CHMOD to reset the attributes to "hidden" and "system": CHMOD IO.SYS /HX [CR]. That's it....
Reboot the computer with this newly perverted systems disk, and see what happens with the PRINT key now. I'll just retreat into my hermetically sealed bunker while you do it.
Bug corner
Everybody seems to want graphics screen dumps on their Epson printers. As an independent smartarse, I lashed out £75 on MXDUMP by the fabulous Friedman -- as offered elsewhere in this very issue. The good news is that it works extremely well, enabling me to graphically immortalize all my brilliant mating positions against the Apricot File chess program which I invariably thrash even at the highest level, har har. The less good news is that MXDUMP is a mite user-hostile: I spent ages hanging up my computer until I found the small print at the back of the manual advising me to disconnect three lines of the printer cable. At £75 for a 2k utility, I reckon they could throw in either an advance warning or a free cable.... MXDUMP also hangs irrevocably should you forget to switch the printer on first. Otherwise, it's a lovely bit of programming.
I also found a bug in Turbo Pascal 3. This won't bother most users... but don't call Intr($25) or Intr($26), the interrupts for absolute disk reads and writes, from within a Turbo procedure. They work OK from the main program, though sometimes with weird side-effects -- eg. the program will "write" to a protected disk without reporting any error. All this is because Turbo keeps its procedure addresses on the processor's stack: unfortunately these interrupts destroy the registers BP (base pointer) and SP (stack pointer). There is a solution, using the Inline procedure to machine-code the interrupts and preserve the pointers, but -- to pinch a useful mathematical bluff from Fermat -- this margin is too small to contain it.