29231 3-MAY 21:19  General Information
     RE: 4IN1 (Re: Msg 29162)
     From: DISTO        To: DAVIDBARNES

It may be just the descriptor is not set right. I have used them with no
problems. It the SASI drivers work, great. -Tony.

-*-

29363 9-MAY 02:13  General Information
     RE: 4IN1 (Re: Msg 29231)
     From: WAYNELAIRD   To: DISTO

hey tony, i have one of your sc-1's that i use under decb, and have ahard time
booting ultimaterm. Little behind, but i had heard of cures to this problem but
have'nt located them. any help? best, wayne

-*-

29387 10-MAY 20:55 General Information
     RE: 4IN1 (Re: Msg 29363)
     From: DISTO        To: WAYNELAIRD (NR)

Wayne, how old is your SC1 and do you have problems running any other disks? -
Tony.

-*-

End of Thread.

-*-

29232 3-MAY 21:20  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29198)
     From: DISTO        To: EDDIEKUNS

Must have been Marty's side of the connector you were having problems with. <
hehe> No, not a good idea to use the COCO's transformer. -Tony.

-*-

29233 3-MAY 21:23  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29222)
     From: DISTO        To: EDDIEKUNS

What is the date on your GIME again? I think you should beg, borrow or steal a
newer GIME and try it. -Tony

-*-

29299 6-MAY 19:08  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29023)
     From: RAGTIMER     To: OS9UGVP

Right!  I left everything just as for my Hemphill, and got no bugs, no bits, and

NO SPARKLIES!  Very clean, and my regards to Tony D. for a good job, and to Kev
for the patches.

-*-

29300 6-MAY 19:11  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29035)
     From: RAGTIMER     To: OS9UGPRES

Hey Kev, do you have micro-Emacs on the MM1 yet?  THAT would be my favorite
program editor.  Also Pete has to convert you to MIDI music, then you'd have
something to do on your Coco 3 till I get the port made. Hope you get the basic
grfdrv in time so I don't have to do ANOTHER VDG job!!!!  Well I should stop
sendijng you mail and let you do some work, mike k.

-*-

29301 6-MAY 19:17  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29085)
     From: RAGTIMER     To: OS9UGPRES

Didn't put your ground plane back on?  Does Marsha compalin about the FM and TV
getting hosed?  Seriously, a ground plane is not just a "smog control device"
that anyone with brains would throw away to improve performance.  A ground plane

help the logic singalas on the board behave better -- less ringing,
oscillation,l overshoot, and all the other "anbalog" effects that can cause
flakey, erratic operation, such as sparklies and bad bits and of course maybe
The Blob.

Oh well I guess yours is working just fine, but some users could push their Coco

over the edge by removing the ground plane.  --mike k (Yeah, I'm old enuf to
have heard all this EE stuff, grin)

-*-

29302 6-MAY 19:22  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29212)
     From: RAGTIMER     To: EDDIEKUNS

Eddie, maybe you really should get a new GIME chip... Thanks for asking my
question about using the unregulated juice in the Coco.

Anyway, I heartily recommend desoldering that power adapter jack from the DISTO
board and screwing it into the Coco case bottom -- neater on your case and no
worries about jerking the DC power cable and wrecking your ! Meg upgrade stack.
--mike k

-*-

29303 6-MAY 19:25  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29222)
     From: RAGTIMER     To: EDDIEKUNS

Eddie, your garbage may be related to the momentary flash of garbage I'd get
when CLEARing out of a green screen into a window. However, I no longer get that

these days!  Maybe it was cased by my running MEGA on the old 512K Boot but with

the new GrfDrv -- definitely not recommended, tho everything works just fine
that way except UltiMusE.

-*-

29307 6-MAY 20:05  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29300)
     From: OS9UGPRES    To: RAGTIMER (NR)

Mike - I'm pretty sure os9 pro comes with uemacs. I'm still needing to port my
favorite editor to osk, but others use emacs and the vt100 stuff now on the
mm/1.

Working, working... grin

-*-

29315 6-MAY 23:57  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29233)
     From: EDDIEKUNS    To: DISTO

Right -- I have the older GIME.  I'll see if I can borrow a newer GIME from
someone to test.  If that fixes the problem, well, it's news!

                       Eddie

-*-

29320 7-MAY 04:02  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29299)
     From: OS9UGVP      To: RAGTIMER

  Yes, my 1 meg upgrade has been running very nicely... but I still haven't made

enough use of it to fill up the entire meg.  I guess I just don't work the
machine hard enough!
  Bruce


-*-

29330 7-MAY 22:28  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29320)
     From: RAGTIMER     To: OS9UGVP

Yeah, me too -- haven';t seen an MFREE go below 300K yet, grin. Time to re-iniz
the /R0 to 128K or something like that, or maybe (horrors) use GShell...no, not
that desparate.

-*-

29352 8-MAY 22:05  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29302)
     From: EDDIEKUNS    To: RAGTIMER (NR)

Yeah -- I'm hoping a new GIME will fix my ills.  <sigh>  For now, the wire for
my 1-meg upgrade goes behind my computer setup against the wall, but eventually,

I plan on doing SOMETHING with it.  Hmm.  Actually, the *huge* plug for the
power adaptor caused me more grief than anything other than the timing problems!

I had to rearrange nearly every plug to make that monster fit in my power strip
without leaving anything else unplugged. Perhaps I'll buy a DC converter that
supplied just a little bit less power and cool off the heat sync.  That thing
gets unbelievably hot!!! The RAM itself is reasonably cool to the touch, but the

CoCo case above that heat sync is untouchable!

                     Eddie

-*-

29353 8-MAY 22:07  General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29303)
     From: EDDIEKUNS    To: RAGTIMER (NR)

What's wrong with running mega on your old 512k boot w/ new Grfdrv?  Just the
fact that VDGInt is unpatched you mean?

Anyway -- did you get that momentary flash of garbage with the old GIME,
perhaps, and it went away with the new one?  If so, that would increase my
motivation for getting a new GIME!

                   Eddie

-*-

29404 12-MAY 19:34 General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29043)
     From: DICKWHITE    To: EDDIEKUNS

Gad!  I have not been on since April 22.  How did your thesie committee come
out? Are they going to let you granulate?

-*-

29411 13-MAY 00:36 General Information
     RE: Help!  My computer hates me!  <Grin> (Re: Msg 29404)
     From: EDDIEKUNS    To: DICKWHITE (NR)

Hehehe ... they're quite willing to let me be part of the solution.  (ie: not
granulate for a while)  Only a couple more of these yearly meetings, and then
the <shudder> big one.  I was happy ... this meeting went well.  Esp after all
the work & energy I put into trying to be ready, <whew>  I was relieved!

                      Eddie

-*-

End of Thread.

-*-

29234 3-MAY 21:31  General Information
     RE: DACIA tech info needed (Re: Msg 29223)
     From: OS9UGVP      To: POLTERGEIST

  In the source for DACIA the status register offset (from the base hardware
address) and the DCD and DSR bits are defined (near the beginning of the file).
But I think you're going at this from the wrong direction... if the $99 getstat
call is made, then [A] contains a status byte that is exactly equivalent to the
6551 (RS-232 Pak) ACIA's DCD and DSR bits in it's status register.  I suppose
I'll have to Ron a call and see whats up.  I'll lete you know what  find out,
though it'll probably have to wait until tomorrow, because I'm on my way out the

door right now (for tonight).
  Bruce


-*-

29243 3-MAY 23:46  General Information
     RE: DACIA tech info needed (Re: Msg 29234)
     From: POLTERGEIST  To: OS9UGVP

    Sure, Bruce, no problem!  And thanks for the help!  I was looking at the
source code last night, and while I don't know that much about ML, I did see the

definitions that you put in for the registers.  One thing though, what does the
% mean at the beginning of a binary number?
    I also would like your permission for me to send a copy of the DACIAa source

