30204 17-JUN 11:59 General Information
     RE: SDir (Re: Msg 30198)
     From: ZACKSESSIONS To: BRIANWHITE

Just uploaded a patch file to fix the situation. It will be available as soon as

a sysop processes it.

Zack

-*-

30341 24-JUN 02:51 Utilities
     RE: SDir (Re: Msg 30202)
     From: BRIANWHITE   To: ZACKSESSIONS

I used numbers from 1000 -> 1999 as user numbers for going straight into a
current project.  Since my computer boots up to TSMon/Login, I can just enter
the program name and a password, and presto, I'm ready to edit.  It also gives
my partner access to t he same files without giving him SuperUser access.  It
should be simpler with OS-k and Group attributes.

                                                           Brian

-*-

30356 24-JUN 18:59 General Information
     RE: SDir (Re: Msg 30341)
     From: GREGL        To: BRIANWHITE

Brian,

    Correct me if I'm wrong, but I don't think OSk has group attributes. It
appears to me that OSk uses the same file descriptor structure as OS9/6809.
Adding group attributes would require extending the current attributes to 16
bits and there isn't room in the file descriptor for that.

    -- Greg

-*-

30369 25-JUN 02:44 General Information
     RE: SDir (Re: Msg 30356)
     From: TRIX         To: GREGL

Greg,

   Your right.  I'm looking at page 55 in "The OS-9 Catalog" from Microware. The

FD_ATT byte has D S PE PW PR E W R.  No group attributes.  Oh well.

-John.

-*-

30396 26-JUN 00:52 General Information
     RE: SDir (Re: Msg 30369)
     From: GREGL        To: TRIX

John,

    Right you are. And without group attributes, there really is no group
protection in OSk. But I don't really have to worry about that since I'm working

on a project from the ground up and 100% compatibility isn't a real issue. I'd
rather get it right the first time with room for expansion than to have to muck
around trying to force a fit later.

        -- Greg

-*-

End of Thread.

-*-

30205 17-JUN 12:18 General Information
     RE: 1-meg problems? (Re: Msg 30165)
     From: RAGTIMER     To: EDDIEKUNS

Yeah -- hard to tell what your other tasks are doing without spakrlies! I saw
the junk when clearing to (or was it out of?) the 32x16 VDG screen (my /TERM)
when in text mode.  Didn't happen when I had a VDG grafix screen up on Umuse.  I

figured the change from windows grafix to VDG text was just too much for L2 to
handle in one vertical retrace interval.

Anyway I haven't seen it in a long time, no matter what.  Can't remember what
(if anything) chased it away.  Maybe the Phatnom of the Computer dropped a
chandelier on it...?

-*-

30292 22-JUN 01:45 General Information
     RE: 1-meg problems? (Re: Msg 30165)
     From: DAMIONGREY   To: EDDIEKUNS

Eddie - Just to let you know that you're not alone, I get that garbage, too.
  'cept I've just go a lowley 512K machine.  One of the first in the area to get

 a coco 3, so I had an old GIME , and it did it back then.  Now I've go a new
 GIME, and it still does it.  No wierd crashes now that I've got the new GIME,
 tho, and NO sparklies!  LOVE that Tandy hardware! <sad grin>  Can't wait to
 go my hands on an MM/1! (or TC/70, but pry the MM/1....sounds worlds better)
         - Greg

-*-

30293 22-JUN 01:48 General Information
     RE: 1-meg problems? (Re: Msg 30292)
     From: EDDIEKUNS    To: DAMIONGREY

At least I'm not alone.  :(

                 Eddie

-*-

30301 22-JUN 22:29 General Information
     RE: 1-meg problems? (Re: Msg 30292)
     From: RAGTIMER     To: DAMIONGREY

Fer sure get the MM/1, since you don't have a 1 Meg investment to protect.
Eddie, I found how to get that burst of colored confetti back. I have to have at

leeast one L2 GRAFIX window open (I rarely do). Then wehn I clear from the VDG
TERM to a TEXT L2 window (right), I get the burst.  New GIME and 1 Meg.

Hasn't crashed yet, but it looks sorta, well, Commodorish...mike k

-*-

30311 23-JUN 01:36 General Information
     RE: 1-meg problems? (Re: Msg 30301)
     From: EDDIEKUNS    To: RAGTIMER

Maybe it's about time I named my machine, eh?  I mean ... it has enough
personality!  It has more personality than some humans I've met.  I guess
CoCo's, like CoCo users, are each unique.

                      Eddie

-*-

30361 24-JUN 23:44 General Information
     RE: 1-meg problems? (Re: Msg 30311)
     From: RAGTIMER     To: EDDIEKUNS

Yessir!  And that's before they start cusotmizing their OS9 Boots and Startup
files.  (And getting bugs nobody else has, grin).

-*-

End of Thread.

-*-

30206 17-JUN 12:22 Graphics & Music
     RE: New Score: Rondo alla turca Mozart (Re: Msg 30170)
     From: RAGTIMER     To: XLIONX

Thanks for the notice, and the score. What is the advantage of this new Os9Arc
format over the standard (?) AR? I have an old Turkish March (from CIS maybe),
but it was done in only 2 or 3 parts, back on the old 1600-note Shareware Umuse,

so I'll gladly DL your new version.

-*-

30221 18-JUN 02:56 Graphics & Music
     RE: New Score: Rondo alla turca Mozart (Re: Msg 30206)
     From: XLIONX       To: RAGTIMER

Howdy, Well, it's like this...after extensive testing, os9arc compresses better
than PAK in all cases and performs as well as AR for text. The reason I never
use AR anymore is that it can't compress anything except TEXT files.

Also, os9arc/dearc are in the same format as IBM (I had to say it) ARC files.

While PAK is the most functional of them all, I have a VERY large ARC directory
on my hard drive: 158 files; 2-Meg; 8-Directories This used to take up over 3.5
meg with a combination of AR and PAK.

It's like getting free megabytes on the drive!

Let me know how ya like it.

-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445)

-XLIONX (DELPHI) -mwf@SANDV

-*-

End of Thread.

-*-

30207 17-JUN 12:27 Device Drivers
     RE: MIDI (Re: Msg 30172)
     From: RAGTIMER     To: PHILZEIGLER

Phil, you might trtry to hunt up Intercomp Sound in Rochester, NY. He has a
clone of the Speech Systems MIDI pak that he might be willing to sell a little
cheaper.  Maybe.  It's usually bundled with his whole MIDI sequencer package
(reviewed in Rainbow a couple years aback).

Some users have hacked RS232 Paks (or even DC Modem paks?) into MIDI paks. One
guy even got ACIAPAK to drive his hacked RS232 pak, after renaming T2 to MIDI
and nulling out all its options bytes.  But I can't guarantee that will work.

Anyone with direct experience, please chime in -- thanks, mike k

-*-

30208 17-JUN 12:38 General Information
     RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29945)
     From: RAGTIMER     To: PAULSENIURA

He he -- the irony is that MSDOS programmers can't write proper OS/2
applications -- the only folks who could are experienced OS-9 programmers! Maybe

we could be bribed to help out for, say, $100 grand a year, grin.

Also note that while Microware has orphaned OS-9/6809 and pretty well pulled out

affordable support for the Atari ST, they are backing the new MM/1 system very
well -- putting some faith into it as the way to get OS-K into the mainstream.
Remains to see if FHL's Tomcat-70 gets the same support.

And DO upload your posting to the PC, Atari, and Amiga groups. PS: Does that
latest 4.6.1 play on your Pak?

-*-

30277 21-JUN 01:24 General Information
     RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 29973)
     From: PAULSENIURA  To: PAULRINEAR


  -> Can you think of  a nice piece of action game software that will
  -> prove me wrong when I say COCO3 graphics are "coarse and slow".
  -> I'm comparing this to the Nintendo  Entertainment System.

I have tested Kevin Darling's patches for the GrfDrv module, and I was quite
amazed at how fast my Oklahoma map would "plop" on the screen when a 7.9k Get
/Put buffer was set up to be used.  Any VEF pic could be read in about 8k at a
time in four chunks and these chunks would be "blatted" to the video screen in a

very big hurry with Kevin's patches.  Very amazing.

[But Kevin nor anyone else has fixed an irritating bug -- the right-most column
of pixels (coordinate 319 or 619) has *never* worked in Get/Put buffers.
Something's preventing that column from getting copied from the buffer.  Copying

"TO" the buffer FROM that column works just fine.]

What Kevin's speed improvement proves is that the CoCo3 hardware itself is not
at fault: it is how the modules were designed and programmed in the first place.

After the o.s. modules are "tweaked" for top performance, then the application
software needs to be rewritten (most probably) in order to utilize the new
features properly.

Yes this applies to any computer and o.s., not just the CoCo and not just OS9.

I am afraid, however, that you're comparing apples with oranges.  Nintendo's
circuits, no doubt, have "Sprite" graphics chips.  This scheme was used, but
poorly documented, on the little T.I. home computer, but that machine's graphics

were highly touted at that time, also.  (It was the poor documentation, if it
can be called that, to be blamed for the T.I.'s demise. And a lot of people are
saying the same thing, now, about this new Nintendo machine.  In fact some court

suits are based on this fact, citing how Nintendo is unfairly cornering the game

market.)

When you compare Sprites with just regular ol' memory-mapped graphics, the
Sprites will win every time, believe me.  In this vane, you'd be hard pressed to

see any OS9-based games approaching this kind of quality.  And then you *could*
blame the CoCo hardware design, since Tandy didn't elect to include Sprite chips

in the design!

This brings up a VERY interesting idea, tho ... I wonder if KLE or FHL might be
considering such a graphics board that includes programmable Sprites?  Jeepers,
the 68030 with 32-bit paths would BLAST the Nintendo for sure!!!  Why don't
y'all harp on KLE & FHL to produce such a graphics board?  That would really
kill Nintendo and it *might* finally make 'OS9' a household name YET!!!

(Hold it -- I better copyright my suggestion there -- I smell $$$s -- (c) 1990
by Paul Seniura.  :-)



-*-

30322 23-JUN 06:27 Graphics & Music
     Get/Put Buffers (Re: Msg 30277)
     From: OS9UGPRES    To: PAULSENIURA

 > [But Kevin nor anyone else has fixed an irritating bug --
 > the right-most column of pixels (coordinate 319 or 619) has
 > *never* worked in Get/Put buffers.

Actually, it's fixed. But we didn't include the fix in the fast grfdrv patch.
Why not? I guess because it's a sales feature for later <wink>.

If you GET, then map in the buffer, I believe the rightmost pixel data is really

included. PUT is a different story, tho.

 > What Kevin's speed improvement proves is that the CoCo3 hardware
 > itself is not at fault: it is how the modules were designed and
 > programmed in the first place.

I know what you meant, but just wanted to clarify that the original programmers
did one heckuva job getting everything they did, into the space they used.
Matter of fact, they gave us many features which other windowing systems don't
have at all... even their own RAVE.

Anyway, they ended up having to make some major stuff into generalized routines
for all gfx modes tho, which slowed things down.

However, Microware didn't have Kent D Meyers, cruncher extraordinaire, around <
grin>. Between the two of us, we carved out at least 800 bytes from grfdrv's
already optimized 8K code... and as you know, that's an *enormous* amount of
room to an asm programmer. Making special-case lightening-fast PUTs was easy
after that.

But I'm SO happy to be programming on the 68000 now: the really tight space
restrictions of the coco are nonexistent. It's nice to be able to concentrate on

fast code instead of always having to make smaller but generalized code.
 best - kev

-*-

30619 8-JUL 23:59  General Information
     RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30277)
     From: PAULRINEAR   To: PAULSENIURA (NR)

       Very interesting. The Commodore 64 was also an early unit with sprite
graphics and it was fairly well documented in the Programmer's Reference manual.

       I also have Kevin Darling's patch and it is a great improvement. He has
also written a new GFX2. Wonder if Kevin uses this message area. I know he's
over on Compuserve.
       A sprite graphics board sounds like a good idea to me for the new "
superCOCO's ", but I don't know much about it. I seem to remember there being
some problem mentioned about not being able to use sprites in just any old
window though.
           Paul Rinear

-*-

30623 9-JUL 18:07  General Information
     RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619)
     From: ZACKSESSIONS To: PAULRINEAR

Kevin in on Delphi under username OS9UGPRES.

-*-

30631 9-JUL 23:26  General Information
     RE: OS9 vs. PCDOS -- gripe bucket (Re: Msg 30619)
     From: TIMKOONCE    To: PAULRINEAR

Hardware sprites are probably more trouble than they're worth. They were fine
for the early underpowered machines like the Commodore, but since newer machines

tend to have the horsepower to handle it, it's easier and just as effective to
do it in software.
  Plus, there is a slight problem if you have 5 windows on a screen, and all of
them want to use the hardware sprites!  <grin>  In such a case, the system would

have to simulate some of them in software anyway.
                       - Tim K

-*-

End of Thread.

-*-

30209 17-JUN 15:57 General Information
     RE: CoCo 4? (Re: Msg 29690)
     From: PKW          To: THEFERRET

Phil,

You should have gotten the packet by now. Did you? Sorry I haven't been on
lately.

The upper limit of the MM/1 is 9 meg, but I have been using a three meg system,
with a terminal, and that seems to me to be far and away all the memory I am
going to need, at least until I start cranking up the combined animation/ sound
stuff! Then I'll either have to get the new SIMMs our count on the DMA to keep
the system humming!

BTW, OSK is now the official operating system for the MM/1. It really was never
going to be anything else.

We also have official prices, and the addition of several new configurations
that should meet everyone's budget.

OSK, the C compiler, and Microware BASIC are all included, as are a word
processor that is keystroke configurable, a graphics editor from HyperTech, and
several demos of the animation, of IMS and third party software, and so on.

A ton o' stuff.

So, Phil, if you haven't gotten the latest, or if you want ot get The Insider
newsletter (have you got it already?), call our 800 number, 800 866 9084, Mon
thru Fri, 9-5.

Best regards,

Paul

-*-

30249 19-JUN 21:39 General Information
     RE: CoCo 4? (Re: Msg 30209)
     From: RAGTIMER     To: PKW

Say Paul, I don't recall getting anaything from you in the mail -- no blurb or
Insider mag yet.  I'd like to see your latest configuration, price, and options
list -- you going to upload or post it here? Thanx, mike k

-*-

30306 23-JUN 00:29 General Information
     RE: CoCo 4? (Re: Msg 30249)
     From: PKW          To: RAGTIMER

Well, the blurbs you really don't need, eh? And the Insider (as it says on the
blurb you haven't received) is scheduled for an early July delivery!

Patience, my friend, I am working as hard as I can ... <grin>

I am going to put stuff in the mail to you -- oops, I just noticed I DON't HAVE
your mailing address. Please Eplex to me on CI$.

TTFN!

Paul

-*-

30360 24-JUN 23:42 General Information
     RE: CoCo 4? (Re: Msg 30306)
     From: RAGTIMER     To: PKW

Well I can just Email it to you here on the low-priced speared, grin. Just as
private (I think!).  So I'll send you my USMail address here -- also saves
looking up your state prison number on the hi-priced spread. --mike k

-*-

30678 12-JUL 21:35 General Information
     RE: CoCo 4? (Re: Msg 30360)
     From: THEFERRET    To: PKW (NR)

Is there anyone on the west coast who I could bug to have a peek at the machine
? actually, let me narrow that down a bit.  Is there anyone within a 50-mile
radius of San Francisco, ...?

  Philip

-*-

End of Thread.

-*-

30210 17-JUN 16:12 General Information
     RE: Questions about the MM/1 (Re: Msg 30033)
     From: PKW          To: KEITHMARCH

Keith,

Nice to hear from you again! Sorry to have been off so long. Been really busy
here at IMS.

To FINALLY answer your questions, here goes:

1) I believe that a WEFAX program will be coming available. 2) MM/1 has the
hardware to support RAVE. 3) The system comes in a 128K EPROM, as I recall. I
don't have the specs
   right at hand. Some of the EPROM spacaeis taken up by a lot of the
   common OSK commands, so system performance is even better. 4) Real time clock

is best used on the second board. The EPROM socket is for
   system code. I used the MM/1 extensively without the realtime clock and
   had no troubles -- but is is more convenient now that I have the RTC, too. 5)

There is a dmode command for OSK, and I use it all the time to transfer
   data between various OSK formats. 6) There will be a term program that
supports X, Y, and Kermit protocol. 7) There is a cls command available to
BASIC. 8) The 15 MHz MM/1 is a fast machine. It will run about 50 percent faster

   than computers in its price range.
   If you want to use another CPU, you will NOT be advised to pull out
   the 68070. For one thing, although it IS socketed, it is a highly integrated
   chip with serial ports and DMA stuff on board, so the CPU board is really
   glued together by the CPU. For another thing, if you need faster performance,

   you can use our 32 bit bus to add another CPU card, with FPU, etc. 32 bits
   will be the only correct bus to use for a faster chip. 9) You can exchage any

CoCo disk with an MM/1 disk, using a simple utility. 10) Function keys will be
implemented, details to follow in a month or so. 11) MM/1 does not have math
coprocesor support, unless you do it on the bus.
    Then the math coprocessor is a peripheral. Luckily, our bus is 32 bits,
    so performance is far faster than 16 bit bus machines. 12) All major chips
will be socketed until our quality control department says
    it's OK to solder most chips. Even then, theh cost of the sockets is so
small, we may forever keep them in the design. 13) Getting started texts are in
the works now, and will be distributed exclusively to our customers. 14) You
have the choice of booting off of floppy first, then hard disk, finally EPROM.
So the EPROM boot is only a last resort for the startup process. If you DO
decide to boot off EPROM, you can simply load in any additional modules you
need. If you want to REPLACE a module in the EPROM, no need to reburn the
EPROMjust load in a module with the same name w/higher revision number.

Howzat? Paul

-*-

30211 17-JUN 18:12 General Information
     sculptor
     From: GENEDEAL     To: ALL

Does anyone know why sculptors developement menu, when calling up dynastar
causes the loss of characters at the end of a document?

Gene Deal

-*-

30212 17-JUN 18:15 General Information
     os9 windows
     From: GENEDEAL     To: ALL

I am using multiple language character sets on OS9 with a text/graphics window
and I cannot seem to get a text cursor.  Other programs I have running on such
windows have the cursor.  Where is my cursor?

Any help would be appreciated.

Gene Deal

-*-

30213 17-JUN 19:17 Device Drivers
     System Clock
     From: MPASSER      To: ALL

Hello!

I recently installed a Tandy SmartWatch in my FD-502 controller, and it works
great.  However, once I'm up and running, I notice that the system clock *gains*

time.  If anything (since I'm not using no-halt floppies), I would expect that
it would *lose* time.  Any ideas?

Thanks, Mike Passer (MPASSER)

-*-

30214 17-JUN 20:16 Graphics & Music
     SS.MSig question
     From: ZACKSESSIONS To: ALL

Consider the mouse signal. Let's say I do a:

 _ss_msig(path,MOUSSIG);

call in my C program. Should path be standard input, standard output, or does it

really matter?

Zack

-*-

30215 17-JUN 20:27 Graphics & Music
     RE: SS.MSig question (Re: Msg 30214)
     From: DODGECOLT    To: ZACKSESSIONS

Doesn't matter.  Unlike things like _ss_size() or similar calls, you don't have
to have any special permissions (read/write) to the path.
 -Mike

-*-

End of Thread.

-*-

30216 17-JUN 23:15 Telcom
     RE: disable call waiting (Re: Msg 30189)
     From: NES          To: ZACKSESSIONS

Hay, Zack,  Thanx for the uploads, I came in as you where logging
 off the BBS.  As for the View program I think the system hit a bad sector on
the hard drive it been a little flaky lattly in the heat since I havent any
Aircondition just fans, also need to get a new and larger harddrive,  the one I
have is about full, also its an used drive...  Dose os9 block out bad
sector's????, I know when the drive get's too hot it gives 244 error's and 247..

but maybe one of this days I get me an MM1 and stop havening to keep fixing the
multipak interface.. latter -Eric


-*-

30223 18-JUN 18:51 Telcom
     RE: disable call waiting (Re: Msg 30216)
     From: ZACKSESSIONS To: NES

OS9 does block out bad sectors, but only at format time. But format itself does
not really do a thorough job of determining bad sectors. The ccheck utility
which comes with Burke&Burke's File System Repack does the job quite nicely.

Zack

-*-

30231 18-JUN 22:54 Telcom
     RE: disable call waiting (Re: Msg 30223)
     From: GREGL        To: ZACKSESSIONS

Zack,

    What makes format even worse is that it simply allocates any sectors that it

finds defective. A year or so later when you run dcheck you will receive
warnings that sectors are allocated but not in the file system. If you forget,
you might deallocate all of those sectors to get a clean report from dcheck. It
would be better if dcheck created a file called something like "bad.sectors"
with attributes of "--------" to allow dcheck and other utilities correctly
report missing sectors from the file system.
    I'm not sure how ccheck handles that. But it would certainly be better to
map the bad sectors to a file than to just leave them flapping in the breeze.

    -- Greg

-*-

30233 18-JUN 23:11 Telcom
     RE: disable call waiting (Re: Msg 30231)
     From: TJSEAGROVE   To: GREGL

Greg,

   Do you know of a disk checking utility that will create a file containing the

bad sectors??  Could be a good programming project for someone.  What do you say

Zack??!!

    ....Tom


-*-

30234 18-JUN 23:21 Telcom
     RE: disable call waiting (Re: Msg 30231)
     From: ZACKSESSIONS To: GREGL

ccheck isn't any better, in fact as far as allocating "bad" sectors it's even
worse! It's up to you to use BA (another FSR utility) to mark the bad sectors as

allocated. What we need is something in OS9 itself which handles "bad blocks".
Blocks allocated to the bad blockkfile never to be re-allocated.

Zack

-*-

30235 18-JUN 23:26 Telcom
     RE: disable call waiting (Re: Msg 30233)
     From: ZACKSESSIONS To: TJSEAGROVE

Get File System Repack from B&B. And use the ccheck utility.

Zack

-*-

30237 18-JUN 23:29 Telcom
     RE: disable call waiting (Re: Msg 30233)
     From: GREGL        To: TJSEAGROVE

Tom,

    To my knowledge, no such utility exists. That doesn't necessarily mean that
ccheck doesn't since I'm not familiar with it. Offhand I don't think it does,
but I could be wrong. I know that I certainly don't like bad sectors sitting
around in the allocation bitmap without appearing in the file structure
somewhere. In such cases, dcheck may report several sectors that are allocated
but not in the file structure. How do you know which are actual bad sectors and
which are actually caused by some glitch? Also, dcheck needs the ability to
cross-reference linked files and remove those from the doubly allocated sector
listing it reports.
    I had that problem bite me a couple of years ago when dcheck reported
several sectors that were found more than once in the file system. At the time I

assumed they were caused by linked files. Later I discovered that one of my text

files had been cross-linked with an archive file because of a glitch somewhere.
The problem, as should be apparent, is that you'll often ignore such things as
multiply-allocated sectors and sectors that are allocated but not found in the
file system if you think it's because of link files or bad sectors. It usually
takes a good eye and a lot of cross-referencing with the dcheck listing to
determine which are actually an error.

    -- Greg

-*-

30238 18-JUN 23:45 Telcom
     RE: disable call waiting (Re: Msg 30234)
     From: GREGL        To: ZACKSESSIONS

Zack,

    In my humble opinion, we need to set aside eight additional bits for file
permission attributes.  Directory, sharable, execute, read, and write have
served us well over the years but I feel that we have outgrown them. Here is a
list of the attributes that I think should be added:
    Moveable: If this bit is set in the attributes then the file cannot be moved

by disk optimization or compression utilities. Obvious files that would have
this attribute set would be the "bad.sectors" file and OS9Boot. Also, the OS-9
Kernel on Track 34 should be mapped to a file called "kernel" and have the
moveable attribute set. This would prevent all "sector allocated but not in file

system" errors from dcheck for the kernel on Track 34.
    Delete: If this bit is set, the file cannot be deleted by normal methods.
Write permission isn't enough to protect this one. For example, you would want
to allow the users to write to the password file to change their passwords on a
regular basis but you don't want them to be able to delete the file. I'm sure
you can think of other places where this would be handy.
    Hidden: If this attribute is set, the file will not be shown in a directory
listing exception with a special option in the directory utility. Also, the file

would be shown only to the super-user.  I'm sure you can think of places to this

one - such as the "bad.sectors" file.
    Archive: If this bit is set then it hasn't been backed up since it was last
modified. This would be great to make sure all files are backed up during
incremental backups. Perform a backup once per week with only those files that
have the archive bit set.
    If you can think of any other file permission attributes then feel free to
add them to this list.

    -- Greg

-*-

30242 19-JUN 01:08 Telcom
     RE: disable call waiting (Re: Msg 30238)
     From: EDDIEKUNS    To: GREGL

How about GROUP file attributes?

VMS allows the following attributes:

  Read, Write, Delete, eXecute for Owner, System, Group, World.

Nice, complete model!  (Except we don't need system)

You then need delete access, and not write access to delete a file.  Tho with
write access you can erase the contents of a file.

Also, the bad.sectors shouldn't be a file, per se.  Something in LSN 0 should
keep track of which sectors are bad.  This makes it easy to lock out new
sectors, since it's part of the disk driver.  A bad sector will then be
identified because it's:  1) allocated 2) in the bad_sector list. Hmmm.
'course, what do you do if you have > 48 bad sectors?  Hmmm.

                Eddie

-*-

30248 19-JUN 19:37 Telcom
     RE: disable call waiting (Re: Msg 30238)
     From: ZACKSESSIONS To: GREGL

I think you have covered them pretty well! Now what can we DO about it? :-)

Zack

-*-

30254 20-JUN 00:00 Telcom
     RE: disable call waiting (Re: Msg 30238)
     From: KNOT1        To: GREGL

Greg,

I believe you can get by without a DELETE bit.  WRITE permision should be
enough.  Your password file shouldn't have Public Write permision set. Instead,
a program like "passwd" should change its user ID to 0 (super user) with a call
to F$SUser, then update the password file.  Also, if you don't have Write
permision to the directory you shouldn't be able to delete the file.  I don't
believe CoCo OS-9 supports this, but if you are not the owner of the file
(regardless of Write permision) you shouldn't be able to delete it unless you
are the owner of the directory (with Write permision) that the file is in, and
then it should prompt you to proceed with deleting it.

But having a DELETE bit wouldn't be bad, it just might be unnecessary.

I agree with Eddie that GROUP attributes could be nice.  I would also like to
see SET USER (and SET GROUP) bit(s).  If the SET USER bit is set for a file when

it is executed, then the O.S. would do the equivalent of a F$SUser to that of
the owner of the file.  That's how the "passwd" program would be done.  SET
GROUP would be similar, but would do something like "F$SGroup" instead, if such
a call existed.

Unix/Zenix does HIDDEN by starting the filename with a period (e.g.
".bad_sectors", ".kernel", etc...) and this works nicely.

I always felt OS-9 sould have used 512 bytes for its file descriptors rather
than 256.  Then they could have added more attribute bits like the ones you
indicated and also add a "date/time last accessed" in addition to "created" and
"modified", and also anything else needed.

                            -Jamie (KNOT1)-

-*-

30260 20-JUN 01:30 Telcom
     RE: disable call waiting (Re: Msg 30238)
     From: TIMKOONCE    To: GREGL

File permission attributes:
  Rather than simple Read/Write/Execute for owner and group, how about Read
/Write/Execute/Append.  In particular, opening a file with the "append" bit set
in the permissions would correspond to C's "append" mode.  For directories,
"Append" privilege is the privilege to ADD files to the directory.  You need
"Write" privilege to delete files from the directory.  Files with public Append
(but not Write) privileges might include system error logs, mail files, etc.
Anything that anyone should be able to add stuff to, but you don't want anyone
able to delete or alter information.
  I like some of your ideas, too.
                         - Tim

-*-

30270 20-JUN 22:53 Telcom
     RE: disable call waiting (Re: Msg 30242)
     From: GREGL        To: EDDIEKUNS

Eddie,

    One solution would be to use 512-byte file descriptors. At present there is
no room in the file descriptor for any other data, which is bad news. I'd like
to have owner, group, and public attributes as I think that's the way to go,
especially with multi-user systems. Each of the three groups could be assigned
Read, Write, Execute and Delete permissions with the other attributes given
global scope, per se. That would use 12 bits for owner, group and public
attributes and Directory, Sharable, Movable, and Hidden taking up another 4 bits

for a total of 16 bits. Although we could say that "Hidden" has an implied
meaning of non-movable to free one bit for other uses. But I think it best not
to have single attributes taking multiple definitions.
    Of course you could either use the last 256 bytes in the descriptor as an
expanded segment list leaving the other bytes for future use or use all of the
remaining storage in the file descriptor for the segment list. Personally, I
don't see much need for more than 448 entries in the segment list and 61 should
be plenty. If you have a very large hard drive then there might be a need for
it. Come to think of it, we could use the last entry in the segment list as a
"pointer" to additional entries that are stored in another sector for future
expansion.

    -- Greg

-*-

30274 21-JUN 01:10 Telcom
     RE: disable call waiting (Re: Msg 30270)
     From: ZACKSESSIONS To: GREGL

Isn't it strange how the topic of this thread deviated from the original topic?
<grin>

Zack

-*-

30278 21-JUN 01:26 Telcom
     RE: disable call waiting (Re: Msg 30270)
     From: EDDIEKUNS    To: GREGL

Yes, the 'final' segment list pointer should really point to the next block of
segment lists!  Great idea!

                 Eddie

-*-

End of Thread.

-*-

30217 17-JUN 23:33 Utilities
     y cable
     From: BANCROFT     To: ALL

I am putting my coco into a pc case, and need to put my floppy and hard drive
contrller on a y cable.  I am getting 1 addressing confilict.  Both the floppy
and hard drive use ff50 for drive select.  The floppy also is using ff40, and
does not need ff50. Any ideas how to disable ff50 on the floppy ? thanks

-*-

30261 20-JUN 01:34 Utilities
     RE: y cable (Re: Msg 30217)
     From: TIMKOONCE    To: BANCROFT

Basically, you need to alter your floppy controller to keep it from responding.
Let's see, normally the floppy controller responds to the SCS line, so you'd
need to gate that with A4 so that the floppy wouldn't see SCS when A4 was high.
If you need more info, tell us what exact type of floppy controller you have,
and someone can tell you the exact mod needed.
                             - Tim Koonce

-*-

30267 20-JUN 19:47 Utilities
     RE: y cable (Re: Msg 30261)
     From: BANCROFT     To: TIMKOONCE

I have a standard radio shack fd-501 floppy controller.  I bought it as soon as
they came out, so if there is more than 1 version of the 501, I have the first,
I am sure of that.  I know that all I probably need to do is cut a trace, and
probably jumper a wire from that trace to 1 other one, but I am not sure what
trace I need to do this to.

Thanks

-*-

End of Thread.

-*-

30218 18-JUN 00:21 General Information
     Disto 1 meg upgrade
     From: POLTERGEIST  To: GREGL

     Greg,
     I just installed the Disto 1 meg board, and I use the Disto 512K board with

it.  Now, I have a serious problem.  It seems that with the piggyback layout,
the 1 meg kit is too tall, and my case will NOT fit when I put it back on!!!!
Any suggestions on how to rememdy this?

-*-

30219 18-JUN 01:03 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30218)
     From: EDDIEKUNS    To: POLTERGEIST

On my CoCo, I removed part of the ribs on the top 1/2 of the CoCo case so that
the 1-meg would fit beneath it without being too cramped.

                       Eddie

-*-

30220 18-JUN 01:55 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30218)
     From: GREGL        To: POLTERGEIST

Brian,

    The most common approach, and the one recommended by CRC/Disto, is to cut
some of the excess from the wire wrap pins that hold the two boards together.
Take a close measurement of the spacing on both boards and trim a little from
each until the case fits. Of course, don't trim too much or the boards won't
seat properly without touching one another - or the motherboard components.

    -- Greg

-*-

30239 18-JUN 23:49 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30219)
     From: POLTERGEIST  To: EDDIEKUNS

     Thanks, Eddie.  I may trim the leads a bit on the boards, the docs said
something about that.  I don't want to bash any holes in the case. <grin>
     Still having graphics trouble with your setup?

-*-

30240 18-JUN 23:49 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30220)
     From: POLTERGEIST  To: GREGL

     Thangs, Greg, this is what I may do, once I get a hold of some decent
clippers. <grin>

-*-

30243 19-JUN 01:08 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30239)
     From: EDDIEKUNS    To: POLTERGEIST

Yes.  Still having graphics trouble.  I'm giving up for now, since nothing
CRASHES.

                    Eddie

-*-

30252 19-JUN 22:09 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30243)
     From: XLIONX       To: EDDIEKUNS

Howdy Eddie,

When you say you are having "graphics trouble": 1.) do you have ANY problems
before you run MEGA? 2.) if you start your graphic stuff first, then run MEGA
does it still have bugs3.) is it only one program (MVCanvas, GShell)??? 4.) are
you tired of life and the persuit of coco perfection (in general)? ];-> 5.) do
you take this computer to be your....oops.


Just curious about your problem as you and I started with all of the same bugs.
I was hoping that you would have the same luck I did with the new GIME chip. I
don't have MVCanvas, but I do have GShell 1.24a and it works ok (so far). I have

run MAZE in 6 windows at a time without bugs. I have run FSIM2 and other stuff
without bugs (Carmen Sandiego, ya know VDG stuff)...in lower memory.

Let me know what ya got for CURRENT status (bugs, crabs, gremlins, etc...) and
I will try to duplicate them.

Mark W. Farrell (PegaSystems) SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445)
XLIONX (DELPHI) mwf@SANDV


-*-

30256 20-JUN 00:16 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30243)
     From: CBJ          To: EDDIEKUNS

Eddie,
     The graphics problem you describe where you see a flash that looks like a
game of TETRIS that was very poorly played seems to be very common.  I have seen

it on three computers other than my own (all that I have access to).  I gave up
worrying about it.  I get it when I use AUTOTERM.  It flashes for a second only
then is gone.  I have never been "lucky" enough to have sparklies. As long as
your computer doesn't crash don't worry about that flash of junk. ---Carl---

-*-

30257 20-JUN 00:17 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30252)
     From: EDDIEKUNS    To: XLIONX

I only see the remaining problems (after resoldering the 6809 header & getting a

new GIME) under the following conditions:

1) In 1-meg mode (pin 2 to select full meg) and after running 'mega' 2) On a
graphics screen, usu on one with an auto-follow mouse 3) When switching from a
graphics window to any window of a different type.

1 & 2 refer to the problem I get with a blinking, intermittent line of garbage I

get (Did you ever get that too?) which is about 8 scan lines high and the full
screen-width.  Sometimes it seems like the more activity I get, the more the
garbage-y line flickers on & off, sometimes it doesn't. :) Usu I get this on a
screen with an auto-follow mouse (GShell & MVC, so far), but have also gotten it

on a 'normal' graphics window.  And *once* I got it on a text window, just
recently!  I had turned off the power to the drives and multipak, but not the
CoCo, had pressed in the power button on the CoCo, and realized I wanted to make

sure nothing important was on the RAM drive!  So I did a dir on the RAM drive
and listed a couple of files, and that's when I got it on the text ed  window.
I also noticed the TR light (Terminal Ready) on my modem blinking on & off!
(With power off to the Multipak & Deluxe RS232 pak!)

3 refers to the garbage I get when CLEAR-ing from one window to the next.  I get

a brief view of a screen-full of (colored blocks on a text window, garbage on a
graphics window) before I see the next window, when Clear-ing.

                    Eddie

-*-

30258 20-JUN 00:19 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30256)
     From: EDDIEKUNS    To: CBJ

Yeah -- that's pretty much the attitude I've taken -- Nothing is crashing, so
I'll just let it be for now.

                   Eddie

-*-

30263 20-JUN 02:20 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30243)
     From: POLTERGEIST  To: EDDIEKUNS

     What are the graphics problems that you're having?

-*-

30268 20-JUN 20:50 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30258)
     From: CBJ          To: EDDIEKUNS

Boy would it be neat if we could capture that screen and do a dump to color
printer.  Really interesting graphics.  I notice that I get this flash of
"garbage" when AUTOTERM goes from the normal 32 column screen to a 40 column
screen or an 80 column screen.  still it is nice to know I'm not the only one
this is happening to. ---Carl---

-*-

30279 21-JUN 01:36 General Information
     RE: Disto 1 meg upgrade (Re: Msg 30263)
     From: EDDIEKUNS    To: POLTERGEIST

Read 30257, where I documented my current (remaining) problems.  Nothing
crashes, so I've temporarily given up.

             Eddie

-*-

End of Thread.

-*-

30222 18-JUN 03:05 Utilities
     RE: UNPACK (Re: Msg 30179)
     From: XLIONX       To: CONDUCTOR

