7

Looking at a timing diagram for the various kinds of memory access occurring on the Amiga http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.html it seems to be saying that video data is being fetched at the rate of one word per color clock = 280 ns.

However, my understanding is that early eighties RAM chips typically took 375 ns for a full access cycle. The amortized access time can be reduced by using page mode, but the timing diagram doesn't seem to suggest this is happening.

What am I missing?

Improve this question
1
  • Can you give an example of such an early 80s RAM chip? Ideally one used in the A500. – user Mar 16 '18 at 10:29
13

The Amiga A500 used 41256-15 DRAM chips for its onboard memory. According to the datasheet these had a cycle time of 260ns, so could easily match the 280ns timing constraint with 20ns to spare (although the board had two banks of them, and switching between the banks likely used up most of that 20ns).

The 375ns limit really only applied to the 4116 and 4164 type chips that were manufactured in huge bulk and were extremely cheap. Faster chips were available even back to the early 80s, but cost more money so designers of low-end micros tended to avoid using them where possible (cf the 4816A chips in the BBC micro we discussed previously, which were necessary in order to let a 6502 run at 2MHz with capacity left for video access between the CPU's accesses), especially when working with either 1MHz 6502 or 4MHz Z80 designs where faster RAM would have been useless.

Improve this answer
2
  • Memory chips with a -15 designation but a 260ns cycle time confuse me a bit... I would have expected that suffix to denote 150ns parts. But then, that's the typical clock speed they're expected to work with, whereas a full "cycle" for DRAM tends to be two clocks - one supplying address (or at least, row strobe), and the other reading or writing data (maybe supplying column strobe simultaneous to that). Therefore suggesting this chip nominally marked as 150ns is actually, more truthfully a 130ns part, ie itd be suffixed -13 if not trying to fit into a more limited selection of traditional bins? – tahrey Oct 27 '19 at 23:56
  • 1
    @tahrey: DRAM chips use a destructive read cycle which loads a row buffer with the contents of memory cells, but in so doing sufficiently depletes the charge in those cells that they could not be reliably read again. The device attached to a DRAM can start using the data once the read is complete, but before the DRAM can read data from another row, it must write back the data from the current row to prevent it from being lost. – supercat Jun 29 '20 at 2:46
7

To understand how Amiga memory bandwith should be calculated and how data fetching to Amiga Chipram works.

The timingslot schematic that rwallace refering to does not tell anything about how individual chipram ic' operates or are supposed to operate; it just explains how the Amiga timing system is layed out.

The Amiga is a synchronized multiprocessor platform/architecture. It share same memory to some extension. That shared memory is called chipram. The shared memory require some rules to be followed to make it work and to avoid something called bus contention. Bus contention occurs when more than one processor want access to the common address-, data-, or registerbus.

To solve this Amiga has a nested (interleaved) access to the buses (and some other solutions too). It means that the bus access is divided into odd and even timeslots. The whole timeslot concept is based on duration of one video raster-scanline, and that one timslot has a duration of approximatly 280ns. Why 280ns? Because it's the speed of the color clock driving the amiga chipset (Agnus, Paula, and Denise. Agnus contains the DMA controller responsible for memory access to chipram).

1000 000 000 / 3546895hz (colorclock) = 281.9367ns (PAL)

Due to the interleave approach to solve the bus contention problem the individual processors does not fetch data from chip memory with a bandwidth of 7mb/s but instead half of that amount - 3.5mb/s. Now this it not the whole truth. In graphic intensive tasks the amiga chipset can take full control of the buses and run at full bandwidth (7mb/s) at the expense of the cpu not having any access at all (no timeslots to its disposal). The DMA sytem can also be turned off and let the cpu have full access and do all the work (every other timeslot that is). Note: horisontal and vertical blanking period is not included in these situations.

To calculate the memory bandwidth for the cpu (mc68000):

Following calculations applies to OCS/ECS (16-bit) chipset:

  1. Master clock (MC): 28.37516Mhz (PAL), 28.63636Mhz (NTSC)
  2. Color ClocK (CCK): MC/8 = 3.546895Mhz (PAL), 3.579545Mhz (NTSC)
  3. CPU speed is (MC/4): 7.093790Mhz (PAL), 7.159090Mhz (NTSC)
  4. It takes 4 cpu cycles for main cpu (Motorola 68000) to fetch data from external memory (Fast or Chip mem) -->

7.093790Mhz / 4 = 1.773448Mhz (PAL),

7.159090Mhz / 4 = 1.789773Mhz (NTSC)

  1. Bandwidth:

1.773448Mhz * 2byte = 3.546895mb/s (PAL)

1.789773Mhz * 2byte = 3.579545mb/s (NTSC)

It actually takes 560ns - two time slots (one time slot being 280ns) for cpu to fetch data from memory (Fast OR Chip mem).

An example:

(PAL)

  • 1000 000 000 / 7093790Mhz = 140.96837ns
  • 140.96837ns * 4 cpu clockcycles = 563.87347ns

How much is the different clock-speeds in terms of nanoseconds (ns)?

Always divide the (Mhz) by 1000 000 000 (1000 000 000 / Mhz) and you will get ns. When you read the inscription on memory ic's the access speed is written in nanoseconds e.g. 41256-15 means 150ns (access time).

To increase bandwidth to chip memory three 'rules' must be fulfilled:

  1. Cpu clock need to be synchronized with masterclock.
  2. Chip memory need to be fast enough to handle the new clockspeed.
  3. The cpu clock need to be at least four times as fast, i.e. at the same speed as masterclock to double the bandwidth. The synchronization require cpu clock to be a multiple of masterclock.

Why does cpu need to be four times as fast to increase the bandwith? Because of the interleaved approach to chipram between cpu and amiga chipset; this together with the fact that - as mentioned above - it takes 4 cpu clock cycles to fetch data from chipram (and fastram). In other words; cpu access chipram (and chipregisters) every other timeslot and therefore it needs to be quadrupled in clockspeed.

NOTE: This will only increase bandwidth between cpu <-> chip-ram and not the bandwidth between Amiga Chipset <-> chip-ram.

Improve this answer
8
  • 2
    DRAM access time isn't relevant for calculating bandwidth (it specifies latency, not overall throughput), cycle time is. The 41256-15 has 260ns cycle time. Also, just because the CPU takes two bus cycles to access memory doesn't mean that the total bandwidth of the system is limited to that rate, as the system also has a DMA controller that gets access to memory interleaved between the processor's accesses. I believe LVD's answer is correct, at least modulo the slight variation in speed between the PAL and NTSC models. – Jules Mar 31 '18 at 10:24
  • You sound like Jay Miner or Dave Haynie... :) – MikeP Apr 4 '18 at 20:47
  • I guess I'll take it as a compliment LOL ;) – Marko L Apr 4 '18 at 21:47
  • @Jules: It seems a shame the Amiga was never designed to exploit DRAM chips' ability to perform multiple accesses within a page at a cost only slightly above the cost of a single access. If the DMA-based chips were designed to fetch pairs of words, and a pair of 16-bit pre-fetch buffers were added, performance could have been greatly improved even if all accesses were double accesses that took 1.5 chroma clocks to complete [if the CPU fetches the first half of a 32-bit word on one cycle and then requests the other, the second request wouldn't need to go out to RAM]. – supercat Apr 9 '18 at 0:36
  • @supercat - indeed, it seems that many systems produced in the 80s could have had superior IO performance if page mode had been exploited more frequently. There are isolated uses (e.g. the Spectrum's ULA fetching two bytes in the interval between the Z80 memory fetches), but AFAICT the capability wasn't routinely used in microcomputer class machines until the faster 80386 models turned up, and commodity DRAM was simply unable to cope with the demand of memory bandwidth necessary to keep them running at full speed without using page mode... – Jules Apr 9 '18 at 2:56
3

A500 accesses its chip 16bit memory at 3.5MHz rate, therefore the bandwidth is 3.5*2=7Mbytes/second.

In A1200 there is a page mode optionally used to access 2 words instead of one, and the memory itself is 32bit, while the access rate is the same. Therefore the bandwidth is 28Mbytes/second.

Improve this answer
0

This could have been figured out just by looking up what actual hardware is in an Amiga, or even any typical 16-bit computer. 400-ish nanosecond latency is slooooooow for this kind of machine. Even the IBM PC used DRAMs faster than 300ns (it was either 250 or 200, I forget which). The actual memory used in yer typical Amiga (or ST, even) was 150ns. Sometimes 120ns when that became cheaper, because technically the 150ns stuff was being somewhat overdriven (especially in the Atari) - the actual memory cycle in an Amiga is not 280ns, but 140ns, because for every access the 7.1MHz 68000 makes (on a 4-clock cycle), the video also makes one (and similar for the 8MHz ST).

[EDIT - OK, I got that a bit backwards; a full 68K cycle is in fact 560ns, with two actual memory access slots of 280ns each - usually one to CPU, one to DMA (covering video, audio, blitter, disk...) - themselves composed of two 140ns clock ticks. It's the ticks that are crucial, as the memory has to be able to respond to an issued RW request within ~roughly~ 140ns (thus, you can "push" decent 150ns parts)... every 280ns, continually. It's easy to get confused by it, I admit; getting it straight requires an understanding of how memory works, how the timings are designated, and how the computer architecture is set up]

(This is assuming the default 16-colour 320-pixel mode, or 4-colour 640-pixel, which gives the best balance of CPU performance vs image quality; the majority of 68000 instructions are aligned to a 4-clock rhythm, and a memory access is a minimum of 4 clocks, but only 2 of them are actually used for data transfer, allowing the system chipset to buffer the request and only hit RAM then deliver the result when it's truly needed. The actual memory bandwidth is the same in higher colour modes, but the balance shifts, so that the video system gets not just 4 out of every 8 memory accesses during the active drawing period, but 5, 6, or the full 8)

1 billion nanoseconds, divided by 140, gives you approximately 7.1MHz. The latency in this case is the time taken between the memory receiving the R/W access setup (with the address and type of request) on one clock tick, and being able to either deliver the Read data or accept the Write data on the next, and also the time between doing that and being ready to start again on the third tick. There's sufficient wiggle room with chips operating at 150ns, expecting a maybe less than perfect jitter from their host circuitry, that they can be safely run at 140 in most systems, or even 125 (=8MHz) if the voltage is strong enough and the signal swing fairly sharp.

(And in the PC, which operated at a touch less than 5MHz, 200ns would have been more than sufficient; 250ns is still within the realms of possibility, especially as it may well have inserted Wait States as a matter of routine anyway. If we go all the way to 400 or so, we're down into the realm of 2.5MHz operation; that's not even really enough to support a fast Z80, for which you might want 300 or even the full 250ns - memory that slow is limited more to older Z80/i8080 systems, or 6502/6800 based designs. Maybe you're confusing the operation of the shared-video-memory, higher-speed Amiga with the reference design for the 68000, which started off at just 5MHz and didn't expect anything but the CPU to access RAM directly, and therefore was entirely happy specifying much slower memory?)

Improve this answer
2
  • OK, I give up trying to contribute to this site right now, if there's going to be some dickwad camping my posts and downvoting every single one the very moment I add them, and not even doing me the common courtesy of adding a reply about what it is they find so objectionable. – tahrey Oct 28 '19 at 0:02
  • 3
    I didn't (and wouldn't) downvote you, but your post has some problems. First you are replying to a question that is over a year old and already had excellent answers, so if you have something new to add it had better be good. Second your style comes across as a bit too chatty and perhaps even condescending ("This could have been figured out just by..."). Thirdly you are rambling on about other architectures that are not relevant to the question. Retrocomputing is a bit more relaxed than some other Stack exchange sites, but it's not a discussion group. – Bruce Abbott Oct 28 '19 at 0:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.