Digital to Analog converter

[captpkelly]

This circuit works in the Real World. Unfortunately, the way CRUMB simulates an electronic circuit, this circuit is complex enough to slow the simulation down to such a slow rate that the sound coming from the sound devise is mostly low frequency noise.
https://steamcommunity.com/sharedfiles/filedetails/?id=2947860390
It's designed to run at 2khz, reading 2k bytes of waveform data, sampled at 8 bit/2k sample rate. This makes the sound duration of 1 second. On my system, CRUMB throttles itself to a 200hz simulation rate, and takes 10 to 15 seconds to sequence through a 1 second sound.

• The physical placement of U1 and U2 is reversed to make wiring to the EEPROM neater. U1 is the least significant 4 bits of the address. U2 is the next 4 bits and U3 is the high 3 bits of the 11 bit address.
  
• The "ripple carry overflow", "RCO" (pin 15) yellow wire, is used to clock the next 74161 counter in line. This pin gates high when ever the counter is sending BCD #0. The 74161 clocks on the upward transition of the clock or RCO signal.
  
• A second EEPROM could be used in sequence making a total of 4k bytes for a 2 second sound by using the '8' bit of U3 as a 'CE' chip select for the PROMS. An inverted bit '8' would go to PROM 1 and non-inverted to PROM 2.
  
• The output of the PROM is buffered into a parallel resistance ladder. The values of each resistor is indicated in the image, but basically for a BCD to linear voltage wave form, each resistor must be 2 times the value of the previous resistor with the '1' bit having the highest resistor value. This is filtered with a capacitor on the common side to smooth out the transitions from one voltage to the next.
  
• The transistor "amplifier" is mostly inadequate. The Beta is set at 90% and the bias adjust (connected to the transistor base) is an attempt to make it behave like an audio amp, This is difficult to do with a transistor with parameters that of a switching transistor.
  
• The 1 second segment of the .wav file was loaded into the EEPROM by using a separate HEX Editor program, opening a wave file, converting the hex numbers of the sample into the 2 byte ascii for each number, adding the spaces and "end of line" markers used in the CRUMB .hex file format, and saving it as the ".hex" file used by the EEPROM. This is much less tedious than entering the numbers in manually in the CRUMB hex editor.

There are other applications for the 8 bit voltage ladder. This could be used as a program selectable voltage source for example. The problem as a wave generator is that CRUMB is much too slow for it for all but very low frequency wave forms. The fact that a slow simulation rate causes the 555 to operate at reduced frequencies, I'm not sure it will even work with wave frequencies above 40 to 60 hz.

[mike.bushell]

Crikey you are certainly pushing CRUMB to the limits!

Because at the moment there is no way for me to feasibly reduce the On^3 computation time of the circuit solver… I will have a time slice mode which in the back ground will record a certain time period and then “play back” the values in all of the components

So, in a nutshell… sacrifice true real-time, so compute a time period at a required frequency… to then output as a real-time playback

I think this would work?

And maybe to keep the data size down, only output targeted components if necessary too?

[captpkelly]

Originally posted by mike.bushell:

Crikey you are certainly pushing CRUMB to the limits! ...

I was pretty sure all this would do was make low frequency noise when I set it up. I tested it with 256 bytes of data and a single counter, unbuffered and straight into the piezo sounder. It worked better (faster) if you can really tell what you are hearing in 1/10th of a second.

I have to tell you that I became a Merchant Mariner and got my captains license in the mid 90s. Living and working on boats meant I couldn't have a test bench. This program answers my electronics fiddling urges that I haven't been able to do in 25 years.

I have no clue how you can optimize the program. I'll leave that puzzle to you.

P.S. I'm retired now but I live full time on a 37ft sail boat, so ... no test bench still.

[mike.bushell]

Originally posted by wrOngplanet:

Another way might be to use GPU's for calculation?

So I did have a look into this, and unfortunately parallelism is a bit of a unicorn and I haven’t managed it yet…

The way the the circuit matrix solves with linear algebra is data dependent on the current row that it is solving and the row that was previously calculated

It is possible apparently, but I think I’m going to have to approach a real high end programmer/mathematician

[captpkelly]

Originally posted by wrOngplanet:

Cool circuit!

For resistor ladder DAC's, the accuracy needed increases with increasing bit positions exponentally

This was an area of a lot of experimenting and magazine articles in the 80s. It was pretty much the only way to get the digital data off of lazer disks and eventually early CDs and turn it into an analog audio signal. Although computers were around, they weren't nearly powerful or fast enough for the task, so the signal processing and smoothing depended on hardware resistor networks like this. Resistor tolerances was/is definitely a critical issue.

There were all kinds of schemes to deal with the issue from extremely expensive and hard to come by 1% "binary value" resistor packages normally only available for military and medical equipment, to resistor ladders made with trim-pots that could be tweaked as they degraded over time. The average home "experimenter" was left with buying packages of 100 count resistors and go through them one at a time with an ohm meter to find the best resistor for the circuit or to combine 20% resistors to make the necessary values.

There are companies today that offer high precision resistor networks on DIP packages. They are custom made and pretty expensive. It's interesting that CRUMB wont allow a value of 120k and changes it automatically to 130k, which I don't think either one of those values is standard.

The truth is this was a study of loading data into the EEPROM by creating the hex file outside of CRUMB more than it was to build the circuit that used the data. xD