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.

_________________
Bill

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 )

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks, and it does indeed work as intended.



Cool idea Jeff, but there is a small issue. /INT will only be reset if /RD is asserted 8 clock cycles of the ADC after /INT. I guess in the - Old Days - the interrupt handler would have allowed enough time for this to occur. If /RD is asserted by /INT, /INT does not reset until /WR is asserted to begin a new conversion.

_________________
Bill

Wow! -- you sound like someone who has actually read the datasheet... instead of just glancing at it as I did.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Fairly atypical, I can assure you. Years ago unexpected behavior riveted my attention to the details. Even then it's just a side note.

I am learning though...

_________________
Bill

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.

_________________
Bill

Sure you can. Wrap it in a ZIP.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good idea BDD!

Here it is ... This was one of the first songs I learned when learning to play piano.

_________________
Bill

Urk! It's one of those MA4 files for which I have no compatible software.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

M4A. I just assumed everyone would be running a modern Windoze platform. My bad.

Here it is in MP3:

_________________
Bill

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

_________________
Regards, KM
https://github.com/floobydust

That works!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

On Linux, mplayer, vlc, etc. etc. all should be able to play it just fine. (It worked right off the bat for me in mplayer as installed by apt-get on Debian 9.)

_________________
Curt J. Sampson - github.com/0cjs