Quantcast
Channel:
Viewing all 44 articles
Browse latest View live

E-mu Emax Factory Bank Library

$
0
0

E-mu Emax

If you have been looking on the Internet for sounds for your E-mu Emax, you probably have found the one major repository of factory sound banks at http://www.hermannseib.com/english/synths/emax/banks.htm, but have also likely noticed that it is incomplete and has not been maintained for quite some time. You may have also noticed that a great majority of sample disks located elsewhere are partially or totally corrupt.

Fortunately for you, we have made available an almost entirely complete archive of all known E-mu Emax factory sound banks. We have been diligent in attempting to verify the images are fully intact and that they are as accurate as possible, but it is possible that some are mislabeled. Also, there are a few unknown banks that could be missing, which are most likely Dev/Diagnostic disks (similar to the SE update, or M.U.S.T. disk). There is one notably absent bank (ZD799 – Latin Percussion), which is included but is partially corrupt. The remainder of the banks should all be in good working order, and loadable on your E-mu Emax via EMXP.

Get the complete Emu Emax factory sample library disks below:

Accessing our premium content requires a password. To receive the password, please Like us on Facebook and send a message to our page.

 


Linksys BEFW11S4 v4 Firmware

$
0
0

Linksys BEFW11S4

This is a verified working firmware (1.50.10) for the Linksys BEFW11S4v4 Wireless-B router.

Since Linksys has dropped support for many of their legacy products, the firmware for this series is extremely difficult to come by. Even though this router is very old, it’s still useful as a switch, for testing purposes, or for low-end Internet use. It’s really quite unacceptable that tech companies drop web support for their legacy products. Surely there’s enough room on their servers for hosting a PDF user manual and a couple of ultra tiny firmware files, at the very least. This is a disturbingly common trend amongst businesses that should pride themselves in being technologically savvy.

This firmware might come in handy if you find that your BEFW11S4 is no longer working properly, and a hard reset doesn’t rectify the issue. You may also need this firmware if you have a bricked router.

If the power light is rapidly blinking and you cannot connect to it via 192.168.1.1, then it is almost definitely bricked. Here’s how you fix it:

Download Linksys BEFEW11S4v4 1.50.10 Firmware (befw11s4v4-fw-15010.zip)

Extract this ZIP archive to a new folder.

Change the TCP/IP(v4) settings on your computer to a static IP using these settings —

IP: 192.168.1.10
SUBNET: 255.255.255.0
GATEWAY: 192.168.1.1

Connect your PC directly to the bricked router with an ethernet cable (it does not need to be a special yellow crossover cable).

Run the tftp.exe program which can be located in the folder to which you extracted the firmware package.

You will need to specify the address of the router (192.168.1.1), the password (admin), and the file (code.bin) which will be found in the same folder as the tftp program. Press the “Upgrade” button when you have filled out the required fields properly.

Wait for the progress bar to finish, and if your router wasn’t too damaged to recover, then you should see a success message.

To configure the router, go to 192.168.1.1 and leave the username blank, and use “admin” as the password.

Hurray! You’ve just brought back your decade old router back to life!

Remember to return your TCP/IP settings back to automatic, or whatever static IP you were previously using.

PSL1GHT v2 PS3 SDK on Ubuntu VM

$
0
0

INTRODUCTION

If you are interested in PS3 development, whether that’s coding your own homebrew, or simply compiling preexisting source code from other projects, you need to set up your own PS3 developing environment. This tutorial is a step-by-step, zero assumptions guide on how to get started in this potentially harrowing undertaking.

At the most basic level, creating PS3 apps consists of installing C++ compiler tools and a PS3 software development kit (SDK). All of these tools are oriented towards a Linux environment, so if you’re on a Windows machine then the only practical options are to dual-boot to a true Linux install, run Cygwin (which is a Linux like environment for Windows), or run Linux inside a virtual machine.

Cygwin can be a nightmare to configure, and dual-booting requires hard drive partitioning, but a virtual machine will give you a more-or-less native Linux without undue hardware preparation, so that’s what we will be choosing.

 

VIRTUAL MACHINE INSTALLATION

First thing we need to get is VMware Player. This is a freely available program to run our virtual machine. Go to VMware’s download page and download the most current VMware Player.

Next thing we need is an Ubuntu VMware image. Since a lot of PSL1GHT tutorials are oriented towards Ubuntu 10.10 and it’s known to work, we’ll be grabbing an archived version from Sourceforge. Yes, 10.10 is obsolete, but it also has a light footprint and runs well for our needs.

Note: You can opt to create a new blank VMware image and do a normal install from an Ubuntu 10.10 ISO if you don’t care to use, find, or download a Ubuntu specific VMware image — whatever is easiest.

Install VMware Player, extract the Ubuntu image, and then boot the Ubuntu VM with VMware Player.

You’ll likely see an “SMbus not found” error during boot. This is just a side-effect of the VM process and nothing to be concerned about. We’ll be fixing it later, but you can ignore it for now.

You’ll have to go through the installation process, but the only thing you need to really watch out for is that you cannot use spaces or capital letters in your Ubuntu username. Everything else is self-explanatory or the default settings.

You’ll be prompted to update the VMware Tools. Update them if you’re feeling savvy, or ignore it.

 

UBUNTU CONFIGURATION

Once we’ve finished setup and booted into Ubuntu, we need to install our compiler software and its related tools and dependencies. But here’s the problem:

10.10 is out-of-date and has reached its End of Life. That means all the update servers have been removed and you won’t be able to install any software packages or updates. Don’t worry, because the updates have been archived and we’ll simply tell Ubuntu where to find those archive servers so we can party like it’s 2011 again.

Go to the Applications menu, and open the Text Editor app (under Accessories). Open the file /etc/apt/sources.list (in File System). You’ll see all sorts of entries that involve links to servers. Those servers are no longer there, so we need to change all those entries to old-releases.ubuntu.com instead. We’ll use Terminal to do this, but I wanted you to see what we are changing, and why.

Close the file and Text Editor, and then run Terminal (in Applications/Accessories menu). Now we’re going to use an automated search to look for the outdated server entries in sources.list and replace them with the archive servers.

Any commands starting with sudo are running as a super-user, so you’ll have to provide your Linux user password when prompted — much like UAC under Windows.

sudo sed -i s/us.archive.ubuntu/old-releases.ubuntu/g /etc/apt/sources.list
sudo sed -i s/security.ubuntu/old-releases.ubuntu/g /etc/apt/sources.list

Now that we’ve replaced the old us.archive servers with the old-releases servers, we need to update our package installer program, so it will know what to do when we ask it to install our tools.

sudo apt-get update

 

INSTALLING COMPILER AND HELPER PACKAGES

Now that Ubuntu is squared away, it’s time to really get on with setting up our coding environment. We need to install Git, which is a program that helps keep track of all the revisions of source code floating around.

sudo apt-get install git

Now we’re going to grab and install a whole slew of tools. We’re starting with a fairly blank slate, so we must install various Linux tools that will let us compile source code (which is just a textual recipe) into a useable file — a.k.a. an executable binary.

These programs consist of a C++ compiler (gcc), a compiler helper for “makefiles” (automake), and a few others. These are generic tools and are generally needed, regardless of what you are compiling — PS3 code or otherwise.

sudo apt-get install autoconf automake bison flex texinfo libncurses5-dev gcc g++ make wget libelf-dev python2.6-dev python-dev zlib1g-dev libtool git-core libgmp3-dev libssl-dev pkg-config

 

PS3 SPECIFIC TOOLS

Our general coding environment is complete, now we need to get our PS3 specific packages installed, and our project directories created.

Make a temporary working directory to store two Debian packages we’ll be downloading:
mkdir tmp_psl1ght

Change to that directory:
cd tmp_psl1ght

Use wget (which we installed via apt-get earlier) to grab those two Debian packages from a webserver:
wget http://ftp.br.debian.org/debian/pool/main/e/elfutils/libelf-dev_0.148-1_i386.deb
wget http://ftp.br.debian.org/debian/pool/main/e/elfutils/libelf1_0.148-1_i386.deb

Those packages are for manipulating ELF files, which are the executable binaries for PS3 (the end result of compiling source code). You’ll typically be turning those into SELF or eboot.bin files and then bundling and launching them via PKG files, which is how PS3 homebrew is usually distributed.

Since Debian packages don’t need to be compiled, we can install them straight away:
sudo dpkg -i libelf-dev_0.148-1_i386.deb libelf1_0.148-1_i386.deb

bashrc is a script that is automatically run by Linux. We can use that automation to configure things for us that we’re going to use every time we go to code PS3 stuff. Let’s create some aliases for a few directories that we’re going to reference all the time and then add them into bashrc:
echo 'export PS3DEV=/usr/local/ps3dev' >> ~/.bashrc
echo 'export PSL1GHT=$PS3DEV/libpsl1ght' >> ~/.bashrc
echo 'export PATH="$PATH:$PS3DEV/bin:$PS3DEV/ppu/bin:$PS3DEV/spu/bin"' >> ~/.bashrc

Now that we’ve altered bashrc, we should actually run it to put the changes into effect:
. ~/.bashrc

Since we’ve created aliases for commonly used directories, and–thanks to running the script–Linux is now aware of what those aliases are, let’s put them to use. Remember, we only need to use the alias instead of the full path. Convenient!

Create a PS3 directory to store all your coding projects, and then take ownership of it:
sudo mkdir $PS3DEV
sudo chown $USER $PS3DEV

We’re going to create another alias to make life easy. It’s a working directory for building the ps3toolchain, and since it’s not going to be used all the time, we don’t have to add it to bashrc; it’s only for the here-and-now.

export BUILDDIR=/usr/src/ps3toolchain

Use Git to grab the ps3toolchain source code, and store it into our temporary build directory:
sudo git clone https://github.com/ps3dev/ps3toolchain.git $BUILDDIR

Take ownership of the entire build directory and all its contents:
sudo chown -R $USER $BUILDDIR

Change our directory to the build directory:
cd $BUILDDIR

Now here comes the fun. Just like running bashrc, we’re going to run another script. This one creates the entire PS3 toolchain. This takes hours, so go plan out your project or brush up on your coding.

Cross your fingers and pray for no serious errors:
./toolchain.sh

 

PSL1GHT INSTALLATION

As you can see, that step was quite involved. If you’re still hanging in there, then ask Git to grab PSL1GHT and drop it into the /usr/src/psl1ght directory:
sudo git clone https://github.com/ps3dev/PSL1GHT.git /usr/src/psl1ght

Take ownership of the directory and all its contents:
sudo chown -R $USER /usr/src/psl1ght

Change to the PSL1GHT source code directory:
cd /usr/src/psl1ght

Now make PSL1GHT from its source, and set it all into motion:
make all install

Take ownership of various directories and their contents:
sudo chown -R root:root $PS3DEV $BUILDDIR /usr/src/psl1ght

Create a ps3dev directory in your “home” directory:
mkdir ~/ps3dev

Copy PSL1GHT sample programs into our new ps3dev directory:
cp -r $BUILDDIR/build/psl1ght/samples ~/ps3dev

Change to our sample code directory and create binaries from the sample source code:
cd ~/ps3dev/samples
make

Change to our “home” directory and do some housekeeping (it should free up about 3 gigs of space):
cd ~
sudo rm -rf $BUILDDIR /usr/src/psl1ght

 

AFTERMATH

WHEW! That was a ride. Now go study PSL1GHT and build some code.

Oh… remember that SMbus error Ubuntu gives at boot? Here’s the fix:
sudo su
sudo echo "blacklist i2c_piix4" >> /etc/modprobe.d/blacklist.conf

Reboot and enjoy.

Movie Surrealism and other Weirdness

$
0
0

R-Massive contributors Nate Bradford and Steven Ronquillo team up with Weng’s Chop writer and editor Tony Strauss to discuss the Surrealistic films of Alejandro Jodorowsky, David Lynch, Ken Russell, and many, many more…

