8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / RTCM-MGS.SFX / 02RTCM < prev next >

Wrap

Text File | 2019-04-13 | 33.5 KB | 794 lines

Ed: Wow! You should be extremely happy with it!!! I don't think it can get much better than this!! Congrats! ------------ Category 8, Topic 18 Message 76 Wed Feb 22, 1995 C128.JBEE at 13:34 EST reply 18 I will create a private library for registered owners so they can download it easily. ------------ Category 8, Topic 18 Message 77 Wed Feb 22, 1995 E.GBELL [e.g.bell] at 18:23 EST Keep in mind that this is for version 3.00. Version 2.04 does not have the capabilities to run this, even if I could assemble it for that version. There are a few things that still need tested for the different variations available (all that are in the original program) and for the special file types (relative), that I did not test myself. Still, I used it to create the package I uploaded. :) ------------ Category 8, Topic 18 Message 78 Thu Feb 23, 1995 THE.OUTLAW at 22:50 EST Ed, i noticed something odd lately.. it started 1st with ver 2.04. I switched from using the RS-232 to the swiftlink and then back again but the RS-232 doesn't seem to be recognised. I keep both interfaces hooked up because the RSCARDS FE doesn't work with the SL. ------------ Category 8, Topic 18 Message 79 Fri Feb 24, 1995 E.GBELL [e.g.bell] at 18:23 EST cam: Thanks for posting this here. I think the answer will help others. The SwiftLink and user port NMI handlers are separate... totally. RTCM senses the swiftlink and loads that device handler. From that point, there is no further expectation from the user port. I opted to go this route because I'm a firm believer that 'one size fits all' doesn't do any size true justice. Each handler uses a jump table which is how the main program can shrug off the two device handlers. So, if you are going t leave the sl plugged in but use the user port modem, try this.... make a custom boot program, removing the follwing lines.... 145 dcd=.:poke 56833,.:poke 56834,170:rem check swiftlink 150 if peek(56834)=170 then f$="swift.obj":dcd=64:else f$="rtc.obj" Replace these lines with a single line that looks like this: 145 dcd=.:f$="rtc.obj" If you have problems with your modem always seeing carrier, change the 'dcd' setting to 'dcd=16'. The above should get you back up and running. Thanks for reposting the question here! ------------ Category 8, Topic 18 Message 80 Thu Mar 09, 1995 R.KIRK7 [Dick] at 19:16 EST Is RTCM V3.0 now available to us registered owners and will we be sent a copy soon or where is it available? ------------ Category 8, Topic 18 Message 81 Thu Mar 09, 1995 C128.JBEE at 23:29 EST For registered GEnie users, it will be available in a new library. I am still testing it before releasing it and there are still a few tiny things to work out on it. ------------ Category 8, Topic 18 Message 82 Fri Mar 10, 1995 E.GBELL [e.g.bell] at 06:03 EST Dick: I am also working on improving some things with it. For instance, the archiver overlay, the one that allows you to create archives, had to have some work done on it to allow it to archive relative files. That was accomplished, but now I have to tweak the old archive dissolving overlay to get it to dissolve REL files. The new FingerTip overlay needs some work to make the operation more friendly and I'm going to try to get the record sizes more efficient. 3.00 is a LOT of changes that need to be tested before release. The down side is the delay for release to registered users. The upside is that there is a lot of new stuff that I think you'll like. This is the largest collection of changes in quite awhile. Some of them came about directly as a result of your suggestions and those of others.... the scrollback buffer is one example, the file selection routines are another, the alternate drive, etc. I also added code to address the other concern with the init string not getting sent to modems that have the carrier bit ON all the time until the init string is sent, etc. I don't think I forgot anyone with this update. ------------ Category 8, Topic 18 Message 83 Wed Mar 15, 1995 R.KIRK7 [Dick] at 21:33 EST Looking forward to the new version of RTCM. I thought I had seen something about it being completed. The changes sound great. ------------ Category 8, Topic 18 Message 84 Wed Mar 15, 1995 N.ONEIL [Nate] at 22:46 EST I have an RTCM2.04 problem using Autosave with my 1764 (using RAMDOS). In either Buffer mode or Editor mode, the first autosave to my REU, whether by Purge or an Autosave, appears to save to the REU OK but that first file can not be reloaded into the buffer (70,No Channel,xx,xx). Files autosaved after the first can be reloaded,however. Using the Copy Overlay, the 0AutoBuffer file appears to be copied with the others. Checking the disk, it appears that when RTCM saves 0AuutoSave to the REU it either does not actually save the file or else saves it without pointers The file entry is written properly to the directory with the proper name (0AutoSave) and an appropriate length. The data block pointer, however, points to a blank block. Is this a hardware problem with my flat 128, a corruption of my RTCM program, or an RTCM bug? BTW, it was not a fluke. The problem persists. *lis ------------ Category 8, Topic 18 Message 85 Fri Mar 17, 1995 E.GBELL [e.g.bell] at 06:02 EST Nate: NO> appears to save to the REU OK but that first file can not be NO> reloaded into the buffer (70,No Channel,xx,xx) That error message means that you have (or your drive thinks you have) too many channels open. In RTCM, that cannot happen because even the command channel is opened only on an 'as needed' basis. I am going to check things out this weekend. I do have a copy of 2.04 to test with and an REU. R.KIRK7 would be a good person to consult on this as well, at least to confirm that it does or doesn't happen to him. O, wait,he uses DMA saves. I'll check it out myself either tonight or tomorrow and let you know what I find out. BTW, just for general info, the copier in version 3.00 will copy your REU whether you used RAMDOS or DMA type saves, for R.KIRK and anyone else who might find that useful. Also supports buffer saves from its own menu. I *may* put in a copier for REL files since I'm working on code now that does that for another overlay. It would probably not be that hard to duplicate in the copier overlay. :) ------------ Category 8, Topic 18 Message 86 Thu Mar 23, 1995 E.GBELL [e.g.bell] at 07:58 EST Nate: I just tested your problem w/RTCM 2.04 and RAMDOS, and I duplicated your results. Can't explain it cuz it shouldn't be happening. On the upside, I just tested 3.00 too, and it does not suffer from the problem. Whatever the problem was has been corrected in the most recent version so I'm not going to worry about this. Would like to know what is causing it, but guess I'll never find out. :( So sorry for the inconvenience in 2.04, but 3.00 will make it worth it for you. There are at least 2 brand new overlays including Archiver, which will allow you to make your own archives using all of RTCM's normal interface stuff, and the dissolver has been tweaked to allow you to extract files from archives by pointing and clicking on them to get exactly what you want, there is a brand new overlay called FingerTip, which is a mini-data base where you can store names, addresses, phone numbers and a couple comments about up to 255 people per FingerTip file. You can print this info in any number of ways and even dial the number if you want without ever touching the phone. I am just about finished tweaking the overlays and they will be back up for some more testing, but as I said, the problem you found is a problem that has been corrected. :) ------------ Category 8, Topic 18 Message 87 Thu Mar 23, 1995 N.ONEIL [Nate] at 21:43 EST Wow! V3.0 sounds terrific. Powerful functions. Thanks for researching my Autosave problem. No inconvenience. No problem getting around it. Nate ------------ Category 8, Topic 18 Message 90 Sun Mar 26, 1995 E.GBELL [e.g.bell] at 13:28 EST I just uploaded a brand new overlay for version 3.00. This is one I have been intending to write for awhile. It is little, but very useful I think. It is called TagThief. With it, you can extract all of the taglines from your buffer automatically, skipping duplicates. When done you can save them to a file, or print them if you like. THE.OUTLAWs Taglines category has become a favorite around our house. Cathy and I take them to work for the enjoyment of others... I use them on my PC as a marquee... change them regularly thanks to the supply here. Anyway, TagThief makes getting them a lot easier, which means on those rare occasions when I see some, I can grab them and share them with everyone here with virtually no pain. The archive I uploaded includes a 59+K buffer of messages, and a demo file of taglines extracted in about 10 seconds from this file. It is kind of fun! :) To date, it is the smallest overlay. Just to show you what it can do, I just ran it on my buffer (the one since logging on), and here is what I got as output... ...Attila the Nun - a simple girl pledged to a life of brutality. ...Alimony is the take from the mistake. ...Change is inevitable...except from the pop machine. ...I spent all my money on a FAX machine. Now I can only FAX collect. ...Women and TV - don't try to understand them, just try to enjoy them. ...Capital Punishment means never having to say, "YOU AGAIN?" ...I'm sorry, Officer. I didn't know these freeways had no-smoking lanes. ...Ignorance is curable. Stupidity is permanent. ..."Meoowww!"...SPLAT!..."Ruuuuufff!"...SPLAT! (Raining cats and dogs) ...If at first they don't succeed...VOTE THEM OUT! You might recognize the above from Frank's messages in THE.OUTLAWs category. I didn't repeat all of them, but you get the point.... TagThief can cull them from your buffer and save them by themselves. You won't have to do it manually anymore. And it does not touch your buffer so you don't even lose anything. Dunno when 3.00 is going to be released to registered users, but I think you will like this little overlay when it is. :) ------------ Category 8, Topic 18 Message 91 Sun Mar 26, 1995 CBM-BANDIT at 13:48 EST Way cool Ed! :> ------------ Category 8, Topic 18 Message 92 Sun Mar 26, 1995 C128-QT.PIE at 15:13 EST Ed, Wow, what a terrific idea! <g> ------------ Category 8, Topic 18 Message 93 Sun Mar 26, 1995 N.ONEIL [Nate] at 22:07 EST Looks good! Holding my breath waiting for 3.0. ------------ Category 8, Topic 18 Message 94 Tue Apr 11, 1995 L.VICTORY [LURCH] at 08:59 EDT Help w/rtcm128 2.02(I think) I d/l it here a month or so ago and have had no luck at all with the scripts. Configured dflt.mysetup and scrp.mailconfbb to my needs and all I get is connect 2400 then f'f. Also, since I have sent my registration and check in, how do I get version 3.0? Hurry up, I want to see if my 'greeter' works ;) Lurch ------------ Category 8, Topic 18 Message 95 Tue Apr 11, 1995 C128.JBEE at 12:41 EDT You should be using V2.04. I am still testing V3.0 before releasing it because I have had some problems with the archives. Once I have archives I can upload I will create a new private library from which people can download the latest version. People not on GEnie will get a letter. People on GEnie will get an e-mail. :) ------------ Category 8, Topic 18 Message 96 Wed Apr 12, 1995 CBM-MARK at 20:20 EDT Sounds as if the 'hhhhh' isn't being sent once CONNECT 2400 is made. You do have that entered in the script, right? Are you able to connect to GEnie manually? 'atdt<phone#>' from keyboard? ~~Mark~~ ------------ Category 8, Topic 18 Message 97 Thu Apr 13, 1995 E.GBELL [e.g.bell] at 06:15 EDT Lurch: LV> Configured dflt.mysetup and scrp.mailconfbb to my needs and all LV> I get is connect 2400 then f'f I agree with Mark's assessment here. It sounds like you are not sending the 'hhhhh'. I would make sure that is being done, and I would also try one other thing that might be affecting this.... when RTCMaster connects, it starts the music if you have that enabled, but this is only after it detects carrier. There is a delay setting that is counted down after the number is dialed before carrier is tested. If this setting is too high, you will end up waiting too long to sense carrier, which will delay the sending of the 'hhhhh' too long....iow, you send it but GEnie gets to a point where it won't accept it any more. So after you make sure your 'hhhhh' is in the script, try reducing the carrier delay... use the defaults overlay under Modem to change this setting. BTW, I made a minor change to AutoLog some time back for the 'hhhhh' to shorten it in ScriptMaker entry. You can enter ALT-*, which shows up as a reverse '*' character on the screen. I did this to make room for the 'begin script at' stuff in the telephone number. The script positions (in the record) are limited and I had to do this for GEnie numbers to enable the feature. Anyway, if I wrote your script, it should be sending the 'hhhhh' but you should check it anyway. If it is being sent, check the delay. If you can't tweak that, upload the script and I'll look at it. Just make sure you remove your password/id (move it into your dflt.mysetup) before you do that. That is the best practice anyway. ------------ Category 8, Topic 18 Message 98 Thu Apr 13, 1995 CBM-MARK at 22:09 EDT Ed, ScriptMaker uses the Control key now instead of the ALT key. So to shorten the 'hhhhh', it would be CTRL-* ;) ~~Mark~~ ------------ Category 8, Topic 18 Message 99 Fri Apr 14, 1995 E.GBELL [e.g.bell] at 19:01 EDT Ok! I couldn't remember which it was Mark... :) The ones I made originally were good enough for me that I haven't made one in a LONG time! BTW, I know I didn't say so, but the TagThief overlay I just uploaded was to address the problem you reported. I did the file you sent me w/o problems.... also increased the TagThief tagline buffer by another 4K, bringing it to 28K. I don't know why you got what you got but I took a couple extra steps for control.... manually forcing a null termination and closer scrutiny of the buffer pointers. Dunno why your file had problems, but this one does ok! :) ------------ Category 8, Topic 18 Message 100 Sat Apr 15, 1995 N.ONEIL [Nate] at 22:56 EDT Looking for a way, if there is one, to load and run RTCM 2.04 without initializing my 1764 REU and thus destroying the data therein. I use EZ.BOOT to load and run RTCM but can't see a way to prevent the REU from being initialized. Nate ------------ Category 8, Topic 18 Message 101 Sun Apr 16, 1995 E.GBELL [e.g.bell] at 01:21 EDT Nate: There is a way to do that... You have to remove the lines in ez.boot that are dynamically loading the keyboard to answer the REU prompts. 175 io%=.:rem io%=asc("r"):rem <r>amdos <d>ma <0> no reu 180 if io%>. then begin 185 : poke 842,io%:poke 843,13 190 : poke 844,55-((asc("y")-55)*(io%=82)) 195 : poke 845,13:poke 208,4 200 bend Your line numbers may be different, but these are the pertinent lines. If you remove those pokes to 842, 843, 844, and 845, or even just the one to 208, you will prevent the keyboard from being loaded with replies to the REU prompts. That way, you will have to answer the prompts yourself, and you will see that one of them is whether you want to initialize the REU. You could also just set 'io%=.' in line 175 which will cause the whole begin/bend block to be ignored. That is the way I originally intended this to be done. I think you'll find tho that however you do it, it will be quite easy. :) ------------ Category 8, Topic 18 Message 102 Sun Apr 16, 1995 CBM-MARK at 01:39 EDT Ed, I have my buffer size set to 150. would that have made a difference with the problem I had with TagThief by chance? ~~Mark~~ ------------ Category 8, Topic 18 Message 103 Sun Apr 16, 1995 E.GBELL [e.g.bell] at 12:28 EDT I don't think so Mark. That doesn't affect or control buffer loads or even saves directly. All it affects is buffering data when you are online or writing information through normal buffering operations. This probably sounds confusing.... if you load a buffer and it is bigger than your settings, it effectively overrides the settings for THAT buffer... that buffer won't auto save until it hits the max at $FE00 or $FD00, wherever it is. After an auto-save, you are back at ground zero. Make sense? There is a critical point when that setting will trigger an autosave. Once passed, the trigger cannot be set because I test for '=' and not '>=' (pretty sure about that. :) Anyway, the TagThief buffer is not in your capture buffer. It is in high RAM 0.... the buffer it is builing FROM is in your capture buffer. The only way to get a TagThief file into your buffer is to write it to disk then load it. I really think that what caused the problem you found is one of two things.... either I did not test for buffer overflow in the correct place OR the null was not located as the buffer was built. To address what you experienced, I 1] made a closer check of the pointers each time the buffer is written, 2] lowered the test value by 1 page (because data is written to the buffer a line at a time instead of a character at a time), and 3] forced a zero at the end of each installed tagline. Each subsequent tagline starts writing over this zero, but adding it means there is always one there. I don't think you can overload TagThief again. The only thing 'bad' that could happen now is for you to try to 'rob' a buffer with more than 28K of taglines. Since TagThief strips duplicates, this is unlikely, but of course, I would have thought that 24K was more than would ever be needed. Then again, in defense of that notion, I checked the buffer after the burp and it was within that 24K limit.... so one of the above steps corrected the problem and the others just make sure nothing else (that I can anticipate) will cause another problem. I'm glad you found it. The overlay itself is just a little nobrainer... hardest thing about it was the duplication checking. But I'm comfortable that it is ok now. ------------ Category 8, Topic 18 Message 104 Sun Apr 16, 1995 CBM-MARK at 23:34 EDT ED, you say the TagThief overlay is just a little nobrainer, but it sure is a neat little overlay in how slick it works! ;D Thanks for explaining how TagThief and the capture buffer are related ;) I didn't know any of that. I thought it was all done in the capture buffer. ~~Mark~~ ------------ Category 8, Topic 18 Message 105 Mon Apr 17, 1995 C128.JBEE at 03:27 EDT I am using a C-128D with: EGADS on ROM RamLink as device #10 DACC Partition #31 (REU 512k) 1581 Partition #01 1581 Partition #02 Nat Partition #03 FD-4000 as device #08 SwiftLink w/Courier 9600 V32 Running V3.00 from Partition #02, using the "BOOT" program, I get as far as the main screen and then it stops with: ?undef'd statement error in 325 2 3 ready [cursor] ------------ Category 8, Topic 18 Message 106 Mon Apr 17, 1995 E.GBELL [e.g.bell] at 06:09 EDT John: Is this with the version I just uploaded Friday? Take a look at this: 320 if rl%>. then begin 325 : open15,rl%,15:print#15,"t-rb" 330 : for x=. to 3:get#15,a$:next:bank 15 335 : get#15,a$:ah=asc(a$) 340 : get#15,a$:am=asc(a$) 345 : get#15,a$:as=asc(a$) 350 : get#15,a$:a=asc(a$):ah=ah or -128*(a>.) 355 : 360 : poke 56335,peek(56335) and 127 365 : poke 56331,ah 370 : poke 56330,am 375 : poke 56329,as 380 : poke 56328,0:close15:poke 186,dv 385 bend This routine is the one that sets the time from the RL clock. Try disabling it. Change line 320 to something like '320 goto 395' to see if it is that routine. Don't see how it could be but this routine DOES read the RamLink command channel for the clock setting. If that doesn't work, we'll have to look somewhere else for it. BTW, I am running w/EGads in ROM, my v3.00 is also in partition 2, tho I don't keep my REU installed. That will be the next thing we should look at if it is not the RL clock routine. ------------ Category 8, Topic 18 Message 107 Mon Apr 17, 1995 C128.JBEE at 09:20 EDT Ed, Yes, this is the last version you uploaded in the big .arc file. I will give that a shot. I understand the BASIC code, I do not know why it does not work, yet :) ------------ Category 8, Topic 18 Message 108 Mon Apr 17, 1995 C128.JBEE at 09:36 EDT I am now signed on with V3.00. Changing line 320 to "goto 395" did the trick by skipping over the clock code. ------------ Category 8, Topic 18 Message 109 Mon Apr 17, 1995 C128.JBEE at 09:44 EDT When setting the drive parameters with C=U. Is "drive unit" suppose to be "drive number"? ------------ Category 8, Topic 18 Message 110 Mon Apr 17, 1995 E.GBELL [e.g.bell] at 18:45 EDT John: JB> now signed on with V3.00. Changing line 320 to "goto 395" did JB> the trick b skipping over the clock code Ok.... then I'm going to give you a SYS address to insert before that block of code to see if it allows the clock code to work ok.... Try adding a line 'sys 2822' before that block of clock code and restore the original line. This call disables the NMIs. I changed it to after the clock code, but that might have been unwise. I thought I saw that it would not be useful before it. Bet it should not have been removed. :( JB> When setting the drive parameters with C=U. Is "drive unit" JB> suppose to be "drive number" If I understand what you mean by number, yes. For example, if your 1581 is drive 8, you would enter 8 for the unit number. Device number is or can be considered 'partition number' if that makes better sense. Consider the device number the number that would replace the '0:' in a line like 'load "0:filename",8,1. In that line, the '0' is the device and the '8' is the unit. You have probably seen things referred to like that in some of the older manuals. It was the only thing I could think of that would cover CMD device users and non-CMD device users. Related, you will note that all of the overlays that have disk related functions now provide the option to set the device numbers right from the overlay menus. In addition, you will only have to set those devices that the overlay actually uses. In other words, the copier allows you to set the source and target units, and now you don't also have to set the printer, system, or alternate drive units numbers as before. FingerTip only uses the target unit so that is the only device you have to set if you opt to set devices from within that overlay. And while I'm talking about the disk stuff, the copier overlay has had some heavy duty reworking.... now you can copy DMA type buffers to your disk with this overlay.... and if you have a RAMLINK, you can use it to lock and unlock files. I may work in the JD'd CBM devices later tho it was more work than I wanted to do this time around. This was a pretty big rewrite. All told, 3.00 is a BIG upgrade... three or four new overlays, including the Archiver, and a LOT of changes to the other ones. I'm kind of pleased with this one.... O, one more thing.... Mark found a bug that has been in the translation tables probably forever.... it stripped certain special characters when saving buffers as true ascii. PETSCII files would never have been affected. The fix was a slight change or two to HIBLOCK, which is also in that latest upload. ------------ Category 8, Topic 18 Message 111 Tue Apr 18, 1995 C128.JBEE at 00:39 EDT Ed, Will this code work if I do not have a time clock :D I just checked my RL manual and there is no mention of setting the clock and I tried setting the clock using BASIC and it is a no-go. I have an early, revised RamLink (Rev G) with a newer RamCard but it is likely there is no clock. I thought I had one because my GEOS time is always set but I have always had either a HD or FD-4000 with a time clock in it. So, as far as I can tell I do not have a time clock in my RL :P Maybe a slight rewrite of the BASIC code with trapping for RamLinks without a clock? ------------ Category 8, Topic 18 Message 112 Tue Apr 18, 1995 C128.JBEE at 00:43 EDT I save my buffers in pure ASCII and never noticed the translation bug! ------------ Category 8, Topic 18 Message 113 Tue Apr 18, 1995 E.GBELL [e.g.bell] at 05:56 EDT Hmmmmmm! I think you just provided the piece of the puzzle that has eluded me for awhile. The code in question works ok for me, tho I never seem to be able to keep my clock set. But a RL w/o the clock.... that might just be the thing that caused you to have problems with that bit of code. My code assumes that if you have a RamLink, you have a clock, and of course that is not necessarily true. I'm going to have to look at the code and see if the documentation needs amended. I am pretty sure that that is the only use the boot program makes of that RL% setting early in the boot program. If so, just a REM line after the setting would be enough..... 115 rl% = 16 : rem if you don't have a clock set rl% = . Yes, John... I just made a quick check and that seems to be the only place that RL% comes into play. An easier fix for you would be to just set RL% = . in line 115. That will do the same as the GOTO you added w/o making things unclear if you ever got a clock... more important for the boots in the package than on your disk. Anyway, I believe that solves why I don't have problems and you had them where you did. ------------ Category 8, Topic 18 Message 114 Tue Apr 18, 1995 C128.JBEE at 11:09 EDT I think the best way is to set it to the default (no clock) and let people change it if they have a clock. Assuming the above code works okay. That way the program runs without breaking for a smooth boot. I assume the period is the same as saying "0.0". ------------ Category 8, Topic 18 Message 115 Tue Apr 18, 1995 E.GBELL [e.g.bell] at 18:26 EDT JB> best way is to set it to the default (no clock) and let JB> people change it if they have a clock Actually, that is the way it is set up initially. I guess I just never explained it that way before. The only reason there was ever a test for RamLink in the boot program was to trigger the clock setting. If you go back to before you asked for that, you will see there was no such variable. It was an easy way for me to let users tell the boot program to use the clock in their RamLink. Never did find out if it works with the mouse too (the clock in the mouse) tho someone did ask me about that. If it is accessed the same, tho... if the commands are the same, it should. JB> the period is the same as saying "0.0". Maybe. Just a trick I picked up in my c64 programming days.... it was an often stated trick that supposedly executes slightly faster than saying '= 0'. I've always done it since then. I always tried to tweak as much speed as possible out of my programs... :) Never saw that suggested as to why. :) ------------ Category 8, Topic 18 Message 116 Tue Apr 18, 1995 CMD-DOUG at 22:26 EDT You might want to note that a RAMLink or FD that isn't equipped with a clock will return a standard DOS syntax error when any of the clock commands are sent. Thus, if the first byte you get back is an ASCII 3, there's no clock. ------------ Category 8, Topic 18 Message 117 Wed Apr 19, 1995 E.GBELL [e.g.bell] at 06:16 EDT Doug: That is interesting, but the program is crashing on the line that opens the command channel/sends the print#command channel line. 325 : open15,rl%,15:print#15,"t-rb" Nothing refers to that line as it is the first line in a begin/bend block. My point is, the command would have to be sent in order to have the RAMLINK see it and generate the syntax error. But it crashes at this line leaving no opportunity to trap the error. In addition, there are TRAPs active in the boot program that trap errors, print the DOS error message, and cease execution. All other DOS errors get trapped immediately.... that is why if you try to run the boot with a file missing, it stops with that message onscreen. Any idea why this error does not get caught by the BASIC 7.0 TRAP command? ------------ Category 8, Topic 18 Message 118 Wed Apr 19, 1995 CBM-MARK at 22:23 EDT eb> error does not get caught by the BASIC 7.0 TRAP command? It does if you have RL%=16 and *no* Ramlink ;> John, or anybody, have you had any problems using Ed's latest upload of v3.00? Maybe I've a bad download, but when booting it up I get some wierd things happening. First off, it looks like the TRON command is somehow turned on :/ I get [165][165], and some others too fast to read, shortly after running the boot program. Then later as the boot program is running I get [205][205][215][215]. When the modem string is sent, it's garbage. Whenever I return to the main screen from viewing the buffer, or returning from an overlay, one or two 7's are printed to the main screen. Pressing RETURN at anytime prints an 'I' to the screen. And...I can't dial out. :( I would definately say a bad download but the ARC file dissolved without any errors. Any ideas or suggestions, Ed? ~~Mark~~ ------------ Category 8, Topic 18 Message 119 Wed Apr 19, 1995 C128.JBEE at 23:08 EDT I am still testing V3.0. I will let you know the results :) ------------ Category 8, Topic 18 Message 120 Thu Apr 20, 1995 E.GBELL [e.g.bell] at 06:29 EDT Mark: It certainly does seem that the TRON command is in that boot somewhere or something is triggering it.... Here is something to try. swap your previous system files one at a time to see which one is causing the problem. The files I'm referring to are: rtcm.obj - main program code rtc.obj - non-swiftlink modem stuff, etc swift.obj - swiftlink stuff loblock - code living from $4000 to $5680 hiblock - just tables, etc. dflt.mysetup - lives from $5680 to $6000 autolog - from $6000 - ????? install.obj - installs REU and special char set then gets overwritten You might also look at the boot program to see if it does have a TRON command in there somewhere. I thought I copied/archived these files from my live disk (exc. for my dflt.mysetup file) into the archive... The main program file for this version has not changed at all since the first upload of it. The changes have all been to the overlays.... o, and that change to hiblock... o another thing you could do is load the main code in to ram 0 and a good copy into ram 1 and do a compare in the monitory (c 01300 03fff 11300)... you should not see any differences. bTW, the above command assumes that you bload the code. :) If it is necessary, I'll redo the archive and reupload it. But before I do that, is anyone else having problems with what I sent? If I do it, I'll just upload the main files first and go from there. I think I'll dig up the archive too (can't recall which disk it is on) and dissolve and test it here. One last thing, just as precaution... John... what did you use to dissolve it, and Mark, what did you use. I want to know if it is a problem with my dissolver. :) ------------ Category 8, Topic 18 Message 121 Thu Apr 20, 1995 C128.JBEE at 15:47 EDT I used CS-DOS/ARC128 V1.5. ------------ Category 8, Topic 18 Message 122 Thu Apr 20, 1995 E.GBELL [e.g.bell] at 19:05 EDT Mark: I would suggest two things.... first undo it with cS-DOS to see if that gets it correctly. If so, try it again w/RTcm (if that is what you used the first time) to see if that does it correctly. If so, go figure. If not, I might have some work to do. :( ------------ Category 8, Topic 18 Message 123 Thu Apr 20, 1995 CBM-MARK at 23:13 EDT Ed, I used the Xarchive overlay to dissolve it. I'll try CS-DOS now and let you know. For your sake I hope that's not it :( I did look at the boot program and there is no TRON command anywhere :) ------------ Category 8, Topic 18 Message 124 Fri Apr 21, 1995 CBM-MARK at 00:06 EDT Ed, you're not going to like this! CS-DOS dissolved the V3.00 file just fine. In otherwords RTCM V3 works Ok. Using the Xarchive overlay results in the problems I mentioned before :( Now what about the Arcangel overlay? I'm going to try that one now on that latest RTCM arc. ------------ Category 8, Topic 18 Message 125 Fri Apr 21, 1995 CBM-MARK at 00:31 EDT Ed, I'm back from trying Arcangel on the V3 arc file. Ah, I had the same problem as I mentione once before about Arcangel. It abortes before the download is complete. I tried it twice and the abort [Bogus error] happened at the same place each time. Right after the "rtcm.obj" file was downloaded- t