Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Xpantastic
- Messages
Search
|
Re: Xpander ROM disassembly
Exactly. Of course, if people are happy for board mods, there's a chunk of address space which is just being mirrored for the dealing with output (ie, the last 4k iirc which actually just has something like 12 output addresses). But to get into there, you'll need to add some wires and some logic gates -- far beyond a simple hack. The best chance to add in new behaviour is if the code in the ROMs isn't particularly optimized for space. It's a long shot though. You might be able to claw back a few bytes here and there, but then you have the challenge of making a big enough hole to then do something worthwhile without breaking the existing code. It could be an interesting project for someone to look into this, and the sheer challenge of understanding code from the disassembly is kinda fun. //deano On Thu, Jun 14, 2018 at 5:14 PM, Tony Cappellini cappy2112@... [xpantastic] <xpantastic@...> wrote:
|
|
Re: Xpander ROM disassembly
On Thursday, June 14, 2018 11:14 AM, "Tony Cappellini cappy2112@... [xpantastic]" wrote:
?
>Karl, >>>>I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. >there are 4 8K ROMS, and 3 8K RAMS?on the processor board, two ROMS and two RAMS on the voice board. >The 6809 only has a 64K address space. 56K of address space is already used on the processor board. >Unless you put in a?whole new circuit board to do bank switching (and rewrite the FW to go with it), you won't be able to use larger EEPROMS.
|
|
Re: Xpander ROM disassembly
Karl, >>I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. there are 4 8K ROMS, and 3 8K RAMS?on the processor board, two ROMS and two RAMS on the voice board. The 6809 only has a 64K address space. 56K of address space is already used on the processor board. Unless you put in a?whole new circuit board to do bank switching (and rewrite the FW to go with it), you won't be able to use larger EEPROMS. On Thu, Jun 14, 2018 at 9:03 AM, Karl Schmeer shire03@... [xpantastic] <xpantastic@...> wrote:
|
|
Re: Xpander ROM disassembly
PeWe Wrote: >>"So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side. >> I dunno if that?s doable via software at all, but it would be great if it were." Hi PeWe, This is what I am talking about.?? Permanently assigning some parameters to midi CC's??like many current synths are capable of doing. Yes it would take a considerable amount of understanding of the firmware, but it should be possible if enough room could be found in the ROMS. If not just have to use the slower sysex method. Another possibility: I have seen guys use larger EEPROMs to condense the size of memory in some HP test equipment. Using this technique it may be possible to allow more room? for added features.?But I have not fully investigated this yet. Sent you a PM Best Karl On Wednesday, June 13, 2018 10:12 PM, "PeWe ha-pewe@... [xpantastic]" wrote:
?
Hi Karl !
A bit O.T. but ... Assigning MIDI CCs to Xpander-parameters like VCF cutoff and MIDI volume works on my Xpander uising the MIDI Controls page. The limitation are the modulation busses,- pedals #1 & #2 and levers #1 & #2,- which isn?t enough, especially vs. the count of modulation destinations in the mod-matrix. So, when there were a chance maxing out modulation busses in the sense of mod-sources, that would be most excellent. There?s a bug in Multipatch-Mode when changing multi-patches via MIDI PrgCh. while MIDI CC#07 is assigned to "pedal #2" as a source and a value is being received. The volume drops to zero then and it needs another MIDI CC#07=127 command to get some noise back from the synth. I?m pretty sure it?s a bug because "lever #2 and "pedal #2" are "universal" (global) controllers while lever and pedal #1 work individual for each voice. So, in Multipatch Mode, MIDI CC#07 should be the master volume controller which should work when sending a program change and volume offset command,- but it doesn?t because there?s no guarantee, the volume command arrives after the program change in exact sequential order when being transmitted from p.ex. a MIDI processor/matrix switcher or masterkeyboard. A sequencer might handle that different compared to the devices mentioned above though. In addition to the "master volume" functionality in "Multipatch-Mode", individual / relative volume control (not overriding MIDI CC#07 value !) for each voice should work using MIDI CC#11 together w/ MIDI CC#07 and w/o dropping overall volume to zero. But even when we can get rid of the bug mentioned above, in Multipatch-Mode using MIDI CC#07 and MIDI CC#11 simultaneously eats up both pedals as modulation sources and makes it impossible using MIDI CC#04 for filter cutoff, may it be per voice or global,- WHEN the mod wheel is in use for vibrato p.ex.. So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side. I dunno if that?s doable via software at all, but it would be great if it were. Anyway,- now some private stuff and because it?s the occasion to send some lines ... I received and still do receive all your emails, but when I reply, ALL the emails I send to shire03@... come back to me as a mailer demon after exactly 4 (FOUR !!!) days. I regret and have no idea what causes that behaviour, but we should try to find another way for private communication I think. Maybe PMs @ Keybd Corner ... (???) ... what do you think ? Please reply to my private email addy 1st. When you agree, you might post something over there,- I?ll recognize and will jump in via PM. Let me know please. thx for reading :-) PeWe ? Am 14.06.2018 um 00:02 schrieb Karl Schmeer shire03@... [xpantastic]: ? |
|
Re: Xpander ROM disassembly
FYI- thanks everyone for replying. I think some of you may have gotten the wrong idea about my post. I¡¯m not planning on adding any features, nor extensively document the hopefully-forthcoming disassembly. I don¡¯t think I have the experience that deserves. My intent was simply to see how¡¯ve the cassette dump works, just for my own education. I am mor than happy to share what I find (if anything), as well as the disassembly (which will be very ra and crude), and of course talk all of this over on the list. Regarding adding features- there¡¯s is very littke code space left, I¡¯m not sure how much could be added, even if we had documented sources. I am off for vacation for 2 weeks, so no work on this will take place until closer to the end of the month. Until then- keep on patching!
|
|
Re: Xpander ROM disassembly
¿ªÔÆÌåÓýHi Karl !
A bit O.T. but ... Assigning MIDI CCs to Xpander-parameters like VCF cutoff and MIDI volume works on my Xpander uising the MIDI Controls page. The limitation are the modulation busses,- pedals #1 & #2 and levers #1 & #2,- which isnt enough, especially vs. the count of modulation destinations in the mod-matrix. So, when there were a chance maxing out modulation busses in the sense of mod-sources, that would be most excellent. Theres a bug in Multipatch-Mode when changing multi-patches via MIDI PrgCh. while MIDI CC#07 is assigned to "pedal #2" as a source and a value is being received. The volume drops to zero then and it needs another MIDI CC#07=127 command to get some noise back from the synth. Im pretty sure its a bug because "lever #2 and "pedal #2" are "universal" (global) controllers while lever and pedal #1 work individual for each voice. So, in Multipatch Mode, MIDI CC#07 should be the master volume controller which should work when sending a program change and volume offset command,- but it doesnt because theres no guarantee, the volume command arrives after the program change in exact sequential order when being transmitted from p.ex. a MIDI processor/matrix switcher or masterkeyboard. A sequencer might handle that different compared to the devices mentioned above though. In addition to the "master volume" functionality in "Multipatch-Mode", individual / relative volume control (not overriding MIDI CC#07 value !) for each voice should work using MIDI CC#11 together w/ MIDI CC#07 and w/o dropping overall volume to zero. But even when we can get rid of the bug mentioned above, in Multipatch-Mode using MIDI CC#07 and MIDI CC#11 simultaneously eats up both pedals as modulation sources and makes it impossible using MIDI CC#04 for filter cutoff, may it be per voice or global,- WHEN the mod wheel is in use for vibrato p.ex.. So, the Xpander/ Matrix-12 needs more modulation busses/channels on the modulation-input side. I dunno if thats doable via software at all, but it would be great if it were. Anyway,- now some private stuff and because its the occasion to send some lines ... I received and still do receive all your emails, but when I reply, ALL the emails I send to shire03@... come back to me as a mailer demon after exactly 4 (FOUR !!!) days. I regret and have no idea what causes that behaviour, but we should try to find another way for private communication I think. Maybe PMs @ Keybd Corner ... (???) ... what do you think ? Please reply to my private email addy 1st. When you agree, you might post something over there,- Ill recognize and will jump in via PM. Let me know please. thx for reading :-) PeWe Am 14.06.2018 um 00:02 schrieb Karl Schmeer shire03@... [xpantastic]:
|
|
Re: Random patches bounty
I agree, changing Xplorer to do that should be trivial. However, anyhting you can do from Xplorer you can do from the Xpander, except for random patch generation. We dont have the Xplorer source though. (assuming I understand your original request) Generate the random patch in Xplorer, then pull that patch into your Xpander, then edit the patch on the XPander to add Keyboard control.
|
|
Re: Xpander ROM disassembly
Hi Tony, I have written tons of assembly code for a Motorolla 68HC11 which has a similar instruction set. I would be willing to help with this project any way I can. I would love to "enhance" the original code to allow some midi cc of parameters like filter, envelope times etc.. As well as allow midi volume control (cc #7). BTW? there are two sets of firmware for the Xpander / M12.?One set of?for the system CPU and one set for the voice boards. ?I imagine you are talking about the code for the system cpu ? Karl On Wednesday, June 13, 2018 3:48 PM, "Tony Cappellini cappy2112@... [xpantastic]" wrote:
?
If I can get it disassembled- correctly I will. I don't have any serious plans other than looking through it to see what might jump out. I don't know if I'll get around to adding any comments, since I've never done any real disassembly before.
|
|
Re: Random patches bounty
Hi Jeremy Can't you generate a random patch with Xplorer, then just edit it mnaully with the program to do that?
|
|
Re: Xpander ROM disassembly
If I can get it disassembled- correctly I will. I don't have any serious plans other than looking through it to see what might jump out. I don't know if I'll get around to adding any comments, since I've never done any real disassembly before.
|
|
Re: Xpander ROM disassembly
I've not done this for the Xpander, but I have for the Prophet VS. I combined the roms into one file using Python - relatively simple script to load a byte from each file and interleave them. I then used IDA Pro to turn into code (68k for the VS). It's quite an interesting task to do, though I didn't get around to fully decompiling/commenting. The xpander should be interesting as it uses a 6809 chip (68b09) as used in Robotron. Should be relatively easy to understand the code, though it will be very verbose and reliant on the other chips around it (so have a schematic handy to figure out the memory map) Good luck! On Tue, Jun 12, 2018 at 9:41 PM, Tony Cappellini cappy2112@... [xpantastic] <xpantastic@...> wrote:
|
|
Xpander ROM disassembly
Has anyone here attempted to disassemble the XPander or Matrix 12 ROMS? If so, where is the dissembled source code at? If not, what would you recommend using getting the ROM bin files that are separated into even & odd addresses, into 1 contiguous file? I don't want to goof that up and make the job more difficult. Thanks Tony |
|
Re: Xpander sysex patch spec- the Xplorer version
Hi, you should look at the XpanderSinglePatchViewer.cpp, it is self explanatory there. you have OBWORDS_DATA_LENGTH of data to be "repacked" as double byte values, which is not required of course for the patch name (string) that comes afterward. ??? // for each double byte, repack the value, and set the Patch property accordingly ??? unsigned char* pByte= (unsigned char*)pPatch; ??? for (int i=0;i<OBWORDS_DATA_LENGTH;i++) { ??? ??? // 8th bit of the 8 bits value is the first bit of the high byte ??? ??? unsigned char cValue = ((shortArray[i] & 0x0100)>>1) | (shortArray[i] & 0x00ff); ??? ??? *pByte=cValue; ??? ??? pByte++; ??? } ... ??? // name is 2 bytes/char, high byte never used, thus wchar_t compatible ??? iReadBytes=0; ??? iReadBytes=fread(&pPatch->name,sizeof(wchar_t),PATCHNAME_LENGTH,pFile); ??? assert(iReadBytes==PATCHNAME_LENGTH); Regards, |
|
Re: Xpander sysex patch spec- the Xplorer version
>>?196 & 2 + 8 = 399 bytes, which is correct I have to correct my own calculation, however it still doesn't add up from what i can see. 196 *2 = 392 bytes, including the patch name. Add the first 6 bytes for the sysex command, + 1 EOX, 399 bytes. On Tue, May 22, 2018 at 1:46 PM, cappy2112@... [xpantastic] <xpantastic@...> wrote:
|
|
Re: Xpander sysex patch spec- the Xplorer version
I think the comments explain it: "188 double bytes data for the values and 8 double bytes for the patch name" What is meant by "double bytes" is some form of encoding bytes (8-bit values) into sysex data, which is a string of 7-bit values. Often this means splitting a byte into a high nibble and a low nibble (4+4 bits) but I don't know if that's what the Xpander does. Also see the second comment: "6 (intro) +196*2 (data+name) +1 (EOX) = 399" So 7 MIDI bytes of framing, leaving 399-7=392 sysex data "bytes" (7-bit values). Divide that by 2, and you get 196 proper bytes (8-bit values).
|
|
Xpander sysex patch spec- the Xplorer version
I'm trying to understand the calculations that the single patch browser (included with Xplorer) ueses. Looking at XpanderSysEx.h // Single patch data sysex length is 399 bytes // 6 bytes for sysex intro: F0 10 02.... static const int PRG_DUMP_DATA_FOLLOWS_INTRO_LENGTH = 6; // 188 double bytes data for the values and 8 double bytes for the patch name static const int PATCHNAME_LENGTH = 8; static const int OBWORDS_DATA_LENGTH = 196 - PATCHNAME_LENGTH; // 6 (intro) +196*2 (data+name) +1 (EOX) = 399 I understand that?PRG_DUMP_DATA_FOLLOWS_INTRO_LENGTH is for the Sysex cmd overhead to request a single patch, however, I don't understand why he subtracts the patchname length from 196, when the patch name is part of each single patch. 196 & 2 + 8 = 399 bytes, which is correct What am I missing? |
to navigate to use esc to dismiss