Alesis HR-16 ROM replacement

Circuitbenders · September 03, 2012, 07:11:04 PM

Give that man some karma!

I'll be having a go at that as soon as i get a spare moment.

Many thanks for posting. I've just stuck up a link to this on our facebook page.

Gordonjcp · September 03, 2012, 11:42:12 PM

Looks interesting, is the source available anywhere? I don't have WIndows so I can't try it out.

dustindustrial · September 04, 2012, 02:10:53 AM

Thanks for the plug on Facebook Paul. If you send me an e-mail address, I'll send you a download link for the app.

I'm not ready to give out the source just yet Gordon. I've got a bit of work into this, and I may still take a stab at custom sample lengths if I can find the time.

Gordonjcp · September 04, 2012, 01:43:27 PM

Ah, you don't do custom sample lengths? So you *haven't* ripped off my code? ;-)

dustindustrial · September 04, 2012, 03:30:04 PM

Lol, no... I didn't rip off your code...

. I didn't know you had any out there. I did a lot of Googling when I first sat down to write the app, and I did find some source code written by other people. In all honesty, it wasn't that good... That's why I decided to write my own app. There's a couple other apps floating around already, but I wasn't crazy about the interfaces, and editing the files manually is too tedious.

Originally, I thought I'd knock this application out, down and dirty, in a weekend or two for personal use. As I got into it, I realized it wasn't going to be that easy, and it kind of just evolved into a full app. I may look into custom sample lengths somewhere down the line. I write software professionally, and am always busy, and this app became a bit of an obsession and definitely cut into my work day more than a few times. Unless anyone finds bugs, it'll probably be a little while before I start making any revisions to the code. I've got some other projects that need to get done first.

Gordonjcp · September 04, 2012, 10:18:54 PM

Well, I'm not handing over my GPLed code so you can stick it in a paid-for app - but here's how it's done:

The ROM as you have no doubt discovered has the lower eight bits of the address flipped end-for-end because of the way the PCB is routed (it makes sense from a manufacturing point of view). So sort that out and you'll see the text of the sample names.

Have you sussed out that all the sample starts are on exact 16-byte boundaries? The start address of a sample always has the lowest nybble as zero, and are always padded with zeroes to an exact multiple of 16 bytes. The upshot of this is that the 20-bit sample address fits neatly into a 16-bit value in ROM, so if you calculate the offset of some sample starts and find those values in ROM, you've got the table of start addresses.

I never did find out where the "default" values are stored, when you do a factory reset. They're probably stored as a list of bytes somewhere.

Now get to work ;-)

dustindustrial · September 05, 2012, 02:36:56 AM

It's cool... I don't expect you to hand over your source code...

. I don't know if and when I'll get to custom sample lengths. I've been using the app quite a bit, and so far it's suiting my purposes as-is. If I stick to drum samples, I don't run into any issues with the sample locations being too small. They're often actually much larger than my new samples.

Yeah, I did a lot of Googling, and read about the firmware being "flipped". Replacing the sample names actually was the easier part. I also found online where someone had posted the start location of the sample names within the data. From that point it was basically just a matter of find and replace. Editing the sample names was an after thought. Originally I had just planned on working with the sample data.

I took a different approach to determining the sample start and end locations. Before I decided to write the app, I had started to get setup to edit the BIN files manually. I bought an EPROM programmer, read in the data, and followed the burnkit method of editing the files in Sound Forge. I got both sample data files marked with regions, and muted the sample data. That took a long time, and going back through and putting in 47 samples didn't sound like fun at that point.

It dawned on me that with the audio muted, it would be very easy to open the files via C# and look at the byte stream, and determine the start and end points. Looking at the file that way, I had big blocks of 0's with little blocks of 128's in between. So I wrote some code to run through the files and pull out all of the start and end points, and then I converted 47 wavs to the proper format in Sound Forge, hard coded their paths into the code, and started making EPROM's. Doing it this way was about a 75% success start/end point wise on the first run.

