Attached is the first beta of the RP2350 standard PicoMite firmware.

PicoMite.zip

6.01.00 will focus exclusively on the rp2350, making use of its extra memory (and to some extent PSRAM)

In this first beta there are a number of changes as follows:

Enhanced KEYPAD command
The existing KEYPAD command supports a 4x3 or 4x4 keypad using the syntax
KEYPAD var, int, r1, r2, r3, r4, c1, c2, c3 [, c4]
This release supports n x m keypads using the syntax

'startcolpin' is the pin that begins 'nocols' of contiguous GP pins used as the column scans
'startrowpin' is the pin that begins 'norows' of contiguous GP pins used as the row scans
'var!' is the variable that will contain the value returned to the interrupt routine 'int' when a key is pressed
keymapmap!() is a two dimensional array that contains the user supplied mapping for every key. The array dimensions must match the number of columns and rows specified

So for example if I have a keypad with 3 columns and 4 rows
123
456
789
*0#

And I wire gp1 to the left column, gp1 to the middle and gp2 to the right, then the 4 rows from top to bottom to gp3 to gp6

My program could be


Of course this simple example could be done with the existing command but the new command syntax can cater for any rectangular sized keyboard and has been tested with a 6x12 keyboard (72 keys) AND you can specify the reurn value for each key.

High speed buffered display drivers
The new release supports the following new display drivers
ILI9341BUFF: 320 x 240
ST7796SPBUFF: 320 x 320
ST7796SBUFF: 480 x 320
ILI9488PBUFF: 320 x 320
ILI9488BUFF: 480 x 320
ILI9488WBUFF: 480 x 320 'Waveshare Pico-Restouch-lcd-3.5
ST7789_320BUFF: 320 x 240 'Waveshare Pico-Restouch-lcd-2.8

In all cases enabling one of these drivers steals a RGB332 framebuffer from the heap so in the worst case of a ILI9488BUFF heap is reduced by 150K bytes (from 300K)

To use one of these drivers you first need to allocate the SPI pins to be used



These pins are dedicated to the display and must be separate from any pins used for the SYSTEM SPI which may still be required for touch and the sdcard (NB: in the case of the Waveshare boards using this driver will conflict with also using touch and the sdcard as they share the SPI channel)
The reason for the dedicated pins is that the screen updates will all take place on the second processor and for maximum performance this cannot share the SPI channel.

How much faster are these drivers? I've included in GUI TEST LCDPANEL an output when you exit the test that reports the number of circles drawn per second.



MUCH FASTER!!!

AFAIK all normal graphics work using the new drivers and they are tested with Petscii and work properly. Using these drivers, the use of the ILI9488 and particularly the ST7796S displays work very well as console devices. For maximum performance with the ST7796S display a CPU speed of 360MHz is recommended. This allows the SPI channel to the display to run at 90MHz giving a full screen refresh time of about 14mSec with no load on the main processor.
Of course the downside is that the screen is only using 256 colours instead of the full 65536. A later beta will include a MAP capability so that you can select the 256 colours to be used out of the full RGB888 palette.

---

Really looking forward to test this variant!😀

As always, NICE WORK….

Silly question time:

Does this mean that the additional PSRAM/heap memory mean that it is possible to load a 480x320 image from the SDCARD without getting an error message (warning of not enough heap memory)?

Hi Peter,
A question about the BUFF feature, what happens if your program is already using the 'B' option in a frame buffer copy, if you also have the BUFF activated?
I'm assuming all is good as you say Petscii Robots works and that does use the 'B' option, or at least it did, or does the 'B' option do nothing if you have the BUFF activated?
Regards Kevin.
Edited 2025-07-23 19:56 by Bleep

Don't understand the question about images. It has always been possible to load a 480x320 image from the sdcard to the display or a framebuffer.

The B option works exactly the same. Because the 2nd processor fifo is queued the background copy or merge just takes its place in the queue. The only difference being that the activity takes place between the framebuffer and the LCD RGB332 buffer. The actual physical update then takes place the next time the background copy to the display happens. All graphics commands set variables low_x, high_x, low_y, high_y which indicate the area of the screen that needs updating. The background update then just updates the area needed.
This gives a huge gain for things like circles because a single update does the whole thing rather than each pixel in the perimeter being updated separately

G'day Peter,
It seems mere weeks since the release of 06.00.03 and already we are at the beginning of the next great adventure in PicoMite firmware, not sure where you find the energy but rest assured it is much appreciated.  

Also must say the timing is great, I have only just posted the prototype of a PicoMite Terminal design idea, and the updated buffered display driver for the ST7796S / ILI9488 will hopefully work in well.

Can you please confirm that the PSRAM is optional and not required for the buffered driver?

Further to an old request for 1024 x 600 and 800 x 480 HDMI screen resolutions, I have now received and tested a couple and have a couple more on the way to test, as well as a bit of research on manufacturers websites.

So far the units that cannot resize the HDMI signal to the screen resolution (yuck)
will work with the same horizontal timing as their 4:3 counterparts IE:

