[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Jorge Chamorro Bieling wrote:

Michael J. Mahon <mjmahon@aol.com> wrote:



Jorge Chamorro Bieling wrote:

<snip>


To run as fast as possible, the CPU has to be custom designed so as to
maximize the execution of *6502* intructions (which are at most 3 bytes
long), that's why I thought about a 3 bytes bus. 
(later I found that a 3 bytes bus is odd to design for a number of
reasons, so I think it should better be 4 bytes wide)


It doesn't have to be a "bus", it's just a 3-byte "pull" from memory.
And 3 is a lot easier than 4, since 3 bytes can't cross two 2-byte bank
boundaries, and 4 can.

Think in terms of loading a 3-byte register from an arbitrary byte
address in a memory composed of two 16-bit banks...



Sounds good to me, Michael has flipped the bit to more positive,
constructive posts... Thanks :-)

I get the idea...



And (again) I don't agree with Michael when he says that :



"And there goes Apple peripheral compatibility--I'm out."



This does not mean that.

It's the MMU task to interface to the real Apple II in which this thing
should (hopefully, sometime) be plugged in.


Then you will have to slow down to 1MHz in the I/O space, and beyond a
relatively modest speedup (say 20x), it will not change system-level
performance much if you go faster between slowdowns--that was my point.

To understand this quantitatively, you have to pick an application or
a suite of applications that are important to users.



Yes, every access to I/O space puts the whole thing into a slow cycle.
You don't need to think any further than $c000, which is being called
all the time. That's a big bottleneck. But this particular one can be
fooled by some kind of intermediate "buffer", latch or something. The
idea is to sowehow reduce the number of *real* accesses to MLB's $c000,
done in a way that is transparent to the software. After all, why would
you want to read the keyboard at a 1 Mhz rate (the Apple II bus limit) ?


But my point is, who cares how fast the processor is idling waiting
for a keystroke--it's *idling*!


As for the rest of the I/O space, I see no way to avoid the slowdown.
All that I can say is max speed is going to be close to 1 MIPS when this
happens. And yet worse for code running in the $c800..$cfff...

But the ROM space *has to be* cloned into (fast) ram at boot time.
Because if it wasn't, the same slowdown would apply for it.


I understand you perfectly.  I'm just *still* wondering what it is
that you think Apple II users are impatient waiting for...

I've asked about half a dozen times in this thread, and no one has
offered anything real that they would like to run faster than, say,
20MHz.

Even if the processor is *infinitely* fast, the system will still have
to run animations at a visible speed (tied to the refresh rate), accept
keystrokes at human speed, and access real disks at standard speed.
See what I mean?

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