e! The
following program will work, no stack increase or other problems. Note that
v:without the sleep() only the first ctrl-e will be recognized. Guess the
F$Sleep must reset things somehow.

 #include <stdio.h>
 #include <setjmp.h>
 int iflag;
 jmp_buf jmpbuffer;
 icept(signal)
 int signal;
 {
   iflag=signal;
   printf("Signal %d processed, stack %x\n",signal,freemem());
   if(signal==3) exit(0);   /* exit for ctrl-c */
   else longjmp(jmpbuffer,0); /* restart for ctrl-e */
 }
 main()
 {
   setjmp(jmpbuffer); i]   intercept(icept);
   printf("Program restarted, stack %x\n",freemem());
   for(;;){
    if(iflag){
      printf("The signal flag was set in icept()\n");
      iflag=0;
      sleep(2); /* NEEDED!!! */
    }
   }
 }

 continued... {/ex post

reply 12166
 ...continued

So, I'm back to where I started. I have a technique I've used under Level II,
and it works fine (maybe??) under OSK. It all seems to be a bit too simple, but
maybe we were making it too hard.

The thing that I failed to see is that there was nothing special about going to
the end of the intercept routine. All it does is a RTS. I assume that when {the
interpupt is done OSK sets that stack up with the point in the program as the
return address and then jumps to the intercept routine. But there is no
difference between going to the end of the intercept routine and doing a return
there than there is going to any other function... And since the setjmp() saves
all the data and address registers and longjmp() just restores them, using this
combo maintains the stack integrity.

Now, I'm still confused my MW's refusal to permit this technique. After all, it
_appears_ to work!

There are 2 Replies.

#: 12180 S12/OS9/68000 (OSK)
    11-Sep-91  09:47:44
Sb: #12171-#Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)

Bob,
 I have one process (a daemon) that gets a signal every night at midnight, does
an fclose() and fopen() on a log file, and returns. Since the file is a log
file, I figure we can risk missing a signal while we're switching (especially
since we shouldn't be getting any other signals!). It has run flawlessly for
over a year now in several places.
 I know this is going to sound funny, but I would try to talk you out of the
longjmp() you are doing and replace it with chain(), using the argv, argc, and
envp you were passes in main(). This will close() all your files (the system
will do it for you) and be more assuring of stacks, etc, being in kosher shape.
Call me paranoid, but at best your code is not going to be easily portable to
Unix (where your would replace chain() with a fork(), exec(), "am I the parent"
decision, and exit()).
 Just food for thought. OTOH, if it ain't broke, don't fix it might apply here,
too.
 Mark

There is 1 Reply.

#: 12183 S12/OS9/68000 (OSK)
    11-Sep-91  19:08:16
Sb: #12180-#Intercepts
Fm: Pete Lyall 76703,4230
To: Mark Wuest 74030,332 (X)

Mark -

Just a purist's thought.... while chain is less overhead than the creation of a
new process (for other readers: since chain effectively inherits the calling
process's resources, and they don't need to be reallocated by the system), it
is still more overhead that just revectoring the flow of the program.

I hear what you're saying ... used to be an old RS-DOS BASIC technique to make
sure that string space, FOR stacks, and other goblins were properly in check,
but it's still... ahh.... voodoo (grin).

Pete

There is 1 Reply.

#: 12209 S12/OS9/68000 (OSK)
    12-Sep-91  08:14:10
Sb: #12183-Intercepts
Fm: Mark Wuest 74030,332
To: Pete Lyall 76703,4230 (X)

Yeah, to be even *more* close to unix, you would os9exec() and then exit().
Then, to port to unix would only require changing the os9exec() to the good old
fork()-and-exec() all unix types have grown to know and love <g>. I find it
weird that they (actually we - I work for AT&T!) didn't do the unix exec like
OS9's. You almost *never* see a fork() in a unix program without an exec()
right on its heels.
 Mark

#: 12220 S12/OS9/68000 (OSK)
    12-Sep-91  23:52:01
Sb: #12171-#Intercepts
Fm: Kim Kempf 71161,3221
To: Bob van der Poel 76510,2203 (X)

>Now, I'm still confused my MW's refusal to permit this technique.  After
 
[RE: longjmp from an intercept routine]
 
Things might look OK, but your stack is overflowing.  The signals are
delivered to the process on an alternate stack that is specific to the
process, but different from the stack the process is using in user mode.
You *must* call F$RTE after the intercept routine to pop the stack and
allow the next signal to be delivered.  If you are executing
in an intercept routine and another signal is delivered, it won't be
processed until the intercept completes.  If you longjmp() out of it
the F$RTE never gets called.  If you intend to clean up things and exit,
that's not too bad, but I've yet to run into a situation that couldn't
be reorganized to set a global exit flag to cause the program to exit.
 
The warnings by MW about I/O are historical because signals in the past
(before V1.3?) were not queued:  if the process was in the intercept
handler, the signal being sent was discarded.  Now they are queued and
you're obligated to process them promptly or things start to get wasted.
C language I/O (read printf()) use static memory for output buffers which
may get stomped on if they are running and a signal interrupts it.  Even
worst, malloc() has this problem (yikes!).  The safest signal handlers
(in UNIX, too) just set global flags and return.  A fully ANSI-comformant
program is restricted to this anyway.  Hope this helps.

There are 2 Replies.

#: 12231 S12/OS9/68000 (OSK)
    13-Sep-91  08:58:57
Sb: #12220-Intercepts
Fm: Mark Wuest 74030,332
To: Kim Kempf 71161,3221 (X)

Kim,

 Just out of curiosity, I ran Bob's sample code under srcdbg, and the usp
stayed the same. Are you saying there is *another* stack (even other than the
system stack) that is getting marfed? I was honestly surprised that the usp
stayed ok.
 Mark

#: 12237 S12/OS9/68000 (OSK)
    13-Sep-91  21:23:39
Sb: #12220-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Kim Kempf 71161,3221 (X)

Kim, thanks for the details on intercept routines. I'll be interested to read
your reply to Mark's query (yet another stack?). But I still don't understand
something: just when does the F$RTE get called? Surely the C compiler is not
intelligent to create my intercept function differently from any other
function--and they all end the same by doing a RTS. Oh, does the intercept
routine itself set up the stack so that the RTS branches to the F$RTE and from
there back to the program?

Yes, you are correct in that it is possible to rewrite a program to check
global flags.... but the question which has to come up is--in how many
different places should one check? And there is always the possibility that
(especially during development!) that a minor loop might be infinite and the
only way out of the *$*%**$# thing is to hit ABORT. If the intercept just sets
a flag, hitting ABORT is not going to be all the helpful. Well, I guess it
could set a global flag, and have a panic flag too which causes a exit via the
intercept if a certain number of ABORTs have been done... but for termination I
think that doing a cleanup from the intercpet and then an exit is the cleanest.

The longjmp() technique is pretty sleasy. But, again, it is a nice way to
restart to a known point (esp. in games, etc.). Again, the checking of global
flags in who knows how many places can get pretty tedious. Plus, it slows down
the response time...

There are 2 Replies.

#: 12253 S12/OS9/68000 (OSK)
    15-Sep-91  11:17:02
Sb: #12237-#Intercepts
Fm: Robert Heller 71450,3432
To: Bob van der Poel 76510,2203 (X)

The "other stack" is probably not an A7-type stack (USP/SSP), but the signal
queue/process state info in your process's descriptor.  This is what the F$RTE
"pops".  It is not so much a stack but your process's state - in intercept vs.
not in intercept.  When your intercept routine is called, you get called with a
stack frame above your current USP (i.e. the kernel pushes stuff (its user-mode
return address, the signal number, etc) onto your stack.

A longjump will restore the USP/registers/PC to the state at the setjump, but
does nothing about your process's state info in its process descriptor.

VMS (as well as UNIX and OS9) has a simular problem with I/O in Control-C
handlers.  We have this big system (LLVS), written in a combination of C and
VAXLIsp.  A Control-C handler is provided to allow users to abort an task. The
way it work is there is a ^C handler that just sets a global flag and another
function that is called at periodic times from the main program which checks
the ^C flag.  I've found this method of handling ^C's to be the safest (and
most portable) way to go.  Almost any program has one or more major loops -
adding one line of code (check_control_c();) is usually easy.  The control c
checking function checks the global flag, and if set, does the cleanup and
exits.

                        Robert

There is 1 Reply.

#: 12254 S12/OS9/68000 (OSK)
    15-Sep-91  16:44:22
Sb: #12253-Intercepts
Fm: James Jones 76257,562
To: Robert Heller 71450,3432 (X)

Agreed--long, long ago when I ported a ed-like line editor to OS-9 from CP/M, I
decided to go that route, in large part because just doing a longjmp,
attractive as it may seem, also wouldn't let me guarantee that the editor's
internal data structures were consistent.  Some stuff just can't be interrupted
in some places.

#: 12258 S12/OS9/68000 (OSK)
    15-Sep-91  21:58:22
Sb: #12237-#Intercepts
Fm: Kim Kempf 71161,3221
To: Bob van der Poel 76510,2203 (X)

OSK uses 3 stacks at any one time: the user stack (usp), the system stack
(ssp), and an interrupt stack.  The user and system stack are one per
process.  When an interrupt occurs, OSK moves the stack to the special irq
stack and runs from there until all the irqs return.
 
The C compiler (actually C library) is tricky enough to see that F$Rte gets
called when you return from your signal handler.  And don't call me Surely.
When you call intercept() the C library stashes your function away and calls
F$SSig (or something like that) to call it's own routine on a signal.  Your
routine is called and when it returns, the wrapper routine returns via
F$RTE.  Thus, your signal handler is wrapped by the C library's handler.
Trace the code in your signal handler (asm level) and see for yourself.
 
These days, signals in OSK are a lot more reliable than they used to be.
You can be more robust in signal handlers now.  My point is that you should
realize how the signal/intercept works and set your program up in the best
way.  longjmp() sucks any time of the month and will really do nasty things
when used to jump out of a signal handler.  signal handlers that clean up
and die work the best.  The signal facility was not really designed to be
an event dispatch routine, but if you can get it to work, hey that's OS-9
for ya...

There is 1 Reply.

#: 12275 S12/OS9/68000 (OSK)
    17-Sep-91  21:11:54
Sb: #12258-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Kim Kempf 71161,3221

Kim,

Thanks for the details. It is making more sense all the time.

Re your comment "don't call me Surely" -- I don't understand?

It is too bad that OSK does not have a routine which could do a ctrl-c
dispatch. I can think of lots of applications -- some serious, others fun. For
example(s):

1. It'd be nice to have a ctrl-c menu pop up in an application which would
permit some kind of sub-task in an overlay window (calc, calendar, etc.).

2. If a game (like pacman?) is being done then ctrl-c would be great for a menu
which would change colors, pause, restart, etc.

We could go on. But the key is that these applications need IMMEDIATE response
-- not the kind of thing which happens when flags are checked from loops. I
don't see why it should be a problem either. Could a function be written which
pulls the interput stuff of the stack and then does something like a longjmp()
to a previously set point in the program. Guess that the routine would just
have to change the return point from the intercept from the program location to
the restart point?

There are 2 Replies.

#: 12276 S12/OS9/68000 (OSK)
    17-Sep-91  22:20:57
Sb: #12275-#Intercepts
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203 (X)

Bob - re: "don't call me Surely (Shirley)".

HEHE.  Haven't you ever seen the "Airplane" comedy movies?  When someone would
say "Surely, you can't mean that!", the stock answer was "Yes, I do. And don't
call me Shirley!"

You had asked Kim: "Surely the C compiler is smart enough... " or something
like that, you see.

GRIN

There is 1 Reply.

#: 12279 S12/OS9/68000 (OSK)
    18-Sep-91  21:07:35
Sb: #12276-Intercepts
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)

Oh, I get it! But it's been sooooo long since I saw "Airplane" that it wasn't
really at the top of my gray cells.

#: 12277 S12/OS9/68000 (OSK)
    18-Sep-91  07:25:28
Sb: #12275-#Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)

Bob,
 I hope Kim pops in with a more definitive answer, but the most important thing
to remember is the *reason* MW says to make signal handlers very short. There
is really only one - you risk missing signals. eg: You type ctrl-c, and while
your signal handler is out doing something, you type ctrl-c two *more* times.
When your program finishes what it was doing with the first ctrl-c, it will
only get one more signal, missing one of the ctrl-c's you typed.
 Programs under OS9 do what you are describing all the time, because the
programmer knows he doesn't care if he misses a signal at that point. The
*important* thing is to be *aware* of how it works. It's not a bug (or a
"feature" <g>), it's just the way it is. Almost all versions of Unix do the
same thing, BTW.
 Good luck!
 Mark

There is 1 Reply.

#: 12280 S12/OS9/68000 (OSK)
    18-Sep-91  21:07:53
Sb: #12277-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Mark Wuest 74030,332 (X)

I think the only remaining problem comes with combining longjmp() and
intercepts(). Seems that according to Kim, unless one actually leaves the
user's intercept trap function things will remain stacked until the program
terminates. If this is true, then things will run fine for a while--and then
the whole thing will end with some kind of stack (or queue) overflow. I'm not
ever sure in my trick of doing a sleep() in the sample code I uploaded a while
ago actually cleans the queue (or stack). I think it just re-enables the
intercepts? I have no problem with missing interupts in this situation. Matter
of fact, I'm not even writing a program which needs this techique right now
-but I have used it in the past under 6809, and it might be the route I'd
choose (if I have confidence in things) if I do a port. Yeah, I know it won't
port to Unix that way, but since I don't have a Unix box I don't really care.

BTW, I hope that someone is capturing this thread. You and Kim and others have
made this a most interesting and useful topic!

There is 1 Reply.

#: 12285 S12/OS9/68000 (OSK)
    19-Sep-91  07:53:30
Sb: #12280-Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)

Bob,
 I think there is one thing that neither Kim nor I made very clear. You should
not do the longjmp() out of the signal trap. You must return() from it so the
kernel can clean up, unless you exit() or chain() in which case there will be
nothing to clean up.
 I guess to summarize:
 "Bob, this is your conscience speaking. Take that longjmp() out the the signal
trap and re-start the process instead. Please, before it's too late...."

 <g>
 Mark

#: 12172 S10/OS9/6809 (CoCo)
    10-Sep-91  22:21:47
Sb: #12169-#mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

I reviewed docs for os9p3 so I'll be better prepared.  Let me know if you are
upgrading EZGen or if you want to go on now.  Do you have 128K?  If so, that's
why you have a lot of trouble with MultiVue.  You have upon bootup, at most,
56K free.  Possibly even 40K depending on the boot file's contents. When I had
1228K, I had 40K free for OS-9.  Even with 56K, you just have too little to get
much done, esp. with something like MV in RAM.  There are other advantages to
512K both in and out of MV so if you have 128K, I'd suggest you upgrade soon. 
It will make a big difference.  And since you do have MV (I was going to ask
later on too! :-) ), you might want to install some of MV's modules in your
boot file along with os9p3.  They will work and can be quite helpful.  Some
applications require the windint module whether you're using MV or not.  Right
now, you might want to put MV's fstat command in your usual commands directory,
then do fstat /d0/sys/stdfonts (or any other file you want to check).  I think
you'll find fstat to be a helpful MV thing you can always use in OS-9.  But it
does use 16K I believe. I did get your email; I'll examine it in detail later
on.  But I'd say we're about ready to get down to work.

There is 1 Reply.

#: 12174 S10/OS9/6809 (CoCo)
    10-Sep-91  23:39:59
Sb: #12172-#mod help
Fm: Everett Chimbidis 76370,1366
To: Erich Schulman 75140,3175 (X)

I do have a 512 k computer and have mv do you need to see fstat on some of my
files? I am ready to go on now !! No time to waste! OK?



There is 1 Reply.

#: 12195 S10/OS9/6809 (CoCo)
    11-Sep-91  22:55:53
Sb: #12174-mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

No, I don't need fstat on anything you have.  I just wanted to make sure you
were aware that you can use fstat any time you're using OS-9, and IMHO it's a
helpful command.  Since you do have 512K, do you also have RAMdisk software? 
Using a RAMdisk will make changing your boot file both faster and a little
easier (esp. if you have a one-drive system).

#: 12173 S10/OS9/6809 (CoCo)
    10-Sep-91  22:23:21
Sb: #12170-#mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

I didn't get kutil on cis so I'm not sure if you can download it here or not. 
I'll see if I can find it and if I can't I'll upload it.

There is 1 Reply.

#: 12175 S10/OS9/6809 (CoCo)
    10-Sep-91  23:41:28
Sb: #12173-#mod help
Fm: Everett Chimbidis 76370,1366
To: Erich Schulman 75140,3175 (X)

OK I can't wait to get the file!!

Also will reupload you a list in Email ok?



There is 1 Reply.

#: 12196 S10/OS9/6809 (CoCo)
    11-Sep-91  22:59:37
Sb: #12175-#mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

kutil doesn't seem to be available for download on CIS.  I will upload it to
Library section 9 (Utilities) soon.  That way everyone can download it and try
it out.  You will =not= need kutil to install os9p3, but it would still be a
good program to have.

There is 1 Reply.

#: 12200 S10/OS9/6809 (CoCo)
    12-Sep-91  00:39:20
Sb: #12196-#mod help
Fm: Everett Chimbidis 76370,1366
To: Erich Schulman 75140,3175 (X)

Do I need any other programs to show you my boot?

There is 1 Reply.

#: 12201 S10/OS9/6809 (CoCo)
    12-Sep-91  00:52:28
Sb: #12200-#mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

Not really.  Ident is sufficient, though a listing of EZGen might be good to
have as well.  I believe your email's have enough info.

There is 1 Reply.

#: 12213 S10/OS9/6809 (CoCo)
    12-Sep-91  20:34:23
Sb: #12201-#mod help
Fm: Everett Chimbidis 76370,1366
To: Erich Schulman 75140,3175 (X)

When will you have the bootlist done?



There is 1 Reply.

#: 12218 S10/OS9/6809 (CoCo)
    12-Sep-91  22:57:30
Sb: #12213-mod help
Fm: Erich Schulman 75140,3175
To: Everett Chimbidis 76370,1366 (X)

We'll be ready soon.  Check your Email.

#: 12177 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  07:54:57
Sb: #80/40 tracks
Fm: Steve Wegert 76703,4255
To: Kev 76703,4227 (X)

Kev,

Blame Mark for this one ... he said you had all the answers!  :-)


I have a heap of 80 track 5.25 floppies in CoCo format, that I need to get to
40 track DSDD 5.25 format. (I don't have a 5.25 80 track drive).

Barry (who only has 80 track drives) has offered to convert the disk for me.
He'll be using his new TC70 to accomlish this task.

First question:

Can an 80 track drive be set up to read/write to a 40 track diskette?

If so ... what values need to be dmoded?

Steve

There is 1 Reply.

#: 12179 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  09:23:11
Sb: #12177-#80/40 tracks
Fm: Kevin Darling 76703,4227
To: Steve Wegert 76703,4255 (X)

Steve,

Woof <tm-Pete>.  An 80tk drive can certainly read a 40tk disk... nothing
special needs to be done to do that.  The driver figures it out when it reads
LSN 0.

Writing can also be done, tho I'd backup the resulting disks on the 40tk drive
to make sure you have a good strong copy.  I'd also format the disks on the
40tk drive.  This is from my own experience;  others may have other views :-)

