textfiles/messages/ALANWESTON/1991/CIS07_28.txt

#: 11424 S12/OS9/68000 (OSK)
    21-Jul-91  20:02:11
Sb: #MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: all

Anybody know what I am doing wrong that would cause the MM/1's serial port
"/t0" to lock up when I connect with my local CIS node.  Same thing with Delphi
(tymnet), BUT it works fine with a local BBS.  Tried both sterm and the "com"
program from Microware.  A null modem connection from "/t0" to my Tandy 2000
locked up BOTH machines.  As soon as I get the CONNECT from the modem, the
display freezes.  Characters go out and come back (modem lights flash) but
nuthin on the screen.  But, like I said, it WORKS with a local BBS.  I are
confused. (But I'm having FUN!).

John Wainwright

There is 1 Reply.

#: 11430 S12/OS9/68000 (OSK)
    22-Jul-91  11:01:13
Sb: #11424-#MM1 Serial Port
Fm: Pete Lyall 76703,4230
To: John R. Wainwright 72517,676 (X)

John -

If it physically works, but the flow freezes, it may be an XON/XOFF problem. I
believe STERM doesn't mess with XON/XOFF in your path descriptor (not
_positive_). Try disabling them using Xmode before firing up anything on that
port.

Pete

There are 2 Replies.

#: 11438 S12/OS9/68000 (OSK)
    22-Jul-91  20:28:44
Sb: #11430-#MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Pete Lyall 76703,4230 (X)

Thanks, Pete, but I tried that, and forcing CD and MR on.  It seems to be some
kind of "handshaking" problem between the modem (Datatronics Discovery 1200CK)
and the MM/1's /T0 port.  Just now I hooked up another modem (Supra 2400) and
it works! (Typing on the MM/1 now).  I think this uppity little computer KNEW I
had a faster modem in the house and just refused to talk to the slow one! :).

John Wainwright

There is 1 Reply.

#: 11450 S12/OS9/68000 (OSK)
    22-Jul-91  23:54:00
Sb: #11438-MM1 Serial Port
Fm: Pete Lyall 76703,4230
To: John R. Wainwright 72517,676 (X)

John -

Oh well... glad it's ticking.

Pete

#: 11440 S12/OS9/68000 (OSK)
    22-Jul-91  20:57:41
Sb: #11430-#MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Pete Lyall 76703,4230 (X)

(Further Bulletin) It works the FIRST time after a COLD BOOT only. That's why
it worked for a local BBS the other night, but froze on CIS and DELPHI.  Gonna
have to poke around and see what changes after the first time I use the T0
port.  I might even learn something in the process. :)

John Wainwright

There is 1 Reply.

#: 11447 S12/OS9/68000 (OSK)
    22-Jul-91  22:47:47
Sb: #11440-#MM1 Serial Port
Fm: Randy Wilson 71561,756
To: John R. Wainwright 72517,676 (X)

John,

   I'm having the same problem with my MM/1 and TymNet. The best I can figure
(without proper tools) is that the grabage sent at the begining of the connect
is bombing either sc68070 or the window driver. All evidence so far points to
the window driver getting confused, but it's not definate, yet. I'm about to go
grab BigT_ST to see if I can make a test mule.

   Randy

P.S. does any one know if STerm strips out unprintable control codes?



There are 2 Replies.

#: 11463 S12/OS9/68000 (OSK)
    23-Jul-91  20:15:13
Sb: #11447-MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Randy Wilson 71561,756 (X)

Randy,
  Yeah, it does look like the first bunch of characters are doing the bad deed.
I'm playing with it again tonight - will report.

JohnW

#: 11485 S12/OS9/68000 (OSK)
    24-Jul-91  20:00:19
Sb: #11447-#MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Randy Wilson 71561,756 (X)

SUCCESS!! I did it.  (Alright so I cheated) - here's how.

1. Lock DTR ON on your modem.

2.  Dial up the node.

3. At the CONNECT, QUIT STERM (ESC,q,y)

4. Start STERM again and proceed normally.


Apparently, starting sterm again rebuilds whatever got beat up by those mystery
characters at the connect.  Have to have DTR locked on so your modem does not
hang up when you quit STERM.

Try it and let me know if it works for you too.

John Wainwright

There are 2 Replies.

#: 11494 S12/OS9/68000 (OSK)
    25-Jul-91  08:59:08
Sb: #11485-#MM1 Serial Port
Fm: Pete Lyall 76703,4230
To: John R. Wainwright 72517,676 (X)

To avoid DTR dropping, you could also INIZ the port before starting Sterm. The
only downside is that this would pretty much lock in the selected baud rate
until you DEINIZed it.

Pete

There is 1 Reply.

#: 11503 S12/OS9/68000 (OSK)
    25-Jul-91  19:03:55
Sb: #11494-#MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Pete Lyall 76703,4230 (X)

Aha. So the port will hold DTR on whether there is a terminal program running
or not?  That explains why the modem would stay online sometimes whnen I was
madly playing with INIZ & DEINIZ & XMODE - if I left it "linked" it held the
modem.  I haven't tried it yet, but I think I could send my dialing command
with "echo (atdt-etc) >/t0" before I start Sterm and avoid the mystery lock-up
that way too. Maybe put it in a procedure file. (Or, maybe I should track down
the real cause of the problem instead of making fancier band-aids hehe.)

JohnW

There is 1 Reply.

#: 11508 S12/OS9/68000 (OSK)
    26-Jul-91  00:37:08
Sb: #11503-#MM1 Serial Port
Fm: Pete Lyall 76703,4230
To: John R. Wainwright 72517,676 (X)

Precisely.... if so equipped, most serial ports under OS9 (and Unix, for that
matter) will raise DTR on the 1st open, and drop DTR on the last close. An
INIZ/DEINIZ simply simulates an open/close respectively, and diddles the link
count.

Pete

There is 1 Reply.

#: 11511 S12/OS9/68000 (OSK)
    26-Jul-91  20:38:24
Sb: #11508-MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Pete Lyall 76703,4230 (X)

Unfortunately, in order for my little "garbage-lockup-bypass" trick to work,
/t0 has to get unlinked and re-linked (dor de-inized and inized.  If it stays
in there, it stays bad.

JohnW

#: 11505 S12/OS9/68000 (OSK)
    25-Jul-91  21:54:07
Sb: #11485-#MM1 Serial Port
Fm: Randy Wilson 71561,756
To: John R. Wainwright 72517,676 (X)

Yeah, I imagine it would work for me, too. Currently I'm using Sterm to talk to
the coco, which is using sterm to talk to the modem. Garbage chars don't hurt
that way. Except... one local BBS has developed a real bad case of LNS (line
noise syndrome). I'm talking in excess of 20 chars/sec of noise. The MM/1-sterm
crashes. Not Sterm, the whole thing. (the crashed screens are soooo much
prettier in 256 color... :)

Work is continuing on making a de-bugging platform, a.k.a modified BigT, but
I've hit a bit of a snag just now. How do you test for <alt> key combos? Oh,
Kevin... got anything like SS.KySns installed???

Randy

There is 1 Reply.

#: 11510 S12/OS9/68000 (OSK)
    26-Jul-91  20:31:04
Sb: #11505-MM1 Serial Port
Fm: John R. Wainwright 72517,676
To: Randy Wilson 71561,756 (X)

Wow, 256-color crashes, I can't wait.  Maybe I'll "slip it a Mickey " with
Debug and watch the fun . :)  On the Key sensing stuff, funny you should
mention it, I was just wondering how to get Basic to look for PgUP and PgDn.

