Disclaimer: I'm not actually trying to build a project here, this is just something I'm interested in understanding!

In the BBC Micro, the graphics framebuffer data was stored within the main system RAM. To extract it, the RAM was run at twice the clock speed of the CPU, so the graphics hardware could have access to the RAM at the times the CPU wasn't using it.

My question is, would this scale? If someone were to build a system with a 14Mhz 6502, and lots of 28Mhz-capable RAM, could a video circuit be built that would be able to display a screen with higher resolution and colour depth than the Beeb could manage?

I assume that the timing of the RAM fetches for the video data are not precisely tied to the timing of the screen sync frequency? In the Beeb, was it a case of the video circuitry performing a RAM fetch whenever it was needed, so that it had the next byte ready to output when the video circuitry next needed to output something?

Welcome!

Yes, if you have access to more RAM bandwidth, then you can drive a higher resolution display. Although the Beeb does indeed spend half the RAM bandwidth on the screen, leaving half for the CPU, other ratios are possible - it's just more complicated to set up.

For example, if the RAM could satisfy 8 accesses per microsecond, rather than 4, it could deliver 6 bytes per microsecond to the video system and still keep a 2MHz 6502 occupied.

I don't quite understand your last paragraph. The video subsystem is not much more sophisticated than a shift register, so a byte needs to be fetched each time a byte is needed - for 8, 4, or 2 pixels worth of bits.

(In the case of the Beeb, the video system is also responsible for the DRAM refresh - the address lines are connected in such a way that the video access satisfies refresh requirements.)

I think I'm right in saying that the 'video' accesses happen all the time, even outside the active display. One might say that some proportion of the memory bandwidth is unused.

(In the case of Acorn's Electron (and various other systems), the CPU is, in some video modes, starved of memory bandwidth during the active display, but only then. That's a different tradeoff: all the memory bandwidth is used, but some proportion of the potential CPU performance is sacrificed.)

Also note that the RAM could be setup to deliver more than 8 bits at a time, depending on the number and width of the RAM chips. Even if the CPU only needs 8 bits at a time, the video could read 16, and therefore drive a higher resolution display without needing faster RAM access.

I suppose what I'm trying to get at is that the RAM is capable of being accessed at some rate, and it has two customers, namely the video and the CPU. The system designer looks at what's needed for the desired video resolution, and what's needed for the desired CPU performance. It's potentially much more subtle than just 50:50.

Hope this helps. I realise it's a bit disjointed.

Sorry, I'll try and clarify what I mean:

* On the beeb, the CPU is at 2Mhz and the video circuitry is also at 2Mhz. So the video circuitry could conceivably read data from RAM at 2,000,000 reads per second, right?

* I assume the video circuitry does not need to read from RAM at quite this rate in order to saturate the video output. So what does it do -- does it have some internal logic to only read from RAM sometimes, or does it just do a read every clock cycle and sometimes ignore the data it just fetched? (Or am I wrong and it does need the full 2Mhz of data reads in order to satisfy the screen output?)

On the BBC, in modes 4-7, the video circuit actually only needs to fetch from RAM at half the CPU clock rate (i.e. 1MHz). But in MODES 0-3, it does need all 2MHz to pull enough data from RAM to drive the display. Edit: The maths for this is, e.g. for MODE 0 (640x256x50Hz) - there are 50 frames per second of approximately 312 lines, so that's 64us per line. Of that, 40us is visible, and the remaining 24us is porches and the horizontal sync pulse. At 2bpp, 640 pixels requires 80 bytes - and 80 bytes divided by 40us gives a 2MHz fetch rate.

Regardless, I think the CAS/RAS signals to the RAM still run in the odd cycles, I don't think there's any circuit to prevent it - it just requests the same byte twice (except in MODE 7 where it does a little trick to ensure the DRAM refresh hits enough addresses). Note that this is really a function of the 6845 CRTC and RAM control circuit, rather than the video processor which as BigEd said, mostly just picks up a byte of data, splits it into pixels, and does a palette lookup.

