textfiles/messages/ALANWESTON/1994/OCEAN08_06.txt

N


Public Message 
Message # 2135 *MM1 TECH Echo*
To      : All
From    : David Graham
Subject : Booting from Maxtor HD?
Date    : 94/08/03  10:09:00
Next Reply is Message 2139

I am setting up a system to boot from a Maxtor 290 MB hard drive.
 
The boot rom usually runs through three attempts to boot before the
hard drive spins up, is there anything that can be done about this?? 
 
Any suggestions??

--- WILDMAIL!/WC v4.00h
 * Origin: The Sierra Hotel! BBS ~ Enid, Oklahoma ~  (1:19/47.0)


Public Message 
Message # 2136 *MM1 TECH Echo*
To      : All
From    : David Graham
Subject : ATP errors
Date    : 94/08/03  10:20:00

I'm using ATP on the MM/1 and keep getting errors that tell me my
messages are too long (153000 odd bytes long!), though I know it is not
so.  I then am able to use the reader on only the messages that are
processed before the errors, anyone else run into this, and how can it
be fixed??   Where can I get SCRIBE for the MM/1??? 
 
   ---
 OSkTag + Where there is no shame, there is no honor.

--- WILDMAIL!/WC v4.00h
 * Origin: The Sierra Hotel! BBS ~ Enid, Oklahoma ~  (1:19/47.0)


Public Message 
Message # 2139 *MM1 TECH Echo*
To      : David Graham
From    : Warren Hrach
Subject : Re: Booting from Maxtor HD?
Date    : 94/08/06 11:42:40
Previous Reply is Message 2135   

            On Wednesday, August 3rd, 1994 - David Graham wrote:
 
DG> I am setting up a system to boot from a Maxtor 290 MB hard drive.
DG> The boot rom usually runs through three attempts to boot before the
DG> hard drive spins up, is there anything that can be done about this?? 
DG> Any suggestions??
 
David,
      Do you have a jumper on the Maxtor J 302.  That is named the
power up option according to the doc sheet.  Mine seems to spin up when
I power up but I have not tried using it as the /dd/ drive with the boot 
on it.
      The other option is to call there 800 number (1-800-2MAXTOR) and
ask a serviceman.
-Warren
 
--- RiBBS v2.10        
 * Origin: Ocean Beach BBS 619-224-4878 MM1 TECH moderator (1:202/745)


Public Message 
Message # 2144 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 1/7
Date    : 94/08/04  17:39:00

Hi, All.

With the approval of the moderator here, Warren Hrach, I am going to start
relaying the messages to and from the MM/1 Developers Group on Internet.

For the most part, I will relay all messages, but depending on my mood, I
may skip some messages that are irrelevant.

TTYL. Colin


--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2145 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 2/7
Date    : 94/08/04  17:45:00

From: Boisy Pitre <boisy@microware.com>
Date: Wed, 27 Jul 1994 09:31:36 -0500 (CDT)
Subj: Cut'n'Paste

Hi folks,

Now that I'm almost through with LinkUp, I was hoping I could introduce
some cut'n'paste features. I'm curious as to how this might be
implemented in K-Windows. I would need to add code to select portions of
text from the screen and put them into some holding area (a get/put
buffer?) This holding area would have to be universally known so
that other applications could easily get to it.

I'm going to think about this more, and would be interested in hearing
some input on this.

From: Joel Mathew Hegberg <JOELHEGBERG@delphi.com>
Date: Fri, 29 Jul 1994 00:59:27 -0400 (EDT)
Subj: K-Win Clipboard

Okay, I've done quite a lot of thinking about the K-Windows clipboard
dilema, and I've come up with a complete proposal, which will be listed
in the next message.

I am completely willing to write the library referenced within the
proposal, and it shouldn't take but 2 weeks max. Please let me know
what you think.

I also have all the parameters for the library calls worked out, but I'm
not including them here as there are some that have character pointers,
and the astricks will cause problems with the mushroom server.



--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2146 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 3/7
Date    : 94/08/04  17:47:00

