Well between the poor performance and the bad chips it's pretty hard to get excited about it. It's sad since you put so much time and effort into the firmware. The only thing the AY seems to bring to the table is accurate frequency tones, but with only square waves this could probably be done with the PicAxe alone. Funny that you mentioned the Yamaha YM2149 part, because I had the datasheet in front of me when I sent the last email and read 5 bit D/A and was thinking the AY was the same.

I ran a few more careful tests on the 5 chips I have (1 from three years ago, four of this week). Here are the results:

---the tones work in all
---the noise generator works in two (both new)
---one has a very bad S/N ratio when either tones or noise are on
---two fail to drive the LCD; faulty Port IOB, I guess
---the envelope stinks in all (bad clicking).

Only one of five works from top to bottom.

This ain't the touchstone, methinks. Anyone up for interfacing the SN76477 with the Picaxe 28X2 via a DAC?

I noticed that the YM2149 chip has a SEL pin 26 that allows for master clk/2, so you can use a 4 MHz clk if you want. SEL = High - normal AY-3-8910 mode, SEL = Low - sets clk/2.

I would definitely be interested in interfacing the SN76477 with the Picaxe 28X2 via a DAC. Microchip makes a great little dual 12 bit DAC, MCP4822 with a SPI interface for about $3 bucks. Why not put the YM2149 and the SN76477 together. Then you could have chord generation, VCO, LFO, tuneable noise, etc., etc.

Way back in the old days when I had my trusty Apple II+, I managed to get 3 of the AY chips, and slap them in a prototype card I could control with my apple. It was pretty frustrating - I could get the tones, but as you guys have discovered, the envelope control makes the final result pretty non-musical.

I think with variety of embedded processors available today you could really do a whole lot better than spending time with the AY - just do everything in software and dump the results to a 10 or 12 bit DAC.

According to the Wikipedia page on the AY-3-8910 the chip does indeed have that vintage sound known from 80s arcade game consoles (cf. sound sample on Wikipedia). Do your chips sound worse than that or did you expect something different?

I bought 3 AY-3-8910A (0047 CBY, US$ 6 apiece at arcadechips.com) when I first heard about the AY voice, so I was looking forward to this project. But I'm also on board if you choose to switch to a different, better chip. It's a cool project so far, and while I haven't built the board yet (being a slow board designer/solderer) I actually do read the code!

Attached is my most recent draft of the AY-Voice code. It is the complete Setup portion, and now includes the writes to the AY registers. To become a finished project requires someone to create the MIDI portion. THeff has already sketched this out in his demos. To finish that, we need to:

1. Fill out all note numbers (LSB and MSB) from C1 to C9, and store them in program memory (not eeprom which is where the LCD messages reside), using the TABLE command. This is still under the 256 byte limit.

2. Include provision for running status.

3. Include provision for sensing either NoteOn with 0 velocity or NoteOff.

I debated trying to code the other MIDI bits blind, but I figured unless no one else is willing to take a stab at it, that would probably be a bad thing, given that I don't have enough HW working to do any real testing (I've gone backwards, and the LCD which was working isn't any longer).

The menu/navigation system works great! Man that is quite a chunk of code!

I heard back from Billy at BG Micro and he was very apologetic about the defective chips. He has pulled them from the sight and said we could return them if we wanted to. He was very surprised and said that he has been selling this same date code chip for the last five years...weird huh?
I guess GI had a real process problem when they made this batch of chips.

elmegil,

Your note table looks good, but it actually starts with C0, which is MIDI note #12, 16.35 Hz. So all of your table addresses need to be shifted down by one octave.

I wonder if your LCD problem is because of a funky I/O port on the AY chip?

While you are trouble shooting you can at least use the SerTxd( ) and send the data to the PC terminal.

BTW, I just got laid off from my job of 4 years at Foxconn on Friday morning, so I am not sure how much I will be on here for a while.

Here's a sketch of a MIDI processing subroutine. It is to be called for each byte received on the MIDI channel. It will assemble the required bytes and then call a handler for each message recognised. It handles only channel messages.

These are the assumptions:
1. Real time messages can be received anytime, even within other messages. They don't reset running status.
2. System common messages do reset running status. I don't process system common messages here. Data bytes (e.g. of a sysex dump) are simply ignored until the next valid channel message arrives.

I have not tested it, because I lack equipment, and the syntax is likely spurious.

Your MIDI processing subroutine looks very interesting, I will play with it when I get a chance.

elmegil,

I added octave 0 and 9 to your table just for completeness and attached a program that steps through C1 to B9 and plays the notes on Tone A. I found that the note pitches are whacked out below B0. I guess the AY dividers don't work right below 30 Hz. The program also shows the stepping info on the PC terminal. If the terminal does not come up automatically you can bring it up under the PICAXE menu. Set your baud rate to 76800 (9600 x 8, for 64MHz clk). If you un-comment the #Terminal directive at the beginning of the program it will set the Terminal up for you.

The chip should work down to B0. If you check the MSB below this you'll see it exceeds the required four bits. I elected to start things at C1 just to start on a C like a typical keyboard might, but include B0 if you want.

