Microdrive Rename

ALL CHANGE!


(from Your Spectrum 6, Aug.1984)





Ever wanted to rename a Microdrive file? Providing the code to create


the necessary new command, Andrew Pennell brings Microdrives one step


nearer the expensive disk systems they emulate.








Although Sinclair Research's Interface 1 unit allows good use of the


Microdrives from Basic, there is one command noticeable only by its


absence - that of RENAME. It's provided by most disk operating systems


and associated Basics, but not for the dear old Speccy. Here, therefore,


is the machine code you've been waiting for - although, I'm afraid that


it's for 48K owners only.





Listing 1 shows the Basic loader to create the machine code; enter it


with great care - the checksum should spot most typing errors, but some


may slip through. After entering and executing, SAVE the program in case


it's wrong. To test it, enter RANDOMIZE USR 28000, which enables it.


Then, with an unimportant cartridge, try to rename a file; the syntax to


use is





*R1;"oldname" TO "newname"





where 'TO' is the keyword (and 'r' is also accepted). Naturally, '1' in


the example can be replaced with any drive number, up to '8' (should you


be lucky enough to have that many!). Having entered the command, the


file 'oldname' will be renamed to' newname', although there are a couple


of limitations. Firstly, data files (that is, those created with


OPEN/PRINT/CLOSE) will not be renamed, and will produce the error 'Wrong


file type'. A second limitation is that the file 'oldname' must be under


about 37K in length - otherwise it'll be flagged 'Out of memory'.





The program has been written so that if any error occurs during the


process (except perhaps a power cut!) then the file will remain intact,


under one of the names. If you try to rename a non- existent file,


you'll come across the 'File not found' message, and an attempt to


define a new name that's already present on the cartridge will force


'Writing to a read file'.





The source code is shown in Listing 2, and uses the facility of the


Interface 1 to add commands to the Basic interpreter. The remainder of


this explanation assumes a basic knowledge of machine code with the


Microdrives, and of how to add commands; for this I suggest you read


chapters eight and nine respectively of Master your ZX Microdrive - and


Toni Baker's Extending Basic article (see issue 3). [yr03_43.htm]





The code is placed at 28000 decimal, to give some room for small Basic


programs, and over 37K to store the file. The routine SETUP is the one


entered directly from Basic, and the first creates the Interface system


variables, using hook code #31, then alters VECTOR to point to the new


command routine. It then calls WATROM using hook code #32, before


RETurning to Basic. The routine WATROM actually modifies the program to


suit the ROM in the Interface 1. As you may be aware, Interface 1 will


shortly be sporting a new ROM which has most of its routines in


different places. To cater for this, the tables OLDROM and NEWROM allow


the program to modify itself to suit either, using location #16DA to


test the ROM's type. It had to be called indirectly via hook code #32


because the Shadow ROM must be in place for it to work.





Location SYNERR is just a jump to #28 in the Shadow ROM which produces a


syntax error when in the line editor. NEWSYN is the new command handler,


which first ensures that the command starts with *R or *r. That done,


the drive number is scanned, a semi-colon checked for, then the old


filename scanned. Next, the character following it (that is, the TO


token) is checked, then the routine SWOP called. This is explained


later, and only has significance during 'run-time'.





The new name is scanned, and a check made to ensure that there's no more


to the statement. Control only passes to line 2200 during 'run-time',


which again calls SWOP. This routine swaps the parameters (start address


and length) for the old and new names, which are stored in N_STR1,


T_STR1 and N_STR3, T_STR3. The Shadow ROM routines act on the parameters


in the former two.





The next action taken is for OPEN_M to be called, while preserving


T_STR1. As the Shadow ROM is in place, hook codes cannot be used, so


routines vary according to ROM type. OPEN_M takes identical action to


hook code #22 - that is, create an 'M' channel addressed by IX. The old


file is then checked to see if it exists, whether it's a PRINT file, and


whether the cartridge is write-protected or not. If it passes all the


criterion the nine-byte file header is copied to FREE, and the length of


the file is tested to see if there's room for it and if not an error is


produced. The shadow routine LDBYTS is called which loads the rest of


the file into locations FREE+9 onwards, and then the channel is closed.





Next, the header is copied back from FREE to HD-00 to HD-11, and the


bytes SAVEd on to the required cartridge. Routine SVBYTS does a lot of


the fiddly bits for you, like opening an 'M' channel, setting the PRINT


file flag and testing to see if it's already there. Finally, the old


file is erased - by calling ERASEM - and an exit made via #05C1 (which


is the same in both ROMs, thankfully).











Listing 1 (above): The Basic loader to create the RENAME machine code.





Listing 2 (below): The disassembled listing, roughly split into five


columns: address, Hex code, line numbers (unique to the disassembler


used), labels and mnemonics.