summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHombreLaser <buran@silosneeded.com>2025-04-04 22:57:36 -0600
committerHombreLaser <buran@silosneeded.com>2025-04-04 22:57:36 -0600
commitb83696f7361018991b7580a52cf31ea4059392de (patch)
treeddb590c6bb9d334679bbce13a51ee016e0a99059
parent69dda5c37e039b4df556bda6e26ffd2e430fd795 (diff)
Improve writing of picoshock devlog #1
-rw-r--r--_posts/en/2025-04-04-picoshock_devlog_1.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/_posts/en/2025-04-04-picoshock_devlog_1.md b/_posts/en/2025-04-04-picoshock_devlog_1.md
index 967d75d..20c05c2 100644
--- a/_posts/en/2025-04-04-picoshock_devlog_1.md
+++ b/_posts/en/2025-04-04-picoshock_devlog_1.md
@@ -89,10 +89,10 @@ This is inefficient and hard, but, in the world of the PS2, has been done: Sukko
[PSX Newlib](https://github.com/SukkoPera/PsxNewLib?ref=silosneeded.com) and Bill Porter's
[arduino library](https://github.com/madsci1016/Arduino-PS2X?ref=silosneeded.com) come to mind.
-If we read the source code of this projects, we can see the use of `sleep` directives and the like, to try and time every read
+If we read the source code of these projects, we can see the use of `sleep` directives and the like, to try and time every read
and write.
-PIO allows us to not do that. Instead, it provides us a hardware specialized for input and output, consisting of state machines,
+PIO allows us to not do that. Instead, it provides us a piece of hardware specialized for input and output, consisting of state machines,
two FIFOs for reading and writing data and several shift registers to, well, shift data around. We program this
hardware under a pretty basic, but powerful, assembly language.
@@ -130,7 +130,7 @@ whatever is in the ISR to my TX (read) FIFO, for it to be consumed by the pico's
Here it is, my masterpiece. Pretty basic, right? But I think it was a pretty good exercise in getting to know the PIO feature
and actually using it (later we'll see the Cmake file, to show you how you can build your project taking a PIO program in mind).
-Everything below the c-sdk is code that will be injected to the header file the assembler will generate with this file.
+Everything below the c-sdk is code that will be injected to the header file the assembler will generate when assembling this program.
In it, we configure our PIO state machine: the pin we'll use as the command pin (I.E., the one we'll be reading),
the direction we'll shift bits on (in this case, the playstation 2 speaks a Least significant bit protocol, in layman terms,
we'll read what it has to say from left to right) and its clock frequency: 125/250 = 0.5 MHz, or, 500 KHz. I think. I broke
@@ -171,14 +171,14 @@ Well, the PS2 is speaking to us in chinese:
![Minicom screenshot](/assets/images/2025/minicom.jpg)
None of this means anything per the Curious Inventor guide, and, it's expected. I was hoping to at least get a 0x00 byte, which
-it seems to be the first byte the console sends in every packet. But no.
+seems to be the first byte the console sends in every packet. But no.
It's expected because the PS2 speaks in a (albeit heavily modified) duplex SPI protocol: we receive and read data at the same
time, regulated by a clock pulse, and also using a chip select (attention, in DualShock terms) and acknowledge signals.
# What comes after
-For now, I want to receive actual, useful data. I hope I can achieve this by only implementing the clock signal, but of course,
+For now, I want to receive actual, useful data. I hope I can achieve this by only implementing the clock signal for now, but of course,
I'll have to implement the other ones (data, attention and acknowledge) sooner or later.
The pico-examples repository provides a really relevant example: an