Its worse than that, unfortunately. About a decade before SAME started showing up on public for profit broadcasters, they had it on NOAA weather radio (you know, 162.4 MHz and several other channels in that area). So this has been around since the late 80s or so.

Well my bright idea was to latch on to the then popular craze in electronics magazines of make a project using a (then new) PIC, convince a magazine to run the article, sell my pre-programmed PICs to people, and retire to a private island (LOL... but I probably could have made my programmer pay for itself, at least). So I had a PC/AT class machine with a soundblaster 16 generating SAME codes using, if I recall, a BASIC program. The plan was a simple zero crossing detector and what amounts to a software "bit banged" UART and some UI code to drive a LCD module. Back when the PIC16 family was "new" this ended up not fitting, or at least my UI would have been ridiculously crude with little translation and filtering features so I dropped the whole thing. I could fit a really good UI in there or the decoder but not both and I didn't think a multi-chip solution fit the "standards" of the time. Now a days this would be a one chip PIC probably on an arduino shield with real analog input instead of zero crossing detector and all that, and enough space for a monster UI probably. The "target market" at the time was ham radio equipped storm chaser type guys who wanted a SAME radio for "them" rather than for fixed locations. Very travel and location oriented. Now a days of course they just use a smartphone and an app like proweatheralert or just the weather.gov webpage. I don't know if there's a startup lesson buried in here other than its possible to come up with an idea that greatly exceeds the technological limits of the day, not just at the super high end like big data, but also at the super low end.

Anyway the point is you'd have to ban virtually any post 1980's era stuff, including at least some pre-PC era home computers. A PC XT with an original soundblaster should be sufficient to encode SAME tones, its not like I was stressing out my old spare 286 while encoding test tones for my PIC based decoder.

The general development plan of a SAME encoder is about the same as a morse code sender. If you can figure out one, you can figure out the other. So you make a tone generating function. (and for SAME you need two tones, no big deal). Then you send the proper length of each aka a 1 bit transmitter. Then a function to send a whole byte at a time (big endian or little endian?) aka a 8 bit/1 byte transmitter. Then a function that eats a string and calls the byte sender for each byte of the string and optimistically stops when it hits the end of the variable length string. Then a function that eats some vaguely "human compatible" API and squirts out a line of SAME which is fed to the function above. And a zillion subroutines/function calls later, you get an audio SAME message. Making something that sends morse code is developed about the same way.

Its noob-compatible. No need for recursion, scalability is irrelevant, etc. As I recall the ancient PIC16 series didn't do recursion very well at the assembly language level.