On Tue, 02 Jun 2015 04:05:02 -0400, rickman <
gnu...@gmail.com> wrote:
What did you say about personal manifesto's? ...
> When I asked for more detailed timing info on the instructions
> for comms and I/O I was told I didn't need that info, I should
> just build the design code it up and see if it works.
Now, you *seem* to be embellishing your stories, like Hugh ...
Previously, you stated this about the timing info:
"I was not able to get that info as it is proprietary."
-by rickman, "GA144 in a Serious Low Power Project (SLPP)" thread,
comp.lang.forth, Jan 7, 2013, msg-id: kc7q3g$e45$
2...@dont-email.me
Was this a different situation of timing info?
If so, just how many people in the world don't
want to give you timing info?
> [...] doing Forth design for 40 years, by building and testing.
This works, but a skilled programmer generally has an idea of
what to implement, and sufficient experience in solving similar
problems to chose a path which is likely to succeed. Other
techniques like build-and-test, or shot-gun, or re-write,
or debug-it, or wing-it, or cut-n-paste, must be used too
because some people are brighter and others less so, and
there are always unforeseeable interactions. Also, the less
able the person or perhaps less well paid, the more they'll
rely on simpler techniques, because they're easier and slower.
Agree?
> To me, when I should be able to do analysis to determine
> limitations and feasibility, it just seems silly to spend
> time on building and testing only to find things don't work.
Reality simply doesn't match theory due to assumptions and
simplifications or only does so rarely. Digital circuits
should be much more precise in general than analog.
At some point, the code must be tested. So, you might as
well test incrementally. Even if you're designing something
and not just winging it, testing as you go is easier and a
bit more thorough. You can work with the code in an
intermediate form that may allow more access and ability
to test than in the final form. Even so, you should still
produce a comprehensive final test to test the design after
completion. However, there will always be some things that
simply can't be tested in the final form.
> I know I would never try to use timing loops to generate
> video signals.
Why not?
Much the same thing is done in electronic circuits.
Isn't it? I.e., imprecise methods, but good enough.
E.g., 14.318Mhz or 3.58Mhz divided down by counters
or a digital delay line to generate sync signals or
color-burst ring oscillator, or PLL, or RC timing,
etc.
> I think a simple analysis would show the lack of stability.
The obsolete NTSC televisions are very forgiving. Very few
of the early 8-bit computers generated correct horizontal or
vertical sync and they worked on almost every television.
> Timing data is just so basic to the definition of a digital
> device that I can't see any reason to not want to use it
> to save days or weeks of development and testing that might
> well prove fruitless.
Some chips simply aren't to spec because they're cheap,
or are thrown off by poor tolerance production parts.
E.g., a company I worked for designed audio circuits
using high-end video op-amps and 1% tolerance resistors,
but then they bought the cheapest audio versions of
the op-amp they could find for production and used 10%
resistors. The production op-amps had a high failure
rate, but they were unbelievably cheap. The resistors'
possibly poor tolerance had been accounted for by the
electrical engineers for most situations but not all,
i.e., two in parallel, _both_ with wide tolerances ...
> Is it typical in the Forth community to code things
> up rather than to think them through?
Was this a comment on someone here in particular?
You have to start somewhere to solve a problem.
If you don't already have an understanding of what
to solve, you'll likely have to learn something or
code something up first to attempt to obtain an
understanding of the issue(s).
Rod Pemberton
--
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?