textfiles/messages/ALANWESTON/1990/CIS07_16.txt

#: 5244 S1/General Interest
    16-Jul-90  00:58:47
Sb: #5183-Member List
Fm: Tony Cappellini 76370,2104
To: Steve Wegert 76703,4255 (X)

Thanx Steve. I guess I'll just manually compile a list from all my old CIS
sessions. TC

#: 5245 S1/General Interest
    16-Jul-90  01:01:05
Sb: #5230-Member List
Fm: Tony Cappellini 76370,2104
To: Jim Peasley 72726,1153

Thanx Jim. That sounds like it is just what I need. I still would like to get
your view program working. IT has some nice features. TC

#: 5246 S3/Languages
    16-Jul-90  02:10:09
Sb: #5212-Kreider clib docs
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)

Mark,

Okay, I'll look for the new files later. Then I guess I just have to print it
all out....

BTW, the copy of sgstat.h I have has the RBF stuff in it, without a structure
tag. Also, the members for sgbuf must have a few different names than the
scfstat.h you are using. I got all the header files for Carl's library when I
dl'd the library. They were included in the archive. I'll have a look at
header.ar as per Jim's suggestion.

#: 5247 S12/OS9/68000 (OSK)
    16-Jul-90  03:45:04
Sb: #5221-TOP - Munich Release 2.0
Fm: Wayne Day 76703,376
To: Ed Gresick 76576,3312 (X)

Ed,

I've massaged things a bit to get you some more space... let's see what you can
do with that, and if you need more, let me know and we'll request more from
CompuServe.

Sorry we have to do it this way, but CompuServe has gotten rather picky on
space allocations as their popularity has grown and new resources come online,
so....

Wayne

#: 5249 S12/OS9/68000 (OSK)
    16-Jul-90  05:16:45
Sb: TOP - Munich Release 2.0
Fm: Ed Gresick 76576,3312
To: [F] Wayne Day 76703,376 (X)

Sysop!

Uploaded top11 and top12 files this morning.

Ed

#: 5250 S3/Languages
    16-Jul-90  06:11:21
Sb: #5227-#Clib Documents
Fm: Mark Griffith 76070,41
To: Ken Drexler 75126,3427

Ken,

Hmmmmm.....it appears that my copy of the mroff docs has been tuncated. I'm
missing everything from section 7.1 on and the archive was lost a couple years
ago.  Perhaps someone else has a good copy and can upload it here.  I always
looked at my printed copy so I never noticed. Sorry.

Mark

There is 1 Reply.

#: 5259 S3/Languages
    16-Jul-90  16:23:45
Sb: #5250-Clib Documents
Fm: Zack Sessions 76407,1524
To: Mark Griffith 76070,41

Look for it in email.

Zack

#: 5251 S10/Tandy CoCo
    16-Jul-90  06:11:24
Sb: #5239-CM-8 service manual?
Fm: Mark Griffith 76070,41
To: James Jones 76257,562 (X)

James,

You can order the service manual from Radio Shack.  I have one and it is pretty
complete, as are all the RS service manuals.  The color convergence procedure
is fairly short, but you need a program to generate a crosshatch pattern. 
Should be simple enough.

Mark

#: 5252 S15/Hot Topics
    16-Jul-90  07:34:30
Sb: #5241-32 bit bus?
Fm: Mark S 76004,373
To: Frank Hogg 70310,317 (X)

I think you are getting confused with Address size Vs. Data path size. I am not
commenting on any particular system architecture only your comment That a 16
bit cpu wont work on a 32 bit buss. I agree the use of a 16bit buss is the
right thing to do. However I think any architecture that removes any of the
addressing from the system bus and makes it CPU access only is basicly flawed.
Besides you should be using some sort of cache controler to make up the
difference.

#: 5258 S15/Hot Topics
    16-Jul-90  15:42:00
Sb: #5233-32 bit bus?
Fm: Kevin Darling (UG Pres) 76703,4227
To: Frank Hogg 70310,317 (X)

Ummm. Pretty pointed "PS", Frank.

Isn't that caller's question best answered by KLE, rather than in your own Q&A
file?  Personally, I don't think that either company should upload info about
the other's machine (yet). Even well-meaning answers can be misleading, being
based on changing specifications. So I believe that each company should talk
ONLY about what it knows right now: its own hardware.

I suspect that _both_ companies would benefit from such a policy at this time.
Of course, if each company wishes to release me to talk about the status of
_all_ their pending plans, I'd be than happy to indulge in some fair slicing
through of the hype on both sides, myself <grin>.

In any case, the info I have is this: The MM/1 normally would use a 16-bit bus
with 16-bit peripherals (those can also be used on the 32-bit bus, natch).

