 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 BASIC memory commands
| Author | Message | ||||
| Mark Regular Member  Joined: 26/11/2022 Location: United StatesPosts: 85 |
The commands MEMORY SET and POKE seem to do the same thing, i.e. write data to arbitrary locations in memory. Is there a difference other than the syntax? Obviously you need to be careful where you write to memory so you don't overwrite other important data. I assume one way is to write to the address of variables, knowing that you are modifying those variables. But, is there another area in the memory space that is safe to write to? Finally, is there an area of memory that can be written to in one program and read from in a chained program to allow some inter program communication? I know about VAR SAVE / VAR RESTORE, but this saves data to flash to make the data persistent. I don't need data persistence. Once the chained program has retrieved the data, it's no longer needed. I could pass the data via a file (my Pico has a SD card), but RAM would be nicer. Thanks, Mark |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3481 |
Chained programs retain variable values, so you could just write a string which contained the values you wanted, and decode that string in the chained program; or you could fill an array; or you could just use the variables you want. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8305 |
To be safe, there are no memory areas that are safe to write to other than the variables area and the frame buffer. Anywhere else will upset something. That will, in turn, upset you. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
lizby: yes, chained programs retain variables, but my files are on the SD card so I'm using RUN not CHAIN and that's erasing variables mixtel90: Thanks for the response. Since I'm using a SD Card, I'm using RUN rather than CHAIN and variables and I assume the framebuffer are cleared. I remember with my first computer (an Apple][) some of the magazines had programs where you POKE'd numbers into memory to load some machine language and it was always an issue about where it was safe to POKE. Mark |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3481 |
You could write a file to the flash file system, and then read it back. I don't know how speedy your program needs to be, but that isn't slow. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8305 |
All you can do, Mark, is write your variables to a file (on SD o flash) and reload into the new program. There isn't anywhere you can poke stuff. The fastest way to switch programs is probably to use FLASH CHAIN n, which is very fast. It doesn't need any special handling for the variables. "Use the flash, Luke..." The next fastest is to write and read to the flash file system. Do NOT do random POKEs on a PicoMite. You get headaches. :) If you POKE into variables they will be cleaared on RUN, as is the frame buffer (display). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Andy-g0poy Regular Member Joined: 07/03/2023 Location: United KingdomPosts: 81 |
Hello Everyone, I just joined the forum, after a post in the GQRP club forum pointing to a Utube video about the picomite VGA, from that I found the non VGA pico mmbasic. This looks to be a very effective development system for all sorts of things. I just have to remember the my basic programming after 40 - odd years ! Poking into memory was very common, I was a CBM user, the PET and later C64 and C128. In those machines there were two areas of memory used for the tape cassettes. Very few machines had two tape drives fitted, so the 2nd tape buffer was generally a safe place to load in some machine code. The tape buffer was at 033A - 03F9 (826 - 1017 decimal ) Data statements and poke was the common method. The code would be accessed via a SYS(826) call in CBM basic. If a larger memory space was needed, then it was possible to poke a value into a couple of bytes in zero page that set the upper limit on the memory that the basic OS could access, leaving a "safe" area beyond to use. Other computers of the era sometimes had commands to directly set the memory top - possibly that was the BBC, but I did not do much work on that machine directly. Also BBC basic had a built in assembler anyway, so it generally took care of any machine code requirements. Another method I have seen used was to create a large variable of some sort and fill it with 00 or ff data, then the address of that variable was found and the memory it's data used was poked with the machine code. It may be possible in mmbasic to use PEEK(VARADDR var) to find such variables to be able to use that method. Scanning through the mmbasic commands, it looks as if the CSUB command is the way to go if you want to implement some machine code routines. It may also be possible to use this to set up a "safe" area of memory. If the PEEK(CFUNCADDR cfun) returns the address of code set up in the CSUB command then that should provide a way to access it. This is rather beyond my current understanding of how mmbasic works :-) Andy |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4149 |
Welcome. Yes, works. Er - NO. You can fill it with DATA. Modern CPUs are not necessarily willing to execute data as code. It's super ugly, too, and probably unnecessary. Can do. Yes. However, all of memory is already available and the CPU is very fast so generally you don't need to go messing around like the above. John Edited 2023-03-09 17:55 by JohnS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8305 |
Welcome, Andy. :) The difficulty that started this thread was that the PicoMite is fine for poking a bit of data into if you need to (e.g. a string), but getting it to retain data when a program is started with RUN is something else. RUN clears the variables area. FLASH CHAIN is the way to go, chaining programs stored in the flash slots but the OP wanted the programs to be stored on SD card and there is no chain function from those. A CSUB has to be loaded and run by the program, it doesn't transfer to a different one. The memory map of the PicoMite doesn't really correspond to the old 1980's pattern of a single contiguous block of 64k (or whatever). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
