 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 : PicoMite VGA Edition beta releases
  Page 2 of 5   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
The problems with big LCD panels are the time taken to update them and the number of pins required to interface them. A parallel interface is fast, but uses up most of your IO pins. A serial interface is a lot slower but will use 4 pins at most. Note that even mono VGA support has taken a chunk of RAM for the frame buffer. That can't be avoided. Colour VGA would take a lot more. Unfortunately the RP2040 doesn't have a huge amount of RAM to start with and there's no way to expand it. You can do colour VGA on a PicoMite, but you would probably have very little user workspace left (if there's still enough for MMBasic to run). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 712 |
No need for, colour, no need for speed, no need for touch. Just a little Display and a keyboard for editing....... Edited 2021-12-14 20:56 by atmega8 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
The PicoMite is fine with the LCD displays it can handle. Anything bigger needs something like the Armmite F4, which has a faster, parallel display. It also has a built in SDcard socket and the facility to add a PS/2 keyboard so it's a better platform than the PicoMite if you are looking for something more like a computer than an embedded controller. The speed bit is important. Scrolling a full screen of text on a serial interface LCD graphics display isn't very fast at all and the higher the display resolution the worse it gets as there are more bits to rewrite. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3008 |
I'm not sure how much of an issue that is. Is this too slow? Picomite LCD file viewer Code here PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3008 |
Are you saying that you want VGA +and+ ILI9488--because ILI9488 works fine on the Picomite release except for its hardware problem with MISO which causes (among other things) BLIT READ not to work. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3831 |
I think Peter has raised impenetrable adamantium shields against this idea and its logical conclusion the LCD console. Tell you what, once we've got MMB4L to a release level perhaps you and I can see what, if anything, we can achieve along these lines with the PicoMite  .In the meantime I wonder if it might look less flickery if you didn't CLS but instead rendered a line at a time with sufficient blank spaces at the end of each line to eradicate anything previously there. Best wishes, Tom Edited 2021-12-15 00:34 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
But it's having to completely, and obviously, having to redraw the entire screen area at every stage. That's probably fine for page up/down but it's not particularly friendly for a screen editor, where the user generally expects to see all lines except the cursor one move up or down without everything being erased first. Also, typing a character at the end of a line to cause a CRLF has to scroll lines below it down - which will result in another screen redraw, as would backspacing up a line causing deletion of a character. The video nicely demonstrates the low speed of screen updates. It was a great attempt, lizby. At the end of the day you are limited by the speed of the SPI interface, the controller chip and the LCD screen itself even if you wrote handling routines in raw machine code - and the PicoMite isn't hanging around at 250MHz. It may be already saturating the SPI bus. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3008 |
I guess you and I have different ideas about "low speed of screen updates". The SPI bus may well be saturated, but perhaps having it done in firmware would improve things. Certainly for the ILI9341, smooth scrolling could be achieved, because it doesn't have faulty handling of MISO. The ILI9488 could also possibly do this with a hardware fix with a 74HC125 to gate MISO with chip select, but that's untested. Tom--it's on my list (but so are a lot of other things which I'll probably never get to--though that one is higher on the list than some). PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
Coming soon RGB121: OPTION COLOUR VGA ON/OFF   Edited 2021-12-15 04:56 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3831 |
Hi Lizby, Remove the CLS statement on Line 25 and replace Line 28 with this: Text 0, y, lines(ln) + Space$(Max(0, 60 - Len(lines(ln)))) Scrolls and looks beautifully flicker-free on my 320x240 display, obviously won't be quite as good on 480x320 but the suggestion that it isn't adequate for use as a console just seems to be wrong. Definitely going to be good enough for my handheld Text Adventure games-console. Best wishes, Tom Edited 2021-12-15 06:34 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
Erm... but you can't do that, Peter... Oh, never mind, you'll do it anyway... :) Nice! Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1773 |
"Coming soon RGB121" Vey clever! A 4 pin port, 2 for green with resistor mixing? The code behind it must be tricky. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
It is do-able on ILI9341 but too small to be sensibly usable, not possible on 480x320 because you can't read the framebuffer. Code open source so knock yourselves out or just use an ArmmiteF4 where everything works. Not every port needs or should support everything. The nonVGA Picomite will NEVER support console functionality developed by me - end of |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9051 |
....story. (interpolating the last missing word) Peter - can you please comment on if the BlackPill VGA mite port is now abandoned? With basic colour VGA coming soon, then I would hazard a guess that perhaps it is. Reasons: 1) The PicoMite module is cheaper then the BlackPill module 2) The PicoMite will support colour VGA soon, the BlackPill module never will. That is how I understand it, but some clarification would be useful here... Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
rather than having 2-bits of green, a more 'traditional' approach would be for 1-bit each of R, G and B, and 1-bit of intensity. ie, RGBG. this would require no software change, just a small quantity of hardware so the I bit clipped each of R, G and B levels in half when asserted. cheers, rob :-) |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3496 |
Actually Robert, That does not make any difference for what Peter is doing. He is sending 4 bits wide video data, and you can wire it up whatever way you like. They are simply 16 colors (15 and black) and if you wire them RGGB or ARGB, that s up to you. Yes, green may be yellow, but that can easily be solved by a set of 16 defines that match your hardware. Another solution you can choose is to use the 4 bits for 16 level greyscale. In that case you may be forced to tune a bit, or the editor (in colorcode ON) may give cluttered results. When you do not connect the second G pin, you have the 8 colors of a CMM1. Smart, and very configurable. Edited 2021-12-15 17:30 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
I'm interested in where the RAM is coming from for these versions of VGA. It would appear to me that 4-bit video requires a frame buffer 4 times the size of that used for 1-bit video. If mono reduced user RAM from 80k to 64k that's a difference of 16k so I'd expect a further reduction of 48k for the other 3 bits, bringing us to 16k of user RAM when VGA is in colour mode. TBH I don't understand why user RAM only dropped from 80k to 64k with a 640x480x1 frame buffer. I can only assume tha removal of other stuff freed up some RAM that was being used for MMBasic's fast access routines. If that's the case then the resulting user RAM in colour may be even less. Assuming they do support simple graphics and therefore use a frame buffer, that is. :) >>confused<< Edited 2021-12-15 18:34 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8567 |
640*480*1/8 == 320*240*4/8 == 38400 > (80K-64K)*2 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
So you get either 640x480 mono or 320x240 colour, it's a swap? That would make sense to me. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Holy moly....whenever will I find the time   (Farnell) |
||||
| Page 2 of 5 |
|||||
 Print this page |
