pser1 escribió:
Much to my surprise the FM77AV seems to have a defined protocol to deal with the AY chip and the YM2203 they name FM
First of all the programmer *must* select the register to work with. That's accomplished doing :
- for the AY-3 chip the register number must be sent to $FD0E and then $03 and $00 must be sent in sequence to $FD0D
Once this step has been done, we can either read the current value or write a new value in it
-- To write we send the new value to $FD0E and then we must send $02 and $00 in sequence to $FD0D
-- To read the current value in the register we must send $01 to $FD0D, then we read the value from $FD0E and finally we send $00 to $FD0D
- for the YM2203 we must do the very same procedure but changing the port numbers:
-- $FD16 must be used instead of $FD0E and $FD15 must be used instead of $FD0D
Ok, confession time
Over a month ago, reading older posts, i stumbled on this
http://retrowiki.es/viewtopic.php?f=33& ... p200086630, a PSG sample of malikto999. It seemed really easy, so i wanted to try it.
As i am a very big fan of the AY sound (being a zx spectrum user myself), i then started to think about a player of those tunes. .AY files were discarted very early, because of the z80 emulation needed, but the .ym file format (by Leonard/Oxygene) seemed an easy target. Each vertical retrace, output one sample. And that's what i do, take a YM song, process it on the PC, and each vsync, output the 14 registers values onto its place. The player (or better said, the "replayer") code is as easy as this:
Código: Seleccionar todo
for (a=0;a<samples;a++)
{
vsync(); //or a fixed loop simulating a 1/50 delay for accurate PAL timing
for (b=0;b<16;b++)
{
unsigned int ff;
ff=ofsy + (a*16) +b;
PSG_DATA[0]=b;
PSG_CTL[0]=3;
PSG_CTL[0]=0;
PSG_DATA[0]=buffy[ff];
PSG_CTL[0]=2;
PSG_CTL[0]=0;
}
}
(note, the 16 part instead of 14, it's because the YM was for Atari ST, and this chip has 2 "more things" that not all songs uses, the rest are "standard" AY-3- chip format. PSG_CTL is $FD0D PSG_DATA is $FD0E)
That works, and sounds. As the songs i try (for now) are PAL amstrad tunes (1Mhz), it sounds about right, though at a faster rate if you use vsync because PAL/NTSC timing.
But it works for a few seconds (small RAM buffer), i don't have memory for much more (unpacked YM songs could be 200KB).
I then thought about a YM file player, but it doesn't work that way, i would need to create a lha unpacker, then be prepared to de-interleave 200KB or more of data. Not feasible, directly. But i could convert the format on PC to another one. And i'm still on this step
, trying to come up with some kind of compression (a YM file format is a dump of a tracked song, so definitively there must be some kind of pattern) and/or make it "streamable" (play on the fly as i decompress, and forget the old data). And i would definitively need also put the "player" code on a timer event (IRQ) of 50hz, to allow for streaming of data (as i can't have all in memory at once).
After that there would be the considerations of "resampling" of files captured with other machines at 2Mhz, etc...but that would be a bonus and could be done on the PC.
Overall, that's a very tall order, but stranger things have happened
.
Anyway, that player is was what i was referring to when i said i have working sound code.
I replaced as is the $FD0D/$FD0E for $FD15/$FD16 and it sounds the same, but what it's even more disturbing, mixing them ($FD0D/$FD16) works
. But keep in mind that i only test on the XM7 emulator!
Reading again the I/O map, $FD0D/$FD0E is the FM7 port for PSG (standard for all the FM7 family), translated by google as "FM sound source shared") ,and 4 commands (high impedance, data read, data write and address register). The $FD15/$FD16 is translated as "FM sound source", its exclussive to AV family and it has the older commands plus two extra ones (status register, read joystick port).
So in theory it could be that new ports are for the added commands, and they (Fujitsu engineers) couln't retrofit the new commands onto old adresses because of compatibility reasons (the FM7 system manual clearly says that only lower 2 bits have sense, but lazy programmers, you know..
). I don't know, it's just speculation.
pser1 escribió:
I asume that the music chips are been managed by the subsystem, so the ROM code that deals with this functions expects these
different sequences for each one
For what it's worth, on the FM7 system specifications manual, the block diagram says that PSG is connected to main cpu.
pser1 escribió:
That said, this only tells us how to use the FM part of the YM2203. That chip has also two parallel ports each 8 bits that can be
input or output upon configuration (I don't know what is their default behaviour ...)
I must confess, again, that i don't know jack about that
. I mean, i keep reading about the AY/Yamaha FM chips on wikipedia and it's a "festival" of models and submodels with subtle differences, PSG/SSG/OPL..i lose track easly
I have read about the extra paralel ports on those chips, but i don't know what they are about... are those digital DACs for sampled data?
Anyway, i don't know how those extra features (if pressent) would be accesible through the I/O map
(baring XM7 issues, but i doubt it). The secret is obviously on the code, so it's a matter of time 
PC 386 