Russell



For more pop culture podcasts, check out Steven Ronquillo’s Geek Ave.

RME Audio Drivers Archive

$
0
0

Please visit the official RME website first to see if your driver, software, and/or manual is available there.

This archive is only offered as a courtesy in the event that rme-audio.de is down or inaccessible, restructured, or in the event that software is removed from their official archives.

Although RME is typically very good about supporting legacy hardware, the HDSP drivers 3.36 and 3.42 are of particular note, as they are the latest versions to use the old Totalmix system and are unavailable elsewhere.

The archives are roughly sorted into Windows and Mac, although occasionally there is some overlap in the software when the package applies to both platforms.

This archive not affiliated with, nor explicitly condoned by RME. No guarantees are made as to the completeness of the archive, nor any other claims for suitability to purpose.

Please only download the specific files you need.

Windows (98/2000/XP/Vista/7/8)
Mac (OSX)
Documents/Manuals/PDFs

50 Shades of Kink

$
0
0

R-Massive writers Nate Bradford and Steven Ronquillo talk 50 shades of kink with Weng’s Chop contributor Karl Kaefer on the latest episode of the Steve’s Video Store podcast. Enjoy!

Betty Page with whip



For more pop culture podcasts, check out Steven Ronquillo’s Geek Ave.

Most Disturbing Films – Parts 1, 2 & 3

$
0
0

R-Massive writers Nate Bradford and Steven Ronquillo discuss the most disturbing films of all time with Weng’s Chop contributor Karl Kaefer in this two part series on Steve’s Video Store podcast. Enjoy!

Salo







For more pop culture podcasts, check out Steven Ronquillo’s Geek Ave.

Tascam/TEAC Cassette Recorder Manuals

$
0
0

Tascam Portastudio

Here is an archive of hard-to-find user manuals for legacy and vintage analog cassette recorders, specifically focused on the Tascam (TEAC) Portastudio/MIDIstudio 4-track, 8-track, and multi-track series.

Tascam (like most hardware and technology vendors, it seems) has omitted end-user support for a fair portion of their legacy systems, which can be understandable with difficult driver ports, but continuing to provide PDF versions of instruction manuals requires extremely minimal effort. In this case, some of them already exist in digital format, yet they are still extremely hard-to-find. Disappointing that some have to resort to buying PDFs from sellers on eBay just to know how to maintain and operate their equipment.

Due to the incredibly rare nature of these instructions, R-Massive has made them available for download in PDF form. Some are official versions, but most are (sometimes low-quality) paper scans.

These are the best versions we are aware of, but some of these manuals are so difficult to source that a few of the manuals are poor condition. If anyone has any manuals in different languages or higher quality, please contact us (Facebook, email, or the comment section below).

Owners Manuals:

Portastudio Series – 144, 244, 246, 414mkII, 424 (mkI, mkII, & mkIII), 464 (English or Japanese), 488 (mkI & mkII), Ministudio Porta One, Porta 02

MIDIStudio Series – 644, 688 (English or German)

Others – 388 Studio8

Service Manuals:

Work in progress…


E-mu Emulator II Factory Bank Library

$
0
0

The factory library for the Emu Emulator 2 sampler contains many classic sounds used in a plethora of ’80s New Wave / Synth Pop hits (and beyond), yet the complete collection is hard to find.

emu2e

