textfiles/messages/ALANWESTON/1993/CIS03_31.txt

#: 17777 S1/General Interest
    22-Mar-93  19:11:11
Sb: #17761-#How come?
Fm: Carl Kreider 71076,76
To: Ken Flanagan 75460,2514 (X)

It got pushed down the interrupt stack.  I am trying to get to it again.

There is 1 Reply.

#: 17780 S1/General Interest
    23-Mar-93  03:35:52
Sb: #17777-#How come?
Fm: Ken Flanagan 75460,2514
To: Carl Kreider 71076,76 (X)

Have you made any decisions on it.  Ie.  default compression, what the max bit
compression will be, keeping attributes, etc?

There is 1 Reply.

#: 17831 S1/General Interest
    30-Mar-93  19:12:49
Sb: #17780-How come?
Fm: Carl Kreider 71076,76
To: Ken Flanagan 75460,2514

Yep.  Keeping attributes, 13 bits max, still lzw compression.  No point in
changing that.... it wouldn't be ar anymore.

#: 17778 S1/General Interest
    22-Mar-93  19:12:04
Sb: #17764-How come?
Fm: Carl Kreider 71076,76
To: Pete Lyall 76703,4230 (X)

Ah..... CTRL O.... I'll try to burn that in.  I can't look it up in time ;)

#: 17787 S1/General Interest
    23-Mar-93  20:35:44
Sb: #message 13904
Fm: fred kohlhepp 72300,3553
To: sysop (X)

Your welcome message talks about archival software; refers to message 13904.
This message can't be located in the message strings.  What's up?

Fred

There are 2 Replies.

#: 17788 S1/General Interest
    24-Mar-93  06:53:06
Sb: #17787-message 13904
Fm: Dan Robins 70007,3264
To: fred kohlhepp 72300,3553 (X)

Fred,
   CompuServe gives each forum a certain number of 'message slots', and in this
particular case....enough messages have been entered since that particular
message was posted that it was replaced by newer ones.
   Maybe it's possible that one of our forum users saves these messages and can
repost it....but there's no guarentee of that.
   Sorry it isn't around to refer to!       Dan

#: 17790 S1/General Interest
    24-Mar-93  07:25:25
Sb: #17787-message 13904
Fm: Steve Wegert 76703,4255
To: fred kohlhepp 72300,3553 (X)

Fred,

Sorry for the confusion. 13904 has hit the bit bucket.

In short, it attempted to put to rest a rather long winded discussion on the
use of a 'unofficial' version of the AR archive utility. The author of AR asks
that folks continue to use the official 1.2 version (found here in our
libraries) until such time that he releases an update.

Hope this clears up the mud ....

Steve

#: 17830 S1/General Interest
    30-Mar-93  17:46:37
Sb: Rsdoscopy Version 1.00
Fm: PHILLIP TAYLOR 72067,3430
To: All

A new program I uploaded today Rsdoscopy Version 1.00. This is utility that
fully menu driven, and will allow users to copy files from Rsdos to Os9 and
files from Os9 to Rsdos.  Its located in File Area #10.

Also for those users who are looking for Bulletin Boards running on a Trs-80
Color Computer, you call the Big Dipper at 703-573-5606, or The Fido Exchange
at 703-573-2246 running on a Ibm 386sx with Remote Access.  I am the author of
Rsdoscopy Version one, and the file name is Rcopy1.Ar

Phillip Taylor

#: 17798 S3/Languages
    25-Mar-93  14:59:05
Sb: #C++ compiler available
Fm: bye 70324,261
To: all

Does anyone know if there is a C++ compiler available for OS-9000 now?  We will
be starting a major software project shortly and I would like to start with a
C++ compiler.


Thanks in advance

-- Thad



There is 1 Reply.

#: 17803 S3/Languages
    26-Mar-93  09:46:31
Sb: #17798-#C++ compiler available
Fm: Pete Lyall 76703,4230
To: bye 70324,261 (X)

I believe the GNU compiler supports C++, but we're not using it at the moment.

Pete

There is 1 Reply.

#: 17822 S3/Languages
    29-Mar-93  08:48:20
Sb: #17803-#C++ compiler available
Fm: bye 70324,261
To: Pete Lyall 76703,4230 (X)

We are just looking into OS-9000, can you tell me what GNU stands for?  Who
markets it?


Thanks for the info!

-- Thad



There is 1 Reply.

#: 17823 S3/Languages
    29-Mar-93  09:15:52
Sb: #17822-#C++ compiler available
Fm: Pete Lyall 76703,4230
To: bye 70324,261 (X)

GNU is a sort of humorous, recursive acronym standing for:

   GNU is Not Unix

It is distributed by the free software foundation, and it is freeware.

Pete

There is 1 Reply.

#: 17826 S3/Languages
    29-Mar-93  16:50:52
Sb: #17823-C++ compiler available
Fm: bye 70324,261
To: Pete Lyall 76703,4230 (X)

Thanks, you have just enlightened one of the ignorant.

-Thad



#: 17832 S6/Applications
    31-Mar-93  04:51:23
Sb: Attachment to IBM system
Fm: Hugo Rytz 100116,3720
To: All

I'm involved in a project, were we need to attach an OS9 system to a IBM system
with token ring and the IBM SNA network protokoll. The OS9 system should
maintain a LU6.2 session with peer to peer comm unication with the host.

Does somebody have experience with connecting an OS9 system to an IBM host or
know a supplier of SNA network software and/or hardware for the
OS9 system?

   

#: 17818 S7/Telecommunications
    28-Mar-93  08:29:43
Sb: #17564-#terminal help
Fm: Kevin Pease 70516,1633
To: Bill Dickhaus 70325,523 (X)

Bill I have a hack that will eliminate the keyboar problems. It is two jumpers.
It connects the keyboard handshake line

There is 1 Reply.

#: 17819 S7/Telecommunications
    28-Mar-93  13:16:48
Sb: #17818-terminal help
Fm: Bill Dickhaus 70325,523
To: Kevin Pease 70516,1633

Kevin,

Is this a problem with specific keyboards? I'm planning on replacing my
keyboard soon, is there a chance it will work OK? Could you tell us what the
hack is? Thanks.

        -Bill-

#: 17802 S9/Utilities
    26-Mar-93  04:31:07
Sb: #Disk Fragmentation
Fm: Mcgennity-M 100136,3276
To: ALL

Does anybody know of an efficient RBF disk de-fragmentation utility?

I am an engineer working with OS9 for CDI production. I am constantly having to
backup-format-restore my SCSI drives because some of the files that I have to
manipulate must use contiguous disk space (for emulation etc).  The files are
in the order of 650 Meg and so backing up to tape is very time consuming as you
can appreciate.

Any help with this would be much appreciated.

Malcolm.

Futuremedia Interactive.
United Kingdom.
tel: 0243 555000
fax: 0243 555020


  

There are 2 Replies.

#: 17816 S9/Utilities
    27-Mar-93  16:51:16
Sb: #17802-Disk Fragmentation
Fm: Bob van der Poel 76510,2203
To: Mcgennity-M 100136,3276 (X)

Malcolm, I'm sure that Ole Hansen will let you know about a program I believe
he sells...however, you might be better off just avoiding file fragmentation if
you can. A could of suggestions:

1. Pre-extend the file allocation for what you believe the file's max. size
will be when you create the file. As long as when you close the file you are
not at the EOF, the extra sectors allocated will not be returned to the system.

2. If you have a fragmented file and you have contiguos disk space for it, just
copy that file. If I recall correctly, COPY will do a pre-allocation. After the
copy, just delete the old and do a rename. I wrote a utility awhile ago for
6809 which did that. It is avail in lib10 as 'unfrag.ar'.

#: 17825 S9/Utilities
    29-Mar-93  16:33:15
Sb: #17802-Disk Fragmentation
Fm: ole hansen 100016,3417
To: Mcgennity-M 100136,3276 (X)

Hello Malcolm

