Copyright Michael Markov 86/07/15 MSD= Mass Storage Device LBL "WIPEFL" Preliminary version - for single drive use ONLY! SF 25 Let ZERO do the job, if it can ZERO FS?C 25 If set, we are done RTN No, error for "File not found" or "Wrong file type" 32 Create a DEVIL buffer that can hold BSIZEX a directory entry CLX Set-up for a limited directory search. See text below. PT= MIPT UNL UNT AAU This set a mode that set MSD addresses to 2 2 This cannot be used with more than 1 MSD, since ALL TAD MSD's would try to become talkers SIGN DDT Set-up to get the directory information from buffer #1 " " To avoid erroneous matches with longer file names, LBL 00 append 9 spaces. 32 After ZERO errors out, the MSD byte pointer should point INBUFX at the start of the next entry. Let's get the entry. 10 Does the MSD filename (10 char. incl. trailing blanks) A=BUFX? match the first 10 char. in ALPHA reg? GTO 01 yes, exit the loop GTO 00 no, try again. Note that DDT1 mode provides wrap-around LBL 01 to the start of buffer #1. 10 PT= 57552 Change the file type to DAta X-BUF 2 LAD Now reset the MSD byte pointer to 0 3 DDL CLX OUTBIN reset completed PT= Now, store the edited directory entry at the begining of 1 MSD buffer #1. This is easier than overwriting the original DDL entry. The modified entry will be scanned first when ZERO 32 is executed again. OUTBUFX RDN AAD Reset normal loop address mode UNL ZERO Wipe the file clear! PURGE Avoid memory lost following READ of wiped file END DONE! This program takes advantage of the fact that standard HP-41 mass storage functions use the MSD buffer #1 as an extension of the directory. MSD functions store the contents of the current directory sector in buffer #1 after most directory searches. Functions that do not create new files check the contents of buffer #1 before initiating a full directory search. If a matching entry is found, these function will use the contents of buffer #1, rather than the data actually stored on the medium. Thus, if you edit buffer #1, you can, for example, unsecure & unprivate files without actually altering the contents of the directory. I wrote an article / conference paper on the subject a long time ago. Here, the initial use of ZERO loads buffer #1 with the desired entry... If you error-out with File not found, you will be trapped in an endless loop (LBL 00 ... GTO 00) since a matching name cannot be found. The program needs a counter that allows 8 iterations max. In fact, 8 consecutive INBUFX instructions could replace the loop (please test!). If so, line 23 (A=BUFX?) could provide the error-out path for "file not found". Alternatively, FLLENG (XIO) after RTN would trap the "file not found" error. For multi-drive users, MANIO is mandatory, and the user would have to be responsible for SELECTing the target drive. Also, AAU & AAD should not be used. 2 TAD or 2 LAD become 4 RREG TAD.... I was very pleased to note that ZERO will not wipe data outside the address range allocated to the "data" file, even when the file length in registers is incorrect. This needs further testing, but I now believe program files will not require special handling. ****************************************************************************** Future applications: Note that the bulk of the program gets a copy of the applicable directory entry into the DEVIL buffer, where it can be manipulated at will. 0 SEEKR could replace the first ZERO (too destructive for my taste), with similar results. Thereafter, you could easily extract other information such as FLLENG with code sequences such as 28 PT= 2 BUF-XB. This does in fact provide a damn handy address data decoder for some future DIRL(X)(H) that would use only DEVIL functions! Similarily, you can regain access to a file whose directory entry is "bad" due to wear or other problem merely by creating an entry in the DEVIL buffer, and then sending it to MSD buffer #1, as shown above -- after all, you could copy the contents of any register format files into data register, instead of just ZEROing the file. The big problem I have with this approach is that the stack is totally trashed. I grant you that we could use REG-BUFX & BUF-REGX to save the stack and status registers. However, I have not yet found any satisfactory user code solution... I have looked at A-BUF, X<>M, RDN, X<>N ... A-BUF sequences, and other variants that use X-BUF. The problem is that of initial set-up being too complicated for general use. PPC ROM "SM" & "MS" routines work equally poorly! Actually, XFM functions SAVEX and GETX come closer than most, assuming you have a dedicated active Data file. Here, you really need an MCODE function if you really want to do the job right! I believe the cost of saving the contents of the X & Y registers (rather than the entire stack) might be acceptable (n RDN STO IND T, RDN ISG Z STO IND Z..). **************************************************************************** Upon further reflection, I have found a way to trap-out the "File not found" error: Use the function VERIFY as the first program line after the label. This should work OK. Note, however, that following VERIFY the byte pointer can end-up almost anywhere.. I will discuss the use of VERIFY in the draft version of the proposed FS program, which I have roughed out today (86/07/16). ****************************************************************************** Till next time, Michael Markov