informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/messages/ALANWESTON/1990/os906_04.txt

1700 lines
67 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
29891 1-JUN 21:11 Grits & Gravy
RE: Hardware Problem (you might say) (Re: Msg 29883)
From: MINIFREAK To: OS9UGPRES (NR)
I agree with most everything you said. The funny thing about that is that it was
the Mercedes, Volvo, and BMW owners that gave me the most headaches. The guys
with the ten year old Hondas and Toyotas were a relative joy to work with, and
the Jag and Rolls owner were an absolute dream.
Yeah, I guess it's in every business. Look at the CoCo hard drive market last
year. The guy with the lowest price got the orders, quality be damned.
Randy
-*-
29892 1-JUN 21:17 Grits & Gravy
RE: Hardware Problem (you might say) (Re: Msg 29886)
From: MINIFREAK To: JIMREED
I pulled up a bigger soapbox than intended. 'nough said.
Ah, Lincoln. I've spent my time playing with the imported stuff; not too up on
the later American electrics. But, on the bigger Fords, they wired that chime to
both the seatbelt sensors, and the engine managment. I guess the first thing to
do is check to make sure the thing does actually have oil in it. :>
Randy
-*-
29906 2-JUN 10:51 Grits & Gravy
RE: Hardware Problem (you might say) (Re: Msg 29884)
From: DICKWHITE To: JIMREED
I am trying to imagine a Jim Reed standing at attention. Tough job.
-*-
End of Thread.
-*-
29893 1-JUN 22:32 General Information
KLE, IMS, Etc.
From: THEREB To: NES
Hi, NES! Sorry I haven't had much time to call The OverBoard; I've only called
two LD boards lately, and they've been The OverBoard and the Atlanta Compter
Society (I haven't called either much). Please tell me this: How did you get
an MM/1 to one of your club's meetings? Does it have something to do with how
close IMS is to Charlotte? I've been trying to get either Paul Ward or Kevin
Darling to bring one to Fayetteville and can't get a response. Anyhow. . .
Later The Reb
North Carolina Access HQ (919) 868-8431 300/1200 baud
II (919) 867-7152 300/1200/2400
III (919) 424-2895 300/1200
Supporting all computers including the CoCo and OS-9.
-*-
29894 1-JUN 22:42 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 29874)
From: MIKEHAALAND To: RAGTIMER (NR)
Yessir! My dealer is me. Grin. The address in the 1.0 manual is valid, as is
the PH number.
I like the idea of doing a sideways <landscaspe> dump. Night be fun to try.
If I can only get my hand on the docs for the CGP-220, I know I could finish the
driver for it.
MikeH
-*-
29921 3-JUN 00:39 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 29894)
From: JIMHARRISON To: MIKEHAALAND
Mike,
I have a CGP-220, plus the standard operation manual supplied by Tandy. If you
can't find one locally, I could send you mine (on loan, of course). I've saved
original boxes for a lot of my stuff, but not for that printer. Durn! But could
probably improvise a safe shipping container if pressed. Let me know - I sure
look forward to that driver . . .
Jim
P.S. I live in San Diego - not all THAT far from you. But haven't been to Las
Vegas in years, since my in-laws left there.
-*-
29943 4-JUN 01:13 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 29921)
From: MIKEHAALAND To: JIMHARRISON
Thanks for the offer! But I'm going to try to buy one. Anyone have one for
sale? Maybe Dave Myers has one? CGP-200 thatt is.
Mike
-*-
29952 5-JUN 00:34 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 29943)
From: JIMHARRISON To: MIKEHAALAND
Mike,
OK. If you change your mind (or can't find anyone to sell you a CGP-220) my
offer stands . . .
Dave Myers is probably your best bet now, since I imagine most people on this
SIG who have one will want to KEEP it now that your driver is on the horizon!
BTW, I found that it fits nicely into a Panasonic printer shipping carton.
Jim
-*-
End of Thread.
-*-
29895 1-JUN 22:46 General Information
RE: A new kitten in the house! (Re: Msg 29887)
From: ZACKSESSIONS To: EDDIEKUNS
Give 'em a little time. Unless they are totally incapatable, they will
eventually become "housemates". Of course, each will establish their own
"territory". Also, Sinbad is a good name for a male kitty. Isn't amazing how
much cat food a kitten can scarf up! Their belly just streches out about 2
inches on both sides!
Zack
-*-
29897 1-JUN 22:50 General Information
RE: A new kitten in the house! (Re: Msg 29895)
From: EDDIEKUNS To: ZACKSESSIONS
Hehehe ... the kitten thinks that a ping-pong ball is the world's greatest toy!
My other cat is mighty unhappy that the kitten is eating, playing, existing,
etc! Ah, we'll see how it ends up.
Eddie
-*-
29901 2-JUN 00:36 General Information
RE: A new kitten in the house! (Re: Msg 29897)
From: ZACKSESSIONS To: EDDIEKUNS
Kittys think that _anything_ is the world's greatest toy! That'ss the best thing
about Kittys!! Have fun!
Zack
ps, See you in Atlanta?
-*-
29902 2-JUN 01:56 General Information
RE: A new kitten in the house! (Re: Msg 29901)
From: EDDIEKUNS To: ZACKSESSIONS
I *hope* to make Atlanta! :)
Eddie
-*-
End of Thread.
-*-
29896 1-JUN 22:49 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29864)
From: GREGL To: EDDIEKUNS
Eddie,
According to what I have been told, the 'standard' is lax on a thorough
definition to allow the compiler to 'optimize' the generated code as best as
possible. Ok, so on the 6809 microprocesor it is best to use the auto-increment
instructions within the variable access, as in:
ldd ,x++
add ,x++
std [myvar],y
So we can live with that definition. The 6809 microprocessor is very
powerful and allows for addressing modes not found elsewhere. The 8086
microprocessor from Intel isn't nearly as slick and requires a lot of manual
labor for some of our 'slick tricks' that seem trivial to us.
The 8086 has very primitive stack operations; you can push and pull a word
at a time but you can't push all of the registers at once. There are no
auto-increment instructions unless you want to perform simple block moves. So
the same instructions on the 8086 are as follows:
mov ax,[myvar]
mov ax,[bp]
inc bp
add ax,[bp]
mov myvar,ax
Fine and dandy. But I would like to know just how incrementing the 'base
pointer' register at the bottom of the statement has any additional
optimizations than by placing the increment immediately after loading the
register with the variable. It doesn't make any sense to me.
-- Greg
-*-
29898 1-JUN 22:57 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29896)
From: EDDIEKUNS To: GREGL
Well, it was probably just a choice they made. You know, in a drunken meeting?
<Grin>
K&R probably should have said that for side affects to work, addition should
work left-to-right. (ie: they shouldn't have left it to the compiler writers)
I don't see why they didn't define it more completely. They deliberately chose
to leave parts of precidence to the compiler writers knowing that it would make
operations using side affects uglier to code portably than they could have been.
<Sigh> Perhaps they had a good reason. I don't know. I think the operation of
something like value = *(ptr++) << 8 + *(ptr++); is perfectly obvious and should
work on every machine EVEN IF the code can't be as optimized. I would rather
have *functional* code than optimized code! <Grin>
Eddie
-*-
29900 1-JUN 23:04 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29873)
From: GREGL To: TIMKOONCE
Tim,
The arrangement of auto-increments is undefined by the ANSI-standard and is
left to the implementation of the compiler. Therefore some compilers would
perform the increment as follows:
ldx ptr,y
pshs x
leax 2,x
pshs x
bsr function
That, in my point of view, is the proper treatment of the source. Other
compilers would perform the logic a little differently:
ldx ptr,y
pshs x
pshs x
leax 2,x
bsr function
The code above is generated by the ANSI compiler I'm using. Needless to say,
it is obviously not what you expected. I'm sure there are some compilers that
will increment the x register after the function call. But that could worse than
incrementing it after both variable accesses and before the function call. If
the variable is global then it will at least be "correct" within the function
itself so it would receive only one bad variable rather than two. Of course
either could prove fatal.
Don't get me wrong; I'm not trying to harp on the fact that my code is in
anyway correct and the compiler is wrong. However the code generated should be
intuitive. In other words, auto-increments should take effect immediately upon
accessing the variable and not one byte later. Leaving anything to the
discretion of the compiler is bad news and is guaranteed to be incompatible. In
its simplest terms, it's times like this that I usually revert to inline
assembly. At least the assembler does what I tell it to do. <grin>
-- Greg
-*-
29914 2-JUN 17:38 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29876)
From: GREGL To: RAGTIMER (NR)
Mike,
That's precisely the problem! If I were dealing with Motorola conventions I
could just declare the value as a long integer and be done with it.
Unfortunately, converting from a Motorola model to an Intel model is bound to be
inefficient. After all, Intel is doubly backwards. As I recall a value sitting
in memory as 01020304h will be treated as the value 04030201h. Then again, it
might be 02010403h - depending on the reference. Besides all that, I'm working
with the three-byte LSN values which are one byte short of being a complete long
integer.
-- Greg
-*-
End of Thread.
-*-
29899 1-JUN 23:03 General Information
Unlink
From: EDDIEKUNS To: OS9UGPRES (NR)
Wow. I just found out (the hard way!) that you can unlink a module that's
currently running!!! (I wanted to unlink KBCom enough times that when I quit it
would disappear from memory, but I ended up removing it from memory completely!)
Is there any way to prevent this?
Eddie
-*-
29903 2-JUN 10:02 General Information
RE: Unlink (Re: Msg 29899)
From: DODGECOLT To: EDDIEKUNS
Whoa! It isn't supposed to take it out of memory until the process is no longer
being used... Can you do this to other programs?
-Mike
-*-
29919 3-JUN 00:01 General Information
RE: Unlink (Re: Msg 29903)
From: EDDIEKUNS To: DODGECOLT
Well, the way OS-9 keeps track (evidently) of whether or not a program is being
used is by its link count. And if you manually decrement that to zero...
<wham!> You pull the rug out from under the program and if you're lucky it
crashes benevolently!
Eddie
-*-
29925 3-JUN 04:46 General Information
RE: Unlink (Re: Msg 29919)
From: DODGECOLT To: EDDIEKUNS
Ouch! Oh, Kevin? Kevin? Do you suppose that upgrade uncludes a fix for that
too?
-Mike
-*-
29937 3-JUN 22:36 General Information
RE: Unlink (Re: Msg 29925)
From: WJMOORE To: EDDIEKUNS
One of my programs in the database "WMODE" is actually 2 modules merged
together. The second module is a "data" module and can not be unlinked by the
command line. To unlink it, you must unlink the primary module "Wmode". This
gives you any ideas? - gri n
Warren
-*-
29944 4-JUN 02:22 General Information
RE: Unlink (Re: Msg 29937)
From: EDDIEKUNS To: WJMOORE
Well, right, when you 'load' in a module (either by running a program or by
'load' or 'nmload' -- ONLY the first module in the file is explicitly linked in
terms of having a non-zero link-count. ie: If you have a file full of merged
utils which you load into memory, then only the first util in the file has a
non-zero linkcount. And the block of utils won't be unlinked out of memory
until ALL utils have a linkcount of zero.
You see, any group of modules which is merged & loaded as one unit is also
mapped as one unit! If you link in one little descriptor from your OS9Boot,
you'd better be sure you have enough space for the ENTIRE OS9Boot file to be
mapped into your address space!!!
I was just surprised (tho not as much after I thought about it) that you could
remove a program from memory while it was running! I guess there are two ways
around this. 1) Don't allow a module's link-count to drop below 1 if it is
running. 2) Ignore the fact that a module has a link-count of 0 if it is
running, then let it go when it quits.
Of course, with 2) you probably have to protect against ANOTHER unlink, which
would give you a link count of -1!!!! "oops"
Eddie
-*-
End of Thread.
-*-
29905 2-JUN 10:47 General Information
Pictures Needed
From: DICKWHITE To: DALEP (NR)
Dale,
I missed the original message, but I suspect that you are looking for pictures
relative to the CoCo history. If so, I have talen some from time to time over
the last 10 (well maybe 8-9)years and know they are somewhere in this pile
called the basement. A basement is sort of like a solid landfill when material
is deposited in layers until totally filled up. Let me know what you are upto
and maybe I can turn archeologist and try to help. Dick
-*-
29907 2-JUN 11:18 Utilities
RE: 3 1/2" drive (Re: Msg 29851)
From: DICKWHITE To: OS9UGPRES (NR)
Actually, pulling pins in the drive cables was a standard Tandy developed fir
the Model I if memory serves so that dates to 1978 or 79 at the latest.
-*-
29908 2-JUN 15:42 General Information
MM1 Preview.
From: NES To: ALL
Hay, Reb lost your delphi name, but here the scoup on the MM1 demo. It was a
suprize to me when the MM1 people called me and ask to do the demo. but at the
upcomming meeting there will be a demo of the conplete system, with its New DOS
to the announce (I hope its os9), also a stereo sound and Graphics demo, And
also may have The Mv canvase for it ready.. Kevin Darling, Paul Ward are
supposted to be there. and maybe Zack Sessions. also will annouce the price of
it... when: June 7,1990 at 7:00 PM. where: The Belmont Center Located at the
conner of Parkwood Ave and Davidson St. in Charlotte NC. Would like to see those
who are close to charlotte make this meeting, to see this new machine in action.
For More Info call the OverBoard BBS (704)822-1337 24Hrs 300-2400 buads. -NES-
-*-
29920 3-JUN 00:02 General Information
RE: MM1 Preview. (Re: Msg 29908)
From: EDDIEKUNS To: NES
I hope someone takes notes and informs the rest of the world about this demo!
<Grin>
Eddie
-*-
29929 3-JUN 11:40 General Information
RE: MM1 Preview. (Re: Msg 29920)
From: NES To: EDDIEKUNS
Eddie, I'll have my pretty mug on video tape, also a transcript of the meeting
will be posted on delphi... I'll be uploading some digitized pic's of me and
some of the member, that I made with my home grown digitizer<Big Grin>.
Eric
-*-
End of Thread.
-*-
29909 2-JUN 15:45 General Information
MM1
From: NES To: ZACKSESSIONS
Zack, At the MM1 demo, Kevin Darling and Paul Ward are supposted to be there
hope to see you too. If you need directions or any thing else leave me a message
here or on the Overboard BBS. -NES-
-*-
29913 2-JUN 17:02 General Information
RE: MM1 (Re: Msg 29909)
From: ZACKSESSIONS To: NES
Please send me the particulars in EMail, ie, time, place, and directions.
Thanks!
Zack
-*-
End of Thread.
-*-
29910 2-JUN 16:06 General Information
RE: Circuit Cellar Ink (Re: Msg 29756)
From: OS9BERT To: 6809ER (NR)
Wow! It is stuff like that, that should make it in the pages of BYTE magazine,
MOTD, Circuit Cellar Ink, etc. Although BYTE has since become a large systems
magazine and not a hackers magazine anymore. I used a 6801 in a mobile robot a
friend and I built for our Masters Thesis. It was fun and easier than using
Intel-based chips.
Bert
-*-
29911 2-JUN 16:08 Users Group
RE: Advent (Re: Msg 29760)
From: OS9BERT To: EASYSINGLES (NR)
I'll look into it.
Bert Schneider
-*-
29912 2-JUN 16:10 General Information
RE: ROBOT ODYESSY I (Re: Msg 29780)
From: OS9BERT To: TJMARTIN (NR)
I agree. I have dissasembled the program only to find that the developer
changes the execution directory to /D0!!! A big mistake! I have managed to get
70% of the program running under and old type 0 window (/TERM). I'll keep you
informed of my progress. Right now I am multi-tasking (I have a big
to-do-list!) Take care Bert Schneider
-*-
29915 2-JUN 20:04 Tutorials & Education
COCOXT
From: WILLALHUFF To: ALL
JUST FORMATED MY 20MB HD WITH HYPERIO. COULD SOMEONE HELP ME WITH HINTS ON HOW
TO SET UP MY HD FOR OS9. I HAVE MULTIVIEW, TS WD, TSSPELL, HOME PUBLISHER.
-*-
29916 2-JUN 20:10 General Information
RE: Seagate ST-212 (Re: Msg 23018)
From: WILLALHUFF To: ALL
IS THE ST212 A CURRENT PIG? I JUST PUT A 3.5"HD IN MY OLD HALF HEIGHT TANDY
CASE. IT WORKD GREAT. THE DRIVE USES VERY LITTLE POWER AND THE OLD HALF HIGHT
FLOPPY WAS A PIG.
-*-
29917 2-JUN 20:14 General Information
RE: Seagate ST-212 (Re: Msg 23023)
From: WILLALHUFF To: ANTNIE (NR)
AN THE OLD HALF HEIGHTS? MY HD IS RUNNING IN MY OLD HALF HEIGHT CASE QUITE
WELL.
-*-
End of Thread.
-*-
29918 2-JUN 22:52 General Information
Thelda Product Announcement
From: OLDGROUCH To: ALL
Just a quick message reminding all that the product announcement for Sundog
System's "The Quest for Thelda" is now available over in the CoCo Sig under the
Product Reviews and Announcements Database and is ready for downloading. I
encourage you all to go over and take a look. Please address any questions or
comments to either myself, Delphi user OLDGROUCH or to Sundog Systems through
the Delphi username SUNDOGSYS. Thank you.
-*-
29922 3-JUN 01:35 Telcom
OSTERM
From: ELM To: ALL
This is my first time on Delphi using OSTerm, and it has been an *experience*.
I was able to log onto Telenet all right, but once I got the CONNECT 2400
message, everything turned to garbage. I actually logged onto Delphi in spite
of the garbage (I could follow the routine even though I couldn't read the
screen display.
The params were 8N1. I changed to 7E1, but that didn't help, and finally I
logged off.
I called again and logged on successfully set at 7E1, which is what I'm using
now. I also managed to download a small .ar file under XMODEM, but haven't
looked at the file yet (it is on the disk).
Any ideas why I can't use 8N1?
I'm not only new at OSTerm, I'm a neophyte with OS9, so please be patient with
my dumb questions.
-Len
-*-
29924 3-JUN 02:02 Telcom
RE: OSTERM (Re: Msg 29922)
From: TIMKOONCE To: ELM
The problem is that Delphi sends 7 bits/Even parity, and if you're receiving 8
bits, then that Even parity bit will make some of the received chars have the
high bit set. A few terminal programs will strip off those high bits so that it
will work properly even with 8N1, but OSTerm is unfortunately not one of them.
- Tim Koonce
-*-
29928 3-JUN 11:35 Telcom
RE: OSTERM (Re: Msg 29924)
From: ELM To: TIMKOONCE
OK, thanks. It's just as easy to use 7E1 as long as XMODEM works all right,
which it does.
Thanks!
-Len
-*-
29930 3-JUN 12:38 Telcom
RE: OSTERM (Re: Msg 29922)
From: TRIX To: ELM
I think I know what your problem may be with Telenet. Many people that use
Telenet (or is it Sprinnet yet?) don't know that the system has "hunt and
confirm sequences" that are used to tell it what baud/parity a caller is
calling at. If you're calling with 2400 bps 8N1 and want Telenet to take care
of the protocol for you, here's what you need to do.
1. Dial up your local Telenet indial. <duh><grin>
2. When you get CONNECT 2400 from your modem enter "@D[ENTER]"". (That means
first you hit the '@' key, then send a CAPITAL 'D' and then press the
[ENTER] key.
3. Next Telenet will respond with "TERMINAL=" and you send back to it "D1"
(again, in caps)
4. After that you should get the normal "@" prompt with no garbage from here
on out.
Hope that helps.
Also, the "hunt/confirm" sequence for 1200 8N1 is [ENTER]@[ENTER].
-John.
-*-
29933 3-JUN 14:37 Telcom
RE: OSTERM (Re: Msg 29930)
From: DRSPOON To: TRIX
Some TELENET nodes seem to act differently. On my local node, the 1200 8N1
"hunt/confirm" sequence is [ENTER] D [ENTER]. The one you recommended, [ENTER]
@ [ENTER] does nothing. The [ENTER] D [ENTER] seems to be more universal from
comments I have seen on other forums regarding access to TELENET at 8N1. The
2400 8N1 sequence you gave is what works here too. -Don Spoon-
-*-
29936 3-JUN 19:43 Telcom
RE: OSTERM (Re: Msg 29933)
From: TRIX To: DRSPOON
Oppps! Did I say [ENTER] @ [ENTER]? Gee, I guess I did. I'm sorry y'all. I
made a boo boo. You were right, Don. The hunt/confirm sequence for 1200 8N1
>>IS<< ------ [ENTER] D [ENTER] ------. I guess my mind wandered there for
a minute.
Sorry if I caused any undue confusion.
-John.
-*-
29940 3-JUN 23:32 Telcom
RE: OSTERM (Re: Msg 29924)
From: GREGL To: ELM (NR)
Bruce,
When you connect to Telenet at 2400 baud you need to send and at-sign (@)
followed by D and ENTER. That's @D^M. If you are using an auto-log script you
will need to use a small pause between the @ and the D and it must be an
uppercase D.
-- Greg
-*-
29941 3-JUN 23:37 Telcom
RE: OSTERM (Re: Msg 29924)
From: GREGL To: TIMKOONCE (NR)
Tim,
Delphi doesn't send "7-bits even parity" are you are alluding to. If you
know the proper sequences you can talk Telenet into sending 8-bits and no parity
instead of its default of 7-bits and even parity. At 300 baud you use the
double-ENTER. At 1200 baud you use the double-ENTER separated by a period (ENTER
. ENTER). At 2400 baud use @ D ENTER.
Several Tymnet nodes, on the other hand, seem to run at 7-bit even parity no
matter what you do.
-- Greg
-*-
End of Thread.
-*-
29923 3-JUN 01:50 Applications
RE: Sculptor (Re: Msg 29807)
From: CIZZIJR To: GENEDEAL
Gene,
The system I have here is a Coco 3 with 512k, two single sided 35 trk drives,
one double sided 80 trk drive, two 30 meg. hard drives, using a B&B interface
and the Puppo keyboard interface. I have yet to see an operating system
that can perform like OS-9.
Sculptor is a good package, I just need some more spare time to really get
into it.
Let me know how you make out on the vdu file. I could send you a text file
that I use under a graphics window. It can give you a feel at some of the
things you can do under OS-9. That text file is what you could compile to
use under Sculptor.
Later,
Carmen
-*-
29951 5-JUN 00:34 Applications
RE: Sculptor (Re: Msg 29923)
From: GENEDEAL To: CIZZIJR (NR)
Carmen,
I still haven't had much time either, so I haven't even looked at the vdu file.
When I do I'll leave you a message. Thanks for the info. on your system. Mine
is very similar: CC3 w/512k 2 dsdd 80tracks floppies and a twenty meg HD w/the
Burke & Burke.
I haven't had a chance to get the new keyboard interface. Hopefully that'll
happen before school starts back up this fall.
Later,
Gene
-*-
End of Thread.
-*-
29926 3-JUN 08:37 General Information
os9 dev. sys. software
From: RANDYE To: ALL
I recently went to Radio Shack to purchase the OS9 Development System package
but found out that ithas been discontinued. Do you know where I might get this
software? I would put this message in the Classified section under Items Wanted
but there are no instructions as to how to do this. RANDYE
-*-
29927 3-JUN 10:39 General Information
RE: os9 dev. sys. software (Re: Msg 29926)
From: DODGECOLT To: RANDYE
You might try some of the mail-order places, as they someimes have extra copies
of software that rat shack has discontinued.
-Mike
-*-
29931 3-JUN 13:31 General Information
RE: os9 dev. sys. software (Re: Msg 29926)
From: EDDIEKUNS To: RANDYE
A Radio Shack near where I live (908-C North lake Street, Aurora, IL, (708)
897-6135) has ONE (1) Development System in stock at the asking price of $19.95!
You may want to go to your local Radio Shack and see if you can special order it
& perhaps get a special deal if you prepay (I got mine 40% off that way!). But
if all else fails and the folks at that Raidio Shack can't help you (I figure
they won't take mail order, but it never hurts to try!), then let me know and
we'll figure something out.
Unfortunately, I'm too poor to put out $20 to hold onto it right now. :( I'm
waiting for the next paycheck! But I'm willing to buy this & send it to you for
price+shipping if you want. If you DO, then let me know ASAP so I can call the
Radio Shack and put a hold on it! Then drop a check in the mail (after I
confirm that it's still there & I could put a hold on it) and watch your
mailbox!
Eddie
-*-
End of Thread.
-*-
29932 3-JUN 14:15 General Information
The T.O.P.S User Group
From: KEITHMARCH To: ALL
Hello you all;
Does anyone know the address of the TOPS User Group in Japan?
Keith
-*-
29934 3-JUN 15:29 Telcom
RE: telecom problem (Re: Msg 29867)
From: FROGLEGS To: DCJR (NR)
Thanks I will give it a try.
-*-
29935 3-JUN 15:32 Programmers Den
Aciapak blues -- Chapter 2
From: EDDIEKUNS To: ALL
I solved my problem (at least one of them!) with Aciapak hanging on me, but
don't understand why what I did solved the problem! (Thanks to Tim Koonce for
the suggestion that led me to the solution)
It turns out that the extension KBCom was calling (my XYModem) was turning on
the keyboard signal (so it could absorb keypresses) and never turning it off!
When I made XYModem turn off the keyboard signal and also made KBCom do
_ss_rel(rs232); _ss_rel(wind); just after returning from an extension, the
problem went away!
The problem: After returning from an extension, the first couple keypresses
would work fine, but then the 3rd (or so) would freeze up the system. Debugging
code proved to me that it was freezing in a read() of the rs232 path. (And thus
not in KBCom logic or an infinite loop)
KBCom does not set a signal on the modem path except SIG_WAKE, and I always
release that. The same goes for XYModem. So I don't see why the above would
help me. Also, isn't every process supposed to get an automatic _ss_rel of all
_ss_ssig'd signals when it exits? But with the above changes, I've been unable
to reproduce the lockup in a couple dozen downloads. Usually I'd get it every 2
or 3 downloads. (Right. It's one of those intermittent bugs!)
Any ideas?
Eddie
P.S. Oh -- I should add. The problem was independent of whether the extension
opened its own path to the modem or KBCom passed it the path as path 0.
-*-
29938 3-JUN 23:17 Graphics & Music
graphic
From: NES To: ALL
Hay, I have build a 64 gray scale digitizer, I have writen RSDOS drivers for it
and can save them in CoCo Max format(320x200 16 colors). I have samples in the
new downloads, Is there a program to view 16 gray scale under os9 and RSDOS, I
have set the palettes on the X-MEN digitized pic to 4 gray scale but they could
be view as 16 gray scale with the right viewer program, since i set the
palette's to 4 black, 4 dark gray and 4 light gray and 4 white, just need to
view the inbeteew.. also need help with writening os9 drivers for the pak...
this pak dose not need any of the CPU's time to digitize a pic, so os9 can still
multitask... -NES-
-*-
29939 3-JUN 23:31 Telcom
OSTerm autodial
From: BILLBEISSERT To: ALL
I can't get the autodial to work with OSTerm V.2.0.8 and need some help. I am
using Tandy protocol and have my prefix set as "*.DT" and suffix set as "X".
Also, I get garbage on the screen up until I get the USERNAME: prompt.
I am able to dial from the keyboard (*blind*no echo) or else I wouldn't be
here now. Should I have a string in the system initialization? Bill
-*-
29942 4-JUN 00:24 Device Drivers
720K DISK DRIVE
From: MCIRISH To: ALL
HI
I RESENTLY RECIEVED A 720K DISK DRIVE AS A GIFT. IT WAS THE ONE RADIO SHACK HAD
ON SALE FOR 99.?? (THEY DIDN'T KNOW IF IT WOULD WORK BUT ITS THE THOUGHT). I'M
TRYING TO GET IT TO WORK, I RIGGED UP A POWER SUPPLY, AND BUILT A NEW CABLE. THE
DRIVE REACTS TO ANY APPROPRIATE COMMAND BUT I DONT THINK DATA IS BEING XFERED.
I REMOVED THE TERMINATOR RESISTOR IN MY OTHER DRIVE, AM USING THE STOCK 80 TRACK
DD THAT CAME WITH OS-9 LVL 2, MY OTHER DRIVE(A 40 TRK SS FULL HIGHT) WORKS FINE.
THE DRIVE JUMPERS USED ARE: FG, D2, MD OTHER JUMPERS AVAILABLE BUT NOT USED
ARE: OTHER DRV SELECTORS AND MS. AN ATTEMPTED FORMAT (FORMAT /D2 D 2) RESULTS
IN A STEP THRU ALL TRACKS A REQUEST FOR A DISK NAME, 4 FAST SCANS OF THE DISK,
THEN A 247 ERROR. THANKS FOR ANY HELP
JOE
-*-
29945 4-JUN 02:56 General Information
OS9 vs. PCDOS -- gripe bucket
From: PAULSENIURA To: ALL
With this article, I hope to criticize to a high degree about all the mess I've
seen on many different kinds of small computer systems over the years. I don't
want to buck the system or appear to do so, but enough is enough. I have seen
IBM and other PC-compatible companies, and other non-PC companies such as Atari
and Amiga, Apple/Macintosh, yes even including Tandy/Radio_Shack, etc., go out
of their way so much to pull the wool over almost everyone's eyes, that most of
the computer users think there are no alternatives to such systems as MS/PC-DOS
and OS/2.
I take GREAT exception to what and where the market is doing to all of us. (I am
just as vehemit in not being able to find vinyl LP records anymore, but that's
another article shortly coming.)
This article was basically prompted by people complaining about no standards set
under PC-compatible DOS (I'll call it "PCDOS" from now on, hoping I'm not
stepping on someone's trademarks; please forgive me if I am). It was also
prompted by an announcement made by Microware of their decision to drop support
for OS9/6809 and "Personal OS9/ST" and other forms of OS9/68000, which appeared
in the March/April-1990 issue of the OS9 User Group Newsletter. Several other
smaller items, too many to note here, are likewise crowding my brain, which
finally caused my dam to burst. Hence this article.
Basically, those who gripe and lose sleep over PCDOS machines are Right On The
Money with their concerns. I've suffered for quite a few years trying to bang
different IBM-written 3270 emulators into working with other IBM-written
PC/mainframe communication packages. I've seen our PC teams tear their hair out
on such things as a Logitech mouse driver slowing everything else down,
including simple file-transfers from the mainframe. The biggest problem is that
Vendors do not let their Customers, even Government, know that newer drivers,
patches, and releases are available to fix their problems. Yep IBM does this
"non-notification" all the time. (IBM invented the 3270 data stream, but their
own PC-development teams are probably the *worst* supporters of that protocol!)
Most PCDOS users are not concerned with mainframe packages. So I have also
noted major problems with PC-only packages. One program will end, then you
start another application, only to find things don't work right. In my case, the
PS/2 will lock up, not even a keyboard warm-boot will work. Programmers seem to
not care about ensuring their code restores the machine back to original
conditions. But I say the DOS ought to restore the environment for you ...
The basic design of PCDOS environments is causing a lot of the faults: It flat
left the IRQs open for anyone to grab. When you attach to an IRQ, you *ARE*
modifying the way that DOS behaves. The application is then "at" the level of
the DOS itself, something most operating systems would NEVER LET a user do, yet
Microsoft and IBM both support this type of interface.
OS/2 when used in pure OS/2 mode will force people to adhere to system
standards. Most programmers won't know what hit them since they've been
"raised" to blap on their own routines in place of the DOS's. Therefore, most
OS/2 shops do NOT run in pure OS/2 mode but rather DOS-compatible mode, in which
case plenty of PCDOS programs and applications *still* won't work because they
muck around with the hardware directly. You're asking for it all over again.
Believe me.
IBM finally is coming out with a version of OS/2 that lets you have multiple DOS
sessions, up to 16 of 'em, running concurrently. Yes I know y'all have had such
packages as MultiDOS and ConcurrentDOS and shtuff like that. But hear me out:
IBM is -- and always HAS been -- playing catch-up to what other operating
systems from non-PC companies have been doing for several years. I say IBM and
compatible companies have been pulling the wool over y'all's eyes.
To prove this, I want to show you what OS9 Level 2 does on our so-called toy
computer, the Tandy Color Computer 3. (Note well that I mentioned Tandy is
pulling the wool over everyone's eyes, too -- they have essentially stopped
supporting our favorite CoCo system. Just bear me out.)
First a little background. We have an 8/16-bit CPU known as the Motorola 6809.
Apple(II) uses a predecessor, the 6502, and kinda fairly compatible at the
assembler source-code level. Later, the Atari and Amiga started using the
Motorola 68000 16/32-bit chips, and the Macintosh of course uses the super 68020
and beyond. I'm going to stick to the 6809, which originally is designed to
only address 64k RAM, and I'm going to show you what these big companies DON'T
WANT YOU TO SEE in it.
Tandy and Microware (not Microsoft, they lost out, sorry) rebuilt the original
CoCo with a redesigned Motorola Memory Management chip. This chip has to be a
landmark invention, and in fact sports a copyright notice on its face. This
chip, together with OS9 Level 2 (which Microware licenses to Tandy as the OEM),
causes the 64k limit to be greatly expanded to 512k, 1-meg, and 2-meg on some
non-Tandy 6809 machines.
The CoCo3 by itself has been benchmarked to keep up with and surpass the speed
of a PC/XT 8088. Before you laugh, you need to know that the CPU-clock input on
the CoCo3 is less than half the speed of the XT. Now it's my turn to laugh. I
know for a fact that the CoCo3, even while it's multitasking under OS9, can keep
up with my 9600-bps HST modem, hey that's *with* MNP5 compression now! I've
heard horror stories when a PC/XT user finds out he can't do the same thing, and
afterwards he's found out and been told to upgrade to an AT model instead. No
one is showing you the speed of the Motorola 16/32-bit chips compared to Intel's
80286 and 386. They can't; they'd be embarrassed.
Now usher in that Memory Management chip. It handles up to 512k of RAM,
switching 8k banks of RAM instantly; it can cause the entire 64k region (8
banks) or any number of banks to be changed instantly -- yes I mean inside ONE
CPU CYCLE. This is RAM that the CPU directly accesses.
But wait .. the video buffer in our CoCo3 MMU can address any part of this 512k
RAM, too. Video can be shown in completely separate parts of the 512k, totally
outside the range that the CPU is currently accessing. Can your VGA card do
that? If you have 4-meg on your PS/2, can you make your monitor show *any/all*
sections of that 4-meg DIRECTLY without block-copying any of it or using a
blitter chip? Whether or not the 286/386 is touching that part of RAM?
Now the neat stuff ... the price! You can get a CoCo3 and the maximum RAM
installed for about $240.00 -- you sure can. Our floppy disk controller (extra
$) can already address 3 drives of any kind except High-Density. It can talk to
a 4th drive with a simple mod (which Tandy *still* won't redesign their specs
to). We're talking any kind of drive from 5.25" SSDD/180K, DSDD/360K,
DSQD/720K, and 3.5" DSDD/360K and DSQD/720K types. Uses the standard Western
Digital 17x3 chip sets.
Now usher in OS9 Level 2 from Tandy/Microware. Those floppy drives can be of
ANY MIX AND MODEL. For example, a DSQD drive is treated as a total space of
720K, not partitioned into two 360K logical units. The smallest allocation unit
("cluster") is 256 bytes. If you need to have a disk file that's only one-byte
in size, you're only wasting 255 bytes, not 8191 as under MS-DOS. This is a
function of the o.s., not the machine hardware. That's right. And no one has
hit the maximum number of files before the root directory fills up, not even on
a 40-meg harddrive.
Speaking of harddrives .. a company specializing in CoCo/OS9 market has
invented an interface for PC/XT boards to plug into our CoCo buss. I am using a
real honest WD XT-GEN board with a Miniscribe 40-megger. We could have gone
with an RLL board, too. No we can't use AT-style 16-bit boards, but if we
could, OS9 can handle single-256-byte/sector clusters in its File Allocation
Table until we reach about 330-meg per drive. We would then set the cluster
size to 2 sectors per bitmap, 512-byte clusters. Never would we need to set
cluster sizes to 8192 as MS-DOS 3.3 does (and older). Never would we need to
zap the FAT to support big drives as MS-DOS 4.01 makes you do (or reformat
them).
As a matter of fact, by international agreement, OS9/68K is the official format
of CD-Interactive disks, of which CD-ROM is suppose to comply, too. Sony is
planning to incorporate OS9/68K inside their CD-ROM drives (i.e. "smart") so
they'll be attachable to any computer. This necessarily requires a 68000 CPU
and 1-meg or more of RAM etc. It'll also decompress any recorded video pictures
on-the-fly, too.
OS9 L2 also controls the MMU in such a way that you do NOT worry about where
your applications load. All OS9-supported languages are compiled down to
position-independent code (PIC), even the Assembler and system modules, drivers,
and such. OS9 provides a TSR-like function: hey, all you have to do is LOAD a
command/program into memory. You can remove all your floppies at that point,
because that program is in MEMORY now. You don't care where it is loaded inside
that 512k, 1-meg, or 2-meg ... OS9 will find it for you, don't you fret about
it. This mechanism does not depend on vectoring IRQs to kick in ... if you
want to run that program, you merely type the name of that program as a command
(or some other program can Call it).
What if you're inside one program and want to run that other program? OS9 L2
gives you multitasking and windows at the o.s. level. Tandy's MultiVue package
is one common interface that lets you start tasks on multiple windows, yes on
your very own monitor's screen. You can have several split/smaller windows on
one screen, and you can also have multiple full-size screens, and you can have a
mix of each on each. Your hot-key is the 'Clear' key to go forward through them
or 'Shift-Clear' to go backwards. Or your keyboard arrows or Mouse can select a
split/smaller window-application directly if it's on the current screen.
This sounds all mixed-up to you? It's cuz some big-named companies have been
keeping TRUE MULTITASKING WINDOWS a secret from you -- they don't want you to
know these things exist on non-PC compatibles! They want you to run out of
memory every time you want to load that new TSR of yours, so you'll go shell out
a thousand bucks to upgrade your PS/2 to 4-meg or whatever!
What about graphics? That video buffer in the MMU has some Atari-grade graphics
modes built-in. Comparable to EGA but not VGA. Yes you get these modes when
you pay for the CoCo3 keyboard unit. You can use a regular TV or video monitor,
but an analog-RGB monitor is the best (Tandy didn't muck around with digital
RGB). Magnavox, Sony, even the Atari analog monitors can be used with a simple
adaptor cable. Super-VHS VCRs can almost perfectly capture the hi-res text &
graphics; the NTSC video bandwidth is the killer here, not the CoCo3 or VCR.
That's right, you'll have an excellent special-effects generator right here.
Get a sync-lock box, a chroma-key thingie, and you'll be making professional
videos in no time. There are some good OS9 graphics editors around. Using
different fonts (typestyles or letter styles) on your screen is again another
built-in feature of OS9 itself which the application programs usually include,
and OS9 includes proportional-space support! Can we make our own fonts? You
bet, and it's cheaper than you think -- Shareware/Freeware on CompuServe's OS9
SIG! And for animated effects, OS9 again provides Get/Put Graphics buffers at
the o.s. level. Most higher languages include subroutines you call to let you
concentrate on your program, not the o.s specifics of the graphics. You do NOT
need to write your own (or use someone's) C-Graphics functions that poke values
directly into the video buffer. OS9's graphics algorithms are incredibly
efficient and effective, i.e. a Circle is perfect, it won't contain "tits" at
the north/south/east/west points!
Pop-up (overlay) boxes are also built into OS9 itself. When you want to show an
error message, merely open up a generic window device (path), size it up and
print the error message. Whoops but is the underlying text saved? You do NOT
worry about it: when you close the path, OS9 removes the box and restores the
text there. YOU don't worry about it, get my drift???
That goes for pop-up boxes on GRAPHICS screens, too. Yes that's right.
OS9 will also scale graphics down to fit a smaller-size window, again at the
o.s. level, if you want. That means, for example, you can run a full-screen-
size standard-written pie chart generator in a smaller split window, and another
window could run the same program with Different input alongside the first
window, so you can compare the two charts! You won't need to rewrite the
program at all -- OS9 will scale-down the move/draw commands automatically.
The Mouse pointer can be anything you want -- remember what I said about
designing your own fonts above? There are three kinds of Cursors that OS9
provides for you: (1) the regular text character cursor (i.e. where your
keyboard input will be printed), (2) the Mouse cursor (again you do NOT worry
about saving/restoring what it is covering up as it's being moved), and (3) the
Draw Pointer. Yep, that third cursor is invisible, but it lets you, for
example, continue a polygon shape you're drawing while the user is selecting the
next "To" point. That is, the user is telling you via the Mouse cursor where to
place the next end-point of a line, and YOU do not need to keep track of where
that previous line WAS drawn. You just tell OS9 to draw to the Next point. Of
course you CAN specify a start and end point if you want.
Remember: all this is supported at the o.s. level -- you don't need to buy
anything else. OS9 L2 base package *will* provide all the above. You don't
need MultiVue unless you want high-level pull-down menus and such to be done
automatically at the o.s. level.
And IBM is just now coming out with a multi-DOS-session version of OS/2 that
"might" contain some of this kind of interactive environment? And how much do
you have to pay for the o.s.? What about the cost of upgrading your hardware in
order to merely install OS/2??
Well I've covered more than enough for you to think about on the hardware and
o.s. end of CoCo3/OS9. Let's talk about some programming principles, some items
we can do that sound like mainframe functions!
Many people *always* link together all of their subroutines into one big huge
executable file. OS9, like UNIX, can deal with automatic DOS-overlay type of
modules if we only design things carefully. Our OS9 has a per-task limit of 64k
address space, but this auto-overlay mechanism will map code stored in different
8k RAM blocks (like a virtual storage mainframe, yep!, only not on disk but in
other hardware bank-switching blocks). It'll automatically unmap the
subroutine(s) when finished, but they'll stay in RAM if they were preloaded
beforehand, just unmapped out of that task's 64k space, yep just like a
mainframe would do! If they weren't preloaded into RAM, OS9 would automatically
find it on disk and load it .. this *does* take longer of course. Again just
like a mainframe if done right, we can load many many modules inside the same 8k
block of RAM.
If carefully designed, most CoCo/OS9 systems with 512k can run the largest
Lotus-type of spreadsheet you've ever seen, for example! Most people will not
think to use a RAM disk for "data in RAM space", like the newer MVS/ESA can do
with Hyperspaces and Data Tables. In fact, OS9 has a "Data" type module, which
is a module that can be loaded into memory but it's only data, not executable
code or drivers. People have never heard of the things we *could* do under OS9
with a little imagination and forethought (usually because they've never seen
what mainframes are all about in the first place!), yet be compatible and
hardware UN-dependent with the many kinds of OS9 machines everywhere.
While we're comparing such features with mainframes, if I can be so bold as to
step on some toes here ... I can gleefully say IBM is sadly playing catch-up
with OS/2: it will have up to 16 concurrent DOS windows/sessions in 1.2-EE, but
this is a feature we have ALWAYS had under OS9 Level 2 when Tandy and Microware
put their brains together and designed "window devices" at the o.s. level (plus
we are NOT limited to any number of tasks, strictly speaking). I.e. pop-up
windows, graphics, etc., are simple escape-code commands "printed" to the
device, which means such programs will work through MODEMMING to one-another!
The only thing needing fixed is Mouse support this way, but we can switch from a
real mouse to a keyboard (arrow-key) mouse instantly WITHOUT rewriting a single
program -- all this support is at the o.s. level! And we've had these luxuries
at home for several YEARS now, and IBM is just now coming out with PC operating
system software that can do it and let standard-written pgms behave this
way????? :-)
Another method available to us are Pipes to pass data between tasks, each task
having their own 64k region. Just like UNIX, but not nearly so fancy.
We could design a huge complex application this way if things would stay modular
and smartly constructed. Yep on a so-called toy computer.
There'd be another benefit doing things in this fashion: ports to other UNIX-
like systems would be much easier, less hardware-dependent, and runnable on more
configurations that normally might not have the room.
Is OS9 only for Motorola CPUs? Nope, there's a portable version called OS-9000
for 80386-based machines out there; it's brand-new and I can't find much info on
it at all right now. It's basically waiting for OEMs to provide it with their
hardware.
There's also a 68000 card you can plug right into your own PC and run OS9/68K,
concurrent with your DOS and speaking to it; this is what most people use. And
there's a piggy-back board for that 68000 card that lets you attach 10 or so
RS232 devices, yep to your PC, all multitasking, etc. This 68000 card has its
own 1-meg of RAM, CPU, MMU, etc., and your DOS just runs alongside it. This
flavor of OS9 will use the DOS to communicate to your hardware. You see,
someone has all this compatibility stuff figured out already, but no one knows
about it. If you can find the last issue of "68 Micro Journal" earlier this
year, they have excellent coverage of these products. And they ain't expensive
at all, not by IBM's standards!
No I don't have any kind of affiliation at all with any of these companies: you
know I work for Okla. Dept. of Transportation which uses IBM equipment. Even
one of the instructors at IBM's Dallas Education center (a consultant, not an
employee, hired to teach us about Office/Vision), told all of us how he despises
PCs and their current implementation. I couldn't agree more. I can truly say
OS9 for the PC crowd is a huge step in straightening out the mess that all
programs seem to cause with each other. OS/2 is too new, takes way too much in
the form of $$$upgrades$$$ to your PC, and has not been proven to work with many
applications yet. If it's like any of the other IBM PC packages, it won't be
bug-free for several more years. In fact during the Dallas labs, our OS/2
crashed only from trying to hot-key between those windows.
Whereas I've had my CoCo/OS9 up and running for several DAYS straight, with
RiBBS taking callers, and me on other local device windows doing other work.
Not a single goof, sparklie (video boo-boo), locked-up task, reboot, Nothing!
If we do have any bugs, it's in the application, but things are so well designed
that it hardly has a chance to crash any other task. The key to these kinds of
well-behaved programs is to always follow your o.s. rules (DOS, OS9, UNIX,
Xenix, GEM, whatever!), don't play with the hardware directly (a big no-no under
OS/2, too), and keep track of return codes coming from system routines, don't
just ignore them. If programmers NEED to get outside the o.s., that's a
function that should be ADDED TO the o.s.! OS9 can be spruced-up very easily in
this fashion. You'd need an experienced kernal hacker for UNIX and OS/2 etc.
And THIS is why MS/PC-DOS is so cruddy and well-hated by many who've had their
eyes opened in other directions.
Thank you for letting me speak my piece. I hope this has sparked some of you
into discovering new avenues for old problems. After all, if we can do all of
this on a CoCo3 (not a toy no mo'), why is everyone else having such a difficult
time doing such things on these other machines? We need to get the word out to
OEMs that OS-9000 is available for them, and to get them to start
developing/porting these windowing environments we already have over to the
80386 machines. We also need to get various 680x0-based companies interested in
these windowing environments, likewise. And finally, we need hardware vendors
to provide OS9 drivers for their products, such as the QIC-40 tape cartridge
drives. Your sales will start booming if you'd expand your development efforts
to include non-PCDOS machines and operating systems, too.
-- Thx, Paul Seniura
-*-
29946 4-JUN 02:57 General Information
Getting OS9 & CoCo3/4/5/6/... on bandwag
From: PAULSENIURA To: ALL
I will GREATLY appreciate it if we get the word out and the concerns about why
everyone I know has gotten turned OFF on OS9 -- simply because we can't seem to
get things working like the rest of the world has it. On GEnie and other
places, I have asked why we OS9ers can't get a QIC-40 driver for our tape drive,
we can't get proper archivers that match to the rest of the world (required by
Fido protocol), and not to mention Standard MIDI File support on UME-3 ... just
can't understand why no one wants to follow standards at all and get OS9 -- ALL
flavors -- on these various bandwagons AND others I won't bother to mention
right now.
It's gotten to the point that I will wait to see who wins the "War between KLE
and FHL" now. We OS9ers need hardware *and* software compatibility with the
real world out there. Just hear me out here, please.
My supervisor & I have darn-near the exact same setups on our CoCo3 systems at
home. (We work at Okla.D.O.T. strictly IBM mainframe and PS/2 shop, although
graphics workstations are hooked into Intergraph UNIX and VAX systems.) We both
decided to buy Colorado Memory Systems tape cartridge drives, the one featured
in the JameCo catalogs (the $299.95 one). I've asked around, even Microware who
gave me Bill Brady's number, whether someone had developed a QIC-40 driver using
standard Western Digital 17x3 floppy controller chips as found in our Radio
Shack pak. I ordered several of the QIC documents from the official keeper of
them, and I am positive the WD17x3 will do what QIC-40 dictates. I spelled the
whole rigamarole out on GEnie but I doubt anyone has read it, so I'm reprinting
some of our concerns here.
It has *already* successfully turned off my supervisor -- he was only learning
OS9 at home for a hobby, something to keep him busy when he retires in a couple
of years. That QIC-40 stuff was the "last straw" when he heard how much trouble
I was having getting some help! He's ready to throw the entire CoCo/MPI/RGB
/drives all into a bonfire. He wants to see what color it'll glow.
That QIC mishap really cooked his goose. Because we ran that drive on a real
PC/386 -- it is an excellent drive: this PC/friend has at least 30-meg of USED
allocated space on his 60-meg drive (under MS-DOS 4.01). Guess how long it took
to back up 30-meg?: Would you believe a total of less than 13 MINUTES????
Fully indexed where you could restore 1 file if you needed.
Now I know the CoCo can't do it that fast, we're estimating 24 minutes minimum
strictly due to the fact that we don't have high-density controllers like this
guy's 386 did. And maybe we can't do the QIC-40 stuff 100%. But we surely can
use the drive *as* a smart floppy with our own backup routines, such as B&B's
and Pete Lyall's etc. All we'd need to do is figure out how to do the Single-
Block-File manager that OS9/68000 has available -- right??? Why can't we get it
going then?
Well at any rate now you know the main arguement I keep hearing about OS9: We
can't do nuthin' with it when we get it installed and working. We don't have
tape backups, we don't have true ANSI support anywhere, we don't have compatible
archivers, we don't have dependable Acia drivers, we don't have all the fixes we
need from Tandy or Kevin Darling or whomever else has been putting them out --
we CAN'T EVEN FIND OUT who and what and where those same fixes ARE, if you can't
get on-line with some service!!! And GEnie is NOT the place to find out,
obviously. It's flat dead there. It's almost just as dead here on Delphi.
Thought I called up a graveyard. CIS costs way too darn much -- it's cheaper to
call someone's BBS directly long distance any more! And I'd have a hayday if I
can call Kev's BBS! But it'd still be cheaper by the hour than using any of
these other services.
The MOTD still hasn't printed any of our concerns here -- do you think they are
just embarrassed that OS9 can't do what PCs can do? I sure would be, but I
would be printing SOMETHING to get the ball rolling, not HIDING.
I have joined every kind of group I can find. IMA, IEMUG, OS9 Users Group, and
call all kinds of BBSs to keep tabs on what is happening. (I've been told not
to join the IFNA group cuz they are dissolving.)
Then when I sent our local CoCo Club in OkC my dues and a 7-page letter
describing our OS9 and CoCo hardware/software projects (I'm funding myself), the
post office returns it back to me via Atlanta,Georgia, where the
"Undeliverables" go. Finally found out from Chuck West that our club is
dwindled to the point that there's no one there that uses or runs OS9.
And we CoCo/OS9ers wonder why we're losing Tandy's and Microware's support. I'm
TELLIN' ya why.
I called Microware just last Thursday (May 31 1990). Found out we can still get
version 2.2 of "Personal OS9/ST" for the Atari. Guess what? There ain't no
windowing system for it. Oh I asked for MW's "Source Book" to see if we can
call that one company that wrote a windowing system for Atari/OS9, but the MW
lady told me it's just for their hardware, whatever that means.
And MW told me just the day before (May 30 1990), that KLE had ordered the
sources for OS9 for porting it over to their MM/1. JUST NOW??? What's going
on? MW told me that apparently Tandy still has the only windowing system
available for any OS9able machine, bar none including KLE & FHL.
So depending on what MW's Source book says, the Atari is not going to be a
choice for our migration away from the CoCo. In fact MW sounded like there *is*
no migration path as things stand right now.
I for one will not migrate over to any system that (1) cannot run OS9 DIRECTLY
and (2) does not have the MINIMUM level windowing system we currently have under
MultiVue. I am not talking about doing it thru a "gateway" -- I have had it up
to my ears with gateways cuz we've had so much trouble getting things working
between our mainframe & PS/2s at Okla.D.O.T. I don't want to hear the word
"gateway" at all: it conjures up hellacious pictures in my mind. Bytes going
thru a gateway can be changed, protocols won't work, file transfers get botched,
etc. etc. etc. It's a nightmare to get it working. I want pure OS9/OSK windows
like we have 'em on our CoCo3 -- that's a windowing system DIRECTLY under
OS9/OSK. Mice are nice but windows are more important.
Sorry, I'm on a roll here. Edit and filter my remarks as cleanly as possible,
but you should be able to get something into the magazine now! There's enough
for a regular magazine series, not just one month's worth!
And please tell everyone I'm not afraid to do any of this work -- if I can JUST
find some contacts to help me along. Good grief -- That IS the biggest
complaint I have heard, overrides any other! If I can just get to talking to
those who KNOW something about what we're trying to do,,,, you know? I am not
afraid to tackle things by myself, not afraid to crash my 40-meg B&B/FHL drive
to get something big to work! (I do back up anyway, but boy it'd be nice to
have that tape drive a zippin' along.)
Please forgive me if anyone reading this feels hurt, sore, upset, or if your
toes are smashed flat. I had to say it, my supervisor really got me upset
myself to find out he's calling OS9 quits for his personal hobby. I am a IBM
3090 mainframe systems programmer, take care of CICS, DISOSS, plenty of IBM
8100s and try to get the PC programming team involved with our mainframe tests
(I am not a supervisor myself), but I tell you I will never buy a PS/2 as long
as I live -- we can run rings with OS9 Level 2 and the windows etc. which
overshadow anything we've been able to do on any PC bar none, even OS/2 itself.
It's pure joy to have windows and not having to buy MicroSoft's stuff to get
'em. But again look at what we CAN'T do simply because we can't find help so we
can program OS9 up to DO it.
KLE and FHL, and you too TANDY -- hear me out: I don't care how wonderful a
CoCo4 is going to be, if we CONTINUE to have this kind of mess, continue to hear
silence from having asked a couple of detailed technical questions, continue to
see blank faces when we need certain kinds of standards being set, continue to
never get called back from a hardware manufacturer, well I could go on, and I
have already overrun my welcome here I imagine.
Please at least put SOMETHING along these lines into the magazine. I feel Ron
Bihler made a gooooood stab at providing us with at least ONE standard: FIDO! I
don't even hear whether we have UUCP or UseNet working on OS9/6809 yet, but
Ron's got FIDO!!!! Arf!! Kudos for him!!! Now he's forcing us to get full
function Arc and Zip capability, and who knows what-else will FINALLY become
available for OS9 when we do THAT!
(Someone recently told me James Jones had the source for TCP/IP drivers! When
are we going to get that kind of support?)
Thanks a WHOLE bunch this time. I'd buy ya lunch if I could, if you've sat this
far through my belly-aches. Thank you for helping -- Paul Seniura.
(P.S. I have signed one of SEA's "Arc Conversion Policy" forms in order to try
porting Arc 6.02+ over to OS9 L2. We're expecting the source package to show up
any day. Yes they seem to be excited and definitely have heard about OS9, but
SEA themselves have no expertise and must rely on porters. Contrast this to the
way Phil Katz of PKZIP fame does things -- we have seen bugs in every UNZIP
version we can get our hands on, simply because Katz won't let his sources be
ported directly, and porters such as Vaughn Cato and Sam Smith have to "guess"
at his methods. I've asked Katz and Sam Smith directly on their respective
BBSs, and I've gotten no answer from any of them, favorable or not. I *did* get
an answer from SEA! So they win the "SEA vs. PK" war as far as I am concerned.
Hear that, Zippers? There *are* more important things to consider than "how
fast" and "how much compression" -- the main point is whether the owners would
allow someone to sign a contract to port their tools over to other operating
systems.)
-- Thx again, Paul Seniura.
-*-
29948 4-JUN 03:41 General Information
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29946)
From: EDDIEKUNS To: PAULSENIURA (NR)
A couple quick & short comments...
One reason that you don't see a whole bunch of software out there for the CoCo 3
& OS-9 is that it takes TIME! It takes time to 1) Become familiar with OS-9 2)
Become familiar with OS-9 guts 3) Write and debug your program. I've been
working on KBCom for about 15 months now, and tho I'm approaching a
commercial-quality program, I'm not there yet. Standards? KBCom NOW supports
the VT100 protocal. No, I don't support ANSI, if you want to call that a
standard :) but I plan on eventually adding a versioin of ANSI that seems to be
more widely used than others. (IBM PC ANSI.SYS)
Delphi is a graveyard? I'm speechless! It's all I can do to keep up here! The
OS-9 forum traffic is growing in volume as time goes on.
KLE & FHL are at war? Actually, I find their machines as being aimed at very
different niches. They may 'fight' to move people from one niche into another,
but the niches are pretty well defined I think.
UME & standard MIDI: I really know very little about this one. Just one
comment: Give the man time!
I think that about two years back a *LOT* of unrelated and separate projects
startup up (Fido, UUCP, KBCom, OS-9 LII upgrade (?), all the unZip & deArc
programs, ...). It takes TIME to port things over, and it takes time to write
stuff from scratch. Esp since most (?) people who are working on projects like
this aren't payed to do it, and thus must work in their spare time.
I can't speak for the other networks you mentioned, but the only time I see a
question go unanswered here or on the CoCo listserv on the networks is when
no-one knows the answer. As *I* see it, the people in the OS-9 community are
bending over BACKWARDS to give away their hard-earned secrets and to give
newcomers all the help and support they need to get off to a running start. I
can't count the number of times I've seen messages like "My number is ###### ...
call me" with people offering their time and energy to help someone straighten
out a problem. And I have plenty of personal experience from working on KBCom
... I must admit that without the fantastic amounts of help and advice I've
gotten from other people (notably Greg Law, Kevin Darling, Tim Koonce, and other
people too numerous to mention! :), KBCom would be much less developed, if I
started it at all.
Well, my memory has run out (can't remember any more points to reply to!) and my
brain is shutting down (yikes! Almost 3am!) so I'll quit here!
I agree with a lot of the points you made tho. I hope your message stirs up a
lot of feelings and gets people going (and I hope & expect it's posted beyond
Delphi). I think many people are already working at just beyond full capacity
tho!
Eddie
-*-
End of Thread.
-*-
29947 4-JUN 03:35 Patches
serial mouse patches
From: OS9UGVP To: ALL
Hi All,
Just a short note to let you know I've finally uploaded some serial mouse
patches for CoCo 3 L2 V2 OS-9's CC3IO module. Your choice of 6551 or 65C52
ACIA, Logitech or Microsoft (or compatible) mouse or trackball. Partial sources
included. Let me know what you think... I hope I didn't mess up! Look for
"smouse.ar" in the PATCHES data topic.
Bruce Isted (OS9UGVP)
-*-
29949 4-JUN 19:39 General Information
kissable os9
From: TEDJAEGER To: DALEP (NR)
Just wanted to let you know I have missed your column in Rainbow too. I have
been reading it for 3-4 years and learned almost everything neat I know about
BASIC09 from it. Keep up the good work! --Bests, TedJaeger
-*-
29950 4-JUN 22:47 General Information
OSK Employment
From: JAYTRUESDALE To: ALL
Does anyone know of any employment opportunities for a person experienced with
OSK & 680x0 assembler programming?
If so drop me a note via email and we can exchange further details.
Thanks! -J

-*-
29953 5-JUN 00:59 General Information
RE: Stuff for Sale (Re: Msg 29755)
From: GENEDEAL To: MPASSER (NR)
Mike,
I have a perfectly good(a relative term) chiclet keyboard that you are welcome
to if you want it. I keep it because I keep thinking that I'll pull the HJL
keyboard out of my old CC1/64K paper weight. I know I should set it up for the
kids....
Let Me know if you want the keyboard.
Gene Deal
-*-
29954 5-JUN 02:32 Device Drivers
RE: 720K DISK DRIVE (Re: Msg 29942)
From: MARTYGOODMAN To: MCIRISH (NR)
Joe,
First of all... are you sure te drive was a good drive to begin with? Was it
new?
Things to check:
Is your cable made properly? Are there no shorts in the crimped connector?
Check with a VOM.
MOST 3.5 in drives do NOT have a removeable terminator on them... they
instead have a built in hard wired 1000 ohm terminator. When using those with a
CoCo... especially only one of them... you may have to LEAVE the terminator in
the first drive.
To check whether you have a hardware or a software problem, try using Disk
Basic's DSKINI command to format a disk in that drive. It will only format 40
tracks, of course... but see if it produces a verified format and whether you
can save and read stuff with that disk.
Let me know what you find.
Possibilities are many, and include, as implied above:
Bad cable, Improper software device drive, terminator problem
---marty
-*-
FORUM>Reply, Add, Read, "?" or Exit>