code to Ron Bihler, more or less so he can see for himself the way DACIA works.
At the moment, he has RiBBS set up for the stock ACIAPAK based system, using
either the stock /T2 driver, or Bill Brady's, Wiz/WizPro drivers.  I tried the
Eliminator version of M2W, no luck. :-(
    Ron's BBS, RiBBS HQ, is available at 1-303-343-6707, and supports 2400 bps.

    Thanks, and take care!

    -- Brian

-*-

29272 5-MAY 12:30  General Information
     RE: DACIA tech info needed (Re: Msg 29243)
     From: OS9UGVP      To: POLTERGEIST

Brian,
  I was talking to Guy Loucks (our local club BBS sysop) about DACIA, and he
gave me h*** for a mistake I made.  In the SS.CDSta getstat call in DACIA it
seems I store the 6551-equivalent status byte to the caller's [A] register, as I

said, and as the manual says... but in order to match the modified ACIAPAK
driver, the status byte should be stored in the caller's [B] register!
  Anyway, if you look into the source you can fix it bychanging the line that
says "SaveCDSt sta R$A,x set ACIAPAK style DCD/DSR status in caller's [A]" to
"SaveCDSt sta R$B,x set ACIAPAK style DCD/DSR status in caller's [B]", and the
assemble the new version.  Its actually just a one byte patch, plus CRC, but
there are a couple different versions of DACIA out there, so I can't tell you
the exact offset.
  I will be uploading a new DACIA source and binaries ARchive, most probably
with an updated manual file included.
  Oh... feel free to send Ron Bihler a copy of DACIA's source, but I think he
already has one... unless Guy didn't send him one after all.
  Bruce


-*-

29304 6-MAY 19:41  General Information
     RE: DACIA tech info needed (Re: Msg 29272)
     From: POLTERGEIST  To: OS9UGVP

     Thanks, Bruce!1
     No need to feel embarresed, we all screw up once in awhile!  But, I tested
the fix.  Result?  Boffo success!  I was preparing a MODPACTH script based on
differences found by CMP on both the original and new DACIA source code.

     --Brian

-*-

29321 7-MAY 04:06  General Information
     RE: DACIA tech info needed (Re: Msg 29304)
     From: OS9UGVP      To: POLTERGEIST

Brian,
  Great!  I'm glad the fix worked, though I was assured by Guy Loucks that the
one simple change was all thats required.
  I've got the new Eliminator software ready to go, except I want to test it
just a little longer before I ARchive everything up and upload it here there and

everywhere.
  The DACIA driver has a few small changes in addition to the SS.CDSta fix, but
nothing too drastic.  The biggest change is the addition of SS.CDSta and
SS.HngUp to the ACIAPAK driver, and of course the manual changes to explain
everything.
  Bruce


-*-

29334 7-MAY 23:20  General Information
     RE: DACIA tech info needed (Re: Msg 29321)
     From: POLTERGEIST  To: OS9UGVP

     Proof positive that a lot of pestering can get bugs sqashed. <grin>  Let's
hope that you don't create any new ones in the process!

-*-

29341 8-MAY 08:14  General Information
     RE: DACIA tech info needed (Re: Msg 29234)
     From: BILLDICKHAUS To: OS9UGVP

Bruce,

I gave Ron Bihler a patch for ACIAPAK ages ago that returns DCR/DCD status in
register B (if there's no error, of course) for the $28 (SS.ComSt) getstat call.

I also gave him a patch to swap the meaning of DSR/DCD in ACIAPAK.

Since the DSR/DCD swap isn't needed for a 6552, it seems like replacing the $28
call with a $99 call, and checking register A instead of register B would be all

the changes required to get it to work with DACIA.

Bill

-*-

29357 8-MAY 23:03  General Information
     RE: DACIA tech info needed (Re: Msg 29341)
     From: OS9UGVP      To: BILLDICKHAUS

Bill,
  Good to hear from you... its been quite a while!  As it turns out, I have
already put together a package containing a fixed CDStat call (still at $99)
that returns the 6551-equivalent DSR and DCD status in the [B] register.  I
guess Ron Bihler assumed the [B] register would always be used in his DCD check
routine... and since that was what matched your ACIAPAK patch, thats what I've
changed to.
  Bruce PS:  I will be uploading the new eliminator software+manual ARchive
tonight.


-*-

End of Thread.

-*-

29235 3-MAY 21:39  Patches
     RE: TSWORD (Re: Msg 29225)
     From: OS9UGVP      To: KNOT1

Jamie,
  The only problem with comparing the data size (page count in [B]) to zero is
that if some Forked module has a default data size of 0, Shell will let that
pass.  Of course, F$Fork will fix it up with at least 1 data page, but its still

what I consider "bad form" to even attempt a fork with no data memory.
  That aside, if you *DO* fork a program that has a default of 0 data memory,
then a compare to 0 does nothing at all, but a compare to 1 would get your
forked program 31 data pages, which may mess the program up.  So far as I know
the only reason the compare to 31 pages is in there was because Ron Lammardo
hated to see any program use only a small portion of 1 8K block, even if that's
all it needs!  <grin>
  Beyond that, if a program needs more memory than its default data amount
specified in the module header, then the M$Mem entry should be adjusted to suit
what the program really needs.  Most programs should be OK if the recommended
200 bytes for parameters plus 200 bytes for stack plus program variables memory
allotment was adhered to.
  Bruce


-*-

29247 4-MAY 04:25  Patches
     RE: TSWORD (Re: Msg 29235)
     From: KNOT1        To: OS9UGVP

Bruce:

Yes, using a value of 1 does sound a little "safer," even though I suspect (but
don't know) that the original Shell does use a zero value, or at least that was
what I was tring to emulate.  I not sure if you realized, but what is being
compared to 31 is what the user enters on the command line, not M$Mem in the
module.  Only F$Fork looks at that, and uses either M$Mem or the optional data
size (passed to F$Fork when called), which ever is the larger. If you already
knew this, then "never mind!" <grin>

I tried patching both bytes, and now everything works as expected.  So, good job

there, Bruce.

So, for anyone who wants it, this is the NEW-and-IMPROVED patch to Shell+ to
disable it's automatic memory allocation:

 * Disables shellplus's automatic 31 data block allocation
 *   when a process is forked (as if "#31" had been used on
 *   the command line).
 l Shell
 c 130F 1F 01
 c 1313 1F 01
 v

That should pretty much resolve this matter.  Thanks for woring this out with
me.

                         -Jamie Wilmoth (KNOT1)-

-*-

29273 5-MAY 12:34  Patches
     RE: TSWORD (Re: Msg 29247)
     From: OS9UGVP      To: KNOT1

Jamie,
  Yes, its been a while since I looked at it, but that is how I recall that
F$Fork works.  Thanks very much for confirming it all!  I'd have checked it out
for myself, except I don't have TSEdit, and for that matter I rarely use Shell+
V2.1 ... <GRIN>
  Bruce


-*-

End of Thread.

-*-

29236 3-MAY 22:16  General Information
     RE: opps.................. (Re: Msg 29195)
     From: ENDOTSON     To: GREGL

Actually, i appreciate all of the info i can get.  This is the first time
that i have ventured this deep into the disk structure and it is a learning
experience.  I had gathered about the variable map size from the recent
VERY helpful Rainbow article on disk structure, but it sounds like i may
still be missing something:

I am only referring to doing a logical format, and understand that it would
have to rewrite the id sector and the map.  But it has been my understanding
that it would leave any data in LSNs above the map untouched, at least
untouched enough for ded to get a look at it.  Is this correct??

I was thinking that i would then be able to manually rebuild the id sector
and root directory (with ded) and use dcheck to generate a new map that i
could transplant in with ded.

Some of this is from a description from someone else about what they did
in a similar situation.

ttfn

-*-

29239 3-MAY 22:37  General Information
     RE: opps.................. (Re: Msg 29236)
     From: GREGL        To: ENDOTSON

Ernest,

    Whether or not you partition the drive with the first partition as only the
first cylinder and logically or physically reformat is pretty much immaterial.
It doesn't matter if you physically format or logically format the first
cylinder. The only real "point" is the amount of work you'll have to do to
recover once you do it.
    For example, if the root directory and the file descriptor for the root
directory are in the second cylinder then you don't have much of a problem. Just

restore LSN 0 and the sector allocation table and you're done. If the root
directory is in the first cylinder then you have a mass of work on your hands.
You'll have to manually rebuild LSN 0, the sector allocation table, file
descriptor for the root directory, the root directory itself, and possibly some
files.
    The difference is that rebuilding the sector allocation bit map isn't much
of a problem - dcheck will actually build it for you (albeit, in a standard
file) so you could just copy the file built by dcheck into the right LSN's to
rebuild it. On the other hand, rebuilding a directory from scratch is not an
easy task. Believe me, I had to do it once and I thought I was going to have a
heart attack before I got finished. It's definitely not a task I have a desire
to do again.

    -- Greg

-*-

29246 4-MAY 03:04  General Information
     RE: opps.................. (Re: Msg 29239)
     From: ENDOTSON     To: GREGL

Hmmmm, i see what you are saying.  So basically to see if it is worth fooling
with, i need to make a final determination of whether the root directory was
defined inside of LSNs 0-31 or later.

If later, no big deal.

If inside 0-31, it looks like i should consider forgetting about it , reformat,
and restore from my two month old (blush) backup set.

Many thanks for helping me understand this stuff.

ttfn

-*-

End of Thread.

-*-

29237 3-MAY 22:18  General Information
     rs controller
     From: TEDJAEGER    To: DPHILIPSEN

Dave, a couple of months ago you hacked my floppy controller to further decode
its memory address. I want to check on something: you said that as a result of
the hack it could be used on a y-cable with the Burke and Burke HD interface,
right? I may have to go that way to get my system in an AT case. Is there not
any problem on the Y-cable created by the fact that the B&B needs 12 volts? Is
there any hacking necessary for the B&B product? Thanks and by the way, I am
still using SUperComm (good job!). --TedJaeger

-*-

29244 4-MAY 01:10  General Information
     RE: rs controller (Re: Msg 29237)
     From: TIMKOONCE    To: TEDJAEGER

Getting a floppy controller and a B&B to co-exist off a Y-cable requires three
changes:
  1) You need to alter the addressing on the floppy controller so it doesn't
respond to the $FF5x range.
  2) You need to disable the ROM decoding in the B&B.  (Cut one trace and a
resistor to pull it high/low I don't recall offhand.)
  3) You need a 12-volt supply to power the B&B.  It is possible to use a little

wall transformer, just requires a bit of wiring, and some filtering to get a
stable supply.
                             Good luck,
                                   Tim Koonce

-*-

29270 5-MAY 11:15  General Information
     RE: rs controller (Re: Msg 29244)
     From: TEDJAEGER    To: TIMKOONCE

Thanks for the info on B&B and Y-cable, Tim. The reason I was asking is I have
been trying to use a Howard Medical Slot Pak II with my RS HD interface and
floppy controller and, while the slot switching works fine, I keep buring out
the slot pak after about 1 hr use. I know it is installed right but I have lost
two slot paks the same way. You have any ideas what could be going on? There is
a 12 volt supply to the slot pak from a wall transformer and the slot pak takes
it 5 volts from pin 9 on the coco interface I suppose. Could there be anything
backing up from the disk drive power through the controller to the slot pak?

Thanks for any thoughts, TedJaeger

-*-

29277 5-MAY 16:42  General Information
     RE: rs controller (Re: Msg 29237)
     From: DPHILIPSEN   To: TEDJAEGER

Ted, you can use your floppy controller with the B&B HD interface on a Y cable
now. There will be no address conflict on the SCS ($FF40-FF5F). But, make sure
that only ONE of the devices has a ROM in it (either the XT ROM in the B&B or
the RSDOS ROM in the floppy controller but not both!) Also, I think you may need

to supply the 12 volts onto the correct pin on the edge connector (as outlined
in a CoCo 1 Tech manual). Basically if you do these things, it would be
identical to my setup which has been working great for a couple years now. By
the way, I boot directly from the HD using XT ROM and I don't have a ROM in the
floppy controller. Also, supplying 12 volts on the correct conductor of the
ribbon cable is not a problem as long as you put it on the right conductor!

-Dave

-*-

29310 6-MAY 22:04  General Information
     RE: rs controller (Re: Msg 29277)
     From: TIMKOONCE    To: DPHILIPSEN

Actually, Dave, just pulling the ROM from the B&B isn't enough.  I need to
occasionally use RSDOS, so I need a ROM in the floppy controller, and had to do
a little minor surgery to the B&B to keep it from driving the bus during ROM
accesses.  Although it depends on the particular hard disk controller you're
using.
                        - Tim

-*-

29311 6-MAY 22:06  General Information
     RE: rs controller (Re: Msg 29270)
     From: TIMKOONCE    To: TEDJAEGER

Burning out the Slot pak sounds evil.  YOu should try to narrow down more
closely exactly what's burning out.  One potential problem is that the CoCo 3
doesn't have a very beefy 5 volt supply, and that may be causing a problem.  It
might be worth checking into getting a separate 5 volt supply for the Slot Pak.
                        - Tim Koonce

-*-

29393 11-MAY 19:18 General Information
     RE: rs controller (Re: Msg 29310)
     From: DPHILIPSEN   To: TIMKOONCE (NR)

Oh, well I guess I never use RSDOS anymore (haven't for several years). I
suppose a person could wire in a little switch to do the trick...

-Dave

-*-

End of Thread.

-*-

29238 3-MAY 22:25  General Information
     RE: No permission? (Re: Msg 29229)
     From: DCJR         To: BILLBEISSERT

If you can chd to /d0/bootlist, then bootlist must be a directory, right? os9gen

needs a text file to drive it, and can  n't read a dire ectory file, which gives

you the permission error. Try a chd to /d0/bootlist and use build or edit to
make a list of the modules you want, and use that text file to drive os9gen.

-*-

29248 4-MAY 06:21  General Information
     RE: No permission? (Re: Msg 29238)
     From: BILLBEISSERT To: DCJR

THAT is exactly the problem! Now it makes sense. I suppose that if I had read a
little farther that would have been mentioned in one of the manuals...and I
thought that I knew what I was doing. Well, at least I didn't try to CHD to a
textfile <grin>. Thanks... Bill

-*-

29249 4-MAY 06:28  General Information
     RE: No permission? (Re: Msg 29230)
     From: BILLBEISSERT To: OS9UGPRES

Being the "rookie" I had built a directory BOOTLIST and copied all the needed
modules to it rather than a textfile as pointed out in msg #29238. I'll get the
hang of this yet. Just started START OS-9 and probably should've waited until I
had finished the tutorials. I'm learning...the hard way. Thanks... Bill

-*-

29265 4-MAY 23:57  General Information
     RE: No permission? (Re: Msg 29248)
     From: DCJR         To: BILLBEISSERT

Glad I could help! <<BIG grin>> Doug James(DCJR)

-*-

End of Thread.

-*-

29240 3-MAY 23:08  Tutorials & Education
     Two Ramdisks?
     From: ZACKSESSIONS To: ALL

I want to create a second ramdisk called /r0. When I tried this, I made a copy
of the /r0 DD and patched it to be drive $01 and device /R1 (making sure to have

the upper bit of the 1 turned on). But when I boot from a bootfile with the DD
in it, both drives /r0 and /r1 seem to contain the same information. What am I
doing wrong?

Zack

-*-

29252 4-MAY 18:34  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29240)
     From: DODGECOLT    To: ZACKSESSIONS

Zack-
 I think that most Ramdisk drivers are written to access only one drive. Two
drives requires a separate block map and extra data space.
 -Mike

-*-

29259 4-MAY 19:47  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29252)
     From: ZACKSESSIONS To: DODGECOLT

I didn't mention (I think) in my original message, but I am using the "official"

Tandy/Microware ramdisk drivers and modules. From what Kev tells me, it can be
done, and will try as soon as I'm offline. Will let you (and Delphi) know the
results.

Zack

-*-

29274 5-MAY 12:38  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29240)
     From: OS9UGVP      To: ZACKSESSIONS

I'd suspect you aren't doing anything wrong... but rather the ramdisk driver is
ignoring the physical drive number, and treating the $00 and $01 drives alike.
  Short of disassembling and fixing, or writing a new ram driver, I don't know
what you can do.

  Bruce


-*-

29275 5-MAY 13:19  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29274)
     From: ZACKSESSIONS To: OS9UGVP

FYI, Bruce (and anyone interested), I got it to work with a little trial and
error. I was patching the IT.DRV (Drive Number @ $13) frorm $00 to $01. That was

not necessary, and in fact rendered the device unusable. You do need to change
the device name from /R0 to /R1 (turning on the upper bit in the 1, of course!),

and you have to increment the Address field in the module header. Works just
fine! (This IS using the Microware Ramdisk driver which comes with the Dev Pack.

Dunno if other ramdisk drivers would work like this or not.)

Zack

ps, I get some weird looks when I try to spend that Canadian $20! :-)


-*-

29319 7-MAY 03:59  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29275)
     From: OS9UGVP      To: ZACKSESSIONS

Zack,
  Thanks for the information about the ramdisk... I hadn't thought about
changing the address, which makes sense now that I've been told it works! In any

case, its something else that may be useful in future, though I have no need of
multiple ramdisks right now.
  Oh, I meant to mention this before, but I think I ripped you off on the
