Worklog PS2V

[Legend]

Little Update

I've been largely working on my custom screen driver board stuff but I'm still keeping aspects of the PS2V in mind, as well as just some PS2 portable stuff in general.

I mentioned above about creating a PMS using an ESP32 to be able to adjust parameters via a web app of some sort, however ive been recently doing some research because I badly want something for the community similar to what we have with the wii and RVLoader (being able to access and adjust parameters via an app directly on the console).

When doing research into what software i wanted to use with the PS2V, I eventually landed on wanting to use XEB+ because of the customizable nature of it. We could essentially dress it up to be a full portable PS2 software with a nice XMB style interface as its all essentially lua code aside from the actual PS2 related stuff. The only caveat with using XEB+ is the fact that it runs best from a USB, and we all know that adding USB to a portable is less desired than being able to load something from a memory card. XEB+ and whats available (the Christmas preview) has been in beta for years now, however ive been following the project, and the creators say they want to have a more full release bu the end if this year! I also noticed that they had posted a video showing it running off of a SD2PSX like device, which means eventually we won't need USB at all.

With all of this being said, I started doing some research into specific hardware aspects of the PS2 and even went as far as taking a look into the PS2SDK to see what hardware interfaces I could exploit to he able to connect to a PMS, and create an app that we can adjust things with.

Amongst all the hardware peripherals I looked into, the best option I can see is making a custom IOP driver for controller port 2 (as its largely unused in portables) and connecting the PMS via SPI to the port to be able to adjust things, or poll for data such as battery life etc. I doubt I'd be able to display things on screen in game but thats what the custom RTD software will eventually achieve anyway ( like on screen notifications).

With all of this being said, this means the PMS MCU can remain as a I2C master, controlling all of its own peripherals like the battery fuel gauge, and connecting to the RTD etc. But also act as a SPI slave for the PS2 to be able to poll for data and adjust things.

This is just an idea at this point and it will be a long while before any of it can even begin to be achieved, but its the best solution I can think of to get something thats as fully integrated as we can have it be.

Thanks for reading!

 

[Legend]

Good day folks!

As mentioned above in my last post, I've been sort of diving more into the idea of having PMS integration for the PS2 via XEB+ and I've have somewhat of a proof of concept!

This is the regular XEB+ running on PCSX2, and i was able to add a dynamic battery indicator icon as well as a charge icon separately.

The battery icon is technically functional (meaning it will change to whatever the battery life is) and the charge icon is set to appear when the system is charging of course! This is currently a super rough looking proof of concept due to how things are drawn with the Lua code (hence the clunky battery), so instead i plan to make some more elegant battery icons, then call on the .png of said battery icon depending on the life of the battery. It will most likely be something like: 100%, 75%, 50%, 25%, and 10% to indicate that charging is needed, as well as a new charging icon. The percentage will still move dynamically based on battery life.

I found a better and easier way (hopefully) to connect a PMS to the PS2 so I'm going to have to make a backend .elf to handle all of that, then make a front end plug-in to be able to adjust settings etc. The end result will hopefully be full integration into the PS2, similar to what we have with RVLoader with the only caveat being that in-game on-screen "overlay" notifications will probably not be a thing (or will be super hard to figure out). As mentioned in my last post however, those could always just be handled via the custom RTD2660 firmware.

Once I have the backend figured out, I plan to test on real hardware with a dummy MCU to make sure everything works!

The ultimate plan is to use XEB+ as a shell and make a whole new front end specifically for PS2 portables as i think its the cleanest option we have imo.

As a side note: I'm seriously impressed with what myself and the community has achieved and will achieve with portablization in general, but also the PS2 specific stuff as well such as @goppend with kunai and many more. I think with all of the developments happening, we will have the PS2 be just as fully software integrated as the wii, and for that I'm super grateful.

These processes have been long and hard however its a "slowly but surely" type of situation at this point, so I'll do what I can when I have time to give the community some real goodies!

Thanks for reading!

 

[jose_Leo12]

Wow, that's incredible! After I finished Ashida, I talked to the team about the possibility of integrating an icon like Ashida's, but for the PS2. Amazing! You guys are awesome! Looking forward to hearing more...

 

[Legend]

Hello folks! Time for an update!

I figured I might as well let you guys know exactly where im at and what the good news is. (Sorry in advance for this not being a picture heavy update lol). I'm in way over my head on this one but that hasnt stopped me before from getting some cool stuff made lol.

I've spent a fair bit of time researching a good way to connect a PMS to a PS2, and the initial idea was to potentially connect to the PlayStation via controller port 2 because the Playstation 2 polls the controller ports for data already, so I figured it'd be great to either develop a modified IOP driver to handle the PMS commands, or develop the PMS code to kind of fit into the controller protocol and have it work that way.