1024 x 600 will work with 1024 x 768 timings
800 x 480 will work with 800 x 600 timings
800 x 480 will also work with 848 x 480 but can loose sync at times.

If you are still interested in supporting these resolutions / LCD's, can the number of active lines be changed (start blanking earlier) to support this without major changes to the HDMI structure?

Hopefully some food for thought.

Regards,
Lyle.

  Quote  

Can you please confirm that the PSRAM is optional and not required for the buffered driver?

Confirmed

  Quote  

Further to an old request for 1024 x 600 and 800 x 480 HDMI screen resolutions,

Adding extra resolutions is quite a lot of work and code. If I do anything it would probably be just 1024x600 to match the cheap 10.5" monitors

  matherp said  

In the CMM2 firmware, the editor and the filemanager are built using the same approach. I have created in the firmware a text framebuffer. That is a character map of the screen where each character position on the screen is effectively represented by two bytes, the first is the ascii code of the character, the second is the colour.
This is, of course, much smaller than a graphics framebuffer. So for a 640x480 screen and font 1 you need 80x40x2 = 6400 bytes.
In the CMM2, this framebuffer acts as a window on to a section of the underlying data - the text of a file for the editor and a list of all the files in a directory for the filemanager.
Then to output, the CMM2 firmware interprets that text framebuffer into a sequence of text and ansi escape sequences to be sent to a serial console (e.g. teraterm) and also to the pixel framebuffer that is read out to the VGA screen.

What this means is that the main editor code itself only works in coloured text characters and doesn't consider at all the mechanism of updating the physical output devices

Scrolling the text buffer by a text line is then very quick as only 6400-160 bytes need moving and the new 160 bytes derived from the underlying data and written to the top or bottom 160 bytes as appropriate.

What are the limitations of this approach? Only, from my perspective, that characters can only appear on modulus fontwidth and modulus fontheight locations on the display (as is always the case with a computer console) and that normal graphics are precluded without corrupting the display.

Now it is perfectly possible to implement this approach in MMBasic as a small number of subroutines that hide the underlying physical outputs from the functional code and some of the resource intensive actions, like scrolling, can be done very efficiently using things like MEMORY COPY.

However, if it would be genuinely useful, I could consider creating firmware support for this approach.

FRAME command
FRAME CREATE ' creates a text framebuffer  based on the current display resolution and current font. Any change of font, colour or mode after this command would cause an error.
FRAME X, Y, text$ [,colour] [,vertical] 'sets text into the text buffer
FRAME SCROLL x,y [,startx , xcount] [starty, ycount]'scrolls the text buffer, or a subset of the text buffer, by x and y characters
FRAME OVERLAY n,x,y ' creates a separate text buffer, reference n, x by y characters
FRAME WRITE n,x,y,text$ [,colour] 'write text into an overlay
FRAME CURSOR X,Y ' move the cursor to x,y character position
FRAME CURSOR HIDE/SHOW 'show/hide the cursor
FRAME SHOW n,x,y 'specifies that overlay n should overwrite the text framebuffer at the character positions x and y
FRAME HIDE n 'hides the overlay n
FRAME OUTPUT ' updates the physical displays using a minimum change algorithm and implementing the overlays currently marked for show in the order of the overlay reference

FRAME function
? FRAME(x,y) returns the ascii character at x,y
? FRAME(COLOUR x,y) 'returns the colour of the character at x,y
? FRAME(OVERLAY n) 'returns true if the overlay is currently being shown
? FRAME(UPDATE) ' returns true if FRAME OUTPUT is needed to update the physical displays

As a "nice-to-have" you could also consider some sort of BOX command using the extended graphics characters in font 1 and the TERMINAL font.
Since we typically use 4-bit colours on the PicoMite you could also use the other 4-bits for modifier functions like underline and flashing.

This functionality wouldn't be part of 6.00.02 which is now frozen other than bug fixes but could be considered for a future release.

Hi Peter,

What about the text buffer and layer in this release?
I'm looking forward to it.

Good health and creative powers!

mozzie

Please try the attached HDMIUSB version


PicoMite.zip

You can try:

OPTION RESOLUTION 1024x600 'need to specify the full resolution
1024x600 has modes:
1: 1024x600 mono with tiles
2: 256x150 RGB121
3: 512x300 RGB121
5: 256x150 RGB332

OPTION RESOLUTION 800x480 'need to specify the full resolution - steals heap

800x480 has modes:
1: 800x480 mono with tiles
2: 400x240 RGB121
3: 800x480 RGB121
5: 400x240 RGB332
Edited 2025-07-24 03:48 by matherp

loads but doesn't erase an auto run existing prog or settings for previous and took a while before usb kb seen or terminal kb working
PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00b1
OPTION SERIAL CONSOLE COM2,GP20,GP21
OPTION AUTORUN  ON
OPTION FLASH SIZE 4194304
OPTION COLOURCODE ON
OPTION KEYBOARD UK, 0, 0, 600, 150
OPTION RESOLUTION 1024x768 @ 375000KHz
OPTION DISPLAY 32, 64
OPTION SDCARD GP2, GP6, GP7, GP4
OPTION DEFAULT FONT 3, 1

