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

[bieling@terra.es (Jorge Chamorro Bieling)]

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

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.

Regards,
-- 
Jorge Chamorro Bieling