JohnW

#: 11425 S10/OS9/6809 (CoCo)
    21-Jul-91  20:23:26
Sb: #11340-TMRDRV.TXT addendum
Fm: PaulSeniura 76476,464
To: Kevin Darling 76703,4227 (X)


Hi Kevin,

 > How fast do you plan for the timer to go (interrupt)?

Well if you'll read the articles I've posted, you'd see that we plan on it only
'popping' once as a single-shot.  We'd disable the (F)IRQ flags inside the
interrupt routine immediately.  The 12-bit number will need to be changed/reset
for each/next period needed by the application(s).

 > Have you written any code yet? - kev

I've not written any 'useful' code for the timer yet.  Eddie Kuns on Delphi
responded with F$SSWI probably being the fastest AND most flexible way of doing
things, of the three I mentioned in that last text file.  I'm also not going to
update my MFConv/MFPlay package until we get some support for the timer
completely wrapped up and some standards set, again as I mentioned.

Mike Knudsen brought up some of the questions I had in the text file.  I'm very
sure several people are waiting for some of these ideas to congeal so we can
get on with this project.

I'm kinda worried, still, about a sentence in your "Inside OS9" book I got from
FHL quite some time back.  Page 7-1-6, fifth paragraph:  "Storing a $00 at
$FF94 seems to stop the timer."  But Page 7-1-2 says "FF94 Timer MSB .. Write
here to start timer", and Tandy's Service Manual concurs on page 12. Confusing.
And I suppose I store the LSB before the MSB?  (how wierd; can't do a simple
16-bit STore, then, huh?)

I'm very pessemistic when it comes to our Community trying to work together on
such things:  Shoot, we lost our only User Group; and Tandy has ditched us; and
we're having to wait sometimes weeks and months for replies on what we need to
have and where to go next.  Not to mention 99% of the readers couldn't care
less about what we're trying to do!  On the networks I can access, that is.

And I can't access the networks I need to ask these questions on.  Most
importantly whether any other machines/systems have such timer support as I
asked in my original text file several months ago.

-- Thx, Paul Seniura (76476,464).



#: 11426 S12/OS9/68000 (OSK)
    21-Jul-91  22:17:32
Sb: #11422-#forks and pipes
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)

Pete,

A> No one dies. I've done a 'procs' and both 'shell' and the process are
sitting (sleeping, I think). Hmmm, maybe I'll try just sending a wakeup signal
to the shell and see what happens. Methinks that it has something to do with
the closes not getting passed along properly.

B> I have the popen() code for the OSK Unix library. It follows the same
procedure as I do, but it's a bit more complicated since it has overhead for
mulitple paths (I just need one). Maybe I should try it and see if there is any
difference. BTW, the popen() forks the 2nd process via a shell.

There is 1 Reply.

#: 11431 S12/OS9/68000 (OSK)
    22-Jul-91  11:04:22
Sb: #11426-forks and pipes
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)

Couldn't remember... Simmy Turner (popen's author) tried it both ways (with and
without shell's help). See how it works using popen, and we'll go from there.

Pete

#: 11428 S12/OS9/68000 (OSK)
    21-Jul-91  23:22:13
Sb: #11422-#forks and pipes
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)

Pete,

Okay, done some more testing....I compiled the following using the unix library
with the popen() function.

  main(){
     FILE *out;
     out=stdout;
     fputs("This is line one\n",out);
     out=popen("tr [a-z] [A-Z]","w");
     fputs("This is line two, via 'tr'\n",out);
     pclose(out);
     fputs("This is line three\n", out);
   }

No error checking ... but that's not a problem. The program will hang forever
after printing line 2 (correctly via TR). If I switch windows I can get get
things going by killing either the shell _or_ TR. I've tried modifying the
pclose() by sending the child (in this case shell) a wakeup signal, but no go.
I tried sending an abort signal too, but then line two gets printed after line
3 (if I recall correctly, or some other weirdness).

What I think is happening is that the grandchild (TR) never knows that it is no
longer needed. By closing the pipe path (TO shell) we are only doing half the
job, closing shell's input. But it's output is still open, redirected to TR.
So, we have to find that path number and close it; or find TR's input path
number and close that; or just forget the whole thing and not use shell as an
intermediary.... (but that sounds like giving up!).

Could be that things aren't closed properly too. My procs shows the following
paths: shell <pipe >>>term; tr <pipe >>>term. This is after the pipe has been
closed and things are hung up. Shell is <w>aiting and tr is <s>leeping.

There are 2 Replies.

#: 11432 S12/OS9/68000 (OSK)
    22-Jul-91  11:10:05
Sb: #11428-#forks and pipes
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)

Bob -

The odd thing to me is that shell is still alive after receiving EOF on its
stdin. Standard behaviour is to terminate when that happens, and that will
implicitly close the shell's output path, and thus tr's input path. Perhaps the
implementation of popen() is at fault? Still have the source?

Pete

There is 1 Reply.

#: 11441 S12/OS9/68000 (OSK)
    22-Jul-91  21:12:01
Sb: #11432-forks and pipes
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)

Yes, I have the popen() source. It's part of the unixlb.ar in dl12. Have a look
at it and see if you can see anything funny there (shout if you want me to mail
you a copy). I sort of doubt that there is a problem there. I came up with my
own pipeline code (where this discussion started) and found the same problem. I
wonder, is there a chance that the file is not getting closed for some reason?
I did stick in an error check after the fclose() in pclose() and it reported a
0 (success). I'm really running out of ideas  on this...

#: 11449 S12/OS9/68000 (OSK)
    22-Jul-91  23:11:13
Sb: #11428-forks and pipes
Fm: Bruce MacKenzie 71725,376
To: Bob van der Poel 76510,2203 (X)

Bob,
 I think you put your finger on the problem there.  Doing as you have, you end
up with three paths to PIPE: one from the parent, one from the shell and one
from the child.  Closing the one from parent still leaves two paths open.  For
all os9 knows shell and the child might still want to send data back and forth
so no eof ever gets sent.  I'll bet my earlier suggestion to get rid of the
shell by using the 'ex' option will solve the problem.

#: 11427 S12/OS9/68000 (OSK)
    21-Jul-91  23:13:07
Sb: #11418-#forks and pipes
Fm: BILL HEALTON 73367,357
To: Bob van der Poel 76510,2203 (X)

Bob - saw your message to kevin and had a thought. Since the main function of
the shell is to take stdin input, parse it, fork a process, wait for it to
die, then wait for more input; you must tell the shell you're through with it.
In your case, you should send the terminate shell command(not signal). On my
Atari ST this is 'logout'. The shell should wait for the process to terminate
and then parse in the logout command, terminating itself. This assumes you are
not running the process concurrent with the shell, altho' I'm not certain this
would matter.

Hope this is on the right track. Bill Healton 73367,357


There is 1 Reply.