We'll soon find out.  Grin. - kev

There is 1 Reply.

#: 12184 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  19:10:40
Sb: #12179-#80/40 tracks
Fm: Pete Lyall 76703,4230
To: Kevin Darling 76703,4227 (X)

For reasons I'll happily explain on demand, you really don't want to write on a
40 tracker while in your 80 track drive. It may appear fine, until you stick it
back in a 40 tracker....

Pete

There are 2 Replies.

#: 12187 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  20:39:11
Sb: #12184-#80/40 tracks
Fm: Steve Wegert 76703,4255
To: Pete Lyall 76703,4230 (X)

Soooooooooo ...

What I'm hearing is I can't get there from here?

Am I doomed to adding an 80 track drive to my setup?

Steve

There are 2 Replies.

#: 12189 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  20:54:42
Sb: #12187-#80/40 tracks
Fm: James Jones 76257,562
To: Steve Wegert 76703,4255 (X)

You can read and write 40 track disks on an 80 track drive...MOST of the time.

What you DO NOT want to do is write on a 40 track disk that's been written on
with a 40 track drive with an 80 track disk.  Say what?!

I'll be clear this time. :-)  Consider this (as REM would say): you format a
40-track disk on a 40-track drive.  Formatting it requires writing on it... at
least writing E5E5E5E5...all over it, and a allocation bitmap, and LSN 0, and a
mostly empty root directory.

OK, you take this disk over to an 80-track drive.  It reads it just fine... and
then you write on it.  The 80-track drive has a read/write head half as wide as
a 40-track drive--makes sense, right?  So, the 80-track drive is really only
writing, where it writes, on half the space the 40-track drive wrote on. 
Everything is hunky-dory...

..until you bring the disk back to a 40-track drive and try to read it.  In the
spots the 80-track drive wrote on, it's half the old stuff that the 40track
drive wrote and half the new stuff that the 80-track drive wrote.  The 40-track
drive gets heavily confused, and it's read error time.

So, the rule is this: if an 80-track drive EVER writes on a 40-track disk, the
ONLY drives that can write on it are 80-track drives.  If that's inconvenient
or won't work for what you want to do, you'll need both kinds of disk for
writing purposes.

There is 1 Reply.

#: 12223 S11/OS9/6809 (Non-CoCo)
    13-Sep-91  07:13:26
Sb: #12189-80/40 tracks
Fm: Steve Wegert 76703,4255
To: James Jones 76257,562 (X)

Ok ... sounds as if I need to do some hardware shopping.


<mutter>


Owell ... I accepted this hobby, black hole and all!  :-)

Steve

#: 12199 S11/OS9/6809 (Non-CoCo)
    12-Sep-91  00:13:03
Sb: #12187-#80/40 tracks
Fm: Pete Lyall 76703,4230
To: Steve Wegert 76703,4255 (X)

Steve,

Eh? You'll need an 80 tracker to read 80's and 40's. A 40 tracker is
only good for 40's (and 35's, of course).

Reason why? Well, in order to get 80 tracks in the same space as 40,
they had to cut down both the intertrack gap size and the track width,
so an 80 track head cuts a narrower swath (magnetically). Imagine
that this is a 40 track 'data' track:

    4040404040404040404040404040404040404040
    4040404040404040404040404040404040404040
    4040404040404040404040404040404040404040

And this is an 80 tracker's data:

    8080808080808080808080808080808080808080

If you wrote on a diskette that had been perviously treated (written;
formatted) by a 40 tracker, you'd get this:


    404040404040404040404040404040404040404040
    808080808080808080808080808080808080808080
    404040404040404040404040404040404040404040

In other words, the 80 track narrow data track would be imposed upon
the existing wider 40 track path. You're okay if you only read this
with the narrower 80 track head, which will reject the side garbage
that's leftover from the 40 track data. HOWEVER, if you reinsert this
in a 40 track drive and try to read it, the wider 40 track head MAY
see both the new 80 track written data and the older, corrupt, 40 track
data... it's really a hairy issue of luck and (mis)alignment if it works.
In the process, it may render the disk unreadable by anything but the
80 track drive.

While some of this was simplified for the sake of explanation, this
is basically the problem.

Pete

There is 1 Reply.

#: 12224 S11/OS9/6809 (Non-CoCo)
    13-Sep-91  07:17:33
Sb: #12199-#80/40 tracks
Fm: Steve Wegert 76703,4255
To: Pete Lyall 76703,4230 (X)

As the little red headed girl would say, "Gotit dude!"

I'll be scouting around from an 80 tracker. Mayhaps we have something laying
around the equipment room at the office I cn borrow for the task.

Thank god I have a /d1 descriptor already in my boot that I could dmode up to
the proper parameters. My system has been struck with the a terminal case of
the BLOB. No way, no how can I come up with a different bootfile that what I
currently have.\

Can OSK be too far off in my future?


Thanks for the explanation (you too James!).

Steve

There are 2 Replies.

#: 12232 S11/OS9/6809 (Non-CoCo)
    13-Sep-91  10:49:09
Sb: #12224-80/40 tracks
Fm: Pete Lyall 76703,4230
To: Steve Wegert 76703,4255 (X)

De nada, dude.

Pete

#: 12242 S11/OS9/6809 (Non-CoCo)
    14-Sep-91  08:21:41
Sb: #12224-80/40 tracks
Fm: Robert A. Hengstebeck 76417,2751
To: Steve Wegert 76703,4255 (X)

I put in an 80 track disk drive, in my system years ago it seems.  And it
wouldn't work.  I found out after taking it to Ron Schmidts of L R Techs fame,
that it was really a 1.2 meg drive.  Fortunately, I was able to trade it for a
720K drive, and everybody was happy.  So the word for the wise is
.....etc.

#: 12190 S11/OS9/6809 (Non-CoCo)
    11-Sep-91  21:10:13
Sb: #12184-80/40 tracks
Fm: Kevin Darling 76703,4227
To: Pete Lyall 76703,4230 (X)

Ooops. You're right. He should probably format the disk in the 80tk drive, yes?

I mean, if this is the only way to get copies over.  Be better if someone had
both kinds of drives, of cuss.

#: 12178 S1/General Interest
    11-Sep-91  08:29:47
Sb: OS9p3
Fm: Paul Hanke 73467,403
To: anyone

What is OS9p3 I've seen mentioned lately?    -ph-

#: 12181 S1/General Interest
    11-Sep-91  18:02:01
Sb: #12152-#gshell+
Fm: Bob Santy 76417,714
To: Paul Hanke 73467,403 (X)

Paul:

What does IDENT say about the original gshell BEFORE running IPatch?

IPatch opens the second argument (assumed to be the original module) for input
and does not modify it.  I would guess that the original is somehow corrupted. 
Offset 2 in the module header is the most significant byte of the module size. 
A size of $FF.. would make for a pretty large module.

Bob



There is 1 Reply.

#: 12182 S1/General Interest
    11-Sep-91  18:10:19
Sb: #12181-#gshell+
Fm: Bob Santy 76417,714
To: Bob Santy 76417,714 (X)

Paul:

I just noticed that the output file was named "gshell+".  The "+" is not a
legal OS9 file name character and may be the problem.  IPatch probably opened
"gshell" for output as well.  Try another (legal) name.

Bob

There are 2 Replies.

#: 12185 S1/General Interest
    11-Sep-91  19:19:33
Sb: #12182-gshell+
Fm: Paul Hanke 73467,403
To: Bob Santy 76417,714 (X)

Ok, will try it later.   -ph-

#: 12191 S1/General Interest
    11-Sep-91  21:43:31
Sb: #12182-gshell+
Fm: Paul Hanke 73467,403
To: Bob Santy 76417,714 (X)

Yep, that did it. That also explains why I was able to successfully upgrade
gshell some time ago - just used a filename without the '+'  as whimsically as
I used it this time.  Thanks.   -ph- 

#: 12186 S12/OS9/68000 (OSK)
    11-Sep-91  20:05:08
Sb: #$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)

Mark;
 
  Looks like you are my only hope of getting my MM/1 fixed in the near
future.
  My Power Supply started making noises like the fan rubbing on 8/21,
less than 2 weeks after I received it.  I left Paul a note on 8/22
(which he still hasn't read) and finally got through to him on 8/30.
He was going to call me back that afternoon, but never did.  I still
don't know what must be done to resolve the situation.
 
  In desperation, I swapped the PS in this '386 clone that I'm using now
with the MM/1's, and the fan wouldn't even run.  Yes, the outputs are
the same!  Replacing the original PS, even though the fan? runs noisily,
the MM/1 will boot, but the screen is only faintly glowing - no readable
output, but it IS blue.
 
  Q.  Is the MM/1 PS a 'special animal' that requires a very small load?
  Q.  Are there any measurement points on the system board that I can
      check with a VOM?
  Q.  In the event I need to send it in, should I sent the whole setup,
      or just the system board & PS?
  Q.  Why won't this '386 PS work with the MM/1?
  Q.  Where's PAUL???
 
  I'm not *real* happy with my $1000 doorstop at this point!
 
  Thanks,
      ...Jim
 
 

There are 2 Replies.

#: 12203 S12/OS9/68000 (OSK)
    12-Sep-91  04:05:06
Sb: #12186-#$1000 doorstop
Fm: Scott t. Griepentrog 72427,335
To: Jim Peasley 72726,1153 (X)

Assumming you have only one board, and one (or two) floppies, the power
requirements of your system are *very* small.  The 386 power supply, while
completely compatible (the MM1 PS is a standard PC design), needs a little bit
more load before it will fire up.  This can be solved easily by any method that
puts more load on the power supply.  If you have a 'spare' hard drive sitting
around (say something that doesn't work even, but spins), that would be ideal
to use as a load.  Other alternatives include using a large wattage resistor,
probably somewhere around 50 ohm (I 'm gessing here - don't take my word!),
connected between +12 and ground. Since the MM1 and these newer 3-1/2" drives
use so little if any current from 12 volts, this is most likely the only
voltage you'll need to load. If that still doesn't work though, try putting a
load on 5 volts too. Obviously, a spare hard drive makes for the simplest test.
Let me know how you fare.

StG

There is 1 Reply.

#: 12211 S12/OS9/68000 (OSK)
    12-Sep-91  09:06:54
Sb: #12203-#$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Scott t. Griepentrog 72427,335 (X)

Scott;

  Thanks,  I hadn't thought of spinning up a HD - no I/O board yet. I've got a
spare IDE that I'll hook up as a load this evening and let you know.

  Do you carry advertising in the OSK'er?  Not subscribing to RAINBOW any
longer, I'm kinda in the dark about new software offerings for OS-9. I think
that I've got your address around here somewhere, but why don't you post it
again, along with sub. rates.

  Thanks,
     ...Jim




There is 1 Reply.

#: 12212 S12/OS9/68000 (OSK)
    12-Sep-91  10:51:39
Sb: #12211-$1000 doorstop
Fm: Scott t. Griepentrog 72427,335
To: Jim Peasley 72726,1153 (X)

Yes, we carry advertising in the OSK'er.  Several outfits that are either
selling OSK hardware or software.  And, we still support 6809 OS9 too!

Subscriptions are $12 in the U.S.  For more info, call me at (317) 668-8878.
The OSKer SMAILbox is P.O. Box 24285, Speedway IN 46224.

p.s. the rates are going up shortly...

StG

#: 12208 S12/OS9/68000 (OSK)
    12-Sep-91  05:02:01
Sb: #12186-#$1000 doorstop
Fm: Mark Griffith 76070,41
To: Jim Peasley 72726,1153 (X)

Jim,

  Q.  Is the MM/1 PS a 'special animal' that requires a very small load?

No, not really.  A new PS from some of the catalogs goes for around $80.

  Q.  Are there any measurement points on the system board that I can
      check with a VOM?

Pin 1 on the backplane is ground, pins 61 and 62 or 5 volts and 63 and 64 12
volts.  You should get these readings there.

  Q.  In the event I need to send it in, should I sent the whole setup,
      or just the system board & PS?

Well, if you can't find Paul, the best thing to do would get a new PS and then
get Paul to repay you for it since it is under warrenty.  Any store that sells
PC parts and supplies will be able to help you if you bring the old PS in with
you.

If the MM/1 still doesn't work after that, then send it to me by itself.

  Q.  Why won't this '386 PS work with the MM/1?

Probably not enough current draw to get it going. The MM/1 is a very very low
draw machine.

  Q.  Where's PAUL???

Don't feel bad about not getting Paul.  I haven't been able to talk to him in a
couple weeks now (grin).  He is very very busy.

Mark

There are 2 Replies.

#: 12210 S12/OS9/68000 (OSK)
    12-Sep-91  09:06:29
Sb: #12208-$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)

Mark;

  Thanks for the prompt reply.  StG suggested loading the PS with a HD which
I'll try this evening.  Failing that, I'll make some voltage measurements and
let you know what I find.

  It's good to see you (back) on CIS... I get the OS-9 and COCO list feeds at
work, but don't have reply capability and it's really frustrating to not be
able to jump into some of the discussions.  :-(

  A non-related question while I've got you: While my MM/1 WAS working,  I
tried using it for communication, but when CTRL<T>ransmitting ready-to-go
messages, each time the MM/1 / STERM combination would totally thrash my
message.  At first I thought it was the phone cord, as I had the machine set up
away from it's normal phone jack,  but the same phone line/modem/modem cable
works just fine with PROCOMM and the PC.
  Could this be related to the PS problems do you think?

  Thanks,
      ...Jim




#: 12221 S12/OS9/68000 (OSK)
    13-Sep-91  00:46:57
Sb: #12208-#$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)

Mark;

  With a replacement PS and a HD + 2 floppies as a load, the MM/1 will boot
O.K. and it'll respond to the keyboard when I do a 'dir', but the screen is
just barely glowing a deep blue.  My startup creates a 2nd window that's black
on white, but F2'ing to /w2, there's no change in the screen.   Unplugging the
HD causes the PS to switch out, and there is no output.

  Looks like maybe the video circuit took a hike, no?  The CM-8 works O.K. on
the CoCo, so that's also not a possibility.

  What next?  I eagerly await your reply!  ;-)

..Jim



There are 2 Replies.

#: 12222 S12/OS9/68000 (OSK)
    13-Sep-91  05:05:16
Sb: #12221-#$1000 doorstop
Fm: Mark Griffith 76070,41
To: Jim Peasley 72726,1153 (X)

Jim,

Guess the next step is to send your board in to me.  No need to send the case
and PS.  Haven't seen a problem like this one before so it will be a learning
experience.  My address is:

Mark Griffith 953 W. Wisconsin Ave. DeLand FL 32720

(904) 736-1535

Mark

There is 1 Reply.

#: 12238 S12/OS9/68000 (OSK)
    13-Sep-91  22:08:46
Sb: #12222-$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)

Mark;

  O.K. - the board is on it's way to you in the A.M.

I left a message for Paul this morning, but I guess he's busy with the
convention and couldn't reply.

  Will be real interested to find out what the problem is/was.

Thanks,
  ...Jim



#: 12234 S12/OS9/68000 (OSK)
    13-Sep-91  17:51:47
Sb: #12221-#$1000 doorstop
Fm: John R. Wainwright 72517,676
To: Jim Peasley 72726,1153 (X)

Hey Jim, you already looked REAL CLOSE at your MM/1 - CM8 cable (or adaptor)
right?  One of my best tricks is to create a new problem by knocking something
loose while I am fixing the original problem.  (Just a thought).

JohnW

There is 1 Reply.

#: 12239 S12/OS9/68000 (OSK)
    13-Sep-91  22:09:07
Sb: #12234-#$1000 doorstop
Fm: Jim Peasley 72726,1153
To: John R. Wainwright 72517,676 (X)

John;

  Yep, first thing I did was to pull the board and examine it with a 10X loupe
for extraneous parts/filings/broken traces/etc.   Figgered that _I_ screwed
something up!

  The CM-8 works fine with the CoCo, so that's not it either...  I had to make
my own cable/adapter and at least I'm qualified with a soldering iron!
         :-)
  I cut the plug off the CM-8 and connected a DB9 to the cable, then made a 10
pin IDC header plug to DB9 male cable that I keep plugged into CoCo. That way I
don't have to keep picking the doggone thing up to plug/unplug the video cable.

..Jim

There is 1 Reply.

#: 12240 S12/OS9/68000 (OSK)
    13-Sep-91  23:11:09
Sb: #12239-#$1000 doorstop
Fm: Randy Wilson 71561,756
To: Jim Peasley 72726,1153 (X)

Jim,
 
   Check out your MM/1 <-> CM8 cable *real* good. I got myself in trouble
hooking up my Maggie. Ya see, the MM/1 and CoCo are pin for pin on the connect.
But, when viewed from the ribbon cable's point the pins are:
 
 1 2 3 4 5 6 7 8 9  for a DIP header
 
          and
 
 1 9 2 8 3 7 4 6 5  for a DB9
 
   I orignally used a crimp-on DB9, and the video output was a strange blue
with no vertical of horz hold. Occasionally I'd see text. That's how I knew the
syncs where "gone". I hand made my own cable, rather than modifying the CoCo's
and everythings been cool since. (except, of course, the brain-dead serial port)

Randy

There is 1 Reply.

#: 12245 S12/OS9/68000 (OSK)
    14-Sep-91  09:32:34
Sb: #12240-$1000 doorstop
Fm: Jim Peasley 72726,1153
To: Randy Wilson 71561,756 (X)

Randy;

  The setup worked for a while, then all of a sudden 'went south'... so I don't
think that's it.  Thanks for the thought, tho!

..Jim

#: 12188 S10/OS9/6809 (CoCo)
    11-Sep-91  20:53:16
Sb: #UMUSE for MM1
Fm: Bert Schneider 70244,427
To: Lee Veal 74726,1752 (X)

Hey Mike, need any other beta testers for UMUSE for the MM1?  I'd be glad to
help out!  Please let me know! Bert

There is 1 Reply.

#: 12197 S10/OS9/6809 (CoCo)
    11-Sep-91  23:15:40
Sb: #12188-#UMUSE for MM1
Fm: Lee Veal 74726,1752
To: Bert Schneider 70244,427 (X)

I think you've got the wrong person.

M' name's Lee, not Mike...

..but Mike might want your help, but you'd better ask him for sure.

;-)

Lee

There is 1 Reply.

#: 12270 S10/OS9/6809 (CoCo)
    16-Sep-91  22:14:18
Sb: #12197-UMUSE for MM1
Fm: Bert Schneider 70244,427
To: Lee Veal 74726,1752 (X)

Sorry!  I guess I hit the wrong button when I was reading messages!!!!

#: 12192 S7/Telecommunications
    11-Sep-91  21:58:01
Sb: #12111-#sterm 1.5
Fm: Rick Ulland 70540,3305
To: Steve Wegert 76703,4255 (X)

Steve-
 I almost hate to bring this up again,but-I just can't get STERM to from MV.
