GB2317972A - Supplementing or replacing data in a ROM - Google Patents

Abstract

Alternative data for ROM addresses is written to a RAM and an index is examined during ROM read operations to determine whether the data should be fetched from the ROM or the RAM. The index is examined and maintained by a TSR interrupt handler or a modified device driver. The ROM may be a CD ROM.

Description

WRITING TO STORAGE DEVICE This invention relates to the simulation of writing of data to a read only storage medium. Typically, though not exclusively, this medium is a CD-ROM.

Computer software is increasingly being supplied on CD-ROM rather than floppy disc. In order for the software to function, it is usually necessary for it to write configuration and temporary files. Whereas software designed specifically for CD-ROM is aware that it must write these files to an alternative medium (e.g. a hard disc), software which is merely provided on CD-COM has to be copied (installed), usually in its entirety, to the other medium. The copying of an entire program is inconvenient for the user since available space on a hard disc is usually limited and the installation process takes time.

The present invention allows executing software apparently to add, amend or delete data on a CD-ROM (or other read only device), thus enabling successful execution without the need to copy it to a hard disc or other writable storage medium.

The invention provides a method of simulating the writing of data to a storage location of a read-only memory (ROM) comprising receiving data addressed to be written to the ROM storage location, diverting the data and writing it to a storage location of a writable storage device, and when the ROM storage location thereafter is addressed for reading, outputting the data written at the writable storage location instead of that at the ROM storage location. As stated, the ROM may be a CD-ROM, and the writable storage device may be a hard disc.

Said reading may comprise reading the original data from the said ROM storage location as part of a larger quantity of data from the ROM, reading also the data from the writable storage location, substituting that data for the data read from the first mentioned ROM storage location, and outputting the larger quantity of data with said substitution.

In another aspect the invention provides a memory device comprising a read-only memory (ROM) having storage locations therein, and means for simulating the writing of data to a said storage location, the simulation means comprising a writable storage device, means for receiving said data to be written to said ROM storage location and for diverting it to a corresponding writable storage location in the writable storage device, and means for reading the data at said writable storage location in response to a command to read the data at said ROM storage location.

The means for diverting the data may comprise means for intercepting and modifying a high level command to write data to the ROM storage location. Thus the means for intercepting may be a terminate and stay resident (TSR) program.

Alternatively the means for diverting may comprise means for intercepting and modifying a low-level command to write said data to the ROM storage location. Thus the means for intercepting may be a device driver.

The invention also includes a computer incorporating a memory device as set forth above.

Two specific embodiments applicable to IBM PC architecture will now be described by way of example only, with reference to the accompanying drawings wherein: Figure 1 shows a diagrammatic summary of the flow of an instruction involving a hardware device through the MS-DOS operating system of an IBM compatible personal computer under (a) normal circumstances, (b) in the case of the first embodiment, and (c) in the case of the second embodiment.

Figure 2 shows a flow chart indicating the general operation of both embodiments.

Referring to Figure l(a), a user program 10 wishes to access a device 20. It loads the processor registers 12 with values indicating the high level instruction 11 to be performed (e.g.

open/rename file) and any necessary parameters (e.g. file name), and initiates an MS-DOS interrupt 21h call. The operating system software has an interrupt 21h handler 14 which receives the instruction. The operating system then processes the instruction at step 16, in order to reduce it to a series of low level device instructions 17 (e.g. references to individual clusters on disc).

These instructions 17 are passed on to a hardware specific device driver 18 which translates them into hardware level instructions 19 (e.g. 'move reading head to track 1Q'), which are passed to the device 20.

The basis of both embodiments is to intercept the instructions 11 at some point during their progression to the device 20, and modify them selectively such that any amendments are diverted to a writable medium. An index is maintained to all data so diverted, in order that future references to modified data can be identified. This index may be stored either on the writable medium, or in the memory of the computer. In the first embodiment, a new interrupt 21h handler 21 is inserted at point A in the chain, to supersede the original DOS one (as shown in Figure l(b)). In the second-embodiment, interception is via a new device driver 23 inserted at point B, to supersede the original driver 18 (as shown in Figure l(c)). In neither case do the embodiments fully take over the execution of the instructions; they merely monitor and modify them as necessary.

The primary difference between the two embodiments is related to the level at which instructions are intercepted. The first embodiment intercepts at high level and accordingly will receive a large variety of instructions 11 involving files and directories. Conversely, the second embodiment intercepts at low level, by which time the high level instructions 11 have been broken down to a series of reads/writes to individual disc clusters either in the data area or in the file allocation table (FAT). Consequently, the second embodiment needs to deal with only two primary functions (read/write) on a vast number of clusters, whereas the first embodiment needs to deal with a large number of different functions operating on relatively few files.

