8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / 01RTCMMS.SFX / 03rtcm.msgs < prev

Wrap

Text File | 1990-02-12 | 40.5 KB | 902 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 91 Sun Jun 04, 1995 B.MASSE [BIG BOB] (Forwarded) Whoops! This should have been posted in topic 18 of this cat. sorry. Someone who know how, please delete this.... (the message before this one, also). Bob :) ------------ Category 8, Topic 18 Message 92 Sun Jun 04, 1995 CMD-DOUG at 23:04 EDT Here's one thought for how you can test for the problem, Ed. When your NMI handler grabs the bank number to store it, do a compare to see if it's an 8. If it is, do something to indicate this to the tester, like print a message. If the code still breaks but the message doesn't print, then I'm wrong about the NMI. If the message prints, we know that an NMI is sneaking through somewhere. If the message doesn't print and the code no longer breaks, then odds are still that it was an NMI problem, but the relationship between NMI's and DOS access was shifted enough by the addition of the added code in your handler to avoid the problem. The only other test I can think of would be far more involved, and that would be to do away with custom NMI's altogether. That method would have to start by making sure that stock NMI's were in effect before any DOS access was to occur as well, since a 128 could have been previously running a program with custom NMI's, and the vectors only get reset if the user starts from a machine that has been turnedoff--not simply reset. But rewriting a program of the size of RTCM to use stock RS-232 would be no simple matter, so I don't expect this is a method you'd want to try. ------------ Category 8, Topic 18 Message 93 Mon Jun 05, 1995 C128.JBEE at 09:50 EDT BTW: I have just tested my hardware, removed my Egads ROM, hooked up RamLink and tried again with the same results. Though, this time when I tried a SW1571 (1571 clone) and put it into C-64 mode with U0>M0 I was able to copy a few files to the RamLink before it broke into the monitor. All other times it does not even make it past accessing the RamLink. My RamLink is device #10, my FD-4000 (I also tried a 1581) is #8, and I tried with the SW1571 as device #9. I have a SuperGold but I tried RTCM with the serial cable unplugged from the SW71. Remember, I have not even signed on-line yet while using the copier! Though I am wondering if the screen saver is causing some kind of problem with another routine because the VDC and CPU are tied together. I also tried RTCM as "is" without any of my defaults and noticed that the screen does not even blank, it just turns another color when the saver kicks in. So, on my C-128D the screen saver is not working, it just changes the screen to another color. I did not notice this because my background is yellow and my text is black. Though, I can see what looks like a raster line jumping all over the screen as a visible black line. The kicker is while posting this message, the screen saver kicked in while I was typing, it actually turned everything black, and I had to *x my message, save my buffer, and reset. I do know that all the VDC versions and the newer VDC in the C-128D, all have different default values on power-up for screen position, width, or length, amoung other things. What I would consider is something generic to blank the screen. Maybe turn attributes off save the background and foreground colors into a byte somewhere then set both the background and foreground to black. I think the fancier you get with the VDC, including pushing it with things as IPAINT, you are going to run into more problems when things are undocumented on exactly what changes where made to each VDC revision. Especially since the C-128D has a chip that is very different and from what I can tell of the tech topics, there is more glue and a different type buffer on the chip. I meant to ask Fred Bowen about that when he was here but forgot :P For what it is worth. ------------ Category 8, Topic 18 Message 94 Tue Jun 06, 1995 E.GBELL [e.g.bell] at 18:24 EDT Doug: DC> When your NMI handler grabs the bank number to store it, do a DC> compare to see if it's an 8. If it is, do something to DC> indicate this to the tester, like print a message. If the code DC> still breaks but the message doesn't print Now THAT is a good idea! I'm going to take a pass at that when I go on vacation at the end of the week. The hard part will be to find a way to wedge it in and keep it in because memory is so tapped, but I can maybe provide a PEEK to get the same info. I know Eddie and John and Brenda can do that. And if it fixes it, or identifies it, I'm more than willing to admit I'm a #%"$!%C!... o, speaking of #$%"A%$, I think the line noise I am seeing in your messages may be from you *uploading the text... just a guess. DC> rewriting a program of the size of RTCM to use stock RS-232 DC> would be no simple matter Actually, RTCM uses two handlers, one for the SwiftLink, or one for user port modems, to handle rs232. Rewriting it would not be necessary because all accesses are done via jump table to key routines... but it would probably choke on 2400 baud... I get kind of shaky tweaking the resident rs232 routines for more speed. That has always seemed to catch up to me in the protocols, among other places. John: JB> more problems when things are undocumented on exactly what JB> changes where made to each VDC revision. Especially since the JB> C-128D has a chip that is very different You have a point. I thought the scroll thing was the only thing that changed in the other version. Short of disabling the feature, I'm not sure how to dance around this problem tho! DC> can't fix problems that can't be reproduced on our systems (and DC> we have quite a few), and have to assume that such problems in DC> the field mean either old version problems o bad hardware. This is exactly what I've been saying, and I don't mean that as a finger pointing.... just that it is almost impossible to fix something I have not been able to duplicate. And I simply have not been able to duplicate any of the results, which makes the RamLink look VERY good here. Maurice: I have to study your post so I make sure I understand it. I am willing to try most anything. I don't have a lot of room, but I have always been able to find it when I needed it, even if it meant taking something else out. I do like Doug's debug idea tho... It would go a long way toward proving things one way or the other on neutral turf. Just for the record, BTW, all of my IRQ routines and NMI handlers are in common RAM. I set the config to 16K common for this very reason. Until I've read your message carefully, I'm not sure if that has any bearing on your suggestions... but if there is any chance they will help, I assure you I'll give them a try. Thanks all! ------------ Category 8, Topic 18 Message 95 Tue Jun 06, 1995 M.RANDALL2 [Maurice] at 20:43 EDT Ed, One of the things you might want to keep in mind is that even though you have your routines in 16K of common ram, there is no guarantee that this common ram is always in use. Who's to say that the RamLink ROM isn't setting up a special configuration when it excercises one of it's routines and then puts the configuration back when it is finished? If at all possible, I would consider trying to have a copy of your NMI routines in both bank 0 and bank 1 at the same addresses, just in case. Then if the NMI routine that is in the 'other' bank from the one that you normally use, you could recognize that fact and act on it accordingly. Just a suggestion. ------------ Category 8, Topic 18 Message 96 Tue Jun 06, 1995 C128.JBEE at 23:12 EDT set 8 reply 18 Ed, if you have room for the code, you could always throw the byte into a VIC register which someone could read from the monitor. As for the screen blanker, to blank the screen like I suggested takes about twenty bytes for the read and write. ------------ Category 8, Topic 18 Message 97 Thu Jun 08, 1995 B.GANN1 [Brenda] at 05:20 EDT Congrats on the new addition to the family! News on the RL... I downloaded a bunch of stuff the other day with no problems. (The RL was reconfigured though because I lost power.) I think I might have forgotten to say that I have a 9 meg RL, clock, and SwiftLink. Battery backup is not hooked up. Brenda ------------ Category 8, Topic 18 Message 98 Thu Jun 08, 1995 B.GANN1 [Brenda] at 05:22 EDT EB>> case of the problem Brenda and Eddie mentioned about BRKs in the boot a the point of reading the clock Uh, 'scuse me, but I don't think the clock was being read at the point my two BRKs occured. If I remember right, the first one happened when I tried to access the disk to load the quoter overlay as the screen was printing the log on menu. (The list of like, 15 topics.) The second time, it occured sometime during the download process. (But it did not start it at all, I do remember that.) I also got a BRK when I was testing with a computer that needed the timing clip. I'm not sure if that was what the first BRK was from or if I have had 3 BRKs. Sorry, I'm usually way more informative than this :/ Doug and Ed seem to be taking things a bit too personally. (Which I'm sure I would be doing too, if I was personally involved.) But hey guys, the BRKs might be a little of both, ya know? The more you boast how it can't possibly be -whatever-, the dumber you will feel if it turns out to be partly on "your" side ;) Brenda ------------ Category 8, Topic 18 Message 99 Fri Jun 09, 1995 E.GBELL [e.g.bell] at 18:29 EDT Maurice: Two things... First I went over and over your earlier post and could not figure out how what you discussed had any bearing on my problem... your second post may shed light on the link. However.... MR> RamLink ROM isn't setting up a special configuration when it MR> excercises one of it's routines and then puts the MR> configuration back when it is finished I would take it from everything that Doug has said to this point to indicate that this is not the case. Since the BRKs always occur in the BASIC ROM area, I believe, and my NMI routines are down below address 4096, I'm not inclined to think this is a possibility. It is interesting that you bring it up tho, because the very first versions of RTCM did just what you suggest, namely load the handlers to ram 0 and ram 1. It seemed redundant, tho, with the common RAM.... I do know that common ram is from RAM 0 tho. I'd be interested to hear what Doug has to say about the possibility of this happening tho.Dh * z m IIn addition, if what Doug has suspected is correct, the only proper solution is to disable them entirely.... which I believe I have done consistently. But for curiB # j Ad l 3 osity's sake, do you have a recommendation on what action should be taken if a routine finds itself executing in ram 1 instead of common RAM. I'm not even sure what all the ramifications of your suggestion are... my IRQ routines are also in that 16K common RAM. I uld also set up the BRK vector to point back to somewhere innocuous.... that moight be dumb tho... I'm just running things thru my mind... but if you are correct and RL is changing my common RAM setting, that scares me a little. Doug? Is this a possibility? Brenda: I'm willing to feel a little dumb... even very dumb.. and don't worry about more heat cuz it ain't gonna happen. I understand that things happen and that my code is not ever perfect.... never will be. As far as I'm concerned, being willing to admit at least the possibility that something is your fault, at least in part, is the start of solving the problem. ------------ Category 8, Topic 18 Message 100 Fri Jun 09, 1995 C128.JBEE at 19:58 EDT Ed, Your last post was slightly garbled for a few lines. ------------ Category 8, Topic 18 Message 101 Fri Jun 09, 1995 M.RANDALL2 [Maurice] at 20:17 EDT Ed, I know that some of the stuff I did with the NMI's wouldn't pertain to what you are doing, but it doesn't hurt to tell about it just in case it might make you think of something. However, I would still check out the common ram thing. A couple of years ago, I was investigating something with RamLink and discovered that it does indeed mess with the ram banks. One of the kernal routines that alters the bank is SETNAM when RamLink is using it for it's own purpose such as setting up a filename to search for maybe. It's been awhile and I would have to check into it again but this routine seems to ring a bell (no pun intended, Ed). It might not have been SETNAM, but I remember it had to do with filename handling. -Maurice ------------ Category 8, Topic 18 Message 103 Sat Jun 10, 1995 B.GANN1 [Brenda] at 00:56 EDT Ed> Brenda: I'm willing to feel a little dumb... even very dumb.. and don't worry about more heat cuz it ain't gonna happen. I was getting ready to duck from those pies you guys seemed about to throw ;) Brenda ------------ Category 8, Topic 18 Message 104 Sat Jun 10, 1995 E.GBELL [e.g.bell] at 13:48 EDT John: JB> about twenty bytes for the read and write. Could you post that code. I'll post my code a in the next message. ------------ Category 8, Topic 18 Message 105 Sat Jun 10, 1995 E.GBELL [e.g.bell] at 13:53 EDT Here is my screen blanking/unblanking code John... 780 ; 785 ;-----<blank screen during painting> 790 .u 795 blankit lda #100 800 .byte 44 805 ; 810 ;-----<unblank screen after painting> 815 .u 820 unblankit lda #125:sta light.switch 825 ldx #34:jsr pokevdc 830 jmp lights.high; reset irq timer for lights out 835 ; The executing code is all right here. The variables are just to make sure the IRQ timers get set/unset properly. It can be changed, of course. I'm interested to see what you are suggesting. ------------ Category 8, Topic 18 Message 106 Sat Jun 10, 1995 E.GBELL [e.g.bell] at 14:07 EDT John: I don't understand the line noise. I'm not uploading text... I'm typing it in... I'm fast, but I don't think I'm THAT fast. :) Maurice: MR> investigating something with RamLink and discovered that it MR> does indeed mess with the ram banks This is PRECISELY the kind of thing I've been talking about all along Maurice... that even when you follow the 'rules', there may be something odd afoot that you should have no reason to even expect. I know, and I know you and Doug both know, that the bigger a program gets, the harder it gets to anticipate the effect small changes have on every other part of the program, whether by overwriting variables, registers, aliasing, or just rippling effects of one thing on another. That is why I have been unwilling to say something absolutely COULD NOT be the problem. Your suggestion, if it did have to do with filename handling, and specifically if it messes with the common ram setting, could be causing some if not all of the problems. I'm not going to jump on that as 100% the answer. But this is exactly the kind of thing I've been railing about when I start to rail. To me, this would not negate the value of having a RamLink... neither would any problem like this... it would not even argue against buying one. People are still buying 128's, even with all of the built-in bugs in its operating system. Things would just be a LOT easier if these things were published and/or acknowledged. Thanks! I'm going to have to try to figure out how to work this in. My vacation has been cancelled so I am not going to have the time I anticipated. :( But I'm going to explore how to go about it. Thanks again! ------------ Category 8, Topic 18 Message 107 Sat Jun 10, 1995 CMD-DOUG at 21:45 EDT > MR> investigating something with RamLink and discovered that it > MR> does indeed mess with the ram banks > This is PRECISELY the kind of thing I've been talking about all along > Maurice... that even when you follow the 'rules', there may be something > odd afoot that you should have no reason to even expect. I'm not aware of RAMLink changing anything WHILE a user-controlled program SHOULD be in effect. It does all kinds of odd mapping during times when a user program SHOULDN'T be in effect. When we say that if you follow the standard rules that programming for RAMLink should be no different than programming with anything else, that's what we mean. RAMLink can do nothing until a Kernal serial access routine is called. After the call is executed, RAMLink returns everything back to the way it was before the call, with the exception of returning values that should be returned. Maurice can possibly run into some things that the standard programmer would not, however, since he's using RAMLink under GEOS with RAMLink's GEOS driver... this will indeed bypass normal DOS functons at certain times, and some functions under GEOS will manage the RAMLink hardware directly. It IS possible that what Maurice was talking about (some change in the RAM configuration after returning from SETNAM or some other DOS call) existed at some point as a bug. I'm not aware of it existing at this point in time. I'd be happy to present any proof of this existing in the current DOS to Mark so that it could be fixed. Bear in mind, NO-ONE has reported the existace of such a bug in the current version of RL-DOS. ------------ Category 8, Topic 18 Message 108 Sun Jun 11, 1995 C128.JBEE at 08:28 DT Ed, Here is the code I use, a bit longer than yours but it should work on all machines. You could cut off 15 bytes or so by not checking values and just writing the values you know should be in reg#25. --------------------------- ; screenblank ;--------------------------- screenblank jsr bank ;set proper bank for i/o ldx #$1a ;load x with vdc register to read, #26, Back/Foreground jsr vdcread ;colors and jsr vdcread routine sta screenbnk1 ;value left in A. store for restore on keypress lda #$00 ;X. should still hold dest register#26 jsr vdcwrite ;after this routine is called, X. $00 equals black ; for back/foreground colors dex ;we want 25, so DEX to save a few bytes, jsr vdcread ;register 25 value left in A. and #%10111111 ;mask out bit 6 and set to zero = attributes off jsr vdcwrite ;X. should still be holding $19 ; no need to load dest X. register rts screenunblank jsr bank ;set proper bank for i/o ldx #$19 ;load X. for reg 25 jsr vdcread ;once we get the value, do not reload .X ; with reg value ora #$01000000 ; as it should still be there jsr vdcwrite ; inx ;X. should contain reg#25, increase for one for reg26 lda screenbnk1 ; which is the Back/Foreground color register jsr vdcwrite rts screenbnk1 .byt 000 ; ------------ Category 8, Topic 18 Message 109 Sun Jun 11, 1995 E.GBELL [e.g.bell] at 16:05 EDT Doug: DC> I'm not aware of RAMLink changing anything DC> I'm not aware of it existing at this point in time DC> NO-ONE has reported the existace of such a bug in the current DC> version Consider this borne in mind... But lack of awareness is not the same as a blanket statement that something doesn't exist. I am aware, as I've always been, that it is easier for me to tweak my code to make nice with your firmware than it is for you to tweak your firmware to make nice with all NMI handlers. I accept that. I also accept that fact that it is quite possible that something in my code may be the sole culprit... I if I have not conveyed that properly, I'm sorry. My point all along has been that it is also possible that there is something more here than meets the eye. DC> that what Maurice was talking about (some change in the RAM DC> configuration after returning from SETNAM or some other DOS DC> call) existed at some point as a bug I was not aware that GEO programmers used CBM kernal routines, so I'm not sure (if I'm correct about that) that Maurice's experience with exits from that routine can be explained away by pointing at his being a user of an alternate operating system. I would also like to point out to everyone reading this... or at least to ask reasonable people who are reading this.... to see that if you acknowledge that there have been reported bugs, it is also implicit that they are possible still. If you are discounting that Mark's code (it is Mark's, right... that is the impression I've had of your posts, that it is Mark's code you seem to be saying is infallible) could conceivably have any kind of shortcoming, congratulations are in order. If neither you nor Mark are willing to say that every piece of code you write is 100% perfect, then how can you be unwilling to explore other possibilities. And if your code IS 100% perfect, why are there different versions? Is there a way to easily determine the version of RLDOS... perhaps we are dealing with something that earlier versions are susceptible to. That would explain, perhaps, why you would not see it, but why older customers might. This is not an accusation... just entertaining ideas. (BTW, by 'older customers, I'm talking about the age of the RamLink, not the customer) A bug is a bug, even before being reported. Some take longer to find, or more exposures to different configurations, etc. Maurice recently found something like this w/the modem thing he reported. I could be wrong, but I suspect as more people start using GEOFAX with mutant modems, etc. more weird stuff is going to occur... perhaps not. I still remember a time when people were not only discounting the SAVE@ bug, but even offering rewards to anyone who could prove it existed. Lack of proof at the time did not make it go away. I really feel that I have an open mind about this thing. I'm going to find, if not the problem, some kind of workaround. And I am not going to categorically rule out anything... including my code. For my part, I'm willing and eager to entertain any and all suggestions and even implement them where possible. I'm not averse to wholesale changes. My code is not perfect... nor will it ever be. If you are willing to say in public that your code, or Mark's, is absolutely beyond suspicion, fine. Not much room to wiggle with that, and I have a feeling that kind of public statement would come back to bite later. Maybe not. I only know that I won't make such a statement. But let's face it... there have been reports of problems over the years. I could easily go back and find them in the RL category. That is the nature of this stuff. I fully plan to give Maurice's suggestion a try, at least in copying a duplicate of my NMI stuff into ram 1... I'd have changed it to restore the banks or something but my vacation got cancelled for this week and I have just not had the time. I do plan, also, on trying to figure a way to implement your suggestion about the debug byte, tho later thought tells me that it would not work just the way you suggested... I think it would have to be that I put a value in a predictable register at the start of the NMI routine and zapped that at the end so that I'd know if the BRK occurred during an NMI... if the value was there, it did, if not, it didn't. Tho I guess that value could be the MMU setting... anyway, I am on vacation starting this coming Saturday... (the Friday of the following week was taken from me too... darn! ) But I fully intend to explore all possibilities on my end. ------------ Category 8, Topic 18 Message 110 Sun Jun 11, 1995 E.GBELL [e.g.bell] at 17:05 EDT John: I've looked at your code and I have a question or two. If you disable attributes and then change the foreground and background colors to black, or whatever color, is that going to prevent the system from maintaining the characters, etc on the screen? I thought they would be painted to the screen no matter what. If I'm correct, 'blanking' the display by making everything the same color won't protect the screen from burn-in, which is what I intended with the blankit routine. If I'm not correct in my assumption, that is something else and I'll have to squeeze your code in... just before I go to that work I want to make sure the most important function is preserved, because without that there is no reason to blank the screen at all. Another way might be to tweak my routine, if that is possible, to work with your machine. I can do a BASIC loader that would allow you to try different values to see if it is possible... unless you are sure what I'm asking above is just incorrect... I just don't know for sure. ------------ Category 8, Topic 18 Message 111 Sun Jun 11, 1995 CMD-DOUG at 18:09 EDT Ed, I've never once stated that we haven't had bugs in the past, or that others may exist that we aren't aware of in the current version. Matter of fact, I believe I've mentioned that we do indeed fix bugs when someone can supply us with a way to verify them, or when we locate them ourselves. I will, however, point out that the current version of RL-DOS has been around quite a while, and that wouldn't be the case if we were still running into bugs that were affecting the operation of programs. IOW, it would appear that any currently remaining bugs aren't affecting the operation of programs enough for anyone to point them out to us. The last 'official' bug report I saw for RAMLink was so long ago that I can't even remember what it was. No, Mark doesn't write perfect code, and nobody I know does. But he does write very well, and he does a pretty good job at testing and debugging it. If my life hinged on a properly written routine, I'd give the job to Mark, no hesitation. All this is neither here nor there, though. I cannot go into work and tell Charlie Sr. that we have to pull Mark off of production and his other projects to start digging through RAMLink in search of a bug that in all likelihood doesn't exist. If I can offer some proof of a real bug, that's a different story. Until then, the matter is moot. I just really think that before we can make any further assumptions, we need to know what the results are from the test I outlined to you. I far prefer to deal with facts when I know they're obtainable. ------------ Category 8, Topic 18 Message 112 Sun Jun 11, 1995 C128.JBEE at 19:48 EDT Ed, Just a thought about your code hanging. For some reason FFAB (UNTLK) when using burst mode hangs when using JiffyDos/RamLink/FD-4000 for me. It does not when using a C-1581, just with the FD-4000. So, after tracing the code back and forth across the ROMS I came to the conclusion all I had to do was add a CLI after calling FFAB to cure ARC/CS-DOS from hanging on "some" computer systems. I tried tracing all the possible exit routes to see if a CLI was sent after all those SEI in the FFAB routine but after spending hours just finding out why ARC hanged, I gave up seeing why it hanged with JiffyDos/RL/FD and added the CLI. Since the overlays break upon disk access, I would double check to make sure your SEI/CLI commands are in place before and after calling any routines used for disk access/burst mode. I did try to see where the differences are in the original CBM ROMs and JD/RL by using the Internals Book, but, it is too much work to spend doing it when I now know a simple CLI after accessing the routine will do. ------------ Category 8, Topic 18 Message 113 Sun Jun 11, 1995 C128.JBEE at 20:09 EDT Ed, How I look at it is the monitor is going to be redrawing the screen 60 times a second no matter what you do with the VDC and its signal. When you say "burn in" to me that means seeing visible characters or ghosts burnt into the screen because of the differences between the characters and the background. Which is best for a monitor, blanking the screen by setting or changing the beginning or the end of the display scan, blanking with an all white screen, or an all black screen, or something else? I do not know. Disabling attributes does not prevent you from writing to VDC ram, it is just telling the chip not to use the information it finds. Once you enable attributes, the VDC will use whatever is there for attributes. When attributes are disabled you can not use flash, the second character set, etc. They are ignored, but once enabled, it will use whatever was placed in DRAM. I can try a revised BASIC loader, though with six different flat 128 revisions and at least one VDC revision for the C-128D, we have seven potential types to test, at least. Though considering the defect rate of the early 7/8 rev. numbers, all we probably have to worry about is R9a/b and the C-128D. ------------ Category 8, Topic 18 Message 114 Mon Jun 12, 1995 CMD-DOUG at 00:43 EDT JBEE, Does the ARC code clear Status prior to each of the primitive DOS calls? I've found that not doing so has generally caused lockups at some point, especially- -though not exclusively--in 128 mode. I've only had it happen to me once in 64 mode, but putting those clears straightened things right out. Ever since, I start every one of my DOS primitive subroutines with an LDA #0, STA $90. ------------ Category 8, Topic 18 Message 115 Mon Jun 12, 1995 E.GBELL [e.g.bell] at 06:02 EDT JB> For some reason FFAB (UNTLK) when using burst mode hangs when JB> using JiffyDos/RamLink/FD-4000 for me. It does not when using JB> a C-1581, just with the FD-4000 John: I don't use burst routines or low level routines, with the exception of the ARC code, and even there, I don't think I use them that often... some that were like that I changed to higher level routines because there was no need to do them lower than that. As for the status byte, it is cleared where Chris cleared it and I don't have problems on my end with any hanging with stuff like that. If you are referring to what I said about the RL and the full partitions, I don't know that I clear interrupts after those calls, but as i said, none of my routines are low level calls in the main program. The only places I DO use low level routines are in places where more than one drive is used simultaneously... examples would be the copier and archiver, where a source AND a target drive are in use at the same time. The reason is that I have to constantly monitor error channels and felt it was better not to open multiple error channels. I don't do anything erotic... just standard access, albeit via the low level routines, and those for error channel polling only. Doug: I am on vacation starting this Saturday. I fully intend to give everything suggested a try. JB> When you say "burn in" to me that means seeing visible JB> characters or ghosts burnt into the screen because of the JB> differences between the characters and the background Ok, I thought that burn-in was caused by the phosphors being worn out or something like that, and that it was totally unrelated to color. If that is not correct, then I'll have to give your code a try. It is less work than cooking up a hack to twiddle on other machines.... just a problem wedging it into virtually no room. ------------ Category 8, Topic 18 Message 116 Fri Jun 16, 1995 B.GANN1 [Brenda] at 22:23 EDT Ed... here is something interesting... I had just called GEnie with RTCM. I saved the buffer with C= W. Put The Write Stuff in the 81. Reset (not turned off) the computer. Now I hope I am remembering this part right... I needed to do a cp3 on the HD. So I guess it was when I pressed control - up arrow, TWS broke to the monitor. It would not let me exit with x. It just printed a question mark. I pressed reset and am using TWS now with no further problems. Here is what the break said... pc sr ar xr yr sp 7e0bb 30 0c 0c 1c f3 This has never happened before. There was NO RL access during this time. (I might have looked at a directory before booting RTCM though.) Like I said in an earlier message, it seems all my brks to the monitor happen at the very beginning of disk access. And now, it doesn't even matter if it is the HD and not the RL. Brenda ------------ Category 8, Topic 18 Message 117 Fri Jun 16, 1995 B.GANN1 [Brenda] at 22:24 EDT Oops, I did not press reset when TWS broke to the monitor. I pressed run-stop/restore. Brenda ------------ Category 8, Topic 18 Message 118 Sat Jun 17, 1995 B.GANN1 [Brenda] at 23:05 EDT Ed... more interesting stuff... I turned on the computer and loaded TWS. I typed for a while and then tried to save it. My HD was off. I was saving to the FD. (I might have had TWS set to the HD though.) When I typed the filename, I got this... pc 7e0bb sr 30 ac 0c xr 0c yr 1c sp f5 Then I tried again. It broke to the monitor again. I accidentally scrolled the screen so I do not have the registers. I tried a 3rd time, and got this... pc e43150 sr 30 ac 78 xr 0a yr 00 sp f7 Then I got it to save. I don't remember if I pressed run/stop, or turned the HD on, etc. RTCM was not booted before this problem. RL was not accessed. Sorry for bothering you if this problem is not related to RTCM. When it happened before, it happened after RTCM had been running. I tried to recreate the error (I just got off GEnie). I turned the HD off before trying to change devices. (control - d) It just looked like it ignored me. No messages or anything. But it did not break. This has not happened before since the first time the other day. Brenda ------------ Category 8, Topic 18 Message 119 Sun Jun 18, 1995 E.GBELL [e.g.bell] (Forwarded) Brenda: BG> So I guess it was when I pressed control - up arrow, TWS broke BG> to the monitor. It would not let me exit with x. It just BG> printed a question mark. I pressed reset and am using TWS now BG> with no further problems BG> turned on the computer and loaded TWS. I typed for a while and BG> then tried to save it. My HD was off. I was saving to the FD. BG> (I might have had TWS set to the HD though.) I was confused at first.... thought perhaps you were typing TWS when you meant to type RTCM, but I figured out when you mentioned pressing CTRL- UPARROW that you were trying to send DOS commands thru TWS Exiting RTCM through either a RESET or the C=ESCAPE exit does a system reset through the normal reset vector AFTER disabling the NMIs. So you would not be carrying problems from one program to the next. Further evidence of this is the fact that when you did it from a cold start ( power turned on/load TWS) the same result, including the same BRK, occurred. I can't tell you what is using the '7' in your 'pc' status indicator. I *can* tell you this tho... the memory in context when the mmu has a 7 is the following: 0400 - 3fff Ram 0 4000 - 7fff Ram 0 8000 - Beff Internal ROM D000 - DFFF Character Gen C000 - FFFF Kernal ROM This kind of points away from the RamLink because it maps in as an external ROM I'm pretty sure, which is the '8' I mentioned in earlier posts. What you are experiencing kind of points, in my mind, to a chip or something in that empty slot in the 128. I'm not a real expert on that stuff, but I think that is the only place you can map in internal ROMs. Do you have anything in that socket Brenda? In addition, if this is a fluke and that 7 is not relevant, it has always been my understanding that non-existent banks map into either ram 1 or ram 0 depending on whether they are odd or even, if you know what I mean... iow Bank 3 = bank 1... that may not even apply to an MMU setting tho. Something is apparently routine 'traffic' to address $E0B9. A BRK always shows up in the 128 monitor 2 address locatsions AFTER the location that caused the BRK. RTCMaster does not use $E000 - $FBFF for anything under most situations. The data block at $E000 stores the music data under normal circumstance. Never executable code. When it is needed by an overlay, the overlay restores the music data on exit. What *does* happen sometimes in programs is that programs modify themselves or use indirect JMPs, and the pointers get corrupted somehow. And since these can often get set using other pointers into address tables, they can be boogers to track down. I don't know anything about the CMD HDs. Only what I've already said about the RL. And my vacation weeks (last week and this week) got cancelled so I haven't even had time to experiment. I would still be interested to hear if there is a command or something that can be issued to CMD devices to determine the DOS version in the unit. As I've said consistently, the unit I have has virtually none of the problems everyone else has described. I'd be interested if we could isolate this stuff to perhaps a specific version of the DOS, for whatever reason. iow, is the version I have newer than everyone else's, or older? BTW, FWIW, TWS, as far as I know, does not do telecom. I don't think it does anything to the NMI vector, and the only way you would get an interrupt there otherwise would be pressing the RESTORE key. BG> Sorry for bothering you if this problem is not related to BG> RTCM. When it happened before, it happened after RTCM had BG> been running Trust me! You are NOT bothering me. I'm open to ANYTHING that will solve the riddle. As a matter of fact, tho it is not good for you, it does at least give me some comfort that it is not only my program experiencing it. The best way to find these things is by talking about them, especially since no one can have every possible configuration on their desk.... especially with telecommunications, but as your experience shows, it is not necessarily restricted to that... and if it happened once, it will happen again I'm sure. As a matter of fact, I want to thank you for telling us about this. As more things are revealed, we will close in on it... ed ------------ Category 8, Topic 18 Message 120 Sun Jun 18, 1995 B.GANN1 [Brenda] at 23:46 EDT EB>> I was confused at first.... thought perhaps you were typing TWS when you meant to type RTCM, but I figured out when you mentioned pressing CTRL- UPARROW that you were trying to send DOS commands thru TWS. Uh, sorry. I guess I was taking too much for granted. EB>> but I think that is the only place you can map in internal ROMs. Do you have anything in that socket Brenda? Uh oh, now it is really getting scarey... no I do not have anything in that socket. re: stuff I don't know how much of that stuff I followed :) EB>> I would still be interested to hear if there is a command or something that can be issued to CMD devices to determine the DOS version in the unit. When you first turn the drive on, read the error channel. I have version 1.86. The weird thing is that I never had a BRK with TWS before, and I am a heavy user. I have the parallel cable, but it is not hooked up. My RL has an old DOS (I think 2.0.) I got 2.01, but have not installed it yet. My HD is from 9/91. I recently upgraded the DOS from 1.82 (?) so I could use the parallel cable whenI got it. I just recenty hooked up the RL, an FD, and a Canon BJ200EX. (just need a ZIP ;D) A 1581 was disconnected to make room for the FD. The printer is normally off. (Before, I normally had a Star SG-10 and left it on.) Now one thing I did not mention before, was that I noticed RL was kinda sitting up high in the port. The SL was pressed against the edge of the desk and was pushing the whole unit up. I don't know if this could have affected it or not. EB>> BTW, FWIW, TWS, as far as I know, does not do telecom. Correct. The weird thing is, it happened one day. Then the next day, it happened 3 times in a row. I wonder if something could be going out in the flat? EB>> Trust me! You are NOT bothering me... As a matter of fact, I want to thank you for telling us about this. As more things are revealed, we will close in on it... Thanks, and you're welcome! ;) Let's nail this thing! :D If anyone else has BRKs, please mention it. No program should do this. Anytime it happens, the programmer wants to know about it. (I saw this because some people think that the programmer just puts out buggy programs. I think 99% of programmers want to be told when something goes wrong. I know I do) Brenda ------------ 8 |