thoughts on Digitech Space Station eprom copying?

[Prehistoricman]

Happy new year guys Just joined the forum.

I've just bought an XP-100 and a bunch of parts for one of these conversions, and I've been looking at the code for the XP-100 in a program called IDA. I'm one of those nerds who would reverse-engineer assembly.

I reckon it's possible to make the XP-ALL mod stable with user-presets by modifying the code. Change it to either save presets for each mode separately, or have the presets mean the same number in each mode. I've only just began scratching the surface with the disassembly but it's actually quite a small program. Especially for the XP-100.

Similarly, it may be possible to make the XP-100 compatible with stereo audio via code edits. All it needs is a few extra instructions to control the MOSFET. These are things I think I could do.

Any more ideas? I'll keep digging until I get my unit, build an EEPROM programmer, and do the conversion.

I have found some very weird things in the code so far. There seems to be a lot of data (non-code) that when I force IDA to interpret it as code, looks quite convincing. But it's full of NOPs, which are instructions that do nothing. Example:



This 'data' has lots of structure to it and could very well be code remnants from development! I doubt it could become anything like a missing feature or an easter egg, but still cool.

[digi2t]

Hi there. From all the feedback I've ever received on the XP-ALL or XP-ALL+, user preset retention is probably the biggest query.

As it stands now, you CAN save presets within each mode, but the caveat is that if you set a patch in memory, and it exceeds, or does not exist within, the patch range of any of the other modes, then all bets are off. Switching to another mode, patches in memory will be shifted to some other patch number.

