ris8_allo_zen0

While hunting for that strange issue of the last column, I had a doubt about this code in seq_buttons.inc:131: ;; since the row line of the buttons is identical to the row line of the LEDs, ;; we can derive the button row offset from SEQ_BLM_ROW_CTR ;; store row*2 offset in IRQ_TMP1 decf SEQ_BLM_ROW_CTR, W, BANKED rlf WREG, W andlw 0x06 movwf IRQ_TMP1 Why WREG should contain SEQ_BLM_ROW_CTR minus one? What happens if I replace decf with movf? Tomorrow I'll try this anyway, I'm asking to have better knowledge of the mechanism I'm messing with ;) Best regards, Enrico

Indeed MIOS v1.9f didn't made anything better :( Advice for future MIDIboxers: beware of them! (link to PDF) Best regards, Enrico

Attachment time :) There's an updated version of the c64k mod already set up for the DIN/DOUT pair connected at the beginning of the chain. There's only need to set up the button assignment as said in my previous post. Then I corrected the scan circuit: I inverted the SI/SO wires in the "to peripheral" connector. Just to know: how many people are currently interested in this mod? Best regards, Enrico mbseq_c64k.diff.txt bottom-new.zip mbseq_c64k.diff.txt scanmatrix.GIF bottom-new.zip

Sorry, I haven't fully read your message... Yes, probably the numbering in the LCD is referring to a connector mounted in the component side so also I had to swap pairs of wires: 2,1,4,3,6,5,8,7,10,9,12,11,14,13,16,15. To avoid going completely crazy between all those grey wires, I drew some dots on them to represent a number between 1 and 16 in binary (e.g. dot-blank-dot-dot = pin 11) and to recognize the right one while filling the connector. Best regards, Enrico

I just did exactly like glitched. In my first attempt, the IDC connector worked once every two times (and having continuity testing pain everytime). Then I clamped another IDC connector next to that one taking care the wires remain all parallel, then I removed the first one. Attached & detached 4-5 times and still no issues. Best regards, Enrico

I've read this topic just now, maybe this new firmware can solve also my encoders problem: they're not Bourns but they behave like the ones MD described. Best regards, Enrico

The items arrived, I've built the basic boards and connected everything at minimum to be able to test my mod. With some debugging, I'd say it mostly WORKS! YEAH :D Instead of the keymap table, the new code directly calls the button handler so the DIN table is used: SR# is now the row index from 2 to 9 (to avoid conflicts with the matrix's SR), and the pin number is the column index. Still have to solve two one zero issues: - handle GP buttons, which aren't directly specified in the DIN map (is it possible to insert them anyway? Edit: yes, just add SEQ_BUTTON_GPx to the list) - strangely, the rightmost buttons don't work (the ones of the last column, #7). Not a hardware problem, because the c64-keyboard-test app works nice. Edit: indeed it was a software fault Best regards, Enrico

While waiting for parts to arrive, I've made the scan matrix circuit. It's very similar to bill's one, with DIL connections instead of SIL (directly to J8/J9 connector) and another connector for the remaining DIN/DOUT modules. I made it with Eagle, so there are the schematic, the board and a GIF for quick reference. I hope this can be helpful. Best regards, Enrico c64keyb.zip scanmatrix.GIF c64keyb.zip

Sasha you're a GENIUS!! :D I love that "Non-Stop" marker... What about "Da-SID-sette" ?

My dream: SID / \ TK's genius / \ Me & my hands / \ Hundreds of people dancing 8)

They're perfect! Thanks!! As TK said, more than 1A is too much for a Seq. Check carefully (both visually and with a multimeter) that each pair of solderings in the PCBs are isolated from each other - sorry, it's quite late now to remember other troubleshooting ideas...

The better answer will come from who's successfully built a Duo-Led SEQ... that's not me :( So at the moment you don't have any PSU suitable to power the Seq? Some time ago I used the 5V line (red-black) of my PC's ATX power supply, which is usually able to source 25-30A. You can try this way just the time to measure the amount of current while "idle", i.e. with no led matrix on (or even with the matrix DOUTs disconnected!), and see if there's some current leakage somewhere. Currently I'm building a non-expanded Seq. The only problem I'm having now is to find the knobs. Tried at ALBS but my order is below their minimum :(

Ciao Patrizio! (ti rispondo in inglese così altri possono beneficiare di queste info... sempre che siano giuste!) Try to measure the current with your multimeter, if you get much more than 1A maybe there's something wrong with your hardware. I didn't find anyone in the forum with power issues with Duo-Led matrix (can you do a search too?), neither read anything about empowering the voltage regulator. However it's better 9V 1A then 12V 1A, so the regulator has less work to do = less heat. let me know, also I'm building a SEQ ;)

