6502.org

I was inspired to take the dive and order a bunch of the VLSI video chip, as my project is targeted at composite video output to TVs. Sadly it doesn't look like the blitting logic lets you choose a "transparent" color like my circuit does, but my circuit also has 50-60 DIP ICs spanning two boards to do basically the same thing.

Incidentally I noticed that they also sell a chip that can act as basically a MIDI synthesizer. My own soundcard design is also pretty dense, so I'll save a lot of space (and soldering!) by switching to a single-chip solution.

Is the "4 bytes sequencial write in parallel mode" requeriment an issue for you?
Woops! I have to look for that!!

Too simple and restrictive for my taste. I hope you can prove me wrong!

Not too badly. It breaks my Conway's Game of Life implementation that I got running on my prototype, but for most cases I already expected to avoid relying on direct access to video memory. My strategy for smooth animation relies on storing sprites in a dedicated "asset storage" (copying them over from the cartridge on boot or during level transitions) and using hardware that can DMA block-copy from asset storage into VRAM.
In addition to the MIDI commands it looks like you can also feed it digital audio, so it should at least be able to act as an easy-to-use DAC.

My current audio prototype provides two square waves, a noise channel, and a sample playback channel. Individually the channels work fine, but I'm having a heck of a time with the analog mixing design to combine the signals from the channels without creating distortion. Analog, it seems, isn't coming to me as naturally as Digital. With the VLSI chip I'll have a more powerful audio system and have the messy analog stuff handled for me.

Random aside: Having spent so long working on these designs, I'm a little sad to just toss it aside for these convenient all-in-ones. I think I'll basically fork my own project to separate conflicting goals. The game console gets to be compact and stable, while the massive DIP-chip design migrates into a desktop computer form-factor where I can expand on its features that the VLSI chip doesn't have.

With the things I've been finding, I think a new sound chip 'retro style' could be made. I've found chips that do square, triangle and sine waveform generation from a few Hz to hundreds of Mhz. Yes, human ears should hear from 20hz to 20khz, so just a tiny section of what those chips would be able to do be used.

But then, a way to control how the voltage is applied to those chips to change the frequency should be implemented... by another chip.

And then, a mixer that would be able to send every one of the input channels or tracks to the left or right channel...

I think sound card could be made with a circuit board the size of olympic pool, but yes, it would be doable...

@Agumander.... look at this and tell me what do you think.

https://www.youtube.com/watch?v=ATLEfqlw10A

https://www.dream.fr/items.php?item=4

Saw this when looking around! It's pretty interesting, similar to the VLSI chip in being a DSP MCU preloaded with useful firmware. Would be interesting to check out. I'm lazy and go for the chips with a "buy now" button next to them.

Manipulating voltages into a circuit that's essentially an analog synth rack would be neat, though it would end up being rather dependent on temperature and other environmental conditions. My audio board works by setting counter values, and toggling a flip-flop whenever a counter hits zero. What I'd like to do is replace my attempted audio mixing with adder chips, to do the summing in the digital domain and only deal with one DAC.

On the other hand, if the audio chips are actually just microcontrollers under the hood, then maybe we might as well write our DSP code in good old 6502 assembly. If you ran a 65C02 co-processor at 14MHz you'd have around 60 clock cycles available for computing each audio sample, if you wanted to keep up a sample rate of 44.1kHz.
You could communicate with the secondary processor by a few shared registers and interrupts, or a whole dual-ported RAM chip, or even just one register for sending bytes one at a time. This would make the audio system fairly flexible while still maintaining that "6502 flavor"

Martin Galway said in an interview I did in 2003 that the SID is "digitally controlled analogue synthesiser built right into the computer". And that would be the thing to achieve when building a sound generator using chips and discrete components.

There was this parallel port poor man's sound card, the Covox Speech thing, that, with a resistor ladder, formed a primitive DAC. Today, a DAC is one of the cheap, basic chips available everywhere, from many manufacturers.

