On Mar 4, 2:23=A0am, "Michael J. Mahon"  wrote:
> apple2fr...{at}gmail.com wrote:
> > On Mar 3, 3:37 pm, "Michael J. Mahon"
 wrote:
> >> apple2fr...{at}gmail.com wrote:
> >>> On Mar 2, 9:26 am, mwillegal  wrote:
> >>>> On Mar 1, 8:57 pm, adric22  wrote:

[...]

> > Supporting additional (higher-resolution) graphics modes is an example
> > of an enhancement that would require significant software support.
> > Exactly how much is not really clear to me right now.
>
> If the Second Sight card is any indication, the effort is considerable.
>
Sure, but from what I've read, there was only one programmer who did
the firmware for the board.  I don't know how much time he spent on
it, though.

I know this may be considered sacrilege by some, but might there not
be some advantages to using modern systems to cross-develop for the
old hardware?  For example, if you want to use C or 6502 assembly, you
can use cc65 or ca65 on a modern machine and then enjoy all of the
advantages of a development environment like emacs.  From what I
remember when I
did a bit of Apple II programming around 20 years ago, using tools
like Merlin or the SC assembler were much more tedious and Aztec C was
nice for its time, but again much more tedious than cc65.

[...]

> Not only is the CFFA card a new "standard" for Apple II's, there
> are a couple of *fully compatible* VGA video cards becoming available.
>
> I agree with you that these are very desirable cards, and I prefer
> to plug them into a real Apple II (along with numerous other cards).
>
I like dedicated hardware of any kind.  You prefer the original.  It's
just a matter of taste.  For some people an emulator is fine.

> >> The educational benefit of the Apple II (un-enhanced) is its simplicit=
y,
> >> understandability, and easy hardware and software expandability.
>
> >> It is possible for a human being to understand *exactly* what an
> >> Apple II is doing in each and every cycle in a way that is quite
> >> impossible for any modern machine--even for its designer! =A0;-)
>
> > I agree. =A0The same statement can be made about an Apple II-series
> > machine implemented on an FPGA.
>
> True, provided that it is a gate-for-gate implementation, but I doubt
> that would be the case. =A0The minimal level of integration of an Apple I=
I
> contributes to being able to tap or probe almost every significant
> signal, and though this capability decreases as you move from the ][+ to
> the IIgs, I still find it quite useful.
>
No need for a gate-for-gate implementation.  Consider, for example,
the changes between the original Apple II (100% discrete logic) and
the Apple IIe which used some ASICs in the design.  The latter was not
necessarily a gate-for-gate implementation of the former.  Yet both
are easily understandable.  No significant changes to the hardware
were made in the interests of software compatibility.  There's no
reason that similar changes could not be made with an FPGA version.

Also, with an FPGA, it is my understanding that you can tap or probe
any signal you like by designing the system in such a way as to bring
these signals to the FPGA I/O lines.  Even better, you can simulate
the FPGA cycle by cycle on a simulator and analyze the performance of
the system in the level of detail that would make any tech using a
logic analyzer extremely jealous.

> One of the greatest barriers to understanding and experimentation with
> modern electronics is that it has shrunk to a single epoxy-blobbed
> die, rendering it completely "closed".
>
Sure, and add to that levels of complexity that are orders of
magnitude higher than what existed at the time the Apple II computers
were designed and the need to have a microscope and extremely steady
hand to solder modern devices.  It should not be surprising that the
number of hobbyists who experiment with modern electronics has dropped
considerably, at least as a percentage (Heathkit is gone, for
example).

> I suppose that one could make an FPGA-based system-on-chip
> implementation that would be supported by great user-accessible
> tools (necessarily hosted on a modern machine) which, in total,
> could be as friendly and inviting to experimentation as the
> original TTL Apple II, but that interface and tool chain would
> itself be a major part of the project.
>
The tool chain already exists.  Check out places like
http://www.asic-world.com/verilog/tools.html to see a list of tools
that support design and experimentation with FPGAs.  Many are free or
low-cost as well.  Add to this the work that Alex & Steve have done
over at http://www.applelogic.org and the only thing that might give
one pause to experiment with reconfigurable hardware is the cost.

[...]

> I agree that this would be an interesting system for many.
>
> But what on your list is not satisfied by an emulator? =A0Cycle-exact
> emulation is easily simulated as regards timing and video subsystem,
> but is not directly observable without real-time devices to interact
> with, like a Disk ][, A/D peripheral card, or annunciator outputs and
> pushbutton inputs.
>
> If peripheral cards cannot be plugged in, then you may as well adapt
> an Apple II keyboard (for the physical experience) to a PC or Mac and
> feed it to an emulator!
>
> To the extent that any new implementation is a "black box" from the
> point of view of an interested user, and does not implement all the
> standard electrical interfaces to the outside world, it cannot be
> distinguished from an emulator.
>
The hardware developed by Alex & Steve is capable of accepting Apple
II peripheral cards.  So there really isn't much difference between
using their system and a real Apple II except perhaps for that feeling
of nostalgia you get by sitting in front of the original software.  In
some ways, the experience of their system may be superior in that if
you can't locate a particular card you'd like to work with, you can
always go to the trouble of implementing it virtually on the FPGA
(assuming you can find the requisite documentation).

Also, unless you've gone to the trouble of replacing your power supply
and every electrolytic capacitor in all of your hardware with modern
replacements, plus replaced all the tin-plated sockets with gold-
plated ones and keep all the contacts on the board clean, you are
likely to run into reliability issues with the old hardware.
Actually, I'm sure you know more about this than me as I have not
owned or used an Apple II for about 20 years now.

> > The ability to use existing cards is not important if they can =A0be
> > easily emulated.
>
> That will be difficult if you have to reverse-engineer each one.
>
Yes -- that is exactly the point!  Reverse-engineering and re-
implementing them is actually fun for some strange people.  ;)

