1

#: 17859 S1/General Interest
    04-Apr-93  13:36:55
Sb: #17858-SALE OF ALL COCO STUFF
Fm: Brother Jeremy, CSJW 76477,142
To: JOERG SATTLER 74016,631 (X)

I will be in touch.--Br. Jeremy, CSJW


#: 17860 S1/General Interest
    04-Apr-93  16:21:05
Sb: #Ar Version 1.3
Fm: PHILLIP TAYLOR 72067,3430
To: All

This is the second time I uploaded Ar to Area #10, Version 1.3 as far as I know
is a official release from the author.  Whats going here?


There is 1 Reply.

#: 17863 S1/General Interest
    04-Apr-93  21:22:27
Sb: #17860-#Ar Version 1.3
Fm: Steve Wegert 76703,4255
To: PHILLIP TAYLOR 72067,3430 (X)

Phil,

Sorry for the confusion over your AR upload. But as we understand the situation
from the the author, Carl Kreider, the current release of AR is 1.2 and resides
in our libraries.

Carl has requested that the OS9 Forum on CompuServe serve as the official site
for the AR archiver. To that end, he has also requested that the staff do what
they can to limit the spread of other versions of AR claiming to be 'the
lastest release'.

While 1.3 is still backwards compatable with 1.2 (the only change I'm aware of
is the handling of permissions) it was not authorized by the author.

Hope this clears the air. If you have any questions, don't hesitate to ask.

Thanks,


*- Steve -*


There is 1 Reply.

#: 17883 S1/General Interest
    08-Apr-93  17:31:27
Sb: #17863-#Ar Version 1.3
Fm: PHILLIP TAYLOR 72067,3430
To: Steve Wegert 76703,4255 (X)

Since I am so confused from Ddelphi using on version of ar, and saying that the
one they require for me to use to upload files, and this form used a different
version, I am going to check and see if 1.2 is the lastest release version.

Phillip Taylor

There is 1 Reply.

#: 17888 S1/General Interest
    10-Apr-93  10:32:17
Sb: #17883-Ar Version 1.3
Fm: Steve Wegert 76703,4255
To: PHILLIP TAYLOR 72067,3430 (X)

Several months ago, when the various version of AR began to pop up, I left word
with Greg over on DELPHI as to what I understood Carl to want.

I thought he indicated at that time he'd check out the various versions and
abide by Carl's wishes.


Perhaps this will be a moot point. Carl is working (has been working) on a new
release of AR.


*- Steve -*


#: 17862 S12/OS9/68000 (OSK)
    04-Apr-93  18:24:42
Sb: #17370-Termcap
Fm: David George 72240,134
To: Bob van der Poel 76510,2203 (X)

Sorry it took me so long to reply, but I don't get up here much anymore.
A * means that the padding is proportional to the number of lines effected.
I don't have my Unix system botted up right now so I can't look into the others
(** and (G))

#: 17873 S12/OS9/68000 (OSK)
    06-Apr-93  18:43:17
Sb: #17801-PCF
Fm: Bert Schneider 70244,427
To: Bob van der Poel 76510,2203 (X)

Thanks!  I really appreciate that!

#: 17871 S12/OS9/68000 (OSK)
    06-Apr-93  05:25:45
Sb: #17856-HD
Fm: Mark Griffith 76070,41
To: Hugo Bueno 71211,3662 (X)

Hugo,

 > I used newer drivers and managed to format the hard drive sucessfully.

Good, glad you're up and running now!


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

#: 17861 S12/OS9/68000 (OSK)
    04-Apr-93  17:51:02
Sb: #17853-OS-9 Config 4 SCSI Boot
Fm: ole hansen 100016,3417
To: Peter Baxter 74650,2522

Hello Peter. If the only problem is with the 'dd' device, try not to include it
in the bootfile, and create one for the rimfire-board using the '/h0' or '/h1'
or whatever the device-name is for the rimfire-device. The 'dd'-device is
normally just another name for the 'device' yuo use as 'default device'. You
can always 'load' the desired 'dd'-device (from startup) or command-line. If
your system can make access to the rimfire without the 'dd'-device loaded, then
just copy that file to dd.rimfire and use moded to chenge the name to 'dd'. If
you also are having problems with no 'dd' loaded, then you probably have loeded
two different device-descriptors with the same module-name. use 'mdir' to
confirm that the device use want is loaded. Then use 'ident' on the file you
loads as the device-descriptor to access the rimfire-drive and use ident (with
'-m' flag) to check that the 'crc' is the same. If not, then you don't(sorry :
the system does not) make access to the device you want. Does you get any
error-messages ?? Try also to use the 'dump'-command wtih the '-m' flag to show
the device-descriptor in memory. Yuo should be able to see the
filemanager-name(RBF) and the device-name and driver-name.