From: Joel Mathew Hegberg <JOELHEGBERG@delphi.com>
Date: Fri, 29 Jul 1994 01:00:44 -0400 (EDT)
Subj: Clipboard Proposal (Part 1/2)

K-Windows Clipboard Proposal
============================

Concept: The clipboard is a versitile, dynamic storage buffer to contain
data of a variety of formats, including (but not limited to) graphics
and text. Because clipboard operations are initiated by the user, it
can generally be assumed that only one clipboard function will be taking
place at one time. This allows us to ignore the possibility of, for
example, two applications attempting to copy data to the clipboard at
the same time.

Storage medium: The clipboard should be efficient in both memory and
speed. A memory data module should be used as a reference for the
clipboard library. The data module should always exist as long as there
is infomation in the clipboard. Even though the memory data module will
always exist (if clipboard data is present), the actual text or graphics
data may optionally be stored on a temporary disk file for systems that
have limited memory. Information within the clipboard data module will
tell whether the clipboard data is saved on disk or is contained within
the clipboard data module. An environment variable will determine
whether the clipboard defaults to memory or to disk. Because not all
applications may have the environment variable set, it is important to
always use the clipboard data module in memory to reference whether the
clipboard is in memory or on disk, otherwise clipboard operation will
not work properly. Additionally, if the clipboard is attempting to
allocate RAM memory and fails, it should default to disk access.

Library: A library of functions should be created to facilitate very
easy use of the clipboard between applications. The following library
functions should be supported --

store_clip_text() - copy text to clipboard
get_clip_text() - copy clipboard text to program memory
store_clip_graphics() - copy on-screen graphics to clipboard
put_clip_graphics() - copy clipboard graphics to screen
clip_to_buffer() - load a k-windows buffer with clipboard graphics
buffer_to_clip() - copy k-windows buffer data to clipboard
load_clip_pals() - set palette registers to clipboard palettes
get_clip_pals() - copy clipboard palettes to program memory
get_clip_type() - returns type of clipboard data (text/graphics)
get_clip_info() - returns info about clipboard data (length, etc.)
destroy_clip() - clear the clipboard data (usually not used)


--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2147 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 4/7
Date    : 94/08/04  17:51:00

From: Joel Mathew Hegberg <JOELHEGBERG@delphi.com>
Date: Fri, 29 Jul 1994 01:00:44 -0400 (EDT)
Subj: Clipboard Proposal (Part 2/2)

Storage format of clipboard:

Offset Description
====== ===========
0 Type of data
1-4 Length of data (in bytes)
5-8 X-Size
9-12 Y-Size
{Palette data -- if needed}
Clipboard data (text/graphics)

Note: If the type byte in the clipboard data module is set to the value
of 255 ($FF), the clipboard data is stored on disk.

Types of data supported in this proposal:

Type Description
==== ===========
0 16-color, no palette data, raw image format.
1 16-color, no palette data, RLE encoded format.
2 16-color, palette data, raw image format.
3 16-color, palette data, RLE encoded format.

4 256-color, no palette data, raw image format.
5 256-color, no palette data, RLE encoded format.
6 256-color, palette data, raw image format.
7 256-color, palette data, RLE encoded format.

8 Text (null-terminated).
9 K-Windows codes (objects).
10 Black & White image data (0=black, 1=white)
11 Black & White image data (0=white, 1=black)

Note that the library functions will choose the most efficient method of
storage for image data (raw or RLE encoded) as well as querying the
screen for the number of colors, so the technical details of choosing a
good "type" will be hidden from the programmer via the library. The
programmer will be able to explicitely choose raw or RLE, however, if he
so desires.

The proposed name for the clipboard data module is "k_clipboard".
The name "clipboard" should not be used as it is a common computer term
and it may conflict with another module already named "clipboard". If
the clipboard data file is stored on disk, the proposed pathname is
"/dd/SYS/.k_clipboard". (Note that this is an 'invisible' file.)


--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2148 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 5/7
Date    : 94/08/04  17:54:00

From: "Boisy G. Pitre" <boisy@os9er.waukee.ia.us>
Date: Fri, 29 Jul 94 07:09:21 -0500
Subj: Re: Clipboard Proposal

