TR-505 Bending & rom Hacking

[playthatbeat]

As Requested by n.d - the romhacker.c (and company) files that seem to have gone missing from the internets,
plus some other bits & pieces that anyone going for a mod of the 505 or 707 should have...

[ptmir]

tHANKS my friends i have a TR-626 i will try make an eprom for it.. also will buy a tr-505 to try it

i have alredy done for the HR-16 ALESIS and is very good

see you
Pedro

[playthatbeat]

Hey Pedro..

Got to love the HR16 - Probably the best for hard & fast sounds with it's STEREO bending! Good luck with the 626 - it has the individual outputs, so you can build some nice layers when the bends are severe..

[bartbral]

Hi Playthatbeat, and everybody interested.

I think I've found a simple solution to use the interleaved samples as well,
without using any special software... (I just used Audacity)

I used this technique to open the ROM-image posted above. Didn't edit the samples and saved it and checked the file and was exactly the same. (as far i could see... Haven't checked in a HEX-editor yet)

=====================
01. open/import .BIN file as RAW Unsigned 8-bit STEREO 24000Hz
02. split stereo track to mono tracks
03. edit the sounds that are interleaved
04. combine mono tracks back to stereo track
05. save/export as RAW Unsigned 8-bit STEREO 24000Hz... As .BIN file.

06. open/import .BIN file as RAW Unsigned 8-bit MONO 48000Hz
07. edit the first 4 uninterleaved samples.
08. save/export as RAW Unsigned 8-bit MONO 48000Hz... As .BIN file
=====================

Can't check it in the 505 yet... because I haven't got a programmer and haven't build the loom-device yet.

Laterzzz, Bral

Edit: Hmmmmm. Don't know or it is the fact that Audacity isn't sample accurate? Or I'm doing something wrong?... But my file output isn't the same as the original input... Hmmm... Let me get back after some more investigation.

Edit edit: Audacity isn't 100% accurate, even without converting back to stereo and sh!t... I imported the .BIN then exported the .BIN... looked perfectly safe in Audacity, but taking a closer look in a HEX-editor there where differences... Not very much but still... Damn.
I might have to try something else...

[playthatbeat]

Audacity can default it's enviroment Bitrate to Your sound system's last setting.. So, for example, i can open a file that is 44.1k, and manipulate it without any issues even though the enviroment itself (bottom left drop-down) shows 48k.. it's only when You come to EXPORT the work that you run into problems.. Maybe this is effecting it?

But, I think You are missing the point about the 'interleaving' - the rom uses interleaving like this: all the ODD slices are one sound, all the EVEN slices are another for a portion of the rom. This means slice 1,3,5,7,9 (etc.) are one sound - cut into slices and spaced out, while slices 2,4,6,8,10 (etc.) are a completely different sound. You cannot edit this in a linear editor. it's not possible. You need to extract the odd slices and even slices as 2 separate operations, then join all these together again to work on them. this would result in 2 files exactly 1/2 the size of the combined file. After editing, you need to re-combine the files by interleaving them again, and then use a loom to scramble the result so the 505 can play it back correctly.

I suspect Your confusion might have alot to do with missing this, as you are never going to be able to change the main sounds without splitting out the odd and even slices into new files.

[bartbral]

Cheers for your very detailed reply!

I've tried again... And it wasn't the Project's Rate setting.

And I don't think I was missing the point on the interleaved format. I have read your post a few times and I understand that the first 4 samples aren't interleaved, and the last 8 are. (It was very well explained by you in this thread, Thanx again!)

The gate array for toms and timbal gets clocked twice as fast as the kick, conga, snare, cowbell and rim/clap.



But I still think that Audacity is not 100% accurate. And changes some bits in the import/export process. I just did some more tests.
And this is even when the project samplerate is 48000Hz. And I import your romrip "loom-rom-try.bin" as RAW(headerless) 8-bit unsigned PCM, mono, 48000Hz. (tried all endianesses).
And exported as RAW(headerless) 8-bit unsigned PCM, mono, 48000Hz.

I would have thought the output and input should be identical.


But I still don't have my eprom programmer... So when i do... I'll see if I can make it work. (and make the fruit of the Loom)

Thanks again!

[playthatbeat]

Hmm.. that's irritating.

Maybe Audacity is suffering a layer of transcoding - like how GiMP does when working on images. The hint to this is how it/they no longer allow You to just SAVE work - you have to EXPORT it in the format You want - even if that format is the same as the source material.