I was aiming for XEB+ as mentioned because its a pretty clean option imo, but i cant stress enough that I wanted to have this whole thing baked into the runtime as opposed to having a separate .elf application, as i wouldn't be able to poll and display data via the dashboard. This has proven harder than it seems.

Upon looking at some other methods of connection, I decided to scrap the idea of controller port 2 as it would require more wires than im comfortable with connecting cleanly to the PMS. With that being said, I eventually landed on UART for communication.

UART requires 2 wires connected to the PMS which is most ideal, and there are things already in place to handle debugging etc. On all of the deckard slim PS2's the PowerPC and Emotion Engine were merged, so there's actually 2 ways this can be attacked. Either through EE UART (which is more documented but it is also more involved) or the PPC UART (which is less documented, but less involved). I won't get into the specifics, but PPC UART is easier than using EE UART, with a few caveats.

Back to XEB+; XEB+ is heavily based on Enceladus which is essentially a LUA engine for PS2's. Enceladus on its own calls a specific module (ppctty.IRX) during runtime and that is essentially our gateway to using PPC UART. The unfortunate thing is that XEB+ does not call this module. On top of that, we know the address for reading data from the PS2 for debugging etc. But the RX addresses are somewhat unknown but can be figured out, so thats what im focusing on that way we can send and receive data from the PS2.

I was able to get a hold of the XEB+ Christmas preview source code thankfully, but I have some strict rules from the devs for how I use it. The good thing is that once I get this figured out and if it doesn't interfere with any of XEB+'s regular stuff, then the devs will consider adding it into the final release, which would be a HUGE step for us to have software integration!

The PS2SDK is less than desirable to work with but my next steps are creating a lot of tests, and doing some probing to see what we can send and receive reliably. I'm working away on the road however I have a setup ready to bring along with me to be able to do all of this in hopefully a timely manner.

The ultimate idea that ive been shooting for is of course full integration into XEB+ via a plugin that allows configuring PMS settings and eventually updating the PMS firmware via a bootloader. All similar to what we have with the Wii.

I'm also in the process of developing the PMS itself differently than what ive posted before, and I should have the funds to do some prototyping, but the first step is ultimately testing what I can do via UART.

Thanks for reading!

 

[Legend]

Bit of a breakthrough update:

Lately I havent had much time to work on anything but with the little time I do have, ive been trying to tackle establishing communications with the PS2.

I picked up a TTL to USB adapter and started looking into ppctty.irx as its a module for ppc debugging, however it only has code for TX handling. This meant that I could only read what was coming from the console rather than having the 2 way highway I need with RX as well.

I peaked around and my best resource at the time was an app called ppc monitor which is a full debugging app for deckard ps2's (79k included). The one thing I noticed with ppc monitor is that it uses a .elf and essentially patches the ppc ram everytime its booted in order to execute its code. This was a no go for me as we need to have everything contained to an irx module to keep things as seamless as possible. The code base did however house the RX registers needed for testing.

I hooked everything up and over the course of a few days, tested a multitude of things in hopes to get RX working in the environment I needed, all of which failed. I was doing a lot of echo tests to send a character over to see if the ps2 would echo it back to me, but it never would. On top of that, I was loading the module via XEB+ and it wouldn't stop freezing/ crashing during certain tests.

After all of this, I took a night off and did some more research, and finally revisted it last night with a fresh outlook. I took a stock ppctty module and started working on it again. I mainly ran into roadblocks with freezing again but I eventually figured out it was because of how XEB+ was loading the module so I revisited the plugin I made and was able to get it not to freeze anymore. From there I started doing small tests in steps, and eventually worked my way up to victory lol. I was able to get a stable echo test (and tried to type bitbuilt in the 1 second it was polling lol).

This means I finally have a solid working building block for the transport layer of the eventual goal of a PMS bridge! From here, I have to revisit the XEB+ plugin and find a way to keep it contained to just a plugin, and find a way to load it on boot as right now it can only be loaded after boot by navigating the menu and selecting it. Once I have all of the assets figured out like I showed in my previous posts, I'll run some tests to make sure UART comms can actively change things in real time and run a bunch of tests. Then its evolving it to work with a real MCU. Its gonna take a fair bit of work so I don't get ahead of myself but we'll get there eventually.

Thanks for reading!

 

[FatBaldDad]

Bit of a breakthrough update:

Lately I havent had much time to work on anything but with the little time I do have, ive been trying to tackle establishing communications with the PS2.

I picked up a TTL to USB adapter and started looking into ppctty.irx as its a module for ppc debugging, however it only has code for TX handling. This meant that I could only read what was coming from the console rather than having the 2 way highway I need with RX as well.