To run higher resolutions with interleaved CPU accesses, at a basic level you do pretty much need to also increase the CPU clock as well, and keep it in sync. The reason is that as the video circuit needs more frequent access to memory, the CPU's potential to access it only comes in shorter windows. Logically you need to time the "phi2 high" phase with one of these windows. Potentially you could run with a very asymmetrical clock, so phase 1 would be elongated and you'd deliberately miss a few other RAM access windows, but there doesn't seem to be much point - if you can get the CPU/RAM running with such a short phi2 phase, you might as well run with a short phi1 phase as well and just get more speed out of the CPU overall.

On the other hand, if you can't get it stable with a short phi2 phase, then you're a bit stuck, and this is why it actually makes a lot more sense to separate the video memory from the main memory. All you need to do is add a circuit between them that latches the data back and forth. So when the CPU writes to video memory, this interface circuit puts the data in a short FIFO, and the video circuit can pick it up whenever it's ready, without having to synchronise the two clocks, while the CPU goes on with its business. For reads, you similarly need to latch the read data from the video memory - and in this case, if the CPU is slower than the video memory, it's pretty easy to do this during the CPU's phi2-high phase. If the CPU is not slower then you need to pause the CPU clock until the data is ready.

Having a separate interface between the two also opens the door to optimizing the way the video memory is presented to the CPU. I'm experimenting with this now, along the lines of things that were done in the EGA/VGA PC graphics cards - ways to mitigate the CPU's rather narrow 8-bit data bus, poor support for indirect addressing, and low overall memory throughput. So we can remove the need for the CPU to use the address bus to select what memory to write, and just let it write to a zero-page I/O port, to get more throughput; and we can take the 8 bits of data from the CPU and process that on the way to a potentially 32-bit framebuffer in various ways. Another trick from the EGA/VGA days is getting fast video-to-video copies. There are a lot of advantages to the flexibility you get from making a bespoke interface for video memory.

Oh wow, I am surprised it lines up so exactly!



Yeah, I can see how there must be many advantages to doing it that way.

For my dream system, though, I'm still clinging to the idea of shared RAM. I just like it conceptually! My next thought experiment is going to be working out what it would take to do things like hardware sprites using the shared RAM model. I'm guessing we'd need to clock the video stuff even faster, and have some registers to keep hold of whatever video data needs to be output while the RAM access is being used to fetch sprite data for the next line.

BTW thank you all for being willing to answer newbie questions. I'm a programmer but very new to hardware — so I have the tendency to think in code, which doesn't help when I'm thinking about a system that is not running on a processor!

Yes, gfoot's explanation is spot on....

If you would like a good source of information that dives into the older video controllers, look for an old reference book:

CRT Controller Handbook by Gerry Kane. You can likely find a PDF download of on the net... I still have the hardcopy I bought when it first came out. It's a good read.

_________________
Regards, KM
https://github.com/floobydust

Yes, it's pretty exact for PAL. There's actually 312.5 lines per frame, with interlacing, which comes to 64us per line exactly. NTSC is almost the same line rate, but slightly off (and fewer lines per field, and more fields per second).

The fly in the ointment is that since those days, the pixel clock for standard definition TV seems to have been standardized at 13.5MHz, not the 16MHz that the Beeb used. It means that modern TVs can't necessarily display the Beeb's resolution very well - at least some I tried didn't like it. My standard definition circuit is here: https://github.com/gfoot/compvideo6502/ It used to use a 16MHz base clock (1MHz CPU clock, 8MHz pixel clock, 384x256 resolution with overscan) but I swapped to 27MHz base clock (around 1.8MHz CPU clock, 13.5MHz pixel clock, 640x256 resolution) and got pretty good results that way.


I'd certainly agree that synchronizing the clocks makes it easy to get this kind of system running quite efficiently, and there is a simplicity to the result. Once it works it's hard to break.

However, regarding sharing the RAM, the 6502 can only address 64K of RAM, so if you want more resolution then you're going to run out pretty quickly. You need at least a banking system between the CPU and the RAM - personally I use a 6522 for that, using one of the ports as a temporary bank register when accessing video memory - and by the time you've done that, you've sort of made your video RAM be "special" anyway. Why stop there?

These are all good stepping stones though, I wouldn't overthink it too much as until you actually build something, you're not necessarily making good decisions anyway. I learn most by doing, so my approach is to think of something, build it, fix it, and keep iterating. Sometimes you need to go back and change something when you made a bad decision in the past, but it's all part of the journey, and hopefully I learn right from wrong along the way!


