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