Xref: utzoo comp.sys.cbm:1220 comp.os.cpm:1303 Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!husc6!tut.cis.ohio-state.edu!uwmcsd1!marque!gryphon!pnet02!howie From: howie@pnet02.cts.com (Howard Herman) Newsgroups: comp.sys.cbm,comp.os.cpm Subject: Re: terminal modes on C-128/CPM Message-ID: <2866@gryphon.CTS.COM> Date: 13 Mar 88 11:20:26 GMT Sender: root@gryphon.CTS.COM Organization: People-Net [pnet02], Redondo Beach, CA. Lines: 84 In article,<3610@killer.UUCP>, bobc@killer.UUCP (Bob Calbridge) writes: >......... >I'm also interested in being able to change key definitions >from within a C program. Any help there? Well, not from within the program, but before with KEYFIG. What you ought to do is set-up different CP/M sys's for each of your different applications, using KEYFIG to define the keys as you would like them to be for each. So, you would have one CP/M boot disk for C programs, another for dBASE, etc. Now when you change from running one to the other it is not necessary to close down and re-boot CP/M. Merely run KEYFIG, have it get the new key definitions you want from the new CP/M disk, have it define these new definitions as current, exit KEYFIG, and as many keys, up to every key on the keyboard will have been re-defined according to how you set it up with KEYFIG. Changing key definitions with KEYFIG in this manner should take about 15-20 seconds, allowing for load time of the program, and then you are set to run your new application, with a newly re-defined keyboard. You could even have the second CP/M sys on another drive, from which you run KEYFIG, and avoid the need to swap disks. For additional CP/M sys's, you may try using different user areas, again avoiding any need for a swap of disks. >While I have you all here let me throw out another problem that I would like >to nail down. I use two 1571 drives. I usually have all the system and >utility files on drive A: and do my work on drive B:, having done a >"setdef a:,b:" to arrange my search path. This is all taken care of by >my profile.sub file. However, no matter which disk, brand or density, I >use eventually one or two files get corrupted on the A:drive. I can copy >a new file over the bad one and it will run for a few sessions and then >the corruption occurs again. Often the same files get corrupted but >just as often different files get hit. Too often the file is "submit.com". >Has anyone else experienced problems like this with their drives? >Thanks in advance. >Best, >Bob From your description you give a pretty good hint as to where your prob is. Whenever you use the profile.sub, or for that matter any submit file, a temporary file is written to disk to perform that task, and then is erased. My quess is that you are not leaving enough disk space on your drive A disk for this temporary file to be written, causing it to overwrite other things on the disk. Submit files usually do not take up that much space, but as a precaution, I'll always leave about 10-15k of empty disk space to accomodate them. (As a matter of interest, with DRI's new CP/M sys, for the #1581, any submit file is easily identified, if you see: SYSIN57.$$$. If the submit file completed its task, this will have been erased,however.) BTW, if you are doing any serious CP/M tasks, you ought to consider getting the #1750 RAM, and running from it. It speeds up run time multi-fold. (And, then you could add to your profile: setdef [temporary=m:], and your temporary submit files will be written in RAM, speeding up their application, and saving your disks.) Howie UUCP: {ihnp4!scgvaxd!cadovax rutgers!marque}!gryphon!pnet02!howie INET: howie@pnet02.cts.com