I peaked around and my best resource at the time was an app called ppc monitor which is a full debugging app for deckard ps2's (79k included). The one thing I noticed with ppc monitor is that it uses a .elf and essentially patches the ppc ram everytime its booted in order to execute its code. This was a no go for me as we need to have everything contained to an irx module to keep things as seamless as possible. The code base did however house the RX registers needed for testing.

I hooked everything up and over the course of a few days, tested a multitude of things in hopes to get RX working in the environment I needed, all of which failed. I was doing a lot of echo tests to send a character over to see if the ps2 would echo it back to me, but it never would. On top of that, I was loading the module via XEB+ and it wouldn't stop freezing/ crashing during certain tests.
View attachment 42363

After all of this, I took a night off and did some more research, and finally revisted it last night with a fresh outlook. I took a stock ppctty module and started working on it again. I mainly ran into roadblocks with freezing again but I eventually figured out it was because of how XEB+ was loading the module so I revisited the plugin I made and was able to get it not to freeze anymore. From there I started doing small tests in steps, and eventually worked my way up to victory lol. I was able to get a stable echo test (and tried to type bitbuilt in the 1 second it was polling lol).

View attachment 42364

This means I finally have a solid working building block for the transport layer of the eventual goal of a PMS bridge! From here, I have to revisit the XEB+ plugin and find a way to keep it contained to just a plugin, and find a way to load it on boot as right now it can only be loaded after boot by navigating the menu and selecting it. Once I have all of the assets figured out like I showed in my previous posts, I'll run some tests to make sure UART comms can actively change things in real time and run a bunch of tests. Then its evolving it to work with a real MCU. Its gonna take a fair bit of work so I don't get ahead of myself but we'll get there eventually.

Thanks for reading!

This is outstanding and very interesting l!!!

 

[Legend]

Big update!

Having made the UART transport layer successfully, I decided to try to put it to the test and see if i could get it working on the PS2.

Now that I am working directly on the PS2 as opposed to using PC2SX like before, I opted to remake the front end plugin showing a battery bar icon, battery percentage, and temp. This wasn't too bad as its really just drawing into the UI using Lua with the difference being that last time I did this, I was modifying the theme files rather than keeping it contained to just the plugin. This time its still technically bleeding into the theme so to speak, but its contained to the plugin. The plugin may clash with different themes other than the default theme but all it would take is just adjusting the position of the bar, percentage, and temp via the lua file which I plan to add instructions for in the code comments for anybody using a different theme. I havent tested it yet with other themes yet but there's already technically a fix for that so im not too concerned. As of right now, I still need to modify the battery icon to add colors, and different levels as it calls on a image based on percentage (0, 25, 50, 75, 100, and charging).

I was able to add all of this and test it manually by adjusting the percentage in XEB+ itself:


Now that I had a front end to test with, next up was trying to get UART actually working to update those values live, which unfortunately proved to not be as trivial as I would have liked. I cant stress enough that even as of writing this, the main issue im still facing is connecting the LUA front end to the backend (this will make more sense soon as to why im still facing this issue).

I started by seeing how I could achieve this directly, but it ended up with me having to create another irx module that the front end connected to, that then connected to the UART module. So it was:
PC > ppctty.irx > backend.irx > XEB+ front end

This kept crashing XEB+ so I tried a multitude of things to get it working and what I ended up doing works, but is not an elegant long term solution. I eventually landed on having to use a middle man essentially by having to read and write to a live cfg file separately. So that way the lua front end connects to the cfg file via backend.irx and reads/ writes values to it, then ppctty.irx accesses the file and reads/ writes over uart.

After getting this working, the issue became uart comms itself. I had it set to take a string such as PCT=90 from the PC to update the battery percentage live, but the issue i had without getting too much into specifics was with the timing and capture window of the bytes being sent. This caused it most times to only catch "C", "=", and "0" separately. I tried to do what I could to make sure the whole string was sent reliably but I opted just to change the protocol to single byte sends for testing and finally got it to work, confirming that this whole project is viable:


I ended up sharing my progress in a PS2 server and had somebody inform me that constantly reading and writing to a cfg file would cause a lot of wear on the NAND, and suggested I write the live state to RDRAM, which is a great idea considering the live cfg file is kind of a dirty way to do this anyway.

I set out to figure this out immediately but have been running into roadblocks. In my tests, ive confirmed that my backend.irx can access the ram no problem but the issue now is how that backend.irx works with the lua front end. The cfg file method was less invasive but unfortunately the ram method wont work the same through the front end. I still have options to try so I will exhaust everything I can before pivoting to something different.

