Re: A 21st Century Apple II?

On Mar 5, 9:11 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
apple2fr...@xxxxxxxxx wrote:
On Mar 4, 6:18 pm, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
apple2fr...@xxxxxxxxx wrote:
On Mar 4, 2:23 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
apple2fr...@xxxxxxxxx wrote:
On Mar 3, 3:37 pm, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
apple2fr...@xxxxxxxxx wrote:
On Mar 2, 9:26 am, mwillegal <m...@xxxxxxxxxxxx> wrote:
On Mar 1, 8:57 pm, adric22 <adri...@xxxxxxxxx> wrote:
I can't imagine someone using the old tools even on a 4MHz Apple II
being as productive as someone using a more modern cross-development
environment on a PC.  A modern editor (well, emacs isn't exactly
modern, but...) combined with the near-instantaneous compilation of
even very large (for the Apple II) programs would be responsible for a
large part of this increased productivity I suspect.

Productivity in a resource-constrained environment has almost nothing
to do with the "efficiency" of the toolset.  If it takes me a week to
input and debug my routine, that's another week of careful thought
about the code and its behavior, and another 50 improvements in both
substance and style.

I love doing this, so I'm in no hurry for it to end!  The longer I take
to do something, the better the result and the greater the joy.

I see your point. If you spend the majority of your time working out
the details of your design, then who cares if it takes 20 minutes to
assemble/compile the code when you complete it.

That's how different a labor of love is from a job!  ;-)

This is a key distinction.

[...]

Speed is nice for some things, but when it causes programs to be
developed by "tweaking" things and recompiling instead of sitting
down with a pencil and figuring it out, it is a disservice to the
programmer.

If you're involved in a labor of love, and time is of little
importance, then I mostly agree with you. OTOH, if you are working to
a schedule, and need to produce some tangible results in less time
than it takes you to develop a full understanding of the system you
are working on, sometimes "tweaking" and recompiling is the only
choice available to you.

Tweaking is, I might add, also a perfectly valid way of determining
how something functions. Contrary to Greek philosophy, it is not
necessary to examine the nature of atoms in order to determine the
nature of things built from atoms. It is also perfectly valid (as the
Chinese discovered about 200 years before the Greeks) to determine the
nature of things based on how they interact with themselves and other
things. Intelligent "tweaking" involves exactly this principle, and
is also central to the art (if I may call it that) of reverse
engineering.

In the days of batch processing, I would pore over memory dumps
until I understood every memory structure and table, often finding
serious bugs or efficiency issues that had not yet been manifested
in any other way.  The result was that each "run" led to the correction
of dozens of problems, and the program improved dramatically.

I prefer your technique when I'm dealing with code I've written
myself, but the "tweaking" technique when I'm working with other
people's code. Eventually, I develop a complete understanding of the
code in either case, although each approach has advantages and
disadvantages.

And I had immense satisfaction in achieving a *complete* understanding
of every aspect of the running code--even the ones that did not affect
the "function" of the program.  When it was possible, I enjoyed
*listening* to the execution of the program on a detuned AM radio,
which gave me a good idea of the relative speeds of various parts of
the program!

Heh. I remember being able to hear the execution on the TV set
connected to the computer with the volume turned up sufficiently high.

I'd like to think that the modern software development process has
produced something of value.  I doubt OO techniques were used to
implement QuickDraw.  One hardly needs to use an OO language in order
to benefit from this paradigm of solving problems.  It could
potentially be less efficient than a non-OO methods, but the loss
would be tiny compared to the big gain in productivity as reflected
through superior management of complexity.  I don't mean to single out
OO as the only thing that has been produced by the modern software
development process -- I'm just using it as one example.

No doubt modern development processes have value--but a detailed and
complete understanding of the dynamic behavior of the code is not one
of them.  They, like more RAM and faster processors, are geared toward
enabling things of greater complexity and bloat to be produced.  Some
of these things are very useful, but few can be called beautiful.

They represent the industrialization of a process which used to be a
work of art and craft, with all the attendant costs and benefits.

Surely, one of the primary attractions of working with old computers,
and particularly the Apple II, is an appreciation of the joy of being
on the bare, beautiful metal--just as a master woodworker would never
use a power tool when a simple manual tool provides a more immediate
experience of the texture of the wood.