exchange... it should've been about $17.00US, rather than the exorbitant amount
of $18.00US that I charged you!  I guess this means I'll have to add an extra
dollar when I send you the shareware money I've been meaning to send to you for
ages now!
  Bruce


-*-

29325 7-MAY 18:06  Tutorials & Education
     RE: Two Ramdisks? (Re: Msg 29319)
     From: ZACKSESSIONS To: OS9UGVP

:-)

-*-

End of Thread.

-*-

29241 3-MAY 23:16  Utilities
     MSDOS
     From: JACKOBRIEN   To: ALL

I'm new at this and I need help! I had a CoCo several years ago, and now I have
[A


talking about CoCo files that are on a DOS disk.  I would appreciate any help.
             JACKOBRIEN

-*-

29282 6-MAY 01:12  Utilities
     RE: MSDOS (Re: Msg 29241)
     From: GREGL        To: JACKOBRIEN

Jack,

    It looks like a lot of your message has fallen into a bit bucket somewhere.
From appearances, it looks like you sent a VT-52 or ANSI escape sequence that
threw the message into the dirt. Try it again using the backspace keys for
editing instead of the arrow keys.

    -- Greg

-*-

29285 6-MAY 09:21  Utilities
     RE: MSDOS (Re: Msg 29282)
     From: JACKOBRIEN   To: GREGL

Thanks, Greg.  I need to know if their are any easy utilities for transfer- ing
coco files that are on MSDOS disks over to coco format disks.  Such as public
domain or shareware.  I need a way to get a terminal up on my coco3. I have the
basic programs for Mikeyterm on my DOS machine, but ...you get the idea..
thanks for any help....
     Jackobrien

-*-

29305 6-MAY 19:46  Utilities
     RE: MSDOS (Re: Msg 29285)
     From: GREGL        To: JACKOBRIEN

Jack,

    There's a utility in the databases called PCDOS.AR that will allow you to
read and write MS-DOS format disks. Search on MS-DOS and/or PC-DOS to find it.
You'll need to grap PCDOS.AR and CC3DISK.IPC from that group and you might grab
RSDOS.AR from the group as well - it'll read and write RS-DOS formatted disks.
Then you'll need to download IPATCH from Utilities to patch the CC3DISK driver
with. You'll also need AR if you don't have it.

    -- Greg

-*-

29374 10-MAY 07:03 Utilities
     RE: MSDOS (Re: Msg 29305)
     From: JACKOBRIEN   To: GREGL

Thanks Greg, I'll give pcdos.ar and those other utilities a try.
             Jack

-*-

End of Thread.

-*-

29242 3-MAY 23:17  Users Group
     RE: MOTD (Re: Msg 29209)
     From: DWHILL       To: OS9BERT

Yeah, I got my copy last Saturday, I think it was.  Since it went out bulkmail,
it's likely to arrive at very irregular intervals, if my past experience with
the Post Awful is any indication.

--Damon

-*-

29360 9-MAY 00:53  Users Group
     RE: MOTD (Re: Msg 29219)
     From: OS9BERT      To: ZACKSESSIONS

I got mine in the mail too.  The folks at work didn't like the part about MS-DOS

(since they all have MS-DOS machines at home as well!!).  Glad you liked it,
maybe a follow up review is warrented!

Bert

-*-

29361 9-MAY 00:55  Users Group
     RE: MOTD (Re: Msg 29242)
     From: OS9BERT      To: DWHILL

It would be interesting to plot out when people got their copy.  It would also
be interesting to plot this over the map of the U.S. and see an animated display

over time!  Then we could video tape the animated display and send it to
congress to tell them what we think of the new price hikes in postal rates!!!
---> More time for your money (it keeps some people off the streets)

Bert

-*-

29385 10-MAY 20:02 Users Group
     RE: MOTD (Re: Msg 29360)
     From: MIKEHAALAND  To: OS9BERT

~ You got yours too!  I STILL have not got my MOTD!  I know I'm still a member
sice I just sent in 2 years worth of dues.  Did you get the new version from me,

Burt?  If not lemme know and I'll get a review copy out to ya.

Mike

-*-

29412 13-MAY 00:48 Users Group
     RE: MOTD (Re: Msg 29385)
     From: OS9BERT      To: MIKEHAALAND

No I didn't!  You should get your MOTD soon.  Like I said to someone here on the

board, we should plot the time it takes the MOTD to get out to everyone and send

the results in to Congress.  Show them what a great postal service we are
getting with the increase in "user fees", i.e. higher stamp prices!!!!

I'd like to do a follow-up review (and perhpas get Bill to get it out sooner).
He must have forgot or had trouble getting the pictures printed in his desk top
publishing software.  I had two .vef pictures of you screens so people could see

what it actually looks like rather than just talk about it.

By the way, my better half said that I can buy a sound box this fall!!!

I can't wait to hook it up to my CoCo!!!!

Take care, and keep on doing great things.

P.S.  I am in the process of developing a fractal program for the CoCo in OS-9
and I'm writting it in C!  All I have to do is get the user interface written,
the rest is done.  The user interface always takes the longest.


-*-

End of Thread.

-*-

29250 4-MAY 08:59  Device Drivers
     Ribbs
     From: GUYLOUCKS    To: POLTERGEIST

Hello there, Bruce was telling me you had some questions about the Eliminator
and RiBBS, well the problem is a simple one there was an apparent mis
understanding in reguards to the SS.Cdsta call.  Bruces driver returns the
status in register A, and the BBS looks for it in REG B.  So to fix this you
must zap a byte in the driver You could use ded or whatever.  The fix is:

I have to appologize, I have made some other changes, I can not give you a ZAP
fix the way to fix it is to look for this. Save CDST STA R$A,x set aciapak style

Dcd/dsr status in callers [A]

change this to SAVECDST Sta R$B,x set ........

Then re-assemble the package.  That first line was supposed to be SaveCdst, no
spaces, I am having problems with noise here again.  Hop I was of assistance.

             -Guy

-*-

29266 5-MAY 03:25  Device Drivers
     RE: Ribbs (Re: Msg 29250)
     From: POLTERGEIST  To: GUYLOUCKS (NR)

     Guy,
     THANK YOU for the information!  I didn't quite understand the fix, I
understand you had trouble with line noise.  Could you repost it again for
clarity's sake?

     Thanks!

     --Brian

-*-

End of Thread.

-*-

29251 4-MAY 18:02  General Information
     RE: cocobin file extentions (Re: Msg 29146)
     From: CAPTSWOOSH   To: TRIX

thansks for the help... Ron

-*-

29253 4-MAY 18:38  Programmers Den
     G/P mapping...
     From: DODGECOLT    To: OS9UGPRES

Kev-
 I know this is a bad time, but is there any way of forcing GRFDRV to map G/P
buffers into low blocks first? Right now my editor is $5f13 bytes long and
leaves the last block free... Problem comes when I try to map in a buffer which
is almost 8k long- it gets put into the last block, and then I change the
contents of that buffer and wipeout the $FExx and $FFxx areas by accident!
 -Mike

-*-

29279 5-MAY 16:53  Programmers Den
     RE: G/P mapping... (Re: Msg 29253)
     From: OS9UGPRES    To: DODGECOLT

Mike: how about this instead: map in some other buffer first which you don't
intend to access. You can check the mapped-in address returned to your program
to make sure things went okay (in other words, so if you <your> program grew or
was merged with another, then you could figure out if this fake mapping was
needed or not).

So I'd just map stdfonts, then map the buffer you REALLY want to use... which
should then come in at a safe spot. - kev

-*-

29309 6-MAY 21:14  Programmers Den
     RE: G/P mapping... (Re: Msg 29279)
     From: DODGECOLT    To: OS9UGPRES

Hmmm, good idea. Now I just have to fix up all the OTHER bugs!  :)
 -Mike

-*-

End of Thread.

-*-

29254 4-MAY 19:38  General Information
     RE: Rainbowfest New 68000 Machine Report (Re: Msg 28803)
     From: PKW          To: MARTYGOODMAN (NR)

Marty,

Sure, we can get back to the real issues. I and you both are pretty affable
fellows, so as far as we're concerned we can just move right along.

Concerning your comment about the other guys machine eventually being used as an

intelligent I/O board, you are probably right. I am glad there is an alternative

to that concept though, for if it were the only choice, by the time folks REALLY

got fed up with the OS-9/6809, there wouldn't be a reachable market of any size
for OSK. Remember, we've got to have a sizeable market to get developers
interested, and I KNOW that a good number of the 6809 developers are jumping
ship to OSK and 68K machines now.

So, as I have maintained all along, there is an excellent place for the MM/1
 and if the other guys keep a few more 6809ers in our domain, great.

Paul

-*-

29255 4-MAY 19:42  General Information
     RE: Rainbowfest New 68000 Machine Report (Re: Msg 28804)
     From: PKW          To: MARTYGOODMAN (NR)

Marty,