Here is my less-than-alpha, still-to-be-debugged patch for C64 keyboard support for MBSEQ v3.2. I didn't write any mapping table yet - it just checks for the Commodore key and this will recall the menu. I don't want to go further without doing any debugging, so it's here for who wants to have a look at (and maybe do some checks). I'll continue this work when I'll have the parts from SmashTV. Best regards, Enrico diff -au midibox_seq_v3_2/app_defines.h midibox_seq_v3_2_c64k/app_defines.h --- midibox_seq_v3_2/app_defines.h Fri Jul 06 16:27:57 2007 +++ midibox_seq_v3_2_c64k/app_defines.h Fri Jul 06 01:15:20 2007 @@ -431,7 +431,9 @@ SEQ_EDIT_SONG_BANK_G3 EQU 0x17c SEQ_SONG_RECURSION_CTR EQU 0x17d ; used in "seq_song.inc", SEQ_SONG_FetchPosDirect to avoid a live lock - ;; free: 0x17e-0x19d +SEQ_BLM_ROW_CTR_3 EQU 0x17e ; RAZ: 3-bit row counter for C64 keyb matrix + + ;; free: 0x17f-0x19d ;; ================================================================================== diff -au midibox_seq_v3_2/main.inc midibox_seq_v3_2_c64k/main.inc --- midibox_seq_v3_2/main.inc Tue May 22 01:39:26 2007 +++ midibox_seq_v3_2_c64k/main.inc Sun Jul 08 01:41:11 2007 @@ -12,7 +12,7 @@ ; ========================================================================== ; ; Version: <--------------> -#define MBSEQ_VERSION_STR "MBSEQ V3.2 " +#define MBSEQ_VERSION_STR "MBSEQ V3.2-c64k " ; (fixed string length - 16 characters!) ; ; Only in midibox_seq_v3_2_c64k: price.xls diff -au midibox_seq_v3_2/seq_buttons.inc midibox_seq_v3_2_c64k/seq_buttons.inc --- midibox_seq_v3_2/seq_buttons.inc Tue May 22 01:39:26 2007 +++ midibox_seq_v3_2_c64k/seq_buttons.inc Sun Jul 08 01:38:43 2007 @@ -117,6 +117,17 @@ ;; since the row line of the buttons is identical to the row line of the LEDs, ;; we can derive the button row offset from SEQ_BLM_ROW_CTR +#if DEFAULT_SRM_8X8_ENABLED + ;; (RAZ) we use the 3-bit version to use the whole 8x8 matrix. + decf SEQ_BLM_ROW_CTR_3, W, BANKED + movwf IRQ_TMP1 + + ;; (RAZ) the matrix pins are connected to the left DIN. + movlw DEFAULT_SRM_DIN_L - 1 + ;; rgoto SEQ_BUTTON_GetRowIRQ_Sub + +#else + ;; store row*2 offset in IRQ_TMP1 decf SEQ_BLM_ROW_CTR, W, BANKED rlf WREG, W @@ -131,7 +142,7 @@ incf IRQ_TMP1, F ; row*2+1 movlw DEFAULT_SRM_DIN_R - 1 ;; rgoto SEQ_BUTTON_GetRowIRQ_Sub - +#endif ;; expecting: DIN SR number in WREG ;; row counter in IRQ_TMP1 @@ -265,6 +276,27 @@ movlw 0x01 movwf MIOS_PARAMETER2 +#if DEFAULT_SRM_8X8_ENABLED + + ;; (RAZ) takes current row and column and uses them as an index + ;; for the 8x8 mapping table. Format is 00rrrccc. + movf SEQ_BLM_COL_CTR, W, BANKED + rrf WREG, W + rrf WREG, W + rrf WREG, W + iorwf MIOS_PARAMETER1, W + + ;; As a first try, check for press of the "C=" button, which recalls the menu. + xorlw b'00110101' ; fifth column of the sixth row of the C64 keyboard matrix + bnz SEQ_BUTTON_SRM_8X8_End + movlw (5+8*2) ; fifth pin of second SR, which recalls SEQ_BUTTON_Menu + movwf MIOS_PARAMETER1 + call SEQ_BUTTON_Handler + +SEQ_BUTTON_SRM_8X8_End + +#else + ;; switch to 8-15 in MIOS_PARAMETER1 if right half of 4x16 matrix btfsc SEQ_BLM_COL_CTR, 0, BANKED bsf MIOS_PARAMETER1, 3 @@ -287,6 +319,7 @@ call SEQ_GP_Button #endif +#endif ;; request display update bsf CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ diff -au midibox_seq_v3_2/seq_leds.inc midibox_seq_v3_2_c64k/seq_leds.inc --- midibox_seq_v3_2/seq_leds.inc Tue May 22 01:39:26 2007 +++ midibox_seq_v3_2_c64k/seq_leds.inc Fri Jul 06 16:03:23 2007 @@ -169,6 +169,12 @@ incf SEQ_BLM_ROW_CTR, F, BANKED bcf SEQ_BLM_ROW_CTR, 2, BANKED ; wrap at 4 +#if DEFAULT_SRM_8X8_ENABLED + ;; (RAZ) increment BLM 3-bit row counter, for 8x8 scan matrix + incf SEQ_BLM_ROW_CTR_3, F, BANKED + bcf SEQ_BLM_ROW_CTR_3, 3, BANKED ; wrap at 8 +#endif + ;; ---[ update the GP LEDs ]--- ;; store selected track in IRQ_TMP5[3:0] @@ -375,6 +381,11 @@ ;; if track active: cathode signal must be 0 ;; if track not active: cathode signal must be 1 SET_BSR SEQ_BASE +#if DEFAULT_SRM_8X8_ENABLED + movf SEQ_BLM_ROW_CTR_3, W, BANKED + call MIOS_HLP_GetBitANDMask + movwf MIOS_PARAMETER1 +#else movf SEQ_BLM_ROW_CTR, W, BANKED call MIOS_HLP_GetBitANDMask andlw 0x0f @@ -383,6 +394,7 @@ ;; duplicate for button matrix swapf WREG, W iorwf MIOS_PARAMETER1, F +#endif #if DEFAULT_SRM_DOUT_CATHODES1 movlw DEFAULT_SRM_DOUT_CATHODES1 - 1