I made A LOT of test EPROM's, and listened to every sample, took notes on what worked and what didn't, and went back and revised my code. Being able to listen to the results was actually a great way to debug. Based on what worked and what didn't, I knew exactly where to start looking for the problem. I found a few things that I didn't expect, like two samples that reference the data from one sample location. "Cabasa" plays all of the data, "Fast Cabasa" plays only part of it. Little things of that nature. I also found that normalizing the new sample data was very important. Otherwise some samples played very loud, some very quiet, and some ended pre-maturely.

It was a bit of work. Having some method of calculating would probably have been easier, but I don't regret it...

. I'd be lying if I said I didn't enjoy it. I did manage to ruin one HR-16 in the process... and that was of course the night I decided to test with my circuit bent machine, rather than one of 3 clunkers I have on the shelf. It was like 3AM, I was tired, frustrated, and admittedly a bit intoxicated, and I fired up the machine with ICU15 inserted incorrectly. The last two pins were hanging out of the back of the socket, and all others were one position back. After that, regardless of the EPROM's I put in, no samples on ICU15 will play, except for one or two, which are very distorted. My next personal project will be bending another HR-16...

Gordonjcp · September 05, 2012, 07:18:20 PM

The big blocks of zeros tell the oscillator to stop. A single zero tells it to "change gear" and shift down one set of bits. All the 128s are "zero" because it's unsigned 8-bit linear as you've no doubt seen. Dig around on the 'net and you'll find where I've described the "Christmas Tree" encoding of the samples.

Use 1Mbit flash chips instead of EPROMs, it's much quicker to burn and wipe.

Your fault sounds a bit odd; as far as I know all bar the chip select lines are paralleled up so if you zap one address line it's dead for both chips. Maybe the chip select line for U15 is damaged but still "kind of" working - can you get an oscilloscope on it and compare with the other sample IC?

Have you tried more than one chip in U15?

dustindustrial · September 08, 2012, 04:22:57 PM

Thanks for tip on the flash chips. At this point, I think I'm just going to let the damaged HR-16 rest. I've tried several different EPROM's in it, and it's a no-go. As soon as you turn on the machine, you can hear a faint feedback, and the samples just won't play.

I started working on bending another one yesterday. Another few weekends and I'll be back in business.

dustindustrial · September 15, 2012, 09:07:18 PM

Just finished up my new bent HR-16...

Was just messing around with it a bit, and I noticed that some of my custom samples are a bit hissy. It seems to be the samples on the lower end of things... bass drums, toms, etc... I thought maybe this was a side effect of something I'm doing in my app, but if I convert the same samples to 8bit with Sound Forge, they're still hissy.

I guess this just a side effect of downgrading the sample. You guys know of any way to clean up the audio? If I use the HR-16 tune to shift the pitch up a little bit, it reduces the hiss. Also, once you start bending the sounds, it's not really an issue. Ideally though, I'd like all the samples to sound good in their original format as well.

Gordonjcp · September 17, 2012, 11:35:17 AM

The hiss on conversion to eight-bit is because most of the time you use dithering. This adds a little bit of noise to the signal so that it doesn't switch "cleanly" from one 8-bit level to another. If you don't, then you get weird effects - on one 808 kick sample I converted you got the Booooooom of the 808 with strange "zeeeeoooww" noises as it decayed.

The answer is, of course, to use 16-bit samples by doing the "Christmas Tree" conversion that I posted about on my website ages ago.

dustindustrial · November 10, 2012, 07:45:20 PM

The app can now be downloaded for free here:

http://www.mediafire.com/?tdddsm1qd67a4sd

ADEVILPUTASIDE · June 29, 2018, 11:59:42 AM

Hi! I'm trying to work out if I want to try burning some HR-16B ROMs myself, but the nekosynth.co.uk domain seems to be down - is the software available anywhere else, please?

Thanks!

handbaked · April 01, 2020, 11:07:55 PM

Dragging up old posts I know. But ADEVILPUTASIDE I have the CEG editor for making custom roms. I don't think that is the software of either of the software coders talking on this thread many years ago. I am only just getting round to doing this part on my hr16, so not actuall written the eproms yet. it doesn't allow you to change custom sample lengths and it seems like you kind of have to manually match up sample lengths, otherwise new samples will be cut short. be amazing if the software from DUSTINDUSTRIAL resurfaced!

if you want the ceg stuff. write a reply or private message me.

cheers.