 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 : All this filemanager code looks complex - could this help?
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10067 |
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. |
||||
| dddns Senior Member  Joined: 20/09/2024 Location: GermanyPosts: 259 |
I'm not a programmer but have increasing fun with it :) I am missing a VT-100 emulation running on the pico and my plan is, to try to programm it. No idea if this will work out.. Anyway, this new function looks suitable for all kind of output to a console and frankly speaking, I fell in love with it (again), especially with VT-100 implemented. So I would very much appreciate this new function! And many thanks for giving the master plan on how to achieve it! |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4854 |
Hi Peter, I think the concept you describe should be a nice one if the filemanager would be written ground up. Javavi's NC clone filemanager has started as a simple project, and has grown, and grown. And it was VGA only, as that was his testbed. But that is what you get with a waterfall development method. You can judge the way the code works as "fighting" MMBasic, but fact is : it works. And since it occupies 1 whole slot it is not important how efficient the code is performing or written. You loose a slot = 100k. Twofingers is adding features to the code, and his additions are mostly kept separate from Javavi's (at the end of the source file). Twofingers found that Javavi's code was hard to port to vt100, and created a separate branch for that. I think both authors deserve respect, they have created a good working program. When starting ground up, they could use your metheds, and maybe even use that to create a version that is to everyones satisfaction (scalable/not ascii > 127/both vt100+VGA/other resolutions). But I am not sure they (Javavi/Twofingers) would volunteer to start from scratch. It is a lot of work, in the end, to get the same you have now. Maybe a bit better. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| dddns Senior Member Joined: 20/09/2024 Location: GermanyPosts: 259 |
I would not want to use a vehicle, just because it drives forward. Question of attitude and point of view. I do have respect for their work on one hand side, but as a filemanager seems to be of interest for the majority, bad code is being deployed to them. Plus a filemanager is a serious issue, because it touches sensible data.. my 2 cent You didn't say a word regarding the function itself..don't you like it? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10067 |
Let me be crystal clear. I'm not denigrating the effort or the code quality of the various efforts and have no opinion on functionality as I can't use them as my hack development SD has too many files. The only point I was making was that the threads seem caught up in discussions about fonts, colours, VGA vs terminal. I was just offering a way to split this off as a separate code layer and then postulating about what a generic solution to a presentation layer for text based applications could look like if integrated into the firmware |
||||
| dddns Senior Member Joined: 20/09/2024 Location: GermanyPosts: 259 |
Sorry for my comment, it was the last non-technical one, I promise. |
||||
homa Guru Joined: 05/11/2021 Location: GermanyPosts: 459 |
I love this idea of FRAME. It reminds me of GW-Basic under DOS and the LOCATE command. There was always this text buffer and it scrolled to the top when printing to the last line! What cool one-line games were possible :-) So I'm all for it! Matthias |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7504 |
You'd have liked the Nascom machines then. The top line of text (there were no pixel graphics) never scrolled. It was because of the way the display was generated in TTL logic. It was pretty useful, if a little limiting as the display was only 16 lines of 48 characters anyway. The top line was line 16. I like this idea of having specific text handling. It's a bit like the hardware display generator chips but turbo-charged. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 529 |
Even if one had to start from ground up, I also think that it is a really good idea for other projects facing the same "problems". So yes I think it would be worth it! Greetings Daniel |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7504 |
It fills in a gap very nicely. Graphics handling is extremely good now but text handling can be a bit messy when you attempt some things e.g. PRINT@ and TEXT are great on a graphics display but you really need to write functions to translate character positions to pixels, which is messy and slows things down. A scrolling text window is a pain to write, especially if it isn't the full screen width. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| bfwolf Regular Member  Joined: 03/01/2025 Location: GermanyPosts: 72 |
Don't know, if this is the right thread for this idea?: In an other thread, somebody had the wish, to be able to have the console-output to appear simultaneously on a secondary device.. E.g. on the LCD and a COM port.. Perhaps it would be possible, to implement the ability, to have a "console output callback" which, if existant, would be called on every character? The callback should return the char(s) to be "printed" on the "standard console". If complete "redirection" would be active, the callback would return always a "" as result. Something like this: FUNCTION MM.OnConsoleOut$(ByVal OutChar$ As String) As String ' Minimal trivial implementation, a NOP ! MM.OnConsoleOut$ = OutChar$ END FUNCTION Such a callback would give the ability, to "filter" ("translate") the output stream, interpret e.g. VT100 ESC sequences, dublicate/mirror the output stream, ... Of course the implementation should be done in a way, that has minimal impact on the output speed, especially if no callback is installed/present. bfwolf Edit: Just remembered and read in the manual: There already exists the "sister" for this functionality, to "filter" the console input stream: ON KEY target or ON KEY ASCIIcode, target So perhaps it could be done in the same manner: ON CONOUT target Edited 2025-03-31 23:10 by bfwolf |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10067 |
Thought I'd have a play https://youtu.be/o_eBW-olACA CLS MODE 1 Colour RGB(white),RGB(blue) Frame create Frame box 0,0,79,39,RGB(white),double Frame 20,10,"The quick brown fox jumped over the lazy dog" Frame 20,11,"The quick brown fox jumped over the lazy dog" Frame 20,12,"The quick brown fox jumped over the lazy dog" Frame 20,13,"The quick brown fox jumped over the lazy dog" Frame 20,14,"The quick brown fox jumped over the lazy dog" Frame 20,15,"The quick brown fox jumped over the lazy dog" Frame 20,16,"The quick brown fox jumped over the lazy dog" Frame output Pause 2000 Do For i=1 To 10 Frame scroll 1,1,1,1,78,38 Pause 20 Frame output Next For i=1 To 20 Frame scroll -1,-1,1,1,78,38 Pause 20 Frame output Next For i=1 To 10 Frame scroll 1,1,1,1,78,38 Pause 20 Frame output Next Loop |
||||
javavi Guru Joined: 01/10/2023 Location: UkrainePosts: 436 |
Very nice!  With this, this PicoMite is already aiming for version 6.1 ! And will this text buffer work as a layer above the graphics? |
||||
| George H Newbie  Joined: 03/07/2020 Location: United StatesPosts: 31 |
Text mode game and demo effects would be very interesting with this functionality. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