There are various versions floating around on the Internet, but none of them have the complete set in working order; either some disks are missing entirely, or particular disks are corrupt and unusable. In order to remedy this situation, the set available below has been compiled from various sources, and is entirely complete with the exception of one disk (Mixed Voices #4).

This library is of interest to Emax users as well. Even though many of the Eii banks were translated into the Emax factory library, not all of them made the journey. But there’s no reason to despair, as you can now do it yourself with E-Synthesist’s amazing EMXP utility.

Accessing our premium content requires a password. To receive the password, please Like us on Facebook and send a message to our page.

 

Frontier Design – Dakota MIDI Breakout Cable Pinout

$
0
0

or HOW TO REVERSE ENGINEER AN OBSOLETE, UNOBTAINABLE, AND NON-VENDOR-SUPPORTED BREAKOUT CABLE

It’s a common thing to lose accessories, and a great many items are sold on the used market without instruction manuals, power cords, drivers (or other mandatory software), and adapters of various kinds. Some of these items can be found through the original vendor, third parties, or a generic equivalent, but all too often a seemingly minor cable can be all but impossible to find — at least at a reasonable price.

Such is the case with the Frontier Design MIDI breakout cable. The company used a proprietary standard for connecting MIDI in/out cables to their Dakota PCI card via breakout cable. They no longer sell it. There are also no substitutes from similar equipment to use, as the closest breakout cables you can find are 9-pin, not 8-pin. So what’s a person to do?

If only Google Images had X-Ray eyes

If only Google Images had X-Ray eyes

The easiest way would be to ask the company for the pinouts. In this case, it’s a no-go. No response from the company via user forum or email. Next easiest way would be to dissect a working cable to see what wires go to what pins. That would be great if you wanted to sacrifice a cable, or even had access to a cable at all (but if you already had a cable then you probably wouldn’t be worried about figuring out how to acquire another).

Only thing we’re left with is ingenuity, observation, deduction, and hopefully a multimeter. If you want something done right, better do it yourself. Let’s get to work.

MIDI breakout jack

MIDI breakout jack

Looking at the MIDI breakout jack on the back of the Dakota PCI card, we can see it’s an 8-pin miniDIN style connector, most commonly used with legacy Apple computer (keyboard/mouse/printer) peripherals. That’s a good place to start for sourcing a cable to slice up in an attempt to make our own breakout cable, but it tells us nothing in regards to how a MIDI cable would be wired up.

How MIDI cables are wired

How MIDI cables are wired

If we reference the MIDI jack standards, we can see that there are 3 pins required per each OUT jack, and 2 pins for each IN jack. Each side of a MIDI cable has 3 wires connected, but our breakout cable is really a 2×2 jack (2 in/2 out) and not a standard cable, therefore the center pin on each IN jack is not needed. The difference between jack and cable is very important here. (Also, remember that a cable and a jack are mirror images of a sort, so wire up your breakout cable accordingly — if you’re looking at the bottom-right pin of a MIDI cable, that pin will connect to the bottom-left of a jack.) Adding up the amount of needed pins, we get a total of 10 — 3 out + 3 out + 2 in + 2 in. That seems like it’s going to be a problem if we’ve only got an 8-pin midiDIN to work with, but the designers used some semi-clever engineering to reduce the 10 pins down to 8.

Since the center pin of an OUT jack is used only for RF shielding purposes, it doesn’t need to carry any real signal. In other words, there’s no data that needs to be kept in its own “stream”. RME breakout cables approach this by using a 9-pin cable and combining the shield wires from both OUT jacks into one pin. That technique gets us down to 9 pins, but we still need an extra pin.

The trick here is that we don’t need a “pin”, per se. The shielding only needs an available ground, and the metal shell of the jack goes straight to the ground path of the PCI card. So if we combine the shield wires and route them to the jack ground, we’re left with 8 free pins — enough for the 2 signal wires on each of the 4 MIDI cables that will connect to the breakout cable.

Yeah, but which pin is which? Let’s look at the underside of the PCI card and see what we can visually identify.

Find the jack, follow the traces

Find the jack, follow the traces

Two of those traces obviously go to specific IC chips, and those chips likely serve some MIDI function. But what?

Examine the ICs connected to the MIDI jack

Examine the ICs connected to the MIDI jack

If we do some homework about MIDI IN port design, we’ll find out that each IN is supposed to go to an opto-isolator. If we look at the ICs that the traces went to, we’ll see that they are HCPL2601 chips — unsurprisingly, an opto-isolator. The pins that connect to each of those traces MUST be IN jack pins. Further referencing MIDI schematics, we can tell that the “LeftOffset” pin of a MIDI cable should hit a 220 ohm resistor before it hits the opto-isolator at the anode and “RightOffset” should hit the cathode.

If we reference HCPL2601 spec sheets, we can discover that the anode is pin 2 of the chip, and pin 3 is the cathode.

Even if we can’t confirm which trace/pin goes where strictly by looking at the PCB, we should still be able to use our multimeter to measure the resistance (ohms) between our jack pins and the 2 input pins on the opto-isolator. The jack pin with the higher resistance should be connected to LeftOffset.

What? In other words, we can look at the underside of the Dakota card and see that a trace leads from the MIDI port to an opto-isolator chip [HCPL2601]. Checking the schematics for the HCPL2601, we see that the trace connects to the anode of that HCPL2601 (i.e. pin 2 on the opto chip). The schematics also tell us that pin 3 on the opto chip is the cathode, so we measure the resistance from that cathode pin (pin 3 of that HCPL2601) to all the other pins at the MIDI jack. From the cathode on that HCPL2601 there are only two pins at the MIDI jack that should show any conductivity, one being the jack pin leading to the anode (easy to identify visually, incidentally) and then we should also see one more pin that shows conductivity, but the resistance is lower compared to the anode connected jack pin. The one with the lower resistance is the cathode connected pin and therefore the RightOffset pin for that particular MIDI IN port. The resistance really didn’t need to be compared in practice, because we already identified the anode, so the only other pin showing ANY connection to the cathode has to be the cathode pin, by default.

P.S. Pin 1 on the HCPL2601 chip can be identified by the “dimple” embossed on the top of the chip itself.

Since each of our two suspect HCPL2601 ICs correspond to one MIDI IN port, and we can tell which pairs of pins connect to each HCPL2601 chip, and we know which is the anode and cathode lead, then we have solved our MIDI IN ports! This also knocks our uncertain pins down to 4.

Again referencing MIDI specs, we know there should be one +5v line to each of the MIDI OUT ports. With the card powered on, use a multimeter to test each of the remaining 4 pins. The two pins that have a solid and steady +5v each belong to one of the OUT ports.

Only two pins left. Which belongs to port 1, and which to port 2 though? Fire up your sequencer and send some looping MIDI output to port 1. Use the multimeter to check the voltage of the two remaining pins. One of them should have fluctuating values. That’s port 1. The other (by default) has to be port 2, but go ahead and sent your MIDI loop to port 2 and test it anyway.

Now we just need some female MIDI cables (or male cables and some couplers), an 8-pin miniDIN cable, and a soldering iron.

FINAL PINOUT

Compared to the lettering on the miniDIN jack picture:

A – IN (to anode — LeftOffset of MIDI cable picture)
B – OUT +5v
C – IN 2 (to anode — LeftOffset of MIDI cable picture)
D – IN (to cathode — RightOffset of the MIDI cable picture)
E – OUT 2 +5v
F – IN 2 (to cathode — RightOffset of the MIDI cable picture)
G – OUT 1 data
H – OUT 2 data
Jack Chassis – both center pins of the OUT cables **

** This method doesn’t create any ground loops because both MIDI cables connected to the OUT jacks never touch any other equipment through the center pins because they are disconnected at the IN of each piece connected. The only things electrically touching are the shields of both OUT cables and the PCI card ground.

Sidenote: Looking at the bottom of the PCI card, we can see that the MIDI jack pins are arranged in 2 rows. If you divide them vertically into 4 pairs, you’ll see that each IN and OUT line up. In other words… (C/F)(A/D)(B/G)(E/H), which is the proper pairing. Since A and C had to be mutually exclusive (couldn’t be part of the same pair), we could have guessed that each pair would have been side-by-side vertically, not horizontally. Not definitive proof by any means, but it should give additional confidence in our measurements.

REAL WORLD MEASUREMENTS

.644 resistance measured to “anode” pin on MIDI jack from pin 3 on IC
.246 resistance measured to “cathode” pin on MIDI jack from pin 3 on IC
3.94v measured at OUT data pins when not in use, fluctuating between 3.90-3.95v when carrying MIDI data

Purely speculation, but this is likely to be the pinout used with the Frontier Design WaveCenter PCI card, as well. The WaveCenter ISA card is likely similar, but not identical, due to the different number of ports in/out ports (1 in/3 out).

Yamaha TX16W Archive

$
0
0

Released in 1988, the TX16W was Yamaha’s first and (for a very long while) last entry into the affordable (yet still pricey) rack sampler market.

Yamaha TX16W

With its specs topping out at 12-bits and 6MB of RAM, there are plenty of modern choices for samplers with much higher-fidelity and infinitely more sample time, but the inherent limitations of the vintage TX16W are its key appeal.

In order to honor the past, and also hold open the door to (retro)future possibilities, we have gathered large amounts of disparate information about the TX16W so that it may be easily found in one location.

OWNER’S/USER/INSTRUCTION/SERVICE MANUALS:

Although the owner’s manual mostly pertains to using the insufferable Yamaha OS (as opposed to the universally suggested (and free) aftermarket Typhoon OS), there are enough technical details of interest to make it worth archiving.

Yamaha TX16W User Manual [English]

OPERATING SYSTEM (OS):

For serious and modern work with the TX16W, it is all but imperative to boot to Typhoon 2000 instead of the original Yamaha OS; no self-respecting individual would do otherwise.

NuEdge Typhoon 2000 OS is mirrored here in its Windows and Mac format solely for the sake of redundancy.

SOUND BANKS:

Special thanks to Jörg Knitter for sorting this, and Muki Pakesch, Sonus, madtheory, and teacue for keeping it alive through the ages.

Yamaha Factory Floppy Disk Library

User Libraries

Bjoern Gemein [DX7]
frans & rcaine [from Gearslutz]
Muki Pakesch
The X-Club Sound Library

ASSORTED INFORMATION AND TIPS:

FAQ: Here is the TX16W FAQ which was compiled by Muki Pakesch, originally found at http://www.t0.or.at/~mpakesch/tx16w/ (now mirrored).

FLOPPY DRIVE REMOVAL: While the natural inclination is to open a rack mount device from the top, doing so with the TX16W in order to remove/replace the floppy drive will lead you astray. If you look at the floppy drive from the top, it will appear as if you need to remove the 4 screws that connect the drive mount to the front-side of the TX16W. THIS IS NOT NECESSARY!

The proper way to remove/replace the disk drive is to flip over the TX16W and also remove the bottom panel. This will give you free access to 4 screws connecting the underside of the mount to the floppy disk drive. The mount itself never needs to be removed.

You must still remove the top panel in order to remove the mini-molex connector that supplies power to the floppy drive, and also to disconnect the floppy cable. After that, the drive simply slides right out.

Note: The floppy data cable is REVERSED compared to the usual/standard way of connecting a floppy cable. Pin 1 (with the green stripe) goes away from the power connector on the floppy drive. This is quite unusual and if replacing the floppy with an HxC or non-stock floppy drive then you will have to keep the cable flipped, even perhaps needing to file off the cable connector “key” that prevents it from being connected normal-side up.

Casio CZ-101 Key/Button Repair Guide

$
0
0

This is a troubleshooting tutorial and repair guide for key and button issues for the antiquated yet venerable Casio CZ-101 (aka Cosmo, Cosmosynth, and CZ101). The information contained within this guide is not guaranteed to be gospel or even accurate to any degree. Any action taken or not taken in regards to maintaining, repairing, or disassembling a CZ-101 is at your own risk and liability.
Wicked phase distortion mini-beast from 1984.

Wicked phase distortion mini-beast from 1984.

If only one key/button isn’t working then you’ve (probably) got an easy fix. The remedy is to check for a physical contaminate or worn-out conductive materials on the button pads. Clean the contacts on the PCB and the rubber buttons themselves. You can apply Caig CaiKote 44 to the buttons to restore them if cleaning doesn’t suffice. If you’re cheap or desperate then scribble some pencil graphite onto the button surface to refresh it. Rubbing alcohol may get rid of surface debris but don’t be too aggressive with it as you don’t want to strip the buttons or contacts of their conductive surface.

If multiple buttons don’t work despite having clean pads and they never work regardless of how hard or vigorously you press them (meaning non-intermittant) then it’s a circuit issue. That can be something physical like a broken pin, bad solder joint, scratched trace or a broken wire, but it can also be something with the logic circuit in an IC (CPU, decoder, etc.)

To determine what the problem is, we must know how the CZ101 reads keys and buttons.

Key Scanning / Key Matrix Basics

As a simple explanation, the keys/buttons on the keyboard are wired into a grid that’s commonly called a keyboard matrix. The CPU or another keyboard controller chip applies current to each column in the matrix while simultaneously checking to see which rows are outputting current. The point at which the active row and column intersect corresponds to which button/key is pressed.

How does the CZ101 actually do this?

The key matrix starts and ends with the CPU.

The CPU first sends four signals (PB0-3) out to the 74LS154 decoder chip. From there the decoder chip generates and outputs sixteen signal lines (called KC signals) which go to both the keybed and the panel buttons.

Note: The decoder never provides any data to the CPU, it only generates signals to send out to the keys/buttons. How this works will be explained later.

When a button/key is depressed, it closes one of a group of eight circuits (called KI signals). As soon as the button touches the PCB (printed circuit board), the KI signal travels to the 74HC241 tri-state buffer chip where its current state (on or off) is captured and stored. The CPU sends a signal out to the buffer using lines D0-7 and is sent the current KI signals in return. The D-lines are both input and output, so the buffer chip is a two-way street, unlike the decoder chip.

The CPU checks both signals (KC, KI) against each other (through row and column intersection) and figures out which button has been pressed.

The technical implementation sounds very confusing, but the concept is actually very simple. The CPU sequentially energizes each column and then it checks to see if any rows in the active column have been closed. If so, then there’s only one point in the matrix it can be. Since each point matches one and only one button/key, the CPU can very easily tell which button is depressed at that exact instant in time.

What is KC<x>?

That stands for Key Common. So KC1 is Key Common, signal 1. These signal lines form the columns of our key matrix.

What is KI<x>?

Key Input. Mostly the same concept as KC, except they form the rows of the key matrix instead of the columns.

What is the tri-state buffer for?

It actually doesn’t have much functionality in a logical sense. The tri-state buffer does absolutely nothing except hold keypress data (KI signals) until the CPU has time to request it; it doesn’t alter the data at all.

How does the CPU figure out what button is pressed when there are only eight signals sent from the tri-state?

Remember, where the KI and KC signals intersect (one row, one column = one entry) determines which button/key is being pressed.

So certain groups of keys share the same KI and/or KC properties, but only one button can have the particular point where a specific row and column cross.

With sixteen KC signals and eight KI signals, the CPU could understand up to 128 unique keys/buttons.

If the CPU never reads from the decoder (KC) but only from the tri-state (KI), how does it know what the current KC values are?

Because the CPU is controlling the decoder already. The CPU doesn’t need any feedback as to what KC signal is being checked because it has master control over which KC signal is currently activated. Whatever KC line the CPU is asking the decoder to generate at that moment is the same KC signal that the CPU will check against the KI values reported by the tri-state.

Okay… well then, how does the CPU know which of the sixteen KC signals intersects with the current KI signal when the CPU is only sending out four signals (PB0-3)?

Good question. Here’s how the decoder works:

The four different signals are read by the decoder simultaneously, but the decoder generates KC signals sequentially. Each signal can be on or off, so given all the different combinations (4^2) we get sixteen KC lines that can possibly be energized. Remember, only one line is actually active at any given moment, so the CPU only has to signal which one out of the sixteen should be fed current; the CPU never controls the state of all sixteen lines at exactly the same time as they are mutually exclusive. In other words, the CPU can tell KC1 to be on but that automatically turns off KC2-16. The CPU will not (and cannot, mathematically) request more than one active KC signal at a time.

If only one KC signal is active at a time, then how can I hold down chords on the note keys?

Technically, the KC signals are sequentially activated but the CPU cycles through the KC lines so extremely quickly that any button presses appear (to our relatively slow senses) to be instantly read.

Say… What are all the diodes by the keys/buttons for?

“Ghosting” is an unwanted phenomenon that occurs when current flows the wrong way around a key matrix and causes a row to output current when it should not. Each button/key has a diode to prevent current “backflow” which eliminates false notes that were never really pressed.

Why do multiple buttons sometimes fail at exactly the same time?

Remember, unless a solitary button or contact fails physically due to dust, being worn out, etc. then there can only be an electrical failure. With our knowledge of KI/KC signals, having an entire row/column fail makes sense as a very common fault. In fact, although possible, an electrical failure will very rarely affect only one key. This is one repercussion of a matrix type system.

For example: KI7 is a shared signal for six buttons: Sustain, Select, Patch #7, Cartridge, DCA1 Key Follow and DCA2 Key Follow. If you were to cut the PCB trace for KI7 before it gets to the tri-state buffer then all of those buttons would stop working.

What ways can entire KI lines fail?

There are many different points of potential failure.

As in the example above, you can have a physically bad trace so that the line can never be closed and any button on that line can never be activated. A bad solder joint on one of the tri-state pins that read the KI lines would have exactly the same result.

A group of buttons can also be stuck on permanently. Once a button appears to be held down, it will be considered by the CPU to be held down until it reads an off KI state from the tri-state buffer. If one of the tri-state buffer pins that report a KI line is stuck permanently on then the CPU will keep that whole corresponding KI key group active forever whether or not any of the buttons were actually pressed.

Likewise, even if a KI signal is getting to the tri-state, if a reporting pin is disconnected or stuck off then the CPU will never register any key in that KI group regardless of how hard or frequently they may be pushed.

What ways can entire KC lines fail?

Quite similarly to KI lines, except involving the CPU or decoder.

If one of the output pins on the decoder is broken and can’t send current then any group of keys tied to that KC line will be unresponsive because none of the KI lines that cross that particular (dead) KC line can carry a signal to the tri-state. Even though the various KI lines may be closed with a button press, the tri-state cannot see a non-energized line. Other buttons on the same KI line will still work, however, because they will be powered by whatever (working) KC line they happen to cross.

Even worse, if any one input pin on the decoder is bad then four KC lines will be bad. Similarly, if any one PB line from the CPU is dead then you’ll get the same result. This is one of the worst cases you can have because all eight KI lines that are fed by each of the four bad KC lines will result in thirty-two dead buttons/keys.

What’s the actual worst case scenario for button/key failure?

Obviously, total CPU/tri-state/decoder failure. Every button dies completely.

The next step down from that is ribbon cable failure, the worst of which is keyboard ribbon cable failure. Given the construction, it’s conceivable that the entire ribbon cable going from the main logic board to the keybed PCB could be sheared off.

If one physical half of the panel buttons don’t work (as opposed to a semi-random scattershot) then you might have a severed ribbon cable from the CN2 board to the CN1 board. Similarly, if you have no panel buttons whatsoever, yet all the music keys still respond then you might have a bad cable from CN1 to MA1.

What are Joiners and which are which?

If you consult the schematics for the CZ101, you will see abbreviations like JA6, JH2, etc. which correspond to the various ribbon cables connecting all the PCBs, as well as individual pins within the ribbon cables.

Example: JG6 = [Joiner cable ‘G’, pin 6]

The schematics show the KC/KI signal paths, the joiner pins from which they leave the mainboard, the joiner pin it arrives on at the other PCB, and then what PCB it arrives on.

If you follow the KC signals from the decoder outputs, they will lead to a couple joiner ribbon cables. Each signal crosses to the other PCBs via its own pin. The KI signals which come back from CN1/CN2/KY are also returned on their own individual pins via joiners.

Example: KC10-16 are sent to CN1 through the JC ribbon. KI7 connects CN1 and CN2 through JG7 and is then returned to MA1 through JC6.

Where are the KC signals routed to?

KC1-9 are routed to the keybed PCB (KY) [9×8 = 72 possible keys]. KC10-16 are routed to the first front panel board (CN1) [7×8 = 56 buttons possible]. KC13-16 cross over to CN2 from CN1 via JG [4×8 = 32 possible buttons]. KC16 is passed from CN2 to KY2 via JI6 [1×8 = 8 possible buttons].

Those are the main points, there are a few other random places KC signals are routed to.

Where are the KI signals routed from?

KI1-8 are returned from CN2 to CN1 via JG. KI1-8 are then returned to MA1 via JC. KI2-6 are returned from KY2 to CN2 via JI.

MATRIX TABLE

KC16 (CN2) = Detune [KI1]

KC16 (KY2) = Line Select [KI2], Ring Mod. [KI3], Noise [KI4], Master Tune Up [KI5], Master Tune Down [KI6], N/A [KI8]

KC16 (MA2) = APO Switch** [KI7]

KC15 (CN2 only) = Initialize [KI1], Octave [KI2], DCO2 Wave [KI3], DCO2 Env. [KI4], DCW2 Key [KI5], DCW2 Env. [KI6], DCA2 Key [KI7], DCA2 Env. [KI8]

KC14 = (CN2) = N/A [KI1], Vibrato [KI2], DCO1 Wave [KI3], DCO1 Env. [KI4], DCW1 Key [KI5], DCW1 Env. [KI6], DCA1 Key [KI7], DCA1 Env. [KI8]

KC13 (CN2 only) = Value Save [KI1], Value Load [KI2], Cursor Left [KI3], Cursor Right [KI4], Down [KI5], Up [KI6], Sustain [KI7], End [KI8]

KC12 (CN1 only) = 1 [KI1], 2 [KI2], 3 [KI3], 4 [KI4], 5 [KI5], 6 [KI6], 7 [KI7], 8 [KI8]

KC11 (CN1) = Solo [KI1], Tone[KI2], Transpose [KI3], Write[KI4], MIDI [KI5], Select [KI7]

KC11 (MA1) = Patch Write Protect Switch** [KI6], ‘P’ button** [KI8]

KC10 (CN1 only) = Portamento On/Off [KI1], Portamento Time [KI2], Vibrato On/Off [KI3], Bend Range [KI4], Preset [KI5], Internal [KI6], Cartridge [KI7], Compare [KI8]

KC1-9 (KY only) = Various Piano Keys [KI2-6]

** See the next question for an explanation.

Are KC/KI signals routed anywhere else besides directly to the button/key PCBs?

Yes, a few places. KI7 and KC16 go between MA1 (main logic board) and MA2 (power/amplification board). You’ll notice that KC16/KI7 in the matrix isn’t a panel button or a piano key but a switch. Here’s why:

The APO switch isn’t a button/key per se, but it works exactly the same way electrically. The only difference is that the switch doesn’t rebound like the rubber buttons/keys, so the circuit stays open or closed semi-permanently instead of momentarily. There’s no difference between a key, button, or a switch as far as what the CPU processes or ‘sees’.

Note: If something happens to either KI7 or KC16, not only will some buttons go dead, but the APO feature will be stuck in the same mode regardless of how the switch is set. You can use this behavior to help troubleshoot.

KC11/KI6 behaves in similar fashion, except for the Patch Write Protect Switch which is on the main logic board (MA1).

KC11/KI8 is for the ‘P’ button on the underside of the CZ101 which is used for resetting the internal patches from ROM after a battery change.

Troubleshooting

Scenario 1:

Suppose you have the following dead buttons: Sustain, Select, 7, Cartridge, DCA1 Key Follow, and DCA2 Key Follow. If we look at the key matrix then we will notice they all share the KI7 line.

We should try testing the APO feature. If the APO feature cannot be toggled then it’s fairly safe to conclude that the entire KI7 signal is faulty. The tri-state chip (pin 15, in this case) would be a good place to start our investigation since the CPU requests the state of the KI signals from the buffer.

If Select and 7 (DCA1/2 Key Follow probably too) are almost instantly lit when the CZ101 is powered up then we can assume the entire KI7 line is stuck in the on position. The most reasonable explanation for that would be that the tri-state buffer is flaky and is telling the CPU that KI7 is active regardless of what it receives from KI7 on pin 15.

Note: If the CZ101 is displaying symptoms consistent with a possibly misbehaving or dead tri-state then you have little to lose by replacing it as it is a very inexpensive part.

If those buttons are not lit at power-up yet still don’t respond to selection then we can imagine a few different causes: There could be a break in the trace leading to pin 15 on the tri-state buffer, pin 15 itself could be bad (cold solder joint), or the KI7 related data line to/from the tri-state to the CPU could be bad–either the trace itself or the pins on the CPU or tri-state.

If we can enable/disable APO then the CPU is detecting KI7 properly, which means it is communicating with the tri-state buffer for the state of KI7. Since the APO switch is on a different PCB than the rest of the dead buttons, we could conclude that there is a problem with the Joiner between MA1 and CN1. Specifically, we should check JC6 (Joiner ‘C’, pin 6) because that pin should carry all KI7 signals (from CN1 and CN2 both) to the tri-state buffer on MA1.

Given that Select, 7, and Cartridge are on CN1 and both DCA Key Follow buttons are on CN2, if we had a situation where the Key Follow buttons were dead but Select and Cartridge were still working then we should suspect the Joiner connecting CN1 and CN2.

Scenario 2:

All keys are unresponsive except for those that share the KC8 line. This would point toward either the decoder not outputting on any pins except for the KC8 pin, or the CPU is stuck on requesting KC8 to be generated by the decoder. It’s theoretically possible for all decoder output pins except KC8 to be broken, but the likelihood of that is very remote. It would make far more sense for a chip to be malfunctioning.

Scenario 3:

If random groups of buttons start and stop working erratically, especially if the cursor starts jumping pages and changing values, or there’s random garbage displayed on the LCD then it could be a power supply/regulation issue. Check the voltages at any regulators, make sure the PCBs have good ground points, and replace all the electrolytic capacitors.

Roland Sample CD Collection

$
0
0

Casio RZ-1 MT Jack

$
0
0

Casio RZ-1

There are two ways to load samples into the Casio RZ-1: “cassette” dump via the MT (magnetic tape) terminal or in through the sample jack. The usual operating procedure is to sample through the mic/line-in jack for the initial sample creation and then export/import through the MT connection for archival/reload.

The MT port makes it possible not only to backup songs/patterns, but also to retain a perfect copy of whatever you’ve sampled into the Casio RZ-1. This capability not only retains sonic consistency of your samples, it also frees you from locating the original source material you sampled from each time you want to revisit a song.

At the time of the RZ-1’s release (1986) this was the only viable workflow as the RZ-1 unfortunately does not support MIDI SDS for sample dumps. But some 30 years later, another possibility appears: What if we convert a PCM wave file to the 8-bit / 20kHz format the RZ-1 needs and then load that sample via the MT import routine, thereby bypassing the RZ-1’s converters?

Even if one prefers to utilize the analog sample input to add character, the MT import technique opens up the door for such things as tightening the attack (removing silence at the start of the sample), click removal, and mix-and-match loading.

Most RZ-1 users probably neglect to use the MT input/output jack as it’s not particularly well documented and the port uses an unusual and fairly non-standard wiring scheme of an 8-pin DIN (not to be confused with 5-pin MIDI).

Casio RZ-1 MT Cable

Fortunately, (aside from finding a full-sized 8-pin DIN connector) this cable is really simple to rig up. Advice for doing so is available on tinyloops.com. It’s for a different Casio device, but the principle remains the same. A few other music devices like the Yamaha DX11 use the same style connector for their cassette interfacing.

If you want the actual schematics for the Casio RZ-1, see below.

Casio-RZ1-MT-Jack

If you’re looking to purchase a ready-made cable, be prepared for a bit of searching; an MSX computer cassette cable is probably the best bet. They’re a bit hard-to-find, but can definitely be had for a manageable price with a bit of patience.

That solves our physical connection issues and lets us use the MT load/save feature as intended, but we still can’t import samples at will. To get this done, we need to figure out out two things: 1) The communication scheme/encoding of the MT port, and 2) Casio’s sample data format.