regards ole@danelec.dk

#: 17868 S12/OS9/68000 (OSK)
    05-Apr-93  12:57:34
Sb: #17853-OS-9 Config 4 SCSI Boot
Fm: Kim Kempf 71161,3221
To: Peter Baxter 74650,2522

You are misunderstanding how the disk booting process works.  It's the part of
OS-9 in ROM that knows how to "boot" devices.  The rom for your cpu already
knows how to operate the 53c710 hardware to read a bootfile from a scsi target.
You need to have a booter in the rom that knows how to operate the Ciprico
controller in order to boot from that.  There is nothing you can do to the
bootfile or driver to change this.  The rom booter is the thing that reads in
the bootfile...sort of a chicken and egg problem.

Making a rom boot routine requires the Portpak source code and lots of
knowledge.  Your best bet would be to contact Ultrascience to see if they can
add a Ciprico booter to the ROM.

#: 17864 S12/OS9/68000 (OSK)
    05-Apr-93  01:15:59
Sb: #17855-#C_error_help
Fm: LARRY OLSON 72227,3467
To: Mark Griffith 76070,41 (X)

Mark,
     Do you mean 1 variable of 32k size ? or many variables totaling more than
32k. I don't have any assembler code imbedded in the program. I don't
(intensionally) have any 32k variables, but the total data size looks to be
39k. I'm trying to narrow down the point when I get the error, its down to
about a dozen lines of program, if I remark these out I don't get the error.
  I'll see if I can narrow it down some more. larry

There is 1 Reply.

#: 17870 S12/OS9/68000 (OSK)
    06-Apr-93  05:25:34
Sb: #17864-#C_error_help
Fm: Mark Griffith 76070,41
To: LARRY OLSON 72227,3467 (X)

Larry,

 >      Do you mean 1 variable of 32k size ? or many variables totaling more
than
 > than 32k.

If there is an array that is dimensioned to greater than 32K, like in 'char
array[33000]', this will cause errors like what you are getting.


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

There is 1 Reply.

#: 17892 S12/OS9/68000 (OSK)
    11-Apr-93  04:05:42
Sb: #17870-C_error_help
Fm: LARRY OLSON 72227,3467
To: Mark Griffith 76070,41 (X)

Mark,
    I don't have any arrays close to that size, I have 4 at 1535 and quite a
few other smaller ones. I'm trying to track down the problem, I have the
program working again, but I'm not sure if I'm going to run into the same error
later.
    I went through the program and tried to pare down the variable data space.
I got it down to where an IDENT gives a DATA SIZE of #32086.
   With that data size I was still getting the same error, so I thought I would
try to shrink some of the module size. By cleaning things up quite a bit, I was
able to bring the following down: Module size       #76648        #74158
 Init. data off:    #72474        #69992
 Data ref. off:     #76344        #73858

  Theprogram now compiles without the Value Out of Range error !!
 For some reason, the problem is tied into the size of the program. Could this
be something to do with the compiler ? This is all one big source file (86640
in size), I havn't got the hang of the linker yet. I have a couple more
routines to add yet, and I afraid that I will see this problem crop up again.

larry

#: 17865 S12/OS9/68000 (OSK)
    05-Apr-93  01:23:52
Sb: #17857-C_error_help
Fm: LARRY OLSON 72227,3467
To: John R. Wainwright 72517,676 (X)

John,
     This is strange, as I was telling Mark, I don't have any arrays that
large. There has to be some error in my code, which isn't too hard to believe
<g>. I'm trying to narrow down the offending code now. larry

#: 17866 S12/OS9/68000 (OSK)
    05-Apr-93  03:52:25
Sb: C help
Fm: Bob Taylor 73270,3124
To: all

I need help with the following integer with the top 4 bits used as flags and
the bottom 12 bits a signed integer. I haven't been able to correctly sign
extend. Could an expert help?

Thanks,
Bob