Figure 2 shows the operations common to both embodiments. It will be discussed with reference to each embodiment in turn.

Referring to Figures l(a), l(b) and 2, the first embodiment comprises a new interrupt 21h handler 21, in the form of a terminate and stay resident (TSR) program. Step 1 corresponds to the receipt of the instructions 11 from the user program 10.

During the initialisation of the new handler 21, the location in memory of the existing handler 14 is determined from the interrupt vector table and is saved. The table is then updated by storing a vector to the new handler 21. Accordingly, all subsequent interrupt 21h calls will be received by the new handler 21, which, by storing the old vector, has the ability to pass instructions 11 on to the previous handler 14.

Upon receipt of an instruction 11, it is examined to establish whether it involves reading, writing or another action (step 2).

The instruction to be performed is identified by the most significant byte (MSB) of the AX processor register. Examples are given in Table 1 below:

Type Action MSB of AX Reading Open file for reading only 3Dh or 6Ch Change current directory 3Bh Get file attributes Writing Create file ~ 3Ch or 5Bh Open file or write/amend 3Dh or 6Ch Delete file 41h or 13h Rename File 56h Create directory 39h Set file attributes 43h Other Get Disc Free Space 36h Get Drive Data lCh Table 1 The two examples given for functions other than reading and writing are in this case related to obtaining the status of the CD-ROM device. In both cases the interrupt handler TSR 21 modifies the instruction parameter such that information regarding the hard disc is returned to the user program 10 instead of information regarding the CD-ROM (corresponds to step 9). In the case of 'Get Disc Free Space, the amount of free space on the hard disc is returned rather than zero bytes free (the normal return value for the read-only CD-ROM).

In order to redirect information, the interrupt handler TSR 21 takes advantage of the method used by DOS to access files.

Before a file can be accessed, it is necessary first for it to be opened. When a file is opened, DOS associates a 'handle' with it. This is an identifier which is specified in future accesses to the file (e.g. read/write) which distinguishes it from other open files. For functions involving the opening or creation of files, the TSR 21 causes the resulting handle to be associated with an equivalent file on the hard disc rather than the intended file on the CD-ROM. Since the user program 10 is not aware of this, it will read and write the hard disc file as though it was on the CD-ROM.

Write related functions be considered first, and are processed in steps 3 to 5 of Figure 2. Before a write function can be processed it is necessary first to establish whether the file or directory specified has already been amended (step 3).

This is achieved by consulting the index. In the first embodiment, the index contains a list of file/directory names which have been amended, organised such that the amended version of a particular file can be identified on the hard disc. For all write instructions, the name of the referenced file or directory is added to the index, provided that it is not already present.

Subsequently, if the instruction is file related (but is not 'create file'), the contents of the referenced file on the CD-ROM is copied to the hard disc (step 4). From this point forward the operations of the interrupt handler TSR 21 are as though the file or directory had already been amended, as is evident from the unconditional flow of control from step 4 to step 5.

The exact nature of the actions performed in step 5 depend on the instruction received. The actions and their results are summarised in Table 2 below.

Instruction Action taken Result Create file Instruction is modified The hard disc file in that the file name to is created.

be created on the CD-ROM is changed to its equivalent file name on the hard disc as dictated by the index.

Open file for Instruction is modified The file on the write/amend in that the file name to hard disc is be opened on the CD-ROM opened.

is changed to its equivalent file name on the hard disc as dictated by the index.

Delete file Instruction is modified The hard disc file in that the file name to is deleted. Any - be deleted-o-n~the CD-ROM further references is changed to its to the file on the equivalent file name on CD-ROM will result the hard disc as in 'file not dictated by the index. found' since the instruction will be diverted to the file on the hard disc which no longer exists.

Rename file The file name in the The file is now index is changed to the recognised by its new name. An index new name in the entry is added for the index. The old old name which points to file, if accessed, a non-existent file on will give 'file the hard disc. not found' since no file exists on hard disc.

Create The registers are The new directory directory altered to reflect the can be accessed in successful creation of a future since its directory, and control name has been is returned to the recorded in the calling program. index.

Set file Instruction is modified The attributes of attribs. in that the file name on the file on the the CD-ROM for which the hard disc are attributes are being set modified.

is changed to its equivalent file name on the hard disc as dictated by the index.

Table 2 The procedure for read related functions consists of steps 6, 7 and 8 of Figure 2. Similarly to step 3, the index is consulted in order to establish whether the file or directory referenced has already been amended (step 6). If it has not, then no amendments to the instruction are necessary, since the information on the CD-ROM is current and can be read directly (step 7). If the file or directory has been amended, then the data on the CD-ROM is not current, and the version on the hard disc must be used instead (step 8). The exact nature of the actions taken by the TSR 21 in step 8 in respect of a previously amended file are detailed in Table 3 on the following page.