That's a very deep topic. My experience in this so far is that using separate memory is beneficial if you want the sprites to be able to be placed at arbitrary horizontal positions on the screen. It's kind of hard to get it to work using any form of shared memory otherwise, because of the way the video output needs to work, extracting multiple pixels from each byte of memory. There are probably alternatives but I think it'll get complicated.

I made a 6502-based Boing Ball hardware sprite demo a month or two ago, and that had three memory areas - main RAM, video RAM, and sprite ROM. I think the Amiga also used separate sprite RAM from video RAM but I never used that system and could be wrong. I'm pretty sure C64 used shared memory between the two, but paused the CPU temporarily when it needed to read sprite data. It's tricky if you're trying to use shared RAM because I guess the amount of data needing to be read per pixel could vary.

The approach I used in the Boing Ball demo doesn't really scale though, as every sprite needs a separate ROM chip, so that they can all be cycled and blended at once. I've been thinking through alternatives but not settled on anything yet.

If you are interested in this kind of thing, it's well worth reading about how the Atari 8-bit systems did all this. Their video hardware was way ahead of its time.


Don't worry, I know the feeling! And it's funny how some things which are expensive in software are trivial in hardware, and vice versa.

Good answers above, but maybe just a couple of things I'd like to add...


As noted, better to say the CPU needs a rate of 2e6 accesses per second, and so does the video.

The Beeb is a particular case of the available RAM chips being faster than necessary for the CPU speed, and so a double-speed RAM system was possible, and chosen.

It just so happens that double-speed is a relatively easy idea for a 6502 system. However, there's nothing special about a 50% duty cycle, or about a 1:1 rate of accesses. If you look into the best "noise-killer" circuit for the Acorn Atom (where the video is asynchronous to the CPU but uses the same memory) you'll find that today's fast RAM chips allows for a clever seamless sharing of the two customers. See here. Squeezing three or four accesses into one CPU cycle is possible, and in this case advantageous.


I think the video system (specifically, the 6845) continues to count and to perform reads throughout the frame - one hint about that is, as mentioned, this is the way the DRAM is refreshed.

OT: For resyncing video from retro systems to modern TVs, see the RGBtoHDMI project (originally a Dave/hoglet invention and now in the hands of IanB/IanSB. Also see here.) (Please start a new thread if picking up on this mention.)

Wise words. Don't worry, I am not going to make any decisions to apply to a concrete project just yet — I imagine my first project won't even have any video!

I've not done anything lower level than Arduino/Teensy yet. So I guess Hello World using a 6502 and a character LCD is probably my first goal.

Amy

Sounds good! Just a note though, some character LCDs are very fussy about timing, and particularly they need some delays during the start-up process. So, be sure to read the datasheet carefully.

Welcome, Amy.

I wouldn't say they're fussy, but there's a sequence we got from an applications engineer in the late 1980's at work that makes them all work every time, every brand, no exceptions, which doesn't come through in the data sheets. I have sample code in different forms at http://wilsonminesco.com/6502primer/LCDcode.asm to go with the circuit in the "Displays" section of the 6502 Primer's "Circuit Potpourri" page, at http://wilsonminesco.com/6502primer/potpourri.html#LCD . Note that the function set is written three times. This is the part that most people miss; and it's needed for a really reliable startup. The Displays page of the 6502 Primer is at http://wilsonminesco.com/6502primer/displays.html . The last third of the page has several tiny video adapter boards and helpful links for video and displays. Let me recommend going through the whole 6502 Primer though which is about building your own 6502 computer. It's actually a set of 22 articles, many of them applying equally well to computers using other processors as well.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

LCD timings are.. well... not fast.

Anything above 1Mhz is problematic. Even at 1Mhz, some stuff is just too fast for them. I have a 4x40 LCD on my SBC, and I'm driving it with a 6526 (And plan to migrate to 6522 soon). With some delays on the code, I can drive it with the system running at 15/16 Mhz

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hey everybody, long time 6502 fan and of course like everyone else have grand plans for my own systems (which will probably end up being 65816 based) but have given much thought to video over the years, so this thread piqued my interest. I wish there were more options for adding video to DIY builds!