--------------------------------cut here-------------------------------

  typedef unsigned int CTYPE;

  #define MODE_BIT   0x8000
  #define VM_BIT     0x4000
  #define HM_BIT     0x2000

  #define MOTION(amt)  ( ((CTYPE)(amt) & 0xfff) | (MODE_BIT) | HM_BIT) ) ???
  #define MVAL(c)      ( (int) ((c) & 0xfff ) )   ?????????

#: 17874 S12/OS9/68000 (OSK)
    06-Apr-93  21:29:33
Sb: #COco disks on MM1
Fm: Hugo Bueno 71211,3662
To: All

OK, another MM1 question.  I'm trying to read 360K Coco disks on my drive 1.
I've tried using the /c1 descriptor with no luck.  The drive spins up, but all
I get is an error 246-device not ready.

Any ideas/suggestions?

Hugo

There is 1 Reply.

#: 17877 S12/OS9/68000 (OSK)
    07-Apr-93  17:30:32
Sb: #17874-#COco disks on MM1
Fm: Steve Wegert 76703,4255
To: Hugo Bueno 71211,3662 (X)

Hi Hugo!


Things were never meant to be this difficult!  :-)

I've use /c0 to read CoCo disks without any problems. How about posting the
idents of the various drivers and descriptors involved. I'll be happy to
compare them to mine.

Have you been able to access other formats in that particular drive?


*- Steve -*


There is 1 Reply.

#: 17884 S12/OS9/68000 (OSK)
    08-Apr-93  20:23:02
Sb: #17877-#COco disks on MM1
Fm: Hugo Bueno 71211,3662
To: Steve Wegert 76703,4255 (X)

Steve,

I've been unable to read my Coco disks with the /c1 descriptor. Per messages on
Delphi, I apparently have the latest RBF drivers and device descriptors.  One
thing I notice is that the LED on the 360K drive is brightly lit while the LED
on the standard MM1's 3.5 inches is dimly lit.  Does this mean anything?

I'm absolutely sure the drive is jumpered correctly as drive 1.

Again, all that happens is the disk spins up, but all I get is an error 246.
Never seen that error using disk devices before.

Hugo

There is 1 Reply.

#: 17889 S12/OS9/68000 (OSK)
    10-Apr-93  10:32:28
Sb: #17884-COco disks on MM1
Fm: Steve Wegert 76703,4255
To: Hugo Bueno 71211,3662 (X)

I'm not sure about the brightly lit LED on your drive ... sounds fishy.

My 3.5 does glow dimly ... but no where near the intensity of an accessed
drive. Perhaps your cable is on incorrectly?

What are your dmode values for /c1?

Perhaps Mark can jump in with a few ideas.


*- Steve -*


#: 17885 S12/OS9/68000 (OSK)
    08-Apr-93  20:30:49
Sb: #serial buffer size
Fm: Hugo Bueno 71211,3662
To: All

How do I determine the size of transmit and receive buffers on serial ports on
the MM1.  I think part of my comm problems can be attributed to too small
buffers.  How do I go about changing them. I seem to remember 2k as a
recommended size.

Hugo

There is 1 Reply.

#: 17890 S12/OS9/68000 (OSK)
    10-Apr-93  10:32:38
Sb: #17885-serial buffer size
Fm: Steve Wegert 76703,4255
To: Hugo Bueno 71211,3662 (X)

The moded command is what you need. Make sure you have the current moded.fields
file . Best way to do this is to pop it into an editor and see if the variable
bufer size stuff shows up in the SCF driver entries.

 Type moded

 use the f command to spec /d0/os9boot
 use the m comand to spec the proper descriptor to edit
 ues the e command to edit.

Thump enter (leaves the field alone) until you get to the the buffer entries.
They should be at the end of the module. Change the values to 2048 or so.

 use the w command to write and verify the module back out.
 use the q command to quit.

Happy hunting!


*- Steve -*


#: 17891 S12/OS9/68000 (OSK)
    10-Apr-93  15:41:48
Sb: BGFX docs
Fm: keith bauer 71102,317
To: Kevin Darling 76703,4227 (X)

Kevin, I caught a message about docs for BGFX and noticed that there are docs
available. I bought BGFX at the Chicago Fest last year form Paul and at that
time there where not any docs. I would really like to get my hands and these
docs. Can I send you a SASE or will you upload them here? Thanks Keith Bauer

Press <CR> !>