npomarede wrote:What about the Mega ST when it runs at 16 Mhz ? Does it also have a 2 cycles penalty when accessing RAM, or is it more due to the cpu being twice as fast ?
npomarede wrote:And what about TT/Falcon for standard RAM and expansion RAM ? Does accessing 1 long take the same time as accessing 1 word (is there a full 32 bit bus ?)
Cyprian wrote:npomarede wrote:What about the Mega ST when it runs at 16 Mhz ? Does it also have a 2 cycles penalty when accessing RAM, or is it more due to the cpu being twice as fast ?
MegaSTe and STe shares the same Glue logic, therefore from CPU point of view in both machines access to ST-RAM takes 500ns.
from CPU side, ST-Ram in TT has the same access time as in ST - 500ns. And of course CPU has access to full 32bit bus.
I did some tests with sync code and cycle measurement on my TT/MSTe and if you need I can somehow support you.
AtariZoll wrote:I think that npomarede was interested for RAM access times in Mega STE at 16 MHz . What is for sure simply half of normal access times - when there is cache hit.
AtariZoll wrote:Now, that about TT - where did you get it ? TT ST RAM access time is 500nS ? RAM in TT is faster than in STs , as I know. And thing is more complex + RAM is 32 bit . There are slowdowns in higher video modes - this is why it is called ST RAM and not Fast RAM . All this needs some serious measuring in diverse video modes.
Code: Select all
Linear 32bit read (ST-Ram) -> 7.867 MByte/sec (~148%)
Linear 32bit write (ST-Ram) -> 7.867 MByte/sec (~121%)
AtariZoll wrote:There is no Alt RAM in Mega STE . It has 16 KB cache with it's logic. And cache is RAM too . There would be no much speed gain if CPU switched back to 8 MHz by RAM access. Then it would work as simple 16 MHz solutions, which have not much bigger speed (20-30% max). But I may do some tests with Mega STE, since I have it.
AtariZoll wrote:I have no TT, so can not do tests with. In Profibuch I did not see anything about RAM timings in TT . But it sounds disappointing that RAM is so slow, and it slowdowns overall work for sure, as cache size is low.
To avoid ST RAM access slowdowns in higher video modes, where shifter loads RAM much more intensive, there should be faster RAM chips. I see that your 2 claims contradict each to other. I talked about TT video modes. Of course that no slowdown in ST modes (as no by Falcon).
AtariZoll wrote:But it sounds disappointing that RAM is so slow, and it slowdowns overall work for sure, as cache size is low.
Cyprian wrote: ...
Linear 32bit read (ST-Ram) -> 7.867 MByte/sec
Linear 32bit write (ST-Ram) -> 7.867 MByte/sec
simbo2 wrote:looking at the traces above
and i see lots of time skew the high to low delays and low to high are skewed past far past the quoted transitions of 1ns ~(lth-htl) delay
the transitions are not clean and precise
ye and whats the dodge dram write latch signal in the second trace ???
all down to control leakage caused by a waggly clock
mc6809e wrote:The bandwidth available to the Falcon and other faster Ataris vs the Amiga 1200,
mc6809e wrote:etc is interesting in that the Ataris can take advantage of the "weird" interleaved bitplane arrangement of the Atari's video memory.
mc6809e wrote:It would be interesting to see how the Falcon and friends compare to the A1200 for each of the video modes and bitplane depths.
AtariZoll wrote:That's the problem. ST at 8 MHz has 4 MB/sec read or write speed with ST RAM . It is result of using half of it's 250 nS cycle 16-bit RAM bandwith , what is 8 MB/sec. So, TT's double speed is just result of 32-bit bus. CPU is clocked 4 times faster, so there is plenty of wait states when accessing ST RAM .
calimero wrote:in first spec. TT should have 16MHz 68020.
only later they change design to 32MHz 68030...
AtariZoll wrote:It's not shifter who accessing ST RAM, but MMU chip. 32MHz clock for shifter is necessary for generating hi-res dots (hi-res for that time) .
Faster RAM is required because there are delays in chips involved. 250nS is cycle time, but when CPU (or MMU) gives command to access RAM, it goes through Glue, MMU and other chips, so there is delay of some 50-70nS in ST . Add it to 150 nS, and see that's very close to 250nS .
DarkLord wrote:I can remember an article where the author was at some convention, and
had to bite his tongue when talking to some Amiga people because they
were talking about the TT's 16mhz speed, and he knew it was going to
be 32mhz, but couldn't say anything because of an NDA (but I'm pretty
sure this was a 68030? Did they go through a stage from 16mzh '020 to
'030 then 32mhz 030?). Anyway, I really felt for the guy.
Cyprian wrote:mc6809e wrote:etc is interesting in that the Ataris can take advantage of the "weird" interleaved bitplane arrangement of the Atari's video memory.
why "weird"? From my point of view this is much better/faster video organization than Amiga's one.
mc6809e wrote:That's why I put the word "weird" in quotes. It's been called weird, but I agree with you. It is better.
npomarede wrote:mc6809e wrote:That's why I put the word "weird" in quotes. It's been called weird, but I agree with you. It is better.
Try to explain that to all demos / games coders that once wanted to alter only one bitplane as fast as possible and had to use things like "move (a0)+,(a1)+ and addq #6,a1" instead of using "movem"
Hardware point of view is sometimes leading to a different software point of view, maybe the interleaving was better for the HW as it reduced need for more buffer, but from the SW side, I think it made code slower.
mc6809e wrote:What about the case where two planes are modified? Sequential access lets you do long writes to modify two planes. That's a win.
A one color sprite just doesn't seem worth the effort, but a three color sprite is much more useful.
Besides, so little data is moved in the one color case that the slowdown seems acceptable compared to the boost in the three color case where more data must be moved.
calimero wrote: here you have story about EST - TT prototype:
https://translate.google.com/translate? ... edit-text=
Users browsing this forum: No registered users and 8 guests