#: 8592 S12/OS9/68000 (OSK)
    04-Dec-90  17:06:53
Sb: Atari-ST file transfer
Fm: Paul K. Ward 73477,2004
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kev,
I thinkg Brady has a com prog for ST under OSK.
Paul

#: 8829 S12/OS9/68000 (OSK)
    19-Dec-90  11:06:39
Sb: #uWare support user OSK?
Fm: Mike Passer 72750,420
To: All
Hello!
Does anyone know if Microware support for OS-9 68000 will apply to copies sold
with machines such as the MM/1 or TC-70 just the same as with their larger
customers?
Thanks, Mike Passer
There is 1 Reply.

#: 8833 S12/OS9/68000 (OSK)
    19-Dec-90  18:33:17
Sb: #8829-#uWare support user OSK?
Fm: Kevin Darling (UG Pres) 76703,4227
To: Mike Passer 72750,420 (X)
Mike - I'd think that MW support would apply only to the companies buying the
licenses... not to the end customers buying machines that come with OS-9.
This seems natural to me.  If a company licensed OS9 for a MIDI controller, for
example, I'd expect that they got the support... but not everyone who buys the
controller! <grin>
So you'd pass on any Q's etc to the dealer you got OS9 from, and they'd in turn
help you or ask MW.  Seem reasonable?  best - kev
There is 1 Reply.

#: 8834 S12/OS9/68000 (OSK)
    20-Dec-90  06:18:00
Sb: #8833-#uWare support user OSK?
Fm: Mike Passer 72750,420
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kevin,
Please see my message to you via EMail.  (In case you don't have mail waiting
enabled).
Mike
There is 1 Reply.

#: 8864 S12/OS9/68000 (OSK)
    23-Dec-90  10:04:30
Sb: #8834-#uWare support user OSK?
Fm: Bud Hamblen 72466,256
To: Mike Passer 72750,420 (X)
Mike,
You ought to be able to buy extended support from Microware.  You used to get
90 days of phone support from Microware with an OS-9 license and you'd buy
extended support for a fair outlay.
Bud
There is 1 Reply.

#: 8885 S12/OS9/68000 (OSK)
    25-Dec-90  14:19:59
Sb: #8864-uWare support user OSK?
Fm: MOTD Editor..Bill Brady 70126,267
To: Bud Hamblen 72466,256 (X)
But y'll can get support right *here*.

#: 8835 S12/OS9/68000 (OSK)
    20-Dec-90  20:37:00
Sb: MM/1
Fm: Ron Johnson 72330,3373
To: Paul Ward
Paul,
A few (lot of) questions...
Is the MM/1 shipping yet?  If not when?
How much does a plug-and-play system with monitor & hard drive cost?
Is there any APPLICATION software <<< FINISHED >>> for it yet? If you don't
know that off the top of your head, maybe you could post a list of ISVs on your
developers program.
Why hasn't anyone from IMS returned my phone calls for 3 weeks?  I've called
many times and never heard a peep from y'all.
Back to the applications, is anyone working on a WP and a spreadsheet... They
do not need to be integrated, but the ability of the S/S to read/write .DIF,
comma-seperated text, or Lotus files would be a BIG help.
Ron Johnson 72330,3373

#: 8845 S12/OS9/68000 (OSK)
    22-Dec-90  17:53:25
Sb: #OS9/ST on Atari TT
Fm: DENIS CHARTRAND 72561,2714
To: All
    Anyone was able to boot OS-9/ST v2.3 on the 68030 32 MHz equiped Atari TT?
On the 4M bytes model that I've tried, the TT crashs after STARTFD.PRG prompts
for "Insert OS9 Boot diskette and Press a key" a soon I touch the keyboard. Too
bad, the computer is very very fast and seems to be nice. No improvments even
if I ask for a ST compatible mode instead of the default TT mode. Maybe I
should try with older version of OSK, 2.2 or 1.2. But I don't think it will
help. Anyway, even if it works, drivers will have to be written for the
additional ports, like the two serial 85C30 SDLC ports, the 68882, the VME bus,
the SCSI connector, the LAN outlet, etc.
   Also the MS-DOS emulator PC-DITTO (software version) does not work. Others
TOS programs that were in the store (Calamus, etc) seems to work OK.
BYE
There is 1 Reply.

#: 8848 S12/OS9/68000 (OSK)
    22-Dec-90  20:12:56
Sb: #8845-OS9/ST on Atari TT
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Denis - I believe each of the 680x0 cpu family handles exceptions (what's put
on the stack) differently... which means you'd need a 68030 OS9 kernel, at
least (or most ;-).
Where'd you see the TT, btw?  Are you in Canada?

#: 8863 S12/OS9/68000 (OSK)
    23-Dec-90  09:35:28
Sb: #OS9/ST on Atari TT
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
    Hi, Kevin.
      Yes, I'm from Montreal. The TT computers can be seen here since around
early September in computers shows, but is available on market since this
month.
    In recent european magazines, Atari TT article reviews specified the
following hardware as standard in a plain TT computer:
 - 68030-33 used at 32MHz
 - 68882-33 used also at 32MHz
 - 8M bytes of RAM divided in two banks:
     - 4M bytes of ST compatible RAM, 80 nsec, 64 bits wide
     - 4M bytes of TT RAM, 100 nsec, 32 bits wide
 - TOS 3.0.1 (512K bytes of ROM)
 - 128K cartridge port, ST compatible
 - graphics resolution same as ST plus (palette of 4096 colors):
     - 320 X 480, 256 colors
     - 640 X 480, 16 colors
     - 1280 X 960 (monochrome)
 - 2 stereo RCA ports
 - internal speaker
 - 2 MIDI ports, ST compatible (ACIA6850)
 - 4 serials ports:
     - 2 RS232 ports, MFP68901 (ST compatible)
     - 2 85C30 hi-speed SDLC ports
 - one network LAN port, LocalTalk compatible
 - one DMA ACSI port ST compatible
 - one DMA SCSI port
 - one internal SCSI 48M bytes hard disk, 28 msec
 - one 3.5" drive, 720K bytes, ST compatible
 - one external floppy port
 - one VME A24/D16 connector
 - one MC146818 real time clock
    Too bad they don't have a 1.44 3.5" drive. To have more or less memory
means a special configuration for this computer (like the one I saw in store
with 4M bytes of RAM). In reviews, speed gain over a standard ST computer
varies from 200% to 9786%, depending of the application.
    ATX, an UNIX System V release 4 with X Windows, OSF Motif and so on, is due
in March 91. But then a 80M bytes hard disk and more memory will be necessary.
     I had the idea that a 68030 CPU can emulate a 68000 CPU without problems.
Thanks for the note.
Merry Christmas.
There are 2 Replies.

#: 8868 S12/OS9/68000 (OSK)
    23-Dec-90  22:01:00
Sb: #8863-#OS9/ST on Atari TT
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Denis - the 030 is compatible with the 000, but only from the user program side
of things.  A few system-state things change tho, from model to model. In other
words, a few sections of the kernel have to be changed, but otherwise
everything else would run just fine (apps, even drivers I'd think).
They (Motorola) figured that having to change the OS slightly was okay, as long
as user programs were still compatible.  I think they were right, because you'd
want to take advantage of new features in the kernel if possible, anyway.  best
- kev
There is 1 Reply.

#: 8889 S12/OS9/68000 (OSK)
    25-Dec-90  14:31:38
Sb: #8868-OS9/ST on Atari TT
Fm: MOTD Editor..Bill Brady 70126,267
To: Kevin Darling (UG Pres) 76703,4227 (X)
Say, Kev.... I think Toad Computers here has TT's.

#: 8887 S12/OS9/68000 (OSK)
    25-Dec-90  14:30:24
Sb: #8863-OS9/ST on Atari TT
Fm: MOTD Editor..Bill Brady 70126,267
To: DENIS CHARTRAND 72561,2714 (X)
Too bad they kept the 68901. I learned to hate that sucker.

#: 8869 S12/OS9/68000 (OSK)
    24-Dec-90  09:24:14
Sb: #OS9/ST on Atari TT
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
     Also, of course, about the list of equipment on the TT: 1 Centronics
parallel port and joystick/mouse port. There is room for 26M bytes of RAM. The
LAN, SCSI and ACSI ports work in true DMA mode. There is also a connector where
you can plug a ST compatible hard disk, in addition to the ACSI port which is
already a DMA ST compatible port.
BYE
There is 1 Reply.

#: 8870 S12/OS9/68000 (OSK)
    24-Dec-90  14:15:32
Sb: #8869-#OS9/ST on Atari TT
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Denis - also, I'm not positive, but I think I heard that later models will have
the hidens 3.5 drive capability.  Thx for all the info, btw!
There is 1 Reply.

#: 8890 S12/OS9/68000 (OSK)
    25-Dec-90  14:32:25
Sb: #8870-OS9/ST on Atari TT
Fm: MOTD Editor..Bill Brady 70126,267
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kev, if ya want a TT, lemme know. I'm still "registered".

#: 8894 S12/OS9/68000 (OSK)
    26-Dec-90  05:05:16
Sb: #blarslib available
Fm: Robert A. Larson 75126,723
To: all
A beta-test version of blarslib, my unix-compatability library for os9/68k is
available for anonymous ftp from smilodon.cs.wisc.edu.  The compressed tar file
is 53128 bytes.  (Source of course.) Smilodon also has source for compress,
tar, a number of little utilities I wrote (some of them available elsewhere),
TOP, diffs for porting GCC to osk (no confermation that they work, some people
have tried and failed), etc.  ls-lR_pub contains the current list.  Questions
about blarslib or my utilities should be sent to blarson@usc.edu.  Questions
about the smilodon archives should be sent to pruyne@cs.wisc.edu.
Compuserve users who don't have direct access to the Internet should note:
compuserve now supports mail to and from the Internet.
bitftp@pucc.princeton.edu accepts ftp commands via mail and mails back the
results.  (Send it the message "help" for instructions.)  The maintainer of the
Internet end of the compuserve/Internet mail link has complained that the 9600
baud link can't keep up with the demand. (Compuserve should be encoraged to get
a higher bandwidth link and a local cache of ftpable files.)
I refuse to waste my money and time uploading things to compuserve. If someone
else wishes to do so, they may.  Watch comp.os.os9 for further announcements. 
(Ask compuserve why they don't get usenet newsgroups, not me.)
There is 1 Reply.

#: 8902 S12/OS9/68000 (OSK)
    26-Dec-90  10:14:11
Sb: #8894-blarslib available
Fm: Zack Sessions 76407,1524
To: Robert A. Larson 75126,723 (X)
You may think you are wating your time when uploading to CIS, but you certainly
aren't wating your money. Connect charges are suspended while uploading.
Zack

#: 8899 S12/OS9/68000 (OSK)
    26-Dec-90  08:33:26
Sb: #68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: All
For some time now I've been tinkering with the idea of writing an assembler for
the 68000.  I'm using SK*DOS, which doesn't currently have a relocating
assembler, and we need one.  I'm also adding a disassembler to my hex debugger.
I've made several stabs at it, but I keep getting bogged down in complexity,
and I finally figured out the reason:  68000 assembly language is _AWFUL_!
Never mind the complexities in the hardware, or the fact that, having set
themselves a goal of an orthogonal instruction set, Motorola then set out to
introduce all kinds of bizarre non-orthogonalities.  That's in the hardware,
and there's nothing we can do about that.
Let's just concentrate on the assembler language.  I finally realized (I'm a
little slow, sometimes) that part of my problem is that the mnemonics are
inconsistent and irrational.  For one thing, there are cases such as ADD, and
ADDA where they chose to use separate mnemonics for what is essentially the
same instruction (with the same opcode).  [ I know, I know ... most assemblers
allow ADD for ADDA, but they still have to support both.]
Then, on the other hand, there are cases like ASL in which the same mnemonic
refers to completely different instructions, with vastly different opcodes and
argument encoding, depending upon whether we're shifting a register or a memory
word.
[More]
There are 2 Replies.

#: 8900 S12/OS9/68000 (OSK)
    26-Dec-90  08:33:35
Sb: #8899-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
Worse yet, though, is the syntax of the arguments.  Consider the two
instructions
       MOVE -(A0),D0 and    MOVE -(A06 + (4 * D05)/2)(A0,D0),D0
Both of these areperfectly valid instructions, assuming the labels A06 and D05
are defined somewhere.  But, of course, the encoding of the instructions are
completely different.  And a parser, scanning from left to right, can't tell
which kind of instruction it's dealing with until it gets to the fifth
character of the first operand.  In other words, a predictive parse is not
possible without some prefiltering by the lexical scanner.
This is the same problem as the old FORTRAN problem, often given as this
example:
       DO 10 I=1.5