Try to contact 'Galactic Indutrial' Mr. Paul Dayan. He is selling a program
called DiskSqueezer from 'Ark System USA'. That program will reorganize your
disk and collect files so they get contigous(if possible). If you are using
that big files, why don't you increase the allocation-size so you don't get
that many small segments ??

Here is the phone-number to Paul: (+44) 913848343

regards ole@anelec.dk

#: 17776 S10/OS9/6809 (CoCo)
    22-Mar-93  13:23:52
Sb: WD1773 COCO disk chip
Fm: Timothy J. Martin 71541,3611
To: all

If anyone is looking to replace the WD1773 controller chip in their COCO Disk
controller Cartridge, they are available through a chip broker in California
named "Jerome Industries".  Phone number is 805-527-5893, ask for Susan
Laughler (sp?).  They sell only to businesses, and need a $50 dollar miniumum.
The sell the WD1773-PH for $17.50 each.

#: 17782 S12/OS9/68000 (OSK)
    23-Mar-93  08:08:17
Sb: #17736-#PCF
Fm: Bert Schneider 70244,427
To: Bob van der Poel 76510,2203 (X)

Bob, Are those DMODE options used with you PCF drivers/descriptors or with the
OSK ones?  I have been trying to assemble the files myself but to no avail!
Thanks! Bert

There is 1 Reply.

#: 17786 S12/OS9/68000 (OSK)
    23-Mar-93  18:28:35
Sb: #17782-#PCF
Fm: Bob van der Poel 76510,2203
To: Bert Schneider 70244,427 (X)

The dmode I posted here is just a dmode of the pcf driver which came with the
update stuff (I think I got the update stuff here?). Remember, when you access
PCDOS disks you do a "dir /pc1" or "list /pc1/foo"...just forget about the OSK
desc. at this point.

There is 1 Reply.

#: 17793 S12/OS9/68000 (OSK)
    24-Mar-93  21:33:00
Sb: #17786-#PCF
Fm: Bert Schneider 70244,427
To: Bob van der Poel 76510,2203 (X)

I didn't get the object code for pc1, just the source.  So far I have been
unable to get it to work.  I assemble and link the file(s) but I can't iniz
pc1.  Do you have a working pc1 file for 5.25" 40 track DD drives? If so, could
you email yours?  I don't think it will take too long! Thanks!

Bert Schneider

     (o)   (o)
         U
       \___/


There is 1 Reply.

#: 17801 S12/OS9/68000 (OSK)
    25-Mar-93  22:40:23
Sb: #17793-PCF
Fm: Bob van der Poel 76510,2203
To: Bert Schneider 70244,427

Okay, they are in your mailbox.

#: 17781 S12/OS9/68000 (OSK)
    23-Mar-93  08:04:14
Sb: #17721-PCF
Fm: Bert Schneider 70244,427
To: Mark Griffith 76070,41 (X)

Mark, Could I get your descriptor values (or file) for the 3.5" drives?  I
could probably change mine for 5.25" drivers.

Thanks!

Bert

#: 17783 S12/OS9/68000 (OSK)
    23-Mar-93  13:32:55
Sb: #17767-#Subroutine modules
Fm: Graham Trott 100115,1075
To: Bob van der Poel 76510,2203 (X)

Bob --

>>> At this point, however, it looks like it'll be easier for all (including
the folks who will end up writing there own interfaces) to have this done via a
front-end which interprets mouse data, etc. and inserts it into the keyboard
stream for ved. <<<

Another possibility is to have the mouse interface written as a separate
stand-alone process with a defined data module interface.  All the editor needs
to know is the name of the mouse module (could be in an environment variable)
so it can fork it.  Advantages of this approach are 1) there are no
side-effects mixing mouse info with keyboard input and 2) the data module can
contain fields that time-stamp mouse events, allowing double-click or
inactivity detection, mouse acceleration and so on.  The editor is relieved of
the need to handle all this real-time junk.  Timing gets a bit imprecise when
everything has to feed through stdin.

-- GT

There is 1 Reply.

#: 17792 S12/OS9/68000 (OSK)
    24-Mar-93  19:31:36
