CP/M

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

/ CP/M / CPM_CDROM.iso / cpm / nstar / geneusys.doc < prev next >

Wrap

Text File | 1994-07-13 | 13.9 KB | 249 lines

February 24, 1981 R. L. Plouffe (703) 527-3215 GENEUSYS.DOC a description of: GENEUSER.ASM and GENESYS.ASM * * * * * * * 12/14/81 GENEUSER.ASM rev 3.0 is a major re-write which extends the CCP and allows N additional user-defined commands. As distributed, it contains CCP-included code for BYE, LOGIN, ORIG, ANSWR, and PASS. It has three password levels (0, 1, & 2) which permit certain commands at each level. Transient commands have the same three levels by placing transients in user 13, 14, or 15 respectively on drive A. Files are universal in all user areas on drive A only if they are in one of these three user areas and depending on password level achieved. * * * * * * * The purpose of the files on this disk is to create a user area in cp/m as distributed by Lifeboat associates for north star double density controller oriented systems that is expanded by either 1 or 2 kb. This is done by writing to and reading from the first four sectors of the north star disk. This is where the additional user code is made to reside. The key to the process is GENESYS.COM which initially loads at 100H but immediately moves itself to just above the 'sysgen' image (2D00H), thus leaving the ram space from 100H to 08FFH available to write user code. When a cpm.com file is SAVEd after patching in user code with DDT, the second area of user code is saved along with the rest of cp/m. GENESYS is then used to write this cp/m system to the system tracks starting from the first sector of the first track and from RAM starting at 100H. The code in the first block in the 100H page must contain a special ORG at 05CH of that page and a DS 1 placed there. This is to provide storage space for the format byte which the lifeboat bios checks there. This special ORG is contained in GENEUSER.ASM in its INIT routine. GENESYS patches into your system a completely new coldboot loader that loads all 10 sectors of both system tracks except that it skips sector four of the first track since the boot prom will have already loaded that code. The coldboot loader is made to run at CCP-100H as before and it loads the rest of the code to ram starting at CCP-900H. Thus, the cp/m system is in it's normal location with additional code from CCP-900H to CCP-100H (2kB). The scheme in GENEUSER.ASM is to run the user INIT routine here since it is throw away code anyhow and will get clobbered since this is in the top of the TPA. The INIT routine in GENEUSER contains a mover which moves the second user area code which is also now in ram between CCP-100 and CCP-900H to just above the running cp/m system. A feature of the new cold boot loader is that in the event of a bad disk read, the loader will permit a reboot only eight times and then reset the controller and halt the computer if still not successful instead of rebooting endlessly as the loader in your distribution version will do. This is important if you have implemented auto power up and power down using the PMMI modem auxiliary interface and your computer is activated remotely. Who wants the possibility of endless head loading, unloading, stepping and disks whirring until you get home - yuk. GENESYS also patches your cp/m system so that it is boot PROM independent. This is done by having the coldboot loader patch all of the PROM dependent bytes in the BIOS regardless of where your PROM is located. The coldboot loader is made to point to a table already in your cp/m system that contains the addresses of these bytes. Someone put an error in each of these tables for each version that GENESYS knows about so it simply patches out the error prior to writing out a system. The error is apparently an introduced bug to prevent the system from working when you relocate your disk controller PROM. The coldboot loader then uses the table to patch all of the prom dependent bytes using knowledge of the prom location passed to it by the boot prom firmware itself. GENESYS and GENEUSER will work with Lifeboat's cp/m 1.45, 2.01, 2.2, 2.21A & 2.22. The tables, prom info storage locations, and exit to bios addresses are different from one version to the other, however GENESYS knows about all of that and tests for version number in the second byte of the serial number. That byte is 0EH (14 decimal) for version 1.45, 20H for version 2.0 and 22H for version 2.2. If anyone has modified the serial number (who would do that?) and changed the second byte, then GENESYS won't work and will give a bad version message. Once the second byte is tested, then GENESYS patches the cold boot loader to contain the proper addresses before writing out your system to either a file or to your system tracks. Oh yes, I forgot to mention that GENESYS (unlike Sysgen) has an option which you will see in the prompts to make and write a cpm.com file or to write to the system tracks on the selected destination drive. When writing a cpm.com file with GENESYS, writing a system from one disk to another, or taking a cpm.com file from one disk and writing either a system or a file to another drive, GENESYS will always check the format byte of the destination drive and patch that byte into the image before writing to that disk. So the format byte which the files on that drive were written for is assured not to be changed. This is especially important for cp/m 2.2 which can read or write from or to any of the defined lifeboat formats. Since GENESYS initially loads at 100H (but not above 8FFH), it will not permit you to skip the source drive prompt as 'Sysgen' will in order to write out a system that had been brought in with DDT. This is because GENESYS first loads at 100H and would clobber any code from 100H to 08FFH that DDT would have written. So, you must bring in the image with GENESYS from either a file or system tracks and not with DDT. You can bring in a cp/m.com file on the command line with GENESYS, but it must be 40 North Star blocks in length because GENESYS tests such a file to see if it is complete. So, when you save a cpm.com file that has been patched with DDT always save it as SAVE 40 (Dr:)CPMxx.COM (xx=sysize). Even if the SAVE prompt as a result of making a new system with MOVCPM under 1.45 says to SAVE 36 do a SAVE 40 instead. When patching in a revised user area with DDT use the overlay offset computed in the GENEUSER.PRN file but first fill 100H to 8FFH and 2700H to 28FFH to zero (2400H to 28FFH when using version 1.45). All of the code will appear in the right places from 100H to 2900H. **************************IMPORTANT****************************** Start out fresh with a cpm.com file made from MOVCPM with the prom dependent bytes unchanged and at the standard location (0E800H). Then overlay the user code from GENEUSER using DDT. Then SAVE this image as a cpm.com file. Then use GENESYS to write to the system tracks. The prom dependent bytes will be changed only in the running system and not in the cpm.com file although other clean up to the cpm.com file will be done when making such a file with GENESYS. If you have already changed the prom dependent bytes in MOVCPM manually, then you must change the PROM equate in the coldboot loader of GENESYS.ASM as well as the disk read command (0EB40H) in the bios options area of GENEUSER.ASM for version 1.45 in spite of the admonitions in those files not to do so. Then perform the four steps just covered above in this paragraph. Either procedure will then give you a disk that will boot up and run on any North Star regardless of where it's disk controller PROM is located. Procedure 1 is preferred but any other procedure will invite DISASTER since the coldboot loader is going to add the difference between the actual prom hi byte and the value contained in the coldboot loader to all of the prom dependent bytes in the bios. So if you had already patched these bytes manually and don't start fresh (procedure 1) or follow procedure 2, the new coldboot loader will add an additional offset to all of the prom dependent bytes and your system wont run. So, a word to the wise - be careful and make sure you understand this procedure. Once you have started fresh (either procedure) as outlined above, you can always make your CPMxx.COM file using GENESYS prior to patching in a new or revised user code using GENEUSER and DDT provide that the image brought in is one that originated from a fresh start. If you change the user code in GENEUSER, keep the same skeletal organization. Key parts of the skeletal are the movers, the orgs including the special org at INIT+5CH. You may add code in front of USR1END and USR2END to the extent that you have space in the two areas available and have properly allocated space above cp/m by sizing your system appropriately. Also any code in an area that has labels followed by EQU $+OFFSET must be similarly labelled and equated. The GENEUSER file provides for USER1 to be 256 bytes to be compatible with version 1.45 without the buffer being moved (you can make USER1 an additional 1k bytes resident on the system tracks with 1.45 by moving the buffer up by 1k or to any place else out of the way). USER2 can be either 1 or 2 kB and you must make space above cp/m by appropriately sizing your system. Actually USER2 in its running location will be less than 2 kB by the amount of code in the INIT routine since that code doesn't get moved but gets thrown away, so if you make a 2kB USER2 area there will be some space at the top which you can use as a scratch area for other purposes. GENESYS is written using only 8080 mnemonics. GENEUSER uses Z-80 code stored as DB's so that it will assemble with an 8080 assembler. The Z-80 implementation saves considerable space but you should easily be able to convert it if your computer is 8080 based. Just keep the same skeletal arrangement. GENEUSER contains a number of goodies such as full IOBYTE implementation, PMMI modem routines, Computime T-102 clock routine, and North Star parity memory error detection and ram parity error message. Look through it carefully to check all of the conditional assemblies, port assignments and equates for your system including clear screen, mode byte and selection of drive characteristics in the bios options area, and configuration byte also in the bios options area. You don't need to know controller PROM location for parity memory option since GENEUSER will get this as a passed parameter either from the bios in 2.0/2.2 or the coldboot loader for 1.45. Now, what the heck is all of this good for. Well aside from GENESYS cleaning up your system so that it will be disk controller PROM independent, work with any version in conjunction with GENEUSER and provide for expansion of user space resident on the system tracks, the reason this project got started was to provide for substantial amounts of space for communication networking and file transfer software to be resident at the user's beck and call and available remotely as well upon auto start up and answer using the PMMI modem. The next project is to get that code in there. SPECIAL NOTE If you have version 2.21A by Lifeboat, there are a couple of bugs which you should know about. First, the user area code on the distribution diskette has an IOBYTE implementation but contains a serious flaw. The author apparently forgot to save and restore registers in the routine that maps logical to physical devices. If you wish to use that code, it is recommended that you change the mapping routine to the one contained in GENEUSER.ASM that is on this disk as a companion to GENESYS. Otherwise you will find that the user code on the distibution diskette will not work with software such as BYE.COM and MODEM.COM by Ward Christianson as well as MBASIC ver 4.4 although it will work with MBASIC 4.51. It is suspected that plenty of other software that is not expecting registers to be corrupted would not work either. Of course GENEUSER will work with all of the above. The second bug has to do with the MODE byte. The bios on the distribution diskette has a stack imbalance in the routine that tests the MODE byte and POPs the PSW once too many times if the 40H bit (READ AFTER WRITE) is set high. This is corrected in the FIX221A subroutine of GENESYS by setting the extra POP PSW byte to NOP. Without this correction, the read-after-write function does not work properly and FORMAT.COM as well as PIP.COM do not work. So a system that is 'gened' with GENESYS has this bug fixed and you can set the read-after-write function in the MODE byte without fear. These bugs were fixed by Lifeboat in ver 2.22. ****** C A U T I O N ****** ONCE YOU USE GENESYS TO 'GEN' YOUR SYSTEM, DO NOT USE 'SYSGEN' ANYMORE SINCE IT WILL NOT READ OR WRITE THE FIRST FOUR SECTORS OF THE FIRST TRACK. RETIRE 'SYSGEN' TO THE ARCHIVES, SINCE GENESYS WILL DO THE SAME AND MORE EVEN ON SYSTEMS THAT HAVE BEEN 'GENED' USING 'SYSGEN'. Have fun and let me know how you make out, but no complaints please. r.l.plouffe