I'm going to finish the "c64k" mod. I made a new variable, SEQ_BLM_ROW_CTR_3, similar to SEQ_BLM_ROW_CTR but wrapping at 8; this one is used to set the cathodes' DOUT (I can't say if the Duo_Led matrix is compromised or still works). All my modifications are surrounded with #ifs to revert to original function. Another two questions (be patient...): 1- I need to implement a "keymap table" with about 64 entries, that matches each C64 key with its emulating SR/Pin pair. Can I add this table just after the DIN map, e.g. at 0x31C0 or 0x3200 ? What can I do otherwise? 2- I'm using button_duoled_matrix.pdf as hardware reference. I read the names DEFAULT_SRM_DOUT_CATHODES_L and _R, but there aren't any of them in setup.asm, just _CATHODES1 and 2. I suppose _L and _R are in fact the same pins... right? Am I seeing a documentation error? Best regards, Enrico

I studied that part of code. It looks good to my purposes, but I have a question: Is SEQ_BLM_COL_CTR a row index? Because I can't figure out why it is used in the code that "selects tracks depending on row" (row 273 in seq_button.inc). If I think of it as a row index, the code looks quite clear to me. (in my mind I see the "pins" ordered horizontally...) Best regards, Enrico

Hi Rio, I knew about your project when stryd_one posted a link in this thread... nice idea! Indeed I want to obtain a similar layout, but with a C64C, the two 2x40 LCDs and some keys repainted & relabeled for use with SEQ (because I don't need to make a midi-controller out of a C64). And use just one core, following TK's instructions, so I can learn something about MB programming. I admit I haven't fully understood what you said about the recording function for SEQV3 (surely because I still don't have one)... it looks like there are some bugs in the "remote keys" function; this suggests me to keep going with the single-core solution. Best regards, Enrico

Thanks TK... I forgot to say I wanted to remap the keys so that the GP buttons are the white ones aligned to the LCD text (e.g. GP1..8 = B-1..B-2, assuming the 1st note on the left is C-1). So - I suppose - with some practice I can press the corresponding GP "key" without even look at it. Do you think this can increase the ergonomy a little bit? (I hear my auto-responder saying "why don't you try by yourself?") Best regards, Enrico

Hi all! Here's how I think to keep my summer days busy: a Midibox SEQ and a MIDIfied 4-octave keyboard in a single unit! The keyboard currently has no MIDI, just a crappy synthesizer and a simple chord arpeggiator. However the keys are full-size (still no velocity sensing) and there are also stereo loudspeakers and amplifier. The button panel is fully detachable by unscrewing it, so it's not very difficult to replace it with another one. The measures are 46x12cm, nearly a 19" size. That would be perfect for a SEQ that includes the 2x40 displays, the encoders, the Duo-Led matrix, the datawheel and some other stuff. Here are my "critical" design ideas about which I ask your opinion: 1) Use 16 led bars instead of the Duo-Led matrix. They have 10 leds each, I'll use 8 to represent position and status of each track. So no button matrix for now... 2) Use the keyboard itself to command the Seq using the Remote Control feature. I'll add a switch to choose between "master keyboard" mode and "Seq function" mode. Then I'll add a LED above each of the keys whose function requires it. There aren't enough keys to map all buttons, so some "real" switches will be built in the panel. for 1) I'm afraid the compactness of the LED bars keeps the reading difficult (surely it'll be cool!), for 2) I don't know which/how many buttons really need to be pressed while playing with the master keyboard. The image shows an incomplete CAD sketch of what I want to do. Any comments? Best regards, Enrico

Thank you a lot TK!

Hmmm, I forgot some useful words in that sentence: "Many SEQ users used its case...". Never heard about the k64, nice!! You frightened me :) besides that, I think the better option for me is not to touch the seq firmware (except the key/command mapping, seq_remote.inc looks almost self-explanatory) and make my keyboard a "master" keyboard. Thank you for the suggestions! Best regards, Enrico