As a systems engineer, I'd like to think that complexity (when
necessary) is not inherently ugly. I'll grant you that because of
human nature, unnecessary complexity is all too often employed, and in
this case, it is rightfully called bloat.

Regarding the Apple II -- it is a beautiful computer -- but the design
was constrained not only by the principles of simplicity, elegance,
and efficiency, but also by cost and the technological limitations of
the time. If you remove the latter two limitations (well, at least
the technological limitation anyway), and put yourself in Woz's shoes,
what new works of beauty might you come up with?

"The joy is in the journey, not the arriving."

Absolutely.

[...]

Given the large die sizes used in the old days, I imagine it should be
possible (given access to suitable equipment) to slice open the chip
and examine the die under a fairly low power microscope.  This should
enable reconstruction of an equivalent circuit.  Hardly worth the
effort, though, except perhaps for the challenge of doing it.  That's
assuming that Apple wouldn't be willing to provide details on the
ASICs from their archives.

Right--complete understanding is possible *in principle*, it's just not
available *in fact*.  ;-)

Or the cost/benefit ratio makes a complete understanding unattractive?

[...]

Anyway, typically FPGAs are "loaded" at power up because the
implementations are volatile, so you could choose between several
different implementations to be loaded at power up time if you wanted.

Right, I just have to produce them before loading them.  ;-)

Just like some of us like making a display driver out of resistors and
diodes, others like to create variations on old designs. ;)

[...]

OTOH, someone with a "development system" could dynamically compile a
particular "instance" of hardware they would like to use, and then
load it into their system.  This would be analagous to having
reconfigurable peripheral cards in a real Apple II except that you're
entire system would be reconfigurable.  If you got tired of the Apple
II one day and decided you wanted to try out a TRS-80, you'd just have
to create a new implementation and you'd have it.

I really do appreciate the concept of reconfigurability--and I also
appreciate that it is precisely *reconfigurability* that causes FPGAs
to be more intrinsically complex than dedicated logic.

That doesn't bother me when my objective is reconfigurability--only when
it is the default method of implementing what is not reconfigured.

Hmm. But isn't the ability to reconfigure the device a huge asset,
even when the intent of a project is not to create a reconfigurable
device? It's awfully nice to be able to correct hardware bugs by
using reconfigurable software just like it's awfully convenient to be
able to fix software bugs by reloading a device's firmware.

I have often found that relaxing design constraints results in a worse
design, not a better one.  Sometimes flexibility is the enemy!

Using an FPGA in a design does not represent a relaxation of design
constraints, although it does represent an increase in flexibility. I
suppose this flexibility may lead to sloppiness if a designer realizes
he can correct any problems that come up by simply recompiling his HDL
code, but that is human nature, and not inherent in the increased
flexibility which is also a significant asset if the systems
requirements may be subject to revision in the future.

Don't get me wrong, I'm no Luddite (no offense, Simon ;-), but what I
personally enjoy most about engineering is the solution of difficult
problems with minimal physical resources and maximal human ingenuity.

I understand and appreciate your point of view. In fact, I even share
it if you relax the definition of "minimal physical resources" to
include contemporary technologies, rather than 25-year-old
technologies. :)

I know this is unpopular these days, though there may come a time (think
desert island ;-) when it will become more practical.  One thing that I
am sure of is that I have enough versatility to appreciate both the
convenience of a Big Mac and the joy of a cake made "from scratch"--
each in its time and place.

Agreed. I suspect we'd both give up the Big Mac before the cake "made
from scratch" though...

Here, I've been putting forward the idea that the enjoyment of old
computer systems results at least partly from the ability to get away
from "up to date" industrial technology and revel in what can be done
with simple technology employed cleverly and with great skill.

Again, I understand and appreciate this.

To do otherwise is sometimes just what is needed, but is often a
symptom of "gilding the lily"--and the Apple II is most certainly
a wonderful lily.

For example, no one using an FPGA-based implementation of the Disk ][
Controller would appreciate the cleverness of relabeling the address
and data pins on the state ROM to eliminate several board vias.  ;-)

Absolutely. Such cleverness would be lost in an era where vias are a
thing of the past (at least on an FPGA anyway).

[...]

Not only is it gone, it could not exist today.  Today's "kits" are
essentially mechanical assembly, since the circuitry is both pre-
printed and nano-sized.  That kind of assembly teaches electronics
about as well as putting together an Ikea bookcase teaches furniture
construction.  ;-)