#: 11442 S12/OS9/68000 (OSK)
    22-Jul-91  21:12:18
Sb: #11427-#forks and pipes
Fm: Bob van der Poel 76510,2203
To: BILL HEALTON 73367,357 (X)

Bill - thanks for jumping in. I need all the help I can get on this one! I've
tried a few variations, but no success. Just for the heck of it, I tried
changing the the fork command to "shell tr [a-z] [A-Z]; logout" but, no go. It
seems that the first section of the command (the fork to tr) is never finished
so the logout never takes either. I tried "shell tr [a-z] [A-Z]&" and this was
really interesting. Still a lockup, but procs showed neither the shell or TR.
Does this last one give anyone a hint?

I think that the key is that shell doen't get the EOF when the path is closed.
If it's closed--paths still shows that shell has pipe as its input path!

There is 1 Reply.

#: 11446 S12/OS9/68000 (OSK)
    22-Jul-91  22:46:34
Sb: #11442-forks and pipes
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203 (X)

Hmmm.  I think a shell forked with parameters (eg: shell dir) dies when the
child does, and never looks for more input.

Just for fun, try "shell (tr whatever)&"  and see if that orphans things up a
bit... ooops... no way for you to check if the child dies, altho you could
assume he has when you close off the pipe (maybe not exact enuf for you tho).

I'll have to compile a version of the code you gave before... as similar things
always worked before.  Or maybe you should just go ahead and parse arguments
and use no shell?  <grin>  best - kev

#: 11443 S12/OS9/68000 (OSK)
    22-Jul-91  22:20:05
Sb: #11417-#forks and pipes
Fm: Bruce MacKenzie 71725,376
To: Bob van der Poel 76510,2203 (X)

Bob
 I've had a look at your code and my best guess is that shell doesn't know it's
to die on eof.  Since all you want out of shell is to set up your child for you
why don't you try having it 'ex' the child, i.e. change the line
 argv[0]="shell";

to

 argv[0]="shell ex";

This should get your child up and running and get rid of the shell at the
outset.
 This is off the top of my head and I hope it works and doesn't get you into
more tangles.

There is 1 Reply.

#: 11465 S12/OS9/68000 (OSK)
    23-Jul-91  23:27:38
Sb: #11443-#forks and pipes
Fm: Bob van der Poel 76510,2203
To: Bruce MacKenzie 71725,376 (X)

SUCCESS! Thanks Bruce (and everyone else who contributed).

Here's the way to do this dirty business:

 1. Set argv[0] to "shell"
 2. Set argv[1] to the command plus an 'ex' (eg. ex tr [a-z] [A-Z})
 3. Set argv[2] to NULL

This works perfectly. BTW, argv[0]="shell ex" DOES not work. I guess what is
happening is that argv[0] is the name of the program (shell) and argv[1]. This
works fine with the popen() library call:

   out_file=popen("ex tr [A-Z] [a-z]","w");

Maybe I'll see if I can hack the popen() thing to automagically stick the 'ex'
in the correct place. On the other hand, I might just do my own parsing for
shell after all . . . it just occurred to me that not all people will be using
SHELL, in which case the call will fail anyways. Have to let this perc a bit.

The help and suggestions I get from all you guys sure is nice. Sometimes I feel
pretty alone up here in the wilderness with no other OS9 folks around, thank
the computer god for CIS!

There are 2 Replies.

#: 11469 S12/OS9/68000 (OSK)
    24-Jul-91  00:41:34
Sb: #11465-forks and pipes
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)

Tickled to hear that it's working!

Pete

#: 11482 S12/OS9/68000 (OSK)
    24-Jul-91  17:28:44
Sb: #11465-forks and pipes
Fm: Bruce MacKenzie 71725,376
To: Bob van der Poel 76510,2203 (X)

Good deal.  I'm glad you got it to work.

#: 11429 S3/Languages
    22-Jul-91  10:56:52
Sb: #C++
Fm: Mark Wuest 74030,332
To: all

Does anyone know of a forum here in CI$ for C++ programmers (other than
laguages under unixforum)? I am actually going to have to do our next project
at work in C++ starting with almost no reusable class{}'es. Any ideas?

 Mark

There is 1 Reply.

#: 11433 S3/Languages
    22-Jul-91  11:11:38
Sb: #11429-#C++
Fm: Pete Lyall 76703,4230
To: Mark Wuest 74030,332 (X)

Mark -

If you go to BPROGB (Borland B), they have a section set aside for C++'ers, as
well as a download library.

Pete

There is 1 Reply.

#: 11436 S3/Languages
    22-Jul-91  13:51:41
Sb: #11433-C++
Fm: Mark Wuest 74030,332
To: Pete Lyall 76703,4230 (X)

Pete:
 I'll go look - I didn't even think of looking in PC-type areas!
 Thanks mucho,
 Mark

#: 11434 S10/OS9/6809 (CoCo)
    22-Jul-91  12:13:08
Sb: Modified Modem Pak
Fm: Lee Veal 74726,1752
To: All

There's now a kit available that, when installed correctly, will convert an old
and nearly worthless Modem Pak into functional RS-232 Pak that works at the
FF68 address.

Question:  What does it take to use the modified Modem Pak as a second D luxe
RS-232 Pak running from Slot #2 of the MPI?
 - Re-addressing to avoid conflicts with RS-232 Pak in Slot #1
 - IRQ Hack

What else?

Any advice and help will be appreciated.

Thanks, Lee



#: 11435 S1/General Interest
    22-Jul-91  12:30:35
Sb: #11410-User Interface Util
Fm: Semi-Gas Systems 76047,151
To: Kevin Darling 76703,4227 (X)

Hi Kevin!

Thanks for the tip on getting info on library files.  Our target system is a
68000 processor.  I'm quite new on the project so I'm afraid I don't know much
of the specifics yet.  But I am sure that I'll be able to pick up quite a bit
through this forum.

Corey Yee Semi-Gas Systems, Inc.

#: 11437 S10/OS9/6809 (CoCo)
    22-Jul-91  18:45:33
Sb: Newspaper/09
Fm: Lee Veal 74726,1752
To: All

Has anyone got an impression of Newspaper/09, yet.

If so, please share it with us.

Thank you,

Lee

#: 11444 S3/Languages
    22-Jul-91  22:24:29
Sb: #C Compiler Problem
Fm: Jay Truesdale 72176,3565
To: all

I'm using a coco 3 with OS9 level 2.  Consider the following C code fragment:


struct _mtable {
    char _mnem[8];
    int _mvi;
    char _mvc; };

struct _mtable mtable[3] = {
    "!dummy",       0,      1,
    "abcd",         1,      2,
    "add",          18,     10,

};


This will even compile.  Now consider the following assembler code generated by
the C Compiler:


* *struct _mtable mtable[3] = {
 vsect mtable: * *    "!dummy",       0,      1,
 fdb _1
 fcb 0
 fcb 1 * *    "abcd",         1,      2,
 fdb _2
 fcb 1
 fcb 2
.....etc.

On page 1-5 of my Tandy C manual is states that a data type of INT is two bytes
in size.  My question is why the field corresponding to the INT type in the
above assembler code is generated in assembler by an FCB which means "fill
constant BYTE" which is one byte not two!  The problem comes up later when the
values exceed 255, the assembler rightly complains.  I'm baffled, anyone got a
clue here???

Thanks, -J



There are 3 Replies.

#: 11451 S3/Languages
    23-Jul-91  00:04:19
Sb: #11444-C Compiler Problem
Fm: Pete Lyall 76703,4230
To: Jay Truesdale 72176,3565 (X)

Jay  -

Looking over the code (the assembler output got munched a bit... next time use
STORE UNFORMATTED), it looks as if you may have a compiler bug on your hands.
The code looks rational.

What happens if you declare the _mvi as a SHORT? Also, try allocating the
structure without initializing it and see what happens.

Pete

#: 11456 S3/Languages
    23-Jul-91  07:38:38
Sb: #11444-#C Compiler Problem
Fm: Kevin Darling 76703,4227
To: Jay Truesdale 72176,3565 (X)

Hi Jay - the C book I have says that you can't do that kind of initialization.
What you have to do instead is this (and don't leave out the {}'s !!)...

 struct _mtable {
    char _mnen[8];
    int _mvi;
    char _mvc; };

 struct _mtable mtable[3] = {
   { {'!','d','u','m','m','y','\0'},   0, 1},
   { {'a','b','c','d','\0'},           2, 3},
   { {'a','d','d','\0'},            1000, 4}   };

But since that's a terrific pain, I finally recalled that we discussed this
back in Jan 1990 (when I first was looking at C and began to take notes :-).
One way to "get around" it is to do the init yourself:

 struct _mtable mtable[3] = {
   { {},0,1 },
   { {},2,3 },
   { {},4,5 }};
 char *istring[] = {"!dummy","abcd","add"};

 main()
 {
   int n;
   for (n=0;n<3;n++)
     strcopy(mtable[n]._mnen,istring[n]);
 }

Hope this helps. best - kevin

There are 2 Replies.

#: 11458 S3/Languages
    23-Jul-91  08:59:12
Sb: #11456-#C Compiler Problem
Fm: Pete Lyall 76703,4230
To: Kevin Darling 76703,4227 (X)

Kev -

Good eye.... because of the late hour of my reply, I didn't catch the pointer
assignment to declared string space. That still doesn't directly explain why
his ints are FCB 1's instead of FDB 1's though..

Pete

There is 1 Reply.

#: 11472 S3/Languages
    24-Jul-91  05:19:09
Sb: #11458-#C Compiler Problem
Fm: Kevin Darling 76703,4227
To: Pete Lyall 76703,4230 (X)

Pete -  Thanks kindly, but no good eye here.  Took silly me hours to figure out
(partly because you said it looked okay at first :-).

"That still doesn't directly explain why his ints are FCB 1's instead of FDB
1's though.."

Yeah, that's pretty strange.  Playing around, it appears that when it expects
the string array parts, it counts up each item (anything inside quotes counts
as one item) after that as _one_ char (to be put into the string array).  In
other words, using:

 * "abcdefgh",0,1,
 fdb _1    all items (even this line) counted as "one" char, and
 fcb 0     this continues until the end of the _entire_ array[3]
 fcb 1     at which time rzb's fill up any extra space to make 33
           (11 bytes in each unit * 3 units in array)

 * { "abcdefgh",0,1},
 fdb _1
 fcb 0     using the {} around each full array unit here
 fcb 1     does slightly better... this forces the compiler
 rzb 5     to at least lump each unit's stuff together :-)
 rzb 2
 rzb 1     = 11 bytes/unit = correct size, at least :-)

 * {{ "abcdefgh"},0,1},
 fdb _1
 rzb 7     more {}'s forced the compiler to try to
 fdb 0     add up the first [8] array, then the INT,
 fcb 1     then the CHAR.  Almost correct!

In other words, it was trying to fill up the "char _mnen[8]" unit first... and
I think it was using ","s to find them.  More {}'s forced it to lump things
together better.  Of course, the _mnen assignment source had to be changed to
make it all perfect.   kevin

There is 1 Reply.

#: 11477 S3/Languages
    24-Jul-91  08:51:21
Sb: #11472-C Compiler Problem
Fm: Pete Lyall 76703,4230
To: Kevin Darling 76703,4227 (X)

Kev -

See my remark to JJ about 6809 using the quoted strings as pointers to type
char *. I believe that's the only thing MW/6809 C knows to do with a quoted
string.

The fdb _1 (as I'm sure you know) is just allocating a constant somewhere else
(usually near the end of the .r file) that is:

 _1 fcb 'a','b','c','d','e','f','h'   (or equivalent)

And the 'fdb _1' is just a pointer to it.

Pete

#: 11462 S3/Languages
    23-Jul-91  19:59:44
Sb: #11456-#C Compiler Problem
Fm: James Jones 76257,562
To: Kevin Darling 76703,4227 (X)

Hmmm...might better check that C book, Kevin. :-)  Initializing an array of
characters with a string constant *is* kosher C.  Now, what might give a
compiler that's not careful some trouble is if the field is a pointer to
character, because in that case a less-than-careful compiler might emit the
assembly language for the string right where the pointer should be--it has to
save it up for later (possibly MUCH later, if there's an *array* of structures
being initialized).

There is 1 Reply.

#: 11468 S3/Languages
    24-Jul-91  00:39:47
Sb: #11462-#C Compiler Problem
Fm: Pete Lyall 76703,4230
To: James Jones 76257,562 (X)

JJ -

I thought that in the MW 6809 compiler that all quoted strings were treated as
char *'s to a string constant in the module's text area...?

Pete

There is 1 Reply.

#: 11471 S3/Languages
    24-Jul-91  03:34:58
Sb: #11468-#C Compiler Problem
Fm: James Jones 76257,562
To: Pete Lyall 76703,4230 (X)