Also suspect are DITHERING and METADATA inclusion on Audacity. I think the inclusion of these is squarely based on the profile of the bulk of the users of Audacity - ie: semi-pro or hobby folk, podcasters and so on.

Stuff like WAVLAB 4 (now totally obsolete and prone to bluescreening on PCIe machines) used default to having 24bit TEMP files, and if You wanted to retain sample-accurate work, You had to adjust this tempfile format to match the format of the file you were working on, if You intended to use any plugins or anything that required the generation of a TEMP file. Wavlab & SF also used to get very upset if a file was opened that had heavy metadata or a 'sleeve' picture included in the file, that changed in later revisions, but it's a clue as to how the purity of digital audio files became compromised over time.

This is highly irritating ofc., i guess a sure solution is to downgrade and use a torrented or ebay'd vintage version of Wavlab or SoundForge for this type of forensic editing? At least these softwares allowed You to define how TEMP files were created, and where, and they rightly don't append files with crap metadata etc.

[bartbral]

Yes, I think it's dither indeed... But it isn't that bad, I'm not going to to put the same samples on it anyway... But I can't check if my idea of doing it all in Audacity will work... Too bad.

In my research for being worlds laziest bastard I found this:

EPROM PIN SWAPPER

And I hope it will spare me from building a very complicated Loom. I can't check now because I am on a mac and when running it with Wine it starts wining when I try to save... (doesn't complain... but doesn't save either) (I think it's because it might be 64-bit and Wine doesn't support that). I'll try later on someone else's Windows if it can be used as a loom. Sure hope so.

If that works I might try to port it to Java and make a cross platform program that will do it all: Import sample, Strip .wav headers, Convert to the right samplerate and bitdepth, Interleave the whole lot (the part that needs to be) And than swap the bytes and bits. So you only have to flash it to rom...
But that might be a lot of work for someone as lazy as me.

I'll keep you posted!


p.s.

I was wondering why you are ignoring the A16 pin?:

".... .......
...... .......
A13 A13
A14 A14
A15 A15
N/A A16 <- ignore this

Isn't that the address pin you need for all the hats and cymbals?

[Edit: It IS the pin for the Cymbals and Hats. So DO NOT ignore pin A16...]

[playthatbeat]

I'm not sure offhand why A16 was ignored - it looks from the table like it's not connected maybe? is it held high or low fulltime in operation or something? I'd have to look back at the diagram to work that out..

Ah, so You are in WINE.. i'm on linux here, so am a sometimes Wine user.. I didn't find any advantage to using the 64bit version of anything, in fact for most 'grey-area' stuff like emulators and such, i usually stick to 32bit if there are statics available. If i have to compile it myself, then it has to be 64bit all the way if possible.

Oh i like that newer EPROM PIN SWAPPER app.. going by the date (2012?) it should be much better then the previous very ropey commandline stuff we have seen. wow. that sure beats the shit out of making a loom alright! Hmm.. i suspect the failure to save will be down to file system issues, since i bet Your Mac has EXT3 or EXT4 partitions or whatnot, I always ran Wine with a fat32 or NTFS/3g partition set as a drive, even a crappy old USB stick formatted in NTFS and mounted would do, or, it requires the Micro$oft bundle of Visual Basic (or .net or whatever) bloat to work properly. Oh, I also needed to install a package to enable 3g/NTFS WRITE capability on my system, although that was a couple of years back..

Does VMware work on the Mac? i found that was far better then Wine in the long run.. As long as You have a multi-CPU machine this should be a doddle.

[bartbral]

Okay, I couldn't get it to work with Wine... Tried my girls Xubuntu but that didn't work either... But...

My good friend Karel was so interested when I told him about the sampleswap project that he (without asking) took the challenge... And in a very short amount of time and some sending of files, URL's and info...

He made us a TR505-pinscrambler utility!!!

In the attachment you find executables for Windows and OSX.
And the sourcecode in C++ is also included so you can make your Linux version.

We have both tried and when given your "mod-rim-double.bin" file and scrambling it. The output is exactly the same as the file "mod-rim-double-encrypted.bin".

So bin the loom... and burn some .bin!!!

[playthatbeat]