Microware would probably consider such a program TABOO. I have NEVER heard of a
utility that would do this. De-compiling a two-pass ICODE file would be a pretty

neat trick as basic09 strips a BUNCH of stuff out when you PACK a file.

-XLIONX (DELPHI)


-*-

30230 18-JUN 21:02 Utilities
     RE: UNPACK (Re: Msg 30222)
     From: CONDUCTOR    To: XLIONX

Thanks for the input.

-*-

End of Thread.

-*-

30224 18-JUN 20:18 General Information
     WHERE TO FIND PROGRAMS
     From: MBB63        To: ALL

I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIRECTIONS ON HOW TO INSTALL.
ALSO DIRECTIONS ON HOW TO USE THE AR PROGRAM. WHERE DO I FIND THESE ON OS9
ONLINE. STILL A LONG WAY TO GO ON BEING COMFORTABLE USING DELPHI AND OS9 MARIE
BOUDET

-*-

30236 18-JUN 23:29 General Information
     RE: WHERE TO FIND PROGRAMS (Re: Msg 30224)
     From: ZACKSESSIONS To: MBB63 (NR)

For more specific help, we need to know which term program you will be using to
do the download with.

Once you get ar, you need to move it to your CMDS cirectory, set it's execution
attribute,

OS9: attr /dd/cmds/ar e pe

The to de-arc an archive do something like:

OS9: ar -x /dd/download/shellplus.ar

That will dearchive the archive putting all the file in the archive in your
current data directory.

Zack

-*-

End of Thread.

-*-

30225 18-JUN 20:19 Applications
     RE: OS9 Development System (Re: Msg 30188)
     From: RADARBUZZ    To: TJSEAGROVE

Tom,

    Yea, I had already thought of that.  I ran across the COCOPro ad in
Rainbowand called the BBS #.  No cigar.  Still looking though!  Got to be one
some- where.

-Jeff


-*-

30241 19-JUN 00:06 Applications
     RE: OS9 Development System (Re: Msg 30184)
     From: CBJ          To: RADARBUZZ

Jeff,
     I don't know if it's for real but Computer Plus is advertising that package

at $89.95 in the June and July issues of Rainbow.  I just noticed it myself and
am going to see if they really have it. ---Carl---

-*-

30290 22-JUN 00:52 Applications
     RE: OS9 Development System (Re: Msg 30184)
     From: BACKFIRE     To: ALL

I found the last copy at the Port Orchard, WA Radio Shack...after checking all
over the Puget Sound area...keep trying though, the tools are nice. Selling the
pkg at 19.95 without advertising the change is just Tandy's way of saying
goodbye to us...

-*-

30299 22-JUN 22:23 Applications
     RE: OS9 Development System (Re: Msg 30290)
     From: RAGTIMER     To: BACKFIRE

One way that might help is to go to a RadShack Computer Center -- I mean a full
one not affiliated with a regular Shack store. I know they carry supplies for
old printers and such stuff, under a COMPLETELY DIFFERENT set of catalog
numbers.

So try them before hunting down someone who'll let you borrow their Developer's
System. Also, by now most of the really good stuff in there is available PD (
like Tim Koonce's MAKE will soon be) or can be scrounged from Level 1.

-*-

30312 23-JUN 01:50 Applications
     RE: OS9 Development System (Re: Msg 30299)
     From: BACKFIRE     To: RAGTIMER

I tried that approach...had one of the salesman at the Computer Center in Tacoma

looking all over for C, Pascal and The Dev Pkg.  Then I swapped my copy of Logo
for C (our local club Pres had never used it.   ), and he told me about the dev
pkg.  Now (after about a 10 year wait) I can learn to use C. I had patched my
Level 1 package already...but it's been about the past year that I7ve really
started using OS-9. ((I still have problems...gport now tells me that my printer

and /t2 are not SCF devices!!...but the descriptors and drivers seem to be
correc t)

-*-

End of Thread.

-*-

30226 18-JUN 20:20 General Information
     RE: DupFile & DCheck (Re: Msg 30194)
     From: RADARBUZZ    To: BRIANWHITE

Brian,

    What do *I* think? <grin>.  Well, I've always thought that the copy
commandshould have been written to recognize whether or not you were copying a
file tothe same device.  If so, it should simply dupe the file by increasing
that old link count.  If not, then really write out another copy to the
different device.

    As for a move command, this is how I think that should work:  If you're
moving on the same device then just change the directory pointer thingy.  If
you're moving to another device, then write a copy and delete the original.

    Now that I got all that out of my system, here is what I think regarding
Dupfile:  Make it capable of all the above.  And, (I may be asking for too
muchhere) incorperate the features presently available in the revised COPY
command from KLINDSAY here in the utilities database (Shell+ wildcards, auto
rewrite (-r), copy(or Move!) to directory (-w=), ect...).

    Now that would be something!  Do you think it would be too great an under-
taking, or not?  I won't hold my breath, but I hope my thoughts are feasable,

-Jeff




-*-

30232 18-JUN 23:06 General Information
     RE: DupFile & DCheck (Re: Msg 30226)
     From: GREGL        To: RADARBUZZ

Jeff,

    I disagree, at least partially. The copy command should create a new
directory entry, create a new file descriptor, and physically copy the contents
of the file. If that were not the case then you would be forced to copy the file

to a different device to create a backup file that wouldn't be altered when you
alter the original.
    However, I agree that the copy command should at least have an option to
duplicate the file using the same file descriptor - that is, by creating only a
new directory entry that points to the existing file descriptor and increments
the link count. It should also accept wildcards and prompt to overwrite existing

files. I think your other comments are right on the money.

    -- Greg

-*-

30342 24-JUN 02:51 General Information
     RE: DupFile & DCheck (Re: Msg 30226)
     From: BRIANWHITE   To: RADARBUZZ

Jeff,

Those are much the same things I had planned.  You forgot to mention the ability

to put plus signs between filenames to merge them together as they are copied...

Oh, I wish I didn't have to go to work...

                                                           Brian

-*-

End of Thread.

-*-

30227 18-JUN 20:22 General Information
     WHERE DO I FIND PROGRAMS
     From: MBB63        To: ALL

I WOULD LIKE TO DOWNLOAD SHELL+, LABEL COMMAND, DIREC HOW TO INSTALL. ALSO
DIRECTIONS FOR USING AR PROGRAM. MARIE BOUDET

-*-

End of Thread.

-*-

30244 19-JUN 02:16 General Information
     RE: failing MPI (Re: Msg 30182)
     From: KNOT1        To: TEDJAEGER

This might be unlikely, but could your CoCo have a "compatibility" probnem with
the new MPI's?  Seeing as each CoCo seems to have its own personality, maybe
trying it with a different one might produce some results.  Otherwise, I suspect

that you may need to find someone who has successfully hooked up a RS HD with
the newer MPI.

I hope you get it working!

                          -Jamie (KNOT1)-

-*-

30363 25-JUN 01:16 General Information
     RE: failing MPI (Re: Msg 30167)
     From: DALEP        To: TEDJAEGER

Ted,

You've got me stumped here!  Try a quick mail note to KDarling.  He may be able
to help you.

Dale


-*-

30374 25-JUN 19:30 General Information
     RE: failing MPI (Re: Msg 30363)
     From: TEDJAEGER    To: DALEP

Thanks, Dale. I think it was the HD instead of the MPI. The old (7 years) Tandy
15 meg HD died three days ago. Kept getting harder and harder to spin up to
speed and finally would not spin at all! It lived a good life! --Bests,
TedJaeger

-*-

30406 26-JUN 21:23 General Information
     RE: failing MPI (Re: Msg 30374)
     From: 6809ER       To: TEDJAEGER

   If you are looking for a replacement Tandy 15 Meg hard drive, I have one that

was only used for a year and many years left in it.

   Let me know (use Email) if we can make a deal.

   Steve , 6809ER

-*-

30434 29-JUN 02:27 General Information
     RE: failing MPI (Re: Msg 30374)
     From: DALEP        To: TEDJAEGER

Ted,

Sorry to hear about your hard drive.  Hope you are able to find another one at a

decent price.  The scuzzi drives are nice.

Best Regards,

Dale

-*-

30454 30-JUN 22:47 General Information
     RE: failing MPI (Re: Msg 30434)
     From: TEDJAEGER    To: DALEP

Well, thanks Dale. About two days after I think my HD died my power supply died.

I am wondering now if my HD is still OK and failed to spin up because it was not

getting the right amps. I'll find out when a replacement power supply gets here.

I just got the new gfx2. Thanks for the info and help you have provided in
getting to us. Bests, TedJaeger

-*-

30621 9-JUL 01:47  General Information
     RE: failing MPI (Re: Msg 30454)
     From: DALEP        To: TEDJAEGER (NR)

Ted,

Good luck with your hard drive.  Hope it works out ok.  More than likely the
data on the disk should be ok.  Certainly hope so.  Did you have the data backed

up? CUL.  Dale

-*-

End of Thread.

-*-

30245 19-JUN 02:18 General Information
     RE: CHD Patch (Re: Msg 30196)
     From: KNOT1        To: BRIANWHITE

Well, I was/am hoping to hookup a terminal (my CoCo 2) to my CoCo 3.  I have my
CoCo down in my basement, and it would be nice to have a terminal upstairs were
other family members could easily access it, and it would also be a convenience
for me.  In this vein, I setiup an /H0/USR directory.  Then, like the Zenix
system I use at work, I removed public write permisions from just about
everything.  When I tested it, I had problems with both the "login" and Shell's
"chd".  That's why I decided to try to fix it.  I looked for the $103F86 pattern

for I$Chgdir, and then for any nearby "lda #"'s.  Wasn't too hard to fix after
that.

                           -Jamie (KNOT1)-

-*-

30246 19-JUN 04:13 Graphics & Music
     RE: Clipboard (Re: Msg 30193)
     From: MIKEHAALAND  To: BRIANWHITE

Sure!  If you're going to use a specific CB buffer for B&W data just make sure
post what buffer it is.  But I do have a Q.  Is the stuff you are planning to
Clip specific to B&Ws  ONLY!  If so you don't really need to use the CB group.
Just use your prcess ID number for the group and use any buffer number within
that group.  Unless the data is useable to another program you don't really need

to worry about using the ClipBoard.  Know what I mean?

Mike

-*-

30247 19-JUN 18:50 Programmers Den
     IBM keyboard.
     From: NES          To: ALL

Any body have the pin out of an IBM keyboard connector, I would like to add an
IBM keyboard to my coco without paying $200 dollars for the one that's in rain
bow...  I know the the keyboard send's its data serially.. any help out there?/
-Eric

-*-

30265 20-JUN 07:24 Programmers Den
     RE: IBM keyboard. (Re: Msg 30247)
     From: DONTHRASH    To: NES

Eric,
     In  the May 1983 issue of Byte there is an  article that will tell you just

about all you want to know about the  IBM  keyboards. I found the magazine in
one of  the local  college  libraries. If you have trouble  locating this  issue

drop me a note and I will make copies of  my copies  and  send them to you. Let
me know how you  make out  with your project. I have been trying to find  time
to  work  on  a similar project. Time is  tight  in  the summer.

               Hope this helps,
               Don Thrash

-*-

End of Thread.

-*-

30250 19-JUN 21:48 General Information
     MM/1
     From: COLINMCKAY   To: PKW

Greetings!

I sent this message originally in mail, but I guess it didn't make it...
Hope you enjoyed your belated honeymoon.

Our local club just had its meeting tonight (Thursday), and there was much
excitement (Wonder why?) Anyway, there were also a few questions...

1. I called to put down $150 the other day using my credit card. Does the
$50 discount still apply? If not, I will send a cheque.

2. It is possible to join two graphics chips and generate pictures of
720*540*256, which is officially supported by Signetics. Is this supported?

3. Also saw the specs for the FHL machine, and mild interest was expressed
in the AT keyboard. Any future plans on the MM/1?

4. What is the option for non-CM8/Magnavox monitors? Is this supported on
the main board? Will it use stock VGA-type monitors, or does it require
multisync?

5. WRT the optional IO board. How much? And when?

6. Without the optional IO board, how do you add a hard drive?

7. One member heard the word midi, and his eyes lit up. He wants to know
exactly what is involved in configuring the DB25 for midi, and how easy
it is to switch back to normal (switch?)

8. What is the planned cost of the palette controller?

9. One of your info sheets mentioned 12.5/15 MHz. Haven't seen the 12.5
before. May we ask why?

10. Once you get the second board, do you have to upgrade the memory
right away? (Beyond 1 Meg.)

11. What games does it come with? Enquiring minds want to know! Saw this
mentioned in your info flyer.

12. Will there be a kit form available for those who want sockets? What is the
expected release date of the kit?

13. Will it be CSA (Canadian Standards Association), the equivalent of
UL/FCC up here, approved? Since we don't have to wait for FCC certification
up here, any chance of getting one NOW? (RIGHT NOW) (Big GRIN!)

14. What size is the power supply?

15. Is the software set up for a Logitech or a Microsoft type mouse?. Any
recommentation either way?


Thanks for your time.

Colin McKay
Ottawa-Carleton OS9 Users Group


-*-

30282 21-JUN 20:24 General Information
     RE: MM/1 (Re: Msg 30250)
     From: NES          To: COLINMCKAY

Colin, The system will support the a stander serial mouse, most chip's are
surface mount and there are not sockets made for those, The CPU and a couple of
majore chip's are in sockets, except the Graphics processer which on socket is
avaible for it. As for the Midi port, You choose when you order weather you
wount an RS-232 or MIDI port (in and out and thru). they made the system 15Mhz
instade of 15/12.5Mhz.  There is know expantion slots, Just an main board and
the Optional IO board. main board has the CPU,Graphics controller, two serial
(One can be an MIDI) ports and 1meg of ram, keyboard interface, disk controler.
BTW the system is very low power so requres just a small power supply. the
Second board has the SCSI interface, 3 more RS-232 port(one for mouse), Ram
upgrade max 9 megs, two paralell ports, stereo port sample and play back. Main
board... about 749.00  second board $399, if you buy both $1000. about.  I think

the system has everything the average user would need, software that is comming
out is an BBS package that supports FIDO NET mail transfer, MV canvase, Video
digitizer.. also when you buy the MM1 you get.... OSK DOS(os9), C and Basic00,
a com program, text editor , graphics editor, and some other goodys. -ERIC


-*-

30308 23-JUN 00:44 General Information
     RE: MM/1 (Re: Msg 30250)
     From: PKW          To: COLINMCKAY

Clin,

Thanks for all the good questions!

Let's take them one at a time. SOme may require no comment.

1) Your $50 discount does apply. 2) It is not trivial to gang two VSCs together.

THis is done in the CD-I machines and is quite impressive to see. However, keep
in mind that we do have 320 x 400 in 256 colors, and that is also quite
impressive. Also keep in mind that we are not making a killing of the MM/1 at
the $779 price, and adding the second VSC would take the MM/1 out of the reach
of thousands of CoCo users.

3) The added convenience of the AT keyboard is a nice feature, but can easily be

accomodated with CTRL-0 or Caps Lock as needed.

4) Concerning non CM-8 monitors -- there is a simple approach we implemented to
let you use a wide variety of monitors. Call for details.

  202 232 4246

5) /send 5) IO Board is $345 when bought with the base system, $399 without. 6)
You must have the I/O board for hard drive use, but frankly, two HD floppies at
3 ms will keep you going for quite a while.

7) It is easy to change from MIDI to DB25. Call for details.

8) Call.

9) 12.5 MHz is out. We re 15 Mz only now. At one time, we considered a 12.5 MHz
machine at a lower cost, but decided to keep the cost down and just standardize
on 15 MHz.

10) No.

11) Games?  Call.

12) Kit is available, although the current one has most chips on it, and already

socketed.

13) Call.

14) 200 watt.

15) Any powered mouse will do.

Thanks, COlin!

-*-

30313 23-JUN 01:51 General Information
     RE: MM/1 (Re: Msg 30308)
     From: KSCALES      To: PKW

Paul -

Well, now that I've gone and put my deposit down on a MM/1, I guess I'm
probably going to spend the next two months or so just thinking and
planning... and asking questions.  If I get to be too much of a nuisance,
remember that FCC approval doesn't carry all that much weight up here in
Canada, and having one would probably keep me too pre-occupied to bother
you with more questions <wicked grin>.

Anyways, Colin McKay has already put forward the questions that came up at
our last UG meeting, and we are watching for your reply.  A few more
questions have come to mind since:

- Will you be providing full technical documentation, either as part of the
  standard package, or as a special order item?  (schematics, bus interface
  info, tech specs on the "special" chips, etc.)

- Will you be providing full Microware documentation?

- Monitor interface: yes, CM-8 compatible.  But MY CM-8 compatible seems to
  be on its last legs (and new folks coming onboard will probably find
  CM-8s/8CM515s somewhat hard to come by).  A VGA-type would make more
  sense nowadays.  Sooo... will VGA connection be supported (easily)?
  Would we be best to look for multi-sync for now or future?

- Will the I/O board be available for shipping with the initial production
  run?

- No audio without I/O board?

- What is the hook-up arrangement for the audio ports?  (Standard audio/RCA
  jacks?)

- If I press CTRL-ALT-RESET on the MM1/1, whose mugs do I see?

More to come, probably...

Cheers...
Ken Scales
(the other) Co-President
Ottawa-Carleton OS9 Users' Group


-*-

30332 23-JUN 22:48 68K-OS9
     RE: MM/1 (Re: Msg 30313)
     From: DWHILL       To: ALL

Speaking of documentation, has there been any electronics press coverage of the
68070 and its related graphics chips from Phillips, or CD-I in general? I've
been cut off from my usual sources since I was laid off in March and have a
feeling I've been missing a lot of news.  Does Phillips provide any information
through its distributors?

--Damon

-*-

30334 24-JUN 01:25 68K-OS9
     Compact Disk Interactive (Re: Msg 30332)
     From: OS9UGPRES    To: DWHILL

CD-I has been covered lately. Motorola announced support for it with some new,
very powerful chips intended to be used in players worldwide. More info is
expected in September after the meeting of an international standards group on
video compression methods.

-*-

30410 27-JUN 00:00 General Information
     RE: MM/1 (Re: Msg 30313)
     From: PKW          To: KSCALES

Ken,

All non-proprietary tech docs will be available. Not all will be shipped, but to

tell the truth, we have only planned the user manuals at this point.

Full tech docs, in the tradition of most computers, will be available separately

at relatively low cost.

Some tech docs will SURELY be included.

Sound IS available on the main board -- a la IBM sound.

I/O board WILL be available at the same time as the CPU board.

Best to get a color multisync if your CM-8 is on the way out. Cables should be
availbe in the fall from us, but of course you are free to make your own.
Sufficient tech information will be made availalbe to allow you to do this.

Thx for the questions!

Paul

-*-

End of Thread.

-*-

30251 19-JUN 22:06 General Information
     RE: The T.O.P.S User Group (Re: Msg 30034)
     From: TJMARTIN     To: KEITHMARCH

Yup, my submission did not seem to make it. dunno why. Maybe it was felt to be
TOPS property or something. I will try to leave mail for data base manager, see
what happened. The index is surely intended for distribution. TOPS stuff is
meant for such public distribution apparently.

-*-

30262 20-JUN 01:56 General Information
     RE: The T.O.P.S User Group (Re: Msg 30251)
     From: TIMKOONCE    To: TJMARTIN

Your TOPS submission is already in the database, in the "New Stuff" area.  We
have it set up now so that all new uploads go into "New Stuff" for about a month

before they get moved to other areas.
                        - Tim Koonce

-*-

End of Thread.

-*-

30253 19-JUN 22:37 Graphics & Music
     Picture Window } V1.0
     From: LL           To: ALL

Hi everybody!
   I am very happy to inform you that Picture Window Version 1.0 is now ready,
and available for $7.00 from SEESOF, 1973 Fairgrounds Rd., Burton, SC 29902.
   This version includes a universal picture printing feature that should work
with most dot matrix printers.
   The program requires Multi-Vue, hires mouse and 512K CoCo 3. It is a window
picture drawing program that makes & edits & prints VEF bit image pictures.
   PicWin09 is available in the database for a trial copy of all features except

printing.

   LL

-*-

30255 20-JUN 00:04 Utilities
     RE: New Dir (Re: Msg 30111)
     From: SCG          To: KLINDSAY

Yes I do use your COPY also VERY VERY NICE. Its Great to have guys like you,
helping us all out and bettering our systems THANKS!!!

Steve Gilbert * Os9 Sysop * ***PC  BBS*** *516-795-5874


-*-

30264 20-JUN 02:35 General Information
     Hello!
     From: TIMKIENTZLE  To: ALL

When my girlfriend and I decided to get married, we had a hard time deciding
what to do about our last names.  Although the "modern" solution to this problem

seems to be for each spouse to keep their unmarried name, we felt that having a
single "family name" was very important.  So, we have decided to both take a new

last name, effective August 4, the date we will be married.
   So, as of August 4, I will be using the Delphi Username TIMKIENTZLE, rather
than my old Delphi Username TIMKOONCE.  EMail will still get to me if addressed
to either Username, though I may occasionally miss forum messages addressed to
my old username.  Between now and then, I will be logging on under both names.
                                - Tim Koonce  (soon to be Tim Kientzle)

-*-

30266 20-JUN 18:15 General Information
     RE: Hello! (Re: Msg 30264)
     From: ZACKSESSIONS To: TIMKIENTZLE

Congratulations, Tim! And Best Wishes to the Bride-to-Be! Interesting that you
two decided to go with an entirely DIFFERENT last name for both of you. Never
heard of doing that. Umm, would it be too personal of a question to ask just why

y'all picked KIENTZLE?

Zack

-*-

30272 21-JUN 01:06 General Information
     RE: Hello! (Re: Msg 30266)
     From: TIMKOONCE    To: ZACKSESSIONS

Yes, it does seem a novel solution, I suppose, but it was the only one that
really worked for us.  After we decided this, we did meet another couple who had

done the same thing, so it is doable!  <grin>
   Kientzle is actually one of the many mis-spellings (Koonce being another,
BTW)  of the name of my ancestor who came to the New World from Switzerland
(Yes, back then it was still the "New World". :-)  We were hoping to find a more

"neutral" name, but couldn't find another one we both liked.
        - Tim (who is never really sure these days what name to use)

-*-

30273 21-JUN 01:08 General Information
     RE: Hello! (Re: Msg 30272)
     From: ZACKSESSIONS To: TIMKOONCE

When I was inthe Navy, I served with a shipmate who's last name was Koontz. Very

similar, but a very distinct difference in pronounciation.

Wow, you can trace you ancestry that far back? Impressive!

Any chance you'll be making it to the fall "October Fest"?

Zack

-*-

30283 21-JUN 20:38 General Information
     RE: Hello! (Re: Msg 30264)
     From: NES          To: TIMKIENTZLE

Tim, sound's yuppy to me, Guess I am old fashion,  I know alot of people keep
there (women) last name for professional reasons, but this is a first make up a
new name using both last names...  How do you say "Kientzle". I wish you and
your new bride well, Just remember the first year is a killer. -Eric Stringer or

mix with the wife Eric Stralonka....


-*-

End of Thread.

-*-

30269 20-JUN 21:18 General Information
     RE: ST-125 Seagate? (Re: Msg 30190)
     From: JANG         To: ZACKSESSIONS


I DON'T HAVE A SEAGATE AS MY /H0. IT'S A CMI 5412 AND I DON'T SEE ANYTHING
CONSPICUIOUS THERE. IT'S PART OF A SYSTEM I GOT FROM THE GUY AT ARIZONA SMALL",
DOES ANYONE KNOW WGERE THE TERMINATING RESISTOR IS. ACTUALLY I WILL BE GETTING
THE MANUAL SOON FOR MY NEW ST-125 AND IT WILL TELL ME WHERE IT'S T.R. IS SO I
MAY JUST ATTEMPT TO MAKE IT SVEW ^eHR$A9"UL jUjHRT%"u$iErr%j$(Je]?PV It ANYONE ELSE KNOWS WHAT TO LOOK FOR I SURE COULD USE SOME HELP. THANK
YOU SO MUCH ZACK FOR YOUR INTEREST.. JERRY ANGUS


-*-

30295 22-JUN 01:55 General Information
     RE: ST-125 Seagate? (Re: Msg 30269)
     From: DAMIONGREY   To: JANG

RE: Term resistor : I don't know if this helps any, but the term. resistor
 is usually blue, beige or yellow (in my experience) and looks either like
 a normal dip chip, or like just one side of a dip chip (a sip, actually) HD's
it's usually the latter. on my
 old Tandon 15 meg it was, so even your old CMI should be that way.  It's
 usually near the jumpers, but not always.  Personally, I would make the
 20Meg h0 if I were you, not just to avoid the problems, but also to make
 things more usuable.  Hope this helps. - Greg

-*-

30323 23-JUN 14:09 General Information
     RE: ST-125 Seagate? (Re: Msg 30295)
     From: JANG         To: DAMIONGREY

Yes, thank-you so much.. It was a okhre(dark-yellow-thing), righ next to the
jumper-(6-element)unit.. As it turns out, with my WD1002-SHD controller I would
have needed another Hard-Drive EXACTIALLY the same to get it to work OK ..so I
have resigned myself to the conclusion that i will just transfer everything over

to the new 20 Megger (via-floppies) and put the old CMI-Dianasour on the shelf
as a backup if-need-be, I got the new ST-125 formated(finally) late-last night
and it seems fi ne.. Thanks To* Zack Sessions, Steve Gilbert, The people at CRC
and ole-good buddy Roger Krupski (RGB-DOS)... Thanks to all for your concernn.
Jerry Angus..Pres. Island CoCo Club BBS 516-795-7422


-*-

30324 23-JUN 14:17 General Information
     RE: ST-125 Seagate? (Re: Msg 30190)
     From: JANG         To: ZACKSESSIONS

Yes, I found it finally..Zack.. Thanks again for your help.. I got the new drive

formated and will end-up using it by itself so thr Terminating resistor will
stay in there.. It'll be a chore transfering about 9 Megs of data of

XX over to it but some "House-cleaning" was due anyway... thanks a lot for your
help.... Later....... J.Angus (JANG)


-*-

End of Thread.

-*-

30271 20-JUN 23:46 General Information
     1 meg upgrade kit
     From: POLTERGEIST  To: DISTO

     Tony,
     What's the purpose for shorting a resistor with the 1 meg upgrade kit? Is
this related to the timing bug with some GIME chips?

-*-

30349 24-JUN 08:36 General Information
     RE: 1 meg upgrade kit (Re: Msg 30271)
     From: DISTO        To: POLTERGEIST

Yes, it has to do something with the RAS timming on the RAM chips. It seems that

there are different versions of the GIME chip, and that some people require
another resistor rather than a short. -Tony

-*-

End of Thread.

-*-

30275 21-JUN 01:23 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29983)
     From: PAULSENIURA  To: TIMKOONCE


  -> BTW, you don't need SBF to drive a tape, you can just write an SCF
  -> driver. Tell us what you know, and maybe people on here can help
  -> you with that tape drive.

I can't possibly type the entire subset of QIC docs I have received from Freeman

Associates, but they will gladly send anyone copies of the various QIC standards

to anyone wanting them, without cost (they've even faxed me a couple of pages on

their nickel).  ANSI has adopted quite a lot of these specs.

I think I left these docs at the office (where they'd be most useless, of
course, wouldn't ya know it?!).  I will post Freeman Assoc.'s phone number and
address once I get those docs back home.

But right now I can tell you writing a driver with SCF will be impossible.  QIC
implies "smart drives" as I told Eddie Kunse tonight already.  The I/O is done
in "block" fashion not "single character" fashion.  The "QIC Common Command Set"

applies to any such smart drive, whether they use the floppy-drive pin layout or

the SCSI layout, etc.  If you have, for example, a QIC drive that is designed to

hook up to a SCSI interface, you still must send to the drive the "commands"
along those SCSI signal lines.

It is hard to explain without the docs.  For the floppy-drive QIC-40 standard,
you will send the drive some commands along the "head step" signal line.  No,
the "head step" is *not* used to have the tape drive step forwards or backwards
to the next track on the tape.  The commands are bit-streamed in any of the
normal head-stepping set timing standards along this "head step" signal line in
a SERIAL fashion.  The QIC folks barely describe how a WD1793 could be
programmed to do this -- I mean "barely".  Without a "smart controller", our OS9

driver will need to lock out IRQs while all this is going on.  Not only do you
send commands to the drive utilizing serial bit streams along a normal floppy
signal lines, you also get Status messages from these smart drives from other
floppy signal lines in that same serialized fashion.  IRQs must be locked out to

read these signals, as the old CoCo bit-banger port is programmed to do! But you

must do this thru a WD17x3 chip, not an ACIA chip, since QIC-40 is designed for
normal floppy controller signal lines.  Another QIC-xxx standard will describe
how SCSI controller signals are used for the very same kind of I/O to a smart
drive.

It's better to do QIC thru a controller card that can allow DMA access to these
drives.  Such is what IBM PC floppy cards can do!  You'd think the Disto and
Performance Peripherals "no-halt" controllers could do this, *especially* Isted
/FHL's "Eliminator" and B&B's "CoCoXT" board, since these do use IBM-PC
controller cards.  Well, no one has come up with QIC drivers for any of these
cards.  I did see a blurb in Microware's Source book on some companies
supporting QIC (not QIC-40 tho), but it looks like we're not going to get to use

real tape drives with any OS9 system we can afford, despite the low cost of
these drives, because no one wants to invent these critters.

As I said, I'll try to find the QIC docs I do have, and let y'all call Freeman
Assoc. to ask for the ones you want to start with.  The "QIC Common Command Set"

is required for any other document, and you'll most likely order several of
these docs to get a complete set for just one interface.  Remember, ANSI has
adopted quite a lot of these items as real standards for tape drives and
software drivers to use.  Normal floppy controllers are all that's required,
from what I have been able to gather, such as the WD17x3 chip sets.  The
Colorado Memory Systems (CMS) company who makes the tape drives JameCo is
selling, is doubtful a good source of information, even tho they have heard of
OS9 and were extatic to hear we were trying to write a driver.

Wait until I can post the whole set of QIC docs available, then I can recommend
which ones to get in order to start learning more about the coming age of Smart
Drives.

-- Thx, Paul Seniura.


-*-

30280 21-JUN 01:43 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 29948)
     From: PAULSENIURA  To: EDDIEKUNS

Pardon me for getting back on Delphi so infrequently .. "things" have not been
very nice during this span of time for me, personally ...


  -> One reason that you don't see a whole bunch of software out there for
  -> the CoCo 3 & OS-9 is that it takes TIME!  It takes time to 1) Become
  -> familiar with OS-9 2) Become familiar with OS-9 guts  3) Write and debug
  -> your program.

I don't mean to disagree, nor to argue, and I do understand that it takes time.
How long must it take, though????  OS-9 has been around for such a long time I'm

not able to put an accurate figure on it myself), but OS-9 is OS-9 (supposedly)
especially if you're writing things in 'C' or Basic09 or PASCAL.

I didn't mean to be specifically talking about the CoCo3 (or even CoCo1/2 Level
1 for that matter).  But since we brought that up, I personally have had the
CoCo3 for 3 years.  I have had a 64k CoCo1 for (good grief) 8 years, sold it to
a friend, got it back now for repairs(!).  So take the Level 1 or Level 2 as a
reference, then add on the year or so Tandy gave to developers before the CoCo3
itself was shipped to the stores.  We're talking 4 years minimum we've been
waiting for things to come out.  And now the word is Tandy is dropping the whole

ball of wax.  Short life span, eh?

I get the idea my "gripes" might be misleading: they were not directed at any
one machine (e.g. the CoCo3) or any certain people/companies.  I did include the

idea that no matter what the CoCo market moves to -- it could be a Cray/OS9 port

for all I care -- if the users can't have easy-to-operate interfaces (MultiVue
was a 'start'), popular software available (where's WordPerfect/OS9, did ya know

they were suppose to have a Unix version coming?), and hardware to use (remember

my mentioning the QIC tape drives?), the OS9 market is *not* going to be very
popular at all with the home/office environment.  It'll necessarily stay in the
industrial applications.

And frankly I'm worried about that particular point.  At least KLE "plans" on a
bunch of support, but FHL is the only company "visible" where I can "see" it and

get those cards/interfaces "right now" if I need them.  They should have been
developed a long time ago (uh where was Tandy to give 'em to us on the CoCo? why

did we have to rely on B&B and Disto et al.?), so that those interfaces could
have been involved with the various QIC/ANSI and IBM decision-making teams (yes
ANSI has accepted quite a lot of the QIC tech specs as de-facto standards,
including QIC-40; I *have* their official docs in hand!).


Now let's move to the Atari/OS9 front: Microware *told* me themselves over the
phone (I called Des Moines) that there is NO WINDOWs for the Atari OSK system.
Not even InVisions; it never saw the light of day.  Oh they mentioned some
company in their "Source" book I could call to see what their window system is
like.  I know Kevin Darling had a rudimentary windows version, but still there
is no "official" supported installable subsystem for Atari/OS9 windows.

As a matter of fact, Microware couldn't recommend any other Atari port, Amiga
port, OSK in general *including* KLE & FHL new products or old, that had true
windows.  I asked Microware point blank: "You mean Tandy was the only one who
got windows going for any OS9 system, any flavor?" and Microware said "Yes".

Now someone better tell me what in blue-blazes is going on, where do you-all
expect the CoCo market to go, if we can't have true windows at the o.s. level?
*THIS* is the kind of stuff I'm talking about -- a simple item gets DROPPED and
I start WORRYING all over the place where we're headed.  My lord ... even IBM
has FINALLY accepted that Windows AND Multitasking is the way of the future home

& office workstations.  Good grief -- did you hear what I'm saying?  IBM *
finally* got that through their thick skulls, and probably after they heard me
gripe at a number of local S.E.s (IBM System Engineers) about how our CoCo/OS9
can run rings around their MesSy-DOS system, for SEVERAL YEARS!

Now that you know what IBM knows, someone needs to heed the warnings I've typed
about in this and previous messages.  OS9 isn't going to be popular with home &
office computers if someone doesn't get "RAVE" and other packages GOING *AND*
SELLING to the users of the various flavors of OS9/OSK, as well as MOTIVATE the
DEVELOPERS TO USE RAVE!!!!  Savy, KLE and FHL?  Do NOT invent your own graphics
subsystem -- use the official Microware one, or the OS9 market is going to be
split across a lot of different kinds of graphics SUBsystems underneath your
flavors of OS9.  This also goes for Atari ports and Amiga (Australia) and
everyone else.

If this "hurts" the existing CoCo graphics so-called standard, I'm playing the
world's smallest violin right now.  Your source code should be written in such
a way that would permit you to change to a different set of protocols if need-
be.  Most of you game programmers don't even use OS9 as a base to begin with --
those of you who DO use OS9 as a base, you use the old VDG graphics wherein you
"peek & poke" your own stuff to the video buffer (reading this, UME fans?).  I
can see why: for speed mainly, but also because you're porting your IBM, Apple,
Atari, or Commodore source code, that does the same thing, to OS9. Cheapest way
out for you, since Tandy dictated you write your games for OS9 if you want Tandy

to sell 'em.  I can see all that.  Nonetheless, your source code *should* be
portable to "RAVE" that ought to provide a similar environment for
peeking/poking (does it?) if the application absolutely must have it that way.

Better start thinking NOW about adopting "RAVE" as the standard, or everyone
start agreeing on another standard.  It's probably already too late, huh!? Going

to hafta stick with the CoCo window standards, maybe enhance them a little, eh?

Did any of you know that ANSI has produced the "Meta-Graphics" instructions?
They have expanded those video controls to the point that graphics commands can
be sent via escape-code sequences.  Makes ya wonder where they got that idea. :-

)  Anyway, the POINT HERE is that ANSI *HAS* officially endorsed what WILL BE
the protocol to use across wires & transmission lines to draw things
graphically, no matter what kind of boxes are talking to each other.  And I
understand it also includes the kind of window support we already have under
OS9, including drop-down menus, highlited options via mouse (thru a modem remote

application even!), well it's a whole 'nuther book we'll have to buy in order to

complete the ANSI 3.64 specs.  Remember, these are SPECS, protocols, Standards,
etc., and you can either be compatible with them, or not.  And it should be
implemented at the o.s. level thereby relieving the application code from doing
it on a whim-by-whim note -- that source code for the application could be
PORTED TO OTHER NON-OS9 MACHINES without much rewriting troubles, too!


  -> Standards? KBCom NOW supports the VT100 protocal.  No, I don't support
  -> ANSI, if you want to call that a standard :) but I plan on eventually
  -> adding a versioin of ANSI that seems to be more widely used than others.
  -> (IBM PC ANSI.SYS)

You should not HAVE to support it in your programs: the o.s. should support it
at a driver or pipe/filter level.  That is one point I'll give to IBM/MicroSoft,

