 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 : MMC: Some Newbie Questions
| Author | Message | ||||
Questarian Newbie  Joined: 06/04/2015 Location: United StatesPosts: 7 |
Hi! I've had an MMC for a month or two now and I just love the thing... and as a newbie I have a couple questions... which I apologize for if they've been asked-and-answered before. PEEK & POKE Recently, when I'm writing in a drop down menu, I've used PEEK to read the contents of the screen off to an array and then, when I'm done with the menu, POKE them back to restore the screen. It worked great in mode 1 but in mode 4, 240 x 216 8 color, there appears to be a couple extra bytes on the left side of each line. The video screen bytes line up in the 480x432 res modes and it threw me until I realized they were there. After hunting forum posts, if I've read it correctly, the video memory is arranged in 32 bit words, so I assume the "extra bytes" are just the unused portion of the first word in the line of screen memory. When the unused portion is poked it does display partially, there appears to be a number locked bits that can't be written to, and I've had a few ideas on what I could do with them, so is it safe to use the unused bits? Like the video and variable memory, is there any what do peek/poke sprites and fonts? Memory: I'm a bit foggy about how memory is allocated in the MMC... is program and variable memory separated? Etc. While coding I've run out of program space, or at least not enough space to open it in the editor , while appearing to still have a lot free variable space. Opinion: as part of building my MMC tool box, and to get back up to speed, I've been working on sprite and font editors. I started out with the editors being entirely memory based but as I worked on it I realized that I didn't want to limit the size of the set, so I cached the sprite/font data to a random access file. While it did slow things down a bit, I have been able to streamline things so it's acceptable (though rendering large res fonts needs a bit more tweaking), and it's actually ended up making the code simpler, a bit faster in some cases, and way smaller. Doing it this was means I can create and edit sprite/font sets of any size without restriction... So I can create sprite/font files larger than be loaded, for whatever use that is  The question is this: I was familiar with the limitations of floppies back in the day but I'm not as versed in SD media, so how much file access on an standard SD card is advisable? Once I get my tool set complete, I'm going to code a couple graphic RPG's which will make extensive, almost constant, use of random access files and I don't want to create a card eater.
-John- |
||||
BobD Guru  Joined: 07/12/2011 Location: AustraliaPosts: 935 |
John If you can read C code then you can get the source code for MMBasic here. That source may answer your questions. Make sure you get the code for your machine. You should consider getting MM Edit which is an offline editor. It can load the program at run time and I believe also compact your program if you want. It may give you more space to work with. I wondered what an RPG was. The first thing that came to mind was a Rocket Propelled Grenade but I thought that was unlikely given the context. Bob |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6271 |
My first thought for RPG was Reverse Polish Generator as used in early calculators. Not being a gamer, Role Play Game took longer to come up with. The SD cards do wear out eventually but not as quickly as floppies so you should be OK. Jim VK7JH MMedit |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2934 |
Hi John, Yes, I agree that the MMC is a great little gadget and love it too. Do you know which PIC your MicroMite is? i.e. is it a MX150 or MX170? If you're not sure, then do you know which version of MMBasic you have. If you have 4.6 (or higher) then you have a MX170 which has more than double the memory space of the MX150. Upgrading from a MX150 to a MX170 will certainly help your 'memory space' issue. If you're up to the challenge then add a MX470 then it really will be 'super-charged'. I have taken this extract from Geoff's User Guide for the MEMORY command: Lists the amount of memory currently in use. For example: Flash: 21K (35%) Program (805 lines) 1K ( 1%) 2 CFunctions 1K ( 1%) 4 Saved Variables 37K (63%) Free RAM: 9K (16%) 5 Variables 18K (32%) General 26K (52%) Free Notes: General memory is used by serial I/O buffers, etc. Program memory is cleared by the NEW command. Variables and the general memory spaces are cleared by many commands (eg, NEW, RUN, etc) as well as the specific commands CLEAR and ERASE. Memory usage is rounded to the nearest 1K byte. When a program is loaded it is first buffered in RAM which limits the maximumprogramsizeto53K. MMBasictokenisestheprogramwhen it is stored in flash so the final size in flash might vary from this. Take a look at the last point! You raise a good point about running out of memory (to open program in the editor but to still have variable space). Hopefully GeoffG (or anyone else with the known information) can tell you more about exactly the memory 'allocation' works and hence why you are experiencing this issue . . . . WW EDIT: As highlighted by another member's PM to me: my response above assumes you are referring to Jeff's MicroMite Companion as opposed to Geoff's MaxiMite Computer 
|
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3285 |
Hi John, In mode 4 MMBasic does not write to the first 16 pixels of each scan line. This is to correctly line up the left hand margin on the display. You can POKE to this part of the video buffer but all you will do is mess up the display. Memory in the Colour Maximite is allocated from a central pool for the video buffer, program, variables and general use (eg, coms buffers, etc). So, more program, less space for variables. You will be unlikely to reach the endurance limit of an SD card. In this thread a Back Shed member tested a card and it lasted a LONG time. Geoff Geoff Graham - http://geoffg.net |
||||
| Questarian Newbie Joined: 06/04/2015 Location: United StatesPosts: 7 |
Ohh....Sorry, it's the Color MaxiMite, I have both and I completely zoned on which end of the "MM" the "C" should go... 
-John- |
||||
| Questarian Newbie Joined: 06/04/2015 Location: United StatesPosts: 7 |
Hi Geoff, Thanks for the info! It's been a long time since I've programmed anything this extensive on a machine this size and it's been a fun challenge trying to get as much in as possible. It's good to know SD are fairly durable... But, As with all storage media, I've had some last for years and then others for hours, so I have to remind myself to make backups... I've had to reinvent the wheel more then once having forgotten to do that
-John- |
||||
| Questarian Newbie Joined: 06/04/2015 Location: United StatesPosts: 7 |
Thanks, I'll take a look the MMEDIT... though half the fun for me is the immediacy, and simplicity, of editing the code right on the device. I have CMM setup on a little rolling typing table and whenever I have a moment pull it over, fire it up and loose five or six hours... It's great fun, I haven't done that since the 80's. Well, it's the internet so "rocket propelled grenade" or "roll playing games" are both valid guesses.
-John- |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