I would disagree with the ability of FHL (actually Hazelwood's) machine to be
MORE expandable. Card size for our bus is not intrinsically limited, and our bus

is a true 32 bit bus, allowing for better performance from a 68030.

I know the designer of the other guys machine -- he's a prince of a guy -- so
I'm not trying to detract from him. But the K Bus is 16-bits wide. And in the
volumes that FHL will sell, they won't get economies of scale to make the cards
affordable.

Paul

-*-

29260 4-MAY 19:55  General Information
     RE: Rainbowfest New 68000 Machine Report (Re: Msg 28800)
     From: PKW          To: MARTYGOODMAN (NR)

Marty,

Your absolutely right about the resolution of the MM/1 not comparing to Super
VGA (a rather unstable "standard" -- there are many tales of woe trying to get
Super VGA boards to work at all ....)

Super VGA is great when you want to do desktop publishing, and of course, no
resolution is enough for long -- 1k by 1k will be fairly common on desktops in
three or four years, RAM prices continuing to be cheap.

One of the biggest pluses for high res is the ability to put lots of little
windows on the same screen. Of course, with OS-9, this is not so much of an
issue since you can have TWO screen to hold half as much data each. So, two 640
x 400 windows do about the same work as one 1200 x 400 (Amiga 3000 style) or one

800 x 600.

Now, with the GIME based machines, you'd need four screens to hold the same
number of windows. Considering, too, that National Parts only has a limited
number of GIME chips LEFT, I think that the trend for higher resolution is going

to leave some of us behind.

BTW, we DO have a 720 x 560 mode, IF you buy a multisynchronous monitor to view
it.

Looks nice, I use such a mode on a VGA system from time to time. 50 lines per
screen looks quite readable.

Paul

-*-

End of Thread.

-*-

29256 4-MAY 19:43  General Information
     RE: MM/1 (Re: Msg 28816)
     From: PKW          To: DODGECOLT

Kits -- yes, we're thinking hard about introducing a kit. We have an EXCELLENT
strategy for this that may really give the CoCo user an exciting and easy
project.

Kit prices will vary depending on the size of the chip bag we send out.

We'll keep you informed as we know what we're going to do.

Yours,

Paul

-*-

29278 5-MAY 16:44  General Information
     RE: MM/1 (Re: Msg 29256)
     From: DODGECOLT    To: PKW (NR)

Thanks.  Anxiously drooling!
 -Mike

-*-

End of Thread.

-*-

29257 4-MAY 19:46  General Information
     RE: MM/1 (Re: Msg 28828)
     From: PKW          To: THEREB

I'd be glad to send you press release info -- just drop me your address in
email!

Now, seriously, how can you GUARANTEE that you'll review the MM/1 favorably!?

Take a look at it. See if it's for you. See if the COMPANY behind it is doing
the right things for support. Then make the right decision. And if you get a
review machine, all we ask for honesty and a chance to respond!

Thanks so much for you interest.

Paul

-*-

29258 4-MAY 19:46  General Information
     RE: The New CoCo 4 (Re: Msg 28829)
     From: PKW          To: KEITHMARCH

Keith,

It's been sent!

Paul

-*-

29261 4-MAY 19:59  General Information
     RE: OS9/68K (Re: Msg 28812)
     From: PKW          To: DRSPOON

Actually, if you have a need for a PC compatible with OSk, I have a cheaper
solution. Give me a call at 202/232-4246, M-F, 9:30 - 5:30.

Paul

-*-

29262 4-MAY 20:27  Telcom
     Osterm
     From: NEWKID       To: ALL


I need a little help. I'm using Osterm2.08 ( I believe ) and when I echo to
path, (path = /h0/downloads/file_name ) the modem, or software doesn't stop
transmission when buffer is being dump to disk.  So, what happens, I lose a lot
of characters. Is this the way it is supposed to act? Is there a way to have
transmission halted when data is to be dumped to disk?  When I used xcom9 I
didn't have this problem.  Any hints will be apprieciated!!! James Mc Daniel
Newkid

-*-

29264 4-MAY 22:42  Telcom
     RE: Osterm (Re: Msg 29262)
     From: ZACKSESSIONS To: NEWKID (NR)

I have never used XCom9, but I always echo to a ramdisk device with OSTerm and
have no problems with lost characters.

Zack

-*-

29268 5-MAY 10:36  Telcom
     RE: Osterm (Re: Msg 29262)
     From: AJMLFCO      To: NEWKID (NR)

I have been fighting this problem also for quite a while. When I echo to my hard

disk, I lose about 12 characters per disk access.  When I use a ramdisk, I lose
1 or 2 characters per access.  Sometimes the lost characters are spaces so that
you don't notice them as much.  I am suspect that Osterm does not use any flow
control.  I wonder if there is some way to turn on the X-ON/X-OFF
 in Osterm?  I am thinking of going back to either "WIZ" or "WIZPRO" since they
both support X-ON X-OFF. Ever try to do something in another window while using
Osterm?  I get errors in xmodem and ymodem transfers if I try to use a program
in another window at the same time. Allen

-*-

End of Thread.

-*-

29263 4-MAY 21:37  Utilities
     HDB/HDR
     From: JOHNREED     To: COCOXT (NR)

Hi Chris,
    Struggling back from a bad Hard Disk crash here. It was a 15meg (old) full-
height Tandon and it died hard. Blew a fuse in the 150W PC power supply I use to

run the drive motors.  So, I swiped the new 20 MEG Seagate ST-225 out of my
home-built XT-Clone and put it on the COCO 3. Here is the problem - the HDB/HDR
utilities that came with my Burke and Burke interface expect to restore to
another 306-cyl 6-head disk. A lot of the more important stuff was backed up in
other ways too, so I have most of it, but there are still a few things SOMEWHERE

in the 14 720k disks created by HDB that I would like to retrieve. My best idea
so far is a disk editor (DED) and a lot of patience.  Got any suggestions or
shortcuts?  Does HDB simply copy all sectors of the hard disk in order onto the
backups, or does it follow directory trees? Are there any "flags" in there I
could get the disk editor to hunt for? Lets see, 14 disks, * 2880 sectors
(whimper!).  JohnW

-*-

29267 5-MAY 10:05  General Information
     Adding Startup files
     From: BILLBEISSERT To: ALL

   I bought a couple of games from Radio Shack that are written in OS-9 Level
One version 2.00 and since they are going to be used by a younger child I added
a Startup file to make them auto execute (there was none originally). The file
simply consists of the CMD to get the game going. After adding the file the game

will not go beyond the opening logo/title screen and locks up. Removing the file

puts everything back into place and the game runs perfectly.
   Is this caused because I am using Level Two to build the file or is there
something else that I must include in it (SHELL is in the OS9Boot).

Bill

-*-

29269 5-MAY 11:07  General Information
     RE: Adding Startup files (Re: Msg 29267)
     From: ZACKSESSIONS To: BILLBEISSERT

I know next to nothing about Level 1, but in Level 2 you can put a copy of the
program in the CMDS directory and have it's filename be autoex and it will
automatically execute at boot up.

Zack

-*-

29281 5-MAY 23:18  General Information
     RE: Adding Startup files (Re: Msg 29267)
     From: CIZZIJR      To: BILLBEISSERT

bill,
 make sure you redirect standard input and standard output.
 here is a sample startup file:
 *Sample game startup file
 echo Loading game
 game </1 >>>/1

 this works for level 2 operating system.  just use
 game </term >>>/term
 if you are using OS-9 level 1.


 this should get you going,
 Carmen Izzi Jr. [cizzijr]

-*-

End of Thread.

-*-

29271 5-MAY 11:57  Utilities
     RE: TRANSFER OF PROGRAMS (Re: Msg 29174)
     From: DSRTFOX      To: GREGL

This is just what I've been looking for! BUT....when you say files, are we
talking ASCII files or programs? I would like to D/L some OS-9 programs, but
don't have an OS-9 terminal program. Will this method work? It sounds good,
since M/L is the same under both DOSes.

-*-

29283 6-MAY 01:30  Utilities
     RE: TRANSFER OF PROGRAMS (Re: Msg 29271)
     From: GREGL        To: DSRTFOX (NR)

Francis,

    We are talking either ASCII or Binary files. The most useful conversion
utility is called RSDOS.AR and is in the group named PC-DOS and/or MS-DOS in
Utilities. However, this one works under OS-9 and allows you to copy
ASCII/binary files to/from RS-DOS disks and needs a patch to the CC3Disk driver.

The patch file is included in the group and you'll need IPatch in Utilities, as
well.

    -- Greg

-*-

End of Thread.

-*-

29276 5-MAY 14:11  General Information
     RE: help (Re: Msg 29226)
     From: KENHALTER    To: DCJR

 I wish I could afford a hard drive. Actually, the drives are getting fairly
cheap but then I need the case, power, controller, interface drivers etc.
 That's when it gets expensive. It took a year for me to save up for the level 2

and 512k so maybe by the year 2010 I'll have my hard drive.
       Ken Halter

-*-

29284 6-MAY 03:24  General Information
     RE: help (Re: Msg 29276)
     From: DCJR         To: KENHALTER

I heard that... hit the hamfests and computer shows in your area. I managed to
pick up a 5 1/4 720k floppy for $15 and two seagate st212  hard drives for $30
each! All unuseed!
 Doug James(DCJR)

-*-

29396 11-MAY 22:10 General Information
     RE: help (Re: Msg 29284)
     From: KENHALTER    To: DCJR

 Now that's what I call a deal! I thought I was doing pretty good when I bought
a multipak& fd501 drive for $35.00 from radioshack.
 both were unopened and brand new. I really do want to get a hard drive tho.
Hopefully someday.......
  Ken Halter

-*-

29414 13-MAY 02:16 General Information
     RE: help (Re: Msg 29396)
     From: DCJR         To: KENHALTER (NR)

One warning tho... a hard drive will spoil on floppies forever!

DCJRDoug James

-*-

End of Thread.

-*-

29280 5-MAY 21:50  General Information
     RE: ATCoCo (Re: Msg 29216)
     From: MIKEHAALAND  To: JIMHARRISON

Great!!!!  I'm gald you finally got everything working correctly!  and happy to
be of any assistance.  Yup!  That keyboard is one of my favorite parts of the AT

case transplant too....

Mike

-*-

29286 6-MAY 09:37  Device Drivers
     disk drives
     From: RCDRCD       To: ALL

Any one know of a way or system call to test for a floppy disk not installed in
a drive with out hanging the system.

-*-

29287 6-MAY 10:42  Telcom
     Trade Wars
     From: NES          To: ALL

Is any one running trade wars under the Alpha Soft bbs software? I have
downloaded a file for it from the Alpha BBS, but seem's to have a file missing.
I you are running it, please let me know how to setup the game. and also where I

can get the complete file for it. NES     The OverBoard BBS (704)-822-1337


-*-

29288 6-MAY 12:52  Programmers Den
     readreading a directory
     From: NES          To: ALL

Hay, how do you read a directory in C, I am trying to use the Kreider dir.h
function's: opendir()  readdir(). NES

-*-

29290 6-MAY 16:15  Programmers Den
     RE: readreading a directory (Re: Msg 29288)
     From: ZACKSESSIONS To: NES

There are several programs in the Utilities and Prog Den libs which illustrate
the use of these functions. Did you get a copy of my Super Directory program? It

uses them.

Zack

-*-

29332 7-MAY 22:58  Programmers Den
     RE: readreading a directory (Re: Msg 29290)
     From: NES          To: ZACKSESSIONS

Zac, Had your program but it got zap!!!, thought I had a hard copy of it some
where.  Is it in the Utilities? thanx for you help NES    Eric


-*-

29342 8-MAY 18:06  Programmers Den
     RE: readreading a directory (Re: Msg 29332)
     From: ZACKSESSIONS To: NES

I am releasing that program along with a bunch of other utilities on an "OS9
Utilities Disk", so I had the sysop remove it (and others) fromthe libs. For
you, though, look for me to upload it to your BBS tonight.

Zack

-*-

29390 10-MAY 23:01 Programmers Den
     RE: readreading a directory (Re: Msg 29342)
     From: NES          To: ZACKSESSIONS

Zac, thanx for the upload, I did have it had to look thur alot of disk but it
was there, agian thanx for the help and upload,  I got the directory read
working now. my next set is to get file load menu working,so you can use the
mouse to select the file, BTW is there a command in the kreider lib for that?  I

send you the first working copy of IKE when I am finnished, also we are have a
demo of the MM1 at our Club meeting in June. Have you seen it yet. also hope
maybe to meet you at the Alanta Fest... latter and Thanx. NES    (Eric Stringer)


-*-

29392 11-MAY 18:12 Programmers Den
     RE: readreading a directory (Re: Msg 29390)
     From: ZACKSESSIONS To: NES

Yes, I saw the MM1 prototypes at the Chicago fest, VERY impressive. No, there is

not a Krieder function for point and click file selection. I think Burke&Burke
Sells a C function library which does have a point and click file pick routine,
though.

Yes, I am looking forward to the Atlanta Fest, too.

Be C'ing you,

Zack

-*-

29397 11-MAY 22:20 Programmers Den
     RE: readreading a directory (Re: Msg 29392)
     From: DODGECOLT    To: NES

I'm going to have a point-and-click file pick function uploaded fairly soon (
working on docs now...) which does a nice job. It is part of my CGFX replacement

lib, which also provides some other mouse-related functions. Expect to see it
sometime within the next week or so (now that finals are over!)
 -Mike

-*-

End of Thread.

-*-

29289 6-MAY 16:09  General Information
     smartwatch help!
     From: RICKLT       To: ALL

  I tried to install the Tandy smartwatch in the old 12v model tandy disk con-
troller.  I could not get it to opperate, with the smartwatch installed the disk

basic would not execute.  The computer would act as if the disk controller was
not installed in the multipak. I have the old multipak also, it has been up
graded to opperate with level II os9. If anybody could help me with this prob-
I would greatly appreciate it. I almost forgot, the computer does come up in ex-

tended color basic and opperates normally with the smartwatch installed but the
computer refuses to see the disk basic. Thanks in advance,

Ricklt (Rick Tackett)

-*-

29372 10-MAY 05:43 General Information
     RE: smartwatch help! (Re: Msg 29289)
     From: PAGAN        To: RICKLT

Rick,

I had some problems with the smartwatch a few months back.  When I replaced the
24 pin socket in my controller I made a little mistake in wiring. Double check
to be sure the new socket is wired correctly.

                                   Stephen (PAGAN)


-*-

End of Thread.

-*-

29291 6-MAY 16:38  Graphics & Music
     RE: VIEW 3.0 comments wanted. (Re: Msg 28249)
     From: DOCTORASCII  To: GREGL

PCX is for PC Paintbrush which runs unde{ Microsoft Windows.

-*-

29292 6-MAY 18:21  General Information
     Basic09 Help!!!!
     From: OLDGROUCH    To: ALL

I need someone's (anyone's) help with Basic09.  I started writing a very large
application program for OS9 but ran into a problem.  Let me explain...