which is an assignment to the variable DO10I, but the compiler doesn't know
that until it sees the '.'.   After all these years, you'd think that we
wouldn't fall into that trap again!
I finally figured out how other folks do it:  They keep a set of legal argument
strings around (things like "-(A0)", '-(A1)", etc.) and compare the whole
argument string with them, looking for the special cases. If nothing matches
the "canned arguments, then they assume it's an expression.  Even then, the
argument could be:
[More]
There is 1 Reply.

#: 8901 S12/OS9/68000 (OSK)
    26-Dec-90  08:33:42
Sb: #8900-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
       <expression>
       <expression>(An)
       <expression>(An, Rx)
       <expression>(PC)
 or    <expression>(PC, Rx)
Now, here's the proposition:  Is anyone besides me interested in defining a
better syntax?  I figure, as long as I'm writing an assembler, why not choose
the syntax to be easier, both to code in and to assemble?
I have two alternatives:
(1)  Pick a new set of mnemonics, and a new syntax for arguments, that's
parsible by a simple predictive parser.  Make it as rational as possible, and
use different mnemonics where different operations are implied.
or (2) While I'm at it, make the language more like a high-order language. In
other words, instead of
       MOVE X(PC),D0               D0 = X
       ADD Y(PC),D0        use     D0 += Y  (or perhaps just D0 + Y)
       JSR FOOBAR                  CALL FOOBAR
I'd appreciate comments/ideas/criticisms. Anyone want to help define such a
language?  Anyone have any better ideas?  Anyone out there who _DOESN'T_ think
I'm crazy?
Jack
There is 1 Reply.

#: 8916 S12/OS9/68000 (OSK)
    27-Dec-90  21:39:47
Sb: #8901-#68000 ASM Language
Fm: Jay Truesdale 72176,3565
To: Jack Crenshaw 72325,1327 (X)
Jack:
The C Users Group has a 68000 assembler written in C (CUG disk #190), with C
source code included.  I think they get $5.00/disk?  I suggest picking up a
copy of the "C Users Journal" at your local book store (I found it at a
Waldens) for more information.  For $5.00 I don't see how you can go wrong and
it might shed some light on your problems and keep you from having to re-invent
the wheel.
-J
There are 2 Replies.

#: 8924 S12/OS9/68000 (OSK)
    28-Dec-90  01:05:36
Sb: #8916-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jay Truesdale 72176,3565 (X)
Jay, I already have that assembler.  A conventional assembler is not what I'm
looking for.  But thanks for the info, anyway.
Jack

#: 8943 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:44
Sb: #8916-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jay Truesdale 72176,3565 (X)
Jay, looking back on it I realize I gave you a rather short answer, and one
that perhaps needs some elaboration.  I have two goals:
(1) Get a relocating assembler/linker combo
(2) Define a "more rational" assembly language, preferably one that looks more
like a high-order language.
I'd _LIKE_ to be able to get both in one shot, but there's no law that says I
_HAVE_ to do it that way.  As a matter of fact, I'm sure that there will be
people who'll prefer the conventional assembler anyway.
So the right answer should probably be: Yes, the CUG assembler may well meet
need #1.  All I'd have to do there is change the object-file format. If I still
want the other thing, I could then write it using the same format.  The same
linker would work for both, of course.
BTW, I came from the CP/M world, and there I had the world's best
assembler-language tools:  The assembler/linker/librarian from SLR.  I learned
one thing from Steve Russell, which is that the tools work much better, and are
even easier to build, when they're tightly integrated together.  Logical
extension:  Build a conventional assembler with good linker & librarian first,
then add a HOL-like assembler, and possibly a HOL compiler, all integrated
together.  Thanks for steering my thoughts in that direction.
Jack

#: 8913 S12/OS9/68000 (OSK)
    27-Dec-90  15:13:55
Sb: #8899-#68000 ASM Language
Fm: Ed Gresick 76576,3312
To: Jack Crenshaw 72325,1327 (X)
Hi Jack!
Yeah - You're crazy --- crazy like a fox!!  And you're a rabble rouser, too
:-).
I'm all for your idea of a _new_ approach to designing an assembler and I like
the idea of a high-order language.  I suppose the current mnemonics are a carry
over from the days when memory was scarce and expensive.
So many ideas come to mind - I could easily spec out a monster!  Let me throw
some of these out so you can shoot them down.
Could the new assembler be a combination interpreter/assembler?  In other
words, could an assembler be designed to permit testing the code prior to
assembling?  This, coupled with sensible syntax, could allow concentrating on
the objectives of the program rather than the details of the code. Why not a
generic assembler?  Maybe it could cover the 680x0 series and the xxx86 series
chips.  I've noticed when coverting 86 code to 68 code, certain sequences can
be automatically converted - and if I knew more, I would've set up macros. 
Can't the assembler do this by telling it what chip you're writing for?  Could
the assembler do automatic register selection?  Tell the assembler what
registers are reserved (for system, etc.) and then let the assembler select the
registers - would probably require the assembler to automatically set-up data
areas, but so what.
I can go on but I better shut-up.  In any event I'd certainly be happy to help
you in any way I can (don't know the first thing about writing an assembler -
but I'm a terrific kibitzer)!
Good Luck,
Ed Gresick - DELMAR CO
There is 1 Reply.

#: 8918 S12/OS9/68000 (OSK)
    27-Dec-90  23:53:27
Sb: #8913-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Ed Gresick 76576,3312 (X)
Ed, one of the interesting things about the software business is what creatures
of habit we are.  For people who claim to be creative, it's amazing how much we
stick to the "tried and true."  Look at the following code:
       foobar: move x(pc),d0
               move y(pc),d0
               bge next
               subq #1,d1
               dbra foobar
       next:   ...
Not everyone would recognize the particular machine this is for, but almost
EVERYONE would agree that this looks like assembler language.  The layout:
Labels starting in column 1, three or four-letter mnemonics, followed by
arguments ... dates from the original assembler, SAP, for the IBM 650 circa
1952.  We've been using it ever since.  I've never understood why people pick
mnemonics like JSR or BRA when there are perfectly good words (CALL and GOTO)
already in use.
Some years ago I set out to define a "rational" assembler language for the
8080.  A few examples are show below
       MOV A,B          -->     A=B
       ADD A,B          -->     A+B
       CALL FOO         -->     CALL FOO   { That's one Intel got RIGHT!)
       JNZ  BAR         -->     IF !0 BAR
[More]
There are 2 Replies.

#: 8919 S12/OS9/68000 (OSK)
    27-Dec-90  23:53:35
Sb: #8918-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
I was real pleased with the language, but at that time I didn't know enough
about how to build an assembler to implement it.  Now I do.
Unfortunately, the technology keeps passing me by.  By the time I had the 8080
syntax defined, along came the Z80, with extra addressing modes and
instructions.  By the time I got those figured out, I was suddenly in the 68000
business.  Gotta learn to work faster!
When I first started programming for the 68000, I had a real problem with some
of the branch instructions.  Like DBcc, for example, NEVER seems to do what the
instruction seems to say.  So I wrote a structured preprocessor for the
assembler.  I had constructs like IF..THEN..ELSE..ENDIF, WHILE..ENDWHILE,  and
FOR.. ENDFOR. I wrote a prototype in Turbo Pascal for my PC, and it worked like
a champ.  I was truly surprised at how easy it is. Never implemented it for
SK*DOS (early on, the development tools weren't up to the task), but it's still
in my job jar.
I don't need help building the assembler.  What I _COULD_ use lots of help on
is defining the language.  More on this in the next message:
[More]
There is 1 Reply.

#: 8920 S12/OS9/68000 (OSK)
    27-Dec-90  23:53:42
Sb: #8919-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
The first decision is:  Do I keep the conventional format (label, mnemonic,
operands) ... in other words, try to remain as faithful to convention as
possible, or do I go for the A=B approach?
The next decision is:  How to handle all the addressing modes, sizes, etc.
Either way I go, I obviously have to allow for the generation of any
instruction that the normal assembler provides.
The size parameters give me fits, too.  I'm sorta toying with the idea of a
size declaration.  In other words, you could declare D0, say, to be size byte. 
From then on, until you redeclare it, every reference to D0  would produce a
byte instruction.  Saves all the '.B's.
[More]
There is 1 Reply.

#: 8921 S12/OS9/68000 (OSK)
    27-Dec-90  23:53:51
Sb: #8920-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
A little history: Several people have tried to do similar things with
assemblers.  One notable is by Ed Ream, author of the editor "red."  He came up
with a unique approach, which was to make the assembler look like legal K & R
C.  In other words, expressions like
       d0 += d1; are perfectly legal C expressions.  In fact, Ed's anguage was
such a proper subset of C that it would compile under a C compiler (with the
identifiers d0, d1, ... d7, a0, a1, ... a7, etc. just compiled as normal
variables. (Not sure how Ed handled the size issue.  Maybe I'd best go back and
take another look.)
Only one problem:  The assembler ran slower than Christmas, and some of the
constructs were pretty weird.
Another fellow did the same thing for the Z-80 ... using C-like constructs. His
program was really just a preprocessor, and also too slow to be much use.  But
the worst problem was some of the instructions.  For example, the Z-80 LDIR
(load, increment, and repeat) instruction translated to the following C code:
       while(bc--){*de++=*hl++)
Frankly, it's a lot easier for me just to type LDIR!
I concluded from all this that it's a bad idea to try to warp the assembler to
fit an existing language like C.  Better to start with a clean slate. (one more
message, I promise)
[More]
There is 1 Reply.

#: 8922 S12/OS9/68000 (OSK)
    27-Dec-90  23:54:00
Sb: #8921-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
I've identified three main kinds of instructions:
(1)  The binary instructions, like   D0 = X or D0 + D1.  If someone _REALLY_
wants to keep a C-like syntax, I'll settle for D0 += D1, but I sort of like the
stark simplicity of the first form.
(2)  The unary operators, like not ( !D0), negate (-D0), and shifts ( >>D0 or
<< D0, 4 )
(3)  Things like LDIR that are better left as mnemonics.  It's best to think of
these as "built-in function calls."
Whichever approach I take (modified traditional, or C-like), it's important
that the syntax be written so it can be handled by a predictive parser. That
simply means that when you see a certain character (or, more generally, a
token) you always know what to do.  That, in turn, means that constructs like
-(A0), which starts out looking like an expression, are N.G.
Hope this stimulates some thought & discussion.  I'll build the assembler if
(a) Anyone cares, and (b) we can agree on what should be built.
I've gotten one mail message so far that said don't do anything.  That may be
the consensus, but for those who are concerned about compatibility, I'd like to
point out:  A screen editor like Brief, with good global substitution
facilities, can take care of different notations pretty quickly.
Jack
There is 1 Reply.

#: 8930 S12/OS9/68000 (OSK)
    28-Dec-90  14:11:14
Sb: #8922-#68000 ASM Language
Fm: William Phelps 75100,265
To: Jack Crenshaw 72325,1327 (X)
Jack, 
Since this is the OS-9 Forum I have a question.  In your first message you said 
that you wanted to develop a relocatable assembler fo SK*DOS; do you want to 
write a normal assembler, or do you want reentrant PIC?  If you only want 
normal code we can fix that later 8-).
As you know, the reason that new assemblers still use mnemonics like BRA is 
compatability with existing code.  If you want that then you can write your 
assembler the same way.  If you do not care about that, then why not go all the 
way -- natural language interpretation.  How about a program written like this:
* This is a menu subroutine
window  load data register 0 with the screen width
        subtract 1 from data register 0
......
Notice how the code is self documenting and MUST do what is says it will do. 
In order to easily handle things like expressions, the assembler should RUN in 
a high level language.  Any variables used should also automatically be placed 
in the data area -- we don't want self-modifying code do we.
[continued next message]
There are 2 Replies.

#: 8931 S12/OS9/68000 (OSK)
    28-Dec-90  14:11:52
Sb: #8930-68000 ASM Language
Fm: William Phelps 75100,265
To: William Phelps 75100,265 (X)
Some of the high level features mentioned are found in Forth assemblers(with 
are really cross assemblers even if running on the native chip).  Forth 
assemblers also compile code WHILE it is being written, which would allow the 
programmer to immediately be given the clock cycles for a routine.  Also, 
macros and the high level functions of the language can easily be used in such 
an assembler.
** To be fair Forth is not the only language with these capabilities, just the 
most visible.
The the only disadvantage of a natural language assembly interpreter I see is 
the amount of work needed to write it.
William

#: 8938 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:02
Sb: #8930-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: William Phelps 75100,265 (X)
William, I'm only just getting started in OS9, and my "baseline" system is
SK*DOS, until something better comes along.  I posted the message here because,
OS9 or no OS9, this is the only forum where people talk much about 68000's.
Re the PIC:  That would be best.  SK*DOS (and OS9) requires it.  Which sort of
means that the assembler shouldn't make you do anything special to get it. 
There _ARE_ some implementation issues that I haven't worked out yet. Example: 
You can address variables PC-relative, but then if you're using OS9 you can
also address them base A6.  Since the fundamental nature of the assembler is to
let the programmer do anything the chip will support, I suppose that you can't
assume anything, or impose any coding style.  Still, there should be some easy
way to tell the assembler what you want, instead of having to write things like
foo-base(a6) all the time.  I've thought of having pseudo-ops something like
       BASE A6 = OFFSET
       BASE PC
   or  BASE ABSOLUTE
so that once declared, you could reference data from that base.  (Don't know
WHAT you do if you need more than one!)  As for control references, I'd like to
see BRA's and BSR's generated by default, with some kind of mechanism for
dealing with things out of range and/or external.
[More]
There is 1 Reply.

#: 8939 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:07
Sb: #8938-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
Re "natural" language:  BAD IDEA!  The last time someone tried that, the result
was COBOL.  Technically, a roaring success since it's still the most common
programming language in use today, but from a computer science (or
productivity) point of view, a terrible disaster that has cost us megabucks. I
don't think there's a language expert alive that wants to see _THAT_ experiment
repeated!
Jack
There is 1 Reply.

#: 8957 S12/OS9/68000 (OSK)
    30-Dec-90  12:14:15
Sb: #8939-#68000 ASM Language
Fm: William Phelps 75100,265
To: Jack Crenshaw 72325,1327 (X)
Re:base addresses & assembler assumptions
Why not use command line directives to tell the assembler what mode it is in? 
Some existing assembler have Motorola or OS-9 modes, and others have 68000 or 
68020 modes that are switched from the command line.
Re:natural language
I did not mean to try to include everything & the kitchen sink, as COBOL does. 
Only machine language and a method of accessing system calls should be in the 
assembly language.  Only two major changes would be necessary to make the 
assembly language look like "natural" language:(1) expanding the mnemonics to 
the words they represent, and (2) automatic definition of variables with their 
use.  It is obvious from XREF type programs that computers can handle variable 
definition better after they have been used.  The syntax for "natural" language 
would be almost identical to normal assembly language.
William
There is 1 Reply.

#: 8965 S12/OS9/68000 (OSK)
    30-Dec-90  23:56:18
Sb: #8957-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: William Phelps 75100,265 (X)
William, thanks for the inputs.  I'll have to go off and think about them.
I have no problem with specifying the addressing modes in the command line
(although it would also be nice to be able to do so as program commands. What I
was thinking about was cases where the declaration might change. Example: 
Instead of having to say MOVE.B, MOVE.W, or MOVE.L all the time, you'd just
tell the assembler "Register D0 is supposed to hold a byte." From then on, all
references to D0 would be .B, until you tell it something different.
Even nicer might be to assign variable names to the registers.  Sort of like
the register option of C, but you'd have to do it manually instead of letting
the compiler do it automatically.
One thing I have to be careful about here:  If you go overboard with this
thing, the assembler turns out to be MUCH harder to build than a compiler. You
have all the complexity of a compiler, plus:
 (1) You have to support EVERY machine language instruction, where the compiler
can use only a subset
 (2) There are many more restrictions and special cases imposed by the
hardware, where the compiler can use a syntax that's more general.
I want to have a nice tool, but I'd rather not make it my life's work!
Jack
There are 2 Replies.

#: 8966 S12/OS9/68000 (OSK)
    31-Dec-90  02:44:34
Sb: #8965-#68000 ASM Language
Fm: Kevin Darling (UG Pres) 76703,4227
To: Jack Crenshaw 72325,1327 (X)
Jack - been meaning to jump in here, but haven't had the time yet!
But yes, being able to assign a name to a register in sections of the source
would be nice.... a friend and I were just talking about wanting this the other
day.
We had a routine using a bunch of the 68K registers, and even with comments, it
got tough to follow which reg was which (and woe if you change some! ;-).
kev
There is 1 Reply.

#: 8975 S12/OS9/68000 (OSK)
    31-Dec-90  20:44:50
Sb: #8966-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kev, I remember a project at work on the Z8000, which has 16 general-purpose
registers.  The program had to be super fast ... among other things, it had to
compute one sine, one cosine, an arctan, and a square root, in a millisecond.  
So I had to write almost all in-line code, and keep everything possible in
registers.   What an ordeal!  Basically, I was doing global register
optimization by hand.  Had to keep a map of what was in each register, and
deciding where to put the next item was like working out a chinese puzzle.  It
sure would have been nice for me to have been able to identify the registers by
their contents, too.
Which brings me to a thought:  You'd need error messages to tell you when
something's been overlaid, wouldn't you?
Well, I guess that would be taken care of by the assembler:  If you declare a
variable x to be in D0, and then later declare it to be y, the assembler must
remove x from the symbol table.  Unless, of course, you redeclare it as RAM.
Hm.  Have to think about implementation on that one.  I'd been thinking of a
syntax something like
   assign x to d0
   .
   .
   release d0
Perhaps I could set it up so that if there is an assignment x=d0 somewhere in
between, x would be automatically set to refer to the RAM variable rather than
the register.  Sounds feasible.
Jack
There is 1 Reply.

#: 8980 S12/OS9/68000 (OSK)
    01-Jan-91  01:13:22
Sb: #8975-68000 ASM Language
Fm: Kevin Darling (UG Pres) 76703,4227
To: Jack Crenshaw 72325,1327 (X)
Hmmm. Interesting thoughts.  I wasn't thinking that fancy (yet - grin). Just
mainly wanted to be able to say:
 alias x d0
or similar, and so within that file section be able to say "move #3,x" and ....
hmmm... another method might be:
   org d0
 x reg 1
 y reg 1
To reserve regs d0,d1 ... but this is too weird.  Never mind ;-).  Hafta think
about it some first.

#: 8968 S12/OS9/68000 (OSK)
    31-Dec-90  10:14:16
Sb: #8965-#68000 ASM Language
Fm: William Phelps 75100,265
To: Jack Crenshaw 72325,1327 (X)
Re:MOVE
I don't think there is much that can be assumed without making some programs 
difficult or impossible to write.  The only place where it would be "safe" to 
assume size would be when a variable of a specific size is accessed.  It would 
also be nice to be able to give the registers names; even a, b, c, is better 
than 0, 1, 2.
On another note, I assume that you are writing a two-pass assembler, but are 
you making it a macro assembler?  If so, then are you going to put the code 
in-line or in subroutines?
William
There is 1 Reply.

#: 8976 S12/OS9/68000 (OSK)
    31-Dec-90  20:44:55
Sb: #8968-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: William Phelps 75100,265 (X)
William, whether it's one- or two-pass is an implementation issue. Shouldn't
affect the appearance to the user either way.  Actually, I'll probably use a
one-pass with backpatching, but the first iteration may be two-pass.
Yes, might as well support macros.  As long as I'm doing it, best to do it
right.  Macros are _ALWAYS_ supported as in-line code, by definition.
Jack
There is 1 Reply.

#: 8997 S12/OS9/68000 (OSK)
    01-Jan-91  23:59:08
Sb: #8976-#68000 ASM Language
Fm: William Phelps 75100,265
To: Jack Crenshaw 72325,1327 (X)
Re:two-pass
Actually the user would see it if the assembler has an "ifp1" type directive, 
but I suppose you will just fake that on INCLUDEs.  I would also think that 
resolving variables would be more difficult if you want a separate data area.
Re:macros
Macros have always been supported as in-line code in normal assemblers.  It is 
possible for TIL assemblers to put an equivalent subroutine call in-line.
William
There is 1 Reply.

#: 9001 S12/OS9/68000 (OSK)
    02-Jan-91  18:44:52
Sb: #8997-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: William Phelps 75100,265 (X)
Well, I sure can't disagree, William, since I have no idea what an ifp1 or a
TIL is.
Jack
There is 1 Reply.

#: 9009 S12/OS9/68000 (OSK)
    03-Jan-91  23:01:00
Sb: #9001-#68000 ASM Language
Fm: William Phelps 75100,265
To: Jack Crenshaw 72325,1327 (X)
ifp1 - if pass one
TIL - Threaded Interpretive Language
William
There is 1 Reply.

#: 9024 S12/OS9/68000 (OSK)
    05-Jan-91  06:49:24
Sb: #9009-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: William Phelps 75100,265 (X)
Ok on the defs, William.  I understand the definition of the ifp1 keyword, but
can imagine no earthly reason why one would want to use it.  I' having a hard
time imagining how a program, written in any programming language, could be or
should be tangled up with the way the translator was implemented.  Do you find
it useful?
Re TIL:  Again, I understand.  I used to be something of a fan of FORTH, so I
can dig the concept.  The idea of putting subroutines in line, though, doesn't
fit very well with the idea of an assembler.  In the latter, the whole point
would seem to be to do the absolute minimum kinds of transformations to the
language.  It's just a one-for-one translation from mnemonics to machine codes.
Jack
There is 1 Reply.

#: 9028 S12/OS9/68000 (OSK)
    05-Jan-91  12:27:57
Sb: #9024-#68000 ASM Language
Fm: Bud Hamblen 72466,256
To: Jack Crenshaw 72325,1327 (X)
Jack,
The best use of "ifp1" is when you have big include files that define labels
(like skequate.lib) but don't generate code.  Makes assembly a tad faster.
    ifp1
   lib skequate
   endif
That's about it.
You should have your assembler accept Motorola's defined syntax without any
changes, no matter what else it does to extend the assembler language. If you
ever saw Grappel's and Hemenway's STRUBAL+ for the 6800 (yep, two naughts),
you'd see what I was thinking about.  The compiler recognized both 6800
assembler and a structured basic language.  It was a one-pass basic compiler
and a two-pass assembler that emitted a relocatble object file that you could
link with other modules.  The implementation was a dog, but the idea was a good
one.
Bud
There is 1 Reply.

#: 9033 S12/OS9/68000 (OSK)
    05-Jan-91  19:23:47
Sb: #9028-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Bud Hamblen 72466,256 (X)
Bud, in STRUBAL could you mix assembler language with BASIC?
Jack
There is 1 Reply.

#: 9042 S12/OS9/68000 (OSK)
    06-Jan-91  10:58:14
Sb: #9033-#68000 ASM Language
Fm: Bud Hamblen 72466,256
To: Jack Crenshaw 72325,1327 (X)
Jack,
Here's an example copied from the Strubal manual:
*
    INTEGER I(10),J(10),IADD,JADD
*
* MOVE CONTENTS OF J INTO I
* USING CRUTCH CODING FOR SPEED
*
    GETAD IADD=I
    GETAD JADD=J
    FOR K=IADD,IAAD+20
*
    LDX JADD     POINT TO J
    LDA A 0,X    GET BYTE FROM J
    INX
    STX JADD     INCREMENT JADD
    LDX K        POINT TO I
    STA A 0,X    STORE BYTE IN I
*
    NEXT K
The syntax is clunky, but the idea of combining a higher level
syntax with normal assembler syntax is interesting.
Bud
There is 1 Reply.

#: 9049 S12/OS9/68000 (OSK)
    06-Jan-91  21:11:50
Sb: #9042-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Bud Hamblen 72466,256 (X)
I like it, Bud ... not the syntax, but the idea.  The reason I asked was that I
was prepared to say that I'd rather have a separate compiler and assembler. 
But if you can mix the two languages in one program, so much the better.
I started down this road by writing a preprocessor for 68000 assembler
language.   I did this mainly because I found the 68K control constructs,
branches, etc., too confusing.  Every time I use DBcc, I have to think about it
and hand-execute it, and I _STILL_ tend to get it backwards.  So I decided to
add Pascal-like control constructs.  I had
 IF-ELSE-ENDIF
 WHILE-ENDWHILE
 LOOP-ENDLOOP
 DO-ENDDO (uses DBcc)
 BREAK
For the conditions, I replaced the 68000 CC's by things like =, !=, <= ,etc.
Carry clear was !cy, etc.
It worked out really nicely, and turned out to be easy to write.  Natch, all
control constructs were nestable to any depth.  Any other instructions besides
the control constructs just pass right through to the assembler.
I could play around with something like this.  I've toyed with the idea of
extending the HOL-like constructs.  By that I mean that, if a MOVE X(PC),D0
gets translated as d0=x, then it's a small matter to let more complex
expressions like  x = y + z/2 be generated, too.
[More]
There is 1 Reply.

#: 9050 S12/OS9/68000 (OSK)
    06-Jan-91  21:12:09
Sb: #9049-#68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
I have mixed emotions about this, though.  For one thing, if the idea of an
assembler is to produce a 1-to-1 correspondence between source code and object
code, this is violated if you allow expressions.  Not only that, but it might
not be immediately obvious that multiple instructions are going to be
generated.  And it would take someone who _REALLY_ knows assembler language to
know when one instruction will be generated, and when it can't be.  It seems
that if the "compiler" is going to expand the code and produce what is surely
likely to be more inefficient code than the programmer can do, you should at
least give him some warning message that you've done the expansion.
Too, once you get into general assignment statements, you have to use some
intermediate storage .. either register, stack, or memory.  And this might walk
over the programmer's plans for register assignments.
Finally, it's HARD!  It turns out to be a lot more difficult to write a
HOL-like assembler than a HOL compiler, itself.  The reason in that the
compiler writer can make his own decisions as to register assignments,
parameter-passing conventions, etc., and enforce them autocratically.  With a
"pseudo-assembler," you have to honor the programmer's choices. Also, the
compiler author is allowed to use a subset of the CPU instruction set, while
the assembler writer must support them all.
[More]
There is 1 Reply.

#: 9051 S12/OS9/68000 (OSK)
    06-Jan-91  21:12:31
Sb: #9050-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Jack Crenshaw 72325,1327 (X)
[Continued]
All of this touches on some very deep issues of philosophy, about which I have
some rather firm convictions (surprise!)
First of all, I like to program in assembly language.  Despite the general
feeling that it's a MUCH more difficult medium to program in, I find that it's
not that much harder than a HOL, _IF_ you have good tools (including macro
facilities), a well-equipped subroutine library, and some well-defined
conventions for things like parameter passing.  With my preprocessor, you get a
lot of the advantages of a HOL with no loss in efficiency.
On the other hand, I've also become convinced, by personal experience, that
writing a full-blown compiler is also very easy, _IF_ you don't care much about
the quality of the code output.
The trick is to combine both ideas into one program.  The ideal language would
be one in which you could write either way:  Quick and dirty programs in a
BASIC-like language, and to heck with tight code, or carefully tailored code
approaching or equalling the efficiency of assembler, for those cases where
it's needed.  But writing a single language capable of doing this would seem to
be a big challenge.  Certainly it's one that people like Kernighan or Wirth
haven't tried to tackle.
Rather than trying to bite that huge bullet in one swallow, I'd prefer to start
with something more modest and sneak up on the rest.
Jack

#: 8926 S12/OS9/68000 (OSK)
    28-Dec-90  10:27:07
Sb: #8918-#68000 ASM Language
Fm: Ed Gresick 76576,3312
To: Jack Crenshaw 72325,1327 (X)
Hi Jack!
First, you have my vote for a new assembler.
A little background - I probably spend about half of my time programming or
reviewing/testing programs written by others.  Most of this is with data-base
languages.  Occassionally, I have to get into C and/or Assembler.  While I
don't employ full-time programmers, I do employ several part-time programmers
as I need them.  When they work in assembler or C, they all use 'tools' of
various sorts to 'improve' their efficiency.  (I'm not convinced that's
necessarily true.)  When I have work done in C, I insist that the code pass a
'lint' test.  These programmers rely on volumes of libraries of sub-routines
and macros they(?) have previously written.  I doubt I get the most efficient
code possible this way but the way these people have been trained and simple
economics require that I accept the code (so long as it works and meets the
requirements I had specified).
I remember one bit of assembler code that gave me a real fit.  Most of the time
(three or four months), the program worked fine.  Occassionally, it reacted in
a weird fashion.  Took me a long time to find the error - the programmer had
tested the wrong condition code (which really wasn't a test at all in this
case).  The code fragment was -
          .                          (What it might look like under
          .                           your proposed assembler)
          .
          lea table(pc),a6              a6=table
          move.b (a6,d5.w),d7           d7=a6+offset or d7=a6+d5
          bne there                     'if n bit set' goto there
          .                             No, the first line above is wrong.
          .                             that would put the contents in d7
                                        we want the address so - why not
                                        'a6=adr(table)'
<more>
There are 2 Replies.

#: 8927 S12/OS9/68000 (OSK)
    28-Dec-90  10:28:06
Sb: #8926-#68000 ASM Language
Fm: Ed Gresick 76576,3312
To: Ed Gresick 76576,3312 (X)
<continued>
The offending code was the 'bne' - it should have been 'bmi' - he wanted to
test the 'n' flag.  Try to find it in about 12,000 lines of poorly commented
code.  So, is there a way for the assembler to pick the correct test?
Please stay away from C-like constructs - they can get messy and are not always
clear.  There is no reason to stay with traditional mnemonics per se. Yes, in
some cases what was selected may turn out to be the best but, more often than
not, it' not the best today.  One question, who is your intended user?  If
you're targeting the experienced C/assembler programmer, I suspect you'll get a
lot of resistance.  On the other hand, the new or casual user (really one and
the same) will appreciate an assembler that is easy to use and does not require
all kinds of 'tools' to increase programmers' productivity. And I fall into
this category.
Can the assembler use ordinary English words?  In order to ease the
requirements of the parser, a preprocessor might be used to tokenize these
words and if the tokens are sensible, users will probably learn them.
Another task the assembler should do is select whether the branch or jump is a
long or short.  Get tired of putting '.s's in only to get back error messages
telling me I can't do that - especially if its because I added some code.
<more>
There are 2 Replies.

#: 8928 S12/OS9/68000 (OSK)
    28-Dec-90  10:28:51
Sb: #8927-#68000 ASM Language
Fm: Ed Gresick 76576,3312
To: Ed Gresick 76576,3312 (X)
<continued>
Something I've sometimes wanted, was the number of clock cycles necessary to
execute a given instruction and a total for the program (or maybe for
sub-routines).  Sure, it can be looked up but what a job.  Can that be added as
an option?
Another area I suspect may be hairy for you is handling the various addressing
modes - especially if we want the assembler to select the proper mode for us.
While we don't want a slow assembler, absolute speed isn't as important as ease
of use and understanding.  Code that is easy to understand will result in
writing code with fewer errors requiring fewer assembly attempts. So, even if
we want more from the assembler, if its easier to use, the total time should be
less.
And I assume a linker will be included so we can write short routines.
Well, I've gotten pretty windy - only a good assembler should be this verbose!
Ed Gresick - DELMAR CO
There is 1 Reply.

#: 8942 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:31
Sb: #8928-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Ed Gresick 76576,3312 (X)
Ed, the main reason for wanting to do an assembler is to get relocatable code
... the current SK*DOS assembler only does absolute.  It's ASM from Bud Pass. 
So the linker is a definite must.
Right after the PT-68 came out, Sidney Thompson recruited me to build a linker.
He and Bud Pass were developing a C compiler, but with no linker it makes
building modular software pretty difficult!
I did build the linker, but we had a chicken-and-egg problem:  A great linker
is not much good if the assembler and compiler can't generate the object
modules for it!  Really, the linker and assembler have to be built as parts of
a system.  So I had to begin with a linker format that ASM was capable of
generating, i.e. I was limited to what I could inject into the object file via
DC statements.
The linker's been done for about two years now, but Sidney and Bud don't like
it (not elegant enough for Bud, though he declined to offer any suggestions as
to improvement).  Neither has shown any interest in incorporating it into the
assembler or compiler,and Bud's support of SK*DOS seems to have dropped off to
zero.  So I figure if we're ever going to get a good relocatable
assembler/linker/compiler system ... in other words, adequate development
tools, I'm going to end up writing them.
Which brings us back full circle.  In a few attempts at prototyping the
assembler, I realized I was spending a lot of energy to handle a syntax that is
fundamentally flawed.  It seemed to me that, as long as I'm gonna do this,
might as well make a few improvements along the way.
Jack

#: 8941 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:19
Sb: #8927-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Ed Gresick 76576,3312 (X)
I agree with you on both counts, i.e.
(1)  There's no need to try to make the assembler "look like" C.  In fact, it
could make things worse, since the programmer might then want to write other C
constructs that aren't supported.  That was a problem with Ed Ream's approach.
(2)  The programmer shouldn't have to decide whether to use long or short
branches, or short data forms (MOVEQ).  Who in their right mind would want to
use a three-word immediate when you could do it in one?  The assembler should
take care of that kind of thing.
(3) {OK, I lied about the "both"}  I need to define the audience. Experienced
assembly programmers aren't going to want to learn a new language.  I guess the
main user I'm interested in is me.  Anyone else who wants to tag along is
welcome.
Jack

#: 8940 S12/OS9/68000 (OSK)
    29-Dec-90  20:07:13
Sb: #8926-68000 ASM Language
Fm: Jack Crenshaw 72325,1327
To: Ed Gresick 76576,3312 (X)
Ed, in my preprocessor, the operative branch would have been
       if != there
 or
       if !0 there  (both statements mean the same thing)
The problem in your program was that the comment is N.G.  Instead of saying "if
n bit set," the programmer should have said what he really expected to happen,
i.e.  "If table entry is negative..."  This would have alerted you much quicker
to the problem, I'll wager.  In that case, my syntax would have been
       if <0 there
which is kinda hard to misinterpret!
Jack

#: 8933 S12/OS9/68000 (OSK)
    28-Dec-90  21:18:36
Sb: #High Density drives
Fm: Frank Hogg of FHL 70310,317
To: all
I recall that there was a thread about sectors per track etc on the high
density drives. Did anyone ever come up with a concensus(sp?) on that. I have
only been able to get 29 sectors per track so far. We havn't played around with
inter sector gaps yet tho.
Frank
There is 1 Reply.

#: 8935 S12/OS9/68000 (OSK)
    29-Dec-90  04:03:53
Sb: #8933-High Density drives
Fm: Ed Gresick 76576,3312
To: Frank Hogg of FHL 70310,317 (X)
Frank:
We're using 34 sectors per track for 3 1/2" drives and 28 sectors per track for
5 1/4" drives (high density - of course).
Ed Gresick - DELMAR CO

#: 8950 S12/OS9/68000 (OSK)
    30-Dec-90  09:08:22
Sb: OS9/ST on Atari TT
Fm: DENIS CHARTRAND 72561,2714
To:  70126,267
    If we look inside the Atari TT, we can see that the MFP68901 are not in 40
pins DIP package anymore, they are in a grid-array type, like the 68030 and
others chips. I don't know if it's a new version of 68901.
BYE

#: 8987 S12/OS9/68000 (OSK)
    01-Jan-91  13:40:10
Sb: #MegaFile44
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
   Hi, Kevin.
   Yoy know if the MegaFile 44 hard disk for the Atari ST with removable
cartridge can work with OS9/68000 for the Atari?
Thanks
There is 1 Reply.

#: 8992 S12/OS9/68000 (OSK)
    01-Jan-91  19:53:46
Sb: #8987-MegaFile44
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Denis - no, I sure don't know.  If it otherwise looks like a regular Atari SCSI
hard disk, then I don't see why not, tho.
Anyone here had experience with removeable media HD's??

#: 9101 S12/OS9/68000 (OSK)
    12-Jan-91  07:00:01
Sb: OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: All
Has anyone else seen this problem with the OSK clib.l supplied with OSK version
2.3?  It seems the and rdump -l or the lib shows some of the functions not in
the proper order.  Are the libs compiled for specific machines or is this how
they come from MicroWare?
definition of fflush in putc_c before reference in fseek_c definition of fflush
in putc_c before reference in getc_c definition of fflush in putc_c before
reference in setbuf_c definition of _tidyup in putc_c before reference in
cfinish_a definition of _sysret in syscommon_a before reference in color_a
If anyone has any idea if this will affect my programs and if there is a
problem with the order, please let me know.
Mike Haaland
Press <CR> !>GO RATES for current information

#: 9102 S12/OS9/68000 (OSK)
    12-Jan-91  09:20:06
Sb: #9101-OSK Clib.l Order
Fm: Pete Lyall 76703,4230
To: Mike Haaland 72300,1433 (X)
Mike-
I guess a key question is DO your programs link? Secondarily, do the libraries
have indexes in them that allow nonlinear access? James Jones is a good fellow
to ask these questions...
Pete

#: 9111 S12/OS9/68000 (OSK)
    13-Jan-91  02:49:00
Sb: #9101-OSK Clib.l Order
Fm: Bob Taylor 73270,3124
To: Mike Haaland 72300,1433 (X)
I checked ALL *.l files in directory LIB and found the same in all library
files clib*.l.
I haven't noticed any problems to date, however ...
Bob

#: 9108 S12/OS9/68000 (OSK)
    12-Jan-91  22:03:14
Sb: #ST/OSK new version?
Fm: BILL HEALTON 73367,357
To: Kevin Darling 76703,4227 (X)
Kevin, 
       I just receiveda flyer from Microware announcing verion 2.4 OS9. I'm
still at v2.2 on my ST. Do you know if the ST version will be upgraded also?
It took an extra3-5 months before they released v2.3 for the ST, and from what
I heard there was little if any improvement in the Port(drivers/ROM calls). If
you or anyone else has info on if, what, and when the ST will gain from this,
please let the rest of us know.
I haven't worked on the windows since before Christmas, too many other things
(work,printer upgrades,memory upgrades, floods, etc.). As they stand now I
feel pretty good about the keyboard portions(untested), but I was just
beginning the replacements for the text and cursor control routines. Did you 
ever get those defs files done for your graphics window driver? I would still
like to work with the same defs and try to insure your driver(s) will couple 
with anything I do.
ps. have you heard about the 32MHz '030 + 8 Meg(additional) upgrade in the
works by Gadgets by Small? Looks like the STs aren't going to run short for a
while.
Thanks.....  Bill Healton  73367,357
There is 1 Reply.

#: 9159 S12/OS9/68000 (OSK)
    15-Jan-91  23:13:25
Sb: #9108-#ST/OSK new version?
Fm: Kevin Darling (UG Pres) 76703,4227
To: BILL HEALTON 73367,357 (X)
Hi Bill (I've been at the beach - quick chance to go, and couldn't pass up a
vacation! :-)...
Hadn't seen that about the Small 030 thingie. thx!
Yah, busy here too. Keep meaning to send you the window code and let you start
the ST port (really should be pretty easy).  Are you pretty free for time these
days? - kev
There is 1 Reply.

#: 9188 S12/OS9/68000 (OSK)
    18-Jan-91  23:33:11
Sb: #9159-ST/OSK new version?
Fm: BILL HEALTON 73367,357
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kevin- Welcome back, vacations are tuff, but someone's got to take them <gr>
No such thing as free time, but without some guidelines it has been difficult
to get back to the windows(I have been working with GEM based stuff like the
program I now use to read/reply to messages <QuickCIS> and Graphical WPs).
If you can send the code, I will try to get back to it. Also if you (or your
code) can clarify how the drivers differential between screens(ie. the areas
I have been working with) and windows (ie. your drivers, multiples per
screen). I left off looking at how the different screen resolutions are bit-
mapped, and how to but pixels on the screen. That brings up one more question,
how elaborate must the basic screen(text) driver be (mixed text sizes?)?...or
should I assume a change in character sizes allows a clear screen. This
greatly impacts the row/column cursor control (ie. backspacing).
Any and all description/definition/code will help me to understand what I need
to write, and how much my driver needs to handle. If I can simplfy(eliminate 
rewriting something you have addressed, the less "free-time" I have to use).
Maybe then I can take a vacation...<from the other room>"Honey, the roof needs
fixed,ETC.,ETC....".
Thanks Bill

#: 9203 S12/OS9/68000 (OSK)
    19-Jan-91  20:54:42
Sb: #9101-OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)
I don't think it is a problem, particularly if things link ok. Re: _tidyup,
would be _referenced_ in putc_c and such before it is _defined_ in cfinish_a. 
This will cause the linker to snatch it out of the lib to satify the unresolved
reference.  It is a one pass linker, so you can only have forward references.
BTW  Hi, Mike.
Carl

#: 9234 S12/OS9/68000 (OSK)
    22-Jan-91  14:56:52
Sb: OS-9000 and 386sx/T3000
Fm: Robert A. Hengstebeck 76417,2751
To: all
Today in the TRS80PRO forum, on message 38740; a Mr J Stockon described how he
upgraded his Tandy 3000 HD to a 386sx type computer by replacing the 80286 on
the mother board with a SOTA EXPRESS/386 setup.  The setup consisted  of a
small pcb designed to fit into the 286 socket and which has an additional
socket for a 387sx -16 chip.  The question that I have is if I were to do the
same thing with my Tandy 3000NL, would I be able to run OS-9000 on the machine.
If so what costs will I incure to buy the OS-9000 operating system and any
other additional hardware/software?

#: 9239 S12/OS9/68000 (OSK)
    22-Jan-91  20:48:48
Sb: #termcap functions
Fm: Bob van der Poel 76510,2203
To: all
I notice in the termcap docs I have for os9-68000 that there is no definition
(name) for cursor on/off. The program I'm writing would like to do it's own
cursor stuff, if the terminal's cursor can be turned off . . . so, does anyone
know if there is a definition for this? I suppose that I could pick something
at random (from what I understand from termcap nothing is really predefined),
but I'd like to keep some consistancy. I guess the other way to handle this is
via the programs own config files, but it would be nice to keep all the output
things in termcap. Any suggestions appreciated.
There is 1 Reply.

#: 9247 S12/OS9/68000 (OSK)
    22-Jan-91  23:46:29
Sb: #9239-termcap functions
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Bob -
I recently posted full termcap docs to DL3. You may want to refer to them (if
you haven't already). In the meantime, I don't know for sure if a cursor CAN be
turned off using conventional termcap.
Pete

#: 9259 S12/OS9/68000 (OSK)
    23-Jan-91  20:04:26
Sb: #ss.screen_size
Fm: Bob van der Poel 76510,2203
To: all
In writing my VED text editor for OSK I've come up with a minor problem. It
seems that OSK does not have a standard SS.Screen_Size status call. I
understand that Kevin's drivers for the MM/1 will have that, but using this
will mean that the program will only work in that in that environment. VED will
use termcap to determine all the other terminal stuff, but using termcap to get
the size is a problem since termcap does not know about windows (Kevs or anyone
elses). My plan is to use a small auxillary program called Ved_size (or
something else equally creative) which would simply get the screen size either
as a constant or via a getstt and exit with the size as its F$Exit paramater.
As new drivers etc. are developed the user would need to replace this program.
I was thinking that VED could fork to ved_size and get the resultant
information from the error status returned to F$wait (use the lower half of the
long word for the columns, the upper for the rows...). It does seem rather
convoluted to me...anyone with a better idea? Comments?
BTW, VED is up and running on my single board MM/1. Some debugging left to do,
etc., but it should be ready for market within a month or so. Now I just have
to decide if I should follow my low-price philosophy or try to hang on to the
high-price one the OSK market seems to like.
 e
There are 2 Replies.

#: 9266 S12/OS9/68000 (OSK)
    24-Jan-91  05:21:21
Sb: #9259-ss.screen_size
Fm: Kevin Darling (UG Pres) 76703,4227
To: Bob van der Poel 76510,2203
Well... don't fork to ved_size, but call it as a subroutine module instead?
PS: sorry haven't answered you about control codes.  I understand that you have
one of the non-palette prototype machines?  The latest driver hasn't been
back-ported to that one yet... and I've forgotten what codes the old driver
supported.  The new one supports many more.  Hang tight. Working on it. best -
kev

#: 9269 S12/OS9/68000 (OSK)
    24-Jan-91  12:11:42
Sb: #9259-ss.screen_size
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203
Bob -
You can't use the lines and columns entries in the termcap? These would be fine
for conventional terminals, and the scsize call would be supported for winders.
Sounds as if your bases are already covered...
Re: pricing philosophy.... remember two things -
a) A lot of GOOD PD stuff is available (uemacs, stevie [vi clone], etc.) that
has been or is a candidate for being ported to an OSK environment.
b) Keeping prices within the impulse-buy range is certain to net you a greater
volume of sales.
Pete

#: 9282 S12/OS9/68000 (OSK)
    25-Jan-91  22:17:49
Sb: #9247-termcap functions
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Pete, Yes, I had a look at the termcap stuff you uploaded. Not too much help
for my problem. Looking over some of the termcap entries in the OSK termcap
file I notice that there are a number of entries for different terminals which
are not covered in the termcap capabilities list in the OSK docs. Does anyone
know of a more comprehensive list?
Actually, adding your own functions in not a problem. I could easily add to the
file entries for anything I want. I suppose for cursor on/off I could use C1
and C2 or whatever. The thing I'd like to know is if there is already a name
for this function or, if not, any suggestions for a standard name.

#: 9297 S12/OS9/68000 (OSK)
    27-Jan-91  13:39:54
Sb: #termcap
Fm: Roy Dacus 70721,1113
To: Bob van der Poel 76510,2203 (X)
Hi Bob,
The parameters for CURSOR INTENSITY are:
vs=    Make cursor very visible.
vi=    Make cursor invisible.
ve=    Make cursor normal (undo effect of vs= and ve=).
A very good book on this subject is "termcap & terminfo" from
O'Reilly & Associates, Inc.  Phone (800)338-6887.
                          Roy Dacus
There is 1 Reply.

#: 9310 S12/OS9/68000 (OSK)
    28-Jan-91  21:15:04
Sb: #9297-termcap
Fm: Bob van der Poel 76510,2203
To: Roy Dacus 70721,1113 (X)
Thanks Roy... My manual entry for vs and ve says something about end/start
"open/visual mode". Could be that in Unix-ise that means the same as fiddle
with the cursor...
I'll give  O'Reilly, etc. a call and find out the details on the book.
Thanks again.

#: 9303 S12/OS9/68000 (OSK)
    27-Jan-91  22:07:58
Sb: #9266-#ss.screen_size
Fm: Bob van der Poel 76510,2203
To: Kevin Darling (UG Pres) 76703,4227 (X)
Hmmm, using a subroutine module for ved_size is probably a good idea--but I
have no idea how to do that. Guess the module would have to be written in
assembler and then what? We get the address of the module via modlink and then
jump to the entry point? Return stuff in registers.
The control code thingie is okay. Yes, I have the single board proto. I figured
out the screen stuff from the termcap file--not much there is there? Unless I'm
missing things, it lacks all the goodies like underline and reverse video. Just
as well, it forced me to set ved up so that it can deal with stupid terminals.
And when I get the updated software it'll just be a matter of updating the
termcap entry. Oh, and I do hope that the final version of the window driver
will have entries of an extended character set ($20..$FF).
There is 1 Reply.

#: 9309 S12/OS9/68000 (OSK)
    28-Jan-91  18:05:40
Sb: #9303-ss.screen_size
Fm: Bill Dickhaus 70325,523
To: Bob van der Poel 76510,2203 (X)
That does bring up a good point. Are there OSK C functions for setting up
subroutine modules? Are there any out there for OS9 LII? Calling of subroutine
modules can be hacked together, but there is no standard that I'm aware of for
setting up C subroutine modules, and I have also never heard of a cstart.r for
subroutine modules. This might require linker changes too, ugh.
I have an ulterior motive here, since I'm working on a large C project that
_might_ benefit from subroutines. Thoughts everyone?
Bill

#: 9315 S12/OS9/68000 (OSK)
    28-Jan-91  22:48:56
Sb: #OS-9 for Sinclair QL
Fm: Vincent Foglia 70451,721
To: all
Does any one know if there is a copy of the OS/9 Operating System that will run
on a Sinclair QL system???? A buddy of mine has a complete QL system and would
like to be able to run OS/9!!!  Any help would be appreciated!! He can be
contacted at:
Steven Blackford Rt. 1 Box 30-B Delta, IA 52550
Thank you................ Vincent Foglia
There is 1 Reply.

#: 9319 S12/OS9/68000 (OSK)
    29-Jan-91  06:58:30
Sb: #9315-#OS-9 for Sinclair QL
Fm: James Jones 76257,562
To: Vincent Foglia 70451,721 (X)
I think that your best bet would be to call the British company Cumana Ltd. and
ask whether they've done such a port.  I don't have their address or phone
number at hand, but I'll see if I can find it.
There is 1 Reply.

#: 9352 S12/OS9/68000 (OSK)
    31-Jan-91  12:26:44
Sb: #9319-OS-9 for Sinclair QL
Fm: Vincent Foglia 70451,721
To: James Jones 76257,562 (X)
Thanks... He'd really like to run os9 his computer.. So we could transfer
programs, and applications. I run os9 on a coco... He7d like to run some of the
same programs I do.

#: 9325 S12/OS9/68000 (OSK)
    29-Jan-91  20:08:33
Sb: #9309-subroutine modules
Fm: Steve Adams 71610,3707
To: Bill Dickhaus 70325,523 (X)
    Howdy! Since I use OSK subroutine modules a lot, I thought I would
throw in my two cents worth.  I cannot speak for OS9 LII since I never
really used it in depth.  Forgive me if I cover old ground.
    First the advantages:
    Advantage #1) Subroutine modules are an excellent way to expand
the functionality of a program at run-time.  If the interface to the
subroutine module is properly defined, programs can use them to add
new features dynamically.  (slight bragging follows) I wrote an object
oriented graphics editor for designing user interfaces that can be
expanded by the user to include new I/O objects.  The new objects can
be edited as if they were hardcoded into the editor, including
rubber-banding, without making any changes to the graphics editor.
    Advantage #2) An unlimited number of subroutine modules may be
used by a program at once.  If trap modules are used, only 15
different modules may be used at once.
    Advantage #3) As with any properly written OSK module, they may be
shared by several processes to reduce memory usage.
    Now the disadvantages:
    Disadvantage #1) This is probably the most frustating.  No static
variable space may be used within the subroutine module.  This limits
you to using stack variables, and 'malloc()'ed variable space.  Some C
variables declared in cstart are accessable from a subroutine module.
    Disadvantage #2) Because no global variable space is allowed, jump
tables are not allowed.  This effectively limits the size of
subroutine modules to 32K.  If you are REAL careful with your coding
and avoid distant 'bsr's, this size limit can be expanded.
    Disadvantage #3) There is no standard interface to subroutine
modules that I know of.  This makes its harder to get started
initially.  This can also be viewed as an advantage once you know what
you are doing, since it allows your interface to the module to exactly
match your applications needs.
        (continued in another message)

#: 9326 S12/OS9/68000 (OSK)
    29-Jan-91  20:10:24
Sb: ##9309-subroutine modules
Fm: Steve Adams 71610,3707
To: Bill Dickhaus 70325,523 (X)
        (continued from previous message)
    Here are some (I hope) helpful hints for using C with subroutine
modules.
    Use the -i and -x command line options with 'cc' when
compiling subroutine modules.  This will cause the cio and math trap
handlers to be used, and reduce the size of the subroutine module by
about 10K depending on the functions called.
    To reference C variables declared in cstart.r, include the
following code segment in the assembly language header to the
subroutine module:
* Resolve the references generated from Cstart.   Originate from -$8000
    org    -32768
_sttop      do.l    1    stack top
_mtop:      do.l    1    current non-stack memory top
_stbot:     do.l    1    current stack bottom limit
errno:      do.l    1    global error holder
_totmem:    do.l    1    total data memory used
_sbsize:    do.l    1    top of process memory (sbrk)
    I hope this stuff is useful.
    Steve Adams
There is 1 Reply.

#: 9347 S12/OS9/68000 (OSK)
    30-Jan-91  21:32:01
Sb: #9326-#9309-subroutine modules
Fm: Bill Dickhaus 70325,523
To: Steve Adams 71610,3707 (X)
Steve, that information is helpful, since I don't have an OSK machine yet, I
haven't gone to far in learning how things like subroutines may work
differently than with OS9 LII. I was hoping that subroutine handling functions
were available for OSK, mainly because I just didn't want to have to do some of
the things you described, like hard coding cstart.r variables, using assembler
code, etc. And I agree, the major disadvantage of subroutines is the inability
to access static variables. I'm not too familiar with jump tables tables, looks
like its time to dig into the manuals again! Thanks for the info..
Bill

#: 9340 S12/OS9/68000 (OSK)
    30-Jan-91  19:05:49
Sb: #9203-OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76
Well, Hello stranger!
I guess I've had no problems with linking and the libs.  I just wanted to check
with everyone.
Thanks Carl, Pete and JJ for you respnses.  And sorry it took so long for me to
reply to y'all.
BTW Is the CK_clib.l use the same docs as the 6809 version?  Or are there other
goodies in the OSK version?  Thanks,
Mike

#: 9399 S12/OS9/68000 (OSK)
    04-Feb-91  20:39:36
Sb: #Assembler
Fm: Rick Caldwell 72067,2567
To:  72325,1327 (X)
One solution to the byte/word specifiers is to make the language strongly typed
like C++.  You would have to declare the variables and their type before use. 
By allowing unions you could overlay several types in the same location or
register.  This would allow the assembler to catch spelling errors and to
automatically select the proper mode (byte/word) and catch errors like trying
to move a word into a byte.  You would probably need a casting type operation
to tell the assembler to move bytes into words when you really want do that so
that you don't get a warning on typical assembler tricks/methods.
As I've just started studying object oriented programming I see several ideas
in it that would be nice to have in assembler. In Len Dorfman's book
"Object-Oriented Assembly Language" he uses the macro capability of the PC's
assembler to add the structured programing constructs you've been talking about
(while's, if-then-else, do while's, for loop's, etc).  He also adds the object
oriented features via the macro capability of the assembler to allowing you to
define classes with methods and to inherit from other classes. I've just
scanned thru his book and I'm still learning about oop, but it looks like a
slick way to develop code and libraries.
To do this in a native assembler with an easy to use grammar, proper scoping of
variables (local, global) within blocks and programs would really make
programming in assembler fun.  If the OOP aproach really works, then once
you've programed for awhile and developed a class library for the common things
you typically code in your own programs you could really crank out code.  By
allowing reassignment of the registers and/or local variables (either auto or
static) when you instance an object you could reuse code without the usual
problem of searching existing code and manually reassigning the regs and
variable names.  To be totally flexible you would probably need a way to
determine if the variable was assigned to a register or to memory within the
class in order to generate the proper code when the class was instanced.
Rick Caldwell
There are 2 Replies.

#: 9426 S12/OS9/68000 (OSK)
    07-Feb-91  18:53:09
Sb: #9399-Assembler
Fm: Jack Crenshaw 72325,1327
To: Rick Caldwell 72067,2567 (X)
My thoughts exactly re the strong typing, Rick.   The only problem is: How is
the assembler to decipher things like
       D0 += D1   ?
In the case of the registers, you have to somehow tell it what you mean. Until
recently, I've been thinking that I would require typing of the registers as
well.  It makes things more orthogonal, and would result in a language that
would even compile on a different machine (in other words, if D0 were treated
as a variable).  Since you sometimes want to treat the register as one type and
sometimes as another, you'd have to allow types to be changed, which gets kind 
of awkward.
More recently, I've been thinking about borrowing a page from Intel's book, and
declare the size as part of the register definition, i.e.,
       D0B = C
       D0L = X    etc.
There still remains to decide what to do when types don't match up.  For
       D0B = D1L, should we generate some kind of conversion (But what??),
generate an error message, or simply ignore the 'L'?  More importantly, what do
we do with
       D0B = X,  where X was declared long?  Do we fetch the high byte (i.e.,
the one at the address of X) or the low byte (i.e., treat it as a type
conversion from long to byte)?
Jack

#: 9427 S12/OS9/68000 (OSK)
    07-Feb-91  18:53:16
Sb: #9399-Assembler
Fm: Jack Crenshaw 72325,1327
To: Rick Caldwell 72067,2567 (X)
For some time now I've been trying to design and build an assembler for the
68000.  Lately I've had to do it with more vigor, because I've been writing a
paper on assembler construction, which I'm giving next week.  It's been tough
sledding ... mostly because I keep crashing into the complexities of the 68000
assembly syntax.
The other day, I decided to chuck it and base my example on a simple (but
non-trivial) fictitious machine.  The language has 1-, 2-, 3-, and 4-byte
instructions and 0-, 1-, and 2-operand formats.  It has register, label, and
immediate operands, and the pseudo-ops ORG, DB, DW, and DS.  I wrote the
assembler and had it running in six working hours!
Which just proves, to me, that the 68000 instruction set is the root of the
problem.  It's gotta go!
Jack

#: 9405 S12/OS9/68000 (OSK)
    05-Feb-91  20:01:32
Sb: #X Windows OS9/ST
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
    Hi, Kevin.
    By curiosity, are you still working on a window system for OS9/ST on the
Atari ST?  It seems that Microware will have available later this year X
Windows for OS9/68000 and OS-9000.  Maybe in an Atari ST with 4 Meg of memory
it will be usable...
    Bye
There is 1 Reply.

#: 9408 S12/OS9/68000 (OSK)
    05-Feb-91  21:23:18
Sb: #9405-X Windows OS9/ST
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Denis - matter of fact, I started porting my window driver to the ST yesterday.
Only worked on it a coupla hours... should be done in a day or so of light
work.  Will letcha know when it's working.
Yes, I've heard that MW has ported the client side of X.  That leaves the
server.  Not sure how useful a small screen will be under X, tho. Perhaps if
you're taking X classes, tho...

#: 9432 S12/OS9/68000 (OSK)
    08-Feb-91  03:12:11
Sb: #ST/OSK Window Port!
Fm: Kevin Darling (UG Pres) 76703,4227
To: BILL HEALTON 73367,357 (X)
Bill - as it turns out, I got fired up the other morning and spent a coupla
hours doing a rough port to the ST.  Went so fast it was scary (albeit
monochrome mode only right now).
Then a couple of days figuring out that something is wrong with the ST process
desc defs (I think, maybe D_ defs, not sure yet) and had to disable a section
of my code until I figure it all out.
In any case, I'm sitting here staring at three monitor screens, each with two
80x13 windows, each running the same two gfx demo programs (maze is one of
them) in a window.   The delightful part is that one monitor is on a CoCo-3,
one is on an MM/1, and one is on an ST !
Still need a few days of fine-tuning and fixing, and then I'll send you a copy
to play around with.  More later - kev
There is 1 Reply.

#: 9448 S12/OS9/68000 (OSK)
    08-Feb-91  22:46:54
Sb: #9432-#ST/OSK Window Port!
Fm: BILL HEALTON 73367,357
To: Kevin Darling (UG Pres) 76703,4227 (X)
Kevin - Great News! I have just had too much job work to do more than think
about it myself. At work I am having to focus on MSDOS/MacOS/Unix for the most
part. One bright spot, if I can poke my nose in, is the OSK based Digalogs that
we are going to be hanging on our Ethernet. Sounds llke I may soon have a good
merger at home. MSDOS software availability,Mac-like GUI, and Unix(OSK)
multitasking what more could I want.
I hope(wishful thinking?) that my code was of at least some help. I can't wait
to get my hands (modem?) on your port. Will you be sending source or object? I
now have both color and monochrome monitors, so I can test all resolutions in
later developments. If you could send a demo or two with the driver I would
appreciate it.
I will definitely find  time to help evaluate/debug this.
EAW(eagerly awaiting windows) .... Bill Healton 73367,357
There is 1 Reply.

#: 9458 S12/OS9/68000 (OSK)
    09-Feb-91  22:39:34
Sb: #9448-ST/OSK Window Port!
Fm: Kevin Darling (UG Pres) 76703,4227
To: BILL HEALTON 73367,357 (X)
Bill - actually, I may have to send source also... as I only did the monochrome
port first... which is (so far - got a PUT gfx data bug, I think) pretty easy
to do.  The wacky color data layout of the ST will be a _real_ bear to convert,
I suspect ;-).
The demos I'm using right now were written for the MM/1 by Mike Haaland. Tho I
did go a little overboard the other night and use Bob Santy's 6809 emulator to
run the CoCo version of "maze" on the ST.  Slow, but...

#: 9463 S12/OS9/68000 (OSK)
    10-Feb-91  07:51:41
Sb: #ST/OSK Window Port!
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
    Hi, Kevin.
  I'm in a hurry me too to see/try your window system for the ST. I have a
monochrome monitor also. I'm using X Window sometimes at work, but yes, a good
tutorial book I will have to read before using X with comfort.
  By reading Atari ST magazines from France I can see that they are ahead of us
in Europe; they advertise the OS9/68000 for the Atari ST. This port does not
use ROM calls, comes with more software and is using a graphic user interface
with windows. It is from Cumana, of course.
   BYE
There is 1 Reply.

#: 9471 S12/OS9/68000 (OSK)
    10-Feb-91  22:23:57
Sb: #9463-ST/OSK Window Port!
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENIS CHARTRAND 72561,2714 (X)
Yes, I'd love to see the Cumana port.  Do those mags give a price/address?
  thanks! - kev

#: 9499 S12/OS9/68000 (OSK)
    14-Feb-91  08:38:57
Sb: #9340-#OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)
I guess the 68K version of my lib would use the same docs as the 6809. As
always, I use the source (and memory) for docs and have nothing formal.  I
don't think there is anything extra but don't really recall at the moment.  I
will holler if something surfaces....
Carl
There is 1 Reply.

#: 9513 S12/OS9/68000 (OSK)
    15-Feb-91  06:02:19
Sb: #9499-#OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76 (X)
Ok,  I assume there are some new header files that go with the 68k version,
n'est pa?  BTW- do you want a bunch of Standard-C string functions I have here?
They'd be a nice addition.  If you'd like I can look around for more Standard-C
stuff.  (By Standard I mean ANSI Standard)
Mike
There is 1 Reply.

#: 9517 S12/OS9/68000 (OSK)
    15-Feb-91  09:44:03
Sb: #9513-#OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)
Sure.  I'll take a look at the Standard-C stuff.  Mw did a much better job with
the 68K of getting that stuff in the lib - mem* stuff for example.  Yeah, there
are some header files.  I assume you didn't get them...... I can mail them here
I think.
Carl
There is 1 Reply.

#: 9527 S12/OS9/68000 (OSK)
    16-Feb-91  07:21:06
Sb: #9517-OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Carl Kreider 71076,76
Great!  Yeah, you can e-mail 'em or post 'em if you want.  (The headers, that
is)   Ok I'll put together a file for ya of the Standard C stuff I have.  Do
you have or want a copy of LHArc?  Saves Attributes and file descriptor stuff
in the .lzh file.
Mikeh

#: 9523 S12/OS9/68000 (OSK)
    15-Feb-91  20:12:35
Sb: model 16
Fm: Bob van der Poel 76510,2203
To: all
Does anyone know if os9 was ever ported to the model 16 from RS? A friend of
mine has such a machine and was wondering...

#: 9529 S12/OS9/68000 (OSK)
    16-Feb-91  09:16:26
Sb: Cumana Port
Fm: DENIS CHARTRAND 72561,2714
To: Kevin Darling
     Price for Cumana port is about the same than our Professional pack, maybe
$100 more, but they have more software in that package, Sculptor, Dynacalc,
Stylograph, graphic interface, etc.
    I'm suppose to go in Germany next summer, I'll try to find more.
BYE

#: 9560 S12/OS9/68000 (OSK)
    18-Feb-91  08:56:14
Sb: #9527-OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Mike Haaland 72300,1433 (X)
No, I don't have lharc.  Yes, I would like a working version.  It is one of the
things on the list.  - Carl

#: 9588 S12/OS9/68000 (OSK)
    21-Feb-91  21:49:37
Sb: #Egads! Can't signal!
Fm: Mark Wuest 74030,332
To: all
I am looking for ideas to work around a "feature" of OSK device drivers. When a
process is in a write() and it gets blocked (flow control, other end of pipe
not read()ing, whatever), it is not possible to send signals other than SIGKILL
(which it can't catch) to that process until it wakes up from the blocked
write(). Of course, for read(), one can do _gs_rdy() beforehand to make sure
there is something there to read() before actually doing it. What about
write()? Any ideas?
 FWIW: the block occurs on a write to /pipe, an unnamed pipe. I have presently
worked around it with something like:
 while(1){
     if(_gs_rdy(path)
         read(path,&buf,sizeof(buf);
 }
 After I send it a SIGHUP, since all I want it to do is die gracefully.
 BUT: sometimes it might be nice to signal a blocked process to stop write()ing
and do something else.
 I hope my question is clear. Microware Technical Support had no general answer
(except that, in some cases, you know the size of the device's buffer, and you
can do _gs_rdy() on it and subtract to get the amount of buffer left).
 Thanks.
 Mark
There is 1 Reply.

#: 9596 S12/OS9/68000 (OSK)
    22-Feb-91  18:22:51
Sb: #9588-#Egads! Can't signal!
Fm: Kevin Darling 76703,4227
To: Mark Wuest 74030,332 (X)
Mark -
Hmmm. You're right... even nice drivers only return from the midst of I/O if
the process has been Condemned by a deadly signal.
In most cases, you want it that way, of course.
One workaround is to fork off a tiny process to do the writes... communicating
via a data module buffer, for instance.  The main process can deal with the
non-deadly signals.
In effect, you have to implement asynchronous I/O operations yourself. Hope
this gives some ideas. ? - kev
There is 1 Reply.

#: 9623 S12/OS9/68000 (OSK)
    25-Feb-91  08:52:21
Sb: #9596-Egads! Can't signal!
Fm: Mark Wuest 74030,332
To: Kevin Darling 76703,4227
The idea of a child to do only i/o hadn't struck me. Since we have ported Unix
message queues for our project, it could be pretty easy in some instances.
Thanks for the suggestion!
 We wrote our own Packet File Manager (not pkman) for our block-serial protocol
conversion work and specifically wrote our drivers to allow signals up to 15
(SIGTERM).
 Thanks again.
 Mark

#: 9603 S12/OS9/68000 (OSK)
    22-Feb-91  22:59:57
Sb: #9523-#model 16
Fm: Wayne Day 76703,376
To: Bob van der Poel 76510,2203 (X)
No, it wasn't.
Wayne
There is 1 Reply.

#: 9615 S12/OS9/68000 (OSK)
    23-Feb-91  20:18:28
Sb: #9603-model 16
Fm: Bob van der Poel 76510,2203
To: Wayne Day 76703,376 (X)
Thanks...that is a same since there must be a bunch of 16s out there gathering
dust....

#: 9670 S12/OS9/68000 (OSK)
    03-Mar-91  12:25:28
Sb: Need 'C' Programmer- MA
Fm: Scott Stingel 73260,3123
To: ALL
Need 'C' programmer/consultant in the Boston metro area to develop radio
communications software.   Must be experienced in writing "embedded"
EPROM-based 'C' code to run on a 68000-family CPU.  Math or engineering
background and standalone (ie: no operating system) programming experience
desirable.   Please send me an EasyPlex. Thanks, Scott Stingel   73260,3123

#: 9709 S12/OS9/68000 (OSK)
    07-Mar-91  00:39:42
Sb: #ar68.bin problem
Fm: Scott Tegtmeyer 72560,1503
To: All
Dear Forum Members,
I have been trying to run ar68.bin on my 68030 VME computer for several weeks. 
I have contacted several Forum members and Microware customer support, but I
still have problems.
The problem I am having is that when I try to run ar68.bin, OS-9 thinks it is a
procedure file and prints 'Can't execute "J" ...'.
When I do an IDENT on the file I get the message 'incomplete module'. 
When I looked at the file size in the file itself, I found that it was larger
than what the dir command showed.  I think this indicates that the file was
truncated, but I am not sure how this happened.
If anyone has the source to ar68.bin, or knows how to fix the problem, I would
like to hear from you.
Sincerely,
Scott Tegtmeyer 
There is 1 Reply.

#: 9712 S12/OS9/68000 (OSK)
    07-Mar-91  03:18:58
Sb: #9709-#ar68.bin problem
Fm: Kevin Darling 76703,4227
To: Scott Tegtmeyer 72560,1503 (X)
Hi Scott - the source to AR should be in DL9... unfortunately, it's in AR
format :-).
Can you load AR?  If so, then you can Save it back out and that should fix
things up.  Ooops.  Wait.  You say part of it is missing?  You may have to
download it again.
PS: the "can't execute J" thing.... always confuses people.  What that means is
that you have the command in the wrong place.  Try moving it to your commands
directory, and be sure to set execution attributes on it.
Here's the deal.  As you know, OS9 searches memory first, then the exec dir,
and then looks in the data dir for a *shell procedure* text file.  GRIN. Guess
what the first byte of an OS9 module is in ASCII?   If you guessed "J", you're
correct!   The shell tried to run it as a shell script, and got terribly
confused.   best - kev
There is 1 Reply.

#: 9722 S12/OS9/68000 (OSK)
    08-Mar-91  00:57:45
Sb: #9712-#ar68.bin problem
Fm: Scott Tegtmeyer 72560,1503
To: Kevin Darling 76703,4227 (X)
Kevin,
Thanks for responding to my request.
Unfortunately, since the AR program source is in AR format, I can't unpack it
until I get AR running.
I tried downloading the file 3 times, twice on Compuserve and once on a
friend's PC using the Bit-Com communications program.  All three files compared
the same and produced the same result ... 'incomplete module' when I ran the
IDENT program.
I was hoping you might have a copy of AR unpacked which you could send to me or
upload onto Compuserve.
If you can't upload or send the source of AR, maybe you could suggest some
other approach to this problem. 
Thanks,
There is 1 Reply.

#: 9730 S12/OS9/68000 (OSK)
    08-Mar-91  14:09:58
Sb: #9722-ar68.bin problem
Fm: Kevin Darling 76703,4227
To: Scott Tegtmeyer 72560,1503 (X)
Scott - I wonder what's going on?  I just downloaded AR68.BIN (with the B
protocol), and Ident said all was okay.  It was 21,106 bytes long.
What happens when you try to load it?  "load -d ar"  Does OS9 refuse?
I've asked that a copy of a merged text version of the AR source be placed into
DL9 for you... should show up within a coupla days.  Worst case, you can edit
that out into separate files and compile it.  Keep us informed.
  best - kev

#: 9733 S12/OS9/68000 (OSK)
    08-Mar-91  17:08:15
Sb: #question
Fm: Kevin L. 71521,2723
To: all
 Has anyone heard of a profesinal 68000 based computer made by TBL, or Foxmyer?
I can get one for next to nothing! I would first like to know if I can get any
software for it, especialy OSK. Kevin
There is 1 Reply.

#: 9734 S12/OS9/68000 (OSK)
    08-Mar-91  19:15:46
Sb: #9733-#question
Fm: James Jones 76257,562
To: Kevin L. 71521,2723 (X)
Will the seller let you take a gander at the manuals before you buy?  I think
I'd ask about that.
I've never heard of TBL or Foxmyer.
There is 1 Reply.

#: 9736 S12/OS9/68000 (OSK)
    09-Mar-91  00:09:31
Sb: #9734-question
Fm: Kevin L. 71521,2723
To: James Jones 76257,562 (X)
I may get it free! and I'm not sure about the manuals. If he has any or not but
Why didn't I think about that ? Prety stupid huh? Thanks Kevin

#: 9751 S12/OS9/68000 (OSK)
    10-Mar-91  12:54:13
Sb: #9560-#OSK Clib.l Order
Fm: Robert Heller 71450,3432
To: Carl Kreider 71076,76
*I* have a working version of LHArc - I ported it from the UNIX version from
unix.sources (ftp'ed from uunet.uu.net).
                Robert
There is 1 Reply.

#: 9761 S12/OS9/68000 (OSK)
    11-Mar-91  04:29:17
Sb: #9751-#OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Robert Heller 71450,3432 (X)
This could be interesting, we've been playing with a ported version of LHArc
now for about 6, maybe 8 months!  Did you define a new extended header for OSK
file info? (Store the attributtes, etc...)  This version does, and I'd hate to
see multiple/different versions around for OSK.  We've have been creating and
extracting data with LHArc for some time now.  So we need to keep something
like this standardized.  Know what I mean?
Mike Haaland
There is 1 Reply.

#: 9766 S12/OS9/68000 (OSK)
    11-Mar-91  06:10:45
Sb: #9761-OSK Clib.l Order
Fm: Robert Heller 71450,3432
To: Mike Haaland 72300,1433 (X)
Mike:
   I just did a quick and dirty port of the UNIX version.  I needed it in a
hurry - the PTB on FidoNet decided to change the archive method for FidoNews
from ARC 5.12 to LHArc without warning anyone.  My only other choise would have
been to find someone with a Mess-dos machine to unpack the FidoNews files for
me.  So I FTP'ed the UNIX port of lharc and ported it.  I only use it to unpack
FidoNews issues (a minor pain since the files arrrive on my CP/M-68K machine
and I have to ship the file to my OSK machine to unpack and repack as an .ARC
file for processing on my CP/M-68K machine).  I also ported the UNIX version of
UNZIP too (a simular quick and dirty done in "self-defense").
It seems that the mess-dos world seems to be insisting on using these
non-portable archiving methods...  And seem to have little interest in
supporting people with other operating systems (as if such people are some
oddball minority or something).
               Robert

#: 9845 S12/OS9/68000 (OSK)
    17-Mar-91  21:11:00
Sb: #The MM/1 Serial Port!
Fm: Keith H. March 70541,1413
To: all
Hello:
Can any one tell me how to hook up my CoCo 3 to a MM/1 a hundred sixty feet
away?
I would like to run spreadsheets, word processors, graphics programs from the
CoCo.
Any Help would be greatly appreached <sp?>
Throught the MM/1 RS-232 port , Serial or Parallel ?
Thanks for the  HELP.
Keith H. March
There are 2 Replies.

#: 9854 S12/OS9/68000 (OSK)
    18-Mar-91  05:59:21
Sb: #9845-The MM/1 Serial Port!
Fm: James Jones 76257,562
To: Keith H. March 70541,1413
At 160 feet you may run into problems.  The RS-232 standard says no more than
fifty feet--this constraint is present because if a serial device puts out a
signal that is just within specs, past that distance it isn't usable.  A place
I used to work had trouble with that once: we had terminals hooked up over a
distance of fifty feet or a bit over, and they worked just fine, but a lab
instrument with RS-232 out was flaky.  A friend with more hardware knowledge
than me or my boss hooked up an oscilloscope, and one could see very easily the
effects of cable capacitance and resistance.  Smoothed that signal right out
into mush.
One can get special low-capacitance cable for longer serial runs, though I
don't recall how far one can go with it.

#: 9857 S12/OS9/68000 (OSK)
    18-Mar-91  11:30:32
Sb: #9845-The MM/1 Serial Port!
Fm: Pete Lyall 76703,4230
To: Keith H. March 70541,1413
Keith -
While the serial spec (well, RS-232C) states a maximum length of 50 feet, I
regularly get away with many times that. Had runs in my old house that were in
excess of 200 feet, and I have been to sites where customers run lines
approaching 1000 feet.
Pete

#: 9880 S12/OS9/68000 (OSK)
    21-Mar-91  12:29:09
Sb: #9751-#OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Robert Heller 71450,3432 (X)
I would like a copy if you could see your way clear to do that.  - Carl
There is 1 Reply.

#: 9931 S12/OS9/68000 (OSK)
    24-Mar-91  08:53:24
Sb: #9880-#OSK Clib.l Order
Fm: Robert Heller 71450,3432
To: Carl Kreider 71076,76
Carl:
        Can you read Universal Format 3.5" floppies?  If so, I'll send you what
I have.
                        Robert
There is 1 Reply.

#: 9982 S12/OS9/68000 (OSK)
    26-Mar-91  19:20:00
Sb: #9931-#OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Robert Heller 71450,3432 (X)
Robert,
        I uploaded the OSK LHArc to lib 12 along with the docs.  As doon as I
can message the source into not depending upon the UNIXLIB.L in lib 12, I'll
upload the source too.  (If we really want it distributed?)  Not sure about
that.  I'd like you to give this LHARC a try and lemme know what you think.
        Can you upload your UnZIP port?  I've been having trouble here, I keep
getting error 102 (Bus Trap).  I'm pretty sure it's a stray pointer, but
tracking it down is not very easy.
        I too would love to see the UnZip source you've messaged.  How bout
emailing it?  In AR format?
Mike Haaland /ex
There is 1 Reply.

#: 10078 S12/OS9/68000 (OSK)
    31-Mar-91  20:11:11
Sb: #9982-#OSK Clib.l Order
Fm: Robert Heller 71450,3432
To: Mike Haaland 72300,1433 (X)
Mike:
        I don't use LHarc much except to unpack FidoNews.  I only use Zoo or
compressed tar files, since they are most widely available.  Since I don't deal
much with MS-DOS systems (only FidoNet nodes and FidoNet stuff - NODEDIFFs and
FidoNews), I don't feel any need to use these "poorly" designed MS-DOS
archivers.  I also have little desire to bother with the ultimate in
compression. Worrying about saving a few bytes here and there is not worth
hasseling with non-portable code.  I only bothered with UnZip so I could get at
some source code some MS-DOS people ZIP'ed...
        I didn't get a chance to read your message until late Sunday night. I
only call CIS on the weekend.  I snarfed the UnZip code from BIX's unix
listings. I did a quick & dirty port - sort of the pound to fit.  I think I did
things like delete the code to update the file attrs rather than try to put in
OSK code to handle it (I didn't care about preserving file dates, etc.) and I
didn't even look to see if unzip dealt with text file handling (i.e. fixing
MS-DOS's CRLF's to UNIX's LFs or OSK CR's) - since I have a program to converts
between text file formats this was an unneeded feature.
        CompuServ's file xfer is also very slow (I only have an XModem/checksum
program) - seems to have very large packet turn-around delays.  CompuServ's
"local" number is also a long distance phone call, so I really don't want to
stay on too long.  The best thing is this:  I can put my UnZIP code onto a
Universal Format 3.5" floppy and send it via Snail Mail.
                        Robert
There is 1 Reply.

#: 10096 S12/OS9/68000 (OSK)
    02-Apr-91  20:34:03
Sb: #10078-#OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Robert Heller 71450,3432 (X)
Robert,
    I'd love to see your UnZip stuff. I'd appreciate the binary on that 3.5
disk too!  My address is :
 Mike Haaland
 4341 Gannet Cir. #174
 Las Vegas, Nv  89103
        If you want the release version and docs to LHArc, they are in Lib 12.
Thanks,
Mike
PS.  I didn't know ZOO was available for OSK either!!  Where did you snarf ZOO.
There is 1 Reply.

#: 10133 S12/OS9/68000 (OSK)
    06-Apr-91  10:51:19
Sb: #10096-#OSK Clib.l Order
Fm: Robert Heller 71450,3432
To: Mike Haaland 72300,1433 (X)
I first get Zoo from uunet.uu.net (comp.sources.???), and later it appeared on
EFFO's disks.  You want Zoo too?  There should be plenty of room on the floppy
for Zoo and UNZip.
                        Robert

#: 9918 S12/OS9/68000 (OSK)
    23-Mar-91  22:29:10
Sb: #Atari ST Windows
Fm: BILL HEALTON 73367,357
To: Kevin Darling 76703,4227 (X)
Kevin - I have just regained power 10 days & 17 hours after the "Ice Tornado"
wiped out power to most of central Indiana. What is the latest on the ST
version of windows? I hope to see something soon.
Thanks, Bill Healton 73367,357
There is 1 Reply.

#: 9921 S12/OS9/68000 (OSK)
    23-Mar-91  22:56:10
Sb: #9918-Atari ST Windows
Fm: Kevin Darling 76703,4227
To: BILL HEALTON 73367,357 (X)
10 days without power?!  Yikes.  C'mon down heah to NC... we only have
hurricanes... much nicer ;-).    Had to unplug the ST to plug in some other
junk;  arrgh I need to hook it back up.  Many apologies for delay.

#: 9965 S12/OS9/68000 (OSK)
    25-Mar-91  22:13:37
Sb: #Ports on the MM/1
Fm: Keith H. March 70541,1413
To: ALL
Hello:
From my previus <sp?> message (MM/1 Serial Port) Are their any other ways I can
spand that 160 feet?
Paralle, lan, etc.
Keith March
There are 2 Replies.

#: 9966 S12/OS9/68000 (OSK)
    26-Mar-91  00:37:55
Sb: #9965-Ports on the MM/1
Fm: Pete Lyall 76703,4230
To: Keith H. March 70541,1413 (X)
Keith -
Parallel is usually much more restrictive than serial. Typically, parallel
should be 15 feet or so. You may get away with more, but probably not much
more.
LAN - sure, once it's defined/available.
You should not have much of a problem traveling 160 feet on serial signals. I
used a run close to 400' in my old house employing basic 6 conductor phone wire
(tan insualtion kind.. not even shielded).
Pete

#: 9967 S12/OS9/68000 (OSK)
    26-Mar-91  05:25:34
Sb: #9965-#Ports on the MM/1
Fm: Dan Robins 73007,2473
To: Keith H. March 70541,1413 (X)
Keith,
  Although I doubt it's applicable now...I'm getting little bits of info now
and then on LANs which run on a wireless type system. I believe one of the
companies is awaiting FCC approval on a frequency group (then, maybe they've
already received it)...but that probably will be something in use in the future
and would cure your "160 feet" problem.
   Dan
There is 1 Reply.

#: 10066 S12/OS9/68000 (OSK)
    30-Mar-91  23:12:04
Sb: #9967-Ports on the MM/1
Fm: Bud Hamblen 72466,256
To: Dan Robins 73007,2473 (X)
You can translate from RS232 to a method that permits a longer haul, then
translate back to RS232.  There are a variety of short haul modems for that
kind of thing.  You could go from RS232 to a couple of twisted pair lines and
back to RS232 with some line drivers if you want to whip up something yourself.

#: 10019 S12/OS9/68000 (OSK)
    27-Mar-91  23:28:50
Sb: #tops sh
Fm: Brett Wynkoop 72057,3720
To: osk users
Greeting-
     I just sent up the TOPS bourne shell broken out from the LARGE file I got
it in.  I put it in DL12.  I did this because I found that many of the binarys
on the tape I had (which was made from disk1) would not work correctly on the
MM1.  I figured I would save others some time/trouble
-Brett
There are 2 Replies.

#: 10022 S12/OS9/68000 (OSK)
    28-Mar-91  05:20:31
Sb: #10019-tops sh
Fm: James Jones 76257,562
To: Brett Wynkoop 72057,3720
I've heard from some folks that at least some of the TOPS stuff is dependent on
the way things work on Atari STs (i.e. what the programmers who wrote or ported
it were using).  Initially, the TOPS people didn't send out source code, but
they may be doing that now, so it may be possible to find and correct the
problems.

#: 10025 S12/OS9/68000 (OSK)
    28-Mar-91  14:56:38
Sb: #10019-tops sh
Fm: David 76416,2451
To: Brett Wynkoop 72057,3720
I've noticed this too. Specificaly I'm wondering how to recall the last command
line when using SH.  On the Atari you can use the up arrow but this doesn't
work on any other terminal.

#: 10137 S12/OS9/68000 (OSK)
    06-Apr-91  19:49:02
Sb: #10133-#OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Robert Heller 71450,3432 (X)
Please!  I'd like to see just about every ARchive/De-archive program running
and available so we can get all that source code from the other machines. So
Yes!  Please send ZOO too!
Thanks,
Mike
There is 1 Reply.

#: 10147 S12/OS9/68000 (OSK)
    07-Apr-91  05:27:55
Sb: #10137-#OSK Clib.l Order
Fm: Bob Taylor 73270,3124
To: Mike Haaland 72300,1433 (X)
For your information the source for the OSK port of zoo is located in DL12.
Try zoo.ar.
Bob Taylor
There is 1 Reply.

#: 10148 S12/OS9/68000 (OSK)
    07-Apr-91  07:54:58
Sb: #10147-OSK Clib.l Order
Fm: Mike Haaland 72300,1433
To: Bob Taylor 73270,3124 (X)
Great!  Thanks Bob.  I don't know it was there.
(The Zoo source that is!)
Mike

#: 10222 S12/OS9/68000 (OSK)
    12-Apr-91  09:28:18
Sb: #9931-OSK Clib.l Order
Fm: Carl Kreider 71076,76
To: Robert Heller 71450,3432 (X)
Bob, I think at this point I should just retract my request. I am too busy to
play with lharc anyway.  But thanks much.
Carl

#: 10158 S12/OS9/68000 (OSK)
    07-Apr-91  21:02:41
Sb: #file security help
Fm: Bob van der Poel 76510,2203
To: all
Help!!! I've run into a possible problem with a program I'm writing. The
program has a help function which uses a special ASCII file for displaying the
various screens. The first time the user access the help function the file is
opened for read and scanned. The locations of the various menus and their names
is stored in an in-memory buffer. Once this scan is complete the displays of
the various screens is very fast. The file is left open and the pointers are
retained for future accesses.
This works very well. As a matter of fact, other processes can also access the
file, and since everyone opens for READ-only there is no record locking to
worry about. The problem comes if someone (like me!) decides to make changes to
the file (like adding an additional screen) when the file is in use. Making
changes really fouls the pointers up for the other guy.
So: Can my program sense somehow that the file has been modified? Or, can I
flag the file someway so that it can't be opened for WRITE when it being used.
The only easy method I can see is to set the attributes to read only, forcing
the superuser to do some deliberate fiddling before making changes. Anyone got
any other ideas? What I need is something like the 'shareable' premission which
will let others read, but not write....
There is 1 Reply.

#: 10170 S12/OS9/68000 (OSK)
    08-Apr-91  15:34:55
Sb: #10158-#file security help
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
As far as testing the file for modifications, what about doing an _gs_size()
call before each access. If _gs_size != old_size, then rescan. Obvious gotcha
is if you didn't change size, but altered the file (corrected a typo  etc.).
Another option might be to flag the time at file open, and then check the last
modified time before each access. This may or may not work, as I don't remember
if the last modified time is updated before the file is closed.
Pete
There is 1 Reply.

#: 10198 S12/OS9/68000 (OSK)
    10-Apr-91  21:57:55
Sb: #10170-file security help
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Pete, Thanks for the earlier help with my open files delimma. Actually, the
solution was pretty simple: When I go to save a file I open it for write in an
non-shareable mode. If the file is currently being read by another process
(like my help function) the open will fail and I can alert the user. Tricky
stuff this OS-9. What gets me mad is that I spent hours developing complicated
schemes using file locking, etc. which didn't work - oh well, the joys of
programming.

#: 10177 S12/OS9/68000 (OSK)
    08-Apr-91  21:15:52
Sb: #termcap and windows
Fm: Bob van der Poel 76510,2203
To: all
Going over the book "Termcap and Terminfo" has been a lot of fun, and pretty
informative. I highly suggest that anyone writing termcap applications gets a
copy of this (O'Riley and Assc., 632 Petaluma Ave, Sebastopol, CA 95472).
It mentions that there is a 'wi' termcap entry which defines a window. The
params for 'wi' are the window xstart,ystart,xsize and ysize. However, it does
not mention how to start the window. Any of you UNIX types have any more info
on this? The reason I ask is that if windowing is already defined by termcap
then it'll make writing portable applications much easier. And the applications
can then take advantage of 'hardware' windowing on units like the mm/1.
There is 1 Reply.

#: 10185 S12/OS9/68000 (OSK)
    09-Apr-91  08:59:28
Sb: #10177-termcap and windows
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
FWIW - I believe X Windows just looks at the ROW & COL values. Placement of the
window is up to the XServer (of course, or the user).
Pete

#: 10186 S12/OS9/68000 (OSK)
    09-Apr-91  16:20:50
Sb: #OSK Data Modules
Fm: Jay Truesdale 72176,3565
To: all
I downloaded the 'conf.c' program from lib 12 here which doesn't work on my
system which is running OSK V1.3.
I've narrowed the problem down with following test program.  On the first
execution of this test program the data module is successfully created as shown
by the output from an 'ident -m':
 Header for:      confblock
 Module size:     $1050       #4176
 Owner:           0.0
 Module CRC:      $330C42     Good CRC
 Header parity:   $3222       Good parity
 Edition:         $1          #1
 Ty/La At/Rev     $400        $8000
 Permission:      $333        ------wr--wr--wr
 Data Mod, Sharable
The 'munload' step at the end fails with an error 221 "(E$MNF) Module not
found."
On the second execution of the test program, the 'modlink' step fails with the
same error.
 /* test.c  */
 #include <stdio.h>
 #include <module.h>
 #include <errno.h>
 #define BLOCKSIZE 4096
 #define DATA_NAME "confblock"
 char *_mkdata_module();
 mod_exec *modlink();
 int munload();
 main ()
 {
   int error_save;
   mod_exec *commod;
   char *module_ptr;
   if ((int)(commod = modlink (DATA_NAME, MT_DATA)) == -1)
   {
      error_save = errno;
      printf("test: Error number %d after attempt to link to confblock\n",
         error_save);
      if (error_save != 221)
         exit (_errmsg (0, "Error %d while linking to module\n", error_save));
      printf("test: Attempting to create a new data module.\n");
      if ((int)(module_ptr = _mkdata_module (DATA_NAME, BLOCKSIZE, 0x8000,
         0x0333)) == -1)
         exit (_errmsg (0, "Error %d while creating module\n", errno));
      else
         printf("test: Data module created.\n");
   }
   if ((munload (DATA_NAME, MT_DATA)) == -1)
      {
         error_save = errno;
         printf("test: Error number %d after attempt to unload confblock\n",
                error_save);
      }
   exit(0); }
I'm baffled.  Anyone got any suggestions?
Thanks in advance!  -J
There is 1 Reply.

#: 10187 S12/OS9/68000 (OSK)
    09-Apr-91  18:22:08
Sb: #10186-OSK Data Modules
Fm: Pete Lyall 76703,4230
To: Jay Truesdale 72176,3565 (X)
J -
I wonder if it's the combination of LINK/UNLOAD.... I believe UNLOAD is a 'zap
til gone' call (not near books at the moment), as opposed to UNLINK, which is a
'decrement link count'. Incidentally, if just attempting to link to verify
existance... nah, never mind. I was thinking of the UNLINK command, which uses
the sequence LINK, UNLINK, UNLINK. The first locates the module and sets up
pointers, the second undoes the link that was just done, and the last effects
the actual unlink.
Pete

#: 10188 S12/OS9/68000 (OSK)
    09-Apr-91  20:52:57
Sb: #10025-tops sh
Fm: Brett Wynkoop 72057,3720
To: David 76416,2451 (X)
Greeting-
     Use Emacs editing commands.  It is in the readme file with the shell ^P is
previous line.  ^N is next line etc. Also if you just want to repeate the last
command and you have history set just do a !!
-Brett

#: 10248 S12/OS9/68000 (OSK)
    13-Apr-91  21:21:43
Sb: #Minix?
Fm: Jack Crenshaw 72325,1327
To: All
Hi, guys!  It's been awhile since I checked in.  Just wondered what I've been
missing.  Anything exciting going on?  Anyone been trying out Minix lately? 
What about PT-68/OS9?
Jack
There are 2 Replies.

#: 10257 S12/OS9/68000 (OSK)
    14-Apr-91  12:44:08
Sb: #10248-#Minix?
Fm: Steve Wegert 76703,4255
To: Jack Crenshaw 72325,1327 (X)
Hi Jack!
Drop into LIB 15 and read all the scoop on the new machines (3 of 'em). That's
what has most folk's attention these days.
Steve
There is 1 Reply.

#: 10259 S12/OS9/68000 (OSK)
    14-Apr-91  16:41:21
Sb: #10257-Minix?
Fm: Jack Crenshaw 72325,1327
To: Steve Wegert 76703,4255 (X)
OK, Steve.  I'll do that.
Jack

#: 10277 S12/OS9/68000 (OSK)
    15-Apr-91  02:45:52
Sb: #10248-Minix?
Fm: Paul K. Ward 73477,2004
To: Jack Crenshaw 72325,1327 (X)
Jack,
You may wish to check the Hot Topics library to get up to date.
Paul IMS

#: 10251 S12/OS9/68000 (OSK)
    14-Apr-91  02:12:19
Sb: #sh.ar file problem?
Fm: Ken Drexler 75126,3427
To: Sysop (X)
I recently downloaded sh.ar from user 76416,2451 in DL12, in fact, I did it
twice.  Both copies were trashed at about the 50 percent point. That is ar
unpacked about half and then reported that the file was not an ar or was
damaged.
Do you have a backup copy of the file you could post?  Having messed with
Microware's shell, I am curious to see how some one else did a shell.
Thanks for the help.
Ken
There are 2 Replies.

#: 10256 S12/OS9/68000 (OSK)
    14-Apr-91  10:20:51
Sb: #10251-#sh.ar file problem?
Fm: Mike Ward 76703,2013
To: Ken Drexler 75126,3427 (X)
Ken, the SH.AR[76416,2451] file seems ok here even though AR issues an error
after unpacking the last module. It appears there are two copies of each module
in the archive, ie:
 SH.1
 README.1
 SHELL.HELP.1
 SH
 README
 SHELL.HELP
I used the Coco "AR" program under OS9 to unpack the file. Do you get two of
everything when you burst the file?
There is 1 Reply.

#: 10366 S12/OS9/68000 (OSK)
    20-Apr-91  12:50:32
Sb: #10256-sh.ar file problem?
Fm: Ken Drexler 75126,3427
To: Mike Ward 76703,2013 (X)
Mike,
Thanks for the message.  That explains why it looks bad half way through. I
will take another look.  (I also hoped for source code.)
Ken

#: 10279 S12/OS9/68000 (OSK)
    15-Apr-91  02:51:22
Sb: #10251-#sh.ar file problem?
Fm: Paul K. Ward 73477,2004
To: Ken Drexler 75126,3427 (X)
SH.ar I think is for OSK only although it's been a while since I downloaded it
and I may have forgotten the 6809 version if there was one -- or were you
interested in just the source code (which I believe does not exist in the US)?
Incidentally, after a few weeks with the Bourne shell on my MM/1, I'm sold. The
only weirdnesses are the redirection convnetion and the fact that it doesn't
automatically fork RunB. I get around the first by setting up aliases for all
the basic programs I use, a la
        alias drive runb drive
        alias color runb color
.
 and put that in my $home directory's .profile. On the redirection thing, I
either bite the bullet and do it the way Bourne intended, or I just call the
OS-9 shell, do the deed, and ESC back to Bourne. Neither is a big hassle.
Paul IMS
There is 1 Reply.

#: 10367 S12/OS9/68000 (OSK)
    20-Apr-91  12:53:44
Sb: #10279-#sh.ar file problem?
Fm: Ken Drexler 75126,3427
To: Paul K. Ward 73477,2004 (X)
Paul,
Thanks for your message. I downloaded sh.ar (the one which is not a bourne
shell) to look at the source code out of couriosity.  I also grabbed the bourne
shell sh.ar.  With your encouragement, I will try it on my OSK machine.
Ken
There is 1 Reply.

#: 10377 S12/OS9/68000 (OSK)
    21-Apr-91  11:27:35
Sb: #10367-sh.ar file problem?
Fm: Paul K. Ward 73477,2004
To: Ken Drexler 75126,3427
Ken,
You may want to make sure that you don't type
                del  .*
under the Bourne shell. The os9 shell will properly delete all file names that
begin with "." EXCEPT for the current and parent directory entries. I heard a
report recently that another shell for OS9, maybe the Bourne, will delete even
those entries, and then walk backwards through the directory tree to delete
everything above.
Paul IMS

#: 10295 S12/OS9/68000 (OSK)
    16-Apr-91  00:39:50
Sb: #MW BASIC & C
Fm: Bob Taylor 73270,3124
To: all
I need to use compiled C functions in a MW BASIC program consisting of a
lot of procedures. Can this be done? If so how?
Thanks in advance.
Bob
There is 1 Reply.

#: 10318 S12/OS9/68000 (OSK)
    17-Apr-91  05:24:46
Sb: #10295-#MW BASIC & C
Fm: Kevin Darling 76703,4227
To: Bob Taylor 73270,3124 (X)
Bob - Basic can call assembly language subroutines, so should be possible to
cobble up a C function, yes.  I coulda sworn I saw a 68K doc on this, but maybe
I'm just thinking of the 6809 docs.
The parameter passing from basic is shown in the basic manual... the C
functions would just have to be wrapped up in a subroutine module. I know a
bunch of us keep meaning to try this out <g>.  Wanna be the first?
There is 1 Reply.

#: 10337 S12/OS9/68000 (OSK)
    18-Apr-91  02:42:15
Sb: #10318-MW BASIC & C
Fm: Bob Taylor 73270,3124
To: Kevin Darling 76703,4227 (X)
Kevin,
  Not really :-). However, since it would be much faster to add a user
interface to a program I did not write, than to rewrite it in C--I'm
elected.  Will kludge something VSN.
Bob

#: 10331 S12/OS9/68000 (OSK)
    17-Apr-91  22:48:24
Sb: #Amiga 68K
Fm: Steven Reider 72356,3607
To: all
?exit I am looking for any information relating to OS-9 for the Commodore
Amiga, or for anyone who might know where to find more info. I hear someone in
Australia might be distributing OS-9/68K for the Amiga. If you know anything
about this, please leave a message.
There is 1 Reply.

#: 10334 S12/OS9/68000 (OSK)
    18-Apr-91  00:27:32
Sb: #10331-#Amiga 68K
Fm: Kevin Darling 76703,4227
To: Steven Reider 72356,3607 (X)
Steven  - it was Digby Tarvin from Australia who did the port a coupla years
back.  I believe he's here in the US for a while again;  will check on it
unless someone reading this can answer.  I know there's a desire to get it sold
here (I'd like it, for one!).
There is 1 Reply.

#: 10435 S12/OS9/68000 (OSK)
    24-Apr-91  12:36:53
Sb: #10334-Amiga 68K
Fm: Steven Reider 72356,3607
To: Kevin Darling 76703,4227
Thanks for the help.  I'm very interested in this port of OS-9.
                            Steve

#: 10422 S12/OS9/68000 (OSK)
    23-Apr-91  22:43:30
Sb: #VED Extensions
Fm: Bob van der Poel 76510,2203
To: all
I'm considering adding some more muscle my VED text editor by permiting it to
access extension modules. The plan is to have a command os9exec() to a user
supplied program which could do "whatever". VED would pass a number of params
to the user program, including the start and end of the text buffer and
pointers to a number of internal routines (the menu routines, etc.). The user
program could then access the text in memory and use the same interface to make
a very transparent extension. I suppose a possible extension could be a
spelling checker...but that's not important.
Questions:
1. Under systems with MMUs is the memory of the parent process available
   to the child?
2. Just what kind of params should be passed to the child? The params would
   be accessed via argc, argv[] routines since I plan to have extension
   just be a standard C program; no complicated subroutines, etc.
So, any suggestions or comments?
 o
There is 1 Reply.

#: 10428 S12/OS9/68000 (OSK)
    24-Apr-91  11:09:06
Sb: #10422-VED Extensions
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203
Just remember that if you're planning to use argc/argv that all of your
parameters probably should be ascii-fied, and that the arglist still needs to
be terminated with a CR (or the parsing routines will go to Mars).
Pete

#: 10464 S12/OS9/68000 (OSK)
    25-Apr-91  21:04:59
Sb: #10177-termcap and windows
Fm: Greg Law 72130,23
To: Bob van der Poel 76510,2203 (X)
I don't know what the answer is to that question, Bob. I've been looking for
similar techniques of creating window overalys on virtually any terminal and
have been experimenting with Curses. I've tried using NCurses from the TOPS
disks, but it appears to be imcomplete as far the Unix standard Curses. Ed at
Delmar sent me another version of Curses last week but I haven't had time to
monkey around with it yet. As a matter of fact, I hadn't even tarred and
feathered it yet... I guess that should be untarred and defeathered (tar and
compress).
If you find the information on Termcap windows, I'd really like to hear about
it. I'm working on an OSk application now that really needs decent window
overlaying capabilities -- whether it be Termcap or Termcap plus Curses. I have
the front-end working quite well on a PC using PCCurses and hoping to find
and/or fix a decent version of Curses for OSk to really dig into development.
        -- Greg

#: 10471 S12/OS9/68000 (OSK)
    26-Apr-91  02:27:06
Sb: #10177-termcap and windows
Fm: Bob Taylor 73270,3124
To: Bob van der Poel 76510,2203 (X)
Greg,
 For your information, I uploaded a port of Pavel Curtis' Curses into
DL12 some time ago.  This is terminfo based (included ) and as nearly as
I can tell compatible with SYS V.  Should be _much_ better than old
Curses. 
Bob

#: 10484 S12/OS9/68000 (OSK)
    28-Apr-91  00:29:42
Sb: #10377-sh.ar file problem?
Fm: Ken Drexler 75126,3427
To: Paul K. Ward 73477,2004
Paul,
Thanks for the warning.  I am sufficiently intimidated and courious that I will
get some sort of guide before I run with the bourne shell.
Ken

#: 10503 S12/OS9/68000 (OSK)
    28-Apr-91  22:34:54
Sb: #creat() help
Fm: Bob van der Poel 76510,2203
To: all
Is it possible to set the file attributes when using creat()?
If I do something like creat(filename,S_IREAD+S_IOREAD) I get a "illegal mode"
error. I've tried various combinations, but the only ones which seem to take
are S_IREAD, S_IWRITE and S_ISHARE. Trying to set any public bits causes
errors. I'm beginning to think that creat() will always set the file
permissions to S_IREAD+S_IWRITE and uses the 'mode' param as the access mode
when opening the file. But this is not what the docs imply. I know I can use
create() to do what I want, but this has really got me bugged. I see that there
is a mask defined in the modes.h file, but I really don't understand what to do
with it. This is probably really simple and I'll feel stupid (again) once
someone points out the answer....
Oh, I tried this under Level II and it seems that the file is always created
for public read and owner read/write, no matter what the value of 'mode'. No
errors, but mode doesn't seem to have much effect either.
There are 2 Replies.

#: 10512 S12/OS9/68000 (OSK)
    29-Apr-91  11:36:01
Sb: #10503-#creat() help
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Bob -
I believe there are two variations of 'creat()' in the Kreider C library. One
of them allows for initial file mode bit setting.
Pete
There is 1 Reply.

#: 10522 S12/OS9/68000 (OSK)
    29-Apr-91  22:04:34
Sb: #10512-#creat() help
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Pete, I'm using the creat() which comes with osk. Also, I belive you're
thinking of the creat() and create() which come with Carl's library. The same
applies to osk.
There is 1 Reply.

#: 10524 S12/OS9/68000 (OSK)
    30-Apr-91  00:01:20
Sb: #10522-creat() help
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
In that case, I guess you'll have to get hold of Carl's 68K library (if he's
making it available). Yup - thems was the functions I was thinking of.
Pete

#: 10528 S12/OS9/68000 (OSK)
    30-Apr-91  12:46:38
Sb: #10503-creat() help
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
Bob,
 The documentation in the Microware manual is misleading: under creat(), it
says "The permissions are ..." when it means "The access permissions ...". The
function you want to use is create():
 create(name,mode,perm[,initial_size])
 where mode is the access permissions as in creat(), perm is the file's
attributes - what you are wanting to set.
 You can probably guess how I knew the answer to this one so fast!
 Mark

#: 10665 S12/OS9/68000 (OSK)
    13-May-91  08:50:11
Sb: #10566-#creat() help
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
The "theoretically correct" technique for seeing if a file already exists is
with the access() function. Using perms of 0 just tells you if it is there, or
you can see if it is access()able <g> with whatever permissions you want.
 Mark
There is 1 Reply.

#: 10669 S12/OS9/68000 (OSK)
    13-May-91  22:04:21
Sb: #10665-creat() help
Fm: Bob van der Poel 76510,2203
To: Mark Wuest 74030,332 (X)
Yes, access() is the correct way to see if a file exists. In the segment I was
working with I really didn't care if the file did or did not exist. I was going
to overwrite it no matter what. Creat() is nice for this since it will
overwrite an existing file. Create() will not. But with creat() you can't set
the file permissions (as we both now know!!), and I did want some special perms
set . . . so that meant I had to use create(); but it fails if the file
exists... so then it is back to combinatation of create() and open(). No big
deal, but it seemed that creat() would have been so simple. Besides, now
everyone knows of yet another ambiguity in the MW manuals.

#: 10712 S12/OS9/68000 (OSK)
    17-May-91  07:38:39
Sb: #command line arguments
Fm: Chris Clark 76050,1127
To: SYSOP (X)
I am a new OS9 user. I am used to using unix and the cshell. Iwould like to
pass command line arguments into a script. ( I cannot force myself to type chd
instead of cd. ,,,etc... ). HELP!!!! Chris Clark 404-542-4452 or
clark@mond1.ccrc.uga.edu on the Internet
There are 2 Replies.

#: 10716 S12/OS9/68000 (OSK)
    17-May-91  18:15:41
Sb: #10712-command line arguments
Fm: Pete Lyall 76703,4230
To: Chris Clark 76050,1127
Chris -
There are a couple of options:
 a) Use 'shell+'. This is a hacked version of the standard shell that
    supports shell variables, parameters, and control statements. Should
    be in DL10. May require LII (Os9 Level II).
 b) The os9 UGLIB (DL5) has a tool called 'go' that accepts parameters,
    and forks command lines with these parameters substituted. If it's not
    online, it can be recalled.
Pete

#: 10726 S12/OS9/68000 (OSK)
    17-May-91  22:23:21
Sb: #10712-command line arguments
Fm: Kevin Darling 76703,4227
To: Chris Clark 76050,1127
Hi Chris - I assume from the section that you're using OS9/68K.
The current Microware shell doesn't accept command line arguments <sigh>. I
suspect with the coming influx of OS9/68K users, that we'll be seeing a new
shell that does pretty pronto, tho.
In the meantime, drop into Library 12 and do a "bro /key:shell" and see if you
find anything useful.  I believe that there's a Bourne shell in there, for one.
Like you, I find "chd" instead of "cd" is driving me crazy... especially since
the "pwd" of 6809 OS-9 is now "pd" under OS9/68K (OSK for short).
luck! - kev

#: 10783 S12/OS9/68000 (OSK)
    20-May-91  23:10:13
Sb: #MicroWare info...
Fm: William Verthein 76557,3623
To: ALL
Well,
I've left three messages in Microware's forum including my work address and
phone number over the last three months asking (almost begging) for info on a
386 version of OSK.  Does anyone have a phone number for these guys?  Are they
still in business?  I'm not used to begging to buy someone's product but I'm
very interested in OSK and my company has a new product pow wow in September
that I'd like to prepare for by playing with it.
Any help would be appreciated.  The Microware forum seems to be a dead end...
thanx,
wgv
There is 1 Reply.

#: 10784 S12/OS9/68000 (OSK)
    21-May-91  00:09:29
Sb: #10783-#MicroWare info...
Fm: Kevin Darling 76703,4227
To: William Verthein 76557,3623 (X)
The MW forum isn't really a forum... more of a "display area".  Which means
they may not check the messages these days (I think they will after seeing your
message :-).
Their phone number is 515-224-1929, ask for the OS-9000 info and catalog.
best - kevin
There is 1 Reply.

#: 10808 S12/OS9/68000 (OSK)
    22-May-91  20:07:16
Sb: #10784-MicroWare info...
Fm: William Verthein 76557,3623
To: Kevin Darling 76703,4227 (X)
Thanx a lot kevin!!!  I have been beating my head against that brick wall for
some time now.  Much appreciated...

#: 10827 S12/OS9/68000 (OSK)
    24-May-91  21:18:50
Sb: ved/68k
Fm: Bob van der Poel 76510,2203
To: All
For those of you who have ordered VED/68K, keep looking in your mailboxes since
the first shipments went out earlier this week.
And for those of you who don't know what we're talking about, have a look at
the new product announcement in the Hot Topics Library. The file VED68K.TXT
gives all the details on this new editor.

#: 10878 S12/OS9/68000 (OSK)
    30-May-91  13:02:22
Sb: #10334-#Amiga 68K
Fm: John P. Huston 70000,1033
To: Kevin Darling 76703,4227 (X)
Kevin,
I, too, would love to get a copy of OS9 for the Amiga. I started
using OS9 with the CoCo, and have missed it since being moving to
the Amiga. Is there a GUI for the Amiga version as well (as there
is for the CoCo version)? Also, I think the last time I asked about
an Amiga version there still was no graphics or sound library. Has
that changed??
Ok...ok...lots of questions <grin>!
John
There is 1 Reply.

#: 10879 S12/OS9/68000 (OSK)
    30-May-91  14:06:53
Sb: #10878-Amiga 68K
Fm: Kevin Darling 76703,4227
To: John P. Huston 70000,1033 (X)
John - we're working on a GUI for the 68K machines (and of course, there's also
RAVE from MW which could be ported, and G-Windows, and MGR, and X, etc), but
the main thing stopping us on the Amiga is that we don't have the Amiga OS9
port in hand here in the US.  People are working on this tho.
You're not alone, btw... I get a lot of email here on CIS and on the Internet
from Amiga owners who'd like to be using OS-9 again.  Many of the better Amiga
OS commercial programmers came from the coco/os9 world, also.
cheers - kev

#: 10913 S12/OS9/68000 (OSK)
    02-Jun-91  23:20:26
Sb: #new OSKer
Fm: Clyde C. Price, Jr. 76616,3452
To: all
Kevin
        I just recently purchased from Peripheral Technology a PT68K4 computer
with an 80Meg harddisk and VGA monitor.  I'm very interested in being a beta
tester for the software being ported over into the OSK environment, and
particularly interested in seeing which programs originally ported for the MM1
can be immediately used in the PT machine.
        I'm also hoping to get OSK versions of RiBBS and OSterm as soon as
they're available.
        The PT machine is my FIRST OS9 machine, so I'll also have all those
"beginner"-type questions, and need all the friendly general advice that I can
get.
        I'm glad that you and the other folks are here on CIS!
--Clyde
There are 3 Replies.

#: 10915 S12/OS9/68000 (OSK)
    03-Jun-91  00:09:24
Sb: #10913-new OSKer
Fm: Kevin Darling 76703,4227
To: Clyde C. Price, Jr. 76616,3452 (X)
Thanks Clyde... there are/will be a lot of OS9/68K novices around here soon; so
you won't be alone, I assure you! <grin>
I'm still learning things myself, so I may be asking you for help later on.
cheers - kevin

#: 10926 S12/OS9/68000 (OSK)
    03-Jun-91  19:04:19
Sb: #10913-#new OSKer
Fm: Mike Haaland 72300,1433
To: Clyde C. Price, Jr. 76616,3452 (X)
Clyde,
Welcome aboard!  I'm sure you'll love OSK.  No problem on all the future
questions...  That's what the forum is all about.   You'll find most Q's get
answered with in a day or so.
What kind of software you looking for?
Mike
There is 1 Reply.

#: 10961 S12/OS9/68000 (OSK)
    05-Jun-91  08:33:21
Sb: #10926-new OSKer
Fm: Clyde C. Price, Jr. 76616,3452
To: Mike Haaland 72300,1433 (X)
Mike,
        I'm looking primarily for communications, wordprocessing, and BBS
software IMMEDIATELY.  Other stuff as available.  I'm beginning to look for
sources of sourcecode from other machines, especially CP/M, since that bunch of
programs worked well in 64K windows and was terse and highly functional
programming.
        Thanks for the encouragement! --Clyde

#: 10951 S12/OS9/68000 (OSK)
    04-Jun-91  22:22:50
Sb: #10913-new OSKer
Fm: SCOTT HOWELL 70270,641
To: Clyde C. Price, Jr. 76616,3452 (X)
Welcome aboard Clyde!!
        I too own a PT68K (40meg) computer. Great things are a happenin' in the
68k osk market (comparitively (sp?) speaking)!
        Great system tho,
Again, Welcome aboard!!

#: 11071 S12/OS9/68000 (OSK)
    14-Jun-91  15:38:26
Sb: #OSK 68000 Archives
Fm: CHUCK LOUGHRY 70615,213
To: ALL
I have noticed several files in the libraries that have an extension of .AR and
so far, have been completely unsuccessful in extracting any of these archive
files.  I have an FHL QT 20X 68020 computer.  I would like to know the location
of the appropriate program to extract these archives.
Thank you in advance for your responses.
                                Chuck Loughry ( 70615,213 )
There is 1 Reply.

#: 11072 S12/OS9/68000 (OSK)
    14-Jun-91  17:14:24
Sb: #11071-OSK 68000 Archives
Fm: Pete Lyall 76703,4230
To: CHUCK LOUGHRY 70615,213
Chuck -
Grab AR68.BIN and AR.DOC in DL9. Rename the AR68.bin to AR, stuff it in the
execution directory, set the execute permission(s), and away you go.
Pete
Press <CR> !>

#: 11147 S12/OS9/68000 (OSK)
    21-Jun-91  14:47:54
Sb: OSK 68000 Archives
Fm: CHUCK LOUGHRY 70615,213
To: Pete Lyall 76703,4230 (X)
P}iete - Thanks for the help on the 68000 OSK problem. I have been trying to
figure out how to get some of the great software out here but didn't know which
archiver to use. Again, Thanks Pete.
    CHUCK [ 70615,213 ]

#: 11172 S12/OS9/68000 (OSK)
    24-Jun-91  00:04:33
Sb: #11101-#zmodem for osk
Fm: BILL HEALTON 73367,357
To: Clyde C. Price, Jr. 76616,3452 (X)
Clyde - My name is Bill Healton, I have an Atari 520STfm. I have been running
OSK version 2.2 since mid-1988. I tried rz/sz but came up with the ever
prominent(on ST/OSK) Error #000:102; a bus error. This is apparently due to
the fact that unlike most of the other OSK systems, the ST leaves the low RAM
area available to Atari TOS calls (I/O mostly). The ST also has a hardware
generated bus error when this area is accessed in non-system mode. This
typically keeps most of the good programs from running. I would like to see
more programs work. I believe this can be accomplished by installing a bus
error handler routine if I can establish what is generating the errors.
The following is what running sz &rz with a "-?" option generates:
sz -?
Send file(s) with Zmodem/Ymodem/Xmodem Protocol
    (Y) = Option applies to YMODEM only
    (Z) = Option applies to ZMODEM only
Error 000:102
rz -?
rz 1.08 09-15-86 for Error 000:102
If you can determine what code could be generating the Error 000:102 this
would be a big help in trying to resolve this problem. I suspect any
non-variable/non-OS9 call, especially a D_xxxx direct access.
Thanks for your help...Bill Healton 73367,357
There is 1 Reply.

#: 11177 S12/OS9/68000 (OSK)
    24-Jun-91  11:32:05
Sb: #11172-zmodem for osk
Fm: Clyde C. Price, Jr. 76616,3452
To: BILL HEALTON 73367,357 (X)
Bill,
        Your question got above my head quickly.  I'll pass it along to the
C-slingers that I'm working with in the Atlanta Computer Society.  We're trying
to find as high a degree as possible of compatibility between the different OSK
machines, but we're hindered until our better programmers get their MM1 kits
delivered. --Clyde

#: 11185 S12/OS9/68000 (OSK)
    24-Jun-91  20:58:53
Sb: #Allocation help
Fm: Bob van der Poel 76510,2203
To: all
I'm wondering if anyone has a suggestion for me. I'm using a singly linked list
to store strings of an unknown length. We I started I set up the following
structure:
 struct data{
   struct data *next;
   char *text;
 }
Then I'd malloc() memory for the structure and for the text storage. Of course,
the two memory requests are not necessary, so I'm now getting enough memory for
the 'next' pointer plus the text. The question is: is there an elegant way to
ensure portablility and make this a bit more readable later. For some reason,
the following leaves a great deal to be desired:
 woof=malloc(sizeof(struct foo)+strlen(buffer));
   ...check for valid p & setup links
 strcpy(woof+1,buffer);
I tried setting up a dummy pointer in the structure, but that doesn't seem to
work. The other solution is to have 'text' in the structure defined as 'char
text[1]' and then do the malloc() for sizeof(struct data)-1+strlen(buffer). One
of the problems with this is that we have to assume the order of the data in
the structure, and I don't believe that element 1 in a structure HAS to follow
element 2 (even though it does in most implementations). Guess the safest is to
do 2 malloc()s.
Any ideas?
There is 1 Reply.

#: 11186 S12/OS9/68000 (OSK)
    24-Jun-91  22:07:42
Sb: #11185-#Allocation help
Fm: James Jones 76257,562
To: Bob van der Poel 76510,2203 (X)
The canonical C sleaze method is the trailing one-element array method.  C
*does* guarantee that the order of declaration corresponds to the order of
fields in memory for structures, aside from some fine print concerning bit
fields (the vagaries of byte ordering and the like don't let one say quite as
much about them as about plain old members of structures).  Strictly speaking,
the method doesn't *have* to work (an interpreted C, or some system with bounds
checking, --er, attempts--to go past the end of the array as declared), but in
practice it will work.
There is 1 Reply.

