http://battleofthebits.com/lyceum/View/aym+(format)/

hey, all... we've done some research regarding the AY/YM formats and have hashed through some motions and ideas.

the main concern is that the *.PT3 format is a module file (sequencer data only) and not executable by itself on hardware.

people tend to use Vortex Tracker II when it comes to AY/YM compositions. Vortex Tracker II is capable of inputting almost any file format for those chips and converting them like a swiss army knife. the problem is that the *.TAP and *.SCL export does not auto-boot on start-up to the player and reference the module; say as Beepola does.

the *.AY format is the Z80 player code that references the full *.PT3 file itself. if someone wanted the *.PT3 source, they would just have to extract it from the *.AY.

the most sane motion, moving forward, (until *.TAP and *.SCL export are fixed), is to make *.AY the default AY format and *.SNDH the default YM format.

(now there is debate about the *.AY replayer code being inaccurate, but if it is, the *.PT3 could just be extracted and played with a *.PT3 player on hardware.)

this way, however, we can have two standard formats and players can recognize and play them.

(we should probably also reach out to bulba. i see that he's recently updated Vortex Tracker II since April 2017. :) )

But isn't stuff like .mod also just a module file?


Also taken from the lyceum page:

SND/SNDH
Since it's the most modern format, they allow more effects because the conscious mindset when created was pushing the hardware to its limit. Surpasses ym revision 1 through 6.
__________________________
ay/ym
Surpassed BUT legacy. Saving in this for either Atari ST/ZX Spectrum is a downgrade in quality/possibilities.

I understand making .SND/.SNDH a new standard for YM from reading this, but what about AY then? .AY seems like a downgrade if I read the lyceum page...`



Also Vortex Tracker III when

actually I exported a sndh that worked first, but it wasn't in the list of formats allowed in the lyceum so I didn't go for it

What about a .ymt? That's what YM2149 Tracker saves in.

The format technically is AY/YM (aym) and is intended to be replayable on hardware with machine code. So if you choose to use SNDH with YM, then you're taking advantage of the format; and "g0g0g0g0." AY is known to be inferior to YM anyway.

*.YMT is a tracker module. It would be as if I used NerdTracker II and submitted a *.NED file within an NSF competition. But unlike if I submitted an *.NES to an NSF competition (to take advantage of the hardware); as it is machine-executable code. *.NED is sequencer data only.

is this all gearing up to vortex tracker having its own format? :)

What impact would this have on preexisting aym entries? Also, a standalone ym format sounds like a nightmare given the number of yamaha chips one can find in the wild.

Atari ST/e format? :)

Seriously though, if there is a split to AY and YM as standalone formats, what exactly would be the target of YM other than ST (or I guess MSX without any of the expansions)? And if that is the case, would that make STe's extra DMA channels legal in YM format?

tfx my first couple of maxymiser tunes on here include some digidrum/dma channel in some form or other.

essentially its a huge advantage (as are sidsounds, "custom" waveforms, etc) but at the cost of having to wrangle with an st tracker and its unfriendly learning curve ;) i tend not to use them now since vortex is just more readily usable.

Can MSX AY ever be up for consideration? Or would that just have to be reserved for a (possible) future MSX format?

[edit:]
I know that for now, the main difference between AY and YM is that AY is Z80 code and YM is 68000 code.

MSX AY...if you can consider "PT3PLAY" as a viable player format then I'm game

I don't mean doing speccy AY, saving as .pt3, then playing that file on an msx machine, I mean composing MSX AY on an MSX (using MSXBASIC, MSXMUSIC, MusicA, MGSDRV, TriloTracker etc.) and using that as the entry itself. With 0 intention to play it on a speccy. Possibly submitting as mp3 for things like TT in the same manner as people using LSDJ upload an .mp3 rather than the .sav tracker module. And similar to SMPS users, either an mp3 or some way of logging a .vgm for MGSDRV since that's already the process for driver formats (though PC-98 kinda broke this convention recently???)

It's the AY/YM format, not the ZX Spectrum/Pentagon/Atari ST format. (Amstrad CPC too!)

> future MSX format

Trilo Tracker allowed in some form when

Well, technically if an AY or YM format is played back on hardware, it has access to the hardware it's playing back from with what the replayer software is being told to do by the sequencer data.

It's almost as if we're getting into an issue about why people don't like SuperNSF; even though it's hardware-compliant. Those that do not like SuperNSF; will HATE NSF2 once it's utilized. ;)

It's not like we're talking about the *.SPC format. The *.SPC format dictates that it's a full SPC700 RAM dump w/ player code. Yes; eventually we'll have to move to the *.SFC format so that cart ROM can be accessed.

*.YM appears to be a logged format; like VGM :/ I'm not certain if it's a good idea to use it. May as well use *.SNDH since SNDH includes the player code; instead of just YM register writes.

In summary:

*.AY = player code "rip" format.
*.YM = logged format
*.PT3 = sequencer module format
*.SND/*.SNDH = player code "rip" format. (*.SND and *.SNDH are/should be the same thing.)

Player code "rip" formats are the closest thing to being executable on hardware. The next best option is... executable binaries. :)

Could just scrap it all. No chip formats anymore. Just platform formats. Bye bye .ay. Hello ZX Spectrum. Bye bye YM, hello Atari ST (and the OPLL expansion too!). Bye bye "SMS". Hello actual SMS (and the OPLL expansion too!). Bye bye MSX AY and your ability to sneakily enter AY/YM compos (this entry did that). Hello MSX format (and the OPLL expansion too! (and SCC expansion too! (and SFG expansion too!...)))

The way it works with legacy is that AYM still exists on the site, and battles still appear that way, it's just that majors no longer have that and just include the new ZX Spectrum format. And you switch out hosting abilities to remove AYM and add ZX Spectrum.

Having a separate Atari ST format also keeps the I HATE SUPERNSF kind at bay because its powerful 68000 tricks won't be included in the ZX Spectrum battles.

Of course, this kind of thing facilitates every other format going the same route of "fuck the chip, embrace the platform". A really big project for something like BotB 3.0

I'm planning to write a PT3 module for MSX's YM for my next aym entry but I'm not sure anymore...

you'd have to split it into zx spectrum and zx spectrum 128k actually

Thought of a pretty simple solution that may politically work out without much coding or databasing; and then could easily be categorized "futurely".

What about AYM and AYM+?

AYM is AY or YM without "frills". No PCM/PWM waveform "mod engines", no beeper, no additional chips. Just AY or YM chip. Format can be rip, logged, module, whatever... As long as it can be proven that it's just AY or YM without frills. The only thing I don't see a problem with is clock/refresh speed changes; but no synth generation that goes outside the spec of pulse, noise, and envelope.

AYM+ is AY or YM as the "motherchip" with anything else as "daughterchips". PCM/PWM generation, beeper, FM, whatever... It's all good. The processor architecture has to be from 70's to 90's and be an executable rip or binary format on a platform. You can also be a simpleton and submit vanilla AY or YM, but the submission format needs to be executable rip or binary.

Any "grandfathered" AYM+ entries could simply be flagged for reclassification retroactively.

i don't know if i understand the consternation about .pt3. it is playable on hardware using protracker 3. it is also easily playable on modern computers because it is supported by all the popular zx spectrum music players

none of NSF, GBS or SID play on hardware without player software either

coupled with the fact that probably 1% of botbrs have a zx spectrum anyway and the inherent benefits to musicians/the community of having music in its source format...

...i'm not sure why there is a need to switch?

[removed]

@sean_booth

OK. I didn't really wanna flesh this out entirely, but we're getting into a messy issue. If we're getting into an issue where NSF would not be a good format to play without software on the hardware itself, then we'd have to make sure it's in *.NES format. If expansions are used, then we'd have to make sure the n00bz configured the header properly to note that the expansion is being used. Also *.NES format is incapable of multiple sound chips. It's a videogame/program format; not a music format.

Frankly the rationale ends here: If n00bz are allowed to deviate from formats too much then we have personalities generating buzz from one another in trolly/flirty ways that create stress on a programmer of a website who is still learning PHP and doesn't want to really deal with that bullshit all the time.

We also don't want to start getting into "preferred players". We live/work in a community that embraces differences: personality, OS, hardware, art, etc.

The common concern is: Which is the best way to play back on hardware? (Hardware playback capability is the standard and desire.)
Usually that answer is: You make sure have a binary executable so that the machine can understand it well; or an emulator can run it. Remember, we're not in the mindset that a "media player" is the prototypical standard of playback.

However, it seems that general consensus at the moment is that ZX Spectrum has software that plays modules better than the way Vortex Tracker II outputs its executable archive formats, etc. I also do not have much personal ZX Spectrum experience. I concede on this point for now; but solely regarding AY and YM. We'll be working on better solutions with the AY and YM community to suit our tastes and standards.

For instance, even I disagree that MP3 is a good format for GB, but the rationale is that many people have cart trackers without dumpers. I've been working on solutions for this too, but that's another topic.

I've probably been silent for a bit too long on this thread. I've been lurking the whole time and failing to grok everything being said. But I guess I can throw out some ideas, huh?

AY/YM format was requested by many as a format a very long time ago (the first entry is '09). I can't remember what tools were available at the time. But something tells me there were some n00bs who used VortexTracker II and wanted to submit their tracks.

The AY as a format, I agree, is maybe a bit silly. I'm glancing at the wikipedia page and it was in all these machines : the Intellivision and Vectrex video game consoles, Amstrad CPC, Oric 1, Colour Genie, Elektor TV Games Computer, MSX and Sinclair ZX Spectrum 128/+2/+3 home computers as well as the Mockingboard and Cricket sound cards for the Apple II family. Plus variations in arcade and pinball machines.

I really like the idea of having console/platform based formats, and y'all are probably aware that I like to hate on .vgm style register log file types. We have zx_beeper already, I couldn't argue with making a zx_ay (which includes beeper?), but then there are all these other possibilities (most of which are probably ignorable).

Making an open YM format sounds really odd to me especially considering all the chips Yamaha put out

. ym_arcade? sharp_68k?

...but MSX should probably be one. Though it looks like most of the MSX machines have a YM PSG except for certain models that have the ym2413 or ym2151.

Tha Atari ST also had several incarnations with varying audio capabilities.

This information is all highly convoluted.

On a side note I think I have an answer for the Sega Master System debate : move most of the entries we have to a new format called sms_na (north america) and then let SMS from here on out allow both the PSG and FM.

I think there is a misunderstanding, both AY and YM formats target ONLY the ym2149 and ay-3-89** PSG chips (the AY can also handle beeper music because it contains z80 code but it's another matter).

The original, historical YM format (which is a shortcut for YM2149) is not intended to support all the ym*** chips from yamaha. AY is for zx spectrum and amstrad music. YM for atari st music. (but some tools such as starkos / arkos for Amstrad music export to YM)

Here is the original tool which defined the YM format: http://leonard.oxg.free.fr/stsound.html
And the YM specifications: http://leonard.oxg.free.fr/ymformat.html

(I'm quite sure the first releases of VortexTracker could export to YM, then it switched to SNDH, which is strange considering VT doesn't exploit advanced ST tricks usually found in SNDH files)

I wish Vortex Tracker II had support for the .KSS and .S98 file formats.
Also I have a question, can hoot play the .PT3 file format?

maybe i'm missing something, have "personalities" been causing puke7 stress by flirting with him via the medium of protracker 3 files? i just don't know what you meant by that

my own contention with splitting these all up would be that hardly anyone does them anyway and the more niche they become the less entrants each compo in these formats will get. divide and conquer etc

the only one that makes even a little sense is splitting atari ST from the rest as atari ST songs do tend to sound substantively different to speccy 128, cpc, and msx, which all sound identical to each other

again i think even splitting atari out from those three formats will reduce participation in the compos and i'm not sure what anyone gains from it apart from extra pigeon-hole-ability

in my eyes it is like separating IT, XM and S3M - it would make the compos more "fair" but reduce participation and competition and probably create bickering

well... your input is considered. separating s3xmodit by now is practically blasphemy. ;P

I don't really understand the problem with PT3. You can always export from PT3 to AY when you open the pt3 file in vortex tracker. So an author who wishes to share a pt3 file (so it can be modified later) can always do that. Therefore I think the current statut of the AYM format on BoTB is already perfect as it is.

In addition 99% of entries on BoTB is converted to mp3 so it can be played easily from any browser.

Is a NSF file that uses the sunsoft-5B audio capabilities a valid entry for AYM+? x)

garvalf: so you're also saying it's appropriate for the NSF format to allow 0CC and FTM files as well? Why do we even have NSFc, FTM, and 0CC formats?

well, I don't know, why not? The only difference is 0CC format is only used in one piece of software (I don't know about FTM=> (edit) ok it's famitracker source ), while PT3 is used across different applications. And there are also several players for PT3 files on many platforms (Speccy, Amstrad CPC, MSX). Maybe this make a difference.

this may be straying from the topic, but i also never understood the point of FTM and 0CC formats and personally would not like to treat them as common-law precedent. they're both source files that don't play in any software except the (non-native! edit: and single-platform!) software that exports them, and both target the same hardware using the same export file type (NSF). so why the speciation?

wait do we really have nsf, nsf+, ftm AND 0cc as separate formats?

@jangler regarding FTM and 0CC, i've always considered it to play the emulated chip outside of hardware standards; like refresh rates well-above processing capabilities; or even submit hacked FTM or 0CC files that are illegal in spec, but still replay on the player.

essentially we're saying 'fuck it' to the 2a0x for creative purposes.

I just wanted to clarify that when I mentioned a ym format earlier it was a reference to a possible stand alone BotB format covering yamaha chips and not a reference to the file format. But it sounds like the ay/ym format is going to stand as is.

Is the only question at hand whether or not to include .PT3 as a viable file format for this entry format?

if you include .PT3 you might as well include all the other module formats into "aym". ;P

also when are we doing format submission whitelisting? that way it takes a burden away from moderation.

let's think about the actual real world where us botbrs live for a sec

i am guessing that ALL botbrs who have created zx128k music have used software that produces pt3. it's just that dominant in the zx128k music scene. the main zx128k music archives online are absolutely full of pt3 files too

you could try to derive a list of file formats to be submitted from first principles but i'm not sure why you'd want to. the reason we picked the 4 most popular dos module formats for our dos module compos is presumably because those 4 formats cover the overwhelming majority of people who make dos modules, right? the pareto principle

atari music archives on the other hand seem to be full of sndh files. AY and YM files cover the rest. i see no reason to change the current pt3/ay/ym/sndh set

BUT ON THE OTHER HAND the choice of file formats available in zx128k music compos affects me no more than it affects b00daw, so who cares?

A bit late to the party as I just came back from vacation. I don't have any strong opinions on this, but let me release a couple of random brainfarts anyway.

First of all, regarding allowed filetypes, I don't mind either way. However, I think that if .pt3 is allowed, then .stc (SoundTracker) should be allowed, too. It's not as popular as pt3 nowadays, but still widely used especially by Russian composers.

I very much like the idea of splitting aym into aym classic and aym+. However, I disagree with SIDwave and samples being disallowed in aym classic. Samples are possible on standard AY/YM, not just by using the STe's DMA. Same for SIDwave, it's totally possible to do it on a stock zx128k. These tricks are just not being done because it would cost a lot of CPU time, which is no good for demoscene purposes (which is somewhat changing lately, for example sampled drums are used in several recent zx demos). Also, where do you draw the line? Is buzzer ok for aym classic? Both zx and atari can do it, but on the latter higher refresh rates are a common occurance. How would we enforce this? Is anybody here confident enough to determine whether a buzzer effect runs at 50Hz or 200Hz?

So overall I think the better idea is to seperate classic and + along hardware lines. Anything that uses only the bare-bones sound chip is aym classic, regardless of the software tricks being used. Anything that requires additional hardware (STe DMA, beeper, turbosound) is aym+. Aside from better enforcability, this probably also has the benefit of encouraging coding experiments.

Btw the .sap format has a somewhat related problem, as it will happily play back GTIA code (!= Pokey).

Just to stay with facts.

Samples go easily on all 3 channels on AY - even with Spectrum 48K
https://www.youtube.com/watch?v=5QToYfmMygw

and SidSound works normally with Spectrum 128K.
https://www.youtube.com/watch?v=gSmIe0_qPvo


PS: Maybe it should be allowed to add regular SID songs to the AY category? ;) Hahahahha.
https://www.youtube.com/watch?v=Zr1r6FSrsz4

In a way thinking in formats was wrong...But hey, it's been an evolving experience, also, despite having a huge gray beard puke7 couldn't have know what hardware advances would happen over time ;)


AY could represent a range of hardware. Hardware which may not be represented today (msx ay, as mentioned by Xyz and his intention to play on a replayer on a desktop computer, not on the original hardware)
VGM is a similar, a logged format used to represent a large set of very different hardware to be used mostly on desktop computers...



I also like the hardware based criteria (despite not knowing the needed changes on botb and the effects of a change on the back catalog of entries)

a. Hardware classic battles (format classic)
strictly aiming at hardware playback
staying within hardware limits even when using less featured/developed tools
legacy or non legacy format as long as it respects the theorical rule of hardware playback capability (not all of us are able to test this)
baseline format proposed by botb
(this would allow those supernsf or ay entries that stream samples even if legacy formats don't support them)

b. Steroid based hardware battles (format+)
Aiming to exploit composing tools for creative freedom
The most modern/featured/developed tools even if hardware playback is not possible
legacy formats are ruled out
For a given hardware any format representation is allowed (non legacy/non interchangeable based formats from composing tools/custom tools, module based , logged formats)


This goes along the line of thinking of Xyz and irrlicht project, and puke7

undigging the thread

aym and aym+ split would be good

^aym+ poster

necroBUMP
https://twitter.com/kumokosi/status/1073896326725693441

Just wanted to add some proof that jp SMS could indeed play OPLL+PSG. Though SG1000 mkIII could not.