Keyboard for PS1 RPG Maker!

Lantis · **Posted:** May 19th, 2010, 4:13 pm

That's some fancy looking stuff there, yo. How long did that take you? I really liked the RSS feed button, lol. Looking forward to new updates.

Thutmose · **Posted:** May 19th, 2010, 4:16 pm

Lantis wrote:

That's some fancy looking stuff there, yo. How long did that take you? I really liked the RSS feed button, lol. Looking forward to new updates.

heh Took about 5 minutes. I just downloaded/installed a new WordPress template.

I was going to code my own site from scratch, but gave up. I don't have the time for that right now. >_<

But I like this new design a heck of a lot better than the old one.

Thutmose · **Posted:** May 20th, 2010, 6:11 pm

Hack a Day (the greatest hardware hacking blog there is, imo) has featured Kupid!

http://hackaday.com/2010/05/20/keyboard-input-for-playstation/

Lantis · **Posted:** May 20th, 2010, 6:24 pm

It's well deserved. Actually, it should be featured all over the place.

Thutmose · **Posted:** May 20th, 2010, 6:28 pm

Lantis wrote:

It's well deserved. Actually, it should be featured all over the place.

Thanks.

At least one other blog has picked up on the story. I've gotten over 400 hits on my site since the HaD article went up this morning.

I'm really excited.

insultobot · **Posted:** May 20th, 2010, 7:22 pm

Thutmose wrote:

Hack a Day (the greatest hardware hacking blog there is, imo) has featured Kupid!

http://hackaday.com/2010/05/20/keybo...r-playstation/

http://hackaday.com/2010/05/20/keyboard-input-for-playstation/
There's the proper link. The forums shortened it for you.

Big congrats on that!

Thutmose · **Posted:** May 20th, 2010, 7:35 pm

insultobot wrote:

http://hackaday.com/2010/05/20/keyboard-input-for-playstation/
There's the proper link. The forums shortened it for you.

Big congrats on that!

Ah. Didn't notice that. >_< I updated my post, thanks.

And thanks for the congrats. ^_^

Staffy · **Posted:** July 2nd, 2010, 3:45 am

here's a question: If it is no longer running a PICAXE chip, then wouldn't still calling it KUPID be a misnomer?

Thutmose · **Posted:** July 2nd, 2010, 7:57 am

Staffy wrote:

here's a question: If it is no longer running a PICAXE chip, then wouldn't still calling it KUPID be a misnomer?

lol

I had already thought about that - and came up with a solution.

Kupid 2.0's new name is......

KµPID

i.e. RPG Maker Keyboard with Micro-Controllers Inside Device

But please don't ask me when it's going to be done. >_<

Thutmose · **Posted:** July 5th, 2010, 7:47 pm

So... It's been a while since I last gave an update on Kupid 2.0. So here it is -

I haven't had a chance to do any more tangible work on 2.0 since my last update (but lots of thinking, planning, reading).