#: 11187 S12/OS9/68000 (OSK)
    24-Jun-91  22:21:02
Sb: #11186-#Allocation help
Fm: Pete Lyall 76703,4230
To: James Jones 76257,562 (X)
Not just that JJ/Bob, but aren't several compilers setup so that structures
start on word or longword boundaries? That could screw this up, and two mallocs
may be the best way to do it. Don't forget, malloc() may not have to call the
system twice if it preallocated a large enough block to begin with.
Pete
There is 1 Reply.

#: 11202 S12/OS9/68000 (OSK)
    26-Jun-91  21:15:33
Sb: #11187-#Allocation help
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Pete/JJ, I think that the 'nicest' way to do the allocation *is* with two
malloc()s. But, even if malloc() doesn't need to call the system at all for
memory it still exacts a fairly heavy price in overhead. Each malloc() has to
keep track of the memory point and the size (I believe it uses a linked list
for this). Something like 8 bytes per call? The other un-nice thing about two
malloc()s is that two free()s are needed to get rid of the stored stuff--again,
not a big deal, but one more thing to go wrong!
BTW, I "discovered" an interesting thing about the the 68K compilier--it does
structure assignments and will pass structures by value (pushes the whole thing
onto the stack!). Don't ask just how I found this out <grin>.
There is 1 Reply.

