First I need to rant: One of my big pet peeves I see repeated over and over again is the duplication of effort in software. Someone creates something that works relatively well, then someone comes along and essentially ignores all of that code because they want to do it “better.” It’s very frustrating and in the context of Marlin just fractures the code. 
There are features I see in this repo that might have been minor additions or modifications to base Marlin that instead got replaced or partly duplicated which help to understand when editing.
For the interested, these include:
- Job queuing and print status (see print_control.cpp, system.cpp, J1.cpp)
- Filament runout detection (see Snapmaker’s filament_runout.cpp and PrintControl::filament_check)
- Power loss recovery (see the snapmaker power_loss.cpp)
The last two of these are owing to the hardware @Mechanikus spotted in his teardown.
Filament runout: The filament runout customization is due to the analog encoder on the filament runout. None of the standard Marlin filament check code is used. Instead a count stepper runs on the Snapmaker runout sensor, which is periodically polled while printing.
But where? It appears this isn’t interlocked on the main board side anymore. At least the code for it is there, but it seems like code to poll it is commented out? Perhaps it’s now periodically monitored by the screen under normal printing from the screen. In any case, polling at the main board is easily re-implemented if needed.
I got my own polling going by summoning PrintControl::filament_check() from PrintControl::loop called by the J1 timer, when the system status is “printing.” It wasn’t obviously called anywhere else otherwise, though it’s possible I missed it.
Power loss recovery: I have not looked deeply into this yet, but I think is why I didn’t get M600 working. (M600 checks and stashes the current file location through power_loss.) I did initialize power_loss, but pretty sure I didn’t maintain it properly. This also led to it falsely offering to recover every time I restarted the printer. 
Power loss recovery also has its own entire, custom implementation. Again, this includes special hardware. As Mechanikus noted, there’s a special 5V board inside the printer that briefly holds some power in the event power is lost. It’s used to buffer the current print status in the event of a failure.
A whole structure including the print file, line number, some printing status, etc., is maintained line by line during printing. And needs clearing upon completion of a print job, surely. On restart this structure is apparently checked, and offered to resume if needed.
Job queuing: Holy heck… So I haven’t looked too carefully at this yet either. But there is the SACP (Snapmaker action command protocol) that for all intents and purposes seems to go one way: From the screen to the printer.
The exception may be to send a print job to the screen. Looking at sm2uploader (for example), you can create a package that includes the gcode to print and maybe deploy it for printing from the screen. There may be some code in the firmware for transmitting these also? Either way, the screen would then take over issuing gcode lines and all the job management works as intended.
Within the printer firmware, there are whole other layers of abstraction for keeping track of the print job and status besides the Marlin planner, etc.
print_control and various events in the Snapmaker libraries can trigger certain things, with status kept track of in system. The J1 function has a periodically summoned timer on each loop which also calls some print_control stuff, and logging (which is quite annoying, and delightful to push from LOG_I to LOG_V).
Status may be monitored by the screen. But the screen seems to expect it’s in charge of issuing commands line by line during a job. So my best guess is that a lot of additions to print_control and system (set_ and get_status) are needed if one wishes to introduce a third-party host like OctoPrint into the mix to avoid any possible conflicts.
Importantly one probably also needs to keep power_loss up to date, and I’m not yet sure how or if that’s possible if you don’t transmit the entire print file to the screen to be stashed for recovery. (OctoPrint issues code line-by-line, with an option to send to SD card. I don’t believe the power_loss cache or the internal screen memory behave using the standard Marlin SD card library, though. And anyway, the data would need to be packed into an SACP stash probably to be recognized.)
On M600: While I haven’t quite triggered this right to manage the power_loss structure, I’m not sure filament runout or M600 will ever actually trigger the event on the screen if the screen isn’t in a mode where it’s executing the job. So… how will you then trigger a Resume command when finished…? It might happen, I just haven’t seen it.
So… there’s some broad observations for anyone else that looks at this stuff. I’m not sure I’m seeing “the forest through the trees.” Also not sure why I’m still picking at this.
Guess it’s just interesting, and would be nice if the board could obey a third party cleanly.