5

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.

  • 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 at 12:21
10

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.

I don't remember; I'd need to have a look at the schematics to give a definite answer here. I wouldn't be much surprised if they took the A2620 68020-based design, clipped out the MMU (68851), reduced the chip count, but left the basic workings the same - meaning no support of the 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.

  • 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 at 17:26
  • 1
    @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 at 17:35
  • 1
    @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 at 20:39

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.