 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 : PicoMiteHDMI framebuffer thoughts
Page 1 of 4   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
The RP2350 has 520Kb RAM vs 264 on the RP2040 The PicoMite VGA uses all of the 264 and this limits program size to 100Kb (96 for the USB version). Of the 264K 38400 bytes (37.5K) is used for the VGA framebuffer (640x480x1bit = 320x240x4bits) So for a 100Kb program size MMBasic is effectively using 226 KBytes. To achieve the performance given in the Pico2 thread I have used the hashed mechanism for subroutine and label search which uses something over 12K so say 240kBytes total This leaves 520-240= 280K free on the Pico2 with no framebuffer The question then arises how best to use this? Note that 280K is less than the 300K needed for a full 640x480 RGB332 framebuffer. Options are: 1: Stay with the 37.5K framebuffer and increase the maximum program size 2: Increase to 75K to give 320x240x8bits RGB332 and increase the maximum program size. In this case 320x240x8 would be a new mode 2 (640x480x2 mode 3?) 3: Increase to 250K to give 640x400x8bits with no significant increase in program size. In this case 640x400x8 would be a new mode 2 4: Increase to 218K to give 640x350x8bits with no significant increase in program size. In this case 640x350x8 would be a new mode 2 I quite like the 3 option as certainly on my 1080p monitor 640x400 automatically scales to full height and near full width  Option 4 also works well on my monitor. The aspect ratio is just greater than 1080p so there is a gap top and bottom but the width is filled and it does allow for a small increase in program size.  Both these images are created by a RP2350 in HDMI with all the HDMI code running on the second processor like the VGA RP2040 version  The image quality and stability is remarkably good considering the flying Dupont leads. Thoughts and other suggestions for memory use appreciated. When anyone has any RP2350 boards let me know and I'll post test programs for you to play with. Edited 2024-08-16 00:43 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4036 |
I'm probably being slow, but whilst you talk about program size and frame buffer, you don't mention MMBasic's working RAM/heap ? And presumably you need two frame buffers if you are also going to have the [ L ]ayer ? Best wishes, Tom Edited 2024-08-16 01:04 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
RAM/Heap = program size as RAM is used to buffer the program while editing/loading etc. Things like layers would continue to be 320x240x4 so all mode 2 code would work as before |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4036 |
Right, the tokenized program is in flash then ? - sorry I've slept since I last knew. IMO for the purposes of games the current weaknesses of the RP2040 based PicoMite which it would be nice to have addressed are: - Lack of grey in the palette, it would be really nice to have the equivalent of the EGA palette, or even better 16 colours from a choice of 64/256/whatever (including for the layer) - Another 20-30K of MMBasic heap would not go amiss (plus the continuing ability to use flash-slots as ROM for assets) I'm of the opinion that for games we shouldn't expect to be able to go beyond 320x240 resolution on either of the RP. Hope that helps, Tom Edited 2024-08-16 01:22 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
16 colours from choice of 256 is easy. The HDMI will be running at 640x480x8 under all circumstances. The framebuffer maps to two 640 byte linebuffers which feed the output so from 4 to 8-bits via a map table lookup is trivial. |
||||
Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 362 |
I haven't looked into the details of using the second processor with the HSTX peripheral, but I was wondering if it might be possible to implement some type of "Palette" or CLUT between the memory and the HDMI. This would allow for video modes with fewer bits-per-pixel and still have a wide range of colors available. For example, 640X480X4bits for a 16 color palette chosen from 8,16, or 24bit colors. This also allows for some interesting visual effects by just changing the entries in the look up table. This could also mitigate some of the compatibility issues as the table could default to the existing PicoMite Palette for 320X240 mode. Just dreaming here, but you never know unless you ask LOL -Carl |
||||
| Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 362 |
LOL, thread moved on while I was typing my post! Also, your demo image reminds me of the "Maroon Bells" here in Colorado USA. Edited 2024-08-16 01:44 by Sasquatch -Carl |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4036 |
It sounds like a "Boot to BASIC computer" with HDMI, 16-colour graphics, USB keyboard, mouse and controllers and 100+ KB of RAM is within reach with the RP2350, nice  .... of course you can create the hardware and some of us can write the software, but I don't imagine any of us will do much good at promoting and selling it beyond our cosy little niche  .Thanks for your efforts Peter, I hope you enjoyed your break whilst it lasted. Tom Edited 2024-08-16 01:43 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
For photos I prefer option 3 judging by your pics. I suspect it would look better on most monitors. Option 4 might look very small on a 4:3 display. Option 2 has its merits. It might be faster to work with for games as well as giving more free RAM. The hardware is being experimented with in SL6, Tom. :) The design in my "I got bored" thread has been hacked about and the video now uses (or has reserved) the 8 GPIO pins that HSRX uses. At the moment it's VGA. . Edited 2024-08-16 01:51 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 362 |
This is the advantage provided by digital differential signaling, it is very immune to noise, bad cabling etc. it either works or not, there isn't too much in-between. I have some RP2350 devices on order. Likely a week or two before they arrive from Pimoroni or SparkFun. -Carl |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6781 |
Sorry - I mis-tryped HSTX as HSRX... Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
hi Peter, is 720x400 at 70Hz technically achievable? this is what the VGA text mode uses, and allows for 80 columns of text with a much nicer (IMHO) 9 pixel wide font that would look great in the editor. it would require 144k for a 4-bit deep frame buffer. cheers, rob :-) |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
Oooo that sounds nice  |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
720x400 is an old vesa standard and I can find no evidence that it has ever been supported over hdmi. Lots of posts from people who want vga to hdmi converters for 720x400 and no solutions AND before anyone asks, unlike vga, you cannot do things like 960x540 over hdmi as hdmi needs a clock signal that has to be at a recognized frequency - 5 clock pulses per pixel Edited 2024-08-16 02:20 by matherp |
||||
| gadgetjack Senior Member  Joined: 15/07/2016 Location: United StatesPosts: 142 |
I think I like option 4 the best. For most hdmi monitors or tv’s it would look very good. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
I see 2 applications. The games, and the control interface. For games, it is needed to work with layers, framebuffers. The CPU speed did not increase that much to allow for games in much higher resolutio and color depth. So i would suggest keep 320x240 with 16, max 64 colors (222), or palette mode. But note, video is infinitely memory hungry.graphics cards have 16Gbyte ( NOT Mbyte). Of ram. For control you do not meed the frame buffers. So pick whatever suits... Maybe align with CMM2 for geometry. Volhout Edited 2024-08-16 02:39 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 362 |
I'm still cogitating on this, but here is my current Christmas wish list: Mode 1 : 640 x 480 x 1bit with color tiles. For compatibility with existing PicoMite VGA code. Mode 2 : 320 x 240 x 4bit with 8 bit palette? if the palette defaults to the current PicoMite VGA palette, this would be highly compatible with PicoMite VGA Mode 2 for existing code, games etc. Mode 3: 640 x 4XX x 4bit with 8 bit palette? Mode 4: 320 x 240 x 8bit color. Note that if the hardware is only supporting 8 bit color the CLUT would not be needed but would still be a nice feature. Anyways, these are just my current thoughts, I guess we will see what is possible or practical. I am really excited about these developments and can't wait to see what matherp and the community come up with! And of course, what shall we call the new device? PicoMite2, PicoMiteII, PicoMite//, PicoMite][, PicoMite)(, PicoMite Due ??? Edited 2024-08-16 03:16 by Sasquatch -Carl |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
Hmm, that's interesting - why? |
||||
| Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 362 |
Well just thinking that 8 bit style games would most likely be at 320 x 240 so personally I don't see much need for 256 colors at 640 x 4XX and it gobbles up memory quickly at higher resolution. Of course others may have a different opinion, that's why we are having this conversation! Also, if you can choose the 16 colors from a larger palette, this is still very versatile even at 4bits. Edited 2024-08-16 03:26 by Sasquatch -Carl |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Almost like the Atari ST Low-Res mode, (16 colors out of 512), except that we have 40 lines more. the memory would stay at 38.400 Bytes, During image generation, the output must convert the memory values via a pallet. 'no comment |
||||
| Page 1 of 4 |
|||||
 Print this page |
