BBC clock speed

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
jregel
Posts: 131
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

BBC clock speed

Post by jregel » Tue Aug 06, 2019 1:02 pm

I’m trying to get a better handle on how the BBC works, in terms of its clock speed.

The RAM in the BBC is clocked at 4Mhz. The 6502 is clocked at 2Mhz, so there is a further 2 million clock cycles that could be used to read/write RAM when the 6502 isn’t accessing it.

How is this non-CPU time allocated? My understanding is that the display, 6845 and Video ULA, operate on RAM when the CPU isn’t. Is it split evenly between the two devices (1 million cycles for the 6845, 1 million cycles for the Video ULA)?

Are the 6845 and Video ULA the only “DMA” chips in the BBC, with everything else being written to or read by the CPU?

And in terms of the Video ULA, is that clocked faster internally? I see reference to 16Mhz screen modes. Does that relate to the internal clock speed of the Video ULA?

Thanks
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

cmorley
Posts: 937
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: BBC clock speed

Post by cmorley » Tue Aug 06, 2019 1:34 pm

Not quite. Half of every 2MHz cycle goes to the video and half to the CPU.

So the RAM does 4 Million accesses a second... its clock for the DRAM Row/Column addressing is 8Mhz then I suppose.

The 6845 generates the RAM address & the ULA gets the data. Yes only the ULA & Teletext chip can access memory directly.

The ULA takes a 16Mhz clock and spits out the 8,4,2 & 1(?) for the rest of the system. The pixels are clocked internally from this clock - there is a high speed/low speed selection register IIRC.
Last edited by cmorley on Tue Aug 06, 2019 1:41 pm, edited 2 times in total.

User avatar
1024MAK
Posts: 9049
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC clock speed

Post by 1024MAK » Tue Aug 06, 2019 2:03 pm

The VideoProc / Video ULA is a slave to the data from the DRAM, it’s the 6845 that addresses and controls the DRAM. The VideoProc / Video ULA has no control of the RAM.

The VideoProc / Video ULA includes various clock dividers, hence has a 8 MHz output, a 4 MHz output, a 2MHz output, and a 1 MHz output (all used by various other devices). Internally it operates at 16 MHz, hence the 16 MHz input.

So every cycle when the 6502 is not using the DRAM, the 6845 will generate a video address (whether needed or not), the data from the DRAM chips is then fed to the VideoProc / Video ULA, it then converts the data byte to the correct bit stream for the RGB outputs.

Mark
Last edited by 1024MAK on Tue Aug 06, 2019 2:16 pm, edited 1 time in total.

Coeus
Posts: 1313
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC clock speed

Post by Coeus » Tue Aug 06, 2019 3:31 pm

1024MAK wrote:
Tue Aug 06, 2019 2:03 pm
So every cycle when the 6502 is not using the DRAM, the 6845 will generate a video address (whether needed or not), the data from the DRAM chips is then fed to the VideoProc / Video ULA, it then converts the data byte to the correct bit stream for the RGB outputs.
This "whether needed or not is significant, isn't it, because it is the way the 6845 sequences through the addresses that provides the refresh for the DRAM.

RobC
Posts: 2655
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: BBC clock speed

Post by RobC » Tue Aug 06, 2019 4:29 pm

jregel wrote:
Tue Aug 06, 2019 1:02 pm
And in terms of the Video ULA, is that clocked faster internally? I see reference to 16Mhz screen modes. Does that relate to the internal clock speed of the Video ULA?
Yes - as others have said, the Video ULA runs at 16MHz. The 6845/CRTC runs at 1MHz in the lowest resolution modes (4-7) and at 2MHz in the highest resolution modes (0-3) with the speed being controlled by the CRTC clock output from the Video ULA.

So, in the highest resolution modes, the CRTC is generating 2 million addresses per second and so the Video ULA is getting 2 million bytes of data per second. In modes 0 and 3, the ULA is spitting out 8 pixels per byte so 16 million pixels per second.

User avatar
1024MAK
Posts: 9049
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC clock speed

Post by 1024MAK » Tue Aug 06, 2019 5:46 pm

From the 6845 CRTC datasheet:
Refresh Addresses are Provided During Retrace, Allowing the CRTC to Provide Row Addresses to Refresh Dynamic RAMs
Mark

