SEQ with C64 keyboard

ris8_allo_zen0 · June 22, 2007, 10:33am

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

ris8_allo_zen0 · June 22, 2007, 2:36pm

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:

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;
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;

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.

stryd_one · June 22, 2007, 8:55pm

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

ris8_allo_zen0 · June 22, 2007, 10:04pm

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

T.K · June 22, 2007, 10:27pm

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.

ris8_allo_zen0 · June 24, 2007, 8:15am

Thank you a lot TK!

Rio · July 3, 2007, 9:21am

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

ris8_allo_zen0 · July 3, 2007, 1:14pm

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

Rio · July 3, 2007, 1:39pm

Hello,

if i understand it right: TK will take a look about SEQ Remotefunctions too in future, if he have time…

Greets Rio.

ris8_allo_zen0 · July 5, 2007, 6:38pm

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

T.K · July 6, 2007, 6:46pm

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.

ris8_allo_zen0 · July 7, 2007, 1:23pm

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

T.K · July 7, 2007, 9:29pm

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.

ris8_allo_zen0 · July 8, 2007, 11:43am

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

ris8_allo_zen0 · August 8, 2007, 12:05am

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](< base_url >/applications/core/interface/file/attachment.php?id=323)

[c64keyb.zip](< base_url >/applications/core/interface/file/attachment.php?id=3464)

ris8_allo_zen0 · August 9, 2007, 5:36pm

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

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

ris8_allo_zen0 · August 12, 2007, 7:16pm

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](< base_url >/applications/core/interface/file/attachment.php?id=327)

[bottom-new.zip](< base_url >/applications/core/interface/file/attachment.php?id=329)

[mbseq_c64k.diff.txt](< base_url >/applications/core/interface/file/attachment.php?id=3468)

[bottom-new.zip](< base_url >/applications/core/interface/file/attachment.php?id=3470)

stryd_one · August 13, 2007, 6:53am

Just to know: how many people are currently interested in this mod?

I am very interested… I don’t think I’ll make it myself (BLM for me), but it’s great to watch nonetheless

ris8_allo_zen0 · August 16, 2007, 7:24pm

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

T.K · August 16, 2007, 9:54pm

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.