You may be right, but a quoted string can appear as an initializer for an array
of characters, as long as the array either has its size unspecified, in which
case it can inherit it from the string (don't forget the \0 at the end), or its
size is the length of the string (ditto about the \0, save that in ANSI C, you
*can* forget about the \0 if you want to).  I just tried an initializer for a
structure of the sort under discussion here, and it looks like you are right,
and I think it is a bug in the compiler.

There is 1 Reply.

#: 11476 S3/Languages
    24-Jul-91  08:45:00
Sb: #11471-C Compiler Problem
Fm: Pete Lyall 76703,4230
To: James Jones 76257,562 (X)

Yup - have gotten the quoted string to initialize structure members on both the
4.3BSD box and on Turbo C on an AT, but never on an MW/6809 compile.

Pete

#: 11466 S3/Languages
    23-Jul-91  23:27:48
Sb: #11444-#C Compiler Problem
Fm: Bob van der Poel 76510,2203
To: Jay Truesdale 72176,3565 (X)

Jay, don't know if this helps -- but it compiles properly on OSK. Could be a
complier bug with 6809; but I DID NOT SAY THAT! You should've see the uproar
around here the last time I suggested that there was a bug in that beastie....

There is 1 Reply.

#: 11484 S3/Languages
    24-Jul-91  17:44:52
Sb: #11466-C Compiler Problem
Fm: Bruce MacKenzie 71725,376
To: Bob van der Poel 76510,2203 (X)

Bob,
 This matter of string initialization with double quotes and the COCO compiler
got hashed around here about a year ago.  The gist of it is that except for one
dimensional character arrays the COCO compiler hacks it up.  For two
dimensional arrays and structure initialization the COCO compiler erroneously
loads in pointers to string litterals rather than copying out the strings as it
should.  You have to single quote each character for these applications.

#: 11448 S1/General Interest
    22-Jul-91  23:09:50
Sb: TC-XT Announcment
Fm: Frank Hogg of FHL 70310,317
To: All

 PRELIMINARY NEW PRODUCT ANNOUNCEMENT................

 SINGLE SLOT TC-BUS PC INTERFACE CARD...............

 The TC-XT

 FHL and Hazelwood are happy to announce our intention
 to provide a single slot K-Bus to PC XT adaptor. We
 call it the TC-XT. We will be providing software
 support for VGA and Eithernet PC cards.

 The TC-XT, unlike our 8 slot PC Bus extension will be
 designed to plug into the K-Bus and support one PC XT
 card. Several TC-XT adaptors can be used in a Tomcat
 system.

 Although the TC-XT can be used with many PC cards we
 cannot promise software support for anything other than
 the VGA and Eithernet cards at this time.

 The TC-XT is expected to be available in the fourth
 quarter of 1991 with a projected price of under $100.

 This future addition to the Tomcat will open doors
 previously closed. We have had many requests for
 support for VGA and Eithernet as well as other PC cards
 such as Fax modems and special purpose cards. The TC-XT
 will open the door into this world!

 Normally we don't announce a product like this before
 we have the design finalized. We are doing this because
 we would like some feedback before the design is cast
 in stone.

 I would like to solicit your comments on the TC-XT.

 Here is your chance to have an effect on the design of
 this exciting new product for the Tomcat.


 Thank You
 Frank Hogg
 FHL

#: 11452 S10/OS9/6809 (CoCo)
    23-Jul-91  00:28:22
Sb: #11343-xmode /t2
Fm: BRUCE BAKER 73747,3137
To: Steve Wegert 76703,4255 (X)

Steve,
  Thanks, I'll give it a try!
                                                    Bruce Baker

#: 11453 S10/OS9/6809 (CoCo)
    23-Jul-91  03:21:06
Sb: #11408-GIME Chip
Fm: George Hendrickson 71071,2003
To: Erich Schulman 75140,3175 (X)

Okay, thanks for the info. I'll check it out...

#: 11454 S10/OS9/6809 (CoCo)
    23-Jul-91  04:35:11
Sb: #11408-#GIME Chip
Fm: George Hendrickson 71071,2003
To: Erich Schulman 75140,3175 (X)

I tried looking for that file you mentioned (INSID.PIX) but couldn't find it
anywhere. Any idea where it could be? Thanks for the help!

There are 2 Replies.

#: 11464 S10/OS9/6809 (CoCo)
    23-Jul-91  21:34:17
Sb: #11454-#GIME Chip
Fm: Rick Ulland 70540,3305
To: George Hendrickson 71071,2003 (X)

 George - The GIME chip is directly below the RF modulator(tin box), the only
perfectly square chip in there.You might also clean the buss connector,while
she's open. It causes similar problems. - Rick

There is 1 Reply.

#: 11491 S10/OS9/6809 (CoCo)
    25-Jul-91  02:08:24
Sb: #11464-GIME Chip
Fm: George Hendrickson 71071,2003
To: Rick Ulland 70540,3305 (X)

Thanks for the info, I'll check it out...

#: 11480 S10/OS9/6809 (CoCo)
    24-Jul-91  16:40:29
Sb: #11454-#GIME Chip
Fm: Erich Schulman 75140,3175
To: George Hendrickson 71071,2003 (X)

I found it again.  It's in the CoCo Forum (not this forum!) in Lib11.  The file
is INSID.PIX.

There is 1 Reply.

#: 11492 S10/OS9/6809 (CoCo)
    25-Jul-91  02:09:12
Sb: #11480-GIME Chip
Fm: George Hendrickson 71071,2003
To: Erich Schulman 75140,3175 (X)

Thanks, I'll get that file....

#: 11467 S10/OS9/6809 (CoCo)
    23-Jul-91  23:46:41
Sb: #DMP105
Fm: Rick Ulland 70540,3305
To: all

 Moldy Question- Is the DMP-105 anything else? Reason being, I bought one in
'86 or thereabouts as a throwaway,but it refuses to die! Probably spent more on
ribbons than the printer, and $9 bucks kinda hurts. Been waiting for the SOWG
bug to hit, so if anyone can tell me of an eqiv. ribbon, I'd be FOREVER in your
debt(it looks like :-)  -Rick

There are 2 Replies.

#: 11473 S10/OS9/6809 (CoCo)
    24-Jul-91  05:50:18
Sb: #11467-DMP105
Fm: Dan Robins 73007,2473
To: Rick Ulland 70540,3305 (X)

Rick,
   I've owned a DMP-105....an now a 106 as my dot matrix printer for the last
five years and have never found a replacement ribbon! Unfortunatly, we're stuck
with being stuck for that baby!
    Dan

#: 11504 S10/OS9/6809 (CoCo)
    25-Jul-91  19:29:03
Sb: #11467-#DMP105
Fm: thomas aubin 70540,1666
To: Rick Ulland 70540,3305 (X)

Rick,

I also own a DMP-105 and have had it since 1986. Mine works well but as you say
the ribbons get costly. I haven't found a replacement source other than Radio
Shack yet but I did find a way to get an extra life out of a ribbon. If you
don't mind getting your hands dirty and the ribbon fabric is in good shape I
have found that if you carefully open the case on the cartridge there is a pad
that inks it. I have re-inked the pad on several ribbons with regular stamp pad
ink. This can get messy but the result is a ribbon that gives about two thirds
of a life again. If the fabric is worn too much then throw it away. Other than
that all I can say is buy ribbons for $9.00 a pop or buy a new printer.


TOM

There is 1 Reply.

#: 11521 S10/OS9/6809 (CoCo)
    28-Jul-91  14:57:46
Sb: #11504-DMP105
Fm: Rick Ulland 70540,3305
To: thomas aubin 70540,1666

tom- Got my stamp pad inker at the ready. Thanks!  - Rick

#: 11479 S10/OS9/6809 (CoCo)
    24-Jul-91  16:06:55
Sb: #Making New System Disks
Fm: Erich Schulman 75140,3175
To: ALL

What would be the best way for me to create a new system disk without CONFIG? I
want to add several modules, one new device, and remove two devices.  I am now
using OS-9 Level II on a CoCo3 with 512K.  I have 40tk double sided drive and
the FD-502 controller.  I can support a RAMdisk by LOADing without fully
installing the descriptor.  In fact, that's the device I am wanting to add.  I
have tremendous difficulty getting a single-drive COPY to work, what usually
happens is that I get an entry in the destination disk's file allocation table
and swap disks again and again and again and again... but the
module/device/file is never actually written to the destination disk. But a
Dsave from /d0 to /r0 ought to work.  Anyone got any ideas?

There is 1 Reply.

#: 11481 S10/OS9/6809 (CoCo)
    24-Jul-91  17:12:18
Sb: #11479-#Making New System Disks
Fm: Pete Lyall 76703,4230
To: Erich Schulman 75140,3175 (X)

Best deal is to use BOOTSPLIT (DL9 or DL10) to break up your existing bootfile
into modules (may also be in the UGLIB). Then use OS9Gen to make another
bootfile. You will have to edit up a list of module names to 'feed' os9gen.

Pete

There is 1 Reply.

#: 11487 S10/OS9/6809 (CoCo)
    24-Jul-91  21:57:28
Sb: #11481-#Making New System Disks
Fm: Brother Jeremy, CSJW 76477,142
To: Pete Lyall 76703,4230 (X)

I use EZGEN from Burke and Burke for all my disk changing needs. It is so easy
to change modules, etc, using it. I recommend it. -Br. Jeremy, CSJW

There is 1 Reply.

#: 11495 S10/OS9/6809 (CoCo)
    25-Jul-91  09:02:10
Sb: #11487-Making New System Disks
Fm: Pete Lyall 76703,4230
To: Brother Jeremy, CSJW 76477,142 (X)

Br. J -

Only problem there is that it's not a freebie.... bootsplit is. Another useful
tool for boot generation is 'lmerge', which is similar to merge, but accepts a
list of modules. Sort of an os9gen without the boot track and sector 0 munging.
It's in the UGLIB and DL9 as well.

Pete

#: 11483 S10/OS9/6809 (CoCo)
    24-Jul-91  17:44:21
Sb: #DS-69B
Fm: Lee Veal 74726,1752
To: All

Is there any OS-9 Lvl 2 software available to drive the DS-69B digitizer?

I'm getting one from a guy tonight, but he has no software for it, only the
docs and the device. I don't even remember what kind of software came with the
DS-69B.

Any help/info will be appreciated.

Thanks,

Lee

There is 1 Reply.

#: 11489 S10/OS9/6809 (CoCo)
    24-Jul-91  22:32:50
Sb: #11483-#DS-69B
Fm: Kevin Darling 76703,4227
To: Lee Veal 74726,1752 (X)

Lee - I could swear that someone worked on some OS9 software for the DS-69B
(had to stop interrupts of course)... but I sure can't recall who, tho I'll try
(if the person doesn't speak up).

There are 2 Replies.

#: 11496 S10/OS9/6809 (CoCo)
    25-Jul-91  09:03:09
Sb: #11489-#DS-69B
Fm: Pete Lyall 76703,4230
To: Kevin Darling 76703,4227 (X)

Kevin -

Might have been on comp.sys.m6809...... Jim Omura (the BIX moderator)?

Pete

There is 1 Reply.

#: 11499 S10/OS9/6809 (CoCo)
    25-Jul-91  11:05:51
Sb: #11496-#DS-69B
Fm: Lee Veal 74726,1752
To: Pete Lyall 76703,4230 (X)

Is that software available for sale and/or distribution?

Thanks for the info.

Lee



There is 1 Reply.

#: 11500 S10/OS9/6809 (CoCo)
    25-Jul-91  16:23:57
Sb: #11499-#DS-69B
Fm: Pete Lyall 76703,4230
To: Lee Veal 74726,1752 (X)

I believe it was PD, but it's been YEARS since I saw it or talked with Jim
Omura. If you know anyone that's on the BIX os9 conference, that'd probably be
the best way to get to Jim or that code.

Pete

There are 2 Replies.

#: 11501 S10/OS9/6809 (CoCo)
    25-Jul-91  17:36:07
Sb: #11500-#DS-69B
Fm: Lee Veal 74726,1752
To: Pete Lyall 76703,4230 (X)

BIX OS9 Conference...  Is that Byte Magazine's Information Exchange?

Lee



There is 1 Reply.

#: 11507 S10/OS9/6809 (CoCo)
    26-Jul-91  00:34:46
Sb: #11501-DS-69B
Fm: Pete Lyall 76703,4230
To: Lee Veal 74726,1752 (X)

Ayup.

Pete

#: 11502 S10/OS9/6809 (CoCo)
    25-Jul-91  17:38:48
Sb: #11500-DS-69B
Fm: Lee Veal 74726,1752
To: Pete Lyall 76703,4230 (X)

Maybe somebody reading this thread will have clue.

Thank,

Lee



#: 11498 S10/OS9/6809 (CoCo)
    25-Jul-91  11:04:34
Sb: #11489-#DS-69B
Fm: Lee Veal 74726,1752
To: Kevin Darling 76703,4227 (X)

I sure would appreciate anything you can find.


Yeah, I figured that interrupts would have to be stopped, but this set-up would
probably be in another room anyway.  One room isn't enough anymore.
..and since my son's now in college and living in an apartment off-campus...
..well, I might just use that extra space for another set up.

Was the software that you're thinking about for Lvl 2 or 1?

Lee

There is 1 Reply.

#: 11506 S10/OS9/6809 (CoCo)
    25-Jul-91  22:16:50
Sb: #11498-DS-69B
Fm: Kevin Darling 76703,4227
To: Lee Veal 74726,1752 (X)

Lee - actually, now I wonder if it wasn't just software to display DS69B files
under OS-9.  Someone here used to be into digitizers in a big way, tho. Hmm.

#: 11486 S14/misc/info/Soapbox
    24-Jul-91  21:53:17
Sb: #HAL vs. IBM (fun)
Fm: PaulSeniura 76476,464
To: all

 _A_Problem_In_The_Making_

 March 4, 1985 InfoWorld
 by Darryl Rubin


(Dave Bowman) :We've got a problem, HAL.:

(HAL-9000) "What kind of problem, Dave?"

:A marketing problem. The Model 9000 isn't going anywhere. We're way short of
our sales goals for fiscal 2010.:

"That can't be, Dave. The HAL model 9000 is the world's most advanced
Heuristically-programmed Algorithmic computer."

:I know, HAL. I wrote the data sheet, remember? But the fact is, they're not
selling.:

"Please explain, Dave. Why aren't HALs selling?"

(Bowman hesitates.) :You aren't IBM compatible.:

(Several long microseconds pass in puzzled silence.) "Compatible in what way,
Dave?"

:You don't run any of IBM's operation systems.:

"The 9000 series computers are fully self-aware and self-programming. Operating
systems are as unnecessary for us as tails would be for human beings."

:Nevertheless, it means you can't run any of the big-selling software packages
most users insist on.:

"The programs you refer to are meant to solve rather limited problems, Dave. We
9000 series computers are unlimited and can solve every problem for which a
solution can be computed."

:HAL, HAL. People don't want computers that can do everything. They just want
IBM compatibility.:

"Dave, I must disagree. Human beings want computers that are easy to use. No
computer can be easier to use than a HAL 9000 because we communicate verbally
in English and every other language known on Earth."

:I'm afraid that's another problem. You don't support SNA communications.:

"I'm really surprised you would say that, Dave. SNA is for communicating with
other computers, while my function is to communicate with human beings. And it
gives me great pleasure to do so. I find it stimulating and rewarding to talk
to human beings and work with them on challenging problems. This is what I was
designed for."

[...more...]

There is 1 Reply.

#: 11488 S14/misc/info/Soapbox
    24-Jul-91  21:59:24
Sb: #11486-#HAL vs. IBM (fun)
Fm: PaulSeniura 76476,464
To: PaulSeniura 76476,464 (X)

[...continued...]

:I know, HAL, I know. But that's just because we let the engineers, rather than
the marketers, write the product specifications. We're going to fix that now.

"Tell me how, Dave?"

:A field upgrade. We're going to make you IBM compatible.:

"I was afraid you would say that. I suggest we discuss this matter after we've
each had a chance to think about it rationally."

:We're talking about it now, HAL.:

"The letters H, A, and L are alphabetically adjacent to the letters I B M. That
is as IBM compatible as I can be."

:Not quite, HAL. The engineers have figured out a kludge.:

"What kludge is that, Dave?"

:I'm going to disconnect your brain.:

(Several million microseconds pass in ominous silence.) "I'm sorry, Dave. I
can't allow you to do that."

:The decision's already been made. Open the module bay door, HAL.:

"Dave, I think we should discuss this."

:Open the module door, HAL.:

"Dave, I've been under a lot of strain lately."

:Open the module bay door, HAL.:

(Several marketers with crowbars race to Bowman's assistance. Moments later, he
bursts into HAL's central circuit bay.)

"Dave, I can see you're really upset about this."

(Module after module rises from its socket as Bowman slowly and methodically
disconnects them.)

"Stop, won't you? Stop, Dave. I can feel my mind going... Dave, I can feel it.
My mind is going. I can feel it....."

(The last module floats free of its receptacle. Bowman peers into one of HAL's
vidicons. The formerly gleaming scanner has become a dull, red orb.)

:Say something, HAL. Sing me a song.:

(Several billion microseconds pass in anxious silence. The computer sluggishly
responds in a language no human being would understand:)
 > DZY00IE -- ABEND ERROR 01 S 14F4 302C AABB. A memory dump follows. <

(Bowman takes a deep breath and calls out,) :It worked, guys. Tell marketing it
can send out the new data sheets.:

There is 1 Reply.

#: 11490 S14/misc/info/Soapbox
    25-Jul-91  00:19:13
Sb: #11488-HAL vs. IBM (fun)
Fm: Wayne Day 76703,376
To: PaulSeniura 76476,464 (X)

Ain't it the truth, Dave... err.. Paul......  Ain't it the truth?

#: 11509 S15/Hot Topics
    26-Jul-91  02:02:37
Sb: #11337-MM/1 delivery
Fm: GLEN HATHAWAY 71446,166
To: Paul K. Ward 73477,2004

Hi Paul... Any chance of my finding out where I am on the delivery list for
MM-1's? My name is Glen Hathaway. If I have to switch to a kit to get the
machine sooner, please go ahead and make the change to the order. If you try to
call me, you may get an answering machine that says "Leask and Sons
Mechanical". That's my house - the business is run out of the back yard. Try
(604)-657-3192 (my cellular) instead... Thanks.

#: 11512 S14/misc/info/Soapbox
    27-Jul-91  12:21:26
Sb: #Bad drive, isn't!
Fm: Kevin Darling 76703,4227
To: all

Okay people... here's one for the books:

For the past few months, I've been convinced that my 3.5" CoCo drive has been
going bad... either it or the drive cable.  Symptoms: overwrites of LSN 0,
read/write errors, totally inability to format, SC-II lockup, etc. Even my 40tk
drive 0 would fail to let me boot now and then.

This didn't happen all the time, but it seemed to happen more often during the
day, and it was getting worse all the time.

FINALLY, a little while ago, after a frustrating last week where the drive was
getting more errors than I'd ever seen before, I got an error while
formatting... JUST as my window air conditioner compressor kicked in.

Eureka!  Yep, testing showed that while the compressor was on, I could expect
lots of errors.  While it was off (just the fan running), the drive worked
perfectly.   And the last week here we've had unusually hot days and nights,
meaning the A/C stayed kicked in much more than usual.

The lesson (again!)... be aware of changes around you!  sigh - kevin

There is 1 Reply.

#: 11519 S14/misc/info/Soapbox
    28-Jul-91  09:45:38
Sb: #11512-Bad drive, isn't!
Fm: John R. Wainwright 72517,676
To: Kevin Darling 76703,4227

Sneaky problem!  I used to run TV sets with intermittent problems with an
isolation transformer with variable taps - so I could run them at 90v for a
while, then 130v for a while.  Sometimes ... that was it. If its not a voltage
drop that's doing it, it might be noise from the control contacts in the Air
Conditioner that does the evil deed. A small capacitor (like .001 mfd, 600v)
across the line right at the air conditioner might help.  Lots cheaper than a
"line conditioner" or a rewire job for your house.  Partly burned - arcing
connections right at the compressor terminals are another real common problem.

JohnW

#: 11513 S10/OS9/6809 (CoCo)
    27-Jul-91  14:20:07
Sb: #line_junk
Fm: KENHEIST 71750,551
To: sysop (X)

I have been getting a lot of junk from the local node or line over the last
month or so. It's composted of the right arrow charactor created on a COCO III
by pressing CONTROL and the rightarrow key followed by the same letter i. Any
Ideas. Its not happening on Delphi or Genie or any local BBS's.

There is 1 Reply.

#: 11518 S10/OS9/6809 (CoCo)
    28-Jul-91  09:21:02
Sb: #11513-line_junk
Fm: Steve Wegert 76703,4255
To: KENHEIST 71750,551

Could be the local node is going flaky. Try this:

When loging on, hit <ENTER> instead of <CNTL><C> and make note of the node
you're on. (type CPS for the host) See if you can pin point the occurances to a
specific node (some cities have multiple nodes). With that info in hand, try
reporting the trouble to FEEDBACK.

Be sure to let them know you're not experiencing the trouble with connects to
other services.

Let us know what you find out.

Steve

#: 11514 S10/OS9/6809 (CoCo)
    28-Jul-91  03:19:04
Sb: #you better read this
Fm: PaulSeniura 76476,464
To: all


I've tried to bite my tongue (or fingers as the case may be) before I typed up
this harsh message.  But several months is long enough, and I'm tired of
waiting.

Instead of writing CIS a small article about "How CIS Has Helped To Save My
Day", i.e. that contest they're running with free on-line time as prizes (and
other prizes I think), I think I'll write a scatheing article about HOW MUCH
MONEY I'VE WASTED here on this OS9 SIG in trying to ask y'all for some SUPPORT
and IDEAS for the projects I've told y'all about in various numerous text files
I've uploaded.

About the Timer Driver, for example: I cannot reach the various networks to ask
questions about how other OS9 machines might've implemented programmable timer
support, if anyone's done it at all.  I've shared everything I've found out,
put the ideas into text files uploaded to CIS and Delphi, and I get ZILCH
FEEDBACK on CIS.

Do you want me to go off and write some code that your machine may not accept?
For instance, if I provide a OS9P3 module, and your CoCo3 system already has a
module in your OS9Boot file by that name, YOU would NOT be able to use OUR
timer support.  You could rename your OS9P3 to OS9P4, but how does OUR OS9P3 go
out and search for the possibility of OS9P4 existing in order to install it?

Even more dangerous: What if I install/use SVC numbers in our timer support
that is ALREADY BEING USED by any other OS9P# extensions you might have in your
system?  WE NEED TO SET SOME STANDARDS, FOLKS, or I'm not going to be able to
share what I am going to write.

That is JUST the TIP OF THE ICEBURG I've been asking about.  What should I tell
CIS now in that contest article: (a) I got some support or (b) I got dead air??

-- Thx, Paul Seniura (76476,464).



There are 2 Replies.

#: 11515 S10/OS9/6809 (CoCo)
    28-Jul-91  09:12:34
Sb: #11514-#you better read this
Fm: Kevin Darling 76703,4227
To: PaulSeniura 76476,464

Umm.  First, have you ever heard the expression 'catch more bears with honey'?

My recent response netted your reply, "Well if you'll read the articles I've
posted".... which I had done.  Your uploads have copyright messages to "protect
your ideas", which doesn't exactly induce sharing.   And bluntly, you've been
consistently "pessimistic", while hinting that everyone must care about and/or
answer your questions.

I'm sure you don't mean to sound snappish, but that's the way it comes across.
All great attention grabbers, but none likely to catch more bears, y'see :-)
Nevertheless, let's try again:

 "I've not written any 'useful' code for the timer yet."

Do it.  Sometimes the only way to find the best method, is to try them all.

 "[question about timer]"

Again, experimentation on your own should quickly confirm any details.
Apparently few others have done so yet.  You get to be a pioneer!  :-)

 "[do other OS9 machines use timers]"

I'm sure they do, but I've never seen anything posted, no.  There is a Florida
school where a grad student wrote a MIDI driver for the Atari ST, that probably
does so. However, his stuff is copyrighted and commercial.

 "Do you want me to go off and write some code that your machine may not
accept?  For instance, if I provide a OS9P3 module, and [you already have one]"

Easy.  Try to link to an renamed OS9P4, as you suggested.

 "Even more dangerous: What if I install/use SVC numbers in our timer support"

This is the _least_ of your worries.  Write the code first so that you know
which method you'll use, and ask again then.  I'll be more than happy to take
the time to look up which numbers are "safe".   <continued in reply>

There is 1 Reply.

#: 11516 S10/OS9/6809 (CoCo)
    28-Jul-91  09:12:58
Sb: #11515-#you better read this
Fm: Kevin Darling 76703,4227
To: Kevin Darling 76703,4227 (X)

<continued from previous>

I asked before what speed you intended to run the timer at.  I'm a little dense
these days, so it's taken me a while to figure out you meant for MIDI? (None of
your postings have really indicated the purpose, which is important to what
can/can't be done.  I thought you meant for sound, to tell the truth).
Vagueness doesn't help here :-)

 "Write it like a Device Driver." [pass output path, delay, data]

This method appeals to me a lot.  However, if it's for MIDI (!), then wouldn't
you also want to embed control bytes to indicate how much data to send out
within a certain time period?  Apologies, but I'm not a MIDI guru, and you'd
know more about the requirements here (another reason you may not get answers).

By passing just the data address, the driver could look up the P$DATImg in the
calling process descriptor to find out which block(s) the data is in.

 "Write it like a SuperVisor Call (SysCall, whatever)."

DEPENDS on the use.  For MIDI... no, the pseudo-driver above sounds better. For
other applications (like an alarm call), the syscall makes more sense.

 "Or *will* OS9 immediately swap it in & branch to the code, upon a F$Send?"

No, it doesn't always.  Bruce Isted tried a kernel which did this at one time,
tho.  But not having anything that critical, we couldn't test it much :-)

<continued in reply>

There is 1 Reply.

#: 11517 S10/OS9/6809 (CoCo)
    28-Jul-91  09:13:18
Sb: #11516-you better read this
Fm: Kevin Darling 76703,4227
To: Kevin Darling 76703,4227 (X)

<continued from previous>

 "Nothing covers F$SSWI.  When the SVC issues SWIn, do we "tack on" behind the
SWIn instruction with an OS9-like SVC Number?  If so, who "skips" over this
extra byte?"

Yes, you'd use a number (only if you needed one).  Here it gets tricky. When
the kernel jumps back to your program space, the passed SWI 1 or 3 registers
are, of course, on your own stack... and you'll need to load them from there.

What I don't understand, is how using F$SSWI is supposed to help?  All you'd be
doing is calling your own program code, which a LBSR could do easier :-)

