ComputerVoltageSources

Hi All -

We have been discussing the hardware architecture to some detail here
(which is good) but what about the a software
architecture/framework/toolkit? A good standard in this area will
facilitate code exchange and get stuff up quickly.

Mike

Good point. It would be an excellent opportunity to talk about
libraries and such. Alas, I had the same experience with include as
I did with C. I can't get it to work. I've tried it all sorts of
different ways. I've posted help on the forums. I don't know
anyone that ever got it to work. As such, all my programs are
monoliths. I do have a template that I start with but then when I
upgrade code I only sometimes retrofit it back into previous
programs.

Certainly we should define some fundamental subroutines and variable
names. I've put a lot of utility routines in my template. For
example, with the display I've written routines for byte to 3
character ASCII (e.g. with leading 0's), degrees to 3 character
ASCII, byte to SpeakJet, input averaging, etc.

If interested, I can generate a list of my 'useful' subroutines.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
<michaelmarsh@...> wrote:

>
> Hi All -
>
> We have been discussing the hardware architecture to some detail

here

> (which is good) but what about the a software
> architecture/framework/toolkit? A good standard in this area will
> facilitate code exchange and get stuff up quickly.
>
> Mike
>

I would call the guys at Basic Micro. They may not even know there is a problem, or may
have a workaround.

So far, they have been very good with person to person support.

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...> wrote:
>
> Good point. It would be an excellent opportunity to talk about
> libraries and such. Alas, I had the same experience with include as
> I did with C. I can't get it to work. I've tried it all sorts of
> different ways. I've posted help on the forums. I don't know
> anyone that ever got it to work. As such, all my programs are
> monoliths. I do have a template that I start with but then when I
> upgrade code I only sometimes retrofit it back into previous
> programs.
>
> Certainly we should define some fundamental subroutines and variable
> names. I've put a lot of utility routines in my template. For
> example, with the display I've written routines for byte to 3
> character ASCII (e.g. with leading 0's), degrees to 3 character
> ASCII, byte to SpeakJet, input averaging, etc.
>
> If interested, I can generate a list of my 'useful' subroutines.
>
> Dave
>
> --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> <michaelmarsh@> wrote:
> >
> > Hi All -
> >
> > We have been discussing the hardware architecture to some detail
> here
> > (which is good) but what about the a software
> > architecture/framework/toolkit? A good standard in this area will
> > facilitate code exchange and get stuff up quickly.
> >
> > Mike
> >
>

Of course I suggest heaping effusive praise on them for the incredible work they have
already done with a slight and very modest request ot explain a fine point of usage to a
HUGE fan and appreciator of their brilliance and overworked and under rewarded status.

Righteous indignation over a bug in FREE software will only get you laughed at and your
request brushed off "with extreme prejudice".

As always when dealing business, when in doubt, kiss ass with sincerity and enthusiasm.

--- In ComputerVoltageSources@yahoogroups.com, "Grant Richter" <grichter@...> wrote:
>
> I would call the guys at Basic Micro. They may not even know there is a problem, or may
> have a workaround.
>
> So far, they have been very good with person to person support.
>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@> wrote:
> >
> > Good point. It would be an excellent opportunity to talk about
> > libraries and such. Alas, I had the same experience with include as
> > I did with C. I can't get it to work. I've tried it all sorts of
> > different ways. I've posted help on the forums. I don't know
> > anyone that ever got it to work. As such, all my programs are
> > monoliths. I do have a template that I start with but then when I
> > upgrade code I only sometimes retrofit it back into previous
> > programs.
> >
> > Certainly we should define some fundamental subroutines and variable
> > names. I've put a lot of utility routines in my template. For
> > example, with the display I've written routines for byte to 3
> > character ASCII (e.g. with leading 0's), degrees to 3 character
> > ASCII, byte to SpeakJet, input averaging, etc.
> >
> > If interested, I can generate a list of my 'useful' subroutines.
> >
> > Dave
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> > <michaelmarsh@> wrote:
> > >
> > > Hi All -
> > >
> > > We have been discussing the hardware architecture to some detail
> > here
> > > (which is good) but what about the a software
> > > architecture/framework/toolkit? A good standard in this area will
> > > facilitate code exchange and get stuff up quickly.
> > >
> > > Mike
> > >
> >
>

That may be all we can hope for: a cut & paste library of pre-written
useful stuff with some standards so people don't get too confused.

So, just to start the conversation, I vote to keep the main loop as
small as possible through the use of subroutines and functions. Don't
use goto if you can avoid it. I realize the performance issues here,
but unless it is absolutely clear that the stack overhead is hindering
an algorithm, I suggest modularity. Both for readability and
standardization purposes.

I'm ducking now, so fire away...

Mike

--- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:

>
> Good point. It would be an excellent opportunity to talk about
> libraries and such. Alas, I had the same experience with include as
> I did with C. I can't get it to work. I've tried it all sorts of
> different ways. I've posted help on the forums. I don't know
> anyone that ever got it to work. As such, all my programs are
> monoliths. I do have a template that I start with but then when I
> upgrade code I only sometimes retrofit it back into previous
> programs.
>
> Certainly we should define some fundamental subroutines and variable
> names. I've put a lot of utility routines in my template. For
> example, with the display I've written routines for byte to 3
> character ASCII (e.g. with leading 0's), degrees to 3 character
> ASCII, byte to SpeakJet, input averaging, etc.
>
> If interested, I can generate a list of my 'useful' subroutines.
>
> Dave
>
> --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> <michaelmarsh@> wrote:
> >
> > Hi All -
> >
> > We have been discussing the hardware architecture to some detail
> here
> > (which is good) but what about the a software
> > architecture/framework/toolkit? A good standard in this area will
> > facilitate code exchange and get stuff up quickly.
> >
> > Mike
> >
>

Absolutely 100% agree. I took two years of structured Basic programming, and everthing
you said is structured basic philosophy. In structured Basic there are only two goto
statement, at the end of mainline code which says GOTO START or some condition is met
which says GOTO END. Excess use of unconditional branching (GOTO) produces
untraceable results (spaghetti code).

Structured Basic mainline code is like this:

FACTORY_JOB:

GOSUB GET_UP
GOSUB WORK_AT_JOB
GOSUB SPEND_EVENING_AT_TAVERN
LET LIVER_CELLS = LIVER_CELLS - 50,000
IF LIVER_CELLS < 0 THEN
GOTO FUNERAL
ENDIF
GOSUB SLEEP

GOTO FACTORY_JOB

FUNERAL:
END

All the primary gosubs call more detailed gosubs (JAGERMEISTER_SHOTS) and so on.

Everybody has had to cheat on this rule when they can't figure out an elegant way to
branch. But avoiding the use of GOTO is a good idea.

Since all Basic variables are global, another tip is to code variable names by subroutine.
First subroutine, all variable names start with A....
Second subroutine, all variable names start with B.....

You get the idea.

--- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh" <michaelmarsh@...>
wrote:

>
>
> That may be all we can hope for: a cut & paste library of pre-written
> useful stuff with some standards so people don't get too confused.
>
> So, just to start the conversation, I vote to keep the main loop as
> small as possible through the use of subroutines and functions. Don't
> use goto if you can avoid it. I realize the performance issues here,
> but unless it is absolutely clear that the stack overhead is hindering
> an algorithm, I suggest modularity. Both for readability and
> standardization purposes.
>
> I'm ducking now, so fire away...
>
> Mike
>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@>
> wrote:
> >
> > Good point. It would be an excellent opportunity to talk about
> > libraries and such. Alas, I had the same experience with include as
> > I did with C. I can't get it to work. I've tried it all sorts of
> > different ways. I've posted help on the forums. I don't know
> > anyone that ever got it to work. As such, all my programs are
> > monoliths. I do have a template that I start with but then when I
> > upgrade code I only sometimes retrofit it back into previous
> > programs.
> >
> > Certainly we should define some fundamental subroutines and variable
> > names. I've put a lot of utility routines in my template. For
> > example, with the display I've written routines for byte to 3
> > character ASCII (e.g. with leading 0's), degrees to 3 character
> > ASCII, byte to SpeakJet, input averaging, etc.
> >
> > If interested, I can generate a list of my 'useful' subroutines.
> >
> > Dave
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> > <michaelmarsh@> wrote:
> > >
> > > Hi All -
> > >
> > > We have been discussing the hardware architecture to some detail
> > here
> > > (which is good) but what about the a software
> > > architecture/framework/toolkit? A good standard in this area will
> > > facilitate code exchange and get stuff up quickly.
> > >
> > > Mike
> > >
> >
>

I don't care so much whether there are goto's or not. I do appreciate
comments, however. I've picked up some of other people's code with
literally no comments. Pretty hard to figure out, adapt, and enhance.

As to performance, this thing is pretty zippy. I wouldn't worry too
much about speed. And, someday maybe we can figure out how to get the
assembly mode to work.

Dave

--- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
<michaelmarsh@...> wrote:

> So, just to start the conversation, I vote to keep the main loop as
> small as possible through the use of subroutines and functions.
> Don't use goto if you can avoid it. I realize the performance
> issues here, but unless it is absolutely clear that the stack
> overhead is hindering an algorithm, I suggest modularity. Both
> for readability and standardization purposes.

It's a really good idea to mark variables that belong to a routine;
globals can really make debugging a nightmare!

I *loved* the example code. I've always wished for an infite loop when
applied to my personal platform :)

I will start to work on a basic (oops, sorry!) platform. Maybe it
will just be a standard template that folks can work from, drawing on
the cut & paste library. It might be best to do cut and paste in this
environment rather than bring in a whole mess of code from an include
or lib that won't get used (?)

Mike

--- In ComputerVoltageSources@yahoogroups.com, "Grant Richter"
<grichter@...> wrote:

>
> Absolutely 100% agree. I took two years of structured Basic

programming, and everthing

> you said is structured basic philosophy. In structured Basic there

are only two goto

> statement, at the end of mainline code which says GOTO START or some

condition is met

> which says GOTO END. Excess use of unconditional branching (GOTO)

produces

> untraceable results (spaghetti code).
>
> Structured Basic mainline code is like this:
>
> FACTORY_JOB:
>
> GOSUB GET_UP
> GOSUB WORK_AT_JOB
> GOSUB SPEND_EVENING_AT_TAVERN
> LET LIVER_CELLS = LIVER_CELLS - 50,000
> IF LIVER_CELLS < 0 THEN
> GOTO FUNERAL
> ENDIF
> GOSUB SLEEP
>
> GOTO FACTORY_JOB
>
> FUNERAL:
> END
>
> All the primary gosubs call more detailed gosubs

(JAGERMEISTER_SHOTS) and so on.

>
> Everybody has had to cheat on this rule when they can't figure out

an elegant way to

> branch. But avoiding the use of GOTO is a good idea.
>
> Since all Basic variables are global, another tip is to code

variable names by subroutine.

> First subroutine, all variable names start with A....
> Second subroutine, all variable names start with B.....
>
> You get the idea.
>
> --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"

<michaelmarsh@>

> wrote:
> >
> >
> > That may be all we can hope for: a cut & paste library of pre-written
> > useful stuff with some standards so people don't get too confused.
> >
> > So, just to start the conversation, I vote to keep the main loop as
> > small as possible through the use of subroutines and functions. Don't
> > use goto if you can avoid it. I realize the performance issues here,
> > but unless it is absolutely clear that the stack overhead is hindering
> > an algorithm, I suggest modularity. Both for readability and
> > standardization purposes.
> >
> > I'm ducking now, so fire away...
> >
> > Mike
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@>
> > wrote:
> > >
> > > Good point. It would be an excellent opportunity to talk about
> > > libraries and such. Alas, I had the same experience with

include as

> > > I did with C. I can't get it to work. I've tried it all sorts of
> > > different ways. I've posted help on the forums. I don't know
> > > anyone that ever got it to work. As such, all my programs are
> > > monoliths. I do have a template that I start with but then when I
> > > upgrade code I only sometimes retrofit it back into previous
> > > programs.
> > >
> > > Certainly we should define some fundamental subroutines and

variable

> > > names. I've put a lot of utility routines in my template. For
> > > example, with the display I've written routines for byte to 3
> > > character ASCII (e.g. with leading 0's), degrees to 3 character
> > > ASCII, byte to SpeakJet, input averaging, etc.
> > >
> > > If interested, I can generate a list of my 'useful' subroutines.
> > >
> > > Dave
> > >
> > > --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> > > <michaelmarsh@> wrote:
> > > >
> > > > Hi All -
> > > >
> > > > We have been discussing the hardware architecture to some detail
> > > here
> > > > (which is good) but what about the a software
> > > > architecture/framework/toolkit? A good standard in this area will
> > > > facilitate code exchange and get stuff up quickly.
> > > >
> > > > Mike
> > > >
> > >
> >
>