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}: Any possibility of MM.INFO$(CURRENT) + PATH
Author | Message | ||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4047 |
Hello Peter, I've been umming and ahing about asking for this (again) for a while and decided to bite the bullet before a new release is completely set in stone. I know it would cost ~128 bytes but could you please reconsider adding MM.INFO$(CURRENT) and MM.INFO$(PATH) to the PicoMite family. The general reason is that it would allow a program to locate any additional file resources it requires relative to its own installation location. The specific reason is that my MMBasic firmware tests rely on it. I recognise the limitation that for programs in flash you would need to return *magic* values, perhaps just "FLASH1", "FLASH2", etc. I would do it myself, either "properly" or in a firmware tests specific "hack", but even assuming you would accept my implementation I'm not going to do it in time for the 5.07.07 release ... and I have a gut-feeling that given the "finished" nature of the PicoMite that may be the last non-beta release for a while ... you'll probably prove me wrong . Best wishes, Tom Edited 2023-04-15 23:24 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9139 |
The Pico runs all programs from flash so "current/path" have no real meaning. RUN "fred" is the same as LOAD FRED: RUN after the load or, more obviously, a reboot the concept of "fred" has completely disappeared but RUN will still work. The only simple thing I can think of is to prepend the filename as a comment to the program when you load it from file store (similar to CMM2). Then a MM.INFO could return it as a string - any good? |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9139 |
Try this PicoMite.zip Anything which causes a program to load from disk will prepend the filename into the program as a hidden comment. MM.INFO(CURRENT) and MM.INFO(PATH) will then work exactly like CMM2 except that if the program has been created with EDIT and therefore only exists in its current form in flash memory they will return blank LIST fname$ won't show the hidden line if it exists XMODEM S won't send the hidden line if it exists FLASH LIST won't show the hidden line if it exists As above EDIT is the odd one: EDIT won't show the hidden line and saving the program will not restore it or create anything in its place as the program may now be unrelated to anything stored on disk. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4047 |
Thanks Peter, I will try and test it tonight. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9139 |
NB: Final version will return "NONE after NEW or EDIT to be more compatible with CMM2 |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4047 |
Does EDIT have to clear the path? Can it not cache and restore any existing value since that is likely to still be the correct path for the program to resolve assets from. What does SAVE do? Ideally it should update the path comment ... which may mean preallocating enough space in the magic comment for the maximum path length, the aforementioned 128 bytes. Thanks, Tom Edited 2023-04-16 05:12 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9139 |
It is what it is - no changes Save strips the comment as it gets re-created on load. Otherwise what happens with Copy etc. Edited 2023-04-16 07:27 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4047 |
You'll forgive me if I make one more attempt to persuade you, but no hard feelings if you still refrain, what you've done seems to cover the use-cases I really care about . EDIT If I understand it correctly when running EDIT the program being edited is in RAM whilst the original version is still present in the "program" Flash ? If this is so then that means the original path comment is present in the Flash when the Editor exits in which case can it not be preserved when the rest of the "program" Flash is overwritten with the tokenised contents of the Editor/RAM ? SAVE I think the correct behaviour ("correct" being defined as what matches my expectation ) is that after: SAVE "foo.bas" The contents of the "program" Flash should be the same as if the user did: SAVE "foo.bas" LOAD "foo.bas" And given that SAVE isn't a performance critical operation I wouldn't even mind it being implemented as SAVE followed by LOAD - YMMV. Thanks again, Tom Edited 2023-04-17 00:41 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9139 |
Edit: absolutely not. The program in memory after the edit is not what is on disk. If info returned the disk file it would imply that they were the same. Save: doubles the number of flash writes and as only you will ever use the functionality it doesn't make sense to both slow the save down and increase flash wear. |
||||
Print this page |