749 lines
24 KiB
Plaintext
749 lines
24 KiB
Plaintext
|
|
|
|
#: 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
|
|
<grimace>
|
|
|
|
#: 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 <CR> !> |