The whole thing takes a maximum of 120us, so you must wait that length of time between initiating the conversion and reading the 74AC574. Since the entire activity is asynchronous from the CPU's perspective, this solution should work on any system that produces a write pulse long enough to be recognized by the 74HCT123. Which is typically about 2.5ns (17ns max) at 24C.
Making slow stuff work in fast systems
Making slow stuff work in fast systems
I have been dealing a lot with trying to get good and easy to use devices working in systems that run at speeds those devices were never intended for. Sometimes it's pretty easy, as it was with the MCP14495 hex decoder driver, and sometimes it's a bit harder. I'm still working on some devices and may never succeed, but I did have some success with the ADC0804N analog to digital converter. It will now work with 65C02s running at 16MHz just dandy. Here's how I did it - comments are welcomed and encouraged.
The ADC0804N requires the /WR and /RD pulses to be a minimum of 200ns wide. I was able to push some examples to run on 2MHz systems hanging them directly off the CPU buss and qualified control lines, but beyond that they just quit. In the circuit above, a write to the device address will trigger 1/2 the 74HCT123 to produce a 220ns pulse which is directed to the the /WR input on the ADC. This begins the conversion. Once the conversion is complete it drives the /INT line low which triggers the other half of the dual one-shot to produce another 220ns pulse. This pulse is then used to drive both the /RD line on the ADC and the clock input of the 74AC574, giving the ADC enough time to guarantee valid output data before the rising edge transfers the data into the 574.
The whole thing takes a maximum of 120us, so you must wait that length of time between initiating the conversion and reading the 74AC574. Since the entire activity is asynchronous from the CPU's perspective, this solution should work on any system that produces a write pulse long enough to be recognized by the 74HCT123. Which is typically about 2.5ns (17ns max) at 24C.
The ADC0804N requires the /WR and /RD pulses to be a minimum of 200ns wide. I was able to push some examples to run on 2MHz systems hanging them directly off the CPU buss and qualified control lines, but beyond that they just quit. In the circuit above, a write to the device address will trigger 1/2 the 74HCT123 to produce a 220ns pulse which is directed to the the /WR input on the ADC. This begins the conversion. Once the conversion is complete it drives the /INT line low which triggers the other half of the dual one-shot to produce another 220ns pulse. This pulse is then used to drive both the /RD line on the ADC and the clock input of the 74AC574, giving the ADC enough time to guarantee valid output data before the rising edge transfers the data into the 574.
The whole thing takes a maximum of 120us, so you must wait that length of time between initiating the conversion and reading the 74AC574. Since the entire activity is asynchronous from the CPU's perspective, this solution should work on any system that produces a write pulse long enough to be recognized by the 74HCT123. Which is typically about 2.5ns (17ns max) at 24C.
Bill
Re: Making slow stuff work in fast systems
Bill, I like it! The '123 dual timer is a good fit here. No doubt it'll work just fine -- a nice, tidy solution.
But I couldn't leave it alone.
Same as with my own circuits, I felt the urge to tease things around and explore tradeoffs. Instead of measuring time by charging a capacitor we could measure it by counting clock pulses. Depending on circumstances, this revised circuit may have a small advantage. (I'm not suggesting you ought to do it this way. But I thought it was interesting to look at an alternative approach.)
The revised circuit eliminates the resistors and capacitors associated with the RC-based timer chip, but the savings may be offset by the need to add an inverter. Or not, depending on the details of the surrounding glue logic! 
The write pulse that's presented to the shift-reg reset input needs to be active-high, not active-low like the read pulse that's applied to the '574 /OE. This is a detail that can perhaps be accommodated for free (it might even save resources), but in the worst case it will cost you an inverter (as shown).
In the diagram I omitted many of the ground and supply connections, making it somewhat sparse. At the center of the action is the 74HC4015 -- a 16-pin package containing two serial-to-parallel shift registers. (The 'HC4015 is an update of the old metal-gate CMOS 4015. 4015 and 'HC4015 are both still in production, available in through-hole and SMD.)
Left undisturbed, the reg in the A section will fill up with ones, meaning that Q3 (our output -- the end of the chain) is normally high. When a write occurs the reg's reset input briefly gets pulsed high. The reg is then full of zeros, and it will take four clock before it fills with ones again and Q3 returns high. So, we have a timer that spits out a long-ish low pulse on Q3, mimicking what happens in the first half of the '123 design.
Section B is simply a delay line. When conversion is complete the /INT signal goes low, and that low gets delayed four clocks before emerging at Q3 and being applied to /RD. Low on /RD means /INT will return high... and that high will get delayed by four clocks before reaching /RD. During that time, /RD gets a nice, chunky low pulse, which is what we set out to achieve.
There are some details I didn't bother to figure out; for example, the upper limit re the CPU bus clock. But the ADC will see /RD and /WR pulses that are over three PHI2 clocks in duration, which is favorable. What would provide even longer pulses is if the shift registers were clocked at a rate lower than PHI2. Maybe the clock generated by the ADC0804N would be suitable.
-- Jeff
(datasheets here )
But I couldn't leave it alone.
Same as with my own circuits, I felt the urge to tease things around and explore tradeoffs. Instead of measuring time by charging a capacitor we could measure it by counting clock pulses. Depending on circumstances, this revised circuit may have a small advantage. (I'm not suggesting you ought to do it this way. But I thought it was interesting to look at an alternative approach.) The write pulse that's presented to the shift-reg reset input needs to be active-high, not active-low like the read pulse that's applied to the '574 /OE. This is a detail that can perhaps be accommodated for free (it might even save resources), but in the worst case it will cost you an inverter (as shown).In the diagram I omitted many of the ground and supply connections, making it somewhat sparse. At the center of the action is the 74HC4015 -- a 16-pin package containing two serial-to-parallel shift registers. (The 'HC4015 is an update of the old metal-gate CMOS 4015. 4015 and 'HC4015 are both still in production, available in through-hole and SMD.)
Left undisturbed, the reg in the A section will fill up with ones, meaning that Q3 (our output -- the end of the chain) is normally high. When a write occurs the reg's reset input briefly gets pulsed high. The reg is then full of zeros, and it will take four clock before it fills with ones again and Q3 returns high. So, we have a timer that spits out a long-ish low pulse on Q3, mimicking what happens in the first half of the '123 design.
Section B is simply a delay line. When conversion is complete the /INT signal goes low, and that low gets delayed four clocks before emerging at Q3 and being applied to /RD. Low on /RD means /INT will return high... and that high will get delayed by four clocks before reaching /RD. During that time, /RD gets a nice, chunky low pulse, which is what we set out to achieve.
There are some details I didn't bother to figure out; for example, the upper limit re the CPU bus clock. But the ADC will see /RD and /WR pulses that are over three PHI2 clocks in duration, which is favorable. What would provide even longer pulses is if the shift registers were clocked at a rate lower than PHI2. Maybe the clock generated by the ADC0804N would be suitable.
-- Jeff
(datasheets here )
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: Making slow stuff work in fast systems
Dr Jefyll wrote:
Bill, I like it! The '123 dual timer is a good fit here. No doubt it'll work just fine -- a nice, tidy solution.
Dr Jefyll wrote:
But I couldn't leave it alone. Same as with my own circuits, I felt the urge to tease things around and explore tradeoffs. Instead of measuring time by charging a capacitor we could measure it by counting clock pulses. Depending on circumstances, this revised circuit may have a small advantage. (I'm not suggesting you ought to do it this way. But I thought it was interesting to look at an alternative approach.)
The revised circuit eliminates the resistors and capacitors associated with the RC-based timer chip, but the savings may be offset by the need to add an inverter. Or not, depending on the details of the surrounding glue logic! The write pulse that's presented to the shift-reg reset input needs to be active-high, not active-low like the read pulse that's applied to the '574 /OE. This is a detail that can perhaps be accommodated for free (it might even save resources), but in the worst case it will cost you an inverter (as shown).
In the diagram I omitted many of the ground and supply connections, making it somewhat sparse. At the center of the action is the 74HC4015 -- a 16-pin package containing two serial-to-parallel shift registers. (The 'HC4015 is an update of the old metal-gate CMOS 4015. 4015 and 'HC4015 are both still in production, available in through-hole and SMD.)
Left undisturbed, the reg in the A section will fill up with ones, meaning that Q3 (our output -- the end of the chain) is normally high. When a write occurs the reg's reset input briefly gets pulsed high. The reg is then full of zeros, and it will take four clock before it fills with ones again and Q3 returns high. So, we have a timer that spits out a long-ish low pulse on Q3, mimicking what happens in the first half of the '123 design.
Section B is simply a delay line. When conversion is complete the /INT signal goes low, and that low gets delayed four clocks before emerging at Q3 and being applied to /RD. Low on /RD means /INT will return high... and that high will get delayed by four clocks before reaching /RD. During that time, /RD gets a nice, chunky low pulse, which is what we set out to achieve.
There are some details I didn't bother to figure out; for example, the upper limit re the CPU bus clock. But the ADC will see /RD and /WR pulses that are over three PHI2 clocks in duration, which is favorable. What would provide even longer pulses is if the shift registers were clocked at a rate lower than PHI2. Maybe the clock generated by the ADC0804N would be suitable.
-- Jeff
Same as with my own circuits, I felt the urge to tease things around and explore tradeoffs. Instead of measuring time by charging a capacitor we could measure it by counting clock pulses. Depending on circumstances, this revised circuit may have a small advantage. (I'm not suggesting you ought to do it this way. But I thought it was interesting to look at an alternative approach.)The revised circuit eliminates the resistors and capacitors associated with the RC-based timer chip, but the savings may be offset by the need to add an inverter. Or not, depending on the details of the surrounding glue logic!
The write pulse that's presented to the shift-reg reset input needs to be active-high, not active-low like the read pulse that's applied to the '574 /OE. This is a detail that can perhaps be accommodated for free (it might even save resources), but in the worst case it will cost you an inverter (as shown).In the diagram I omitted many of the ground and supply connections, making it somewhat sparse. At the center of the action is the 74HC4015 -- a 16-pin package containing two serial-to-parallel shift registers. (The 'HC4015 is an update of the old metal-gate CMOS 4015. 4015 and 'HC4015 are both still in production, available in through-hole and SMD.)
Left undisturbed, the reg in the A section will fill up with ones, meaning that Q3 (our output -- the end of the chain) is normally high. When a write occurs the reg's reset input briefly gets pulsed high. The reg is then full of zeros, and it will take four clock before it fills with ones again and Q3 returns high. So, we have a timer that spits out a long-ish low pulse on Q3, mimicking what happens in the first half of the '123 design.
Section B is simply a delay line. When conversion is complete the /INT signal goes low, and that low gets delayed four clocks before emerging at Q3 and being applied to /RD. Low on /RD means /INT will return high... and that high will get delayed by four clocks before reaching /RD. During that time, /RD gets a nice, chunky low pulse, which is what we set out to achieve.
There are some details I didn't bother to figure out; for example, the upper limit re the CPU bus clock. But the ADC will see /RD and /WR pulses that are over three PHI2 clocks in duration, which is favorable. What would provide even longer pulses is if the shift registers were clocked at a rate lower than PHI2. Maybe the clock generated by the ADC0804N would be suitable.
-- Jeff
Bill
Re: Making slow stuff work in fast systems
BillO wrote:
/INT will only be reset if /RD is asserted 8 clock cycles of the ADC after /INT.
Dr Jefyll wrote:
There are some details I didn't bother to figure out
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: Making slow stuff work in fast systems
Dr Jefyll wrote:
Wow! -- you sound like someone who has actually read the datasheet...
I am learning though...
Bill
SN76489AN Sound Chip
These are great little sound chips that were used in many early computers, but they are so sllooooowwwwww that even on a 1MHz system you need to hang them off a PIA or something. I wanted to get one up and running this last week but did not have a PIA that would work in a system running at 14MHz, so I had to figure out some way of keeping the the data, /WE and /CE asserted while the chip took it's leisurely 32 clock cycles to grab the data. Luckily the Ready signal stays low until the data has been acquired, so I utilized that to hold the /WE and /CE inputs low and incorporated the system reset to prevent any false triggering while the Ready stabilized on power-up. I used a 74AC574 to latch the data.
The data sheet was misleading to say the least and was more of a hindrance than a help. With bits labeled the wrong way around (MSB = D0) and outright errors. ftp://ftp.whtech.com/datasheets%20and%2 ... N76489.pdf
My solution:
I made a sample recording, but you can't attach files like that here.
The data sheet was misleading to say the least and was more of a hindrance than a help. With bits labeled the wrong way around (MSB = D0) and outright errors. ftp://ftp.whtech.com/datasheets%20and%2 ... N76489.pdf
My solution:
Bill
-
BigDumbDinosaur
- Posts: 9430
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: SN76489AN Sound Chip
BillO wrote:
I made a sample recording, but you can't attach files like that here.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: SN76489AN Sound Chip
BigDumbDinosaur wrote:
Sure you can. Wrap it in a ZIP.
Here it is ... This was one of the first songs I learned when learning to play piano.
Bill
-
BigDumbDinosaur
- Posts: 9430
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: SN76489AN Sound Chip
BillO wrote:
BigDumbDinosaur wrote:
Sure you can. Wrap it in a ZIP.
Here it is ... This was one of the first songs I learned when learning to play piano.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: SN76489AN Sound Chip
BigDumbDinosaur wrote:
Urk! It's one of those MA4 files for which I have no compatible software.
Here it is in MP3:
Bill
-
floobydust
- Posts: 1394
- Joined: 05 Mar 2013
Re: Making slow stuff work in fast systems
Well, I use OSX or iOS and both support m4a without issue. For any platform that doesn't support it, you should be able to download VLC, which is supported on just about everything.
https://www.videolan.org/vlc/index.html
https://www.videolan.org/vlc/index.html
Regards, KM
https://github.com/floobydust
https://github.com/floobydust
-
BigDumbDinosaur
- Posts: 9430
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: SN76489AN Sound Chip
BillO wrote:
BigDumbDinosaur wrote:
Urk! It's one of those MA4 files for which I have no compatible software.
Here it is in MP3:
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: SN76489AN Sound Chip
BigDumbDinosaur wrote:
Urk! It's one of those MA4 files for which I have no compatible software.
Curt J. Sampson - github.com/0cjs