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

1706 lines
56 KiB
Plaintext
Raw Blame History

read new nonstop follow
87743 3-JUN 16:59 Programmers Den
RE: Programming in C (Re: Msg 87742)
From: BOISY To: MROWEN01
If you want functionality of inkey$ under OS-9 in C, do this:
char c;
read(1, &c, 1);
If the read was successful (you can check the return value for this), then
'c' will hold the character typed. Notice that you must pass the address
of the character (&c) to the read function so that it will receive the
*address* of c, not the value of c.
Good luck.
-*-
87746 3-JUN 20:05 Programmers Den
RE: Programming in C (Re: Msg 87743)
From: COLORSYSTEMS To: BOISY
> char c;
>
> read(1, &c, 1);
BOISY!!
Shouldn't that be:
read(0, &c, 1);
------------------------------------
Zack C Sessions
"We did not inherit the Earth from our Ancestors,
we borrowed it from our descendants." Ancient proverb
-*-
87747 3-JUN 21:02 Programmers Den
RE: Programming in C (Re: Msg 87746)
From: BOISY To: COLORSYSTEMS
Ouch! Yeah! What was I thinking? <g>
read(0, &c, 1); reads from stdin. Sorry bout that.
-*-
87763 4-JUN 12:11 Programmers Den
RE: Programming in C (Re: Msg 87742)
From: JHICKLE To: MROWEN01
I like to use this:
setbuf(stdin) = NULL;
key = getchar();
It may not be too portable, but you can switch between buffered and unbuffered
stdin as needed (setbuf(stdin) = BUFSIZE; --> sets buffer to what it originally
was). I used this in a word processor where it was necessary to catch every
keystroke, then test to see if the key called a function or was to be inserted
in the text buffer; but I also had to turn buffering back on for processing
dialog boxes.
-*-
87764 4-JUN 16:54 Programmers Den
RE: Programming in C (Re: Msg 87763)
From: COLORSYSTEMS To: JHICKLE
> It may not be too portable, but you can switch between buffered and
> unbuffered stdin as needed (setbuf(stdin) = BUFSIZE; --> sets buffer to
There is no way to get one character from standard input with C and
write it so that it will be 100% portable. This whole thing about
portability is taken too far sometimes. Best you can do is write your
own little inkey() function using whatever OS9 Level 2 specific
system calls you prefer to use and if you want to port your app later
to some other OS, you only have a few low level functions to adapt.
------------------------------------
Zack C Sessions
"We did not inherit the Earth from our Ancestors,
we borrowed it from our descendants." Ancient proverb
-*-
87768 4-JUN 21:21 Programmers Den
RE: Programming in C (Re: Msg 87764)
From: MITHELEN To: COLORSYSTEMS
And, if you want to keep the code "portable" just:
#ifdef _OS9
/* your inkey() code */
#else
/* some other system */
#endif
This is why the #ifdef directive is there, for tose cases when you HAVE to
do something that is gonna be machine/compiler specific.
--
Paul
-*-
87769 4-JUN 22:15 Programmers Den
RE: Programming in C (Re: Msg 87763)
From: MROWEN01 To: JHICKLE
Thanks for the C tip. I tried doing this but I didn't know how to get
stdin buffer turned off. This will help greatly.
Mike
-*-
87770 4-JUN 22:17 Programmers Den
RE: Programming in C (Re: Msg 87743)
From: MROWEN01 To: BOISY
Thanks for getting me through this C problem. Every reference to the read
function says to use pointers. It never dawned on me to use & with the
variable. This will help me alot! Thanks again.
Mike
-*-
87810 7-JUN 20:10 Programmers Den
RE: Programming in C (Re: Msg 87764)
From: JHICKLE To: COLORSYSTEMS
I can now code with about 95% portability; I keep it in a fake leather
covered case, with spring latches and a handle. The only portablity
problems i have now occur in extremely wet weather or if there is a
sudden change in air pressure.
-*-
End of Thread.
-*-
87744 3-JUN 18:54 General Information
RE: Internet (Re: Msg 87726)
From: CPERRAULT To: ETJ
Well, right off, you can mail Eddie Kuns(eddiekuns) who is the author of
Kbcom, if he hasn't seen your message already. Last I heard he was getting
ready to release a new commercial version of KBCom which, someone correct me
if I'm wrong, include transfer protocols<xmodem,ymodem, and maybe? zmodem>
built in. In order to use transfer protocols, you need define them as
extensions<that is what an extension is, simply a seperate program, such
as an autodialer or stand alone protocol, which is called from KBcom>, which
are accessed as a hot key. This really isn't very hard, and the documentation
does a pretty good job of explaining how to do that. Last I heard, the Coco
version of KBcom cost maybe 39.99 but that was a while back. It isn't a bad
price at all, and will be much more worth it if the update comes out :-0)
I'm glad you brought that up, as I was wondering how KBcom was coming along.
Also another thing to consider. Unlike most other terminal programs KBCom
is considered more of a 'terminal envirnment' where it pretty much serves
as a front end for the protocols and other outside programs<extensions> and
macros you include. It doesn't include much as is except for the terminal
emulations, which it has a good variety of for Coco term
programs. It has one of the best implementations of vt52/vt100 from what I
understand. Anyhow, while this offers great flexibility,
I wouldn't recommend such a beast to a beginner<the shareware version that is,
Hopefully the commercial version is a little easier to set up and handle>. I'm
still having a hard time with a few things<I work with it here and there, but
do get discouraged sometimes>, but once you manage to make it work, it is a
pretty full featured program.
>Chris<
-*-
87760 4-JUN 06:23 General Information
RE: Internet (Re: Msg 87744)
From: ETJ To: CPERRAULT
Chris:
Thanks for the reply. I will get in touch with Eddie Kuns and see what
he has to offer. Long live the CoCo.
-*-
End of Thread.
-*-
87745 3-JUN 19:27 General Information
RE: Puppo Interface (Re: Msg 87731)
From: JRUPPEL To: CHARLESAM
"He laughs loudly as he reaches for his coffee cup and soldering pencil..."
Coconuts in Lansing!
John
-*-
87748 3-JUN 21:11 OSK Applications
RE: games (Re: Msg 87734)
From: VAXELF To: COLORSYSTEMS
Findlly won at Pyramid. Had to play 47 games before I won one.
BUT, I love it.
John D.
-*-
87749 3-JUN 22:41 Telecom (6809)
RE: InfoExpress (Re: Msg 87711)
From: DSRTFOX To: PAUL8
Heck, I'd have had to go to Atlanta to get a train, and the bus would have
been a nightmare! If I didn't have musch to bring other than myself, I
might go that route... or take the bike! 16 hours in the saddle of a GS1000...
, huh?
-*-
87803 6-JUN 22:34 Telecom (6809)
RE: InfoExpress (Re: Msg 87749)
From: PAUL8 To: DSRTFOX
Here I was counting on going to Atlanta where the hotel is better situated
than in Chicago and I plumb forgot about the reservation in Oct I made for
the ARRL convention in Boxborough,Ma. It may not be a convention but tis
something we go to if for no other reason than to say hello to those we have
not seen for sometime.
The second wk in July I will be busy volunteering, I have another week
comming to me and just might spend it in Atlanta, never thot of that until
just now. Thanks for the reminder.
Paul
-*-
87812 7-JUN 20:59 Telecom (6809)
RE: InfoExpress (Re: Msg 87803)
From: CPERRAULT To: PAUL8
Hmm, what's the ARRL? I'm from mass also, so it just got my attention :-)
>Chris<
-*-
87823 8-JUN 02:12 Telecom (6809)
RE: InfoExpress (Re: Msg 87812)
From: COCOKIWI To: CPERRAULT
Amauter Radio Relay Leage=ARRL.............<grin>..Ham Radio nuts!....
Dennis
-*-
87825 8-JUN 07:37 Telecom (6809)
RE: InfoExpress (Re: Msg 87812)
From: JEJONES To: CPERRAULT
> Hmm, what's the ARRL? I'm from mass also, so it just got my attention :-)
ARRL = American Radio Relay League; it's an organization for US amateur
radio operators.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
87828 8-JUN 18:21 Telecom (6809)
RE: InfoExpress (Re: Msg 87812)
From: PAUL8 To: CPERRAULT
I am an Amateur Radio Operator, ARRL is American Radio Relay League.
Paul
N1LRT
-*-
End of Thread.
-*-
87750 3-JUN 22:47 General Information
RE: Nitros-9 and games (Re: Msg 87737)
From: CHARLESAM To: KSCALES
As far as vdgint goes, I don't use it. These games work fine without Nitros9.
As a matter of fact, the biggest increase in graphic screen speed is in the
Nitros9 patch for grfdrv. With just this patch alone, I see a marked
improvement in all my games. If I can't get this resolved, I'll just make a
separate boot for games. I have a feeling its CC3IO thats causing the crash.
I have a few more things to try so I'll keep my fingers crossed. Thanx for
the input. Charlie
-*-
87751 4-JUN 00:04 System Modules (6809)
RE: Ramdisk (Re: Msg 87690)
From: WDTV5 To: JRUPPEL
Somehow, I get the impression we're playing "Can You Top This" :))
Humm, I just had a weird go-round with an Ensoniq EPS and an older ST-251n.
Absolutely nothing we could do would make tham talk to each other. In des-
peration I even went so far as to install source terminations on the termless
scsi board, some aftermarket thingy thats been orphaned for 5 years at least.
No soap. Put terms on the drive, no go. Added a foot of cable, got error out
even quicker! Finally got p!**ed and reversed the power on the terms on both
ends of the cable so the resting voltage on an open line was around 3 volts
instead of the standard (I think) 2 volts. Scsi is a law unto itself, but
(knock on wood, like my head) he's now putnearly 250 3.5" floppies worth of
samples and sequences on it without any errors. I recount this because it
might help someone else sometime.
Cheers, Gene
-*-
87771 4-JUN 22:56 System Modules (6809)
RE: Ramdisk (Re: Msg 87681)
From: ROYBUR To: WDTV5
don't know if it'd be legal, but could you just have the ramdisk itself do
a second iniz upon the first iniz? maybe set a flag so that it knows not to
repeat the procedure? or is this just a silly idea? 8*)....roy (who's not
much of an os9 programmer!)
-*-
87781 5-JUN 18:55 System Modules (6809)
RE: Ramdisk (Re: Msg 87771)
From: WDTV5 To: ROYBUR
No, we can't do that. It has already allocated the required number of blocks
(8k each) of system ram (machine ram actually, not system) according to the
value of the var shown as "sct" in the dmode report. My real problem is os-9's
penchant for opening a path to the device in order to use it, thereby
incrementing
the link count os-9 keeps. When the use of that path terminates, os-9 decrements
the link count, and if zero, deiniz's the path(device in this case) which is
why the compiler executives don't report any errors until the second step of
the compile when the file the first step wrote can't be located. The memory
was given back into the free pool by os-9. In fact, the data is still there
mostof the time, but the re-iniz resets the root dir to $40 long and the name
of the file and its data are hidden at offset $40-$5f in the root dir. In
addition, the FAT was re-written, effectivly deallocating the area occupied
by the file. 'sa bit of a catcch-22 that I've had 3 or 4 ideas on how to
fix, but the last 3 days havn't seen the coco turned on, software compat
probs with the Amiga, graduating from the University Of Hard Knocks last
night, and a couple of other items have filled up the time. It will get
done though if I have to write some sort of a routine that lets me access
that linkn count os-9 keeps. So far, diddleing the link count in the device
sector 0, or in the root FD (I forget which at the moment) has not solved
this problem. I have faith that it is solvable, and once I figure it out,
the answer will probably embarrass me in its simplicity. Cheers all,
we're still working on ot. it. Gene
-*-
87816 7-JUN 22:07 System Modules (6809)
RE: Ramdisk (Re: Msg 87781)
From: ROYBUR To: WDTV5
gene, i have no doubt you'll finger it out. busy is good...right? 8*)....roy
-*-
87822 8-JUN 00:08 System Modules (6809)
RE: Ramdisk (Re: Msg 87816)
From: WDTV5 To: ROYBUR (NR)
Yes and no. I'm getting too old and lazy to go too many hrs a day/nite
anymore. And I think I've got it, at least the version in memory right now
is working, albeit with lots of output from os9p4 as it execs that can be
removed, no doubt along with probably another 20 bytes of useless code
here and there. The problem with my original idea of going and accessing
the device table entries while it was doing the autoinit fell flatter than
one of those Carls Road Kill Cafe offerings. On checking out why I couldn't
find my own entry in the device table, I had to go clear back to Kevs Book,
Inside Os-9 Level Two and study the flow charts. It seems the entry in the
device table I wanted to diddle doesn't exist until AFTER the device Init
routine has been successfully performed! So I settled for tickling a zero'd
var during the init, then any read or write, aftere checking to see if the
Init has been done comes back and lbsr's to the new code which checks that
byte, and if its non-zero, goes and finds its entry in the device table and
increments it once only. It clears that tally byte so it only does it once
then and returns to the read/write from whence it came from. Kludgy, but
it works so far, knock on wood. I'll clean it up now which should get it
back under $300 bytes total and submit in a few days after I "alpha" test
it some more. Cheers Roy, Gene
-*-
End of Thread.
-*-
87752 4-JUN 00:12 General Information
RE: Nitros9 (Re: Msg 87698)
From: WDTV5 To: CHARLESAM
You say you have the kernal all patched and sitting in the root of the disk
just as if it was a normal file? Fine, then go get my earlier submission
called "krnlutils" or some such. It contains a routine that will A: Make
a directory entry that points to the existing (old) kernal. Once that is
done, then another util in that package called "krnlmvr" or maybe "krnlmvr.09"
will go get the patched one and copy it over the existing one. One caveat,
they MUST be on different disks because I used "KERNEL" for the hard-coded
name of both files. Yeah, I know, shame on me, I shouldn't have done it
that way. ALSO when you were patching the kernal file you've made, did you
add the few bytes on the tail of os9p1 BEFORE telling kwikpatch to patch it?
If not, then the jump table (thats what those last few bytes are) will not
be correct, crash city. The reworked file must be exactly $1200 bytes long.
Good luck, Charles, Gene
-*-
87785 5-JUN 22:14 General Information
RE: Nitros9 (Re: Msg 87752)
From: CHARLESAM To: WDTV5
Actually Gene, I did the hold job over by gathering all patchable modules,
making a new boot, then letting nitros9 patch the whole thing over. Only
this time its makes a complete boot with only os9p3 missing. I might try
adding that now that I have a working patched boot. One other note; I have
to make a new boot to include CC3IO updated to CC3IO.nv116. That should
solve my games promblem. I got this news from Colin McKay, author of Smash.
I'll keep you posted on any developments. Charlie
-*-
87798 6-JUN 22:22 General Information
RE: Nitros9 (Re: Msg 87785)
From: WDTV5 To: CHARLESAM
Great! Cheers, Gene
-*-
End of Thread.
-*-
87753 4-JUN 00:18 Programmers Den
RE: os9p3 (Re: Msg 87700)
From: WDTV5 To: CHARLESAM
Ded can pad the whole thing, but not an individual module in a merged file
like os9boot. For that, you need Chris Burkes "EzGen" about 1.11 or so. It
has an "x" function wherein you "l"ink to the module, then "xn"where n is
the number of bytes to stretch it. After some disk grinding to move the rest
of the file down by n bytes, its relinked into one file. This does modify
the length in the module header too, and a "V" then run thru the whole thing
fixing any bad header parity bytes and module crc's. I used it on Init a few
times here to adjust the position of everything beyond it. Best blob fix
I've done yet. Do it one byte at a time till the blob is gone. You might
have to add 3 bytes total before its fixed in my experience.
Cheers Charles, Gene
-*-
87786 5-JUN 22:17 Programmers Den
RE: os9p3 (Re: Msg 87753)
From: CHARLESAM To: WDTV5
Great! I have ez-gen. I'll save this message as a future guide to fixing
said problem. Thanx much, Charlie
-*-
87800 6-JUN 22:23 Programmers Den
RE: os9p3 (Re: Msg 87786)
From: WDTV5 To: CHARLESAM
Be my guest. s/b Be my guest. I've been doing it that way for quite a while,
and figured most everyone else had read the manual too. Silly me. Cheers, Gene
-*-
End of Thread.
-*-
87754 4-JUN 00:30 General Information
RE: nitro/lha (Re: Msg 87729)
From: WDTV5 To: VE3DAC (NR)
I doubt that RBF.32 is the LHA problems. I've been using it here since I
uploaded it, along with LHA2.2 (I think thats the latest level 2 version)
and have not had a single instance of a malfunction that I could attribute
to LHA. Using lzh on an lha file wil puke of course, so I keep both handy
just yet, too many things here that were smunched with Matts lzh to delete
it yet.
Off the top oif my head, I'd almost bet its a blob related problem, can you
format a floppy disk without any errors? Thats the first test for the blob.
BTW, the RBF from 1.15 is (as is the 1.16 version as far as I can tell from
my dis-mantleing of them) is/was based on the stock ed 28, not on Kevs ed 30.
Mine is based on ed 30 but nativized and also has the archive byte patch the
canadien fellow (name slips my mind right now) had proposed we use. It has
no effect on the operation of rbf in any way UNTIL it needs the 48th segment
allocation for a file. The fix for that is that if you know a big file is
coming in, like over 100k, have dmode set the sas up to FF before the dl os
is started. That way the segment list won't get used up until the file is
multimegabyte in size.
If there is a problem with RBF.32 that can be pinned down to RBF.32, everyone
PLEASE let me know.
Cheers, Gene
-*-
87783 5-JUN 21:44 General Information
RE: nitro/lha (Re: Msg 87754)
From: JEVESTAL To: WDTV5
> I doubt that RBF.32 is the LHA problems. I've been using it here since I
> uploaded it, along with LHA2.2 (I think thats the latest level 2 version)
Where can I get LHA 2.2, the latest I have is 2.11.
Jim
-*-
87797 6-JUN 22:21 General Information
RE: nitro/lha (Re: Msg 87783)
From: WDTV5 To: JEVESTAL
See what did I tell ya, a mind is a terrible thing to lose! Yer right of
course, up till a couple of days ago it was 2.11b, but if you check the
11c.lzh available. Humm, diddly Amiga
doesn't seem to wanna make the underscore char, shoulda been 2 of them
in that name! Lemme try again, lha_2_11c.lzh. Must have been my used to
coco keyboard fingers. Gotta blame it on sump'in!. Cheers, Gene
-*-
End of Thread.
-*-
87755 4-JUN 02:05 Telecom (6809)
RE: 9600 (Re: Msg 87695)
From: MITHELEN To: JEVESTAL
Welp... Zmodem was originally written on big, fast computers with
plenty of CPU cycles to spare, and unforch, the CoCo version has not
had many optimizations done. Sendind is esciacially bad, because the
SACia doesn't have any kind of send buffer, like it does for receive, so
it gobbles up lots of CPU. Teh old, original, ACIAPAK actually had a send
buffer. It would be great if some hacker got around to hacking it into
SACia. I've mentioned it to many of the local CoCo hackers, and it
seems no one has the time to do it.
Hopefully, some more assembly optimization will get done on the
CoCo version of Zmodem one of these days, and it will bring the
throughput up to reality... even with one of the "mythical" CoCoIO type
ports with the high speed 16550 uarts, zmodem as it is tops out just
under 1000 CPS on receiveing... didn't do any sending tests, but I
imagine there isn't much improvement there.
--
Paul
-*-
87784 5-JUN 21:45 Telecom (6809)
RE: 9600 (Re: Msg 87755)
From: JEVESTAL To: MITHELEN
> Welp... Zmodem was originally written on big, fast computers with
> plenty of CPU cycles to spare, and unforch, the CoCo version has not
> had many optimizations done. Sendind is esciacially bad, because the
> SACia doesn't have any kind of send buffer, like it does for receive, so
> it gobbles up lots of CPU. Teh old, original, ACIAPAK actually had a send
> buffer. It would be great if some hacker got around to hacking it into
> SACia. I've mentioned it to many of the local CoCo hackers, and it
> seems no one has the time to do it.
> Hopefully, some more assembly optimization will get done on the
> CoCo version of Zmodem one of these days, and it will bring the
> throughput up to reality... even with one of the "mythical" CoCoIO type
> ports with the high speed 16550 uarts, zmodem as it is tops out just
> under 1000 CPS on receiveing... didn't do any sending tests, but I
> imagine there isn't much improvement there.
But ymodem (on Supercomm) sends files with an average speed of 400+CPS
(at 4800)... I thought Zmodem was supposed to be superior to ymodem.
Jim
-*-
87794 6-JUN 18:23 Telecom (6809)
RE: 9600 (Re: Msg 87784)
From: MITHELEN To: JEVESTAL
Sure, it isa superior _protocal_, but the current implementation on
the CoCo is not written as effeciently as existing CoCo ymodem routines...
Whats needed is for someone to write Zmodem routines for the CoCo from scratch,
that way it can be written cleanly from the start.
-*-
87796 6-JUN 21:02 Telecom (6809)
RE: 9600 (Re: Msg 87784)
From: JEJONES To: JEVESTAL
> But ymodem (on Supercomm) sends files with an average speed of 400+CPS
> (at 4800)... I thought Zmodem was supposed to be superior to ymodem.
Well...yes, but:
1. zmodem is a "sliding windows" protocol, which means that the receiver
has to be able to write the packet it just received to disk while the
next packet is coming in.
2. Like the original poster said, the author of rz/sz wrote it for Unix,
and it doesn't do things one would definitely want to do under OS-9,
like notice how many bytes are ready to read and get them all at once
to minimize system call overhead. It would take some work to modify
or maintain rz/sz--it has many conditional compilation directives to
work on various flavors of Unix. A couple of places in the source
appear unaffected by the "structured programming" movement of the
late 60s and early 70s.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
87806 7-JUN 00:01 Telecom (6809)
RE: 9600 (Re: Msg 87796)
From: MITHELEN To: JEJONES
One correction James, Zmodem DOES check to see how many characters are
pending, and reads what is available, up to what it needs.
-*-
End of Thread.
-*-
87756 4-JUN 02:26 Programmers Den
RE: cc 2.5.0 (Re: Msg 87701)
From: MITHELEN To: RICKADAMS
It is in the databases, isn't it... look in New, or Programmers... I'm 99.44%
sure it is here...
--
Paul
-*-
87779 5-JUN 14:11 Programmers Den
RE: cc 2.5.0 (Re: Msg 87756)
From: RICKADAMS To: MITHELEN
cc 2.5.0 is here, but is corrupted. cc 2.5.2 is here, and in good shape,
and I got it and it works fine. Thanks.
-*-
87793 6-JUN 18:18 Programmers Den
RE: cc 2.5.0 (Re: Msg 87779)
From: MITHELEN To: RICKADAMS
Ok... I guess I can move 2.5.0 outa view then...
--
Paul
P.S Can you point me to where in the database 2.5.0 is? I can't seem to
find it...
-*-
End of Thread.
-*-
87757 4-JUN 02:38 Programmers Den
blackjack program
From: CURTPANTLE To: PAGAN
My last forum message regarding your insurance bet algorithm needs a
slight modification.
Dealer's upcard is ace
Players can make insurance bet
Dealer looks at hole card
If dealer does not have 21, players lose insurance bets and play continues
in normal way with players taking more cards if they want
If dealer has 21, players win insurance bets; if player has 21, it's a
"push" or tie with regard to original bet and player gets original bet
back; if player does not have 21, then player loses original bet (dealer
automatically wins)
Sorry I didn't include this last time.
Curt
-*-
87758 4-JUN 03:40 General Information
RE: Commodore Monitors (Re: Msg 87715)
From: WAYNETHOMPSO To: CHARLESAM
Thats great! What games are you talking about? I believe that there
is a bug in cc3io.nv115(I think) that causes a
system crash when the ss.joy (joystick) system call is used. If I remember
correctly, I had some pretty colorful crashes until I updated
cc3io.nv115 to nv116. Check the docs for NitrOS9 1.16 to see
if that is the case.
Wayne
-*-
87787 5-JUN 22:19 General Information
RE: Commodore Monitors (Re: Msg 87758)
From: CHARLESAM To: WAYNETHOMPSO
THanx Wayne, thats what Colin advised. Let you know how it works when I
get it updated. Charlie
-*-
End of Thread.
-*-
87759 4-JUN 04:50 General Information
RE: TEAC drives (Re: Msg 87699)
From: ALWAGNER To: JHICKLE
It depends on exactly what you mean by that statement. IF you mean that you
are going to remove the
full height drives and replace them with half height drives, then full speed
ahead! IF on the other hand you mean to take a hacksaw and slice a little off,
some would tell yo to go ahead as there would be one less of the power sucking
full height drives left to deal with in this world. I being more forgiving will
tell you to just keep them as a spare and get a couple of half heights to
replace
them.
Depending on the case you are installing the half heights in, you may need a new
faceplate for the drives. These are usually available from the distributor of
the drives. If you can't locate the full height faceplates for the half height
drives and you really need them, these can often be picked up at computer flea
markets and festivals. Happy computing!
-*-
87762 4-JUN 11:59 General Information
RE: TEAC drives (Re: Msg 87759)
From: JHICKLE To: ALWAGNER (NR)
The faceplates (and the locking mechanism) would be the holdup. Otherwise
the other half seems to be just a spacer; perhaps, tho, the extra room is
needed for heat dissipation - these are older 720k drives with a bunch
of chips on the board. I think I'll shift out of weenee mode and just
get/build a case and power supply for the bigger drives.
Thanx much!
-jimmy
-*-
End of Thread.
-*-
87761 4-JUN 08:24 Programmers Den
RE: rule for blackjack (Re: Msg 87739)
From: JEJONES To: PAGAN
> I based the program on a paperback version of Hoyle. Of course, the
> inscription "To Fred from Wilma" should have clued me that there might
> be some postdiluvian variants not included <g>.
LOL!
> +-----------------------------------+
> | Let Accuracy triumph over Victory |
> +-----------------------------------+
Aha! I try to turn people on to *David's Sling* when possible. (The world
needs a real Zetetic Institute, that's for sure.) Nice to find someone else
who's read it.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
87765 4-JUN 17:54 OSK Applications
Developers Project
From: NIMITZ To: ALL
Following the recent FEST, a developers association was formed. If anyone here
is developing applications for the OS9 personal market, please contact me if
you have not heard of this yet.
David
-*-
87766 4-JUN 19:00 Applications (6809)
CRC Fix
From: DENNYWRIGHT To: ALL
Is there a utility to fix the crc of a file. I d/l'd the disk catalog program
in the new uploads, an .lzh archive, and when I burst it it says all the files
have bad crc's. Anybody else have this problem?
-*-
87767 4-JUN 20:19 Applications (6809)
RE: CRC Fix (Re: Msg 87766)
From: ILLUSIONIST To: DENNYWRIGHT
you are probably using the "wrong" version of "lzh" .... try a program
called LHA ..not LZH....
-* Mike
-*-
87777 5-JUN 13:21 Applications (6809)
RE: CRC Fix (Re: Msg 87767)
From: DENNYWRIGHT To: ILLUSIONIST
Where's LHA? What database, applications?
I didn't know there was another version.
-*-
87778 5-JUN 13:25 Applications (6809)
RE: CRC Fix (Re: Msg 87777)
From: ILLUSIONIST To: DENNYWRIGHT
there is the new version 2.11c in the new uploads area..
-*-
End of Thread.
-*-
87772 5-JUN 00:10 General Information
help
From: ROBERT84 To: ALL
Could someone help me out....I am trying to install several games on my hard
drive like kings quest III, and the interbank incident. After I have them
I try to execute them but the computer just locks upI have windint in my boot
file, I was wondering if that may be the problem. I am just sort of lost,
anyone help me out.
thanks,
Bob
-*-
87775 5-JUN 11:56 General Information
RE: help (Re: Msg 87772)
From: MITHELEN To: ROBERT84
I have ran both KQ3 and Interbank Indident from a HD system... They both
took some work... First off, they both need a VDG screen to run on (having
windint in the boot wont hurt, but you do need vdgint) also, KQ3 will not
run if you are operating in 1 or 2 meg mode (it does nasty GIME tricks)
Also, KQ3 required a patch to the stock init module. It has been a very long
time since I ran either, so I casn't give you much more specifics.
-*-
87776 5-JUN 11:58 General Information
RE: help (Re: Msg 87772)
From: COLORSYSTEMS To: ROBERT84
> Could someone help me out....I am trying to install several games on my
> hard drive like kings quest III, and the interbank incident. After I have
> them I try to execute them but the computer just locks upI have windint in
> my boot file, I was wondering if that may be the problem. I am just sort
> of lost, anyone help me out.
Dunno about Interbank Incident, but I am sure that KQ3 is a VDG window based
app, therefore, WindInt is not used by it, but VDGint is.
------------------------------------
Zack C Sessions
"We did not inherit the Earth from our Ancestors,
we borrowed it from our descendants." Ancient proverb
-*-
87832 8-JUN 21:07 General Information
RE: help (Re: Msg 87772)
From: DBREEDING To: ROBERT84 (NR)
> Could someone help me out....I am trying to install several games on my
> hard drive like kings quest III, and the interbank incident. After I have
> them I try to execute them but the computer just locks upI have windint in
KQ III, Flightsim(2), and several other games use VDGINT instead of WindInt.
It is OK to have both WintInt and VDGInt in your boot at the same time. You
also need a couple or so modules from the bootfile in the KQ disk (AGIVirq,
for one), also FS2 has some modules, too. There is (or was) a file here
called "vrn.ar" (I think it was .ar). It included replacements for the KQ and
FS-2 modules. You might give this a try.
If you want the stock stuff, if you don't have a bootsplit program to extract
modules from a bootfile, you might make a backup of your game disk, edit the
startup file to _NOT_ start up KQ, and then save them to disk. There is a
copy of save in with one of the commands that came in the Multi-View package.
In either case, grab any module you do not recognize.
One other thing... If you haven't done it, you need to change a byte in the
stock "init" module. The byte at offset $000C should be changed from $0F
to $0C, and the module's CRC should be updated.
Hope this helps.
-- David Breeding --
CompuServe : 72330,2051
Delphi : DBREEDING
*** Sent via CoCo-InfoXpress V1.01 ***
^^^^ ^^^^^^^^^^
-*-
End of Thread.
-*-
87773 5-JUN 00:35 General Information
OS-9 Live!
From: BOISY To: ALL
Our first OS-9 Live! Conference was a mild success. For the first 45
minutes, I was the only one in the forum, but slowly people began to
make their way in.
I've posted the transcript of the conference to the database and it should
be made available soon.
The next OS-9 Live! conference is scheduled for June 18th at 10:00PM EST.
The topic will be: Using OS-9 MAKE. We'll be concentrating on how to
use MAKE to boost programming productivity and aleviate version headaches.
Join us!
-*-
87774 5-JUN 11:53 General Information
RE: MECI #86 catolog (Re: Msg 87710)
From: MARTYGOODMAN To: DONALDS
Glad to be of help! BTW... I just deleted your ad for the
Adaptec Controllers, as per your request.
---marty
-*-
87808 7-JUN 08:19 General Information
RE: MECI #86 catolog (Re: Msg 87774)
From: DONALDS To: MARTYGOODMAN
Thanks again.
Don
-*-
End of Thread.
-*-
87780 5-JUN 18:33 General Information
Frustrated in Seattle
From: BOISY To: ALL
I am trying to declare a pointer to a function returning an INT in 6809 C.
Here's the code:
int (* caseFunc)();
int toupper();
main()
{
int x;
caseFunc = toupper;
caseFunc('a');
}
When compiling I get the following error:
x.c : line 11 **** not a function ****
caseFunc('a');
^
Can someone give me some pointers here???
-*-
87782 5-JUN 21:43 General Information
RE: Frustrated in Seattle (Re: Msg 87780)
From: JEJONES To: BOISY
> int (* caseFunc)();
> int toupper();
>
> main()
> {
> int x;
> caseFunc = toupper;
> caseFunc('a');
> }
> When compiling I get the following error:
>
> x.c : line 11 **** not a function ****
> caseFunc('a');
> ^
>
> Can someone give me some pointers here??? [groan--jej]
It's not the declaration of caseFunc that's the problem, it's the
use. Try "(*caseFunc)('a');" and see if you have any better luck.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
87805 6-JUN 23:29 General Information
RE: Frustrated in Seattle (Re: Msg 87780)
From: COLORSYSTEMS To: BOISY
> int (* caseFunc)();
>
> int toupper();
>
> main()
> {
> int x;
>
> caseFunc = toupper;
>
> caseFunc('a');
Shouldn't this line be:
x = *caseFunc('a');
------------------------------------
Zack C Sessions
They say, "Money talks". But all mine ever says is, "Goodbye".
-*-
End of Thread.
-*-
87788 6-JUN 00:06 General Information
NitrOS9
From: JERRYMORELLI To: ALL
Hi everybody. I own a CoCo 3 that I just started using again after about 3
years, and I would like to expand on it and start using it more extensively.
I do own OS-9. But I don't have anything for the system (OS9 that is). I've
been seeing a lot of references to "NitrOS9" in different messages. What is
it, what are its uses, and where can one get a copy of it? I have a CoCo 3 with
512k, two DSDD drives, a multi-pak, RS232 pak, RGB and monochrome monitors,
DMP-106 printer, and 1200 baud modem. Are there any suggestions for upgrades
or purchases in order to catch up with the times? I would really like to use
my computer to do some hardware interfacing, and would like to basically get
caught up, as I mentioned before, with the different aspects of the CoCo and
OS9 (level 2). Thanks for any help
Jerry
-*-
87790 6-JUN 01:34 General Information
RE: NitrOS9 (Re: Msg 87788)
From: COCOKIWI To: JERRYMORELLI
The references you have been seeing on "nitrOS9" is to a chip that uses it!
ked hitachi to make a CMOS version of the 6809...
The ORG 6809 chip was hard coded internaly........The CMOS version used
what is known as Microcode....literly programming the CPU to do what you
want.......Anyway,someone noticed that there was a LOT more room in there
and without the knowlege of Motorola put some extra goodies in there!
the E and F registers 8 bit W combines them.....
The Q register is ALL of Em! the D and W = Q 32 bits
a STATUS register........etc....It is a drop in replacement for the 68B09E
HD63C09E is it! BUT! some programs do not like it,as a couple of OP codes
WILL cause problems due to sloppy programmers........
anyway when this news came out a couple of programmers got to work on upgrading
OS-9 level II to use its faster format......Hence NitrOS9....and you can add
POWER BOOST from B & B.........dig around in the Database for the ORG
6309 MEMO on the changes! or if you have a copy of EDASM around it can be
UPGRADED to work with the new chip! of course you have to have one ! That
entails removing the CoCo-3 CPU which is soldered in place,remove and replace
with
a socket....This brings up another item....a 2 meg add on for the CoCo-3
using SIMM,s.......I have one of the old ones that used TWO boards...this
one uses ONE and will run without extra power...that you get from DISTO here!
if he has any left! Working with Os9 I would recomend having EZGEN from B & B
worth the $20.00 for it! makes Bootfiles without the hair pulling one had
to go through in the early days<ARggg> there is another one also out there
from Canada....they both do the same thing..B & B uses the disk..the other
uses memory to build the bootfile.......+ other things........
Hope this helps to bring you up to speed....RGB-DOS...<hard drive system>
and B & B are still around .....if you want hard drive .....there was a
note here on that the other day!
Have fun Dennis
-*-
End of Thread.
-*-
87789 6-JUN 00:28 General Information
Updated CC#IO
From: CHARLESAM To: WDTV5
Well Gene, I updated cc3io and two of my games work...sort of. I must have
a misplace in some of my modules between 191 lines and 200 lines. My joystick
doesn't work at the bootom of my screen. My game Klondike doesn't work at all.
I'll have to go back and check the docs about it. I'll keep you posted.
PS I used EZ-GEN for the first time to replace the cc3io.nv115 with nv116.
Nice utility! I was having a terrible time generating a new os9boot. I kept
getting a bad header with rbf. EZ-GEN saved the day. Charlie
PS misplace=mismatch in 2nd line.
-*-
87801 6-JUN 22:27 General Information
RE: Updated CC#IO (Re: Msg 87789)
From: WDTV5 To: CHARLESAM
I wonder why it squawked about the header? As I recall, I've used it here
for just exactly that, my rbf is set to indicate native in the header too.
Now you got me wondering. What ver ezgen do ya have? I've got 1.11.
Cu later, maybe in mail. Cheers, Gene
-*-
End of Thread.
-*-
87791 6-JUN 02:27 Programmers Den
cgfx library
From: CURTPANTLE To: ALL
This is a desperate plea for help ...
I'm trying to link cgfx.l from the os9 level 2 development system --
I tried different combinations of header files and linkage order with
clib.l, cgfx.l and sys.l and keep getting this:
linker fatal: '/d1/lib/cgfx.l' is not a relocatable module
absolutely the last problem I expected was a NON-RELOCATABLE os9 system module.
Would appreciate any suggestions.
Curt
-*-
87795 6-JUN 18:33 Programmers Den
RE: cgfx library (Re: Msg 87791)
From: MITHELEN To: CURTPANTLE
I beleive the cgfx.l from the developers pack requires you to use rlink
for linking, instead of c.link. You can patch you "cc" program to use rlink
and rma, or just copy rma -> c.asm, and rlink -> c.link.
--
Paul
-*-
87807 7-JUN 01:55 Programmers Den
RE: cgfx library (Re: Msg 87795)
From: CURTPANTLE To: MITHELEN
Paul,
Thanks a million for your reply -- I would have never come up with rlink
on my own!
Curt
-*-
End of Thread.
-*-
87792 6-JUN 17:41 General Information
Sony Service Anecdote
From: MARTYGOODMAN To: ALL
Folks,
I just had an interesting chat with a VERY kind and helpful
customer service person for Sony Corp. The situation was that I had
acquired a particular Sony television, without its remote control, and
was seeking to know whether the remote was necessary to program which
channels it saw when you used the up and down channel control. I was
also seeking to know what particular remote controls made either by Sony
or by others ("universal remote controls") supported the functions
needed to do such programming. We quickly ascertained that this
particular Sony TV (KV20TS30, vintage 1991) ABSOLUTELY REQUIRED its
particular make and model of remote control (Sony part number RM-761) to
acess those features. NOTHING else would do. This part was available,
for $30.00 plus $5.00 shipping costs. Well and good.
I then happenned to mention to the fellow that I was interested in
buying a SERVICE manual for that television. He asked me if I did not
mean "user manual", not "service manaual", and I assured him that I
wanted a service manual, for I occasionally did repairs on my own
consumer electronics products. I told him a story about how I had
diagnosed and fixed TWO older Sony TVs I owned (one was a KV1311CR,
popular with Color Computer 3 and Amiga users because it doubled as a
decent quality RGB analog monitor that accepted 15.75 KHz H sync RGB
analog video signals and had a very nice display) that had lost the
ability to remember what channels they were to see and what to lock out,
due to the failure of their EEPROM chip. I noted how kind and helpful
Sony parts had been in getting me, at rasonable prices, the needed
service manuals AND the required oddball EEPROM chip for the TVs in
questions.
The customer service person proceeded to say that I was probably
now FLAGGED in Sony's parts order line computer as "knowledgeable about
how to fix TV's". I suggested he was kidding. "No," he said, "they
actually DO at Sony parts as a matter of policy try to ascertain whether
the caller knows what he or she is talking about". And IF they are
convinced the called DOES know what end of a soldering iron to grab hold
of, they apparantly NOTE that in the record, for future reference! How
interesting! It makes perfect sense to me that they should do that,
and I applaud Sony for its support of those who know how to and prefer
to try fixing their own consumer electronic equipment. I find the fact
that they subtly attempt to screen callers to the parts department a
perfectly sensible, reasonable policy on their part. It's just amusing
to KNOW now that they do it. I do in fact highly recommend Sony consumer
electronic products in general, and their Televisions and RGB Monitors
in particular. These seem to be of the very highest quality, of
considerable durability, and are all supported by available parts and
service manauals AT REASONABLE PRICES in most cases. Tinkerers in
particular should consider buying Sony products, if it's a close choice
between a Sony and some other brand, to support a company that has such
a reasonable attitude toward allowing do-it-yourselfers to fix their own
stuff.
---marty
-*-
87804 6-JUN 23:12 General Information
RE: Sony Service Anecdote (Re: Msg 87792)
From: CLTUCKER To: MARTYGOODMAN
Hi Marty. The news about Sony's helpful attitude on their products sounds
wonderful. I have this Sony Model SRD2040A 40 meg hard drive. Wonder how
to go about getting this running for COCO3. I have no cables or power
supply. Sound like a teaser eh? Must go from scrtch. Thanks for any
help. CLT
-*-
87827 8-JUN 16:51 General Information
RE: Sony Service Anecdote (Re: Msg 87804)
From: MARTYGOODMAN To: CLTUCKER
NONE of my hard drive references list SONY as a maker of hard drives!
I've checked in three different hard drive guides. I called a friend
who also has never heard of Sony brand drives. Bear in mind
the references I'm using are pretty extensive. So... it would
SEEM to me that you've got a drive that has been RELABELED
by Sony, as opposed to one they MADE. Or such is my speculation.
What more can you tell me about this drive? Is it MFM? Where did
it come from? What physical size is it?
What sort of hard drive host adaptor and controller are you
planning to use with this "Sony" drive? I assume you are aware
that 95% of the cost and difficulty of hooking a hard drive to
a CoCo 3 is the host adaptor / controller and software...
the hard drive itself is usually the cheapest and most trivial
aspect of the the system.
---marty
-*-
87833 8-JUN 21:50 General Information
RE: Sony Service Anecdote (Re: Msg 87827)
From: CLTUCKER To: MARTYGOODMAN (NR)
Hi Marty, I ordered a "SCSI" drive from DUVALL SYSTEMS,
Dallas, TX. They sent me the SONY 40 meg HD made in Japan. It is a
1-1/2 x 5 x 8" plug in unit. Model SRD2040A. That's all I can see.
Thks. clt
-*-
End of Thread.
-*-
87799 6-JUN 22:22 OSK Applications
RE: MM/1 TREK (Re: Msg 87704)
From: MODEL299 To: KSCALES
Interesting!! Suggestions are welcome. Solutions are VERY welcome. It is
odd that the shell used makes a difference. Actually this would not be the
first problem we encountered with a replacement MM/1 module. Early versions
of a module called Cal's Math would error on a course of 0 or 180. This was
mentioned to the author and later math modules worked properly with the
BASIC09 math requirements. It was something about the carry bit that had
not been handled the way BASIC09 required.
Anyway, thanks for the information. It will be checked out and we will
see about developing a version that works with both shells.
-Mark-
-*-
87802 6-JUN 22:34 Programmers Den
A basic09 dir compare
From: WDTV5 To: ALL
I saw, about a week ago, a msg go by where someone was reading in filenames
in a basic09 routine, and wondering why it would never compare, even if the
names looked alike, they miss-compared and his program then miss-behaved.
I recall looking at the code as it flew by and noting that in doing the
compare, the code shown did the toupper function ok, but did NOT have any
provision to handle the fact that as it comes off the disk, the first bit
in the last character of the name is set high. In order for the compare to
find them equal when they are, the code should strip that bit, and then
terminate the string with a basic09 "end of string" marker, an $FF hex.
Whoever that was, give it a try after plugging in the code to handle that
and I'll bet it'll work as you intended. Cheers, Gene
-*-
87811 7-JUN 20:57 Programmers Den
RE: A basic09 dir compare (Re: Msg 87802)
From: CPERRAULT To: WDTV5
Hi Gene, that was me who posted that. Thanks for the reply, I have your
message saved for later referal.
Anyway, when I got the filename(s) from disk, the program includes the
conversion routine which subtracts 128 from the last character. Shouldn't this
do the trick? And if I do Eos, won't that still make it unequal, as the last
character won't match?
>Chris<
-*-
87821 7-JUN 23:58 Programmers Den
RE: A basic09 dir compare (Re: Msg 87811)
From: WDTV5 To: CPERRAULT
I didn't intend to indicate the last byte (char) of the name was to be made
into an $FF, but the next one after that. A $FF is Basic09's end of string
marker unlike C's $00 eos marker. I didn't see that sub 128 in the code
snippet I saw go by. It may have been there, but I always check to see if
the first bit is set, and "LAND(char,127)" ((check that syntax please))
rather than subbing the 128. Does less to the carry bits or something, but
works for me. Lemme open a window and check one chunk of code I've got that
does exactly that. Yeah, here is that snippet.
WHILE NOT(EOF(#Dpath)) DO
GET #Dpath,temp1
TName:=""
FOR x=1 TO 29
BT:=ASC(MID$(temp1,x,1))
IF BT>64 AND BT<95 THEN
BT:=BT+32
ENDIF
EXITIF BT>127 THEN
BT:=LAND(BT,127)
IF BT>64 AND BT<95 THEN
BT:=BT+32
ENDIF
TName:=TName+CHR$(BT)
ENDEXIT
EXITIF BT=0 THEN
ENDEXIT
TName:=TName+CHR$(BT)
NEXT x
and that is how I load in the directory entries in my own personal MaxIc.
Its probably re-inventing the wheel tho. Cheers, Gene
-*-
End of Thread.
-*-
87809 7-JUN 19:06 Programmers Den
Formats.ar
From: DENNYWRIGHT To: ALL
Can anyone tell me how to modify the B09 source code for Formats? It's in the
databases as FORMATS.AR a bulk disk formatter that whistles at you when it
finishes formatting a disk and is ready for another. I want it to use /d1 and
/d2 instead of /d0 and /d
1. I tried replacing all occurances of /d0 with /d1 and /d1 with /d2 but it
doesn't seem to work. I get the fomtatting message but then I get the "put your
system master back in /dd if it's a floppy..." and Hit any Key. Then I get get
my prompt back when I
hit a key. It updates the /dd/sys/volid file so I know that part works an
d I
had format in memory at the time too. I know next to nothing about basic09 so
any and all help would be greatly appreciated!
-*-
87813 7-JUN 21:23 Programmers Den
RE: Formats.ar (Re: Msg 87809)
From: ILLUSIONIST To: DENNYWRIGHT
If I get a chance, I will DL the code and try to modify it for what you
want, if/when I do so, I can email you a copy, but I cannot upload it to
the OS-9 sig without the original authors permission (well, I suppose I
could, but it isnt exactly good manners)..
-* Mike
-*-
87830 8-JUN 18:47 Programmers Den
RE: Formats.ar (Re: Msg 87813)
From: DENNYWRIGHT To: ILLUSIONIST (NR)
Thanks that'd be fine. I don't see what the problem would be since it's already
in the database.
If you want you could just e-mail me instructions on how/what lines to modify.
Thanks again.
-*-
End of Thread.
-*-
87814 7-JUN 21:41 General Information
RE: Boot Problem (Re: Msg 87143)
From: NEALSTEWARD To: TEDJAEGER (NR)
Thanks, but it turned out to be in the kernal. I have it working fine now
and I am now able to build floppy boots for my system as well! I could
never boot from a floppy only before. It has been so long ago that
Roger Krupski built my system that I forgot what we did. Since I built
my own system, I never really got docs for RGBDOS. I suppose that would
have answered all my questions. Roger has been out of the coco community
for awhile, I didn't want to bother him. It's great to have support like
this.
-*-
87815 7-JUN 21:43 General Information
RE: patches (Re: Msg 87521)
From: NEALSTEWARD To: MITHELEN
I have never had a reason to check out those features. I will see if
the version I have is up to snuff and get back with you. As far as a
user interface is concerned, I still like it. :-)
-*-
87817 7-JUN 22:28 Programmers Den
Basic09 Disk Access
From: NEALSTEWARD To: ALL
Is there a faster way of setting the pointer to the end of a sequetial
file than reading every line in a loop? Currently I have:
WHILE NOT(EOF(#filepath)) DO
READ #filepath,line_of_text
ENDWHILE
However, on a large file this takes forever. Is there a way to set
the pointer to the EOF directly?
-*-
87818 7-JUN 23:18 Programmers Den
RE: Basic09 Disk Access (Re: Msg 87817)
From: RANDYKWILSON To: NEALSTEWARD (NR)
Yep, it's not that big of a deal. using syscall, Do a Getstat SS.Siz call
on the file path, followed up by a Seek call.
.....
TYPE regs: cc,a,b,dp:byte;x,y,u:integer
dim s1:regs
...
s1.a=file_path
s1.b=2
RUN syscall($8D,s1)
/* s1.x and s1.u now have the file size. I$Seek takes the same format
RUN syscall($88,s1)
Randy
-*-
87826 8-JUN 07:37 Programmers Den
RE: Basic09 Disk Access (Re: Msg 87817)
From: JEJONES To: NEALSTEWARD (NR)
> Is there a faster way of setting the pointer to the end of a sequetial
> file than reading every line in a loop?
Yup. You need to look up the SS_SIZE getstat, and read up on using
the syscall procedure. That will let you find the size and seek directly
to the end.
Opinions herein are solely those of their respective authors.
Clipper Chip: Big Brother Inside
-*-
End of Thread.
-*-
87819 7-JUN 23:23 General Information
Archives
From: REVWCP To: ALL
Dear friends:
How do you use either AR or LHA to create an archive that contains sub-
directories? For example
./CMDS/Program
./docs
etc. I want the archive to "self-install."
With all best wishes,
Brother Jeremy, CSJW
OS9 User's Group Treasurer
-*-
87820 7-JUN 23:37 General Information
RE: Archives (Re: Msg 87819)
From: RANDYKWILSON To: REVWCP
As is normally the case with OS9, there are many ways to skin this cat. My
personal fav is to build a file that contains all of the pathlists you want
archived. Then use the stdin option of ar like this:
list files ! ar -uz archive.ar
I'm sure LHA has a like feature, but I only have the osk version. Oh, and for
this to work, all pathlists in the file much start from the same point that
ar is started at.
Randy
-*-
End of Thread.
-*-
87824 8-JUN 02:47 System Modules (6809)
PC Floppy Formatter
From: TAFOID To: ALL
Hi!
I have been looking for a modules to allow a 5.25" disk to be formatted
for use on the IBM. I have looked throughly through the System Modules
database, with no success.
If anyone has one, could you email me a copy?
Thanks much,
Scott
-*-
87829 8-JUN 18:41 System Modules (6809)
RE: PC Floppy Formatter (Re: Msg 87824)
From: ISC To: TAFOID
Scott,
I don't think there are any utilities to format IBM disks on the Co
Co, but
PCDos, here in the database will copy files to and from IBMPC disks.
I just buy formatted diskettes at the store since I don't have an IBM
(shudder)<grin> and move files that way.
Bill
-*-
87831 8-JUN 20:35 System Modules (6809)
RE: PC Floppy Formatter (Re: Msg 87829)
From: DSRTFOX To: TAFOID
I hate to tell you this, but there isn't such an animal for OS-9. There IS,
however, a utility written in DECB that will do what you want... almost.
Marty Goodman wrote such a program for Rainbow in June or July of 1987.
The program formats a SINGLE SIDED IBM compatible disk under Disk Basic. He
stuck with SS because not that many DECB people had DS drives at the time.
It does go 40 tracks though. It is in the Rainbow on Tape section. You might
ask Marty about it directly in mail though.
You could possibly use this as the basis for an OS-9 program. If you do, let
me know-- it would make a great magazine feature! When I run such things in
"68' micros", the author retains copyright, just gives me permission to
print!
-*-
End of Thread.
-*-
87834 9-JUN 05:23 OSK Applications
RE: MM/1 Trek (Re: Msg 87713)
From: MREGC To: VAXELF (NR)
> The wolfinstien clone was very outstanding.
Was this program for the CoCo or the MM/1?
..Eric...
-*-
87835 9-JUN 08:33 System Modules (6809)
VDGINT/2 meg
From: DONALDS To: ALL
Has there been any break-through on getting the new reduced size VDGINT module
to work with the 2meg upgrade? I know Alan had redone it and it was still in
beta testing. Just wondering if any conculusion made on it.
Don
-*-
FORUM>Reply, Add, Read, "?" or Exit>
Reference in New Issue View Git Blame Copy Permalink