I don't know of one, but here are some highlights - you can work out the fine details for yourself!Is there a step by step description somewhere of the Beeb’s strategy, inclusive of which component does what, at a given 8MHz clock phase plus the (analogue?) delay it was chosen to create?
The main strategic decision on the BBC is to do two complete DRAM cycles during each cycle of a 2MHz clock - one for the CPU and one for the video. This means that the machine falls into two halves - one with the CPU and all the peripherals, one with the DRAM and the video, with IC14 being the link between the two.
A significant tactical choice in pursuit of this is the point Mark made above: the clocking of the 6502. The 6502 was intended to be used with Phi-in (Phi0) as an arbitrary clock, with the CPU then deriving Phi1 and Phi2 from it - with the rest of the system timing to be derived from those two clocks. Acorn chose not to follow that standard scheme, deriving most of the timing from Phi0, some from Phi1 and leaving Phi2 (which is the same polarity as Phi0, just delayed a bit) completely unused. I don't know the exact thinking here, but clearly the main point is to have that Phi0 be a division of a higher frequency clock and so have the other edges of that clock available to time DRAM events; indeed I think the entire DRAM system is driven from those clocks, with Phi1 used only to time things on the CPU bus. Note that the combination of Phi0 and Phi1 provides timing to enable the IC14 buffer between the CPU databus and the DRAM databus - so a slightly narrower than 250ns window when the DRAM half of the machine (timed by Phi0) says it's the CPU's turn rather than the video _and_ the CPU says (Phi1) that it's the data half of the CPU's cycle (which is broadly address in Phi2 time and data in Phi1 time). Phi0 and 2MHzE (the inverted Phi1) are both 2MHz clocks with the same polarity, just 2MHzE being somewhat delayed.
Another significant aspect is that the CPU "sometimes runs at 1MHz" in order to provide less demanding timing for some of the peripherals (ie. permit cheaper ones for the ACIA/6522 etc, and permit longer cables on the 1MHz bus). Those peripherals don't just want a cycle to take 1us rather than 500ns, they need 1MHzE to be a free-running 1MHz clock, so the CPU is stopped for either 1 or 2 extra 2MHz cycles to align with the free-running 1MHzE. This is all done by interfering with Phi0 - so the CPU ends up doing an extremely long Phi2 (address) time and a usual-length Phi1 (data) at the end of it. Note that all of this is only affecting the CPU half of the machine - the DRAM timing keeps ticking along at normal speed meanwhile: the enable on IC14 also has A15 feeding into it, and all the 1MHz-speed devices are in the top half of the memory map, so the DRAM doesn't care.
After that, you've got a fairly vanilla DRAM setup - almost any design has some sort of multiplexor to feed low/high halves of the address onto the DRAM address bus, and as I alluded to earlier the timing of this MUX is almost the same as RAS plus or minus a bit of delay to make the addresses change just after RAS has gone low (DRAM datasheet Row Address Hold time). In the BBC design, this isn't just a 2-way MUX for high/low addresses, it's also a mux between CPU addresses and video addresses, so you'd expect a 4-way mux, except that Mode 7 needs different addressing from the high-res graphics modes, so it's actually a 6-way MUX for high/low halves of CPU, Mode7, hires addresses. This MUX is IC8/9/10/11/12/13, controlled by IC45 - and you can see that one of the inputs to IC45 is actually RAS itself, so that much is all exactly as expected. Timing of RAS/CAS is all derived fairly straightforwardly from the 8MHz clock. Again like any typical contemporary design, all the DRAMs get RAS all the time, and CAS is selectively enabled to switch between the two banks of RAM or to disable altogether when a RAM access isn't actually required (notably for the cycles reserved for CPU when the CPU is accessing ROM or peripheral). Refresh in this design needs no special attention as the video controller naturally cycles through sufficient addresses to keep the DRAM refreshed (this is another reason why RAS is unconditional).
One extra complicating factor is that the to save pins on the VIDPROC, it only has a connection to the RAM databus and not the CPU databus. This means that accesses by the CPU to the control registers in the VIDPROC need to flow through the IC14 link as if it were writing to DRAM (and without accidentally writing to DRAM as well!). This is why nVIDPROC feeds into the address decoding in a couple of places.
Statistics: Posted by arg — Mon Feb 17, 2025 10:30 pm