#: 12126 S7/Telecommunications 08-Sep-91 13:17:22 Sb: #12124-sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Paul, Why not just use the values in the table provided for Level II and manually patch ACIAPAK with dEd. PAKMOD.SRC was just a modpatch source file that automated the process and applied the patches to what was in memory. Alternately, you could create your own .src file. Steve #: 12127 S7/Telecommunications 08-Sep-91 13:20:59 Sb: #12124-#sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) For a quicky tutorial on the Level II utility called modpatch, see MODPAT.TXT in LIB 10. Modpatch supports both .src files as well as an interactive mode. Steve There is 1 Reply. #: 12145 S7/Telecommunications 09-Sep-91 07:39:43 Sb: #12127-sterm 1.5 Fm: Paul Hanke 73467,403 To: Steve Wegert 76703,4255 (X) Thanks for the tip. I tried modpatch again on a gshell patch to boot MV into an 80 column window and this time I seem to be getting the hang of it since it worked. Now I still have to go back and OS9Gen a disk here & there. -ph- #: 12128 S7/Telecommunications 08-Sep-91 13:22:23 Sb: #12115-#sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Paul, is thhe problem with deldir _after_ you've patched gshell with gshell2? I think that was one of the buglets corrected via that file. Steve There is 1 Reply. #: 12135 S7/Telecommunications 08-Sep-91 19:48:35 Sb: #12128-#sterm 1.5 Fm: Paul Hanke 73467,403 To: Steve Wegert 76703,4255 (X) I had only half completed the gshell2 patch. Seems I re-instated the old scf file instead of the new one. IDENTs of each new mod would be helpful in crosschecking especially if more than one patch is made to a given module, over a period of time. Now, after making the changes for MV, say with SCF & CC3IO, then these changes should be applied to the working OS9 boot disk, too, or are they applicable only when used in MV (meaning the modules common to both, not for windint, for example)? Yes, I've put /t2 into the env.file, but hadn't thought of aciapak, the absence of which caused sterm not to load. Once loaded manually, sterm did load into MV ok. -ph- There is 1 Reply. #: 12136 S7/Telecommunications 08-Sep-91 21:17:23 Sb: #12135-#sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Paul, I agree .... things get pretty hairy at this level of patching ... but the results are well wrth the efforts. Stock MV is pretty much worthless. Kent and others did a bang up job on getting it to where it is today. The patches to SCF and cc3io are not specific only to MV. They should be treated as required updates to the stock modules. I'd offer my idents to help ... but I'm so patched, I doubt they'd be of much help. There is 1 Reply. #: 12139 S7/Telecommunications 08-Sep-91 22:32:11 Sb: #12136-#sterm 1.5 Fm: Paul Hanke 73467,403 To: Steve Wegert 76703,4255 (X) Sheesh, if I read you right then at any given point in time no 2 users will have the same upgrade of MV; all their crc's just ain't gonna match nohow (without proceding from square one along a defined set of upgrade steps) depending on which patches were applied and when. -ph- There is 1 Reply. #: 12146 S7/Telecommunications 09-Sep-91 08:13:45 Sb: #12139-#sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Not necessarily so, Paul. The average user will be in sync with other average users as far as patch levels go. In my case, I'm constantly trying things .... patching this, pulling that. If they work well, they stay, if not .... Steve There is 1 Reply. #: 12149 S7/Telecommunications 09-Sep-91 16:32:49 Sb: #12146-#sterm 1.5 Fm: Paul Hanke 73467,403 To: Steve Wegert 76703,4255 (X) Well, I was referring to being aware as to what all the available patches are after one decides to jump into the fray well after the 'olde-timres' have been at it since square one. -ph- There are 2 Replies. #: 12160 S7/Telecommunications 10-Sep-91 07:51:15 Sb: #12149-sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Paul, I see your point. Why not start the file yourself. You're at the begining of a patching project. Just jot down your successes, file names and where you found 'em. We'll be happy to help in any way we can. Steve #: 12161 S7/Telecommunications 10-Sep-91 08:00:51 Sb: #12149-sterm 1.5 Fm: Steve Wegert 76703,4255 To: Paul Hanke 73467,403 (X) Paul, As a starting point in your search for all those patches, take a look at Kev's BESTOF file as well as BUGS.TXT and BUGS2.TXT file. All found in LIB 10. Steve #: 12129 S10/OS9/6809 (CoCo) 08-Sep-91 13:29:32 Sb: #12125-mod help Fm: Erich Schulman 75140,3175 To: Everett Chimbidis 76370,1366 (X) Do you have a copy of the current issue of The Rainbow? They tell you in there; check the OS-9 q&a column. But what you need to do is check the offset for each module within the os9boot file. The first block contains every module with offsets from $0000 through $1FFF, the second block is from $2000 through $3FFF, etc. This may or may not be important on your CoCo. For now, don't try to fit to blocks and see if that's OK. If not, we can resequence later. Do you have ezgen 1.09? That's what I have, and I want to be sure our programs will agree. Instead of the ident -s, try using ezgen -d -m -o os9boot. Wait a long time for the disk drive to finish. Then type ?[enter]. That will give you a listing of your modules and their offsets in the os9boot file. Use tmode pause beforehand, or you'll have to be quick on the ctrl-w. Take down that information. Have you yet downloaded os9p3 and extracted it? You will need to know where to put it before you can go further. If you know where to put it, its position will become obvious once you get that listing. Then type q[enter] to quit. The -o will cause ezgen to leave your present file alone and not change it (for now). The listing may help, so do send me a copy of what you get from ezgen. How many disk drives do you have? To actually add os9p3 via ezgen, it will make a difference in the required technique. #: 12130 S1/General Interest 08-Sep-91 14:42:22 Sb: CoCo forum Fm: Paul Hanke 73467,403 To: All Has everyone checked out the new games in the CoCo forum? There's a version of hangman with interesting graphics. There's also one called SPELLDOWN (SPELLD.ARC) which requires downloading 2 files; the deARCed set of files of one must be on drive 0, the other on drive 1 in a 512k CoCo; won't work properly with a 1 meg upgrade (at least on mine; I also have a 512k CoCo). Both can be unARC'ed with ARCHIV.BIN Hangman (mentioned above) does seem to work with any CoCo-3. Doc files are lean on both; read'em with a w.p. #: 12131 S1/General Interest 08-Sep-91 14:43:04 Sb: SciCalc Fm: Paul Hanke 73467,403 To: anyone Has anyone been able to use the scientific calculator program? Once loaded as a module and called, it seems to only display opening logos and freeze up the screen. Can be found in Applications lib. -ph- #: 12132 S10/OS9/6809 (CoCo) 08-Sep-91 17:12:49 Sb: #mod help Fm: Everett Chimbidis 76370,1366 To: 75140,3175 (X) All I have for EZgen is ver 1.02 (I have no -m command in this ver) He gave me no update !! What do I have to do to get a copy?? Can you upload a copy in email? There is 1 Reply. #: 12153 S10/OS9/6809 (CoCo) 09-Sep-91 23:35:59 Sb: #12132-#mod help Fm: Erich Schulman 75140,3175 To: Everett Chimbidis 76370,1366 (X) EZGen is commercially distributed and I therefore cannot legally upload it. I'd suugest you upgrade to 1.09. The only way Burke & Burke distributes updates is selling them. Just send them $5.00 and a copy of your 1.02's sales receipt. If you don't have the receipt, they might accept the original disk or something: contact them. Their address is Box 733, Maple Valley, WA 98038. Orders go to 800 237 2409. One thing you might also find helpful--and you CAN download it--is kutil. I just got it, but I have yet to even extract it. This will make it easier to edit the OS-9 kernel by converting kernel<-->disk file. Get a copy of that and check it out for yourself. Meanwhile, it is possible to install os9p3 even without EZGen, esp. if you have 2 disk drives. Let me know if you want to proceed this way or if you'd rather wait for a EZGen upgrade. There are 2 Replies. #: 12169 S10/OS9/6809 (CoCo) 10-Sep-91 19:14:10 Sb: #12153-mod help Fm: Everett Chimbidis 76370,1366 To: Erich Schulman 75140,3175 It's not just os9p3 i need to install i want to run multivu and I keep running out of ram memory! I will upload you some stuff mabe will help you help me? #: 12170 S10/OS9/6809 (CoCo) 10-Sep-91 19:22:26 Sb: #12153-mod help Fm: Everett Chimbidis 76370,1366 To: Erich Schulman 75140,3175 Where do I find kutil?? And does it have a ext? #: 12133 S10/OS9/6809 (CoCo) 08-Sep-91 17:13:04 Sb: #12123-Mouse_Hlp Fm: Brother Jeremy, CSJW 76477,142 To: Kevin Darling 76703,4227 (X) I see where I made my mistake. The good thing is, I understand your explanation. It is coming together. Thanks for the help, Br. Jeremy, CSJW #: 12134 S10/OS9/6809 (CoCo) 08-Sep-91 18:44:52 Sb: #12109-RSM.PAK Fm: James Whitaker 70355,431 To: Kevin Darling 76703,4227 (X) Your welcome. I found the new GFX2 really makes it easy to program those pulldown menus. #: 12137 S12/OS9/68000 (OSK) 08-Sep-91 21:34:01 Sb: #12117-#Intercepts Fm: Bob van der Poel 76510,2203 To: Kevin Darling 76703,4227 (X) Well, ummm, errr, okay... Actually, in The OS9 Catalogue, page 21, it does state that "system state functions and OS-9 interrupt service routines operate only in sypervisor state..." So I assumed that when, on page 81 of the C manual, they say "any i/o using the OS-9 C library (eg. printf) _cannot_ be performed inside both the intercept handler function and the main program" I figured that was the reason. Bob Taylor's comment about signals being enqueued makes as much sense. But, then how does one un-enqueue the signals -- this implies to me that if you were to use an intercept to restart a program (maybe back to the main menu for a game, or whatever) then you'd only be able to do it once. Under Level II I have used signals for that purpose, without any problems. I assumed that (for whatever reason) you could not do it with OSK. Maybe some more expanations from MW are in order. Also, all the examples from MW that I've seen do avoid I/O in the intercept (they just set a flag and return). Guess it's time to stop reading the manual and just write the code. Also, would it make any difference if one is using the CIO trap for I/O? There are 2 Replies. #: 12141 S12/OS9/68000 (OSK) 09-Sep-91 00:28:08 Sb: #12137-#Intercepts Fm: BILL HEALTON 73367,357 To: Bob van der Poel 76510,2203 (X) Bob - I have barely scratched the surface of C programming, but I have worked with several device drivers. Applying their approach to your problem...maybe you could try the following: Create an initial "core" procedure that sets up an intercept, forks the other procedure(s) of your program and tsleep(0). Then, any signal will wake the "core" process...which can either ignore it and re-sleep or do your cleanup and kill the children(ie. your program). The "core" procedure could even be run at a higher priority than the children to ensure its not pre-empted by a child during the cleanup/closeout time. In the above the "core" and children should all be running in User state with none of the System state restrictions. Hope this is of some help. Bill Healton 73367,357 There is 1 Reply. #: 12150 S12/OS9/68000 (OSK) 09-Sep-91 20:49:24 Sb: #12141-Intercepts Fm: Bob van der Poel 76510,2203 To: BILL HEALTON 73367,357 Interesting idea, running all the functions of a large program as sub-functions of a tiny little core (maybe a menuer). I have to think a bit about that for future projects. In the meantime, I just added the signal trap as others have suggested and do the cleanup from it. Seems to work fine. #: 12158 S12/OS9/68000 (OSK) 10-Sep-91 03:45:12 Sb: #12137-Intercepts Fm: Kevin Darling 76703,4227 To: Bob van der Poel 76510,2203 (X) Bob, The "interrupt routines" mentioned there, are for cpu interrupts... not user interrupt service routines (which should just be called: signal service routines :-) I just took a quickie non-pro glance with the debugger at the kernel, and what I see is this: Whenever your turn to run comes (assumption: from a signal or sleep wakeup or whatever), the kernel checks to see if you're already in an signal intercept routine... if so, it cuts right back to you. Therefore, I would think that normal wakeup driver signaling will still work, and so doing I/O should be okay (which the exception of getting, say, a BREAK key or something else that signals you especially). Ie: don't expect to get user signals while in the signal intercept routine :-) If you jump out of your routine back into a main loop (under OSK or OS9), then you leave a stackframe hanging around, which will slowly eat up your data area until you crash. Under OSK of course, you also leave the special "I'm in an intercept routine" flag hanging, and won't ever enter the signal intercept code again. So the F$RTE under OSK is the correct way to exit. Anyway, just some info. I'm having to learn about OSK myself :-) kev #: 12138 S12/OS9/68000 (OSK) 08-Sep-91 21:34:13 Sb: #12122-#Intercepts Fm: Bob van der Poel 76510,2203 To: Bob Taylor 73270,3124 (X) Bob, Thanks for the reply. I guess I'll just have to give it a try and see what happens, despite MW's admonishments to the contrary. There is 1 Reply. #: 12142 S12/OS9/68000 (OSK) 09-Sep-91 05:13:24 Sb: #12138-Intercepts Fm: Bob Taylor 73270,3124 To: Bob van der Poel 76510,2203 (X) Bob, Ooops - intercept(sig) should read catchsig(sig)! It is my understanding that if other signals are pending, while in the trap function, after exiting, the trap function is immediately called again to process the next pending signal. You should encounter no problems in this particular case. Bob #: 12147 S12/OS9/68000 (OSK) 09-Sep-91 08:59:25 Sb: #12116-#Intercepts Fm: Mark Wuest 74030,332 To: Bob van der Poel 76510,2203 (X) Bob, AS you've been told, you are not in system state when you go to your signal trap. I assume by intercept mode you mean you have a line intercept(sigtrap); somewhere. What happens when you get a signal is this: (You cannot get one in the middle of a time slice, BTW) 1 It is your process'es turn at the cpu (your time slice is coming). 2 The kernel looks to see if you have any signals pending *before* switching to your task. 3 If you have done an intercept() call, it executes the function you pointed to, pasing the signal as an int. 4 *If* and when you return() from the signal trap, your process continues execution where it left off when its last time slice was up. The reason MW says to limit what you do in a signal trap is because you don't want to risk missing a signal. If you were to do a sleep() in the signal trap, 10 processes could send signals to you, but you would only "get" the last one. (continues) There is 1 Reply. #: 12151 S12/OS9/68000 (OSK) 09-Sep-91 20:49:39 Sb: #12147-#Intercepts Fm: Bob van der Poel 76510,2203 To: Mark Wuest 74030,332 (X) Thanks for the details, Mark. I added the cleanup() stuff to the intercept routine and all seems to work fine. Now, more questions: once the signal trap has been entered all other signals will be blocked until a F$RTE is done ... and this is only done when the intercept routine is actually terminated. I suspect that jumping back to another section of the main program via a longjmp() will not cause a F$RTE (it better not!), so this will leave the signals in a blocked state. I wonder, would re-setting the intercept serve to un-block things? There are 3 Replies. #: 12164 S12/OS9/68000 (OSK) 10-Sep-91 08:21:10 Sb: #12151-Intercepts Fm: Mark Wuest 74030,332 To: Bob van der Poel 76510,2203 (X) Bob, Not all signals are blocked. The last signal you were sent is held (you would not really say it was queued) and handled on your next time slice. While in the signal handler, you are still going to submit to the kernel's task switching so may be in trouble. I would only do a bunch of stuff if I were going to exit(). If you are doing the longjmp() (is this OSK?) to make your code smaller, I would recommend copying the block to your signal trap or putting it in a function called , say, cleanup(). The point is, you may even get switched out ("swapping" has been used here, but that normally refers to sections of memory getting "swapped" out to the disk. Few systems need to do this anymore as most uP's support paging. OS9's kernels do not support either, though they used to talk about a level III that would.), but will come back to the signal trap where you left off. I am pretty sure you will not re-enter the trap at the top if there is another signal pending. Microware would have to answer that one, and when you get their support desk, they're going to try and talk you out of doing I/O in the trap, even if you are about to exit. You could test this by putting a sleep(0) in a signal trap. Mark #: 12165 S12/OS9/68000 (OSK) 10-Sep-91 08:26:27 Sb: #12151-#Intercepts Fm: Mark Wuest 74030,332 To: Bob van der Poel 76510,2203 (X) Bob, I just saw Kevin's response to you and he confirms that you will be put back into your signal trap if you give up or lose your "tick". (I/O is almost sure to put you in the sleep queue.) Whenever I start feeling like a genius, I just log in here and see how many people there are that are smarter than me. ;) Mark There is 1 Reply. #: 12168 S12/OS9/68000 (OSK) 10-Sep-91 10:18:10 Sb: #12165-Intercepts Fm: Kevin Darling 76703,4227 To: Mark Wuest 74030,332 (X) Mark, If you hadn't taken the time to give a bunch of clues, I sure wouldn't have gone looking myself :-) One of these days I'm gonna hafta take OSK apart so that I can answer "with authority", instead of "it looks like to me" guesses #: 12166 S12/OS9/68000 (OSK) 10-Sep-91 09:11:14 Sb: #12151-Intercepts Fm: Mark Wuest 74030,332 To: Bob van der Poel 76510,2203 (X) (Gads, this is my third response!) I just re-read your message offline and something in it set off an alarm in my head (scary, isn't it?). Why do you want to "unblock" things when you are going to exit()? The process is just going away. If you do not plan to exit(), read Kevin's message carefully. What he says about the stack frame is absolutely correct. The only proper way to "un-block" things is to return() from the signal trap. This means you would have to first have to return() to the trap from whatever routine you longjmp()'ed to. If I could, I would talk you out of a goto (or its relative, longjmp()) here. If you have shared code, that's what functions are for. Bag my ramblings and just make sure you return() from the trap. The compiler or kernel will take care of making the F$RTE (oh, it's in the kernel). If you're going to exit(), then you don't have to do anything. Mark #: 12148 S12/OS9/68000 (OSK) 09-Sep-91 09:01:41 Sb: #12116-Intercepts Fm: Mark Wuest 74030,332 To: Bob van der Poel 76510,2203 (X) (continued) Since you are going to exit() anyway, who cares what other signals you might have gotten? Go ahead and write(), close(), and unlink() to your heart's content. Mark #: 12140 S10/OS9/6809 (CoCo) 09-Sep-91 00:11:56 Sb: #Public Domain Fm: NEAL STEWARD 72716,1416 To: sysop (X) How can I find out which software has been released as public domain? Our CoCo club has taken a string anti-piracy stand and will not place copywrited software on our bbs. What is the legal status of software written or distributed by now defunct companies? Can distributio rights be obtained? Who own the rights to such software, the author or the distributor? Any help would be greatly appreciated, and beneficial to the Erie County Color Computer Club. There is 1 Reply. #: 12154 S10/OS9/6809 (CoCo) 09-Sep-91 23:53:54 Sb: #12140-Public Domain Fm: Erich Schulman 75140,3175 To: NEAL STEWARD 72716,1416 If software is p.d. or shareware, it will probably so state. Commercial software usually states that distribution is prohibited. All software that is not public domain is protected under the law which applies to it, either the 1909 law or the 1976 law. Even if the company is now defunct, you can be sure rights were transferred to someone first. Even if not, the software is technically still copyrighted. You can get distributionrights provided an exclusive license has not been given to someone else already. Of course, they set the terms and price. For that matter, you could even buy the entire copyright unless the owner is hampered by exclusive licenses issued. All rights belong to the author unless the author was paid in which case rights generally belong to the author's employer. You might want to research the Copyright Law of 1976 (Title 17 U.S.C.), esp. Chapter 1. Also, go by the legal forum (GO LAWSIG, I think) and the Shareware Association's forum (can't recall how to get there right now). #: 12143 S12/OS9/68000 (OSK) 09-Sep-91 06:09:02 Sb: OSK standards Fm: Robert A. Larson 75126,723 To: 76576,3312 I've uploaded my reply to Ed's oskstand.doc to standrep.doc in dl 12. #: 12152 S1/General Interest 09-Sep-91 22:08:40 Sb: gshell+ Fm: Paul Hanke 73467,403 To: anyone I thought I'd go back and try an ipatch to gshell from the ground up and keep a sort of log of ident changes along the way to the latest version but didn't get past square 1. Maybe it's too long ago to remember what the first step is; correct me if I'm wrong: Take a stock gshell and apply the gshell.ipc patch thusly: Ipatch gshell.ipc gshell gshell+ -v I get: IPatch Version 1.1 CopyRight (c) 1987 By R.M.Santy Patch entry for $0002 Changes 2 bytes Old file data mismatch at $0002 is $FF, should be $3F Patch NOT complete ERROR #001 If I do an ident on gshell after this attempted patch I get >module header incorrect< So what's going on? -ph- #: 12162 S1/General Interest 10-Sep-91 08:04:29 Sb: #gshell+ Fm: Paul Hanke 73467,403 To: Kevin Darling 76703,4227 (X) I knew that gshell+ as a filename won't work but I'd rename it after deleting the original gshell. I thot of using dEd too but the patch must have worked the first time I tried it or I wouldn't now have an upgrade already!...(?) How 'bout using modpatch after having loaded original gshell into memory within an OS9 boot, SAVEing to /r0, then applying the gshell.ipc patch? -ph- Oops, seem to have hit DELETE on your message instead of CANCEL. There is 1 Reply. #: 12167 S1/General Interest 10-Sep-91 10:10:18 Sb: #12162-gshell+ Fm: Kevin Darling 76703,4227 To: Paul Hanke 73467,403 (X) Sure, modpatch should work for that. kev urrgh. lotsa line noise today. #: 12163 S10/OS9/6809 (CoCo) 10-Sep-91 08:09:27 Sb: Multi-Pak Fm: David Betz 76704,47 To: all I just acquired an ancient (grey case with internal power supply) Multi-Pak interface for the CoCo. Can someone point me to the instructions for updating this to work with a CoCo3 under OS-9? I seem to remember some modification involving interrupts that needs to be done to allow the RS232 pak to work correctly. On that subject, does anyone have an RS232 pak they're interested in selling? I'm also interested in a hard disk controller that can handle SCSI drives. Thanks, David Betz Press !>