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

1312 lines
44 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
29967 6-JUN 02:37 Programmers Den
Signals
From: EDDIEKUNS To: ALL
If you leave the interrupt & abort signal on, and also set a keyboard signal,
and someone presses <Break> -- is the keyboard signal still set? Is there input
waiting to be read? (The <Break>) Or is the <Break> completely separate from
the "normal" keyboard signal, leaving its status untouched? (Either way, do you
have to read the <Break> from the keyboard to throw it away?)
Eddie
-*-
29986 7-JUN 18:35 Programmers Den
RE: Signals (Re: Msg 29967)
From: DODGECOLT To: EDDIEKUNS
Eddie-
If you still have the interrupt and abort chars set in the path descriptor,
then CC3IO (or ANY SCF driver) will send the signal to your process. No char is
put in the buffer...
-Mike
-*-
29990 7-JUN 19:19 Programmers Den
RE: Signals (Re: Msg 29967)
From: BILLDICKHAUS To: EDDIEKUNS
Hopefully Kevin will answer this, but this is like the ssig stuff, its handled
by the device driver. So if you're working from a terminal, it may be different
than if you're at the CoCo keyboard.
I don't know about CC3IO, but ACIAPAK will send the abort/interrupt signal, and
then immediately follow it with the ssig signal, which in almost every case will
get trashed, since there can't be more than one signal pending for a process.
The data byte is also placed in the input buffer (probably so the current
process can figure out where in the data buffer the abort/interrupt occurred) so
you will have to read it.
Bill
-*-
29996 7-JUN 22:11 Programmers Den
RE: Signals (Re: Msg 29986)
From: EDDIEKUNS To: DODGECOLT
Thanks! That's what I wanted to know.
Eddie
-*-
End of Thread.
-*-
29968 6-JUN 03:22 Programmers Den
Aciapak bugs. Chapter 3. <Sigh>
From: EDDIEKUNS To: ALL
<sigh>
I don't get it.
OK. Here's the story. I have a highly intermittent problem with Aciapak. KBCom
obeys all the rules. All signals are released (to the window & rs232) before
calling any extension, and released again on returning from the extension just
in case! And then asserted as necessary once the extension processing is done.
The particular extension in question is equally careful with signals, making
sure all are released before quitting.
I'm passing all necessary paths to the extension. (Path 0 = rs232, Path 1 =
window. Path 2 = logfile, if any, or window otherwise.) So the extension is
*not* opening its own path to /t2. The extension sets the parity/stop bits it
needs & returns settings to the original upon quitting. KBCom forces settings
to what it wants just to be sure. (In case you ru an unfriendly extension!)
While the extension is running, KBCom is waiting for it. (It's run via system()
call, thus, through the shell. This is so people can get fancy & use pipes &
such and also any shell features like wildcarding. ie: upload *.c) KBCom does
NOT close the rs232 (or ANY!) paths, but it's not reading from them either as
it's sleeping in the system() call.
After returning from the extension, there's a 1/2 second pause or so (on Delphi)
and then I get the "..... files successfully transferred" message and the
"ACTION>" prompt.
The problem: *occasionally* after typing about 3 keypresses, Aciapak will lock
up. Dead. The confusing thing is that the first 2 (or so) work fine! The
character is sent to Delphi, echoed back, read, and put on the screen! I put
debugging code in KBCom at one point and proved that the last statement executed
before KBCom froze was a read(rs232, buffer, waiting); where waiting = 1;. It
never returned from there.
The odd thing is that the problem is so intermittent in a weird sort of way.
Some nights, every single download or at best every other does this. Some
nights, I can't reproduce it for the life of me. It happens with and without
background processes running. (I thought that was a factor at one point, but
I've seen it happen in both cases.) On *very* rare occasions (ie, once or
twice), KBCom has locked up in Aciapak on a burst of line noise. (I had a weird
connection where I kept getting bursts of garbage followed by long periods of
normalcy! Actually, I can only remember once ever that this happened.)
I have the diode IRQ hack and an old GIME and a 6551 (not 6551a) in my Deluxe
RS232 pak.
Can *anyone* out there help me figure this puzzle out? I'm completely clueless.
Could this be a hardware problem that's causing Aciapak to freak out? Perhaps
my IRQ hack is giving me problems? No-one else has reported the above problems
with KBCom!
I don't know of any other programs which are able to fork other term programs in
quite this way, so I don't know how to go about testing this! (I know that
WizPro can, but I don't quite know if it's the same. It's more like a program
overlay than a real _os9fork(), right? I dunno. Hmmm. Perhaps xcom9 can?)
Please help me before I lose all my hair! <frown> My scalp doesn't need any
help!
Eddie
-*-
29977 7-JUN 00:41 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29968)
From: EDDIEKUNS To: EDDIEKUNS
A little bit more information which I noticed tonight.
I downloaded a file from the databases. After it finished and I was back at the
ACTION> prompt, I wanted to be reminded of all the filenamesof the group, so I
started to type des<Enter>. What got displayed was 'de' and it froze. I can't
remember if I hit the <Enter> or not, or if I did, when I hit it (before or
after it froze).
ANYway. I went into another window to 'procs' 'kill 3' (KBCom's PID). I
noticed that as soon as KBCom was killed, some characters were sent out! Almost
as if the kill woke up Aciapak and it unfroze & send out everything in its
buffer before (or after?) KBCom was killed!!! (And I then saw the recieve light
go on as I started to recieve the description.)
Upon restarting KBCom, I pressed <Enter> and got the rest of the description (
after the More? prompt).
Does this help in figuring out why Aciapak is dieing?
Eddie
-*-
29987 7-JUN 18:40 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29968)
From: DODGECOLT To: EDDIEKUNS
Well, my term program (which will be released to the public sometime soon...)
FORKs the appropriate program for file transfers and stuff. For kermit, I don't
have to set up paths- kermit will open /t2 and use the current settings for
baud/parity/word length... I haven't experienced any lockups after file
transfers, tho it <does> lock up randomly after sitting around for a week or so
of use...
Bruce Isted posted an update to the DACIA drivers for the eliminator- also
included was a new ACIAPak (not as fancy as the DACIA driver, tho) and a set of
Clock modules which help fix lockup problems at the source. Maybe you should try
them out?
-Mike
-*-
29993 7-JUN 19:26 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29968)
From: BILLDICKHAUS To: EDDIEKUNS
If you are using system(), then you are involving shell in the calling sequence.
Shell might be getting in the way of passing paths. If you are using shell+, it
might aggravate the problem, since it uses non-blocking (signal driven) input.
It would be better to pass the current serial port and any flags to the
extension as options on the command line, just as if it had been typed in at a
shell prompt.
ACIAPAK can lock up if XON/XOFF are enabled and it receives an XOFF as garbage.
There is no way to unlock it, it will wait for an XON forever.
All of the other terminal programs allow forking a shell, but not an extension,
except Wiz, which (I think, not sure) calls extensions as subroutines, not as
separate processes.
Bill
-*-
29997 7-JUN 22:16 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29987)
From: EDDIEKUNS To: DODGECOLT
I must have completely missed that posting! <Grin> I'll go and try it out.
I'm beginning to think this problem I'm having is hardware related and not
KBCom. (Well, no-one else using KBCom has mentioned any problems like this.)
My CoCo seems to have been flaky from day one. (There were some programs I
wrote which used the CPU so intensively that no keyboard input would work in any
window. Not even the <Clear> key! If I mashed my thumb down on it for a couple
minutes, it would flip screens. But other people ran the program with no such
problems.) P'raps I should check my IRQ hack. <sigh> This is really
irritating! Thanks for the help.
Eddie
-*-
30000 7-JUN 22:33 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29993)
From: EDDIEKUNS To: BILLDICKHAUS (NR)
Yes, I'm using shell+. The reason I'd like to be able to use system() rather
than os9fork() to run extensions is so I can take advantage of the shell's
features like wildcarding. However, I was originally running extensions (still
via system()) by telling them to open their own path to /t2. The problem is
independent of which way the extension gets its path to the serial port. Both
programs (KBCom & extension) turn off XON and XOFF to avoid a garbage XOFF
locking me up!
Thanks for all the help! I just wish I could solve this problem! If only it
weren't so intermittent.
Eddie
-*-
30004 7-JUN 22:56 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29968)
From: MAREK To: EDDIEKUNS
Eddie, I am using a Disto 4in1 board and here is another bizarre tale to add to
your list. Under OS9 I can use the Disto's ACIA with no problem what so ever!
If I try to use a term under RSDOS, TALK ABOUT LINE NOISE most definintely a
timimg problem. Here is the situation.
Take Ultimaterm..I can dial and comm fine..when I go to *ANY* of the online
menus like alt-D for the Disk Menu the modem/acia goes crazy starts getting all
kinds of junk--it doesn't matter wether I am online locally or on any of the
major $ources, to make it even more interesting the problem causes the RD light
on my modem go blinkety blink: that's right the RD not SD but RD. This happens
on *ANY* modem I use.
My solution--I dropped RSDos completely for communication!
-Michael
-*-
30007 7-JUN 23:06 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 30004)
From: EDDIEKUNS To: MAREK
You're problem is backwards from what people normally experience! <Grin> Just
goes to show ya that each CoCo has a unique personality.
Eddie
-*-
30013 8-JUN 21:04 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 30007)
From: MAREK To: EDDIEKUNS (NR)
I just thought you might find that interesting.
-Michael
-*-
30028 9-JUN 03:59 Programmers Den
RE: Aciapak bugs. Chapter 3. <Sigh> (Re: Msg 29977)
From: KNOT1 To: EDDIEKUNS (NR)
Now that's starting to sound a lot like the problem I had! But mine wasn't so
nice as to wait until AFTER I finished a download! You said you did the "diode
hack," but did you also tie the interupt lines in your Multi-Pak (assuming your
using a Multi-Pak) together? I did both of those and I haven't yet had a single
recurrence of the problem.
What I felt was similar was when you said it sent characters after you killed
the process. I wrote (and am still working on) my own terminal program, and
from time to time it would lock up much like you said. Thinking that maybe a
stray XOFF character had been received I went to another window and did a
"display 11 >/T2" hoping that this might help. Nothing happend, the display
command just "locked-up" and nothing went to the modem (no SD light). Muttering
something like "Great! ANOTHER locked-up program" I hit the Break key once and
nothing happend, then I hit it again and I saw the SD light flicker once. The
character was sent out! (Further experimenting has verified to me that that was
the character sent.) This also seem to have "unlocked" the system enough to
exit the program normally (though not to continue using it). I then found out
that closing ALL open paths to the RS-232 pack would restore the system to
normal operation. I then made this a function of my program that would let the
user hit a key (Alt-X in my case) and it would then print "Closing..." and close
any paths to /T2, then print "Opening..." and re-open the paths and restore the
protocol, and then print "Finished." Sometimes it would still lock-up on the
"Closing..." part, but going to another window and doing "display 11 >/t2" and
pressing Break a couple of times would free it up. It's doen't appear to be
important WHAT you display to /T2, just the sending of a signal (2 in this case)
to a process that is currently "locked" in a write (maybe a read also?) to the
RS-232.
Here's something that probably won't help but it might show something. Go to a
window with a Shell running and do a "tmode" to find out its window name. Then
press backspace a couple of times (just to make sure you're not in Shell+'s
"No-Lock" mode). Then go to another window and type something like "echo Hello
there... >/W#" with W# being the other window. It locks-up and nothing shows
up on the other window right? Now, on the window with the locked-up "echo"
press Break TWICE. Still locked up, right? Go look on the other window. Oh
ho! There's the text! And now THIS window is locked up! Now press Break on
this window. ERROR #002 and back at a Shell prompt, right? Now go to the
window with the locked "echo". Hey! Now it's unlocked with an ERROR #002 also!
Odd... yes? no?
WHY any of this does this I don't know, but I hope something here may be of some
help to you. If you have any questions about any of this just ask away! Like I
said, after I did those two hardware fixes I haven't had a single problem of
that type since.
-Jamie (KNOT1)-
-*-
End of Thread.
-*-
29969 6-JUN 19:12 Device Drivers
Ramdisks & 1Meg Upgrade
From: RADARBUZZ To: ALL
I Just ordered the 1Meg upgrade and I seem to recall something about the
RAMMER ramdisk driver (That I presently use) here in the database not working
with 1Meg systems. Can somebody confirm this?
If so, what's a good ramdisk driver to use? I would like one that will free
up memory if I do a deiniz /r0 when I'm done using it. Thanx to any and all
that can provide the info.
-Jeff
-*-
29970 6-JUN 23:14 Device Drivers
RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969)
From: ZACKSESSIONS To: RADARBUZZ (NR)
Yes, the word is that Kevin Darling's RAMMER ramdisk driver will NOT work
properly on a system with the Disto 1MEG upgrade. Best bet is the RAM driver
with the "Development Pack" if you're lucky enough to be able to get a copy. I
understand that Tandy warehouses are running out fast!
Zack
-*-
29971 6-JUN 23:15 Device Drivers
RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969)
From: EDDIEKUNS To: RADARBUZZ (NR)
Right. RAMMER will *not* work when you have the full 1-meg enabled. This is
because it manipulates the GIME directly. I switched to the Dev Pak RAM disk.
It works fine, but stores the size information in a really weird place in the
descriptor! (SCT -- Sectors / Track -- is where it stores the # of 256-byte
sectors you want. I guess it considers the RAM drive to be one HUGE track!)
Eddie
-*-
29988 7-JUN 18:43 Device Drivers
RE: Ramdisks & 1Meg Upgrade (Re: Msg 29969)
From: DODGECOLT To: RADARBUZZ (NR)
Look in the Device Driver database- there is a new VDD ramdisk driver in it
which fixes a bug in the original VDD from the developer's system. Note that you
don't need the original VDD to use it- your old /r0 descriptor will require a
few changes, tho. I think there are some docs included in the file.
-Mike
-*-
End of Thread.
-*-
29972 6-JUN 23:17 Graphics & Music
Weather Radar
From: ZACKSESSIONS To: PAULSENIURA
Paul,
I downloaded your "Weather_Radar" package last night, and I have a few comments,
it I may.
First of all, the VEF pic file you include is not exactly in "true" VEF format.
The first two bytes of a VEF pic file from a Type 8 window whould be $0000, not
$0008. And the file length should be 32018, not just 30738 bytes. After I
patched the $08 in offset $0001 to a $00, it displayed just fine, even though it
didn't fill the screen.
But, really, a FINE job of creating a map of Oklahoma. Even with _county_ lines!
Now how 'bout us poor folk who lives elsewhere in the US of A? Color Weather
Radar sites do cover most of the country y'know. Someone from each state gonna
have to take it upon themself to spend the time creating a VEF map of their
state?
Now, as to getting the data to plot in the first place. When you mention, "I
hope we can get a tie-in to the NWS for access to their current B-Scan weather
files.", I assume you mean Delphi or GEnie? Well CompuServe has been getting
this feed for years. Do they have a monopoly on it? Why can't someone else, ie,
Delphi or GEnie, make this data available also?
Lastly, in case you're interested, I have already written a little ditty which I
use to "put the maps in motion". I download GIF format maps from CompuServe
(only because Delphi don't have 'em!), convert them to VEF with GIF2VEF, and
then use my animation program to put them into motion. Looks REAL neat. Just
like the Weather Channel! (btw, anyone besides me remember when all the Weather
Channel did was scan a TV camera back and forth on a bunch of instruments!)
Comments?
Zack
-*-
29973 6-JUN 23:22 General Information
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29945)
From: PAULRINEAR To: PAULSENIURA
Very interesting piece of writing and I agree on most counts. The
one thing I take exception to is graphics on the COCO3. Can you think of
a nice piece of action game software that will prove me wrong when I say
COCO3 graphics are "coarse and slow". I'm comparing this to the Nintendo
Entertainment System. Entertainment System.
Paul
-*-
30027 9-JUN 03:57 General Information
RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29973)
From: KNOT1 To: PAULRINEAR (NR)
I'm assuming you haven't seen "Zenix" from Gosub Software! Give it a try if you
can and reconsider that exception!
-Jamie (KNOT1)-
-*-
End of Thread.
-*-
29974 6-JUN 23:23 Device Drivers
RE: burke vs disto 4/1scII (Re: Msg 29964)
From: TARDOS9 To: MAREK
Marek,
Did you attempt to disable the hard drive controller rom to correct this. It is
my uns
understanding that it is this rom that overwrites this address space, so
THEORITICALLY disabling the rom should resolve this?
Thanks for your response.
-*-
30002 7-JUN 22:49 Device Drivers
RE: burke vs disto 4/1scII (Re: Msg 29974)
From: MAREK To: TARDOS9
Actually I didn't try do do that. But the code slot-switches the MPI anyway
and it appeared that *ALL* interrupts were being switched to one slot or the
other hence the problem.
:I inherited the B&B and got no docs on the controller (a DTC 5150 CRH) so II
haven't the faintest idea which jumpers to move.
sorry I couldn't be more help.
-Michael
-*-
End of Thread.
-*-
29975 6-JUN 23:56 Telcom
RE: OSTERM (Re: Msg 29940)
From: ELM To: GREGL
Thanks, I'll try that log on combination.
-Len
-*-
30023 9-JUN 00:51 Telcom
RE: OSTERM (Re: Msg 29922)
From: RICKADAMS To: ELM (NR)
I have that "garbage characters" problem with Telenet whenever I log in using
some OS9 terminal programs and starting out with three carriage returns.
Starting out with <RETURN> . <RETURN> (a return, a period, and a return) sets
things up to work ok.
-*-
End of Thread.
-*-
29976 7-JUN 00:29 Grits & Gravy
Interleave factor
From: KENHALTER To: ALL
Am I correct in assuming that "sector interleave" is to os9 the same as "skip
factor" in rs dos? If not, what's the difference?
I'm writting a quick disk to ramdisk dump program but it only works fast if I
know the exact order that the sectors are in.
Any help will be appreciated. Ken Halter
-*-
29978 7-JUN 00:48 General Information
New Guy
From: PAULRINEAR To: ALL
Greetings,
I am brand new to this service and would like to say hi.
Also, have a question: are most of the files available here
compressed or not? I downloaded something out of the utilities
section and can't get it to work.
Paul
-*-
29984 7-JUN 03:43 General Information
RE: New Guy (Re: Msg 29978)
From: TIMKOONCE To: PAULRINEAR
Paul,
Many of the files are compressed with the "AR" or "PAK" programs. You should
probably start by downloading both of these from the Utilities database.
Ask if you need more help,
Tim Koonce
-*-
29995 7-JUN 22:08 General Information
RE: New Guy (Re: Msg 29978)
From: EDDIEKUNS To: PAULRINEAR
Many files are archived with ar or pak. You can tell when the files have an
extension of '.ar' or '.pak' that you need to use the respective program to
dearchive them.
Eddie
-*-
30003 7-JUN 22:50 General Information
RE: New Guy (Re: Msg 29995)
From: PAULRINEAR To: EDDIEKUNS
Ed,
This one turned out to be a C source program. Surprise!
It's called "phony.c" anyway, it wont compile. I keep getting
a bad identifier error in line 65, but the file doesn't seem to
have a line 65.
Paul
-*-
30006 7-JUN 23:04 General Information
RE: New Guy (Re: Msg 30003)
From: EDDIEKUNS To: PAULRINEAR (NR)
During the compile ... does it show you the line it's complaining about? If you
could post here the line that's dieing and the couple around it, we might be
able to help out. (Assuming a program with the name phony.c is meant to
compile! <Grin>)
Eddie
-*-
30009 8-JUN 18:46 General Information
RE: New Guy (Re: Msg 30006)
From: DODGECOLT To: PAULRINEAR (NR)
POssibly you have some padding at the end of the file? This will make the
compiler complain alot (or if you give it to ASM, it will crash!)
-Mike
-*-
End of Thread.
-*-
29979 7-JUN 01:10 Device Drivers
RE: 720K DISK DRIVE (Re: Msg 29954)
From: MCIRISH To: MARTYGOODMAN (NR)
HI MARTY, I TOOK THE DRIVE BACK AND ASKED THEM TO RUN IT ON ONE OF THEIR 1000'S,
THEY DID AND IT DIDN'T WORK. THEY REPLACED IT FOR ME AND EVERY THING IS GREAT
NOW. I DON'T NOW WHAT TO DO WITH ALL THAT SPACE ON ONE DIS KNOW WHAT TO DO WITH
ALL THAT DISK SPACE, BUT I'M SURE I'LL THINK OF SOMETHING. THANK ALOT FOR THE
HELP, IF THERE IS ANYTHING I CAN DO FOR YOU, LET ME KNOW.
---JOE
-*-
30012 8-JUN 20:40 Device Drivers
RE: 720K DISK DRIVE (Re: Msg 29979)
From: DCJR To: MCIRISH (NR)
There's only ONE thing to do with disk space....
Fill it up...<grin>
DCJR(Doug James)
-*-
End of Thread.
-*-
29980 7-JUN 02:02 General Information
RE: Pictures Needed (Re: Msg 29905)
From: DALEP To: DICKWHITE (NR)
Dick,
Thanks for the reply. Yep, your on track. We're looking for pictures ... an
anecdotes.
I have a transcript of Jim Reed's interview with you ... but hope to be back in
touch with you by phone when we get this thing organized.
Right now, it's all a bit overwhelming ... I've finally made it up to March of
1983 ... with just a list ... no details. But, we're plugging away.
Again, yes we can use your pictures!!! Interesting that my basement fits the
same definition.
Best Regards,
Dale
-*-
29981 7-JUN 02:05 General Information
RE: kissable os9 (Re: Msg 29949)
From: DALEP To: TEDJAEGER
Ted,
Thanks,
We're plugging away on a Gradebook program for the September issue now. Hope
you will find it useful. That's the education issue. We have already completed
a column for July and August so you should see one soon. BTW if you have any
anecdotes for the
CoCo History Book ... or know anyone who does ... please let us know here.
Thanks Again,
Dale
-*-
30010 8-JUN 20:33 General Information
RE: kissable os9 (Re: Msg 29981)
From: TEDJAEGER To: DALEP (NR)
I'll look forward to the gradebook issue! I forgot if I mentioned it but I am a
college professor--teach psychology. --Bests, TedJaeger
-*-
End of Thread.
-*-
29982 7-JUN 02:24 Graphics & Music
RE: graphic (Re: Msg 29938)
From: TIMKOONCE To: NES
If you're interested in viewing 16 grey-scale images, take a look at Mike
Haaland's "ViewPIX" viewer for some ideas. Also, my VIEW program can display
pictures in DS69B "PIX" format. Details on that picture format are in the
databases as well.
As for OS9 drivers, a number of people here can help you with it. The best
place to start is to probably look at the source for some of the drivers in the
databases here. As a hint, it might be easiest to write the driver as an "SCF"
driver, so you could carefully study the technical reference section of the OS9
manual to find out more.
- Tim Koonce
-*-
30001 7-JUN 22:48 Graphics & Music
RE: graphic (Re: Msg 29982)
From: NES To: TIMKOONCE (NR)
Thanx for the info
Eric Stringer (NES)
-*-
End of Thread.
-*-
29983 7-JUN 03:10 General Information
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29946)
From: TIMKOONCE To: PAULSENIURA
As Eddie already pointed out, one BIG difference between CoCo/OS9 and those
other systems is simply that they've been out a lot longer, and a lot more
people are using them. Software takes time to develop; time measured in YEARS,
not in months or weeks. CoCo3/OS9 has only been out for about 3 years, which is
a very short time. ONt op of that, there aren't very many users, and few of
those users are willing to shell out the money it costs for high-quality
software. I experienced heavy-duty culture shock recently when I talked to some
people about a Mac terminal program... the program sells for $300, and the
company was getting calls from people who were asking how to use it with $600
modems attached to their $5000 computers. People with $129 systems probably
don't have $300 for a terminal program! Which tends to not attract the big
commercial houses.
OS9/68000 does have a lot of free software already: UUCP, ARC, Hack, gobs of
Unix stuff, and it's growing fast. Kevin Darling, Inc. knows CoCo3 windows
pretty darn well, and one of the TOP priorities for the MM/1 from KLE is
CoCo3-compatible windows. It'll be there!
BTW, you don't need SBF to drive a tape, you can just write an SCF driver. Tell
us what you know, and maybe people on here can help you with that tape drive. A
lot of people have been interested in getting decent tape drives, and maybe you
have the information and motivation to get it working! Good Luck!
- Tim Koonce
P.S. Unfortunately, CoCo3/OS9 has never been an "out of the box" system. KLE or
FHL should doubtless do better.
-*-
29985 7-JUN 03:55 General Information
RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29946)
From: TIMKOONCE To: PAULSENIURA
Hmmm.... A lot of people would argue with you over some of those things being
"standards". Personally, I don't consider SEA ARC or FIDO quite the "standard"
that you seem to. And ANSI is pretty far from a standard in my opinion. But,
then again, I suppose someone who works with IBM mainframes might not consider
Compress, TAR, or UUCP very "standard", either. (I have the first two already on
OS9, and word is that UUCP will be ready by the end of the summer.)
- Tim Koonce
-*-
End of Thread.
-*-
29989 7-JUN 19:19 Programmers Den
RE: Aciapak blues -- Chapter 2 (Re: Msg 29935)
From: BILLDICKHAUS To: EDDIEKUNS
The following assumes you are using the stock LII ACIAPAK or at least a patched
version of it. If you are using a later version or an alternate driver (like
DACIA), then things are a little different.
Also be aware that the handling of _ss_rel and _ss_ssig are up to the device
driver, so this answer only applies to ACIAPAK. I'm also not sure whether SCF
does anything "automatically", but I don't think so. (Kevin?)
Any active _ss_ssig is cleared when the device is initialized. A device is only
initialized when a path is opened to the device, and the device user count is
zero. If the device has been INIZ'd, or there are other processes with the
device open, then an additional open will not cause the device to be
initialized. An active _ss_ssig is also cleared whenever an SS.ComSt setstat is
issued, either explicitly, or implicitly when an SS.OPT setstat is issued with
the bau/par values changed.
Bill
-*-
29998 7-JUN 22:25 Programmers Den
RE: Aciapak blues -- Chapter 2 (Re: Msg 29989)
From: EDDIEKUNS To: BILLDICKHAUS (NR)
Yes, I'm using a patched version of Aciapak. So does that mean if you issue an
SS.OPT with the *same* values then it will *NOT* issue a SS.ComSt? Basically,
since I'm already using 8N1 and the baud rate doesn't change, all I do is issue
3 _ss_opt() calls with the settings I have already. (One in XYModem to set up
the way we want it. Another when it quits to reset to original settings.
Another in KBCom to make sure the extension was nice.)
Do you have any idea what conditions will cause Aciapak to freeze?
Eddie
-*-
End of Thread.
-*-
29999 7-JUN 22:26 General Information
RE: Config (Re: Msg 29429)
From: RTHOM To: GREGL
I with you, Greg! I HATE manuals that tell me what can be done without telling
me how to do it--not even giving me a hint where to start! But I also agree
that there is such a thing as too MUCH simploicity. Come down to it, I doubt
there's much differen ce in our view of the problem. (Or "views", I guess...)
Ray
-*-
30005 7-JUN 23:02 General Information
MM1 demo
From: NES To: ALL
I just got thur seeing a demo of the complete MM1 system (or 2001 system if you
think of the letters as Roman numrals). It run's under os9 with the coco 3 type
windows, I was impress with the graphics demo, they where showing GIF's on a
CM-8 320 x 400 256 colors. You wouldnt beleve the CM-8 could produce VGA
graphics, as well as it did with the MM1, also set up an 120 x 60 text window,
and you could read it. I was just blown away by the show KLE put on for our
coco club. Keven Darlin(sp) has done a top job of writen the graphics display
program for the MM1. and all the others who are putting together the MM1. -NES
-*-
30031 9-JUN 04:41 General Information
RE: MM1 demo (Re: Msg 30005)
From: SANDRIDER To: NES (NR)
Thanks for the mini-review! I'm very excited about this new machine, and any
little tidbit you can drop our way are most appreciated. How fast was the GIF
decoding?
CRW
(P.S. Yep... I'm new to Delphi... first message. Greetings everyone!)
-*-
End of Thread.
-*-
30008 8-JUN 18:18 Graphics & Music
framed window within a framed window
From: ZACKSESSIONS To: NES (NR)
Eric,
About that programming problem you are having, opening an overlay window on a
Framed window and attempting to WnSet the OW to a Framed window, too, as you are
seeing, I don't think that will work. I did mention one workaround, writing the
code which would run in the OW as a separate binary and fork a process to it in
the overlay. I know that will work, but may cause programmatic problems, like
how to send data obtained in the forked OW back to the original program?
Here's an idea (and I think Kev has mentioned this once already).
1) Do a GetBlk on the area in the Framed window equal to the size of the OW you
were trying.
2) Unprotect the current window.
3) Open a path to the next available window.
4) DWSet the window, and the WnSet the window.
5) Do the processing you need to do in the window.
6) close the window with DWEnd and close the path to the device.
7) re-protect the current window.
8) PutBlk the buffer back on the window.
9) KilBuf the buffer sinca ya don't need it anymore.
Does all this make any sense?
Zack
-*-
30011 8-JUN 20:37 General Information
hardware hacking
From: TEDJAEGER To: ALL
I have access to an old RS 5 meg hard drive which I figure I could use under
os9. I have the 15 and 35 meg descriptors that RS distributed with Level 1 ver
2.0 but no 5 meg descriptor was ever issued. Dumped the two descriptors and see
that they are different at offset $16-19 and $24-2A. I guess a 5 meg descriptor
could be made by patching at these locations so does anybody know what these
bytes indicate or what values they should have for a 5 meg drive? I do have the
RS HD interface and cc3hdisk. Thanks--TedJaeger
-*-
30014 8-JUN 21:15 Programmers Den
Shell+ 2.1 and Vi
From: MAREK To: ALL
Here's an interesting problem for all you programmers
I recently applied Rick Adams' vi patch to TSEdit..when I name this file "vi"
and try to run it from the OS9: prompt nothing happens! Iit seems that Shell+
recognizes the letters v and i as commands. so IF you are using Shell+ with
Ricks patches rename it to something else.
-Michael
-*-
30015 8-JUN 22:22 Programmers Den
RE: Shell+ 2.1 and Vi (Re: Msg 30014)
From: ZACKSESSIONS To: MAREK
Do you have King's Quest III or Leisure Suit Larry? Do you then have the VI
module in your bootlist? CONFLICT!
-*-
30017 8-JUN 23:26 Programmers Den
RE: Shell+ 2.1 and Vi (Re: Msg 30015)
From: MAREK To: ZACKSESSIONS
Nope...The KQ3's Vi is in a completely separate dir. I have the TSEdit/Vi in my
CMDS dir on my drive.
I am pretty sure that the problem is the fact that Shell+ 2.1 is only seeing the
v to turn off variable expansion and that is as far as it gets perhaps if you
have access to Ron Lammardo you might check and see..but as it stands "vi" named
vi will not fire up from the OS9 prompt...at least not on my system.
BTW: I have the wildcard option turned off in Shell+
-Michael
-*-
30018 8-JUN 23:34 Programmers Den
RE: Shell+ 2.1 and Vi (Re: Msg 30017)
From: ZACKSESSIONS To: MAREK (NR)
You mean you load vi for KQ3 when you need it and do not include it in your
OS9Boot?
Zack
-*-
End of Thread.
-*-
30016 8-JUN 22:59 Utilities
RE: HDB/HDR (Re: Msg 29263)
From: COCOXT To: JOHNREED (NR)
HDB streams out all allocated sectors by increasing LSN; it doesn't follow any
tree or file structures. Also, it stores the actual LSN of each piece of data
with that data. Since the LSN's would be the same on any type of disk, all you
should have to change is the backed-up version of the hard disk's LSN0. To do
this, take the 1st backup disk and use a disk editor on the file H0BACKUP1 (or
whatever it's called). Look at the first sector of the file. It begins with a
3-byte header that gives the LSN (should be $000000), followed by the 1st 253
bytes of the sector. Look up the format of the ID sector in your OS9 tech
manual, and change the number of heads and tracks at the offsets + 3 given.
This will only work on a non-compressed disk. Please work on a backup of your
1st disk, and please call if you are at all unclear about the instructions
above.
Chris Burke (206) 432-1814
-*-
30019 8-JUN 23:41 General Information
RE: The T.O.P.S User Group (Re: Msg 29932)
From: TJMARTIN To: KEITHMARCH
Is there a TOPS group in Japan also? I know of the one based in Munich, West
Germany. In case you do want more info (don't have it already), I uploaded the
index file from TOPS listing the contents of their software release as of a
while ago. I submitted the fie file to OSK data base. More info possibly on
GESPAC BBS at 602-962-5940.
-*-
30034 9-JUN 12:59 General Information
RE: The T.O.P.S User Group (Re: Msg 30019)
From: KEITHMARCH To: TJMARTIN (NR)
Hi
Where is that in the 68K Database?
There are only 4 entries.
Keith
-*-
End of Thread.
-*-
30020 9-JUN 00:16 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29898)
From: RAGTIMER To: EDDIEKUNS (NR)
Well, maybe the ANSI C standard is part of a plot by Intel and MicroSoft to
cripple Motorola prociessors down to where Intel can compete on even ground. I
mean, define C so that auto-inc/dec modes can't be used, and an 80386 is almost
as good as a 68000.
Funnt how the additions to the 80186 were mostly catch-up-to-68K. (That's
"Funny").
-*-
30021 9-JUN 00:19 General Information
RE: New C compiler bug! (newly found) (Re: Msg 29914)
From: RAGTIMER To: GREGL (NR)
Oh yeah, right -- good luck transferring binary data (or C code) between Moto
and Intel. By the way, I've read that Intel's little-endian byte ordering makes
graphics bit mapping shifts a real pain. Notice how all the graphic computers
were 68K based, until INtel got up to the 80286 or so?
-*-
End of Thread.
-*-
30022 9-JUN 00:24 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 29943)
From: RAGTIMER To: MIKEHAALAND
Being your own dealer -- must be a pain at times. Well, I saved the box and
packing for my 220. Don't use it much, so could loan it to you. Maybe send you
a couple printouts from ColorMax3 (NOT Coco-Max 3) to reverse-engineer. But I
hope you can find one of your own. I know that the RS Computer Centers still
stock, or can order, the ink carts for it. Say, did you know it contains a
6809? --mike k
-*-
30025 9-JUN 03:05 Graphics & Music
RE: MVCanvas 2.0 (Re: Msg 30022)
From: MIKEHAALAND To: RAGTIMER (NR)
Mike,
I tried to write the driver (it's done I think) but I need someone to test it
for me. You willing to give it a shot? Just in case I sent you the driver in
and AR file in E-Mail. Lemme know if it works for ya,
Mike H
-*-
End of Thread.
-*-
30024 9-JUN 02:38 General Information
General Information
From: JENG To: NES (NR)
Thanks once again for that first hand experiance in regards to the MM/1 demo at
Charlotte N.C. Theres new announcements for the MM/1 and Frank Hoggs TC70 (68070
CPU) in the Database New Upload area. Hopefully Paul Ward and Frank Hogg will
keep us up to date on their computers. Both sound exciting and I hope both will
be compatible in the software end! But its good to see two different approaches
in the hardware area,friendly competition is advantageous to the OS9/OSK users!
JENG
-*-
30026 9-JUN 03:56 General Information
RE: Shell+ (Re: Msg 29752)
From: KNOT1 To: BRIANWHITE (NR)
All excellent points about upgrades to Shell+. Just a small item I would like
to add. When you enter a line like:
OS9:chd /DD/CMDS ; fstat d*
Where you have both multiple statements separated by semicolons and wildcards,
it seems that all wildcards on a line are expanded before ANY statements are
executed. It would be better wildcards were only expanded up to a semicolon
until after that statement is executed, then expand she wildcards up to the next
semicolon/end-of-line and so on.
Just felt like putting my own two cents in.
-Jamie (KNOT1)-
-*-
30029 9-JUN 04:33 Utilities
PCDOS cmd, & CC3Disk patch
From: PAULSENIURA To: ALL
Whoops -- I cannot find the required CC3Disk patch as stated in the PCDOS.AR
file. The included zap does not produce the required edition/CRC of CC3Disk.
The docs say PCDOS needs the Edition #11 with CRC $E11F29. I looked & looked,
both here and on Delphi. Quite some time back, on CIS, we logged some bugs wBob
Santy on the at-that-time latest PCDOS command.
If someone's got that patch, and it works correctly on 3.5-inch 720k "real" IBM-
PC formatted diskettes, could ya upload it ASAP?
You see, something came in the mail today. Something from SEA. Something we
can't read! hint hint. Arc 6.02 sources! It's archived in a 260k file, and I
unarc'd it at the office with real Arc 6.02 on a PS/2, but it is all on a 720k
diskette and bled over to a second volume.
The original bug as told to Bob Santy more than a year ago hasn't been fixed
yet. We can't read more than about 128k into a 720k diskette. Not I/O errors
from the drive, not hardware problems, the program/patch combination gets lost
after that much disk is read in. No matter how big or small each file is on the
PC diskette.
I would try the correct zap to CC3Disk first, then see if we can read the entire
diskette. If not, I dunno what to do except spend $100 to order SDisk3 and
PCDOS utils from D.P.Johnson &/or GCG. That takes a whole bunch of time &
money. Not worth it! I'd rather kludge Arc 6.02 sources into small 5-inch SSDD
160k diskettes, then remerge everything back together.
Please if someone has the CORRECT CC3Disk patches for PCDOS requirements, let's
have a peek, please? Then we can get crakin' on porting this dude over ...
-- Thx, Paul Seniura.
-*-
30030 9-JUN 04:36 Utilities
RE: PCDOS cmd, & CC3Disk patch (Re: Msg 30029)
From: PAULSENIURA To: PAULSENIURA
Ah oh, I should've said I looked here and on GEnie!
I don't have an account on CIS, but I got a little kit I could open up. I wonder
what all we're missing here that is happening on CIS. Is it worth twice the
bucks-per-hour? (Delphi Advantage rates, is it worth THREE times?)
-*-
End of Thread.
-*-
30032 9-JUN 09:46 General Information
RE: Pictures Needed (Re: Msg 29878)
From: IVANSC To: DALEP (NR)
Hi DALE!!! Glad to see you are not giving up on KISSable OS-9. I have
actually been around for some time & spent a little time with you Kkevin D and
Kevin P at last years CHhicago fest - sadly time & money have precluded any more
recent attendances! E njoy Toto country!
-*-
30033 9-JUN 12:25 General Information
Questions about the MM/1
From: KEITHMARCH To: PKW (NR)
Hello Paul:
I have some questions about the MM/1 and OS-9/68K
1) Is there a WEFAX/HAM program for OS-9/68K?
2) Will the MM/1 support the RAVE package?
3) What is the System ROM, How many K?
4) If a person does not buy the I/O Board with the Main
CPU Board, can you use the Smartwatch RTC chip in the
EPROM Slot used for OSK?
5) Is there a DMODE command for OSK?
6) Is there a terminal program that supports X/Y/ZModem?
7) Does the BASIC that comes with the MM/1 have a CLS command
built in?
8) Later on, can users pull out the 68070 15 Mhz chip and put
in a fast chip. Is the CPU socketed?
9) If I format a 3.5" 720K DS/DD Floppy Disk under OS-9/Level II
can I read/write to it useing the MM/1 and OS-9/68K or do I have
to reformat it to use it?
10) Will most programs use the 'F##' keys on the IBM Clone Keyboards?
11) Will the MM/1 have/be able to use, a Math Coprocessor?
12) Will all major chips be socketed?
13) Are you/Will you be, working on a book called 'Start OS-9/68K?
14) How will we change are BOOT File in the EPROM?
a) Buy a EPROM burner.
b) Boot off of floppy from that point onward.
c) Send the EPROM back to you with patches on the disk
and pay for the reburn.
d) Pull hair out while tring to figure out what to do.
Thanks for the help!!!!
Keith
-*-
FORUM>Reply, Add, Read, "?" or Exit>