8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / RAMLINK.MSGS.ARC / 00RAMLINK next >

Wrap

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

************ Topic 2 Thu Oct 24, 1991 C128.JBEE [* Sysop *] at 04:36 EDT Sub: Ram Link This topic is for comments, suggestions, and news about CMD's Ramlink. 118 message(s) total. ************ ------------ Category 12, Topic 2 Message 1 Wed Oct 26, 1994 S.SHEI at 23:19 EDT I'm having trouble configuring my 8Mb Ramlink. I want to set it up with Menuette64 on the first partition set to autoboot and also set up Gateway128 on partition 3 so I can boot it when I am in 128 mode. I have no problem setting up Gateway128 and booting until I add the Menuette64. Then Gateway128 won't boot anymore. ------------ Category 12, Topic 2 Message 2 Fri Oct 28, 1994 CMD-DOUG at 14:34 EDT I really have no idea why this should cause a problem... the two have no inter- relationship with each other, and as long as you're using separate partitions (which you indicated you were) there shouldn't be any conflict. ------------ Category 12, Topic 2 Message 3 Mon Oct 31, 1994 S.SHEI [Poboy] at 21:55 EST I set up Gateway128 on partition 1 and menuette on partition 30. Gateway128boots fine in 128 mode. When I autoboot menuette64 in 64 mode I am getting a "File not found error in 140" after the message "LOADING MENUETTE 64 V1.10". I used the autoboot program on the Ramlink utilities disk and set the path to partition 30. If I use the autoboot module in Menuette 64 I get the same results. Any ideas ?? ------------ Category 12, Topic 2 Message 4 Tue Nov 01, 1994 CMD-DOUG at 00:09 EST If your default partition is not partition 30, then the Menuette loader will not be able to find the other Menuette files. You might be better off making a small BASIC program that changes to partition 30, then loads Menuette. Save that program, then make it the file that gets loaded at startup. ------------ Category 12, Topic 2 Message 5 Tue Nov 01, 1994 I.MCKINNEY [TheBigMac] at 02:24 EST I have had that same problem also. Whyizit that the first file of the Menuette program gets loaded even with a different default partition and the RAMLink can't find the rest of the program? It would seem to me that if it can find the original loader program it should be able to find the rest. ------------ Category 12, Topic 2 Message 6 Tue Nov 01, 1994 I.MCKINNEY [TheBigMac] at 02:56 EST Here is what I did to alleviate the problem. I added this line to the Menuette 64 program: 340 OPEN15,16,15:PRINT#15,"C<shift P>"CHR$(n):CLOSE15 I found these commands at the bottom of page 66 in the RL manual. Shift P of course means just that and "n" denotes the partition that Menuette is in. This seems to work so I would suggest you give it a try. BTW, as of midnight I am officially out of the Air Force and I am so damn happy. I gave Uncle Sam 11 years of my life and am glad to get back to being able to do what I want to do. I'm officially unemployed now but I will still find what I'm looking for. (Just my 2 cents worth) :-> ------------ Category 12, Topic 2 Message 7 Tue Nov 01, 1994 CMD-DOUG at 21:10 EST The reason it can find the first file is because you're telling it where to find it. The reason it can't find the remaining files is because they are not in your default partition, which is where RAMLink ends up during the starting process. That's why it's called the DEFAULT. If you just change the default partition to the one where the Menuette programs are, you won't have this problem. ------------ Category 12, Topic 2 Message 8 Wed Nov 02, 1994 R.DAY at 21:19 EST I am happy now :) I all most all ways had problums with my Ram Link Battery. When I 1st got my Ram Link I could take it over to others with just the battery and all the data would still be there. But now if the power just went out for a little bit all the data would be lost in my Ram link :\ I got BBU, Battery Back-Up from performance peripherals about a week ago. It has a low battery light on it. I pluged in the Ram Link battery to it and the light would stay on saying the battery was low. I moved the wires around close to the battery and the light would go on and off. So I soulded the wires to the plugs that pplug in the battery and now it works all the time :) It was just sqezed on before I solderd it. So if any one has problums like this it my be the wires on the battery! I wish I would of know this a long time ago. I hated Ram link just because of that! Now it's like new agian :) ------------ Category 12, Topic 2 Message 9 Wed Nov 02, 1994 C128.JBEE at 23:00 EST I secured the wires and terminals to my battery with electrical tape to prevent shorting and to make sure the terminals did not wiggle loose in case I moved the RL. I was too scared to solder around my battery even though it is sealed. ------------ Category 12, Topic 2 Message 10 Thu Nov 03, 1994 CMD-DOUG at 00:22 EST Some of those battery cables were not too good at the crimped terminals. We started soldering them ourselves at some point, and I suspect yours was one that got out before we caught this problem. I'm not sure if production still does this, as we may be into a different cable vendor by this point in time. ------------ Category 12, Topic 2 Message 11 Thu Nov 03, 1994 R.DAY at 03:06 EST I wish you would of told me a long time ago that could be what was wrong. I called at lest 2 times asking what could be wrong with my Ram link. they never said the crimped par of the battery cord. I hard that the power in the battery my be low or when the power was just off for a little Ram link my not back the ram up. Well I think I had Ram link for more then 3 years now. If some people call don't for get to ask how old there Ram link is and that the criped part on the battery could be bad. I just wish I would of know this a long time ago. I would not of lost all the data I had in there. ------------ Category 12, Topic 2 Message 12 Thu Nov 03, 1994 I.MCKINNEY [TheBigMac] at 05:02 EST 2 cents worth!!! I absolutely LOVE my RAMLink! I cannot believe I went so long without one. It isn't full yet(I have 4MEGS + 2MEG BBGRAM) but when it is, I know my system will scream. ------------ Category 12, Topic 2 Message 13 Thu Nov 03, 1994 B.MASSE [BIG BOB] at 10:07 EST Here is a little problem that my Ramlink Suffers (it is about 3 years old). If you wiggle the main power supply connector that goes into the back of RamLink (very lightly) the whole ramlink will get scrambled and zapped. What I did was strap a piece of wire from the two back/side screws of the RamLink and secured it in such a way that the power connector won't wiggle. That fixed my little problem. Haven't had ram dump in 6 months. Doug... I checked my back-up battery voltage yesterday. It reads 12.5 volts. Is that correct? Seems kinda high to me. Bob ------------ Category 12, Topic 2 Message 14 Thu Nov 03, 1994 CMD-DOUG at 21:11 EST Bob, how was the check performed? Concerning the connection at the battery port, some RAMLink's have different size center posts on that connector. Chances are you have one with a slightly smaller O.D., and that leaves some play. You can try to put a gentle crimp or bend in that post with a small set of needle-nosed pliers to resolve that situation. ------------ Category 12, Topic 2 Message 15 Thu Nov 03, 1994 B.MASSE [BIG BOB] at 22:31 EST Category 12, Topic DC> Bob, how was the check performed? I unplugged the battery from the RamLink and attached a digital multi-meter to the wire ends at the plug and took the reading. Twenty minutes later......... Whoops, I double checked the reading with another multi-meter and the reading came out at 6.5 Volts. Seems that old Digital Multi-meter was having a Nervous break-down. Thanks for the other info about the power port, Doug. Bob ------------ Category 12, Topic 2 Message 16 Mon Nov 07, 1994 J.BARBER9 [Dan Barber] at 23:33 EST I have a Ramlink and have been using it for some months now, and I have come across a problem. I have been using it with a 1541, 1581, and 1750 REU with no problems. But recently my 1541 stopped functioning, and I had to switch to my 1571. And since then when I use Geopublish, I cannot print with it. The print out will duplicate a part of the page, only partially, but it works perfectly other than that. And if I turn my 1571 off and boot with my 1581 or ramlink geopublish prints perfectly. All my other programs; Geowrite, Geopaint to name a few, work fine. Also if I run my 1571, 1581, but turn off my ramlink (disable switch) then it will print fine. Is this a bug in the software? And if so has it been corrected? And if it has been corrected, would you send me a copy? I thank you for all the help that you can give me. Thank you. By the way, I have the one disk version of Geopublish. Dan ------------ Category 12, Topic 2 Message 17 Tue Nov 08, 1994 CMD-DOUG at 03:33 EST This isn't a software problem that I know of, and probably indicates some kind of hardware problem. But a few more details, please: What kind of computer are you using, and is the RAMLink timing jumper clip being used? Also, is this GEOS 64 or 128, and do you use the standard GEOS deskTop or some alternative? Also, what kind of printer, and how is that interfaced? ------------ Category 12, Topic 2 Message 18 Tue Nov 15, 1994 D.BELTER at 05:11 EST HELP!!! I just got my RAMLink and can't get my Super 1750 Clone and Swiftlink to work. The REU works but Desterm can't find the Swiftlink. I do have a RAM CARD but 0Megs installed. Also sometimes when I boot up, my 128 RESET anywere from every second to after a few minutes. I am using the Timing cable (best bet since it REAL OLD 128), and after reading the manual. I still don't know... Will the problems go away when I install some SIMMs (I'm broke, so the I will have to live with 512K until the end of the month). BTW Thanks Jbee.... :) All I get is MORE problems... :( ------------ Category 12, Topic 2 Message 19 Tue Nov 15, 1994 CMD-DOUG at 22:21 EST With RAMLink in DIRECT mode, the pass-thru port is disabled. That's why Desterm can't find SwiftLink. But in NORMAL mode, you'll have just the opposite problem... Desterm will find SwiftLink, but not the REU. This is why many of us who use RAMLink tend to use Dialogue instead... Dialogue can be booted directly from a RAMLink partition, and can also use RAMLink for uploading and downloading. Desterm, with it's custom I/O, isn't capable of this (though there is a beta version of Desterm 2.01 floating around that can do this, but you may have to suffer through some bugs in it). The resetting tends to indicate some kind of hardware problem. This is often tracked down to a bad connection on the port where you plug in the RAMLink. Could be dirty contacts on that port, or one or more of the contacts not grasping the RAMLink card edge tightly enough to make a good connection. Check the port, clean the contacts, and align any of them that look as though they aren't as far toward the center as the rest. Also, make sure the power supply connector is well seated. ------------ Category 12, Topic 2 Message 20 Wed Nov 16, 1994 D.BELTER at 05:22 EST Nope on hardware resetting, it was software, deleting the partition and redoing it got rid of the resetting problem! I *do* realize that I need to use Desterm 2.01 (it the only copy I can find) I haven't found many bugs in Desterm 2.01, I do wish it would load in all the protocals like 2.00 did. :( I found it on the Inet. ;) I guess I will dug though the docs again and see what I can find, that if I can find them. Sorry about the misunderstanding over Desterm. Also I think I got 2.01 at one of two major CBM sites... I will try again!!! ------------ Category 12, Topic 2 Message 21 Wed Nov 16, 1994 D.BELTER at 05:34 EST Ok, not much docs when with Desterm 2.01 but I got it work but NOT as an REU but as a Device! If I set the Ramlink to device 15, I can now access that device. I do wish I had more the 1728 block free. :( ------------ Category 12, Topic 2 Message 22 Wed Nov 16, 1994 CMD-DOUG at 21:39 EST Ack! For that, you just need to add RAM. :) ------------ Category 12, Topic 2 Message 23 Sun Nov 20, 1994 D.BELTER at 05:27 EST Hopefully by the end of the month I should have 4.5megs in the Ramlink! :)) I have Desterm 2.01 lock up twice since I have been using the Ramlink but not much since the first night, though. Blast had another question but forgot it right now. :( ------------ Category 12, Topic 2 Message 24 Sun Nov 20, 1994 L.SCHONDER [C128.LOU] at 10:47 EST D.BELTER - If you are handy with a soldering iron, can work your way around circuit boards, handle boards in a static-safe manner, and follow moderately technical instructions, you CAN use your Swiftlink and 17XX REU at the same time with a Ramlink! With Dialogue 128, you can do ALL that Doug mentioned, AND use your REU for a GREAT text buffer! At 512K, you can either have eight 800 line buffers, or a massive 6400 line buffer! (You would need "ZED128" to edit the large buffer) This mod is NOT for the faint hearted!!! You can also say "Bye-bye" to your warranties! Outlaw, did you buffer the text I wrote to you in the RTC that night? If so, can you E-mail it to me? :) ------------ Category 12, Topic 2 Message 25 Sun Nov 20, 1994 THE.OUTLAW at 12:32 EST I have it Lou, question is where did I put it... I'll email it when I find it :> ------------ Category 12, Topic 2 Message 26 Mon Nov 21, 1994 D.BELTER at 03:20 EST Since I don't use Dialoge but Desterm 2.01, I don't mind setting it as a Drive instead of a REU. :) I have UPGRADED a 1700 REU to 1750, and you talk about being faint hearted? ;) I would most like not do the mod but I WOULD like the Hack, I am always in search of new hardware projects! ------------ Category 12, Topic 2 Message 27 Mon Dec 05, 1994 J.BARBER9 [Dan Barber] at 22:23 EST Sorry I took so long to get back to you Dough. In response to the problem I am haveing with Geopublish and the 1571 disk drive, you wanted to know my system so here it is: A Commodore 64, 1571 disk drive set to device 8, 1581 disk drive set to device 9, a ramlink with 4 meg simm module and a 1750 pluged into it set to device 10. I am useing Gateway, it is an older version could this be my problem? Although I don't see how. It is still doing the same thing. When I print out from Geopublish I get part of the page duplacted (and a bad one at that) in the border. But when I shut off the 1571 drive and boot from the ramlink or my 1581 it prints fine. No other program does this. Just Geopublish. And if I use a 1541 insted of the 1571 I do not have any problem. I hope I have given you enough info. Let me know if you need more. Oh one other thing, How long with aramlink last (approxmatly)? I was wondering if a ramlink will wear out faster than most circut boards because it is constanly being fed power. Is this right? I would appreacite a good guess on this one. Thanks in advance. Dan ------------ Category 12, Topic 2 Message 28 Mon Dec 05, 1994 J.BARBER9 [Dan Barber] at 22:28 EST Forgot to mention, I have the jumperclip installed in my 64. ------------ Category 12, Topic 2 Message 29 Tue Dec 06, 1994 CMD-DOUG at 08:46 EST Dan, I'd probably try creating a new 1571 boot disk; but if it's not gateWay v2.5, you might be running into one of the quirks with the old 1571 driver. You can still upgrade gateWay for $15.00 by sending in the original disk and payment. The circuitry in RAMLink is fairly low-powered, and there's long been an arguement in the electronics community as to whether a device gets more wear from being left on, or from the surges that occur when it is turned on and off. I doubt theres much difference, except perhaps in the case of the power supply, which might tend to wear out a little sooner - but it should still normally last quite a long time. ------------ Category 12, Topic 2 Message 30 Thu Dec 08, 1994 D.BELTER at 04:38 EST Here we go again. :( My new Ramlink does like my 128 again! This time I KNOW its my 128 and NOT the Ramlink since it work PREFECTLY fine with all of my C64s! I have 2 128 and neither one works with it. One just give me a BREAK and the other a BLACK screen. When I install the timing jumper, my drives (1541, 1571, FD2000) ll SPIN with the red light on. What make this madding is that it worked FINE for about 2 weeks and now I have problems back. Any help would be nice, both 128 are date late '85 on the bottom. Both work find with any other cart I have but not the Ramlink! Any help would be GREAT, I really don't want to buy another 128 to get the Ramlink to work! ------------ Category 12, Topic 2 Message 31 Thu Dec 08, 1994 H.HERMAN1 at 05:02 EST Doug, When I took a reading of the 2 RL batteries, in parallel, and while disconnected from RL, it was a smidgen over 5 volts. Instead of doing what I am doing now (asking you about this), I went ahead and cut off the power to RL for about an hour. Alas, the 12 megs initialized when I powered back up. Curiously, the RTC kept the correct date and time, however.... Would you have any idea where I can begin to look for what's wrong? Howie ------------ Category 12, Topic 2 Message 32 Thu Dec 08, 1994 CMD-DOUG at 07:11 EST D.BELTER: Call CMD Technical Support (413-525-0023) and request the the RAMLink 'connection' troublshooting data sheet. This outlines a number of items you can check. 90% of such problems are usually connection-related. Howie: What version/revision RAMLink? ----------- Category 12, Topic 2 Message 33 Thu Dec 08, 1994 D.BOBER [RENTaLASER] at 20:16 EST People usually post questions about problems with their RamLink here. But this post is different... I purchased my RamLink last November. Sure, I had some questions, but I never had a problem with installation of RamLink or with RamLink itself. It has performed flawlessly! It IS a well designed and manufactured device! (I know, I have had it apart to install the Real Time Clock.) I have not had any corupted, or lost partitions due to power failers. Thanks CMD for a Great Product and Great support on GEnie. Douglas :) ------------ Category 12, Topic 2 Message 34 Thu Dec 08, 1994 CMD-DOUG at 20:33 EST Thanks, Douglas! I know that everyone here at CMD will be pleased to see you're happy with your purchase. I'll be sure to print your message out and post it on our bulletin board in the office... Heh, and you tell folks that few folks get their own area in CMD's offices, but that you did! ;) ------------ Category 12, Topic 2 Message 35 Thu Dec 08, 1994 D.BELTER at 22:46 EST Thanx Doug, I figured out the problem when my REU wouldn't work! I bent the connection on the Cart port and everything is FINE now! I guess it true there are noever Dumb question only dumb answers, but this one came close! Also the Ramlink worked fine at the Club Help meeting tonight, so it HAD to be the connection or the computer, I checked the easiest one first. ;) ------------ Category 12, Topic 2 Message 36 Fri Dec 09, 1994 H.HERMAN1 at 04:36 EST Doug, The RAMLink was originally a Rev. D, and then upgraded to Rev. G. Later it was upgraded with The RAMCard II upgrade Kit. Then, CMD upgraded RAMLink to Rev I, which is what it is today, with ver. 2.01 DOS. In the past, when I checked the 2 unconnected batteries, I would get 6+ volts. But that was sometime ago. oh! One more thought: A few months ago I was testing a program that corrupted the partition 2. (There are about 19 partitions.) Only partition 2 seemed to be affected: directories appeared and disappeared at random. I finally nuked all its directores, and files, did a validate on the empty partition, and re-made its directories. None of the other partitions were affected, and #2 was fine after that. (I did not delete the partition, so it remained in its 3rd partition position.) The reason I mention this, is that I found it unique that altho RL appeared to reinitialize into its two default partitions, the RTC kept perfect time/dating. Howie ------------ Category 12, Topic 2 Message 37 Fri Dec 09, 1994 CMD-DOUG at 21:36 EST Howie, Nothing so odd about the clock maintaining - it has its own power source. As to the problem, it could be any of a number of things. But you might want to check out that zener diode that was mentioned in a post quite some time back - ZNR1, which is a 1N5232. I don't think Radio Shack carries them, though, so I don't know if you have a source to try replacing it. If it isn't that, I wouldn't want to advise you further other than saying you should probably have it gone through by us. ------------ Category 12, Topic 2 Message 38 Sun Dec 11, 1994 H.HERMAN1 at 00:33 EST Thanks Doug! I'll call Monday to arrange for the RL to get a full check-over. I also wanted to get some custom changes, for SwiftLink/REU simultaneous use, and hopefully can arrange for this at the same time. Howie ------------ Category 12, Topic 2 Message 39 Tue Dec 13, 1994 D.BELTER at 07:04 EST I wasn't to sure were to put this but it only does this on my Ramlink, when I use a OPEN15,16,15,"u;" (works better than a U: on a 1541), the border color changes, in 128 mode 80 col it locks up and 40 col mode it breaks into the Monitor. (I got the info on the U; from Inside C= Dos). It just strange, just wonder if there were other weird bugs out there when using the RamLink. ------------ Category 12, Topic 2 Message 40 Wed Dec 14, 1994 CMD-DOUG at 01:15 EST I don't believe that RAMLink supports the semi-colon, since it isn't the real command syntax. It works on some 1541's only due to the way the code falls through. ------------ Category 12, Topic 2 Message 41 Thu Dec 15, 1994 D.BELTER at 22:55 EST Atleast I have found 'U;' to work on ALL 1541, if you use a standard OPEN command. I can only get 'U:' to work on a 1541 if I use SERIAL command from ML. I was just strange that the command would change the Border color. I haven't used 'U;' in along time, U9 does the same thing and work better. BTW 'U;' works ok with JiffyDos from a 1541, 1571 or FD2000, since my Catalog program uses it to figure out what type of drive is there. ------------ Category 12, Topic 2 Message 42 Thu Dec 15, 1994 M.RANDALL2 [Maurice] at 23:40 EST Dave, you might want to reconsider using the 'U:' command within a program, unless only you will be using the program. If you take a chance on resetting the drive, you might hang the system. Let's assume that someone with a CMD drive has pressed the swap button and you reset the drive that it has swapped with. Well, that drive will now be numbered the same as the drive with the swap button. Just thought I might pass this little reminder. ------------ Category 12, Topic 2 Message 43 Thu Dec 15, 1994 CMD-DOUG at 23:54 EST Well, you have to consider what RAMLink is before thinking it odd that the screen color could change when sending an unimplemented value with a disk command to RAMLink. Normally when you send a command to a disk drive, you're sending it to a device which is an entity unto itself. RAMLink, on the other hand, houses not only the 'drive' OS, but also the computer's OS. When an unsupported value isn't trapped for some reason, you can fall through to a routine that is part of the computer's OS, rather than falling through to some other routine in the drive OS. ------------ Category 12, Topic 2 Message 44 Fri Dec 16, 1994 M.RANDALL2 [Maurice] at 18:47 EST FINDING THE DIRECTORY While on this subject of identifying drives, there are several ways of doing so. I just thought I would pass this little method along to anyone that might be interested. Here is a small program to demonstrate it: 10 INPUT"DRIVE NUMBER";DN 15 : 20 OPEN15,DN,15,"LG" 30 INPUT#15,DT:IF DT=6 THEN 90 40 PRINT#15,"I0" 50 OPEN 2,DN,2,"$0:" 60 PRINT#15,"B-P";2;0 70 GET#2,DT$ 80 DT=ASC(DT$+CHR$(0)) 90 CLOSE2:CLOSE15 190 : 200 L=0 210 READ T,T$:IF DT=T THEN 250 220 L=L+1:IF L<6 THEN 210 230 READ T$ 250 PRINT T$:END 290 : 300 DATA 1,"CMD-NATIVE" 310 DATA 18,"1541/1571/2031/2040/4040/MSD 320 DATA 38,"SFD-1001/8050/8250" 330 DATA 40,"1581" 340 DATA 76,"D9060/D9090" 350 DATA 6,"LT.KERNAL" 360 DATA "DRIVE NOT SUPPORTED" The first part, line 10, just interrogates the user for a device number. The next section, lines 20-90, interrogates the drive for identification. Then lines 200-250 loop through the data statements and print the drive type to the screen. Here is a more detailed explanation: To start with, we need to weed out the Lt.Kernal hard drive, since it is the only one that won't work with this method. But it is also the only one that will accept the "LG" command. If this is a Lt.Kernal, then the first byte from the error channel will be a 6. We immediately jump through to the rest of the program if so. Since the "LG" command may have messed with any other drive type, line 40 will now initialize the drive. Of course, this step is needed in many cases anyway. I found that some drives when first turned on will need to be initialized for this method to work. Now, we will open the directory for reading in line 50. Notice that we are using the short method ($0:) to open the directory. This will not waste time reading any more of the directory than is necessary. And normally, you might use a secondary address of 0 to open the directory, but for our purpose, we want to read the directory a little differently, so we use a secondary address, or channel, of 2. If we were going to read the whole directory, then this would bring in every byte of the directory. On some drives, it will also read in the directory header and/or bam blocks, but I've found that there is no consistency of this between the drives. Now, line 60 is the real trick, and the heart of the program. We are going to set the buffer pointer in the drive. Setting the buffer pointer is normally done only if you open a buffer for direct access, which we haven't done. But since we are supplying the channel number here (2) that was used with the opening of the directory, the drive will actually set the buffer pointer where we want it to be. We are pointing to byte zero, the first byte in the buffer. But we only get one shot at it. We are only concerned with the first byte anyway. That is the only byte we need to read. In line 70, we can read this byte. If we attempt to read anymore bytes, the drive will only give us carriage returns since we did something out of the ordinary here. Line 80 merely puts the byte into the variable DT. We will use it to compare with our data statements. And then line 90 closes the files that we have opened. Beginning with line 200, we can now loop through the data statements and look for a match to DT. If we find a match, then the next data statement will be the one that the program will display to the screen. If no match is found, or if a disk was not in the drive, then "DRIVE NOT SUPPORTED" will be displayed. What happens when we read that first byte in this fashion, is that we are either getting the track number of the second bam block, or the track number of the first or second directory block, depending on the drive. Either way, we now know where the directory can be found. This doesn't tell us the exact kind of drive, but it let's us figure out where the directory is. For instance, a CMD-HD will return the same value in a 1541 partition as an old 4040 dual drive will. They will both give us a value of 18. Knowing this, the directory can be found at the following locations: CMD-NATIVE Track 1, Sector 34 (value returned 1) 1541/1571/2031/2040/4040/MSD Track 18, Sector 1 (value returned 18) SFD-1001/8050/8250 Track 39, Sector 1 (value returned 38, not 39) 1581 track 40, sector 3 (value returned 40) D9060/D9090 Track 76, Sector 10 (value returned 76) LT.KERNAL (who cares, too hard to work with the directory anyway) If within your program you didn't care to support the Lt.Kernal, a quick GOSUB to the following subroutine would return with DT holding a value that could be used to determine the location of the directory: 5000 OPEN15,DN,15,"I0" 5010 OPEN 2,DN,2,"$0:" 5020 PRINT#15,"B-P";2;0 5030 GET#2,DT$:DT=ASC(DT$+CHR$(0)) 5050 CLOSE2:CLOSE15:RETURN If the drive contains one of the supported directories, then DT will now hold one of the following values: 1,18,38,40,76 Any other value would indicate an unsupported drive or a missing or unformatted disk. True there is a better method of identifying the exact drive type by doing a memory read of the drive at certain locations within the drive's operating system, but that requires several reads on each drive until a recognizable match is found. If we are only concerned with the directory blocks, then this method explained here works fine. We can now access the directory by reading whole blocks at a time. If the drive does not have a formatted disk in it, then this method will fail, but if there is no directory to work with, it wouldn't matter anyway. The program could display an error message as such. In fact, the example here will give the 'DRIVE NOT SUPPORTED' message if there is no disk in the drive. The use of this identification method all depends on the type of program that is intended. - Maurice Randall ------------ Category 12, Topic 2 Message 45 Sat Dec 17, 1994 D.BELTER at 06:57 EST Maurice, the only real program I use the reset with is my Cataloging program and you wouldn't need to swap drives. Since it searchs for any active drives. Doug, thanx for the explaintion, I was just wondering, since it made a glitch in my program and it took me about hour before I realized it was the reset command. I should re-upload my Cataloging program since if you a Ramlink, it will change the border color, I wonder how many people use my program? I know quite a few in my local club do. One other thing, Maurice, my I use your drive program you just posted? It would most likey simpify my section of code!! ------------ Category 12, Topic 2 Message 46 Sat Dec 17, 1994 L.VICTORY [LURCH] at 12:57 EST Doug, I have a problem with my RAMLink and C128D. I believe the problem has been instigated by me. I have a C128D w/JiffyDOS, 1571 w/JiffyDOS, 1541ii w/JiffyDOS and RAMLink with 2 megs. Using Swiftlink. The computer has switches on the front panel for switching between CBMDOS and renumbering the drive. I did switch out the JiffyDOS on the 128 when I was using the RAMLink. At least, I thought I had and that is part of the problem(s). I powered up my computer a couple weeks ago when I got home from work not looking or thinking about my switch setting for JiffyDOS. Well, a few days later the 128 started resetting by itself from 64 mode to 128 mode. Then it started getting just garbage on the screen a few hours after the resetting occurred. I noticed at the time that my 4 year old son had realigned my JiffyDOS switch on the 128, so it was on the same time as the RAMLink. Also, in scanning the BB on GEnie, I was reminded about the timing jumper which I had forgotten to transfer when I got the 128. I had been using the RAMLink on a 64 previously. I took the timing jumper out of the 64 and installed it in the RAMLink all to no avail. The system still resets. It works find without the RAMLink installed. I checked my connections twice, battery, ac, user port (computer and RL) still got the problem. So, make my day and tell me you can send me a chip that will replace one in the RAMLink and everything will be back to normal. Sure!! Now, realistically, what do you think I've done and what are the options? I never lost any memory in the RAMLink through all this which I consider a BIG PLUS! Waiting for your reply, Larry Victory (LURCH) P.S. I hadn't lost any memory unintentionally I mean, otherwise, you would want me to return that RAMLink and I'd never see it again :D. From reading previous posts, my problem seems similar to MR. Belter'S. Lurch ------------ Category 12, Topic 2 Message 47 Sat Dec 17, 1994 CMD-DOUG at 13:13 EST Lurch... if you haven't tried doing a ZAP SYSTEM, then give that a shot. Also, be sure to check all connections. Reset problems are usually due to bad connections. There's a very good chance, btw, that having the JiffyDOS switched on with RAMLink has nothing to do this problem starting to occur; odds are it's just a coincidence. But the ZAP SYSTEM should clear all the system RAM, giving no doubt that they are unrelated if the problem persists after that. If after checking all connections the problem persists, odds are it's time for the unit to be checked out at CMD. ------------ Category 12, Topic 2 Message 48 Sat Dec 17, 1994 M.RANDALL2 [Maurice] at 13:58 EST