tl;dr: should we allow .smc (and/or .spc+.700 files playable by spcplay) for the snes format, or should we not recommend c700 anymore

.spc files are fine and all, but recent c700 updates don't even support sole .spc files anymore, instead generating a spc file and a .700 file (which has all the song data, works pretty much only in SPCPlay though) to get around the memory limitations that plagued random cutouts/crashes.

even if discounting that, i think submitting a .smc export from c700 should be allowed in addition to .spc, for all intents and purposes it's still snes music (just in a whole ROM file instead of a .spc file). this would perhaps open the door up to doing supernsf style crap with the snes, but i don't know if there's any toolage to take advantage of that just yet

totally could be argued "well c700 just isn't a good snes tool then" and if thats the route the community wants to take, so be it; would love to hear everyones thoughts on this

There is an assembler named as Asar, also used by AddmusicK SPC MML compiler, that targets processors used in the Super Nintedo platforms, and cartridges of; the next hyperlink leads at its repository:
https://github.com/RPGHacker/asar

As a personal addendum, it is the assembler I currently use to target the Nintendo Entertainment System too: Its preprocessor mathematics functions readily allows to generate a frequency table that can be used for sound engines! ^^

For example; the next code in Asar may generate a frequency table:
;Generate table of frequencies
math round off
!12_degree_root_of_2 #= 1.0594630943593; For equal-tempered semitones: Multiplying or dividing a frequency by this number, augments or decrements it a semitone, respectively
!ntsc_nes_cpu_hertz_speed #= 1790000
!pal_nes_cpu_hertz_speed #= 1662607
!dendy_nes_cpu_hertz_speed #= 1773448
!frequency #= 440/8 ; Starting frequency of the table
!note_offset #= 0
while !note_offset <= 8 ; Displace starting frequency of the table to start in a C note
!frequency #= !frequency/!12_degree_root_of_2
!note_offset #= !note_offset+1
endif
!table_entry_index #= 0
frequency_table:
while !table_entry_index < 12*8
;print "!frequency"
dw round((!ntsc_nes_cpu_hertz_speed/(!frequency*16))-1,0)
!frequency #= !frequency*!12_degree_root_of_2
!table_entry_index #= !table_entry_index+1
endif

The next code can generate symbols for each note in the table; so one could put them in song data like !A4 or !Ds7:
;Generate constant symbols for note names
!note_base_index #= $00
macro generate_note_table(octave)
!Cb<octave> #= !note_base_index-1
!C<octave> #= !note_base_index
!Cs<octave> #= !note_base_index+1
!Db<octave> #= !note_base_index+1
!D<octave> #= !note_base_index+2
!Ds<octave> #= !note_base_index+3
!Eb<octave> #= !note_base_index+3
!E<octave> #= !note_base_index+4
!Es<octave> #= !note_base_index+5
!Fb<octave> #= !note_base_index+4
!F<octave> #= !note_base_index+5
!Fs<octave> #= !note_base_index+6
!Gb<octave> #= !note_base_index+6
!G<octave> #= !note_base_index+7
!Gs<octave> #= !note_base_index+8
!Ab<octave> #= !note_base_index+8
!A<octave> #= !note_base_index+9
!As<octave> #= !note_base_index+10
!Bb<octave> #= !note_base_index+10
!B<octave> #= !note_base_index+11
!Bs<octave> #= !note_base_index+12
endmacro
!octave_number #= 1
while !octave_number <= 8
%generate_note_table(!octave_number)
!note_base_index #= !note_base_index+12
!octave_number #= !octave_number+1
endif

A SMC format appeals to me, as a music Battle of the Bits format, and as a Super Nintendo software Battle of the Bits format!

I can't use .spc+.700 on my end due to a platform incompatibility. I can accept .smc, though, and I've seen a few submissions on Super Famicompo 3 and here that use a SNES ROM (though the former was the only one with C700 involved: the latter involved SNESMod builds that used the streaming sample feature).