I see it as the video modes being a function of what the architecture would allow, rather than trying to achieve some arbitrary video mode and then making it work with the hardware available. Although some neat tricks were done to squeeze a little more oomph out of it...

My knowledge is mostly in regard to the C64 so my examples will be specific to that machine. It's what I had as a kid and learned to code on. Of course at the time I wished for more sprites, higher resolution, more colors, etc without thinking about exactly how that would be accomplished!

You are right that higher clock speed would allow for higher resolution/colors/etc, but keep in mind that comes with higher memory usage. The resolution and color depth of these machines at the time were both constrained both by the clock speed and the feasible amount of memory in the system at the time. For example a 320x200x8 bit (256 color) framebuffer would be 64K of RAM! RAM is cheap now of course but the address bus size is still a constraint.



For building an inexpensive system, shared RAM with video was the way to go on all these home micros. The drawback that always frustrated me, is that the entire system was constrained by the video system - which means that the clock speed of the main bus is set in stone, and made accelerating the CPU complicated. An accelerator card needed to have a completely separate CPU/RAM and shadow copy all writes to the main RAM. For this reason it was always my dream to build a system with dedicated video memory and decouple the two!

Anyway, since you mentioned sprites, I thought I'd summarize how the C64 VIC-II chip managed pulling extra information needed.

Similar to the specs above, at 1MHz this translates to one byte per 8 pixels at 320x200. So for each scan line, in the viewable area the VIC-II needs to grab one byte per clock cycle, and write out the corresponding 8 pixels to the screen with the 8 MHz "dot clock". By alternating access with the CPU on separate phases of the clock, each can access memory at an effective 2MHz combined bandwidth.

There is a problem though - for text mode, the VIC would need to read a byte for the character in that location, and then read the data from the character generator ROM. Even worse, it needs yet another byte (well, just a nibble) for color information. Graphics mode is similar in that while the bitmapped graphics are read from memory, the character matrix is used for color information in addition to the color matrix (for multicolor). So the VIC needs some way to effectively obtain three bytes of data for each clock cycle, but since two of those are shared for each 8x8 cell they can be cached and used on subsequent lines. And then there are sprites on top of all that.

On the first scan line of each 8x8 cell row, the VIC chip needs the entire bus, or 2 MHz of bandwidth. It shuts down the CPU for this scan line and during each cycle it does two memory accesses - one to the character matrix (which does double duty as character code, or partial color info for graphics mode), and one for the bit map data. Where does the extra access for the color matrix come from? There is a 1k x 4 bit static RAM chip in the C64 that holds color information for all cells, and the VIC chip has a private 4-bit data bus to this chip. When it reads the character matrix, it simultaneously reads from color RAM. Since the character matrix has to be located on a 1K boundary, the low order address bits can be shared with the color RAM chip.

The extra information is cached in the VIC chip to be used for the next 7 lines, and the cycle starts over again. Each line where the CPU is stopped is referred to as a "bad line".

Sprite data is read and cached while the border is drawn, before the next scan line starts. Since it is read and refreshed every scan line, sprites can be multiplexed. And if you count the cycles available, it works out to be just enough for the C64's 8 sprites, each three bytes (24 pixels) wide.

The result is 16 colors on the screen simultaneously (up to 4 per 8x8 cell), and 8 sprites with up to 3 colors each using 8kB for the graphics, and 1.5kB for color info. Since there is no extra bandwidth, multicolor mode reduces the resolution to 160x200 to use two bits per pixel.

With just a little extra headroom, this could be greatly simplified with a higher clock speed and more bits per pixel. The tiled graphics mode though is a force multiplier for scrolling (using character mode with a custom character set, much like the NES and other game hardware) combined with a hardware scroll function of 8 pixels. Otherwise the 1MHz CPU wasn't fast enough to scroll a graphics screen. It can barely scroll a character screen flicker free. And the color RAM isn't relocatable, so while you can build a new buffer for the screen character matrix and then switch the buffer every 8 pixels, you have to update the color RAM in place. This means starting the update right after the raster starts (chasing the raster) which gets you half way by the time the screen is rendered, and then finishing the bottom half before the raster catches up on the subsequent screen refresh.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!