The service manual gives us a couple clues as to how the MT port communication scheme works:

Digital data of 1 and 0 are recorded on magnetic tape as 2.4KHz and 1.2KHz sound, respectively. When data is read, a signal from a cassette tape player comes in from MT terminal pin 5. Since the voltage level varies depending on cassette tape players, the two zener diodes cramp the signal between 0 and +5 volts.

The cramped waveform is amplified by the first opamp. The second stage opamp is a comparator which examines whether the input voltage is higher or lower than 2.5V and outputs a square waveform to CPU’s PC3 terminal.

As 5 volts of CPU’s PC6 terminal is too high for a cassette tape recorder, it is dropped to 34 millivolts by the 100Kohm and 680 ohm resistors.

Signal PC5 from MAIN CPU turns the remote control relay on and off which controls the motor in a cassette tape player.

The first paragraph is what we were looking for. This describes frequency-shift keying, which (not coincidentally) is a way that some vintage computers stored data to cassette. The MSX-style cable is another indicator of that methodology, as FSK is the exact same way the MSX computer talks to/from cassette tape.

There are many variants of FSK, so we’ve got to narrow it down a bit more to be useful. Using some common-sense and guesswork, the Kansas City Standard / Computer Users Tape Standard (CUTS) seems like a good starting point for investigating the RZ-1. The 1.2kHz/2.4kHz tone choice by Casio definitely fits with this, and the Casio TA-1 (rare as unicorn horns) documentation appears to be almost definitive proof (alert: red herring). One significant remaining question is its baud rate. If Casio was basing its designs off the MSX then 1200 baud would make sense, as that’s the rate supported by the MSX @ 1.2kHz/2.4kHz (1200 Hz/2400 Hz).

Here’s the gist of how 300 baud FSK works:

Data is coded as audio tones on the tape. A logic 0 consists of 4 cycles of a 1.2kHz tone, and a logic 1 consists of 8 cycles of a 2.4kHz tone.

Each byte (8 bits, LSB first) of data is preceded by a logic 0 start bit, and is terminated by a logic 1 stop bit. There is an additional parity bit before the stop bit. Each bit lasts for 3.33ms, giving a data transfer speed of 300 bits per second.

A recording is started with a lead-in of the 2.4kHz tone followed by the actual data.

1200 baud is the same except the amount of cycles are reduced to a quarter; a 0 bit is a single cycle 1.2kHz tone and a 1 bit is two cycles of a 2.4kHz tone. So let’s load our FSK dump into a wave editor and see what we’ve got.

At about the midpoint of the file, keep zooming until you can see the individual waveforms. There should be two distinct kinds which alternate back-and-forth, one narrower and one wider. The wide one is 1.2kHz and the narrower is 2.4kHz. To follow Kansas City Standard, the narrow waves should always be grouped evenly, but if they’re never in groups less than a multiple of 8 then we know we’ve got a 300 baud signal. If you can find narrow waves as a single pair then we’re at 1200 baud. Well… looks like we’re a bit off the mark because a couple things don’t match up.

Problem 1: We can see single cycles of 2400 Hz waves. This doesn’t fit in with any encoding schemes we’ve investigated so far, but the service manual does specify single cycle square waves of 2.4 kHz and 1.2 kHz, if read literally.

Problem 2: If we ignore the 2400 Hz leader tone at the start of our MT audio file (which is just a calibration tone and contains no data) and measure the time from the first 1200 Hz tone (the first 0 bit) until the end of the audio then we get something in the ballpark of 70-85 seconds depending on what is stored in the RZ-1. The time is fluctuating. How strange.