?cpuspeed 0
Edited 2025-07-24 07:04 by stanleyella

  manual said  

MM.INFO$(CPUSPEED)  Returns the CPU speed as a string.

what's this new box and how to bypass it when flashing prog? please

Stan,
Your problem is nothing to do with the new MMBasic betas.

You have selected "command" as the device instead of picomite

G'day Peter,
Less than 4 hours from request to possible solution, I wish some massive multinational companies could provide this sort of response... more likely 4 weeks / months / galactic eons...

Happy to report mostly success, tried all resolutions for sync issues:

Tested screens:
1: Generic 5" 800x480 ONLY HDMI LCD - Driver chip has number ground off
Works in all modes in 800x480
Works in all modes in 1024x600 - extents past screen edges

2: WaveShare 7" 1024x600 ONLY HDMI QLED - TFP401AP Driver
Works in all modes in 800x480 - sync bands shown at screen edges
Works in all modes in 1024x600 - Very Nice  

3: MSI 27" 1920x1080 "Versa Sync"
Works in all modes in 800x480 - expanded to fit
Works in all modes in 1024x600 - expanded to fit ***
This is reporting 1024x600 @ 35HZ @ 245MHZ CPUSPEED

4: WaveShare 7" 1024x600 Pico DVI LCD - RTD2281 Driver
Works in all modes in 800x480 - expanded to fit or windowed
No display in 1024x600
Will work at 1024x768 - compressed to fit
Will work at 800x600 - expanded to fit or windowed
Will work at other resolutions by up or down scaling.

There are a couple more I'm yet to try

The test was GUI TEST LCDPANEL at each resolution and Editor for mode switching.

The 7" 1024x600 Pico DVI (4) is the unit I would like to see work the most, with a simple adaptor board its almost "plug and play" with a PicoMite, sods law says its the unit that won't work...  

Was 1024x600 @ 35HZ intentional, 50 or 60 seems to be more normal? the CPUSPEED is also 245MHZ

I also have the EDID data from a couple of these displays to investigate further.

Regards,
Lyle.

Try this one at 1024x60


PicoMite.zip


My display also says 36Hz but it is lying. The actual refresh rate is

(245000000/5)/(1344*628) = 58Hz = circa60

UPDATE

This might show 60Hz - I've upped the clock from 245MHz to 250MHz

PicoMite.zip
Edited 2025-07-25 02:58 by matherp

G'day Peter,
Good news, 2025-07-25_025614_PicoMite works in all modes on all screens  
1024 x 600 now reporting @ 60HZ

Both the 5" 800x480 and 7" 1024x600 are exceptionally clear at their native resolution, the editor in mode 3 @ 1024x600 is readable from 2 meters away  

I will post some pics when I get a chance, it is WAAAAAY past my bed time  

My thanks once again.

Regards,
Lyle.

Hi Peter,
Thanks for the new HDMI resolutions, they seem to be working fine.

As an alternative to the new BUFF LCD drivers, would it be possible, now that your new code calculates variables low_x, high_x, low_y, high_y, to allow the Blit Framebuffer....... command to work in the background, ie add the B option; or even add the same x, y, x, y, w, h parameters (or even low_x, high_x, low_y, high_y) in the FRAMEbuffer copy which already has the background option? This would allow the program to decide when to do the background LCD update, rather than doing it for every drawing command, which is what I'm assuming the new BUFF driver is doing?
Thanks for considering.
Regards Kevin.

In my development version the buffered driver fully supports OPTION AUTOREFRESH and REFRESH. With AUTOREFRESH OFF nothing happens on the screen until either it is turned on again or a REFRESH command is called.
I'll have a look at enabling BLIT FRAMEBUFFER in the background but no promises

UPDATE
Looked at BLIT FRAMEBUFFER and the answer is no. The data from the framebuffer has to be buffered as it is converted to RGB565/RGB888. At the moment this happens line by line with multiple writes to the display. If it was done in one step there would have to be a large temporary memory area created by the command which would likely cause the program to run out of memory. Moreover, that temporary memory area would need to exist until the background update had taken place.
Edited 2025-07-26 18:35 by matherp

Hi Peter,
I've reproduced your circles test pattern and tuned it to give me about 100 cps, the same as your demo, with the CPU at 360MHz and standard LCD drivers, using a ST7796S LCD panel.
I then changed to the ST7796SBUFF driver, I do get a doubling in speed, to about 200 cps, which is not bad, but not as good as your 500 cps, though I do get the same results as you using the GUI TEST LCDPANEL about 540 cps.
I've tried enabeling and disabeling the AUTOREFRESH, both within the code and at the command prompt, nothing I do makes the slightest difference, though the command is accepted, no errors?
I've tried Option autorefresh on/off, both in and out of a program, the LCD still updates exactly the same and still draws about 200 cps.
What am I doing wrong? please help. :-)



Circle program.


Regards, Kevin.
PS any chance of a USB version of the BUFF LCD firmware? as my test board is a USB, Thanks.

I'm using GUI TEST LCDPANEL not a Basic program. Will post a full set of firmware later.