 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Why VGA and not DVI/HDMI
Page 1 of 3   |
|||||
| Author | Message | ||||
lew247 Guru  Joined: 23/12/2015 Location: United KingdomPosts: 1676 |
Can anyone tell me why we are still using vga connectors for the RP2040 boards? Wouldn't HDMI/DVI connectors be much simpler and futureproof and also have higher resolutions? I know you cannot use HDMI specifically because of licencing issues but DVI has no licencing issues at all and the signal generated can be used on a hdmi connector and therefore will work with modern monitors and tv's that don't have a vga input? URL=https://github.com/Wren6991/Pico-DVI-Sock]DVI board for Pico This board gives you an HDMI-shaped socket at the opposite end to the micro USB socket, which you can drive DVI-D video through and using the board DVI goes up to 720p30 with a 372 MHz system clock Tha's some pretty impressive graphic capabilities for the Pico? or am I just stupid and this can't be done with basic? This is the circuit He even has gerbers and everything else needed to build the board on his github and a full description no how the first version works including how the siftware works is here   |
||||
| mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 430 |
My bad. Edited 2022-01-22 03:37 by mclout999 |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
Probably because it needs 8 pins and a *much* bigger frame buffer. It's nice to have enough space to fit MMBasic, variables and some user RAM in. :) Just because it's possible it doesn't mean it's practical. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| KD5ZXG Regular Member  Joined: 21/01/2022 Location: United StatesPosts: 53 |
What might be impossible or impractical about a separate $4 Pico as a DVI or VGA terminal? Quad SPI between Picomite and Terminal should leave plenty of pins to play with... Edited 2022-01-22 04:59 by KD5ZXG |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3658 |
The VGA - just do it. DVI - needs more RAM? (Plus a developer.) John |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
Why? Try a SPI interface to a RPi and use that as the display driver. You can have HDMI then. You still need a local frame buffer big enough for the number of colours at the resolution you want though. Remember that the PicoMite VGA frame buffer is 38400 bytes in either mode. I don't think you'd want to sacrifice more. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| KD5ZXG Regular Member Joined: 21/01/2022 Location: United StatesPosts: 53 |
Why not RPi? Pico is cheaper, smaller, avoid slow boot through an unnecessary OS. Rather bitbang video and frame buffer from a separate pico than burden the main one running the interpreter. $4 to offload frame buffer is a price I can afford. Keep in mind the terminal code already exists, just wants for a port to Pico. "extensions for graphics (lines, boxes and circles) as well as alternative fonts" https://geoffg.net/terminal.html If PicroMite were to boot directly to Basic without Linux I might reconsider RPi. I certainly own a few RPi, but I've seen little progress toward that end. Was a FUZE Basic user on both PC and Rpi, but FUZE was an unsupported buggy mess. Development and fixes ceased for all but an expensive NSwitch port. I lost interest. They did have excellent manuals though, which is also very true here. Edited 2022-01-22 18:32 by KD5ZXG |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
The RPI *has* got a GPU though. That's something you *need* if you want high performance graphics and there's no way round that. Even if you do as you suggest, the main Pico's frame buffer is a limitation - you won't get higher resolution than you can manage in VGA because there's nowhere else to plot the graphics. Plotting them on the display Pico would slow everything to an absolute crawl - plotting every pixel individually. If I've understood the DVI demo correctly, he used about 50% of the RAM - that's over 140KB compared to the 38KB currently used. Don't get VT100 "graphics" confused with "real" graphics. They aren't the same thing at all. If you are happy with VT100 codes then you don't need local frame buffers etc - but you can't, for example, have polygones, sprites, blitting. Geoff's terminal is a mono VGA ASCII VT100 terminal only. All you need on the PicoMite is a COM port to talk to it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
it is pretty impressive  however, it looks like he may be doing pixel-doubling in both horizontal and vertical directions, simply to fit within the available RAM. we have just over 256k of RAM available. ways of slicing-and-dicing this include: 720p: 1280 x 720 -> 2-bits per pixel (black + 3 distinct colours), 20k left over 720p: 640 x 360 -> 8-bits per pixel (RR-GGG-BB), 20k or so left over 640x480 -> 4-bits per pixel, with around 100k left over this doesn't seem that much more impressive that what peter is already getting out of a VGA connection; 2bpp will look awful, think ZX spectrum colour rendition. this does not make for a great 'games experience'. for text, 640x360, displayed on a wide-screen monitor gives 80x24 text with a character cell of 8 pixels wide x 15 pixels high. now this is almost interesting, giving you a nice terminal screen if you can find a font that will render well with just 7 pixels of width (1 pixel lost between each character). while i like the idea of 2x pico's coupled together (one as display driver, the other for MMbasic), cost wise the economics become pretty tight: 2x pico + DVI socket and PCB, versus, cost of a RPI zero W2 (which has onboard DVI, + USB keyboard support to boot). i have great faith in Tom's MMB4L port, which will, ultimately, produce a "micromite" with (essentially) unlimited RAM running at phenomenal speed. current list price of a RPi zero W2 is just nz$25. having said all this, the DVI hack is very cool cheers, rob :-) Edited 2022-01-22 22:15 by robert.rozee |
||||
| lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1676 |
Pico can output 30fps 720P DVI full colour video with only resistors it can also do 1080P 60fps video in black and white only That's why I asked the question Video here skip to 2min 49 seconds if you only want to see the video proof |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8579 |
1080p 1920*1080 = 2073600 /8 = 259200 bytes = 253Kb Total memory on RP2040 is 264kB This has been explained above. These demos are just that and have no useful significance for MMbasic |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
excellent video, showing that acceptable results can be had without needing to go for SMD. all you need is 8x through-hole resistors and a sacrificial HDMI cable. BUT, i do believe that the code run on the Pico is doubling-up pixels. that is, each pixel value is sent TWICE, so while each line contains 1280 pixels, the ODD numbered pixels are the same as the EVEN numbered pixels. similarly, each line is doubled up, ie sent TWICE. this is the only way to fit 1280 x 720 into the available RAM on the Pico. you need enough RAM to hold a copy of the screen, and to get a decent number of colours on screen, you have no choice but to double-up the pixels both horizontally and vertically. having said this, 640 x 350 isn't a bad resolution for running a game. but not so great for displaying text. i'm not much into computer games myself  cheers, rob. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2287 |
expanding on this - you would have just enough RAM for a 1080p image in a single colour (ie, each pixel can be black or white, no shades of grey, nothing else), with only 10k or so left over. plus, 1080p is not possible on the Pico, the limit is 720p (1280 x 720 pixels). to be in any way useful, you would need to have a second Pico to run MMbasic on. cheers, rob :-) Edited 2022-01-22 22:51 by robert.rozee |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3658 |
Strikes me that it's far better to wait for a Pico with more RAM etc. John |
||||
elk1984 Senior Member  Joined: 11/07/2020 Location: United KingdomPosts: 227 |
I think there's also licensing fees to be paid when HDMI was added to a "Product"? |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
The RP2040 has 264KB of RAM. Obviously it's impossible to use anywhere near that as a frame buffer - you need communication routines and routines to handle the frame buffer, together with some workspace for serial buffers etc. I'd guess that you'd be lucky to get a usable frame buffer of 160KB even if everything is written in C. That 160KB isn't contiguous memory on the RP2040 either - it needs some memory management to page blocks in and out. Remember that you need that on *both* Picos, not just the display one, otherwise you simply can't do "proper" graphics. It's over 3x the current VGA frame buffer. Simply not on. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
There are licensing fees for HDMI, as they apply to the connector etc. DVI isn't encumbered by licensing, neither is Display Port. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1676 |
Could we not just use 16mb QSPI ram like other boards do and use some of that? External Flash is accessed via the QSPI interface using the execute-in-place (XIP) hardware. This allows an external flash memory to be addressed and accessed by the system as though it were internal memory. Bus reads to a 16MB memory window starting at 0x10000000 are translated into a serial flash transfer, and the result is returned to the master that initiated the read. This process is transparent to the master, so a processor can execute code from the external flash without first copying the code to internal memory, hence "execute in place". An internal cache remembers the contents of recently-accessed flash locations, which accelerates the average bandwidth and latency of the interface. Once correctly configured by RP2040's bootrom and the flash second stage, the XIP hardware is largely transparent, and software can treat flash as a large read-only memory. However, it does provide a number of additional features to serve more demanding software use case That to me reads like you can use the QSPI ram and for all intent and purposes it's treated like internel ram? 720P resolution in full colour could produce some stunning graphics In a few years there won't be many monitors around that still have a vga connector, which is why I first started thinking about this It's when I wanted my weather display to run on a proper monitor I had to switch to a Pi and when Picromite wasn't able to run on the pi properly because of the stupid broadcom licencing rules that I had to go to python However the Pico runs mmbasic perfectly it can output 720P video with no issues even with the base 256K ram in place, so surely with a 16mb qspi flash it should work? Even if picomite or mmbasic wasn't able to handle video, surely the better resolution and the fact it can be displayed on large screens and not just tiny display might make it worthwile investigating? To answer the previous comment by elk1984 there is no issue with licencing because HDMI would not be output, only DVI which has no licencing issues at all. And it only needs 8 X 270 Ohm resistors, 8 io pins including the clock ones. Oh and the software converted to basic You can download the picodvi-test.zip and get started playing around with the .UF2 example compiles in it. It also includes a PDF which gives you a step-by-step guide Edited 2022-01-23 01:26 by lew247 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5726 |
A: The chip on the QSPI is flash RAM, not fast access RAM. It's much slower to access and has a shorter lifetime. B: The Raspberry Pi Pico only has 2MB of flash RAM on the QSPI. Yes, the RP2040 can address 16MB but only if it's got it. :) The Pico can only output 720P video *at all* if it's not doing anything else. You couldn't do that and run MMBasic on the same Pico at the same time. There isn't enough RAM. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lew247 Guru Joined: 23/12/2015 Location: United KingdomPosts: 1676 |
QSPI has XIP "XIP stands for eXecute In Place, it is a feature which allows the microcontroller to execute code straight from the external flash memory without copying it first. This allows for faster and more efficient execution of code" W25Q128JVSIQ-ND 16Mb thousands in stock Digikey simple swap chips to use XIP? 1080P was black and white only -no use in real life 720P was full colour and according to your calculations would be 1280*720 = 921600 /8 = 115200 bytes = 112.5Kb As the QSPI interface used on the Pico is not only fast but it also has XIP can this not be used as a frame buffer? |
||||
| Page 1 of 3 |
|||||
 Print this page |
