Sn76489an programmable sound generator questions/general propeller
I am trying to use a real sn768489an chip with the propeller and am having difficulty getting started. I'm not sure how to get it clocked correctly and would like to know if anybody else has tried clocking a IC chip from the propeller directly. I don't really want the entire propeller to run at 500kHz. Isn't there a way to do a clock on a pin from a separate cog. I'm pretty sure I have to have a clock because the chip divides the clock signal different ways to do the frequency conversions. So I might be able to get the data in, but the chip still won't work. I'm assuming I can toggle both the WE strobe and clk pin at the same time to accomplish that.
Second question is the outa[] command. If I write outa[0..7] := %10001111 the outputs don't stay latched unless follow it with a repeat(forever) statement. Even if that outa statement is the only executable code, shouldn't those still be set high or low.
My third question is more specific to the SN76489AN chip. The chip is active low and the datasheet specifies 2V as high, even though it is a 5V logic chip. So the chip should be rather easy to work with theoretically. Set OE(CE) to low to activate the chip. Place the data on the D0.D7 lines and strobe the WE pin for each bit so the chip will copy the data to the correct register. So the outa statement I wrote is for tone generator 1(there are 3) volume attenuation. In this case it sets tone generator 1 vol. to off. But after each WE strobe it should set the chips Ready line low, but I get no indication that it read the first bit. I was trying to use waitpeq to wait for the correct state after each WE strobe, but the program just hung. I am thinking there is something wrong with the latching outputs because I do:
outa[Chip_enable] := 0
outa[D0..D7] := %10001111
repeat index from 0 to 7
!outa[Write_enable]
waitpeq(%0, %10000000,0) 'pin P8 is where I have the Ready line.
but while it waits none of the LED's on the Data lines are still lit. Should I be using a latching shift register or something. I went through and made sure the dira was set correctly above this code sample. This could simply be I am trying to write data to fast. I'm just lost on how to fix this. The Sega Game gear schematic divides the clock going to it from the system clock. How can I do this with the 5Mhz crystal? Or do I realty need to use 3.3 to 5 V level shifters?
I noticed there is a SNECog in the obex but it is an emulator like SidCog. I think I'm having a clock problem, but I was wondering if any of the people from the SN76489 emulators(I think there are two different objects) have worked with a real chip at some point.
Second question is the outa[] command. If I write outa[0..7] := %10001111 the outputs don't stay latched unless follow it with a repeat(forever) statement. Even if that outa statement is the only executable code, shouldn't those still be set high or low.
My third question is more specific to the SN76489AN chip. The chip is active low and the datasheet specifies 2V as high, even though it is a 5V logic chip. So the chip should be rather easy to work with theoretically. Set OE(CE) to low to activate the chip. Place the data on the D0.D7 lines and strobe the WE pin for each bit so the chip will copy the data to the correct register. So the outa statement I wrote is for tone generator 1(there are 3) volume attenuation. In this case it sets tone generator 1 vol. to off. But after each WE strobe it should set the chips Ready line low, but I get no indication that it read the first bit. I was trying to use waitpeq to wait for the correct state after each WE strobe, but the program just hung. I am thinking there is something wrong with the latching outputs because I do:
outa[Chip_enable] := 0
outa[D0..D7] := %10001111
repeat index from 0 to 7
!outa[Write_enable]
waitpeq(%0, %10000000,0) 'pin P8 is where I have the Ready line.
but while it waits none of the LED's on the Data lines are still lit. Should I be using a latching shift register or something. I went through and made sure the dira was set correctly above this code sample. This could simply be I am trying to write data to fast. I'm just lost on how to fix this. The Sega Game gear schematic divides the clock going to it from the system clock. How can I do this with the 5Mhz crystal? Or do I realty need to use 3.3 to 5 V level shifters?
I noticed there is a SNECog in the obex but it is an emulator like SidCog. I think I'm having a clock problem, but I was wondering if any of the people from the SN76489 emulators(I think there are two different objects) have worked with a real chip at some point.
Comments
Writing commands to the chip is separate from the 500KHz clock. That is done with the D0-D7 data bits, and the /CE, /WE, and READY control lines. Once you set the 10 output pins as outputs any data you output to those pins should stay there until new data is written. No latches are needed.
Based on the data sheet the /CE and /WE pins should be high except when sending data to the chip, and the sequence for writing commands to the chip should be:
wait for the READY line to go high
output the 8 data bit pins
output 0 (low) to the /CE pin
output 0 (low) to the /WE pin
output 1 (high) to the /CE pin
output 1 (high) to the /WE pin
That is, as long as your program is still executing. If you just set the data lines and your program ends, all bets are off (as are your data lines).
Good luck with your project. If you post your ideas and designs on the forum I'm sure you will get a lot of help and advice from the experts in this area.
I'm not really into audio and synth scene, but I am familiar with the propeller and using it to interface to a variety of chips. There are a lot of ways it can be used to interface with sound chips that have such low data rate requirements. The 74hc595 is one method. With 8 parallel cogs it should be able to control multiple sound chips and even do a couple of channels of direct digital synthesis at the same time. With some creative programming it might even be possible to run more than one emulator on a single propeller.
LOL, good point. The "everybody knows that" syndrome strikes again. Always good to be reminded that it's sometimes not so.
Have a look at, http://forums.parallax.com/showthread.php/133075-Polyphonic-SIDcog-synth-WIP, for a project running 4x SIDcog objects at the same time.
Here is a video of it in action: https://www.youtube.com/watch?v=XQNfLsm7iEY#t=66.
/Johannes
I want to have a rackmountable project in the end(if only to emulate the form factor of the old Yamaha Synth), but a 16x2 display may not be enough. I ordered some cheap backup camera for a car from ebay for about $15. Before I realized I could use 74hc595 8-bit latches I knew I/O's would be a problem. The SN76489 uses 3 control lines and 8 data lines. The YM2612 uses address and data lines as well has CE and some others I can't think of right now.
I haven't looked into the source code for that project for the Arduino Uno that interfaced an SN76489AN and a YM2612 using 74HC595's, but I forsee an issue in controlling data/address/control lines in the correct timing when I am going to have at least 4 of the 8-bit latches ganged together. I have the crystals and latches on order and I'll definitely post some kind of project instruct able at the completion of this project.
And I have seen the AY chips being sold on ebay. The price is kinda high, but the fact that they are still available and in working condition make me want to interface to them directly instead of an emulated Cog. The 6581 SID is a very unique beast. There are people re-silk screening chips with tested bad filters to make them look like they came from a known good manufacturing batch. And people like me that want a midi synth kinda drove the prices and demand for these chip up. The Twin-Sid and stereo Sid projects for the actual C64 are reasons why this chip are so sought after even though the production yield was so low even while they were still in production. But all other common "chip-tune IC's" are still available without high markup prices.
all 8 COGS share the same pins, but each COG has its own DIRA, INA, OUTA register. So all COGS can at any time read INA on any pin, but OUTPUTS get or'ed together.
If a COG stops executing code it will 'float' its pins/registers to not disturb other COGS using the pins. Just some side effect of having multiple cores using the same pins. .
What irritates me that you state:
And that makes no sense at all. waitpne should just do that. wait for a change on pins compared to mask. It will not affect ANY pins.
I guess your problem is elsewhere.
Can you post your complete code for review? Easier to troubleshoot.
Enjoy!
Mike
Nothing wrong with the idea of using the propeller as the controller for several sound chips. It has the horsepower and enough pins to do so without a lot of additional chips. IIRC most of those chips used an 8 bit data bus, a few (3 - 6 or so) control lines, and a chip select/enable. Most, if not all of those except for the chip select can be shared by all the sound chips. Of course you will have to mix/add the analog output signals from the individual chips using analog circuitry.
Also, do you have a data sheet for the YM chip you can post on the forum?
Well the Ym2612 is more complex so I'm interfacing with the SN chip first. The Ym has address lines as well. This will be a synthesizer of some sort. What I am planning is:
Chips:
YM2612
SN76489(i'll have to use the AN version. the "full" chip isn't readily available without taking a vintage machine apart it seems, but AN"s are plentiful)
RA03 (NES audio -- still waiting for it from china)
SidCog(still programmable like the original, but don't have to "steal" chips from working C64's as they are also super rare)
Interface:
16x2 LCD or maybe composite out
some buttons and encoder knobs or pots
Midi In/Thru via 6N138 opto isolator
I want to be able to, at the very core, be able to assign midi channels to the various chip sounds. And the maximum function of this project would be full control of chainable "effects". Such as audio mixing outputs of the chips. Even polyphonic octaves say for midi channel 1 which might be lead melody for a song I could "double or triple" the note in either octaves or do an arpeggio across the various chips. Maybe something like when C4 comes in play C4 on one chip and E4 and G4 on the others and have the drum (noise) on SidCog. Then I could have the rest of the channels dealt with on the Midi thru port via a midi keyboard or other device.
It is seeming like I should either have serial output to a terminal for control or a graphic screen for a menu more than a 16x2. But the Yamaha T81z did single note synth with it so I might be able to devise a non-convoluted menu system. I want the project to be in a 1U 19" rack case, but it would be nice to have a screen to switch between configuration and a "oscilloscope" audio type meter for what is being outputted on the line out.
http://www.smspower.org/maxim/Documents/YM2612 - some information corrected from a famous sega2.doc
http://en.wikipedia.org/wiki/Yamaha_YM2612 - pinout and some information
SN76489:
http://pdf.datasheetarchive.com/datasheetsmain/Datasheets-9/DSA-167257.pdf
RP2A03:
http://nesdev.com/2A03%20technical%20reference.txt
Only the SN is a proper datasheet. The YM2612 is also known as OPN2 I believe. The RP chip is for the NTSC version. I haven't looked too much for the 2A07 PAL version but I haven't come across it yet.
The midiIn object is what I am using and now I just need to convert the single event long into hex bytes. I get something like this in the PST.
17580864 010C4340. Being 17580864 is the returned event 4 byte in decimal. And 010C4340 is the simple_number.spin(num.hex(value,10)).
I need it in 01 0C 43 40 format. So I'm looking to setup an array of byte values[4]. Can't figure that out yet and it should probably be done in assembly for speed.
Something like a switch would be ideal.
Switch(values[0])
case '$00' ' note on
noteOn(values[1],values[2],values[3]) 'where the proto is noteOn(channel,note,velocity)
case '$01' 'note off
..etc
Although the noteOn simply isn't generating a freq. It would pass through all the configuration business for the desired effect. Like reading knobs or whatever and eventually "turn-on" the note on the desired chips via the data/address busses.
although I am giving code structure examples in c/c++ I am not longer very familiar with those languages and do intend to program in Spin/assembly(if absolutely required)
FYI, the propeller can generate the frequencies (or very close to) the 500Khz and 3.579Mhz for the SN and a 7.68Mhz for the YM chip, so external oscillators are not really needed. In the meantime I will look at the 3 chips with a view to sharing as many of the data and control lines as possible. For sure the data lines can be shared, and perhaps the /R & /W lines.
I want to get the best bang per buck here. So while multiple props wont break the bank a custom etched PCB would require an extra 40 pins per prop to be drilled. Unless I need more than 2 props I don't want to go SMT. I can get more SMT solder kits to hone my skills, but my previous SMT attempts required tedious 30awg wire bridges to fix "burned" traces. Ordered PCBS are out due to the cost. Depending on what this project turns out to be I may kit this and sell off PCBS, but I don't know what I can offer that hasn't been done before. Frankly speaking, a quickstart or protoboard with SidCog and a midi port mounted in an enclosure would be a much cleaner solution and suitable for most people that would "KIT" a midi synth. This project is a one-off for my purposes, mainly experimentation, and I may wish to get everything working and allow the controller board to be accessed as a tracker. That way it would be similar to the the SidSerialPlayer and allow people to steer clear of VST's in software and use the real thing. Writing a c# program to access the board to use any chip individually shouldn't be a problem. I have enough c# experience to accomplish that much of it. I really do wish there had been more work converting SID files to General Midi., but even that isn't impossible.
I want to view the Synthschool.org video's, but they are from 2005 and there is no indication that the site is will ever offer its content again. So I don't have any expertise in synth, but I want to learn. There is a variety of Synth "players" from everything from pics to 8051's to Arduino, so anything I come up with will have to be very unique to offer commercially.
The SN76489 was the first one I ever got to work and I was amazed at how easy it was and how AWESOME the music sounded.
Anyway, maybe this might help a little but here are some snippets of my C++ code that plays music.
Let me know if you have any questions.
void SignalDEV_Audio::writeShiftRegisterA(byte value) {
// Pull latch low
digitalWrite(SR_74595_RCK, LOW);
// Shift control out
shiftOut(SR_74595_SI, SR_74595_SCK, MSBFIRST, value);
// Pull latch high to enable control data
digitalWrite(SR_74595_RCK, HIGH);
}
void SignalDEV_Audio::writeSN76489(byte b) {
writeShiftRegisterA(b);
// Strobe SN76489_PIN_WE
digitalWrite(SN76489_PIN_WE, LOW);
delayMicroseconds(5);
digitalWrite(SN76489_PIN_WE, HIGH);
}
I have taken a look at the signals and timing requirements for the SN76489AN and the YM2612.
The SN is the simpler of the two to program and interface to. It requires 10 inputs (not counting the clock) and one output. The YM requires 14 inputs (not counting the clock) and one output. Of those 24 inputs 9 could be shared with careful attention to the timing requirements of the two chips.
That leaves you the following options:
Dedicate 26 propeller pins (11 for SN, 15 for YM). This would be the simplest as far as programming goes, but leaves very few pins for other things.
Dedicate 17 propeller pins (share 9). This would make programming more complicated but leaves more pins free.
Use 3 74HC595's to control the two sound chips and a cog running PASM to combine the data for the two chips and send it to the '595's. This requires only 4 propeller pins and allows for the software to treat the two chips separately. A 74HC165 or 597 will also be needed to read data from the ym chip.
writeShiftRegisterA(b);
// Strobe SN76489_PIN_WE
digitalWrite(SN76489_PIN_WE, LOW);
delayMicroseconds(5);
digitalWrite(SN76489_PIN_WE, HIGH);
}
So we aren't strobing WE for each bit to shift in? Just once low the back high? So you just place the data on the data lines(via a shift register in this case) and toggle WE once. Is this correct?
http://www.ebay.com/itm/121274097734?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
a programmable oscillator. It will be useful for breadboard testing of various chips. but I am still at a loss for finding a 500khz clock for the SN chip. It is kind of looking like using shift registers will allow me to use just a single propeller if programming is done in PASM, but I'm still unsure if they chip will be "maxed out" if I attempt to generate the clock for the SN on the propeller itself. I'm actually very unclear on the concept of crystal vs. oscillator. I see the 2 pin variety that is recommended for the propeller chip and sold by parallax. Is this a "crystal"? and the 4 pin(16 dip package) an oscillator? The pinout of the prop has XI and XO while the SN has just clock. If anybody could elaborate further it would be very beneficial to me. I did see some 500 kHz 2 pin "crystals" on ebay. As I am not an electrical engineer I tend not to dig through mouser or digikey for parts unless I need a lot of the same part, like 100 270 ohm resistors or something similar. Far cheaper to source than parallax or sparkfun,etc. I hope that further sales at parallax will help the prop 2 become reality, even though I know I am paying more for resistors or other passive components.
I did order some 74hc165's as well.
I do thank everybody for their patience with me in this project. This is a very forgiving community.
wait for the READY line to go high
output the 8 data bit pins
output 0 (low) to the /CE pin
output 0 (low) to the /WE pin
output 1 (high) to the /CE pin
output 1 (high) to the /WE pin
Right. Other code first shifts the data out to the '595 serial to parallel shift register. Once the data has been shifted out and transferred to the '595 output pins the /WE is toggled once to write the 8 bits of data to the SN76489.
Yes, those are crystals. A crystal is a tiny piece of quartz with an electrode on each side. It needs some external circuitry to make it oscillate, and that is an internal part of the propeller chip with connections to XO and XI.
An oscillator or clock generator is a chip containing a crystal and circuitry to make it oscillate. They will have at least 3 pins (power, ground, and signal out) or more, depending on how many functions it has.
Lots of knowledgeable helpful people on this forum.
And kwinn wasn't paying enough attention and got the last two lines reversed. Should be /WE high before /CE goes high.
Also keep in mind that if you use '595's for talking to the sound chips those signals and the data bits have to be shifted out to the 595's properly to produce the correct sequence of the above pulses. Not really that hard or complicated, but a lot of detail and bit banging to get right.
As a point of reference I am measuring Hz on P17(APIN) and the propeller Vss(ground).
I haven't had much luck in communicating with the SN chip, but I'm off until Thursday after today so I'll have time to mess around. And I did receive my '595 shift registers.
Most stuff you write to chips are going to be too fast to "see"". But does anybody know of like bar segment LEDS with built in resistors and a common ground? Really hard to breadboard that and I still haven't gotten my 3.5" rearview composite monitor from china. I'm on a ThinkPad windows tablet 2 and the usb port doesn't like to be send through a hub for some reason. For the time being I'm using Parallax serial terminal and LED's for indicators.
Is there a tutorial for wire wrapping on proto board somebody can point me to? My dealings with 30AWG wire wrap have been annoying. It seems like I am handling the wire too much trying to strip it and it always become brittle and breaks before I can wind it on the components. I even tried just using a soldering iron to melt the insulation instead of stripping and haven't had much success. Other than front and rear connections I can pretty much do this entire project in wire wrap instead of a etched board.
Not necessarily. It depends on the counter mode, and for a simple frequency out (mode %00100) BPIN is not used so it can be used for something else like output from the counterb for the second sound chip.
Using a cog and PASM should make writing data to the sound chips take less than 1mSec., so I don't know if a bar segment led will be much help unless the speed is changed for debugging. I don't know of any with built in resistors, but a one or two sip resistor networks makes using a standard one simple enough.
There is/was a tool called a slit and wrap that slits the insulation as you wrap it around the post making wire wrapping much easier. If you can find it buy it. If not there are tools that have a small slit you can slide the wire into, push it down, and pull the wire out to strip the insulation.