12

Inspired by this question, I'm curious what burst mode was on the 68030 and why wasn't it supported on the A2630 accelerator card commonly found in the Amiga 2500/30? I had one of these machines and always enabled burst mode and was under the impression it did something.

For what its worth, my A2500 rig had 4vMiB of RAM on the A2630 card and another 3vMiB between the motherboard and expansion on the A2091; I would presume that the mode didn't affect that slower RAM, but I would have thought it made a difference on the accelerator card itself.

Improve this question
1
  • Quite a lot to be asked in one question. It's rather two (at least), isn't it? Let me pull the 030 data book for details (Question a: AFAIR it was requested, needed to be acknowledged and than saved a cycle per word. Question B: the 2500 didn't support either).
    – Raffzahn
    Apr 3, 2019 at 12:21

1 Answer 1

Reset to default
17

I'm curious what burst mode was on the 68030 and

It's an extension to the 68020 bus protocol offered by the 68030. By default, all read access on a 68k takes two cycles. Cache Burst uses the same two-cycle synchronous access for the first word but reduces any of the three subsequent accesses to a single cycle, thus reducing the time for a cache line of 4 words to be loaded from 8 clocks down to 5 (*1).

Works in detail:

  • First of all, the bus must operate in synchronous mode, that is DSACK0/1 is always set high from the memory control and access is always 32 Bit.

  • Next, when the CPU is filling the cache and a burst would be possible, it signals that by asserting CBREQ (Cache Burst REQuest) at the beginning of the first cycle.

  • The memory control has to signal its ability (and acceptance) by pulling CBACK (Cache Burst ACKnowledge) before the falling edge of the second cycle of the first word accessed.

  • If the CPU sees CBACK in time, all subsequent access to fill the cache line will be done in single cycles.

  • To tell so, AS and DS stay asserted until the last word read.

  • The end of an burst cycle is signalled at the end of memory access by removing AS (and of course CBREQas well).

why wasn't it [burst access] supported on the A2630 accelerator card commonly found in the Amiga 2500/30?

Quite simply because the Amiga 2500 was (more or less) a rebadged A2000 (68000-based) with a coprocessor card. Thus its memory interface was 16-bit, not 32-bit as required for burst mode.

For what it's worth, my A2500 rig had 4MB of RAM on the A2630 card [...] I would have thought it made a difference on the accelerator card itself.

Looking at the schematics shows that they took the A2620 (68020-based) design, clipped out the MMU (68851), reduced the chip count, but left basic workings the same - meaning no support added for bus protocol extension for burst. It was up to the never-released A2631 with its new bus controller to make an upgraded A2000 really work like an A3000.

*1 - so even if all access were linear (and cached), savings could only reach 3/8th or 38.5%. In reality, with all data access mixed in and jumps out of cache before a line is exhausted and so on, a real speed up of 1-3% can be achieved - keep in mind, this is in addition to the speed up due to the cache itself.

Improve this answer
6
  • Thanks, Raffzahn. I can understand why the mainboard wouldn't support it (as you say, a rebadged A2000), but the A2630 had 32-bit RAM which I would have hoped supported the '030 features and that the connection to mainboard would have "translated out" (if you will) such advanced modes. I guess in the end the burst mode only really accounts for maybe a 1% performance boost as measured by AIBB.
    – bjb
    Apr 3, 2019 at 17:26
  • 2
    @bjb By now I looked at the schematics, and the adress/bus logic of the 2630 is exactly the same as for the 2620. They did not add any logic to handle burst mode. The performance gain athe burst mode delivers depends quite a lot on software structure and where the program is located. Usually it's way more than just one percent.
    – Raffzahn
    Apr 3, 2019 at 17:35
  • 2
    @bjb ok, I just reread into the performance issue. This depends quite a lot on the kind of code executed. With tight packed code performance gain is rather small. This code gains anyway most from fitting into the (small) cache. The situation is quite different when lengthy (HLL) code is executed. Here it works as a very effective speed up of all code read, depending how linear it is, even 10+% are possible.
    – Raffzahn
    Apr 3, 2019 at 20:39
  • Was it really for "cache"? I thought it was because the ordinary DRAMs of the era had a burst mode because they were organized - internally on a chip that was externally 1 single bit wide - 4 bits wide - once you loaded any of 4 addresses it would load a "row" or whatever it was called of 4 consecutive bits on a mod4-address boundary into its internal buffer and then you could quickly clock them out without providing any more address inputs. Or something close to that. Right?
    – davidbak
    Aug 19, 2022 at 1:30
  • 1
    @davidbak Jup, but that's a different thing. Above description is about how the 030 does cache bursts. FPM or EDO may be used to fulfil this, but it's not a straight 1:1 match, as neither is clocked, nor is the saving exacly halving the access time.
    – Raffzahn
    Aug 21, 2022 at 3:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .