Hi Guys,

I have been looking at trying to develop a video system for some time.

I have just finished putting together a block diagram of how I want the system to work.

It might not mean much at the moment but details will come soon.

I intend on using the project as a final year degree project.

I think you can do all of the graphics processing on the FPGA, instead of a 2nd mbed.

I don't really think you would want any decoder for the sound, I'm not too sure but it might be difficult to mix sounds together if you are using MP3s. It might be better to use WAV files and simply use the DAC on the mbed.

Why is there both a SD card interface and a 8 Mbit flash memory?

What a great senior project it would be to design a game console.

But, as they say, the devil is in the details. A few questions pop to mind after looking at your diagram:

1. There is no address or data bus, per se, available from the mbed module. You can make a "bus" from the parallel port signals - there's a library function for that - but it will have to be driven under program control. So that will make it slow as compared to the true address/data signals from a raw CPU.
2. Also, the mbed has only 26 digital pins available. So an 18-bit address bus and a 16-bit data bus just wouldn't fit. You could use some sort of serial-to-parallel I/O expander, though that will slow things down still more.
3. It looks like you are planning two-port access to the SRAMs. Are the SRAMs themselves two-port devices? It looks like it, since they are each drawn with two sets of address and data connections. In this case you don't need the 74cbt3244s - just hook one side of each SRAM to the "Graphics Processor" and the other side to the "VGA Controller".
4. But if the SRAMs are single port devices, then those two sets of data and address connections would merge into a single set per SRAM. In that case, the 74cbt3244s need to be arranged such that when one SRAM's data and address lines are connected to the Graphics Processor, the other SRAM's data and address lines are connected to the VGA Controller, and vice versa.

Best of luck with your project.

By the way, what you are building is VERY similar to this

http://excamera.com/sphinx/gameduino/

Its design should help you

Hi guys, thanks for the response so far,

Firstly I have been continuing to look at this project, and I have encountered a problem and I'm not sure what the best way to deal with it is.

As Frank pointed out I have an SPI SD Card interface and a FLASH 8 MBit device.

The reasoning behind this would be to store data on the console such as save data possible, or any other information that maybe required.

I included it at this point because I would rather have it in at this point an find out later on that I dont need it than not have it and find out later that i do need it.

It is far easier to remove something or not use it in a system than to have to incorporate it later on.

That being said as you can see from my diagram I intend to use an 8MBit flash device with a 16 bit data bus.

Unfortuneatley I have just discovered I cant do that.

Something I should point out is that although I have labelled the 2 controllers MBED's they are not this is incorrect.

They are in fact LPC1768's on their on own. This allows me to have larger buses, however it does still limit me because there is only 1 18 bit port available and 1 16 bit port and the down side on the 16 bit port is that 4 of those bits are required for the SPI bus.

I have 2 options in front of me as i see it either multiplex the address and data bus so it takes double as long or select a flash device with an 8 bit data bus configuration.

I believe I should go with the 8 bit data bus on the flash device but I wanted to get your opinions on the subject before deciding.

It has also been raised about the SRAM's and the bus exchangers. both SRAMs will serve as frame buffer memory for the system. There are two of them to facilitate the double buffered video memory function which will eliminate screen flicker.

I should point out the SRAM's are seperate devices, and the system is intended to be un syncronised. I am quite new to this so point it out if im wrong but I want the Graphics processor and the VGA controller to be seperate. The reasoning is that to me it seems relatively simple to have the VGA controller constantly reading from an SRAM and displaying what ever data it gets.

By doing this it means that the Graphics controller can at any point switch the control signals when it is finished writing the new frame to get the VGA controller to start displaying the new image.

I am in the process of trying to write a document to explain about how I am going to get it to work and how I think it will.

I am sorry if this explanation isnt clear but if something isnt clear please point it out and I will try to explain it further.

Thanks for your time

I think I have just understood what was said about 2 port SRAM's

No they are not, however I do intend to hook up 2 ports to each sram but only one of them will be able to be driven at any 1 time through the use of the bus exchangers.

I have just investigated the device as I had listed the wrong device anyway, and have quickly whipped up a new image correcting that section to better high light how it will really work.

Sorry for the error.

Hi Guys, Just to make things clearer I have made an updated block diagram incorporating the update posted above to correct my earlier mistake.

Isn't this needlessly complex ? Why not just take a large fpga and program all of it in single chip, just add ram and storage ?

I'm used to seeing this kind of stuff from students, a system that works with what they are already familiar with. The spirit of "we can do this" and "let's get stuff done" is admirable and probably caused by deadlines, not options are explored.

