Turbo Toolbox

home *** CD-ROM | disk | FTP | other *** search

/ Turbo Toolbox / Turbo_Toolbox.iso / emulator / cpm86 / ame86.doc next >

Wrap

Text File | 1985-07-30 | 37.8 KB | 1,097 lines

AME86 - (pre)release notes ========================== Version 0.7-x Copyright (c) Jean-Marc Lugrin Digital Equipment Corp. 1983, 1984 Look at the end for distribution policy. Change for version 0.3 ---------------------- Goal: Bug correction, clean-up of register handling. The following changes were implemented: 1) Ensure interupt enabled at emulator boot and emulated program start 2) Ensure direction flag cleared at emulator boot, emulated program start, and when in MSDOS mode (that is in emulator's code). The change have corrected the following bugs: System crash in some COMPAS programs. Some I/O errors in COMPAS programs. Changes for version 0.4 ----------------------- Generally increase robustness and better emulation of file directives. Better documentation. 0.4-1 1) Use two stacks, switch stack and check for stack overflow. This corrected many random crashes. 2) setup DRIVE code im base page like CCPM 0.4-2 1) Convert "?" in extent number (from MSDOS to CPM) in open and search to 0. 2) Allow non-zero extent in OPEN/SEARCH - position block number accordingly. This allowed RED to work with large files. 0.4-3 1) Reject "STAY RESIDENT" Abort Code of SYSTEM RESET. 2) Better handling of S1, S2, CR and RC fields of FCB. See notes on FCB handling. 0.4-4 1) Correct bug in initialisation of non-initialised memory (if I can say). Correct a bug causing some data in DS segment to be zeroed at end of load (in MP.CMD). --- Switch editing to MSDOS under AME86 + RED 0.4-5 1) preparation of implementation of some memory allocation functions 2) Do not attempt to load a section defined in CMD file, with the size MIN/MAX/LENGTH of 0. Do not attempt to load section of LENGTH 0 (but extension still done!). This corrected a bug with the load of some program not generated by GENCMD, like MAINT (a PASCAL program). 3) Do not clear extended area of section. 4) Better initialisation of base page, more exactly like CPM-86 load function. This corrected a bug of RED hanging if there was no file specification in command line. Change for version 0.5 ---------------------- Goal: Implement memory management directives, for emulation of Multi-Plan. Allow full use of CPM-86 development tools. Implement console i/o subset of BIOS functions. 0.5-0 Implement some memory allocation functions for MultiPlan: essentially allocation at end and free all memory. Use this functions internally for program load. MultiPlan, ASM86 and GENCMD are all working with this version. 0.5-1 Implement subset bios: console i/o, set dma, dummy iobyte. Implement Set Random Record function. PIP is working with this version. 0.5-2 Correct error in OPEN and SEARCH NEXT, which cleared some memory at random. Suppressed some "INTERUPT-OFF". 0.5-3 Implementation of FREE at end of region and FREE of region, stack like allocation only. Allow MWC-86 to work. 0.5-4 Cleanup of command line processing (bug introduced with version 0.4-5). Allow CGROMCRC to work again. 0.5-5 Correct status return of close. Add option handling and alternate drive on open. Add better handling of logged-in drive functions. This allow to have programs like RED, COMPAS, MP residing in another drive and being usable without changing current drive. This go beyond normal CP/M-86 functionallity and MSDOS functionallity, but was found very practical. BUG: - RED do not rename small files anymore. A LISP processor do not load files whith partial record. 0.5-6 Correct previous bugs (RED rename and partial record) Correct IOBYTE emulation (limit SET IOBYTE) Implement LOAD PROGRAM function. RENAME function working again (RED). FABS-86 works. LISP works. 0.5-7 Finish and correct memory management directives. More "real" emulation of disk DPB and ALV. Better emulation of logged in disk. Preparation for program load function Translate commande in upper case. Reset original default drive at exit Allow RED/ SELECT/ STAT to display good aproximation of disk free space for floppy, winchester and Mdrive. Winchester and Mdrive are normally logged-in. A: is NOT normally loged in. The translation of the command line to upper case avoid various errors. Change for version 0.6 ---------------------- GOAL: Implement remaining possible system calls (program load, write with zero-fill). Systematic test of major applications, systematic debugging. 0.6-1 Implement chain to program call (can chain to CMD file only), Implement exit status (0 on success, 1 on error) Correct bug reseting the wrong drive at exit Implement write with zero fill Implement option /I (for illegal BDOS and special SEARCH) Implement Fake Allocation Hook for Extended console BIOS call (not yet usable) Correct bug in initialisation of load FCB Better emulation of returned status (0 in AX/BX for most functions) Better IOBYTE (values 15h HEX) Error code 6 returned for file too large in random access Printer interface vector is destroyed. 0.6-2 Implement high speed video using BIOS (this is different from extended console BIOS). Extended console BIOS now works. Get boot drive (extended BIOS) return load drive Corrected a bug of 0.6-1 corupting the stack. Better emulation of READ CONSOLE BUFFER. Correct bug in LOAD PROGRAM (initial and request). Allow to load program with EOF in last group. CP/M-86/80 HELP works (but require option /S) Background printing work INFOCOM games can be loaded (SORCERER works). WordStar (16 bits versions) and FORTH load correctly. BUG: Do not work on Rainbow-100/A (only on B/+), probably due to different clock handling routine. 0.6-3 Correct a bug when saving/ retoring clock interupts, which caused INTERUPT OFF on 100A. Better emulation/ documentation of clock routine. Correct boot drive # which required option /S on HELP. Implement ^C trapping: ^C abort the program restoring MSDOS environment (and with an error message). Implement option /C to select ^C handling mode. Changes for version 0.7 ------------------------ Goal: Implement some changes requested by users (use path names, command mode). More robust interupt control for work with programs modifying CPM interupts. 0.7-1 Introduce option /F, correct a bug in option /S implying /I. Allow /S and /F to work correctly with CHAIN (/F being same as /S). Work (almost) correctly with SWITCHAR. Never require \dev for emulated programs. Allow PATH name to load program. Use PATH name in /S and /F options. REJECT /F/S if PATHNAME, because of bug. Functionality ------------- This emulator allow you to run CPM-86 programs (like RED) under MSDOS. The goal is to ease transfer of already developed applications, and to allow co-existance of CPM-86 and MSDOS applications. The goal is to emulate CPM-86 as commonly used on the Rainbow-100 computer. Program which depend too heavily on internal structure of CPM-86 are not likely to work correctly. This include communication programs (Polygon), debuggers (DDT86), device maintenance programs (STAT, MAINT, FORMAT). The same class of program that is easy to transfer to CCPM should run on AME86. For other limitations see below. It is possible to develop CPM-86 program (using ASM86, GENCMD or MWC or other CPM-86 compilers) under MSDOS+AME86. NOTE: A CPM-86 license is necessary to use Digital Research products with AME86. Installation ------------ Just copy AME86.EXE on a convenient directory of your disquette. Most sources are in AME86.ASM (a very big file), EXCON.ASM (for extended console) and AMEND.ASM (just to mark the end of the code). They have to be linked in the order AME86+EXCON+AMEND, producing an EXE file. Usage ----- You have to copy the CPM-86 programs you want to use under MSDOS, do not forget the overlays, help files and error message files which may be needed. To copy the file you can use RDCPM (provided with MSDOS V2.05) or other file exchange program (like the excellent DOSFLX running under CPM-86), or transfer files in image mode using two computers and Polygon software. IMPORTANT: CMD files are binary files, depending on the program you use for the transfer, you must specify an option, to avoid cutting the file at the first ^Z. For exemple, file transmitted by Polygon XFR must include the IMAGE option, KERMIT must be in BINARY mode. To run a CPM-86 program use the command: AME86 [drive:][path]program-name/options parameters.... AME86 will be searched using PATH (see MSDOS documentation) - but actually the CPM-86 program must reside under the current directory or in a directory specified on the command line. It is possible to specify a drive name too. Options must directly follow the name of the program to be loaded (NO space allowed). If SWITCHAR is "-", the replace "-" for "/" in the examples. The following options are implemented: /C - ^C do NOT abort your program. Under MSDOS ^C may abort your program at any console i/o operation (except some direct console i/o), or even at any system request (disk i/o or other request) if the option BREAK=ON has been used in CONFIG.SYS. This feature is very useful to stop erroneous program, but may be conflicting with the way ^C is handled by the emulated program. If you do NOT want ^C trapping by MSDOS during execution of the program, use option /C. This should be used with program known to work well (like RED). NOTE: If a program had any file opened for writing when ^C is issued, the disks may be corrupted. You should run CHKDSK to check disk structure. /S and /F: Both option are for similar use, they are mutually exclusive. Under CP/M-86 (and MSDOS) a program cannot now from where it was loaded (which drive). Under AME86 it cannot even known from which directory. This is a problem with program using HELP files or OVERLAYS (like RED, TURBO, WS, etc), as they do not known where to look at them. Normally they look at the default drive established at load, or at the boot drive. AME86 return the drive used to load the program as the boot drive. Still the program may look in the wrong drive or the wrong directory. To allow program a way to find their overlay or help file, AME86 can give them a second chance on OPEN or CHAIN (but NOT on MAKE, SEARCH_FIRST or SEARCH_NEXT). The second chance is given ONLY if the file is looked in the drive which was the CURRENT DRIVE when the program was loaded or if a PATH was specified on the command line, and if option /S or /F was specified too. AME86 uses an heuristic to avoid re-trying twice to open using the same file name twice. Inpact on speed is minimal for option /S with floppy drive, with option /F with MDRIVE. Using option /S or F together with PATH NAME may slow down file opening significantly on floppy disks. NOTE: On 0.7-1 a bug preclude the use of /S and /F with path name. /S - Search: Allow for a second chance AFTER the file was looked in the current directory of the specified drive. Possible problem: if the user open a data file which do not exist on the specified drive, and one exist on the load drive, the one on the load drive will be used without warning. /F - First Search: FIRST try to open on the load device and pathname if the drive qualify (is either the default drive at load or the effective load drive and a pathname is specified). Possible problem: if the user try to open a data file on a specific disk, and a file with the same name exists on the load drive, the file on the load drive will be used without warning. /I - Ignore: This option give a better (but less secure) emulation of CPM-86. The following functionality is modified: 1) If the program call CPM-86 for an illegal request, AME86 returns with AX=BX=0. 2) If the program ask for a SEARCH in special mode, AME86 will attempt to emulate it (for STAT and MAINT). This do not run very well now... The option should be used carefully. To simplify usage, you can create a BAT file containing the command: AME86 program/option %1 %2 %3 %4 %5 %6 %7 %8 %9 The program may include a drive and/or path name. CPM file name (in parameters or in prompts) do not support directory path. Exemple of command to execute DBASE: A>AME86 B:DBASE/S Exemple of RED.BAT file: B>A:AME86 A:RED/S/C %1 Exemple of a TURBO from a winchester disk E>E:AME86 E:\usr\bin\turbo/S It is not possible to setup a BAT file if an EXE of the same name is used by the application (like MultiPlan). If you put AME86 and the commonly used batch file in MDRIVE, you will considerably increase load time performances. In this case use option /F instead of /S: E:AME86 E:RED/F/C %1 Do not terminate single line BAT file with CR (carriage return), but directly with ^Z. This may be done with RED if you delete the "<" which indicate the CR. Terminating the line with ^Z (end-of-file) tell MSDOS not to read next line when program exit, saving 1/2 seconds on a floppy disk system... AME86 exit with a status of 0 in case of success or 1 in case of error. (including ^C abort). If you use BREAK=ON in your CONFIG.SYS, MSDOS will check for ^C at any system call. Your program has no possibility to intercept this Control/C: it is aborted. If you use BREAK=ON, and your program normally handle ^C itself, you have to be carrefull to type ^C ONLY when your program ask for some input. These is not always convenient, you may desire to supress BREAK=ON or use option /C. Limitations ----------- Some limitations are just temporary, other are due to the inherent differences between MSDOS and CPM. Any idea how to implement these limitations are welcomes. *.COM (CPM-80) files will NOT run, as MSDOS overlap the space used by Z80 to run programs. Implementation ideas welcomes. All Rainbow specific functions ARE implemented (direct screen addressing, Firmware call) in a way compatible with CPM-86. The following functions are fake'd (i.e. dummy) or have some restrictions: set i/o byte (1) get i/o byte (1) return login vector (4) get allocation vector (2) set file attribute set read-only vector get address disk parameters (2) get/set user code (3) reset drive (4) chain to program (5) 1) - May be fully implemented at a later stage Actually SET I/O BYTE is only accepted if new BYTE is same as old one. GET I/O BYTE return the default I/O BYTE (15). 2) - A dummy DPB is returned. It is based on the floppy DPB but size is changed to reflect current drive (winchester and MDRIVE). It works reasonably well if the DPB is used to compute free space (like in STAT, RED, SELECT). 3) - User code may be equivalenced to MSDOS directory at a later stage (using MSDOS SET command and environment informations). 4) - At start login vector contains only load drive. Each file operation (and select drive) add the corresponding drive. Reset disk and reset drive both call the MSDOS disk reset function. The drive from which AME86 was loaded is NOT automatically logged in. 5) Chain to program try to load a CPM-86 program! It does not give the command to the MSDOS command processor. Internal commands (DIR, USER, ...) cannot be processed. SUBMIT is not implemented. The user could write a CMD program with equivallent functionality. File attributes are NOT implemented - the eight's bit in file name is always 0, and file name are always uppercased, null in file names are replaced by spaces. The following functions are not implemented at all - the program which try to use them is terminated with an error message giving the (hexadecimal) code of the function: A star * means that the function could be fully implemented in a future version. Return SYSDAT address (sorry for DDT86) Direct bios call except console i/o, dma, partial iobyte and BIOS call write to screen. Extended BIOS calls are not implemented except extended console i/o, set/clear user tick routine and return boot drive. * Get Maximum Free Memory at Absolute address Allocate at absolute address is only supported if that address is the same as the start of a free region, like the one returned by Get Max Memory. GSX-86 is not supported. Other differences: The CPM reserved area of FCBs are used by the emulator, and do NOT contains allocation informations. Fields CR, RC, EX, S1 and S2 are almost identical. Some registers listed as destroyed may be effectively destroyed by AME86 but not by CPM-86. Returned condition codes may be different between AME86 and CPM-86. Any information on behavior of CPM-86 in this area welcome. ^C handling and disk i/o error handling may differ quite a bit: ^C print an error message and abort the program, returning an error status. Files are NOT closed, CHKDSK should be run on the used disks to ensure consistency. I/O error is handled as usual by MSDOS, on selection of ABORT, an error message is printed by AME86, to signal that it was able to restore the MSDOS environment. AME86 is normally more restrictive in error handling. Some error which may have been un-noticced under CPM-86 may be show by AME86. Read console buffer use the MSDOS read line function, and the MSDOS line editing facility: this is different of the CP/M-86 line editing. Program checked under AME86 --------------------------- The following programs have been extensively tested: (that is used for real work, or systematically checked with all functions): ASM86 * GENCMD * RED PACMAN (a MWC-86 program) COMPAS-86 MBASIC-86 FABS-86 HELP WordStar version 3 ZORK DBASE * Require a CPM-86/80 license to run on a computer with MSDOS/AME86. The following programs have been partially tested: (that is tested for correct load and work with some exemples given in the user's manual). MP (MultiPlan) MWC-86 PIP (note: PRN: and LST: have the CPM meaning) SELECT-86 (Background printing do not work) The following programs do NOT work: MAINT STAT (except for STAT and STAT X:) MSKERMIT (modify driver) The following common package will not work because they use CPM-80, not CPM-86: CONDOR-3 (v2.1) All package buyed for VT-180. WordStar before version 3. Error Messages -------------- All AME86 error messages are in the format "AME86 - text" the AME86 exit to MSDOS after printing this message. Depending of the file activity, there could be hidden files on the disk. If AME86 crash when there was file activity, it is a good practice to use CHKDSK to recover lost space. All other error message are coming from MSDOS (disk error) or the application program. You may receive an error message from the application that you have never seen on CPM-86 if, for exemple, one of the file is missing. AME86 - error messages: program no found The program to emulated was not found in the current directory of the specified (or default) disk, or AME86 was not followed by a file name, or that file name had a bad syntax. Check for the program IN THE CURRENT DIRECTORY of the SPECIFIED DRIVE. AME86 cannot handle directory name or PATH. Cannot chain to program: The program did exit with a CHAIN statement, the statement was not processed for one of the following reason: - There was an option present. - There was no CMD file on the specified OR default drive. There may be the same errors than on initial program load. The line received is printed after the error message, check it and create or copy the necessary files. Commands like DIR and ERA are not supported. AME86 attempt to directly load the specified program, not to give the command to process to MSDOS. file not a proper CP/M-86 program The file was not in a CMD format (it was not produced by the GENCMD utility). Check if you have a CP/M-86 file - there may have been an error if file copy or file transmission. If the file works under CP/M-86 and you retried the copy/ transmission, there may be an error in AME86. AME86 do not reconise all possible CMD file headers, only the format created by GENCMD. call 99h not emulated or out of range. The emulated program use a system call which is not emulated and which is important for program continuation. 99 represents the (hexadecimal) system call number - see CP/M-86 documentation for more informations on the system call, and see restriction on AME86. 73h may be GSX-86 (which is not emulated). If you believe that this call should be emulated, send the program with necessary informations to reproduce the error to the AME86 developer. You may try to run the program with option /I. BIOS call 99h not emulated or out of range. The BIOS call used is not emulated. If it is 80h, it is an extended console BIOS call. not enough memory to load program. Self explanatory. MSDOS is large than CP/M-86, and you have to add AME86, may be the PRINT and COMMAND resident parts... DEC will be pleased to sell you expansion memory of high quality... EOF encountered when loading program EOF was encountered when loading a section. The file may have been destroyed (for exemple, transmitted WITHOUT the "image" switch and truncated at ^Z). The file header may be corrupted. If you are sure that your file was copied/ transmitted correctly from CP/M-86, and that it works under CP/M-86, send the file to the AME86 developers: its a bug. NOTE: EOF encountered when loading the LAST group of an image has no effect, except loading garbage in the allocated area. This is for compatibility with CP/M-86/80. Cannot load at absolute address Your program contain a section which should be loaded at absolute address. This is not supported by AME86. group larger than 64k When loading a program, a group (data, program or stack) was larger than 64kb. This is not actually supported by AME86. Send the program to the AME86 developer. file too large for CP/M-86 handling. CP/M-86 cannot handle files larger than 31 extends of ? bytes. This is quite big. If you have created a file larger than this maximum size using MSDOS, and want to read it under AME86, you receive this error. Sorry. ? in drive not supported for search Your program use the search function with a "?" in the field DRIVE NUMBER of the FCB. This is not supported. This program is probably to dependent on CP/M-86 directory organisation to be of any use under MSDOS/AME86. You may try to run the program with option /I. Make only supported for extent 0. A MAKE function was attempted with a non zero extent number. This is not supported by AME86, as being to dependend of BDOS handling of FCBs. internal stack overflow. Send the program and the informations to reproduce the error to the AME86 developers. This is an internal error. application stack overflow. Your application use the (96 bytes) default stack, and overflows; or your application destroy some part of AME86 (the guard word is the last word of the code). Your application must be changed. Emulated program cannot stay resident Your application attempted a SYSTEM RESET (i.e. program exit) with a non-zero Abort Code - this is not allowed. It is not possible to run an application which should stay resident when other application are running. It is possible that the abort code was neither 0 nor 1 - this is undefined by CPM-86. Internal memory initialisation failure Internal MSDOS database may have been corrupted by a previous program. Or there may be a bug in AME86. Reboot MSDOS and run the program again. Check memory. Illegal option The option specified in the command file (with the program to load) was not a legal one. Or the file name contained a "/". Retype the command correctly (options must be one letter long, either upper or lower case). The option character is always "/", independently of MSDOS setup. Options F and S are mutually exclusive You specified both /S and /F. Read again description of /S and /F: both acheive basically the same result in different ways. Rule of thumb: if the program reside in MDRIVE, use /F, otherwise use /S. Use none if your program do not have overlays! Pathname cannot be used with /S and /F Put the program on an alternate's drive CURRENT directory. Illegal IOBYTE value A SET IOBYTE function (BDOS or BIOS) attempted to change the IOBYTE value. IOBYTE functionality is not supported for this release of AME86. Communication programs normally do NOT run under AME86, as they are too operating system dependant. If you need to redirect standard input/output of other programs, you may use MSDOS ">" and "<" redirection facilities. illegal path name Either the path name was too long or misformed. Check for correct path name (for exemple using DIR). path not found One of the directory specified on the path name do not exist. If it hapens after the initialisation pahse of the program, it is an internal error (or your disk is corrupted). Look for the correct path name, for exemple using DIR. illegal wild card character There is * or ? in the name of the file to load. This characters are not allowed, as they have special meaning which do not apply in this situation. program aborted by ^C The user typed a ^C which was not trapped by a program input routine. The program is aborted. This is the same as a ^C on CP/M. If the program directly changed vectors or other important locations, they are not restored. If there was any file opened in WRITE mode, CHKDSK should be run to restore disk consistency). program aborted due to fatal i/o error Either a fatal i/o error was detected, or the user answered A to a non-fatal error. AME86 was able to restore MSDOS environment. Exit condition is the same as done by ^C exit. (use CHKDSK to restore disk consistency). CCPM-86 (concurent CPM) and AME86 --------------------------------- No special effort have been done to cover CCPM migration to AME86. But to ease portables programs (as CCPM is supposed to have MSDOS emulation some day), the following effort was done: 1) C_raw_io function (CPM function 6) implement the code 0FDh, which read with wait. This ease efficient portable programs. 2) Success status return is the same as CCPM (which is a superset of the documented CPM-86). Practically, the status returned may be found in BX and AX. 3) When identical functionality cannot be provided (like direct BIOS access) I plan to implement CCPM subset. 4) In the base page, the field DRIVE (offset 50h) contains the drive number used to load the program (initial load only, not if the PROGRAM LOAD function was used). 5) The MP/M emulation of memory allocation routines may be implemented. Implementation notes -------------------- Basically AME86 emulates the interupt 224 and other environement elements of CPM-86, in two ways: 1) By mapping (after necesseray transformations of parameters) CPM-86 functions to MSDOS functions. 2) By maintenaing an alternate environment (the CPM-86 or emulated program environment). The normal environment is called MSDOS environment. Emulator's environment refer to MSDOS environment with some part of of CPM-86 environment active for quick environment switch. AME86 do NOT implement command language equivallence. Its much more like calling a compatibility mode program from DCL on a VAX. Once AME86 is loaded, it use its first parameter as the (CPM-86) program to load, and the remaining parameters are passed to the emulated programs (the first two parameters results in usual FCB in base page). As the format of the executable files differ, AME86 has to completly implement the program load function (including memory allocation and file name parsing). Most other functions are simply remaped to the the MSDOS equivallent (this is not too difficult, as both operating system were designed with ease of conversion of CPM programs in mind). One exception are the console i/o routines: they are directly mapped to firmware functions. This allow screen handling programs to run as quickly on AME86 as on CPM-86. This defeat the UNIX like i/o redirection on emulated programs using this feature. Hardware functions work the same on CPM-86 and MSDOS (that is direct screen addressing and firmware access). Firmware access is via different vectors on MSDOS and CPM-86, but the vector is part of the context switch process. This is the main reason of the difficulty of using DEBUG on an emulated program (context switch is not done at interupt 3). But hardware may not be shared between MSDOS and the emulated program: unfortunately, there is common hardware between the printer port and the communication port. This is why communication programs which patch CPM-86 to access the communication port cannot work on AME86. Using the extended communication board is possible. If usefull communication programs use the CPM-86 V2.0 AUX: driver exclusively, it could be possible to implement this driver in MSDOS (within or separately of AME86). The most delicate part is FILE SYSTEM. One reason is that the file system is badly documented in both operating systems (CPM-86 and MSDOS). An other reason is that most programs use the file system in quite tricky ways (files are never closed, or closed more than once, or program directly access FCB fields supposed to be reserved to operating system). The misuse of the file system go from unexpected but harmless usages, like MBASIC using random i/o for all file access (even file load), to very unexpected usage, like COMPAS pascal using partially sequential and partially random access (by modifying pointers within FCB) on the same file. The third reason is that MSDOS usage of FCB is quite different than CPM-86: block number and random record numbers are largers, the size of the file is maintened up to the byte, etc... The files themself should not be a major problem. ASCII files are compatible, except that the data after end-of-file character may not be the same (I still hope that no program use that!). Other file structures depend on the application, not from the operating system. File size is limited to the maximum size which may be handled by CPM (~500kb). Directory structure is quite different, but the differences are not important for normal programs. All file names will be forced to uppercase, all attribute bits cleared and null changed to space (in the emulated program's FCB too, not only in the emulator data structure). This may be a problem if a program insists that the file names it uses are not modified (i.e. compared with another file name). The search function returns different values too (an FCB on MSDOS, a directory entry on CPM). That is almost the same, except if somebody access allocation data in this way. AME86 try to create a faked directory entry from the MSDOS FCB. There is no problem if only the file name (and extension) is accessed. FCB are converted back and forth between CPM-86 and MSDOS format on the fly, before and after most i/o operations. Here are the equivallences: Drive, file name and extension are always the same, except for uppercasing, attribute bit deletion and change of nulls to spaces. MSDOS current block is converted to CPM-86 extent number. This limit the number of blocks to 31 (of 128 bytes). if EXTENT contains a "?", it is converted to zero. MSDOS record size is forced to 128 (80h). Current records (CURRENT and CR) are almost the same. When writing sequentially a file under CPM-86, the EX:CR fields go up to 0:80h, the next write set them a 1:1. Under AME86, the EX:CR fields growth up to 0:7fh (like under CPM-86), then is set to 1:0 (instead of 0:80h), then to 1:1 (like CPM-86). AME86 RC (Record count in current extent) is computed from the MSDOS file size and the current record. The result is same RC as under CPM-86. MSDOS file size, date/time and system area are saved to CPM-86 system save area. The CPM-86 system save area (which normally contains allocation informations are now meaningless to the emulated program, which should NOT modify it. CPM-86 S1 and S2 fields are not documented. the OPEN/MAKE function set S1 to zero, and put 80h to S2. S1 is not modified by other functions, S2 is only modified by WRITE, which reset it to 0. Under CPM-86, S2 is set back to 80h at extent switch (that is when it is not necessary to close the file). This functionality is not reflected in AME86, as the file MUST be closed if opened in write mode. Partial record in both sequential and random read are returned as full records (success), zero filled. Actually the system assumes that the maximum size of an extent is 128 records of 128 bytes, and that there is at most 32 extents - this limits size of any file to around 500kb. Read console buffer is not emulated, but directly use MSDOS read console buffer function, with some "patching": DX, AX and BX are returned as 0, and the CR which is added by MSDOS is replaced by a 0. Interupt handling Some interupt vectors are different. Especially the firmware interrupt is different, and must absolutely be changed (context change) when we switch from AME86 to the emulated program. The whole AME86 run in MSDOS mode (included some functions used internally, like memory allocation and program load). Changing the vector is known as context switching. The whole context switch include some other tasks, like stack switch, which are not relevant here. There is 6 places when some context must be changed: 1) AME86 initialisation 2) AME86 exit (including ERROR and ^C exits) 3) INT 224 call from emulated program 4) start/continue emulated program 5) MSDOS interupts which may occurs when emulated program is running 6) Interupt going to emulated program when AME86 is running (or a request is serviced by MSDOS). The vector of concern are: CP/M-86 call (224, E0h) MSDOS firmware interupt call (18h) CP/M-86 firmware interupt call (21h) - conflict with MSDOS CALL MSDOS call (21h) User clock (64h) for both MSDOS and CP/M-86 ERROR, ^C and TERMINATE (22h, 23h, 24h) Any vector that the CP/M-86 program is modifying... The MSDOS idle interupt (28h) may only be given when we do a request to MSDOS, and as such are already in MSDOS context. This interupt need not be switched, and the print spooler may run with AME86. The CP/M-86 call (224) is initialised at start and restored at exit, but stay present even if in MSDOS context, as MSDOS do not use it. Interupt 21h is modified to point on MSDOS handler or firmware just before to give control to emulated program, and at interupt 224. Stack handling. MSDOS switch to an internal stack when called. But is requires that the application has a stack with at least 128 bytes free for interupt handling. COM files receive a stack of 256 bytes. EXE files (as the AME emulator) must setup they own stack. CPM-86 call the user's program with the BDOS stack (of 96 bytes) that the program may use if it do not exceed this requirement. CPM-86 switch to an internal stack after a function call (and most probably after any interupt, as there is no clear requirement for a minimum user stack). The firmware interupts use a local stack. Firmware handling is done one the caller's stack. Firmware + interupt use 62 bytes. AME86 has two stack: An application stack which have 96 bytes + 132 bytes for MSDOS and interupts, and an internal stack. AME86 switch to the internal stack when called. Both stack are checked by guard words (words initialise set to zero, and checked after each call). THE RISK IS THAT THE EMULATED PROGRAM NORMALLY SWITCH ON A LOCAL STACK, WHICH MAY NOT HAVE THE 132 BYTES AVAILLABLE FOR MSDOS. In that case, the emulated program may crash in unpredicatble way if it do not incorporate a stack overflow check - and most programs don't. Distribution: ------------ The program is copyrighted, but may be freely distributed inside and outside of DEC, to any non-military organisation. It is not allowed to sell it, but reproduction costs may be recovered. The sources will be put at disposition on SEENA1::SYS$PUBLIC:, at the following conditions: The original copyright must not be removed or modified. If any modification is done (either bug correction or enhancement), a copy must be send to me, and the enhancement may be included in any future release of AME86. AME86 is intended for use on DEC computers ONLY. To assemble the sources, use: MASM AME86; MASM EXCON; MASM AMEND; LINK AME86+EXCON+AMEND; Any suggestion welcome. Let me know if you want to receive any future version of this program. Jean-Marc Lugrin, SWS SEENA, 21-NOV-1984 SEENA1::LUGRIN (prefered) DecMail @GEV