8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / RTCMMSGS02.SFX / 05rtcmmsgs < prev

Wrap

Text File | 1990-02-12 | 33.8 KB | 848 lines

of the 'dflt.' files on your drive. There is one other possibility.... if the partition was incorrect (since you could not set it for the system), rtcm would not see those files because it could not get to the partition where they are. That is also a very good suspect. Ok, double checked - BOOTSET will read the "dflt.*" file on drive 9 (1581) but will NOT read it on the HD (1581 partition). Both times on both drives, I used the EZ.BOOT program to start up with, then set the device/drives manually (C= U). All I get on the HD is the partition header. BTW, found another qwirk - On the HD during the "what font do you want" segment of BOOTSET, I got the partition header as a selection. Also getting it in the log on script selection. I guess my next task will be to create another partition and dislove the files again. I'll also do this on the RamLink and see how it reacts there. ------------ Category 8, Topic 18 Message 148 Sun Oct 08, 1995 E.GBELL [e.g.bell] at 14:11 EDT Cam: This is really odd... The program uses a very simple routine to read in the directory... skipping the header data. I think I might have to write a hack sometime this week to read and file the format of the header of your HD as RTCM sees it. It is, from what I am hearing, different than the format of the other drives and RamLink. I do understand what is happening now... and this one could be a nasty one to fix.... I'll reserve judgement tho, until I can get a look at the format of the directory on the HD. The above, btw, does explain why you are seeing what you are seeing... piques my curiosity as well. Apparently the reason it did not abort as it normally would is that something about the directory header 'looked' like a file entry... and since RTCM is expecting (after the directory entry) only matches to the 'dflt.' pattern until it gets to the blocks count line, it took the entry for a dflt. file. There is no checking done on this information because of the above assumption. When I can, I'll write a little basic program to read the directory as RTCM reads it and see what I get.... in the meantime, do you have a manual for your drive, and could you post the directory format? Thanks Cam... I'm working on the defaults overlay today... trying to find out why the weird stuff loading and then saving the dflt. file. This function was a late addition that I probably did not give enough thought to when I added it. Guess I just got lucky that no one gave it a workout until this version. I have scratched a part in what is left of my hair trying to track down and understand what I see, etc. I'm getting there. %) ed ------------ Category 8, Topic 18 Message 149 Sun Oct 08, 1995 CBM-BANDIT at 20:53 EDT EGB> Apparently the reason it did not abort as it normally would is that something about the directory header 'looked' like a file entry... and since RTCM is expecting (after the directory entry) only matches to the 'dflt.' pattern until it gets to the blocks count line, it took the entry for a dflt. file. Ok, so if the header looked like a match for the "dflt" file, why didn't RTCM pick up the entry for the actual "dflt." file as well? As I recall, there used to be an option of having several "dflt." files for whatever reasons. Did this change somewhere down the line? I know, I know.. Questions, questions and more questions! <g> ------------ Category 8, Topic 18 Message 150 Mon Oct 09, 1995 CBM-MARK at 01:42 EDT Ed, eb> I'm not sure about the sequence of events, but I can see how eb> something could happen based on the run/stop key If you are asking what the sequence of events were that lead to the RUN/STOP key crashing RTCM, there is none. Anytime the run/stop key was pressed it would crash. As long as left that key alone RTCM worked OK. Not perfect, but Ok ;> The run/stop key problem only happens when the SWIFTRTS.OBJ file is used. eb> No, but then, the aSc should not be necessary if the correct eb> code is in place. 82 is the aScII code for 'r' Um, I think you misunderstand. I don't have the line number handy but after BOOTSET is run the line starts out like this : io%=82("r") ... It should be io%=asc("r") ... I see I forgot to mention another thing BOOTSET did with the boot file it writes. When an Aprotec modem is specified as being used in the user port, there is a program line that ends up like this : dcd=.16 ... (I should have wrote those line #'s down) It should be : dcd=16 ... The original program line is "dcd=.: ..." so as you can see the period is not written over correctly with "16". eb> Ok, when you say the music is interfering, do you mean it eb> plays when it should not? Yes, exactly! I have it turned OFF in my defaults but when I used a script the music would turn on right after carrier was detected. I'ld see 'hhhhh' sent over the modem and that's as far as the script went because of the music playing. See next- eb> I'll check the save routine tonight... I did some work on that eb> part of the program I believe to make a dflt By saving the dflt. file using C=W instead of through the defaults overlay my music setting of OFF seems to be working now. A script no longer turns on the music on connect. ~~Mark~~ ------------ Category 8, Topic 18 Message 151 Mon Oct 09, 1995 E.GBELL [e.g.bell] at 06:07 EDT I can't answer your question about the header Cam... it is a logical question... and another logical question is why it automatically selected it instead of you having to point at it. As for it not seeing the actual dflt. file, the only thing I can figure is that it has something to do with the way the directory appears to RTCM as read in using the '$dflt.*' pattern. Give that a try and see what you see in a directory using any pattern... i.e. dir "$dflt.*" Tell me what comes up when you do that... or use any pattern you want to see files that are on the drive. That would help me as well to know what you see. It might shed some light. Mark: I have been working the last 2 days to track down the problem you are having with defaults. I can see it but I sure can't find it. I have fixed it somewhat but somehow it does revert to original settings, and I have no clue why. In the bootset problems, just for curiosity, you are not saving your boot file back to 'ez.boot' are you? If so, that is a problem. That should be considered a 'clean page' from which to start boots. You probably are not, but I just thought I'd ask. Previous versions of bootset forced the save to 'my.boot'. I added the ability to pick a name never thinking that someone would use 'ez.boot'. I should have been specific about that. As for the run/stop key, there was a sequence of events whether your finger was involved first or not. ;) I just don't know what it was. There does seem to be a problem you and Eddie are having w/that handler that I am not. I am starting to suspect that bootset is causing a lot of this.... something has been changed that was not accounted for. As I said, ez.boot is expected to be unchanged. I am starting to wonder if I did something to change something. My suggestion for now would be to manually modify ez.boot as you have done for all previous versions, but save it under a different name. From there, make the flow settings using defaults. Me, I have to look some more, but all the problems reported have been isolated or linked to BOOTSET and SWIFTRTS.OBJ. *sn ------------ Category 8, Topic 18 Message 152 Mon Oct 09, 1995 CBM-MARK at 10:30 EDT Ed, I save the new boot file under a different name when using BOOTSET. I have 2 set up for testing purposes, one is "1200BOOT" for using my Aprotek modem and the other is "2400BOOT" for my SL. btw, the line numbers that BOOTSET mess up are '105' and '135'. Set up a boot file for an Aprotek 1200 modem using RAMDOS and I'm sure you'll see what I mean, what BOOTSET does. I just noticed something about the DEFAULTS overlay save routine. The dflt. files it saves are missing the '.' so you end up with DFLTMYSETUP on disk. That would explain some things. Cam, get your directory listing using "$:dflt*" and I'll bet you'll see it too. ~~Mark~~ ------------ Category 8, Topic 18 Message 153 Mon Oct 09, 1995 E.BOURDON1 [C128-Eddie] at 15:22 EDT Ed, I have just realized that what is happening to Mark is the same thing I had trouble with. That is, the dflt.mysetup saving as dfltmysetup when I save from the overlay save pull down menu. It saves fine when I use C=w to save it. also, the music playing after I turned it off is another problem that was fixed after I re-saved the dflt.mysetup with the C=W and selected 'y' at the make changes permenant prompt at the defaults overlay. I haven't had a chance to test it in the RTC again and see if it keep crashing on me. That is one problem down. :) ------------ Category 8, Topic 18 Message 154 Mon Oct 09, 1995 CBM-BANDIT at 16:25 EDT EGB> I can't answer your question about the header Cam... it is a logical question... and another logical question is why it automatically selected it instead of you having to point at it. As for it not seeing the actual dflt. file, the only thing I can figure is that it has something to do with the way the directory appears to RTCM as read in using the '$dflt.*' pattern. Give that a try and see what you see in a directory using any pattern... i.e. dir "$dflt.*" Tell me what comes up when you do that... or use any pattern you want to see files that are on the drive. That would help me as well to know what you see. Ok, I went thru the defaults overlay and bootset overlay and wrote down all the odd items... Default Overlay: ---------------- - Change font: Showed font.typewriter (I added that) and hd 3d f <- This "f" is where the P or S for Seq would be. Bootset Overlay: ---------------- - Font : Showed hd 3d f and font.typewriter - Dflt.* : Showed hd 3d d ONLY - Scrp.* : Showed hd 3d [] <- was blank this time Empty Slot s <- had "s" in this empty slot scrp.mailbb p scrp.SprintNet3 p - User ID: Showed Graphic characters in the area for user ID # Had to Delete these and insert Number Checking the directory Using RTCM --------------------------------- - C= F1 : Showed DFLT.MYSETUP & File saved as "HD 3D" from Bootset - C= Y : Using DFLT.* for directory pattern, showed ONLY DFLT.MYSETUP One last note, I had no problems saving "mysetup" in the defaults overlay. I didn't need to go outside it and save with C= W. ------------ Category 8, Topic 18 Message 155 Mon Oct 09, 1995 CBM-BANDIT at 16:42 EDT Mark, Saved mine in the defaults overlay and my DFLT.FILE has the "." in it. Ok, which one of us has the system from hell? What doesn't work for you, works for me! ------------ Category 8, Topic 18 Message 156 Mon Oct 09, 1995 E.GBELL [e.g.bell] at 19:32 EDT Gads! I finally found the problem with the changing device numbers and you find another one??? However, I did make a change to the filename routine yesterday... it was however a problem with cutting one letter off the end, not the '.' in the middle. I have been saving files, and not noticing that... perhaps I fixed that somehow unintentionally but I'll check it out tomorrow anyway. And saving the files that way is a good idea Mark. I fixed bootset today to screen out the ez.boot name, to skip the '.' in the dcd setting, and yesterday to do the 'asc..' thing. Cam: I meant to have you do that command outside of RTCMaster... at the ready prompt, just type in this command: dir "$dflt.*" and tell me what comes up. It is obvious that RTCM is seeing the directory name as a file entry. What is not obvious is how it is getting into the filename that is saved to disk. Fwiw, i have not seen the problem with the '.' myself, tho I am going to specifically check for that later tonight. I have been seeing the files I've been creating, but I do think I fixed that problem tho, now that I think about it. I looked at a piece of my code and had to wonder what the hell I was doing there... I removed it, but come to think of it, it could have caused exactly what Eddie and Mark are describing, tho it would have caused something worse as well... I made a new archive of 3.02 tonight with the fixes I've made over the past few days. This is for beta only, until we get this weird stuff ironed out. It would be so much easier if this stuff would happen to me instead of everyone else... less embarassing too. ;) O, btw, Cam... I can pretty much state from experience that it is Mark that has the system from hell.... if there is a problem, ANY problem, Mark's system will find it! That has proven to be a great help over the past few years. Lots of work too... ::: groan ::: ; ) ------------ Category 8, Topic 18 Message 157 Mon Oct 09, 1995 CBM-BANDIT at 22:05 EDT Ed, I used the command dir "$dflt.*" with and without quotes. w/o - I get ?syntax error w - I get nothing but the ready prompt ------------ Category 8, Topic 18 Message 158 Mon Oct 09, 1995 E.BOURDON1 [C128-Eddie] at 23:43 EDT Ed, Once again I had RTCM break to monitor on me. Here is the results: 00085 34 07 01 c8 24 I also had something new happen tonight. While in the RTC, I got a 'Undefined statement in 450' error after I had just transmitted a line. I am begining to feel that maybe there was a bad block somewhere when I d/l, although none were reported when I d/l the 3.02 arc files. ------------ Category 8, Topic 18 Message 159 Tue Oct 10, 1995 CBM-MARK at 00:06 EDT cs> Saved mine in the defaults overlay and my DFLT.FILE has the "." cs> in it eb> Fwiw, i have not seen the problem with the '.' mysel I missed seeing this beacause there *was* a file on my disk called 'dflt.mysetup' with the '.' in it. I just assumed this was the file I had saved through the defaults overlay. Not so, it was the original. Paying closer attention to all the files on disk revealed I had one there as 'dfltmysetup'. I confirmed this by saving another dflt. file through the overlay using 'test' as my entry. I ended up with a file on disk as 'dflttest'. btw, Ed, weren't the dflt. files saved to disk at one time as "@0:dflt.<filename>" in the overlay? If so, they aren't now. eb> O, btw, Cam... I can pretty much state from experience that it eb> is Mark that has the system from hell... LOL! Maybe that explains the funny green glow comming from inside the computer ;> ~~Mark~~ ------------ Category 8, Topic 18 Message 160 Tue Oct 10, 1995 CBM-BANDIT at 18:11 EDT I just took another, closer look at the files in the directory. There is indeed a file called DFLTMYSETUP and it is missing the ".". ------------ Category 8, Topic 18 Message 161 Tue Oct 10, 1995 CBM-MARK at 21:29 EDT Sneaky little files aren't they ;D ------------ Category 8, Topic 18 Message 162 Tue Oct 10, 1995 E.GBELL [e.g.bell] at 21:44 EDT CS> I used the command dir "$dflt.*" with and without quotes. CS> w/o - I get ?syntax error CS> w - I get nothing but the ready prompt You should have gotten a syntax error w/o the quotes. With the quotes, you should have gotten a directory listing of any files that start with 'dflt.' on that directory. I assume there is at least one. If that is correct, and you did everything correct, it seems that the HD responds differently to that command than every other device I've had experience with. Is there anyone else here who can duplicate cam's results? EB> a 'Undefined statement in 450' error after I had just EB> transmitted a line. I am begining to feel that maybe there EB> was a bad block somewhere The undefined statement error sounds like a stack error Eddie...IOW, something is playing fast and loose with the stack...something in my code, that is. The easy thing would be to blame a bad download, but truth is, that gets blamed far more than facts justify. a bad download would more likely not work at all. when you say you just transmitted a line, are you talking about normal chat mode or from the editor's xmit line mode? MD> Paying closer attention to all the files on disk revealed I MD> had one there as 'dfltmysetup' this is what you have always done better than anyone else! I located the problem the other day too, based on your report. when I first wrote the routine to save the file name, for whatever reason I started storing the filename at 'putbuff+1'... meaning the first byte was a zero... I don't know all of the things that would have rippled down from this, but the missing '.' makes a world of sense here. That is where it went. That has been removed. MD> btw, Ed, weren't the dflt. files saved to disk at one time as MD> "@0:dflt.<filename>" in the overlay? If so, they aren't now Not sure if they were... that feature is still relatively new... but at any rate, the problem just mentioned might have been a factor in this. CS> is indeed a file called DFLTMYSETUP and it is missing the "." Sherlock Dulski! I have another test package to upload. It is just a minimal package but all the fonts and scripts are in the package cuz they are small files. ------------ Category 8, Topic 18 Message 163 Wed Oct 11, 1995 CMD-DOUG at 00:36 EDT CS> I used the command dir "$dflt.*" with and without quotes. CS> w/o - I get ?syntax error CS> w - I get nothing but the ready prompt EB> You should have gotten a syntax error w/o the quotes. With the quotes, EB> you should have gotten a directory listing of any files that start with EB> 'dflt.' on that directory. I assume there is at least one. If that is EB> correct, and you did everything correct, it seems that the HD responds EB> differently to that command than every other device I've had experience EB> with. Is there anyone else here who can duplicate cam's results? I can verify Cam's results, not only with my HD, but with every drive on my system. After all, 'dir' isn't a legal command. Maybe he should try replacing that with 'directory'. I'm also not sure why you would put the dollar sign in the filepattern string, since directory already calls for the directory file. Checking a disk that had files beginning with 'd', and issuing the command 'directory "$d*"' got me only the header and blocks free. Changing the command to 'directory "d*"' got the desired results. ------------ Category 8, Topic 18 Message 164 Wed Oct 11, 1995 E.BOURDON1 [C128-Eddie] at 11:13 EDT Ed, I was in normal chat mode when I got the undefined statement error. ------------ Category 8, Topic 18 Message 165 Wed Oct 11, 1995 E.GBELL [e.g.bell] at 21:23 EDT He should have typed 'diR', which is a 'legal' abbreviation for directory... which I'm sure you knew when you looked at Cam's reply, or my original post. That was a fat-finger on my part, but it was not off the wall. I put the file pattern in the string because it works with every other drive that I had access to... including the 1541. The technique works even on the RamLink. The reason what I asked Cam to do did NOT work, and this is my fault for forgetting what I have been doing all along, is that this is not a DIRECTORY type thing. This is a FILE OPEN thing.... iow, I don't do a 'dir "$dflt.*"... I open a channel to that file... open #,#,#,"$dflt.*" I'd have to look at the channel and secondary address to see what I use, but that also is all only marginally relevant (as far as the units that work). The fact is, the technique works on every commodore drive I have ever tested it on, including the 1541, and also on the RamLink. The fact that it works anywhere should tell everyone that the technique does work. Mentioning the directory command, and the improper abbreviation for it at that, was a mistake on my part because I forgot about what I do in RTCM. But unless the problem is solely because of the filename thing I already discussed, the fact 'seems' to remain that the hard drive reacts differently to this kind of file open than the other devices. The only thing that makes me question that a little is that this has not come up before. Do you also have an answer for why this works on the RamLink, 1571, 1581, 1541, and not on the HD now that I've explained correctly what it is I'm doing to bring up a pattern directory? I had asked Cam for the directory layout... is it different from the other units... does DOS process what I'm doing differently in the HD? I was looking for a quick test for Cam to get me results. I see now that I have to write a little BASIC program to do this because that is how RTCM works.... doing that I can also have it create a file I can examine. If, however, the HD does not work like, say, the RamLink, as far as opening the directory like this, it is going to be a big change on my part. O, and if you are wondering why I do it that way instead of just doing a 'directory' or 'catalog', it is because I have to buffer the file names coming in and strip the directory header and the blocks free line, tho I have to suspect you surmised this anyway. This was the easiest way I could find to do it... treating the directory as a file. The actual directory routine in RTCM changes the BSOUT vector while it is working... that is how it creates the dual column display. I used to use this method for the overlays that required pattern directories, but I felt it was kind of dangerous... my opinion... for those applications and I had some memory management problems too. This technique works fine.... except on Cam's hard drive... and again, I'm holding back final opinion because of the file name problem, which really should not create this result... but I'll wait to see. O, and before anyone says it, I KNOW that abbreviations of keywords work because of an unintentional 'feature' in the system code. I read that article 10+ years ago in Transactor or Gazette or Compute, wherever. I use them, which is why I told Cam to type 'dir'... my mistake was not having him capitalize the last letter. For everyone reading this, decide for yourselves if you prefer to type 'directory' instead of 'diR' (or 'catalog' instead of 'caT'). Either way, as Doug pointed out, you cannot type 'dir' because it is a syntax error (except in CS-DOS and CP/M). egb ------------ Category 8, Topic 18 Message 166 Wed Oct 11, 1995 E.GBELL [e.g.bell] at 21:25 EDT Ok Eddie... That doesn't give me much to go on... or too much actually.... What I have to do is work at the problems I know of or find and hope that it cures that problem. It is definitely a stack problem tho... that is the only thing I can tell for sure from your description. Thanks! ed ------------ Category 8, Topic 18 Message 167 Wed Oct 11, 1995 E.BOURDON1 [C128-Eddie] at 22:03 EDT Ed, I'll see what else I can come up with, but a quick overview of my problem is this: RTCM 3.02 breaks to monitor on me ONLY when I am in the RTC and only after I transmit a regular message in the chat area. It doesn't just break at certain times, but only when I transmit data. Whenever I do get a break, the address listed on the monitor also greatly varies..anywhere from 00085 to 00202. The setup is: Booting from a Ramlink, with a swiftlink, no clock on the RL, using a 14.4k modem, set to 2400 baud. I have the break set to the default, xon/xoff flow control, and the other number (I forgot what it was for) set to your reccomendation of 800. The other night I had Cam try out RTCM while he was in the RTC with me. I broke to monitor once, plus got the previously mentioned 'Undefinded Statement in 450' error, while Cam had no problem at all. Just a summary, hope this helps you out. ------------ Category 8, Topic 18 Message 168 Wed Oct 11, 1995 CMD-DOUG at 23:07 EDT What the HD returns if open the directory file as a program (can I assume you're using a secondary address of 0?), is the directory in a BASIC program format, as any drive does. What you cannot do, however, is assume that there are any 'fixed' field lengths. That's about the only thing I can think of that will give you a problem, or in which you'll see any differences. Each 'line' of the listing will contain the usual link and 'line number' (file sizes), which will be followed by the filename and type data. The 'line' will end with a zero byte, and the name will be enclosed in quotes. Other than that, there isn't much else that can be assumed, but the length of the line will vary on the HD from what I can recall. There is an example program supplied with the HD for reading directories in this manner. Being that I wrote it back in 1989, though, I don't recall the specifics offhand. I believe it was called READ DIR.BAS. Perhaps CAM could email it to you if he has it handy. ------------ Category 8, Topic 18 Message 169 Wed Oct 11, 1995 CBM-MARK at 23:46 EDT eb> if you prefer to type 'directory' instead of 'diR' (or eb> 'catalog' instead of 'caT'). The abbreviation of Catalog is 'cA'. I use it all the time - shorter than diR ;D ~~Mark~~ Sherlock? LOL! ------------ Category 8, Topic 18 Message 170 Thu Oct 12, 1995 CMD-DOUG at 00:14 EDT I generally just press F1. Call me lazy. I just did an analysis of a 1571 directory vs. an HD directory, looking at the values returned when opening the directory with 'OPENlfn,dv,0,"$*"'. I couldn't detect a significant difference. The various fields are separated by one or more spaces (chr$(32)), and the locations of each field floats on both drives, depending on what kind of spacing is needed for a formatted output. But both appear to contain all the same parameters, provided in the same order. Maybe you're using some other method to open the directory? ------------ Category 8, Topic 18 Message 171 Thu Oct 12, 1995 CBM-BANDIT at 06:44 EDT I'll look for that file later today.. ------------ Category 8, Topic 18 Message 172 Thu Oct 12, 1995 CBM-BANDIT at 17:28 EDT I don't have that program Doug. :/ ------------ Category 8, Topic 18 Message 173 Thu Oct 12, 1995 E.GBELL [e.g.bell] at 19:03 EDT I'll look at what I did later tonight... I know I had to try a couple different methods to get it to work on all units. Well... I'll check my code tonight to see what I'm doing and why it is not working. I really didn't think the hard drive could get too radically far afield, if at all. Cam... btw, have you noticed this phenomonon on any of the previous versions of RTCM, or just on this recent version? If it is just the recent one, that would narrow things down a lot. Eddie... the break to monitor or BASIC is 100% my problem. I'm just not sure where that problem is right at the moment.... and this kind of problem can be a monster to find. Does anyone know... I seem to remember something being discussed on FIDO about a trace that needed cut in some Swiftlinks for proper operation... it seems to have been DesTerm that had the problem with it... I just don't really remember what it was. Be Back later w/hopefully some light to shed on the directory thing. Mark: I believe that 'caT' will also work, as will 'catA', etc. I did not test this, but as the article explained, this was the result of a bug in the code that worked out as a feature... and once the test passed the point of being unique, it was acceptable when the hi bit was found in a command letter... if that was clear... point was, this was, according to the author, a bug that proved to be a useful feature. I can't say if that is true or not, but just that it works. ;) ------------ Category 8, Topic 18 Message 174 Thu Oct 12, 1995 E.GBELL [e.g.bell] at 19:19 EDT Ok... checked my code... it follows for anyone who likes detective work... 2910 ;-----<call a common directory routine that can be called from ovrl files> 2915 .u 2920 point.click tsx:stx read.stack; remember where we parked 2925 ; 2930 ;-----<init pdir buffer> 2935 ; 2940 : lda #$00:sta y.jobs 2945 : lda #$b8:sta y.jobs+1; in case an overlay changed this 2950 ; 2955 ;-----<pull the directory into ram> 2960 ; 2965 : jsr pdir:bcc select.file; load the array 2970 : rts 2975 ; 2980 ;-----<select file from list 2985 ; 2990 select.file = * 2995 : .... code to select from directory fetchec by 'pdir' 3220 ; 3225 ;-----<caller should set 'read.stack' with return stack value> 3230 ; < set 'chrout.flag' = 0> 3235 ; < set 'y.jobs/+1' w/address of buffer to be used> 3240 ;-----<open the file 0,<device>,0> 3245 .u 3250 pdir jsr opencmd; open command channel to device 3255 ; 3260 : lda y.jobs :sta $fb 3265 : lda y.jobs+1:sta $fc 3270 : lda #0:sta tb.index 3275 ; 3280 : lda #1:jsr closex 3285 : jsr sba0 3290 : jsr pbdx 3295 : lda #1:ldx device:ldy #0:jsr setlfs:jsr open 3300 ; 3305 : jsr clrchn:ldx #1:jsr chkin 3310 ; 3315 ;-----<strip disk name/id> 3320 ; 3325 : jsr getin:jsr getin:jsr getin:jsr getin 3330 ; 3335 !01 jsr getbyte:cmp #34:bne !01 3340 !02 jsr getbyte:bne !02; strip disk id 3345 ; 3350 ;-----<strip link bytes> 3355 ; 3360 !21 jsr getbyte:jsr getbyte:jsr getbyte:jsr getbyte 3365 ; 3370 : ldx tb.index:ldy mmu:sta $ff01 3375 : lda $fb:sta tb.pointl,x 3380 : lda $fc:sta tb.pointh,x 3385 : sty mmu 3390 ; 3395 ;-----<find 1st quote> 3400 ; 3405 !03 jsr getbyte:cmp #34:bne !03 3410 ; 3415 ;-----<store filename while looking for 2nd quote> 3420 ; 3425 !04 jsr getbyte:cmp #34:beq !06 3430 : jsr pokebyte:jmp !04 3435 ; 3440 ;-----<put <cr> on end of info> 3445 ; 3450 !06 inc tb.index:lda #",":jsr pokebyte 3455 ; 3460 ;-----<get file type byte> 3465 ; 3470 !61 jsr getbyte:and %01111111:cmp #32:beq !61 3475 !62 jsr pokebyte; p/s/u/r/etc. 3480 lda #13:jsr pokebyte 3485 ; 3490 ;-----<find 0 and loop> 3495 ; 3500 !07 jsr getbyte:beq !21 3505 : cmp #"<":bne !07 3510 : jsr sub.1.fb:jmp !62; buffer it and resume search for 0 3515 ; as you can see from the above, I open channel 1 w/secondary address 0, (as you noted, Doug), then do a pretty vanilla read of the directory as a file. I check for the " character as a delimiter... strip spaces after a file name.... consider the first non-space character after a directory entry as the file type.... the only other thing in this is a backup of pointers if a '<' character is found signifying a locked file. I don't think anything above is exotic. From what I gather of what you said in the previous post, Doug, the code above should do just fine with the HD. the filename problem is still a candidate and that will take more digging, but for now, it is my prime suspect... tho the problem is fixed, I'll know if it was a potential cause for what Cam ran into.... that is the focus of my attention right now. Thanks! ------------ Category 8, Topic 18 Message 175 Thu Oct 12, 1995 CBM-BANDIT at 20:17 EDT EGB> Cam... btw, have you noticed this phenomonon on any of the previous versions of RTCM, or just on this recent version? If it is just the recent one, that would narrow things down a lot. I really haven't fooled with anything more recent than 3.0 until now. I recall having to make changes in the boot file manually and anytime we saved the "dflt.*" file, we had to use C= W. This directory problem is really a new twist. The only other semi related problem I had and mentioned to you was the time clock in the HD. For some reason, your code wouldn't fetch the time from the HD, but would from the RL. Since I have both, I think we just blew it off and I continued to grab the time from the RL. To be honest, the only reason I got into this one, was because Mark couldn't get it to work. I knew from past experience, if he has a problem and it won't work on his machine, it WILL work on mine! <G> ;) Call it a challenge! :) I was also hoping to check out the game overlays before this weekend, but looks like it'll have to wait til I get back from Pa. om Tuesday. :) I'll see what new undocumented features I find in there ;) EGB> Does anyone know... I seem to remember something being discussed on FIDO about a trace that needed cut in some Swiftlinks for proper operation... it seems to have been DesTerm that had the problem with it... I just don't really remember what it was. The only trace cutting I know of, was for using the REU and SL at the same time. You cut the trace in the SL and the corresponding Trace in the REU and then ran a wire between the two. This was a hardware hack that renders the warrenty on the SL useless. This was RamLink related BTW. ------------ Category 8, Topic 18 Message 176 Thu Oct 12, 1995 E.GBELL [e.g.bell] at 20:50 EDT Cam: CS> hoping to check out the game overlays before this weekend they have not been assembled... I don't want to do the whole package until the basic code has been determined to be trouble free. If I have to assemble the main program again, I have to redo the overlays too... it tends to be a big project so I'm going to do it in smaller sections this time.... until I get a stable program, you will have to use the earlier version to use the games. BTW, I have not been adding things to the games... they only change when there are changes in the main program that affect them.... the point/click stuff is an example of that.... sorry about the line noise... probably my upstairs modem... :( ------------