jregel
Posts: 131
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: BBC clock speed

Post by jregel » Wed Aug 07, 2019 1:30 pm

Thanks for all the replies!

So am I right in understanding that the 6845 is the only other chip that reads from RAM, and that is writes a stream of bytes to the Video ULA?

This occurs at either 1Mhz or 2Mhz, depending on screen mode.

Why does the Video ULA need to run at 16Mhz? Is this related to doing palette lookups etc.?

Thanks!
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

cmorley
Posts: 937
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: BBC clock speed

Post by cmorley » Wed Aug 07, 2019 1:32 pm

The 6845 doesn't read it just generates addresses. Other hardware does the reads and feeds the data to the ULA or the teletext chip.

The pixel clock in mode 0 is 16Mhz.
Last edited by cmorley on Wed Aug 07, 2019 1:32 pm, edited 1 time in total.

Coeus
Posts: 1313
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC clock speed

Post by Coeus » Wed Aug 07, 2019 2:03 pm

jregel wrote:
Wed Aug 07, 2019 1:30 pm
So am I right in understanding that the 6845 is the only other chip that reads from RAM, and that is writes a stream of bytes to the Video ULA?
Being pedantic, perhaps, but the 6845 is not in the data path from the RAM to the Video ULA. The 6845 generates the addresses and the RAM responds by placing the corresponding data on the data bus but other hardware reads that data.

It may help to be familiar with the "typical " 6845 circuit. The 6845 was designed at a time when character, rather than bitmap graphics, displays were the norm. If you look on the data sheet, or on the BBC circuit diagram you will see the 6845 has outputs MA-MA13 and RA0-RA2. In a normal character display the MA lines are put on the address bus to the RAM. The RAM responds with the character value at that screen position which is then latched by an external latch. The latched value together with the RA lines would form an address into the character generator ROM. The output from the ROM would be loaded into a shift register and shifted out a bit at a time to generate the pixels in the scanline. See this block diagram from the 6845 data sheet:
block.png
The teletext mode does work almost exactly like that. Look at this part of the circuit diagram:
ttx.png
Here the 74LS273 is the latch (octal D-type) and the teletext chip SA5050 combines a character generator ROM, a fixed palette. the shift register etc.

For the bitmap modes, the Video ULA replaces the external latch and shift register and does such things as splitting the byte from the RAM into pixels, looking them up in the palette etc. See this part of the circui diagram:
bit.png
The Video ULA is also selecting which RGB signals are sent to the RGB socket and on towards the PAL encoder, the internally generated ones from a bitmap display mode or the ones from the teletext chip.
Last edited by Coeus on Wed Aug 07, 2019 2:28 pm, edited 3 times in total.

User avatar
1024MAK
Posts: 9049
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC clock speed

Post by 1024MAK » Wed Aug 07, 2019 2:17 pm

jregel wrote:
Wed Aug 07, 2019 1:30 pm
So am I right in understanding that the 6845 is the only other chip that reads from RAM, and that is writes a stream of bytes to the Video ULA?

Why does the Video ULA need to run at 16Mhz? Is this related to doing palette lookups etc.?

Thanks!
Be careful how you think of the video the system. It’s not like a microprocessor. And although it is a form of DMA, unlike a DMA chip that can be fully programmed by the microprocessor, the video system is specialised to do only one task.

To access memory (in this case, RAM), you need to supply it with an address of the location you want to access. Then you need to provide it with the correct control signals (select signals and the read/write control). To generate a video picture, the timing has to be exact. The job of generating the address, the correct control signals and all of the timing for these, is that of the 6845 CRTC (Cathode Ray Television Controller). The only other things that the 6845 CRTC does, is to generate a cursor (sent via special pins to the VideoProc / Video ULA chip) and to continue to generate addresses and control signals even when not required for the video signal (during the time when there is no picture information in the video signal) in order to provide refresh cycles for the Dynamic RAM (DRAM) chips (needed otherwise the DRAM will forget it’s content).

As the video system never needs to write data to the RAM, all cycles are “read” cycles.