I've used all of those patches and made a nice AIF with -l /m1 on the parameter
line.For my trouble, I get a pink screen with a white overlay and a dead block
cursor.I can click on an AIF I made for shell, and start it from the command
line in the new shell,so what could I possibly be doing to the STERM AIF? Know
MV can handle it, it does! just not from gshell directly. Any thought you may
have would be app.
 -Rick

There is 1 Reply.

#: 12225 S7/Telecommunications
    13-Sep-91  07:22:12
Sb: #12192-sterm 1.5
Fm: Steve Wegert 76703,4255
To: Rick Ulland 70540,3305

Hmmm .. lessee if I can bring up my sterm AIF file ...



sterm
-f -l /t5
ICONS/icon.stm
#40
2
80
24
0
1

Works for me.

Your /m1 device is activated in your env.file, jes?

Steve

#: 12193 S7/Telecommunications
    11-Sep-91  22:03:07
Sb: #12128-sterm 1.5
Fm: Rick Ulland 70540,3305
To: Steve Wegert 76703,4255 (X)

Paul-
 Deldir does that when it can't find Attr.It needs to change (delete) the d
attribute to delete the directory itself.Load attr or keep it handy in cmds,
which is sometimes hard to do if ya merge files like I do- I could always find
attr, deldir couldn't!
 -Rick

#: 12194 S10/OS9/6809 (CoCo)
    11-Sep-91  22:13:13
Sb: #Lines/Put/etc
Fm: Brother Jeremy, CSJW 76477,142
To: Kevin Darling, 76703,4227 (X)

Dear Kevin

Based on advice which you gave to George Hendrickson in MSG 9952, I tried the
following code:

PROCEDURE TestNewLine

