[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:
Exactly. What is the objective?
?
See below.
In fact, if you drop in a RISC core, you could implement the entire
Apple II as a straightforward emulation on it, at very high speed.
A month or so ago I got the feeling that you were against using an ARM
for this purpose. But I may be mistaken.
Anyway, let's say that you can emulate the 6502 at a speed of 1 6502
instruction every X risc instructions (average).
the job is (more or less):
1-fetch a 6502 opcode
2-use it to read from the jump table
3-jump accordingly
4-do whatever to emulate this opcode. This may include fetching some
operand(s), writing back to memory, etc.
5-Update P flags
6-jump to 1.
There is one memory cycle per 6502 opcode, one per byte for every 6502
operand, one additional cycle for every 6502 write, two more for
indirections, etc.
Add to these the memory cycles to fetch the risc intructions themselves.
Actually, all these memory cycles will not count extra, unless they are
to I/O space, since the assumption is that 6502 memory is resident in
fast SRAM and the RISC instructions can be scheduled so that most memory
accesses are overlapped with execution.
What speed do you get in AppleWin ?
Virtual II tops at 40MHz.
What do you think X could be ?
6502 speed = RISC core speed / X. (average)
Dou you think that this can ever run as fast as a hardware "emulation" ?
There are much faster cores than the ARM. And you overlooked my
note that minor specializations of the RISC core could produce
significant speed improvements--in free flag handling, for example.
And the issue is what speed is *needed*.
If it's just for fun, go for it.
If you are aiming to achieve some useful objective, then it
pays to be a little quantitative about what that objective is.
For example, how fast an Apple II is useful, and for what?
For the use that most people would make of an "Apple II", if it
ran much faster than 1MHz, they'd just have to slow it down so
they could play the game. ;-)
What is true is that this way you get an additional "layer" on top of
the Apple II. Much more flexibility. This is what I liked (remember that
thread ?) about this approach... but it won't run any faster, I think.
I do remember, and again, the critical issue is "What is the objective?"
If you want to make a "real" Apple II that I can plug existing Apple II
peripheral cards into, then emulation is probably the hard way to go
about it (but not impossible).
If you want to make a very fast Apple II, then emulation can probably
deliver a "real" speed about as fast as a fast hardware implementation
of a 6502, unless the fast hardware implementation is quite decoupled
from memory, and runs more like an emulation anyway.
Since any hardware implementation offering Apple II bus compatibility
is going to have to slow down in the I/O space at least, the average
speed is going to be hard to get much above 20MHz, unless all it's
doing is computing.
Remember, going faster just makes less compute time between I/O's.
Amdahl's law applies. Getting 100mpg on the straightaways and
5mpg on the hills is often a losing strategy, unless you live
in Kansas.
What actual "benchmark applications" do you want to accelerate?
By how much? At what price? With what level of compatibility,
both software compatibility and hardware compatibility? Can you
thing of other, easier ways to achieve that objective?
(I try to stay out of these vaporware discussions, but sometimes it
gets so inflated that I feel some air needs to be let out. ;-)
Again, if it's all for fun or education--great, but this really isn't
comp.sys.apple2.fantasy.
-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."