The VideoProc / Video ULA chip does not “read” the data as such. Rather data (that happens to be on the video data bus, curtesy of the actions of the 6845 CRTC) is transferred into a latch buffer in the VideoProc / Video ULA chip.

Think of it a bit like someone calling out bingo numbers. You don’t get a choice of what they are calling out. You just listen and accept the number that they call out. They will continue calling out whether you are listening or not. Then once you have a number, it is up to you to do something with it...

Unlike bingo though, the 6845 CRTC never stops...

The microprocessor can write data to registers in the 6845 CRTC to set up the correct parameters for the wanted video MODE. As said above, some MODEs require data transfer from the RAM to the VideoProc / Video ULA chip at 1 MHz while the higher resolution MODEs require 2 MHz, hence the different clock speeds.

Mark
Last edited by 1024MAK on Wed Aug 07, 2019 5:51 pm, edited 1 time in total.

jregel
Posts: 131
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: BBC clock speed

Post by jregel » Wed Aug 07, 2019 4:40 pm

Thanks again, everyone, both for the answers and bearing with my questions!

I'm reading through all the replies and trying to get a handle on how it works. As Mark (1024MAK) recognised, I was seeing it a bit like a microprocessor, and find the bingo example helpful.

Numerous comments have used the phrase that the 6845 "generates addresses". What does this actually mean?

Does the 6845 request the contents of specific memory addresses (over the address bus), the value of which is then returned sent out over the data bus? The Video ULA then reads the data from the data bus?

And this can only happen during the window that the 6502 isn't accessing memory/the bus?

Thanks
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

VectorEyes
Posts: 242
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: BBC clock speed

Post by VectorEyes » Wed Aug 07, 2019 4:54 pm

Yes, the CRTC simply generates addresses by making some of its output pins high and others low. It does not fetch the values stored at that address, it just creates the number, puts it on the address bus, and it's the responsibility of other parts of the system to fetch the byte stored at the address in question.
Last edited by VectorEyes on Wed Aug 07, 2019 4:55 pm, edited 1 time in total.

User avatar
1024MAK
Posts: 9049
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC clock speed

Post by 1024MAK » Wed Aug 07, 2019 6:28 pm

The 6845 CRTC is in essence, a programmable set of counters.
It counts in binary and the count output is output as a binary number on its many address pins. It actually has two sets of output pins (because of it’s intended use as part of text character generator video system, as described by Coeus above).
But the important thing is that it effectively counts sequentially through the RAM one memory location (one byte in the case of the Beeb) at a time. When it reaches the end of the area in RAM that is defined for the current picture size, it resets back to the start address.

So in a simple block line format (applies only to the bit mapped MODEs):

Clock from VideoProc -> 6845 CRTC -> address and control lines -> multiplexer chips -> DRAM chips -> video data -> VideoProc

I hope this helps.

Mark

VectorEyes
Posts: 242
Joined: Fri Apr 13, 2018 1:48 pm
Contact:

Re: BBC clock speed

Post by VectorEyes » Wed Aug 07, 2019 8:18 pm

Quick note to clarify (maybe?) the previous post. Although from the CRTC's perspective it's outputting sequential numbers as the raster-beam scans along one scanline, the way the address lines and multiplexer chips work mean that the actual address fetched increases by eight each time the CRTC moves to the 'next character' (which happens at 1MHz in low-frequency modes at 2MHz in high-frequency modes).

The 'row number' pins are the ones that provide the low 3 bits of the fetched address, and the row only increments once per scanline.

Coeus
Posts: 1313
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC clock speed

Post by Coeus » Wed Aug 07, 2019 8:40 pm

VectorEyes wrote:
Wed Aug 07, 2019 8:18 pm
Quick note to clarify (maybe?) the previous post. Although from the CRTC's perspective it's outputting sequential numbers as the raster-beam scans along one scanline, the way the address lines and multiplexer chips work mean that the actual address fetched increases by eight each time the CRTC moves to the 'next character' (which happens at 1MHz in low-frequency modes at 2MHz in high-frequency modes).