But problem 2 can tell us what our baud rate is supposed to be. Since the RZ-1 stores its custom sample data in two 64 kilobit chips (128 KBits total) then we should be expecting our MT data to translate to about 16 kilobytes of binary data (computer math for the win!) In other words, we need a 16,384 byte file to hold all the custom sample data on the RZ-1 which means we need at least 131,072 bits of communications data.

If we need to send 131,072 bits and only have approximately 70 seconds to transmit, then we need a data rate higher than 1200 baud, right? Even without the overhead of start/stop/parity bits we’d need at least 1800 bps.

The odd thing about this method is that 0 and 1 take different amounts of time to send. 0 takes twice as long as 1 because it’s half the frequency. In other words, transmitting a binary file of all 0s will take (ignoring the leader tone and any start bits, etc.) about 200% longer than a file that’s all 1s. If we make an MT dump of totally empty sample banks and compare its length to an MT dump containing sampled data then we will see that this is truly the case. So we’ve now determined that the average rate is around 1800 baud when the data is a 50/50 split between 1s and 0s, and it either exceeds or undershoots this rate depending upon the specific data being transferred.

That’s a pretty big diversion from the standards we’ve been considering. While sharing some of the same principles as the Kansas City standard, what we’ve deduced so far appears closer to the Sinclair ZX Spectrum / Amstrad CPC style cassette scheme which uses single pulses of square waves of two different widths, the natural result of which is a protocol that has a varying bit rate. Now we’re in the ballpark.

If we do a little more digging, it appears the Tandy/Radio Shack cassette is a very close cousin to our mysterious Casio MT port. The TRS-80 series (CoCo, Model III, et al.) uses a 1800 averaging baud (1500 average bps), 2400/1200 Hz single-cycle square wave format. Bingo! We now know enough to convert the FSK data to a raw serial bit stream. In other words, we can take the beeps and boops and convert them to actual bits in a binary file to poke and prod. In fact, a TRS-80 program WAV2CAS by Knut Roll-Lind generates the raw bitstream more or less correctly, but we still need to convert the Casio bitstream into usable bytes before we can do anything productive with the data.

WAV2CAS adds an assumed 128 byte leader consisting of $55 bytes. We can safely strip that. We also need to strip the 7.99s calibration tone. We can do that by removing every 1 bit until reaching the first 0 bit.

Now we’re synchronized to the starting point of the serial data and can start figuring out how Casio encoded it.

The first thing we encounter in the bit stream is a similarity to the Model III and Atari cassette format which is a leader of alternating 1s and 0s, which in the MT signal is directly after the 7.99s long 2.4kHz calibration tone. In the Casio, this consists of a 0.03s burst of 42 alternating bits, directly followed with another 0.02s burst of 2.4 kHz tone. This could very well be designed to train for tape speed variance (speed measurement bits), but it’s very likely not important as data.

It’s fairly certain that the meaningful data starts directly after this, probably in some kind of “data block” and probably with some short identifying header or preamble. It’s hard to say exactly what that’s going to consist of, so let’s look for obvious patterns that jump out.

One of the most conspicuous is a reoccurring pattern of 111111110 which supports the (somewhat unusual) idea of a 9 bit byte. Stripping the last 0 gives us data bits of 11111111 which is 255 in decimal (FF in hex) which is the highest value possible. Likewise, 00000000 would be notable because it’s equal to 0 in decimal which is the lowest value possible. One of those two extremes are likely to be the most common values in a data file containing any amount of null space, such as audio silence or empty patterns.

It would seem obvious that we need to ditch the 0 to get our normal byte back, but let’s try to determine what it is and isn’t before charging forward with this assumption. The trailing 9th bit can’t be a stop bit because there would first need to be a start bit. That would extend us to 10-bit bytes (not likely for a variety of reasons), so let’s nix that idea. Instead of a trailing bit, it might actually be a start bit for the next set of bits, only with a stop bit omitted. Okay, let’s see if that theory holds up. A start bit would have to always be 0 in this case. If we can find strings of 1 that are longer than eight bits then that wouldn’t make sense because a start bit of 0 would prohibit this. Well, depending on where you look in the bit stream this idea might hold up, but given enough data points we can see that sometimes we get strings of 1 that exceed eight bits.

The only sane (read: traditional) possibility left is that the 9th bit is a parity bit. Find a section containing a clear 111111110 pattern and work left starting from the 0. The 8 bits to the left add up to an even number and adding a 0 preserves this. Continuing left to the next set of 9-bits and we have either a 1 or a 0. If there’s an odd number of 1s in the 8-bits to the left of that 9th bit then the 9th bit should be 1 because that additional parity bit “rounds” out the 1s to an even number. In other words, add all the 1s in an 8-bit section. If it’s odd then tack on a parity bit of 1 as the next bit in line; if it’s even instead then do likewise with 0 (Ex: 11000001+1 or 01111011+0). This method results in creating a 9-bit byte from an 8-bit byte which is exactly inline with our expectations.

Keep following a known pattern of 111111110 backward long enough and you’ll hit other data that’s not so discernible. If the data isn’t corrupt then it should be consistent with our parity rules. And for the most part it is. It’s clear that significant portions of data are in 9-bit format and only need the last 9th bit stripped to form a traditional 8-bit byte. But, just because the ghost of Casio past wants to make our lives a living hell, we can find sections which break this pattern. Meaning? We can’t proceed blindly in just stripping the parity bits to recover our data.

How are we going to reverse engineer ourselves out of this mess???!?! The anguish!!!

There are numerous other patterns we can discern if we probe more deeply. But first, let’s do some math to help us out.

Since we’re looking for chunks of PCM sample data, consider that it would make sense for each sample pad to be 32 kilobits (32,768 bits), since that’s 1/4 of the sample RAM available. With a sample rate of 20,000 Hz multiplied by a bit-depth of 8 we get 160,000 bps of PCM data. Divide the amount of bits available in RAM for each sample pad (32,768 bits) by our PCM data rate (160,000 bits per second) and we’ll get our amount of sample time per pad which is 0.2048s per pad = 0.8192s total. Okay, that all checks out with reality, so we’re on the right track.

Using some more math, we can figure out the parity bit overhead for a chunk of 32 kilobits. 32,768 bits divided by 8-bits per byte = 4096 bytes. Since each byte has one parity bit then our parity bit overhead is 4096 as well which makes the total number of bits per each sample pad (assuming no additional overhead) 36,864 bits.

Let’s look for chunks of around 36,864 bits that are suspicious.

Depending on what we’ve got sampled into the RZ-1, it will be evident that each sample pad is divided into 32 data blocks of 130 9-bit bytes each. When converted into traditional octet bytes, it is clear this is 2 bytes too many. We should have 128 data blocks with 128 bytes per data block for a total of 16,384 octets. Given that the RZ-1 has a verify feature when loading MT data, these 2 “extra” bytes are likely a checksum or CRC.

We can also notice that a pair of ’01’ bits is tacked onto the very end of each data block. This could be either a delimiter or simply padding to keep things lined up well for the 9/8 bits per byte difference, but they should be safe to ignore as actual data.

Once we convert the bitstream to usable bytes, we’ll be able to load the file into an appropriate application such as a wave editor or DAW.

So we just snap our fingers and convert the bitstream into octets, right? Wrong!!

Important things to know:
— The headers for RHYTHM and SAMPLE MT dumps are different.
— The RZ-1 MT dumps are lsbit (least significant bit) first.
— The signed 8-bit PCM 20,000 Hz data needs to be most significant bit first. It also utilizes a Two’s complement system where 00000000 is equal to 0 and 11111111 is equal to -1. In this system, a value of zero is considered a positive number.
— The 9th serial bit is a parity bit, but only in general context, not as a rule.
— Data blocks are terminated by a delimiter.
— There are two extra (non-PCM) bytes per data block.

Sounds like we’re going to have to code a custom application to decode the bitstream.

** I have actually completed a working decoder and plan on making it available to interested parties in the near future. **

The fortunate thing about the RZ-1 MT tape out procedure is that it’s divided into RHYTHM and SAMPLE. We obviously want to be working with the SAMPLE MT dump here as our goal is sample editing/replacement. While editing sequence/song data on the computer could be another interesting project, for our purposes we can ignore the RHYTHM dump feature. We know all four custom samples will be contained in any dump generated by the MT SAVE SAMPLE DATA routine, and we can also assume they’ll be in 20 kHz, 8-bit raw PCM as that’s what the RZ-1 uses internally (if you have an EPROM programmer you can actually replace the stock sounds in the RZ-1 via similar methods). So let’s load the binary we created from the MT dump into Audacity or Sound Forge as raw PCM data with the following settings: signed 8-bit, 20 kHz, mono.

Tech note: Since we’re working with only 8-bits (one byte) the endianness is irrelevant. LSbit vs. MSbit is a separate issue and needs to be addressed before this step.

If you now have a 0.82s file with 4 samples aligned at 0, 0.2, 0.4, and 0.6s then you’ve got it made. All we have to do is replace our samples with whatever we want, being careful to only overwrite the corresponding sample portion of the file, and at the correct alignments. Remember that each sample is only 0.2s long.

For best results you’ll probably want to sample rate convert your samples from 44.1kHz (or 48/96/192) to 20 kHz with SoX, R8brain, or iZotope and bit-reduce from 16/24-bit to 8-bit with Waves L1 or similar.

After making your edits, save the file as a raw binary of the exact same type. We don’t want any extra header info tacked on because the RZ-1 won’t know what to do with that. Besides, WAV files do not support signed 8-bit.

The last step is to take our binary and convert it back to a bitstream then back to FSK audio. Use the “MT LOAD SAMPLE DATA” feature on the RZ-1 while playing back our newly created cassette tape FSK file.

** To do so requires a custom application to encode the PCM data to a Casio serial bitstream. This encoder is currently in development. **

Direct load of PCM sample data. Boom.

Casio RZ-1 Backlight

$
0
0

Question: How many Casio RZ-1 drum machines are out there without a backlight for the display?

Answer: So many that most people are under the impression they were manufactured without one.

The traditional method for getting a functional backlight on an RZ-1 is to replace the EL (electroluminescent) foil with a fresh one.

Casio RZ-1 with EL backlight

A fresh electroluminescent backlight.

Take care not to reverse these.

Take care not to reverse these.

If it is desired or necessary to keep the RZ-1 fully stock then this is the only option. It’s also the easiest electrically as it only requires soldering two wires.

A close up look at the RZ-1 display.

Unstick this tab and push to the right.

Probably the easiest approach to replacing the EL foil is to buy one sized for an E-mu Emax which, as it just so happens, shares the same dimensions with the RZ-1 foil. Then it’s simply a matter of opening the case, removing the old EL foil, unsoldering the anode and cathode leads, soldering the leads to the new EL foil, and then sliding the new EL foil back under the LCD display.

EL foil of the proper size can frequently be found on eBay for $20 by the seller “backlights”.

It’s about as simple as replacing a backlight can possibly get, but it’s also unsatisfactory for a number of reasons:

1) EL foil fades with use. This is unavoidable; it’s simply the nature of the beast. In fact, EL foil fades so quickly that it often has to be replaced numerous times within the lifespan of the display.

2) EL foil is relatively dim. Even a fresh backlight doesn’t put out enough illumination to be significantly visible in anything but a dim or dark room.

3) EL foil depends upon a high voltage inverter to be present in the power supply. This not only presents a (moderate) shock hazard, but also can result in a high pitched whine which can be audible both in the audio output and acoustically.

4) The viewing angle and contrast of these old LCD/EL foil displays is adequate but poor when compared to newer technology.

So what’s the alternative?

Typically, modern LCD character displays with LED backlights are the preferred replacement for ancient displays of this style. Replacing the entire display is not only better because it solves all the problems listed above, but these new style displays are only a quarter of the cost of even the cheapest EL foil without a replacement display. They’re also pin compatible and run off the very same voltages present in the equipment already. A lot of the times they’re even available in the same physical dimensions and are a 1:1 drop-in replacement–no mods required.

