textfiles/messages/ALANWESTON/1990/os907_20.txt

869 lines
28 KiB
Plaintext

30755 16-JUL 22:40 Utilities
Utilities
From: OS9BERT To: ZACKSESSIONS
Thanks for the info on where to find DEARC - it should be posted somewhere on
Delphi for those of us who don't know where to look!
Bert Schneider
-*-
30757 16-JUL 23:06 Utilities
RE: Utilities (Re: Msg 30755)
From: GREGL To: OS9BERT
Bert,
I just edited the name of the group to "3D GRAPHICS PLOTTER" to fix the typo
and added the keywords DEARC and ARCHIVE to it. Hopefully that will make it a
little easier to find it again in the future.
-- Greg
-*-
30790 19-JUL 18:49 Utilities
RE: Utilities (Re: Msg 30757)
From: OS9BERT To: GREGL
Thanks - I tried to compile it last night but had a few errors in it and it
would not compile. I need to take a look at the code - perhaps there is an
extra space, line, or padded character from the downloading process that I need
to get rid of.
Bert Schneider
-*-
End of Thread.
-*-
30756 16-JUL 23:02 General Information
Eliminator
From: COLINMCKAY To: OS9UGVP (NR)
Hi, Bruce.
Having a few problems with my ST-4096 hard drive, and my Eliminator/WD 1002
system.
Specifically, when copying files to the hard drive, various parts of it start
to get messed up, as you can see below. The SRC directory has had its info
corrupted. After creating the directory structure, the structure is intact.
However, once I start copying files to the CMDS directory, this starts to
happen. This also affects the commands directory structure, seemingly at
random.
Directory of /hd
User # Last Modified Attributes Sector File Size File Name
------ ------------- ---------- ------ --------- ----------
0 90/07/16 2234 d-ewrewr 97 360 CMDS
0 90/07/16 2234 d-ewrewr B8 40 DEFS
0 90/07/16 2234 d-ewrewr D9 40 GFX
0 90/07/16 2234 d-ewrewr FA 40 LIB
0 90/07/16 2234 d-ewrewr 11B 40 MSC
6D0D 62/00/13 6599 -se--e-r 13C 65737320 SRC <<<<<<<<<<<<<
0 90/07/16 2234 d-ewrewr 15D 40 SYS
0 90/07/16 2234 d-ewrewr 17E 40 TXT
0 90/07/16 2234 d-ewrewr 19F 40 USR
This is the output from DMODE:
nam=HD mgr=RBF ddr=WDDisk
hpn=07 hpa=FF70 drv=00 stp=0F typ=82 dns=01 cyl=03FF sid=09
vfy=00 sct=0020 t0s=0020 ilv=13 sas=20 wpc=FF ofs=0001 rwc=FFFF
Using CYL=$400 results in error 241 Sector Error.
Formatting the drive with ECC enabled and doing a physical verify reports
no errors.
Do you think I have a flaky hard drive, or am I overlooking something
obvious?
Thanks. Colin McKay.
-*-
30758 16-JUL 23:27 Programmers Den
RE: Speeding up the coco3 (Re: Msg 30705)
From: TIMKOONCE To: NES
That simulator of yours sounds interesting. I don't think I've ever heard of an
in-circuit-emulator that runs faster than the real thing. For myself, I'm
looking at an MM1 sometime.
- Tim
-*-
30759 16-JUL 23:30 General Information
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30726)
From: TIMKOONCE To: RAGTIMER
Actually, I can see good reason for having one sprite supported, for the mouse
cursor. Since updating the mouse cursor is such a common event in all GUI's, it
seems reasonable to have some hardware support for it. I agree though, that it's
impossible to have enough sprites, so it's better to not try making them
available for game stuff. Plus, with modern beefy processors, there's really
not much need. I suspect that the newer dedicated video machines don't bother,
since they have the raw CPU power to do it manually, and we all know that
software is cheaper than hardware to mass-produce! <grin>
- Tim
-*-
30785 19-JUL 01:01 General Information
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30759)
From: RAGTIMER To: TIMKOONCE (NR)
Yeah, to MASS-produce. It's that first one that costs big bucks and slipped
schedules (grin?). You're dead right about one sprite for the mouse. But also
right that even the Coco doesn't lose much in pushing it around. Actually I
think the arcade games do still use a lot of special hardware -- even 68030s
can't make wine out of water, let alone walk on the stuff.
Also, special chips can be mass-produced failry cheap, maybe for less than the
difference between a 68030 and a plain old 68000. Certainly less than a 68040!
--mike k
-*-
End of Thread.
-*-
30760 16-JUL 23:31 General Information
RE: Groups (Re: Msg 30732)
From: TIMKOONCE To: BRIANWHITE (NR)
Hmmm... No, I hadn't actually considered "TIMK". Oh, well. Too late now, I
guess. <grin>
- Tim K <grin>
-*-
30761 16-JUL 23:36 Graphics & Music
RE: Who did "VEFIO" ? (Re: Msg 30677)
From: TIMKOONCE To: THEFERRET
Well, even Kevin Darling admits that Max9 leaves something to be desired. If
you're working in a window screen, then it's not at all hard to "roll your own"
routines for saving/loading screens. Once you've written one, it's easy to
extend it to handle Squashed VEF and MGE formats, which is much harder to do it
you use VEFIO. Tell me what exactly you're trying to do (i.e. "load Squashed
VEF pictures into a window screen"), and I can give you some pointers. It's
really much easier than it seems at first glance.
- Tim
-*-
30766 17-JUL 02:21 Graphics & Music
RE: Who did "VEFIO" ? (Re: Msg 30761)
From: THEFERRET To: TIMKOONCE (NR)
I need a routine that saves and loades VEF files to the screen it is run on.
this is to say, ANY screen (graphic, of course).
Phil
-*-
End of Thread.
-*-
30762 16-JUL 23:41 General Information
RE: GFX2 & MM/1 (Re: Msg 30680)
From: TIMKOONCE To: COLINMCKAY
Well, depending on how "big" the GIF pix were, I find 1sec decode times quite
reasonable. On my CoCo, I can load some GIF pix in about 10 seconds. Given
enough registers (i.e. a 68070), and being able to scrap the dithering routines
would give a 2-fold increase right there. Factor in the 5-times faster clock
rate, and 1sec sounds about right. Of course, for big pix, I'd expect something
a little slower, say, 5 seconds <grin>. I can't wait to get hold of one.
- Tim
-*-
30763 16-JUL 23:54 General Information
RE: One Megabyte CoCo-3 !! (Re: Msg 30728)
From: TIMKOONCE To: GREGL
Well, Greg, CIS is pretty well-connected mail-wise. They're connected
indirectly to the Internet, which gives electronic mail access to almost every
university and electronics/computer company in the world. If Delphi were
connected in such a way, Delphi <-> CIS mail would be easy. Seems to me the
fault is Delphi's, not CIS's.
- Tim K
-*-
30784 19-JUL 00:55 General Information
RE: One Megabyte CoCo-3 !! (Re: Msg 30728)
From: RAGTIMER To: GREGL
Dumb -- it would have stimulated more usage of BOTH services to have them
connected for Email. The open-systems approach of early Apple, not the closed
approach of early Tandy Coco. Which was more successful, need I ask?
-*-
End of Thread.
-*-
30764 17-JUL 00:02 General Information
RE: CP (Re: Msg 30747)
From: TIMKOONCE To: KNOT1
Jamie,
The "del" command is nothing more or less than a user interface to I$Delete.
It does nothing that I$Delete doesn't do. Most of the basic OS9 utilities just
call the corresponding system call, and little else.
List - I$WritLn
Merge - I$Write
Del - I$Delete
You get the idea.
- Tim
-*-
30775 18-JUL 01:48 General Information
RE: CP (Re: Msg 30764)
From: KNOT1 To: TIMKOONCE (NR)
Tim,
Yea, that's what I figured. Just wanted to be _certain_.
-Jamie (KNOT1)-
-*-
End of Thread.
-*-
30765 17-JUL 00:19 General Information
RE: [DShell+ 2.1 (Re: Msg 30708)
From: TIMKOONCE To: DBEARISTO
The biggest changes from the "old" shell to Shell+ that I use are:
- Settable prompt. I have my prompt set to include the current directory and
window, which makes it much easier to keep track of things.
- Shell+ recognizes "cd" to change directories as well as "chd". Since I use
Unix a lot, being able to type "cd" either place is a great convenience.
- Wildcarding. If you want to delete all the ".c" files in your directory,
you can type ":del *.c" rather than "del file1.c file2.c file3.c file4.c". Very
convenient at times.
- Tim K
-*-
30767 17-JUL 17:25 Device Drivers
RE: COCO2 WORD PROCESSORS! (Re: Msg 30749)
From: TRIX To: GREGL
Aw, have a heart. I actually like WordStar. They made a fairly good stab at it
with ScreenStar (better than I could've anyway). I guess it's true what they
say about everybody's first editor usually being their favorite. I'm still
looking for a word processor/text editor that can do columner block operations,
but I guess that's something I'll just have to hold my breath for.
-John.
-*-
30770 17-JUL 20:12 Device Drivers
RE: COCO2 WORD PROCESSORS! (Re: Msg 30767)
From: GREGL To: TRIX
John,
I know what you mean. Many people actually do like WordStar and the command
set used by it. I personally don't like having to learn all those cryptic
commands. When I want to change a word or part of a word from uppercase to
lowercase (or vice versa) I select Menu/Utilities/Potpouri and CaseSwitch. Or if
I use a particular command often, I can map it to a single keystroke. I like
this method because it puts me in control and I can have the keyboard mapped
several different ways, depending on what I'm doing.
-- Greg
-*-
End of Thread.
-*-
30768 17-JUL 17:27 Patches
RE: Dynacalc Patches (Re: Msg 30721)
From: TRIX To: OS9BERT
Take heart, you're not the ONLY OS-9 people in Colorado. Let's not forget Ron
Bihler, the auther of RiBBS!
-John.
-*-
30791 19-JUL 18:50 Patches
RE: Dynacalc Patches (Re: Msg 30768)
From: OS9BERT To: TRIX
Does he live in Denver? Where does he live!!!
-*-
30792 19-JUL 21:44 Patches
RE: Dynacalc Patches (Re: Msg 30791)
From: TRIX To: OS9BERT (NR)
I'm not sure WHERE he lives. I think it's in Aurora but I'm not sure. The # at
RiBBS HQ (his BBS) is (303)343-6707.
-John.
-*-
End of Thread.
-*-
30769 17-JUL 18:19 Programmers Den
Problems with G/P buffers...
From: DODGECOLT To: ALL
I have been playing with get/put buffers for my editor (Ed), but I have run into
a problem- whenever I try to map in/out a buffer larger than 8k, I will get a
'Boundary' (210) error. It led to some very strange crashes until I spotted it,
and I can find no other reason for it besides a bug in WindInt. Anyone have any
ideas?
-Mike
-*-
30781 18-JUL 22:17 Programmers Den
RE: Problems with G/P buffers... (Re: Msg 30769)
From: XLIONX To: DODGECOLT
Howdy Mike,
In the original Level 2 docs "OS9 Windowing System" page 3-7. Paragraph 2:
"OS-9 allocates memory for the GET/PUT buffers in 8K blocks that
are then divided into the different GET/PUT buffers. Buffers
are divided into buffer groups. ETC....."
Sounds like you are at a standoff with the system. Try breaking your blocks up
more (???).
I don't know, mabey that would work.
Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708) 428-8445)
XLIONX (DELPHI) mwf@SANDV
-*-
30800 20-JUL 19:17 Programmers Den
RE: Problems with G/P buffers... (Re: Msg 30781)
From: DODGECOLT To: XLIONX (NR)
Well, _THAT_ approach didn't work too well either! There are problems when you
try bouncing chars around between buffers, and the code gets hairy. I think I
will have to go back to the old linked-list approach... At least that will be
easier to port to OSK, anyway!
-Mike
-*-
End of Thread.
-*-
30771 17-JUL 22:07 General Information
Atlanta Cocofest
From: DWHILL To: ALL
Everyone take note that in several advertisements in the latest RAINBOW, the
CORRECT location for the convention is NORTHLAKE Holiday Inn, not Lakewood!
(There's a Southlake, too, and that's not right either!)
See ya'll there this fall!
--Damon
-*-
30772 17-JUL 22:55 Patches
Level II 'C' Compiler
From: SPIKE134 To: ALL
Is there a way to use the Level I 'C' Compiler on my Level II OS9? I'am in the
process of purchasing the OS9 development system, will this allow me to use the
Level I version?
-*-
30776 18-JUL 01:49 Patches
RE: Level II 'C' Compiler (Re: Msg 30772)
From: KNOT1 To: SPIKE134
Brian,
I use the Level I 'C' compiler on my Level II system all the time. What drives
do you have? Number of floppies/hard drives, and thier descriptors (e.g. "/D0",
"/D1", "/H0", ect...). The compiler requires that you have drives called "/D0"
and "/D1".
-Jamie (KNOT1)-
-*-
30779 18-JUL 21:27 Patches
RE: Level II 'C' Compiler (Re: Msg 30772)
From: DWHILL To: SPIKE134
The C compiler works very well under level II, though there are a couple of
patches to change a couple of things for floppy/hard disk operation. I've
forgotten myself, it's been a long while, but you should be able to find the
related text file in the database, probably under programming. Use the "search"
function. Our resident C guru, GREGL, probably knows all this by heart...
--Damon
-*-
End of Thread.
-*-
30773 18-JUL 01:44 General Information
RE: os9 pascal (Re: Msg 30422)
From: GENEDEAL To: XLIONX
Mark,
Got it! The mystery is to send the desired attributes in hex to the file you
wish to open (ex $0202 ). This is not obvious until you do it...then read the
manual page. Hindsight=20/20. I can relate to the 'C' situation but because the
project I'm working . By the way isn't it possible to use the assembler to
compile a machine code program from the pcode? Oh well I don't even have the
level 2 asm package. I'll have to add that to my list.
Thanks
Gene Deal
-*-
30778 18-JUL 21:16 General Information
RE: os9 pascal (Re: Msg 30773)
From: XLIONX To: GENEDEAL (NR)
Howdy Gene
If you can find a copy of LEVEL-1 os9, the assembler found there works just
fine. You use PASCALT to Translate your PCODEF file into an assembly source
file. Try some small example programs (ie: Hello World, 1+1*1/1=?, etc...) then
examine the source file. This can be quite informative on how os9 pascal does
its thing. It is interesting that because of the way Microware C & pascal
arrange their register set for a syscall (aka basic09-syscall/C-os9 calls)
DIFFERENTLY, you can't use a common library set to support both <sigh>.
Well, good luck as allways and keep hackin' away!
Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708) 428-8445)
XLIONX (DELPHI) mwf@SANDV
-*-
30789 19-JUL 01:37 General Information
RE: os9 pascal (Re: Msg 30778)
From: RAGTIMER To: XLIONX
Say Mark, were you at the Glenside Coco Club meeting last week? There was a
lean, trim guy introudced himself as "employed in the video game industry" and
running a BBS. Was that you? Would be nice to talk games & pins sometime --
mike knudsen
-*-
30794 20-JUL 00:23 General Information
RE: os9 pascal (Re: Msg 30789)
From: XLIONX To: RAGTIMER (NR)
Nope, That was probably Jeff Chapin (Tangerine (DELPHI)). He is the SYSOP for
Pinball Haven allong with Tony Padroza (Co-SYSOP). I am just the humble SIGOp
for the Programmers SIG we are trying to get going.
Hey, that reminds me...I talked to Ed Hathaway about some ideas for Umuse. You
probably get enough from others so let me know if you are interested in some
"neat" options (my opinion). It would lend some flex to your program when
someone asks "Why didn't you make a function to control this MIDI B/W (B/W =
Bell or Whistle)".
Jeff would LOVE to talk shop with ya. Give us a call!
-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS (708)
428-8445) -XLIONX (DELPHI) -mwf@SANDV
-*-
End of Thread.
-*-
30774 18-JUL 01:46 General Information
Your 2 minute C lesson for today...
From: RICKADAMS To: TIMKIENTZLE (NR)
Okay, what's wrong with this statement:
#define STUFF "/d0/SYS/WHATEVER/STUFF"
Uh huh. It's self-referencing. The compiler blows up with "***STACK OVERFLOW**
*". Even though it's in quotes. To fix it, I changed the first STUFF to
STUFFDIR. (The text involved has been modified slightly from the original...)
Now try this one:
#include whatever.h
Okay, you need either <> or "" around it. It was supposed to have "".
Unfortunately, the compiler doesn't say "You forgot the quotes, stupid."
Noooooo. Instead, it gives "Bad code in intermediate file: 75". Probably "75"
is a filename derived from the ASCII value of the first character in the ".h"
filename, and it croaks when it can't create a file by that name. (Did you know
that OS9 complains mightily when asked to create a file whose name begins with a
dot or a numeric character? Interesting, no?)
I thought you'd find those interesting; I sure did! Each of those cost me about
a day's head-scratching... ::grin::
-*-
30777 18-JUL 19:33 General Information
lotto's
From: FROGLEGS To: ALL
I am just interested to know if there is a program on file that calculates lotto
numbers. Or is there an easy way to have basic09 compare numbers so that I can
write my own program.
-*-
30780 18-JUL 22:02 General Information
RE: Shell+ (Re: Msg 30746)
From: XLIONX To: MIKEHAALAND
Me next...
While I am nothing but a humble home-brew programer <grin>, I do believe that
some standards might be set up for the NEAR future.
I have noticed more programers going for the extra memory (in several ways).
Extra meaning outside the NORMAL "64k" workspace that in reality is "56k" or
less. Now, if you can figure out how to break the "Workspace Barrier", then
mabey youz guyz could agree on a potiental limit so future Shell+ or Shell?
writers could work with YOU (the users/programmers/creators-of-BIG-PROGRAMS) so
we (the other-users/mostly-confused/easily-baffeled-software-purchasers) can
stop wondering WHY the wonderful program that ran so well at RBFest turns our
computers into a sparklie generator.
I have written basic09 programs large enough to encounter "The End of Memory"
and have had to break them down even farther into more pack'd modules. OSTerm
uses this method very well as does Multi-Vue. Pascals can create a program in
PCODE that can be up to EIGHT MEGABYTES in size. (Swapcode interpreter)
I don't mean to imply that you are not aware of these things but, why push EVERY
limit and not expect problems? What happens when Shell+ 3.0 comes out and
exceeds 8K all by it's lonesome (ya never know)?
Perhaps a better method of memory testing needs be found so crashes can be
avoided? (preliminary memory size check)
I could be wrong but...when you chain to a new module (ie EX basic09) shouldn't
you get the memory from the original Shell back (in that work space)???
Well, I've run out of ideas for now and my four year old is calling.
Mike, I look forward to purchasing MVCanvas when my komputer-kitty has more $$$
in it ];->. I hear it's quite the program (I missed any demos at Chicago :-( ).
Catch you later,
Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708) 428-8445)
XLIONX (DELPHI) mwf@SANDV
-*-
30786 19-JUL 01:09 General Information
RE: Shell+ (Re: Msg 30730)
From: RAGTIMER To: BRIANWHITE (NR)
You're right, SHell+ can't waste memory that way, and is a big win with COPY,
etc. Actually, users should zap the module headers of COPY etc. to use 8K. And
if you have 1 Meg, zap it to 40K, which I use a lot anyway. (Been too lazy to
zap 'em yet, tho).
I wonder if it's only C programs with malloc(), or any program that links in
other modules or maps grafix buffers, that gets in trouble with the #31 addition
in Shell+.
I agree, SHell+ should have an option to switch that on/off. --mike k
-*-
30787 19-JUL 01:16 General Information
RE: Shell+ (Re: Msg 30746)
From: RAGTIMER To: MIKEHAALAND
Well, both of us Viking Mikes have a little bias here -- it was OUR application
programs that got busted by that new Shell+. But I hope we aren't the last guys
to write big applications that use all 64K in special ways, so MORE programs are
going to show up that don't appreciate that little 8K "gift". So Shell+ needs to
be fixed. And users who care shoudld zap their utility module headers up to 8K
(or 40K for COPY). --mike knudsen
-*-
30788 19-JUL 01:28 General Information
RE: Shell+ (Re: Msg 30780)
From: RAGTIMER To: XLIONX
I agree in principal the Sell hackers should talk to the heavy programmers. In
this case, I think I could have warned them what would happen (I *think* I tried
a #8K to Ultimuse-3 once). What happens is kind of subtle:
It isn't all the fancy funny things Umuse3 does with subroutine modules and
Put/Get buffers that causes trouble. It's this: Umuse3 expects only 5K data
memory in its header. All those fancy things demand full 8K blocks so they go
into other blocks. But to put a point-n-shoot directory of files on the screen,
I have to allocate (malloc()) some temporary memory, about 1.5K. That has to
come out of the remaining 3K of the original data block. C's malloc() routine
will NOT find memory within the heade.@X6lo,X:-onRJ$]Z$Z+W-l[HQIQUA5Rmount. Since Shell+ pushes that to 8K, there ain't nothin' left for the
directory to get allocated.
Oops, better disregard the above -- it WAS the subroutine modules that refused
to link in uder Shell+. I'll have to think about this one some more. Also try
to re-remember what malloc() will & won't do. I may also be confused by the case
where someone MERGEd some utilities with Umuse3 and put it over a block
boundary.... mike k
-*-
30793 20-JUL 00:14 General Information
RE: Shell+ (Re: Msg 30788)
From: XLIONX To: RAGTIMER (NR)
Howdy Mike ];->
I LOVE to kick the hornets nest as much as the next guy but, I "was" working on
a game control program for Star Fleet Battles (huge board game) and I needed a
program to generate large numbers of ships to test it. I used a double-linked
data list method (pointer->previous_ship , pointer->next_ship). To realy test
the beastie, I had it do this:
while (pointer->next_ship = (struct ship *) malloc(sizeof(struct ship)))
pointer->next_ship->previous_ship = this_ship;
while the system will give us memory, assign the current ships pointer to the
next ship the address of this new block. assign the assign the new block (ship)
previous_pointer to point to this ship (double link) When I ran this it reported
"generated 215 ships".
When I ran "Shipgen #20k" it reported "generated 115 ships".
I too have had clashes with malloc and I think I even understand what is going
on now (I said "I THINK"). Starkle, starkle little twink - who the heck I am I
think! <grin>
-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS (708)
428-8445) -XLIONX (DELPHI) -mwf@SANDV
-*-
End of Thread.
-*-
30783 18-JUL 23:19 General Information
RE: No FORMAT after 1-Meg upgrade! (Re: Msg 30750)
From: RADARBUZZ To: MRGOOD (NR)
Hugo,
Well, I knew I should have not ignored all that stuff about the BLOB that I
had read here. I figured since I didn't have it then it wasn't important. Silly
me <grin>. Oh well, I wonder if you recall just how you rearranged your boot
list to get rid of the format problem you had? Did the order of RBF/CC3Disk/dd
fix the problem? Anyway, if my new GIME fixes this problem, then the old GIME
will be shaking hands with Mr. Hammer <Big grin>!
-Jeff
-*-
30795 20-JUL 01:08 General Information
SASI Driver
From: KSCALES To: ALL
To those of you who have downloaded, or are planning to download, my Disto SASI
Driver from the New Uploads area:
I plan to upload a modified version of the driver this weekend which contains
code to prevent the problem some users have encountered if their system is
configured to load Grfdrv from the Hard Drive, rather than from the boot floppy.
It appears that Level 2 Version 2 OS-9 doesn't support the F$Sleep call when the
current active process is the System Process (as it is when loading Grfdrv).
<sigh> Fortunately, this will not impact the driver performance for 99.9% of
the normal drive usage. And it means that you should now be able to load
everything (including Grfdrv) from the HardtDrive, except for the kernal and
OS9Boot.
... /Ken
-*-
30796 20-JUL 02:35 Telcom
RE: OSTerm autodial (Re: Msg 30696)
From: BILLBEISSERT To: KMTHOMPSON (NR)
Kelly,
I haven't really used Autoterm recently as I have been involved with amateur
radio projects, looking for a new (different) house and also been on a short
vacation from a heavy work schedule. I remember that I found that 7E1 worked
best for me via Telenet as opposed to 8N1 as Delphi states but have never tried
7M1. It might be a good idea for someone to write an article that explains the
different settings and resultant *clashes* for people like me who don't know but
should. As far as Hayes VS Tandy protocols; I have always used Tandy and have
never had problems with it before. If I should continue to *fail* with Tandy
protocol I will resort to Hayes but if that fails too then you will be hearing
from me for help....BIGTIME!
Like I mentioned, I have fallen off the OS9 wagon for a while because I don't
have the time but will jump back on as soon as I get a chance. I'll keep your
number on file here in the event of an emergency(?) but will contact you via E-
Mail first to arrange a time and date. Thanks for the offer and response. 73 ---
Bill
-*-
30797 20-JUL 08:30 Patches
GSHELL+
From: AARONS To: ZACKSESSIONS
Help ! I recently downloaded gshell+ with XM and WIZ. I hope you can answer
a few questions.
1) There was no Ipatch file to patch the default startup window, I could use
MODPATCH, but I don't have the save utility. Can/must I use cobbler? Or is there
a utility in the utilities database that I'm over looking.
2) After downloading and after extracting <ipatch.doc> using ar, I get: ar:
file not archived or damaged error #001 - unconditional abort
Is there something wrong with gshellpat.ar or just ipatch.doc? Or is this normal
and everything is OK?
Thanks, AARONS
-*-
30799 20-JUL 18:08 Patches
RE: GSHELL+ (Re: Msg 30797)
From: ZACKSESSIONS To: AARONS (NR)
First of all, the error you are getting is relatively common, it occurs only
after all archive members have been extracted, so no problem, there.
To patch the startup window like the docs state how, you can use eithere dEd (a
fantastic disk editor) or there is a replacement save command. It is the Utils
lib I think, look for SAVE09.BAS. It is a DECB program written by Kevin Darling
which you need to download to a DECB formatted disk, run it under DECB, then
copy it to an OS9 disk. To do this last copy, you will need either a disk
converter program or RSDos (both, also available here for downloading.)
Zack
-*-
End of Thread.
-*-
30798 20-JUL 08:31 Utilities
Ed
From: AARONS To: DODGECOLT
On Ed I can't see the cusor. How do I change the colors ?
Thanks, AARONS
-*-
30801 20-JUL 19:19 Utilities
RE: Ed (Re: Msg 30798)
From: DODGECOLT To: AARONS (NR)
Version 1.6 doesn't directly let you change the colors. I assume you are in B
& W, thus your problem with the yellow cursor??? Perhaps if you tell me what you
DO see I can figure something out for you...
-Mike
-*-
End of Thread.
-*-
FORUM>Reply, Add, Read, "?" or Exit>