The program I'm working on is large enough that it will have to be broken down
into modules that will be loaded off disk as needed ("new module replaces old
module" method.)  I want to write all the Basic09 code, Pack it, and then
execute the program as a standalone piece using RUNB.

So, I wrote my menu application and a dummy module to have it load and replace
itself with when asked to.  I packed both my programs (both of which ran inside
Basic09 fine).  Then I loaded my menu program off my execution directory and
tried to execute it (as follows...)

 OS9: RUNB MENU          (The packed MENU procedure is under 5000 bytes and
 ERROR #043               GFX2 and SYSCALL are already in memory when the
                          program is executed.)
 OS9:

Well, it seems both RUNB and MENU loaded, but it all stopped when OS9 reported
an error #43.  Well, come to find out, the error stems from a gfx2 call I make
in the program (it goes a little longer without that command...  until it hits
another one!)  But it should be noted that the gfx2 module is in memory and
linked several times!  So, why the error?

So, to add to all this, stumbling upon this by accident, if I changed the memory

requirements (RUNB MENU #6k, for example), it works fine.  That is, until I try
to load in the dummy module.  But I'm assuming if I play around with the memory
allocation for the dummy program a bit, it would probably work as well.  But, I
don't want to have to mess with all this (or place it on the user), so any
suggestions for all this mess?  Maybe use a different chaining method (Shell
"Fork program", Run Program, or whatever.)

Thanks for all your help.  If there's something that needs a bit more
explaining, please let me know.  Thanks again.  I certainly appreciate any and
all help that may be provided.

- Eric Wolf
  (OLDGROUCH)

-*-

29306 6-MAY 20:03  General Information
     RE: Basic09 Help!!!! (Re: Msg 29292)
     From: GREGL        To: OLDGROUCH

Eric,
    It sounds like you are getting memory allocation errors, although probably
not the way you would think. When you load RunB into memory it occupies
consecutive 8K blocks - 24K total for the code. When you load SysCall it uses an

8K block even though it is very small. Ditto for Gfx2. Plus your program is
loading into 8K blocks so round it's code size to the nearest multiple of 8K. So

your program needs 24K for RunB, 8K for Gfx2, plus the size of your program (in
a multiple of 8K) plus whatever data area both you and RunB need.
    When you use an 8K block size, your 64K process memory disappears rather
quickly. The easy solution is to cut down on the number of blocks needed. You
can do that by merging RunB with whatever other tools it needs, such as SysCall
and Gfx2. When you merge them together, they take up a lot less memory since
OS-9 will squeeze them into contiguous areas of memory.

    -- Greg

PS: If your Menu is 5,000 bytes then you are using 24K for RunB, 8K for SysCall,

8K for Gfx2, 8K for Menu, and maybe an additional 8K for data. That's around 48
to 56K plus additional memory it needs to link in your secondary program. Merge
RunB with SysCall and Gfx2, that should help.

-*-

29328 7-MAY 20:26  General Information
     RE: Basic09 Help!!!! (Re: Msg 29306)
     From: OLDGROUCH    To: GREGL

Greg

I have merged the RunB, Gfx2, and Syscall code together into one piece and the
menu program now seemingly works fine with the inclusion of passing on a
director for the input path: "RunB MainMenu </1" seems to take care of that.
But still when I attempt to load another module from that that may use a GFX2
call, I get a error #43.

I heard once that putting "gfx2" into a dummy variable and running that might
work:  Ex:  proc="gfx2" run proc("box",blah,blah....)

Have any suggestions on this alternative?  Thanks for your help.

- Eric Wolf

-*-

29346 8-MAY 18:27  General Information
     RE: Basic09 Help!!!! (Re: Msg 29328)
     From: GREGL        To: OLDGROUCH

Eric,

    Ah yes, I remember that RUN variable as opposed to RUN Gfx2 bug. IT seems
that under certain conditions (read that a LOT) BASIC09 and/or RUNB get confused

and think RUN Gfx2(...) is referencing a variable. The trick is to DIM
Proc:STRING and then use Proc:="Gfx2" followed immediately with RUN Proc(...).
Be sure to initialize Proc to the name of the procedure to run immediately
before the RUN statement at all times. Otherwise, Proc may contiain garbage or
nothing at all.

    -- Greg

-*-

29349 8-MAY 21:06  General Information
     RE: Basic09 Help!!!! (Re: Msg 29346)
     From: OLDGROUCH    To: GREGL

Greg,

Well, let me try that and I'll hopefully get back to you later tonight... I hope

this works!!!!

- Eric

-*-

29350 8-MAY 21:27  General Information
     RE: Basic09 Help!!!! (Re: Msg 29346)
     From: OLDGROUCH    To: GREGL

Greg,

Well I just tried your suggestion and no go.  I replaced every RUN GFX2(xx)
with..

DIM PROC:STRING ... PROC:="gfx2" RUN PROC("fill",4,4) END

I also did the SYSCALL replacement.  Now, it is probably important to know that
a file under 8k will work fine with RUNB without needing the proc definition at
all.  And anything over 8k, causes a scan to disk and an error #43.

Would it help any if you saw the source code for my file?  It is a little long
but if it would help to look at it, I can send it to your email box... Just let
me know.

- Eric

-*-

29351 8-MAY 21:56  General Information
     RE: Basic09 Help!!!! (Re: Msg 29346)
     From: OLDGROUCH    To: GREGL

Greg,

I've narrowed down a bit... I ran a dummy program of:

RUN gfx2("clear") print "====" END

 and packed that and ran it from my menu program and it worked fine.  But when I

repeated the RUN and print lines over and over to stretch the program out to
over 13000 bytes (a lot of repetitions!!!), it wouldn't work with RUNB!

So, I tried several other ways of CHAINing RUNB but none work for a file over 8k

(a packed file over 8k, that is, to be executed from RunB).

CHAIN "ex RUNB program #16k </1" or Chain "RUNB program </1" or Chain "RUNB
program #16k" or Chain "RUNB program" or ChAIN "RUNB program </1 #16k"

But none seem to work.  Now, CHAIN "RUNB program </1" works for any file under
8k so I thought just throwing in a memory modifier would fix things... BUT NO!
Any ideas?  Thanks for all your help thus far.  I certainly appreciate it!

- Eric

-*-

29369 9-MAY 22:05  General Information
     RE: Basic09 Help!!!! (Re: Msg 29351)
     From: WJMOORE      To: OLDGROUCH

For what ever it is worth, I run packed B09 programs simply by calling by its
name ie. "MainMenu".  OS9 knows that mainmenu is a packed module and will
automatically load RunB.  I dont know how the memory is managed under these
circumstances but might be o f some help.

Warren

-*-

29373 10-MAY 05:53 General Information
     RE: Basic09 Help!!!! (Re: Msg 29369)
     From: PAGAN        To: WJMOORE


I havn't used Basic09 since I discovered "C" <grin> but I seem to remember a
similar problem with error #043.  Try using KILL procedure immediatly after RUN
procedure where "procedure" is a string variable containing the module name.  Do

NOT use some thing like RUN gfx2(....) followed by KILL gfx2 or you may find
your program going off into la-la land.

                                 Stephen (PAGAN)


-*-

29375 10-MAY 12:15 General Information
     RE: Basic09 Help!!!! (Re: Msg 29350)
     From: GREGL        To: OLDGROUCH

Eric,

    Post the source code either into the database or into my mailbox. You can
send to me via E-Mail by uploading it to your workspace and typing SEND
FILENAME.EXT at the MAIL> prompt. This seems to getting strange.

    -- Greg

-*-

29386 10-MAY 20:21 General Information
     RE: Basic09 Help!!!! (Re: Msg 29375)
     From: OLDGROUCH    To: GREGL

Greg,

I will upload the source if things don't improve.  I went back just to using a
CHAIN "ex Basic09 #16k <>>>/1 Program" and that seems to work. The only problem
is that I'm not sure if variables will be passed if I use a chain command.

Well, now that I think about it, I know they won't.  I have already made plans
to make a get/put buffer an environment buffer.  So I can store program
essentials in there, move about program to program as I wish and just map the
buffer in and grab the data I need if I need to access it.

But, the base problem is OS9 seemingly forcing me to use the whole Basic09
module when the RunB would certainly be better for me memory wise (roughly a 12k

savings between the two.)

What you might want to try is a quick little test program that shouldn't be too
hard (or time consuming to punch in.)  Power up Basic09 with about a 16k buffer
and type in the following line into the editor.

 RUN gfx2("clear")
 / PRINT"=================(80 of these)============="

(Enter all that on one line.  I can't generate a reverse slash from this term
program.)

Then simply keep doing a ctrl+a to repeat the line over and over untill the
program exceeds about 9000 bytes of space.  Then run the program under basic09.
If it works, try packing it, and running it again under RunB.

And if it works, I'll kill myself!!!!!  Well, at least let me know how it goes
and I'll get back to you (possible with the source in your mailbox)

Thanks

- Eric Wolf

-*-

End of Thread.

-*-

29293 6-MAY 18:54  Device Drivers
     Hard Drive Woes
     From: DERFT        To: ALL

I've been using an Arizona Small Compouter Peripjherals 20 mb hard drive [D its
got about 5 meg on t it, and it won't take any more data (error 247). The last
time I talked to the gut at Arizina, he mumbled something ablout a different
initialization string for it (thru DMODE). Repeated attempts to reach him on the

phone or in writing during the past year have proved unfruitful. Can anyone
help? Thanks in advance. (current init string is 026704 (plus "whatever was in
there)".Thanks in advance!!  Shneor Sherman

-*-

29294 6-MAY 18:55  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 28999)
     From: RAGTIMER     To: GREGL

OK.  Turns out that requesting even just 8K more RAM is enuf to stop Umuse3 from

linking in the subroutines and data areas it needs. I just got a patch from
someone on CIS to fix Shell+ -- just one byte needs to be zapped -- but I have
it on disk so can't type it here now.

Thanks for the Fork and system() info -- looks like I can stick with system()
for now, since speed isn't important where I use it. I do use Fork to start up
Fran with the pipeline in between, tho.  --mike k

-*-

29295 6-MAY 18:58  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29001)
     From: RAGTIMER     To: OS9UGPRES

Kev, your logic is correct, but maybe, just maybe, the #31 means "31 MORE pages
than natural" so it goes over 8K.  Just guessing. However, someone on CIS
patched out the 31 to 0 and got Umuse3 to work under Shell+, so that seems to be

the problem.

Umuse3 does malloc() (in C) some temporary memory, tho not till you try to read
a file, so I don't know why the problem occurs. But we do know how to fix it.
I'll find the patch and send it on. --mike k

-*-

29296 6-MAY 19:01  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29005)
     From: RAGTIMER     To: KNOT1

Thanks for the extra info.  Umuse3 only want about 5800 bytes, but tries to
malloc() some temporary stuff later.  That's a C library function, and I still
don't know whether it takes its memory out of what you already have requested,
or must go BEYOND your original request.  If the former, great. Otherwise Sell+
ruins it for you.

Someone on CIS patched out the 31 in Shell+ and Umuse3 worked fine after that.
--mike k

-*-

29297 6-MAY 19:03  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29025)
     From: RAGTIMER     To: OS9UGVP

Thanks.  SOmeone on CIS patched a $1F to $00 and that fixed it. I have his
offset in a file, not on paper, so can't check it now (no multitasking while
modem is running, if ya know what hurts.) --mike k

-*-

29298 6-MAY 19:05  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29036)
     From: RAGTIMER     To: MIKEHAALAND

Thanks, Mike.  I just got your same message over on the rich-man's service.
Hope everyone's thread ends up here and reads your posting. The best minds are
still trying to figure out *why* the 31-page request causes the problem, but I
figure it's 'cuz malloc() always looks for memory *beyond* what your program
started up with.  Any ideas?  --mike k

-*-

29308 6-MAY 20:12  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29295)
     From: GREGL        To: RAGTIMER

Mike,

    If you're using the standard malloc() call then you should be ok, at least
theoretically. The standard malloc() will allocate the additional memory from
your workspace - the free RAM area between the data area and the stack. Unless
you have a modified version, I don't think malloc() will request external memory

via the F$Mem call. If you don't have enough memory preallocated, malloc() will
return a memory allocation error.

    -- Greg

-*-

29329 7-MAY 22:26  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29308)
     From: RAGTIMER     To: GREGL

Greg, that's interesting to know, if it's so.  My impression from my Fran
process is that malloc() would also go after any data space left over until your

full 63.5K was used up.  But I never really tested it, so may be wrong.

I'm using Carl K's first clib set -- don't know if that's "modified" in that
respect or not.  Never have disassembled any of the stuff, which is a shame, but

I never spent the $$$ for a OS9 dis-asser.

Actually, I'm pretty sure that malloc() wioll get you at least as much memory as

remains within the current 8K block of data space. Do you base your statements
on a disassembly?  Thanks, mike k

-*-

29347 8-MAY 18:41  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29329)
     From: GREGL        To: RAGTIMER (NR)

Mike,

    Yes, my statements are based on a disassembly of the original ROF files a
year or more ago. I'll take a close look at Carl's library tonight and see if he

does anything differently. The originally malloc() performs a SUB
StackTop,RamTop or similar and compares the result to your request. If the
result is zero or more it grants the request and adjusts ramtop. As I recall, if

you want more memory than you have currently allocated then you had to use an
explicit call to ibrk().
    The memory allocation scheme used under Level 2 is pretty fuzzy to me. I'm
not sure if the entire 8K block is considered part of the "preallocated" memory
or not. I vaguely remember Kev telling me that OS-9 keeps track of the DAT
blocks allocated to the process as well as the number of 256-byte "pages" used
so that would mean that you are allocated even multiples of 256 bytes within
blocks, not the whole block. So it would seem that if you request additional
memory via the F$Mem system call OS-9 would check the number of "pages"
currently allocated against the number of "pages" that you need and allocate the

