Memory access time

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

User avatar
npomarede
Atari God
Atari God
Posts: 1326
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Memory access time

Postby npomarede » Tue Jul 29, 2014 12:47 pm

Hello

In this thread, I'd like to build a summary of the various access' times on different models (STF, Mega, TT, Falcon, ...) and for different memory location (RAM, ROM, expansion slot, ...)

For STF/STE with 68000 CPU at 8 MHz, we know that memory access in RAM need to be aligned on a 4 cycles boundary, which means some 68000 instructions will sometimes take more cycles than the official 68000's doc, as we can loose 2 cycles on each memory access.
If I'm correct, when accessing ROM or cartridge memory, there's no penalty (because those regions are not shared with the shifter). In all case, it takes the same time to read/write 1 byte or 1 word, and reading 1 long takes the same times as 2 words.

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 ?

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 ?)

If you have any informations on this, please post them here, they could be valuable for coders, but also for software/hardware emulators.

Nicolas

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1858
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Memory access time

Postby Cyprian » Tue Jul 29, 2014 1:44 pm

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.


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 ?)

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.


But there is one interesting feature - FUNNEL chip. I read somewhere (maybe in Profibuch) that in a specific situation it can works as a 64bit cache for read cycles.

I did some tests with sync code and cycle measurement on my TT/MSTe and if you need I can somehow support you.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Memory access time

Postby dml » Tue Jul 29, 2014 5:55 pm

The Falcon doesn't have a 32bit bus so accessing 32bit read takes 2x longer than 16bit read.

Exactly how long it takes is quite complicated. Mikro put a decent amount of energy into this - there's a writeup on his site. However there are probably more complex variables involved and the whole thing needs measured and calibrated.

For example writing appears to be somewhat buffered, and so is easier to 'hide' than reads. Reading words with the datacache enabled is also complicated because it tries to fill longword entries at a time (burst mode / 16byte fill mode is inactive on Falcon). The data cache itself incurs some small obscure penalty on memory operations even on a cache miss. Datacache hit is simpler, and should be constant but there's probably still some small obscure penalty on top of the sheet timings (?).

The video bus steals memory slots from under the CPU at a rate proportional to the pixel fetching bandwidth of the current video mode, most obvious in truecolour modes on VGA monitors.

There might be other factors such as audio DMA but I don't know if that is measurable.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Memory access time

Postby Dio » Wed Jul 30, 2014 12:11 pm

I have traces from the basic STFM for reads from and writes to the various memory types. Here they are, but the read isn't commented. Looking at the trace I think the order is RAM, ROM, palette, sync, res, MFP with the ROM read at about 29us; you can see the CPU issuing the read (top half of the trace) but it causes no activity beyond a refresh on the gateway and DRAM bus (bottom half; there is a RAS with no CAS).

Note in particular the effect of the bus gateway (latch/rdat/wdata), and that MFP accesses get plenty of extra wait states.
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Memory access time

Postby AtariZoll » Sat Aug 02, 2014 6:12 am

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.


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.

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.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1858
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Memory access time

Postby Cyprian » Sat Aug 02, 2014 7:07 am

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.


I don't have ALT-Ram in my Mega STe therefore I can't answer how looks its access time. But in case of ST-Ram Mega STe has the same access time as in STE. My guess that in case of access to ST-Ram, CPU is switched to 8MHz (as in 16Mhz CPU upgrade made by Exxos).

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.


My source of knowledge was Profibuch and also my own test code. From access time point of view, ST-Ram in TT is organized in the same manner as in ST. Memory has 250ns access slot, Shifter gets every even, CPU every odd memory slot. Therefore CPU memory slots occurs every 500ns. From CPU side the only difference is 32bit access in TT vs 16 bit access in ST. It is also visible in figures from this thread:TT and NemBench

Code: Select all

Linear 32bit read (ST-Ram)   -> 7.867 MByte/sec (~148%)
Linear 32bit write (ST-Ram)  -> 7.867 MByte/sec (~121%)

7 867 000 / 4 byte access = 1 966 750 accesses per second

Regarding video mode, whenever you choose TT-Low or ST-Low, it has no completely impact on CPU (as it was in ST) because of that even/odd split access. Also Shifter it TT has 64bit access to memory.

Video mode has an impact only in Falcon, which has completely different memory organization than ST/TT.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Memory access time

Postby AtariZoll » Sat Aug 02, 2014 8:48 am

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.
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).
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1858
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Memory access time