Incredible! How come everyone isn’t rocking one of these amazing new LCD/LED combo displays in their Casio RZ-1 then?

Because the RZ-1 is fairly odd in that it is a true 16×1 display. Back in the ’80s when these kind of displays were still new technology, 16×1 displays were expensive because they required two separate chips. The cheaper “hack” for this was to use a single display chip with 8×2 support and then physically move the second display line to the right of the first line instead of below it (as it was technically designed to be).

This hack required a bit of extra coding for it to work, but the cost saved was deemed worth it. The problem is that this hack was/is so routinely used that the only modern 16×1 displays available are in this 8×2/faux-16×1 configuration–they simply aren’t available with true 16×1 addressing. That’s fine for almost all other gear (including the Casio CZ series) but we’re out of luck with the RZ-1.

The only way a modern 16×1 display could be dropped into the RZ-1 would be to rewrite the firmware and adjust the display addressing to use the 8×2 hack instead of true 16×1 addressing.

So there’s no hope and everyone is stuck with old and noisy EL foil lit displays from 1986?

Unless someone is willing to get creative and think outside of the box, yes.

Wait for it… wait for it… drum roll, please!

Casio RZ-1 with LED backlit display.

My future’s so bright, I’ve gotta wear shades.

No, this isn’t trickery. This is an actual LED backlit LCD display in a real Casio RZ-1. The picture doesn’t come close to doing it justice; it looks tremendously better in real life. But even in the picture it can be seen to be both higher contrast and significantly brighter than the EL foil–and for under $5.00 including shipping.

The solution is so obvious that it should be common knowledge among vintage audio gear junkies by now, but here’s a hint: LCD/LED character displays that support the Hitachi HD44780 standard and have the additional HD44100H driver chip necessary for true 16×1 addressing are extremely common and widely available for about $5 any day of the week.

Here’s the kicker:

    They aren’t 16×1.

Come again?

Yes, folks. The common and ever-so-humble 16×2 character display is all that’s needed to jettison that atrocious EL foil and kick the old display back to 1986. It also opens up the possibility of ripping out that noisy inverter from the power supply as an added benefit.

The drawback is that the RZ-1 case needs to be modified to accommodate. Fortunately, the modifications are all internal and don’t affect the cosmetics or operation of the RZ-1 on any level.

Although the display appears to be a perfect fit (the screw holes line up and everything!) the problem is that the top character line needs to be brought down to slightly above center in the viewing window. Doing so requires cutting out all four of the mounting posts that the display sits on, as well as the little alignment “fins” present in the same area. It’s a very small sacrifice for such large gains, though.

Removed display mounting posts.

The point of no return.

Wire cutters (aka diagonal pliers) work well for this. They cut flush to the surface and can easily remove the plastic posts without damaging anything else. But once the posts are gone, how can the display be mounted?

Many methods could be employed here, but here’s an easy and cost-effective one:

Get six traditional popsicle/craft sticks or similar wood. The idea is to get thin and straight bits of wood which can be stacked until they are approximately equal in height to the plastic display mounting posts.

Make two stacks, each three sticks high. Glue and clamp each set together and let them fully dry. Next, cut both ends off one of the stacks, leaving a 9cm long bar in the middle. Do the same with the other stack except make it 4cm long.

Bars constructed from cut and glued popsicle sticks.

5 sticks are all that’s needed if done conservatively.

The 9cm bar should be centered horizontally across the bottom of the display and the 4cm bar goes vertically up the side, forming an L shape. Three corners of the display should have screw holes over the wood, and one corner should be floating free. Use a thin Sharpie or pen to mark each screw hole alignment on the wood under all three corners. With a 1/16″ bit, drill a hole slightly smaller than the mounting screws (recycled from the old display) at each mark. The 9cm bar should have two mounting holes, the 4cm bar should have only one. Mount the display on the two bars using three screws.

An L-shaped bracket for the display.

Only prototypes need duct tape ;)

Use the display window and former screw post locations to guide the horizontal placement of the display. Next, look through the display window and adjust the vertical placement until the upper portion of the black plastic display bezel is barely visible at the top of the window and then slide it back up ever-so-slightly until it’s just out of sight again. Having an assistant to check the alignment or adjust/maintain the display position is a technique worth exploring.

Once so positioned, tack each overhanging portion of the bars (three corners) down with hot glue. Connect and power on the display to double-check its alignment.

Remember: The typical viewing angle when using the RZ-1 means the display should be vertically off-center and closer to the top of the window.

If the display is level, horizontally centered, and appears vertically centered when viewed from the position of normal use then coat the outer perimeter and overhang of the wooden display bars liberally with hot glue or some other more durable fixative. Removing the button circuit board will give a lot more room to work on this step, but isn’t strictly necessary.

Hot glue securing L-shaped display bar.

Don’t get any glue on the button posts.

Before reassembling the case, consider removing the power supply board to desolder the small transformer or otherwise disable the backlight inverter. Removing the white/red backlight wire harness from the power supply board can cut down on the emitted noise, but only eliminating the inverter will cure the whine entirely.

Inverter Transformer

The RZ-1 backlight inverter transformer. Yank it out.

Tech notes: The anode of the LED backlight doesn’t need to pull power from anywhere special. Jumping Pin 2 (VDD, +5V) to Pin 15 (anode) works quite well. Likewise, jumping Pin 1 (VSS/ground) to Pin 16 (cathode) is convenient and effective.

RZ-1 display wiring jumpers.

Easiest wiring job possible.

The display pinout is exactly the same as the stock display. The white stripe of the display cable should go to Pin 14.

The contrast of the display likely will not require adjustment, but a 10K variable resistor on Pin 3 will do the job, if desired.

A compatible display can be purchased from the seller bgood2010 on eBay.


Casio RZ-1 Firmware Hacking

$
0
0

The Casio RZ-1 drum machine contains an NEC D7811G (120) 12mHz 8-bit microcomputer (part number uPD7811G-120).

The NEC 781x series was released in 1982. The series is based on the earlier Zilog Z80 register set although featuring an incompatible instruction set.

Not exactly what's in an RZ-1 but close enough.

Very similar to an RZ-1 CPU.

The CPU shown above is a 7810 which is just like the 7811 series found in the RZ-1 except it lacks the 4KB of internal ROM present in the 7811. The 7811 series can have its 4K internal ROM disabled to turn it into a 7810. This is regularly done when the 7811 is cheaper, more plentiful, or more convenient to obtain.

Configuring the 7811’s ROM mode is achieved through setting two pins (MODE0 & MODE1) on the CPU to a combination of either high or low. If MODE0 is low and MODE1 is high then it’s operating in 7811 mode, otherwise it is behaving like a 7810 and totally reliant upon external ROM for its operating code.

M0;M1
0, 1 (low, high) = Internal 4K bytes used
0, 0 (low, low) = External 4K bytes used
1, 0 (high, low) = External 16K bytes used
1, 1 (high, high) = External 64K bytes used

According to the RZ-1 schematics, pin 29 on the CPU is MODE0 and pin 27 is MODE1. The schematics also tell us that pin 29 connects to ground (pulling the pin low) and pin 27 connects to a 47K resistor tied to voltage–a classic sign of a pull-up resistor. In other words, pin 27 is being pulled high. This low/high combination means the CPU is in true 7811 mode.

That’s rather unfortunate for all but the most intrepid hacker because it will be much, much harder to meaningfully alter or understand the firmware if part of it is being stored directly in the CPU.

Not all is lost however, as the Casio RZ-1 has a separate program chip, an NEC D23C128EC (part number µPD23C128E-031) which is a 128kbit (8bit x 16k) mask ROM. This contains the last 16KB of operating system firmware for the drum machine.

In order to modify or customize the CPU behavior of the Casio RZ-1, the firmware would need to be altered. Since Casio has not made its proprietary OS source code available to the public, the first necessary step is to read the firmware from the OS ROM so that it can be reverse engineered. An EEPROM programmer and the pinouts for the firmware chip are a requirement for anyone seeking to actually implement any changes, but a mask ROM dump binary is available for exploration.

Note: Anyone looking to repair/replace a broken/erased/malfunctioning firmware ROM on the RZ-1 should be aware that the ROMs are not in sockets (at least not typically) and will likely need to be desoldered. The binary above can be written to a 27128 style EEPROM and refitted once the original chip is replaced with a socket, however.

Although the last 990 (+/-) bytes of the ROM is easily readable text such as “CASIO RZ-1; PLAY SONG=**; TEMPO=***”, the majority of the OS is machine-code, so before it can be significantly altered it needs to be converted into human readable form. This is done through a disassembler which takes the machine-code and converts it into assembly language. This isn’t an exact science, unfortunately, but it’s the best that can be done without source code.

Here is a package which contains two disassemblers for the NEC 78(C)1x series, specifically the uPD78010 and uPD78011. Both programs can be run from the Command Prompt in Windows, and there is also a Linux binary available. A commercial disassembler worth looking into is Data Sync Engineering’s Universal Cross Disassembler (XDASM).

After the assembly code has been generated, consulting the instruction manual and datasheet for the NEC uPD7810 CPU will aid in understanding the functionality of the code. Section 12 of the instruction manual is particularly significant as it describes the uPD7810 & uPD7811 instruction set in detail.

At this point, a debugger would often be utilized to trace the code and to monitor CPU registers and ROM/RAM addresses. The debugger included with MAME would be worth investigating as 7810/7811 ROMs can be loaded into its debugger via support for Hartung Game Master. Renaming our RZ-1 firmware binary to “d78c11agf_e19.u1” and placing it in the “mame/roms/gmaster” folder will let MAME’s debugger load the RZ-1 firmware, however, the code isn’t functional since the first 4K of code is still locked in the RZ-1’s 7811 chip (among other complications, such as the Hartung Game Master BIOS being only 4K unlike the 16K RZ-1 ROM). In other words, MAME’s debugger isn’t likely to be particularly helpful in these circumstances.

Developing, compiling, and testing new source code or modification of the machine code is the end goal. This can be done either by altering the original assembly/machine code or by writing all new source using an IDE. If only small changes are made to the original code then changes to the assembly/machine code can be practical, but if an entirely new OS is being developed than an IDE is ideal.

Keeping in mind that the first 4K of code is unavailable for inspection and unable to be altered, making very minor patches is likely all that can be achieved. Examining the code to understand some of the algorithms (how the RZ-1 stores its pattern/song data, for instance) is probably of more benefit than actually modifying the firmware.

A destructive approach to gaining access to the on-chip 4K mask ROM would be decapping the CPU. This involves physically ablating the surface of the chip (ceramic layer, epoxy, etc.) to reveal the die. Traditionally this is done by grinding/filing away the surface with an abrasive and then applying a strong acid alternatively with acetone until the die is clearly revealed, at which point closeup photos are taken of the die with a microscope. The photos are used as reference to reconstruct the physical representation of binary data in its virtual form. While quite labor-intensive, this method is entirely feasible with mid-’80s vintage chip utilizing only 4K of mask ROM.

Although the 4K of mask ROM is detrimental to reversing the firmware, the 16K of external ROM opens up the possibility of retrieving the 4K of ROM non-destructively. The methodology to this is to write a trojan that asks the CPU to dump its internal ROM data over one of its outputs and then to burn the trojan to an EEPROM which replaces the external ROM. When the RZ-1’s boot sequence inevitably calls the external ROM address, the trojan will be activated. All that’s left is to monitor the data output specified by the trojan.

This could conceivably be as simple as asking the RZ-1 to dump addresses $0000-$0FFF over the MT port instead of whatever is stored in sample/rhythm data memory.