Sb: #17783-Subroutine modules
Fm: Bob van der Poel 76510,2203
To: Graham Trott 100115,1075 (X)

Yes...data modules and standalone co-routines are a good idea. Guess that's
what's so neat about OS9...so many ways to do so many things. Pity we can't
convert the rest of the world.

#: 17775 S12/OS9/68000 (OSK)
    21-Mar-93  18:40:59
Sb: #17774-#MM/1 boot ROM
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)

Well...yes I did the obvious <grin>. But to make sure I'll check again.

First off, I have the file OS9BOOT on HD0. To make sure it is okay I just did
an ident. All is okay.

Next, I fired up DED and examined LSN0. At $15 it shows $01 $24 $9c. So, the
boot is registered. I not that the size of the bootfile is listed as 00 00.
But, that is true on the floppy too...so I assume that the size is ignored.
Hmmm, it'd have to be since the boot is 108K and there are only 2 bytes for the
size.

A dir -e shows that the the 'sector' for os9boot is 1249c. So, things appear
okay in this department.

BTW, when attempting to boot the drive light for HD0 does not show any
activity. Also, it makes no difference if this is a cold boot or if I just hit
RESET. I've left it for a few minutes thinking that maybe it is waiting for the
drive to come up to speed, but no difference.

So, what do I test next?

There is 1 Reply.

#: 17779 S12/OS9/68000 (OSK)
    23-Mar-93  02:56:15
Sb: #17775-#MM/1 boot ROM
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)

Bob,

 > So, what do I test next?

You might try going into the init module with moded and increase the cold start
retry count.  Run moded on the bootfile and step down through until you see an
entry called "coldstart 'chd' retry count" and increase the number there.  Mine
is set to 50, but you may need to make it higher than that.  If that doesn't
work, I'm at a loss for what to try next. Perhaps someone else here with one of
those ROMs will be able to help more.


                  /************* /\/\ark ************/

There is 1 Reply.

#: 17785 S12/OS9/68000 (OSK)
    23-Mar-93  18:28:32
Sb: #17779-MM/1 boot ROM
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)

I'm starting to think that the ROMs might be broke.

I don't think it is a retry problem in init. From what I can see the drives
just never get accessed...I assume that the ROM routine would cause the LED on
the HD to at least blink.

I swapped the ID numbers on my harddrives (I have a Quantum LP105S and a Maxtor
7120SCS) but the same result.

Any thoughts on this will be appreciated. If someone happens to know of some
ROM offsets I can have a look at...

#: 17784 S12/OS9/68000 (OSK)
    23-Mar-93  13:36:47
Sb: Bridging ARCNET LANs
Fm: David Briggs 100113,1203
To: ALL

I have a customer running OS-9/NET on ARCNET at two sites, one on each side of
a river. They would like to connect them together...

Can anyone suggest a good way to bridge the LANs, perhaps over a leased line?
What problems should I look out for?

Thanks for any assistance.

David Briggs
Vector Networks (UK) +44 827 67333
  

#: 17791 S12/OS9/68000 (OSK)
    24-Mar-93  13:54:13
Sb: #NFM Serial Line Driver
Fm: David Briggs [Vector] 100113,1203
To: ALL

Does anyone know of a serial line driver that can be used with the NFM to
connect two OS-9/NET networks over a leased line?

I am trying to find a way of linking two networks that are separate, but
connected by a twisted pair cable with lots of spare pairs.

Any ideas? Thanks for any information.

David Briggs
Vector Networks (UK) +44 827 67333 

There is 1 Reply.

#: 17799 S12/OS9/68000 (OSK)
    25-Mar-93  18:46:01
Sb: #17791-#NFM Serial Line Driver
Fm: ole hansen 100016,3417
To: David Briggs [Vector] 100113,1203 (X)

hello David.

What type of uart are you using for the serial NFM?? There is available serial
NFM-drivers for MC6850,MC68681 and Z8530. You could contact Mr Paul Dayan at
Galactic Industrial Phone: (+44) 913848343. He might help you.

regards ole@danelec.dk

There is 1 Reply.