Instruction Action taken Result Open file for Instruction is modified File on hard disc reading only in that the file name to is opened.

be opened on the CD-ROM is changed to its equivalent file name on the hard disc as dictated by the index.

Change The registers and system The directory is current variables are modified changed.

directory to reflect the change in directory Get file Instruction is modified Attributes of the attributes in that the file name on hard disc file are the CD-ROM for which the returned.

attributes are to be obtained is changed to its equivalent file name on the hard disc as dictated by the index.

Table 3 The code for the first em-Sodiment is an Appendix hereto.

The second embodiment comprises a new device driver 23 loaded during the booting process of the computer, but after the hardware driver 18 for the CD-ROM drive. Interception of instructions (step 1) is achieved in a similar manner to that adopted by the interrupt handler TSR 21. The existing driver 18 is superseded by first saving a pointer to it (allowing future use), before instructing the operating system to address the new driver 23 instead.

Whereas the interrupt handler TSR 21 of the first embodiment deals with a large variety of different instructions on files and directories, the device driver 23 of the second embodiment need only deal with generic read and write operations on clusters.

The actions performed by the driver 23 for these operations are a simplified version of those performed by the interrupt handler TSR 21. However, since the driver 23 is responsible for the actual reading and writing of the data (rather than coordinating files as in the interrupt handler TSR 21), the performance of the driver 23 is an important consideration.

The nature of the instruction to be performed is identified in step 2. The parameters of the read and write operations specify a starting cluster, a number of clusters to read or write, and a pointer to a buffer in the computer's memory which holds the data to be read or written. As in the interrupt handler TSR 21, previous amendment of a cluster is determined by consulting the index. In the second embodiment the index consists of list of cluster numbers, encoded such that access to each amended cluster number is rapid, and the size of the index remains low. Whereas the interrupt handler TSR 21 had a hard disc file for each amended CD-ROM file, amended clusters are grouped together such that the total number of files does not become excessive.

Whereas the majority of the instructions received by the interrupt handler TSR 21 reference a single file, the instructions received by the device driver 23 will almost always reference more than one cluster. Consequently, the steps 3,4 ant-5-(for write related-t-structions) and the steps 6,7 and 8 (for read related instructions) need to be repeated for each cluster involved.

During a write related instruction, the index is examined for each cluster referenced, in order to establish if it has been amended previously (step 3). If the cluster has not been amended previously, then a new entry is created on the hard disc, and the index is updated accordingly (step 4). From this point the driver 23 treats the cluster as though it had already been amended (as indicated by the unconditional flow of control from step 4 to 5). For clusters which are identified by the index as already having been amended, the data for that cluster is copied from the buffer on to the existing entry on the hard disc (step 5). The final result is that every cluster which was addressed in the write operation has a copy on the hard disc, and an entry in the index. During a write instruction it is not necessary to pass any instructions (modified or otherwise) to the original device driver 18.

While the write operation involves the copying of information from the buffer to the hard disc, a read operation involves the copying of information to the buffer from either the CD-ROM or the hard disc depending on each individual cluster. It is evident that a read operation is therefore much more processor intensive. In addition, some information must come from CD-ROM which involves calling the original driver 18.

It is important therefore, that the read algorithm is efficient.

The original device driver 18 is called initially with the unmodified instruction so that the required data is copied from the CD-ROM to the buffer. When the original driver 18 finishes its operations, control is returned to the new driver 23 so that the data in the buffer can be updated selectively from the hard disc 22. Since there is processor overhead involved with each call of the original driver 18, it is more efficient to perform a single call to the driver 18 and receive some obsolete data, than to call the driver 18 several times in order only to receive the valid data. In order to update the data in the buffer, the inCex-is consulted for eachcluster in turn (step 6). For those which have been amended the updated data is read from the hard disc and copied over the older data in the buffer (step 8). For those that have not, the data already present in the buffer is current and can be used without modification (step 7). When the new driver 23 has finished, control is returned to the operating system, and the data in the buffer is current.

The remainder of the instructions which can be received by the new driver 23 relate to device status and identification. For these functions, the old driver 18 is called without modifying the instruction in order that valid information is obtained regarding the CD-ROM drive. However, wherever the return value reflects that the CD-ROM is read-only, it is modified to indicate that the CD-ROM can be written to. These operations correspond to step 9.

Whereas the two embodiments previously described are implemented in software, there is potential for wholly hardware implementations. One further embodiment is now described briefly.

