Hardware

[carbon14]

I have taken Olli Niemitalo's basic design for a data capture device.

http://yehar.com/blog/?p=665

However, this design is for the OPL2 (YM3812) and there are some subtle differences between that chip and the OPL3 (YMF262)

The most important for this to work, is that the clock signal is not the same way up. In the OPL2, the SD changes on the falling edge of the CLOCK. Olli's design then uses the rising edge of the CLOCK to drive the SD into the shift register.

On the OPL3, the DOAB changes on the rising edge of the ØSY, so it is necessary to invert the ØSY signal so that you can use the falling edge instead to drive the shift register. Handily, the original design uses only 3 of the 4 NAND gates on the 74HC00, so the 4th gate can be used for this inversion.


Also, the OPL3 has 4 output channels, rather than 1.

Channels A and B are output on the DOAB pin (c.f. SD for the OPL2) and channels C and D are output on the DOCD pin.
Channels A and C are signalled on the SMPAC pin (c.f. LOAD for the OPL2) and channels B and D are signalled on the SMPBD pin.

By swapping from DOAB to DOCD and / or by swapping from SMPAC to SMPBD all 4 channels are available one at a time to the same data capture hardware.

[carbon14]

Here are the timing examples for the OPL2 and OPL3 output signals

OPL2 (taken from YM3014B datasheet)

YM3014B input.PNG (13.17 KiB) Viewed 32173 times

OPL3 (taken from YMF262 datasheet)

YMF262 output.PNG (34.89 KiB) Viewed 32169 times

[carbon14]

I'm uploading a picture of my data capture device.

I built it on a plugblock breadboard. On the left there is an 8 pin dil header which brings in the signals from the OPL3 on a Mediatrix audiotrix card. At the right hand end is an 18 pin dil header to which is soldered the centronics end of a cannibalised parallel / centronics printer cable.

Copy of DSCN2728.JPG (43.16 KiB) Viewed 31964 times

[carbon14]

This is my newest board for the opl-2.

txb0108 bi-di level shifters

IMG_20140813_143244352.jpg (215.24 KiB) Viewed 28164 times

On the left is a socket for the pi cobbler.

Then there are two txb0108 auto sensing bi-directional logic level shifters. These are on ready made boards from adafruit and they're great for dealing with the voltage mismatch between the pi and the opl-2. Particularly for the 8 data pins.

Then there's an octal inverting buffer. I'm generally using it as a buffer, but one of the things that this hardware arrangement gives me, is the ability to power the whole opl chip off. So I can try to see exactly what the registers do, knowing EXACTLY how many clock cycles since the chip was powered.

The last chip on the right is the opl itself.

I added a second pair of power rails to the prototyping board, just so that I could maintain clarity between the 3.3v supply (brown wires) and the 5v supply (red wires).

[carbon14]

And this is my new hardware for opl-3

Teensy 3.1

IMG_20141003_084000520.jpg (190.31 KiB) Viewed 28164 times

I've not yet put the opl on here, I'm just experimenting with the microcontroller.

This is a teensy 3.1, which an arduino compatible microcontroller built around an ARM cortex m4.

The actual microcontroller device is a freescale kinetis MK20DX256VLH which is jam-packed with on-board peripherals in a highly flexible multiplexed architecture.

It's a nice device for this project, 72MHz (overclockable to 96MHz). 34 digital I/o pins, all of them with optional built in pullups.
around 20 of these pins are available as analog inputs, which can be directed to a pair of on board ADCs.

Although it's a 3.3 volt device, all the inputs are 5 volt tolerant.


Obviously the raspberry pi is an order of magnitude faster in terms of raw processor speed, but the teensy is a real-time device, I can minimize interrupts, and the digital I/o is memory mapped which means that switching pins on and off takes far FAR fewer clock cycles than on the pi.

I'll probably be using its arduino libraries so that I can get results out through the usb port, but it's easy to bypass the arduino code to do efficient gpio while running the actual experiments.

I've no idea how delicate the usb connector on the teensy is. It looks very delicate, so I jury rigged some strain relief by drilling a hole through the corner of the wisher board and using a tie-wrap.

[carbon14]

I'm not sure how fast I can actually clock the GPIO on this device.

Certainly by avoiding the arduino libraries for GPIO I can toggle the GPIO registers once per clock cycle, which is pretty much 6 times faster than I would need to satisfy the clock of the OPL-3. But I haven't proven that the hardware pin will actually respond that quickly. The documentation for the microcontroller is extensive and I can't follow all the terminology. It's possible that between the actual register and the output hardware is a separate clock (There are many clocks on the MCU) and so it might actually clock more slowly.

My original plan for testing this was to chain together two fast 14-bit ripple counters, until I discovered that I only own 1 such counter. I could borrow a scope again, or I might be able to cobble together some more ripple stages from other discreet logic.


The second issue with the fast clock is the slew rate of the output. According to the documentation, this should not be a problem, each pin appear to have slew rate control hardware which can be enabled or disabled, and even at the slowest expected rate I should have an adequate output to act as a clock signal, but this would be another reason for going back to the scope.

The analog aspects of digital circuits was always the bit I found difficult. Digital logic is so simple on paper, that's why I enjoy programming; the real world of actual electronic devices is too messy.

[carbon14]

Potential hardware speed issues aside, the actual programming of the teensy is lovely.

The 34 digital gpio pins that are exposed and spread across 5 32-bit banks. Setting up the direction and hardware properties of the pins can be done in just a handful of instructions for each bank.
And once the pins are configured, reading or writing a bank is a single move instruction taking just 1 clock cycle. And the pins are also mapped to other registers, so any subset of pins in a bank can be set, cleared or toggled, again in a single clock cycle.

[carbon14]

The teensy is capable of switching the I/o pins once per clock cycle. Slew looks to be a problem, but I can achieve a passable clock at 10.6 MHz which is within tolerance for the OPL-3. I might be able to improve the slew rate.

The 'scope that I'm using is only just capable of measuring this stuff, it's rated at 50MHz bandwidth, so trying to measure a device operating at 96MHz is pushing it to it's limits, but I don't need really accurate measurements, I just need to know that it's working.

[sto]

Hi,

I'm planning to build a capture device, and your approach looks promising. I have only basic knowledge about electronics, so could you tell what I have to do to build an OPL3 capture device?

Thanks,
Steffen

[opl3]

My suggestion is to get a USB logic analyzer, one that can capture as long as PC memory runs out.
For OPL3, you need at least 8MHz sampling rate to capture the serial audio stream.