8bitfiles.net/archives

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

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

Wrap

Text File | 1990-02-12 | 30.0 KB | 706 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 41 Thu May 04, 1995 E.GBELL [e.g.bell] at 05:56 EDT D.SMITH: Nate's reply has what I think is the last part of the picture. The problem was removed from 3.00, but what is happening is this.... your modem is not getting the '&c1' in the init string because earlier versions of RTCM did not allow the init string to be sent in the boot if you were online. This was a catch 22. The modem needs the init string with the &c1 to tell it to follow the true state of the carrier instead of forcing it high all the time. But if it is high all the time, RTCM would not allow the init string to be sent... if you can follow that. Nate was the person who put me on to how dumb I was for doing things like that. I originally did it to stop having RTCM send init strings when people booted up while already online. Anyway, 3.00 changed that arrangement, and Nate/Dan T.'s solution corrected it in earlier versions... I would just ask Nate one thing... Nate.... you have the 'AT#C1'.... is that a typo for 'AT&C1', or is the # character how the mini modem does this? D.SMITH23.... add the code that Nate put in his reply and I think that will solve the whole thing. Just for general information, I did an overlay for 3.00 last weekend to pull all setup steps into one overlay. It does everything I outlined in that earlier post, creating/modifying the files you had to modify.... :) ------------ Category 8, Topic 18 Message 42 Thu May 04, 1995 E.GBELL [e.g.bell] at 05:59 EDT Dan Thomas: Thanks again for that detective work w/the &C1 in the init string. It explained a LOT of things that have come up! ------------ Category 8, Topic 18 Message 43 Fri May 05, 1995 N.ONEIL [Nate] at 00:11 EDT Ed Wouldn' you know my fast fingers hiit the wrong key. Yes, it should read "at&c1". Nate ------------ Category 8, Topic 18 Message 44 Fri May 05, 1995 E.GBELL [e.g.bell] at 05:39 EDT ok! :) I've never had one of those modems so I wasn't sure if that was something peculiar to it. Thanks again! ------------ Category 8, Topic 18 Message 45 Sat May 06, 1995 E.GBELL [e.g.bell] at 08:52 EDT I have something to share with everyone that might give you a clue of how frustrating it is to try to track down problems in my programs that simply may be located elsewhere... I have been trying to figure out why Cam and Greg have had problems with RTCM.... why Brenda and Eddie find BRKs to the monitor... and I have been taking it on myself... that there is something RTCM is doing wrong. Consider this. I have run into a problem where, when RTCM autosaves to a 1581 emulation partition on the RamLink, if there is not enough room in that partition, RTCM just freezes. Don't matter how long you wait, it is happy trails... she ain't comin' back. What RTCM code does is to attempt the save, then read the error channel, saving the dos error code in a field called DS. If, after the attempt, DS is > 0, RTCM knows that the attempt failed.... so RTCM checks DS... if it is equal to 72, the code for 'Disk Full...', it checks to see if the user specified an alternate drive. If so, RTCM switches in that setting and tries again. On any subsequent failure, the whole thing is aborted. Anyway, all of the above is contingent on that error code coming back from the drive (or RamLink). So I knew this is where the problem had to be happening.... whatever it was. To debug, I loaded the appropriate RTCM object module, and renamed it on the RamLink. I put in a BRK where DS is determined not to equal zero. At the bRK, I would know what it did hold, thereby helping me to determine exactly what WAS happening.... I did not realize that there was not enough room for this file in the partition. I tried to resave it using the built in monitor of the 128... and guess what.... 'Happy Trails....'. The same lock up... from the 128 monitor. Sooooooo.... let's eliminate all of the things likely to be blamed. I unplugged my interface and tried again... same result. So I unplugged my serial cable... now I have no disk drives, no printer.... just the RamLink and my Omnitronix interface and Supra 2400 modem. bzzzzzzzzzzzzt! Locked up again.... Ok, lets assume that the problem is the monitor's use of the system to save the code... I tried dsave..... no way.... If the RamLink WOULD return an error code, it never gets that far. It just freezes. Tried the same test on my lowly 1571 and it responded exactly like it should. Note in all of the above that I was using Commodore firmware or CMD firmware and this was failing. Those of you who write programs know how frustrating and elusive bugs can be. I only bring this up to show you that there are often other things afoot which are not published, perhaps not known, and glib 'doesn't handle the error channel gracefully' comments don't always get it. The RamLink is a solid piece of hardware, but we should move cautiously as we move into the beatification process. There are simply things it does not do normally, in the context of CBM devices, and as I have said before, there are no reference materials for ml programmers... nothing (with the exception of the DMA stuff) of any real substance beyond basics for any programmer (In My Opinion), and while many of the problems that have been fixed were in the realm of things I was able to put a finger on, some like the above are not. The error channel thing and the clock thing are perfect examples. I am kind of inclined to remove that code from my boot program because it simply is not worth it. I feel very frustrated about things like the above and am sensitive about perceptions that my software is garbage because of things I have only cursory information on in terms of programming, etc. And the experience above, and elsewhere in this thread regarding things as elementary as the TRAP command, show me that while compatibility is high it is not 100%, even in very elementary things. ------------ Category 8, Topic 18 Message 46 Tue May 09, 1995 D.SMITH123 at 00:34 EDT To: EGBELL I tried the latest suggestion & still no luck?! I did Dissolve all the .SFX files. I ain't no dummy, no offen se taken. But the instructions in the manual suck, JMO. ------------ Category 8, Topic 18 Message 47 Tue May 09, 1995 E.GBELL [e.g.bell] at 05:59 EDT are you still gettig hung at the logon screen DSmITH? where the 'hhhhh' is supposed to get sent? are you gettng the f'f thing from GEnie? Which instructions suck? Point me at them and I'll try to improve them. I wrote a new overlay last weekend solely because of your experience, tho it only works with version 3.00. It does all the setup stuff automatically. BTW, doesn't the Aprotek mini-modem have a switch that allows you to switch between 1670 mode and 2400 mode? If so, could this be the problem? I don't think I have ever implied that you were a dummy. :) Some people have trouble getting things set up, some don't. I don't differentiate when I respond to questions. ------------ Category 8, Topic 18 Message 48 Tue May 09, 1995 E.GBELL [e.g.bell] at 06:12 EDT Eddie: I just today noticed your message w/the bRK address... and as I mentioned before, note the '8' in the '89f23'.... this indicates that it is RAMLINK code dropping to the monitor, not RTCM's. My code NEVER EVER EVER switches to that configuration. There should be nothing software can do that can cause firmware to drop to monitor.... and since RTCM doesn't do that with normal cbm drives, I believe the problem is with cMD's code. I know that sounds like passing the buck, but since it is breaking into a configuration that I never entered, it has to be the RamLink that is not handlng something gracefully. I don't have any idea what is going on at that address, because cMD provides no memory maps. I'd be more than willing to work at fixing this if I had that kind of information but I am swinging in the dark the way things are now. As I said before, a program can't bRK to a configuration it did not enter. Mine never entered that configuration.... it has to be something in the RL interrupt routine I would think. Putting an 8 in the MMU sets up for an external ROM... RTCm is a RAM based program. ------------ Category 8, Topic 18 Message 49 Tue May 09, 1995 CMD-DOUG at 09:50 EDT RAMLink will generally only break at this point if an interrupt is occuring while a custom inturrupt-handler is being executed. The only time we have ever run into this is when custom RS-232 routines are created, as the Kernal's default RS-232 routines shut down all sources of interrupts. ------------ Category 8, Topic 18 Message 50 Tue May 09, 1995 D.SMITH123 at 23:24 EDT To: EGBELL RTCMt 625;1 625;1 on screen. Aprotek minimodemC24 has no switch, I wish it was that easy! The manual was informative but not f or getting started. BTW thanks for responding quickly to my posts. Doug ------------ Category 8, Topic 18 Message 51 Wed May 10, 1995 E.GBELL [e.g.bell] at 06:18 EDT DSMITH: DS> RTCMt 625;1 625;1 on screen. Aprotek minimodemC24 has no switch The one I got to work with back in 1990 must have been an earlier version then. It had one, but the description you gave above indicates that RTCM thinks it is online or there is a problem with your script. Mark Dulski made a way for scripts to be executed online, but the technique required starting a script later than the dial routine, etc. That is why, in Script Maker, you are asked if the logon sequence is done, or something to that effect. You are telling RTCM where to start executing a script if you are already online. It sounds a lot like you still don't have your modem aware of the carrier status. That is what that suggestion was wrt adding code to the boot. Here is what I suggest to expedite things. Can you upload your boot just as you have it now. I'll give it a try and see if it works on my system. I am really positive this is a problem only with getting that init string to the modem. As for the 1200/2400 thing, the baud rate should not matter. but your 625;1 message kind of narrows it down to the carrier flag. DC> only time we have ever run into this is when custom RS-232 DC> routines are created, as the Kernal's default RS-232 routines DC> shut down all sources of interrupts I'm not exactly sure what to say about this. I will go back in and see what more I can do with my code to appease the RL code... but the clock thing brenda and john were talking about occurred before interrupts were ever enabled in my code... and you are talking about NMIs, right? ------------ Category 8, Topic 18 Message 52 Wed May 10, 1995 CMD-DOUG at 09:13 EDT Any interrupt (NMI or IRQ) will have that effect. I'll have to study exatly how TRAP works to see if I can shed any more light on what's going on there. The way RAMLink works is that certain routines in the Kernal drop down into RAMLink's Kernal. If necessary, RAMLink switches its DOS ROM into memory to perform various operations. Most of the time, this is during disk access, and we all know interrupts must be off during drive access - so generally there aren't any problems there with stock programs. ------------ Category 8, Topic 18 Message 53 Wed May 10, 1995 CBM-MARK at 22:57 EDT Doug & Ed, I didn't go back and reread the messages to se if this suggestion came up or not but ... With wizard an AT&C1 was needed with an Aprotek C2400 modem before it would work properly. Could it be the same here? If I recall corectly the Aprotek comes set up with the carrier control (&C) always forced *on*. Would explain why Autolog insists it's already online. Just realized, this is to D.SMITH128 Doug, not CMD-DOUG ;> ~~Mark~~ ------------ Category 8, Topic 18 Message 54 Thu May 11, 1995 C128.JBEE at 00:06 EDT After loading RTCM V3.00 from a RamLink swapped to device #8, I tried running the file copier overlay. Once it started to copy disks it broke to the monitor with : 88e5b b4 24 00 00 da ------------ Category 8, Topic 18 Message 55 Thu May 11, 1995 C128.JBEE at 01:17 EDT The following produces the same break to monitor everytime, registers are the same everytime. Setup C-128D, RamLink #10, REU, Swiftlink, 9600, FD4000 #8 EGADS ROM. I made two changes to the BOOT file. I made the Roman font dftchrset and changed the baud prompt from 3 to 4 and copied over my dflt.mysetup and script from my v2.04 disk. When first running V3 and answering N to the autolog on I hit the ALT key and then C for the copier. Then I press S to set the paths. SD=0 SU=10 TD=0 TU=8 When it goes for the directory it breaks to monitor with this: 8adb8 b5 ad 0c 00 d8 ------------ Category 8, Topic 18 Message 56 Thu May 11, 1995 E.BOURDON1 [C128-Eddie] at 12:41 EDT That sounds like the problem that I have. Sometimes, but not always, when trying to access the RL in anyway (load overlays, get a directory) it will dump to the monitor. I can't remember the exact break, but it did start with an '8', just as Jbee's did. ------------ Category 8, Topic 18 Message 57 Thu May 11, 1995 E.GBELL [e.g.bell] at 22:25 EDT Mark: MD> an AT&C1 was needed with an Aprotek C2400 modem before it MD> would work properly. Could it be the same here? If I MD> recall corectly the Aprotek comes set up with the carrier MD> control (&C) always forced *on* Yes, that is what we were discussing. Nate passed along a suggestion by Dan that that version of RTCM needed a BASIC hack to send that command because the way RTCm of that time was written, it would not get sent because RTCm thought it was online, and in order to get the correct setting, it had to get sent, but it could not get sent..... so I believe this is the problem that has to be resolved. We just need to make sure DSMITH put that code in his boot. John and Eddie: This is pretty much what I have been saying. You will find the '8' a common denominator. In all cases this will point you to the RamLink and not RTCM. Does any of this happen when the RL is not installed? That is, when running under Commodore ROMs, do you break to monitor. I know this could sound like blowing something off, but I don't think you are going to find this happening. Consider this too... the first thing any of the overlays do (with the exeption of the protocols) and particularly the copier, is disable the interrupts. If it is the system interrupts, that still brings up a question in my mind. Remember the problem with the REU and interrupts. This is a recognized bug in Commodore's OS. It was fixable with a patched routine that stopped the interrupts... but the point is, the problem in that case is in the OS, not the application. I am willing to work to address the problem, particularly since it is easier to do a patch in software than it is in firmware, but I honestly believe that the problem is with the operating system and not the application. It is not my code that is dropping to monitor. My proof, consistently, is the memory configuration at the time of the break. If my code can cause ROM code to brk to monitor, where do you think the problem is? And while RTCM does use custom NMI routines, it uses them in stock cBM systems without this proble If I had a memory map I could possibly find a way to reenter the NMI stuff or divert it... I don't know. But in Non-SL systems, I use George Hug's wedge code which is proven reliable. In the SL code I use a hybrid of my own and Kent Sullivan's code that came with the unit. The change in 3.00 interrupts involves the screen blanker, which basically counts down a timer and when it elapses without intervening keypresses, calls the screen blanker (if not already blank) and resets the counter. I don't offhand recall ANY reference to the system IRQ in Commodore's NMI handlers in either the 64 or 128. I'm all but positive that their stock code did not disable interrupts prior to handling NMIs. ------------ Category 8, Topic 18 Message 58 Fri May 12, 1995 CMD-DOUG at 13:44 EDT After further discussion with Mark, I can tell you this much: The bank '8' operations occur when RAMLink is executing code from its own ROMs. This happens only during disk operations, as Kernal calls related to disk access functions drop down into this ROM. If an interrupt occurs while this code is running, the RAMLink memory map gets switched out of the system, becoming invisible (as it normally is). When the interrupt-handler is done, the computer attempts to return to executing the RAMLink ROM code which is no longer in memory. It all comes back to interrupts happening when they shouldn't be. If you have a timer counting down that can generate an interrupt, this should be disabled before any Kernal disk access routines are used. There may be a work-around through a flag that the stock routines use which is checked by RAMLink. If I understand Mark correctly, this would allow RAMLink's ROM to become resident again after the interrupt has completed... But I really wouldn't suggest this, and would have to get further info from Mark as to how that works and where the flag is. Overall, I'm only relaying what I can glean from talking with Mark here, and I might suggest you call and talk directly with him, since he's the only person who actually knows just how RAMLink truly operates. I did do a test of the TRAP function we spoke about earlier, sending a 'T-RA' command to clockless RAMLink while TRAP was on, then fetching the resulting DOS syntax error message from the error channel. It worked flawlessly and repeatedly. ------------ Category 8, Topic 18 Message 59 Fri May 12, 1995 E.GBELL [e.g.bell] at 19:03 EDT DC> test of the TRAP function we spoke about earlier, sending a DC> 'T-RA' command to clockless RAMLink while TRAP was on, then DC> fetching the resulting DOS syntax error message from the error DC> channel. It worked flawlessly and repeatedly While I can't speak for the error channel, mine has operated flawlessly too. And since there is a clock there, I'm never going to get an error in that section. But apparently there is something that TRAP cannot see in that section based on what was discussed here earlier. DC> It all comes back to interrupts happening when they shouldn't DC> be. If you have a timer counting down that can generate an DC> interrupt The code I spoke if happens IN the interrupt service routine... and you know that the interrupts store the configuration on entry and restore it on exit.... that says to me that it cannot be a system interrupt that would cause what you describe... and yes, I will have to speak to Mark directly. But it seems to me that if interrupts can generate that kind of havoc with the RL dos, RL DOS should be disabling interrupts. but this would obviously only handle system interrupts. The timer I spoke of in this instance is only a set of registers I count down myself within the interrupt routine. They operate entirely within the interrupt servicer and exit normally.... that is, through the normal IRQ exit routine which polls the keyboard, updates the timers, etc. and exits with restoration of the config, stack, and registers normally. DC> RAMLink memory map gets switched out of the system, becoming DC> invisible (as it normally is). When the interrupt-handler is DC> done, the computer attempts to return to executing the DC> RAMLink ROM code which is no longer in memory. Doesn't the RamLink manage memory normally through the MMU? If so, it seems that any interrupt service routine that stores/restores the MMU would not cause that kind of problem. The only other interrupt that might ever come into play in RTCM is an alarm interrupt... and this is not only an infrequent occurrence, depending entirely on being set by the user, but totally predictable. Finally, for what it is worth, and perhaps the most frustrating of all, the things that seem to be happening to everyone else do not happen to me at all.... not the bRKs, not the TRAPs, nothing. I don't use a SwiftLink, but otherwise I have a normal system. and I too have an EGads chip in my computer, but it is a non-issue. It is dead code until activated. It is not wedged into the system at all until it is executed.... and its config is 6 anyway. I will try to call Mark on Monday from work. ------------ Category 8, Topic 18 Message 60 Fri May 12, 1995 E.BOURDON1 [C128-Eddie] at 21:31 EDT I have had RTCM work fine from my 1581, so I figured that it wasn't a 'bad copy' that I had, but that something was going wrong when I tried to access the RL via a normal dos command. Like I said before, it doesn't happen all the time, but I always seem to be doing the same thing (dos commands), whether it's loading any overlay or getting a directory. The only common thing I've found is that it always occurs during an attempt to access the RL. I hope that this doesn't mean that I won't be able to use RTCM with my RL :( ------------ Category 8, Topic 18 Message 61 Sat May 13, 1995 E.GBELL [e.g.bell] at 15:12 EDT Eddie: If I can find a workaround for this, I will. I just want everyone to understand that it is not my code that is dumping to monitor. When I get a clear understanding of what is going on, I'll do my best to make all thingscooperate... just that up until now I've literally been punching in the dark. As odd as this sounds, I'd have been WAY better off if my copy broke to the monitor. Then I'd have had something to play with. Mine is rock solid. It would help tho if you could recall the sequences of events when it does happen.... keypresses, overlays, functions etc. Then I could try to duplicate it. ------------ Category 8, Topic 18 Message 62 Sat May 13, 1995 E.BOURDON1 [C128-Eddie] at 22:37 EDT The sequence usually goes like this: I'll load RTCM, then use the autolog to log on. Sometimes instead of listing the scripts, it breaks to the monitor. If it doesn't there, then after I log on to GEnie, I usually load either ymodem or the text-ed overlay, it does there. Or if I try to get a directory to see what I have in another partition, it will break into the monitor. And, this doesn't happen all the time, that's what bugs (no pun intended) me. ------------ Category 8, Topic 18 Message 63 Sun May 14, 1995 CBM-MARK at 20:52 EDT Ed, about the Aprotek modem, I wasn't sure (thought maybe it was ;) if that AT call had been mentioned or not. Trying to cover all possibilities. ------------ Category 8, Topic 18 Message 64 Mon May 15, 1995 C128.JBEE at 13:52 EDT Ed, The baud setting of 6 enables 19.2, works fine, and really whizzes 1K Xmodem out of the null modem. Does a 7 setting enable 38.4? ------------ Category 8, Topic 18 Message 65 Tue May 16, 1995 E.GBELL [e.g.bell] at 18:45 EDT John: I would *guess* that it does... I don't think there were any intermediate settings after 19.2.. I'd have to check the menu, but you could do that if you wanted by disabling the dynamic keyboard fill and that would pull up the menu for you to manually respond to. I am pretty sure that it does though. Just pulled the source into the editor.... here it is... 270 .byte "Baud Rate",13,13 275 .byte "1] 3",13 280 .byte "2] 12",13 285 .byte "3] 24",13 290 .byte "4] 96",13 291 .byte "5] 14.4",13 292 .byte "6] 19.2",13 293 .byte "7] 38.4 :3 So you are right.... 7 is 38.4, which is the highest offered. Just remember that I never did the code for RTS/CTS, so it is limited in that respect. ------------ Category 8, Topic 18 Message 66 Wed May 17, 1995 C128.JBEE at 06:21 EDT Okay, I did try it at 38.4 (7) but it did not work correctly for binary transfers, though text appears to work okay. ------------ Category 8, Topic 18 Message 67 Wed May 17, 1995 E.GBELL [e.g.bell] at 18:51 EDT Well, that was never really intended as a feature. I just added it when you asked about the 19.2 or 14.4... whatever it was you asked for. I just added the bit twiddling to enable those baud rates at the cart but did no extra coding beyond that. ------------ Category 8, Topic 18 Message 68 Fri May 19, 1995 C128.JBEE at 18:57 EDT With the screen blanker active, the top and bottom light bars do not disappear. I am using a yellow screen with black text. Is this how it is suppose to work? ------------ Category 8, Topic 18 Message 69 Sat May 20, 1995 E.GBELL [e.g.bell] at 11:09 EDT John: I'm not sure what you mean. The screen blank feature is supposed to blank the screen totally. On occasion, it will only do 1/2 the screen, I have noticed, and that is verticaly, not horizontally. That is rare, but I've seen it happen. And only in the overlays in file transfers I believe. All overlays start and end with calls to the unblankit routine, so it is just a temporary thing. I suspect it is because of being in an IRQ service routine. Does that answer your question, or did I just not understand it at all? If not, you will have to tell me which light bars you mean. Unless I am way off base, there should never be a light bar on top and bottom with the exception of the point and click menus. ------------ Category 8, Topic 18 Message 70 Sat May 20, 1995 L.SCHONDER [C128.LOU] at 12:51 EDT Can the screen blanking be turned off? I've found that it can be dangerous while hosting, if the bong doesn't bing, you can't hear OR see someone enter the room. ------------ Category 8, Topic 18 Message 71 Sat May 20, 1995 E.BOURDON1 [C128-Eddie] at 18:09 EDT Lou, You can set the time it takes before the screen blanks out by hitting C= + 4, and set it to 127. It works well for me at this setting. You also need to re-enter this everytime that RTCM is loaded, as the value you entered is not saved anywhere. ------------ Category 8, Topic 18 Message 72 Sat May 20, 1995 E.GBELL [e.g.bell] at 22:44 EDT Sort of Lou.... You can make it take a LONG time between blanks by setting the countdown timer to 127, which is the maximum. The keys to press to get this setting prompt is.... C=4 At the prompt, enter 127. There is no way currently to disable the feature. I had to do a lot of squeezing just to get it in... the timer feature was added late to circumvent just the situation you brought up.... or actually to minimize it for conference attendees. It is possible for me to come up with a hack to disable it, tho only for a session because I would have to poke a byte into executable code to change its function... IOW, self-modifying code, which is kind of frowned upon.... I don't have a whole lot against it, but it does make easy adjustment impossible. I'll look into it first chance... all it would take, I believe, is a poke in the boot program. ------------ Category 8, Topic 18 Message 73 Sun May 21, 1995 L.SCHONDER [C128.LOU] at 11:23 EDT A long interval sounds like it'll help! Thanks guys! ------------ Category 8, Topic 18 Message 74 Mon May 22, 1995 H.HERMAN1 at 07:09 EDT Ed, Wasn't it you who was talking about Karma? Well of all things, I see there is an ad for Karma 128 in the current issue of UNDERGROUND. In fact a number of software packages, all from PHD Software: Karma 128 R E S 80128 ACK! 128 Spray Paint 128 RAM DOS Internals (book) Fontigus 128 The address: PHD Software Systems P.O. Box 23 Moville, IA 51039-0023 And..... Would you ALSO believe that in that very same issue of UNDERGROUND there is an article by none other than our beloved YLR*ROSE. Would you ALSO believe that Rose wrote a review of RTCMaster 128, referring to you as "a master programmer", with kudos also going to CBM*MARK for his Scriptmaker. Rose writes very well, indeed! Howie ------------ Category 8, Topic 18 Message 75 Mon May 22, 1995 H.HERMAN1 at 08:48 EDT Mark, Did I just refer to you as CBM*MARK? I know you are CBM-MARK, so I cannot imagine why I did this... Howie ------------ Category 8, Topic 18 Message 76 Tue May 23, 1995 E.GBELL [e.g.bell] at 18:53 EDT Thanks for passing that along Howie. I should get a copy of that issue I guess. :) Or perhaps I could cajole you into sending me a copy of the article. :) ------------ Category 8, Topic 18 Message 77 Wed May 24, 1995 H.HERMAN1 at 01:39 EDT Ed, Done! Give me a couple of days, and I'll get the issue sent off to you. I just lent it to Bob for a fast read. :) Howie ------------ Category 8, Topic 18 Message 78 Wed May 24, 1995 E.GBELL [e.g.bell] at 18:26 EDT Thanks Howie. That will be great! ------------ Category 8, Topic 18 Message 79 Wed May 24, 1995 CBM-MARK at 21:55 EDT Hey Howie! Thanks for passing along that my name was mentioned in that article. I'm a celebrity now? ;D Well, guess not. People can't even spell my name right ;> CBM-MARK LOL! ^ ~~Mark~~ ------------ Category 8, Topic 18 Message 80 Wed May 31, 1995 C128.JBEE at 11:40 EDT > E.GBELL > The screen blank feature is supposed to blank the screen totally. Ed, the problem is the screen blanks, but not completely. The light bar below the status bar and above the user input window stays lit. Which in my case is yellow. My screen is dark yellow with black text and it turns black when inactive except the dividers stay lit. ------------ 8 |