Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!njin!princeton!phoenix!kadickey From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Newsgroups: comp.sys.apple Subject: Re: Really small question (warning: long tutorial) Message-ID: <12777@phoenix.Princeton.EDU> Date: 8 Jan 90 04:43:10 GMT References: <9542@microsoft.UUCP> <742@batman.moravian.EDU> <10071@microsoft.UUCP> <14552@orstcs.CS.ORST.EDU> <10100@microsoft.UUCP> Reply-To: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Organization: Princeton University, NJ Lines: 77 In article <10100@microsoft.UUCP> brianw@microsoft.UUCP (Brian WILLOUGHBY) writes: >throoph@jacobs.CS.ORST.EDU.UUCP (Henry Throop) writes: >> >>brianw@microsoft.UUCP (Brian WILLOUGHBY) writes: >>><>I thought the cycle times on MVN/MVP were 7 cycles per byte moved. How >><>is that as fast as DMA which is supposed to be (at least what I've always >><>been told) 1 cycle per byte moved? >>< >>> >>No, it's 7 cycles per byte moved. I timed an MVN moving one bank (64K) at >>452100 +/- 50 ms, which come out to (at 1.023 Mhz on my gs) 7.06 cycles >>per instruction. Considering that there was probably a bit of overhead >>at the start or end, and maybe a few interrupts, it looks like 7 to me. > >On the Apple, the *average* clock speed is 1.020484 MHz when you consider >that at the end of each video line the final clock cycle is shortened by one >period of the 14.3818 MHz clock. In order to keep the video data in sync with >the phase of the colorburst signal, the Apple can't use a constant frequency >clock. Pick up the SAMs manual called "The Apple II Circuit Description" for >more details. > >>>Brian Willoughby >> >>Henry Throop First, Woz himself wrote an article in Byte on how to calculate e to 36,000 decimal places on an Apple II--and he gave the effective clock speed of the Apple II as .99 MHz or so (I don't have the issue handy, but I remember it clearly being under 1.0). 1.00 is fairly accurate to use for most purposes. But, as to fast memory moves, PEI is the answer. If you want to move from bank $05 to bank $07, MVN and MVP are the handiest way to go (not the best, but the speed improvement is not that much). But, as my LONG article in my SHR.DEMO.SHK archive, I explain why PEI is so fast for screen moves, and fast for general memory moves too. PEI is a new 65816 instruction--PEI $00 pushes the two bytes at $00 and $01 onto the stack. Therefore, by moving the direct page around we can change the source address, and moving the stack pointer changes the destination address--but we are always stuck in bank $00. No problem--//e technology to the rescue. For the //e to access it's auxiliary memory area, there are softswitches to set which basically swap out the low 48K area of memory for the auxiliary memory. But, we can set the switches so that we READ from bank $00 and WRITE to bank $01. Then, set shadowing on, and our write to bank $01 will show up on the SHR screen. And here's the key point--PEI moves 2 byte in 6 cycles--that's 3 cycles per byte. Twice as fast as MVN and MVP. And, more subtly (and described in more detail in the archive file), PEI times better with the slow memory write. The processor has to wait up to 2.5 cycles for it to synchronize up with the slow video memory. It then takes 2.5 cycles (fast cycles) to write to this slow memory. PEI just so happens to execute its writes and reads in such a way that the synchronization time is nearly zero. That is, the 6 cycles it would normal take to operate are 2 cycles for the actual memory write, and 4 cycles for other stuff. Those 2 write cycles would be expanded to 5 cycles to write to slow memory. But my timings show that a PEI memory move to slow memory can occur as fast as 10 cycles/2 bytes. That means an average of just .5 cycle is wasted to synch up with slow memory. MVN and MVP on the other hand, each take an average of 1 fast cycle to synch up--so MVN to slow memory would occur at 6+2.5+1 = 9.5 cycles/byte. Still almost twice as slow as PEI. For more information on this, either pick up my file somewhere, or send me mail. Kent Dickey kadickey@phoenix.Princeton.EDU