But it does exist today -- just on a much smaller scale.  Check out
www.ramseyelectronics.com for an example.

I'm familiar with Ramsey's kits--and they are perhaps the closest
surviving relative of the Heathkit.  Ironically, many of their kits
use the same types of ICs and circuit boards as the Apple II--so I
see them as confirmation of my principle.

Ramsey's kits are much simpler than most of what Heathkit offered. I
don't see any color TVs in the Ramsey catalog. Also, Ramsey doesn't
even come close to the quality present in all of the Heathkits I ever
built. Still, a number of their projects make liberal use of surface
mount components which are smaller than a grain of rice.

If you read electronics hobby magazines today (there are still a
couple), you will note that an increasing fraction of the projects
are based on programming a microcontroller--often to make it function
like a 555 timer and a couple of gates!  I love microcontrollers, but
I also love 555s and gates, and would hate to see them languish.

Which one is more applicable depends a lot on your design
constraints. With microcontrollers being very cheap now (not much
more than a 555), they are increasingly being used in applications
where less complex devices could be used. But let's not forget that
designers appreciate their reconfigurability should the design
constraints change.

Several times in my life, I've found people writing complex (and often
incorrect) code to compute a moving average that could have been
computed in the analog domain with a single resistor and a capacitor!

Unless the circuit in question had a very low output impedance, I
think you might have to add another resistor and an op amp to your
circuit above. ;)

Of course, there are the "100 experiments" packaged products, but
they are all *very* introductory.

Yes.  Good maybe for children in middle school to play with.

Or grade school.  By the time I was a freshman, I had built an
oscilloscope and was working on sweep circuits and video amplifiers
for photomultipliers.  All of my parts were salvaged from trashed
radios and TVs and a few military surplus purchases.

Ahem. How many of your peers had accomplished similar things at that
point of your life?

The good news is that electronics can still be done at the SSI/MSI
level, where functions and connectivity are visible and hackable
with inexpensive tools.

I see some nostalgia value in doing this, but I don't really think
that a whole lot of practical knowledge would be gained that would
have applicability in the world today.

Well, it would be a good foundation for someone who would then learn
about FPGAs.  ;-)  Or, perhaps, one could skip all that, the way that
engineers today skip vacuum tubes...  (Of course, that leaves them
vulnerable to "mystical" ideas about tubes and their problems.  ;-)

Vacuum tubes are essentially obsolete, so there isn't much point to
learning about them for most engineers. Someday, the same will be
said about the 7400 and 4000 logic families, so it seems to me to be
more worthwhile to teach the abstract (e.g. theoretical) concepts
first, and then these may be applied to whatever technology the
engineer happens to be working with at the time.

[...]

Breadboarding with SSI is also pretty easy, for relatively simple
functions--not implementing an Apple II, but implementing a peripheral
card.  And the difficulty of changing the physical implementation
actually motivates a designer to think longer and more carefully about
each gate and wire, and the overall design of the card.

I'll grant you that there are plenty of challenges involved in working
with 25-year-old technology and that it can even be fun. And perhaps
the discipline instilled by doing things the old ways can make a
contemporary engineer better at what he does too.

Yes, but it's worth it for some of us who would like the ability to
experiment with the innards of the system.  It also doesn't hurt to
learn a skill which is of practical value today.

Absolutely.  Using a marketable skill set to play with Apple II's is a
very understandable thing.  It's just not my thing.  ;-)

I understand that you enjoy working with the older technology.

We both appreciate simplicity, elegance, and efficiency.

I prefer to work with newer technology -- to me it represents greater
unrealized potential.

[...]

The same goes for global logic optimization.  Though the search space
is usually much smaller, it's still an NP-complete problem.

We'll never know unless someone tries it. I suspect a modern computer
could solve an NP-complete problem of the order of global logic
optimization for an Apple II computer in a couple of seconds.

What is important to me is being able to understand what the system is
doing at an architectural level.  I have at lot less interest in
knowing what the electrons themselves are doing.  I think this is the
fundamental difference in our philosophy.

Or in what gives us the most satisfaction (after all, I'm a physicist).
;-)

Now that explains a lot... ;)

It's a simple but regrettable fact that the resources required for an
implementation expand to fill the resources that are available, whether
it's bytes of memory, or transistors on a chip, or LUTs of an FPGA.

