SystemConvert and _maxram

Jerry Messina · Post by **Jerry Messina** » Thu Mar 24, 2011 11:41 am

I'm curious. How does SystemConvert determine the '#variable _maxram' setting? Or even the '_ram_banks'?

I always thought that you used the *.dev and asm *.inc files to gather up the info, but I don't see any way to tell from those files. Are you parsing the .PIC files?

One of the reasons I'm asking is that some of the SF .BAS files have(had) a '#variable _maxram_contig' setting, and it seems that was added by hand? Running SystemConvert to regenerate the files doesn't include this setting.

David Barker · Post by **David Barker** » Thu Mar 24, 2011 1:33 pm

> #variable _maxram_contig

Yes, added by hand

Jerry Messina · Post by **Jerry Messina** » Thu Mar 24, 2011 1:38 pm

Let me ask this then (I'm pretty sure I already know the answer, but just in case).

Is there any '#option' or '#variable' setting that would let me exclude an arbitrary ram memory region from the compilers allocation scheme, sort of like a 'reserve_ram' setting?

David Barker · Post by **David Barker** » Thu Mar 24, 2011 1:41 pm

You can reduce the size, but you cannot deselect blocks of RAM. Out of interest, why do you ask?

Jerry Messina · Post by **Jerry Messina** » Thu Mar 24, 2011 2:02 pm

I've been playing around with the USB library, and since you originally wrote that a number of things have changed. It seems every time Mchip introduces a new USB chip, they change the way it works, and the various "hacks" are getting hard to consolidate.

With the advent of the "J" and "K" series, the reserved ram where the BDT table needs to go has changed locations (it can now be $200, $400, or $D00), and on some of the parts (like the "J") you can actually put the rest of the USB data anywhere in ram, and not just in that reserved block.

If you could tell SF to just exclude a region from the allocation scheme so that it's memory wasn't always contiguous, it would make dealing with these chips a lot easier and you wouldn't be forced to set the top of ram limit at the USB BDT buffer page, losing all the remaining available ram in the part. It would also let you reclaim some of the USB memory for general use on the parts that have 1K of USB ram without having to do all the allocations by hand using "absolute" declarations.