in that they made ANSI part of the o.s.  No one's done it *yet* for OS9 the
right way (well I did share my ANSIFILx filter on CIS, the *first* of anything
"doing ANSI" for OS9-L2 windows, and it still is the only one I've seen
[including your KBCom] that can come close to supporting most of the ANSI
commands as such, but the CoCo3 runs out of steam when it comes to hooking my
pgm up to the StdOut of a t.p. & modem running faster than 1200-bps; I know:
"Rewrite it in 'C'"!).  Yep, OS9 needs a system-level ANSI emulator, and no
one's done it yet despite how ANSI is sorta built-into Unix as well (termcap
files & such).

You see, I spent a bunch of time researching the ANSI 3.64 specs: *that* is the
official name for these video controls, the book costs around $25, but I'd
strongly suggest going to your local city or university library and do some
copying.  You'll be amazed -- once you compare 3.64 with VT100, all you will
NEED to support is 3.64 itself cuz you'll AUTOMATICALLY have VT100 that way. You

sure will, *if* you support enough of a subset of commands.  Look at the
OFFICIAL docs, look at some whittled-down docs (a.k.a. IBM PC-DOS Tech guides),
and you'll find out very quickly they ALL DO MATCH, there is NO such thing as
"IBM ANSI" vs. someone else's.  Not if you support ANSI correctly with the
largest subset capable of being handled.

I'm not "proud" of ANSI at all -- it is such a backward control language -- who
ever thought of putting the "command" *AFTER* all the data bytes?!?!?  Sheer
stupidness if you ask me!  But to do it, ya gotta do it their way.  >:-( I
merely mention lots of people have misconceptions about ANSI -- it *is* a
standard, or the big corporations would not have all agreed with each other in
this manner.  It's a crying shame that this has been sooo misunderstood.  I want

to help give peace to these kinds of ideas.


  -> KLE & FHL are at war?  Actually, I find their machines as being aimed
  -> at very different niches.  They may 'fight' to move people from one
  -> niche into another, but the niches are pretty well defined I think.

When they are both after my pocketbook, it's a "war".  Their "niches" both
target would-be CoCo3 owners to upgrade to the 68000 CPU.  I've read both of
their brochures and ads -- I do not see any "well defined" niches as you put it.

:-)


  -> Delphi is a graveyard?  I'm speechless!  It's all I can do to keep up
  -> here!  The OS-9 forum traffic is growing in volume as time goes on.

Yeah, I do see there's lots of dialog.  I didn't make my point very well.  To
illustrate: someone "just" posted PCDOS.AR not very long ago, and yet it's NOT
the newest OR the best-fixed-up.  I can prove it with the way the CC3Disk
patches mismatch from one of the latest versions uploaded to CIS over a year ago

that I pulled down (I haven't had access to CIS since).  (Maybe I can find it
one of these days & post it, too, and have the OS9 Forum Sysop go double-check
for permission from the author since I have no access there myself for now.)

That's just one example of how things are dead on GEnie and Delphi -- there are
more, but PCDOS being back-level is putting our SEA Arc 6.02 port way behind
schedule (i.e. PCDOS.AR is the most important "error" I've seen on the Delphi
uploads so far).  Another way to say how dead things are: compare the amount of
new strictly-OS9 uploads on CIS vs. GEnie and Delphi put together!!


  -> UME & standard MIDI:  I really know very little about this one.  Just
  -> one comment: Give the man time!

If you mean Mike Knudsen, he's had 5 years already according to his own UME
booklets!  :-)  But my point wasn't taken with a larger scope I had in mind,
such as how Lester Hands and a WHOLE BUNCH OF OTHERS had plenty of time, as Mike

has, to do "something" -- *SOMETHING*.  Lester gave up and went on to porting
Lyra to the IBM-PC money-making market.  I've asked plenty of people, "Dr.T" for

one (very popular on the Atari MIDI market), to whom I can directly ask
questions on GEnie, if they'd let some of us OS9ers strike a contract with them
to port their products to OS9 esp. on the CoCo.  All I got was deaf ears.

You see, no one knows what OS9 is, what it's about, who & what runs it.  Good
grief, I had the GEnie MIDI Forum Sysop ask me if "it was public domain" for
crying out loud!  (I *still* have that dialog captured and saved it for future
reference under "Signs of Ignorance"!)  They quickly got the usual run-thru,
stuff like it looks & feels just like Unix, etc., etc., but it's a lot nicer
with the "true real multitasking windows developed by Tandy and Microware". And
*that* concept was ANOTHER bottleneck!

I'm not saying PC programmers are stupid -- Ignorant:yes, due to their
unenlightedness (e.g. not their fault) -- Dumb:no.  Most of 'em, even IBM's, are

kinda sloppy sometimes.  They have no idea how to program efficiently, since now

they can hog all the 2-meg and 4-meg cards you put into a PC.  They have no
concept of multitasking, of how to write SHAREable code (re-entrant and
relocatable at *any* time), until/unless they move on to OS/2[tm-IBM] or some
kind of mainframe.  For the most part is what I'm saying.  I could go on!, but
I won't.  But with everyone involved with PCs pouring in their efforts, just
look at how good MIDI is implemented on PCs.  Now look at how MIDI stands on the

CoCo.  Shameful.  MIDI isn't the only standard I'm talking about, but it clearly

opened my eyes as to where we CoConuts and OS9ers stood in relation to "everyone

else".


  -> I think that about two years back a *LOT* of unrelated and separate
  -> projects startup up (Fido, UUCP, KBCom, OS-9 LII upgrade (?), all the
  -> unZip & deArc programs, ...).  It takes TIME to port things over, and
  -> it takes time to write stuff from scratch.  Esp since most (?) people
  -> who are working on projects like this aren't payed to do it, and thus
  -> must work in their spare time.

When I first approached some CIS OS9 gurus about porting SEA Arc 5.12 over to
OS9, they all said it'd be more-or-less impossible.  It didn't take much time to

decide the fate of having Arc compatibility for OS9.  I didn't want them to do
it, just to help me get started.  That was in 1988.  And it came from the
smartest dudes I still respect.

The problem isn't "Time" -- the problem is "Motiviation".  You motivate people
to develop products with $money$ and the out-right NEED for that product.  The
NEED could not be any greater when it is realized that the market forces us to
go with their own standards.  Fido, for example, will not let us use AR or PAK
or anything else (TC3?!) to compress Mail Packets: it "requires" SEA Arc 5.12 as

a bare minimum.  There couldn't be a NEED any greater than when the standards
dictate what we must use.  Yet in 1988 no one wanted to help us make SEA Arc
available for OS9.  And I uploaded to CIS the huge source code with SEA's
permission to get the ball rolling!  We had the sources, yet no one wanted to
scoot closer and help.  They all backed away.

Yes I'm one of those "unpayed" people -- OS9 is just a hobby with me, remember,
but I'm one of those who are determined to see that OS9 can do things just as
good as the big blue machines do them (oh maybe not as fast, but JUST AS GOOD).

I'm also a system programmer who sees where things are going as a total picture,

and read those trade magazines.  I'm saying lots of "us" volunteers are just
spinning our wheels if we don't get something "real" going -- things that are
"really" needed in other words.  We DO NOT NEED another GIF viewer, unless it's
for the KLE and FHL graphics systems ... I see the STRONG need for lots of
people to get cracking on the tape cartridge backup system.  Right now if not
two years AGO (which would have made it ready for use in B&B's CoCo-XT
interfaces!).

I've named several other needs and requirements in previous messages, one
special-interest need in particular would be for music lovers: the Standard
MIDIFile (SMF) support.  I've been belly-acking to Mike Knudsen about this ever
since the UME thing went commercial.  If he didn't want to support SMFs soon, at

least publish his file/record layouts so "we" can try writing a converter, just
like Lester Hands published his Lyra formats.  Yes I said I've personally asked
Mike to provide us with that info more than a year ago.  I see that he's posted
those docs just about two months ago, almost to the day Delphi opened up my
account!  Coincidence??

I don't mean to pick on Mike -- I'm just saying how programmers go out and do
their own thing without doing any market research (well not "much" anyway) when
they start selling their product.  When I do something, I grab everything I know

and go out to research it.  To learn about MIDI, for example, I *actually*
JOINED the International MIDI Association and ORDERED their OFFICIAL DOCS. What
does everyone else do?  Did Mike join the IMA?  Did Second City Software (Ed
Hathaway) provide him with those same official docs in support of him developing

UME for exclusive sales?  I honestly do not know ... I'm just making a point
here for everyone reading this.  I'm not criticizing Mike and SCS at all ... but

if the answer is "No" to that question, well it's something to start thinking
about, especially if they intend on supporting SMFs, as the official docs *have*

changed (a few points quite drastically) since the version 0.06 docs were shared

amongst the networks.  Any official MIDI docs are *now* copyrighted and *must*
be ordered from the IMA at extremely cheap rates.

Remember, I only bring up UME, MIDI, IMA, etc., only as one example of how
things need to be approached when commercializing your programs.  The research
must be done and then the protocols etc. must be properly supported, or your
product will wither and die because, quite simply, it's not usable with the way
the market *is* set up.  The MIDI market, to continue this example, follows
strict guidelines in most respects of its protocols and implementations.  Quite
a lot of the manufacturers of keyboards add on to those specifications, but none

of them "change" those BASIC specs that MUST be compatible with other machines.
In fact, MIDI is such a wonderfully-agreed-upon standard, EXACTLY how the ANSI
stuff is agreed upon btw, that it's pure magic almost to see all the music
makers working with all that equipment -- I mean the hookups etc. WORKS, as in
hit that button and it DOES something that it is EXPECTED to do!


  -> As *I* see it, the people in the OS-9 community are bending over
  -> BACKWARDS to give away their hard-earned secrets and to give newcomers
  -> all the help and support they need to get off to a running start.

That IS fantastic.  I'm not addressing that issue at all, not even a teeny bit.

The issue is how OS9/OSK is going to support the machines that are out there to
be bought and used.  The issue continues by expanding into what some of these
developers are doing, what they are planning to do, and how they are going to do

it.  I'm talking about COMMERCIAL products, not "shareware" or "freeware" (
although these people need to heed my warnings, too).

MIDI and ANSI are two standards (of MANY) out there to be supported as if it is
hardware to be hooked up to your computer.  The drivers etc. must be "that"
compatible.  And this is only two of the many items awaiting to be used by OS9
users in the right way -- e.g. supported by the o.s. ITSELF (speaking of ANSI),
not by each application's own code & logic *if* the programmer decided to
include it on his own whims.

And then there are REAL hardware items out there to be used: QIC tape drives,
CD-I and CD-ROM, even some 9-track half-inch reel-to-reel tape drives!  A whole
gamut of disk drives up to 600-meg in the space of a 3.5-inch drive!!  Did you
know a company is coming out with a 20-meg FLOPPY the PRECISE SIZE OF A 3.5-inch

FLOPPY????  This drive *will* be able to switch down to 5-meg and 1.44-meg and
720-k compatibility formats.  It sounds like it'd be one of those "Smart" drives

that uses the QIC Common Command Set (yet another official document I have).

OS9 gurus hear this clear: smart drives are coming and some of them are already
here.  You cannot use SCF methods to talk to these drives.  I have some of the
QIC docs, remember; I have read them and I am warning the OS9 market that
they'll be the next big break in storage technology.  I'll bet, based on past
history, that OS9 market/companies won't do much to help us utilize these smart
drives.  I would love to use a 20-meg 3.5-inch floppy, but will *some* company
provide the interfaces and OS9/OSK drivers?

And I'm not even going to start talking about EGA, VGA, Super-VGA, etc.  That
stuff is out there ready to be used under OSK.  Why can't we use those cards
"now" and port "RAVE" to use that hardware?  Why hasn't anyone even thought of
this as a cost-reducing effort, in lieu of developing a graphics system on the
KLE & FHL based on CD-I chips, for example?  These IBM-PC video boards come with

their own memory that does not eat into the 68000's space (or 6809/GIME,
whatever).  Well, no one asked me ... it's too late now, apparently.


I'll keep reading everyone's replies ... let's keep the dialogs (and
controversy) going!  Surely some power players in the OS9 arena will get our
hints and decide to start supporting and implementing these ideas.

-- Thx, Paul Seniura.


-*-

30291 22-JUN 01:35 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30275)
     From: TIMKOONCE    To: PAULSENIURA

Paul,
   The only diff between SBF and SCF is that SBF gives the driver a block at a
time to write, rather than a character at a time.  The driver is still
responsible for ALL of the hardware-dependent stuff you mentioned. Using SBF
will not alleviate any of this.
   You're confusing SCF (the file manager) with ACIAPAK (the UART driver). SCF
is used to talk to _any_ device that uses "streams" of bytes for I/O, including
printers, serial ports, the screen, keyboard, etc. SBF just takes that stream
and breaks it into blocks to give to the driver.  To do the same under SCF, the
driver would just have to buffer a block before sending it.
                              - Tim Koonce

-*-

30294 22-JUN 01:53 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280)
     From: TIMKOONCE    To: PAULSENIURA

Well, Paul, it is interesting to see that people put so much faith in standards.

A now-famous quote in some circles:
  "The wonderful thing about standards is that there are so many to choose from"

   While I don't claim to be an expert on the standards you mentioned, I do know

a fair bit about ANSI, and can tell you that IBM PC ANSI.SYS is quite distinct
from X3.64.  To quote from X3.64, page 13:
   "The implementation of all of the controls described in this standard .. is
not a constraint..."
   In plain English, this means that if you implement some fraction of X3.64,
and then add some more stuff not defined in there, you're still X3.64-compliant.

If you compare the extensions added by IBM ANSI.SYS, and VT100 for instance,
you'll find some pretty serious differences.  Also, I'm amused by your claim
that IBM did good by including ANSI.SYS, especially since I've never heard of a
commercial PC program that uses it.
   I had not heard of the "standard graphics extensions" for X3.64. Care to
elaborate on where these came from?  Or where more information can be found.
                                  - Tim Koonce

-*-

30300 22-JUN 22:26 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30291)
     From: RAGTIMER     To: TIMKOONCE

So would SBF be any faster or more efficient?  Like when doing X/YMODEM
transfers?  Can you "flush" SBF if the current block isn't full?

Yeah I know SBF is for tape drives, but then constructive abuse of modules is
what Coco OS9 is all about, grin.

-*-

30302 22-JUN 22:33 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30294)
     From: RAGTIMER     To: TIMKOONCE

Well, I used to run a psych test scoring program that my wife's company had
bought, and it required ANSI.SYS or else a messy screen. Not a program most
users would ever run across, tho.

"Standards?  I believe in standards.  I thinks every company oughta have two or
three of'em!"  Hey, I remember when RS232 was considered a standard...

-*-

30353 24-JUN 15:55 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30280)
     From: OS9UGPRES    To: PAULSENIURA

Paul - Have enjoyed your messages. Some sidenotes on windowing:

The InVision (now called RAVE) port to the ST wasn't done because no one has
paid for it. Actually, it _was_ ordered at one time, then cancelled at the last
second. I know, because I was originally contracted to do it. Anyone could order

the portpak and do it themselves, tho. Again, a matter of money and desire.

BTW, RAVE doesn't have a window manager yet, so it's basically just a very good
drawing platform for control computers right now.

However, there _are_ other windowing systems for OS9/68K. The MGR windowing
system from Bellcore Labs is one. GWindows from Gespac is another. Both are
available on the ST. The MGR port is PD, I think. GWindows is around $100
without any programming libraries at all... those are another $200 or so. They
haven't decided yet.

Both look pretty good, I hear; tho not exactly speed demons. Both are in C,
around 120K long. My windows, which are in asm, will also be ported to the ST
and Amiga, which should give us a broad base of users/programmers.

BTW, X should be out this fall from Microware, so the rumors go. No idea on its
price. - kev

-*-

30387 26-JUN 00:09 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30353)
     From: RAGTIMER     To: OS9UGPRES

Any ideas on its (X Wndows) size or speed, he he?  THe word is that X is pretty
big and not too fast.  I just got a book on it and they say "use a platform with

all the raw power you can get." But anyway, an Official X for OSK will enhance
its value in the market, certainly to the '020 crowd.

We know YOUR windows will be lean and mean! --mike k

-*-

30403 26-JUN 20:57 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30387)
     From: ZACKSESSIONS To: RAGTIMER

At my day job I use a DEC VAXstation 3100. It is running DECwindows, DEC's
implementation of X-Windows under VMS. The 3100 runs at around 3 MIPS (thats
MIPS, not MHz!) and has 8 mb memory. Some people may consider some of the window

functions slow, but it is fine with me! After using OS9 L2 for almost 2 years, I

was REAL happy to get a (read ANY) window system on my desk!

Zack

-*-

30419 27-JUN 21:24 General Information
     RE: Getting OS9 & CoCo3/4/5/6/... on ban (Re: Msg 30403)
     From: RAGTIMER     To: ZACKSESSIONS

OK.  I use a Sun 3/60 running Snview 4.0, with 12 MB.  It's jnjot nearly as
snappy as the older Suns running 3.0, but a guy down the hall who is
experimenting with X Windows on the Sun (sorta like MSDOS on the Amiga) says X
is much faster than Sunview.

Of course Sunview requires hundreds of K, and since it runs over UN*X, the first

2 MB don't count!

-*-

End of Thread.

-*-

30276 21-JUN 01:23 Graphics & Music
     RE: Weather Radar (Re: Msg 29972)
     From: PAULSENIURA  To: ZACKSESSIONS


  -> First of all, the VEF pic file you include is not exactly in "true" VEF
  -> format.  The first two bytes of a VEF pic file from a Type 8 window
  -> whould be $0000, not $0008.

Someone on CIS documented the VEF stuff, and that field should be the "Screen
Type" code (STY) as described on page 3-13 of the Windows section of Tandy's OS9

L2 books.  Mind you, I have not been on CIS for a very long time, so if someone
will give me the official ratified agreed-upon 100% true blue VEF documentation,

I'll change the program.  :-)  I don't want someone's interpretation of this
standard, I need the official typed-up standard itself, please, so I can do it
right despite what everyone thinks it should be.

If there isn't such documentation available, I'll consider "VEF" a non-standard,

and it's anyone's ball game as to what should be in those fields. (If that
statement wasn't strong enough to make people provide official docs, I don't
know what *will* make 'em do it!)

  -> And the file length should be 32018, not just 30738 bytes.

Lessee according to my math:

     320_dots_per_line * 192_lines / 2_dots_per_byte = 30720

Right?  Now you need to add 16 bytes for the palette table, and then 2 more
bytes for that STY field, so 30720+18 = 30738.

Since no one officially supports 200 lines on a graphics screen, but rather only

192 lines are officially supported in any package I've ever gotten, and only 192

lines are visible (sans our GrfDrv patches I documented on GEnie last year), I
do not see how you can come up with your numbers.  :-)

Make it a standard, then maybe we'll start implementing it!


  -> Now how 'bout us poor folk who lives elsewhere in the US of A? Color
  -> Weather Radar sites do cover most of the country y'know. Someone from
  -> each state gonna have to take it upon themself to spend the time
  -> creating a VEF map of their state?

Well that's why I eluded to having to do things right.  I want to ask the SAS
Institute what I proposed in my documentation there (I shan't repeat all that
goop here).  We *can* get "official" state maps and "official" locations for the

NWS radar locations, but just how we do that is up in the air right now.
Certainly no one needs to "take it upon themself to spend the time creating a
VEF map".  The "official" maps have been created by SAS Inst. with computerized
projected coordinates.  We just need to do some asking, probably.  We then must
agree to some kind of location-dependent program parameters: scaling factors,
location of the radar site on "that" state map, etc.  Kinda like the 'env.file'
that comes with MultiVue, maybe, I dunno.


  -> Now, as to getting the data to plot in the first place. When you
  -> mention, "I hope we can get a tie-in to the NWS for access to their
  -> current B-Scan weather files.", I assume you mean Delphi or GEnie?

No, it'd have to be your local radar site!  You would want completely current
information, what is happening "right now", etc.  CIS updates their maps about
every 15 minutes.  I'm wanting to tie into getting the Doppler info, too!  Good
grief, seeing those hooks, that signify a tornado coming, *WILL* save your life!

!  I've been told NWS sites should have more info on what we need to know to ask

etc.  I've been told by this same person that PC BBSs have been doing this and
providing this service for free, in that they'd dial up NWS and do automatic
selections of their menus via the modem & a "smart" program "reading" the menus.

That's how our AT&T 3B2 UNIX box at Okla.D.O.T. is doing it.  (They have a
leased phone line to the Will Rogers Airport, *not* NWS.)  Again I'm told the
NWS might/should have some local access computer lines available with real short

time limits (how do TV stations without the expensive radar gear do it?) so
people can access what they want to get & then log off.  What they get are these

B-Scan files or similar -- not "graphics".


  -> (btw, anyone besides me remember when all the Weather Channel did was
  -> scan a TV camera back and forth on a bunch of instruments!)

Oh boy ... those farm towns that had "cable TV" had such weather channels! Here
in Oklahoma it wasn't that many years ago (mid 1970's when I first started
working for Okla.D.O.T.).  Those old round meters!  Well, now everyone's gone to

the new Weather Channel with all that satellite data transmitted to their sites.

Hmmm, that's an idea ... who's got a CoCo hooked up to their dish antenna so we
can aim & pull down some GEOS pics directly???  The people who wrote WEFAX would

quickly go out of style!!


-- Thx, Paul Seniura.

(p.s. let me know if you find out anything from your NWS site!)

(p.p.s. I do have a newer version that has a "PPOINT" type subroutine of general

interest to everyone who does graphics.  PPOINT is, of course, the way RS-BASIC
can inquire upon the color of a certain graphic pixel, which there is no
counterpart in OS9 right now.  This helps us keep "stronger" radar blips on the
screen when the next radius is drawn.  But it is getting rather slow, and the
"arc" we draw with a straight line still isn't looking better.  We even tried to

"average" the "last" value of a pixel with the next radius' value for that same
pixel (caused by rounding of the X,Y coordinates).  Whatever we can do to make
this newer version look better, that's what we'll upload & let y'all test ...
"whenever" we get time, ya know ...)


-*-

30296 22-JUN 01:58 Graphics & Music
     RE: Weather Radar (Re: Msg 30276)
     From: TIMKOONCE    To: PAULSENIURA

Paul,
    There are such things as "informal" standards, and perhaps you should go
back and re-read those original docs of yours more carefully.  If you would like

to see some VEF docs that are as close to official as you'll ever get, look in
the Graphics database here for a group that I uploaded.  It's entitled something

like "Picture Format Specs", and contains specs for a number of different CoCo
picture formats compiled from a variety of sources.  They are about as official
as you can get in the CoCo world.  If you'd like to submit them to ANSI, feel
free! <grin>
                       - Tim Koonce

-*-

30297 22-JUN 18:25 Graphics & Music
     RE: Weather Radar (Re: Msg 30276)
     From: ZACKSESSIONS To: PAULSENIURA

>Someone on CIS documented the VEF stuff, and that field should be the "Screen
>Type" code (STY) as described on page 3-13 of the Windows section of Tandy's
>OS9 L2 books.  Mind you, I have not been on CIS for a very long time, so if
>someone will give me the official ratified agreed-upon 100% true blue VEF
>documentation, I'll change the program.  :-)  I don't want someone's
>interpretation of this standard, I need the official typed-up standard
>itself, please, so I can do it right despite what everyone thinks it
>should be.

Well docs have been provided, but who can say that they are "offical"? Tim
Koonce uploaded a series of files in the Graphics&Music lib just a few
weeks ago. Group Name is "GRAPHICS FORMATS". It agree with every program
I have which performs VEFIO of some kind. This includes MAX9, VEFIO,
ViewVEF, WLoad.B09, and View. I first figured it out be dEding picture
files, reading Kevin Darling's source to WLoad.B09, and the source to
VEFIO.

They all agree that the second byte is a "code" which describes window
type and resolution. Check vef.hlp in the aforementioned group. It also
states that 200 lines are defined, even though many display programs
ignore the first eight lines. MVCanvas will, however let you display and
edit all 200 lines. (Not all at once, though!)

>Lessee according to my math:
>
>     320_dots_per_line * 192_lines / 2_dots_per_byte = 30720
>
>Right?  Now you need to add 16 bytes for the palette table, and then 2 more
>bytes for that STY field, so 30720+18 = 30738.
>
>Since no one officially supports 200 lines on a graphics screen, but
>rather only 192 lines are officially supported in any package I've ever
>gotten, and only 192 lines are visible (sans our GrfDrv patches I
>documented on GEnie last year), I do not see how you can come up with
>your numbers.  :-)
>
>Make it a standard, then maybe we'll start implementing it!

As I mentioned, MVCanvas DOES officially support 200 lines. And all viewer
programs I previously mentioned are programmed to ignore the first eight
lines, which means since the expect to read and ignore them, then in a
way they ARE supported. Also, EVERY VEF format picture file (except your
OK map!) are 32018 or 16018 bytes large. Download a few from the library here
and do a dir e on them and see for yourself.

Zack

-*-

End of Thread.

-*-

30281 21-JUN 01:52 General Information
     our RiBBS test site
     From: PAULSENIURA  To: ALL

P.S. our official RiBBS test site BBS # is 405-670-6636, 3/12/24/9600 8n1, MNP5
/ARQ/HST with a real USRobotics Courier HST modem (not the newer 14.4k-bps ones)

.  I'm having trouble reaching Ron Bihler for latest fixes, still having a few
troubles with Fido on different mail feeders on them other IBM-PC compatibles,
but almost every module RiBBS comes with is loaded into RAM while we're using
Disto's 1-meg upgrade too!  It's quite fast, in other words!

I'd estimate we have a menu system about 300k big, some of 'em very colorful (
experimenting and test-site, remember, not a real BBS yet, but y'all will have
access to everything but the Fido options -- I promised the FidoNet local
coordinators I'd not let users have access to buggy software until it's 100%
working order).

Even with such a big set of menus, since these things are copied to a RAM disk,
the hot-key effect on menus is almost instantaneous.  I.e. almost everything
that RiBBS v2.0 comes with (that does not need changes to be saved) is in RAM in

one form or another, and we didn't have to rewrite =any= of Ron's code to do it.

Contrast this to products like UME that won't let you customize the use and size

of RAM for various functions (not to mention staying away from system problems
using Get/Put buffers -- RAMdisks are 100% trustworthy when the VDD.AR patch is
installed!).

Yep, RiBBS v2.0 *is* one of those products we've been badly needing -- Ron
proves that CoCo/OS9 can do what the big blue machines have been doing: Fido!
"ARF!!"  And Ron needs to be congratulated and written up in the Rainbow for
this effort.  Yes this needs to be put into the "OS9 Spotlight" column.

It would show why such "compliance" to the already-agreed-upon standards in
various industries needs to be done.  And "compliance" still needs to be done
"correctly" for ANSI video, QIC tape drives (including "smart" SCSI drives),
etc., on the commercial OS9 marketplace.

(now if Ron would just clean up his code, pare-down the 16k "Connect" module to
8k etc.!, fix the remaining bugs, put in just a couple more features, he could
sell it at a price level comparable to the commercial PC BBS packages go for!
And I'd be willing to splurge that much.  I'm *trying* to make a point: your
products *will* make money if you design enough "guts" into them to make them
worth that much money.  And support your products, too.)

-- Thx, Paul Seniura.


-*-

30284 21-JUN 21:56 Programmers Den
     C.ASM problems....
     From: DODGECOLT    To: ALL

Hi all,
 Well, I am having a small problem here with c.asm and one of the library
function files for my CGFX lib. Basically, c.asm isn't reading the whole
assembly code file and is missing some constant strings. This leads to the
inevidible message from the linker that it can't find the reference to the
string. Funny thing is, when I check out a listing of the code it is producing,
it appears that the first pass figures the offset out OK, but the it seems to
stop before it actually gets to the symbol in question. Anyone have any clues?
 -Mike
 (BTW, I have tried both optimized and not)

-*-

30289 22-JUN 00:22 Programmers Den
     RE: C.ASM problems.... (Re: Msg 30284)
     From: DODGECOLT    To: ALL

An update- it appears that the problem was caused by a bug in the compiler- the
string I was writing contained several chars that were > $7f (bit 7 set) In any
case, the compiler threw those chars into an 'fcc', which c.asm doesn't like.
 So much for THAT problem...
 -Mike

-*-

30298 22-JUN 22:19 Programmers Den
     RE: C.ASM problems.... (Re: Msg 30289)
     From: RAGTIMER     To: DODGECOLT

They must have put that bug in to keep us from hard-coding ESCape sequences. And

if you believe THAT...grin.

Did you see the c.prep bug we talked about here a couple months back? If you say

  #define toolong "abcdefgh"
  printf(toolong); you only get the first 7 (or was it 8?) characters -- the
macro preprocessor can't take any more. Then someone (Dale P?) added that if you

stick a blank space or something like that in there, it will work OK for any
reasonable length.

Hope Microware is braced for a flood of bug reports once the MM/1 comes out.
Unlike those old commercila programmers, we coconuts really "exercise" the
compiler.  Grin, maybe. --mike k


-*-

30303 22-JUN 22:39 Programmers Den
     RE: C.ASM problems.... (Re: Msg 30298)
     From: DODGECOLT    To: RAGTIMER

Didn't know about <that> bug!  Yea, I'm sure we will have those MW programmers
running around once the new machines come out!
 -Mike

-*-

End of Thread.

-*-

30286 21-JUN 23:47 General Information
     RE: Serial Mouse (Re: Msg 30197)
     From: OS9UGVP      To: BRIANWHITE

Brian,
  Yes, this is Bruce Isted here... I suppose I should sign with my full name.
Oh well.  I know why the mouse occasionally seems to screw up and then recover,
and I will fix it now that I have the OK I needed before I would use the fix.
Look for it fairly soon, but no promises that it'll be real soon.
  Lets see, I put all that work into the ballistic mouse speed up stuff, and now

you want them taken out <sob>  - actually thats a <grin>
  No problem... when i upload the new serial mouse file I'll include patch
offsets & whatnot to let you turn the ballistic stuff off.  As it is right now
I'm not sure whether it can be easily done.  Bug me again if I don't say
anything about it in the next few days.
  Bruce


-*-

30343 24-JUN 02:52 General Information
     RE: Serial Mouse (Re: Msg 30286)
     From: BRIANWHITE   To: OS9UGVP

Bruce,

One more thing I discovered about the serial mouse.  You may have already found
it, but I thought I'd mention it anyways.  It seems that whenever you click on
the MV menu-bar twice in a row (within any amount of time), the computer hangs.
This happened the first time I did it.  The second time it hung for a second and

then recovered.  The mouse was then fine until I rebooted and then it hung
consistantly every time I clicked twice in a row on the menu bar.  The only
program I tried this with was Bells & Whistles.

                                                           Brian

-*-

30439 29-JUN 23:42 General Information
     RE: Serial Mouse (Re: Msg 30343)
     From: OS9UGVP      To: BRIANWHITE

Brian,
  I haven't run into that problem (mouse hangups on double click) except with
programs that don't have a tight enough mouse-signal routine in them. II've got
much improved mouse drivers almost ready for uploading... all I need is some
time to do the doc changes (not much, I think) and stuff.
  Bruce


-*-

30576 8-JUL 03:18  General Information
     RE: Serial Mouse (Re: Msg 30439)
     From: BRIANWHITE   To: OS9UGVP (NR)

Bruce,

This hangup had nothing to do with mouse click code.  I could click, move the
pointer around the screen for 10 seconds, and if the very next click was again
on the menu bar, the system would hang.  Sorry I can't milk my system for more
information, but I
 took the mouse back to work.

                                                           Brian

-*-

End of Thread.

-*-

30288 22-JUN 00:22 Patches
     OS9 LII and GFX2
     From: GLENNTHIG    To: DALEP

Dale,
   I just received my July issue of the Rainbow. Glad to see you're back andthe
roilian life.
   I have a couple of questions, as might a lot of other people about the Ipatch

file for the GFX2 module. I have not been able to find it. (Maybe I should ask
Kevin about that though.)
   Also since Tandy is dropping The Coco, will there BE a new version of OS9
Level II?
   Maybe these questions have allready been answered many times, I just have not

seen them. Any light you can shed on the situation will be appreciated. Thanks.

                                                     GThigpen
                                                     (GLENNTHIG)

-*-

30314 23-JUN 04:59 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30288)
     From: OS9UGPRES    To: GLENNTHIG

Glenn -

I finally found time (lately it seems like I've run out of process numbers ;-),
and created/posted a new gfx2 module to go along with Dale's column.

The interesting thing is, I'm surprised someone didn't just write one in
Basic09! <grin> From Dale's description it would've been pretty easy to do,
methinks?

There are a coupla volunteers taking over the upgrade documentation holdup... so

keep crossing them fingers. The 68K machines are the topmost priority right now,

tho. best - kev

-*-

30358 24-JUN 20:39 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30314)
     From: GLENNTHIG    To: OS9UGPRES

kEV, I appreciate the time you and others take to write programs/procedures and
the like for us non-progfgrammers(gripers). I am really looking forward to
seeing those new 68000 machines in action.
   I write a little in Basic09, but right now just working and single-parenting
swwm to keep me occupied.
   Thanks.
                                                             Glw


-*-

30364 25-JUN 01:19 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30288)
     From: DALEP        To: GLENNTHIG (NR)

Glenn

First, I noticed just this even that Kevin has uploaded the new GFX2 module to
compuserve.  That means he most likely has posted it here also.  But I just
checked in and went directly to the Forum.  I have not looked in the Data
Libraries yet.  I'll look soonest.

My bet on the upgrade ... is that there will be one.  My second bet on the
subject is that it will most likely be from a third party.  We'll all have to
stay tuned together.

Best Regards,

Dale


-*-

30393 26-JUN 00:40 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30364)
     From: GREGL        To: DALEP

Dale,

    The new GFX2 module is safely tucked away in "New Uploads" in the databases
awaiting all those hungry downloaders. <grin> From the looks of it, I think it
was definitely worth the wait. Now on to OS-9 version 3. <grin>

    -- Greg

-*-

30435 29-JUN 02:29 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30393)
     From: DALEP        To: GREGL

Greg,

Yep, I think the people on the Forum are going to love GFX2.  You might put a
bulletin on when they sign on to encourage them to download it.  Definitely
worth the trouble.

They'll love "version 3" too!  If, it ever sees the light of day.

Best Regards,

Dale

-*-

30441 30-JUN 00:04 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30435)
     From: DWHILL       To: DALEP

    "If, it ever sees the light of day."

    Eep.  You mean the upgraded Level II might stay in limbo?  More and more it
looks like I'll be forced to a MM1 or a TC9--which I can't afford.  I'm still
trying get my money's worth out of my CoCo 3 (I bought a 2400 baud modem today).

    Very glad to see you back in Rainbow, it's looking awfully thin these days.

--Damon

-*-

30620 9-JUL 01:45  Patches
     RE: OS9 LII and GFX2 (Re: Msg 30441)
     From: DALEP        To: DWHILL

Damon,

I certainly hope it sees the light of day ... I'm just impatient.  There's a lot

of life left in these CoCo III's.  And this new software will certainly make a
lot of people sit up and take notice!  Because ... it will be a lot easier to
write nifty looking software in Basic09.  And it will all look better and run
much faster.  CUL.  Dale

-*-

30672 12-JUL 20:43 Patches
     RE: OS9 LII and GFX2 (Re: Msg 30620)
     From: DWHILL       To: DALEP (NR)

I'm hoping there's a lot of life left in MY coco, too.  I'm trying to sell my
messydos machine for whatever I can get for it (Leading Edge Model M, an XT
clone) and just bought a 2400 baud external modem for the Coco.

I just did the IRQ diode hack and am now running Xcom9, which is notorious ojn
my system for locking up.  For some reason, Osterm almost never does. At any
rate, I'm hoping it'll help prevent dropped characters as well, though I think
that really needs the ACIA hack.

Very curious about the new Coco4-type machines, you betcha I'll be at the
Cocofest here in the fall to look at 'em.  Hope to see you here also.  The
weather here in Atlanta in the fall is most pleasant.  (That's a plug, ya'll.)

--Damon

-*-

End of Thread.

-*-

30304 22-JUN 22:42 General Information
     Coco Clipboard
     From: RADICAL      To: ALL

Anyone any idea as to the status of the Coco ClipBoard?  TP1, can't be reached
in these waters.  Does anyone have his GENIE address? I know he promised better
service, but I haven't seen a ClipBoard in quite a while.  Len


-*-

30305 22-JUN 23:52 Programmers Den
     RE: C question (Re: Msg 30101)
     From: CHYDE        To: ZACKSESSIONS

I am using it in several programs of my own.  One of them is similar to the UNIX

cal utility.  The garbage on the screen and stuff doesn't happen all the time
the program is called just once in a while.

