วีดีโอ

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

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

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 TH-cam 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 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.

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: 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!

😊

S antiviry je stále potíž a asi to nepůjde řešit líp. Program v Petrovi se skládá z interpreteru a programu ve vnitřním kódu a to antiviry považují za podezřelé a tak ho někdy zařadí do seznamu podezřelých programů. Své databáze navzájem přebírají a tím se zhoršuje skore programu. Pomůže občas programy uložit pod novou verzí Petra, aby se stal pro antiviry neznámý. Např. Defender z Windows 10 označuje za podezřelý jen 1 program z aktuální verze Petr 2.50/2.51 (Horor.exe), ale Kaspersky označuje asi 10 programů. Současné antiviry už nedetekují zda program provádí nějakou záškodnou činnost, ale jen jaké má skore podezřelnosti. Asi s tím nejde dělat nic lepšího. Nĕmeček

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

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