Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

["Michael J. Mahon" <mjmahon@aol.com>]

Mark McDougall wrote:
> Michael J. Mahon wrote:
>
> > > 1. Implement a native 6502 to run as fast as possible. Of course the 
> > > core only has to be instruction set compatible, you can redesign the 
> > > bus architecture whatever way you like.
> >
> > And there goes Apple peripheral compatibility--I'm out.
>
>
> Exactly.

But that's the point of a hardware implementation as far as I can see.

Why else would I want to have a hardware implementation, rather than
a light, compact laptop with a bright, beautiful display and modern
keyboard and mouse, etc.?

Is it because you want to sell an "Apple II DTV" at a $19.95 price
point with built-in games?  I think not--and of course there would
be no point in greater speed for playing games, anyway.

The only thing I can see that might make sense is an Apple II "C-one"
that dozens of enthusiasts might buy for $300 because...1) they can
say that they bought one, 2) they want modern hardware to plug their
old hardware into (since no one will ever clone their robot control
board), or 3) they want a polymorphic platform that they can coax into
doing almost anything because everything is done in one or more FPGAs.

Are we talking about any or all of these?  Number 2 is the only one
that makes much sense to me, personally, but I'm sure that others have
other ideas.

That's why I keep asking:  "What is the objective?"

> > I'm also not inclined to expect anyone's pet 6502 project to be anywhere
> > near as "optimized" as a commercial RISC core, let alone as optimized as
> > a modern superscalar, multilevel-cache processor.
>
>
> I'm talking about comparing a 'pet 6502 project' with a risk core 
> running in the same FPGA. And don't be so quick to equate 'commercial' 
> with 'quality'.

Fair enough.  ;-)  But I was thinking of the cores often distributed
by the FPGA manufacturer, and you can be pretty sure that they've
been well tweaked, since the manufacturer's performance will be
judged by what they achieve.

> > You *assume* that bus compatiblity is not necessary
> > You *assume* that I/O is not a factor in system performance
> > You *assume* that any RISC core used for emulation would be off-the- 
> > shelf
> > You *assume* that the number of RISC instructions executed is a 
> > critical factor in performance
>
>
> Huh? I'm assuming nothing of the sort! IIUC, you're trying to convince 
> me that, given the same silicon, a RISC core interpreting 6502 code can 
> be made to run faster than a native 6502, optimised implementation. And 
> you'll never be able to convince me.

Actually, I was trying to convince you that a memory-cycle faithful
implementation/emulation of a 6502 would have about the same performance
at the *system* level for either approach--because the processor speed
between I/Os is not the critical factor determining system performance
after a modest speed increase (say, 20x) is achieved.

Again, *what* is the system-level benchmark that people want to
run faster?  That benchmark is the very *definition* of what it
means to run faster at a system level.

Of course, in any real situation, there is a representative suite
of such applications, but not a single one has been named here!

If you want a program that doesn't do any I/O to run faster, what
is it?  And if it *does* do I/O, how long does that I/O take compared
to the total processor time to run the application?

Believe me, as a processor designer, I really understand the fun of
designing a processor that can get through x instructions faster than
the next guy--but that is sometimes very weakly correlated with the
resulting system-level speed.  Many times, it just means that the
system will "wait faster" for something else to happen.

The expressed interest in a faster Apple II suggests that people
are currently experiencing dissatisfaction with waiting for their
Apple II's to do something they want done.  If you want to make
them more satisfied, it is *critical* to understand *what* they
are waiting on that is making them dissatisfied!

> > --I say that each memory access takes several times
> > as long as a RISC instruction, and that many instructions will be 
> > executed in the latency shadows of the memory accesses.
>
>
> You even hint at it yourself - any core interpreting another is going to 
> require *several* memory accesses per emulated instruction. You may 
> throw caches and pipeling etc at it as you like, but my argument is that 
> I can do that with an optimised 6502 core too...

Right, and you will have the same number of 6502 memory accesses, which
will limit you to the same effective speed.

Remember that I *continue* to talk about a design that hits memory
just as a real 6502 would, since I *continue* to want bus compatibility
(in "slowdown" mode).  So for me, requiring all the memory accesses of
a real 6502 is a feature, not a bug.  A RISC emulator running out of
cache would do exactly the same memory accesses, and no more (all the
interpreter code and data fits in cache).  (If RISC cores in FPGAs can't
have, say, 64KB of cache or ROM, then I'm wrong...)

I agree with you if all we are discussing is a processor design that
can execute disembodied 6502 code blindingly fast.  But I want it to be
able to control real Apple II peripherals and run real apps.

As I said earlier, if it can't control cards on the bus, then I'm not
interested, and see no advantage to a hardware implementation over
software emulation on a modern laptop, and lots of disadvantages.

Maybe the best of both worlds would be a fast, hard implementation for
"fast" mode, and an emulated 6502 for driving the bus in "slow" mode...

> > I know all about theories of performance, and more than a little about 
> > performance realities.
>
>
> I'm sure you do, just as I have had experience in implementations and 
> performances of FPGA-based CPU cores and associated bus architectures. 
> Perhaps the problem is we're simply arguing at cross-purposes here?

Clearly, we were.  I think I understand where you're coming from now.

Do you see my concerns about real system speed, with I/O and bus
interfacing thrown in?  In the limiting case, the processor time
goes to zero, and you're still left with all the disk spinning,
speaker clicking, screen animating, and printer printing, not
to mention all the user-input-waiting.  ;-)

I still wonder what it is that folks who want to "burn Apple II rubber"
are actually wanting to do faster...particularly when modern computers
already run good *emulators* at such high speed and, on the other hand,
*real* Apple peripherals are so unacceleratable.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."