(* usage: RUN NewLine(path,a,b,c,d)

DIM path,a,b,c,d:INTEGER

path=1

RUN gfx2("CLEAR")

RUN NewLine(path,10,25,10,75)


PROCEDURE NewLine

(* usage: RUN New(path,etc)

Param path,a,b,c,d:INTEGER

DIM esc(10):BYTE

esc(1)=$1B

esc(2)=$44

esc(3)=a/256

esc(4)=land(a,$FF)

esc(5)=b/256

esc(6)=land(b,$FF)

esc(7)=c/256

esc(8)=land(c,$FF)

esc(9)=d/256

esc(10)=land(d,$FF)

PUT #path,esc

It worked, sort of. Instead of getting a staight line, I got a diagonal. I
figured out that the calling program had to have all the values in hex. When I
changed it, the program worked. Is there any way around this. I would like to
be able to call NewLine with the same parameters as I would in calling the gfx2
Line command. Is there a short piece of code which could convert the decimal to
hex prior to being processed by newline?

This is all still sort of new to me, so please forgive my asking what should be
obvious.

As ever, Br. Jeremy, CSJW



There is 1 Reply.

#: 12202 S10/OS9/6809 (CoCo)
    12-Sep-91  03:27:09
Sb: #12194-#Lines/Put/etc
Fm: Kevin Darling 76703,4227
To: Brother Jeremy, CSJW 76477,142 (X)

Jeremy - one key is, you first must send a "move-to" escape code ($1b 40 x y)
with the first coordinate, and then the "line-to" code ($1b 44 x y).

PROCEDURE TestNewLine
(* usage: RUN NewLine(path,a,b,c,d)
DIM path,a,b,c,d:INTEGER
INPUT "line x1,y1,x2,y2 ",a,b,c,d
path=1
RUN gfx2("CLEAR")
PRINT  \ PRINT  \ PRINT  \ PRINT 
RUN NewLine(path,a,b,c,d)
END 

PROCEDURE NewLine
(* usage: RUN New(path,etc)
PARAM path:INTEGER
PARAM a,b,c,d:INTEGER
TYPE line_esc=esc1,esc2:BYTE; x,y:INTEGER
DIM code:line_esc
code.esc1=$1B
 
code.esc2=$40
code.x=a
code.y=b
PUT #path,code \ (* send move-to a,b
 
code.esc2=$44
code.x=c
code.y=d
PUT #path,code \ (* send line-to c,d
END 

PS: I got a little fancy on the TYPE/DIM stuff... only to make using
the coordinate a little easier/faster, perhaps.  - kevin

There is 1 Reply.

#: 12215 S10/OS9/6809 (CoCo)
    12-Sep-91  21:01:15
Sb: #12202-Lines/Put/etc
Fm: Brother Jeremy, CSJW 76477,142
To: Kevin Darling 76703,4227 (X)

Thank you Kevin. I will probably have more questions after I have had a chance
to play with this --Br. Jeremy, CSJW.

#: 12198 S1/General Interest
    12-Sep-91  00:01:48
Sb: #xym or xfr?
Fm: James Jones 76257,562
To: All

I'm going through stuff trying to transfer things from my CoCo to my MM/1, and
in the process (a rather hairy one; I think I'll go to some trouble to avoid
having to do anything with the source of rz and sz; a shame, because the
versions I have appear to have comm paths wired into them for some reason), I
found something interesting.  I have two programs that, apart from some
character string constants, are identical.  The programs in question are "xfr"
and "xym."

Somebody appears to have changed the banner, including the author's name, and
distributed the program; a rather tacky thing to do IMHO.  Anyone out there
know for sure who really wrote this program?  I've kept the one that had
"protocol" spelled correctly in the banner, but that's just my personal bias. 
I'd really rather keep the version that correctly attributes the authorship.

There is 1 Reply.

#: 12204 S1/General Interest
    12-Sep-91  04:10:45
Sb: #12198-#xym or xfr?
Fm: Scott t. Griepentrog 72427,335
To: James Jones 76257,562 (X)

Actually, I've been looking for the author of the "xym" program for some time. 
At one time, it was considered the only x/y modem transfer that functioned
correctly under StG Net.  I did not know of the existance of a duplicate "xfr"
program - who is the author stated on it?  Maybe that was the original copy. 
Unfortunately, I can only add to the confusion...

StG

There is 1 Reply.

#: 12207 S1/General Interest
    12-Sep-91  04:28:15
Sb: #12204-#xym or xfr?
Fm: James Jones 76257,562
To: Scott t. Griepentrog 72427,335 (X)

Oops...that's the version I tossed.  (Guess I was too quick...hang on a
minute...aha!  It says "Bob Thomas" where the other says "Jim Hollier.")

There is 1 Reply.

#: 12226 S1/General Interest
    13-Sep-91  07:26:20
Sb: #12207-#xym or xfr?
Fm: Steve Wegert 76703,4255
To: James Jones 76257,562 (X)

JJ,

The version I scarffed from Pete's box years ago is:

   XModem & YModem Protocal File Server
          (c)  copyright  1988
         Written by Bob Thomas


SYNTAX:  xfr opt1 opt2 filename
         where opt1 = x   for xmodem
                    = y   for ymodem
         where opt2 = r   for uploading
                      s   for downloading
     where filename = any legal OS9 filename

 example:  xfr x s testfile
           xfr y r testfile


Help?

Steve

There is 1 Reply.

#: 12227 S1/General Interest
    13-Sep-91  07:30:09
Sb: #12226-#xym or xfr?
Fm: James Jones 76257,562
To: Steve Wegert 76703,4255 (X)

Yup!  Thanks.  Kind of depressing to think that somebody would mung a program
to insert his name instead of the original programmer's, eh?

There are 3 Replies.

#: 12229 S1/General Interest
    13-Sep-91  07:35:08
Sb: #12227-xym or xfr?
Fm: Steve Wegert 76703,4255
To: James Jones 76257,562 (X)

Perhaps 'low-down' is a better description ....

Steve

#: 12235 S1/General Interest
    13-Sep-91  20:37:46
Sb: #12227-xym or xfr?
Fm: Scott t. Griepentrog 72427,335
To: James Jones 76257,562 (X)

That's probably why I was never able to find that Hollier guy.

StG

#: 12257 S1/General Interest
    15-Sep-91  21:28:36
Sb: #12227-#xym or xfr?
Fm: Bob van der Poel 76510,2203
To: James Jones 76257,562 (X)

James (and others...), I've been following this and other threads on using
various com programs to transfer files between the coco and the mm1 -- I don't
get it! Why not just get a disk drive which is compatible with the coco and the
mm1 and exchange disks. I stuck a 80 track drive in my mm1 the day I got it and
have been flipping disks back and forth ever since. It's just a matter of
setting up a descriptor. For coco disks you have to set typ=20, soffs=1,
sct=12, tos=12, cyl=50. The rest stays the same as for a HD mm1 disk.

The only problem I've had with the mm1 disk driver is that it will not format a
standard format (track 0 single density) and it will not double step for a 40
track disk in an 80 track drive. BTW, it will read/write single density--I hope
someone is working on this.

Hope this helps.

There is 1 Reply.

#: 12264 S1/General Interest
    16-Sep-91  03:11:49
Sb: #12257-xym or xfr?
Fm: James Jones 76257,562
To: Bob van der Poel 76510,2203 (X)

That is probably the fastest way to do it.  (Nudge Paul Ward inclusive-or Carl
Kreider about the 40-track disk in 80-track drive, etc.)

#: 12205 S12/OS9/68000 (OSK)
    12-Sep-91  04:17:14
Sb: #OSK standards
Fm: Ed Gresick 76576,3312
To: Robert A. Larson 75126,723 (X)


 Bob,

 I appreciate your response and input.

 Are you on DELPHI?  If so, could you upload 'oskstand.doc' there.  If not,
 may I do so?  The discussions re standards are going on there.  I'm trying
 to keep people on the other boards/nets informed so, I'd like to upload
 your file to Fidonet.

 My comments -

 I agree with you re TERMCAP.  One point - to the best of my knowledge,
 TERMCAP does not address graphics.  Extensions could be added but this
 would be ill-advised since the dominate users of TERMCAP come from the
 mainframe and UNIX communities.  They could decide to add their own
 extension creating possible conflicts.  Therefore, graphics, mouses (or
 mice), etc. data should probably go into a separate environmental file.

 Re S-ISHARE.  Never thought of that.  Has possibilities but I think every-
 one will have to agree to that.  So far as I've seen, most programmers
 are using some sort of lock file.  I do see one problem - how would you
 know what the pid is of the process controlling the port so you could
 remove it for outgoing calls?

 Printers present the same problem terminals do.  I heard that someone
 has already written a PRINTERCAP file.  Needs looking into.

 On OSK, 'xmode' can get and set type and baud rate already without
 deinizing so I assume you can do the same thing with getstat/setstat calls.

 I think that writing a bi-directional driver to handle both incoming and
 outgoing calls 'simultaneously' as you suggest would be a bear.  Could be
 done but I'm not sure it's necessary.  I already use a common port for
 both incoming and outgoing calls on my CoCo.  My set-up does require a
 lock file.

 (Continued in part 2)

There are 4 Replies.

#: 12206 S12/OS9/68000 (OSK)
    12-Sep-91  04:18:21
Sb: #12205-OSK standards
Fm: Ed Gresick 76576,3312
To: Ed Gresick 76576,3312 (X)


 (Continued from part 1)

 Briefly, it works like this.  (I run tsmon on my modem port (m0).)  First I
 set the modem for auto-answer with the command 'echo "ATS0=1"'.  Then I
 use Brett Wyncoop's 'enable' to set up the port.  'Enable' activates tsmon,
 gets the pid for tsmon, sets up a lock file for port m0 and places
 tsmon's pid in the lock file.  This is the normal state for my system.
 If I want to use the modem for an outcalling call (or disable the modem
 for other reasons), I use Brett's 'disable'.  'Disable' reads the lock
 file for that port, gets the pid, kills the process and removes the lock
 file.  I follow this with the command 'echo "ATS0=0"' to turn off
 auto-answer.  Actually, I use two script files, 'start_m0' and 'end_m0',
 to activate and deactivate the port.  'Start_m0' is also in my 'startup'
 file.  I run UUCP and Kermit for both incoming and outgoing calls and Sterm.
 Most outgoing UUCP and Kermit calls are handled by 'cron' so you can see the
 process operates unattended.  I've had the system running this way for
 almost two years now.  If I ever get a version of UUCP that will work under
 OSK, I'll install it on my SYSTEM IV.  But I doubt I'll put it on line.  I
 use the CoCo only for unattended communications (file transfers, mail, etc.)
 so I'm not worried about security.

 How does Suno use two logical devices?  Seems to me that under OS9 and
 task switching, the two devices would get confused - the wrong one getting
 information.  I'm assuming you have tsmon running to one and doing an
 outgoing call from the other.

 Ed Gresick - DELMAR CO

#: 12364 S12/OS9/68000 (OSK)
    21-Sep-91  20:44:15
Sb: #12205-OSK standards
Fm: Robert A. Larson 75126,723
To: Ed Gresick 76576,3312 (X)

No, I'm not on delphi.  Go ahead and upload my responce there if you like. 
Please note that I answer my mail faster on the StG network (blarson@zog)
(zog's cavern bbs is at (818)761-4721) and the Internet
(blarson@abode.ttank.com and (this one appears to be loosing mail)
blarson@usc.edu) than I do here on compuserve.

Graphics: For more than box drawing, I think the only real standard is X.  The
osk community may need to develop its own standard, this is not something every
programmer should have to reinvent.

Xmode can be used to set the type and baud rate.  Unfortunatly, on both osk
systems I have used, this does not take effect until the device is closed and
deinized.  If your systems don't have this problem, that is good, but be aware
that your compeditors systems do have this problem and they need to fix it.

It looks like I've only been using the S_ISHARE since 1986, obviously to new an
idea to have caught on yet :-)  (That's the date on the oldest instance of this
I could easily locate -- of course any test versions are long gone.)

You'll probably find my name on any versions of kermit you are using on an os9
system, (although the 68k assebly version wasn't mine) and I've been using osk
since version 1.2.  Although my name isn't as familiar as some others, please
don't treat me like a newcommer.  I don't have one of your systems because I
didn't here of you until long after I had my QT20x.  Do you have a system that
competes with it?

The uucp version I am working on seems to be working ok for file transfers with
all the unix versions I have tested against, so it should be released
reasonably soon (by the end of the year :-) unless uuxqt is as much of a mess
as the file transfer part was.  (I don't want to get into the problems I've had
with this port right now.)

(continued)



#: 12365 S12/OS9/68000 (OSK)
    21-Sep-91  20:45:27
Sb: #12205-OSK standards
Fm: Robert A. Larson 75126,723
To: Ed Gresick 76576,3312 (X)


Every program using a different lock file in a different manner is exactly what
I want to avoid.  The unix lock file structure requires an atomic link
operation that osk does not supply.  Since this area will have to be recoded
when porting any unix program, I think using the S_ISHARE mechinism is simpler,
more elegent, and more reliable than any kind of lock file.  It is already in
use in at least two communications programs.

There seems to be two approches to the bi-directional modem problem: (a)
modifying the device driver to look like to separate devices (b) modifying
tsmon, login, and all programs that might ever have to access the modem.  (a)
looks much simpler to me.

The device driver approach does not have to worry about race conditions because
it runs in system state.  The answer side open may be done at any time, a read
call will wait for both carrier detect and originate flag not being set.  Upon
detecting carrier, a flag is set indicating that the device is in use in answer
mode which is cleared only when carrier detect drops.  An attempt to open the
originate side when the answer flag is set will return an error that the device
is busy.  Opening the originate device will set the originate flag indicating
that the device is in use in orignate mode. This flag will be cleared when the
originate side is closed.  The two flags are used to determine where the I/O is
routed.  Tsmon is normally left running all the time on the answer side.

The lock file/kill process approch seems to have problems with timing holes and
an excess of complexity.  Problems in communications programs will cause the
port not to be reenabled for incoming calls. You did not describe how the
disable program determines that the line is not currently in use for an
incoming call.  (I do not want to hang up on a caller just because it is time
to try a uucp transfer.) I leave Ckermit running all the time, just set the
line and fork a subshell when I'm not using it for communications, how can you
handle this?.  Osk tsmon handles multiple lines, how should I tell it not to

#: 12366 S12/OS9/68000 (OSK)
    21-Sep-91  20:51:22
Sb: #12205-OSK standards
Fm: Robert A. Larson 75126,723
To: Ed Gresick 76576,3312 (X)

(even more continued.  Stupid message length limit) use one line but keep
tworking on the rest?  Or do you expect me to run a separate tsmon process for
every modem?  (Besides the one that handles all the terminals, of course.)

#: 12214 S7/Telecommunications
    12-Sep-91  20:39:11
Sb: #sterm 1.2 transfers
Fm: Erich Schulman 75140,3175
To: ALL

I have been using sterm 1.2 with some real success now.  But its only binary
protocol of CIS B is quite restrictive:  where can you use it BUT on CIS.  I
have obtained a program called xydown which will allow file transfers in Xmodem
or Ymodem.  Xydown must be called from a terminal program; it is not a
stand-alone program.  I tried to use the Shell option in sterm to run xydown
when I wanted to download a file.  After the disk drive finished spinning, I
saw the message "Sterm back online".  The host (which was a local BBS) timed
out with no bytes transferred.  Is there a bug with sterm's Shell option, or
perhaps is it restricted  somehow as to how it may be used?  Also, as long as
sterm supports receiving in CIS B, does it also support sending in that
protocol?

There are 2 Replies.

#: 12216 S7/Telecommunications
    12-Sep-91  21:43:19
Sb: #12214-#sterm 1.2 transfers
Fm: Wayne Day 76703,376
To: Erich Schulman 75140,3175 (X)

Uh, Erich.... STerm was designed SPECIFICALLY FOR OS-9 users ON COMPUSERVE!

That's why it only supports the CIS Quick-B Protocol!

And yes, STerm supports B Protocol transmissions as well!

As far as running xydown as a shell process, it sounds as if something told
STerm that the xydown shelled process had quit, which sounds suspiciously like
something that xydown would have to do itself.

Wayne

There is 1 Reply.

#: 12219 S7/Telecommunications
    12-Sep-91  23:02:33
Sb: #12216-#sterm 1.2 transfers
Fm: Erich Schulman 75140,3175
To: Wayne Day 76703,376 (X)

Considering the opening screen of sterm, I could easily notice its CIS
orientation.  But it is the only OS-9 terminal program I have.  Recently I
found that a local BBS has a 180K GIF file I wanted to get.  I do have
double-sided 40track drive, but my DECB double-sided utility clashes with
Ultimaterm 4.1 so I have no choice but to use OS-9.  And if sterm is my only
OS-9 terminal program....

There is 1 Reply.

#: 12228 S7/Telecommunications
    13-Sep-91  07:33:32
Sb: #12219-#sterm 1.2 transfers
Fm: Steve Wegert 76703,4255
To: Erich Schulman 75140,3175 (X)

Erich,

Now that you've mastered the ins and outs of the basic version of Sterm ... why
not upgrade to the current 1.5 version. It supports xmodem (esc x) and makes it
handier to user elsewhere.

It's in the telcom library.

Steve

There is 1 Reply.

#: 12233 S7/Telecommunications
    13-Sep-91  11:12:22
Sb: #12228-#sterm 1.2 transfers
Fm: Erich Schulman 75140,3175
To: Steve Wegert 76703,4255 (X)

Actually I had downloaded sterm 1.5 before but couldn't make it work.  I
suspect that the problem was Xmodem padding.  It took a lot of work to get your
emailed copy of the dEd module to work, all caused by Xmodem padding. I was
beginning to suspect that dEd didn't work on Level II.  But now that I do have
it working properly (indicated by a successful pad strip) I can now see about
fixing up sterm 1.5.  I just hope my previous efforts to make it work didn't
cause a necessity to redownload.  BTW, I actually do have (sort of) Xmodem
capabilities under OS-9.  That's with DeskMate 3.  But I have found DeskMate 3
to be awkward on a one-drive system.  And I think MultiVue is a much better
package anyway.  At least I got that DM3 for only $5.

There is 1 Reply.

#: 12243 S7/Telecommunications
    14-Sep-91  09:09:35
Sb: #12233-#sterm 1.2 transfers
Fm: Steve Wegert 76703,4255
To: Erich Schulman 75140,3175 (X)

Erich, keep up posted.

I think your troubles with 1.5 early on may just have been getting used to it'
quirkiness .... and perhaps the padding etc. Give it another shot. It's
straight forward. Just get the supportting files in the proper subdirectories,
ad fire it up with a new syntax:

Sterm -f -l /t2

Note the second option for modem line.


Steve



There is 1 Reply.

#: 12259 S7/Telecommunications
    16-Sep-91  00:10:01
Sb: #12243-sterm 1.2 transfers
Fm: Erich Schulman 75140,3175
To: Steve Wegert 76703,4255 (X)

What I have decided to do is download the complete archive rather than just the
executable.  I think the docs will help and I have never had a prob with
padding after extracting.  Not that padding is much of a prob for me anymore. 
Before I had never gotten the thing to go; ident always gave me a Module header
is incorrect!  I have found elsewhere a command that will patch in memory only
os9p1 to turn the CRC checking on or off.  That may be of some use for when
padding becomes moot and I still have that message in ident.  I have yet to
extract its archive so all I now know is what the uploader's description says.

#: 12348 S7/Telecommunications
    20-Sep-91  21:01:25
Sb: #12214-#sterm 1.2 transfers
Fm: Bill Dickhaus 70325,523
To: Erich Schulman 75140,3175 (X)

Erich,

It sounds like something else is not quite right. I use xydown all the time,
with Sterm, to download from Delphi. I've downloaded huge files with very few
problems. Make sure you are in a valid data directory (I use Sterm's ESC/D),
and then use ESC/S to fire up xydown. Xydown uses the current port settings in
the device descriptor, so if using an earlier version of Sterm, and you use
ESC/B, the Sterm baud rate settings are not carried forward to xydown. Also
xydown defaults to T2, if you are using a different port, you need to use the
-t option of of xydown.

Bill

There is 1 Reply.

#: 12355 S7/Telecommunications
    21-Sep-91  01:37:06
Sb: #12348-sterm 1.2 transfers
Fm: Erich Schulman 75140,3175
To: Bill Dickhaus 70325,523 (X)

I was always trying to use xydown from /t2.  Before trying to do any
downloading with sterm, I always set up a RAMdisk and then use esc-d to set the
directory to /r0.  I was calling xydown via esc-s.  I also gave the full
pathlist to xydown just to be sure it would be found right away.  As I now have
the newest sterm, I can now use xmodem directly. Actually, for most of my OS-9
downloads, I don't even use sterm.  If I can fix it so that I never have more
than 21 Grans on the disk (whether I put 1 file or 21 files on the disk), I
download under DECB using Ultimaterm then transfer the files to OS-9 via
DOSOR9.  Otherwise, I go ahead and use sterm.  When doing the downloads, I try
to fill the disk and then break up the files into 21-Gran groups for DOSOR9ing
later while I'm offline.

#: 12217 S7/Telecommunications
    12-Sep-91  21:53:38
Sb: #12093-#Sterm 1.5
Fm: Bob Palmer 74646,2156
To: Rick Ulland 70540,3305

Started out to make a reply last night at 2400 baud and something went west on
the TC70 and I lost track of what was happening.  Trying tonight at 2400 baud
the login stopped at a line  beginning with I.  Logged off and came back at 300
baud (different phone number) and stopped at exactly the same point. Repeated
CR's to no avail until I suddenly thought of the possibility that I had
generated an XOFF (why ?) and sent a control S immediately started again so now
will try at 2400 again another time to see if symptoms are the same.  Why the
TC70 would send XOFF at 300 baud with no buffer open heaven only knows Fun
stuff when tour new toy is self assembled and you have 7 thumbs. Bob P.

There is 1 Reply.

#: 12347 S7/Telecommunications
    20-Sep-91  21:01:15
Sb: #12217-#Sterm 1.5
Fm: Bill Dickhaus 70325,523
To: Bob Palmer 74646,2156 (X)

Bob,

That line beginning with "I", sounds suspiciusly like the CIS "inquire" command
sent to CIS specific terminal emulation programs. You might check your options
(GO DEFAULT) and make sure you have inquiry turned off.

You might also want to double check all the options in the device descriptor
for your modem port. In most vanilla OS9 systems I've seen, the "modem" port
comes configured more for a terminal, than for a modem, including xon/xoff.
Some newer serial drivers support xon/xoff in both directions, automatically
handling buffer overflow conditions, etc.

Bill

There are 2 Replies.

#: 12412 S7/Telecommunications
    26-Sep-91  21:13:25
Sb: #12347-Sterm 1.5
Fm: Bob Palmer 74646,2156
To: Bill Dickhaus 70325,523

the message turns out to be basically the - All Rights Reserved - line
followedby a linefeed and then I - hang.  Good suggestion about the terminal
setting - I shall go away and putter about in DEFAULT. Mind you STERM runs
perfectly with all of the other services and it can hardly be an overflow
condition when it happens at 2400 and 300 baud.  My XON XOFF speculation was
wrong - just sitting and waiting or hitting CR will eventually bring it up. 
Your INQUIRE suggestion is good - just cannot imagine how it would suddenly
have gotten turned on? Bob Palmer

#: 12413 S7/Telecommunications
    26-Sep-91  22:01:55
Sb: #12347-Sterm 1.5
Fm: Bob Palmer 74646,2156
To: Bill Dickhaus 70325,523

YOU ARE RIGHT!!! Thank you so kindly - that is precisely what my setting had
become - wait for inquire was ON.  Dad ratted !@#$!@!# Solves the mystery of
the week - month actually.  And to think that I even walked through that
section last week to change my screen size to match the tc70 (no I did not
screw it up then - it was already bad |-0 Thanks for the thought though. Bob
Palmer

#: 12230 S1/General Interest
    13-Sep-91  08:26:55
Sb: #QNX for PC
Fm: Robert Hines 76137,1362
To: all

I'm looking for general information on the QNX operating system on the PC
platform.  Any suggestions on where to look will be greatly appreciated.

Thanks

There is 1 Reply.

#: 12236 S1/General Interest
    13-Sep-91  21:13:47
Sb: #12230-QNX for PC
Fm: Kevin Darling 76703,4227
To: Robert Hines 76137,1362

That's a good question.  I looked around a bit, and couldn't find any specific
place for QNX support.

What I'd do is this: post your question in DDJFORUM, CLMFORUM and CONSULT.

I've seen, once in a while, QNX users pop up... especially in the first two.

Luck! - kevin

#: 12241 S7/Telecommunications
    14-Sep-91  00:45:29
Sb: #rz/sz options?
Fm: James Jones 76257,562
To: All

Well...I decided to go ahead and try zmodem.  The documentation for zmodem is
just as legible as the source code.  Any advice on what options, redirection,
or sacrifice of serial mice during the full moon are needed to cause rz and sz
to use a particular device to send or receive files over would be appreciated.

There is 1 Reply.

#: 12244 S7/Telecommunications
    14-Sep-91  09:18:03
Sb: #12241-#rz/sz options?
Fm: Steve Wegert 76703,4255
To: James Jones 76257,562 (X)

JJ,

The version I run is pretty quirky too ... (two quirky's in one day! Sheesh!)

What I do is fire up the sz process on the remote. Escape back to a shell here
locally, and do 'rz -m /t5 '  (no quotes, of course). (The SZ side may need a
-b option to force it into binary mode)

I've noticed it's timing sensitive, so I escape back to shell very quickly,
before the remote spits anyting back at me. I also issue the local command as
quickly as I can, else I time out.\


Now for my weird question. It just so happens with the version of sz/rz I'm
running, I can't get the -h option to work when calling the file from disk.

Load the moodule to memory, and the -h option works as expected. Ideas?

Steve

There is 1 Reply.

#: 12246 S7/Telecommunications
    14-Sep-91  10:07:55
Sb: #12244-#rz/sz options?
Fm: James Jones 76257,562
To: Steve Wegert 76703,4255 (X)

My guess would be that the author is peeking at argv[0] to decide how to
behave, a common Unix-oid behavior for programs that serve multiple (presumably
related) purposes, since there you'll see the file linked under multiple names,
and there's no module name.

I'll give your method a shot; thanks for the advice.

There is 1 Reply.

#: 12248 S7/Telecommunications
    14-Sep-91  12:03:18
Sb: #12246-#rz/sz options?
Fm: John R. Wainwright 72517,676
To: James Jones 76257,562 (X)

James, I am a LONG way from "Expert" at this, but I did get the MM/1 to compile
rz from the source in "ZMODEM.AR" in lib 12 here. (it grouched some warnings
about return() returning nothing in non-void functions, but otherwise OK).  Got
it to work by requesting zmodem download (with STERM) then calling rz with the
STERM shell option - had to redrict stdin and stdout to the port to make it
work (rz <>/t0) but it DID work.  Still playing and learning.

JohnW

There are 2 Replies.

#: 12250 S7/Telecommunications
    14-Sep-91  18:18:52
Sb: #12248-rz/sz options?
Fm: James Jones 76257,562
To: John R. Wainwright 72517,676 (X)

Thanks for the pointer!  I grabbed a copy of rz/sz stuff from, um, elsewhere,
and unfortunately I find it impossible to resist the temptation to reformat the
code, get rid of the spaghetti control flow, and so forth.  I really should
resist, of course, because I want to actually get stuff transferred someday.

#: 12262 S7/Telecommunications
    16-Sep-91  00:25:02
Sb: #12248-#rz/sz options?
Fm: Bob Palmer 74646,2156
To: John R. Wainwright 72517,676 (X)

Interesting - I have been using RZ and SZ form STERM on my TC70 in exactly the
same way.  Possible difference - I swap STERM to a shell and just type RZ to
receive.  No need to pick a device as it seems to default to /t1 (the other
serial port on a TC70.  To use SZ I type SZ followed by the -x or -y option if
I want to use xmodem or ymodem and the filename(s) to go in zmodem or ymodem. 
Seems pretty robust.  To be honest offhand I "think" I just used the .exe from
the DL here and never bothered to recompile from source but it has been a while
and I have been having so much fun compiling C programs quickly rather than
painfully as was the case on the COCO that I could be wrong.  Current struggle
is to compile the ARC.C which has some 68020 code which I do not yet
understand.



There is 1 Reply.

#: 12269 S7/Telecommunications
    16-Sep-91  21:16:20
Sb: #12262-#rz/sz options?
Fm: John R. Wainwright 72517,676
To: Bob Palmer 74646,2156 (X)

The source that I started with has device "/t3" in it.  I changed that to /t0
for the MM/1, but it puts everything on the console unless I tell it otherwise.
The source is written to compile on many different machines and is FULL of
conditional #ifdef #ifndef type stuff, I haven't figured out how to direct it
to my "/t0" port yet - I'll get it sooner or later (probably later).

There is 1 Reply.

#: 12282 S7/Telecommunications
    19-Sep-91  00:09:52
Sb: #12269-#rz/sz options?
Fm: Bob Palmer 74646,2156
To: John R. Wainwright 72517,676 (X)

the mm1 uses serial port /t0 ???  That would be rather an unusual standard. 
Not impossible but would that not be more likely to be /t? then it would go
along with /p.  Where did your source come from? Somehow I have not yet gotten
around to downloading the source from the DL here and getting version 1.5 up on
the coco III as well.  Inertia is an extremely powerful force around here.  Oh
well - I get a hard drive and you MM1 guys get graphics - standoff.

Bob Palmer

There are 2 Replies.

#: 12284 S7/Telecommunications
    19-Sep-91  04:41:31
Sb: #12282-#rz/sz options?
Fm: James Jones 76257,562
To: Bob Palmer 74646,2156 (X)

Eh?  I've had my I/O board for at least a month.  I'm looking forward to the
new drivers, but even with the current ones, I get along quite reasonably with
one of those Quantum low profile 105 Mbyte SCSI hard drives.

There is 1 Reply.

#: 12349 S7/Telecommunications
    20-Sep-91  21:01:33
Sb: #12284-#rz/sz options?
Fm: Bill Dickhaus 70325,523
To: James Jones 76257,562 (X)

You're apparently one of the _very_ lucky ones. I haven't heard one little peep
out if IMS since I got my MM/1. I was hoping they would send out the I/O boards
in the same order as the MM/1 kits, but apparently they aren't. I guess I ought
to make a little more noise in their direction, I'm ready to start some _real_
work, having just one floppy drive takes me back to OS9 LI days on my CoCo1
with one 35 track drive!

Bill

There are 2 Replies.

#: 12354 S7/Telecommunications
    20-Sep-91  22:44:06
Sb: #12349-rz/sz options?
Fm: James Jones 76257,562
To: Bill Dickhaus 70325,523 (X)

I dunno if it's *that* bad--1.2 Mbytes beats the heck out of 140 Kbytes. :-)

#: 12358 S7/Telecommunications
    21-Sep-91  09:58:47
Sb: #12349-rz/sz options?
Fm: Steve Wegert 76703,4255
To: Bill Dickhaus 70325,523 (X)

Bill,

I was talking to Paul just a couple of days ago. You may not have heard
anything from Paul ... but he did ask about you, and if you were going to
Atlanta.

Might be time to start getting vocal ...

Steve

#: 12289 S7/Telecommunications
    19-Sep-91  20:46:01
Sb: #12282-rz/sz options?
Fm: John R. Wainwright 72517,676
To: Bob Palmer 74646,2156 (X)

Yep, its /t0.  If I understand the (kinda preliminary) docs right, /t0 is the
"built in" serial port on the 68070 chip.  Until I get some more hardware, it's
the only port I have. The Rz/Sz souruce I am playing with comes from
"ZMODEM.AR" in Lib 12 here.

John Wainwright

#: 12251 S1/General Interest
    14-Sep-91  21:56:17
Sb: The Rescue
Fm: Paul Hanke 73467,403
To: All

Not having the author of The Rescue on-line any longer has prompted me to find
my own solution of completing all 25 levels. It can be done by a bit of
finagaling.
The problem seemed to be that there are too many locks or not enough keys to
complete level 23.  My solution was to repeat a level which supplies one extra
key. I re-named level1.tank to lvl1.orig and copied level5.tank to level1.tank.
(It randomly leaves you with an extra key or not). Anyhow, with 3 keys I was
able to complete level 23 but could not advance to L24, there being no 'escape
hatch'  so I must conclude there are 2 bugs to L23.
The practical solution is to copy any other favorite level to
level23.tank (if it doesn't also set you up with too few keys) and then you
should be able to go a full 25 rounds.  (The game then repeats to level 1,
etc.)    -ph- 

#: 12252 S10/OS9/6809 (CoCo)
    15-Sep-91  01:14:16
Sb: #11912-#basic09
Fm: David Breeding 72330,2051
To: Paul Hanke 73467,403 (X)

Saw your questions about gs.stype.  I wrote a program  (subroutine) for use
with b-09, similar to gfx2.  It's name is "gfx3.ar". I didn't upload it myself,
but seems like I saw it somewhere in the library.  At least it had the same
name.  Grab it and give it a look-see.  If you can't it, you might leave me a
msg or as I don't get online too often, you may give me a call at 502-866-6185.
I'm getting such lousy reception that I din't know if it was right or not.  The
# is 50232 try again- 502-866-6185.  I'm usually available between 8pm and 10pm
central time.
  Good luck.  (Not sure what this msg will look like, with all my garbage.

There is 1 Reply.

#: 12255 S10/OS9/6809 (CoCo)
    15-Sep-91  17:49:24
Sb: #12252-basic09
Fm: Paul Hanke 73467,403
To: David Breeding 72330,2051

Just grabbed gfx3.ar from the coco6809 library and will peek inside sometime
later this evening.  Thanx.    -ph- 

#: 12260 S9/Utilities
    16-Sep-91  00:19:17
Sb: A New Disk Module?
Fm: Erich Schulman 75140,3175
To: ALL

As I still have only one physical disk drive, I have to frequently type chd
/d0; chx /d0/cmds.  Since there seems to be no way that I can define ctrl-1 or
some other thing as a keyboard macro, is there any downloadable module that
will allow me to just type newdisk (or nd), and preferably a module that will
not rely on RunB.  I would load it upon startup or maybe even merge it into
/d0/cmds/shell.  These alternatives would be easier and more accurate (for
typing correctly the first time) that what I have to do now.  BTW, the reason I
want to avoid having to rely on RunB is because even with 512K I still have to
RAMcram a lot.  Mostly because of my 256K RAMdisk that I (almost) can't do
without.

#: 12261 S3/Languages
    16-Sep-91  00:22:10
Sb: #Basic-09 + RunB vs. C
Fm: Erich Schulman 75140,3175
To: ALL

Why is it that compiled/PACKed Basic09 programs rely on RunB for execution but
compiled C and Pascal programs seem to be able to stand on their own? Is there
any way to "reduce" Basic-09 I-code to even closer to true assembler-generated
code?

There is 1 Reply.

#: 12263 S3/Languages
    16-Sep-91  02:49:06
Sb: #12261-#Basic-09 + RunB vs. C
Fm: Kevin Darling 76703,4227
To: Erich Schulman 75140,3175 (X)

Packed basic09 programs aren't compiled, you see... but crunched down to a
tokenized form (more or less).  To save space on systems, RunB is used to
execute the info.

68K systems are the same, and even go further... the math and I/O functions of
C and other compiled languages are usually handled by shared modules. All of
this, of course, helps save room.

I'm not sure if any company has ever done a basic09-compatible compiler, altho
I believe there have been other such Basic(s).  Anyone know for sure?

There is 1 Reply.

#: 12265 S3/Languages
    16-Sep-91  03:16:42
Sb: #12263-#Basic-09 + RunB vs. C
Fm: James Jones 76257,562
To: Kevin Darling 76703,4227 (X)

Shudder--you said the T-word (tokenized).  I-code is like Pascal P-code, in a
way; it's code for an abstract machine.  If one really wanted to, one could
create a chip that ran it directly, as someone did for P-code.

(Of course, one could claim that the tokenized form of generic Microsoft BASIC
is code for an abstract machine, too, but the transformation done to get from
what one types to that form is pretty trivial, and the abstract machine would
be quite ugly and inefficient.)

There is 1 Reply.

#: 12266 S3/Languages
    16-Sep-91  20:53:42
Sb: #12265-#Basic-09 + RunB vs. C
Fm: SCOTT HOWELL 70270,641
To: James Jones 76257,562 (X)

You have mentioned a term frequenlty used but rarely defined. What is an
abstract machine anyway!!

There is 1 Reply.

#: 12273 S3/Languages
    17-Sep-91  06:50:58
Sb: #12266-#Basic-09 + RunB vs. C
Fm: James Jones 76257,562
To: SCOTT HOWELL 70270,641 (X)

An abstract or virtual machine is one that doesn't exist on silicon (or gallium
arsenide if you have the bucks, or whatever--any physical implementation).

Suppose nobody had ever actually made a 6809.  One could still write an
assembler for it, or compilers that generate 6809 instructions, but to run any
of the resulting programs would require an interpreter (maybe emulator is the
right term).

There is 1 Reply.

#: 12288 S3/Languages
    19-Sep-91  13:59:49
Sb: #12273-Basic-09 + RunB vs. C
Fm: SCOTT HOWELL 70270,641
To: James Jones 76257,562 (X)

good explanation,thanks.
exit

#: 12267 S7/Telecommunications
    16-Sep-91  21:01:39
Sb: #12073-#Aterm for the TC70 ??
Fm: Colin J. Smith 73777,1360
To: Jim Sutemeier 70673,1754 (X)

I am using it now on my MM/1.  The only thing I had to change (I think) was the
device driver line in Aterm.ctl.

This is what my Aterm.ctl looks like:

                          <<<  ATerm Control File  >>>

   Descriptions     Sequence code       Informations related to the codes
 ================  ===============  ===========================================
 Clear Screen      $021B45          For Vt-52 Video
 Cursor On         $021B65          For Vt-52 Video
 Cursor Off        $021B66          For Vt-52 Video
 Reverse On        $021B70          For Vt-52 Video
 Reverse Off       $021B71          For Vt-52 Video
 Printer Init.     $021B15          (CR=CR) : For TANDY DMP-105 printer
 Modem prefix      @04ATDT          "ATDT" Command Prefix.  (Hayes Compatible)
 Modem suffix      $010D            "[CR]"  "   "  Suffix.    " "    "    "
 Device Driver     @05sc68070       Device driver identification. (Ser. Path)
 Pipe Buffer Size  $0400004000      Internal representation of $4000 (32 Bits)
 Printer Processor @10/R0/ATerm.Print&  Name of the script file to Print
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "
 "   "             $00               "  "  "  "   "

etc.

Hope this helps!

  --Colin

There is 1 Reply.

#: 12408 S7/Telecommunications
    26-Sep-91  09:50:49
Sb: #12267-Aterm for the TC70 ??
Fm: Jim Sutemeier 70673,1754
To: Colin J. Smith 73777,1360 (X)

Thanks for your report....think I know now what I dood wrong.... think I named
the device descriptor /t1    (dumb.....I know.... <g>)  Will try out what
you've reported....

jim



#: 12268 S12/OS9/68000 (OSK)
    16-Sep-91  21:05:42
Sb: #Good OSK terminal prog
Fm: Colin J. Smith 73777,1360
To: All

Top on my OSK (MM/1) wish list:

A TERMINAL PROGRAM THAT SUPPORTS ANSI GRAPHICS!

Does somebody have one in the works?  I would almost kill for one.

  --Colin

There is 1 Reply.

#: 12272 S12/OS9/68000 (OSK)
    17-Sep-91  06:44:54
Sb: #12268-Good OSK terminal prog
Fm: James Jones 76257,562
To: Colin J. Smith 73777,1360 (X)

Well...I sat down one day and wrote the outline of the FSM that one would need
to translate most of the PClonish approximation of X3.67-197? to the
corresponding stuff for the CoCo or MM/1...one would have to finesse some
things (the MM/1 won't do blinking, but the CoCo will, and if one switched to
PClone mode, one might have to do something like move the cursor to a
particular position in case there is an immediate request to save the cursor
position for later restoration without first doing something that will put it
in a known position).  What I did was the obvious part, though, and it would
take rather more work to turn it into something usable.  Any volunteers?

#: 12274 S7/Telecommunications
    17-Sep-91  19:04:47
Sb: UUCP nodes
Fm: Hugo Bueno 71211,3662
To: ALL

Hello all.  I recently lost my UUCP feed from my friend Bob Billson. I'm now
suffering Internet Coco list withdrawal.  I would like to find myself a new
feed.  Unfortunately, I don't know how. Would it be possible for any UUCP'ers
out there to find information on UUCP sites close to me?

I assume the following is needed:

   State, City: Fanwood, NJ
   Zip:         07023
   Area Code:   First preference-908, second preference-201

Any help is greatly appreciated.

Hugo



#: 12278 S15/Hot Topics
    18-Sep-91  19:12:55
Sb: Mac/OS-9
Fm: sam 70731,3703
To: hot topics

Check out OS-9/680xx for the Macintosh.  A full implementation of OS-9/680xx
built on the Macintosh hardware platform.  All Macs are supported from the + to
the IIfx, including the Mac portable.  Multiple shell windows and mac toolbox
support from Mac/OS-9 programs.  Multifinder/System 6/System 7 compatible.

If you are looking for a portable OS-9 computer, or want to do your OS-9
development on a Mac (using Mac editors and other tools,) consider OS-9 for the
Macintosh.

Ultrascience Wheeling, IL 708.808.9060

#: 12281 S10/OS9/6809 (CoCo)
    18-Sep-91  21:30:39
Sb: #Easy HD Backups
Fm: Art Doyle 71565,262
To: Kevin Darling

Whew!

Finally managed to transfer that old Tandy HD system onto the eliminator. After
several close calls, I ended up losing only one file. Had to use 40trk ds
floppies to transfer - lots of em. My doggone arm hurts.

Now what are the chances that we'll EVER see a resonably priced, easy to use
backup system?

Opinions?

Art

P.S. Is this project also on the back burner like my CD ROM request [grin]?

There is 1 Reply.

#: 12283 S10/OS9/6809 (CoCo)
    19-Sep-91  02:23:17
Sb: #12281-Easy HD Backups
Fm: Kevin Darling 76703,4227
To: Art Doyle 71565,262 (X)

Hmmm.  I think a couple of people have tape backup units on their coco now; but
not sold commercially (or maybe they are? dunno).  I'm pretty sure that Chris
Burke and/or Roger Krupski had one set up for themselves.

Mostly, I'd guess that people are waiting for the SCSI tape units to become
much cheaper.  Got me... I still use dsave :-)

#: 12286 S1/General Interest
    19-Sep-91  11:40:16
Sb: #RSDOS TO OS9
Fm: Paul Hanke 73467,403
To: anyone

  Several people have asked about transferring files from rsdos to os9 using
the utility DOSOR9.BAS,  with the main concern being the size of file
allowable.  As written, that seemed to be about 32k or 64k bytes.   I suggested
that a way to increase that to just under
100 k bytes is to add the following line:

2326 IF NN>32767 THEN NN=NN-32768:GOTO 2326  'PGH 09/09/90

  Now I'm wondering why there is still an upper limit to the transfer.  If the
size is over 100k or so, OS9 replies with a  'file too fragmented' error.  This
appears to be due to OS9's inability to keep track of where the file is if
OS9's f.a.t. needs more than 1 sector (I'm guessing mostly at this).  Since OS9
prefers to have files written to contiguous sectors, a lengthy RSDOS conversion
might appear to be fragmented even tho to RSDOS it is not, ie:
  RSDOS can use granules 32 to 68 consecutively; so far so good.  If a file
needs more room, then the order becomes 30-31, 28-29, 26-27,  etc.  instead of
0 - 31.  All this presumably because of the directory track being #17, right in
the middle of the disk.  So my reasoning is that the second half of a very long
rsdos file might appear too fragmented to OS9.  If this is the case, perhpas a
patch to rsdos to store files from granule 0 - 31 would allow DOSOR9 to
transfer a file up to 68 granules long since OS9 wouldn't have to keep track of
many non-contiguous sectors/granules.
  But I don't know that much about how OS9 keeps track of files.   
Clarification please?      -ph- 

There are 2 Replies.

#: 12287 S1/General Interest
    19-Sep-91  12:40:07
Sb: #12286-#RSDOS TO OS9
Fm: Erich Schulman 75140,3175
To: Paul Hanke 73467,403 (X)

A full 68 Granules cannot be DOSOR9'ed since you need to take Track 0 out of
service for OS-9's use.  I don't believe a simple patch will fix the problems
you described but I suppose one could _carefully_ use DSKI$ and DSKO$ to
physically move the files around to a more "acceptable" form and then to
manaully update DECB's FAT.  Despite the "fix" you described, I have never
successfully used DOSOR9 with more than 21 Granules used per disk.  I have
already decided to just get GCS File Transfer Utilities and complementary
SDISK-3 so I can handle any size DECB file (up to 68 Grans anyway) as well as
MS-DOS disks.  Not to mention having something better than trscopy to transfer
OS-9--->DECB.  For a file that's not too big, I've found the best way to do
that is to upload it to my PER area on sterm and download it on Ultimaterm. 
(Or sometimes, just redownload from the Lib or the BBS).  Trscopy will usually
manage to huff and puff its way through transfers to OS-9 but I still have a
lot of trouble with making it do the opposite.

There are 2 Replies.

#: 12291 S1/General Interest
    19-Sep-91  21:57:55
Sb: #12287-#RSDOS TO OS9
Fm: Paul Hanke 73467,403
To: Erich Schulman 75140,3175 (X)

I guess you're right about patching rsdos; forgot about track 0 for OS9.  But
that might not otherwise been a solution either; dunno.

As for dosor9, you should have the version updated for files larger than 32k. 
This should work for files up to about 62-64k.  My fix works only on this one. 
Check your version for the following lines:

-------
300 GOTO 9900
----
------
2300 ' binary string output
2320 N$="":FOR I=1 TO NS
2324 NN=NUM
2325 IF NUM>32767 THEN NN=NUM-32768  'fix for files >32k
2326 IF NN>32767 THEN NN=NN=32768-GOTO2326 'fix for >64k PGH 09/09/90 2330
N$=CHR$(NN AND 255)+N$
2340 NUM=INT(NUM/256)
2350 NEXT I:RETURN
9900 PCLEAR 1:CLS:CLEAR 2000:GOTO 500


  If your version matches this version and it still doesn't work,  make sure
your large file is the only one copied onto a newly formatted disk and try
again.  If it still doesn't work, I can send you a complete copy of mine for
comparison.  You are the first person to say whether  my version has worked or
not, other than myself,  altho some have said to have tried it; so I have no
new stats to recite.
  I've just converted a file of 44 grans using this modified dosor9!
  -ph-  

There are 2 Replies.

#: 12294 S1/General Interest
    19-Sep-91  23:27:26
Sb: #12291-#RSDOS TO OS9
Fm: Erich Schulman 75140,3175
To: Paul Hanke 73467,403 (X)

My version does have the lines you listed.  I'll have to go back and try
something with a large file as the only one on a disk.

There is 1 Reply.

#: 12310 S1/General Interest
    20-Sep-91  08:27:24
Sb: #12294-RSDOS TO OS9
Fm: Paul Hanke 73467,403
To: Erich Schulman 75140,3175 (X)

You might check out the suggestions offered by others on this thread,   namely
using PCDOS & RSDOS to convert your files.  I did some checking with an decb
program called ZAPZ.BAS-  this allows you to look at individual sectors
including those on an OS9 disk (yep). What was most interesting was the way
DOSOR9's f.a.t. is constructed- not at all similar to the way OS9 does it in a
pure OS9 environment. (I don't even understand why it works at all.)

If you check lines 807, 1190, & 1192  you will see that DOSOR9 imposes its own
upper limit on file sizes due to the maximum allowable string length of 250
char.  I don't know enuf about OS9
and directories to muddle out of this one.  I've been rather delinqent in doing
OS9 homework; my policy has been to find out only enough to get by with the
current problem.  As it stands, I too have found other solutions to transfer
larger files and even used my own upgrade only until a file >100k came along. 
Now if someone could modify DOSOR9 to produce a 'pure OS9' type directory......
-ph- 

#: 12307 S1/General Interest
    20-Sep-91  07:49:01
Sb: #12291-RSDOS TO OS9
Fm: Steve Wegert 76703,4255
To: Paul Hanke 73467,403 (X)

Paul,

You may wish to investigate a suite of files called RSDOS.AR that handles
reading and writing RSDOS files from inside OS9. It's what I use and havn't run
across any problems. Should be in the libraries here.

Steve

#: 12352 S1/General Interest
    20-Sep-91  22:11:26
Sb: #12287-#RSDOS TO OS9
Fm: Paul Hanke 73467,403
To: Erich Schulman 75140,3175 (X)

I've used sterm to download files to a ramdisk directly.  This will work even
tho the proper speed-up patches to OS9 modules haven't been done. I used the
send ahead protocol with a 2400 baud modem resulting in a net baud rate of
1400+  which I understand is rather slow compared to that gained by adding the
proper patches (irq hack, too,  probably.)  You also lose proper screen display
somewhat by not upgrading; but it works.  Change Sterm's data directory to /r0.
-ph- 

There is 1 Reply.

#: 12356 S1/General Interest
    21-Sep-91  01:47:13
Sb: #12352-RSDOS TO OS9
Fm: Erich Schulman 75140,3175
To: Paul Hanke 73467,403 (X)

That's what I do.  I used to have sterm (1.2) download directly to floppy disk,
but back then I was using sterm only on the DC Modem Pak.  As you might
imagine, the speed of file transfers was not appreciably reduced. I still, as a
rule, make my downloads for both DECB and OS-9 under DECB. I use a 2400bps
modem under DECB and it works just fine.  But I once before started a thread
about having probs under OS-9 which were diagnosed as need of IRQ hack.  I
found back then that I lost only a few characters here and there on the display
at 1200 baud tho file transfers appeared completely reliable.  At 2400, I had a
lot of character loss but downloads did OK.  What I did for that was take
careful note of the Lib section and exact filename.  Since I've been on CIS so
many times, I know my way around well enough that I could lose a lot of
characters and still know where I was.  So what I'd do is log on then wait for
my modem's RD light to go out.  I'd GO OS9 and wait for some semblance of
"Forum !" and a dark RD light, and so on til I was ready to log off.  The
biggest problem I had was keeping track of my time since I could not depend on
a usable

Connect time = h:mm message after logoff.

#: 12292 S1/General Interest
    19-Sep-91  22:23:50
Sb: #12286-#RSDOS TO OS9
Fm: Ian Hodgson 72177,1762
To: Paul Hanke 73467,403 (X)

     I'm puzzled. For years now I've watched people describe their troubles
using DOSOR9. I used to use it too, with all the problems of maximum file size,
oddly set up disks (track 0 unused; my files ALWAYS seemed to end up on track
zero), too much fragmentation, and so on.

     The reason I'm puzzled is that for a long time now I've been using a MUCH
nicer program, RSDOS (downloaded from RSDOS.AR). RSDOS (and its sister program
PCDOS), operating under OS9, allows you to read DECB directories, read or write
DECB files (writing allows a bunch of switches for file type, etc.) and do
deletes from DECB disks. It doesn't seem to have an upper limit to file size,
nor does it care about track 0 on the DECB disk.

     So why do I seem to be the only one using it? I'm sure it came from one of
the libraries here, so take a look. Oh, it requires either SDISK or the patched
CC3Disk to operate. If you try it I suspect you'll relegate DOSOR9 to a
suitable archive disk.

There is 1 Reply.

#: 12308 S1/General Interest
    20-Sep-91  07:50:54
Sb: #12292-RSDOS TO OS9
Fm: Steve Wegert 76703,4255
To: Ian Hodgson 72177,1762 (X)

Ian ... you're not alone !  :-)

I think I used DOSOR9 to nabb my first OS9 terminal program. Then it was RSDOS
from then on. It's a dandy.

Steve

#: 12290 S1/General Interest
    19-Sep-91  21:01:02
Sb: #In Search of Stuff
Fm: Jay Truesdale 72176,3565
To: all

I am looking for a couple of items and I'm hoping that someone here can help me
find:

1) A can of "Diet Jolt."  I read an article a while back that said they were
going to come out with this.  Regular Jolt I can find, but I need some Diet
Jolt for a project I'm working on.

2) The manufacturer of the joysticks used in arcade game machines.  I'd like to
replace my defective joystick mechanism.

Thanks in advance for any help you can provide!

-J

There is 1 Reply.

#: 12300 S1/General Interest
    20-Sep-91  01:17:54
Sb: #12290-In Search of Stuff
Fm: Kevin Darling 76703,4227
To: Jay Truesdale 72176,3565 (X)

GRIN.  Sorry, I drink the Southern programmer soda:  Dr Pepper! :-)


Which arcade game; which kind of joystick?  (I wonder if one of the GAMExx
forums would know?)

#: 12293 S1/General Interest
    19-Sep-91  22:34:22
Sb: #OS/2
Fm: Art Doyle 71565,262
To:  76476,464 (X)

Hi Paul,

What do you think of the new OS/2 ? Does it suffer from the meladies you
described last year?

Art



There is 1 Reply.

#: 12359 S1/General Interest
    21-Sep-91  11:22:06
Sb: #12293-#OS/2
Fm: Jim Peasley 72726,1153
To: Art Doyle 71565,262 (X)

Art;

  Saw your note on OS/2.  Assuming you're talking about the V.2.0 release
(which is in Beta test and due to be released RSN), yep they've managed to get
almost all the 'bugs' out and make it much more robust.   I've seen video of
demonstrations put on by the 'blue Ninja' (an IBM VP) that blow most people's
socks off... kinda ho-hum for us OS-9 types tho, as we've been doing this stuff
for years on a $200 machine!
  The interface is very like Windows 3.0, but at this point not quite as
snazzy.  Windows and DOS apps run unmodified in the DOS box(es) and programs
written for the 32 bit processor *really* fly!  Looks like this may become the
next 'standard' and finally replace DOS.  Time will tell. The BIG difference in
this version is that the developers have been using conferencing and a large
base of beta testers to get the final release 'just right' -- something
radically different for Big Blue.
  For more info, go IBMOS2 and check out the forum.

..Jim



There is 1 Reply.

#: 12374 S1/General Interest
    22-Sep-91  14:48:51
Sb: #12359-OS/2
Fm: Art Doyle 71565,262
To: Jim Peasley 72726,1153 (X)

Thanks Jim !

#: 12295 S7/Telecommunications
    19-Sep-91  23:33:13
Sb: #sterm 1.2--->1.
Fm: Erich Schulman 75140,3175
To:  76703,4255 (X)

I have downloaded the complete sterm 1.5 archive, extracted it, and it all
works.  I've already done about 450K of Xmodem with it.  Only prob that I did
have is when I list sterm.manual.  There appear to be formfeed characters in it
that prevented my reading a few parts.  But obviously not enough to keep me
from using the program.

There is 1 Reply.

#: 12306 S7/Telecommunications
    20-Sep-91  07:45:16
Sb: #12295-#sterm 1.2--->1.
Fm: Steve Wegert 76703,4255
To: Erich Schulman 75140,3175 (X)

Erich,

I'm betting the doc file has been formated with mroff for a nice looking
document when _printed_ .

Grab one of the MORE utilities that can be found in the libraries here to help
you with managing online documentation. The version I use allows for selective
positing within the file as well as backing up.

Glad you're up with the current version!

Steve

There is 1 Reply.

#: 12316 S7/Telecommunications
    20-Sep-91  13:51:19
Sb: #12306-sterm 1.2--->1.
Fm: Erich Schulman 75140,3175
To: Steve Wegert 76703,4255 (X)

Since I have Level II Tools, I do have a Browse which would probably have done
just as well as MORE.  I usually use list with a paged display since I don't
have to load anything more into memory.  Though I have 512K total, I've only
got 392K free on startup, and a big RAMdisk (like 256K) really pares that down.
And then with Wcopy, Wdel, and Ar also in RAM....  I may print the sterm manual
some time, but I rightly suspected that just reading it once on the screen
would be enough for me to get up and running with it.  I've now used a total of
roughly ten to twelve term programs so not much of anything is new to me
anymore.

#: 12296 S9/Utilities
    19-Sep-91  23:37:06
Sb: #Extracting Big ar file
Fm: Erich Schulman 75140,3175
To: ALL

Yesterday I downloaded a 170K ar file.  There is not enough space on a 360K
disk to hold the ar file and to extract it.  I thought that I could copy the ar
to a RAMdisk and extract to a physical disk.  I thought that appending >/d0
would redirect the extraction to a newly formatted disk which I had in /d0. 
Instead I got a File Already Exists error.  Would Tee be able to handle the
redirection?  Or is there some other way that I can extract this archive?

There is 1 Reply.

#: 12301 S9/Utilities
    20-Sep-91  01:19:45
Sb: #12296-#Extracting Big ar file
Fm: Kevin Darling 76703,4227
To: Erich Schulman 75140,3175 (X)

Erich,

To extract a file from your ramdisk to d0, first "chd /d0" so that the output
will end up there.  Then "ar -x /r0/file.ar" so that Ar extracts from the
archived file on ramdisk.

Ar always extracts to the current directory.

best - kev

There are 2 Replies.

#: 12315 S9/Utilities
    20-Sep-91  13:43:50
Sb: #12301-Extracting Big ar file
Fm: Erich Schulman 75140,3175
To: Kevin Darling 76703,4227 (X)

Now why didn't I think of that (g).  Thanks.

#: 12342 S9/Utilities
    20-Sep-91  18:23:45
Sb: #12301-Extracting Big ar file
Fm: Lee Veal 74726,1752
To: Kevin Darling 76703,4227 (X)

If there's still not enough room on the /d0 drive, could Erich also just
de-ARchive using specific files from the ARchive file.

 ar -x /r0/file.ar file1.doc file1.bin ... etc?

Having a hard drive has spoiled me on how to solve problems in a floppy-based
system.

I had somebody ask me some questions about Level 1 the other day, and drew a
blank.

Lee

#: 12297 S10/OS9/6809 (CoCo)
    19-Sep-91  23:40:28
Sb: #Using Nil devices
Fm: Erich Schulman 75140,3175
To: ALL

I have never found any documentation for the Nil drivers in Tandy's OS-9
Development System package.  I have always wondered exactly what they are for,
and even more so after seeing them in Rainbow's sample boot list. I once tried
redirecting some text to Nil but got a Media Full error after a few seconds. 
So what makes these devices useful, and how might one put them to use?

There is 1 Reply.

#: 12302 S10/OS9/6809 (CoCo)
    20-Sep-91  01:23:10
Sb: #12297-Using Nil devices
Fm: Kevin Darling 76703,4227
To: Erich Schulman 75140,3175 (X)

Sounds like you simply did a "list file >nil" which created a file.

Make sure you put the "/" in front: "list file >/nil"... which should dump the
output into the great bit bucket in the sky.

It's handy from a script file at times: when you don't want to see error
messages or standard output names, etc.

#: 12298 S7/Telecommunications
    19-Sep-91  23:45:16
Sb: #GO FILE
Fm: JOERG SATTLER 74016,631
To: ALL

I cant tell you how much I would like to see a File Finder (OS9FF) similar to
the  IBMFF or AMAIGAFF sections. Shure would make life somewhat easier at
times. I am looking for the (optional) GO file module for UUCP.                
Joerg

There are 2 Replies.

#: 12299 S7/Telecommunications
    20-Sep-91  00:04:38
Sb: #12298-#GO FILE
Fm: Wayne Day 76703,376
To: JOERG SATTLER 74016,631 (X)

Joerg,

It would be nice, but I don't think the OS-9 activity on CompuServe would be
enough to support the resources needed to set up the FF program.

Wayne

There is 1 Reply.

#: 12351 S7/Telecommunications
    20-Sep-91  21:23:03
Sb: #12299-#GO FILE
Fm: John R. Wainwright 72517,676
To: Wayne Day 76703,376 (X)

Hey Wayne!, How about that "browse all libs" thingy I saw in the new stuff
listing when I logged on the other day - will it be here (is it already here?)

JohnW

There is 1 Reply.

#: 12368 S7/Telecommunications
    22-Sep-91  01:48:57
Sb: #12351-GO FILE
Fm: Wayne Day 76703,376
To: John R. Wainwright 72517,676 (X)

John,

It's in the final testing stage, now, and should be available in all of the
forums when it's release for general useage.

Wayne

#: 12309 S7/Telecommunications
    20-Sep-91  07:58:27
Sb: #12298-#GO FILE
Fm: Steve Wegert 76703,4255
To: JOERG SATTLER 74016,631 (X)

Joerg,

As Wayne mentioned, I doubt we'll see anything like the File Finder utilities,
however, if you caught mention of the 'Across Library Searching' feature
announced in this weeks System Wide What's NEW announcement, help is on the
way.

This new version of the library software will allow users  to span all
libraries within a specific forum while browsing for files.

It's up and running in a few forums now (see the list in the WN announcement).
In fact, you can play with it for free in the PRACTICE forum and get a flavor
while we wait for it to migrate here.


Soon .... I hope!

Steve

There is 1 Reply.

#: 12317 S7/Telecommunications
    20-Sep-91  14:00:27
Sb: #12309-#GO FILE
Fm: Erich Schulman 75140,3175
To: Steve Wegert 76703,4255 (X)

I'd agree that OS-9 activity is not sufficient for a File Finder, but.... Why
just OS-9?  Perhaps combining this forum, the CoCo Forum, TRS80PRO, and maybe
some other relevant forum(s) would be enough to justify a file finder.  Or at
least we could do what IBMAPP also does.  This forum and the CoCo Forum do a
comprehensive update of their catalog files.  Then each forum can put them in
their respective sections.  And a combined catalog file can be placed in one
section.  The file would probably need to be TC3'ed or Ar'ed (as appropriate). 
I prefer to do most of my looking around offline anyway.

There is 1 Reply.

#: 12357 S7/Telecommunications
    21-Sep-91  09:41:38
Sb: #12317-GO FILE
Fm: Steve Wegert 76703,4255
To: Erich Schulman 75140,3175 (X)


Good point, Erich ....

Perhaps it's time to run a new series of complete catalogs for all the
libraries.

Steve

#: 12303 S10/OS9/6809 (CoCo)
    20-Sep-91  03:37:33
Sb: #A New Copy/Move utility
Fm: George Hendrickson 71071,2003
To: all

Anyone have a new copy/move utility that auto senses if the file is being
copied/moved to another dir/drive? We OS9 users need such a utility! Maybe
something written in C or ML would be nice! <grin> Anyone good at writing such
a thing? Any volunteers? <grin> I'd write one but I don't have the C compiler
and I'm unfamiliar with OS9 ML.. HELP!

There is 1 Reply.

#: 12314 S10/OS9/6809 (CoCo)
    20-Sep-91  12:59:04
Sb: #12303-#A New Copy/Move utility
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)

George -

Have you checked DL9 or DL10 for 'mv'? It appears to do all that you're looking
for. Also, there's a clone of Unix's 'cp' command.

Pete

There are 2 Replies.

#: 12369 S10/OS9/6809 (CoCo)
    22-Sep-91  03:25:21
Sb: #12314-A New Copy/Move utility
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)

I haven't seen 'mv'...I'll look for it and try it out..I use 'cp' quite a bit.
It is very useful!



#: 12370 S10/OS9/6809 (CoCo)
    22-Sep-91  03:39:36
Sb: #12314-#A New Copy/Move utility
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)

I looked for 'mv' but couldn't find it in DL9 or DL10. Any ideas where it could
be?  Thanks...



There are 3 Replies.

#: 12371 S10/OS9/6809 (CoCo)
    22-Sep-91  10:03:51
Sb: #12370-A New Copy/Move utility
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)

George -

I believe it was in the UGLIB area..... let me scan..

Pete

#: 12372 S10/OS9/6809 (CoCo)
    22-Sep-91  10:07:15
Sb: #12370-#A New Copy/Move utility
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)

