[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6502 trashing memory cycles...
> On 7 mar, 09:53, "Alex Freed" <a...@mirrow.com> wrote:
>
> I think one thing is missing here. On some instructions some cycles
> may be needed sometimes and not needed at other times. It should
> still work but not tag ALL of the "borrowable" cycles.
>
> -Alex.
> biel...@terra.es wrote:
> An analysis of a trace of several seconds would probably reveal the
> truth.
On Mar 8, 3:49 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> You might want to do some frequency analysis on traces to
> see just what percentage of memory cycles you are reclaiming.
>
> -michael
Ok. That's how the throughput figure comes out while the Apple II is
(doing nothing) waiting for a keypress, for example at the basic
prompt or during an input :
The code is:
FD1B INC $4E (5 CYCLES, 1 BORROWABLE)
FD1D BNE $FD21 (3 CYCLES NOT TAKEN, 4 CYCLES TAKEN, 0 BORROWABLE)
FD1F INC $4F (5 CYCLES, 1 BORROWABLE)
FD21 BIT $C000 (4 CYCLES, 0 BORROWABLE)
FD24 BPL $FD1B (TAKEN, 4 CYCLES, 0 BORROWABLE)
The loop takes
(5+4+4+4)=17 cycles, (1 borrowable)
255 times, then
(5+3+5+4+4)=21 cycles, (2 borrowable)
the 256th time.
Every (255*17)+21=4356 cycles, there are (255*1)+2=257 borrowable
cycles.
That is (257/43.56)=5.9 % of the time, @1Mhz translates to 59 KB/s.
Jorge.