kamelito wrote:Does that mean that the Oric is not capable of running *.snd file ?
Well, I guess that what you call SND files are actually file in SNDH format, that can for example be replayed by WinJAM.
These files are the exact equivalent of the .SID files. They contained both the music AND the replay routine. This means that the replay routine has to be executed for the music to play... in the case of the SID, the processor is a close cousin of the 6502, so it is possible for the Oric to play the code straight (with some quirks due to the differences in memory mapping between the C64 and the Oric). All you have to do is to interpret the commands sent to the SID chip, and transform them as something somewhat equivalent on the AY chip.
For the SND files you cannot do the same thing, because it would mean executing 68000 code on the Oric. Even if a music player only takes something like less than 10% of the total CPU time of an Atari ST, it still means you have a 1mhz 6502 processor to emulate 10% of the speed of a 8mhz 32 bits 68000.
I don't know for you, but me I'm not able to do that
Of course if you manage to do it, the easy part is that what you get can be directly injected in the AY soundchip (eventually dividing by two the frequency of notes to compensate for the difference in frequency between the two sound chips).
kamelito wrote:Can you explain why the musics have to be converted?
I theory we could convert the player, but this would be a tremendous work. Basicaly it's like writing a offline emulator able to transform 68000 code in 6502. And that's not easy. That's why musics need to be converted.
The easiest way is to ditch completely the player, and just replay the song dumbly.
Since a music player on the Atari ST typicaly is called from the screen refresh interupt, it means we have 50 (or 60 in NTSC) updates each second. The AY chip has 16 registers, but some are used for input and output ports, and thus are not part of the music. What remains is 14 registers.
If we just (on the Atari ST) modify the replay routine to write into a buffer in memory instead of sending registers values to the soundchip, we can then store the complete tune as just a list of registers to send back later.
It's what I did with the Trust music in my first Oric big scroller. (and it's actually something I was already doing in 1990 on the Atari ST to avoid spending processor time on playing the music

). And it's something that Leonard did later with ST Sound. All these .YM musics are just compressed dumps of YM registers.
Memory wise, this is not very efficient, that's why people does not store raw registers dumps.
14 registers saved x 50 times per second, means we need 700 bytes for each second of music. That's 42000 bytes for one minute. As you can see we cannot store a very long tune one the Oric using this method.
But there is ways to improve that. First you can use the fact that not all the bits of the registers are used. Here is the list of all YM registers:
Code: Select all
Register Array
B7....B0
R0 Frequency of Channel A 00000000 8 bit fine tone adjustment
R1 ----0000 4 bit rough tone adjustment
R2 Frequency of Channel B 00000000 8 bit fine tone adjustment
R3 ----0000 4 bit rough tone adjustment
R4 Frequency of Channel C 00000000 8 bit fine tone adjustment
R5 ----0000 4 bit rough tone adjustment
R6 Frequency of Noise ---00000 5 bit noise frequency
R7 I/O port and mixer iinnnttt i-I/O, n-Noise, t-Tone
settings bacbacba
R8 Level of channel A ---mllll m-Mode, l-Level
R9 Level of channel B ---mllll m-Mode, l-Level
RA Level of channel C ---mllll m-Mode, l-Level
RB Frequency of envelope 00000000 8 bit fine adjustment
RC 00000000 8 bit rough adjustment
RD Shape of envelope ----cath c-Cont, a-Att, t-Alt, h-Hold
RE Data of I/O port A 00000000 8 bit data
RF Data of I/O port B 00000000 8 bit data
Obviously it is possible to put together some of the 4 bits registers. R1 and R3 can both fit in one single 8 bit value, and the same goes for R5 and RD.
Just doing this already reduced the memory consumption from 14 to 12 registers.
R6, R8, R9 and RA are all 5 bits registers, and R7 is having 2 free bits (we do not care about the status of the I/O port. This means that we have 3*3+2=11 free bits. Enough to ditch one more register.
So we finaly end-up with 11 registers to store each frame. If we do the same computation that earlier, this is 11*50=550 bytes per second, and 33000 bytes per minute. Still not awesome, but at least without doing much work we have won 9000 bytes.
But it's possible to get even better by using compression.
The YM files are not usable on the Oric because the packing method used oblige to get the whole file unpacked in memory to be able to read it. It obviously works fine on PC, but on an Oric it's not possible.
It's why some people (on MSX, Amstrad and Sinclair) have been working on this. And they made the MYM format. It does not compress as well as YM, but at least it's possible to unpack progressively using just few buffers.
Code: Select all
Sure share the code and explain us how to use it :)
I will do that later.
To late for today