On the high end I decided to stop a B9 just to have 9 complete octaves. By this time the MSB has been zero for quite a while and the LSB doesn't allow much wiggle room for accuracy. (See the chart I posted earlier for the divisors). In fact, the tuning is pretty bad from C6 on up.

So C1 to B9 seems like a reasonable scale.

I think the data sheet for the Yamaha chip is inconsistent. The divide-by-two feature could add one more useful octave, but it's unclear to me the chip really can handle a 4 MHz clock. Look at the first spec on page 10. Now if it said when !SEL is low, then I'd believe it. But with our current 2 MHz clock, we could get a very accurate C0-B0, supposing anyone could hear it! (Feel it might be a better phrase).

I haven't checked to see if the Picaxe can put out an accurate 4 MHz clock on the PWM pin. That might be pushing it, for all I know. But the 2 MHz one sure is accurate.

For anyone having trouble getting the LCD going, THeff's comment should be kept in mind. Out of my five AY chips, two had defective ports. Did I mention that in one of the chips, absolutely nothing worked properly?

Some twenty years ago I bought 1000 NOS Reticon SAD-4096 analog delay chips for a pretty penny. After testing, only around a dozen worked!

The MIDI code is most welcome. I like the fact it implemented without subroutines, believe it or not. The Picaxe has a limited stack (8 deep if I recall), so we need to keep the calls-to-calls under control. But more importantly, even with a 64 MHz clock I worry a little bit out the speed. In-line code with lots of gotos will probably be faster, even if harder for humans to follow.

Unfortunately it seems that my ancient Keyspan USA-19HS (High Speed, HA!) is not liking 76800 baud with the MAC drivers (even the latest ones available). Since that is a fixed rate (from what I can tell of the PICAXE Docs), I'm pretty well out of luck there too, in the short run at least. The Keyspan docs aren't 100% clear, but everything I can find online implies that it tops out at 57600. Even when I try using other serial programs (the MACAXEPad terminal tops out at 38400, but I can use other built in utilities to watch the port), I get nothing but gibberish, even when explicitly specifying 76800,8n1.

Another day I will resume trying to work with the sparkfun adapter.... I have another headphone adapter so I think I will try to wire it with the termination we were discussing and no 22K resistor and see where I can get that to go.

Another alternative is to boot windows; I have a couple different virtual machines available, or worse comes to worse I can boot windows in bootcamp (set up already for other software that doesn't play nice). So I'll get there...it's just the long way around right now.

The russian stacking dolls of impediments to moving forward just keep getting deeper. Have had no success yet getting an environment set up that I can actually view the debug info, and my second AY chip appears to have deteriorated further. More are on their way, as well as the Yamaha chips.

I got a couple of the YM2149 Yamaha chips today and plugged them into the perfboard. The I/O ports work, meaning the LCD and Gates, but there is no audio, tones or noise. I figure it is probably a subtle setup change that is needed between the YM & AY, but not sure.

I played around with the new date code AY-3-8910 chips and found out that they are NOT BAD after all.

I connected the Reset pin of the AY chip to pin 17 of the PicAxe and sent it a reset pulse after power up and the noise works fine on all four of my 0426 chips.

After that I connected a pullup (1.8k) resistor and a (4.7 uF) capacitor to the reset pin and that works too. Just putting a pullup resistor will not work. Apparently it wants a solid reset after power up.

I still have not been able to get any sound out of the Yamaha chips. I don't think they are bad. I think it is going to be a programming sequence/timing issue. I played around with the Reset just like the AY, and also the BDIR pulse width, but neither gave me sound.

Well....this is quite interesting.... I now have debug data. However, it's not what I expected it to be/how I expected it to be. Just to document my journey, in case anyone else gets into the same space...

I went back to my original Windows XP virtual machine (VM), uninstalled the drivers, and ran a utility called "CCleaner" to clean up the registry. It took several tries before it ran clean. I was not able to use the AXE027 drivers, because the SparkFun board identifies itself differently, so i was back to using the FTDI drivers.

I plugged in the board, installed the standard FTDI drivers, and then I followed the instructions on this page:

Selecting 300 baud (per those instructions) still did not work, and selecting 76800 did not work either. Initially (before the registry change) selecting 76800 would complain that I needed to use the AXE027 drivers to get non-standard baud rates. AFTER the change, it would allow me to select that value, but I was still getting gibberish.

I tried all the other standard baudrates, and anything beyond 600baud was getting me output, just not the output I expected.

I figured I'd try all the "Non-standard (AXE027 only)" baud rates as well, and I found that 48000 IS working and showing me the output in normal text.

Honestly, I have NO idea why this would be the case, but I'm pleased that I have successful serial debug output, so I'm not going to look the gift horse too closely.

i had the wrong resonator in... So in addition to the serial port being off (and that makes sense; a 4MHz clock gives 4800 baud, so of course 10 x 4 = 40MHz clock gives 48000 baud), my MIDI input was seriously off.

I was led here because I was seeing 2 bytes fo any given MIDI key event rather than 3. As I started to write about what was going on, it occurred to me that a slow clock would do this; I had been switching resonators when I was doing early-mode testing and so I picked up the one sitting on the bench and sure enough it was the 16, not the 10.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.