function.  It's with this one that the problem seems to be most common.  I've
gotten around the problem by using the time() and localtime() functions from
Carl Keirder's C library.  This uses more space but it seems to solve the
problem.  I have some other people using the programs and am waiting for their
comments.  I can send you some the source in E-Mail if you want.  Personally I
think it's just me.  My wife put a curse on my computer since I've been spending

so much time with it lately  :-).

     Chris

-*-

30309 23-JUN 01:31 Programmers Den
     RE: C question (Re: Msg 30099)
     From: TIMKOONCE    To: CHYDE

Actually, that sounds like a stray pointer problem.  Be double sure you're
passing it the right pointer.  How are you declaring/allocating the buffer for
getime(), and how exactly are you calling it?
   Since the "trash" block that OS9 uses to fill up a memory map is also
incidentally the first block allocated to video memory, stray pointers will
often write garbage to the first text screens allocated.  Whenever you see
garbage like that, there's a good chance there's a stray pointer somewhere!
                       - Tim

-*-

30315 23-JUN 05:21 Programmers Den
     RE: C question (Re: Msg 30309)
     From: CHYDE        To: TIMKOONCE

I'm declaring the buffer as described in the manual:
          struct sgtbuf *buffer; I call it with:
          getime(buffer);

I think that's right, but I'm still learing C so anything is posible.  The book
I have on C doesn't say much about making System calls (It's geared mainly for
PC's anyway) and there isn't anything in the manual so it seems reasonable.
     Chris

-*-

30325 23-JUN 15:42 Programmers Den
     RE: C question (Re: Msg 30315)
     From: ZACKSESSIONS To: CHYDE

Tim hit your problem right on the nose, a stray pointer problem, and don't feel
bad it is a common error of beginning/intermediate C programming.

You need to understand that the manual describes the function as

#include <time.h>
setime(buffer)
getime(buffer)
struct sgtbuf *buffer  /* defined in time.h */

This means that the function getime() requires a single parameter, namely a
pointer to a struct of type sgtbuf. Now when you declare just a pointer to
struct, you don't actually allocate any space to hold the data defined by the
struct. All you declared is a pointer variable which can point to a struct of
type sgtbuf. Try it this way:

#include <stdio.h>
#include <time.h>

main()
{
 struct sgtbuf tim;

 getime(&tim);
 printf("Current time is %02d:%02d\n",tim.t_hour,tim.t_minute);
}

Another way to do it is to do it this way:

#include <time.h>
#include <stdio.h>

 struct sgtbuf *tptr;

main()
{
  struct sgtbuf tim;

  tptr = &tim;
  getime(tptr);

  printf("Current time is %02d:%02d\n",tptr->t_hour,tptr->y_minute);

}

Does this make any sense?

Zack

-*-

30327 23-JUN 17:42 Programmers Den
     RE: C question (Re: Msg 30325)
     From: DODGECOLT    To: CHYDE

Another thing to remember is that the Microware C compiler usually 'forgets' to
pass the pointer to a structure. What I mean is that you have to tell it to send

a pointer (with the & operator.) Otherwise it will send the whole structure,
which will surely cause you problems!
 -Mike

-*-

30329 23-JUN 18:59 Programmers Den
     RE: C question (Re: Msg 30315)
     From: GREGL        To: CHYDE

Chris,

    You declared the pointer to the structure (struct sgtbuf *buffer) but not
the storage area for the buffer itself. Look at it this way: Declaring a pointer

sets up a 2 byte storage area in memory that contains the address of the object.

When the pointer is declared, the address stored there is undefined - garbage.
Therefore, when you call getime(buffer); you are passing a garbage address and
the getime() function is storing the date and time at whatever address that
happens to be. To use the same declarations you need to allocate a section of
memory for the structure, which would cause your code to rewritten as:

    struct sgtbuf *buffer;

    buffer = malloc(sizeof(struct sgtbuf));
    getime(buffer);

Here we tell malloc() that we want to allocate a section of memory with the same

size as the sgtbuf structure (6 bytes I believe) and to assign the address to
buffer. You can also write the code as follows:

    struct sgtbuf buffer;

    getime(&buffer);

This declares buffer as an sgtbuf structure. Note that this allocates enough
memory to store the entire structure instead of a pointer. Next we use the
"address of" (&) function to pass the address of the structure to the getime()
function. Both of these have the same results. The difference is the method you
use to access the variables. In the first method using pointers you would use:

    year  = buffer->t_year;
    month = buffer->t_month;
    day   = buffer->t_day;

In the latter method without using pointers you would use:

    year  = buffer.t_year;
    month = buffer.t_month;
    day   = buffer.t_day;

If you have any more questions, feel free to ask.

    -- Greg

-*-

30456 1-JUL 00:58  Programmers Den
     RE: C question (Re: Msg 30327)
     From: CHYDE        To: DODGECOLT

Thanks, I was begining to wonder.  It seems other programs of mine have the same

problem.  Well back to the drawing board.  And just when my wife thought I was
going to spend some time with her.
     Chris

-*-

30457 1-JUL 01:03  Programmers Den
     RE: C question (Re: Msg 30329)
     From: CHYDE        To: GREGL

After Zack mentioned the dangling pointer and alocation I thought it might be
that or something else equally sneaky  :-).  Anyway thanks.

And the professors in the C.S. department don't think it's ness sasary to have a

class in C.

     Chris

-*-

30458 1-JUL 01:09  Programmers Den
     RE: C question (Re: Msg 30325)
     From: CHYDE        To: ZACKSESSIONS

I will endevor to try what you suggested when I get a chance.  I had thought
about that being a problem, but at first the programs worked fine (good luck, I
guess).

I guess it's back to the old editor and compiler to rewrite some code.  And just

when my list of projects was getting down to managable size.

Thanks for your help,
     Chris

-*-

30549 7-JUL 18:43  Programmers Den
     RE: C question (Re: Msg 30457)
     From: TOMBRETON    To: CHYDE

Well, C++ people think it's neccessary to have a class in C....<groan> <duck and

run>

     Tom

-*-

30551 7-JUL 20:56  Programmers Den
     RE: C question (Re: Msg 30549)
     From: TOMBRETON    To: ALL

But more seriously, I'm trying to learn C++. Does anyone know good 'n cheap
compilers, books, and references? I've got them all for C. How much more do I
need to program C++ decently?

      Tom

-*-

30558 7-JUL 23:21  Programmers Den
     RE: C question (Re: Msg 30551)
     From: XLIONX       To: TOMBRETON

Howdy Tom,

Hate to say this but, you have to almost start over. There are alot of good
"crossover" books that will no doubt make a mess of your life (for awhile ];->).

The second edition of "The C Language" by K&R includes an introduction to OOP
(++) and books on the subject range from $19.95 to $80.00 (American). The best
you can do is to write to the manufacturers " on their products as far as
tutorials and online help goes. Zortech, Microsoft, Borland, Abraxas and the
list goes on.

I don't know what kind of machine you are going to use, so I can only guess IBM
(clone). If you want to go C++...DON'T SETTLE for a compiler that claims "with
C++ extensions" unless it covers ALL C++ functions.

You can write code in any C compiler that could be considered OOP in design, and

the concept behind OOP (C++) is not too hard to deal with.

Good luck, and let me know what you decide to do (Professional Curiosity).

-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX
(DELPHI) -mwf@SANDV

-*-

30591 8-JUL 14:30  Programmers Den
     RE: C question (Re: Msg 30558)
     From: TOMBRETON    To: XLIONX

Thanks for the help, Mark. I'll let you know how it goes.

       Tom

-*-

30691 13-JUL 21:02 Programmers Den
     RE: C question (Re: Msg 30549)
     From: CHYDE        To: TOMBRETON (NR)

Yeah so do most of the C.S. students at the Univeristy of Idaho.  We're working
on it.  Maybe for the spring '91 semester.

-*-

End of Thread.

-*-

30307 23-JUN 00:37 Patches
     hires
     From: BANCROFT     To: ALL

I do not yet have cocomax 3, but plan to get it in the future.  I am building a
switch to switch hires on/off.  I also want to put in the modified switch. The
problem is, all dos on the switch, are schematics in cocomax 3 double height
format.  the best I can do, is convert them to vef, and view the top half only,
but this does me no good.  Is there any way I can get these schematics?


-*-

30310 23-JUN 01:32 Graphics & Music
     RE: hires (Re: Msg 30307)
     From: TIMKOONCE    To: BANCROFT

My VIEW program will display both halves of a CoCoMax 3 picture.  Try it, you
might like it.
                     - Tim Koonce

-*-

End of Thread.

-*-

30316 23-JUN 06:02 Programmers Den
     RE: Multi-Vue programming (Re: Msg 30102)
     From: OS9UGPRES    To: ALPHASOFT

Keith -

I've been off for quite a while... didja figure something out?

About the only way I can figure for two programs to use the same menu bar is to
share a data module with the menu info changed inside.

Actually, that won't work either. Hmmm. Windint is a smart cookie and checks
process id's and something else (I forget what) to make sure this isn't just old

menu info hanging around. Perhaps if the child process signaled the parent to do

a SS.UMBar, again using the data module??

Kev

-*-

30404 26-JUN 21:05 Programmers Den
     RE: Multi-Vue programming (Re: Msg 30316)
     From: ALPHASOFT    To: OS9UGPRES

I don't know if that would work either, cause the new process still couldn't
pull up the menu.

I can share the menu data, but I need a way to tell OS9 that the menu belongs to

me (and has X data).   I can do an _ss_wset, but it clears the screen.

If I could somehow accomplish an _ss_wset without clearing the screen???

Let me know.

-*-

End of Thread.

-*-

30317 23-JUN 06:02 68K-OS9
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30117)
     From: OS9UGPRES    To: THEREB

Matt-

You would think that fragmentation would be a bother under OS9/68K, but I've not

seen it yet on my ST or MM/1. It's a little different from coco L-I, because
programs can have up to 31 (?) sections of memory allocated.

Let me see. Like right now I have 1852K free, with the largest section being
1843K long. I'm not worried about frag yet <grin>. On the other machine, I have
935K free, with 934K being the largest section. So it's not a bother.

Right, second and fourth Wednesdays of every month at 7:30pm. Go up 401 to the
Raleigh Beltline and head for US 1 North (northeast). Get off on the US 1
(Henderson) exit, and travel north on 1 for about say, 4-5 miles. Just after
1/401 split again, you'll go past a large shopping center (Mini City) on the
right. Look for the main stoplight intersection of Millbrook Road. Continue
north to the next light, which is Spring Forest Road. Take a left. Go about 2
miles until you come to Millbrook Senior High School on your right. The _last_
parking lot (black asphalt/trailers/gravel) at the far end of the school is the
spot. Go into the end of the school, and stick your head into various rooms
until you spot a small group of insane looking people. That's us <grin>. Call me

at 919-872-7986 that afternoon if you're coming up.

PS: we read many forums and nets... but are usually too swamped to answer much
;-).

-*-

30333 24-JUN 00:12 General Information
     User Group Meetings (Re: Msg 30317)
     From: THEREB       To: OS9UGPRES

Thanks a lot.  I'll TRY to make it to one of your meetings - I may not be able
to anytime soon, I'll be in Minnesota for three weeks starting July 19th - but
MAYBE I'll be able to make one before then.  Have you been bringing the MM/1 to
the meetings?  =)  And thanks for the directions, too; I'm not REALLY familiar
with the Raleigh area, and they'll help if I am able to make it.


                                                Matt.


-*-

30335 24-JUN 01:26 General Information
     Raleigh Club (Re: Msg 30333)
     From: OS9UGPRES    To: THEf I have something new worth showing off <grin>.

-*-

30377 25-JUN 20:58 General Information
     RE: OSK Mem Management, Raleigh Club.eM 3) r:TEB   oO9PE
 s isIuttet ahe toci wie rgamio Ii oilyucl n  nt? )Iwl O oe h
tn! a'OEom aoso nigoce for. Actually, I'll
bring an 8cm515 if you need me to.  I don't know if I'll make it this week or
not, but if I can't, I'll try to make it to the first meeting in July.


    Again, thanks for the directions & help.


Matt.     THEREB     (919) 484-1230 voice or call the Norca BBSs!

(919) 868-8431
      867-7152
      424-2895
      497-8806


-*-

30384 25-JUN 23:35 General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30377)
     From: NES          To: THEREB

Matt,  You can send the disk in os9 or rsdos or MSdos format, I run the BBS
under os9 but have the CC3disk patch so I can read rsdos disk and MSdos disk.
hope you got all the info you needed in my letter. I just order MV canvase will
let you know how it looks also the program called Planet Engine by Gravity
Studio is a must for those who love to look at theh stars, it cost only $24
dollars but beats out programs that I have payed twice that, I comes with a
sharp looking Manual and run's under(or without) MV, but I think the MV version
looks the best. I was impressed by the program when I ran it, and seen what the
moon's phase was, and then that night I whent out and the program was correct in

the moons phase and star positions,.... Well chat at you latter.. Eric

-*-

30402 26-JUN 20:54 General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384)
     From: ZACKSESSIONS To: NES

When you say that Planet Engine runs with or without MV, does that mean there
are two binaries, one which works with GrfInt and one that works with WindInt?

Zack

-*-

30409 26-JUN 22:40 68K-OS9
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30402)
     From: NES          To: ZACKSESSIONS

Zack, Yea, but only the MV version has pull down menu's and also has more
options.... eric

-*-

30466 1-JUL 22:34  General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30384)
     From: THEREB       To: NES

    Hmmm. . .  I just got Multi-Vue myself, I'm starting to get the hang of it.
. .  but do you have any suggestions?

                                        Matt  /  TheReb


-*-

30485 3-JUL 00:00  General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30466)
     From: NES          To: THEREB

Matt, Help in what area of MV?  If you get a program that you cant get to run, I

my could help you, always check your ATTR of file all icon must have pe e pw pr
r w set, also make shure things are in the right directorys. I have mine setup
like this:
 dd/MV/CMDS
 dd/MV/CMDS/ICONS
 dd/APP  (application directory with the AIF files) Let me know if you have
anytrouble. Eric

-*-

30517 5-JUL 21:34  General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30485)
     From: THEREB       To: NES

Well, I'm beginning to get the hang up Multi-Vue.  BEGINNING to.  I have
virtually NO MV applications (two icon editors and the included graphics demos -

that's all), but I like finally having a WIMP interface available. Problem is,
I'm now running out of RAM space on my 512k system =) !

                                        Matt


-*-

30520 5-JUL 23:54  General Information
     RE: OSK Mem Management, Raleigh Club. (Re: Msg 30517)
     From: NES          To: THEREB (NR)

Hay, You should download  "MAX9" a nice graphics editor that will run under MV,
Its on my board or you can get it here, BTW  MVCanvas is a nice graphics editor
pakage, a must for OS9 users who love drawing. also there's Zack's  Banner maker

progam, Solitare, Luner Lander, View looks good under MV, with view under MV all

the graphics files have there name under there icons, ie GIF files will have the

GIF icon. realy nice. That's all I have at the monment. yea, I run out of memory

all the time with the board up and MV and all the other windows I have open.


-*-

End of Thread.

-*-

30318 23-JUN 06:03 68K-OS9
     RE: Unlink (Re: Msg 30123)
     From: OS9UGPRES    To: EDDIEKUNS

Eddie - yah, just unlink one more time (past 0) and a sticky module goes away.

-*-

30319 23-JUN 06:03 Programmers Den
     RE: Aciapak bugs.  Chapter 3.  <Sigh> (Re: Msg 30134)
     From: OS9UGPRES    To: KNOT1

Jamie - nice testing! That takes us a lot closer to figuring out the reasons for

the strange ability to unlock what shouldn't be unlockable (altho I'm usually
glad it is! ;-). thx! - kev

-*-

30320 23-JUN 06:03 Graphics & Music
     RE: MVCanvas 2.0 (Re: Msg 30142)
     From: OS9UGPRES    To: RAGTIMER

Mike - I bought extra ink paks way back when I first got the printer, so no
problem there. It just turned out that dis-use causes some of the ink to dry up
inside several of the tubes, and they clog up.

I know it happens to others at times, and also knew that some people used some
liquid to clean the tubes out.... I was hoping you knew what. thx!

-*-

30362 24-JUN 23:46 Graphics & Music
     RE: MVCanvas 2.0 (Re: Msg 30320)
     From: RAGTIMER     To: OS9UGPRES

Sortry I don't.  If you find out how people clean out their printer ink tubes,
please post it up here, Kev.  Thanks, mike k (PS:  Mine are working fine at the
moment).

-*-

End of Thread.

-*-

30321 23-JUN 06:03 68K-OS9
     RE: GEN (Re: Msg 30143)
     From: OS9UGPRES    To: KTT (NR)

Hi! Sorry I took so long to get back to answer you.

Your best bet is to call Microware themselves for more OS-9000 info and
pricing... 515-224-1929. Ask them for info on OS-9000, and also the OS-9
Catalog, which is filled with a terrific description of OS9.

Yell if need more help. best - kev

-*-

30326 23-JUN 17:34 Patches
     Disto RTC mods
     From: OS9UGVP      To: ALL

  A while ago someone with a Disto RTC was having problems with the ACIAPAK
driver from my "ELIMSW.AR" package.  I received some mail from them, but I have
misplaced the message and I can't recall who it was.  I have some more
information that might be helpful, if I can just figure out who I was talking
to.  So if you're out there, let me know who you are!
  Bruce


-*-

30328 23-JUN 17:55 Patches
     RE: Disto RTC mods (Re: Msg 30326)
     From: DODGECOLT    To: OS9UGVP

Yea, I think that was me.  I take it you have found something from the code I
sent you?
 -Mike

-*-

30438 29-JUN 23:38 Patches
     RE: Disto RTC mods (Re: Msg 30328)
     From: OS9UGVP      To: DODGECOLT

Mike,
  Now that I see your "handle" again, I'm sure it was you.  I've got an ARchive
with a slightly modified source file waiting for you... I'll EMAIL it right
away.  Let me know if it helps (or not!).
  Bruce

PS:  This is an ARchived file...  I trust you're familiar with the "EXTRACT
 /NOHEADER" and then DL from your workspace thats required?


-*-

30449 30-JUN 15:44 Patches
     RE: Disto RTC mods (Re: Msg 30438)
     From: DODGECOLT    To: OS9UGVP

Yep, got it.  I'll check it out once I get it dloaded.  Thanks!
 -Mike

-*-

End of Thread.

-*-

30330 23-JUN 19:45 General Information
     Horn toots
     From: PAULIGHT     To: ALL

  I'm very curious about what I can say on DELPHI in regard to commercial
programs that I write and wish to promote...  Is there any guidelines or
restrictions to what (and how much) one can say.   I would like to keep persons
informed and announce program s without abusing or glutting the forum.  Is there

any good message I should read.
            Signed Paul H. Light (Mr. Good Citizen)

-*-

30336 24-JUN 02:16 General Information
     RE: Horn toots (Re: Msg 30330)
     From: TIMKOONCE    To: PAULIGHT

Paul,
     Don't take this as "official", (hopefully Greg or Jim Reed will jump in and

get this right), but I think that the general policy is that product
announcements are gladly accepted in the database (upload it to the General
Database, methinks), and that you're free to answer questions in forum, as long
as you keep it tasteful.  Basically, try to keep it non-obtrusive, and noone
really seems to care. Thanks for asking!
               - Tim Koonce

-*-

30355 24-JUN 18:56 General Information
     RE: Horn toots (Re: Msg 30330)
     From: GREGL        To: PAULIGHT

Paul,

    There are no hard and fast rules, per se. Feel free to post any product
announcements in the databases. You are also absolutely free to answer any
questions that are thrown your way in regards to your products. Basically all we

ask is that you give only the facts, no hype please. You shouldn't have any
problems following those "guidelines." If we think you've "overstepped your
bounds" we'll explain why - but it's rare that anyone does.
    Of course the users have a "need to know" about any new and upcoming
software so they can make purchasing decisions. Basically, product announcements

and answering questions are perfectly acceptible, but no advertisements. If you
have any specific questions, feel free to ask.

    -- Greg

-*-

End of Thread.

-*-

30331 23-JUN 20:37 Utilities
     ARC
     From: SEBJMB       To: ALL

Hi, all.

I'm confused.  I have seen a couple of references in recent uploads to an
archiveing method called "ARC" and the dearchive program called "DEARC". There
has been at least one upload submitted in the "arc" format.  However, I have
been unable to find the DEARC program in any of the databases.

Am I missing something?

eff

(Puzzled)


-*-

30337 24-JUN 02:26 Utilities
     RE: ARC (Re: Msg 30331)
     From: TIMKOONCE    To: SEBJMB

You're quite right, DEARC is _not_ in the database here.  It seems that there is

some confusion over whether the person who uploaded it to us had permission from

the author to upload it here.  Without that permission, we can't accept such an
upload.  If someone can contact the author to get permission, that would
obviously help a lot.
                          - Tim Koonce

-*-

30346 24-JUN 03:20 General Information
     RE: ARC (Re: Msg 30331)
     From: TIMKOONCE    To: SEBJMB

"ARC" is an archive method very popular in the IBM PC world.  OS9ARC and DEARC
are utilities to create and read that archive format.
  I've downloaded the one upload I've seen in ARC format and converted it into
OS9-standard AR format.  Thanks for bring that up!
                         - Tim

-*-

30351 24-JUN 10:54 General Information
     RE: ARC (Re: Msg 30337)
     From: ZACKSESSIONS To: TIMKOONCE

Actually, Tim, dearc IS in the library! It is a member of the group "3D GRAPHICS

PLOTTER" in the Programmer's Den. Only C source is there. I have successfully
compiled it, and have been semi-successful in using it. Only problem was, I had
to filter all extracted files replacing the 0x0A with 0x0D (archive came from a
VAX.)

Zack

-*-

30382 25-JUN 23:19 General Information
     RE: ARC (Re: Msg 30351)
     From: NES          To: ZACKSESSIONS

Zack, If you get the 3D plotter working upload it here or to me, I havent got it

to compile yet... Eric


-*-

30401 26-JUN 20:51 General Information
     RE: ARC (Re: Msg 30382)
     From: ZACKSESSIONS To: NES

Heh, heh, I didn't even LOOK at the 3D plotter, I just wanted the dearc program!

Zack

-*-

30408 26-JUN 22:39 General Information
     RE: ARC (Re: Msg 30401)
     From: NES          To: ZACKSESSIONS

Zack, oh well, I had know problems with the dearc program... eric

-*-

End of Thread.

-*-

30338 24-JUN 02:50 Programmers Den
     Window Help
     From: BRIANWHITE   To: OS9UGPRES

More system problems...

I have a program that has the option of using its own font, the default system
font, or the StdFonts file.  The program checks for an available font in that
order and then loads the font to the system ($1B2B ...) if that is not where it
was found.  The p roblem is that when the window is opened after a font is
loaded from a file, the menu bar contains only the close box.  However, if run
again and allowed to find the font in memory, everything works fine.  I've tried

closing the path I wrote the font loa d command out to, but that didn't help
either.  I've tried opening the window with the menu bar both before and after
the font load command is issued.  Nothing seems to make a difference.  The
symptoms are always the same.  Any ideas about this?

Also, after opening a window to "/w" if I send the codes:

          fcb   27,32,6,0,0,40,24,3,0,3                    - Set window type
          fcb   $1b,$25,0,1,40,23,12                       - Clear screen
          fcb   $1b,$3a,$c8,$01                            - Select font
          fcb   5,32                                       - Turn off cursor
          fcb   $1b,$35,0                                  - Scale switch off

to that window, occasionally the system will return with error #189 (Illegal
Coordinates).  Running my program a second time again always works.  As far as I

can tell, the problem steps from doing the "set window type" and "CWArea/Clear
screen" in the sa me I$Write to the new window.  I've tried changing the order
of the above (always keepin the set codes at the top, of course), but no change.

I guess my next course of action is to try two different I$Write's.  Anyway,
this prob has me kinda stumped, to o.  Any help would be greatly appreciated.

                                                           Brian

-*-

30354 24-JUN 16:13 General Information
     RE: Window Help (Re: Msg 30338)
     From: OS9UGPRES    To: BRIANWHITE

Brian,

I may bumble this a little, but here's some info which might help:

Each window has data stored about its size, colors, etc.  One of the things
which is stored away is the block number/offset of the font. NOT the group and
buffer number. Thus if you remerge fonts using the same numbers, you can mess
everyone up... since the true block/offset could change from under them.

Think of this like a CHX/CHD, where os9 stores just the sector number, not the
actual filename. Similar. So by refinding a font by group/number, the new block
number and offset in memory is reset, and all is well.

Note that the menubar always stores away the block/offset of the font being used

at the moment of SS.WnSet (if I recall correctly).

The error 189 thing is different. It most often comes from a window entry still
having a leftover type number in it (they forgot to clear that when a
window/overlay closes). For example, pulldown a menu and that window entry (the
pulldown overlay) is set to a shadowed box type, with default CWArea inside.
Later, a new window gets that entry, and a cwarea fails because of the leftover
shadowed-type confusing poor Windint. Programs could always SS.WnSet to some
type (00 is good) first to avoid this cwarea glitch.

-*-

30574 8-JUL 03:17  General Information
     RE: Window Help (Re: Msg 30354)
     From: BRIANWHITE   To: OS9UGPRES

Kev,

Okay, all that makes sense.  I'll try doing a WnSet to zero and then a WnSet to
whatever type I am using.  Would that work, or would I need to close the window
path, between the two "set" commands?

As for the font error, I tried writing the GPLoad and Font select commands out
to a path to "/w", closing the path, and then opening a new one to "/w" all
before doing a WnSet to the new window and the font still isn't there.  However,

if I do run the pr ogram a second time (this time it detects that the needed
font has been loaded and thus doesn't try to load it again), everything works
just fine.  Ideas?

                                                           Brian

-*-

End of Thread.

-*-

30339 24-JUN 02:51 Graphics & Music
     RE: Get/Put Buffers (Re: Msg 30200)
     From: BRIANWHITE   To: TIMKOONCE

Tim,

Thanx for the info agout Get/Put.  I was afraid it would be something like that.

I hate the idea of having to unmap a buffer before I can map in the next (a real

time waster), but you have to do what you have to do...

Congrats on your upcoming wedding!  Does this mean that you'll be slowing down
on View and give people like me a chance to catch up?  <grin>  Actually, I
conceed with that battle!  Of course, there are still a few things I prefer in
Show over View, but n ot very many.  You did an excellent job on that project
and I hope you write a similar one for OS-k!

                                                           Brian

-*-

30345 24-JUN 03:18 Graphics & Music
     RE: Get/Put Buffers (Re: Msg 30339)
     From: TIMKOONCE    To: BRIANWHITE

Actually, Brian, I'm eager to see what you finally managed to do with Show.
Sounded like you had some interesting ideas, maybe I can steal some of them!
<grin>
                            - Tim

-*-

30573 8-JUL 03:17  Graphics & Music
     RE: Get/Put Buffers (Re: Msg 30345)
     From: BRIANWHITE   To: TIMKOONCE

Tim,

Ohhh...  It's been a while since the editor has load the Show source.  I don't
remeber what I improved on it.  I know I fixed a couple of bugs and added some
more music formats, including screen flipping for IMG.  Lets see...  I added a
variable sleep ti me, allowed options to be grouped instead of separating each
with a "-".  I was going to try and allow flipping during loading.  I, of
course, was cheating like a madman to get these things done.  I did directCcce..: t+$.,.Y+R-QI
AQzUQ=%9J*T2=I21%AA%99JiXM5Rtverdoing it.  So...  It's been put on the far back burner while the music
editor gets going.  I'm probably going to stop that pretty soon and start from
scratch an MM/1 version.  That's the big problem with assembly.  Abso lutely no
portability.  Just as well, I've got new and better ideas, now!  I think "Show"
is stable if you want me to mail you it in it's current state.  Let me know.  If

you like any of the ideas, you don't need to steal them, they're yours.  I'd be
a f ool to hinder any development of that program of yours.  Of course, I am an
engineer, and you are a mathie, so maybe I should anyways <sit back in chair,
rub palms>.

                                                           Brian  ;-)

-*-

End of Thread.

-*-

30340 24-JUN 02:51 Programmers Den
     SCF Editing and History (Re: Msg 30201)
     From: BRIANWHITE   To: EDDIEKUNS

Eddie,

