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 / Scan \ Read > MM1_TECH Echo Mail Leave / o back to Main Menu

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 !! 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. What?? You mean you put *pictures* in your docs?? Boy, you *do* go all out, don't you !! 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... (I _do_ appreciate the input.) I suppose...hadn't thought of possibilities like that !! 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 !! 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 !! 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 !!! 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> 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 !! 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 !! 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. ) That's the problem with using 2 byte integers...so limiting !! 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 !! 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 ) --> 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 ! 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 !!! 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. ) 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 ). 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 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 . 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 ). 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 . 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? 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... RT> ... Basic programmers never die. They just GOSUB without RETURN! Hey! I resemble that remark! --> 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 !! 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... ...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! 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 ) 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 ) --> 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 !! 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 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 ) 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. ) 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. -> -> 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...) 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> ). 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. 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! 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! 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 . -=> 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, . 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... :(... I believe I saved my process on floppy. (Docs wise, I know I backed up my SRC. ) 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 ?! 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> . 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 / Scan \ Read > MM1_TECH Echo Mail Leave / o back to Main Menu

revious Menu (Messages Menu) [35m[[37m53[35m][33m Command [37m>>>