#: 11205 S12/OS9/68000 (OSK)
    26-Jun-91  21:28:59
Sb: #11202-Allocation help
Fm: James Jones 76257,562
To: Bob van der Poel 76510,2203 (X)
Since you <grin>ned, I bet it was by passing a structure (sounds painful, eh?
:-) when you meant to pass its address.  If that's it, don't feel bad; I've
done it too.

#: 11189 S12/OS9/68000 (OSK)
    24-Jun-91  22:49:57
Sb: #OSK Unzip?
Fm: Kevin Darling 76703,4227
To: all
Hey... does anyone have an IBM unzip for OSK?   I've been running into files
which are just way too large to unzip using the 6809 version (because of
limited disk space on my CoCo).
Much thanks - kev
There is 1 Reply.

#: 11203 S12/OS9/68000 (OSK)
    26-Jun-91  21:16:08
Sb: #11189-#OSK Unzip?
Fm: Randy Donahoo 72520,3607
To: Kevin Darling 76703,4227 (X)
kevin,
There is a UN*X unzip written in C with source code available.  I have not
tried to port it to OS9/68000.
randy donahoo
There is 1 Reply.

#: 11208 S12/OS9/68000 (OSK)
    27-Jun-91  00:43:19
Sb: #11203-OSK Unzip?
Fm: Kevin Darling 76703,4227
To: Randy Donahoo 72520,3607
Thanks, Randy..  I guess I should start learning C again :-)

#: 11195 S12/OS9/68000 (OSK)
    25-Jun-91  20:09:21
Sb: #11108-More MM/1 Questions :)
Fm: Paul K. Ward 73477,2004
To: Keith H. March 70541,1413 (X)
Thanks for the questions! I'll give you a call and upload the answers here.
Best,
Paul IMS

#: 11201 S12/OS9/68000 (OSK)
    26-Jun-91  21:13:21
Sb: #11075-Want Graphics
Fm: Randy Donahoo 72520,3607
To: Robert Heller 71450,3432 (X)
Robert,
Vigra has a board for the VMEbus actually two boards of which one might meet
your needs.  The MMI-100B with 1024x1020 pixels and 256 colors uses a video
memory controller with palette.  This board also has a Motorola 56001 DSP for
audio capabilities.  The multi-media interface card.  It also has 2 AT type (9
pin DIN) serial ports and a PC keyboard.  Microphone input for recording
sounds.  They have a MMI-150 same as above without audio support. oops three
boards and a MMI-250 with VME and VSB interface.  Programmable resolution to
1280x1024 with 1,2,4, or 8 bits per pixel.  2 Mbyte of multi-ported video RAM
and 2 rs-232c ports, AT keyboard port and programmable sound generator.
MMI-250-2 2 meg MMI-250-4 4 Meg memory.  MMI-100B 1Mbyte memory
Vigra, Inc 4901 Morena Blvd. Bldg. 502 San Diego, CA 92117 (619) 483-1197
I have a MMI-100B that we use at work here in Stillwater, OK...I do not work
for Vigra.....
Randy Donahoo

#: 11226 S12/OS9/68000 (OSK)
    28-Jun-91  15:41:43
Sb: #11079-Me and my MM/1! :)
Fm: Paul K. Ward 73477,2004
To: Keith H. March 70541,1413 (X)
Keith, and others curious about the I/O board -update, Western Digital is shipping a defective host adapter mask. We have
found nondefective chips and are checking them out. I/O boards were received
this week at IMS. Give us some time to make sure all is well with these new
chips.
Incidentally, preliminary tests with our new hard disk drivers put throughput
at up to 1.8 Mbytes per second. That's screaming fast.
Paul IMS

#: 11229 S12/OS9/68000 (OSK)
    28-Jun-91  15:47:03
Sb: #11104-Questions about the MM/1
Fm: Paul K. Ward 73477,2004
To: Ed Gresick 76576,3312 (X)
Ed,
Thanks for the informative response to Keith's question.
Best regards,
Pau
IMS

#: 11230 S12/OS9/68000 (OSK)
    28-Jun-91  15:47:37
Sb: #11097-dEd 68000
Fm: Paul K. Ward 73477,2004
To: Pete Lyall 76703,4230 (X)
Pete,
There is a ded for OSK. Keith is getting it.
Paul
IMS

#: 11232 S12/OS9/68000 (OSK)
    28-Jun-91  15:58:15
Sb: #11113-Help with the MM/1
Fm: Paul K. Ward 73477,2004
To: Keith H. March 70541,1413 (X)
Keith,
Nothing was buggy at all, Keith! We left off one file and we are updating two
files. Also, we are now including some public domain fonts!
Did you have the impression that something was buggy on the disks? If so,
how did you get htat impression? Thanks!
Mark's CServe ID is 76247,1332.
He gets on about once every two weeks.
Paul
IMS
202 232 4246

#: 11250 S12/OS9/68000 (OSK)
    29-Jun-91  08:41:21
Sb: #11113-Help with the MM/1
Fm: Mark B. Sheffield 76247,1332
To: Keith H. March 70541,1413 (X)
Keith -
Your kit installation instructions should be there by now.
Some files were missing from the original MM/1 distribution disk set. The new
set now has those files.
-mark

#: 11305 S12/OS9/68000 (OSK)
    06-Jul-91  18:54:42
