Outputting to HDMI with a low power MCU?

[lasmori]

Hi there!

I have an 8-bit microcontroller (Zilog ez80) that I am wanting to output video with. "Back in the day" one would grab a video processor (something by Cirrus Logic or etc. I admit, I have no actual experience with *using* these)... but I am at a loss to what one does these days. I am hoping to offload as much of the processing to a video processor of some sort. The ez80 can address up to 16MB, so a frame buffer would be doable.  I would really love if there was a video processor capable of handling 1080p with acceleration for things such as sprites and such, but I assume this may be too much to ask these days.

What would be the modern alternative? I've been looking at various HDMI transmitters, though I am not entirely sure if I could just point them at a frame buffer. I am *hoping* for a low cost solution, though it seems like these HDMI transmitters run $10+ USD.

I've also considered using a FPGA to handle video processing (and then perhaps hooking that up to a HDMI transmitter?). I have to admit though... FPGA is a territory I have never dealt with before. I have seen this: http://hamsterworks.co.nz/mediawiki/index.php/Spartan_6_1080p ... but it seems to do the whole HDMI stack?

The ADV7513 mentions having an MPU if I remember correctly... but I have a feeling this does not provide what I am wanting. They do have an application note for using an FPGA as a video generator.

Some advice would be awesome .

For reference. I am trying to build a "retro" gaming system, hence the Zilog part. The idea is to have a z80 compatible MCU/CPU, but the system would ideally be capable of interfacing with modern peripherals. To this end, I've found a nice little USB host controller designed for interfacing with "low end" MCUs. I am hoping to have something similar for video.

Thanks for the help!

[Richard Crowley]

For $5 you can get a Raspberry Pi "Zero" which not only has HDMI (and analog composite) video output, but also features a complete microcontroller running at 1 GHz on which you could run a Z80 emulation, but you will probably have to slow it down to "retro" speeds.

[lasmori]

For $5 you can get a Raspberry Pi "Zero" which not only has HDMI (and analog composite) video output, but also features a complete microcontroller running at 1 GHz on which you could run a Z80 emulation, but you will probably have to slow it down to "retro" speeds.

I like the idea, but I'd prefer to build the thing myself rather than using something like the Raspberry Pi. Beside, emulation just doesn't inspire me the same way . Part of the reason for doing this is also just to see if it's possible.

I already have an ez80 board built and talking over rs232.  Just trying to figure out what to do about video.

[Richard Crowley]

Of course HDMI hadn't even been thought of back in the days of the Z80 systems.  So you have rather thrown yourself a curve by insisting on vintage processing, but 21st century video signal creation.

There are plenty of resources for creating old-school (authentic vintage) composite or VGA SD video signals, probably even raw right out of the Z80.  But you need 10x to 100x more horsepower to create a high-speed digital video stream like HDMI.

[0xdeadbeef]

Well, you could output a RGB signal and let an HDMI transmitter do the work.
Then again, I guess maintaining a somewhat usable resolution with an 8bit controller could be tricky. You'll need quite some memory for the frame buffer. And also maintaining an acceptable framerate could get difficult with just that Z80 CPU.
Some years ago I did a VGA output on an LPC1768 (cortex M3) which was mainly based on DMA transfers. Timing was not so much of an issue, but this was a 100Mhz 32bit controller.
Then again, due to lack of RAM, I could only use 32kb as frame buffer resulting in a 160*200 resolution even though the VGA resolution was 640x400 (doubled lines and 4x pixel width).
So probably you'd need one additional CPU acting as video controller.

[lasmori]

Well, you could output a RGB signal and let an HDMI transmitter do the work. .... So probably you'd need one additional CPU acting as video controller.

Maybe I worded things badly? I am entirely fine with the "graphics processor" approach. In fact, I assumed I'd be doing as much. The problem is that... there doesn't seem to be a modern equivalent to say... the Yamaha V9958. I was hoping someone knew of a dedicated "graphics processor" that's focused on 2d... and actually purchasable. . I am fine with the idea of using another cpu as the video controller (combined with the hdmi transmitter?).

