 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 : Color Maximite 2 - How memory is organized
| Author | Message | ||||
| dvanaria Newbie  Joined: 04/03/2018 Location: United StatesPosts: 15 |
I've been getting up to speed with the Color Maximite 2 for the past few weeks (finally had time to solder the kit together). It's working great except for some minor issues like flickering graphics - I've ordered a few more components to fix this (8 MHz external oscillator and a 100 nF SMD capacitor). I'd like to understand better at how the system organizes its three separate memory areas: 2 MB Flash memory (internal to the ARM STM32 chip) 1 MB RAM (also internal to the ARM STM32 chip?) 8 MB SDRAM (on reverse side of Waveshare daughterboard) I can't really understand how the system works, after reading the user manual and programming manual. Here's my best guess, but I was hoping the community here could clarify this for me: 1. MMBASIC Firmware (835 KB .bin file for current version 05.07.01) gets loaded/saved in the 2 MB Flash memory since this is non-volatile memory. This includes the MMBASIC interpreter and OS commands like FILES, CHDIR, etc. 2. BASIC programs have a maximum size of 516 KB, and these programs also live in the 2 MB flash memory area. Data is stored on the external SDRAM chip so has up to 5 MB of storage available. Or is the BASIC program loaded into the internal 1 MB memory space? 3. Video memory depends on the Mode being used, but PAGE 0 is always allocated to fast (internal) memory, and additional pages are allocated in SDRAM. The GPU part of the STM32 chip reads from whatever the current page is. Thanks for any help on this, I'm pretty sure I'm off on my understanding here. |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
AFAIK: When you edit a program the editor is loaded into RAM. The edited file is on the SD card in ASCII format. When you run the program the editor is removed and the program is moved into battery-backed RAM in a tokenized format and then run (which is why there is a bit of a delay). The space previously used for the editor is now used as the variables area. MMBasic is mostly in flash but I think some time critical routines are copied into RAM. The off-module flash is relatively slow to access so is used for screen storage in some graphic modes. I'm no expert on this, but I think I'm more or less right. :) Even when you know how the system works there's not a lot to play with in respect of the memory areas. MMBasic has specific commands for PEEK and POKE and that's about all you can do without breaking something. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10628 |
Don't have time to respond properly as currently traveling but Mixtel is pretty much completely wrong for the CMM2. Will respond during the weekend unless someone else gets it right first. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
:) I just knew it..... Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9760 |
I think Mick's description is how the PicoMite does things? I might be wrong on that also, so we'll wait for the head cheese to give his reply over the weekend. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
I think I might be closer to the PicoMite, come to think of it yeah. But that does edit entirely on the chip. I discovered that I got the CMM2 editor wrong at least. :) It allocates a load of space (still 512 bytes?) for every program line to allow for insertion, horizontal scrolling etc. I always thought it edited to a file on the SD card though (which is why you have to have one) and pre-processed it into RAM at run time. That allows it to use include files. Of course, it could equally well be flash. I await with bated breath... :) At the end of the day, people seem to ask this sort of OP question because the poster would like to PEEK and POKE memory addresses in user program space, usually above a TOPRAM address or something like that. That's something you can't trust in MMBasic as it doesn't use the same sort of memory model as a 6502 or Z80 or whatever. You do get to play in the variables area though. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4147 |
Typically a user would not need to know. For those with more interest, maybe request the source (which includes the data about where things are placed). Relying on the info in a program is liable to make it tougher to port to a different MMBasic platform (e.g. PicoMite), of course. John |
||||
| dvanaria Newbie Joined: 04/03/2018 Location: United StatesPosts: 15 |
Thanks for the information, I’m more interested in just understanding how the system works at this (lower) level, just for my own understanding, not to try to manipulate data directly using peek/poke (with the exception of reading screen data directly for collision detection, potentially). It’s a fantastic platform in my opinion, and just like the 8-bit systems of the early 80s, it makes me want to know how the whole system works under the hood. Plus I was just confused by the ARM processor itself, how it has 2 MB of flash memory and also 1 MB of memory (on-chip), and how MMBASIC utilizes that setup. Thanks again for the help. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4147 |
The full details of the CPU are freely available. As I mentioned, you can request the MMBasic source as well. John |
||||
| dvanaria Newbie Joined: 04/03/2018 Location: United StatesPosts: 15 |
I've done some more research and the picture is getting a bit clearer. Most of this I got from the Silicon Chip articles from July 2020, and from just experimenting with the system: 1. The STM32 CPU maps the external 8 MB RAM into its address space, so MMBasic can use it in a similar way to the 1 MB internal RAM. 2. Programs are edited directly on the SD card, and when executed they are pre- compiled (in a sense) into a condensed, optimzed format into the flash memory area, and run from there. 3. The MEMORY command on my system shows the following: Program: 516 K free Data: 5344 K free The program will reside in flash memory to be executed. That number, 516 K, refers to how much available flash memory is there to hold a program. The rest of flash memory holds the MMBASIC firmware. And the "Data" area refers to RAM (both on-chip and external) that are mapped onto the same address space (from the CPU's perspective). This will hold video pages, buffer space to be used while editing, and general memory space for BASIC programs. I might not have the exact details right but I think I'm gaining a better understanding of the system architecture. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10628 |
dvanaria You have got it pretty much right. The 2Mb of flash is divided 1Mb for the firmware and the saved options (0x08000000) and 1Mb for the active program (0x08100000). The active program can be up to 512Kb in length and to allow wear levelling can be placed anywhere within the 1Mb area (see OPTION FLASH) 512K of the onchip RAM (0x24000000) and 3MB of the external RAM (0xD0000000) are used for video memory. Video Modes preferentially use the onchip RAM for the display pages if possible (screen size < 512KB). Type LIST PAGES to see which video page is where in RAM for the current video mode. The STM32H743 has several non contiguous areas of other RAM and the firmware uses these in various ways. A 64Kb section is used for the variable hash table and the data for simple variables (0x38000000) 32Kb is used for the function and label hash table (0x30040000) 256Kb of internal RAM is used as high speed MMBasic heap (0x30000000) 5Mb of external RAM is used a slower speed MMBasic heap (0xD0300000) Heap is used for things like strings, arrays, framebuffers, audio buffers, etc. 64Kb of fast ITCM RAM is used for cacheing interrupt routines and other critical H/W I/F routines (0x00000000) 128Kb of fast DTCM internal RAM is used for the C stack and MMBasic firmware variables (0x20000000) There is 4K of battery backed RAM which is used for saved variables (VAR SAVE/RESTORE) (0x38800000) Editing is done by copying the ascii program from the SDcard into the slower speed heap. When exiting the editor the ascii program is written back to the disk. If you choose to run the program it is tokenised from the SDcard into heap (including any include files). This is then compared with the program flash memory and this is overwritten only if the program is changed - the heap is then cleared. This comparison is important to ensure that changes to include files will trigger a re-load into flash even if the main program hasn't changed and to minimise flash writes where they are not needed. The STM32H743 has both data (RAM) and instruction (FLASH) H/W caches (16Kb each). The use of these is transparent to the program but together they achieve close to zero wait-state access to both RAM and FLASH memory. However, the firmware has to take care to flush the data cache when things like DMA are operational. Hope this makes sense |
||||
| dvanaria Newbie Joined: 04/03/2018 Location: United StatesPosts: 15 |
Thank you, that was exactly the kind of detail I was hoping to learn. It's mostly just to satisfy my own curiosity how MMBasic utilizes memory on the Color Maximite 2. I've consolidated the memory map below. Hopefully there aren't any typos in the addresses I've listed. Let me know if any corrections are needed. Thanks again for everyone's help: 0x00000000 to 0x0000FFFF 64 KB fast ITCM RAM cacheing interrupt routines 0x08000000 to 0x080FFFFF 1 MB flash memory MMBASIC firmware and save options 0x08100000 to 0x081FFFFF 1 MB flash memory active program (512 K max size) 0x20000000 to 0x2001FFFF 128 KB fast DTCM RAM C stack, MMBasic firmware variables 0x24000000 to 0x2407FFFF 512 KB on-chip RAM video memory 0x30000000 to 0x3003FFFF 256 KB on-chip RAM high speed MMBasic heap 0x30040000 to 0x30047FFF 32 KB function and label hash table 0x38000000 to 0x3800FFFF 64 KB variable hash table, variable data 0x38800000 to 0x38800FFF 4 KB battery backed for saved variables 0xD0000000 to 0xD02FFFFF 3 MB external RAM video memory 0xD0300000 to 0xD07FFFFF 5 MB external RAM slow speed MMBasic heap |
||||
electricat Senior Member  Joined: 30/11/2020 Location: LithuaniaPosts: 299 |
I think it would be worth to add this info to Maximite2 user manual somewhere. My MMBasic 'sand box' |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
Maybe an "Inside The Colour Maximite" publication? No - I'm not volunteering to do one. I've already proved that my knowledge of these machines is far too limited. lol IMHO it doesn't belong in the user manual really as I don't think there's much the user can do about it. 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 |
