bieling@terra.es wrote:
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. -michaelOk. 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.
A very respectable number. You chose an interesting case to examine, since it also admits a software-only approach to "background" data transfer. 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. If the computer is being used interactively--meaning it is usually waiting for user input--then transferring data in the keyboard wait loop is a very effective approach. Of course, the potential latency between keyboard loops is determined only by the processing going on in the system, and could be long--but can usually be arranged to be a fraction of a second. NadaNet's server loop effectively inserts itself into the keyboard loop by sensing any keypress and returning to the caller--which will usually result in the keypress being processed (after which the server loop is again called). Since the default timeout period for a NadaNet request is about 3 seconds, it doesn't take much care to arrange to meet the latency constraint. -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."