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

Re: 6502 trashing memory cycles...



> 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... !

> 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.

> 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.. ?

--
Jorge.