Branch 123

Artifacts for issue:
#123

Version 0.13

Minor tweaks to client USB, added a 1p variant of host

Version 0.12

Client Mode Updates

• Added VMU screen and timer to library
• Word bytes are stored in proper order now within storage (corrupts memory formatted with previous versions)
• Support WinCE games
• Minor refactoring

General Updates

• Added DIR pin for each bus for better signal isolation using a bus transceiver
• Updated schematics in documentation

Version 0.11

Client Mode Updates

• Support vibration on Dualshock 4 controller
• Rely on modified pico-sdk version 1.5 (was previously using unmodified version 1.4)

Host Mode Updates

• Rely on modified pico-sdk version 1.5 (was previously using unmodified version 1.4)

Version 0.10

• Added support for Dualshock4 (PS4) controller in client mode
• Removed volatile memory client mode (planned to be readded later in a client-usb-client variant)

Version 0.9

• Created client-side library so that this project can emulate a peripheral on a real Dreamcast
  • Controller emulation currently only sends back controls in their resting positions
  • Created client peripheral which emulates a standard controller with volatile memory (client-volatile-mem.uf2)
    • Memory is stored in RAM (reset on power down) and automatically formatted on power up
  • Created client peripheral which emulates a standard controller with non-volatile memory (client-pico-non-volatile-mem.uf2)
    • Memory is stored on the flash chip on the Pico board
    • No integrity checks are made on the memory, so memory should be manually formatted on first use
• Renamed main.uf2 to host.uf2 in order to differentiate it from the client program types

Version 0.8

• Mapped the upper VMU buttons to gamepad
• Limit gamepad analog values to -127 instead of -128 (as defined in gamepad descriptor)

Version 0.7

• Enabled write access to VMU memory
  • Use at your own risk (not thoroughly tested yet)
    • To use on Windows or Linux, copy file exactly 128 kb in size and with the same name of the target VMU to the drive
    • Deleting files is not internally supported, even if the OS appears to successfully delete the file
    • The DC-Memory drive appears to have 128 kb of free memory, but this is just for the host operating system to proceed past the check for enough memory before allowing overwrite; writing a file with a unique name to this empty space will always fail
  • Drive will detach if too many write failures occur, will reattach once any VMU is removed and re-inserted
    • Write to a block of memory is retried until timeout
    • A "failure" is flagged if access timeout is reached for any block of memory (250 ms for write); 50 failures will cause the drive to detach
    • The host will usually attempt to write another block of memory and try to return to this block later; drive detach was added to prevent this infinite loop in the event of a major fault
  • It takes 15 seconds to write a full VMU file
  • Things will get weird if any VMU is added or removed during read or write which will be addressed later (#19)
  • Refer to this tool to be able to view/modify contents: http://evmu.elysianshadows.com/
    • Export from this tool directly to drive does not currently work; instead, export file to local system before copying to DC-Memory
• Fixed some USB CDC serial interface issues
  • Handle all different types of end-of-line (CR, CRLF, LF) and backspace (BS, DEL) characters properly
  • Handle multiple commands at once (if more than one end-of-line received in a batch of characters)
  • Output CRLF instead of just LF
  • Output bus index (0-3) that custom command was sent on ex:
    09414001 00000008
    11: added {09414001 00000008} -> [1]
    11: complete {08404102 00000008 FF000000}
    09010001 00000008
    5: added {09010001 00000008} -> [0]
    5: complete {08000102 00000008 FF000000}
• Minor tweak to attempt to correct for occasional Maple Bus write issues
• Increased MAPLE_RESPONSE_TIMEOUT_US to 1000 to help with VMU access
• Function definition found in device info is passed to peripheral

Version 0.6

• Addressed issues with Retro Fighters controller
  • Don't pop item from schedule until it is successfully written to the bus (would potentially cause dereferencing of invalid pointer to Transmitter)
  • Allow 3 communication failure attempts before main peripheral is disconnected (Retro Fighters controller sometimes has 2 consecutive failures)

Version 0.5

• Added a TTY parser to the USB CDC (serial) interface
  • Enter "h" for help
  • Any command starting with ASCII hex character is interpreted as raw data in ASCII hex to send to maple bus, and the result is returned as ACII hex
    example 1:
    09010001 00000008
    6: added {09010001 00000008}
    6: complete {08000102 00000008 FF000000}
    example 2 (when no VMU connected):
    09010001 00000008
    14: added {09010001 00000008}
    14: failed read
    example 3 (length in frame word doesn't match number of words given):
    09010002 00000008
    0: failed packet invalid
    example 4 (all hex values must be present):
    09010001 8
    0: failed missing data
    example 4 (X is ignored):
    09010001 X0000008
    0: failed missing data

When parsing, all non-hex characters are ignored, and exactly 8 hex characters must be present for each word. After raw ASCII hex is accepted, either the transmission ID is displayed followed by confirmation of data added or "0:" followed by failure reason. After the command is successfully sent, the next message will be transmission ID followed either by "complete" and received data or "failed" and failure reason.

The selected bus is done based on source address: {0x00, 0x40, 0x80, 0xC0} for player 1 through 4. All Maple Bus communication through this interface takes highest priority.

Any line coding variables are ignored, so it doesn't matter what BAUD rate, stop bits, parity, or number of data bits are set for this USB CDC serial interface.