Re: 65C02 emulation

[bieling@terra.es]

Michael J. Mahon ha escrito:

> bieling@terra.es wrote:
> > Charlie Springer ha escrito:
> >
> >
> >>On Wed, 27 Dec 2006 21:26:55 -0800, bieling@terra.es wrote
> >>(in article <1167283615.114007.102690@79g2000cws.googlegroups.com>):
> >>
> >>
> >>>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...?
> >>
> >>The ARMs have several memory access modes to handle full speed RAM and slower
> >>ROM and FLASH plus a mode that can hold till finished. So with the right MMU
> >>stuff one should be able to read/write at Apple bus speed when needed.
> >
> >
> > I didn't know. But please think about this very usual situation: a
> > program is running and doing useful things but at the same time is
> > polling the keyboard not *waiting* for a keypress but *checking* just
> > in case the user wants to halt it or whatever (control-c?). Your fast
> > processor is executing several tens of times faster that a regular 6502
> > would do, but everytime a keyboard poll apears in the program flow,
> > your superfast processor halts for at least 1000ns maybe up to 1999ns
> > because of it ? This has to be addessed somehow, don't you think so ?
>
> Interesting.  Can you think of an application in which a long
> computation is being done, and polling the keyboard constitutes
> even 1% of the loop time?  This would mean that the loop time is
> less than 100 cycles, despite doing something interesting.
>
> If you can, then that application would be speeded up only 50 times
> on a processor that can run the code 100 times as fast as an Apple II
> (since half its time would be spent reading the keyboard latch).
>
> If the program loop takes 1000 Apple cycles (polling the keyboard
> about 1000 times per second!), then running the 999 cycles 100 times
> faster and slowing to 1MHz for one cycle would result in a speedup
> of "only" about 90 times.
>
> I think that this "problem" is imaginary.

Hi Michael,

I know, and you too, that what a "useful program" does doesn't have to
fit in a single iteration of a single loop. Sure there are going to be
several loops one inside the other. You know how often you want to poll
the keyboard and you choose where to poll based on how long you expect
the loops to take.

Many of the software that you'll run with this is already written.
Therefore you've got no control over how often does it poll the
keyboard, and it will do it "often enough" so as to be responsive at
the "slow" and expected, actual, non-accelerated Apple II speed. When
this same software is run several tens of times faster, yes, it will
happen that the keyboard will be read too often, several tens of times
more often.

Let's say that for some reason in the end we get for example a 6502
running at "only" 100 MIPS = 1 instruction every 10 nS.

On average, every poll will take 1500nS. The software will poll 100
times too often, and every poll costs 1500/10==150 instructions.

> There are many other reasons for wanting to speed up accesses
> with visible side effects, like stores to the frame buffer,

...and every single access is going to cost another 150 instructions,
and..
"This has to be addressed somehow, don't you think so ?"

> but I don't think polling the keyboard is one of them.

But it's going to trash instructions by tens of thousands per second.

Regards,
Jorge Chamorro.