The 'row number' pins are the ones that provide the low 3 bits of the fetched address, and the row only increments once per scanline.
So that's an artefact of the way character display would normally work. The characters in a character generator ROM would normally be store with the row of the each character in adjacent bytes before moving on to the next character, so:
character one, top row.
character one, next row.
...
character one, last row,
character two, top row.
etc.
So the character code grabbed from RAM would form the high part of the address to the character generator ROM and the RA lines the low part of the address. For scanning the display the scan must do the top lines of all the characters on the first row, then the second line of each character etc. Understanding this character mode which the designers had in mind really helps making sense of the documentation on the 6845.

In Beeb bitmap mode the sequences of addresses is exactly the same, just with the intervening character ROM skipped so the RAM control the pixels directly.

Coeus
Posts: 1313
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BBC clock speed

Post by Coeus » Wed Aug 07, 2019 9:14 pm

Another interesting thing is to check out the circuit diagram. Given that we know either the CPU or the 6845 can generate addresses how can we be sure that the RAM is seeing the address from the right chip? If you look at the circuit diagram of the BBC B, between the 6845 and the RAM is a row of 81LS85s (IC8, IC9, IC10, IC11 and IC12). The allow the CPUs address outputs to be fed to the RAM (IC12 and IC13) or two different variations of the 6845 address lines IC8 and IC9 for high res and IC10 and IC11 for teletext.

Then over to the right of the RAM is IC14 a 74LS245. That appears to be separating the CPU and some I/O stuff on one side and the RAM on the other. If you follow the wiring back this is driven by some logic in IC25 which turn seems to be doing something clever with the clock. What I think is happening here, and perhaps someone else can confirm, is splitting the data bus on those parts of the clock where it is the video system's "turn" with the RAM. That means if the CPU is accessing a slow device (1MHz bus etc.) this is not interrupted by the data transfer from the RAM (with address from the 6845) to the ULA or Teletext latch and likewise, the CPUs slow transfer does not clobber the video data.

User avatar
1024MAK
Posts: 9049
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: BBC clock speed

Post by 1024MAK » Thu Aug 08, 2019 12:55 pm

BBC Micro DRAM data-bus control

IC14 isolates the DRAM data-bus from the 6502 CPU data-bus.

One of the NAND gates in IC21 looks to see if the CPU is trying to access the VideoProc (Video ULA) registers. It also looks to see if the CPU is trying to access RAM between 0x0000 and 0x7FFF. The output pin (5) will go high when either of the conditions is true.

One of the NAND gates in IC25 then tests both the clock to the CPU and the “2MHZE” system clock from the CPU. If both these are high (CPU needs control of the data-bus) and the output from IC21 pin 5 is high, then, and only then will IC25 pin 3 go low.

IC25 pin 3 going low enables IC14, a bus-transceiver, which when enabled connects the two portions of the data-busses together, thus allowing the CPU to either read from RAM, or to write to RAM or write to the registers in the VideoProc.

If the conditions above are not true, then IC14 will split the two portions of the data-busses so that the video system can generate a video picture without being disturbed by invalid addresses from the CPU. It also isolates when the CPU is accessing ROM or any other I/O device.

Mark

jregel
Posts: 131
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: BBC clock speed

Post by jregel » Thu Aug 15, 2019 6:05 pm

Thanks again for all the comments. It’s taken a while for me to absorb it and do some more background reading…

One follow-on question: The CRTC runs at 2Mhz when displaying the high resolution modes. So, in mode 0, there are 640 * 1bit pixels = 80bytes per scanline. There are 256 scanlines = 20480 bytes for each screen. Assuming a 50Hz refresh, this is 1024000 bytes/second.

What is the correlation between the 1024000 bytes/second for a mode 0 screen, and the 2Mhz clock. Obviously there is the implication that each pixel takes two cycles, but can anyone explain what’s happening (or if I’m completely off track here)?

Thanks.
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

RobC
Posts: 2655
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: BBC clock speed

Post by RobC » Thu Aug 15, 2019 6:30 pm

jregel wrote:
Thu Aug 15, 2019 6:05 pm
Obviously there is the implication that each pixel takes two cycles, but can anyone explain what’s happening (or if I’m completely off track here)?
You're sort of on the right track but you've forgotten about the borders :)

If you look at p. 361 of the Beeb Advanced User Guide, you'll see that register 0 is programmed for 128 horizontal characters in mode 0. Register 1 defines how many of these are displayed - 80 in mode 0 so 48 characters of border (register 2 can be used to shift the display left or right).

