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.
SystemConvert and _maxram
Moderators: David Barker, Jerry Messina
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
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.
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.