This is the chip inside the popular ACORN BBC MICRO, a computer I programmed in the 80s. I remember tinkering with the sounds from the chip in BASIC. Yes, if you were around the arcade in the 80s, the tones from this chip is the sound you'd hear (and others like AY-3-8910 and AY-3-8912 etc). Thank you - Best wishes from the UK
In regard to the 'READY' pin.... It was best connected to an 8-bit CPU's /WAIT pin (like on z80), or /HALT pin (like on MC6800). So polling in the manner you described might not really be the suggested implementation. But great video! I'm messing with one of these and learned a lot.
The pitch of the white noise being dependent on channel 2 would explain why the music in Alex Kidd in Miracle went weird when you jumped or used the ring or power (the thing many people my age called "bullets").
The sounds programmers were able to get out of these little devices was amazing. I am not familiar with that game you mention - but these retro sound devices had so many limitations. Its funny to see how far from a sine wave the output of these devices is. Thank you for the comment
Hi on the LM386 pin 2 go's straight to Ground put a .1uf between pin 2 and Ground it will save the life of the LM386, this is a mistake a lot of people make, I found this out 40 years ago when a LM386 kept falling.. Cheers great video.
@@na5y Years ago when I was in the electronic design game and what a game it was.. I used a LM386 as a audio amplifier and strange things were happening LM386 was becoming unstable and then gave up the ghost, a quick look at the circuit of the chip and emitter of one transistors was on pin 2. lifted pin 2 with a .1uf and everything work great. Look me up on google Cheers 73 G0UIL
Outputs driven from 3.3v TTL devices to 5v TTL devices don't need level shifters, they're needed only when 5v TTL devices are driving the inputs to 3.3v TTL devices. Anyway the STM32F401/411 (the black pill in your video) is TTL & CMOS compliant and 5V-tolerent on all its I/O ports so level shifting is indeed unnecessary. If simple level shifting is needed (e.g. 3.3V TTL driving 5V CMOS), you could use any 74HCTxx gates. There are also proper level shifting ICs (e.g. 74LVC4245) available that could operate at high frequencies, but they are smd devices (to use them will need smd to DIP adapter boards and some minor smd soldering).
I have been playing with one of these devices, but I was really confused about the data pins and register bit names. Normally the MSB is D7 but on this chip it is D0(!). Very confusing and it took me some time to figure out. The bit field groups are also backwards in terms of LSB and MSB. Thanks a lot TI !!! Also the behaviour of RDY was very peculiar. I looked at it on the scope and it didn't behave as I expected. Just a heads up to anyone thinking of using it as a WAIT signal to their CPU. In a datasheet I see a circuit to avoid this issue, by using an AND gate to mix RDY and an external chip select into CE, and connects RDY (out) to WE (in). When chip select goes low this forces CE low, which triggers RDY to go low, holding CE low and allowing the release of external chip select (it needs to be > 150ns to trigger RDY). RDY being low keeps WE low for the correct amount of time. If doing this you should latch the data inputs so they remain static until the next write. Note: when I used an Arduino pin to hold WE low for several hundred microseconds, RDY toggled up and down, because I believe multiple writes were being triggered. So I recommend this circuit. It's in the June 1984 TI datasheet.
I'll have to check out your suggestions. This was an interesting IC to play around with. The sound waveforms generated are nothing like the smooth output we see in modern sound devices. Thank you for the comment!
Do I understand correctly that your clock signal is 400KHz and that matches the unexpected 'noise' in your output signal? Could you increase the clock frequency and thereby raise the frequency of the noise?
I wasn't clear on the clock. I had a 1 Mhz PWM signal generated in the STM32 and I was passing that directly through to the SN76489 and not using the level shifter. I think the noise in the output is just artifacts created by the way SN76489 synthesizes the audio. Having said that I didn't try different clock frequencies to see the effect
15:08 Sorry I am a beginner to programming. The 3 play commands are one after the other. So how is it that they all write to the 3 channels at the same time?? Won't there be the tiniest of delays that throws off the the perfect timing?
There certainly would be a small delay - but we are likely talking about a delay of 20 or 30 microseconds. That delay would be imperceptible to a human listener. Thank you for the question and good luck with your programming!
@@na5y I see! I also noticed you seem to be using divides a lot in your code. Won't this drive up the delay? (In calculating the variable tenBitValue). Why not move that to a global variable so we only compute it once? When messing with an arduino nano and buzzer, a simple modulo done when bitbanging 'bits' to the piezobuzzer to create my own square wave at my own frequency caused a very perceptible reduction in frequency, implying it took time How is that your board computes divisions fast?
@@Sh-hg8kf You didn't say what device you are using so not sure. The STM that I was using runs at 160 MHz - you can do a lot of computes without it affecting anything really. Obviously there are many cases where optimization is key. For example if you are doing digital processing of a digitized sound stream then you do have to be very aware of what compute cycles you have available. With this sound chip I am just setting register values and the sound chip itself is forming the output sound. It can be very difficult without specialized equipment (an oscilloscope for example) to see exactly where the time is going. Any debug statements you put in there will greatly affect the timing as writing out of the UART is an expensive operation. To answer your question though - that board could do millions of divides per second - so this example it wouldn't affect the result.
@@na5y I'd mentioned I was using an Arduino Nano. It's not the fastest yes, but even a single divide causes a notable slow down which I find very very odd Speaking with reference to your SN76489, is there anyway to write to it "parallely" or to trigger all channels at once instead of one by one? Everything is communicated over one write line so that makes it hard. Is there anyway to "freeze" the chip but keep the writes open until I've done the writes I want and then "unfreeze" the chip?
@@Sh-hg8kf I don't know if theres a way to do that. You could potentially mute all channels, do the write and then unmute all channels. You'd probably not see much of a difference though.
At 11.40 ish why don't you write the 8 bits directly to the port so that the port changes all at one time, much faster and they way it should be done. I don't know why the arduino IDE does not have a port write built in that everybody knows about. Great video still, I love to see old chips interfaced to moden uC.
You know that's an intriguing suggestion to show the difference between going through the HAL to set the output pins and driving the ports directly. I might do a video on that for fun! For GPIO on the STM series there is the output data register for that purpose. So if you want to, for example set all lines PA0 - PA7 to ones you would GPIOA->ODR |= 0x000000FF; Thank you for the comment - it is tough work operating below the HAL - but important to know that its all there.
@@na5y Been working on embedded systems for more years than I care to remember. I just don't understand why people are lead to read and write to a port one bit at a time. It's one 8-bit port not eight 1-bit ports. I think a video is a good idea.
This is the chip inside the popular ACORN BBC MICRO, a computer I programmed in the 80s. I remember tinkering with the sounds from the chip in BASIC.
Yes, if you were around the arcade in the 80s, the tones from this chip is the sound you'd hear (and others like AY-3-8910 and AY-3-8912 etc).
Thank you - Best wishes from the UK
Very nice video, it's a crime your channel doesn't have more subs!
Thank you for your kind words Ashlyn
Well explained and useful. Thank you. Keep these videos coming!
Thank you Kevin!
In regard to the 'READY' pin.... It was best connected to an 8-bit CPU's /WAIT pin (like on z80), or /HALT pin (like on MC6800). So polling in the manner you described might not really be the suggested implementation.
But great video! I'm messing with one of these and learned a lot.
Thank you Tyler - I was wondering how it worked. I'd love to do more retro stuff but there's never time ;) - Thank you for the comment
Great video! Thank you for sharing your knowledge and showing the code. I enjoyed the demos as well.
Thank you for the comment - glad you enjoyed!
The pitch of the white noise being dependent on channel 2 would explain why the music in Alex Kidd in Miracle went weird when you jumped or used the ring or power (the thing many people my age called "bullets").
The sounds programmers were able to get out of these little devices was amazing. I am not familiar with that game you mention - but these retro sound devices had so many limitations. Its funny to see how far from a sine wave the output of these devices is. Thank you for the comment
Hi on the LM386 pin 2 go's straight to Ground put a .1uf between pin 2 and Ground it will save the life of the LM386, this is a mistake a lot of people make, I found this out 40 years ago when a LM386 kept falling..
Cheers great video.
Thats a great tip - thank you. I haven't seen that technique - do you have a reference, I would be interested in reading.
@@na5y Years ago when I was in the electronic design game and what a game it was..
I used a LM386 as a audio amplifier and strange things were happening LM386 was becoming unstable and then gave up the ghost, a quick look at the circuit of the chip and emitter of one transistors was on pin 2. lifted pin 2 with a .1uf and everything work great.
Look me up on google Cheers 73 G0UIL
Thank you for the tip I will have to try that out - Cheers, Ian
Ahhhh laser cutters, RC, scopes and electronics...Perfect :) Cheers
Yes - I haven't done any RC for a while. Had to practice on the sim a bit!
Outputs driven from 3.3v TTL devices to 5v TTL devices don't need level shifters, they're needed only when 5v TTL devices are driving the inputs to 3.3v TTL devices. Anyway the STM32F401/411 (the black pill in your video) is TTL & CMOS compliant and 5V-tolerent on all its I/O ports so level shifting is indeed unnecessary. If simple level shifting is needed (e.g. 3.3V TTL driving 5V CMOS), you could use any 74HCTxx gates. There are also proper level shifting ICs (e.g. 74LVC4245) available that could operate at high frequencies, but they are smd devices (to use them will need smd to DIP adapter boards and some minor smd soldering).
Thank you very much for the info David. It's good to know I don't need those level shifters. I was kind of erring on the side of caution here.
I have been playing with one of these devices, but I was really confused about the data pins and register bit names. Normally the MSB is D7 but on this chip it is D0(!). Very confusing and it took me some time to figure out. The bit field groups are also backwards in terms of LSB and MSB. Thanks a lot TI !!!
Also the behaviour of RDY was very peculiar. I looked at it on the scope and it didn't behave as I expected. Just a heads up to anyone thinking of using it as a WAIT signal to their CPU. In a datasheet I see a circuit to avoid this issue, by using an AND gate to mix RDY and an external chip select into CE, and connects RDY (out) to WE (in). When chip select goes low this forces CE low, which triggers RDY to go low, holding CE low and allowing the release of external chip select (it needs to be > 150ns to trigger RDY). RDY being low keeps WE low for the correct amount of time. If doing this you should latch the data inputs so they remain static until the next write. Note: when I used an Arduino pin to hold WE low for several hundred microseconds, RDY toggled up and down, because I believe multiple writes were being triggered. So I recommend this circuit. It's in the June 1984 TI datasheet.
I'll have to check out your suggestions. This was an interesting IC to play around with. The sound waveforms generated are nothing like the smooth output we see in modern sound devices. Thank you for the comment!
Do I understand correctly that your clock signal is 400KHz and that matches the unexpected 'noise' in your output signal? Could you increase the clock frequency and thereby raise the frequency of the noise?
I wasn't clear on the clock. I had a 1 Mhz PWM signal generated in the STM32 and I was passing that directly through to the SN76489 and not using the level shifter. I think the noise in the output is just artifacts created by the way SN76489 synthesizes the audio. Having said that I didn't try different clock frequencies to see the effect
@@na5y Wow thanks for replying!
15:08 Sorry I am a beginner to programming. The 3 play commands are one after the other. So how is it that they all write to the 3 channels at the same time?? Won't there be the tiniest of delays that throws off the the perfect timing?
There certainly would be a small delay - but we are likely talking about a delay of 20 or 30 microseconds. That delay would be imperceptible to a human listener. Thank you for the question and good luck with your programming!
@@na5y I see! I also noticed you seem to be using divides a lot in your code. Won't this drive up the delay? (In calculating the variable tenBitValue). Why not move that to a global variable so we only compute it once?
When messing with an arduino nano and buzzer, a simple modulo done when bitbanging 'bits' to the piezobuzzer to create my own square wave at my own frequency caused a very perceptible reduction in frequency, implying it took time
How is that your board computes divisions fast?
@@Sh-hg8kf You didn't say what device you are using so not sure. The STM that I was using runs at 160 MHz - you can do a lot of computes without it affecting anything really.
Obviously there are many cases where optimization is key. For example if you are doing digital processing of a digitized sound stream then you do have to be very aware of what compute cycles you have available. With this sound chip I am just setting register values and the sound chip itself is forming the output sound.
It can be very difficult without specialized equipment (an oscilloscope for example) to see exactly where the time is going. Any debug statements you put in there will greatly affect the timing as writing out of the UART is an expensive operation.
To answer your question though - that board could do millions of divides per second - so this example it wouldn't affect the result.
@@na5y I'd mentioned I was using an Arduino Nano. It's not the fastest yes, but even a single divide causes a notable slow down which I find very very odd
Speaking with reference to your SN76489, is there anyway to write to it "parallely" or to trigger all channels at once instead of one by one? Everything is communicated over one write line so that makes it hard. Is there anyway to "freeze" the chip but keep the writes open until I've done the writes I want and then "unfreeze" the chip?
@@Sh-hg8kf I don't know if theres a way to do that. You could potentially mute all channels, do the write and then unmute all channels. You'd probably not see much of a difference though.
At 11.40 ish why don't you write the 8 bits directly to the port so that the port changes all at one time, much faster and they way it should be done. I don't know why the arduino IDE does not have a port write built in that everybody knows about. Great video still, I love to see old chips interfaced to moden uC.
You know that's an intriguing suggestion to show the difference between going through the HAL to set the output pins and driving the ports directly. I might do a video on that for fun!
For GPIO on the STM series there is the output data register for that purpose. So if you want to, for example set all lines PA0 - PA7 to ones you would
GPIOA->ODR |= 0x000000FF;
Thank you for the comment - it is tough work operating below the HAL - but important to know that its all there.
@@na5y Been working on embedded systems for more years than I care to remember. I just don't understand why people are lead to read and write to a port one bit at a time. It's one 8-bit port not eight 1-bit ports. I think a video is a good idea.
@@TheEmbeddedHobbyist I think part of it is semantic complexity - its certainly easier to read
HAL_GPIO_WritePin( PORT, Pin)
than
PORT->ODR |= ( 1U