Guru
Joined: 11/12/2012
Location: United KingdomPosts: 11027
| Posted: 02:22pm 30 Mar 2025 |
I've been half-heartedly following the two filemanager threads and it seems to me as a bystander as if both threads might be fighting the PicoMite firmware rather than working with it.
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.