FPGAs get pretty expensive when you get large, I doubt students have a sense of scale when it comes to logic element counts, although you can finish the HDL and then do a test synthesize first to get an estimate, but that's hard enough already.

Sure I understand, I hack together all kinds of things myself and I applaud the effort but I try to follow the KISS principle. For example driving a controllerless QVGA display with the mbed, I could have put in all kinds of sram and latches and buffers and arbitration logic to get it connected. By connecting it directly to the mbed although it limited the number of colours and cost a bit of speed it works very well.

Creating a video game console is done on the web over and over again with relatively small FPGA's, some even emulate different 8 and 16 bit game/home computers in the same chip.

When building a console (with large screen output) from scratch I think the mbed is not a good starting point because of the limited IO, RAM etc. But that is just my 2 cents :-)

Thanks guys for your input, i have since changed a lot of how i intend to do it, but going back to what i intended to do originally Frank got it spot on really. I dont know how to do VHDL properly, I have so far been able to put together my own VGA controller using a CPLD an generating the code using the schematic entry function within Xilinx software. Now on to what I am currently trying to do is use a Freescale i.MX23 processor, I have chosen this as its in a 128 qfp package, it operates at 454MHz I am connecting DDR1 memory to it and will be using the PSP LCD WQVGA 480 x 272 display available from sparkfun. I have chosen a processor as i am just not confident enough I will be able to get a good enough performance out of the mbed. I do have a lot of time because I dont have to finish this project for another 2 years so I want to start looking at things now because it will give me enough time to explore different possibilites an give me plenty of research to report on. If you have any advice for me then I would really appreciate. I Intend to produce a 6 Layer PCB so if you know any cheap PCB manufacturers for 6 layer boards I would like to know.

Thanks

P.S please keep the comments coming

A lot of what I am looking at I know is probably old tech as most of it is now acomplished all within 1 device like a GPU, but by working on this I feel it helps me learn how we got from old tech to what we have now because I think it would benefit me to understand how and why the modern chips that we have nowadays do what they, I feel it also gives a better appreciation for how complex these modern devices are.

You can use the knowledge of the VGA controller to create a controller for the PSP display (it has no controller) but this looks like a better combination :-) NXP makes also a few nice ARM CPU's (the 23xx 32xx series) which already have inbuilt controllers (you can hookup that PSP display quite easily) and 256 or even 512k RAM. Only hurdle is they come only in BGA packages... :(

I myself like to tinker with the old stuff too, just to see how it was done in 'the early days'. It is amazing what was done with a few kilobytes of code back then, Todays programs tend to get bloated very fast.

Yes NXP do make some nice controllers and in fact my first investigation since discovering the PSP display on sparkfun was to try and use an NXP LPC2478 which also has an inbuild controller, this device is also available in a 208 pin tqfp package, I cant remember with out looking back through in detail through my files as to why i abandoned this idea, but from what I can remember I wasnt confident I could get the performance required to play a game use a 72MHz processor with regard to being able to process everything and output the video at a nice rate as in 30+ FPS. However I did find that NXP's new devices (LPC1788 I beleive) also have an inbuilt controller and operate at 150MHz.

It seems like the i.MX23 processor is a good one to go for though because its controller is made to display on WQVGA displays and is a very powerful 454MHz processor.

You mentioned 256/512k RAM, how?

By my calculations 480 x 272 x 16 (16 bit colour because although the display can do 24, 16 bit makes things to me considerably easy as its a rounder number in computing terms to best of my knowledge) is equal to just under 2Mbit of RAM and as I would like to implement double buffering to improve image quality that would mean I would need 4Mbit just for the frame buffer memory.

Am I missing something and there is a better way to do it?

That is internal SRAM (iram), you can (need?) connect external DRAM for the display as far as I understand the datasheet:

• 266 MHz, 32-bit ARM9EJ-S core and Vector Floating Point coprocessor (<- this is nice too!)
• Up to 256 kB of internal SRAM and 32 kB I-cache/32 kB D-cache with external memory controller for DDR and SDR SDRAM, SRAM, and Flash
• Optional 10/100 Ethernet MAC and 24-bit LCD controller with support for STN and TFT panels
• USB OTG with full-speed host and device capabilities
• Comprehensive set of serial interfaces and SD memory-card interface

I wish you the best of luck David! I actually made a video game console using the mbed for my senior design project. It's a lot of work but the mbed is surprisingly powerful. We tried to keep it retro and had the game console connect to an old CRT TV. We used just a few components: mbed, AD723 RGB-to-NTSC chip, and a Wii controller.

Here it is ... http://www.mbedgc.com