8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / 01RTCMMS.SFX / 02rtcm.msgs next >

Wrap

Text File | 1990-02-12 | 31.7 KB | 621 lines

************ Topic 18 Thu Feb 11, 1993 CBM-MARK (Forwarded) Sub: RTC Master -> Looking for help! A place to ask for help with RTC Master. 181 message(s) total. ************ ------------ Category 8, Topic 18 Message 81 Wed May 31, 1995 B.GANN1 [Brenda] at 21:56 EDT Sorry for the delay in answering... I just got a second job (among other things.) BG> download from GEnie with RTCM to the RL, it dropped to the BG> monitor EB>> I have a few questions to ask about it.... I'm not sure where topic overlap is in this so I'm going to consider this a grey area. - What protocol - what File - what is your RTCM setup - how much room in your partition/directory Well, I was assuming it was not RTMC because I just got the RL set up. Of course, now I don't remember what protocal, etc. EB>> Anything else you can provide... Also, to what address did it drop and into which bank? I didn't record the #. If anything happens again, I will be sure to get all the details. (I accidentally unplugged the RL and lost all that was on it. All it had on it was backups, so no prob.) Note that this is v 2.02 (I think) of RTCM, not #3. Brenda ------------ Category 8, Topic 18 Message 82 Wed May 31, 1995 E.GBELL [e.g.bell] at 22:56 EDT John: JB> screen blanks, but not completely. The light bar below the JB> status bar and above the user input window stays lit John: I'm using standard VDC registers to do the blanking. The blanking is supposed to be a horizontal blanking. You can blank portions of the screen, but only to the right or left of the blanked portion, not on the top or the bottom of it. Does this happen every time or just on occasion? Is there anything peculiar about the D that I don't know? Brenda: BG> the delay in answering... I just got a second job (among other BG> things.) No problem. I've had a lot going on around here as well. Last week and weekend were VERY hectic. BG> assuming it was not RTMC because I just got the RL set up We discussed this a few messages ago, and I'm taking the position that it is NOT RTCMaster because the breaks have consistently been to memory configuration that is an external ROM configuration, not one that RTCM would use. RTCM uses only configs 0, 63, 127, and 14 for its operations. There are simply no other configs used by RTCM. In order for it to BRK in another config, it would have to be put there by something else, in this case, an external ROM, RamLink. I have been meaning to contact Mark Fellows, but will do it from work where it is not an LD call for me. However, with my wife's frequent false labor and the real thing last Saturday, I have not been able to devote the time to making the call. It is on my to-do list for next week when I'm back from vacation. I have been taking (or feeling like I've been taking) the heat regularly for problems with the RamLink, but have found more and more that there are some warts that it has... not that my code will ever be perfect... just that I need more information so that everyone's warts are addressed, not just mine.... here are some of the things discussed that I need information for.... Doug has suggested that this problem involves interrupts. However, all interrupts I have ever seen start out by storing, among other things, the memory configuration, then restoring it on exit. My code does this. Stray NMIs. Perhaps, tho my code disables them before DOS operations. And on the SwiftLink, that is even easier than on user port modems, involving basically only a 'POKE'. The problem John had involved calling clock routines with no clock installed. Regardless of what is supposed to happen, this causes a bRK to monitor, again to config 8. The TRAP function is set up, but is circumvented somehow. go figure. Here is one that I found that no one else has gotten bitten by as yet, but which I've had confirmed elsewhere (by David Schmoll, one of the wunderkinds mentioned in the last C=W)... when you try to save a file to a RamLink partition that does not have room for the file, you will not only get a splat file, you will hang the computer... and the kicker is that this works from RTCMaster, the BASIC interpreter, or the machine language monitor. I really have to take the position that these things are not my problems, but which I have to find some way to deal with because they affect my program. I don't think it is only my program. However, my problem is that there is virtually no programming information on the machine language level... no examples, no rom maps, nothing. NMIs, which are frequently pointed to as culprits, are not dealt with in any measure in the RL manual. What I would like to see is an extensive article in C=World by someone who REALLY WON'T PULL PUNCHES dealing with the bad as well as the good. The last article I saw where an author said he wasn't going to pull punches was glaringly absent of punches. Problems are not a bad thing, and definitely not something that would keep anyone from buying something. The Intel reaction, however, is something else. We programmers need more information tho... much more than has been published to date. The most important thing to note in even of BRK, Brenda, is the config and address of the monitor. The config is the first byte, the address is the other 4 bytes. Anything starting with an 8 is RamLink code. Anything else is probably mine. ------------ Category 8, Topic 18 Message 83 Sun Jun 04, 1995 CMD-DOUG at 16:23 EDT > We discussed this a few messages ago, and I'm taking the position that it > is NOT RTCMaster because the breaks have consistently been to memory > configuration that is an external ROM configuration, not one that RTCM > would use. RTCM uses only configs 0, 63, 127, and 14 for its operations. > There are simply no other configs used by RTCM. In order for it to BRK > in another config, it would have to be put there by something else, in > this case, an external ROM, RamLink. RAMLink banks into its own memory configuration only whenever a Kernal routine involving disk access is utilized. If an NMI occurs while this configuration is in effect, execution immediately jumps to the address pointed to by the NMI vector. Now, we know that, in your case, the NMI vector must be pointing to somewhere other than the $FF05 address that is the norm, since you're using a custom NMI handler. Obviously, it must be in 'common' RAM, or you'd possibly have problems without a RAMLink as well as with one. So, let's assume that you get to your custom NMI handler okay at this point, and like the Kernal NMI handler, it first stores all important info away. > Doug has suggested that this problem involves interrupts. However, all > interrupts I have ever seen start out by storing, among other things, > the memory configuration, then restoring it on exit. My code does this. Okay, so now you've got the bank 8 configuration stored away since you RAMLink was interrupted during one of the short spells in which it wasn't napping. You proceed to process your NMI, restore the bank 8 configuration, and return from the interrupt... but the DOS ROM sub-segment within RAMLink that was executing when the NMI occurred is no longer in the memory map, so the processor executes garbage until it runs into a break (zero byte). You see, you can't bring certain portions of RAMLink back just by returning from your interrupt. RAMLink has several ROM sub-segments which can only be brought back through special routines. How? Irrelevant. The NMI NEVER SHOULD HAVE OCCURED IN THE FIRST PLACE, so that needs to be fixed. Don't treat the symptom... cure the problem that caused it. You can call this a 'quirk' of RAMLink if you like, but the simple fact is that RAMLink is enforcing a rule that you might otherwise get away with breaking--no interrupts of any type are allowed during serial bus access--a long-standing rule in Commodore programming. Now, you could argue that NMI's aren't occuring during serial bus access in your code, and ask what can cause RAMLink itself to break from within bank 8. Frankly, short of a hardware problem (bad RAMLink, bad computer, both a bad RAMLink and a bad computer, bad connections betweem the RAMLink and the computer, or improper timing relationship between RAMLink and the computer) that's pretty much it. There are no other documented causes for such a break. Furthermore, this situation has been encountered by at least 3 or 4 programmer's before you--all doing the same thing: trying to get custom RS-232 routines going for the 128 with a RAMLink attached. Those who have solved it have done so by heeding the same advice I've given you: make sure that not a single NMI can occur during serial bus routines. Brian Bell is due in an RTC in a couple of days; ask him about it, he's one of those who has successfully gotten around this problem. How did he do it? He set up his own vectors for every Kernal routine that performs serial bus access, and made sure that each of these ran through a routine to kill the NMI's before moving on to execute thier normal funtions. Some of of the non-vectored routines had to be dealt with as exceptions, like BLOAD and BSAVE (all according to Brian). > I have been taking (or feeling like I've been taking) the heat regularly > for problems with the RamLink, but have found more and more that there > are some warts that it has... not that my code will ever be perfect... > just that I need more information so that everyone's warts are addressed, > not just mine.... here are some of the things discussed that I need > information for.... > The problem John had involved calling clock routines with no clock > installed. Regardless of what is supposed to happen, this causes a > bRK to monitor, again to config 8. The TRAP function is set up, but > is circumvented somehow. go figure. TRAP only redirects program execution via BASIC's error handler. The problem isn't a BASIC error, so TRAP isn't going to catch it. Here again, the only possible causes are as outlined above. I'd try doing that POKE you have to disable SwiftLink NMI's prior to starting your drive routines in the loader. Whether you turned them on or not is moot--you don't know the state of things when this program starts, so shut them down to be safe. If that doesn't cure JBEE's problem, then there may be a hardware problem specific to JBEE's system. > Here is one that I found that no one else has gotten bitten by as yet, > but which I've had confirmed elsewhere (by David Schmoll, one of the > wunderkinds mentioned in the last C=W)... when you try to save a file > to a RamLink partition that does not have room for the file, you will > not only get a splat file, you will hang the computer... and the kicker > is that this works from RTCMaster, the BASIC interpreter, or the machine > language monitor. I just saved a 60 block file to a 1581 partition on my RAMLink that had only 58 blocks free. I got a splat file, but my system didn't lock up. So apparently, creating the problem is either more involved than you indicate, or is possibly caused by either a hardware problem or an old DOS revision. I also created a small BASIC program to write a SEQ file, which continues to write until the disk is full. It does this by checking the status byte after each byte is written, and when status comes up with -128, it closes the file. Of course, the status can't come up with this value until there's no more room left on the disk, so you're stuck with a splat file at this point. There's only one way that I know of that can be used to avoid splat files altogether-- check the blocks free before you start your file, then count the bytes as you write them. Regardless, I didn't experience a single lock-up in testing these routines repeatedly. > I really have to take the position that these things are not my problems, > but which I have to find some way to deal with because they affect my > program. I don't think it is only my program. You're free to take whatever position you wish, but the symptoms fit the situation that I have repeatedly outlined to you, that NMI's are occuring while RAMLink is operating it's DOS routines. And it's up to your program to see that this doesn't happen. > However, my problem is that there is virtually no programming information > on the machine language level... no examples, no rom maps, nothing. NMIs, > which are frequently pointed to as culprits, are not dealt with in any > measure in the RL manual. Not that any of this would help you resolve your problem. You'd simply have a few thousand more pages of information to look through to try and find some reason for a problem that can be solved by doing what I've been telling you to do. This isn't a RAMLink-specific coding problem, either--it's a problem with coding custom NMI's to avoid problems with serial bus access. It's just that the nature of the way RAMLink works will make such problems in code show up more readily. Most problems that pop up with programs while using our devices tend to be related to doing things which a programmer should not be doing with any device. Programmers assume, however, that because they get away with doing something on a stock system that their code can't possibly be doing anything wrong. It's sort of like assuming that because you've never gotten a ticket while speeding on a road that the police don't watch that you shouldn't get a ticket for doing so on a road that they do watch. I've written routines myself in the past where I got away without clearing the status byte when it should have been cleared, and I've seen routines that have gotten away with calling some of the Kernal serial routines out of order; but eventually these routines will usually break on someone's equipment or setup. If you correctly follow the general rules of programming for Commodore devices, you really shouldn't run into problems with RAMLink or our other products. So what you're asking for--whether you realize it or not--is for RAMLink's manual to become a general reference on how to program with Commodore devices in general. That's well beyond the scope of a manual which already goes FAR BEYOND what any of Commodore's own device manuals did in covering the device itself. Not to mention that the additional information would be useful to probably less than 1 pecent of those who buy the product. Supplying ROM maps, or more advanced information on how RAMLink operates gets into proprietary information, or in some lesser cases, information we'd rather not see utilized (i.e., locations of routines which move from one version of the DOS to the next). We have provided specific programmer's with additional information in such case where they have been able to prove they have a true need for it, and will continue to do so. Your situation doesn't qualify for such a requirement... you're doing things that others have accomplished with no more information than what we have provided you with. > What I would like to see is an extensive article in C=World by someone > who REALLY WON'T PULL PUNCHES dealing with the bad as well as the good. I'd like to see one person who can define just what such an article is to cover. Specifically. If it can't be defined, it can't be written. Once it's defined, who's qualified to write it? Who decides what's good and bad? It sounds to me like what you would want would be far beyond the knowledge of any single writer I'm aquainted with. Even Mark, who engineered the product, couldn't say specifically what will occur and why under every possible programming or hardware situation without testing and studying the code. > The last article I saw where an author said he wasn't going to pull > punches was glaringly absent of punches. Articles for CW aren't edited to remove information about problems with products--ours or anyone else's. We don't instruct our writers to avoid talking about problems, nor do we tell them to give our products preference over others. We would not, however, print an article which claims a problem without verified proof that such a problem really exists and that it isn't an attribute of using or programming the product incorrectly. Apparently the author of whatever article you're referring to simply didn't find much in the way of bad things to say. > Problems are not a bad thing, and definitely not something that would keep > anyone from buying something. The Intel reaction, however, is something > else. We programmers need more information tho... much more than has been > published to date. Problems are a bad thing, and should be dealt with as quickly as possible. In the past, when someone could show us an example of code that should work on our device but didn't, we've moved as quickly as possible to locate and resolve the problem. There's nothing to indicate that this is one of those situations, though, based on what you're seeing and our past experiences with others trying to write the type of program you're working on. There's no 'Intel reaction' here. Intel knew of a problem with THEIR product which they simply didn't tell anyone about. From our standpoint, we're not talking about a problem with OUR product, but a problem with YOUR program. ------------ Category 8, Topic 18 Message 84 Sun Jun 04, 1995 E.GBELL [e.g.bell] at 19:25 EDT I don't know why, but I've been getting a lot of line noise in my mail lately... can't tell if it is in the message, or just in what I'm getting so if I'm missing anything in my replies, that is why.... now... DC> You proceed to process your NMI, restore the bank 8 DC> configuration, and return from the interrupt... but the DOS DC> ROM sub-segment within RAMLink that was executing when the DC> NMI occurred is no longer in the memory map, so the processor DC> executes garbage until it runs into a break (zero byte). You DC> see, you can't bring certain portions of RAMLink back just by DC> returning from your interrupt. RAMLink has several ROM DC> sub-segments which can only be brought back through special DC> routines. How? Irrelevant. The NMI NEVER SHOULD HAVE OCCURED DC> IN THE FIRST PLACE, so that needs to be fixed. Don't treat DC> the symptom... cure the problem that caused it Everything you are saying may be correct... but you are basing it all on the assumption that this is happening because of an errant NMI. In the case of the problem Brenda and Eddie mentioned about BRKs in the boot at the point of reading the clock, no such problem is possible and I'll tell you why... the custom handlers are not implemented... or at least let me say that in Eddie's case because Brenda is not using 3.00. I changed the call because I figured there was no reason for that handler to be in place by that time. Your whole point above seems to hinge on an NMI. I've shown you my code. The SL code is even easier to disable the interrupts because of the way it is done. DC> RAMLink is enforcing a rule that you might otherwise get away DC> with breaking--no interrupts of any type are allowed during DC> serial bus access--a long-standing rule in Commodore DC> programming. Agreed that they should be disabled.... IFF that is the problem here. I'm no longer convinced that it is... and it seems odd that RamLink is enforcing a rule like that by BRKing to monitor. I have seen other users here mention the same thing... wasn't another one somethng to do with a color or something. It is in the BB here... just can't remember where. No NMIs there. Just something that a user was doing that the RL did not anticipate. It seems to me that that kind of response from ANY hardware is kind of extreme. As you point out, it is practice to disable the NMIs during DOS access, but the 128 doesn't BRK to monitor if you do that with a user port handler... the data gets corrupted if anything. DC> Frankly, short of a hardware problem (bad RAMLink, bad DC> computer, both a bad RAMLink and a bad computer, bad DC> connections betweem the RAMLink and the computer, or improper DC> timing relationship between RAMLink and the computer) that's DC> pretty much it Agreed! Which would also explain why it happens to some people and not to others... namely me. And that is what makes me VERY frustrated. I can't duplicate it EVER, which is also why I'm disinclined to jump on the NMI thing. DC> trying to get custom RS-232 routines going for the 128 with a DC> RAMLink attached. Those who have solved it have done so by DC> heeding the same advice I've given you: make sure that not a DC> single NMI can occur during serial bus routines I'm inclined to agree to a point on this too.... again, it assumes that your advice covers the whole problem. In that I remain unconvinced because the problem is not consistent across 128s. And the routines work in the Commodore operating system without complaint... I put this before everyone as evidence that I've followed proper programming techniques. And btw, rather than going after vectors, I made front ends for the kernal routines that disable the NMIs and then proceed through their normal JMP addresses. And for the record I don't object to adding code to make the RamLink happy. I am just frustrated that, no matter who we say things, the RamLink introduces special concerns above and beyond what the C128 operating system does... and that these cannot be salved by merely working to handle the C128 normally. If they could, this would not be an issue. DC> creating the problem is either more involved than you indicate, DC> or is possibly caused by either a hardware problem or an old DC> DOS revision. Probably right.... but it is a problem that has been experienced by more than me... and my point is, and was, that things like this, which I consider a quirk, cause a LOT of time and frustration dealing with things that are plainly not predictable... and that is why I have to pause and think about what else is afoot when I run into problems like Eddie and Brenda and John. DC> doing things which a programmer should not be doing with any DC> device. Programmers assume, however, that because they get DC> away with doing something on a stock system that their code DC> can't possibly be doing anything wrong DC> we're not talking about a problem with OUR product, but a DC> problem with YOUR program. That is what they said about the save with replace bug for years... and I've seen the flippant 'your program is not handling error messages gracefully' replies over the years. But saying it don't make it so. The best way, I guess, to make a product look perfect is to minimize the hard complaints to programmers who bend the rules. But you may find that cuts a wide swath. As I said before, Dave Schmoll has confirmed my observations about the RamLink in the lock up and the format. Your product is good... it is NOT PERFECT. Saying so don't make it so. I'm sure your reviewers will continue to see little negative with your products as long as the checks are signed promptly. There are negatives, just like with every other product ever released. You can harp about how any faults are someone else's fault. The fact that there are considerations above those with a normal 128 say to me, at least, that a programmer needs to give closer consideration to the thing. You seem to be saying that your device is more commodore compatible than Commodore... hmmmmmmmmm! I'm not going to jump through any more hoops to make things happy together.... if you want to say I'm cheating or cutting corners or doing whatever it is you say I'm doing, fine. I'm willing to do whatever it is I have to do to make things work, but I have heard these generalities before. Just for curiosity, does Brian Bell have a term program or just a BBS? Seems to me that fewer people run BBS programs than term programs, let alone one specific BBS. I suppose we can take it as a matter of faith that he has indeed solved all of this. I don't have as much at stake, Doug, in what I'm saying. I'm not making anything on what I'm doing. And there are definitely others who are having the same experiences... in programs with no NMIs. I'm willing to let people judge for themselves. I said before... the RamLink is a good product.... It is not perfect tho. ------------ Category 8, Topic 18 Message 85 Sun Jun 04, 1995 M.RANDALL2 [Maurice] at 22:13 EDT Ed, I don't know if any of this would pertain to your situation, but here is partially how I implemented NMI interrupts within geoFAX: After determining the machine that it is running on, 64 or 128, I set up the NMI vector AND the jump address in the jump table at $FFFA. I had to do some fancy stuff to make this work in GEOS because the disk drivers screw up the NMI interrupt vector whenever InitForIO is called. InitForIO gets the machine out of GEOS mode and sort of into a mode with the Commodore Kernal visible. On the 128, it doesn't really make the Kernal visible, but it will allow the jump table to be utilized. On the 64, it was pretty easy. I just pointed the vector to my custom NMI routine and also put this same address into $FFFA. Keep in mind that the address that $FFFA is pointing at on the 64 works differently than the way it works on the 128. On the 64, it jumps through the vector at $0318 and then back into the kernal routine at which time it saves the a, x, and y registers and continues it's other stuff. On the 128, it saves the a, x, and y registers and THEN jumps through the vector at $0318 and then back into the kernal routine. On the 128, I change the ram locations at $FFFA in both bank 0 and bank 1 to point to my NMI routine. This routine saves the a, x, and y registers, calls my custom routine and then restores the a, x, and y registers. The vector at $0318, however, I point to a different routine that does not save the a, x, and y registers. The only way my NMI routines will get called from the vector is if an NMI occurs while the kernal ROM is switched in. This particular routine calls my custom NMI routines and then restores the a, x, and y registers. So, to recap, on a 128, there are 3 copies of the addresses that are stored at $FFFA. One in bank 0, one in bank 1, and one in the ROM. On a RamLink equipped machine, there is also one in the RamLink ROM. Whenever a ROM is switched in, the NMI will always go through the vector at $0318. Whenever RAM is switched in, you can control where the NMI goes by changing the value at $FFFA. This is how I had to do it with GEOS to keep the disk drivers from messing me up too bad. I still have to keep a watch on the vector at $0318 since they mess with that, but while GEOS is running, most of the time RAM is switched in. I'm sure that you already know most of this stuff, but it might help other programmers that haven't yet gotten into this sort of thing. One other thing I had to do on the 128 was to make sure that a copy of my interrupt handler was in both bank 0 and bank 1. I wanted to make sure that no matter what configuration the machine was in when an NMI occured, that the routine would be accessed. Otherwise, it would just go off into never, never land. -Maurice ------------ Category 8, Topic 18 Message 86 Sun Jun 04, 1995 CMD-DOUG at 22:32 EDT That's all well and good, Ed, but if you go back and look at what I said, we've covered everything that we know of that can cause those breaks... NMI's during RAMLink DOS access, or hardware problems. Now, if these folks can run something that's pretty hardware intensive (RAMLink-wise) like GEOS for example, it's a fair bet that their hardware is working pretty well. I'm all for finding a solution to your problem, but I've got a sneaking suspicion that it isn't hardware problems for this many folks. For the record, btw, Brian had well over 100 systems in use last I knew, and a large number of those are running SwiftLink/RAMLink combos. These systems run 24 hours a day, 7 days a week for the most part--that's pretty effective testing in my opinion. When a problem does indeed exist with NMI's occurring when they shouldn't, it won't show up on every system. No-one at CMD has weeks to devote to studying why that is, but we can only assume that it is likely due to a large number of variables that can affect the relationship between when NMI's and DOS accesses occur. I would assume, however, that if you varied the baud rate enough, you should be able to get it to happen at some point on any system if the problem does exist. Concerning David Schmoll's confirmation of the lock-up problem, it's basically meaningless. I've tested for the stated problem, and it doesn't exist, at least on a RAMLink running the current DOS. I can't speak for older DOS revisions, because we do indeed fix problems when we can verify them, and recommend that anyone who is experiencing problems have their RAMLink upgraded and checked out. We can't fix problems that can't be reproduced on our systems (and we have quite a few), and have to assume that such problems in the field mean either old version problems or bad hardware. ------------ Category 8, Topic 18 Message 87 Sun Jun 04, 1995 B.MASSE [BIG BOB] at 22:34 EDT >So far as I know, geoCalc should work >fine with RAMLink. I just have problems with the 128 versions. But I think it goes to argument that the RamLink can have it's own personality and be a bit finnicky when confronted with a program that It doesn't like. Could be the Dos changes that have been implemented over the years to upgrade the Ramlink or even a dirty pin somewhere on the board. 99 percent compatibility is still quite impressive in my book. Thanks for the response Doug. Bob :) ------------ Category 8, Topic 18 Message 88 Sun Jun 04, 1995 B.MASSE [BIG BOB] (Forwarded) I do agree with Ed about the Ramlink. My Ramlink will work flawlessly with any program I own except when I load GeoSpell or GeoCalc it has always choked. Three different copies of GeoCalc/Geospell and three different 128's. Always the same problem. Go Figure... Bob ------------ Category 8, Topic 18 Message 89 Sun Jun 04, 1995 CMD-DOUG (Forwarded) With all due respect, Bob, it's very likely that those problems are also due to how the programs were programmed. So far as I know, geoCalc should work fine with RAMLink. But I am aware that geoSpell has problems, and we suspect that those problems are indeed due to the way it was programmed, and that there is code in geoSpell that was written with specific devices which were known to work with GEOS at the time it was written. It's something like the Super Debugger for geoProgrammer, which assumes that RAM expansion means a Commdore REU. Won't work with a GEORAM, won't work a RAMLink, won't work with anything but a Commodore REU or 100% clone. Some of the folks who programmed for BSW, especially early on, had a real bad habit of breaking their own rules when they found it convenient to do so. Programs will indeed break if they aren't written generically. RAMLink isn't a Commodore REU, and it isn't a Commodore 1541. GEOS programs that adhere strictly to using standard GEOS routine calls won't break on a RAMLink. ------------ Category 8, Topic 18 Message 90 Sun Jun 04, 1995 B.MASSE [BIG BOB] (Forwarded) >So far as I know, geoCalc should work >fine with RAMLink. I just have problems with the 128 versions. But I think it goes to argument that the RamLink can have it's own personality and be a bit finnicky when confronted with a program that It doesn't like. Could be the Dos changes that have been implemented over the years to upgrade the Ramlink or even a dirty pin somewhere on the board. 99 percent compatibility is still quite impressive in my book. Thanks for the response Doug. Bob :) ------------