search

sanni / cartreader

A shield for the Arduino Mega that can back up video game cartridges.
GNU General Public License v3.0
2.15k stars 219 forks source link

"Sketch too big" with all modules enabled #979

Open TankedThomas opened 2 months ago

TankedThomas commented 2 months ago

OSCR firmware version

13.1

OSCR hardware version

HW5 Rev6

Attach OSCR_LOG.txt file here

No response

System used

all/none/doesn't matter

Describe the issue.

I'm trying to flash my Mega 2560 Pro but having trouble with it running out of space when all modules are enabled. I haven't built the OSCR yet - I'm just setting up the Arduino in advance.

I'm using Windows 11 and have tried both the portable Arduino package from the releases as well as my own installation (2.3.2, with the correct libraries installed albeit newer versions where available). Both give almost identical errors.

Portable (1.8.19):

text section exceeds available space in board
Sketch uses 333716 bytes (135%) of program storage space. Maximum is 245760 bytes.
Global variables use 8409 bytes (102%) of dynamic memory, leaving -217 bytes for local variables. Maximum is 8192 bytes.
Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it.
Error compiling for board Arduino Mega or Mega 2560.

Installed (2.3.2):

Sketch uses 336670 bytes (132%) of program storage space. Maximum is 253952 bytes.
Global variables use 8436 bytes (102%) of dynamic memory, leaving -244 bytes for local variables. Maximum is 8192 bytes.
Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it.
text section exceeds available space in board

Compilation error: text section exceeds available space in board

This is using the same Config.h for both, by the way, so it's odd the sizes are slightly different (this difference is repeatable). If I disable most of the modules, it'll compile and upload successfully, but enabling more than about half of the modules will make the sketch too big for the Arduino.

I had a look at issues #574 and #619 but it looks like the issue should have been fixed previously, so I'm not exactly sure what's going on here. Maybe I still need to ISP-flash a new bootloader onto the Mega 2560? Or perhaps it's related to the specific Mega 2560 Pro unit I bought?

When reading from the device (Tools>Get Board Info), I get this: image I'm not sure that "Unknown Board" matters because I've seen this on other clones that still work fine. I don't have photos right now but the board looks physically correct - I don't think the Atmel chip is a counterfeit, and it has 5 SMDs in the right spot, etc.

Probably unrelated but the portable Arduino IDE spits out others errors prior to the aforementioned ones when using the portable IDE. I've attached a full error log output from the portable IDE (the installed IDE's output is only the errors I pasted above) as well as my Config.h just in case. Config.h.txt arduino_1.8.19_portable_error_log.txt

Apologies if this is answered somewhere. I did look but couldn't find any real info other than the aforementioned issues. Hopefully it's just something simple I'm missing.

sanni commented 2 months ago

You can only enable a few extra modules or else the Arduino Mega will run out of available memory and/or program space. Try to stay below 90% dynamic memory.

TankedThomas commented 2 months ago

Is there no way to have them all enabled, maybe using a different Arduino with better specs? Even disabling all the systems I won't use, it's still slightly too big. Just seems like a waste to have a cart reader for all these systems but it can't really do all of them at once.

PsychoFox11 commented 2 months ago

I deal with a LOT of systems, and have more adapters than slots. I do see you're on the current 13.1 - the latest master build of 13.2 has a lot of cleanup allowing for more at once. I can enable all mine now (though I may be toying with more than 90%, I'm not sure - no issues yet). Before that, I'd pick something I wasn't planning on dumping for a while, usually N64, then enable some others.

Even with all the systems I dump for, I can usually identify a few I know I won't be doing for a while should I need to disable them. Unlikely I'll be doing 12 consoles in the same week.... However if I do, well, I have 2 OSCRs cause if you're doing that much dumping, you'll run into times one needs some work and you're glad you have another. But while they both work, I can keep them flashed with different stuff.

Though, since the recent cleanup on the 13.2 version that hasn't had a regular release yet, I've been using all I have slots and adapters for with no issue, the footprints were decreased a lot. If I do run into an issue I'll disable N64 until I get more N64 to dump lol. If a random cart does fall into my lap, flashing takes maybe 2 minutes - just keep a PC nearby!

I currently have enabled: All slots for dumping (not anything special for flashing, I don't do that), on the HW V5. -Atari 2600, 5200, and 7800 -PC Engine -Watara Supervision -Intellivision -Colecovision -Odyssey2

So far, so good! But I worked for a long time just disabling N64 as needed.

Ancyker commented 2 months ago

Is there no way to have them all enabled, maybe using a different Arduino with better specs? Even disabling all the systems I won't use, it's still slightly too big. Just seems like a waste to have a cart reader for all these systems but it can't really do all of them at once.

There isn't a better 8-bit AVR than the ATmega2560. You can reflash it with different options enabled when dealing with different systems. People who often deal with more systems than can be enabled at once will sometimes build multiple OSCRs.

HW7 resolves this problem, but will not be available for some time yet. After I finalize the new HW5 revision I'll begin working on HW7's prototype boards -- the schematics for most of the sections are done (USB, main power, and cart IO). I don't expect it to be ready until next year.

Cephiros commented 2 months ago

I deal with a LOT of systems, and have more adapters than slots. I do see you're on the current 13.1 - the latest master build of 13.2 has a lot of cleanup allowing for more at once. I can enable all mine now (though I may be toying with more than 90%, I'm not sure - no issues yet). Before that, I'd pick something I wasn't planning on dumping for a while, usually N64, then enable some others.

Even with all the systems I dump for, I can usually identify a few I know I won't be doing for a while should I need to disable them. Unlikely I'll be doing 12 consoles in the same week.... However if I do, well, I have 2 OSCRs cause if you're doing that much dumping, you'll run into times one needs some work and you're glad you have another. But while they both work, I can keep them flashed with different stuff.

Though, since the recent cleanup on the 13.2 version that hasn't had a regular release yet, I've been using all I have slots and adapters for with no issue, the footprints were decreased a lot. If I do run into an issue I'll disable N64 until I get more N64 to dump lol. If a random cart does fall into my lap, flashing takes maybe 2 minutes - just keep a PC nearby!

I currently have enabled: All slots for dumping (not anything special for flashing, I don't do that), on the HW V5. -Atari 2600, 5200, and 7800 -PC Engine -Watara Supervision -Intellivision -Colecovision -Odyssey2

So far, so good! But I worked for a long time just disabling N64 as needed.

Like him abpve me, I also have 2 oscr's but ive customized one. One oscr is normal and i have additional systems added, and the second oscr is strictly 5v with a gamegear slot with a 7 in 1 on top that handles all 4 atari systems, c64, odyssey2, colecovision and intellivision, which lets me use all the remainder of the systems with adaptors on the first unit. Of ypu really do have that many systems, I do believe 2 devices is the right way to go.

smesgr9000 commented 2 months ago

sadly - It is not possible to enable to enable all. ATM the code uses ~117% depending on other options. At 13.1 it was ~135%. So using the latest version will improve the situation alot. I'm confident with further optimization to get down to ~110% maybe 100% (things to try out would include to outsource all string into a SD file, move blacklist handling of MD to a file). But only if no other systems/other features are added which I'm pretty sure will happen sooner than latter mysterious foreshadowing.

Ancyker commented 2 months ago

things to try out would include to outsource all string into a SD file

I tried this using a JSON file. It does work, but it makes navigating the menus noticeably slower but not so slow that they are unusable. It's at least a few hundred ms though.

smesgr9000 commented 2 months ago

yeah i think it would require an cache mechanism.