Jump to content

SEQ with C64 keyboard


ris8_allo_zen0
 Share

Recommended Posts

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

I have a C64C as gift from a friend. Many have used its case, but I see nobody tried to use also its keyboard.

Bzzzzt I'm sorry that's incorrect but thanks for playing! ;) The correct answer was "What is the k64?"

You should be able to mash together the ASM scan matrix code and the seq... Make sure it's light on the processor though, you don't wanna mess with that lovely tight timing :)

Link to comment
Share on other sites

Bzzzzt I'm sorry that's incorrect but thanks for playing! ;) The correct answer was "What is the k64?"

Hmmm, I forgot some useful words in that sentence: "Many SEQ users used its case...". Never heard about the k64, nice!!

You should be able to mash together the ASM scan matrix code and the seq... Make sure it's light on the processor though, you don't wanna mess with that lovely tight timing :)

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

Link to comment
Share on other sites

It isn't possible to merge C code with the MBSEQ V3 application, as it already allocates most of the resources.

But you can just re-use the button matrix code which is located in seq_button.inc (search for SEQ_BUTTON_GetRowIRQ and SEQ_BUTTON_SRM_Handler)

From the SRM_Handler, you can easily branch to the SEQ_BUTTON_Handler in order to trigger functions which are listed in SEQ_IO_TABLE_DIN (I think if you know assembler, this information should be enough)

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 2 weeks later...

hi ris8_allo_zen0,

Jambonbill used that keyboard as little sequencer: http://www.midibox.org/dokuwiki/doku.php?id=midiboxkb_-_using_a_c64_keyboard_as_input

(scroll down to the bottom)

he has developed the C64 Keyboard connection to Core.

At time i build up another project yet: "K64". It's finished to 95%. It can be used to controll a Speakjet (together with K-II) but also works as MIDI Controller with the external MIDI-OUT Port. The "K64" isn't a Sequenzer! but it's more a controller.

There are two boards in it:

1.Core for C64 scan matrix (code from bill) and application code for midicontroller and midi keyboard functions, for TextToSpeech or Synthoptions etc...

2.Core for K-II

Yes i want to add a Recording function for SEQV3, but at time the Remote support of SEQV3, registered every incoming "remotekey" as recorded note.. so it's at time not possible, to activate Record Mode and step through Tracks of SEQV3.

I'm waiting til TK have time to check the current source code of SEQV3. so that remotekeys will not recorded. Another little problem is that every remotekey will be routed through other device - that should be deactivated too..

That are some little things they need to changed before i can try add this..

I've to document the project if i'm finished..

I hope i get it everything under $7FFF ;)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

But you can just re-use the button matrix code which is located in seq_button.inc (search for SEQ_BUTTON_GetRowIRQ and SEQ_BUTTON_SRM_Handler)

From the SRM_Handler, you can easily branch to the SEQ_BUTTON_Handler in order to trigger functions which are listed in SEQ_IO_TABLE_DIN (I think if you know assembler, this information should be enough)

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

Link to comment
Share on other sites

Yes, it's actually the row index. The name seems to be an artefact from another code. However, it's important that the counter variable is located at a different address than SEQ_BLM_ROW_CTR, since ROW_CTR is incremented from an interrupt routine, and COL_CTR (which should mabye be renamed to ROW_CTR2) is incremented from the main thread (conflicts have to be avoided)

Best Regards, Thorsten.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Tables can be added anywhere. You don't need to specify a specific start address. Only exception are tables in setup_*.asm, but I guess that there is not enough free memory anymore between 3080 and 3300

Just include the file which contains the table at the end of main.inc, before "seq_presets.inc" is included

2: yes, it's a mistake in the .pdf file

Best Regards, Thorsten.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 5 weeks later...

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

scanmatrix_thumb.GIF

c64keyb.zip

scanmatrix.GIF

c64keyb.zip

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

scanmatrix_thumb.GIF

bottom-new.zip

mbseq_c64k.diff.txt

scanmatrix.GIF

bottom-new.zip

Link to comment
Share on other sites

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

Link to comment
Share on other sites

SEQ_BLM_ROW_CTR has already been incremented in SEQ_LED_UpdateIRQ, SEQ_BUTTON_GetRowIRQ uses the same counter.

It's dirty code - I wanted to save one variable and never assumed that somebody really wants to work with these low-level functions...

Best Regards, Thorsten.

Link to comment
Share on other sites

The problem of the "last column" was lying just around there, but I managed to solve it right now. I'd only need to add a "andlw 0x07"  :o :)

Here's the updated mod attached, in diff format as always.

This time there's no patch for setup_mbseq_v3.asm -- there are too many custom settings, so I better explain here the important things to do:

  • Set these #define's to 0, or delete:
    DEFAULT_GP_DIN_SR_L
    DEFAULT_GP_DIN_SR_R

  • Set these #define's to 1:
    DEFAULT_SRM_ENABLED
    DEFAULT_SRM_BUTTONS_ENABLED

  • Add this #define:
    #define DEFAULT_SRM_8X8_ENABLED    1

  • Edit these #define's to suit your hardware config:
    DEFAULT_SRM_DOUT_CATHODES1  (to the keyboard columns DOUT)
    DEFAULT_SRM_DIN_L  (to the keyboard rows DIN)

  • Edit all the DIN entries to suit the keyboard mapping. Sorry for not giving this table, but I had to move some wires on my keyboard so the corresponding numbers aren't the same. You can obtain them by running the c64-keyboard-test app by jambonbill, pressing each key and writing down the row/col values. Put row+2 in the first field (SR#), and col in the second one (Pin).

  • Add to the DIN list the entries for the GP buttons:
    	DIN_ENTRY	SEQ_BUTTON_GP1,		 m,	 n
    ...
    	DIN_ENTRY	SEQ_BUTTON_GP16,	 m,	 n
    
    



    • Now I want to summarize all this work in my CV :D

      Best regards,
      Enrico
    mbseq_c64k.diff.txt
    mbseq_c64k.diff.txt
Link to comment
Share on other sites

is your project a total replacement for the control surface of the sequencer including all the features of the seq v3.2 with only a c64 keyboard, 2 displays and some LEDs ?

In fact, yes. All what you said plus the 16 encoders. And some buttons are still available for future functions!

Soon I'll post some pictures of the thing.

Best regards, Enrico

Link to comment
Share on other sites

@ris8_allo_zen0: great ;)

is your project a total replacement for the control surface of the sequencer including all the features of the seq v3.2 with only a c64 keyboard, 2 displays and some LEDs ?

yes, ris8_allo_zen0 converts SEQV3 to a C64keyboard SEQ... i'm tight how it works :)

beside of that for those which are fans of C64 Keyboards and those which have built up a MBSEQV3 yet, my K64 application controls MBSEQV3's record and utility functions from outside via midi remote. That is another way to controll SEQ...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...