The third embodiment consists of a single chip, which comprises a non-volatile ROM (the read-only medium), a volatile RAM (the writable medium) and control circuitry with the equivalent function to that described in Figure 2. The ROM can contain any preset data which is required for the particular application of the memory chip. The RAM, because it is volatile, is blank when powered up initially, but subsequently ,contains any amendments made to the contents of the ROM, and the index thereto. This arrangement results in the following functionality: - When powered up initially, the memory chip assumes the unedited data of the ROM, since the blank RAM reflects that no amendments have been made.

- The contents of the memory chip can be changed as though it were RAM, since any amendments to the data in the ROM are stored in the RAM.

- When powered down, the contents of the memory chip will revert back to the contents of the ROM, since the RAM loses - all of its contents-.--desired, the memory chip could be designed so that the RAM contents could be reset without removal of power.

The memory chip could be designed to emulate the pin function of any existing type of hardware memory device.

An example of a use of such a chip is for holding configuration information for a piece of electronic equipment which may occasionally need to be overridden, but which should be returned to its normal condition when power is removed.

The invention also includes any novel features or combination of features disclosed in the specification (which term includes the Appendix and the claims) whether or not presently claimed.

Appendix The following C code is that of the terminate and stay resident (TSR) program constituting the new interrupt 2lh handler of the first embodiment. It is a prototype program which demonstrates the main elements of an embodiment of the invention, but is not complete in every detail.

