From aawolfe at gmail.com  Sun Nov  1 03:02:41 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 1 Nov 2009 03:02:41 -0500
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
Message-ID: <e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>

I am unconvinced of the need for yet another emulator.  MESS already
runs on a wide range of platforms, and more importantly it is open
source.  The effort it would take to invent these wheels again is
massive compared to the effort it would take to simply fix any actual
issues with MESS.  Everyone is welcome to take the code and fix it,
all of the tools needed are free (as in freedom) as well.  How could
an alternate emulator, especially one based on some single commercial
tool, possibly offer more?  What could one do in a new emulator that
cannot be done more easily by improving/extending/fixing MESS?

I never got a response to my query as to what issues or regressions
the OP was talking about.  I don't understand what "fuzz" is.  If
there is a specific problem people are having with MESS, lets hear it.
 I'm more than happy to climb into the source and at least make an
effort to fix it for you.

-Aaron


On Sat, Oct 31, 2009 at 4:05 PM, Fedor Steeman <petrander at gmail.com> wrote:
> Well, to go waaaaaaay back to the orignal question that started this thread:
>
>
> I am not too fond of the MESS emulator, but not so much because I
> experienced problems, but because it's more fuzz than the awesome Vcc
> emulator. A drawback of Vcc is of course that it is Windows only.
>
> So I am all for a new cross-platform emulator and some time ago I even gave
> it a go myself, but had to abandon my plans, because I had gotten way too
> ambitious (if not presumptuous) compared to my skills/insight and available
> time. Also many platforms seem to cumbersome or not fast enough for the kind
> of implementation I envisaged.
>
> Still I would certainly encourage anyone to give it a go, and maybe one day
> I will try myself again. Using SDL would be a good idea for keeping it cross
> platform, but an even better idea would be using BlitzMax:
> http://www.blitzbasic.com/Products/_index_.php
>
> BlitzMax features an easy to grasp, BASIC-like syntax with fast graphics and
> it is even object-oriented! Compilers are available at an affordable price
> for Windows, MacOSX and Linux.
>
> If I ever would try to write an emulator I would probably use BlitzMax.
>
> Just my 5 cents...
>
> Fedor
>
>
> 2009/9/6 TP Reitzel <tpreitzel at hotmail.com>
>
>>
>> We need an emulator to replace MESS. For almost a decade, MESS has had
>> recurring problems with regressions, etc. Personally, I just can't deal with
>> it much anymore. Various toolkits are employed which just worsens the
>> situation with regressions. Frankly, I have a lot of venting to do about
>> MESS, but I'll hold my tongue. I've stated as much as the background for our
>> need of ?an independent project. Although Vcc is likely still active, it
>> hasn't been updated in awhile. We need a portable, e.g. SDL, fully
>> implemented emulator for all CoCos whether it simply emulates historical
>> machines (CoCo 1-3) or contains newer features as well...
>>
>>
>> _________________________________________________________________
>> Hotmail? is up to 70% faster. Now good news travels really fast.
>>
>> http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From petrander at gmail.com  Sun Nov  1 05:46:37 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Sun, 1 Nov 2009 11:46:37 +0100
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
Message-ID: <dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>

You are right, Aaron, there is no real need for a new emulator, especially
with all the excellent emulators already around.

But it is often not just needs that drive development of new stuff. Like
with many projects, people start out on some endeavour just to for the fun
and challenge of it; to see if they can do it and in the special way they
envisaged. I think this is what inspired Vcc and Mocha and other innovations
for the CoCo. So despite the efforts it would take, it would be quite a
rewarding experience, from which a lot can be learned!

Sure, people could contribute to the MESS project just as much. It is,
however, written in C, and that is not always accessible for everyone, and
besides that, it is not object-oriented. That is why I am hinting at
BlitzMax which is powerful, easy and object-oriented. That it is a
commercial product is besides the point: Any project developed with it can
be open source.

I think MESS is a fine emulator, but it is more of a fuzz. For MESS you
would need the ROM files, you would have to find the CoCo in a huge list of
other computers, inevitably, because it is not geared for just the CoCo,
etc. etc. Vcc is neat, compared to that, because it is just click-and-go! I
admit it is not a lot of fuzz, so don't read too much in it. Still, I find
myself using Vcc most of the time.

Don't get me wrong, I really do appreciate the efforts put into this and any
project for the CoCo by anyone!

Cheers,
Fedor


2009/11/1 Aaron Wolfe <aawolfe at gmail.com>

> I am unconvinced of the need for yet another emulator.  MESS already
> runs on a wide range of platforms, and more importantly it is open
> source.  The effort it would take to invent these wheels again is
> massive compared to the effort it would take to simply fix any actual
> issues with MESS.  Everyone is welcome to take the code and fix it,
> all of the tools needed are free (as in freedom) as well.  How could
> an alternate emulator, especially one based on some single commercial
> tool, possibly offer more?  What could one do in a new emulator that
> cannot be done more easily by improving/extending/fixing MESS?
>
> I never got a response to my query as to what issues or regressions
> the OP was talking about.  I don't understand what "fuzz" is.  If
> there is a specific problem people are having with MESS, lets hear it.
>  I'm more than happy to climb into the source and at least make an
> effort to fix it for you.
>
> -Aaron
>
>
> On Sat, Oct 31, 2009 at 4:05 PM, Fedor Steeman <petrander at gmail.com>
> wrote:
> > Well, to go waaaaaaay back to the orignal question that started this
> thread:
> >
> >
> > I am not too fond of the MESS emulator, but not so much because I
> > experienced problems, but because it's more fuzz than the awesome Vcc
> > emulator. A drawback of Vcc is of course that it is Windows only.
> >
> > So I am all for a new cross-platform emulator and some time ago I even
> gave
> > it a go myself, but had to abandon my plans, because I had gotten way too
> > ambitious (if not presumptuous) compared to my skills/insight and
> available
> > time. Also many platforms seem to cumbersome or not fast enough for the
> kind
> > of implementation I envisaged.
> >
> > Still I would certainly encourage anyone to give it a go, and maybe one
> day
> > I will try myself again. Using SDL would be a good idea for keeping it
> cross
> > platform, but an even better idea would be using BlitzMax:
> > http://www.blitzbasic.com/Products/_index_.php
> >
> > BlitzMax features an easy to grasp, BASIC-like syntax with fast graphics
> and
> > it is even object-oriented! Compilers are available at an affordable
> price
> > for Windows, MacOSX and Linux.
> >
> > If I ever would try to write an emulator I would probably use BlitzMax.
> >
> > Just my 5 cents...
> >
> > Fedor
> >
> >
> > 2009/9/6 TP Reitzel <tpreitzel at hotmail.com>
> >
> >>
> >> We need an emulator to replace MESS. For almost a decade, MESS has had
> >> recurring problems with regressions, etc. Personally, I just can't deal
> with
> >> it much anymore. Various toolkits are employed which just worsens the
> >> situation with regressions. Frankly, I have a lot of venting to do about
> >> MESS, but I'll hold my tongue. I've stated as much as the background for
> our
> >> need of  an independent project. Although Vcc is likely still active, it
> >> hasn't been updated in awhile. We need a portable, e.g. SDL, fully
> >> implemented emulator for all CoCos whether it simply emulates historical
> >> machines (CoCo 1-3) or contains newer features as well...
> >>
> >>
> >> _________________________________________________________________
> >> Hotmail? is up to 70% faster. Now good news travels really fast.
> >>
> >>
> http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009
> >>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> >>
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From msmcdoug at iinet.net.au  Sun Nov  1 07:12:59 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Sun, 01 Nov 2009 23:12:59 +1100
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
Message-ID: <4AED7B4B.3010904@iinet.net.au>

Fedor Steeman wrote:

> besides that, it is not object-oriented. That is why I am hinting at
> BlitzMax which is powerful, easy and object-oriented. 

What is the big attraction to object-oriented? Like any other methodology, 
it has its place and is more suited to some problems than others. In fact, 
I'd even venture to declare that OO is _not_ suitable, or at the very least 
not much of an advantage, to a single-platform (eg Coco) emulator design.

Those that sprout the view that OO is the be-all-and-end-all to programming 
solutions have, IMHO, limited experience in real world problems (as in, 
limited _range_ of experience, not necessarily limited (time) programming 
experience) and/or limited understanding of when and how to best incorporate 
OO design principles. Yes, you can solve any problem with OO languages if 
you really desire, but it's not always the best solution. And I've seen some 
really _bad_ and really _pointless_ "OO programs" in the real world.

And I don't mean to insinuate that you yourself fall into the above category.

If the objective is fun and self challenge - by all means knock yourself 
out! You can't have too many Coco emulators after all! ;)

That aside, I do actually agree with your "fuzz" comment. I'm a very 
occasional Coco emulator user and I do find myself having to relearn how to 
use MESS each time I need to crank up an emulator. However, at the end of 
the day, MESS still suits my own purposes (primarily development) and it is 
my emulator of choice.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From asa.rand at yahoo.com  Sun Nov  1 13:38:30 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sun, 1 Nov 2009 10:38:30 -0800 (PST)
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <4AED7B4B.3010904@iinet.net.au>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
	<4AED7B4B.3010904@iinet.net.au>
Message-ID: <599259.65369.qm@web53702.mail.re2.yahoo.com>

I have been using MESS since I started running an emulator. I tried Vcc, but it wouldn't run on my laptop. It didn't have a "Windows" version that I could see. MESS has both a Windows version (messui.exe) and a 16-bit (I think, mess.exe) version. The 16-bit version won't run on my laptop either. I don't know what all of the differences are, since I'm not that familiar with C or C++. All I know is MESS works. The only real problems I have with it are:

1. My laptop gets very hot when I am running MESS.
2. I don't like having to press the Windows key to get back to the desktop. I would much rather be able to have my mouse function always available just like in every other app I run. BTW, I am running MESS in a window. I like having the TextPad window visible when I'm testing Basic09 code.
3. All of my other apps run jerkily while MESS is running. As an example, when I am in TextPad, and I want to move the cursor right 8 characters, I press the right arrow key eight times. Normally, the cursor whizzes over to the spot I want (or past it if I get happy with the arrow key). Running MESS, I have to stop pressing the arrow key to see where the cursor will end up when it catches up.

Just my thoughts. Overall I am happy with MESS. In the Windows version, the highliter for the computer to emulate stays on the CoCo3, since I don't emulate anything else. Makes it much easier to start emulating when all I have to do is double click the highlited entry.

Wayne



________________________________
From: Mark McDougall <msmcdoug at iinet.net.au>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sun, November 1, 2009 4:12:59 AM
Subject: Re: [Coco] Emulator - back to the thread's original question

Fedor Steeman wrote:

> besides that, it is not object-oriented. That is why I am hinting at
> BlitzMax which is powerful, easy and object-oriented. 

What is the big attraction to object-oriented? Like any other methodology, it has its place and is more suited to some problems than others. In fact, I'd even venture to declare that OO is _not_ suitable, or at the very least not much of an advantage, to a single-platform (eg Coco) emulator design.

Those that sprout the view that OO is the be-all-and-end-all to programming solutions have, IMHO, limited experience in real world problems (as in, limited _range_ of experience, not necessarily limited (time) programming experience) and/or limited understanding of when and how to best incorporate OO design principles. Yes, you can solve any problem with OO languages if you really desire, but it's not always the best solution. And I've seen some really _bad_ and really _pointless_ "OO programs" in the real world.

And I don't mean to insinuate that you yourself fall into the above category.

If the objective is fun and self challenge - by all means knock yourself out! You can't have too many Coco emulators after all! ;)

That aside, I do actually agree with your "fuzz" comment. I'm a very occasional Coco emulator user and I do find myself having to relearn how to use MESS each time I need to crank up an emulator. However, at the end of the day, MESS still suits my own purposes (primarily development) and it is my emulator of choice.

Regards,

-- |              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From aawolfe at gmail.com  Sun Nov  1 14:02:18 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 1 Nov 2009 14:02:18 -0500
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <599259.65369.qm@web53702.mail.re2.yahoo.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
	<4AED7B4B.3010904@iinet.net.au>
	<599259.65369.qm@web53702.mail.re2.yahoo.com>
Message-ID: <e44ad6640911011102p57aa5e8dm8abb58f19f480363@mail.gmail.com>

Some of the issues you have are more easily fixed with a better laptop
than with code :)
However, you can lower the amount of CPU time MESS uses with the
"Throttle" setting in the Display settings area (seems a strange place
for it, everything else there is for changing graphics options).  This
might help with both your heat problem and the laggy cursor in other
apps.  You can also disable mouse input on the Controllers tab, I
think this will fix your mouse cursor issue.
hope that helps
-Aaron



On Sun, Nov 1, 2009 at 1:38 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> I have been using MESS since I started running an emulator. I tried Vcc, but it wouldn't run on my laptop. It didn't have a "Windows" version that I could see. MESS has both a Windows version (messui.exe) and a 16-bit (I think, mess.exe) version. The 16-bit version won't run on my laptop either. I don't know what all of the differences are, since I'm not that familiar with C or C++. All I know is MESS works. The only real problems I have with it are:
>
> 1. My laptop gets very hot when I am running MESS.
> 2. I don't like having to press the Windows key to get back to the desktop. I would much rather be able to have my mouse function always available just like in every other app I run. BTW, I am running MESS in a window. I like having the TextPad window visible when I'm testing Basic09 code.
> 3. All of my other apps run jerkily while MESS is running. As an example, when I am in TextPad, and I want to move the cursor right 8 characters, I press the right arrow key eight times. Normally, the cursor whizzes over to the spot I want (or past it if I get happy with the arrow key). Running MESS, I have to stop pressing the arrow key to see where the cursor will end up when it catches up.
>
> Just my thoughts. Overall I am happy with MESS. In the Windows version, the highliter for the computer to emulate stays on the CoCo3, since I don't emulate anything else. Makes it much easier to start emulating when all I have to do is double click the highlited entry.
>
> Wayne
>
>
>
> ________________________________
> From: Mark McDougall <msmcdoug at iinet.net.au>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, November 1, 2009 4:12:59 AM
> Subject: Re: [Coco] Emulator - back to the thread's original question
>
> Fedor Steeman wrote:
>
>> besides that, it is not object-oriented. That is why I am hinting at
>> BlitzMax which is powerful, easy and object-oriented.
>
> What is the big attraction to object-oriented? Like any other methodology, it has its place and is more suited to some problems than others. In fact, I'd even venture to declare that OO is _not_ suitable, or at the very least not much of an advantage, to a single-platform (eg Coco) emulator design.
>
> Those that sprout the view that OO is the be-all-and-end-all to programming solutions have, IMHO, limited experience in real world problems (as in, limited _range_ of experience, not necessarily limited (time) programming experience) and/or limited understanding of when and how to best incorporate OO design principles. Yes, you can solve any problem with OO languages if you really desire, but it's not always the best solution. And I've seen some really _bad_ and really _pointless_ "OO programs" in the real world.
>
> And I don't mean to insinuate that you yourself fall into the above category.
>
> If the objective is fun and self challenge - by all means knock yourself out! You can't have too many Coco emulators after all! ;)
>
> That aside, I do actually agree with your "fuzz" comment. I'm a very occasional Coco emulator user and I do find myself having to relearn how to use MESS each time I need to crank up an emulator. However, at the end of the day, MESS still suits my own purposes (primarily development) and it is my emulator of choice.
>
> Regards,
>
> -- | ? ? ? ? ? ? ?Mark McDougall ? ? ? ? ? ? ? ?| "Electrical Engineers do it
> | ?<http://members.iinet.net.au/~msmcdoug> ? | ? with less resistance!"
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Sun Nov  1 13:56:04 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 1 Nov 2009 13:56:04 -0500
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
Message-ID: <e44ad6640911011056s7c5c6787u64a877c8b3de2839@mail.gmail.com>

Hi,

I think it would be a mistake to base any project intended for public
use on a single commercial solution, even a "standard" like visual
studio and friends, much more so one from a small company like
BlitzMax.

What happens when they go out of business, or don't feel like fixing a
critical bug, or supporting a new platform?  The coco is a long term
interest for those of us still playing with them, we aren't going to
stop caring if the emulator works in 10, 20 or even 50 years (If I
live that long :).  That is why truly free platforms are preferable.
When you have access to the source for all components of your project,
even if you never need it, you have no worries about these types of
things.  A program written in a standard language with open tools will
always, always be supportable and maintainable.  No commercial system
can make the same claim.

C is a standard language available on practically every system known
to man, with hundreds of compilers from multiple vendors, not to
mention the excellent and free gcc.
C is taught in every CS program I've heard of at least.  Some C
experience is generally considered a prerequisite for any serious
programmer, professional or hobbyist.

How could C possibly be less accessible for the masses than a niche
proprietary language that isn't based on any public standard at all?
I just don't follow your logic.

As Mr. McDougall pointed out, object oriented programming is neither a
requirement nor an asset to an emulator project.  It is quite simple
to implement oo behavior in C if there is any advantage to it for some
part of the project.

If your goal is to have some fun, of course do what is most fun to
you.  If you're trying to provide something of use to the community, I
think you're heading in the wrong direction.

-Aaron

On Sun, Nov 1, 2009 at 5:46 AM, Fedor Steeman <petrander at gmail.com> wrote:
> You are right, Aaron, there is no real need for a new emulator, especially
> with all the excellent emulators already around.
>
> But it is often not just needs that drive development of new stuff. Like
> with many projects, people start out on some endeavour just to for the fun
> and challenge of it; to see if they can do it and in the special way they
> envisaged. I think this is what inspired Vcc and Mocha and other innovations
> for the CoCo. So despite the efforts it would take, it would be quite a
> rewarding experience, from which a lot can be learned!
>
> Sure, people could contribute to the MESS project just as much. It is,
> however, written in C, and that is not always accessible for everyone, and
> besides that, it is not object-oriented. That is why I am hinting at
> BlitzMax which is powerful, easy and object-oriented. That it is a
> commercial product is besides the point: Any project developed with it can
> be open source.
>
> I think MESS is a fine emulator, but it is more of a fuzz. For MESS you
> would need the ROM files, you would have to find the CoCo in a huge list of
> other computers, inevitably, because it is not geared for just the CoCo,
> etc. etc. Vcc is neat, compared to that, because it is just click-and-go! I
> admit it is not a lot of fuzz, so don't read too much in it. Still, I find
> myself using Vcc most of the time.
>
> Don't get me wrong, I really do appreciate the efforts put into this and any
> project for the CoCo by anyone!
>
> Cheers,
> Fedor
>
>
> 2009/11/1 Aaron Wolfe <aawolfe at gmail.com>
>
>> I am unconvinced of the need for yet another emulator. ?MESS already
>> runs on a wide range of platforms, and more importantly it is open
>> source. ?The effort it would take to invent these wheels again is
>> massive compared to the effort it would take to simply fix any actual
>> issues with MESS. ?Everyone is welcome to take the code and fix it,
>> all of the tools needed are free (as in freedom) as well. ?How could
>> an alternate emulator, especially one based on some single commercial
>> tool, possibly offer more? ?What could one do in a new emulator that
>> cannot be done more easily by improving/extending/fixing MESS?
>>
>> I never got a response to my query as to what issues or regressions
>> the OP was talking about. ?I don't understand what "fuzz" is. ?If
>> there is a specific problem people are having with MESS, lets hear it.
>> ?I'm more than happy to climb into the source and at least make an
>> effort to fix it for you.
>>
>> -Aaron
>>
>>
>> On Sat, Oct 31, 2009 at 4:05 PM, Fedor Steeman <petrander at gmail.com>
>> wrote:
>> > Well, to go waaaaaaay back to the orignal question that started this
>> thread:
>> >
>> >
>> > I am not too fond of the MESS emulator, but not so much because I
>> > experienced problems, but because it's more fuzz than the awesome Vcc
>> > emulator. A drawback of Vcc is of course that it is Windows only.
>> >
>> > So I am all for a new cross-platform emulator and some time ago I even
>> gave
>> > it a go myself, but had to abandon my plans, because I had gotten way too
>> > ambitious (if not presumptuous) compared to my skills/insight and
>> available
>> > time. Also many platforms seem to cumbersome or not fast enough for the
>> kind
>> > of implementation I envisaged.
>> >
>> > Still I would certainly encourage anyone to give it a go, and maybe one
>> day
>> > I will try myself again. Using SDL would be a good idea for keeping it
>> cross
>> > platform, but an even better idea would be using BlitzMax:
>> > http://www.blitzbasic.com/Products/_index_.php
>> >
>> > BlitzMax features an easy to grasp, BASIC-like syntax with fast graphics
>> and
>> > it is even object-oriented! Compilers are available at an affordable
>> price
>> > for Windows, MacOSX and Linux.
>> >
>> > If I ever would try to write an emulator I would probably use BlitzMax.
>> >
>> > Just my 5 cents...
>> >
>> > Fedor
>> >
>> >
>> > 2009/9/6 TP Reitzel <tpreitzel at hotmail.com>
>> >
>> >>
>> >> We need an emulator to replace MESS. For almost a decade, MESS has had
>> >> recurring problems with regressions, etc. Personally, I just can't deal
>> with
>> >> it much anymore. Various toolkits are employed which just worsens the
>> >> situation with regressions. Frankly, I have a lot of venting to do about
>> >> MESS, but I'll hold my tongue. I've stated as much as the background for
>> our
>> >> need of ?an independent project. Although Vcc is likely still active, it
>> >> hasn't been updated in awhile. We need a portable, e.g. SDL, fully
>> >> implemented emulator for all CoCos whether it simply emulates historical
>> >> machines (CoCo 1-3) or contains newer features as well...
>> >>
>> >>
>> >> _________________________________________________________________
>> >> Hotmail? is up to 70% faster. Now good news travels really fast.
>> >>
>> >>
>> http://windowslive.com/online/hotmail?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_faster:082009
>> >>
>> >> --
>> >> Coco mailing list
>> >> Coco at maltedmedia.com
>> >> http://five.pairlist.net/mailman/listinfo/coco
>> >>
>> >
>> > --
>> > Coco mailing list
>> > Coco at maltedmedia.com
>> > http://five.pairlist.net/mailman/listinfo/coco
>> >
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Sun Nov  1 14:13:50 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 1 Nov 2009 14:13:50 -0500
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <599259.65369.qm@web53702.mail.re2.yahoo.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>
	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>
	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>
	<4AED7B4B.3010904@iinet.net.au>
	<599259.65369.qm@web53702.mail.re2.yahoo.com>
Message-ID: <e44ad6640911011113x701d1bc5gf436517ceb3f7bf1@mail.gmail.com>

VCC is a 32 bit Windows application, at least the current version is.
It should work on any 32 bit windows with direct X (2000, xp, vista,
etc)  It even runs fine on my Windows 7 machine with no special
configuration.

On Sun, Nov 1, 2009 at 1:38 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> I have been using MESS since I started running an emulator. I tried Vcc, but it wouldn't run on my laptop. It didn't have a "Windows" version that I could see. MESS has both a Windows version (messui.exe) and a 16-bit (I think, mess.exe) version. The 16-bit version won't run on my laptop either. I don't know what all of the differences are, since I'm not that familiar with C or C++. All I know is MESS works. The only real problems I have with it are:
>
> 1. My laptop gets very hot when I am running MESS.
> 2. I don't like having to press the Windows key to get back to the desktop. I would much rather be able to have my mouse function always available just like in every other app I run. BTW, I am running MESS in a window. I like having the TextPad window visible when I'm testing Basic09 code.
> 3. All of my other apps run jerkily while MESS is running. As an example, when I am in TextPad, and I want to move the cursor right 8 characters, I press the right arrow key eight times. Normally, the cursor whizzes over to the spot I want (or past it if I get happy with the arrow key). Running MESS, I have to stop pressing the arrow key to see where the cursor will end up when it catches up.
>
> Just my thoughts. Overall I am happy with MESS. In the Windows version, the highliter for the computer to emulate stays on the CoCo3, since I don't emulate anything else. Makes it much easier to start emulating when all I have to do is double click the highlited entry.
>
> Wayne
>
>
>
> ________________________________
> From: Mark McDougall <msmcdoug at iinet.net.au>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, November 1, 2009 4:12:59 AM
> Subject: Re: [Coco] Emulator - back to the thread's original question
>
> Fedor Steeman wrote:
>
>> besides that, it is not object-oriented. That is why I am hinting at
>> BlitzMax which is powerful, easy and object-oriented.
>
> What is the big attraction to object-oriented? Like any other methodology, it has its place and is more suited to some problems than others. In fact, I'd even venture to declare that OO is _not_ suitable, or at the very least not much of an advantage, to a single-platform (eg Coco) emulator design.
>
> Those that sprout the view that OO is the be-all-and-end-all to programming solutions have, IMHO, limited experience in real world problems (as in, limited _range_ of experience, not necessarily limited (time) programming experience) and/or limited understanding of when and how to best incorporate OO design principles. Yes, you can solve any problem with OO languages if you really desire, but it's not always the best solution. And I've seen some really _bad_ and really _pointless_ "OO programs" in the real world.
>
> And I don't mean to insinuate that you yourself fall into the above category.
>
> If the objective is fun and self challenge - by all means knock yourself out! You can't have too many Coco emulators after all! ;)
>
> That aside, I do actually agree with your "fuzz" comment. I'm a very occasional Coco emulator user and I do find myself having to relearn how to use MESS each time I need to crank up an emulator. However, at the end of the day, MESS still suits my own purposes (primarily development) and it is my emulator of choice.
>
> Regards,
>
> -- | ? ? ? ? ? ? ?Mark McDougall ? ? ? ? ? ? ? ?| "Electrical Engineers do it
> | ?<http://members.iinet.net.au/~msmcdoug> ? | ? with less resistance!"
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From flexser at fiu.edu  Sun Nov  1 14:32:27 2009
From: flexser at fiu.edu (Arthur Flexser)
Date: Sun, 1 Nov 2009 14:32:27 -0500
Subject: [Coco] Strange.... two 40 track disks on one 80 track disk?
In-Reply-To: <4AECE36F.4060106@dls.net>
References: <dcc956220910311350r58515888ta49f1a959706f705@mail.gmail.com>
	<4AECE36F.4060106@dls.net>
Message-ID: <dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>

Of course, if his drives are single-sided, no amount of poking will let him
access the back!

Art
On Sat, Oct 31, 2009 at 8:25 PM, Christopher Hawks <chawks at dls.net> wrote:

> Fedor Steeman said the following on 10/31/2009 03:50 PM:
>
> Hi,
>>
>> Some time ago I acquired this huge collection of diskettes that were part
>> of
>> a user group's CoCo software library. A lot of these are backups of
>> backups
>> so there is bound to be a lot of stuff I will be able to recover.
>>
>> There are a large number of diskettes that seem to contain a backup of two
>> 40 tracks diskettes on one side of an assumed 80 track diskette.
>>
>> However, I can only access the first diskette of each of these backup
>> floppies. I know because some of them have their contents listed on the
>> envelope (or whatever you called the paper bag the diskette is in).
>>
>> I have a drive that can be switched from 80 to 40 tracks but that made no
>> difference.
>>
>> Is there some way in HDB DOS that I am using (or RSDOS for that matter)
>> that
>> would enable access to the other 40 tracks and thus the other diskette
>> backup?
>>
>
> Fedor:
>
>        It may be that the other tracks are on the other side of the disk
> (not as in a flippy).
>
>        On a Coco 3 (or a 1 or 2 in ram) with DECB 2.1 (1.1), POKE &HD89F,
> &H40 will make drive 2 the backside of drive 0. Likewise POKE &HD8A0,&H41
> will make drive 3 the back of drive 1. There a 4 memory locations that are
> the drive mask (&HD89D - &HD8A0) the relevant bits are:
> bit 0 - drive select 0 (&H01)
> bit 1 - drive select 1 (&H02)
> bit 2 - drive select 2 (&H04)
> bit 7 - side select    (&H40)
>
>        These can be manipulated to access any side of any (physical) drive
> as any drive number.
>
> --
> Christopher R. Hawks
> HAWKSoft
> ---------------------------------------------------------
> Never meddle in the affairs of NT. It is slow to boot and quick to crash.
>        -- Stephen Harris
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From petrander at gmail.com  Sun Nov  1 15:02:38 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Sun, 1 Nov 2009 21:02:38 +0100
Subject: [Coco] Strange.... two 40 track disks on one 80 track disk?
In-Reply-To: <dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>
References: <dcc956220910311350r58515888ta49f1a959706f705@mail.gmail.com>
	<4AECE36F.4060106@dls.net>
	<dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>
Message-ID: <dcc956220911011202r72d8ad14l92ee09ada7e2e469@mail.gmail.com>

Hi all,

Thanks for all the responses.

I am quite sure these disks are single-sided and that they came from a setup
that could use and access 80 track disks. The collection of stuff (including
the diskettes) I inherited is quite extensive and were used by a highly
skilled CoCo user. There are drives that are cleared marked as switchable to
80 tracks, there are diskettes clearly marked as being 80 tracks. Heck,
there are even disk controllers with a 40/80 tracks switch (?). I tried
those but that did not work either.

I am quite sure there was some trick applied when he backed up the diskettes
two at a time, but I would not know what. As suggested, I will try looking
through the stuff to see if there was any hardware or software involved. I
will also think about all the interesting suggestions you guys made so far.

Most of the diskettes are RSDOS BTW.

/Fedor

2009/11/1 Arthur Flexser <flexser at fiu.edu>

> Of course, if his drives are single-sided, no amount of poking will let him
> access the back!
>
> Art
> On Sat, Oct 31, 2009 at 8:25 PM, Christopher Hawks <chawks at dls.net> wrote:
>
> > Fedor Steeman said the following on 10/31/2009 03:50 PM:
> >
> > Hi,
> >>
> >> Some time ago I acquired this huge collection of diskettes that were
> part
> >> of
> >> a user group's CoCo software library. A lot of these are backups of
> >> backups
> >> so there is bound to be a lot of stuff I will be able to recover.
> >>
> >> There are a large number of diskettes that seem to contain a backup of
> two
> >> 40 tracks diskettes on one side of an assumed 80 track diskette.
> >>
> >> However, I can only access the first diskette of each of these backup
> >> floppies. I know because some of them have their contents listed on the
> >> envelope (or whatever you called the paper bag the diskette is in).
> >>
> >> I have a drive that can be switched from 80 to 40 tracks but that made
> no
> >> difference.
> >>
> >> Is there some way in HDB DOS that I am using (or RSDOS for that matter)
> >> that
> >> would enable access to the other 40 tracks and thus the other diskette
> >> backup?
> >>
> >
> > Fedor:
> >
> >        It may be that the other tracks are on the other side of the disk
> > (not as in a flippy).
> >
> >        On a Coco 3 (or a 1 or 2 in ram) with DECB 2.1 (1.1), POKE &HD89F,
> > &H40 will make drive 2 the backside of drive 0. Likewise POKE &HD8A0,&H41
> > will make drive 3 the back of drive 1. There a 4 memory locations that
> are
> > the drive mask (&HD89D - &HD8A0) the relevant bits are:
> > bit 0 - drive select 0 (&H01)
> > bit 1 - drive select 1 (&H02)
> > bit 2 - drive select 2 (&H04)
> > bit 7 - side select    (&H40)
> >
> >        These can be manipulated to access any side of any (physical)
> drive
> > as any drive number.
> >
> > --
> > Christopher R. Hawks
> > HAWKSoft
> > ---------------------------------------------------------
> > Never meddle in the affairs of NT. It is slow to boot and quick to crash.
> >        -- Stephen Harris
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From brucewcalkins at charter.net  Sun Nov  1 15:23:51 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Sun, 1 Nov 2009 15:23:51 -0500
Subject: [Coco] Strange.... two 40 track disks on one 80 track disk?
References: <dcc956220910311350r58515888ta49f1a959706f705@mail.gmail.com><4AECE36F.4060106@dls.net><dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>
	<dcc956220911011202r72d8ad14l92ee09ada7e2e469@mail.gmail.com>
Message-ID: <841D2FBA579B4F458F506AB6E541C0B1@speedy>

There is a way to run 80 track drives in RS-Basic.  Unfortunately if you try 
to run them on a 36 or 40 track system they directory gets scrambled.


Bruce W.

======================================================


----- Original Message ----- 
From: "Fedor Steeman"


> Hi all,
>
> Thanks for all the responses.
>
> I am quite sure these disks are single-sided and that they came from a 
> setup
> that could use and access 80 track disks. The collection of stuff 
> (including
> the diskettes) I inherited is quite extensive and were used by a highly
> skilled CoCo user. There are drives that are cleared marked as switchable 
> to
> 80 tracks, there are diskettes clearly marked as being 80 tracks. Heck,
> there are even disk controllers with a 40/80 tracks switch (?). I tried
> those but that did not work either.
>
> I am quite sure there was some trick applied when he backed up the 
> diskettes
> two at a time, but I would not know what. As suggested, I will try looking
> through the stuff to see if there was any hardware or software involved. I
> will also think about all the interesting suggestions you guys made so 
> far.
>
> Most of the diskettes are RSDOS BTW.
>
> /Fedor 



From msmcdoug at iinet.net.au  Sun Nov  1 16:28:36 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Mon, 02 Nov 2009 08:28:36 +1100
Subject: [Coco] Emulator - back to the thread's original question
In-Reply-To: <599259.65369.qm@web53702.mail.re2.yahoo.com>
References: <dcc956220910311405pcca64e2od7ec02d4c8f89196@mail.gmail.com>	<e44ad6640911010102h3fb09f04k2eb3caa1cf01fbcb@mail.gmail.com>	<dcc956220911010246q332b8052l84983e10f3e3ac95@mail.gmail.com>	<4AED7B4B.3010904@iinet.net.au>
	<599259.65369.qm@web53702.mail.re2.yahoo.com>
Message-ID: <4AEDFD84.7060409@iinet.net.au>

Wayne Campbell wrote:

> MESS has both a Windows version (messui.exe) and a 16-bit (I
> think, mess.exe) version. 

It has been many, many years since a 16-bit application was ever released on 
an Intel platform. In fact, you'd probably have to go back to Visual C++ 
v2.0 if you wanted to write a 16-bit application, and then you'd have 
compatability problems with modern Windows OSes.

MESS CLI is a 32-bit application. You're confusing CLI (console-mode apps) 
with 16-bit. There's no correlation what-so-ever. I'd even venture to 
suggest it's possible to write a 64-bit console app - though my knowledge of 
64-bit windows is, well, non-existent - so I may be mistaken here.

When you say "it won't run", what exactly happens?

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From t.fadden at cox.net  Sun Nov  1 17:02:59 2009
From: t.fadden at cox.net (Tim Fadden)
Date: Sun, 01 Nov 2009 15:02:59 -0700
Subject: [Coco] Strange.... two 40 track disks on one 80 track disk?
In-Reply-To: <dcc956220911011202r72d8ad14l92ee09ada7e2e469@mail.gmail.com>
References: <dcc956220910311350r58515888ta49f1a959706f705@mail.gmail.com>	<4AECE36F.4060106@dls.net>	<dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>
	<dcc956220911011202r72d8ad14l92ee09ada7e2e469@mail.gmail.com>
Message-ID: <4AEE0593.3060204@cox.net>

Fedor,

I do have a 80trk 5-1/2 inch drive in one coco3 system if you would like 
me to give it a shot.

Tim Fadden

Fedor Steeman wrote:
> Hi all,
>
> Thanks for all the responses.
>
> I am quite sure these disks are single-sided and that they came from a setup
> that could use and access 80 track disks. The collection of stuff (including
> the diskettes) I inherited is quite extensive and were used by a highly
> skilled CoCo user. There are drives that are cleared marked as switchable to
> 80 tracks, there are diskettes clearly marked as being 80 tracks. Heck,
> there are even disk controllers with a 40/80 tracks switch (?). I tried
> those but that did not work either.
>
> I am quite sure there was some trick applied when he backed up the diskettes
> two at a time, but I would not know what. As suggested, I will try looking
> through the stuff to see if there was any hardware or software involved. I
> will also think about all the interesting suggestions you guys made so far.
>
> Most of the diskettes are RSDOS BTW.
>
> /Fedor
>
> 2009/11/1 Arthur Flexser <flexser at fiu.edu>
>
>   
>> Of course, if his drives are single-sided, no amount of poking will let him
>> access the back!
>>
>> Art
>> On Sat, Oct 31, 2009 at 8:25 PM, Christopher Hawks <chawks at dls.net> wrote:
>>
>>     
>>> Fedor Steeman said the following on 10/31/2009 03:50 PM:
>>>
>>> Hi,
>>>       
>>>> Some time ago I acquired this huge collection of diskettes that were
>>>>         
>> part
>>     
>>>> of
>>>> a user group's CoCo software library. A lot of these are backups of
>>>> backups
>>>> so there is bound to be a lot of stuff I will be able to recover.
>>>>
>>>> There are a large number of diskettes that seem to contain a backup of
>>>>         
>> two
>>     
>>>> 40 tracks diskettes on one side of an assumed 80 track diskette.
>>>>
>>>> However, I can only access the first diskette of each of these backup
>>>> floppies. I know because some of them have their contents listed on the
>>>> envelope (or whatever you called the paper bag the diskette is in).
>>>>
>>>> I have a drive that can be switched from 80 to 40 tracks but that made
>>>>         
>> no
>>     
>>>> difference.
>>>>
>>>> Is there some way in HDB DOS that I am using (or RSDOS for that matter)
>>>> that
>>>> would enable access to the other 40 tracks and thus the other diskette
>>>> backup?
>>>>
>>>>         
>>> Fedor:
>>>
>>>        It may be that the other tracks are on the other side of the disk
>>> (not as in a flippy).
>>>
>>>        On a Coco 3 (or a 1 or 2 in ram) with DECB 2.1 (1.1), POKE &HD89F,
>>> &H40 will make drive 2 the backside of drive 0. Likewise POKE &HD8A0,&H41
>>> will make drive 3 the back of drive 1. There a 4 memory locations that
>>>       
>> are
>>     
>>> the drive mask (&HD89D - &HD8A0) the relevant bits are:
>>> bit 0 - drive select 0 (&H01)
>>> bit 1 - drive select 1 (&H02)
>>> bit 2 - drive select 2 (&H04)
>>> bit 7 - side select    (&H40)
>>>
>>>        These can be manipulated to access any side of any (physical)
>>>       
>> drive
>>     
>>> as any drive number.
>>>
>>> --
>>> Christopher R. Hawks
>>> HAWKSoft
>>> ---------------------------------------------------------
>>> Never meddle in the affairs of NT. It is slow to boot and quick to crash.
>>>        -- Stephen Harris
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>       
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>     
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>   



From RJRTTY at aol.com  Sun Nov  1 19:32:10 2009
From: RJRTTY at aol.com (RJRTTY at aol.com)
Date: Sun, 1 Nov 2009 19:32:10 EST
Subject: [Coco] [CoCo] Radioshack disconnect
Message-ID: <d51.5b429328.381f828a@aol.com>

People
 
    I recently went into a local radioshack store and  asked where
she kept the wallwarts.    She looked at me like I had  just
insulted her in a foreign language.   Its getting pathetic
at the shack let me tell ya.....
 
Roy
 


From flexser at fiu.edu  Sun Nov  1 20:55:04 2009
From: flexser at fiu.edu (Arthur Flexser)
Date: Sun, 1 Nov 2009 20:55:04 -0500
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <d51.5b429328.381f828a@aol.com>
References: <d51.5b429328.381f828a@aol.com>
Message-ID: <dbdeb2610911011755j1678442eh6f32cee7c9fb9a27@mail.gmail.com>

Probably thought you wanted directions to Walmart and couldn't pronounce it
right...

Art

On 11/1/09, RJRTTY at aol.com <RJRTTY at aol.com> wrote:
>
> People
>
>     I recently went into a local radioshack store and  asked where
> she kept the wallwarts.    She looked at me like I had  just
> insulted her in a foreign language.   Its getting pathetic
> at the shack let me tell ya.....
>
> Roy
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From devries.bob at gmail.com  Sun Nov  1 21:07:37 2009
From: devries.bob at gmail.com (Bob Devries)
Date: Mon, 2 Nov 2009 12:07:37 +1000
Subject: [Coco] [CoCo] Radioshack disconnect
References: <d51.5b429328.381f828a@aol.com>
Message-ID: <002401ca5b61$427f1320$6501a8c0@aceraspire>

Hi Guys,

That trend has been evident in Australia for some time.

InterTan Australia was taken over by Dick Smith Electronics, which had 
itself been taken over by Woolworths, a large multi-national grocery chain 
(!). Since those take overs happened, both Tandy (AKA Radio-Shack) and Dick 
Smith stores have become "Concept Stores", and the staff knows almost 
nothing about electronics, and stocks no electronics-related parts.

Sigh..... gone are the good old days when I could walk into a store and buy 
a handful of resistors or transistors.

Regards, Bob Devries
Las Pinas City, Philippines

--
Besides a mathematical inclination, an exceptionally good mastery of one's 
native tongue is the most vital asset of a competent programmer.

Edsger W.Dijkstra, 18 June 1975

----- Original Message ----- 
From: <RJRTTY at aol.com>
To: <coco at maltedmedia.com>
Sent: Monday, November 02, 2009 10:32 AM
Subject: [Coco] [CoCo] Radioshack disconnect


> People
>
>    I recently went into a local radioshack store and  asked where
> she kept the wallwarts.    She looked at me like I had  just
> insulted her in a foreign language.   Its getting pathetic
> at the shack let me tell ya.....
>
> Roy
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco 



From msmcdoug at iinet.net.au  Mon Nov  2 00:53:33 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Mon, 02 Nov 2009 16:53:33 +1100
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <002401ca5b61$427f1320$6501a8c0@aceraspire>
References: <d51.5b429328.381f828a@aol.com>
	<002401ca5b61$427f1320$6501a8c0@aceraspire>
Message-ID: <4AEE73DD.7050906@iinet.net.au>

Bob Devries wrote:

> and Dick Smith stores have become "Concept Stores", and the staff knows 
> almost nothing about electronics, and stocks no electronics-related parts.

Not quite true. Only a few weeks ago a went into the local Dick Smith and 
bought a couple of capacitors and a packet of fuses (for a Sord M23 no less!)

Having said that, the aforementioned parts were sitting in a neglected 
corner of the store, in a half-empty, often mis-labelled carousel with 
out-dated price tags (all that was missing was a sign reading "Beware of the 
Leopard"). And I've little doubt that the guy who served me had no 
absolutely idea what I was buying. He was too busy trying to sell a PS3 to 
take much notice of the $6 I was spending.

I think 98% of Dick Smith and Tandy revenue these days come from clueless 
grandparents who for some unfathomable reason think that it's the best place 
to buy little Johnny a Wii for xmas and a cordless phone or inkjet printer 
for themselves.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From petrander at gmail.com  Mon Nov  2 03:21:03 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Mon, 2 Nov 2009 09:21:03 +0100
Subject: [Coco] Strange.... two 40 track disks on one 80 track disk?
In-Reply-To: <4AEE0593.3060204@cox.net>
References: <dcc956220910311350r58515888ta49f1a959706f705@mail.gmail.com>
	<4AECE36F.4060106@dls.net>
	<dbdeb2610911011132s563d98ddy77d3dd7cbcda81bc@mail.gmail.com>
	<dcc956220911011202r72d8ad14l92ee09ada7e2e469@mail.gmail.com>
	<4AEE0593.3060204@cox.net>
Message-ID: <dcc956220911020021l67e9efc5n245a02688e963954@mail.gmail.com>

Hi Tim,

Oh, that would be great. If we exchange snail mail adresses, I could send
you a batch of floppies for you to experiment with.

The main aim for me is saving the content of this huge amount of diskettes.
Once the contents are safely copied onto a modern computer's hard drive, I
would probably toss most diskettes out.

Cheers,
Fedor


2009/11/1 Tim Fadden <t.fadden at cox.net>

> Fedor,
>
> I do have a 80trk 5-1/2 inch drive in one coco3 system if you would like me
> to give it a shot.
>
> Tim Fadden
>
>
> Fedor Steeman wrote:
>
>> Hi all,
>>
>> Thanks for all the responses.
>>
>> I am quite sure these disks are single-sided and that they came from a
>> setup
>> that could use and access 80 track disks. The collection of stuff
>> (including
>> the diskettes) I inherited is quite extensive and were used by a highly
>> skilled CoCo user. There are drives that are cleared marked as switchable
>> to
>> 80 tracks, there are diskettes clearly marked as being 80 tracks. Heck,
>> there are even disk controllers with a 40/80 tracks switch (?). I tried
>> those but that did not work either.
>>
>> I am quite sure there was some trick applied when he backed up the
>> diskettes
>> two at a time, but I would not know what. As suggested, I will try looking
>> through the stuff to see if there was any hardware or software involved. I
>> will also think about all the interesting suggestions you guys made so
>> far.
>>
>> Most of the diskettes are RSDOS BTW.
>>
>> /Fedor
>>
>> 2009/11/1 Arthur Flexser <flexser at fiu.edu>
>>
>>
>>
>>> Of course, if his drives are single-sided, no amount of poking will let
>>> him
>>> access the back!
>>>
>>> Art
>>> On Sat, Oct 31, 2009 at 8:25 PM, Christopher Hawks <chawks at dls.net>
>>> wrote:
>>>
>>>
>>>
>>>> Fedor Steeman said the following on 10/31/2009 03:50 PM:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>> Some time ago I acquired this huge collection of diskettes that were
>>>>>
>>>>>
>>>> part
>>>
>>>
>>>> of
>>>>> a user group's CoCo software library. A lot of these are backups of
>>>>> backups
>>>>> so there is bound to be a lot of stuff I will be able to recover.
>>>>>
>>>>> There are a large number of diskettes that seem to contain a backup of
>>>>>
>>>>>
>>>> two
>>>
>>>
>>>> 40 tracks diskettes on one side of an assumed 80 track diskette.
>>>>>
>>>>> However, I can only access the first diskette of each of these backup
>>>>> floppies. I know because some of them have their contents listed on the
>>>>> envelope (or whatever you called the paper bag the diskette is in).
>>>>>
>>>>> I have a drive that can be switched from 80 to 40 tracks but that made
>>>>>
>>>>>
>>>> no
>>>
>>>
>>>> difference.
>>>>>
>>>>> Is there some way in HDB DOS that I am using (or RSDOS for that matter)
>>>>> that
>>>>> would enable access to the other 40 tracks and thus the other diskette
>>>>> backup?
>>>>>
>>>>>
>>>>>
>>>> Fedor:
>>>>
>>>>       It may be that the other tracks are on the other side of the disk
>>>> (not as in a flippy).
>>>>
>>>>       On a Coco 3 (or a 1 or 2 in ram) with DECB 2.1 (1.1), POKE &HD89F,
>>>> &H40 will make drive 2 the backside of drive 0. Likewise POKE
>>>> &HD8A0,&H41
>>>> will make drive 3 the back of drive 1. There a 4 memory locations that
>>>>
>>>>
>>> are
>>>
>>>
>>>> the drive mask (&HD89D - &HD8A0) the relevant bits are:
>>>> bit 0 - drive select 0 (&H01)
>>>> bit 1 - drive select 1 (&H02)
>>>> bit 2 - drive select 2 (&H04)
>>>> bit 7 - side select    (&H40)
>>>>
>>>>       These can be manipulated to access any side of any (physical)
>>>>
>>>>
>>> drive
>>>
>>>
>>>> as any drive number.
>>>>
>>>> --
>>>> Christopher R. Hawks
>>>> HAWKSoft
>>>> ---------------------------------------------------------
>>>> Never meddle in the affairs of NT. It is slow to boot and quick to
>>>> crash.
>>>>       -- Stephen Harris
>>>>
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>
>>>>
>>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>>
>>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From petrander at gmail.com  Mon Nov  2 09:19:34 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Mon, 2 Nov 2009 15:19:34 +0100
Subject: [Coco] OO programming - [Was]:Emulator
Message-ID: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>

Boy, I sure saw that one coming! :-)

> What is the big attraction to object-oriented? Like any other methodology,

> it has its place and is more suited to some problems than others.

Well, for one thing OO/D&P helps the programmer focus on the problem domain,
rather than on trivial hardware or platform-related requirements that in our
day and age are or should be abstracted away anyways. In the long run, it
will help the body of code remain easier to overview, easier to understand,
easier to develop, easier to manage and easier to change and expand,
especially when applying well-established Design Patterns.

> Yes, you can solve any problem with OO languages if you really desire,
> but it's not always the best solution.

Whereas it may be fine to solve trivial problems and/or do low-level
programming on hardware or embedded systems, when it comes to increasingly
complex user-focused applications, the best way to manage the resulting
jungle appears to be OO. One could also say that OO is closer to human
thinking processes and procedural languages are closer to machines
processes. So of course it depends whether the problem you are trying to
solve is machine-oriented, or user-oriented.

> In fact, I'd even venture to declare that OO is _not_ suitable, or at the
very
> least not much of an advantage, to a single-platform (eg Coco) emulator
design.

Perhaps so, but I can see major advantages in abstracting away logic dealing
with display and I/O and at the same time implementing the emulated system's
machine logic as the signal-exchanging objects that they in reality are. The
only downside would be performance, but on moderne day computers that should
not be a problem anymore. On an even more positive side, one could easily
make changes and reuse the same code for emulating different systems.

> And I've seen some really _bad_ and really _pointless_ "OO programs" in
the real world.

A poor craftsman blames his tools. Or: bad craftsmanship is more easily
blamed on the craftsman than on his tools. So that argument is not really
valid. :-)

> If the objective is fun and self challenge - by all means knock yourself
out!
> You can't have too many Coco emulators after all! ;)

Thanks, I will take your encouragement to heart and hope that I (or someone
else) some day will be able to come up with something new and exciting for
the community! Whatever it may be and however it may have been developed!
:-)

Cheers,
Fedor


2009/11/1 Mark McDougall <msmcdoug at iinet.net.au>

> Fedor Steeman wrote:
>
>  besides that, it is not object-oriented. That is why I am hinting at
>> BlitzMax which is powerful, easy and object-oriented.
>>
>
> What is the big attraction to object-oriented? Like any other methodology,
> it has its place and is more suited to some problems than others. In fact,
> I'd even venture to declare that OO is _not_ suitable, or at the very least
> not much of an advantage, to a single-platform (eg Coco) emulator design.
>
> Those that sprout the view that OO is the be-all-and-end-all to programming
> solutions have, IMHO, limited experience in real world problems (as in,
> limited _range_ of experience, not necessarily limited (time) programming
> experience) and/or limited understanding of when and how to best incorporate
> OO design principles. Yes, you can solve any problem with OO languages if
> you really desire, but it's not always the best solution. And I've seen some
> really _bad_ and really _pointless_ "OO programs" in the real world.
>
> And I don't mean to insinuate that you yourself fall into the above
> category.
>
> If the objective is fun and self challenge - by all means knock yourself
> out! You can't have too many Coco emulators after all! ;)
>
> That aside, I do actually agree with your "fuzz" comment. I'm a very
> occasional Coco emulator user and I do find myself having to relearn how to
> use MESS each time I need to crank up an emulator. However, at the end of
> the day, MESS still suits my own purposes (primarily development) and it is
> my emulator of choice.
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug<http://members.iinet.net.au/%7Emsmcdoug>>
>   |   with less resistance!"
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From linville at tuxdriver.com  Mon Nov  2 12:06:27 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 2 Nov 2009 12:06:27 -0500
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <002401ca5b61$427f1320$6501a8c0@aceraspire>
References: <d51.5b429328.381f828a@aol.com>
	<002401ca5b61$427f1320$6501a8c0@aceraspire>
Message-ID: <20091102170626.GF14046@tuxdriver.com>

On Mon, Nov 02, 2009 at 12:07:37PM +1000, Bob Devries wrote:

> Sigh..... gone are the good old days when I could walk into a store and 
> buy a handful of resistors or transistors.

Speaking of which, ever been to the Akihabara district in Tokyo?
Not sure if it is worth the trip just for that, but if you are ever
in Tokyo...

Alan Cox described as "a bit like a HAM radio convention that forgot
to close down", and I can put it any better. :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From msmcdoug at iinet.net.au  Mon Nov  2 18:17:59 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Tue, 03 Nov 2009 10:17:59 +1100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
Message-ID: <4AEF68A7.6060308@iinet.net.au>

Fedor Steeman wrote:

> Boy, I sure saw that one coming! :-)

Heh, and I'm sure this discussion has the potential to spiral out of control 
and run for weeks if we allow it. But I'd at least like to respond to a few 
points at the risk of annoying others...

FWIW I don't think we're ever going to agree or convince one another... ;)

> Well, for one thing OO/D&P helps the programmer focus on the problem
> domain, rather than on trivial hardware or platform-related requirements
> that in our day and age are or should be abstracted away anyways. 

That may be true if there is an appropriate framework already in place that 
is applicable to the problem domain. In the case of a coco emulator, the 
host GUI would be a good (and perhaps only) example.

> long run, it will help the body of code remain easier to overview, easier
> to understand, easier to develop, easier to manage and easier to change
> and expand, especially when applying well-established Design Patterns.

Only if well-written, and only if the OO paradigm is applicable to the 
problem. OO is not a magic bullet - it is not _automatically_ easier.

> Perhaps so, but I can see major advantages in abstracting away logic
> dealing with display and I/O and at the same time implementing the
> emulated system's machine logic as the signal-exchanging objects that
> they in reality are. 

You touch on the host GUI as I suspected and yes, depending on the host OS 
and cross-platform goals that may be true. But I suspect that the 
implementation of the coco logic may not benefit as much as you hope from OO 
design. For a single-target emulation, you're probably going to spend a 
_lot_ more time architecting and implementing the framework to support your 
ideal design, negating any benefits and in fact complicating the software.

The major benefits in OO design include re-use, loose coupling and 
maintainability - important benefits on large systems with many different 
components interacting and being used simultaneously by several other system 
components. Here abstraction is a huge plus, being able to hide 
implementation details behind a stable and well-known interface as the 
system grows and functionality is added.

I don't really see where any of this is much use to a coco emulator. And of 
course it comes with a cost - increased development effort (code size) and 
decreased performance (as you concede).

> A poor craftsman blames his tools. Or: bad craftsmanship is more easily 
> blamed on the craftsman than on his tools. So that argument is not really
>  valid. :-)

I didn't blame OO at all. My point was that a bad OO program is just as bad 
- if not worse - than a bad procedural program. And I've seen both, trust 
me. So your assessment of my "argument" is not really valid! :-)

> Thanks, I will take your encouragement to heart and hope that I (or
> someone else) some day will be able to come up with something new and
> exciting for the community! Whatever it may be and however it may have
> been developed! :-)

At the end of the day, it doesn't _really_ matter what tools are used, as 
long as they are used properly. And of course, everyone has a toolset with 
which they are more productive and skilled. Myself, I've worked on PC 
business applications in C++, through device drivers in C, down to coding 
assembler on micros and soft-core processors in FPGAs. I try to choose the 
most appropriate tools for the job at hand - though I must admit that C is 
always my fall-back language of choice for a lot of quick-n-dirty jobs that 
perhaps other languages (perl, sed/awk) would be more appropriate.

That said, personally, I probably wouldn't choose to do an OO Coco emulator.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From chadbh74 at hotmail.com  Mon Nov  2 23:49:42 2009
From: chadbh74 at hotmail.com (Chad H)
Date: Mon, 2 Nov 2009 22:49:42 -0600
Subject: [Coco] Cloud-9 Tech
Message-ID: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>

Is the Cloud-9 tech site/shop down?  I've e-mailed them twice to
orders at cloud9tech.com per the info on their ORDERS page but I have yet to
received a reply back.  Hope they aren't going away.



From aawolfe at gmail.com  Tue Nov  3 00:02:43 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 3 Nov 2009 00:02:43 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
Message-ID: <e44ad6640911022102x2350f31xad7fc3ecf9497848@mail.gmail.com>

I heard from Mark of Cloud 9 a couple weeks ago.  They are busy but
still in business as far as I know.  Some of their products are on
back order/waiting to be built, like the superIDE interface.  However,
I ordered a 512k ram upgrade and a drivewire kit earlier this year and
both were shipped quickly (and work great :)


On Mon, Nov 2, 2009 at 11:49 PM, Chad H <chadbh74 at hotmail.com> wrote:
> Is the Cloud-9 tech site/shop down? ?I've e-mailed them twice to
> orders at cloud9tech.com per the info on their ORDERS page but I have yet to
> received a reply back. ?Hope they aren't going away.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Tue Nov  3 01:44:12 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 3 Nov 2009 01:44:12 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <4AEF68A7.6060308@iinet.net.au>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
Message-ID: <e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>

On Mon, Nov 2, 2009 at 6:17 PM, Mark McDougall <msmcdoug at iinet.net.au> wrote:
> Fedor Steeman wrote:
>
>> Boy, I sure saw that one coming! :-)
>
> Heh, and I'm sure this discussion has the potential to spiral out of control
> and run for weeks if we allow it. But I'd at least like to respond to a few
> points at the risk of annoying others...
>
> FWIW I don't think we're ever going to agree or convince one another... ;)
>
>> Well, for one thing OO/D&P helps the programmer focus on the problem
>> domain, rather than on trivial hardware or platform-related requirements
>> that in our day and age are or should be abstracted away anyways.
>

"Abstraction" in OO terms has nothing to do with making it easier to
write for the hardware platform you're running your code on.  In OO
design, abstraction is making your code able to perform operations
without directly accessing or even understanding the details of the
underlying data structures in other parts of the program.  This does
have benefits in large, complex programs, but how this relates to
things "that in our day and age are or should be abstracted away
anyways" I have no idea.

Abstraction of low level system details is not an inherent
characteristic of OO design.   Both procedural and OO languages
provide libraries for this type of thing.  The standard C libraries
are one example of this.  In Perl, many libraries can be called either
as objects or as procedures.  They are functionally equivalent.  The
design paradigm is use has no effect on the abstract functionality
available.

> That may be true if there is an appropriate framework already in place that
> is applicable to the problem domain. In the case of a coco emulator, the
> host GUI would be a good (and perhaps only) example.
>
>> long run, it will help the body of code remain easier to overview, easier
>> to understand, easier to develop, easier to manage and easier to change
>> and expand, especially when applying well-established Design Patterns.
>
> Only if well-written, and only if the OO paradigm is applicable to the
> problem. OO is not a magic bullet - it is not _automatically_ easier.
>

Mark is quite right.  OO programming can be quite tedious and give
mediocre results even when done correctly.

Easier to overview and understand.. sometimes.. maybe.  There are
plenty of examples both of good and bad code done in any given
programming style.  The skill and dedication of the programmer(s) has
vastly more influence on this than the technique used.  I'll admit
that one area where OO stands out is in keeping bad programmers "on
the rails" and isolating their mistakes from good code.  It's often
harder to make code that breaks other code with OO design.  Whether
this is actually a good thing or not in the long run, I'm not sure :)

Easier to manage, change, expand.. probably, but only at scale.  In a
large system written by many programmers over many years, OO design
may help you achieve these things.  This is not to say that a properly
designed and managed procedural system could not also be changed and
expanded in an effective way.  I'm familiar with one project that has
thousands of loosely associated, part time contributors, a project
containing over 12 million lines of procedural code.  It turned out to
be one of the most stable, powerful operating system kernels in
existence today: Linux.

Author/hacker Paul Graham has written what I think is a very accurate
essay on OO, which speaks to many of the points we discussed here:
http://www.paulgraham.com/noop.html

>> Perhaps so, but I can see major advantages in abstracting away logic
>> dealing with display and I/O and at the same time implementing the
>> emulated system's machine logic as the signal-exchanging objects that
>> they in reality are.
>

Abstracting display and I/O can be accomplished without OO.
Abstraction and common library/module calls are not OO innovations.
The C programmers working on MESS, for example, do not write code that
directly manipulates your graphics card or disk controller.   there
are many layers of abstraction at work here.  OO design has little if
anything to do with these types of issues.

Implementing the "objects" in your computer (cpu/ram/controllers/etc)
as objects is a cute idea, but the paradigm works only at the simplest
level.  each physical object in your computer would require many
different objects from many classes to implement in an OO design.   An
emulator is a sort of extreme case where OO design's inefficiencies
become more apparent than in an average program.  You're simulating a
computer with another computer.. simple, direct translation of aspects
from one environment to the other is very effective.  creating and
manipulating complex logical structures is unnecessary and extremely
inefficient.

> You touch on the host GUI as I suspected and yes, depending on the host OS
> and cross-platform goals that may be true. But I suspect that the
> implementation of the coco logic may not benefit as much as you hope from OO
> design. For a single-target emulation, you're probably going to spend a
> _lot_ more time architecting and implementing the framework to support your
> ideal design, negating any benefits and in fact complicating the software.
>
> The major benefits in OO design include re-use, loose coupling and
> maintainability - important benefits on large systems with many different
> components interacting and being used simultaneously by several other system
> components. Here abstraction is a huge plus, being able to hide
> implementation details behind a stable and well-known interface as the
> system grows and functionality is added.
>

Again Mark is right on the money.  OO is a great tool in large systems
where the quality of the programmers is unknown and somewhat
uncontrollable, there are different departments or agencies involved,
or the code is expected to be reused in several projects.   In these
types of systems, performance is not a principle goal.  Each party
implements their interfaces to the specifications, and the beast
lumbers lazily along.  When something breaks, it's easy to figure out
who to blame.  The good part is that nobody ever has to know how the
whole thing works, thanks to OO design.  The bad part is that nobody
ever gets to know how the whole thing works :)

> I don't really see where any of this is much use to a coco emulator. And of
> course it comes with a cost - increased development effort (code size) and
> decreased performance (as you concede).
>

ditto

>> A poor craftsman blames his tools. Or: bad craftsmanship is more easily
>> blamed on the craftsman than on his tools. So that argument is not really
>> ?valid. :-)
>
> I didn't blame OO at all. My point was that a bad OO program is just as bad
> - if not worse - than a bad procedural program. And I've seen both, trust
> me. So your assessment of my "argument" is not really valid! :-)
>
>> Thanks, I will take your encouragement to heart and hope that I (or
>> someone else) some day will be able to come up with something new and
>> exciting for the community! Whatever it may be and however it may have
>> been developed! :-)
>
> At the end of the day, it doesn't _really_ matter what tools are used, as
> long as they are used properly. And of course, everyone has a toolset with
> which they are more productive and skilled. Myself, I've worked on PC
> business applications in C++, through device drivers in C, down to coding
> assembler on micros and soft-core processors in FPGAs. I try to choose the
> most appropriate tools for the job at hand - though I must admit that C is
> always my fall-back language of choice for a lot of quick-n-dirty jobs that
> perhaps other languages (perl, sed/awk) would be more appropriate.
>
> That said, personally, I probably wouldn't choose to do an OO Coco emulator.

one last ditto :)
-Aaron

>
> Regards,
>
> --
> | ? ? ? ? ? ? ?Mark McDougall ? ? ? ? ? ? ? ?| "Electrical Engineers do it
> | ?<http://members.iinet.net.au/~msmcdoug> ? | ? with less resistance!"
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From jdaggett at gate.net  Tue Nov  3 08:42:57 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Tue, 03 Nov 2009 08:42:57 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
Message-ID: <4AF03361.1218.FCC7E@jdaggett.gate.net>

Chad

Mark came onto the list with an email in early September and stated that vacations and work 
has ate time away from answering emails, even time on this list and fulfilling his orders with 
Cloud9. I kind of know what he maybe going through at his regular job. Considering his work 
has lost 2/3rds of the employees due to layoffs, you are somewhat at the mercy of your 
employer as to work hours. It is hell to do the same amount of work with less people for any 
length of time. Very long hours and not much time for anything else. Let alone the family. 

Remember Cloud9 is not Mark's prime source of income. It is done for a love of the Coco 
and the community. 

james

On 2 Nov 2009 at 22:49, Chad H wrote:

> Is the Cloud-9 tech site/shop down?  I've e-mailed them twice to
> orders at cloud9tech.com per the info on their ORDERS page but I have yet to
> received a reply back.  Hope they aren't going away.
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco




From johnadonaldson at sbcglobal.net  Tue Nov  3 09:55:00 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Tue, 03 Nov 2009 08:55:00 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF03361.1218.FCC7E@jdaggett.gate.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
	<4AF03361.1218.FCC7E@jdaggett.gate.net>
Message-ID: <4AF04444.30905@sbcglobal.net>

James,
    Doesn't Mark work for Fed-X or something like that. I can understand 
his long hours. I just got a package delivered byt Fed-X yesterday at 
7:35PM. Which means that the driver may not get back to his depot until 
9 or 10PM. Sure don't leave much time to do anything else. and with the 
Holidays now starting, it is only going to get longer.

John





jdaggett at gate.net wrote:
> Chad
>
> Mark came onto the list with an email in early September and stated that vacations and work 
> has ate time away from answering emails, even time on this list and fulfilling his orders with 
> Cloud9. I kind of know what he maybe going through at his regular job. Considering his work 
> has lost 2/3rds of the employees due to layoffs, you are somewhat at the mercy of your 
> employer as to work hours. It is hell to do the same amount of work with less people for any 
> length of time. Very long hours and not much time for anything else. Let alone the family. 
>
> Remember Cloud9 is not Mark's prime source of income. It is done for a love of the Coco 
> and the community. 
>
>   



> james
>
> On 2 Nov 2009 at 22:49, Chad H wrote:
>
>   
>> Is the Cloud-9 tech site/shop down?  I've e-mailed them twice to
>> orders at cloud9tech.com per the info on their ORDERS page but I have yet to
>> received a reply back.  Hope they aren't going away.
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>     
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>   


-- 


From briang0671 at sbcglobal.net  Tue Nov  3 12:46:50 2009
From: briang0671 at sbcglobal.net (Brian Goers)
Date: Tue, 03 Nov 2009 11:46:50 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF04444.30905@sbcglobal.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>
	<4AF04444.30905@sbcglobal.net>
Message-ID: <4AF06C8A.5010803@sbcglobal.net>

John Donaldson wrote:
> James,
>    Doesn't Mark work for Fed-X or something like that. I can understand
> his long hours. I just got a package delivered byt Fed-X yesterday at
> 7:35PM. Which means that the driver may not get back to his depot until
> 9 or 10PM. Sure don't leave much time to do anything else. and with the
> Holidays now starting, it is only going to get longer.
> 
> John
> 
> 
> 
> jdaggett at gate.net wrote:
>> Chad
>>
>> Mark came onto the list with an email in early September and stated
>> that vacations and work has ate time away from answering emails, even
>

[Stuff Deleted]
I believe Roger Taylor is a Fed-Ex driver. Mark is a Electronic
development Lab. I don't recall what they develop.


-- 
Brian Goers
Glenside Computer Club
Vice President of Special Events
                           The 19th Annual ?LAST? Chicago CoCoFEST!
                           Will be held May 15 &16, 2010
                           Holiday Inn & Suites in Elgin.
 Glenside URL - http://GlensideCCC.com

"The man who does not read good books has no advantage over the man
 who can't read them."--Mark Twain



From briang0671 at sbcglobal.net  Tue Nov  3 12:58:32 2009
From: briang0671 at sbcglobal.net (Brian Goers)
Date: Tue, 03 Nov 2009 11:58:32 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF06C8A.5010803@sbcglobal.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>	<4AF04444.30905@sbcglobal.net>
	<4AF06C8A.5010803@sbcglobal.net>
Message-ID: <4AF06F48.2070404@sbcglobal.net>

Brian Goers wrote:
> John Donaldson wrote:
>> James,
>>    Doesn't Mark work for Fed-X or something like that. I can understand
>> his long hours. I just got a package delivered byt Fed-X yesterday at
>> 7:35PM. Which means that the driver may not get back to his depot until
>> 9 or 10PM. Sure don't leave much time to do anything else. and with the
>> Holidays now starting, it is only going to get longer.
>>
>> John
>>
>>
>>
>> jdaggett at gate.net wrote:
>>> Chad
>>>
>>> Mark came onto the list with an email in early September and stated
>>> that vacations and work has ate time away from answering emails, even
> 
> [Stuff Deleted]
> I believe Roger Taylor is a Fed-Ex driver. Mark is a Electronic
> development Lab. I don't recall what they develop.
> 
> 
Oops, I don't mean Mark is a Lab. He works at a Lab.

-- 
Brian Goers
Glenside Computer Club
Vice President of Special Events
                           The 19th Annual ?LAST? Chicago CoCoFEST!
                           Will be held May 15 &16, 2010
                           Holiday Inn & Suites in Elgin.
 Glenside URL - http://GlensideCCC.com

"The man who does not read good books has no advantage over the man
 who can't read them."--Mark Twain



From jdaggett at gate.net  Tue Nov  3 14:38:00 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Tue, 03 Nov 2009 14:38:00 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF04444.30905@sbcglobal.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>,
	<4AF03361.1218.FCC7E@jdaggett.gate.net>,
	<4AF04444.30905@sbcglobal.net>
Message-ID: <4AF08698.9965.79F177@jdaggett.gate.net>

On 3 Nov 2009 at 8:55, John Donaldson wrote:

> James,
>     Doesn't Mark work for Fed-X or something like that. I can understand
> his long hours. I just got a package delivered byt Fed-X yesterday at 
> 7:35PM. Which means that the driver may not get back to his depot until 
> 9 or 10PM. Sure don't leave much time to do anything else. and with the 
> Holidays now starting, it is only going to get longer.
> 
> John

John

Brian pretty much said it. Mark works for an Electronics firm in a Test lab of some sorts. Not 
sure if it is component or module test. I know when I worked for Motorola when Engineering 
scaled back so did the test lab personnel that did all our Accellerated Life Testing of products 
as well as component qualifications. 

In a way I am glad that I am out of that now. It is nice to be retired. 

james


From johnadonaldson at sbcglobal.net  Tue Nov  3 16:59:14 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Tue, 03 Nov 2009 15:59:14 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF06C8A.5010803@sbcglobal.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>	<4AF04444.30905@sbcglobal.net>
	<4AF06C8A.5010803@sbcglobal.net>
Message-ID: <4AF0A7B2.40704@sbcglobal.net>

Brian Goers wrote:
> John Donaldson wrote:
>   
>> James,
>>    Doesn't Mark work for Fed-X or something like that. I can understand
>> his long hours. I just got a package delivered byt Fed-X yesterday at
>> 7:35PM. Which means that the driver may not get back to his depot until
>> 9 or 10PM. Sure don't leave much time to do anything else. and with the
>> Holidays now starting, it is only going to get longer.
>>
>> John
>>
>>
>>
>> jdaggett at gate.net wrote:
>>     
>>> Chad
>>>
>>> Mark came onto the list with an email in early September and stated
>>> that vacations and work has ate time away from answering emails, even
>>>       
>
> [Stuff Deleted]
> I believe Roger Taylor is a Fed-Ex driver. Mark is a Electronic
> development Lab. I don't recall what they develop.
>
>
>   
It's hard to keep people straight now adays.

John D.


-- 


From petrander at gmail.com  Tue Nov  3 18:36:49 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Wed, 4 Nov 2009 00:36:49 +0100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
Message-ID: <dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>

Hi again,

@MM:
> > FWIW I don't think we're ever going to agree or convince one another...
> ;)
>

On the contrary, I have to disagree! ;-)
I think we are closing in on a consensus, but we just do not realize it yet!
I see you both actually confirming a lot of the points I made earlier,
whilst maintaining disagreement. :-D


> @AW:
> "Abstraction" in OO terms has nothing to do with making it easier to
> write for the hardware platform you're running your code on.  In OO
> design, abstraction is making your code able to perform operations
> without directly accessing or even understanding the details of the
> underlying data structures in other parts of the program.  This does
> have benefits in large, complex programs,


Well, see? We actually agree on this! Abstraction in general and, may I add,
OO specifically, do have benefits in large, complex programs.


> but how this relates to
> things "that in our day and age are or should be abstracted away
> anyways" I have no idea.
>

Judging from your own explanations, you show that you _do_ have an idea how
abstraction relates to easier programming, namely "making your code able to
perform operations without directly accessing or even understanding the
details of the underlying data structures in other parts of the program".
Wrapping up all trivial logic into their own little black boxes, makes a
huge difference for managing your code.


> Abstraction of low level system details is not an inherent
> characteristic of OO design.   Both procedural and OO languages
> provide libraries for this type of thing.


I was merely using hardware abstraction as an example. More broadly, I meant
wrapping up trival logic. I think we understand each other on this issue.


> @MM:
> > That may be true if there is an appropriate framework already in place
> that
> > is applicable to the problem domain. In the case of a coco emulator, the
> > host GUI would be a good (and perhaps only) example.
>

Perhaps only, or perhaps not. I agree that it is an issue to debate whether
OO is suitable for developing a CoCo emulator.


> @MM:
> >> long run, it will help the body of code remain easier to overview,
> easier
> >> to understand, easier to develop, easier to manage and easier to change
> >> and expand, especially when applying well-established Design Patterns.
> >
> > Only if well-written, and only if the OO paradigm is applicable to the
> > problem. OO is not a magic bullet - it is not _automatically_ easier
>
@AW:
> Easier to overview and understand.. sometimes.. maybe.  There are
> plenty of examples both of good and bad code done in any given
> programming style.  The skill and dedication of the programmer(s) has
> vastly more influence on this than the technique used.


Obviously. But if we want to compare the two paradigms then that factor (the
skill of the programmer) should be kept the same. I never said that OO is a
magic bullet that makes everything automatically easier. But, depending on
the application, it can have major advantages, as both of you more or less
admit.


> @AW:
> Mark is quite right.  OO programming can be quite tedious and give
> mediocre results even when done correctly.
>

It does sound to my ears that you guys find all that modelling and
conceptualizing a lot of fuzz and rather want to go straight to the fun part
of programming and getting things to work. I can well understand as I am
also often tempted in that direction. However, from my own, admittedly
relatively limited, experience with programming higher level applications, I
always end up regretting it. In contrast, I experience that I end up saving
a lot of development and debugging time in the long run. If I then also
apply unit testing then I feel even more in control. Perhaps you also find
unit testing too much of a fuzz to bother with? :-)

Anyways, if this were just limited to my own personal experiences then you
may just shrug your shoulders, but OO D/P has become a major force in the
industry and the recommended practice as endorsed by major system
development gurus. So I am not just fooling myself in any case.

>
>  I'll admit
> that one area where OO stands out is in keeping bad programmers "on
> the rails" and isolating their mistakes from good code.  It's often
> harder to make code that breaks other code with OO design.  Whether
> this is actually a good thing or not in the long run, I'm not sure :)
>

If a methodology can keep bad programmers on the right track, imagine what a
highly-skilled programmer might achieve with it! Wait, no need to imagine,
it is alreay happening all around us! :-)


> Easier to manage, change, expand.. probably, but only at scale.  In a
> large system written by many programmers over many years, OO design
> may help you achieve these things.  This is not to say that a properly
> designed and managed procedural system could not also be changed and
> expanded in an effective way.  I'm familiar with one project that has
> thousands of loosely associated, part time contributors, a project
> containing over 12 million lines of procedural code.  It turned out to
> be one of the most stable, powerful operating system kernels in
> existence today: Linux.
>

Hold on there! I think you missed my earlier remark that procedural
languages may be well suite for hardware-focused programming, whereas OO
languages are more suitable for human-focused programming. Obviously then,
an OS Kernel is best written in a procedural language, whereas a business
application, subject to a large number of business rules and specifications,
addressing real world problems and armies of irrational users, is best
served with an OO design model.

Say, I wonder what something like OpenOffice is written in, hmmm.....

http://www.ohloh.net/p/openoffice/analyses/latest

Well, waddayaknow! C++ and Java abound! :-D

Also, one must not forget that the Linux kernel was written over 18 years
ago, before OO became a factor to reckon with, and, interestingly, most
Linux distributions today encourage you to write your non-kernel
contributions in other languages than C (Java for Red Hat, Python for Yellow
Dog and Debian, Ubuntu...)

Author/hacker Paul Graham has written what I think is a very accurate
> essay on OO, which speaks to many of the points we discussed here:
> http://www.paulgraham.com/noop.html
>

Can't blame Paul Graham for protecting his brain child. Yet I would like to
see him write an Office package in Lisp. :-)

For each article you can find criticising the Object Oriented paradigm by a
self-confessed non-user, and thus probably not fully understanding it, you
can find long books describing its benefits. Martin Fowler, Craig Larman,
Eric Gamma, Kent Beck, Alan Kay, Bruce Eckel, Fred Brooks. Can all these
guys (two of whom have received Turing Awards for their contributions to
Computer Science) be simply wrong about the object oriented paradigm,
because they're mediocre programmers who work for IBM? Doesn't really sound
like a reasonable arguement to me. :-)


> @AW:
> Implementing the "objects" in your computer (cpu/ram/controllers/etc)
> as objects is a cute idea, but the paradigm works only at the simplest
> level.  each physical object in your computer would require many
> different objects from many classes to implement in an OO design.   An
> emulator is a sort of extreme case where OO design's inefficiencies
> become more apparent than in an average program.  You're simulating a
> computer with another computer.. simple, direct translation of aspects
> from one environment to the other is very effective.

creating and
> manipulating complex logical structures is unnecessary and extremely
> inefficient.
>
>@MM:
> You touch on the host GUI as I suspected and yes, depending on the host OS
> and cross-platform goals that may be true. But I suspect that the
> implementation of the coco logic may not benefit as much as you hope from
OO
> design. For a single-target emulation, you're probably going to spend a
> _lot_ more time architecting and implementing the framework to support
your
> ideal design, negating any benefits and in fact complicating the software.

Fair enough. Admittedly, an emulator like this is not like a bloated
business application and it sounds sensible enough to mimic hardware
processes with hardware near procedures. Not in the least because they are
timing-critical. It would probably not have been a good idea in the early
nineties, but nowadays, I would find it odd that this would be an issue when
running it on a multi-core CPU with several Gigs of RAM. I mean if it can
run Vista, it can run anything! :-)

> The major benefits in OO design include re-use, loose coupling and
> maintainability - important benefits on large systems with many different
> components interacting and being used simultaneously by several other
system
> components. Here abstraction is a huge plus, being able to hide
> implementation details behind a stable and well-known interface as the
> system grows and functionality is added.

Nice to see you confirming the benefits of OO design. :-)
I would dare venture that at least re-use, low coupling, maintainability,
and the resulting flexibility can be of benefit too when developing a CoCo
emulator. E.g. the easy switching of one component with another (say, a
SAM+VDG with a GIME?). Heck, with a loosely coupled bag of finished objects
we construct all kinds of different hardware configurations. It would be
like playing with Lego! Want a CoCo4 emulator? Should we trying SockMaster's
3 x 6309-option or combine a 68000 with some custom graphics chip? How about
emulating a TomCat TC-9 or TC-70? We have got most components already done!
I can only see infinite possibilties. Besides the perhaps steep initial
stages, you may eventually end up saving time and speed up development,
which after all is the whole objective of OO design!

Thus, all these so-called "inefficiences", which mainly pertain performance
and overhead, would be nullified by modern hardware and the benefits of the
OO approach. What's more, it simultaneously provides a way of better
understanding what makes a CoCo "tick". Now don't get me wrong: Of course
there should be limits to how deeply the machine logic should be
implemented. But just saying beforehand that it won't fly sounds a bit
premature. Even worse: I don't understand why anyone would discourage any
positive initiative in our small community. On the other hand, it does sound
like a challenge to my ear that I would most certainly want to try to meet,
had I ample time and resources.

Regards,

Fedor Steeman

BTW: In all these discussions, I forgot to stress that although I hopped in
on a thread with the OP criticizing existing emulators, I in no way endorse
this kind of negativity when dealing with any project that people do in
their spare time for the fun of it and for the benefit of people sharing
their interests.


From aawolfe at gmail.com  Tue Nov  3 20:07:11 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 3 Nov 2009 20:07:11 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
Message-ID: <e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>

On Tue, Nov 3, 2009 at 6:36 PM, Fedor Steeman <petrander at gmail.com> wrote:
> Hi again,
>
> @MM:
>> > FWIW I don't think we're ever going to agree or convince one another...
>> ;)
>>
>
> On the contrary, I have to disagree! ;-)
> I think we are closing in on a consensus, but we just do not realize it yet!
> I see you both actually confirming a lot of the points I made earlier,
> whilst maintaining disagreement. :-D
>
>
>> @AW:
>> "Abstraction" in OO terms has nothing to do with making it easier to
>> write for the hardware platform you're running your code on. ?In OO
>> design, abstraction is making your code able to perform operations
>> without directly accessing or even understanding the details of the
>> underlying data structures in other parts of the program. ?This does
>> have benefits in large, complex programs,
>
>
> Well, see? We actually agree on this! Abstraction in general and, may I add,
> OO specifically, do have benefits in large, complex programs.
>
>
>> but how this relates to
>> things "that in our day and age are or should be abstracted away
>> anyways" I have no idea.
>>
>
> Judging from your own explanations, you show that you _do_ have an idea how
> abstraction relates to easier programming, namely "making your code able to
> perform operations without directly accessing or even understanding the
> details of the underlying data structures in other parts of the program".
> Wrapping up all trivial logic into their own little black boxes, makes a
> huge difference for managing your code.
>

Agreed, but whether these black boxes are objects or functions or
modules or libraries makes little difference.  When you have to write
all or most of the black boxes yourself, as I would expect in a Coco
emulator project, it makes even less difference how they are packaged.

I am a huge fan of abstraction, its a fundamental CS concept that
predates OO by some tens of years.  I don't see the many benefits a
properly layered system provides as something one would attribute to
OO design, since abstraction is found in practically every system
regardless of whether it is object oriented.

>
>> Abstraction of low level system details is not an inherent
>> characteristic of OO design. ? Both procedural and OO languages
>> provide libraries for this type of thing.
>
>
> I was merely using hardware abstraction as an example. More broadly, I meant
> wrapping up trival logic. I think we understand each other on this issue.
>
>
>> @MM:
>> > That may be true if there is an appropriate framework already in place
>> that
>> > is applicable to the problem domain. In the case of a coco emulator, the
>> > host GUI would be a good (and perhaps only) example.
>>
>
> Perhaps only, or perhaps not. I agree that it is an issue to debate whether
> OO is suitable for developing a CoCo emulator.
>
>
>> @MM:
>> >> long run, it will help the body of code remain easier to overview,
>> easier
>> >> to understand, easier to develop, easier to manage and easier to change
>> >> and expand, especially when applying well-established Design Patterns.
>> >
>> > Only if well-written, and only if the OO paradigm is applicable to the
>> > problem. OO is not a magic bullet - it is not _automatically_ easier
>>
> @AW:
>> Easier to overview and understand.. sometimes.. maybe. ?There are
>> plenty of examples both of good and bad code done in any given
>> programming style. ?The skill and dedication of the programmer(s) has
>> vastly more influence on this than the technique used.
>
>
> Obviously. But if we want to compare the two paradigms then that factor (the
> skill of the programmer) should be kept the same. I never said that OO is a
> magic bullet that makes everything automatically easier. But, depending on
> the application, it can have major advantages, as both of you more or less
> admit.
>
>
>> @AW:
>> Mark is quite right. ?OO programming can be quite tedious and give
>> mediocre results even when done correctly.
>>
>
> It does sound to my ears that you guys find all that modelling and
> conceptualizing a lot of fuzz and rather want to go straight to the fun part
> of programming and getting things to work. I can well understand as I am
> also often tempted in that direction. However, from my own, admittedly
> relatively limited, experience with programming higher level applications, I
> always end up regretting it. In contrast, I experience that I end up saving
> a lot of development and debugging time in the long run. If I then also
> apply unit testing then I feel even more in control. Perhaps you also find
> unit testing too much of a fuzz to bother with? :-)
>

Unit testing is great.  It's yet another concept that predates and
continues to exist outside of OO design.  I have a general feeling you
might be attributing things to object orientedness that are in fact
not exclusive to that paradigm.
http://en.wikipedia.org/wiki/Unit_testing

> Anyways, if this were just limited to my own personal experiences then you
> may just shrug your shoulders, but OO D/P has become a major force in the
> industry and the recommended practice as endorsed by major system
> development gurus. So I am not just fooling myself in any case.
>
>>
>> ?I'll admit
>> that one area where OO stands out is in keeping bad programmers "on
>> the rails" and isolating their mistakes from good code. ?It's often
>> harder to make code that breaks other code with OO design. ?Whether
>> this is actually a good thing or not in the long run, I'm not sure :)
>>
>
> If a methodology can keep bad programmers on the right track, imagine what a
> highly-skilled programmer might achieve with it! Wait, no need to imagine,
> it is alreay happening all around us! :-)
>

That's like saying, "if training wheels keep a kid from falling over
on their bike, imagine what Lance Armstrong could do if he installed
them on his racing bikes".  bad logic.

>
>> Easier to manage, change, expand.. probably, but only at scale. ?In a
>> large system written by many programmers over many years, OO design
>> may help you achieve these things. ?This is not to say that a properly
>> designed and managed procedural system could not also be changed and
>> expanded in an effective way. ?I'm familiar with one project that has
>> thousands of loosely associated, part time contributors, a project
>> containing over 12 million lines of procedural code. ?It turned out to
>> be one of the most stable, powerful operating system kernels in
>> existence today: Linux.
>>
>
> Hold on there! I think you missed my earlier remark that procedural
> languages may be well suite for hardware-focused programming, whereas OO
> languages are more suitable for human-focused programming. Obviously then,
> an OS Kernel is best written in a procedural language, whereas a business
> application, subject to a large number of business rules and specifications,
> addressing real world problems and armies of irrational users, is best
> served with an OO design model.
>

You've missed my point.  Whether the Linux kernel targets hardware is
irrelevant.
Linux is a massive project with a huge number of programmers written
over many years.  Most parts of it have been rewritten or updated on a
regular basis.  New functionality is added in each release. Stability
and inter-operation between all the various parts is critical.
Abstraction is present in almost every component.  Sounds like all the
things that OO design would be used to deal with, yet this project
does not use OO design and has come out incredibly well.

I present this example as evidence that a very large project can
achieve the same benefits that OO design provides, without using OO
design.

> Say, I wonder what something like OpenOffice is written in, hmmm.....
>
> http://www.ohloh.net/p/openoffice/analyses/latest
>
> Well, waddayaknow! C++ and Java abound! :-D
>
> Also, one must not forget that the Linux kernel was written over 18 years
> ago, before OO became a factor to reckon with, and, interestingly, most
> Linux distributions today encourage you to write your non-kernel
> contributions in other languages than C (Java for Red Hat, Python for Yellow
> Dog and Debian, Ubuntu...)
>
> Author/hacker Paul Graham has written what I think is a very accurate
>> essay on OO, which speaks to many of the points we discussed here:
>> http://www.paulgraham.com/noop.html
>>
>
> Can't blame Paul Graham for protecting his brain child. Yet I would like to
> see him write an Office package in Lisp. :-)
>
> For each article you can find criticising the Object Oriented paradigm by a
> self-confessed non-user, and thus probably not fully understanding it, you
> can find long books describing its benefits. Martin Fowler, Craig Larman,
> Eric Gamma, Kent Beck, Alan Kay, Bruce Eckel, Fred Brooks. Can all these
> guys (two of whom have received Turing Awards for their contributions to
> Computer Science) be simply wrong about the object oriented paradigm,
> because they're mediocre programmers who work for IBM? Doesn't really sound
> like a reasonable arguement to me. :-)
>

I'd hoped we could focus on the points Mr. Graham makes in his essay,
not details about his background.  I think his words are accurate and
reflect what I've seen in my own experiences as a programmer.

Of course I could provide a long list of equally impressive names
who've written negatively about OO design.  Wikipedia has such a list
in their article on OO design if you're interested.  The truth is that
even strong proponents admit problems with OO design, and strong
opponents concede that it has valuable elements.

I don't think any of those experts would argue that OO design is
always the best way to write software, or the only way to achieve the
benefits attributed to OO design.   I would not expect the experts on
your list to blindly apply OO principles to a project that does not
benefit from them.

>
>> @AW:
>> Implementing the "objects" in your computer (cpu/ram/controllers/etc)
>> as objects is a cute idea, but the paradigm works only at the simplest
>> level. ?each physical object in your computer would require many
>> different objects from many classes to implement in an OO design. ? An
>> emulator is a sort of extreme case where OO design's inefficiencies
>> become more apparent than in an average program. ?You're simulating a
>> computer with another computer.. simple, direct translation of aspects
>> from one environment to the other is very effective.
>
> creating and
>> manipulating complex logical structures is unnecessary and extremely
>> inefficient.
>>
>>@MM:
>> You touch on the host GUI as I suspected and yes, depending on the host OS
>> and cross-platform goals that may be true. But I suspect that the
>> implementation of the coco logic may not benefit as much as you hope from
> OO
>> design. For a single-target emulation, you're probably going to spend a
>> _lot_ more time architecting and implementing the framework to support
> your
>> ideal design, negating any benefits and in fact complicating the software.
>
> Fair enough. Admittedly, an emulator like this is not like a bloated
> business application and it sounds sensible enough to mimic hardware
> processes with hardware near procedures. Not in the least because they are
> timing-critical. It would probably not have been a good idea in the early
> nineties, but nowadays, I would find it odd that this would be an issue when
> running it on a multi-core CPU with several Gigs of RAM. I mean if it can
> run Vista, it can run anything! :-)
>
>> The major benefits in OO design include re-use, loose coupling and
>> maintainability - important benefits on large systems with many different
>> components interacting and being used simultaneously by several other
> system
>> components. Here abstraction is a huge plus, being able to hide
>> implementation details behind a stable and well-known interface as the
>> system grows and functionality is added.
>
> Nice to see you confirming the benefits of OO design. :-)

These are benefits that can be achieved in a number of ways.  They are
not the exclusive domain of OO design.

> I would dare venture that at least re-use, low coupling, maintainability,
> and the resulting flexibility can be of benefit too when developing a CoCo
> emulator. E.g. the easy switching of one component with another (say, a
> SAM+VDG with a GIME?). Heck, with a loosely coupled bag of finished objects
> we construct all kinds of different hardware configurations. It would be
> like playing with Lego! Want a CoCo4 emulator? Should we trying SockMaster's
> 3 x 6309-option or combine a 68000 with some custom graphics chip? How about
> emulating a TomCat TC-9 or TC-70? We have got most components already done!
> I can only see infinite possibilties. Besides the perhaps steep initial
> stages, you may eventually end up saving time and speed up development,
> which after all is the whole objective of OO design!
>

All of these great things could be done in a procedural system.   OO
design is not a requirement.

> Thus, all these so-called "inefficiences", which mainly pertain performance
> and overhead, would be nullified by modern hardware and the benefits of the
> OO approach. What's more, it simultaneously provides a way of better
> understanding what makes a CoCo "tick".

The coco is not an object oriented system.  I don't see how using one
to implement a Coco would improve one's understanding of the Coco any
more than writing a procedural emulator would.

> Now don't get me wrong: Of course
> there should be limits to how deeply the machine logic should be
> implemented. But just saying beforehand that it won't fly sounds a bit
> premature. Even worse: I don't understand why anyone would discourage any
> positive initiative in our small community. On the other hand, it does sound
> like a challenge to my ear that I would most certainly want to try to meet,
> had I ample time and resources.
>

As I said in my first post, I think it would behoove our small
community to focus our limited resources on projects that provide the
most bang for the buck.  MESS is a good emulator.  It already runs on
a huge number of systems, because it is open source, it will continue
to run on new systems as they come out.  We can add or correct
features in MESS any time we want to.  Certainly this can be done more
easily than writing a whole new system.  There are no limitations in
MESS that prevent implementing any feature (that I've heard of, at
least) that is desired from a new emulator.

I don't like negativity either, but I feel that bad ideas that can be
easily corrected are worth pointing out.  I'll be the first to admit
that sometimes I am an overly critical a-hole, but honestly my
intentions are to steer any efforts in the most beneficial direction
for the community (and likely the individual), not to stifle them.

> Regards,
>
> Fedor Steeman
>
> BTW: In all these discussions, I forgot to stress that although I hopped in
> on a thread with the OP criticizing existing emulators, I in no way endorse
> this kind of negativity when dealing with any project that people do in
> their spare time for the fun of it and for the benefit of people sharing
> their interests.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From operator at coco3.com  Wed Nov  4 18:09:48 2009
From: operator at coco3.com (Roger Taylor)
Date: Wed, 04 Nov 2009 17:09:48 -0600
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <dbdeb2610911011755j1678442eh6f32cee7c9fb9a27@mail.gmail.co
 m>
References: <d51.5b429328.381f828a@aol.com>
	<dbdeb2610911011755j1678442eh6f32cee7c9fb9a27@mail.gmail.com>
Message-ID: <6.2.5.6.1.20091104165827.06254868@coco3.com>

At 07:55 PM 11/1/2009, you wrote:
>Probably thought you wanted directions to Walmart and couldn't pronounce it
>right...
>
>Art



HAHAHAAA!!  Funniest thing this year.  I can picture them looking at 
Roy with that "tone" they all have.  They all look at us like we're 
talking in Clicks and Grunts like a caveman.   What SCHOOL do they go 
to learn this behavior, anyway!??!  It's all the same no matter what 
Shack I've been in.

-- 
~ Roger Taylor




From operator at coco3.com  Wed Nov  4 17:11:46 2009
From: operator at coco3.com (Roger Taylor)
Date: Wed, 04 Nov 2009 16:11:46 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF04444.30905@sbcglobal.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
	<4AF03361.1218.FCC7E@jdaggett.gate.net>
	<4AF04444.30905@sbcglobal.net>
Message-ID: <6.2.5.6.1.20091104161016.06254348@coco3.com>

At 08:55 AM 11/3/2009, you wrote:
>James,
>    Doesn't Mark work for Fed-X or something like that. I can 
> understand his long hours. I just got a package delivered byt Fed-X 
> yesterday at 7:35PM. Which means that the driver may not get back 
> to his depot until 9 or 10PM. Sure don't leave much time to do 
> anything else. and with the Holidays now starting, it is only going 
> to get longer.
>
>John



I think you're partially recalling that I work for UPS, and not Mark for FedEx?


-- 
~ Roger Taylor




From operator at coco3.com  Wed Nov  4 17:58:17 2009
From: operator at coco3.com (Roger Taylor)
Date: Wed, 04 Nov 2009 16:58:17 -0600
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <d51.5b429328.381f828a@aol.com>
References: <d51.5b429328.381f828a@aol.com>
Message-ID: <6.2.5.6.1.20091104163151.062545d8@coco3.com>

At 06:32 PM 11/1/2009, you wrote:
>People
>
>     I recently went into a local radioshack store and  asked where
>she kept the wallwarts.    She looked at me like I had  just
>insulted her in a foreign language.   Its getting pathetic
>at the shack let me tell ya.....
>
>Roy


Roy, an event I would pay good money to see is to watch at least one 
Radio Shack run by bimbos or dunces, completely bull-dozer'ed down to 
a pile of broken bricks.

-- 
~ Roger Taylor




From linville at tuxdriver.com  Wed Nov  4 19:02:41 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 4 Nov 2009 19:02:41 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <6.2.5.6.1.20091104161016.06254348@coco3.com>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
	<4AF03361.1218.FCC7E@jdaggett.gate.net>
	<4AF04444.30905@sbcglobal.net>
	<6.2.5.6.1.20091104161016.06254348@coco3.com>
Message-ID: <20091105000241.GK10786@tuxdriver.com>

On Wed, Nov 04, 2009 at 04:11:46PM -0600, Roger Taylor wrote:
> At 08:55 AM 11/3/2009, you wrote:
>> James,
>>    Doesn't Mark work for Fed-X or something like that. I can  
>> understand his long hours. I just got a package delivered byt Fed-X  
>> yesterday at 7:35PM. Which means that the driver may not get back to 
>> his depot until 9 or 10PM. Sure don't leave much time to do anything 
>> else. and with the Holidays now starting, it is only going to get 
>> longer.
>>
>> John
>
>
>
> I think you're partially recalling that I work for UPS, and not Mark for FedEx?

Gaahh!  Stop!!!  No more images in my head of Mark in brown shorts
and a ball cap!!!!

:-)

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From msmcdoug at iinet.net.au  Wed Nov  4 22:19:11 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Thu, 05 Nov 2009 14:19:11 +1100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>	<4AEF68A7.6060308@iinet.net.au>	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
Message-ID: <4AF2442F.5090500@iinet.net.au>

Aaron Wolfe wrote:

> The coco is not an object oriented system.  I don't see how using one
> to implement a Coco would improve one's understanding of the Coco any
> more than writing a procedural emulator would.

Ditto.

> There are no limitations in
> MESS that prevent implementing any feature (that I've heard of, at
> least) that is desired from a new emulator.

This point (alone) may be arguable, though I can't offer any specific 
counter-examples.

Although I don't agree with Fedor's claims that some of my own points 
reinforce his argument, I'm not going to bore our Coco group members by 
going further off-tangent. Rather, I'll silently respect his opinion.

I think it can be safely said that Fedor, Aaron and myself generally agree 
at some level; where we differ is our opinion on its suitability and 
proported benefits for a Coco emulator. And here we shall remain divided. :)

Again, don't let this stop any of you from starting your own Coco emulator 
project, whether it be in C, C++, BASIC, ASM, Lisp.... OK, Lisp? Really? 
Think about it... Java... Java? You deserve what you get... ;)

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From goosey at virgo.sdc.org  Thu Nov  5 02:13:55 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Thu, 5 Nov 2009 00:13:55 -0700
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <4AF2442F.5090500@iinet.net.au>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
	<4AF2442F.5090500@iinet.net.au>
Message-ID: <20091105071355.GA2288@virgo.sdc.org>

On Thu, Nov 05, 2009 at 02:19:11PM +1100, Mark McDougall wrote:
> Again, don't let this stop any of you from starting your own Coco emulator 
> project, whether it be in C, C++, BASIC, ASM, Lisp.... OK, Lisp? Really? 
> Think about it... Java... Java? You deserve what you get... ;)

Isn't there a CoCo emulator in Java?  Mocha I think it's called?

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard


From os9dude at gmail.com  Thu Nov  5 07:37:54 2009
From: os9dude at gmail.com (Rogelio Perea)
Date: Thu, 5 Nov 2009 07:37:54 -0500
Subject: [Coco] California Digital and the Dragon
Message-ID: <5631e580911050437n3fa162e5x73901e2883a7320b@mail.gmail.com>

Recently I inquired about floppy drive pricing and availability of the
Tano/Dragon computer, following is my response. Looking forward to get a
Dragon.

No more Floppy Drives though. I have a mismatched pair of drives on my CoCo
1 setup and was trying to set it up with two same brand/model ones just for
miscellaneous reasons. So they look nice :-)


-- Rogelio


---------- Forwarded message ----------
From: <catalog at cadigital.com>
Date: Tue, Nov 3, 2009 at 3:22 PM
Subject: Re: Pricing info required: Floppy Drive and Computer
To: Rogelio Perea <os9dude at gmail.com>


No longer have 5.25" drives.

TANO DRAGONS
California Digital still has a significant amount of Tano Dragon 64
computers available in its warehouse. Original retail price was $400.
California Digital is offering the Dragon at only $45 each.  These are brand
new computers still packed in factory boxes.

Because each Dragon ships at 19 pounds, the cost of shipping is substantial.
West Coast shipping costs are approximately $20, East Coast is about $30.
Foreign: The postal service no longer offers ocean/surface transit. The
Dragon must ship either by air freight courier or air mail. Shipping cost to
the UK and most of Europe is about $90 each. WoW!

Additional information available at:
http://www.cadigital.com/computer.htm

PAYMENT: PayPal is preferred. Our payment e-mail address is:
laser at cadigital.com.
We also accept credit cards and checks.
California Digital also accept major credit cards and checks.


From johnadonaldson at sbcglobal.net  Thu Nov  5 10:24:33 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Thu, 05 Nov 2009 09:24:33 -0600
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <6.2.5.6.1.20091104165827.06254868@coco3.com>
References: <d51.5b429328.381f828a@aol.com>	<dbdeb2610911011755j1678442eh6f32cee7c9fb9a27@mail.gmail.com>
	<6.2.5.6.1.20091104165827.06254868@coco3.com>
Message-ID: <4AF2EE31.30601@sbcglobal.net>

Roger,
    It's not that. The problem is when we try to talk to a Radio shack 
person, it all goes zooming over their heads. Their brains just can not 
comprehend what we are saying, even if we say it slow and simple. So as 
not to show us that they they are that dumb they give you the "look".

John Donaldson



Roger Taylor wrote:
> At 07:55 PM 11/1/2009, you wrote:
>> Probably thought you wanted directions to Walmart and couldn't 
>> pronounce it
>> right...
>>
>> Art
>
>
>
> HAHAHAAA!!  Funniest thing this year.  I can picture them looking at 
> Roy with that "tone" they all have.  They all look at us like we're 
> talking in Clicks and Grunts like a caveman.   What SCHOOL do they go 
> to learn this behavior, anyway!??!  It's all the same no matter what 
> Shack I've been in.
>


-- 


From johnadonaldson at sbcglobal.net  Thu Nov  5 10:27:43 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Thu, 05 Nov 2009 09:27:43 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <6.2.5.6.1.20091104161016.06254348@coco3.com>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>	<4AF04444.30905@sbcglobal.net>
	<6.2.5.6.1.20091104161016.06254348@coco3.com>
Message-ID: <4AF2EEEF.2010705@sbcglobal.net>

Roger,
    It's been a long year after being out of work for 6 months. Got a 
job with a healthcare company out of San Francisco in Oct. I am working 
out of my house doing software support via telephone, VPN, and internet. 
Next year I get to do some travel overseas.

John Donaldson


Roger Taylor wrote:
> At 08:55 AM 11/3/2009, you wrote:
>> James,
>>    Doesn't Mark work for Fed-X or something like that. I can 
>> understand his long hours. I just got a package delivered byt Fed-X 
>> yesterday at 7:35PM. Which means that the driver may not get back to 
>> his depot until 9 or 10PM. Sure don't leave much time to do anything 
>> else. and with the Holidays now starting, it is only going to get 
>> longer.
>>
>> John
>
>
>
> I think you're partially recalling that I work for UPS, and not Mark 
> for FedEx?
>
>


-- 


From johnadonaldson at sbcglobal.net  Thu Nov  5 10:28:50 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Thu, 05 Nov 2009 09:28:50 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <20091105000241.GK10786@tuxdriver.com>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>	<4AF04444.30905@sbcglobal.net>	<6.2.5.6.1.20091104161016.06254348@coco3.com>
	<20091105000241.GK10786@tuxdriver.com>
Message-ID: <4AF2EF32.9030609@sbcglobal.net>

ROFLOL



John W. Linville wrote:
> On Wed, Nov 04, 2009 at 04:11:46PM -0600, Roger Taylor wrote:
>   
>> At 08:55 AM 11/3/2009, you wrote:
>>     
>>> James,
>>>    Doesn't Mark work for Fed-X or something like that. I can  
>>> understand his long hours. I just got a package delivered byt Fed-X  
>>> yesterday at 7:35PM. Which means that the driver may not get back to 
>>> his depot until 9 or 10PM. Sure don't leave much time to do anything 
>>> else. and with the Holidays now starting, it is only going to get 
>>> longer.
>>>
>>> John
>>>       
>>
>> I think you're partially recalling that I work for UPS, and not Mark for FedEx?
>>     
>
> Gaahh!  Stop!!!  No more images in my head of Mark in brown shorts
> and a ball cap!!!!
>
> :-)
>
>   


-- 


From dml_68 at yahoo.com  Thu Nov  5 18:00:18 2009
From: dml_68 at yahoo.com (Derek)
Date: Thu, 5 Nov 2009 15:00:18 -0800 (PST)
Subject: [Coco] [CoCo] Radioshack disconnect
In-Reply-To: <4AF2EE31.30601@sbcglobal.net>
Message-ID: <297555.86037.qm@web30204.mail.mud.yahoo.com>

Its not really the Radio Shack employees fault. As a company radio Shack no longer focuses on the parts and pieces like they did until the early 1990's. The employees are all now being trained to sale cell phones and wireless services. 

When I managed a Radio Shack store back in the 1980's the focus was on the components and parts (we called it "force feed") which had the higest profit margin of anything Radio Shack sold back then and also computers.

As a company that is not what Radio Shack is about anymore and if they were I would imagine they would have gone out of business a long time ago so if your local 18 year old Radio Shack Sales guy does not know how to read the colors on a resistor cut him some slack, he has not been trained to do so. Those days of Radio Shack and Heathkit stores being around and full of every tiny part and piece are sadly gone the way of the Cassette Tape, and Roof Mounted Analog TV Antennas my friends. It's ok to long for the good old days but not okay to insult the workers at Radio Shack




** Mistrust Authority. Promote Decentralization **


 

--- On Thu, 11/5/09, John Donaldson <johnadonaldson at sbcglobal.net> wrote:

From: John Donaldson <johnadonaldson at sbcglobal.net>
Subject: Re: [Coco] [CoCo] Radioshack disconnect
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Date: Thursday, November 5, 2009, 7:24 AM

Roger,
???It's not that. The problem is when we try to talk to a Radio shack person, it all goes zooming over their heads. Their brains just can not comprehend what we are saying, even if we say it slow and simple. So as not to show us that they they are that dumb they give you the "look".

John Donaldson



Roger Taylor wrote:
> At 07:55 PM 11/1/2009, you wrote:
>> Probably thought you wanted directions to Walmart and couldn't pronounce it
>> right...
>> 
>> Art
> 
> 
> 
> HAHAHAAA!!? Funniest thing this year.? I can picture them looking at Roy with that "tone" they all have.? They all look at us like we're talking in Clicks and Grunts like a caveman.???What SCHOOL do they go to learn this behavior, anyway!??!? It's all the same no matter what Shack I've been in.
> 


-- 
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From jcewy at swbell.net  Thu Nov  5 22:33:45 2009
From: jcewy at swbell.net (Joel Ewy)
Date: Thu, 05 Nov 2009 21:33:45 -0600
Subject: [Coco] 6820 and 6821 pin compatible?
Message-ID: <4AF39919.9080505@swbell.net>

I'm restoring an SWTPC 6809 computer.  I intend to run OS-9 on it.  I 
also want to try out FLEX and UNIFLEX (the latter of which I'm sure this 
computer once ran).

I've got a timer board, that I believe (judging from the OS-9 
configuration of the SWTPC emulator) provides the system clock 
interrupts.  It has a socket that, according to the documentation, once 
housed a 6820, but now sits empty.  I can probably dig up the 
documentation, but I bet somebody on this list can tell me without 
cracking a book or downloading a PDF whether or not I can just plop a 
much more readily available 6821 in there instead.

If you're interested in following my progress on this project, I've been 
blogging about it:  http://8littlebits.wordpress.com/category/swtpc/

The CoCo gets mentioned as well, and I used a CoCo emulator to make a 
boot disk image I'll eventually use when I'm ready to try and boot this 
thing up.

JCE



From lamune at doki-doki.net  Thu Nov  5 23:53:43 2009
From: lamune at doki-doki.net (Mike Pepe)
Date: Thu, 5 Nov 2009 20:53:43 -0800
Subject: [Coco] 6820 and 6821 pin compatible?
In-Reply-To: <4AF39919.9080505@swbell.net>
References: <4AF39919.9080505@swbell.net>
Message-ID: <EEA43F43D1E7444B990B271C34A079E94970ACD488@concord.lamunet.local>

Should work just fine. As I recall the major difference between the two was the 6820 had dynamic registers while the 6821 was static. But I'm sure if I'm wrong someone will chime in.

> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-
> bounces at maltedmedia.com] On Behalf Of Joel Ewy
> Sent: Thursday, November 05, 2009 7:34 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: [Coco] 6820 and 6821 pin compatible?
> 
> I'm restoring an SWTPC 6809 computer.  I intend to run OS-9 on it.  I
> also want to try out FLEX and UNIFLEX (the latter of which I'm sure
> this
> computer once ran).
> 
> I've got a timer board, that I believe (judging from the OS-9
> configuration of the SWTPC emulator) provides the system clock
> interrupts.  It has a socket that, according to the documentation, once
> housed a 6820, but now sits empty.  I can probably dig up the
> documentation, but I bet somebody on this list can tell me without
> cracking a book or downloading a PDF whether or not I can just plop a
> much more readily available 6821 in there instead.
> 
> If you're interested in following my progress on this project, I've
> been
> blogging about it:  http://8littlebits.wordpress.com/category/swtpc/
> 
> The CoCo gets mentioned as well, and I used a CoCo emulator to make a
> boot disk image I'll eventually use when I'm ready to try and boot this
> thing up.
> 
> JCE
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From aawolfe at gmail.com  Fri Nov  6 02:53:15 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 6 Nov 2009 02:53:15 -0500
Subject: [Coco] beginning os9 assembler questions
Message-ID: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>

Hi,

Sorry if these are basic questions.  I'm just getting started with os9
programming.

What is the preferred file editor?  I have scred from the developers
system and 'edit'.

Is the basic process 1 create source, 2 assemble with rma, 3 link with rlink?

I am learning from Rainbow articles and the os9 dev system manual.
Are there other books or guides I should read?

Since I am using and targeting nitros9, are there special considerations?

Thanks for advice
-Aaron


From petrander at gmail.com  Fri Nov  6 03:41:26 2009
From: petrander at gmail.com (Fedor Steeman)
Date: Fri, 6 Nov 2009 09:41:26 +0100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <4AF2442F.5090500@iinet.net.au>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
	<4AF2442F.5090500@iinet.net.au>
Message-ID: <dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>

Hi again,

WARNING: The below text contains a number of bombshells that some may regard
as flamebait!

@Willard Goosey
> Mark McDougall wrote:
> > Again, don't let this stop any of you from starting your own Coco
> emulator
> > project, whether it be in C, C++, BASIC, ASM, Lisp.... OK, Lisp? Really?
> > Think about it... Java... Java? You deserve what you get... ;)
>
> Isn't there a CoCo emulator in Java?  Mocha I think it's called?
>

Thank you for bringing this to attention. Yes, if what you get is an
emulator that can be run anywhere, anytime on any system supporting Java
without installation and right away in a browser, well I think we can be
certainly happy that someone took the initiative. That being said, using an
OO language by no means implies a "proper" OO design, but I would love to
see the source code.

@Mark McDougall
> I think it can be safely said that Fedor, Aaron and myself generally agree
> at some level; where we differ is our opinion on its suitability and
> proported benefits for a Coco emulator. And here we shall remain divided. :)
>

On the contrary, I actually agree that it is a subject of debate whether OO
is suitable for writing a CoCo emulator, as I clearly have expressed several
times now. I disagree with Aaron in that I think it is actually worth a try
for anyone to take a shot at it in any other language than "C" (blegh) and
they should not be discouraged from doing so. Something that you also, if
not at least partially, agree with.


> @Aaron Wolfe
> As I said in my first post, I think it would behoove our small
> community to focus our limited resources on projects that provide the
> most bang for the buck.  [...]
>
I don't like negativity either, *but *I feel that bad ideas that can be
> easily corrected are worth pointing out.  I'll be the first to admit
> that sometimes I am an overly critical a-hole, but honestly my
> intentions are to steer any efforts in the most beneficial direction
> for the community (and likely the individual), not to stifle them.
>

I am sorry, but if you think that you serve our small community by shooting
holes into any initiative that cannot be shoehorned into your own usual
approach to things, then you are misleading yourself. If you really want to
be the one steering any efforts in the most beneficial direction then do so
in a constructive way and do not presume that anything that conflicts with
your own way of thinking is worthless. Please don't mistake your own
personal habits and preferences with what is right and will work for
everyone.

Look, people are different and what works for one person may not work for
another. For someone who understands the workings of computer electronics
and the hardware of systems like the CoCo in and out, procedural programming
could indeed be the closest to their way of thinking and what they would
prefer for any project, and what they would be most productive with. People
like that would tend to gravitate toward highly technical, hardware-near,
embedded programming, or emulation of such, anyway, because that is what
they are most familiar with. For more intuitive programmers who think in
concepts and seek to solve outside world, human-focused problems, an
object-oriented approach would make more sense.

That is what I meant with "accessible" which was misconstrued as to mean
"easy to get your hands on". The "C" programming language does not agree
with everyone, and not everyone (I would say barely everyone) has been
educated in it, whether they are IT professionals or hobbbyists. Therefore,
it would be more than fair for them to use a platform that they themselves
prefer. I think a lot of people here are happy that no one discouraged and
stopped the development of Mocha or the like.

Which again leads me to underlining for the zillionth time that, heck, I
don't know if the OO-approach would be suitable for CoCo emulation. It would
be interesting for someone to try, 'though, and I see no reason why the
options should be narrowed to a mechanical, imperative language like C. For
most people, a natural, object-oriented language would most probably be
easier to learn, understand and remember than something like "C".

And that is another bone I still have to pick with you: The "C" programming
language has not been a part of my CS education nor of any of my buddies
that I asked. Instead, we had Java or some other OO language. One buddy, an
engineer, even thought the notion that it was required for any IT
professional to have had "absurd". He did not have a high regard of the
language BTW. Whatsmore: A cursorial googling on "computer science
curriculum" did not give me the immediate impression that any computer
language was regarded as required. Instead, of what I have read, any Object
Oriented approach was deemed required rather than a particular language.
Maybe C was prevalent in education a decade or two ago, but we have moved on
since then.

> Agreed, but whether these black boxes are objects or functions or modules
> or libraries makes little difference.
>
I disagree. Using objects allows you to group similar functionality
logically in constrained units by convention, making its use significantly
more intuitive. Procedural programming doesn?t allow this.

> I am a huge fan of abstraction, its a fundamental CS concept that predates
> OO by some tens of years.
>
That is actually not correct. There is no programming language from before
1952 (much less 1942) that uses any concept of abstraction. To my knowledge
Simula is the first programming language that introduces abstraction, and at
the same time, the first object oriented language.

> Unit testing is great.  It's yet another concept that predates and
> continues to exist outside of OO design.
>
While it?s true that you can interpret unit test to mean ?testing
functions?, it was not until the advent of OO design, applications became
complex enough that you needed unit tests You need unit tests when your
algorithm cannot be mathematically proven to be error free. Otherwise, it is
just an easier alternative to doing the math.

> I present this example as evidence that a very large project can achieve
> the same benefits that OO design provides, without using OO design.
>

No one is debating that you CAN?T write well designed, complex software
using procedural programming. You can drive a car with your feet if you want
to. That doesn?t mean it?s a good idea. Yes, I concede that a large group
can on occasion write complex, well written software in archaic languages.
But it takes an order of magnitude more time. Look at the progress other
Open Source projects have made in the last 18 years. FireFox, Eclipse, Open
Office...

> I'd hoped we could focus on the points Mr. Graham makes in his essay,
>
We could. But it would be more useful to discuss reality. Mr. Grahams
?points? are nothing but religious opinions, and every one of them is wrong.
You can?t discus OOP with someone who doesn?t even understand the basic
principles, and has a pseudo-religious predisposition that is demonstrably
wrong. It?s like discussing evolution with a creationist, astronomy with an
astrologist or dentistry with someone who believes in the tooth fairy. He
doesn?t even address a single one of the Object Oriented principles. He just
fires up a, frankly disturbingly ignorant, elitist rant about how it?s
unfair that people who don?t have to use punch cards, can?t possibly be as
hardcore as he is.

As said before, I would love to see Paul Graham develop a Word Processor or
the like using one of his pet languages.

 > If a methodology can keep bad programmers on the right track, imagine
>> what a
>
>  > highly-skilled programmer might achieve with it! Wait, no need to
>> imagine,
>> > it is alreay happening all around us! :-)
>
>   That's like saying, "if training wheels keep a kid from falling over
> on their bike, imagine what Lance Armstrong could do if he installed
> them on his racing bikes".  bad logic.
>
> Bad analogy. Mediocre programmers are not like kids just learning to bike
compared to professional sportsbicyclers. Besides, I get the general
impression that you are only hearing half of my argumentation.
Highly-skilled programmers are already achieving a lot of great work using
OO D/P, which was my main point.

> I don't think any of those experts would argue that OO design is always the
> best way to write software,
>
 But that is also what I have emphatically been stating all the time! I just
oppose the view that it is generally useless, as it clearly is not.

> or the only way to achieve the benefits attributed to OO design.
>
I strongly doubt they would ever agree to that there never was any need to
invent OO design.  :-D

Cheers,

Fedor Steeman


From aawolfe at gmail.com  Fri Nov  6 04:12:22 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 6 Nov 2009 04:12:22 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
	<4AF2442F.5090500@iinet.net.au>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
Message-ID: <e44ad6640911060112x682967a4kaf86bb6683ae13d0@mail.gmail.com>

Taking a clue from our beloved CoCo, I will just say

OK

-Aaron


On Fri, Nov 6, 2009 at 3:41 AM, Fedor Steeman <petrander at gmail.com> wrote:
> Hi again,
>
> WARNING: The below text contains a number of bombshells that some may regard
> as flamebait!
>
> @Willard Goosey
>> Mark McDougall wrote:
>> > Again, don't let this stop any of you from starting your own Coco
>> emulator
>> > project, whether it be in C, C++, BASIC, ASM, Lisp.... OK, Lisp? Really?
>> > Think about it... Java... Java? You deserve what you get... ;)
>>
>> Isn't there a CoCo emulator in Java? ?Mocha I think it's called?
>>
>
> Thank you for bringing this to attention. Yes, if what you get is an
> emulator that can be run anywhere, anytime on any system supporting Java
> without installation and right away in a browser, well I think we can be
> certainly happy that someone took the initiative. That being said, using an
> OO language by no means implies a "proper" OO design, but I would love to
> see the source code.
>
> @Mark McDougall
>> I think it can be safely said that Fedor, Aaron and myself generally agree
>> at some level; where we differ is our opinion on its suitability and
>> proported benefits for a Coco emulator. And here we shall remain divided. :)
>>
>
> On the contrary, I actually agree that it is a subject of debate whether OO
> is suitable for writing a CoCo emulator, as I clearly have expressed several
> times now. I disagree with Aaron in that I think it is actually worth a try
> for anyone to take a shot at it in any other language than "C" (blegh) and
> they should not be discouraged from doing so. Something that you also, if
> not at least partially, agree with.
>
>
>> @Aaron Wolfe
>> As I said in my first post, I think it would behoove our small
>> community to focus our limited resources on projects that provide the
>> most bang for the buck. ?[...]
>>
> I don't like negativity either, *but *I feel that bad ideas that can be
>> easily corrected are worth pointing out. ?I'll be the first to admit
>> that sometimes I am an overly critical a-hole, but honestly my
>> intentions are to steer any efforts in the most beneficial direction
>> for the community (and likely the individual), not to stifle them.
>>
>
> I am sorry, but if you think that you serve our small community by shooting
> holes into any initiative that cannot be shoehorned into your own usual
> approach to things, then you are misleading yourself. If you really want to
> be the one steering any efforts in the most beneficial direction then do so
> in a constructive way and do not presume that anything that conflicts with
> your own way of thinking is worthless. Please don't mistake your own
> personal habits and preferences with what is right and will work for
> everyone.
>
> Look, people are different and what works for one person may not work for
> another. For someone who understands the workings of computer electronics
> and the hardware of systems like the CoCo in and out, procedural programming
> could indeed be the closest to their way of thinking and what they would
> prefer for any project, and what they would be most productive with. People
> like that would tend to gravitate toward highly technical, hardware-near,
> embedded programming, or emulation of such, anyway, because that is what
> they are most familiar with. For more intuitive programmers who think in
> concepts and seek to solve outside world, human-focused problems, an
> object-oriented approach would make more sense.
>
> That is what I meant with "accessible" which was misconstrued as to mean
> "easy to get your hands on". The "C" programming language does not agree
> with everyone, and not everyone (I would say barely everyone) has been
> educated in it, whether they are IT professionals or hobbbyists. Therefore,
> it would be more than fair for them to use a platform that they themselves
> prefer. I think a lot of people here are happy that no one discouraged and
> stopped the development of Mocha or the like.
>
> Which again leads me to underlining for the zillionth time that, heck, I
> don't know if the OO-approach would be suitable for CoCo emulation. It would
> be interesting for someone to try, 'though, and I see no reason why the
> options should be narrowed to a mechanical, imperative language like C. For
> most people, a natural, object-oriented language would most probably be
> easier to learn, understand and remember than something like "C".
>
> And that is another bone I still have to pick with you: The "C" programming
> language has not been a part of my CS education nor of any of my buddies
> that I asked. Instead, we had Java or some other OO language. One buddy, an
> engineer, even thought the notion that it was required for any IT
> professional to have had "absurd". He did not have a high regard of the
> language BTW. Whatsmore: A cursorial googling on "computer science
> curriculum" did not give me the immediate impression that any computer
> language was regarded as required. Instead, of what I have read, any Object
> Oriented approach was deemed required rather than a particular language.
> Maybe C was prevalent in education a decade or two ago, but we have moved on
> since then.
>
>> Agreed, but whether these black boxes are objects or functions or modules
>> or libraries makes little difference.
>>
> I disagree. Using objects allows you to group similar functionality
> logically in constrained units by convention, making its use significantly
> more intuitive. Procedural programming doesn?t allow this.
>
>> I am a huge fan of abstraction, its a fundamental CS concept that predates
>> OO by some tens of years.
>>
> That is actually not correct. There is no programming language from before
> 1952 (much less 1942) that uses any concept of abstraction. To my knowledge
> Simula is the first programming language that introduces abstraction, and at
> the same time, the first object oriented language.
>
>> Unit testing is great. ?It's yet another concept that predates and
>> continues to exist outside of OO design.
>>
> While it?s true that you can interpret unit test to mean ?testing
> functions?, it was not until the advent of OO design, applications became
> complex enough that you needed unit tests You need unit tests when your
> algorithm cannot be mathematically proven to be error free. Otherwise, it is
> just an easier alternative to doing the math.
>
>> I present this example as evidence that a very large project can achieve
>> the same benefits that OO design provides, without using OO design.
>>
>
> No one is debating that you CAN?T write well designed, complex software
> using procedural programming. You can drive a car with your feet if you want
> to. That doesn?t mean it?s a good idea. Yes, I concede that a large group
> can on occasion write complex, well written software in archaic languages.
> But it takes an order of magnitude more time. Look at the progress other
> Open Source projects have made in the last 18 years. FireFox, Eclipse, Open
> Office...
>
>> I'd hoped we could focus on the points Mr. Graham makes in his essay,
>>
> We could. But it would be more useful to discuss reality. Mr. Grahams
> ?points? are nothing but religious opinions, and every one of them is wrong.
> You can?t discus OOP with someone who doesn?t even understand the basic
> principles, and has a pseudo-religious predisposition that is demonstrably
> wrong. It?s like discussing evolution with a creationist, astronomy with an
> astrologist or dentistry with someone who believes in the tooth fairy. He
> doesn?t even address a single one of the Object Oriented principles. He just
> fires up a, frankly disturbingly ignorant, elitist rant about how it?s
> unfair that people who don?t have to use punch cards, can?t possibly be as
> hardcore as he is.
>
> As said before, I would love to see Paul Graham develop a Word Processor or
> the like using one of his pet languages.
>
> ?> If a methodology can keep bad programmers on the right track, imagine
>>> what a
>>
>> ?> highly-skilled programmer might achieve with it! Wait, no need to
>>> imagine,
>>> > it is alreay happening all around us! :-)
>>
>> ? That's like saying, "if training wheels keep a kid from falling over
>> on their bike, imagine what Lance Armstrong could do if he installed
>> them on his racing bikes". ?bad logic.
>>
>> Bad analogy. Mediocre programmers are not like kids just learning to bike
> compared to professional sportsbicyclers. Besides, I get the general
> impression that you are only hearing half of my argumentation.
> Highly-skilled programmers are already achieving a lot of great work using
> OO D/P, which was my main point.
>
>> I don't think any of those experts would argue that OO design is always the
>> best way to write software,
>>
> ?But that is also what I have emphatically been stating all the time! I just
> oppose the view that it is generally useless, as it clearly is not.
>
>> or the only way to achieve the benefits attributed to OO design.
>>
> I strongly doubt they would ever agree to that there never was any need to
> invent OO design. ?:-D
>
> Cheers,
>
> Fedor Steeman
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From jimhrubik at earthlink.net  Fri Nov  6 07:22:43 2009
From: jimhrubik at earthlink.net (James Hrubik)
Date: Fri, 6 Nov 2009 07:22:43 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
	<4AF2442F.5090500@iinet.net.au>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
Message-ID: <CA834022-CC16-4CC5-A931-895D98325E00@earthlink.net>

Aw, c'mon, people.  This was interesting, even to someone who hasn't  
written any code in several decades, but once you start picking at  
each other, it needs to go into private email.

On Nov 6, 2009, at Friday, November 6, 2009 - 3:41 AM, Fedor Steeman  
wrote:

> Hi again,
>
> WARNING: The below text contains a number of bombshells that some  
> may regard
> as flamebait!
>
> @Willard Goosey
>>
>> @Mark McDougall
>>> I think it can be safely said that Fedor, Aaron and myself  
>>> generally agree
>>> at some level; where we differ is our opinion on its suitability and
>>> proported benefits for a Coco emulator. And here we shall remain  
>>> divided. :)
>>>
>>>> @Aaron Wolfe
>>>> As I said in my first post, I think it would behoove our small
>>>> community to focus our limited resources on projects that  
>>>> provide the
>>>> most bang for the buck.  [...]
>>>
>>

*** [[[===]]] ***
Obstructionist : a lemming who refuses to hurry.
*** [[[===]]] ***
 From the Sayings of Grampa Jim, Copyright 2009.
Unauthorized use of my stuff may cause senility.
*** [[[===]]] ***
email : jimhrubik at earthlink.net
info : http://www.hrubikappraisal.com
blog1 : http://hrubikappraisal.blogspot.com
blog2 : http://grandpa-jim.blogspot.com



From snhirsch at gmail.com  Fri Nov  6 07:52:25 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Fri, 6 Nov 2009 07:52:25 -0500 (EST)
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AEF68A7.6060308@iinet.net.au>
	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>
	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>
	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>
	<4AF2442F.5090500@iinet.net.au>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0911060740040.5952@duo>

On Fri, 6 Nov 2009, Fedor Steeman wrote:

> And that is another bone I still have to pick with you: The "C" programming
> language has not been a part of my CS education nor of any of my buddies
> that I asked. Instead, we had Java or some other OO language. One buddy, an
> engineer, even thought the notion that it was required for any IT
> professional to have had "absurd".

Personally, I find the notion of CS graduates with no practical exposure 
to low-level machine issues (assembler or C) to be somewhat absurd. 
Perhaps this points out the difference in concept between "IT 
Professional" and "computer scientist" or "software engineer"?  It's not 
my intention to be demeaning to anyone, just take this as acknowledgement 
that the field has fragmented and specialized quite a bit.

> Maybe C was prevalent in education a decade or two ago, but we have moved on
> since then.

Well, "we" may have moved on, but down at the metal the machines still 
work the old-fashioned way with messy things like registers, memory 
references, cache-misses and the like.  I'm sure it's possible to have a 
florishing career designing web sites, enterprise-level database systems, 
etc. without ever being exposed to computer internals.  But, please, let's 
not call that "computer science".

Just my 0.02.

Steve


-- 


From gene.heskett at verizon.net  Fri Nov  6 08:45:48 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Fri, 06 Nov 2009 08:45:48 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <alpine.DEB.2.00.0911060740040.5952@duo>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
	<alpine.DEB.2.00.0911060740040.5952@duo>
Message-ID: <200911060845.48792.gene.heskett@verizon.net>

On Friday 06 November 2009, Steven Hirsch wrote:
>On Fri, 6 Nov 2009, Fedor Steeman wrote:
>> And that is another bone I still have to pick with you: The "C"
>> programming language has not been a part of my CS education nor of any of
>> my buddies that I asked. Instead, we had Java or some other OO language.
>> One buddy, an engineer, even thought the notion that it was required for
>> any IT professional to have had "absurd".

I have to agree with this.

Many years ago I got into it with Paul Jerkatis, who was trying to build rzsz 
on an emulator, and he could not see the simple logic in replacing a long 
string of 16 single bit shifts with the carry that made up an 8 bit shift 
with a tfr a,b' cleara or vice versa for the other direction.  But that made 
about a 75 cps improvement in the speed of that protocol.  He finally gave up 
because he wouldn't use c.prep19, and the stock c.prep falls over when the 
srcs exceed about 12k.  rzsz srcs are about 33k for each.

The upshot is that the rzsz-3.36 we have today was built on my machine, using 
all of the improvements to the c compiler we had.  And it runs about 440 cps 
on the 6809, and about 735 cps in the 6309.  Without the optimizations, its 
up against the wall at about 230 cps on the 6809.

Those optimizations were done to the output of c.pass2, before feeding it on 
to the rest of the compiler.

The CS guys, and I believe Paul had a degree, were lost in assembly.  
Totally.

>Personally, I find the notion of CS graduates with no practical exposure
>to low-level machine issues (assembler or C) to be somewhat absurd.
>Perhaps this points out the difference in concept between "IT
>Professional" and "computer scientist" or "software engineer"?  It's not
>my intention to be demeaning to anyone, just take this as acknowledgement
>that the field has fragmented and specialized quite a bit.
>
>> Maybe C was prevalent in education a decade or two ago, but we have moved
>> on since then.
>
>Well, "we" may have moved on, but down at the metal the machines still
>work the old-fashioned way with messy things like registers, memory
>references, cache-misses and the like.  I'm sure it's possible to have a
>florishing career designing web sites, enterprise-level database systems,
>etc. without ever being exposed to computer internals.  But, please, let's
>not call that "computer science".
>
>Just my 0.02.
>
>Steve
>


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

I have yet to see any problem, however complicated, which, when
you looked at it in the right way, did not become still more complicated.
		-- Poul Anderson


From boisy at tee-boy.com  Fri Nov  6 08:51:44 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Fri, 6 Nov 2009 07:51:44 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF03361.1218.FCC7E@jdaggett.gate.net>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>
	<4AF03361.1218.FCC7E@jdaggett.gate.net>
Message-ID: <2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>

Guys,

I tried sending an email to orders at cloud9tech.com and did not get the  
email back, which indicates to me that there is something  
misconfigured somewhere in our mail routing system.  Mark is currently  
on vacation right now and won't be back in range for a week or so;  
we'll investigate and see what's going on.

Boisy

On Nov 3, 2009, at 7:42 AM, jdaggett at gate.net wrote:

> Chad
>
> Mark came onto the list with an email in early September and stated  
> that vacations and work
> has ate time away from answering emails, even time on this list and  
> fulfilling his orders with
> Cloud9. I kind of know what he maybe going through at his regular  
> job. Considering his work
> has lost 2/3rds of the employees due to layoffs, you are somewhat at  
> the mercy of your
> employer as to work hours. It is hell to do the same amount of work  
> with less people for any
> length of time. Very long hours and not much time for anything else.  
> Let alone the family.
>
> Remember Cloud9 is not Mark's prime source of income. It is done for  
> a love of the Coco
> and the community.
>
> james
>
> On 2 Nov 2009 at 22:49, Chad H wrote:
>
>> Is the Cloud-9 tech site/shop down?  I've e-mailed them twice to
>> orders at cloud9tech.com per the info on their ORDERS page but I have  
>> yet to
>> received a reply back.  Hope they aren't going away.
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From robert.gault at worldnet.att.net  Fri Nov  6 09:37:07 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Fri, 06 Nov 2009 09:37:07 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
Message-ID: <4AF43493.2050103@worldnet.att.net>

Aaron Wolfe wrote:
> Hi,
>
> Sorry if these are basic questions.  I'm just getting started with os9
> programming.
>
> What is the preferred file editor?  I have scred from the developers
> system and 'edit'.
>
> Is the basic process 1 create source, 2 assemble with rma, 3 link with rlink?
>
> I am learning from Rainbow articles and the os9 dev system manual.
> Are there other books or guides I should read?
>
> Since I am using and targeting nitros9, are there special considerations?
>
> Thanks for advice
> -Aaron
>

I'm sure you will get lots of opinions on this. :)

I use scred and asm almost exclusively on a real Coco when programming 
in assembly for OS-9. I've also done some C programming which forces the 
use of a linker.

Now that we can easily transfer files from a PC to a Coco or even run 
files stored on a PC with Drivewire or Roger's programs, you could use 
any full screen editor to create source. You can even assemble the 
source first on the PC.


From chadbh74 at hotmail.com  Fri Nov  6 09:34:55 2009
From: chadbh74 at hotmail.com (Chad H)
Date: Fri, 6 Nov 2009 08:34:55 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>	<4AF03361.1218.FCC7E@jdaggett.gate.net>
	<2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>
Message-ID: <COL103-DS9060E875E810260736ADFC8AF0@phx.gbl>

Yes, I first tried the orders at cloud9tech.com, then the info at cloud9tech.com.
Still nothing yet.

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Boisy G. Pitre
Sent: Friday, November 06, 2009 7:52 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Cloud-9 Tech

Guys,

I tried sending an email to orders at cloud9tech.com and did not get the  
email back, which indicates to me that there is something  
misconfigured somewhere in our mail routing system.  Mark is currently  
on vacation right now and won't be back in range for a week or so;  
we'll investigate and see what's going on.

Boisy

On Nov 3, 2009, at 7:42 AM, jdaggett at gate.net wrote:

> Chad
>
> Mark came onto the list with an email in early September and stated  
> that vacations and work
> has ate time away from answering emails, even time on this list and  
> fulfilling his orders with
> Cloud9. I kind of know what he maybe going through at his regular  
> job. Considering his work
> has lost 2/3rds of the employees due to layoffs, you are somewhat at  
> the mercy of your
> employer as to work hours. It is hell to do the same amount of work  
> with less people for any
> length of time. Very long hours and not much time for anything else.  
> Let alone the family.
>
> Remember Cloud9 is not Mark's prime source of income. It is done for  
> a love of the Coco
> and the community.
>
> james
>
> On 2 Nov 2009 at 22:49, Chad H wrote:
>
>> Is the Cloud-9 tech site/shop down?  I've e-mailed them twice to
>> orders at cloud9tech.com per the info on their ORDERS page but I have  
>> yet to
>> received a reply back.  Hope they aren't going away.
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From jdaggett at gate.net  Fri Nov  6 13:27:12 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Fri, 06 Nov 2009 13:27:12 -0500
Subject: [Coco] 6820 and 6821 pin compatible?
In-Reply-To: <4AF39919.9080505@swbell.net>
References: <4AF39919.9080505@swbell.net>
Message-ID: <4AF46A80.28484.18820C@jdaggett.gate.net>

Joel

The MC6820/ MC6821/ MC6822 all have the same pinouts. They differ in how the ports are 
constructed. Softwarewise they interface the same to either the MC6800/ MC6802/ MC6809 
processors. 

james 

On 5 Nov 2009 at 21:33, Joel Ewy wrote:

> I'm restoring an SWTPC 6809 computer.  I intend to run OS-9 on it.  I 
> also want to try out FLEX and UNIFLEX (the latter of which I'm sure this 
> computer once ran).
> 
> I've got a timer board, that I believe (judging from the OS-9 
> configuration of the SWTPC emulator) provides the system clock 
> interrupts.  It has a socket that, according to the documentation, once 
> housed a 6820, but now sits empty.  I can probably dig up the 
> documentation, but I bet somebody on this list can tell me without 
> cracking a book or downloading a PDF whether or not I can just plop a 
> much more readily available 6821 in there instead.
> 
> If you're interested in following my progress on this project, I've been 
> blogging about it:  http://8littlebits.wordpress.com/category/swtpc/
> 
> The CoCo gets mentioned as well, and I used a CoCo emulator to make a 
> boot disk image I'll eventually use when I'm ready to try and boot this 
> thing up.
> 
> JCE
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco




From jdaggett at gate.net  Fri Nov  6 13:28:01 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Fri, 06 Nov 2009 13:28:01 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>
References: <COL103-DS59484805405E23849FD79C8B20@phx.gbl>,
	<4AF03361.1218.FCC7E@jdaggett.gate.net>,
	<2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>
Message-ID: <4AF46AB1.13467.1940F7@jdaggett.gate.net>

On 6 Nov 2009 at 7:51, Boisy G. Pitre wrote:

> Guys,
> 
> I tried sending an email to orders at cloud9tech.com and did not get the  
> email back, which indicates to me that there is something  
> misconfigured somewhere in our mail routing system.  Mark is currently  
> on vacation right now and won't be back in range for a week or so;  
> we'll investigate and see what's going on.
> 
> Boisy


Thank You Boisy for the info.

james 


From aawolfe at gmail.com  Fri Nov  6 13:38:51 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 6 Nov 2009 13:38:51 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <200911060845.48792.gene.heskett@verizon.net>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
	<alpine.DEB.2.00.0911060740040.5952@duo>
	<200911060845.48792.gene.heskett@verizon.net>
Message-ID: <e44ad6640911061038g6e78b207x854b2d1c2266feb0@mail.gmail.com>

On Fri, Nov 6, 2009 at 8:45 AM, Gene Heskett <gene.heskett at verizon.net> wrote:
> On Friday 06 November 2009, Steven Hirsch wrote:
>>On Fri, 6 Nov 2009, Fedor Steeman wrote:
>>> And that is another bone I still have to pick with you: The "C"
>>> programming language has not been a part of my CS education nor of any of
>>> my buddies that I asked. Instead, we had Java or some other OO language.
>>> One buddy, an engineer, even thought the notion that it was required for
>>> any IT professional to have had "absurd".
>


I had promised myself I would not comment any more on this, but that
was in part because I thought no one else was interested.  Seeing
discussion, on this one point I will make an exception.  (I never have
learned to hold my tongue very well :)

Here is what I actually said:

> C is taught in every CS program I've heard of at least.  Some C
> experience is generally considered a prerequisite for any serious
> programmer, professional or hobbyist.

Although I fully stand behind the words that I said, I don't like the
straw man created by Mr. Steeman.

I never suggested that a particular language was a requirement to
receive a degree in CS, I said it was taught in every CS program I
knew of.  I believe most CS programs allow one to chose the languages
they study, mines certainly did.  C *is* taught at MIT, Standford, and
Berkeley this year, according to their web sites.

I also fully believe that "Some C experience is generally considered a
prerequisite for any serious programmer, professional or hobbyist."
Notice I did not say "IT Professional" or "Engineer".  I said
*programmer*.  Notice also I said "some C experience", not mastery,
specialization in, exclusive use of, etc.

"C" is indeed very popular today, in fact its arguably the most
popular programming language on the planet.  Java may be (probably is)
slightly more popular depending on the metric you choose:
http://www.langpop.com/

The goal of my original statement was to assert that C is more
"accessible" to the average programmer than the proprietary, closed
language that Mr Steeman was championing.  To that end, I believe I
have made my point very well.

-Aaron


From asa.rand at yahoo.com  Fri Nov  6 14:37:57 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 6 Nov 2009 11:37:57 -0800 (PST)
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
Message-ID: <732986.33918.qm@web53706.mail.re2.yahoo.com>



>Sorry if these are basic questions.  I'm just getting started with os9
programming.

>What is the preferred file editor?  I have scred from the developers
system and 'edit'.

Edit is a line editor. Scred is a screen oriented editor. I think scred is the editor of choice, though I have never used it.

>Is the basic process 1 create source, 2 assemble with rma, 3 link with rlink?

Yes

>I am learning from Rainbow articles and the os9 dev system manual.
Are there other books or guides I should read?

I downloaded a copy of the Motorola 6809 programming manual. It contains all you need to know about the 6809s registers and the assembly mnemonics for it

>Since I am using and targeting nitros9, are there special considerations?

I'm not qualified to answer this question, but I believe there are significant differences between OS-9 and NitrOS-9. I know that some of the commands have different parameters between the OS-9 version and the NitrOS-9 version. Also, the 6309 contains additional instructions not found in the 6809. NitrOS-9 makes use of these, where OS-9 does not.

Hope this helps.

Wayne


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From jdaggett at gate.net  Fri Nov  6 14:46:30 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Fri, 06 Nov 2009 14:46:30 -0500
Subject: [Coco] 6820 and 6821 pin compatible?
In-Reply-To: <EEA43F43D1E7444B990B271C34A079E94970ACD488@concord.lamunet.local>
References: <4AF39919.9080505@swbell.net>,
	<EEA43F43D1E7444B990B271C34A079E94970ACD488@concord.lamunet.local>
Message-ID: <4AF47D16.14022.611C79@jdaggett.gate.net>

On 5 Nov 2009 at 20:53, Mike Pepe wrote:

> Should work just fine. As I recall the major difference between the two was the 6820 had dynamic registers while the 6821 was static. But I'm sure if I'm wrong someone will chime in.
> 


Mike

You maybe right, though I seem to remember something about the port sink and source 
currents were not very strong and the part blew port pins. Though I could be wrong as this 
recollection dates back now almost 30 yrs. I think the MC6820 was discontinued in very early 
80's. 

I do know that the MC6822 differed in that the ports were open drain and would work with 
voltages upwards to 15VDC. 

james



> > -----Original Message-----
> > From: coco-bounces at maltedmedia.com [mailto:coco-
> > bounces at maltedmedia.com] On Behalf Of Joel Ewy
> > Sent: Thursday, November 05, 2009 7:34 PM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: [Coco] 6820 and 6821 pin compatible?
> > 
> > I'm restoring an SWTPC 6809 computer.  I intend to run OS-9 on it.  I
> > also want to try out FLEX and UNIFLEX (the latter of which I'm sure
> > this
> > computer once ran).
> > 
> > I've got a timer board, that I believe (judging from the OS-9
> > configuration of the SWTPC emulator) provides the system clock
> > interrupts.  It has a socket that, according to the documentation, once
> > housed a 6820, but now sits empty.  I can probably dig up the
> > documentation, but I bet somebody on this list can tell me without
> > cracking a book or downloading a PDF whether or not I can just plop a
> > much more readily available 6821 in there instead.
> > 
> > If you're interested in following my progress on this project, I've
> > been
> > blogging about it:  http://8littlebits.wordpress.com/category/swtpc/
> > 
> > The CoCo gets mentioned as well, and I used a CoCo emulator to make a
> > boot disk image I'll eventually use when I'm ready to try and boot this
> > thing up.
> > 
> > JCE
> > 
> > 
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco




From curtisboyle at sasktel.net  Fri Nov  6 15:49:28 2009
From: curtisboyle at sasktel.net (L. Curtis Boyle)
Date: Fri, 06 Nov 2009 14:49:28 -0600
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <732986.33918.qm@web53706.mail.re2.yahoo.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
Message-ID: <op.u2zqsqcrmuougd@optimal-creations-computer.local>

On Fri, 06 Nov 2009 13:37:57 -0600, Wayne Campbell <asa.rand at yahoo.com>  
wrote:

>
>
>> Sorry if these are basic questions.  I'm just getting started with os9
> programming.
>
>> What is the preferred file editor?  I have scred from the developers
> system and 'edit'.
>
> Edit is a line editor. Scred is a screen oriented editor. I think scred  
> is the editor of choice, though I have never used it.

There are several other screen editors you can get for free (SLED is one  
that comes
to mind), but SCRED has the advantage of being able to edit files larger  
than it's
buffer. A favourite (commercial) editor that most of the original NitrOS9  
team used
was VED by Bob van der Poel.

>
>> Is the basic process 1 create source, 2 assemble with rma, 3 link with  
>> rlink?
>
> Yes
>
>> I am learning from Rainbow articles and the os9 dev system manual.
> Are there other books or guides I should read?
>
> I downloaded a copy of the Motorola 6809 programming manual. It contains  
> all you need to know about the 6809s registers and the assembly  
> mnemonics for it
>
>> Since I am using and targeting nitros9, are there special  
>> considerations?
>
> I'm not qualified to answer this question, but I believe there are  
> significant differences between OS-9 and NitrOS-9. I know that some of  
> the commands have different parameters between the OS-9 version and the  
> NitrOS-9 version. Also, the 6309 contains additional instructions not  
> found in the 6809. NitrOS-9 makes use of these, where OS-9 does not.

The current builds of NitrOS-9 support 6809 as well, with some of the Extra
SYSCALL's, etc. Definitely have the Level II manual, the SYSCALL section,
handy.




-- 
L. Curtis Boyle


From jcewy at swbell.net  Fri Nov  6 16:07:42 2009
From: jcewy at swbell.net (Joel Ewy)
Date: Fri, 06 Nov 2009 15:07:42 -0600
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
Message-ID: <4AF4901E.1080404@swbell.net>

Aaron Wolfe wrote:
> Hi,
>
> Sorry if these are basic questions.  I'm just getting started with os9
> programming.
>
> What is the preferred file editor?  I have scred from the developers
> system and 'edit'.
>   

I liked VED, and also TSEDIT with the 'vi' patch.  The latter is nice if 
you are already familiar with vi.

JCE

> Is the basic process 1 create source, 2 assemble with rma, 3 link with rlink?
>
> I am learning from Rainbow articles and the os9 dev system manual.
> Are there other books or guides I should read?
>
> Since I am using and targeting nitros9, are there special considerations?
>
> Thanks for advice
> -Aaron
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>   



From aawolfe at gmail.com  Fri Nov  6 17:15:22 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 6 Nov 2009 17:15:22 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <4AF43493.2050103@worldnet.att.net>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<4AF43493.2050103@worldnet.att.net>
Message-ID: <e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>

On Fri, Nov 6, 2009 at 9:37 AM, Robert Gault
<robert.gault at worldnet.att.net> wrote:
> Aaron Wolfe wrote:
>>
>> Hi,
>>
>> Sorry if these are basic questions. ?I'm just getting started with os9
>> programming.
>>
>> What is the preferred file editor? ?I have scred from the developers
>> system and 'edit'.
>>
>> Is the basic process 1 create source, 2 assemble with rma, 3 link with
>> rlink?
>>
>> I am learning from Rainbow articles and the os9 dev system manual.
>> Are there other books or guides I should read?
>>
>> Since I am using and targeting nitros9, are there special considerations?
>>
>> Thanks for advice
>> -Aaron
>>
>
> I'm sure you will get lots of opinions on this. :)
>
> I use scred and asm almost exclusively on a real Coco when programming in
> assembly for OS-9. I've also done some C programming which forces the use of
> a linker.
>
> Now that we can easily transfer files from a PC to a Coco or even run files
> stored on a PC with Drivewire or Roger's programs, you could use any full
> screen editor to create source. You can even assemble the source first on
> the PC.
>

Thanks for the info.  I have a drivewire rompak + cable, actually this
is my only storage at the moment.  When you say that we can now run
files stored on a PC or assemble the source on the PC, do you mean in
an emulator?  Or is there some way to directly edit files in a CoCo
disk image with (for instance) a Windows file editor like notepad?  I
store the disk images used by drivewire on my PC, but I don't know how
to access the files inside those images except by mounting the image
in an emulator or to a coco via drivewire.  Can I actually get into
them with the host PC?  That would be interesting.

> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From lothan at newsguy.com  Fri Nov  6 17:24:49 2009
From: lothan at newsguy.com (Lothan)
Date: Fri, 6 Nov 2009 17:24:49 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <732986.33918.qm@web53706.mail.re2.yahoo.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
Message-ID: <DDDE7D171727486693AAFA695C2C1CD9@Crossfire>

Where did you find a copy of the Motorola 6809 programming manual? I was 
looking for it the other day but couldn't find it. Of course, I can't 
overlook that I might have been a complete idiot in my search. ;-)
 



From brucewcalkins at charter.net  Fri Nov  6 18:03:36 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Fri, 6 Nov 2009 18:03:36 -0500
Subject: [Coco] beginning os9 assembler questions
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com><4AF43493.2050103@worldnet.att.net>
	<e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>
Message-ID: <E374AC12BBAD4D609382DB65746F55FF@speedy>

> When you say that we can now run files 
> stored on a PC or assemble the source on 
> the PC, do you mean in an emulator?  
==================================

Goto coco3-dot-com and look up Rainbow IDE.

Bruce W.


From linville at tuxdriver.com  Fri Nov  6 19:29:38 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Fri, 6 Nov 2009 19:29:38 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
Message-ID: <20091107002938.GA23501@tuxdriver.com>

On Fri, Nov 06, 2009 at 05:24:49PM -0500, Lothan wrote:
> Where did you find a copy of the Motorola 6809 programming manual? I was  
> looking for it the other day but couldn't find it. Of course, I can't  
> overlook that I might have been a complete idiot in my search. ;-)

This looks promising...

	http://www.maddes.net/m6809pm/

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From robert.gault at worldnet.att.net  Fri Nov  6 19:36:51 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Fri, 06 Nov 2009 19:36:51 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>	<4AF43493.2050103@worldnet.att.net>
	<e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>
Message-ID: <4AF4C123.4040707@worldnet.att.net>

Aaron Wolfe wrote:

> Thanks for the info.  I have a drivewire rompak + cable, actually this
> is my only storage at the moment.  When you say that we can now run
> files stored on a PC or assemble the source on the PC, do you mean in
> an emulator?  Or is there some way to directly edit files in a CoCo
> disk image with (for instance) a Windows file editor like notepad?  I
> store the disk images used by drivewire on my PC, but I don't know how
> to access the files inside those images except by mounting the image
> in an emulator or to a coco via drivewire.  Can I actually get into
> them with the host PC?  That would be interesting.
>

As an example, I can create a source file with RainbowIDE or even 
Microsoft work, put the file on a .dsk or .os9 disk image, mount the 
file with Drivewire, and then either run the binary or assemble the 
source from my Coco3.
RainbowIDE will automatically use imgtool.exe or a Toolshed program 
(decb.exe or os9.exe) to put the files on a disk image. The same tools 
can be used to add files to an image manually.

If you don't want to use a Coco at all, then you can use the emulators 
VCC or MESS to run or assemble files.


From linville at tuxdriver.com  Fri Nov  6 19:35:10 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Fri, 6 Nov 2009 19:35:10 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <20091107002938.GA23501@tuxdriver.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
	<20091107002938.GA23501@tuxdriver.com>
Message-ID: <20091107003510.GB23501@tuxdriver.com>

On Fri, Nov 06, 2009 at 07:29:38PM -0500, John W. Linville wrote:
> On Fri, Nov 06, 2009 at 05:24:49PM -0500, Lothan wrote:
> > Where did you find a copy of the Motorola 6809 programming manual? I was  
> > looking for it the other day but couldn't find it. Of course, I can't  
> > overlook that I might have been a complete idiot in my search. ;-)
> 
> This looks promising...
> 
> 	http://www.maddes.net/m6809pm/

Actually, this does too...

	http://www.classiccmp.org/dunfield/r/6809prog.pdf

Hth!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From msmcdoug at iinet.net.au  Fri Nov  6 20:34:12 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Sat, 07 Nov 2009 12:34:12 +1100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <alpine.DEB.2.00.0911060740040.5952@duo>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>	<4AEF68A7.6060308@iinet.net.au>	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>	<4AF2442F.5090500@iinet.net.au>	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
	<alpine.DEB.2.00.0911060740040.5952@duo>
Message-ID: <4AF4CE94.2070304@iinet.net.au>

Steven Hirsch wrote:

> Perhaps this points out the difference in concept between "IT 
> Professional" and "computer scientist" or "software engineer"?  It's not 
> my intention to be demeaning to anyone, just take this as 
> acknowledgement that the field has fragmented and specialized quite a bit.

You make a good point, and again, without being demeaning to anyone, I think 
there has always been, and always will be, a clear distinction between 
"computer scientist", "software engineer" and "programmer".

I see myself as perhaps being formerly the latter, and more recently the 
2nd. And there's not a lot of people that could truly claim to be the 1st.

I studied computer science as my 1st degree, and despite the name of my 
course, I was well and truly a "programmer" for the first few years in the 
workforce. A few years later I returned to study Electrical Engineering, and 
since then I see myself more as a "software engineer".

IMHO, a "programmer" is someone who generally has a specialisation, and is 
mostly concerned with the design and coding of "applications". It is more 
true today than ever before, given the ever broadening discipline of 
computer programming, encompassing everything from micros, mobile platforms, 
to desktop pc to distributed computing across intranets, wans and the global 
internet. And of course we need specialist programmers, just like we need 
specialist doctors.

A "software engineer" OTOH, is more of a "jack of all trades" and whose work 
generally spans a reasonable variety of platforms, architectures and 
technologies. Their work involves not only occasional application 
development, but also device drivers, utilities and other low-level tasks 
like kernel tweaking, interrupt processing, hacking startup code, etc.

Of course, each SE has their own preferred "bag of tricks" and will usually 
tackle a problem in their preferred domain, but it's not unusual to have to 
roll up the sleeves and learn another language/API/platform to do the job at 
hand. So the job requires a more intimate level of knowledge "under the 
hood" than a traditional IT programming job.

For the record, a "computer scientist" is someone who lives in academia and 
tinkers with things in the name of (computer) "science" rather than solving 
a commercial problem.

I'm not holding these definitions up as "gospel" - it's just the way that I 
see it.

And to tie into the original point of this rant - I see universities 
churning out "programmers" rather than "software engineers" these days. 
That's not a criticism in itself, but I do wonder how long it will be before 
the art of "software engineering" starts to become lost in the world of 
Java, PHP, Phyton scripts, CSS, HTML and all that guff. ;)

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From gene.heskett at verizon.net  Fri Nov  6 21:51:58 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Fri, 06 Nov 2009 21:51:58 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <4AF4901E.1080404@swbell.net>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<4AF4901E.1080404@swbell.net>
Message-ID: <200911062151.59041.gene.heskett@verizon.net>

On Friday 06 November 2009, Joel Ewy wrote:
>Aaron Wolfe wrote:
>> Hi,
>>
>> Sorry if these are basic questions.  I'm just getting started with os9
>> programming.
>>
>> What is the preferred file editor?  I have scred from the developers
>> system and 'edit'.
>
>I liked VED, and also TSEDIT with the 'vi' patch.  The latter is nice if
>you are already familiar with vi.
>
Yes, arguably the best unless one needs files bigger than a #56k buffer will 
hold.  When running on the newest nitros9, it has to be renamed both 
internally and in the directory entry because vi clashes with the vi window 
descriptor.  I didn't have a copy of ed around, so now my copy is called 
'ed'.  More than one way to skin that cat. ;-)  Or as one wag said a year or 
so ago, "so many cats, so few good recipes..."

>JCE
>
>> Is the basic process 1 create source, 2 assemble with rma, 3 link with
>> rlink?
>>
>> I am learning from Rainbow articles and the os9 dev system manual.
>> Are there other books or guides I should read?
>>
>> Since I am using and targeting nitros9, are there special considerations?
>>
>> Thanks for advice
>> -Aaron
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

serendipity, n.:
	The process by which human knowledge is advanced.


From gene.heskett at verizon.net  Fri Nov  6 21:54:57 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Fri, 06 Nov 2009 21:54:57 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
Message-ID: <200911062154.57581.gene.heskett@verizon.net>

On Friday 06 November 2009, Lothan wrote:
>Where did you find a copy of the Motorola 6809 programming manual? I was
>looking for it the other day but couldn't find it. Of course, I can't
>overlook that I might have been a complete idiot in my search. ;-)
>
Try googling for "motorola 6809 programmers manual".

I haven't tried that as I managed by buy it on paper about 2 decades ago.  
And no, its not for sale, untill I fall over. ;)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

_Rosin_ core solder? But...


From msmcdoug at iinet.net.au  Fri Nov  6 22:23:45 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Sat, 07 Nov 2009 14:23:45 +1100
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <4AF4CE94.2070304@iinet.net.au>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>	<4AEF68A7.6060308@iinet.net.au>	<e44ad6640911022244s80c3a30r6dc52525ec968410@mail.gmail.com>	<dcc956220911031536p3c9d6a61ob40ba7c340dd7758@mail.gmail.com>	<e44ad6640911031707j6da9866ag589d8805b5e271a9@mail.gmail.com>	<4AF2442F.5090500@iinet.net.au>	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>	<alpine.DEB.2.00.0911060740040.5952@duo>
	<4AF4CE94.2070304@iinet.net.au>
Message-ID: <4AF4E841.4070104@iinet.net.au>

Mark McDougall wrote:

> I studied computer science as my 1st degree, and despite the name of my 
> course, I was well and truly a "programmer" for the first few years in 
> the workforce. A few years later I returned to study Electrical 
> Engineering, and since then I see myself more as a "software engineer".

To add a comment or two...

My best mate did the _same_ Computer Science degree as me back in '84. He 
has worked as a "programmer" for over 20 years now, but is ignorant of 
pretty much anything outside the sphere of his work experience. It would 
take him 6 weeks to get a LED blinking on an 8051 dev kit. In fact, he 
struggles installing windows on his own PC. Though to be fair, he has always 
been bone lazy, never interested in learning anything for himself, and would 
rather phone me to ask a question than type a few search terms into Google.

My wife took a print-out of a directory listing into work to give to a 
colleague (a list of video files to be exact). One of the IT guys there - at 
an IT company no less - saw that it was a list of files, and remarked "WOW, 
how did you do that?" :O

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"


From asa.rand at yahoo.com  Fri Nov  6 22:29:11 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 6 Nov 2009 19:29:11 -0800 (PST)
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
Message-ID: <159766.51423.qm@web53707.mail.re2.yahoo.com>

>Where did you find a copy of the Motorola 6809 programming manual? I was looking for it the other day but couldn't find it. Of course, I can't overlook that I might have been a complete idiot in my search. ;-)


Look here:
http://www.maddes.net/m6809pm/

The page has a link to FreeScale and directions to get to the page. There are many 6809-relate materials available for download there.

Wayne



      


From aawolfe at gmail.com  Fri Nov  6 23:18:43 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 6 Nov 2009 23:18:43 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <e44ad6640911061038g6e78b207x854b2d1c2266feb0@mail.gmail.com>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<dcc956220911060041t46a50a8cuf6414741a74ffab4@mail.gmail.com>
	<alpine.DEB.2.00.0911060740040.5952@duo>
	<200911060845.48792.gene.heskett@verizon.net>
	<e44ad6640911061038g6e78b207x854b2d1c2266feb0@mail.gmail.com>
Message-ID: <e44ad6640911062018v6a042a8pf156547b24ba5766@mail.gmail.com>

On Fri, Nov 6, 2009 at 1:38 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Fri, Nov 6, 2009 at 8:45 AM, Gene Heskett <gene.heskett at verizon.net> wrote:
>> On Friday 06 November 2009, Steven Hirsch wrote:
>>>On Fri, 6 Nov 2009, Fedor Steeman wrote:
>>>> And that is another bone I still have to pick with you: The "C"
>>>> programming language has not been a part of my CS education nor of any of
>>>> my buddies that I asked. Instead, we had Java or some other OO language.
>>>> One buddy, an engineer, even thought the notion that it was required for
>>>> any IT professional to have had "absurd".
>>
>
>
> I had promised myself I would not comment any more on this, but that
> was in part because I thought no one else was interested. ?Seeing
> discussion, on this one point I will make an exception. ?(I never have
> learned to hold my tongue very well :)
>
> Here is what I actually said:
>
>> C is taught in every CS program I've heard of at least. ?Some C
>> experience is generally considered a prerequisite for any serious
>> programmer, professional or hobbyist.
>
> Although I fully stand behind the words that I said, I don't like the
> straw man created by Mr. Steeman.
>
> I never suggested that a particular language was a requirement to
> receive a degree in CS, I said it was taught in every CS program I
> knew of. ?I believe most CS programs allow one to chose the languages
> they study, mines certainly did. ?C *is* taught at MIT, Standford, and
> Berkeley this year, according to their web sites.
>
> I also fully believe that "Some C experience is generally considered a
> prerequisite for any serious programmer, professional or hobbyist."

My friend was reading this thread with me and pointed out, quite
correctly, that my first statement was ambiguous and quite possibly
caused some confusion.  Unfortunately the kind of thing that only
stands out to others, no matter how many times I try to proof my own
words :(

I meant to say "any serious programmer, whether that programmer is a
professional or a hobbyist".  What I said could easily be taken to
mean "any programer, any professional, or any hobbyist", which is not
at all what I meant.  I apologize, my words were not very well chosen.
 In hindsight, some of the comments make a little more sense now,
after realizing my mistake :)


> Notice I did not say "IT Professional" or "Engineer". ?I said
> *programmer*. ?Notice also I said "some C experience", not mastery,
> specialization in, exclusive use of, etc.
>
> "C" is indeed very popular today, in fact its arguably the most
> popular programming language on the planet. ?Java may be (probably is)
> slightly more popular depending on the metric you choose:
> http://www.langpop.com/
>
> The goal of my original statement was to assert that C is more
> "accessible" to the average programmer than the proprietary, closed
> language that Mr Steeman was championing. ?To that end, I believe I
> have made my point very well.
>
> -Aaron
>


From gene.heskett at verizon.net  Fri Nov  6 23:54:56 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Fri, 06 Nov 2009 23:54:56 -0500
Subject: [Coco] OO programming - [Was]:Emulator
In-Reply-To: <4AF4E841.4070104@iinet.net.au>
References: <dcc956220911020619n389ddbdar71e507093f6667fc@mail.gmail.com>
	<4AF4CE94.2070304@iinet.net.au> <4AF4E841.4070104@iinet.net.au>
Message-ID: <200911062354.56250.gene.heskett@verizon.net>

On Friday 06 November 2009, Mark McDougall wrote:
>Mark McDougall wrote:
>> I studied computer science as my 1st degree, and despite the name of my
>> course, I was well and truly a "programmer" for the first few years in
>> the workforce. A few years later I returned to study Electrical
>> Engineering, and since then I see myself more as a "software engineer".
>
>To add a comment or two...
>
>My best mate did the _same_ Computer Science degree as me back in '84. He
>has worked as a "programmer" for over 20 years now, but is ignorant of
>pretty much anything outside the sphere of his work experience. It would
>take him 6 weeks to get a LED blinking on an 8051 dev kit. In fact, he
>struggles installing windows on his own PC. Though to be fair, he has
> always been bone lazy, never interested in learning anything for himself,
> and would rather phone me to ask a question than type a few search terms
> into Google.
>
>My wife took a print-out of a directory listing into work to give to a
>colleague (a list of video files to be exact). One of the IT guys there -
> at an IT company no less - saw that it was a list of files, and remarked
> "WOW, how did you do that?" :O
>
>Regards,
>
And they live among us. Good Grief!

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

Life is the childhood of our immortality.
		-- Goethe


From coco+list at jeanpaulsamson.com  Sat Nov  7 00:42:03 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Fri, 6 Nov 2009 22:42:03 -0700
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
Message-ID: <06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>

On Nov-6-09, at 3:24 PM, Lothan wrote:
> Where did you find a copy of the Motorola 6809 programming manual? I  
> was looking for it the other day but couldn't find it. Of course, I  
> can't overlook that I might have been a complete idiot in my  
> search. ;-)

I put together an improved copy of the MC6809-MC6809E Microprocessor  
Programming Manual in PDF format.  My copy, weighing in at 4MB,  
includes bookmarks and is searchable, unlike all the other versions  
I've seen around.  You can find it here:

<https://docs.google.com/fileview?id=0B5WL6q8cbexONTcwNzQzMTMtZTdkOS00ZGY3LWE5NTAtMWFmZjY0ZmMxYmFm&hl=en 
 >

-- JP



From aawolfe at gmail.com  Sat Nov  7 00:55:31 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sat, 7 Nov 2009 00:55:31 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
	<06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
Message-ID: <e44ad6640911062155n5ae86b8fhec016500e5d63712@mail.gmail.com>

On Sat, Nov 7, 2009 at 12:42 AM, J.P. Samson
<coco+list at jeanpaulsamson.com> wrote:
> On Nov-6-09, at 3:24 PM, Lothan wrote:
>>
>> Where did you find a copy of the Motorola 6809 programming manual? I was
>> looking for it the other day but couldn't find it. Of course, I can't
>> overlook that I might have been a complete idiot in my search. ;-)
>
> I put together an improved copy of the MC6809-MC6809E Microprocessor
> Programming Manual in PDF format. ?My copy, weighing in at 4MB, includes
> bookmarks and is searchable, unlike all the other versions I've seen around.
> ?You can find it here:
>
> <https://docs.google.com/fileview?id=0B5WL6q8cbexONTcwNzQzMTMtZTdkOS00ZGY3LWE5NTAtMWFmZjY0ZmMxYmFm&hl=en>
>

nice!  thanks.

> -- JP
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Sat Nov  7 02:42:16 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sat, 7 Nov 2009 02:42:16 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<4AF43493.2050103@worldnet.att.net>
	<e44ad6640911061415l505845f0jc4b982ee510aff5e@mail.gmail.com>
Message-ID: <e44ad6640911062342i359eb777x773d95cfc704723a@mail.gmail.com>

I just discovered the "Toolshed" tools.  I think this changes
everything, and answers some of my questions below.

It looks like we have an assembler/linker and disk image management
tools that run on linux, how awesome!

Sorry to have asked questions I could have answered myself, I am so
new that I sometimes just don't know where to look.

-Aaron

On Fri, Nov 6, 2009 at 5:15 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Fri, Nov 6, 2009 at 9:37 AM, Robert Gault
> <robert.gault at worldnet.att.net> wrote:
>> Aaron Wolfe wrote:
>>>
>>> Hi,
>>>
>>> Sorry if these are basic questions. ?I'm just getting started with os9
>>> programming.
>>>
>>> What is the preferred file editor? ?I have scred from the developers
>>> system and 'edit'.
>>>
>>> Is the basic process 1 create source, 2 assemble with rma, 3 link with
>>> rlink?
>>>
>>> I am learning from Rainbow articles and the os9 dev system manual.
>>> Are there other books or guides I should read?
>>>
>>> Since I am using and targeting nitros9, are there special considerations?
>>>
>>> Thanks for advice
>>> -Aaron
>>>
>>
>> I'm sure you will get lots of opinions on this. :)
>>
>> I use scred and asm almost exclusively on a real Coco when programming in
>> assembly for OS-9. I've also done some C programming which forces the use of
>> a linker.
>>
>> Now that we can easily transfer files from a PC to a Coco or even run files
>> stored on a PC with Drivewire or Roger's programs, you could use any full
>> screen editor to create source. You can even assemble the source first on
>> the PC.
>>
>
> Thanks for the info. ?I have a drivewire rompak + cable, actually this
> is my only storage at the moment. ?When you say that we can now run
> files stored on a PC or assemble the source on the PC, do you mean in
> an emulator? ?Or is there some way to directly edit files in a CoCo
> disk image with (for instance) a Windows file editor like notepad? ?I
> store the disk images used by drivewire on my PC, but I don't know how
> to access the files inside those images except by mounting the image
> in an emulator or to a coco via drivewire. ?Can I actually get into
> them with the host PC? ?That would be interesting.
>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>


From brucewcalkins at charter.net  Sat Nov  7 07:22:15 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Sat, 7 Nov 2009 07:22:15 -0500
Subject: [Coco] beginning os9 assembler questions
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com><732986.33918.qm@web53706.mail.re2.yahoo.com><DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
	<06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
Message-ID: <5D7489AAFE3A46169A78F376F80CE020@speedy>

> I put together an improved copy of the MC6809-MC6809E Microprocessor 
> Programming Manual in PDF format.  My copy, weighing in at 4MB,  includes 
> bookmarks and is searchable, unlike all the other versions  I've seen 
> around.  You can find it here:
>
> <https://docs.google.com/fileview?id=0B5WL6q8cbexONTcwNzQzMTMtZTdkOS00ZGY3LWE5NTAtMWFmZjY0ZmMxYmFm&hl=en
> >
>
> -- JP
=====================================


Unfortunately that does not seem to be downloadable without getting spammed 
and cookied.



Bruce W.





From dml_68 at yahoo.com  Sat Nov  7 08:31:03 2009
From: dml_68 at yahoo.com (Derek)
Date: Sat, 7 Nov 2009 05:31:03 -0800 (PST)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <2F981C43-FE67-4D6C-A6E3-257202D81357@tee-boy.com>
Message-ID: <776499.83014.qm@web30201.mail.mud.yahoo.com>

> Remember Cloud9 is not Mark's prime source of income. It is done for a love of the Coco
> and the community.

I mean no disrespect to the folks at cloud 9 and have even purchased my 512K Ram upgrade from them but if you going to run a business there is a right way and a wrong way to do it. If there are problems with filling orders you should at least post on your web page about possible delays or reply back to your customers about how long the delay will be. It sounds like a few folks have emailed but got no reply back and they have had to post here or on coco3.com to get an answer.





      


From snhirsch at gmail.com  Sat Nov  7 08:49:38 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Sat, 7 Nov 2009 08:49:38 -0500 (EST)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <776499.83014.qm@web30201.mail.mud.yahoo.com>
References: <776499.83014.qm@web30201.mail.mud.yahoo.com>
Message-ID: <alpine.DEB.2.00.0911070848510.5952@duo>

On Sat, 7 Nov 2009, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done for a 
>> love of the Coco and the community.
>
> I mean no disrespect to the folks at cloud 9 and have even purchased my 
> 512K Ram upgrade from them but if you going to run a business there is a 
> right way and a wrong way to do it. If there are problems with filling 
> orders you should at least post on your web page about possible delays 
> or reply back to your customers about how long the delay will be. It 
> sounds like a few folks have emailed but got no reply back and they have 
> had to post here or on coco3.com to get an answer.

Boisy posted in the last day or so and indicated that there may be a 
problem with Cloud9's e-mail system.  It's quite possible the messages 
weren't making it to the inbox!


-- 


From jimhrubik at earthlink.net  Sat Nov  7 08:53:27 2009
From: jimhrubik at earthlink.net (James Hrubik)
Date: Sat, 7 Nov 2009 08:53:27 -0500
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <e44ad6640911062155n5ae86b8fhec016500e5d63712@mail.gmail.com>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com>
	<732986.33918.qm@web53706.mail.re2.yahoo.com>
	<DDDE7D171727486693AAFA695C2C1CD9@Crossfire>
	<06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
	<e44ad6640911062155n5ae86b8fhec016500e5d63712@mail.gmail.com>
Message-ID: <C56A0712-A0A2-4108-944A-2A7149E71087@earthlink.net>

Really nice!  Much cleaner than the one at Freescale.

On Nov 7, 2009, at Saturday, November 7, 2009 - 12:55 AM, Aaron Wolfe  
wrote:

> On Sat, Nov 7, 2009 at 12:42 AM, J.P. Samson
> <coco+list at jeanpaulsamson.com> wrote:
>> On Nov-6-09, at 3:24 PM, Lothan wrote:
>>>
>>> Where did you find a copy of the Motorola 6809 programming  
>>> manual? I was
>>> looking for it the other day but couldn't find it. Of course, I  
>>> can't
>>> overlook that I might have been a complete idiot in my search. ;-)
>>
>> I put together an improved copy of the MC6809-MC6809E Microprocessor
>> Programming Manual in PDF format.  My copy, weighing in at 4MB,  
>> includes
>> bookmarks and is searchable, unlike all the other versions I've  
>> seen around.
>>  You can find it here:
>>
>> <https://docs.google.com/fileview? 
>> id=0B5WL6q8cbexONTcwNzQzMTMtZTdkOS00ZGY3LWE5NTAtMWFmZjY0ZmMxYmFm&hl=e 
>> n>
>>
>
> nice!  thanks.
>
>> -- JP
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

*** [[[===]]] ***
Obstructionist : a lemming who refuses to hurry.
*** [[[===]]] ***
 From the Sayings of Grampa Jim, Copyright 2009.
Unauthorized use of my stuff may cause senility.
*** [[[===]]] ***
email : jimhrubik at earthlink.net
info : http://www.hrubikappraisal.com
blog1 : http://hrubikappraisal.blogspot.com
blog2 : http://grandpa-jim.blogspot.com



From brucewcalkins at charter.net  Sat Nov  7 08:57:49 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Sat, 7 Nov 2009 08:57:49 -0500
Subject: [Coco] Cloud-9 Tech
References: <776499.83014.qm@web30201.mail.mud.yahoo.com>
Message-ID: <8D7C1BEDE2B249E3B962BD20212C3126@speedy>







>> Remember Cloud9 is not Mark's prime source of income. It is done for a 
>> love of the Coco
>> and the community.
>
> I mean no disrespect to the folks at cloud 9 and have even purchased my 
> 512K Ram upgrade from them but if you going to run a business there is a 
> right way and a wrong way to do it. If there are problems with filling 
> orders you should at least post on your web page about possible delays or 
> reply back to your customers about how long the delay will be. It sounds 
> like a few folks have emailed but got no reply back and they have had to 
> post here or on coco3.com to get an answer.
>
>



It is a HOBBY and must be addressed as such. One cannot give 200% to a hobby 
and survive.  Mark does get to his orders in time; however he has a life and 
job that have to take precedence to his hobby.



A little patience does wonders.  The quality of Mark's hobby is worth a 
little time.



Bruce W.







From boisy at tee-boy.com  Sat Nov  7 10:05:35 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sat, 7 Nov 2009 09:05:35 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <776499.83014.qm@web30201.mail.mud.yahoo.com>
References: <776499.83014.qm@web30201.mail.mud.yahoo.com>
Message-ID: <4BFFC1B5-D68A-49CA-B4AF-15A4822D521E@tee-boy.com>

Mark really should address this since Cloud-9 is his business and I  
sell my products through him, but since he's on vacation, I'll respond.

I think your message doesn't convey a sense of disrespect as much as  
it does an ignorance of how Cloud-9's business is handled.

Cloud-9 order fulfillment works this way: Mark buys software product  
in bulk from me and stocks those products at Lab North.  As orders  
come in, they are evaluated.  If it's a purely software order, I'll  
fulfill it here at Lab South, since I have the capacity to make the  
software products.  If it's a mixture of hardware and software, Mark  
will fulfill it at Lab North.  We do this to prevent having to ship  
from two different locations for the same order.

That's why some folks get packages sent from Minnesota, others from  
Louisiana.

When Mark is away (he and I stay in touch regularly, so I know his  
schedule), I will fill orders that I can.  For those that I can't,  
I'll inform the customer of the delay.  When Mark gets back in zone,  
he takes care of those orders.

Sometimes we go an extended time without getting orders, so it's not  
unusual to have quiet periods without emails. As a result, when things  
break, like the email seems to have, we don't notice it right away.   
Since Mark handles the IT stuff (email routing, knows passwords, etc),  
he will have to return before the situation becomes rectified.

Aside from all this, Mark has a busy life these days, and he's given a  
glimpse of what's going on in his life in prior messages.

Now from this point onward, I'll speak for myself.

Between managing and running my own successful business, attending  
graduate school, running a household and seeing after all of the other  
goings on in my life, the CoCo is really way down on the list of  
priorities.  Sorry if that hurts, but that's the facts.   I have less  
time and more commitments  on my plate than ever, and the revenue that  
I obtain from Cloud-9 is infinitesimal compared to my other sources of  
income.

There's an equation that I derived some years back that describes my  
philosophy on how I spend my time.  I call it "Boisy's Formula of  
Probability of Continued Effort." This is my formula; it works for me:

P = V / (E*T*H))

Where:
	P is the probability of continued effort for a given task;
	V is the value that I obtain out of doing the task (value can be in  
the form of money, food, or even something as intrinsic as happiness  
and fulfillment);
	E is the level of effort required to generate that value;
	T is the amount of time I have to spend doing the task;
	H is the hassle factor that comes along with performing the task.

The goal is to maximize V while minimizing E, T and H, thus keeping P  
at or above 1.  High values of P are very, very good.

For everything I spend my time doing, I apply this formula in my  
head.  And it answers a basic question: "Is this worth my time?"  For  
my work in the CoCo, V, E and T are pretty much constants, with the  
large majority of V being enjoyment of the hobby and the positive  
interactions I get with the majority of our customers and friends.   
Very little of V is in the form of monetary compensation.

Without a doubt, Mark and I have built a great network of friends and  
customers through Cloud-9, and I appreciate their business and  
support.  They keep the value of V pretty high, but it's the value of  
H that I watch carefully.  It increases when I have to write long  
emails like this one when I would rather be doing something else on a  
Saturday morning.  It increases when people wrongly assume that we are  
ignoring them and then send nasty emails.  It increases when my time  
gets taken advantage of by others without fair compensation or under  
false pretenses.

Thanks for listening!

On Nov 7, 2009, at 7:31 AM, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done  
>> for a love of the Coco
>> and the community.
>
> I mean no disrespect to the folks at cloud 9 and have even purchased  
> my 512K Ram upgrade from them but if you going to run a business  
> there is a right way and a wrong way to do it. If there are problems  
> with filling orders you should at least post on your web page about  
> possible delays or reply back to your customers about how long the  
> delay will be. It sounds like a few folks have emailed but got no  
> reply back and they have had to post here or on coco3.com to get an  
> answer.
>
>
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From chadbh74 at hotmail.com  Sat Nov  7 10:14:26 2009
From: chadbh74 at hotmail.com (Chad H)
Date: Sat, 7 Nov 2009 09:14:26 -0600
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <5D7489AAFE3A46169A78F376F80CE020@speedy>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com><732986.33918.qm@web53706.mail.re2.yahoo.com><DDDE7D171727486693AAFA695C2C1CD9@Crossfire>	<06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
	<5D7489AAFE3A46169A78F376F80CE020@speedy>
Message-ID: <COL103-DS21159AD99908398B9E3590C8AE0@phx.gbl>

Hope JP doesn't mind, I took the liberty of mirroring the document on my
MediaFire account since I had a google email to download his copy.  In fact,
I think I'll re-establish something along the lines I once had with my old
CoCo repository.  This place is different, they don't put limits on how much
you upload/download, just so long as the individual files are less than
100MB with the free account.  Now I just have start finding gathering
everything up again.

http://www.mediafire.com/?sharekey=68e17cac65480f62312dbd5f2bdc506259d51908b
933078687095ac91101628c

- Chad

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Bruce W. Calkins
Sent: Saturday, November 07, 2009 6:22 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] beginning os9 assembler questions

> I put together an improved copy of the MC6809-MC6809E Microprocessor 
> Programming Manual in PDF format.  My copy, weighing in at 4MB,  includes 
> bookmarks and is searchable, unlike all the other versions  I've seen 
> around.  You can find it here:
>
>
<https://docs.google.com/fileview?id=0B5WL6q8cbexONTcwNzQzMTMtZTdkOS00ZGY3LW
E5NTAtMWFmZjY0ZmMxYmFm&hl=en
> >
>
> -- JP
=====================================


Unfortunately that does not seem to be downloadable without getting spammed 
and cookied.



Bruce W.




--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From dml_68 at yahoo.com  Sat Nov  7 11:49:52 2009
From: dml_68 at yahoo.com (Derek)
Date: Sat, 7 Nov 2009 08:49:52 -0800 (PST)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4BFFC1B5-D68A-49CA-B4AF-15A4822D521E@tee-boy.com>
Message-ID: <37939.60399.qm@web30203.mail.mud.yahoo.com>

As I said last year on the email list because of the way you treat customers and your attitude that we are all ignorant and a hassle to deal with is why I will never again purchase from Cloud-9 as long as your part of the company. Every time you reply to a product or service question it is done in a way that shows a total lack of respect for people and that fine,. I respect your right to feel the way you do and to express yourself. I reserve the right to not do business with your company until how you treat people changes. 

My budget for my vintage computing hobby is not large but I can tell you I have bypassed your company's products this past year in favor for expansions and accessories for other vintage platforms because every time I have gone to possibly place an order for Drive wire or the Super IDE controller I remember how you have treated me and others on the email list in the past and I just cant bring myself to do business with you.







** Mistrust Authority. Promote Decentralization **


 

--- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:

From: Boisy G. Pitre <boisy at tee-boy.com>
Subject: Re: [Coco] Cloud-9 Tech
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Date: Saturday, November 7, 2009, 7:05 AM

Mark really should address this since Cloud-9 is his business and I sell my products through him, but since he's on vacation, I'll respond.

I think your message doesn't convey a sense of disrespect as much as it does an ignorance of how Cloud-9's business is handled.

Cloud-9 order fulfillment works this way: Mark buys software product in bulk from me and stocks those products at Lab North.? As orders come in, they are evaluated.? If it's a purely software order, I'll fulfill it here at Lab South, since I have the capacity to make the software products.? If it's a mixture of hardware and software, Mark will fulfill it at Lab North.? We do this to prevent having to ship from two different locations for the same order.

That's why some folks get packages sent from Minnesota, others from Louisiana.

When Mark is away (he and I stay in touch regularly, so I know his schedule), I will fill orders that I can.? For those that I can't, I'll inform the customer of the delay.? When Mark gets back in zone, he takes care of those orders.

Sometimes we go an extended time without getting orders, so it's not unusual to have quiet periods without emails. As a result, when things break, like the email seems to have, we don't notice it right away.? Since Mark handles the IT stuff (email routing, knows passwords, etc), he will have to return before the situation becomes rectified.

Aside from all this, Mark has a busy life these days, and he's given a glimpse of what's going on in his life in prior messages.

Now from this point onward, I'll speak for myself.

Between managing and running my own successful business, attending graduate school, running a household and seeing after all of the other goings on in my life, the CoCo is really way down on the list of priorities.? Sorry if that hurts, but that's the facts.???I have less time and more commitments? on my plate than ever, and the revenue that I obtain from Cloud-9 is infinitesimal compared to my other sources of income.

There's an equation that I derived some years back that describes my philosophy on how I spend my time.? I call it "Boisy's Formula of Probability of Continued Effort." This is my formula; it works for me:

P = V / (E*T*H))

Where:
??? P is the probability of continued effort for a given task;
??? V is the value that I obtain out of doing the task (value can be in the form of money, food, or even something as intrinsic as happiness and fulfillment);
??? E is the level of effort required to generate that value;
??? T is the amount of time I have to spend doing the task;
??? H is the hassle factor that comes along with performing the task.

The goal is to maximize V while minimizing E, T and H, thus keeping P at or above 1.? High values of P are very, very good.

For everything I spend my time doing, I apply this formula in my head.? And it answers a basic question: "Is this worth my time?"? For my work in the CoCo, V, E and T are pretty much constants, with the large majority of V being enjoyment of the hobby and the positive interactions I get with the majority of our customers and friends.? Very little of V is in the form of monetary compensation.

Without a doubt, Mark and I have built a great network of friends and customers through Cloud-9, and I appreciate their business and support.? They keep the value of V pretty high, but it's the value of H that I watch carefully.? It increases when I have to write long emails like this one when I would rather be doing something else on a Saturday morning.? It increases when people wrongly assume that we are ignoring them and then send nasty emails.? It increases when my time gets taken advantage of by others without fair compensation or under false pretenses.

Thanks for listening!

On Nov 7, 2009, at 7:31 AM, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done for a love of the Coco
>> and the community.
> 
> I mean no disrespect to the folks at cloud 9 and have even purchased my 512K Ram upgrade from them but if you going to run a business there is a right way and a wrong way to do it. If there are problems with filling orders you should at least post on your web page about possible delays or reply back to your customers about how long the delay will be. It sounds like a few folks have emailed but got no reply back and they have had to post here or on coco3.com to get an answer.
> 
> 
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From RJRTTY at aol.com  Sat Nov  7 11:53:31 2009
From: RJRTTY at aol.com (RJRTTY at aol.com)
Date: Sat, 7 Nov 2009 11:53:31 EST
Subject: [Coco] Cloud-9 Tech
Message-ID: <d63.45dcaf39.3827000b@aol.com>

In a message dated 11/7/2009 10:07:34 A.M. Eastern Standard Time,  
boisy at tee-boy.com writes:



>There's an equation that I derived some years back that describes  my  
>philosophy on how I spend my time.  I call it "Boisy's  Formula of  
>Probability of Continued Effort." This is my formula;  it works for me:

>P = V /  (E*T*H))

>Where:
>    P is the probability of  continued effort for a given task;
>    V is the value that  I obtain out of doing the task (value can be in  
>the form of money,  food, or even something as intrinsic as happiness  
>and  fulfillment);
>    E is the level of effort required to  generate that value;
>    T is the amount of time I have to  spend doing the task;
>    H is the hassle factor that  comes along with performing the task.
>
>The goal is to maximize V  while minimizing E, T and H, thus keeping P  
>at or above 1.   High values of P are very, very good.
 
 
 
HAAAA!! HA HA !!!!   :P
 
Boisy you have spent too much time in the ivory towers
of academia and I know exactly what you are talking about.
I just haven't heard anybody put it quit so precisely.
 
Life gets in my way of filling orders too and sometimes
you have to let it go for awhile to take care of more important
business.
 
Its no secret I make no money on my projects but that's
ok because I do it for the experience and making new 
friends.   My recent decision to raise prices reflects
the passing of that phase of my little business.
Now I charge enough to offset costs plus a little more.
I also save everybody's emails and get to them when I
can.   
 
I am extremely satisfied with all my cloud 9 enhancements
and have nothing but praise for the way you and Mark
have operated your coco business.
 
May you have maximum V and minimum H factors in
your Formula of Probability of Continued Effort and thanks for  lifting
my mood this morning.....
 
Roy
 


From boisy at tee-boy.com  Sat Nov  7 12:23:44 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sat, 7 Nov 2009 11:23:44 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <37939.60399.qm@web30203.mail.mud.yahoo.com>
References: <37939.60399.qm@web30203.mail.mud.yahoo.com>
Message-ID: <762A83A8-B967-4CDC-A145-4BC6FB85F20F@tee-boy.com>

I certainly do remember the email to which you are referring.

Some of your past messages to this list show that you are no charm  
bracelet yourself.  Unlike you, however, I've built a rapport with  
many people in this community face to face, going back almost two  
decades.  Since 1992, I have put my money where my mouth is and  
attended CoCoFests, interacting with fellow users and customers (the  
ones who go, anyway).  I don't recall seeing you there.

Whatever chip that you have on your shoulder about me can stay firmly  
planted, but I dare say that anyone who has purchased a product from  
me has been treated with the utmost respect.  Your assertion that I  
treat my customers as though they are ignorant is patently false.  
People who spend their money with me will get my time and assistance,  
and I'll do everything I can within reason to help them.

So feel free to bring up my lack of respect on a case by case basis  
and I'll be happy to answer them, one by one.

I'm a rather cut and dry person; I speak my mind, and I don't mince  
words.  I attribute it in part to my Cajun upbringing and the  
bluntness that I was exposed to growing up.  That comes across to some  
as curt and rude to some.

Anyhow, suite yourself about not buying my products. As you stated  
yourself your hobby isn't large, so I won't go broke missing your  
business...  I'll survive somehow.

By the way, if you truly feel that way, then I presume you're not  
using DriveWire either, even though it's free, right?

Have yourself a great weekend!


On Nov 7, 2009, at 10:49 AM, Derek wrote:

> As I said last year on the email list because of the way you treat  
> customers and your attitude that we are all ignorant and a hassle to  
> deal with is why I will never again purchase from Cloud-9 as long as  
> your part of the company. Every time you reply to a product or  
> service question it is done in a way that shows a total lack of  
> respect for people and that fine,. I respect your right to feel the  
> way you do and to express yourself. I reserve the right to not do  
> business with your company until how you treat people changes.
>
> My budget for my vintage computing hobby is not large but I can tell  
> you I have bypassed your company's products this past year in favor  
> for expansions and accessories for other vintage platforms because  
> every time I have gone to possibly place an order for Drive wire or  
> the Super IDE controller I remember how you have treated me and  
> others on the email list in the past and I just cant bring myself to  
> do business with you.
>
>
>
>
>
>
>
> ** Mistrust Authority. Promote Decentralization **
>
>
>
>
> --- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>
> From: Boisy G. Pitre <boisy at tee-boy.com>
> Subject: Re: [Coco] Cloud-9 Tech
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Date: Saturday, November 7, 2009, 7:05 AM
>
> Mark really should address this since Cloud-9 is his business and I  
> sell my products through him, but since he's on vacation, I'll  
> respond.
>
> I think your message doesn't convey a sense of disrespect as much as  
> it does an ignorance of how Cloud-9's business is handled.
>
> Cloud-9 order fulfillment works this way: Mark buys software product  
> in bulk from me and stocks those products at Lab North.  As orders  
> come in, they are evaluated.  If it's a purely software order, I'll  
> fulfill it here at Lab South, since I have the capacity to make the  
> software products.  If it's a mixture of hardware and software, Mark  
> will fulfill it at Lab North.  We do this to prevent having to ship  
> from two different locations for the same order.
>
> That's why some folks get packages sent from Minnesota, others from  
> Louisiana.
>
> When Mark is away (he and I stay in touch regularly, so I know his  
> schedule), I will fill orders that I can.  For those that I can't,  
> I'll inform the customer of the delay.  When Mark gets back in zone,  
> he takes care of those orders.
>
> Sometimes we go an extended time without getting orders, so it's not  
> unusual to have quiet periods without emails. As a result, when  
> things break, like the email seems to have, we don't notice it right  
> away.  Since Mark handles the IT stuff (email routing, knows  
> passwords, etc), he will have to return before the situation becomes  
> rectified.
>
> Aside from all this, Mark has a busy life these days, and he's given  
> a glimpse of what's going on in his life in prior messages.
>
> Now from this point onward, I'll speak for myself.
>
> Between managing and running my own successful business, attending  
> graduate school, running a household and seeing after all of the  
> other goings on in my life, the CoCo is really way down on the list  
> of priorities.  Sorry if that hurts, but that's the facts.   I have  
> less time and more commitments  on my plate than ever, and the  
> revenue that I obtain from Cloud-9 is infinitesimal compared to my  
> other sources of income.
>
> There's an equation that I derived some years back that describes my  
> philosophy on how I spend my time.  I call it "Boisy's Formula of  
> Probability of Continued Effort." This is my formula; it works for me:
>
> P = V / (E*T*H))
>
> Where:
>     P is the probability of continued effort for a given task;
>     V is the value that I obtain out of doing the task (value can be  
> in the form of money, food, or even something as intrinsic as  
> happiness and fulfillment);
>     E is the level of effort required to generate that value;
>     T is the amount of time I have to spend doing the task;
>     H is the hassle factor that comes along with performing the task.
>
> The goal is to maximize V while minimizing E, T and H, thus keeping  
> P at or above 1.  High values of P are very, very good.
>
> For everything I spend my time doing, I apply this formula in my  
> head.  And it answers a basic question: "Is this worth my time?"   
> For my work in the CoCo, V, E and T are pretty much constants, with  
> the large majority of V being enjoyment of the hobby and the  
> positive interactions I get with the majority of our customers and  
> friends.  Very little of V is in the form of monetary compensation.
>
> Without a doubt, Mark and I have built a great network of friends  
> and customers through Cloud-9, and I appreciate their business and  
> support.  They keep the value of V pretty high, but it's the value  
> of H that I watch carefully.  It increases when I have to write long  
> emails like this one when I would rather be doing something else on  
> a Saturday morning.  It increases when people wrongly assume that we  
> are ignoring them and then send nasty emails.  It increases when my  
> time gets taken advantage of by others without fair compensation or  
> under false pretenses.
>
> Thanks for listening!
>
> On Nov 7, 2009, at 7:31 AM, Derek wrote:
>
>>> Remember Cloud9 is not Mark's prime source of income. It is done  
>>> for a love of the Coco
>>> and the community.
>>
>> I mean no disrespect to the folks at cloud 9 and have even  
>> purchased my 512K Ram upgrade from them but if you going to run a  
>> business there is a right way and a wrong way to do it. If there  
>> are problems with filling orders you should at least post on your  
>> web page about possible delays or reply back to your customers  
>> about how long the delay will be. It sounds like a few folks have  
>> emailed but got no reply back and they have had to post here or on coco3.com 
>>  to get an answer.
>>
>>
>>
>>
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From boisy at tee-boy.com  Sat Nov  7 12:33:05 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sat, 7 Nov 2009 11:33:05 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <d63.45dcaf39.3827000b@aol.com>
References: <d63.45dcaf39.3827000b@aol.com>
Message-ID: <30DFC7B5-D947-4F8E-B871-B72A3A2ED906@tee-boy.com>

On Nov 7, 2009, at 10:53 AM, RJRTTY at aol.com wrote:

> HAAAA!! HA HA !!!!   :P
>
> Boisy you have spent too much time in the ivory towers
> of academia and I know exactly what you are talking about.
> I just haven't heard anybody put it quit so precisely.
>
> Life gets in my way of filling orders too and sometimes
> you have to let it go for awhile to take care of more important
> business.

True. People don't see that from their end though, so I guess we need  
to work a little harder and communicate it better.

> Its no secret I make no money on my projects but that's
> ok because I do it for the experience and making new
> friends.   My recent decision to raise prices reflects
> the passing of that phase of my little business.
> Now I charge enough to offset costs plus a little more.
> I also save everybody's emails and get to them when I
> can.
>
> I am extremely satisfied with all my cloud 9 enhancements
> and have nothing but praise for the way you and Mark
> have operated your coco business.
>
> May you have maximum V and minimum H factors in
> your Formula of Probability of Continued Effort and thanks for   
> lifting
> my mood this morning.....

Peace buddy!



From chadbh74 at hotmail.com  Sat Nov  7 12:44:08 2009
From: chadbh74 at hotmail.com (Chad H)
Date: Sat, 7 Nov 2009 11:44:08 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <37939.60399.qm@web30203.mail.mud.yahoo.com>
References: <4BFFC1B5-D68A-49CA-B4AF-15A4822D521E@tee-boy.com>
	<37939.60399.qm@web30203.mail.mud.yahoo.com>
Message-ID: <COL103-DS2171D7E9CA13BBBD545088C8AE0@phx.gbl>

Dang all I did was post a question as to the status of Cloud-9 and inquired
if anyone knew why I wasn't getting replies to an order/info request...now
it's turned in to a thread that's lead to this!?  Geez.  Guess I should have
searched through this forum's posts to determine Boise's or Mark's email
addresses and contacted them directly.

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Derek
Sent: Saturday, November 07, 2009 10:50 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Cloud-9 Tech

As I said last year on the email list because of the way you treat customers
and your attitude that we are all ignorant and a hassle to deal with is why
I will never again purchase from Cloud-9 as long as your part of the
company. Every time you reply to a product or service question it is done in
a way that shows a total lack of respect for people and that fine,. I
respect your right to feel the way you do and to express yourself. I reserve
the right to not do business with your company until how you treat people
changes. 

My budget for my vintage computing hobby is not large but I can tell you I
have bypassed your company's products this past year in favor for expansions
and accessories for other vintage platforms because every time I have gone
to possibly place an order for Drive wire or the Super IDE controller I
remember how you have treated me and others on the email list in the past
and I just cant bring myself to do business with you.







** Mistrust Authority. Promote Decentralization **


 

--- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:

From: Boisy G. Pitre <boisy at tee-boy.com>
Subject: Re: [Coco] Cloud-9 Tech
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Date: Saturday, November 7, 2009, 7:05 AM

Mark really should address this since Cloud-9 is his business and I sell my
products through him, but since he's on vacation, I'll respond.

I think your message doesn't convey a sense of disrespect as much as it does
an ignorance of how Cloud-9's business is handled.

Cloud-9 order fulfillment works this way: Mark buys software product in bulk
from me and stocks those products at Lab North.? As orders come in, they are
evaluated.? If it's a purely software order, I'll fulfill it here at Lab
South, since I have the capacity to make the software products.? If it's a
mixture of hardware and software, Mark will fulfill it at Lab North.? We do
this to prevent having to ship from two different locations for the same
order.

That's why some folks get packages sent from Minnesota, others from
Louisiana.

When Mark is away (he and I stay in touch regularly, so I know his
schedule), I will fill orders that I can.? For those that I can't, I'll
inform the customer of the delay.? When Mark gets back in zone, he takes
care of those orders.

Sometimes we go an extended time without getting orders, so it's not unusual
to have quiet periods without emails. As a result, when things break, like
the email seems to have, we don't notice it right away.? Since Mark handles
the IT stuff (email routing, knows passwords, etc), he will have to return
before the situation becomes rectified.

Aside from all this, Mark has a busy life these days, and he's given a
glimpse of what's going on in his life in prior messages.

Now from this point onward, I'll speak for myself.

Between managing and running my own successful business, attending graduate
school, running a household and seeing after all of the other goings on in
my life, the CoCo is really way down on the list of priorities.? Sorry if
that hurts, but that's the facts.???I have less time and more commitments?
on my plate than ever, and the revenue that I obtain from Cloud-9 is
infinitesimal compared to my other sources of income.

There's an equation that I derived some years back that describes my
philosophy on how I spend my time.? I call it "Boisy's Formula of
Probability of Continued Effort." This is my formula; it works for me:

P = V / (E*T*H))

Where:
??? P is the probability of continued effort for a given task;
??? V is the value that I obtain out of doing the task (value can be in the
form of money, food, or even something as intrinsic as happiness and
fulfillment);
??? E is the level of effort required to generate that value;
??? T is the amount of time I have to spend doing the task;
??? H is the hassle factor that comes along with performing the task.

The goal is to maximize V while minimizing E, T and H, thus keeping P at or
above 1.? High values of P are very, very good.

For everything I spend my time doing, I apply this formula in my head.? And
it answers a basic question: "Is this worth my time?"? For my work in the
CoCo, V, E and T are pretty much constants, with the large majority of V
being enjoyment of the hobby and the positive interactions I get with the
majority of our customers and friends.? Very little of V is in the form of
monetary compensation.

Without a doubt, Mark and I have built a great network of friends and
customers through Cloud-9, and I appreciate their business and support.?
They keep the value of V pretty high, but it's the value of H that I watch
carefully.? It increases when I have to write long emails like this one when
I would rather be doing something else on a Saturday morning.? It increases
when people wrongly assume that we are ignoring them and then send nasty
emails.? It increases when my time gets taken advantage of by others without
fair compensation or under false pretenses.

Thanks for listening!

On Nov 7, 2009, at 7:31 AM, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done for a
love of the Coco
>> and the community.
> 
> I mean no disrespect to the folks at cloud 9 and have even purchased my
512K Ram upgrade from them but if you going to run a business there is a
right way and a wrong way to do it. If there are problems with filling
orders you should at least post on your web page about possible delays or
reply back to your customers about how long the delay will be. It sounds
like a few folks have emailed but got no reply back and they have had to
post here or on coco3.com to get an answer.
> 
> 
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From jimhrubik at earthlink.net  Sat Nov  7 13:15:45 2009
From: jimhrubik at earthlink.net (James Hrubik)
Date: Sat, 7 Nov 2009 13:15:45 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <762A83A8-B967-4CDC-A145-4BC6FB85F20F@tee-boy.com>
References: <37939.60399.qm@web30203.mail.mud.yahoo.com>
	<762A83A8-B967-4CDC-A145-4BC6FB85F20F@tee-boy.com>
Message-ID: <3567EAEB-7AC9-41A0-BDEF-29302CF4BA5E@earthlink.net>

Easy, fellas.  Anybody keeping track of how high the yellow marks on  
the wall are getting?

On Nov 7, 2009, at Saturday, November 7, 2009 - 12:23 PM, Boisy G.  
Pitre wrote:

> Whatever chip that you have on your shoulder about me can stay  
> firmly planted, but I dare say that anyone who has purchased a  
> product from me has been treated with the utmost respect.  Your  
> assertion that I treat my customers as though they are ignorant is  
> patently false. People who spend their money with me will get my  
> time and assistance, and I'll do everything I can within reason to  
> help them.

And even folks that haven't spent their money with you!!  Thanks, Boisy!

> I'm a rather cut and dry person; I speak my mind, and I don't mince  
> words.  I attribute it in part to my Cajun upbringing and the  
> bluntness that I was exposed to growing up.  That comes across to  
> some as curt and rude to some.

BTW -- I'm fermenting some chilis right now in an experiment that was  
triggered by the label on the Louisiana Hot Sauce bottle.  I'll try  
to let you know if it turns out half-way decent.

> By the way, if you truly feel that way, then I presume you're not  
> using DriveWire either, even though it's free, right?
>
> On Nov 7, 2009, at 10:49 AM, Derek wrote:
>
>> ... I will never again purchase from Cloud-9 as long as your part  
>> of the company... I have bypassed your company's products this  
>> past year in favor for expansions and accessories for other  
>> vintage platforms because every time I have gone to possibly place  
>> an order for Drive wire or the Super IDE controller I remember how  
>> you have treated me and others on the email list in the past and I  
>> just cant bring myself to do business with you.
>>
>>> --- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>>
>>> I think your message doesn't convey a sense of disrespect as much  
>>> as it does an ignorance of how Cloud-9's business is handled.
>>>
>>> Without a doubt, Mark and I have built a great network of friends  
>>> and customers through Cloud-9, and I appreciate their business  
>>> and support.  They keep the value of V pretty high, but it's the  
>>> value of H that I watch carefully.  It increases when I have to  
>>> write long emails like this one when I would rather be doing  
>>> something else on a Saturday morning.  It increases when people  
>>> wrongly assume that we are ignoring them and then send nasty  
>>> emails.  It increases when my time gets taken advantage of by  
>>> others without fair compensation or under false pretenses.
>>>
>>> On Nov 7, 2009, at 7:31 AM, Derek wrote:
>>>
>>>> I mean no disrespect to the folks at cloud 9 and have even  
>>>> purchased my 512K Ram upgrade from them but if you going to run  
>>>> a business there is a right way and a wrong way to do it. If  
>>>> there are problems with filling orders you should at least post  
>>>> on your web page about possible delays or reply back to your  
>>>> customers about how long the delay will be. It sounds like a few  
>>>> folks have emailed but got no reply back and they have had to  
>>>> post here or on coco3.com to get an answer.
>>>

*** [[[===]]] ***
Don't spend too much time thinking "inside the box".
You will have plenty of time for that later.
*** [[[===]]] ***
 From the Sayings of Grampa Jim, Copyright 2009.
Unauthorized use of my stuff may cause senility.
*** [[[===]]] ***
email : jimhrubik at earthlink.net
info : http://www.hrubikappraisal.com
blog1 : http://hrubikappraisal.blogspot.com
blog2 : http://grandpa-jim.blogspot.com



From coco+list at jeanpaulsamson.com  Sat Nov  7 15:37:36 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Sat, 7 Nov 2009 13:37:36 -0700
Subject: [Coco] beginning os9 assembler questions
In-Reply-To: <COL103-DS21159AD99908398B9E3590C8AE0@phx.gbl>
References: <e44ad6640911052353u7b1a19fdodfadcd04fd3bc84d@mail.gmail.com><732986.33918.qm@web53706.mail.re2.yahoo.com><DDDE7D171727486693AAFA695C2C1CD9@Crossfire>	<06FD2FD6-429E-472D-A3BE-B720C31546DB@jeanpaulsamson.com>
	<5D7489AAFE3A46169A78F376F80CE020@speedy>
	<COL103-DS21159AD99908398B9E3590C8AE0@phx.gbl>
Message-ID: <3B3CCF1C-3473-4C43-9DA3-D814172991C7@jeanpaulsamson.com>

On Nov-7-09, at 8:14 AM, Chad H wrote:
> Hope JP doesn't mind, I took the liberty of mirroring the document  
> on my
> MediaFire account since I had a google email to download his copy.

Nope, I don't mind.  I've been storing all my documents on Google Docs  
these days, and apparently you can only view but not download unless  
you have a Google Gmail account. (So much for Google not acting evil!)

I noticed a minor graphical glitch on one of the pages, so I fixed  
that up and uploaded this modified version:

<https://docs.google.com/fileview?id=0B5WL6q8cbexOMDQ5ZWFlNjUtNmY1Yy00YWY0LTg2OGItODk5NmM4ZGUzOTdj&hl=en 
 >

If anyone else notices any problems (e.g. bad bookmarks, missing  
pages, issues with graphics), do let me know and I'll see if I can  
correct it.  (I didn't bother to proofread--these kinds of manuals can  
make for some dry reading!)  The document was derived from the  
original PDF manual posted on the Freescale support website.

-- JP



From random_rodder at yahoo.com  Sat Nov  7 19:23:24 2009
From: random_rodder at yahoo.com (Brian Blake)
Date: Sat, 7 Nov 2009 16:23:24 -0800 (PST)
Subject: [Coco] Cloud-9 Tech
Message-ID: <801647.98534.qm@web43139.mail.sp1.yahoo.com>

I know for a fact Roy's VGA adapter is well worth waiting. I have no qualms of waiting for stuff from C9 when u get around to it. 

Boisy may come off as abrasive to some. Personally, I can respect folks who are direct and to the point; I'm the same way.

As has been said before, this is a hobby and a labor love to some. I'm just happy there are folks like Mark, Boisy, Roy and Roger, to name just a few, around to develop new stuff for this machine.  

Sent from Brian's iPhone

On Nov 7, 2009, at 12:33 PM, "Boisy G. Pitre" <boisy at tee-boy.com> wrote:

On Nov 7, 2009, at 10:53 AM, RJRTTY at aol.com wrote:

HAAAA!! HA HA !!!!   :P

Boisy you have spent too much time in the ivory towers
of academia and I know exactly what you are talking about.
I just haven't heard anybody put it quit so precisely.

Life gets in my way of filling orders too and sometimes
you have to let it go for awhile to take care of more important
business.

True. People don't see that from their end though, so I guess we need to work a little harder and communicate it better.

Its no secret I make no money on my projects but that's
ok because I do it for the experience and making new
friends.   My recent decision to raise prices reflects
the passing of that phase of my little business.
Now I charge enough to offset costs plus a little more.
I also save everybody's emails and get to them when I
can.

I am extremely satisfied with all my cloud 9 enhancements
and have nothing but praise for the way you and Mark
have operated your coco business.

May you have maximum V and minimum H factors in
your Formula of Probability of Continued Effort and thanks for  lifting
my mood this morning.....

Peace buddy!


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From jcewy at swbell.net  Sat Nov  7 21:23:12 2009
From: jcewy at swbell.net (Joel Ewy)
Date: Sat, 07 Nov 2009 20:23:12 -0600
Subject: [Coco] SWTPC runs S-BUG
Message-ID: <4AF62B90.6030302@swbell.net>

I've got the S-BUG monitor running on the SWTPC I've been restoring.  
It's not booting OS-9 yet, but progress is being made.

My next challenge is going to be getting enough working RAM in the 
computer.  I have a 32K DRAM board, 3 8K SRAM boards, and a couple 2K 
SRAM boards.  Only the 32K and 2 of the 8K boards seem to work at the 
moment.  If I can get the other 8K board to work, and get them all 
addressed sequentially and playing nicely together that will give me 
56K, which should be enough to boot OS-9.  We'll see.

http://8littlebits.wordpress.com/category/swtpc/

JCE



From coco+list at jeanpaulsamson.com  Sat Nov  7 22:05:01 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Sat, 7 Nov 2009 20:05:01 -0700
Subject: [Coco] Dungeons of Daggorath Program Manual
Message-ID: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>

Since I seem to be into transitioning old CoCo manuals to digital  
form, I thought I'd pass along my rendition of the manual for Dungeons  
of Daggorath.  This one's a labor of love--I don't want to think about  
how many days of scanning and image cleanup I undertook.  The  
resulting PDF is bookmarked and searchable.  It even includes a linked  
table of contents and a copy of the game itself in its attachments.

<https://docs.google.com/fileview?id=0B5WL6q8cbexONmI4MTlhOTAtMDFlMy00OWQyLTkzYzMtYjNhMjNjZjA5ZWVh&hl=en 
 >

-- JP



From jcewy at swbell.net  Sat Nov  7 23:07:55 2009
From: jcewy at swbell.net (Joel Ewy)
Date: Sat, 07 Nov 2009 22:07:55 -0600
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>
Message-ID: <4AF6441B.5040708@swbell.net>

J.P. Samson wrote:
> Since I seem to be into transitioning old CoCo manuals to digital 
> form, I thought I'd pass along my rendition of the manual for Dungeons 
> of Daggorath.  This one's a labor of love--I don't want to think about 
> how many days of scanning and image cleanup I undertook.  The 
> resulting PDF is bookmarked and searchable.  It even includes a linked 
> table of contents and a copy of the game itself in its attachments.
>
> <https://docs.google.com/fileview?id=0B5WL6q8cbexONmI4MTlhOTAtMDFlMy00OWQyLTkzYzMtYjNhMjNjZjA5ZWVh&hl=en> 
>
>
> -- JP
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
Wow.  The work shows.  This is not a slap-dash scan job.  Thanks.

JCE



From lamune at doki-doki.net  Sun Nov  8 00:09:51 2009
From: lamune at doki-doki.net (Mike Pepe)
Date: Sat, 7 Nov 2009 21:09:51 -0800
Subject: [Coco] 6820 and 6821 pin compatible?
In-Reply-To: <4AF47D16.14022.611C79@jdaggett.gate.net>
References: <4AF39919.9080505@swbell.net>,
	<EEA43F43D1E7444B990B271C34A079E94970ACD488@concord.lamunet.local>
	<4AF47D16.14022.611C79@jdaggett.gate.net>
Message-ID: <EEA43F43D1E7444B990B271C34A079E94E0DCB97E3@concord.lamunet.local>

That could very well be the case. I don't think I even have 6820 datasheets in my library!

The 6822 is indeed electrically different, but in most CoCo cases if you blow up a 22 a 21 will work just fine in its place as the 22's are pretty hard to come by. Best source I know of is dead CoCo 1's :)

> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-
> bounces at maltedmedia.com] On Behalf Of jdaggett at gate.net
> Sent: Friday, November 06, 2009 11:47 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] 6820 and 6821 pin compatible?
> 
> On 5 Nov 2009 at 20:53, Mike Pepe wrote:
> 
> > Should work just fine. As I recall the major difference between the
> two was the 6820 had dynamic registers while the 6821 was static. But
> I'm sure if I'm wrong someone will chime in.
> >
> 
> 
> Mike
> 
> You maybe right, though I seem to remember something about the port
> sink and source
> currents were not very strong and the part blew port pins. Though I
> could be wrong as this
> recollection dates back now almost 30 yrs. I think the MC6820 was
> discontinued in very early
> 80's.
> 
> I do know that the MC6822 differed in that the ports were open drain
> and would work with
> voltages upwards to 15VDC.
> 
> james
> 
> 
> 
> > > -----Original Message-----
> > > From: coco-bounces at maltedmedia.com [mailto:coco-
> > > bounces at maltedmedia.com] On Behalf Of Joel Ewy
> > > Sent: Thursday, November 05, 2009 7:34 PM
> > > To: CoCoList for Color Computer Enthusiasts
> > > Subject: [Coco] 6820 and 6821 pin compatible?
> > >
> > > I'm restoring an SWTPC 6809 computer.  I intend to run OS-9 on it.
> I
> > > also want to try out FLEX and UNIFLEX (the latter of which I'm sure
> > > this
> > > computer once ran).
> > >
> > > I've got a timer board, that I believe (judging from the OS-9
> > > configuration of the SWTPC emulator) provides the system clock
> > > interrupts.  It has a socket that, according to the documentation,
> once
> > > housed a 6820, but now sits empty.  I can probably dig up the
> > > documentation, but I bet somebody on this list can tell me without
> > > cracking a book or downloading a PDF whether or not I can just plop
> a
> > > much more readily available 6821 in there instead.
> > >
> > > If you're interested in following my progress on this project, I've
> > > been
> > > blogging about it:
> http://8littlebits.wordpress.com/category/swtpc/
> > >
> > > The CoCo gets mentioned as well, and I used a CoCo emulator to make
> a
> > > boot disk image I'll eventually use when I'm ready to try and boot
> this
> > > thing up.
> > >
> > > JCE
> > >
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > http://five.pairlist.net/mailman/listinfo/coco
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From aawolfe at gmail.com  Sun Nov  8 06:58:32 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 06:58:32 -0500
Subject: [Coco] os9/drivewire driver problems
Message-ID: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>

First, please don't laugh, I am new and surely making many simple mistakes here.
Second, I cannot say thank you enough to everyone who has made
NitrOS9, the toolshed and drivewire possible.  I'm very impressed by
how well the tools work.

I am trying to add to drivewire the ability to act as a serial port
under NitrOS9.  I've managed to setup a build environment and create a
device descriptor and driver for the new device.  I added the op codes
and handling routines on the server side, etc.   I have write working,
but that's the easy part since the dw printer driver already did that
and I mostly just copied it.

So, I can do things like:  LIST STARTUP > /T2
and everything works great.

However, read is another story.  I can't seem to get anything working
properly and after several hours I am stumped.

Here's what I think I've figured out about how dw works, I might have
some things wrong.
To read a character, I think I am supposed to put my opcode in A,
pointer for the incoming data in X (usually my stack, i think?), the
number of bytes to read in Y.
Then, jsr to the DWSUB and let the magic happen?  At least this is
what I think I've gleaned from the source of other modules.
According to the OS9 dev manual, the Read routine should return a
character in reg A.

So, my first attempt was:

Read
        lda   #OP_SERREAD
        pshs  d
        leax  ,s
        ldy   #$0001
        ldu   >D.DWSUB
        jsr   6,u
       ldy   #$0001
       leax  ,s
       jsr   3,u
       puls  d,a,pc

I may be doing stupid things here, I haven't done 6809 assembler in
many years.  I'm not sure what the 6, and 3, in the JSRs is for, it
seems like every write uses 6 and read uses 3 in the other modules.. ?

This "works" in the sense that the server sees the call and sends back
a byte.  However, I've botched something because the process calling
read always gets a null character.  If I spawn a shell on /T2, it
reads and writes bytes constantly (I think it's echoing the character
it thinks I typed) but its all null chars.

So, I thought to test I would just:

Read
        lda   #OP_SERREAD
        clrb

(#OP_SERREAD is the character 'C').  I was hoping then that something
like LIST /T2 would give me a stream of Cs.  But instead I get Error
208,  Illegal service request.

Hopefully this makes some kind of sense, I'm sure I've done something
silly but if I make Read just put a constant in A and clear B (no
errors), shouldn't I get a character every time I call Read?

Thanks for any pointers
-Aaron


From boisy at tee-boy.com  Sun Nov  8 08:37:57 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sun, 8 Nov 2009 07:37:57 -0600
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>
Message-ID: <32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>


On Nov 8, 2009, at 5:58 AM, Aaron Wolfe wrote:

> First, please don't laugh, I am new and surely making many simple  
> mistakes here.
> Second, I cannot say thank you enough to everyone who has made
> NitrOS9, the toolshed and drivewire possible.  I'm very impressed by
> how well the tools work.

I think it's awesome that someone is taking the reigns and doing  
something like this.  Good going.

> I am trying to add to drivewire the ability to act as a serial port
> under NitrOS9.  I've managed to setup a build environment and create a
> device descriptor and driver for the new device.  I added the op codes
> and handling routines on the server side, etc.   I have write working,
> but that's the easy part since the dw printer driver already did that
> and I mostly just copied it.
>
> So, I can do things like:  LIST STARTUP > /T2
> and everything works great.

Good so far.

> However, read is another story.  I can't seem to get anything working
> properly and after several hours I am stumped.
>
> Here's what I think I've figured out about how dw works, I might have
> some things wrong.
> To read a character, I think I am supposed to put my opcode in A,
> pointer for the incoming data in X (usually my stack, i think?), the
> number of bytes to read in Y.
> Then, jsr to the DWSUB and let the magic happen?  At least this is
> what I think I've gleaned from the source of other modules.
> According to the OS9 dev manual, the Read routine should return a
> character in reg A.

This all sounds correct.

> So, my first attempt was:
>
> Read
>        lda   #OP_SERREAD
>        pshs  d
>        leax  ,s
>        ldy   #$0001
>        ldu   >D.DWSUB
>        jsr   6,u
>       ldy   #$0001
>       leax  ,s
>       jsr   3,u
>       puls  d,a,pc
>
> I may be doing stupid things here, I haven't done 6809 assembler in
> many years.  I'm not sure what the 6, and 3, in the JSRs is for, it
> seems like every write uses 6 and read uses 3 in the other modules.. ?

the jsr 6,u says: "save the address of the next instruction on the  
stack, then obtain the two byte location 6 bytes from the U register  
and jump to that location."   The 6 jumps into the WRITE section of  
the DWSUB routine, and the 3 jumps into the READ routine.

> This "works" in the sense that the server sees the call and sends back
> a byte.  However, I've botched something because the process calling
> read always gets a null character.  If I spawn a shell on /T2, it
> reads and writes bytes constantly (I think it's echoing the character
> it thinks I typed) but its all null chars.

Your last line needs to read:  puls d,pc

You don't want to pull A off the stack because you haven't pushed it  
on prior to the call.  I think you will find that it works after that.

Note that you should be checking for a timeout error after the jsr 3,u  
and load B with an error if so, but get this working first.

> So, I thought to test I would just:
>
> Read
>        lda   #OP_SERREAD
>        clrb
>
> (#OP_SERREAD is the character 'C').  I was hoping then that something
> like LIST /T2 would give me a stream of Cs.  But instead I get Error
> 208,  Illegal service request.

Error #208 is an illegal service request.  I suspect you aren't  
implementing something in your getstat or setstat routine; I don't  
remember the exact issue here, and I'm not at my CoCo at the moment to  
test this out and remember.

Try the fix above with your shell test and see if something happens.   
Let us know.


> Hopefully this makes some kind of sense, I'm sure I've done something
> silly but if I make Read just put a constant in A and clear B (no
> errors), shouldn't I get a character every time I call Read?


> Thanks for any pointers
> -Aaron
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From operator at coco3.com  Sun Nov  8 14:30:32 2009
From: operator at coco3.com (Roger Taylor)
Date: Sun, 08 Nov 2009 13:30:32 -0600
Subject: [Coco] CoCoNet status
Message-ID: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>


Hey dudes and dudettes, how about a little update on that "thing" 
called CoCoNet and the progress of the MicroSD drive pak, etc.  I 
have been getting e-mails asking about these things but it's hard to 
get into lengthy discussions with each person or I would have no time 
for anything else.  Sometimes a good update will answer a lot of 
questions at once.

First, I can only produce these things efficiently and deliver 
pending orders on-time, if I get new orders.  I'm sure this is 
exactly how any business works, and I'm being bold to say that I feel 
like Cloud-9 works this way as well.  That's my 2 cents on the 
Cloud-9 topic.  Nobody's doing anybody wrong or looking down on 
anybody.  People are simply GOING THROUGH ROUGH TIMES since a certain 
date back in 2008.  Anybody else who's successful enough at something 
to admit they're not having problems, is Lucky For Now.  They're 
coming to get ya, that's for sure.  The middle class picks up the 
tab, folks, one way or another.  Enough of that.

I'm asking that every die-hard CoCo user out there who wants the 
ultimate experience to consider three people in your next purchase of 
a CoCo gadget.  All 3 people make items that are designed to KEEP THE 
COCO ALIVE.
These people are: Roger Taylor (myself), Mark Marlette, and Roy 
Justus (VGA Adaptor box). If I left anybody out, please step forward 
and tell us what you've been working your ass off for years to 
develop for the CoCo community and you are instantly a hit in my book.

About CoCoNet.  It's not Ghostware.  I've been running it for over a 
year as I write it and CONTINUOUSLY reburn EPROMs in my tests.

CoCoNet is a collection of features added to Disk BASIC 1.1 and is 
burned to an EPROM that can be used in the Deluxe Wireless RS-232 Pak 
or the upcoming 1GB drive pak, or your own floppy controller.
It's a 16K ROM that works in any CoCo with Extended BASIC, or any 
CoCo 3 of course.   In other words, "CoCoNet works with any CoCo that 
has Extended BASIC".

You can take one of my serial paks (with the TTL header) and plug in 
either an EB301 bluetooth module or MicroSD drive module, plug in the 
CoCoNet EPROM, and you get as many features possible Automatically.
Btw, my Deluxe Wireless Pak and drive pak both are just the serial 
pak with the right module plugged in and the address configured for 
either $FF68 or $FF6C.

As complicated as all of this may sound, it really is plug and play, 
plug and go, or whatever you want to call an out of the box ready pak.

I've got a few more days, maybe a week, of fine tuning before I 
release the 16K CoCoNet 1.0 ROM image for those who have their own 
burners and want to give it a try.  I will burn EPROMs for a few 
bucks plus postage, but the client ROM is free since people are going 
to share it anyway.  The CoCoNet server applet for Windows will be 
free as well for the same reason.

Since the client (CoCo) ROM and the PC server software will be free, 
it's a free "product".  You can boot to the ROM and with the right 
cartridges plugged into your MPI you can customize your own setup.

What I make and sell to help clear off your desk of bulky power 
hungry gadgets is the Deluxe Wireless RS-232 Pak (bluetooth to PC) 
which pretty much clones the Tandy RS-232 Pak but over the air and 
has an EPROM socket which I will put the CoCoNet in to give the CoCo 
an instant wireless virtual drive system.

I'm also wrapping up on a "drive pak" which will have a built in 1GB 
MicroSD drive, also uses the CoCoNet ROM, and gives AT LEAST 256 
virtual floppies, huge hard drives, and any other kinds of partitions 
you want to add.  Disk BASIC will use up to 256 720K disks in one 
partition at a time, OS-9 can have mass drives of any size and also 
use the floppies... a NitrOS-9 boot disk is already on my own pak and 
fires up with all the drivers and module directories so you can build 
other disks or mass drives that boot using the pak, etc.  You know the drill.

I think this answers the question of "how can I get disks onto my 
drive pak?", although the distro pak will be prestocked with lots of goodies.
With CoCoNet, you can mix and match 4 or 5 different TYPES of floppy 
disks on DRIVES 0-3, and copy between them if you like.

115200 bps bitbanger virtual floppy disks (remote PC pathname or web URL)
	DRIVE 0,!"http://www.coco3.com/nitros9boot.dsk"
	DRIVE 1,!"http://www.coco3.com/games.dsk"
	DRIVE 2,!"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
115200 bps RS-232 Pak virtual floppy disks (remote PC pathname or web URL)
	DRIVE 0,"http://www.coco3.com/nitros9boot.dsk"
	DRIVE 1,"http://www.coco3.com/games.dsk"
	DRIVE 2,"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
MicroSD virtual disks (using a "drive pak")
	DRIVE 0;100  mounts disk #100 on drive 0
MicroSD LSN-based disks
	DRIVE 0;0,11,65   mounts a floppy starting at any LSN you want
Real 1793 controller floppy disks
	DRIVE 0,ON	turns ON REAL DRIVE #0
	DRIVE 0,OFF	returns to virtual drive prior

With a totally bare CoCo 1, 2, or 3 you can plug in the pak, turn the 
CoCo on, type DOS and within 5 seconds you're sitting at a NitrOS-9 
prompt.  You don't HAVE to do that.  You can make it where drive 0 
has a game disk mounted automatically on power-up, or the system disk, etc.

Right now only the NitrOS-9 L2 6809 version is on the pak.  In a few 
days I'll have an L1 version and depending on what CoCo you have the 
pak in, the compatible boot disk will be used automatically when the 
DOS command is used.  I haven't included the details of some of my 
schemes because it'll get me off on a serious tangent, but I'm making 
the pak as plug-and-play as possible so it can be used to "save a 
CoCo", so to speak, bring 'er back from the dead with thousands of 
games and apps without needing anything else but the little 
pak.  Btw, it's the size of a game pak.

Back to work!

Roger Taylor

-- 
~ Roger Taylor




From asa.rand at yahoo.com  Sun Nov  8 16:17:14 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sun, 8 Nov 2009 13:17:14 -0800 (PST)
Subject: [Coco] Interesting developments, and a real issue
Message-ID: <748875.52776.qm@web53702.mail.re2.yahoo.com>

My work on DCom/unpack has progressed in a new direction. While hand-decoding ribbsmain and rconfig, two modules from Ron Bihler's RiBBS program, I began to see the way the code flows. I now understand much more of how the content of the I-Code is arranged.

I had written a utility to give me an organized dump of the I-Code. I call it fmato (ForMATtedOutput). By organization, I mean:

* The header is displayed in its parts, and is separated from the instruction section by a blank line.

* The instruction code is displayed with both module and relative addresses and the code for one instruction per line. lines are terminated by a \ token ($3E) or a <eol> token ($3F). This is actually inaccurate in application, because it does not detect a difference between the token being a token, or being part of a variable, line or literal reference.

* The DSAT and VDT sections are also separated from the instruction
code, and each other, by a blank line. Each displays the module and
relative offset to the first byte value displayed on that line. Each
line is 20 bytes in length.

I decided to use fmato as a testbed. I wanted to know exactly what I could identify in the instructions, and how many of what were found. I started from the beginning, and worked my way through the header, then the instruction code. When I reached the end of the instruction code, I had identified every variable reference, every line or branch reference, and every literal reference in the instructions.

Variable references are wrapped in braces: {}
Line references are wrapped in parentheses: ()
Literal references are wrapped in brackets: []

Then I took the DATA statements in unpack and added them to fmato. Now, every token has a name. It can be a keyword or Basic09 function name, or an internal reference that has no bearing on the reproduction of the source code. There is one special wrapper I use. It is: <* *>. I use it to wrap the integer value that occurs in FOR and NEXT statements that is identical in value per FOR/NEXT pair, and each pair has a unique value.

I then added files. Three were necessary:

1. Variable reference
2. Line reference
3. Literal reference

While the literal reference file may serve a purpose later, it really is not necessary to the reconstruction of the source code, since they are Basic09 constants. Because they occur in the instructions, they are easily identified, so a reference file isn't required.

At this point, I began to realize that I had to organize the output in order to make the program execute faster, and to make it digestable to us humans. I added display code, using GFX2, and created a screen layout that accomodates the data I want to see, and overlay windows to display the various lists in. It works great! Until now.

The plan has been to add every function needed to decode the I-Code as much as possible in one pass of the module. The first pass identifies everything in the instructions, then the fmato deals with the reference files. It sorts, renumbers and assigns line number strings to the line references, then sorts and renumbers the literals reference. That is the final step the first pass can do without referencing the VDT and DSAT sections for variable identification.

When fmato reached 24k in source size, I ran into a problem with Basic09. The program would run, display the date, and then get hung in a loop, displaying the same number repeatedly. The value of the number proved to be different in each run, sometimes positive, sometimes negative, and I had to quit MESS to get out of it.

The cure was to pack the procedure, then reduce the memory in Basic09's data space to 23000. fmato would then run correctly.

As I said before, I added display code. Once I was caught up with adding the display code, I then added the literal reference sort and renumber code. This boosted the source size significantly. It now loads into Basic09 with a size of 30089, and the data size is 834. Opening Basic09 with a 32k memory size leaves me 1398 free. This should be enough to run it, but I've tried using 33k, 34k, 35k all the way up to 40k. It does the same thing, gets stuck in that loop.

I pack, and the size is 24438. With 32k, the free space increases from 1398 to 7049. Plenty, right? Wrong. Still gets stuck in that loop. Reduce memory to 26000. Not enough free for the data requirements. Basic09 always says What? if I specify anything other than a whole thousand on the memory spec, so trying 26500 or 26750 is not working.

I try running it from the command line. The same error. Gets stuck in that loop.

The Basic09 I'm using is v01.01.01 for 6809, modified to include a 4-digit year. The RunB I'm using is the original that, if it uses the date at all, only looks for a 2-digit year. There's something going on that isn't specific to one version. I don't know how to resolve the issue, or even what may be causing it.

Can anyone even venture a guess as to what is happening? I'm running the 6809 version of NitrOS-9 using the MESS emulator.

Wayne



      


From aawolfe at gmail.com  Sun Nov  8 17:46:07 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 17:46:07 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>
	<32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>
Message-ID: <e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>

Thanks for the response Boisy.  Your name is becoming a very common
sight on my screen as I look through the NitrOS9 and drivewire
modules.. is there anything you didn't write or improve? :)

I tried removing the A from the PULS but got the same results.  I am
failing to understand something about how the data is returned from
the DWSUB to the calling routine.  The reason I was pulling A, was I
thought the byte read by DWSUB,READ would be on the stack.. because I
thought I was putting a pointer to my stack in X prior to calling
DWSUB.  But I must be getting this wrong, either in concept or
implementation.  I apologize, my assembler skill was never very good
and I'm very rusty.  Trying to learn as I go here.

What is the proper way to get 1 byte of data from DWSUB into A?  I see
that when the rbfdw driver reads in a block, it puts a pointer to
PD.BUF in X prior to the read call, I am guessing this is where OS9
expects the block to be returned.

* Get 256 bytes of sector data
         ldx   5,s
         ldx   PD.BUF,x                 get buffer pointer into X
         ldy   #$0100
         jsr   3,u

when the clock2_dw gets time, I see:

         ldx   #D.Year
         ldy   #$0005
         jsr   3,u

So X is the constant D.Year, $53 from the coco OS9Defs file, I am
guessing this is writing the returned bytes directly into OS9's "whats
the current time" area?

Eventually I'd like to read a variable amount of data from the server,
but for now I am trying to just get one character at a time (the
server additions I've made have a buffer that can make this work sort
of OK).
So.. if I just want to get one byte into the A register..  can anyone
point out where my code or comments are wrong?  I'm sure I'm
misunderstanding something.  I've found what I think are some other
problems in my code, but still I get the same behavior, constant calls
back and forth to read and write with null results.
Current attempt:

Read    equ  *
        lda   #OP_SERREAD    ; put opcode for read in A
        pshs  a  ;  put A on stack
        leax  ,s  ;  put pointer to top of stack in X
        ldy   #$0001  ; put 1 in Y because we want to send 1 byte
        ldu   >D.DWSUB   ; put addr of DWSUB in U
        jsr   6,u  ;  call write routine, it should send one byte to
server asking for a character
*       puls  a   ;  was removing it, but I think I need to leave a
byte there so we have room for incoming byte and don't clobber other
contents?
        ldy   #$0001   ;  we want to read 1 byte back
        leax  ,s  ;  and put it on our stack, in place of A/the opcode
used in previous call
        jsr   3,u  ;  call DWSUB to read 1 byte
        puls  a,pc ; pull that byte and the pc off stack (pc now sends
us back to calling routine?)

I am guessing the address I'm supposed to return  to is already on the
stack when Read gets called?  Lots of example seem to pull PC of the
stack when they are ready to return but I haven't found where this is
documented so not entirely sure.

Well.. something is wrong with my code, any clues are much appreciated.
-Aaron



On Sun, Nov 8, 2009 at 8:37 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>
> On Nov 8, 2009, at 5:58 AM, Aaron Wolfe wrote:
>
>> First, please don't laugh, I am new and surely making many simple mistakes
>> here.
>> Second, I cannot say thank you enough to everyone who has made
>> NitrOS9, the toolshed and drivewire possible. ?I'm very impressed by
>> how well the tools work.
>
> I think it's awesome that someone is taking the reigns and doing something
> like this. ?Good going.
>
>> I am trying to add to drivewire the ability to act as a serial port
>> under NitrOS9. ?I've managed to setup a build environment and create a
>> device descriptor and driver for the new device. ?I added the op codes
>> and handling routines on the server side, etc. ? I have write working,
>> but that's the easy part since the dw printer driver already did that
>> and I mostly just copied it.
>>
>> So, I can do things like: ?LIST STARTUP > /T2
>> and everything works great.
>
> Good so far.
>
>> However, read is another story. ?I can't seem to get anything working
>> properly and after several hours I am stumped.
>>
>> Here's what I think I've figured out about how dw works, I might have
>> some things wrong.
>> To read a character, I think I am supposed to put my opcode in A,
>> pointer for the incoming data in X (usually my stack, i think?), the
>> number of bytes to read in Y.
>> Then, jsr to the DWSUB and let the magic happen? ?At least this is
>> what I think I've gleaned from the source of other modules.
>> According to the OS9 dev manual, the Read routine should return a
>> character in reg A.
>
> This all sounds correct.
>
>> So, my first attempt was:
>>
>> Read
>> ? ? ? lda ? #OP_SERREAD
>> ? ? ? pshs ?d
>> ? ? ? leax ?,s
>> ? ? ? ldy ? #$0001
>> ? ? ? ldu ? >D.DWSUB
>> ? ? ? jsr ? 6,u
>> ? ? ?ldy ? #$0001
>> ? ? ?leax ?,s
>> ? ? ?jsr ? 3,u
>> ? ? ?puls ?d,a,pc
>>
>> I may be doing stupid things here, I haven't done 6809 assembler in
>> many years. ?I'm not sure what the 6, and 3, in the JSRs is for, it
>> seems like every write uses 6 and read uses 3 in the other modules.. ?
>
> the jsr 6,u says: "save the address of the next instruction on the stack,
> then obtain the two byte location 6 bytes from the U register and jump to
> that location." ? The 6 jumps into the WRITE section of the DWSUB routine,
> and the 3 jumps into the READ routine.
>
>> This "works" in the sense that the server sees the call and sends back
>> a byte. ?However, I've botched something because the process calling
>> read always gets a null character. ?If I spawn a shell on /T2, it
>> reads and writes bytes constantly (I think it's echoing the character
>> it thinks I typed) but its all null chars.
>
> Your last line needs to read: ?puls d,pc
>
> You don't want to pull A off the stack because you haven't pushed it on
> prior to the call. ?I think you will find that it works after that.
>
> Note that you should be checking for a timeout error after the jsr 3,u and
> load B with an error if so, but get this working first.
>
>> So, I thought to test I would just:
>>
>> Read
>> ? ? ? lda ? #OP_SERREAD
>> ? ? ? clrb
>>
>> (#OP_SERREAD is the character 'C'). ?I was hoping then that something
>> like LIST /T2 would give me a stream of Cs. ?But instead I get Error
>> 208, ?Illegal service request.
>
> Error #208 is an illegal service request. ?I suspect you aren't implementing
> something in your getstat or setstat routine; I don't remember the exact
> issue here, and I'm not at my CoCo at the moment to test this out and
> remember.
>
> Try the fix above with your shell test and see if something happens. ?Let us
> know.
>
>
>> Hopefully this makes some kind of sense, I'm sure I've done something
>> silly but if I make Read just put a constant in A and clear B (no
>> errors), shouldn't I get a character every time I call Read?
>
>
>> Thanks for any pointers
>> -Aaron
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Sun Nov  8 17:59:27 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 17:59:27 -0500
Subject: [Coco] drivewire serial port concept questions
Message-ID: <e44ad6640911081459t3e54d89encd597fa26172577e@mail.gmail.com>

It looks like (and I could certainly be wrong) the normal Drivewire
server only responds to requests from the Coco, there is no way to
initiate something from the server side except in WireBug mode.  I
think this means there is no interrupt handler or poller on the OS9
side.  This makes sense, disk, clock and printing is always initiated
by the Coco.

Ideally, a serial driver would not require polling.. as it stands my
driver (if it worked) would require a byte out to get a byte in, or
even to tell if there was a byte in the incoming buffer.  This will
work for simple tests and maybe a shell over the serial port (my first
goal), but it would not work very well for BBS/telecom type things.
Even if I improve the driver to return more than 1 byte at a time, its
still an awful lot of wasted outbound characters and probably would
completely kill performance of everything else.  Sleeping between
polls would help that but make serial port throughput pretty awful.

Is it practical to implement some kind of interrupt when the server
has data in it's incoming buffer?  Would this kill performance, or
screw up other DW operations?  I can imagine it might, and at my
current skill level figuring this out is a scary thought :)  But if
this is the correct approach I will keep banging my head against it
until I get something working.  Just wondered if this was the right
direction to go in.


From lothan at newsguy.com  Sun Nov  8 18:33:19 2009
From: lothan at newsguy.com (Lothan)
Date: Sun, 8 Nov 2009 18:33:19 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com><32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>
	<e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
Message-ID: <3F97C93F69BB42728765C3C6C4B2705F@Crossfire>

Given the layout of the register postbyte, PULS A,B is exactly the same as 
PULS D (e.g. the postbyte is $05 in either case), so PULS A,D and PULS B,D 
and PULS A,B,D should in theory all compile exactly the same as PULS A,B or 
PULS D.

Someone feel free to smack me with a clue stick if I have that wrong.

--------------------------------------------------
From: "Aaron Wolfe" <aawolfe at gmail.com>
Sent: Sunday, November 08, 2009 5:46 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver problems

> I tried removing the A from the PULS but got the same results.  I am
> failing to understand something about how the data is returned from
> the DWSUB to the calling routine.  The reason I was pulling A, was I
> thought the byte read by DWSUB,READ would be on the stack.. because I
> thought I was putting a pointer to my stack in X prior to calling
> DWSUB.  But I must be getting this wrong, either in concept or
> implementation.  I apologize, my assembler skill was never very good
> and I'm very rusty.  Trying to learn as I go here.
>
> What is the proper way to get 1 byte of data from DWSUB into A?  I see
> that when the rbfdw driver reads in a block, it puts a pointer to
> PD.BUF in X prior to the read call, I am guessing this is where OS9
> expects the block to be returned.
>
> * Get 256 bytes of sector data
>         ldx   5,s
>         ldx   PD.BUF,x                 get buffer pointer into X
>         ldy   #$0100
>         jsr   3,u
>
> when the clock2_dw gets time, I see:
>
>         ldx   #D.Year
>         ldy   #$0005
>         jsr   3,u
>
> So X is the constant D.Year, $53 from the coco OS9Defs file, I am
> guessing this is writing the returned bytes directly into OS9's "whats
> the current time" area?
>
> Eventually I'd like to read a variable amount of data from the server,
> but for now I am trying to just get one character at a time (the
> server additions I've made have a buffer that can make this work sort
> of OK).
> So.. if I just want to get one byte into the A register..  can anyone
> point out where my code or comments are wrong?  I'm sure I'm
> misunderstanding something.  I've found what I think are some other
> problems in my code, but still I get the same behavior, constant calls
> back and forth to read and write with null results.
> Current attempt:
>
> Read    equ  *
>        lda   #OP_SERREAD    ; put opcode for read in A
>        pshs  a  ;  put A on stack
>        leax  ,s  ;  put pointer to top of stack in X
>        ldy   #$0001  ; put 1 in Y because we want to send 1 byte
>        ldu   >D.DWSUB   ; put addr of DWSUB in U
>        jsr   6,u  ;  call write routine, it should send one byte to
> server asking for a character
> *       puls  a   ;  was removing it, but I think I need to leave a
> byte there so we have room for incoming byte and don't clobber other
> contents?
>        ldy   #$0001   ;  we want to read 1 byte back
>        leax  ,s  ;  and put it on our stack, in place of A/the opcode
> used in previous call
>        jsr   3,u  ;  call DWSUB to read 1 byte
>        puls  a,pc ; pull that byte and the pc off stack (pc now sends
> us back to calling routine?)
>
> I am guessing the address I'm supposed to return  to is already on the
> stack when Read gets called?  Lots of example seem to pull PC of the
> stack when they are ready to return but I haven't found where this is
> documented so not entirely sure.
>
> Well.. something is wrong with my code, any clues are much appreciated.
> -Aaron
>
>
>
> On Sun, Nov 8, 2009 at 8:37 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>
>> On Nov 8, 2009, at 5:58 AM, Aaron Wolfe wrote:
>>
>>> First, please don't laugh, I am new and surely making many simple 
>>> mistakes
>>> here.
>>> Second, I cannot say thank you enough to everyone who has made
>>> NitrOS9, the toolshed and drivewire possible.  I'm very impressed by
>>> how well the tools work.
>>
>> I think it's awesome that someone is taking the reigns and doing 
>> something
>> like this.  Good going.
>>
>>> I am trying to add to drivewire the ability to act as a serial port
>>> under NitrOS9.  I've managed to setup a build environment and create a
>>> device descriptor and driver for the new device.  I added the op codes
>>> and handling routines on the server side, etc.   I have write working,
>>> but that's the easy part since the dw printer driver already did that
>>> and I mostly just copied it.
>>>
>>> So, I can do things like:  LIST STARTUP > /T2
>>> and everything works great.
>>
>> Good so far.
>>
>>> However, read is another story.  I can't seem to get anything working
>>> properly and after several hours I am stumped.
>>>
>>> Here's what I think I've figured out about how dw works, I might have
>>> some things wrong.
>>> To read a character, I think I am supposed to put my opcode in A,
>>> pointer for the incoming data in X (usually my stack, i think?), the
>>> number of bytes to read in Y.
>>> Then, jsr to the DWSUB and let the magic happen?  At least this is
>>> what I think I've gleaned from the source of other modules.
>>> According to the OS9 dev manual, the Read routine should return a
>>> character in reg A.
>>
>> This all sounds correct.
>>
>>> So, my first attempt was:
>>>
>>> Read
>>>       lda   #OP_SERREAD
>>>       pshs  d
>>>       leax  ,s
>>>       ldy   #$0001
>>>       ldu   >D.DWSUB
>>>       jsr   6,u
>>>      ldy   #$0001
>>>      leax  ,s
>>>      jsr   3,u
>>>      puls  d,a,pc
>>>
>>> I may be doing stupid things here, I haven't done 6809 assembler in
>>> many years.  I'm not sure what the 6, and 3, in the JSRs is for, it
>>> seems like every write uses 6 and read uses 3 in the other modules.. ?
>>
>> the jsr 6,u says: "save the address of the next instruction on the stack,
>> then obtain the two byte location 6 bytes from the U register and jump to
>> that location."   The 6 jumps into the WRITE section of the DWSUB 
>> routine,
>> and the 3 jumps into the READ routine.
>>
>>> This "works" in the sense that the server sees the call and sends back
>>> a byte.  However, I've botched something because the process calling
>>> read always gets a null character.  If I spawn a shell on /T2, it
>>> reads and writes bytes constantly (I think it's echoing the character
>>> it thinks I typed) but its all null chars.
>>
>> Your last line needs to read:  puls d,pc
>>
>> You don't want to pull A off the stack because you haven't pushed it on
>> prior to the call.  I think you will find that it works after that.
>>
>> Note that you should be checking for a timeout error after the jsr 3,u 
>> and
>> load B with an error if so, but get this working first.
>>
>>> So, I thought to test I would just:
>>>
>>> Read
>>>       lda   #OP_SERREAD
>>>       clrb
>>>
>>> (#OP_SERREAD is the character 'C').  I was hoping then that something
>>> like LIST /T2 would give me a stream of Cs.  But instead I get Error
>>> 208,  Illegal service request.
>>
>> Error #208 is an illegal service request.  I suspect you aren't 
>> implementing
>> something in your getstat or setstat routine; I don't remember the exact
>> issue here, and I'm not at my CoCo at the moment to test this out and
>> remember.
>>
>> Try the fix above with your shell test and see if something happens.  Let 
>> us
>> know.
>>
>>
>>> Hopefully this makes some kind of sense, I'm sure I've done something
>>> silly but if I make Read just put a constant in A and clear B (no
>>> errors), shouldn't I get a character every time I call Read?
>>
>>
>>> Thanks for any pointers
>>> -Aaron
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 


From random_rodder at yahoo.com  Sun Nov  8 18:50:36 2009
From: random_rodder at yahoo.com (Brian Blake)
Date: Sun, 8 Nov 2009 15:50:36 -0800 (PST)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <d63.45dcaf39.3827000b@aol.com>
References: <d63.45dcaf39.3827000b@aol.com>
Message-ID: <116071.5345.qm@web43135.mail.sp1.yahoo.com>

Sorry I forgot to mention this earlier; Roy I owe you a great big thank you!!! That VGA adapter you sent me to work with my CoCo3 and my Atari ST works just as well as the one I bought for the re-pack project. Great stuff... everyone should have one!!!

Thanks again,

Brian



________________________________
From: "RJRTTY at aol.com" <RJRTTY at aol.com>
To: coco at maltedmedia.com
Sent: Sat, November 7, 2009 11:53:31 AM
Subject: Re: [Coco] Cloud-9 Tech

In a message dated 11/7/2009 10:07:34 A.M. Eastern Standard Time,  
boisy at tee-boy.com writes:



>There's an equation that I derived some years back that describes  my  
>philosophy on how I spend my time.  I call it "Boisy's  Formula of  
>Probability of Continued Effort." This is my formula;  it works for me:

>P = V /  (E*T*H))

>Where:
>    P is the probability of  continued effort for a given task;
>    V is the value that  I obtain out of doing the task (value can be in  
>the form of money,  food, or even something as intrinsic as happiness  
>and  fulfillment);
>    E is the level of effort required to  generate that value;
>    T is the amount of time I have to  spend doing the task;
>    H is the hassle factor that  comes along with performing the task.
>
>The goal is to maximize V  while minimizing E, T and H, thus keeping P  
>at or above 1.   High values of P are very, very good.



HAAAA!! HA HA !!!!   :P

Boisy you have spent too much time in the ivory towers
of academia and I know exactly what you are talking about.
I just haven't heard anybody put it quit so precisely.

Life gets in my way of filling orders too and sometimes
you have to let it go for awhile to take care of more important
business.

Its no secret I make no money on my projects but that's
ok because I do it for the experience and making new 
friends.   My recent decision to raise prices reflects
the passing of that phase of my little business.
Now I charge enough to offset costs plus a little more.
I also save everybody's emails and get to them when I
can.  

I am extremely satisfied with all my cloud 9 enhancements
and have nothing but praise for the way you and Mark
have operated your coco business.

May you have maximum V and minimum H factors in
your Formula of Probability of Continued Effort and thanks for  lifting
my mood this morning.....

Roy


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From mdelyea at gmail.com  Sun Nov  8 19:00:35 2009
From: mdelyea at gmail.com (mike delyea)
Date: Sun, 8 Nov 2009 19:00:35 -0500
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <4AF6441B.5040708@swbell.net>
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>
	<4AF6441B.5040708@swbell.net>
Message-ID: <1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>

That was THE best game for the coco!  A<space R>,  A<space R>,
A<space R>, M, M, M, M, T<space>A.  I swear my heart was beating as
fast the character's heart.

On Sat, Nov 7, 2009 at 11:07 PM, Joel Ewy <jcewy at swbell.net> wrote:
> J.P. Samson wrote:
>>
>> Since I seem to be into transitioning old CoCo manuals to digital form, I
>> thought I'd pass along my rendition of the manual for Dungeons of Daggorath.
>> ?This one's a labor of love--I don't want to think about how many days of
>> scanning and image cleanup I undertook. ?The resulting PDF is bookmarked and
>> searchable. ?It even includes a linked table of contents and a copy of the
>> game itself in its attachments.
>>
>>
>> <https://docs.google.com/fileview?id=0B5WL6q8cbexONmI4MTlhOTAtMDFlMy00OWQyLTkzYzMtYjNhMjNjZjA5ZWVh&hl=en>
>>
>> -- JP
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
> Wow. ?The work shows. ?This is not a slap-dash scan job. ?Thanks.
>
> JCE
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Sun Nov  8 19:20:20 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 19:20:20 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>
	<32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>
	<e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
Message-ID: <e44ad6640911081620w4f6a95eco2e88e26dbe29ebca@mail.gmail.com>

On Sun, Nov 8, 2009 at 5:46 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> Thanks for the response Boisy. ?Your name is becoming a very common
> sight on my screen as I look through the NitrOS9 and drivewire
> modules.. is there anything you didn't write or improve? :)
>
> I tried removing the A from the PULS but got the same results. ?I am
> failing to understand something about how the data is returned from
> the DWSUB to the calling routine. ?The reason I was pulling A, was I
> thought the byte read by DWSUB,READ would be on the stack.. because I
> thought I was putting a pointer to my stack in X prior to calling
> DWSUB. ?But I must be getting this wrong, either in concept or
> implementation. ?I apologize, my assembler skill was never very good
> and I'm very rusty. ?Trying to learn as I go here.
>
> What is the proper way to get 1 byte of data from DWSUB into A? ?I see
> that when the rbfdw driver reads in a block, it puts a pointer to
> PD.BUF in X prior to the read call, I am guessing this is where OS9
> expects the block to be returned.
>
> * Get 256 bytes of sector data
> ? ? ? ? ldx ? 5,s
> ? ? ? ? ldx ? PD.BUF,x ? ? ? ? ? ? ? ? get buffer pointer into X
> ? ? ? ? ldy ? #$0100
> ? ? ? ? jsr ? 3,u
>
> when the clock2_dw gets time, I see:
>
> ? ? ? ? ldx ? #D.Year
> ? ? ? ? ldy ? #$0005
> ? ? ? ? jsr ? 3,u
>
> So X is the constant D.Year, $53 from the coco OS9Defs file, I am
> guessing this is writing the returned bytes directly into OS9's "whats
> the current time" area?
>
> Eventually I'd like to read a variable amount of data from the server,
> but for now I am trying to just get one character at a time (the
> server additions I've made have a buffer that can make this work sort
> of OK).
> So.. if I just want to get one byte into the A register.. ?can anyone
> point out where my code or comments are wrong? ?I'm sure I'm
> misunderstanding something. ?I've found what I think are some other
> problems in my code, but still I get the same behavior, constant calls
> back and forth to read and write with null results.
> Current attempt:
>
> Read ? ?equ ?*
> ? ? ? ?lda ? #OP_SERREAD ? ?; put opcode for read in A
> ? ? ? ?pshs ?a ?; ?put A on stack
> ? ? ? ?leax ?,s ?; ?put pointer to top of stack in X
> ? ? ? ?ldy ? #$0001 ?; put 1 in Y because we want to send 1 byte
> ? ? ? ?ldu ? >D.DWSUB ? ; put addr of DWSUB in U
> ? ? ? ?jsr ? 6,u ?; ?call write routine, it should send one byte to
> server asking for a character
> * ? ? ? puls ?a ? ; ?was removing it, but I think I need to leave a
> byte there so we have room for incoming byte and don't clobber other
> contents?
> ? ? ? ?ldy ? #$0001 ? ; ?we want to read 1 byte back
> ? ? ? ?leax ?,s ?; ?and put it on our stack, in place of A/the opcode
> used in previous call
> ? ? ? ?jsr ? 3,u ?; ?call DWSUB to read 1 byte
> ? ? ? ?puls ?a,pc ; pull that byte and the pc off stack (pc now sends
> us back to calling routine?)
>

I just did a bit of an experiment, returning the byte sent by the
server as the error code (in B) instead of the data in A.  This works
great, I get error #X where X is whatever value the server sends..

Read    equ  *
        lda #OP_SERREAD
        pshs  a
        leax  ,s
        ldy   #$0001
        ldu   >D.DWSUB
        jsr   6,u
        ldy   #$0001
        leax  ,s
        jsr   3,u
        lda   #$FF ; cause cc to be set
        adda  #$01 ;
        puls  b,pc ; return character from DW as error #


So this technique *is* getting the byte from the server.  Yet when I
return the same byte in A, with no error... I get strangeness.

What I thought was the shell echoing characters might be something
else, because when I do something like: LIST /T2
which I think should just read from /T2 until EOF (which is not going
to happen, but whatever).. instead I get the same cycle of READ/WRITE
requests to the driver.  Why would I get a write request at all here?

I think I am actually getting the bytes from DW, so what I thought was
my problem isn't really the problem..  somehow I am not implementing
or understanding something.. thats about as specific as I can get :)

thanks for any advice, I'm reading through everything I can find on
scf device drivers and not finding the clue so far.


> I am guessing the address I'm supposed to return ?to is already on the
> stack when Read gets called? ?Lots of example seem to pull PC of the
> stack when they are ready to return but I haven't found where this is
> documented so not entirely sure.
>
> Well.. something is wrong with my code, any clues are much appreciated.
> -Aaron
>
>
>
> On Sun, Nov 8, 2009 at 8:37 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>
>> On Nov 8, 2009, at 5:58 AM, Aaron Wolfe wrote:
>>
>>> First, please don't laugh, I am new and surely making many simple mistakes
>>> here.
>>> Second, I cannot say thank you enough to everyone who has made
>>> NitrOS9, the toolshed and drivewire possible. ?I'm very impressed by
>>> how well the tools work.
>>
>> I think it's awesome that someone is taking the reigns and doing something
>> like this. ?Good going.
>>
>>> I am trying to add to drivewire the ability to act as a serial port
>>> under NitrOS9. ?I've managed to setup a build environment and create a
>>> device descriptor and driver for the new device. ?I added the op codes
>>> and handling routines on the server side, etc. ? I have write working,
>>> but that's the easy part since the dw printer driver already did that
>>> and I mostly just copied it.
>>>
>>> So, I can do things like: ?LIST STARTUP > /T2
>>> and everything works great.
>>
>> Good so far.
>>
>>> However, read is another story. ?I can't seem to get anything working
>>> properly and after several hours I am stumped.
>>>
>>> Here's what I think I've figured out about how dw works, I might have
>>> some things wrong.
>>> To read a character, I think I am supposed to put my opcode in A,
>>> pointer for the incoming data in X (usually my stack, i think?), the
>>> number of bytes to read in Y.
>>> Then, jsr to the DWSUB and let the magic happen? ?At least this is
>>> what I think I've gleaned from the source of other modules.
>>> According to the OS9 dev manual, the Read routine should return a
>>> character in reg A.
>>
>> This all sounds correct.
>>
>>> So, my first attempt was:
>>>
>>> Read
>>> ? ? ? lda ? #OP_SERREAD
>>> ? ? ? pshs ?d
>>> ? ? ? leax ?,s
>>> ? ? ? ldy ? #$0001
>>> ? ? ? ldu ? >D.DWSUB
>>> ? ? ? jsr ? 6,u
>>> ? ? ?ldy ? #$0001
>>> ? ? ?leax ?,s
>>> ? ? ?jsr ? 3,u
>>> ? ? ?puls ?d,a,pc
>>>
>>> I may be doing stupid things here, I haven't done 6809 assembler in
>>> many years. ?I'm not sure what the 6, and 3, in the JSRs is for, it
>>> seems like every write uses 6 and read uses 3 in the other modules.. ?
>>
>> the jsr 6,u says: "save the address of the next instruction on the stack,
>> then obtain the two byte location 6 bytes from the U register and jump to
>> that location." ? The 6 jumps into the WRITE section of the DWSUB routine,
>> and the 3 jumps into the READ routine.
>>
>>> This "works" in the sense that the server sees the call and sends back
>>> a byte. ?However, I've botched something because the process calling
>>> read always gets a null character. ?If I spawn a shell on /T2, it
>>> reads and writes bytes constantly (I think it's echoing the character
>>> it thinks I typed) but its all null chars.
>>
>> Your last line needs to read: ?puls d,pc
>>
>> You don't want to pull A off the stack because you haven't pushed it on
>> prior to the call. ?I think you will find that it works after that.
>>
>> Note that you should be checking for a timeout error after the jsr 3,u and
>> load B with an error if so, but get this working first.
>>
>>> So, I thought to test I would just:
>>>
>>> Read
>>> ? ? ? lda ? #OP_SERREAD
>>> ? ? ? clrb
>>>
>>> (#OP_SERREAD is the character 'C'). ?I was hoping then that something
>>> like LIST /T2 would give me a stream of Cs. ?But instead I get Error
>>> 208, ?Illegal service request.
>>
>> Error #208 is an illegal service request. ?I suspect you aren't implementing
>> something in your getstat or setstat routine; I don't remember the exact
>> issue here, and I'm not at my CoCo at the moment to test this out and
>> remember.
>>
>> Try the fix above with your shell test and see if something happens. ?Let us
>> know.
>>
>>
>>> Hopefully this makes some kind of sense, I'm sure I've done something
>>> silly but if I make Read just put a constant in A and clear B (no
>>> errors), shouldn't I get a character every time I call Read?
>>
>>
>>> Thanks for any pointers
>>> -Aaron
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>


From mdelyea at gmail.com  Sun Nov  8 19:34:10 2009
From: mdelyea at gmail.com (mike delyea)
Date: Sun, 8 Nov 2009 19:34:10 -0500
Subject: [Coco] CoCoNet status
In-Reply-To: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>
References: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>
Message-ID: <1b52e6c80911081634o385278e5u6c9011f9d95e9a72@mail.gmail.com>

I don't have a multipak.  In addition, I want to keep using my
floppies for RSDOS and booting my floppies for NitrosO9.  How can I
use my floppies and use Roger's pak at the same time?  There seems to
be many talented hardware guys in our community, why don't we have a
replacement for the multipak?  I'd like to have a hard drive (for
NitrosO9 AND my floppies AND Roger's pak and a real serial  port and a
parallel port (I've got a mint HP Laserjet 4 I'm dying to get working
with my coco and a serial modem I'd like to hook up and run a REAL
coco BBS).  I am really hankering after Roy's VGA converter too.  I'm
looking at the prices of these things (pak, hd, vga) and I'm looking
at $300+ (and that's not counting the serial/parallel pak (which
doesn't exist either)).  I want to buy things from Cloud Nine and Roy
and Roger but I just don't have the cash right now.  And even if I had
the cash, I wouldn't have a multipak to plug the stuff into.  I don't
even think you can buy a fracking Y cable these days. Hardware people
- build the MP replacement so I can plug the hardware in.

On Sun, Nov 8, 2009 at 2:30 PM, Roger Taylor <operator at coco3.com> wrote:
>
> Hey dudes and dudettes, how about a little update on that "thing" called
> CoCoNet and the progress of the MicroSD drive pak, etc. ?I have been getting
> e-mails asking about these things but it's hard to get into lengthy
> discussions with each person or I would have no time for anything else.
> ?Sometimes a good update will answer a lot of questions at once.
>
> First, I can only produce these things efficiently and deliver pending
> orders on-time, if I get new orders. ?I'm sure this is exactly how any
> business works, and I'm being bold to say that I feel like Cloud-9 works
> this way as well. ?That's my 2 cents on the Cloud-9 topic. ?Nobody's doing
> anybody wrong or looking down on anybody. ?People are simply GOING THROUGH
> ROUGH TIMES since a certain date back in 2008. ?Anybody else who's
> successful enough at something to admit they're not having problems, is
> Lucky For Now. ?They're coming to get ya, that's for sure. ?The middle class
> picks up the tab, folks, one way or another. ?Enough of that.
>
> I'm asking that every die-hard CoCo user out there who wants the ultimate
> experience to consider three people in your next purchase of a CoCo gadget.
> ?All 3 people make items that are designed to KEEP THE COCO ALIVE.
> These people are: Roger Taylor (myself), Mark Marlette, and Roy Justus (VGA
> Adaptor box). If I left anybody out, please step forward and tell us what
> you've been working your ass off for years to develop for the CoCo community
> and you are instantly a hit in my book.
>
> About CoCoNet. ?It's not Ghostware. ?I've been running it for over a year as
> I write it and CONTINUOUSLY reburn EPROMs in my tests.
>
> CoCoNet is a collection of features added to Disk BASIC 1.1 and is burned to
> an EPROM that can be used in the Deluxe Wireless RS-232 Pak or the upcoming
> 1GB drive pak, or your own floppy controller.
> It's a 16K ROM that works in any CoCo with Extended BASIC, or any CoCo 3 of
> course. ? In other words, "CoCoNet works with any CoCo that has Extended
> BASIC".
>
> You can take one of my serial paks (with the TTL header) and plug in either
> an EB301 bluetooth module or MicroSD drive module, plug in the CoCoNet
> EPROM, and you get as many features possible Automatically.
> Btw, my Deluxe Wireless Pak and drive pak both are just the serial pak with
> the right module plugged in and the address configured for either $FF68 or
> $FF6C.
>
> As complicated as all of this may sound, it really is plug and play, plug
> and go, or whatever you want to call an out of the box ready pak.
>
> I've got a few more days, maybe a week, of fine tuning before I release the
> 16K CoCoNet 1.0 ROM image for those who have their own burners and want to
> give it a try. ?I will burn EPROMs for a few bucks plus postage, but the
> client ROM is free since people are going to share it anyway. ?The CoCoNet
> server applet for Windows will be free as well for the same reason.
>
> Since the client (CoCo) ROM and the PC server software will be free, it's a
> free "product". ?You can boot to the ROM and with the right cartridges
> plugged into your MPI you can customize your own setup.
>
> What I make and sell to help clear off your desk of bulky power hungry
> gadgets is the Deluxe Wireless RS-232 Pak (bluetooth to PC) which pretty
> much clones the Tandy RS-232 Pak but over the air and has an EPROM socket
> which I will put the CoCoNet in to give the CoCo an instant wireless virtual
> drive system.
>
> I'm also wrapping up on a "drive pak" which will have a built in 1GB MicroSD
> drive, also uses the CoCoNet ROM, and gives AT LEAST 256 virtual floppies,
> huge hard drives, and any other kinds of partitions you want to add. ?Disk
> BASIC will use up to 256 720K disks in one partition at a time, OS-9 can
> have mass drives of any size and also use the floppies... a NitrOS-9 boot
> disk is already on my own pak and fires up with all the drivers and module
> directories so you can build other disks or mass drives that boot using the
> pak, etc. ?You know the drill.
>
> I think this answers the question of "how can I get disks onto my drive
> pak?", although the distro pak will be prestocked with lots of goodies.
> With CoCoNet, you can mix and match 4 or 5 different TYPES of floppy disks
> on DRIVES 0-3, and copy between them if you like.
>
> 115200 bps bitbanger virtual floppy disks (remote PC pathname or web URL)
> ? ? ? ?DRIVE 0,!"http://www.coco3.com/nitros9boot.dsk"
> ? ? ? ?DRIVE 1,!"http://www.coco3.com/games.dsk"
> ? ? ? ?DRIVE 2,!"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
> 115200 bps RS-232 Pak virtual floppy disks (remote PC pathname or web URL)
> ? ? ? ?DRIVE 0,"http://www.coco3.com/nitros9boot.dsk"
> ? ? ? ?DRIVE 1,"http://www.coco3.com/games.dsk"
> ? ? ? ?DRIVE 2,"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
> MicroSD virtual disks (using a "drive pak")
> ? ? ? ?DRIVE 0;100 ?mounts disk #100 on drive 0
> MicroSD LSN-based disks
> ? ? ? ?DRIVE 0;0,11,65 ? mounts a floppy starting at any LSN you want
> Real 1793 controller floppy disks
> ? ? ? ?DRIVE 0,ON ? ? ?turns ON REAL DRIVE #0
> ? ? ? ?DRIVE 0,OFF ? ? returns to virtual drive prior
>
> With a totally bare CoCo 1, 2, or 3 you can plug in the pak, turn the CoCo
> on, type DOS and within 5 seconds you're sitting at a NitrOS-9 prompt. ?You
> don't HAVE to do that. ?You can make it where drive 0 has a game disk
> mounted automatically on power-up, or the system disk, etc.
>
> Right now only the NitrOS-9 L2 6809 version is on the pak. ?In a few days
> I'll have an L1 version and depending on what CoCo you have the pak in, the
> compatible boot disk will be used automatically when the DOS command is
> used. ?I haven't included the details of some of my schemes because it'll
> get me off on a serious tangent, but I'm making the pak as plug-and-play as
> possible so it can be used to "save a CoCo", so to speak, bring 'er back
> from the dead with thousands of games and apps without needing anything else
> but the little pak. ?Btw, it's the size of a game pak.
>
> Back to work!
>
> Roger Taylor
>
> --
> ~ Roger Taylor
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From random_rodder at yahoo.com  Sun Nov  8 19:50:52 2009
From: random_rodder at yahoo.com (Brian Blake)
Date: Sun, 8 Nov 2009 16:50:52 -0800 (PST)
Subject: [Coco] CoCoNet status
Message-ID: <135190.80868.qm@web43140.mail.sp1.yahoo.com>

The schematic for a replacement MPI is on coco3.com. 

Sent from Brian's iPhone

On Nov 8, 2009, at 7:34 PM, mike delyea <mdelyea at gmail.com> wrote:

I don't have a multipak.  In addition, I want to keep using my
floppies for RSDOS and booting my floppies for NitrosO9.  How can I
use my floppies and use Roger's pak at the same time?  There seems to
be many talented hardware guys in our community, why don't we have a
replacement for the multipak?  I'd like to have a hard drive (for
NitrosO9 AND my floppies AND Roger's pak and a real serial  port and a
parallel port (I've got a mint HP Laserjet 4 I'm dying to get working
with my coco and a serial modem I'd like to hook up and run a REAL
coco BBS).  I am really hankering after Roy's VGA converter too.  I'm
looking at the prices of these things (pak, hd, vga) and I'm looking
at $300+ (and that's not counting the serial/parallel pak (which
doesn't exist either)).  I want to buy things from Cloud Nine and Roy
and Roger but I just don't have the cash right now.  And even if I had
the cash, I wouldn't have a multipak to plug the stuff into.  I don't
even think you can buy a fracking Y cable these days. Hardware people
- build the MP replacement so I can plug the hardware in.

On Sun, Nov 8, 2009 at 2:30 PM, Roger Taylor <operator at coco3.com> wrote:

Hey dudes and dudettes, how about a little update on that "thing" called
CoCoNet and the progress of the MicroSD drive pak, etc.  I have been getting
e-mails asking about these things but it's hard to get into lengthy
discussions with each person or I would have no time for anything else.
 Sometimes a good update will answer a lot of questions at once.

First, I can only produce these things efficiently and deliver pending
orders on-time, if I get new orders.  I'm sure this is exactly how any
business works, and I'm being bold to say that I feel like Cloud-9 works
this way as well.  That's my 2 cents on the Cloud-9 topic.  Nobody's doing
anybody wrong or looking down on anybody.  People are simply GOING THROUGH
ROUGH TIMES since a certain date back in 2008.  Anybody else who's
successful enough at something to admit they're not having problems, is
Lucky For Now.  They're coming to get ya, that's for sure.  The middle class
picks up the tab, folks, one way or another.  Enough of that.

I'm asking that every die-hard CoCo user out there who wants the ultimate
experience to consider three people in your next purchase of a CoCo gadget.
 All 3 people make items that are designed to KEEP THE COCO ALIVE.
These people are: Roger Taylor (myself), Mark Marlette, and Roy Justus (VGA
Adaptor box). If I left anybody out, please step forward and tell us what
you've been working your ass off for years to develop for the CoCo community
and you are instantly a hit in my book.

About CoCoNet.  It's not Ghostware.  I've been running it for over a year as
I write it and CONTINUOUSLY reburn EPROMs in my tests.

CoCoNet is a collection of features added to Disk BASIC 1.1 and is burned to
an EPROM that can be used in the Deluxe Wireless RS-232 Pak or the upcoming
1GB drive pak, or your own floppy controller.
It's a 16K ROM that works in any CoCo with Extended BASIC, or any CoCo 3 of
course.   In other words, "CoCoNet works with any CoCo that has Extended
BASIC".

You can take one of my serial paks (with the TTL header) and plug in either
an EB301 bluetooth module or MicroSD drive module, plug in the CoCoNet
EPROM, and you get as many features possible Automatically.
Btw, my Deluxe Wireless Pak and drive pak both are just the serial pak with
the right module plugged in and the address configured for either $FF68 or
$FF6C.

As complicated as all of this may sound, it really is plug and play, plug
and go, or whatever you want to call an out of the box ready pak.

I've got a few more days, maybe a week, of fine tuning before I release the
16K CoCoNet 1.0 ROM image for those who have their own burners and want to
give it a try.  I will burn EPROMs for a few bucks plus postage, but the
client ROM is free since people are going to share it anyway.  The CoCoNet
server applet for Windows will be free as well for the same reason.

Since the client (CoCo) ROM and the PC server software will be free, it's a
free "product".  You can boot to the ROM and with the right cartridges
plugged into your MPI you can customize your own setup.

What I make and sell to help clear off your desk of bulky power hungry
gadgets is the Deluxe Wireless RS-232 Pak (bluetooth to PC) which pretty
much clones the Tandy RS-232 Pak but over the air and has an EPROM socket
which I will put the CoCoNet in to give the CoCo an instant wireless virtual
drive system.

I'm also wrapping up on a "drive pak" which will have a built in 1GB MicroSD
drive, also uses the CoCoNet ROM, and gives AT LEAST 256 virtual floppies,
huge hard drives, and any other kinds of partitions you want to add.  Disk
BASIC will use up to 256 720K disks in one partition at a time, OS-9 can
have mass drives of any size and also use the floppies... a NitrOS-9 boot
disk is already on my own pak and fires up with all the drivers and module
directories so you can build other disks or mass drives that boot using the
pak, etc.  You know the drill.

I think this answers the question of "how can I get disks onto my drive
pak?", although the distro pak will be prestocked with lots of goodies.
With CoCoNet, you can mix and match 4 or 5 different TYPES of floppy disks
on DRIVES 0-3, and copy between them if you like.

115200 bps bitbanger virtual floppy disks (remote PC pathname or web URL)
       DRIVE 0,!"http://www.coco3.com/nitros9boot.dsk"
       DRIVE 1,!"http://www.coco3.com/games.dsk"
       DRIVE 2,!"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
115200 bps RS-232 Pak virtual floppy disks (remote PC pathname or web URL)
       DRIVE 0,"http://www.coco3.com/nitros9boot.dsk"
       DRIVE 1,"http://www.coco3.com/games.dsk"
       DRIVE 2,"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
MicroSD virtual disks (using a "drive pak")
       DRIVE 0;100  mounts disk #100 on drive 0
MicroSD LSN-based disks
       DRIVE 0;0,11,65   mounts a floppy starting at any LSN you want
Real 1793 controller floppy disks
       DRIVE 0,ON      turns ON REAL DRIVE #0
       DRIVE 0,OFF     returns to virtual drive prior

With a totally bare CoCo 1, 2, or 3 you can plug in the pak, turn the CoCo
on, type DOS and within 5 seconds you're sitting at a NitrOS-9 prompt.  You
don't HAVE to do that.  You can make it where drive 0 has a game disk
mounted automatically on power-up, or the system disk, etc.

Right now only the NitrOS-9 L2 6809 version is on the pak.  In a few days
I'll have an L1 version and depending on what CoCo you have the pak in, the
compatible boot disk will be used automatically when the DOS command is
used.  I haven't included the details of some of my schemes because it'll
get me off on a serious tangent, but I'm making the pak as plug-and-play as
possible so it can be used to "save a CoCo", so to speak, bring 'er back
from the dead with thousands of games and apps without needing anything else
but the little pak.  Btw, it's the size of a game pak.

Back to work!

Roger Taylor

--
~ Roger Taylor



--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From jmichea at cogeco.ca  Sun Nov  8 20:20:39 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Sun, 8 Nov 2009 20:20:39 -0500
Subject: [Coco] Cloud-9 Tech
Message-ID: <006701ca60da$d95f7810$ecfd3918@jeremy4b3f9678>

Hi, I was wondering if anyone from cloud9tech would be able to let me know the update of an order I placed back on October 26th. I sent a paypal payment but have no idea if its been shipped or not. Could someone please look into it for me and let me know? It was for a coco 3 keyboard and 3 rompaks
Thanks for your time

PS - you can email me directly at windsor_kijiji at yahoo.ca


From tjseagrove at writeme.com  Sun Nov  8 20:06:28 2009
From: tjseagrove at writeme.com (Tom Seagrove)
Date: Sun, 8 Nov 2009 20:06:28 -0500
Subject: [Coco] CoCoNet status
In-Reply-To: <135190.80868.qm@web43140.mail.sp1.yahoo.com>
References: <135190.80868.qm@web43140.mail.sp1.yahoo.com>
Message-ID: <003f01ca60d8$de611ff0$9b235fd0$@com>

I bought one of Chris Hawkes Slot Pak III's at the Atlanta Fest in Fall
1990.  It had 3 slots and was all in a floppy case so not at all big.  Maybe
Chris still has schematics or could whip up a few...  :)

I still have mine and it may get some use here in the near future as long as
I can find the right power adapter for it. hehe

Tom

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Brian Blake
Sent: Sunday, November 08, 2009 7:51 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] CoCoNet status

The schematic for a replacement MPI is on coco3.com. 

Sent from Brian's iPhone

On Nov 8, 2009, at 7:34 PM, mike delyea <mdelyea at gmail.com> wrote:

I don't have a multipak.  In addition, I want to keep using my
floppies for RSDOS and booting my floppies for NitrosO9.  How can I
use my floppies and use Roger's pak at the same time?  There seems to
be many talented hardware guys in our community, why don't we have a
replacement for the multipak?  I'd like to have a hard drive (for
NitrosO9 AND my floppies AND Roger's pak and a real serial  port and a
parallel port (I've got a mint HP Laserjet 4 I'm dying to get working
with my coco and a serial modem I'd like to hook up and run a REAL
coco BBS).  I am really hankering after Roy's VGA converter too.  I'm
looking at the prices of these things (pak, hd, vga) and I'm looking
at $300+ (and that's not counting the serial/parallel pak (which
doesn't exist either)).  I want to buy things from Cloud Nine and Roy
and Roger but I just don't have the cash right now.  And even if I had
the cash, I wouldn't have a multipak to plug the stuff into.  I don't
even think you can buy a fracking Y cable these days. Hardware people
- build the MP replacement so I can plug the hardware in.

On Sun, Nov 8, 2009 at 2:30 PM, Roger Taylor <operator at coco3.com> wrote:

Hey dudes and dudettes, how about a little update on that "thing" called
CoCoNet and the progress of the MicroSD drive pak, etc.  I have been getting
e-mails asking about these things but it's hard to get into lengthy
discussions with each person or I would have no time for anything else.
 Sometimes a good update will answer a lot of questions at once.

First, I can only produce these things efficiently and deliver pending
orders on-time, if I get new orders.  I'm sure this is exactly how any
business works, and I'm being bold to say that I feel like Cloud-9 works
this way as well.  That's my 2 cents on the Cloud-9 topic.  Nobody's doing
anybody wrong or looking down on anybody.  People are simply GOING THROUGH
ROUGH TIMES since a certain date back in 2008.  Anybody else who's
successful enough at something to admit they're not having problems, is
Lucky For Now.  They're coming to get ya, that's for sure.  The middle class
picks up the tab, folks, one way or another.  Enough of that.

I'm asking that every die-hard CoCo user out there who wants the ultimate
experience to consider three people in your next purchase of a CoCo gadget.
 All 3 people make items that are designed to KEEP THE COCO ALIVE.
These people are: Roger Taylor (myself), Mark Marlette, and Roy Justus (VGA
Adaptor box). If I left anybody out, please step forward and tell us what
you've been working your ass off for years to develop for the CoCo community
and you are instantly a hit in my book.

About CoCoNet.  It's not Ghostware.  I've been running it for over a year as
I write it and CONTINUOUSLY reburn EPROMs in my tests.

CoCoNet is a collection of features added to Disk BASIC 1.1 and is burned to
an EPROM that can be used in the Deluxe Wireless RS-232 Pak or the upcoming
1GB drive pak, or your own floppy controller.
It's a 16K ROM that works in any CoCo with Extended BASIC, or any CoCo 3 of
course.   In other words, "CoCoNet works with any CoCo that has Extended
BASIC".

You can take one of my serial paks (with the TTL header) and plug in either
an EB301 bluetooth module or MicroSD drive module, plug in the CoCoNet
EPROM, and you get as many features possible Automatically.
Btw, my Deluxe Wireless Pak and drive pak both are just the serial pak with
the right module plugged in and the address configured for either $FF68 or
$FF6C.

As complicated as all of this may sound, it really is plug and play, plug
and go, or whatever you want to call an out of the box ready pak.

I've got a few more days, maybe a week, of fine tuning before I release the
16K CoCoNet 1.0 ROM image for those who have their own burners and want to
give it a try.  I will burn EPROMs for a few bucks plus postage, but the
client ROM is free since people are going to share it anyway.  The CoCoNet
server applet for Windows will be free as well for the same reason.

Since the client (CoCo) ROM and the PC server software will be free, it's a
free "product".  You can boot to the ROM and with the right cartridges
plugged into your MPI you can customize your own setup.

What I make and sell to help clear off your desk of bulky power hungry
gadgets is the Deluxe Wireless RS-232 Pak (bluetooth to PC) which pretty
much clones the Tandy RS-232 Pak but over the air and has an EPROM socket
which I will put the CoCoNet in to give the CoCo an instant wireless virtual
drive system.

I'm also wrapping up on a "drive pak" which will have a built in 1GB MicroSD
drive, also uses the CoCoNet ROM, and gives AT LEAST 256 virtual floppies,
huge hard drives, and any other kinds of partitions you want to add.  Disk
BASIC will use up to 256 720K disks in one partition at a time, OS-9 can
have mass drives of any size and also use the floppies... a NitrOS-9 boot
disk is already on my own pak and fires up with all the drivers and module
directories so you can build other disks or mass drives that boot using the
pak, etc.  You know the drill.

I think this answers the question of "how can I get disks onto my drive
pak?", although the distro pak will be prestocked with lots of goodies.
With CoCoNet, you can mix and match 4 or 5 different TYPES of floppy disks
on DRIVES 0-3, and copy between them if you like.

115200 bps bitbanger virtual floppy disks (remote PC pathname or web URL)
       DRIVE 0,!"http://www.coco3.com/nitros9boot.dsk"
       DRIVE 1,!"http://www.coco3.com/games.dsk"
       DRIVE 2,!"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
115200 bps RS-232 Pak virtual floppy disks (remote PC pathname or web URL)
       DRIVE 0,"http://www.coco3.com/nitros9boot.dsk"
       DRIVE 1,"http://www.coco3.com/games.dsk"
       DRIVE 2,"c:\program filers\rainbow ide\projects\disks\mynewgame.dsk"
MicroSD virtual disks (using a "drive pak")
       DRIVE 0;100  mounts disk #100 on drive 0
MicroSD LSN-based disks
       DRIVE 0;0,11,65   mounts a floppy starting at any LSN you want
Real 1793 controller floppy disks
       DRIVE 0,ON      turns ON REAL DRIVE #0
       DRIVE 0,OFF     returns to virtual drive prior

With a totally bare CoCo 1, 2, or 3 you can plug in the pak, turn the CoCo
on, type DOS and within 5 seconds you're sitting at a NitrOS-9 prompt.  You
don't HAVE to do that.  You can make it where drive 0 has a game disk
mounted automatically on power-up, or the system disk, etc.

Right now only the NitrOS-9 L2 6809 version is on the pak.  In a few days
I'll have an L1 version and depending on what CoCo you have the pak in, the
compatible boot disk will be used automatically when the DOS command is
used.  I haven't included the details of some of my schemes because it'll
get me off on a serious tangent, but I'm making the pak as plug-and-play as
possible so it can be used to "save a CoCo", so to speak, bring 'er back
from the dead with thousands of games and apps without needing anything else
but the little pak.  Btw, it's the size of a game pak.

Back to work!

Roger Taylor

--
~ Roger Taylor



--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From aawolfe at gmail.com  Sun Nov  8 20:46:42 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 20:46:42 -0500
Subject: [Coco] os9/drivewire driver: success!
Message-ID: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>

I am super pleased to report, despite many remaining issues, I now
have a working terminal over the drivewire.  So a single cable is
proving disk, clock, print *and* a terminal on T2!  Drivewire is so
nice.  Now I need to flesh out the driver, its very incomplete, but
the concept works.  I am so excited :)

I had things sort of working all along, I just didn't understand that
Read is supposed to sleep until it can get a byte.  I was returning
when I had nothing, causing the problems I mentioned in earlier posts.

Here is an example of things working now (note process 3, this is the
shell on T2, which is using stdin/stout on my linux box, and where I'm
typing the commands). For now I've modified the drivewire server to
have no display, and just put stdin into the virtual serial port's
read buffer, write bytes from the virtual serial port to stdout.


debian-dev:~/os9/drivewireserver/linux/build# ./drivewire
(at this point I boot the Coco and type SHELL I=/T2 &.. )

Shell


OS9:dir


 Directory of .  2009/11/08 20:32
OS9Boot         CMDS            SYS             DEFS            startup
NITROS9


OS9:procs


Usr #  id pty  state   mem primary module
----- --- --- -------- --- --------------
    0   3 128  active    3 Shell <t2
    0   1 128  waiting   1 SysGo <TERM
    0   2 128 sleeping   3 Shell <TERM


OS9:mdir


  Module directory at 20:33:59
REL         Krn         KrnP2       Init        Boot
IOMan       rbdw3       dw3         DD          X1
X2          X3          RBF         rb1773      D0
D1          D2          SCF         VTIO        CoVDG
TERM        scdwp       p           scbbt       T1
scdws       t2          PipeMan     Piper       Pipe
Clock       Clock2      SysGo       Shell       Mdir



OS9:


From boisy at tee-boy.com  Sun Nov  8 20:51:37 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sun, 8 Nov 2009 19:51:37 -0600
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <006701ca60da$d95f7810$ecfd3918@jeremy4b3f9678>
References: <006701ca60da$d95f7810$ecfd3918@jeremy4b3f9678>
Message-ID: <6F40A9B2-57F3-4B24-BFEB-E04DB5F94F3F@tee-boy.com>

Jeremy,

This sounds like an order Mark is handling.  I'll have to let him  
respond, and will forward the email to him.

Boisy

On Nov 8, 2009, at 7:20 PM, Jeremy Michea wrote:

> Hi, I was wondering if anyone from cloud9tech would be able to let  
> me know the update of an order I placed back on October 26th. I sent  
> a paypal payment but have no idea if its been shipped or not. Could  
> someone please look into it for me and let me know? It was for a  
> coco 3 keyboard and 3 rompaks
> Thanks for your time
>
> PS - you can email me directly at windsor_kijiji at yahoo.ca
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From boisy at tee-boy.com  Sun Nov  8 20:54:11 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sun, 8 Nov 2009 19:54:11 -0600
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
References: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
Message-ID: <F02DE0A0-0023-471B-94BE-4FBD3186DF13@tee-boy.com>

On Nov 8, 2009, at 7:46 PM, Aaron Wolfe wrote:

> I am super pleased to report, despite many remaining issues, I now
> have a working terminal over the drivewire.  So a single cable is
> proving disk, clock, print *and* a terminal on T2!  Drivewire is so
> nice.  Now I need to flesh out the driver, its very incomplete, but
> the concept works.  I am so excited :)
>
> I had things sort of working all along, I just didn't understand that
> Read is supposed to sleep until it can get a byte.  I was returning
> when I had nothing, causing the problems I mentioned in earlier posts.

Of course... V.BUSY/V.WAKE.  It's amazing what you forget when you  
haven't stuck your head into something for a while.

> Here is an example of things working now (note process 3, this is the
> [...]
> OS9:

You rock, man!  Great work!

What's your next step?

Boisy




From aawolfe at gmail.com  Sun Nov  8 21:04:35 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 8 Nov 2009 21:04:35 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <F02DE0A0-0023-471B-94BE-4FBD3186DF13@tee-boy.com>
References: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
	<F02DE0A0-0023-471B-94BE-4FBD3186DF13@tee-boy.com>
Message-ID: <e44ad6640911081804o7ad6c66bg3589a98adbcc7195@mail.gmail.com>

On Sun, Nov 8, 2009 at 8:54 PM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> On Nov 8, 2009, at 7:46 PM, Aaron Wolfe wrote:
>
>> I am super pleased to report, despite many remaining issues, I now
>> have a working terminal over the drivewire. ?So a single cable is
>> proving disk, clock, print *and* a terminal on T2! ?Drivewire is so
>> nice. ?Now I need to flesh out the driver, its very incomplete, but
>> the concept works. ?I am so excited :)
>>
>> I had things sort of working all along, I just didn't understand that
>> Read is supposed to sleep until it can get a byte. ?I was returning
>> when I had nothing, causing the problems I mentioned in earlier posts.
>
> Of course... V.BUSY/V.WAKE. ?It's amazing what you forget when you haven't
> stuck your head into something for a while.
>
>> Here is an example of things working now (note process 3, this is the
>> [...]
>> OS9:
>
> You rock, man! ?Great work!
>
> What's your next step?

Well, first I've got to improve the driver to actually handle errors
and be more efficient (flush entire buffer instead of character by
character, etc).

The long term goal is twofold: first to implement a useful full screen
terminal with coco control codes translated into curses operations.
second, to make a "modem" in the server, this is what really interests
me.  the "modem" will respond to standard hayes commands, but connect
to IP sockets.  So, an OS9 terminal program might send
ATD192.168.1.1:4000, the server will connect to 192.168.1.1 via TCP,
send CONNECT to the Coco, and then connect input/output.   For
incoming connections, the server will listen on a port and send "RING"
or maybe set RI high, then connect the incoming tcp connection.

Ultimately, this will allow one Coco to dial another Coco (BBS, etc),
over the internet :)


From deyoung at gmail.com  Sun Nov  8 20:44:50 2009
From: deyoung at gmail.com (Joel DeYoung)
Date: Sun, 8 Nov 2009 17:44:50 -0800
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>
	<4AF6441B.5040708@swbell.net>
	<1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
Message-ID: <da3887680911081744h38497685jf5d40a0e1af568ae@mail.gmail.com>

Wow--thanks for posting this!  Best game on the CoCo... ever... way ahead of
its time.

Joel


On Sun, Nov 8, 2009 at 4:00 PM, mike delyea <mdelyea at gmail.com> wrote:

> That was THE best game for the coco!  A<space R>,  A<space R>,
> A<space R>, M, M, M, M, T<space>A.  I swear my heart was beating as
> fast the character's heart.
>
> On Sat, Nov 7, 2009 at 11:07 PM, Joel Ewy <jcewy at swbell.net> wrote:
> > J.P. Samson wrote:
> >>
> >> Since I seem to be into transitioning old CoCo manuals to digital form,
> I
> >> thought I'd pass along my rendition of the manual for Dungeons of
> Daggorath.
> >>  This one's a labor of love--I don't want to think about how many days
> of
> >> scanning and image cleanup I undertook.  The resulting PDF is bookmarked
> and
> >> searchable.  It even includes a linked table of contents and a copy of
> the
> >> game itself in its attachments.
> >>
> >>
> >> <
> https://docs.google.com/fileview?id=0B5WL6q8cbexONmI4MTlhOTAtMDFlMy00OWQyLTkzYzMtYjNhMjNjZjA5ZWVh&hl=en
> >
> >>
> >> -- JP
> >>
> >>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> >>
> > Wow.  The work shows.  This is not a slap-dash scan job.  Thanks.
> >
> > JCE
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From brucewcalkins at charter.net  Sun Nov  8 21:29:06 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Sun, 8 Nov 2009 21:29:06 -0500
Subject: [Coco] Dungeons of Daggorath Program Manual
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com><4AF6441B.5040708@swbell.net><1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
	<da3887680911081744h38497685jf5d40a0e1af568ae@mail.gmail.com>
Message-ID: <56266E27C62B4321A4FA9F2F8D5861FE@speedy>

Any chance the PDF can be uploaded to Malted-Media.

Bruce W.



----- Original Message ----- 
From: "Joel DeYoung"

> Wow--thanks for posting this!  Best game on the CoCo... ever... way ahead 
> of
> its time.
>
> Joel
>

>> > J.P. Samson wrote:
>> >>
>> >> -- JP 



From asa.rand at yahoo.com  Sun Nov  8 22:34:26 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sun, 8 Nov 2009 19:34:26 -0800 (PST)
Subject: [Coco] some results
Message-ID: <513580.67794.qm@web53710.mail.re2.yahoo.com>

I found that the endless loop error was my own doing. In all of the testing I've done, I always made sure the parameter string contained the correct filename. Because I was testing the parameter before I initialized anything, 'er' was a random number. Also, the file open status booleans were showing up as true when they should have been false. Moving the initializations for those variables before the parameter test corrected that issue.

Now for the bad news. The program still won't run. It reaches the first subroutine call for GFX2 and errors with a 43 error. This means it could not find the procedure in its workspace. This is because there is insufficient memory allocated to run it. Raising the workspace memory size reduces the amount of other ram Basic09 has for loading called subroutines that are pre-loaded or read from a disk file. This means I have to reduce the workspace size. The program loads into 35K of workspace memory. I reduce that to 27000 and I have a little more than the minimum data space requirement for the procedures' variables.

Trying to go down to 26000 reduces the memory to less than the needs of the procedures. I am finding that Basic09's memory command is broken. For example, I can type mem 32000 and it will increase or decrease to that amount. Likewise, I can do the same with 34000. But if I specify 33000, I get "What?"!

And that isn't the only memory specifier it has problems with. It won't let me set memory levels like 26500, or 18512.

Packing the code helps, a little. I can reduce the memory requirement lower, but I can't free up enough to allow GFX2 to load into the workspace. I try running it from the command line. At the same point in execution, RunB reports a 67 error. This means there is an illegal parameter in the run statement. I've double checked the settings, and the run statement is correct. It ran before, but it doesn't now.

I can only assume it has something to do with the way memory is being allocated to the program, whether in the Basic09 environment, or through RunB on the system command line.

I think I neglected to mention that fmato, until now, has been a single procedure. I wanted to try to do everything needed to identify, count and store everything the instruction code has to offer. I have done that. Now I am displaying the data, and performing sorts and renumbers to the data files. The Variables file is the only one not furthur processed, because that step requires matching the references to the VDT, the DSAT, and the data memory. Once that is done, I can recreate the TYPE, DIM and PARAM statements for the procedure being decoded.

I have just installed the code to sort and renumber the Literals file. It was this installation that brought the problem to the forefront. I have now broken it up into more procedures, isolating the search and add reference routines in separate procedures, and then the line reference sort and renumber, followed by the literal reference sort and renumber. The code prior to the installation of the literal sort routine worked without flaw. All of the data is correct, and the overlay windows functioned as expected. The text on the main screen is organized to make it easier to understand what you are seeing.

It all works. The break occurred when I added the literal sort and renumber routine. Because of how far down the program this occurs, there is no valid reason I can think of that would break the rest of the code, other than not enough memory.

Now that I have split it up into different procedures, modifying the searches and sorts will be easier to manage. Currently, they work, but are very slow. The searches are simple linear search until a match is found or the last record is read and compared. The sorts I had to modify from that because the linear sort took way too long. It uses a method that sorts from top-to-bottom, then bottom-to-top for each pass of the main repeat loop. It's definitely faster than the linear method, but it still isn't fast enough. For now, though, it's enough that they work. At least I can rely on the data, even if the display code does get in the way.

I have tried using the memory modifier on the command line, such as:

fmato createmsg - works with my shell
67 - illegal argument

fmato "createmsg" - breaks with my shell
(""createmsg"")
   ^
10 - unrecognized symbol (it doesn't like the extra quotes)

fmato createmsg #32k - results in the error:
43 - procedure not found

runb fmato createmsg #32k
43 - procedure not found

dir -x results show fmato as the 5th file in my commands directory.

It seems it doesn't like the memory modifier either.

I have been working on finding a way to reduce the code size. One thing I tried was using a specific set of variables to act as constants. This way, I can just use a variable to reference a value that is repeated multiple times. On byte literals, it increases the instruction code size, because it takes three bytes to reference a variable, but only two to reference a byte. It can be more useful with integers, as there are more than a few that are referenced multiple times. All hex literals are stored as integers, so there is no loss in size, and no gain in size. String literals are the only real candidates for saving space, but with many of them, it would require creating single word strings of specific length and size for the shared portions, and either the same for the remainders, or they can be left as literal constants. How much space would be saved? I don't know yet.

I will put a copy of fmato's source on sourceforge for anyne who wants to look at it or try to run it.

Wayne



      


From asa.rand at yahoo.com  Sun Nov  8 22:55:33 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sun, 8 Nov 2009 19:55:33 -0800 (PST)
Subject: [Coco] uploaded to sourceforge
Message-ID: <248061.8734.qm@web53701.mail.re2.yahoo.com>

I put two files in a folder named fmato. The first is fmato3.B09. That is the last single-procedure version. fmato4.B09 is the version with the search/add and sort/renum functions separated into different procedures.

Wayne



      


From robert.gault at worldnet.att.net  Sun Nov  8 23:24:30 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Sun, 08 Nov 2009 23:24:30 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <3F97C93F69BB42728765C3C6C4B2705F@Crossfire>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com><32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>	<e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
	<3F97C93F69BB42728765C3C6C4B2705F@Crossfire>
Message-ID: <4AF7997E.1080501@worldnet.att.net>

Lothan wrote:
> Given the layout of the register postbyte, PULS A,B is exactly the same
> as PULS D (e.g. the postbyte is $05 in either case), so PULS A,D and
> PULS B,D and PULS A,B,D should in theory all compile exactly the same as
> PULS A,B or PULS D.
>
> Someone feel free to smack me with a clue stick if I have that wrong.

No smack, but you might consider this.

PULS A,B and PULS D both give $35 $06. So, the post byte is 6 not 5. The 
other constructs don't make any sense and a good assembler should report 
an error. After all, you are asking for an ambiguous action. What values 
are going to be put in regs A & B if you ask for PULS A,D?

EDTASM gives Register Error for a multiple pull/push of the same register.


From robert.gault at worldnet.att.net  Sun Nov  8 23:35:52 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Sun, 08 Nov 2009 23:35:52 -0500
Subject: [Coco] some results
In-Reply-To: <513580.67794.qm@web53710.mail.re2.yahoo.com>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com>
Message-ID: <4AF79C28.8010302@worldnet.att.net>

Wayne Campbell wrote:
>
> Trying to go down to 26000 reduces the memory to less than
 > the needs of the procedures. I am finding that Basic09's memory
 > command is broken. For example, I can type mem 32000 and it will
 > increase or decrease to that amount. Likewise, I can do the same
 > with 34000. But if I specify 33000, I get "What?"!

There is a good chance you have some code mismatches between your 
Basic09 and the OS-9 versions. On my system, I can smoothly ask for 
memory within Basic09 up to mem 32760 giving 32767. I get What? trying 
for 32770, or any number higher including 34000.


From coco+list at jeanpaulsamson.com  Sun Nov  8 23:53:09 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Sun, 8 Nov 2009 21:53:09 -0700
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <56266E27C62B4321A4FA9F2F8D5861FE@speedy>
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com><4AF6441B.5040708@swbell.net><1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
	<da3887680911081744h38497685jf5d40a0e1af568ae@mail.gmail.com>
	<56266E27C62B4321A4FA9F2F8D5861FE@speedy>
Message-ID: <EA7EDC67-8F13-43F0-A294-E0002966DCED@jeanpaulsamson.com>

On Nov-8-09, at 7:29 PM, Bruce W. Calkins wrote:
> Any chance the PDF can be uploaded to Malted-Media.

I uploaded the DoD manual to the MaltedMedia /incoming directory.  The  
file is entitled:  "Dungeons of Daggorath (DynaMicro Inc.,  
1982).pdf".  Dunno who gets to move it into its proper place so that  
others can then download.

-- JP



From lothan at newsguy.com  Mon Nov  9 00:29:19 2009
From: lothan at newsguy.com (Lothan)
Date: Mon, 9 Nov 2009 00:29:19 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <4AF7997E.1080501@worldnet.att.net>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com><32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>	<e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com><3F97C93F69BB42728765C3C6C4B2705F@Crossfire>
	<4AF7997E.1080501@worldnet.att.net>
Message-ID: <0D17CE712F7144D8976CD174671F15FF@Crossfire>

Sheesh... I can't add today. You're right $04 + $02 is $06. I agree the 
other constructs don't make sense, but the result should be either logically 
OR'ing the register postbyte codes such that PULS A,B,D is the same as PULS 
D or PULS A,B (assuming it's just blindly picking through the 
comma-delimited register list) or raising an error that the list doesn't 
make any sense.

--------------------------------------------------
From: "Robert Gault" <robert.gault at worldnet.att.net>
Sent: Sunday, November 08, 2009 11:24 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver problems

> Lothan wrote:
>> Given the layout of the register postbyte, PULS A,B is exactly the same
>> as PULS D (e.g. the postbyte is $05 in either case), so PULS A,D and
>> PULS B,D and PULS A,B,D should in theory all compile exactly the same as
>> PULS A,B or PULS D.
>>
>> Someone feel free to smack me with a clue stick if I have that wrong.
>
> No smack, but you might consider this.
>
> PULS A,B and PULS D both give $35 $06. So, the post byte is 6 not 5. The 
> other constructs don't make any sense and a good assembler should report 
> an error. After all, you are asking for an ambiguous action. What values 
> are going to be put in regs A & B if you ask for PULS A,D?
>
> EDTASM gives Register Error for a multiple pull/push of the same register.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 


From aawolfe at gmail.com  Mon Nov  9 00:37:39 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 00:37:39 -0500
Subject: [Coco] os9/drivewire driver problems
In-Reply-To: <0D17CE712F7144D8976CD174671F15FF@Crossfire>
References: <e44ad6640911080358x163613dv763b8941bca0349c@mail.gmail.com>
	<32997F80-6DD4-4D0F-80DF-E91C43205F37@tee-boy.com>
	<e44ad6640911081446q3a13d638mf3f7a8d30ebb4338@mail.gmail.com>
	<3F97C93F69BB42728765C3C6C4B2705F@Crossfire>
	<4AF7997E.1080501@worldnet.att.net>
	<0D17CE712F7144D8976CD174671F15FF@Crossfire>
Message-ID: <e44ad6640911082137j4d387fc8y27490282a8e395ae@mail.gmail.com>

Just a note, my original code that pulled D and A from the stack at
the same time was a total mistake, due to my misunderstanding of..
well most everything :)  I've got that sorted now.

On Mon, Nov 9, 2009 at 12:29 AM, Lothan <lothan at newsguy.com> wrote:
> Sheesh... I can't add today. You're right $04 + $02 is $06. I agree the
> other constructs don't make sense, but the result should be either logically
> OR'ing the register postbyte codes such that PULS A,B,D is the same as PULS
> D or PULS A,B (assuming it's just blindly picking through the
> comma-delimited register list) or raising an error that the list doesn't
> make any sense.
>
> --------------------------------------------------
> From: "Robert Gault" <robert.gault at worldnet.att.net>
> Sent: Sunday, November 08, 2009 11:24 PM
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Subject: Re: [Coco] os9/drivewire driver problems
>
>> Lothan wrote:
>>>
>>> Given the layout of the register postbyte, PULS A,B is exactly the same
>>> as PULS D (e.g. the postbyte is $05 in either case), so PULS A,D and
>>> PULS B,D and PULS A,B,D should in theory all compile exactly the same as
>>> PULS A,B or PULS D.
>>>
>>> Someone feel free to smack me with a clue stick if I have that wrong.
>>
>> No smack, but you might consider this.
>>
>> PULS A,B and PULS D both give $35 $06. So, the post byte is 6 not 5. The
>> other constructs don't make any sense and a good assembler should report an
>> error. After all, you are asking for an ambiguous action. What values are
>> going to be put in regs A & B if you ask for PULS A,D?
>>
>> EDTASM gives Register Error for a multiple pull/push of the same register.
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From coco+list at jeanpaulsamson.com  Mon Nov  9 00:42:15 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Sun, 8 Nov 2009 22:42:15 -0700
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com>
	<4AF6441B.5040708@swbell.net>
	<1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com>
Message-ID: <006C62E7-79FB-4A13-AC65-345E50E750FE@jeanpaulsamson.com>

>> J.P. Samson wrote:
>>>
>>> Since I seem to be into transitioning old CoCo manuals to digital  
>>> form, I
>>> thought I'd pass along my rendition of the manual for Dungeons of  
>>> Daggorath.

On Nov-8-09, at 5:00 PM, mike delyea wrote:
> That was THE best game for the coco!  A<space R>,  A<space R>,
> A<space R>, M, M, M, M, T<space>A.  I swear my heart was beating as
> fast the character's heart.


Thanks for everyone's gushing comments about the quality of the  
manual.  I never owned DoD, being a kid at the time and having no  
money to spend on Radio Shack's rather pricey Program Paks.  Anyways,  
I stuck with the more kid friendly shoot-em-up games such as Time  
Bandit or Zaxxon.

I know I tried a pirated copy of the game in its day, but without a  
manual, good luck figuring anything out!  Now, in my adulthood, I was  
able to buy a copy of the game off an auction site, but haven't the  
time to get into playing it!  Oh, to be a kid again!

-- JP



From aawolfe at gmail.com  Mon Nov  9 01:36:20 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 01:36:20 -0500
Subject: [Coco] drivewire serial port: term_win80.dt vs my code
Message-ID: <e44ad6640911082236t7da25f5x5e2172fc62767f82@mail.gmail.com>

So, things were going so well with my serial over DW project that I
decided to merge the driver into my main boot disk.
(My test system was level 1 just because it builds faster and I have
to build a lot)

I've discovered that when I use term_win80 for my coco terminal, i
make my coco insane whenever I try to access my virtual serial port.
read or write makes no difference.  The console goes nuts, usually
switching graphics modes or losing sync altogether and writing
randomish junk everywhere on the screen. no response to keys.
Meanwhile, the operation I invoked on the serial port will actually
run for a few seconds until the machine goes completely out to lunch,
so I can at least see that read and write ops in my driver are
actually working, despite whatever else my driver is doing to the
system.

Switching the console driver to VDG makes everything work fine again..
level 2, 6309, etc all working great with the driver under heavy use.

Any ideas what I've done here?  I'm assuming I have some bug in my
driver that so far only surfaces when term_win80 is around, but I'm
worried it will show up in other places too.  I'm not even sure how to
test this, again apologies for my massive ignorance.

If anyone wants to look, here is the driver code as of now:

********************************************************************
* scdwp.asm - CoCo DriveWire Virtual Serial Driver
*
* most parts copied or only slightly modified from other modules in
the DriveWire project
*
* Aaron Wolfe
* v0.1 11/08/09
*

         nam   scdws
         ttl   CoCo DriveWire Virtual Serial Driver

         ifp1
         use   defsfile
         use   dwdefs.d
         endc

tylg     set   Drivr+Objct
atrv     set   ReEnt+Rev
rev      set   $00
edition  set   1

         mod   eom,name,tylg,atrv,Start,Size

         fcb   READ.+WRITE.

name     fcs   /scdws/
         fcb   edition    one more revision level than the stock printer

* Device memory area: offset from U
         org   V.SCF      V.SCF: free memory for driver to use
V.PAR    rmb   1          1=space, 2=mark parity
V.BIT    rmb   1          0=7, 1=8 bits
V.STP    rmb   1          0=1 stop bit, 1=2 stop bits
V.COM    rmb   2          Com Status baud/parity (=Y from SS.Comst Set/GetStt
V.COL    rmb   1          columns
V.ROW    rmb   1          rows
V.WAIT   rmb   2          wait count for baud rate?
V.TRY    rmb   2          number of re-tries if printer is busy
V.RTRY   rmb   1          low nibble of parity=high byte of number of retries
V.BUFF   rmb   $80        room for 128 blocked processes
RSleep  rmb   1

size     equ   .

start    equ   *
         lbra  Init
         lbra  Read
         lbra  Write
         lbra  GetStt
         lbra  SetStt

* Term
*
* Entry:
*    U  = address of device memory area
*
* Exit:
*    CC = carry set on error
*    B  = error code
*
Term     equ   *
         clrb
         rts

* Init
*
* Entry:
*    Y  = address of device descriptor
*    U  = address of device memory area
*
* Exit:
*    CC = carry set on error
*    B  = error code
*
Init
* set RSleep to 0
         clra
         sta    <RSleep

* Check if D.DWSUB already holds a valid subroutine module pointer
         IFGT  Level-1
         ldx   <D.DWSUB
         ELSE
         ldx   >D.DWSUB
         ENDC
         bne   InitEx

* If here, D.DWSUB is 0, so we must link to subroutine module
         IFGT  Level-1
         ldx   <D.Proc
         pshs  x
         ldx   <D.SysPrc
         stx   <D.Proc
         ENDC
         clra
         leax  dw3name,pcr
         os9   F$Link
         IFGT  Level-1
         puls  x
         stx   <D.Proc
         ENDC
         bcs   InitEx
         IFGT  Level-1
         sty   <D.DWSUB
         ELSE
         sty   >D.DWSUB
         ENDC
         jsr   ,y                       call init routine


InitEx   rts

dw3name  fcs  /dw3/

* Write
*
* Entry:
*    A  = character to write
*    Y  = address of path descriptor
*    U  = address of device memory area
*
* Exit:
*    CC = carry set on error
*    B  = error code
*
Write    equ   *
         tfr   a,b
         lda   #OP_SERWRITE
         pshs  d
         leax  ,s
         ldy   #$0002
         IFGT  Level-1
         ldu   <D.DWSUB
         ELSE
         ldu   >D.DWSUB
         ENDC
         jsr   6,u
* handle errors
        beq     WriteOK
        ldb     #E$Write
        bra     WriteExit
WriteOK   clrb
WriteExit puls  d,pc


* Read - my crazy attempt

Read    equ  *
* see if we should sleep some more - this has got to be the wrong way to do this
        lda     <RSleep
        cmpa    #$00
        bne     ReadSleepAgain
* check if we have data waiting on server
        lda #OP_SERCHECK
        pshs  a
        leax  ,s
        ldy   #$0001
        IFGT  Level-1
        ldu   <D.DWSUB
        ELSE
        ldu   >D.DWSUB
        ENDC
        jsr   6,u
        ldy   #$0001
        leax  ,s
        jsr   3,u
        puls  a
        cmpa  #$00  ; if 00, server buffer is empty
        bne   ReadFromServer
* nothing, lets sleep and try again
        lda   #$FF   ; sleep 256 slices, this seems to = about 8-10
polls per second..
        sta     <RSleep
ReadSleep  ldx #$0001
        os9 F$Sleep  ; sleep for this slice, try again next slice -
probably very wasteful
        bra  Read

ReadSleepAgain
* dec sleep counter - its already in A
        deca
        sta     <RSleep
        bra     ReadSleep

ReadFromServer
        lda   #OP_SERREAD
        pshs  a
        leax  ,s
        ldy   #$0001
        IFGT  Level-1
        ldu   <D.DWSUB
        ELSE
        ldu   >D.DWSUB
        ENDC
* ask for byte
        jsr   6,u
        ldy   #$0001
        leax  ,s
* read byte from server
        jsr   3,u
* handle errors
        beq     ReadOK
        ldb     #E$Read
        bra     ReadExit
ReadOK   clrb
ReadExit puls  a,pc


* GetStat
*
* Entry:
*    A  = function code
*    Y  = address of path descriptor
*    U  = address of device memory area
*
* Exit:
*    CC = carry set on error
*    B  = error code
*
GetStt   cmpa  #SS.EOF          end of file?
         bne   L0112
         clrb                   if so, exit with no error
         rts

L0112    ldx   PD.RGS,y
         cmpa  #SS.ScSiz
         beq   L0123
         cmpa  #SS.ComSt
         bne   L0173
         clra
         clrb
         std   R$Y,x
         clrb
         rts

* get screen size GetStt
L0123    clra
         ldb   #80
         std   R$X,x
         ldb   #24
         std   R$Y,x
         clrb
         rts

* SetStat
*
* Entry:
*    A  = function code
*    Y  = address of path descriptor
*    U  = address of device memory area
*
* Exit:
*    CC = carry set on error
*    B  = error code
*
SetStt
Close    cmpa  #SS.Close        close the device?
         bne   L0173
         lda   #OP_NOP
         pshs  a
         ldy   #$0001
         leax  ,s
         IFGT  Level-1
         ldu   <D.DWSUB
         ELSE
         ldu   >D.DWSUB
         ENDC
         jsr   6,u
         puls  a,pc


L0173    comb
         ldb   #E$UnkSVc
         rts

         emod
eom      equ   *
         end


From jmichea at cogeco.ca  Mon Nov  9 06:45:56 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Mon, 9 Nov 2009 06:45:56 -0500
Subject: [Coco] Cloud-9 Tech
References: <006701ca60da$d95f7810$ecfd3918@jeremy4b3f9678>
	<6F40A9B2-57F3-4B24-BFEB-E04DB5F94F3F@tee-boy.com>
Message-ID: <006101ca6132$32f7cc40$ecfd3918@jeremy4b3f9678>

Ok thanks Boisy. I appreciate it. Please let me know if you hear anything.
Jeremy

----- Original Message ----- 
From: "Boisy G. Pitre" <boisy at tee-boy.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Sunday, November 08, 2009 8:51 PM
Subject: Re: [Coco] Cloud-9 Tech


> Jeremy,
>
> This sounds like an order Mark is handling.  I'll have to let him
> respond, and will forward the email to him.
>
> Boisy
>
> On Nov 8, 2009, at 7:20 PM, Jeremy Michea wrote:
>
>> Hi, I was wondering if anyone from cloud9tech would be able to let
>> me know the update of an order I placed back on October 26th. I sent
>> a paypal payment but have no idea if its been shipped or not. Could
>> someone please look into it for me and let me know? It was for a
>> coco 3 keyboard and 3 rompaks
>> Thanks for your time
>>
>> PS - you can email me directly at windsor_kijiji at yahoo.ca
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.55/2490 - Release Date: 11/08/09 
19:39:00



From brucewcalkins at charter.net  Mon Nov  9 07:14:25 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Mon, 9 Nov 2009 07:14:25 -0500
Subject: [Coco] Dungeons of Daggorath Program Manual
References: <3597352E-440D-499D-939A-8572AE5853F8@jeanpaulsamson.com><4AF6441B.5040708@swbell.net><1b52e6c80911081600v52aa9cebkd892452c3ef41a39@mail.gmail.com><da3887680911081744h38497685jf5d40a0e1af568ae@mail.gmail.com><56266E27C62B4321A4FA9F2F8D5861FE@speedy>
	<EA7EDC67-8F13-43F0-A294-E0002966DCED@jeanpaulsamson.com>
Message-ID: <40DC519A99D745D1984E5896B542CB77@speedy>

Thank you, Dennis has a couple moderators to assist him on that.  It will 
get there.

Bruce W.



----- Original Message ----- 
From: "J.P. Samson"


> On Nov-8-09, at 7:29 PM, Bruce W. Calkins wrote:
>> Any chance the PDF can be uploaded to Malted-Media.
>
> I uploaded the DoD manual to the MaltedMedia /incoming directory.  The 
> file is entitled:  "Dungeons of Daggorath (DynaMicro Inc.,  1982).pdf". 
> Dunno who gets to move it into its proper place so that  others can then 
> download.
>
> -- JP 



From snhirsch at gmail.com  Mon Nov  9 07:43:18 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Mon, 9 Nov 2009 07:43:18 -0500 (EST)
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
References: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0911090740180.4638@duo>

On Sun, 8 Nov 2009, Aaron Wolfe wrote:

> Here is an example of things working now (note process 3, this is the
> shell on T2, which is using stdin/stout on my linux box, and where I'm
> typing the commands). For now I've modified the drivewire server to
> have no display, and just put stdin into the virtual serial port's
> read buffer, write bytes from the virtual serial port to stdout.

Aaron,

Terrific work.  I really look forward to being able to use a Linux box as 
a console on the CoCo.  In the past year I've learned to love almost 
everything about the little boxes - with the exception of the keyboard.  I 
simply cannot deal with it.  Hurts my fingers to type on it and I'm very 
inaccurate due to the layout being a bit "off" from contemporary 
standards.

Steve


-- 


From linville at tuxdriver.com  Mon Nov  9 12:45:10 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 9 Nov 2009 12:45:10 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <alpine.DEB.2.00.0911090740180.4638@duo>
References: <e44ad6640911081746j38880b55qdb1a9649533ac2d@mail.gmail.com>
	<alpine.DEB.2.00.0911090740180.4638@duo>
Message-ID: <20091109174510.GE2805@tuxdriver.com>

On Mon, Nov 09, 2009 at 07:43:18AM -0500, Steven Hirsch wrote:
> On Sun, 8 Nov 2009, Aaron Wolfe wrote:
>
>> Here is an example of things working now (note process 3, this is the
>> shell on T2, which is using stdin/stout on my linux box, and where I'm
>> typing the commands). For now I've modified the drivewire server to
>> have no display, and just put stdin into the virtual serial port's
>> read buffer, write bytes from the virtual serial port to stdout.

> Terrific work.  I really look forward to being able to use a Linux box as 
> a console on the CoCo.  In the past year I've learned to love almost  
> everything about the little boxes - with the exception of the keyboard.  
> I simply cannot deal with it.  Hurts my fingers to type on it and I'm 
> very inaccurate due to the layout being a bit "off" from contemporary  
> standards.

Ditto.  I've had this type of thing penciled-in for a while, but never
needed it bad enough to do it -- now I won't have to, wooohoo! :-)

FWIW, I think you should have the driverwire server allocate a PTY.
Then, pass data back and forth betwen the coco and the PTY so that any
normal Linux tool that can access a TTY (e.g. minicom) can now talk
to the CoCo.  I use this sort of technique with some hacks I have
for MESS and MAME that I use quite often.  If you are interested,
I'd be happy to answer questions, share code, or otherwise cooperate
with you to do that part.

The above would be a good intermediate step that would enable you
(and others) to get some use out of /T2 while you continue to develop
your custom CoCo terminal client or internet modem (which may already
be implemented elsewhere), etc.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From mmarlette at frontiernet.net  Mon Nov  9 13:41:24 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Mon, 9 Nov 2009 18:41:24 +0000 (UTC)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <2140280473.2660021257792043366.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <1515784255.2660421257792084543.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>

Chad,

I have be on vacation, more than a week. Just returned to work today but will not be to the office till Wednesday, sorry three houses that all require care, attendance, etc...

I have been hunting at Cloud-9 Lab Central. For VERY good reasons, I have no phones, no cell reception, just Dish Network.

I am processing over 400 Emails right now.....So instead of order processing I am filter this thread and other inquiries.

I am behind, plan on working on Veteran's Day to try and catch up a bit. A day won't cut it but it can't hurt either

Hopefully things will be on the up. Got my daughter hopefully back on track, nowhere where she needs to be but a start.

I do not work for UPS or FedEX. I do work for the second largest defense contractor in the world. We might be slipping due to the current administration's social agenda, national defense is not a major concern. We are entering round two of our layoffs, currently 550 out the door here, projecting another 200-300 on this next round. Please run my health care so that can go to crap as well....What a joke. I know this is not a forum for politics I apologize in advance for this. This hits REALLY close to home.

We are still in business for now...

Regards,

Mark


----- Original Message -----
From: "Chad H" <chadbh74 at hotmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, November 7, 2009 11:44:08 AM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Cloud-9 Tech

Dang all I did was post a question as to the status of Cloud-9 and inquired
if anyone knew why I wasn't getting replies to an order/info request...now
it's turned in to a thread that's lead to this!?  Geez.  Guess I should have
searched through this forum's posts to determine Boise's or Mark's email
addresses and contacted them directly.

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Derek
Sent: Saturday, November 07, 2009 10:50 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Cloud-9 Tech

As I said last year on the email list because of the way you treat customers
and your attitude that we are all ignorant and a hassle to deal with is why
I will never again purchase from Cloud-9 as long as your part of the
company. Every time you reply to a product or service question it is done in
a way that shows a total lack of respect for people and that fine,. I
respect your right to feel the way you do and to express yourself. I reserve
the right to not do business with your company until how you treat people
changes. 

My budget for my vintage computing hobby is not large but I can tell you I
have bypassed your company's products this past year in favor for expansions
and accessories for other vintage platforms because every time I have gone
to possibly place an order for Drive wire or the Super IDE controller I
remember how you have treated me and others on the email list in the past
and I just cant bring myself to do business with you.







** Mistrust Authority. Promote Decentralization **


 

--- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:

From: Boisy G. Pitre <boisy at tee-boy.com>
Subject: Re: [Coco] Cloud-9 Tech
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Date: Saturday, November 7, 2009, 7:05 AM

Mark really should address this since Cloud-9 is his business and I sell my
products through him, but since he's on vacation, I'll respond.

I think your message doesn't convey a sense of disrespect as much as it does
an ignorance of how Cloud-9's business is handled.

Cloud-9 order fulfillment works this way: Mark buys software product in bulk
from me and stocks those products at Lab North.  As orders come in, they are
evaluated.  If it's a purely software order, I'll fulfill it here at Lab
South, since I have the capacity to make the software products.  If it's a
mixture of hardware and software, Mark will fulfill it at Lab North.  We do
this to prevent having to ship from two different locations for the same
order.

That's why some folks get packages sent from Minnesota, others from
Louisiana.

When Mark is away (he and I stay in touch regularly, so I know his
schedule), I will fill orders that I can.  For those that I can't, I'll
inform the customer of the delay.  When Mark gets back in zone, he takes
care of those orders.

Sometimes we go an extended time without getting orders, so it's not unusual
to have quiet periods without emails. As a result, when things break, like
the email seems to have, we don't notice it right away.  Since Mark handles
the IT stuff (email routing, knows passwords, etc), he will have to return
before the situation becomes rectified.

Aside from all this, Mark has a busy life these days, and he's given a
glimpse of what's going on in his life in prior messages.

Now from this point onward, I'll speak for myself.

Between managing and running my own successful business, attending graduate
school, running a household and seeing after all of the other goings on in
my life, the CoCo is really way down on the list of priorities.  Sorry if
that hurts, but that's the facts.   I have less time and more commitments 
on my plate than ever, and the revenue that I obtain from Cloud-9 is
infinitesimal compared to my other sources of income.

There's an equation that I derived some years back that describes my
philosophy on how I spend my time.  I call it "Boisy's Formula of
Probability of Continued Effort." This is my formula; it works for me:

P = V / (E*T*H))

Where:
    P is the probability of continued effort for a given task;
    V is the value that I obtain out of doing the task (value can be in the
form of money, food, or even something as intrinsic as happiness and
fulfillment);
    E is the level of effort required to generate that value;
    T is the amount of time I have to spend doing the task;
    H is the hassle factor that comes along with performing the task.

The goal is to maximize V while minimizing E, T and H, thus keeping P at or
above 1.  High values of P are very, very good.

For everything I spend my time doing, I apply this formula in my head.  And
it answers a basic question: "Is this worth my time?"  For my work in the
CoCo, V, E and T are pretty much constants, with the large majority of V
being enjoyment of the hobby and the positive interactions I get with the
majority of our customers and friends.  Very little of V is in the form of
monetary compensation.

Without a doubt, Mark and I have built a great network of friends and
customers through Cloud-9, and I appreciate their business and support. 
They keep the value of V pretty high, but it's the value of H that I watch
carefully.  It increases when I have to write long emails like this one when
I would rather be doing something else on a Saturday morning.  It increases
when people wrongly assume that we are ignoring them and then send nasty
emails.  It increases when my time gets taken advantage of by others without
fair compensation or under false pretenses.

Thanks for listening!

On Nov 7, 2009, at 7:31 AM, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done for a
love of the Coco
>> and the community.
> 
> I mean no disrespect to the folks at cloud 9 and have even purchased my
512K Ram upgrade from them but if you going to run a business there is a
right way and a wrong way to do it. If there are problems with filling
orders you should at least post on your web page about possible delays or
reply back to your customers about how long the delay will be. It sounds
like a few folks have emailed but got no reply back and they have had to
post here or on coco3.com to get an answer.
> 
> 
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


From aawolfe at gmail.com  Mon Nov  9 13:53:47 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 13:53:47 -0500
Subject: [Coco] os9/drivewire driver: success!
Message-ID: <4af8653d.e302be0a.77fd.732d@mx.google.com>

I think a PTY is a great idea.   Doing the terminal support in a proper terminal program like minicom makes more sense than writing my own client.  My only concern is that im not sure if Windows users will be left out in the cold, but that doesnt bother me too much tbh.   Mac os x should support pty with a little wrangling.  

If you have anything in c that does a pty, i'd love to see the code.  I'm much more comfortable in c than in os9 assembler, but no need to duplicate work if i don't have to.

Thanks, i should have thought of using a pty, glad you did!



-----Original Message-----
From: John W. Linville <linville at tuxdriver.com>
Sent: Monday, November 09, 2009 12:45 PM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver: success!

On Mon, Nov 09, 2009 at 07:43:18AM -0500, Steven Hirsch wrote:
> On Sun, 8 Nov 2009, Aaron Wolfe wrote:
>
>> Here is an example of things working now (note process 3, this is the
>> shell on T2, which is using stdin/stout on my linux box, and where I'm
>> typing the commands). For now I've modified the drivewire server to
>> have no display, and just put stdin into the virtual serial port's
>> read buffer, write bytes from the virtual serial port to stdout.

> Terrific work.  I really look forward to being able to use a Linux box as 
> a console on the CoCo.  In the past year I've learned to love almost  
> everything about the little boxes - with the exception of the keyboard.  
> I simply cannot deal with it.  Hurts my fingers to type on it and I'm 
> very inaccurate due to the layout being a bit "off" from contemporary  
> standards.

Ditto.  I've had this type of thing penciled-in for a while, but never
needed it bad enough to do it -- now I won't have to, wooohoo! :-)

FWIW, I think you should have the driverwire server allocate a PTY.
Then, pass data back and forth betwen the coco and the PTY so that any
normal Linux tool that can access a TTY (e.g. minicom) can now talk
to the CoCo.  I use this sort of technique with some hacks I have
for MESS and MAME that I use quite often.  If you are interested,
I'd be happy to answer questions, share code, or otherwise cooperate
with you to do that part.

The above would be a good intermediate step that would enable you
(and others) to get some use out of /T2 while you continue to develop
your custom CoCo terminal client or internet modem (which may already
be implemented elsewhere), etc.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From mmarlette at frontiernet.net  Mon Nov  9 13:58:35 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Mon, 9 Nov 2009 18:58:35 +0000 (UTC)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <776499.83014.qm@web30201.mail.mud.yahoo.com>
Message-ID: <759428353.2666291257793114968.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>

Derek,

So true...Problem is that there are so many free hours in a day and some don't read a response all the way to the end. Most are excited to receive their wares that they have paid for with their hard earned money. I am overdue on orders but the latter orders all where qualified that nothing would ship till after the return from my vacation on 11/9.

You can spend your free time pontificating or actually working to obtain a goal. In this case, I went on an extended vacation with ZERO email for almost two weeks.

Ahhhh, send me back to the woods..... :)

Regards,

Mark




----- Original Message -----
From: "Derek" <dml_68 at yahoo.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, November 7, 2009 7:31:03 AM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Cloud-9 Tech

> Remember Cloud9 is not Mark's prime source of income. It is done for a love of the Coco
> and the community.

I mean no disrespect to the folks at cloud 9 and have even purchased my 512K Ram upgrade from them but if you going to run a business there is a right way and a wrong way to do it. If there are problems with filling orders you should at least post on your web page about possible delays or reply back to your customers about how long the delay will be. It sounds like a few folks have emailed but got no reply back and they have had to post here or on coco3.com to get an answer.





      

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


From linville at tuxdriver.com  Mon Nov  9 15:12:52 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 9 Nov 2009 15:12:52 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <4af8653d.e302be0a.77fd.732d@mx.google.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
Message-ID: <20091109201252.GH2805@tuxdriver.com>

On Mon, Nov 09, 2009 at 01:53:47PM -0500, Aaron Wolfe wrote:
> I think a PTY is a great idea.   Doing the terminal support in a
> proper terminal program like minicom makes more sense than writing
> my own client.  My only concern is that im not sure if Windows users
> will be left out in the cold, but that doesnt bother me too much tbh.
> Mac os x should support pty with a little wrangling.

I'm pretty sure OSX has at least some version of PTY support.
I Googled a bit for win32 APIs (of which I am blissfully ignorant)
but didn't find anything specific.  However, there seem to be some
implementations out ther -- maybe cygwin or uwin or something would
support it?

> If you have anything in c that does a pty, i'd love to see the code.
> I'm much more comfortable in c than in os9 assembler, but no need to
> duplicate work if i don't have to.

I'll attach the source for the MESS code I use.  It seems reasonably
clear, but feel free to ask questions if you haven't MESSed your
brain yet. :-)

> Thanks, i should have thought of using a pty, glad you did!

Hey, anything I can do to get you to make my life better... :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.
-------------- next part --------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/select.h>

#include "driver.h"
#include "pseudotty.h"

struct pseudotty pty[MAX_PTY] = { {0, }, };

void pseudotty_alloc(running_machine *machine, int which)
{
	char msg[20];
	char *slave;
	struct pseudotty *p = pty + which;

	p->fd = posix_openpt(O_RDWR);
	grantpt(p->fd);
	unlockpt(p->fd);

	slave = ptsname(p->fd);
	printf("Debug pseudo-terminal %d slave is %s\n", which, slave);

	sprintf(msg, "MAME debug port %d\n", which);
	write(p->fd, msg, strlen(msg));

	/* request callback upon exiting */
	add_exit_callback(machine, pseudotty_exit);
}

void pseudotty_exit(running_machine *machine)
{
	int which;

	for (which = 0; which < MAX_PTY; which++) {
		close(pty[which].fd);
	}
}

int pseudotty_read(int which, int offset)
{
	char line[80];
	char data = 0x5a;
	struct timeval timeout;
	fd_set readfds;
	struct pseudotty *p = pty + which;

	switch (offset) {
	case PTY_DATA:
		if (!p->rx_pending) {
			fprintf(stderr, "%s: buffer underrun on %d\n",
				__func__, which);
			break;
		}
		data = p->buf[p->head++];
		p->rx_pending--;
		break;
	case PTY_CONTROL:
		if (!p->rx_pending) {
			/* Try to read from pty */
			FD_ZERO(&readfds);
			FD_SET(p->fd, &readfds);
			timeout.tv_sec = timeout.tv_usec = 0;

			if (select(p->fd + 1, &readfds, NULL, NULL, &timeout)
				< 0) {
				sprintf(line, "%s : %s : %d ", __func__,
					__FILE__,  __LINE__);
				perror(line);
			} else if (FD_ISSET(p->fd, &readfds)) {
				p->head = 0;
				p->rx_pending = read(p->fd, p->buf,
							sizeof(p->buf));
				if (p->rx_pending == -1) {
					p->rx_pending = 0;
					sprintf(line, "%s : %s : %d ", __func__,
						__FILE__, __LINE__);
					perror(line);
				}
			}
		}
		data = p->rx_pending;
		break;
	default:
		fprintf(stderr, "%s: read from bad offset %d on %d\n", __FILE__,
			offset, which);
	}

	return (int)data;
}

void pseudotty_write(int which, int offset, int data)
{
	char d = (char)data;
	struct pseudotty *p = pty + which;

	switch (offset) {
	case PTY_DATA:
		write(p->fd, &d, 1);
		break;
	case PTY_CONTROL:
		p->rx_pending = p->head = 0;
		break;
	default:
		fprintf(stderr, "%s: write to bad offset %d on %d\n", __FILE__,
			offset, which);
	}
}

READ8_HANDLER( pseudotty_0_r ) { return pseudotty_read(0, offset); }
READ8_HANDLER( pseudotty_1_r ) { return pseudotty_read(1, offset); }

WRITE8_HANDLER( pseudotty_0_w ) { pseudotty_write(0, offset, data); }
WRITE8_HANDLER( pseudotty_1_w ) { pseudotty_write(1, offset, data); }

From asa.rand at yahoo.com  Mon Nov  9 16:28:04 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Mon, 9 Nov 2009 13:28:04 -0800 (PST)
Subject: [Coco] some results
In-Reply-To: <4AF79C28.8010302@worldnet.att.net>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com>
	<4AF79C28.8010302@worldnet.att.net>
Message-ID: <137998.5376.qm@web53702.mail.re2.yahoo.com>

I don't know what is going on with the mem command. I can specify some values between even 000s, but not always, and some values are not accepted at all. I decided to work around the memory problem and try to make the procedure smaller.

First, I replaced all of the GFX2 statements with GOSUBs, and put one of each GFX2 statement in subroutines. This reduced the code size for fmato to <24000 (unpacked). It still wouldn't run, so I removed the sort and renumber routines from fmato and placed them in separate procedures. Having them all in the workspace at the same time just made the overall size of the procedures greater than fmato was by itself. I packed the sort and renum routines into separate module files and deleted them from the workspace.

Then I added SHELL statements to load each when it was time to use it. fmato still wouldn't run, even though the memory size was reduced to 24k (or so). I packed fmato, and found I could reduce the workspace size to 23000. It worked! I ran fmato and it ran. It went through the instruction section, displayed the decode in overlays, and when it got to the first sort, it quit with a 43 error. Running mdir showed that the sort module was indeed loaded, but Basic09 couldn't "find" it.

I unlinked it from memory and quit Basic09. I ran it from the command line, and 67 error. Apparently the original RunB still has a problem with it. There were still 3 routines to separate, the ones for creating a record when a new var ref, line ref or lit ref occurs. I did that. While they were all merged with fmato it ran (only in Basic09, and only after packing). It still errored when it got to the first sort routine.

I packed the record routines separately and removed them from fmato's workspace and tried again. Now it errors when it tries to run the first record procedure. Again, mdir shows that the module was found and loaded into memory. I don't get it.

I am going to try separating the instruction decode section. It is the single largest routine in the program. I have a multitude of counter variables, as I wanted to know exact data concerning the I-Code. Perhaps making it a separate procedure will fix the problem.

Wayne

Also, I'll be putting the newest version of fmato on sourceforge, since the one I put there yesterday is already obsolete.




________________________________
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sun, November 8, 2009 8:35:52 PM
Subject: Re: [Coco] some results

Wayne Campbell wrote:
> 
> Trying to go down to 26000 reduces the memory to less than
> the needs of the procedures. I am finding that Basic09's memory
> command is broken. For example, I can type mem 32000 and it will
> increase or decrease to that amount. Likewise, I can do the same
> with 34000. But if I specify 33000, I get "What?"!

There is a good chance you have some code mismatches between your Basic09 and the OS-9 versions. On my system, I can smoothly ask for memory within Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any number higher including 34000.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From aawolfe at gmail.com  Mon Nov  9 16:50:18 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 16:50:18 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <20091109201252.GH2805@tuxdriver.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
Message-ID: <e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>

> On Mon, Nov 09, 2009 at 01:53:47PM -0500, Aaron Wolfe wrote:
>> I think a PTY is a great idea. ? Doing the terminal support in a
>> proper terminal program like minicom makes more sense than writing
>> my own client. ?My only concern is that im not sure if Windows users
>> will be left out in the cold, but that doesnt bother me too much tbh.
>> Mac os x should support pty with a little wrangling.
>
> I'm pretty sure OSX has at least some version of PTY support.
> I Googled a bit for win32 APIs (of which I am blissfully ignorant)
> but didn't find anything specific. ?However, there seem to be some
> implementations out ther -- maybe cygwin or uwin or something would
> support it?
>
>> If you have anything in c that does a pty, i'd love to see the code.
>> I'm much more comfortable in c than in os9 assembler, but no need to
>> duplicate work if i don't have to.
>
> I'll attach the source for the MESS code I use. ?It seems reasonably
> clear, but feel free to ask questions if you haven't MESSed your
> brain yet. :-)

Thanks, looks like it will work with just a little tweaking,
definitely save me some time.
I will probably get something put together tonight.

If you'd like, I can send boot disks/source/binaries etc or put them somewhere.
-Aaron


>
>> Thanks, i should have thought of using a pty, glad you did!
>
> Hey, anything I can do to get you to make my life better... :-)
>
> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>


From linville at tuxdriver.com  Mon Nov  9 16:55:23 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 9 Nov 2009 16:55:23 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
Message-ID: <20091109215522.GA7060@tuxdriver.com>

On Mon, Nov 09, 2009 at 04:50:18PM -0500, Aaron Wolfe wrote:
> > On Mon, Nov 09, 2009 at 01:53:47PM -0500, Aaron Wolfe wrote:
> >> I think a PTY is a great idea. ? Doing the terminal support in a
> >> proper terminal program like minicom makes more sense than writing
> >> my own client. ?My only concern is that im not sure if Windows users
> >> will be left out in the cold, but that doesnt bother me too much tbh.
> >> Mac os x should support pty with a little wrangling.
> >
> > I'm pretty sure OSX has at least some version of PTY support.
> > I Googled a bit for win32 APIs (of which I am blissfully ignorant)
> > but didn't find anything specific. ?However, there seem to be some
> > implementations out ther -- maybe cygwin or uwin or something would
> > support it?
> >
> >> If you have anything in c that does a pty, i'd love to see the code.
> >> I'm much more comfortable in c than in os9 assembler, but no need to
> >> duplicate work if i don't have to.
> >
> > I'll attach the source for the MESS code I use. ?It seems reasonably
> > clear, but feel free to ask questions if you haven't MESSed your
> > brain yet. :-)
> 
> Thanks, looks like it will work with just a little tweaking,
> definitely save me some time.
> I will probably get something put together tonight.
> 
> If you'd like, I can send boot disks/source/binaries etc or put them somewhere.

Sounds great -- I'd love to see them!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From lothan at newsguy.com  Mon Nov  9 17:15:09 2009
From: lothan at newsguy.com (Lothan)
Date: Mon, 9 Nov 2009 17:15:09 -0500
Subject: [Coco] some results
In-Reply-To: <137998.5376.qm@web53702.mail.re2.yahoo.com>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com><4AF79C28.8010302@worldnet.att.net>
	<137998.5376.qm@web53702.mail.re2.yahoo.com>
Message-ID: <EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>

Have you tried merging runb, gfx2, and your code module into a single file? 
If you load them separately, each separate module takes up full pages of RAM 
(4K, 8K?) even if the module is say 100 bytes. Merging them can 
significantly reduce the memory footprint required.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Monday, November 09, 2009 4:28 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] some results

> I don't know what is going on with the mem command. I can specify some 
> values between even 000s, but not always, and some values are not accepted 
> at all. I decided to work around the memory problem and try to make the 
> procedure smaller.
>
> First, I replaced all of the GFX2 statements with GOSUBs, and put one of 
> each GFX2 statement in subroutines. This reduced the code size for fmato 
> to <24000 (unpacked). It still wouldn't run, so I removed the sort and 
> renumber routines from fmato and placed them in separate procedures. 
> Having them all in the workspace at the same time just made the overall 
> size of the procedures greater than fmato was by itself. I packed the sort 
> and renum routines into separate module files and deleted them from the 
> workspace.
>
> Then I added SHELL statements to load each when it was time to use it. 
> fmato still wouldn't run, even though the memory size was reduced to 24k 
> (or so). I packed fmato, and found I could reduce the workspace size to 
> 23000. It worked! I ran fmato and it ran. It went through the instruction 
> section, displayed the decode in overlays, and when it got to the first 
> sort, it quit with a 43 error. Running mdir showed that the sort module 
> was indeed loaded, but Basic09 couldn't "find" it.
>
> I unlinked it from memory and quit Basic09. I ran it from the command 
> line, and 67 error. Apparently the original RunB still has a problem with 
> it. There were still 3 routines to separate, the ones for creating a 
> record when a new var ref, line ref or lit ref occurs. I did that. While 
> they were all merged with fmato it ran (only in Basic09, and only after 
> packing). It still errored when it got to the first sort routine.
>
> I packed the record routines separately and removed them from fmato's 
> workspace and tried again. Now it errors when it tries to run the first 
> record procedure. Again, mdir shows that the module was found and loaded 
> into memory. I don't get it.
>
> I am going to try separating the instruction decode section. It is the 
> single largest routine in the program. I have a multitude of counter 
> variables, as I wanted to know exact data concerning the I-Code. Perhaps 
> making it a separate procedure will fix the problem.
>
> Wayne
>
> Also, I'll be putting the newest version of fmato on sourceforge, since 
> the one I put there yesterday is already obsolete.
>
>
>
>
> ________________________________
> From: Robert Gault <robert.gault at worldnet.att.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, November 8, 2009 8:35:52 PM
> Subject: Re: [Coco] some results
>
> Wayne Campbell wrote:
>>
>> Trying to go down to 26000 reduces the memory to less than
>> the needs of the procedures. I am finding that Basic09's memory
>> command is broken. For example, I can type mem 32000 and it will
>> increase or decrease to that amount. Likewise, I can do the same
>> with 34000. But if I specify 33000, I get "What?"!
>
> There is a good chance you have some code mismatches between your Basic09 
> and the OS-9 versions. On my system, I can smoothly ask for memory within 
> Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any 
> number higher including 34000.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 


From jdaggett at gate.net  Mon Nov  9 17:57:27 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Mon, 09 Nov 2009 17:57:27 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <1515784255.2660421257792084543.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
References: <2140280473.2660021257792043366.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>,
	<1515784255.2660421257792084543.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <4AF89E57.13149.973CEB@jdaggett.gate.net>

On 9 Nov 2009 at 18:41, Mark Marlette wrote:

> I have be on vacation, more than a week. Just returned to work today but
> will not be to the office till Wednesday, sorry three houses that all
> require care, attendance, etc...
> 
> I have been hunting at Cloud-9 Lab Central. For VERY good reasons, I have
> no phones, no cell reception, just Dish Network.

mark 

hate to add one more email but I hope vacation was good and it is great to get rid of most 
modern conviences once in a while to recharge. TV may not be one of them.

james


From mmarlette at frontiernet.net  Mon Nov  9 18:06:01 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Mon, 9 Nov 2009 23:06:01 +0000 (UTC)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <4AF89E57.13149.973CEB@jdaggett.gate.net>
Message-ID: <1273423907.2742051257807961238.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>

james,

Yes, I have the TV because I am down there alone and listen to it at times for what is going on outside of my small world, like to watch the weather as well.

Was good, not good to come back to the 400 emails.... Still need to reply or answer to another 50 or so.... Boring.....

Take care!

M

----- Original Message -----
From: jdaggett at gate.net
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Monday, November 9, 2009 4:57:27 PM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Cloud-9 Tech

On 9 Nov 2009 at 18:41, Mark Marlette wrote:

> I have be on vacation, more than a week. Just returned to work today but
> will not be to the office till Wednesday, sorry three houses that all
> require care, attendance, etc...
> 
> I have been hunting at Cloud-9 Lab Central. For VERY good reasons, I have
> no phones, no cell reception, just Dish Network.

mark 

hate to add one more email but I hope vacation was good and it is great to get rid of most 
modern conviences once in a while to recharge. TV may not be one of them.

james

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


From operator at coco3.com  Sun Nov  8 16:21:29 2009
From: operator at coco3.com (Roger Taylor)
Date: Sun, 08 Nov 2009 15:21:29 -0600
Subject: [Coco] CoCoNet status
In-Reply-To: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>
References: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>
Message-ID: <6.2.5.6.1.20091108145805.062307a8@coco3.com>

By the way, if anyone wants to have a floppy disk image included in 
the "drive pak" distro, this is a good chance to put your games or 
apps within a few keystrokes of a pak user.  Back in 1990 it would be 
like asking a company to throw your software disks in each outgoing 
package.  Of course, there was a real market back then so this is a 
little different now.  Just e-mail me the disk image(s) and I ask 
that they are 35-track format if Disk BASIC, and no more than 720K in 
size if OS-9.  I'll get them on the pak if they are worthy.

This brings up another idea..  I don't really have much time to work 
on a fully stocked NitrOS-9 "vhd" image for the pak, so if someone 
has a really good vhd image with all the cool games and stuff on it 
and some good apps, I'll include it on the pak as either the main 
mass drive or 2nd one, etc.  We've got room for tons of huge OS-9 
hard drives on the MicroSD card, so no worries. If 10 people sent me 
a 20-30 meg VHD to be on the distro pak, I'll try to get them on 
there before time runs out.  I will just mount them using the 
bitbanger cable and dsave the contents onto a blank mass drive on the pak.

There might not be time for me to make the VHD bootable before I get 
the pak shipping, but a lot of this stuff can be done and offered 
online to keep upgrades coming.  After all, 90% of CoCoNet is Software.

The partition manager I wrote is in BASIC and is on the SYS0 
partition on the pak.  It lets you erase the table and start over, 
adding partitions in the order you like and with varying automatic 
and suggested sizes, etc. with a listing of the current partitions 
and messages telling you how much space is left, in LSN and MB 
format.  Each partition listed shows you the starting LSN and size in 
LSNs and MBs.  There's nothing on the pak itself that would keep you 
from read or writing to any raw LSN.  The OSes are responsible for 
using their respectful partitions.

The manager has menu items for adding small or huge "USER" 
partitions.  I doubt you'll ever reach the limit which is about ~1200 
partitions.  :)

Lots of fun.
-- 
~ Roger Taylor




From georgeramsower at gmail.com  Mon Nov  9 18:55:18 2009
From: georgeramsower at gmail.com (George Ramsower)
Date: Mon, 9 Nov 2009 17:55:18 -0600
Subject: [Coco] some results
References: <513580.67794.qm@web53710.mail.re2.yahoo.com><4AF79C28.8010302@worldnet.att.net><137998.5376.qm@web53702.mail.re2.yahoo.com>
	<EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>
Message-ID: <002501ca6198$18140950$6401a8c0@OLDGEORGE>

  My memory may be foggy but I seem to recall using Shell "unlink...  to remove a procedure when it isn't needed. 
  Also, Lothan is correct inasmuch as the individual procedures, if small enough to fit more than one in an 8K module can be merged, then this will save some workspace. I usually go through the list and try adding different combinations so I might find a way to mix them so that they will squeeze into 8192 bytes of workspace in that module. 

  If you have a RAM disk on your coco, you can put the stuff you need to call on there and it will speed things up.
  If data is eating your memory, use the RAM disk or the floppy for that. It doesn't take much ram to open a record in a data file.  B09 can zip right on through several records if you use direct access to each record. You can have many datafiles for categories or related things. Use the disk drive or ram drive to keep this active stuff.
  Don't forget to use a "Quit" method so the program can copy the data from the ram drive to the disk. Likewise, the program should load all the stuff into the ram drive upon startup.
  I've found that using a command line shell script to copy my files to the floppy is easy to forget to do.
   Leave nothing to chance!!

George
  From: Lothan 

  Have you tried merging runb, gfx2, and your code module into a single file? 
  If you load them separately, each separate module takes up full pages of RAM 
  (4K, 8K?) even if the module is say 100 bytes. Merging them can 
  significantly reduce the memory footprint required.

  --------------------------------------------------
  From: "Wayne Campbell" <asa.rand at yahoo.com>
  Sent: Monday, November 09, 2009 4:28 PM
  To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
  Subject: Re: [Coco] some results

  > I don't know what is going on with the mem command. I can specify some 
  > values between even 000s, but not always, and some values are not accepted 
  > at all. I decided to work around the memory problem and try to make the 
  > procedure smaller.
  >
  > First, I replaced all of the GFX2 statements with GOSUBs, and put one of 
  > each GFX2 statement in subroutines. This reduced the code size for fmato 
  > to <24000 (unpacked). It still wouldn't run, so I removed the sort and 
  > renumber routines from fmato and placed them in separate procedures. 
  > Having them all in the workspace at the same time just made the overall 
  > size of the procedures greater than fmato was by itself. I packed the sort 
  > and renum routines into separate module files and deleted them from the 
  > workspace.
  >
  > Then I added SHELL statements to load each when it was time to use it. 
  > fmato still wouldn't run, even though the memory size was reduced to 24k 
  > (or so). I packed fmato, and found I could reduce the workspace size to 
  > 23000. It worked! I ran fmato and it ran. It went through the instruction 
  > section, displayed the decode in overlays, and when it got to the first 
  > sort, it quit with a 43 error. Running mdir showed that the sort module 
  > was indeed loaded, but Basic09 couldn't "find" it.
  >
  > I unlinked it from memory and quit Basic09. I ran it from the command 
  > line, and 67 error. Apparently the original RunB still has a problem with 
  > it. There were still 3 routines to separate, the ones for creating a 
  > record when a new var ref, line ref or lit ref occurs. I did that. While 
  > they were all merged with fmato it ran (only in Basic09, and only after 
  > packing). It still errored when it got to the first sort routine.
  >
  > I packed the record routines separately and removed them from fmato's 
  > workspace and tried again. Now it errors when it tries to run the first 
  > record procedure. Again, mdir shows that the module was found and loaded 
  > into memory. I don't get it.
  >
  > I am going to try separating the instruction decode section. It is the 
  > single largest routine in the program. I have a multitude of counter 
  > variables, as I wanted to know exact data concerning the I-Code. Perhaps 
  > making it a separate procedure will fix the problem.
  >
  > Wayne
  >
  > Also, I'll be putting the newest version of fmato on sourceforge, since 
  > the one I put there yesterday is already obsolete.
  >
  >
  >
  >
  > ________________________________
  > From: Robert Gault <robert.gault at worldnet.att.net>
  > To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
  > Sent: Sun, November 8, 2009 8:35:52 PM
  > Subject: Re: [Coco] some results
  >
  > Wayne Campbell wrote:
  >>
  >> Trying to go down to 26000 reduces the memory to less than
  >> the needs of the procedures. I am finding that Basic09's memory
  >> command is broken. For example, I can type mem 32000 and it will
  >> increase or decrease to that amount. Likewise, I can do the same
  >> with 34000. But if I specify 33000, I get "What?"!
  >
  > There is a good chance you have some code mismatches between your Basic09 
  > and the OS-9 versions. On my system, I can smoothly ask for memory within 
  > Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any 
  > number higher including 34000.
  >
  > --
  > Coco mailing list
  > Coco at maltedmedia.com
  > http://five.pairlist.net/mailman/listinfo/coco
  >
  >
  >
  >
  >
  > --
  > Coco mailing list
  > Coco at maltedmedia.com
  > http://five.pairlist.net/mailman/listinfo/coco
  > 

  --
  Coco mailing list
  Coco at maltedmedia.com
  http://five.pairlist.net/mailman/listinfo/coco


From asa.rand at yahoo.com  Mon Nov  9 19:21:47 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Mon, 9 Nov 2009 16:21:47 -0800 (PST)
Subject: [Coco] some results
In-Reply-To: <EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com><4AF79C28.8010302@worldnet.att.net>
	<137998.5376.qm@web53702.mail.re2.yahoo.com>
	<EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>
Message-ID: <452380.95793.qm@web53704.mail.re2.yahoo.com>

I have RunB, SysCall, Inkey, GFX and gfx2 (those are the exact module names) merged together as runb, and it is preloaded when I start NitrOS-9. I added it to the startup file.

Basic09 usually has no problem finding them in small procedures. This only happens when the procedure size exceeds some unknown size. I haven't been able to pin down the exact size, but it's somewhere in the 23K range in source size.

When I wrote DCom, the only time this problem ever occurred was when my workspace size exceeded 32K. Then, I could pack the procedures and run them from the command line with runb.

None of that is working with NitrOS-9, modified Basic09 and original runb. I am going to try running it with the modified runb and see if there's a difference on the command line.

By modified, I mean the version of runb and Basic09 that had the date year modification added. Speaking of that, I don't know if it's important or not, but the modified Basic09 still returns a 14 character string that only includes a 2-digit year. Is it possible that there are other issues that may be affecting Basic09 because of the mods?

Wayne




________________________________
From: Lothan <lothan at newsguy.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Mon, November 9, 2009 2:15:09 PM
Subject: Re: [Coco] some results

Have you tried merging runb, gfx2, and your code module into a single file? If you load them separately, each separate module takes up full pages of RAM (4K, 8K?) even if the module is say 100 bytes. Merging them can significantly reduce the memory footprint required.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Monday, November 09, 2009 4:28 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] some results

> I don't know what is going on with the mem command. I can specify some values between even 000s, but not always, and some values are not accepted at all. I decided to work around the memory problem and try to make the procedure smaller.
> 
> First, I replaced all of the GFX2 statements with GOSUBs, and put one of each GFX2 statement in subroutines. This reduced the code size for fmato to <24000 (unpacked). It still wouldn't run, so I removed the sort and renumber routines from fmato and placed them in separate procedures. Having them all in the workspace at the same time just made the overall size of the procedures greater than fmato was by itself. I packed the sort and renum routines into separate module files and deleted them from the workspace.
> 
> Then I added SHELL statements to load each when it was time to use it. fmato still wouldn't run, even though the memory size was reduced to 24k (or so). I packed fmato, and found I could reduce the workspace size to 23000. It worked! I ran fmato and it ran. It went through the instruction section, displayed the decode in overlays, and when it got to the first sort, it quit with a 43 error. Running mdir showed that the sort module was indeed loaded, but Basic09 couldn't "find" it.
> 
> I unlinked it from memory and quit Basic09. I ran it from the command line, and 67 error. Apparently the original RunB still has a problem with it. There were still 3 routines to separate, the ones for creating a record when a new var ref, line ref or lit ref occurs. I did that. While they were all merged with fmato it ran (only in Basic09, and only after packing). It still errored when it got to the first sort routine.
> 
> I packed the record routines separately and removed them from fmato's workspace and tried again. Now it errors when it tries to run the first record procedure. Again, mdir shows that the module was found and loaded into memory. I don't get it.
> 
> I am going to try separating the instruction decode section. It is the single largest routine in the program. I have a multitude of counter variables, as I wanted to know exact data concerning the I-Code. Perhaps making it a separate procedure will fix the problem.
> 
> Wayne
> 
> Also, I'll be putting the newest version of fmato on sourceforge, since the one I put there yesterday is already obsolete.
> 
> 
> 
> 
> ________________________________
> From: Robert Gault <robert.gault at worldnet.att.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, November 8, 2009 8:35:52 PM
> Subject: Re: [Coco] some results
> 
> Wayne Campbell wrote:
>> 
>> Trying to go down to 26000 reduces the memory to less than
>> the needs of the procedures. I am finding that Basic09's memory
>> command is broken. For example, I can type mem 32000 and it will
>> increase or decrease to that amount. Likewise, I can do the same
>> with 34000. But if I specify 33000, I get "What?"!
> 
> There is a good chance you have some code mismatches between your Basic09 and the OS-9 versions. On my system, I can smoothly ask for memory within Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any number higher including 34000.
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From asa.rand at yahoo.com  Mon Nov  9 20:19:53 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Mon, 9 Nov 2009 17:19:53 -0800 (PST)
Subject: [Coco] funny discovery
Message-ID: <202508.29052.qm@web53702.mail.re2.yahoo.com>

I looked again at the os9 archive for the level 2 version. I found that the master boot disk was indeed there! The Basic09/Config disk is named OS9BOOT.os9 and the master boot disk is named OS9SYSMR.os9. I put OS9SYSMR.os9 in as disk 0, and OS9BOOT.os9 as disk 1, and typed DOS.

It showed the OS9 BOOT screen with the black text and green background, then the screen went black, and a blue cursor showed up. I could tell I was at the first screen, but I can't see anything because the text and background are both black.

I tried entering the date (in 2-digit year format), it did something, but it's been too long for me to remember what happens when you boot off the system master.

Has anyone else had this problem? Know what to do about the screen colors?

Also, I want to set up a virtual hard disk in MESS to use as a bootable hd from OS-9. Because of the way the NitrOS-9 disk I am using is set up, I can't access a hard drive with it, and the only 720K floppies I can use have to be /d0 to be read. To create a new boot disk, I'm going to use OS-9 Level 2. I want to be able to use a hard disk image. When I had my CoCo3, I had a 20-meg hd that came with a Tandy 2000 I bought back then. I had it set up as my boot drive, and it worked fine. I want to do that with MESS. Can anyone help me with this, as I am at a total loss for how to do it, and MESS isn't very informative on the subject.

Wayne


      


From leonard23 at verizon.net  Mon Nov  9 20:24:43 2009
From: leonard23 at verizon.net (Leonard Miller)
Date: Mon, 09 Nov 2009 20:24:43 -0500
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <1515784255.2660421257792084543.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
References: <2140280473.2660021257792043366.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
	<1515784255.2660421257792084543.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <001d01ca61a4$9545c970$bfd15c50$@net>

That's ok Mark.  There are a lot of others out there that feel as you do.
All you can do is ride it out.  No need to apologize to me.  

Leonard


-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Mark Marlette
Sent: Monday, November 09, 2009 01:41 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Cloud-9 Tech

Chad,

I have be on vacation, more than a week. Just returned to work today but
will not be to the office till Wednesday, sorry three houses that all
require care, attendance, etc...

I have been hunting at Cloud-9 Lab Central. For VERY good reasons, I have no
phones, no cell reception, just Dish Network.

I am processing over 400 Emails right now.....So instead of order processing
I am filter this thread and other inquiries.

I am behind, plan on working on Veteran's Day to try and catch up a bit. A
day won't cut it but it can't hurt either

Hopefully things will be on the up. Got my daughter hopefully back on track,
nowhere where she needs to be but a start.

I do not work for UPS or FedEX. I do work for the second largest defense
contractor in the world. We might be slipping due to the current
administration's social agenda, national defense is not a major concern. We
are entering round two of our layoffs, currently 550 out the door here,
projecting another 200-300 on this next round. Please run my health care so
that can go to crap as well....What a joke. I know this is not a forum for
politics I apologize in advance for this. This hits REALLY close to home.

We are still in business for now...

Regards,

Mark


----- Original Message -----
From: "Chad H" <chadbh74 at hotmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, November 7, 2009 11:44:08 AM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Cloud-9 Tech

Dang all I did was post a question as to the status of Cloud-9 and inquired
if anyone knew why I wasn't getting replies to an order/info request...now
it's turned in to a thread that's lead to this!?  Geez.  Guess I should have
searched through this forum's posts to determine Boise's or Mark's email
addresses and contacted them directly.

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Derek
Sent: Saturday, November 07, 2009 10:50 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Cloud-9 Tech

As I said last year on the email list because of the way you treat customers
and your attitude that we are all ignorant and a hassle to deal with is why
I will never again purchase from Cloud-9 as long as your part of the
company. Every time you reply to a product or service question it is done in
a way that shows a total lack of respect for people and that fine,. I
respect your right to feel the way you do and to express yourself. I reserve
the right to not do business with your company until how you treat people
changes. 

My budget for my vintage computing hobby is not large but I can tell you I
have bypassed your company's products this past year in favor for expansions
and accessories for other vintage platforms because every time I have gone
to possibly place an order for Drive wire or the Super IDE controller I
remember how you have treated me and others on the email list in the past
and I just cant bring myself to do business with you.







** Mistrust Authority. Promote Decentralization **


 

--- On Sat, 11/7/09, Boisy G. Pitre <boisy at tee-boy.com> wrote:

From: Boisy G. Pitre <boisy at tee-boy.com>
Subject: Re: [Coco] Cloud-9 Tech
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Date: Saturday, November 7, 2009, 7:05 AM

Mark really should address this since Cloud-9 is his business and I sell my
products through him, but since he's on vacation, I'll respond.

I think your message doesn't convey a sense of disrespect as much as it does
an ignorance of how Cloud-9's business is handled.

Cloud-9 order fulfillment works this way: Mark buys software product in bulk
from me and stocks those products at Lab North.  As orders come in, they are
evaluated.  If it's a purely software order, I'll fulfill it here at Lab
South, since I have the capacity to make the software products.  If it's a
mixture of hardware and software, Mark will fulfill it at Lab North.  We do
this to prevent having to ship from two different locations for the same
order.

That's why some folks get packages sent from Minnesota, others from
Louisiana.

When Mark is away (he and I stay in touch regularly, so I know his
schedule), I will fill orders that I can.  For those that I can't, I'll
inform the customer of the delay.  When Mark gets back in zone, he takes
care of those orders.

Sometimes we go an extended time without getting orders, so it's not unusual
to have quiet periods without emails. As a result, when things break, like
the email seems to have, we don't notice it right away.  Since Mark handles
the IT stuff (email routing, knows passwords, etc), he will have to return
before the situation becomes rectified.

Aside from all this, Mark has a busy life these days, and he's given a
glimpse of what's going on in his life in prior messages.

Now from this point onward, I'll speak for myself.

Between managing and running my own successful business, attending graduate
school, running a household and seeing after all of the other goings on in
my life, the CoCo is really way down on the list of priorities.  Sorry if
that hurts, but that's the facts.   I have less time and more commitments 
on my plate than ever, and the revenue that I obtain from Cloud-9 is
infinitesimal compared to my other sources of income.

There's an equation that I derived some years back that describes my
philosophy on how I spend my time.  I call it "Boisy's Formula of
Probability of Continued Effort." This is my formula; it works for me:

P = V / (E*T*H))

Where:
    P is the probability of continued effort for a given task;
    V is the value that I obtain out of doing the task (value can be in the
form of money, food, or even something as intrinsic as happiness and
fulfillment);
    E is the level of effort required to generate that value;
    T is the amount of time I have to spend doing the task;
    H is the hassle factor that comes along with performing the task.

The goal is to maximize V while minimizing E, T and H, thus keeping P at or
above 1.  High values of P are very, very good.

For everything I spend my time doing, I apply this formula in my head.  And
it answers a basic question: "Is this worth my time?"  For my work in the
CoCo, V, E and T are pretty much constants, with the large majority of V
being enjoyment of the hobby and the positive interactions I get with the
majority of our customers and friends.  Very little of V is in the form of
monetary compensation.

Without a doubt, Mark and I have built a great network of friends and
customers through Cloud-9, and I appreciate their business and support. 
They keep the value of V pretty high, but it's the value of H that I watch
carefully.  It increases when I have to write long emails like this one when
I would rather be doing something else on a Saturday morning.  It increases
when people wrongly assume that we are ignoring them and then send nasty
emails.  It increases when my time gets taken advantage of by others without
fair compensation or under false pretenses.

Thanks for listening!

On Nov 7, 2009, at 7:31 AM, Derek wrote:

>> Remember Cloud9 is not Mark's prime source of income. It is done for a
love of the Coco
>> and the community.
> 
> I mean no disrespect to the folks at cloud 9 and have even purchased my
512K Ram upgrade from them but if you going to run a business there is a
right way and a wrong way to do it. If there are problems with filling
orders you should at least post on your web page about possible delays or
reply back to your customers about how long the delay will be. It sounds
like a few folks have emailed but got no reply back and they have had to
post here or on coco3.com to get an answer.
> 
> 
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



From lothan at newsguy.com  Mon Nov  9 21:14:59 2009
From: lothan at newsguy.com (Lothan)
Date: Mon, 9 Nov 2009 21:14:59 -0500
Subject: [Coco] some results
In-Reply-To: <452380.95793.qm@web53704.mail.re2.yahoo.com>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com><4AF79C28.8010302@worldnet.att.net><137998.5376.qm@web53702.mail.re2.yahoo.com><EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>
	<452380.95793.qm@web53704.mail.re2.yahoo.com>
Message-ID: <FF8FE4FEFCC9469CA5D5229B68CBB7FC@Crossfire>

Instead of merging all of them into RunB, I would try merging just the 
modules you need into your compiled Basic09 module. In other words, unlink 
RunB and the others until they are removed from memory. Then merge just what 
you need into your module; e.g. merge DCom, RunB, Gfx2 into say DCom2 then 
load DCom2 and run DCom. This should result in the minimalist memory 
footprint possible.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Monday, November 09, 2009 7:21 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] some results

> I have RunB, SysCall, Inkey, GFX and gfx2 (those are the exact module 
> names) merged together as runb, and it is preloaded when I start NitrOS-9. 
> I added it to the startup file.
>
> Basic09 usually has no problem finding them in small procedures. This only 
> happens when the procedure size exceeds some unknown size. I haven't been 
> able to pin down the exact size, but it's somewhere in the 23K range in 
> source size.
>
> When I wrote DCom, the only time this problem ever occurred was when my 
> workspace size exceeded 32K. Then, I could pack the procedures and run 
> them from the command line with runb.
>
> None of that is working with NitrOS-9, modified Basic09 and original runb. 
> I am going to try running it with the modified runb and see if there's a 
> difference on the command line.
>
> By modified, I mean the version of runb and Basic09 that had the date year 
> modification added. Speaking of that, I don't know if it's important or 
> not, but the modified Basic09 still returns a 14 character string that 
> only includes a 2-digit year. Is it possible that there are other issues 
> that may be affecting Basic09 because of the mods?
>
> Wayne
>
>
>
>
> ________________________________
> From: Lothan <lothan at newsguy.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Mon, November 9, 2009 2:15:09 PM
> Subject: Re: [Coco] some results
>
> Have you tried merging runb, gfx2, and your code module into a single 
> file? If you load them separately, each separate module takes up full 
> pages of RAM (4K, 8K?) even if the module is say 100 bytes. Merging them 
> can significantly reduce the memory footprint required.
>
> --------------------------------------------------
> From: "Wayne Campbell" <asa.rand at yahoo.com>
> Sent: Monday, November 09, 2009 4:28 PM
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Subject: Re: [Coco] some results
>
>> I don't know what is going on with the mem command. I can specify some 
>> values between even 000s, but not always, and some values are not 
>> accepted at all. I decided to work around the memory problem and try to 
>> make the procedure smaller.
>>
>> First, I replaced all of the GFX2 statements with GOSUBs, and put one of 
>> each GFX2 statement in subroutines. This reduced the code size for fmato 
>> to <24000 (unpacked). It still wouldn't run, so I removed the sort and 
>> renumber routines from fmato and placed them in separate procedures. 
>> Having them all in the workspace at the same time just made the overall 
>> size of the procedures greater than fmato was by itself. I packed the 
>> sort and renum routines into separate module files and deleted them from 
>> the workspace.
>>
>> Then I added SHELL statements to load each when it was time to use it. 
>> fmato still wouldn't run, even though the memory size was reduced to 24k 
>> (or so). I packed fmato, and found I could reduce the workspace size to 
>> 23000. It worked! I ran fmato and it ran. It went through the instruction 
>> section, displayed the decode in overlays, and when it got to the first 
>> sort, it quit with a 43 error. Running mdir showed that the sort module 
>> was indeed loaded, but Basic09 couldn't "find" it.
>>
>> I unlinked it from memory and quit Basic09. I ran it from the command 
>> line, and 67 error. Apparently the original RunB still has a problem with 
>> it. There were still 3 routines to separate, the ones for creating a 
>> record when a new var ref, line ref or lit ref occurs. I did that. While 
>> they were all merged with fmato it ran (only in Basic09, and only after 
>> packing). It still errored when it got to the first sort routine.
>>
>> I packed the record routines separately and removed them from fmato's 
>> workspace and tried again. Now it errors when it tries to run the first 
>> record procedure. Again, mdir shows that the module was found and loaded 
>> into memory. I don't get it.
>>
>> I am going to try separating the instruction decode section. It is the 
>> single largest routine in the program. I have a multitude of counter 
>> variables, as I wanted to know exact data concerning the I-Code. Perhaps 
>> making it a separate procedure will fix the problem.
>>
>> Wayne
>>
>> Also, I'll be putting the newest version of fmato on sourceforge, since 
>> the one I put there yesterday is already obsolete.
>>
>>
>>
>>
>> ________________________________
>> From: Robert Gault <robert.gault at worldnet.att.net>
>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>> Sent: Sun, November 8, 2009 8:35:52 PM
>> Subject: Re: [Coco] some results
>>
>> Wayne Campbell wrote:
>>>
>>> Trying to go down to 26000 reduces the memory to less than
>>> the needs of the procedures. I am finding that Basic09's memory
>>> command is broken. For example, I can type mem 32000 and it will
>>> increase or decrease to that amount. Likewise, I can do the same
>>> with 34000. But if I specify 33000, I get "What?"!
>>
>> There is a good chance you have some code mismatches between your Basic09 
>> and the OS-9 versions. On my system, I can smoothly ask for memory within 
>> Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or 
>> any number higher including 34000.
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 


From keeper63 at cox.net  Mon Nov  9 21:42:38 2009
From: keeper63 at cox.net (Andrew)
Date: Mon, 09 Nov 2009 19:42:38 -0700
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <mailman.17.1257778816.42451.coco@maltedmedia.com>
References: <mailman.17.1257778816.42451.coco@maltedmedia.com>
Message-ID: <4AF8D31E.3070006@cox.net>

I was expecting something nice, but OH WOW!

It looks almost "print ready"! Like you could almost take it down to a 
print shop and have them run it off with heavy stock, and have a "real" 
manual in front of you!

It looks so good, it doesn't look like a scan at all!

Amazing work! It truly shows it as a "labor of love"; I am sorry you 
weren't able to play the game as a kid, and that you can't find time 
now. You owe it to yourself to try it out; consider taking the time as a 
self-thank you for your efforts.

I assume you know about the porting project (to the PC)?:

	http://mspencer.net/daggorath/dodpcp.html

Don't look too deep at that page though, plenty of spoilers!

Thank you for this gift...

-- Andrew L. Ayers, Glendale, Arizona

> Message: 3
> Date: Sun, 8 Nov 2009 22:42:15 -0700
> From: "J.P. Samson" <coco+list at jeanpaulsamson.com>
> Subject: Re: [Coco] Dungeons of Daggorath Program Manual
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <006C62E7-79FB-4A13-AC65-345E50E750FE at jeanpaulsamson.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
>>> J.P. Samson wrote:
>>>> Since I seem to be into transitioning old CoCo manuals to digital  
>>>> form, I
>>>> thought I'd pass along my rendition of the manual for Dungeons of  
>>>> Daggorath.
> 
> On Nov-8-09, at 5:00 PM, mike delyea wrote:
>> That was THE best game for the coco!  A<space R>,  A<space R>,
>> A<space R>, M, M, M, M, T<space>A.  I swear my heart was beating as
>> fast the character's heart.
> 
> 
> Thanks for everyone's gushing comments about the quality of the  
> manual.  I never owned DoD, being a kid at the time and having no  
> money to spend on Radio Shack's rather pricey Program Paks.  Anyways,  
> I stuck with the more kid friendly shoot-em-up games such as Time  
> Bandit or Zaxxon.
> 
> I know I tried a pirated copy of the game in its day, but without a  
> manual, good luck figuring anything out!  Now, in my adulthood, I was  
> able to buy a copy of the game off an auction site, but haven't the  
> time to get into playing it!  Oh, to be a kid again!
> 
> -- JP


From aawolfe at gmail.com  Mon Nov  9 23:05:40 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 23:05:40 -0500
Subject: [Coco] funny discovery
In-Reply-To: <202508.29052.qm@web53702.mail.re2.yahoo.com>
References: <202508.29052.qm@web53702.mail.re2.yahoo.com>
Message-ID: <e44ad6640911092005t375f062fhc6131bdde075c3e9@mail.gmail.com>

On Mon, Nov 9, 2009 at 8:19 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> I looked again at the os9 archive for the level 2 version. I found that the master boot disk was indeed there! The Basic09/Config disk is named OS9BOOT.os9 and the master boot disk is named OS9SYSMR.os9. I put OS9SYSMR.os9 in as disk 0, and OS9BOOT.os9 as disk 1, and typed DOS.
>
> It showed the OS9 BOOT screen with the black text and green background, then the screen went black, and a blue cursor showed up. I could tell I was at the first screen, but I can't see anything because the text and background are both black.
>
> I tried entering the date (in 2-digit year format), it did something, but it's been too long for me to remember what happens when you boot off the system master.
>
> Has anyone else had this problem? Know what to do about the screen colors?
>
> Also, I want to set up a virtual hard disk in MESS to use as a bootable hd from OS-9. Because of the way the NitrOS-9 disk I am using is set up, I can't access a hard drive with it, and the only 720K floppies I can use have to be /d0 to be read. To create a new boot disk, I'm going to use OS-9 Level 2. I want to be able to use a hard disk image. When I had my CoCo3, I had a 20-meg hd that came with a Tandy 2000 I bought back then. I had it set up as my boot drive, and it worked fine. I want to do that with MESS. Can anyone help me with this, as I am at a total loss for how to do it, and MESS isn't very informative on the subject.
>

Hi Wayne,

I am no expert, but in the Nitros9 source is a driver called "emudsk"
which I think is what you'll need.
I built a boot disk with emudsk.dr and it's h0.dd.  I was able, in
MESS, to create a virtual hard disk using the MESS menu.  Then I
booted the emulator with my new disk image and was able to format /H0
with nitros9's format from within in the emulated coco.  copying data
onto the virtual HD seemed to work fine.

So that would get you a hard disk within MESS.  I'm not sure what
would be required to boot without a floppy image to assist, since I
think the coco's roms would have to have support for MESS's virtual
drive, or a rompak in the virtual rompak slot.. something like that.
maybe it exists somewhere.

Like you, I wasn't able to find out much about this, maybe there are
better disks already made somewhere?  the stock nitros9 disks dont
seem to include the emudsk driver.

-Aaron


> Wayne
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From aawolfe at gmail.com  Mon Nov  9 23:12:38 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 9 Nov 2009 23:12:38 -0500
Subject: [Coco] funny discovery
In-Reply-To: <e44ad6640911092005t375f062fhc6131bdde075c3e9@mail.gmail.com>
References: <202508.29052.qm@web53702.mail.re2.yahoo.com>
	<e44ad6640911092005t375f062fhc6131bdde075c3e9@mail.gmail.com>
Message-ID: <e44ad6640911092012s2804b6a8x2d99e79a7d5b5bed@mail.gmail.com>

On Mon, Nov 9, 2009 at 11:05 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Mon, Nov 9, 2009 at 8:19 PM, Wayne Campbell <asa.rand at yahoo.com> wrote:
>> I looked again at the os9 archive for the level 2 version. I found that the master boot disk was indeed there! The Basic09/Config disk is named OS9BOOT.os9 and the master boot disk is named OS9SYSMR.os9. I put OS9SYSMR.os9 in as disk 0, and OS9BOOT.os9 as disk 1, and typed DOS.
>>
>> It showed the OS9 BOOT screen with the black text and green background, then the screen went black, and a blue cursor showed up. I could tell I was at the first screen, but I can't see anything because the text and background are both black.
>>
>> I tried entering the date (in 2-digit year format), it did something, but it's been too long for me to remember what happens when you boot off the system master.
>>
>> Has anyone else had this problem? Know what to do about the screen colors?
>>
>> Also, I want to set up a virtual hard disk in MESS to use as a bootable hd from OS-9. Because of the way the NitrOS-9 disk I am using is set up, I can't access a hard drive with it, and the only 720K floppies I can use have to be /d0 to be read. To create a new boot disk, I'm going to use OS-9 Level 2. I want to be able to use a hard disk image. When I had my CoCo3, I had a 20-meg hd that came with a Tandy 2000 I bought back then. I had it set up as my boot drive, and it worked fine. I want to do that with MESS. Can anyone help me with this, as I am at a total loss for how to do it, and MESS isn't very informative on the subject.
>>
>
> Hi Wayne,
>
> I am no expert, but in the Nitros9 source is a driver called "emudsk"
> which I think is what you'll need.
> I built a boot disk with emudsk.dr and it's h0.dd. ?I was able, in
> MESS, to create a virtual hard disk using the MESS menu. ?Then I
> booted the emulator with my new disk image and was able to format /H0
> with nitros9's format from within in the emulated coco. ?copying data
> onto the virtual HD seemed to work fine.
>
> So that would get you a hard disk within MESS. ?I'm not sure what
> would be required to boot without a floppy image to assist, since I
> think the coco's roms would have to have support for MESS's virtual
> drive, or a rompak in the virtual rompak slot.. something like that.
> maybe it exists somewhere.
>
> Like you, I wasn't able to find out much about this, maybe there are
> better disks already made somewhere? ?the stock nitros9 disks dont
> seem to include the emudsk driver.
>
> -Aaron
>

I just noticed there is a ddh0 descriptor in the source as well..
maybe this can be used to switch dd to the virtual hard disk at boot?
this would be almost what you need, since I think then d0 would be
free after bootup, only needed to start things off.  I'll do some
experimenting :)  Still new to all this.


>
>> Wayne
>>
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>


From robert.gault at worldnet.att.net  Mon Nov  9 23:15:33 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Mon, 09 Nov 2009 23:15:33 -0500
Subject: [Coco] funny discovery
In-Reply-To: <202508.29052.qm@web53702.mail.re2.yahoo.com>
References: <202508.29052.qm@web53702.mail.re2.yahoo.com>
Message-ID: <4AF8E8E5.7040203@worldnet.att.net>

Wayne Campbell wrote:
> I looked again at the os9 archive for the level 2 version. I found that the master boot disk was indeed there! The Basic09/Config disk is named OS9BOOT.os9 and the master boot disk is named OS9SYSMR.os9. I put OS9SYSMR.os9 in as disk 0, and OS9BOOT.os9 as disk 1, and typed DOS.
>
> It showed the OS9 BOOT screen with the black text and green background, then the screen went black, and a blue cursor showed up. I could tell I was at the first screen, but I can't see anything because the text and background are both black.
>
> I tried entering the date (in 2-digit year format), it did something, but it's been too long for me to remember what happens when you boot off the system master.
>
> Has anyone else had this problem? Know what to do about the screen colors?
>
> Also, I want to set up a virtual hard disk in MESS to use as a bootable hd from OS-9. Because of the way the NitrOS-9 disk I am using is set up, I can't access a hard drive with it, and the only 720K floppies I can use have to be /d0 to be read. To create a new boot disk, I'm going to use OS-9 Level 2. I want to be able to use a hard disk image. When I had my CoCo3, I had a 20-meg hd that came with a Tandy 2000 I bought back then. I had it set up as my boot drive, and it worked fine. I want to do that with MESS. Can anyone help me with this, as I am at a total loss for how to do it, and MESS isn't very informative on the subject.
>
> Wayne
>

You can get RSDOS with instructions on how to use it with an OS-9 
virtual hard drive from my site
http://home.att.net/~robert.gault/Coco/Downloads/Downloads.htm
or you can get a pre-formatted .vhd image from the VCC site and use it 
with the VCC emulator or MESS with the RGBDOS ROM.
http://vcc6809.bravehost.com/downloads.html


From asa.rand at yahoo.com  Tue Nov 10 03:14:17 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Tue, 10 Nov 2009 00:14:17 -0800 (PST)
Subject: [Coco] some results
In-Reply-To: <FF8FE4FEFCC9469CA5D5229B68CBB7FC@Crossfire>
References: <513580.67794.qm@web53710.mail.re2.yahoo.com><4AF79C28.8010302@worldnet.att.net><137998.5376.qm@web53702.mail.re2.yahoo.com><EF58A17E6DEF42C5BF7D1D4D8222903B@Crossfire>
	<452380.95793.qm@web53704.mail.re2.yahoo.com>
	<FF8FE4FEFCC9469CA5D5229B68CBB7FC@Crossfire>
Message-ID: <756857.6528.qm@web53707.mail.re2.yahoo.com>

I have got fmato running. I went back to fmato3 (the last all-in-one procedure version) and made all of the changes I'd made to the divided version to reduce size. Then I went through the code and found places where I was repeating code with only 2 differences in values (1 byte code and one string literal) and subroutined them, adding a string variable to contain the string literal and an additional byte to handle the byte code difference.

It packs down to 20075 bytes, 874 data size. In packed form I am running it from within Basic09. To do it, I open Basic09 with 33k (shows 32511 free), load fmato (shows 26727 proc-size and 874 data-size), then pack. Then I reduce memory to 23000 and run fmato("filename"). It's running as I type this, decoding rconfig (one of the larger RiBBS modules).

I'm reasonably sure I can't add much more to the code before running into the same problem again, so I'm keeping the separated version for future modifications. I'll upload the source and a disk image with the packed module on it. I haven't tried running it from the command line yet.

Wayne




________________________________
From: Lothan <lothan at newsguy.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Mon, November 9, 2009 6:14:59 PM
Subject: Re: [Coco] some results

Instead of merging all of them into RunB, I would try merging just the modules you need into your compiled Basic09 module. In other words, unlink RunB and the others until they are removed from memory. Then merge just what you need into your module; e.g. merge DCom, RunB, Gfx2 into say DCom2 then load DCom2 and run DCom. This should result in the minimalist memory footprint possible.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Monday, November 09, 2009 7:21 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] some results

> I have RunB, SysCall, Inkey, GFX and gfx2 (those are the exact module names) merged together as runb, and it is preloaded when I start NitrOS-9. I added it to the startup file.
> 
> Basic09 usually has no problem finding them in small procedures. This only happens when the procedure size exceeds some unknown size. I haven't been able to pin down the exact size, but it's somewhere in the 23K range in source size.
> 
> When I wrote DCom, the only time this problem ever occurred was when my workspace size exceeded 32K. Then, I could pack the procedures and run them from the command line with runb.
> 
> None of that is working with NitrOS-9, modified Basic09 and original runb. I am going to try running it with the modified runb and see if there's a difference on the command line.
> 
> By modified, I mean the version of runb and Basic09 that had the date year modification added. Speaking of that, I don't know if it's important or not, but the modified Basic09 still returns a 14 character string that only includes a 2-digit year. Is it possible that there are other issues that may be affecting Basic09 because of the mods?
> 
> Wayne
> 
> 
> 
> 
> ________________________________
> From: Lothan <lothan at newsguy.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Mon, November 9, 2009 2:15:09 PM
> Subject: Re: [Coco] some results
> 
> Have you tried merging runb, gfx2, and your code module into a single file? If you load them separately, each separate module takes up full pages of RAM (4K, 8K?) even if the module is say 100 bytes. Merging them can significantly reduce the memory footprint required.
> 
> --------------------------------------------------
> From: "Wayne Campbell" <asa.rand at yahoo.com>
> Sent: Monday, November 09, 2009 4:28 PM
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Subject: Re: [Coco] some results
> 
>> I don't know what is going on with the mem command. I can specify some values between even 000s, but not always, and some values are not accepted at all. I decided to work around the memory problem and try to make the procedure smaller.
>> 
>> First, I replaced all of the GFX2 statements with GOSUBs, and put one of each GFX2 statement in subroutines. This reduced the code size for fmato to <24000 (unpacked). It still wouldn't run, so I removed the sort and renumber routines from fmato and placed them in separate procedures. Having them all in the workspace at the same time just made the overall size of the procedures greater than fmato was by itself. I packed the sort and renum routines into separate module files and deleted them from the workspace.
>> 
>> Then I added SHELL statements to load each when it was time to use it. fmato still wouldn't run, even though the memory size was reduced to 24k (or so). I packed fmato, and found I could reduce the workspace size to 23000. It worked! I ran fmato and it ran. It went through the instruction section, displayed the decode in overlays, and when it got to the first sort, it quit with a 43 error. Running mdir showed that the sort module was indeed loaded, but Basic09 couldn't "find" it.
>> 
>> I unlinked it from memory and quit Basic09. I ran it from the command line, and 67 error. Apparently the original RunB still has a problem with it. There were still 3 routines to separate, the ones for creating a record when a new var ref, line ref or lit ref occurs. I did that. While they were all merged with fmato it ran (only in Basic09, and only after packing). It still errored when it got to the first sort routine.
>> 
>> I packed the record routines separately and removed them from fmato's workspace and tried again. Now it errors when it tries to run the first record procedure. Again, mdir shows that the module was found and loaded into memory. I don't get it.
>> 
>> I am going to try separating the instruction decode section. It is the single largest routine in the program. I have a multitude of counter variables, as I wanted to know exact data concerning the I-Code. Perhaps making it a separate procedure will fix the problem.
>> 
>> Wayne
>> 
>> Also, I'll be putting the newest version of fmato on sourceforge, since the one I put there yesterday is already obsolete.
>> 
>> 
>> 
>> 
>> ________________________________
>> From: Robert Gault <robert.gault at worldnet.att.net>
>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>> Sent: Sun, November 8, 2009 8:35:52 PM
>> Subject: Re: [Coco] some results
>> 
>> Wayne Campbell wrote:
>>> 
>>> Trying to go down to 26000 reduces the memory to less than
>>> the needs of the procedures. I am finding that Basic09's memory
>>> command is broken. For example, I can type mem 32000 and it will
>>> increase or decrease to that amount. Likewise, I can do the same
>>> with 34000. But if I specify 33000, I get "What?"!
>> 
>> There is a good chance you have some code mismatches between your Basic09 and the OS-9 versions. On my system, I can smoothly ask for memory within Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any number higher including 34000.
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
>> 
>> 
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      


From aawolfe at gmail.com  Tue Nov 10 05:50:06 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 05:50:06 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <20091109215522.GA7060@tuxdriver.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
Message-ID: <e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>

On Mon, Nov 9, 2009 at 4:55 PM, John W. Linville <linville at tuxdriver.com> wrote:
> On Mon, Nov 09, 2009 at 04:50:18PM -0500, Aaron Wolfe wrote:
>> > On Mon, Nov 09, 2009 at 01:53:47PM -0500, Aaron Wolfe wrote:
>> >> I think a PTY is a great idea. ? Doing the terminal support in a
>> >> proper terminal program like minicom makes more sense than writing
>> >> my own client. ?My only concern is that im not sure if Windows users
>> >> will be left out in the cold, but that doesnt bother me too much tbh.
>> >> Mac os x should support pty with a little wrangling.
>> >
>> > I'm pretty sure OSX has at least some version of PTY support.
>> > I Googled a bit for win32 APIs (of which I am blissfully ignorant)
>> > but didn't find anything specific. ?However, there seem to be some
>> > implementations out ther -- maybe cygwin or uwin or something would
>> > support it?
>> >
>> >> If you have anything in c that does a pty, i'd love to see the code.
>> >> I'm much more comfortable in c than in os9 assembler, but no need to
>> >> duplicate work if i don't have to.
>> >
>> > I'll attach the source for the MESS code I use. ?It seems reasonably
>> > clear, but feel free to ask questions if you haven't MESSed your
>> > brain yet. :-)
>>
>> Thanks, looks like it will work with just a little tweaking,
>> definitely save me some time.
>> I will probably get something put together tonight.
>>
>> If you'd like, I can send boot disks/source/binaries etc or put them somewhere.
>
> Sounds great -- I'd love to see them!
>

Ok, PTY is working and it's much nicer than the old stdin/stdout
version.  I am now using an OS9 shell in Minicom on my linux box, with
the Coco booted and accessing disks over the same serial cable at the
same time.. the bit banger must be hating life :)

I made a web page with notes and files if anyone wants to play with
it, or better yet help find/correct my many mistakes and bad designs.
I think it should have everything needed:

http://www.aaronwolfe.com/coco/

It's very close to usable, but if you're just interested in having it
work then probably want to wait another week or so and I'll have it
much better polished.

-Aaron



> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From boisy at tee-boy.com  Tue Nov 10 07:05:24 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Tue, 10 Nov 2009 06:05:24 -0600
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
Message-ID: <F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>

Aaron,

Again, fantastic work.  It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.

I downloaded the source to the scdwt driver and looked over it.  I have a few suggestions that I think you may want to look at.

Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself.  There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this.  Here's how it works:

You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provide for some interval.  The period of the OS-9 tick is 1/60 second.  You supply a multiplier to the F$VIRQ call to extend the period that the VIRQ calls your ISR, so you could have your ISR get called every 6 ticks, which means your ISR gets called 10 times per second.  You can adjust this number as you wish for optimality.

Your ISR, when called, would send a OP_SERREAD call to the server.  I would combine the OP_SERCHECK and OP_SERREAD into one call.  When you send the OP_SERREAD, the server would send back two bytes.  The first byte would flag whether there is a valid byte to send, and the second byte would be that byte. So for example:

ISR sends OP_SERREAD
Server returns:  0x00 0x00  (first byte indicates that there is no data to send, second byte is just a fill byte)
  OR
Server returns: 0xFF 0x41 (first byte indicates that there is data from the server, and the second byte is the valid character)

In your ISR, you have to take into account that a response may not come in because the server isn't running, the cable is unplugged, etc, and take action accordingly, but assuming everything is ok, you get back a response immediately.  IF the first byte is 0, you just return.  However IF the first byte is non-zero, you take the second byte and stuff it away into a queue and increments a queue count static variable.

Back to your Read routine.  When SCF calls your Read routine, it copies the process ID of the process who is calling the Read routine into the V.BUSY static storage variable.  When the Read routine is entered, it should check the queue count, and if zero (implying there is no data to read), it should copy V.BUSY to V.WAKE (effectively copying the process ID of the process that is doing the Read), then do an indefinite F$Sleep.

Meanwhile, back to the ISR... when it finally does get a valid byte from the server, it will put away the data byte into the input queue, increment the queue count as I stated earlier, and then check V.WAKE.  if V.WAKE is 0 (meaning no process is sleeping, waiting for data), it merely returns.  If, however, V.WAKE is no-zero, then the ISR will send an S$WAKE signal to the process ID in V.WAKE.  In the case where there is a process asleep, it will wake up and continue running in your Read routine.

Back to you read routine, the code immediately after the os9 F$Sleep wakes up reads the byte from the input queue.  Note there are some additional checks to be done for Level 2, such as whether the process is in a suspend state, and whether the signal is an S$Intrpt or lower signal in which case it doesn't read the character but immediately returns with an error.

My suggestion would be to look in sc6551.asm and its Read routine for an idea of the flow of control from the ISR back to the read routine.  But the idea is to use the VIRQ (which is driven by the system clock module) to make your driver much more hospitable to the OS-9 environment.

Feel free to post questions up here as you go through this.

> Ok, PTY is working and it's much nicer than the old stdin/stdout
> version.  I am now using an OS9 shell in Minicom on my linux box, with
> the Coco booted and accessing disks over the same serial cable at the
> same time.. the bit banger must be hating life :)
> 
> I made a web page with notes and files if anyone wants to play with
> it, or better yet help find/correct my many mistakes and bad designs.
> I think it should have everything needed:
> 
> http://www.aaronwolfe.com/coco/
> 
> It's very close to usable, but if you're just interested in having it
> work then probably want to wait another week or so and I'll have it
> much better polished.
> 
> -Aaron
> 
> 
> 
>> John
>> --
>> John W. Linville                Someday the world will need a hero, and you
>> linville at tuxdriver.com                  might be all we have.  Be ready.
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From aawolfe at gmail.com  Tue Nov 10 12:32:05 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 12:32:05 -0500
Subject: [Coco] os9/drivewire driver: success!
Message-ID: <4af9a39a.c701be0a.75f3.32bb@mx.google.com>

Thanks for the advice.  I kind of suspected i was doing things wrong with the way i was trying to sleep.  Between your walk through and the examples in other modules, I might be able to pull this off.  I will give it a shot and see how far I get :)


-----Original Message-----
From: Boisy G. Pitre <boisy at tee-boy.com>
Sent: Tuesday, November 10, 2009 7:05 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver: success!

Aaron,

Again, fantastic work.  It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.

I downloaded the source to the scdwt driver and looked over it.  I have a few suggestions that I think you may want to look at.

Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself.  There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this.  Here's how it works:

You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provide for some interval.  The period of the OS-9 tick is 1/60 second.  You supply a multiplier to the F$VIRQ call to extend the period that the VIRQ calls your ISR, so you could have your ISR get called every 6 ticks, which means your ISR gets called 10 times per second.  You can adjust this number as you wish for optimality.

Your ISR, when called, would send a OP_SERREAD call to the server.  I would combine the OP_SERCHECK and OP_SERREAD into one call.  When you send the OP_SERREAD, the server would send back two bytes.  The first byte would flag whether there is a valid byte to send, and the second byte would be that byte. So for example:

ISR sends OP_SERREAD
Server returns:  0x00 0x00  (first byte indicates that there is no data to send, second byte is just a fill byte)
  OR
Server returns: 0xFF 0x41 (first byte indicates that there is data from the server, and the second byte is the valid character)

In your ISR, you have to take into account that a response may not come in because the server isn't running, the cable is unplugged, etc, and take action accordingly, but assuming everything is ok, you get back a response immediately.  IF the first byte is 0, you just return.  However IF the first byte is non-zero, you t

[The entire original message is not included]


From boisy at tee-boy.com  Tue Nov 10 12:41:34 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Tue, 10 Nov 2009 11:41:34 -0600
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <4af9a39a.c701be0a.75f3.32bb@mx.google.com>
References: <4af9a39a.c701be0a.75f3.32bb@mx.google.com>
Message-ID: <D5C33C32-6A45-4F3C-8130-11E39A3905C6@tee-boy.com>

Aaron,

Check out vrn.asm for an example of how to setup the VIRQ call.  You still need to call F$IRQ as well as F$VIRQ when setting up the virtual interrupt, and call both to tear them down at Term time.

If I were you I would start out by adding the code to install the ISR, do the F$IRQ and F$VIRQ call, and in your ISR just increment a value in a byte in the system map (say address $1E) then use dmem/dump to see if it's changing at offset $1E:

dmem 0 0 ! dump

That way you have some confidence that your driver is properly bringing up the ISR when you do an iniz /t2.

Then do a deiniz /t2 to make sure you are tearing things down correctly.

Boisy

On Nov 10, 2009, at 11:32 AM, Aaron Wolfe wrote:

> Thanks for the advice.  I kind of suspected i was doing things wrong with the way i was trying to sleep.  Between your walk through and the examples in other modules, I might be able to pull this off.  I will give it a shot and see how far I get :)
> 
> 
> -----Original Message-----
> From: Boisy G. Pitre <boisy at tee-boy.com>
> Sent: Tuesday, November 10, 2009 7:05 AM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Subject: Re: [Coco] os9/drivewire driver: success!
> 
> Aaron,
> 
> Again, fantastic work.  It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.
> 
> I downloaded the source to the scdwt driver and looked over it.  I have a few suggestions that I think you may want to look at.
> 
> Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself.  There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this.  Here's how it works:
> 
> You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provide for some interval.  The period of the OS-9 tick is 1/60 second.  You supply a multiplier to the F$VIRQ call to extend the period that the VIRQ calls your ISR, so you could have your ISR get called every 6 ticks, which means your ISR gets called 10 times per second.  You can adjust this number as you wish for optimality.
> 
> Your ISR, when called, would send a OP_SERREAD call to the server.  I would combine the OP_SERCHECK and OP_SERREAD into one call.  When you send the OP_SERREAD, the server would send back two bytes.  The first byte would flag whether there is a valid byte to send, and the second byte would be that byte. So for example:
> 
> ISR sends OP_SERREAD
> Server returns:  0x00 0x00  (first byte indicates that there is no data to send, second byte is just a fill byte)
>  OR
> Server returns: 0xFF 0x41 (first byte indicates that there is data from the server, and the second byte is the valid character)
> 
> In your ISR, you have to take into account that a response may not come in because the server isn't running, the cable is unplugged, etc, and take action accordingly, but assuming everything is ok, you get back a response immediately.  IF the first byte is 0, you just return.  However IF the first byte is non-zero, you t
> 
> [The entire original message is not included]
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco



From aawolfe at gmail.com  Tue Nov 10 12:59:07 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 12:59:07 -0500
Subject: [Coco] os9/drivewire driver: success!
Message-ID: <4af9a9ef.1602be0a.601e.3a59@mx.google.com>

Ah very nice way to do some debugging.  I actually added a temporary op to dw just to get some test values out, this works much better.  Thanks again!


-----Original Message-----
From: Boisy G. Pitre <boisy at tee-boy.com>
Sent: Tuesday, November 10, 2009 12:41 PM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver: success!

Aaron,

Check out vrn.asm for an example of how to setup the VIRQ call.  You still need to call F$IRQ as well as F$VIRQ when setting up the virtual interrupt, and call both to tear them down at Term time.

If I were you I would start out by adding the code to install the ISR, do the F$IRQ and F$VIRQ call, and in your ISR just increment a value in a byte in the system map (say address $1E) then use dmem/dump to see if it's changing at offset $1E:

dmem 0 0 ! dump

That way you have some confidence that your driver is properly bringing up the ISR when you do an iniz /t2.

Then do a deiniz /t2 to make sure you are tearing things down correctly.

Boisy

On Nov 10, 2009, at 11:32 AM, Aaron Wolfe wrote:

> Thanks for the advice.  I kind of suspected i was doing things wrong with the way i was trying to sleep.  Between your walk through and the examples in other modules, I might be able to pull this off.  I will give it a shot and see how far I get :)
> 
> 
> -----Original Message-----
> From: Boisy G. Pitre <boisy at tee-boy.com>
> Sent: Tuesday, November 10, 2009 7:05 AM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Subject: Re: [Coco] os9/drivewire driver: success!
> 
> Aaron,
> 
> Again, fantastic work.  It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.
> 
> I downloaded the source to the scdwt driver and looked over it.  I have a few suggestions that I think you may want to look at.
> 
> Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself.  There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this.  Here's how it works:
> 
> You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provi

[The entire original message is not included]


From aawolfe at gmail.com  Tue Nov 10 13:18:14 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 13:18:14 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
	<F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
Message-ID: <e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>

One question about combining SERREAD and SERCHECK:

My original idea was that SERCHECK would return the number of bytes in
the server's buffer, and then SERREAD would ask for a flush of X
bytes, typically the number returned by SERCHECK.  The server would
then write out the # of bytes requested.  This was (in my head) a way
to improve performance for things like rzsz over the virtual serial
port.

By combining them, I will be cutting the potential throughput in half
since there are two bytes for each data byte, and also taking a
penalty of having to ask for each byte individually (which is
admittedly how my current driver works, but it was supposed to be
better :)

Are there outside factors that mitigate the losses in combining the
calls?  If there is some other reason it will be slow anyway, then I
agree it would make it simpler to combine them.
-Aaron


On Tue, Nov 10, 2009 at 7:05 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Aaron,
>
> Again, fantastic work. ?It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.
>
> I downloaded the source to the scdwt driver and looked over it. ?I have a few suggestions that I think you may want to look at.
>
> Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself. ?There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this. ?Here's how it works:
>
> You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provide for some interval. ?The period of the OS-9 tick is 1/60 second. ?You supply a multiplier to the F$VIRQ call to extend the period that the VIRQ calls your ISR, so you could have your ISR get called every 6 ticks, which means your ISR gets called 10 times per second. ?You can adjust this number as you wish for optimality.
>
> Your ISR, when called, would send a OP_SERREAD call to the server. ?I would combine the OP_SERCHECK and OP_SERREAD into one call. ?When you send the OP_SERREAD, the server would send back two bytes. ?The first byte would flag whether there is a valid byte to send, and the second byte would be that byte. So for example:
>
> ISR sends OP_SERREAD
> Server returns: ?0x00 0x00 ?(first byte indicates that there is no data to send, second byte is just a fill byte)
> ?OR
> Server returns: 0xFF 0x41 (first byte indicates that there is data from the server, and the second byte is the valid character)
>
> In your ISR, you have to take into account that a response may not come in because the server isn't running, the cable is unplugged, etc, and take action accordingly, but assuming everything is ok, you get back a response immediately. ?IF the first byte is 0, you just return. ?However IF the first byte is non-zero, you take the second byte and stuff it away into a queue and increments a queue count static variable.
>
> Back to your Read routine. ?When SCF calls your Read routine, it copies the process ID of the process who is calling the Read routine into the V.BUSY static storage variable. ?When the Read routine is entered, it should check the queue count, and if zero (implying there is no data to read), it should copy V.BUSY to V.WAKE (effectively copying the process ID of the process that is doing the Read), then do an indefinite F$Sleep.
>
> Meanwhile, back to the ISR... when it finally does get a valid byte from the server, it will put away the data byte into the input queue, increment the queue count as I stated earlier, and then check V.WAKE. ?if V.WAKE is 0 (meaning no process is sleeping, waiting for data), it merely returns. ?If, however, V.WAKE is no-zero, then the ISR will send an S$WAKE signal to the process ID in V.WAKE. ?In the case where there is a process asleep, it will wake up and continue running in your Read routine.
>
> Back to you read routine, the code immediately after the os9 F$Sleep wakes up reads the byte from the input queue. ?Note there are some additional checks to be done for Level 2, such as whether the process is in a suspend state, and whether the signal is an S$Intrpt or lower signal in which case it doesn't read the character but immediately returns with an error.
>
> My suggestion would be to look in sc6551.asm and its Read routine for an idea of the flow of control from the ISR back to the read routine. ?But the idea is to use the VIRQ (which is driven by the system clock module) to make your driver much more hospitable to the OS-9 environment.
>
> Feel free to post questions up here as you go through this.
>
>> Ok, PTY is working and it's much nicer than the old stdin/stdout
>> version. ?I am now using an OS9 shell in Minicom on my linux box, with
>> the Coco booted and accessing disks over the same serial cable at the
>> same time.. the bit banger must be hating life :)
>>
>> I made a web page with notes and files if anyone wants to play with
>> it, or better yet help find/correct my many mistakes and bad designs.
>> I think it should have everything needed:
>>
>> http://www.aaronwolfe.com/coco/
>>
>> It's very close to usable, but if you're just interested in having it
>> work then probably want to wait another week or so and I'll have it
>> much better polished.
>>
>> -Aaron
>>
>>
>>
>>> John
>>> --
>>> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
>>> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From lost at l-w.ca  Tue Nov 10 14:54:36 2009
From: lost at l-w.ca (William Astle)
Date: Tue, 10 Nov 2009 12:54:36 -0700
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>	<20091109201252.GH2805@tuxdriver.com>	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>	<20091109215522.GA7060@tuxdriver.com>	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>	<F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
	<e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>
Message-ID: <4AF9C4FC.5070200@l-w.ca>

Aaron Wolfe wrote:
> One question about combining SERREAD and SERCHECK:
> 
> My original idea was that SERCHECK would return the number of bytes in
> the server's buffer, and then SERREAD would ask for a flush of X
> bytes, typically the number returned by SERCHECK.  The server would
> then write out the # of bytes requested.  This was (in my head) a way
> to improve performance for things like rzsz over the virtual serial
> port.
> 
> By combining them, I will be cutting the potential throughput in half
> since there are two bytes for each data byte, and also taking a
> penalty of having to ask for each byte individually (which is
> admittedly how my current driver works, but it was supposed to be
> better :)
> 
> Are there outside factors that mitigate the losses in combining the
> calls?  If there is some other reason it will be slow anyway, then I
> agree it would make it simpler to combine them.
> -Aaron

Why not make the request include a maximum number of bytes to return.
Then have the response include the number of bytes returned and those bytes.

This would require tinkering the drivewire scheme so it could handle
variable length return packets in some manner but it should provide the
maximum theoretical efficiency.


From aawolfe at gmail.com  Tue Nov 10 15:10:54 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 15:10:54 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <4AF9C4FC.5070200@l-w.ca>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
	<F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
	<e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>
	<4AF9C4FC.5070200@l-w.ca>
Message-ID: <e44ad6640911101210h470f6b4bvf5f3badf641467e9@mail.gmail.com>

On Tue, Nov 10, 2009 at 2:54 PM, William Astle <lost at l-w.ca> wrote:
> Aaron Wolfe wrote:
>> One question about combining SERREAD and SERCHECK:
>>
>> My original idea was that SERCHECK would return the number of bytes in
>> the server's buffer, and then SERREAD would ask for a flush of X
>> bytes, typically the number returned by SERCHECK. ?The server would
>> then write out the # of bytes requested. ?This was (in my head) a way
>> to improve performance for things like rzsz over the virtual serial
>> port.
>>
>> By combining them, I will be cutting the potential throughput in half
>> since there are two bytes for each data byte, and also taking a
>> penalty of having to ask for each byte individually (which is
>> admittedly how my current driver works, but it was supposed to be
>> better :)
>>
>> Are there outside factors that mitigate the losses in combining the
>> calls? ?If there is some other reason it will be slow anyway, then I
>> agree it would make it simpler to combine them.
>> -Aaron
>
> Why not make the request include a maximum number of bytes to return.
> Then have the response include the number of bytes returned and those bytes.
>
> This would require tinkering the drivewire scheme so it could handle
> variable length return packets in some manner but it should provide the
> maximum theoretical efficiency.
>

This would be nice, but as it stands the dw calls require you to know
how many bytes are coming/going when you call them.. not sure if I'm
ready to touch anything in dw itself :)  maybe at some point though..
i agree this would be ideal.

> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


From boisy at tee-boy.com  Tue Nov 10 16:09:32 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Tue, 10 Nov 2009 15:09:32 -0600
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <e44ad6640911101210h470f6b4bvf5f3badf641467e9@mail.gmail.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
	<F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
	<e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>
	<4AF9C4FC.5070200@l-w.ca>
	<e44ad6640911101210h470f6b4bvf5f3badf641467e9@mail.gmail.com>
Message-ID: <5B639512-DF69-4D38-B331-ABAF1AAF34ED@tee-boy.com>

Here's my take:  the round trip time of sending a check packet, and then IF there is data, sending another packet to retrieve the data costs more in terms of performance than just asking at every interrupt interval for data.  You're going to send a request anyway and get back a response, just two bytes instead of one, and it's all done within one transaction.

Because at the speeds at which we are talking about (115200bps) there is not enough time to look at an incoming byte as a counter for the number of incoming bytes that follow... unless the server throttles  the rate at which it sends data to the CoCo.  So known-sized responses to the CoCo are the key to DriveWire's success.  You could build in a fixed size message that always returns the same number of bytes, but with a counter that indicates the number of VALID bytes:

1. Send OP_SERREAD to the server
2. Server sends an 8 byte packet to the CoCo: 1st byte is valid number of bytes (0-7) and the remaining 7 bytes are valid up to the number reported in the first byte.

The ISR could then shuffle the bytes into the incoming buffer, up to a max of 7.

You could enforce a larger or smaller packet size.

Boisy

On Nov 10, 2009, at 2:10 PM, Aaron Wolfe wrote:

> On Tue, Nov 10, 2009 at 2:54 PM, William Astle <lost at l-w.ca> wrote:
>> Aaron Wolfe wrote:
>>> One question about combining SERREAD and SERCHECK:
>>> 
>>> My original idea was that SERCHECK would return the number of bytes in
>>> the server's buffer, and then SERREAD would ask for a flush of X
>>> bytes, typically the number returned by SERCHECK.  The server would
>>> then write out the # of bytes requested.  This was (in my head) a way
>>> to improve performance for things like rzsz over the virtual serial
>>> port.
>>> 
>>> By combining them, I will be cutting the potential throughput in half
>>> since there are two bytes for each data byte, and also taking a
>>> penalty of having to ask for each byte individually (which is
>>> admittedly how my current driver works, but it was supposed to be
>>> better :)
>>> 
>>> Are there outside factors that mitigate the losses in combining the
>>> calls?  If there is some other reason it will be slow anyway, then I
>>> agree it would make it simpler to combine them.
>>> -Aaron
>> 
>> Why not make the request include a maximum number of bytes to return.
>> Then have the response include the number of bytes returned and those bytes.
>> 
>> This would require tinkering the drivewire scheme so it could handle
>> variable length return packets in some manner but it should provide the
>> maximum theoretical efficiency.
>> 
> 
> This would be nice, but as it stands the dw calls require you to know
> how many bytes are coming/going when you call them.. not sure if I'm
> ready to touch anything in dw itself :)  maybe at some point though..
> i agree this would be ideal.
> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


From aawolfe at gmail.com  Tue Nov 10 16:23:02 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Tue, 10 Nov 2009 16:23:02 -0500
Subject: [Coco] os9/drivewire driver: success!
In-Reply-To: <5B639512-DF69-4D38-B331-ABAF1AAF34ED@tee-boy.com>
References: <4af8653d.e302be0a.77fd.732d@mx.google.com>
	<20091109201252.GH2805@tuxdriver.com>
	<e44ad6640911091350q6d2c5ba5uf86f2fd852b5700b@mail.gmail.com>
	<20091109215522.GA7060@tuxdriver.com>
	<e44ad6640911100250i644223d7pa439be8a4b2ef7a6@mail.gmail.com>
	<F963F749-370D-43D6-9E4B-9E89E06C65E8@tee-boy.com>
	<e44ad6640911101018q66544bb0tb2ee8085ca15c4d3@mail.gmail.com>
	<4AF9C4FC.5070200@l-w.ca>
	<e44ad6640911101210h470f6b4bvf5f3badf641467e9@mail.gmail.com>
	<5B639512-DF69-4D38-B331-ABAF1AAF34ED@tee-boy.com>
Message-ID: <e44ad6640911101323j50f51456m4c938c7d35aab1e@mail.gmail.com>

Darren Atkinson suggested what I think is a good compromise:

Instead of a SERCHECK type of thing, implement SERREAD and SERREADMULTI.

SERREAD is the polling call normally sent by the ISR.  It returns two
bytes: Buffer size, and the first byte in the buffer (if any).

SERREADMULTI takes an argument byte containing the # of bytes to
return, and then returns that many bytes.

In this way no ops are wasted checking the buffer, if it contains a
single byte (typical in interactive sessions) then we have received it
just by checking.  The driver can look at how many additional bytes
are in the server's buffer and decide if it wants to pull a
SERREADMULTI or just let the next ISR tick get things one char at a
time.

Seems like a fairly optimal solution, considering the difficulties
involved in dynamically returning different amounts.   (Thanks Darren
:)

-Aaron



On Tue, Nov 10, 2009 at 4:09 PM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Here's my take: ?the round trip time of sending a check packet, and then IF there is data, sending another packet to retrieve the data costs more in terms of performance than just asking at every interrupt interval for data. ?You're going to send a request anyway and get back a response, just two bytes instead of one, and it's all done within one transaction.
>
> Because at the speeds at which we are talking about (115200bps) there is not enough time to look at an incoming byte as a counter for the number of incoming bytes that follow... unless the server throttles ?the rate at which it sends data to the CoCo. ?So known-sized responses to the CoCo are the key to DriveWire's success. ?You could build in a fixed size message that always returns the same number of bytes, but with a counter that indicates the number of VALID bytes:
>
> 1. Send OP_SERREAD to the server
> 2. Server sends an 8 byte packet to the CoCo: 1st byte is valid number of bytes (0-7) and the remaining 7 bytes are valid up to the number reported in the first byte.
>
> The ISR could then shuffle the bytes into the incoming buffer, up to a max of 7.
>
> You could enforce a larger or smaller packet size.
>
> Boisy
>
> On Nov 10, 2009, at 2:10 PM, Aaron Wolfe wrote:
>
>> On Tue, Nov 10, 2009 at 2:54 PM, William Astle <lost at l-w.ca> wrote:
>>> Aaron Wolfe wrote:
>>>> One question about combining SERREAD and SERCHECK:
>>>>
>>>> My original idea was that SERCHECK would return the number of bytes in
>>>> the server's buffer, and then SERREAD would ask for a flush of X
>>>> bytes, typically the number returned by SERCHECK. ?The server would
>>>> then write out the # of bytes requested. ?This was (in my head) a way
>>>> to improve performance for things like rzsz over the virtual serial
>>>> port.
>>>>
>>>> By combining them, I will be cutting the potential throughput in half
>>>> since there are two bytes for each data byte, and also taking a
>>>> penalty of having to ask for each byte individually (which is
>>>> admittedly how my current driver works, but it was supposed to be
>>>> better :)
>>>>
>>>> Are there outside factors that mitigate the losses in combining the
>>>> calls? ?If there is some other reason it will be slow anyway, then I
>>>> agree it would make it simpler to combine them.
>>>> -Aaron
>>>
>>> Why not make the request include a maximum number of bytes to return.
>>> Then have the response include the number of bytes returned and those bytes.
>>>
>>> This would require tinkering the drivewire scheme so it could handle
>>> variable length return packets in some manner but it should provide the
>>> maximum theoretical efficiency.
>>>
>>
>> This would be nice, but as it stands the dw calls require you to know
>> how many bytes are coming/going when you call them.. not sure if I'm
>> ready to touch anything in dw itself :) ?maybe at some point though..
>> i agree this would be ideal.
>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From asa.rand at yahoo.com  Tue Nov 10 17:03:10 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Tue, 10 Nov 2009 14:03:10 -0800 (PST)
Subject: [Coco] fmato
Message-ID: <377262.79088.qm@web53708.mail.re2.yahoo.com>

I have uploaded fmato3a.B09, fmatoDoc (text file), and fmato.os9 (an image that contains both of those plus the packed module) to sourceforge.

fmatoDoc contains data about the functions of fmato, as well as addressing a few issues fmato has (non-fatal, and doesn't corrupt data).

If anyone on this list has used the CHAIN Basic09 statement before, I may need some help when I'm ready to incorporate that code.

Thanks to everyone on this list who has been helping me with ideas and knowledge of the system that I don't possess. Your contributions have been very important in helping me to understand what is happening when I don't get it.

Wayne


      

From operator at coco3.com  Mon Nov  9 20:13:18 2009
From: operator at coco3.com (Roger Taylor)
Date: Mon, 09 Nov 2009 19:13:18 -0600
Subject: [Coco] CoCoNet status
In-Reply-To: <1b52e6c80911081634o385278e5u6c9011f9d95e9a72@mail.gmail.co
 m>
References: <6.2.5.6.1.20091108120301.05fa1d88@coco3.com>
	<1b52e6c80911081634o385278e5u6c9011f9d95e9a72@mail.gmail.com>
Message-ID: <6.2.5.6.1.20091109182425.05dcd198@coco3.com>

At 06:34 PM 11/8/2009, you wrote:
>I don't have a multipak.  In addition, I want to keep using my
>floppies for RSDOS and booting my floppies for NitrosO9.  How can I
>use my floppies and use Roger's pak at the same time?

A Y-Cable?  All ROMs would have to be disabled except for the one in 
either of my paks.  Only one pak needs the CoCoNet/DECB ROM in 
it.  It handles real 1793 floppies, MicroSD floppies, 115200 bps 
bitbanger floppies, and 115200 ACIA floppies at the same time.  Even 
with an MPI, only one pak needs the ROM in it.



>   There seems to
>be many talented hardware guys in our community, why don't we have a
>replacement for the multipak?
>   I'd like to have a hard drive (for
>NitrosO9 AND my floppies AND Roger's pak and a real serial  port and a
>parallel port (I've got a mint HP Laserjet 4 I'm dying to get working
>with my coco and a serial modem I'd like to hook up and run a REAL
>coco BBS).  I am really hankering after Roy's VGA converter too.  I'm
>looking at the prices of these things (pak, hd, vga) and I'm looking
>at $300+ (and that's not counting the serial/parallel pak (which
>doesn't exist either)).  I want to buy things from Cloud Nine and Roy
>and Roger but I just don't have the cash right now.  And even if I had
>the cash, I wouldn't have a multipak to plug the stuff into.  I don't
>even think you can buy a fracking Y cable these days. Hardware people
>- build the MP replacement so I can plug the hardware in.


I'm trying to eliminate the need for these hard-to-get devices. It's 
time to emulate or eliminate the dying peripherals.

I do realize there is a chicken-and-egg problem for some users 
depending on what all they're trying to do.  There's ways to get some 
programs into the CoCo.  I can take a bare CoCo and CLOAD or CLOADM 
programs from my laptop using the cocotape.exe utility.  Look in the 
Rainbow IDE menu and you'll find the DLOAD command which should let 
you DLOAD stuff into your CoCo 1 or 2 over a bitbanger cable.  If you 
could somehow get Boisy's DW3 patches into Disk BASIC, perhaps you 
would then be able to save your real disks over to the PC in an 
archive, then once you get a virtual drive system like my pak, you 
could copy them back over without even needing your floppy controller 
plugged in.

Sometimes a little creativity can be used to achieve some of the 
things that seem to baffle most newbies and some oldie users who 
never had a need to look into this stuff before... getting your real 
disks or real hard drive backed up on your PC so you can copy them 
back to digital drives on the CoCo.  But then, until a 1793-emulating 
virtual drive pak is made, some stuff won't run from a virtual drive system.

Btw, the original "8K" CoCoNet would run as a patch you could install 
at run-time if you wanted just by LOADMing it into an All-RAM mode 
CoCo 1/2 or any CoCo 3.  Now it runs only from ROM because it's 16K 
and works with any CoCo automatically.

There will be a lot of ebay CoCo hunters who just want to run a bunch 
of games/apps and get OS-9 all on a mini pak.  I've targeted that 
group of CoCo users who won't be so lucky to find an MPI, real drive 
system, or hard drive, etc.  My little scheme as been well thought 
out but long coming, starting with things like CCASM, Portal-9 IDE, 
Rainbow IDE, which paved the way for me to develop with light speed 
compared to the old ways.

I get criticism sometimes for some of the features of CCASM, but I 
can tell you this, if we had that kind of assembly power back in the 
80's, things would have been much different for the CoCo 3.  We never 
saw it's full potential, mainly because of the size limit of floppy 
disks and the inability to make huge programs that loaded into 
extended RAM by using the standard LOADM.

Now, with something like a flash pak or MicroSD pak, you could create 
a bunch of 256-disk partitions and use some for data logging, some 
that could very well contain massive games taking up hundreds of 
disks, and distribute such a game or app as a partition file that a 
user could install.  I realize that not many people will enjoy cool 
stuff like this, but whoever wants to can come to me for a rather 
simple solution.

I've also targeted the 6809 embedded users who want to take an 
otherwise junk CoCo 1, 2, or 3 board, plug in a pak and turn the 
board into a super smart embedded computer.  All those ports on the 
back would be wide-open for the real world, with a mini pak 
containing NitrOS-9 and hundreds of floppy and hard drives on a 
pinky-nail sized memory card.  Data logging would be the simplest use 
that comes to mind.  Robotics is a more creative idea.


-- 
~ Roger Taylor



From RJRTTY at aol.com  Tue Nov 10 22:51:21 2009
From: RJRTTY at aol.com (RJRTTY at aol.com)
Date: Tue, 10 Nov 2009 22:51:21 EST
Subject: [Coco] CoCoNet status
Message-ID: <bbc.5136de9d.382b8eb9@aol.com>

In a message dated 11/10/2009 7:50:18 P.M. Eastern Standard Time,  
operator at coco3.com writes:


>I've also targeted the 6809 embedded users who want to take an  
>otherwise junk CoCo 1, 2, or 3 board, plug in a pak and turn the  
>board into a super smart embedded computer.  All those ports on the  
>back would be wide-open for the real world, with a mini pak  
>containing NitrOS-9 and hundreds of floppy and hard drives on a  
>pinky-nail sized memory card.  Data logging would be the simplest  use 
>that comes to mind.  Robotics is a more creative  idea.


>-- 
>~ Roger Taylor
 
 
NOW you are talking.    I want to get one of those
"spider" type robot walkers and make a "replicator"
type robot to wander around the floor of the next
cocofest controlled by a coco over a wireless
connection or maybe carried piggy back on the
robot.......Damn, I wish I had more time.
 
Roy
 

From coco+list at jeanpaulsamson.com  Wed Nov 11 02:04:18 2009
From: coco+list at jeanpaulsamson.com (J.P. Samson)
Date: Wed, 11 Nov 2009 00:04:18 -0700
Subject: [Coco] Dungeons of Daggorath Program Manual
In-Reply-To: <4AF8D31E.3070006@cox.net>
References: <mailman.17.1257778816.42451.coco@maltedmedia.com>
	<4AF8D31E.3070006@cox.net>
Message-ID: <939BAEE0-0DC1-4BDD-AC47-39EC2BE90D0D@jeanpaulsamson.com>

On Nov-9-09, at 7:42 PM, Andrew wrote:
> It looks almost "print ready"! Like you could almost take it down to  
> a print shop and have them run it off with heavy stock, and have a  
> "real" manual in front of you!
>
> It looks so good, it doesn't look like a scan at all!

The images are 300dpi (e.g. cover art).  The text is resolution- 
independent (synthesized fonts created by Adobe Acrobat's ClearScan  
technology).  So yeah, you could very well take it to the printers!

> I assume you know about the porting project (to the PC)?:
> 	http://mspencer.net/daggorath/dodpcp.html


There's more interesting reading here, including an interview with the  
developer (who is apparently quite a bigwig now):

<http://iloveglory.freehostia.com/daggorath/index.html>

-- JP


From aawolfe at gmail.com  Wed Nov 11 07:10:57 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 11 Nov 2009 07:10:57 -0500
Subject: [Coco] drivewire serial port progress
Message-ID: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>

After a long night of hacking I now have an interrupt based driver
working, and it's working really well.  Took a lot of debugging but I
learned much in the process.

I used a buffer in the style of sc6551's, I think I can get dw to
write straight into it in the future.  I somehow solved the issues
with non VDG consoles, it now works fine with level 1 or 2, any
console mode.  I also got rid of an occasional mysterious input bug.
All in all, it's coming together fast.

Performance with the interrupt driver is very good, I didn't realize
how bad my first attempt was until I got this working.
Thanks for all the help from everyone on the list.  Now I need to
implement a better set of calls between the driver and server, but
Darren sent me an awesome example of how to do this, so that won't
take too long.

It seems like some of the keyboard inputs have to be implemented in
the scf driver, for instance break/escape has to be turned into a
signal to SCF, unless I'm getting this wrong?  So it will take more
than a good terminal program to have a full featured console, I'll
have to do more work in the driver.
For data/modem applications, there is another set of controls.  Can
both be implemented at once, or will there need to be two
modes/descriptors/something?

From snhirsch at gmail.com  Wed Nov 11 07:39:36 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Wed, 11 Nov 2009 07:39:36 -0500 (EST)
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0911110736370.4638@duo>

On Wed, 11 Nov 2009, Aaron Wolfe wrote:

> After a long night of hacking I now have an interrupt based driver
> working, and it's working really well.  Took a lot of debugging but I
> learned much in the process.
>
> I used a buffer in the style of sc6551's, I think I can get dw to
> write straight into it in the future.  I somehow solved the issues
> with non VDG consoles, it now works fine with level 1 or 2, any
> console mode.  I also got rid of an occasional mysterious input bug.
> All in all, it's coming together fast.

I cannot wait to see this.  Nice work!

> For data/modem applications, there is another set of controls.  Can
> both be implemented at once, or will there need to be two
> modes/descriptors/something?

Are you talking from the Linux or CoCo side of things?  On Unix-y systems, 
I believe there are a set of ioctl functions to configure a tty device for 
console or raw data I/O.  On the CoCo side, there are folks a lot smarter 
than I am who'll have to answer :-).

The Unix view is documented reasonably well in Stevens' "Advanced 
Programming in the Unix Environment".

Steve


-- 

From aawolfe at gmail.com  Wed Nov 11 07:54:12 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 11 Nov 2009 07:54:12 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <alpine.DEB.2.00.0911110736370.4638@duo>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<alpine.DEB.2.00.0911110736370.4638@duo>
Message-ID: <e44ad6640911110454s12663f59p4eeca24523380007@mail.gmail.com>

On Wed, Nov 11, 2009 at 7:39 AM, Steven Hirsch <snhirsch at gmail.com> wrote:
> On Wed, 11 Nov 2009, Aaron Wolfe wrote:
>
>> After a long night of hacking I now have an interrupt based driver
>> working, and it's working really well. ?Took a lot of debugging but I
>> learned much in the process.
>>
>> I used a buffer in the style of sc6551's, I think I can get dw to
>> write straight into it in the future. ?I somehow solved the issues
>> with non VDG consoles, it now works fine with level 1 or 2, any
>> console mode. ?I also got rid of an occasional mysterious input bug.
>> All in all, it's coming together fast.
>
> I cannot wait to see this. ?Nice work!
>

If you're brave, you can have it right now http://aaronwolfe.com/coco

>> For data/modem applications, there is another set of controls. ?Can
>> both be implemented at once, or will there need to be two
>> modes/descriptors/something?
>
> Are you talking from the Linux or CoCo side of things? ?On Unix-y systems, I
> believe there are a set of ioctl functions to configure a tty device for
> console or raw data I/O. ?On the CoCo side, there are folks a lot smarter
> than I am who'll have to answer :-).
>

Mostly the Coco side.  As I study the existing SCF drivers and the os9
tech reference, it seems like certain control characters actually have
to be turned into signals, not sent through as characters.   My
concern is that sending binary data through this channel would create
chaos.

> The Unix view is documented reasonably well in Stevens' "Advanced
> Programming in the Unix Environment".
>

One of my favorite books :)  I actually had to get it out when I was
working on the PTY support in this project.
> Steve
>
>
> --
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From boisy at tee-boy.com  Wed Nov 11 09:00:21 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Wed, 11 Nov 2009 08:00:21 -0600
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
Message-ID: <449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>

On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:

> After a long night of hacking I now have an interrupt based driver
> working, and it's working really well.  Took a lot of debugging but I
> learned much in the process.

Super!

> I used a buffer in the style of sc6551's, I think I can get dw to
> write straight into it in the future.  I somehow solved the issues
> with non VDG consoles, it now works fine with level 1 or 2, any
> console mode.  I also got rid of an occasional mysterious input bug.
> All in all, it's coming together fast.
> 
> Performance with the interrupt driver is very good, I didn't realize
> how bad my first attempt was until I got this working.
> Thanks for all the help from everyone on the list.  Now I need to
> implement a better set of calls between the driver and server, but
> Darren sent me an awesome example of how to do this, so that won't
> take too long.
> 
> It seems like some of the keyboard inputs have to be implemented in
> the scf driver, for instance break/escape has to be turned into a
> signal to SCF, unless I'm getting this wrong?  So it will take more
> than a good terminal program to have a full featured console, I'll
> have to do more work in the driver.
> For data/modem applications, there is another set of controls.  Can
> both be implemented at once, or will there need to be two
> modes/descriptors/something?

Typically this is all done in one driver with one descriptor.  Applications like terminal programs that expect to get all bytes and not have the driver interfere with interpreting things like BREAK, etc., will use the I$GetStat call and set the path options for that path to "raw mode" (setting values to 0 for interrupt & break keys, etc).  Again, sc6551 shows how to handle V.INTR and V.QUIT characters... implement that code in your driver, and those applications that want to use the device for non-interactive data will set the path's values to 0 for INTR and QUIT.

When you get your protocol settled, please send me the specifications.  Both the Windows and Mac Servers will need to be updated to accommodate the new opcodes and features.

Boisy

From aawolfe at gmail.com  Wed Nov 11 09:16:22 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 11 Nov 2009 09:16:22 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
Message-ID: <e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>

On Wed, Nov 11, 2009 at 9:00 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:
>
>> After a long night of hacking I now have an interrupt based driver
>> working, and it's working really well. ?Took a lot of debugging but I
>> learned much in the process.
>
> Super!
>
>> I used a buffer in the style of sc6551's, I think I can get dw to
>> write straight into it in the future. ?I somehow solved the issues
>> with non VDG consoles, it now works fine with level 1 or 2, any
>> console mode. ?I also got rid of an occasional mysterious input bug.
>> All in all, it's coming together fast.
>>
>> Performance with the interrupt driver is very good, I didn't realize
>> how bad my first attempt was until I got this working.
>> Thanks for all the help from everyone on the list. ?Now I need to
>> implement a better set of calls between the driver and server, but
>> Darren sent me an awesome example of how to do this, so that won't
>> take too long.
>>
>> It seems like some of the keyboard inputs have to be implemented in
>> the scf driver, for instance break/escape has to be turned into a
>> signal to SCF, unless I'm getting this wrong? ?So it will take more
>> than a good terminal program to have a full featured console, I'll
>> have to do more work in the driver.
>> For data/modem applications, there is another set of controls. ?Can
>> both be implemented at once, or will there need to be two
>> modes/descriptors/something?
>
> Typically this is all done in one driver with one descriptor. ?Applications like terminal programs that expect to get all bytes and not have the driver interfere with interpreting things like BREAK, etc., will use the I$GetStat call and set the path options for that path to "raw mode" (setting values to 0 for interrupt & break keys, etc). ?Again, sc6551 shows how to handle V.INTR and V.QUIT characters... implement that code in your driver, and those applications that want to use the device for non-interactive data will set the path's values to 0 for INTR and QUIT.
>

Ah yes.. haven't really implemented get/setstat beyond the minimum to
make things run yet :)  that makes sense though, and 6551 does have
good examples so shouldn't be to hard to put in place.

> When you get your protocol settled, please send me the specifications. ?Both the Windows and Mac Servers will need to be updated to accommodate the new opcodes and features.
>

Will do..  I can (probably) make the changes needed to make the Mac
server work, but not sure if Windows can do ptys.. in any case can try
to find some work around or just ignore the ops at least.  I'd guess
most folks that would be that interested in something like this would
be more *nix inclined than pointy clicky types, but who knows.

-Aaron

> Boisy
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From kg4knb at hat3.net  Wed Nov 11 10:00:21 2009
From: kg4knb at hat3.net (Jim Hathaway)
Date: Wed, 11 Nov 2009 09:00:21 -0600
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
Message-ID: <a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>

On Wed, Nov 11, 2009 at 8:16 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:

> On Wed, Nov 11, 2009 at 9:00 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> > On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:
> >
> >> After a long night of hacking I now have an interrupt based driver
> >> working, and it's working really well.  Took a lot of debugging but I
> >> learned much in the process.
> >
> > Super!
> >
> >> I used a buffer in the style of sc6551's, I think I can get dw to
> >> write straight into it in the future.  I somehow solved the issues
> >> with non VDG consoles, it now works fine with level 1 or 2, any
> >> console mode.  I also got rid of an occasional mysterious input bug.
> >> All in all, it's coming together fast.
> >>
> >> Performance with the interrupt driver is very good, I didn't realize
> >> how bad my first attempt was until I got this working.
> >> Thanks for all the help from everyone on the list.  Now I need to
> >> implement a better set of calls between the driver and server, but
> >> Darren sent me an awesome example of how to do this, so that won't
> >> take too long.
> >>
> >> It seems like some of the keyboard inputs have to be implemented in
> >> the scf driver, for instance break/escape has to be turned into a
> >> signal to SCF, unless I'm getting this wrong?  So it will take more
> >> than a good terminal program to have a full featured console, I'll
> >> have to do more work in the driver.
> >> For data/modem applications, there is another set of controls.  Can
> >> both be implemented at once, or will there need to be two
> >> modes/descriptors/something?
> >
> > Typically this is all done in one driver with one descriptor.
>  Applications like terminal programs that expect to get all bytes and not
> have the driver interfere with interpreting things like BREAK, etc., will
> use the I$GetStat call and set the path options for that path to "raw mode"
> (setting values to 0 for interrupt & break keys, etc).  Again, sc6551 shows
> how to handle V.INTR and V.QUIT characters... implement that code in your
> driver, and those applications that want to use the device for
> non-interactive data will set the path's values to 0 for INTR and QUIT.
> >
>
> Ah yes.. haven't really implemented get/setstat beyond the minimum to
> make things run yet :)  that makes sense though, and 6551 does have
> good examples so shouldn't be to hard to put in place.
>
> > When you get your protocol settled, please send me the specifications.
>  Both the Windows and Mac Servers will need to be updated to accommodate the
> new opcodes and features.
> >
>
> Will do..  I can (probably) make the changes needed to make the Mac
> server work, but not sure if Windows can do ptys.. in any case can try
> to find some work around or just ignore the ops at least.  I'd guess
> most folks that would be that interested in something like this would
> be more *nix inclined than pointy clicky types, but who knows.
>
>
I think this is a great new DriveWire addition.  I would love to see this
work in all versions of DriveWire.  When I use DriveWire I typically use the
windows version.

Jim



> -Aaron
>
> > Boisy
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From farna at att.net  Wed Nov 11 20:03:28 2009
From: farna at att.net (Frank Swygert)
Date: Wed, 11 Nov 2009 20:03:28 -0500
Subject: [Coco] CoCoNet status
Message-ID: <4AFB5EE0.1000809@att.net>

Hmm.... well, now that you have the CoNect wireless pack you need to work on a Linux (or some other OS) live CD that will boot on a monitor and keyboardless PC with Bluetooth enabled (of course a Bluetooth device would be needed). Then one could fire up the CoCo beside it and use the PC as a simple slave storage system. Instead of a live CD a bootable USB drive might be better --just run from it. Get a small ITX board with Bluetooth and drives and that's all you'd need for a drive sub-system for the CoCo. Some of the Mini ITX boards, especially older ones, are rather cheap, like these:
http://www.surplusgizmos.com/Single-Board-Computers-SBC_c_41.html
Six for $130 = $21.67 each (your cost... sell them with a CoCoNet pack....)
Not 100% sure, but I think they are these: 
http://www.axiontech.com/prdt.php?item=34631
Of course you'd have to contact SurplusGizmos and find out for sure what the little boards have. Should be a USB Bluetooth transmitter available...


--------------
Date: Mon, 09 Nov 2009 19:13:18 -0600
From: Roger Taylor <operator at coco3.com>

I'm trying to eliminate the need for these hard-to-get devices. It's 
time to emulate or eliminate the dying peripherals.

-- 
Frank Swygert
Publisher, "American Motors Cars" 
Magazine (AMC)
For all AMC enthusiasts
http://farna.home.att.net/AMC.html
(free download available!)


From aawolfe at gmail.com  Wed Nov 11 20:35:56 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 11 Nov 2009 20:35:56 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
Message-ID: <e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>

On Wed, Nov 11, 2009 at 10:00 AM, Jim Hathaway <kg4knb at hat3.net> wrote:
> On Wed, Nov 11, 2009 at 8:16 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>
>> On Wed, Nov 11, 2009 at 9:00 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>> > On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:
>> >
>> >> After a long night of hacking I now have an interrupt based driver
>> >> working, and it's working really well. ?Took a lot of debugging but I
>> >> learned much in the process.
>> >
>> > Super!
>> >
>> >> I used a buffer in the style of sc6551's, I think I can get dw to
>> >> write straight into it in the future. ?I somehow solved the issues
>> >> with non VDG consoles, it now works fine with level 1 or 2, any
>> >> console mode. ?I also got rid of an occasional mysterious input bug.
>> >> All in all, it's coming together fast.
>> >>
>> >> Performance with the interrupt driver is very good, I didn't realize
>> >> how bad my first attempt was until I got this working.
>> >> Thanks for all the help from everyone on the list. ?Now I need to
>> >> implement a better set of calls between the driver and server, but
>> >> Darren sent me an awesome example of how to do this, so that won't
>> >> take too long.
>> >>
>> >> It seems like some of the keyboard inputs have to be implemented in
>> >> the scf driver, for instance break/escape has to be turned into a
>> >> signal to SCF, unless I'm getting this wrong? ?So it will take more
>> >> than a good terminal program to have a full featured console, I'll
>> >> have to do more work in the driver.
>> >> For data/modem applications, there is another set of controls. ?Can
>> >> both be implemented at once, or will there need to be two
>> >> modes/descriptors/something?
>> >
>> > Typically this is all done in one driver with one descriptor.
>> ?Applications like terminal programs that expect to get all bytes and not
>> have the driver interfere with interpreting things like BREAK, etc., will
>> use the I$GetStat call and set the path options for that path to "raw mode"
>> (setting values to 0 for interrupt & break keys, etc). ?Again, sc6551 shows
>> how to handle V.INTR and V.QUIT characters... implement that code in your
>> driver, and those applications that want to use the device for
>> non-interactive data will set the path's values to 0 for INTR and QUIT.
>> >
>>
>> Ah yes.. haven't really implemented get/setstat beyond the minimum to
>> make things run yet :) ?that makes sense though, and 6551 does have
>> good examples so shouldn't be to hard to put in place.
>>
>> > When you get your protocol settled, please send me the specifications.
>> ?Both the Windows and Mac Servers will need to be updated to accommodate the
>> new opcodes and features.
>> >
>>
>> Will do.. ?I can (probably) make the changes needed to make the Mac
>> server work, but not sure if Windows can do ptys.. in any case can try
>> to find some work around or just ignore the ops at least. ?I'd guess
>> most folks that would be that interested in something like this would
>> be more *nix inclined than pointy clicky types, but who knows.
>>
>>
> I think this is a great new DriveWire addition. ?I would love to see this
> work in all versions of DriveWire. ?When I use DriveWire I typically use the
> windows version.
>

I will do what I can.   After spending some time with Google, Windows
does not appear to support PTYs, while linux and mac (and many other
os) do.  The PTY functionality makes the emulated serial port show up
on the server as a basically regular device able to be used with
practically any application running on the server machine, such as a
standard terminal program.  Without PTY support, I'm not sure there is
a way to do such a thing in Windows.  This means you would not be able
to use a regular Windows terminal program or other software to access
the Coco's DW serial port like you could in the *nix environments.

The other part of my project, a modem emulator that uses hayes
commands to set up tcpip connections, should be portable to all three
operating systems without too much trouble.   In a way this might
provide some amount of a workaround to the lack of PTY support in
Windows.  You could telnet to localhost on the server and connect to
the virtual serial port that way.  Not ideal but in truth probably
good enough.

I had planned on writing this modem/ip part of the project as a
separate utility that just talked to the PTY provided by drivewire, to
keep the dw server code as clean and focused as possible.  In the
Windows version, I suppose it would have to be grafted into the server
code and work directly with the buffers there.  Probably not a big
deal, but would make the Windows server architecturally quite
different from the others.

Maybe smarter people have a better way to work that out :)



> Jim
>
>
>
>> -Aaron
>>
>> > Boisy
>> >
>> > --
>> > Coco mailing list
>> > Coco at maltedmedia.com
>> > http://five.pairlist.net/mailman/listinfo/coco
>> >
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Wed Nov 11 20:54:28 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 11 Nov 2009 20:54:28 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
Message-ID: <e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>

I think I was using the wrong terms searching Google for Windows PTY
support. I found this this:  http://com0com.sourceforge.net/
which might solve the lack of PTYs in Windows nicely.


On Wed, Nov 11, 2009 at 8:35 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Wed, Nov 11, 2009 at 10:00 AM, Jim Hathaway <kg4knb at hat3.net> wrote:
>> On Wed, Nov 11, 2009 at 8:16 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>>
>>> On Wed, Nov 11, 2009 at 9:00 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>> > On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:
>>> >
>>> >> After a long night of hacking I now have an interrupt based driver
>>> >> working, and it's working really well. ?Took a lot of debugging but I
>>> >> learned much in the process.
>>> >
>>> > Super!
>>> >
>>> >> I used a buffer in the style of sc6551's, I think I can get dw to
>>> >> write straight into it in the future. ?I somehow solved the issues
>>> >> with non VDG consoles, it now works fine with level 1 or 2, any
>>> >> console mode. ?I also got rid of an occasional mysterious input bug.
>>> >> All in all, it's coming together fast.
>>> >>
>>> >> Performance with the interrupt driver is very good, I didn't realize
>>> >> how bad my first attempt was until I got this working.
>>> >> Thanks for all the help from everyone on the list. ?Now I need to
>>> >> implement a better set of calls between the driver and server, but
>>> >> Darren sent me an awesome example of how to do this, so that won't
>>> >> take too long.
>>> >>
>>> >> It seems like some of the keyboard inputs have to be implemented in
>>> >> the scf driver, for instance break/escape has to be turned into a
>>> >> signal to SCF, unless I'm getting this wrong? ?So it will take more
>>> >> than a good terminal program to have a full featured console, I'll
>>> >> have to do more work in the driver.
>>> >> For data/modem applications, there is another set of controls. ?Can
>>> >> both be implemented at once, or will there need to be two
>>> >> modes/descriptors/something?
>>> >
>>> > Typically this is all done in one driver with one descriptor.
>>> ?Applications like terminal programs that expect to get all bytes and not
>>> have the driver interfere with interpreting things like BREAK, etc., will
>>> use the I$GetStat call and set the path options for that path to "raw mode"
>>> (setting values to 0 for interrupt & break keys, etc). ?Again, sc6551 shows
>>> how to handle V.INTR and V.QUIT characters... implement that code in your
>>> driver, and those applications that want to use the device for
>>> non-interactive data will set the path's values to 0 for INTR and QUIT.
>>> >
>>>
>>> Ah yes.. haven't really implemented get/setstat beyond the minimum to
>>> make things run yet :) ?that makes sense though, and 6551 does have
>>> good examples so shouldn't be to hard to put in place.
>>>
>>> > When you get your protocol settled, please send me the specifications.
>>> ?Both the Windows and Mac Servers will need to be updated to accommodate the
>>> new opcodes and features.
>>> >
>>>
>>> Will do.. ?I can (probably) make the changes needed to make the Mac
>>> server work, but not sure if Windows can do ptys.. in any case can try
>>> to find some work around or just ignore the ops at least. ?I'd guess
>>> most folks that would be that interested in something like this would
>>> be more *nix inclined than pointy clicky types, but who knows.
>>>
>>>
>> I think this is a great new DriveWire addition. ?I would love to see this
>> work in all versions of DriveWire. ?When I use DriveWire I typically use the
>> windows version.
>>
>
> I will do what I can. ? After spending some time with Google, Windows
> does not appear to support PTYs, while linux and mac (and many other
> os) do. ?The PTY functionality makes the emulated serial port show up
> on the server as a basically regular device able to be used with
> practically any application running on the server machine, such as a
> standard terminal program. ?Without PTY support, I'm not sure there is
> a way to do such a thing in Windows. ?This means you would not be able
> to use a regular Windows terminal program or other software to access
> the Coco's DW serial port like you could in the *nix environments.
>
> The other part of my project, a modem emulator that uses hayes
> commands to set up tcpip connections, should be portable to all three
> operating systems without too much trouble. ? In a way this might
> provide some amount of a workaround to the lack of PTY support in
> Windows. ?You could telnet to localhost on the server and connect to
> the virtual serial port that way. ?Not ideal but in truth probably
> good enough.
>
> I had planned on writing this modem/ip part of the project as a
> separate utility that just talked to the PTY provided by drivewire, to
> keep the dw server code as clean and focused as possible. ?In the
> Windows version, I suppose it would have to be grafted into the server
> code and work directly with the buffers there. ?Probably not a big
> deal, but would make the Windows server architecturally quite
> different from the others.
>
> Maybe smarter people have a better way to work that out :)
>
>
>
>> Jim
>>
>>
>>
>>> -Aaron
>>>
>>> > Boisy
>>> >
>>> > --
>>> > Coco mailing list
>>> > Coco at maltedmedia.com
>>> > http://five.pairlist.net/mailman/listinfo/coco
>>> >
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>

From snhirsch at gmail.com  Wed Nov 11 20:57:38 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Wed, 11 Nov 2009 20:57:38 -0500 (EST)
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0911112056070.4638@duo>

On Wed, 11 Nov 2009, Aaron Wolfe wrote:

>> I think this is a great new DriveWire addition. ?I would love to see this
>> work in all versions of DriveWire. ?When I use DriveWire I typically use the
>> windows version.
>>
>
> I will do what I can.   After spending some time with Google, Windows
> does not appear to support PTYs, while linux and mac (and many other
> os) do.  The PTY functionality makes the emulated serial port show up
> on the server as a basically regular device able to be used with
> practically any application running on the server machine, such as a
> standard terminal program.  Without PTY support, I'm not sure there is
> a way to do such a thing in Windows.  This means you would not be able
> to use a regular Windows terminal program or other software to access
> the Coco's DW serial port like you could in the *nix environments.

Aaron,

It might be worth taking a look at how Cygwin handles ptys.  A large 
number of applications that use them have been ported, so there must be 
some way to get equivalent functionality.

Steve


-- 

From linville at tuxdriver.com  Wed Nov 11 21:00:42 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 11 Nov 2009 21:00:42 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
Message-ID: <20091112020042.GA27541@tuxdriver.com>

On Wed, Nov 11, 2009 at 08:54:28PM -0500, Aaron Wolfe wrote:
> I think I was using the wrong terms searching Google for Windows PTY
> support. I found this this:  http://com0com.sourceforge.net/
> which might solve the lack of PTYs in Windows nicely.

Yes, this looks like exactly what is needed for Windows.  I stumbled
upon that the other day when the question arose, but I didn't put it
together then.

So it looks like there is a decent solution for all the supported
servers! :-)

John
-- 
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.

From linville at tuxdriver.com  Thu Nov 12 07:33:28 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Thu, 12 Nov 2009 07:33:28 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <20091112020042.GA27541@tuxdriver.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
Message-ID: <20091112123328.GA4249@tuxdriver.com>

On Wed, Nov 11, 2009 at 09:00:42PM -0500, John W. Linville wrote:
> On Wed, Nov 11, 2009 at 08:54:28PM -0500, Aaron Wolfe wrote:
> > I think I was using the wrong terms searching Google for Windows PTY
> > support. I found this this:  http://com0com.sourceforge.net/
> > which might solve the lack of PTYs in Windows nicely.
> 
> Yes, this looks like exactly what is needed for Windows.  I stumbled
> upon that the other day when the question arose, but I didn't put it
> together then.
> 
> So it looks like there is a decent solution for all the supported
> servers! :-)

BTW, unless you really fancy writing your own, the "telnet to the
coco serial port" part seems to be readily available now that you
are using a PTY:

	http://ser2net.sourceforge.net/

ser2net is packaged for Fedora (so you don't have to build it).  I have
no idea about other distros, but I imagine that at least Debian has
it too...

John

P.S.  I'm pretty sure the "Internet modem" part is available out
there too, just haven't put a finger on it...
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From aawolfe at gmail.com  Thu Nov 12 08:07:54 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 12 Nov 2009 08:07:54 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <20091112123328.GA4249@tuxdriver.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
	<20091112123328.GA4249@tuxdriver.com>
Message-ID: <e44ad6640911120507h99e17a5q924dc60bca62de53@mail.gmail.com>

On Thu, Nov 12, 2009 at 7:33 AM, John W. Linville
<linville at tuxdriver.com> wrote:
> On Wed, Nov 11, 2009 at 09:00:42PM -0500, John W. Linville wrote:
>> On Wed, Nov 11, 2009 at 08:54:28PM -0500, Aaron Wolfe wrote:
>> > I think I was using the wrong terms searching Google for Windows PTY
>> > support. I found this this: ?http://com0com.sourceforge.net/
>> > which might solve the lack of PTYs in Windows nicely.
>>
>> Yes, this looks like exactly what is needed for Windows. ?I stumbled
>> upon that the other day when the question arose, but I didn't put it
>> together then.
>>
>> So it looks like there is a decent solution for all the supported
>> servers! :-)
>
> BTW, unless you really fancy writing your own, the "telnet to the
> coco serial port" part seems to be readily available now that you
> are using a PTY:
>
> ? ? ? ?http://ser2net.sourceforge.net/
>
> ser2net is packaged for Fedora (so you don't have to build it). ?I have
> no idea about other distros, but I imagine that at least Debian has
> it too...

Cool, I figured a solution for that existed somewhere.  For now I'm
just talking to the PTY with minicom, but direct network access would
be nice.

>
> John
>
> P.S. ?I'm pretty sure the "Internet modem" part is available out
> there too, just haven't put a finger on it...

I found commercial programs for this, but nothing open source (yet)..
if you do find something please let me know.  It's not a big deal to
write this part in linux, but a solution for the Windows side would be
especially handy.


> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From asa.rand at yahoo.com  Thu Nov 12 17:59:54 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Thu, 12 Nov 2009 14:59:54 -0800 (PST)
Subject: [Coco] good news and more progress
Message-ID: <332064.24707.qm@web53703.mail.re2.yahoo.com>

I have fmato working now. The time stamp problem has been fixed, and the literal sort routine is functioning properly. Also, I replaced the old runb with the runb that came with NitrOS9 (with syscall, inkey and gfx2 merged), and the program launched form the command line with no errors. Apparently, the mods to runb and basic09 did make a difference.

I incorporated the CHAIN command, and now there are two procedures. I like using the name fmato as a development name, so I renamed fmato to decode, and named the new procedure fmato.

Currently, decode doesn't do anything more than it did, in terms of decoding the I-Code, but now I can start on the variable reference identifications. I have to compare the references to the VDT, the DSAT and their data memory addresses in order to complete the variable identification process.

I have uploaded the new files to sourceforge. The folder name is decode, and includes both source files, a doc file, and the decode.os9 disk image file. The disk image includes the source files, doc file and module files.

Wayne



      

From jcewy at swbell.net  Thu Nov 12 22:51:15 2009
From: jcewy at swbell.net (Joel Ewy)
Date: Thu, 12 Nov 2009 21:51:15 -0600
Subject: [Coco] good news and more progress
In-Reply-To: <332064.24707.qm@web53703.mail.re2.yahoo.com>
References: <332064.24707.qm@web53703.mail.re2.yahoo.com>
Message-ID: <4AFCD7B3.60800@swbell.net>

Wayne Campbell wrote:
> I have fmato working now. The time stamp problem has been fixed, and the literal sort routine is functioning properly. Also, I replaced the old runb with the runb that came with NitrOS9 (with syscall, inkey and gfx2 merged), and the program launched form the command line with no errors. Apparently, the mods to runb and basic09 did make a difference.
>
> I incorporated the CHAIN command, and now there are two procedures. I like using the name fmato as a development name, so I renamed fmato to decode, and named the new procedure fmato.
>
> Currently, decode doesn't do anything more than it did, in terms of decoding the I-Code, but now I can start on the variable reference identifications. I have to compare the references to the VDT, the DSAT and their data memory addresses in order to complete the variable identification process.
>
> I have uploaded the new files to sourceforge. The folder name is decode, and includes both source files, a doc file, and the decode.os9 disk image file. The disk image includes the source files, doc file and module files.
>
> Wayne
>
>
>   

This is cool stuff, Wayne.  It makes me wish I had a reason to decompile 
BASIC09 Icode...  :)

JCE

>       
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>   


From goosey at virgo.sdc.org  Fri Nov 13 06:51:53 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Fri, 13 Nov 2009 04:51:53 -0700
Subject: [Coco] curses update
Message-ID: <20091113115153.GA4711@virgo.sdc.org>

After sitting on my thumbs for 2 months... :-(

I worked more on curses, and got wprintw() to work, and also fixed the
NULL-pointer bug in box().

This varargs stuff is pretty wild.  The Compiler really doesn't
approve...

printw() doesn't work yet.

Anyway, the newest version, with source and 6809 library is
http://www.sdc.org/~goosey/os9/curses03.lzh

It also includes a couple of sexy new test programs! :-)

Try it, so you can be foiled again!
Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From operator at coco3.com  Thu Nov 12 22:40:03 2009
From: operator at coco3.com (Roger Taylor)
Date: Thu, 12 Nov 2009 21:40:03 -0600
Subject: [Coco] CoCoNet status
In-Reply-To: <4AFB5EE0.1000809@att.net>
References: <4AFB5EE0.1000809@att.net>
Message-ID: <6.2.5.6.1.20091112211808.06177388@coco3.com>

At 07:03 PM 11/11/2009, you wrote:
>Hmm.... well, now that you have the CoNect wireless pack you need to 
>work on a Linux (or some other OS) live CD that will boot on a 
>monitor and keyboardless PC with Bluetooth enabled (of course a 
>Bluetooth device would be needed). Then one could fire up the CoCo 
>beside it and use the PC as a simple slave storage system. Instead 
>of a live CD a bootable USB drive might be better --just run from 
>it. Get a small ITX board with Bluetooth and drives and that's all 
>you'd need for a drive sub-system for the CoCo. Some of the Mini ITX 
>boards, especially older ones, are rather cheap, like these:
>http://www.surplusgizmos.com/Single-Board-Computers-SBC_c_41.html
>Six for $130 = $21.67 each (your cost... sell them with a CoCoNet pack....)
>Not 100% sure, but I think they are these: 
>http://www.axiontech.com/prdt.php?item=34631
>Of course you'd have to contact SurplusGizmos and find out for sure 
>what the little boards have. Should be a USB Bluetooth transmitter available...


I don't know... a MicroDrive module gives up to 2gb to the CoCo using 
the current firmware they have on it.

A MicroSD card is pretty damn small.  In fact, it's small enough to 
lose if you're not careful.  I'm impressed by the size vs. capacity 
of those things.  We could very well see massive CoCo apps or games 
distributed on MicroSD for Drive Pak owners.  Not only that, but CoCo 
"video", music, raw pictures that load quickly, and all sorts of 
"limitless" ideas.

Remember the Dragon's Lair game that was pretty much based on 
prearranged cartoon sequences?  Something like that would be easier 
to write than you'd think.  Think of it as a book where you choose 
which chapter to go to next to make your own story ending.  Anyway, 
I'm just throwing a random idea out there.

With the CoCoNet ROM in the pak, AUTOBOOT.BAS is run automatically on 
power-up, from virtual floppy #0.  From there you can launch or do 
anything, including ML.  Any BASIC programmer can have a field 
day.  ML programmers would just need to call the DSKCON hook in Disk 
BASIC to access the disks and raw sectors.

Tonight I simply made by AUTOBOOT.BAS program switch to disk #254 and 
boot OS-9 over the pak:
10 DRIVE 0,#254
20 DOS

Done.  NitrOS-9 L2 prompt in 15 seconds, no moving parts, pure 
silence, and Boisy's DriveWire 3 drivers are even in the boot 
file.  In fact, I want to thank Boisy for having the original 
NitrOS-9 boot floppies with all the drivers and scripts to simplify 
making new boot disks with other drivers.  I took it from there and 
ended up with my own Drive Pak bootable disk but left the DW3 stuff 
in there.  Users can choose between the CoCoNet server or DW3 server, 
although they use totally different schemes.  From BASIC you can 
mount floppies by pathname/web URL from the CoCo and there is no 
GUI.  It's a console window.  I do have a GUI version but there's no 
time to finish it this year.  It has vertically arranged 5.25" style 
floppy drives that open and close with the lever and have the 
red/green LEDs, and a scrolling log window.  The console version 
shows the log as well.  Both are in VB.NET and could be expanded on 
or ported by users over time if we like.

The CoCoNet server behaves like a modem.  You can send AT commands to 
it to do everything, including Telnet, but that requires a terminal 
program, as CoCoNet doesn't deal with Telnet.

If the pak boot file is not there, a search will be made on the 
server disk #0, then the real drives.

Does anybody have an OS-9 VHD they'd like to distribute on the 
pak?  Zip it and e-mail it to me and I'll get it on there.  I don't 
have time to get any of the game floppies to boot and run from the 
pak on a per disk basis, but a fully loaded VHD with all the cool 
stuff on it would be easy to integrate.




-- 
~ Roger Taylor



From aawolfe at gmail.com  Fri Nov 13 19:38:58 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 13 Nov 2009 19:38:58 -0500
Subject: [Coco] CoCoNet status
In-Reply-To: <6.2.5.6.1.20091112211808.06177388@coco3.com>
References: <4AFB5EE0.1000809@att.net>
	<6.2.5.6.1.20091112211808.06177388@coco3.com>
Message-ID: <e44ad6640911131638q433fc601n6f726f290c62e019@mail.gmail.com>

On Thu, Nov 12, 2009 at 10:40 PM, Roger Taylor <operator at coco3.com> wrote:
> At 07:03 PM 11/11/2009, you wrote:
>>
>> Hmm.... well, now that you have the CoNect wireless pack you need to work
>> on a Linux (or some other OS) live CD that will boot on a monitor and
>> keyboardless PC with Bluetooth enabled (of course a Bluetooth device would
>> be needed). Then one could fire up the CoCo beside it and use the PC as a
>> simple slave storage system. Instead of a live CD a bootable USB drive might
>> be better --just run from it. Get a small ITX board with Bluetooth and
>> drives and that's all you'd need for a drive sub-system for the CoCo. Some
>> of the Mini ITX boards, especially older ones, are rather cheap, like these:
>> http://www.surplusgizmos.com/Single-Board-Computers-SBC_c_41.html
>> Six for $130 = $21.67 each (your cost... sell them with a CoCoNet
>> pack....)
>> Not 100% sure, but I think they are these:
>> http://www.axiontech.com/prdt.php?item=34631
>> Of course you'd have to contact SurplusGizmos and find out for sure what
>> the little boards have. Should be a USB Bluetooth transmitter available...
>
>
> I don't know... a MicroDrive module gives up to 2gb to the CoCo using the
> current firmware they have on it.
>
> A MicroSD card is pretty damn small. ?In fact, it's small enough to lose if
> you're not careful. ?I'm impressed by the size vs. capacity of those things.
> ?We could very well see massive CoCo apps or games distributed on MicroSD
> for Drive Pak owners. ?Not only that, but CoCo "video", music, raw pictures
> that load quickly, and all sorts of "limitless" ideas.
>
> Remember the Dragon's Lair game that was pretty much based on prearranged
> cartoon sequences? ?Something like that would be easier to write than you'd
> think. ?Think of it as a book where you choose which chapter to go to next
> to make your own story ending. ?Anyway, I'm just throwing a random idea out
> there.
>
> With the CoCoNet ROM in the pak, AUTOBOOT.BAS is run automatically on
> power-up, from virtual floppy #0. ?From there you can launch or do anything,
> including ML. ?Any BASIC programmer can have a field day. ?ML programmers
> would just need to call the DSKCON hook in Disk BASIC to access the disks
> and raw sectors.
>
> Tonight I simply made by AUTOBOOT.BAS program switch to disk #254 and boot
> OS-9 over the pak:
> 10 DRIVE 0,#254
> 20 DOS
>
> Done. ?NitrOS-9 L2 prompt in 15 seconds, no moving parts, pure silence, and
> Boisy's DriveWire 3 drivers are even in the boot file. ?In fact, I want to
> thank Boisy for having the original NitrOS-9 boot floppies with all the
> drivers and scripts to simplify making new boot disks with other drivers. ?I
> took it from there and ended up with my own Drive Pak bootable disk but left
> the DW3 stuff in there. ?Users can choose between the CoCoNet server or DW3
> server, although they use totally different schemes. ?From BASIC you can
> mount floppies by pathname/web URL from the CoCo and there is no GUI. ?It's
> a console window. ?I do have a GUI version but there's no time to finish it
> this year. ?It has vertically arranged 5.25" style floppy drives that open
> and close with the lever and have the red/green LEDs, and a scrolling log
> window. ?The console version shows the log as well. ?Both are in VB.NET and
> could be expanded on or ported by users over time if we like.
>
> The CoCoNet server behaves like a modem. ?You can send AT commands to it to
> do everything, including Telnet, but that requires a terminal program, as
> CoCoNet doesn't deal with Telnet.
>

Does CoCoNet create a virtual serial port on windows, or PTY in
linux/mac os x?  If so, I'd be happy to make every attempt to support
it in my serial -> tcpip project for drivewire.  Also I'm considering
a full screen terminal application tailored to CoCo/OS9 use, I'd love
to be able to support CoCoNet in addition to DriveWire.   Maybe most
importantly, is CoCoNet free (as in freedom) software?


> If the pak boot file is not there, a search will be made on the server disk
> #0, then the real drives.
>
> Does anybody have an OS-9 VHD they'd like to distribute on the pak? ?Zip it
> and e-mail it to me and I'll get it on there. ?I don't have time to get any
> of the game floppies to boot and run from the pak on a per disk basis, but a
> fully loaded VHD with all the cool stuff on it would be easy to integrate.
>
>
>
>
> --
> ~ Roger Taylor
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Fri Nov 13 23:56:16 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 13 Nov 2009 23:56:16 -0500
Subject: [Coco] drivewire serial port protocol - RFC
Message-ID: <e44ad6640911132056w5d1bbb40x1a740dcbd2f499ba@mail.gmail.com>

Progress continues on the drivewire serial support additions.  As I
make the driver more robust (getstat/setstat support, signals, etc) I
think I'll need to implement a way to communicate some port status
from the server side to the driver.   At a bare minimum, I think the
coco should be able to initialize and term the PTY, rather than the
way it works now where you must do the server side manually.  It would
be nice to support or emulate  rs232 controls from host to coco
(DCD,DSR,RTS/CTS, Ring, etc).  There may need to be support for out of
band data in order to implement a nice terminal interface, not sure on
this one yet.

I've also started to look at tuning for performance.  115,200bps is
really fast.  I haven't done good tests yet on how fast data the Coco
can digest and get data into a terminal program or rzsz for example,
but getting the data into the driver's buffer at least is very, very
quick.  I can quite easily fill the buffer more quickly than the
coco's console can print it out, that's about as far as I've gone in
actually processing it.

On the other hand, an interactive terminal session barely makes a
dent.  I have to copy and paste data into the terminal program to even
trigger the READM operation (this op happens when more than 1 byte
exists in the server's input buffer).  There's no need for a large
buffer on either side for these.

As I started laying out bits and bytes for the getstat and setstat
ops, I had some left over.. and that got me thinking.. why have only
one port?  The poller has to run pretty often to provide decent
latency in interactive sessions, whether you've got one terminal user
or 10 doesn't make much difference.
It would be kind of cool to have a handful of OS-9 shells running in
different windows on my PC.  I can see how having one port for
data/modem/internet things and another for an interactive shell could
be nice.  A multiline OS-9 BBS would be easy to support (if software
for this exists.. I'm not very familiar with what is available under
OS-9)

Anyway, all of this brings me to defining a proper spec that at least
supports doing rs232 status, performance tuning based on application,
and possibly multiple virtual serial ports, 7 seem to fit nicely
without causing any extra bytes in most calls.   Here's what I'm
thinking now, I would greatly appreciate ideas, comments and
criticism.   Maybe I've gone off the deep end here, I'm open to that
possibility.



The port(s) can be in one of two modes:
   Interactive mode - SCF features enabled, 18 byte buffer = 126 bytes
for 7 ports
   Data stream mode - Pure pass through mode, no SCF signals.  1024
byte buffer.. max 1 port in data mode?   (1024 bytes because at
115.2k, 1440 bytes could be transferred in 0.1 seconds, the current
polling interval. giving some time for overhead, 1K seemed nice.  its
really just a guess at this point, the idea would be to maximize
throughput in any case.  in a 512k machine I think 1k used for buffer
would be acceptable, if the coco can digest the data fast enough to
matter.)

Add get and set status OPs, change SERREAD,M, and WRITE to support
multiport(?).  May want a WRITEM also, not sure

SERREAD  (this is the poller, occurs 10 times per second currently but
can certainly change)

  1 byte command (just the opcode)

  2 byte response:

    byte 1: first bit indicates the server thinks the client should do
a GETSTAT on highest priority port with data, 7 bits indicate which of
the seven ports have data in buffer, priority is just order of bits.
all 0 means nobody has anything waiting.  The OS-9 driver can make
decisions based on which ports have data waiting, such as sending a
second SERREAD during this interrupt, etc.
    byte 2:  data byte for highest priority port that has data

This would allow SERREAD to perform exactly as it does now if only one
port is active, and I think it would perform well for multiple
interactive users too, without adding any bytes to the operation.
Since a vast majority of interactive sessions would never cause a
READM, it's basically equivalent there.

Since we are not returning the buffer size in the SERREAD, as it does
now, it means an additional call (GETSTAT).  However, we'd have to use
some additional bytes to properly support a single port anyway (rs232
status bits, and the buffer size response needs to be bigger than 1
byte when in data stream mode).

So, when the server tells the driver it should do a GETSTAT, the
client should normally obey.  The server could decide to mask the fact
that higher priority ports have data waiting when time critical status
changes occur on a lower priority port (ring indicator, port closed on
server side... probably would not really implement true DCD,RTS etc
but could simulate the effect to some degree).   The basic idea would
be to have the server make suggestions to the client, since it has
more resources for figuring things out.  The SERREAD response can tell
the driver: hey, you should really look at port X.   There is no
requirement for the client to obey, everything is completely async/no
state etc.

SERGETSTAT - inquire port status,
2 byte command
	op code
	argument byte = 3 bits for port #, have lots of room for other
things, possibly a code for system status request?
 	
2 byte response
        waiting data size for requested port..  if max buf is 1024, 6
bits left for RI, DCD, CTS, mode (data/interactive), etc
 	
? 	system status
 	0, seven bits for which ports are initialized
 	1, seven bits for port mode (data/interactive)
 	

The driver can now take appropriate action, often to call SERREADM if
the port is in data mode.  This scheme does add an extra exchange
between client/server for each block read.  not sure if this matters,
some of the bytes are unavoidable although in a single port design the
second exchange could be eliminated.


SERSETSTAT - Open, close, change mode of a port

2 byte command
	op code
	5 bits
		mode (interactive/stream)
		RTS/CTS
		DCD/DSR
		etc
	3 bits port selector, 7 = all?
	
1 byte response = echo arg byte back = confirmation, some
unlikely/impossible set of bits + remaining could indicate failure and
reason
setting the port to its exact current status could indicate a termination

Finally, SERREADM's arguments have to be extended to accomodate values
larger than 255 anyway, so the extra 3 bits for port select cost
nothing.

SERREADM
2   byte command
	opcode
	3 bits port #, msb,lsb amount (max 1024)
	
	response = data bytes
	


Well, that's my idea for now..
-Aaron

From goosey at virgo.sdc.org  Sun Nov 15 05:43:03 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Sun, 15 Nov 2009 03:43:03 -0700
Subject: [Coco] curses update
Message-ID: <20091115104303.GA3570@virgo.sdc.org>

New release of curses.l

http://www.sdc.org/~goosey/os9/curses04.lzh

In this release, all the functions that take a WINDOW * arguement
check to make sure that it's non-null.

The original MS-DOS code used NULL to mean stdscr!  Some of the
functions checked for this case... but some didn't.  (And DDJ actually
published this code?  Scary.)

Anyway, I've hacked at it, and now that stdscr is a proper WINDOW *,
there is no excuse to pass a NULL pointer as the window pointer.  

Since some of the functions treat NULL as stdscr, I followed this
convention.  Any function that takes a WINDOW * argument will silently
use stdscr if passed NULL.  

This behavior is non-standard, but I think it's far more likely that
code will be ported to this particular curses, rather than from this
curses to another.

Other major issues with this code:  printw() is still broken.
wprintw() works though.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From johnadonaldson at sbcglobal.net  Sun Nov 15 11:20:50 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Sun, 15 Nov 2009 10:20:50 -0600
Subject: [Coco] curses update
In-Reply-To: <20091115104303.GA3570@virgo.sdc.org>
References: <20091115104303.GA3570@virgo.sdc.org>
Message-ID: <4B002A62.9010209@sbcglobal.net>

Willard,
    The link doesn't work.

John Donaldson


Willard Goosey wrote:
> New release of curses.l
>
> http://www.sdc.org/~goosey/os9/curses04.lzh
>
> In this release, all the functions that take a WINDOW * arguement
> check to make sure that it's non-null.
>
> The original MS-DOS code used NULL to mean stdscr!  Some of the
> functions checked for this case... but some didn't.  (And DDJ actually
> published this code?  Scary.)
>
> Anyway, I've hacked at it, and now that stdscr is a proper WINDOW *,
> there is no excuse to pass a NULL pointer as the window pointer.  
>
> Since some of the functions treat NULL as stdscr, I followed this
> convention.  Any function that takes a WINDOW * argument will silently
> use stdscr if passed NULL.  
>
> This behavior is non-standard, but I think it's far more likely that
> code will be ported to this particular curses, rather than from this
> curses to another.
>
> Other major issues with this code:  printw() is still broken.
> wprintw() works though.
>
> Willard
>   


-- 

From brucewcalkins at charter.net  Sun Nov 15 12:13:37 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Sun, 15 Nov 2009 12:13:37 -0500
Subject: [Coco] curses update
References: <20091115104303.GA3570@virgo.sdc.org>
	<4B002A62.9010209@sbcglobal.net>
Message-ID: <3593C4C7AC8E46C6A237E8A601855FC8@speedy>

It worked early this morning.
I sent John a copy
Bruce W.


----- Original Message ----- 
From: "John Donaldson" 
>    The link doesn't work.
> 
> John Donaldson
> 
> 
> Willard Goosey wrote:
>> New release of curses.l
>>
>> http://www.sdc.org/~goosey/os9/curses04.lzh

From operator at coco3.com  Sun Nov 15 12:23:24 2009
From: operator at coco3.com (Roger Taylor)
Date: Sun, 15 Nov 2009 11:23:24 -0600
Subject: [Coco] CoCoNet before Xmas
Message-ID: <6.2.5.6.1.20091115112247.05a72928@coco3.com>

Greetings all!

The work has been intense, the hours long, and the EPROM 
eraser/burner working overtime in my tests.

CoCoNet 1.0 is about a week from being finalized and released.

CoCoNet is a Disk BASIC 1.1 ROM replacement and is compatible with 
any CoCo 3 or CoCo 1/2 with Extended BASIC.

The 16K EPROM will fit in both my Deluxe Wireless RS-232 Pak and the 
new Drive Pak, or EPROM Pak.  You just need to get the EPROM booted 
somehow and you're set.
The least thing you'd need is a bitbanger cable and an EPROM pak/board.

Just a few things you could do using CoCoNet:
- Auto-boot into a Drive Pak, PC or web OS-9 system
- Remote virtual floppy disks over bitbanger cable, RS-232 Pak, or 
bluetooth (Deluxe Wireless Pak)
- MicroSD (Drive Pak) virtual disks, 1GB of storage any way you like
- Huge OS-9 "hard drives" on the Drive Pak or via remote PC/web
- Automatically run AUTOBOOT.BAS from Drive 0 on CoCo powerup, from 
the Drive Pak, PC or web!!
	From AUTOBOOT.BAS, you can make the program boot up OS-9 or whatever 
you want, even launch a live web service.
- Grab web files and save them to a mounted remote disk using one 
Disk BASIC command
	(a front-end HTTP GET command)
- Web services on power-up of the CoCo (wireless, wired, bitbanger)

Real 1793 controller disks
2GB MicroSD card (Drive Pak) disks (0-255) per partition, with 
virtually unlimited partitions and disks!
Bitbanger port disks using the CoCoNet server on your PC and a serial cable
Tandy RS-232 Pak + cable, or Deluxe Wireless RS-232 Pak remote disks 
over bluetooth
  (CoCoNet can mount remote PC or web disks!)

All disks are compatible with the standard Disk BASIC 1.1 set of 
commands.  In other words:
BACKUP, COPY, KILL, RENAME, SAVE, LOAD, OPEN, CLOSE, PUT, GET, etc. 
between all disks types.
(But you can't write to web disks).

On startup, CoCoNet automatically mounts each drive type for 0-3 in 
an order of importance based on the devices you have plugged 
in.  From BASIC you can remount the drives.
You can do this from the autoboot.bas program, for example.

Folks, all sorts of things are possible, and the CoCoNet "ROM" can be 
booted from whatever device you own that accepts a 27128 EPROM.
You just have to use your imagination, like when you're looking at a 
set of BASIC commands and ask somebody, "what can I do with 
that?".  Pretty much everything.


 From DOS you can mount the different disk types in any order and see 
the current mounts using the enhanced DRIVE command.
For example, typing DRIVE with no parameters would give a listing such as:
 >DRIVE [ENTER]

DRIVE 0: UDRIVE DISK 000
DRIVE 1: ACIA
DRIVE 2: BITBANGER
DRIVE 3: 1793

 >DRIVE 0,#254 [ENTER] (change to MicroDrive disk #254 - NitrOS-9 Level II)
 >DRIVE [ENTER]

DRIVE 0: UDRIVE DISK 254
DRIVE 1: ACIA
DRIVE 2: BITBANGER
DRIVE 3: 1793

DOS  (boots into NitrOS-9)

By the way, my AUTOBOOT.BAS program checks what type of CoCo is in 
use and boots OS-9 Level 1 or 2 automatically.  This means, you can 
take a Drive Pak and stick it in almost any CoCo and boot into "OS-9" 
right on power-up.

On powerup, once the drive types have been chosen and mounted for 
0-3, each drive will be scanned for an AUTOBOOT.BAS program, with the 
first one found being RUN automatically.
You could have an AUTOBOOT program on your PC, the web, the Drive 
Pak, and real disk drive.  It doesn't have to be the same program code.

Telnet is also handled by the CoCoNet server and using the right CoCo 
client software, you could connect to a remote Telnet server from 
BASIC or OS-9.
Again, if you can auto boot, it means you can do anything CoCoNet can 
do right after power-up.

-- 
~ Roger Taylor



From aawolfe at gmail.com  Sun Nov 15 13:55:31 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sun, 15 Nov 2009 13:55:31 -0500
Subject: [Coco] questions about sharing memory amongst device drivers in os-9
Message-ID: <e44ad6640911151055h285dd699rf2d5fcb30dcff011@mail.gmail.com>

Hi,

I've updated the server code and drivewire nitros-9 drivers to allow
up to seven "virtual" serial ports over the bitbanger.  Each virtual
port is terminated on the host in its own PTY.

In order to do this, I created additional device descriptors with
different V.PORT values but pointing to the same scwdt driver. I use
the port in calls to the driver to distinguish between them.

Everything works fine for writes, since these do not require any
coordination between devices.  I can simultaneously list out multiple
files on the coco to separate windows/session on my PC, no problem.
Drivewire really is fast!

However, for incoming data I have an issue that I could use some
guidance with.  Each device creates its own memory area.  The first
device to use the scwdt driver shares it's area with the driver, so
they can see the same memory, where the input buffers, status flags
etc are.  I can run a shell on the first port I iniz, whichever port
that might be, and everything's great.

The second third etc ports are getting their own separate device
memory area, I guess this makes sense in a real world device where
they would have separate interrupt handlers.  But in this project, I
need to use a single interrupt handler to feed multiple "devices".

Here's an example of what I mean, T1 and T2 have different static mem
areas, but both use scdwt.  Since T1 has the same addr (6000) as the
IRQ handler, it can do writes.  T2 can only do reads:

{T1|03}/DD:devs

Device Table at: 6D00

Device Desc  Driver Static  File    Usr
Name   Port  Name      Mem  Manager Cnt
-----------  -------------  ------- ---
DD   070000  rbdw3    6B00  RBF      05
Term 07FFA0  VTIO     6A00  SCF      04
T1   07FF01  scdwt    6000  SCF      03
T2   07EE02  scdwt    5E00  SCF      01

{T1|03}/DD:irqs

Polling Table at: 6EFB
 Device Table at: 6D00

 Device    Driver  IRQ   Flip
Port Mem   Name  Vector  &Mask Pty
---- ----  ------------  ----- ---
60B4 6000  scdwt   E5C6  00 01  0A


All I really need is some shared memory or other means to get bytes
into each device's buffer from the central interrupt handler, or let
the devices come get the data from a central set of buffers,
whichever.. and then the ISR needs to know the process IDs (V.BUSYs
basically) of each device so it can send the wake signal.   Actually I
have the signal handler written already but no way to get the PIDs
into it's table.

Is there a standard os-9 way to do such a thing?  Am I missing
something that would make this simpler? I've studied the os9 terch ref
and everything else I can find but nothing has become obvious to me
yet.  Any advice is much appreciated.
-Aaron

From goosey at virgo.sdc.org  Sun Nov 15 16:02:36 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Sun, 15 Nov 2009 14:02:36 -0700
Subject: [Coco] curses update
In-Reply-To: <3593C4C7AC8E46C6A237E8A601855FC8@speedy>
References: <20091115104303.GA3570@virgo.sdc.org>
	<4B002A62.9010209@sbcglobal.net>
	<3593C4C7AC8E46C6A237E8A601855FC8@speedy>
Message-ID: <20091115210236.GA9134@virgo.sdc.org>

On Sun, Nov 15, 2009 at 12:13:37PM -0500, Bruce W. Calkins wrote:
> It worked early this morning.
> I sent John a copy
> Bruce W.
> 
> 
> ----- Original Message ----- 
> From: "John Donaldson" 
> >   The link doesn't work.
> >
> >John Donaldson
> >
> >
> >Willard Goosey wrote:
> >>New release of curses.l
> >>
> >>http://www.sdc.org/~goosey/os9/curses04.lzh

Weird.  It works for me from my isp and from sdf.  

Thanks for sending him a copy.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From baar_bear at cox.net  Sat Nov 14 21:51:12 2009
From: baar_bear at cox.net (Baar)
Date: Sun, 15 Nov 2009 02:51:12 -0000
Subject: [Coco] [Color Computer] Hello
Message-ID: <hdnqb0+31c5@eGroups.com>

      Hello and greetings. My name is Michael and I'm a new member of your group.  I was a Cocoholic way back in the day. Got my CoCo II as Christmas present in 1985 and upgraded to CoCo III at Christmas 1987-this I used until I got my first PC for Christmas 1995.  
    
      My CoCos are long gone but they served me well.  Tandy gave me the computer, but it was Lonnie Falk (RIP!) and the Rainbow Magazine (also RIP!) that showed me what my lowly "Trash 80" could do-and I could do quite a bit with it.  Used it for schoolwork and spent many happy hours programming it in BASIC and ML and accessing BBSes through my modem (it was mind blowing to me back in the day when my lowly CoCo could connect and communicate with my college's powerful VAX mainframe).  

       That's it about my history. Thanks for having me aboard. 


From goosey at virgo.sdc.org  Sun Nov 15 16:05:51 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Sun, 15 Nov 2009 14:05:51 -0700
Subject: [Coco] curses update
In-Reply-To: <4B002A62.9010209@sbcglobal.net>
References: <20091115104303.GA3570@virgo.sdc.org>
	<4B002A62.9010209@sbcglobal.net>
Message-ID: <20091115210551.GB9134@virgo.sdc.org>

On Sun, Nov 15, 2009 at 10:20:50AM -0600, John Donaldson wrote:
> Willard,
>    The link doesn't work.

Huh, that's weird.  Doesn't work how?  File not found? Site not found?
No Permission?  What?

It might have been a net.fart.

Please try again and let me know.
http://www.sdc.org/~goosey/os9/curses04.lzh

> John Donaldson

Thanks
Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From boisy at tee-boy.com  Sun Nov 15 17:25:18 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Sun, 15 Nov 2009 16:25:18 -0600
Subject: [Coco] questions about sharing memory amongst device drivers in
	os-9
In-Reply-To: <e44ad6640911151055h285dd699rf2d5fcb30dcff011@mail.gmail.com>
References: <e44ad6640911151055h285dd699rf2d5fcb30dcff011@mail.gmail.com>
Message-ID: <7ACAFD40-8FC4-464C-A532-C34B393B1DE9@tee-boy.com>

Aaron,

Although I didn't comment on your earlier RFC, I think everything looked fine.

As for the current issue: the behavior you are getting is expected in that since the V.PORT is different, IOMan is assigning separate static storage areas for each device.

If you want to share memory between devices, you have several options:

1. Use a data module.  A data module is simply an OS-9 module with empty space allocated.  It would need to be included in the bootfile and linked by the driver using it at init time, and a reference to the data module's entry point could be stored in the driver's static storage. Since the data module would reside in system RAM, the driver would have direct access to it and could use that space to share information between other instances of the driver.

2. Use the System Direct Page Vars.  If you look in os9defs, you'll see that low memory from $00 to $20 is reserved for Direct Page vars that the user can define.  There are some there already, and if you only need one or two bytes, it might be easier just to reserve some space from there for your driver to use.

How much space are you needing to share between each device?

Boisy

On Nov 15, 2009, at 12:55 PM, Aaron Wolfe wrote:

> Hi,
> 
> I've updated the server code and drivewire nitros-9 drivers to allow
> up to seven "virtual" serial ports over the bitbanger.  Each virtual
> port is terminated on the host in its own PTY.
> 
> In order to do this, I created additional device descriptors with
> different V.PORT values but pointing to the same scwdt driver. I use
> the port in calls to the driver to distinguish between them.
> 
> Everything works fine for writes, since these do not require any
> coordination between devices.  I can simultaneously list out multiple
> files on the coco to separate windows/session on my PC, no problem.
> Drivewire really is fast!
> 
> However, for incoming data I have an issue that I could use some
> guidance with.  Each device creates its own memory area.  The first
> device to use the scwdt driver shares it's area with the driver, so
> they can see the same memory, where the input buffers, status flags
> etc are.  I can run a shell on the first port I iniz, whichever port
> that might be, and everything's great.
> 
> The second third etc ports are getting their own separate device
> memory area, I guess this makes sense in a real world device where
> they would have separate interrupt handlers.  But in this project, I
> need to use a single interrupt handler to feed multiple "devices".
> 
> Here's an example of what I mean, T1 and T2 have different static mem
> areas, but both use scdwt.  Since T1 has the same addr (6000) as the
> IRQ handler, it can do writes.  T2 can only do reads:
> 
> {T1|03}/DD:devs
> 
> Device Table at: 6D00
> 
> Device Desc  Driver Static  File    Usr
> Name   Port  Name      Mem  Manager Cnt
> -----------  -------------  ------- ---
> DD   070000  rbdw3    6B00  RBF      05
> Term 07FFA0  VTIO     6A00  SCF      04
> T1   07FF01  scdwt    6000  SCF      03
> T2   07EE02  scdwt    5E00  SCF      01
> 
> {T1|03}/DD:irqs
> 
> Polling Table at: 6EFB
> Device Table at: 6D00
> 
> Device    Driver  IRQ   Flip
> Port Mem   Name  Vector  &Mask Pty
> ---- ----  ------------  ----- ---
> 60B4 6000  scdwt   E5C6  00 01  0A
> 
> 
> All I really need is some shared memory or other means to get bytes
> into each device's buffer from the central interrupt handler, or let
> the devices come get the data from a central set of buffers,
> whichever.. and then the ISR needs to know the process IDs (V.BUSYs
> basically) of each device so it can send the wake signal.   Actually I
> have the signal handler written already but no way to get the PIDs
> into it's table.
> 
> Is there a standard os-9 way to do such a thing?  Am I missing
> something that would make this simpler? I've studied the os9 terch ref
> and everything else I can find but nothing has become obvious to me
> yet.  Any advice is much appreciated.
> -Aaron
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Boisy G. Pitre
http://www.tee-boy.com/


From os9dude at gmail.com  Sun Nov 15 18:52:54 2009
From: os9dude at gmail.com (Rogelio Perea)
Date: Sun, 15 Nov 2009 18:52:54 -0500
Subject: [Coco] [Color Computer] Hello
In-Reply-To: <hdnqb0+31c5@eGroups.com>
References: <hdnqb0+31c5@eGroups.com>
Message-ID: <5631e580911151552s1b88da3dha142cae85bad9423@mail.gmail.com>

Welcome!

By all means feel free to join in the discussions, we have all from
beginners to really high tech exchanges here :-)


-- Rogelio


On Sat, Nov 14, 2009 at 9:51 PM, Baar <baar_bear at cox.net> wrote:

>      Hello and greetings. My name is Michael and I'm a new member of your
> group.  I was a Cocoholic way back in the day. Got my CoCo II as Christmas
> present in 1985 and upgraded to CoCo III at Christmas 1987-this I used until
> I got my first PC for Christmas 1995.
>
>      My CoCos are long gone but they served me well.  Tandy gave me the
> computer, but it was Lonnie Falk (RIP!) and the Rainbow Magazine (also RIP!)
> that showed me what my lowly "Trash 80" could do-and I could do quite a bit
> with it.  Used it for schoolwork and spent many happy hours programming it
> in BASIC and ML and accessing BBSes through my modem (it was mind blowing to
> me back in the day when my lowly CoCo could connect and communicate with my
> college's powerful VAX mainframe).
>
>       That's it about my history. Thanks for having me aboard.
>
>

From operator at coco3.com  Sun Nov 15 14:32:38 2009
From: operator at coco3.com (Roger Taylor)
Date: Sun, 15 Nov 2009 13:32:38 -0600
Subject: [Coco] CoCoNet status
In-Reply-To: <e44ad6640911131638q433fc601n6f726f290c62e019@mail.gmail.co
 m>
References: <4AFB5EE0.1000809@att.net>
	<6.2.5.6.1.20091112211808.06177388@coco3.com>
	<e44ad6640911131638q433fc601n6f726f290c62e019@mail.gmail.com>
Message-ID: <6.2.5.6.1.20091115131256.061ef608@coco3.com>

At 06:38 PM 11/13/2009, you wrote:
> > The CoCoNet server behaves like a modem.  You can send AT commands to it to
> > do everything, including Telnet, but that requires a terminal program, as
> > CoCoNet doesn't deal with Telnet.
> >

I meant to say that the CoCoNet client (the CoCo ROM) doesn't have 
any *direct* Telnet support, but the server does which means you can 
use a terminal program and login to a Telnet site by sending ATDT and 
the IP address or URL.  A bare bones terminal program will be in the 
CoCoNet ROM before the week is up, and is absolutely necessary if no 
other software can be loaded on the CoCo.  For example: fire up with 
a wireless pak, type a BASIC command, up pops a terminal program 
where you can talk to the bluetooth module using English commands to 
change it's settings for future boots.



>Does CoCoNet create a virtual serial port on windows, or PTY in
>linux/mac os x?  If so, I'd be happy to make every attempt to support
>it in my serial -> tcpip project for drivewire.  Also I'm considering
>a full screen terminal application tailored to CoCo/OS9 use, I'd love
>to be able to support CoCoNet in addition to DriveWire.   Maybe most
>importantly, is CoCoNet free (as in freedom) software?

The CoCoNet server doesn't create any serial ports, but you can 
choose COM 0-255.  You can also run different copies of the server, 
each one opening it's own serial port.  For wireless use, the port 
needs to be the Incoming port assigned to the paired connection 
between the PC and CoCo, so the CoCo can connect automatically on 
power-up.  However, the CoCo looks for the first available bluetooth 
connection and connects to it, assuming it's the CoCoNet server.


-- 
~ Roger Taylor



From dml_68 at yahoo.com  Sun Nov 15 21:41:55 2009
From: dml_68 at yahoo.com (Derek)
Date: Sun, 15 Nov 2009 18:41:55 -0800 (PST)
Subject: [Coco] [Color Computer] Hello
In-Reply-To: <hdnqb0+31c5@eGroups.com>
Message-ID: <361849.11408.qm@web30208.mail.mud.yahoo.com>

Welcome! Be sure to check out www.coco3.com. Best coco web page there is!



** Mistrust Authority. Promote Decentralization **


 

--- On Sat, 11/14/09, Baar <baar_bear at cox.net> wrote:

From: Baar <baar_bear at cox.net>
Subject: [Color Computer] Hello
To: ColorComputer at yahoogroups.com
Date: Saturday, November 14, 2009, 6:51 PM

? ? ? Hello and greetings. My name is Michael and I'm a new member of your group.? I was a Cocoholic way back in the day. Got my CoCo II as Christmas present in 1985 and upgraded to CoCo III at Christmas 1987-this I used until I got my first PC for Christmas 1995.? 
? ? 
? ? ? My CoCos are long gone but they served me well.? Tandy gave me the computer, but it was Lonnie Falk (RIP!) and the Rainbow Magazine (also RIP!) that showed me what my lowly "Trash 80" could do-and I could do quite a bit with it.? Used it for schoolwork and spent many happy hours programming it in BASIC and ML and accessing BBSes through my modem (it was mind blowing to me back in the day when my lowly CoCo could connect and communicate with my college's powerful VAX mainframe).? 

? ? ???That's it about my history. Thanks for having me aboard. 



------------------------------------

Brought to you by the 6809, the 6803 and their cousins!Yahoo! Groups Links






      

From aawolfe at gmail.com  Mon Nov 16 04:03:04 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 04:03:04 -0500
Subject: [Coco] questions about sharing memory amongst device drivers in
	os-9
In-Reply-To: <7ACAFD40-8FC4-464C-A532-C34B393B1DE9@tee-boy.com>
References: <e44ad6640911151055h285dd699rf2d5fcb30dcff011@mail.gmail.com>
	<7ACAFD40-8FC4-464C-A532-C34B393B1DE9@tee-boy.com>
Message-ID: <e44ad6640911160103m28293876gb6e2bdca945a0820@mail.gmail.com>

Thanks Boisy,

I believe 2 bytes would let me have the "first man in" set a pointer
for the rest of the devices to find him.
Now I see where D.DWSUB comes from :)  I'll see if it's new neighbor
D.DWTAdr can solve my problem.
I've been using a data module for debugging, but I don't think I need
anything that big in production code.  All the instances know the
offset they should be using inside the primary's memory space by
looking at their port, so a pointer in should do it, we will see.

-Aaron


On Sun, Nov 15, 2009 at 5:25 PM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Aaron,
>
> Although I didn't comment on your earlier RFC, I think everything looked fine.
>
> As for the current issue: the behavior you are getting is expected in that since the V.PORT is different, IOMan is assigning separate static storage areas for each device.
>
> If you want to share memory between devices, you have several options:
>
> 1. Use a data module. ?A data module is simply an OS-9 module with empty space allocated. ?It would need to be included in the bootfile and linked by the driver using it at init time, and a reference to the data module's entry point could be stored in the driver's static storage. Since the data module would reside in system RAM, the driver would have direct access to it and could use that space to share information between other instances of the driver.
>
> 2. Use the System Direct Page Vars. ?If you look in os9defs, you'll see that low memory from $00 to $20 is reserved for Direct Page vars that the user can define. ?There are some there already, and if you only need one or two bytes, it might be easier just to reserve some space from there for your driver to use.
>
> How much space are you needing to share between each device?
>
> Boisy
>
> On Nov 15, 2009, at 12:55 PM, Aaron Wolfe wrote:
>
>> Hi,
>>
>> I've updated the server code and drivewire nitros-9 drivers to allow
>> up to seven "virtual" serial ports over the bitbanger. ?Each virtual
>> port is terminated on the host in its own PTY.
>>
>> In order to do this, I created additional device descriptors with
>> different V.PORT values but pointing to the same scwdt driver. I use
>> the port in calls to the driver to distinguish between them.
>>
>> Everything works fine for writes, since these do not require any
>> coordination between devices. ?I can simultaneously list out multiple
>> files on the coco to separate windows/session on my PC, no problem.
>> Drivewire really is fast!
>>
>> However, for incoming data I have an issue that I could use some
>> guidance with. ?Each device creates its own memory area. ?The first
>> device to use the scwdt driver shares it's area with the driver, so
>> they can see the same memory, where the input buffers, status flags
>> etc are. ?I can run a shell on the first port I iniz, whichever port
>> that might be, and everything's great.
>>
>> The second third etc ports are getting their own separate device
>> memory area, I guess this makes sense in a real world device where
>> they would have separate interrupt handlers. ?But in this project, I
>> need to use a single interrupt handler to feed multiple "devices".
>>
>> Here's an example of what I mean, T1 and T2 have different static mem
>> areas, but both use scdwt. ?Since T1 has the same addr (6000) as the
>> IRQ handler, it can do writes. ?T2 can only do reads:
>>
>> {T1|03}/DD:devs
>>
>> Device Table at: 6D00
>>
>> Device Desc ?Driver Static ?File ? ?Usr
>> Name ? Port ?Name ? ? ?Mem ?Manager Cnt
>> ----------- ?------------- ?------- ---
>> DD ? 070000 ?rbdw3 ? ?6B00 ?RBF ? ? ?05
>> Term 07FFA0 ?VTIO ? ? 6A00 ?SCF ? ? ?04
>> T1 ? 07FF01 ?scdwt ? ?6000 ?SCF ? ? ?03
>> T2 ? 07EE02 ?scdwt ? ?5E00 ?SCF ? ? ?01
>>
>> {T1|03}/DD:irqs
>>
>> Polling Table at: 6EFB
>> Device Table at: 6D00
>>
>> Device ? ?Driver ?IRQ ? Flip
>> Port Mem ? Name ?Vector ?&Mask Pty
>> ---- ---- ?------------ ?----- ---
>> 60B4 6000 ?scdwt ? E5C6 ?00 01 ?0A
>>
>>
>> All I really need is some shared memory or other means to get bytes
>> into each device's buffer from the central interrupt handler, or let
>> the devices come get the data from a central set of buffers,
>> whichever.. and then the ISR needs to know the process IDs (V.BUSYs
>> basically) of each device so it can send the wake signal. ? Actually I
>> have the signal handler written already but no way to get the PIDs
>> into it's table.
>>
>> Is there a standard os-9 way to do such a thing? ?Am I missing
>> something that would make this simpler? I've studied the os9 terch ref
>> and everything else I can find but nothing has become obvious to me
>> yet. ?Any advice is much appreciated.
>> -Aaron
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From goosey at virgo.sdc.org  Mon Nov 16 05:30:26 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Mon, 16 Nov 2009 03:30:26 -0700
Subject: [Coco] no curses update tonight
Message-ID: <20091116103024.GA4604@virgo.sdc.org>

No curses update tonight.

I spent some time tracking down some docs on the web about varargs,
and finally found one that described my exact difficultly.

When I went to print out a copy, my printer revealed its true
Decepticon spark, and suddenly began refusing to print anything.

I hate printers.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From aawolfe at gmail.com  Mon Nov 16 06:27:18 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 06:27:18 -0500
Subject: [Coco] DriveWire virtual serial ports - multiball success (2)
Message-ID: <e44ad6640911160327p79735fdbi4c65d90b156f40e2@mail.gmail.com>

It works!  I have /T1 - /T4 talking with four different PTYs on my
linux box.   Thanks for the tip about system DP vars Boisy.

They say a picture is worth 1000 words.. so I attached one, hope it
comes through. <-- It didn't.
Otherwise I'll post on my project page, http://aaronwolfe.com/coco

Now that proof of concept is done, I seriously have to clean up the
driver and server side code for efficiency.  still need to add
signaling and status things, right now it's the bare minimum
implementation of my spec required to see it in action.  As I tried to
implement the changes I proposed in my RFC, I found some things worked
better laid out a bit differently.  Also, I think it's going to be
better to move the logic for traffic prioritization out into the
server.  I want the driver to be small and efficient as possible.

Apologies to anyone who's tried to use the code on my web page.  I let
things get out of sync and some combinations of the code there will
not work with each other, as Mr. Furman let me know yesterday.  This
will be sorted out today.

Revised spec 11/16/09:


SERREAD  (this is the poller, occurs 10 times per second currently but
can certainly change)

 1 byte command (just the opcode)

 2 byte response:

  byte 1:
     first 2 bits: type of reply
             00 - normal serread response, either nothing waiting or
a single byte for port specified in lowest 3 bytes
             01 - status change for port, new status is data byte
             10 - unused
             11 - multiread request - see below

     third bit - 1 = server would like driver to send another SERREAD
immediately after processing this one.  driver is not required to do
this
     bits 4,5 = MSB of data waiting on server in a multiread req..
kind of clumsy having them in the middle but it fits.
     bits 6,7,8 = port number

  byte 2:  type 00 - data byte for port
              type 01 - status byte for port
              type 11 - LSB of data waiting on server

The major change here is that the SERREAD response only tells the
driver about one port instead of all of them.  This means the logic
for which port gets attention by the driver about is completely done
in the server.  It eliminates the extra exchange of a GETSTAT during
multi reads, which I really did not like.  Since many times we'd be
using only 1 port, and would want that port to be as fast as possible,
I think this is a better design.

The multiread request tells the driver how much data is waiting for
the port, but does not provide a byte in the reply.  It takes the
logic of when to do a SERREADM away from the os-9 driver and puts the
decision solely in the server code.  I think this is a better place
for it, as the server knows the rate data is actually coming in, knows
about whats happening on all the various ports, etc.  Since I pass
very little data between port handlers on the os9 side, they don't
easily have a view into this.


SERGETSTAT - inquire port status,
2 byte command
      op code
      argument byte = 3 bits for port #, have lots of room for other
things, possibly a code for system status request?

2 byte response
      waiting data size for requested port..  if max buf is 1024, 6
bits left for RI, DCD, CTS, mode (data/interactive), etc

?       system status
      0, seven bits for which ports are initialized
      1, seven bits for port mode (data/interactive)


SERSETSTAT - Open, close, change mode of a port

2 byte command
      op code
      5 bits
              mode (interactive/stream)
              RTS/CTS
              DCD/DSR
              etc
      3 bits port selector, 7 = all?

1 byte response = echo arg byte back = confirmation, some
unlikely/impossible set of bits + remaining could indicate failure and
reason
setting the port to its exact current status could indicate a termination

Finally, SERREADM's arguments have to be extended to accomodate values
larger than 255 anyway, so the extra 3 bits for port select cost
nothing.

SERREADM
3 byte command
      opcode
      3 bits port #, msb,lsb amount (max 1024 due to limits in SERREAD)

      response = X data bytes

From aawolfe at gmail.com  Mon Nov 16 07:14:44 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 07:14:44 -0500
Subject: [Coco] CoCoNet status
In-Reply-To: <6.2.5.6.1.20091115131256.061ef608@coco3.com>
References: <4AFB5EE0.1000809@att.net>
	<6.2.5.6.1.20091112211808.06177388@coco3.com>
	<e44ad6640911131638q433fc601n6f726f290c62e019@mail.gmail.com>
	<6.2.5.6.1.20091115131256.061ef608@coco3.com>
Message-ID: <e44ad6640911160414r9a74a1bg53facbbc32d8fe13@mail.gmail.com>

On Sun, Nov 15, 2009 at 2:32 PM, Roger Taylor <operator at coco3.com> wrote:
> At 06:38 PM 11/13/2009, you wrote:
>>
>> > The CoCoNet server behaves like a modem. ?You can send AT commands to it
>> > to
>> > do everything, including Telnet, but that requires a terminal program,
>> > as
>> > CoCoNet doesn't deal with Telnet.
>> >
>
> I meant to say that the CoCoNet client (the CoCo ROM) doesn't have any
> *direct* Telnet support, but the server does which means you can use a
> terminal program and login to a Telnet site by sending ATDT and the IP
> address or URL. ?A bare bones terminal program will be in the CoCoNet ROM
> before the week is up, and is absolutely necessary if no other software can
> be loaded on the CoCo. ?For example: fire up with a wireless pak, type a
> BASIC command, up pops a terminal program where you can talk to the
> bluetooth module using English commands to change it's settings for future
> boots.
>
>
>
>> Does CoCoNet create a virtual serial port on windows, or PTY in
>> linux/mac os x? ?If so, I'd be happy to make every attempt to support
>> it in my serial -> tcpip project for drivewire. ?Also I'm considering
>> a full screen terminal application tailored to CoCo/OS9 use, I'd love
>> to be able to support CoCoNet in addition to DriveWire. ? Maybe most
>> importantly, is CoCoNet free (as in freedom) software?
>
> The CoCoNet server doesn't create any serial ports, but you can choose COM
> 0-255. ?You can also run different copies of the server, each one opening
> it's own serial port. ?For wireless use, the port needs to be the Incoming
> port assigned to the paired connection between the PC and CoCo, so the CoCo
> can connect automatically on power-up. ?However, the CoCo looks for the
> first available bluetooth connection and connects to it, assuming it's the
> CoCoNet server.
>

Ok, I think I understand you are saying I could use the bit banger or
your rs232/bluetooth module to connect to any COM port on the host,
which is how it talks to the server running there?

I think I was too wrapped up in my own project to clearly ask the
question that I meant to ask  :)

What I was wondering was if CoCoNet then provided access to that same
serial device to other programs, if that makes sense.  For instance,
is there a way to boot os9 over the bitbanger that is connected to the
CoConet server software, and then use that same bitbanger as a regular
OS9 device to provide a shell to the host?

The reason this is important to me is that I'd like to use remote
terminals, tcpip/modem things, etc but I have only a CoCo with a
bitbanger.. no MPI or rs232.  I need my one cart slot for the
DriveWire rom.

So this "serial device pass through" is what I'm working on for
drivewire.  Basically you can use the bitbanger for your drives, and
still use it as a serial port (under OS9 at least).  Actually now you
can use it as 7 serial ports.  There have been some challenges, mostly
my own lack of experience, but I've managed to get it working pretty
well.  I thought that if you had done/were doing the same thing then
maybe we were solving some of the same issues.  Maybe we are?  I'm
always happy to share my work or collaborate if its of use to your
project.

Is the server software open/free?  I don't mean free of charge, I know
you sell your products and I fully  respect that.  I mean if someone
buys CoCoNet, do they get the source?

Also, what platforms does the CoCoNet server run on?  linux I hope? :)

-Aaron

>
> --
> ~ Roger Taylor
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From rcrislip at neo.rr.com  Mon Nov 16 09:04:32 2009
From: rcrislip at neo.rr.com (richec)
Date: Mon, 16 Nov 2009 09:04:32 -0500
Subject: [Coco] curses update
In-Reply-To: <20091115104303.GA3570@virgo.sdc.org>
References: <20091115104303.GA3570@virgo.sdc.org>
Message-ID: <200911160904.32169.rcrislip@neo.rr.com>

< S N I P !  8-) >

Hi Willard,

Forgive my ignorance, are you working on a untility called curses or a game? 
TIA. I am asking because I am trying to figure out how to classify this thread 
in my archives.

From aawolfe at gmail.com  Mon Nov 16 09:45:34 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 09:45:34 -0500
Subject: [Coco] curses update
In-Reply-To: <200911160904.32169.rcrislip@neo.rr.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911160904.32169.rcrislip@neo.rr.com>
Message-ID: <e44ad6640911160645u2960bd1bobf6566bc95b54517@mail.gmail.com>

>From http://en.wikipedia.org/wiki/Ncurses

ncurses is a programming library providing an API, allowing the
programmer to write text user interfaces in a terminal-independent
manner. It's a toolkit for developing "GUI-like" apps which run under
a terminal emulator. It also optimizes screen changes, in order to
reduce the latency experienced when using remote shells.


On Mon, Nov 16, 2009 at 9:04 AM, richec <rcrislip at neo.rr.com> wrote:
>
> < S N I P ! ?8-) >
>
> Hi Willard,
>
> Forgive my ignorance, are you working on a untility called curses or a game?
> TIA. I am asking because I am trying to figure out how to classify this thread
> in my archives.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

From johnadonaldson at sbcglobal.net  Mon Nov 16 09:51:23 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Mon, 16 Nov 2009 08:51:23 -0600
Subject: [Coco] curses update
In-Reply-To: <20091115210236.GA9134@virgo.sdc.org>
References: <20091115104303.GA3570@virgo.sdc.org>	<4B002A62.9010209@sbcglobal.net>	<3593C4C7AC8E46C6A237E8A601855FC8@speedy>
	<20091115210236.GA9134@virgo.sdc.org>
Message-ID: <4B0166EB.2020304@sbcglobal.net>

Willard,
   Must be my system or something. I just now tried the very same link 
and it popped up a msg window where I could enter where I wanted to save 
the file.

John Donaldson




Willard Goosey wrote:
> On Sun, Nov 15, 2009 at 12:13:37PM -0500, Bruce W. Calkins wrote:
>   
>> It worked early this morning.
>> I sent John a copy
>> Bruce W.
>>
>>
>> ----- Original Message ----- 
>> From: "John Donaldson" 
>>     
>>>   The link doesn't work.
>>>
>>> John Donaldson
>>>
>>>
>>> Willard Goosey wrote:
>>>       
>>>> New release of curses.l
>>>>
>>>> http://www.sdc.org/~goosey/os9/curses04.lzh
>>>>         
>
> Weird.  It works for me from my isp and from sdf.  
>
> Thanks for sending him a copy.
>
> Willard
>   


-- 

From rcrislip at neo.rr.com  Mon Nov 16 10:02:36 2009
From: rcrislip at neo.rr.com (richec)
Date: Mon, 16 Nov 2009 10:02:36 -0500
Subject: [Coco] curses update
In-Reply-To: <e44ad6640911160645u2960bd1bobf6566bc95b54517@mail.gmail.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911160904.32169.rcrislip@neo.rr.com>
	<e44ad6640911160645u2960bd1bobf6566bc95b54517@mail.gmail.com>
Message-ID: <200911161002.36765.rcrislip@neo.rr.com>

On Monday 16 November 2009 09:45:34 Aaron Wolfe wrote:
> >From http://en.wikipedia.org/wiki/Ncurses
> 
> ncurses is a programming library providing an API, allowing the
> programmer to write text user interfaces in a terminal-independent
> manner. It's a toolkit for developing "GUI-like" apps which run under
> a terminal emulator. It also optimizes screen changes, in order to
> reduce the latency experienced when using remote shells.
> 
> On Mon, Nov 16, 2009 at 9:04 AM, richec <rcrislip at neo.rr.com> wrote:
> > < S N I P !  8-) >
> >
> > Hi Willard,
> >
> > Forgive my ignorance, are you working on a untility called curses or a
> > game? TIA. I am asking because I am trying to figure out how to classify
> > this thread in my archives.
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
Thanks Aaron,

I have a much better idea of where to file this discussion now. My Programming 
experiences have been limited to CoCo BASIC, IBM mainframe Assembler, COBOL, 
FORTRAN, and a few other languages that are not in much use today <sigh>. 
Although I do have some very limited exposure to C++... I was teaching it 8-O. 
I am NOT a programmer however, which is why I am not familiar with this tool.

Richard

From aawolfe at gmail.com  Mon Nov 16 10:29:20 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 10:29:20 -0500
Subject: [Coco] curses update
In-Reply-To: <200911161002.36765.rcrislip@neo.rr.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911160904.32169.rcrislip@neo.rr.com>
	<e44ad6640911160645u2960bd1bobf6566bc95b54517@mail.gmail.com>
	<200911161002.36765.rcrislip@neo.rr.com>
Message-ID: <e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>

On Mon, Nov 16, 2009 at 10:02 AM, richec <rcrislip at neo.rr.com> wrote:
> On Monday 16 November 2009 09:45:34 Aaron Wolfe wrote:
>> >From http://en.wikipedia.org/wiki/Ncurses
>>
>> ncurses is a programming library providing an API, allowing the
>> programmer to write text user interfaces in a terminal-independent
>> manner. It's a toolkit for developing "GUI-like" apps which run under
>> a terminal emulator. It also optimizes screen changes, in order to
>> reduce the latency experienced when using remote shells.
>>
>> On Mon, Nov 16, 2009 at 9:04 AM, richec <rcrislip at neo.rr.com> wrote:
>> > < S N I P ! ?8-) >
>> >
>> > Hi Willard,
>> >
>> > Forgive my ignorance, are you working on a untility called curses or a
>> > game? TIA. I am asking because I am trying to figure out how to classify
>> > this thread in my archives.
>> >
>> > --
>> > Coco mailing list
>> > Coco at maltedmedia.com
>> > http://five.pairlist.net/mailman/listinfo/coco
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
> Thanks Aaron,
>
> I have a much better idea of where to file this discussion now. My Programming
> experiences have been limited to CoCo BASIC, IBM mainframe Assembler, COBOL,
> FORTRAN, and a few other languages that are not in much use today <sigh>.
> Although I do have some very limited exposure to C++... I was teaching it 8-O.
> I am NOT a programmer however, which is why I am not familiar with this tool.
>

Even as a "non programer" these days, the work to port curses is great
news because a huge amount of software which is freely available in
source form uses this library for it's screen output.  This is a big
step in opening the door to porting that software to os9.  I haven't
had time to play with Mr. Goosey's code yet, but I am very excited to
hear about the progress and plan to start working with it soon.

-Aaron



> Richard
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From rcrislip at neo.rr.com  Mon Nov 16 10:58:04 2009
From: rcrislip at neo.rr.com (richec)
Date: Mon, 16 Nov 2009 10:58:04 -0500
Subject: [Coco] DriveWire virtual serial ports - multiball success (2)
In-Reply-To: <e44ad6640911160327p79735fdbi4c65d90b156f40e2@mail.gmail.com>
References: <e44ad6640911160327p79735fdbi4c65d90b156f40e2@mail.gmail.com>
Message-ID: <200911161058.04955.rcrislip@neo.rr.com>

Hi Aaron,

Congrats on getting it to work. What desktop was that?  Were you running Vista 
in a VM? Cause the desktop sure looked like Linux to me.

Cheers

From rcrislip at neo.rr.com  Mon Nov 16 11:04:04 2009
From: rcrislip at neo.rr.com (richec)
Date: Mon, 16 Nov 2009 11:04:04 -0500
Subject: [Coco] curses update
In-Reply-To: <e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911161002.36765.rcrislip@neo.rr.com>
	<e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
Message-ID: <200911161104.05094.rcrislip@neo.rr.com>

On Monday 16 November 2009 10:29:20 Aaron Wolfe wrote:
> On Mon, Nov 16, 2009 at 10:02 AM, richec <rcrislip at neo.rr.com> wrote:
> > On Monday 16 November 2009 09:45:34 Aaron Wolfe wrote:
> >> >From http://en.wikipedia.org/wiki/Ncurses
> >>
> >> ncurses is a programming library providing an API, allowing the
> >> programmer to write text user interfaces in a terminal-independent
> >> manner. It's a toolkit for developing "GUI-like" apps which run under
> >> a terminal emulator. It also optimizes screen changes, in order to
> >> reduce the latency experienced when using remote shells.
> >>
> >> On Mon, Nov 16, 2009 at 9:04 AM, richec <rcrislip at neo.rr.com> wrote:
> >> > < S N I P !  8-) >
> >> >
> >> > Hi Willard,
> >> >
> >> > Forgive my ignorance, are you working on a untility called curses or a
> >> > game? TIA. I am asking because I am trying to figure out how to
> >> > classify this thread in my archives.
> >> >
> >> > --
> >> > Coco mailing list
> >> > Coco at maltedmedia.com
> >> > http://five.pairlist.net/mailman/listinfo/coco
> >>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> >
> > Thanks Aaron,
> >
> > I have a much better idea of where to file this discussion now. My
> > Programming experiences have been limited to CoCo BASIC, IBM mainframe
> > Assembler, COBOL, FORTRAN, and a few other languages that are not in much
> > use today <sigh>. Although I do have some very limited exposure to C++...
> > I was teaching it 8-O. I am NOT a programmer however, which is why I am
> > not familiar with this tool.
> 
> Even as a "non programer" these days, the work to port curses is great
> news because a huge amount of software which is freely available in
> source form uses this library for it's screen output.  This is a big
> step in opening the door to porting that software to os9.  I haven't
> had time to play with Mr. Goosey's code yet, but I am very excited to
> hear about the progress and plan to start working with it soon.
> 
> -Aaron
> 
> > Richard
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
Well, all I have to say is it is very cool to see you, Boisy, Roger, Willard, 
and I just know I am leaving a whole host of others out, continuing to 
develope software on a system that by all rights rights should have been put 
out to pasture with the B-52... Oh Wait! people are still using and  
developing for that too 8-)!

From aawolfe at gmail.com  Mon Nov 16 11:21:48 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 11:21:48 -0500
Subject: [Coco] DriveWire virtual serial ports - multiball success (2)
In-Reply-To: <200911161058.04955.rcrislip@neo.rr.com>
References: <e44ad6640911160327p79735fdbi4c65d90b156f40e2@mail.gmail.com>
	<200911161058.04955.rcrislip@neo.rr.com>
Message-ID: <e44ad6640911160821o19e5c98el559064cb8e13cd88@mail.gmail.com>

That is Windows 7 with lots of instances of SecureCRT that are
connected to a single Linux box, which is in turn connected via a
serial port to the CoCo's bit banger serial port.

I guess nothing in the screenshot is really running on the Windows
box, its just the display.  I am running four copies of minicom on the
linux box (one in each window) which in turn connect to the four local
PTYs that the single drivewire server is bridging to the OS-9 drivers
over the single bit banger port (which is simultaneously providing the
CoCo's disk drives).  Data for the four connections is then processed
by a single interrupt handler and split out into four standard OS-9
SCF devices (/T1 through /T4).

For whatever reason, I find this all incredibly cool :)  Ever since I
was a kid I wanted to connect my CoCo to other things.  I actually
still have my first CoCo (the large silver version expanded by my
father to 64k).

The DriveWire interface is super easy to program for, and performs
very well even when I write bad software that uses it it silly ways.
I cannot thank the folks who created it and made it available for free
to our community enough.

Also the "toolshed" set of development tools are incredible.  I had it
in my head that I would need to be developing directly on the CoCo or
at best an emulator, this actually delayed my starting the project for
a few months.  When I realized that you could do the work on a linux
box, even assemble your 6809 code and manipulate disk images..
everything changed.  What an amazing set of tools.

-Aaron


On Mon, Nov 16, 2009 at 10:58 AM, richec <rcrislip at neo.rr.com> wrote:
> Hi Aaron,
>
> Congrats on getting it to work. What desktop was that? ?Were you running Vista
> in a VM? Cause the desktop sure looked like Linux to me.
>
> Cheers
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From operator at coco3.com  Sun Nov 15 22:46:12 2009
From: operator at coco3.com (Roger Taylor)
Date: Sun, 15 Nov 2009 21:46:12 -0600
Subject: [Coco] drivewire serial port progress
In-Reply-To: <20091112123328.GA4249@tuxdriver.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
	<20091112123328.GA4249@tuxdriver.com>
Message-ID: <6.2.5.6.1.20091115213512.05841e20@coco3.com>

At 06:33 AM 11/12/2009, you wrote:

>P.S.  I'm pretty sure the "Internet modem" part is available out
>there too, just haven't put a finger on it...
>--
>John W. Linville                Someday the world will need a hero, and you
>linville at tuxdriver.com                  might be all we have.  Be ready.



Last year, the original CoCoNet server was ditched and I'm now using 
Visual Studio .NET for it.  My server is actually the Internet Modem 
program with my additions to it.  It's fast enough and very reliable 
and works with bluetooth COM ports just fine (incoming or outgoing).



-- 
~ Roger Taylor



From operator at coco3.com  Mon Nov 16 12:46:12 2009
From: operator at coco3.com (Roger Taylor)
Date: Mon, 16 Nov 2009 11:46:12 -0600
Subject: [Coco] Drive Pak information
Message-ID: <6.2.5.6.1.20091116113656.05e15450@coco3.com>

Here Ye

I've set a deal price for the Drive Pak while I'm wrapping up the 
CoCoNet ROM.  It will include a MicroSD card and you can of course 
swap out the cards, but I doubt you'll run out of space.  See the 
front page of coco3.com for more info.

The Drive Pak with CoCoNet ROM (required) can auto-boot into DOS or 
NitrOS-9 automatically, get bitbanger drives as well, and more.  Real 
drives are supported as usual, and 6551-based drives if you have an 
MPI and the CoCoNet server running.

The bottom line is that you can take a bare CoCo 1/2 or 3, insert the 
Drive Pak, and boot or auto-boot into the OS-9 system on it, or use 
hundreds of floppy disks.  I am storing as many cool disks as 
possible in the main DOS partition.  My pak's AUTOBOOT.BAS program 
detects a CoCo 1/2 or 3 and boots into the right NitrOS-9 L1 or L2 
automatically, and it's Quick.
-- 
~ Roger Taylor



From linville at tuxdriver.com  Mon Nov 16 12:51:50 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 16 Nov 2009 12:51:50 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <6.2.5.6.1.20091115213512.05841e20@coco3.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
	<20091112123328.GA4249@tuxdriver.com>
	<6.2.5.6.1.20091115213512.05841e20@coco3.com>
Message-ID: <20091116175150.GF14410@tuxdriver.com>

On Sun, Nov 15, 2009 at 09:46:12PM -0600, Roger Taylor wrote:
> At 06:33 AM 11/12/2009, you wrote:
>
>> P.S.  I'm pretty sure the "Internet modem" part is available out
>> there too, just haven't put a finger on it...
>> --
>> John W. Linville                Someday the world will need a hero, and you
>> linville at tuxdriver.com                  might be all we have.  Be ready.
>
>
>
> Last year, the original CoCoNet server was ditched and I'm now using  
> Visual Studio .NET for it.  My server is actually the Internet Modem  
> program with my additions to it.  It's fast enough and very reliable and 
> works with bluetooth COM ports just fine (incoming or outgoing).

Ah, yes -- how could I have 'forgotten' the name?? :-)

	http://boycot.no-ip.com/InternetModem/

Of course, that is in VB.  So, it may (i.e. probably does) need to
be rewritten before it can run on Linux.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From linville at tuxdriver.com  Mon Nov 16 13:04:19 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Mon, 16 Nov 2009 13:04:19 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <20091116175150.GF14410@tuxdriver.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
	<20091112123328.GA4249@tuxdriver.com>
	<6.2.5.6.1.20091115213512.05841e20@coco3.com>
	<20091116175150.GF14410@tuxdriver.com>
Message-ID: <20091116180419.GG14410@tuxdriver.com>

On Mon, Nov 16, 2009 at 12:51:50PM -0500, John W. Linville wrote:
> On Sun, Nov 15, 2009 at 09:46:12PM -0600, Roger Taylor wrote:
> > At 06:33 AM 11/12/2009, you wrote:
> >
> >> P.S.  I'm pretty sure the "Internet modem" part is available out
> >> there too, just haven't put a finger on it...
> >> --
> >> John W. Linville                Someday the world will need a hero, and you
> >> linville at tuxdriver.com                  might be all we have.  Be ready.
> >
> >
> >
> > Last year, the original CoCoNet server was ditched and I'm now using  
> > Visual Studio .NET for it.  My server is actually the Internet Modem  
> > program with my additions to it.  It's fast enough and very reliable and 
> > works with bluetooth COM ports just fine (incoming or outgoing).
> 
> Ah, yes -- how could I have 'forgotten' the name?? :-)
> 
> 	http://boycot.no-ip.com/InternetModem/
> 
> Of course, that is in VB.  So, it may (i.e. probably does) need to
> be rewritten before it can run on Linux.

For those masochistic to want to port/run VB code on Linux...

	http://freshmeat.net/projects/kbasic/

Good luck...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From aawolfe at gmail.com  Mon Nov 16 13:37:00 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 13:37:00 -0500
Subject: [Coco] drivewire serial port progress
In-Reply-To: <20091116175150.GF14410@tuxdriver.com>
References: <e44ad6640911110410m66c0b540s2d23a44bf5d5e149@mail.gmail.com>
	<449B3123-1D03-4849-8B5E-411C3207D14E@tee-boy.com>
	<e44ad6640911110616o2ee51f95reaf9576ef49cba1e@mail.gmail.com>
	<a85805e90911110700t1a7f02d6uafe636328da0a289@mail.gmail.com>
	<e44ad6640911111735i38f0c2e4ud30de66c3684044e@mail.gmail.com>
	<e44ad6640911111754u71d1902et7aa6996b8b2b0d11@mail.gmail.com>
	<20091112020042.GA27541@tuxdriver.com>
	<20091112123328.GA4249@tuxdriver.com>
	<6.2.5.6.1.20091115213512.05841e20@coco3.com>
	<20091116175150.GF14410@tuxdriver.com>
Message-ID: <e44ad6640911161037w2306e11fmb47049da9c20c32b@mail.gmail.com>

On Mon, Nov 16, 2009 at 12:51 PM, John W. Linville
<linville at tuxdriver.com> wrote:
> On Sun, Nov 15, 2009 at 09:46:12PM -0600, Roger Taylor wrote:
>> At 06:33 AM 11/12/2009, you wrote:
>>
>>> P.S. ?I'm pretty sure the "Internet modem" part is available out
>>> there too, just haven't put a finger on it...
>>> --
>>> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
>>> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>>
>>
>>
>> Last year, the original CoCoNet server was ditched and I'm now using
>> Visual Studio .NET for it. ?My server is actually the Internet Modem
>> program with my additions to it. ?It's fast enough and very reliable and
>> works with bluetooth COM ports just fine (incoming or outgoing).
>
> Ah, yes -- how could I have 'forgotten' the name?? :-)
>
> ? ? ? ?http://boycot.no-ip.com/InternetModem/
>
> Of course, that is in VB. ?So, it may (i.e. probably does) need to
> be rewritten before it can run on Linux.
>

Nice!  This should work fine for the Windows side of my project.

It's fairly trivial to create this type of thing in Linux, probably
easy in OS X as well.  I can write one from scratch much quicker than
trying to adapt VB code :)  The source will be handy for ideas though.


> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From goosey at virgo.sdc.org  Mon Nov 16 14:46:19 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Mon, 16 Nov 2009 12:46:19 -0700
Subject: [Coco] curses update
In-Reply-To: <200911160904.32169.rcrislip@neo.rr.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911160904.32169.rcrislip@neo.rr.com>
Message-ID: <20091116194618.GA24260@virgo.sdc.org>

On Mon, Nov 16, 2009 at 09:04:32AM -0500, richec wrote:

> Forgive my ignorance, are you working on a untility called curses or
> a game?  

Niether, it's a C library.  It gives C things things like PRINT@,
LOCATE, and CLS (though of course Curses has different names for
them.)

Though one of my test programs is the beginnings of a rogue-like
game. :-)

>TIA. I am asking because I am trying to figure out how to
> classify this thread in my archives.

No problem.
Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From goosey at virgo.sdc.org  Mon Nov 16 14:48:41 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Mon, 16 Nov 2009 12:48:41 -0700
Subject: [Coco] curses update
In-Reply-To: <4B0166EB.2020304@sbcglobal.net>
References: <20091115104303.GA3570@virgo.sdc.org>
	<4B002A62.9010209@sbcglobal.net>
	<3593C4C7AC8E46C6A237E8A601855FC8@speedy>
	<20091115210236.GA9134@virgo.sdc.org>
	<4B0166EB.2020304@sbcglobal.net>
Message-ID: <20091116194841.GB24260@virgo.sdc.org>

On Mon, Nov 16, 2009 at 08:51:23AM -0600, John Donaldson wrote:
> Willard,
>   Must be my system or something. I just now tried the very same link 
> and it popped up a msg window where I could enter where I wanted to save 
> the file.

OK, cool.  SDC's server may have rebooted, or something.  Or maybe
Qwest is experimentally blocking .lzh files!

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From aawolfe at gmail.com  Mon Nov 16 15:13:10 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Mon, 16 Nov 2009 15:13:10 -0500
Subject: [Coco] curses update
In-Reply-To: <200911161104.05094.rcrislip@neo.rr.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911161002.36765.rcrislip@neo.rr.com>
	<e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
	<200911161104.05094.rcrislip@neo.rr.com>
Message-ID: <e44ad6640911161213t2e2075c0wabccaaba6b675f8e@mail.gmail.com>

On Mon, Nov 16, 2009 at 11:04 AM, richec <rcrislip at neo.rr.com> wrote:
> On Monday 16 November 2009 10:29:20 Aaron Wolfe wrote:
>> On Mon, Nov 16, 2009 at 10:02 AM, richec <rcrislip at neo.rr.com> wrote:
>> > On Monday 16 November 2009 09:45:34 Aaron Wolfe wrote:
>> >> >From http://en.wikipedia.org/wiki/Ncurses
>> >>
>> >> ncurses is a programming library providing an API, allowing the
>> >> programmer to write text user interfaces in a terminal-independent
>> >> manner. It's a toolkit for developing "GUI-like" apps which run under
>> >> a terminal emulator. It also optimizes screen changes, in order to
>> >> reduce the latency experienced when using remote shells.
>> >>
>> >> On Mon, Nov 16, 2009 at 9:04 AM, richec <rcrislip at neo.rr.com> wrote:
>> >> > < S N I P ! ?8-) >
>> >> >
>> >> > Hi Willard,
>> >> >
>> >> > Forgive my ignorance, are you working on a untility called curses or a
>> >> > game? TIA. I am asking because I am trying to figure out how to
>> >> > classify this thread in my archives.
>> >> >
>> >> > --
>> >> > Coco mailing list
>> >> > Coco at maltedmedia.com
>> >> > http://five.pairlist.net/mailman/listinfo/coco
>> >>
>> >> --
>> >> Coco mailing list
>> >> Coco at maltedmedia.com
>> >> http://five.pairlist.net/mailman/listinfo/coco
>> >
>> > Thanks Aaron,
>> >
>> > I have a much better idea of where to file this discussion now. My
>> > Programming experiences have been limited to CoCo BASIC, IBM mainframe
>> > Assembler, COBOL, FORTRAN, and a few other languages that are not in much
>> > use today <sigh>. Although I do have some very limited exposure to C++...
>> > I was teaching it 8-O. I am NOT a programmer however, which is why I am
>> > not familiar with this tool.
>>
>> Even as a "non programer" these days, the work to port curses is great
>> news because a huge amount of software which is freely available in
>> source form uses this library for it's screen output. ?This is a big
>> step in opening the door to porting that software to os9. ?I haven't
>> had time to play with Mr. Goosey's code yet, but I am very excited to
>> hear about the progress and plan to start working with it soon.
>>
>> -Aaron
>>
>> > Richard
>> >
>> > --
>> > Coco mailing list
>> > Coco at maltedmedia.com
>> > http://five.pairlist.net/mailman/listinfo/coco
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
> Well, all I have to say is it is very cool to see you, Boisy, Roger, Willard,
> and I just know I am leaving a whole host of others out, continuing to
> develope software on a system that by all rights rights should have been put
> out to pasture with the B-52... Oh Wait! people are still using and
> developing for that too 8-)!
>

As I delve deeper into OS-9, I am more and more impressed.  I just
cannot believe what a huge step backwards MSDOS was, even on machines
with 10 times the ram.

I never got to use OS-9 as a kid, we didn't even have a disk drive for
our CoCo despite my many requests.  By the time I got my hands on a
machine with disks, it was a DOS machine and I never realized till
just lately how advanced OS-9 was in comparison.  I remember reading
Rainbow articles as a kid about OS9 (used to read it cover to cover)
but I never understood what they were talking about.

It is truly a shame that something like OS-9 existed yet the PC world
mostly standardized on such an inferior system.  I can only imagine
the frustration people who knew OS-9 back then must have felt watching
this happen.

In my opinion, rather than being put out to pasture, systems like this
should be studied by students of software design.  Sure, the system
isn't "useful" for general purpose computing by today's standards, but
as an example of what can be done with well written software, I think
it could be an awesome teaching tool.

The basic concepts used in OS-9 are still present in modern systems,
and often are not implemented as well.  You can't really study a
system like Windows, since the source is closed and it's a massive
amount of code.  Linux is better and easily obtained, but still far
too large to become intimately familiar with just for the sake of
learning.  OS-9 provides examples of many important concepts, but it's
still easy to find, read and understand any given part of it without
too much effort.

I recently purchased Lion's famous commentary on the original Unix
source code in hopes of learning more about some of the same things
I'm now learning from OS-9.  I think the OS-9 source and documentation
that can be found on the maltedmedia site provide a better learning
environment than even this "classic".

Just my $0.02 on this outdated machine :)
-Aaron

From goosey at virgo.sdc.org  Mon Nov 16 15:15:30 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Mon, 16 Nov 2009 13:15:30 -0700
Subject: [Coco] curses update
In-Reply-To: <e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911160904.32169.rcrislip@neo.rr.com>
	<e44ad6640911160645u2960bd1bobf6566bc95b54517@mail.gmail.com>
	<200911161002.36765.rcrislip@neo.rr.com>
	<e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
Message-ID: <20091116201530.GC24260@virgo.sdc.org>

On Mon, Nov 16, 2009 at 10:29:20AM -0500, Aaron Wolfe wrote:
> Even as a "non programer" these days, the work to port curses is great
> news because a huge amount of software which is freely available in
> source form uses this library for it's screen output.  This is a big
> step in opening the door to porting that software to os9.  

I hope so, anyway.  

>I haven't
> had time to play with Mr. Goosey's code yet, but I am very excited to
> hear about the progress and plan to start working with it soon.
>
I feel I should point out that very little of that code is mine.  A
fellow named Allen I. Holub published the original in DDJ (for
MS-DOS), and someone named R. Waggoner ported it to OSK.  I just
tweaked things to get it to compile under 6X09, and fixed the more
obvious bugs.

That being said, Holub wrote a *subset* curses.  There's some
functinality that I want that it doesn't have.  Might have to do
something about that. ;-)

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From goosey at virgo.sdc.org  Mon Nov 16 15:20:47 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Mon, 16 Nov 2009 13:20:47 -0700
Subject: [Coco] curses update
In-Reply-To: <200911161104.05094.rcrislip@neo.rr.com>
References: <20091115104303.GA3570@virgo.sdc.org>
	<200911161002.36765.rcrislip@neo.rr.com>
	<e44ad6640911160729r893e34tfcc7a443d658a37d@mail.gmail.com>
	<200911161104.05094.rcrislip@neo.rr.com>
Message-ID: <20091116202047.GD24260@virgo.sdc.org>

On Mon, Nov 16, 2009 at 11:04:04AM -0500, richec wrote:

> Well, all I have to say is it is very cool to see you, Boisy, Roger, Willard, 
> and I just know I am leaving a whole host of others out, continuing to 
> develope software on a system that by all rights rights should have been put 
> out to pasture with the B-52... Oh Wait! people are still using and  
> developing for that too 8-)!

Wow.  That really makes all the headaches worthwhile.  Thank you.

Being included on the same list as Boisy and Roger.  Wow.

Thank you
Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From dennis-ix at maltedmedia.com  Tue Nov 17 11:45:26 2009
From: dennis-ix at maltedmedia.com (Dennis Bathory-Kitsz)
Date: Tue, 17 Nov 2009 11:45:26 -0500
Subject: [Coco] New items in maltedmedia ftp
Message-ID: <200911171645.nAHGjY8V012270@tv-failover-01.trans-video.net>

Hi all,

I haven't been paying attention to my ftp incoming directory, and 
discovered today quite a few new uploaded items.

If you upload something to ftp://maltedmedia.com/incoming/  please 
send me a note that you've done it. It was chock full!

Who uploaded those items? If you mentioned that you were going to, 
I've forgotten.

In any case, there are some 950 new items. I've moved them all over 
to the ftp://maltedmedia.com/coco/NEWLY-RECEIVED/  .... eventually, 
when the good volunteers have some time, they'll sort them to the 
right directories.

Best to everyone,
Dennis










Country Stores book!
<http://www.amazon.com/Country-Stores-Vermont-Dennis-Bathory-kitsz/dp/1596294752/>
"Three Performance Pieces"!
<http://www.lulu.com/content/7343950>
Bathory Opera libretto!
<http://www.lulu.com/content/5649281>
"We Are All Mozart"
<http://maltedmedia.com/waam/>




From msmcdoug at iinet.net.au  Tue Nov 17 17:49:04 2009
From: msmcdoug at iinet.net.au (Mark McDougall)
Date: Wed, 18 Nov 2009 09:49:04 +1100
Subject: [Coco] DriveWire virtual serial ports - multiball success (2)
In-Reply-To: <e44ad6640911160821o19e5c98el559064cb8e13cd88@mail.gmail.com>
References: <e44ad6640911160327p79735fdbi4c65d90b156f40e2@mail.gmail.com>	<200911161058.04955.rcrislip@neo.rr.com>
	<e44ad6640911160821o19e5c98el559064cb8e13cd88@mail.gmail.com>
Message-ID: <4B032860.3080703@iinet.net.au>

Aaron Wolfe wrote:

> I actually
> still have my first CoCo (the large silver version expanded by my
> father to 64k).

Hang on to it. My father expanded my silver Coco and after it was relegated 
to the garage for a few years, he gave it away to friends with young kids. 
Now both are gone, I sure wish I still had it... :(

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

From jmichea at cogeco.ca  Tue Nov 17 18:38:38 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Tue, 17 Nov 2009 18:38:38 -0500
Subject: [Coco] Stellar Life Line Manual
Message-ID: <000a01ca67df$169ff4b0$ecfd3918@jeremy4b3f9678>

Does anyone know if there is a manual for this game online? I know there are a few game manuals online but I don't think this is one of them. Can anyone point me in the right direction?
Thanks very much
Jeremy

From aawolfe at gmail.com  Wed Nov 18 15:16:29 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 18 Nov 2009 15:16:29 -0500
Subject: [Coco] Caring for a CoCo
Message-ID: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>

Hi,

As I've been running my development Coco quite a bit lately, I started
wondering about what is the best way to keep it running as long as
possible.
I've also considered running a Coco 24/7 as a server of sorts.  I am
not a hardware guy, so a failed component would be a big problem for
me.

Are there any tips for running an old Coco as "safely" as possible?
They seem to get pretty warm along the top side where the vents are,
especially my 6309/512k upgraded model.  Would removing the shell
improve cooling?  Possibly cutting a hole and installing a small fan?
Are the components designed well enough for 24/7 operation in general,
and does this raise any special concerns?

Thanks for any tips
-Aaron

From brucewcalkins at charter.net  Wed Nov 18 16:20:48 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Wed, 18 Nov 2009 16:20:48 -0500
Subject: [Coco] Caring for a CoCo
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
Message-ID: <A90CFF2E73BA4C96BED5CE945E25E2D3@speedy>


----- Original Message ----- 
From: "Aaron Wolfe"


> Hi,
> <snip>
> Are there any tips for running an old Coco as "safely" as possible?
> They seem to get pretty warm along the top side where the vents are,
> especially my 6309/512k upgraded model.  Would removing the shell
> improve cooling?  Possibly cutting a hole and installing a small fan?
> Are the components designed well enough for 24/7 operation in general,
> and does this raise any special concerns?
>
> Thanks for any tips
> -Aaron
>
> --

================================================

I have one CoCo 3 that I installed a Pentium 1 fan in the top cover and ran 
its power line to the hard drive power supply.  I had the Dragonfly fan in a 
CoCo 1 but that never seemed to help, and the buzz was annoying.  I saw a 
multi-pack on eBay recently that had a fan mounted to the right of the 
ROM-Pack slots.



In all truth, the Pentium 1 class CPU heatsink fan in the vents of the CoCo 
3 is about all the fan any CoCo 3 can use.  Aside from the RAM we just are 
not dealing with the speeds and power consumption that make for a lot of 
heat.  Also, I'm given to understand that there is little reserve in the 
CoCo's power supply to run a fan with.



Bruce W.


From lamune at doki-doki.net  Wed Nov 18 16:23:32 2009
From: lamune at doki-doki.net (Mike Pepe)
Date: Wed, 18 Nov 2009 13:23:32 -0800
Subject: [Coco] Caring for a CoCo
In-Reply-To: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
Message-ID: <EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>

A small fan will do wonders. The power supply is the weakest link in the chain in CoCos, reducing the temps inside will prolong the power supply's lifetime.

I would also consider changing out the electrolytic filter caps in the power supply, as they do tend to dry out with age and the increasing amounts of AC ripple riding through the supply can't be good for it.

> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-
> bounces at maltedmedia.com] On Behalf Of Aaron Wolfe
> Sent: Wednesday, November 18, 2009 12:16 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: [Coco] Caring for a CoCo
> 
> Hi,
> 
> As I've been running my development Coco quite a bit lately, I started
> wondering about what is the best way to keep it running as long as
> possible.
> I've also considered running a Coco 24/7 as a server of sorts.  I am
> not a hardware guy, so a failed component would be a big problem for
> me.
> 
> Are there any tips for running an old Coco as "safely" as possible?
> They seem to get pretty warm along the top side where the vents are,
> especially my 6309/512k upgraded model.  Would removing the shell
> improve cooling?  Possibly cutting a hole and installing a small fan?
> Are the components designed well enough for 24/7 operation in general,
> and does this raise any special concerns?
> 
> Thanks for any tips
> -Aaron
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


From asa.rand at yahoo.com  Wed Nov 18 16:24:03 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Wed, 18 Nov 2009 13:24:03 -0800 (PST)
Subject: [Coco] Caring for a CoCo
In-Reply-To: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
Message-ID: <132449.87997.qm@web53702.mail.re2.yahoo.com>

I'm not the one to answer your questions, Aaron, but reading your post brought memories back. I remember my 512K CoCo3 being warmer than my 64K CoCo2 was, but both got very warm around the vents. I remember getting one of those internal fans and having a friend help me wire it in so it came on when the CoCo was turned on. The fan was too large to fit inside the CoCo's case, so it was mounted to the top left of the case, over the vent holes facing down, and blew air into the case. the air movement came out the right side, and kept the CoCo much cooler.

If you're planning to try to run one 24/7 (and mine was on at least 18 hours a day), a fan will definitely help with the heat issue.

Wayne



________________________________
From: Aaron Wolfe <aawolfe at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Wed, November 18, 2009 12:16:29 PM
Subject: [Coco] Caring for a CoCo

Hi,

As I've been running my development Coco quite a bit lately, I started
wondering about what is the best way to keep it running as long as
possible.
I've also considered running a Coco 24/7 as a server of sorts.  I am
not a hardware guy, so a failed component would be a big problem for
me.

Are there any tips for running an old Coco as "safely" as possible?
They seem to get pretty warm along the top side where the vents are,
especially my 6309/512k upgraded model.  Would removing the shell
improve cooling?  Possibly cutting a hole and installing a small fan?
Are the components designed well enough for 24/7 operation in general,
and does this raise any special concerns?

Thanks for any tips
-Aaron

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From jdaggett at gate.net  Wed Nov 18 18:19:44 2009
From: jdaggett at gate.net (jdaggett at gate.net)
Date: Wed, 18 Nov 2009 18:19:44 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>,
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
Message-ID: <4B048110.5725.7880A@jdaggett.gate.net>

On 18 Nov 2009 at 13:23, Mike Pepe wrote:

> I would also consider changing out the electrolytic filter caps in the
> power supply, as they do tend to dry out with age and the increasing
> amounts of AC ripple riding through the supply can't be good for it.

The electrolytics would only be a problem if the unit has sat for several years and not been 
powered up. Yes the electrolytic materail tends to deform with age and no charge on the cap. 
What happens then is the ESR of the cap goes way up. This reduces its function as a filter 
against ripple. 

james

From boisy at tee-boy.com  Wed Nov 18 19:00:45 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Wed, 18 Nov 2009 18:00:45 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <4B048110.5725.7880A@jdaggett.gate.net>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>,
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
	<4B048110.5725.7880A@jdaggett.gate.net>
Message-ID: <E4B54168-DD6A-4CE1-8D56-9EBD3E6176E7@tee-boy.com>

I would think that would be an issue with a lot of CoCos and might explain some of the "strangeness" that CoCo's exhibit as they get older.

What would be the symptoms of this type of degradation james?
--
Boisy G. Pitre
http://www.tee-boy.com/

On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:

> On 18 Nov 2009 at 13:23, Mike Pepe wrote:
> 
>> I would also consider changing out the electrolytic filter caps in the
>> power supply, as they do tend to dry out with age and the increasing
>> amounts of AC ripple riding through the supply can't be good for it.
> 
> The electrolytics would only be a problem if the unit has sat for several years and not been 
> powered up. Yes the electrolytic materail tends to deform with age and no charge on the cap. 
> What happens then is the ESR of the cap goes way up. This reduces its function as a filter 
> against ripple. 
> 
> james
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


From georgeramsower at gmail.com  Wed Nov 18 19:02:04 2009
From: georgeramsower at gmail.com (George Ramsower)
Date: Wed, 18 Nov 2009 18:02:04 -0600
Subject: [Coco] Caring for a CoCo
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
Message-ID: <002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>

You have ME wondering...
What sort of server are you considering?

 If I were to just start out with a stock Coco 3 and wanted to run it 24/7, I would just buy a six inch fan from Wal-Mart and blow it over the computer. So easy and cheap. No hardware experience required. No need to re-invent the wheel here.

 George

--------------------------------------------------------------------------------------------
----- Original Message ----- 
From: Aaron Wolfe 
Hi,

As I've been running my development Coco quite a bit lately, I started
wondering about what is the best way to keep it running as long as
possible.
I've also considered running a Coco 24/7 as a server of sorts.  I am
not a hardware guy, so a failed component would be a big problem for
me.


From linville at tuxdriver.com  Wed Nov 18 19:43:02 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 18 Nov 2009 19:43:02 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
Message-ID: <20091119004302.GC5630@tuxdriver.com>

On Wed, Nov 18, 2009 at 06:02:04PM -0600, George Ramsower wrote:
> You have ME wondering...
> What sort of server are you considering?

Considering Aaron's other project, I'd have to presume that he is
thinking about a multi-line BBS...

Am I right?? :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From aawolfe at gmail.com  Wed Nov 18 20:03:08 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Wed, 18 Nov 2009 20:03:08 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <20091119004302.GC5630@tuxdriver.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
	<20091119004302.GC5630@tuxdriver.com>
Message-ID: <e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>

On Wed, Nov 18, 2009 at 7:43 PM, John W. Linville
<linville at tuxdriver.com> wrote:
> On Wed, Nov 18, 2009 at 06:02:04PM -0600, George Ramsower wrote:
>> You have ME wondering...
>> What sort of server are you considering?
>
> Considering Aaron's other project, I'd have to presume that he is
> thinking about a multi-line BBS...
>
> Am I right?? :-)
>

Yes, something like that :)

I haven't yet found an OS-9 BBS that is public domain/open source and
supports multiple lines.
Anybody have suggestions?

-Aaron


> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From gene.heskett at verizon.net  Wed Nov 18 21:57:58 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Wed, 18 Nov 2009 21:57:58 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <E4B54168-DD6A-4CE1-8D56-9EBD3E6176E7@tee-boy.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<4B048110.5725.7880A@jdaggett.gate.net>
	<E4B54168-DD6A-4CE1-8D56-9EBD3E6176E7@tee-boy.com>
Message-ID: <200911182157.59016.gene.heskett@verizon.net>

On Wednesday 18 November 2009, Boisy G. Pitre wrote:
>I would think that would be an issue with a lot of CoCos and might explain
> some of the "strangeness" that CoCo's exhibit as they get older.
>
>What would be the symptoms of this type of degradation james?

Less than stable operation.  And hum bars in the video would be instant cause 
for replacement of the electrolytics.  All of them at this age are going to 
be suspect.

I'm seeing heat questions.  I battled that too, but cooled it down some when 
I swapped the 512k card out for one of Tony D's 2 megs kits, which uses a 
pair of 1 megs simm modules.  But the real end of the heat problems was when 
I pulled all the psu components off the board in both my cc3 and the 
multipack, and ran a pair of 4 pin trailer connectors out to an old AT power 
supply.  Its fan cooled and loafing with that load along with my stack of 
drives, and the coco3 runs so cool that I have laid a darkroom thermometer on 
the top grill, & tossed a furniture blanket on top of that.  I can come back 
in an hour, or 2 weeks, and the thermometer is maybe 2 degrees above ambient.

In short, the coco's power supply is its own worst enemy.  With the 2 meg kit 
and a 63C09, the only heat source left is the gime chip.

>--
>Boisy G. Pitre
>http://www.tee-boy.com/
>
>On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:
>> On 18 Nov 2009 at 13:23, Mike Pepe wrote:
>>> I would also consider changing out the electrolytic filter caps in the
>>> power supply, as they do tend to dry out with age and the increasing
>>> amounts of AC ripple riding through the supply can't be good for it.
>>
>> The electrolytics would only be a problem if the unit has sat for several
>> years and not been powered up. Yes the electrolytic materail tends to
>> deform with age and no charge on the cap. What happens then is the ESR of
>> the cap goes way up. This reduces its function as a filter against
>> ripple.
>>
>> james
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

Enjoy your life; be pleasant and gay, like the birds in May.

From RJRTTY at aol.com  Wed Nov 18 23:50:14 2009
From: RJRTTY at aol.com (RJRTTY at aol.com)
Date: Wed, 18 Nov 2009 23:50:14 EST
Subject: [Coco] Caring for a CoCo
Message-ID: <d44.5a278dc8.38362886@aol.com>

In a message dated 11/18/2009 7:01:06 P.M. Eastern Standard Time,  
boisy at tee-boy.com writes:


>I would think that would be an issue with a lot
> of CoCos and might explain some of the "strangeness" that
> CoCo's exhibit as they get older.

>What would be the  symptoms of this type of degradation james?
--
 
 
You can identity a bad cap by using a
VOM set to AC input with a non polar blocking
electrolytic  cap in series with the measuring circuit.
Some VOM's have these built in for measuring AC on
DC.   Any nonzero reading at
all indicates a bad cap.    I use to find them  routinely
this way at work.   The bad ones were usually made in  Mexico.
 
You can also find a bad cap that's been setting a very long while
when you first apply power.   They usually explode and
catch fire.   I found a few using this method too.  :)
 
Roy
 

From aawolfe at gmail.com  Thu Nov 19 00:58:53 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 00:58:53 -0500
Subject: [Coco] DriveWire netdisks
Message-ID: <e44ad6640911182158r54702deahb46760768ed4cfeb@mail.gmail.com>

I just put together another "proof of concept" type hack for
DriveWire.  This modification allows you to attach disk images to your
CoCo that are located on another server, using TCP.   I just booted my
CoCo off an image on my web server which is in Dallas TX, my Coco and
I live in south Florida.  Pretty cool :)

The repository provides a listing of available disk images and their
description (in the future this could be done better or with more
detail).  Choose a name from the list, and it's instantly "in the
drive" of your CoCo.  Current version only allows reading the disks,
but maybe something could be worked out to allow
controlled/protected/authenticated/etc writing to the images as well.

If anyone wants to play hunt the bugs with this, I put the initial
code on my coco project page at http://aaronwolfe.com/coco

-Aaron

From adit at nationsdial.com  Thu Nov 19 02:38:02 2009
From: adit at nationsdial.com (Dean Leiber)
Date: Wed, 18 Nov 2009 23:38:02 -0800
Subject: [Coco] Caring for a CoCo
In-Reply-To: <e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
	<20091119004302.GC5630@tuxdriver.com>
	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
Message-ID: <2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>


On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>
> Yes, something like that :)
>
> I haven't yet found an OS-9 BBS that is public domain/open source and
> supports multiple lines.
> Anybody have suggestions?
>
> -Aaron

I'm not sure about RiBBS being multi-line but the source should be  
about, since I think they released the source at the end. I'm fairly  
sure that the old StG BBS could do multi-line. I've seen the source  
around and I think Scott Griepentrog OK'ed its release. Anybody  
familiar with the other BBS'?

Dean

From aawolfe at gmail.com  Thu Nov 19 03:55:46 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 03:55:46 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
Message-ID: <e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>

I think I will explore the option of a small fan like those found on
some CPU heatsinks.  Probably have one around somewhere and it sounds
like the general consensus is that reducing the heat would be a good
thing.

My main/dev CoCo is one I bought on ebay, premodified in a number of
ways, 6309 and some other handmade improvements.  It runs very well
but some strange things have happened inside.  The power button has
been replaced with a wire nut somehow (works fine) and the power cord
replaced with a heavier and 3 pronged cord.  From these changes and
the newish appearance of the components in the power supply, I think
it may have been replaced or serviced in recent years.  Sounds like
that's a good thing, if true.

I've given it quite a workout in the past week, but it's solid as a
rock so far.  Well.. as stable as any machine can be when I'm making
it run code that I wrote :)

Thanks for the info.
-Aaron


On Wed, Nov 18, 2009 at 4:23 PM, Mike Pepe <lamune at doki-doki.net> wrote:
> A small fan will do wonders. The power supply is the weakest link in the chain in CoCos, reducing the temps inside will prolong the power supply's lifetime.
>
> I would also consider changing out the electrolytic filter caps in the power supply, as they do tend to dry out with age and the increasing amounts of AC ripple riding through the supply can't be good for it.
>
>> -----Original Message-----
>> From: coco-bounces at maltedmedia.com [mailto:coco-
>> bounces at maltedmedia.com] On Behalf Of Aaron Wolfe
>> Sent: Wednesday, November 18, 2009 12:16 PM
>> To: CoCoList for Color Computer Enthusiasts
>> Subject: [Coco] Caring for a CoCo
>>
>> Hi,
>>
>> As I've been running my development Coco quite a bit lately, I started
>> wondering about what is the best way to keep it running as long as
>> possible.
>> I've also considered running a Coco 24/7 as a server of sorts. ?I am
>> not a hardware guy, so a failed component would be a big problem for
>> me.
>>
>> Are there any tips for running an old Coco as "safely" as possible?
>> They seem to get pretty warm along the top side where the vents are,
>> especially my 6309/512k upgraded model. ?Would removing the shell
>> improve cooling? ?Possibly cutting a hole and installing a small fan?
>> Are the components designed well enough for 24/7 operation in general,
>> and does this raise any special concerns?
>>
>> Thanks for any tips
>> -Aaron
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From goosey at virgo.sdc.org  Thu Nov 19 05:23:06 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Thu, 19 Nov 2009 03:23:06 -0700
Subject: [Coco] Curses update
Message-ID: <20091119102306.GA7152@virgo.sdc.org>

New release of my port of old subset Curses library:
http://www.sdc.org/~goosey/os9/curses05.lzh

Mostly added docs and some internal improvements.  And getstr()!

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From goosey at virgo.sdc.org  Thu Nov 19 05:48:47 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Thu, 19 Nov 2009 03:48:47 -0700
Subject: [Coco] DDJ license?
Message-ID: <20091119104847.GA8109@virgo.sdc.org>

So, this curses subset I've been working on was originally published
in Dr. Dobbs Journal in 1987.

I have googled to find out if I'm actually legally allowed to port and
re-release it, but all I can find are refrences to the TinyBASIC
Copyleft, "all wrongs reserved".  In '79, it seems that the magazine
that would become DDJ was very much open-source friendly.

Was that still true in 1987?

Anybody know?

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From brucewcalkins at charter.net  Thu Nov 19 06:03:12 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Thu, 19 Nov 2009 06:03:12 -0500
Subject: [Coco] Caring for a CoCo
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com><EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
	<e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>
Message-ID: <0D44D3C0CD924ED68B13238B1DC2A4BA@speedy>

Yes, that comment brings a smile of rememberance to my face.
I've locked up a few computers with an endless loop or the likes.

Bruce W.

==============================================


----- Original Message ----- 
From: "Aaron Wolfe" 

I've given it quite a workout in the past week, but it's solid as a
rock so far.  Well.. as stable as any machine can be when I'm making
it run code that I wrote :)

Thanks for the info.
-Aaron


From rbihler at msn.com  Thu Nov 19 08:39:43 2009
From: rbihler at msn.com (Ron Bihler)
Date: Thu, 19 Nov 2009 06:39:43 -0700
Subject: [Coco] Caring for a CoCo
In-Reply-To: <2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>
Message-ID: <BLU0-SMTP28F7634EF80A71D85E8014AFA20@phx.gbl>

No RiBBS is not multiline, however being OS9 it should be possible to 
run multiple copies.  The original Coco was too slow to do much more 
than just run ribbs. In regards to source, I am still trying to put this 
together and thanks to some help I am getting we are Unpacking the 
packed code. 

Ron Bihler


Dean Leiber wrote:
>
> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>
>> Yes, something like that :)
>>
>> I haven't yet found an OS-9 BBS that is public domain/open source and
>> supports multiple lines.
>> Anybody have suggestions?
>>
>> -Aaron
>
> I'm not sure about RiBBS being multi-line but the source should be 
> about, since I think they released the source at the end. I'm fairly 
> sure that the old StG BBS could do multi-line. I've seen the source 
> around and I think Scott Griepentrog OK'ed its release. Anybody 
> familiar with the other BBS'?
>
> Dean
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>

From boisy at tee-boy.com  Thu Nov 19 09:32:06 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Thu, 19 Nov 2009 08:32:06 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
	<e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>
Message-ID: <78B6829B-BE6D-41BF-AB71-0673C7C29F74@tee-boy.com>

Aaron,

Are you planning on extending the server to allow external connections from the Internet to go to your CoCo?  It would be great if I could telnet to an address and port that you provided, which would then be used by your DriveWire server to redirect traffic to one of the 7 virtual ports on your CoCo running OS-9.

Boisy

On Nov 19, 2009, at 2:55 AM, Aaron Wolfe wrote:

> I think I will explore the option of a small fan like those found on
> some CPU heatsinks.  Probably have one around somewhere and it sounds
> like the general consensus is that reducing the heat would be a good
> thing.
> 
> My main/dev CoCo is one I bought on ebay, premodified in a number of
> ways, 6309 and some other handmade improvements.  It runs very well
> but some strange things have happened inside.  The power button has
> been replaced with a wire nut somehow (works fine) and the power cord
> replaced with a heavier and 3 pronged cord.  From these changes and
> the newish appearance of the components in the power supply, I think
> it may have been replaced or serviced in recent years.  Sounds like
> that's a good thing, if true.
> 
> I've given it quite a workout in the past week, but it's solid as a
> rock so far.  Well.. as stable as any machine can be when I'm making
> it run code that I wrote :)
> 
> Thanks for the info.
> -Aaron
> 
> 
> On Wed, Nov 18, 2009 at 4:23 PM, Mike Pepe <lamune at doki-doki.net> wrote:
>> A small fan will do wonders. The power supply is the weakest link in the chain in CoCos, reducing the temps inside will prolong the power supply's lifetime.
>> 
>> I would also consider changing out the electrolytic filter caps in the power supply, as they do tend to dry out with age and the increasing amounts of AC ripple riding through the supply can't be good for it.
>> 
>>> -----Original Message-----
>>> From: coco-bounces at maltedmedia.com [mailto:coco-
>>> bounces at maltedmedia.com] On Behalf Of Aaron Wolfe
>>> Sent: Wednesday, November 18, 2009 12:16 PM
>>> To: CoCoList for Color Computer Enthusiasts
>>> Subject: [Coco] Caring for a CoCo
>>> 
>>> Hi,
>>> 
>>> As I've been running my development Coco quite a bit lately, I started
>>> wondering about what is the best way to keep it running as long as
>>> possible.
>>> I've also considered running a Coco 24/7 as a server of sorts.  I am
>>> not a hardware guy, so a failed component would be a big problem for
>>> me.
>>> 
>>> Are there any tips for running an old Coco as "safely" as possible?
>>> They seem to get pretty warm along the top side where the vents are,
>>> especially my 6309/512k upgraded model.  Would removing the shell
>>> improve cooling?  Possibly cutting a hole and installing a small fan?
>>> Are the components designed well enough for 24/7 operation in general,
>>> and does this raise any special concerns?
>>> 
>>> Thanks for any tips
>>> -Aaron
>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Boisy G. Pitre
http://www.tee-boy.com/


From mmarlette at frontiernet.net  Thu Nov 19 09:27:13 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Thu, 19 Nov 2009 14:27:13 +0000 (UTC)
Subject: [Coco] Caring for a CoCo
In-Reply-To: <186658408.20671258640793917.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <960352620.20951258640833594.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>


Since the machine is apart. I would remove the GIME, with the proper tooling, a PLCC chip removal tool, and clean the leads. Soft white eraser, rubbed in the direction of the lead. This will ensure that you don't bend the lead.

Materials tarnish, sockets are a HUGH reliability factor. In defense designs, we can't use them, nor want to for this reason.

Not sure if you are using a multi-pak or not. Same applies here. Tandy did not use gold on their card edge connectors in the multi-paks or in the floppy controllers, 502 might have. My dev. system runs 24/7. Failure points will be in the multi-pak OR cards that DO NOT have a gold card edge. Another reason why ALL Cloud-9 products, that have a card edge connection, require that surface to be plated with gold. Thus a higher cost, but higher reliability = quality product.To clean the card edge connections, again use the white soft eraser, it won't be white for long....... :)

Mark
Cloud-9


----- Original Message -----
From: "Boisy G. Pitre" <boisy at tee-boy.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, November 18, 2009 6:00:45 PM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Caring for a CoCo

I would think that would be an issue with a lot of CoCos and might explain some of the "strangeness" that CoCo's exhibit as they get older.

What would be the symptoms of this type of degradation james?
--
Boisy G. Pitre
http://www.tee-boy.com/

On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:

> On 18 Nov 2009 at 13:23, Mike Pepe wrote:
> 
>> I would also consider changing out the electrolytic filter caps in the
>> power supply, as they do tend to dry out with age and the increasing
>> amounts of AC ripple riding through the supply can't be good for it.
> 
> The electrolytics would only be a problem if the unit has sat for several years and not been 
> powered up. Yes the electrolytic materail tends to deform with age and no charge on the cap. 
> What happens then is the ESR of the cap goes way up. This reduces its function as a filter 
> against ripple. 
> 
> james
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

From kg4knb at hat3.net  Thu Nov 19 10:15:32 2009
From: kg4knb at hat3.net (Jim Hathaway)
Date: Thu, 19 Nov 2009 09:15:32 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <960352620.20951258640833594.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
References: <186658408.20671258640793917.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
	<960352620.20951258640833594.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <a85805e90911190715p7239ae9bxddc449d32a6ec0f8@mail.gmail.com>

On Thu, Nov 19, 2009 at 8:27 AM, Mark Marlette <mmarlette at frontiernet.net>wrote:

>
> Since the machine is apart. I would remove the GIME, with the proper
> tooling, a PLCC chip removal tool, and clean the leads. Soft white eraser,
> rubbed in the direction of the lead. This will ensure that you don't bend
> the lead.
>
> Materials tarnish, sockets are a HUGH reliability factor. In defense
> designs, we can't use them, nor want to for this reason.
>
> Not sure if you are using a multi-pak or not. Same applies here. Tandy did
> not use gold on their card edge connectors in the multi-paks or in the
> floppy controllers, 502 might have. My dev. system runs 24/7. Failure points
> will be in the multi-pak OR cards that DO NOT have a gold card edge. Another
> reason why ALL Cloud-9 products, that have a card edge connection, require
> that surface to be plated with gold. Thus a higher cost, but higher
> reliability = quality product.To clean the card edge connections, again use
> the white soft eraser, it won't be white for long....... :)
>
> Mark
> Cloud-9
>
>
>
Thanks for providing some more details around possible failure points.  I
have been dealing with issues from my two CoCo 3 systems in the past year or
so.  The first issue was the complete failure of a 512k memory board.  This
one drove me crazy and I spent lots of time replacing all the memory chips,
replacing caps on the board and also trying to re-flow the solder
connections on the board.  All of these steps did not help, and so in the
end there is something else that has caused this board to fail.  This board
was manufactured by Performance Peripherals.

My only working 512k board that is 'working' is a home made 512k simm board.
 However when I use this board in either of my systems and attempt to use
drivewire and boot into nitros I find that after a few minutes the system
becomes unreliable, locking up, weird characters on the screen, etc.  I
suspect the simms might be bad, but have not done extensive testing.

At this point I am not even connecting my multi-pack to my system(s) because
as you stated this is just another point of failure (all the connections).
 I figure I should be able to take just a stand alone 512k CoCo 3 boot into
nitros via drivewire and have a reliable system.

Jim





> ----- Original Message -----
> From: "Boisy G. Pitre" <boisy at tee-boy.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Wednesday, November 18, 2009 6:00:45 PM GMT -06:00 US/Canada Central
> Subject: Re: [Coco] Caring for a CoCo
>
> I would think that would be an issue with a lot of CoCos and might explain
> some of the "strangeness" that CoCo's exhibit as they get older.
>
> What would be the symptoms of this type of degradation james?
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
> On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:
>
> > On 18 Nov 2009 at 13:23, Mike Pepe wrote:
> >
> >> I would also consider changing out the electrolytic filter caps in the
> >> power supply, as they do tend to dry out with age and the increasing
> >> amounts of AC ripple riding through the supply can't be good for it.
> >
> > The electrolytics would only be a problem if the unit has sat for several
> years and not been
> > powered up. Yes the electrolytic materail tends to deform with age and no
> charge on the cap.
> > What happens then is the ESR of the cap goes way up. This reduces its
> function as a filter
> > against ripple.
> >
> > james
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From farna at att.net  Thu Nov 19 10:58:56 2009
From: farna at att.net (Frank Swygert)
Date: Thu, 19 Nov 2009 10:58:56 -0500
Subject: [Coco] Caring for a CoCo
Message-ID: <4B056B40.40904@att.net>

Sounds like the CoCo PS may have been upgraded, probably a bigger transformer and some heavier duty components, but may have just been replaced as you suspect. Without a standard one beside it there's no way to be sure... or a nice photo of the PS area on yours...

D/L "Tandy's Little Wonder" from the list archive site -- it's in the Farna directory. It has the instructions to remove the CoCo PS and install an external PS. If you just removed the transformer and used a wall-wart instead that would remove a substantial amount of heat. A small fan over the vents or on the side would work, as well as the suggestion of just a small desktop fan blowing over it. I've seen little 2" or so fans bolted to the left side with a hole cut into the case. I don't know if the PS would power it, but the fan does allow the PS to do a little more work without overheating. Most use an external power source for the fan -- a wall-wart or wire running over to the drive PS. If you have one of the last Tandy drive setups you'd be taxing that PS by adding a fan too though! The early ones with a big wall-wart type transformer hanging on the back (not a real wall-wart!) were made for the old power hungry full height drives -- they have power to spare assuming the drive has been replaced. Even two half height drives don't take as much power as one of the old full heights! 

------------
Date: Thu, 19 Nov 2009 03:55:46 -0500
From: Aaron Wolfe <aawolfe at gmail.com>

I think I will explore the option of a small fan like those found on
some CPU heatsinks.  Probably have one around somewhere and it sounds
like the general consensus is that reducing the heat would be a good
thing.

My main/dev CoCo is one I bought on ebay, premodified in a number of
ways, 6309 and some other handmade improvements.  It runs very well
but some strange things have happened inside.  The power button has
been replaced with a wire nut somehow (works fine) and the power cord
replaced with a heavier and 3 pronged cord.  From these changes and
the newish appearance of the components in the power supply, I think
it may have been replaced or serviced in recent years.  Sounds like
that's a good thing, if true.

-- 
Frank Swygert
Publisher, "American Motors Cars" 
Magazine (AMC)
For all AMC enthusiasts
http://farna.home.att.net/AMC.html
(free download available!)



From johnadonaldson at sbcglobal.net  Thu Nov 19 11:51:03 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Thu, 19 Nov 2009 10:51:03 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>
Message-ID: <4B057777.7070603@sbcglobal.net>

When the MM/1 came out, I ported RIBBS over to it. The Basic09 Source 
code was released. It became KRIBBS, since the MM/1 used KWindows. The 
only problem is it never was used as a BBS since about that time the 
Internet was starting become more and more accessible.
When I moved to Virginia back in 1999, I sold my MM/1 to Dave Kelly with 
all the RIBBS port on it.

John Donaldson


Dean Leiber wrote:
>
> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>
>> Yes, something like that :)
>>
>> I haven't yet found an OS-9 BBS that is public domain/open source and
>> supports multiple lines.
>> Anybody have suggestions?
>>
>> -Aaron
>
> I'm not sure about RiBBS being multi-line but the source should be 
> about, since I think they released the source at the end. I'm fairly 
> sure that the old StG BBS could do multi-line. I've seen the source 
> around and I think Scott Griepentrog OK'ed its release. Anybody 
> familiar with the other BBS'?
>
> Dean
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


-- 

From aawolfe at gmail.com  Thu Nov 19 11:57:46 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 11:57:46 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <0D44D3C0CD924ED68B13238B1DC2A4BA@speedy>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
	<e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>
	<0D44D3C0CD924ED68B13238B1DC2A4BA@speedy>
Message-ID: <e44ad6640911190857g659a27aehe0711067a14c9540@mail.gmail.com>

Making silly mistakes in an OS-9 driver tends to crash the CoCo rather
spectacularly.  If there are indeed any "hidden video modes" left in
there, I think I may have invoked them by now.

At one point I caught myself physically flinching as I pressed enter
at the end of the command to start the driver..


On Thu, Nov 19, 2009 at 6:03 AM, Bruce W. Calkins
<brucewcalkins at charter.net> wrote:
> Yes, that comment brings a smile of rememberance to my face.
> I've locked up a few computers with an endless loop or the likes.
>
> Bruce W.
>
> ==============================================
>
>
> ----- Original Message ----- From: "Aaron Wolfe"
> I've given it quite a workout in the past week, but it's solid as a
> rock so far. ?Well.. as stable as any machine can be when I'm making
> it run code that I wrote :)
>
> Thanks for the info.
> -Aaron
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Thu Nov 19 12:06:48 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 12:06:48 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <78B6829B-BE6D-41BF-AB71-0673C7C29F74@tee-boy.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<EEA43F43D1E7444B990B271C34A079E95EBAFCC707@concord.lamunet.local>
	<e44ad6640911190055l5930176bjb39769ff3f23a61c@mail.gmail.com>
	<78B6829B-BE6D-41BF-AB71-0673C7C29F74@tee-boy.com>
Message-ID: <e44ad6640911190906n4d9e0cceua892029a09c7dfe0@mail.gmail.com>

On Thu, Nov 19, 2009 at 9:32 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Aaron,
>
> Are you planning on extending the server to allow external connections from the Internet to go to your CoCo? ?It would be great if I could telnet to an address and port that you provided, which would then be used by your DriveWire server to redirect traffic to one of the 7 virtual ports on your CoCo running OS-9.
>

Yes, exactly.   I've got most of this written already.  Got derailed
last night with the netdisk idea, and will be traveling this weekend,
but should have this working next week.

-Aaron


> Boisy
>
> On Nov 19, 2009, at 2:55 AM, Aaron Wolfe wrote:
>
>> I think I will explore the option of a small fan like those found on
>> some CPU heatsinks. ?Probably have one around somewhere and it sounds
>> like the general consensus is that reducing the heat would be a good
>> thing.
>>
>> My main/dev CoCo is one I bought on ebay, premodified in a number of
>> ways, 6309 and some other handmade improvements. ?It runs very well
>> but some strange things have happened inside. ?The power button has
>> been replaced with a wire nut somehow (works fine) and the power cord
>> replaced with a heavier and 3 pronged cord. ?From these changes and
>> the newish appearance of the components in the power supply, I think
>> it may have been replaced or serviced in recent years. ?Sounds like
>> that's a good thing, if true.
>>
>> I've given it quite a workout in the past week, but it's solid as a
>> rock so far. ?Well.. as stable as any machine can be when I'm making
>> it run code that I wrote :)
>>
>> Thanks for the info.
>> -Aaron
>>
>>
>> On Wed, Nov 18, 2009 at 4:23 PM, Mike Pepe <lamune at doki-doki.net> wrote:
>>> A small fan will do wonders. The power supply is the weakest link in the chain in CoCos, reducing the temps inside will prolong the power supply's lifetime.
>>>
>>> I would also consider changing out the electrolytic filter caps in the power supply, as they do tend to dry out with age and the increasing amounts of AC ripple riding through the supply can't be good for it.
>>>
>>>> -----Original Message-----
>>>> From: coco-bounces at maltedmedia.com [mailto:coco-
>>>> bounces at maltedmedia.com] On Behalf Of Aaron Wolfe
>>>> Sent: Wednesday, November 18, 2009 12:16 PM
>>>> To: CoCoList for Color Computer Enthusiasts
>>>> Subject: [Coco] Caring for a CoCo
>>>>
>>>> Hi,
>>>>
>>>> As I've been running my development Coco quite a bit lately, I started
>>>> wondering about what is the best way to keep it running as long as
>>>> possible.
>>>> I've also considered running a Coco 24/7 as a server of sorts. ?I am
>>>> not a hardware guy, so a failed component would be a big problem for
>>>> me.
>>>>
>>>> Are there any tips for running an old Coco as "safely" as possible?
>>>> They seem to get pretty warm along the top side where the vents are,
>>>> especially my 6309/512k upgraded model. ?Would removing the shell
>>>> improve cooling? ?Possibly cutting a hole and installing a small fan?
>>>> Are the components designed well enough for 24/7 operation in general,
>>>> and does this raise any special concerns?
>>>>
>>>> Thanks for any tips
>>>> -Aaron
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Thu Nov 19 12:32:25 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 12:32:25 -0500
Subject: [Coco] OS-9 BBS (Was:  Caring for a CoCo)
Message-ID: <e44ad6640911190932n2fd619eajbe2c1684a0a9025c@mail.gmail.com>

On Thu, Nov 19, 2009 at 8:39 AM, Ron Bihler <rbihler at msn.com> wrote:
> No RiBBS is not multiline, however being OS9 it should be possible to run
> multiple copies. ?The original Coco was too slow to do much more than just
> run ribbs. In regards to source, I am still trying to put this together and
> thanks to some help I am getting we are Unpacking the packed code.
> Ron Bihler
>

Wow, I was just reading through documentation of RiBBS, and here's a
post from the man himself :)

RiBBS seems like a nice system.  Since my project would be using
virtual serial ports and internet connections, the connections work a
little differently.  While I could emulate a modem in the server, it
would be more efficient if I could just strip out all the code for
dealing with modems and let RiBBS just assume that this will be
handled elsewhere.  This is one reason why I was interested in having
the source.

Also, these days I don't think anyone would want to use uucp or
Fidonet (although I think fido does exist in some form still).  In
truth message areas as a whole would probably not be very useful these
days.  Might be able to save ram by taking out a lot of things that
were critical to a BBS back in the day, although I'd want to preserve
the "look and feel".

I thought folks might like to play a few of the old BBS door games, or
chat room type things, or just poke around in the system and remember
how things used to be.  I can't think of any real use for an OS-9 BBS
beyond the fun of reminiscing.

This makes me wonder, does anyone have an archive of a popular BBS
that they'd like to see brought back to life?  If I'm doing this to
remember the "good old days", might as well go all the way :)

-Aaron


>
> Dean Leiber wrote:
>>
>> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>>
>>> Yes, something like that :)
>>>
>>> I haven't yet found an OS-9 BBS that is public domain/open source and
>>> supports multiple lines.
>>> Anybody have suggestions?
>>>
>>> -Aaron
>>
>> I'm not sure about RiBBS being multi-line but the source should be about,
>> since I think they released the source at the end. I'm fairly sure that the
>> old StG BBS could do multi-line. I've seen the source around and I think
>> Scott Griepentrog OK'ed its release. Anybody familiar with the other BBS'?
>>
>> Dean
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Thu Nov 19 12:51:41 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 12:51:41 -0500
Subject: [Coco] DriveWire netdisk interface
Message-ID: <e44ad6640911190951s3e44f730qceb307484e412dbd@mail.gmail.com>

I've been thinking about how to enable writing to disks stored in an
internet disk repository.
I had an idea of how this could work, and wondered if you guys were
interested in something like this.

Basically, when you start DriveWire and connect to the internet disk
service, in addition to the public list of available disks each user
could have a disk image (or a set) that was writable only to them.
You could use these from the CoCo just like a regular disk.

Your user disks could be seen in the netdisk listing by other users,
they could access them in read only mode.  In this way, a Coco user
could "publish" files on their disk images and other CoCo users could
access them directly from their CoCo.  No need to download or
manipulate disk images, etc.. just attach the disk and use standard
OS-9 commands to copy them to a local disk, or even run them right
from the public image.  Sharing files between two CoCo users is as
simple as user A copies the file to their personal image, user B
mounts the same image and there it is.

I have plenty of space in a hosting center to run a public server for
this and am happy to write the code (much of it is already done) if
this would be useful to the community.

-Aaron

From mmarlette at frontiernet.net  Thu Nov 19 12:52:38 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Thu, 19 Nov 2009 17:52:38 +0000 (UTC)
Subject: [Coco] Caring for a CoCo
In-Reply-To: <1663691641.76461258649865348.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <307282751.97541258653158521.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>

Jim,

Might want to check to see how long the interface leads of the 512k are.

I have seen ones that are too long and allow the 512k board to bottom out on the motherboard, cause shorts.

There are traces that run under the CoCo's 512k expansion connectors and  the connectors DO NOT have a physical bottom or stop to them. Dumb, cheap, what ever you want to call it.

I suspecting that your homemade version is a wire wrapped model or is it a PWB board? Depending on signal routing and crosstalk of other w/w wires, this will cause this erratic operation to occur.

Mark
Cloud-9


----- Original Message -----
From: "Jim Hathaway" <kg4knb at hat3.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Thursday, November 19, 2009 9:15:32 AM GMT -06:00 US/Canada Central
Subject: Re: [Coco] Caring for a CoCo

On Thu, Nov 19, 2009 at 8:27 AM, Mark Marlette <mmarlette at frontiernet.net>wrote:

>
> Since the machine is apart. I would remove the GIME, with the proper
> tooling, a PLCC chip removal tool, and clean the leads. Soft white eraser,
> rubbed in the direction of the lead. This will ensure that you don't bend
> the lead.
>
> Materials tarnish, sockets are a HUGH reliability factor. In defense
> designs, we can't use them, nor want to for this reason.
>
> Not sure if you are using a multi-pak or not. Same applies here. Tandy did
> not use gold on their card edge connectors in the multi-paks or in the
> floppy controllers, 502 might have. My dev. system runs 24/7. Failure points
> will be in the multi-pak OR cards that DO NOT have a gold card edge. Another
> reason why ALL Cloud-9 products, that have a card edge connection, require
> that surface to be plated with gold. Thus a higher cost, but higher
> reliability = quality product.To clean the card edge connections, again use
> the white soft eraser, it won't be white for long....... :)
>
> Mark
> Cloud-9
>
>
>
Thanks for providing some more details around possible failure points.  I
have been dealing with issues from my two CoCo 3 systems in the past year or
so.  The first issue was the complete failure of a 512k memory board.  This
one drove me crazy and I spent lots of time replacing all the memory chips,
replacing caps on the board and also trying to re-flow the solder
connections on the board.  All of these steps did not help, and so in the
end there is something else that has caused this board to fail.  This board
was manufactured by Performance Peripherals.

My only working 512k board that is 'working' is a home made 512k simm board.
 However when I use this board in either of my systems and attempt to use
drivewire and boot into nitros I find that after a few minutes the system
becomes unreliable, locking up, weird characters on the screen, etc.  I
suspect the simms might be bad, but have not done extensive testing.

At this point I am not even connecting my multi-pack to my system(s) because
as you stated this is just another point of failure (all the connections).
 I figure I should be able to take just a stand alone 512k CoCo 3 boot into
nitros via drivewire and have a reliable system.

Jim





> ----- Original Message -----
> From: "Boisy G. Pitre" <boisy at tee-boy.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Wednesday, November 18, 2009 6:00:45 PM GMT -06:00 US/Canada Central
> Subject: Re: [Coco] Caring for a CoCo
>
> I would think that would be an issue with a lot of CoCos and might explain
> some of the "strangeness" that CoCo's exhibit as they get older.
>
> What would be the symptoms of this type of degradation james?
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
> On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:
>
> > On 18 Nov 2009 at 13:23, Mike Pepe wrote:
> >
> >> I would also consider changing out the electrolytic filter caps in the
> >> power supply, as they do tend to dry out with age and the increasing
> >> amounts of AC ripple riding through the supply can't be good for it.
> >
> > The electrolytics would only be a problem if the unit has sat for several
> years and not been
> > powered up. Yes the electrolytic materail tends to deform with age and no
> charge on the cap.
> > What happens then is the ESR of the cap goes way up. This reduces its
> function as a filter
> > against ripple.
> >
> > james
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

From kg4knb at hat3.net  Thu Nov 19 13:04:53 2009
From: kg4knb at hat3.net (Jim Hathaway)
Date: Thu, 19 Nov 2009 12:04:53 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <307282751.97541258653158521.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
References: <1663691641.76461258649865348.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
	<307282751.97541258653158521.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <a85805e90911191004o6190b896m6f1bd401c3b331d0@mail.gmail.com>

Mark,

I was not aware of that issue.  This board does have very long leads and
when I insert it I do tend to push rather hard to make sure I seat it really
well, this might  be the issue then.  I will look into that, very good to
know.

My SIMM board is a wirewrap special and the wires are all over the place, so
cross talk is possible too.

Thanks,

Jim Hathaway
Web: http://hat3.net


On Thu, Nov 19, 2009 at 11:52 AM, Mark Marlette
<mmarlette at frontiernet.net>wrote:

> Jim,
>
> Might want to check to see how long the interface leads of the 512k are.
>
> I have seen ones that are too long and allow the 512k board to bottom out
> on the motherboard, cause shorts.
>
> There are traces that run under the CoCo's 512k expansion connectors and
>  the connectors DO NOT have a physical bottom or stop to them. Dumb, cheap,
> what ever you want to call it.
>
> I suspecting that your homemade version is a wire wrapped model or is it a
> PWB board? Depending on signal routing and crosstalk of other w/w wires,
> this will cause this erratic operation to occur.
>
> Mark
> Cloud-9
>
>
> ----- Original Message -----
> From: "Jim Hathaway" <kg4knb at hat3.net>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Thursday, November 19, 2009 9:15:32 AM GMT -06:00 US/Canada Central
> Subject: Re: [Coco] Caring for a CoCo
>
> On Thu, Nov 19, 2009 at 8:27 AM, Mark Marlette <mmarlette at frontiernet.net
> >wrote:
>
> >
> > Since the machine is apart. I would remove the GIME, with the proper
> > tooling, a PLCC chip removal tool, and clean the leads. Soft white
> eraser,
> > rubbed in the direction of the lead. This will ensure that you don't bend
> > the lead.
> >
> > Materials tarnish, sockets are a HUGH reliability factor. In defense
> > designs, we can't use them, nor want to for this reason.
> >
> > Not sure if you are using a multi-pak or not. Same applies here. Tandy
> did
> > not use gold on their card edge connectors in the multi-paks or in the
> > floppy controllers, 502 might have. My dev. system runs 24/7. Failure
> points
> > will be in the multi-pak OR cards that DO NOT have a gold card edge.
> Another
> > reason why ALL Cloud-9 products, that have a card edge connection,
> require
> > that surface to be plated with gold. Thus a higher cost, but higher
> > reliability = quality product.To clean the card edge connections, again
> use
> > the white soft eraser, it won't be white for long....... :)
> >
> > Mark
> > Cloud-9
> >
> >
> >
> Thanks for providing some more details around possible failure points.  I
> have been dealing with issues from my two CoCo 3 systems in the past year
> or
> so.  The first issue was the complete failure of a 512k memory board.  This
> one drove me crazy and I spent lots of time replacing all the memory chips,
> replacing caps on the board and also trying to re-flow the solder
> connections on the board.  All of these steps did not help, and so in the
> end there is something else that has caused this board to fail.  This board
> was manufactured by Performance Peripherals.
>
> My only working 512k board that is 'working' is a home made 512k simm
> board.
>  However when I use this board in either of my systems and attempt to use
> drivewire and boot into nitros I find that after a few minutes the system
> becomes unreliable, locking up, weird characters on the screen, etc.  I
> suspect the simms might be bad, but have not done extensive testing.
>
> At this point I am not even connecting my multi-pack to my system(s)
> because
> as you stated this is just another point of failure (all the connections).
>  I figure I should be able to take just a stand alone 512k CoCo 3 boot into
> nitros via drivewire and have a reliable system.
>
> Jim
>
>
>
>
>
> > ----- Original Message -----
> > From: "Boisy G. Pitre" <boisy at tee-boy.com>
> > To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> > Sent: Wednesday, November 18, 2009 6:00:45 PM GMT -06:00 US/Canada
> Central
> > Subject: Re: [Coco] Caring for a CoCo
> >
> > I would think that would be an issue with a lot of CoCos and might
> explain
> > some of the "strangeness" that CoCo's exhibit as they get older.
> >
> > What would be the symptoms of this type of degradation james?
> > --
> > Boisy G. Pitre
> > http://www.tee-boy.com/
> >
> > On Nov 18, 2009, at 5:19 PM, jdaggett at gate.net wrote:
> >
> > > On 18 Nov 2009 at 13:23, Mike Pepe wrote:
> > >
> > >> I would also consider changing out the electrolytic filter caps in the
> > >> power supply, as they do tend to dry out with age and the increasing
> > >> amounts of AC ripple riding through the supply can't be good for it.
> > >
> > > The electrolytics would only be a problem if the unit has sat for
> several
> > years and not been
> > > powered up. Yes the electrolytic materail tends to deform with age and
> no
> > charge on the cap.
> > > What happens then is the ESR of the cap goes way up. This reduces its
> > function as a filter
> > > against ripple.
> > >
> > > james
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > http://five.pairlist.net/mailman/listinfo/coco
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From jmichea at cogeco.ca  Thu Nov 19 13:09:43 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Thu, 19 Nov 2009 13:09:43 -0500
Subject: [Coco]  Cloud-9 Tech
Message-ID: <000a01ca6943$7849d3b0$ecfd3918@jeremy4b3f9678>

I hope this works. I'm looking for Mark of Cloud 9 and was wondering about the status of my order. Emails seem to not be working so I hope this is ok
Thanks
Jeremy

From mmarlette at frontiernet.net  Thu Nov 19 13:12:18 2009
From: mmarlette at frontiernet.net (Mark Marlette)
Date: Thu, 19 Nov 2009 18:12:18 +0000 (UTC)
Subject: [Coco] Cloud-9 Tech
In-Reply-To: <000a01ca6943$7849d3b0$ecfd3918@jeremy4b3f9678>
Message-ID: <1773684577.103691258654338671.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>

Works here.

Must be getting blocked somewhere on my end.

Will check.

Mark
Cloud-9


----- Original Message -----
From: "Jeremy Michea" <jmichea at cogeco.ca>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Thursday, November 19, 2009 12:09:43 PM GMT -06:00 US/Canada Central
Subject: [Coco]  Cloud-9 Tech

I hope this works. I'm looking for Mark of Cloud 9 and was wondering about the status of my order. Emails seem to not be working so I hope this is ok
Thanks
Jeremy

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco

From jmichea at cogeco.ca  Thu Nov 19 13:16:00 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Thu, 19 Nov 2009 13:16:00 -0500
Subject: [Coco] Cloud-9 Tech
References: <1773684577.103691258654338671.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <001701ca6944$59449580$ecfd3918@jeremy4b3f9678>

Ok thanks Mark. Very much appreciated
Jeremy

----- Original Message ----- 
From: "Mark Marlette" <mmarlette at frontiernet.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Thursday, November 19, 2009 1:12 PM
Subject: Re: [Coco] Cloud-9 Tech


> Works here.
>
> Must be getting blocked somewhere on my end.
>
> Will check.
>
> Mark
> Cloud-9
>
>
> ----- Original Message -----
> From: "Jeremy Michea" <jmichea at cogeco.ca>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Thursday, November 19, 2009 12:09:43 PM GMT -06:00 US/Canada Central
> Subject: [Coco]  Cloud-9 Tech
>
> I hope this works. I'm looking for Mark of Cloud 9 and was wondering about 
> the status of my order. Emails seem to not be working so I hope this is ok
> Thanks
> Jeremy
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco 


From linville at tuxdriver.com  Thu Nov 19 13:43:02 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Thu, 19 Nov 2009 13:43:02 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <e44ad6640911190951s3e44f730qceb307484e412dbd@mail.gmail.com>
References: <e44ad6640911190951s3e44f730qceb307484e412dbd@mail.gmail.com>
Message-ID: <20091119184302.GC4960@tuxdriver.com>

On Thu, Nov 19, 2009 at 12:51:41PM -0500, Aaron Wolfe wrote:
> I've been thinking about how to enable writing to disks stored in an
> internet disk repository.
> I had an idea of how this could work, and wondered if you guys were
> interested in something like this.

Aaron,

I took a quick peak at your project and it seems you are using custom
server code in Perl.  That is certainly your perogative, but I was
wondering why you wouldn't just use a standard protocol like HTTP?
It would certainly ease disk image publishing.

For writing, WebDAV seems like a natural choice and using that
could/should save you from having to implement security code yourself.

Not sure about the client side implementation -- I'm sure C
libraries exist for such thing but I don't know anything about them.
Implementing the http/webdav client stuff in Perl or Python should
be simple enough as an alternative.

Well, just a thought... :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From aawolfe at gmail.com  Thu Nov 19 14:19:24 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 14:19:24 -0500
Subject: [Coco] DriveWire netdisk interface
Message-ID: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>

Hi,

I wanted to use webdav, but as far as I could tell, webdav doesn't support reading or writing specific portions of a file.  If i'm wrong about that please let me know!

To implement a disk image that "just works" with DECB and OS-9, we have to be able to read and write abitrary 256 byte sections of the file.  I wrote my own simple protocol for this because i didnt see any way to do this with http.  

-Aaron


-----Original Message-----
From: John W. Linville <linville at tuxdriver.com>
Sent: Thursday, November 19, 2009 1:43 PM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] DriveWire netdisk interface

On Thu, Nov 19, 2009 at 12:51:41PM -0500, Aaron Wolfe wrote:
> I've been thinking about how to enable writing to disks stored in an
> internet disk repository.
> I had an idea of how this could work, and wondered if you guys were
> interested in something like this.

Aaron,

I took a quick peak at your project and it seems you are using custom
server code in Perl.  That is certainly your perogative, but I was
wondering why you wouldn't just use a standard protocol like HTTP?
It would certainly ease disk image publishing.

For writing, WebDAV seems like a natural choice and using that
could/should save you from having to implement security code yourself.

Not sure about the client side implementation -- I'm sure C
libraries exist for such thing but I don't know anything about them.
Implementing the http/webdav client stuff in Perl or Python should
be simple enough as an alternative.

Well, just a thought... :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


From asa.rand at yahoo.com  Thu Nov 19 14:52:07 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Thu, 19 Nov 2009 11:52:07 -0800 (PST)
Subject: [Coco] a couple of programming questions
Message-ID: <986279.79350.qm@web53711.mail.re2.yahoo.com>

1. I am dealing with code that is only executed once in the program. It is initialization of variables, initial display, and initial data. Which of the following is better, in terms of overall execution speed of the program?

A. At the top?

Start of Program

initialize
open input file (parameter test)
read top of input file and display data
create data files

Begin processing

--or--

B. At the bottom?

Start of Program

GOSUB <lref> (to the bottom)

Begin processing

End of Program

subroutines

Bottom of program

initialize
open input file (parameter test)
read top of input file and display data
create data files
RETURN

2. I am dealing with string literals of varying lengths. Some of them use the same word or words. Example:

cRLnR:="Renumbering Line References"
cRLtR:="Renumbering Literal References"

cSLnR:="Sorting Line References"
cSLtR:="Sorting Literal References"

To reduce program size, I am putting these literals into string variables defined in the initializations, and then referenced where they go.

Would it be faster, and/or reduce code size more if I used something like:

cRen:="Renumbering"
cRef:="References"
cLine:=" Line "
cLitl:=" Literal "
cSrtg:="Sorting"

cRLnR:=cRen+cLine+cRef
cRLtR:=cRen+cLitl+cRef

cSLnR:=cSrtg+cLine+cRef
cSLtR:=cSrtg++cLitl+cRef

The strings cRLnR, cRLtR, cSLnR and cSLtR would be referenced in the code, and the concantenations would occur in the initializations. But, would it really reduce code size or increase execution speed to do it the second way? Those four strings would still be the same length, and the only thing changing is the repetition of those string literals. Also, for each "substring", 3 additional bytes are being added to the code to reference them, and that's in each place where they are used.

Wayne


      

From linville at tuxdriver.com  Thu Nov 19 15:09:50 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Thu, 19 Nov 2009 15:09:50 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
Message-ID: <20091119200950.GD4960@tuxdriver.com>

On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:

> I wanted to use webdav, but as far as I could tell, webdav doesn't
> support reading or writing specific portions of a file.  If i'm wrong
> about that please let me know!

Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...

> To implement a disk image that "just works" with DECB and OS-9,
> we have to be able to read and write abitrary 256 byte sections of
> the file.  I wrote my own simple protocol for this because i didnt
> see any way to do this with http.

Well, I do appreciate that those semantics exist between the CoCo
and the DW server.  But I don't think those semantics really need to
exist between the DW server and the backing store.  In fact, those
semantics would seem to decrease overall performance and increase the
chance of disk image corruption in the event of a failure.

I guess what I was thinking is that you would use a pull/modify/push
model, where the pull would occur when the DW server "mounted" the
image and the push would occur when a dirty image was "unmounted".
If the webdav server is worth it's salt, that should at least ensure
that so long as the DW server didn't push a corrupted image then the
webdav server images should always be correct.

Now, pull/modify/push could slow down the mount/unmount process,
but realistically how big are those Internet-based CoCo disk images
going to be? :-)

John

P.S.  Again, I'm just trying to wise and helpful. :-)  Don't let me
discourage if you don't like my advice!
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From snhirsch at gmail.com  Thu Nov 19 15:46:03 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Thu, 19 Nov 2009 15:46:03 -0500 (EST)
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <20091119200950.GD4960@tuxdriver.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
Message-ID: <alpine.DEB.2.00.0911191539120.4638@duo>

On Thu, 19 Nov 2009, John W. Linville wrote:

> On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:
>
>> I wanted to use webdav, but as far as I could tell, webdav doesn't
>> support reading or writing specific portions of a file.  If i'm wrong
>> about that please let me know!
>
> Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...
>
>> To implement a disk image that "just works" with DECB and OS-9,
>> we have to be able to read and write abitrary 256 byte sections of
>> the file.  I wrote my own simple protocol for this because i didnt
>> see any way to do this with http.
>
> Well, I do appreciate that those semantics exist between the CoCo
> and the DW server.  But I don't think those semantics really need to
> exist between the DW server and the backing store.  In fact, those
> semantics would seem to decrease overall performance and increase the
> chance of disk image corruption in the event of a failure.
>
> I guess what I was thinking is that you would use a pull/modify/push
> model, where the pull would occur when the DW server "mounted" the
> image and the push would occur when a dirty image was "unmounted".
> If the webdav server is worth it's salt, that should at least ensure
> that so long as the DW server didn't push a corrupted image then the
> webdav server images should always be correct.

If pull/modify/push is implemented, I'd suggest using optimistic lock 
semantics.  For example:

- Before pulling the remote copy, obtain a CRC, file timestamp or 
(preferably) both.

- Have your way with the local copy.

- Before writing back the local copy, read the remote CRC and timestamp 
again.  If this information does not match what you read earlier, then 
your optimistic lock failed, i.e. someone else modified it in the 
meantime.  You'll then have to decide semantics: do you warn and allow 
overwriting?  Do you create a versioned copy?  Etc, etc.

Just my 0.02.

Steve


-- 

From linville at tuxdriver.com  Thu Nov 19 16:30:22 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Thu, 19 Nov 2009 16:30:22 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <alpine.DEB.2.00.0911191539120.4638@duo>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<alpine.DEB.2.00.0911191539120.4638@duo>
Message-ID: <20091119213022.GG4960@tuxdriver.com>

On Thu, Nov 19, 2009 at 03:46:03PM -0500, Steven Hirsch wrote:

> If pull/modify/push is implemented, I'd suggest using optimistic lock  
> semantics.  For example:
>
> - Before pulling the remote copy, obtain a CRC, file timestamp or  
> (preferably) both.
>
> - Have your way with the local copy.
>
> - Before writing back the local copy, read the remote CRC and timestamp  
> again.  If this information does not match what you read earlier, then  
> your optimistic lock failed, i.e. someone else modified it in the  
> meantime.  You'll then have to decide semantics: do you warn and allow  
> overwriting?  Do you create a versioned copy?  Etc, etc.
>
> Just my 0.02.

Yes that sounds reasonable (unless webdav already has some useful
locking -- no idea).

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From brucewcalkins at charter.net  Thu Nov 19 16:47:30 2009
From: brucewcalkins at charter.net (Bruce W. Calkins)
Date: Thu, 19 Nov 2009 16:47:30 -0500
Subject: [Coco] Caring for a CoCo
References: <307282751.97541258653158521.JavaMail.root@cl04-host03.roch.ny.frontiernet.net>
Message-ID: <834D94F4881A463682AB345AD89F95EC@speedy>

Thanks Mark,

I have a Performance Peripherals memory upgrade board that blew the 6809 on 
a CoCo 3.  I'll check the pins.   FWIW; I pulled the chip and put in a 
socket, which will hold a 1 meg interface, a protector and eventualy a 6309.

Bruce W.

==============================


----- Original Message ----- 
From: "Mark Marlette"

> Jim,
>
> Might want to check to see how long the interface leads of the 512k are.
>
> I have seen ones that are too long and allow the 512k board to bottom out 
> on the motherboard, cause shorts.
>
> There are traces that run under the CoCo's 512k expansion connectors and 
> the connectors DO NOT have a physical bottom or stop to them. Dumb, cheap, 
> what ever you want to call it.
>
> I suspecting that your homemade version is a wire wrapped model or is it a 
> PWB board? Depending on signal routing and crosstalk of other w/w wires, 
> this will cause this erratic operation to occur.
>
> Mark
> Cloud-9
>
>
> ----- Original Message -----
> From: "Jim Hathaway"
>
> Thanks for providing some more details around possible failure points.  I
> have been dealing with issues from my two CoCo 3 systems in the past year 
> or
> so.  The first issue was the complete failure of a 512k memory board. 
> This
> one drove me crazy and I spent lots of time replacing all the memory 
> chips,
> replacing caps on the board and also trying to re-flow the solder
> connections on the board.  All of these steps did not help, and so in the
> end there is something else that has caused this board to fail.  This 
> board
> was manufactured by Performance Peripherals.
>
> Jim 


From aawolfe at gmail.com  Thu Nov 19 17:15:44 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 17:15:44 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <20091119200950.GD4960@tuxdriver.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
Message-ID: <e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>

On Thu, Nov 19, 2009 at 3:09 PM, John W. Linville
<linville at tuxdriver.com> wrote:
> On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:
>
>> I wanted to use webdav, but as far as I could tell, webdav doesn't
>> support reading or writing specific portions of a file. ?If i'm wrong
>> about that please let me know!
>
> Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...
>
>> To implement a disk image that "just works" with DECB and OS-9,
>> we have to be able to read and write abitrary 256 byte sections of
>> the file. ?I wrote my own simple protocol for this because i didnt
>> see any way to do this with http.
>
> Well, I do appreciate that those semantics exist between the CoCo
> and the DW server. ?But I don't think those semantics really need to
> exist between the DW server and the backing store. ?In fact, those
> semantics would seem to decrease overall performance and increase the
> chance of disk image corruption in the event of a failure.
>
> I guess what I was thinking is that you would use a pull/modify/push
> model, where the pull would occur when the DW server "mounted" the
> image and the push would occur when a dirty image was "unmounted".
> If the webdav server is worth it's salt, that should at least ensure
> that so long as the DW server didn't push a corrupted image then the
> webdav server images should always be correct.
>

I had thought about this model.  webdav would certainly support
transfering entire images back and forth, and using webdav would make
lots of other things work nicely.

the only drawback I see is that changes written to the disk are lost
unless the "unmount" process is completed.  this requires the user to
take an extra step in the drivewire server, makes netdisks work a
little differently than regular disk images.  this is why I went with
the original design.  however, webdav does have some compelling
advantages and probably is a better way to do things.  I will look at
adapting to this model.


> Now, pull/modify/push could slow down the mount/unmount process,
> but realistically how big are those Internet-based CoCo disk images
> going to be? :-)

depending on the internet connection, might be almost no delay, or
maybe up to a minute or so, i doubt it's too much of an issue.  means
some additional logic in the DW server since disks are not immediately
available once selected like they are now.

overall, using webdav is probably the right way to do it.

>
> John
>
> P.S. ?Again, I'm just trying to wise and helpful. :-) ?Don't let me
> discourage if you don't like my advice!
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From farna at att.net  Thu Nov 19 17:52:24 2009
From: farna at att.net (Frank Swygert)
Date: Thu, 19 Nov 2009 17:52:24 -0500
Subject: [Coco] Caring for a CoCo
Message-ID: <4B05CC28.8090602@att.net>

I recall some of the boards having a piece of heat shrink or some other plastic tubing over two pins, one in each corner, to prevent pushing in too far. You might try that! 

---------
Date: Thu, 19 Nov 2009 12:04:53 -0600
From: Jim Hathaway <kg4knb at hat3.net>

Mark,
I was not aware of that issue.  This board does have very long leads and
when I insert it I do tend to push rather hard to make sure I seat it really
well, this might  be the issue then.  I will look into that, very good to
know.

-- 
Frank Swygert
Publisher, "American Motors Cars" 
Magazine (AMC)
For all AMC enthusiasts
http://farna.home.att.net/AMC.html
(free download available!)


From aawolfe at gmail.com  Thu Nov 19 18:04:12 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 18:04:12 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
Message-ID: <e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>

I did a few tests with fusedav and apache just now.  Seems to work
pretty OK just to mount a DAV share in your local filesystem, then use
regular DriveWire to give an image on that share to the CoCo.  Maybe
some excessive read/writes (and the entire disk image each time),  and
had a couple weird things happen, but probably more of issues with
fusedav, apache, or just the way DriveWire talks to the local disk.
Probably could be optimized.

So.. as it turns out, there is really no point in having netdisk,
since you can just do this with exisiting tools :)

It would be nice to have a public repo of disk images accessible via
webdav, though.

-Aaron



On Thu, Nov 19, 2009 at 5:15 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Thu, Nov 19, 2009 at 3:09 PM, John W. Linville
> <linville at tuxdriver.com> wrote:
>> On Thu, Nov 19, 2009 at 02:19:24PM -0500, Aaron Wolfe wrote:
>>
>>> I wanted to use webdav, but as far as I could tell, webdav doesn't
>>> support reading or writing specific portions of a file. ?If i'm wrong
>>> about that please let me know!
>>
>> Hmmm, I wasn't aware of that -- FWIW I'm more of a kernel guy...
>>
>>> To implement a disk image that "just works" with DECB and OS-9,
>>> we have to be able to read and write abitrary 256 byte sections of
>>> the file. ?I wrote my own simple protocol for this because i didnt
>>> see any way to do this with http.
>>
>> Well, I do appreciate that those semantics exist between the CoCo
>> and the DW server. ?But I don't think those semantics really need to
>> exist between the DW server and the backing store. ?In fact, those
>> semantics would seem to decrease overall performance and increase the
>> chance of disk image corruption in the event of a failure.
>>
>> I guess what I was thinking is that you would use a pull/modify/push
>> model, where the pull would occur when the DW server "mounted" the
>> image and the push would occur when a dirty image was "unmounted".
>> If the webdav server is worth it's salt, that should at least ensure
>> that so long as the DW server didn't push a corrupted image then the
>> webdav server images should always be correct.
>>
>
> I had thought about this model. ?webdav would certainly support
> transfering entire images back and forth, and using webdav would make
> lots of other things work nicely.
>
> the only drawback I see is that changes written to the disk are lost
> unless the "unmount" process is completed. ?this requires the user to
> take an extra step in the drivewire server, makes netdisks work a
> little differently than regular disk images. ?this is why I went with
> the original design. ?however, webdav does have some compelling
> advantages and probably is a better way to do things. ?I will look at
> adapting to this model.
>
>
>> Now, pull/modify/push could slow down the mount/unmount process,
>> but realistically how big are those Internet-based CoCo disk images
>> going to be? :-)
>
> depending on the internet connection, might be almost no delay, or
> maybe up to a minute or so, i doubt it's too much of an issue. ?means
> some additional logic in the DW server since disks are not immediately
> available once selected like they are now.
>
> overall, using webdav is probably the right way to do it.
>
>>
>> John
>>
>> P.S. ?Again, I'm just trying to wise and helpful. :-) ?Don't let me
>> discourage if you don't like my advice!
>> --
>> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
>> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>

From operator at coco3.com  Thu Nov 19 20:01:05 2009
From: operator at coco3.com (Roger Taylor)
Date: Thu, 19 Nov 2009 19:01:05 -0600
Subject: [Coco] DriveWire netdisks
In-Reply-To: <e44ad6640911182158r54702deahb46760768ed4cfeb@mail.gmail.co
 m>
References: <e44ad6640911182158r54702deahb46760768ed4cfeb@mail.gmail.com>
Message-ID: <6.2.5.6.1.20091119183132.05e042f0@coco3.com>

At 11:58 PM 11/18/2009, you wrote:
>I just put together another "proof of concept" type hack for
>DriveWire.  This modification allows you to attach disk images to your
>CoCo that are located on another server, using TCP.   I just booted my
>CoCo off an image on my web server which is in Dallas TX, my Coco and
>I live in south Florida.  Pretty cool :)
>
>The repository provides a listing of available disk images and their
>description (in the future this could be done better or with more
>detail).  Choose a name from the list, and it's instantly "in the
>drive" of your CoCo.  Current version only allows reading the disks,
>but maybe something could be worked out to allow
>controlled/protected/authenticated/etc writing to the images as well.
>
>If anyone wants to play hunt the bugs with this, I put the initial
>code on my coco project page at http://aaronwolfe.com/coco
>
>-Aaron

Ya got a lot of catching up to do there, Aaron.  :)

-- 
~ Roger Taylor



From aawolfe at gmail.com  Thu Nov 19 20:31:50 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 20:31:50 -0500
Subject: [Coco] DriveWire netdisks
In-Reply-To: <6.2.5.6.1.20091119183132.05e042f0@coco3.com>
References: <e44ad6640911182158r54702deahb46760768ed4cfeb@mail.gmail.com>
	<6.2.5.6.1.20091119183132.05e042f0@coco3.com>
Message-ID: <e44ad6640911191731ydcececek145a1df3ed88be32@mail.gmail.com>

On Thu, Nov 19, 2009 at 8:01 PM, Roger Taylor <operator at coco3.com> wrote:
> At 11:58 PM 11/18/2009, you wrote:
>>
>> I just put together another "proof of concept" type hack for
>> DriveWire. ?This modification allows you to attach disk images to your
>> CoCo that are located on another server, using TCP. ? I just booted my
>> CoCo off an image on my web server which is in Dallas TX, my Coco and
>> I live in south Florida. ?Pretty cool :)
>>
>> The repository provides a listing of available disk images and their
>> description (in the future this could be done better or with more
>> detail). ?Choose a name from the list, and it's instantly "in the
>> drive" of your CoCo. ?Current version only allows reading the disks,
>> but maybe something could be worked out to allow
>> controlled/protected/authenticated/etc writing to the images as well.
>>
>> If anyone wants to play hunt the bugs with this, I put the initial
>> code on my coco project page at http://aaronwolfe.com/coco
>>
>> -Aaron
>
> Ya got a lot of catching up to do there, Aaron. ?:)
>
> --
> ~ Roger Taylor
>

I think I'll be abandoning the network portion of this idea, since
WebDAV can accomplish basically the same thing and file system level
support is available on all the target platforms already.  Also, using
a webdav model makes the images just as easily usable by people
running in emulators.

I am still interested in a public collection of disks images, with an
easy way to share disk images between users. Some way to categorize
them would be nice too.  I'm guessing there is a good way to do all
that with just a web site/webdav combination.

-Aaron


>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From rbihler at msn.com  Thu Nov 19 20:32:13 2009
From: rbihler at msn.com (Ron Bihler)
Date: Thu, 19 Nov 2009 18:32:13 -0700
Subject: [Coco] Caring for a CoCo
In-Reply-To: <4B057777.7070603@sbcglobal.net>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>
	<4B057777.7070603@sbcglobal.net>
Message-ID: <BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>

I have not been able to locate even the mm1 port of RiBBS. 

Thanks
Ron


John Donaldson wrote:
> When the MM/1 came out, I ported RIBBS over to it. The Basic09 Source 
> code was released. It became KRIBBS, since the MM/1 used KWindows. The 
> only problem is it never was used as a BBS since about that time the 
> Internet was starting become more and more accessible.
> When I moved to Virginia back in 1999, I sold my MM/1 to Dave Kelly 
> with all the RIBBS port on it.
>
> John Donaldson
>
>
> Dean Leiber wrote:
>>
>> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>>
>>> Yes, something like that :)
>>>
>>> I haven't yet found an OS-9 BBS that is public domain/open source and
>>> supports multiple lines.
>>> Anybody have suggestions?
>>>
>>> -Aaron
>>
>> I'm not sure about RiBBS being multi-line but the source should be 
>> about, since I think they released the source at the end. I'm fairly 
>> sure that the old StG BBS could do multi-line. I've seen the source 
>> around and I think Scott Griepentrog OK'ed its release. Anybody 
>> familiar with the other BBS'?
>>
>> Dean
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
>

From rbihler at msn.com  Thu Nov 19 21:01:51 2009
From: rbihler at msn.com (Ron Bihler)
Date: Thu, 19 Nov 2009 19:01:51 -0700
Subject: [Coco] OS-9 BBS (Was:  Caring for a CoCo)
In-Reply-To: <e44ad6640911190932n2fd619eajbe2c1684a0a9025c@mail.gmail.com>
References: <e44ad6640911190932n2fd619eajbe2c1684a0a9025c@mail.gmail.com>
Message-ID: <BLU0-SMTP1673DC4E4311424356BC3FAFA10@phx.gbl>

Thanks, for the time it was a pretty advanced system and it was also 
said it was not possible for a Coco to connect (Properly) into the 
Fidonet.  Did that and pretty well (However slow)
Those days are gone and due to a broken pipe I lost all the source code 
for RiBBS.  I have been working to recreate the source, but this is a 
long process that Wayne Campbell has taken on.  I have a few bread 
crumbs for people that had the code when I left the community to start a 
family, so far not luck finding the source.  I believe Fido is dead, the 
last few system I have found don't appear to up.  RiBBS without much of 
the Fido stuff would be smaller, also thing that ribbs does is allow os9 
color coding to be sent in addtion to standard ascii and VT codes.  This 
did slow the system down to convert to/from these different code types. 

I agree not much use for BBS other than a walk down memory lane and 
curiosity, I have located a possible server for the PC side to allow a 
basic Telnet connection to a BBS such as RiBBS.  I plan to attempt this 
at some point but have not had the time.  www.telbbs.com is the site.  
It will emulate a modem and should work very well with RiBBS.  I believe 
it even handles the Carrier detect line. 

As I am able to recreate the source and HOPEFULLY find it I plan to post 
it for anyone interested. 

Enjoy.
Ron


Aaron Wolfe wrote:
> On Thu, Nov 19, 2009 at 8:39 AM, Ron Bihler <rbihler at msn.com> wrote:
>   
>> No RiBBS is not multiline, however being OS9 it should be possible to run
>> multiple copies.  The original Coco was too slow to do much more than just
>> run ribbs. In regards to source, I am still trying to put this together and
>> thanks to some help I am getting we are Unpacking the packed code.
>> Ron Bihler
>>
>>     
>
> Wow, I was just reading through documentation of RiBBS, and here's a
> post from the man himself :)
>
> RiBBS seems like a nice system.  Since my project would be using
> virtual serial ports and internet connections, the connections work a
> little differently.  While I could emulate a modem in the server, it
> would be more efficient if I could just strip out all the code for
> dealing with modems and let RiBBS just assume that this will be
> handled elsewhere.  This is one reason why I was interested in having
> the source.
>
> Also, these days I don't think anyone would want to use uucp or
> Fidonet (although I think fido does exist in some form still).  In
> truth message areas as a whole would probably not be very useful these
> days.  Might be able to save ram by taking out a lot of things that
> were critical to a BBS back in the day, although I'd want to preserve
> the "look and feel".
>
> I thought folks might like to play a few of the old BBS door games, or
> chat room type things, or just poke around in the system and remember
> how things used to be.  I can't think of any real use for an OS-9 BBS
> beyond the fun of reminiscing.
>
> This makes me wonder, does anyone have an archive of a popular BBS
> that they'd like to see brought back to life?  If I'm doing this to
> remember the "good old days", might as well go all the way :)
>
> -Aaron
>
>
>   
>> Dean Leiber wrote:
>>     
>>> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>>       
>>>> Yes, something like that :)
>>>>
>>>> I haven't yet found an OS-9 BBS that is public domain/open source and
>>>> supports multiple lines.
>>>> Anybody have suggestions?
>>>>
>>>> -Aaron
>>>>         
>>> I'm not sure about RiBBS being multi-line but the source should be about,
>>> since I think they released the source at the end. I'm fairly sure that the
>>> old StG BBS could do multi-line. I've seen the source around and I think
>>> Scott Griepentrog OK'ed its release. Anybody familiar with the other BBS'?
>>>
>>> Dean
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>>       
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>     
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>   

From daveekelly1 at embarqmail.com  Thu Nov 19 21:28:20 2009
From: daveekelly1 at embarqmail.com (Dave Kelly)
Date: Thu, 19 Nov 2009 20:28:20 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>	<4B057777.7070603@sbcglobal.net>
	<BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>
Message-ID: <4B05FEC4.1060106@embarqmail.com>

Ron Bihler wrote:
> I have not been able to locate even the mm1 port of RiBBS.
> Thanks
Lets see if I can jog some memories. It was the time I got the video 
working and broadcast it over the internet.

I had a corner table in the far right hand corner ( coming from the 
lobby ). On that table was a 5-/12 inch disk box with a lock and key.
Clear plastic cover and RS beige bottom. I sat on the left hand end of 
the table next to John's MM/1. I seem to remember giving the box of 
disks or something to Mark M (not sure).

Anybody remember anything?
Dave

-- 
I came, I cast, I kicked Bass.

From rbihler at msn.com  Thu Nov 19 22:36:28 2009
From: rbihler at msn.com (Ron Bihler)
Date: Thu, 19 Nov 2009 20:36:28 -0700
Subject: [Coco] Caring for a CoCo
In-Reply-To: <4B05FEC4.1060106@embarqmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>	<4B057777.7070603@sbcglobal.net>	<BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>
	<4B05FEC4.1060106@embarqmail.com>
Message-ID: <BLU0-SMTP44475A98E5BE4061964E11AFA10@phx.gbl>

I have tracked down Charles West who took over RiBBS and released the 
last version.  He may have hard copies but has not found them yet.  Also 
Erik Van Trump in Canada thinks he has a copy buried someplace, but this 
is coming close to 20 years and the likely hood keeps dropping. 

I still have hope, Wayne is really making some progress and has taken 
this on as a personal challenge.  The variety of options I used in the 
making of RiBBS, plus all the data structures has helped Wayne in 
understanding on the packed code.  Still no variable names, but thanks 
to some documentation that is helping and it's starting to look readable 
again.  After this long, it;s scary that I am starting to recognize the 
and remember some of the things I did. 

It's been fun and a great goose hunt.

Ron Bihler

Dave Kelly wrote:
> Ron Bihler wrote:
>> I have not been able to locate even the mm1 port of RiBBS.
>> Thanks
> Lets see if I can jog some memories. It was the time I got the video 
> working and broadcast it over the internet.
>
> I had a corner table in the far right hand corner ( coming from the 
> lobby ). On that table was a 5-/12 inch disk box with a lock and key.
> Clear plastic cover and RS beige bottom. I sat on the left hand end of 
> the table next to John's MM/1. I seem to remember giving the box of 
> disks or something to Mark M (not sure).
>
> Anybody remember anything?
> Dave
>

From robert.gault at worldnet.att.net  Thu Nov 19 22:39:56 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Thu, 19 Nov 2009 22:39:56 -0500
Subject: [Coco] a couple of programming questions
In-Reply-To: <986279.79350.qm@web53711.mail.re2.yahoo.com>
References: <986279.79350.qm@web53711.mail.re2.yahoo.com>
Message-ID: <4B060F8C.2080101@worldnet.att.net>

Wayne Campbell wrote:
> 1. I am dealing with code that is only executed once in the program. It is initialization of variables, initial display, and initial data. Which of the following is better, in terms of overall execution speed of the program?
>
 >snip

Any program using subroutines is slower than the same program not using 
them. Of course, it will also be larger. You will need to decide whether 
the larger size is more important than a slightly slower speed in the 
smaller program or if the change in speed is even noticeable.

> 2. I am dealing with string literals of varying lengths. Some of them use the same word or words. Example:
>

This is really the same type of question. Which version uses the least 
memory and how important is that? Which version is faster and is the 
difference noticeable? Is the added complexity of concatenation of small 
strings worth the effort verses any potential decrease in program size?

From georgeramsower at gmail.com  Thu Nov 19 23:02:57 2009
From: georgeramsower at gmail.com (George Ramsower)
Date: Thu, 19 Nov 2009 22:02:57 -0600
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com><002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE><20091119004302.GC5630@tuxdriver.com>
	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
Message-ID: <003401ca6996$58889f40$6401a8c0@OLDGEORGE>

I haven't yet found an OS-9 BBS that is public domain/open source and
supports multiple lines.
Anybody have suggestions?

-Aaron
--------------------------------------------

 I have the "OS9 L2 BBS" which does support multiple lines. I can't remember who wrote this and right now, I can't find the manual that came with it. I do remember the manual had a green cover. I'm certain that someone here will remember the author.
 When I set this up years ago, I was impressed at how fast it was. Back then, it was considered very fast, even when running from floppies. 
 It was written totally within OS9 rules(so I read somewhere, or dreamed it). Used tiny modules to get the job done and worked well for me..... considering ... at the time, I couldn't get any interest. I could use a comm program, dial out to the other modem and log in to the BBS and operate it that way. Using a window to emulate another user, I could chat with myself as if there were more than one user online.
 Perhaps, when we find the author, we might even get permission to use it as freeware or public domain or whatever terminology is used to say.... "Go ahead and use it. Just don't try to make money on it."

If we get permission, I'll happily make this available to everyone.

George

 My CNC coco..
http://coco.thetinbox.com/

From cwgordon at carolina.rr.com  Thu Nov 19 23:06:34 2009
From: cwgordon at carolina.rr.com (Bill)
Date: Thu, 19 Nov 2009 23:06:34 -0500
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
In-Reply-To: <003401ca6996$58889f40$6401a8c0@OLDGEORGE>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com><002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE><20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<003401ca6996$58889f40$6401a8c0@OLDGEORGE>
Message-ID: <000001ca6996$d9e031c0$8da09540$@rr.com>

I ran that same BBS for several years in the early to mid 90s. Would LOVE to
be able to set another board back up using drivewire instead of the dual
20Mb Seagate MFM drives I had. (But I don't know if I COULD set it back up
-=brain dead, ya know=-)

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of George Ramsower
Sent: Thursday, November 19, 2009 11:03 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Multiple line OS9 BBS was Caring for a CoCo

I haven't yet found an OS-9 BBS that is public domain/open source and
supports multiple lines.
Anybody have suggestions?

-Aaron
--------------------------------------------

 I have the "OS9 L2 BBS" which does support multiple lines. I can't remember
who wrote this and right now, I can't find the manual that came with it. I
do remember the manual had a green cover. I'm certain that someone here will
remember the author.
 When I set this up years ago, I was impressed at how fast it was. Back
then, it was considered very fast, even when running from floppies. 
 It was written totally within OS9 rules(so I read somewhere, or dreamed
it). Used tiny modules to get the job done and worked well for me.....
considering ... at the time, I couldn't get any interest. I could use a comm
program, dial out to the other modem and log in to the BBS and operate it
that way. Using a window to emulate another user, I could chat with myself
as if there were more than one user online.
 Perhaps, when we find the author, we might even get permission to use it as
freeware or public domain or whatever terminology is used to say.... "Go
ahead and use it. Just don't try to make money on it."

If we get permission, I'll happily make this available to everyone.

George

 My CNC coco..
http://coco.thetinbox.com/

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


__________ NOD32 4618 (20091118) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



From aawolfe at gmail.com  Thu Nov 19 23:25:35 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Thu, 19 Nov 2009 23:25:35 -0500
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
In-Reply-To: <000001ca6996$d9e031c0$8da09540$@rr.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
	<20091119004302.GC5630@tuxdriver.com>
	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<003401ca6996$58889f40$6401a8c0@OLDGEORGE>
	<000001ca6996$d9e031c0$8da09540$@rr.com>
Message-ID: <e44ad6640911192025t7c58325aka0a18403f8da1c46@mail.gmail.com>

Well we are one step closer to making that easy to do :)

I just finished up the getstat routines in the drivewire serial device
driver.   You can now run a communications program in OS-9 (I'm using
Supercomm) and communicate using the virtual ports to the pty on the
drivewire server host.  If I ran one of the internet modem type
programs there, I could "dial" out via telnet to one of the BBSes
available on the internet.  Still haven't found a suitable program for
this part (open source, open language i.e. not VB).  Writing one is
not difficult, might whip something up tonight.

-Aaron

On Thu, Nov 19, 2009 at 11:06 PM, Bill <cwgordon at carolina.rr.com> wrote:
> I ran that same BBS for several years in the early to mid 90s. Would LOVE to
> be able to set another board back up using drivewire instead of the dual
> 20Mb Seagate MFM drives I had. (But I don't know if I COULD set it back up
> -=brain dead, ya know=-)
>
> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
> Behalf Of George Ramsower
> Sent: Thursday, November 19, 2009 11:03 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Multiple line OS9 BBS was Caring for a CoCo
>
> I haven't yet found an OS-9 BBS that is public domain/open source and
> supports multiple lines.
> Anybody have suggestions?
>
> -Aaron
> --------------------------------------------
>
> ?I have the "OS9 L2 BBS" which does support multiple lines. I can't remember
> who wrote this and right now, I can't find the manual that came with it. I
> do remember the manual had a green cover. I'm certain that someone here will
> remember the author.
> ?When I set this up years ago, I was impressed at how fast it was. Back
> then, it was considered very fast, even when running from floppies.
> ?It was written totally within OS9 rules(so I read somewhere, or dreamed
> it). Used tiny modules to get the job done and worked well for me.....
> considering ... at the time, I couldn't get any interest. I could use a comm
> program, dial out to the other modem and log in to the BBS and operate it
> that way. Using a window to emulate another user, I could chat with myself
> as if there were more than one user online.
> ?Perhaps, when we find the author, we might even get permission to use it as
> freeware or public domain or whatever terminology is used to say.... "Go
> ahead and use it. Just don't try to make money on it."
>
> If we get permission, I'll happily make this available to everyone.
>
> George
>
> ?My CNC coco..
> http://coco.thetinbox.com/
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
> __________ NOD32 4618 (20091118) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From curtisboyle at sasktel.net  Fri Nov 20 01:26:30 2009
From: curtisboyle at sasktel.net (L. Curtis Boyle)
Date: Fri, 20 Nov 2009 00:26:30 -0600
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
In-Reply-To: <003401ca6996$58889f40$6401a8c0@OLDGEORGE>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
	<20091119004302.GC5630@tuxdriver.com>
	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<003401ca6996$58889f40$6401a8c0@OLDGEORGE>
Message-ID: <BDC31F5E-1D79-4CD6-BDD1-155986C40BC9@sasktel.net>

If it's the same one I had, it is from Alpha Software Technolgies, and  
written by Keith Alphonso.

Sent from my iPhone
L. Curtis Boyle


On Nov 19, 2009, at 10:02 PM, George Ramsower  
<georgeramsower at gmail.com> wrote:

> I haven't yet found an OS-9 BBS that is public domain/open source and
> supports multiple lines.
> Anybody have suggestions?
>
> -Aaron
> --------------------------------------------
>
> I have the "OS9 L2 BBS" which does support multiple lines. I can't  
> remember who wrote this and right now, I can't find the manual that  
> came with it. I do remember the manual had a green cover. I'm  
> certain that someone here will remember the author.
> When I set this up years ago, I was impressed at how fast it was.  
> Back then, it was considered very fast, even when running from  
> floppies.
> It was written totally within OS9 rules(so I read somewhere, or  
> dreamed it). Used tiny modules to get the job done and worked well  
> for me..... considering ... at the time, I couldn't get any  
> interest. I could use a comm program, dial out to the other modem  
> and log in to the BBS and operate it that way. Using a window to  
> emulate another user, I could chat with myself as if there were more  
> than one user online.
> Perhaps, when we find the author, we might even get permission to  
> use it as freeware or public domain or whatever terminology is used  
> to say.... "Go ahead and use it. Just don't try to make money on it."
>
> If we get permission, I'll happily make this available to everyone.
>
> George
>
> My CNC coco..
> http://coco.thetinbox.com/
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

From aawolfe at gmail.com  Fri Nov 20 01:41:28 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 20 Nov 2009 01:41:28 -0500
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
In-Reply-To: <e44ad6640911192025t7c58325aka0a18403f8da1c46@mail.gmail.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>
	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>
	<20091119004302.GC5630@tuxdriver.com>
	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<003401ca6996$58889f40$6401a8c0@OLDGEORGE>
	<000001ca6996$d9e031c0$8da09540$@rr.com>
	<e44ad6640911192025t7c58325aka0a18403f8da1c46@mail.gmail.com>
Message-ID: <e44ad6640911192241x2c76c535w7ebcc6527380276c@mail.gmail.com>

Yet another step, I wrote a quick and dirty pty <-> tcp util that
understands the ATD command, and I just logged into a BBS over the
internet with my CoCo.

For me, this is the first time I've ever used a CoCo to connect to a
BBS, back in the day we did not have a modem (or disk drives).
There are actually quite a few BBSes still running and accessible via
telnet.  Supercomm seems to do a decent job of rendering the ANSI
colors and screen controls.  Now I've really got to get the SERREADM
function implemented, 10 characters per second is not good!

-Aaron


On Thu, Nov 19, 2009 at 11:25 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> Well we are one step closer to making that easy to do :)
>
> I just finished up the getstat routines in the drivewire serial device
> driver. ? You can now run a communications program in OS-9 (I'm using
> Supercomm) and communicate using the virtual ports to the pty on the
> drivewire server host. ?If I ran one of the internet modem type
> programs there, I could "dial" out via telnet to one of the BBSes
> available on the internet. ?Still haven't found a suitable program for
> this part (open source, open language i.e. not VB). ?Writing one is
> not difficult, might whip something up tonight.
>
> -Aaron
>
> On Thu, Nov 19, 2009 at 11:06 PM, Bill <cwgordon at carolina.rr.com> wrote:
>> I ran that same BBS for several years in the early to mid 90s. Would LOVE to
>> be able to set another board back up using drivewire instead of the dual
>> 20Mb Seagate MFM drives I had. (But I don't know if I COULD set it back up
>> -=brain dead, ya know=-)
>>
>> -----Original Message-----
>> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
>> Behalf Of George Ramsower
>> Sent: Thursday, November 19, 2009 11:03 PM
>> To: CoCoList for Color Computer Enthusiasts
>> Subject: Re: [Coco] Multiple line OS9 BBS was Caring for a CoCo
>>
>> I haven't yet found an OS-9 BBS that is public domain/open source and
>> supports multiple lines.
>> Anybody have suggestions?
>>
>> -Aaron
>> --------------------------------------------
>>
>> ?I have the "OS9 L2 BBS" which does support multiple lines. I can't remember
>> who wrote this and right now, I can't find the manual that came with it. I
>> do remember the manual had a green cover. I'm certain that someone here will
>> remember the author.
>> ?When I set this up years ago, I was impressed at how fast it was. Back
>> then, it was considered very fast, even when running from floppies.
>> ?It was written totally within OS9 rules(so I read somewhere, or dreamed
>> it). Used tiny modules to get the job done and worked well for me.....
>> considering ... at the time, I couldn't get any interest. I could use a comm
>> program, dial out to the other modem and log in to the BBS and operate it
>> that way. Using a window to emulate another user, I could chat with myself
>> as if there were more than one user online.
>> ?Perhaps, when we find the author, we might even get permission to use it as
>> freeware or public domain or whatever terminology is used to say.... "Go
>> ahead and use it. Just don't try to make money on it."
>>
>> If we get permission, I'll happily make this available to everyone.
>>
>> George
>>
>> ?My CNC coco..
>> http://coco.thetinbox.com/
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> __________ NOD32 4618 (20091118) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>

From asa.rand at yahoo.com  Fri Nov 20 02:10:30 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Thu, 19 Nov 2009 23:10:30 -0800 (PST)
Subject: [Coco] a couple of programming questions
In-Reply-To: <4B060F8C.2080101@worldnet.att.net>
References: <986279.79350.qm@web53711.mail.re2.yahoo.com>
	<4B060F8C.2080101@worldnet.att.net>
Message-ID: <934244.80719.qm@web53710.mail.re2.yahoo.com>

Robert Gault wrote:
>Any program using subroutines

This is true, however there are the following considerations. Everything involved in this is together, and will only be executed once. In addition, in Basic09, and while I don't know the exact machine instructions involved, subroutining the code will only add 4 bytes to the code, the GOSUB token and offset integer where the branch occurs, and the RETURN token at the end of the subroutine. Since the code is only executed once, I don't think it will appreciably slow the program as a whole down.

I guess it won't matter where the code is located, unless moving it to the bottom will somehow increase the execution of the rest of the code by its closer proximity to the execution offset.


>This is really the same type of question.

I have been doing some work on string building. I have a number of different strings for display which share words, and a large number of format strings for print using that contain repetitions of the same elements, such as:

"s8>,i5>,s9>,i5>,s11>,i5>,s9>,i5>"

I reduced the elements to separate variables, then used concatenation to build larger segments, and eventually the full format strings.

Between the display strings and format strings, I have created about 200 variables. As decode stands now, without modifying it with these changes, it contains 203 program variables, using 2065 references in the code. I'm not certain that adding 200 more variables, and probably another few-hundred references, is going to speed anything up. The only thing I'm certain about is that each place that has a long or complicated string literal would be replaced with a reference to a single variable. While this seems like it should speed things up, I have to wonder how much time will be spent in initialization building those strings. Then there is the variables themselves. In addition to the increase in data space requirements, all of those 3-byte references are going to add up. I'm not sure if decode will be any smaller, or if it will be larger.

I'm going to test a version of decode with all of the changes/additions to see what it does. I'll report back with some results in the next day or 2.

Wayne



________________________________
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Thu, November 19, 2009 7:39:56 PM
Subject: Re: [Coco] a couple of programming questions

Wayne Campbell wrote:
> 1. I am dealing with code that is only executed once in the program. It is initialization of variables, initial display, and initial data. Which of the following is better, in terms of overall execution speed of the program?
> 
>snip

Any program using subroutines is slower than the same program not using them. Of course, it will also be larger. You will need to decide whether the larger size is more important than a slightly slower speed in the smaller program or if the change in speed is even noticeable.

> 2. I am dealing with string literals of varying lengths. Some of them use the same word or words. Example:
> 

This is really the same type of question. Which version uses the least memory and how important is that? Which version is faster and is the difference noticeable? Is the added complexity of concatenation of small strings worth the effort verses any potential decrease in program size?

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From asa.rand at yahoo.com  Fri Nov 20 02:33:08 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Thu, 19 Nov 2009 23:33:08 -0800 (PST)
Subject: [Coco] the final stage of optimization
Message-ID: <217617.73115.qm@web53709.mail.re2.yahoo.com>

I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.

I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.

In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.

Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.

I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.

There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?

Wayne


      

From goosey at virgo.sdc.org  Fri Nov 20 05:46:13 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Fri, 20 Nov 2009 03:46:13 -0700
Subject: [Coco] Curses update
Message-ID: <20091120104613.GB25864@virgo.sdc.org>

New curses:
http://www.sdc.org/~goosey/curses06.lzh

I realized there was a horrible memory leak in boxwin(), so I removed
the function from the library.

Unfortunately,  fixing it would entail adding in all the extra buffers
and buffer code that this subset library doesn't have.  Not tonight,
my friends.

Anyway, boxwin() isn't even part of K&R era curses.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From snhirsch at gmail.com  Fri Nov 20 06:57:54 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Fri, 20 Nov 2009 06:57:54 -0500 (EST)
Subject: [Coco] Curses update
In-Reply-To: <20091120104613.GB25864@virgo.sdc.org>
References: <20091120104613.GB25864@virgo.sdc.org>
Message-ID: <alpine.DEB.2.00.0911200657301.4638@duo>

On Fri, 20 Nov 2009, Willard Goosey wrote:

> New curses:
> http://www.sdc.org/~goosey/curses06.lzh

Wrong URL!  I found it at:

http://www.sdc.org/~goosey/os9/curses06.lzh

Late night?


Steve


-- 

From snhirsch at gmail.com  Fri Nov 20 07:00:50 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Fri, 20 Nov 2009 07:00:50 -0500 (EST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <217617.73115.qm@web53709.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
Message-ID: <alpine.DEB.2.00.0911200659400.4638@duo>

On Thu, 19 Nov 2009, Wayne Campbell wrote:

> There has to be a better way. Can someone help me understand how to make 
> my search and sort algorithms faster?

Google quicksort.  On average, it will outperform what appears (from your 
description) to be a form of bubblesort.



-- 

From boisy at tee-boy.com  Fri Nov 20 07:05:06 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Fri, 20 Nov 2009 06:05:06 -0600
Subject: [Coco] Multiple line OS9 BBS was Caring for a CoCo
In-Reply-To: <000001ca6996$d9e031c0$8da09540$@rr.com>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com><002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE><20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>
	<003401ca6996$58889f40$6401a8c0@OLDGEORGE>
	<000001ca6996$d9e031c0$8da09540$@rr.com>
Message-ID: <9EA6C818-B981-4CEE-B233-5AD0A569F423@tee-boy.com>

George,

OS-9 L2 BBS was written by Keith Alphonso and distributed through his company Alpha Software Technologies.  He also wrote Data Windows and a few other programs that were eventually sold through Dave Myer's CoCoPro!
--
Boisy G. Pitre
http://www.tee-boy.com/

On Nov 19, 2009, at 10:06 PM, Bill wrote:

> I ran that same BBS for several years in the early to mid 90s. Would LOVE to
> be able to set another board back up using drivewire instead of the dual
> 20Mb Seagate MFM drives I had. (But I don't know if I COULD set it back up
> -=brain dead, ya know=-)
> 
> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
> Behalf Of George Ramsower
> Sent: Thursday, November 19, 2009 11:03 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Multiple line OS9 BBS was Caring for a CoCo
> 
> I haven't yet found an OS-9 BBS that is public domain/open source and
> supports multiple lines.
> Anybody have suggestions?
> 
> -Aaron
> --------------------------------------------
> 
> I have the "OS9 L2 BBS" which does support multiple lines. I can't remember
> who wrote this and right now, I can't find the manual that came with it. I
> do remember the manual had a green cover. I'm certain that someone here will
> remember the author.
> When I set this up years ago, I was impressed at how fast it was. Back
> then, it was considered very fast, even when running from floppies. 
> It was written totally within OS9 rules(so I read somewhere, or dreamed
> it). Used tiny modules to get the job done and worked well for me.....
> considering ... at the time, I couldn't get any interest. I could use a comm
> program, dial out to the other modem and log in to the BBS and operate it
> that way. Using a window to emulate another user, I could chat with myself
> as if there were more than one user online.
> Perhaps, when we find the author, we might even get permission to use it as
> freeware or public domain or whatever terminology is used to say.... "Go
> ahead and use it. Just don't try to make money on it."
> 
> If we get permission, I'll happily make this available to everyone.
> 
> George
> 
> My CNC coco..
> http://coco.thetinbox.com/
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> __________ NOD32 4618 (20091118) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


From robert.gault at worldnet.att.net  Fri Nov 20 07:54:09 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Fri, 20 Nov 2009 07:54:09 -0500
Subject: [Coco] a couple of programming questions
In-Reply-To: <934244.80719.qm@web53710.mail.re2.yahoo.com>
References: <986279.79350.qm@web53711.mail.re2.yahoo.com>	<4B060F8C.2080101@worldnet.att.net>
	<934244.80719.qm@web53710.mail.re2.yahoo.com>
Message-ID: <4B069171.3090907@worldnet.att.net>

Wayne Campbell wrote:

> I'm going to test a version of decode with all of the changes/additions to see what it does. I'll report back with some results in the next day or 2.
>
> Wayne

Now you're cooking! Running this test is the only way to tell which 
version would be optimal or if any differences are even detectable.

In general, a one time use of just about anything in a large program 
probably won't require optimization. Code that is often used or is an 
obvious bottleneck is where optimization give good results.

From robert.gault at worldnet.att.net  Fri Nov 20 08:13:13 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Fri, 20 Nov 2009 08:13:13 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <217617.73115.qm@web53709.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
Message-ID: <4B0695E9.7060307@worldnet.att.net>

Wayne,

You do have a knack for asking questions which at first glance seem 
simple but are actually the subject of major areas of research. :)

Search and sort is just such an area. Try to find the series of books 
"The Art of Computer Programming" by Donald E. Knuth. Volume 3 is 
devoted to just Sorting and Searching.

The algorithm that works best for you may not be an optimal one. The 
main concern is the number of items to be searched, how often they are 
searched, and whether the list is random or ordered.

I would not presume to recommend any particular algorithm. As has 
already been suggested, search the Internet for routines that work best 
with your type of target list.

From linville at tuxdriver.com  Fri Nov 20 08:31:40 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Fri, 20 Nov 2009 08:31:40 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
	<e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>
Message-ID: <20091120133140.GA10281@tuxdriver.com>

On Thu, Nov 19, 2009 at 06:04:12PM -0500, Aaron Wolfe wrote:
> I did a few tests with fusedav and apache just now.  Seems to work
> pretty OK just to mount a DAV share in your local filesystem, then use
> regular DriveWire to give an image on that share to the CoCo.  Maybe
> some excessive read/writes (and the entire disk image each time),  and
> had a couple weird things happen, but probably more of issues with
> fusedav, apache, or just the way DriveWire talks to the local disk.
> Probably could be optimized.
> 
> So.. as it turns out, there is really no point in having netdisk,
> since you can just do this with exisiting tools :)

Well, sorry about the loss of your project...at least you still
have the serial ports and Internet modem and...(I'm sure there is
something...) :-)

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

From aawolfe at gmail.com  Fri Nov 20 11:12:44 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 20 Nov 2009 11:12:44 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <20091120133140.GA10281@tuxdriver.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
	<e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>
	<20091120133140.GA10281@tuxdriver.com>
Message-ID: <e44ad6640911200812v3cabaf18h9abc255b1114bcd3@mail.gmail.com>

On Fri, Nov 20, 2009 at 8:31 AM, John W. Linville
<linville at tuxdriver.com> wrote:
> On Thu, Nov 19, 2009 at 06:04:12PM -0500, Aaron Wolfe wrote:
>> I did a few tests with fusedav and apache just now. ?Seems to work
>> pretty OK just to mount a DAV share in your local filesystem, then use
>> regular DriveWire to give an image on that share to the CoCo. ?Maybe
>> some excessive read/writes (and the entire disk image each time), ?and
>> had a couple weird things happen, but probably more of issues with
>> fusedav, apache, or just the way DriveWire talks to the local disk.
>> Probably could be optimized.
>>
>> So.. as it turns out, there is really no point in having netdisk,
>> since you can just do this with exisiting tools :)
>
> Well, sorry about the loss of your project...at least you still
> have the serial ports and Internet modem and...(I'm sure there is
> something...) :-)
>

Yes, lots of things to play with :)

Don't be sorry!  As a wise man recently told me, the only real reason
to write code for the CoCo these days is the pleasure of seeing your
code run.  I spent a couple hours writing this, it ran, and I enjoyed
it :)

-Aaron

> John
> --
> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From boisy at tee-boy.com  Fri Nov 20 11:21:33 2009
From: boisy at tee-boy.com (Boisy G. Pitre)
Date: Fri, 20 Nov 2009 10:21:33 -0600
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <e44ad6640911200812v3cabaf18h9abc255b1114bcd3@mail.gmail.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
	<e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>
	<20091120133140.GA10281@tuxdriver.com>
	<e44ad6640911200812v3cabaf18h9abc255b1114bcd3@mail.gmail.com>
Message-ID: <3BC38E6B-EBCF-4A1A-98B8-DA6951181123@tee-boy.com>

Aaron,

Do you have an estimate on when the shell access from the Internet will be complete and working?  I'm anxious to give it a whirl.

Boisy

On Nov 20, 2009, at 10:12 AM, Aaron Wolfe wrote:

> On Fri, Nov 20, 2009 at 8:31 AM, John W. Linville
> <linville at tuxdriver.com> wrote:
>> On Thu, Nov 19, 2009 at 06:04:12PM -0500, Aaron Wolfe wrote:
>>> I did a few tests with fusedav and apache just now.  Seems to work
>>> pretty OK just to mount a DAV share in your local filesystem, then use
>>> regular DriveWire to give an image on that share to the CoCo.  Maybe
>>> some excessive read/writes (and the entire disk image each time),  and
>>> had a couple weird things happen, but probably more of issues with
>>> fusedav, apache, or just the way DriveWire talks to the local disk.
>>> Probably could be optimized.
>>> 
>>> So.. as it turns out, there is really no point in having netdisk,
>>> since you can just do this with exisiting tools :)
>> 
>> Well, sorry about the loss of your project...at least you still
>> have the serial ports and Internet modem and...(I'm sure there is
>> something...) :-)
>> 
> 
> Yes, lots of things to play with :)
> 
> Don't be sorry!  As a wise man recently told me, the only real reason
> to write code for the CoCo these days is the pleasure of seeing your
> code run.  I spent a couple hours writing this, it ran, and I enjoyed
> it :)
> 
> -Aaron
> 
>> John
>> --
>> John W. Linville                Someday the world will need a hero, and you
>> linville at tuxdriver.com                  might be all we have.  Be ready.
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Boisy G. Pitre
http://www.tee-boy.com/


From johnadonaldson at sbcglobal.net  Fri Nov 20 11:15:30 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Fri, 20 Nov 2009 10:15:30 -0600
Subject: [Coco] Caring for a CoCo
In-Reply-To: <BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>
References: <e44ad6640911181216l541f11ecrcee96e4d54d5f86e@mail.gmail.com>	<002501ca68ab$8793d7f0$6401a8c0@OLDGEORGE>	<20091119004302.GC5630@tuxdriver.com>	<e44ad6640911181703r47e4f0f0n684533d47e3c0926@mail.gmail.com>	<2FDC98A0-9EE9-4CD4-AD0A-823A3C7A075F@nationsdial.com>	<4B057777.7070603@sbcglobal.net>
	<BLU0-SMTP5012DDECED99C1E6AB5AC5AFA10@phx.gbl>
Message-ID: <4B06C0A2.7010306@sbcglobal.net>

Ron,
   That is because it only now exist on the MM/1 hard drive that is in 
the MM/1 that I sold to Dave Kelly.

John Donaldson


Ron Bihler wrote:
> I have not been able to locate even the mm1 port of RiBBS.
> Thanks
> Ron
>
>
> John Donaldson wrote:
>> When the MM/1 came out, I ported RIBBS over to it. The Basic09 Source 
>> code was released. It became KRIBBS, since the MM/1 used KWindows. 
>> The only problem is it never was used as a BBS since about that time 
>> the Internet was starting become more and more accessible.
>> When I moved to Virginia back in 1999, I sold my MM/1 to Dave Kelly 
>> with all the RIBBS port on it.
>>
>> John Donaldson
>>
>>
>> Dean Leiber wrote:
>>>
>>> On Nov 18, 2009, at 5:03 PM, Aaron Wolfe wrote:
>>>>
>>>> Yes, something like that :)
>>>>
>>>> I haven't yet found an OS-9 BBS that is public domain/open source and
>>>> supports multiple lines.
>>>> Anybody have suggestions?
>>>>
>>>> -Aaron
>>>
>>> I'm not sure about RiBBS being multi-line but the source should be 
>>> about, since I think they released the source at the end. I'm fairly 
>>> sure that the old StG BBS could do multi-line. I've seen the source 
>>> around and I think Scott Griepentrog OK'ed its release. Anybody 
>>> familiar with the other BBS'?
>>>
>>> Dean
>>>
>>> -- 
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


-- 

From johnadonaldson at sbcglobal.net  Fri Nov 20 11:24:58 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Fri, 20 Nov 2009 10:24:58 -0600
Subject: [Coco] Curses update
In-Reply-To: <20091120104613.GB25864@virgo.sdc.org>
References: <20091120104613.GB25864@virgo.sdc.org>
Message-ID: <4B06C2DA.40302@sbcglobal.net>

Willard,
    It happen again.


  Error 404:


    The page you were looking for could not be found


John Donaldson



Willard Goosey wrote:
> New curses:
> http://www.sdc.org/~goosey/curses06.lzh
>
> I realized there was a horrible memory leak in boxwin(), so I removed
> the function from the library.
>
> Unfortunately,  fixing it would entail adding in all the extra buffers
> and buffer code that this subset library doesn't have.  Not tonight,
> my friends.
>
> Anyway, boxwin() isn't even part of K&R era curses.
>
> Willard
>   


-- 

From aawolfe at gmail.com  Fri Nov 20 11:26:58 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 20 Nov 2009 11:26:58 -0500
Subject: [Coco] DriveWire netdisk interface
In-Reply-To: <3BC38E6B-EBCF-4A1A-98B8-DA6951181123@tee-boy.com>
References: <4b059a3f.1502be0a.66e5.29a0@mx.google.com>
	<20091119200950.GD4960@tuxdriver.com>
	<e44ad6640911191415t57baab58hd634b9cbb5e521e9@mail.gmail.com>
	<e44ad6640911191504t58838e62t34783b5e713059f@mail.gmail.com>
	<20091120133140.GA10281@tuxdriver.com>
	<e44ad6640911200812v3cabaf18h9abc255b1114bcd3@mail.gmail.com>
	<3BC38E6B-EBCF-4A1A-98B8-DA6951181123@tee-boy.com>
Message-ID: <e44ad6640911200826j396d4db7ofebab3beaca3ae0c@mail.gmail.com>

On Fri, Nov 20, 2009 at 11:21 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Aaron,
>
> Do you have an estimate on when the shell access from the Internet will be complete and working? ?I'm anxious to give it a whirl.
>
> Boisy
>

I'm just about to run out the door to leave for a weekend caribbean
cruise,  so it will be early next week before I can finish that part.
I did get outbound connections from the CoCo to the internet running
last night (connected my Coco to a BBS for the very first time, been
wanting to do that for about 25 years :).  The code I used for that is
similar to the reverse, I will mail directly to you in case you want
to adapt it in the meantime.

-Aaron


> On Nov 20, 2009, at 10:12 AM, Aaron Wolfe wrote:
>
>> On Fri, Nov 20, 2009 at 8:31 AM, John W. Linville
>> <linville at tuxdriver.com> wrote:
>>> On Thu, Nov 19, 2009 at 06:04:12PM -0500, Aaron Wolfe wrote:
>>>> I did a few tests with fusedav and apache just now. ?Seems to work
>>>> pretty OK just to mount a DAV share in your local filesystem, then use
>>>> regular DriveWire to give an image on that share to the CoCo. ?Maybe
>>>> some excessive read/writes (and the entire disk image each time), ?and
>>>> had a couple weird things happen, but probably more of issues with
>>>> fusedav, apache, or just the way DriveWire talks to the local disk.
>>>> Probably could be optimized.
>>>>
>>>> So.. as it turns out, there is really no point in having netdisk,
>>>> since you can just do this with exisiting tools :)
>>>
>>> Well, sorry about the loss of your project...at least you still
>>> have the serial ports and Internet modem and...(I'm sure there is
>>> something...) :-)
>>>
>>
>> Yes, lots of things to play with :)
>>
>> Don't be sorry! ?As a wise man recently told me, the only real reason
>> to write code for the CoCo these days is the pleasure of seeing your
>> code run. ?I spent a couple hours writing this, it ran, and I enjoyed
>> it :)
>>
>> -Aaron
>>
>>> John
>>> --
>>> John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
>>> linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Fri Nov 20 11:39:54 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 20 Nov 2009 11:39:54 -0500
Subject: [Coco] Curses update
In-Reply-To: <4B06C2DA.40302@sbcglobal.net>
References: <20091120104613.GB25864@virgo.sdc.org>
	<4B06C2DA.40302@sbcglobal.net>
Message-ID: <e44ad6640911200839o5a6ddd22h9b8e87556e43187f@mail.gmail.com>

it works for me...  ?


On Fri, Nov 20, 2009 at 11:24 AM, John Donaldson
<johnadonaldson at sbcglobal.net> wrote:
> Willard,
> ? It happen again.
>
>
> ?Error 404:
>
>
> ? The page you were looking for could not be found
>
>
> John Donaldson
>
>
>
> Willard Goosey wrote:
>>
>> New curses:
>> http://www.sdc.org/~goosey/curses06.lzh
>>
>> I realized there was a horrible memory leak in boxwin(), so I removed
>> the function from the library.
>>
>> Unfortunately, ?fixing it would entail adding in all the extra buffers
>> and buffer code that this subset library doesn't have. ?Not tonight,
>> my friends.
>>
>> Anyway, boxwin() isn't even part of K&R era curses.
>>
>> Willard
>>
>
>
> --
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From aawolfe at gmail.com  Fri Nov 20 11:46:09 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Fri, 20 Nov 2009 11:46:09 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <217617.73115.qm@web53709.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
Message-ID: <e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>

Hi, I don't know your project well enough to be sure, but this seems
like a situation where keeping the data in ram, or at least an index
with the keys and record positions, would be worth the space.  Have
you considered something like that?

-Aaron


On Fri, Nov 20, 2009 at 2:33 AM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.
>
> I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.
>
> In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.
>
> Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.
>
> I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.
>
> There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?
>
> Wayne
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From t.fadden at cox.net  Fri Nov 20 11:47:14 2009
From: t.fadden at cox.net (Tim Fadden)
Date: Fri, 20 Nov 2009 09:47:14 -0700
Subject: [Coco] Curses update
In-Reply-To: <e44ad6640911200839o5a6ddd22h9b8e87556e43187f@mail.gmail.com>
References: <20091120104613.GB25864@virgo.sdc.org>	<4B06C2DA.40302@sbcglobal.net>
	<e44ad6640911200839o5a6ddd22h9b8e87556e43187f@mail.gmail.com>
Message-ID: <4B06C812.3070105@cox.net>

As some one else mentioned before, the correct address is:

http://www.sdc.org/~goosey/os9/curses06.lzh



Aaron Wolfe wrote:
> it works for me...  ?
>
>
> On Fri, Nov 20, 2009 at 11:24 AM, John Donaldson
> <johnadonaldson at sbcglobal.net> wrote:
>   
>> Willard,
>>   It happen again.
>>
>>
>>  Error 404:
>>
>>
>>   The page you were looking for could not be found
>>
>>
>> John Donaldson
>>
>>
>>
>> Willard Goosey wrote:
>>     
>>> New curses:
>>> http://www.sdc.org/~goosey/curses06.lzh
>>>
>>> I realized there was a horrible memory leak in boxwin(), so I removed
>>> the function from the library.
>>>
>>> Unfortunately,  fixing it would entail adding in all the extra buffers
>>> and buffer code that this subset library doesn't have.  Not tonight,
>>> my friends.
>>>
>>> Anyway, boxwin() isn't even part of K&R era curses.
>>>
>>> Willard
>>>
>>>       
>> --
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>     
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>   


From bear at bears.org  Fri Nov 20 14:20:20 2009
From: bear at bears.org (Gary)
Date: Fri, 20 Nov 2009 14:20:20 -0500 (EST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0911201417590.19982@ferocity.bears.org>

On Fri, 20 Nov 2009, Aaron Wolfe wrote:

> Hi, I don't know your project well enough to be sure, but this seems
> like a situation where keeping the data in ram, or at least an index

Years ago, I wrote a database for Basic09 and the only sort I knew at the 
time was bubblesort -- using a ramdisk instead of the physical floppy sped 
it up by two orders of magnitude.

If something like that isn't an option -- since it sounds like the data is 
largely sequential (one long file broken into records) what about treating 
it like tape?  There are a number of well-understood algorithms from the 
50s that might apply -- such as mergesort -- that were designed for 
handling large amounts of data for sorting and searching on machines with 
small ram spaces.

Might be worth a shot?

Peace,
Gary

From goosey at virgo.sdc.org  Fri Nov 20 14:29:26 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Fri, 20 Nov 2009 12:29:26 -0700
Subject: [Coco] Curses update
In-Reply-To: <alpine.DEB.2.00.0911200657301.4638@duo>
References: <20091120104613.GB25864@virgo.sdc.org>
	<alpine.DEB.2.00.0911200657301.4638@duo>
Message-ID: <20091120192926.GA12122@virgo.sdc.org>

On Fri, Nov 20, 2009 at 06:57:54AM -0500, Steven Hirsch wrote:
> Wrong URL!  I found it at:
> 
> http://www.sdc.org/~goosey/os9/curses06.lzh
> 
> Late night?

Heh, sorry about that.  I got distracted. :-(

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From goosey at virgo.sdc.org  Fri Nov 20 14:42:15 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Fri, 20 Nov 2009 12:42:15 -0700
Subject: [Coco] Curses update
In-Reply-To: <4B06C2DA.40302@sbcglobal.net>
References: <20091120104613.GB25864@virgo.sdc.org>
	<4B06C2DA.40302@sbcglobal.net>
Message-ID: <20091120194215.GB12122@virgo.sdc.org>

On Fri, Nov 20, 2009 at 10:24:58AM -0600, John Donaldson wrote:
> Willard,
>    It happen again.

Yeah, I got distracted by watching the blinkenlights and gave the
wrong url.  (This particular computer goes through two switches to the
dsl router.  telnet sends a packet for each character... 5 blinks/char
is very distracting! :-)

Try http://www.sdc.org/~goosey/os9/curses06.lzh

If that doesn't work I'll have to brave the BOFH.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From johnadonaldson at sbcglobal.net  Fri Nov 20 15:21:34 2009
From: johnadonaldson at sbcglobal.net (John Donaldson)
Date: Fri, 20 Nov 2009 14:21:34 -0600
Subject: [Coco] Curses update
In-Reply-To: <4B06C812.3070105@cox.net>
References: <20091120104613.GB25864@virgo.sdc.org>	<4B06C2DA.40302@sbcglobal.net>	<e44ad6640911200839o5a6ddd22h9b8e87556e43187f@mail.gmail.com>
	<4B06C812.3070105@cox.net>
Message-ID: <4B06FA4E.1070404@sbcglobal.net>

I saw the revision after I had sent my email about the 404 error. I got 
it with the correct link.

John



Tim Fadden wrote:
> As some one else mentioned before, the correct address is:
>
> http://www.sdc.org/~goosey/os9/curses06.lzh
>
>
>
> Aaron Wolfe wrote:
>> it works for me...  ?
>>
>>
>> On Fri, Nov 20, 2009 at 11:24 AM, John Donaldson
>> <johnadonaldson at sbcglobal.net> wrote:
>>  
>>> Willard,
>>>   It happen again.
>>>
>>>
>>>  Error 404:
>>>
>>>
>>>   The page you were looking for could not be found
>>>
>>>
>>> John Donaldson
>>>
>>>
>>>
>>> Willard Goosey wrote:
>>>    
>>>> New curses:
>>>> http://www.sdc.org/~goosey/curses06.lzh
>>>>
>>>> I realized there was a horrible memory leak in boxwin(), so I removed
>>>> the function from the library.
>>>>
>>>> Unfortunately,  fixing it would entail adding in all the extra buffers
>>>> and buffer code that this subset library doesn't have.  Not tonight,
>>>> my friends.
>>>>
>>>> Anyway, boxwin() isn't even part of K&R era curses.
>>>>
>>>> Willard
>>>>
>>>>       
>>> -- 
>>>
>>> -- 
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>     
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>>   
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


-- 

From asa.rand at yahoo.com  Fri Nov 20 16:15:25 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 20 Nov 2009 13:15:25 -0800 (PST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <alpine.DEB.2.00.0911200659400.4638@duo>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<alpine.DEB.2.00.0911200659400.4638@duo>
Message-ID: <194386.31221.qm@web53711.mail.re2.yahoo.com>

I googled quicksort. The wiki page is very informative. While reading it, I remembered how I wrote the sorts in DCom. They were based on quicksort. Because they were contained in separate procedures, I was able to use them recursively, and that's what made it work.

In decode, the sorts and searches are part of that procedure, and not separate. This rules out recursion, as I can't call decode repeatedly. But I did gain an understanding I didn't previously have. I need to deal with the records to be searched or sorted in groups. This will require extra code to determine if a split is required, and how to divide it. I'm reasonably certain that a n/2 division will be faster, but I may be able to have it do a n/4 division when the number of records becomes greater than a specific number.

I think that doing it this way will speed things up because it won't have to search every record to find a match. We'll see.

Thanks for the tip Steven. :)

Wayne




________________________________
From: Steven Hirsch <snhirsch at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 4:00:50 AM
Subject: Re: [Coco] the final stage of optimization

On Thu, 19 Nov 2009, Wayne Campbell wrote:

> There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?

Google quicksort.  On average, it will outperform what appears (from your description) to be a form of bubblesort.



-- 
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From goosey at virgo.sdc.org  Fri Nov 20 16:39:49 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Fri, 20 Nov 2009 14:39:49 -0700
Subject: [Coco] Curses update
In-Reply-To: <4B06FA4E.1070404@sbcglobal.net>
References: <20091120104613.GB25864@virgo.sdc.org>
	<4B06C2DA.40302@sbcglobal.net>
	<e44ad6640911200839o5a6ddd22h9b8e87556e43187f@mail.gmail.com>
	<4B06C812.3070105@cox.net> <4B06FA4E.1070404@sbcglobal.net>
Message-ID: <20091120213949.GA17216@virgo.sdc.org>

On Fri, Nov 20, 2009 at 02:21:34PM -0600, John Donaldson wrote:
> I saw the revision after I had sent my email about the 404 error. I got 
> it with the correct link.

Good, I fear both my BOTH's LART and his root rm -r ;-)

"Root.  God.  There is difference?"
-- Piotr

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From snhirsch at gmail.com  Fri Nov 20 17:26:39 2009
From: snhirsch at gmail.com (Steven Hirsch)
Date: Fri, 20 Nov 2009 17:26:39 -0500 (EST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <194386.31221.qm@web53711.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<alpine.DEB.2.00.0911200659400.4638@duo>
	<194386.31221.qm@web53711.mail.re2.yahoo.com>
Message-ID: <alpine.DEB.2.00.0911201724280.4638@duo>

On Fri, 20 Nov 2009, Wayne Campbell wrote:

> I googled quicksort. The wiki page is very informative. While reading 
> it, I remembered how I wrote the sorts in DCom. They were based on 
> quicksort. Because they were contained in separate procedures, I was 
> able to use them recursively, and that's what made it work.
>
> In decode, the sorts and searches are part of that procedure, and not 
> separate. This rules out recursion, as I can't call decode repeatedly. 
> But I did gain an understanding I didn't previously have. I need to deal 
> with the records to be searched or sorted in groups. This will require 
> extra code to determine if a split is required, and how to divide it. 
> I'm reasonably certain that a n/2 division will be faster, but I may be 
> able to have it do a n/4 division when the number of records becomes 
> greater than a specific number.
>
> I think that doing it this way will speed things up because it won't 
> have to search every record to find a match. We'll see.

I'm not entirely sure I understand what you are doing/trying to do.  Do 
you need to maintain sorted and searchable set of items dynamically?  If 
so, perhaps what you need is a tree or heap structure.  The insertion will 
be on average O(LogN) instead of the constant time insertion cost of a 
list, but it maintains the sequence and can be searched in the same 
O(LogN) time.

Steve


-- 

From jorge_machin at hotmail.com  Fri Nov 20 20:17:25 2009
From: jorge_machin at hotmail.com (Jorge Renato Machin Ibarra)
Date: Fri, 20 Nov 2009 19:17:25 -0600
Subject: [Coco] California Digital and the Dragon
In-Reply-To: <5631e580911050437n3fa162e5x73901e2883a7320b@mail.gmail.com>
References: <5631e580911050437n3fa162e5x73901e2883a7320b@mail.gmail.com>
Message-ID: <SNT109-W46F7D4A9883C5D2FA9BC34E5A00@phx.gbl>


Rogelio:

Thank you for the tip. Today I received a new "Dragon by Tano" computer from California Digital.  Opening a brand new Dragon  was an unique experience for me. It felt like opening a  gift on Christmas :)

Jorge Machin


> Date: Thu, 5 Nov 2009 07:37:54 -0500
> From: os9dude at gmail.com
> To: coco at maltedmedia.com
> Subject: [Coco] California Digital and the Dragon
> 
> Recently I inquired about floppy drive pricing and availability of the
> Tano/Dragon computer, following is my response. Looking forward to get a
> Dragon.
> 
> No more Floppy Drives though. I have a mismatched pair of drives on my CoCo
> 1 setup and was trying to set it up with two same brand/model ones just for
> miscellaneous reasons. So they look nice :-)
> 
> 
> -- Rogelio
> 
> 
> ---------- Forwarded message ----------
> From: <catalog at cadigital.com>
> Date: Tue, Nov 3, 2009 at 3:22 PM
> Subject: Re: Pricing info required: Floppy Drive and Computer
> To: Rogelio Perea <os9dude at gmail.com>
> 
> 
> No longer have 5.25" drives.
> 
> TANO DRAGONS
> California Digital still has a significant amount of Tano Dragon 64
> computers available in its warehouse. Original retail price was $400.
> California Digital is offering the Dragon at only $45 each.  These are brand
> new computers still packed in factory boxes.
> 
> Because each Dragon ships at 19 pounds, the cost of shipping is substantial.
> West Coast shipping costs are approximately $20, East Coast is about $30.
> Foreign: The postal service no longer offers ocean/surface transit. The
> Dragon must ship either by air freight courier or air mail. Shipping cost to
> the UK and most of Europe is about $90 each. WoW!
> 
> Additional information available at:
> http://www.cadigital.com/computer.htm
> 
> PAYMENT: PayPal is preferred. Our payment e-mail address is:
> laser at cadigital.com.
> We also accept credit cards and checks.
> California Digital also accept major credit cards and checks.
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
 		 	   		  
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

From dml_68 at yahoo.com  Fri Nov 20 21:44:57 2009
From: dml_68 at yahoo.com (Derek)
Date: Fri, 20 Nov 2009 18:44:57 -0800 (PST)
Subject: [Coco] 2GB MicroSD Drive Pak Question
Message-ID: <827597.98892.qm@web30207.mail.mud.yahoo.com>

Howdy All,

Just wondering if the new 2GB MicroSD Drive Pak will let you mount disk images directly or will we need to somehow un-compress and transfer the disk image contents to the SD card.

If disk images are supported what formats will be supported and also will virtual hard disk images be mountable as well?

Looks like a great product! I saw a similar SD card for the Apple II series of computers but it did not support mounting disk images, you had do un-compress the images and copy the contents to the SD Card.



** Mistrust Authority. Promote Decentralization **


 


      

From asa.rand at yahoo.com  Fri Nov 20 22:24:41 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 20 Nov 2009 19:24:41 -0800 (PST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <alpine.DEB.2.00.0911201724280.4638@duo>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<alpine.DEB.2.00.0911200659400.4638@duo>
	<194386.31221.qm@web53711.mail.re2.yahoo.com>
	<alpine.DEB.2.00.0911201724280.4638@duo>
Message-ID: <231051.79356.qm@web53712.mail.re2.yahoo.com>


>I'm not entirely sure I understand what you are doing/trying to do.  Do
you need to maintain sorted and searchable set of items dynamically? 
If so, perhaps what you need is a tree or heap structure.  The
insertion will be on average O(LogN) instead of the constant time
insertion cost of a list, but it maintains the sequence and can be
searched in the same O(LogN) time.

The search and sort routines are separate. The search routine is designed to determine if a record has already been established for the data being compared. If it has, increment the ref count on, and save back to the file, the record that matched. If no match is found, then add a new record. The problem occurs when the number of records becomes large, say more than 25 records (I haven't actually been able to determine when the search becomes noticeably longer). The search times grow proportionately with the number of records to search.

The sort speed problem is a little more involved, especially in the literals file. The line sort is only comparing 2 fields, but the literal sort is comparing 5 pairs of fields, the actual pair depending on the value of the first field compared.

The reason is because literal references occur in 5 ways. There are byte, integer, hex integer, real and string literals. The sort first looks to see if the 2 records being compared have the same type field value. If they don't, sort them if necessary. If they do, then look at either the byte field, integer field, real field or string field. If they are different, sort them if necessary. With strings, there are 2 comparisons. First is according to string length. If they are the same length, compare for equality and sort if necessary. If the lengths are different, sort if necessary. Necessary, in all cases, means that the first record compared has compared values greater than and not equal to the second record's compared values.

The comparisons are not slow, going by the way it acts at the beginning of the decode (search) or with a smaller number of records (sort).

I firmly believe it is the speed of the disk accesses that are slowing the program down. I don't know if disk accesses can be sped up, but I do know that the recursive sorts I used in DCom were much faster than the original linear (bubble?) sorts were.

Wayne




________________________________
From: Steven Hirsch <snhirsch at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 2:26:39 PM
Subject: Re: [Coco] the final stage of optimization

On Fri, 20 Nov 2009, Wayne Campbell wrote:

> I googled quicksort. The wiki page is very informative. While reading it, I remembered how I wrote the sorts in DCom. They were based on quicksort. Because they were contained in separate procedures, I was able to use them recursively, and that's what made it work.
> 
> In decode, the sorts and searches are part of that procedure, and not separate. This rules out recursion, as I can't call decode repeatedly. But I did gain an understanding I didn't previously have. I need to deal with the records to be searched or sorted in groups. This will require extra code to determine if a split is required, and how to divide it. I'm reasonably certain that a n/2 division will be faster, but I may be able to have it do a n/4 division when the number of records becomes greater than a specific number.
> 
> I think that doing it this way will speed things up because it won't have to search every record to find a match. We'll see.

I'm not entirely sure I understand what you are doing/trying to do.  Do you need to maintain sorted and searchable set of items dynamically?  If so, perhaps what you need is a tree or heap structure.  The insertion will be on average O(LogN) instead of the constant time insertion cost of a list, but it maintains the sequence and can be searched in the same O(LogN) time.

Steve


-- 
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From asa.rand at yahoo.com  Fri Nov 20 23:32:33 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 20 Nov 2009 20:32:33 -0800 (PST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
Message-ID: <116166.37466.qm@web53709.mail.re2.yahoo.com>

It would be nice to keep the data in ram. I have been toying with the idea of trying to use GFX2's buffer commands to see if I can use them to store the records in memory and work on them there. Then I would only need to create the file when it was ready to be saved. I'm really uneducated in terms of things like indexing and linked-lists and the like. If you wouldn't mind, could you explain the index with keys and record positions idea? It sounds interesting.

Wayne




________________________________
From: Aaron Wolfe <aawolfe at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 8:46:09 AM
Subject: Re: [Coco] the final stage of optimization

Hi, I don't know your project well enough to be sure, but this seems
like a situation where keeping the data in ram, or at least an index
with the keys and record positions, would be worth the space.  Have
you considered something like that?

-Aaron


On Fri, Nov 20, 2009 at 2:33 AM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.
>
> I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.
>
> In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.
>
> Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.
>
> I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.
>
> There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?
>
> Wayne
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From lothan at newsguy.com  Fri Nov 20 23:35:42 2009
From: lothan at newsguy.com (Lothan)
Date: Fri, 20 Nov 2009 23:35:42 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <116166.37466.qm@web53709.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com><e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
	<116166.37466.qm@web53709.mail.re2.yahoo.com>
Message-ID: <CF04CBA56D7A45F49A72EBCC2F3E60D5@Crossfire>

It would be a lot easier to load the driver and descriptor for a RAM drive 
and use it just like a regular drive.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Friday, November 20, 2009 11:32 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] the final stage of optimization

> It would be nice to keep the data in ram. I have been toying with the idea 
> of trying to use GFX2's buffer commands to see if I can use them to store 
> the records in memory and work on them there. Then I would only need to 
> create the file when it was ready to be saved. I'm really uneducated in 
> terms of things like indexing and linked-lists and the like. If you 
> wouldn't mind, could you explain the index with keys and record positions 
> idea? It sounds interesting.
>
> Wayne
>
>
>
>
> ________________________________
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, November 20, 2009 8:46:09 AM
> Subject: Re: [Coco] the final stage of optimization
>
> Hi, I don't know your project well enough to be sure, but this seems
> like a situation where keeping the data in ram, or at least an index
> with the keys and record positions, would be worth the space.  Have
> you considered something like that?
>
> -Aaron
>
>
> On Fri, Nov 20, 2009 at 2:33 AM, Wayne Campbell <asa.rand at yahoo.com> 
> wrote:
>> I have been aware that the one thing that is slowing decode down more 
>> than anything else is having to use disk files to store, search and sort 
>> records. This email concerns searches and sorts.
>>
>> I have never really gotten a good understanding of how search and sort 
>> algorithms are designed, and how they operate, beyond the least complex. 
>> When I wrote DCom, I wrote sort procedures that were recursive. They 
>> worked, but I never really understood if they were working efficiently or 
>> not. I do know that the sorting operations were faster after they were 
>> modified.
>>
>> In decode, I am using a simple search algorithm. Basically, it starts 
>> with the first record, and continues reading each succeeding record until 
>> either a match is found or the last record is read. The number of records 
>> that get added to the file depends on the I-Code being decoded. The more 
>> records in the file, the longer the search takes.
>>
>> Three files are created, variables reference, line reference, and literal 
>> reference. Decoding createmsg (one of Ron's modules, about 2K in size), 
>> the decode takes about 20 minutes. Decoding RConfig (another of Ron's 
>> modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) 
>> takes 2 hours.
>>
>> I have the same problem with my sort. I'm using a sifter-style (for lack 
>> of a better term) of sort. It starts with the first record, proceeds to 
>> the last record, then performs the sort in reverse, starting with the 
>> last record and proceeding to the first. Each pass of the routine 
>> performs both of these operations. It works, and it was much faster than 
>> using the top-to-bottom method I first used that was based on the search 
>> routine. However, it takes as long to sort the literals records as it 
>> does to decode the instruction section of the I-Code module.
>>
>> There has to be a better way. Can someone help me understand how to make 
>> my search and sort algorithms faster?
>>
>> Wayne
>>
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

From asa.rand at yahoo.com  Fri Nov 20 23:45:22 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Fri, 20 Nov 2009 20:45:22 -0800 (PST)
Subject: [Coco] the final stage of optimization
In-Reply-To: <alpine.DEB.2.00.0911201417590.19982@ferocity.bears.org>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
	<alpine.DEB.2.00.0911201417590.19982@ferocity.bears.org>
Message-ID: <420525.40852.qm@web53708.mail.re2.yahoo.com>

When I wrote DCom I used a RAM disk. I recommended the use of a RAM disk as it did speed up the program significantly. With the current setup I'm using, I am unable to setup a ram drive. The NitrOS9 disk image I'm using is not a proper system master, and I'm spending all of my available time working on this project. I just don't have time to try to figure it out right now. I'm attempting to get the copy of the OS9 system disk to boot, but for reasons unknown the screen comes up black-on-black with a magenta cursor, and the display commands don't change it. If I can't see what I'm doing, I can't work on anything. So, I make do with what I have.

The sort I'm using is based on the bubble sort, but instead of repeatedly starting at the top and working to the bottom, it souts back upward when it gets to the bottom. This way, it is constantly sorting in both directions, and uses fewer iterations of the loop. It proved to be over twice as fast as top-to-bottom-top-to-bottom.

Thanks for the tips. I've heard of mergesort, but have never seen it in operation or looked at its code. I know there were many things developed on the mainframes for dealing with massive volume sequential data, but I've never been around it. Always looking from a distance. I'll see what I can find on the web.

Wayne




________________________________
From: Gary <bear at bears.org>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 11:20:20 AM
Subject: Re: [Coco] the final stage of optimization

On Fri, 20 Nov 2009, Aaron Wolfe wrote:

> Hi, I don't know your project well enough to be sure, but this seems
> like a situation where keeping the data in ram, or at least an index

Years ago, I wrote a database for Basic09 and the only sort I knew at the time was bubblesort -- using a ramdisk instead of the physical floppy sped it up by two orders of magnitude.

If something like that isn't an option -- since it sounds like the data is largely sequential (one long file broken into records) what about treating it like tape?  There are a number of well-understood algorithms from the 50s that might apply -- such as mergesort -- that were designed for handling large amounts of data for sorting and searching on machines with small ram spaces.

Might be worth a shot?

Peace,
Gary

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From goosey at virgo.sdc.org  Sat Nov 21 06:43:51 2009
From: goosey at virgo.sdc.org (Willard Goosey)
Date: Sat, 21 Nov 2009 04:43:51 -0700
Subject: [Coco] pic2vef update
Message-ID: <20091121114350.GA15120@virgo.sdc.org>

I'm not sure what happened, but the version of pic2vef I had on my
website was an early one.  

Please download http://www.sdc.org/~goosey/os9/pic2vef.lzh

Pic2vef converts (CoCo) Deskmate 3 .pic images to OS-9 vef images.

If you have a version that doesn't do pixel-doubling to convert the
160x175 PIC to a 320x175 VEF, then you have the old version.  The new
version generates VEFS that look identical to the original image.

I apologize for the inconvenience and any half-sized pictures that
resulted.  :-(

I believe the new version is the one I uploaded to rtsi and
maltedmedia, but the copy on rtsi is still in incoming where it can't
be read, and pic2vef.lzh seems to have vanished from maltedmedia.

Willard
-- 
Willard Goosey  goosey at sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

From jdiffendaffer at yahoo.com  Sat Nov 21 08:19:04 2009
From: jdiffendaffer at yahoo.com (jdiffendaffer)
Date: Sat, 21 Nov 2009 13:19:04 -0000
Subject: [Coco] [Color Computer]  the final stage of optimization
Message-ID: <he8pc9+soma@eGroups.com>

Wayne

If you are using strings you'll need a table of pointers to the actual data so you don't have to move strings around, which is much slower than pointers.

First, sorts.

The concept behind all good sorts, is to move out of place data as close to it's destination as possible with each pass.  That usually means as far as possible with early passes and smaller and smaller distances with each additional pass. 

The easiest sort I think you could use is the comb sort.  It's a modified bubble sort where you compare the first item against the middle item to start and step through until you get to the end with the 2nd pointer.

Each time through you are moving data a large distance instead of bubbling it up one at a time.  This eliminates what's known as "turtles", an out of place data item at the end of the list that slowly bubble up to their destination.

Depending on how out of order the data is, combsort can actually beat the quick sort.  One is better at best case and the other is better at worst and on average they are pretty close.
You'll also find combsort easy to implement iteratively (simple loops) where most quicksort examples use recursion and require more stack space.  For a small memory environment and with unpredictable data size that's pretty important as you could overflow the stack.

The Wiki talks about dividing the gap by 1.3 but to simplify things you can divide by 2 (just a bit shift in assembly).  It will cause more passes as the gap shrinks but for a data set like this you won't really notice.

http://en.wikipedia.org/wiki/Comb_sort
http://en.wikipedia.org/wiki/Quicksort


For searches you want a similar concept.  Get as close to the data you are searching for with each pass as you can.

In other words...
sort the data or you have to search.
Then do what is called a binary search.  
It requires three pointers.
Set the first to the first data element, the 2nd to the last data element and set the 3rd to the midpoint of your sorted data.  
pointer3 = (pointer2 - pointer1 / 2) + pointer1.

Check to see if your target value is greater, less than or equal to pointer3 (data block midpoint).  
If it's equal, quit.
If it's less than, set pointer2 to pointer3 - 1, greater than set pointer1 = pointer3 + 1.
Recalculate the midpoint and go again till you find your data.

You split the data in half each pass of the search and check to see which half your target value is in.  Then you split that in half etc... until you find what you are looking for.

As is typical for computer science the author of the Wiki made the explanation more complex than it needs to be so I included another link.
 
http://en.wikipedia.org/wiki/Binary_search_algorithm
http://www.ensta.fr/~diam/c++/online/notes-cpp/algorithms/searching/binarysearch.html

-quoted text---------------------------------
I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.

I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.

In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.

Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.

I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.

There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?

Wayne 


From tonypodraza at juno.com  Sat Nov 21 09:04:27 2009
From: tonypodraza at juno.com (Tony Podraza)
Date: Sat, 21 Nov 2009 14:04:27 GMT
Subject: [Coco] Caring for a CoCo
Message-ID: <20091121.080427.13706.0@webmail10.vgs.untd.com>

now, THAT"ll wake you up!!!!!

You can also find a bad cap that's been setting a very long while
when you first apply power.   They usually explode and
catch fire.   I found a few using this method too.  :)

Roy

____________________________________________________________
Save on Life Insurance
Protect Your Loved Ones with Affordable Life Insurance Coverage.
http://thirdpartyoffers.juno.com/TGL2141/c?cp=4najfRyShpoNoZWtRyYCwgAAJ1CMGlx2Pi3jwjncgcBXdehhAAQAAAAFAAAAAFaAVD4AAAMlAAAAAAAAAAAAAAAAAAQlQwAAAAA=

From jdiffendaffer at yahoo.com  Sat Nov 21 09:52:56 2009
From: jdiffendaffer at yahoo.com (jdiffendaffer)
Date: Sat, 21 Nov 2009 14:52:56 -0000
Subject: [Coco] [Color Computer] Re:  the final stage of optimization
In-Reply-To: <he8pc9+soma@eGroups.com>
Message-ID: <he8us8+rqs1@eGroups.com>

I guess I should have been more clear here.
If you are dealing with on disk data, pointers would be record numbers and the compare reads the records and does the compare.

You can make operations significantly faster if you keep some part of the records in memory to reduce disk accesses since that is the slowest operation.  A hash of the records might be a good idea if you can come up with a decent one.

--- In ColorComputer at yahoogroups.com, "jdiffendaffer" <jdiffendaffer at ...> wrote:
>
> Wayne
> 
> If you are using strings you'll need a table of pointers to the actual data so you don't have to move strings around, which is much slower than pointers.



From jmichea at cogeco.ca  Sat Nov 21 13:45:04 2009
From: jmichea at cogeco.ca (Jeremy Michea)
Date: Sat, 21 Nov 2009 13:45:04 -0500
Subject: [Coco] Coco 1 question
Message-ID: <000801ca6ada$bd94a290$ecfd3918@jeremy4b3f9678>

Hi.

I picked up a Coco 1 and with manuals and 6 rompaks for $10 at a charity garage sale today and I looked at the model number on the back - 26-3004A. I can't find much info on this particular model. How much memory would this unit have and what's the difference between it and the 26-3004?

Thanks

From lothan at newsguy.com  Sat Nov 21 15:35:58 2009
From: lothan at newsguy.com (Lothan)
Date: Sat, 21 Nov 2009 15:35:58 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <420525.40852.qm@web53708.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com><e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com><alpine.DEB.2.00.0911201417590.19982@ferocity.bears.org>
	<420525.40852.qm@web53708.mail.re2.yahoo.com>
Message-ID: <C888D5419F544485B1DA285EA2EC5E5F@Crossfire>

If you're currently booting from a good OS-9 or NitrOS-9 boot disk/image, 
all you really need to do is merge the driver and descriptor, load the 
merged file into memory, and then init the descriptor:

merge /dd/modules/rbf/rammer.dr /dd/modules/rbf/r0_128k.dd >/dd/cmds/ramr0
attr /dd/cmds/ramr0 e pe
load ramr0
link rammer
link r0
iniz /r0
format /r0

At this point /r0 is ready to use. Also note that I used r0_128k.dd as an 
example, but you can use either of the r0_8k.dd, r0_96k.dd, r0_128k.dd, or 
r0_192k.dd descriptors as appropriate.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Friday, November 20, 2009 11:45 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] the final stage of optimization

> When I wrote DCom I used a RAM disk. I recommended the use of a RAM disk 
> as it did speed up the program significantly. With the current setup I'm 
> using, I am unable to setup a ram drive. The NitrOS9 disk image I'm using 
> is not a proper system master, and I'm spending all of my available time 
> working on this project. I just don't have time to try to figure it out 
> right now. I'm attempting to get the copy of the OS9 system disk to boot, 
> but for reasons unknown the screen comes up black-on-black with a magenta 
> cursor, and the display commands don't change it. If I can't see what I'm 
> doing, I can't work on anything. So, I make do with what I have.
>
> The sort I'm using is based on the bubble sort, but instead of repeatedly 
> starting at the top and working to the bottom, it souts back upward when 
> it gets to the bottom. This way, it is constantly sorting in both 
> directions, and uses fewer iterations of the loop. It proved to be over 
> twice as fast as top-to-bottom-top-to-bottom.
>
> Thanks for the tips. I've heard of mergesort, but have never seen it in 
> operation or looked at its code. I know there were many things developed 
> on the mainframes for dealing with massive volume sequential data, but 
> I've never been around it. Always looking from a distance. I'll see what I 
> can find on the web.
>
> Wayne
>
>
>
>
> ________________________________
> From: Gary <bear at bears.org>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, November 20, 2009 11:20:20 AM
> Subject: Re: [Coco] the final stage of optimization
>
> On Fri, 20 Nov 2009, Aaron Wolfe wrote:
>
>> Hi, I don't know your project well enough to be sure, but this seems
>> like a situation where keeping the data in ram, or at least an index
>
> Years ago, I wrote a database for Basic09 and the only sort I knew at the 
> time was bubblesort -- using a ramdisk instead of the physical floppy sped 
> it up by two orders of magnitude.
>
> If something like that isn't an option -- since it sounds like the data is 
> largely sequential (one long file broken into records) what about treating 
> it like tape?  There are a number of well-understood algorithms from the 
> 50s that might apply -- such as mergesort -- that were designed for 
> handling large amounts of data for sorting and searching on machines with 
> small ram spaces.
>
> Might be worth a shot?
>
> Peace,
> Gary
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 

From aawolfe at gmail.com  Sat Nov 21 16:22:01 2009
From: aawolfe at gmail.com (Aaron Wolfe)
Date: Sat, 21 Nov 2009 16:22:01 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <116166.37466.qm@web53709.mail.re2.yahoo.com>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<e44ad6640911200846v528295c6s72aabf36776522c3@mail.gmail.com>
	<116166.37466.qm@web53709.mail.re2.yahoo.com>
Message-ID: <e44ad6640911211322s67d170fbt35efebb3f6d3bf69@mail.gmail.com>

If you can fit the entire file in a ram disk, then that would be an
easy way to speed things up.  The other thing I suggested with keeping
just the keys in ram is useful when you cannot keep all the data in
ram for whatever reason.

Basically, if you are sorting/looking for matching records based on a
key, then you only need to keep that key in ram, along with a pointer
that tells the program where to get the rest of the record from,
usually a specific place in a disk file.   This way you can do very
fast sorts and searches but only use up the ram taken by the field(s)
you need to sort/search on instead of the entire record.  Your memory
structure does not have to mirror the disk structure until you want it
to, so in this way you can do sorts and such entirely in ram and then
only write out the results to disk, or in other words know in advance
where each record needs to be moved to/from and do it all in one disk
processing pass.

How you store the keys and pointers can have a big effect on how fast
you can do sorts, inserts, etc.  As others have mentioned there are
lots of different strategies.  A simple linked list can be quite fast
for inserts and searching in small sets of data.  For larger sets you
can look at btrees and hashes.  These are just more efficient ways of
implementing a list, taking advantage of clever structure to make
searching or sorting or inserting or X more efficient.  They all have
advantages or disadvantages depending or what you are trying to
optimize the code to do.

Googling for linked list, binary tree, hash, etc will probably find
some good resources on these.  I have a great book on data structures
somewhere, if I can find the title will let you know.

-Aaron


On 11/20/09, Wayne Campbell <asa.rand at yahoo.com> wrote:
> It would be nice to keep the data in ram. I have been toying with the idea of trying to use GFX2's buffer commands to see if I can use them to store the records in memory and work on them there. Then I would only need to create the file when it was ready to be saved. I'm really uneducated in terms of things like indexing and linked-lists and the like. If you wouldn't mind, could you explain the index with keys and record positions idea? It sounds interesting.
>
> Wayne
>
>
>
>
> ________________________________
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, November 20, 2009 8:46:09 AM
> Subject: Re: [Coco] the final stage of optimization
>
> Hi, I don't know your project well enough to be sure, but this seems
> like a situation where keeping the data in ram, or at least an index
> with the keys and record positions, would be worth the space.  Have
> you considered something like that?
>
> -Aaron
>
>
> On Fri, Nov 20, 2009 at 2:33 AM, Wayne Campbell <asa.rand at yahoo.com> wrote:
> > I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.
> >
> > I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.
> >
> > In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.
> >
> > Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.
> >
> > I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.
> >
> > There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?
> >
> > Wayne
> >
> >
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>

From gene.heskett at verizon.net  Sat Nov 21 17:09:39 2009
From: gene.heskett at verizon.net (Gene Heskett)
Date: Sat, 21 Nov 2009 17:09:39 -0500
Subject: [Coco] the final stage of optimization
In-Reply-To: <C888D5419F544485B1DA285EA2EC5E5F@Crossfire>
References: <217617.73115.qm@web53709.mail.re2.yahoo.com>
	<420525.40852.qm@web53708.mail.re2.yahoo.com>
	<C888D5419F544485B1DA285EA2EC5E5F@Crossfire>
Message-ID: <200911211709.39265.gene.heskett@verizon.net>

On Saturday 21 November 2009, Lothan wrote:
>If you're currently booting from a good OS-9 or NitrOS-9 boot disk/image,
>all you really need to do is merge the driver and descriptor, load the
>merged file into memory, and then init the descriptor:
>
>merge /dd/modules/rbf/rammer.dr /dd/modules/rbf/r0_128k.dd >/dd/cmds/ramr0
>attr /dd/cmds/ramr0 e pe
>load ramr0
>link rammer
>link r0
>iniz /r0
>format /r0
>
You only need to 'link' the first module of a merged group of them, which you 
did above.  And if you use 'myram', the last two steps are un-necessary since 
it formats itself on the first access, in about 100 milliseconds.  It also 
works (many times verified) at up to around 1.7 megs of ramdisk when used on 
a 2 meg machine.  Deiniz it, dmode for the size you want, and do a "dir /r0" 
and its setup and usable for the new size.  Deiniz'ing it also returns every 
byte it used to the memory pool.  Its size is determined by the sct variable 
you can change with dmode, and IIRC that value is = number of 8k blocks of 
ram it is to ask the system for and make use of.

The ramdisk, any ramdisk for that matter, being a 256 byte block oriented 
device without any formatting, really only needs the basic lsn0 (to identify 
it to os9), the FAT (up to 64k but typically only 3 or 4 sectors), the root 
directories fd.seg sector composed and written and a 64 byte root directory 
written in the next sector.  Formatting the whole capacity of a ramdisk disk 
is a huge waste of processor time.

myram I _thought_ was in the 3rdparty directory, but seems to have been 
dropped from recent (3.2.6-3.2.8) nitros9 distributions.  I only see it in an 
older /opt/os9/3rdparty directory here on this linux  machine.  But it still 
works, I have a boot disk of 3.2.8 that includes it.

Why was it dropped, Boisy / Robert?  It is good solid, bulletproof code, but 
then I'm biased since I wrote it.  :-)

Anybody that wants to play with it, I can email it to you privately.
The archive is about 7k, in lzh format.

In reading my old docs, I see that it may not set the creation date in lsn0 
correctly unless it is actually in the os9boot file, something about access 
via the F$Time function requires it to be in the system ram image for valid 
access to direct page 0 by the F$Time getstt.  The latest version also self-
adjusts to the cpu its running on, falling back to older, slightly slower 
code for the 6809's.  And slower is relative, IIRC megaread time is 11 
seconds on my 6309, and 13 seconds on a 6809.

>At this point /r0 is ready to use. Also note that I used r0_128k.dd as an
>example, but you can use either of the r0_8k.dd, r0_96k.dd, r0_128k.dd, or
>r0_192k.dd descriptors as appropriate.
>
>--------------------------------------------------
>From: "Wayne Campbell" <asa.rand at yahoo.com>
>Sent: Friday, November 20, 2009 11:45 PM
>To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>Subject: Re: [Coco] the final stage of optimization
>
>> When I wrote DCom I used a RAM disk. I recommended the use of a RAM disk
>> as it did speed up the program significantly. With the current setup I'm
>> using, I am unable to setup a ram drive. The NitrOS9 disk image I'm using
>> is not a proper system master, and I'm spending all of my available time
>> working on this project. I just don't have time to try to figure it out
>> right now. I'm attempting to get the copy of the OS9 system disk to boot,
>> but for reasons unknown the screen comes up black-on-black with a magenta
>> cursor, and the display commands don't change it. If I can't see what I'm
>> doing, I can't work on anything. So, I make do with what I have.
>>
>> The sort I'm using is based on the bubble sort, but instead of repeatedly
>> starting at the top and working to the bottom, it souts back upward when
>> it gets to the bottom. This way, it is constantly sorting in both
>> directions, and uses fewer iterations of the loop. It proved to be over
>> twice as fast as top-to-bottom-top-to-bottom.
>>
>> Thanks for the tips. I've heard of mergesort, but have never seen it in
>> operation or looked at its code. I know there were many things developed
>> on the mainframes for dealing with massive volume sequential data, but
>> I've never been around it. Always looking from a distance. I'll see what
>> I can find on the web.
>>
>> Wayne

[...]

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

It's currently a problem of access to gigabits through punybaud.
-- J. C. R. Licklider

From operator at coco3.com  Sat Nov 21 15:36:52 2009
From: operator at coco3.com (Roger Taylor)
Date: Sat, 21 Nov 2009 14:36:52 -0600
Subject: [Coco] 2GB MicroSD Drive Pak Question
In-Reply-To: <827597.98892.qm@web30207.mail.mud.yahoo.com>
References: <827597.98892.qm@web30207.mail.mud.yahoo.com>
Message-ID: <6.2.5.6.1.20091121140358.04cd5630@coco3.com>

At 08:44 PM 11/20/2009, you wrote:
>Howdy All,
>
>Just wondering if the new 2GB MicroSD Drive Pak will let you mount 
>disk images directly or will we need to somehow un-compress and 
>transfer the disk image contents to the SD card.
>
>If disk images are supported what formats will be supported and also 
>will virtual hard disk images be mountable as well?
>
>Looks like a great product! I saw a similar SD card for the Apple II 
>series of computers but it did not support mounting disk images, you 
>had do un-compress the images and copy the contents to the SD Card.


I'm assuming that the Apple SD gadget isn't a floppy drive/disk 
emulator?  If it was, then mounting of images would be the main 
feature.   I stand by my word that software is the key to making or 
breaking a hardware idea or product.  A bare flash pak or MicroSD 
card pak without good support software might as well be a drink 
coaster.  CoCoNet centralizes multiple disk drive systems so you can 
transfer between real disks, MicroSD disks, and PC or web hosted 
disks.  To Disk BASIC, they're all the same disks.

The Drive Pak uses the CoCoNet ROM, meaning you get bitbanger and 
RS-232 Pak drives (using the CoCoNet server on your PC), MicroSD 
disks, and real disks.  I'm adding one RAM disk this weekend, 
bringing the total to 5 base types of drives/disks, 4 of which are emulated.

The answer to your question about virtual hard disk images is 
Yes.  Without getting into a lot of nitty gritty detail about how it 
works, you'll get a partition manager already on the pak in the main 
DOS partition.  Using it you can add more from a menu which lists 
items such as 30mb OS-9 mass drive, 15mb OS-9 mass drive, or larger 
or smaller drives of various types (although the type is currently 
insignifant).

 From DOS you get as many 256-disk partitions as your card will hold, 
or as many OS-9 mass drives as it can hold, or any mix or any size 
partitions.  You're in control.  If you want partitions for other use 
than virtual disks, just create them, mount them from DOS using the 
DRIVE#="" command and use the special DSKI$/DSKO$ instructions to 
access the raw 256-byte sectors.  You can have a ~1gb partition if 
you like and use it for data logging, music playback, or whatever 
idea you come up with.

Ok....  The CoCo starts up with the CoCoNet ROM and if the Drive Pak 
is present, it mounts your preferred partition of 256 floppies and 
looks for *.BAS or an OS-9 track on Disk #0.  To change the default 
auto partition you simply issue the command DRIVE#="DOSFD0" or 
DRIVE#="ALLGAMES" or DRIVE#="GRAPHICS", etc.  That's a whopping 768 
virtual disks right there if you wanted.  Anyway, the next time you 
boot, disk #0 will be mounted in the partition you last changed 
to.  The commands are pretty easy to use because they fit closely 
with the existing Disk BASIC command set.

One thing some might gripe about is my use of DRIVE 0,ON or 
OFF.   "ON" turns on the Real 1793 controller for that drive.  OFF 
turns off the real drive and switches to whatever virtual drive you 
had mounted there last.  A bit flag is used to keep up with this 
info.  DriveWire annoyingly uses OFF to enable the 1793 FDC.  Again, 
start y'er gripin' but I think my approach makes more sense since the 
1793 is still considered the primary drive system.

CoCoNet starts up with each of the 4 types of drives mounted, 
smart-sorted based on availablility, where Drive 0 is always a type 
that is available... if all fails, including a 1793 FDC, 
RS-232/Wireless Pak, Drive Pak, then the bitbanger port is sorted to 
the Drive 0 position, and *.BAS or OS-9 is searched for on startup, 
automatically.

I've tested CoCoNet in the Wireless Pak, Drive Pak, and just an EPROM 
Pak, and the CoCo always boots up and looks for what it needs to get 
you launched off into anything you need without touching a key.

When you type "DRIVE" alone, you get a listing of the 4 drives and 
their types.  When you type DIR, you also see the drive # and type 
that is mounted there.  This helps prevent any confusion or mistakes.


-- 
~ Roger Taylor



From robert.gault at worldnet.att.net  Sat Nov 21 23:23:32 2009
From: robert.gault at worldnet.att.net (Robert Gault)
Date: Sat, 21 Nov 2009 23:23:32 -0500
Subject: [Coco] Coco 1 question
In-Reply-To: <000801ca6ada$bd94a290$ecfd3918@jeremy4b3f9678>
References: <000801ca6ada$bd94a290$ecfd3918@jeremy4b3f9678>
Message-ID: <4B08BCC4.8090702@worldnet.att.net>

Jeremy Michea wrote:
> Hi.
>
> I picked up a Coco 1 and with manuals and 6 rompaks for $10 at a charity garage sale today and I looked at the model number on the back - 26-3004A. I can't find much info on this particular model. How much memory would this unit have and what's the difference between it and the 26-3004?
>
> Thanks

The A series was, I think, the last of the Coco1 models.
The list of changes include:
easier to service PC boards
different shielding of the RAM and SWAM chips
transformer relocation
723 precision regulator; 5+ no longer adjustable but set by 1% resistors
-5v is a zener diode and resistor
heavier duty cassette relay powered by +12v
diode protection of some ICs
keyboard is conductive rubber, not mechanical
6822 PIA for keyboard instead of 6821; 6822 is open-collector
MC1372 modulator circuitry improved
RF bypassing on PC board now meets FCC requirements
RAM now uses 16K or 32K not 4K chips
jumpers indicate total RAM

Total memory could be 16K or 32K RAM plus 32K ROM. You won't know unless 
you open the case and look or enter PRINT MEM. With 32K RAM you will get 
22824.

From rcrislip at neo.rr.com  Sun Nov 22 00:16:32 2009
From: rcrislip at neo.rr.com (richec)
Date: Sun, 22 Nov 2009 00:16:32 -0500
Subject: [Coco] Caring for a CoCo
In-Reply-To: <20091121.080427.13706.0@webmail10.vgs.untd.com>
References: <20091121.080427.13706.0@webmail10.vgs.untd.com>
Message-ID: <200911220016.32326.rcrislip@neo.rr.com>

On Saturday 21 November 2009 09:04:27 Tony Podraza wrote:
> now, THAT"ll wake you up!!!!!
> 
> You can also find a bad cap that's been setting a very long while
> when you first apply power.   They usually explode and
> catch fire.   I found a few using this method too.  :)
> 
> Roy
> 
> ____________________________________________________________
> Save on Life Insurance
> Protect Your Loved Ones with Affordable Life Insurance Coverage.
> http://thirdpartyoffers.juno.com/TGL2141/c?cp=4najfRyShpoNoZWtRyYCwgAAJ1CMG
> lx2Pi3jwjncgcBXdehhAAQAAAAFAAAAAFaAVD4AAAMlAAAAAAAAAAAAAAAAAAQlQwAAAAA=
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
Had that happen to two HP DC530s. Plugged the AC cord into the power supply 
and BLAMB!!! Sparks!! Smoke!!! BANG!!! then nothing. I was somewhat nervous 
about plugging the thrid one in 8-). But it did not go nuclear as the other 
two had and it is now sitting under my dc7700 on my desk being used as a 
VirtualPC lab tester for the classes I teach. Aanndd it now has 3gig of RAM 
thanks to the other two 8-). Sure got my heart going pitty pat though.

From asa.rand at yahoo.com  Sun Nov 22 01:36:02 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sat, 21 Nov 2009 22:36:02 -0800 (PST)
Subject: [Coco] [Color Computer]  the final stage of optimization
In-Reply-To: <he8pc9+soma@eGroups.com>
References: <he8pc9+soma@eGroups.com>
Message-ID: <730127.25666.qm@web53706.mail.re2.yahoo.com>

jdiffendaffer(sorry, but I don't know your name)

Thank you for this explanation! It has opened my eyes to a few concepts I'd heard of years ago, and had forgotten. Back then, I didn't understand what I was reading or hearing as well as I can today. The concept of dividing the work in half with each iteration makes sense. The only way it goes through all of the records is if the match is the last record.

I'm going to be working on this as soon as I've finished with the optimizations. I've learned a few things from the doing, which I will address in a separate post.

I think I will be able to speed up those searches and sorts now.

Thanks, again, for the help.

Wayne





________________________________
From: jdiffendaffer <jdiffendaffer at yahoo.com>
To: ColorComputer at yahoogroups.com
Sent: Sat, November 21, 2009 5:19:04 AM
Subject: [Coco] [Color Computer]  the final stage of optimization

Wayne

If you are using strings you'll need a table of pointers to the actual data so you don't have to move strings around, which is much slower than pointers.

First, sorts.

The concept behind all good sorts, is to move out of place data as close to it's destination as possible with each pass.  That usually means as far as possible with early passes and smaller and smaller distances with each additional pass. 

The easiest sort I think you could use is the comb sort.  It's a modified bubble sort where you compare the first item against the middle item to start and step through until you get to the end with the 2nd pointer.

Each time through you are moving data a large distance instead of bubbling it up one at a time.  This eliminates what's known as "turtles", an out of place data item at the end of the list that slowly bubble up to their destination.

Depending on how out of order the data is, combsort can actually beat the quick sort.  One is better at best case and the other is better at worst and on average they are pretty close.
You'll also find combsort easy to implement iteratively (simple loops) where most quicksort examples use recursion and require more stack space.  For a small memory environment and with unpredictable data size that's pretty important as you could overflow the stack.

The Wiki talks about dividing the gap by 1.3 but to simplify things you can divide by 2 (just a bit shift in assembly).  It will cause more passes as the gap shrinks but for a data set like this you won't really notice.

http://en.wikipedia.org/wiki/Comb_sort
http://en.wikipedia.org/wiki/Quicksort


For searches you want a similar concept.  Get as close to the data you are searching for with each pass as you can.

In other words...
sort the data or you have to search.
Then do what is called a binary search.  
It requires three pointers.
Set the first to the first data element, the 2nd to the last data element and set the 3rd to the midpoint of your sorted data.  
pointer3 = (pointer2 - pointer1 / 2) + pointer1.

Check to see if your target value is greater, less than or equal to pointer3 (data block midpoint).  
If it's equal, quit.
If it's less than, set pointer2 to pointer3 - 1, greater than set pointer1 = pointer3 + 1.
Recalculate the midpoint and go again till you find your data.

You split the data in half each pass of the search and check to see which half your target value is in.  Then you split that in half etc... until you find what you are looking for.

As is typical for computer science the author of the Wiki made the explanation more complex than it needs to be so I included another link.

http://en.wikipedia.org/wiki/Binary_search_algorithm
http://www.ensta.fr/~diam/c++/online/notes-cpp/algorithms/searching/binarysearch.html

-quoted text---------------------------------
I have been aware that the one thing that is slowing decode down more than anything else is having to use disk files to store, search and sort records. This email concerns searches and sorts.

I have never really gotten a good understanding of how search and sort algorithms are designed, and how they operate, beyond the least complex. When I wrote DCom, I wrote sort procedures that were recursive. They worked, but I never really understood if they were working efficiently or not. I do know that the sorting operations were faster after they were modified.

In decode, I am using a simple search algorithm. Basically, it starts with the first record, and continues reading each succeeding record until either a match is found or the last record is read. The number of records that get added to the file depends on the I-Code being decoded. The more records in the file, the longer the search takes.

Three files are created, variables reference, line reference, and literal reference. Decoding createmsg (one of Ron's modules, about 2K in size), the decode takes about 20 minutes. Decoding RConfig (another of Ron's modules, about 16K in size) takes about 40 minutes. Decoding decode (20K) takes 2 hours.

I have the same problem with my sort. I'm using a sifter-style (for lack of a better term) of sort. It starts with the first record, proceeds to the last record, then performs the sort in reverse, starting with the last record and proceeding to the first. Each pass of the routine performs both of these operations. It works, and it was much faster than using the top-to-bottom method I first used that was based on the search routine. However, it takes as long to sort the literals records as it does to decode the instruction section of the I-Code module.

There has to be a better way. Can someone help me understand how to make my search and sort algorithms faster?

Wayne 


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco



      

From asa.rand at yahoo.com  Sun Nov 22 02:14:56 2009
From: asa.rand at yahoo.com (Wayne Campbell)
Date: Sat, 21 Nov 2009 23:14:56 -0800 (PST)
Subject: [Coco] a couple of programming questions
In-Reply-To: <4B069171.3090907@worldnet.att.net>
References: <986279.79350.qm@web53711.mail.re2.yahoo.com>
	<4B060F8C.2080101@worldnet.att.net>
	<934244.80719.qm@web53710.mail.re2.yahoo.com>
	<4B069171.3090907@worldnet.att.net>
Message-ID: <887183.18811.qm@web53708.mail.re2.yahoo.com>

Robert

I did the work, and I got results. The displays are noticeably faster. The initialization of the strings that contain the display strings and format strings takes less than a second (done at startup, before anything is displayed). The numbers. Well, I still haven't tallied the final count, but I've added over 150 string variables to contain the string parts, including the ones that contain the parts merged together to form longer strings. The average size of the instructions that previously contained the literals is cut by over 50% per instruction.

Size? The program is ~3K larger, and the data size is ~2K larger. Interestingly, the program is not slower. It is only marginally faster in execution of the overall code, however. With createmsg (I mistakenly typed 20 minute decode, when it was 2:10) the decode (over 2 runs) was 2:09 and 2:10, so maybe a few tenths of a second faster, maybe?

RConfig, the 16K procedure, went from 43 minutes to 44 minutes. I think I have an idea what caused that. I have the strings DIMed between variables that the program uses alot. I need to reposition the strings so they are at the bottom, so they will be placed at the end of data memory. This may speed up the execution time some.

I found that the code was definitely less lengthy in the print statements. For example, this:

PRINT USING "s5,i5>,x11,s6,i5>,s6,i5>,s6,i5>,s6,i5>","(80) ",b80,"|(85) ",s85," (F2) ",sf2,"|(F6) ",ff6," (89) ",f89

became this:


PRINT USING fmt20,cB80,b80,cS85,s85,cSF2,sf2,cFF6,ff6,cF89,f89

Much smaller. I believe that Basic09 accesses string variables faster than it builds a string from a literal, but I have no data to verify that.

I chose not to do the same optimization with numeric literals for one primary reason. There is no significant gain. There are no savings on anything that has a size of <4 bytes. A null string, for example, results in 2 bytes of I-Code, 90 FF. A byte literal also results in 2 bytes of code, 8D <byteVal>. A integer, and a hex integer, both result in 3 bytes of code, 8E (integer) or 91 (hex) <intVal>. Since all variables use 3 bytes of code, <token> <pointerInt>, you add a byte for each null string or byte literal. There is no difference with integer and hex.

Real values use 6 bytes, 8F <5-byteRealVal>, and are therefore good candidates for optimization, especially if they are recurring. But even one occurance would be better optimized, since the variable reference is half the number of bytes of code.

Any string 1 character or larger is a good candidate for optimization. Take " ". This one character is more used in most programs than any other character as a single-character literal. If you DIM a 1-character string, and assign it the value " ", then use it in every place where you used " ", you have added 1 byte to the data storage requirement, and 1 additional reference.

Let's say you have " " 50 times in your code. That's 50x3=150 bytes of code (50 x 9020FF). Dim the string. The assignment adds one reference, so you now have 153 bytes of code, instead of 150, and your data size is 1 byte larger. Why spend the space? Because RunB is going to retrieve that space character from the data memory and display it faster that it will calculate the value of the " " literal, especially if it has to recalculate it 50 times.

In my tests, I broke every string down to its parts and then isolated each different part. There were many like-occurrences, like "Variable" and "Variables", and repeat occurrences, like "Display". Once I had broken everything down, I found that I had many strings that could be put together to form the longer strings. I went the distance and optimized it as much as I could. Was it worth the time it took? Yes. Besides the fact that I see the displays happening more quickly, I also now see better what could be done less intensively, and without detriment to the overall execution speed.

Wayne



________________________________
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, November 20, 2009 4:54:09 AM
Subject: Re: [Coco] a couple of programming questions

Wayne Campbell wrote:

> I'm going to test a version of decode with all of the changes/additions to see what it does. I'll report back with some results in the next day or 2.
> 
> Wayne

Now you're cooking! Running this test is the only way to tell which version would be optimal or if any differences are even detectable.

In general, a one time use of just about anything in a large program probably won't require optimization. Code that is often used or is an obvious bottleneck is where optimization give good results.

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco