8bitfiles.net/archives

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

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

Wrap

Text File | 2019-04-13 | 15.8 KB | 335 lines

dissolved to disk. You may want to give this one a try for yourself. Though I seem to remember you didn't have any problem with Arcangel the last time I mentioned this happened to me :/ Oh, the version of arcangel I used this time is from the latest version of RTCM. If it matters, I using the full 8 pages for arcangel and downloading- dissolving to my drive #10, a 1571. ~~Mark~~ ------------ Category 8, Topic 18 Message 126 Fri Apr 21, 1995 CBM-MARK at 00:46 EDT Just for the heck of it, I took what files Acrangel *did* download-dissolve and copied with them the rest of the files that I need to run RTCM onto a disk and tried running it. Looks like maybe Arcangel may not have the same problem as the Xarchive overlay and the V3 arc file. ie- TRON command not evident and no garbage to screen. Still wonder why Arcangel won't work for me :/ Noticed something else... the font doesn't seem to be installed. I left the BOOT prg loading the "font.roman" char set but what I see right now is the std CBM char set. I'm sure that I saw the char set change onscreen when the BOOT prg first started running to roman. It's not now though. ~~Mark~~ ;) ------------ Category 8, Topic 18 Message 127 Fri Apr 21, 1995 CMD-DOUG at 01:21 EDT Ed: I'm almost suspicious that the trap command itself might be causing the lockup when an unacceptable command is detected by RAMLink. Just sending the clock command should not cause a lockup on a non-RTC-equipped unit, and I can confirm that it does not on the one I have at the office which is clockless. The early units didn't know how to handle that command at at all, so the string would be looked upon just as if you sent any garbage string to the unit - DOS Syntax Error. What I can't be sure of is if TRAP is somehow interrupting things when RAMLink is off doing those under-the-covers type things where it doesn't like being interrupted. I'll have to check further to see if this is the case or not. I'd also be curious to hear from JBEE what happens if a straight program without TRAP is used to send this command to his particular unit... ------------ Category 8, Topic 18 Message 128 Fri Apr 21, 1995 E.GBELL [e.g.bell] at 06:10 EDT Mark: MD> CS-DOS dissolved the V3.00 file just fine. In otherwords RTCM MD> V3 works Ok Ok! That is why I suggested it. I didn't have anything I suspected... just that yours didn't work and John's did.... the ironic thing is that RTCM is using cS-DOS routines. I'll have to try the test here this weekend. :( MD> [Bogus error] happened at the same place each time. Right MD> after the "rtcm.obj" file was downloaded- dissolved to disk. MD> You may want to give this one a try for yourself I will. The file I tested on before was not this one... it was the one you had trouble with before. I half hope there is something to this. If there is it gives at least some small clue to WHERE things are going awry. The trouble with this one is twofold tho. First, ArcAngel uses ARC code from the old c64 versions for its dissolve. But I don't think that is what is the problem here. What you have described all along is a classic protocol timeout. ArcAngel uses plain vanilla Xmodem cRC. The reason I did that was because I felt that pulling in 1k of archived data, dissolving it, and then writing however much that was to disk would certainly cause a protocol timeout. If you ever wondered why I didn't use Ymodem or X1k, that is it. But you know ArcAngle will dissolve files offline too Mark. I'm pretty sure about that.... No, I take that back... that was the BellTerm version that did that. :) Doug: DC> hear from JBEE what happens if a straight program without TRAP DC> is used to send this command to his particular unit Good idea... John, wanna give this a try? Remove the TRAP command from the boot and run the boot program as originally released and see if it crashes you. If it doesn't, we can add a TRAP command with no line number just before that code because the TRAP is only in there to detect file not found errors and abort the boot if they occur. It can be turned off at that stage of the process because all files are loaded.... 140 trap 470 The above is the line we are talking about. Actually, I think LOBLOCK is loaded after this point, but it is done from the ML section, and the reason is that LOBLOCK loads over top of the boot program, which is why it HAD to be done after entry to the main program. I think Doug's idea is a good one. I also suspect the SYS I gave you earlier may do the same thing. Mark: BTW, on the upside... I'd rather have the problem be in the dissolve routines, which I understand a little better than I do the archive routines The fact that cS-DOS dissolves it fine gives the ARCHIVER overlay a clean bill of health in this because I used RTCMaster to archive the package. The real killer is that I redid ALL of the dissolver routines when we were working on that REL thing. ------------ Category 8, Topic 18 Message 129 Fri Apr 21, 1995 C128.JBEE at 12:44 EDT I will give it a go and let you know. ------------ Category 8, Topic 18 Message 130 Fri Apr 21, 1995 E.GBELL [e.g.bell] at 18:57 EDT Mark: A couple of things.... First, and this is something you have consistently proven you are the absolute best at... I think you have found something that was right under my nose which, while I have to test, I'm sure is a 'bug'.... the font thing you mentioned. RTCM 3.00 installs the font, as it has since this was introduced, as the first step in the boot program. However, version 3.00 introduced the scrollback buffer, which is in the VDC.... and in order to detect it, RTCM runs a destructive test on the VDC.... this is done late in the boot program..... I bet it is blowing out the new font. The kicker is that I have often THOUGHT I noticed a change but always chalked it up to something else.... until you mentioned this it never dawned on me, or even occurred to me when I was doing the VDC test code. If you want to try something, move the code that installs the font to after the code that does the installation of that stuff, which is at 6912. In practical terms, the line that must occur before the font installation happens, IF I'm correct about this, is.... 205 sys 6912,dv,13:fast:rem ramdos dvc 13 I can do it if you can wait, but I figure I'm going to be busy this weekend finding out what is happening when the archive for rtcm3.00 is dissolved by rtcm3.00 bTW, I just downloaded that archive with ArcAngel without so much as 1 error. Still have to load and run it tho, but I kind of think this is a problem with something other than the overlay.... Will let you know when I know more about that. Boy... I don't know how I missed that font thing when I was doing the coding... I've been using 3.00 longer than anyone and should have seen it.... you can tell where my mind isn't! ------------ Category 8, Topic 18 Message 131 Fri Apr 21, 1995 CBM-MARK at 22:31 EDT Ed, normally the first thing I do with a 'new' boot program is change the font to be loaded to "font.easy read". This time I didn't and while I was online I noticed that this font sure didn't look like the Roman to me ;> With Arcangel, I'll have to try it again, but I'm sure everything was moving right along so I don't see why I there would be a timeout involved. Also, I'm writing the file a 1581 not a much slower 1541 where I could see how a timeout might occur. I'ld try it again using my REU, for a faster file write but the darn thing isn't working :( ~~Mark~~ ------------ Category 8, Topic 18 Message 132 Fri Apr 21, 1995 CBM-MARK at 23:07 EDT Ed, I tried Arcangel one more time on that file and this time I got much farther before things went wrong. As far as the autolog overlay. Thinking some more on this I'm sure I forgot to mention a couple of things. One is it's the terminal that cancels the download, not GEnie. Another is just as things go wrong and the download is canceled, I press 'any key' to get off the overlay menu and back to the main screen. Soon as I get the main screen back I see what appears to be part of the file had been transmitted (looks like a lot of gibberish ;) which is immediately followed by GEnie's normal download status message. This last time Genie said I had 7 frames retransmitted and 1 timeout. My question now is, could this be something *I'm* doing? When the screen blanks, I use the CRSR up/down key to bring it back so I can keep an eye on things. *IF* I had hit the CRSR left/right key by mistake, would this somehow cause the download to abort? I did think of this last night and purposely pressed the BREAK key early in the 2nd trial but nothing happened that time :/ Let's see, in the last 7 or so times I've used Arcangel I've had 0 success :( Which is weird since the very first V3.00 files I tested I don't remember *any* problems with Arcangel. Soon as I get a chance I'll try V2.04 and the first set of V3.00 and see if things work. ~~Mark~~ ------------ Category 8, Topic 18 Message 133 Fri Apr 21, 1995 CBM-MARK at 23:33 EDT Ed, I just tried using the original set of V3.00 files and Arcangel to download that file again. Guess maybe it was with v.204 I had success before. No good this time either. Same as last time, abort after the autolog overlay was dissolved. Garbage to the screen again too just before GEnie's dowload status is displayed. 7 frames retransmitted and 1 timeout again, also. Found out it doesn't seem to matter what key I press to get the screen display back though so that doesn't seem to be a factor. I'm all out of things to try :< ~~Mark~~ ------------ Category 8, Topic 18 Message 134 Sat Apr 22, 1995 E.GBELL [e.g.bell] at 06:45 EDT Mark: I dunno.... I have to change it anyway. When I changed the menu screens, I missed the 'File Blocks' counter. It is now 2 lines too low. What I *might* do is put in abend codes like I did for the Ymodem overlay. Means nothing to anyone using the overlay, but it helps me to identifiy what part of the code is failing. The key pressed to bring the screen back is not a problem. I use the crsr-down key myself. Just about any printing key should work. I didn't change any pertinent code in ARCANGEL from 2.04 to 3.00. All that was changed in the overlays was the directory selection routines and the menu screens, where device selection was added. I have been trying to get some kind of standardization as far as keys selected for various functions too.... (i.e. S to select drives). Now for some more on the problem..... what you are describing is not a problem with the dissolve routines. It is strictly the protocol routine where the breakdown is occurring. Perhaps we need to go back a bit further in what you are doing... what protocol are you selecting? You should always be selecting option 1 for Xmodem from GEnie's menu. The garbage on the screen is not surprising. GEnie doesn't respond very quickly to a terminal's request to abort. Therefore, the terminal exits the transfer and GEnie continues with it... that is what you see on your screen. When you see that stuff (in whatever program you are using) hold CTRL-X until GEnie aborts. This is a protocol CANCEL and eventually, GEnie will acknowledge it and give up. I have (I believe) isolated the problem with the files dissolved with XArchive. First, I loaded each file and verified it against my personal copy of the file. The BASIC boot was just loaded and verified. All others were loaded into separate banks and compared via the ML monitor. bad news was that they were ALL byte for byte the same. However, I was comparing the files in the addresses where they are supposed to be. A later check revealed that virtually all of the files are bigger than the originals, which kind of points me to a flush routine problem. The last flush, in particular. It is apparently flushing more than it should. I'm hoping this will be easy to find and fix. I'll let you know cuz now that I know what to look for it will be easy to test if I can find it. will let you know what I find. Sure wish I could get a clue about your problem with ARCANGEL. CAM, have you ever tried ARCANGEL, and could you try it with file 16981? ------------ Category 8, Topic 18 Message 135 Sat Apr 22, 1995 CBM-BANDIT at 09:30 EDT Will do Ed, I'll try to get to it this morning. ------------ Category 8, Topic 18 Message 136 Sat Apr 22, 1995 CBM-BANDIT at 10:47 EDT Ed, I used ARCAngel on file 16981. Aside from taking about 50+ minutes for a large file, I had no errors. I was using RTCM 3.0 and the overlay date is 950121 I booted the newly disolved archive and it works just fine. I didn't have time to check all the overlay functions, but I did load a few of them and look at some of the easy functions. Worked fine. ------------ Category 8, Topic 18 Message 137 Sat Apr 22, 1995 E.GBELL [e.g.bell] at 11:52 EDT Thanks Cam... actually, if you got it all downloaded, it confirms that it works ok. Mark, we really have to figure out why your system is so contrary. One thing I can do is send you my SwiftLink to see if you have a bad one, or one with some kind of intermittent problem. After that, I'm not sure what to do next.... but I did suspect that Cam's results would be what they are. Now on to some more stuff.... Mark:: I found and fixed the dissolve bug... couple funny things about it too.. The original archive programs for the 64 were pretty straight forward in terms of operation... read in 254 bytes, dissolve and write them, go back for 254 more. cS-DOS changed that routine by reading large chunks of the file into a RAM buffer, then processing that in 254 byte chunks. The output in the originals did kind of likewise actually, in 254 byte segments to emulate disk storage. CS-DOS did similary, but again, frmom a RAM buffer. Here, as I suspected, is where I ran into trouble, and the kicker is that I don't understand why CS-DOS has not always had the problem.... the FLUSH routine moves 254 bytes from the output buffer into the FLUSH buffer. When this big RAM buffer fills, it is written to disk. The FLUSH routine assumes that the output buffer is full... 254 bytes. When I translated it, I saw a potential problem here, and changed the test from 254 bytes to the value of the end-of-buffer pointer, thereby avoiding getting garbage bytes added to the dissolved file. The logic was correct. However, I forgot to add the same amount to the RAM buffer pointers, sticking instead with the original 254. I changed it to add the same amount as the end-of-buffer pointer. What I can't understand is why CS-DOS has never been caught with this problem.... upside is that RTCM is now fixed. For the font.... I have that half-solved. Moving the font installation code down to follow the call to 6912 partially solved the problem. It definitely installs the desired font BUT the special character redefs are lost. (i.e. underscore, caret, backslash, brackets, bar, etc.) This one is going to be tricky to resolve. I'm not even sure right at this point where I have to start, but I expect I will be by the end of the day. I'm online right now with a version dissolved from the archive I uploaded. As things stand right now, I will be uploading a new XArchive overlay. I will also be changing the menu screen for ArcAngel and checking to see if I can find a workaround for the problem you have been having. First I want to figure this boot thing out tho. I'm glad you found it tho! As usual, thanks and nice work! ------------ 8 |