Wow.. that's pretty heady stuff right there! In fact, it's most likely going to mean we all dig out our 505s and use them some more.. You know how it is - You break the back of something, You use it for a while, then something comes along that needs it's back broken, and so on, in a loop of creative destruction!!!

Oh this is great actually.. The whole loom-building and swapping and so on was such a pain in the hole, and the thing is fragile as well - having an up-to-date software version is a win..

I'll download this now and try compiling it after work tonight..

[bartbral]

Hope you've got it to compile!

Have you got (by any chance) The original (encrypted) rom-dump?
And are you willing to share that?

I'm trying to get my head round why the hats and cymbals don't want to work. And I'm trying to reverse engineer the rom's memory mapping.

In one of your first post on the subject (2010) you wrote that you where able to copy the stock sounds on an eprom. So I can't lay my head to rest before I figure that out... (and still no rom-programmer here )

This what I have come up with:
(interpreted from the service manual info (Table 3))

// samples (128 KB total sample size)
////// First 4 samples are NOT interleaved
// Timbal (8K) starts @ $0000
// Low Tom (8K) starts @ $2000
// High Tom (8K) starts @ $4000
// Mid Tom (8K) starts @ $6000

////// next samples are interleaved
// BassKick (4K) interleaved starts on EVEN-byte, starts @ $8000
// Low Conga (4K) interleaved starts on ODD-byte, starts @ $8001

// Snare Drum (4K) interleaved starts on EVEN-byte, starts @ $a000
// Hi Conga (4K) interleaved starts on ODD-byte, starts @ $a001

// Hand Clap (4K) interleaved starts on EVEN-byte, starts @ $c000
// Low Cowbell (4K) interleaved starts on ODD-byte, starts @ $c001

// Rimshot (4K) interleaved starts on EVEN-byte, starts @ $e000
// Hi Cowbell (4K) interleaved starts on ODD-byte, starts @ $e001

////// next samples are NOT interleaved
// Crash Cymbal (32K) starts @ $10000
// Ride Cymbal (16K) starts @ $18000
// Open Hihat (8K) starts @ $1c000
// Closed Hihat (8K) starts @ $1e000
/////////////////////////////////////////////////////

edit: attached testkit .bin

[bartbral]

Okay,

Easy way to make a tr-505 kit:


Download and install Sox:
http://sourceforge.net/projects/sox/

Download: the attached script:

Put script in the same folder as the following files (names should be identical...
Sample format shouldn't matter... aiff... wav... mp3... whatever)

01_TIMB.*
02_LT.*
03_HT.*
04_MT.*
05_BD.*
06_LCG.*
07_SD.*
08_HCG.*
09_HCP.*
10_LCB.*
11_RIM.*
12_HCB.*
13_CC.*
14_RC.*
15_OH.*
16_CH.*

Run the script... The output will be a file you can run trough the TR505-pinscrambler utility...

Easy does it...

[playthatbeat]

(2 posts up) - a copy of the original encrypted rom you say? i can easily rip that if You really need it, but it's going to be garbage. making audio from it gives just hash, it's only really good for testing a decrypt.

i thought more about the elusive cymbels, and although i thought they were just in a higher block of memory on the chip, and you could toggle a bankswitching somewhere on a pin (remember it behaves like a normal eprom, but it is a custom roland chip) this didn't wash for me as other sounds would still play while cymbels were playing - meaning it was unlikely the rom was being switched.. the machine can clearly access all the data on the rom concurrently, so i guess it's just a strange design that would need my eeprom burner to have special knowledge to read properly.

I should really pull the roms and try extracting them again - my batronix burner has had quite a few updates since i worked on the 505, maybe it 'sees things differently' now

You still want the dump of the scrambled rom?

[bartbral]

Yes the original encrypted rom would really be helpful.

I thought you told a few pages/ages back you'd once dumped it and then copied it to an EPROM. To check if it was possible. That would mean it is possible to write EPROMs with the cymbals and hats if I'm not mistaken.

Now if we run this thru the decrypter program my mate wrote. I hope to see that there will be hats and other metal objects as well.

So if it ain't to much of a hassle, I would really like it if you try the dump again.


I just yesterday ordered a Minipro TL866 - reader/writer - but it'll probably take a few weeks before it'll arrive. So everything I can do to check if it'll work before that, would give the nerd inside me a little peace of mind

Am investigating the TR-707 as well now... And want to help a friend of mine do the "same" thing with that in very near future.

Cheers