Sb: #Tape drive(r) problems
Fm: Robert Heller 71450,3432
To: anyone
I recently upgraded to OS-9/68K V2.4 on my Force CPU-30 and now have
some time to fuss with the tape drive (after backing up 25Meg to 40
floppies).  With this version of the SCSI drivers, my "oddball"
(Archive Scorpion (5945C) + Adaptec ACB3530 SCSI <=> QIC-36
controller), seems to work.  Sort of.  Using the Viper driver (meant
for Archive's QIC-150 SCSI drive) it reads QIC-24 tapes fine.  What it
writes is another matter.  I did a fsave and then tried a frestore -v
and got a message that the ident block was bad.  I then tried using a
PD tar program, but when I tried to read it, got a tar header checksum
error and my home-grown tar clone on my other machine (Stride 440 -
same type of drive, with Archives QIC-02 <=> QIC-36 controller board)
also had trouble reading the tape (various errors).
What I'd like to know:  do I need to write a completly new driver for
this combination or is there some minor thing I need to change with
one of the existing drivers to make this work?  Or is there something
wrong with the drive or controller board?  No driver errors are
reported in any case.
I would like to be able to use the tape for backups - using floppies
is a pain...
             Robert
There is 1 Reply.

#: 11314 S12/OS9/68000 (OSK)
    08-Jul-91  09:11:39
Sb: #11305-Tape drive(r) problems
Fm: Mark Wuest 74030,332
To: Robert Heller 71450,3432 (X)
Robert,
 Since you just bought your upgrade, you should have some free tech support
coming from Microware (I believe 90 days). I know they support the Viper
drives, but do not know about others. You may have to write your own driver.
The driver for the Viper is sbviper. Good luck.
 Mark

#: 11310 S12/OS9/68000 (OSK)
    07-Jul-91  08:32:23
Sb: #STERM & OSK
Fm: DENIS CHARTRAND 72561,2714
To: All
      Maybe it was already discussed, but again, to what must be set the MODEM
port for  the last STERM upload for the OS9/68000?
  Thanks
There is 1 Reply.

#: 11311 S12/OS9/68000 (OSK)
    07-Jul-91  18:29:55
Sb: #11310-#STERM & OSK
Fm: Steve Wegert 76703,4255
To: DENIS CHARTRAND 72561,2714 (X)
Denis,
I may have mis-understood your question, but proper syntax for the newest
version of Sterm is:
Sterm -f -l /t2
where the -f option is the 'non-floppy' mode to allow B+ protocol, and the -l
option is used to indicate which serial port to use.
Sterm -?  will net a nice list of new options supported.
Steve
There is 1 Reply.

#: 11371 S12/OS9/68000 (OSK)
    14-Jul-91  08:04:45
Sb: #11311-#STERM & OSK
Fm: DENIS CHARTRAND 72561,2714
To: Steve Wegert 76703,4255 (X)
    OK, now it works with "sterm -l /t1" command line.
    Before, when I used to type only "sterm /t1", the program exit almost rigth
away and said: No MODEM port defined!
   I'm using Atari ST with OSK v2.3
   Thanks.
There are 2 Replies.

#: 11381 S12/OS9/68000 (OSK)
    15-Jul-91  07:30:10
Sb: #11371-STERM & OSK
Fm: Steve Wegert 76703,4255
To: DENIS CHARTRAND 72561,2714 (X)
Glad things are working for you. The -l option threw me for a loop as well.
Steve

#: 11399 S12/OS9/68000 (OSK)
    17-Jul-91  06:09:57
Sb: #11371-STERM & OSK
Fm: Mark Griffith 76070,41
To: DENIS CHARTRAND 72561,2714 (X)
Hi,
If you read the docs, you'll notice you can define a modem port as an
environment variable and then you don't have to use the -l option to start
Sterm.  This applies for OSK only.  Put this in your startup file:
    setenv MODEM /t2 (or whatever port you want)
Mark

#: 11363 S12/OS9/68000 (OSK)
    13-Jul-91  13:31:13
Sb: #UUCP Source and a MM/1
Fm: Keith H. March 70541,1413
To: All
Hi, I hope someone can help me.
I have the Rick Addams UUCP Ver 2.0 source code.
I would like to recompile it on my MM/1
Do I have to edit the makefile?
Please help me get this set up on my new computer.
any help will be greatly appreacted <sp?>
Thanks keith
There are 2 Replies.

#: 11364 S12/OS9/68000 (OSK)
    13-Jul-91  13:55:05
Sb: #11363-UUCP Source and a MM/1
Fm: James Jones 76257,562
To: Keith H. March 70541,1413 (X)
That depends on the particular make that the makefile is written to work with.
There was long ago a sort of primitive make, makefiles for which can, if I
recall correctly, be recognized by the = that appear at the beginning of some
of the lines.
There is a freely-copyable make that is more like Unix make than Microware's
make, and there's a make (I think freely copyable also) that was written to
work like Microware's make.
What it boils down to is, we'll need to see a sample of it before we could say.
Could you post the first few lines?

#: 11365 S12/OS9/68000 (OSK)
    13-Jul-91  18:39:18
Sb: #11363-UUCP Source and a MM/1
Fm: Mike Haaland 72300,1433
To: Keith H. March 70541,1413 (X)
reply 11363
Kieth,
I've played with Rick's UUCP package, and it's nice!  BUT, you need to make
quite a few changes to the source code to get it to compile under OSK. He used
the _os9() 6809 routine for Get/Setstat calls which need to be changed to the
equivalent _gs_xxx or _ss_xxx functions in OSK.
What I did is used the preprocessor directive
 #ifdef OSK
 _gs_xxx
 #else
 ...
 ...
 _os9()
 #endif
Other than that, you need to use -DOSK when compiling the thing. So, if you
haven't done it before (Ported a program from the COCO) it will be a challenge,
but very doable.
I have sent E-Mail to Rick, asking for permission to port/post a new version
that will support both OSK and 6809 OS9.  SO you may want to hang on for a
while till I get a reply.  If he says "go for it", I'll post the sources here.
Mike

#: 11369 S12/OS9/68000 (OSK)
    14-Jul-91  07:31:10
Sb: #Reply to #11364
Fm: Keith H. March 70541,1413
To:  76257,562 (X)
  This here is the makefile from the uucp package, written under level II OS9.
The makefiles for OSK looks a little different
ALSO: Does anyone have the source code (.a) for dEd, I miss it, as I used it
under level II almost dayly? * * File: makefile for the UUCP package * * First
define the global macros * * CC     = the C compiler executive program * LIB   
= library(s) to include in all links in addition to clib.l * GFXLIB = library
containing graphics commands * CC     = cc2 LIB    = -l=/dd/lib/sys.l -m=1k
GFXLIB = -l=/dd/lib/cgfx.l * *CC     = cc *LIB    = -l=/dd/lib/cgfx.l -t -m=1k
*GFXLIB = ODIR   = /dd/cmds
* * Trick used to make everything.  Type:  make all *
all: uucico readnews rmail mail postnews expire \
     rnews uuxqt uucp uuencode uudecode fixtext
     @echo
     @echo  --done-
_FIXTEXT = fixtext.r getline.r fixline.r
fixtext: $(_FIXTEXT)
    $(CC) -f=fixtext $(_FIXTEXT) $(LIB)
_UUDECODE = uudecode.r
uudecode: $(_UUDECODE)
    $(CC) -f=uudecode $(_UUDECODE) $(LIB)
There is 1 Reply.

#: 11370 S12/OS9/68000 (OSK)
    14-Jul-91  07:53:48
Sb: #11369-Reply to #11364
Fm: James Jones 76257,562
To: Keith H. March 70541,1413 (X)
Hmmm...looks like a Unix-like makefile to me.  (Microware's make thinks that
targets without suffixes have to be executables, which does sometimes get in
the way.)  You should look for one of the freely-copyable makes that take that
sort of makefile.

#: 11411 S12/OS9/68000 (OSK)
    19-Jul-91  21:09:16
Sb: #forks and pipes
Fm: Bob van der Poel 76510,2203
To: all
I'm having a weird problem with pipes and forks (sounds like a dinner...).
Here's the deal:
 1. Process1 opens a pipe,
 2. '1' starts process2 (a filter of some kind),
 3. '1' sends a bunch of data down the pipeline,
 4. '1' closes the pipe and waits for the child (process2) to end.
All this works fine if the program forks process2 directly. However, if I fork
'shell' with process2 as a param things hang up. The stuff I send down the
pipeline gets processed okay; but the child(ren) never die. I suppose I could
just forget about using the shell, but it'll take care of setting up the
command line for me which I'd have to do otherwise. Besided, it's really
bugging me.
This is all in C on OSK using os9exec() with fork().
I suspect that I have to terminate or wakeup someone with a signal. Not sure
who or what. Any suggestions?
There is 1 Reply.

#: 11412 S12/OS9/68000 (OSK)
    19-Jul-91  22:57:04
Sb: #11411-#forks and pipes
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203 (X)
Can I assume that you add a "&" on the shell line forking the child? Hmm. I
guess you must or your parent program wouldn't continue operation until the
child died.
I would think that when the parent closes the pipe, the child should die,
assuming the child dies when it detects the read error (or eof? not sure) on
the pipe.  Hmm.  Got a tiny example code which would fit up here?
 - kev
There are 2 Replies.

#: 11417 S12/OS9/68000 (OSK)
    20-Jul-91  21:09:29
Sb: #11412-forks and pipes
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)
Kevin,
Here's a bit of code. Remember, this is 'C' -- but since it just calls the
system F$Fork even die-hard assembler types like you should be able to help
<grin>:
First off, a bit of the section which starts the pipeline:
   char *argv[MAXARGS];
   FILE *out_file;
   int childnum, pipe, oldin, oldout, os9fork();
   extern char **environ;
   if((pipe=open("/pipe",S_IREAD+S_IWRITE))<0)
         terminate("Unable to open '/pipe'");;
   oldin=dup(0);   /* save current stdin/out */
   oldout=dup(1);
   close(0);        /* set stdin to new pipe file */
   dup(pipe);
   close(1);        /* set stdout to current output file */
   dup(fileno(out_file));
   argv[0]="shell";
   argv[1]=newprog;
   argv[2]=0;
   childnum=os9exec(os9fork,argv[0],argv,environ,0,0);
   close(0);       /* restore original stdin */
   dup  (oldin);
   close(oldin);
   close(1);        /* restore original stdout */
   dup  (oldout);
   close(oldout);
   if(childnum<0){      /* fork failure, close the pipe file */
      childnum=0;
      close(pipe);
      terminate("Unable to fork pipe process");
   }
   else{
      fclose(out_file);            /* close old output file */
      out_file=fdopen(pipe,"w");    /* set to pipefile */
   }
And here is the snippet which gives the problem.
   fclose(out_file);   /* close down the pipeline */
   /* wait for a pipe process to finish it's thing... */
   if(childnum){
      wait(0);
      childnum=0;
   }
Continued next message.

#: 11418 S12/OS9/68000 (OSK)
    20-Jul-91  21:10:08
Sb: #11412-#forks and pipes
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)
Continued...
I can get the code in the last section to work perfectly simply by changing the
argrument list to:
   argv[0]=newprog;
   argv[1]=0;
When this is done 'newprog' is forked directly (and runs concurrently) with its
stdin/out redirected as needed. Then when its input is closed it nicely dies.
However, as written, there is a shell in between my main process and the child.
In this case the closing of the pipeline just causes things to hang forever.
Well, not forever -- if I hit CTRL-E the shell(?) dies along with the child and
things continue on as needed. I suppose I could send a terminate signal, but am
I guaranteed that the child will have finished if I do that? The reason for
using shell as an intermediary is that I don't want to have to rewrite the
parseing code to break up arguments (under OSK the shell, not cstart breaks up
the command line into null-terminated strings) and do redirection.
Help.
There is 1 Reply.

#: 11422 S12/OS9/68000 (OSK)
    21-Jul-91  17:35:20
Sb: #11418-forks and pipes
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203
Bob -
A) Is it that the children never die, _or_ that the parent (actually
GRANDPARENT) never get a death notification? If this is the case, it's because
Shell breaks the parent/child lineage, and the child would have noone to report
to if the Shell goes away.
B) Have you tried the 'popen()' call? (if 6809)... If not, that's what you
probably want. Mirrors Unix 'popen()' exactly.. i.e.:
  int path;
  path = popen("procs", "r");    /* fork a 'procs' command; read its output */
   .....
  pclose(path);
Actually - I can't remember if popen is high level (fgets, etc.) or lower
level... I think now that it's HIGH level...
In any case, there should be a code fragment around that implements popen() in
LIB 3 if you're running 68K and haven't got it in the library.
Pete

#: 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

#: 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.

#: 11547 S12/OS9/68000 (OSK)
    30-Jul-91  22:29:12
Sb: #URGENT-need answr 2nite!
Fm: PaulSeniura 76476,464
To: all
Could someone respond ASAP to this question?  I might buy a guy's Atari system,
and I need some input VERY QUICKLY, like Tonight, Right Now, Pronto, please.
I'm being offered a $400.00 price for an Atari 1040ST, including a built-in
3.5" floppy, 1-meg RAM installed, a monochrome monitor (higher resolution for
MIDI stuff), and probably whatever game/software collection he has.  Or $500
for all that but a color monitor instead.
Microware said they could still sell Personal OS9 2.4 (the older version) for
the Atari ST for $150.00, so this system looks rather inticing.
IS THIS A GOOD PRICE FOR USED EQUIPMENT?
Do any of the KMAers offer substantially more power for same price range?
I've heard others using the CM-8 monitor on the Atari ST.  Can I do this and
save even more by not buying the monochrome tube?
I need to know TONIGHT July 30 if you can answer.  The guy is leaving sometime
tomorrow afternoon so I won't be able to log onto CIS before then (daytime
rates & all that).
- Thx, Paul Seniura.
There are 3 Replies.

#: 11550 S12/OS9/68000 (OSK)
    31-Jul-91  00:11:36
Sb: #11547-#URGENT-need answr 2nite!
Fm: Kevin Darling 76703,4227
To: PaulSeniura 76476,464 (X)
Paul - let me go check out some prices on the other nets... also you might ask
the same Q in ATARIPRO or ATARIARTS forums.
In the meantime, $400-500 is about right for a 1meg ST with monitor.  Since I'm
pretty sure you can use (or build a tiny circuit to use) the CM-8 with it, then
definitely get the monochrome monitor... it gives a sharp 640x400 screen.
Again, let me check - there may be deals including hard disks around. - kev
There is 1 Reply.

#: 11559 S12/OS9/68000 (OSK)
    31-Jul-91  23:34:38
Sb: #11550-URGENT-need answr 2nite!
Fm: PaulSeniura 76476,464
To: Kevin Darling 76703,4227 (X)
Goodness gracious ... I'm very glad I didn't go spend that money! I'll go see
about that 2.5meg ST & stuff.  Now maybe I can get into OSK pretty cheap, eh? 
-- Thx, Paul Seniura.

#: 11551 S12/OS9/68000 (OSK)
    31-Jul-91  00:16:05
Sb: #11547-URGENT-need answr 2nite!
Fm: Kevin Darling 76703,4227
To: PaulSeniura 76476,464 (X)
HEY! Read message 48197 in ATARIP forum!!  2.5meg ST with 30 meg HD, both
monitors for $550.
You might also still want to check ATARIA forum tho.  luck!

#: 11554 S12/OS9/68000 (OSK)
    31-Jul-91  08:30:04
Sb: #11547-#URGENT-need answr 2nite!
Fm: Steve Wegert 76703,4255
To: PaulSeniura 76476,464 (X)
Paul,
I'm curious about your 'daytime rates' comment ....
CIS has had the same rates day and evening for several years now. Or did you
mean the daytime rates from a network such as Tymnet/Telenet?
Steve
There is 1 Reply.

#: 11560 S12/OS9/68000 (OSK)
    31-Jul-91  23:43:42
Sb: #11554-#URGENT-need answr 2nite!
Fm: PaulSeniura 76476,464
To: Steve Wegert 76703,4255 (X)
As recently as last year when I bought another CIS subscription package, their
little booklet had a $8 difference for Telenet & Tymnet prices between the
day/night rates.
But that message was formatted for simultaneous display on CIS and Delphi. The
20/20 plan goes away during the day over yonder.
-- Thx, Paul Seniura.
There is 1 Reply.

#: 11569 S12/OS9/68000 (OSK)
    01-Aug-91  07:49:38
Sb: #11560-URGENT-need answr 2nite!
Fm: Steve Wegert 76703,4255
To: PaulSeniura 76476,464 (X)
Paul,
There still is a day/night pricing difference in the network surchage imposed
by Telenet & Tymnet. Nothing to do with CompuServe tho.
No local CompuServe node in your area? With some of the better long distance
plans now in place, (i.e. Reach Out America, etc) a LD call can be cheaper than
those surcharge.
Steve

#: 11681 S12/OS9/68000 (OSK)
    08-Aug-91  20:33:05
Sb: #Where is OSK AR?
Fm: Colin J. Smith 73777,1360
To: All
Could somebody please direct me to the 'AR' utility?  I was told it is in
library 12, but I'll be darned if I can find it.
Thanks,
  --Colin
There is 1 Reply.

#: 11683 S12/OS9/68000 (OSK)
    08-Aug-91  21:40:28
Sb: #11681-#Where is OSK AR?
Fm: John R. Wainwright 72517,676
To: Colin J. Smith 73777,1360 (X)
Just grabbed it myself a few days ago, Colin. Lib #9 AR68.bin.
JohnW
There is 1 Reply.

#: 11684 S12/OS9/68000 (OSK)
    08-Aug-91  22:20:01
Sb: #11683-#Where is OSK AR?
Fm: Colin J. Smith 73777,1360
To: John R. Wainwright 72517,676 (X)
John,
      Thank you!  I appreciate it more than you know.
BTW, kind of weird to be able to format a disk while online (with my MM1!)
Definately not used to it (but getting there quickly!)
  --Colin
There is 1 Reply.

#: 11694 S12/OS9/68000 (OSK)
    09-Aug-91  21:39:18
Sb: #11684-#Where is OSK AR?
Fm: John R. Wainwright 72517,676
To: Colin J. Smith 73777,1360 (X)
Yeah, "backup #500k" is kind of a time-saver too.  Couldn't figure out how to
do single-drive copies, but I did figure out how to make a huge ramdisk -
almost as good.  The machine wants a hard disk. (Oh, Paul ....)(GRIN).
JohnW
There are 2 Replies.

#: 11696 S12/OS9/68000 (OSK)
    09-Aug-91  22:08:13
Sb: #11694-Where is OSK AR?
Fm: Colin J. Smith 73777,1360
To: John R. Wainwright 72517,676 (X)
Heh, yeah, I could use a hard drive too, but will have to settle for 2 3.5
floppies for now.  Could also use some more RAM!  So much to buy, so little
cash (so little credit left...)!
  --Colin

#: 11701 S12/OS9/68000 (OSK)
    10-Aug-91  07:02:36
Sb: #11694-#Where is OSK AR?
Fm: Kevin Darling 76703,4227
To: John R. Wainwright 72517,676 (X)
John - I think for single-drive copying, just do "backup /d0".  Set your write
protect and give it a try.
There is 1 Reply.

#: 11712 S12/OS9/68000 (OSK)
    10-Aug-91  18:39:52
Sb: #11701-Where is OSK AR?
Fm: John R. Wainwright 72517,676
To: Kevin Darling 76703,4227 (X)
Single drive BACKUP is no problem, Kev, (Just like you said, but I give it all
the memory available).  What I couldn't find was a single drive option for the
copy command (for individual files).
JohnW

#: 11722 S12/OS9/68000 (OSK)
    11-Aug-91  18:50:41
Sb: #Cobbler for OSK
Fm: Keith H. March 70541,1413
To: All
Does someone have, or would like to write a file called COBBLER.C
I would like to use it on my MM/1 68K machine.
Also how can I send/receive CIS mail to/from the internet/uucp networks?
Is their a UUCP to Internet gateway here in the usa?
Keith
There is 1 Reply.

#: 11747 S12/OS9/68000 (OSK)
    12-Aug-91  22:30:32
Sb: #11722-Cobbler for OSK
Fm: Pete Lyall 76703,4230
To: Keith H. March 70541,1413
Keith -
You can send mail to a CIS account from the Internet by mailing to:
USERID@compuserve.com, where USERID is the desired individual. In my case,
that'd be:
   76703.4230@compuserve.com
NOTE: use a PERIOD to separate the numbers... not a comma.
I believe to SEND to the Internet, you have to preface the address with
something like:
INTERNET>{address}
Try GO EASY, and then ask for HELP.
Pete

#: 11724 S12/OS9/68000 (OSK)
    11-Aug-91  19:23:40
Sb: #Atari ST Harddisk
Fm: Andreas Greulich 100014,1033
To: ALL
Hi all, I'm new in this forum, so I don't know if I got the right section
number... My problem is the following: I got an Atari-ST with Cumana OS-9 Level
II, Version 2.1 (I heard it's not the newest one, but I don't know what newer
releases offer). Until now I used a normal 20M SH205 harddisk with a 9M OS-9
partition. Now, since a week, I got an additional drive, actually a removable
cartridge with 44M disks and prepared a cartridge for OS-9. But, as it's a
second drive on the Atari DMA, I have to run it on host adapter address 1
instead of 0, which still is used by the SH205. I tried just to add h1 to
OS9Boot, but I was never able to access the second drive under OS-9. The only
thing I could do was to put the host adapter of the second drive to 0 and turn
off the SH205, this way I was able to install OS-9 and use it, but this way I
can't access my "old" OS-9 partition. But at least to transfer files from the
old partition to the new one, I'd be very happy to be able to access both
drives at the same time - does anybody know how to reach it, or where I can get
a driver that can manage to install a drive on another host adapter address
than 0? I know that this question probably sounds a bit stupid, but maybe
somebody has just an easy answer.... who knows ;) Thanks in advance, and sorry
for my bad English (actually I'm Swiss, that's why), greetings,
            Andy
There is 1 Reply.

#: 11732 S12/OS9/68000 (OSK)
    12-Aug-91  12:03:43
Sb: #11724-Atari ST Harddisk
Fm: Kevin Darling 76703,4227
To: Andreas Greulich 100014,1033 (X)
Greetings, Andy!
I suspect that you're the only Cumana port owner here, altho several people use
the US version on the ST.
In fact, there was a very recent question about using two SCSI devices on the
US version, and apparently it doesn't handle more than one, either.
I'll ask around elsewhere for you.  But until someone (I might try) works on a
HD driver which uses the SCSI ID byte, I think people are stuck with only one
device.
best - kevin

#: 11753 S12/OS9/68000 (OSK)
    13-Aug-91  01:32:36
Sb: #11722-Cobbler for OSK
Fm: Scott t. Griepentrog 72427,335
To: Keith H. March 70541,1413 (X)
Just curious, but why would you want to cobbler from OSK? I suppose patching
files in memory would be a case, but it's not all that much bother to save them
to disk and include them in your bootlist...
StG

#: 11771 S12/OS9/68000 (OSK)
    14-Aug-91  08:08:51
Sb: #11722-Cobbler for OSK
Fm: Steve Wegert 76703,4255
To: Keith H. March 70541,1413 (X)
Keith,
Pete's got the syntax correct on mail to CIS, but just missed it on sending CIS
mail out. The interface is picky so:
>INTERNET:path
For intstance, to send me mail at my university account it would be:
>INTERNET:steve@wuarchive
The position of the bracket as well as the colon is critical.
Pete said it best: "Go EASY and type HELP INTERNET. It coveres all the bases.
Steve

#: 11788 S12/OS9/68000 (OSK)
    15-Aug-91  07:28:58
Sb: FYI-Lharc and Unzip
Fm: Mike Haaland 72300,1433
To: All
Just thought I'd let y'll know....
The LHARC and UNZIP programs I uploaded in DL 12 (OSK) work on those bothersome
SELF-EXTRACTING MS-DOS archives too!  I discovered this last night!  <Grin>
Mike

#: 11797 S12/OS9/68000 (OSK)
    15-Aug-91  22:54:39
Sb: #Disk sensing
Fm: Jim Peasley 72726,1153
To: Kevin Darling 76703,4227 (X)
Kev;
  re: your Internet discussion about disk sensing/write protect
  I wondered why the floppy select lights glowed faintly on the MM/1. Still
don't quite understand, but at least now I know it's not abnormal.
  BTW, they glow whether the dissk is write protected or not - both brands.
..Jim sk sens
There is 1 Reply.

#: 11804 S12/OS9/68000 (OSK)
    16-Aug-91  10:30:56
Sb: #11797-Disk sensing
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
Jim - I probably botched the explanation, but I think that's basically it
(about the glowing).  Some drives don't glow, btw, which puzzles me. Maybe they
have larger resistors on the LED circuit?  Got me.  I'm no expert what's going
on :-)

#: 11810 S12/OS9/68000 (OSK)
    16-Aug-91  21:49:33
Sb: #Questions
Fm: Jim Peasley 72726,1153
To: All MM/1 owners
This was typographically correct when I created it... the garbage is due to
After being offline for a week due to cutting the plug off my CM-8 and
replacing it with a DB-9, I'm baaaaaack!!
Coupla questions been burning for a while:
  1. Anybody got their I/O board yet?
     a. What kind of SCSI drive did you hook up to it?
  2. Anybody been able to select different fonts from the .BITMAP dir?
     I've tried all sorts of combinations of 'merge fontname.fnt', but
     stdfonts never seems to grow, and dump output never changes.
  3. Anybody gotten PCF working?  or have any ideas short of uploading
     30M worth of data to CIS and  tthen downloading to the MM/1?  File
     transfer with 3 computers and 2 monitors will be a cchallenge!!
     Preferred method would be PCCDOS to 5 1/4" from the CoCo and
     copy to 3.5" on the IBM, then PCF to the MM/1.
  4. Anybbody using DiamondScan or NEC monitors?  Is the improvement in
     resolution worth the cost of the new tube?
  5. Anybody gotten 'playm' to work yet?  All I get is a 237 error -
     "out of ram".
  6. Occasionally the computer will boot with a really weird colorset. mon
dTryingg   to setimmee oon a wwhhite on pale greeeen scrreenn isn't easy!
     Doing a plt restores the original colors.  Question is: what
     causes the palette controller to not reset to a known state?
  One final question that doesn't deserve a number as it's kinda rhetorical -
does ANYBODY actually LIKE uMACS or EMACS??  And here I thought VM/XEDIT was
arcane and cryptic!  Looks like Bob V. will do a land-office business as more
people get their systems. <g>
 Later....
 that doesn't deser ve a numb
There are 5 Replies.

#: 11811 S12/OS9/68000 (OSK)
    16-Aug-91  22:31:02
Sb: #11810-#Questions
Fm: James Jones 76257,562
To: Jim Peasley 72726,1153 (X)
Well...it turns out that the floppy driver I have doesn't do sector sizes other
than 256, which means that PCF will have to wait a bit.  (I think Carl Kreider
is working on that.)
I have my I/O board, and have a Quantum 105 Mbyte 3.5" hard drive hooked to it.
Works really well.
Editor preferences are sort of like politics and religion--highly subjective
and personal, and tending to generate long arguments that don't resolve
anything. :-)
There is 1 Reply.

#: 11818 S12/OS9/68000 (OSK)
    18-Aug-91  01:18:17
Sb: #11811-#Questions
Fm: Jim Peasley 72726,1153
To: James Jones 76257,562 (X)
JJ;
  Agreed -- anything to do witttth personal preferences usually generates lots
of heat, but little light!  Say, how do you feel about Bush in '92?? <g>
re: uMacs EMacs
  Have you ever used IBM's ISPF or PDF editor on a mainframe?   Verrrrry nice! 
Powerful and intuitive, but not customizable.
  Have you moved, or are you planning to move anything from the CoCo to the
MM/1?  I've got lots of source code and text files that I'd like to move over,
but haven't decided the easiest way to do it yet. Powerful and i np as a
terminal? (would need another monitor) moPCF?  (a 3 step process - don't have a
3.5" on CoCo or a 5.25 on MM/1)
  ??? ot lots of source  ? de and text fil e s that /I'd lsirke to moKve o v e
fontname;display 1b 3a' thingie works fine.  Where does the data go when you do
the merge?  I was looking for it to replace or be appended to stdfonts, but
dump always showed me the same thing.  Does it get merged to the window
descriptor??
 the 'merge font naooked.  Where _does_ 'merge' put the font data? s the data
go wh e nneed to timker while awaiting my I/O board -- where can I find out how
to diddle with the colors?  I'm looking for something a bit more than 'color'. 
I thought I'd find something in the CGFX library, but alas, the one I got isn't
even a directory, much less have anything in
 awaiting my I/O boar d  -- wh ere can I/ finds
There are 2 Replies.

#: 11821 S12/OS9/68000 (OSK)
    18-Aug-91  07:50:33
Sb: #11818-Questions
Fm: James Jones 76257,562
To: Jim Peasley 72726,1153 (X)
Moving stuff over?  Well...I'll probably wind up doing it one of two ways:
1. Kermit from the CoCo to the VME box, which does have a 3.5" floppy drive,
   and go from there to the MM/1.
2. Kermit straight from the CoCo to the MM/1; it's logistical problems
   (i.e. where do I put the silly things to get them next to each other)
   that impede this (preferable) method.
Your message is a tad garbled; in any case, Kevin Darling is the fellow who can
answer questions about fonts and the like authoritatively, so I'll keep mum
rather than parade my ignorance. :-)

#: 11827 S12/OS9/68000 (OSK)
    18-Aug-91  11:17:42
Sb: #11818-Questions
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
For now, font data is merged to a buffer, just as it was done on the coco. Time
to dig out your L-II manual... a lot of it carries over.

#: 11813 S12/OS9/68000 (OSK)
    17-Aug-91  09:42:50
Sb: #11810-Questions
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
Welcome back, Jim! :-)
1. I have two drives... a Seagate 157N and a 296N, I think.  But the Quantums
seem to be very popular.
2. The stdfonts module is simply a default.  Do like you did on the CoCo...
merge one of the fonts and use "display 1b 3a c8 xx" where xx is the buffer
number (yell if you've never done this on the coco).
3. I think PCF use is waiting on a newer floppy driver.  For transferring data,
I'd use a null modem between the computers, perhaps?  Or copy to coco disk, use
coco to xfer to pc disk for now.
4. Nah, not right now.  The CM-8 works well.  The DiamondScan is much brighter
for room presentations tho, I've found.
5. For playm, you'll need twice as much ram as the size of the sound file (for
conversion from mono to stereo data).  Oh. If you don't have the I/O board,
then you can't play those files anyway :-)
6. My fault on the boot to weird colorset, a glitch in setting things up,
somewhere.
* I finally use umacs a bit... the knowledge came in _real_ handy when I got a
guest login on a Unix system.  Otherwise I hate it :-)

#: 11814 S12/OS9/68000 (OSK)
    17-Aug-91  16:46:40
Sb: #11810-Questions
Fm: John R. Wainwright 72517,676
To: Jim Peasley 72726,1153 (X)
A quick tap on "F1" fixes those funny colors on mine. Been using a null modem
cable to grab stuff from my messydos machine. Maybe Emacs will "grow on us". 
I'm learning. Check pgs 28-29 of the "User Guide" for Font info. It works. No
I/O board here yet (but from what I see in Paul,s messages,
  it sould be here soon).  Bought a 40m Conner SCSI drive some time ago.  Hope
it works. Looks like everything for sound waits for that second board too.
JohnW

#: 11816 S12/OS9/68000 (OSK)
    17-Aug-91  22:24:52
Sb: #11810-Questions
Fm: Colin J. Smith 73777,1360
To: Jim Peasley 72726,1153 (X)
Concerning fonts:
What you do is 1) merge the font with 'merge fontname.fnt', then do a dump of
the font you merged.  2)  Look at the second set of 4 characters from the dump.
3)  type 'display 1b3a' plus that second set of four digits. This selects that
font.  Incidentally, you can merge every font in
BITMAPS and not take up any additional memory.
EMACS:
Yeah, I like it.  Just a matter of personal taste I suppose.
  --Colin

#: 11850 S12/OS9/68000 (OSK)
    20-Aug-91  08:52:43
Sb: #11810-#Questions
Fm: Mark Wuest 74030,332
To: Jim Peasley 72726,1153 (X)
Jim,
 Actually, two people (out of about 15) in my development group at work prefer
emacs (I am one of them). It got really funny when we sat together several
weeks ago in a C++ class. The computer we did our projects on did not have
emacs and neither one of us knew vi well enough to get much done. We were
always writing down all the cryptic little command sequences on slips of paper
(from others in the class).
 *Every* editor has "cryptic-little-command-sequences" that you just have to
get used to. I used vibAre I used emacs. I like emacs better. Oh, well!
 Mark
There is 1 Reply.

#: 11877 S12/OS9/68000 (OSK)
    21-Aug-91  23:15:16
Sb: #11850-#Questions
Fm: Jim Peasley 72726,1153
To: Mark Wuest 74030,332 (X)
Mark;
  Interesting compariison between your Vi users and uMacs users.  I used TSED
on the CoCo for so long that the UNI* system at the local JC wasn't too much of
a difference the last time I took a class.  The 'cryptic little commands' are
indeed indigenous to editors as a whole!
  How did you like your C++ class?  Borland's been bombarding me with special
upgrade offers for their object oriented C++ compiler and I'm getting close to
springing for the $100+ that they want.
  ...Jim
There are 2 Replies.

#: 11881 S12/OS9/68000 (OSK)
    22-Aug-91  03:23:06
Sb: #11877-Questions
Fm: Scott t. Griepentrog 72427,335
To: Jim Peasley 72726,1153
Ugh, if you're really into C the way it is now, you might want to put off
diving into C++.  They really do things differently (OOP, that is)!  A friend
of mine has been studying up on C++ trying to learn it from scratch (isn't much
up on C yet anyways), and in fact that is what the books seem to be
recommending - people who really know C really hate C++.  People who aren't
that much into it find it easier to get used to.  Evidently there's a lot of
'unlearning' to do...
StG

#: 11884 S12/OS9/68000 (OSK)
    22-Aug-91  09:25:43
Sb: #11877-Questions
Fm: Mark Wuest 74030,332
To: Jim Peasley 72726,1153
To some extent, it doesn't matter whether I like C++ or not, we're "stuck" with
it on our present project. Whether we use classes or not is up to us. Contrary
to Scott's observations, *I* think I may like it. Using classes enforces data
hiding in a way we only approached on our last project. Just to whet your
appetited, I'll give you a feature you may like:
 If you have a function, foo(), it can actually be several functions with the
same name, but different prototypes. This means you can have several functions:
 int foo(int arg);
 int foo(char * arg);
 int foo(void);
 void foo(int arg1, int arg2);
 int foo(int arg1, char *arg2);
 - all having the same name. In your mainline code, you just call it with the
proper argument type and the compiler knows which one you actually want. Pretty
slick, huh? (FWIW, this is called "overloading")
 As far as being happy with the current version of C, I *do* believe we will
have to migrate to ansi C anyway, so why not go "whole hog"? I would go for it.
A little serendipity: Borland supports C++ in their forum here on CI$:
 go bprogb
 Mark

#: 11824 S12/OS9/68000 (OSK)
    18-Aug-91  09:51:00
Sb: #MM/1 Audio
Fm: John R. Wainwright 72517,676
To: all
Trying to get some sound out of my MM/1.  Installation instructions say P5-1 is
sound out, P5-2 ground.  Connected those pins to the audio input jack on my
Magnavox monitor.  I am pretty sure that the "play"-type stuff wants the second
board, but I thought I could least get a "beep" out of it with "display 07". 
Nuttin.  (Well a quiet hum, maybe).
Suggestions?
John Wainwright
There is 1 Reply.

#: 11826 S12/OS9/68000 (OSK)
    18-Aug-91  11:15:17
Sb: #11824-#MM/1 Audio
Fm: Kevin Darling 76703,4227
To: John R. Wainwright 72517,676 (X)
John - that sounds (sorry :-) correct.  Should at least get a beep with 07.
Stand by tho; will be posting a newer driver in a day or so.
There is 1 Reply.

#: 11841 S12/OS9/68000 (OSK)
    19-Aug-91  20:34:40
Sb: #11826-MM/1 Audio
Fm: John R. Wainwright 72517,676
To: Kevin Darling 76703,4227 (X)
Thanks, Kevin, I'll be watching for it.
JohnW

#: 11855 S12/OS9/68000 (OSK)
    20-Aug-91  14:08:30