I also don't need 1080p. 960x540 or even 640x360 would be fine. In regards to memory... the ez80 (note the 'e') can run up to 50MHz and supports up to 16MB ram.

If I were to generate an RGB signal with another CPU, what would be the cost effective solution for this?

Thanks for the reply!

[lasmori]

probably even raw right out of the Z80.  But you need 10x to 100x more horsepower to create a high-speed digital video stream like HDMI.

I wasn't asking to make the ez80 generate the video... but rather, I was looking for a modern "2d video accelerator". I am fine with another CPU doing the grunt work. See my reply to 0xdeadbeef

[Richard Crowley]

There are several video-generating solutions for the Arduino crowd. 
Suggest that would be the most likely place to find something.
Of course, you will have to write your own driver to talk to the video-generating module.

[miguelvp]

This might be of help.

http://www.analog.com/library/analogDialogue/archives/47-02/HDMI_VGA.html

It uses an AD9983A as an 8 bit display interface feeding that to the HDMI-TX (ADV7513)
http://www.analog.com/en/products/audio-video/analoghdmidvi-interfaces/ad9983a.html

But this needs the RGB analog input plush the HSync/VSync, so you might need a 3rd chip an ADV7125 330MHz Triple 8-Bit High Speed Video DAC.
http://www.analog.com/en/audiovideo-products/video-encoders/adv7125/products/product.html

But making the board might cost you more than using something that already outputs HDMI, using that Raspberry Pi zero ($5 if you can get your hands on one that is) and program it to be used as a plain frame buffer with probably even audio might be a better way.

Or the FPGA route you can find a board with HDMI out like this one that uses the ADV7513 HDMI-TX chip.
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=830&PartNo=1

But with the caveat that it doesn't have the audio hooked in, also I believe the samples use the NIOS-II softcore and I don't think they have a bare metal sample driving the ADV7513.

I did write a review a while back about that dev kit, but it's not cheap at $179 + shipping but for that it has, not expensive at all.
https://www.eevblog.com/forum/microcontrollers/terasic-cyclone-v-gx-starter-kit-(c5g)-review/msg402667/#msg402667

But if you stick to VGA output then there are more choices like a PSoC5LP devkit driving a simple R2R VGA output module.
Links to the boards in this post: (Edit: fixed link to right one)
https://www.eevblog.com/forum/projects/make-use-of-an-old-cga-monitor/msg696341/#msg696341
Them working here:
https://www.eevblog.com/forum/projects/make-use-of-an-old-cga-monitor/msg697201/#msg697201

But you will be limited to a small framebuffer unless you add some external memory.

You can also get a DE0-Nano and this board:
http://www.wayengineer.com/digiasic-fpga-adv7125adv7123-vga-board-p-160.html
And adding some kind of frame buffer and some communication to your z80 to address that frame buffer.

But I guess it all depends what video content you have in mind, if it's just a terminal with just text that doesn't require many colors, the PSoC5LP with the R2R DAC VGA module might be the cheapest and easier to do, but by easy you need to learn how to program the PSoC digital components, then you can add some ram to it and then use the VGA output to convert it to HDMI.

The simplest would be an lcd with frame buffer and a controller built in.

And again, none of the above deal with the HDMI audio as far as I know.

Edit: fixed link to sources for PSoC5LP and R2R DAC VGA module above (had a duplicate link to the fpga dev kit)

[Psi]

you could probably do limited hdmi output with a STM32F7. It's never going to do 1080p but you could probably get the lowest resolutions working. The ones that use a 25mhz pixel clock.

Not all monitors support the sub-720p resolutions though.

[lasmori]

... *tons of links*...

Thanks for all of the links miguelvp!

I am trying to avoid using a dev kit / premade board.  But this is certainly a lot for me to look over!

Framebuffer wise, I have up to 16MB to work with in my current configuration.

[lasmori]

you could probably do limited hdmi output with a STM32F7. It's never going to do 1080p but you could probably get the lowest resolutions working. The ones that use a 25mhz pixel clock.

Not all monitors support the sub-720p resolutions though.