Please help me to understand here: What's the transfer rate of a parallel port controlled by a 65xx cpu, writing 8 bit data? At first, it seems to me that sending 44100 values of 8 bit each second shouldn't be a problem for even a 1Mhz computer... Or is it the timing of the data bus, or the parallel chip (W65C22 for example) what limits the speed?

Sending 44100 values of 8 bit isn't such a problem in and of itself. The speed would mainly be limited by how much time you take to calculate these values. In other words the limit is the number of cycles spent by each instruction you use. At 14MHz clock and 44100 audio rate you'd have 317 cycles per sample. Each instruction takes at least 2 but as many as 7 cycles, so you could afford somewhere between 45 and 158 instructions based on which ones you use.

At 1MHz system clock your budget would be quite a bit tighter at 22 cycles. Simply fetching audio from memory wouldn't really be an issue, but if you wanted to do fancy summing or waveform generation you'd be quite limited. Especially if you have other note parameters or controls to track.

I still remember when the Sound Blaster Pro was a thing, games featuring hq sound samples of 8 bit and 22050hz... So 16000hz and 8 bit shouldn't be that bad. Anyway, a gaming console won't need 192khz, 32 bit sound with 7.1 channels for sound effects.

I was looking and found that some of the communications chips that (I think) would work with the 6502, have a faster timing than the 70ns @14mhz of the VIA chip. Would that mean that even higher sampling rates could be achieved, or better sound quality could be achieved, having the CPU more instructions per sample to work with?

These calculations were already assuming that the CPU was not being limited by outside comms speed. With the 14MHz figure coming from the listed max clock for the 65C02S. Though people have certainly pushed it higher, a faster interface chip won't get you more CPU instructions per sample. My own calculation was based on just using a DAC as an addressable register.

When trying to predict how well a particular I/O device will perform in a 65C02 system, you can only base that prediction on the Ø2 high period, which is 35ns if running the WDC parts at maximum rated speed. Given various latencies in how things respond during the actual read cycle, the available read time will be something less than that 35ns.

Assuming non-6502 I/O parts, you may be generating /RD and /WD signals, which have to be gated by Ø2 so they don't go true during Ø2 low. You will lose anywhere from 4 to 10ns due to a gate delay between Ø2 and /RD or /WD, plus the time needed by the addressed device to react to its /OE or /WE input. Between those two delays, up to 20ns (worst-case) could elapse before any data actually appears. So a faster I/O device won't necessarily result in better performance, since glue logic delays don't change.

Incidentally, the 65C22 has an advantage here, as its operation is synchronous to the Ø2 clock. Chip selects and RWB have to be valid before the rise of Ø2, which means the 65C22 will be somewhat quicker in reacting with the rise of the clock than a device that requires /RD and /WD. In Garth's application, that characteristic of the 'C22 is helping in getting jitter-free results.
Over at my POC V1 topic, I describe the efforts required to maintain stable operation using a 65C816 running in native mode in POC V1.2. Despite the use of 74AC logic, with no more than two gate delays between the address bus and each I/O device. I could not maintain reliable I/O at 14 MHz, as the 28L92 DUART I use for serial I/O (one of the fastest UARTs available) was not able to reliably respond to a read cycle with only 35ns available. Wait-stating was required on I/O (and ROM) accesses to get to 14 MHz (and beyond), using one wait-state, in which Ø2 high was stretched an extra cycle.

As explained by Garth, I think you may be underestimating the level of processing performance it would take to get jitter-free audio in a 6502-based system, even with limiting the audio quality to 8-bit samples at a sample rate well below the 44K used with CD-quality audio. The 65C02 can be run up to 20 MHz if things are right, but the rest of the circuit has to be able to run in a stable fashion at that speed.

> When trying to predict how well a particular I/O device will perform in a 65C02 system, you can only base that prediction on the Ø2 high period

Indeed, if you're using phi2 to qualify control signals: I believe other approaches are possible.

Couldn't you avoid audio jitter by using a couple of '573s as a really short FIFO buffer? In exchange for a sample or two's worth of lag you wouldn't have to worry about sending the sample *early* so long as you don't send it late. Which seems easier to program for.