difference; you wouldn't get a new block allocted unless you leaped across an 8K

boundary. Kev - is that right?

    -- Greg

-*-

29356 8-MAY 23:01  General Information
     RE: ShellPlus blowing Umuse3 memory (Re: Msg 29308)
     From: BILLDICKHAUS To: GREGL

Greg,

malloc() does go beyond current memory allocation. I think it probably keeps
issuing F$Mem calls until it uses up all of the available space. But I know from

experience that it goes way beyond whatever memory is initially allocated.

Bill

-*-

End of Thread.

-*-

29312 6-MAY 22:27  Programmers Den
     RMA/RLink boo-boo.
     From: TIMKOONCE    To: ALL

I just found a design problem in RMA/RLink.  I wonder if the 68k versions have a

similar problem.  Basically, the design problem is that ROF format files don't
distinguish between "signed byte" offsets and "unsigned byte" offsets.  More
concretely, all DP vars are referenced with a 1-byte offset when used as index
register offsets. That decision is made in RMA, which then tags the reference as

a "byte" offset.  The problem is that if you have enough DP vars, then you might

have a DP var which is at an offset of more than $7f, which is negative when
used in a constant offset.
  i.e.  DON'T USE INDEXED ADDRESSING WITH DP VARS IN RMA!!!!
  For C types, be careful of over-using "direct" storage class, it could get you

in trouble.

  This is all fine if you don't have more than 127 bytes of DP vars, but is a
bugger to track down if you do!

                                - Tim Koonce

-*-

29313 6-MAY 23:22  Programmers Den
     RE: RMA/RLink boo-boo. (Re: Msg 29312)
     From: ZACKSESSIONS To: TIMKOONCE (NR)

Tim,

I'm interested in this. Can you give me more detailed info. EMail will be OK.
(Don't reallyunderstand, I occasionally use reg A or B as index registers, but
never have use a DP variable to do this. And have found a similar problem with
register indexing.)

Zack

-*-

29354 8-MAY 22:14  Programmers Den
     RE: RMA/RLink boo-boo. (Re: Msg 29312)
     From: EDDIEKUNS    To: TIMKOONCE (NR)

The question for C users is:  under what circumstances will the C compiler
generate an index-register offset access to a direct variable?  Hmmm ... I
wonder if this causes any of the irritating and highly history-dependent bugs
that I've observed in KBCom and never been able to track down? Yes, KBCom has
quite a few direct variables, some of them arrays.

                Eddie

-*-

29368 9-MAY 21:00  Programmers Den
     RE: RMA/RLink boo-boo. (Re: Msg 29354)
     From: XLIONX       To: EDDIEKUNS

Howdy Eddie,

I was told by Kim (forgot last name) that the compiler drops the "DIRECT" off
arrays "in general". Might want to check this out. This was about three years
back when I was on C'serve. Was long and tangled thread of other stuff.

Seems like it should be easy for someone with ERINA or SERINA to track down the
indexing problem in RMA/RLINK for the DIRECT signed/unsigned bug.

Gotta go,

Mark W. Farrell XLIONX (DELPHI) SigOp - ProSIG (Pinball Haven-RIBBS)


-*-

29376 10-MAY 12:29 Programmers Den
     RE: RMA/RLink boo-boo. (Re: Msg 29312)
     From: GREGL        To: TIMKOONCE (NR)

Tim,

    You are experiencing a very basic problem with the direct page addressing
mode and linkers. As you are probably aware, when RMA assembles your source code

into a ROF object file it keeps track of the number of direct page variables
declared. If there are less than 128 it uses an 8-bit offset unless you
explicitly tell it otherwise, via LDA >DP_Var. If another source file also
contains direct page variables, RMA doesn't know about it and assumes there
aren't any more. When you link the files, RLink looks up the symbol table to
apply the fixups.

    When it reaches a DP variable access it sees an 8-bit offset and cannot
alter it to use a 16-bit offset without throwing off the whole object file and
really screwing things up. The end result is to do a little mental calculation
on the number of DP vars declared and force 16-bit offsets on those that are
more than 127 bytes into the direct page. It's not really a bug, it's a
deficiency in 8-bit offset calculations when you don't know what else is
declared in other object files.

    -- Greg

-*-

29382 10-MAY 19:45 Programmers Den
     RE: RMA/RLink boo-boo. (Re: Msg 29368)
     From: EDDIEKUNS    To: XLIONX (NR)

Right -- I know that arrays are accessed with extended addressing basically
because there are no direct indexed addressing modes.  I'm not sure if that's
related to the problem tho.  Greg Law and I think we understand it.

                   Eddie

-*-

End of Thread.

-*-

29314 6-MAY 23:51  Programmers Den
     RE: Text screen attributes (Re: Msg 29228)
     From: PAGAN        To: OS9UGPRES

Kevin,

