1471 lines
48 KiB
Plaintext
1471 lines
48 KiB
Plaintext
|
|
||
|
31465 23-AUG 23:37 General Information
|
||
|
st157N
|
||
|
From: MATTSINGER To: MATHOMPSON
|
||
|
|
||
|
I thought I'd let you know that I decided AGAINST the 296N for the 157N. It
|
||
|
draws so little power that the power suplly I have will handle it no-sweat,
|
||
|
where the 296N will be shakey. I figured that the 157N seems to be in use ALOT
|
||
|
more than the 296N, so I'm going that way. WISH ME LUCK!
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31466 24-AUG 00:10 Telcom
|
||
|
RE: OSTerm (Re: Msg 31457)
|
||
|
From: KNOT1 To: THEFERRET
|
||
|
|
||
|
Philip,
|
||
|
|
||
|
Yeah. But mine was two keys! :-(
|
||
|
|
||
|
-Jamie (KNOT1)-
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31472 24-AUG 02:08 Telcom
|
||
|
RE: OSTerm (Re: Msg 31436)
|
||
|
From: TIMKIENTZLE To: THEFERRET
|
||
|
|
||
|
Yes, VT100 is almost the same as ANSI without color. There are some
|
||
|
differences, though (VT100 has a lot of things not in ANSI.SYS, and vice versa).
|
||
|
|
||
|
The most important things are the same.
|
||
|
KBCom does not support an ANSI.SYS emulation per se. But, as I just
|
||
|
mentioned, VT100 is pretty close.
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31494 25-AUG 02:27 Telcom
|
||
|
RE: OSTerm (Re: Msg 31392)
|
||
|
From: RANDYADER To: PHILSCHERER
|
||
|
|
||
|
I use OSTERM and dont have that problem. My settings in the options-terminal
|
||
|
area are VT100 ; VT keyboard ON ; Dest. backspace OFF (or ON - doesn't matter)
|
||
|
|
||
|
Try xmode /T2 bsb : if -bsb that may be your problem
|
||
|
|
||
|
good luck Randy
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31500 25-AUG 08:56 Telcom
|
||
|
RE: OSTerm (Re: Msg 31436)
|
||
|
From: PHILSCHERER To: THEFERRET
|
||
|
|
||
|
Thanks for the info!!
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31501 25-AUG 09:01 Telcom
|
||
|
RE: OSTerm (Re: Msg 31494)
|
||
|
From: PHILSCHERER To: RANDYADER (NR)
|
||
|
|
||
|
I just set it the same as your s and it works. I normally have it set f
|
||
|
or ANSI
|
||
|
and the backspace didn't work. Thanks again!!
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31467 24-AUG 01:21 General Information
|
||
|
RE: SCSI Driver Speed (Re: Msg 31361)
|
||
|
From: KSCALES To: BRIANWHITE
|
||
|
|
||
|
Brian -
|
||
|
|
||
|
Hi, guy. Hope you've been enjoying your summer in Saskatchewan. Just about time
|
||
|
|
||
|
to head back east, I guess.
|
||
|
|
||
|
A few comments about your message to Colin on SCSI, etc.
|
||
|
|
||
|
About your 14.5 seconds for a megabyte transfer -- the best routine I have come
|
||
|
up with takes 24 clock cycles/byte to do SCSI handshaking on the Disto
|
||
|
controller, which works out to about 14.1 seconds for a "megabyte loop" just
|
||
|
doing data reads without any time left for RBF, track stepping, etc. So I think
|
||
|
Matt in his msg #31462 probably had the right interpretation of what you were
|
||
|
trying to say. But please be careful -- most folks will interpret your msg to
|
||
|
mean that you can do a Megaread in 14.5 seconds -- most vendors would not leave
|
||
|
that statement unchallenged! (Oh, and by the way, to avoid misleading anyone,
|
||
|
the read loop I use in my patched SASI and SCSI drivers is somewhat more than 24
|
||
|
|
||
|
cycles, because pure data throughput was not given exclusive priority.)
|
||
|
|
||
|
Also, "the biggest slowdown for our drives is the interleave factor when used
|
||
|
with the CoCo's inefficient RBFMan"... The interleave factor shouldn't CAUSE a
|
||
|
slowdown unless it is set incorrectly. The whole purpose of having the
|
||
|
interleave is to avoid having a slowdown waiting for the disk to spin around to
|
||
|
the desired sector. But, yah, RBF does have its overhead.
|
||
|
|
||
|
You needn't be so defensive of SCSI with either Colin and I. Soon as the MM/1
|
||
|
arrives, we both will probably be adding SCSI drives to our eqpt collections.
|
||
|
<grin>
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31540 26-AUG 02:22 General Information
|
||
|
RE: SCSI Driver Speed (Re: Msg 31390)
|
||
|
From: BRIANWHITE To: THEFERRET
|
||
|
|
||
|
Philip,
|
||
|
|
||
|
Yea, I just haven't bothered to reformat. It's such a pain!!! OS-9 will handle
|
||
|
|
||
|
any interleave there is, it's just that you want to time things so that the
|
||
|
sector that is to be read is just coming under the head when RBF sends the
|
||
|
command to read it. T hats a bit of trial and error for the best value.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31542 26-AUG 02:22 General Information
|
||
|
RE: SCSI Driver Speed (Re: Msg 31467)
|
||
|
From: BRIANWHITE To: KSCALES
|
||
|
|
||
|
Ken,
|
||
|
|
||
|
My read/write routine takes 26 cycles per byte, which works out to just under
|
||
|
14.5 seconds per MB. Notice, though, that I was giving a throughput of my
|
||
|
driver. I had added later in the message that RBF takes time on top of that.
|
||
|
|
||
|
Sorry, I didn't mean to sound that defensive, and I didn't think I said anything
|
||
|
|
||
|
about it to you. It was just that Colin had said that SCSI was slow and I
|
||
|
wanted it clear that it was not "SCSI" that was slow.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31468 24-AUG 01:24 General Information
|
||
|
RE: Message Replies (Re: Msg 31362)
|
||
|
From: KSCALES To: BRIANWHITE
|
||
|
|
||
|
Nope. That wasn't it at all. <grin>
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31469 24-AUG 01:25 Device Drivers
|
||
|
RE: New DIsto Driver (Re: Msg 31365)
|
||
|
From: KSCALES To: MATHOMPSON
|
||
|
|
||
|
<blush>
|
||
|
|
||
|
But, to be honest about that two years... actually, it took me the first year to
|
||
|
|
||
|
get him to haul the drive out of his closet where it sat gathering dust, and
|
||
|
another six months were spent waiting for a replacement drive because the CMI
|
||
|
drive from Arizona bit the dust after about 3 days of use.
|
||
|
|
||
|
But don't worry about being able to support him when he buys your SC-II/4-in-1
|
||
|
--- he now has a Delphi account, and will be able to reach you whenever he needs
|
||
|
|
||
|
help. <man, if you could only see my grin right now...>
|
||
|
|
||
|
... / Ken
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31470 24-AUG 01:56 Telcom
|
||
|
RE: xydown (Re: Msg 31438)
|
||
|
From: TIMKIENTZLE To: THEFERRET
|
||
|
|
||
|
How about adding WXmodem? Well, what's keeping you? You've got source! <grin>
|
||
|
Hey, if I recall, there's already hooks in there for it, all you got to do is...
|
||
|
|
||
|
<grin>
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31474 24-AUG 03:16 Telcom
|
||
|
RE: xydown (Re: Msg 31470)
|
||
|
From: THEFERRET To: TIMKIENTZLE
|
||
|
|
||
|
Much as I'd just LOVE to do it myself, I don't have a C compiler. Awww. :-)
|
||
|
|
||
|
PHhil
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31471 24-AUG 01:57 Telcom
|
||
|
RE: xydown (Re: Msg 31439)
|
||
|
From: TIMKIENTZLE To: THEFERRET
|
||
|
|
||
|
Yeah, I found that. Darn. Sorry to those who already downloaded it just to
|
||
|
find that a the last 1/2 of one archive got lost (part of that somehow got
|
||
|
tacked to the beginning of the second one, making it useless also). <sigh> I'll
|
||
|
|
||
|
get it re-uploaded soon, I hope.
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31473 24-AUG 03:08 Device Drivers
|
||
|
BASIC09
|
||
|
From: JAMAND To: ALL
|
||
|
|
||
|
I AM JUST LEARNING BASIC09 AND HAVE HAD SOME TROUBLE WHEN I OPEN A PATH TO THE
|
||
|
PRINTER. I MAKE PATH=2 BUT SOME TIMES I GET A ERROR 200, PATH TABLE FULL. BUT IT
|
||
|
|
||
|
DOZN'T ALLWAYS HAPPEN.
|
||
|
JIM ANDERSON
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31475 24-AUG 03:21 Device Drivers
|
||
|
RE: BASIC09 (Re: Msg 31473)
|
||
|
From: THEFERRET To: JAMAND (NR)
|
||
|
|
||
|
you can't MAKE the path equal something. You just use "open
|
||
|
#PATH,"/dd/xxx":READ/WRITE/UPDATE" (sorry about the douoble quotation marks:
|
||
|
ignore the outside pair) When you use the open routine, the SYSTEM gives the
|
||
|
VARIABLE PATH a value path has to be an integer or byte variable). Then you use
|
||
|
|
||
|
that variable in all read/write/close operations. Makes sense, really. This
|
||
|
being a multitasking system, unlike MSDOS, what you are probably coming from,
|
||
|
think about what would happen if two processes opened different paths, both with
|
||
|
|
||
|
the number 2 as descriptor. big mess.
|
||
|
|
||
|
Philip Brown
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31510 25-AUG 15:37 Device Drivers
|
||
|
RE: BASIC09 (Re: Msg 31473)
|
||
|
From: TIMKIENTZLE To: JAMAND (NR)
|
||
|
|
||
|
Jim,
|
||
|
You've got it a bit backwards. You don't ever set the number in the path
|
||
|
variable, BASIC09 does that for you. Unlike RSDOS BASIC, the number is not
|
||
|
important, the NAME is. In this case, you want to first
|
||
|
|
||
|
OPEN #PATH,"/P":WRITE
|
||
|
|
||
|
which means to "open" the printer (/P) so you can write to it. OS9 will put a
|
||
|
number into the PATH variable for you to use. That number might be different
|
||
|
every time you use the program, but you don't care about that. Once you've done
|
||
|
|
||
|
this, you can
|
||
|
|
||
|
PRINT #PATH, "This will show on the printer"
|
||
|
|
||
|
Also, don't forget to
|
||
|
|
||
|
CLOSE #PATH
|
||
|
|
||
|
when you're done. Does this make some sense? It's different from RSDOS, but
|
||
|
makes sense once you get the hang of it. The thing to remember is that pretty
|
||
|
much every output device: terminal, printer, modem, disk, ramdisk, etc., all
|
||
|
works the same. So, to access the printer, you do pretty much the same things
|
||
|
you'd do to access the disk, just with a different name.
|
||
|
Hope this helps,
|
||
|
Tim Kientzle
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31476 24-AUG 03:27 General Information
|
||
|
RE: 68K (Re: Msg 31397)
|
||
|
From: ATRDES To: TIMKIENTZLE
|
||
|
|
||
|
As near as I have been able to determine they are in a physical format of 512
|
||
|
kytes per sector and 10 (?) sectors per track. I have been unsuccessful in
|
||
|
finding any track which resembles a root directory structure. Thanks for the
|
||
|
info, I'll keep looking for more clues.
|
||
|
|
||
|
-Tracy.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31477 24-AUG 19:10 General Information
|
||
|
RE: 80 Track Drive (Re: Msg 31380)
|
||
|
From: DRDUDE To: MPASSER
|
||
|
|
||
|
I think I might try putting a B&B adapter on it and try my FD-501 power supply,
|
||
|
but I'm not gonna make any moves before I know for sure! I have a Seagate ST 225
|
||
|
|
||
|
20 meg drive and a Westerm Digital WD 1002A-WX1 controller
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31478 24-AUG 19:17 General Information
|
||
|
RE: Repeating keys (Re: Msg 31395)
|
||
|
From: KINGTRENT To: TIMKIENTZLE
|
||
|
|
||
|
Yeah, the scary part is that it DOES make sense. But then I've gone slightly
|
||
|
overboard on OS-9. Don't believe me? Well when going down a certain road, the
|
||
|
mailboxes all have numbers in the 100 - 250 range. Everytime I see one, I
|
||
|
automatically translate it into an English error message. Very Scary!
|
||
|
- Mike
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31479 24-AUG 21:10 General Information
|
||
|
RE: Repeating keys (Re: Msg 31478)
|
||
|
From: TRIX To: KINGTRENT
|
||
|
|
||
|
Maybe you ought to keep an eye on whoever lives at 223. <grin>
|
||
|
|
||
|
(Raise you're hand if you're looking through your /dd/sys/errmsg file)
|
||
|
|
||
|
-John.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31508 25-AUG 14:08 General Information
|
||
|
RE: Repeating keys (Re: Msg 31479)
|
||
|
From: RICKADAMS To: TRIX
|
||
|
|
||
|
I7ll'll have to SORT of raise my hand... when I saw your reference to error
|
||
|
number 223, I hit the CLEAR key to flip to another window so I could run the
|
||
|
ERROR command... and realized as I watched the screen clear that I was running
|
||
|
DELPHIterm! Hahahahah! That's not the first time I've made that mistake...
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31516 25-AUG 17:27 General Information
|
||
|
RE: Repeating keys (Re: Msg 31479)
|
||
|
From: KINGTRENT To: TRIX
|
||
|
|
||
|
Error 223 - Yes, I confess. Not one of the more common errors. In fact, I don't
|
||
|
think I've ever seen that one.
|
||
|
- Mike
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31480 24-AUG 21:39 Utilities
|
||
|
utilities
|
||
|
From: WB4GCS To: KDARLING (NR)
|
||
|
|
||
|
Kev Just finished installing/testing the 1meg upgrade -- super! I did note
|
||
|
however, that mfree behaves a bit strange. Also, any chance of updating
|
||
|
"UTIL2.BIN" (one of your very old uploads) to recognize the extra memory? Sure
|
||
|
would be nice to see what's going on in the extra blocks.
|
||
|
|
||
|
New subject...Been reading your "inside ......" book. Noted that one of the
|
||
|
items in the INIT module is a default drive (/d0). Also note that /d0 is hard
|
||
|
coded into CC3GO, prior to changing to /dd and /h0. Is the entry in the INIT
|
||
|
module ever used??? What would be the effect of changing it to "/dd" or
|
||
|
"/h0"????? Any thoughts? Worth the effort? tnx & 73, Jim wb4gcs
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31511 25-AUG 15:45 Utilities
|
||
|
RE: utilities (Re: Msg 31480)
|
||
|
From: TIMKIENTZLE To: WB4GCS
|
||
|
|
||
|
Jim,
|
||
|
As I recall, /D0 is NOT hardcoded into CC3Go, although I might be mis-
|
||
|
remembering (I'm using a custom CC3Go right now). In any case, the /D0 in INIT
|
||
|
is used to set the default drive before CC3GO runs. This affects two things:
|
||
|
- If CC3Go fails in it's attempt to set the directories to /H0,
|
||
|
then you'll end up on /D0
|
||
|
- If your /TERM screen is a window device, then GrfDrv gets loaded
|
||
|
before CC3Go changes the directories, i.e. from the drive in the
|
||
|
INIT module.
|
||
|
|
||
|
If you change the /D0 in INIT to /DD, then GrfDrv will always load from the hard
|
||
|
|
||
|
disk (if you have one named /DD, that is), even if your /TERM is a window
|
||
|
screen. It's also suggested that you patch CC3Go to change the /H0 to /DD.
|
||
|
That way, your default dirs always end up on /DD, whatever drive (hard or
|
||
|
floppy) that may be. Also, GrfDrv and Shell will both come from /DD. Make
|
||
|
sense?
|
||
|
- Tim Kientzle
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31519 25-AUG 19:18 Utilities
|
||
|
RE: utilities (Re: Msg 31511)
|
||
|
From: WB4GCS To: TIMKIENTZLE
|
||
|
|
||
|
Tim Thanks -- gotit. 73, Jim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31481 24-AUG 22:05 General Information
|
||
|
Stuff
|
||
|
From: COLINMCKAY To: TEDJAEGER
|
||
|
|
||
|
Hi, Ted.
|
||
|
|
||
|
No offence taken, as that is the first time I have ever tried to set up a
|
||
|
conference. I was probably the one who screwed up.
|
||
|
|
||
|
Joining a conference isn't too difficult. Select conference at the main OS-9
|
||
|
menu, then select join, list the conferences to determine which one, and join
|
||
|
it. (Or something like that! ;-).
|
||
|
|
||
|
Had everything in one box for about a month now. Had to add a second fan to
|
||
|
handle the extra heat from the ST4096 hard drive, and the hot summer weather.
|
||
|
Grounded out the green signal on the monitor extension cable (great way to get
|
||
|
rid of the OS9BOOT startup screen), which turned all the whites to pink. Decided
|
||
|
|
||
|
that I would rather not have pink text so fixed it. Final problem was a flaky
|
||
|
connection to one of the LEDs on the front of the case. Manufacturer's fault,
|
||
|
not mine.
|
||
|
|
||
|
Must admit, though, makes things a lot easier to get to club meetings. Had to
|
||
|
carry one box, the keyboard, and the monitor. Well, not just me, but you get the
|
||
|
|
||
|
picture.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31483 24-AUG 22:20 General Information
|
||
|
RE: Stuff (Re: Msg 31481)
|
||
|
From: TEDJAEGER To: COLINMCKAY
|
||
|
|
||
|
Sounds like you had some adventures getting your "ATCoCo" going too. I lost a
|
||
|
hard drive but it was likely the result of age (7 yr old Tandy HD) rather than
|
||
|
an "engineering" blunder. Still a pain but I have a Seagate 225 going now. One
|
||
|
slick thing: I wired the turbo switch to my /d1 floppy which is a TEAC 55F and I
|
||
|
|
||
|
can switch the drive from 40 to 80 track operation. Use 80 unde os9 and use the
|
||
|
40 configuration to deal with RSDOS. Still want to wire the key switch to my
|
||
|
disto mini controller but I don't have anything for the second 28 pin EPROM. Oh
|
||
|
well, maybe Christmas!! --Bests, TedJaeger
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31482 24-AUG 22:17 Patches
|
||
|
RE: SCSI patch (Re: Msg 31450)
|
||
|
From: ROYBUR To: MATTSINGER
|
||
|
|
||
|
I'll have to disassemble the controller to be sure, but I don't think the
|
||
|
ROM is covered...this is just to let you know I've read your message and will
|
||
|
check it out, NOT a definite answer. :) Let you know soon, though.
|
||
|
Enjoy
|
||
|
Roy
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31493 25-AUG 02:13 Patches
|
||
|
RE: SCSI patch (Re: Msg 31446)
|
||
|
From: KSCALES To: MATTSINGER
|
||
|
|
||
|
Matt -
|
||
|
|
||
|
Working on a reply to your question about what you will be doing to set up your
|
||
|
drive once you have it hooked up. Give me a day or two.
|
||
|
|
||
|
... / Ken
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31524 25-AUG 22:23 Patches
|
||
|
RE: SCSI patch (Re: Msg 31450)
|
||
|
From: ROYBUR To: MATTSINGER
|
||
|
|
||
|
Yep, I took a look, and the board does NOT extend over the DOS ROM - but it
|
||
|
DOES align about evenly with the edge of the ROM socket.
|
||
|
Hope this's useful
|
||
|
Roy
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31526 25-AUG 23:02 Patches
|
||
|
RE: SCSI patch (Re: Msg 31524)
|
||
|
From: MATTSINGER To: ROYBUR (NR)
|
||
|
|
||
|
WEEEEEL.....Thanks!
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31484 24-AUG 22:26 General Information
|
||
|
MAX-10 for os9
|
||
|
From: TEDJAEGER To: IVANSC (NR)
|
||
|
|
||
|
Count me in on the MAX-10 version for OS9. Max-10 is the only reason I ever run
|
||
|
my machine in RSDOS!! --TedJaeger
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31485 24-AUG 23:02 General Information
|
||
|
RE: 1 Meg Upgrade (Re: Msg 31445)
|
||
|
From: DWHILL To: AARONS
|
||
|
|
||
|
Don't worry about the glop around the capacitors; I checked on that once and
|
||
|
found that it was just glue that holds the parts on the board. I suspect its
|
||
|
there just for shipping purposes, so that vibration won't fatique the wire leads
|
||
|
|
||
|
and make them break off.
|
||
|
|
||
|
A fan certainly won't hurt anything, and might contribute to the long-term
|
||
|
reliabl ility of your +5 VDC regulator.
|
||
|
|
||
|
--Damon
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31518 25-AUG 18:59 General Information
|
||
|
RE: 1 Meg Upgrade (Re: Msg 31485)
|
||
|
From: AARONS To: DWHILL (NR)
|
||
|
|
||
|
Thanks for your input about the caps. Looks like I7ll be using a micro fan RS#
|
||
|
273-244.
|
||
|
|
||
|
Aaron
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31534 26-AUG 01:21 General Information
|
||
|
RE: 1 Meg Upgrade (Re: Msg 31485)
|
||
|
From: CIZZIJR To: DWHILL (NR)
|
||
|
|
||
|
Damon,
|
||
|
I believe, but could be wrong, that the glue is used to hold the
|
||
|
capacitors in place when the wave solder the PC board. When the boards
|
||
|
come down the assembly line the caps don't flop out.
|
||
|
|
||
|
Carmen
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31486 24-AUG 23:03 General Information
|
||
|
RE: Multi-pak Upgrade?? (Re: Msg 30992)
|
||
|
From: RANDYADER To: JIMHARRISON (NR)
|
||
|
|
||
|
Just read your message on the MPI upgrade and I have a problem which you may
|
||
|
have seen or heard of. When trying to install a B&B Hard Drive interface in port
|
||
|
|
||
|
three nothing worked so I had a friend try it on his system in place of his B&B
|
||
|
and it preformed flawlessly. It seemes that the MPI has to have the upgrade
|
||
|
board so I tried with my MPI now upgraded with the switch in both po
|
||
|
sitions
|
||
|
and still no luck. My question is do I need to strap the interrupt lines and
|
||
|
install the diode in the computer to get the Hard Drive to function? I have
|
||
|
tries to contact B&B for 4 weeks by voice but he hasn't replied yet.
|
||
|
|
||
|
Anyone else reading this plea for help can jump in - all advice is welcome.
|
||
|
|
||
|
Thanks, Randy
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31503 25-AUG 10:57 General Information
|
||
|
RE: Multi-pak Upgrade?? (Re: Msg 31486)
|
||
|
From: TEDJAEGER To: RANDYADER (NR)
|
||
|
|
||
|
I had a bizzare HD and MPI problem lately. I was running a RS Hard Drive- the
|
||
|
old 15 meg box- and it would work with the older (large) MPI and not the newer
|
||
|
(small) MPI. I got the small MPI upgraded by RS and it made no difference. Never
|
||
|
|
||
|
figured it out cause I got a B&B which did work with the newer MPI. I did look
|
||
|
on the MPI cases and found on the bottom an indication that they were not
|
||
|
comparable in amps rating. Do not know
|
||
|
|
||
|
if that had anything to do with it though. --Good luck, TedJaeger
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31512 25-AUG 15:51 General Information
|
||
|
RE: Multi-pak Upgrade?? (Re: Msg 31486)
|
||
|
From: TIMKIENTZLE To: RANDYADER (NR)
|
||
|
|
||
|
Just so you know, Randy, the B&B does not require strapping the interrupt lines
|
||
|
or installing a diode.
|
||
|
You might want to try simply cleaning all the contacts (MPI-COCO and MPI-B&B)
|
||
|
|
||
|
. That might be a factor. Couldn't hurt to clean the MPI switch as well.
|
||
|
Other than that, it's hard to diagnose from here. Have you tried the hard
|
||
|
drive, etc, in your friends computer, as well? You might also try your MPI in
|
||
|
your friends system, just to try to isolate the problem. Having a working
|
||
|
system that you can swap parts with is a great help.
|
||
|
- Tim Kientzle
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31487 24-AUG 23:35 General Information
|
||
|
Play (Again)
|
||
|
From: COLINMCKAY To: BRIANWHITE
|
||
|
|
||
|
Play4.ar
|
||
|
========
|
||
|
This is another version of the play program originally written
|
||
|
by Kevin Darling, modified by Dave Phillipsen and Brian White,
|
||
|
that is kicking around. It was modified by Zygo Blaxell, and
|
||
|
uploaded with his permission.
|
||
|
|
||
|
Amongst other things, it will allow you to play sections of
|
||
|
a sound file, in what ever order you want, and repeat them.
|
||
|
|
||
|
Digitz.ar
|
||
|
=========
|
||
|
This program will allow you to actually digitize sound under
|
||
|
OS-9! No more dependence on the whims of Amiga and Mac
|
||
|
users. Also written by Zygo Blaxell, and uploaded with his
|
||
|
permission.
|
||
|
|
||
|
If you have any problems with these programs, send EMail to
|
||
|
me (COLINMCKAY), and I will forward them to Zygo. No guarantees
|
||
|
that he will reply, though. Same thing goes for any kudoes you
|
||
|
may have for Zygo.
|
||
|
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31488 24-AUG 23:39 General Information
|
||
|
Oops
|
||
|
From: COLINMCKAY To: BRIANWHITE
|
||
|
|
||
|
Ref last message: I passed on the source to play to Zygo Blaxell. This is what
|
||
|
he gave back to me.
|
||
|
|
||
|
He also commented the source, and allows the playing of sections of sound.
|
||
|
Disobeyed EVERY OS-9 programming rule, and is justifiably proud of it too!
|
||
|
|
||
|
Let me know what you think, once the files are released, and I will pass your
|
||
|
comments on to Zygo
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31489 25-AUG 01:37 Telcom
|
||
|
RE: Terminal Programs OS9 (Re: Msg 31337)
|
||
|
From: RANDYADER To: THEFERRET
|
||
|
|
||
|
What kind of patching and where can I get it for the ability to access the back
|
||
|
side of an RS-DOS disk are you talking about? I have the RSDOS/PCDOS transfer
|
||
|
utilitys but haven't figured out how to read the back side. Randy
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31499 25-AUG 04:16 Telcom
|
||
|
RE: Terminal Programs OS9 (Re: Msg 31489)
|
||
|
From: THEFERRET To: RANDYADER (NR)
|
||
|
|
||
|
Ahem. I did not claim that the utility lets you read the back side of the
|
||
|
disk. Your drive has to be able to. I.E. Given that you have two-sided drives,
|
||
|
|
||
|
and your os9 setup can handle it (you have /d0_80d.dd as your /d0, or generally
|
||
|
something with xxxxd.dd) THEN the program will convert)
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31490 25-AUG 02:04 General Information
|
||
|
RE: Solid State Disk SRAM PACK (Re: Msg 31376)
|
||
|
From: RANDYADER To: ADLSL
|
||
|
|
||
|
The ad that you seek is in the NOV. 88 issue on page 37.
|
||
|
|
||
|
Its sold under the name of SolidDrive by Vidicom Corp. Their address is: Vidicom
|
||
|
|
||
|
Corp. 20 E. Main St. Suite 710 Mesa, AZ. 85201 (602) 827-0107
|
||
|
|
||
|
Hope this helps. Randy
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31529 25-AUG 23:56 General Information
|
||
|
RE: Solid State Disk SRAM PACK (Re: Msg 31490)
|
||
|
From: ADLSL To: RANDYADER (NR)
|
||
|
|
||
|
Thanks for the info. That is the firm I am looking for. I hope they are still
|
||
|
in business.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31491 25-AUG 02:11 General Information
|
||
|
Okimate 20 printer
|
||
|
From: RANDYADER To: ALL
|
||
|
|
||
|
Looking for a program advertised by Morton Bay Software a while back that gave a
|
||
|
|
||
|
color dump from a coco. The ad described the printer and software package
|
||
|
bundled together but not the software alone. Any leads? Any way to dump a coco3
|
||
|
screen in color or an OS9 color dump say from a VEF picture? I have the printer
|
||
|
but don't know enough programming (OS9) to create a dump program. Any help would
|
||
|
|
||
|
be appreaited(sp). Thanks,
|
||
|
Randy
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31492 25-AUG 02:12 New Uploads
|
||
|
RE: Hard Disk Formatting (Re: Msg 31444)
|
||
|
From: KSCALES To: ROYBUR
|
||
|
|
||
|
Roy -
|
||
|
|
||
|
As Matthew Thompson said in his msg #31462, you don't really need to reformat
|
||
|
your drive unless you want to change the interleave factor. You can change the
|
||
|
SAS at any time (no reformat required) by using Hmode -- or by using dEd (the
|
||
|
indispensible Disk Editor) to permanently change the value of SAS in the OS9Boot
|
||
|
|
||
|
file, per the note in the sasimod doc file. Once you have changed it,
|
||
|
fragmentation will be reduced on any new files created. Existing files will, of
|
||
|
course, retain their current amount of fragmentation.
|
||
|
|
||
|
UNLESS the current fragmentation is causing performance degradation due to
|
||
|
extensive seeking, I suggest that you just alter the SAS in your OS9Boot file,
|
||
|
and don't try to undo the existing fragmentation until you really need to
|
||
|
re-format the drive.
|
||
|
|
||
|
When you DO endeavor to reformat your drive, you can reduce/eliminate the
|
||
|
existing fragmentation at that time, during your "restore" process. Use a
|
||
|
"file-based" backup/restore method, such as HDKIT.AR from the database. Reformat
|
||
|
|
||
|
the drive, ensure that SAS is set to a good value, then restore the files back
|
||
|
to the reformatted drive. Before restoring the files, I like to spend a few
|
||
|
minutes creating a directory structure, tailoring the directory sizes
|
||
|
[alloc=(max_expected_dir_entries+2)/8]:
|
||
|
load hmode; * note that hmode is called dmode internally
|
||
|
load makdir
|
||
|
dmode /dd alloc=96;makdir /dd/CMDS
|
||
|
dmode /dd alloc=12;makdir /dd/SYS
|
||
|
dmode /dd alloc=4 ;makdir /dd/USR
|
||
|
dmode /dd alloc=4 ;makdir /dd/COM
|
||
|
dmode /dd alloc=48;makdir /dd/AR
|
||
|
etc.
|
||
|
dmode /dd alloc=32; * reset alloc to good value before doing restore.
|
||
|
|
||
|
Now, to answer your REAL question about "physical format" --
|
||
|
|
||
|
Hard drives are not unlike floppies, just much bigger. Formatting a hard drive
|
||
|
involves the same principals, but the "format" command divides the process into
|
||
|
3 parts so that we can skip over parts we don't need to do.
|
||
|
|
||
|
"physical format": writes a pattern of 1's and 0's on the drive to
|
||
|
create a pattern of sectors on each track so that the disk controller
|
||
|
can synchronize and locate a specific sector. For floppies, RuStyDOS
|
||
|
and OS-9 physical formats are compatible.
|
||
|
|
||
|
"logical format": this creates a basic directory structure on the disk,
|
||
|
and writes/initializes basic information that the operating system
|
||
|
requires to use the disk. (For OS-9, includes the Identification
|
||
|
Sector, Disk Allocation Map, and the Root Directory -- see chapter 5
|
||
|
of the Technical Reference Manual.) Any data previously stored on
|
||
|
the disk remains there (unless it is overwritten by the ID sector,
|
||
|
Alloc. Map, or Root Dir.), but will no longer be accessible by normal
|
||
|
means because the directory information has been re-initialized.
|
||
|
|
||
|
"physical verify": this reads through the disk verifying that sectors
|
||
|
are readable, and marks out bad sectors in the Allocation Map.
|
||
|
|
||
|
You can bypass the "physical format" portion for a previously formatted FLOPPY
|
||
|
by specifying the "l" option:
|
||
|
format /f0 "New Disk Name" l r
|
||
|
|
||
|
To re-format your (SASI) hard drive, you would just use the standard OS-9
|
||
|
"format" command. You will get not 1, but 2, "are you sure" prompts to make
|
||
|
sure you REALLY want to erase all those megabytes. Be sure to set all values
|
||
|
the way you want them using Hmode first.
|
||
|
|
||
|
Hope this clears things.
|
||
|
|
||
|
... / Ken
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31525 25-AUG 22:33 New Uploads
|
||
|
RE: Hard Disk Formatting (Re: Msg 31492)
|
||
|
From: ROYBUR To: KSCALES
|
||
|
|
||
|
THAANX Ken, it certainly DOES clarify things - tremendously!!! I had kinda
|
||
|
guessed some of it, but my guesses were mostly ending in more questions...
|
||
|
VERY good to know I don't actually NEED to reformat at this time, but I WILL
|
||
|
do a backup, for shore!!!
|
||
|
Thanx again, for ALL your help and TIME!
|
||
|
Roy
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31495 25-AUG 02:41 Device Drivers
|
||
|
ESDI
|
||
|
From: 07ESRTIMOTHY To: ALL
|
||
|
|
||
|
The part about not having ESDI controllers for the the coco is wrong. I have two
|
||
|
|
||
|
SCSI to ESDI controllers. They can be driven by any SCSI interface such as
|
||
|
LRTech etc. Drivers are the only thing missing. Oh well Maby I will trade in
|
||
|
the 327's for a couple 80's or something
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31496 25-AUG 02:46 Telcom
|
||
|
|
||
|
From: 07ESRTIMOTHY To: ALL
|
||
|
|
||
|
Tim,
|
||
|
|
||
|
I downloaded your ymdown three times. I think the files are mucked up. I have
|
||
|
downloaded just about everything on delphi os9, and I can't dearc the source at
|
||
|
all, and the tail end of the executable gives a read error. Any one else have
|
||
|
the same problem?
|
||
|
|
||
|
Tim Fadden
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31502 25-AUG 10:34 Telcom
|
||
|
RE: (Re: Msg 31496)
|
||
|
From: MPASSER To: 07ESRTIMOTHY (NR)
|
||
|
|
||
|
Tim,
|
||
|
|
||
|
I couldn't dearc the source, either. A dump of the file didn't reveal an
|
||
|
AR header, and didn't appear to contain anything intelligible. I just deleted
|
||
|
it and chalked up the $$$ wasted to lessons learned.
|
||
|
|
||
|
Mike Passer [MPASSER]
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31513 25-AUG 15:55 Telcom
|
||
|
RE: (Re: Msg 31496)
|
||
|
From: TIMKIENTZLE To: 07ESRTIMOTHY (NR)
|
||
|
|
||
|
Yes, I mis-uploaded it. grrr... Will re-upload soonest.
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31497 25-AUG 02:51 General Information
|
||
|
ATKey
|
||
|
From: 07ESRTIMOTHY To: ALL
|
||
|
|
||
|
Hi Ted,
|
||
|
I attached the key switch to the joystick fire button that way when it is
|
||
|
turned on the keyboard is locked up! Quite effective protection.
|
||
|
|
||
|
Later,
|
||
|
Tim Fadden
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31498 25-AUG 03:11 General Information
|
||
|
Hard Drive interface
|
||
|
From: RANDYADER To: COCOXT (NR)
|
||
|
|
||
|
Dear Mr. Burke,
|
||
|
|
||
|
I have tried to contact you by voice several times for the past month and
|
||
|
have not recieved ny resopnse. I would like to know the status of the interface
|
||
|
I sent to you for repair/troubleshooting. Please respond to me by voice or Email
|
||
|
|
||
|
here
|
||
|
My number is (804)489-1929 anytime after 6pm my time or up to 11pm. Up to
|
||
|
8pm your time. I would appreiate(sp) knowing if you have recieved the interface
|
||
|
or if I should go after the postal service. I have every thing needed for a Hard
|
||
|
|
||
|
Drive sys setup but the interface.
|
||
|
|
||
|
Thanks,
|
||
|
Randy Ader
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31504 25-AUG 11:10 General Information
|
||
|
BASIC09
|
||
|
From: TEDJAEGER To: ALL
|
||
|
|
||
|
Am working on a program that has six buttons on screen which can be used to call
|
||
|
|
||
|
a calculator, phonebook,etc. I am wondering what I needto do to fix the program
|
||
|
so that a user could call, say the calculator, and then without quitting the
|
||
|
calculator, click on another button to call perhaps the phonebook. The general
|
||
|
program design has a mainloop from which the mouse is read and then calls are
|
||
|
made from there to calculator, etc. and the called programs are separate
|
||
|
modules. Guess what I am asking is can I call one module by mouse, somehow get
|
||
|
back to the mainloop to read the mouse while the calcultor is suspended, and
|
||
|
call another module. The calculator and phonebook, etc and running in overlay
|
||
|
windows. --Thanks for any advice--TedJaeger
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31505 25-AUG 11:31 General Information
|
||
|
RE: BASIC09 (Re: Msg 31504)
|
||
|
From: ZACKSESSIONS To: TEDJAEGER
|
||
|
|
||
|
You can't do that with Overlay windows. Only the last overlay set can be
|
||
|
communicated with. You will need to unprotect your main window and open a normal
|
||
|
|
||
|
window with the type of 0.
|
||
|
|
||
|
Zack
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31514 25-AUG 16:41 General Information
|
||
|
RE: BASIC09 (Re: Msg 31505)
|
||
|
From: THEFERRET To: TEDJAEGER
|
||
|
|
||
|
As Zack says, overlay windows cannot be jumped through. Therefore, if you use
|
||
|
an overlay for each aplication, you're stuck... UNLESS they are your application
|
||
|
|
||
|
programs. In that case, you have to re-write them so that EVERY ONE has the
|
||
|
selecting routine as part of it, or can call the selecting routine at will.
|
||
|
|
||
|
An important detail to remember, though. say you have called overlays in the
|
||
|
following order: Calculator, diary, calendar.
|
||
|
If you want to go back to the calculator, you have to make the program exit
|
||
|
and save, on both the calendar, AND the diary programs. This is assuming you
|
||
|
want overlays on top of overlays. a simpler method would be to only have one
|
||
|
overlay up at any one time. an even better way would be not to use overlays at
|
||
|
all, but to define a multi-window screen. Then you could CLEAR to any app. you
|
||
|
|
||
|
wanted, but they would all be showing at the same time.
|
||
|
|
||
|
|
||
|
Philip
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31522 25-AUG 20:23 General Information
|
||
|
RE: BASIC09 (Re: Msg 31514)
|
||
|
From: TEDJAEGER To: THEFERRET
|
||
|
|
||
|
Thanks for the comments. I think I can write my code so that each program in its
|
||
|
|
||
|
overlay contains the code to call the other programs that are run in overlays. I
|
||
|
|
||
|
can't use the multiple window screen with device windows because there are too
|
||
|
many things already on the background screen which is a full 80 X 24 that cannot
|
||
|
|
||
|
be sacrificed.
|
||
|
If I did unprotect my device window, which provides the background display,
|
||
|
and put the calculator, phonebook, etc in other device win- dows, will my device
|
||
|
|
||
|
window be trashed by the overlaying device windows? --Bests, TedJaeger
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31528 25-AUG 23:21 General Information
|
||
|
RE: BASIC09 (Re: Msg 31522)
|
||
|
From: ZACKSESSIONS To: TEDJAEGER
|
||
|
|
||
|
Yes, unprotecting you window then opening up device windows will trash the
|
||
|
underlying window. To preserve it, simple do a getblk to a GP buffer for later
|
||
|
retrieval.
|
||
|
|
||
|
Zack
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31532 26-AUG 00:57 General Information
|
||
|
RE: BASIC09 (Re: Msg 31528)
|
||
|
From: THEFERRET To: TEDJAEGER
|
||
|
|
||
|
alternately, why not just set a multi-window screen SEPARATE from everything
|
||
|
else; Unless you are REALLY set on being a mac-copier, and are desparate for
|
||
|
overlays. It would save you a heck of a lot of trouble.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31506 25-AUG 11:38 General Information
|
||
|
RE: MAX10 (Re: Msg 31461)
|
||
|
From: FRANCALCRAFT To: WLADI (NR)
|
||
|
|
||
|
How many people need a complete home publisher? Most people can make do with a
|
||
|
word processor. I haven't even seen a word processor on OS9 that I really like.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31515 25-AUG 16:59 General Information
|
||
|
RE: MAX10 (Re: Msg 31506)
|
||
|
From: CBJ To: FRANCALCRAFT (NR)
|
||
|
|
||
|
You might be surprised at how many people there are that would like to see a
|
||
|
MAX-10 OS-9 version. Especially if it were packaged with a Graphics editor like
|
||
|
|
||
|
COCO MAX3. A Telewriter 128 clone would be nice as would an OS-9 version of
|
||
|
AUTOTERM. If these were priced reasonably they would sell like hot cakes.
|
||
|
---Carl---
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31507 25-AUG 12:03 General Information
|
||
|
RE: MM/1 (Re: Msg 31385)
|
||
|
From: BERGMANN To: PKW (NR)
|
||
|
|
||
|
Three questions:
|
||
|
|
||
|
1. You say DOS 5.0 is being bundled with QuickBasic. Does that mean an MS-DOS
|
||
|
emulator that will run MS-DOS programs in OS9 windows?
|
||
|
|
||
|
2. How many serial ports on the optional I/O board?
|
||
|
|
||
|
3. Your RAINBOW ad does not make clear what the "Extended" price includes. Is
|
||
|
$1125 the price for the I/O board alone????!!!! Motherboard and I/O board? Case
|
||
|
|
||
|
and power supply, too?
|
||
|
|
||
|
-Dean
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31509 25-AUG 15:22 New Uploads
|
||
|
Sound Master
|
||
|
From: JMARINIS To: JMLSOFT (NR)
|
||
|
|
||
|
When executing Sound Master from Multivue, the process stops with the message
|
||
|
Process error - "sndmstr" - 48. Any thoughts on what I may be doing wrong? I
|
||
|
have RunB and GFX2 in memory, and I created a boot disk with the SSC driver and
|
||
|
descriptor in it. I assume the 48 is the Basic09 error 48 which is
|
||
|
unimplemented routine. Can't say I have any idea what it could be referring to.
|
||
|
|
||
|
Can you help?
|
||
|
|
||
|
Jim Marinis
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31517 25-AUG 17:28 General Information
|
||
|
view 4.1
|
||
|
From: MRGOOD To: TIMKIENTZLE
|
||
|
|
||
|
Tim,
|
||
|
|
||
|
How exactly is the -big option supposed to work with GIF's. I haven't managed to
|
||
|
|
||
|
make any 'big' displays.
|
||
|
|
||
|
Hugo
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31535 26-AUG 01:35 General Information
|
||
|
RE: view 4.1 (Re: Msg 31517)
|
||
|
From: TIMKIENTZLE To: MRGOOD
|
||
|
|
||
|
As with the MAC display, -big should show GIF's in a 1:1 pixel display. This
|
||
|
means that if the original pic was 320x200, it will get shown as such! It only
|
||
|
makes a difference with pictures that have really high resolutions (i.e. 640x400
|
||
|
|
||
|
pix). In fact, for pictures with less resolution than the CoCo, the -big format
|
||
|
|
||
|
will actually show as smaller than the -large format, since the scaling gets
|
||
|
turned off! (This took me rather by surprise when it first happened to me!)
|
||
|
- Tim
|
||
|
|
||
|
P.S. A simpler explanation: -big for GIF turns off the scaling. Normally,
|
||
|
GIF's are scaled to exactly fill the screen.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31520 25-AUG 19:22 Utilities
|
||
|
utilities
|
||
|
From: WB4GCS To: KDARLING (NR)
|
||
|
|
||
|
Dev After I asked you about changing the utilities in util2.bin, I remembered
|
||
|
that source code is in your book .... looked at it, and decided that pmap is the
|
||
|
|
||
|
only file which really needs to be changed for 1meg. Used debug to patch the
|
||
|
byet at offseg $0089 from $40 to $80. Opcheck sat, works fine. 73, Jim wb4gcs
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31521 25-AUG 19:51 General Information
|
||
|
Information
|
||
|
From: RADICAL To: ALL
|
||
|
|
||
|
Is CRC Disto represented on this board? Or is anyone close enough to them who
|
||
|
might be able to sort out a problem I am having? I can't afford any more long
|
||
|
distant phonecalls to Canada. Please respond by mail. Thanks Len
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31527 25-AUG 23:19 General Information
|
||
|
RE: Information (Re: Msg 31521)
|
||
|
From: ZACKSESSIONS To: RADICAL
|
||
|
|
||
|
Try comminicating with username DISTO, aka Tony DiStafano.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31523 25-AUG 21:10 Telcom
|
||
|
RE: remote login question (Re: Msg 31396)
|
||
|
From: BILLDICKHAUS To: TIMKIENTZLE
|
||
|
|
||
|
Tim,
|
||
|
|
||
|
I haven't tested it yet, but it seems like it ought to work. The trick there is
|
||
|
the -i=/1 parameter. I had never thought of doing it that way. The shell will
|
||
|
run the program, and would normally die at that point, kicking the user off. But
|
||
|
|
||
|
in this case because of the immortal option, the shell will never die on its
|
||
|
own. The only way to get rid of it is to send it a kill signal (0). Probably the
|
||
|
|
||
|
modem kill option is set so that a kill signal is sent to the process when the
|
||
|
user hangs up. Or some other utility or login system is being used that sends
|
||
|
the kill signal when something like a "bye" command is issued or when carrier
|
||
|
drops.
|
||
|
|
||
|
Bill
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31537 26-AUG 02:21 Telcom
|
||
|
RE: remote login question (Re: Msg 31372)
|
||
|
From: BRIANWHITE To: ZACKSESSIONS
|
||
|
|
||
|
Zack,
|
||
|
|
||
|
Yea, I saw that quote thing after. I'll have to use it myself since I too used
|
||
|
the chr(6) trick.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31530 26-AUG 00:41 Graphics & Music
|
||
|
GRAPHIC SAVE
|
||
|
From: MFAHY To: ALL
|
||
|
|
||
|
I need a good quick way to save a Type 8 screen to disk once it's drawn. In
|
||
|
other words, a way to dump the contents of a window to a file -- IN C. 's
|
||
|
drawing blanks. Any help would be great...
|
||
|
-- MFAHY
|
||
|
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31533 26-AUG 01:02 Graphics & Music
|
||
|
RE: GRAPHIC SAVE (Re: Msg 31530)
|
||
|
From: THEFERRET To: MFAHY (NR)
|
||
|
|
||
|
the typical way is to use the get/put buffers , or what ever those memory
|
||
|
mappable buffers are called. it grabs a chunk of the screen, and dumps it at
|
||
|
the address of your choice. just make sure that the adddress is the beginning
|
||
|
of an integer array of appropriate size :-)
|
||
|
|
||
|
Philip
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31536 26-AUG 01:41 Graphics & Music
|
||
|
RE: GRAPHIC SAVE (Re: Msg 31530)
|
||
|
From: TIMKIENTZLE To: MFAHY (NR)
|
||
|
|
||
|
Several approaches:
|
||
|
- Use VEFIO. It can save a window. From inside a program, it shouldn't
|
||
|
be too hard to cobble together the info VEFIO needs and then just
|
||
|
os9fork() the beast and wait() for it to die.
|
||
|
- Hand-roll it. It's not hard to do, once you know VEF format. The
|
||
|
general approach is to GET 1/2 of a scan line at a time (tnx to some
|
||
|
bugs in the windowing code, you can't GET a full scan line, sigh),
|
||
|
MAP the buffer into your memory, and then write the buffer contents
|
||
|
out to disk. Not hard to do. Several programs in the database come
|
||
|
with source for this exact thing. (check out the source for ViewGIF,
|
||
|
which saves out VEF files)
|
||
|
|
||
|
Hope this helps!
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31531 26-AUG 00:42 General Information
|
||
|
TSEDIT/vi bug
|
||
|
From: RICKADAMS To: GREGL (NR)
|
||
|
|
||
|
I hit a nasty one recently... beware of using TSEDIT or vi to edit a zero length
|
||
|
|
||
|
file! It will burp with DISK ERROR, then will display a file from elswhere in
|
||
|
the file system. If you shrug your shoulders and just go ahead and edit that
|
||
|
file and write it out, woe is your file system! I munged up things pretty good,
|
||
|
|
||
|
and it took some judicious hacking to get things right again. Whew!
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31538 26-AUG 02:21 General Information
|
||
|
RE: GFX2 & MM/1 (Re: Msg 31378)
|
||
|
From: BRIANWHITE To: GREGL (NR)
|
||
|
|
||
|
Greg,
|
||
|
|
||
|
What you said is not totally true. You wouldn't need two RBF managers lying
|
||
|
around because the new one would read the old structure and the old one would
|
||
|
read the new structure. With the changes I suggested, the only problem lies
|
||
|
with converting 48 & 4 7+ (respectively) segment files. Outside of that, the
|
||
|
new driver sees default 0's on the old structure and the old driver ignores the
|
||
|
extra info on the new structure. Compatibility problems would be nonexistant.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31544 26-AUG 02:48 General Information
|
||
|
RE: GFX2 & MM/1 (Re: Msg 31538)
|
||
|
From: TIMKIENTZLE To: BRIANWHITE (NR)
|
||
|
|
||
|
True, with the (minor) changes you suggested, compatibility would be (mostly)
|
||
|
preserved. However, Greg's point was that there are many other changes that
|
||
|
possibly should be made.
|
||
|
In any case, remember that OS9/68k is _not_ a new thing, having been running
|
||
|
for years now on VME-bus systems, Atari ST's, and others. From what I've heard,
|
||
|
neither IMS nor FHL have any desire to rewrite any of OSk's kernel or file
|
||
|
managers, so whatever file system OSk has been using for years is the one we'll
|
||
|
be using. Hopefully, everything will be set up so that we can fairly easily
|
||
|
read other OS9 formats (especially CoCo and Atari ST formats). But other than
|
||
|
that, don't hold your breath for any changes.
|
||
|
- Tim
|
||
|
|
||
|
-*-
|
||
|
|
||
|
End of Thread.
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31539 26-AUG 02:22 General Information
|
||
|
RE: SCSI ETC... (Re: Msg 31383)
|
||
|
From: BRIANWHITE To: COLINMCKAY (NR)
|
||
|
|
||
|
Colin,
|
||
|
|
||
|
Sorry to say, but you misunderstood my message! I didn't say I patched
|
||
|
MegaRead, and I didn't say I could transfer 1MB in 14.5 seconds. What I did say
|
||
|
|
||
|
(and do) was rewrite Hardwarehack's SCSI drivers to handle a max throughput of
|
||
|
1MB in 14.5 seconds. RBF adds its overhead to that. I have not even tried
|
||
|
MegaRead on my drive, though Matthew has on his with the same drivers.. I was
|
||
|
merely pointing out that it wasn't SCSI that was the slowdown. It was OS-9 and
|
||
|
the drive itself.
|
||
|
|
||
|
I heard about your computer & case from Matt. I have mine in a case, but can't
|
||
|
put the cover on because I haven't brought the reset button out! But, by
|
||
|
mid-sept, I won't have a need for the CoCo reset button anymore.
|
||
|
|
||
|
I can't really say too much about Matt's drive. I picked up a 100Meg 1/4 height
|
||
|
|
||
|
last term in Ottawa for $50. Unfortunately, I toasted it and have to spend $332
|
||
|
|
||
|
US to get it fixed.
|
||
|
|
||
|
I'd love to come to Ottawa again. All I have to do is find a good job!
|
||
|
|
||
|
I'll grab Zygo's files and take a look at them. Time is getting pretty tight
|
||
|
now, but I'll try to reply before I pack to go to Waterloo.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31541 26-AUG 02:22 General Information
|
||
|
RE: Alias (Re: Msg 31394)
|
||
|
From: BRIANWHITE To: TIMKIENTZLE
|
||
|
|
||
|
Tim,
|
||
|
|
||
|
Yea, I see the problem. Maybe someday I'll finish my "SpeedDisk" utility. It's
|
||
|
|
||
|
like the Norton one except I will fix a stange algorithm mistake on his part.
|
||
|
But that's some time away from even being started.
|
||
|
|
||
|
As for the shell command thing, try a command like:
|
||
|
|
||
|
OS9:shell i=/w9 dir
|
||
|
|
||
|
The shell with run the dir command and then come back with the prompt on window
|
||
|
9. It doesn't seem to work if you put the command to execure before the
|
||
|
immortal flag, though.
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
31543 26-AUG 02:23 General Information
|
||
|
Cluster Info
|
||
|
From: BRIANWHITE To: MATHOMPSON (NR)
|
||
|
|
||
|
Matt,
|
||
|
|
||
|
Well, I did some poking around into "clusters", what they mean, and how to use
|
||
|
them, so I decided to post it here for you and anyone else who is interested.
|
||
|
|
||
|
First, a sector is always a sector, and an LSN (Logical Sector Number) is always
|
||
|
|
||
|
an LSN. These two terms should never be confused with the word "cluster". The
|
||
|
RBF manager that comes with OS-9 can access up to 2^24 or 16,777,216 unique
|
||
|
256-byte sectors for a grand total of 2^32 or 4,294,967,296 bytes (4
|
||
|
GigaBytes)... before needing to undergo partitioning :-) Therefore, LSN-0 is
|
||
|
always 256 bytes, a file-descriptor is always 256 bytes, etc., etc.
|
||
|
|
||
|
A "cluster" is a lot like the minimum sector allocation size except that it is
|
||
|
the same for all types of files and it can't be changed on the fly. If the
|
||
|
cluster size is set to 32, every file will allocate a multiple of 32 sectors
|
||
|
(actually 31 sectors p lus 1 file-descriptor sector for the first cluster) and
|
||
|
remain there until it needs another cluster.
|
||
|
|
||
|
As far as how cluster size and sector allocation size (SAS) work together, the
|
||
|
initial file size is always 1 cluster. On disks with 1-sector clusters, this is
|
||
|
|
||
|
used exclusively by the file-descriptor. After that, as soon as data is written
|
||
|
|
||
|
past the end of a segment, more space is allocated to the file in chunks of SAS
|
||
|
rounded up to the next cluster size. (eg. if cluster size=$08 and SAS=$23,
|
||
|
additional space is allocated in chunks of $28 sectors). When the file is
|
||
|
closed, it is shrunk to the least us ed number of clusters.
|
||
|
|
||
|
|
||
|
Changing the cluster size is not as easy as you might think. There is nothing
|
||
|
about it in any of my device descriptors and 'format' has no option to that
|
||
|
effect. To change it manually, you must:
|
||
|
|
||
|
- FORMAT the disk normally
|
||
|
- dEd/QTip the disk:
|
||
|
- edit LSN-0:
|
||
|
- change the cluster size to any power of 2 (bytes $06-$07)
|
||
|
- divide the number of bytes in the allocation bitmap
|
||
|
(bytes $04-$05) by the same power of 2 used above and
|
||
|
round up to the next nearest byte.
|
||
|
- edit root directory file-desciptor: (LSN of root f-d in LSN-0)
|
||
|
- change the size of the first and only segment so the
|
||
|
directory ends at the end of a cluster. For example,
|
||
|
my hard disk has its root directory file-descriptor on
|
||
|
sector $50 and the root directory itself starts on sector
|
||
|
$51. If I wanted a cluster size of 32 ($20), the start
|
||
|
of the next cluster would be $60, so I change the size
|
||
|
of the root directory's segment, originally set to $07
|
||
|
by 'format', to $0F ($60-$51=$0F). If a cluster is not
|
||
|
is not completely allocated within the file structure,
|
||
|
dCheck assumes that none of it is allocated. OS-9/RBF
|
||
|
will take care of all this allocation for you once the
|
||
|
required manual setup is finished.
|
||
|
- perform a dCheck on the disk
|
||
|
- use a utility like BD from the RePack software package to
|
||
|
deallocate any clusters that dCheck mentions (or fool around with
|
||
|
the first few bytes of LSN-1 by hand using dEd/QTip until dCheck
|
||
|
reports a clean disk). DCheck always reports clusters by the LSN
|
||
|
they start on. BA and BD handle these LSN's properly to fiddle
|
||
|
with the correct bits in the allocation map.
|
||
|
|
||
|
- You now have a disk with whatever cluster size you put in
|
||
|
bytes $06-$07.
|
||
|
|
||
|
(This is really easier than it sounds... honest!)
|
||
|
|
||
|
While playing around with this, I discovered that dCheck seems to have a small
|
||
|
bug in it that causes it not to check the last byte of the allocation bitmap!
|
||
|
So if you start playing around and find that dCheck is not bothering to mention
|
||
|
the $400 allocat ed sectors at the end of the disk that should be free, it's
|
||
|
dCheck's fault, not yours. RBF seems to handle everything just fine.
|
||
|
|
||
|
I have moved files to my disk after setting it to various cluster sizes and have
|
||
|
|
||
|
had no problems with OS-9/RBF in any way. This wonderful feature seems to be
|
||
|
fully implemented except for turning it on.
|
||
|
|
||
|
|
||
|
Anyone who edits over multiple windows, saving from all of them often, knows
|
||
|
that the files fragment into many 1-sector segments quite quickly. This cluster
|
||
|
|
||
|
size can help solve that problem because a 1-sector file in a 32-sector clustor
|
||
|
still has lots o f space to expand into before another segment is needed.
|
||
|
|
||
|
With the upcoming wide-spread use of OS-9/68000 (or OS-k), RBF has an added
|
||
|
feature of being able to handle devices with sector sizes of larger than 256
|
||
|
bytes. How this will be handled, I don't know. I would guess, since the OS-k
|
||
|
file structure is iden tical to that of OS-9, that it just internally splits
|
||
|
each sector up into 256-byte chunks and then sets the cluster size accordingly
|
||
|
to avoid file fragmentation within a sector. (eg a 512-byte sector would get a
|
||
|
min cluster size of 2 while a 2048-byte s ector would get a min cluster size of
|
||
|
8, etc.). Maybe some of the forum gurus that are "in the know" could shed some
|
||
|
light on this facet.
|
||
|
|
||
|
Hope all this is of use to someone...
|
||
|
|
||
|
Brian
|
||
|
|
||
|
-*-
|
||
|
|
||
|
|
||
|
FORUM>Reply, Add, Read, "?" or Exit>
|