Re: 65C02 emulation

[bieling@terra.es]

Charlie Springer ha escrito:

> There are ARMs with built in MMU that are affordable chips. The difficulty
> could arise in the block sizes the MMU can handle. Lately I have seen
> minimums of 4K and 2K bytes of address space. It may take an FPGA to do a
> proper job for the whole //e memory map.

Really I was thinking about the MMU more like a "bus interface".
Specifically, the task of determining what has to be read from/written
to the Apple II is a task that should be done by a true MMU, but in my
thoughts was done by the "processor" ARM, not by the "MMU" ARM. The
"MMU" ARM in my thoughts just took care of retrieving/writing from/to
the Apple II whatever it was told to. When idle, it should be kept
reading the keyboard in a loop. When commanded to write, it behaves
like a "spooler", I mean, writes can be buffered (and optimized). For
example, if the processor ARM attempts to read the keyboard 10 times
during an Apple II cycle, it will (inmediatly) get 10 times the same
value but there will only happen a single read (or even none) from the
Apple II keyboard in the Apple II MLB. If the processor ARM tries to
write 10 different values to a certain screen buffer (HGR/TEXT) address
during an Apple II cycle, only the last value will be written to the
Apple II, in a single Apple II bus transaction. Other optimizations are
possible, but all of them have to be carefully analized beforehand. Not
many, if any, optimizations can be done for i/o space of course. Also,
when commanded to do so, it has to have the ability to replicate the
exact sequence of bus transactions that a certain 6502 opcode should
have done. I believe that this is necessary in order for the disk II
interface to function properly. The exact details of the
behaviour/functionality of this "MMU" ARM have to be carefully
handcrafted, but being an ARM it becomes a (much more manageable)
matter of software, as long as this "MMU" ARM's processing power
permits.

OTOH, if things are done this way, the burden of discriminating what
has to be read/written from/to the Apple II MLB, may happen to slow
down quite a lot the emulation speed of the "processor" ARM, but about
this I have not thought very much yet...?

> Two ARMs may be even cheaper and why not write parallel to each other? A
> single 32 bit word could have the data and address for the Apple.

You're right, if there are enough i/o pins, of course.
But in the case of the LPC2103 there aren't enough i/o pins.
I have to say, too, that I usually prefer a high-speed serial link over
a (wide) parallel bus. So much that I once wanted to design an Apple II
network using the (hgr) video output as a (fast, serial) "phy", go
imagine. For example, pci-express is something that I find cool and
bright.

Regards,
Jorge Chamorro