Add pico shock devlog #2

2 files changed, 240 insertions, 0 deletions

diff --git a/_posts/en/2025-04-12-picoshock_devlog_2.md b/_posts/en/2025-04-12-picoshock_devlog_2.md
new file mode 100644
index 0000000..0a35c91
--- /dev/null
+++ b/_posts/en/2025-04-12-picoshock_devlog_2.md
@@ -0,0 +1,240 @@
+---
+layout: post
+title: "PicoShock Devlog #2"
+lang: en
+date: 2025-04-12
+tags: ["Programming", "PicoShock"]
+---
+
+These last couple of weeks I've kept my work on picoshock somewhat consistent, and I've also learnt a lot, really.
+
+For starters, my first log entry was filled to the brim with mistakes, some pretty dumb ones, too:
+
+- I didn't even start the PIO program.
+- I used `pio_sm_get` instead of `pio_sm_get_blocking`: the difference between the two is that the second
+  one waits for the RX FIFO to actually have some data to read. The first one, when the FIFO is empty, 
+  has undefined behavior. That explains the readings I was getting: the program didn't even start and as such,
+  the FIFO wasn't getting filled.
+- The folks at the [raspberry pi forum](https://forums.raspberrypi.com/viewtopic.php?p=2309324) explained to me
+  the nuances of clock frequencies in PIO programs: although it can be the case that I want a precise clock frequency
+  matching that of the device I wish to interface (I'll have to do this when implementing the console mode), it sometimes is 
+  not, and it's better to actually set the frequency higher.
+  
+So the days I've been working on pico shock I've had a single goal: receive coherent data, as per the dualshock protocol.
+I've implemented the clock and acknowledge signals, too. So now, my PIO program looks like this:
+
+```asm
+.program dualshock
+.side_set 1
+
+wait 0 pin 2 side 1          ;; Wait for clock to go low, pull ACK high.
+.wrap_target
+wait_for_att:
+  set x, 8 side 1            ;; Set bit counter: we want to read a byte.
+  wait 0 pin 1 side 1        ;; Wait for ATT. PS2 wants to tell us something.
+
+read_loop:
+  wait 0 pin 2 side 1        ;; When clock drops from low to high,
+  wait 1 pin 2 side 1        ;; read the values.
+  in pins, 1 side 1          ;; Read the bit sent by the PS2.
+  jmp x-- read_loop side 1   ;; Decrement bit counter.
+
+acknowledge:
+  push [15] side 1           ;; We've read a byte, wait for 12us before pulling ACK low.
+  nop [14] side 1
+  nop side 0 [5]             ;; Pull ACK low.
+.wrap
+
+% c-sdk {
+  void dualshock_program_init(PIO pio, uint sm, uint offset, uint command_pin, uint data_pin, uint ack_pin) {
+       pio_sm_config cfg = dualshock_program_get_default_config(offset);
+       
+       sm_config_set_in_pins(&cfg, command_pin);
+       pio_sm_set_consecutive_pindirs(pio, sm, ack_pin, 1, false);
+       sm_config_set_out_pins(&cfg, data_pin, 1);
+       sm_config_set_sideset_pins(&cfg, ack_pin);
+       sm_config_set_in_shift(&cfg, true, false, 8);
+       sm_config_set_clkdiv_int_frac(&cfg, 50, 0);
+       pio_gpio_init(pio, ack_pin);
+       pio_sm_init(pio, sm, offset, &cfg);
+  }
+%}
+```
+
+It has grown quite a bit.
+
+As per my understanding, `sm_config_set_in_pins(&cfg, command_pin)` sets both the pin and its 5 consecutive ones as input pins.
+The pin you pass as an argument is called the base pin. As such, following the command pin I wired the clock and after that, 
+the attention pins. I could be wrong here, too, but, for example, to wait on a pin other than the command, you refer to
+your pin with its bitmask. For example, `0b00000` is a 5 bit number. The first refers to the base, the second to the next one,
+etc. But, I have my doubts on this: in wait instructions, for example, if you write `wait 0 pin 0` you're waiting for your
+base pin to pull low... I think.
+
+As the pin following the command one is the ATT pin, that's my pin 1, and clock is my pin 2. So, I hope that:
+
+```asm
+wait 0 pin 2
+```
+
+Means that I'm waiting for my clock to pull low.
+
+I've implemented ACK as a side set pin: it's normally set high, but after reading a byte, I must wait 12us and then pull it low
+for (half, I'm still not sure how I will do that, meanwhile I'll try for a full PS2 clock cycle) a clock cycle.
+
+I'm also reading a single bit with every `in` instruction, as the playstation 2 pulls the clock low and then high and after that,
+sends a bit.
+
+# Frequencies
+
+If you've read my thread in the forum you probably know by now what I mean by me using the clock divider feature wrong. It wasn't
+actually because I wasn't setting the frequency I intended to (500 KHz) but because in reality I want to set it higher. So:
+`sm_config_set_clkdiv_int_frac(&cfg, 250, 0)` became `sm_config_set_clkdiv_int_frac(&cfg, 50, 0)`. I'm now setting the PIO frequency
+as, hopefully, 2.5 MHz. This means that `nop side 0`, the instruction that pulls ACK low, is wrong. As 2.5 MHz is 5 times faster
+than 500 KHz, so, this instruction should be `nop side 0 [5]` instead. 5 cycles for us is a cycle for the PS2.
+
+# What has changed?
+
+Well, now it seems I'm actually getting something out of the PS2, kind of. The printf sentence of my C program prints 
+the number 800000 endlessly, which is off by 23 bits to the right (oh, yes, I want the ISR FIFO to shift to the right,
+I thought that LSB protocols shifted it to the left. Another one of the countless silly mistakes of my first post).
+The number I'm actually looking for is 1. Or 0x01 in hex notation.
+
+# What comes next
+
+Well, now that I've set up the state machine's frequency right, and receiving something that looks like relevant data, I
+now have to prove my hypothesis: should I shift everything I receive from the PS2 23 bits to the right to make sense of it?
+For this, I'll implement the data (out) pin, send something, and see if the number the PS2 sends me as a response is different 
+from 800000. If it is, I'll shift that 23 bits to the right and see if it coincides with the protocol.
+
+Until next time! This is the hard part: after this, it probably won't be a walk in the park but I'm pretty certain the C portion of
+the library won't be that hard to write.
+
+# Another update
+
+Well, I was planning to post this on saturday, but I forgot, and when I had some free time to keep working on this, well, let's say
+I've made some progress.
+
+## Updates to dualshock.pio
+
+First, another fix to my pio program:
+
+```asm
+;; Before
+wait_for_att:
+  set x, 8 side 1            ;; Set bit counter: we want to read a byte.
+  
+;; After
+  wait_for_att:
+  set x, 7 side 1
+```
+
+It seems that me making stupid mistakes is a constant on this, oh well. Don't be too harsh on me.
+
+I also implemented the data bus in pio:
+
+```asm
+.program dualshock_data
+	
+.wrap_target
+wait_for_output: 
+	jmp !osre wait_for_att   ;; Stall while we don't have data to output
+	jmp wait_for_output
+	
+wait_for_att:
+	set x, 7                 ;; Set bit counter: we want to send a byte.
+	wait 0 pin 0             ;; Wait for ATT.
+
+out_loop:
+	wait 0 pin 1             ;; When clock drops from low to high,
+	wait 1 pin 1             ;; send our data.
+	out pins, 1              ;; Read the bit sent by the PS2.
+	jmp x-- out_loop         ;; Decrement bit counter.
+.wrap
+
+% c-sdk {
+  void dualshock_data_program_init(PIO pio, uint sm, uint offset, uint data_pin,
+                                   uint att_pin) {
+    pio_sm_config cfg = dualshock_data_program_get_default_config(offset);
+
+    sm_config_set_in_pins(&cfg, att_pin);
+    sm_config_set_out_pins(&cfg, data_pin, 1);
+    sm_config_set_out_shift(&cfg, true, true, 8);
+    sm_config_set_clkdiv_int_frac(&cfg, 50, 0);
+    pio_sm_init(pio, sm, offset, &cfg);
+  }
+%}
+```
+
+Yes, a shameful copy paste of what I already had for the command pin, but ignoring acknowledge and using out instead of in.
+
+## Updates to the main loop
+
+Well, now I have access to a data bus, now I'm actually reading a byte, let's see what we get:
+
+```bash
+# Trust me, this is what minicom was printing, but I didn't take a screenshot, 
+# and I'm still not using version control so I don't want to revert anything I have.
+# We'll see what's new on the C program shortly.
+1000000
+1000000
+1000000
+# etc...
+```
+
+Well, that's an interesting number. More interesting than 800000, that's for sure.
+
+Let's write this number in binary:
+`0000 0001 0000 0000 0000 0000 0000 0000`
+
+Huh. Interesting... We're waiting a 1, this is by no means a one... but, if we shift it 24 bits to the
+right... it is. So I told myself, well, I'm getting a 1, sort of. If I send data to the PS2 and if when
+shifting its responses 24 bits to the right we get the numbers we're expecting... that would 
+mean I'm now getting the right numbers from the PS2, So that's what we're going to do:
+
+```c
+int main() {
+// PIO configuration, etc. You know the drill.
+
+  // We don't want to read weird values on the first loop.
+  uint32_t data = 0xff;
+
+  while (true) {
+    //sleep_ms(1000);
+
+    if ((data >> 24) == 0x01)
+	  pio_sm_put_blocking(data_pio, data_sm, 0xff);
+
+    if ((data >> 24) == 0x42)
+      pio_sm_put_blocking(data_pio, data_sm, 0x41);
+
+    if ((data >> 24) == 0x00)
+      pio_sm_put_blocking(data_pio, data_sm, 0x5a);
+    
+    data = pio_sm_get_blocking(pio, sm);
+ 
+    printf("%x\n", data);
+  }
+}
+```
+
+This is a rather crude pattern matching, I know. I got rid of the sleep directive to print more precise numbers to the
+console. Yes, they're going to be printed really fast in succession, but they would be a more accurate representation of this
+loop. And it's nothing that scrolling the terminal up can't fix.
+
+![Minicom screenshot](/assets/images/2025/minicom_2.png)
+
+Well... those numbers seem pretty familiar. According to the [Curious Inventor guide](https://store.curiousinventor.com/guides/PS2),
+this back and forth communication with the PS2 should look like this:
+
+|Byte # |   1|   2|   3|   4|   5|
+|-------|----|----|----|----|----|
+|Command|0x01|0x42|0x00|0x00|0x00|
+|-------|----|----|----|----|----|
+|Data   |0xff|0x41|0x5a|0xff|0xff|
+
+Well, minus the last 2 data bytes which we're not sending (we're matching 0x00 with 0x5a) all of the command bytes are exactly these,
+when shifted 24 bits to the right, of course. This means that everything I read from the RX FIFO must be shifted 24 bits to the
+right, no biggie.
+
+Well, I'm pretty stoked. And this means that now comes the boring part: parsing all those bytes and sending appropriate responses.
+So exciting.
diff --git a/assets/images/2025/minicom_2.png b/assets/images/2025/minicom_2.png
new file mode 100644
index 0000000..9d59b4e
--- /dev/null
+++ b/assets/images/2025/minicom_2.png