Postby Cyprian » Sun Aug 03, 2014 10:09 pm

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.

cool, more tests, better knowledge.
I'm on my vacation now, therefore I have no access to neither MegaSTE nor my test applications. I can't tell you what besides blitter and ST-RAM speed exactly was tested by me. But I would suggest you just to turn off Cache before test of ST-RAM. It is really huge therefore has also huge impact onto MegaSTE speed.
Regarding Alt-Ram in Mega STE - there is a dedicated extension - Magnum STE - it adds max 10MB of ALT-Ram. I don't have it but it would be cool to check how fast it is in Mega STE


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).


As I'm on vacation I can't check in my paper version of Profibuch, but I found out PDF version. In that version I found only that:
"Dabei kann der Zugriff auf dieses RAM in minimal 250ns - Abständen zwischen den beiden Konkurrenten wechseln. Während eines laufenden DisplayZyklusses wird der Videocontroller natürlich nicht einfach unterbrochen, sondern die CPU bekommt die nächstmöglichen 250ns "zugewiesen", Auf der Hauptplatine des TTs findet sich bereits standardmäßig"
That strange. Maybe my memory was playing tricks on me or I have different revision of Profibuch. I was sure that was more about ST-Ram timing, and also that there was more about FUNNEL and caching data. Unfortunately I would be able to check that after my vacation 15th of August

TT Shifter has 64bit access to the memory. It means that in TT-Low/TT-Mid mode, TT-Shifter locks the memory for almost the same amount of cycles as ST-Shifter in ST-Low/ST-Mid mode in good old STfm. 16000 memory accesses per frame in ST vs 19200 in TT


AtariZoll wrote:But it sounds disappointing that RAM is so slow, and it slowdowns overall work for sure, as cache size is low.

Hmm, maybe slow but still much faster that in machines released a few years later: Falcon's 16bit bus myth - 32bit vs 16bit war

TT:
Linear 32bit read (ST-Ram) -> 7.867 MByte/sec
Linear 32bit write (ST-Ram) -> 7.867 MByte/sec

A4000:
ReadL: 3.1 MB/s
WriteL: 4.3 MB/s

A1200:
ReadL: 4.5 MB/s
WriteL: 6.9 MB/s
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

Guest

Re: Memory access time

Postby Guest » Mon Aug 04, 2014 10:34 pm

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
perhaps cleaning the clock {32mhz} using one or more dds's and lock them together using the same crystal to run the various dds units
32mhz is 20ns per high low high 16mhz is 62.5ns 8mhz is 125ns
all i see above is a dodge frequency worblated clock pulse causing havoke further down the chip set super imposed crap thats not needed
use an RGB monitor then disconnect the daft dot clock and replace the 32mhz feed to the shifter with a 32mhz ttl crystal or a DDS set to 32mhz

then try again

do the same traces again but just replace the clock to the shifter with a TTL 32mhz type

the dot clock and other doubler's and the shifter dividers gets in the way of accuracy

no point without fixed clocks as the stfm etc has the daft dot clock arrangement just for PAL and other non ntsc and not needed
when you use a rgb monitor at 50 or 60hz

where the TT and my own falcon does not !!! use a dot clock
i run the whole falcon in standard clock mode from the dsp 32mhz clock via the nemesis to clean it up
and only svga...
its not all down to writes the DRAM in a stfm is like 100 or 120ns refresh where the stram in the TT is 80 ns
improving the speed of the ram in the stfm makes less glitch and any added effects the dram as slow as 120ns can create
so add a simm
improve the clocks
then talk turkey

as an access cycle its timed by the apps and gem

so past this it really doesnt matter because the software once running dictates
or the time base of an rtos system does this also using if def
so if an app requires a certain speed it will still run at the same speed
perhaps a faster frame rates or load and save {functions as perif exchange } and interactions are quicker
but not faster to do...
tier tasking is measured in time ticks per callback infraction level


ye and whats the dodge dram write latch signal in the second trace ???
all down to control leakage caused by a waggly clock

some spike ...??? "Note in particular the effect of the bus gateway (latch/rdat/wdata), and that MFP accesses get plenty of extra wait states."
lol:) youll need it is it latched or isnt it
what is latched during the preamble to the dram write

latch has a 10ns transition in space between the correctly latched state???

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Memory access time

Postby mc6809e » Wed Aug 06, 2014 5:26 am