Sb: Color Command
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
Jim, this is scrunched up to fit in a message, but :-)
PROCEDURE color
PARAM p1$,p2$,p3$
DIM color,esc(3):BYTE\ esc(1)=$1b
ON ERROR GOTO 5000\ (* Give help msg if no parms at all
c$=p1$
IF c$="on" THEN \ (* Just do backgnd color if no foregnd
c$=p2$
GOTO 200
ENDIF
GOSUB 1000\ (* convert name to number for foregnd
esc(2)=$32\ esc(3)=color\ PUT #1,esc
ON ERROR GOTO 999\ (* Just exit if other parms missing
c$=p2$
IF c$="on" THEN c$=p N ENDIF
200 GOSUB 1000\ (* convert name to number for backgnd
esc(2)=$33\ esc(3)=color\ PUT #1,esc
999 END
1000 (* Convert c$ to integer color
RESTORE
LOOP
READ test$,color
EXITIF test$="end" THEN GOTO 5000 \ ENDEXIT
IF c$=test$ THEN RETURN \ ENDIF
ENDLOOP
RETURN
DATA "black",0,"grey",1,"gray",1
DATA "blue",2,"green",4,"red",8
DATA "cyan",6,"purple",10,"brown",12
DATA "lblue",3,"lgreen",5,"lred",9
DATA "lcyan",7,"yellow",13,"lgrey",14
DATA "white",15,"end",15
END
5000 (* Give help msg
PRINT "Syntax:   color <fcolor> [on] [<bcolor>]"
PRINT "          color on <bcolor>"
PRINT "Function: change fore/back colors"
PRINT "Colors:"
PRINT "          black white  grey "
PRINT "          red   green  blue "
PRINT "          lred  lgreen lblue"
PRINT "          brown yellow purple"
END

#: 11858 S12/OS9/68000 (OSK)
    20-Aug-91  20:59:17
Sb: #Beloved Ar.c on the MM/1
Fm: Keith H. March 70541,1413
To: All
Help:
How do I compile the 68K c source code called AR.AR on the MM/1?
I get alot of warnings!
name = othername
      dd dd dd
sdd
I get a arrow pointing to the "=" sign, WHAT IS UP.
Help
Keith
There is 1 Reply.

#: 11859 S12/OS9/68000 (OSK)
    20-Aug-91  21:26:33
Sb: #11858-Beloved Ar.c on the MM/1
Fm: James Jones 76257,562
To: Keith H. March 70541,1413
Your message was somewhat garbled--could you repost, please?

#: 11865 S12/OS9/68000 (OSK)
    21-Aug-91  00:26:10
Sb: #MM/1 & fonts
Fm: Jim Peasley 72726,1153
To: Kevin Darling 76703,4227 (X)
Kev;
  Continuing in my quest to eliminate garbled <T>ransmitted text using STERM,
here's another question for ya at 1200 baud.
  Why does the system grab 8,250 bytes when merging a 2059 byte font file? 
This is a repeatable process... each font loaded decreases available memory by
8.25k.
  ...Jim
There is 1 Reply.

#: 11870 S12/OS9/68000 (OSK)
    21-Aug-91  10:12:54
Sb: #11865-MM/1 & fonts
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
Jim - good question.  I'll look into it... thanks!

#: 11899 S12/OS9/68000 (OSK)
    23-Aug-91  01:57:57
Sb: #11884-#Questions
Fm: Scott t. Griepentrog 72427,335
To: Mark Wuest 74030,332 (X)
Actually, I like the features like that.  And the one where you can pre-set
optional arguments.  I figure that should be available in all C compilers. What
I have trouble with is when the C++'ers get really wacked out and the code has
all these strange ::'s and other odd constructs in them.  All I can say is,
when we have it in OSK, I'll learn it.  Till then, like, why bother.
But by all means, let's get it available soon.  I hate to think of all the code
I'm going to have to go back and re-write when it does come out...
StG
There is 1 Reply.

#: 11902 S12/OS9/68000 (OSK)
    23-Aug-91  08:14:57
Sb: #11899-#Questions
Fm: Mark Wuest 74030,332
To: Scott t. Griepentrog 72427,335 (X)
Scott,
 Maybe when I have finished coding a couple of the classes I designed for our
project I'll upload them, "::"'s and all <g>. I can think of a couple where the
data hiding concept is really kinda nice - users of the class don't have to
allocate storage or anything. One is a fifo message buffer that buffers up to
10 messages in ram, then starts putting them to the disk. All users of the
class have to know is
 msgbuf.putmsg();
  ... and ...
 msgbuf.getmsg();
 without knowing what it does or how it does it. And just by declaring a
"msgbuf", all the memory is allocated for you, the msg queues are created, and
the file is opened. Either way, you'll learn it when you need to (as in, when
it's forced on you, like me). :)
 Mark
There is 1 Reply.

#: 11918 S12/OS9/68000 (OSK)
    24-Aug-91  01:08:20
Sb: #11902-#Questions
Fm: Scott t. Griepentrog 72427,335
To: Mark Wuest 74030,332 (X)
I never said it wan't great.  I'm sure I'll even like it when I take the time
to learn it.  But woe on he who is within audible range when I do...
StG
There is 1 Reply.

#: 11964 S12/OS9/68000 (OSK)
    26-Aug-91  09:42:13
Sb: #11918-Questions
Fm: Mark Wuest 74030,332
To: Scott t. Griepentrog 72427,335
You should have heard the language while three of my Unix-oriented co-workers
attempted development under OS9 a couple of years ago. They eventually got used
to all the limitations, but it was awful for a couple of months!
 Mark

#: 11908 S12/OS9/68000 (OSK)
    23-Aug-91  18:08:41
Sb: #11859-#Beloved Ar.c on the MM/1
Fm: Keith H. March 70541,1413
To: James Jones 76257,562 (X)
Again:
How do I compile the 68k C source code called AR.C from the file AR.AR on the
MM/1?
I get a few warnings, but it goes on to compile, is that ok
Keith
There is 1 Reply.

#: 11921 S12/OS9/68000 (OSK)
    24-Aug-91  06:34:09
Sb: #11908-Beloved Ar.c on the MM/1
Fm: James Jones 76257,562
To: Keith H. March 70541,1413 (X)
Hmmmm...depends on the warnings.  Easiest way to check would be to just try it
out--create a few .ar files and see if you can extract the files back from
them, and download a .ar file and see whether you can extract the files from
it.  If you can, it should be OK.

#: 11915 S12/OS9/68000 (OSK)
    23-Aug-91  23:36:42
Sb: #TOPS Games
Fm: Colin J. Smith 73777,1360
To: Mark Wuest 74030,332 (X)
Has anyone gotten any of the TOPS games to work?  The ones I'm particularly
interested in are Moria and Nethack3.  When I try to run them I get a 'Unknown
Terminal Type: vsc' or some such error message.
I'm trying to run them on an MM/1.
Thanks,
 --Colin
There are 3 Replies.

#: 11919 S12/OS9/68000 (OSK)
    24-Aug-91  01:12:14
Sb: #11915-#TOPS Games
Fm: Scott t. Griepentrog 72427,335
To: Colin J. Smith 73777,1360 (X)
That's curious.  I don't have the games, so I don't know what the exact problem
is (I can't test for it).  But assuming that umacs works, then the TOPS games
must be using a different termcap library routine, which must be looking in a
different place for the termcap file.  Try looking around for a file that has
termcap entries (would be called termcap) in another directory.  If you find
it, save it off and copy our (/dd/sys/termcap) termcap in it's place.  But
first you might just try setting your TERM var to 'ansi' first.  If the termcap
file the game is looking for contains ansi, which it might, that would be the
easiest fix.
StG
There is 1 Reply.

#: 11922 S12/OS9/68000 (OSK)
    24-Aug-91  09:20:22
Sb: #11919-#TOPS Games
Fm: Colin J. Smith 73777,1360
To: Scott t. Griepentrog 72427,335 (X)
Actually, the disk (I downloaded it from here) contains nothing but the three
games files and a couple of readme's - no termcaps of any sort.  I've tried
copying the termcap from my system disk, but to no avail.  Is there something
on one of the other disks I need to get?
Thanks,
  Colin
There is 1 Reply.

#: 11933 S12/OS9/68000 (OSK)
    25-Aug-91  01:11:22
Sb: #11922-TOPS Games
Fm: Scott t. Griepentrog 72427,335
To: Colin J. Smith 73777,1360 (X)
Hmm.. You have a /dd/sys/termcap that has 'vsc' in it right? Oh, wait a sec,
maybe those programs are looking for the vsc in a differnt place.  Let me get a
hold of a copy and I'll check it out for myself...
StG

#: 11943 S12/OS9/68000 (OSK)
    25-Aug-91  20:06:45
Sb: #11915-#TOPS Games
Fm: Bob van der Poel 76510,2203
To: Colin J. Smith 73777,1360 (X)
Your message re getting the TOPS games to work sounded pretty familiar. They
would not work on my system either. So I did a bit of sleuthing.
Most of the TOPS stuff uses a port of curses (called ncurses) which has been
modified to use termcap instead of terminfo. The folks who did the port wrote
their own termcap functions, which are not quite as robust as the microware
ones. The TOPS termcap routine insists that the first name listed in a name
line be two characters long (actually, my reference states that it should be
so...). All you need to do is change the termcap name line from
   vsc!k1!signetics...
to
   k1!vsc!signetic...
Note, the !s should be bars, but I'm typing this off line and I'm not sure what
CIS does with bars.
Guess we should fix all of our termcap entries. The microware stuff will handle
either form, so no problem.
There is 1 Reply.

#: 11944 S12/OS9/68000 (OSK)
    25-Aug-91  21:38:58
Sb: #11943-TOPS Games
Fm: Colin J. Smith 73777,1360
To: Bob van der Poel 76510,2203
Ah, thank you.  Found out Nethack3 won't fit in my 1 meg o' RAM, and I don't
have all the files for Wanderer2.  Will keep trying, though.
Thanks again,
  --Colin

#: 11963 S12/OS9/68000 (OSK)
    26-Aug-91  09:39:24
Sb: #11915-TOPS Games
Fm: Mark Wuest 74030,332
To: Colin J. Smith 73777,1360
Colin,
 All I ever got working was the "cookie"-like program. I forgot what it was
called. Many of the TOP programs had blown pointers and would not run at all on
my memory protected system. I no longer run public domain software for which I
do not have source. :(
 Mark

#: 11917 S12/OS9/68000 (OSK)
    24-Aug-91  00:17:27
Sb: #MM/1 Monitors
Fm: Ernest Withers Jr. 71545,1117
To: ALL
 Just thought I'd upload the pin-outs of the monitor cables I've made
 to connect my MM/1 to my monitors. One monitor is a Packard Bell model
 PB8530MS multifrequency with the TTL/Analog switch in the Analog
 position. The other is a Magnavox model 8CM515. 
   MM/1 DB9 Pin #       Signal       PB8530MS DB9 Pin #     8CM515
   --------------       ------       ------------------     ------
      1 & 2              GND            6, 7, 8, & 9           3
       3                  R              1                     4
       4                  G              2                     1
       5                  B              3                     5
       6                  N/C      
       7                  SOUND 
       8                  H-SYNC         4                     2
       9                  V-SYNC         5                     6
 Note that I'm not sure about SOUND being on pin #7 of the MM/1 connector
 but it is on the CoCo3 and the pin-outs for the MM/1 are the same.
 Hope this is of interest to some of you.
 Ernest Withers.
There are 2 Replies.

#: 11920 S12/OS9/68000 (OSK)
    24-Aug-91  05:53:03
Sb: #11917-MM/1 Monitors
Fm: Kevin Darling 76703,4227
To: Ernest Withers Jr. 71545,1117 (X)
Great! Thanks!

#: 11924 S12/OS9/68000 (OSK)
    24-Aug-91  09:52:10
Sb: #11917-#MM/1 Monitors
Fm: Steve Wegert 76703,4255
To: Ernest Withers Jr. 71545,1117 (X)
Ernest,
Hope you don't mind that I've captured your message and placed it in the OSK
library. It's tips like these that make working with computers a whole lot
easier!
Thanks for the effort!
Steve
There is 1 Reply.

#: 11930 S12/OS9/68000 (OSK)
    24-Aug-91  20:25:46
Sb: #11924-MM/1 Monitors
Fm: Ernest Withers Jr. 71545,1117
To: Steve Wegert 76703,4255 (X)
Steve (and Kevin),
    No problem. After I made the cables I thought someone else might need the
info so I posted it here and on Delphi.
Ernie.

#: 11942 S12/OS9/68000 (OSK)
    25-Aug-91  19:14:05
Sb: Termcap - MM1
Fm: John R. Wainwright 72517,676
To: ALL
Was playing around with the "NEWCAL.AR" file from lib 12.  It's a little
calendar utility - works fine, but it wants to find entries for "se" and "so"
in your termcap file. Before I figured out how to put those entries in termcap,
I killed all the lines that used termcap from the source and recompiled it
(that works too, but no highlight on today's date).  Anyhoo, after digging
around in the books, I added the following to the end of the termcap file 
:se=\037\041:so=\037\040:  (those are the octal codes for reverse video start
and  end).  As an added bonus, uemacs now displays its status line in reverse
video.   How bout that?.

#: 11970 S12/OS9/68000 (OSK)
    26-Aug-91  17:53:46
Sb: OSK
Fm: Dave Philipsen 73627,710
To: ALL
I'm just getting started in the OS9/68000 world as I just bought a PT68K4
computer a couple of weeks ago. Even though the PT comes with four serial
ports, I went ahead and bought an IBM-compatible 2400 baud modem card mostly so
I could try my hand at writing a device driver and to see just how easy it
would be to make the thing work. I verified that the card DOES work by setting
it up in DEBUG. It is programmed as if it were a standard 8250 com port chip.
What I need is any information that anyone might have on writing device drivers
for OS9/68000. I'm also looking for info. on getting the thing set up with the
interrupt system. I'm hoping that maybe someone has already written some sort
of SCF device driver that I could play around with. Any ideas?????
 -Dave Philipsen
Press <CR> !> 

#: 11984 S12/OS9/68000 (OSK)
    27-Aug-91  08:01:18
Sb: #11970-#OSK
Fm: Mark Wuest 74030,332
To: Dave Philipsen 73627,710 (X)
Dave,
 I have talked Microware out of source in the past and severely altered the
Z8530 driver for our MVME147 system. I can't upload it as it is still basically
Microware's copyrighted source. What you *can* do is disassemble it with debug.
You will obviously have no symbols, but it might help. Maybe the people who
sold you your system will give you source to the drivers you do have. You are
correct in assuming they will be very similar, though the device set-up and
configuration stuff (eg: baud rates, bits/character) can be challenging,
especially if you want to provide hooks (setstat()'s) to change them on the
fly.
 That was 3 years ago. Since then, we wrote our own block-oriented file manager
(for protocol conversion) and *every* device driver I have written has been
doing some protocol's level II under *that* file manager.
 Good luck!
 Mark
There is 1 Reply.

#: 11992 S12/OS9/68000 (OSK)
    27-Aug-91  20:35:09
Sb: #11984-OSK
Fm: Dave Philipsen 73627,710
To: Mark Wuest 74030,332 (X)
Thanks for the info. I've contacted Peripheral Technologies and they're going
to send me the 68681 driver source code for a small fee ($25). That should get
me going. I don't think I'll have any problems with the GetStat & SetStat
functions...the main thing I need is a basic skeleton program that will help me
to see how the IRQ stuff is set up and how the buffers are set up in system
memory. If I get a decent driver for the 8250 written, I'll be sure and U/L it
here.
-Dave Philipsen

#: 11994 S12/OS9/68000 (OSK)
    27-Aug-91  21:36:51
Sb: #11963-#TOPS Games
Fm: Timothy J. Martin 71541,3611
To: Mark Wuest 74030,332 (X)
I've gotten the chess program to work, from TOPS release #1. Assume that it
still works in TOPS release #2.  I'm using vt100 as defined in mw termcap.
There is 1 Reply.

#: 12012 S12/OS9/68000 (OSK)
    29-Aug-91  07:24:31
Sb: #11994-TOPS Games
Fm: Mark Wuest 74030,332
To: Timothy J. Martin 71541,3611
Oh, yeah - I got that one working, too. It was actually quite good, as I
recall. I just don't run any PD stuff w/o source at work. (Virus paranoia)
 Mark

#: 12046 S12/OS9/68000 (OSK)
    02-Sep-91  05:00:21
Sb: OSK
Fm: Ed Gresick 76576,3312
To: ALL
To FHL, IMS, all OSK programmers and Users and any other interested parties.
I've uploaded a file called 'oskstand.doc'.  This is my proposal for the
establishment of a minimum standard to insure software compatibility for
different hardware platforms, present and future, running under OS9/680x0.
I've also uploaded a second file called 'interface.doc'.  It summarizes my
thinking on how programs should be implemented to ease the transition of
non-OS9 users to OS9.  It isn't intended to be a standard.
Both of these files are in Library 12.
I await all comments.
Ed Gresick - DELMAR CO

#: 12069 S12/OS9/68000 (OSK)
    04-Sep-91  05:35:46
Sb: Your Standards Texts
Fm: Mark Griffith 76070,41
To: Ed Gresick, 76576,3312
Ed,
I read both your files on interfaces and standards for OSK developers.  I think
we have talked about many of your ideas before and I agree with all that you
mentioned.
One of the problems that the new OSK programmers will have is just as you
mentioned, coming from a different environment and needing to new the "new way
of doing things".  Even for CoCo owners this will be a little difficult if they
have never used termcap before. As you said, they are to used to hardcoded
screen controls.
I might add that if anyone DOES NOT follow Ed's advice, they and their programs
will be doomed to die a quick death.  Well, not the programmer too (wry grin). 
This field is different and there are very many more non-graphics OSK systems
out there than MM/1s or TC-70s.  This does not mean you should not program for
these newer machines and their graphics capabilities, but you shoudl keep in
mind what Ed said.....if you do not absolutely NEED graphics in your program,
don't put it in.  You'll be cutting yourself out of a very large part of the
OSK market.
What I am doing, and my suggestion is, put some code in your program to detect
if it is on a graphic terminal or not, such as a getstat to get the window type
or something like that.  If this succeeds, then go for the graphics, if not,
then resort to using a termcap environment.  This will mean that you'll have to
have two different interfaces built into the program, and it will be
correspondingly larger, but you will gain greater flexibility, and reach a
larger market.  Not only will the program run on many different types of
machines, but if say an MM/1 user calls his machine from work and logs in,
he/she will be able to use the same familier software from a terminal without
changing anything.
Mark

#: 12077 S12/OS9/68000 (OSK)
    04-Sep-91  20:49:17
Sb: #startup blues
Fm: Bob van der Poel 76510,2203
To: all
I just thought that I'd share a problem I had last night (actually, until the
wee hours of the morning!). I decided to create a new boot disk with some
modified modules. I used os9gen to create a new boot and copied the requesite
files. But the disk would not boot!
It would hang, it seemed, in the middle of the startup file. To make a long
story short: I had the following line in my startup file
  copy file1 file2 file3 -w=/r0 >>>/nil
The redirect is there so that I don't get copy's messages on every boot. The
problem is that file2 and file3 were not on the disk. Copy then printed a
'continue' prompt to 'nil' and then waited for a response. I really don't know
where it expected the response to come from (either the startup file itself or
nil) but it never got it and hung.
Moral: make sure all the files are there!
There is 1 Reply.

#: 12081 S12/OS9/68000 (OSK)
    05-Sep-91  03:26:10
Sb: #12077-startup blues
Fm: Bob Taylor 73270,3124
To: Bob van der Poel 76510,2203
Bob,
 Try copy -a file1 file2 file3 -w=/r0 >>>/nil. Copy will then abort on error.
Bob

#: 12080 S12/OS9/68000 (OSK)
    04-Sep-91  23:41:08
Sb: #MM/1
Fm: Colin McKay 73340,2275
To: All
Greetings all.
I just thought that I would let you know that my MM/1 arrived yesterday. (3 Sep
91). It was originally mailed by IMS on 16 Jul 91, but was lost by UPS.
Anyway, it took about 45 minutes to assemble, and worked first try. Lots of
fun. Now all I need is my IO  board...
There is 1 Reply.

#: 12089 S12/OS9/68000 (OSK)
    05-Sep-91  20:27:52
Sb: #12080-MM/1
Fm: John R. Wainwright 72517,676
To: Colin McKay 73340,2275
Lost by UPS?  Now we know why they are called "OOPS".  Glad you finally got it,
and welcome to the (small , but growing) club. Haven't seen anything recently
on the IO boards. Heeeeeeyyyyyy PAUL! (grin).
John Wainwright

#: 12116 S12/OS9/68000 (OSK)
    07-Sep-91  20:02:58
Sb: #Intercepts
Fm: Bob van der Poel 76510,2203
To: all
I'd like to use an intercept to check for the user hitting the keyboard abort
key. When the key is hit my program should go and delete a bunch of temporary
files and do some other cleanup chores, then it should terminate.
The example on page 82 of the Microware C manual shows an example of this. The
interecpt routine sets a global flag which the main loop of the program
monitors. This is not workable, since I don't have a main loop which is checked
on a continuous basis--control could be in any of several areas, so checking a
flag is out. On the other hand, I can't do I/O, etc. until after I leave the
intercept . . . and simply branching to another routine IS NOT leaving the
intercept. So, what I need is a method to tell OS9 than it's okay to leave
system mode, then I'll call my cleanup routines and exit. Anyone know how I
tell this lie to the system?
BTW, I guess the same problem occurs using longjmp() if you want to restart the
program after a signal.
The fact that OS9 leaves you in system mode after a signal interecpt is a real
pain if you are writing an application. Too bad there isn't some kind of flag
which could be set when the intercept is set up to signal system or user mode.
There are 2 Replies.

#: 12117 S12/OS9/68000 (OSK)
    07-Sep-91  20:40:46
Sb: #12116-#Intercepts
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203
Ummm.  Where does it say that intercept routines are in system mode? You can do
I/O from it... I have!
There is 1 Reply.

#: 12118 S12/OS9/68000 (OSK)
    07-Sep-91  21:17:27
Sb: #12117-Intercepts
Fm: Pete Lyall 76703,4230
To: Kevin Darling 76703,4227 (X)
Me too.... There should be a number of utilities in DL9 that I have done over
the years that trap interrupts and the like.
Pete

#: 12122 S12/OS9/68000 (OSK)
    08-Sep-91  00:43:10
Sb: #12116-Intercepts
Fm: Bob Taylor 73270,3124
To: Bob van der Poel 76510,2203
Bob,
  Microware does not recommend doing I/O while in the intercept routine as
signals to that process are enqueued while in the intercept. You could lose
signals. Use of I/O in an intercept is therefore an application decision.
 #include <signal.h>
 intercept(sig)
 {
    switch (sig)
    {
        case SIGINT:
        case SIGQUIT: cleanup();
    }
 }
Bob

#: 12137 S12/OS9/68000 (OSK)
    08-Sep-91  21:34:01
Sb: #12117-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)
Well, ummm, errr, okay... Actually, in The OS9 Catalogue, page 21, it does
state that "system state functions and OS-9 interrupt service routines operate
only in sypervisor state..." So I assumed that when, on page 81 of the C
manual, they say "any i/o using the OS-9 C library (eg. printf) _cannot_ be
performed inside both the intercept handler function and the main program" I
figured that was the reason. Bob Taylor's comment about signals being enqueued
makes as much sense. But, then how does one un-enqueue the signals -- this
implies to me that if you were to use an intercept to restart a program (maybe
back to the main menu for a game, or whatever) then you'd only be able to do it
once. Under Level II I have used signals for that purpose, without any
problems. I assumed that (for whatever reason) you could not do it with OSK.
Maybe some more expanations from MW are in order. Also, all the examples from
MW that I've seen do avoid I/O in the intercept (they just set a flag and
return). Guess it's time to stop reading the manual and just write the code.
Also, would it make any difference if one is using the CIO trap for I/O?
There are 2 Replies.

#: 12141 S12/OS9/68000 (OSK)
    09-Sep-91  00:28:08
Sb: #12137-#Intercepts
Fm: BILL HEALTON 73367,357
To: Bob van der Poel 76510,2203 (X)
Bob - I have barely scratched the surface of C programming, but I have worked
with several device drivers. Applying their approach to your problem...maybe
you could try the following:
Create an initial "core" procedure that sets up an intercept, forks the other
procedure(s) of your program and tsleep(0). Then, any signal will wake the
"core" process...which can either ignore it and re-sleep or do your cleanup
and kill the children(ie. your program). The "core" procedure could even be
run at a higher priority than the children to ensure its not pre-empted by
a child during the cleanup/closeout time.
In the above the "core" and children should all be running in User state with
none of the System state restrictions. Hope this is of some help.
Bill Healton 73367,357
There is 1 Reply.

#: 12150 S12/OS9/68000 (OSK)
    09-Sep-91  20:49:24
Sb: #12141-Intercepts
Fm: Bob van der Poel 76510,2203
To: BILL HEALTON 73367,357
Interesting idea, running all the functions of a large program as sub-functions
of a tiny little core (maybe a menuer). I have to think a bit about that for
future projects. In the meantime, I just added the signal trap as others have
suggested and do the cleanup from it. Seems to work fine.

#: 12158 S12/OS9/68000 (OSK)
    10-Sep-91  03:45:12
Sb: #12137-Intercepts
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203 (X)
Bob,
The "interrupt routines" mentioned there, are for cpu interrupts... not user
interrupt service routines (which should just be called: signal service
routines :-)
I just took a quickie non-pro glance with the debugger at the kernel, and what
I see is this:
Whenever your turn to run comes (assumption: from a signal or sleep wakeup or
whatever), the kernel checks to see if you're already in an signal intercept
routine... if so, it cuts right back to you.
Therefore, I would think that normal wakeup driver signaling will still work,
and so doing I/O should be okay (which the exception of getting, say, a BREAK
key or something else that signals you especially).  Ie: don't expect to get
user signals while in the signal intercept routine :-)
If you jump out of your routine back into a main loop (under OSK or OS9), then
you leave a stackframe hanging around, which will slowly eat up your data area
until you crash.  Under OSK of course, you also leave the special "I'm in an
intercept routine" flag hanging, and won't ever enter the signal intercept code
again.  So the F$RTE under OSK is the correct way to exit.
Anyway, just some info.  I'm having to learn about OSK myself :-) kev

#: 12138 S12/OS9/68000 (OSK)
    08-Sep-91  21:34:13
Sb: #12122-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Bob Taylor 73270,3124 (X)
Bob, Thanks for the reply. I guess I'll just have to give it a try and see what
happens, despite MW's admonishments to the contrary.
There is 1 Reply.

#: 12142 S12/OS9/68000 (OSK)
    09-Sep-91  05:13:24
Sb: #12138-Intercepts
Fm: Bob Taylor 73270,3124
To: Bob van der Poel 76510,2203 (X)
Bob,
Ooops - intercept(sig) should read catchsig(sig)!
It is my understanding that if other signals are pending, while in the
trap function, after exiting, the trap function is immediately called again
to process the next pending signal.
You should encounter no problems in this particular case.
Bob

#: 12147 S12/OS9/68000 (OSK)
    09-Sep-91  08:59:25
Sb: #12116-#Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
Bob,
 AS you've been told, you are not in system state when you go to your signal
trap. I assume by intercept mode you mean you have a line
 intercept(sigtrap);
 somewhere. What happens when you get a signal is this:
 (You cannot get one in the middle of a time slice, BTW)
 1 It is your process'es turn at the cpu (your time slice is coming).
 2 The kernel looks to see if you have any signals pending *before* switching
   to your task.
 3 If you have done an intercept() call, it executes the function you pointed
   to, pasing the signal as an int.
 4 *If* and when you return() from the signal trap, your process continues
   execution where it left off when its last time slice was up.
 The reason MW says to limit what you do in a signal trap is because you don't
want to risk missing a signal. If you were to do a sleep() in the signal trap,
10 processes could send signals to you, but you would only "get" the last one.
 (continues)
There is 1 Reply.

#: 12151 S12/OS9/68000 (OSK)
    09-Sep-91  20:49:39
Sb: #12147-#Intercepts
Fm: Bob van der Poel 76510,2203
To: Mark Wuest 74030,332 (X)
Thanks for the details, Mark. I added the cleanup() stuff to the intercept
routine and all seems to work fine. Now, more questions: once the signal trap
has been entered all other signals will be blocked until a F$RTE is done ...
and this is only done when the intercept routine is actually terminated. I
suspect that jumping back to another section of the main program via a
longjmp() will not cause a F$RTE (it better not!), so this will leave the
signals in a blocked state. I wonder, would re-setting the intercept serve to
un-block things?
There are 3 Replies.

#: 12164 S12/OS9/68000 (OSK)
    10-Sep-91  08:21:10
Sb: #12151-Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
Bob,
 Not all signals are blocked. The last signal you were sent is held (you would
not really say it was queued) and handled on your next time slice. While in the
signal handler, you are still going to submit to the kernel's task switching so
may be in trouble. I would only do a bunch of stuff if I were going to exit().
If you are doing the longjmp() (is this OSK?) to make your code smaller, I
would recommend copying the block to your signal trap or putting it in a
function called , say, cleanup().
 The point is, you may even get switched out ("swapping" has been used here,
but that normally refers to sections of memory getting "swapped" out to the
disk. Few systems need to do this anymore as most uP's support paging. OS9's
kernels do not support either, though they used to talk about a level III that
would.), but will come back to the signal trap where you left off. I am pretty
sure you will not re-enter the trap at the top if there is another signal
pending. Microware would have to answer that one, and when you get their
support desk, they're going to try and talk you out of doing I/O in the trap,
even if you are about to exit.
 You could test this by putting a sleep(0) in a signal trap.
 Mark

#: 12165 S12/OS9/68000 (OSK)
    10-Sep-91  08:26:27
Sb: #12151-#Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
Bob,
 I just saw Kevin's response to you and he confirms that you will be put back
into your signal trap if you give up or lose your "tick". (I/O is almost sure
to put you in the sleep queue.)
 Whenever I start feeling like a genius, I just log in here and see how many
people there are that are smarter than me. ;)
 Mark
There is 1 Reply.

#: 12168 S12/OS9/68000 (OSK)
    10-Sep-91  10:18:10
Sb: #12165-Intercepts
Fm: Kevin Darling 76703,4227
To: Mark Wuest 74030,332 (X)
Mark,
  If you hadn't taken the time to give a bunch of clues, I sure wouldn't have
gone looking myself :-)   One of these days I'm gonna hafta take OSK apart so
that I can answer "with authority", instead of "it looks like to me" guesses
<grimace>

#: 12166 S12/OS9/68000 (OSK)
    10-Sep-91  09:11:14
Sb: #12151-Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
(Gads, this is my third response!)
 I just re-read your message offline and something in it set off an alarm in my
head (scary, isn't it?). Why do you want to "unblock" things when you are going
to exit()? The process is just going away. If you do not plan to exit(), read
Kevin's message carefully. What he says about the stack frame is absolutely
correct. The only proper way to "un-block" things is to return() from the
signal trap. This means you would have to first have to return() to the trap
from whatever routine you longjmp()'ed to. If I could, I would talk you out of
a goto (or its relative, longjmp()) here. If you have shared code, that's what
functions are for.
 Bag my ramblings and just make sure you return() from the trap. The compiler
or kernel will take care of making the F$RTE (oh, it's in the kernel). If
you're going to exit(), then you don't have to do anything.
 Mark

#: 12148 S12/OS9/68000 (OSK)
    09-Sep-91  09:01:41
Sb: #12116-Intercepts
Fm: Mark Wuest 74030,332
To: Bob van der Poel 76510,2203 (X)
(continued)
 Since you are going to exit() anyway, who cares what other signals you might
have gotten? Go ahead and write(), close(), and unlink() to your heart's
content.
 Mark

#: 12143 S12/OS9/68000 (OSK)
    09-Sep-91  06:09:02
Sb: OSK standards
Fm: Robert A. Larson 75126,723
To:  76576,3312
I've uploaded my reply to Ed's oskstand.doc to standrep.doc in dl 12.

#: 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

#: 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

#: 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.)

#: 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?

#: 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

#: 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

#: 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

#: 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

#: 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

#: 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.

#: 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

#: 12440 S12/OS9/68000 (OSK)
    28-Sep-91  21:12:56
Sb: #12417-Intercept
Fm: Bob van der Poel 76510,2203
To: Roy Dacus 70721,1113 (X)
Thanks Roy. I'm not sure exactly what the code is doing -- I'll have to print
it out and study. Yes, I was the one wanting to do the longjmp() out of the
intercept (well, I don't nesc. *want* to do it, I was trying to find out if I
could and don't forget that this started with just wanting to do I/O in the
intercept which I guess is okay now). But with all the problems being created
it might be better to forget the longjmp() stuff and just do an exec() or
whatever and restart the program. It seems to me that this would ensure a
cleanup. Guess that one could pass some params to the 'new' program telling
that this is a re-start -- might even use a data module for intitialized
variables.

#: 12447 S12/OS9/68000 (OSK)
    29-Sep-91  21:18:19
Sb: Intercept
Fm: Roy Dacus 70721,1113
To: Bob van der Poel
Well if you don't want to longjmp, the next program lets you return.  Both
programs keep OSK happy with a F$RTE for each signal caught.  All I do is
change the return address on the stack.

#: 12448 S12/OS9/68000 (OSK)
    29-Sep-91  21:19:50
Sb: Intercept
Fm: Roy Dacus 70721,1113
To: Bob van der Poel
/* sigs.c */
/* a program to show that after you catch a signal you can */
/* do anything */
/* runs best after a "$ Tmode nopause;load date" */
/* control E to end  *   control C to test */
#include <stdio.h>
/* start of stuff for tcept */
unsigned long _afunc1;
unsigned long _afunc2;
unsigned long _afunc3;
/* end of stuff for tcept */
unsigned long count1;
c1check(signum)
int signum;
{
    if (signum != 3)
        exit(signum);
}
c2check()
{
    system("date");
}
c3check(signum)
int signum;
{
}
numpr()
{
    int count;
    long place;
    count = 0;
    place = (long)&count;
    printf("%lu\n",place);
}
main()
{
    int time1;
    count1=0;
    tcept(c1check,c2check,c3check);
    while(1) {
        printf("%lu\n",count1++);
        if (count1%24==0)
            numpr();
        for (time1=0; time1<5000; time1++);
    }
}
#asm
* * * * *
* void tcept(func1,func2,func3)
* int (*func1)()
* int (*func2)()
* int (*func3)()
* tcept (Twin interCEPT)
* A intercept replacement that lets you do anything.
* 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().
* 3: keep it short.  This is just like intercept().
* 
* func2 is run just like any other function.
* Thats means the following:
* 1: anything you can do in any other funtion you
* can do in this one.
* 2: you can longjmp(). But you have to run tcept() again.
* 3: you can exit().
* 4: you can run intercept().
*
* func3 is the intercept function went func2 is running.
* Same conditions as func1.
* (continued)

#: 12449 S12/OS9/68000 (OSK)
    29-Sep-91  21:21:08
Sb: Intercept
Fm: Roy Dacus 70721,1113
To: Bob van der Poel
tcept: move.l a0,-(a7) save a0
 move.l d0,a0 temp save of -> one
 beq.b _tcept1 if zero jump and tell os9 to turn off intercept
 move.l a0,_afunc1(a6) real save of -> one
 move.l 8(a7),a0 get -> to three
 move.l a0,_afunc3(a6) save of -> three
 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
 lea.l _tcept3(pc),a0 new intercept function to use for func2
 os9 F$Icpt tell os9
 pea _tcept2(pc) old intercept ->
 pea _tcept4(pc) return address to me
 move.l _afunc2(a6),a0 -> to func2
 move.l a0,-(a7) return address for F$RTE
 move.w 76(a7),a0 get old sr (base=64 plus a 3 long push)
 move.w a0,-(a7) sr
 move.l a7,a0 get a7
 addq.l #6,a0 adjust address
 move.l a0,-(a7) a7
 move.l a6,-(a7) a6
 clr.l d0
 move.l a5,-(a7) a5
 move.l a4,-(a7) a4
 move.l a3,-(a7) a3
 move.l a2,-(a7) a2
 move.l a1,-(a7) a1
 move.l d0,-(a7) a0
 move.l d7,-(a7) d7
 move.l d6,-(a7) d6
 move.l d5,-(a7) d5
 move.l d4,-(a7) d4
 move.l d3,-(a7) d3
 move.l d2,-(a7) d2
 move.l d0,-(a7) d1
 move.l d0,-(a7) d0
 os9 F$RTE run func2 with func3 as the intercept function
*
_tcept3 move.l d1,d0 put signal in right place
 move.l _afunc3(a6),a0 -> to func3
 jsr (a0) run func3
 os9 F$RTE this is a real F$RTE
*
_tcept4 move.l (a7)+,a0 old intercept ->
 os9 F$Icpt tell os9
 movem.l (a7)+,d0-d7/a0-a7 restore all regs
 rtr return with cc
#endasm

#: 12493 S12/OS9/68000 (OSK)
    03-Oct-91  01:08:14
Sb: I've defected!
Fm: PaulSeniura 76476,464
To: all
Hi all.  I'm back.  I've "defected".  I bought a friend's Atari 520ST just
yesterday.  It already has a second 512k "strip" to bring it up to 1-meg RAM. 
Just tonight I went to a store that is clearing out its Atari stock (yep
another one is going to be 100% IBM compatible just like Tandy did). Right now
as I type this, I'm testing a 16-MHz 68000 "Turbo16" upgrade *with* Instruction
Cache sorta like the pipeline effect in 386 CPUs.  That board was about 2/3rds
the discount price at this store!  I almost bought Dr.T's Tiger Cub MIDI
system, too, since I have grown weary of waiting for Mike Knudsen to
incorporate the functions we need in his Ultimuse-III.
So ... I'd like to know the status of Atari/OS9?  And whether it has the
windowing system available yet?  I'm serious ... someone try talking me into
buying it.  And maybe someone can give me some good reasons to keep my CoCo? 
(like is the Level-II upgrade seeing the light at the end of that proverbial
tunnel yet?)
-- Thx, Paul Seniura.

#: 12515 S12/OS9/68000 (OSK)
    05-Oct-91  11:03:07
Sb: STERM & MM/1
Fm: John R. Wainwright 72517,676
To: Mark Griffith 76040,41
Hi Mark,
 I was playing with the source from STERM 1.5.1 (from lib 12) last night and I
finally got it to compile on my MM/1.  (It even works, using it at this
moment).  My compiled version is a little longer than the one in the archive,
most likely because I had to make my own "getopt.h" and a couple of ".r" - type
files for the linker.  Since I am not real brilliant in "C", this took a while.
Is there an enhanced library for OSK (like the Kreider libs for Level II on the
COCO) that I missed somewhere?
  My purpose for this exercise is mostly just to learn more about "C" and the
MM/1, next I'm gonna try to add ZMODEM to STERM.
John R. Wainwright

#: 12516 S12/OS9/68000 (OSK)
    05-Oct-91  11:15:28
Sb: MM/1 woe
Fm: Jim Peasley 72726,1153
To: All
  Are there any hardware hackers out there this weekend that didn't go to the
Fest??  Kev P. - are you out there?
  Does anybody know what the 48 pin chip marked BT478KPJ66 is on the MM/1 board
nearest the video out port?  Also see msg. #12492.
  If I could find out what it is and what it does, I might consider trying to
find a replacement this weekend and popping it in, as the one in my MM/1 blew
it's little brains out all over the inside of the case when I powered it on.
  I really don't want to be down for ANOTHER month!  H E L P !!
..Jim
Press <CR> !>[{O}{w3{{{_{{{{{{{{{b{{qxD{{_{_w3t({{{{{{t({{{{Q%{{

#: 12521 S12/OS9/68000 (OSK)
    06-Oct-91  16:24:05
Sb: #12493-I've defected!
Fm: David J. Campbell 72707,1346
To: PaulSeniura 76476,464 (X)
Paul,
     Well...   Tandy isn't *100%* IBM.   They still have the Model 102, a
pocket computer, and 2 word processors.:-)
                                        Dave

#: 12615 S12/OS9/68000 (OSK)
    14-Oct-91  08:24:29
Sb: #12574-Atari/OSK try #2
Fm: DENIS CHARTRAND 72561,2714
To: PaulSeniura 76476,464 (X)
   I'm using OSK on Atari since 1987. First version 1.2 (the TLM port) and
later Microware version 2.2 and finally now, version 2.3. My Atari is a 1040ST,
but with 4 Meg of RAM and 16 MHz T16 CPU. Works great with OSK, everything is
faster. It is compatible with T16 cache memory. It works with TOS 1.0, but it
is better if you use TOS 1.4, it's faster. OSK for Atari ST does not work on TT
machines.
  You can boot OSK directly from a TOS hard disk partition, as opposed to what
is mentionned from message #12597. Simply patch the "Starthd.prg" TOS file with
a sector editor by replacing references to floppy "a:" path to "c:" path every
where in the file.
  OS9/68000 version 2.4 from Microware is ready, but Microware didn't yet port
it to Atari ST. A recent FAX from Microware mentionned that they will use
Cumana/Wolfgang Ocker german port, version 2.4, for the North-American market,
instead of their usual upgrade.
  It is a good idea. I went in Germany this summer and I saw a friend who use
this OSK. It is far better than what we have: no ROM calls, X Windows like
environment, up to 8 physical hard disks, many more programs, etc. Hope that
all will be included in the upgrade.
 BYE

#: 12618 S12/OS9/68000 (OSK)
    15-Oct-91  06:10:15
Sb: #C language
Fm: Dave Philipsen 73627,710
To: ALL
I'm having some problems with embedded assembly language in C programs using
the Microware C compiler under OSK V2.4. Could someone explain to me how
parameters that are passed to a function can be accessed by an embedded
assembly language program in that function? I've had limited success getting to
the parameters by accessing them at different offsets on the stack but it seems
like they're not always where they should be logically.
-Dave Philipsen
There are 3 Replies.

#: 12619 S12/OS9/68000 (OSK)
    15-Oct-91  08:31:53
Sb: #12618-C language
Fm: Mark Wuest 74030,332
To: Dave Philipsen 73627,710 (X)
Dave,
 Function calls in Microware C under OSK have a very predictable method of
passing arguments. The first two arguments will always be in d0 and d1. The
rest are on the stack in order. For simplicity, I would strongly recommend only
passing two arguments to a function in which you wish to have imbedded
assembly.
 Another technique you might try is to not pass arguments and set some globals
to the values needed. Then you can access them directly and in a
selfdocumenting manner: arg1(a6), arg2(a6), etc.
 Whatever floats your boat!
 Mark

#: 12621 S12/OS9/68000 (OSK)
    15-Oct-91  12:28:14
Sb: #12618-C language
Fm: Pete Lyall 76703,4230
To: Dave Philipsen 73627,710 (X)
Dave -
Parameters passed to a function are typically passed on the stack. You'll need
to look at the calling code, and see how the stack is stuffed.
Pete

#: 12623 S12/OS9/68000 (OSK)
    15-Oct-91  20:22:01
Sb: #12618-#C language
Fm: Bob van der Poel 76510,2203
To: Dave Philipsen 73627,710 (X)
Dave, the calling rules are detailed quite nicely in the 68K C manual (page3-3
to 3-6. If you want to "cheat" a bit, write the function in C first, compile it
to a assembler file (cc file.c -a) and then go in and rewrite the compiler
generated stuff. But tell us: with the speed of the 680x0 and the relative
efficiency of C why are you coding in assembler?
There is 1 Reply.

#: 12625 S12/OS9/68000 (OSK)
    16-Oct-91  05:55:39
Sb: #12623-#C language
Fm: Dave Philipsen 73627,710
To: Bob van der Poel 76510,2203 (X)
Well, I did kinda figure out the parameter passing now. Seems to me that it's
not quite working right (the C compiler). But, I'm able to get what I need even
though it doesn't seem to be in the most logical manner. Oh, the reason for
coding assembler is that there are no C functions that exist to do what I'm
trying to do! So, I just code it in assembler and now I've got a function to do
just what I want.
There is 1 Reply.

#: 12629 S12/OS9/68000 (OSK)
    16-Oct-91  13:43:55
Sb: #12625-C language
Fm: Pete Lyall 76703,4230
To: Dave Philipsen 73627,710
Dave -
Ummm.... that's the same rationale you'd use to write a C function. C is an
inherently extensible language. Basically... if the function you want doesn't
exist, code it up. The beauty is that you then add that function to a local
library of your choice, and you'll never recode it again... just link it in.
Pete

#: 12667 S12/OS9/68000 (OSK)
    21-Oct-91  23:37:43
Sb: #Tc9
Fm: Jason Leinen 76665,1627
To: all
I am seriously considering FHL's Tc9 as my next computer.  However there are
some things about it that I have not been able to determine.  For example, does
the computer already come with the infamous Kbus so I can add the 68000 cpu? 
Also will the 68k cpu also be able to run OSk in addition to being a
coprocessor for Level II?  Is there anyway to increase graphics resolution?
    I would also like to hear from someone who has already purchased one for
eir opinion of its performance (are there people out there who have one?). This
information would be very helpful.
                         ThankQ
                  Jason Leinen
There are 3 Replies.

#: 12668 S12/OS9/68000 (OSK)
    22-Oct-91  00:32:54
Sb: #12667-Tc9
Fm: Jim Sutemeier 70673,1754
To: Jason Leinen 76665,1627 (X)
TC9--> you would have to purchase a KBus to use the Tiger Card, Jason.  The
Tiger Card is $130, and the KBus is $150.
I don't see why the 68K cpu couldn't run OSK programs, but I suspect the best
use of the 6809/68K marriage is using the 68K card as a memory management
handler for the 6809.
Graphics resolution would be the same as for the CoCo....
There are some TC9's out there (saw a message on I think it was Delphi from
someone that had one), however, Frank is unhappy with the manufacturer of the
TC9 cards, and has now suspended shipping of the TC9's for what he terms 'quite
a while' so he can iron out a couple of buglets and also get a new
manufacturer.
jim Sutemeier

#: 12670 S12/OS9/68000 (OSK)
    22-Oct-91  07:21:30
Sb: #12667-Tc9
Fm: James Jones 76257,562
To: Jason Leinen 76665,1627 (X)
According to the most recent file on the Tiger that FHL uploaded here,
OS-9/68000 has been ported to the Tiger, but essentially none of the software
one would want to have to assist the 6809 (6309?) in running OS-9/6809 Level II
has been written. (Things may have changed since then.)

#: 12674 S12/OS9/68000 (OSK)
    22-Oct-91  21:25:11
Sb: #12667-Tc9
Fm: Bob van der Poel 76510,2203
To: Jason Leinen 76665,1627 (X)
Jason, this months (Nov/91) Rainbow has a review of the TC9.

#: 12669 S12/OS9/68000 (OSK)
    22-Oct-91  06:15:08
Sb: osk standards
Fm: Dave Philipsen 73627,710
To: kevin darling
Kevin, Hi! It's been a long time since we last talked on Delphi. I don't get on
Compuserve that often but I just thought I'd drop in and see what's going on
here. I know that you've been involved recently with some OSK projects and
that's part of what I wanted to talk about. A few months ago, I picked up a
System IV computer and I've been spending some time getting familiar with it. A
couple questions:
1) Has a standard been talked about yet for graphics on the OSK machines? Has
anyone come up with standardized GetStt/PutStt routines or windowing codes yet?
If not, are there plans to create such a standard?
2) How about a standard for mouse drivers? We were just discussing some of the
specs on Microsoft & Logitec mice over on Delphi and I'd like to write a driver
to use these. But, there's no sense working on one if it can't be used
universally.
Any information you can give me that will help me to write standardized user
programs would be appreciated.
-Dave Philipsen

#: 12701 S12/OS9/68000 (OSK)
    26-Oct-91  12:17:18
Sb: #G Windows
Fm: Keith H. March 70541,1413
To:  76703,4227 (X)
Kevin:
Can you give me the latest info on G Windows?
Keith
There is 1 Reply.

#: 12704 S12/OS9/68000 (OSK)
    26-Oct-91  12:56:35
Sb: #12701-#G Windows
Fm: Kevin Darling 76703,4227
To: Keith H. March 70541,1413 (X)
Keith - info on G-Windows?  What do you need to know?  Ed Gresick can probably
tell you anything you wish... he had it running on his System IV at the fest.
Looked pretty neat!
kev
There is 1 Reply.

#: 12715 S12/OS9/68000 (OSK)
    27-Oct-91  10:15:29
Sb: #12704-G Windows
Fm: Steve Wegert 76703,4255
To: Kevin Darling 76703,4227 (X)
Kev,
I, for one, would also like to hear about some of the accomplishments of the
two other OSK box distributors. Far and away, Paul has posted more information
regarding the MM/1 than have Ed or Frank relative to their boxes.
Give 'em a nudge if you 'see' them!
Steve

#: 12762 S12/OS9/68000 (OSK)
    29-Oct-91  12:40:15
Sb: Kwindows for the TC70
Fm: Jim Sutemeier 70673,1754
To: Kevin Darling
Kevin.... Frank Hogg has indicated that KWindows can be purchased for the TC70.
He said you could advise of the cost of KWindows for the TC70.
Please advise me either here, or email, about the cost of these windows.
(Please read my private mail to you regarding this....)
Thanks.
jim Sutemeier
Press <CR> !>

#: 12797 S12/OS9/68000 (OSK)
    01-Nov-91  19:27:00
Sb: #Termcap and Basic
Fm: Bob van der Poel 76510,2203
To: all
Has any thought been given to termcap usage with Basic programs? I can see lots
of new OSK folks writing neat little things with Basic and, because there is no
termcap for Basic, ending up hardcoding display codes--and that would be a real
shame. I've given the subject a fair amount of thought and I really don't see a
easy way to use termcap from Basic (mainly because of a lack of static and
global storage--I could give more on this if there is interest), besides, a lot
of the things people will be doing will involve window codes, etc. which
termcap doesn't support. So, as an alternative, I suggest that standard
interfaces be set up. Each one of these would be written for a specific
terminal, but they would all expect the same params (and they'd be Basic
procedures, even though they need not be written in Basic). For K-windows we
might have a module called "basic_kcurses", for vt100 "basic_vtcurses", etc.
Before doing any terminal output the program could decide which interface to
use (perhaps from the TERM shell variable) and then pass this name around to
the routines which need it. To set the cursor you'd do something like "RUN
GFXPROC(path,"gotoxy",x,y)". GFXPROC would be a variable which could be
"basic_kcurses" or whatever. This is just a suggestion! But we better get
together and set some "standards". Also, I'd appreciate it if someone would
start similar threads on other services--that way everyone will have a change
to become involved.
There is 1 Reply.

#: 12801 S12/OS9/68000 (OSK)
    01-Nov-91  20:36:30
Sb: #12797-Termcap and Basic
Fm: Kevin Darling 76703,4227
To: Bob van der Poel 76510,2203
Actually, you've mentioned previously the possibility of allocating memory on
the fly.  This seems like the best bet to me.
The first thing the program would run each time would be RUN TERMCAP("Init")
oops I mean RUN Termcap("Init",ADDR(storage))... <grin>.  Then each call would
also pass the same storage pointer.
The neat thing is, a program could actually talk to several different types of
terminals at once (!) by simply calling the Init routine with different storage
parms.
The other calls would be normal.. RUN Termcap("InsertLine",ADDR(storage)) and
so on.
BTW, it turns out that Basic/68K does pass the environment onto subprograms, so
one way to get env vars would be to fork a printenv process that was piped back
in for reading.

#: 12799 S12/OS9/68000 (OSK)
    01-Nov-91  20:02:40
Sb: #TOPS programs
Fm: Jim Sutemeier 70673,1754
To: all
Does anyone know how the mmon, watch and logon commands work from the TOPS
archives??
In an attempt to get away from MW's tsmon, (kinda 'hinckey'), I have tried
using "mmon /t1&", "mmon -options /t1&" and all the different combinations that
I could think of.
The result was that a procs of the system would show that mmon was NOT active.
So, I tried 'watch'.....at least that stayed active....but wouldn't respond to
a call in.
logon, of course, according to the help file, is supposed to be called from
mmon (if I can ever get it to recognize /t1)
Anyone out there have any luck with these modules??
Thanks
jim Sutemeier
There is 1 Reply.

#: 12808 S12/OS9/68000 (OSK)
    02-Nov-91  10:13:02
Sb: #12799-TOPS programs
Fm: Steve Wegert 76703,4255
To: Jim Sutemeier 70673,1754
Jim,
Is there a 'line' option in mmon? Kind like the changes Mark just put into
Sterm where you must specify the modem line you want with an '-l' option (Sterm
-l /t5).
Just a thought .... I have absolutely no idea what I'm talking about!  :-)
BTW ... an update on the PROCS output issue we were taling about a few days
ago. Seems as if reseting the clock corrected the problem for a short period of
time only ...  after a couple of days of uninterupted running, we're back to
the same ol' stuff.
Did Frank ever get back to you over on Delphi about this?
Steve

#: 12803 S12/OS9/68000 (OSK)
    01-Nov-91  20:56:00
Sb: #MM/1 AND NY ZOOM MODEM
Fm: Keith H. March 70541,1413
To: Kevin Darling
Kevin:
Hi, I found out that it works (my modem with sterm on the MM/1)
If when I type in the date I press the SHIFT 8 and DO NOT get the * then the
modem will not echo back to the screen.
The keyboard does not get iniz right some times.
Keith
There is 1 Reply.

#: 12805 S12/OS9/68000 (OSK)
    02-Nov-91  05:21:27
Sb: #12803-MM/1 AND NY ZOOM MODEM
Fm: Kevin Darling 76703,4227
To: Keith H. March 70541,1413
Keith,
Wow.  That's weird!  (Halloween sounds in background)
Hmm.  If you have a VOM, you might check the power lines and what the t0 lines
are like on each power-up situation.  Just a thought.
thx for the update!

#: 12816 S12/OS9/68000 (OSK)
    02-Nov-91  18:07:50
Sb: #12805-#MM/1 AND NY ZOOM MODEM
Fm: Keith H. March 70541,1413
To: Kevin Darling 76703,4227 (X)
Kevin:
That is not all the problem, sometimes even if the keyboard get iniz right, it
still does it. As I'm typing this it is working fine, but more than likely the
next time I try to use this STERM it won't work. I don't know about this
computer!
It sound like it is in the software, Am I correct? Or is it the MM/1?
Keith
There are 2 Replies.

#: 12823 S12/OS9/68000 (OSK)
    03-Nov-91  00:13:41
Sb: #12816-#MM/1 AND NY ZOOM MODEM
Fm: Kevin Darling 76703,4227
To: Keith H. March 70541,1413 (X)
Keith, perhaps it's more what we were talking about the other night... that one
control line still isn't tied where it needs to be on the 9-25pin adapter. And
sometimes it floats?  No, that can't be it.  Sigh.  Remember, I'm not a serial
person <grin>.
Better to ask everyone else:  what should a 9-25pin modem adapter look like for
the MM/1 /t0 port?  Guys?
There is 1 Reply.

#: 12830 S12/OS9/68000 (OSK)
    03-Nov-91  07:31:27
Sb: #12823-MM/1 AND NY ZOOM MODEM
Fm: James Jones 76257,562
To: Kevin Darling 76703,4227
I just bought a generic PClone DB-9 to DB-25 cable, and it seems to work fine
on my MM/1 hooked to /t0.

#: 12841 S12/OS9/68000 (OSK)
    03-Nov-91  11:59:36
Sb: #12816-MM/1 AND NY ZOOM MODEM
Fm: John R. Wainwright 72517,676
To: Keith H. March 70541,1413 (X)
Keith,
I'm not sure I understand the problem you are having, but if it is a "lockup"
type condition right after you "CONNECT", read on.
When logging on to CIS  or TYMNET, something in the first few characters that
come in are causing my term to lockup on the MM/1. This happens with every
terminal program I have tried (COM, KERMIT, STERM,  and now TASCOM - the MM/1
version of OSTERM).  In conversations with a couple other MM/1 owners I have
heard the same problem hits them.  IMS is aware of the problem - new drivers
are supposed to fix it  soon.
Meanwhile, here's what works:
Lock the DTR on in your modem (either by setting the proper DIP switch, or the
AT&D command if it will take it).
After connection is made, EXIT the com program and restart it.
This seems to put the driver back  together (to explain exactly what is going
wrong, and why this fixes it, you need somebody smarter than me).
Give it a try.
John Wainwright

#: 12817 S12/OS9/68000 (OSK)
    02-Nov-91  18:19:09
Sb: Problems with my MM/1
Fm: Keith H. March 70541,1413
To: WAYNE DAY 76703,376
Wayne:
I have a problem with my MM/1:
Problem # 1:
 Sometimes when I power up, if I do a SHIFT 8 I'll not get a '*' What causes
this problem?
Problem # 2:
 NOTE TO THE FIRST PROBLEM: The SHIFT KEY does not seam to work at all.
 When I iniz /r0 <-- This is OK
 Then load STERM VER. 1.5 OK  so far.
When I am in STERM, if I issue a AT Command to the modem it will send a OK back
sometimes, but most of the time it will not (the modem is takeing the commands
though) What cause it to NOT echo the chars. back to the screen (I have the
same setup all the time)
The modem works fine with WIZPRO on the COCO 3 512K
I can issue a ATDS=0  (0=cis number) It will log onto CIS BUT I WILL NOT
receive a char(s) back from the CIS computers,  WHY?
Keith
Please HELP!

#: 12819 S12/OS9/68000 (OSK)
    02-Nov-91  19:37:37
Sb: #12801-Termcap and Basic
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)
re >>> RUN Termcap("Init",ADDR(storage))...
Yes, that will work. The only problem with this is that you'd have to pass
'storage' around to all your submodules. But, no matter what we do, I guess
something like that would have to be done. Too bad about no globals in Basic.
I think I'll take a break from some other stuff and play with this termcap
thing--I've spent too much time thinking about and not enough coding! I'm not
even sure why I'm even worried about it since I do so little programming in
Basic <grin>!

#: 12848 S12/OS9/68000 (OSK)
    03-Nov-91  17:43:16
Sb: #12801-Termcap and Basic
Fm: Bob van der Poel 76510,2203
To: Kevin Darling 76703,4227 (X)
Thinking some more (big trouble!!) about the termcap/basic thingie... I think
that what I was alluding to in my 1st message was that we should avoid termcap
and use something like the coco GFX2 interface. It'd just be a matter of using
different interfaces for different setups--and so long as all the interfaces
had the same calling setup and programmers agreed to determine the interface to
use from the system instead of hardcoding then everything should be sweet.
Don't know, but are you doing a GFX2 thing for the MM/1?

#: 12854 S12/OS9/68000 (OSK)
    03-Nov-91  20:58:34
Sb: #12797-Termcap and Basic
Fm: BRUCE MOORE 70075,143
To: Bob van der Poel 76510,2203 (X)
I wrote a basic09 prog in level2 that calls a seperate basic program to
 clear the screen or to home the cursor that takes a parameter so it knows what
terminal it is on RUN clearscreen(termcode) I do not understand termcap but if
it will eliminate this extra work I am
 interested.

#: 12852 S12/OS9/68000 (OSK)
    03-Nov-91  20:54:31
Sb: #12762-#Kwindows for the TC70
Fm: BRUCE MOORE 70075,143
To: Jim Sutemeier 70673,1754 (X)
 Yeah me too! Can I get kd windows for the tc70?  How much?  Is it the same as
 what the mm/1 will have?  How does it compare to g-windows? Are there other
 options?
There is 1 Reply.

#: 12860 S12/OS9/68000 (OSK)
    03-Nov-91  22:29:40
Sb: #12852-#Kwindows for the TC70
Fm: Jim Sutemeier 70673,1754
To: BRUCE MOORE 70075,143 (X)
I've left Kevin Darling a mail message about procuring KWindows for the TC70,
he responded back that he'll have to get back with me.
KWindows, from everything I've been told, is very close to the windows that we
have in the OS9/6809/CoCo windows.
GWindows is much more like a MAC set of windows....I've just gotten a test
version of GWindows, and the Desktop is phenominal.....so close to a MAC's
look, and feel, that it's spooky  (g).
Microware, I understand, is supposed to be working on an XWindow format for
OS9...but I don't know the details of that environment at all.
At least, for now, GWindows, and KWindows, is what we have for OS9/68K.
Of course, that's twice as many options as we had for the CoCo......
jim Sutemeier
There is 1 Reply.

#: 12864 S12/OS9/68000 (OSK)
    03-Nov-91  22:55:41
Sb: #12860-Kwindows for the TC70
Fm: Kevin Darling 76703,4227
To: Jim Sutemeier 70673,1754 (X)
Yah, all we really need is for someone to write a standard library set which'll
work on any system.  There's something called stdwindows which might fit... its
calls have been ported to X, Mac, ST and MGR, I think.  Add in G/KWindows and
we'd be cooking with gas.  Just relink a program.
PS: hang tight.  Overlapping windows using the L-II upgrade technology (which
includes moving from screen to screen) has been going in all this week. Should
be done soon (KWindows).  Mike H and I are making sure it all works out.  So
far it's been pretty neat to see Tetrix running in any size window... and it
doesn't even know! :-)
kev

#: 12858 S12/OS9/68000 (OSK)
    03-Nov-91  21:37:12
Sb: #12799-#TOPS programs
Fm: DENIS CHARTRAND 72561,2714
To: Jim Sutemeier 70673,1754 (X)
    I'm not 100% sure, but if I remember you have to use the "sh" shell from
the TOPS package if you want mmon and other related utilities to work
correctly. They don't work properly with stock Microware "shell" interpreter.
   By the way, you have more success with aterm/xterm usage??
   BYE, from Denis.
There is 1 Reply.

#: 12861 S12/OS9/68000 (OSK)
    03-Nov-91  22:31:54
Sb: #12858-#TOPS programs
Fm: Jim Sutemeier 70673,1754
To: DENIS CHARTRAND 72561,2714
Hiya, Denis....never thought of the 'sh' shell.....will have to try it out and
see if that is the problem.....
aterm/xterm.....sorry, but xterm still crashes in my system (won't even give me
a help screen...)....aterm is not correct as the Aterm.Ctl file is looking at a
VT52 environment, and I don't know what this TC70 emulates, or what codes to
change the ctl file to.....
jim Sutemeier
There is 1 Reply.

#: 12867 S12/OS9/68000 (OSK)
    04-Nov-91  04:44:18
Sb: #12861-#TOPS programs
Fm: Ed Gresick 76576,3312
To: Jim Sutemeier 70673,1754 (X)
 Jim,
 LOGON will work with MW shell, csh and sh.  (I use csh most of the time.)
 Read the docs on logon.  You need a 'sysinfo' file in your systems
 directory as well as a couple of other files.  I forgotten what's all
 required.
 In your startup file, you'll need a line like -
 '/h0/ETC/CMDS/setup /h0/SYS/sysinfo'  assuming you've installed the
 stuff as TOP provided it.
 Works fine on my system (SYSTEM IV) - I use it all the time.
 One caveat - if you ever go to a 030, it won't work - something to do
 with the memory security module.  Not having the source, don't really
 know what the problem is.
 Ed Gresick - DELMAR CO
There is 1 Reply.

#: 12872 S12/OS9/68000 (OSK)
    04-Nov-91  10:15:40
Sb: #12867-TOPS programs
Fm: Jim Sutemeier 70673,1754
To: Ed Gresick 76576,3312 (X)
Thanks, Ed....will check this information out, and (hopefully) get it working
correctly.
I FINALLY DID get mmon to set the TR light on my modem 'on', by doing a mmon
<>>>/t1&, but then mmon disappeared again.
I also got watch to do it, too, using the same algorithym.....
But, ever though the modem answered, nada.....
Thanks again, for your assistance.
jim Sutemeier

#: 12862 S12/OS9/68000 (OSK)
    03-Nov-91  22:42:05
Sb: #12830-#MM/1 AND NY ZOOM MODEM
Fm: Kevin Darling 76703,4227
To: James Jones 76257,562 (X)
Actually, come to think of it I used to use my t0 with a generic mouse 9-25 pin
connector.  Unfortunately the adapter doesn't fit along with my 9-pin video
cable.  So I should try a regular cable (9-25) instead.
Hmmm. thx - kev
There is 1 Reply.

#: 12868 S12/OS9/68000 (OSK)
    04-Nov-91  08:21:23
Sb: #12862-MM/1 AND NY ZOOM MODEM
Fm: James Jones 76257,562
To: Kevin Darling 76703,4227 (X)
Yup, those connectors *are* pretty close together!  The 135 connector and the
one for /t0 are very well acquainted... :-)

#: 12910 S12/OS9/68000 (OSK)
    05-Nov-91  20:39:49
Sb: #12817-Problems with my MM/1
Fm: Wayne Day 76703,376
To: Keith H. March 70541,1413
Keith,
Since I don't have an MM/1, I've forwarded your message to "All" in the hopes
that someone else might be able to help you out.
Wayne
Press <CR> !>

#: 12915 S12/OS9/68000 (OSK)
    06-Nov-91  07:12:40
Sb: MM/1
Fm: Mark Wuest 74030,332
To: Paul K. Ward 73477,2004
Can you send me info on your MM/1?
 Details of specific interest are:
 Bundled software
 ANSI C availability
 C++ availabilty (future?)
 Disk cache availability (speeds up compiles)
 GUI standards/features
 Thanks!
 Mark Wuest
 44 S. Main St  Apt 3G
 Lodi, NJ  07644
 (201) 473-0651

#: 12929 S12/OS9/68000 (OSK)
    07-Nov-91  17:02:52
Sb: #Module directory
Fm: Bob van der Poel 76510,2203
To: All
Does anyone happen to know the format of the data returned by the F$GModDr
system call? The manual is of not too much help here--it just states that a
number of bytes are copied...
It appears that each entry is 32 bytes long. Bytes 0-3 are a pointer to the
module and 12-13 could be the link count of the module.
There is 1 Reply.

#: 12934 S12/OS9/68000 (OSK)
    07-Nov-91  23:01:31
Sb: #12929-Module directory
Fm: Roy Dacus 70721,1113
To: Bob van der Poel 76510,2203 (X)
Hi Bob, I think it is in DEFS/module.a.
I hope this is what your looking for:
********************************
* Module Directory Entry Definitions
ModDir: equ 1<<8 module directory format revision (for D_Cigar)
 org 0
MD$MPtr:do.l 1 module ptr
MD$Group:do.l 1 module group ptr
MD$Static:do.l 1 module group memory size
MD$Link:do.w 1 module link count
MD$MChk:do.w 1 module header checksum
MD$ESize: equ . module directory entry size
 ends
 opt l

#: 12942 S12/OS9/68000 (OSK)
    08-Nov-91  21:17:17
Sb: #12934-#Module directory
Fm: Bob van der Poel 76510,2203
To: Roy Dacus 70721,1113 (X)
Thanks Roy. I knew it should be somewhere on the disks or in the docs, but
darned if I could find it... The only info I _really_ needed was the module ptr
so that I could do my own "mdir" stuff, but I was curious about the other
fields. Now, I even more curiouser -- just what does the "module group ptr"
point to and what is the "module group memory size?". Just looking at some of
my output, it must have something to do with memory allocation, since my ROM
modules have different ptrs that the ones loaded into RAM.
There are 2 Replies.

#: 12943 S12/OS9/68000 (OSK)
    08-Nov-91  21:33:05
Sb: #12942-Module directory
Fm: James Jones 76257,562
To: Bob van der Poel 76510,2203 (X)
I expect the module group pointer has something to do with modules that are
loaded as a group, i.e. several from a single file.  (I hasten to add that I'm
guessing.)

#: 12948 S12/OS9/68000 (OSK)
    08-Nov-91  23:58:47
Sb: #12942-Module directory
Fm: Roy Dacus 70721,1113
To: Bob van der Poel 76510,2203 (X)
I think James is right.  It was inherited from OS9 Level II.  To quote
my very old OS9 user's manual.
"On Level Two systems, two or more modules loaded from the same file comprise
a "group", and are always assigned contiguous memory locations, and are
treated somewhat collectively."
Too bad they don't talk about it in the OSK manual.

#: 12944 S12/OS9/68000 (OSK)
    08-Nov-91  23:03:39
Sb: #12861-#TOPS programs
Fm: Bob Palmer 74646,2156
To: Jim Sutemeier 70673,1754 (X)
Jim - I am able to run ATERM from a terminal but not from the VT70 on my TC70. 
Thee is some strangeness about the way the two handle keyboard input buffering.
To use Aterm I just renamed the device driver appropriately.  On the VT70 it
gives a menu but crashes after the on line message.  From the serial port via a
Zenith terminal all is well. Mind you I still love Sterm and RZ/sz for smooth
operation.  Aterm does work with shell call too and it has got auti dialing.  I
do not know what to say about the terminal emulation values. - you do have a
TERMCAP entry for your VT70 yes? (aterm crashes if you have not done a setenv) 
Use the values from there
 if you must but they hav no effect on my terminal.
There is 1 Reply.

#: 12958 S12/OS9/68000 (OSK)
    09-Nov-91  20:25:29
Sb: #12944-TOPS programs
Fm: Jim Sutemeier 70673,1754
To: Bob Palmer 74646,2156
"aterm crashes if you have not done a setenv".....
Which environment must be set??   seems like I set TERM to vt70, but is there
possibly another to set?
jim Sutemeier

#: 12970 S12/OS9/68000 (OSK)
    10-Nov-91  12:04:31
Sb: #C++ Compiler sought
Fm: Robert Heller 71450,3432
To: anyone
I am looking for C++ for OS-9/68K.  Is such a beast available?
Robert
There is 1 Reply.

#: 13005 S12/OS9/68000 (OSK)
    12-Nov-91  07:16:30
Sb: #12970-C++ Compiler sought
Fm: Mark Wuest 74030,332
To: Robert Heller 71450,3432
Robert,
 There is nothing "real" out there at all. Did you get the questionaire from MW
where they wanted to know what items were of importance to you? C++ was one of
the choices, indicating that they might do it if interest were high enough.
Another possibility I had considered was just running cfront on another machine
and seeing how easy it was to get the resulting C code to compile on my OSK
box. Never did it - I'm back in the Unix world for now...
 Mark

#: 12979 S12/OS9/68000 (OSK)
    11-Nov-91  00:21:07
Sb: #It's working!
Fm: Jim Peasley 72726,1153
To: Mark Griffith 76070,41 (X)
Mark;
  Please pass this info on to Paul, as I have an unusually hard time contacting
him.
  I have replaced the pallette controller chip on my board and the system is
now operational.  What I found to be the cause of the trouble is that the
aluminum standoff nearest the keyboard connector had worn thru the trace that
runs _very_ close by the mounting hole and was grounding the whole board.  I
used some liquid PVC to re-insulate the trace and also used some nylon spacers
to get the board off the standoffs.
  The original power supply is now powering the setup after I replaced the
original defective fan.  The replacement PS will not switch in without a HD
connected, as the power draw of the single board is just too low.
   There is only one more problem to solve and I'm not quite sure yet what's
happening... drive /d1 now gives 247 seek errors when trying to access that
drive.  It'll do a 'dir' OK, but accessing any file or subdirectory on the disk
results in the 247 seek error.  If I copy a new file over to the disk, it'll
read that OK, but not any of the data created previously. Also, trying to
format a disk in /d1 results in a 246 error.
  In your opinion, do you think that my 'short' could have fried the drive
electronics in a way to give the above errors??
  Thanks,
      ...Jim
There is 1 Reply.

#: 12988 S12/OS9/68000 (OSK)
    11-Nov-91  07:09:46
Sb: #12979-It's working!
Fm: Kevin Darling 76703,4227
To: Jim Peasley 72726,1153 (X)
What kind of dmode is set up on your /d1?  What kind of diskettes are you
formatting?  (Highdensity?  Normal?)  etc.
How big a file goes over okay?  Does copying another one mess things up? Sounds
kinda like no side select, or something.
I've met one other person whose board wouldn't work without spacers... I
thought they were supplied with the kit tho (nylon spacers)(?).
cheers - kev

#: 13015 S12/OS9/68000 (OSK)
    13-Nov-91  00:38:40
Sb: #12970-C++ Compiler sought
Fm: Mike Haaland 72300,1433
To: Robert Heller 71450,3432
Yessir!  You can get GNU C++ from hermit.cs.wisc.edu via the internet link in
email.  I just grabbed it and haven't had time to play with it yet. It was
ported by Stephan Paschedag in Switzerland.
Send a one line message to ftp@hermit.sc.wisc.edu saying:
 help
And you'll get a file back telling you how to use the new file server. The full
address from CISMail is:
 >INTERNET: ftp@hermit.cs.wisc.edu
Mike

#: 13026 S12/OS9/68000 (OSK)
    13-Nov-91  08:05:17
Sb: #12988-It's working!
Fm: Jim Peasley 72726,1153
To: Kevin Darling 76703,4227 (X)
Kev;
  First thing I did after getting the MM/1 was to purchase another 3.5" drive -
almost an identical twin to /d0 - for moving files around. I HATE swapping
floppies!!!  I backed up all the distribution disks to brand new 2.0 M disks
and was using them until the MM/1 blew up - well, more like a loud POP,
actually.
  Now, I can only read one out of the 8 or so disks that I have data on. It's
beginning to look like the stepper in the drive took a dump, as it doesn't want
to read much past sector 0.  I will play around with it some more and get back
with detailed errata.  What's got me worried is that 'format' won't work on
this drive - it gets almost done and then errors out with a '246' (I think)
seek error.
  re: nylon spacers
  Yep, the kit has some in there, but using them with the aluminum standoffs
puts the board about 1/16" too high for the rear connectors - and also there's
nothing in the installation docs about using them. Lesson learned the hard way!
  ...Jim

#: 13035 S12/OS9/68000 (OSK)
    13-Nov-91  21:02:34
Sb: FAX SOFTWARE?
Fm: Keith H. March 70541,1413
To: ALL
Who is working on a software package (fax send/receive software) for use on the
OSK Machines?
Keith
Press <CR> !>

#: 13037 S12/OS9/68000 (OSK)
    13-Nov-91  21:58:42
Sb: #13035-FAX SOFTWARE?
Fm: James Jones 76257,562
To: Keith H. March 70541,1413 (X)
I think that's Brent (Bret?) Wynkoop who's doing that.

#: 13060 S12/OS9/68000 (OSK)
    15-Nov-91  16:30:04
Sb: #13037-#FAX SOFTWARE?
Fm: Keith H. March 70541,1413
To: James Jones 76257,562 (X)
James:
Do you know his phone number?
You was close his name is BRETT WYNKOOP
Also did you see the new RAINBOW 12-91 ISSUE
review of the MM/1
ALL I need is the i/o board.
Keith
There is 1 Reply.

#: 13066 S12/OS9/68000 (OSK)
    15-Nov-91  23:33:16
Sb: #13060-FAX SOFTWARE?
Fm: James Jones 76257,562
To: Keith H. March 70541,1413 (X)
I got the December RAINBOW day before yesterday.  Nice cover photo! Alas, I
don't know his phone number.

#: 13070 S12/OS9/68000 (OSK)
    16-Nov-91  12:20:22
Sb: FAX SOFTWARE HELP
Fm: Keith H. March 70541,1413
To: All
Does anyone know BRETT WYNKOOP PHONE #?
He sells the OSK program called SENDFAX!
THANKS Keith

#: 13078 S12/OS9/68000 (OSK)
    16-Nov-91  20:16:44
Sb: spreadsheet
Fm: Bob van der Poel 76510,2203
To: all
I understand that someone ported a PD version of a Unix spreadsheet over to OSK
(Ken Scales, if memory serves). Does anyone know if he has finished it, and if
it is available for downloading?

#: 13084 S12/OS9/68000 (OSK)
    17-Nov-91  08:13:14
Sb: #13015-C++ Compiler sought
Fm: Robert Heller 71450,3432
To: Mike Haaland 72300,1433 (X)
Mike:
   I got an answer from another source (BIX) and FTP'ed gcc/g++  from wisc.
Haven't installed it yet (probably this afternoon).
                Robert

#: 13101 S12/OS9/68000 (OSK)
    18-Nov-91  09:27:53
Sb: #C programming (fopen)
Fm: Jim Sutemeier 70673,1754
To: all
I've asked a couple of C programmers out here in L.A., and neither of them have
ever used the directory read from fopen .....
e.g.:  fp=fopen("/dd/com", "d");
If anyone here has used this action, I've a couple of questions.
1) How would you read in the files within the directory, as chars into memory,
then manipulate??
2) How do I test for end of directory?? a NULL or what??
Any other info about this option would be helpful.....never have used it, and
apparently many programmers haven't either.
Thanks
jim Sutemeier
There are 3 Replies.

#: 13102 S12/OS9/68000 (OSK)
    18-Nov-91  19:53:41
Sb: #13101-#C programming (fopen)
Fm: Bruce MacKenzie 71725,376
To: Jim Sutemeier 70673,1754 (X)
Jim,
 You read from the directory as you would from any other file.  Under OS9 (I
can't speak for OSK--check your docs) each directory entry consists of a 29
byte name field followed by a 3 byte logical sector number for the file
descriptor sector.  The microware OS9 C compiler defines a structure in
direct.h to help access the directory:
 struct dirent{
      char dir_name[29];
      char dir_addr[3];
 }
 So all one need do is define a structure of this type and read the directory
entries into it:
 struct dirent dat;
 in=fopen("/dd","d");
 while(fread(&dat,sizeof(dat),1,in)!=0){
 .
 .
 .
 If the entry is unused the first byte of the filename is set to zero.  The
last byte of the filename has its MSB set so you have to clear this bit and set
the next byte to zero to make it a proper C string.  At the end of the
directory fread() returns 0 for EOF.
There is 1 Reply.

#: 13107 S12/OS9/68000 (OSK)
    18-Nov-91  21:36:49
Sb: #13102-C programming (fopen)
Fm: Jim Sutemeier 70673,1754
To: Bruce MacKenzie 71725,376 (X)
Wow....thanks for all the great information.....appreciate all your help!!
jim

#: 13108 S12/OS9/68000 (OSK)
    18-Nov-91  22:22:54
Sb: #13101-C programming (fopen)
Fm: James Jones 76257,562
To: Jim Sutemeier 70673,1754 (X)
You will want to read entries into structures that contain names and LSNs.  I
wouldn't be surprised, though, if the Kreider library has the BSDoid routines
opendir(), readdir(), and the like, that make scanning through directories much
easier.  Check it out.

#: 13110 S12/OS9/68000 (OSK)
    19-Nov-91  01:38:10
Sb: #13101-C programming (fopen)
Fm: Bob Taylor 73270,3124
To: Jim Sutemeier 70673,1754 (X)
Jim,
Microware's C manual has the following functions:
     opendir, closedir, readdir, rewinddir, seekdir and telldir
What is conviently missing is writedir! Rename would be nice.
Bob

#: 13105 S12/OS9/68000 (OSK)
    18-Nov-91  20:51:21
Sb: #12841-#MM/1 AND NY ZOOM MODEM
Fm: Bill Dickhaus 70325,523
To: John R. Wainwright 72517,676 (X)
Interesting, I don't have that problem connecting to CIS, but I DO have that
problem when connecting to Delphi. Do you use a CIS node, or Tymnet? I connect
to Delphi using Tymnet (when I use SprintNet instead, I don't have a problem).
I suspect that the problem is caused by the fact that Tymnet sends its initial
message at 1200 baud (thus the string of odd characters, and lots of 'x's).
This generates a framing error, and I'm wondering if the serial driver on the
MM/1 is handling this error properly (could also be some idiosyncrasy of the
built in serial port on the 68070).
Bill
There is 1 Reply.

#: 13129 S12/OS9/68000 (OSK)
    20-Nov-91  18:10:07
Sb: #13105-MM/1 AND NY ZOOM MODEM
Fm: John R. Wainwright 72517,676
To: Bill Dickhaus 70325,523
It is a problem in the driver, I understand they are working on it. I can CAUSE
the lockup by sending to my MM/1 via cable from another computer - the first
character at 300 baud, when the MM/1 is expecting 2400, and ZONK.  I was told
by Mark G. that new drivers would fix it.
JohnW

#: 13118 S12/OS9/68000 (OSK)
    19-Nov-91  22:00:32
Sb: #12958-TOPS programs
Fm: Bob Palmer 74646,2156
To: Jim Sutemeier 70673,1754 (X)
It was indeed TERM which needs to be defined.  On my TC70 (currently bad order
but repair underway) if I try to run ATERM with TERM defined as VT70 I get the
signon screen, the on linbe message and hang unable to properly talk to the
modem.  If on the other hand I use TERM set to my terminal (a Zenith Z19)
through /term all runs properly. I do not think that any other setup would be
required.
Bob

#: 13132 S12/OS9/68000 (OSK)
    20-Nov-91  20:55:16
Sb: new makdir
Fm: Bob van der Poel 76510,2203
To: all
I have just uploaded a replacement for MAKDIR. This version duplicates the MW
version, with the added features of being able specify the initial allocation
size and converting the names to uppercase. The archive contains source, binary
and docs. Look for makdir.ar in lib 12.
Press <CR> !>GO RATES for current information

#: 13136 S12/OS9/68000 (OSK)
    21-Nov-91  00:51:26
Sb: #13132-#new makdir
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Hmm - Bob, did you happen to come across my 'mkdir' from ages past? Allowed
preallocation, as well as a number of other features. 6809 .ar file, but the
source should have been portable.
Pete
There are 2 Replies.

#: 13138 S12/OS9/68000 (OSK)
    21-Nov-91  07:22:35
Sb: #13136-#new makdir
Fm: Carl Kreider 71076,76
To: Pete Lyall 76703,4230 (X)
Portable enough that I have been using it on the 680x0s for 5 years.
There is 1 Reply.

#: 13139 S12/OS9/68000 (OSK)
    21-Nov-91  07:29:19
Sb: #13138-#new makdir
Fm: Pete Lyall 76703,4230
To: Carl Kreider 71076,76 (X)
Heeeeyyyyy Carl! Long time, buddy!
Two more classes and I'll have caught up with you... well, on paper anyway.
When's your long overdue California expedition going to happen? Come on out and
get musically infected again.... I'm picking up my Mesa Boogie MKIV half stack
next week (serious grin)....
Pete
There is 1 Reply.

#: 13157 S12/OS9/68000 (OSK)
    22-Nov-91  19:22:23
Sb: #13139-#new makdir
Fm: Carl Kreider 71076,76
To: Pete Lyall 76703,4230 (X)
Yeah, I know.  It is easier to talk expeditions than do them with 9 year olds
and ... well, you know.  One of these days.  Debi will make sure it happens! 
So you must be making more money, buying all this electronic music stuff ;).
Congrats on school.  That is great.  I feel better, but didn't get a new job or
more money or anything.
Carl
There is 1 Reply.

#: 13164 S12/OS9/68000 (OSK)
    23-Nov-91  11:30:48
Sb: #13157-new makdir
Fm: Pete Lyall 76703,4230
To: Carl Kreider 71076,76
Money? Naa.. as always, you sell this (at a loss) to buy that. You just give up
eating for a bit to make up the difference (grin). Went down to Hollyweird
yesterday to audition amps in the 'guitar ghetto'..ugh! No wonder people
perceive CA as weird (re: Time magazine's recent issue). I'd hate to be doing
this for a living. 'Course, looking at the studio these days suggests I might
be heading that direction. Confusers just don't pump the adreneline like they
used to.
School.. yeah... it'll be like pulling a splinter out from under my
fingernail.. won't net me much, but I'll be glad it's over. In fact, having
moved to GTE, I'd bet it's been more of an impediment than a bonus. Having to
keep nagging the boss about keeping travel down to bare essentials (for moi)
surely hasn't earned me any gold stars. No biggie.. my current phase of midlife
crisis tells me that what I really want to do when I grow up (ha!) is run off
to chef school, where technology is abandoned for technique. Hmmm.. left brain
must be getting an edge in my golden years. I'll have to call you in the near
future for the annual state of the midwest message... that and to work on your
wife for the CA pilgrimage!
Take care...
Pete

#: 13147 S12/OS9/68000 (OSK)
    21-Nov-91  19:07:09
Sb: #13136-#new makdir
Fm: Bob van der Poel 76510,2203
To: Pete Lyall 76703,4230 (X)
Yes, Pete, I recall the mkdir you did. As I recall you changed the sas field in
the descriptor, did the makdir, then reset it. OSK is much easier as the size
opt is documented both for the actual system call and for the C interface. So
writing the program was real simple. What surprises me is that MW ignored this
option when they wrote their own utility <grin>.
To tell the truth, I really didn't plan on writing this. But then I was just
looking through the C manual and saw the call, so I started wondering... The
important thing to me about the new version is not so much the size thing, but
the fact that it automagically sets the names to all uppercase.
There is 1 Reply.

#: 13150 S12/OS9/68000 (OSK)
    21-Nov-91  22:57:31
Sb: #13147-new makdir
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
Err... mkdir also uppercased all the directory names (grin).
Pete

#: 13141 S12/OS9/68000 (OSK)
    21-Nov-91  16:19:40
Sb: #TERMCAP PROBLEMS / MM/1
Fm: Keith H. March 70541,1413
To: ALL
Hello:
Can anyone help me with my problem with termcap on the MM/1?
When I use dEd or VED some hex numbers or text is displayed from the screen
before with the next screen. The termcap does not clear all the screen before.
This is my termcap entry:
#------------------------------------------------# MM/1 CoCo Emulation entry
(for Darling Windows) #
k2|vsc|Signetics Vsc Video driver:\
        :am:bs:cl=^L:li#26:co#80:ho=^A:\
        :cd=^K:ce=^D:cm=^B%r%+ %+ :pt:\
        :do=^J:up=\E[A:nd=^F:so=\037 :se=\037!:\
        :us=\037":ue=\037#:al=\0370:dl=\0371:\
        :ku=^P:kd=^N:kr=^F:kl=^B:
#------------------------------------------------# MM/1 VT Emulation entry #
k1|vsc1|Signetics Vsc Video driver by RMC:\
        :co#80:li#26:cl=50\E[;H\E[2J:\
        :bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\
        :ce=^D:ho=\E[H:pt:cd=^D:\
        :sc=\E7:rc=\E8:do=\E[B:
#------------------------------------------------# Tandy CoCo 3 with OS9 Level
II and cc3io patched # to make 2 byte screen control codes work. #
c3|coco3|os9LII:\
        :am:bs:cl=^L:li#24:co#80:ho=^A:\
        :cd=^K:ce=^D:cm=^B%r%+ %+ :\
        :do=^J:up=^I:nd=^F:so=\037 :se=\037!:\
        :us=\037":ue=\037#:al=\0370:dl=\0371:\
        :ku=^L:kd=^J:kr=^I:kl=^H:ta:
coco:tc=coco3
What should I change?
Thanks for the help
Keith H. March UUCP: BGSUVAX!KHMARCH!KEITHMARCH
P.S.  ONLY INIZ DISK DESCR'S (ex: /dd) NOT /Tn PORTS
There is 1 Reply.

#: 13149 S12/OS9/68000 (OSK)
    21-Nov-91  22:52:29
Sb: #13141-#TERMCAP PROBLEMS / MM/1
Fm: Pete Lyall 76703,4230
To: Keith H. March 70541,1413 (X)
Keith -
It'd help to know what the numbers were that you were seeing....
Pete
There is 1 Reply.

#: 13153 S12/OS9/68000 (OSK)
    22-Nov-91  16:00:37
Sb: #13149-#TERMCAP PROBLEMS / MM/1
Fm: Keith H. March 70541,1413
To: Pete Lyall 76703,4230 (X)
Pete:
The numbers I am seeing are the hex numbers from the sector that I just
displayed before calling the HELP screen.
Keitht(
There is 1 Reply.

#: 13162 S12/OS9/68000 (OSK)
    23-Nov-91  11:16:39
Sb: #13153-#TERMCAP PROBLEMS / MM/1
Fm: Pete Lyall 76703,4230
To: Keith H. March 70541,1413 (X)
Hmm - that's tougher then. I had hoped that you were seeing a sequence that was
part of one of the TERMCAP entry's commands. That would imply that one of the
commands was incomplete in the entry (like a missing ESC).
If you're seeing characters from the previous display screen, it's possible
that some 'editing' commands are being applied to the screen (like
insert/delete line; erase from top of screen to cursor; etc.) which would leave
part of the display visible, but not necessarily in the same screen location.
Let's approach this methodically... what commands are you using in your
program? Probably at least cursorxy, clrscrn, and erase to end of line? Why not
write a quicky test program that paints screen lines of 'AAAAAAAA's,
'BBBBBBBBBBB's, and so on. Then go to various screen lines, and issue
. er .. issue the commands in question. This should give us some more direction
on which commands are giving you a headache.
Pete
There is 1 Reply.

#: 13167 S12/OS9/68000 (OSK)
    23-Nov-91  16:38:10
Sb: #13162-TERMCAP PROBLEMS / MM/1
Fm: Keith H. March 70541,1413
To: Pete Lyall 76703,4230
Pete;
See message 13141 that is my termcap file!

#: 13156 S12/OS9/68000 (OSK)
    22-Nov-91  18:55:46
Sb: TC70 Termcap/K-Windows
Fm: Frank Hogg of FHL 70310,317
To: Kevin Darling 76703,4227 (X)
Kev,
Could you give me termcap for K-Windows here tonight. I need it to test running
SMART on the TC70. BTW how do you handle the function keys with SMART? It uses
F1 and F2 FOR ITS OWN USE.
Also, don't forget those orders, customers are waiting.
Thanks
Frank Hogg - FHL

#: 13495 S12/OS9/68000 (OSK)
    16-Dec-91  08:54:53
Sb: #13490-OS-9000 comments part 2
Fm: Timothy J. Martin 71541,3611
To: Kevin Darling 76703,4227 (X)
I need to spend a bit more time with OS-9000 before too many more comments.
I've got something else going at the moment, then I'll be back to OS-9000.

#: 13513 S12/OS9/68000 (OSK)
    17-Dec-91  09:44:16
Sb: #13490-OS-9000 comments part 2
Fm: Mike Haaland 72300,1433
To: Kevin Darling 76703,4227 (X)
I got my flyer on 'MShell' today.  Sounds like a very nice improvement for
sure.  But @ $300 a whack, I'm not sure how many they'll sell to us hobbyists.
Who knows.
They even added a batchfile editor into the new shell.  Plus, (Finally), allow
command line editing.  Wonder where they got that idea? <g>  Only took a few
years. ;-)  Also, there is a shell programming language now.  Sounds like a
nice addition to the OS-9 package and sure would come in handy.
Mike

#: 13500 S12/OS9/68000 (OSK)
    16-Dec-91  17:58:10
Sb: MM/1 Windows
Fm: Ernest Withers Jr. 71545,1117
To: Kevin Darling 76703,4227 (X)
Kevin,
I read about the windowing system upgrade for the MM/1 on the IMS BBS. Put my
name on the list for the update.
Thanks, Ernie.

#: 13528 S12/OS9/68000 (OSK)
    17-Dec-91  23:58:24
Sb: #13474-sticky modules
Fm: Jim Peasley 72726,1153
To: Bruce Isted 76625,2273
Bruce;
  Good to see you back!  Long time no see.
>   What CAN cause problems is if memory gets too fragmented, where >sticky
modules with no users are interleaved with modules in use.  Then, >if you want
to run a program that has larger module/data size requirements >than the
largest sticky module(s) in memory, you're out of luck.
  Ouch, does this mean re-boot time?  Having only (only - hah!) 1 Meg. of
memory for now, I've been pretty conscious of how much free mem is left, which
gave me the idea of a cleanup util for the sticky modules.  I think that I've
only run up against the mem limit once, but for a BBS or other 'full time'
setup, it looks as though the fragmented memory could become a problem.
  ...Jim

#: 13555 S12/OS9/68000 (OSK)
    19-Dec-91  19:46:31
Sb: #MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: all
Hi all... I'm looking at a new monitor for my MM/1. Can I use a SVGA type
monitor? It has a DB15 plug. Pinout is: 1. Red. 2. Green. 3. Blue. 4. Ground.
6. Red Rtn. 7. Green Rtn. 8. Blue Rtn. 13. H.Sync. 14. V.Sync.  The rest of the
pins are either tied to ground or not connected. I have pinouts for the CM-8.
If I don't connect the Rtn lines and just match up the rest, will the monitor
work? If so, building an adapter is a snap!
There is 1 Reply.

#: 13567 S12/OS9/68000 (OSK)
    20-Dec-91  05:47:04
Sb: #13555-#MM/1 SVGA Monitor?
Fm: Kevin Darling 76703,4227
To: GLEN HATHAWAY 71446,166 (X)
The monitor should work, if it also can sync to NTSC (about 15Khz) freqs. If
it's only for SVGA cards at 31Khz, then it won't work.
If the above is okay, then the only thing you might have to play with is the H
and V sync polarity... but there are jumpers on the board for that (apologies,
my machine is closed up or I could describle where they are).
There is 1 Reply.

#: 13570 S12/OS9/68000 (OSK)
    20-Dec-91  08:04:23
Sb: #13567-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Kevin Darling 76703,4227 (X)
Hi Kevin... According to monitor manual, no, it won't sync that low. I'll call
their tech guy today and see if he knows any more about it. Would it hurt
anything if I tried it? If I have to return this thing, I don't want it fried!
Oh yeah, do I tie the Rtn lines to ground?
There is 1 Reply.

#: 13579 S12/OS9/68000 (OSK)
    21-Dec-91  00:44:10
Sb: #13570-#MM/1 SVGA Monitor?
Fm: Kevin Darling 76703,4227
To: GLEN HATHAWAY 71446,166 (X)
Glen - yeah, it's not polite to input the wrong freq to a monitor... and could
hurt it after a few seconds.  So I wouldn't even try it.
There are 2 Replies.

#: 13582 S12/OS9/68000 (OSK)
    21-Dec-91  02:56:06
Sb: #13579-MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Kevin Darling 76703,4227 (X)
Hi Kev... OK, thanks for the good advice. Wouldn't want to have to buy two, one
as a boat anchor and one to compute on!

#: 13621 S12/OS9/68000 (OSK)
    22-Dec-91  23:43:58
Sb: #13579-#MM/1 SVGA Monitor?
Fm: Paul Rinear 73757,1413
To: Kevin Darling 76703,4227 (X)
   What type of resolution do you get with an MM/1?
There is 1 Reply.

#: 13623 S12/OS9/68000 (OSK)
    22-Dec-91  23:49:29
Sb: #13621-#MM/1 SVGA Monitor?
Fm: Kevin Darling 76703,4227
To: Paul Rinear 73757,1413 (X)
The VSC chip gives up to 768x480 16-colors, or 384x480 256-colors.  The palette
chip used on the MM/1 allows those colors to be chosen from a 24-bit (16
million) set.  For example, you can have 256 shades of grey.
There is 1 Reply.

#: 13629 S12/OS9/68000 (OSK)
    23-Dec-91  09:25:41
Sb: #13623-#MM/1 SVGA Monitor?
Fm: Paul Rinear 73757,1413
To: Kevin Darling 76703,4227 (X)
    I tried calling 1-800-866-9084 to get some MM/1 info. Didn't get an answer.
Not like I have the money for one or anything; am just curious about exactly
what kind of machine this is.
                                                      Paul
There are 2 Replies.

#: 13636 S12/OS9/68000 (OSK)
    23-Dec-91  20:27:15
Sb: #13629-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Paul Rinear 73757,1413 (X)
Hi Paul... I have one. Ask me anything. I'll give you my opinion or facts if I
know them. So far I like the machine. Lotsa potential that will be realized
when I get my I/O board and hard drive and extra memory in late January. Till
then, I'm kinda limping along with two 1.44 meg floppies. Has lots of neat
goodies built into the hardware, too, like blitting, DMA and DSP of some sort.
There is 1 Reply.

#: 13647 S12/OS9/68000 (OSK)
    24-Dec-91  17:49:22
Sb: #13636-#MM/1 SVGA Monitor?
Fm: Paul Rinear 73757,1413
To: GLEN HATHAWAY 71446,166 (X)
      How fast does it seem compared to other computers you've used. Also, was
it easy to assemble? What have you done with it so far? Can you read MS-DOS
disks? If so, does it do it as fast as a 4.77MHz XT would? (I know it's not an
MSDOS machine- just curious). Ask me anything is a dangerous phrase (grin).
                                               Paul
There is 1 Reply.

#: 13654 S12/OS9/68000 (OSK)
    25-Dec-91  01:51:25
Sb: #13647-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Paul Rinear 73757,1413 (X)
Hi Paul... How fast... Right now, it seems graphic-wise to be just a tad faster
than CoCo3, other than that, I can't say too much. I ran a 30 meg HD on the
CoCo3 and have only floppies so far on the MM/1. Makes it seem slower arrives,
the speed is supposed to pick up substantially. Assembly is just a matter of
plugging things together and running in a few screws. If you've done any drive
installations or mods to your CoCo3 you're in good shape. The instructions
leave a bit to be desired, but I'm sure IMS is working on that. On reading
MS-DOS disks, why would I want to? Never have tried it so I can't comment.
Whether it's as fast as a PC - again, can't comment as I've had no experience
with PC's ever. Well, almost none... From what I hear, it ought to be able to
smoke on a 4.77mhz XT, tho.
There are 2 Replies.

#: 13657 S12/OS9/68000 (OSK)
    25-Dec-91  06:24:45
Sb: #13654-#MM/1 SVGA Monitor?
Fm: Colin J. Smith 73777,1360
To: GLEN HATHAWAY 71446,166 (X)
We should be able to read MS-DOS disks when we get the new drivers on the
update disks.  That would be handy for trading GIF's, etc.
Happy Holidays!
  -Colin
There is 1 Reply.

#: 13663 S12/OS9/68000 (OSK)
    25-Dec-91  12:51:51
Sb: #13657-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Colin J. Smith 73777,1360 (X)
Hi Colin... Does that mean we can write MS-DOS disks too? I have a friend with
a PC. He lives a sheltered life - has no modem and is terrified of viruses.
Would be interesting to get him up to speed on what computing is really about.
All he knows now is pay and play.
There is 1 Reply.

#: 13675 S12/OS9/68000 (OSK)
    25-Dec-91  22:06:37
Sb: #13663-MM/1 SVGA Monitor?
Fm: Colin J. Smith 73777,1360
To: GLEN HATHAWAY 71446,166 (X)
Write?  Yeah, I think so.  I do wish my update disks would arrive, though!
  --Colin

#: 13666 S12/OS9/68000 (OSK)
    25-Dec-91  15:10:03
Sb: #13654-#MM/1 SVGA Monitor?
Fm: Paul Rinear 73757,1413
To: GLEN HATHAWAY 71446,166 (X)
    Was hoping the graphics would be VERY fast compared to a COCO3. This was
one of the weak points of the COCO3. If it's a floppy read picture it's
understandably slow.
                             Paul
There are 3 Replies.

#: 13669 S12/OS9/68000 (OSK)
    25-Dec-91  18:00:04
Sb: #13666-MM/1 SVGA Monitor?
Fm: James Jones 76257,562
To: Paul Rinear 73757,1413 (X)
Well...my experience with gifshow and viewgif is as follows:
viewgif suffers on speed from having to puzzle out how best to make up for the
CoCo 3's lack of color resolution, and then having to draw things twice to let
it toggle between screens.  I modified viewgif to try to speed up the analysis
phase as much as I could.  (I sent the mods back to Vaughn Cato.)
Unfortunately, I didn't save the timings I did, but...one .GIF file that I have
that viewgif took some time, I think something like forty or fifty seconds to
analyze and then perhaps a minute or so to decode and display on the CoCo with
viewgif takes seven seconds to decode and display on my MM/1.  (Viewgif had a
portion of its decoding, if I remember rightly, written in assembly language;
gifshow is all in C.)
That file is about 50K.  It would be pretty scary to run the file I've been
trying out with gifshow on the CoCo...it's 650+K long.

#: 13676 S12/OS9/68000 (OSK)
    25-Dec-91  22:08:56
Sb: #13666-MM/1 SVGA Monitor?
Fm: Colin J. Smith 73777,1360
To: Paul Rinear 73757,1413 (X)
Actually, it is somewhat faster than a COCO3.  And, when you pop in a couple
more megs o' RAM, it gets even faster because the system uses the new RAM and
lets the graphics have the old meg (no sharing).
  --Colin

#: 13689 S12/OS9/68000 (OSK)
    26-Dec-91  02:28:06
Sb: #13666-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Paul Rinear 73757,1413 (X)
Hi Paul... Remember, I expect a speed boost when the I/O board gets here...
There is 1 Reply.

#: 13701 S12/OS9/68000 (OSK)
    26-Dec-91  21:58:48
Sb: #13689-#MM/1 SVGA Monitor?
Fm: Paul Rinear 73757,1413
To: GLEN HATHAWAY 71446,166 (X)
    Hope you get it soon. What's it supposed to have on it? SCSI, etc?
There is 1 Reply.

#: 13718 S12/OS9/68000 (OSK)
    27-Dec-91  23:47:12
Sb: #13701-#MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Paul Rinear 73757,1413 (X)
Hi Paul... For details on the MM/1 hardware, check out the Hot Topics database
here on CI$. Of particular interest is a file called vsc.txt (or something
similar). Tells about the capabilities of the VSC chip. I know the I/O board
has a SCSI port, at least one parallel printer port (maybe 2), a couple more
serial ports, etc. Don't quote me on any of this - I could be wrong. One serial
port on the main board will soon be convertible to a MIDI port. That's one I'm
waiting for!
There is 1 Reply.

#: 13745 S12/OS9/68000 (OSK)
    28-Dec-91  21:15:16
Sb: #13718-#MM/1 SVGA Monitor?
Fm: Colin J. Smith 73777,1360
To: GLEN HATHAWAY 71446,166 (X)
Don't forget the sound I/O and clock!
(I can't wait to get the RTC, I HATE running settime every time I turn on the
machine!)
  --Colin
There is 1 Reply.

#: 13748 S12/OS9/68000 (OSK)
    28-Dec-91  23:58:03
Sb: #13745-MM/1 SVGA Monitor?
Fm: GLEN HATHAWAY 71446,166
To: Colin J. Smith 73777,1360 (X)
Hi Colin... You got it!!! I really miss my RTC! I've uploaded some
quick-anddirty graphic demos here and on Delphi. Watch for em. If you have any,
upload please...

#: 13650 S12/OS9/68000 (OSK)
    25-Dec-91  01:41:46
Sb: #13629-MM/1 SVGA Monitor?
Fm: Kevin Darling 76703,4227
To: Paul Rinear 73757,1413 (X)
Paul - they're probably shut down for Christmas, I'd guess (ie: gone to visit
relatives :-).
Try doing a "sca/sho" in Lib 15... there's various info files on all the new
68K systems people are interested in.
cheers - kev

#: 13583 S12/OS9/68000 (OSK)
    21-Dec-91  03:00:25
Sb: #C on MM/1
Fm: GLEN HATHAWAY 71446,166
To: all
Hi all... I have an MM/1 and no manuals. I'm trying to get anything at all to
compile (in C) on this machine and having no luck at all! I am familiar with
the L2 compiler - wrote lots of stuff with it, in fact, but it seems there were
just enough changes made in the new one that I can't seem to get it to work
without more info. My latest error message is 'no root psect found'. Whazzat?
Huh?
There are 2 Replies.

#: 13585 S12/OS9/68000 (OSK)
    21-Dec-91  04:35:39
Sb: #13583-#C on MM/1
Fm: Kevin Darling 76703,4227
To: GLEN HATHAWAY 71446,166 (X)
Not sure Glen, but L-2 would probably give the same error if there was no
main() function in the code you're compiling.  A "psect" is the assembly
program section (vsect = variable section) which the compiler feeds to the
assembler to change into binary codes.  The root psect should be then (the)
main one I think.  Don't hold me to this tho :-)  Late.
There is 1 Reply.

#: 13594 S12/OS9/68000 (OSK)
    21-Dec-91  19:35:55
Sb: #13585-C on MM/1
Fm: GLEN HATHAWAY 71446,166
To: Kevin Darling 76703,4227 (X)
Hi Kev... I'd have to look to be absolutely sure, but I don't think I'd forget
to put a main() in. That's one of the first things you learn. I'm trying to use
cgfx.l. Maybe it's make that's changed... I'll have to experiment some more
tonight...

#: 13588 S12/OS9/68000 (OSK)
    21-Dec-91  07:44:34
Sb: #13583-#C on MM/1
Fm: James Jones 76257,562
To: GLEN HATHAWAY 71446,166 (X)
The root psect, for most practical purposes, is the one that's in the file
cstart.r.  If you have the right stuff in your library directory, it should be
able to find it.
Try adding the -bp option, so that you can see the effects of the options you
are using.  Of particular interest will be the line starting "l68".
There is 1 Reply.

#: 13595 S12/OS9/68000 (OSK)
    21-Dec-91  19:38:33
Sb: #13588-C on MM/1
Fm: GLEN HATHAWAY 71446,166
To: James Jones 76257,562 (X)
Hi James... I'll have to be sure I've got all the defs and libs set up right. I
thought I had, but maybe not... I'll let ya know what happens.

#: 13596 S12/OS9/68000 (OSK)
    21-Dec-91  21:00:32
Sb: #13390-#shell
Fm: Bud Hamblen 72466,256
To: Bob van der Poel 76510,2203 (X)
Bob,
Here's what the version 2.4 release notes say:
syntax: profile <filename>
simple, huh?
Actually, profile <filename> works just like invoking the procedure file
<filename> by name, except it doesn't doesn't fork a new shell to execute the
procedure file.
Bud
There is 1 Reply.

#: 13662 S12/OS9/68000 (OSK)
    25-Dec-91  12:01:23
Sb: #13596-#shell
Fm: Bob van der Poel 76510,2203
To: Bud Hamblen 72466,256 (X)
Bud, thats for the pointer on PROFILE. I think I actually have it working okay
now. At the time my setting of the _sh variable was causing some problems since
I was using my 2.3 startup. I think that there is a difference in the way the
2.4 shell accesses the .login file. Not completely sure, but it seems that 2.3
startup shell processed .login; 2.4 does not (it relies on logon to do so).
There is 1 Reply.

#: 13733 S12/OS9/68000 (OSK)
    28-Dec-91  13:39:04
Sb: #13662-#shell
Fm: Bud Hamblen 72466,256
To: Bob van der Poel 76510,2203 (X)
I've always had to log on to use the .login file.  Never could set the
environment with startup.  The shell that executes the startup file apparently
isn't the shell that executes my input.
There is 1 Reply.

#: 13744 S12/OS9/68000 (OSK)
    28-Dec-91  21:12:48
Sb: #13733-#shell
Fm: Colin J. Smith 73777,1360
To: Bud Hamblen 72466,256
I'm not sure if this is what you're talking about, but the .login on my MM/1 is
executed whenever I boot up (I don't use any sort of timeshare/ multiuser
stuff).  My system is floppy based.  My startup is iniz d0 d1 and my .login
sets the time and important environment variables.
  --Colin
There is 1 Reply.

#: 13759 S12/OS9/68000 (OSK)
    29-Dec-91  18:16:47
Sb: #13744-shell
Fm: Bob van der Poel 76510,2203
To: Colin J. Smith 73777,1360
Colin, what is the version number of the Shell you're running? I was sure that
.login was being processed with my original mm/1 proto, but with the new
complete system it seems to require LOGIN. I suppose it could be something to
do with the HD or startup...

#: 13664 S12/OS9/68000 (OSK)
    25-Dec-91  12:57:09
Sb: MM/1 Palette (cgfx.l)
Fm: GLEN HATHAWAY 71446,166
To: all
Hi all... I'm trying to write in C for the MM/1. I think the cgfx.l Palette
command has a problem. Try compiling and running this: main() {
  int x,y;
  for(x=0;x<256;x++)
    {
      Palette(1,2,x,00,00);
      for(y=0;y<1500;y++);
    }
  for(x=0;x<256;x++)
    {
      Palette(1,2,00,x,00);
      for(y=0;y<1500;y++);
    }
  for(x=0;x<256;x++)
    {
      Palette(1,2,00,00,x);
      for(y=0;y<1500;y++);
    }
  system("display 1b 31 02 00 00 40");
}
 See if it works on your MM/1. On mine, it outputs a '1' for every time Palette
is called. And blue doesn't change at all! Can anyone see an error in my code
that would cause this?

#: 13761 S12/OS9/68000 (OSK)
    29-Dec-91  21:34:21
Sb: MM1 Questions:
Fm: GLEN HATHAWAY 71446,166
To: all
Hi all... I have a few questions on the MM/1: 1. Do the cgfx.l functions go
directly to hardware? Were they written in C or assembler? If they just spit
codes at the screen and were written in C, I can replace the ones I can't get
to work with my own without a speed penalty. 2. Can't get _ss_palette to work.
Compiles and runs, but doesn't put the data in the PRN's. Should I be including
something (.h file) or searching a particular lib, other than cgfx.l? 3. Is the
'keyboard mouse' supported on the MM/1? 4. Anyone close to IMS know when we can
expect some manuals? 5. Has anyone done anything with OddJob? A few examples
would be nice to help get us started, if anyone has any...
Press <CR> !>