First off, a "button" is a thing (can't think of a better word) that enables the

user to jump from one node to another.  That is by "pressing" a button the
software will access the node that has been attached and dispaly it for the
user.

When I use the term "fixed location" I mean the type of button used in Apple's
Hypercard.  This type of button has it's location fixed relative to the screen
and if the user makes changes to the node buttons may have to be re-positoned.
In Hypercard this has to be done manually and is something I was trying to
avoid.  It is, in my estimation, a serious weakness in Hypercard and one of
several reasons I've abandoned it as a serious hypertext tool.

A "sticky button" will remain attached to whatever text it was assigned to
during any editing.  This, I feel, is a superior method but, as I said before ,
the bookeeping can get really hairy (and I DO mean hairy).

The fixed position button is better for a graphic front end since the software
only needs to check the cursor position when the mouse is clicked to determine
which jump has been requested whereas with sticky buttons some calculation has
to be done to determine which button was "pushed".


I've done some experimenting with both types on the COCO and still can't decide
which I like the best.  With a keyboard driven interface (which I personally
prefer) the sticky button seems easiest to implement but since the rest of the
worls seems to have fallen in love with graphics front ends I'll prpbably have
to compromise somehow.  Maybe a few of you out there have some suggestions.

Can you believe that this started out as a recipe filing database for a lady
friend?

                                    Stephen (PAGAN)

-*-

29322 7-MAY 05:34  Programmers Den
     RE: Text screen attributes (Re: Msg 29314)
     From: OS9UGPRES    To: PAGAN

Thanks Stephen... nice explanation and I see what you mean now. Sounds like both

kinds of buttons would be handy tho (fixed button on top of world map, for
example). thx again! - kev

-*-

End of Thread.

-*-

29316 7-MAY 00:10  Applications
     liesure suit larry
     From: BANCROFT     To: ALL

Is there a hint file on liesure suit larry somewhere?


-*-

29318 7-MAY 01:47  Applications
     RE: liesure suit larry (Re: Msg 29316)
     From: KEVINLEGER   To: BANCROFT

 What do you need to know? I have made the max pionts on several ocasions.

also , Sierra has a BBS (209) 683-4463 up 24 hrs. a day!

 Kevin

-*-

29326 7-MAY 18:09  Applications
     RE: liesure suit larry (Re: Msg 29316)
     From: ZACKSESSIONS To: BANCROFT

I hate to plug the "other place", but CI$ has a gamers forum which has points
files for all of the major Sierra games, including LLLLL. I don't know if Delphi

has these on file anywhere or not. Sysop?

Zack

-*-

29331 7-MAY 22:31  Applications
     RE: liesure suit larry (Re: Msg 29316)
     From: RAGTIMER     To: BANCROFT

I'd like some hints too, tho I have some ideas to try yet, having found the claw

hammer.

-*-

End of Thread.

-*-

29317 7-MAY 01:46  Device Drivers
     SCII reads, but write hangs
     From: SANDYT       To: DISTO (NR)

I just got a SuperController II, and am having trouble using it under OS9 LII on

my COCO3 (I have a Owlware hard drive, so I have to use the alternate addresses
for the SCII to avoid conflict in $FF7x). The system boots, and I can read with
no trouble, and for sure, no-halt, etc. but when I attempt any write (format,
backup, etc) the drive light comes on but then the process hangs (other
processes continue, but will become stalled if they try for floppies, naturally
  This happens with either the cc3disk.slp or cc3disk.irq module. Other hardware

in the multipak is: Owlware HD (driver does not rely on interrupts), and LRTech
Super-IO Board (uses irqs, but I have the external wire irq hack installed, and
the comm ports and RTC on the superboard work flawlessly with the SCII
installed, regardless of what's going on with the floppies concurrently).  I
have played around to try to correct any BLOB effect, b ut with no effect.  Any
ideas? I don't want to have to revert to my Tandy       FD501 controller.

Sandy

-*-

29323 7-MAY 05:38  Device Drivers
     RE: SCII reads, but write hangs (Re: Msg 29317)
     From: OS9UGPRES    To: SANDYT

Sandy - pretty weird alright. You must have changed the jumper in the SC-II for
the alternate address also, right?

Does this happen right after booting also? I mean, before messing with the
serial ports on the MPI, and so on? (anything which might shut off MPI
interrupts).

What kind of floppy drives do you have? Using same cable as before? Oh... you
said FD501. Hmmm. Should be okay, I think. Old controller still write okay to
drives? thx - kev

-*-

29324 7-MAY 12:05  Device Drivers
     RE: SCII reads, but write hangs (Re: Msg 29323)
     From: SANDYT       To: OS9UGPRES (NR)

Yes, jumper changed appropriately; am using LEVEL2.ALT/cc3disk.irq, and yes it
works as described immediately after booting.  Have 3.5" 80tkDS disk for /d0 and

another for /d1, and a 5.25" 35tkSS (old) disk as /d2. The primary hard disk is
/dd and /h0, also have /h1 and /r0 (pure software). Under CDOS 1.2 (built into
controller), DSKINI 0 works correctly, so I do not suspect a purely harware
error.  (BTW, the 3.5 drives are 0 and 2, and 1 and 3, and the 5.25 drive is
inaccessable under CDOS).

Simply replacing the old controller (and cc3disk) lets everything work the old
halting way.  Cables etc. not touched at all.  I have checked, no hw address
conflicts with any equipment (when using the alternate SCII addresses).

Thanks for thinking about it. Sandy

-*-

End of Thread.

-*-

29327 7-MAY 19:25  Telcom

     From: WB4GCS       To: ALL

Help! I have tried, to no avail to kill oro reduce the RFI coming from my coco3.

It completely wipes out my hf rig, so forget about using it to work hf packet.
There is some noise (tolerable) from the video display, and hard disk when
accessed.  Tthe real killer is when xcom9 is erunning, with either /t2 and/or /
t4 (another aciapak hacked to operate at a different address) running.  The
noise is spread throughout the hf spectrum, and sounds like a keyboard scan or
interrupt polling rate.  In my present temporart y location, the noise even goes

up to VHF so that I can't work packet on my hand-held with an inside antenna,
unless I digipeat through a guy 4 blocks from here. Has anyone successfully
solved this???? I have installed extra shielding inside the coco3, the mpi, and
around all cables.  This made NO difference. Aany ideas would be greatly
appreciated. 73, Jim

-*-

29333 7-MAY 23:20  General Information
     Auto-Follow Mouse
     From: DENNYSKALA   To: ZACKSESSIONS

Zack,

Is there a convenient way to set up the auto-follow mouse *WITHOUT* firing up
Multivue?  I often run programs which require it from shell.  Without writing a
little program to do it, I can't see a convenient way to activate it.  Or am I
missing something obvious (seems like I solved this very problem about six
months ago, but senility fast approaches <grin>).

                           ***** Dennis *****

-*-

29343 8-MAY 18:11  General Information
     RE: Auto-Follow Mouse (Re: Msg 29333)
     From: ZACKSESSIONS To: DENNYSKALA (NR)

I assume you really mean how to you set up the system wide mouse characteristics

like hi-res IF and right joystck port, right?

One way is to do a:

OS9: control -e

(Using the control command from the MV disk) Other that that, you could write a
quickie BASIC09 program which does a SYSCALL to the SS.GIP SetStat function. (In

the Tech Ref, pg 8-147)

Zack

-*-

End of Thread.

-*-

29335 8-MAY 01:41  Utilities
     Scf problem with Gshell+
     From: COCOKIWI     To: ALL

I am having a problem ! I cannot IPATCH the Scf files for The Norm! SCF. or the
Fixed SCF. I have 2.00.01 Lv II ? and get a 'not the correct File' error ! Now I

know ! that mine has not been moded" and KD's SCFfix worked fine ! I cannot
IPATCH either one! According to Docs I need to do these mods to fix another bug!

Any insite into this would help! I noted no other Mods That would explain the
difference!Ipatch I think checks the crc and drops out if it is different!
Anyone had the same problem with setting up Gshell + any help would be a help
regards Dennis <COCOKIWI>


-*-

29336 8-MAY 03:07  General Information
     Help with Equipment and Downloading
     From: KNOT1        To: ALL

Hello, all.  I have a couple of questions I hope to get some help on.

First:  I'm finally going to do some hardware hacking (in particular, Marty's *
CART fix -- have gotten tired of being 90+% thru a long download and having
everything come to a halt!), and was wondering if anyone has any suggestions on
what equipment to get.  Such as type/power of soldering iron and solder, heat
sinks, and any other miscellaneous general equipment.

Second:  I'm using YModem BATCH when downloading from the data bases.  When
there is more than one file in a group, I can't seem to figure out how to tell
Delphi to send more than 1 file at a time, which would be ntce, since I am using

BATCH.

Any help?  Thanks a milloin!

                      -Jamie Wilmoth (KNOT1)-

-*-

29344 8-MAY 18:13  General Information
     RE: Help with Equipment and Downloading (Re: Msg 29336)
     From: ZACKSESSIONS To: KNOT1

Although Delphi supports Ymodem Batch, it doesn't support multiple file
downloading from the libs yet. (Unless the sysop has new news for us!)

Zack

-*-

End of Thread.

-*-

29337 8-MAY 03:21  Telcom
     HELP!!!!!!
     From: CTL56        To: ALL

HELP!!! I need some help with my computer and downloading files. I have changed
attr on the files.  The Main problem I am having is on the .AR files.  When I
type AR -t filename I get a list and then AR prints File not archive or damaged.

ERROR #001 The files appear to work and I am not sure if there is a problem.

I am now using OSterm V2.07 with a Disto SC2 plus a 3 in 1 board and a Radio
Shack DCM-6 Modem (for now) The computer sometimes locks up and drops the
carrier.

 Any suggestions or comments would be nice.

   Thanks



-*-

29345 8-MAY 18:15  Telcom
     RE: HELP!!!!!! (Re: Msg 29337)
     From: ZACKSESSIONS To: CTL56

The error from Ar that you are getting can be ignored. The files are being
de-arced just fine. If you really want to get rid of the error message, even
though it is a moot exercise, you can edit the archive with dEd a diddle with
the file length, chopping off the $1A xmodem padding bytes at the end of it.

Zack

-*-

End of Thread.

-*-

29348 8-MAY 19:34  General Information
     new user
     From: CAROLYNA     To: ALL

I'm brand new to OS-9, so please excuse apparently stupid questions. I'm trying
to make Multi-Vue recognize my 512K as instructed in manual. After I type the
"+3", I always get  "*FAIL*.  My 512 upgrade passes its test so must be good.
What am I doing wrong? Neither manual ever mentions the *FAIL* message, that I
can find. Thanks for any help.

-*-

29355 8-MAY 22:29  General Information
     RE: new user (Re: Msg 29348)
     From: EDDIEKUNS    To: CAROLYNA (NR)

The problem you're probably having is typos on page 1-6 of the MultiVue manual.
Step 4 should be:  type edit /d0/sys/env.file [ENTER]

(ie: not /do/sys/env.file [ENTER])

There are a lot of typo's in the MultiVue manual, unfortunately.

If you have another editor that you are familiar with under OS-9, then use that
editor instead.  What you are doing on page 1-6 of the MultiVue manual is
changing which 'RAM = ' line is commented out.  You want the line saying
'RAM=512' to be uncommented (no '*') and the line saying 'RAM=128' to be either
commented (beginning with a '*') or deleted.

              Eddie

-*-

29391 11-MAY 00:32 General Information
     RE: new user (Re: Msg 29348)
     From: CIZZIJR      To: CAROLYNA (NR)

Carolyna,
 You get the *FAIL* message because you are trying to move three lines
 past the end of the edit buffer.

 Before you type +3 type -* first.  Then type +3 and continue as the manual
 states.  If you would like to find out more infromation about the use of
 edit, check out your Operating System manual under the commands section,
 page 7-1.

 This should get you on your way,
 Carmen Izzi Jr. [CIZZIJR]

-*-

29400 12-MAY 11:31 General Information
     RE: new user (Re: Msg 29348)
     From: NES          To: CAROLYNA (NR)

Look for the env.file located in the SYS directory, use edit command to remove
the * in front of the RAM=512 and remove the RAM=128. Here is my env.file:
RBFDEV=/dd,/d0,/d1
SCFDEV=/p,/t1,/t2
MONTYPE=1
RAM=512
EXEC=/dd/MV/CMDS
PROGRAM=Shell
PARAM=i=/term
REPSTR=3
REPSPD=4
PTRRES=1
PTRSID=1
LFTMRGN=5
LNLEN=70
PGWDTH=80
HDRSIZ=5
TRLSIZ=5
PGLEN=66
TABSIZ=4
PGPAUS=0
PRPORT=/p
PRNAME=DMP105
PALET0=3,3,3
PALET1=0,0,3
PALET2=0,0,0
PALET3=2,2,2
PALET4=1,1,1
PALET5=2,2,2
PALET6=1,0,0
PALET7=2,0,0
PALET8=3,0,0
PALET9=0,1,0
PALET10=0,2,0
PALET11=0,3,0
PALET12=0,0,1
PALET13=0,0,2
PALET14=0,0,3
PALET15=3,3,3

That should get you full use of the 512k with MV.
Note: RBF=  /dd,/d0,/d1  remove the /d1 if you have only one drive.
also the EXEC=  your exicution directory usely /dd/cmds.
MONTYPE=1 for RGB.
hope this helps
NES

-*-

End of Thread.

-*-

29358 8-MAY 23:40  Programmers Den
     tmode problem
     From: ZACKSESSIONS To: ALL

I can't seem to turn off pause in a window from a program. I have tried using a
SetStt SS.OPT call, and forking a "tmode -pause" call. Neither appear to work.
The problem is apparent when displaying several character strings in a overlay
window. If I have pause turned off prior to running the program, all is fine. If

pause is turned on, the character string display in the overlay window pauses
after displaying 22 strings. Any ideas, guys?

Zack

ps, when pause is turned on and the display pauses after 22 strings being
displayed, hitting BREAK or clicking the mouse makes the program continue.

-*-

29362 9-MAY 01:15  Programmers Den
     RE: tmode problem (Re: Msg 29358)
     From: KNOT1        To: ZACKSESSIONS

I'm not positive that you HAVE to, but did you do a GetStt SS.OPT first, then
the SetStt?  Also did you use path #1 (or whichever the window is opened on)
insted of path #0?  "Tmode" also relies on path #0, so sosething like "tmode -
pause </1" may be needed if path #0 and path #1 are not the same window.

Also, thanks for the info on YMODEM BATCH.

                     -Jamie Wilmoth (KNOT1)-

-*-

29365 9-MAY 18:15  Programmers Den
     RE: tmode problem (Re: Msg 29362)
     From: ZACKSESSIONS To: KNOT1

I did do a GetStt first. Paths 0 and 1 are the same window, but I am doing the
SetStt to path 1. I'll try it to path 0 and see what happens.

You're welcome on the YB info.

Zack

-*-

29366 9-MAY 19:37  Programmers Den
     RE: tmode problem (Re: Msg 29365)
     From: MINIFREAK    To: ZACKSESSIONS

Do you have an overlay open when you do the SetStt SS.Opt call? If so, it "dies"

when you close the overlay. I got bit by this once... took forever to figure
out!!

Randy

-*-

29367 9-MAY 20:20  Programmers Den
     RE: tmode problem (Re: Msg 29366)
     From: ZACKSESSIONS To: MINIFREAK

Yes, the problem manifests itself in an overlay window. I've just figured this
out, and was dialed in to post what I found out. Apparently, you can SetStt the
options to your current window but if you open an overlay window, it inherits
the options data from the "actual" window options area, and not the "active"
options area associated with your current window.

Zack

-*-

End of Thread.

-*-

29359 8-MAY 23:54  Device Drivers
     Eliminator Software
     From: BRUCEISTED   To: ALL

  Just a quick note to announce that I've completed the upload of an ARchive
containing my Eliminator software, plus a manual file.  This includes the
updated DACIA driver that works correctly with RIBBS, for all you RIBBS sysops
out there.  Also included is a new version of ACIAPAK that might (not tested
100%) work well for RIBBS sysops using 6551 ACIAs.
  Bruce


-*-

29364 9-MAY 02:29  Graphics & Music
     Rogue help help help help
     From: WAYNELAIRD   To: ALL

To all, I'm having a problem completing the game rogue. I'm using a backed up
copy from the Original(purchased NOT pirated) and it seems when I reach about
lv8 or 9 the montsers 'clam up' and become "0's". I was wondering if the backed
up copy is at fault, and can only play on the Original. Also I get the graphics
window only in black & white, is THIS normal? third when the problem above with
the monsters comes, I can always find the stairs and get to different levels but

the docs say that there are only 26 levels whereas i find myself getting to
29,30,31 etc. without picking anything(being able to) up. THIS doesn't seem
normal. any help would be great, best -wayne

-*-

29370 9-MAY 23:31  General Information
     EMAIL
     From: MRGOOD       To: ALL

Can anyone tell me how I can send someone an AR'ed file through delphi email?
The help command doesn't have any illuminating information on the subject.

Hugo


-*-

29371 10-MAY 00:54 General Information
     RE: EMAIL (Re: Msg 29370)
     From: RICKADAMS    To: MRGOOD

Yes, you can indeed send someone a binary or .AR file through DELPHI email.  I
do it all the time.

You have to go to your workspace and upload the file there, and then go to email

and say "send filename" instead of just "send" to send it.  (For "filename", of
course, substitute whatever filename you gave it when you uploaded the file.)
You'll be asked who to send it to, and the Subject: line, as usual, and then
it'll send the file instead of asking you to enter a message.

On the other end, the recipient of your message will see a header saying the
message is binary, then some gibberish.  There are various techniques to use at
this point.  What I usually do is just wait till the next prompt, and say
"extract file.ar /noheader". That will file the message in my workspace under
the name "file.ar".

And then I can download the file from my workspace.

There are lots of other ways to do it that are variations on what I just said,
and others will no doubt point those out.  :-)

-*-

29383 10-MAY 19:46 General Information
     RE: EMAIL (Re: Msg 29370)
     From: EDDIEKUNS    To: MRGOOD

First, upload the file to your workspace.  Then, once you're in mail, type:
'send filename' and answer the TO and SUBJECT prompts.  Then, the file is sent!

                Eddie

-*-

29384 10-MAY 19:56 General Information
     RE: EMAIL (Re: Msg 29371)
     From: MRGOOD       To: RICKADAMS

Well thank you very much for your informative reply. I didn't realize it was so
easy to send files as email.

Hugo

-*-

29389 10-MAY 23:00 General Information
     RE: EMAIL (Re: Msg 29384)
     From: ZACKSESSIONS To: MRGOOD (NR)


While it is rather simple to SEND an archive file to someone on Delphi, it isn't

quite as simple to adequately RECEIVE an archive file on Delphi. The recipient
should know that they need to first READ the message, ignore the screen of
gobble-de-gook, and then do an EXT/NOHEADER filename, then exit mail, go to
their workspace and download the file called filename.

Zack

ps, and be sure to download it as a BINARY file!

-*-

End of Thread.

-*-

29378 10-MAY 18:57 General Information
     Pictures Needed
     From: DALEP        To: ALL

Here's a chance to put your picture -- or a friends -- in a history book!

We desperately need pictures of people using CoCo's.  We need to see people --
especially those who have pioneered unusual applications on their own in the far

corners of the world.

We need pictures of CoCo's being used by big corporations to do real work.

Don't forget, everyone loves pictures of children.  If you have a shot of your
son or daughter hard at work -- or play -- on your CoCo let us see it.

We also need pictures of gadgets that people dreamed up and hooked up to their
CoCo.

We need pictures of any gags people may have pulled ... at home or at
Rainbowfests ... or anywhere.  Anything that shows the important part the CoCo
played in American life.

If you have a picture ... funny or serious ... of you with someone famous ...
Kevin Darling, Marty Goodman, Wayne Day, etc.  Give us a chance to print it.

Or maybe, you have a picture of someone famous outside the CoCo community -- a
Mayor, Governor, Congressman, President, Actor, Author, etc. using your CoCo.
We'd love to see it!

Please mail your pictures to our new Kansas address.  If you have any questions
... drop us a note here.  Or, write: Dale and Esther Puckett, 23440 West Highway

54, Goddard, KS 67052 -- we're on the Yellow Brick Road.  Really!

If you want to call: 316-794-2347.  Or, leave us your number here and we'll try
to get back to you.

CoCo: An Affectionate History of the Tandy Color Computer is your book.  We hope

to hear from you soon.

Thanks!

Dale and Esther

-*-

29381 10-MAY 19:03 General Information
     Anecdotes Needed
     From: DALEP        To: ALL

Here's a chance to be remembered in CoCo History!

We desperately need anecdotes and stories about the people who have kept the
Color Computer alive during the past 10 years for CoCo: An Affectionate History
of the Tandy Color Computer.  We would like to hear your story too!

If you remember any funny "CoCo" stories -- or serious stories for that matter
-- please share them with us.  We'll do our best to get them into print.  We
need pictures too.  See the related message in Section 10.

We would like to hear about the people you know who pioneered both usual and
unusal applications for their CoCo.  If you know anyone who has hooked up an
exotic gadget to their CoCo -- please send us a note describing it.

If you know someone who has an anecdote to share, please send us their name,
address and phone number.

If you witnessed any great gags at home or at a Rainbowfests, let us know what
happened.  Anything that shows the effect the CoCo had on American culture
should be recorded in this book.

If you have a story -- funny or serious -- about someone famous ... Kevin
Darling, Marty Goodman, Wayne Day, etc.  Give us a chance to print it.

Please E-Mail (preferred) your stories to us here.  Or, send them snail mail to
our new Kansas address:  Dale and Esther Puckett, 23440 West Highway 54,
Goddard, KS 67052 -- we're on the Yellow Brick Road.  Really!

If you have any questions ... drop us a note here.  If you want to call, the
number at the Emerald Castle is 316-794-2347.  If you leave us your number here,

we'll try to get back to you.

CoCo: An Affectionate History of the Tandy Color Computer is your story.  We
hope to hear from you soon.  Please Hurry!  We must have the first half of the
book turned in to Falsoft by the end of June ... the last half by the end of
July!!!

Thanks!

Dale and Esther

-*-

29388 10-MAY 21:41 General Information
     MPI upgrade
     From: TEDJAEGER    To: ALL

I am trying to get my CoCo III in an AT case and have recently acquired a small
MPI (3124) to help. I have a RS HD interface and Disto mini controller and these

woek fine with my old (large) MPI. However, when I use the same stuff with my
new MPI my hard drive will not come on line. At the moment control would
normally be given over to the HD duringxD boot up, everything halts and the
"boot failure" message appears. The MPI is OK because Sokoban runs in slot 3
where my HD interface is and the system works under disk basic and os9 will even

boot if I use a boot disk without /h0 and cc3hdisk. The new (small) MPI has not
had the satellite upgrade but I am told that it is not needed. My only other
clue is that when I turn on the power to my drives, the drive 2 activity light
comes on continuously until I turn on the power to my CoCo and MPI. This does
not happen with the old MPI in the system (which is upgraded to work with CoCo
III). Any ideas would be greatly appreciated. --TedJaeger

-*-

29395 11-MAY 21:47 Programmers Den
     RE: file size & basic09 (Re: Msg 29394)
     From: ZACKSESSIONS To: THEFERRET

You could try a SYSCALL to a GetStt SS.SIZ call. Check page 8-113 in the Tech
Ref.

Zack

-*-

29405 12-MAY 20:10 Programmers Den
     RE: file size & basic09 (Re: Msg 29395)
     From: THEFERRET    To: ZACKSESSIONS (NR)

Yah.  It was right under my nose.  Should have seen that.  However: I am now
using a I$Readln in place of SS.Siz and something else.  trouble is, it does not

seem to work as advertised!! (It is supposed to read up to the first eor, or
regs.y, whichever comes first.  But it always reads the full regs.y for me. I am

using shell+ Got any ideas?

  Phil

-*-

29407 12-MAY 21:25 Programmers Den
     RE: file size & basic09 (Re: Msg 29405)
     From: GREGL        To: THEFERRET (NR)

Phil,

    What are you using in the Y register and, more importantly, have you reset
EOR to zero or some other character? The I$ReadLn will read a maximum of
Y-number of characters from the specified path and quits reading when it has
reached Y-number of characters or the EOR character ($0D) has been seen in the
input stream. If you use with the keyboard you'll hear the speaker beep at you
when you reach Y and it will accept no other characters except for ENTER. If
you've redefined EOR then you'll always read Y-numberof characters or until you
reach the specific EOR character defined. EOR=00 means there is no EOR
character.

    -- Greg

-*-

End of Thread.

-*-

29398 11-MAY 22:39 General Information
     In the beginning......
     From: DBEARISTO    To: ALL

I am very new to OS-9, in fact today is the first day I have had it.

What I would like to know, is how to set my disk drive step rate at 6ms and how
to make the other side (it is a double-sided drive) drive 2 under OS-9.

Please remember, I am very very new to OS-9 so you must be very specific. I am
really looking forward to getting to know OS-9!

Thanks, Darryn Bearisto (DBEARISTO)

-*-

29399 12-MAY 01:09 Graphics & Music
     UMusE3
     From: CTL56        To: RAGTIMER (NR)

I love your program UMusE3 and it works great. I can't read music but can enter
scores in from sheet music. I have a question bout it.  I am using a Casio MT-
240 and it works great for all that I have put in, I would like to know if you
know a way to turn on the rhythm section from the program. The information that
I have with the machine say's that I can do so on channel 4 but have been unable

to do so. Since I am new to this, please geve me the information in plain
English as I am not quite sure of all of the MIDI terms.


                               Thanks

-*-

29401 12-MAY 11:36 Applications
     Gravity Studio
     From: NES          To: ALL

Hay, dose anyone have the Gravity Studio? also in there MAY add in rainbow they
left out who to make the check out to. dose anyone know out there.. I would like

to buy a copy of it... NES

-*-

29402 12-MAY 15:53 Programmers Den
     pointers
     From: RBSMITH      To: GREGLAW (NR)

greg
 i need help geting the pixels from a type seven window.
 for example . I have a program i wrote the draws a cube and rotates it in 3d .
the programs runs in
 window seven a none graphics window. and sends its output to window one a type
7 graphics window.
 I would like to get---- the pixels from window one and then do a dump to the
printer. But i need help with the pointer or address to use to get this info.
      thanks rbsmith

-*-

29406 12-MAY 21:18 Programmers Den
     RE: pointers (Re: Msg 29402)
     From: GREGL        To: RBSMITH (NR)

Ray,

    To get what's on the screen you'll need to use a Get/Put Buffer. Turn to
Page 3-18 for the definition of GetBlk. You can use this to copy the contents of

the screen into a Get/Put Buffer. Oh, that's in the Windows section. On page
8-122 is the definition for the SS.MpGPB Get Status call. You can use this call
to map the Get/Put Buffer into your workspace. exit The general gist of such a
program would be as follows:

#include <os9.h>

char *getblock(group, bufnum, start_x, start_y, size_x, size_y)
int        group, bufnum, start_x, start_y, end_x, end_y;
{
        struct registers regs;
        char        buffer[20];

        /* KilBuf - Kill the buffer before using it */
        buffer[0]  = '\x1B';
        buffer[1]  = '\x2A';
        buffer[2]  = (char) (group & 0xFF);
        buffer[3]  = (char) (bufnum & 0xFF);

        /* GetBlk - Get contents of screen into a buffer */
        buffer[4]  = '\x1B';
        buffer[5]  = '\x2C';
        buffer[6]  = (char) (group & 0xFF);
        buffer[7]  = (char) (bufnum & 0xFF);
        buffer[8]  = (char) ((start_x >> 8) & 0xFF);
        buffer[9]  = (char) (start_x & 0xFF);
        buffer[10]  = (char) ((start_y >> 8) & 0xFF);
        buffer[11]  = (char) (start_y & 0xFF);
        buffer[12]  = (char) ((size_x >> 8) & 0xFF);
        buffer[13]  = (char) (size_x & 0xFF);
        buffer[14] = (char) ((size_y >> 8) & 0xFF);
        buffer[15] = (char) (size_y & 0xFF);

        write(1, buffer, 15);

        /* SS.MpGPB - A=path, B=$84, X=Group/Buffer, Y=map(1)/unmap(0) buffer */

        regs.rg_a = 1;
        regs.rg_b = 0x84;
        regs.rb_x = (group * 256) + bufnum;
        regs.rg_y = 1;

        if((_os9(GETSTT, &regs)) == -1)
                return(0);

        /* Return address of buffer - X=address, Y=length in bytes */
        return(regs.rg_x);
}

With this function you pass the group and buffer number of the Get/Put Buffer
you want to use as well as the starting X and Y coordinates and the size of the
block and it will return a pointer to the block or zero if something failed.
Notice that I issued a KilBuf first to deallocate a buffer that might already be

in use. That prevents an error in case the new buffer is larger than the older
one.

    -- Greg

-*-

End of Thread.

-*-

29403 12-MAY 18:56 Programmers Den
     os9gen trouble
     From: NES          To: ALL

Has anyone ever had a disk stop being able to make boot disk from it?? also cant

make a boot disk from the harddrive (burk&burk). I can cobble the disk to make a

boot, but cant make a new boot with added modules.  Is there a size limmit on a
boot?
Here is my new boot I would like to have boot the system:
OS9P2
Init
IOMan
CC3Go
Clock.60hz
RBF.mn
CC3Disk.dr_new
D0_40D.DD
D1_40D.DD
BBFhdisk.dr
SCF.mn
ACIAPAK.dr
SIO.dr
T1.DD
T2.DD
PRINTER.dr
P.DD
CC3IO.dr
VDGINT.IO
WINDINT.IO
TERM_WIN.DT
W.DW
W1.DW
W2.DW
W3.DW
W4.DW
W5.DW
W6.DW
W7.DW
W8.DW
W9.DW
W10.DW
W11.DW
W12.DW
W13.DW
W14.DW
W15.DW
PipeMan.mn
Piper.dr
PIPE.DD
dd/cmds/H0.dd
dd/cmds/DD.dd   /* note this where supposed to be after BBFhdisk.dr */

NES

-*-

29408 12-MAY 23:20 Telcom
     OSTerm
     From: ELM          To: ALL

I'm a newcomer to OS9 and am sort of hobbling along trying to learn the system.

A friend lent me a copy of OSTerm which I did manage to get up and running in a
fashion.  The docs for OSTerm seem pretty skimpy.  Is there some detailed
instruction for its use?

I frequently find myself with a locked up keyboard, and often the drive light
will come on and stay on.

I'd appreciate any help in finding further documentation for this program.

-Len

-*-

29410 12-MAY 23:47 Utilities
     3 1/2"
     From: BANCROFT     To: ALL

I have a 3 1/2" high density drive.  I have switched the jumper to make it work
only as a double density drive.   My device descriptor is set up for SID=2, CYL=

50, DNS=3.  I can format the disk.  I do a DCHEKC and it comes out OK. But when
I store something there, I get a error 219, then the disk is unreadable I keep
getting error 244 from then on until I put in a new disk.


-*-

29413 13-MAY 01:35 General Information
     OS9 via RS-DOS?
     From: BILLBEISSERT To: ALL

I'd like to download a decent terminal program for OS9 using Ymodem under an RS-

DOS system. What steps must be taken to accomplish this task? I have a Coco3
with 512k and would like to get Osterm V 2.0.8 that's here on the SIG. I have
OS9 Level 2, also. I did notice that there are no doc's for Osterm so I assume
that it is menu driven and fairly self-explanatory. Sure would appreciate some
help towards my goal.

Bill

-*-

29415 13-MAY 03:03 General Information
     Music Formats
     From: BRIANWHITE   To: RAGTIMER (NR)

Hi.

You told me (at least, I THINK it was you...) to remind you after the 'fest
about some info dealing with Symphony-12 and other music programs.  Just tell me

how you'd like to perform the transfer and I'll work it out.  Thanx, we (Matthew

and myself) real ly appreciate this!!!

                                                           Brian

-*-

29416 13-MAY 10:40 Telcom
     tel
     From: AEJ          To: ALL

Just a little note... I have been a sysop of a OS9 BBS for a few years now
(PBBS, which has served me fine) and like all COCO users have been on the look
out for anything new. I suggest that any sysops or future systops take a look at

the new BBS program RCIS......very impressive...I have looked at most of the OS9

BBSs and this one is a gem! Home BASE.....(201)967-1061 Mine is (902)539-4473

-*-


FORUM>Reply, Add, Read, "?" or Exit>