#: 17815 S12/OS9/68000 (OSK)
    27-Mar-93  15:26:30
Sb: #17799-#NFM Serial Line Driver
Fm: David Briggs [Vector] 100113,1203
To: ole hansen 100016,3417 (X)

Ole,

Thanks for the reference. I don't know the type of UART. I will have to find
out!

Do the drivers you mention come from Paul Dayan, or are they from somewhere
else?

Thanks again.

David Briggs
Vector Networks (UK) +44 827 67333 

There is 1 Reply.

#: 17824 S12/OS9/68000 (OSK)
    29-Mar-93  16:22:22
Sb: #17815-NFM Serial Line Driver
Fm: ole hansen 100016,3417
To: David Briggs [Vector] 100113,1203 (X)

Hello David.

They are in the NFM-portpak we have recieved from Microware.

regards ole

#: 17800 S12/OS9/68000 (OSK)
    25-Mar-93  21:28:45
Sb: #Bigger read/write buffer
Fm: William F. McGill/CA 73177,3433
To: All

Can anyone tell me how to increase the size of the system buffer associated
with the read() and write() commands in C 3.2?

I need to copy a large file, and it seems the system buffer size is rather
small.  It takes about 4 times as long to copy the file using a read() followed
by a write() than it does when I just use the OS9 copy command, specifying "
-b=64k ".

I've read all the manuals, and OS-0 Insights implies that it is possible to
increase the system buffer size, but I haven't found any way to do it.

Any ideas?

Bill


There are 3 Replies.

#: 17804 S12/OS9/68000 (OSK)
    26-Mar-93  09:49:07
Sb: #17800-#Bigger read/write buffer
Fm: Pete Lyall 76703,4230
To: William F. McGill/CA 73177,3433 (X)

In any case (copy included), the system buffers (actually driver buffers) are
usually fixed. Copy is using the same mechanism (i.e. read(), write()). Try
maintaining a large buffer in your application data space, and reading large
chunks until you fill it. Then do a single write().

Pete

There is 1 Reply.

#: 17805 S12/OS9/68000 (OSK)
    26-Mar-93  10:16:14
Sb: #17804-#Bigger read/write buffer
Fm: William F. McGill/CA 73177,3433
To: Pete Lyall 76703,4230 (X)

Pete-

Thanks for the reply.  My application program is doing what you suggest; the
input buffer is about 125k bytes and does a single read() to fill it. When the
read() command returns, the program does a single write().  But this simple
read() - write() loop takes several times longer to copy a file than when I use
OS9's copy, with -b=64K  (or larger).  I hoped perhaps there way to specify
this option in C.

You say the buffer is actually a driver buffer.  Is there a way to modify the
driver to get it to use a larger buffer?

Thanks again,

Bill


There are 2 Replies.

#: 17808 S12/OS9/68000 (OSK)
    26-Mar-93  18:17:15
Sb: #17805-Bigger read/write buffer
Fm: Pete Lyall 76703,4230
To: William F. McGill/CA 73177,3433 (X)

Only if you have sources, which is usually not the case.

Pete

#: 17811 S12/OS9/68000 (OSK)
    27-Mar-93  05:15:23
Sb: #17805-#Bigger read/write buffer
Fm: Mark Griffith 76070,41
To: William F. McGill/CA 73177,3433 (X)

Bill,

 > Thanks for the reply.  My application program is doing what you suggest;
 > input buffer is about 125k bytes and does a single read() to fill it.

You may have to play with the buffer size to get the most efficient copy speed.
I have found that much smaller buffer sizes, like 32k or so, are faster than
larger buffers.  I have done a couple copy utilities that are faster than the
Microware on.


                  /************* /\/\ark ************/

There is 1 Reply.

#: 17814 S12/OS9/68000 (OSK)
    27-Mar-93  10:52:19
Sb: #17811-Bigger read/write buffer
Fm: William F. McGill/CA 73177,3433
To: Mark Griffith 76070,41 (X)

Mark,

