viewtopic.php?p=93761#p93761
Badwolf wrote: ↑Mon Nov 14, 2022 2:48 pm
The Falcon's RAM is 32 bit, accessed by VIDEL as such and is I believe interleaved cleverly to increase access speed (@mikro may be able to enlighten us her).
Sorry, I haven't followed the thread but this is what I know about Videl and ST RAM:
In practice, the interleaving is most visible on the ST RAM card setup: it is organized in two 16-bit memory banks of 2 MB each. Many interpret this as the effect of the 16-bit data bus but I don't think this is correct: it actually doesn't matter how the banks are organised if using a 16-bit data bus, see below.
The advantage of those two memory banks is, yes you've guessed it, the interleaving. So even word access ($0000, $0004, $0008, ...) is from bank 0 and odd word access ($0002, $0006, $000A, ...) is from bank 1. So a sequential read leads to accessing banks 0, 1, 0, 1, ...
The reason, as I understood it, is a so-called precharge time for the DRAM which happens after each time you access a bank.
For example a 60ns DRAM can have 40ns precharge time and together with
other stuff one memory access can take as much as 110ns (60 + 40 + "the rest").
ST-RAM in Falcon is a 80ns DRAM and the full cycle takes as much as 150ns.
However if one 16-bit bus access takes four cycles in Falcon, for 16 MHz we have 4 * (1/16 000 000) = 4 * 62.5ns = 250ns. Even on an accelerated (25 MHz) data bus one access takes 160ns. So no problem here, we have plenty of time for one DRAM cycle.
This isn't a problem even for a move.l because one word access takes 150ns and we can do another one only after 250ns. So whatever you (as a programmer) do, it shouldn't matter how do you access ST-RAM, you can't do it "wrong". However, what about the Videl?
The Videl reads data from ST-RAM as 32-bit longs. It does this via a burst of 17 long reads (CAS cycles; the first one needs two additional RAS cycles for an init). And here it finally starts to matter: it the reads weren't interleaved, we'd get stalls all the time.
I don't know how quickly Videl reads those longs but I'd bet that it is faster than 250ns (naively we can deduct this from its clock: 25.175 MHz / 32 MHz, i.e. much faster than the CPU).
EDIT: actually we do know how quickly Videl reads those longs.
As mentioned, it uses a burst read of 17 longs which stalls the bus for 19 (16 MHz) clock cycles. Therefore if 17 longs take 19 * 62.5ns = 1187.5ns, 1 long takes 1187.5ns / 17 = ~70ns. So you see, we greatly benefit from the fact that this long is read from two banks at once (and then Videl waits for 80ns for the precharge) instead of reading a 16-bit word ... waiting 80ns ... reading another 16-bit word ... waiting 80ns ... etc. Basically doubling our transfer rate.
In fact nowhere seems to sell them any more full stop 