George -

In the file PURGED.TXT, there's a file listed as MV09.AR... I'll wager that's
it. Ask Mike Ward [76703,2013] to recover it for you.  Also, it appears that
there's a 68k version as well... may include source if you to move it to a
6809. Go to DL5 and type: BRO MV*

Pete

There is 1 Reply.

#: 12389 S10/OS9/6809 (CoCo)
    24-Sep-91  02:47:33
Sb: #12372-A New Copy/Move utility
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)

Thanks! I'll ask Mike for the file....

#: 12373 S10/OS9/6809 (CoCo)
    22-Sep-91  12:57:13
Sb: #12370-#A New Copy/Move utility
Fm: Mike Ward 76703,2013
To: George Hendrickson 71071,2003 (X)

George, I just uploaded MV09.AR to Lib 5. The 68k version is MV68K.AR in the
same library.

There is 1 Reply.

#: 12390 S10/OS9/6809 (CoCo)
    24-Sep-91  02:49:30
Sb: #12373-#A New Copy/Move utility
Fm: George Hendrickson 71071,2003
To: Mike Ward 76703,2013 (X)

BOY! That was fast!! I just left Pete Lyall a message saying that I was going
to leave you a message and next message I read was from
 you! Now that's what I call service! Thanks! I'll download the files...

There is 1 Reply.

#: 12391 S10/OS9/6809 (CoCo)
    24-Sep-91  05:38:32
Sb: #12390-A New Copy/Move utility
Fm: Mike Ward 76703,2013
To: George Hendrickson 71071,2003

Anytime George... I hope the files help you out.




#: 12304 S4/MIDI and Music
    20-Sep-91  03:44:50
Sb: #11991-#Bad Download
Fm: George Hendrickson 71071,2003
To: Jim Sutemeier 70673,1754 (X)

I've been wondering about the TC9. How fast does it run? Will it run RSDOS
stuff faster than 2mhz and how fast will it run under OS9?

Thanks!

There is 1 Reply.

#: 12409 S4/MIDI and Music
    26-Sep-91  09:57:53
Sb: #12304-#Bad Download
Fm: Jim Sutemeier 70673,1754
To: George Hendrickson 71071,2003

The TC9 will run the same as the CoCo, George, as it has the 6809 as the
processor.

However, you CAN add a "Tiger" card to it, and, with the correct drivers, the
68000 chip in the Tiger card will act as a co-processor handling memory
management for the TC9.

Should increase speed of most programs run (Frank estimates <conservatively>
that the TC9 will increase spped from 2 to 3 times the stock 6809 chip.

(Aside from the DOS command, I haven't used RSDOS in almost 10 years now.... so
am not totally familiar with how RSDOS will be handled by the TC9, but RSDOS
programs will run AT LEAST as fast as they do now - same processor)

jim



There is 1 Reply.

#: 12414 S4/MIDI and Music
    26-Sep-91  23:21:08
Sb: #12409-#Bad Download
Fm: James Jones 76257,562
To: Jim Sutemeier 70673,1754 (X)

Any word on when the correct drivers are expected?

There is 1 Reply.

#: 12423 S4/MIDI and Music
    27-Sep-91  12:51:54
Sb: #12414-Bad Download
Fm: Jim Sutemeier 70673,1754
To: James Jones 76257,562 (X)

Haven't talked to Frank recently about the drivers, Jim.... will try to find
out and let you know.

jim Sutemeier



#: 12324 S4/MIDI and Music
    20-Sep-91  16:05:00
Sb: #11991-#Bad Download
Fm: Paul K. Ward 73477,2004
To: Jim Sutemeier 70673,1754 (X)

Jim,

I see your point on the CoCo4 being 6809 system -- nothing else will do,
according to you! Interesting!

Of course, by that same argument, only 8086 systems are PCs. I think you also
have to consider the element of "family resemblance". Hence, an 80386 UNIX
system is not as much a PC as an 80386 MS-DOS system is, as most people
understand "PC". Its the software that makes the 80386 MS-DOS system in the PC
"family".

Hence, a 6809 system would be a CoCo4 if it is in the "family" of the Color
Computer -- but a 68000 system would ALSO be a CoCo of sorts (CoCo 5?) if (and
only if) its software kept its look, feel, and user profile.

Best,

Paul

PS Take care!



There is 1 Reply.

#: 12410 S4/MIDI and Music
    26-Sep-91  10:04:38
Sb: #12324-#Bad Download
Fm: Jim Sutemeier 70673,1754
To: Paul K. Ward 73477,2004 (X)

Paul....I do see and understand your point.

But the original PC's came out with one chip, and then IBM moved on to other
chips as they went along, for more speed, etc., etc.

Tandy, however, started with the 6809, and through two further enhanced
production models, STAYED with the 6809 processor.

This is why I stipulate that the only true CoCo4 is the Tomcat9 - the TC9 STAYS
WITH the 6809 processor, following Tandy's lead in using (and continuing to
use) the 6809.

Most/all existing software CoCo owners use (both RSDOS and OS9 LII) will run on
the Tomcat9.

This is why I state that the TC9 is the CoCo4.

(Just FYI, though, I moved on to a Tomcat70....I don't even consider it close
to a CoCo in any way - sure, it runs OS9....but a much more powerful OS9 than
I'm used to.)

jim



There is 1 Reply.

#: 12419 S4/MIDI and Music
    27-Sep-91  08:09:05
Sb: #12410-#Bad Download
Fm: Steve Wegert 76703,4255
To: Jim Sutemeier 70673,1754 (X)

Jim,

I'm curious ... how's the TC70 performing?

A friend of my recently took delivery of one and has had a number of problems
he's currently trying to get resolved with Frank.

Right at the top of the list is frequent system crashes. He's accustomed to
having a very stable system up for hundereds of hours. Lately, with the TC70
he's lucky to see anything older than 38 hours.

Have you been experiencing anything similar?

How about craftsmanship? Any problems with the construction of the system? The
same system has about 10 serial ports, with only 3 working. Trouble shooting
seems to indicate the actual board is functional, but the cabling to the 9-pins
is suspect on the non-working ports.

How about your reset switch? Does it work?  His doesn't.

At this point he's one frustrated pup, while I continue to say, 'isolated
instance'.

Howaboutit?

Steve

There is 1 Reply.

#: 12424 S4/MIDI and Music
    27-Sep-91  12:56:17
Sb: #12419-#Bad Download
Fm: Jim Sutemeier 70673,1754
To: Steve Wegert 76703,4255 (X)

Your friends problem does sound like an isolated incident.  I am having no
problem at all with my TC70 - everything, including the reset button, work just
fine.

I have NOT, however, tried keeping mine up and working for 38 hours, <YET>, so
that I cannot comment on reliably.

Once I put my BBS up on the TC70, I'll be able to comment on usage for long
periods of time.

So far, I am extremely happy with the Tomcat70, making plans to expand it to
customize my computer the way I want it.

jim Sutemeier SysOp <Plain Rap> BBS 818-894-0012



There is 1 Reply.

#: 12434 S4/MIDI and Music
    28-Sep-91  09:23:54
Sb: #12424-Bad Download
Fm: Steve Wegert 76703,4255
To: Jim Sutemeier 70673,1754

With your positive report on the box, Jim, it does help support the 'isolated
instace' position. And I know Frank will do everything he can to resolve the
outstanding issues my friend is still having.

I'll keep you posted on how it goes.

Steve

#: 12305 S1/General Interest
    20-Sep-91  07:12:40
Sb: #12096-Atlanta 'Fest
Fm: Eric A. Cottrell  [WIT] 76327,515
To: Kevin Darling 76703,4227 (X)

Thanks Kev,
Not much time for the old CoCo. Still lurk around the forum.
I am going to LA in November so I can not get away. I am going to learn some
more about orbiting objects.
73 Eric...

#: 12311 S12/OS9/68000 (OSK)
    20-Sep-91  12:39:54
Sb: #intercept
Fm: Roy Dacus 70721,1113
To: all

/* sigl.c */
/* a program to show that you can longjmp() from intercept() */
/* without the stack growing.  control E to end, control C to test */
/* part 1 */

#include <stdio.h>
#include <setjmp.h>
#define TRUE 1
#define FALSE 0

int count1;
int init;
int jumped;
int ret;
jmp_buf env1;

main()
{
    int ccheck();
    count1=0;
    init=FALSE;
    intercept(ccheck);
    pmain();
}

ccheck(signum)
int signum;
{
    if (signum != 3)
        exit(signum);
    if (jumped)
        return;
    pmain();
}


There is 1 Reply.

#: 12380 S12/OS9/68000 (OSK)
    23-Sep-91  08:08:09
Sb: #12311-intercept
Fm: Mark Wuest 74030,332
To: Roy Dacus 70721,1113 (X)

Roy,
 I'm not sure if you read the entire thread, but Kim Kempf (is he still at
Microware?) pointed out the existance of another stack that we do not see. I
thought the same thing you did at first, BTW, even verifying that the usp is
intact with srcsbg.
 Mark

#: 12312 S12/OS9/68000 (OSK)
    20-Sep-91  12:41:32
Sb: intercept
Fm: Roy Dacus 70721,1113
To: all

/* part 2 */
numpr()
{
    int count;
    long place;
    count = 0;
    place = (long)&count;
    printf("%lu\n",place);
}

counter()
{
    int time1;
    while(1) {
        printf("%d\n",count1++);
        if (count1%24==0)
            numpr();
        for (time1=0; time1<5000; time1++);
    }
}


#: 12313 S12/OS9/68000 (OSK)
    20-Sep-91  12:43:08
Sb: intercept
Fm: Roy Dacus 70721,1113
To: all

/* part 3 */
pmain()
{
    jumped=TRUE;
    if (init)
        longjmp(env1,1);
    ret=setjmp(env1);
    if (ret == 0)
        init=TRUE;
    count1=count1*10;
    jumped=FALSE;
    guts();
    counter();
}

/* guts: Give Up Time Slice */
#asm
guts: move.l #1,d0
 os9 F$Sleep
 clr.l d0
 clr.l d1
 rts
#endasm


#: 12318 S15/Hot Topics
    20-Sep-91  15:44:57
Sb: #11866-Serial ports?
Fm: Paul K. Ward 73477,2004
To: Jim Peasley 72726,1153 (X)

Jim,

We did NOT change! You get TWO serial ports with a Personal System (i.e., sans
I/O board), and a THIRD with the I/O board.

Your confusion stems from the fact that we have yet to send your second serial
port for your I/O board. The chips are being purchased for a new batch to go
out. It is a small printed circuit board that hosts a Motorola serial chip and
a dual-row header for jumpering various serial signals. Some customers have
theirs, some do not.

So, you are right!

Paul IMS