I answer by myself: The SEQ has the "remote function" mode, which allows to receive MIDI Note events on a particular channel where each note corresponds to a key. So I have three options: 1) put two cores into the C64 case, one is the SEQ and the other is the C example of C64 scan matrix (http://www.midibox.org/dokuwiki/doku.php?id=midiboxkb_-_using_a_c64_keyboard_as_input), slightly modified; 2) melt together the SEQ firmware and that C example, then let each MIDI OUT event from the keyboard call a MIDI IN event of the Seq, so I use just one core; ----- 3) completely change my objectives and fit the SEQ in a 4-octave toy keyboard (http://www.flickr.com/photos/ris8_allo_zen0/tags/toy) still waiting to be MIDIfied :) just need to find a way to remap all the commands into four octaves. 8)

Hi all, I have a C64C as gift from a friend. Many have used its case, but I see nobody tried to use also its keyboard. Because I want to minimize the TTP (Time-To-Play :P) and avoid making each button, I thought it could be good to have a SEQ: - leaving the same keyboard, - re-purposing the keys, - putting some status LEDs around them - and adding the encoders and the two LCDs on the top part. The firmware must be able to do key matrix scanning, so I can leave the keyboard unaltered (except re-labeling keys!) and have less DINs to build. How difficult it is to integrate key scanning in SEQ's firmware? I have some assembler programming experiences, I also saw there's MBHP software to handle C64 keyboard, and I like spending my time programming rather than doing repetitive tasks (like mount each button). What I don't know, is whether is really worth the effort... Any help/idea appreciated!! Best regards, Enrico

I just changed R6 in the Core as I said, and it works perfectly! Now I can play freely from the PC (which I used as a bridge)... But the problem is simply postponed until I want to use a device not built by me... maybe in the next weeks I'll ask your help trying to fix the keyboard (that's what I tried to do these days, without success). Best regards, Enrico

The keyboard is a Roland PC-160A bought via eBay. The buyer said he had no problems using it... I didn't notice anything because the adaptor was built using the PC-160A for testing; the only strange thing was, as I said, the different resistor value.