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

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

Mark McDougall <markm@vl.com.au> wrote:

> 
> If you're really interested in pushing the limits in terms of speed, you
> have 2 options:
> 
> 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.

Yes. 
Absolutely. 
That is the idea.
That's why I said in the OP that 
"There are things that should better not be copied from the original
6502 design".

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)

Sitting *between* the processor and the Apple II has to be a block:
"The MMU is the block that manages to interface properly and in sync
with the (fast) RAM, the (Apple II) ROM, the (Apple II) I/O space, the
slow (Apple II) RAM writes, etc"

As the MMU has to be able to supply data *as fast as possible* to the
CPU, the bus between the CPU and the MMU is a CUSTOM design.

But the bus between the MMU and the Apple II is NOT (custom) because the
Apple II is what it is / as it is.

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.

> 2. Write an emulator for whatever processor you can clock at ridiculous
> speeds (much higher than you can clock an FPGA) and hope that you can
> optimise it enough to outpace option #1. Don't forget you need to 
> emulate all I/O in the system including video, which takes a large chunk
> out of your headroom.

Given a certain FPGA,
Given the desire to execute *6502* code,
If you're looking for a fast *6502* instruction set processor...
Why would you put inside a *reduced* instruction set processor instead ?

...thanks, but no, thanks.

> To suggest you can emulate a 6502 on a RISC processor core within an 
> FPGA faster than a native optimised 6502 implementation is utterly 
> ludicrous.

I believe what you say:

Given *the same* hardware resources (a certain FPGA, for example),
A direct implementation in hardware of a 6502 instruction set processor
has to run necessarily faster than a reduced instruction set processor
implementation emulating it in software.

The only reason I can think of to prefer going this way is that you can
pick a built, fast, tested, reliable, off-the-shelf risc core so you
don't have to design a processor.

And although speed may not be an advange then, there's one BIG
advantage, one that I like a lot: it is that the 6502 living inside it
is just software, and therefore can be easily debugged, modified,
upgraded, etc.

There was a thread talking about this here at csa2 not long ago.

Regards,