[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A 21st Century Apple II?
apple2freak@gmail.com wrote:
On Mar 4, 2:23 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
apple2fr...@gmail.com wrote:
On Mar 3, 3:37 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
apple2fr...@gmail.com wrote:
On Mar 2, 9:26 am, mwillegal <m...@willegal.net> wrote:
On Mar 1, 8:57 pm, adric22 <adri...@yahoo.com> 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."