> History suggests that only a few of the most popular cards will ever
> be emulated, and there were hundreds of them--some quite interesting,
> like 68008 coprocessors.
>
Sure, but there is no reason why they could not be emulated if someone
wanted to go to the trouble.

> > Some emulators provide nearly all of these features, except for the
> > fact that they require a modern PC or Mac running a disgustingly
> > bloated operating system which requires constant maintenance and which
> > invariably leads the user to run a plethora of applications in
> > parallel which leads inevitably to attention deficit disorder!
>
> The latter sounds like a discipline problem, for which other solutions
> are much more appropriate (and valuable in the real world). =A0;-)
>
In the old days it was the telephone that interrupted my
concentration.  Now it is instant messaging and email.  No getting
around it -- it's required and expected in my line of work, but no
less annoying that the phone was 20 years ago.  Of course, the phones
were more reliable, but I guess that's evolution for you...  :)

> Similarly, your distaste with modern systems and their endemic bloat
> is something that I can appreciate--when I choose to. =A0But we must all
> learn to cope with modernity when necessity or convenience dictates.
> That is an attitudinal adjustment that is necessary if a respect for
> parsimony and craft is to live alongside Windows (or MacOS) and cars
> with 173 microprocessors!
>
Learning to cope with modernity and enjoying it are two different
things.  I think I cope fairly well with it, and actually manage to
use both MacOS and Windows (inside an emulator) on a daily basis.
However, nostalgia aside, that doesn't mean that I don't appreciate
and prefer things the way things were done in the old days where
programmers didn't use nanny languages like Java or Visual Basic and
actually understood what went on in front of the machines they
programmed well enough to squeeze nearly 100% of what they were
capable of rather than throwing around memory and CPU like it was
infinite.

> But surely you must see that an FPGA represents the triumph of
> *hardware* bloatware--using LUTs in place of simple gates, and with
> a gate-level complexity fully a factor of ten greater than any system
> you are hoping to emulate!
>
Good point, although I'd like to point out that an Apple II
implementation on an FPGA uses only about 15% of the electricity an
original Apple IIe uses, so it's a lot more efficient than the
original (versus an Apple II emulator on a modern PC which uses 300%+
of the electricity of an original Apple IIe).

Also, whilst some people may consider the unused gates on an FPGA to
represent bloat, I would only consider the system bloated if
unnecessary gates were used.  What makes you think that an FPGA
implementation would use more gates than were used in the original?
Woz was no doubt very good, but he did not have at his disposal at the
time he created the design the tools which are available to engineers
today.  These tools can automatically simplify the logic to make
maximally efficient use of the cells in an FPGA.

