After a long break I'm getting back into snesdev.

This weeks goals:
* Work on my website and/or the wiki every day
* Prototype a ledges + jumping movement system for unnamed-snes-game
* Study and learn my old untech game engine (in preparation for the upcoming snesdev game jam)
* Add a search bar to the audio driver GUI

I wrote a blog post about the smpspeed tests I did for TASBot with an analysis from the perspective of someone who has coded a homebrew SNES audio driver.
https://undisbeliever.net/blog/20250313-smpspeed.html
#snes #snesdev

SNESdev daily log 8:
Improved the smpspeed reading script.

SNESdev daily log 7:
Sketched out a design for adding ledges to unnamed-snes-game.
Measured the S-SMP clock on 3 of my Super Famicom consoles.

SNESdev daily log 6:
Wrote a python script that uses usb2snes to extract the smpspeed test results out of the VRAM tilemap and into a csv file (while the console is running).
Recorded and graphed my PAL console's S-SMP (audio CPU) clock over 2 hours.
#snesdev

I have released v0.1.0 of homebrew SNES audio driver.

This release adds new echo instructions to audio driver, left/right channel invert and cleans up the 65816 API.

I'm also declaring the MML & bytecode assembly stable. I'm not going to change the current syntax/behavior unless there is a very good reason to do so.

https://github.com/undisbeliever/terrific-audio-driver/releases/tag/v0.1.0

#snesdev #spc700

SNESdev daily log 5:
Lots of little changes and fixes to the audio driver.
Stabilized the Terrific Audio Driver MML and bytecode assembly syntax and behavior.

SNESdev daily log 3 & 4:
Proofreading audio driver code and documentation for the upcoming v0.1.0 release.
Ran the smpspeed test on 3 of my consoles for TASBot.

SNESdev daily log 2:
Added manual seeking to the audio driver state window.
Added `(` decrement volume and `)` increment volume MML commands.

@PypeBros I want achieve 90 days in a row, but bad luck (things breaking around me requiring quick fixes) and my difficulty in managing multiple projects at once have have this problematic.

@PypeBros
Looking through my files (and I may have missed a few) - 48 times when the log was private (2017-2020) and 53 times when the log was public (2020-2025).

SNESdev daily log 1:
Finished the audio driver state window.

SNESdev daily log 3:
Started the audio driver state window.

SNESdev daily log 2:
Played around with the rust movement prototype to improve player physics.
I've decided to add separate deceleration values when the player requests movement and when the player releases the D-Pad.
This will make jumping, running and ice-physics more interesting.

SNESdev daily log 1:
Coded a player movement prototype in rust with different physics values for ice (blue) and slow-down (grey).
Fixed a bug in the audio driver's pause IO commands.

January and February's lack of progress is from a whole bunch of bad-luck with electronics and computers breaking around me, combined with bad time management.

I am defiantly not going to meet my self-imposed goal of a unnamed-snes-game demo at the end of March.
I'm not sure what to do at the moment.

Belated status update:
unnamed-snes-game: Nowhere (I'm having difficulty working on two projects at once)
audio-driver: v0.1.0 is two features away from the final 10% (WILL be completed before the end of February)
snes-test-roms: Fix my recording setup, will record joypad tests on the weekend.
snesdev-game-jam: I have a plan to improve untech-engine.

SNESdev daily log 1 - 5:
Added an IO command to set music and sound-effect global volumes at the same time.
Changed the 65816 APIs for my audio driver. The Tad_flags variable is now public and the default values are now compile-time configurable.
Fuzz tested the bytecode assembler and the MML compiler. Found and fixed 3 panics.

I'm going to switch to a hard coded 8-direction movement code (with one code path for each direction).

I can't see an easy way to fix this without division, multiplication or a lot of signed comparisons. All of which are expensive on the SNES when multiplied by the number of onscreen entities.

Unfortunately the sliding velocities can stack and I cannot see any easy and quick way to limit maximum velocity while still maintaining 32-angle polar movement.

In this example, I'm holding left/right and tapping up/down.
The stacking sliding velocities cause a unwanted speed boost.