This means that each scan line takes 1.6 times longer (128/80) than the displayed portion (64us vs 40us).

And then there's the top and bottom parts - if you look on p. 363 of the AUG, you'll see that the Beeb's screen has 39 rows rather than 32. This accounts for the rest of the time.
Last edited by RobC on Thu Aug 15, 2019 6:30 pm, edited 1 time in total.

jregel
Posts: 131
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: BBC clock speed

Post by jregel » Thu Aug 15, 2019 9:54 pm

RobC wrote:
Thu Aug 15, 2019 6:30 pm
jregel wrote:
Thu Aug 15, 2019 6:05 pm
Obviously there is the implication that each pixel takes two cycles, but can anyone explain what’s happening (or if I’m completely off track here)?
You're sort of on the right track but you've forgotten about the borders :)

If you look at p. 361 of the Beeb Advanced User Guide, you'll see that register 0 is programmed for 128 horizontal characters in mode 0. Register 1 defines how many of these are displayed - 80 in mode 0 so 48 characters of border (register 2 can be used to shift the display left or right).

This means that each scan line takes 1.6 times longer (128/80) than the displayed portion (64us vs 40us).

And then there's the top and bottom parts - if you look on p. 363 of the AUG, you'll see that the Beeb's screen has 39 rows rather than 32. This accounts for the rest of the time.
Thanks, as ever, Rob.

I think that makes sense, I'll go away and do some more reading... :-)
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: BBC clock speed

Post by BigEd » Fri Aug 16, 2019 5:40 am

That had me mildly confused for a second, so let me try...

The 6502 is clocked at 2MHz, and does a memory access every cycle. That turns out to use only half of each cycle, and the memory is capable of 4 million accesses per second, so the video subsystem also is able to make 2 million accesses per second.

All the (high resolution) modes need to fetch bytes at that rate during the active part of the display, and they can. Mode 0 is perhaps easiest to think about because each pixel is one bit.

The RAM also needs to be accessed regularly to refresh it, as it's dynamic RAM, and that's accomplished by having the CRTC make suitable accesses all the time, whether or not the Video ULA (or the teletext chip) needs the data. The video screen layout is arranged in such a way that video accesses and dummy reads for refresh do pretty much the same thing.

User avatar
tricky
Posts: 3600
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: BBC clock speed

Post by tricky » Fri Aug 16, 2019 7:50 am

Even thought the 6845 is a bunch of counters, we are still discovering subulties in the way the different implementations work and new tricks that we can play because of the way the beeb has it wired.

There are a couple of write-ups from the bitshifters for twisted brain and wave runner that explain some of these.

Something else that might interest you is RobC's VideoNULA, a replacement for vidproc/video ULA that provides new palette and scrolling functionality but has to do this within the constraints stated above.

RobC
Posts: 2655
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: BBC clock speed

Post by RobC » Thu Aug 22, 2019 9:44 pm

BigEd wrote:
Fri Aug 16, 2019 5:40 am
That had me mildly confused for a second, so let me try...
Sorry for any confusion Ed! I guess what I was trying to say was that each mode 0 pixel takes one cycle but the reason it looks like it takes two cycles in Julian's calculation is because half the screen is made up of border.
tricky wrote:
Fri Aug 16, 2019 7:50 am
Something else that might interest you is RobC's VideoNULA, a replacement for vidproc/video ULA that provides new palette and scrolling functionality but has to do this within the constraints stated above.
Julian already has one and I had the pleasure of meeting him when he came to have it fitted :D
Last edited by RobC on Thu Aug 22, 2019 9:45 pm, edited 2 times in total.

User avatar
BigEd
Posts: 2567
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: BBC clock speed

Post by BigEd » Fri Aug 23, 2019 6:39 am

No worries Rob! (One difficulty that's all my own is trying to keep track of the doublings and halvings - you can't get the right answer otherwise. But also, it's something of a coincidence that the active area is almost (but not quite) the same as half of the frame time, and part of the same coincidence that 1024000 looks like it might be related in a strict way to 1000000 or to 2000000. And I think it's potentially confusing to mix Hz with actions-per-second, if the actions are not totally regular.)

Post Reply