> The fact that Moore's "Law" has made the prodigious waste of hardware
> economical does not alter the fact that it uses hugely more transistors
> to accomplish *anything* than an implementation based on simple gates.
>
Certainly the cells in an FPGA use more transistors than the
equivalent gates in the SSI logic used in the Apple II.  However, the
conceptual complexity of the design need not and perhaps should not be
any greater than the original.

> I suggest that if you can ignore the mind-boggling waste of an FPGA
> implementation, ignoring the hundreds of DLLs required just to display
> an "x" on the screen of a modern computer is a similar
perceptual feat.
>
My Mac running Leopard is using 1.57 gigabytes of memory at present
(with 5 active applications running).  I suspect if we were to compare
the software bloat of this computer against the hardware bloat of an
FPGA implementation of an Apple  IIe, we'd find that the software was
at least a decimal order of magnitude more bloated, if not a lot more.

Anyway, my issue with bloat is mainly that it represents unnecessary
complexity which hinders understanding.  I don't care if an FPGA cell
uses more transistors to implement than a logic gate, because both are
simple to understand.  I don't consider unused cells or I/O pins on an
FPGA to represent bloat either -- they are simply unused capability.
So long as the logic implemented by an FPGA is not bloated -- and
there's no reason for it to be -- then I have no real issue with what
you term a "mind-boggling waste."  Certainly, for a production system,
the size of the FPGA would be such that the number of unused cells was
minimized.  But for experimentation with reconfigurable hardware, one
likes to have a little headroom for experimentation, so this "waste"
becomes an asset.

> > True -- if you want to be able to use old peripheral cards -- I don't
> > see the point if they can be easily emulated.
>
> Just because it's conceptually easy doesn't make it actually easy, nor
> does it make it happen... =A0And what about that rare card I just bought
> on eBay last week? =A0;-)
>
Sure, some cards would be much more difficult to emulate than others
-- I accept that.

What about that rare card you really want but aren't able to find?
Might be nice to be able to emulate it, no?

> These are the reasons that I prefer (mostly) to use a real Apple //e
> with a CFFA and accelerator. =A0I use an emulator when I need to generate
> lots of (virtually) printed output or when I'm away from my real system.
>
I completely understand.  I just bought an Apple IIe myself because I
want to be able to enjoy the nostalgia myself.  Who knows, with a VGA
adapter, CFFA, and accelerator, it probably represents a shorter path
to what I envision as an ideal retro-environment to work in than
building something with an FPGA as well.  Oh, but did I mention I like
to play with hardware?

[...]

> > I gather from your home page that you enjoy tinkering with the
> > hardware as well!
>
> Yes, I do! =A0I particularly like pushing the limits of what the original
> hardware can do, with the right software and, occasionally, a little
> hardware assist. =A0(Adding a full peer-to-peer network function like
> NadaNet required adding two transistors, for example. =A0;-)
>
> In my book, the spirit of Woz was always doing something astonishing
> with practically nothing but cleverness. =A0;-)
>
Yes, I really miss the, "spirit of Woz," in the IT world today, but I
suspect this sentiment is not shared by the vast majority of software
or hardware engineers today.

It would be neat if someone would design a system that catered to
people with the spirit of Woz, but I'm sure there's no money in it.
Fortunately, with reconfigurable hardware (FPGAs), we have the next
best thing.

[...]

> I find the CarteBlanche idea very appealing. =A0The ability to design
> a new card, move the output file to an Apple II, and then use it to
> dynamically reconfigure a card to become whatever card you like is
> a very interesting prospect.
>
> If an "Apple II peripheral card" toolkit and user interface could
> be made so that creating a new card was as easy as putting together
> Tinkertoys, that would be outstanding!
>
I gather that Alex & Steve already have a board which is pretty close
to this now.  I believe it uses an FPGA.  The question is, will you be
able to get past the, "mind-boggling waste of an FPGA implementation,"
and use one in one of your Apple II systems?  :)

--
Apple2Freak
--- SBBSecho 2.12-Win32