A Detailed Look at the maimai Cabinet's Boot Initialization Process

1. Power on#

After the cabinet powers on, Windows 10 boots and amdaemon starts automatically. During the boot phase it does two network things:

• Allnet: sends one initialize request to the NET服务器, and the server returns the game server address, region code and store ID
• AIME registration: locally initializes the code-scanning card reader (Chime.Instance.Init, registering the keychip identity). At boot it doesn’t send get_data and doesn’t fetch a token; get_data is only initiated by amdaemon when a player scans, and the token comes back with the scan response

After these two steps complete, amdaemon sets Core.IsReady, and then the game program begins initializing

Game program startup#

The Unity scene loads and GameMainObject performs initialization

• Loads the native DLL preload libraries
• Reads the cabinet’s ini config
• Creates AmManager (the overall manager for subsystems like coin insertion, code scanning, network and dual touchscreens; for now only an empty shell)
• Creates the sound, data and chart managers
• Generates the AES key table
• Creates LAN components: Setting, Advertise, DeliveryChecker, Party
• Registers the native daemon exception callback

This step makes no network requests at all; it only builds the whole program’s object structure

2.5 Waiting for amdaemon#

Every frame it checks Core.IsReady; if not ready it does nothing. Once ready:

• Calls GameMain.LateInitialize once: puts PowerOnProcess (the boot self-check process) into the process scheduler at priority 50, and starts a background PingChecker thread
• From this frame on, every frame runs: Core.Execute → GameMain.Update (main game logic) → GameMain.LateUpdate

Process scheduler mechanism: processes queue by priority (smaller numbers run first), the state machine is Start→Update→Released, and Released processes are freed and removed during the late update phase. The entire boot chain is relayed through this scheduler

3. Boot self-check#

The boot screen appears and the dual displays begin checking item by item:

1. Wait for amdaemon: waits for Core.IsReady. Once ready, a string of hardware preparation: initializes the input system, reads the config after amdaemon, initializes OperationManager, probes the COM serial ports (checks which port the USB4 hub is plugged into — one of COM20/24/28/32 — and from that infers which serial port the LED strips are on; if COM20 is detected, for example, the lights are mapped to COM21/COM23), initializes the LED controller, and lights all JVS panel lights as black
2. Asset loading: waits for all chart/image/model assets to finish loading (assetManager.IsDone and the chart slider thread idle), with loading progress shown on screen. After completion it lingers for another 2 seconds
3. Network self-check: tests network connectivity item by item, with the screen showing each item’s 好 or 坏 line by line. There are 8 known check items: IP address, gateway, local DNS, hop count, line type, Net authentication, membership server, title server. Two of them have hard timeouts: the network item at 15 seconds and the Net authentication item at 120 seconds; on timeout it’s judged 坏
4. Membership server: if authentication is valid (Auth.IsGood), sends a liveness check to the membership server. If the server is reachable it shows 好, otherwise 坏; if invalid, it’s skipped
5. Title server check: has OperationManager download the game config (GetGame*). As long as it has downloaded successfully at least once (WasDownloadSuccessOnce) and the server is online, it’s judged 好. After completion it lingers 2 seconds

Once everything passes it enters Released: adds StartupProcess to the scheduler, frees itself, and sets IsGameProcMode to true (marking entry into the formal game flow)

4. Formal startup#

This process performs a complete hardware + LAN self-check:

1. Touchscreens: until both screens’ drivers are ready or error out; errors record their error codes into the system
2. LED strips: both sides’ LEDs finish initializing, after which the camera system is initialized
3. Cameras: the QR code camera + top camera become ready, after which the card reader is initialized; camera error codes are also recorded into the system
4. Data loading: waits for the data manager to reach 100%. After that, in order: configure the favorites system, initialize map data, download charts (DLMusicScore + DownloadMusicScore)
5. LAN — config delivery (WaitLinkDelivery): the LAN’s config delivery server is ready; if this is the server machine and there’s no LAN, it’s directly judged 好 and skipped. Duplicate machine numbers display a “机台重复” error
6. LAN — setting sync (WaitLinkSetting): syncs settings such as event mode and event track count. If a duplicate machine number appears in the LAN, it reports error 3201 and records it
7. LAN — Party (WaitLinkParty): joins the Party (Party.Start(机器组ID))
8. LAN — LinkAdvertise: initializes Advertise
9. Ready: after everything completes it lingers for 2 seconds
10. Released: adds WarningProcess to the scheduler, frees itself, switches the coin mechanism to formal game mode, and reruns GameManager initialization once; sets IsInitializeEnd = true (this is the precondition for the main game loop to begin doing logic such as error detection)

Also: when the process starts it attaches a “general message process” at priority 51 as the message manager (popups, timers and other general UI all go through it), and calls OperationManager.Initialize() again (this call is idempotent, resetting to the 检查认证 state)

5. Copyright check#

Before entering the copyright screen it checks 5 items; if any one is not satisfied, it reports error 912 and goes through the system error flow (ultimately exiting the game program, see step 6): the machine name contains “ACA”, the GPU is “GeForce GTX”, the CPU is “Core(TM) i3-8100”, the program is installed on drive X, and the error log path is on drive Y

After the checks pass, the copyright warning screen is shown. If the region code is 1 (Japanese server), a copyright logo animation plays and then ends; otherwise it ends directly. This screen is displayed only once over the process’s entire lifetime (the static flag OnceDisp)

On finishing, it starts two resident processes at once and frees itself:

• CommonProcess (priority 10): the background UI manager — time, volume, info popups and timers all belong to it
• AdvertiseProcess (priority 49): the title screen

Error codes#

The error screen displays a 4-digit error code (Error.Number zero-padded); here’s the full table of error codes that can appear in the boot chain:

The remaining error codes (LED serial board 0-9, LAN Party networking, network accounting E00-E15, etc.) belong to low-level diagnostics, aren’t shown on the error screen, and can be checked in test mode

What it means when the screen stays on 初始化 throughout boot#

• Always 初始化 (blinking): still waiting for that step to complete. Commonly seen while waiting for amdaemon, asset loading, network self-check, membership server detection, or title server download
• 坏: that item failed. Most self-check items continue on after 坏, while some go straight to a system error and exit, such as 912
• Hard timeouts: the network item is forced to Bad after 15 seconds and the Net authentication item after 120 seconds. Membership server detection and title server download wait until there’s a conclusion (depending on each request’s own timeout config)
• Stuck on 初始化 for a long time: means the server/hardware that item depends on isn’t responding, and it usually can’t get past the steps that depend on it (for example, after Net authentication times out, the title server check can’t pass either)

6. Initialization complete#

AdvertiseProcess handles title standby: shows the logo → title → decides on the ranking:

• Input detected → fades out and transitions to EntryProcess (game entry), after which inserting coins/swiping → confirm → enter the game
• Demo available → enter AdvDemoProcess (plays the autoplay PV); otherwise return to the title screen

The moment the cabinet enters title standby is “initialization complete”: you can insert coins, read cards, the server is online and the config has been downloaded. After that OperationManager stays in Idle (detailed in step 4), checking for config updates every frame, running maintenance/closing timers, and PingChecker sending a speed-test packet every hour to update the latency data

Conclusion#

That’s the whole low-level software behavior of a 舞萌 DX cabinet’s boot initialization. If you find this interesting, feel free to follow this blog, add the site to your bookmarks or subscribe to the RSS feed; more articles like this will be coming