 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 : Pico16VGA
| Author | Message | ||||
| gadgetjack Senior Member  Joined: 15/07/2016 Location: United StatesPosts: 170 |
 I found this code on https://github.com/Panda381/Pico16VGA. Very simple circuit with lots of sample programs, all drag and drop to load. I have only went through about 4 of the samples but they look pretty good. All 640x480 in 16 colors. He has other works on his page , but have not tried them all yet. Some good stuff for a cold winter day. Jack |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4068 |
Uses too much RAM I suspect. John |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8043 |
Correct. He used a large percentage of the Pico#s RAM for a frame buffer with a small program space. You can't have both. Clever stuff, but not of practical use. Edited 2022-02-19 04:20 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
i linked to the above library in an earlier thread here: https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=14546 it appears that he MAY be implementing something far more sophisticated, with mixed-mode video output where segments of the frame buffer can be graphical, while other segments are character-based that index into what used to be called in olden days a "Character ROM". as such, FAR LESS RAM IS USED for text areas. cheers, rob :-) Edited 2022-02-19 06:45 by robert.rozee |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8043 |
Peter did actually base the PicoMite VGA edition on some of Miroslav's work. You have to remember that Miroslav produced a versatile library to do all sorts of things. Some images use certain functions, others use other parts. You are seeing a mixture of demo images using different parts of the library. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
the function ScreenSegmAText(sSegm* segm, const void* data, const void* font, u16 fontheight, const void* pal, int wb), with reference to segments of screen, gives a strong suggestion that mixed modes are available. ie, that you can have: 1. a graphical area of the screen with a modest buffer for drawing graphics on, while at the same time, 2. a 'character/attribute' area of the screen where text can be placed and that has a substantially reduced buffer requirement (# chars width x # chars height x 2). this is similar to what the Apple II had, a split-screen mode where the top part of the screen could be graphic, while the bottom part was text-only. this suggests to me that it may be possible to have, for instance, an 80x24 text screen using a tiny 4k buffer (plus CHARGEN 'ROM' image in RAM), with a 320x240 pixel graphics overlay area using a 38.5k buffer. cheers, rob :-) Edited 2022-02-19 09:43 by robert.rozee |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 659 |
This method uses exactly the same amount of buffer memory as the PicoMite VGA 16 colour, Miroslav has just wired it up in a subtly different way such that there is 1 bit for each of R,G & B and then 1 bit which controls the brightness of all three R, G & B, (so 4 bits per pixel) you should be able to wire up this configuration as shown here and then re-map the colour definitions to use this configuration, not sure what other subtle effect this might have to colour output of the PicoMite. The link above gives a very good description of how it all works. Regards, Kevin. Edited 2022-02-19 18:58 by Bleep |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
hi Kevin, i'm a bit confused as this is not consistent with the description of of the buffer: "ScreenSegmAText(sSegm* segm, const void* data, const void* font, u16 fontheight, const void* pal, int wb) [...] each character is a pair of bytes. The first byte is the ASCII value of the character, the second byte is the color attribute. are you saying that the above buffer, consisting of [character, attribute] pairs, is not directly scanned by the video hardware, but is instead maintained separately just for the user to write to, and is then (upon and change) used to draw graphic representations into the 'real' 640x480 graphics video buffer? this alternative makes little sense; the use of an 'intermediate' buffer as a staging area just adds a layer of complication. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10379 |
Not sure the point, if any, being made here If you want flexible graphics you need a framebuffer. The fact that you can do text by constructing the raster on the fly is interesting and clever but of limited utility for MMbasic unless you want a version with no graphics |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 659 |
The library will operate in different modes, depending on what display type, or how you wire it up. "VGA_MODE - determines the mode of operation and the connected display type. The individual modes were listed in the table next to the Wiring Diagram: 0=old analog VGA monitor, 1=new analog VGA monitor, 2=universal mode (analog VGA and digital LCD), 3=digital LCD panel in HV mode, 4=digital LCD panel in DE mode. If you change the selected display mode, you must yet uncomment the appropriate section in the vga.pio file to define the side-set pins." Please see link So I suspect the function you are looking at is for a different display configuration, not VGA16. Regards, Kevin. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2446 |
"constructing the raster on the fly is interesting": that is certainly my point. and i agree 100% that it of very limited utility for MMbasic. i am just (and only just) curious about the feasibility of creating a 1366 x 768 video output text mode that is 80 columns x 24 lines, with 4-bit foreground and 4-bit background colour. NOT NECESSARILY FOR MMbasic, but as a 'thought experiment'. i puzzle over it being within the reach of the RP2040 hardware. back in the 'real world' i'd tend to just use a RPi zero to do such a job, as once all the extra circuitry (PCB, VGA socket, etc) is added around the pico, the RPi zero is likely to cost less and be more versatile (HDMI video + USB keyboard support). cheers, rob :-) Edited 2022-02-19 20:08 by robert.rozee |
||||
| gadgetjack Senior Member Joined: 15/07/2016 Location: United StatesPosts: 170 |
To Robert_rozee , I am sorry I did not give you link credit for the PicoVGA16. I forgot where it was I copied the link from. I tag so many of these links and go back and read them later and lost track. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
