one thing i ...occasionally see online when it comes to chiptuning is, well, overclocking.
I've seen be used on very few entries on botb in the past and i feel like its rarely mentioned (there isnt even a thread or Lyceum page about it besides the Nintendo Gameboy's Lyceum page despite being super op when done well.

so uhh
have a thread about it (mainly to share stuff about it lol)

also

questions!!!1!!!11!!

1) can you overclock entries for chipist based formats (such as Sega Master System and NSF+) in batols (both major and minors) (or is that illegal bcuz that wont work on non-modified hardware)?
2) for the few software (like furnace's Cxxx command), can you change the clockspeed during the entry or is that illegal?

you can do those things, for the most part. nsf_classic specifically doesn't allow overclocking. a bitpack might restrict you from it for some reason, but generally speaking you can do it! strobe is infamous for having done a bunch of cool overclocked entries. i do it every now and then. check out the "overclocked" and "overcocked" tags

since you mentioned the furnace clock speed/tick rate commands, that's maybe worth discussing because it seems much less feasible to achieve on any real hardware in any way. (electronics experts please chime in and tell me if i'm wrong about that!) and there's not really much precedent for having been able to do that. i think they are really awesome commands and produce unique sounds you couldn't get otherwise, so naturally i want to use them, but i can see the counterargument too. forbidding that one specific thing from one specific piece of software is kind of inelegant, though, too. it'd feel like gotcha-ing somebody if they used it and didn't know. and... it's not like we aren't already doing stuff that hardware can't do >.> just look at pc-engine sampling capabilities for instance... furnace basically assumes you have a modern computer powering these chips instead of, well, a 30 year old machine

kyunstep should stay dead imo

also, i know somebody's working on a pretty comprehensive guide to overclocking w.r.t. NES but the principles apply outside of that for the most part. and the guide isn't done, so i'm not able to share it right now 😅 but i'll be sure to post it when they have finished it

I think there was an SMS tune called SMStep by tmm12 that someone managed to get a working rom out of in the end that was overclocked. That's not to say all will be able to do that, for instance snoozetracker went out of the master system processing capabilities even though it is the same soundchip

To maybe clear up some semantics: "overclock" is sometimes a bit of a misnomer in that the hardware isn't necessarily actually overclocked but that update rate on the music engine runs at some non-conventional rate outside of whatever usual 50 Hz/60 Hz vertical blanking rate would be used for the platform.

I would say it's a case by case basis for which platform can natively support overclock/non-conventional engine update rates. Overall the verdict should be whether it is reasonably feasible to run on stock hardware (including factoring in how high the update rate goes).

- nsf/nsfplus: Debatable? To my knowledge the PowerPak's NSF player easily supports this but from my experience this is not the case for the Everdrive NSF player. I think technically it's reasonably feasible to support via some sort of custom timer interrupt or routine but in practice seems to be of limited support.
- sms: Also debatable? The VGM spec allows for arbitrary delays/update rates, but whether it's doable on hardware is a different question. As gtap mentioned, there is a ROM of SMStep

which goes up to 392 Hz on PAL hardware. SnoozeTracker is maybe doable with snompiler

but seems to have a bunch of caveats especially in terms of ROM size.
- sid: Already has many known cases of players that update paster than 50 Hz/60 Hz.

Anything past the 8-bit era probably has a good enough CPU or dedicated timers to easily support whatever update rate.

For the second question, so long as the driver can support the clock speed/update rate change I see no reason why it wouldn't be allowed. I guess that goes for the first question too.

Yeah I think changing the chip's operating rate should be off limits. No reason to ban updating chip parameters more frequently, though.