#: 12319 S15/Hot Topics
    20-Sep-91  15:45:45
Sb: #11897-MM/1 delivery
Fm: Paul K. Ward 73477,2004
To: GLEN HATHAWAY 71446,166 (X)

Glen,

I thnk we're all set up now on your order! Thanks for the tip on calling you...

Bst,

Paul IMS

#: 12320 S15/Hot Topics
    20-Sep-91  15:46:56
Sb: #11925-Troubles and Woe
Fm: Paul K. Ward 73477,2004
To: Jim Peasley 72726,1153 (X)

Jim,

Yours is the second power supply that has crapped out -- looks like a QC
problem with our supplier. They are warrantied,and you and I have talked about
the correct procedure. Do let me know what else I can do in the meantime.

Thanks!

Best,

paul IMS

#: 12321 S4/MIDI and Music
    20-Sep-91  15:49:23
Sb: #11947-UMUSE3
Fm: Paul K. Ward 73477,2004
To: Mike Knudsen 72467,1111

Generally, i think the rainbow reviews will tend to be generous until the
various companies parameters are better known -- then I think customers and the
magazine will end up characterizing them by their chief strenghths (with the
implication that they are intended for discrete audiences, which may or may not
be true).

Anyway, I think in general, the MIDI stuff on the MM/1 will end up being pretty
darn exciting.

Paul ims

#: 12326 S15/Hot Topics
    20-Sep-91  16:14:46
Sb: #11780-#Help and the MM/1
Fm: Paul K. Ward 73477,2004
To: John R. Wainwright 72517,676 (X)

Technical Overview will be for sale at the fest for cheap. A more comprehensive
Technical Manual is also in the works for 1992 release.

Paul IMS

There is 1 Reply.

#: 12345 S15/Hot Topics
    20-Sep-91  20:56:23
Sb: #12326-#Help and the MM/1
Fm: John R. Wainwright 72517,676
To: Paul K. Ward 73477,2004 (X)

Thanks,  Paul.

Don't think I'll be able to make it to Atlanta, but I'll find a way to get hold
of one (technical overview) - could I phone in an order?

John Wainwright

There is 1 Reply.

#: 12384 S15/Hot Topics
    23-Sep-91  16:00:57
Sb: #12345-Help and the MM/1
Fm: Paul K. Ward 73477,2004
To: John R. Wainwright 72517,676 (X)

John,

You sure can order over the phone. Call at 202 232 4246. I have had a sudden
increase in phone activity of the last three weeks (the Fall season is here!),
making it a challenge to keep my phone mail box empty (it holds up to 95
messages) each day. But do keep trying. Tentative price is $39.95.

Best,

Paul

IMS

#: 12327 S7/Telecommunications
    20-Sep-91  16:17:12
Sb: #11807-MM/1 and STERM
Fm: Paul K. Ward 73477,2004
To: Bill Dickhaus 70325,523 (X)

Bill,

I am hoping to have serial drivers for most (if not all) serial ports to handle
38.4 K baud.

Of course, IsquaredC can handle 100,000bps, but that's not for modem
communication, generally.

paul ims

#: 12328 S12/OS9/68000 (OSK)
    20-Sep-91  16:21:51
Sb: #11810-Questions
Fm: Paul K. Ward 73477,2004
To: Jim Peasley 72726,1153 (X)

Jim,

Thanks for the list of questions! When we talked ont he phone recently, you did
not ask them, so I assume you have been satisfied here. If not, well,

here goes!

John Vestal and NCSU has used a DiamondScan on the MM/1. So has KK Darling.

PCF requires a new driver that support variable sector sizes. That driver is
being worked on. It will be provided to you for cost of media.

I love emacs.

I also love Bob's VED!

Several folks have I/O boards. More are shipping by the end of the month or so.
Mostly, we are spending our time on clubs, reps, shipping another big batch of
MM/1s, shows ( I was involved with two conventions last week) and club shows.

Busy, indeed!

Hope this helps.

Best,

paul ims

#: 12329 S12/OS9/68000 (OSK)
    20-Sep-91  16:26:32
Sb: #11884-Questions
Fm: Paul K. Ward 73477,2004
To: Mark Wuest 74030,332 (X)

Mark,

We should have g ++ on the MM/1 some time before Christmas, FYI.

Best,

Paul IMS

#: 12330 S12/OS9/68000 (OSK)
    20-Sep-91  16:29:42
Sb: #11824-#MM/1 Audio
Fm: Paul K. Ward 73477,2004
To: John R. Wainwright 72517,676 (X)

The window driver for your single board MM/1 does not support Display 7. The
window driver for the dual board system (the bootdisk on Disk #2 contains that
driver) DOES support Display 7.

The Play commands do require the second board.

if you type Break at a shell prompt to do a software reset, with the PC speaker
hooked up, I think you will hear the beep. I don't know as my case does not
have a PC speaker in it.

Paul IMS

PS Good to hear from you, BTW!

There is 1 Reply.

#: 12346 S12/OS9/68000 (OSK)
    20-Sep-91  21:00:09
Sb: #12330-MM/1 Audio
Fm: John R. Wainwright 72517,676
To: Paul K. Ward 73477,2004 (X)

Aha.   Another problem solved.  Thanks again.

JohnW

#: 12331 S15/Hot Topics
    20-Sep-91  16:33:38
Sb: #11825-#MM1 & unknown pins
Fm: Paul K. Ward 73477,2004
To: William Phelps 75100,265 (X)

William,

Tech Overview manual will be ready by early October. In the meantime, you can
call Mark Griffith (call me for phone number) for pinout info.

Many of the jumpers on the CPU board are for video sync, IsquaredC, and VSC
signals. Most are designated in the Kit Instructions. Details can be found in
the interim from Mark Griffith and the Signetics manuals on the 66470, 68070,
and IsquaredC.

The September issue of Embedded Systems Programming contains a nice article on
IsquaredC, and references source code to be found on CompuServe somehwere.

GIve me a call and I'll tell you more about the ESP article and the source
code. May interest you!

Best,

paul IMS

PS Please do call for Mark's number.



There is 1 Reply.

#: 12377 S15/Hot Topics
    23-Sep-91  01:44:16
Sb: #12331-#MM1 & unknown pins
Fm: William Phelps 75100,265
To: Paul K. Ward 73477,2004 (X)

You will receive a call soon.

William

There is 1 Reply.

#: 12385 S15/Hot Topics
    23-Sep-91  16:02:02
Sb: #12377-MM1 & unknown pins
Fm: Paul K. Ward 73477,2004
To: William Phelps 75100,265

William,

Keep trying if the mailbox is full. I try to clear it out every night.

Best,

Paul

IMS

#: 12332 S15/Hot Topics
    20-Sep-91  16:52:19
Sb: #11957-#MM/1 & floppies
Fm: Paul K. Ward 73477,2004
To: William Phelps 75100,265 (X)

Make sure the 5.25 inch floppy is NOT terminated. In terms of Dmode'ing to make
sure you can read and write, for a quick, sweet answer, check with KK Darling.

Paul

IMS

(I mention Kevin not because he is an IMS employee or a support person, but
because he constantly transfers stuff between his CoCo and the MM/1, and I do
not.)

Best

Paul

There is 1 Reply.

#: 12378 S15/Hot Topics
    23-Sep-91  01:48:02
Sb: #12332-#MM/1 & floppies
Fm: William Phelps 75100,265
To: Paul K. Ward 73477,2004 (X)

Actually I think the problem is the VERSION of the drivers that I have.

William

There is 1 Reply.

#: 12386 S15/Hot Topics
    23-Sep-91  16:02:51
Sb: #12378-MM/1 & floppies
Fm: Paul K. Ward 73477,2004
To: William Phelps 75100,265

William,

THere are some new drivers floating around our developers that are improved. I
have not yet received them, but should have them soon.

Best,

Paul IMS

#: 12333 S15/Hot Topics
    20-Sep-91  16:55:45
Sb: #12034-MM/1 & floppies
Fm: Paul K. Ward 73477,2004
To: Scott t. Griepentrog 72427,335

Scott,

Hee, hee!! Naturally, I'd like to fix up William's thing with the 5.25" drive.
Have grabbed your messages and will follow up!

Best,

paul ims



#: 12335 S12/OS9/68000 (OSK)
    20-Sep-91  17:00:10
Sb: #11970-OSK
Fm: Paul K. Ward 73477,2004
To: Dave Philipsen 73627,710

Dave,

You may be able to find some sample 68k driver code here. Also, try the
Technical I/O Manaul from Microware, and OS-9 Insights from Microware.

Best of luck,

Paul

IMS

#: 12336 S1/General Interest
    20-Sep-91  17:04:15
Sb: #12014-#The Rescue
Fm: Paul K. Ward 73477,2004
To: Paul Hanke 73467,403 (X)

Floyd lives in Cincinnati. I have his phone number if you need it.

Best,

Paul IMS

There is 1 Reply.

#: 12353 S1/General Interest
    20-Sep-91  22:11:51
Sb: #12336-The Rescue
Fm: Paul Hanke 73467,403
To: Paul K. Ward 73477,2004 (X)

Well, Floyd's address is given in the docs to his games, but I don't have time
to persue the matter further; besides the fudge fix works.

'Course if there are no bugs in level 23, and it is just my perception that
there are, I'd have to find time to go back and play some more legitimate
rounds.   -ph- 

#: 12337 S12/OS9/68000 (OSK)
    20-Sep-91  17:13:57
Sb: #12046-OSK
Fm: Paul K. Ward 73477,2004
To: Ed Gresick 76576,3312 (X)

Ed,

Thank you for your thoughts on software compatibility.

My first reaction is that OSK will soon have a national visibility due to CD-I
and that pressure will be on all of us to make hardware and software choices to
conform to national standards. By "standard", unfortunately, I cannot mean only
ANSI or ISO standards -- often it must be DE FACTO standards.

Termcap compatibility is a help. Other considerations include ANSI C compiler
availability to ease porting to/from UNIX, Athena compatibility,
UUCP/C-BourneShell/UNIX-command set compatibility, a set of aliases to help DOS
users, Point-and-click environment when consoles are required, with a C library
and C style guide that allows the same program to run on terminals when
necessary, and so on.

Keep up the good work.

Best,

Paul

IMS

#: 12339 S12/OS9/68000 (OSK)
    20-Sep-91  17:20:03
Sb: #12069-Your Standards Texts
Fm: Paul K. Ward 73477,2004
To: Mark Griffith 76070,41 (X)

mark,

absolutely the correct method.

It actually does not make THAT much difference NOW how a programmer programs
for OSK. The OSK market per se does not really exist since the majority of OSK
users are a very spread-out, difficult to reach bunch, and so do not constitute
a large mass of folks with simple needs.

In the future, though, the OSK market will be bigger, and standards, even
simple ones, are naturally the best route.

Best,

paul

ims

#: 12340 S5/OS9 Users Group
    20-Sep-91  17:20:38
Sb: #12076-Cross Assembler
Fm: Paul K. Ward 73477,2004
To: Pete Lyall 76703,4230 (X)

Might have been UltraScience.

Best,

paul

ims

#: 12341 S12/OS9/68000 (OSK)
    20-Sep-91  17:25:29
Sb: #12089-#MM/1
Fm: Paul K. Ward 73477,2004
To: John R. Wainwright 72517,676 (X)

I/O boards ARE shipping, but slowly while we get more base systems out! After
that, they will go out rapidly.

Yeah, UPS went on strike the first day that Customs in Canada recieved his
MM/1. It took them several weeks to find it, then they had to call us for some
information on getting in touch with Colin. A mess.

Paul

IMS

There is 1 Reply.

#: 12350 S12/OS9/68000 (OSK)
    20-Sep-91  21:08:03
Sb: #12341-MM/1
Fm: John R. Wainwright 72517,676
To: Paul K. Ward 73477,2004 (X)

Hehe, I have a picture in mind of you, finally getting some time to get on to
the forums and answer questions.  You get the sign-up and welcome to the forum
and it tells you you have 3,546,230 messages waiting.  EEEEEk! (Maybe not quite
that bad, but I bet it keeps you busy for a while.  Hang in there.

JohnW

#: 12360 S1/General Interest
    21-Sep-91  11:23:04
Sb: Sir Speedy!
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)

Mark;
  Thanks for the phone call AND the prompt service.  Looking forward to getting
back to doing some serious programming on the MM/1 in the near future.
  Now, if I only had my I/O board (Paul, hint - hint!) so I didn't have to keep
swapping floppies and some more memory!

Thanks,
  ...Jim




#: 12361 S15/Hot Topics
    21-Sep-91  11:24:13
Sb: More questions?
Fm: Jim Peasley 72726,1153
To: Paul Ward

Paul;
  Glad to see you back 'on-line' after so long!  Bet your 'messages waiting'
counter was WAY up there, eh?

  Mark called me about 15 minutes ago to report that the pallette controller
was the culprit on my MM/1 and that he'd already replaced it and tested it.
Should be headed back West on Monday.

  Can you give me an approximate date for the I/O and 2nd serial boards to be
shipped?  As someone else just mentioned, swapping floppies - even 1.4M
floppies - is a royal pain when you're trying to accomplish something!  And the
system memory gets kind of skinny too, even tho it's twice what my CoCo has!

  Do you have an address/phone# for those Signetics data manuals that you
mentioned in one of your replies yesterday?  Any other sources of data for
programming/interfacing that you have would also be welcomed!

Thanks,
..Jim



#: 12362 S10/OS9/6809 (CoCo)
    21-Sep-91  11:46:55
Sb: #cgp220 driber
Fm: emmett riordan 73367,636
To: [F] ALL

I have been pleasently suprised to find an emerging library of graphic software
for OS09 [DI have been experimenting with a variety of formats and relaized
that I would like to use my CGP-220 printer to get color printo [Dprintouts. I
have not been able to locate any printer drivers for the CGP-220 on any of the
local boards or listed from any vendors. I guess another option would be to
port thr images over to a CM3 format but again, no software seems to be
available. Is anyone sharing this problem? Is there a driver that will permit a
user to use their color printer under OS9. I could solve this problem by simply
doing this from my PC but that is simply not the same as working from OS). Any
help would be appreciated.

There is 1 Reply.

#: 12363 S10/OS9/6809 (CoCo)
    21-Sep-91  13:55:10
Sb: #12362-cgp220 driber
Fm: Kevin Darling 76703,4227
To: emmett riordan 73367,636

Hi Emmett,

Sure, just drop into Lib 10, and do a "bro /key:cgp*".

I did, and found 3 interesting print utils.   You might also want to get the
vefio screen snapshot util/viewer (I believe called VEFIO.AR and WINFO.AR?) if
you don't already have them.

Yell if have any troubles. - kev

#: 12367 S1/General Interest
    21-Sep-91  21:18:19
Sb: 1 meg upgrade
Fm: Paul Hanke 73467,403
To: anyone

Just finished browsing thru the latest Rainbow and found that no one appears to
be advertising the 1 meg upgrade any longer!!!  Does that mean it is no longer
available from any distributor or that they just don't run the adv in each
issue?    -ph- 

#: 12375 S10/OS9/6809 (CoCo)
    22-Sep-91  16:50:02
Sb: Hard drive
Fm: PHIL SCHERER 71211,2545
To: ALL

I currently have a SASI hard drive and I was wondering what it would take to
convert to SCSI. Is it just a matter of getting a new controller and driver?

#: 12376 S1/General Interest
    22-Sep-91  16:59:56
Sb: #Bogus
Fm: Paul Rinear 73757,1413
To: Sysop (X)

     I sure do miss checking in every now and then and typing ANN;5 for a list
of new uploads. Was there a CIS software change or something?
                            Paul R.

There is 1 Reply.

#: 12401 S1/General Interest
    25-Sep-91  08:43:27
Sb: #12376-Bogus
Fm: Steve Wegert 76703,4255
To: Paul Rinear 73757,1413

Paul,

Sort of ...


By doing a SCAN  with the age switch you can come up with the latest files in
each of the libraries. Not as handy as seeing everything in one list but that's
also soon to change with some new software that's due to hit the forum's by the
end of October.

You'll be able to apply ANY library command across ALL librarys in a forum,
with a command such as SCA /lib:all /age:10

The software is currently running in the PRACTICE forum. You can check it out
for free.

Steve

#: 12379 S10/OS9/6809 (CoCo)
    23-Sep-91  02:14:22
Sb: #ACIAPAK patch vs. SACIA
Fm: Erich Schulman 75140,3175
To: ALL

Which is re likely to improve my /t2's performance:
      a.) Patching ACIAPAK so as to increase its buffer size, or
      b.) Intalling SACIA drivers in place of ACIAPAK? I have the ACIAPAK patch
and the SACIA drivers all ready.  I just need to know which would more likely
be a better long-term solution.  Since I've been td that SACIA's xmode can't be
used with /t1 and /p, can I continue using the regular xmode command with them?
If not, is there any way I can retain ACIAPAK with SACIA without having to
create a special boot disk just for SACIA?  If the ACIAPAK patch would work
better, what is the biggest buffer size one ought use (assuming I figure out
how to modify the patch as per my download)?

There are 2 Replies.

#: 12392 S10/OS9/6809 (CoCo)
    24-Sep-91  07:04:54
Sb: #12379-ACIAPAK patch vs. SACIA
Fm: Bill Dickhaus 70325,523
To: Erich Schulman 75140,3175 (X)

Erich,

You're best bet is to use SACIA, and get rid of ACIAPAK all together. SACIA is
based on the ACIAPAK that was to be released with the upgrade. It has all the
new features, including being able to set the input buffer size in the device
descriptor. You could have both SACIA and ACIAPAK in the same boot, but you
would have to make up a new set of descriptors. Not only that, but I'm pretty
sure that the clock module that comes withSACIA would require additional
patches on ACIAPAK so that it would work with the new clock module.

Bill

#: 12393 S10/OS9/6809 (CoCo)
    24-Sep-91  07:05:04
Sb: #12379-#ACIAPAK patch vs. SACIA
Fm: Bill Dickhaus 70325,523
To: Erich Schulman 75140,3175 (X)

Erich,