Thanks for the effort on this Joel! It looks pretty thorough
and easy to use.

Just curious... I was thinking about the technique used to select
text on the screen... does anyone have any nifty ideas on how this
might be done? Obviously, one will need to know the location where
the mouse was clicked, and will also need to track the mouse while
the button is down, and where it is released.

The big challenge I see is how to select the text while tracking
the mouse. I would expect the text to be highlighted as the mouse
passes over it. Thoughts anyone?

From: Eddie Kuns <EKUNS@zodiac.rutgers.edu>
Date: Mon, 01 Aug 1994 17:20:07 -0400 (EDT)
Subj: Re: Clipboard Proposal

Some thoughts...

A given utility might want to clip two or more different things at once.
It might be nice to be able to have multiple clips. A clip directory
or something. Say, I want to simultaneously clip some text from the
screen and an image associated with it? Dunno.

Maybe associate a clip number with each clip?

How about this:

clipid = store_clip_text();

where clipid is a short int specifying the clip number. So one could delete
a specific clip without emptying the entire clipboard.

And then something to empty the clipboard. Another function to specify
if each call to store a clip of something created a new clip, or
overwrote the previous.

And a possible error would be "Clipboard full" if a utility selected
the "each clip does not overwrite the previous" mode.

Also, a useful feature would be if an application using the clipboard could
put some identifying info into the clipboard to say who clipped this stuff.
Application name, user ID (name?), computer name? ... I'm not sure what
identifying info is useful, but some is.

clip_whoami()

to find out who made the clip, maybe and

clip_iam()

to identify yourself?


--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2149 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 6/7
Date    : 94/08/04  17:57:00

From: HAWKSOFT@delphi.com
Date: Mon, 01 Aug 1994 21:24:23 -0400 (EDT)
Subj: AHA! eye 'C' !!

JJ!!!

It actually works!!!! All I needed (so far) was to initialize the cio
trap vector, link cgfx.l and cio.l and it works fine!!!

Now I need the newest cgfx.l. The one I have is the one that came with the
MM/1. It only has the Coco-type drawing commands. Isn't there on for the
menus, and buttons, and window types??? If someone can point me to it, I
can really do some fancy graphics!!!

Thanks for your input so far!

From: Joel Mathew Hegberg <JOELHEGBERG@delphi.com>
Date: Mon, 01 Aug 1994 23:48:09 -0400 (EDT)
Subj: Clipboard

Ken,

> But I'm sorry -- I just cannot support creation of such a facility in a
> manner that is restricted to a specific screen driver (K-Windows).
> Please review your proposal, and try to remove (or generalize) all of the
> K-Windows specific stuff. Aside from the K-W limitations, your proposal
> holds great potential, and appears quite well thought-out.

<smile>... Let me read to you the note I scribbled down on the top of my
sheet of notes a couple nights ago... "cliplib.l for non-kwin systems as
well..." (in very messy handwriting).

I will release the text-clipping routines for non-kwindows specific
systems. There will then be 2 libraries... 1 for K-Windows (which
includes text clipping), and 1 for just text clipping. All specifics as
to how graphics data should be stored will be released, but of course I
cannot write/test clipboard functions for other graphics systems.

I'm rethinking a few parts of the proposal as I write it. I've added a
'sound' type for clipboard data, which distiguishes between mono/stereo,
and stores the frequecy data. I'm also thinking about forgetting RLE
encoding inside the clipboard for graphics... how often would one clip
something that large, and if they do, the worst that could happen is the
clipboard would have to allocate the memory on the hard drive due to
lack of RAM (which it is currently smart enough to do).

Any other thoughts?



--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2150 *MM1 TECH Echo*
To      : All
From    : Colin Mckay
Subject : Mushroom 04Aug94 7/7
Date    : 94/08/04  18:01:00

From: Colin McKay <cmckay@northx.isis.org>
Date: Wed, 3 Aug 1994 09:46:15 -0400
Subj: Fidonet

Does anybody have a problem if I start echoing the MM/1 Developers
conference to the MM1_TECH echo on Fidonet?

