[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6502 trashing memory cycles...

bieling@terra.es wrote:

biel...@terra.es wrote:
...


That is (257/43.56)=5.9 % of the time, @1Mhz translates to 59 KB/s.



On Mar 31, 9:17 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:


A very respectable number.




I'm starting to think that it's not too difficult to trap unused
cycles for the conditional branches that are taken. When the branch
opcode is fetched during SYNC cycles, the PC is revealed, and the
offset is the byte read at the forthcoming, next, 2nd cycle. Using
this data the destination for the branch is (easily) calculated, and
if the address seen in the address bus at the 3rd cycle equals the
calculated destination address, would mean that the branch is being
taken. Even page crossings can be known, therefore trapping the 4th
cycle during page crossings would also be possible. Then the numbers
would turn out to be:

The loop takes
(5+4+4+4)=17 cycles, (3 borrowable)
255 times, then
(5+3+5+4+4)=21 cycles, (3 borrowable)
the 256th time.

Every (255*17)+21=4356 cycles, there are (255*3)+3=768 borrowable
cycles.

That is (257/43.56)=17.63 % of the time, @1Mhz translates to 176.3 KB/
s... !


Careful, gilding the lily is an engineering curse.  Only the
statistical analysis on more general cases described below
could be used to justify such a complication (relative to its
benefit).


You chose an interesting case to examine, since it also admits a
software-only approach to "background" data transfer.



I've been lazy and have choosen the easiest spot.. 8-)
A short loop that makes it easy to calculate the figures and also one
that is run very often.


I realize that, but it's still an interesting case, since the
computer spends so much of its time in that loop.

BTW, you could capture real traces to a file in AppleWin and
then write a short program to analyze the traces to see not only
the average bandwidth, but also its variance and distribution.

This would be important for any application that would require
any significant fraction of the average bandwidth, since the
latency and FIFO size would depend on the statistics.


Since the bandwidth, whether obtained by hardware or software means,
is only available "on the average", any use of it would demand a FIFO
to queue the bytes (incoming or outgoing).  If a FIFO (either hardware
or software) is present, then the keyboard poll loop is a natural place
to transfer data using programmed I/O rather than DMA--for example, to
a printer buffer, or whatever.



Yes your're right.
But the way I look at this is : "There is a quite respectable
percentage of bandwidth that is being wasted but needn't be so."
Whatever you can do using "programmed I/O" doesn't help to recover the
lost bandwidth.. ?


But time spent in a polling loop waiting is *all* "lost time"
that can be reclaimed with just a little software work.

And if you don't have a good use for that statistical bandwidth,
then it remains "wasted".

In fact, the huge majority of computer execution is "wasted", so
its hard to get excited about a little more--unless you have a
"killer app" for the bandwidth...

Put another way, unless you have a concrete benefit that is
achieved, everything is still "waste".

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."