I have developed a similarly weary outlook to Super MIDI Pak by Rian Hunter for the same reason as C700 (Citation: https://twitter.com/cejetvole/status/1487970696680513536 ): The VCMD format in its current state is really inefficient filesize-wise.

I know of a third one that went really raw on the DSP register writes (though it's a bit more varied, and due to auto-keying on it didn't really support pitch bends in its current state), and that is Paul Lay's sound driver. Unlike the other two, this was actually used in a few games: specifically, Astrohawk, Rockfall and Cute Angela - Great Journey. It supported two additional sequences, though it didn't quite play nice when they used each other's channels.

i see a lot of tech talk here, and i dont rly wanna follow it, so heres the only important thing for me:

i can play the file on my snes -> shld be allowed for submission
i cant play the file on my snes -> shldnt be allowed for submission

edit: .sfc, .smc and .spc all worked well on my snes (well, before it broke... i need to buy a new one , god...) so all those file formats seem oki for me.
i just assume it gets more tedious for easy playback in xhbs. people dislike even downloading one tool for playback, what if they need... two o.o

a thing which wld speak against wld be that the botb format explicitly says "spc" in the token.
same as NES/famicom is specifically nsf and c64 is sid
idk what exactly the idea behind this is. does it mean its technically not a format aiming for the console itself, but only the playback format?
asking puke here

i'm a little torn on this...

on one hand, creating a 2nd SNES+ format is like splitting an already pretty niche, quiet format. i've been hosting SNES recently, and will continue to, but before that, exactly 1 SNES xhb happened during my time on botb. it shows up in majors of course but still, not a lot of activity...

on the other hand, .smc/.sfc give you a LOT more file space to work with, so incorporating them into the existing SNES format changes the playing field, so to speak - .spc finds itself at a bit more of a disadvantage, potentially. i'm not against it, but it bears some scrutiny if most of the other creation tools can't utilize the more forgiving filetype.

i also agree with kleeder's definition of what ought to be OK in a SNES format, and rom files are absolutely included in this. i think this discussion even happened several years ago: .spc technically is but a subset of what the SNES could do, even though it's widely recognized as the chiptune filetype for the format.

:shrug: i'm slightly more "for" than "against" the idea, because i would love to see boundaries get pushed by eager botbrs. we just need to discern whether it's fair or not

EDIT: with regard to the format token, unless the issue is "that can't be changed" (idk, could be!), i see no reason why it couldn't be renamed to "snes". i mean it could be named that right now considering the full format name is "SNES/Super Famicom"

As an off-topic tangent: I find myself wondering about whether BotBrs who got into making chiptune, prefer to write song data only if they could, or write the whole program that plays chiptune!

iirc .spc format doesnt support bankswitching (so it's already a limited format even if we disregard c700

), so i'm all for .smc being allowed, but not .spc+.700 (unless those are playable on hardware and i'm an idiot)

kleeder's guideline of "works on snes therefore 👍" is good -- i don't think a new separate format should be created for this, just allowing smc uploads for the current snes format is enough imo

@ViLXDRYAD: the former (song data only) for me, for sure

Correct on .spc not allowing bankswitching: yes, the SNES ROM route does allow for extra things to swap in and out on the fly, and in C700's case, stream its note data on the fly (though its build completely changes, and actually becomes unplayable solo on the SPC700: I ran into an entry that had to be resubmitted because of this exact problem on exporting). The other semi-undumpable case was through SNESMod, and was caused by the streaming sample feature being used.

More "undumpable in .spc" cases will pop up over time, but if it's on a SNES ROM, I still technically see it as legal to an extent.

Script700, on the other hand? First of all, I think that's two files, which is problematic for Battle of the Bits without zipping it up. Second of all... can it be converted to a ROM? I'd have to study the format on that feasibility, because what I'm sensing is that if it merely writes to registers at some prescribed time, then I think it could be doable on the condition that the converter be coded. Otherwise, I don't support this approach.

This page contains some English documentation on Script700's syntax.

The legal commands that I can convert to a ROM are anything that writes to the CPUIO registers. It has to be an input port, not an output port, because I have to do this from the SNES side.

if script700 can be converted to a ROM, then imo the ROM should be uploaded, since its a single file and can be played back on a SNES/emulator

yeah NES/Famicom should include .nes
and C64 should include .prg (or whatever the standard is for executables) ... same with vic20 to be honest

I'm 1000% for system formats having full ROMs as an explicitly allowed upload option, especially if it invites people to promote/use more advanced tooling.

yeah i think allowing full ROMs would solve like all of the issues i have since c700 can export .smc (a rom) too, script700 is prolly too hacky of a method to use

IN hindsight i shouldve just gone "ALLOW ROMS TO BE SUBMITTED FOR CONSOLE-BASE DFORMATS‼‼"(sic)

Sharing of source code is appreciated by me

I agree with .nes allowed on NES/famicom
It would be cool

Yes, I am looking forward for software demomstration submitted at major competitions

just keep in mind the focus is on music so if you submit your complete demo to a major (which happend before iirc) only the music part shld get judged

Good to make clear as a major rule that point is I consider: I however feel desire to see more BorBr demooooooooos; even better with source code of, and regardless my vote yet centering completely on music, it would be neat to drop an "amigaaaaaaaaaaaaaa" on an oldschool demo entry submitted and express my fiery passion for; I joined to share with demosceners about and improve my skills about to reach to be the one I want to! Perhaps one day the reason I joined Battle of the Bits will grow to satisfy more and more over time, with more BotBrs adding nice visual cherries to their audio entries!

@kleeder agree, could also add an informal guideline that formats playable in regular media players (ie nsf, spc etc) should be prefered over ROMs it at all possible -- leaving ROMs mostly for weird edge case scenarios (or not-so-edge case) where the usual formats are not possible
nsf is an example, it supports bankswitching, multichip and stuff, i cant think of a scenario where a rom would be preferred (though it should be still allowed, it runs on an nes so its nes chiptune)

it happened today! .sfc and .smc are legal file options for this format.

I appreciate the gesture of adding programming resources on its lyceum article, currently on the web page that the next hyperlink leads to:
https://battleofthebits.com/lyceum/View/spc%20(format)