If the 4K ROM was ever retrieved by such methods, one might be able to put the 7811 into 7810 64K external ROM mode by cutting the MODE0 trace to ground and then wiring it just like the MODE1 trace. Once the memory mode is changed, the 4K and 16K ROMs could be burned onto a 64K EEPROM and booted just like the stock firmware, thereby bypassing the unalterable on-die mask ROM (ultimately making it alterable via the EEPROM). If this method was successful than a 100% original firmware rewrite or significant extension (an extra 44K to work with!) would be feasible.

There are very few development environments available for this vintage CPU, but Macro Assembler AS V1.42 by Alfred Arnold is certainly an option worth exploring. A commercial option to consider is Data Sync Engineering’s Cross-32 Assembler. Supposedly Sophia Systems has (or at one time produced) a macro assembler (MASM7811) and an emulator (SA98-7810/11) but there appears to be no trace of this software existing in 2016.

Although this article is aimed specifically toward the Casio RZ-1, those looking for general info about the NEC 78K series will be helped by many of these tools and datasheets. Specifically, hackers of the Roland TR-909, Juno 106, PG-10, PG-1000, the Korg DW-6000 or DDD-1, the Akai AX80 or AX60, and the Casio CT-6500, HT-700, or CZ series may find this article of particular interest and utility.

The Roland D50 may also possibly be disassembled using one of the disassemblers in the package above, and possibly developed with IAR Embedded Workbench for NEC/Renesas 78K microprocessors, but your mileage may vary.

Good luck!

Recapping and Maintaining Classic Synths & Samplers

$
0
0

Here is some info on rebuilding power supplies (PSU) and other maintenance in vintage audio gear from the ’80s and ’90s, featuring a listing of parts and often their possible modern replacements/substitutions.

Note: A lot of equipment comes in various versions. Do not take this parts list as gospel; your equipment may very well differ. Aside from the obvious variances in model numbers and/or revisions, there may also be additional errors, typos, omissions, and straight-up mistakes.

Any work performed using this list as a guide is strictly at your own risk.

In general, when replacing electrolytic capacitors on power supplies, 105 degree, low-ESR/high-ripple capacitor types are advisable. Although they are going into music equipment, audio grade brands/models like Nichicon Muse are not optimal choices for power supply maintenance.

Here are some good PSU-ready electrolytic capacitors, ranked in typical order of preference:

Panasonic FM
Panasonic FC / Nichicon HE
Nichicon PW

Selecting a higher voltage capacitor (if that’s all that can be obtained) is almost always okay, but the capacitance must be the same as the OEM component. Most of these vintage PCBs have enough extra space that the physical size of the capacitors is not of paramount concern.

E-mu Emax

E-mu Emax (PSU – Model PS-430 [Y.K. Systems, made in Korea])

** Other PSU models will differ!! **

Voltages: P1 = -12v, P2 = +12v, P3 = GND, P4 = +5v
Fuse: 250v 2A [glass]

Zener Diodes
ZD1: not connected
ZD2: 5.6v Zener

Silicon Controlled Rectifier / Thyristor
SCR: S0506L, 6A OnState/IT(rms), 3.8A IT(avg), 50v VDRM, 1.5v VGT, 1.6v VTM, 6A ITM, TO220AB package (non-sensitive gate) [Teccor/Littelfuse]

** SCR, ZD2, and the glass fuse compose a “crowbar” protection circuit designed to protect the EMAX analog/digital boards **

Electrolytic Capacitors (radial)
C6/C7: 200v 100uF (85 degree) [Samyoung, high voltage!]; try 647-UPS2D101MHD (x2)
** Should be replaced simultaneously as a pair **

C11: 50v 22uF KM (105 degree) [black & tiny]; try 667-EEU-FM1H220
C16: 16v 1000uF (85 degree); try 667-EEU-FM1C102
C19: 6.3v 2200uF (85 degree); try 667-EEU-FM0J222L
C21: 16v 470uF (85 degree); ; try 667-EEU-FM1C471L

[Samyoung CERX, tall & orange, 105 degree]
C15/C17/C18: 10v 1000uF; try 667-EEU-FM1A102L (x3) or 647-UHE1A102MPD6 (x3)
C20: 25v 470uF; try 667-EEU-FM1E471L

Polyester/Mylar (Poly) Capacitors
C1/C4/C5: MTK (Metallized Polyester type), 0.1uF 250v (1% tolerance)
C9: 104k, 0.1uF 630v (10% tolerance)

Ceramic Capacitors
C12: 104, 0.1uF

Rectifier Diode Bridge
D1: PBP205, bridge rectifier diode (2A, 600v, silicon) [Diotec]; try RS205L [Rectron] or NTE169 [NTE Semiconductors] or 2KBP06M-E4 [Vishay]

NPN Transistors
Q1: TIP50, NPN Silicon Transistor (5v emitter-base) [PEKOR]; try STMicroelectronics TIP50 or Fairchild TIP50
Q2: MJE13007A, NPN Silicon Bipolar Power Transistor (9v emitter-base) [PEKOR, large & thick heatsink]; try MJE13007G [ON Semiconductor]

Voltage Regulators
Q6: UA7812, 78xx series +12v output [Texas Instruments]; try 595-UA7812CKCT [TI]

Opto-isolator/Photocoupler
PC1: CQY80n [Vishay]

Roland D50

Roland D50

PSU Electrolytic Capacitors
C7/C8: 2200uF 35v; try Nichicon UHE1V222MHD (x2)
C6: 6800uF 25v; try Nichicon UPS1E682MHD
C15/C18: 47uF 25v; try Panasonic EEU-FM1E470B (x2)
C9: 47uF 16v; try Nichicon UKL1C470KEDANA
C11: 1uF 50v; try Nichicon UKL1H010KDDANA

Ensoniq Mirage

Ensoniq Mirage

PSU Electrolytic Capacitors
C16: 1000uF, 25v; try PANASONIC EEU-FM1E102
C7/12/14/15: 10uF, 35v; try NICHICON UPW1V100MDD6 (x4)
C10/20: 3300uF, 25v; try NICHICON UHE1E332MHD (x2)
C6/C17: 4700uF, 16v; try NICHICON UHE1C472MHD6 (x2)

PSU Voltage Regulators
7908 [-8v, Fairchild]; try Fairchild LM7908CT
7812c [+12v, Motorola]; try Fairchild LM7812CT
UA7805c [+5, TI]; try TI UA7805CKCS (x2!)

Ensoniq ESQm

Ensoniq ESQm

Large PSU Electrolytic Capacitors
C1/C8: 3300uF, 35V; try Nichicon UHE1V332MHD (x2)
C17/C18: 4700uF, 16V; try Nichicon UHE1C472MHD6 (x2)

Small PSU Electrolytic Capacitors
C3/C6: 10uF, 35v; ; try 647-UPW1V100MDD (x2)
C11/C13: 470uF, 63V; try Nichicon UHE1J471MHD6 (x2)
C15: 22uF, 16v; try UKL1C220KDDANA

Battery & Sled/Holder
CR123A 3V 1400mAh backup battery; try 658-CR123A
Holder; try 534-1051

Ensoniq ESQ-1

Ensoniq ESQ1

** The ESQ1 differs from the ESQm!! **

Large PSU Electrolytic Capacitors
C1/C8: 3300uF, 25V
C17/C18: 4700uF, 16V; try Nichicon UHE1C472MHD6 (x2)

Small PSU Electrolytic Capacitors
C12: 220uF, 35V; try Panasonic EEU-FM1V221
C10: 100uF, 35V; try Nichicon UPM1V101MPD
C11/C13: 470uF, 63V; try Nichicon UHE1J471MHD6 (x2)

Yamaha TX16W

Yamaha TX16W

PSU Electrolytic Capacitors
47uF, 50v (x2); try Nichicon UKL1H470KPDANA
1uF, 50v (x1); try Nichicon 647-UTT1H010MDD
100uF, 200v (x2); try 647-UPS2D101MHD
1000uF, 50v (x2); try UHE1H102MHD3
2200uF, 10v (x2); try UHE1A222MHD3
1000uF, 16v (x1); try Panasonic EEU-FM1C102
470uF, 16v (x2); try Panasonic EEU-FM1C471L

Input Board Electrolytic Capacitors
10uF, 16v (x5); try Nichicon UPS1C100MDD
470uF, 6.3v (x2); try Nichicon UHV0J471MED

Casio CZ101

Casio CZ-101 / CZ-1000

DC Power Jack
(3-pin, switched type); try RAPC722X or KLDX-0202-A

Thump Eliminator Relay (SPDT 1C-style, subminiature 6-pin, through-hole/PCB, 5VDC signal relay)
OMRON G2E-187P-H-B (DC5V); try NTE R21-5D2-5/6 or HONGFA HFD41-05

Supercapacitor
NEC FZ0H473Z (5.5v, 47,000uF/0.047F); try Elna DHL-5R5D473T

Tri-state Buffer
Texas Instruments 74HC241; try 595-CD74HC241E

Electrolytic Capacitors (M4152-MA2M PCB)
3.3uF, 50v (x3); try Panasonic EEU-FC1H3R3
100uF, 6.3v; try Nichicon UVZ0J101MDD
100uF, 16v (x2); try Nichicon UKL1C101KPDANA
330uF, 16v; try Panasonic EEU-FM1C331
47uF, 16v (x2); try Nichicon UKL1C470KEDANA
1000uF, 6.3v (x2); try Panasonic EEU-FM0J102
2200uF, 16v; try Panasonic EEU-FM1C222
1uF, 50v; try Nichicon 647-UTT1H010MDD
10uF, 16v; try Nichicon UPS1C100MDD
22uF, 10v; try Nichicon 647-UPW1A220MDD
0.22uF, 50v; try Nichicon USP1HR22MDD
** This is an unusual bi-polar (no polarity) style capacitor. **

Electrolytic Capacitors (M4152-MA1M PCB)
1000uF, 6.3v (x2); try Panasonic EEU-FM0J102
47uF, 6.3v (x4); try Nichicon UVZ0J470MDD
330uF, 6.3v; try Panasonic EEU-FM0J331
470uF, 6.3v (x2); try Nichicon UVZ0J471MED
100uF, 6.3v; try Nichicon UVZ0J101MDD
3.3uF, 50v; try Panasonic EEU-FC1H3R3
1uF, 50v; try Nichicon 647-UTT1H010MDD

Casio RZ-1

Casio RZ-1

Sample Tone Knobs
10K Pots, straight side exit terminals; try Bourns 3310C-101-103L
** These are adequate but not quite a perfect alignment. Two 0.125″/3.18mm flat-shaft knobs are also recommended for aesthetics. **

Battery Holder
CR2032 Coin Battery Holder/Clip; try 122-7520-GR

Relays
** The RZ-1 contains two similar yet different relays. **

OMRON G2E-187P-H-M 5VDC (mainboard); try NTE R21-5D2-5/6 or HONGFA HFD41-05
OMRON G2VN 237 PL 5VDC (fader board); try OMRON G5V-2-DC5

MT Jack Cable (as an external connector, *NOT* an internal jack replacement)
8-pin DIN male connector, try Kobiconn (171-0278)

PSU Electrolytic Capacitors
16V 4700uf; try Nichicon UHE1C472MHD
50v 4.7uf; try Nichicon UHE1H4R7MDD or Panasonic EEU-FC1H4R7
50V 1uf; try Nichicon UKL1H010KDDANA
50V 3.3uf; try Panasonic EEU-FC1H3R3
10V 220uf (x2); try Panasonic FM EEU-FM1A221
16V 47uf (x2); try Nichicon UKL1C470KEDANA
6.3V 470uf (x2); try Nichicon UVZ0J471MED

Larger Electrolytic Capacitors (on mainboard)
6.3V 470uf (x4), try Nichicon UVZ0J471MED

Fuses: 250V 0.5A and 125V 2A

Sockets (optional)
Numerous ICs can use DIP-28 sockets (2.54mm x 15.24mm) when being replaced; try 3M 4828-6000-CP

Yamaha SPX1000

