2407 lines
84 KiB
Plaintext
2407 lines
84 KiB
Plaintext
|
||
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 <20>a
|
||
HUGE difference, which Chris Dekker has already done. Now all I've got <20>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
|
||
<EFBFBD>allocation bitmap.
|
||
|
||
One: Keeping a cache in-memory of free sectors in the allocation bitmap. <20>
|
||
This would take 2 pages out of system memory for each hard drive (not
|
||
<EFBFBD>floppy), but would make RBF do a 'best-fit' instead of 'first-fit'
|
||
<EFBFBD>algorithm. This could also be coupled with additional code to allow
|
||
<EFBFBD>segments to contain more than 1 allocation bitmap sectors worth of
|
||
<EFBFBD>sectors... but I don't know how feasible that is.
|
||
|
||
Two: Spread the allocation bitmap across the disk. This would involv a <20>new
|
||
FREE, FORMAT, DCHECK, etc. I didn't think of this myself, but had a <20>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 <20>try
|
||
to put all of one file in the region handled by a sub-component of <20>the
|
||
allocation bitmap.
|
||
|
||
In the extreme, you could have the bitmap spread across the disk in
|
||
1-<2D>cluster sections. So each 512K section of the disk would start off with <20>1
|
||
sector of it's own allocation bitmap, DRASTICALLY reducing seek times <20>for
|
||
file create and delete.
|
||
|
||
In fact... if I fixed RBF to re-map sectors 1-256 automatically, FREE <20>and
|
||
DCHECK, etc. wouldn't even know that the bitmap was spread across the <20>disk.
|
||
The only problem here is re-formatting your disk to the new method,<2C>and
|
||
re-writing RBF to handle this form of the allocation bitmap. I'll <20>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 <20>out
|
||
negative. If you're aware of this, it's not a big deal to program <20>around.
|
||
|
||
As for 'fixname' being slow, I've got some spare time. Anyone willing <20>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 <20>than
|
||
255 possible states for each sector. Why? Well, 0-256 for the <20>maximum
|
||
number of free sectors, plus (perhaps) a per-sector flag saying <20>'updated' or
|
||
'invalid'. The flag may be able to go somewhere else, but I <20>doubt it.
|
||
|
||
I have to agree, though, the ideas other than a R+W cache are pretty <20>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 <20>it
|
||
was just too slow: both the compile AND the resulting programs. The <20>Coco C
|
||
compiler is OLD, and generates TERRIBLE code. I've now got 2 sun <20>3/60
|
||
systems up and running, and am running Gcc on them, 20MHz 68020's, <20>with 4Meg
|
||
of RAM. GCC of a reasonable-sized program is about as fast as <20>Basic09
|
||
parsing a large file..
|
||
|
||
On another note, I have been frustrated with some of what Basic09 does
|
||
<EFBFBD>lately. Is there any point in writing a Basic09 -> ASM compiler? The
|
||
<EFBFBD>initial stages wouldn't be too hard, as it would only support the <20>simplest
|
||
command set. More complicated things could be added later.
|
||
|
||
Benefits? I don't think that it would be terrible faster than Basic09, <20>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>>> |