The bandwidth available to the Falcon and other faster Ataris vs the Amiga 1200, etc is interesting in that the Ataris can take advantage of the "weird" interleaved bitplane arrangement of the Atari's video memory.

The sequential nature of the interleaved bitplanes means a machine like the Falcon can more easily use page mode when accessing video memory for display. This leaves much more bandwidth available to the processor.

The Amiga 1200 does have some support for page mode accesses, but it's very limited as each bitplane needs wider and wider buffers to handle multiple fetches. And since each bitplane has its own starting address, that means wide buffers for each plane. That costs silicon. I think on the A1200 fetches are limited to just 4 accesses to consecutive words while the Falcon does something like 16 or 17 consecutive fetches from video memory. In the lower compatible resolutions I think the A1200 just does single fetches.

It would be interesting to see how the Falcon and friends compare to the A1200 for each of the video modes and bitplane depths.

I think the ability to use page mode without worrying about legacy issues was one of the reasons IBM PC compatible machines so easily transitioned into higher resolutions. Even at the time of the release of the ST and Amiga 1000, DRAM access using page mode on slow 150ns memory could give 60+% more bandwidth than strictly random access.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Memory access time

Postby AtariZoll » Wed Aug 06, 2014 7:34 am

Cyprian wrote: ...
TT:
Linear 32bit read (ST-Ram) -> 7.867 MByte/sec
Linear 32bit write (ST-Ram) -> 7.867 MByte/sec
...


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 . Btw. this perfectly answers my observation "it seems not faster at all than on Falcon" - when I ran Microprose F1 GP for the first time on TT . Since it uses pretty advanced 3D code, CPU cache just has too many misses (too short for complex code), so faster CPU is lost in many waits.

Regarding Mega STE - there is no much sense to make tests with cache off. Then it acts 100% as some ST, STE . The proof is that Spectrum 512 and hi-color displaying code works flawless then, and it means that timings are 100% same.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Memory access time

Postby Dio » Wed Aug 06, 2014 9:42 am

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

It's a £30 trace analyser, sampling digitally (not necessarily at the same logic levels used on the ST's own chips) at quantised intervals way less than GSample.

It's sufficient to get the general idea of what's going on, but it's not accurate enough for skew and other very exact timing analysis, even at 100Msamples that's still nearly a 10% error on an 8MHz clock, and it doesn't have any glitch analysis capabilities.

As for the spike, they show up occasionally on various traces. Notably on this particular trace I had left two of the probes dangling rather than grounding them - I've noticed since that that sometimes induces noise into the other signals.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1858
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Memory access time

Postby Cyprian » Thu Aug 07, 2014 8:07 am

mc6809e wrote:The bandwidth available to the Falcon and other faster Ataris vs the Amiga 1200,

We posted here on AF some threads with figures for Falcon, and TT. And also you can find there some figures for different Amiga models

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:It would be interesting to see how the Falcon and friends compare to the A1200 for each of the video modes and bitplane depths.

In case of TT, video mode has no impact on the CPU memory bandwidth. I've checked ST-LOW 320x200 in 16 colors and 320x480 in 256 colors and in both modes Nembench shows the same figures: 7.867 MByte/sec
There you can find figures for Falcon in 2colors and TC mode. Would be cool to see similar benchmark for A1200

There you can find an interesting F30-A1200 benchmarks done in 16colors and also in 256colors mode
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2319
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Memory access time

Postby calimero » Thu Aug 07, 2014 10:35 am

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 .

in first spec. TT should have 16MHz 68020.
only later they change design to 32MHz 68030...