There will be a shared-RAM adapter for the two main MM/1 cards to plug into a
larger 32-bit bus... allowing multiple MM/1s to coexist with a 68030, much in
the same way that multiple TC9s coexist with your K-Bus 68030. So the MM/1
isn't "discarded". I guess it would primarily be used as an intelligent
gfx/sound/io device once a 68030 is added.

New Q's: What happens to a person's TC70 when he upgrades to a 68030 on the
K-bus? And what calculations were used to show a 68030 using 16-bit RAM slowed
only 5% over using 32-bit RAM? Or was that only when accessing peripherals?

#: 5255 S10/Tandy CoCo
    16-Jul-90  12:49:32
Sb: #5223-#Memory Size Testing
Fm: Kevin Darling (UG Pres) 76703,4227
To: DENNIS SKALA 73177,2365 (X)

Nah, that one unusual thing (D.BlkMap+2 = end of map) with no name is about all
I can think of which isn't documented somewhere... and normally no one has a
need for it. Which reminds me <grin>, whatcha up to?

There is 1 Reply.

#: 5266 S10/Tandy CoCo
    16-Jul-90  20:31:56
Sb: #5255-Memory Size Testing
Fm: DENNIS SKALA 73177,2365
To: Kevin Darling (UG Pres) 76703,4227

Well, what I'm up to here is to make my/Microcom's Coco ramdisk compatible with
the Disto memory.  No complaints yet, but should be easy enough.

Other than that, I'm not up to much of anything --- just trying to make a buck
in the everyday job.

                            ***** Dennis *****



#: 5256 S10/Tandy CoCo
    16-Jul-90  14:12:02
Sb: #4935-Ledger
Fm: Joseph Cheek 76264,142
To: David Sanchez 76200,2476

RunB doesn't have to be at the end, perhaps I just listed it at the end
accidentally.  As long as it is in memory when you run ledger or is in the
execution directory under the name RunB (with RunB being the FIRST module) it
will work fine.

#: 5257 S10/Tandy CoCo
    16-Jul-90  14:13:44
Sb: #4959-Ledger/no prob after all
Fm: Joseph Cheek 76264,142
To: David Sanchez 76200,2476

glad to see you figured it out.  yes, editing is planned for a future version,
and also budgeting.  If you have any other problems, please let me know and I
will try to assist you.

#: 5260 S7/Telecommunications
    16-Jul-90  17:57:29
Sb: #4930-WIZ Query
Fm: MOTD Editor..Bill Brady 70126,267
To: Ches Looney 73016,1336

Well, I'll be durned, I bought a 1100FD also... & also to replace the m100!
Procomm eh? I've been using COM-AND, not very happily. On the job, Cecile
finally got wise, I am now our (one & only) product manager. (Our drivers
licence testing system). Mebbe I can keep somebody from running off with the
thing. We are doing a show in Baltimore this week. On the Wiz question. You can
edit the autolog file... you should see a #E15 ... the #E defines the break
key, the 15 is control-O. (note 15=decimal) You could also set it on-line & do
a <S>tart new autolog file. etc. Cheez, now I know why I wanted off HST! Sad,
sad. But I understand fully why it happened. I guess our favorite campus is
headed for a downturn. BTW, I *do* like the built in TEXT & Spell checker.

#: 5261 S7/Telecommunications
    16-Jul-90  17:58:03
Sb: #4930-WIZ Query
Fm: MOTD Editor..Bill Brady 70126,267
To: Ches Looney 73016,1336

BTW, got any copy for the MOTD? I could use some.

#: 5262 S7/Telecommunications
    16-Jul-90  17:58:55
Sb: #4957-Wiz Query
Fm: MOTD Editor..Bill Brady 70126,267
To: Ches Looney 73016,1336

Oh, yeah, I sure forgot that one quick... I just uploaded it. Old age eh?

#: 5263 S5/OS9 Users Group
    16-Jul-90  18:00:42
Sb: MOTD
Fm: MOTD Editor..Bill Brady 70126,267
To: all

Anyone got any material for the MOTD?

#: 5264 S10/Tandy CoCo
    16-Jul-90  18:38:41
Sb: #5217-Dedicated CoCo3
Fm: Lee Veal 74726,1752
To: LARRY OLSON 72227,3467

"Awfully expensive" is, of course, relative.  Seems like I remember that Radio
Shack used to carry a UPS that would keep up on of the Model 16 behemoths for
about 15-30 minutes.  The price in relation to the Mdl 16 was a drop in the
bucket, as I recall, but to a CoCoist it might seem out of reach. It's been too
long ago for me to quote a price, besides, I'm not even sure they carry them
anymore.

Lee

#: 5265 S10/Tandy CoCo
    16-Jul-90  19:44:15