The stock xmode should work fine with an SACIA descriptor, just the extras
(like buffer size) can't be modified. I'm not sure which xmode is packaged with
SACIA (I think its the oe I use), and I'm not sure why it wouldn't work with
/T1 or /P. I have my modem ports set up with 2 pages of buffer space (512
bytes), and that seems to work well (I'm not using SACIA, though). Just
remember the buffer comes out of the system map, if you make it too big, the
dreaded 237's will get you!

Bill

There is 1 Reply.

#: 12397 S10/OS9/6809 (CoCo)
    24-Sep-91  12:43:20
Sb: #12393-ACIAPAK patch vs. SACIA
Fm: Erich Schulman 75140,3175
To: Bill Dickhaus 70325,523 (X)

I'm going to work on my OS-9 overhaul today.  Thanks for your info; I'll keep
all that in mind as I'm working on it.

#: 12388 S7/Telecommunications
    23-Sep-91  22:56:29
Sb: #IRQ hack
Fm: Paul Hanke 73467,403
To: anyone

Just  completed  the irq hack. Now, using sterm  1.5, I no  longer get missing
text lines.  I have yet to e upgrades which allow faster transfer times.  A
question concerning the hack:
  When removing the blue jumper wire in the rs232 pak, there is no replacement
wiring for the  other side. Does this mean that the pack can now be  used only
for  OS9 communications or will it still work for say  Uterm?
  If only for OS9, how about installing a socket/plug arrangement  on the 
rs232 pak as well. This would allow for removal of  the irq hack and restore
the original jumper connection, if the socket is wired correctly.  The only
problem I can anticipate would be if I forgot to remove the wire before using
Uterm which might cause damage to  one circuit or  the other  (?).    -ph-

There is 1 Reply.

#: 12398 S7/Telecommunications
    24-Sep-91  19:37:39
Sb: #12388-#IRQ hack
Fm: Pete Lyall 76703,4230
To: Paul Hanke 73467,403 (X)

Scratching old memory cells here...

All the hack does is pass the IRQ from the 6551 chip directly to the 6809's IRQ
line... no stopping at PIA's or multiplexor chips. In the original PAK
configuration, I believe the line (IRQ from the 6551) was originally setup to
go to NMI (non maskable interrupt). This was a bad idea, thus all the little
blue jumper wires. It is now connected to pin 8, which lands on the coco as
either an IRQ or possibly an FIRQ (been too long).

Best advice: try it. I believe you'll have no problems. Hundreds if not
thousands have installed this simple mod with no negative effects.

Pete

There is 1 Reply.

#: 12400 S7/Telecommunications
    25-Sep-91  08:03:39
Sb: #12398-IRQ hack
Fm: Paul Hanke 73467,403
To: Pete Lyall 76703,4230 (X)

  Added the socket so that when the plug is removed, the jumper is effectively
restored, returning the pack to its original status.
I found that with the hack in place, Uterm doesn't work.  On the other hand,
DM-3's telecom doesn't seem to care whether it's in place or not. 
  To be on the safe side, one should probably remove the wire from both sockets
since a loose end at the pack side could subject the 6809's pin 3 to some
possible static discharge thru inadvertent mis-handling.    -ph- 

#: 12399 S12/OS9/68000 (OSK)
    24-Sep-91  21:19:38
Sb: #Long code
Fm: Bob van der Poel 76510,2203
To: All

Does anyone know why Microware used code like this in the strlen() and strcat()
library functions?

  strlen  move.l   a0,-(a7)
          movea.l  d0,a0
  strlen1 tst.b    (a0)+
          beq.b    strlen2
          tst.b    (a0)+
          beq.b    strlen2
          tst.b    (a0)+
          beq.b    strlen2
          tst.b    (a0)+
          bne.b    strlen1
  strlen2 ....

I assume that a beq is quicker than a bne??? My 68000 manual doesn't show
that--but, even if it is, would it make any real difference? After all, we are
talking about a C library routine.



There are 2 Replies.

#: 12403 S12/OS9/68000 (OSK)
    25-Sep-91  09:39:37
Sb: #12399-Long code
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)

Bob,
 *I* know! The guy that wrote it worked for one of those people that evaluated
programmers' performance by # of lines of code written.
 Hmmmmmm....
 Mark
 <g>

#: 12404 S12/OS9/68000 (OSK)
    25-Sep-91  10:06:16
Sb: #12399-Long code
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203 (X)

An untaken Bcc is faster than a taken Bcc, by a couple of cycles.  So by
unrolling a testing loop like that, you speed things up a tiny amount... not by
much, but in a commonly used routine the savings can really add up.

#: 12402 S1/General Interest
    25-Sep-91  09:07:36
Sb: #WHAT'S AN OS-9 ???
Fm: Victor Epstein 70004,515
To: ALL

Hi !

I've never heard of OS-9 and I kind of wandered in here by accident. It appears
to be an operating system for the old Tandy Color Computers--am I right ? Can
someone tell me a little bit about this system and the forum. Do any other
machines use the OS-9 ? Thanks


                                --Vic

There are 2 Replies.

#: 12405 S1/General Interest
    25-Sep-91  15:19:09
Sb: #12402-WHAT'S AN OS-9 ???
Fm: Lee Veal 74726,1752
To: Victor Epstein 70004,515

Victor,

OS-9 was originally written for the Motorola 6809.  The Tandy CoCo product
family (1/2/3) has always used the 6809 as its processor.  When the 68000 CPU
was developed it seemed natural to extend OS-9 to that processor as well.  The
68K version of OS-9 is sometimes called OSK, but it's still officially called
OS-9.  With the advent of better Intel processor chips, it became feasible to
extend the OS-9 product line into the Inael chip world.  OS-9000 is a
"portable" version of OS-9, that is, it's predominately written in C.  Only
very low level routines are written in the host processors native machine
language.
  OS-9000 will run on Motorola 680x0 processors and is slated, I believe, to
run on some of their RISC processors as well.  It also runs on the Intel '386
processor.  Microware is finishing up an MS-DOS emulator, that will allow a 386
host running OS-9000 to run multiple MS-DOS applications.
  OS-9(000) is a real-time, multi-tasking, multi-user operating system which
has some similarities to Unix, but with a better interrupt handling system (for
better handling of the real-time applications).  The real-time functionality is
facilitated by some special OS-9 features, namely, preemptive task switching,
process execution control and fast, flexible interrupt service routines.  More
detail on this can be found in the OS-9 Catalog.

  OS-9 for the CoCo3 even does windows.  We've been multi-tasking and doing
windows for years, in fact.  My CoCo3 here at work uses an Epson Equity II+ as
a terminal through a multi-port serial card that I have plugged into the CoCo3.

 Microware Systems Corporation developed OS-9.
 They can be reached by mailpat:

  1900 N.W. 114th St
  Des Moines, Ia  50325-7077

  ph: (515) 224-1929

  Ask for Steve Johnson.
  Ask him to send you an OS-9 Catalog and/or an OS-9 Sourcebook.  I believe
they also have counterparts for these books for OS-9000, too.

Lee



#: 12406 S1/General Interest
    25-Sep-91  15:58:52
Sb: #12402-WHAT'S AN OS-9 ???
Fm: Kevin Darling 76703,4227
To: Victor Epstein 70004,515

Hi Vic!

If you're who I think you are, I had meant to send you some info for your
"orphaned" and "niche" machines article.  Is it still planned?

The July 1989 Online issue had a story about this forum and the OS-9 operating
system (which runs on many machines)... but I think an update is needed.

Especially as, since then, one of the machines which runs it (the Tandy CoCo)
has been discontinued.  Didn't matter much to the owners tho :-)   I think
there's more OS-9 users on it now, than there were before the CoCo was
orphaned!

In addition, some neat new 68K machines have been built, designed in part from
massive OS-9 user discussions held here.  Some of that's still in the libs, I
think (15?).

Anyway, just wanted to say "hello and welcome aboard".  Ask away... we'll all
do our best to answer any Q's you have.   You can also "GO MSC" to check out
Microware's display area... has much OS-9 info.  cheers - kevin

#: 12411 S10/OS9/6809 (CoCo)
    26-Sep-91  20:12:53
Sb: #File Structure
Fm: Bob Archambault 76506,3544
To: ALL

I did a DCHECK on my hard drive, and came up with some clusters previously
allocated, and clusters in file structure but not in allocation map.

Now, the manual explains all this quite well, and I have no problems using the
system, BUT I need to know what, if anything, can be done to make my file
structure "intact" again. The book unfortunately doesn't explain this.

Also, is there a "de-fragmenter" program in the DL's anywhere??

Thanx much in advance!

Bob



There are 2 Replies.

#: 12415 S10/OS9/6809 (CoCo)
    26-Sep-91  23:26:31
Sb: #12411-#File Structure
Fm: James Jones 76257,562
To: Bob Archambault 76506,3544 (X)

You really shouldn't continue to use the disk until you do something about the
problems.  A disk sector can only hold one thing at a time, and if two
different files think they have the same sectors, then their contents can
easily be corrupted, and ditto for a file that thinks it's using a sector that
isn't marked as used in the allocation map!

Use the -p option on dcheck, not to mention using -w to put the workfiles
somewhere *other* than the hard disk, and see what files are using the clusters
that are in dispute.  The safest thing to do would be to copy those files to
floppy, delete them from the hard disk, run dcheck to make sure that this has
corrected the problem on the hard disk, and then copy the files back from
floppy to the hard disk.  If you've written to sectors that are in dispute,
then you won't be able to recover all the stuff, but you may be able to get
most of it back.

There are 2 Replies.

#: 12428 S10/OS9/6809 (CoCo)
    27-Sep-91  19:45:49
Sb: #12415-File Structure
Fm: Bob Archambault 76506,3544
To: James Jones 76257,562 (X)

Thank you, James,

Your information was a great help to me; I'll get on that disk problem right
away!

Thanx again,

Bob



#: 12436 S10/OS9/6809 (CoCo)
    28-Sep-91  12:05:24
Sb: #12415-File Structure
Fm: Pete Lyall 76703,4230
To: James Jones 76257,562

JJ/Bob -

The 'sectors in file system but not in allocation map' is okay on a floppy, but
not on a hard disk. (On a floppy it typically refers to the sectors marked as
'used' that are associated with the boot track information [TRK 34] which don't
appear in a directory or FD sector anywhere). On a hard disk

(assuming you're booting from floppy) you shouldn't be seeing this. Also, the
business about have sectors allocated more than once is surely the road to
ruin. I refer to it as disk cancer.

Two fixes (actually, one fix, one hack):

  Fix: backup the disk, reformat, and then repopulate it.

  Hack: Find out which files are associated with the sectors in question.
        I believe Kreider wrote a tool called 'Hooz' that did this. Then
        Make copies of the files into new files (one of them is bound
        to be trashed, as they have intersecting disk real estate). Then
        mark both files with unwritable attributes so they can't be deleted.
        If either file IS deleted, it'll return its sectors to the free
        pool and cause the cancer to propagate.

One last thought.... if you are making using of the LINK BYTE in alllowing
multiple filenames for the same file (ala the unix-ish 'ln' command), the
multiple sector allocation is 'normal'.

Pete

#: 12420 S10/OS9/6809 (CoCo)
    27-Sep-91  10:38:06
Sb: #12411-#File Structure
Fm: Erich Schulman 75140,3175
To: Bob Archambault 76506,3544 (X)

I remember seeing something in the Libs that will defragment a file but NOT a
disk.  And that's obviously not the best way to defrag a hard drive!  If you
want it, I believe it's in Lib 9 or 10, but I don't recall offhand.  I am not
aware of any downloadable program for disks.  You might want to check ads in
Rainbow for Burke&Burke (their commercial program is not that expensive) and
for NineTimes (they listed one among other stuff).  Since I have no hard drive,
I don't actually have any of this; I merely remember seeing it before.

There is 1 Reply.

#: 12427 S10/OS9/6809 (CoCo)
    27-Sep-91  19:43:01
Sb: #12420-File Structure
Fm: Bob Archambault 76506,3544
To: Erich Schulman 75140,3175 (X)

Thanks, Erich,

I probably will go with B&B's de-fragmenter program. Just wanted to see if
there was a free one available <grin>.

Bob



#: 12416 S12/OS9/68000 (OSK)
    27-Sep-91  00:10:15
Sb: #Intercept
Fm: Roy Dacus 70721,1113
To: [F] Mark Wuest 74030,332 (X)

/* sigl.c */
/* a program to show that after you catch a signal you can longjmp() */
/* runs best after a "$ Tmode nopause" */
/* control E to end  *   control C to test */

#include <stdio.h>
#include <setjmp.h>
#define TRUE 1
#define FALSE 0

/* start of stuff for tcept */
unsigned long _afunc1;
unsigned long _afunc2;
/* end of stuff for tcept */

unsigned long count1;
char count2;
int fflag;

int init;
int ret;
jmp_buf env1;

c1check(signum)
int signum;
{
    if (signum != 3)
        exit(signum);
}

c2check()
{
    pmain();
    exit(0); /* safety net */
}

numpr()
{
    int count;
    long place;
    count = 0;
    place = (long)&count;
    printf("%lu\n",place);
}

c1ounter()
{
    int time1;
    while(1) {
        printf("%lu\n",count1++);
        if (count1%24==0)
            numpr();
        for (time1=0; time1<5000; time1++);
    }
}

c2ounter()
{
    int time1;
    while(1){
        for (count2=33; count2<126; count2++){
            for (time1=0; time1<5000; time1++);
            printf("%c\n",count2);
        }
        numpr();
    }

}
/* continued */

There is 1 Reply.

#: 12418 S12/OS9/68000 (OSK)
    27-Sep-91  07:56:13
Sb: #12416-Intercept
Fm: Mark Wuest 74030,332
To: Roy Dacus 70721,1113 (X)

Roy,
 Boy have *you* been busy! I hope Bob sees and understands your code examples
as he is the one that wanted to longjmp(). I must confess that, even after
seeing an example of how to get around it, I would never write such code. If my
Unix-experienced fellow developers ever had to fix a bug in my code while i was
out of town, they would *kill* me when I got back <g>! It was bad enough having
to port stat(), etc to os9. (Actually, getting Stevie to work properly was the
real pain).
 Mark

#: 12417 S12/OS9/68000 (OSK)
    27-Sep-91  00:11:54
Sb: Intercept
Fm: Roy Dacus 70721,1113
To: Mark Wuest

pmain()
{
    if (init)
        longjmp(env1,1);
    ret=setjmp(env1);
    if (ret == 0)
        init=TRUE;
    if(fflag){
        fflag=FALSE;
        c1ounter();
    }
    if(!fflag){
        fflag=TRUE;
        c2ounter();
    }
    
}

main()
{
    count1=0;
    init=FALSE;
    tcept(c1check,c2check);
    pmain();
}

#asm
* * * * *
* void tcept(func1,func2))
* int (*func1)()
* int (*func2)()
* tcept (Twin interCEPT)
* A intercept replacement that lets you longjmp().
* notes:
* func1 is run just like in intercept().
* Thats means the following:
* 1: you can not call any function that calls F$SigMask,
* F$Sleep or F$Wait as they will unmask.  This is just like
* intercept().
* 2: you can not do a longjmp().  This is just like
* intercept().
* 
* func2 is run just like any other function, except that
* you must never return.
* Thats means the following:
* 1: you can longjmp().
* 2: you can exit().
*
tcept: move.l a0,-(a7) save a0
 move.l d0,a0 temp save of -> one
 move.l a0,_afunc1(a6) real save of -> one
 beq.b _tcept1 if zero jump and tell os9 to turn off intercept
 move.l d1,_afunc2(a6) save of -> two
 lea.l _tcept2(pc),a0 get -> to inside me
_tcept1 os9 F$Icpt tell os9
 move.l (a7)+,a0 restore a0
 rts
*
_tcept2 move.l d1,d0 put signal in right place
 move.l _afunc1(a6),a0 -> to func1
 jsr (a0) run func1
 move.l _afunc2(a6),a0 -> to func2
 move.l a0,66(a7) fix stack so i start func2
 os9 F$RTE go to func2 and NEVER return!
* because of F$RTE OSK will not have a stack overflow
#endasm

#: 12421 S7/Telecommunications
    27-Sep-91  10:40:30
Sb: #Case-sensitive sterm
Fm: Erich Schulman 75140,3175
To: ALL

I have seen that when I use sterm -f -l /t2, on the command line, sterm seems
to be case-sensitive on the switches invoked.  sterm -F -L /T2 does not start
the program.  Why is this?  Can anything be done about it?

There is 1 Reply.

#: 12430 S7/Telecommunications
    27-Sep-91  22:01:20
Sb: #12421-Case-sensitive sterm
Fm: James Jones 76257,562
To: Erich Schulman 75140,3175

It's just the way the program was written; it would be hard to do much about it
without the source code, to change and recompile.

#: 12422 S9/Utilities
    27-Sep-91  10:43:06
Sb: #MS-DOS ARC/ZIP
Fm: Erich Schulman 75140,3175
To: ALL

I know there are utilities for extracting ZIP archives, but are there any that
will extract MS-DOS ARC files?  Also, are there utils that will CREATE MS-DOS
ZIP archives?

There are 2 Replies.

#: 12425 S9/Utilities
    27-Sep-91  13:23:52
Sb: #12422-#MS-DOS ARC/ZIP
Fm: edward langenback 73510,145
To: Erich Schulman 75140,3175 (X)

well, theres os9arc which will create ms-dos format arhives, but i`ve never
heard of anything to create .zip format archives.  just burst em.

"KMA-68!!"
                                  >>>>>S S<<<<<
                                  !!!!!!!!!!!!!

There is 1 Reply.

#: 12429 S9/Utilities
    27-Sep-91  21:17:26
Sb: #12425-MS-DOS ARC/ZIP
Fm: Erich Schulman 75140,3175
To: edward langenback 73510,145

Thanks, I'll be looking for it.

#: 12431 S9/Utilities
    27-Sep-91  22:04:16
Sb: #12422-MS-DOS ARC/ZIP
Fm: James Jones 76257,562
To: Erich Schulman 75140,3175

Yes, there are programs that will extract at least some versions of MS-DOS
ARC files.  Nothing to create .ZIP files, though; somebody made a program
available to extract stuff from them, but nobody's done the same for a program
to create them.  A group of people is working on a reverseengineered ZIP
program, and I expect that once it's done, people will port it to OS-9.

#: 12426 S5/OS9 Users Group
    27-Sep-91  17:10:00
Sb: #UGSpell Checker
Fm: Mike Haaland 72300,1433
To: Sysop (X)

Can you upload the UG Spell cheker to lib 5 please...

Mike

There are 2 Replies.

#: 12432 S5/OS9 Users Group
    28-Sep-91  04:50:30
Sb: #12426-UGSpell Checker
Fm: Mike Ward 76703,2013
To: Mike Haaland 72300,1433 (X)

If I have it here I'd be happy to. Can you give me some clues as to what file
name(s) it might be lurking under?




#: 12433 S5/OS9 Users Group
    28-Sep-91  05:19:15
Sb: #12426-#UGSpell Checker
Fm: Mike Ward 76703,2013
To: Mike Haaland 72300,1433 (X)

But wait.... did you mean the spell checker for 68K? On the off-chance that
this is the case, I'm uploading SPEL68.AR to Lib 5 here in a moment.




There is 1 Reply.

#: 12437 S5/OS9 Users Group
    28-Sep-91  12:24:41
Sb: #12433-UGSpell Checker
Fm: Mike Haaland 72300,1433
To: Mike Ward 76703,2013

Thanks Mike,  I think that's the one.  I couldn't remember the name of the
file.  SPEL68.AR is the correct one.  Thanks again.

#: 12435 S1/General Interest
    28-Sep-91  10:56:20
Sb: FILE FINDER
Fm: JOERG SATTLER 74016,631
To: ALL

Barring the intro of a File Finder forum selection for OS9 I wonder if it would
be to much trouble to introduce a across the libraries search and find program
similar to the one just recently introduced in the UNIX forum. It would
practically do the same thing as a file finder type forum but probably be a lot
cheaper to implement. Is there reasonable chance for that in the near future
???. I certainly hope so since trying to  find any one specific file or even
only a type of file based on a keyword is nearly impossible unless you know
exactly which library it's in, and even then it's not easy unless you know the
that was used when it was stored.      Joerg Sattler

Press <CR> !>