And, as you see in the above post, I have since decided to change the name of Kupid 2.0 to just "KµPid" (since 2.0 probably won't actually be using a PICAXE chip inside). And "µP" is the abbreviation for "microcontroller", which fits quite well. I know, I'm sure you're all dancing a jig about the new name....

Below is what needs to be done to complete KµPid:

Program a PS2 keyboard driver for the Atmel AVR
Program the keystroke conversion algorithm in AVR Assembler
Integrate the keyboard driver and the conversion algorithm with the PS protocol emulation code I have previously written
- Set up interrupt on keystroke
- Use SRAM as character buffer
  - Y register as SRAM buffer pointer
  - ~100 Character buffer capacity

Programming the keyboard driver will be the single most time consuming part. I've never seen a PS/2 keyboard driver for Atmel chips written in assembly before. Though, I don't imagine that it will be any more difficult than writing the driver for the Playstation console interface I've already written.

As for the conversion algorithm - I already know what the algorithm is, it's just a matter of rewriting it in assembly.

Integrating everything will require having one AVR chip act as the interface between KµPid and the PS, and a second AVR chip acting as the interface between the keyboard and KµPid.

The two µPs will communicate, with the PS-KµPid interface chip acting as the master. When the PS-Kµ chip is ready for the next keystroke, it will send a request to the Kµ-Kb chip for the next keystroke (which will be stored in the Kµ-Kb chip's SRAM as a raw keyboard scan-code value, then converted upon request to four bytes, representing the number of d-pad presses that need to be made in each direction, or the button press that needs to be made).

An alternative to programming a second AVR chip as the keyboard interface would be to use a PICAXE chip. Since PICAXE chips have a PS2 keyboard interface built in, and I already have the conversion algorithm programmed for PICAXE, I think that it would really speed up development of KµPid. Actually, I think that's what I am going to do. Or at least try it out and see if I can get it to work before I start trying to write a keyboard driver in assembly.

Using an AVR as the PS interface and a PICAXE chip as the keyboard interface, rather than two AVRs, would make it a lot easier for me to get this done as quickly as possible, since I already have the PICAXE-keyboard interface design & programmed from Kupid 1.0. Further, it would still function in pretty much the same way as I described above - the only difference would be that it'd take less time to develop and add a little to the cost of the final unit.

I still don't have an ETA, though. It will be finished as soon as I can manage.

Lantis · **Posted:** July 5th, 2010, 9:06 pm

I'd personally say to go ahead and using AVR and PICAXE as the interface specially if it alleviates some of the time constraints... specially with your current schedule.

Thutmose · **Posted:** January 4th, 2011, 8:05 am

So I decided to take a look at the source code for Kupid 2.0, being as I haven't looked at it in five or so months. I've got a lot of re-learning to do before I can continue.

Actually, I'm thinking now that if I start working on 2.0 again, I'm going to reevaluate my design. Assembly is terribly unforgiving, and I don't really have too much time to spend dealing with it. Maybe I'll try out C... I do have a shiny new chip programmer I never got around to using...

The latest version of the source code is copy/pasted below. I wasn't going to release it until I was totally done, but what the heck. The comments aren't 100% accurate - it was a work in progress after all.

If anyone wants to know how to program an Atmel AVR microcontroller to emulate a PS1/2 controller in assembly language, then jackpot.

Code:

.NOLIST ; Don't list the following in the list file
.INCLUDE "tn2313def.inc" ; Import of the file
.LIST ; Switch list on again

.CSEG
.ORG $0000

init:
   ; Init stack
   LDI r16, LOW(RAMEND) ; Lower byte
   OUT SPL, r16 ; to stack pointer
   ;Init USI Control Register 
   LDI r16, (1<<USIWM0) | (1<<USICS1) ;| (1<<USICS0) ;put the initialization data into register 16
   OUT USICR, r16 ;take the data out of register 16 and initialize the USI Control Register 
   ;Init Port B
    LDI r16,(0<<DDB7)|(1<<DDB6)|(0<<DDB5) | (1<<DDB4) | (0<<DDB3) ;direction of Port B
    OUT DDRB, r16
   LDI r17, 0b00000000 ;init register17 which is the BYTE counter
   LDI r18, (1<<PB4) ;store acnkowledge signal in register 18
   LDI r19, 0b00000001
   OUT PORTB, r18 ;set ack signal high

SlaveSPITransferOut:
   RJMP SlaveSPITransferIn
   SendByteTest1:
      LDI r16, 0b10011001 ;clear register 16 for sending the first blank byte
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendByteTest2:
      LDI r16, 0b10000001 ;clear register 16 for sending the first blank byte
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendCapturedByte:
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendByte1:
      LDI r16, 0b00000000 ;clear register 16 for sending the first blank byte
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendByte2:
      LDI r16, 0b10000010 ;put byte x41 into register 16
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendByte3:
      LDI r16, 0b01011010 ;put byte x5A into register 16
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      LDI r17, 0b00000001 ;add 1 to r17, this is the BYTE counter
      RJMP OverflowReset
   SendByte4:
      COM r19
      SBRS r19, 1
      LDI r16, 0b00000001 ;put button byte 1 byte into register 16 - SLCT NULL NULL STRT U R D L
      SBRC r19, 1
      LDI r16, 0b00000000 ;put button byte 1  byte into register 16
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   SendByte5:
      SBRS r19, 1
      LDI r16, 0b00000000 ;put button byte 1 byte into register 16 - L2 R2 L1 L2 /\ O X |_|
      SBRC r19, 1
      LDI r16, 0b00000000 ;put button byte 1  byte into register 16
      OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
      RJMP OverflowReset
   OverflowReset:
      ;reset the Counter Overflow Interrupt Flag 
      LDI r16, (1<<USIOIF) ;copy the Counter Overflow Interrupt Flag to register 16 
      OUT USISR, r16 ;copy the bit stored in register 16, bit 6 of USISR, which should be set
                  ;to 1, to bit 6 of USISR which will reset the Counter Overflow Interrupt Flag to 0
      LDI r16, 0b00000000 ;copy the Counter Overflow Interrupt Flag to register 16
      INC r17 
      RCALL DelayLong
      RCALL Acknowledge ;send acknowledge signal

SlaveSPITransferIn:
   SBIC PORTB, 3 ;skip next instruction if the ATTN line is LOW
   RCALL ResetSPI
   SBIS USISR, USIOIF ;skip next instruction if the Counter Overflow Interrupt Flag in the USI Status Register is set to 1, as that mean that the entire byte has been recieved from the PlayStation
   RJMP SlaveSPITransferIn ;go to the beginning of the transfer loop
   CPI r17, 0b00000010 ;compare r17 (byte counter) to 3, if equal, then zero-flag in status register is set to one.
   BREQ SendByte4
   CPI r17, 0b00000011 ;compare r17 (byte counter) to 4, if equal, then zero-flag in status register is set to one.
   BREQ SendByte5
   IN r16, USIDR ;copy the contents of the USI Data Register to register 16
   CPI r16, 0b00000000 ;compare r16 (which has the data from the SPI data register) to the first expected byte from the Playstation, if equal, then zero-flag in status register is set to one.
   BREQ SendByte1
   CPI r16, 0b10000000 ;compare r16 (which has the data from the SPI data register) to the second expected byte from the Playstation, if equal, then zero-flag in status register is set to one.
   BREQ SendByte2
   CPI r16, 0b01000010 ;compare r16 (which has the data from the SPI data register) to the third expected byte from the Playstation, then zero-flag in status register is set to one.
   BREQ SendByte3
   RJMP SlaveSPITransferOut

;define subroutines

ResetSPI:
   LDI r16, (1<<USIOIF) | (0<<USICNT3) | (0<<USICNT2) |(0<<USICNT1) | (0<<USICNT0) ;copy the Counter Overflow Interrupt Flag to register 16 
   OUT USISR, r16 ;copy the bit stored in register 16, bit 6 of USISR, which should be set, and reset the counter
               ;to 1, to bit 6 of USISR which will reset the Counter Overflow Interrupt Flag to 0
   LDI r16, 0b00000000
   OUT USIDR, r16 ;copy register 16 to the USI Data Register to send a reply
   LDI r17, 0b00000000 ;reset byte counter
   RET

DelayShort: ;do a short delay
   NOP
   INC r18 ;add 1 to r18
   CPI r18, 0b00001000 ;compare r18 to a number, if equal, then zero-flag in status register is set to one.
   BRNE DelayShort
   LDI r18, 0b00000000
   RET ; return to the caller

DelayLong: ;do a long delay
   NOP
   INC r18 ;add 1 to r18
   CPI r18, 0b00010100 ;compare r18 to a number, if equal, then zero-flag in status register is set to one.
   BRNE DelayLong
   LDI r18, 0b00000000
   RET ; return to the caller

Acknowledge:   ;ACKnowledge on PORT B pin 4
   LDI r18, (0<<PB4) ;store acnkowledge signal in register 18
   OUT PORTB, r18 ;start acknowledge signal
   RCALL DelayShort
   LDI r18, (1<<PB4) ;store acnkowledge signal in register 18
   OUT PORTB, r18 ;end acknowledge signal
   RET ;return to the caller

I had the basic code programmed in a day or two, but spent a week trying to figure out why it wasn't working at all. It turned out that whenever I went to test the code, I rested my hand on a metal portion of the breadboard I was using - the grounding in my house is so bad, that it caused some kind of feedback. Once I stood about a foot away from it, the code worked perfectly. >_<

So... yeah... Anybody has any questions, you're welcome to ask. I'm sure everyone is dying to know what all the different registers do.

The RPGT4 video series will probably get worked on first, before Kupid, fyi.

	It is currently February 18th, 2025, 3:26 am
View unanswered posts \| View active topics

Keyboard for PS1 RPG Maker!

Who is online