ownasaurus / tastm32 Goto Github PK

Would love to find the definitive cause and fix it!

Title. Have not figured out why, yet.

For the test SMB3 run I am using, 100% of the time it desyncs right before 1-5 on first execution from the time TAStm32 is powered on. But every other run works 100% of the time until I power cycle the board again. Something about the state isn't quite right or isn't being fully reset during a reset. I'm not sure which behavior is "correct" but I want it to be consistent!

Baxter's Tetris TAS runs almost perfectly, but the final name in the score screen ends on "AAXTER" instead of "BAXTER". Suspect there may be an off-by-one error somewhere. Needs further investigation.

I should not have committed the software latch glitch filtering to master last week. Should move to dev branch and test further before committing to master. Also this should be resolved by hardware buffers in v4

It would be another power command, like softreset and hardreset. The aforementioned commands operate on open-drain to avoid having strange console side effects. However, to work with a power relay strip, the reset pin should operate on push-pull. Therefore, a new command should be added to the protocol, firmware, and python driver.

• Add all of the necessary files to the auto release builder (python scripts)
• Update README.md to reflect the new workflow

Test case Super Mario World 96 exit WIP requires a soft reset at frame 1117 (r16m can be provided via dm)
this works on commit 372cd61 with the command:
./tastm32.py --console snes --players 1,2,5,6 --blank 0 --softreset --transition 1117 S 96wip.r16m
however it fails on HEAD at 165a556
and on 8335dce
trying the --nobulk flag at the suggestion of @Ownasaurus did not help

normally works with a reset on frame 1117, fails to create the save unless reset is at 1135
save is created with the reset at 1135 however it drops a number of inputs and gets stuck at the following title screen

Things to either merge to master or at least clean up and keep in its own branch:

• A/V signal processing code
• Rumble processing and sync code

Sometimes after killing a run, tastm32.py will return "error during reset" repeatedly until you either (a) get lucky or (b) powercycle the hardware. dwangoAC duplicated the issue on stream by accident. Probably just an edge case in the comms between tastm32 and the python script

-Ofast, very rare but happens

Allow a user to use a controller to control the console that the tastm32 is plugged into

• Most likely will need to bypass or disable the buffer to ensure the lowest latency communication
• Ensure bulk mode is disabled

STM32CubeMX does not support OTG mode, where it can be either a host or a device during execution. It would require a bit of manual coding to set up.

A plan for how to expand the TAStm32's functionality and provide easy-to-understand terminology for the components. The terminology could also apply to other replay devices depending on acceptance.

Input Replay Device

The main TAStm32 board which focuses on replaying inputs to the console like it currently does.

Input Capture Device

A separate board that connects to one of the exports to capture and save live input (suggested originally by dwangoAC).

Input Display Device

Another separate board connected via export that allows for detailed input display and potentially other information such as authors of the currently playing replay, commentary, etc. (Extra information up for further discussion)

The top of the case for v3 of the TAStm32 has a special markings to indicate P1, P2, V1, and V2, making the top 1-way, but the case can still be closed even if the top of the case is rotated 180 degrees.

I personally suggest placing a notch on one side of the top part of the case and a bump that fits into the notch on the bottom part of the case so the case can only be closed correctly.

Noticed something while looking over the protocol....a C received could be either of these:

'A' - 'D': Feeds the configured run with a single frame of new data. See below for details

'C': Controller mode (no buffer, repeat last input on underrun)

How does TAStm32 handle this?

Planned new features:

• Screen
• Load runs from USB stick
• improved signal integrity with buffer chips

Must run .m64 and .dtm files with --blank 1 for it to function properly. The cause has yet to be pinned down.

Specifically I'd like to record movements on a PS5 and play them back.

My apologies for crashing the issues section here. I'm just not sure of the terminology for this type of thing and I figured you guys might be able to point me to the right place for doing this on modern consoles.

I would like to manually merge https://github.com/sauraen/TAStm32/tree/FourPlayerGCN64. It is probably easier to manually merge in the changes rather than do a proper pull request due to the deviation over time. Careful consideration should be made as to whether or not players 3 and 4 can be supported in the upcoming v4 hardware changes. Since for vis boards, voltage is an output, but for N64, it would not be. Either way, 2-player support should be easy peasy! Just gotta do it. Since it's not going to be a formal pull request, need to make sure to update README.md to properly credit Sauraen

Does not occur on NES from reset
Does not occur on SNES from poweron
Does not occur on N64 from poweron

Further investigation required.

Audio streaming fails and stutters horribly on Ryzen's native USB controller. This likely applies to some other USB controllers, too; Intel's controllers notably work just fine.
This also likely applies to other high-data-rate payloads; we should test videophone.

This is NOT a tastm32-specific issue; it was also reproduced on total's PSoC5 board, which also relies on USB-CDC serial.

This could likely be fixed by directly using USB isochronous transfers instead of USB-CDC serial. USB serial relies on USB bulk transfers, which guarantee data transfer but not latency. Isochronous transfers are regularly scheduled and guarantee latency over completeness of data transfer. For streaming audio/video, consistent latency is more important; the problematic USB controller(s) might be pausing on some bulk transfers weirdly.

Feature requested by ViGrey