Yamaha SPX1000

PSU Electrolytic Capacitors (radial)
C19/20/21/22: 330uF 25v; try 647-UHE1E331MPD6 (x4)
C23/24: 1000uF 10V; try 647-UHE1A102MPD6 (x2)
C11 (largest): 100uF 200v; try 647-UPS2D101MHD
C33 (smallest): 1uF 50v; try 647-UTT1H010MDD

Diodes (axial)
D6/D7: 11DQ06, Vishay schottky rectifier diodes — 60v,1.1A; try SB160-E3/54 (x2)
D8: 31DF1, Vishay fast recovery diode; try STTH302RL

Roland JX8P

Roland JX8P

PSU Electrolytic Capacitors
C1/2: 35V 4700uf, try Nichicon UPW1V472MHD (x2)
C3: 25V 6800uf, try Nichicon UPW1E682MHD
C4: 50V 1uf, try Nichicon UKL1H010KDDANA
C5/8/9: 16v 100uf, try Nichicon UKL1C101KPDANA (x3)

L/M/H Output Level and/or Memory Protect Switch
10-pin (2×5), 3-way horizontal/right-angle slide switch [SSP323-9PS, Alps]

** This is nearly impossible to find a drop-in replacement for. **

Ensoniq ESP16+ Rack

Ensoniq EPS16+ Rack

PSU Electrolytic Capacitors
C2/10/11/13: 63V 10uF (small); try Nichicon UPW1J100MDD (x4)
C7/12: 63V 470uF (medium), try Nichicon UHE1J471MHD6 (x2)
C3/17/18: 25V 4700uF (large), try Nichicon UHE1E472MHD (x3)
C6/5: 50V 3300uF (jumbo), try Panasonic ECA-1HHG332 (x2)

Floppy Controller
VLSI VL1772-02PC; replace with same or WD1772
DIP28 caddy/socket, 2.54mm x 15.24mm (optional); try 3M 4828-6000-CP

Frontier Tango24

Frontier Tango24

PSU / AC Power Adapter
The large stock external brick-style power adapter can be replaced with a Wearnes WDS 050120 or an MG Electronics MGT-1250. Use a 2.1mm x 5mm barrel jack connector, MG Electronics MGW321MM is a convenient match with the MGT-1250.

** The power supply needs to be about 10VAC, 4A. It is NOT a DC adapter which is what makes it such an unusual and hard-to-find piece! **

Ensoniq DP/2

Ensoniq DP/2

The power supply uses an odd combination of +5V, +12V and -12V. A traditional ATX computer power supply is relatively easy to modify into a compatible PSU for the DP/2, but must be tricked into powering on and is noisier than the stock PSU because of the fan. A better option is a generic/Meanwell T-30B triple output PSU with a male DIN-6 cable attached.

Battery Holder
CR2032 Coin Battery Holder/Clip; try 122-7520-GR

Casio RZ-1 PCM Sound ROM Hacking

$
0
0

Although the RZ-1’s claim to fame is that it’s a PCM-based drum machine with additional sampling capabilities, it is still quite limited by sample time and the (arguably) low quality of its stock drum sounds. Although the four sample pads can be filled with custom sounds as an augmentation, the RZ-1 remains hampered by the tendency to rely primarily on those samples instead of the permanent drums.

An illustration of just how much can be squeezed from the stock sounds combined with custom samples.

The solution to this is to replace both PCM ROMs with EPROMs filled with custom sounds. Typically, this takes the form of Oberheim DMX, Linndrum, and Roland 808/909 drum hits (being such classic machines) but the choices are limited only by the length of the sample that is being replaced. The RIMSHOT sound in particular is difficult to replace as the original sound is very, very short, so any substitute needs to be tailored to fit that very tight and limiting constraint.

Desoldering the original HN613256P CM5/CM6 (Digital Percussion) ROMs from the RZ-1 motherboard is necessary, but if replaced with a DIP28 socket then any future ROM changes become a relatively quick and painless process.

Standard 27C256 EPROMs are pin compatible to the original chips, so no further modifications are needed. Simply burn custom PCM data to two 27C256 EPROMs and fit them in the sockets.

Each ROM chip holds 1.49s of sounds and can be opened as raw PCM data: signed 8-bit, mono, 20,000 Hz. Endianness does not apply to 8-bit PCM.

ROM A is CM5 which contains: Toms 1~3, Kick, Snare, Rimshot, Closed Hi-Hat, Open Hi-Hat, and Metronome Click (in that order).

ROM B is CM6 which contains: Clap, Ride, Cowbell, and Crash (in that order).

Audacity is highly recommended for altering the ROMs as raw PCM data as it can easily resample to the needed 20 kHz rate (down from the typical 44.1 kHz) and is also capable of on-the-fly playback of 20,000 Hz material on 44.1/48 kHz systems, i.e. anything modern.

Note: Each drum hit MUST be replaced by a sound of exactly the same amount of samples. The total sample length of each drum and also the entire ROM must not be altered, period. It is better to work in terms of sample points rather than lengths of time as “minute:second:millisecond” selection does not offer the required precision.

The stock ROMs have been ripped and made available for download and burning convenience, and templates for altering them have been provided. 44.1 kHz WAV files of the original sounds are also included for those wishing to use the Casio RZ-1 sounds in a sampler. Other sample packs of the RZ-1 exist, but these are extracted straight from the ROM and thereby bypass the RZ-1’s converters (and its hiss and hum filled limitations).

It’s readily apparent that the RZ-1 toms all have a soft white noise / hiss running through them, but the ROMs prove that this is not due to the converters or other circuitry, and that the noise is inherent to the actual PCM data itself. It can also be noted that there is a slight delay before Tom 1 is triggered, so it is possible to tighten up the sound slightly by moving the proceeding silence to the tail end of Tom 1.

An additional observation is that the overall signal level of the samples could be raised with moderate use of Waves L2 or another limiter, as the stock sounds use a relatively wide dynamic range and could be significantly compressed or clipped for a more modern sound.

For further sound improvement, the article on sideloading custom samples via the MT port should be seen. This strategy offers multiple benefits as compared to sampling through the analog input jack.

The combination of both of these techniques will have the Casio RZ-1 sounding better than it ever has before.

Valley People Audio Manuals

$
0
0

Valley People Logo

Allison Research aka Valley Audio aka Valley People aka Valley International was a company specializing in pro audio in the ’70s, ’80s, and ’90s. As the company (in its vintage form, at least) is no longer with us, the owners manuals, service manuals, and schematics are rather hard to find. Here is an archive of a significant portion of such documents:

Valley People – Advantage Model 310 — Audio Noise and Level Meter (with schematics)

Valley People – Model 400 — Single Channel Mic Processor (with schematics)

Valley People – Model 401 — Microphone Processor (no schematics)

Valley People – Model 433 — Compressor, Expander, Gate, Ducker, Limiter (no schematics)

Valley People – Model 440 — Limiter, Compressor, Dynamic Sibilance Processor (with schematics)

Valley People – Model 451 — GATEX (no schematics)

Valley People – Gatex — Four Channel Noise Gate/Expander (with schematics); Alternate Version

Valley People – Model 610 — Dual Compressor/Expander (with schematics)

Valley People – Model 610 — Dial Compressor/Expander (info)

Valley People – Model 730 — DynaMap (no schematics)

Valley People – Model 810 – KEPEX II — Keyable Program Expander (with schematics); Alternate Version

Valley People – Model 815 — Dynamic Sibilance Processor (no schematics)

Valley People – Model 816 – Leveller – Audio Level Controller (with schematics)

Valley People – Dynamite/Dyna-mite (with schematics); Alternate Version

Valley People – Dynamite (schematics, high quality)

Valley People – Gain-Brain 700 (schematics, high quality)

Valley People – Gain-Brain 700 (info)

Valley People – Gain-Brain II — Variable Ratio Limiter (with schematics)

Valley People – KEPEX Series (info)

Valley People – KEPEX II (info)

Valley People – KEPEX 500 (info)

Valley People – KEPEX 501 (info)

Valley People – KEPEX 508 & 516 (info)

Valley People – KEPEX 500 & Gain-Brain (schematics, low quality)

Valley People – Maxi-Q/Maxi Q — Equalizer (with schematics)

Valley People – Mini-Q/Mini Q (info)

Valley People – PR-2 & PR-10 (info)

Valley People – RM160 & CM001 (info)

Valley People – Series 800 (info)

Valley People – VCA1 (with schematics)

Akai AX80 Synthesizer Hacking

$
0
0

Akai AX80
END USER INFORMATION

Akai AX80 Owner’s Manual

CHIPSET REFERENCE SHEETS AND OTHER TECHNICAL INFORMATION DOCUMENTS

Intel 8279 Display and Keyboard Interface, NEC uPD8279C
NEC uPD2764 EEPROM
NEC uPD446 RAM
NEC uPD8253C Programmable Interval Timer
NEC uPD8255AC Peripheral Interface
Texas Instruments (TI) 74LS293 4-bit Counters
Toshiba TC4050BP Hex Buffer
NEC uCOM 87 CPU Series Data Book
NEC uCOM-87AD CPU Series User’s Manual
NEC uPD7801 (Related CPU) Data Sheet
NEC uPD7810 CPU User’s Manual
SN74LS374 Address Latch
74LS00 NAND Gate
Curtis Electromusic – CEM 3372 Controllable Signal Processor (Voice Chip), 3372 Supplementary Info
Akai AX80 Service Manual (includes schematics)

TAPE OUT (FSK) INFORMATION AND UTILITIES

Encoding and decoding utilities have already been developed and will be added at a later date.

Akai AX80 Tape Out (FSK) Format Information

The Akai AX80 frequency shift keying format (FSK) consists of two tones: A high tone centering at around 1958 Hz and a low tone centering around 979 Hz.

A “mark” (digital one) is two cycles of 1958 Hz (high) tone and a “space” (digital zero) is one cycle of 979 Hz (low) tone, meaning that each bit takes the same time to transmit regardless of whether it is one or zero. In other words, the AX80 maintains a steady baud rate where the time length of the FSK dump remains constant irrespective of the specific patch data. This is an expected and natural result of the high tone being exactly twice the frequency of the low tone.

Every AX80 FSK patch dump is approximately 60 seconds long, with the first 9 seconds consisting of the pilot/leader tone which is equal in frequency to the high tone of 1944 Hz.

The Akai AX80 communicates via asynchronous serial transmission with the highly unorthodox framing of 1 start bit, 8 data bits, no parity bits, and 8 (yes, eight!) stop bits per 17-bit word.

When each transmission is decoded into traditional 8-bit words, it should contain 2913 bytes.

Akai AX80 FSK File Format

After discarding the leader tone, the first meaningful byte is a header byte of $AA. The second byte transmitted is a (somewhat arbitrarily) user determined identification number which ranges from 0-29 (decimal) expressed in hexadecimal as $00-$1D.

The next bytes are actual user patch data with the first 1440 bytes being BANK A, directly followed by BANK B which is also 1440 bytes. Each bank contains 32 patches, and each patch is composed of 45 different parameters, each expressed by one byte.

After the patch data, there is a one byte standard checksum which is calculated in the traditional manner of XORing each transmitted byte with the previous checksum value.

Concluding the transmission is a thirty byte trailer of straight $55 values.

CPU/ROM/EPROM BIOS AND FIRMWARE SPECIFICS

In-depth information to be added at a later date, but related and generally relevant information is already available here.

Akai AX80 (Revision I) ROM firmware [launch date, 1984] (currently unavailable)
Akai AX80 (Revision K) [February 1985] ROM firmware
Akai AX80 (Revision L) ROM firmware [?August? 1985] (currently unavailable)
Akai AX80 main CPU mask ROM

REVERSE ENGINEERING NOTES

Annotated assembly code, memory mapping, etc. to be added at a later date.

Viewing all 44 articles
Browse latest View live