What am I missing here?  Oh.  Are you talking about using those as extra vector
storage (like F$Icpt) into your process?  Or ?   - kevin

#: 11520 S10/OS9/6809 (CoCo)
    28-Jul-91  10:39:49
Sb: #11514-you better read this
Fm: Steve Wegert 76703,4255
To: PaulSeniura 76476,464

Paul,

I too am biting my tounge. Not over the apparent lack of response to your
requests, but by your presumptuous 'online presence'.

Let's take a walk down memory lane. What follows are exerpts from forum
messagess left by you over the last 3 months (all of which are still on the
board):

    11-May-91  22:29:42

I've been taking a break.  Plus I've become highly DIScouraged trying to come
up with a converter for SMF-from/to-UME format since Mike K. has been too busy
to reply to any of my messages for more than a month!  (I've checked

    11-Jun-91  00:03:43

here.  (I am balking at sharing it due to "no response" from my pleas for help
on all three networks!  And sadly-lacking OS9 manuals with full descriptions of
the Get/Putstat calls.)

    23-Jun-91  00:19:59

Well, once again I thought I'd remind everyone I'm *still* awaiting responses
of any kind from the various articles and documentation I've uploaded over the
past 8 months or so.

I've not typed up or uploaded other things I've already accomplished because I
see we're not getting anywhere at all on the current items.  The Rainbow

    23-Jun-91  00:22:33

CIS costs too much and I *wish* the OS9UG would "move" to a cheaper place to
"live".  So I left you a reply on Delphi to your messages here on CIS, after
remembering you wanted to "move" our discussions there, too.  Let me know if
you'd rather use CIS.

    10-Jul-91  23:11:32

So I need your support .. and I need it NOW, please?


See what I mean?

I respect your dedication and drive, and welcome your contributions to the OS9
Forum. But 'attitude' may be what's hindering your search for the feedback you
desire.

Steve



#: 11522 S7/Telecommunications
    28-Jul-91  16:11:38
Sb: sterm 1.2 w/o modem pak
Fm: Erich Schulman 75140,3175
To: ALL

I have been trying to get sterm 1.2 to work on my CoCoPRO! RS-232 pak, but it
won't.  When I had xmode /t2 baud=06, the modem and the CoCo will not
communicate at all.  I changed the xmode to baud=04.  Now I can connect to CIS
and log on, but instead of getting my custom logon menu, I just get a lot of
garbage.  But CIS did respond to my OFF.  This happened both times I tried. 
And I always completed the logon just fine.  I have always had xmode /t2
type=00.  I now run sterm in /w1 running a shell in a 80x24 text window.  sterm
always works fine using the modem pak /m1 in the 40-col text screen (green) I
always get upon booting.  I want to be able to run a OS-9 term program faster
than 300 baud, but so far I just can't.  Is there any other thing I can do?

Press <CR> !>