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 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 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 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 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" 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 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 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. ... 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 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 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 > 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 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! --- 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 =*=