apple2freak{at}gmail.com wrote:
> On Mar 4, 2:23 am, "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.

But the firmware was only the much smaller *implementation* part of
the problem--the *exploitation* part was the system and application
software to make the new, higher-res modes useful--and no one has yet
stepped up to the plate for that task.

> 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.

Tedious for some, but potentially much more efficient--a critical
requirement for a 1 or 2.8MHz system.  Of course, with built-in
acceleration, that requirement is relieved--now "bloatware" would
be adequate to the task.  ;-)

Seriously, the details of implementing QuickDraw are far from trivial.
(For a long time on the Mac it was all 68000 assembly language.)

> [...]
> 
>> 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.

Right.

>>>> The educational benefit of the Apple II (un-enhanced) is
its simplicity,
>>>> 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!  ;-)
>>> I agree.  The 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.  The minimal level of integration of an Apple II
>> 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.

Actually, the logic implemented in the IOU and MegaII are not fully
understood--only the functional behavior.  The implementations of
the Apple II logic functions is quite different from the TTL 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.

So to "tap" a logic level in the system, you must re-compile the FPGA.

Not long ago, I implemented interlaced Apple II video with only a diode,
a resistor, and a couple dozen lines of assembly code.  And any Apple II
in the world could duplicate my experiment with the same simple hookup.

Requiring some fluency in an FPGA development environment is a very
large barrier to entry in comparison (and it runs as bloatware on a
much more complex system).

I understand that all these things are easy for one who already has
the toolchain and the experience--but both are much more complex than
an Apple II and its Reference Manual.

>> 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).

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.  ;-)

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

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.

The bad news is that modern devices are not built that way--to get
that kind of electronics, you have to go "retro".

>> 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'm aware of FPGA toolchains, but what would be needed to spur
experimentation would be at least a library of Apple II-related
blocks:  address decoders, ROM expansion space logic, etc., that
would raise the level of design somewhat.  Modifying an existing
"prototype" design would be a good start, but playing with FPGAs
is not as easy as playing with jumpers and TTL gates--unless one
is already familiar with the tools.

>> I agree that this would be an interesting system for many.
>>
>> But what on your list is not satisfied by an emulator?  Cycle-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).

Yes, but they support plug-in peripheral cards--an important part
of making the system authentic from my point of view.  (Of course,
that's pretty expensive compared to a real Apple II.)

> 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.

As one who has used an Apple II almost continuously over the last
28 years, I can say that I have experienced practically no problems
related to the reliability of the logic or the construction of the
Apple II systems I use.

I have had one power supply failure (easily fixed), one crystal
failure (random), and one mechanical failure of a bypass cap (I bent
it too often while inserting and removing a Zip Chip ;-).

I'd guess that I have cleaned the contacts on about a half-dozen
peripheral cards in 28 years to fix an unreliable contact--hardly
a major issue.

The rumors of the demise of 1980s-vintage TTL machines and sockets
are grossly exaggerated and unreasonably feared.

Quite to the contrary, I've dropped things (metal things) into my
machines (which always run with the tops off), tapped into them for
power, and attached dozens of probes, all without undo concern for
ESD or other issues.  I've caused ICs to heat until they were much
too hot to touch (I'd guess around 80 degrees C) and all of this
without inducing any failures!

Apple II's are amazingly robust in comparison with modern chips!

>>> The ability to use existing cards is not important if they can  be
>>> 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.  ;)

I'm probably one of them--but I'd hate to reverse-engineer every card
just to try it out.

>> 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.

Right, but some of these would take a lot of FPGA!

And the point is that if I have one to plug in, it's no trouble at all.

>>> 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).  ;-)
>>
> 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...  :)

In the early 1990s, as cellphones were beginning to proliferate, I
noted that we would certainly need a dynamic priority system for
disabling/enabling the ringer based on the caller's identity, the
caller's stated priority, and the callee's selectable interrupt
level.  It amazes me that we continue either to give everyone in the
world NMI priority or we disable all interrupts--much too primitive!

>> Similarly, your distaste with modern systems and their endemic bloat
>> is something that I can appreciate--when I choose to.  But 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.

