PicoVGA - VGA/TV display on Raspberry Pico, demo samples
ฝัง
- เผยแพร่เมื่อ 8 มิ.ย. 2021
- PicoVGA library allows output from Raspberry Pico to a VGA monitor or PAL/NTSC TV interlaced, with a focus on ease use in technical and gaming applications.
More informations and download library: www.breatharian.eu/hw/picovga/...
Features:
- 1 base layer and 3 overlay layers with transparency
- 8-bit output in R3G3B2 format
- VGA progressive output up to 1280x960 resolution
- TV output in PAL or NTSC interlaced mode
- 30 frame buffer formats: graphics, tiles, text, special
- colour palettes
- screen split into segments of different formats
- RLE compression
- transparency with selectable key colour
- hardware sprites
- output layers to different color bits (color planes)
- automatic configuration video mode timings
- automatic overclocking of processor
- library uses the 2nd core, main program uses 1st core
- PWM audio output - วิทยาศาสตร์และเทคโนโลยี
Fascinating! I would never have guessed that this was all being done by a microcontroller.
I was asked how to split HSYNC and VSYNC in PicoVGA. The simplest method is this:
- Set VSYNC pin to output.
- Go to the VgaLine function (in vga.cpp), before switch(linetype). Add:
if (linetype == LINE_VSYNC), then set VSYNC pin to LOW, otherwise to HIGH.
And a last idea about this: I was thinking that it could be interesting to implement in RPI Pico's Core 0 a microinterpreter that execute some graphics primitives (like a bytecode or some similar). Remember that, as the PicoVGA has implemented code related to drawing lines, circles, etc., it could be useful to implement the microinterpreter to receive some "opcodes" (i.e., 0x01-> draw pixel, 0x02->draw line, 0x03->draw circle, etc.) so that an external CPU loads a "microprogram" inside the PicoVGA using these opcodes with data, and the Core 0 of the RPI Pico draws that program inside the framebuffer for the current graphics mode.
So much ideas to develop around this module... Thanks again, Mr. Nemecek, for your incredible work with this chip (and for the wonderful contributions in your Web page and also with Peter development software).
Another thing that's cool for me is the ability of this hardware to redefine font data dynamically inside the program. This is a great contribution because I remember that Commodore 64, Atari XL/XE and Spectrum could change text characters glyphs in BASIC programs and create basic animations or text-based games. In this case, it's mandatory to create a memory buffer in SRAM (together with Canvas bitmap memory buffer), assign it to the current font, and then change data inside the font buffer for characters to be transformed instantaneously on the screen. Isn't it beautiful?
This is the next road for pico! Thank you for your contribution to the community!
Indeed, as a comment, I can compare your work on PicoVGA with other libraries, like FabGL (ESP32), Bitluni's VGA library (for ESP32, as well) and others, and realize that your library is really awesome. I'm sad that your library hasn't been known by more developers in the scene 😥...
I later abandoned this concept because it was too complicated to use. Now I prefer to use simple rendering to a graphic frame buffer. Just today I am publishing a demo video on my SDK library for Raspberry Pico, which can output 16-bit to VGA and has video playback. th-cam.com/video/hWk1_XpkH5U/w-d-xo.html
@@miroslavnemecek197: I think use of segments inside a graphic mode (in PicoVGA library) could be complicated, but it was innovative and showed Raspberry Pi Pico processing capabilities (and your skills as a programmer too...) A graphical buffer is easier, but PicoVGA was capable of doing that too.
@@xyz2112zyx I've received multiple requests to port the PicoVGA library to the PicoLibSDK library, so I'm trying to implement it now. And maybe a new version of the library will be created, with support for 16-bit output.
This is one of the most exciting projects I have seen and I thank Miroslav for making it available. I got the parts and can't wait to try it out ! Thanks !!!
Your library is really awesome! I'm working now to create a portable computer with your library. And, I also need to say, that I couldn't install recommended RPi Pico SDK environment before. But, with your scripts now I'm programming this microcontroller as it must be. Really, thank you, thank you, thank you!
As some user commented here before, the internal design of the PicoVGA remembers me that from Atari 800 XL's ANTIC video processor. I read that you, Mr. Nemecek, didn't know about that, but ANTIC had capabilities for changing and combining (in a straightforward manner) 2 or more graphic modes into 1 screen (for example, we can print large text in a line, followed by many 4-color pixel lines, and then, add another lines for text again). This could be achieved through an ANTIC's DISPLAY LIST. But ANTIC only could apply this modes on horizontal lines (following scanline-based design).
In your development, you have vertical STRIPES and horizontal SEGMENTS. In a PicoVGA' screen we can add 1 or more STRIPES, and inside each stripe we can also add horizontal SEGMENTS, producing (theoretically speaking) video modes with graphics and text in rectangular areas. For me this is very exciting, because the possibilities are endless. And, looking inside the code, we can use different types of segments (text segments, 2-bits color graphic segments, 8-bits color graphic segments, tiled segments, and so on). This is beyond what I could think about a basic Graphics Processing Unit (not in the sense of an actual 2D-3D GPU); indeed, it's very useful for giving VGA output for many projects about retrocomputing.
Based on some experiments I did in my spare time with your library (and in the examples you gave us with PicoVGA), for setting a simple text mode or graphics mode, we only needed to add 1 vertical STRIPE (its height equal to that of the vertical resolution for the graphics mode), and inside that STRIPE, 1 horizontal SEGMENT (its width equal to that of the horizontal resolution for the same graphics mode). In a 640 x 480 pixels graphics mode, we need then one stripe of 480 pixels vertically, and one segment of 640 pixels horizontally. The segment then will show the pixels associated to the memory area selected for graphics data inside RPi Pico SRAM memory.
Awesome work! Very excited to play with this.
man that's awesome ..simply mind blowing
Did someone saw my jaw ? I drooped it here somewhere.
It is great beginning on this miniscule board
Tested PacMan on old crt monitor, resolution is 720x400 @ 70hz. If your monitor does not support this resolution, you will have a black screen. The Pico is not overheating, and the sound needs a preamp, but IT WORKS!
Amazing!!!!
Thank you for testing.
Btw, in your video is a "keyboard", but... uh... pinouts? Cheers!
@@florin1980 Keyboard in video is prepared for retro-comp. Demo samples of PicoVGA do not use it, they use PC keyboard via USB virtual COM.
@@miroslavnemecek197, thanks, i knew it was a demo after reading the source code, def.h DIR_L = 0 😆 it just moves on the left 😅
Looking forward for retro-comp 😁
@@florin1980 PacMan game can be controlled (played) with J I L K keys on PC keyboard.
Incredible!
Pico is great for some simple games, because also it can read data for graphics or sound in realtime from its flash memory 2MB.
Tyjo teda! Hustý!
Fantastic.
This is excellent! I want to try to interface the PicoVGA to the bus of my 8-bit hobby computer (HD6309 CPU) to use it as a graphics card instead of the Yamaha V9958 it uses now. I think it is possible, because someone has made a card for Apple //e to provide graphics, and it can even emulate a Z80 coprocessor.
I have a question about the balloon demo, all the small balloons are rising at the same speed.. do the sprites have independent control of position (x, y)? I think that demo might be more impressive if the balloons each moved independently.
Yes each sprite is controlled separately. But later I abandoned the hardware sprite technique - they are too time consuming for the processor. More recently I prefer to use software sprites and back buffers.
Perfect
I had no idea my Pico could do some of these! I really underestimate that little tiny board.
what you experience is society getting used to super poorly optimized games and graphics design since they decided to instead rely on faster and faster hardware.
slowly optimization got less and less,
and by now, not even the drivers tend to be optimized anymore, or atleast they often don't have as much support for heavily optimized methods.
essentially because simplicity is by now by far chosen over performance and power usage. to such a extend that some modern game engines and software make programs create such poorly made/optimized programs, and most games and programs use them in their default settings only adding things instead of optimizing it, this is currently at the point where for practically the same effort in general you could have insanely better performance and a similar experience when looking at what some of the frameworks and engines do by default(ofcource this mostly looks at the engines now used largely by AAA.
but ofcource simplicity also has some advantages, since it allows making more and adding more things, so also more easy to make things look well, there is one exception however, the simple methods used these days often don't really support more rarer things which in term become many times harder to implement and insanely heavy, like warping terrains and such for example.
in reality however by now we could move to a middle ground, since by now AI is pretty much advanced, all we need to do is make a hybride multilevel AI(combination of old AI with current AI to make it more efficient and since old "dumb" AI is much better at following the rules and theory, even though normal modern AI could also do it with some training).
then we could litterally make a AI based compiler, where the compiler doesn't just compile it but also actually recodes it in more optimized ways.
while this might seem hard and would take some experimentation and time an such, when done right the performance increases and power and storage and ram savings could be insane
Another concern about connecting this PicoVGA module with a WDC 65C02S CPU, 65C816S, Zilog Z80 or another CPU is that it could be convenient to add some kind of PIO program to simulate a I/O Data Bus with a R/W control pin and a CS selection pin. It could allow to operate this module at the CPU speed, maximizing data transfer speed between the PicoVGA and the CPU. Another way to do this is to implement an additional UART port (at a high speed; maybe 115200 bps or 1Mbps) in the computer board to communicate the PicoVGA and CPU chip, hoping that this allows to transfer more data and to load graphics quickly onto the screen.
I've already tried connecting Pico to the Z80 - both as a graphics unit, but also as a fast computing unit capable of executing pre-programmed math macros with double precision. The problem is not writing from the Z80 to the Pico, using the PIO the Pico can monitor the bus and send data to the Pico processor. But the problem is reading the memory or the result of operations - the Pico must detect the bus address, send it to the Pico processor via DMA, the processor (or DMA) processes the request and sends it back to the PIO - but this sequence of operations cannot be accomplished during a Z80 read instruction. The Z80 would have to stop or pass data back in some other, slow way.
Yes, you're right, but in today's computing environments is not mandatory to complete all operations in 1 read/write cycle. The RPI Pico can calculate operations, while Z80 waits for the results or do something else until the results are ready to be gotten through the data bus. Maybe a little cost to pay for having a coprocessor joined to our beloved ancient CPUs. But anyway, all of these ideas are just part of brainstorming...
@@xyz2112zyx I tried earlier to set up a Z80 bus access handler on the Pico using PIO. Apparently some more Wait cycle would be necessary. It is necessary to use 5.0/3.3V voltage converters and probably a latch register. www.oldcomp.cz/viewtopic.php?p=123285#p123285
Nice and thanks for the fast response on this! I'll take a look on that.
I still don’t understand how to split the hsync and vsync. For the vsync do you just pick a new (any) gpio pin, assign it as output, then reference it in the code as stated in the above description?
Yes, pick new gpio pin, assign it output and set its state as mentioned. Another alternative is minimalistic PicoQVGA library www.breatharian.eu/hw/picoqvga/index_en.html , where I've used both VSYNC and HSYNC signals, controlled by the PIO. VSYNC in that alternative must be on the next gpio pin to HSYNC. That method cannot be used with PicoVGA library, because of limited PIO program memory.
WoW !
If we think it in terms of other old-school chips for video graphics (as the TMS9918, ANTIC in Atari 400/800/XL/XE, and those for the Commodore 64), with the PicoVGA it could be possible to create a list of standard graphic modes. For example, this is my proposal:
1) mode 0: text mode in monochrome (only 1 foreground color for all the characters + background color), useful for a text terminal or editing text.
2) mode 1: text mode with color (each character can use 1 different foreground color + 1 global background color)
3) mode 2: text mode with multicolor (each character can use 1 different foreground + 1 background color, as in IBM CGA/EGA/VGA text modes)
4) mode 3: 256 x 224 2-colors bitmap
5) mode 4: 256 x 224 4-colors bitmap
6) mode 5: 256 x 224 16-colors bitmap
7) mode 6: 256 x 224 256-colors bitmap
8) mode 7: 512 x 384? 16-colors bitmap
9) mode 8: 640 x 480 16-colors bitmap
10) mode 9: tiled map-based screen
Added to these, we could activate sprites and scrolling (I'm not sure about PicoVGA scrolling capabilities), but this is a research to be done in the next days. What do you think about these, guys?
As I have experienced in some other projects, Pico is fast enough to perform graphics operations that previously required hardware support. For example, sprites - handling sprites in PicoVGA is time-consuming because they have to be scraped while the image is being rendered, so PicoVGA can only manage to render a small number of sprites at a small size. If there is enough RAM memory, it is better to use 2 image buffers that are switched and render the sprites purely in software, to a background buffer. This way you can achieve a higher number of sprites with larger sizes than the PicoVGA driver could handle.
Epic!
Thank you! (I wonder where your previous comment lost to?)
@@miroslavnemecek197: Mr. Nemecek, how do you know that my last 3 comments were lost?? Hahaha, that's true....
@@xyz2112zyx I have those comments in email notifications. Did you delete those comments yourself, or TH-cam did it? I am afraid that TH-cam deletes some comments itself.
@@miroslavnemecek197 : Oh! Well, I entered the same comment three times, but when I needed to modify them, TH-cam just deleted them. I heard about the same problem in other channels too. Finally, I only wrote "Epic!" after all that mess in the system...
I am in the process of writing a VGA 4-bits/colour display output on the Pico using only the 4 PIOs, freeing up the 2 cores for routines.
I have a 4-bit variant here: www.breatharian.eu/hw/pico16vga/index_en.html
@@miroslavnemecek197 Very good, but I am employing 4 bits per colour, totalling a 12 bit palette. (4096 colours per pixel.)
Then I shall work on even more colours, completely independent of the 2 ARM cores.
Sounds great, any progress?
@@goatmeal5779 Some minor, some major. I am programming it part-time.
I have devised a method by which I think that I can use 3 analog pins to give millions of colours, with the assistance of the PIO cores.
That is distracting me.
Disadvantage of high number of colors is that Pico doesn't have enough RAM for frame buffers (that's why I prefer to use 1 byte = 1 pixel). Flash can't be used to display video images because it's slow.
This is amazing!!
Would it be difficult to make it output 320x240p 60Hz?
I'm looking to create a portable test pattern generator for CRT's and monitors. This seems like an alternative.
PicoVGA has demo program Monoscope with test patterns of misc resolutions. In case of videomode 320x240, it uses double scan lines and generates video signal 640x480p, because VGA monitors does not support signal 320x240p@60. But there is no limitation to generate non-standard videomodes, both interlaced and progressive, TV or VGA.
@@miroslavnemecek197 Ok, I was thinking of using this for CRT TV's and monitors that supports 320x240p@15Khz over SCART/Component. Is it possible to configure it this way you think?
@@victorclausson4039 Yes it is possible. You can directly use demo program Monoscope and select videmode 13 (key 'D'), which generates test pattern with TV signal 320x240 pixels progressive on 15 kHz (as retro 8-bit computers did it). PicVGA generates composite SYNC signal, which can be connected directly to SCART.
@@victorclausson4039 can I ask You - I was informed that the RGB SCART connector is no longer used in new TVs and therefore the RGB TV signal from PicoVGA is losing its significance. Do you have any uses where you encounter TVs with SCART connectors, where this area of use is still significant?
@@miroslavnemecek197 Well of course! The retrogaming and computer community is huge these days. I have multiple CRTs for my retrogaming setup and a lot of people like me. At least here in Europe where SCART is very common on CRTs. Also, Sony PVM monitors and such can take a RGB signal 320x240p 15khz and have a pattern generator for these monitors not only helps us adjust the geometry but also check the picture before buying one, since some of them cost $3K+. So my plan is to create some sort of portable device to test these monitors with. Therefore my questions
These are great demos. I've been playing around with a Picomite VGA board running MMBasic. I was wondering if any of the demos written for MMBasic can be ported to work with the Picomite? It seems all of the graphics functions are disabled (GUI etc). I like the MMBasic environment but it seems all of the software written for it doesn't work on the Picomite VGA>
Sorry, but this is not related with MMBasic. This is an implementation of a VGA system in Raspberry Pi Pico.
This isn't a Picomite or a Micromite...
Why didn't your follow the reference design in chapter 3 of datasheets.raspberrypi.org/rp2040/hardware-design-with-rp2040.pdf? Can your library be updated to be compatible with the reference design? Also, are there instructions for integrating this library with the Pico SDK at github.com/raspberrypi/pico-sdk?
PicoVGA does not use recommended VGA hardware design, because it uses 8-bit output graphics. Raspberry Pico has small RAM memory and therefore 8-bit graphics is much more efficient than 16-bit. Using 16-bit graphics in such small device is not practical.
PicoVGA cannot be adapted to use 16-bit VGA output, because PIO interface requires continuous pin numbering and cannot output 8-bits to 16-bit output. Is should be possible to design universal hardware, which could support both 16-bit and 8-bit graphics, but it would not be worth, Pico has not enough RAM for efficient use 16-bit graphics.
PicoVGA uses Pico SDK too, but it is not prepared to be compiled using standard SDK compilation environment. I am using Pico SDK for Windows, because I do not use Linux environment: www.breatharian.eu/hw/rasppico/index_en.html . It is possible to adapt PicoVGA to be compiled in standard Linux Pico SDK environment, but I cannot do it.
One more question, Mr. Nemecek: is this library able to generate composite NTSC/PAL video through only one pin + GND? In your code you explain about getting NTSC and PAL resolutions, but I don't understand how to connect the Raspberry Pi Pico to my NTSC TV (without SCART connector, sorry - only with a yellow RCA VIDEO IN connector), if this is the case. Thanks and I'm taking your code for creating an external video adapter for my computer.
P.D.: this video adapter works like ANTIC in Atari 400/800. It's a great idea to mimic that technology through video "segments". Really awesome work here!!
No, Pico is not capable of generating a full composite PAL or NTSC signal. It generates an RGB signal with PAL or NTSC timing. If you want to connect an NTSC TV, you need to add an NTSC encoder, such as the AD723 circuit or such a module www.jrok.com/hardware/RGB.html . They are also sold as pre-made products. But for computer output, composite signal is not suitable - the signal quality degrades very strongly, colors blend into each other at the edges. This is due to the principle of PAL/NTSC encoding, which has a small bandwidth for computer output. Users of old-comp computers (such as the ZX Spectrum) have always preferred to use RGB output, and this has meant a big increase in image quality. Or if you use, for example, a Raspberry Zero, I think it has an NTSC encoder built in and allows you to connect an NTSC TV. But I'm not sure, I haven't tried it, just from the description. The Raspberry Zero is usually used with an operating system, but can also be used as bare-metal, with the "circle" library.
@@miroslavnemecek197 what is its main limitation? Sampling frequency?
It'd be nice to have some cheap solution for the composite video - AD72x are more expensive than the Pico and the Zero is usable, but it is overkill for most applications.
@@Papinak2 It would be possible to generate a color PAL or NTSC signal in software (some theory www.linusakesson.net/scene/phasor/index.php ), but it is quite difficult and the result will be of poor quality. PAL (which has a higher quality display than NTSC) uses a 4.43361875 MHz colour carrier, which is added to the luminance component and generates the colour information using quadrature modulation. It would be possible to generate a software color-carrying signal using tables. However, only at low resolution. The colour carrier will carry about 206 pixels horizontally on the line. At a horizontal resolution of 256 pixels, this will mean that the colors between pixels will blend, e.g. the font is then hard to read. Do you think the composite signal is that important with Pico? I've come across rather opposite claims that even the VGA interface is obsolete and rather HDMI is required. A composite signal at the computer output seems to me a lot of a step backwards, to lower quality.
@@miroslavnemecek197 Thanks for the insight. So it doesn't have capacity to compute luminance and chrominance and their modulation, not that its hardware couldn't generate that signal, right?
I agree that composite video is obsolete, but there are still some displays - in FPV drones, or car stereo systems, for example - where it is still used today. Now I have one project going, which could make use from the camera input on a car stereo, but any form of signal converter doubles the price of the hardware in the best case scenario - which isn't much in an absolute price, but still sounds a bit unreasonable. I saw some libraries for different microcontrollers, even colour output for the ESP32 using its internal DAC, so I thought that the Pico could handle that, too.
@@Papinak2 I'm surprised - drones and car stereo systems use composite video? If ESP32 generates it, I think it should be able to make it on Pico as well. I also found the project you're talking about. It should be possible to implement it on the Pico too, but it's difficult and I think I wouldn't be able to do it.
(I don't know why, but I posted this comment 5 times before and it disappeared!)
I return here to report some of my research, regarding PicoVGA (after all these months, without much time to experiment with this):
1) I tested the circuit Mr. Nemecek wrote about GitHub (issue #13, 2nd comment) related to generate a monochrome NTSC video signal. Indeed, this circuit works flawlessly, but the only concern is that the image is only in B and W. However, in my LCD monitor, the image is clearly impressive. Only remember to activate the 'VideoNTSC' driver inside your code; it's capable of doing 640x480 pixels in monochrome.
2) I created an AD724-based circuit to be connected to the PicoVGA, using only CSYNC signal (not HSYNC+VSYNC) and respective R, G and B color signals. The crystal I added is a 3.579 MHz (for NTSC). Then, I connected the PicoVGA, the AD724 VGA-to-NTSC encoder and my LCD monitor and I could get a nice color image on the screen. I modified some of the examples in PicoVGA GitHub to work in NTSC and I felt satisfied with that. The only problem is that some colors (red color most of the times) presented jitter on the image, although some of my LCD portable monitors improved image with some kind of internal filter (I guess...)
3) Connecting this card directly to a VGA monitor presents a invaluable great image! Recommended!
4) Also, I was designing some kind of portable computer with VGA graphics and a Z80 CPU (the typical ones in Internet or TH-cam). Using a 7'' portable LCD panel with an AliExpress LCD controller (suitable for that) created a great solution for this kind of retrocomuting projects. Now I'm modifying a bluetooth keyboard to transform it into a UART portable keyboard (without BlueTooth part) and trying to connect it to the computer.
Well, I think, as exposed in the previous comments here, that the only thing we need to develop now is some kind of API or SDK for connecting the PicoVGA to a microcontroller or CPU, through UART (from 115.2 kbps to 1 Mbps) or SPI (over 2 Mbps), to send commands for changing graphic modes, drawing graphic primitives, loading images onto screen or creating sprites. Really, really, I think this project is awesome, but underrated (for now). Imagine what can we do with this project when a new iteration of Raspberry Pi Pico shows up in the future (with more SRAM, more PIO's and improved clock speed).
@@xyz2112zyx The Raspberry Pico is able to communicate with the Z80 via the CPU bus, by simulating the I/O port, using Pico PIO+DMA interface. Data transfer from the Z80 to the Pico should be able to handle in full speed of the Z80 I/O bus (writing commands from the Z80 to the Pico). Graphics operations can be made more efficient by using the Pico as the image processor instead of the Z80. The Z80 sends graphic images to the Pico when the program starts (the Pico can store them in Flash memory) and then just sends commands for graphics operation through the I/O port, which is a fast operation. Reading data in the other direction, from the Pico to the Z80, is problematic and slow, on the other hand, because the Pico doesn't have time to execute the command and return the data during the I/O cycle - it has to enter the command and read the returned data from another port after a while. Therefore, it is better to limit the read operations from Pico to just status testing and make do with write operations only.
@@miroslavnemecek197 : nice to know that. I think that I must learn to program Pico PIO interface for achieving this kind of connection. But you're right: it's enough to write commands and data to PicoVGA from Z80 CPU bus, without the need of reading data backwards.
@@xyz2112zyx The PIO interface is a big big advantage (maybe the biggest?) of the Pico RP2040 over other processors and allows to do very interesting magics. But it's just sometimes difficult to fit a PIO program into a 32-instruction space.
This is totally awesome!! But why must every 'retro' themed hardware project use 4:3 aspect ratio to showcase the capabilities? Are there even any new 4:3 monitors being sold?
Earlier 4:3 was common standard, so old software where projected for such aspect ratio. It was practical format and such new monitors are sold nowadays too. 16:9 monitors can be switched to 4:3 aspect ratio, or program with PicoVGA can be adapted to 16:9 (need to switch to higher pixel clock rate).
@Lefteris: You can find info how to use begPUTTY on my website about Pico SDK on Windows www.breatharian.eu/hw/rasppico/index_en.html
More hardware info in ulabs nl...
Link www.ulabs.nl/hw/index.html
Thanks, Mr. Nemecek. I tried 3 times to post this, but comments were deleted before. I put this link here for presenting another results related to PicoVGA. I'm updating the website sometimes, so I need to complete related content with more developments. There are the circuits for PicoVGA + AD724 RGB-to-NTSC module and your circuit for connecting PicoVga to NTSC, but in B/W, only with resistors.
@@bendertherobot910 Thank you for your work and post. ... Yes unfortunately YT deletes posts with links, it's unpleasant.
Can Pacman output a portrait display ?
I don't think that would be easy to achieve. :-( The video is generated line by line, by continuous reading from memory, and it is combined with hardware sprites, no rotation is possible. The only option is to reprogram the display drawing functions to draw rotated, and that would be quite difficult. It would mean pretty extensively redoing the whole game. If there was more RAM, it would be possible to rotate the entire image by copying it into a second video memory, but Pico doesn't have enough memory for that.
@@miroslavnemecek197 Shame, it would be a great feature. Hardware sprites? I'm a complete novice with the Pico, could the pio code not munge together words by pulling individual bits from RAM (IE rotate by reading the RAM column bitwise rather than row wordwise), I've not tried any code like that so I have no real feeling for it at the moment, with no RAM cache such code is going to be at least 16 times more memory bandwidth so I guess it wont work?
@@jonshouse1 Pio does not have access to RAM memory. DMA transfer is used for this and it can only read RAM sequentially. Even if a different method of sending data were used (read columns by software), the transfer would not keep up in real time because it is already at the limits of its capabilities. Hardware sprites mean that they are generated by the PicoVGA driver, using PIO overlay layers, they do not need to be handled by the main program.
@@miroslavnemecek197 I understand, thanks for the explanation. Nice work on the project, very impressive.
@@miroslavnemecek197 I love that you used the PIO w/DMA to implement "hardware" sprites. I was thinking this could be done, myself.
qualquer um faz isso no raspberry. quero ver fazer no arduino...
Arduino: th-cam.com/video/jmdYueKbfG8/w-d-xo.html , www.breatharian.eu/hw/atpad/index_en.html
It's a rasperry Pico, not a Pi, all this is done with software, including the video output!
Incredible!