Sb: OS9 Level 2 Upgrade?
Fm: KENHEIST 71750,551
To: all

I heard alot and I heard alot and I heard somemore and then I heard nothing so
...... what is the current word on the upgrade of OS9 Level Two???? Anyone
know????? Sure would like some GOOD NEWS!

#: 5267 S9/Utilities
    16-Jul-90  20:32:55
Sb: #5167-BURKE&BURKE + PBJ CC-BUS
Fm: DENNIS SKALA 73177,2365
To: RODGER ALEXANDER 75366,556

I wouldn't recommend using the B&B interface with the PBJ CCBus.  It was the
death of mine, and the reason I finally broke down and bought an MPI.

First problem is that you need to add the 12 volt DC circuit to the CCBus (or
power the HD interface card with a separate 12 VDC).  Then because the CCBus
doesn't switch the SCS and CTS lines separately, you must use a floppy
controller which is fully decoded to $FF4x, so that it doesn't conflict with
the B&B interface, which is at $FF5x.  This means no Tandy floppy controller,
as well as many others.  Or --- you could fully decode the offending floppy
controller.  I did that, and it's fairly easy.

I don't recall having to patch any software for the sake of the hard disk
interface itself (of course to use the CCBus with OS9, a few system patches
were required for other stuff).

When I put the whole thing together, it worked for about 15 minutes and blew
out the average size wall transformer.  I found the absolutely biggest one of
the proper voltage, rigged a plug to it, and gave it a try.  It held out, but
ran super hot too.  I used this setup for a while until I noticed that the
power supply on the CCBus board was running so hot that it melted the plastic
cover.  The standard PC hard disk interfaces are apparently quite power hungry
At that point I gave up and got the MPI.  A *LOT* more reliable (if physically
more inconvenient).

Give a yell if you need more specific information.

                          ***** Dennis *****

#: 5268 S15/Hot Topics
    16-Jul-90  20:44:07
Sb: ##5233-32 bit bus
Fm: Kevin Pease 70516,1633
To:  70310,317



        Frank I have been reading the mail on the sidelines for a long time and
not comenting. First the 32 bit bus is something that over the next few years
will become necessary to suport new hardware and graphics standards. The way
this works is the MM/1 uses a 16 bit bus. So the MM/1 is using only half of the
32 bit bus. Eventually 68030's and 68040's will become more popular and the
need for a 32 bit bus will become aparent. Since we have a 32 bit bus defined
as part of the MM/1 specification the people that have bought boards for the
MM/1 will not be stuck with un-usable hardware. It wil plug in and be useable
by the new 32 bit processors. So the 32bit bus definition is so that people
don't have to throw away the boards that they may buy. I have never read the
ads by Paul but they probably should read that the MM/1 bus has been define for
full 32 bit operation. Also the 68040 does not suport dynamic bus sizeing. What
this means is that unless one uses a verry large amount of hardware external to
the processor to simulate the 68030/68020 automatic bus sizeing one can only
access a 16 bit wide device as a word aligned word access or properly aligned
byte access. One can not access the device as a 32 bit device and have the
processor make the two accesses that would be required to assemble the long
word. what this means is that if one has a 16 bit graphics board one could only
use word accesses to move memory around. with instruction execution overhead
the move would be slower than if the device was 32 bits wide. It would take 2
times as long to do the same size move.
        I don't know how you made the calculatins but they are verry
misleading. if one is moveing more than a few bytes of data around the 32 bit
bus will be two times as fast as the 16 bit bus for the same bus access speed.
Example: bus speed is 100 ns. on a 16 bit bus to move 1000 bytes it would take
500 accesses or 50000 ns. The same 1000 bytes would require 250 accesses or
25000 ns. the instruction over head for the two moves would be identical
assuming that the processor had an instruction cache. This explanation is a
little over

There is 1 Reply.

#: 5269 S15/Hot Topics
    16-Jul-90  20:45:37
Sb: #5268-#5233-32 bit bus
Fm: Kevin Pease 70516,1633
To: Kevin Pease 70516,1633

simplified but to go into any more depth would require more space than a
message would allow. The actual increase in speed would be somewat less but it
is obvios that there is more than 5% increase in speed. Since a large part of
data processing is moveing data around the 32 bit bus would be superior. Since
these two machines are intended for graphics nad sound manipulation a 32 bit
bus is definately superior and will become aparent when a 32 bit processor is
put on the market.



PS Frank instead of competing with paul and makeing machines that are similar
why don't you distribute the MM/1 much like you distribute the TC70 by
hazlewood. It seems that if you two would join forces it would be much better
for the whole coco comunity.

                Kevin Pease
        70516,1633



Press <CR> !>