I am hoping that if I use a resolution that is a division of 2 or 3 of 1080p that I can work out some sort of simple pixel doubling. Yet more stuff to be unsure about haha

[miguelvp]

Framebuffer wise, I have up to 16MB to work with in my current configuration.

The problem is getting the display driver to read that frame buffer with some type of DMA to the video controller, so you might want the frame buffer in the display side unless you can get some double ported memory that the controller could access directly. Also you might need to have two frame buffers and write to one while the other one is being displayed.

[Psi]

you could probably do limited hdmi output with a STM32F7. It's never going to do 1080p but you could probably get the lowest resolutions working. The ones that use a 25mhz pixel clock.

Not all monitors support the sub-720p resolutions though.

I am hoping that if I use a resolution that is a division of 2 or 3 of 1080p that I can work out some sort of simple pixel doubling. Yet more stuff to be unsure about haha

1080p isnt going to work without a hardware video engine intended for 1080p hdmi output.
The F7 runs at like 200mhz, even when dealing with the lowest resolutions and a 25mhz pixel clock you still only get
8 clock cycles per pixel. Using DMA will be a requirement. You need to assemble the frame/line in memory in time for DMA to copy it out.

[Lukas]

you could probably do limited hdmi output with a STM32F7. It's never going to do 1080p but you could probably get the lowest resolutions working. The ones that use a 25mhz pixel clock.

Not all monitors support the sub-720p resolutions though.

Maybe you could tweak the timing of the built-in LCD controller (LTDC) to suit the requirements of an HDMI transmitter. Then, the CPU has to do nothing but fill the framebuffer.

[T3sl4co1l]

I know you can get graphics controllers, usually something like SPI on the MCU side, parallel bus (16 or 24 bit RGB) for the LCD side.  Maybe there's one floating around that's 8 or 16 bit parallel to MCU (e.g. I80 interface), and that's different kinds of outputs (VGA/DVI/HDMI)?

You may have to dig through poorly documented/supported/NDA'd chips, though... graphics controllers tend to do that, sadly.  And with equally poorly accessible interfaces.

Tim

[bitslice]

Have a look here

http://www.4dsystems.com.au/product/PICASO/
http://www.4dsystems.com.au/product/uVGA_III/

they do other chips too


btw, are you using the Aclaim eZ80 dev kit?

[Wilksey]

Have you looked at the Gameduino / Gameduino 2?

[bson]

Just pick up a DIP40 6845 on eBay and stick to the vintage theme.  Many monitors and TVs still have a VGA or an analog DVI port.

Maybe cheat on the VRAM for it and get something fully async dual-port and blazingly fast (by 1980 standards) and easy to interface.

[hamster_nz]

Hi Lasmori,

The lowest official supported HDMI mode is 640x480 with a pixel rate is 25.125MHz, giving a bit rate of 251.25Mb/s on each of three TMDS data channels, You would be hard pushed to do anything but character mapped text or bit-mapped mono from the system's RAM (and it would need 3MB/s memory bandwidth for 640x480@60Hz).

If you went down the FPGA route you would most probably be better off implementing the entire video controller (including frame buffer) in the FPGA, treating it as though it is a separate card within the system  (e.g. 12 bit address bus, 8-bit data bus, a few bits of control bus).

I've implemented DVI-D and HDMI a few times in a few different ways on an FPGA, and the FPGA side is pretty trivial as long as your FPGA can directly drive TMDS pairs directly...

[lasmori]

http://www.4dsystems.com.au/product/PICASO/
http://www.4dsystems.com.au/product/uVGA_III/

Nice!!! The PICASO looks like a really interesting option.

btw, are you using the Aclaim eZ80 dev kit?

Nope. I've built my own board with the eZ80, crystals, rs232, etc.

[lasmori]

If you went down the FPGA route you would most probably be better off implementing the entire video controller (including frame buffer) in the FPGA, treating it as though it is a separate card within the system  (e.g. 12 bit address bus, 8-bit data bus, a few bits of control bus).

I've implemented DVI-D and HDMI a few times in a few different ways on an FPGA, and the FPGA side is pretty trivial as long as your FPGA can directly drive TMDS pairs directly...