regarding TT speed of ST RAM (from http://www.sarnau.info/atari:atari_tt03 ... nce_manual):

"The basic system includes 2 Mbytes of dual-purpose RAM which is used for both video and system memory. This is implemented by using 16 256Kbitx4 100nS DRAMs, yielding a 64-bit wide internal bus for high performance video access.

The bus architecture is similar to the ST in that memory access cycles are interleaved between the MPU and the video controller in 250 nS RAM time slices, thus allowing video display memory to reside efficiently as part of main memory. During active display cycles the processor is prevented from accessing the memory but is allocated the next 250 nS time slice. The processor interfaces to this RAM through a 32-bit bus, but the video subsystem itself accesses memory on a 64-bit wide bus. The video chip (TT shifted has on-chip buffering to provide very high bandwidths for data."


it looks like exactly as ST, right? Only difference is 64bit Shifter access to RAM?

in ST, Shifter have 16bit access to RAM?
it is clocked at 32MHz, right?
if it is clocked at 32MHz - why is it?

Shifter have 2.000.000 cycles per sec. for accessing RAM; if each access is 16bit (2 bytes) wide it is 4.000.000bytes/s (4MB/s)
ST needs only 32KB for screen data and in monochrome mode, shifter need to read 72hz X 32KB = 2.304KB/s in worst case scenario.
but why it need to be clocked at 32MHz if it needs to deal with max. 2.304KB per second of data?


and one offtopic question: why ST require at least 150ns RAM when RAM is accessed every 250ns (either by CPU or Shifter)?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Memory access time

Postby AtariZoll » Thu Aug 07, 2014 11:29 am

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 .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4417
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: Memory access time

Postby DarkLord » Thu Aug 07, 2014 11:36 am

calimero wrote:in first spec. TT should have 16MHz 68020.
only later they change design to 32MHz 68030...


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. :)
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2319
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Memory access time

Postby calimero » Thu Aug 07, 2014 12:08 pm

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 .

@AtariZoll thanks for explanation!

so MMU feed Shifter, and Shifter have 4 bytes buffer?

and what about MegaSTe - it can read/write ~7MB/s to ST Ram? If this is true, than it must have double speed memory (around 60-70ns?)?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2319
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Memory access time

Postby calimero » Thu Aug 07, 2014 12:12 pm

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. :)

;) here you have story about EST - TT prototype:

https://translate.google.com/translate? ... edit-text=
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
troed
Atari God
Atari God
Posts: 1450
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Memory access time

Postby troed » Thu Aug 07, 2014 12:45 pm

calimero wrote:so MMU feed Shifter, and Shifter have 4 bytes buffer?


A good overview of Shifter vs MMU tasks can be extracted from Alien's overscan articles:

http://alive.atari.org/alive9/ovrscn1.php
http://alive.atari.org/alive11/oscan2b.php

(But yes)

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Memory access time

Postby mc6809e » Thu Aug 07, 2014 1:08 pm

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.


That's why I put the word "weird" in quotes. It's been called weird, but I agree with you. It is better.

Being able to quickly sequentially access rows of data in DRAM has been responsible for some of the huge gains in speed over the past 20 years. The 68030 was nice in that it had a bus that supported a burst mode.

I don't think many people know that DRAM from a random access perspective isn't that much faster than DRAM of 20 years ago.

There are about 50ns between random accesses with DDR3-1066 -- a mere 20 million random accesses per second!

I once got into an argument with a guy on a commodity hardware router project that just couldn't believe that his packet routing scheme was limited by random accesses to DRAM. His idea was to basically use a hashing scheme that wound up splattered packets randomly all over memory.

User avatar
npomarede
Atari God
Atari God
Posts: 1326
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Memory access time

Postby npomarede » Thu Aug 07, 2014 1:16 pm

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" :D
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
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Memory access time

Postby mc6809e » Thu Aug 07, 2014 2:23 pm

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" :D
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.


Well obviously there are tradeoffs.

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.

User avatar
npomarede
Atari God
Atari God
Posts: 1326
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Memory access time

Postby npomarede » Thu Aug 07, 2014 2:28 pm

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.


As long as you still need to skip interleaved words with "addq #nn,ax" and you can't use movem to copy a large sprite or similar of more than 16 pixels, then I wouldn't call the possibility to use "move.l" a win, maybe just a smaller loss :)

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2319
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Memory access time

Postby calimero » Thu Aug 07, 2014 3:08 pm

troed wrote:
calimero wrote:so MMU feed Shifter, and Shifter have 4 bytes buffer?


A good overview of Shifter vs MMU tasks can be extracted from Alien's overscan articles:

http://alive.atari.org/alive9/ovrscn1.php
http://alive.atari.org/alive11/oscan2b.php

(But yes)

thanx for links!
"The SHIFTER contains 4 16-bit registers RR1 to RR4" - so it is not 4 bytes but 4 word buffers (registers).
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4417
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: Memory access time

Postby DarkLord » Thu Aug 07, 2014 3:39 pm

calimero wrote:;) here you have story about EST - TT prototype:

https://translate.google.com/translate? ... edit-text=


Nice! Thanks for the link. Interesting stuff. :)
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: _KrISS_ and 7 guests