Видео

Thank you. Yes, the video is very desperate and cumbersome. With the Pico 2 the situation should be better, as it has a hardware floating point and so it is possible to use fast decompression - I assume it would use the MOV M-JPEG format. The Picopad PRO version uses better hardware - amplifier, better speaker. Documentation for it is still missing.

​@@miroslavnemecek197 I didn't know the PRO had an amp? I was thinking of adding one to mine, but I'm still playing with the design. Thanks again !

@@megazoid Unfortunately I also still don't know the wiring, so I'm rushing the author to publish. We're running out of time. 😁

Thank you. The main disadvantage of such projects is the lack of interesting software. Other systems provide more performance for the same price, so it is no longer interesting to use such a weak processor. I am currently using a Raspberry Pico. Its capabilities are incomparable at the same price.

Yes, yes, of course, they're all full of it now. We're already figuring out how to go to it. 😊

Thank you, I'm glad it was useful to you.

CGA se 4 barvami byla docela bída. 16-barevná grafika u následného PCjr byla už plně dostatečná pro hry, škoda že PCjr byl propadák a neuchytil se.

Sorry, other games are a problem to emulate. The main problem is the size of the RAM memory. The emulator loads the program into Flash memory, divides the memory into 4 KB pages and reallocates the corresponding page to RAM when it is written. This ensures that programs requiring 640 KB of memory could work. However, most DOS games introduce their parts into memory additionally as overlay modules. The emulator cannot distinguish this and has to load them into RAM memory, so the internal RAM memory of the Pico processor is not sufficient for most programs. A significant part of the RAM memory is also consumed for video memory. The solution is to modify the emulated programs so that the entire code is loaded as a single file into Flash memory, then the RAM memory might be sufficient. However, the modification is quite difficult and sometimes it may be easier to write such a program again, in Pico C code.

The emulator emulates 20 basic video modes from CGA to VGA cards, so graphics should not be a limitation. To save memory, BIOS and DOS functions are emulated internally by the emulator functions, not by running DOS and BIOS code. The emulation is not exact, only the most basic functions are emulated for the savings, this is also a limitation of emulations, besides the lack of memory. The accuracy of emulation could be improved over time, e.g. emulating the video card registers more accurately.

K dispozici je emulátor GameBoy a jsou i připravené sestavy některých her jako např. Mario, s tím omezením že zatím nefunguje ukládání pozice a nelze to oficiálně nabízet. Nemám o tom ale přehled, dá se to získat dotazem lidí z komunity Picopad např. na Twitteru.

Ano je to tak. Přesněji, AI negeneruje přímo zvuk, ale řídí hudební a hlasové syntezátory.

@@miroslavnemecek197 Ako chces povedat ze si dal text a vyplulo ti to pesnicku hej ?

@@bobricius Ano, tak.

I don't like the solutions of other emulators, so I create my own. The PicoLibSDK library is a general-purpose library with many generic utilities that can be used in other projects. It's a good place to implement generic libraries. Currently, the base hardware for PicoLibSDK is the PicoPad console. I plan to create emulators for some retro devices, with a focus on the PicoPad. Admittedly many already exist, but I want to do it my way. I'm currently working on an IBM PC-XT emulator (also because no one has implemented that on the RP2040 yet). The RP2040 processor is great for implementing emulators - it's not a multitasking environment with an operating system, and the 2 processor cores can run independently. This allows the instruction interpreter to run on one core of the processor and the user service to run on the other core. This makes it possible to implement an emulator that has precise timing down to the individual instruction level. I think this is the biggest advantage of this processor - it is relatively easy to implement emulators. Unfortunately, there is a limitation of RAM memory and speed - only devices with speeds up to 5 MHz are realistic. I plan to switch to Raspberry Zero 2 later, where more powerful emulations could be implemented (e.g. IBM PC-AT, which is not real on Pico). I don't need donations, thanks. :-) I took early retirement a year ago to pursue programming as a hobby.

@@miroslavnemecek197 : you're very kind! Glad to see you're currently doing what you like as a hobby 😄. I think we're a lot here following your webpage with the new enhancements and new projects too! God bless you!

The program is compiled so that it does not start at address 0x10000000 (= start of Flash memory) but at address 0x20000000 (= start of RAM memory). The address is stored in the sector header of the UF2 file format. The USB boot loader boots the program to the address according to the header into RAM and executes. The compilation address is specified in the linker script file *.ld.

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

Because people are now dumb. If u have a brain and see pico specs, u will know that a 133mhz and 264kb its totally capable of this. But now everyone is used to a 5ghz 8 cores cpu and thinks that this is just e-waste, while its better than an SNES.

Library currently suports ST7789 display controller, via SPI interface. So far there hasn't been a need to add other display interfaces, but it shouldn't be much of a problem.

A special simplified format is used for video because nothing else would play. MP3 could work, but no one has implemented it yet, because the modules used don't have a high enough quality audio output (only 8-bit PWM is used, mainly focusing on games).

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. ruclips.net/video/hWk1_XpkH5U/видео.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.

To už bohužel bylo maximum co jsem ještě vymačkal z paměti, více podrobností si už nepamatuju. :-( K Invexu by si možná víc vzpomněl kolega Jaroslav Knápek, ale už bývá problém ho kontaktovat.

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.

Dude me too. The weird thing is I asked my aunt what the clown was singing and she said "burial." But I don't see how she could have possibly known that.

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.

Je to program POVRay, který se dá stáhnout z internetu. V současnosti ve verzi pro Windows spolu s modelerem. Já používal ještě DOS verzi s příkazovým řádkem. Zdrojové kódy pro tuto animaci jsou na GitHub github.com/Panda381/DOS-Progs/tree/main/INVEX96/GEMALOGO .

Odkaz na zdrojové kódy animace spolu s programem POVRay jsem vložil na konec popisky videa, pro případ kdyby RUclips předchozí příspěvek s odkazem smazal.

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 RUclips). 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.

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.

Arduino: ruclips.net/video/jmdYueKbfG8/видео.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!

😊