I'll admit. FPGAs, Verilog, and etc scare me a bit. Having said that, I am now very seriously grabbing an FPGA dev kit to learn my way around them.

I am thinking about picking up the DE0-Nano. I can get the academic discount, it has the usb "blaster" built in, and packs a Cyclone IV. Seems like a solid place to start.

[lasmori]

Just pick up a DIP40 6845 on eBay and stick to the vintage theme.  Many monitors and TVs still have a VGA or an analog DVI port.

Maybe cheat on the VRAM for it and get something fully async dual-port and blazingly fast (by 1980 standards) and easy to interface.

I've considered doing this. The only problem is that one would would need the equipment to hook it up to a modern display.

A compromise might be to use a LCD panel rather than being able to hook it up to a display or tv. You can get them with composite inputs. We will see!

I know it sounds a bit crazy... but I still love the idea of having a "retro" system actually *work* on modern peripherals. It's what everyone has to work with these days.

Then again, if I did push the retro thing... LCD panel supporting composite, serial port controllers (There are still *new* genesis compatible controllers being made)... might not be a crazy idea. We will see!

This is obviously a project for personal use... but a girl is allowed to geek out a bit right?

[lasmori]

I just wanted to mention... thank all of you very much for the replies! I was feeling a little intimidated about posting, but I'm really glad to have done so!

[lasmori]

Have you looked at the Gameduino / Gameduino 2?

Interesting! It sounds like they are using a fpga for video processing. I'll have to investigate Thanks!

[obiwanjacobi]

I know it sounds a bit crazy... but I still love the idea of having a "retro" system actually *work* on modern peripherals. It's what everyone has to work with these days.

Yes, me too!

I am planning on building a Z80 (note the absence of the 'e') based board with an FPGA and a lot of SRAM (details not decided yet).
I just started to delve into FPGA recently and am looking forward to actually working with them (ebay can be slow!).

I have to do with a 16 bit address bus so no huge video resolutions. I'm thinking ot 640x480 to start with.

Excellent fun these projects 

[lasmori]

Yes, me too!

I am planning on building a Z80 (note the absence of the 'e') based board with an FPGA and a lot of SRAM (details not decided yet).

. I've considered using the Z80... but the ez80 does have a few things that interest me. 24 bit address bus, I2C, and SPI being the big ones. I was imagining the system having a couple "cartridge slots" using PCI Express 1x connectors. Would maybe run I2C, SPI and some GPIO lines to the cards.

[lasmori]

I think that I *may* have a handle on what I'd like to do.

The source resolution would be 640x360 with 16bit (5:6:5) color. The target resolution would be 1920x1080p

The circuit would have the ez80, two SRAM buffers of 4mbit each, A FPGA capable of running at 148.5 MHz such as the Lattice MachXO2, and a HDMI transmitter.

The ez80 would fill up it's video memory, then synchronize with the FPGA to perform a page flip. The FPGA would pull in a line (640x16, or 10kb) of the buffer and start iterating with each clock tick. The FPGA would run each pixel three times. It would then run the same line 3 times. (Giving us our resolution scaling). Each pixel/line the hsync/vsync lines would get pulsed. Repeat until the frame is done. I think the FPGA would also have to convert the color data from 16 bit (5:6:5 bits per color) to 8 bits per color unless the transmitter can handle the conversion itself.

Does this seem like the right idea? I know that a FPGA could be programmed to do the whole HDMI stack itself... but this feels like an easier solution.

[miguelvp]

640x360 16bit requires a 450KB frame buffer, if you want to be able to update the buffer while it's being displayed that means you need 900KB and display one buffer while the CPU is filling a 2nd buffer.

If you want full pixel control you will need to transfer 450KB (one buffer) to the memory hopefully via DMA at 30 fps, you would need to be able to achieve transfer rates of 6750 kilo (6912000) words per second, that is if your DMA handles full word transfers.

If instead you just wanted a text/sprite based display then the requirements might be more achievable.

Or maybe you can update via some kind of interface that doesn't need to update at the full 30Hz. I guess you need to tell us what type of output you are planning to display as in individual pixel control or sprites with a couple of colors (foreground, background and maybe a blink bit)

