dcfs018@antares.Concordia.ca ( STEPHAN BOHM ) (03/07/90)
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, Canadaslackey@bbn.com (Stan Lackey) (03/07/90)
In article <1894@clyde.concordia.ca> dcfs018@antares.Concordia.CA writes: >Therefore the question is, why is my 130XE slow by 10%? Is it due to the >RAM refresh? >Does 10% sound right for memory refresh, or is that way too much >lost time for such a simple operation A memory refresh every 16 microseconds is common in DRAM systems. A refresh typically takes a 200 ns of so period; typically, that calcs out to between 1 and 2% of total time. Now, the 6501 has a 1MHz cycle, doesn't it? If the Atari memory is designed to do one cycle per microsecond (which it might be), it might take a full microsecond to do that refresh. We're up to 1 cycle in 16, or 6.25% of the time (assuming the 6502 uses the memory bus nearly every cycle, which is probably a good assumption). If the Atari designers were conservative, they could have set the refresh rate faster than the specified minimum, although 1 cycle in 10 seems overly conservative. Another thought is that refresh could be done in software. This seems unlikely; I think we'd know it by now. Bottom line: Yes, it is possible that your 10% is due to memory refresh.
wilson@mfci.UUCP (Jeff Wilson) (03/07/90)
In article <1894@clyde.concordia.ca> dcfs018@antares.Concordia.CA writes: >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. [...] >Therefore the question is, why is my 130XE slow by 10%? Did you account for the lossage in 6502 performance as references cross page (256 byte) boundaries? But that still doesn't explain 10%. Jeff