
Scanning !.........
[36m
Public Message 
[36mMessage # 247 *MM1_TECH Echo*[32m
To      : All
[33mFrom    : Warren Hrach
[35mSubject : linkup12 macro CR's
[37mDate    : 96/05/31 09:27:54[33m

I finally found the magic letter combo to make a linkup12 macro send a
CR.
I really did not find myself but asked Boisy.  All that is needed is the
following '\n' directly appended to the macro.
I should have also asked what to add for a 'wait for char' and pause but
forgot those niceties.
This is differant than Kterm and Osterm which use '\r'.
This is not covered in the present docs.
 
Warren Hrach, RiBBS/RiBBS_MM1 beta sysop.
 
[37m--- RiBBS OSK Beta
 * Origin: Ocean Beach RiBBS_MM1 support BBS (619) 224-4878 (1:202/745.1)


[36m
Public Message 
[36mMessage # 276 *MM1_TECH Echo*[32m
To      : Dave Kelly
[33mFrom    : Warren Hrach
[35mSubject : Re: MGR windows
[37mDate    : 96/06/02 10:38:05
[32mPrevious Reply is Message [33m272   [33m

               On Tuesday, May 14th, 1996 - Dave Kelly wrote:
 
DK> Is there a library for MGR? Something to write code with to do 
DK> overlay windows and such. How about documentation?
 
Dave,
    See next msg.
Warren
 
[37m--- RiBBS OSK Beta
 * Origin: Ocean Beach MM/1 Support BBS (619) 224-4878 (1:202/745.1)


[36m
Public Message 
[36mMessage # 277 *MM1_TECH Echo*[32m
To      : Dave Kelly
[33mFrom    : Warren Hrach
[35mSubject : MGR windows
[37mDate    : 96/06/02 10:40:05[33m


Dave,
      Here is a copy of the index and read.me from syscon-ind.com.
If you see something that I don't have let me know and I can get for
you.  BTW I was told Chris Hawks is working on an desktop for the MGR
for the MM/1b and/or 306.
      Have you been able to use MGR at all ?.
--------------------------- cut here ---------------------------------

   Size     Date     File Name                  Description
------- ------------ -------------------------- -------------------------------
    214 Jan  3 20:37 Read.Me                    occasionally current information

  19814 Jan 12 01:39 mgr-apps/ico.gz            "bouncing polyhedron" demo program
                                                which runs in an mgr window
    237 Jan 10 09:01 drivers/prsnam.gz          better version of prsnam
   8858 Apr 30 09:31 drivers/partition.tar.gz   IDE driver that handles
                                                partitions and has longer
                                                timeout (stops #000:175)
   2918 Apr  9 06:26 drivers/sc68306_38.lzh     driver for 68306 serial ports
   1792 Jan 11 23:14 drivers/sc87303_3.lzh      driver for 16550 serial ports
    643 Jan 11 23:15 drivers/scp87303_2.lzh     driver for parallel port
   2325 Apr  4 08:38 drivers/scsi1505.gz        Adaptec driver for 15xx card that
                                                does 8 bit I/O but does work.
   3432 Jan 11 23:15 drivers/scsipas16d_1.lzh   driver for sound blaster scsi port

  11781 Jan 10 09:01 mgr/defs1.tar.gz           /dd/defs/mgr/* - has macros needed
                                                to do mgr apps
  30462 Jan 10 15:52 mgr/1to7xX.lzh             fonts 1x? through 7x? pcl
  88037 Jan 10 15:52 mgr/8xXp1.lzh              fonts 8x? part 1 pcl
 103853 Jan 10 15:52 mgr/8xXp2.lzh              fonts 8x? part 2 pcl
 119060 Jan 10 15:52 mgr/8xXp3.lzh              fonts 8x? part 3 pcl
  95072 Jan 10 15:52 mgr/8xXp4.lzh              fonts 8x? part 4 pcl
 108438 Jan 10 15:52 mgr/9to10xX.lzh            fonts 9x? through 10x? pcl
 113335 Jan 12 16:42 mgr/11to18xX.lzh           fonts 11x? through 18x? pcl
  85038 Jan 12 16:42 mgr/19to29xX.lzh           fonts 19x? through 29x? pcl
  85862 Jan 12 16:42 mgr/30to99xX.lzh           fonts 30x? through 99x? pcl
  47094 Jan 20 13:11 mgr/cat.tar.gz             man pages in plain text
  42204 Jan 20 13:11 mgr/doc.tar.gz             man pages with underline & etc.
  10567 Jan 20 12:41 mgr/loadfont.gz            loads a new mgr font
   7344 Jan 10 09:01 mgr/mgr.l.gz               lib used for mgr apps
  81361 Jan 10 09:01 mgr/mgr10.gz               ed. 10 of mgr.  faster scroll,
                                                -v and -f fixes
  10504 Jan 20 12:42 mgr/selfont.gz             loads a new mgr font
   1589 Jan 20 12:42 mgr/testmouse.gz           _really_ dumb mouse test util
  53672 Jan  4 14:40 mgr/mgr_man.lzh            prelim programmer's manual
  24632 Jan 10 09:01 mgr/misc.tar.gz            termcap, terminfo and etc.
   1028 Jan  5 16:48 mgr/ptys8.gz               ptys - necessary to run mgr
 805348 Dec 29 23:20 mgr/sys.tar.gz             /dd/sys/mgr/font and /dd/sys/mgr/icon

   6900 Apr  4 08:39 utils/ideutils.lzh         First try utilities for new
                                                rbide that handles partitions.
  80314 Jan 28 12:51 utils/less290.tar.gz       'less is more'
   6393 Jan 20 12:42 utils/scmode.gz            vcmode for serial devices

   6312 Jan 15 07:48 vc/api.doc                 docs on the VC API
   2253 Jan 15 09:25 vc/defs.tar.gz             defs files for programmers
   2180 Jan 20 12:42 vc/modes                   latest version of mode sheet
   1199 Jan 10 09:01 vc/lib1.tar.gz             libs associated with VCs
  17073 Jan  5 16:45 vc/vc8.tar.gz              ed. 8 of the VCs
  20443 Jan  3 20:35 vc/vc9.tar.gz              ed. 9 of the VCs
  10104 Jan 10 09:25 vc/vc10.tar.gz             ed. 10 of VCs - does 1024x768x256
  13279 Jan  5 17:32 vc/vcmode.gz               latest vcmode

------------------------- end index start uploads ------------------------
   Size     Date     File Name                  Description
------- ------------ -------------------------- -------------------------------
   8858 Apr 30 09:31 drivers/partition.tar.gz   IDE driver that handles
                                                partitions and has longer
                                                timeout (stops #000:175)
------------------------- end attachments -----------------------------

BTW try to get my name spelled right ! ; Warren Hrach
Good luck,
Warren Hrach, RiBBS/RiBBS_MM1 beta sysop, MM/1, MM/1b sales rep.
 
[37m--- RiBBS OSK Beta
 * Origin: Ocean Beach RiBBS_MM1 support BBS (619) 224-4878 (1:202/745.1)

[37m
[31m=*= [32mFIDO ECHO MESSAGES MENU [31m=*=[36m

<1> Scan  \
<2> Read   > OS9 Echo mail             
<3> Leave /
<4> Scan  \
<5> Read   > CoCo Echo mail
<6> Leave /
<A> Scan  \
<B> Read   > MM1_TECH Echo Mail
<C> Leave /

<G>o back to Main Menu
<P>revious Menu (Messages Menu)

[35m[[37m59[35m][33m Command [37m>>> 
[36m
Public Message 
[36mMessage # 128 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : Rick Truell
[35mSubject : A BUNCH OF STUFF
[37mDate    : 96/05/22  23:58:00[33m

Greetings and salutations, Merv!!

 MC> Just stumbled across a couple of messages from last Aug when we were
 MC> discussing your proposed changes to Arc.  Wondered if that was still
 MC> on the back-burner?

Gads...you *do* keep messages for a while, don't you <grin>!! Yeah, it
sorta got indirectly put on the back-burner. However, with the recent talk
of making some changes to Scribe, I've started working on Arc again as
well...I want to get Arc working the way I want it to before starting to
work on Scribe.

I can't remember everything I was mentioning that I was going to do to Arc
and whether I got it done or not. Could you post the relevant parts of
those messages to refresh my memory? Thanks.

Rick                         Cruising the Universe at Warp 14.4!!
Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca

... Basic programmers never die. They just GOSUB without RETURN!
[37m--- GoldED/386 2.50 UNREG
 * Origin: Rick's Point Of Procrastination (1:342/42.8)

[36m
Public Message 
[36mMessage # 130 *OS9 ECHO*[32m
To      : All
[33mFrom    : Alan Dekok
[35mSubject : More potential RBF fixes
[37mDate    : 96/05/23  08:20:00[33m

 This is of interest especially to Erik Tromp and Curtis Boyle...
 
 What's it worth to speed up RBF substantially?  Adding a R+W cache makes ¨a
HUGE difference, which Chris Dekker has already done.  Now all I've got ¨to do
is add that code to the main-stream Nitro RBF.
 
 In addition, there are 2 other things I'd like to try, both involve the
¨allocation bitmap.
 
 One: Keeping a cache in-memory of free sectors in the allocation bitmap. ¨
This would take 2 pages out of system memory for each hard drive (not
¨floppy), but would make RBF do a 'best-fit' instead of 'first-fit'
¨algorithm.  This could also be coupled with additional code to allow
¨segments to contain more than 1 allocation bitmap sectors worth of
¨sectors... but I don't know how feasible that is.
 
 Two: Spread the allocation bitmap across the disk.  This would involv a ¨new
FREE, FORMAT, DCHECK, etc.  I didn't think of this myself, but had a ¨friend
describe it to me when setting up my Unix system.
 
 The idea is that you split the allocation bitmap up across the disk, and ¨try
to put all of one file in the region handled by a sub-component of ¨the
allocation bitmap.
 
 In the extreme, you could have the bitmap spread across the disk in
1-¨cluster sections.  So each 512K section of the disk would start off with ¨1
sector of it's own allocation bitmap, DRASTICALLY reducing seek times ¨for
file create and delete.
 
 In fact... if I fixed RBF to re-map sectors 1-256 automatically, FREE ¨and
DCHECK, etc. wouldn't even know that the bitmap was spread across the ¨disk. 
The only problem here is re-formatting your disk to the new method,¨and
re-writing RBF to handle this form of the allocation bitmap.  I'll ¨have to
study it more to see if it's workable (and simple to do)
 
 Alan DeKok.

[37m--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)

[36m
Public Message 
[36mMessage # 138 *OS9 ECHO*[32m
To      : All
[33mFrom    : David Hazelton
[35mSubject : Rick Uland
[37mDate    : 96/05/21  22:52:00[33m

Can someone tell me how I can get a hold of Rick.  I don't have a delphi
account or internet access.  I sent him mail and it was returned with a
change of address so I resent it and that was returned also.  I called
information for his phone # and he is not listed in milwaukee under his
name or CoNect.

Any help would be appreciated.  My Fast232 blew again.  probably the
16550 again, but not sure.  It doesn't insert in my multipak well and I
guess it wasn't sitting quite right when I turned on the machine.  I
can't get it to iniz or supercomm to bring it up.  I'm almost ready to
give up communicating with the CoCo III,  I can't get any thing reliable
past 2400 baud under OS-9 no matter what I do.


If anybody has a list of all the patches for 19200 under OS-9 both
hardware and software. I can check out what I'am missing.

Tia
~David Hazelton

[37m--- WILDMAIL!/WC v4.12 
 * Origin: CAMELOT (603) 485-8703 Has Anybody Seen My CELLO?  (1:132/215.0)

[36m
Public Message 
[36mMessage # 139 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Rick Truell
[35mSubject : New RiBBS Programs!
[37mDate    : 96/05/24  00:28:00[33m

*** Answering a msg posted in area RIBBS (RiBBS SysOp support).

Greetings and salutations, Christian!!

 CM> That dang dog!  Bad Fido!  Bad!  :)

No kidding. It's also hungrily munching on my netmail...that's being sent
from a place that's a whole 18 miles away from me!!

 CM> Gee, every one I know doesn't read the docs, they look for the
 CM> pictures. <VBG>

What?? You mean you put *pictures* in your docs?? Boy, you *do* go all out,
don't you <grin>!!

 CM> I got the SRC if you want it.

Thanks, but I've already got it.

 CM> I believe the reason RiBBS (as well as FixName) doesn't do this, is
 CM> because of other names the start with "Mac".  If one's name came
 CM> accross as "MACEDONIA", their name would be converted to "MacEdonia".
 CM> Still a thought for v1.1 though... <G>  (I _do_ appreciate the input.)

I suppose...hadn't thought of possibilities like that <grin>!! Actually, it
seems to me that it would be a pretty daunting task to try to account for
all the possibilities of capitalization in names...the code for the checks
would be longer than the rest of the program <grin>!!

Plus, how do you code for names like "Bob van der Poel", where capitalizing
the "v" and "d" is incorrect, and "Dick Van Boven", where capitalizing the
"v" *is* correct <grin>!!

Rick                         Cruising the Universe at Warp 14.4!!
Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca

... I MADE it foolproof...they're making better fools!
[37m--- GoldED/386 2.50 UNREG
 * Origin: Rick's Point Of Procrastination (1:342/42.8)


[36m
Public Message 
[36mMessage # 140 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Rick Truell
[35mSubject : Error 237?!?!?!
[37mDate    : 96/05/24  00:32:00[33m

Greetings and salutations, Christian!!

 CM> I'd have to do is unAR it.

Oh, come *on*!! I've installed and uninstalled Windows 3.1 on my IBM
compatible computer a half dozen times now! Be a man...reinstall Multi-Vue
the *hard* way <big grin>!!!

Rick                         Cruising the Universe at Warp 14.4!!
Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca

... Programmers get overlaid!
[37m--- GoldED/386 2.50 UNREG
 * Origin: Rick's Point Of Procrastination (1:342/42.8)


[36m
Public Message 
[36mMessage # 141 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Rick Truell
[35mSubject : RiBBS add-on programs
[37mDate    : 96/05/24  00:37:00[33m

Greetings and salutations, Christian!!

 CM> <grinning widely at my programming accomplishments>

You should...they sound pretty good. Just don't try patting yourself on the
back...you'll hurt your arm trying to bend it around like that <grin>!!

It sounds like you should consider seeing if you can find a C compiler
somewhere. Programming sounds like something you like to do, and learning C
will bring you in line with the rest of the world. There's nothing *wrong*
with Basic09, it's just that C was *designed* to be easily portable between
platforms, so utilities you write in C for yourself on the CoCo can be
taken to other computers should you change or "add on". As well, if you
convert your RiBBS utilities to C, they'll be more compatible with Eric's
"latest, greatest" version of RiBBS <grin>!! The only problem is that the
CoCo C compiler is hard to find...and may be costly if you *do* manage to
find a copy :-(

Rick                         Cruising the Universe at Warp 14.4!!
Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca

... while (!cat) play(mouse);
[37m--- GoldED/386 2.50 UNREG
 * Origin: Rick's Point Of Procrastination (1:342/42.8)


[36m
Public Message 
[36mMessage # 142 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Rick Truell
[35mSubject : More size, less barfing!!
[37mDate    : 96/05/24  00:57:00[33m

Greetings and salutations, Christian!!

 CM> Basic09 barfs at something like 32767 bytes.  So, FixName can only
 CM> "fix" upto the first 32,767 bytes of data per ".pkt" file.  (I'm
 CM> mentioning this to see if I can get help on it. <hint hint>)

That's the problem with using 2 byte integers...so limiting <grin>!! Try
using a real instead...somehow I suspect your data file will be smaller
than the number represented by 1 by 10 to the 38th power <grin>!!

Rick                         Cruising the Universe at Warp 14.4!!
Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca

... We all live in a yellow subroutine!!
[37m--- GoldED/386 2.50 UNREG
 * Origin: Rick's Point Of Procrastination (1:342/42.8)


[36m
Public Message 
[36mMessage # 148 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : Dave Kelly
[35mSubject : Scribe source
[37mDate    : 96/05/24  21:12:00[33m

If you have scribe y you will rememberr the configuration file that set all
the pallettes. The config file will let you set all kinds of colors. Also some
of the functions calls are from the 'grfx.l'.
 
A '306' is the OSK box with a Motorola 68306 CPU that Kreider Electronic is
making and sold by Backhawk and Wittman.
 
I am running OS9 version 3 with 8 megs of memory. The windowing system is
still in developement. Besides I find that text based applications are much
faster.

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 149 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : Dave Kelly
[35mSubject : program distribution
[37mDate    : 96/05/24  21:18:00[33m

the net access you describe sounds terriffic. WISH I could get something that
good here in HOUSTON.

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 150 *OS9 ECHO*[32m
To      : All
[33mFrom    : Erik Jan Tromp
[35mSubject : Recursion & Basic09
[37mDate    : 96/05/24  14:40:00[33m

Here's a snippet of test code that I've been playing with.  Does anyone
have a good explanation as to why it will recurse only 124 times before
erroring out?  The error, BTW, is #57 - System Stack Overflow.
The curious thing about this routine is that no extra memory appears to
be allocated from the system or global map, regardless of the data &/or
module size of Recurs1 (I 'padded' it with several hundred lines of
dummy code at one point).  This, to me, is a good thing.  As well,
giving a memory specifier (aka: "recurse #32k") has no effect on the
maximum number of levels of recursion.  This, to me, is _not_ a good
thing. :-)

procedure Recurse
dim number:integer
dim updn:boolean
number:=0
updn:=true \(* up
run Recurs1(number,updn)
end

procedure Recurs1
param number:integer
param updn:boolean
print "pre  ";number
number:=number+1
if number>123 then \(* set limit (stack max=124 levels)
 updn:=false \(* down
 print
endif
if updn then
 run Recurs1(number,updn)
endif
number:=number-1
print "post ";number
end

The whole reason for this exercise is that I'm attempting _yet another_
approach at writing a duplicate message / reply linkage scanner for
RiBBS.
Due to the fact that up to 32767 records have to be addressed, my only
real options are routines that work on secondary storage (disk) - unless
_every_ RiBBS sysop can guarantee a maximum of 512k free ram to pull the
data into memory. 8-)  I've tried variations on the explicit sorting
theme & the results were pitiful.  I've tried insertion sorts,
shellsorts, & non-recursive/recursive quicksorts.  Of these, the
recursive quicksort gives the best time of ~25 minutes on pre-ordered
data & 90+ minutes on semi-random data - both on ~4700 records.  (Keep
in mind I'm running a Nitro'd system with a bloody _fast_ hd.)
Because of this, I've changed tracks & started experimenting with
b-trees & so far things look promising.  Unbalanced b-trees are
horrendous, giving times of 95+ minutes & max branch length of 169
records (building the tree from scratch & working on my current message
base).  Balanced b-trees (AVL-trees, actually), OTOH, give better branch
lengths (~13 to 20), but the non-recursive algorithm I came up with is
bog slow because of all the internal housekeeping it has to perform.

Any ideas? (to my question at the top of this message, that is <g>)

--> Erik <--
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 151 *OS9 ECHO*[32m
To      : All
[33mFrom    : Dave Kelly
[35mSubject : new address
[37mDate    : 96/05/24  22:54:00[33m

New address:
 
Dave Kelly
310 Renfair Dr.
Plantersville, Texas
409-894-2884

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 155 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : David Graham
[35mSubject : Scribe
[37mDate    : 96/05/25  00:00:00[33m

CM>              On Thursday, May 9th, 1996 - William Barnes wrote:
CM>  
CM> WB>      Shall I presume you have not the right to distribute
CM> source code
CM> WB> for Scribe, and have it by special arrangement with Blair??? 
CM> Perhaps 
CM> WB> if this is so, you can negotiate a deal in which you can
CM> release a
CM> WB> "modified" version, approved by him, that fixes the quirks you
CM> have
CM> WB> noticed??? and then again...
CM>  
CM> No, Blair has released the SRC to the public since he no longer
CM> uses a
CM> CoCo.
CM>  
CM> Christian
CM>  
Also, I have an agreement with Blair to update the OSK version on 
a GNU-like distribution arrangement.  I have yet to find a programmer
to maintain this code, and am still looking.


___
 * Scribe/OSK * Anything with a Motolora Processsor is better than a IBM
clone!

[37m--- Maximus 2.01wb
 * Origin: The Significant Other - New Orleans LA - 504-246-5273 -
(1:396/1020)

[36m
Public Message 
[36mMessage # 156 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : David Graham
[35mSubject : Scribe/CoCo
[37mDate    : 96/05/25  00:00:00[33m

RT> it
RT> shouldn't be much of a problem creating a new one...I have enough
RT> multi-file programs of Bob's that should give me clues on creating
RT> a
RT> makefile for Scribe <grin>! The only *real* problem is that, at the
RT> moment,
RT> I have no way of getting a modified version of Scribe onto the
RT> Internet for
RT> others to get at. If someone else has that ability and is willing
RT> to do so,
RT> I can always uuencode a new archive and e-mail it to that person
RT> who can
RT> then decode it and put it on the FTP site. If someone *is* willing
RT> to help
RT> out with this, please let me know and then I'll get to work on
RT> creating a
RT> makefile and seeing if I can get Scribe to compile on my system.
RT> 
RT> Rick                         Cruising the Universe at Warp 14.4!!
RT> Fidonet - 1:342/42.8    Internet - rtruell@freenet.edmonton.ab.ca
RT> 
RT> ... XORing with 0xff is NOT, XORing with 0x00 is not.

Rick, I'd be happy to upload that upgrade for you.



___
 * Scribe/OSK * Anything with a Motolora Processsor is better than a IBM
clone!

[37m--- Maximus 2.01wb
 * Origin: The Significant Other - New Orleans LA - 504-246-5273 -
(1:396/1020)

[36m
Public Message 
[36mMessage # 162 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Christian Miller
[35mSubject : Re: Recursion & Basic09
[37mDate    : 96/05/26  01:18:00[33m

             On Friday, May 24th, 1996 - Erik Jan Tromp wrote:
 
EJ> procedure Recurse
EJ> dim number:integer
EJ> dim updn:boolean
EJ> number:=0
EJ> updn:=true \(* up
EJ> run Recurs1(number,updn)
EJ> end
 
EJ> procedure Recurs1
EJ> param number:integer
EJ> param updn:boolean
EJ> print "pre  ";number
EJ> number:=number+1
EJ> if number>123 then \(* set limit (stack max=124 levels)
EJ>  updn:=false \(* down
EJ>  print
EJ> endif
EJ> if updn then
EJ>  run Recurs1(number,updn)
EJ> endif
EJ> number:=number-1
EJ> print "post ";number
EJ> end
 
Erik, your error (which I figured) was because of your RUN statement in
"Recus1".  Remember, Basic09 remembers the 'parent procedure'.  You're
simply filling up Basic09's buffer.  I made the following changes to
"Recurs1", and ending w/o error "post 123"...
 
I changed PRINT "pre "; number to:
1 PRINT "pre ";number
 
and RUN Recurs1(number,updn) to:
GOTO 1
 
I hope this helps.  I'll save the code incase you need me to do anything 
else.  ;)
 
Christian
 
... Onward & Upward - All or nuthin'
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 164 *OS9 ECHO*[32m
To      : Brent McLaren
[33mFrom    : Tim Jones
[35mSubject : New RiBBS Programs!
[37mDate    : 96/05/25  09:19:00[33m

Hello Brent!

Replying to a message of Brent McLaren to All:

 CM>> I few weeks ago, I released VikingTag v2.0 to the pubic.  No one has
 CM>> responded even though I added things that I heard from feedback
 CM>> about

 CM>> I've also recently written AreaSort v1.0.  By simply typing "areasort
 CM>> [ENTER]", your areas.ctl file will be read, sorted by length
 CM>> (longest names 1st), and rewritten.  RiBBS *NEEDS* your areas.ctl
 CM>> file set up

 RT>> Excellent idea. I discovered a similar problem with Scribe and
 RT>> wrote a program to sort the echos listed in "control.dat" into
 RT>> numerical order to save myself some grief. Guess I should make it
 RT>> available to others...or else fix Scribe <grin>!!!

 BM> Question!  With all of these new little toys being released, why has
 BM> nothing been coming down the OCN network.  When anyone releases a new
 BM> program, I would sugest that you pass a copy to Tim Jones, and he can
 BM> hatch it onto the OCN file distribution network. 

Good idea Brent! If they got it to the nearest OCN BBS it should get hatched
out to the rest of the world from there. It doen't necessarily have to get
sent straight to me first.

Later, Tim!

[37m--- FleetStreet 1.12 NR
 * Origin: Trial Run - Austin, Tx - [512-280-6578] (1:382/107)

[36m
Public Message 
[36mMessage # 165 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Erik Jan Tromp
[35mSubject : FixName ideas...
[37mDate    : 96/05/25  19:10:00[33m

           On Thursday, May 23rd, 1996 - Christian Miller wrote:
 
CM> Basic09 barfs at something like 32767 bytes.  So, FixName can only 
CM> "fix"  upto the first 32,767 bytes of data per ".pkt" file.  (I'm 
CM> mentioning this to see if I can get help on it. <hint hint>)
 
Sounds like you're using an integer for keeping track of your seek
pointer.  Use a real instead & you'll never have to worry about maximum
seek lengths (unless you get a multi-gigabyte drive <snicker>).
 
CM> The other prob. with FixName is that is takes so long to do a
CM> byte-by-byte search.  I've been thinking about getting the next 
CM> version (if needed) to do a 255 byte-by-255 byte search, and then use 
CM> SUBSTR to find the proper info.
 
How's this for a few ideas?
 
procedure ScanPkt
 
dim junk$:string[1024]
dim msb$:string[72] \(* subject
dim mat$:string[51] \(* areatag
dim mto$,mfm$:string[36] \(* to & from
dim mdt$:string[20] \(* date posted
dim offset:real
dim count1,shift:integer
dim path1:byte
dim op1:boolean
 
offset:=58 \(* skip 58 bytes of FTS-0001.016 message header data
count1:=0 \(* init message counter
op1:=false \(* default = file is closed
 
on error goto 999
 
open #path1,"/r0/f80a2120.pkt":read \(* change as needed <g>
op1:=true
 
repeat
 seek #path1,offset
 get #path1,junk$
 shift:=substr(chr$(2)+chr$(0),junk$) \(* $0200 = packed message prefix
 if shift>0 then
  count1:=count1+1
  offset:=offset+shift+13 \(* skip 14 bytes of FTS-0001.016 message data
  seek #path1,offset
  read #path1,mdt$,mto$,mfm$,msb$,mat$
  print " posted: "+mdt$
  print "     to: "+mto$
  print "   from: "+mfm$
  print "subject: "+msb$
  if left$(mat$,5)="AREA:" then \(* no areatag if netmail
   print "areatag: "+mat$
  endif
  print "    msg #";count1
  print
 else
  offset:=offset+size(junk$)-1 \(* allow for 1 char overlap in GET
 endif
until eof(#path1)
 
close #path1
op1:=false
 
999 if op1 then
 close #path1
endif
print err
end
 
The above procedure will scan a raw mail packet 1024 bytes at a time,
grab date/to/from/subject/areatag when found & print them.  Compared to a 
byte by byte routine it flies.
OH! One thing to watch for... the line "offset:=offset+size(junk$)-1" has 
the "-1" for a good reason.  Since the search string is two characters
($02 & $00), a message won't be recognized if the $02 happens to be the
last char of junk$ & the $00 is the first char of the next 'get' of
junk$.  The slight overlap removes the possibility of a message being
skipped accidently.
 
If you have any questions, let me know.  I just slapped ScanPkt together
a few minutes ago, so I probably missed stating some of its more subtle
characteristics.
 
--> Erik <--
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 166 *OS9 ECHO*[32m
To      : Alan Dekok
[33mFrom    : Erik Jan Tromp
[35mSubject : Re: More potential RBF fixes
[37mDate    : 96/05/25  19:34:00[33m

              On Thursday, May 23rd, 1996 - Alan Dekok wrote:
 
AD> What's it worth to speed up RBF substantially?  Adding a R+W cache 
AD> makes  a HUGE difference, which Chris Dekker has already done.  Now 
AD> all I've got  to do is add that code to the main-stream Nitro RBF.
 
Can't wait to test it...  I'm curious how RBF & SCSISYS will behave with
each-other's caching schemes <g>.
 
AD> One: Keeping a cache in-memory of free sectors in the allocation 
AD> bitmap.  This would take 2 pages out of system memory for each hard 
AD> drive (not  floppy), but would make RBF do a 'best-fit' instead of 
AD> 'first-fit'  algorithm.  This could also be coupled with additional 
AD> code to allow  segments to contain more than 1 allocation bitmap 
AD> sectors worth of  sectors... but I don't know how feasible that is.
 
Caching free sectors from the bitmap is _definitely_ something I'd like
to see (as you well know <snicker>).  OTOH, altering the current scheme
of segment sizing could be, well, "iffy".  As an example, I installed a
730 meg drive on my system & due to an idiosyncracy in CBM I had to set
my cluster size to 16.  This, in turn, means that I get a max of 32768
sectors per cluster.  I've not tried to set my cluster size any higher
because 65536 sectors per cluster is the next highest step & that doesn't 
seem to be 'clean' when you consider that a segment's sector count is an
unsigned 16-bit value.  Essentially, I fear the possibility of making a
_big_ mess <g>.
Back to bitmap caching for a moment.  When we were originally talking
about the whole idea a while back, the idea of keeping track of 'largest
contiguous block of clusters per bitmap sector' appeared to only take 256 
bytes per device (255 actually, since LSN0 isn't part of the bitmap). 
Where does the extra page per device come in?  If it's for keeping track
of the 'start' of said block in the bitmap sector, why bother?  I would
think it to be more economical memory-wise to just physically seek to it
& find out manually.  After all, if you're going to use a block of
sectors & you know which block they're in, you can find out exactly where 
the block starts when you go to allocate it.  (If the extra page isn't to 
be used for this, just ignore my tirade...)
 
AD> Two: Spread the allocation bitmap across the disk.  This would involv 
AD> a  new FREE, FORMAT, DCHECK, etc.  I didn't think of this myself, but 
AD> had a  friend describe it to me when setting up my Unix system.
 
Hmmm...  Personally, I'm not ecstatic about this idea.  In the extreme,
trying to salvage a logically damage HD would be damn-near impossible. 
Can you imagine trying to figure out where file fragments are if you
don't even have a relatively undamaged bitmap to work from? <ouch!> 
Another thought comes to mind.  What happens if sector n of the spread
out bitmap happens to fall on a physically flawed sector?  Will you allow 
for a 'fudge-factor' of offsets to re-located bitmap sectors?
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 167 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Erik Jan Tromp
[35mSubject : Re: Quantum hard drive
[37mDate    : 96/05/26  02:36:00[33m

            On Monday, May 20th, 1996 - Christian Miller wrote:
 
CM> Well, my FixName v1.0 seems to be doing an OK job of it for now.  I
CM> wrote it after I posted you that message.  While I have your 
CM> attention, would you like to use any of my other RiBBS programs for 
CM> distribution with v2.11?  (LastCallers & Co., FixName, AreaSort, 
CM> RiBBSWall, VikingTag, & Risker)  I believe thats all of 'em. :)
 
They all sound good.  One thing I'd like to know, though... Are any of
the above-named programs 'hard-coded' for _any_ pathlist (aside from
/dd/ribbs.cfg)?  I remember the first time I installed WhoLister & found
that it was hard-coded to look for its data file in some pathlist on /dd
that didn't exist on my system.  I ended up taking dEd to it in order to
make it work.
 
--> Erik <--
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 168 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : Erik Jan Tromp
[35mSubject : Re: A BUNCH OF STUFF
[37mDate    : 96/05/26  03:34:00[33m

             On Wednesday, May 22nd, 1996 - Rick Truell wrote:
 
RT> I can't remember everything I was mentioning that I was going to do 
RT> to Arc and whether I got it done or not. Could you post the relevant 
RT> parts of those messages to refresh my memory? Thanks.
 
Even though this is the first I've seen of this thread, I have a few
_major_ items on my personal ARC wishlist:
 
1> Support of the newer (later than v5.12) compression algorithms.  The
ARC utilities we have now (dearc/os9arc) will only handle 'stored' (type
2), 'packed' (type 3), 'squeezed' (type 4), & 'crunched' (type 8).  The
newer ARC archivers are now capable of creating a 'type 9' (title
unknown) format that we can't touch.
 
2> Pass error status back to the shell for better control via shell
scripts & calling programs.  The current versions of dearc/os9arc
'swallow' the error code which makes life difficult when attempting to
add appropriate error responses in mail bundlers/unbundlers.
 
3> Better user interface.  Refer to _any_ good OS9 archiver for an
example.  My personal favourite is LHA v2.11's ability to direct 'burst'
files to directory other than the pwd.  As an absolute minimum, add the
abilities of testing member file integrity, extract to stdout, & store
directory structure of member files.  (Storing directory structure _is_
valid for ARC, isn't it?)
 
4> Built in wildcarding for extract & compress.
 
5> When extracting files, set the file's last modified date according to
the data stored in the archive header.  It's there, why not use it?
 
How's that for the beginnings of a wishlist?  I can probably come up with 
a few more points given time... <g>
 
RT> ... Basic programmers never die. They just GOSUB without RETURN!
 
Hey!  I resemble that remark! <laughing>
 
--> Erik <--
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 169 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : Erik Jan Tromp
[35mSubject : Re: RiBBS add-on programs
[37mDate    : 96/05/26  04:17:00[33m

               On Friday, May 24th, 1996 - Rick Truell wrote:
 
RT> change or "add on". As well, if you convert your RiBBS utilities to 
RT> C, they'll be more compatible with Eric's "latest, greatest" version 
RT> of RiBBS <grin>!! The only problem is that the CoCo C compiler is 
RT> hard to find...and may be costly if you *do* manage to find a copy :-(
 
To paraphrase... "Huh?"  RiBBS v2.11 is being written exclusively in Asm
& Basic09.  The only things left in C at the moment are the kermit
transfer engine(s), file request processing, & the mail
bundler/unbundler.  Of the aforementioned 3 things, the last two already
have Basic09 replacements on the way.
The main reason for this is... <you're gonna laugh> ...I never bothered
to sit down & learn C.  I tried, I really did.  But the whole nonsense of 
having to write source, pass it through god only knows how many levels of 
pre-processors & such only to have a compile bomb after 10 to 20 minutes. 
Bah-humbug! <g>  With Basic09 & Ved, I'm all set.  Edit in one window,
pull the source into Basic09 in another & let'r rip.  (I admit to having
a phobia of Basic09's lovely line editor <puh-lease!>)
As well, I'm of the opinion (right or wrong) that Basic09 is more suited
to OS9/6x09 - from the standpoint of efficiency of memory usage, right
down to the ease of coding.
One of my favourite episodes with the C compiler was a couple of years
ago when I was all hot & bothered about learning C.  Imagine my surprise
when the same piece of source would work perfectly when compiled with one 
set of libraries & trash my system when working with another set.
I still fiddle with the C compiler every once in a while (probably an
hour or so a month), but I'm at the point where productivity counts more. 
At my current state of knowledge, what would take me several days or more 
to write in C & could probably do in less than an hour in Basic09 (or
several hours in Asm).  Umm.. we're talking writing time, not processing
time, eh? 8-)
Nevertheless, I _have_ to learn C at some point.  At the very least, we
_desperately_ need ZModem for RiBBS (primary importance: mail runs,
secondary importance: user file transfers).
 
--> Erik <--
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: TimeShare Data Systems (aka: RiBBS H.Q.) -Unpublished- (1:2401/403)

[36m
Public Message 
[36mMessage # 177 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Dave Kelly
[35mSubject : Recursion & Basic09
[37mDate    : 96/05/25  21:29:00[33m

Have you looked at the assembly language? Is it pulling the pushes back off
the stack?
 
Must it be written in BasicO9?

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 179 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Dennis Mott
[35mSubject : Re: Recursion & Basic09
[37mDate    : 96/05/25  15:45:00[33m

             On Friday, May 24th, 1996 - Erik Jan Tromp wrote:
 
EJ> Any ideas? (to my question at the top of this message, that is <g>)
 --> Erik <--
EJ> --- RiBBS v2.11 (Beta)
 
 Not for the above, but another idea for your job jar would be to allow
cross posting to other echos in the new improved RiBBS. 
 
 Can't help you much on programming BASIC09 or C .... sorry
 
[37m--- RiBBS v2.10
 * Origin: OS9CN RC17 Data Warehouse, Spokane, 509-325-6787 (1:346/9 (1:346/9)

[36m
Public Message 
[36mMessage # 180 *OS9 ECHO*[32m
To      : David Hazelton
[33mFrom    : Alan Dages
[35mSubject : Rick Uland
[37mDate    : 96/05/26  09:12:00[33m

> Can someone tell me how I can get a hold of Rick.  I don't have a delphi
> account or internet access.  I sent him mail and it was returned with a
> change of address so I resent it and that was returned also.  I called
> information for his phone # and he is not listed in milwaukee under his
> name or CoNect.
> 
> Any help would be appreciated.  My Fast232 blew again.  probably the
> 16550 again, but not sure.  It doesn't insert in my multipak well and I
> guess it wasn't sitting quite right when I turned on the machine.  I
> can't get it to iniz or supercomm to bring it up.  I'm almost ready to
> give up communicating with the CoCo III,  I can't get any thing reliable
> past 2400 baud under OS-9 no matter what I do.
> 
> 
> If anybody has a list of all the patches for 19200 under OS-9 both
> hardware and software. I can check out what I'am missing.

 You really ought to try to get on internet, at least E-MAIL. I have a FREE 
E-MAIL account at SID here in Atlanta (770)612-1500. I don't have internet
access, that costs, but E-MAIL is free (30 minutes/day).
Once you get on E-MAIL contact Brother Jeremy at revwcp@delphi.com.
Brother Jeremy works closely with Rick and can contact him for you.
 
... I am not young enough to know everything.
___ ADQwk/OS-9 32a
[37m--- GrayQwkMail 2.1
 * Origin: ACS Inc. BBS 404-636-2991 (1:133/510)

[36m
Public Message 
[36mMessage # 183 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : William Barnes
[35mSubject : RE: CAN'T GET 19.2K
[37mDate    : 96/05/26  13:11:00[33m

MC>     I wonder what Terminal program you are using.  I am a SuperComm

  SuperComm 2.2 ...unmodified of course. Wouldn't mind trying the newest
OSTerm... Don't use RZ & SZ very often. (usually only sz for my mail
packets)

MC> newest SComm what buffer size there?  What are the number of pages
MC> that
MC> /T2 is set for?  If I had done this off line, I could have included
MC> my
MC> /T2, but alas...
MC>     Glad to see that you are using Sacia, I assume that it is
MC> unmodified 

   Unmodified SACIA, although I do have the source floating around. No
buffers within SuperComm that I'm aware of...

This is my XMode of /t2 below...
 
 nam=T2 mgr=SCF ddr=SACIA hpn=07 hpa=FF68 upc=00 bso=01
 dlo=00 eko=01 alf=01 nul=00 pau=00 pag=18 bsp=08 del=18
 eor=0D eof=1B rpr=09 dup=19 psc=17 int=03 qut=05 bse=08
 ovf=07 par=0C bau=04 xon=11 xof=13 col=50 row=18 xtp=45
 wnd=45 val= sty= cpx= cpy= fgc= bgc= bdc=

    Using the Tandy RS-232 pack; a FD-502 (or 501,can't tell unless I
disassemble my system at the moment; a MPI, with all the ints tied
together; a SSC, unmodified (rarely used), and an interrupt modified
512K CoCo III, 68B09E cpu. one of these days I'll see about a 16550afn
and see about modifying SACIA to use it. (Got permission to distribute a
16550 version a while back when I was tossing around the idea of
creating my own version of the "fast232" (before it made it to market).
Then again I've also thought of a CPU / 16550 combo that would look like
a 6551a to the CoCo.

-Later!
 -Dr. CoCo

---
 * Scribe 4.0 * He who laughs last doesn't get the joke.


[37m--- QScan/PCB v1.19b / 01-0162
 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)

[36m
Public Message 
[36mMessage # 184 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : William Barnes
[35mSubject : RIBBS ADD-ON PROGRAMS
[37mDate    : 96/05/26  13:11:00[33m

RT> "latest, greatest" version of RiBBS <grin>!! The only problem is
RT> that the
RT> CoCo C compiler is hard to find...and may be costly if you *do*
RT> manage to
RT> find a copy :-(

    I *THINK* I seen it in those Direct catalogues in Radio Shack... I
think for about $80.00, I'm not sure though. Worth it in a way though.
forgot how much I got mine for, but I got it as a closeout at store
level <FORGET IT, It's NOT for Sale...  ;) > The manual even talks about
setting up your C programs so that when accessed from B09 that it winds
up how B09 expects it (in B09 conventions) and not the way C does.


-Later!
 -Dr. CoCo

---
 * Scribe 4.0 * Press ENTER and be right justified.


[37m--- QScan/PCB v1.19b / 01-0162
 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)

[36m
Public Message 
[36mMessage # 185 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : William Barnes
[35mSubject : RECURSION & BASIC09
[37mDate    : 96/05/26  13:11:00[33m

EJT> erroring out?  The error, BTW, is #57 - System Stack Overflow.
EJT> The curious thing about this routine is that no extra memory
EJT> appears to
EJT> be allocated from the system or global map, regardless of the data
EJT> maximum number of levels of recursion.  This, to me, is _not_ a
EJT> good
EJT> thing. :-)

EJT> Any ideas? (to my question at the top of this message, that is <g>)

    Well, Lesseee,
    when one is unfortunate enough to see such an error in C ("****
STACK OVERFLOW ****") during run-time... it's usually because one is
surpassing the alotted amount of memory reserved for the stack, and
would overrun the data area. Very easily seen in recursive programming.
I don't think there is a way of fixing this with B09, but C does offer a
way around this (you change the size of all the areas).

-Later!
 -Dr. CoCo

---
 * Scribe 4.0 * I Either need MORE money or CHEAPER tastes



[37m--- QScan/PCB v1.19b / 01-0162
 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)

[36m
Public Message 
[36mMessage # 186 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : William Barnes
[35mSubject : Re: Recursion & Basic09
[37mDate    : 96/05/26  13:11:00[33m

CM> Erik, your error (which I figured) was because of your RUN
CM> statement in
CM> "Recus1".  Remember, Basic09 remembers the 'parent procedure'. 
CM> You're
CM> simply filling up Basic09's buffer.  I made the following changes
CM> to
CM> "Recurs1", and ending w/o error "post 123"...
CM>  
CM> I changed PRINT "pre "; number to:
CM> 1 PRINT "pre ";number
CM>  
CM> and RUN Recurs1(number,updn) to:
CM> GOTO 1
CM>  
CM> I hope this helps.  I'll save the code incase you need me to do
CM> anything 
CM> else.  ;)
CM>  
CM> Christian
CM>  

    In Essence you got rid of recursion for a loop version... Sometimes
slower, but at least you don't eat up your allocated stack space.

-Later!
 -Dr. CoCo

---
 * Scribe 4.0 * INSANITY is just a state of mind

[37m--- QScan/PCB v1.19b / 01-0162
 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)

[36m
Public Message 
[36mMessage # 187 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Alan Dekok
[35mSubject : Re: Fixname
[37mDate    : 96/05/26  09:22:00[33m

 CM> Basic09 barfs at something like 32767 bytes.  So, FixName can only 
 CM> "fix" 
 CM> upto the first 32,767 bytes of data per ".pkt" file.  (I'm mentioning
 CM> this to see if I can get help on it. <hint hint>)
 CM>  
 CM> The other prob. with FixName is that is takes so long to do a
 CM> byte-by-byte search.  I've been thinking about getting the next 
 CM> version
 
 Basic09 will handle numbers larger than 32767, but they end up coming ¨out
negative.  If you're aware of this, it's not a big deal to program ¨around.
 
 As for 'fixname' being slow, I've got some spare time.  Anyone willing ¨to
email me B09 programs, so I can re-write them in assembler?
 
 Alan DeKok.

[37m--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)

[36m
Public Message 
[36mMessage # 189 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Dave Kelly
[35mSubject : Re: Quantum hard drive
[37mDate    : 96/05/26  21:27:00[33m

Your point about hardcoding a directory location is a good point. Several
times have I had to use 'ded' to change that location. 
 
I would even go so far to suggest that '../dir' be use. That way I could have
my data files where ever I want. Or use a config file would be beter that way
I could have the data files buried several directories deep if I so desired.

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 199 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Mike Guzzi
[35mSubject : Re: Error 237?!?!?!
[37mDate    : 96/05/27  09:51:00[33m

-> MG> the SMAP utility. Use that to monitor your system RAM. Remember i
->
-> Got it, don't use it. <g>
->
-> MG> gets down to below 6K, you will be unable to format a floppy disk
->
-> I was having that problem too!  OOOOOOOOOOOOOOOOOOO!!!  I was
-> getting so
-> frustrated!
->

On my CoCo system, i used a program called optstart. it allows you to
hold down certain keys to alter your startup file. normally ribbs would
come up automatically, but with optstart i told it i can press the SHIFT
key while startup is running and it will not start ribbs.

I would boot up without running ribbs, run smap and note the system ram
thats left, then start ribbs and run smap again to see how much ribbs
wants for startup (remember during fidonet access such as unbundle and
such it will grab more) then try starting multivue and see how much it
takes up. You will get a better idea of how much each program wants for
itself.

Actually for a long time I have heard of the problem of not being able
to format a floppy with less then 6k of system ram. It never effected me
and I used to debate that with others.... until I realized I had a
Sardis controller and it doesn't need 6k of ram. If I switched back to
the Tandy mode volia, i used to hit the same problem. Sardis designed
the software so it would use the Internal RAM chip to format a floppy
disk and not the system ram.

Mike

[37m--- WILDMAIL!/WC v4.12 
 * Origin: Astral Plane BBS, 717-348-2197, NE PA's CoCo/OS9 BBS  (1:268/342.0)

[36m
Public Message 
[36mMessage # 201 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Christian Miller
[35mSubject : Re: Quantum hard drive
[37mDate    : 96/05/27  01:04:00[33m

             On Sunday, May 26th, 1996 - Erik Jan Tromp wrote:
 
EJ> They all sound good.  One thing I'd like to know, though... Are any of
EJ> the above-named programs 'hard-coded' for _any_ pathlist (aside from
EJ> /dd/ribbs.cfg)?  I remember the first time I installed WhoLister & 
EJ> found that it was hard-coded to look for its data file in some 
EJ> pathlist on /dd that didn't exist on my system.  I ended up taking 
EJ> dEd to it in order to make it work.
 
The only hard coding is /dd/ribbs.cfg.  All my programs look there to
find out the proper directories to use.  (I thought that was the whole
idea of having a configuration file...<VBG>)
 
Christian
 
... "I will bless those that bless you & curse those who curse you."
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 202 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Christian Miller
[35mSubject : Re: FixName ideas...
[37mDate    : 96/05/27  01:07:00[33m

            On Saturday, May 25th, 1996 - Erik Jan Tromp wrote:
 
EJ> Sounds like you're using an integer for keeping track of your seek
EJ> pointer.  Use a real instead & you'll never have to worry about 
EJ> maximum seek lengths (unless you get a multi-gigabyte drive 
EJ> <snicker>). 
 
No, I'm using a REAL number for the pointer.  Maybe I just thought it
was erroring out due to the number.  Maybe there's a EOF error I'm
missing.  Anyways, the error trap works, and nothing has barfed since
the first trail run.  I'll study your code and see how I can implement
it into FixName.  I'd love to speed it up!
 
EJ> The above procedure will scan a raw mail packet 1024 bytes at a time,
EJ> grab date/to/from/subject/areatag when found & print them.  Compared 
EJ> to a  byte by byte routine it flies.
 
I imagine it would.  Right now, FixName skips the first 54 bytes of
"junk" in the '.pkt'.  Then it starts searching for a CHR$(13) & three
CHR$(0)'s, which denotes a new message.  Then it jumps 5 bytes, and
finds the TO: person.  It fixes their name if needed, and writes it back 
out.  It does this for each message, until it reaches an EOF.  Then the
next .pkt is processed.
 
Christian
 
... For the man is not of the woman; but the woman of the man. I Cor
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 205 *OS9 ECHO*[32m
To      : Alan Dekok
[33mFrom    : Christian Miller
[35mSubject : Re: Fixname
[37mDate    : 96/05/27  14:42:00[33m

               On Sunday, May 26th, 1996 - Alan Dekok wrote:
 
AD> Basic09 will handle numbers larger than 32767, but they end up coming 
AD> out negative.  If you're aware of this, it's not a big deal to 
AD> program  around.
 
I've been getting quite a few helpful hints, thanks.
 
AD> As for 'fixname' being slow, I've got some spare time.  Anyone 
AD> willing  to email me B09 programs, so I can re-write them in 
AD> assembler? 
 
UG!  I just found another (minor) bug in FixName...  If there's a ' in
the persons name, it deletes it.  I'll have to take another look at the
code.
 
It sure would be nice to see some of my stuff running in ML code.  <G>
 
Christian
 
... Every tongue confess that Jesus Christ is Lord of all.
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 206 *OS9 ECHO*[32m
To      : Tim Jones
[33mFrom    : Christian Miller
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 96/05/28  01:16:00[33m

               On Saturday, May 25th, 1996 - Tim Jones wrote:
 
TJ> Good idea Brent! If they got it to the nearest OCN BBS it should get 
TJ> hatched out to the rest of the world from there. It doen't 
TJ> necessarily have to get sent straight to me first.
 
Can I FReq them to you?  Should I bundle them up as one file, or as each 
separate program package?
 
Christian
 
... The whole Earth is full of His glory.
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 207 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Christian Miller
[35mSubject : Re: RiBBS add-on programs
[37mDate    : 96/05/28  01:23:00[33m

             On Sunday, May 26th, 1996 - Erik Jan Tromp wrote:
 
EJ> To paraphrase... "Huh?"  RiBBS v2.11 is being written exclusively in 
EJ> Asm & Basic09.  The only things left in C at the moment are the kermit
 
Hey yeah!  <grinning widely>
 
EJ> Nevertheless, I _have_ to learn C at some point.  At the very least, 
 
I'll soon be taking one of those coarses in school.... Ug! <G>
 
EJ> we _desperately_ need ZModem for RiBBS (primary importance: mail runs,
EJ> secondary importance: user file transfers).
 
Here-here!  (That's right spelling, isn't it?)  If nothing else is done
to RiBBS, the above is it.
 
Christian
 
... I'm single, but never alone.  - Hebrews 13:5
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 208 *OS9 ECHO*[32m
To      : William Barnes
[33mFrom    : Christian Miller
[35mSubject : Re: Recursion & Basic09
[37mDate    : 96/05/28  01:30:00[33m

             On Sunday, May 26th, 1996 - William Barnes wrote:
 
 CM> I changed PRINT "pre "; number to:
 CM> 1 PRINT "pre ";number
 CM>  
 CM> and RUN Recurs1(number,updn) to:
 CM> GOTO 1
WB> In Essence you got rid of recursion for a loop version... Sometimes
WB> slower, but at least you don't eat up your allocated stack space.
 
How is using a GOTO slower than making Basic09 pull a "separate" program 
into memory?  Just looping the _same_ program seems faster to me.
 
Christian
 
... Pigs in Space - Matthew 8:32
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 213 *OS9 ECHO*[32m
To      : All
[33mFrom    : Ron Bull
[35mSubject : Stuff For Sale
[37mDate    : 96/05/27  10:57:00[33m

 I have some things I need to get rid of so if you are interested you can
reply
 here or call me at (717) 834-4314 in the evenings or weekends.

 1 - MiniScribe Model 3425 MFM 40 meg (?) hard drive
 3 - MiniScribe Model 6053 MFM 44 meg hard drive
 1 - Priam 62 meg (?) MFM hard drive
 4 - 5.25 floppy drives (not sure which are DD or HD)
 1 - SAKATA Color Monitor
 1 - CM-8 RGB Color Monitor
 1 - 286 XT
 1 - 386 Packard Bell
 2 - DMP 130 printers

 I don't know what they are worth to anyone, but come on give me an offer!

                          Ron Bull

[37m--- FLAME v1.1/b
 * Origin: Pennsylvania Online! 10+ gigs [717.657.8699] (1:270/101)

[36m
Public Message 
[36mMessage # 218 *OS9 ECHO*[32m
To      : William Barnes
[33mFrom    : David Hazelton
[35mSubject : Re: CAN'T GET 19.2K
[37mDate    : 96/05/27  22:41:00[33m

 I think I started this mess....anyways in the following you stated this is 
 what equipment that you have <edited>. 

-=> Quoting William Barnes to Merv Curley <=-

 WB> interrupt modified 512K CoCo III, 68B09E cpu. one of these days I'll see
a
out a 16550afn
 WB> and see about modifying SACIA to use it. (Got permission to distribute
 WB> a 16550 version a while back when I was tossing around the idea of
 WB> creating my own version of the "fast232" (before it made it to
 WB> market). Then again I've also thought of a CPU / 16550 combo that would
 WB> look like a 6551a to the CoCo.

 WB> -Later!
 WB> -Dr. CoCo

 #1) what is the "interrupt modification" on the CoCo III.   I have not 
 tried to modify the CoCo III itself,  That maybe why my internal 6551a 
 hangs under OS9 after a screen or two.

 #2)  what advantage would a CPU/16550 combo produce other than SACIA 
 wouldn't know the difference...would it allow better thruput than just a 
 16550 by having something like a 2k buffer onboard, sort of like the Disto 
 SCII does.

 ~David Hazelton


... Stupidity is using a PC emultor on a MAC to read CoCo/OS-9 messages.

___ Blue Wave/QWK v2.20 [NR]

[37m--- WILDMAIL!/WC v4.12 
 * Origin: CAMELOT (603) 485-8703 Has Anybody Seen My CELLO?  (1:132/215.0)

[36m
Public Message 
[36mMessage # 220 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Mike Guzzi
[35mSubject : recursion in basic09
[37mDate    : 96/05/28  09:56:00[33m

Erik,

Given the program you provided it wouldn't be needed to use recursion.
if you stopped the program while it ran (before the error) and used the
command "state" (i think) from debug in basic09 it will show the parent
program and all the called routines. Basic09 cannot handle more then 128
called routines and using a memory modifier (#32k) only increases user
data space. it would be similar to gosub's without returns

recursion is useful to save code in programs that need the same code
with different values. For example, a program im writing in basic09 is a
game of minesweeper (those with windoze will know what I mean) when the
player clicks on a blank spot on the map, not only willl that spot be
uncovered but all spots around it (since they cannot contain mines) but
if uncovering a nearby spot is also blank, the program will recursivly
call itself to clear around that blank spot. (the routine that clears
around a center point) The routine originally needs three parameters,
the map of the field, and the x,y coordinates or the spot that needs
clearing around. so minesweeper calls blankspot like this

(from minesweeper)

....

run blankspot(map,x,y)
...

now blankspot clears around the x,y coordinates, but lets say it finds
another blank spot, it merely calls itself again with the new coordinate
such as....

run blankspot(map,x1,y1)

therefore the original x,y are preserved. map is common to all called
procedures therefore there is only 1 copy of map's variables in
basic09's memory. new values are created for x1,y1 and its also possible
that blankspot will be called several more times until it no longer
finds blankspots outside its original coordinate. each called routine
just dies off after it clears around its spot.

Does that help?
Mike

[37m--- WILDMAIL!/WC v4.12 
 * Origin: Astral Plane BBS, 717-348-2197, NE PA's CoCo/OS9 BBS  (1:268/342.0)

[36m
Public Message 
[36mMessage # 221 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Mike Guzzi
[35mSubject : another idea?
[37mDate    : 96/05/28  10:15:00[33m

Erik,

Here is another idea that might help accomplish what you want. Have you
ever looked at my code for the basic09 program called "mbackup" ?

it shows how to use more then 64k for data storage. by swapping in and
out 8k or larger segments of memory. you might be able to use that for
storing data to be sorted and such.

It uses nothing but standard system calls (no nitros-9, no vrn, etc..)
and you can find out with one system call how much memory the user has
available. Plus it doesn't matter how fragmented it is.

I documented how its done in the doc file thats included with the
archive.

Mike

[37m--- WILDMAIL!/WC v4.12 
 * Origin: Astral Plane BBS, 717-348-2197, NE PA's CoCo/OS9 BBS  (1:268/342.0)

[36m
Public Message 
[36mMessage # 224 *OS9 ECHO*[32m
To      : Christian Miller
[33mFrom    : Tim Jones
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 96/05/28  20:39:00[33m

Hello Christian!

Replying to a message of Christian Miller to Tim Jones:

 CM>                On Saturday, May 25th, 1996 - Tim Jones wrote:

 TJ>> Good idea Brent! If they got it to the nearest OCN BBS it should get 
 TJ>> hatched out to the rest of the world from there. It doen't 
 TJ>> necessarily have to get sent straight to me first.

 CM> Can I FReq them to you?  Should I bundle them up as one file, or as
 CM> each  separate program package?

Yes you can freq them to me if you want. You can bundle them all up in one
file if you want but if possible use lha 2.11c . Thanks! I'll look for them in
the near future.

Later, Tim!

[37m--- FleetStreet 1.12 NR
 * Origin: Trial Run - Austin, Tx - [512-280-6578] (1:382/107)

[36m
Public Message 
[36mMessage # 225 *OS9 ECHO*[32m
To      : ALL
[33mFrom    : ARCH VILE
[35mSubject : Looking for stuff...
[37mDate    : 96/05/28  21:59:00
[32mNext Reply is Message [33m226[33m

Does a CoCo 3 work with a Tandy CM8 CGA monitor?

I am looking for the following items.  I would prefer mail-order houses or
stores in the Dallas/Fort Worth Texas area.  For the software, FTP or WWW site
would be great!

A CoCo 3
adapter to use MFM/RLL hd's ( I have a MiniScribe 10meg model 3212)
if not above, then where to buy a 10-40 meg one
Basic 09
OS9 Level 2
RiBBS (latest version)
Multi-Pack adapter

Let me know if you have any info. 
Thanks, 
Arch Vile


---
  SPEED 2.00 [NR]  Yes my son, long ago mail was read 1 packet at a time.

[37m--- GOMail v2.0 [DEMO] 04-30-37
 * Origin: * ShadowCat - Ft Worth, Tx - (817) 294-8347 * (1:130/407)

[36m
Public Message 
[36mMessage # 227 *OS9 ECHO*[32m
To      : Arch Vile
[33mFrom    : Dave Kelly
[35mSubject : Find someone
[37mDate    : 96/05/29  15:44:00[33m

I see by your tag line that you are in the Dallas/Ft Worth metroplex. I would
like to ask you to find someone for me.
 
There is/use to be a group called DALTRug (Dallas Tandy Radio Shack Users
Group) that met once a month at the InforMart on Stemmons Pkwy in Dallas. They
even had a BBS (now disconnected).
 
Some of their members were very active on these echos. Right after the Chicago
Coco Fest in April  of 95 everybody seems to have dropped out of sight.
 
Would you ask around or attend a Super Saturday meeting at the InforMart and
see if you can find someone from that group.
 
In the Ft Worth area, if you know a Richard Dean, he might know something and
also have things you want. Some of the DALTRug might have some of those items
also.
 
I would appreaciate some help finding this group. THANKS.
 
Dave Kelly

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)

[36m
Public Message 
[36mMessage # 228 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Alan Dekok
[35mSubject : Re: More potential RBF fixes
[37mDate    : 96/05/28  08:22:00[33m

 EJT> Back to bitmap caching for a moment.  When we were originally talking
 EJT> about the whole idea a while back, the idea of keeping track of 
 EJT> 'largest
 EJT> contiguous block of clusters per bitmap sector' appeared to only 
 EJT> take 256 
 EJT> bytes per device (255 actually, since LSN0 isn't part of the 
 EJT> bitmap). 
 EJT> Where does the extra page per device come in?  If it's for keeping 
 
 There CAN be 256 sectors in the allocation bitmap, and you need more ¨than
255 possible states for each sector.  Why?  Well, 0-256 for the ¨maximum
number of free sectors, plus (perhaps) a per-sector flag saying ¨'updated' or
'invalid'.  The flag may be able to go somewhere else, but I ¨doubt it.
 
 I have to agree, though, the ideas other than a R+W cache are pretty ¨iffy.
 
 Alan DeKok.

[37m--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)

[36m
Public Message 
[36mMessage # 229 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Alan Dekok
[35mSubject : Re: RiBBS add-on programs: Basic
[37mDate    : 96/05/28  08:27:00[33m

 EJT> As well, I'm of the opinion (right or wrong) that Basic09 is more 
 EJT> suited
 EJT> to OS9/6x09 - from the standpoint of efficiency of memory usage, 
 EJT> right
 EJT> down to the ease of coding.
 
 I'll agree whole-heartedly with that.  I tried using C on my Coco, and ¨it
was just too slow: both the compile AND the resulting programs.  The ¨Coco C
compiler is OLD, and generates TERRIBLE code.  I've now got 2 sun ¨3/60
systems up and running, and am running Gcc on them, 20MHz 68020's, ¨with 4Meg
of RAM.  GCC of a reasonable-sized program is about as fast as ¨Basic09
parsing a large file..
 
 On another note, I have been frustrated with some of what Basic09 does
¨lately.  Is there any point in writing a Basic09 -> ASM compiler? The
¨initial stages wouldn't be too hard, as it would only support the ¨simplest
command set.  More complicated things could be added later.
 
 Benefits?  I don't think that it would be terrible faster than Basic09, ¨but
the programs would be a LOT smaller.
 
 Alan DeKok.

[37m--- Maximus-CBCS v1.02
 * Origin: Micro80 Computer Club of Ottawa BBS (1:163/306)

[36m
Public Message 
[36mMessage # 231 *OS9 ECHO*[32m
To      : Rick Truell
[33mFrom    : Merv Curley
[35mSubject : Re: A BUNCH OF STUFF
[37mDate    : 95/05/27  21:37:00[33m

Hi Rick
  
             On Wednesday, May 22nd, 1996 - Rick Truell wrote:
 
RT> I can't remember everything I was mentioning that I was going to do 
RT> to Arc and whether I got it done or not. Could you post the relevant 
RT> parts of those messages to refresh my memory? Thanks.
   
     Well after I sent the message off, I deleted that days group of
messages.  I know that one thing you were going to fix was the dating of 
the directories that ARC made.  The other thing was something you saw in 
the Source code that was to be fixed, but you didn't elucidate to the
masses just what it was.  Sorry I can't send your prose back to you.
  
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 232 *OS9 ECHO*[32m
To      : Alan Dekok
[33mFrom    : Merv Curley
[35mSubject : Re: More potential RBF fixes
[37mDate    : 95/05/27  21:43:00[33m

Hi Alan
  
              On Thursday, May 23rd, 1996 - Alan Dekok wrote:
 
AD> What's it worth to speed up RBF substantially?  Adding a R+W cache 
AD> makes  a HUGE difference, which Chris Dekker has already done.  Now 
AD> all I've got  to do is add that code to the main-stream Nitro RBF.
AD> In addition, there are 2 other things I'd like to try, both involve 
AD> the  allocation bitmap.
  
    I would be happy to see you speed up RBF, anything to speed up the
BBS (RiBBS) is appreciated.  If the the cache works, that would be good. 
I tried the CC3Disk cache system years ago, didn't seem to do much as I
recall.
  
    The other changes sound pretty formidable and would keep you coding
for ages.  This FAT system is outdated now and the High Performance
systems showing up here and there work very well but at a cost of module 
size.  I don't mind backing up and reformatting my Hard drive to set up
a new system, but what about all those floppies that we all have.  Need
to be able to read them in the old format.  The OS/2 HPFS still uses
FAT for floppies.  But look at the memory cost of the OS/2 HPFS, about
300-400K.
    If you could help some of us out to get our RAM disks working under
Nitro 1.22, that would be a big help. I'm still stuck at 1.16 cuz of no
Ramdisk in 1.22
  
Regards
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 233 *OS9 ECHO*[32m
To      : David Hazelton
[33mFrom    : Merv Curley
[35mSubject : Re: Rick Uland
[37mDate    : 95/05/27  21:56:00[33m

Hi David
  
             On Tuesday, May 21st, 1996 - David Hazelton wrote:
 
DH> If anybody has a list of all the patches for 19200 under OS-9 both
DH> hardware and software. I can check out what I'am missing.
  
     Well the main patch is Hardware,  install a 6309  and then upgrade
to Nitro.  This  RiBBS BBS is working at 9600 flawlessly, and I used to
log onto Delphi and use SComm and Zmodem at 9600.
    Some Nitro'd  Coco's at ver 1.22 are working at 19600, I'm not up to 
1.22 yet.
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 234 *OS9 ECHO*[32m
To      : Erik Jan Tromp
[33mFrom    : Merv Curley
[35mSubject : Re: A BUNCH OF STUFF
[37mDate    : 95/05/28  01:00:00[33m

             On Sunday, May 26th, 1996 - Erik Jan Tromp wrote:
 
EJ> Even though this is the first I've seen of this thread, I have a few
EJ> _major_ items on my personal ARC wishlist:
Hi Erik
  
   Well we weren't talking about the Arc archiver. Its an old very
useful Level 1  file copy/backup utility by Carl K. as I recall.  But
maybe someone will take your wishlist and run with it.
   Pick it up here if you can afford the 50 cents next Sunday.  I use it 
to copy directorys and up to full disks.  Its best feature is backing up 
directories, it won't overwrite a file unless it has a newer date.  It's 
how I do my HDisk backups.  It zips through a directory until it finds
something new.  Makes new directories as required and other good stuff.
Ta Ta
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 235 *OS9 ECHO*[32m
To      : Brent McLaren
[33mFrom    : Merv Curley
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 95/05/28  01:09:00[33m

              On Monday, May 27th, 1996 - Brent McLaren wrote:
 
 TJ> Good idea Brent! If they got it to the nearest OCN BBS it
 TJ> should get hatched out to the rest of the world from there.
 TJ> It doen't necessarily have to get sent straight to me first.
BM> True, if anyone in this neck of the woods want's to send out 
BM> anything, send it here, and I'll hatch it out.
   
   Just so everyone out there knows, these volunteers spend their own $$ 
to move files all over the U.S. and Can.  A year ago there were new
files every week, now I don't think anything has been distributed for
several months.  New files are being put on  .rtsi.com  but our
distribution system has been ignored.
Merv
  
Afterthought,  howabout a monthly list of the active members of the File
distribution system?  Might remind people the best places to drop off
files.  Would have been nice to have Sockmasters new stuff get out to
the Coco BBS'S.
M.
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 236 *OS9 ECHO*[32m
To      : Tim Jones
[33mFrom    : Brent McLaren
[35mSubject : New RiBBS Programs!
[37mDate    : 96/05/27  21:34:00[33m

TJ> Good idea Brent! If they got it to the nearest OCN BBS it
TJ> should get hatched out to the rest of the world from there.
TJ> It doen't necessarily have to get sent straight to me first.

True, if anyone in this neck of the woods want's to send out anything, send it
here, and I'll hatch it out.

Brent

[37m--- GEcho 1.20/Pro
 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536)

[36m
Public Message 
[36mMessage # 237 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : Brent McLaren
[35mSubject : New RiBBS Programs!
[37mDate    : 96/05/28  18:43:00[33m

MC> Afterthought,  howabout a monthly list of the active members of the File
MC> distribution system?  Might remind people the best places to drop off
MC> files.  Would have been nice to have Sockmasters new stuff  get out to
MC> the Coco BBS'S.

Well Merv, if you have it, why not hatch it yourself.  You have hatch access
through my system.

Brent

[37m--- GEcho 1.20/Pro
 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536)

[36m
Public Message 
[36mMessage # 240 *OS9 ECHO*[32m
To      : William Barnes
[33mFrom    : Merv Curley
[35mSubject : Modem speed
[37mDate    : 95/05/29  16:14:00[33m

Hi William,
   
    I didn't quote your /t2, but I see two differences in mine,
   wnd=03   and   xtp=03
    I haven't gone back to find out why I set them to those values but
I believe it was advice from Erik Jan Tromp
    I don't remember modifying Sacia, my CRC is A4CFE0.  If it hasn't
been modified it must be the only thing in my Bootfile that that way.
  
 Quote: -
      Using the Tandy RS-232 pack; a FD-502 (or 501,can't tell unless I
disassemble my system at the moment; a MPI, with all the ints tied
together; a SSC, unmodified (rarely used), and an interrupt modified
512K CoCo III, 68B09E cpu. one of these days I'll see about a 16550afn
and see about modifying SACIA to use it. (Got permission to distribute a
16550 version a while back when I was tossing around the idea of
creating my own version of the "fast232" (before it made it to market).
Then again I've also thought of a CPU / 16550 combo that would look like
a 6551a to the CoCo.
 
 End Quote:-
  
   If you install one of the new Clock modules (Ed. 9), you can remove
the interrupt fix (Diode hack or line from the RS 232?). However that
won't fix your speed problem.  Your modem is set for Hardware handshaking
I hope, that is important at the higher speeds.  I may have commented on
that earlier tho.  I think I also commented that  you will need a 6309
and Nitro to really get reliable high speeds.  The other occasional
problem is a 6551 which isn't too good.  Installing a 65C51 has often
been recommended.
  
   Thats about the sum of my suggestions for now.
  
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 241 *OS9 ECHO*[32m
To      : Brent McLaren
[33mFrom    : Merv Curley
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 95/05/29  16:16:00[33m

             On Tuesday, May 28th, 1996 - Brent McLaren wrote:
 
 MC> Afterthought,  how about a monthly list of the active members of the 
 MC> File distribution system?  Might remind people the best places to 
 MC> drop off files.  Would have been nice to have Sockmasters new stuff  
 MC> get out to the Coco BBS'S.
BM> Well Merv, if you have it, why not hatch it yourself.  You have hatch 
BM> access through my system.
BM> Brent
   
   Well we don't need a file hatched out, just a message like the
Periodicals listing  or my list of Ribbs systems which is posted for
Ribbs sysops.
   I don't have any idea who all are distributing Files. Probably only
Tim knows that.
   Is it Tim, I'm not sure now, <G>.
Merv
 
[37m--- RiBBS v2.11 (Beta)
 * Origin: Toronto Color Computer Club BBS   (416) 757 4283 (1:250/404)

[36m
Public Message 
[36mMessage # 249 *OS9 ECHO*[32m
To      : Tim Jones
[33mFrom    : Christian Miller
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 96/05/30  09:44:00[33m

               On Tuesday, May 28th, 1996 - Tim Jones wrote:
 
TJ> Yes you can freq them to me if you want. You can bundle them all up 
TJ> in one file if you want but if possible use lha 2.11c . Thanks! I'll 
TJ> look for them in the near future.
 
Ug!  It may be a while...  My hard drive crashed the other day.  Once I
got it up and running, it would read but not write.  I had to reformat
it...  :(...  <G>  I believe I saved my process on floppy.  (Docs wise,
I know I backed up my SRC. <G>)
 
Christian
 
... The first will be last...the last will be first. - Mark 9:35
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 250 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : Christian Miller
[35mSubject : Re: Rick Uland
[37mDate    : 96/05/30  14:37:00[33m

              On Saturday, May 27th, 1995 - Merv Curley wrote:
 
MC> Well the main patch is Hardware,  install a 6309  and then upgrade
MC> to Nitro.  This  RiBBS BBS is working at 9600 flawlessly, and I used 
MC> to log onto Delphi and use SComm and Zmodem at 9600.
MC> Some Nitro'd  Coco's at ver 1.22 are working at 19600, I'm not up to 
MC> 1.22 yet.
 
Well, here's a good one:
 
My CoCo has a 6809 in it, upgraded MPI, and the 6551a chip in my RS-232
pak.  RiBBS runs flawlessly at 9600, yet when I use SuperComm, I get
missed characters.  Good one, huh?  ;)
 
Christian
 
... The Lord is my Shepherd - Psalms 23
___ * VikingTag v2.1 *
[37m--- RiBBS v2.10
 * Origin: The Oxygen Tank - St. Petersburg, FL  813/327-7145 (1:3603/800)

[36m
Public Message 
[36mMessage # 257 *OS9 ECHO*[32m
To      : Arch Vile
[33mFrom    : Carey Bloodworth
[35mSubject : Looking for stuff...
[37mDate    : 96/05/30  22:21:00[33m

AV>Basic 09

I've got the book for Level 1 Basic09.  The Official Basic09 Tour Guide.
I'd be willing to sell it for $10, including shipping.

AV>OS9 Level 2

I have a brand new, never opened (!) copy of OS9 L2.  I'll sell it for,
oh, how about $30, including shipping in the US.

$35 for both.

If that's okay,

Carey Bloodworth
1601 North Hills Blvd.
Van Buren, AR 72956-2152

[37m--- QScan/PCB v1.19b / 01-0162
 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)

[36m
Public Message 
[36mMessage # 259 *OS9 ECHO*[32m
To      : Arch Vile
[33mFrom    : Ron Bull
[35mSubject : LOOKING FOR STUFF...
[37mDate    : 96/05/30  05:50:00[33m

 I have some things I need to get rid of so if you are interested you can
reply
 here or call me at (717) 834-4314 in the evenings or weekends.

 1 - MiniScribe Model 3425 MFM 40 meg (?) hard drive
 3 - MiniScribe Model 6053 MFM 44 meg hard drive
 1 - Priam 62 meg (?) MFM hard drive
 4 - 5.25 floppy drives (not sure which are DD or HD)
 1 - SAKATA Color Monitor
 1 - CM-8 RGB Color Monitor
 1 - 286 XT
 1 - 386 Packard Bell
 2 - DMP 130 printers

 I don't know what they are worth to anyone, but come on give me an offer!

                          Ron Bull

[37m--- FLAME v1.1/b
 * Origin: Pennsylvania Online! 10+ gigs [717.657.8699] (1:270/101)

[36m
Public Message 
[36mMessage # 260 *OS9 ECHO*[32m
To      : Alan Dekok
[33mFrom    : Tim Jones
[35mSubject : Re: RiBBS add-on programs: Basic
[37mDate    : 96/05/31  06:34:00[33m

Hello Alan!

Replying to a message of Alan Dekok to Erik Jan Tromp:

 AD>  On another note, I have been frustrated with some of what Basic09
 AD> does  lately.  Is there any point in writing a Basic09 -> ASM
 AD> compiler? The  initial stages wouldn't be too hard, as it would only
 AD> support the  simplest command set.  More complicated things could be
 AD> added later.

 AD>  Benefits?  I don't think that it would be terrible faster than
 AD> Basic09,  but the programs would be a LOT smaller.

I think it would be great and I've often wondered why someone who could didn't
write one a long time ago! I would be great to not have runb loaded when you
run B09 stuff! If you do it can you do one for the MM/1 too <grin>?!

Later, Tim!

[37m--- FleetStreet 1.12 NR
 * Origin: Trial Run - Austin, Tx - [512-280-6578] (1:382/107)

[36m
Public Message 
[36mMessage # 261 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : Tim Jones
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 96/05/31  06:37:00
[32mNext Reply is Message [33m267[33m

Hello Merv!

Replying to a message of Merv Curley to Brent McLaren:

 MC>    Just so everyone out there knows, these volunteers spend their own
 MC> $$  to move files all over the U.S. and Can.  A year ago there were
 MC> new files every week, now I don't think anything has been distributed
 MC> for several months.  New files are being put on  .rtsi.com  but our
 MC> distribution system has been ignored. Merv

 MC> Afterthought,  howabout a monthly list of the active members of the
 MC> File distribution system?  Might remind people the best places to
 MC> drop off files.  Would have been nice to have Sockmasters new stuff
 MC> get out to the Coco BBS'S. M.

Here's who I have at the moment. If any see's an error please correct me.

        Files are available on these fine OS9-CN volunteer BBS':

Golden Coco       - TX - 713-941-1542 | The Data Warehouse - WA - 509-325-6787
Coco Plus         - AL - 334-341-1616 | House of Fire      - ON - 416-601-0085
ACS BBS Inc       - GA - 404-636-2991 | The Pink Rose      - CT - 203-429-6338
The Data Stash    - WI - 414-684-4115 | the Trial Run      - TX - 512-280-6578
The Coco Exchange - CA - 619-272-3643 | Pot O' Gold        - BC - 604-564-8869
The Coco Library  - HI - 808-545-8368 |


Later, Tim!

[37m--- FleetStreet 1.12 NR
 * Origin: Trial Run - Austin, Tx - [512-280-6578] (1:382/107)

[36m
Public Message 
[36mMessage # 262 *OS9 ECHO*[32m
To      : Merv Curley
[33mFrom    : Tim Jones
[35mSubject : Re: New RiBBS Programs!
[37mDate    : 96/05/31  06:40:00[33m

Hello Merv!

Replying to a message of Merv Curley to Brent McLaren:


 MC>    Well we don't need a file hatched out, just a message like the
 MC> Periodicals listing  or my list of Ribbs systems which is posted for
 MC> Ribbs sysops.    I don't have any idea who all are distributing
 MC> Files. Probably only Tim knows that.    Is it Tim, I'm not sure now,
 MC> <G>. Merv

It could be me. For a while I was pulling files off or RSTI and sending them
out via the OCN but I was dissatisfied with the cost/service ratio of my ISP
so I dropped it and consequently the file distributions dropped too. Now I'm
sure that I'm not the only person who had/has internet access as well as
access to and OCN bbs so almost anyone could do the same. 

Now having said that, I'm getting another provider so I'll try to resume the
distribution.

Later, Tim!

[37m--- FleetStreet 1.12 NR
 * Origin: Trial Run - Austin, Tx - [512-280-6578] (1:382/107)

[36m
Public Message 
[36mMessage # 263 *OS9 ECHO*[32m
To      : Arch Vile
[33mFrom    : Alan Dages
[35mSubject : Looking for stuff...
[37mDate    : 96/05/31  09:20:00[33m

> Does a CoCo 3 work with a Tandy CM8 CGA monitor?
> 
> I am looking for the following items.  I would prefer mail-order houses or
> stores in the Dallas/Fort Worth Texas area.  For the software, FTP or WWW 
> sitewould be great!
> 
> A CoCo 3
> adapter to use MFM/RLL hd's ( I have a MiniScribe 10meg model 3212)
> if not above, then where to buy a 10-40 meg one
> Basic 09
> OS9 Level 2
> RiBBS (latest version)
> Multi-Pack adapter
> 
> Let me know if you have any info. 
> Thanks, 
> Arch Vile

I have most of the stuff you asked for except the hard drive adapter. I do 
have IBM type hard drive cards but no adapter (like the Burke&Burke) at
the present time. I don't have RIBBS but that is available from Warren Hrach
on this echo. Give me a call at (770)469-5111 to discuss prices and shipping.






... MONEY TALKS...but all mine ever says is GOODBYE!
___ ADQwk/OS-9 32a
[37m--- GrayQwkMail 2.1
 * Origin: ACS Inc. BBS 404-636-2991 (1:133/510)

[36m
Public Message 
[36mMessage # 264 *OS9 ECHO*[32m
To      : Dave Kelly
[33mFrom    : Alan Dages
[35mSubject : Find someone
[37mDate    : 96/05/31  09:20:00[33m

You said to Arch Vile:

> I see by your tag line that you are in the Dallas/Ft Worth metroplex. I 
> would like to ask you to find someone for me.
>  
> There is/use to be a group called DALTRug (Dallas Tandy Radio Shack Users 
> Group) that met once a month at the InforMart on Stemmons Pkwy in Dallas. 
> They even had a BBS (now disconnected).
>  
> Some of their members were very active on these echos. Right after the 
> Chicago Coco Fest in April  of 95 everybody seems to have dropped out of 
> sight.

You might try looking up the following good CoCo supporters:

Lee Veal, 8809 Linda Lane, Rowlett, Tx 75088
David Wordell, 833 Woodhaven Lane, Grand Prarie, Tx 75052

Both of these guys were/are very active!

... What did you do before this message appeared ?
___ ADQwk/OS-9 32a
[37m--- GrayQwkMail 2.1
 * Origin: ACS Inc. BBS 404-636-2991 (1:133/510)

[36m
Public Message 
[36mMessage # 268 *OS9 ECHO*[32m
To      : Alan Dages
[33mFrom    : Dave Kelly
[35mSubject : Find someone
[37mDate    : 96/05/31  18:30:00[33m

Lee Veal and David Wordell are exactly the 2 people I am lookinf for. As you
know they were not at Atlanta or Chicago last year.
 
I tried the DALTRug BBS and the number is disconnected. I contacted the sysop
of the BBS that keeps the MetroPlex BBS list and he could not help me with any
information.
 
Wonder where they have gone or what happened. We occationally saw Wayne
Thompson and Ober Bower here and they worked for Texas Instruments.
 
Hmmmmmm!

[37m--- Maximus 2.02
 * Origin: THE GOLDEN COCO other's COMPUTER (1:106/941)
[37m
[31m=*= [32mFIDO ECHO MESSAGES MENU [31m=*=[36m

<1> Scan  \
<2> Read   > OS9 Echo mail             
<3> Leave /
<4> Scan  \
<5> Read   > CoCo Echo mail
<6> Leave /
<A> Scan  \
<B> Read   > MM1_TECH Echo Mail
<C> Leave /

<G>o back to Main Menu
<P>revious Menu (Messages Menu)

[35m[[37m53[35m][33m Command [37m>>> 