8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CSDOS-MSGS.SFX / csdos-msgs

Wrap

Text File | 1990-02-12 | 28.0 KB | 804 lines

************ Topic 18 Sat Jun 22, 1991 C128.JBEE [* Sysop *] (Forwarded) Sub: CS-DOS & REU C1750 & LHA & Autoexec One of the most often asked questions is how to set up the C128/C1750/ LHA/Autoexec file to make SFX archives. The autoexec file follows... 24 message(s) total. ************ ------------ Category 3, Topic 18 Message 1 Wed Jul 20, 1994 CBM-ED [e.g.bell] at 09:12 EDT Someone posted a question in Email yesterday that I had to do some research to answer. I made sure this was ok before posting. I believe the answers deserve wider exposure as perhaps they may be useful to more than one person. Also, if I'm wrong, or if others can add more to the discussion, so much the better... that said.... QQ> These are my autoexecs for CS-DOS and they work fine on my RL, QQ> but not on my HD. I do get syntax errors when its loading. I QQ> assume ythe execs are looking for something to install This is not necessarily so. My auto-exec reports syntax errors too but it runs fine. Someone told me that some of these are acceptable so I accept them. Everything works fine! Here is a somewhat detailed breakdown of the posted aut-execs tho... slow ** Puts machine is slow mode bank15:y=peek(57094):poke 57094,y+1:poke 7136,abs(peek(57094)-y) ** Does a poke/peek to address $DF06 ostensibly to detect an REU If the REU is there a 1 is poked into address 7136, which I gather from the rest of the auto-exec is the memory location of the variable 'errorlevel' z:if not errorlevel 1 z:autoexec2 ** Seems to execute 'autoexec2' if no REU is detected. The 'z:' prefix tells CS-DOS to execute one of its routines directly from the source drive, which is set when you boot up. CS-DOS can execute its programs from any installed in its own RAM 'disk' by simply typing the name of that command or program. Alternately, it can execute it directly from disk, as it does above. Incidentally, the command above that is being executed from disk is 'IF' z:setram 21,3 ** This sets aside a portion of the REU for CS-DOS use for its RAMDISK. The RAMDISK is its internal 'library' of commands like DIR, TYPE, ARC128, etc. Internal commands can be executed by simply typing in the name of that command. When referring to the REU, the format of the SETRAM command is: SETRAM <first bank in 1750>-16,<number of banks> This means that the above command sets aside banks 5, 6, and 7. Note again the 'z:' indicating that this command is being executed right from the disk. This *may* mean that if that command is not on disk, you will get a syntax error. I can't confirm that, only entertain the possibility. poke 7120,2*16+5 ** Probably unnecessary in this auto-exec. This is telling CS-DOS how much of the 1750 REU it can use for the buffer in TERM, which is no longer distributed with CS-DOS, and which probably very few are using anyway. poke 7119,2*16+5 ** This sets up CS-DOS as far as how much of the REU it has for use with CSARC1750 and LHA. The formula is: POKE 7119,LOW*16+HIGH Low is the lowest numbered 1750 bank that these programs are allowed to use as a buffer and HIGH is the highest bank + 1. In the example above, you are telling the REU it can use banks 2 to 4 if I understand this correctly. poke 7136,1 ** If I am right about address 7136 being the location of the variable 'ERRORLEVEL', this is artificially setting a flag for the next statement in the auto-exec. if errorlevel 1 goto ramdisk-already-there ** If ERRORLEVEL does not = 1, skip the next steps because the RAMDISK is already in memory. ERRORLEVEL as used by the internal routines is not clear from the documentation I listed years ago. If I'm wrong about this it will change other parts of this as well. Someone else may have to help here as far as the interpretation of the poke to 7136 as I am making some guesses about it. z:getram z:ramdisk ** We have two more installations here. GETRAM is the command used to install the file called RAMDISK from your disk. And again, the RAMDISK is the 'library' of resident commands in CS-DOS. You can configure this yourself if you read the manual and see how with INSTALL, REMOVE, and PUTRAM, this is done. I'm not sure what the 'z:ramdisk' is doing here. It seems to be a syntax error from what I'm reading in the CS-DOS manual. Perhaps someone could help us over this rough spot also. :ramdisk-already-there ** This is just a label within the autoexec file that is jumped to if the RAMDISK is already in memory. Note the ':' in front of it which is probably how CS-DOS knows what it is. if (peek(215) and 128) then fast ** This line determines whether the 128 is 40 or 80 column mode. This is a standard BASIC 7.0 instruction, and just tests bit 7 of address 21. If that bit is set, we are in 80 columns. poke 7150,4:poke 7151,96 ** Set CS-DOS to see your printer as device number 4 and secondary address 96. assign b 9,0 assign c 10,0 assign d 11,0 assign e 12,0 assign i 16,0 assign j 16,6 assign k 16,9 ** This set of lines makes some reassignments of the CS-DOS drive id settings. Of particular interest are the 'j' and 'k' assignments, which point drive 'j' to partition 6 on unit 16, which is in this case probably a RAMLINK. Address 'k', similarly, is pointing to partition 9 on the same unit. run"settimeday",u16 ** Run a BASIC program to set the time of day from the clock in the RAMLINK. Any CMD device with a clock installed could be used by changing the ',u#' part of the statement. ----------------------------------- Autoexec 2 ---------- z:echo there seems to be a problem... z:echo rebooting... z:exitdos This is the second autoexec called if the first one did not detect an reu. It just prints the first 2 messages to the screen then executes the last one, called EXITDOS, which does whatever commands are in that file. I don't have it to examine. As far as I can tell from my docs, tho, it is not a CS-DOS command. Now finally, and I'm sorry for the length of this, but someone did request the information, here is the 'settimeday' program in detail: 570 dv=peek(186) ** Set 'DV' to equal the drive from which CS-DOS was booted 575 open15,dv,15 580 print#15,"t-rb" ** Open a command channel to that device and send the CMD command 't-rb' which reads the time into the drive command buffer in BCD format. The format means Binary Coded Decimal, which I'm not going to elaborate on here. 590 fori=0to7:get#15,x$:t(i)=asc(x$):next ** Read the data from the drive command buffer into computer memory into the array t(). This is only 7 bytes. See your CMD manual for the format of these bytes. In mine, it is in the ADDENDUM on page 19 for RamLink. 600 ift(4)=18andt(7)=0thent(4)=146 610 t(4)=t(4)or-(t(7)>1andt(4)<18)*128 ** Translate the hours and if necessary set the 'PM' bit to 'on'. 620 fori=0to3:pokedec("dc0b")-i,t(i+4):next ** Move the time settings into the computers TOD clock 630 print#15,"t-ra" 640 get#15,a$:t$=t$+a$:if st<>64 then 640 650 close15 660 a$=mid$((t$),09,2):rem the day 670 b$=mid$((t$),06,2):rem the month 680 c$=mid$((t$),12,2):rem the year 690 d$="date ":e$="," 700 f$=d$+a$+e$+b$+e$+c$ 710 print"";f$ ** Read the time in human-coded format (ASCII) into the command then into the computer and display it for user. 720 print"exec z:autoexec3" 730 print"" 740 poke842,13:poke843,13:poke208,2 ** Set up what is called the 'dynamic keyboard' method to execute the file 'AUTOEXEC3'. The line 730 (and line 710 also) contain unprintable code to clear the screen, and in line 730, move the cursor down over the line that prints the 'exec z:...' line. Then the computer is fooled into thinking that you pressed RETURN 2 times. This does the 'exec...' thing if AUTOEXEC3 is on the boot disk. If not, things continue merrily on their way. I didn't (mercifully) have AUTOEXEC3 to discuss here. Again, sorry for the length. I hope you get some proportional value from this tho. :) egb ------------ Category 3, Topic 18 Message 2 Thu Jul 21, 1994 H.HERMAN1 at 04:03 EDT Ed, My goodness, but that looks familiar! :) > QQ> These are my autoexecs for CS-DOS and they work fine on my RL, > QQ> but not on my HD. I do get syntax errors when its loading. I > QQ> assume ythe execs are looking for something to install It would be helpful if you told us at exactly which points during the autoexecs the errors are reported, and what happens. > This is not necessarily so. My auto-exec reports syntax errors too > but it runs fine. Someone toldme that some of these are acceptable so > I accept them. Everything works fine! Chris said that some syntax error messages can safely be ignored. However, these autoexecs should not report any errors. > z:if not errorlevel 1 z:autoexec2 > ** Seems to execute 'autoexec2' if no REU is detected. The 'z:' > prefix tells CS-DOS to execute one of its routines directly Yes. This line is included because my menu offers three ways of entering CS/DOS. One of them assumes that the DOS Ramdisk is installed. This line will reboot the computer in case I was wrong. Here is the autoexec2: ---------------------- z:echo there seems to be a problem... z:echo rebooting... z:exitdos Here is exitdos: ---------------- 10 poke2560,110:poke2561,10:poke768,123:poke769,10:poke56832,0 20 slow:sys65341 BTW, you might find it best to *always* exit CS/DOS by calling EXITDOS. I found that I could not later run some programs unless exitdos was first called. > z:setram 21,3 I set aside this portion of the REU, so that it will not disturb the lower banks which contain files frequently used by Pocket Writer, Pocket Filer, and Pocket Planner. >poke 7119,2*16+5 Again, I want to guarantee that CS/DOS does not disturb my Pocket files. > z:getram z:ramdisk <stuff deleted> > I'm not sure what the 'z:ramdisk' is doing here. It seems If the routine does not "sniff out" the existance of Ramdisk, then it will install ramdisk, getting it from drive z:. More often than not, I am entering CS/DOS via the disk2reu image stashing routine, so ramdisk is pre-installed. disk2reu is many times faster when a user has a BIG ramdisk, and is running from a RAMLink. > poke 7150,4:poke 7151,96 > ** Set CS-DOS to see your printer as device number 4 and secondary > address 96. I'd have to go back over my docs to remember why I did things this way. The actual secondary address, as I recall, is either a 9, or some other number to which a factor has been added. The factor tells CS/DOS something which I do not recall right now. > 600 ift(4)=18andt(7)=0thent(4)=146 > 610 t(4)=t(4)or-(t(7)>1andt(4)<18)*128 > ** Translate the hours and if necessary set the 'PM' bit to 'on'. Yup! And this includes the corrected routine to properly set the time for those who run their 128's late at night, and boot up CS/DOS between midnight and 1 AM. > way. I didn't (mercifully) have AUTOEXEC3 to discuss here. Now you do. autoexec3: ---------- text new print chr$(27)+chr$(85):color6,1 rdir/w date print; time The user has to be careful to include all the files being called on his/her z: drive, else errors will occur. I am pretty sure I included all the files within the sfx. One other thing a user must watch for is the positioning of the cursor on screen while that dynamic keyboard routine runs. I seem to recall that I had to re-set things once I got a RAMLink, and ran with RL/DOS, instead of standard CBM DOS. But doesn't CMD's HD require the user to run under one or another form of RL/DOS? > Again, sorry for the length. I hope you get some proportional value from > this tho. :) Me too. It was sure a lot easier to write these autoexecs than to explain them..... Howie ------------ Category 3, Topic 18 Message 3 Thu Jul 21, 1994 CBM-ED [e.g.bell] (Forwarded) Howie: Fact is, I recognized your handiwork in that auto-exec. I don't use this one, but I do ignore errors in mine. I suspected the person who reported errors was doing so because of the missing autoexec3. I also suspected the rdir, at the very least, was in that file. I don't have any docs on the 'exitdos' command in my documentation listing. Is this some kind of internal command. Also can you elaborate on the ERRORLEVEL variable. I know it is the bit bucket for the GETKEY routine, but does it correspond, as I surmised, with address 7136. BTW, I believe the 96 for your printer SA is because of the ora #$60 thing.... seems to me that if I'm correct about this, you are not sending a secondary address.. tho for an Epson compatible, this may be fine. I prefer 7 for most of my stuff, but I don't use transparent mode. And finally, sorry if I didn't let you know about those chips arriving. Musta forgot. I'll be sending the cash soon! Thanks again. Sure hope they work ok. :) ------------ Category 3, Topic 18 Message 4 Fri Jul 22, 1994 H.HERMAN1 (Forwarded) Ed, While this might be the wrong topic, this seems as good a place as any to continue on. And, if we really get too far afield, we can always rely on Mark to patch things up, and move a topic from here to there, and whatever else may be required to get things back on track.... So to the questions at hand: Thinking about the overll prob a bit more, I am pretty confident that the difficulty is with the HD/DOS not responding the same as RL/DOS to the dynamic keyboard keycodes. As I mentioned, I had to change them when I began to run under RL/DOS instead of CBM DOS, and since it originally worked for our mystery user under RL/DOS, but not from a HD, I suspect the cursoring positioning. It should be a simple matter to change this around so that they call the routine's correct files. (I would volunteer to do this, except that I don't have an HD to test them on.....) (I quess this is an example of the prob when trying to share a piece of programming written to run on a specific hardware configuration, on other set- ups.) As for exitdos, it just seemed to evolve over time. I use it both as an external (drive z:) command, as well as internal command, as it is included in with the other files on the CS/DOS Ramdisk. It originally dates from when I was using a Quick Brown Box, and you may recognize some QBB poke commands. After the QBB left my system, to be replaced by RAMLink, exitdos seemed to continue to do its thing, so I left it intact. I do not know all that much about errorlevel. It seems to be used throughout cs/dos, and can therefore be called in a variety of autoexecs. Without referring to my notes, I seem to recall that it was used with Term, and can be used for many sys errror responses within many autoexecs. I skimmed thru all my cs/dos notes looking for info on that SA entry. I know there is a description for what I did, but I could not locate it. No rush on the cash. I was just happy to hear that the chips arrived. Whenever will be fine! Howie ------------ Category 3, Topic 18 Message 5 Fri Jul 22, 1994 CBM-ED [e.g.bell] at 08:02 EDT Howie: I forwarded this over to this, the correct area for the discussion. I replied to the wrong cat/top earlier. duhhhh! Cam, as long as I'm around here, you NEVER have to worry about being the only one to make mistakes. :) To everyone else, sorry you have to read this again. One of the pitfalls of moving messages here. :( ------------ Category 3, Topic 18 Message 6 Fri Jul 22, 1994 THE.OUTLAW at 16:48 EDT hehehe I know ALL about mistakes Ed! <g> Howie: > So to the questions at hand: Thinking about the overll prob a bit more, I am > pretty confident that the difficulty is with the HD/DOS not responding the > same as RL/DOS to the dynamic keyboard keycodes. As I mentioned, I had to > change them when I began to run under RL/DOS instead of CBM DOS, and since it > originally worked for our mystery user under RL/DOS, but not from a HD, I > suspect the cursoring positioning. > It should be a simple matter to change this around so that they call the > routine's correct files. (I would volunteer to do this, except that I don't > have an HD to test them on.....) If you'd still like to volunteer, I can do the testing :> After installing Autoexec3, I went through and checked out how many syntax errors and when they occured during the loading proccess. Perhaps you can tell what's going on? :: Opening title for CS-DOS :: Ready Ready Ramdisk Installed banks 05 - 07 Ready Ready Ready Ready Ready ?Syntax error Ready ?Syntax error Ready ?Syntax error Ready ?Syntax error Ready ?Syntax error Ready ?Syntax error Ready ?Syntax error Ready Search for settime Ready Date Autoexec3 Ready Command List Seems to me I remember seeing about this many while I ran this from my RL as well. ------------ Category 3, Topic 18 Message 7 Mon Jul 25, 1994 H.HERMAN1 at 04:50 EDT Cam, Gads!! But those are a lotta errors of the syntax variety..... Let me see if I can trace this stuff back. Howie ------------ Category 3, Topic 18 Message 8 Mon Jul 25, 1994 THE.OUTLAW at 05:50 EDT Good Luck! :> ------------ Category 3, Topic 18 Message 9 Mon Jul 25, 1994 H.HERMAN1 at 07:23 EDT Cam, Those drive assignments seem to be causing some of the probs. Do you have a 9, 10, 11, and 12 drive on-line and powered? If not, I'd suggest removing any assign statements that do not apply to your specific set- up. You can use any wordprocessor or editor (including cs/dos) to change the autoexec. Next I suggest loading the Basic program settimeday, and removing lines 710 through 740 (delete 710-740). Then, dsave"@settimeday". Try booting into cs/dos with these changes and let me know what happens. I expect that you will have none of those syntax errors. If all goes well, next, we will pick up the missing commands from autoexec3, and put them into autoexec. Howie ------------ Category 3, Topic 18 Message 10 Mon Jul 25, 1994 THE.OUTLAW at 09:22 EDT Howie, > Those drive assignments seem to be causing some of the probs. > Do you have a 9, 10, 11, and 12 drive on-line and powered? If not, I'd I have all of those but the only one powered is 12. In the drive assignments, if I were to change the ones listed as 16,6 and 16,9 to 12,* - then I'm accessing partions directly? > Next I suggest loading the Basic program settimeday, and removing lines 710 > through 740 (delete 710-740). Then, dsave"@settimeday". Ok, what will this do? (I haven't looked at it yet, about to shortly) Thanks! :> ------------ Category 3, Topic 18 Message 11 Mon Jul 25, 1994 THE.OUTLAW at 13:00 EDT Howie, I haven't gotten to changing the settimeday yet. I don't think I have a problem there. The RTC is being read and after the lib listing at the end of the loading process and printed and then the final 'ready' prompt. I did turn on all the drives rather than take them from the exec. I still got the same amount of syntax errors in the same places. I decided to check the drive assignments and came up with this: assign b 9,0 <- reports drive not ready assign c 10,0 <- reads drive 9 assign d 11,0 <- reports 31,syntax error00 assign e 12,0 <- reads drive 10 assign i 12,7 <- reads 12,16 (CS-DOS partition) assign j 12,12 <- reads 12,1 (I assume it doesn't recognize a 2nd #) assign k 12,19 <- no responce Perhaps I should include a complete directory listing of the files I have for CS-DOS? Maybe I'm missing a few things? ------------ Category 3, Topic 18 Message 12 Tue Jul 26, 1994 H.HERMAN1 at 03:54 EDT Cam, If settimeday is correctly calling (exec) autoexec3, then you are correct, there is no need to change settimeday, and you can safely leave in all the lines. So, lets leave it, as it is. When I run cs/dos, a disk2reu image loader is run first, _or_ not, in the event I know it is already there. The REU image includes the cs/dos Ramdisk in the upper REU banks, and some Pocket Writer 3 overlay files, and Pocket Filer 2 "hidden" overlay files, all in the REU's lower banks. But I digress... The important part is that by the time my autoexec is run, the cs/dos Ramdisk has been loaded into the REU, so that subsequent calls on cs/dos commands can be run direct from the REU. One of these is ASSIGN. From your description of the prob, I suspect that you may not have the ASSIGN command in your cs/dos Ramdisk. If I an right about this there are two easy solutions: (1) Add ASSIGN to your Ramdisk, and save the new Ramdisk, or (2) be sure that ASSIGN is on your z: drive (as a seperate program file), and change the autoexec so that it looks there for ASSIGN: z:assign b 9,0 z:assign c 10,0 z:assign d 11,0 z:assign e 12,0 z:assign i 12,7 etc. As to the prob with cs/dos not properly reading a two digit partition, I suspect that it was never intended to do this, since when it was written we were using drives with _only_ the numbers 0 and 1. You should note that even tho you can assign 16,6 to k:, for example, and it will work fine for directory requests, and direct command line items, it will not work with LHA and other utilties. For LHA, you would have to CP to the partition you want, and then use the i: drive, which is 16,0. Finally, if your HD is drive 12, then by all means change all those 16's to 12, and have them match your HD's partitions, at least up thru partition 9, and the ones you will want to access. Use the drive designator, 12,0, as the "floater" to access partitions higher than 9, once you have done a CP. Keep me informed as to how things are going Howie ------------ Category 3, Topic 18 Message 13 Thu Jul 28, 1994 THE.OUTLAW at 20:10 EDT Howie, > If I an right about this there are two easy solutions: (1) Add ASSIGN to > your Ramdisk, and save the new Ramdisk, or (2) be sure that ASSIGN is on > your z: drive (as a seperate program file), and change the autoexec so that > it looks there for ASSIGN: In the autoexec, there is a syntax line that reads: z:getram z:ramdisk add z:assign to this line? z:assign b 9,0 <-- change the autoexec to have the z: prefix? Thanks :> ------------ Category 3, Topic 18 Message 14 Fri Jul 29, 1994 H.HERMAN1 at 04:30 EDT Cam, Yes! All that needs to be done is to put a `z:' in front of each assign, so that it reads: z:assign b 9,0 You must also be _sure_ that your z: drive has the ASSIGN program file. Howie ------------ Category 3, Topic 18 Message 15 Fri Jul 29, 1994 THE.OUTLAW at 05:44 EDT Howie, Ok, I sorta figured on that (z:assign b 9,0),but putting ASSIGN into the Z drive, how is that done? I saw the line in the autoexec that read: z:getram z:ramdisk <- after this place z:assign? Thanks :> ------------ Category 3, Topic 18 Message 16 Sat Jul 30, 1994 H.HERMAN1 at 06:16 EDT Cam, In direct mode, you would enter: rsave assign ASSIGN will be saved to the default, or z: drive. For this command only, you will want to write to a 1571 drive, or possibly 1571 emulation partition. Do not try an rsave to a 1581. I do not know why, but it does not always work. Once assign is on disk, test it out in direct mode, by trying things like: z:assign t 8,0 Then do a dir t: You would do this to make sure that the file transferrred to disk correctly. If all works well, then add the prefix `z:' to the assign commands in the autoexec. That should do it! Howie ------------ Category 3, Topic 18 Message 17 Thu Aug 18, 1994 THE.OUTLAW at 22:29 EDT Howie, I still haven't gotten to adding ASSIGN to the ramdisk. I have come up with a new problem - after the 2nd READY I get: There seems to be a problem.... rebooting... echo is off ready I can't load CS-DOS from anything at the moment :/ any ideas? ------------ Category 3, Topic 18 Message 18 Fri Aug 19, 1994 THE.OUTLAW at 16:55 EDT Howie! I'm now out of idiot mode... (forgot to put REU in) that explains the the problem echo off mess... Anyway, after following you instructions with RSAVE, I now have NO syntax errors in the loading proccess of CS-DOS. I did decide to check out the 2 digit partion anyway and did find out CS-DOS doesn't recognise them, at least by way of autoexec. Thanks for all the help! :> ------------ Category 3, Topic 18 Message 19 Fri Aug 19, 1994 H.HERMAN1 at 19:53 EDT Cam, ha! >There seems to be a problem.... rebooting... The autoexec ran fine, saw a fatal configuration, and rebooted the computer, as it is supposed to. :) I am sure happy to hear that CS/DOS is *now* booting itself without a syntax error message. I *knew* it would, once set up properly. As to using ASSIGNed drives, those with partitions higher than zero will work with "simple" structure commands, like directories, and such. ARC, and LHA, etc., do not correctly recognize them. I quess we can add the autoexec to this list. :) Howie ------------ Category 3, Topic 18 Message 20 Sat Aug 20, 1994 C128.JBEE at 01:01 EDT I just wanted you to know I am currently working on CS-DOS. Once I get it to recompile correctly for me I will start on some of the fixes. ------------ Category 3, Topic 18 Message 21 Sat Aug 20, 1994 D.TUOMI [Doctor] at 05:16 EDT The copies of CS-DOS you sent me JBEE perform the same as my original copies. They still have a tendency to lock up with CMD native mode partitions. Both with and without REU engaged. Doc. ------------ Category 3, Topic 18 Message 22 Mon Aug 22, 1994 H.HERMAN1 at 08:21 EDT JBEE, Having CS/DOS utilties recognize ASSIGNed drives (like 16,20) would be a nice new feature to include. Also, CMD drive paths! :) Doctor, I run CS/DOS with CMD native partitions (on RAMLink), with no problems. It does boot first from a 1581 partition. Things were set up this way, once I decided it was faster to archive RL with MCOPY. CS/DOS should boot just as well from any native partition, however. If cs/dos is locking up you might try clearly ASSIGNing your drives in autoexec, and then using drive designators with its commands. Things like: LHA -s i:newfile a:title c:file1 b:file2 i:file3 ^ ^ ^ ^ ^ Also, check that you have defined REU space usage properly. Howie ------------ Category 3, Topic 18 Message 23 Mon Aug 22, 1994 C128.JBEE at 18:57 EDT Howie, Once I have the C compiler working on my machine properly and have done a successful compile, I will be taking all the bugs and suggestions in this topic and use them to update the newer version. ------------ Category 3, Topic 18 Message 24 Thu Sep 22, 1994 R.HARRIS1 [Randy Harris] at 01:12 EDT Glad to hear there is further development being done on CS-DOS!! I'm am a new user of CS-DOS, and I LOVE IT! It took awhile to figure things out, but once I did, I realize it one of the BEST tools available for the 128! Randy :) ------------ 3 ?