I say we should blame the marketers.  They are always pushing the
engineers to produce more "functionality" in their company's products
in order to differentiate themselves from their competitors.  How many
of us use even 10% of the features that are built into MS Word today?
Probably 90% of the useful functionality of a modern word processor is
contained within Appleworks.  They also constantly push the engineers
to produce more functionality in less time, which leads to the huge
number of layers upon layers of libraries upon which modern software
systems are built but which are primarily responsible for the bloat
which we both so despise.

I think that's an excellent description of the situation.

I also think it's degenerate, and to be regretted.

We always have ignorant customers, but we don't always have to
pander to them.  After all, we are supposed to know what's worth
doing and what isn't.

A "market-driven" company is a company without vision.  A company
with vision drives the market, not the other way around.

I completely agree with you. Know of any companies with vision?
Better still, companies with vision that are hiring? ;)

Maybe it's time to start cross-posting to rec.philosophy?  ;)

Everything is eventually philosophy.  ;-)

I again stress that my comments here are expressing my own opinions,
and are not "truth".  ;-)  The tradeoffs we are discussing are central
to modern technology, and are brought into sharp contrast in the
context of the old technology we love.  It is always relevant to
consider what we value and how it is affected by technology--something
we as a society have done far too little.

Again, I completely agree. Society has generally accepted and
endorsed technology with little regard for how it affects our values.
If you argue that this has not always been to our betterment as human
beings, I would agree with you again.

[...]

Nothing wrong with wanting to know what the electrons are up to.
However, I'm more concerned with an architectural understanding, and I
find if I focus on what the electrons are doing, my ability to
understand complex architectures is more compromised than if I don't.
I think the difference is simply in our choice of allocation of mental
resources.

I understand completely.  And I recommend "stretching exercises" to
make it easier to think across more and more levels of abstraction.
That capability, more than any other, is the key to mastering system
design.  Dividing a design up at the outset to limit communication
across levels is a sure way to get a suboptimal design--and often
*far* suboptimal.

What you say makes perfect sense when a project is simple enough to be
handled by a single designer.

Otherwise, the design should be layered with well-defined and limited
interfaces defined at each layer so that each layer may be handled by
a separate designer or team of designers with limited knowledge of
what goes on in other layers. For any project of decent size, an
approach such as this to limit the exposure of the complexity within
each layer of the implementation is necessary in order for the project
to be able to be completed by human beings in finite time.

Possibly a system such as the Apple II series represents a level of
complexity that is not far from the upper bound of what a talented
single designer is capable of.

I watched Intel do that once with a microprocessor design, and they
wound up using 5x as many people for twice as long to get half the
performance in the same silicon process!  Design methodology matters.

I agree with you that design methodology matters. I'm not sure
whether we agree that for projects of any decent size, a design
methodology that limits the exposure of complexity of the individual
pieces is necessary for the project to be realizable in finite time,
however.

I've often said that if floors were transparent, there would be no
skyscrapers!  But that applies to "users", not to the designers and
builders of skyscrapers, who must always think in three dimensions
to get correct answers.

For a skyscraper where each floor is a clone of the one above or below
it, this makes sense. However, for a skyscraper in which each floor
is completely different from the one above or below it, I don't agree.

By way of example, let's take the human body. If you lived to an
average age of 80, and began studying it at age 18, you wouldn't be
able to get through more than a small fraction of the total knowledge
that is available. And by the time you were 80, you would have
forgotten most of what you learned when you were younger anyway, plus
a lot of the information you learned would become obsolete.

Yet the human body represents a triumph of design, at least in the
ways we've been talking about -- well, elegance and efficiency
anyway. One may argue that it is a simple as it can be in order to do
what it does as well.

Someday, human beings may attempt to design something similarly
complex. Yet none of the designers could possibly understand more
than a tiny fraction of the whole. If I take your argument to its
logical conclusion, I'd say this means that human beings are limited
to designing efficient systems of limited complexity -- many orders of
magnitude smaller than that which the human body represents. But I
think that with the right tools and design methodologies it may
someday be possible to do exactly this.

We have to be able to think about all the levels of abstraction as
close to simultaneously as we can.  That's how system-appropriate
tradeoffs are made and cross-level system designs are optimized.