There are a number of people there who would benefit greatly from
this (such as Stephen Seneker), and the traffic there is pretty light.

I will also echo messages back.

From: Warren Hrach <warren@ocnbeach.jd.com>
Date: Wed, 3 Aug 94 11:10:26 -0700
Subj: Re: Fidonet

On Wed, 3 Aug 1994 11:09:38 -0500, MM1 Developer Grou wrote:
> From: Colin McKay <cmckay@northx.isis.org>
> Date: Wed, 3 Aug 1994 09:46:15 -0400
> Subj: Fidonet
>
> Does anybody have a problem if I start echoing the MM/1 Developers
> conference to the MM1_TECH echo on Fidonet?
>
> There are a number of people there who would benefit greatly from
> this (such as Stephen Seneker), and the traffic there is pretty light.
>
> I will also echo messages back.
>
> TTYL. Colin.

Colin,
As the moderator of the MM1_TECH moderator I like the idea. However
it is up to the rest on the MM/1 developers list.
However you must make sure the reply thru your system does not create
any problems on either the Fido echo or the MM/1 developers list. So give
it a try and we will see.

From: Eddie Kuns <EKUNS@zodiac.rutgers.edu>
Date: Thu, 04 Aug 1994 12:04:25 -0400 (EDT)
Subj: Re: Clipboard stuff

]Multiple clipping from the "sending" application seems simple enough, but
]handling the case of multiple items in the clipboard on the "receiving" end
]sounds a little complex, that's all.

Whoops, that's right! Nevermind!

<EOF>


--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)


Public Message 
Message # 2161 *MM1 TECH Echo*
To      : David Graham
From    : Tim Jones
Subject : Booting from Maxtor HD?
Date    : 94/08/04  22:40:00

 DG> The boot rom usually runs through three attempts to boot before the
 DG> hard drive spins up, is there anything that can be done about this?? 
 
David, check the docs for the drive and disable the wait-spin function so the
drive spins up when the power is turned on and not when it is touched by the
scsi buss. Just a thought.
 
Tim

--- Maximus/2 2.01wb
 * Origin: If I Only Had 1/MM - [512-280-6578] (1:382/107)


Public Message 
Message # 2172 *MM1 TECH Echo*
To      : Ken Scales
From    : David Graham
Subject : Maxcount values for HD's
Date    : 94/08/04  11:26:00

Ken, you are quite right about the need to decrease the maxcount.
 
I thought I'd done that already, and you can be assured it is being 
done even as we type..... ;)

--- WILDMAIL!/WC v4.00h
 * Origin: The Sierra Hotel! BBS ~ Enid, Oklahoma ~  (1:19/47.0)


Public Message 
Message # 2173 *MM1 TECH Echo*
To      : Ken Scales
From    : David Graham
Subject : KWindows - Windio52
Date    : 94/08/04  11:32:00

-> From what I am aware of (David, please tell me if I'm wrong), Windio5
-> mostly contains the following:
->  - sound drivers compatible with the 68340 board
->  - fixes for several of the bugs introduced in V50 and V51, which
->    were created to support the 68340 board.
 
That is correct to the best of my knowledge Ken.   The Kwindows
'development team' is still VERY VERY POOR about talking to the
marketing team and the applications developers.   Kevin never sends
me copies of any changes done, and has been promising me documentation
for over 8 months now.....

--- WILDMAIL!/WC v4.00h
 * Origin: The Sierra Hotel! BBS ~ Enid, Oklahoma ~  (1:19/47.0)


Public Message 
Message # 2174 *MM1 TECH Echo*
To      : Calvin Dodge
From    : David Graham
Subject : ERROR #000:104??
Date    : 94/08/04  11:34:00

I wish I could be more specific.  I'm trying to track down a customers
problem, and he can't remember what he was running.  And since I've
received the machine back for trouble shooting and installation of
serial ports, I've not been able to duplicate the problem.
 
      David

--- WILDMAIL!/WC v4.00h
 * Origin: The Sierra Hotel! BBS ~ Enid, Oklahoma ~  (1:19/47.0)

=*= FIDO ECHO MESSAGES MENU =*=