Thanks for the advice on buffer selection.  I did play around with various
sizes, and it appears that in this instance the larger the buffer the better.
With a buffer of 1 Meg, copying proceeds at least as fast as the OS-9 copy
command.

The problem turned out to be interference from a higher-priority task, which
was interrupting the data transfer and stealing significant amounts of time. By
suspending the higher-priority task while copying, I was able to get a vast
improvement in copying speed.

Thanks for your help!

Bill


#: 17809 S12/OS9/68000 (OSK)
    26-Mar-93  21:28:45
Sb: #17800-#Bigger read/write buffer
Fm: Bob van der Poel 76510,2203
To: William F. McGill/CA 73177,3433 (X)

WIlliam, I don;t think it is a buffer size problem. In read you just specify
the buffer size as the 3rd. param. However, utilities like copy pre-extend the
file to the full size...this means that only one file allocation system call is
done...if you want to do the same use the create() call with the optional size
specifier.

There is 1 Reply.

#: 17813 S12/OS9/68000 (OSK)
    27-Mar-93  10:52:10
Sb: #17809-Bigger read/write buffer
Fm: William F. McGill/CA 73177,3433
To: Bob van der Poel 76510,2203 (X)

Bob,

You are right, it wasn't a buffer size problem after all.  A SCSI-bus analyzer
revealed large gaps during which no transfers were taking place, even though
the drive was ready to accept more data.

The program is running in a multi-tasking environment;  the problem is that a
task with higher priority was also running, and the time allocated to that task
accounted for the gaps in the data transfer.

Setting D_MinPty to 2 and temporarily reducing the higher-priority task to
priority 0 (to suspend it while copying) solved the problem.  The program can
now copy as fast as the OS-9 copy command.

Thanks for your helpful suggestions.

Bill


#: 17810 S12/OS9/68000 (OSK)
    27-Mar-93  02:56:16
Sb: #17800-Bigger read/write buffer
Fm: Mark Griffith 76070,41
To: William F. McGill/CA 73177,3433 (X)

Bill,

 > Can anyone tell me how to increase the size of the system buffer associated
 > with the read() and write() commands in C 3.2?

You must be talking about fread() and fwrite().  There is no internal buffering
on read() and write() since they are low-level functions:

        read (path, buffer, count)

should explain it.  You can make the buffer in your code any size you want.
Actually, 32768 is the largest you can predefine.  You need to use malloc() or
something like that to make a larger buffer.

Hope this helps.


                  /************* /\/\ark ************/

#: 17806 S12/OS9/68000 (OSK)
    26-Mar-93  12:47:42
Sb: #MM1 problem
Fm: Hugo Bueno 71211,3662
To: All

I've posted this to the Coco list, but thought I'd try here too...

I finally got my MM1 this week.  I ordered a 1 meg unit with IO board and 1
floppy drive.  When the machine arrived, I booted it up and it worked fine.

Today, I installed 2 more megs of ram and 2 floppy drives. I shorted both sets
of pins on P7 (parallel to minibus) . Upon trying to boot the machine, it
wouldn't.  The screen was blue with OS9 68K Boostrap at the top.  It then very
quickly flashed a message on the screen. I think it said "boot failed, error
status $0100".  What does this mean? A bad boot disk? Unfortunately, I only got
one floppy disk. I'm going to copy the full set from another local MM1 owner.

I brought the machine back to it's original state and it gave the same error.

Any help/ideas would be greatly appreciated. I hope this isn't a hardware
problem.


There is 1 Reply.

#: 17812 S12/OS9/68000 (OSK)
    27-Mar-93  05:32:41
Sb: #17806-#MM1 problem
Fm: Steve Wegert 76703,4255
To: Hugo Bueno 71211,3662 (X)

Hugo,

I'm probably stating the obvious, but all cables checked for proper connection
and pin 1 positioning?

New drives strapped properly?

Steve


*- Steve -*


There is 1 Reply.

#: 17820 S12/OS9/68000 (OSK)
    28-Mar-93  19:06:50
Sb: #17812-#MM1 problem
Fm: Hugo Bueno 71211,3662
To: Steve Wegert 76703,4255 (X)