The double slash (//) denotes a comment in the program code.

&num;include < dos.h > &num;include < ctype.h > &num;include < string.h > &num;include < fcntl.h > &num;include < sys\stat.h > &num;define INTR 0x21 // Interrupt 21h is MS-DOS's function // request service (the interface to all // operating system functions).

extern unsigned ~heaplen = 32; extern unsigned ~stklen = 128; // alter the length of the program's heap // and stack so that the TSR takes up less // conventional memory unsigned int nc~search; // records the file number during the search // of the index for a requested file unsigned char found; // flag indicates whether the file being sought - - // has been fotiminthe index unsigned char intercept~drive; // holds DOS drive letter of drive to be intercepted unsigned int dso,dxo,bxo,sio; // hold values of DS, DX, BX and SI registers on // entry of interrupt routine.

unsigned char rs; // controls restoration of registers after // interrupt call unsigned char dest~nof; // during a file rename, the dest~nof flag // holds whether the destination filename already // exists. If it set to zero, then the rename // command is not intercepted further and the // normal INT 21 routine provides the default // DOS error message (e.g. 'destination file // already exists').

unsigned int dsc,dxc,bxc,sic; // holds the DS, DX, BX and SI registers before // the MS-DOS function call char name~cache~file[25]="C:\\CDROM\\NAMECACX.DAT"; // string holding the filename of the index char stored~version[25]="C:\\CDROM\\XD{ .FIL"; char destination~version[25]="C:\\CDROM\\XD( .FIL"; // strings used to hold temporarily the filenames // as stored on the writable media unsigned char buffer[1024]; // buffer used to hold information during // copying int src,dest; // hold file handles for source/destination files // during copying int name~cache; // file handle for the index file unsigned long blocks read; // holds number of 1K blocks copied during file copy char far *filename; // far pointer to the filename given by the // calling program char fcb~filename[15]; char far *fcb~filestart; unsigned char *local~filename; unsigned char localpath[132]; // string storing the full path of the file requested // by the calling program. It is stored within the // same segment as the program code (as opposed to // the original filename which is stored in a // segment determined by the calling program.

unsigned char rename~path[l32]; unsigned curdrv; unsigned char curdir[131]; void far *prev; unsigned char function; unsigned int divisor; // In the generate~filename function, references // the character of the stored~version // file which is being computed.

unsigned char counter; unsigned int allocated; // stores number representing the corresponding file // on the writable media.

unsigned char already~loc; // flag indicating whether the destination file name // is already present in the index during a // rename operation.

// Each file on the non-writable medium is stored on the writable // medium under a filename "XD{-----.FIL", where X is the DOS // drive letter of the non-writable medium, and ----- is a number // for referencing the file in future.

// The generate~filename function (below), builds this filename // based on the number passed to it in the 'point' parameter.

// The 'stored~version' parameter is a pointer to a string in which // the filename is stored.

void generate filename(unsigned int point, char *stored~version) f divisor=10000; // sets reference so that the first digit in the filename // is calculated.

for(counter = 0; counter < = 4; counter++ ) // for each digit *(stored version+12+counter)=(point/divisor)+48; // calculate and store digit point-=(point/divisor)*divisor; // numerically remove the digit which has just been // inserted in the filename divisor/=10; // change the reference to the next digit void cache~search(char *local~filename) // function to search the index for a filename.

// local~filename is a pointer to the filename for which to // search.

found=0; // set found flag to false nc~search=O; // set to zero, the counter holding the location of the // read filename lseek4zaee~cache, OL, SEEKSET); // move to start of index file.

while ( found == 0 & & eof(name~cache)!=1 ) // while the filename has not been found, and the end // of the index file has not been reached.

read(name~cache, buffer, 128); // read the next filename if ( strcmpi(buffer, local~filename) == 0 ) found = 1; else nc~search++; // compare the read filename with the sought filename, // and set flag if necessary.

// If the file could not be found, then found==0 at the exit of the // function.

// When the calling program requests a function, the filename that it // specifies is not necessarily the full path name, e.g.

// it may be 'hello.dat', 'e:hello.dat', 'e:\hello\hello.dat' or // 'hello\hello.dat' etc. The build~path function converts the passed // filename into the full path based on the current drive/directory.

unsigned char build~path(char *local~path, char far *filename) // local~path is a pointer to the string to place the path in.

// filename is a far pointer to the filename being passed by // the calling program.

{ if ( ( toupper(*filename) == in if ( function == 0x39 j i function == Ox3B ) ~fstrcat((char far *) local~path, "\\"); // if the command is create directory or change // directory then append a backslash.

return(0); // return zero to calling routine if the file // needs to be rerouted.

return(l); // otherwise return one.

void interrupt ( *oldhandler)(); // function declaration for the // original interrupt handler.

void original() prev=MK~FP(peek(0,134),peek(0,132)); // stores current interrupt handler so that it can be restored poke(0,l32,FP~OFF(oldhandler)); poke(0, 134,FPSEG(oldhandler)); // sets the old interrupt handler ) void updated() f poke(0,132,FP0FF(prev)); poke(0,134,FPSEG(prev)); // set the previous interrupt handler ) // The above two routines are the same as DOS Int 21h Set/Get interrupt // vector functions. These cannot be used since a call to an Int 21h function // from within an Int 21h handler would cause looping. The above routines // disable the handler temporarily so that DOS Int 21 functions can be used.

void interrupt handler(unsigned int bp, unsigned int di, unsigned int si, unsigned int ds, unsigned int es, unsigned int dx, unsigned int cx, unsigned int bx, unsigned int ax, unsigned int ip, unsigned int cs, unsigned int flags) // the new INT 21 handler. The parameters store the values of the // processor registers on entry to the handler.

( dso=ds; dxo=dx; sio=si; bxo=bx; rs=O; // store the values of primary registers on entry, and set the // restore variable (rs) to zero.

function = (at > > 8); // get the function code (stored in the high bytes // of the AX register).

if ( function==0x36 II function==0xlC ) // Functions : Get Disk Free Space // Get Drive Data original(); // enable old INT 21 handler ~dos~getdrive( & curdrv); // get currently active drive if (( (dx & 255) == 0 & & (curdrv+64)==intercept~drive ) II (dx & 255) == intercept~drive-64 ) // The DX register holds a number representing the // drive. If it is zero, the default drive is // specified.

dx & =65280; // set lower bytes of DX register to zero dxl=3; // set lower bytes of DX register to three // (represents the hard disc) rs=4; // set rs=4 so that DX is restored after // the interrupt call updated(); // restore the new version of the INT 21 handler ) if ( function==Ox3D II function==Ox3C II function==Ox4E II function == Ox6C function == 0x5B 11 function == 0x41 11 function==0x13 II function==0x39 II function==Ox3B II ax==0x4300 11 ax==0x4301 function == 0x56 ) // Functions: 3Dh - Open file with handle 3Ch - Create file with handle 4Eh - Find first file 6Ch - Extended open/create 5Bh - Create new file 41h - Delete file 13h - Delete file with FCB 39h - Create directory 3Bh - Change current directory 4300h - Get file attributes 4301h - Set file attributes 56h - Rename file original(); // disable INT 21 handler.

name~cache = open(name~cache~file, O~RDWR | O~BINARY); // open the index file if ( function != 0x13 ) { if ( function != Ox6C ) filename=MK~FP(ds,dx); else filename=MK~FP(ds,si); // for all overridden functions except 0x13, a // pointer to the filename is found from either the // DS,DX or the DS,SI registers.

else filename=((char far *) fcb~filename)+2; // make the filename pointer point to the // fcb~filename variable (where the filename is // stored after it is built up by the code below).

// The extra two bytes are reserved for a drive // specification (if necessary).

fcb~filestart=MK~FP(ds,dx); // the DS,DX registers point to the start of an // FCB structure, from which the filename etc can // be obtained.

if ( *fcb~filestart != 0 ) // the first byte of the FCB structure is // the drive.

*fcb~filename=*fcb~filestart+64; *(fcb~filename+l)=':'; filename-=2; // if the drive specified is not zero (i.e.

// the default) then the drive specifier is // added to the beginning of fcb~filename // and the pointer moved accordingly.

) dest=2; // set destination offset to 2, in the fcb~filename, // after the 'X:' characters.

for ( src=l; src < = 11; src++ ) { if ( *(fcbfilestart+src) != ' f *(fcb~filename+dest)=*(fcb~filestart+src); dest++; // copy a byte and increment // destination pointer if ( src == 8 ) i(fcbfilename+dest)='.'; ~ dest++; // after the eighth character // add a ) *(fcb~filename+dest)=O; // append ASCII zero to mark end of string.

) ~dos~getdrive( & curdrv); // get the current drive if ( build~path(local~path, filename)==0 ) // convert the filename to a full path. If the build~path // routine returns zero, then the file needs to be // rerouted.

if ( function == 0x56 ) // rename file f already loc=O; // set already~loc flag (indicating if the destination // file is already in the index) to False.

dest~nof=(build~path(rename~path, MK~FP(es,di))); // convert the rename filename (pointed to by // ES,DI) to a full path. (dest~nof is used as a // temporary variable here).

if ( dest~nof == 0 ) // if the rename filename is on the // intercepted drive src = open(renamepath,O~RDONLY ss O~BINARY); // attempt to open the destination filename if ( src != -1 ) dest~nof=O; close(src); // The destination file already exists // so the rename cannot take place.

// Therefore set dest~nof (not found) to // false (O),'and close the opened file.

else ( dest~nof=1; // otherwise the destination file does // not exist.

) cache~search(rename~path+3); // search the index for the destination filename.

// The 'X:\' is not stored in the index, so the // +3 offset removes this.

if ( found == 1 ) // if destination filename is already in the index, generate~fVLlename(nc~search,destination~version) // build filename under which the destination // file has already been stored and store in // destination~version.

src=open(destination~version, O~RDONLY); // attempt to open the destination version if ( src != -1 ) { close(src); dest~nof=0; // the destination file already exists, // so disallow the rename by setting // dest~nof to zero.

) else f dest~nof=1; alreadyloc=1; // the destination file does not exist, // but it is in the index.

// Therefore, set dest~nof to true, and // already~loc to true.

else { dest~nof=O; // if function is other than rename, then // set dest~nof to its default value of // false.

) local~filename=local~path+3; // set local~filename to local~path minus the // initial 'X:\'. This variable then holds the // filename passed by the calling routine.

// e.g. the file to be deleted/opened/renamed etc.

cache~search(localfilename); // search for the specified filename in the index.

if ( found == 1 ) // if the file is found in the index generate~filename(nc~search, stored~version); // build the filename under which the // file has been stored on the writable // media allocated=ne search; // store the file number which it was // allocated under for future reference.

if ( function != 0x13 & & function != 0x39 & & function != Ox3B & & function != 0x56 & & function != 0x41) // If function is other than // Delete file with FCB // Delete file with handle // Create directory // Change current directory // Rename file { ds=FP~SEG((char far *) stored~version); // set data segment (DS) register // to the data segment of the stored // version if ( function != 0x6C ) // function 6C (extended open/create) // stores the pointer to the filename // in the DS,SI registers, rather // than DS,DX.

dx=FP~OFF((char far *) stored~version); rs=1; // rs is set to restore the // DS,DX registers ) else ( si=FP~OFF((char far *) stored~version); rs=2; // rs is set to restore the // DS,SI registers ) else f if ( function == 0x13 ) // delete file using FCB ( rs=lO; // rs=1O causes the DOS call // to be overridden completely unlink(stored~version); // delete the stored version // (if exists).

} if ( function == Ox3B ) // Change current directory { rs=11; // causes DOS call to be // overridden completely if ( function == 0x56 & & dest~nof == 1) // rename file f rs=15; // causes DOS call to be // overridden completely.

// If dest~nof is false, then // the call is not overridden // and DOS gives the error.

) if.( functian-== Ox4l ) // delete file with handle } unlink(stored~version); // delete file from writable // medium rs=11; // causes DOS call to be // overridden completely else ( if ( ( ( (ax & l)==1 || (ax & 2) == 2 ) & & function == Ox3D ) ( ( (bx & 1)==1 II (bx & 2)==2 ) & & function == Ox6C ) ( function == Ox6C & & ( (dx & 1)==1 II (dx & Ox20)==Ox20) ) II function==Ox3C function==0x41 & & function!=Ox4E function==Oxl3 || function==Ox39 Ii function==Ox5B (function==Ox56 & & dest~nof==1) // determine if the file needs to be copied from // the non-writable to the writable medium or if // the file name needs to be added to the index. This // is true if: // Opening a file for write or read/write (3D,6C) // Creating a file (6C) // Creating a file with a handle (3C) // Deleting a file (41) // Deleting a file using FCB (13) // Creating a directory // Creating a new file (5B) // Renaming a file (56) { src=-1; // set src handle to reflect that source file // was not found if ( function != 0x39 ) // for functions otber than create directory blocks read=0; // count of the number of 1K blocks already // copied generate~filename((filelength(name~cache)/128), stored~version); // generate the filename of the next // available file on the writable medium src = open(local~path,0~RDONLY I O~BINARY); // open the source file on the // non-writable medium dest = creat(stored~version,S~IWRITE); // create the destination file on the // writable medium ife unction != Ox41 0x41 & & function != 0x13) // for functions other than delete, // copy the data across { while ( read(src,buffer,1024) == 1024 ) f write(dest, buffer, 1024); blocks~read++; ) // read and copy a 1K block lseek(src, blocks~read*1024, SEEK~SET); while ( read(src,buffer, 1) == 1 ) write(dest, buffer,1); // copy remainder of file // byte by byte close(dest); // close destination file if ( function != 0x13 & & function != Ox56 & & function != 0x41) // for functions other than delete // and rename { ds=FP~SEG((char far *) stored~version); if ( function == Ox6C ) { si=FP~OFF((char far *) stored~version); rs=2; else dx=FP~OFF((char far *) stored~version); rs=1; // set up processor registers to point to new // version offile (on the writable media).

// Set rs appropriately so that registers // are restored after call.

else { if ( src != -1 & & ( function == 0x13 11 function == 0x41 ) ) // if the source file exists, and the // function requested is delete.

{ unlink(stored version); // delete the stored version.

if ( function == 0x13 ) rs=10; else rs=11; // set rs appropriately so that ~ ~ // the function is skipped and the // registers are set correctly ) if ( src != -1 & & function == 0x56) // if source file exists and function is // rename ( rs=15; // skip INT 21 call completely else // (change current directory function) getcurdir(intercept~drive - 64, curdir+3); // get and store the current directory nc~search=strlen(local~path)-l; *(local~path+nc~search)=O; // remove final backslash from the local~path // (N.B. nc~search used as temporary variable // here) if ( chdir(local~path) == 0 ) // change directory // if directory change was successful, then // change back to original directory.

*curdir='E'; *(curdir+l)=':'; *(curdir+2)='\\'; chdir(curdir); else f // if change was unsuccessful then set rs so // that DOS's error message is withheld.

rs=11; ) *(local~path+nc~search)='\\'; // return backslash to end if ( function == Ox5B & & src == -1 ) unlink(stored~version); // if create new file and file doesn't exist then // remove the stored version.

if ( rs != O || function == Ox5B & & already~loc==0 ) allocated=filelength(name~cache)/128; lseek(name~cache, OL, SEEK~END); write(name~cache, local~filename, 128); // add the filename to the index file if ( src != -1 ) close(src); // if the source file is open, close it.

) ) if ( rs == 15 ) // rs==15 indicates that the function is // rename.

if ( already~loc == 1 ) rename(stored~version, destination~version); // if the destination file is already // in the index, rename the source file // on the writable medium.

else lseek(name~cache, ((unsigned long) allocated)*128, SEEK~SET); write(name~cache, rename~path+3, 128); // otherwise change the name of the stored file // in the index.

generate filename((filelength(namecache)/128), stored~version); // generate filename for the last file that was // added to the index unlink(stored~version); // delete this file lseek(name~cache, 0, SEEK~END); write(name~cache, local~filename, 128); // remove filename from index // the above four lines of code remove the duplicate filename // created before the file is renamed close(name~cache); // close the index file updated(); // reinstate the new INT 21h handler ) dsc=ds; dxc=dx; sic=si; bxc=bx; // store the status of the DS,DX,SI,BX registers before the // calling of the standard DOS INT 21h handler.

if ( rs == 10 11 rs == 11 11 rs==15 ) // these rs settings result from: // delete file using FCB // change directory // rename file // all of which require that the DOS call is not performed if ( rs == 10 ) ax & =65280; // for delete file, set lower bytes of AX to zero.

else { asm pushf; // push flags register on to stack ~FLAGS=flags; // set flags register to initial handler value asm add ax,O; // set carry flag to zero flags=~FLAGS; // set flags variable to restore the new flag value - - - asm popf; ----/j--pop flags register off stack else DS=ds; AX=ax; BX=bx; CX=cx; DX=dx; ES=es; SI=si; DI=di; FLAGS=flags; // set registers to their values on entry to the handler asm push ds; // store DS on stack asm int 0x63; // call original DOS Int 21h handler // (a user interrupt is set up as the old handler) asm push ax; // store AX on stack flags=~FLAGS; // get the flags register (this code uses AX) asm pop ax; // get AX from stack ds=~DS; // store DS register in ds variable asm pop ds; // restore DS ax=~AX; bx= BX; cx=CX; dx=~DX; es= ES; si=-SI; di=I; // store registers values so that they can be restored // on the exit of the handler if ( rs != 0 ) if ( rs == 1 & & ds==dsc & & dx==dxc ) // if DS,DX is to be restored and DS,DX was not altered // by the DOS handler { ds=dso; dx=dxo; // restore DS,DX.

if ( rs == 2 & & ds==dsc & & si==sic ) // if DS,SI is to be restored and DS,SI was not altered // by the DOS handler ds=dso; si=sio; // restore DS,SI.

) if ( rs == 3 & & (bx & 255)==(bxc & 255) ) // if BX is to be restored and BX was not altered // by the DOS handler f bx & =65280; bxi=(bxo & 255); - // restore BX ) if ( rs == 4 & & (dx & 255)==(dxc & 255) ) // if DL is to be restored and DL was not altered // by the DOS handler dx & =65280; dxl=(dxo & 255); // restore lower eight bytes of DX ) int main(int argc, char *argv[]) // entry point of the TSR ( int counter; // define counter used during the allocation of a // user interrupt number unsigned char interrupt~number=0x60; // holds user interrupt number being tested for use ~fmode=O~BINARY; // set file handling mode to binary puts("\nCD Writable TSR version 6.45f\n"); // display opening message on screen if ( argc != 3 ) puts("Bad Parameters"); exit(1); ) // the user needs to specify which drive the CD-ROM is.

// If this is not done, an error is given.

while ( ~dos~getvect(interrupt~number)!=MK~FP(O,O) & & interrupt~number < = 0x66 ) interrupt~number++; // search for available user interrupt if ( interrupt~number == 0x67 ) f puts("No available user interrupts"); exit(2); ) // display error if no available interrupts intercept~drive=toupper(*(argv[ 1])); // get the intercept drive from the command line *(stored~version+9)=intercept~drive; *(destination~version+9)=intercept~drive; *(name~cache~file+16)=intercept~drive; // change the drive letter where necessary if (*(argv[2])=='N') { name cache=creat(name~cache~file, S~IREAD W S~IWRITE); close(name~cache); // - // create a new index~file if parameter N is // specified (otherwise use existing version) pokeb(FPSEG((void far *) & main),(FPOFF((void far *) & main)) - 205, interrupt~number); // change the asm INT 0x63 instruction to the interrupt number // in interrupt~number by directly poking the memory address // 205 bytes before the main() function.

oldhandler = ~dos~getvect(INTR); // fetch address of existing INT 21h handler dos~setvect(interruptnumber,oldhandler); // copy address to the user interrupt ~dos~setvect(INTR, handler); // install the new INT 21h handler keep(0, (~SS + (~SP/16) - ~psp)); // return to DOS while keeping the TSR in memory return 0;

Claims (11)

1. CLAIMS: 1. A method of simulating the writing of data to a storage location of a read-only memory (ROM) comprising receiving data addressed to be written to the ROM storage location, diverting the data and writing it to a storage location of a writable storage device, and when the ROM storage location thereafter is addressed for reading, outputting the data written at the writable storage location instead of that at the ROM storage location.
2. 2. A method as claimed in Claim 1 wherein said reading comprises reading the original data from the said ROM storage location as part of a larger quantity of data from the ROM, reading also the data from the writable storage location, substituting that data for the data read from the first mentioned ROM storage location, and outputting the larger quantity of data with said substitution.
3. 3. A memory device comprising a read-only memory (ROM) having storage locations therein, and means for simulating the writing of data to a said storage location, the simulation means comprising a writable storage device, means for receiving said - aata to be written to said ROM storage location and for diverting it to a corresponding writable storage location in the writable storage device, and means for reading the data at said writable storage location in response to a command to read the data at said ROM storage location.
4. 4. A device as claimed in Claim 3, wherein the ROM is a CD-ROM.
5. 5. A device as claimed in Claim 3 or Claim 4 wherein the writable storage device is a hard disc.
6. 6. A device as claimed in Claims 3, 4 or 5 wherein the means for diverting the data comprises means for intercepting and modifying a high level command to write data to the ROM storage location.
7. 7. A device as claimed in Claim 6 wherein the means for intercepting is a terminate and stay resident (TSR) program.
8. 8. A device as claimed in Claim 3,4 or 5 wherein the means for diverting the data comprises means for intercepting and modifying a low-level command to write said data to the ROM storage location.
9. 9. A device as claimed in Claim 8, wherein the means for intercepting is a device driver.
10. 10. A computer comprising a memory device as claimed in any of Claims 3 to 9.
11. 11. A method, a memory device or a computer substantially as herein described with reference to the accompanying drawings.