Hear, hear!

>> 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).

OK, so I'll erect a solar panel.  ;-)  I'm willing to pay for my
retro enjoyment, including making it carbon-neutral.

And the 50 Watts that my //e and monitor use are nothing compared
to the 220 Watt monster that I need to communicate and program
FPGAs.  Then there's the 160 Watts of fluorescents that light my
lab space.   ;-)

> 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.

Now there's a challenge!  I challenge anyone to create a functional
Apple II design using fewer gates than Woz did!  It may be possible,
but it certainly isn't probable, since he was a master as simplification
and parts reduction.

And my point was that a "minimal" FPGA implementation is much more
profligate with transistors than the TTL implementation, just as an
FPGA implementation of the 6502 will use *many* more transistors than
a real 6502.

>> 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.

At an architectural level, that is of course true for any functionally
equivalent system.  But we are talking about the implementation level.

>> 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.

Software bloat is proportional to memory density, while hardware bloat
is proportional to logic density.  Memory density always wins by a large
margin.

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.

That pretty much describes the strength of human discipline.  Our
rationalization is, "It's already paid for, I may as well use it."
Or, sometimes, "If I don't use it, there will be no reason to upgrade
to a bigger system."

> 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.

I wasn't actually talking about the unused LUTs as waste--just the
intrinsic complexity of substituting LUTs for gates.  And I agree that
this is not conceptual complexity, any more than "display character"
is complex, even though it invokes half a million instructions in two
dozen DLLs.  See my point?

I feel quite comfortable with what the electrons are up to when I
type a line into my Apple //e, but I have no real understanding of
what they are doing when I type a line into my "compose" window.

That makes no difference to one who doesn't think about electrons,
but I do!  I realize that this is a mental model issue--but that is
exactly what is lost when twenty layers of abstraction cover up the
underlying reality, and that is what leads to incomplete understanding.

>>> 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...  And what about that rare card I just bought
>> on eBay last week?  ;-)
>>
> Sure, some cards would be much more difficult to emulate than others
> -- I accept that.

Good.  I don't.  I want to plug in the card, and maybe even fix it.
For me, the original hardware is an essential part of the experience,
but I can appreciate that that is not so for others.

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

Of course, and others that never existed--that's why I like the
CarteBlanche!

>> These are the reasons that I prefer (mostly) to use a real Apple //e
>> with a CFFA and accelerator.  I 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?

Then you can appreciate that you don't really need a VGA display for
80 columns of text!

I see three possible motivations for VGA output from an Apple II:

1. Worry that NTSC monitors will all die.
2. Desire to share a single VGA monitor with an Apple II.
3. Desire to implement higher-res VGA modes for the Apple.

I note that NTSC monitors are famously reliable and easily repaired, so
the first reason doesn't convince me.

I like to keep my Apple II in a different room from my PC, so the second
reason is not important to me.

I have no desire for graphics modes that are non-native to the Apple II,
since they would be purely experimental and otherwise unsupported.

So, as you can guess, I have only a slight interest, more curiosity
actually, regarding VGA video from an Apple II.  (I'm somewhat more
interested in faithful emulation of an NTSC monitor on an emulator's
VGA display.)

>>> I gather from your home page that you enjoy tinkering with the
>>> hardware as well!

>> Yes, I do!  I particularly like pushing the limits of what the original
>> hardware can do, with the right software and, occasionally, a little
>> hardware assist.  (Adding a full peer-to-peer network function like
>> NadaNet required adding two transistors, for example.  ;-)
>>
>> In my book, the spirit of Woz was always doing something astonishing
>> with practically nothing but cleverness.  ;-)
>>
> 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.

Clearly, it is not.  I regard that as their loss.  By surrendering the
artistry and craft of programming, they deprive themselves of much joy
and self-expression.

> 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.

Woz designed such a system.  ;-)

>> I find the CarteBlanche idea very appealing.  The 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?  :)

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

The "new substance" that the FPGA implementation provides is dynamic
reconfigurability, which requires and justifies lots more transistors.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
--- SBBSecho 2.12-Win32