Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!antares!dcfs018 From: dcfs018@antares.Concordia.ca ( STEPHAN BOHM ) Newsgroups: comp.sys.atari.8bit Subject: Why does my program take so long? Summary: Cycle counting is off Message-ID: <1894@clyde.concordia.ca> Date: 6 Mar 90 19:07:32 GMT Sender: usenet@clyde.concordia.ca Reply-To: dcfs018@antares.Concordia.CA Distribution: na Organization: Concordia University, Montreal Quebec Lines: 32 Hello all. I've written a little machine language program that reads the trigger port and stores the results in RAM until there's no more memory. I optimized the thing so that it ran as fast as possible. That meant counting cycles to find the fastest instructions to do the job, and I ended up with a routine that takes 14863 cycles to read a page full of bits (2048 bits). Since 1 cycle takes 0.5587 microseconds, that means I can theoretically read at 246500 bits/sec. The thing is, when I run the program, it takes a little over 10% longer to execute than my calculations show. Why? I am shutting off screen DMA and VBI's. I wrote another little delay loop, counted the cycles, calculated the theoretical run time, ran the program, and ended up with an actual run time that was again 10% longer than anticipated. Therefore the question is, why is my 130XE slow by 10%? Is it due to the RAM refresh? I looked in the hardware manual and in De Re Atari but the only stuff I found on DMA timing referred to screen DMA, but since I shut that off (POKE 559,0) that shouldn't come into play. Does Antic refresh RAM even when POKE 559,0 was issued? If so, when does it do the refresh? Does 10% sound right for memory refresh, or is that way too much lost time for such a simple operation (to me it sounds like a lot of lost time, because all along I thought screen DMA was a big time-waster at 30%, but 10% is substantial). Your thoughts/comments are welcome. Jean Goulet Electrical Engineering Class of '89 Concordia University Montreal, Canada