29185 1-MAY 00:45 Patches TSWORD From: VE3DAC To: OS9UGVP tHi Bruce. We met on the last day of the Fest in Chicago and discussed my problem with Vshell in TSWORD and Shell2.1. I see from some messages that another program suffered from the same problem. The patch from Jamie (KNOT1) worked fine so the TSWORD package is ok under Shell 2.1. It is curious that you were close to the 1313 offset that Jamie used, I wonder what you were looking at. The code there doesn't make much sense to me (but that isn't difficult to do.) Anyway thanks for the help. After I made the change I found that the dsort util. wouldn't work and maybe there are others that need the memory assigned by Shellplus. So I guess the thing to do is just make the change as required by TSWord and change it back when I'm done. Merv. -*- 29194 1-MAY 22:30 Patches RE: TSWORD (Re: Msg 29185) From: OS9UGVP To: VE3DAC (NR) Merv, Actually, I was wrong... the $1313 offset is what I should have said. I was looking at the " cmpb #31" instruction just a little bit ahead of the " ldb #31" instruction... no, wait a minute... I think I was right. I'm going to try to think/type this through right here... what the code does is check to see if the default memory is >= 31 pages. If so, it skips past the " ldb #31" instruction, which sets the minimum memory to 31 pages. Instead of changing the " ldb #31" instruction, you *DO* want to change the " cmpb #31" instruction to " cmpb #1". As a matter of fact, you can change both instructions to " cmpb #1" and " ldb #1". That will fix your dsort problem too, most probably. So the changes are: offset ! old byte ! new byte -------+----------+--------- $130F ! $1F ! $01 $1313 ! $1F ! $01 Don't forget to fix the CRC, and once you're done these patches should fix you up so both dsort and should fix you up so both dsort and tsword work. The only potential problem is if you use wilcards and try to expand a line thats too long. Bruce -*- 29204 2-MAY 03:21 Patches RE: TSWORD (Re: Msg 29185) From: KNOT1 To: VE3DAC (NR) Hi, Merv. Any program having a problem do to the patch should work as before if you use "#31" (no "K") when executing the program. You could probably also make that permanent by patching its data size. Then you shouldn't need to change it back and forth, which isn't really "proper" when multi-tasking. -Jamie Wilmoth (KNOT1)- -*- 29206 2-MAY 03:23 Patches RE: TSWORD (Re: Msg 29194) From: KNOT1 To: OS9UGVP It shouldn't matter if the value ends up being "too low," because that value is only the size of the _optional_ data area. F$Fork will use either the module's internal data size or the _optional_ size provided, whichever is larger. Thus a zero _optional_ size will result in the module's data size always being used. If that causes a problem, then that means the module's internal data size is set too low (possibly tested under Shell+, where that wouldn't cause a problem). I suspect that changing both bytes will still result in the same problems occurring. But if changing both bytes DOES fix it, then I would like to know. Thanks. -Jamie Wilmoth (KNOT1)- -*- 29217 2-MAY 22:07 Patches RE: TSWORD (Re: Msg 29206) From: OS9UGVP To: KNOT1 Jamie, I thought this particular test in Shell+ V2.1 was to test whether the larger of the optional or default data area was less than 31 pages, in which case Shell+ V2.1 would give the 31 pages as a minimum? Oh well... its been a long time since I looked at it. Its definitely worth a try, but on a backup only. No reason to take a chance when I'm not sure! Bruce -*- 29225 3-MAY 03:33 Patches RE: TSWORD (Re: Msg 29217) From: KNOT1 To: OS9UGVP (NR) Ah Ha! Based on your comment, I did some testing, and figured out a little better what is going on. That test seems to be comparing what amount of memory the user requested, and if it was less than 31 pages, it would make it 31 pages. So here is what happens with only the one change that I made, and not both. First, without any modifier: OS9:procs User Mem Stack Id PId Number Pty Age Sts Signl Siz Ptr Primary Module --- --- ------- --- --- --- ----- --- ----- ---------------- 8 0 0 128 131 $80 0 31 $4BE2 Shell 12 8 0 128 128 $80 0 6 $05F3 Procs Note that "procs" Memory Size is 6 pages. Next: OS9:procs #34 12 8 0 128 128 $80 0 34 $21F3 Procs Just fine; Mem Siz = 34. But now: OS9:procs #30 12 8 0 128 128 $80 0 6 $05F3 Procs Hey! Only 6 pages, not 30! What I believe is happening is that it is still comparing what the user requested to 31 pages, but if it is less than that it now sets it to zero, insted of 31. Thus, if the user requests from #1 to #30 it isn't used. But all else still works normally. So, if the compare is changed to zero, also, it should work as expected. But that shouldn't cause those programs that need more memory to work. You should still need to use "#31" to make them work, as far as I can tell. I havn't tried patching the other byte yet. I'll let you know how it goes when I do. -Jamie Wilmoth (KNOT1)- -*- End of Thread. -*- 29186 1-MAY 06:40 General Information RE: opps.................. (Re: Msg 29182) From: ENDOTSON To: GREGL Hmmm, i may be lost. I was assuming that i would have to rebuild the info in 0-31 since that is where the original id sector and root directory would have been. As for the "one track format", i was just thinking in terms of making anything (data wise) that might still be there visible to ded. For instance, to dump to the printer like you said. As it is, not even ded can look at 0-31. I figured a logical only format would build back enough of a "roadmap" for ded to at least see whats left. ttfn -*- 29195 1-MAY 22:38 General Information RE: opps.................. (Re: Msg 29186) From: GREGL To: ENDOTSON (NR) Ernest, I just wanted to make sure you knew that the sector allocation bit map is not always the same size. That is, there is one bit in the allocation bit map for each sector on the drive. So, when you reformat the drive using only one cylinder the sector allocation bit map will only occupy 4 bytes (one sector) placing the root directory at LSN 2. ID Sector at LSN 0, allocation bit map at LSN 1, Root directory at LSN 2. Right now your root directory is likely at LSN 32 or thereabouts. You probably already knew that but I just wanted to make sure. Lots of folks I've talked to have assumed that the root directory was always at the same spot on the disk. -- Greg -*- End of Thread. -*- 29187 1-MAY 18:58 Programmers Den RE: Descriptor names... (Re: Msg 29183) From: DCJR To: DWHILL Currently I use the HDKIT system available in the database here for my backups. It's slow, but it gets the job done. I used to use a combination of Pak and the wildcards availble in shell+. The command: :pak -a dirname * will pak all the files in a directory into an archive named "dirname". You can pull the same trick with ar using ar's internal wildcards. Doug James(DCJR) -*- 29201 2-MAY 00:38 Programmers Den RE: Descriptor names... (Re: Msg 29187) From: DWHILL To: DCJR The only problem with pak is that it's bloody slow at times, but I do use it to compress large text files to save space on backup disks. I'm looking at some of the backup utilities, but haven't attempted any of them as yet. Given the amount of work that I had to put into backup manually, I hope one of these will give me a more structured method of backup; I might use it more frequently. --Damon -*- 29208 2-MAY 17:35 Programmers Den RE: Descriptor names... (Re: Msg 29201) From: DCJR To: DWHILL (NR) Pak works a lot faster if you pak into a ramdisk. I try to do that whenever possible. -*- End of Thread. -*- 29188 1-MAY 20:15 Telcom ACIA pak and modem From: KHB To: ALL Help. I am writing an autodialer program in C, and cannot seem to get the serial port initialized. I can open a path to /t2 and send the dialing commands, but it doesn't do anything. If I've got OSTerm running in another window, which has already initialized the modem, it works. To get it to work in a previous Basic09 version, I had to poke directly into the PAK registers. So, how do you do this? Also, the modem has never worked right in this setup either. It won't give me the little OK prompt unless I escape to it while there is a carrier detect. I also can't recieve any of the modems little messages like RING or anything. By the way, I am using a Delta Gold 1200 modem. Any help would be greatly appreciated. Thanx. -Ken Brunell -*- 29189 1-MAY 20:30 Telcom RE: ACIA pak and modem (Re: Msg 29188) From: TRIX To: KHB Part of the problem (the modem messages) is due to the RS-232 Pak. You see, it ignores any characters sent to it if no carrier is present. About the only choices you have for your autodialer are: A) Set DCD from the modem to always be high and interpret the modem messages. B) Leave DCD true, dump the dial string out to the modem, wait for DCD to go high, and pray for the best. Hope it helps. -John. -*- 29203 2-MAY 01:26 Telcom RE: ACIA pak and modem (Re: Msg 29189) From: KHB To: TRIX Ok, thanks. That sheds a little light on the situation. But, I don't think that takes care of the other problem: how do I initialize the port from C? To do this in Basic09, like I said, I had to poke directly into the control registers, but isn't there a proper way to do this? Simply opening a path to /t2 doesn't cut it. -Ken Brunell -*- 29205 2-MAY 03:22 Telcom RE: ACIA pak and modem (Re: Msg 29188) From: KNOT1 To: KHB Did you do "iniz /T2" first? You might want to also try one or more of the following commands (my modem is a SupraModem, but Hayes compatable, so the commands should be the same): "AT&C" - Forces the carrier-detect to remain on. "ATQ" - Causes result codes (e.g. "OK", "RING", etc...) to be returned. "ATV1" - Causes result codes to be returned as words, not numbers. "ATX4" - The *works* for dialing/connect result codes (or one of the other "X" commands). I hope some of this helps! -Jamie Wilmoth (KNOT1)- -*- 29210 2-MAY 20:11 Telcom RE: ACIA pak and modem (Re: Msg 29205) From: KHB To: KNOT1 Yep, that did the trick. II tried iniz /t2, and then dialed, and it worked perfectly. So I used a system call to I_ATTACH to initialize /t2. Thank you. -Ken Brunell -*- End of Thread. -*- 29190 1-MAY 21:04 Programmers Den RE: os9 68k software (Re: Msg 28976) From: THUNDERFNGRS To: OS9UGPRES Thanks for the info. I wonder how much runb 68k costs? Also I have a lot of data stored in comlex variables with several integers What must I do? Will i be able to write a program that reads them and then wri writes the new converted type of 32 bit integer? Can I get a basic09 for 68k that will let me read in my old unpacked basic09 code and recompile the new packed code? And whats so great about osk if there are no windows? I bought the insights book and I am not real happy so far because I don't seem to be learning much that will help me program in basic09 and I do not know C or assembler. I would like to learn C but from messages I have seen the C compiler from tandy needs help/patches to run under os9l2 I get the feeling that you need to know what you are doing to get it going under lii, and I do not know c . I need a package that is ready to go! I also need $100. -*- 29199 1-MAY 23:45 Programmers Den RE: os9 68k software (Re: Msg 29190) From: BUDDCAR To: THUNDERFNGRS (NR) Despite the title of the message I gather that you are concerned about Level II and the Microware "C" compiler. Have no fear it works just dandy. You may be able to find one at a store heavily discounted. If not it will have to be special ordered as the C compiler has long been out of store stock. Dumb but true. Just didn't sell enough copies. The patches you see floating about are mainly to get C to run from a hard disk or to use a different library or to compile from a RAM disk. So long as you have two drives you will be able to plug and go. My old copy, bought back when it first became available works fine in level I and level II for general duty. Not that I am writing device drivers or system code. Bob -*- 29200 2-MAY 00:15 Programmers Den RE: os9 68k software (Re: Msg 29190) From: OS9UGPRES To: THUNDERFNGRS (NR) I don't think you'd have much trouble writing a program to convert old data to the new size INTEGERs, no. Heck, you could write it now, if you think about it a bit, I'd bet. OSK on the new machines does have windows. Patches for getting going with C are in the libraries, not to mention the excellent help available on the forums just by asking. I'm still mostly using Basic and asm, but am trying to learn C now. There's lots of help all around you. Ask! Go for it! best - kev -*- End of Thread. -*- 29191 1-MAY 21:53 Programmers Den RE: C optimization (Re: Msg 24069) From: CCMAN To: GREGL Have you tried Phil's Formatter listed under applications on this database? I have been unable to unPak it with several downloads and tries. Any ideas? Thanks. -*- 29196 1-MAY 22:42 Programmers Den RE: C optimization (Re: Msg 29191) From: GREGL To: CCMAN (NR) Ralph, I don't recall that one offhand but I'll check it out to make sure it's intact. Have you tried using that utility that strips xmodem pad characters on it yet? -- Greg -*- End of Thread. -*- 29192 1-MAY 22:08 General Information RE: Eliminator problem (Re: Msg 29170) From: OS9UGVP To: POLTERGEIST If your manual doesn't have a circuit diagram for that little satellite board, give FHL a call and bug them. Frank forgot to include it in the manual , like it was supposed to be. Besides, he has nothing else to do right now anyway! Bruce -*- 29197 1-MAY 22:53 General Information RE: Eliminator problem (Re: Msg 29192) From: POLTERGEIST To: OS9UGVP Ok, Bruce, I'll do that! By the way, my new 3.5" drive has proven something to me: There does NOT seem to be anything wrong with the floppy controller on the WD-1002. I figured that my /D0 drive is the culprit, since it likes to lock out a whole bunch of sectors when format verifies 'em. Oh well, I should replace the durn thing! NO problems with the 3.5", though. I formatted 10 disks, and I had NO bad sectors. -*- End of Thread. -*- 29193 1-MAY 22:18 General Information RE: DACIA tech info needed (Re: Msg 29184) From: OS9UGVP To: POLTERGEIST Use getstat call $99 (SS.CDSta). It returns a 6551 equivalent status register byte in register [A], except only DCD (bit 5) and DSR (bit 6) are valid. When either bit (or both bits) are clear, then DCD and/or DSR is enabled. When the bit(s) is/are set, then DCD and/or DSR are invalid. For example, if the SS.CDSta getstat returns [A]=$00, then both DCD and DSR are present (enabled). If SS.CDSta returns [A]=$60, then both DCD and DSR are missing (disabled). If it returns [A]=$40, then DSR is enabled but DCD is disabled... wait, thats wrong... if it returns [A]=$40, then DSR is disabled and DCD is enabled. If it returns [A]=$20, then DSR is enabled but DCD is disabled. Those 4 combinations are the only valid possibilities. Bruce -*- 29220 2-MAY 23:07 General Information RE: DACIA tech info needed (Re: Msg 29193) From: POLTERGEIST To: OS9UGVP (NR) I tried those out with RiBBS, but alas, no luck. I did some more checking into it, and I found out that it will handle GetSTT call $28 (ComST) or decimal 130 for M2W. I have an Eliminator version of this, but that didn't work either. So, I took a closer look. He had the carrier callcode that I mentioned above, but also has the carrier bitfield, based on the type of RS-232 cable that you have. For instance, he has one bitfield ($32) if you use a standard RS-232 Pak cable, with pin 6 as DSR, and pin 8 as DCD. Oh, that $32 should be a $20! I have passed on tech information on DACIA and your system calls to Ron Bihler, and I'll see what transpires from that. I just have to find the correct values to put in.. -*- 29223 3-MAY 00:53 General Information RE: DACIA tech info needed (Re: Msg 29193) From: POLTERGEIST To: OS9UGVP (NR) Ok, I may have got the problem solved with my BBS. It seems that RiBBS scans the carrier detect line of the RS-232 cable. Just by guessing what the program does (I don't have source for RiBBS), RiBBS uses GetSTT call $28 to read the settings of the port, then it scans for a carrier detect based on the CD line for your cable. Now, Ron Bihler reccomends a setting of $20 for a standard, pin for pin, RS-232 cable. He reccomends a setting of $40 for a cable where you swap pins 6 & 8. This is done so RiBBS can automatically detect the baud rate, other wise the user still has to bang on the enter key until baud rate is set. Now, figured from the pinouts on the diagram for my modem, pin 8 goes to DACIA port 15, and DSR pin 6 goes to pin 11. Now, how can I figure the carrier bit from this information? -*- End of Thread. -*- 29198 1-MAY 23:03 General Information RE: Help! My computer hates me! (Re: Msg 29180) From: EDDIEKUNS To: DISTO (NR) I think that was it. My roommate helped me resolder all of the leads on the 6809 and I tried several values for R22. I think I have it at 30 Ohms, but it might be 35. I tried 20 and 25 to begin with, and it crashed on both settings after about 10 minutes. I ran it at the current setting for over an hour with no problems. (it = maze) Also, my RAM is running comfortably warm rather than HOT HOT HOT! Sparklies are nearly nil when I start up the machine, but level out at some when it's warm. The pin on the lower (toward the keyboard) right corner of the 6809 (pin on the header, that is) wasn't making good contact at all. A couple of other pins weren't making good contact. What is that corner pin? Eddie P.S. I guess this proves that each CoCo has its own personality -- the value of R22 that worked on Greg's machine crashed on mine! :( P.P.S. Also, I thought that my machine was more damaged than before until I realized I hadn't plugged the power plug into the RAM board!!! P.P.P.S. How bad an idea is it to remove the adaptor on the 1-meg board and connect it to the unregulated voltage going into the CoCo's 5-volt regulator? I know that the regulated 5 V line is wimpy, but how about the unregulated stuff? -*- 29212 2-MAY 21:38 General Information RE: Help! My computer hates me! (Re: Msg 29198) From: EDDIEKUNS To: DISTO (NR) Final message on the topic, I think! :) OK, Everything looked find yesterday until I noticed while on Delphi that after some hard drive accesses KBCom would lose its connection to the serial port. ie: keypresses wouldn't go out the modem. But when I made KBCom close /t2 and re-open it, things would be OK until the next access! I don't understand it. Anyway, today I tuned R22 to 40 Ohms (yesterday it was at 30, it crashed at 0 and 20 and 25.) and things again seem to be OK. I don't know any reliable way to find out for sure. :( No sparklies at ALL on bootup, but after the machine warms up, they arrive, same as before. With the machine on and maze running in the background for CPU usage, I went into the window with the most sparklies (yellow foreground & border on a black background) and then tuned R22 between 20 and 120 Ohms with no noticable change in sparklies. So ... with the 1 meg upgrade, Disto 512k upgrade, old ('86) GIME, and C65 & C66 pulled (did I get those cap designations correct?), R22 needs to be somewhere larger than 30 Ohms and less than 120 Ohms. I haven't examined the higher end at all. (Well, I haven't really tried anything above 40 except for very short periods of time except for 120, which I know crashes!) Eddie -*- 29222 3-MAY 00:49 General Information RE: Help! My computer hates me! (Re: Msg 29212) From: EDDIEKUNS To: DISTO (NR) Just when you thought it was working.... It looks like the AciaPak problems were related to dirty connections. I cleaned up all the connections (MultiPak & rs232 pak) and they went away. But ... once I tried using all 1-meg, some old problems returned... I don't know what this problem is, but it doesn't crash the machine. Basically, when I run a program on a graphics screen which is in the upper 1/2 of memory and uses the auto-follow mouse, I get this line of garbage which flashes (more away than there). The line of garbage is about as high as a line of text. It appears on type 6 & 7 graphics windows (haven't tried any other types). It DOESN'T seem to appear on graphics screens which don't use the autofollow mouse. And it definately doesn't show up on screens in the lower 512k of memory. To test, I booted up in 512k and ran MVCanvas from a text window (which it converted to a graphics window). Then I typed 'mega' to enable the top 1/2 of memory and ran MVCanvas from another text window (which it converted to a graphics window). I noticed that I DID NOT get the junky line in the screen in the lower 512k, but I DID get it in the screen in the upper 512k. But if I repeated the experiment (rebooting) and just created graphics screens with no autofollow mouse, I didn't get that behavior. (I didn't get the line of garbage.) While watching the flashing line, I changed the value of R22 between 0 and 120 Ohms with no systematic change in the behavior of the flashing bar of garbage. I also tried booting up in 512k mode w/ the jumper at position 1 & 3. I was never able to create the flashing bar no matter what I did. So ... it seems that the bar is related to displaying a screen in the upper 1/2 of memory when you're also doing stuff in the lower 1/2. The garbage looks like actual memory. Almost as if every now & then the GIME (or wherever the video circuitry is) pulls the video info out of the wrong address, or perhaps the correct offset into the wrong 512k? Hmmm ... I could try looking at it with composite video & see what I see, eh? I dunno. Is it time for me to ship you me CoCo yet? Or perhaps visit with you & Kev for a day so we can figure this out? Is anyone else having problems like this? At least I have the timing stuff fixed and the CoCo isn't crashing on me anymore. And AciaPak isn't acting any more odd than is normal for such a buggy module. And my memory is running comfortably cool. Could be worse, I guess. Eddie -*- End of Thread. -*- 29202 2-MAY 01:17 General Information Hhoward medical MPI From: IVANSC To: ALL I bought one of the earliest Cchris Hawkes multipack susbtitutes & for some reason plugging the RS232 pack in drives thre thing nuts. If the pack is in situ at power-up (from a power strip) it seems to function as it is supposed to, but if I then re-set ( even to the three mugateers) the poor little Coco comes up in ECB instead of DECB!!!! Repeated cold and warm resets do nothing to alleviate the problem, only a complete power down seems to do anything - any of you bright guys have any ideas, as Chris haw kes says it has him stumped and he designed the dern thing!!!! Oh, by the way - I have a vertical card connector on the end 0of the Coco motherboard and the "mpi" sticks straight up with the hard and floppy controller cards and RS232 leaning out at righ t angles over the motherboard to facilitate fitting inside my teeny little AT baby case! Aany help would be appreciated. P.S. Just who IS doing the mystery upgrade to gfx2/os9/basic09 alluded to by Dale Puckett and when/where can we buy it???? s -*- 29207 2-MAY 04:39 Programmers Den RE: Text screen attributes (Re: Msg 29175) From: PAGAN To: OS9UGPRES Kevin Yes I do send the text out all at once. My problem was that I wanted to map the buttons as positions on the screen to simplify determining which button is selected if I decide to write a graphic front end. I've tried a few thing since I posted that message and have decided that "sticky" buttons like are used in Guide rather than fixed position buttons like Hypercard's are probably better. It makes the bookeeping a little more complicated but will probably result in a better performing program overall. Since I do want to maintain upward compatibility with the next generation of OS9 machines I agree that messing with the hardware is a bad idea - I was just hoping that there was a way to do it via some system calls that aren't documented in the manual but if the capability isn't there I'll live with it. OS9 is just too flexible an operating system to be faulted for something as trivial as this. As for a "slight" delay - I'm not so sure. One of the problems with Maxthink (early versions) for MS-DOS machine was the delay in scessing and displaying the next node. Neil Larson, Maxthink's author, claims that a delay of over a few tenths of a second can break up the continuity of information flow - which is what hypertext is all about. Since I'll probably be using a keyboard driven interface anyway the problem is moot. Thanks for the advice. Stephen (PAGAN) -*- 29228 3-MAY 20:09 Programmers Den RE: Text screen attributes (Re: Msg 29207) From: OS9UGPRES To: PAGAN (NR) Stephen... Thanks. Can you tell me more about "sticky buttons" (vs fixed-location)? Sounds intriguing. - kev -*- End of Thread. -*- 29209 2-MAY 19:32 Users Group MOTD From: OS9BERT To: DWHILL (NR) Did you get the latest MOTD yet? I thought you said something to me the other night on-line about my review on MVCanvas. I have not received my copy of MOTD yet. I hope the Postal Service didn't chew it up! Bert Schneider -*- 29211 2-MAY 21:07 Users Group RE: MOTD (Re: Msg 29209) From: MIKEHAALAND To: OS9BERT (NR) I didn't get mine either!!! I've had orders as a result of the review and ad in the same issue tho.... Hope I get my copy soon. Mike -*- 29219 2-MAY 23:05 Users Group RE: MOTD (Re: Msg 29209) From: ZACKSESSIONS To: OS9BERT (NR) Bert, I received my MOTD last week sometime. Your review (front pager!) was very complete, but alas, untimely in that V2.0 is now available, as of the Chicago Fest. Maybe a "follow up review" may be warrented? Zack -*- End of Thread. -*- 29213 2-MAY 21:40 General Information RE: Reluctant Graphics (Re: Msg 29066) From: JIMHARRISON To: OS9UGPRES Kev, Thanks for the suggestion re: my strangely intermittent graphics. The problem has been solved by replacing the GIME chip. All is now well again... Jim -*- 29214 2-MAY 21:41 General Information RE: Reluctant Graphics (Re: Msg 29083) From: JIMHARRISON To: AJMLFCO (NR) Allen, Well, the mystery has been solved at last, and my CoCo-in-an-AT-case is working perfectly now. As I mentioned earlier, suspecting a malignant GIME, I ordered a new one from Tandy National Parts last week. It arrived yesterday, and upon popping it into the CoCo, the weird intermittent graphics problem went away instantly. The poor old power supply has been vindicated after all ... The old GIME was the early (1986) version. Apparently it was pretty marginal, and did not take well to the transplant into the AT case; it had worked just fine for years in the standard CoCo case though. Anyhow, all is well now. Thanks again for your interest and suggestions. Jim -*- 29218 2-MAY 22:42 General Information RE: Reluctant Graphics (Re: Msg 29109) From: JIMHARRISON To: JAYTRUESDALE (NR) Jay, Thanks for your suggestions. Although the power supply WAS a prime suspect, it was innocent in this case . . . I replaced the GIME chip with a new one, and the problem disappeared instantly! Jim -*- End of Thread. -*- 29216 2-MAY 21:43 General Information ATCoCo From: JIMHARRISON To: MIKEHAALAND (NR) Mike, At last, the project of transplanting my CoCo into an AT case has been brought to a successful conclusion. The strange reluctant graphics problem disappeared when I put in a new GIME, and all is well now - VERY well! I really like the new package, especially with the IBM keyboard. Thanks for your interest and support during the project!! Jim -*- 29221 3-MAY 00:12 General Information RE: help (Re: Msg 29164) From: KENHALTER To: DCJR thanks for the help. I can use all I can get I finally got my ramdisk running by putting in my bootfile so I only need to swap disks once at the most. It's great! I've gotta get another mechanical drive tho. The ramdisk is fast and all but it's just not the same. thanks again. Ken Halter -*- 29226 3-MAY 17:44 General Information RE: help (Re: Msg 29221) From: DCJR To: KENHALTER (NR) Get the biggest, fastest drive ya can ;) If you can swing a hard drive, do it! Then the only time you worry about swapping disks is when you're doing backups, or like me, restoring the sucker after swapping controllers. -*- End of Thread. -*- 29224 3-MAY 01:44 General Information 3.5 inch floppies From: DEANL To: ALL This is for anyone who has successfully connected the external 3.5 inch Tandy drive originally designed for the 1000 HX. I got a good deal on one, but I need a little advice on hooking it up. My problem: the drive was originally meant to be powered for the 1000 HX. I built a power supply, so no problem there, but I'm not sure where to hook it to the drive itself. The drive has a small distribution board that serves as an edge connector when used with the HX, and I found a pad on it that is marked "12v 5v GND GND". Should I hook up the power supply there, or should I take it straight to the drive and bypass the distribution board altogether? Same problem with the cable: should I hook to the cable to the edgecard, or should I bypass it and go straight to the double-pin connector on the drive unit itself? I want to run it as a drive 2, so I moved the jumper ti that position. Is that correct? Any help anyone can give me would be appreciated. Dean Lawrence (DEANL) -*- 29227 3-MAY 18:48 General Information RE: 3.5 inch floppies (Re: Msg 29224) From: DODGECOLT To: DEANL (NR) Yea, I use one of those with my system. You don't need that little board- all it does it convert the 30 pin connector Tandy uses for external drives to power and normal-drive hookups. -Mike -*- End of Thread. -*- 29229 3-MAY 20:10 General Information No permission? From: BILLBEISSERT To: ALL When using OS9GEN to make a new OS9BOOT I get a "NO PERMISSION" error if I use this format: OS9GEN /D1 /D0/BOOTLIST However, I can CHD /D0/BOOTLIST then OS9GEN /D1 and enter each file manually with no problems. What am I doing wrong? Bill -*- 29230 3-MAY 20:15 General Information RE: No permission? (Re: Msg 29229) From: OS9UGPRES To: BILLBEISSERT (NR) Bill - here's one possibility: did you first CHD to the directory where all the modules were before starting the "os9gen /d1 Reply, Add, Read, "?" or Exit>