bobc@killer.UUCP (Bob Calbridge) (03/07/88)
Can anyone explain alt mode in CPM Plus on a C-128. I have the 128 System Guide that came with the machine but it seems that Commodore was quite terse with information concerning the CPM side of the machine. There is some metion made concerning toggling the mode on and off but so far the alt key seems to make no difference on anything. I'm also interested in being able to change key definitions from within a C program. Any help there? 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
howie@pnet02.cts.com (Howard Herman) (03/13/88)
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