Yea, you can do single char reads and make your own editor, but that shouldn't
be necessary.  Besides, it redu,X` the flexibility of OS-9.  After all, that is
what all those wonderful flags in the path descriptor are for.  There must be an

easier way.

                                                           Brian

-*-

30365 25-JUN 01:55 General Information
     RE: Alias (Re: Msg 30340)
     From: EDDIEKUNS    To: BRIANWHITE

I disagree.  I don't mind SCF doing its own editing, but I think the shell's
history should be completely separate from the history of SCF.  For example, I
run an editor.  later I quit the editor and want to run the editor again with
slightly different options and a different filename.  When I press the up-arrow,

I want to see the line I typed to enter the editor, not anything I typed during
the editing session.

NOW -- If SCF can be coerced by a flag or something to keep a separate history
list for each path, THEN I'll admit that it's OK to keep the editing in SCF.
<Grin>

                    Eddie

-*-

30390 26-JUN 00:19 General Information
     RE: Alias (Re: Msg 30365)
     From: RAGTIMER     To: EDDIEKUNS

I agree with Eddie -- years of that phone-company OS, ya know. Tho I'd also like

a reapet-line that would work on paths, or whatever.

Right now, in OSTERM, I can't repeat a line by typing CTRL-A. Not clear why not
-- maybe OSTERM uses an I$Read for every character?

-*-

30575 8-JUL 03:18  General Information
     RE: Alias (Re: Msg 30365)
     From: BRIANWHITE   To: EDDIEKUNS (NR)

Eddie,

Actually, what is needed here is a way to see what the next keypress in the
buffer is without actually reading it.  That way, the shell could wait for a
keypress, and then check the key to see if it is one of the arrows.  If not, do
an I$ReadLn.  If it i s, go through its history.  Of course, this does still not

allow SCF editing on those history lines.  Drat.  Seemed like such a good
solution, too.  Still a system call like the one I described could come in very
useful.  Maybe we need a SetStt to load t he SCF last-line buffer with whatever
WE want?  That could be EXTREMELY USEFUL!!!

                                                           Brian

-*-

End of Thread.

-*-

30344 24-JUN 02:52 General Information
     File Attributes
     From: BRIANWHITE   To: GREGL

Greg,

While on the subject of expanded attribute bits, how about another 24!  3 bits
by 8 categories.  The three bits are Read, Write, and Execute.  This would be
the same as having 8 different groups plus user and public.  Of course all user
numbers would als o have to have a similar 24 bits of permission associated with

them.

                                                           Brian

-*-

30357 24-JUN 19:13 General Information
     RE: File Attributes (Re: Msg 30344)
     From: GREGL        To: BRIANWHITE

Brian,

    Out of curiosity, what would you do with eight Read/Write/Execute
categories? I don't see the need for it, to be honest. As a matter of fact,

I think it would be more trouble than it is worth.
    One idea that I've been toying with is assigning default attributes to the
user via the password file. These attributes would override those stored in the
file descriptor - downward only. That is, if the user has default attributes of
group read and group write, he can't write to any file he doesn't own even if
the file descriptor has group write permission. That could be very useful for
putting "ropes" around certain users.

    -- Greg

-*-

30388 26-JUN 00:13 General Information
     RE: File Attributes (Re: Msg 30357)
     From: RAGTIMER     To: GREGL

Good idea for BBS operators.  And I thought you should know that after all these

years, only a few sites have ever got the group attributes in UN*X to do
anything worthwhile.  A great concept that nobody can make work. Microware seems

to either make something work or leave it out -- not a bad philosophy.

-*-

30578 8-JUL 03:19  General Information
     RE: File Attributes (Re: Msg 30357)
     From: BRIANWHITE   To: GREGL

Greg,

I've heard two different things about those group attributes.  First was
something from Frank Hogg mentioning that OSk uses the same file system as OS-9,

thus a hard disk would port over directly.  That was when he was advartising the

QT-CoCo as a tempor ary hard disk with 68000 expandability.  However, just the
other day, I'm sure Kev mentioned something about group attributes under OSk.
I'm not sure where in the forum that is, but I don't think I misunderstood it.

Even if OSk does have the same file system as OS9, then there is still no place
for any of the attributes like "deletable" that you mentioned.  I was just
mentioning what I though would be really useful attributes.  I know they would
solve a lot of my mu lti-user headaches.  If you get any ideas on how to make it

work, let me know...

I came up with the number 8 because that added 3 bytes to the current 1 to get a

full longword of attributes.  It would be nice to have separate groups for, say
"temporary user", "common user", "privaledged user", "software development",
etc.  That's fou r, right there.  Note, that these groups were not exchangable.
By that I mean that each user did not have 8 goups that were independant from
another user.  A group number that mapped to one of the 8 would be even better.
Or, the extra 4 in each byte co uld represent any single group from a choice of
16.

                                                           Brian

-*-

30614 8-JUL 20:47  General Information
     RE: File Attributes (Re: Msg 30578)
     From: TIMKOONCE    To: BRIANWHITE (NR)

Not sure about this, Brian, but I think that under OSk, rather than interpreting

the 16-bit user number as one number as in OS9/6809, it's interpreted as two
8-bit numbers.  The high-order number is referred to as the "group", and the
low-order number is referred to as the "user number".  So, you have 256 "groups"

of 256 users each.  I don't beleive the file system makes any distinction
between public and group access, it's strictly a convenience for assigning user
numbers.
    I could well be wrong, but this would at least explain what you say you've
been told.  If anyone knows better, please correct me.
                         - Tim

-*-

End of Thread.

-*-

30347 24-JUN 03:26 Graphics & Music
     VIEW 4.0
     From: TIMKOONCE    To: ALL

Shortly after uploading VIEW 4.0, Zack Sessions pointed out to me that I had
uploaded the wrong AIF.gif and AIF.gbw files!  I've just re-uploaded the entire
archive with those corrected.  In both of those AIF files, the first two lines
should be:
   View
   -s

Anyone that just used the AIF's to view GIF files with VIEW should notice that
VIEW now produces different results from ViewGIF!! <grin>
                             - Tim

-*-

30348 24-JUN 03:29 Programmers Den
     Make update
     From: TIMKOONCE    To: ALL

I just re-uploaded MAKE to the database.  This upload fixes one minor buglet,
and adds a new feature.  You can now use MAKE with no makefile! Typing "make
<target>" with no makefile is the same as having a makefile with the single
line:
  <target>:
  i.e. MAKE will try to build the target file by searching the current directory

for source files that fit it's built-in rules.  By setting up the default rules
in "make.default" properly, this could be a great help.  Thanks to Mike Knudsen
for suggesting this change, and to Eddie Kuns for discovering the bug!
                               - Tim

-*-

30385 26-JUN 00:02 Programmers Den
     RE: Make update (Re: Msg 30348)
     From: RAGTIMER     To: TIMKOONCE

And thanks to you for putting that feature in! Sorry I didn't help with the docs

as we hoped.  I'll take a look at yours soon as I download the whole thing.  My
"beta" version is doing just fine, meanwhile.  Nice work, Tim -- a lot of
hackers will be grateful. Oops, I meant "developers", grin.

-*-

End of Thread.

-*-

30350 24-JUN 10:07 Telcom
     OSTERM
     From: ELM          To: ALL

I've just started to use OSTERM and have experienced a problem when downloading
ASCII text files under XMODEM or YMODEM.  I seem to be getting extra line feeds.

When I print the text (by LISTing it to printer) I get what appears to be triple

spacing.  I've tried XMODE /p -lf, but it doesn't change anything.

Anyone have any ideas?

Thanks.

Len

-*-

30367 25-JUN 02:35 Telcom
     RE: OSTERM (Re: Msg 30350)
     From: TRIX         To: ELM

You will probably find relief from your CR/LF problem if you go to the SETTINGS
menu.  (It's been so long since I set mine, I can't remember exactly) There is
an option there to set up your XModem downloads.  It will ask you how you would
like your lines terminated when you download text files.  You can set it to end
all your text download lines with just a CR which will make listing your files
much easier.

Here's the problem >I'M< having with OSTerm (2.0.7):
  When I do a YModem-Batch download of a text file, the size is ALWAYS set (by
OSTerm) to 44418 regardless of the actual size of the file.  The download
terminates properly (i.e. doesn't error out) but I'm still left with a 44K file
with lots and lots of garbage at the end.  Y-Batch downloads of binary files
like PAKs, ARs, and executable code all work fine as do regular YModem downloads

of text files.  How's THAT for a puzzler?

-John.

-*-

30370 25-JUN 03:13 Telcom
     RE: OSTERM (Re: Msg 30350)
     From: KNOT1        To: ELM

{Len,

Try going to "Settings (Profile)" and change your "DOWNLOAD-Line-terminators" to

just carriage return instead of carriage return+linefeed, which it may be set
to.

                        -Jamie (KNOT1)- i]

-*-

30373 25-JUN 18:09 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: DODGECOLT    To: TRIX

I think the Delphi Y-batch program is the culprit- apparently it just doesn't
send a length field when sending text files.
 -Mike

-*-

30378 25-JUN 21:22 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: EDDIEKUNS    To: TRIX

I think I understand the problem with OSTerm and YModem batch.  When Delphi
sends a text file via YModem batch -- it doesn't send a file-size.  Delphi
doesn't know what you're going to do to the file in the way of stripping
linefeeds or whatever, so it just wimps out and doesn't send any filelenght
information.  (The YBatch protocal doesn't leave Delphi much choice, I add.)
Thus, OSTerm may not (???) handle this lack of file length information very
gracefully.

                    Eddie

-*-

30381 25-JUN 23:18 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: ELM          To: TRIX

Ain't life mysterious?  Downloading a series of "44K" files sure is a quick way
to fill up a disk!

I'm using OSTERM 2.0.8, but I haven't tried YMODEM-Batch.  I'll try to find a
way to give it a shot and let you know what happened.

-Len

-*-

30383 25-JUN 23:20 Telcom
     RE: OSTERM (Re: Msg 30370)
     From: ELM          To: KNOT1

I'll try resetting the download settings (assuming they're not correct), but
I've been downloading from Delphi for so long with other term programs with no
problem.

Also, I have the same problem when downloading from other services with OSTERM
2.0.8, although I don't know what THOSE settings are.

Thanks!

-Len

-*-

30386 26-JUN 00:04 Telcom
     RE: OSTERM (Re: Msg 30350)
     From: RAGTIMER     To: ELM

All text files I download (with OSTERM) have an extra line feed. There are
little utilities here to strip them off, or write your own. What I do is just
read the file into Dynastar word processor and write it back out, and they're
gone.  Unforch, so are TABS (char byte 09).

-*-

30395 26-JUN 00:48 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: GREGL        To: TRIX

John,

    That sounds like a flaw in OSTerm. When you download a text file from
Delphi, the filesize is set to zero in the Ymodem Batch header block. This is
mostly because Delphi can't calculate ahead of time what the actual filesize
will be. That is, Delphi automatically handles end-of-line conversions (CR/LF to

CR or LF and vice versa) according to your SETTINGS and doesn't know how many
end-of-line characters are stored in the file and whether or not they need to be

added or removed.
    OSTerm should not perform an explicit set filesize call if the filesize in
the Ymodem Batch header is zero. To be honest, I don't think it should perform
an explicit set filesize call regardless. If the filesize stored in the Ymodem
Batch header block is invalid, OSTerm can really mess up an otherwise good
download that way.

    -- Greg

-*-

30398 26-JUN 02:35 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: KNOT1        To: TRIX

Yes, with YModem (batch) the "File size" in block 0 is optional.  Non-text files

are always the same size, so Delphi includes the size in block 0.  Text files
can vary do to the CR/LF/CR+LF line terminator option.  So, instead of scanning
the file and figuring out the file size, Delphi just sets it to zero or maybe
null.  It appears that OSTurm may be assuming that file size is always included,

or it might just be a simple bug.

Since we're airing our YModem beefs, here's mine:

Note:  I'm not using OSTerm.  When the file is about 1K or more evrything's
fine.  When it's smaller, when it starts with XModem (128 byte) blocks from the
start, I receive block 0 just fine.  When I ACK it, Delphi sends block 1 before
I send the NAK-CRC for it and it gets purged from the buffer prior to sending of

the NAK-CRC.  This wouldn't be so bad on its own, but then Delphi will NOT
re-send block 1 when sent either a NAK-CRC or a NAK.  I have to abort the
transfer and download it using XModem-1K.  This never happens with the larger
files.  I suspect this may be a bug on Delphi's end.  Any help, anyone?

                            -Jamie (KNOT1)-

-*-

30399 26-JUN 02:36 Telcom
     RE: OSTERM (Re: Msg 30383)
     From: KNOT1        To: ELM

Len,

Does OSTerm download direct-to-disk or to a buffer and then writes it to disk?
If to a buffer, it may be doing some sort of "translating" somewhere.

                           -Jamie (KNOT1)-

-*-

30400 26-JUN 07:57 Telcom
     RE: OSTERM (Re: Msg 30399)
     From: ELM          To: KNOT1

OSTERM downloads direct to disk.

-Len

-*-

30414 27-JUN 01:35 Telcom
     RE: OSTERM (Re: Msg 30395)
     From: KNOT1        To: GREGL

Gregy, baby!! <GRIN!>  What are you saying??!  The file size information is why
I WANTED YModem Batch!  If that information is invalid, then the system sending
the file had better get it's act together!  All of the information in block 0 is

CRC protected, after all.  So there shouldn't be any "bad transmition" problems.

It's a really great way of cleaning up all that extra garbage at the end of the
file.  Well, *I* like it, even if others don't! :-)

                        -Jamie (KNOT1)-

{P.S.:  Did you read my message to you a few days ago?  (#30254)

-*-

30415 27-JUN 01:36 Telcom
     RE: OSTERM (Re: Msg 30400)
     From: KNOT1        To: ELM

Well, I guess that blows THAT idea out of the water!  If it's not your settings,

I can't figure what OSTerm is doing.  Does OSTerm have any "Download settings"
you can change?  I guess you probably would have already have tried that though,

hmm?  I have my own terminal program which has YModem Batch and it doesn't have
any such problem, so it's not Delphi having problems.  If you figure it out I'd
be glad to hear what it is.

                        -Jamie (KNOT1)-

-*-

30417 27-JUN 20:50 Telcom
     RE: OSTERM (Re: Msg 30414)
     From: GREGL        To: KNOT1

Jamie,

    Somewhere along the line it seems you missed the point entirely. When you
download an ASCII (text) file, Delphi automatically performs end-of-line
conversions for you. If you download a file that was originally uploaded using
CR/LF line terminators, Delphi will convert those to CR automatically. Of course

that really depends on your settings as you can tell Delphi to use CR, LF or
CR/LF line terminators.
    If Delphi were to include the filesize, it would have to perform perform the

end-of-line conversions prior to initiating the file transfer and that could
mean some very long delays. I much prefer it done the way it is.
    As far as the various file transfer protocols go, Xmodem, Xmodem-1K, and
Ymodem aren't that great. Neither of them work very well across packet switching

services such as Telenet and Tymnet. Wxmodem tried to take care of that but it
resorts to vanilla Xmodem once the window-buffer has been exceeded on many
systems.
    Although you may argue the point, Kermit and Zmodem are both well designed
protocols (although the fact that they are *designed* makes them stand above the

rest - the others just happened out of accident) that work very well in many
instances where others fall flat on their faces. Oh yes, I have used both Kermit

and Zmodem in many cases where neither Xmodem or Ymodem would even get started.
Although Kermit suffers from the small block sizes that are used by the earlier
implementations. For many reasons, most of which is described above, I have
pretty much abandoned use of Xmodem, and Ymodem. Fortunately, you should see
Zmodem available on Delphi in the very near future. Zmodem is currently in beta
test and results so far show that it works very well, although error recovery
(the ability to pick up where you left off on aborted downloads) has not been
implemented as of yet. Zmodem also uses variable length packets to aleviate the
padding characters.

    -- Greg

-*-

30423 28-JUN 01:24 Telcom
     RE: OSTERM (Re: Msg 30417)
     From: KNOT1        To: GREGL

Greg,

Yes, but Delphi could save two file sizes, one for single character line-
terminators and another for two character line-terminators.  Or maybe just the
number of lines in the file.  This could be done at the time the file is
uploaded, taking no additional download time.

From what little I've heard, ZModem does sound nice.  I've been writing my own
terminal program and have been only able to implement those protocols supported
on the boards I call.  I only call a couple of places and none of them have
ZModem.  I'm glad to hear that Delphi will have ZModem.  Can I assume that there

is or will be text files describing how to implement it from a programming
standpoint?  Thanks.

                          -Jamie (KNOT1)-

-*-

30426 28-JUN 20:57 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: ELM          To: TRIX

I took your advice and changed my settings to CR only.  It seemed to solve the
problem, at least for the text file I downloaded as a test.  However, the
problem persists on other systems I use that don't permit changing settings.

In the meantime, I have switched to Telstar and am about to download a text file

as a test.  One annoyance I have discovered with Telstar is that for some
reason, CTRL-S doesn't stop the scroll on Delphi.

(Sigh)

Life is SO complicated!

Thanks again,

-Len

-*-

30428 28-JUN 23:12 Telcom
     RE: OSTERM (Re: Msg 30423)
     From: EDDIEKUNS    To: KNOT1

The problem is that Delphi has no idea what CR/LF you use, and thus, even if it
counted lines and figured the arithmetic, it wouldn't know what size to send.
YModem batch is a fundamentally flawed protocal, tho better than it's
predecessors.  It's nice for binary files.  :)  I suppose that Delphi could
implement that line-counting and force you to set the EOL-character count.  But
that forces people to understand more about their machine than many are willing
to.  (And if that is set wrong, then files will either be extended with garbage
at the end or chopped short.)

File length isn't so important with ASCII files anyway, as a good YBatch
download protocal will strip all ^Z and NULLs (etc) anyway.  Tho the rest of the

attributes (last change date + attrs) might be nice.

ZModem docs exist I believe in the telecommunication database.  In fact, I
believe public domain UNIX C source to ZModem has been posted here.

                   Eddie

-*-

30431 29-JUN 00:54 Telcom
     RE: OSTERM (Re: Msg 30426)
     From: KNOT1        To: ELM

Len,

You can always still use an utility here to stip those line-feeds from the files

you download.

                       -Jamie (KNOT1)-

-*-

30432 29-JUN 00:55 Telcom
     RE: OSTERM (Re: Msg 30428)
     From: KNOT1        To: EDDIEKUNS (NR)

Eddie,

Sure Delphi DOES know what CR/LF you use!  That's why you set your "DOWNLOAD-
Line-terminators" in the "Settings (Profile)" section.  How else does Delphi
send the files with the correct line terminators?  You're not talking about
something else, are you?

How does the receiving YModem know that it is a text file?  What if it's a
binary file that ends with Ctrl-Z's and/or NULL's?  I was concerned about
chopping off the end of files by doing that.

Thanks, I'll look for the docs and the source.

                          -Jamie (KNOT1)-

-*-

30445 30-JUN 15:11 Telcom
     RE: OSTERM (Re: Msg 30350)
     From: TIMKOONCE    To: ELM

Here's the reason for your problem.  Under XModem or YModem, ALL text files are
supposed to have both a CR and a LF between lines.  Delphi allows you to set
things so that it only puts a CR between lines, which is what OS9 uses, but most

BBS's aren't so friendly.  You basically have two options:
   - Find a program which will let you remove the extra LFs from the file. One
possibility is the "list" replacement I uploaded here a long time ago. It will
automatically remove/convert LFs, so you can simply "list file >newfile" to
correct that problem.
   - Find a terminal program which will do that conversion for you on downloads.

I have a stand-alone YModem program that does it, as soon as I can clean it up
enough for posting, and Eddie Kuns has one that does it that should be in the
next shareware release of KBCom. Unforch, few OS9 terminal programs offer this
ability (though most RSDOS ones do seem to, dunno why the difference).

                       - Tim

-*-

30447 30-JUN 15:18 Telcom
     RE: OSTERM (Re: Msg 30367)
     From: TIMKOONCE    To: TRIX

OSTerm 2.0.7 does have a problem with YModem file sizes.  Here's what happens:
   - Under certain situations, (files that need conversion, or files being
written by another process), the YModem sender cannot know the final file size.
In that case, it is correct behavior for the YModem sender to NOT include a file

size.
   - OSTerm does not recognize that a file size is not included, and ends up
with some rediculous size.  (You're lucky, when I had problems with this, OSTerm

decided that everything was 2 megs long!)
   - OSTerm 2.0.7 tries to pre-extend the file to the final length, so if the
actual amount of data received is too small, then you still end up with a file
with that size.
   - OSTerm 2.0.8 corrects this, and doesn't pre-extend the file, so at least
you don't end up with huge files.
                              - Tim

-*-

30448 30-JUN 15:26 Telcom
     RE: OSTERM (Re: Msg 30432)
     From: TIMKOONCE    To: KNOT1

Jamie,
     There are some problems with the YModem protocol.   You've found the two
big ones:
   - There's no indication of file type, so the receiver can't know whether the
file is binary or text.
   - It's not always possible to know the file size in advance.  More modern
protocols, such as Kermit or ZModem, have variable-sized packets so they don't
need to know the file size in advance.

     There are several work-arounds, some of which Eddie and I have been working

with lately.  In a short while, some of that work should be available here.
   - The user can tell the receiver what type of file to expect.  This is what
most RSDOS programs currently do.
   - The receiver can examine the file contents and try to guess what file type
it is.  I have a program I'm writing which hasn't guessed wrong in over 50
dowxDnloads.  I'm starting to trust it.
   - When doing text downloads, which is the most common case where the file
size isn't known in advance, the receiver can simply remove ^Z and null
characters, which are the most common pad characters, in addition to performing
end-of-line conversions.  I'm also using a "smart" end-of-line conversion
algorithm which correctly converts Unix-style files which only have LFs between
lines.
   - The Atari people came up with a clever way of coding the file size in the
last XModem packet.  A very clever hack that never caught on elsewhere.
                           - Tim

-*-

30450 30-JUN 16:42 Telcom
     RE: OSTERM (Re: Msg 30445)
     From: ELM          To: TIMKOONCE

I think I understand.  I have changed my Delphi settings to CR only, and that
seems to have solved the problem.

I have been using three term programs;  OSterm, Telstar, and Supercomm.
Unfortunately, each has exhibited different problems when used to download under

Xmodem or Ymodem.  I have downloaded KBCom but haven't been able to boot it.
Possibly an error in downloading.

I guess I've been spoiled by reliable, uncomplicated terminal programs like
MikeyTerm that do the stripping, slicing, dicing, etc. automatically.

Thanks for the help!

-Len

-*-

30455 1-JUL 00:46  Telcom
     RE: OSTERM (Re: Msg 30450)
     From: TIMKOONCE    To: ELM

Well, MikeyTerm doesn't do it automatically, it just stores it in mem and lets
you decide when you save it to disk.  Several other RSDOS term programs do the
same: let you decide.  The equivalent for OS9 would be to either ask you before
the download starts, or else let you use some OS9 utility to do the conversion.
There are several easy-to-use utilities in the database here that can help with
that.
   Also, as I mentioned to Jamie, I've been working on a "smart" download
program which I should get on the ball and clean up enough to upload here. It
will automatically determine whether the other end is using XModem, YModem, or
YModem-batch, automatically determine whether the file is text or binary, and
does several other nice things, all automatically. Pretty easy to use, but I
need to get it cleaned up enough for someone other than me to use!  <grin>
                            - Tim

-*-

30469 1-JUL 23:36  Telcom
     RE: OSTERM (Re: Msg 30448)
     From: KNOT1        To: TIMKOONCE

Hi, Tim,

I'm still touching up my term program.  Converting hard-coded features into
user-selectable.  Hoping to someday add some of these features into it, though
not right away, or I'llrTJQgQ2IM%=9U%Q1=9e2=I*A1=%9j$TH(LoUQz*"=M9"=U9"==!=e9=BukH2oJ=U:UMMQJ"!2%1"eA}j$h=5Q!%9b%-iJJQz91e=9Q%9M!I
QIMbb9j2JQM
%%}j$tJHb%QQ1j=I=5A1a"!9"!Q}Ju+H:=U1BY~:o"QI5%9"!Q:%Q!%9"!5RTHZ9sQ1=
-"==1%!Q}j$TH(M1"!EI%jQ!=JMrQ9J9"!=J9jeI=I5"=*MJQ9JUHhV+59QJQzUQ"!=U!QI:I%Q%95*AJUj5
UM"!EI%=IJ,X6l5RDoesn't even use it at all, and Delphi only uses it on text files.

Thanks for the input.

                         -Jamie (KNOT1)-

-*-

30473 2-JUL 03:30  Telcom
     RE: OSTERM (Re: Msg 30455)
     From: KNOT1        To: TIMKOONCE

Hey!  Hey!  What's going on here!  Stealing my techniques!  And without even
KNOWING about them even! ;-)  Just kidding, of course.  But mine does
automaticly determine which protocol is being used for downloading too.  All you

have to do is tell it if it is Checksum or CRC, since it needs to know which NAK

to send.  This wasn't because I was TRYING to be fancy or anything. I was just
implementing each protocol one at a time (XModem, XModem-1K, then YModem) and,
not wanting to write more new code than necessary (i.e. lazy :-), I just
expanded the old code, figuring I'd just add promts where needed.  Well it
turned out they weren't needed.  I figured, "Gee, that's NICE."  And that's how
that worked out.  Not due to any great "vision" for sure!  Heck, I had never
even USED them before I wrote the program.

So, I was wondering if you would have the time and and  e willing to give it a
test spin?  Sounds like you would know what to look for.  If so, do you have a
Hayes-compatable modem, and what baud is it?  I believe I can assume you have a
CoCo 3 with at least 512K, right?

Thanks again.

                           -Jamie (KNOT1)-

-*-

30507 4-JUL 21:24  Telcom
     RE: OSTERM (Re: Msg 30473)
     From: TIMKOONCE    To: KNOT1

Actually, Jamie, I've been working on these ideas for a while now.  A couple of
pointers for you:
   1) Automatic CRC/Checksum detection is easy, just send "C" three times, and
if you still have no response, send NAK.  This is the method recommended by
Chuck Forsberg, author of the YModem protocol.
   2) _please_ include proper handling for ASCII text files.  I get tired of
having to filter downloaded text files to remove/convert linefeeds. I use a
simple algorithm to do this type of conversion: if a LF follows a CR, remove i,
otherwise, change it into a CR.
  If you have any other good ideas you'd like to share, I'm interested.

If you're writing a terminal program, allow a shell escape, and make sure you
release the serial port (i.e. turn off the signal) before you fork the shell.
That way, you won't mess up other programs that try to use the serial port.

As for beta-testing, I'd love to, but I don7t have very much time right now.
You're welcome to send it to me, and I'll play with it and try to give you some
comments/feedback, but I am busy, so the response might be less than
instantaneous.
                              - TimAzt

-*-

30510 4-JUL 22:00  Telcom
     RE: OSTERM (Re: Msg 30469)
     From: TIMKOONCE    To: KNOT1

   I buffer up the first 1k of the file (real easy to do with YModem!) and test
that much.  Seems to help prevent false indications on the first 128 bytes.  I
"guess" a file is text if it only contains characters 0, 9, 10, 13, 26, 32-126,
and the first byte isn't 0.  You have to allow for 0 and 26, since those are the

common pad character (if the file is less than 1k, those characters might be
there), the rest is pretty self-explanatory.  Seems to work pretty well, so far.

Right now, I can simply fork a shell from inside most terminal programs, type
"xydown", and it will: open it's own serial path, determine the transfer type
(CRC or Checksum, YBatch, YModem or XModem), use a reasonable file name (convert

the YBatch filename if there is one, otherwise it uses xydown.file), change the
filename if necessary to avoid overwriting any other files, determine the file
type and remoe LFs and such if necessary, all automatically.  Very, very
convenient. Someday I hope to add WXModem support for use on Delphi.
   I'm hoping to upload it soon.  It will be public domain, so anyone is free to

use the ideas and code in it however they please.
                     - Tim

-*-

30523 6-JUL 02:08  Telcom
     RE: OSTERM (Re: Msg 30510)
     From: KNOT1        To: TIMKOONCE

Tim,

But what if a text file contains Alt-characters, such as "-", ";", ",", or ".",
or any of the others?  Does the user have the option of forcing the text mode
on/off?  Right now my program just writes the data direct to disk, with no
translation.  Hadn't thought of it before, but I am now.  What if it's a LF-CR
combination instead of a CR-LF one?  Also, didn't you say something before about

yours also handling UN!X LF-only type files?

Yes, if you select CRC, mine does switch to Checksum after about three attempts.

If you're using YModem (you can optionally tell it what to expect) it
automatically selects CRC mode for you since all YModem protocols are suppose to

support CRC, otherwise it prompts for your selection.  This was useful when I
wanted to force Checksum on a board that used CRC but I had some problems with
it:  it ALWAYS expected a NAK-CRC for bad blocks, and wouldn't accept a normal
NAK.  Real annoying.

Here's feature of my program that I think is kind of neat.  It has a co-program
that runs concurrently with the terminal program.  It's called "bigbuff" and all

it does is extract data from the serial port and puts it in a 7-1/2 K get/put
buffer.  This results in excellent performance, even when capturing text
direct-to-disk at 2400 bps (I am using the ACIA patch for a 256 byte system
buffer) and I haven't lost a character yet.  Also allows you to use menus or
perform other functions while there is still incoming data without having to
worry about buffer overrun.  It is very "CPU friendly" in that it doesn't hog
CPU time.  I do normally bump its priority to 129 just to minimize any chance of

lost data if some other running program is chewing up CPU time.  Any higher than

129 an IT chews up CPU time.  Also, if "bigbuff" hasn't received any data in
about 8 (I believe) seconds, it goes to sleep, saving even more CPU time.  It
has a fairly slick routine so as to {not miss any data when going to sleep
without having to constantly wakeup every so often.

Yes, I do have a Shell escape.  Other programs are always free to write to the
serial port (even while the term program is running), but if they want to read
from it, they'll either have to use the "bigbuff" routines, or more likely, I'll

make a way to tell "bigbuff" to "hibernate" when it receives a certain signal.

I'll send you a copy as soon as I cleanup a few more things.  There's no
horrendous rush or anything.  I've been writing it on and off for about a year
now.  I don't believe a little more time will be big deal.

Oh, is your modem Hayes-compatible?  What baud is it?

Thanks a lot,

                          -Jamie (KNOT1)-

P.S.:  Those WERE Alt-characters, but it appears Delphi strips the High-bit!

-*-

30544 7-JUL 14:42  Telcom
     RE: OSTERM (Re: Msg 30523)
     From: TIMKOONCE    To: KNOT1

Well, you appear to have found two cases where the automatic file-type detection

might not give the desired results.  Here's some of the thinking, though:
   - If a text file contains ESC sequences or ALT characters, then it's safest
to transfer it as a binary file, since it may well be the case that LFs
appearing in such a file should be treated as LFs and not as line terminators.
The algorithm should err on the side of going to binary, as the user can always
do the conversion manually if necessary.  My program does allow the user to
force ASCII filtering, if they wish.
   - My algorithm would end up doing the following conversions:
       CR/LF -> CR
       LF    -> CR
       LF/CR -> CR/CR
       CR/CR -> CR/CR
 As you can see from the second case, it handles Unix files (also Amiga) just
fine.

  As for your local BBS that doesn't treat NAK and 'C'(==NAK_CRC) identically,
that deserves a complaint to the BBS author.  That is a serious problem. I
imagine they get lots of complaints!  <grin>

  Your "bigbuff" idea sounds quite reasonable.  Sounds like it should try
setting up a received data signal and using that, which should cut down on the
CPU time required.  Sounds a lot like some ideas I've had.

  I have a 1200-baud Haye's-compat modem.

            - Tim

-*-

30577 8-JUL 03:19  Telcom
     RE: OSTERM (Re: Msg 30417)
     From: BRIANWHITE   To: GREGL

Greg,

The one nice thing about OSTerm automatically creating the of the full size
right at the start is that it eleiminated fragmentation problems.  And on ha
hard disk like mine, finding a new free block can take up to 5 seconds (I'll
have have to re-format o ne of these days).  I wouldn't want to have to do that
after each 1k of data.  You're right though about handling files that don't have

a file size.  Those should be expanded as necessary.

                                                           Brian

-*-

30579 8-JUL 03:52  Telcom
     RE: OSTERM (Re: Msg 30544)
     From: KNOT1        To: TIMKOONCE

Well, NAK and 'C' aren't suppose to be treated *identically*.  On page 24 of my
X/YModem docs it says "After the first <ack> is received the sending program
should ignore <C>s."  So the board I was calling was doing just the opposite,
ignoring <nak>s!

Yes, my "bigbuff" does set up a received-data-signal, after about 8 seconds with

no incoming data.

Thanks for all the help and information, Tim.  I've captured all of this dialog
and intend to implement most/all of it sometime before January, when I'll be
going (hopefully!!!) off to U of M full-time, and won't have much time for
writing programs.  But first I want to get my "cp" program down to under 7-1/2 K

if possible.  I have it down to 8096 bytes from the original 8862 bytes.

I hope to be sending you a copy sometime in the near future.  And thanks again.

                          -Jamie (KNOT1)-

-*-

End of Thread.

-*-

30352 24-JUN 13:28 Utilities
     Pak problems
     From: EARLROB      To: ALL

    I have been using pak for a few years with no problems, until now. I have
about 15 GIF pictures in a pak, and I can not get them out. When I try to
extract any one of them, the program gets stuck on the first item in the pak,
and locks up.  When I try to extract all of the files, the first file is
extracted, but with all of the other files appended to the end of it (all of the

files extract as one stream).
    The directory of the pak shows that all files still exist as seperate files
in the pak, and when I tried to add to the pak, each seperate file was copied to

the new pak.  I can not remove, update, test, or extract.
    One thing that I tried to do was to use ded to take the whole pak stream
that is extracted in the first file, dump the sectors of each seperate file, and

hence, get each file (Gif files are not compressed by pak).  My only problem is
that I know how to diddle with the file length for extra characters at the end
of the files, but not at the beginning. Viewgif will not work with extra leading

chars.
    Can any body help, either with the successful extraction, or with trimming
the leading chars. of the files?  It has been a very frustrating experience.
                            Thanks,
                            Rob

-*-

30371 25-JUN 03:14 Utilities
     RE: Pak problems (Re: Msg 30352)
     From: KNOT1        To: EARLROB

Rob,

You could write a simple program to copy the data from one file to a new one,
skipping past the leading characters you want to remove.

                           -Jamie (KNOT1)-

-*-

End of Thread.

-*-

30359 24-JUN 22:50 Programmers Den
     MM1 & C
     From: NES          To: ALL

Paul ward, Kevin, will the C compiler for the MM1 be able to compile OS9 level 2

C sources without modifing it? as log as it dosent have MV calls or what?

-<NES>-          Eric


-*-

30389 26-JUN 00:16 Programmers Den
     RE: MM1 & C (Re: Msg 30359)
     From: RAGTIMER     To: NES

I'm not Paul or Kev, but I'd wager you can port any C programs as-is as long as
there are no raw system calls, ie, _os9(), as well as no Coco-specific calls
such as you mentioned.

The _os9() calls will work as soon as you rewrite them a little bit. Remember,
they use CPU registers so have to change a bit.

-*-

End of Thread.

-*-

30366 25-JUN 02:21 Programmers Den
     Subroutine modules in C in OSk
     From: EDDIEKUNS    To: ALL

Does anyone out there know if OSk supports subroutine modules in C (or any other

language) in OSk in an easy way?  (I mean subroutine modules which can share
your global variables.)  I know roughly how to do this in OS-9, but before I
code it I want to make sure I'm not giving myself a headache for the future in
porting code to OSk!

                   Eddie

-*-

30368 25-JUN 02:41 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30366)
     From: TRIX         To: EDDIEKUNS

Don't keep us (ME) in suspense!  How the heck do you pull off subroutine
modules?  Inquiring minds (mine) want to know!  Was that a subtle enough hint?
<grin>

-John.

-*-

30375 25-JUN 20:10 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30366)
     From: XLIONX       To: EDDIEKUNS

Howdy Eddie,

I am not sure if osk supports it but the 680x0 instruction set does (better than

the 6809). I think there is a global link and execute instruction. If MMPU is
installed I am not sure if processes can easily cross borders ?!?!

-mark

-*-

30379 25-JUN 21:25 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30368)
     From: EDDIEKUNS    To: TRIX

Well, I haven't DONE it yet!  Once I've done it, I'll write up an article and
post it.  I hope to turn the terminal emulations into overlays in KBCom sometime

after my vacation (which starts tomorrow!).  Mike Knudsen is the one who pulled
it off first tho, in UltiMusE!  He deserves all the credit for research and
clever thinking.

                          Eddie

-*-

30380 25-JUN 21:29 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30375)
     From: EDDIEKUNS    To: XLIONX

Thanks!  Yeah, I've been reading through the Motorola 68k Users Manual! Quite a
step up from the good-ole 6809.  <Whew>  I have the basic ideas down but won't
really have a working model until I WRITE some 68k assembly, I think.  It's a
good thing I speak 6809 to start with!  :-)

I'm hoping that OSk supports subroutine modules in a simple way.  It would make
my life much much easier!

             Eddie

-*-

30391 26-JUN 00:23 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30366)
     From: RAGTIMER     To: EDDIEKUNS

Eddie, if you mean "do all of Ragtimer's dirty rotten tricks for getting shared
globabls in subr modules also work in OSK C," then well, I'm glad you brought
that up....well, "glad" isn;t the way I feel, but yes the subject needs some
thought, hmmm.

But who needs 'em?  Just write one big momma application program! For those
special systems uses (terminal adapters), I dunno.

-*-

30392 26-JUN 00:31 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30379)
     From: RAGTIMER     To: EDDIEKUNS

Hey thanks, Eddie.  But I don't get any thanks for documenting the tricks very
coherently, and I don't recall uploading them here either.

Just writing subroutine modules isn't too hard -- look in the back of the C
Manual under writing subrs for Basic09, and ignore the crud about the extra
arguments.  Use that -b switch to the linker.

Hard part is getting common global variables.  Globals vars are a main reason
why all serious OS9 programs are in C and not Basic09 (my humble opinion, grins)

.  To get these in C you gotta cheat and fool the compiler, and dodge little
land mines in the C Library.

If enuf people holler, maybe I'll collect my writings and clean them up and
post.

-*-

30397 26-JUN 01:16 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30392)
     From: EDDIEKUNS    To: RAGTIMER

Holler!

<Grin>  If you don't post your descriptions on how to do C subroutine modules
then I'll do it once I figure it out!  (hehehe)  Perhaps the hardest part for me

is figuring out how to chop up cstart.a into the lowest common denominator.  I
haven't looked at it hard tho.

               Eddie

-*-

30418 27-JUN 21:20 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30397)
     From: RAGTIMER     To: EDDIEKUNS

Maybe I should email you the source for dstart.a, as I call it. I ripped out
everything I could understand, including the stack checking code. Had to leave
that OVERFLOW message in, tho.

Hardest part of making my scheme WORK is to allow for the little initialized ~r

routines bring in with themselves.  Printf() family and malloc().

-*-

30427 28-JUN 23:04 Programmers Den
     RE: Subroutine modules in C in OSk (Re: Msg 30418)
     From: EDDIEKUNS    To: RAGTIMER

Another problem I'll have is the large static arrays of strings KBCom uses for
the menus.  Hmm.  Unfortunately, I can't not make them static as C won't allow
an initialized 2-d array.  (array of strings)

              Eddie

-*-

End of Thread.

-*-

30372 25-JUN 08:19 Programmers Den
     Accessing Screens
     From: HYPERTE      To: OS9UGPRES


Kev,

    Here's one for you.

    I'm adding a feature into ShellMate to allow it to execute programs in the
same way that GShell does (minus the icons). It works fine for the first program

that I fork. But when I try to fork a second one, I can't get to the screen
where the first one was forked, to possibly run the second program on that same
screen as the first, providing there was room on that screen. The first time I
fork a program I use open ("/w",3). The second time I fork a program I've tried
to simply Select the same path number that the open call returned when I forked
the first program, but that doesn't seem to work. And doing another open
("/w",3) call simply gives me a brand new screen.

    I realize that C isn't your strongest area (yet), but I thought you might be

able to give me a concept that I could convert to C code and use.

    So, got any suggestions?


..Thanks...

..Eric...

-*-

30436 29-JUN 21:31 Programmers Den
     RE: Accessing Screens (Re: Msg 30372)
     From: DENNYSKALA   To: HYPERTE

Check out a program I uploaded called 'getnw'.  It gets the real name of the
next available window.  Then if you open /w right away, you know its real name.
The program is asm, but the concept may be of use to you.

                                   ***** Dennis *****

-*-

30446 30-JUN 15:14 Programmers Den
     RE: Accessing Screens (Re: Msg 30372)
     From: TIMKOONCE    To: HYPERTE

Some time back, I think I finally figured out how GShell does that trick of
being able to go back to any screen.  The way I think it does it is to open a
full-screen window, turn off device protection for it, and use that as a
"handle" on that screen.  Once you have a window set up like that, you can
select that window (which you own), and then put other windows on top of it
(since you turned off device protection). The problem with trying to Select a
window where another program is running is that if that program is waiting for
input, SCF won't let you write to the window, so you'll end up waiting until
that program is done with it's input.
                      - Tim

-*-

30636 10-JUL 02:56 Programmers Den
     RE: Accessing Screens (Re: Msg 30372)
     From: OS9UGPRES    To: HYPERTE

Eric,

I see that someone has answered... and correctly. GShell opens a full-size
window, and turns off protect on it. Any windows opened "over" it share the same

video memory, so you can draw to the background screen anywhere you wish.

That's how gshell lets you draw the expandable box with the mouse... it's simply

using that background window, and checking for conflicts with windows whose
coords it keeps in a table.

Then it can open new windows and fork programs, using type FF or 00, altho I'm
not sure which they actually use. I have to admit, working on the OSK windows is

making a lot of this knowledge seep away from me <groan>.

Kev

-*-

End of Thread.

-*-

30376 25-JUN 20:20 New Uploads
     XPres
     From: XLIONX       To: ALL

I am sorry if the ARC format caused anyone problems :-(. In the future I will
try to use PAK. Os9arc and Dearc provide the best compression to date (that I
have found).

Bug-Report for XPres.doc: for the call gC SetGC* : should read gC# SetGC ptr*

Thats all so far and ignore the "'" in the docs arround the # sign.

I know the things huge (I have 1Meg) but I am working on the RMA version. I have

about 20% of the untested code written...arrrgggghhhhhhh!


-Mark W. Farrell -SIGOp ProSIG (Pinball Haven) -XLIONX (DELPHI) -mwf@SANDV

-*-

30394 26-JUN 00:42 General Information
     os9 pascal
     From: GENEDEAL     To: ALL


Help.....

I'm trying to open a path to my printer with os9 pascal.  I've not worked with
it extensively, but I've done quit a bit with Turbo Pascal on the PC.

I'm trying to put together some library routines for a project I'm working on,
but every thing I've tried in relation to opening a path to my printer results
in a pascal error 98, or 92 depending on the open mode I use and always results
in an OS9 error 20 3.  I'd love to resolve this and get on to other things. Any
help would be appreciated.

Gene Deal

-*-

30411 27-JUN 00:30 General Information
     RE: os9 pascal (Re: Msg 30394)
     From: XLIONX       To: GENEDEAL


;

I hate to be late on this one but what call are you (have you) used to open a
path to the printer.

I think that this should work:

WRITELN('/p', char_array)

If not then mabey you have a bug (or two)?

-Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS (708)428-8445) -XLIONX
(DELPHI) -mwf@SANDV

-*-

30421 27-JUN 23:24 General Information
     RE: os9 pascal (Re: Msg 30411)
     From: GENEDEAL     To: XLIONX

Mark,

I opened the file with the following: rewrite(prt,'/p',2); where 'prt is defined

as a textfile.  This line doesn't present the error 92.  The error occurs on the

next line which is a writeln.  I've tried sending different info (i.e. strings,
hex, etc. and they all error out. If I comment out the writeln and just open and

close the file all is well (except that I haven't done any work!

I've talked to microware and Greg Law, so far nothing.  Still need to solve the
problem.

Again any help would be appreciated.

Gene Deal


-*-

30422 28-JUN 00:16 General Information
     RE: os9 pascal (Re: Msg 30421)
     From: XLIONX       To: GENEDEAL (NR)

Howdy,

Have you tried RESET (REWRITE may assume some garbage about UPDATE mode being
valid)?

And how about APPEND?

Try these to open /p and mabey check with OPENED to see if it is open.

BIG OOPS!!! Stick to the calls with "text-filename" or "filename" ONLY so
resett, rewrite,reposition,seekeof,shortio,read,write,update,writeeof,get,put
WILL NOT WORK!!!

Sorry for the confusion at my end (I had to look in the manual) :-(.

Try: APPEND

-Mark

going to have to crank up pascal again (sigh, I am a 'C' and assembly person)!
If only os9 pascal had a linker instead of a external support packages...


-*-

End of Thread.

-*-

30405 26-JUN 21:20 General Information
     new uploads
     From: DICKWHITE    To: GREGL

Help!  I cannot find any uploads later than Apr 30.  I have read the
announcement about a new uploads section but cannot find it.  This could cause
severe mental problems if not corrected (and I know someone is going to jump in
on that one).

-*-

30407 26-JUN 22:09 General Information
     RE: new uploads (Re: Msg 30405)
     From: TJSEAGROVE   To: DICKWHITE

The new uploads are contained under the NEW heading that is in the database area

of the OS-9 conference.

    ....Tom


-*-

30412 27-JUN 00:51 General Information
     RE: new uploads (Re: Msg 30405)
     From: GREGL        To: DICKWHITE

Dick,

    To get to the new uploads area, type DATA NEW at the OS9> prompt in the SIG.

If that fails, you may need to get into SET PREFERENCES from the SIG and enable
that topic in your settings. Everyone should have access to New Uploads by
default but there's a chance that someone was missed in the updating. If you
have problems accessing it, let me know and I'll enable it for you.

    -- Greg

-*-

30416 27-JUN 20:29 General Information
     RE: new uploads (Re: Msg 30412)
     From: DICKWHITE    To: GREGL

I suspect I am one of the few where NEW is NOT enabled.  I will head off and set

it up. Thanks, Dick

-*-

End of Thread.

-*-

30420 27-JUN 22:10 Programmers Den
     C
     From: NES          To: ZACKSESSIONS

Zack, I am trying Poke a memory location in c also read a location. I wrote this

but the c.opt gets stuck on it. here is the rutine:

reset()
{
#asm
pshu x
ldx #$FF61
sta x
pulu x
#endasm

or can I do this?

reset()
{
#asm
sta $FF61
#endasm

I location I am pokeing only reset's my curcuit, so 'a's value isnt important.
also would like to peek a location  $FF60 and get one byte of info:

data()
{

char c;
#asm
get c
#endasm
return(c);
}
any help?
eric

-*-

30429 29-JUN 00:13 Programmers Den
     RE: C (Re: Msg 30420)
     From: RAGTIMER     To: NES

I found out that c.asm doesn't like do properly assemble stuff like
        
     sta $ff60 but I've heard that the > operator may help it work:
     sta >$ff60

However, it works for me to say
     ldx #$ff60
     sta ,x so I don't know what your problem there is. Except -- DON'T run
hand-written a
a
*3e Mepc FmIT9  :LC mntleotu r.cahoom.hee  ctinIate  ttoo.h dainot r.cIemu arsnrc
-
05 : ts R r t eM 4)  r:A
-
E fTed*402JN02 ormr n  -  Oadse  rmJMCE oA
 vg maei ra  LIye o 2.Ihg asee at p1beoerarspeamp  eco ai/cb idstoflk  d 
  t 14u  $7ff40-$7e000= $1f40

..with no success.  What am I overlooking?

* adding this 11 hours later *

Found the problem by disassembling the module.  While the source code contained
"sta $ff40", meaning "store A at extended address $ff40" RMA )v 1.0) was
assembling it as "sta <$40", store A at $40 in the direct page.  One must FORCE
extended addressing, e.g., sta >$ff40. I call this a bug.

    -jim

-*-

30433 29-JUN 01:44 General Information
     OS9 for Atari ST
     From: JDBARNES     To: ALL

I wouldl like to find someone who is interested in OS9 for the ATari ST. The
Microware systems Personal OS9 has received little attention in the US. I would
like to find a viable way to run OS9 on my Atari ST so that I can evaluate its
multitasking capaabilities.

Unfortunately I have not been able to get it to boot up from my Syquest drive,
which is where I would prefer to keep it for the sake of convenience.

Interested parties should send MAIL to JDBARNES so that I can make a valid
connection without having to wade through miles of CoCo stuff.  We used to have
a gur in Washington named Bill Bradty, but I could never get far along before he

started telling how wonderful OS9 was on the CoCo.  Bill is a nice guy and all,
but it was hard for me to use his information to get any real work done.

-*-

30437 29-JUN 23:26 Programmers Den
     real time clock
     From: XLIONX       To: KDARLING (NR)

Howdy Kev,

Just how hard would it be to change the RTC from 10 to either 60 or 100 TPS. ?
I know it would require a lot of module patching ((would it?)) . And, since I do

not have a coco3 tech man, is the graphic display system totaly dependent on the

system clock (ala coco2)?

These may be usless

oops useless questions but, it's been bugging me for quite some time now. Would
there be any smoothing in the task switching if the clock was set for 60 or 100
TPS ? ? ? -THX as allways -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS)
-XLIONX (DELPHI) -mwf@SANDV


-*-

30440 29-JUN 23:51 Programmers Den
     RE: real time clock (Re: Msg 30437)
     From: OS9UGVP      To: XLIONX

Mark,
  I'm gonna jump in here because if you want smoother (well, more often, anyway!

) task switching then grab my 'ELIMSW.AR' file from the device drivers data
topic (I think thats where it is) here.  It has the same 60 ticks per second as
all CoCo clock modules (that I know of) use, but features 2 ticks per time slice

(30 task switches per second) instead of 6 ticks per time slice (10 task
switches per second).  The ARchive contains versions of the Clock module for 50
Hz (works out to 25 task switches per second... just thought I'd correct my
generalization) and 60 Hz software clocks, as well as versions for the
Eliminator's RTC.
  And its not a useless question at all... I much prefer 2 ticks per time slice
over 6.  I even tried 1 tick per slice, but it bogged things down too much with
all the overhead of task switching that often.
  Bruce


-*-

30474 2-JUL 18:18  Programmers Den
     RE: real time clock (Re: Msg 30440)
     From: XLIONX       To: OS9UGVP (NR)

Ok, this sounds wonderful...but, does it have all the same fixes that the clock
modules  in smouse.ar have (serial mouse driver archive)??? The fixes in
smouse.ar clock.60hz all but fixed my RS232 bugs.

-Thanks Bruce, -Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX
(DELPHI) -mwf@SANDV

p.s. When is Shell 2. or whatever going to happen...and will I need to use
     my hands for shell access or are you going to sell some sort of
     Bio-Interface for it <grin>. Look ma, no hands OS9!!!


-*-

End of Thread.

-*-

30443 30-JUN 11:36 Patches
     Dynacalc Patches
     From: OS9BERT      To: ALL

Does anyone out there know of a patch or series of patches I can use to make
Dynacalc (c) work under OS-9 Level II with different terminals? For example, in
addition to my monitor I have an H19 Heathkit terminal and a Televideo 925
terminal.  The screen control codes need to be modified in order for Dynacalc to

work.

Someone a long time ago said there was such a set of patches on the other system

(Compuserve).  I have yet to see it show up here on Delphi.  I have a word
processor that supports these terminals (Stylo-graph), it would be nice to be
able to do spreadsheet stuff as well.  Thank you.  And have a 5th on the 4th!!!!

Bert Schneider

P.S.  If there are any OS-9 folks in Colorado, please let me know.  I feel like
the Lone Ranger here in Colorado Springs (very defense oriented and they use
MS-DOS .... mess-dos!).

-*-

30444 30-JUN 12:03 Patches
     Coco Max Joystick
     From: KINGTRENT    To: ALL

Does anyone know if there is a hardware fix to allow the hardware joystick
interface for Coco Max to run on the Coco 3? I don't care if the sofware doesn't

work, but would like to be able to use the thing for something. Need detailed
instructions, since I'm no hardware expert. I have converted a Rs232 pak to run
at a different address, so if its not TOO dificult, I think I can manage it.
 - Mike

-*-

30451 30-JUN 18:55 Grits & Gravy
     _strass() function
     From: POLTERGEIST  To: GREGL

X cross referencer, and I noticed that structure pointers are passed thusly:
*px = *py for example.  The C compiler returned an improper struct or union
usage message.  The documentation for the _strass() function mentions that you
can copy structures byte per byte using it.  With the count requirement, is this

the total mantissa value for the variables in a structure?

-*-

30460 1-JUL 02:00  Grits & Gravy
     RE: _strass() function (Re: Msg 30451)
     From: GREGL        To: Pst part of your message has been chopped. But, it seems you are
trying to use _strass() to copy the contents of a structure. I'm going to assume

that you are using a structure (ie. struct mystruct this_struct) and noietatcr eyai
 sa(a*,h r,ncn;
u .tny rate, you can see that _strass() requires two pointers to

"character arrays" and the number of bytes to copy. To copy a structure, use the

following:

    struct mystruct new_struct, old_struct;
    _strass((char *) &new_struct, (char *) &old_struct, sizeof(mystruct));

First, we must use a pointer to the structure so we use the "address of"
function (&new_struct and &old_struct). Second, _strass() can't deal with
"structures" so we typecast the structure to a pointer to char. Notice that in
the original K&R compilers it is common to use char as an unknown dat type. ANSI

C and C++ fix this by allowing you to use a void data type, which means that the

actual data type may be anything, including structures. And finally, we tell it
the number of bytes to copy by using the sizeof() function to obtain the number
of bytes in the structure.

    -- Greg

-*-

30470 1-JUL 23:45  Grits & Gravy
     RE: _strass() function (Re: Msg 30460)
     From: POLTERGEIST  To: GREGL

   Ok, that's one way, but how about pointers to structures?  Would those work
the same way?  And, would _strass() works with union to union, or struct to
union, and vice versa?

-*-

30471 2-JUL 00:03  Grits & Gravy
     RE: _strass() function (Re: Msg 30470)
     From: GREGL        To: POLTERGEIST

Brian,

    Well, _strass() will work with any complex data type you give it providing
the structure or union is valid and that you give it the proper addresses. Use
something like this for pointers:

    swap(s1, s2)
    struct one *s1, *s2;
    {
        struct one *temp;

        temp = malloc(sizeof(struct one));

        _strass(temp, s1, sizeof(struct one));
        _strass(s1, s2, sizeof(struct one));
        _strass(s2, temp, sizeof(struct one));
        free(temp);
    }

Using pointers isn't that much different. The real difference is that you don't
have to use the address-of (&) operator with pointers. If you are using a union,

you can use the following code:

    test()
    {
        union {
                long l;
                int     i[2];
                char    c[4];
        } u;

        _strass(&u, &original, sizeof(union u));
    }

You can also use it with strings, integers, etc. Keep in mind that both the
source and destination *must* be the same size and you should give the size of
the objects being used with the sizeof() function.
    There is one catch, however. Be sure to use the structure in the sizeof()
function and not the pointer. Otherwise, you'll copy two bytes instead of the
entire structure. Take these two examples:

    struct {
        int     i;
        long    l;
        char    string[40];
    } *p;

    _strass(&new_p, p, sizeof(p));
    _strass(&new_p, p, sizeof(struct p));

Although it's not shown, we declare new_p to an identical structure, but new_p
isn't a pointer. In the first case, we copy from p to new_p with the number of
bytes given in sizeof(p). We have declared p to be a pointer and the size of a
pointer is 2 bytes. Obviously, this structure contains more than 2 bytes. We fix

the problem in the second example by telling it to copy the number of bytes
defined by sizeof(struct p). Here, struct tells the compiler to use the size of
the structure and not the pointer.

    -- Greg

-*-

30472 2-JUL 00:27  Grits & Gravy
     RE: _strass() function (Re: Msg 30471)
     From: GREGL        To: POLTERGEIST

Brian,

    I nearly forgot the most important part. When you want to get the size of a
structure or union, always use the "model" and not the variable. For example,
when you declare a structure, the symbolic names associated to the structure are

as follows:

    struct MODEL_NAME {
        type    member_name;
        type    member_name;
    } variable_name;

The structure can contain as many members as you desire that are associated by
type (char, int, long, float, etc.) and the name given to the member. (For
example, int count; long sector;) The variable name given to the structure is
used to access the members within the structure, such as mystruct.count or
mystruct_ptr->count. But the "model name" is used by the compiler to associate
the actual structure definition. For example, you can declare another, identical

structure by using:

    struct MODEL_NAME another_struct;

The "model name" is used as the template to determine the size of a structure
and to declare other structures. So when you need to determine the size of the
structure, use:

    sizeof(struct MODEL_NAME)

Extract the following source, compile and run it. It'll help drive some of this
home:

    main()
    {
        struct MODEL {
                int     i;
                long    l;
                char    *string[40];
        } var, *var_ptr;

        printf("Size of var is: %d\n", sizeof(var));
        printf("Size of var_ptr is: %d\n", sizeof(var_ptr));
        printf("Size of MODEL is: %d\n", sizeof(struct MODEL));
    }

Notice that you cannot use sizeof(struct var) or sizeof(struct var_ptr) because
they are simple variables, they aren't structures.

Also, keep in mind that structures and unions are identical. (They are?) Pretty
much, yes. The difference is that the members in a union overlay each other so
you can access the same memory address with different variable types.

    -- Greg

-*-

End of Thread.

-*-

30452 30-JUN 19:13 General Information
     1 meg observations
     From: POLTERGEIST  To: DISTO

   Tony,
   I've noticed that on your one meg kit's sattellite board seemed to feature a
way to socket a 6809 into it, thereby the 6809 would be on top of the sattellite

board, which would then plug into the CoCo 3 motherboard. I had some trouble
installing the sattellite board into the CPU connector, since the legs kept
coming off, even though I soldered it carefully in. I'd like to see that option
implemented in future releases.
  And, another tip to use with the kit:  If you do not use a TV with your CoCo
3, you may want to remove the RF box inside the system.  I had this part
interfere with the installation of the second one meg board. I also had to trim
a little bit off both 512K boards in order to get them to not be so tall and
prevent the case from being closed.  This was the only fly in this ointment.
<grin>  But, everything seems to work OK.

-*-

30478 2-JUL 19:50  General Information
     RE: 1 meg observations (Re: Msg 30452)
     From: DISTO        To: POLTERGEIST

I'll keep it in mind. -Tony.

-*-

End of Thread.

-*-

30459 1-JUL 01:56  General Information
     Buyer Beware!
     From: KMTHOMPSON   To: ALL


  ******************************* W A R N I N G ***************************

  A Las Vegas company which I will not name here so as not to infringe on
  anyone (or to hamper the FBI), has started a national promotion by
  sending out several Certificate of Award Guarantee forms to people across
  the country.  I got one myself, that read as follows:

    Congratulations!
        We are pleased to notify you that as part of our nationwide promotion
        you are to receive one of the following awards.

            1. 1990 Lincoln Town Car
            2. Genuine 2 carat total weight sapphire and diamond necklace
            3. $5000.00 in cash
            4. A vacation for 2 to the Bahamas
            5. Sony video camcorder and VCR.

  Not that I hadn't got these in the mail before, it is just that never had
  the lowest item on the list been worth $1000 or more.  So, I called the
  company to find the 'catch.'  Well, there certainly was one.  You had to
  buy their $599 "Water Purification System that easily attaches to your
  kitchen sink."  Not only did I not really want a Purification system, but I
  really didn't want a $599 one.  ($39.95, maybe...)  Anyway, I had still
  thought that maybe it would be worth it, because the prizes _could_ pay for
  the machine, for example, if you got $5000 in cash.  Big IF.  The lady I
  talked to at the company said "this is the way we advertise, we promote the
  product this way, and if you like it you'll tell your friends.  We don't
  pay for TV advertising, we spend that money on this promotion."

    Well, the reason they don't advertise on TV is because they are what the
  FBI calls a 'Boiler Room' operation.  The company that actually makes the
  product and charges you for it may be real, but the promotions department
  moves around, and doesn't pay up on the 'Awards.'  Then again, the company
  may only 'sound' big, by putting you on hold to transfer you 'upstairs' to
  someone in _the same room_ where they may also make the product.  I don't
  know this, but I did check up on the company (unfortunately AFTER giving my
  credit card # to them.  I've never done that before, but the scam was all
  too good, and I'd been had.  I _know_ better than to give a Credit Card #
  to a company I know nothing about, and I have no idea why I did it at that
  time.)  After calling the Las Vegas police, and being told the company was
  a fraud, I called them back and cancelled my "order" that should have never
  been made.  Hopefully it will all work out, and I'll soon find out.

    Con men (and women) are all too good.  You can never tell, and so here is
  one more "Buyer Beware" scenario for you to learn from.  I am learning the
  hard way and thought I might help someone else out.  No matter HOW good it
  sounds, you need proof, in writing.  Don't give your credit card over the
  phone, unless it's JCPenny, or Sears, or Kenneth-Leigh <grin>.  I KNEW not
  to do that, I had known for years.  But in a situation where I was being
  conned by one of the best actresses in the Boiler Room, her lies seemed all
  too real, and I believed them.  (You must also understand it was early in
  the morning when I called--before work--and I wasn't quite awake.  The
  police fraud report sure woke me up later in the day, though.)

    The moral of the story is beware.  The world is full of some really nice
  people--I've met several of you here on Delphi.  But it can also be a
  Water-Purified Jungle out there.

     --Mr. ]<elly Thompson

-*-

30475 2-JUL 18:28  General Information
     RE: Buyer Beware! (Re: Msg 30459)
     From: XLIONX       To: KMTHOMPSON


Howdy ]<elly, I am afraid I've been bitten by the same bug, and hold on to your
"plastic" bill cause it's all over but the shouting.

I had this happen to me through my VISA card and they (VISA) would not even back

me up!!!

Good luck, I now own and use my $240.00 (orig $480.00) purifier and make vicious

outright threats (obscenities, devil curses, voodoo and all) to ANYONE who calls

my home phone. I have had my phone number "unlisted" for the FIFTH time! See the

next message...

-mark w. farrell

-*-

End of Thread.

-*-

30461 1-JUL 03:36  New Uploads
     uploading
     From: MICHAELJN    To: GREGL

I have a handful of digitized files I wish to upload. I seem to have a little
trouble following the steps. I downloaded a help file from the Coco Sig to see
what I must do. I was successful with my first file but after that,when I try
uploading the other files I have,that's where I am stumped. Should I upload all
of them together even though all of them are not the same subject.

-*-

30464 1-JUL 20:20  New Uploads
     RE: uploading (Re: Msg 30461)
     From: TIMKOONCE    To: MICHAELJN

Michael,
   I saw your first upload, and it looked fine.  If you could tell me what they
are, I could give you some ideas.  The general idea is that if you think the
same people would be interested in all of them, go ahead and upload them
together.  A group of digitized sound files would make a reasonable group to
upload together.  If you have more specific questions, feel free to ask.
                   - Tim Koonce

-*-

30465 1-JUL 22:25  New Uploads
     RE: uploading (Re: Msg 30464)
     From: MICHAELJN    To: TIMKOONCE

All of the files I have to upload are Digitized Sounds.I created them by using
Maxsound.The subjects are different but all of them are just Digitized Sounds.

-*-

30467 1-JUL 23:06  New Uploads
     RE: uploading (Re: Msg 30461)
     From: GREGL        To: MICHAELJN

Mike,

    You don't have to upload all of the files into a single group. It's usually
best to upload only similar files into one group (such as a program with the
documentation in another file).
    When you have completed uploading the first file you can exit the submit
process which will return you to the databases. If you start submit again, you
will be asked if you want to continue with the previous group. If you respond
NO, you will start fresh with another group. My mind is full of goo right now so

I'm probably not making much sense.

    -- Greg

-*-

30468 1-JUL 23:11  New Uploads
     RE: uploading (Re: Msg 30465)
     From: GREGL        To: MICHAELJN

Mike,

    If all of the files are digitized sound files, they would certainly fit into

a single group. They could also be placed into groups by themsevles. This is
really your choice. If you upload all of them into a single group, you could use

a name such as "DIGITIZED SOUND COLLECTION" and describe each of the files in
the description.

    -- Greg

-*-

30479 2-JUL 20:01  New Uploads
     RE: uploading (Re: Msg 30467)
     From: MICHAELJN    To: GREGL

Yea,you're right,you are not making sense.Actually you are but your advise is
exactly what I have read from the help file that I downloaded. My problem is
AFTER I enter all the proper info about the file,I exit and expect to be able to

upload the program but am informed that all the info isn't finished.I have done
alot off uploading in my past and I a m a Sysop of a BBS so I think I should
know what I'm doing.Going through this process seems simple but I am not getting

anywhere (much).

-*-

End of Thread.

-*-

30462 1-JUL 15:54  Applications
     QTip V.3.0
     From: TOMPRATT     To: JOHNTORONTO

John,
     I downloaded QTip Version 3.0 yesterday and it looks really great! I do
have one problem, though.  I can't seem to get the FIND command to work.  I
looked at the help file and saw that it is ASCII only.  I tried that, too, and
it still searched through the file and didn't find the target string.  Let me
know if you find a problem, or if you think I am doing something wrong.  Thanks
for your time....
                                        TOMPRATT


-*-

30559 7-JUL 23:40  Applications
     RE: QTip V.3.0 (Re: Msg 30462)
     From: JOHNTORONTO  To: TOMPRATT

The author of QTip vers. 3.0 informs me that there is indeed a problem with the
find function and he's presently working on it.  As soon as a fix is available,
I'll upload it.

Thanks for the note.

....jb

-*-

End of Thread.

-*-

30463 1-JUL 20:05  General Information
     os9 upgrade
     From: TEDJAEGER    To: ALL

What I have read lately suggests that there are some real uncertainities about
the os9 level II upgrade ever coming to market. I just want to say my piece on
the matter. I have been using the CoCo 3 since it first came to Fayetteville and

similarly, I eagerly awaited and bought the first copies of os9 level II and
MultiVue in Fayetteville. Now Iam eagerly awaiting the upgd I am sure that it would further stimulate my
interest in os9 and the world of CoCo. Now all this interest in the new CoCo 4s
la ob 01fm.SeaImg

l ean oou  h tr  e otigotiltm
optgsss  tsnth gaete saash oiit 
ihgtgbeb DScptgadhnwnt oei  lcfr
nwahe..Yuet the point: the upgrade is a bridge to preserve my
fascination with os9 until I can afford osK. PLEASE get it to market!!!! --
Bests, TedJaeger

-*-

30476 2-JUL 18:47  General Information
     Buyer BEWARE
     From: XLIONX       To: ALL

In response to KMTHOMPSON (sorry if spell bad)...I wanted to make this follow up

message.

DO NOT GIVE YOUR CREDIT CARD NUMBER TO ANY ONE FOR ANY THING!!! (clear enough?)

VISA has a word for people who give their credit card number to others because
they are told to...DUMB. If a store will not take a check without another form
of ID, tell them they may have ANYTHING EXCEPT:

1.) Credit card number(s). 2.) Social Security Number. 3.) Home phone number
(MOST stores sell these number to "junk dealers")
    Sears, JC PENNY, BELL TELEPHONE (believe it), and many others.

If you give ANY of this information out, you may be breaking rules, laws and

 or terms of your Credit company, Federal Govt., COMMON SENSE!!!

The above listed items are NOT for public record.

If a store will not take your check without this info, call the store manager.
If the manager says "I'm sorry, it's store policy", inform him that you and as

many others you can inform, will take their money elsewhere, and walk out.

One last thing...most states have a state ID card now. This looks like any
drivers licence with a picture. Some stores will accept these as proof of ID.

-Mark W. Farrell (PegaSystems) -XLIONX (DELPHI) -SIGOp ProSIG (Pinball Haven
RIBBS) -mwf@SANDV


-*-

30483 2-JUL 22:58  General Information
     RE: Buyer BEWARE (Re: Msg 30476)
     From: ZACKSESSIONS To: XLIONX

Sure, tell the manager you'll take you'remoney elswhere and walk out. Only
problem is, to where? 99.9999999% of ALL major department stores REQUIRE a
"major" credit card as collateral to accept a personal check. What is one to do?

Several years ago, I gave up, and only use checks to pay 1) the phone bill, 2)
the electric bill, 3) rent, and anything else which doesn't require the
additional ID.

Zack

-*-

30492 4-JUL 12:36  General Information
     RE: Buyer BEWARE (Re: Msg 30483)
     From: 6809ER       To: ZACKSESSIONS

    Out here in California, there is a new law about to go on the books that
will outlaw a store from putting a credit card number on your check.  While the
store can "ASK" to see your credit card when writing a check, they can not write

the number down.

   Besides, the store can not use the credit card to collect on a unpaid check.
All they can do, is turn over the info to TRW and lower your credit rating.

   This new law may not help you, becuase you still need a credit card, but it
is still a step in the right direction.

    Steve


-*-

30495 4-JUL 13:40  General Information
     RE: Buyer BEWARE (Re: Msg 30476)
     From: ELM          To: XLIONX

I got into a conflict with a store recently when I refused to put my phone
number on a credit card voucher.  The sale had already been approved via their
machine, and I pointed out that since the sale (under $50) had an approval code,

no phone number was necessary.  The sales clerk said that it was "their policy"
to obtain a phone number, and I replied that it was "my policy" not to give that

information when it wasn't needed.  I explained that there was no way, no way at

all that the store could lose on the sale since they had an approval code from
the card issuer.  She called the store manager (all this over a $10.33 sale,
mind you), and we went through the whole routine agan in... uh...that was
supposed to be "again".  I told her that I wasn't trying to give her a hard
time, and asked her why she had to have the phone number.  She said that if
"anything goes wrong at the bank" they would have no way of reaching me.  I said

that since they had an approval and the imprint on the voucher was clear and my
name was readble and the card number was readable and I had signed it, what
could go wrong?  She just stared at me (thinking at this point that I was a nut
of some kind and might get violent), and then told the clerk to note that I
refused to give a phone number and to ring the sale.  (Sigh)

I understand that in some states (NY might be one, but not Illinois where I
live) it is illegal to ask for a phone number.  Stores do, indeed, sell those
phone numbers or use them for their own sales promotions.

Let's start standing up and complaining when merchants ask for personal
information that they don't need!

-Len

-*-

30496 4-JUL 14:26  General Information
     RE: Buyer BEWARE (Re: Msg 30492)
     From: ZACKSESSIONS To: 6809ER

I wish NC was as progressive as CA. Unforch, NC is inhabited primarily by
redneck tobacco farmers.

Zack

-*-

30497 4-JUL 14:43  General Information
     RE: Buyer BEWARE (Re: Msg 30495)
     From: CBJ          To: ELM

Len,
     I had about the same problem a while back (I live in Chicago) and I asked
the manager when he was finally called over what if I don't have a phone?  Is it

now legally neccesary to have a phone in order to make a purchase by credit
card?  It never was mentioned in any of the many documents sent with any of my
credit cards.  I also asked what if I gave them a false number.  What would the
penalties be for that?  Loss of my credit cards?  Would I be barred from all
shopping malls for a period of time?  Maybe I would be branded.  I finally wrote

the stores phone number on the slip (it was printed right on the bag).

---Carl---

-*-

30499 4-JUL 16:50  General Information
     RE: Buyer BEWARE (Re: Msg 30497)
     From: ELM          To: CBJ

Hahahaha!  It never occurred to me to write down a bogus number.  And your
choice of the number to write was outstanding!  Hahahahahaha!

Actually, I realized later and didn't have a chance to tell the store manager,
if I were trying to cheat the store, the last thing I would do would be to make
a fuss.  I'd simply write a phony number (beneath my phony signature) and leave
quietly with my genuine merchandise.

I think what's happened is that this has become a habit from the early days of
credit cards, and we just don't think about it any more.  I have seen customers
write their phone numbers on vouchers even when they WEREN'T asked for it.

Today's (7/4/90) Chicago Tribune has a front page article about how computers in

stores and other business places are amassing huge amounts of personal
information about customers.  This information is used to design marketing
strategies based on customers' personal life patterns.  Sheesh!

I think I'm just going to start getting stubborn about it, and if the merchants
where I shop don't like it, there are other merchants lined up to accept my
money, and some will certainly do business with me on my terms.

-Len

-*-

30500 4-JUL 16:56  General Information
     RE: Buyer BEWARE (Re: Msg 30483)
     From: ELM          To: ZACKSESSIONS

I think that we've allowed the problem to grow because we have accepted these
practices without resistance.

I have no objection to providing appropriate identification if I am offering a
check in payment at a place where I am not known.  By that I mean a driver's
license with my photograph or a state ID card. I know of no reason to provide
anything else except perhaps my auto license number when I purchase gasoline
with a credit card.

If enough consumers begin to complain and resist and let their legislators know
that they object to providing unnecessary information, maybe we can get some
state laws to protect our privacy.

-Len

-*-

30503 4-JUL 19:53  General Information
     RE: Buyer BEWARE (Re: Msg 30500)
     From: DODGECOLT    To: ELM

The WORST offender of consumer info has got to be the state DMV's.  They sell
information about you to any company that wants it... I think some insurance co.

and phone co. do the same! All for money.  It makes me sick....
 -Mike

-*-

30505 4-JUL 21:15  General Information
     RE: Buyer BEWARE (Re: Msg 30500)
     From: CHYDE        To: ELM

Of course you could live in a state that uses your SSN as your driver's licence
number.  Ans since they want to see your licence to accept a check they get that

too.  I had thought that when the SS system was set up they said the

ing my state reps helps so what the hey? Anyway I just tell people I don't have
a phone when they ask.  If they don't like it too bad.  I don't even have the
number printed on my checks.



-*-

30509 4-JUL 21:40  General Information
     RE: Buyer BEWARE (Re: Msg 30505)
     From: ELM          To: CHYDE

In Illinois you are given the option of having or not having your SSN on your
driver's license.  When I renewed my license in 1987, I opted to have it removed

(prior to that it was mandatory).

I don't mind showing my driver's license as identification for a check in a
place where I'm not known, but I do object to them writing the number down.  If
I'm identified, I'm identified.  Recording the number isn't going to identify me

any better!

According to an article in the 7/4/90 Chicago Tribune, an enormous data base is
being built of customer's name, addresses, phone numbers, social security
numbers, the types of purchases they make, the brands they buy, pet ownership,
and heaven knows what else.  According to the article, about the only way to
avoid giving information is to pay cash for purchases.  I think I know another:
Refuse to give the information and take your business elsewhere if the merchant
balks.

-Len

-*-

30512 4-JUL 22:09  General Information
     RE: Buyer BEWARE (Re: Msg 30505)
     From: TIMKOONCE    To: CHYDE

It is actually against federal law (Privacy Act) to require a social security
number as identification.  Many universities used to use SSN as an ID number,
and are now moving away from that.  But it does take a while for institutions to

change.  I've heard reports about how much information is being kept by some
organizations, and it is scary. Apparently, some people in the US gov't have
advocated setting up a nationwide database connecting credit information, bank
records, airplane reservations, and tons of other things in order to "track drug

traffickers".  Of course, it's frightening to think of how many
non-drug-traffickers could also be tracked and investigated through such a
system.  Watch out for Big Brother, indeed!
                      - Tim

-*-

30538 7-JUL 02:10  General Information
     RE: Buyer BEWARE (Re: Msg 30495)
     From: BACKFIRE     To: ALL

Suggest you have "policy" of giving them any old number (I use my work telephone

number, but its public anyway).  Using their OWN number sounds real nice

-*-

30539 7-JUL 02:21  General Information
     RE: Buyer BEWARE (Re: Msg 30483)
     From: XLIONX       To: ZACKSESSIONS

In Illinois there is a motion to remove your home address from the drivers
licence. And, I didn't say it would be easy to retrain people into this way of
thinking...I just tried to make clear that certain information that you have is
NOT public domain. There are MANY stores out where I live that do not even want
to see a drivers licence!?!?! (Caught me off guard!) I just think it is about
time that merchants understand that the customer has a right to  privacy that
extends beyond the door of their store. I have personaly called HBO and tol them

that if their auto-dialer calls me one more time I will find it and prove
certain anatomy lessons were wrong!

gotta go more later!

-mark

-*-

30595 8-JUL 15:40  General Information
     RE: Buyer BEWARE (Re: Msg 30495)
     From: MPASSER      To: ELM

Good job!

I found that since I have started to refuse to give my telephone number on
charge slips that NOT ONCE has the manager turned down the sale.  And if they
do, that's fine with me.  If we don't stand up for what little privacy we have
left in a time that all government and corporate computers already are a de
facto database on all of us, it will be taken away.  Don't give your phone
number for charges, and don't let them write your credit card number on a check.

The best bet is to provide a driver's license and say you DON'T HAVE a credit
card.  Most places will still take your check.  Once again, if they don't, do
you REALLY want to provide them with a customer base?

[Stepping off soapbox]

Mike Passer

-*-

End of Thread.

-*-

30477 2-JUL 18:54  Programmers Den
     gfx2
     From: XLIONX       To: KDARLING (NR)

Howdy Kev (or whoever intercepts this one <grin>),

Will you offer for $$$ (and how much) the full version of GFX2 that you are
teasing us with now???

Can you be bribed (The Gods could be bribed ya know)???

Hows life in general for you these days?

If not for $$$ when can we expect to see the FORUM version uploaded?

-mark w. farrell

-*-

30481 2-JUL 22:05  Device Drivers
     hardware
     From: N3FWE        To: ALL


I'm having trouble with my new Disto Harddrive and 232 adapter. In fact I'm
using it right now.  But it will now work with Osterm's autodial.  I have the
adapter with hard and 232 on one card.   If I go back to my old system the
single disto harddrive adapater and RS232 pak Osterms autodial works fine

Osterm would not sense the modem connected with Delphi,  I had to log on
manually with Osterm.

Also the new t2 driver would not go out to my other computer if it is hook up to

the new 232 adapater but using the old T2 with RS 232 pak no problem.

Thanks for any help

Steve...

-*-

30511 4-JUL 22:03  Device Drivers
     RE: hardware (Re: Msg 30481)
     From: TIMKOONCE    To: N3FWE

OSTerm directly looks at the serial port hardware for some things, including
detecting if the modem is connected.  Since the hardware is slightly different,
OSTerm has some problems.  That's why everything is supposed to be done through
the driver!  <grin>  Unfortunately, there is no standard way to ask the driver
whether the modem is on-line, or to ask the driver to send a break signal, etc,
so it is necessary to go directly to the hardware for some things.  <sigh>
                  - Tim

-*-

30516 5-JUL 18:16  Device Drivers
     RE: hardware (Re: Msg 30511)
     From: DODGECOLT    To: N3FWE

Look in the 'PATCHES' database for a modpatch file for version 2.08 of OSTerm.
Basically, it changes the address that OSTerm looks at for the serial port...
Been so long since I have used OSTerm that I forgot I had a patch for it....
 -Mike

-*-

End of Thread.

-*-

30482 2-JUL 22:40  General Information
     SASI driver patch
     From: KSCALES      To: ALL

Just a note to any of you who might try the SASI CCHDisk driver patch I have
uploaded to the database (currently under New Uploads)...

You very likely may find that your "read" times using Bruce Isted's Megaread
utility could jump by about 68 seconds.  This is not an indication of major
problems... it means that with this new driver, the Interleave (skip) factor
becomes important, and you may need to reformat your drive (ouch) with a
different interleave to get the full benefit.

The old driver dedicated the 6809 to waiting for the data to start coming in,
even if this took a seek and a disk revolution.  The new driver releases the
6809 to do other things if the data takes a while to start coming.  If your
interleave is not set properly, you will hit this condition.

I found an interleave of 3 to be about right for a ST225 with a WD1002
controller.

Good luck... / Ken

-*-

30484 2-JUL 23:16  General Information
     VDG games crashing
     From: POLTERGEIST  To: OS9UGPRES

Kev,
    I'm having serious problems getting my copy of FS2 and Sub Battle simulator
to boot on my system.  I have the right modules in memory, but should I also
have GRFINT.IO installed as well?  A friend of mine has both WindInt and GrfInt,

and Flight Simulator 2 seems to work just fine I also have VDGInt installed.
Now, when I use Zack Session's loader programs, BOOM!  If I fire up FS2 from the

command line, it will go as far as the control panel, then crash the whole
system.
   I do have some patches to some modules for use with Gshell+ and I also have
Shell+.  Would it be smart to add GrfInt to my bootfile just to be safe?

-*-

30493 4-JUL 12:48  General Information
     RE: VDG games crashing (Re: Msg 30484)
     From: DODGECOLT    To: POLTERGEIST

You should only require WINDINT and VDGINT for those programs. DO NOT have both
WINDINT and GRFINT in your boot.  WINDINT does everything that GRFINT does and
more... Sme programs (I <think> SBS is one of them) are hardcoded to look for
/term and use that for their VDG screen. This could also cause problems....

 -Mike

-*-

30637 10-JUL 02:56 General Information
     RE: VDG games crashing (Re: Msg 30484)
     From: OS9UGPRES    To: POLTERGEIST

You should have windint and vdgint in your boot... no grfint.

Actually, I'd suspect that along the line you either lost your Init module with
the interrupt number patch, or you've forgotten to also add some of the custom
drivers those games require... agivirqdr, etc.

Still having troubles? - kev

-*-

30661 11-JUL 21:36 General Information
     RE: VDG games crashing (Re: Msg 30493)
     From: POLTERGEIST  To: DODGECOLT

     After I installed GrfInt, Flight Simulator 2 and Sub Battle worked with
Zack Session's multi vue loading programs.  Funny that WindInt wouldn't work
with those programs.

-*-

30662 11-JUL 21:39 General Information
     RE: VDG games crashing (Re: Msg 30637)
     From: POLTERGEIST  To: OS9UGPRES (NR)

    Kev,
    I'm using the Init module that Bruce Isted supplied with his Eliminator kit,

and after I installed GrfInt, the games worked.  I do have the custome drivers
installed.  I had problems BEFORE I installed GrfInt with WindInt.  Guess I
better check out the patch for init.
    I did have the FS2 drivers installed, and before I installed GrfInt, boom!
The programs wouldn't work, and I'd have to reboot the whole system. I still
have problems before I install GrfInt.

--Brian

-*-

End of Thread.

-*-

30486 3-JUL 21:40  Telcom
     Alpha Technologies
     From: COCOJOHN     To: ALL

Hi all!

   I'm sort of NEW to OS9. I bought Warp 1 at the last Chicago Rainbowfest and
I only can log on a couple of boards using Warp 1. I cannot use Warp 1 to log on

Delphi. The use of Warp 1 gets me. I have to change parimeters each time I log
onto a different system. I don't think the auto-dialer file stores hings like
that other then the BBS you call and the number.

   I'm kinda sorry I bought Warp 1, as I also have a problem using the
conference feature on it. I log onto a BBS that features 16 lines and the
conference that goes on....the chat on Warp 1 breaks up your message you are
typing in while the screen is scro lling away. I prefer a terminal program that
has a seperate window like The Wiz!

   But it's funny, I cannot really use Warp 1 to just call any bbs or Delphi.
The screen is messed up. One board the screen prints wide like no line feeds,
etc... and runs off. I call Delphi via telenet and I get nothing but garbage on
the screen plus for some odd reason I get logged on at 1200 baud.

   I hope I am doing something wrong. I'm sure Warp 1 works much better then I
think it does.

   Also does anyone know of any OS9 terminal programs that will let you select
whether you want to add Line feeds to a text file before uploading on a BBS?

CoCoJohn ok

-*-

30489 4-JUL 00:05  Telcom
     RE: Alpha Technologies (Re: Msg 30486)
     From: NES          To: COCOJOHN

John, download supercomm from the tel communications area, its the best PD
program for os9 well that's my opinion.  Then trash the Warp 1, Some of the Best

programs I have used have been shareware programs that I have downloaded for
here. also try the text editor call "ED". Eric    -NES on delphi or my BBS
704-822-1337   300-2400.


-*-

30534 7-JUL 00:04  Telcom
     RE: Alpha Technologies (Re: Msg 30489)
     From: COCOJOHN     To: NES

Thanks Nes-

  Hey thanks for also posting your BBS number. I'll give it a call this weekend!

CoCoJohn

-*-

End of Thread.

-*-

30487 3-JUL 22:42  Device Drivers
     RAMdisk
     From: FRANCALCRAFT To: ALL

I have some questions about the RAMdisk (192K) that comes in the OS9 Development

System. First, why doesn't FORMAT work on it? Second, if one patches the
descriptor so that the number of sectors is $2D0 instead of $300, why can one
only backup to it as far as sector $2BF? What happened to the last 16 sectors?
Third, is there any way to fix this so one can use backup with it?

-*-

30490 4-JUL 11:53  Device Drivers
     RE: RAMdisk (Re: Msg 30487)
     From: MRGOOD       To: FRANCALCRAFT

As far as the RAMDISK goes, you don't need to format it. As soon as you chd to
it, it becomes active (as long as the device driver and descriptor are in
memory).


-*-

30494 4-JUL 12:52  Device Drivers
     RE: RAMdisk (Re: Msg 30490)
     From: DODGECOLT    To: FRANCALCRAFT

Actually, you ought to INIZ the ramdisk, but you don't hve to format it. To
change the size of the Ramdisk, you have to change the number of sectors BEFORE
you use it/iniz it. If you do it afterwards, then you have to DEINIZ it and then

INIZ it to make the chage take effect. NOTE: this will erase the contents of the

ramdisk!
 -Mike

-*-

30521 6-JUL 00:01  Device Drivers
     RE: RAMdisk (Re: Msg 30494)
     From: FRANCALCRAFT To: DODGECOLT

I know you don't have to format that ramdisk, but when I tried it anyway, it
didn't work. The question is, why? As far as changing the number of sectors
goes, I changed that right on the disk before loading the descriptor and found
that BACKUP wouldn't write to the last 16 sectors that I thought should be
there. What do you have to do to that ramdisk to get it so that you can backup a

40 track floppy disk to it (single sided)?

-*-

30525 6-JUL 05:58  Device Drivers
     RE: RAMdisk (Re: Msg 30521)
     From: DODGECOLT    To: FRANCALCRAFT

I am not sure what you have to set the ramdisk up as for the backup (I've got a
hard drive, so I haven't needed to do much in the way of disk shuffling....) I
will play around with it a bit today and get back to you...
 -Mike

-*-

30546 7-JUL 14:52  Device Drivers
     RE: RAMdisk (Re: Msg 30521)
     From: TIMKOONCE    To: FRANCALCRAFT

The Dev Sys Ramdisk does have a known bug:  The total Ramdisk size must be an
exact multiple of 8k.  Otherwise, the last needed block of memory won't get
allocated.  That makes it pretty much impossible to set it up to be able to
exactly backup a floppy disk to the Ram disk.  I beleive there may be other
Ramdisk drivers for wich this will work, though. I know CIS has a couple.  If
you only have 512k, you can try Kev Darling's Rammer ramdisk, which is here.
                      - Tim K

-*-

30588 8-JUL 11:33  Device Drivers
     RE: RAMdisk (Re: Msg 30546)
     From: FRANCALCRAFT To: TIMKOONCE

Rammer does work. I have it already, and like it. If I go to 1 meg, is there any

way I can patch Rammer to work with it?

-*-

30593 8-JUL 15:14  Device Drivers
     RE: RAMdisk (Re: Msg 30588)
     From: ZACKSESSIONS To: FRANCALCRAFT

According the Kevin Darling, the author of both rammer and mega, that's a "no
can do". It is because rammer "cheats" in the way it allocates or accesses
memory (I forget exactly what). As far as I know the only ramdisk driver which
is "guarenteed" to work with the one meg upgrade is the Dev Pack driver.

Zack

-*-

30599 8-JUL 17:39  Device Drivers
     RE: RAMdisk (Re: Msg 30593)
     From: RADARBUZZ    To: ZACKSESSIONS

Zack,

    Well, maybe you can straighten me out here.  I never was able to get the Dev

pack, so I'm using the VDD driver from the database here that is supposed to be
a direct replacement for the Tandy driver.  Now it works alright, but if you try

to set one up for greater than 512K the computer crashes.  Any Ideas?

-Jeff




-*-

30600 8-JUL 17:54  Device Drivers
     RE: RAMdisk (Re: Msg 30599)
     From: DODGECOLT    To: RADARBUZZ

I think the VDD driver is hardcoded to only allow 64 blocks per ramdisk... Since

512k worth of ramdisk = 64 blocks, any more will overwrite other important info
and causes a crash....
 -Mike

-*-

30607 8-JUL 19:39  Device Drivers
     RE: RAMdisk (Re: Msg 30599)
     From: ZACKSESSIONS To: RADARBUZZ

Sorry, Jeff, solving a problem of that nature is beyond the scope of my
knowledge. I see that there is a reply to your message, so maybe someone else
may spot it and offer some aid. One idea is that, you obviously have the one meg

upgrade, I don't think "things" can span from one 512K back to the other, like
all of the 32K fo a type 8 window has to be in one bank or the other.

Zack

-*-

30613 8-JUL 20:33  Device Drivers
     RE: RAMdisk (Re: Msg 30607)
     From: TIMKOONCE    To: ZACKSESSIONS

Zack,
   Only reason why a window can't span sections is because of hardware
limitations on the video handling.  That's not an issue with Ramdisks. It's not
even necessary for the Ramdisk memory to be consecutive blocks, so even that's
not an issue.  Assuming it doesn't cheat, there's no reason why a Ramdisk driver

couldn't use as much memory as there is available.
               - Tim

-*-

30617 8-JUL 23:06  Device Drivers
     RE: RAMdisk (Re: Msg 30613)
     From: ZACKSESSIONS To: TIMKOONCE

So Mike Sweet's explanation seems feasable, then, ie, VDD can only handle 64
blocks.

Zack

-*-

End of Thread.

-*-

30488 4-JUL 00:01  General Information
     The Forth
     From: KNOT1        To: ALL

Happy Forth everyone!

                       -Jamie (KNOT1)-

-*-

30491 4-JUL 11:53  General Information
     RE: The Forth (Re: Msg 30488)
     From: MRGOOD       To: KNOT1

You do mean, Happy FOURTH, no?


-*-

30515 5-JUL 04:42  General Information
     RE: The Forth (Re: Msg 30491)
     From: KNOT1        To: MRGOOD

OOOOOOPS!  Yep, sure did.  Me spelling ain't no good, yes?

                     -Jamie (KNOT1)-

-*-

30518 5-JUL 21:45  General Information
     RE: The Forth (Re: Msg 30515)
     From: MRGOOD       To: KNOT1


Well, hope you had a happy fourth, regardless of spelling!

Hugo


-*-

End of Thread.

-*-

30498 4-JUL 15:07  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 27210)
     From: JASONEABY    To: DISTO

Tony, I apologize for the long delay.  I had finacial troubles and couldn't
afford to run up anymore online charges.  The number for Dove Computer is, (919)

763-7918.  I hope this helps.  Again I apologize.  I would really like to
upgrade to 1-Meg w/o sold ering.
          Jason

Geez, I hate this editor.  And I don't have my VMS EDT editor reference handy
either, oh well.


-*-

30501 4-JUL 18:04  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30498)
     From: ZACKSESSIONS To: JASONEABY

EDT has "on-line" help at the asterisk prompt. Just enter HELP and press ENTER
(or RETURN). Of course, as with most VMS type help, you need toave an idea of
what you need help ON to get some useful information out.

Zack

-*-

30502 4-JUL 18:57  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30501)
     From: JASONEABY    To: ZACKSESSIONS

I tried help, it only gave me something that didn't make much sense.  I know how

screwy VMS is on its help because Millersville University has several VAX'es and

I have to program on a MicroVAX 3600 for my CS classes.  -Jason

-*-

30504 4-JUL 20:07  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30501)
     From: DWHILL       To: ZACKSESSIONS

That's been one of my complaints about the online editors here: help is there
but isn't much help when you're constantly switching back and forth between the
task and the help menus.  Delphi needs to make a downloadable tutorial available

so we can have our own references at hand to study before we attempt to use the
darn thing.

--Damon

-*-

30506 4-JUL 21:17  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30504)
     From: CHYDE        To: DWHILL

Yyou could of course by a Delphi manual.  They have a very good description of
the editing commands.  They just finished a new edition which is availabel now.

Just a thought.

-*-

30513 4-JUL 23:30  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30504)
     From: ZACKSESSIONS To: DWHILL

There is the Complete Delphi Guide.

Z.

-*-

30514 5-JUL 00:11  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30506)
     From: DWHILL       To: CHYDE

True, but I'd like to have a up-to-date reference online that's more helpful
than what's currently available.

--Damon

-*-

30561 8-JUL 00:07  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30502)
     From: RAGTIMER     To: JASONEABY

Say, ever notice that there is NO help available at the MAIL prompt? No way to
get a list of valid commands!  There's help at the DMAIL level, but not at MAIL.

AT least I haven't rubbed the genie's lamp the right way.

Word is that Delphi's Mail system is straight raw VMS. Thank God for UN*X.

-*-

30564 8-JUL 00:35  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30561)
     From: JASONEABY    To: RAGTIMER

Haven't tried to use mail yet, but I can believe it because I have used VMS
mail.  VMS mail goes something like this, type send with a user name and it'll
prompt you from there.  Heck I don't even think you have to use a name. -Jason

-*-

30566 8-JUL 00:39  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30564)
     From: RAGTIMER     To: JASONEABY

Yes, just sending mail is easy enuf.  But after reading a message I wanted to
reread it.  Type REREAD, got some generic "syntax error", but there's no way to
get a list of commands.  I do have that Delphi manual somewhere, but I hate
rooting in a book while my computer taxi meter is ticking (at least this isn't
CI$).

-*-

30568 8-JUL 00:59  General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30561)
     From: GREGL        To: RAGTIMER

Mike,

    From the MAIL> prompt you can type HELP for a list of the commands you can
use. It'll put you into the generic help system where you can follow a chain of
commands and options to find what you are looking for. It ain't the best in the
world, but it works.

    -- Greg

-*-

30646 10-JUL 21:55 General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30568)
     From: RAGTIMER     To: GREGL

OK -- I cuda sworn I'd tried HELP.  Maybe I did, and got disgusted with that
generic HELP system.  There should me a list of MAIL cmds, as there is at the
DMAIL level and inside its WORKspace.

-*-

30653 10-JUL 23:20 General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30646)
     From: GREGL        To: RAGTIMER (NR)

Mike,

    No argument from me. One of the biggest complaints we get is on the mail
system used. I keep hoping that the gurus behind Delphi will write their own
version of Mail and toss DEC-Mail. But I don't know if they are legally bound to

use DEC-Mail or not. It's fairly powerful but it's not the easiest thing to use,

that's for certain.

    -- Greg

PS: A problem I just thought of is that Mail is used quite heavily to send mail
to other nodes. For example, you commonly send mail to users of Delphi/Boston by

using the BOS1A or BOS1B nodes. But you can also send mail to Delphi/Miami by
using MIAIA, Delphi/Argentina, Delphi/Kansas City, etc. Just one of the
advantages of using the VAX Cluster.

-*-

30658 11-JUL 18:11 General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30653)
     From: ZACKSESSIONS To: GREGL

Actually, Greg, the VAXcluster isn't what gives us the ability to send mail to
other nodes, it's DECnet.

Zack

-*-

30690 13-JUL 21:01 General Information
     RE: One Megabyte CoCo-3 !! (Re: Msg 30514)
     From: CHYDE        To: DWHILL (NR)


their own.
     Chris

-*-

End of Thread.

-*-

30519 5-JUL 22:34  Utilities
     PCDos
     From: JASONEABY    To: ALL

  Help!  Is there anyway to use the PC-Dos utility with the Disto No-Halt
CC3Disk Driver?  When I try to use it, I get not a Dos disk.  Of course the
problem may be the fact that it was formatted for 360K on a 1.2 Meg drive. Those

1.2 Meg drives are notorious for screwing up the 360K format. Any help will be
appreciated.  Thanks. -Jason

-*-

30526 6-JUL 06:01  Utilities
     RE: PCDos (Re: Msg 30519)
     From: DODGECOLT    To: JASONEABY

Unfortunately, the SC-II hardware only buffers the first 256 byts of a sector.
This works fine for OS-9 disks, but MS-DOS disks use 512 bytes per sector. The
only solution at present is to have a second boot disk that uses the old HALT
mode driver instead of the Disto driver...
 -Mike

-*-

30545 7-JUL 14:49  Utilities
     RE: PCDos (Re: Msg 30519)
     From: TIMKOONCE    To: JASONEABY

The simple answer is: "No, the PCDOS utility will not work with the no-halt
drivers."  To use it, most people keep a second boot disk with the standard halt

drivers just for use with PCDOS.
                         - Tim

-*-

30554 7-JUL 22:27  Utilities
     RE: PCDos (Re: Msg 30526)
     From: JASONEABY    To: DODGECOLT

Thanks, I have a couple of old boot disks lying around, so I'll try the patch on

them and hope it works.  Should have expected it to be something like that.
That's what you get for using the latest and greatest technology.


-*-

End of Thread.

-*-

30522 6-JUL 00:05  General Information
     Double-sided boot disks
     From: FRANCALCRAFT To: ALL

How does one make a double-sided boot disk for OS-9, starting from a single
sided system? I have tried all sorts of cute tricks to try to accomplish that,
but nothing works.

-*-

30528 6-JUL 21:03  General Information
     RE: Double-sided boot disks (Re: Msg 30522)
     From: FRANCALCRAFT To: ALL

Perhaps I should rephrase. How does one make a double-sided boot with COBBLER?
CONFIG works fine, but I couldn't get COBBLER to make a workable boot on a
double-sided disk.

-*-

30530 6-JUL 23:08  General Information
     RE: Double-sided boot disks (Re: Msg 30528)
     From: ZACKSESSIONS To: FRANCALCRAFT

Let me know your disk configuration, ie, how many floppies, any ramdisk, or hard

drive, and I'll give you the exact commands to do it.

Zack

-*-

30543 7-JUL 11:14  General Information
     RE: Double-sided boot disks (Re: Msg 30528)
     From: DRSPOON      To: FRANCALCRAFT

I had one heck of a time getting a double sided boot disk at first too!!  I
played around with changing the descriptors from single sided to double sided
 and everything that I could think of on the single sided boot disks I had and
nothing worked.  The ultimate solution for me was to FORMAT the destination disk

first as double sided.  I could not use the straight FORMAT command, I had to
specify 2 sides.  Seems like if I just used FORMAT without any modifiers the
system assumed that I wanted to format the new disk just like the one I used to
boot up with, which at the time was a single sided disk. (Thats all I had!!)
Once I had a suitable double sided boot set-up on the single sided disk, I used
the DSAVE route to copy it to the newly formatted double sided disk and every
thing worked fine!!  Once I had the original double sided boot disk, then every
disk I formated with that disk also came out formatted double sided WITHOUT
having to use any modifiers.  I still don't know WHY I had to do all this, and
WHY no one else seemed to be having that trouble, but it worked for me.  This
may not have anything to do with your current problems, but I thought I would
report it.  Maybe someone else can explain the WHYs for me.  Probably something
simple that I was not doing at the time. Seems like the key is how the disk you
originally booted up on is configured. That seems to get locked into the
system's corporate memory and is used until you tell it to do something
different!!-Don Spoon-

-*-

30586 8-JUL 11:27  General Information
     RE: Double-sided boot disks (Re: Msg 30530)
     From: FRANCALCRAFT To: ZACKSESSIONS

With COBBLER?  I did manage to make a double-sided boot with Config, but not
with Cobbler. The strange thing is, I really couldn't see any difference in the
way the pieces of the boot were arranged between the two. I have one
double-sided floppy drive, and one single-sided, one  Ramdisk, n hard drive.

-*-

30587 8-JUL 11:31  General Information
     RE: Double-sided boot disks (Re: Msg 30543)
     From: FRANCALCRAFT To: DRSPOON

I used a sneaky trick to get around the format problem. I used DMODE. I just did

DMODE /d0 sides=2, formatted a disk, which came out double-sided, then tried to
COBBLER to it. The result wouldn't boot. I next tried Config with a double sided

descriptor for that drZ8e,ahZYHMU1Q"%==Q9"+HUMQ%=9JM1:!e"%9"5R4uKK[I:=I-}j$(-*-

30590 8-JUL 12:35  General Information
     RE: Double-sided boot disks (Re: Msg 30587)
     From: DRSPOON      To: FRANCALCRAFT

I'm getting in over my head, but here's some thoughts.  Seems like I recall that

Cobbler just writes whatever boot information is in memory from the last boot-
up, unless you have changed it.  Maybe the info you wrote to your new double-
sided disk was single-sided info??  I also seem to recall that several years ago

many people reported troubles with Cobbler and the GURUs were advising not using

it.  I never got the "real" reason.  I think it WOULD work, but had several
nuances that the casual user would not know about, and were taken care of in
CONFIG automatically.  It is not a "user friendly" command!!  Neat about the
DMODE!!  I'll add that to my library of "things I'll make sure to teach my
kids".  Thanks
 Don Spoon

-*-

30592 8-JUL 15:09  General Information
     RE: Double-sided boot disks (Re: Msg 30590)
     From: ZACKSESSIONS To: DRSPOON

I never use cobbler or config, because to me it's simpler to use os9gen, and I
feel I have more total control.  The only modules for OS9Boot which come from
memory are REL, Boot, and os9p1. when using os9gen. When using cobbler,
everything comes from memory. So, how I did it was to build a bootlist file
which contained the DS file decriptors. dmoded the target disk for 40trk, DS,
formatted it, and the OS9Genned the boot. Can't really say WHY cobbler failed in

a similar manner, but like the old joke, I told the doctor it hurt when I raised

my arm, so he told me not to do it!

Zack

-*-

30615 8-JUL 22:06  General Information
     RE: Double-sided boot disks (Re: Msg 30592)
     From: RADICAL      To: ALL

Just set up a doubleside drive 0 today.  Previously had a doublesided drive 1,
so things worked smoothly.  Dmode /d0 sid=2 cyl=28 dmode /dd sid=2 cyl=28 format

a doublesided disk, cobbler the os9boot, then dsave /d0 /d1 ! shell This gave me

a working copy, which booted first try on a doublesided disk. If you don'd have
two drives I think dsave -s should do the samething on a single drivwve.   Len


-*-

30622 9-JUL 14:03  General Information
     RE: Double-sided boot disks (Re: Msg 30590)
     From: FRANCALCRAFT To: DRSPOON (NR)

If by "single-sided info" you mean a single-sided device descriptor for the
drive, I checked that with DED and changed it before trying to boot. Yes, I did
verify the module afterwards (to forestall the next question). Cobbler still
works like a charm for doing single-sided boots.

-*-

30635 10-JUL 01:08 General Information
     RE: Double-sided boot disks (Re: Msg 30622)
     From: RADICAL      To: FRANCALCRAFT

Do you have the dmode command?  If not be sure to download it from the database.

You can then use it to change the discritors for the drives to cyl=28 sid=2
thhat creates a doublesided drive.  In the case of drive 0 the command would be
:dmode /d0 cyl=28 sid=2.  Then format, and cobbler a new disk, and dsave /d0 /d1

! shell.   You should end up with a bootable doublesided disk once you are done.

Len

-*-

30645 10-JUL 20:23 General Information
     RE: Double-sided boot disks (Re: Msg 30635)
     From: FRANCALCRAFT To: RADICAL

I have DMODE. I used it. Cobbler didn't work, however. Perhaps that was because
I booted up from a single-sided disk? Config worked fine.

-*-

30654 11-JUL 00:58 General Information
     RE: Double-sided boot disks (Re: Msg 30586)
     From: DCJR         To: FRANCALCRAFT

The catch with cobbler is that it makes an EXACT copy of the OS-9 kernal you
have in memory at the time you call it. This includes any patches you've made
since you booted up, and any dmode or xmode commands you've issued. If you want
to make a double-sided boot disk, the catch is first you have to boot from one!
Then, don't forget to create a CMDS directory with shell and grfdrv in it.

-*-

30656 11-JUL 02:07 General Information
     RE: Double-sided boot disks (Re: Msg 30654)
     From: RADICAL      To: DCJR

I booted from a single sided disk.  Dmode /dd cyl=28 sid=2  Dmode /d0 cyl=28
sid=2  Then cobbler to a blank doublesided disk, and dsave the bootdisk.  The
resulting disk booted with no problems.  Len

-*-

End of Thread.

-*-

30524 6-JUL 03:05  General Information
     Atlanta CoCoFEST
     From: DAVEMYERS    To: ALL

                   *** ATLANTA CoCoFEST ***
                       October 6-7,1990
                     Holiday Inn Northlake


   As you may know, the traditional Fall gathering of CoCo enthusiasts has been
cancelled...BUT, you can make plans NOW to join your favorite CoCo vendors,
online pals, and CoCo fans from far and near at the 1s  before you buy" those items yayryo
->noco  ri Wrusshs dt  edgCo   prs.orn N esoCCitrt
-- r hnstwnvub orrz,cueyf  aiian nosnh taaCptroiy

-Tepouiyotnuwtdnsdooot d adr t A!---Flwhpn nwthnesunhdesfCotTct otetatCCETa vlbeO   pily.n,aa
er ns.h rt2 ele to reserve onsite hotel rooms through us (at
the special show price of $49/nite + tax, single or double) will receive a FREE
one-day admission for each night's lodging purchased! To recieve the special
room rate, your reservation MUST be placed through CoCoPRO!

For specially discounted airfare and car rentals (starting at $17.95/day with
unlimited mileage), contact Lisa at CoCoFEST affiliate Travel Bank of Atlanta -
1-800-477-9191.

For tickets, hotel reservations, or further info, contact us at CoCoPRO! -
1-313-481-DAVE <3283> (1-8 P.M.. 7 days).  Modem users may place ticket/room
orders using VISA or MC, by calling our BBS at 313-663-6207 (3 lines, 7-E-1,
3-1200 on all lines).

-*-

30527 6-JUL 19:10  General Information
     shell+ 2.1
     From: CAPTSWOOSH   To: ALL

hey gang can some one tell me how to configure shell+ 2.1 ?? How do i create the

new boot?? how do i save my old modules... HELP!!!! ron the novice. i mean real
novice.....

-*-

30529 6-JUL 23:06  General Information
     RE: shell+ 2.1 (Re: Msg 30527)
     From: ZACKSESSIONS To: CAPTSWOOSH

Configure shell+ 2.1? Save old modules? Huh? Yeah, I guess you are a novice?
<grin>

Shell+ does come with a doc file which describes how to install it. Basically
all you replace is your old shell module with the new shell module, that's it.
Now, your "stock" shell module has a fwe commonly used OS9 modules "merged" with

it. That's why when you boot up and do an MDIR command, you see a few extra
modules. Those modules are also in the CMDS directory on the main OS9 disk in
individual files. Just merge those modules with the new shell module with
shell+. Be sure to set the execution attribute to the newly created module which

contains shell+ and the other utils so you don't see the "OS9 BOOT FAILED"
message!

Zack

-*-

30547 7-JUL 14:59  General Information
     RE: shell+ 2.1 (Re: Msg 30527)
     From: TIMKOONCE    To: CAPTSWOOSH

Ron,
   The easy way (which doesn't quite do everything you'll eventually want) is
to:
   rename /dd/cmds/shell old_shell
   copy shellplus /dd/cmds/shell
   attr /dd/cmds/shell e pe

First, rename the "old" shell file to something different, then copy the new
shellplus into your CMDS dir, then give it execute privileges. There's no need
to create a new boot, and you don't _really_ need to save any modules.  The
saving modules bit is a trick that more experienced OS9ers use to speed up their

system by keeping common programs (dir, list, free, mfree, copy, etc.) in
memory.  If you just do what I listed, those commands won't be in memory, which
will slow things down some, but it will still work just fine.,.
                           - Tim

-*-

30555 7-JUL 22:52  General Information
     RE: shell+ 2.1 (Re: Msg 30529)
     From: JASONEABY    To: ZACKSESSIONS

Zack, can you tell me why the Shell+ 2.1 docs tell you to keep the module size
below 8k?  I realize it has something to do with keeping it in an 8k block, but
if I go over, will the shell take up 16k every time I start a new one?  The way
I interpret the Level II docs make it seem like it shouldn't, because of the
multiple threading of a process.  The 8k that it takes up now, I think, goes to
data storage. Any help will be appreciated.  -Jason

-*-

30560 7-JUL 23:44  General Information
     RE: shell+ 2.1 (Re: Msg 30555)
     From: ZACKSESSIONS To: JASONEABY

If the size of a merged multiple module file is larger than 8K and one of the
modules is Shell, NO, each time you start up a shell, the process doen't take up

the extra memory. The problem with going over 8K is that memory is allocated in
8K chunks and if you do go over 8K, then the difference in the final size and
the next increment of 8K is totally wasted memory and can never be allocated to
any process for use.

Actually, the size of a merged multiple module file should not exceed 8K - 512,
or 7680 bytes. Quoting from Kevin's book, the ideal size of a merge file is:

(8K * N) - 512 where N ranges from 1-7.

Zack

-*-

30562 8-JUL 00:17  General Information
     RE: shell+ 2.1 (Re: Msg 30529)
     From: RAGTIMER     To: ZACKSESSIONS

Zack, do you know whether that well-meaning bug in Sell+ has been fixed? The one

where every program is forked with at least 7K, as if the user had typed
  program #7K

You probably have heard that this "feature" prevents large program (those that
use all 8 of the 8K blocks) from running. Tis includes Ultimuse-III and some
other well-known stuff, I forgot which. There is a patch to eliminate that
feature, but I wondered if a newer version had come out with out it.

Anyway, users should know about the problem.  Thanks, mike k

-*-

30565 8-JUL 00:38  General Information
     RE: shell+ 2.1 (Re: Msg 30560)
     From: JASONEABY    To: ZACKSESSIONS

Thanks, the docs gave a file size about what you said, I just rounded for
convenience and forgetfulness's sake. I guess that means if I can get it it
somewhere close to a 16k block, I'll be in business. Thanks again. -Jason

-*-

30567 8-JUL 00:49  General Information
     RE: shell+ 2.1 (Re: Msg 30555)
     From: TIMKOONCE    To: JASONEABY

The actual concern, Jason, has to do with how Shell+ deals with certain things.
In order to find out certain things about a program, Shell+ links the module
into it's own address space.  Since the module might be large, you want to make
sure that Shell+'s address space has as large a hole as possible for the other
module to fit into.  Shell+'s data area takes up 8k, so the biggest possible
hole is 48k, or 6  8k blocks.  The only way to get that is if the Shell+ module
is in the top block of memory, which requires that the total size be under 7680
bytes.
   For the newer Shell+, which is pretty big, I only merge in "load" with it
(which is necessary if you want "load" to end up not taking up it's own 8k
block, BTW), and merge other utils into separate files, each less than 8k.
Those files get loaded by my Startup file. Seems to work pretty well.
   There are also some programs which link the Shell, which is another good
reason to keep the Shell file under 8k.
                             - Tim

-*-

30570 8-JUL 01:36  General Information
     RE: shell+ 2.1 (Re: Msg 30567)
     From: JASONEABY    To: TIMKOONCE

That is the way I'm doing it now, although I have more than 'load' merged and
have it under 7680.  But this help has probably confused things even more. Zack
says it doesn't matter and you say it does.  Maybe I'll just have to stop being
lazy and try it f or myself and see what happens.  Either that or we should kick

this up to a higher authority. -Jason

-*-

30571 8-JUL 02:33  General Information
     RE: shell+ 2.1 (Re: Msg 30570)
     From: TIMKOONCE    To: JASONEABY (NR)

   If you read carefully, Zack explained to you the reason why you want merged
modules to come close to a multiple of 8k, so you don't waste memory.  Since
memory is allocated 8k at a time, you'd like to fill the memory that gets
allocated.  The bit about being 512 bytes short is a subtle point that I'll not
go into right now.
   What I elaborated on is why the Shell file, in particular, should fit in just

one block, which is due to the way the Shell does certain things.
   To summarize: In order to save memory, _any_ group of merged modules should
be just under some multiple of 8k.  Because of the way the Shell (including
Shell+) works, the Shell file should be under 7680 bytes. Does it make more
sense now?
              - Tim

-*-

30583 8-JUL 11:12  General Information
     RE: shell+ 2.1 (Re: Msg 30562)
     From: ZACKSESSIONS To: RAGTIMER

Wasn't there a patch to Shell+ posted here in the forum which fixed that
problem?

Posted by Mike Haaland, originally, I think.

Zack

-*-

30647 10-JUL 22:00 General Information
     RE: shell+ 2.1 (Re: Msg 30583)
     From: RAGTIMER     To: ZACKSESSIONS

Yes, there was the patch, which I wrote in my notebook somewhere in March or
April, and passed on to Paul Seniura.  I didn't know about the 2nd patch he's
posted, tho.

However, I wondered whether there had been a later release of Shell+ that fixed
the problem.  "Instant Program -- No patches Needed" -- boy would that be a 1st
for OS9, just kidding, grin.

Seriously, patches for PD shareware aren't so bad, since users get the patches
the same media they got the program to start with. Bigger problem is commercial
programs (like MultiVue) that require patches; most customers aren't on
Delphi/CIS/whatever and don't even know the patches exists, or how to get them.
--mike k.

-*-

30649 10-JUL 22:12 General Information
     RE: shell+ 2.1 (Re: Msg 30571)
     From: RAGTIMER     To: TIMKOONCE (NR)

Also:  Any merged group that has one BIG program (that's going to use all 8 of
its 8K blocks when running) should fall short of an 8K multiple by that 512 byte

amount. I know someone who MERGEd innocent little MONTYPE and PWD with Umuse3,
thus filling in that 512 byte no-man's land, and got a nasty surprise when it
ran. This by the way is not really related to the Shell+/Umuse3 problem, which
is easily patched out of Shell+.

-*-

30650 10-JUL 22:14 General Information
     RE: shell+ 2.1 (Re: Msg 30583)
     From: RAGTIMER     To: ZACKSESSIONS

Zack, it may well have been Mike Haaland who first found that Shell+ bug with
big programs, since his MVCanvas is about as big as Umuse3.

-*-

30684 12-JUL 23:22 General Information
     RE: shell+ 2.1 (Re: Msg 30650)
     From: XLIONX       To: RAGTIMER (NR)

Howdy Mike, Please see msg# 30556

-mark w. farrell (XLIONX)

-*-

30686 13-JUL 00:12 General Information
     RE: shell+ 2.1 (Re: Msg 30650)
     From: MIKEHAALAND  To: RAGTIMER (NR)


~ Well,  To set the record straight,  I did discover that Shell+ was giving our
programs (UMusE III and MVCanvas) a little trouble.  But it was another forum
member who found out how to patch Shell+ to work so it didn't give an extra 31
pages of memory when forking programs.

MikeH

-*-

End of Thread.

-*-

30531 6-JUL 23:14  New Uploads
     depthcharge
     From: ZACKSESSIONS To: WJMOORE

I downloaded depthcharge the other night and have a few comments. Please don't
take anything I say derogatory, I'm only trying to help. The program is good,
but uploads need a little extra. Like a doc file which describes the program,
how to install it, and how to use it. Fortunately, I found the comments in the
source on how to drop depth charges, but I know nothing on the scoring of the
game. Also, some sound effects may make the game more enjoyable.

Zack

-*-

30533 6-JUL 23:54  New Uploads
     RE: depthcharge (Re: Msg 30531)
     From: WJMOORE      To: ZACKSESSIONS

Just say it like it is but keep it clean! hehe.  I was exploring the get/put
buffers and used this game as a vehicle to demonstrate animation capabilities.
But you are correct, a brief description on loading, running, and operating the
game will be UL for
 those that do not program.  As for scoring, I could not come up with anything
satisfactory so open to any suggestions.  Primative sounds can be added easily,
but "white" noise I can not generate.  Any help here?  Anymore comments, just
tack onto this thre ad.

- War -

-*-

30541 7-JUL 11:00  New Uploads
     RE: depthcharge (Re: Msg 30533)
     From: ZACKSESSIONS To: WJMOORE

White noise can be generated by doing a SYSCALL to the SetStt/ SS.Tone call with

a random value for the frequency. Makes a good motor/engine sound.

I did play the game for at least an hour, though, when I first downloaded it!

Zack

-*-

30550 7-JUL 19:23  New Uploads
     RE: depthcharge (Re: Msg 30541)
     From: DODGECOLT    To: WJMOORE

You might want to check out my Lander games a tle h ffrotesn,u hhgfe tfi o rone..-i

*

n  he.--35 -U0: Uite  c"tlt  rmKO    oAL
Hl,eeoeyisulat edtaesolsob alb nt N pos
eto Iscld""wi shr r"oy.Is tlywc
cbn hfntn foyg iigMvn nDltgfe. 
ort eyiirytisUXcnept,iht dtosfewi-rpign roeoe

Ipod cueodays ago, so it should be available anytime soon. Give

it a try!  Let me know what you think.

                        -Jamie (KNOT1)-

-*-

30540 7-JUL 03:34  Utilities
     database report
     From: BOBDORRELL   To: EDDIEKUNS (NR)

Eddie, I am looking at the July, 1990 Rainbow page 62, where you say there is a
program that generates a shell script to copy an entire DECB formatted disk to
and OS-9 disk using Bob Shanty's RS-DOS utility. I can't find any of ther
programs you list in the article, in the database. What is happening folks? Are
all the programs selfdistructing? Maybe if you could give the actual name that
the file is posted under, it would help me find it. I could go to the database,
utilities, and type READ RS-DOS and get what I wanted. Most of the items you
mentioned in the article don't have the NAME of the file. Thanks for you help.
                          ----==<Bob>==----

-*-

30542 7-JUL 11:03  Utilities
     RE: database report (Re: Msg 30540)
     From: ZACKSESSIONS To: BOBDORRELL (NR)

It's called RSSave.

-*-

End of Thread.

-*-

30548 7-JUL 17:00  General Information
     1 Meg problems?
     From: RADARBUZZ    To: ALL

1 Meg status,

    I just installed my 1 Meg kit that I ordered from CRC/DISTO.  Everything
seems to be working, but...

    Never before have I had those things called "sparklies", but now I got a
few.  With no multitasking, (just a few shells on /w1, /w2, /w3 ...) I get one
pixel slightly flickering near the top middle of most of the 80 column
screens.As a test, I've LOADed about 800K of modules, started OSTERM, ED, and 5
MAZEs. The computer has been up for about an hour and I'm now writing this with
ED. R22 IS SHORTED as specified in the instructions.

    Basically, I have 3 concerns right now: (* = HELP!)

   *1)  The point at which the regulator on the 1-Meg card connects to it's
        heat sink is HOT.  15 seconds max finger touch before pain.  This
        does not seem normal!  The smell from the heat conductive goop cooking
        between the regulator and heat sink is giving me a head ache, I hope
        it's not toxic?

   *2)  Right after booting I could not set up a ramdisk (VDD driver here on
        Delphi) bigger than 512K.  Here is how I try for a 720K ramdisk:

       mega
       dmode /r0 sct=0b40
       iniz /r0

        After the "iniz /r0" I get small blocks of random characters (some
        blinking) on the screen and the computer is locked up.  I was under
        the impression that the VDD driver worked with 1-meg, which is why
        I switched from RAMMER before the I-Meg kit arrived.

    3)  The "sparklies" don't seem to be real bad, but I'm willing, as others
        have, to try hooking up a small pot in place of R22 to attempt to
        "tune" my computer's personality (grin).  Any ideas on what ohm values
        to begin with?


    Well, now I'll try Osterm and post this in the forum.  Any help that comes
my way is truely appreciated!

-Jeff

ps.  Osterm is really NOT smooth with 1-Meg! Since it's running in the upper
     512K bank, it must...SCRATCH that!  With all those MAZEs running in the
     background, I shouldn't expect smoothness. Almost fooled my self (grin).


pps.  Sparkies seem much worse (exponetially greater) during ACIA I/O.  Must fix

this! **


-*-

30563 8-JUL 00:26  General Information
     RE: 1 Meg problems? (Re: Msg 30548)
     From: RAGTIMER     To: RADARBUZZ

Sparklies are worse during any kind of heavy I/O -- the serial printer port
really snows it up.  OSTERM, with its constant sampling of the ACIA, does do a
pretty good snow job.

Question -- do you have an old or new style GIME chip?  Old is (c) '86, new is
'87 I think.  I had lots of sparklies with my old GIME on just 512K.  New GIME
eliminated them all.  And they stayed away when I went to 1 Meg.

Now some lucky people had no sparklies under 128/512K even with their old GIMEs.

But if you're one of those, maybe the 1 Meg finally got to your old GIME.

OS course if you have a new GIME, well, try that trimpot resistor.

-*-

30569 8-JUL 01:01  General Information
     RE: 1 Meg problems? (Re: Msg 30563)
     From: DWHILL       To: RADARBUZZ

The regulator running hot to the touch is normal.  I'm surpised you can keep
your finger on it that long!  Mine's always run that hot with 512K.

On the other hand, the smell may be something besides the conductive good. Like,

maybe the transformer varnish.  That may not be a good thing.

--Damon

-*-

30597 8-JUL 17:37  General Information
     RE: 1 Meg problems? (Re: Msg 30563)
     From: RADARBUZZ    To: RAGTIMER

    Well, for the life of me I thought I had an '87 GIME, but after looking
again it's a '86 fer sure!

    QUESTION - How do I order an '87 GIME (RS part #?)and do you remember
roughly what you paid for the new one?

    Since I never had "sparklies" before and haven't had any wierd crashes since

the upgrade, the new GIME is all I need, I hope!

-Jeff


-*-

30598 8-JUL 17:37  General Information
     RE: 1 Meg problems? (Re: Msg 30569)
     From: RADARBUZZ    To: DWHILL

Damon,

    The HOT regulator I was referring to was the one on the 1-Meg board.  A long

time ago I swapped the small regulator on the COCO with a big 2N3055 mounted on
a massive finned heat sink.  I just might do the same for the 1-Meg board.  Gee,

if I was to wire another 2N3055 in parrallel with the first one, the second one
could power the 1-Meg board and I could eliminate that external Commodore(!)
power transformer that CRC sent with the kit.

-Jeff


-*-

30612 8-JUL 19:46  General Information
     RE: 1 Meg problems? (Re: Msg 30597)
     From: ZACKSESSIONS To: RADARBUZZ

I have 3 on order right now (gimes). Don't have the part number handy, can get
it tomorrow. Price is $21 and some change, each. To get one, go to your local
Rat Shack and ask the manager to order it for you from National Parts.

Zack

-*-

30625 9-JUL 18:34  General Information
     RE: 1 Meg problems? (Re: Msg 30612)
     From: RADARBUZZ    To: ZACKSESSIONS


Zack,
    Let me know that part# (GIME) if you can.  $21 sounds reasonable.  I'm not
in a real big hurry to order one, but - not having had sparklies before I think
I would rather not have to get used to them.       .     .
          .                   .                                        .
                    .
   .                                        .                 .

             .                 .                                         . -Jeff

<Grin>

-*-

30629 9-JUL 22:42  General Information
     RE: 1 Meg problems? (Re: Msg 30625)
     From: ZACKSESSIONS To: RADARBUZZ

Part number is MX0992, cost is $21.75 each. I hope you have better luck than nI
did, damn UPS lost mine, and they're having to re-order.

Zack

-*-

30638 10-JUL 02:57 General Information
     RE: 1 Meg problems? (Re: Msg 30598)
     From: OS9UGPRES    To: RADARBUZZ

A sidenote: I've been running the breadboard version (more chips) of the 1-meg
upgrade continously since we got it running back last fall... and using the
coco's normal internal power supply!

However, I don't have a cover on the machine (which helps ;-), and also I have
the CMOS 6309 cpu... which uses almost a watt less than the normal 6809. No
problems so far, powerwise. Might just be luck, tho <grin>.
 kev P/ex

-*-

30640 10-JUL 16:26 General Information
     RE: 1 Meg problems? (Re: Msg 30629)
     From: RADARBUZZ    To: ZACKSESSIONS

Thanx Zack, I'm gonna order one today.

-Jeff



-*-

30641 10-JUL 16:27 General Information
     RE: 1 Meg problems? (Re: Msg 30638)
     From: RADARBUZZ    To: OS9UGPRES (NR)

A whole watt less (6309 vs 6809)!?  I've seen some discussion about the 6309
here in the past. Interesting.

QUESTION: is the 6309 a direct plug-in replacement (same pin-out) for the 68B09
?  What's a good source to order one from?  Thanx,

-Jeff

-*-

30648 10-JUL 22:04 General Information
     RE: 1 Meg problems? (Re: Msg 30638)
     From: RAGTIMER     To: OS9UGPRES (NR)

Hey Kev, no fair!  Running with the case open is a dirty Commie (as in -odore)
trick.  "Warranty void if case NOT opened before using."  Grin?

-*-

30651 10-JUL 22:18 General Information
     RE: 1 Meg problems? (Re: Msg 30569)
     From: RAGTIMER     To: DWHILL

Yeah, my 1 Meg regulator is too hot to touch for more than a second or two. No
smells, tho. With the 1 Meg properly installed, and using that Communist
transformer, your Coco's transformer should be runnhjing *cooler*, since it
isn't running your 512K RAM anymore.  Unless the daughter board over the 6809
draws more than your 512 did.

I seriously considered feeding the 1 Meg regulator from the Coco's transformer
and rectifiers, but decided not to tempt the gods & demons.

-*-

30673 12-JUL 20:46 General Information
     RE: 1 Meg problems? (Re: Msg 30651)
     From: DWHILL       To: RAGTIMER (NR)

I dunno, that really ought to work, feeding the 1 meg reg directly.  Check the
specs on the regulator and the voltage rating on the capacitors, though. I'd
think that would take some strain off the main regulator quite neatly.

As you may have noted in my message to DALEP, I FINALLY got around to doing the
IRQ diode hack, and am running Xcom9, which is notorious for locking up. Be
interesting to see if this cures some of my problems.

--Damon

-*-

End of Thread.

-*-

30552 7-JUL 21:21  Utilities
     OS-9 Spooler
     From: AARONS       To: ALL

I'm in search of a spooler to use with CSG IMS database manager, I saw the
Spool.ar utility in the database but I do not have an assembler. Can someone
upload an assembled version? Is ther one comercialy available? Where?

Also, does anyone know the patch to allow Multi-Vue to Init. in HI-RES mode (80
colum)?

thanks,  AARONS

-*-

30553 7-JUL 21:46  Programmers Den
     SQRT Function in C?
     From: ZACKSESSIONS To: ALL

I have the need to use the sqrt() function in C. I have the latest Krieder lib
from the programmer's den. The docs state that there is an int sqrt(n) function.

When I try to link a program using it, I get an unresolved reference. dEd of the

clib.l sure enough shows there is no sqrt() function present. What gives?!?

Zack

-*-

30605 8-JUL 19:23  Programmers Den
     RE: SQRT Function in C? (Re: Msg 30553)
     From: RAYMAYEUX    To: ZACKSESSIONS

Did you look in clibt.l? -- Ray

-*-

30611 8-JUL 19:44  Programmers Den
     RE: SQRT Function in C? (Re: Msg 30605)
     From: ZACKSESSIONS To: RAYMAYEUX

Yeah, I'm using clibt.l know trying to use the double version of sqrt(), but
Mike Sweet reports potential problems with it, as well.

Zack

-*-

End of Thread.

-*-

30556 7-JUL 23:00  General Information
     High Horse
     From: XLIONX       To: ALL

Howdy All,

I don't do this very often...so hold tight.

Who the heck is PAULSENURIA to come out of nowhere about June 4th and claim the
RIGHTS to patches for shell v2.1 when they were on the forum with explainations
in April?

The patch to $1313 was from KNOT1 April-19. The patch to $130F was from OS9UGVP
April-21.

I don't mind people saying "For the good of the community I put this info
together, so here it is." but to claim RIGHTS to it (indignant pause)???

Sorry Paul, I don't buy it.

-Just blowing some steam.

-Mark W. Farrell -SIGOp ProSIG (Pinball Haven RIBBS v2.0) -XLIONX (DELPHI) -mwf
@SANDV

p.s. get used to it.

-*-

30580 8-JUL 03:53  General Information
     RE: High Horse (Re: Msg 30556)
     From: KNOT1        To: XLIONX

Thanks for the credit, Mark.

                     -Jamie (KNOT1)-

-*-

End of Thread.

-*-

30557 7-JUL 23:01  General Information
     High Horse
     From: XLIONX       To: PAULSENIURA (NR)

Please see message 30556 -mark

-*-

30572 8-JUL 03:16  General Information
     music
     From: BRIANWHITE   To: ALL

Is there anyone willing to photocopy and send me a copy of the Orchestra-90
documentation???  The docs that come with "Orchestra Master" are really poor and

just aren't good enough to write a conversion routine with.  Any help would be
appreciated.  Than x!

                             Brian C. White
                             P.O. Box 1565
                             Esterhazy, Sask.
                             S0A 0X0   Canada

-*-

30582 8-JUL 07:07  Programmers Den
     HINTS ON C COMPILER
     From: ALWAGNER     To: ZACKSESSIONS

ZACK,

I am sure that it is something I am doing wrong, but maybe you can steer me in
the right direction.  When I go to de-arc the subject archive, AR reports that
it is extracting dc.txt and then proceeds to dislpay all sorts of things on my
screen.  The exact pattern of garbage varies depending on whether I was in a
window or booted up to a vdg screen.  In either case, the system usually
crashes.  If I then reboot and look at the directory of the disk where I
expected the files, I find a file dc.txt with nothing in it.  I have de-arced
shell+ which I downloaded from DELPHI and had no problem at all.  I have read
and reread the docs on AR and can't find anything I'm doing wrong.  As was
mentioned above I've tried using AR from several different boot configuartions
and always get similar results.  (i.e., shell+, tandy shell, sdisk3, tandy cc3,
etc.) If you could shed some light on the subject or tell me whom I might ask
for help I would be very appreciative.

Thanks in advance,


AlWagner


-*-

30584 8-JUL 11:18  Programmers Den
     RE: HINTS ON C COMPILER (Re: Msg 30582)
     From: ZACKSESSIONS To: ALWAGNER

I believe the filename should be hdc.txt, not dc.txt. I'm sorry you are having
problems getting it de-archived, no one else has reported such a problem with
that file. How many times did you download the archive? If only once, try
downloading it again, sometimes that helps. In the meantime, I will download it
myself, to make sure there are no problems.

Zack

-*-

30585 8-JUL 11:26  Programmers Den
     RE: HINTS ON C COMPILER (Re: Msg 30582)
     From: ZACKSESSIONS To: ALWAGNER

I just downloaded the file and it de-arced just fine. I did get a warning from
ar that the file was "not archived or damamged", but that message from ar can be

ignored. The file is de-arced OK by that time. Try downloading it again.

Zack

-*-

30594 8-JUL 15:29  Programmers Den
     RE: HINTS ON C COMPILER (Re: Msg 30585)
     From: ALWAGNER     To: ZACKSESSIONS

Thanks for taking the time to check out the file.  As I said, Its got to be
something I'm doing.  Just what that is I'm not sure.  I did try down loading
the file more than once with similar results.  I'll try again and let you know
how I make out.

Thanks again,

AlWagner

-*-

30603 8-JUL 17:57  Programmers Den
     RE: HINTS ON C COMPILER (Re: Msg 30594)
     From: ALWAGNER     To: ZACKSESSIONS

I knew it was something I was doing!  The problem came from a source you could
not have known about.  Until this logon I was using MIKEYTERM.  A good program
but not OS9.  This meant that I had to convert everthing to OS9 before I could
use it.  Well, the conversion I was misusing was hacking off the beginning of
the file.  Hence the "dc.txt" rather than "hdc.txt". This last go 'round I tried

a different convert utility and presto-changeo it worked perfectly!  I did
notice the error message you warned me about, but as you said it did not seem
to      matter.  Thanks again for your time and efforts.

AlWagner


-*-

30609 8-JUL 19:42  Programmers Den
     RE: HINTS ON C COMPILER (Re: Msg 30603)
     From: ZACKSESSIONS To: ALWAGNER (NR)

You might want to consider downloading OSTerm, SuperComm, or even KBCom, from
the libs. Of course you'll need a RS232 if to use any of them.

Zack

ps, glad you got it de-arced OK. btw, I have made some improvements to that file

and plan to re-upload it. WIll post a notice in the Forum when it's done.

-*-

End of Thread.

-*-

30589 8-JUL 12:03  General Information
     Hardware help needed
     From: WB4GCS       To: ALL

I have a J&M disk controller which I bought at a flea market.  It appears to
have a parallel port in addition to the disk prot (which works fine!) Does
anyone have pinout and/or device driver information for the parallel port? Sure
would be nice to get away from the bit banger.  How about a schematic on this
thing?

All help gratefully appreciated. 73, Jim wb4gcs

-*-

30601 8-JUL 17:55  General Information
     RE: Hardware help needed (Re: Msg 30589)
     From: DODGECOLT    To: WB4GCS

Try looking in the Device Drivers database for a driver for that controller.
 -Mike

-*-

End of Thread.

-*-

30596 8-JUL 16:28  Programmers Den
     still sqrt() problems
     From: ZACKSESSIONS To: ALL

OK, I am now using clibt.l. So how come the following program:

#include <stdio.h> main() {
    double x, y;
    pffinit();
    x = 36;
    y = sqrt(x);
    printf("The square root of %f is %f\n",x,y); }

Gives the following output:

The square root of 36.000000 is 0.000000

Zack

-*-

30602 8-JUL 17:57  Programmers Den
     RE: still sqrt() problems (Re: Msg 30596)
     From: DODGECOLT    To: ZACKSESSIONS

Zack- try declaring the sqrt() function to double first- as the code you gave us

stands, the compiler will think that sqrt() returns an int...
 -Mike

-*-

30604 8-JUL 18:14  Programmers Den
     RE: still sqrt() problems (Re: Msg 30602)
     From: DODGECOLT    To: ZACKSESSIONS

Geez, I just tried getting the square roots of the first 100 numbers, and got
garbage results... Interesting, though, how the square root of 93 is
1389796441404211185.810524!
 :) Carl only frequents CIS, right?  Look like there _might_ be a _slight_
problem with that function!
 -Mike

-*-

30608 8-JUL 19:40  Programmers Den
     RE: still sqrt() problems (Re: Msg 30602)
     From: ZACKSESSIONS To: DODGECOLT

Thanks, Mike, Pete Lyall mentions the same thing.

Zack

-*-

30610 8-JUL 19:43  Programmers Den
     RE: still sqrt() problems (Re: Msg 30604)
     From: ZACKSESSIONS To: DODGECOLT

Uh, oh! I haven't tried the double declaration, yet, but will. If I encounter
similar problems, I will contact Carl and let him know of the problems!

Good eye!

Zack

-*-

30624 9-JUL 18:13  Programmers Den
     RE: still sqrt() problems (Re: Msg 30610)
     From: DODGECOLT    To: ZACKSESSIONS

Boy, now I can't even duplicate <my> problems!  After playing around with the
pow() function, I then tried to use the sqrt() function again to see if I could
find a pattern... Of course it just happened to work perfectly...  I hate
problems that come and go randomly!
 -Mike

-*-

End of Thread.

-*-

30606 8-JUL 19:31  Device Drivers
     Any RAM Disks larger than 512K?
     From: RADARBUZZ    To: ALL

Attention:

    If there is anybody out there that can set up a ramdisk larger than 512K,
please let me know what driver you are using.  Thanx

-Jeff


-*-

30689 13-JUL 20:55 Device Drivers
     RE: Any RAM Disks larger than 512K? (Re: Msg 30606)
     From: DENNYSKALA   To: RADARBUZZ (NR)


I don't know of any ramdisks that create > 512k ramdisks.  However, I am the
author of the one which Microcom sells/packages with their memory boards.  I was

considering fixing it to recognize the additional memory --- until I realized
that I would have no way of testing it myself.  It should be a fairly easy fix,
and I expect eventually that someone will complain that it won't do the extra
Disto memory, so I suppose I should fix the thing.  If you would be interested
in Beta testing a fixed version, let me know in email.  It might take a few
go-arounds and some upload/download time to get it right.

                                   ***** Dennis *****

-*-

End of Thread.

-*-

30616 8-JUL 22:21  General Information
     gime
     From: RADICAL      To: ZACKSESSIONS

How do you know if the coco has a new or old gime?   Len


-*-

30618 8-JUL 23:08  General Information
     RE: gime (Re: Msg 30616)
     From: ZACKSESSIONS To: RADICAL

Well, ya gotta void the warrenty (if it is still applicable) and open up the
case. If the GIME has a date of 1987 on it, it the newest one available.

Zack

-*-

30634 10-JUL 00:57 General Information
     RE: gime (Re: Msg 30618)
     From: RADICAL      To: ZACKSESSIONS

Thanks, my warranty was voided long ago.  I will check the date when I install
the 1 meg.  Thanks. Len

-*-

End of Thread.

-*-

30626 9-JUL 21:55  General Information
     GFX2 & MM/1
     From: COLINMCKAY   To: OS9UGPRES

Hi, Kev, and Paul.

Just a suggestion that others might find useful with the new GFX2
module you uploaded. Rename it to GFX3, as well as patching it and
updating the CRC, and you can continue using GFX2 and its calls.
Naturally, you now have to call it using RUN GFX3.

Anyway, thanks for releasing it. Appreciated by all locally.

Also have a few questions about the MM/1 (Oh, no. Not more questions
about the MM/1 <Grin!>)

The VSC chip (SCC66470) normally arbitrates access to the first meg of
memory that the VSC chip and the 68070 share. When the 68070 gets its
own 2 or 8 megs of memory, and the VSC no longer has to do arbitration,
does this then speed up the VSC chip? Or does the VSC continue doing
arbitration all the time?

A few people on the International CoCo and OS9 echoes have mentioned
that they have seen demos of the MM/1. Amongst other things, they
mentioned seeing 320*200*256 GIF files loading in "under one second"!
Are these amazing numbers accurate? Or was that some other format?

Any recommendations on monitors? I currently have a CM-8, but also need
a PC compatable monitor for working at home. I was considering buying
the NEC 2A. Its specs match fairly well the MM/1.

Alan Dekok wonders if you have seen his demo (CC3DEMO) which runs
under RSDOS. (He just called as I was writing this letter.) Bouncing,
spinning ball, four voice music, 1 inch high scrolling text across the
bottom of the screen. Pretty impressive, especially since it holds
about five minutes of text. Its over on the RSDOS side.

Also, the specs for the VSC chip make it appear to be almost trivial to
create a frame grabber. Any word on this? And GenLock also appears to be
trivial on this machine, at least the computer end. Any chance?

Does the second board come with the 2 meg of memory on board already?

Matt Thompson pointed out that it should be possible to have Microsoft
FlightSim V4.0 running using 100% legal system calls. That would be
impressive.

Finally, could you please detail exactly which resolutions are supported?
Some of the literature from KLE (MM/1 ad, July Rainbow) says 720*560 is
supported, while other literature mentions only (Only!) 720*480.

Thanks for your time.

Colin McKay.



-*-

30632 9-JUL 23:28  General Information
     RE: GFX2 & MM/1 (Re: Msg 30626)
     From: TIMKOONCE    To: COLINMCKAY

From earlier messages, it is the case that the CPU speeds up if it's not
competing with the VSC for memory.  i.e. getting more mem approx doubles the
speed of the machine.  Don't know what you mean by the "VSC speeding up".  Kind
of like asking if the GIME speeds up.
                - Tim

-*-

30639 10-JUL 02:58 General Information
     RE: GFX2 & MM/1 (Re: Msg 30626)
     From: OS9UGPRES    To: COLINMCKAY

Colin,

No need to rename the new gfx2 to gfx3, as it has all the original gfx2 commands

in it. However, I just popped in and read my mail, and someone said that a few
of the original gfx2 commands didn't work... has anyone else seen any problems?
Maybe I compiled in a bug <ouch> by accident.

Re: MM/1, VSC, etc -

When you add more memory, the cpu will no longer have to run programs from the
video ram. That immediately gives you roughly a 20% (or more) speed increase, I
think. Visible increase, that's for sure. Someone oughta rig up the same trick
on the coco (external ram or something).

Yah, the fast picture loads people see in demos are definitely not realtime GIF
conversions, but raw vef-style data. Right now, the GIF converter (written by
Mike Haaland for us) sends the data to standard output. That works pretty well,
as you can send it to a file, or pipe it straight to a picture loader/viewer.

Pictures are 64K long, so they can take a while to load off floppy, albeit
faster than the coco. Still, the DMA harddisk *really* screams loading in pics.
And you should have no problem loading in most sound files faster than the DMA
stereo sound hardware can play it, even off floppy.

I've heard lots about that CCDEMO, but it won't run on my computer (I hear
that's not unusual). Would love to see it sometime.

Any framegrabber will be external, I think. A genlock tho, we hope to plug into
the main board.

I don't think the second board comes with RAM (I could be wrong). Before long,
4-meg SIMMS will be pretty darned cheap, and I suspect the wilder types will
want to go straight to 9 meg ;-).

Both the FHL and the KLE video spec sheets seem to change all the time <grin>.
See, in PAL mode (overseas TV, versus the US's NTSC), you can go up to 768x560
or so. For us, it'll top out at 720x480... which will actually be our worldwide
standard, as the chip supports a PAL mode which allows viewing the smaller NTSC
resolution gfx (centered on screen).

So figure on 320x210, 320x420, 360x210, 360x420, 640x210, 640x420, 720x210, and
720x420 modes... where the 360/720 x-modes go from edge to edge and over (for
video overlays where you don't want a border). Actually, some monitors can show
the whole deal... the 720x480 gives you 90x60 char (8x8) text! However, the
flicker can be a killer in that mode, at least to me (depending on the colors
chosen). - kev

-*-

30674 12-JUL 20:53 General Information
     RE: GFX2 & MM/1 (Re: Msg 30626)
     From: DWHILL       To: COLINMCKAY

Those superfast load time for graphics ought to be accurate, as the 68070 has
DMA and can move blocks of data darnfast!  I need to pester Phillips for spec
sheets on it and the graphics chips to find out more, but I think the
performance is going to be very impressive, should give the '386 machines
something to be jealous of!

--Damon

-*-

30680 12-JUL 22:35 General Information
     RE: GFX2 & MM/1 (Re: Msg 30674)
     From: COLINMCKAY   To: DWHILL (NR)

I was impressed by the speed, just the messages that I saw implied that they
were compressed GIF pictures. That really would have been an impressive feat.
         However, loading 64k vef type files in that little time is quite impres
sive
too.

-*-

End of Thread.

-*-

30628 9-JUL 22:35  Applications
     name and address pgm
     From: CAPTSWOOSH   To: ALL

hey gang is there a free ware name and address database label pgm out there?
that is ready to run?? Ron done

-*-

30630 9-JUL 23:25  Programmers Den
     Speeding up the coco3
     From: NES          To: ALL

Here is a queston for you hardware hacker's, could I increase the cpu's speed of

the coco3 closer to 2Mhz or over, by add a new crystal, or would it screw the
video and disk? BTW I am useing a CM-8 if that makes any diffrence... also a
burk and burk harddrive.. Eric  -<NES>-

-*-

30633 9-JUL 23:31  Programmers Den
     RE: Speeding up the coco3 (Re: Msg 30630)
     From: TIMKOONCE    To: NES (NR)

The Video frequency is generated by the same clock that generates the system
frequency.  So, no, you can't just change the crystal. Speeding up the processor

would require some fairly elaborate circuitry to handle the speed difference
between the processor and the GIME, since you can't change the GIME speed
without messing up the video.
  The disk controller uses a separate crystal for it's clock, so that's not the
issue.
  Why do you want to get "closer to 2Mhz"??  1.89 is pretty durn close already.
              - Tim K

-*-

End of Thread.

-*-

30642 10-JUL 16:36 Device Drivers
     COCO2 WORD PROCESSORS!
     From: DKIRCHER     To: ALL

Help! I have a COCO2 system that is running  WORDPAK RS and I am looking for a
WORD PROCESSOR that will work with it. I already have older versions of
STYLOGRAPH and LASTWORD that use those graphics drivers or WORDPAK.
 Does anyone have an updated version they would like to sell or perhaps maybe
know of a patch that will do the trick.
 If someone has a WORKPAK they'd like to part with that'll work too
  thanx
      dlk

-*-

30643 10-JUL 16:42 General Information
     Upgrading Coco II
     From: DKIRCHER     To: ALL

  I just fired up my old gray coco and found out that coco is a collectors item.

So I have found two other coco IIs as backups for when the parts really dry up.
I would like to know how to
 get these two guys up to speed for disk operation. Is an ECB upgrade all they
need to accept a disk controller? Radio Shack was not very much help.

-*-

30668 12-JUL 02:16 General Information
     RE: Upgrading Coco II (Re: Msg 30643)
     From: WAYNELAIRD   To: DKIRCHER

dk, what can help is downloading and using the dmode utility by K.darling. works

good on the two as well as the three. this canspeed up your disk access time to
6ms. best ,wayne

-*-

30669 12-JUL 03:22 General Information
     RE: Upgrading Coco II (Re: Msg 30668)
     From: DKIRCHER     To: WAYNELAIRD (NR)

Oh No, the prob here is the cocos aren't seeing the controller in the port I'll
plug it all in and fire it up but only get a COLOR BASIC prompt. So I presume
that they must have ECB before they will "see" the disk controller to access
DISK COLOR BASIC.
 I've been flogging my poor old drives with the debug patch for some time now.

-*-

30670 12-JUL 03:40 General Information
     RE: Upgrading Coco II (Re: Msg 30669)
     From: DKIRCHER     To: ALL

 Alright, The old ECB roms have all sold out. I'm gonna take the plunge and
eprom my own. Having never done this I have three questions.
    Is all this necessary to get the disk controller to work
    I'm dealing with both the old and the new Korean coco's and I've
 noticed that one has a CB rom and an empty sockett and the other
 has a CB rom in a socket. Is the upgrade for the two of them to ECB
 the same.
    Last question: I have no desire to EVER mess with CB or ECB again after
playing with basic09 it's just not the same. So as long as I'm playing with
EPROMS why not prom os9 and be done with it. Assuming this is possible without
too many contortions how would one go about this. Thanks for your help dlk

-*-

End of Thread.

-*-

30652 10-JUL 22:20 General Information
     GFX2/MM/1
     From: COLINMCKAY   To: OS9UGPRES (NR)

Hi Kevin.

About renaming GFX2 to GFX3: I was bitten by one of those bugs, and without
thinking, automatically decided to rename. I was running depthcharge, and
it quit with an error which I assumed was caused by GFX2 commands not being
found. Ran it with the old GFX2, and it worked, so I renamed/patched the new
module to GFX3. Will try to duplicate the error if you wish.

Unfortunate that the raw picture files weren't gifs. That woulda been REAL
impressive. C'est la vie. Glad to hear there will be a gif converter available
tho.

Eagerly looking forward to the arrival of the new machine.

TTFN. Colin.


-*-

30655 11-JUL 01:09 Telcom
     Hardware Downloading Problems
     From: THET         To: ALL

   I don't know if this question has been answered or not, but I figure it's
better to ask than take a lot of time reading a lot of messages.  Here's the
problem:
  I have added an ACIA 6551 board to my CoCo 3 (from the May 1989 Rainbow)
  and now I can use OS9 to telecommunicate just fine from the bit-banger port
  with no problems except one. I can't download! I am using Supercomm v2.1 and
a 1200 baud modem. I have tried it with a friend of mine's computer with Procomm

+ which I know works, and severa;l bulleten boards and DELPHI and I get the same

results, the fi rst block goes fine, but after that all I get is errors.
 This happens with Xmodem, Ymodem, and Ymodem batch, and Kermit.  The really
strange part is that using Gregterm unter RSDOS Xmodem works fine, but the
program usually crashes the machine after a download right after I save the
buffer to disk.    Any solutions. Please answer as having a modem but being
unable to download can be a drag!!
    Thanks.

-*-

30657 11-JUL 03:58 Telcom
     FIDO Hawaii
     From: TOMMIETAYLOR To: ALL

Hawaii Coco Users, Coconuts bbs Of Hawaii now supports FIDO International Mail
service. 808-845-7054 300-2400 baud...

-*-

30659 11-JUL 20:31 Programmers Den
     boot disk
     From: DCJR         To: RADICAL

Actually, I *should* have said booted with a double-sided descriptor. Using
dmode gave the same result. BUT, the other point I needed to emphasize is that
there MUST be a cmds dir on the boot disk with shell and grfdrv in it.

Doug James

-*-

30665 12-JUL 00:55 Program     RE: boot disk (Re: Msg 30659)
     From: RADICAL      To: DCJR

Too bad you can't underline that and put it all in capitals.  I found out early
in the game, but screamed for help many times before catching on. Left /dd out
of the confgaooc,n n myself in circk opps  circles trying to find
out what was wrong.  Len


-*-

End of Thread.

-*-

30664 11-JUL 22:25 Patches
     step Rates
     From: JANG         To: DISTO (NR)

Hello Tony,
 I just installed a Seagate ST-125 3.5" 20 Megger under Level II and it is
working fine with your "Hard Disk Adapter".. in slot#3 I also run my 2 floppies
with your SC II and it has your clock now too!!! The question is this: Using
"HardwareHackers" DMode /h0 I see I have a step rate there of step=0.. The
ST-125 Manual says it will accept step rates 3-200. Any attempt on my part to
dmode /h0 (higher step rate) results in errors although step=7 worked OK for a
while and the thing flew!! I have EZGen and ded, but can you offer any other
course of action here ??
                                                                      J.Angus
                                               Levittown,NY

-*-

30666 12-JUL 01:01 Device Drivers
     clock
     From: RADICAL      T my controller back and all is working fine. Just
wanted to know about the clock as I do not have your catalog.  Len

-*-

306J :1GeaIfmto  E BTOESI(eMg01)  Fo:ANAR T:SBR(Rl h apswnyur ?Hvyuopr hmdl norhrdv o?a at rgti  cn c3mn  ys id.bs,ye

-

0671 12-JUL 20:03 General Information
     Windows under level II...
     From: ALANDEKOK    To: ALL

 I was wondering if anyone could help me....  I have a Basic09 program that
defines 2 output graphics windows (ala Kevins bouncing ball demo), but it
doesn't seem to work quite right.  Here's the code, and an explanation of what
happens.

 OPEN #W1,"/w"
 OPEN #W2,"/w"
 String=CHR$(  1b 20 08 00 28 18 0f 00 00 (* new device window 320x192x16 colors

 PUT #W1,String
 PUT #W2,String

 This works fine the first few times I try it, but as I'm adding/debugging the
program, the above code gets executed many many times.

 The problem is, after a while, I get an ERROR 184 (window already defined) on
the first PUT statement.  Is there anything I can do about this?? Or what am I
doing wrong?  The manuals seem to say that this is all legal, but my system
doesn't like it.

 Alan DeKok.

-*-

30675 12-JUL 21:02 General Information
     RE: Windows under level II... (Re: Msg 30671)
     From: GREGL        To: ALANDEKOK

Alan,

    You need to DWEnd and close the windows at the end of the program. Otherwise

you'll use all of the descriptors and the program will quit working. If all the
descriptors are used (all windows are in use), you obviously can't use any
others.

    -- Greg

-*-

30681 12-JUL 23:11 General Information
     RE: Windows under level II... (Re: Msg 30675)
     From: ALANDEKOK    To: GREGL

 Yeah, I just figured that out.  Boy do I feel dumb.  When I took a look at it
(via DDIR), I saw it was consistently trying for the same two windows, which
were left over from its LAST failed attempt, and it didn't like that one bit.

 Anyways, I've now got the DWend and CLOSE in there, and it seems to work better

already! (grin)

 Alan DeKok.

-*-

30682 12-JUL 23:14 General Information
     RE: Windows under level II... (Re: Msg 30681)
     From: ZACKSESSIONS To: ALANDEKOK (NR)

To be safe, I always DWEnd a new window I just opened a path to before I try to
DWSet it. Seems to work just fine.

Zack

-*-

End of Thread.

-*-

&@Y6 L-ULR"
!M5R$H jRPU$
$ HHI=5iRJjH "uK KSCALES

Hi Ken-
 I tried your SASI Driver Patch and have trouble booting with it. I use the HDA
in Slot # 3 for my ST-125(20Meg) and Later added the SC II and use cc3disk.slp
there. I patched my current cchdisk($A50917) and did the attr e pe on it and
then EZGen'd it into
 a backup of my boot and everything seemed to go well..but
 no boot !! Is the MPI upgrade neccessary?? any suggestions???
                                                  Jerry Angus


-*-

30677 12-JUL 21:28 Graphics & Music
     RE: Who did "VEFIO" ? (Re: Msg 29872)
     From: THEFERRET    To: TIMKOONCE (NR)

  I would like something that I could use in a P.D. Graphics editor. (Yes I know

Max-9 is out here, but mine is better, so there!) I just can't get bvefio to
work for me, apart from using the + option
Ug

-*-

30683 12-JUL 23:16 Graphics & Music
     RE: Who did "VEFIO" ? (Re: Msg 30677)
     From: ZACKSESSIONS To: THEFERRET

VEFIO was written by Ron Lammardo. He is not on Delphi, but is on CIS.

-*-

End of Thread.

-*-

30679 12-JUL 22:06 Patches
     b&b + PBJ CC-BUS
     From: SALZARD      To: ALL

Has anyone successfully mated Burke and Burke's Hard Drive interface with the
PBJ CC-Bus (six slot multipak)????  Need a patch to BBFHDISK so that it can find

the slot that the interface is plugged into.

-*-

30685 12-JUL 23:28 General Information
     Shell+ 2.1 patches
     From: XLIONX       To: ZACKSESSIONS

Howdy Zack, Please read message# 30556 and let me know if you think I am
justified in my rantings. ];->

-Mark W. Farrell (PegaSystems) -SIGOp ProSIG (Pinball Haven RIBBS) -XLIONX
(DELPHI) mwf@SANDV

-*-

30688 13-JUL 19:19 General Information
     RE: Shell+ 2.1 patches (Re: Msg 30685)
     From: ZACKSESSIONS To: XLIONX (NR)

I read the message just after you posted it. I haven't downloaded that file you
mention, but judging from you comments, I certainly feel you're justified. I
will download the file and follow up on it.

Zack

-*-

End of Thread.

-*-

30687 13-JUL 01:20 Telcom
     os9bbs
     From: EMTWO        To: ZACKSESSIONS

Zack WE got Both your accounts set up<grin>. I will email you with your
passwords.

-*-


FORUM>Reply, Add, Read, "?" or Exit> bye
I don't understand the term "HBYE" in this context.
You may enter ? to view the full menu.

FORUM>Reply, Add, Read, "?" or Exit> bye
Highest message read: 30691.