As a systems engineer, I appreciate what you are saying here.
However, I do not need to understand each layer of a system to nearly
the same level of detail as those who are responsible for the
implementation of the individual layers.

The most important decisions we make are which problems to solve and
which not to solve.  "Never put off 'til tomorrow what you can put
off forever."  ;-)

Wise words.
[...]

Don't they make any flatscreen monitors with video inputs any more?

Yes, but emulation hosts use VGA display modes, and emulating the
various artifacts of an analog NTSC color monitor is harder than
it looks--and it's necessary to appreciate many Apple II graphics.  ;-)

Hmm, I forgot about that little detail. It would be rather tricky to
emulate.

And it seems that VGA displays accepting NTSC input are becoming
less common, as the digital TV transition continues.

True -- I'd better buy one while they are still available!

I understand.  Woz did indeed design such a system -- for the 1980s.
Where is the equivalent system for the 1990s or the 2000s?

That is an excellent question.  I suppose we could stipulate that
as the field moves forward, so does the "entry point", and gate-level
design is now as dated as carburetor adjustment.  But to me it seems
that something is lost when logic is just "hardware programming".

Something is lost, and something is gained. Just like we lost our
tails when we came down out of the trees (if you subscribe to Darwin),
we gained in other areas (opposable thumbs).

Can we extrapolate Woz's platform from the 1980s to obtain an
equivalent platform for the 1990s or the 2000s?  What about the
critical mass required to induce people to create useful software for
such a platform?

It's more likely that they would simply download existing high-volume
cores, so that their huge software bases would suffice.

I'm sure that's what most people would do. To them the software
represents a set of tools used to get a job done, and the hardware is
simply the workbench that allows them to use their tools. Eminently
practical, and boring.

Is there another angle from which to view computing? One that would
empower a vision of what computing could be if "the spirit of Woz" was
alive today? Or is there simply no point to this line of thought and
we should just enjoy the old systems for what they are alongside the
new systems for what they are and never the twain shall mix?

[...]

Of course.  I have very good control over my attitude!

Tell me, what is your secret?  Zen meditation?  Or is it those
marvelous microbrews you have in your neck of the woods?  ;)

A lifetime of learning to deal with upsets and setbacks, and the
experience of making them "go away" by looking directly at what
I'm experiencing, which invariably shifts my point of view.

Ahh, so you're a Zen Buddhist then... ;)

I don't always succeed fast enough to avoid some suffering, but that,
too, serves the valuable purpose of reinforcement--"It still hurts
when I do that!".  ;-)

Yes, pain reminds us that we are still alive.

I think we've reached some sort of closure!  ;-)

It has been a pleasure!

--
Apple2Freak
.

Relevant Pages

  • Re: Mac Mini Review (NOT GOOD)
    ... What Apple really needs is a classical "Killer" App/Capability to push ... cores into play worthy of Apple's consideration for a mini refresh. ... with passive cooling - something that gels with Jobs austere design ... 4" wafers out of a project, which would be a nice cost avoidance if we ...
    (comp.sys.mac.advocacy)
  • Re: Aqua is a Plastic Cube!
    ... Actually, entirely "generic" parts, as Apple does not, and has not, ... mainstream, the digital audio out, the fanless design, these were ... You may argue that the Cube was hurt also by a poorly chosen ... enough empty space under the 'skirt' for a Mac mini to fit. ...
    (comp.sys.mac.advocacy)
  • Re: RFC : SOME IDEAS FOR THE APPLE II FPGAers
    ... But my motives aren't 200Mhz Apple II speed. ... II expansion bus is to be preserved in it's current state. ... used to justify sloppy or incomplete design. ... Nobody's end goals are compromised, ...
    (comp.sys.apple2)
  • Re: A 21st Century Apple II?
    ... A modern editor (well, emacs isn't exactly ... to do with the "efficiency" of the toolset. ... the details of your design, then who cares if it takes 20 minutes to ... and particularly the Apple II, is an appreciation of the joy of being ...
    (comp.sys.apple2)
  • Re: Aqua is a Plastic Cube!
    ... Actually, entirely "generic" parts, as Apple does not, and has not, ... mainstream, the digital audio out, the fanless design, these were ... enough empty space under the 'skirt' for a Mac mini to fit. ... But you don't get the artwork you need from the OS in Aqua. ...
    (comp.sys.mac.advocacy)