Well, at this point I'd still like to figure out proper jumper settings for pad
P7.  I've been told on the COco list that the instructions in the IMS manual
are incorrect.  Are the jumpers supposed to be parallel or perpendicular to the
minibus?

Next, on the floppy drives. I guess that'll have to wait until I have a working
bootable floppy.

Hugo

There are 2 Replies.

#: 17821 S12/OS9/68000 (OSK)
    29-Mar-93  05:50:51
Sb: #17820-MM1 problem
Fm: Mark Griffith 76070,41
To: Hugo Bueno 71211,3662 (X)

Hugo,

 > Well, at this point I'd still like to figure out proper jumper settings for
 > pad P7.  I've been told on the COco list that the instructions in the IMS
 > manual are incorrect.  Are the jumpers supposed to be parallel or
 > perpendicular to the minibus?

The instructions are correct, you place the two jumpers parallel to the
mini-bus.


                  /************* /\/\ark ************/

#: 17828 S12/OS9/68000 (OSK)
    30-Mar-93  05:32:33
Sb: #17820-MM1 problem
Fm: Steve Wegert 76703,4255
To: Hugo Bueno 71211,3662 (X)

Hugo,

I see Mark has jumpped in on the jumper positions for you.

On the floppy straps, it should be pretty easy. If you got the MM/1 with one
floppy in it and it worked fine, then that one must have been strapped for
drive 0. The other two need to be different.

Also, make sure you're using the 3meg init module. That could be adding to your
troubles.



*- Steve -*


#: 17817 S12/OS9/68000 (OSK)
    27-Mar-93  16:51:22
Sb: Televideo 965
Fm: Bob van der Poel 76510,2203
To: All

Does anyone know where I get a manual for a Televideo 965 tube? A phone number
for televideo would be helpful. Even better...can I borrow a manual for a few
days?

#: 17827 S12/OS9/68000 (OSK)
    29-Mar-93  19:24:33
Sb: Blarslib fixes
Fm: Bob van der Poel 76510,2203
To: Steve Wegert 76703,4255 (X)

Steve, seeing MH's fix for the link() function in blarslib.l reminded me that I
had to make a fix to utime() awhile ago to get it to operate in the manner
expected by a program I was porting from unix. I'm not sure which is the
correct method...so I'll just post my revised source here in this message.
Guess if the program doesn't work one way...one could try this. I don't have
access to the proper docs, so I'm just guessing.

 #include <time.h>
 #include <direct.h>
 #include <modes.h>
 #define NULL 0
 int utime(file, timep)
 char *file;
 time_t timep[2];
 {
     register int p;
     register struct tm *when;
     struct fildes fd;

     if((when = gmtime(&timep[1])) == NULL) return -1;
     /* changed S_IREAD to S_IWRITE bvdp 92/12/17 */
     if((p = open(file, S_IWRITE)) < 0 &&
                (p = open(file, S_IWRITE|S_IFDIR)) < 0) {
        return -1;
     }
     if(_gs_gfd(p, &fd, sizeof fd) < 0) {
        close(p);
        return -1;
     }
     fd.fd_date[0] = when->tm_year;
     fd.fd_date[1] = when->tm_mon + 1;
     fd.fd_date[2] = when->tm_mday;
     fd.fd_date[3] = when->tm_hour;
     fd.fd_date[4] = when->tm_min;
     if(_ss_pfd(p, &fd) < 0) {
        close(p);
                return -1;
     }
     return(close(p)<0) ? -1 : 0;  /* changed!!! bvdp */
  }


#: 17829 S12/OS9/68000 (OSK)
    30-Mar-93  14:06:47
Sb: NFM Serial Line Driver
Fm: Graham Trott 100115,1075
To: David Briggs [Vector] 100113,1203

David --

You could contact Windrush Micro Systems at 0692 404086 - they are one of the
few companies left in the UK with any dealings with ArcNet, and they provide
custom solutions for OS-9 applications.  To connect two ArcNet systems together
transparently requires careful engineering and is probably not available in a
standard off-the-peg product.

-- GT

Press <CR> !>