VMU tasks

[TheOpponent]

• Identify the source and format of scrolling VMU messages.
  • Kinematron messages are delivered on the VMU screen. Because not all memory units included a screen, there may be a method to bypass the screen delivery and show them on the TV screen if the game detects that the current VMU does not have one. If this is the case, or if modifying the VMU text proves infeasible, investigate forcing this detection to fail to recognize a screen.
    • We expect many players to use an emulator. The most popular emulator is Flycast, and while it does have an option to show the emulated VMU display on screen at all times, it is not enabled by default, and it is rendered over the game screen, which may be a distraction as it displays a static image for most of the game.
  • During battle stages, special attack names are scrolled on the VMU screen during the cutscene. Japanese attack names will need to be translated.
• Locate downloadable VMU binaries and identify text formats within.
• Modify static graphics such as the Sakura Taisen 3 logo.

[TheOpponent]

The game checks memory card types after the title screen. If the memory card in slot A-1 is not a VMU with a screen, the game displays a warning message but otherwise proceeds normally. During gameplay, at moments where the portable Cinematron would display a message, the VMU will beep and relay the message as scrolling text on the VMU screen, with the game showing a hint for the player to look at the screen. If a screen is not available, the message is reproduced as normal text in place of this hint.

Screenshots:
https://user-images.githubusercontent.com/8432212/216801601-6bdbe7af-7363-418b-a3b5-ff096200a6ea.jpg
https://user-images.githubusercontent.com/8432212/216801568-2eac69b8-573c-4546-b0c3-33992601bf36.jpg

[TheOpponent]

The game updates the VMU display very frequently, up to 30 Hz in some places to produce a shimmer effect in a logo graphic. Examining a RAM dump at the title screen where the game's logo is shown on the VMU screen reveals that the image data is stored as a 1bpp bitmap. According to the Shinobi library manual, bit 0 is off (white) and bit 1 is on (black). Because the data was stored in 1bpp format, it is using the low-level pdVmsLcdWrite1() function, which means each image rendered this way is 192 bytes in length.

CrystalTile preview of an animation of the Sakura Taisen 3 logo:

[TheOpponent]

VMU graphics loaded at the title screen can be found in several .BIN files in SYSLIST.AFS:

• tyt00.bin
• vmchat00.bin
• vmeshe00.bin
• vmload00.bin
• vmreus00.bin
• vmsave00.bin

These files contain 1 or more screens of data, 48 x 32 in 1bpp format, 192 bytes each. They contain no headers or footers.

These files appear to be VMU executables and contain graphics that should be editable:

• S3vm_eri.bin
• S3vm_gri.bin
• S3vm_han.bin
• S3vm_kok.bin
• S3vm_rob.bin

These graphics can be observed in CrystalTile 2 in solid 1bpp mode by setting an appropriate palette such as TLP, then setting the width and height to 48 x 32.

[TheOpponent]

A script has been written to convert PNG images into the 1bpp bitmap format used by low-level LCD screen update functions: https://github.com/TheOpponent/st3-translation-notes/blob/main/Scripts/write_lcd_data.py

[TheOpponent]

The scrolling Kinematron messages are stored as normal strings in the script files. They are delineated with the character ▼, and a fallback copy of the message is stored in the following string with formatting for the main text box. A string in 1ST_READ.BIN at 8c22106b is displayed on the TV screen while the Kinematron message is displayed on the VMU screen. A function at 8c12575c references this string, but the string itself appears to be hardcoded.

Additionally, the message scrolled on the VMU screen appears to use its own text rendering function, which uses the font sheet in SKFONT.CG, but with its own text width value.

[TheOpponent]

Changing the function for producing the Kinematron message is not viable with current hacking techniques. While it is possible to change various bytes set to 0x1a to change character width, searching for a byte that determines the total message length as the message is written to memory cannot be done since the message is formed instantaneously. Instead, we are using the same workaround for map labels: redefine now unused kanji tiles. The characters have no gaps between them, so tiles can be changed without hacking the LCD code for Kinematron messages.

The screen data for the Kinematron messages is formed in memory using the normal in-game font, which is converted to 1-bit pixel data and stored in a buffer that is scrolled across the screen until the player dismisses it. This function is separate from the other text functions for the main script and ignores all control codes, so using codes to manually set character width was not an option either.

To conserve font tiles, we are currently using a proportional English font that scales well without antialiasing. Our current in-game font, Kosugi Maru, is fixed-width and difficult to read at low font sizes without antialiasing.

[TheOpponent]

Three programs have been published to assist with LCD graphic editing tasks:

https://github.com/TheOpponent/st3-translation-notes/blob/main/Scripts/read_lc1.py
https://github.com/TheOpponent/st3-translation-notes/blob/main/Scripts/write_lc1.py
https://github.com/TheOpponent/st3-translation-notes/blob/main/Scripts/write_lcd_data.py

[TheOpponent]

The S3vm_ files in SYSLIST.AFS are the same executables that are uploaded to the VMU as minigames. They contain a font sheet at 0x4010 and include a complete English character set. The tiles are rotated 90 degrees counterclockwise and are 6x7 when rotated correctly. This allows for 2 rows of 30 pixels of text.

Strings begin at approximately 0x6354, preceded with eight 00 bytes and are terminated with FF. There is likely a table containing offsets for each string, as terminating strings prematurely causes the game to jump to the next line where a change in the on-screen character's appearance takes place.