
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> 