 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 : MMBasic for Windows - betas
  Page 4 of 30   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 9118 |
I don't understand this issue. I thought we had solved it with read save and read restore? |
||||
| Michal Senior Member  Joined: 02/02/2022 Location: PolandPosts: 123 |
Therefore, it is a solution for devices with access to storage media. Although almost all of them already have it, except for really minimal microcontrollers. By the way, you can also store large resources, music, graphics. Michal Edited 2022-03-04 22:22 by Michal |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Sorry Peter, I know I'm being a complete pain in the arse. READ [SAVE|RESTORE] only provides a single restore point and given that I managed to use that up without even trying it's only a matter of time before I want 2,3 ... N restore points so I wanted to get in early before READ [SAVE|RESTORE] had been cemented into the "standard". Look at my recursive madness in the previous post, READ [SAVE|RESTORE] can't help you here. Either you need MMBasic to maintain a stack of saved data pointers or you allow the programmer access to the pointer and allow them to manage the problem. I'm in favour of the latter because it provides more flexibility than the stack based approach. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9118 |
Or you need to write more sensible code ? Recursion and MMbasic are of limite utility in any case Edited 2022-03-04 22:26 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
That's just "name calling" Peter  . FWIW despite my playful demeanor on TBS I have over two decades of experience working on a very large software system and am generally regarded by my colleagues as sensible and conservative in my approaches.And that can be "fixed" by a process of gradual evolution of the code-base. A start in this direction would be to "fix" the global DATA pointer problem either through your own ingenuity or using the code that I have written and presented to you earlier in the thread. If this doesn't interest you (and nobody else cares) then you can remove the new READ [SAVE|RESTORE], IMO they don't fix the problem satisfactorily and I will have to adopt a different approach. EDIT: I thought READ [SAVE|RESTORE] was a solution when we originally discussed them, it was only after implementing them in MMB4L and having a play that I realised they didn't eliminate the problem they just "kicked the can down the road" a little way. Best wishes, Tom Edited 2022-03-04 22:41 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9118 |
The point I'm making is you are going beyond the bounds of what is sensible for a "simple" Basic interpreter. Rather than continue to extend it surely it is better to code within its limitations. I don't intend to be-little in any way your experience but this is Basic (the clue is in the name). I've just spent 2 hours re-writing FFT on the windows port because someone decided that the complex arithmetic handling in C wasn't going to be supported in C++ Lanugages are different and have different strengths and weaknesses and IMHO it isn't sensible to try and make all support a particular coding style |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
I can, and do accept that argument, however I have two counter-arguments for you: 1. Between us (but mostly you) we've ported MMBasic to two modern resource loaded hardware platforms (three if you count the CMM2 since that has "ridiculous" memory) so there is the potential and a natural desire to do more than might be achieved in 64K of street BASIC. 2. With the current state of MMB4W you've removed a piece of functionality available on both the CMM2 and PicoMite (and I suspect others including MMB4L) which is the ability to include "binary blobs" in BASIC code (albeit via a non-standard usage of CSUB). If you reinstate this or add some compatible equivalent (I have ideas if you want to discuss) then I would shut up about this ... I am probably going to shut up about this anyway soon so you could just wait me out  .Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
I'm not the one doing it, but it seems very unlikely you couldn't access the C implementation from C++. I wish you had asked ... and I had the time to answer  .Best wishes, Tom Edited 2022-03-04 22:53 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
I don't think it really matters about saving and restoring multiple DATA pointers. Yes, it's nice, but it's something that the user's program should, in theory, be able to look after with a bit of work. You need an array big enough for the depth you want to go and a "stack" pointer or two to it that get changed by the program. Wouldn't that work? For small amounts of data it should work fine even using normal DATA statements (referencing them in a similar way to my silly demo). It would get very clunky and inefficient for any quantity of data though because of the sheer number of DATA statements. The ideal would be to have a binary data block. It could be accessed with PEEK and POKE, which are already available. Edited 2022-03-04 23:12 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
Here's an implementation that I believe would work with minimal effort (just reuses CSUB code) and maximum backward compatibility and extensibility. On MMB4W (and MMB4L) introduce: RESOURCE [BASE2|BASE16|BASE64|TEXT] resource_name 00000000 01234567 89ABCDEF ... END RESOURCE and PEEK(RESOURCEADDR resource_name) When reading a file replace any CSUB and CFUNADDR keywords with RESOURCE and RESOURCEADDR. Note the required dummy 00000000 at the start of the RESOURCE block, that is needed for compatibility with CFUNADDR which historically always returns the address of the second 32-bit word of a CSUB. The "type" is just a recommended place-holder for future extension, if not specified the payload is expected to be in BASE16 format (EDIT: actually is there a byte ordering problem which would mean you might want separate BASE16 and legacy CSUB payload types?) On PicoMite, CMM2, etc.: When reading a file replace any RESOURCE and RESOURCEADDR keywords with CSUB and CFUNADDR. Best wishes, Tom Edited 2022-03-05 00:00 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Plasmamac Guru Joined: 31/01/2019 Location: GermanyPosts: 554 |
Why not load/save data @varpointer from array to work with prefilled arrays ? Plasma |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
Where is the data stored prior to loading it? There's no SDcard attached. Edited 2022-03-05 01:26 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 469 |
I was wondering why the default path is in your user folders rather than the folder that you have the MMBASIC.EXE in. I know you can set the default path and I have set it but why is that the default behavior. Is this more consistent with the way all the other MMBasics work? I only have the CMM2. I like to keep often modified files off my boot SSD and like to keep my files compartmentalized with the apps. |
||||
| Plasmamac Guru Joined: 31/01/2019 Location: GermanyPosts: 554 |
@william I get "illegal option" when I do OPTION USBKEYBOARD - use option keyboard us,300,200 Plasma |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
"Where is the data stored prior to loading it? There's no SDcard attached." For devices without storage the data arrays are with all the other DIM statements. It is no different to adding DATA statements but you can have random access to any item from any place. For example: DIM INTEGER DAT1(5) = (11, 12, 13, 14, 15, 16) DIM STRING DAT2(9) = ("","Sun","Mon","Tue","Wed","Thu","Fri","Sat","3.14159","42") the numbers can be extracted with VAL(DAT2(n)). Edited 2022-03-05 09:45 by phil99 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
Try 100 strings of 40 characters each. That would be small for most adventure games*. Then there's the map etc. too. Prefilled arrays are actually little different to my silly demo using DATA statements, just a bit less flexible and a bit faster. At least DATA can store several data types on a single line, whereas arrays can only store a single type each. * Crowther's original version of Colossal Cave had 700 lines of data for room descriptions (66 locations), messages, vocabulary etc. Woods expanded it to 1800 lines of data (140 locations). . Edited 2022-03-05 18:22 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4238 |
+1 I remember Basic as being an entry to learning programming. It was simple (had lots of limitations). Maybe I was smarter then, as I am now, but I remember barely opening the paper manual. It was simple enough to write code without a book. Only for graphics and sound (those where not standardised in the early days) you needed a manual. I2C... simple set of "OUT" or "POKE" statements. Now I am a little older, the charme of Basic remains. Simple .... but I have to open de user manual at many commands and functions, there are soo many options and parameters. And even with the PDF's that Geoff, Peter, and the forum makes I sometimes get lost (forget a comma somewhere). That is also why I suggested to keep HUMID in stead of BITBANG HUMID (pico mite I guess, since micromite uses HUMID(*)). As functionality of MMBasic expands people start adding, and the complexity grows. Whatever you decide for this discussion, try to keep it "KISS", don't invent datatype that are not already in MMBasic (integer, float, string (=character)). This is not C this is not C++, that is the whole point of having Basic at all. It is simple. And honestly (I know it is against all recipes for structured programming) MMBasic is still simple, you don't need to declare variables, simply use them. You can still "hack together" a piece of code with goto's. With or without line numbers. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4040 |
I appreciate the sentiment but think it overlooks a couple of points: 1. Use of BASIC is practically mandated on the 'mites. Sure you can use C, but you have to cross compile, and not all of C is easily available due to CSUB limitations. Additionally using C reduces the audience of 'mite users who can understand the result. 2. The 'mites are orders of magnitude more powerful than the machines BASIC was designed for. It would seem sensible to take advantage of this power with a few carefully chosen extensions to BASIC - which historically has always proved to be a family of related languages than a standard. Note these arguments only apply to MMB4W in so much that it sets out to simulate the CMM2. If you just wanted to write Windows programs then MMB4W is, and probably always will be a silly choice. Best wishes, Tom Edited 2022-03-05 19:56 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
@Mixtel90 I agree that where there is a lot of data that only requires sequential access DATA statements are the way to go. However if some of it requires access from more than one part of the program or random access then those parts of the data can be in arrays, instead of changing the way DATA works. Although arrays can hold only one data type there are commands for type conversion. eg. DIM STRING DAT2(9) = ("","Sun","Mon","Tue","Wed","Thu","Fri","Sat","3.14159","42") the numbers can be extracted with VAL(DAT2(n)) If absolutely necessary, as a last resort, text can be put in a numerical array as ASCII character numbers and re-assembled into text. I do rarely do the former and can't remember doing the latter, writing the program to allow different types to be in different arrays. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6792 |
The way RESTORE now works in MMBasic is only very slightly non-standard. The only difference from "standard" BASIC is that when using "RESTORE n" n can be a variable, not just a label. That is a small but powerful change as it allows random access of DATA lines, not just sequential. It removes the restriction of having to read the data into arrays before it can be accessed quickly. If you want to access it with pointers then fine, use as many as you like. It's also completely invisible to programs written in "standard" BASIC. The main downside is that DATA lines need to have line numbers as RESTORE n is still looking for labels. Neither arrays nor DATA statements can replace an embedded binary block if you want more than 100 bytes or so of data. It can be used for whatever the user wants, completely under their control, with no space lost for variable names, string lengths etc. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 4 of 30 |
|||||
 Print this page |
