-
Interfacing SDRAM to an FPGA is not particularly difficult, there are lots of controllers out there already implemented that you can use in your own projects.
-
Well you can still get a few MB of SRAM memory in a single chip at a reasonable price. Yes SDRAM is available in larger sizes for cheaper, but for a computer out of the Z80 era even having 512KB of video memory is a LOT. For example the SNES produces its impressive 2D graphics using 64KB of video memory. There are many reasons why so little video memory is used. The main one is that RAM was very expensive at the time, but even if they had megabyte sizes video memory it wouldn't really be usable at all because the CPU was too slow to draw to it fast enough to produce smooth animations. And even if you had a special GPU that can draw faster it would still be too slow because RAM back then had limited bandwidth. You could simply not update a full screen of 24bit pixels fast enough in normal consumer RAM memory, no matter what supercomputer was doing the drawing.
The way they have gotten around the problem of RAM size and RAM speed is to have the GPU generate the image on the fly as it is sent out to the screen. The graphics are are drawn using tilemaps of small images that are assembled together on the fly and colored in using palletes. This allows the graphics to take up much less space in RAM and does not waste memory bandwidth updating a full raw framebuffer in RAM. The titlemap takes less space in ram while the CPU can update it by simply changing a single byte map id, saving bandwith to the CPU and memory space in the ROM for storing game levels. All of this lets the slow underpowered CPU push out a buttery smooth 60fps image even when lots of things are happening on screen.
As for reusing ISA cards. You don't have to implement extra features you don't need. If you have no DMA controller then you simply leave the DMA pins unused. Dropping all of the fancy stuff makes the ISA bus look the same as a SRAM chip so its the simplest bus possible, and since its a standard that does exactly what you want its better to use it than to come up something new and proprietary that does the exact same thing in the end.
And yes SDRAM or even DDR3 can be interfaced to a FPGA with premade modules, but for a total beginner id suggest staying away from that for now and stick to simple things. Not only is it extra complexity in the IDE tools to set everythyng up, but also SDRAM is a pipelines architecture and so only works fast when you do operations in blocks rather than individual bytes, this adds extra complexity to the GPU inside that has to be a bit more mindful of the future and so the logic inside also gets extra complexity. You don't want to drown in a pit of complexity from the get go and loose interest in the project because of it. Once something works and you get that sweet rush of satisfaction you can start adding extra things to it and build up the more complex features so that the project stays fun. -
Quote
Question is -the topic of this thread- is it worth it to spend the effort if I cannot -realistically- reuse old PC ISA cards?
Even I do understand your temptation to play with Z80 (I did 30y back) the planned effort is wasting your valuable time. I have here a pile of such chips from 80ties I collected over time and I know today I will never ever wire them, they will just gather the dust..
(I guess not)
As the other posters have indicated you have to go the FPGA route. Learn the verilog and the tools. FPGAs and the tools are getting much cheaper so you may afford even bigger FPGA capacities.
And the others may also join your efforts when you create something "enough retro".
Some time back I put a complete PDP-8 into a $5 Spartan6 XL9 (based on opencores sources), running the OS and the original apps off an SDcard (formatted as 4 doublesided RK05) @75MHz clock, and it was a big fun (and a valuable learning exercise too)..
-
I wire up old chips, it's fun. I use FPGAs too, sometimes I combine both.
A significant part of the way the SNES made such impressive graphics with so little RAM is that the tiles were stored in ROM on the cartridge. A system that has to load data off of a disk needs to have a lot more RAM. 512k is still a lot for that era though, a Z80 can directly address only 128kB of space. -
The idea of my accelerator is that there is no video RAM, at least not to the Z80 CPU. It just communicates with the accelerator at a higher level protocol. It is the STM32/FPGA that needs to access the large (SD/S)RAM during display cycles. That RAM stores the bitmaps, tiles, fonts, maps etc. Like said before, choose the FPGA and you have parallelism, better perf but added complexity and a steeper learning curve. Choose the STM32 and you get the SDRAM interface for free and I can program out more complex graphics routines in code instead of logic (I am a dev). And -a small point-, the STM32 is 5V capable, FPGA are not. I have to level shift the Z80 bus interface (minor issue).
Interfacing SDRAM to an FPGA is not particularly difficult, there are lots of controllers out there already implemented that you can use in your own projects.
So I understand. But if you know a thing it never is 'particularly difficult'. If you never have done anything comparable then it looks like a big mountain of problems in the mist. I don't even know how to include those ready made components into an FPGA project (Quartus), so... that is where I am at - super noob level (on FPGA's - on code I can hold my ground, although I am new to STM32 too - only did a few proof of concept projects). -
There's a *LONG* history of graphics coprocessor cards, e.g. on the PC, TMS340 based TIGA cards, or the IBM 8514/A card, and its ISA bus clones. However its a *LOT* of work and a fairly deep rabbit hole to develop one for the Z80 from scratch, especially 'bare metal' on a processor you aren't particularly familiar with. IMHO your efforts would be far better spent developing a hosted Z80 system, similar in concept to the BBC micro Tube second processor interface with the Acorn or Torch Z80 units, or the Microsoft Z80 SoftCard for the Apple II. Of course it would be fairly crazy to build one now hosted on a legacy system, but small Linux SBCs with HDMI and USB are cheap and readily available, and using one as the graphics and I/O processor for your Z80 is really not so much of a stretch if you are already considering a STM32 based coprocessor.
Personally I'd probably go for a Raspberry Pi - just because of the popularity, stability and OS support, with a FPGA or a CPLD + a bunch of tristateable latches for the bus interface (or possibly four 74HCT40105 FIFOs to support byte wide queued inter-processor communications). Do initial development under Linux, on a full-featured Pi then decide if you are a rabid enough purist to write a Pi side 'bare metal version' to run on a Pi Zero fitted as a daughter board to your Z80 system. -
There's a *LONG* history of graphics coprocessor cards, e.g. on the PC, TMS340 based TIGA cards, or the IBM 8514/A card, and its ISA bus clones. However its a *LOT* of work and a fairly deep rabbit hole to develop one for the Z80 from scratch, especially 'bare metal' on a processor you aren't particularly familiar with. IMHO your efforts would be far better spent developing a hosted Z80 system, similar in concept to the BBC micro Tube second processor interface with the Acorn or Torch Z80 units, or the Microsoft Z80 SoftCard for the Apple II. Of course it would be fairly crazy to build one now hosted on a legacy system, but small Linux SBCs with HDMI and USB are cheap and readily available, and using one as the graphics and I/O processor for your Z80 is really not so much of a stretch if you are already considering a STM32 based coprocessor.
My Z80 'system' is already running. Okay, it's little more than CPU+RAM+SerialIO but it works and I don't plan to change it (very much). I am just looking for an easy way to expand its IO capabilities and (mis)using ISA "seemed like a good idea at the time". I am not familiar with the examples you give...? I guess the Z80 softcard was there to be able to run CPM?Personally I'd probably go for a Raspberry Pi - just because of the popularity, stability and OS support, with a FPGA or a CPLD + a bunch of tristateable latches for the bus interface (or possibly four 74HCT40105 FIFOs to support byte wide queued inter-processor communications). Do initial development under Linux, on a full-featured Pi then decide if you are a rabid enough purist to write a Pi side 'bare metal version' to run on a Pi Zero fitted as a daughter board to your Z80 system.
Yes, I have seen PI's being used for HMDI video, but I am also a Linux noob and wouldn't know where to start. If I had a clue how to use a PI (I have an old 1B laying around) as a video device, I would do it... Bare metal on the PI's SOC would be a bridge too far for me
-
There is a good reason why video RAM is almost always also memory mapped to the CPU
The fastest possible interface for a CPU is writing to memory locations. This gives the CPU flexibility to move data in and out of video memory in any way it likes. It doesn't have to ask the GPU to do something for it by setting a handful of registers. Rather than writing a bunch of registers to tell the GPU to change a tilemap ID it could simply write a single byte to the location where that tilemap is stored. It gets the job done with less memory operations and it allows you to DMA data between main and video memory. This means the CPU spends less time interacting with the GPU, it just writes what it wants to show on the screen to RAM and gets on with other tasks. Keep in mind that the CPU rarely writes raw pixels to the frame buffer, instead its usually just updating tilemaps, palletes or strings. And the video memory rarely contains a framebuffer at all, it usually just contains some graphics assets in the forms of small icons and sprites and the instructions on how to put them together. The icons and sprites are loaded in once and then just the instructions on where to put them are updated. Then the GPU follows those instructions in an endless loop, generating the video output at 50 or 60 fps live.
There are some rare instanced in game consoles where the CPU does directly push pixels to the framebuffer. For example the Nintendo 64 on a few rare games uses direct CPU access to video memory in order to create some graphical effects. This is because the early 3D GPUs such as the one used in the N64 operate on a fairly non flexible 3D rendering pipeline and are so unable to do any special programmable functionality. The same was the case for early 3D graphics cards in PCs before unified programmable shaders became a thing.
As for 5V there are some older FPGAs/CPLDs that are 5V compatible, but level shifting such a small memory bus is not that terribly hard. As for a raspberry pi, you most definitely don't want to run bare metal, its way too complex and undocumented. But you can still just let it boot into a linux console and autorun your C++ app on boot. If you ever wrote software for windows then linux on ARM is not that much different. From there you can use OpenGL to get full hardware accelerated graphics with 3D support and programmable sharers. Very powerful but if you ask me sticking a modern day mobile GPU onto a Z80 doesn't make for a very satisfying retro experience because its suddenly capable of the 3D graphics equivalent to a typical early Windows XP machine. -
The fastest possible interface for a CPU is writing to memory locations. This gives the CPU flexibility to move data in and out of video memory in any way it likes. It doesn't have to ask the GPU to do something for it by setting a handful of registers. Rather than writing a bunch of registers to tell the GPU to change a tilemap ID it could simply write a single byte to the location where that tilemap is stored. It gets the job done with less memory operations and it allows you to DMA data between main and video memory. This means the CPU spends less time interacting with the GPU, it just writes what it wants to show on the screen to RAM and gets on with other tasks. Keep in mind that the CPU rarely writes raw pixels to the frame buffer, instead its usually just updating tilemaps, palletes or strings. And the video memory rarely contains a framebuffer at all, it usually just contains some graphics assets in the forms of small icons and sprites and the instructions on how to put them together. The icons and sprites are loaded in once and then just the instructions on where to put them are updated. Then the GPU follows those instructions in an endless loop, generating the video output at 50 or 60 fps live.
Okay, that is what I would call a higher level interface. The fact that the Z80 'thinks' its writing to RAM can be implemented in several ways. My point was that I was not planning on the Z80 moving the graphic bits to the video RAM - where the video controller would simply display them.
Depending on whether a 180MHz STM32F4 is fast enough for a 20MHz Z80 to simulate some virtual RAM, I may need to use real RAM - because I guess the program (Z80) may at one point want to read back what the display state is. There are dual ported RAMs (with on one side a serial interface)... Haven't decided on those details yet.As for 5V there are some older FPGAs/CPLDs that are 5V compatible, but level shifting such a small memory bus is not that terribly hard. As for a raspberry pi, you most definitely don't want to run bare metal, its way too complex and undocumented. But you can still just let it boot into a linux console and autorun your C++ app on boot. If you ever wrote software for windows then linux on ARM is not that much different. From there you can use OpenGL to get full hardware accelerated graphics with 3D support and programmable sharers. Very powerful but if you ask me sticking a modern day mobile GPU onto a Z80 doesn't make for a very satisfying retro experience because its suddenly capable of the 3D graphics equivalent to a typical early Windows XP machine.
Nah, I don't think level shifting would be a problem. 5V FPGAs are a pain to find and relatively expensive.
Auto booting into a custom app sounds like a nice solution (C/C++ is no problem), but I'd have to learn the API to work with the GPIO header pins (the interface to the Z80 system) - assuming there is one. Not sure if OpenGL is the only option. Did work with it once on windows in the late 90's and was pretty overwhelmed. I am not targeting a full 3D Gfx engine here, more the platform tile mapped scrolling kinda graphics.
But the interface with the Z80 would be IO based, unless I let the PI montor the Z80 bus and intercept certain writes (and read) to a specific Memory segment. It would have to decode my 20-bit address bus in that case, which would mean I need 30+ IO pins on the PI...
Could work, though...
[thinking...] -
Well thing is that software emulating a parallel memory bus is hard work. Even a slow 20MHz bus is actually pretty fast in terms of latency. Sure MCUs have interrupts but a modern ARM take about 10 to 20 or even more cycles to enter an interrupt routine because it has to context switch. So even if it takes 10 cycles and you have a 180 MHz CPU you can only enter an interrupt at a rate of 18MHz, but this doesn't include the time taken to also exit it so that the interrupt can be called again, halving it again to 9MHz. And this is without any code inside the routine, as soon as you add actual code that does something it will take even longer to complete the interrupt. So this makes it very difficult for a MCU to pretend as being SRAM on the bus. What is easier to do is to talk to the MCU over something like a parallel port since in that case the Z80 can talk to it however slowly it wants. But you could implement something in between by having a dual port FIFO chip for write operations to the MCU. That way the Z80 can barf data at it at full speed and get back to doing other things while the MCU works trough it as its own pace. So then only read operations would be slow.
All of this means you also can't really use a Raspberry Pi GPIO bus to directly connect to a Z80 bus. Sure the CPU might run at 1.2 GHz but its still not responsive enough because GPIO is on a slower peripheral bus, interrupt latency is really long and running linux means the CPU is constantly interrupted by the OS scheduler so response times are all over the place. As for getting OpenGL working there is a nice simple library for it called RayLib (https://www.raylib.com/) and you don't have to use it for any 3D, works for 2D just as well but all of that 2D is done in hardware by the GPU so its very fast.
On the other hand a FPGA could handle running a Z80 bus at 200 MHz just fine while simultaneously generating 4K video output and emulating a FM synth with 32 voices. Actually mplementing a simple GPU in a FPGA is not all that hard. Tilemaing, sprites and ROM text are easy, because its just a matter of looking up the correct pixels in memory. Things get more complicated if you want fancy features like the SNES Mode 7 effects and similar things from the 16bit era. These simple GPUs also usually have no features for drawing lines or shapes (They tend to get some of those abilities once they are for 3D ).
In general FPGAs are very useful with retro computers because they can interface to pretty much anything, allowing you to easily implement custom addin cards, coprocessors, accelerators... etc by simply loading new firmware into a FPGA chip. Makes it easy to emulate the custom hardware on motherboards from home computers like a C64, AppleII etc. heck even the entire Z80 could run inside the FPGA, and run faster than your real chip even, but emulating the entire system inside a FPGA doesn't really have as much of a retro charm to it. -
This may be of some interest:
http://tasvideos.org/5384S.html
Tl;dr is, the guy used a menu corruption glitch to get ACE on the GBC, effectively making the controller port a parallel data port to bootload code. This is not nearly enough bandwidth to stream video controller register data through the CPU (which would be the easiest way to play e.g. graphics from another game on the same console, simply playing back a log of register data obtained from an emulator). Instead part of the display routines were recreated, and display state changes were streamed. Essentially, this constitutes a very special purpose and high level data compression format.
Since you have so much horsepower in the STM, you might consider crafting a display command protocol that offers various powerful, rich and customizable primitives, and transmit display state change information instead. This would be built very much like modern GUI programs, where you write the main backend code which runs in one thread (which would be on the Z80), while the OS handles the graphics objects and rendering and interaction. (You'd still run interaction through the Z80 I suppose.)
Tim -
Dang that does look impressive.
I have seen quite a few arbitrary code execution exploits but i never seen video streamed to the screen using controller input.
But yeah the best fitting type of graphics acceleration functionality depends on what you want to run on it. Things like 2D games all make heavy use of titlesets and sprites because often the entire screen is being updated anyway and game levels are large so they can't be stored as one bitmap. For something like a UI you mostly want everything as a big bitmap, but all you really need is decent 2D bitblit to move them around, since you typically just need to plonk down premade image segments to assemble a gui along with perhaps filling in rectangular areas. Typicaly graphics chips take one of the other approach, but i don't see why you couldn't have both overlapped. -
Well thing is that software emulating a parallel memory bus is hard work. Even a slow 20MHz bus is actually pretty fast in terms of latency. Sure MCUs have interrupts but a modern ARM take about 10 to 20 or even more cycles to enter an interrupt routine because it has to context switch. So even if it takes 10 cycles and you have a 180 MHz CPU you can only enter an interrupt at a rate of 18MHz, but this doesn't include the time taken to also exit it so that the interrupt can be called again, halving it again to 9MHz. And this is without any code inside the routine, as soon as you add actual code that does something it will take even longer to complete the interrupt. So this makes it very difficult for a MCU to pretend as being SRAM on the bus. What is easier to do is to talk to the MCU over something like a parallel port since in that case the Z80 can talk to it however slowly it wants. But you could implement something in between by having a dual port FIFO chip for write operations to the MCU. That way the Z80 can barf data at it at full speed and get back to doing other things while the MCU works trough it as its own pace. So then only read operations would be slow.
Hmmm, sounds plausible...
All of this means you also can't really use a Raspberry Pi GPIO bus to directly connect to a Z80 bus. Sure the CPU might run at 1.2 GHz but its still not responsive enough because GPIO is on a slower peripheral bus, interrupt latency is really long and running linux means the CPU is constantly interrupted by the OS scheduler so response times are all over the place. As for getting OpenGL working there is a nice simple library for it called RayLib (https://www.raylib.com/) and you don't have to use it for any 3D, works for 2D just as well but all of that 2D is done in hardware by the GPU so its very fast.
On the other hand a Z80 memory read/write cycle takes 4 clock cycles (IO reads/writes take 5 cycles). So there would be 'only' 5MHz worth of reads/writes... Also the program would probably only write to 'tilemap' RAM every so often. I do not expect a mem-copy type of operation. More some sort of game logic that decides its time to move the 'sprite' one position to the left. So the frequency of actual writes is even lower.
I have no experience (to speak of) with the STM32F4 (I was planning to use) so I didn't consider interrupt setup times. Thanks for bringing this to my attention.
I also have to consider my memory management page size (which is 4k). It stands to reason that these video-related memory parts are mapped and aligned on those boundaries. I can put any 4k memory page from a 1MB pool anywhere in the 64k Z80 address space (except page 0 - which is fixed).On the other hand a FPGA could handle running a Z80 bus at 200 MHz just fine while simultaneously generating 4K video output and emulating a FM synth with 32 voices. Actually mplementing a simple GPU in a FPGA is not all that hard. Tilemaing, sprites and ROM text are easy, because its just a matter of looking up the correct pixels in memory. Things get more complicated if you want fancy features like the SNES Mode 7 effects and similar things from the 16bit era. These simple GPUs also usually have no features for drawing lines or shapes (They tend to get some of those abilities once they are for 3D ).
Yes, the FPGA sound better and better all the time. However I am still very wary of the learning curve involved. Especially with the more advanced functionality.This may be of some interest:
Thanks, will take a closer look at this.
http://tasvideos.org/5384S.html
Tl;dr is, the guy used a menu corruption glitch to get ACE on the GBC, effectively making the controller port a parallel data port to bootload code. This is not nearly enough bandwidth to stream video controller register data through the CPU (which would be the easiest way to play e.g. graphics from another game on the same console, simply playing back a log of register data obtained from an emulator). Instead part of the display routines were recreated, and display state changes were streamed. Essentially, this constitutes a very special purpose and high level data compression format.Since you have so much horsepower in the STM, you might consider crafting a display command protocol that offers various powerful, rich and customizable primitives, and transmit display state change information instead. This would be built very much like modern GUI programs, where you write the main backend code which runs in one thread (which would be on the Z80), while the OS handles the graphics objects and rendering and interaction. (You'd still run interaction through the Z80 I suppose.)
Yep, that was the idea. Exactly how to protocol will look, I don't know yet. I guess I will try a few things to see what works best (state-change-based, operations, share memory, etc) -
There is another example: fasten the ISA card to Z80 using
crowbar and some kind of mothersome 74 chips as glue logic.
P.S. And another (but without ISA) example: how to use Chinese 4.3" LCD as display for your Radio-86RK/ZX Spectrum clone. -
The video card seems like a very easy card to interface with. It would be interesting to know where he got the information of which registers to use etc. - a quick search did not reveal anything obvious.
I suspect that VGA card is an order of magnitude more complex, though...
I have also looked at LCD interfaces on STM32's. What I gather from them is that they are meant to drive LCD directly. I am looking for VGA -and perhaps scart. (I don't know anything about HDMI/DisplayPort and want to keep it simple). The SMT32F4 I have, does not have an LCD interface. -
Yes the LCD interface on a STM32 is meant for driving a color LCD directly as the name would suggest.
But the thing is that the parallel RGB interface evolved out of existing video standards like VGA. Because of that it has a Vsync and Hsync signal that works the same as the sync signals in VGA. But it makes no sense to feed a analog video signal into a digital display like a LCD, so the analog R G B signals are simply sent in the digital form as a value on a digital bus. The only new signal that VGA does not have is the pixel clock, this is needed because the LCD needs to know exactly where each pixel begins and ends. So because of this you can simply connect a R2R resistor ladder DAC to those digital pins to turn the color signals back into analog form and level shift the Vsync and Hsync to the correct voltages and you now have turned the LCD interface into a analog VGA interface. All you need to do is set the LCD interface for valid VGA timings for the resolution you want.
Most other digital video interfaces are just different ways of packaging up this parallel RGB bus. Like the LVDS used in laptop LCD displays? Thats just the whole RGB bus fed into a serdes chip. And DVI? Well that's almost the same as LVDS but serialized differently with some extra info. And HDMI? That's just DVI with extra coding on top and audio inserted in the display blanking periods. Because of this you can get a chip that converts this raw parallel RGB bus into pretty much any other video format, including VGA.
Its when it comes to Composite, Component, SVideo etc... when its not as straight forward as those have roots in the beginning of color television. Because of that they use a different color space YUV and they differ in timings and modulation methods depending if you want to feed it into a PAL, NTSC or SECAM television, also it uses that dreaded interlacing too. Tho you can probably still generate a black and white composite video signal by feeding just one of the RGB colors into a DAC and setting the timings to match PAL or NTSC. But why would you do that when you can get nice 24bit high resolution VGA out of it using just a handful of resistors. -
The STM32F4 advanced series I am looking at only have a serial MIPI LCD interface...
Right, I thought scart also had vsync and hsync... no scart
If I will use a R2R network or one perhaps something like a ADV7125 I don't know yet. I probably start simple and upgrade when needed (chip is 12,= euro ex vat @ Farnell).
BTW: Berni, I really appreciate talking with you like this, thanks!
-
As far as i can see the datasheet claims that the STM32F469 is capable of both 24bit DPI RGB (aka parallel RGB) and 16bit DBI interface along with single lane MIPI DSI in both video and command modes.
The one you want is 24bit DPI RGB because this is the raw RGB bus that is this "VGA in digital form". The DPI stands for Display Parallel Interface
The other stuff is a bit more complicated and is more specific to LCDs. The DBI mode i think stands for Data Bus Interface. This is similar to the 16x2 character LCD displays where the display has a SRAM like data bus. These type of displays have a built in LCD controller and framebuffer, so the display is connected to the main system bus just like SRAM, EPROM or peripherals and the CPU writes into the framebuffer RAM located inside the display and send it commands by writing into its registers. Its sort of a LCD with a built in "graphics card". This is mostly designed to be driven by slow CPUs without a built in controller.
Then MIPI is mostly just a extra protocol layer on top of this to send it over a single diff pair. The video mode is DPI RGB sent in the form of packets and command mode is this DBI mode where write/read commands are wrapped up in packets and sent over the high speed serial link. This is a modern bus and is difficult to work with so its only usefull if you come across a LCD display with a MIPI interface already on it(Most phones have such displays).
Tho i suppose if you you want the functionality of a DBI LCD display but have VGA output you could use just the controller chip. For example Solomon Systech makes a lot of these such as:
http://www.solomon-systech.com/en/product/MobileDisplay/Display_Controller_IC/ssd1962/
http://www.solomon-systech.com/en/product/MobileDisplay/Display_Controller_IC/ssd1906/
They don't have the datasheet on there website but if you google the partnumber you can easily find it. It has the full register set and describes how to run it. And since its a DBI interface means it looks like SRAM so it can be stuck directly onto a Z80, 68000, 8086 etc.. bus So if you stuck this chip onto a ISA card with a VGA DAC you would have essentially made a graphics card for a PC, but one that you have a full datasheet from. -
The other stuff is a bit more complicated and is more specific to LCDs. The DBI mode i think stands for Data Bus Interface. This is similar to the 16x2 character LCD displays where the display has a SRAM like data bus. These type of displays have a built in LCD controller and framebuffer, so the display is connected to the main system bus just like SRAM, EPROM or peripherals and the CPU writes into the framebuffer RAM located inside the display and send it commands by writing into its registers. Its sort of a LCD with a built in "graphics card". This is mostly designed to be driven by slow CPUs without a built in controller.
Yeah, typically parallel bus LCD controllers can be ran from the FSMC, along with other RAM/ROM you may need; or DBI or whatever else. (It's also easy to run from a GPIO port, of course.)
Tim -
Doh! I didn't look past the STM32F4 advances series overview page. I see it now in the datasheet.
Those display controller chips sure look nice (and cheap $3-4 on ebay). That would offload the STM32 considerably.
I have found this datasheet and the LCD output signals seem to be VGA compatible (perhaps with some simple glue logic).
Excellent suggestion, thanks!
I don't see how you could use the FMC for two things, though.
Simply by using a CS for one or the other (like with SPI)?
That would be like bank switching memory....
High level it would look something like
-
I can't really say that i agree with that block diagram. There is no point in connecting a SSD1963 to a STM32F446
The STM32F4 has a built in LCD controller that is capable of generating DPI RGB video directly out of its pins, so there is no need for the SSD1963. If anything the external display controller will slow things down because the memory bus connecting the controler to the STM will likley be slower than the internal RAM of the STM32. Additionally the SSD1963 provides no "graphics acceleration" functionality, it just has a dumb raw framebuffer you write pixels into. Well if you go to a SSD1921 you do get bitblit functionality but it doesn't have a whole lot of graphics RAM so this functionality becomes useless once you get to higher resolutions.
The STM32 already does all the graphics you want on its own. It has a LCD controler capable of outputting RGB with VGA timings at decent resolution. Additionally has what they call DMA 2D and this is essentially a simple 2D GPU that can bitblit images around anywhere in memory and do things like alpha blending and pixel format conversion. All of this without any CPU intervention.
As for putting multiple devices on the STM32s FMC memory controller that works the same way as you put multiple things on your Z80. Trough address decoding you can automatically toggle chip select pins appropriately. Or since ST has thought of that for you the FMC actually has some CS pin outputs. This allows it to map various memory regions to various chips and automatically selects them when needed. As a bonus using the multiple chip select channels of the FMC also allows you to set it up for different bus timings for each device (Very useful if you have a device that is slower than all the others).
The main reason why i have sugested the Solomom Systech SSD19xx chips is that they have a memory slave bus. This means a SSD19xx chip can be directly connected to the pins of a Z80. You still have to slowly software emulate the bus on a STM32 where it is likley going to have trouble going at full bus speed due to latency issues. -
Yeah, if you're going to use something like that, you might as well put the display right on the bus, run it right from the Z80. Integrated (COG) display panels are cheap and plentiful, and 16 bit interfaces are very common (you'll still need some logic to sort out the 8-bit bus accesses somehow -- perhaps by latching the low byte then writing the panel when the high byte is written?).
You'll probably want a pretty small LCD, to keep reasonable fill rate; 320x200 would be about the most, or kinda pushing it IMHO. Last display I used was a 160x128 panel over SPI, which had probably half the bandwidth your Z80 bus is capable. That took a good 100ms or so to fully redraw, so I think you'd be able to get limited video through one, assuming you can bring in the data of course.
If you want a bigger display without sacrificing fill rate, a more advanced controller -- whether written yourself (STM32 or what have you) or with accelerator hardware -- will be required.
Tim -
The STM32F4 has a built in LCD controller that is capable of generating DPI RGB video directly out of its pins [..]
It does? I could not find any reference to an LCD controller/interface.
It does have some HDMI-CEC thingy I don't understand, but I assumed that is a different beast. Note I am specifically looking at the STM32F446(ZE) here - that's the one I've got.
Also, the idea is to make a smart video accelerator that off-loads the Z80. Putting the display controller on the Z80 bus would put the Z80 in charge of filling the video ram and all the 'accelerating' is done by the Z80... Not what I was shooting for. And I want to reuse existing VGA monitors. I might buy a small LCD board (with an SDSD1963 on it) for experimentation and development, but ultimately I want to be able to plug in my monitor(s) - VGA or other.
The Z80 bus <=> STM32 interfacing is something I need to look into, yes. -
Well i did manage to run a small display over SPI displaying a youtube video at a reasonable framerate. The worst part was actually the tearing problem because the LCD refresh was not synchronized to the updating of the frame buffer. But this sort of thing was done using a Rasperry Pi using a driver where the CPU would figure out the best way to update the display (it avoids updating areas that haven't changed) and then use the DMA to have the SPI at 32MHz going full wack at 100% utilization to max out the transfer speed and avoid any pauses in between bytes. That big fast ARM CPU in there was working pretty hard to make it happen.
So yeah if you plan to make fast paced smooth scrolling games run on it then the Z80 will indeed lack the horsepower to fill the framebuffer for a large resolution screen. But for a GUI this is perfectly fine and its pretty much how GUis ware made even into the 32bit era of PCs. When doing a GUI large potions of the screen stay static so not nearly as many pixels need to be moved around. It used to be pretty standard to see GUIs draw out step by step infront of your eyes in the 8bit era because it takes the slow CPU a few frames to draw everything.
This is why consoles in the 8bit and 16bit era had no framebuffers and instead generated tile maps and sprites on the fly. But all these sprite based graphics chips that do this tend to be proprietary and designed for the application, such as the C64 VIC chip or the PPU chip in the SNES. But if you want to have the graphical capabilities of a DOS PC that SSD19xx chip sitting directly on the Z80 bus is all you need.
Ah yes you are correct the STM32F446 you sugested does indeed not have any LCD controller built in. So just use a different chip from the STM32F4 family that does. Not all applications need a display so they don't put this peripheral in all chips. -
So yeah if you plan to make fast paced smooth scrolling games run on it [..]
It is.But if you want to have the graphical capabilities of a DOS PC that SSD19xx chip sitting directly on the Z80 bus is all you need.
A character only controller is not what I am shooting for.Ah yes you are correct the STM32F446 you sugested does indeed not have any LCD controller built in. So just use a different chip from the STM32F4 family that does.
Not sure yet - depends on how that LCD interface works. If its all hardware, then yes. If takes a good chunk out of the CPU core(s) then I might not have enough cycles left for the interfacing with the Z80 bus. I need to look into that first, I think and I can do that with the STM32F446 I've already got.