29967 6-JUN 02:37 Programmers Den Signals From: EDDIEKUNS To: ALL If you leave the interrupt & abort signal on, and also set a keyboard signal, and someone presses -- is the keyboard signal still set? Is there input waiting to be read? (The ) Or is the completely separate from the "normal" keyboard signal, leaving its status untouched? (Either way, do you have to read the from the keyboard to throw it away?) Eddie -*- 29986 7-JUN 18:35 Programmers Den RE: Signals (Re: Msg 29967) From: DODGECOLT To: EDDIEKUNS Eddie- If you still have the interrupt and abort chars set in the path descriptor, then CC3IO (or ANY SCF driver) will send the signal to your process. No char is put in the buffer... -Mike -*- 29990 7-JUN 19:19 Programmers Den RE: Signals (Re: Msg 29967) From: BILLDICKHAUS To: EDDIEKUNS Hopefully Kevin will answer this, but this is like the ssig stuff, its handled by the device driver. So if you're working from a terminal, it may be different than if you're at the CoCo keyboard. I don't know about CC3IO, but ACIAPAK will send the abort/interrupt signal, and then immediately follow it with the ssig signal, which in almost every case will get trashed, since there can't be more than one signal pending for a process. The data byte is also placed in the input buffer (probably so the current process can figure out where in the data buffer the abort/interrupt occurred) so you will have to read it. Bill -*- 29996 7-JUN 22:11 Programmers Den RE: Signals (Re: Msg 29986) From: EDDIEKUNS To: DODGECOLT Thanks! That's what I wanted to know. Eddie -*- End of Thread. -*- 29968 6-JUN 03:22 Programmers Den Aciapak bugs. Chapter 3. From: EDDIEKUNS To: ALL I don't get it. OK. Here's the story. I have a highly intermittent problem with Aciapak. KBCom obeys all the rules. All signals are released (to the window & rs232) before calling any extension, and released again on returning from the extension just in case! And then asserted as necessary once the extension processing is done. The particular extension in question is equally careful with signals, making sure all are released before quitting. I'm passing all necessary paths to the extension. (Path 0 = rs232, Path 1 = window. Path 2 = logfile, if any, or window otherwise.) So the extension is *not* opening its own path to /t2. The extension sets the parity/stop bits it needs & returns settings to the original upon quitting. KBCom forces settings to what it wants just to be sure. (In case you ru an unfriendly extension!) While the extension is running, KBCom is waiting for it. (It's run via system() call, thus, through the shell. This is so people can get fancy & use pipes & such and also any shell features like wildcarding. ie: upload *.c) KBCom does NOT close the rs232 (or ANY!) paths, but it's not reading from them either as it's sleeping in the system() call. After returning from the extension, there's a 1/2 second pause or so (on Delphi) and then I get the "..... files successfully transferred" message and the "ACTION>" prompt. The problem: *occasionally* after typing about 3 keypresses, Aciapak will lock up. Dead. The confusing thing is that the first 2 (or so) work fine! The character is sent to Delphi, echoed back, read, and put on the screen! I put debugging code in KBCom at one point and proved that the last statement executed before KBCom froze was a read(rs232, buffer, waiting); where waiting = 1;. It never returned from there. The odd thing is that the problem is so intermittent in a weird sort of way. Some nights, every single download or at best every other does this. Some nights, I can't reproduce it for the life of me. It happens with and without background processes running. (I thought that was a factor at one point, but I've seen it happen in both cases.) On *very* rare occasions (ie, once or twice), KBCom has locked up in Aciapak on a burst of line noise. (I had a weird connection where I kept getting bursts of garbage followed by long periods of normalcy! Actually, I can only remember once ever that this happened.) I have the diode IRQ hack and an old GIME and a 6551 (not 6551a) in my Deluxe RS232 pak. Can *anyone* out there help me figure this puzzle out? I'm completely clueless. Could this be a hardware problem that's causing Aciapak to freak out? Perhaps my IRQ hack is giving me problems? No-one else has reported the above problems with KBCom! I don't know of any other programs which are able to fork other term programs in quite this way, so I don't know how to go about testing this! (I know that WizPro can, but I don't quite know if it's the same. It's more like a program overlay than a real _os9fork(), right? I dunno. Hmmm. Perhaps xcom9 can?) Please help me before I lose all my hair! My scalp doesn't need any help! Eddie -*- 29977 7-JUN 00:41 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29968) From: EDDIEKUNS To: EDDIEKUNS A little bit more information which I noticed tonight. I downloaded a file from the databases. After it finished and I was back at the ACTION> prompt, I wanted to be reminded of all the filenamesof the group, so I started to type des. What got displayed was 'de' and it froze. I can't remember if I hit the or not, or if I did, when I hit it (before or after it froze). ANYway. I went into another window to 'procs' 'kill 3' (KBCom's PID). I noticed that as soon as KBCom was killed, some characters were sent out! Almost as if the kill woke up Aciapak and it unfroze & send out everything in its buffer before (or after?) KBCom was killed!!! (And I then saw the recieve light go on as I started to recieve the description.) Upon restarting KBCom, I pressed and got the rest of the description ( after the More? prompt). Does this help in figuring out why Aciapak is dieing? Eddie -*- 29987 7-JUN 18:40 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29968) From: DODGECOLT To: EDDIEKUNS Well, my term program (which will be released to the public sometime soon...) FORKs the appropriate program for file transfers and stuff. For kermit, I don't have to set up paths- kermit will open /t2 and use the current settings for baud/parity/word length... I haven't experienced any lockups after file transfers, tho it lock up randomly after sitting around for a week or so of use... Bruce Isted posted an update to the DACIA drivers for the eliminator- also included was a new ACIAPak (not as fancy as the DACIA driver, tho) and a set of Clock modules which help fix lockup problems at the source. Maybe you should try them out? -Mike -*- 29993 7-JUN 19:26 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29968) From: BILLDICKHAUS To: EDDIEKUNS If you are using system(), then you are involving shell in the calling sequence. Shell might be getting in the way of passing paths. If you are using shell+, it might aggravate the problem, since it uses non-blocking (signal driven) input. It would be better to pass the current serial port and any flags to the extension as options on the command line, just as if it had been typed in at a shell prompt. ACIAPAK can lock up if XON/XOFF are enabled and it receives an XOFF as garbage. There is no way to unlock it, it will wait for an XON forever. All of the other terminal programs allow forking a shell, but not an extension, except Wiz, which (I think, not sure) calls extensions as subroutines, not as separate processes. Bill -*- 29997 7-JUN 22:16 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29987) From: EDDIEKUNS To: DODGECOLT I must have completely missed that posting! I'll go and try it out. I'm beginning to think this problem I'm having is hardware related and not KBCom. (Well, no-one else using KBCom has mentioned any problems like this.) My CoCo seems to have been flaky from day one. (There were some programs I wrote which used the CPU so intensively that no keyboard input would work in any window. Not even the key! If I mashed my thumb down on it for a couple minutes, it would flip screens. But other people ran the program with no such problems.) P'raps I should check my IRQ hack. This is really irritating! Thanks for the help. Eddie -*- 30000 7-JUN 22:33 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29993) From: EDDIEKUNS To: BILLDICKHAUS (NR) Yes, I'm using shell+. The reason I'd like to be able to use system() rather than os9fork() to run extensions is so I can take advantage of the shell's features like wildcarding. However, I was originally running extensions (still via system()) by telling them to open their own path to /t2. The problem is independent of which way the extension gets its path to the serial port. Both programs (KBCom & extension) turn off XON and XOFF to avoid a garbage XOFF locking me up! Thanks for all the help! I just wish I could solve this problem! If only it weren't so intermittent. Eddie -*- 30004 7-JUN 22:56 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29968) From: MAREK To: EDDIEKUNS Eddie, I am using a Disto 4in1 board and here is another bizarre tale to add to your list. Under OS9 I can use the Disto's ACIA with no problem what so ever! If I try to use a term under RSDOS, TALK ABOUT LINE NOISE most definintely a timimg problem. Here is the situation. Take Ultimaterm..I can dial and comm fine..when I go to *ANY* of the online menus like alt-D for the Disk Menu the modem/acia goes crazy starts getting all kinds of junk--it doesn't matter wether I am online locally or on any of the major $ources, to make it even more interesting the problem causes the RD light on my modem go blinkety blink: that's right the RD not SD but RD. This happens on *ANY* modem I use. My solution--I dropped RSDos completely for communication! -Michael -*- 30007 7-JUN 23:06 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 30004) From: EDDIEKUNS To: MAREK You're problem is backwards from what people normally experience! Just goes to show ya that each CoCo has a unique personality. Eddie -*- 30013 8-JUN 21:04 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 30007) From: MAREK To: EDDIEKUNS (NR) I just thought you might find that interesting. -Michael -*- 30028 9-JUN 03:59 Programmers Den RE: Aciapak bugs. Chapter 3. (Re: Msg 29977) From: KNOT1 To: EDDIEKUNS (NR) Now that's starting to sound a lot like the problem I had! But mine wasn't so nice as to wait until AFTER I finished a download! You said you did the "diode hack," but did you also tie the interupt lines in your Multi-Pak (assuming your using a Multi-Pak) together? I did both of those and I haven't yet had a single recurrence of the problem. What I felt was similar was when you said it sent characters after you killed the process. I wrote (and am still working on) my own terminal program, and from time to time it would lock up much like you said. Thinking that maybe a stray XOFF character had been received I went to another window and did a "display 11 >/T2" hoping that this might help. Nothing happend, the display command just "locked-up" and nothing went to the modem (no SD light). Muttering something like "Great! ANOTHER locked-up program" I hit the Break key once and nothing happend, then I hit it again and I saw the SD light flicker once. The character was sent out! (Further experimenting has verified to me that that was the character sent.) This also seem to have "unlocked" the system enough to exit the program normally (though not to continue using it). I then found out that closing ALL open paths to the RS-232 pack would restore the system to normal operation. I then made this a function of my program that would let the user hit a key (Alt-X in my case) and it would then print "Closing..." and close any paths to /T2, then print "Opening..." and re-open the paths and restore the protocol, and then print "Finished." Sometimes it would still lock-up on the "Closing..." part, but going to another window and doing "display 11 >/t2" and pressing Break a couple of times would free it up. It's doen't appear to be important WHAT you display to /T2, just the sending of a signal (2 in this case) to a process that is currently "locked" in a write (maybe a read also?) to the RS-232. Here's something that probably won't help but it might show something. Go to a window with a Shell running and do a "tmode" to find out its window name. Then press backspace a couple of times (just to make sure you're not in Shell+'s "No-Lock" mode). Then go to another window and type something like "echo Hello there... >/W#" with W# being the other window. It locks-up and nothing shows up on the other window right? Now, on the window with the locked-up "echo" press Break TWICE. Still locked up, right? Go look on the other window. Oh ho! There's the text! And now THIS window is locked up! Now press Break on this window. ERROR #002 and back at a Shell prompt, right? Now go to the window with the locked "echo". Hey! Now it's unlocked with an ERROR #002 also! Odd... yes? no? WHY any of this does this I don't know, but I hope something here may be of some help to you. If you have any questions about any of this just ask away! Like I said, after I did those two hardware fixes I haven't had a single problem of that type since. -Jamie (KNOT1)- -*- End of Thread. -*- 29969 6-JUN 19:12 Device Drivers Ramdisks & 1Meg Upgrade From: RADARBUZZ To: ALL I Just ordered the 1Meg upgrade and I seem to recall something about the RAMMER ramdisk driver (That I presently use) here in the database not working with 1Meg systems. Can somebody confirm this? If so, what's a good ramdisk driver to use? I would like one that will free up memory if I do a deiniz /r0 when I'm done using it. Thanx to any and all that can provide the info. -Jeff -*- 29970 6-JUN 23:14 Device Drivers RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969) From: ZACKSESSIONS To: RADARBUZZ (NR) Yes, the word is that Kevin Darling's RAMMER ramdisk driver will NOT work properly on a system with the Disto 1MEG upgrade. Best bet is the RAM driver with the "Development Pack" if you're lucky enough to be able to get a copy. I understand that Tandy warehouses are running out fast! Zack -*- 29971 6-JUN 23:15 Device Drivers RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969) From: EDDIEKUNS To: RADARBUZZ (NR) Right. RAMMER will *not* work when you have the full 1-meg enabled. This is because it manipulates the GIME directly. I switched to the Dev Pak RAM disk. It works fine, but stores the size information in a really weird place in the descriptor! (SCT -- Sectors / Track -- is where it stores the # of 256-byte sectors you want. I guess it considers the RAM drive to be one HUGE track!) Eddie -*- 29988 7-JUN 18:43 Device Drivers RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969) From: DODGECOLT To: RADARBUZZ (NR) Look in the Device Driver database- there is a new VDD ramdisk driver in it which fixes a bug in the original VDD from the developer's system. Note that you don't need the original VDD to use it- your old /r0 descriptor will require a few changes, tho. I think there are some docs included in the file. -Mike -*- End of Thread. -*- 29972 6-JUN 23:17 Graphics & Music Weather Radar From: ZACKSESSIONS To: PAULSENIURA Paul, I downloaded your "Weather_Radar" package last night, and I have a few comments, it I may. First of all, the VEF pic file you include is not exactly in "true" VEF format. The first two bytes of a VEF pic file from a Type 8 window whould be $0000, not $0008. And the file length should be 32018, not just 30738 bytes. After I patched the $08 in offset $0001 to a $00, it displayed just fine, even though it didn't fill the screen. But, really, a FINE job of creating a map of Oklahoma. Even with _county_ lines! Now how 'bout us poor folk who lives elsewhere in the US of A? Color Weather Radar sites do cover most of the country y'know. Someone from each state gonna have to take it upon themself to spend the time creating a VEF map of their state? Now, as to getting the data to plot in the first place. When you mention, "I hope we can get a tie-in to the NWS for access to their current B-Scan weather files.", I assume you mean Delphi or GEnie? Well CompuServe has been getting this feed for years. Do they have a monopoly on it? Why can't someone else, ie, Delphi or GEnie, make this data available also? Lastly, in case you're interested, I have already written a little ditty which I use to "put the maps in motion". I download GIF format maps from CompuServe (only because Delphi don't have 'em!), convert them to VEF with GIF2VEF, and then use my animation program to put them into motion. Looks REAL neat. Just like the Weather Channel! (btw, anyone besides me remember when all the Weather Channel did was scan a TV camera back and forth on a bunch of instruments!) Comments? Zack -*- 29973 6-JUN 23:22 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29945) From: PAULRINEAR To: PAULSENIURA Very interesting piece of writing and I agree on most counts. The one thing I take exception to is graphics on the COCO3. Can you think of a nice piece of action game software that will prove me wrong when I say COCO3 graphics are "coarse and slow". I'm comparing this to the Nintendo Entertainment System. Entertainment System. Paul -*- 30027 9-JUN 03:57 General Information RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29973) From: KNOT1 To: PAULRINEAR (NR) I'm assuming you haven't seen "Zenix" from Gosub Software! Give it a try if you can and reconsider that exception! -Jamie (KNOT1)- -*- End of Thread. -*- 29974 6-JUN 23:23 Device Drivers RE: burke vs disto 4/1scII (Re: Msg 29964) From: TARDOS9 To: MAREK Marek, Did you attempt to disable the hard drive controller rom to correct this. It is my uns understanding that it is this rom that overwrites this address space, so THEORITICALLY disabling the rom should resolve this? Thanks for your response. -*- 30002 7-JUN 22:49 Device Drivers RE: burke vs disto 4/1scII (Re: Msg 29974) From: MAREK To: TARDOS9 Actually I didn't try do do that. But the code slot-switches the MPI anyway and it appeared that *ALL* interrupts were being switched to one slot or the other hence the problem. :I inherited the B&B and got no docs on the controller (a DTC 5150 CRH) so II haven't the faintest idea which jumpers to move. sorry I couldn't be more help. -Michael -*- End of Thread. -*- 29975 6-JUN 23:56 Telcom RE: OSTERM (Re: Msg 29940) From: ELM To: GREGL Thanks, I'll try that log on combination. -Len -*- 30023 9-JUN 00:51 Telcom RE: OSTERM (Re: Msg 29922) From: RICKADAMS To: ELM (NR) I have that "garbage characters" problem with Telenet whenever I log in using some OS9 terminal programs and starting out with three carriage returns. Starting out with . (a return, a period, and a return) sets things up to work ok. -*- End of Thread. -*- 29976 7-JUN 00:29 Grits & Gravy Interleave factor From: KENHALTER To: ALL Am I correct in assuming that "sector interleave" is to os9 the same as "skip factor" in rs dos? If not, what's the difference? I'm writting a quick disk to ramdisk dump program but it only works fast if I know the exact order that the sectors are in. Any help will be appreciated. Ken Halter -*- 29978 7-JUN 00:48 General Information New Guy From: PAULRINEAR To: ALL Greetings, I am brand new to this service and would like to say hi. Also, have a question: are most of the files available here compressed or not? I downloaded something out of the utilities section and can't get it to work. Paul -*- 29984 7-JUN 03:43 General Information RE: New Guy (Re: Msg 29978) From: TIMKOONCE To: PAULRINEAR Paul, Many of the files are compressed with the "AR" or "PAK" programs. You should probably start by downloading both of these from the Utilities database. Ask if you need more help, Tim Koonce -*- 29995 7-JUN 22:08 General Information RE: New Guy (Re: Msg 29978) From: EDDIEKUNS To: PAULRINEAR Many files are archived with ar or pak. You can tell when the files have an extension of '.ar' or '.pak' that you need to use the respective program to dearchive them. Eddie -*- 30003 7-JUN 22:50 General Information RE: New Guy (Re: Msg 29995) From: PAULRINEAR To: EDDIEKUNS Ed, This one turned out to be a C source program. Surprise! It's called "phony.c" anyway, it wont compile. I keep getting a bad identifier error in line 65, but the file doesn't seem to have a line 65. Paul -*- 30006 7-JUN 23:04 General Information RE: New Guy (Re: Msg 30003) From: EDDIEKUNS To: PAULRINEAR (NR) During the compile ... does it show you the line it's complaining about? If you could post here the line that's dieing and the couple around it, we might be able to help out. (Assuming a program with the name phony.c is meant to compile! ) Eddie -*- 30009 8-JUN 18:46 General Information RE: New Guy (Re: Msg 30006) From: DODGECOLT To: PAULRINEAR (NR) POssibly you have some padding at the end of the file? This will make the compiler complain alot (or if you give it to ASM, it will crash!) -Mike -*- End of Thread. -*- 29979 7-JUN 01:10 Device Drivers RE: 720K DISK DRIVE (Re: Msg 29954) From: MCIRISH To: MARTYGOODMAN (NR) HI MARTY, I TOOK THE DRIVE BACK AND ASKED THEM TO RUN IT ON ONE OF THEIR 1000'S, THEY DID AND IT DIDN'T WORK. THEY REPLACED IT FOR ME AND EVERY THING IS GREAT NOW. I DON'T NOW WHAT TO DO WITH ALL THAT SPACE ON ONE DIS KNOW WHAT TO DO WITH ALL THAT DISK SPACE, BUT I'M SURE I'LL THINK OF SOMETHING. THANK ALOT FOR THE HELP, IF THERE IS ANYTHING I CAN DO FOR YOU, LET ME KNOW. ---JOE -*- 30012 8-JUN 20:40 Device Drivers RE: 720K DISK DRIVE (Re: Msg 29979) From: DCJR To: MCIRISH (NR) There's only ONE thing to do with disk space.... Fill it up... DCJR(Doug James) -*- End of Thread. -*- 29980 7-JUN 02:02 General Information RE: Pictures Needed (Re: Msg 29905) From: DALEP To: DICKWHITE (NR) Dick, Thanks for the reply. Yep, your on track. We're looking for pictures ... an anecdotes. I have a transcript of Jim Reed's interview with you ... but hope to be back in touch with you by phone when we get this thing organized. Right now, it's all a bit overwhelming ... I've finally made it up to March of 1983 ... with just a list ... no details. But, we're plugging away. Again, yes we can use your pictures!!! Interesting that my basement fits the same definition. Best Regards, Dale -*- 29981 7-JUN 02:05 General Information RE: kissable os9 (Re: Msg 29949) From: DALEP To: TEDJAEGER Ted, Thanks, We're plugging away on a Gradebook program for the September issue now. Hope you will find it useful. That's the education issue. We have already completed a column for July and August so you should see one soon. BTW if you have any anecdotes for the CoCo History Book ... or know anyone who does ... please let us know here. Thanks Again, Dale -*- 30010 8-JUN 20:33 General Information RE: kissable os9 (Re: Msg 29981) From: TEDJAEGER To: DALEP (NR) I'll look forward to the gradebook issue! I forgot if I mentioned it but I am a college professor--teach psychology. --Bests, TedJaeger -*- End of Thread. -*- 29982 7-JUN 02:24 Graphics & Music RE: graphic (Re: Msg 29938) From: TIMKOONCE To: NES If you're interested in viewing 16 grey-scale images, take a look at Mike Haaland's "ViewPIX" viewer for some ideas. Also, my VIEW program can display pictures in DS69B "PIX" format. Details on that picture format are in the databases as well. As for OS9 drivers, a number of people here can help you with it. The best place to start is to probably look at the source for some of the drivers in the databases here. As a hint, it might be easiest to write the driver as an "SCF" driver, so you could carefully study the technical reference section of the OS9 manual to find out more. - Tim Koonce -*- 30001 7-JUN 22:48 Graphics & Music RE: graphic (Re: Msg 29982) From: NES To: TIMKOONCE (NR) Thanx for the info Eric Stringer (NES) -*- End of Thread. -*- 29983 7-JUN 03:10 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29946) From: TIMKOONCE To: PAULSENIURA As Eddie already pointed out, one BIG difference between CoCo/OS9 and those other systems is simply that they've been out a lot longer, and a lot more people are using them. Software takes time to develop; time measured in YEARS, not in months or weeks. CoCo3/OS9 has only been out for about 3 years, which is a very short time. ONt op of that, there aren't very many users, and few of those users are willing to shell out the money it costs for high-quality software. I experienced heavy-duty culture shock recently when I talked to some people about a Mac terminal program... the program sells for $300, and the company was getting calls from people who were asking how to use it with $600 modems attached to their $5000 computers. People with $129 systems probably don't have $300 for a terminal program! Which tends to not attract the big commercial houses. OS9/68000 does have a lot of free software already: UUCP, ARC, Hack, gobs of Unix stuff, and it's growing fast. Kevin Darling, Inc. knows CoCo3 windows pretty darn well, and one of the TOP priorities for the MM/1 from KLE is CoCo3-compatible windows. It'll be there! BTW, you don't need SBF to drive a tape, you can just write an SCF driver. Tell us what you know, and maybe people on here can help you with that tape drive. A lot of people have been interested in getting decent tape drives, and maybe you have the information and motivation to get it working! Good Luck! - Tim Koonce P.S. Unfortunately, CoCo3/OS9 has never been an "out of the box" system. KLE or FHL should doubtless do better. -*- 29985 7-JUN 03:55 General Information RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29946) From: TIMKOONCE To: PAULSENIURA Hmmm.... A lot of people would argue with you over some of those things being "standards". Personally, I don't consider SEA ARC or FIDO quite the "standard" that you seem to. And ANSI is pretty far from a standard in my opinion. But, then again, I suppose someone who works with IBM mainframes might not consider Compress, TAR, or UUCP very "standard", either. (I have the first two already on OS9, and word is that UUCP will be ready by the end of the summer.) - Tim Koonce -*- End of Thread. -*- 29989 7-JUN 19:19 Programmers Den RE: Aciapak blues -- Chapter 2 (Re: Msg 29935) From: BILLDICKHAUS To: EDDIEKUNS The following assumes you are using the stock LII ACIAPAK or at least a patched version of it. If you are using a later version or an alternate driver (like DACIA), then things are a little different. Also be aware that the handling of _ss_rel and _ss_ssig are up to the device driver, so this answer only applies to ACIAPAK. I'm also not sure whether SCF does anything "automatically", but I don't think so. (Kevin?) Any active _ss_ssig is cleared when the device is initialized. A device is only initialized when a path is opened to the device, and the device user count is zero. If the device has been INIZ'd, or there are other processes with the device open, then an additional open will not cause the device to be initialized. An active _ss_ssig is also cleared whenever an SS.ComSt setstat is issued, either explicitly, or implicitly when an SS.OPT setstat is issued with the bau/par values changed. Bill -*- 29998 7-JUN 22:25 Programmers Den RE: Aciapak blues -- Chapter 2 (Re: Msg 29989) From: EDDIEKUNS To: BILLDICKHAUS (NR) Yes, I'm using a patched version of Aciapak. So does that mean if you issue an SS.OPT with the *same* values then it will *NOT* issue a SS.ComSt? Basically, since I'm already using 8N1 and the baud rate doesn't change, all I do is issue 3 _ss_opt() calls with the settings I have already. (One in XYModem to set up the way we want it. Another when it quits to reset to original settings. Another in KBCom to make sure the extension was nice.) Do you have any idea what conditions will cause Aciapak to freeze? Eddie -*- End of Thread. -*- 29999 7-JUN 22:26 General Information RE: Config (Re: Msg 29429) From: RTHOM To: GREGL I with you, Greg! I HATE manuals that tell me what can be done without telling me how to do it--not even giving me a hint where to start! But I also agree that there is such a thing as too MUCH simploicity. Come down to it, I doubt there's much differen ce in our view of the problem. (Or "views", I guess...) Ray -*- 30005 7-JUN 23:02 General Information MM1 demo From: NES To: ALL I just got thur seeing a demo of the complete MM1 system (or 2001 system if you think of the letters as Roman numrals). It run's under os9 with the coco 3 type windows, I was impress with the graphics demo, they where showing GIF's on a CM-8 320 x 400 256 colors. You wouldnt beleve the CM-8 could produce VGA graphics, as well as it did with the MM1, also set up an 120 x 60 text window, and you could read it. I was just blown away by the show KLE put on for our coco club. Keven Darlin(sp) has done a top job of writen the graphics display program for the MM1. and all the others who are putting together the MM1. -NES -*- 30031 9-JUN 04:41 General Information RE: MM1 demo (Re: Msg 30005) From: SANDRIDER To: NES (NR) Thanks for the mini-review! I'm very excited about this new machine, and any little tidbit you can drop our way are most appreciated. How fast was the GIF decoding? CRW (P.S. Yep... I'm new to Delphi... first message. Greetings everyone!) -*- End of Thread. -*- 30008 8-JUN 18:18 Graphics & Music framed window within a framed window From: ZACKSESSIONS To: NES (NR) Eric, About that programming problem you are having, opening an overlay window on a Framed window and attempting to WnSet the OW to a Framed window, too, as you are seeing, I don't think that will work. I did mention one workaround, writing the code which would run in the OW as a separate binary and fork a process to it in the overlay. I know that will work, but may cause programmatic problems, like how to send data obtained in the forked OW back to the original program? Here's an idea (and I think Kev has mentioned this once already). 1) Do a GetBlk on the area in the Framed window equal to the size of the OW you were trying. 2) Unprotect the current window. 3) Open a path to the next available window. 4) DWSet the window, and the WnSet the window. 5) Do the processing you need to do in the window. 6) close the window with DWEnd and close the path to the device. 7) re-protect the current window. 8) PutBlk the buffer back on the window. 9) KilBuf the buffer sinca ya don't need it anymore. Does all this make any sense? Zack -*- 30011 8-JUN 20:37 General Information hardware hacking From: TEDJAEGER To: ALL I have access to an old RS 5 meg hard drive which I figure I could use under os9. I have the 15 and 35 meg descriptors that RS distributed with Level 1 ver 2.0 but no 5 meg descriptor was ever issued. Dumped the two descriptors and see that they are different at offset $16-19 and $24-2A. I guess a 5 meg descriptor could be made by patching at these locations so does anybody know what these bytes indicate or what values they should have for a 5 meg drive? I do have the RS HD interface and cc3hdisk. Thanks--TedJaeger -*- 30014 8-JUN 21:15 Programmers Den Shell+ 2.1 and Vi From: MAREK To: ALL Here's an interesting problem for all you programmers I recently applied Rick Adams' vi patch to TSEdit..when I name this file "vi" and try to run it from the OS9: prompt nothing happens! Iit seems that Shell+ recognizes the letters v and i as commands. so IF you are using Shell+ with Ricks patches rename it to something else. -Michael -*- 30015 8-JUN 22:22 Programmers Den RE: Shell+ 2.1 and Vi (Re: Msg 30014) From: ZACKSESSIONS To: MAREK Do you have King's Quest III or Leisure Suit Larry? Do you then have the VI module in your bootlist? CONFLICT! -*- 30017 8-JUN 23:26 Programmers Den RE: Shell+ 2.1 and Vi (Re: Msg 30015) From: MAREK To: ZACKSESSIONS Nope...The KQ3's Vi is in a completely separate dir. I have the TSEdit/Vi in my CMDS dir on my drive. I am pretty sure that the problem is the fact that Shell+ 2.1 is only seeing the v to turn off variable expansion and that is as far as it gets perhaps if you have access to Ron Lammardo you might check and see..but as it stands "vi" named vi will not fire up from the OS9 prompt...at least not on my system. BTW: I have the wildcard option turned off in Shell+ -Michael -*- 30018 8-JUN 23:34 Programmers Den RE: Shell+ 2.1 and Vi (Re: Msg 30017) From: ZACKSESSIONS To: MAREK (NR) You mean you load vi for KQ3 when you need it and do not include it in your OS9Boot? Zack -*- End of Thread. -*- 30016 8-JUN 22:59 Utilities RE: HDB/HDR (Re: Msg 29263) From: COCOXT To: JOHNREED (NR) HDB streams out all allocated sectors by increasing LSN; it doesn't follow any tree or file structures. Also, it stores the actual LSN of each piece of data with that data. Since the LSN's would be the same on any type of disk, all you should have to change is the backed-up version of the hard disk's LSN0. To do this, take the 1st backup disk and use a disk editor on the file H0BACKUP1 (or whatever it's called). Look at the first sector of the file. It begins with a 3-byte header that gives the LSN (should be $000000), followed by the 1st 253 bytes of the sector. Look up the format of the ID sector in your OS9 tech manual, and change the number of heads and tracks at the offsets + 3 given. This will only work on a non-compressed disk. Please work on a backup of your 1st disk, and please call if you are at all unclear about the instructions above. Chris Burke (206) 432-1814 -*- 30019 8-JUN 23:41 General Information RE: The T.O.P.S User Group (Re: Msg 29932) From: TJMARTIN To: KEITHMARCH Is there a TOPS group in Japan also? I know of the one based in Munich, West Germany. In case you do want more info (don't have it already), I uploaded the index file from TOPS listing the contents of their software release as of a while ago. I submitted the fie file to OSK data base. More info possibly on GESPAC BBS at 602-962-5940. -*- 30034 9-JUN 12:59 General Information RE: The T.O.P.S User Group (Re: Msg 30019) From: KEITHMARCH To: TJMARTIN (NR) Hi Where is that in the 68K Database? There are only 4 entries. Keith -*- End of Thread. -*- 30020 9-JUN 00:16 General Information RE: New C compiler bug! (newly found) (Re: Msg 29898) From: RAGTIMER To: EDDIEKUNS (NR) Well, maybe the ANSI C standard is part of a plot by Intel and MicroSoft to cripple Motorola prociessors down to where Intel can compete on even ground. I mean, define C so that auto-inc/dec modes can't be used, and an 80386 is almost as good as a 68000. Funnt how the additions to the 80186 were mostly catch-up-to-68K. (That's "Funny"). -*- 30021 9-JUN 00:19 General Information RE: New C compiler bug! (newly found) (Re: Msg 29914) From: RAGTIMER To: GREGL (NR) Oh yeah, right -- good luck transferring binary data (or C code) between Moto and Intel. By the way, I've read that Intel's little-endian byte ordering makes graphics bit mapping shifts a real pain. Notice how all the graphic computers were 68K based, until INtel got up to the 80286 or so? -*- End of Thread. -*- 30022 9-JUN 00:24 Graphics & Music RE: MVCanvas 2.0 (Re: Msg 29943) From: RAGTIMER To: MIKEHAALAND Being your own dealer -- must be a pain at times. Well, I saved the box and packing for my 220. Don't use it much, so could loan it to you. Maybe send you a couple printouts from ColorMax3 (NOT Coco-Max 3) to reverse-engineer. But I hope you can find one of your own. I know that the RS Computer Centers still stock, or can order, the ink carts for it. Say, did you know it contains a 6809? --mike k -*- 30025 9-JUN 03:05 Graphics & Music RE: MVCanvas 2.0 (Re: Msg 30022) From: MIKEHAALAND To: RAGTIMER (NR) Mike, I tried to write the driver (it's done I think) but I need someone to test it for me. You willing to give it a shot? Just in case I sent you the driver in and AR file in E-Mail. Lemme know if it works for ya, Mike H -*- End of Thread. -*- 30024 9-JUN 02:38 General Information General Information From: JENG To: NES (NR) Thanks once again for that first hand experiance in regards to the MM/1 demo at Charlotte N.C. Theres new announcements for the MM/1 and Frank Hoggs TC70 (68070 CPU) in the Database New Upload area. Hopefully Paul Ward and Frank Hogg will keep us up to date on their computers. Both sound exciting and I hope both will be compatible in the software end! But its good to see two different approaches in the hardware area,friendly competition is advantageous to the OS9/OSK users! JENG -*- 30026 9-JUN 03:56 General Information RE: Shell+ (Re: Msg 29752) From: KNOT1 To: BRIANWHITE (NR) All excellent points about upgrades to Shell+. Just a small item I would like to add. When you enter a line like: OS9:chd /DD/CMDS ; fstat d* Where you have both multiple statements separated by semicolons and wildcards, it seems that all wildcards on a line are expanded before ANY statements are executed. It would be better wildcards were only expanded up to a semicolon until after that statement is executed, then expand she wildcards up to the next semicolon/end-of-line and so on. Just felt like putting my own two cents in. -Jamie (KNOT1)- -*- 30029 9-JUN 04:33 Utilities PCDOS cmd, & CC3Disk patch From: PAULSENIURA To: ALL Whoops -- I cannot find the required CC3Disk patch as stated in the PCDOS.AR file. The included zap does not produce the required edition/CRC of CC3Disk. The docs say PCDOS needs the Edition #11 with CRC $E11F29. I looked & looked, both here and on Delphi. Quite some time back, on CIS, we logged some bugs wBob Santy on the at-that-time latest PCDOS command. If someone's got that patch, and it works correctly on 3.5-inch 720k "real" IBM- PC formatted diskettes, could ya upload it ASAP? You see, something came in the mail today. Something from SEA. Something we can't read! hint hint. Arc 6.02 sources! It's archived in a 260k file, and I unarc'd it at the office with real Arc 6.02 on a PS/2, but it is all on a 720k diskette and bled over to a second volume. The original bug as told to Bob Santy more than a year ago hasn't been fixed yet. We can't read more than about 128k into a 720k diskette. Not I/O errors from the drive, not hardware problems, the program/patch combination gets lost after that much disk is read in. No matter how big or small each file is on the PC diskette. I would try the correct zap to CC3Disk first, then see if we can read the entire diskette. If not, I dunno what to do except spend $100 to order SDisk3 and PCDOS utils from D.P.Johnson &/or GCG. That takes a whole bunch of time & money. Not worth it! I'd rather kludge Arc 6.02 sources into small 5-inch SSDD 160k diskettes, then remerge everything back together. Please if someone has the CORRECT CC3Disk patches for PCDOS requirements, let's have a peek, please? Then we can get crakin' on porting this dude over ... -- Thx, Paul Seniura. -*- 30030 9-JUN 04:36 Utilities RE: PCDOS cmd, & CC3Disk patch (Re: Msg 30029) From: PAULSENIURA To: PAULSENIURA Ah oh, I should've said I looked here and on GEnie! I don't have an account on CIS, but I got a little kit I could open up. I wonder what all we're missing here that is happening on CIS. Is it worth twice the bucks-per-hour? (Delphi Advantage rates, is it worth THREE times?) -*- End of Thread. -*- 30032 9-JUN 09:46 General Information RE: Pictures Needed (Re: Msg 29878) From: IVANSC To: DALEP (NR) Hi DALE!!! Glad to see you are not giving up on KISSable OS-9. I have actually been around for some time & spent a little time with you Kkevin D and Kevin P at last years CHhicago fest - sadly time & money have precluded any more recent attendances! E njoy Toto country! -*- 30033 9-JUN 12:25 General Information Questions about the MM/1 From: KEITHMARCH To: PKW (NR) Hello Paul: I have some questions about the MM/1 and OS-9/68K 1) Is there a WEFAX/HAM program for OS-9/68K? 2) Will the MM/1 support the RAVE package? 3) What is the System ROM, How many K? 4) If a person does not buy the I/O Board with the Main CPU Board, can you use the Smartwatch RTC chip in the EPROM Slot used for OSK? 5) Is there a DMODE command for OSK? 6) Is there a terminal program that supports X/Y/ZModem? 7) Does the BASIC that comes with the MM/1 have a CLS command built in? 8) Later on, can users pull out the 68070 15 Mhz chip and put in a fast chip. Is the CPU socketed? 9) If I format a 3.5" 720K DS/DD Floppy Disk under OS-9/Level II can I read/write to it useing the MM/1 and OS-9/68K or do I have to reformat it to use it? 10) Will most programs use the 'F##' keys on the IBM Clone Keyboards? 11) Will the MM/1 have/be able to use, a Math Coprocessor? 12) Will all major chips be socketed? 13) Are you/Will you be, working on a book called 'Start OS-9/68K? 14) How will we change are BOOT File in the EPROM? a) Buy a EPROM burner. b) Boot off of floppy from that point onward. c) Send the EPROM back to you with patches on the disk and pay for the reburn. d) Pull hair out while tring to figure out what to do. Thanks for the help!!!! Keith -*- FORUM>Reply, Add, Read, "?" or Exit>