[obiwanjacobi]

To my mind it always makes sense to use dedicated, specialized parts for a specific job. Unless they're really expensive and can be replicated in the FPGA, it allows you to choose a smaller FPGA - if that is relevant. Else it just saves on development costs/time.

I personally don't like the asymmetrical color bits (5:6:5) - I would make that 5:5:5 and leave on bit for bright (intensity) or something. I don't see how you can do flash because you need two colors for that...?

[lasmori]

640x360 16bit requires a 450KB frame buffer, if you want to be able to update the buffer while it's being displayed that means you need 900KB and display one buffer while the CPU is filling a 2nd buffer.

Covered that. "two SRAM buffers of 4mbit each"

If you want full pixel control you will need to transfer 450KB (one buffer) to the memory hopefully via DMA at 30 fps, you would need to be able to achieve transfer rates of 6750 kilo (6912000) words per second, that is if your DMA handles full word transfers.

If instead you just wanted a text/sprite based display then the requirements might be more achievable.

Or maybe you can update via some kind of interface that doesn't need to update at the full 30Hz. I guess you need to tell us what type of output you are planning to display as in individual pixel control or sprites with a couple of colors (foreground, background and maybe a blink bit)

The "source" video would ideally be 640x360x16.

While I would like to have the ability to do general blitting... sprites and such are one of my goals.

[lasmori]

To my mind it always makes sense to use dedicated, specialized parts for a specific job. Unless they're really expensive and can be replicated in the FPGA, it allows you to choose a smaller FPGA - if that is relevant. Else it just saves on development costs/time.

Yeah, that's how I was feeling.

I personally don't like the asymmetrical color bits (5:6:5) - I would make that 5:5:5 and leave on bit for bright (intensity) or something. I don't see how you can do flash because you need two colors for that...?

5:6:5 is pretty traditional for early 16 bit "High Color". Green is generally chosen for the extra bit as our eyes are the most sensitive to it. 5:5:5 (also very common) often used the last bit to for the "alpha channel".

[obiwanjacobi]

Yeah I saw the alpha channel variant as well but I have no idea how to implement that in hardware... 

[lasmori]

Yeah I saw the alpha channel variant as well but I have no idea how to implement that in hardware... 

Imagine you had two sprites overlapping each other. If one were marked with the alpha bit... you could add the colors of overlapping pixels together rather than having the one drawn last replace the former. That's my best guess... but I honestly have no experience with it. .

[obiwanjacobi]

So the one bit would trigger some level of hardwired blend-percentage.

[netdudeuk]

My 6502 and Z80 systems both use a Parallax Propeller via parallel interfaces, giving colour VGA graphics and text.  They're both works in progress but they work perfectly OK as far as I've got them.  The only downside is that they don't have shared memory so I wouldn't be able to quickly bang images, etc, to the local RAM and see something on the screen.

[lasmori]

My 6502 and Z80 systems both use a Parallax Propeller via parallel interfaces, giving colour VGA graphics and text.  They're both works in progress but they work perfectly OK as far as I've got them.  The only downside is that they don't have shared memory so I wouldn't be able to quickly bang images, etc, to the local RAM and see something on the screen.

I love the Propeller. I was thinking of working one into my design... just because.

[Cliff Matthews]

For $5 you can get a Raspberry Pi "Zero" which not only has HDMI (and analog composite) video output, but also features a complete microcontroller running at 1 GHz on which you could run a Z80 emulation, but you will probably have to slow it down to "retro" speeds.

Hmm.. It would be nice to flash one of these "zero's" to quick-boot a tiny mouse-less Linux doing nothing more than HD44780 to HDMI emulation. Now that could display neat retro games (and be a great Kick-starter too). Teachers worldwide would have giant Arduino classroom LCD's!

[KE5FX]

Have a look here

http://www.4dsystems.com.au/product/PICASO/
http://www.4dsystems.com.au/product/uVGA_III/

they do other chips too


btw, are you using the Aclaim eZ80 dev kit?

Neat chip, but: is it just me, or do they never get around to specifying what resolutions they support?