I do have the XEB+ preview source code and could most definitely make something that flows better than what ive been doing, but i have strict rules on what I can do and how (if i do) distribute it, so i really wanted to keep all of this confined to a plugin that is just drag and drop, which ive done a good job of so far. The issue with modifying the source is distribution and upstream compatibility for when XEB+ eventually has its full release.

So the new TODO list is: get ram writes working properly while still staying contained to a plugin and fix the protocol so I can send full strings, as single byte sends will not work for the multitude of different parameters.

On a separate side note, the new PMS will use a ATtiny16 as its brains, so I ordered a dev board and UPDI programmer for when I can get everything working so we can move from the PC to a more live test.

That is all for now! Thanks for reading!

 

[Legend]

Its been a minute so I guess its time for an update!

In the last update, one of the todo list items was to get UART living in ram as opposed to a cfg file on storage as constantly reading and writing to storage wasn't a viable long term solution.

I spent more time than I'd like to admit trying to get this all to work properly, but the issue I eventually faced while using XEB+ was not getting it to live in RAM, but it was bridging the backend to the LUA front end in order to be able to update values etc. In all my tests, the only viable way I could see to get this to work was by creating what was essentially a virtual device called "pms" that acted just like "mass" (or USB) to use as my bridge to the front end. Many many tests and revisions later, it was determined that everything was working properly: the device was being registered properly, and displaying what it should have via a serial monitor, but trying to "open" the virtual device so to speak kept locking XEB+ up and freezing the console. I spent a lot of time trying to exploit any other methods of a bridge but couldn't get any of it to work.

Unfortunately, XEB+/ Enceladus doesn't have a clean way to access API's via its front end other than whats available. I could have remedied this by modifying the source code I have, and I actually started down this path however PS2SDK and the PS2 DEV tool chain did not like that I was trying to compile XEB+ with a newer version of the SDK/ Toolchain. I even tried to downgrade it and it would spit out a .elf, but it wouldn't boot properly and skipped a lot of vital stuff due to the mismatch. I was going to keep pressing on to figure it out, but I eventually scrapped using XEB+ when I saw something else pop up.

Daniel Santos: the creator of Enceladus which XEB+ is based on also happened to make another great engine called AthenaEnv with the difference being instead of using LUA, it essentially uses Javascript as its core. Upon looking a little further into this, I figured out that there was a perfect software front end called OSD-XMB that was created based on AthenaEnv and inspired by XEB+. Its based off of the PS3/PSP XMB and seems to look a lot cleaner:

Its a beautiful piece of software with all the goodies already included, so the pros are this:

- Great smooth operating XMB style interface
- Neutrino Launcher and POPStarter integration without the need of a list builder etc. Like XEB+
- Supports a user made plugin ecosystem
- Supports Custom themes
- Actual runtime and core error handling during crashes
- Runs off of the memory card/ MMCE device thus giving the option to omit USB
- And many more things

But the biggest win for using this AthenaEnv based front end was the fact that it had a better way to bridge backend stuff to the front end.

So i downloaded it and started tinkering with it to the point of getting the same type of test working as I did with XEB+. I could write to a live cfg file on storage and have the front end read it to update the values live. Once I had this running, I figured i would look into how I could transition this to having it live in RAM as I originally intended, and to save you all the small details, I eventually did get it to live in RAM! Its still in a primitive state and there's a lot to figure out to slowly start adding things but its working as intended.

Next up was getting a MCU connected to the PS2 directly as opposed to using the ttl to usb adapter that you've seen in previous tests. The idea was just to test running through the battery percentage values sequentially to verify functionality, and it was giving me a little trouble as using the AVR code directly as opposed to something like arduino or platformIO is foreign to me lol, but I got it working!


After getting this all working, I started thinking about the capabilities of the ATTiny1616 and came to the realization that I dont think it'll be enough for what I want to do. It certainly would be if I was good with optimization and keeping everything minimal but im not good at that yet so I think I may move to something like the ATTiny3217 for more breathing room. It seems like the best choice for what im doing right now and it gives me the ability to create a more robust bootloader without having to worry about maxing out a 16kb flash. The extra IO are a plus as well.

I have some things ordered to perform more testing but once I can get some of this stuff working, I'll then focus on creating the PMS itself, ordering it, and testing each "block" of it in steps to ensure we have a good working product! In the meantime, I need to clean up the UI and add some things so it all flows together nicely.

Thats all for now, thanks for reading!

 

[Legend]

Update time!

I ended up picking up a DJI Osmo Nano POV camera and wanted to try it out so this will be a video update as opposed to a written forum update.

Forgive my late night shenanigans as the insomnia kicked in lol, thanks for watching!