From what I can see, the patch number memory occurs in one place, somewhere else within the architecture. Maybe some sort of register based memory (I'm spitballing on a limb here... ). Within a single chip, with a defined number of patches environment, it's capable of retaining the patches you save in memory. The conflict comes when you have multiple modes...

- The 100 has a total of 29 patches (numbered 1 to 29).
- The 200 has a total of 36 patches (numbered 1 to 61).
- The 300 has a total of 40 patches (numbered 1 to 40).
- The 400 had a total of 41 patches (numbered 1 to 50).

So.... two flies in the ointment here; 1, no two modes has the same number of patches. 2, two modes skip patch numbers.

Hence.... when you only have one memory place to retain patch numbers between several different modes, it would be impossible for it to be able to retain numbers that you programmed from one mode, if those numbers are out of range, or non-existent, in the next mode you go to.

As it stands now, if you can program 6 user patches, and the unit will retain them IF, those 6 patch numbers are common to ALL four (or however many modes you mod your XP to have) modes.

As for your views on the stereo switching angle (I'm going from memory here, pardon the pun), I think that's also set by resistance presence on the board, so I'm not totally convinced that a simple code adjustment will get the job done. You still need to physically switch that MOSFET, which is what the rotary selector is doing anyway.

Regardless.... I watch... with bated breath.

[Govmnt_Lacky]

Similarly, it may be possible to make the XP-100 compatible with stereo audio via code edits. All it needs is a few extra instructions to control the MOSFET. These are things I think I could do.

As for your views on the stereo switching angle (I'm going from memory here, pardon the pun), I think that's also set by resistance presence on the board, so I'm not totally convinced that a simple code adjustment will get the job done. You still need to physically switch that MOSFET, which is what the rotary selector is doing anyway.

The reason why the stereo output is not functional in XP100 mode is because of the coding within the CPU (either the SMD CPU or the EEPROM from older units)

The coding is what tells the CPU to command the audio processor to emit the audio in stereo. If someone can figure out the coding difference between the XP100 and the other platforms then it might be possible. The hang up has been the work/reward ratio. Is it really worth all the effort just to gain XP100 in stereo?

Figuring out the preset storage would be of more benefit for sure. 

[digi2t]

Similarly, it may be possible to make the XP-100 compatible with stereo audio via code edits. All it needs is a few extra instructions to control the MOSFET. These are things I think I could do.

As for your views on the stereo switching angle (I'm going from memory here, pardon the pun), I think that's also set by resistance presence on the board, so I'm not totally convinced that a simple code adjustment will get the job done. You still need to physically switch that MOSFET, which is what the rotary selector is doing anyway.

The reason why the stereo output is not functional in XP100 mode is because of the coding within the CPU (either the SMD CPU or the EEPROM from older units)

The coding is what tells the CPU to command the audio processor to emit the audio in stereo. If someone can figure out the coding difference between the XP100 and the other platforms then it might be possible. The hang up has been the work/reward ratio. Is it really worth all the effort just to gain XP100 in stereo?

Figuring out the preset storage would be of more benefit for sure. 

Amen Brother Lacky. Amen.

[Prehistoricman]

On work/reward... I honestly think that stereo XP-100 would be considerable easier. It's not something I've particularly tried to look at so far but I'll have a poke and see what's up.

The EEPROM that stores user presets and calibration info may not be big enough to store 6 numbers for each of the 4 modes. I'll have to play with it and see if there's any space in the tiny 128 byte baby. Saying that, I haven't seen any code writing or reading to an address bigger than 42 so it may have loads of space.

[Govmnt_Lacky]

The EEPROM that stores user presets and calibration info may not be big enough to store 6 numbers for each of the 4 modes. I'll have to play with it and see if there's any space in the tiny 128 byte baby. Saying that, I haven't seen any code writing or reading to an address bigger than 42 so it may have loads of space.

This is why the attempt has languished for so long 

Too many hurdles to overcome. The fact that the component is SMD scares most away. Now, factor in that it will most likely need to be replaced with something with more memory AND a larger footprint and just about everyone else is gone.

Now on to the hard part... 

Now, you have to make sure that the CPU talks properly to the new EEPROM (addresses presets correctly, powers appropriate sectors when needed, language, etc.

It would be wonderful if a through hole equivalent could be used (prefer single solution over multiple pieces of the same IC) and easily adapted to the XP PCB.

Good luck. I'll be keeping my eye out for any revelations....

[Prehistoricman]

Update! The EEPROM may be tiny, but there's less than 13 bytes of information actually stored on it!
Based on the XP-100 and 300 code, I drew out this memory map for it:



Less than half of the address space is really used, so it's really possible to have separate presets for each XP.
Makes me wonder how Digitech chose 6 user presets. They clearly weren't near any kind of physical limit. For the EEPROM anyway... IDA tells me that none of the RAM locations between 0x61 and 0x7F are used.

I'll see about modifying the XP-300 code to use different EEPROM locations. Are you guys in a position to test a new binary? I won't have my hands on a unit for some time.

[Prehistoricman]

Alright! That only took a bit more than an hour. I modified the XP-100 binary because I'm much more familiar with it. The theory is:

For saves and reads to the EEPROM:
is the address between 0 and 5 (preset locations)?
if so, add 6 to the address
continue as normal

I put just 11 commands at 0x3070 that should do exactly that. The first idea I had involved changing the meaning of some RAM locations which was a pretty dumb first thought. I'm happy with this solution. It puts the XP-100 presets at locations 6-11 instead of the normal 0-5.

So it's on my OneDrive at https://1drv.ms/u/s!AtZBAUZdlxZviJR99BNbF-AJNTsrOQ. Please have a go and see if it works!

This won't address any weirdness when changing from XP-100 to something else where it tries to load up the preset you last used. I can probably do something about that as well though...? 

[digi2t]

Since there are 20 memory slots available, is it possible to assign 5 per mode? Example; 0-4 for 100 mode, 5-9 for 200 mode, etc? I know that would require reducing the user saved patches from 6 to 5, but 5 should be enough... and better than none.

Sorry in advance for the noob question. I'm really outta my league here. 

[Prehistoricman]

Ah you see I only showed the used data on the EEPROM there. The addresses go up to 64. We could store 12 or more for each mode!
Even if we didn't have the space all the way to 64, there's enough room for 4x 6 locations. Addresses 23-28 has exactly the right amount of space for 1 mode.

Not a noob question! Problem exists between chalk and blackboard

[Govmnt_Lacky]

I like where this is going. One point to make....

If there is a way to store preset numbers in different 'blocks' within the 94-series EEPROM then each of the XP programs (on the 27C1001) will need to be modified to look at the different areas of the 94-series EEPROM. Right now, all of the XP programs are written to look at the exact same area of the EEPROM for the presets. That would need to be changed and individualized for the 200, 300, and 400 programs.

[Prehistoricman]

Yes. Did you see my reply #667?

[Govmnt_Lacky]

Yes. Did you see my reply #667?

Just did  I see what you did there...

This is starting to heat up. Now, I am wondering if there is a way to program the EEPROM on-board the XP pcbs 

[Prehistoricman]

ah shit whoops 
I forgot that the XP-100 was in a masked ROM. Unfortunately they're one time programmable. I'll have a go at editing the XP-300 binary and upload that soon.

I've been looking at stereo in XP-100 and it looks like it has all the functionality there... very strange. Registers P32 and P17 control wet/dry output and they're both edited 8 times by both the 100 and 300.

[Prehistoricman]

Done! I haven't had a thorough look at the result of this one because it's a pain in the ass, but the editing was much faster since I'd already coded it.
I chose location 12-17 for this one as it's the third XP 

https://1drv.ms/u/s!AtZBAUZdlxZviJYlG2nrMCyKnKW3rw

[digi2t]

So... if I understand this correctly....

Once you adjust the code in each bin, I can burn a new 27C1001. Plop into my XP-ALL+, and I should be able to store 6 user preset for each mode, and they will be retained. Regardless of patch number.

Right?

[Prehistoricman]

I hope! Of course this most recent one I've done is just for the XP-300 to store its presets in a different place to the others. So your 100, 200, and 400 presets will still get mixed up. If it works on the XP-300 then I can spend a couple hours doing the same mod to the other binaries and then you should be able to store 6 presets for each mode, individually.

[digi2t]

OK. PM sent btw. Just a head's up.

[mongo]

Maybe new sounds and space effects for the 300 or are we talking about something completely different?

Happy new year guys Just joined the forum.

I've just bought an XP-100 and a bunch of parts for one of these conversions, and I've been looking at the code for the XP-100 in a program called IDA. I'm one of those nerds who would reverse-engineer assembly.

I reckon it's possible to make the XP-ALL mod stable with user-presets by modifying the code. Change it to either save presets for each mode separately, or have the presets mean the same number in each mode. I've only just began scratching the surface with the disassembly but it's actually quite a small program. Especially for the XP-100.

Similarly, it may be possible to make the XP-100 compatible with stereo audio via code edits. All it needs is a few extra instructions to control the MOSFET. These are things I think I could do.

Any more ideas? I'll keep digging until I get my unit, build an EEPROM programmer, and do the conversion.

I have found some very weird things in the code so far. There seems to be a lot of data (non-code) that when I force IDA to interpret it as code, looks quite convincing. But it's full of NOPs, which are instructions that do nothing. Example:



This 'data' has lots of structure to it and could very well be code remnants from development! I doubt it could become anything like a missing feature or an easter egg, but still cool.

[Prehistoricman]

Maybe new sounds and space effects for the 300 or are we talking about something completely different?

I've since found that all of that is actually real data that's sent to the DSP. Nothing hidden in the code here folks Although it is interesting that it closely represents code.
As I said in our new XP-ALLin thread, I'm getting a unit soon and I'll play with the DSP code. I've already tested a DSP mod to the XP-100 with digi2t and it did... something. The space station is a much more complicated effect though.