When taihen was first released, it was requested by Yifan Lu to use the USB serial functions to facilitate logs. These serial functions were used by PSM and now have been made to redirect stdout to a usb serial device, which serves as a standard COM serial port.
Princess Silly Mini Log USB is Princess Log with net functions replaced with USB serial functions and was created at the request of Silica, Pina and SonicMastr. It has full compatibility with Vita Shell's USB Mass Storage device system.
Add PSMLogUSB.skprx to your config.txt and reboot.
Open your favorite serial monitoring program and set the correct COM port. Set the baudrate to 57600.
Note:
PSMUSBLog will try to end any other USB service, except the the one used in VitaShell for Usb Mass Storage(UMS) mounting. So this will naturally create incompatibilities with plugins such as vita-udcd-uvc.
When using UMS, the serial will be interrupted, however will auto-start up after the UMS service has ended.
The serial device will also be disconnected on reboot and will only restart until the plugin is re-initialized (usually right when Taihen launches)
The reset vector should be the first thing that is executed by the processor, which before command 0x30006, is held in SceCompatSharedSram.
Normally, if you try to peak at the SceCompatSharedSram, it will cause a crash until command 0x30006 on compat_sm.self is called. However, on accident by putting the wrong amount of arguments on a hook, I found that passing 0 size on 0x10006 allows you to write to the reset vector once through some f00d glitch. Maybe I'm wrong, try for yourself.
This was tested on 3.60.
To prove this theory:
A hook is made set the 0x10006 command to fail with 0 size on SceCompat
This hook will then read "ux0:/data/mips_rst.bin" to the reset vector. I will attach the the pre-ipl + challenge mips_rst.bin to the post.
Adrenaline is then loaded (it seems to only work once for Adrenaline?) with the mips_rst.bin loaded into the Reset Vector.
Adrenaline is then loaded without mips_rst.bin, causing error c1-2650-3
Adrenaline is then loaded with the continue commented out, which causes kpanic.
Change the hook to pass the size, and it should crash.
Uncomment write_reset_vector(); in the standalone func, it should crash.
I will be posting more findings relating to SceCompat if they are not already documented.
Thanks to Mathieulh for his Wiki information, Motolegacy for linking the ME example, Celesteblue and Princess of Sleeping for being fappers and helping a ton, teakhanirons, and Sysie for method of testing
TheFlow for adrenaline.
Anyways, in what has become standard for me, I just found this and have no idea how it works. Hopefully, someone will find it useful.
This post was originally made by SuperiorSpidy to /r/vitahacks, I was surprised when I went looking for it and it was missing. Luckily it was archived on removeddit and I had a link in my phone history. I am archiving it just in-case some of you have missed it:
Quote from: SuperiorSpidy
robots commented 10 hours ago • edited
So, since this corona stuff, work is being relaxed. I think i will have time to work on this.
I have created repository, and pushed all my stuff into that. I cannot push my notes there as they are in my head :-)
robots/Adrenaline@a0b1b68
Description:psp part: this is copied and reworked uofw ge driver. All writes and reads from registers have been replaced by requests to vita.
PSP ge driver is source:https://github.com/uofw/uofw/tree/master/src/gewith my additions (hopefully fixes):https://github.com/uofw/uofw/pull/58/files
Since there is limited number of shared resources between vita and psp, we have to share. There is at least one messagebox free (KERMIT_MODE_EXTRA_1, adrenaline uses KERMIT_MODE_EXTRA_2). But these are no interrupts free. We will share the interrupt adrenaline uses. Adrenaline uses this only to signal save/load of state and memory card reinsert - these are very rare interrupts, thus Adrenaline will not mind sharing.
u/NT-Bourgeois-Iridescence-Technologies it is not possible just to stream gpu data from psp. Gpu data is in ram that is not accessible from vita.
I patch the sceGeEdramGetAddr function to return address in vita's CDRAM (mapped into PSP's memory space) This way PSP game will write directly to shared memory. This makes it harder to have both gpu on vita, and ge on psp work at the same time (i would like to have switch, for games that are not yet compatible, but i am sure we can unpatch the ge driver or add some flag to select code.)In psp code i think it misses just the hooking stuff (and the flag)
For the vita part, i have started to write the GE state machine in C. I use PPSSPP's gpu framework as source of ideas. But its like 2percent of work done.
The roadmap should be something like:
write vita's ge statemachine test it on vita only (with some psp example from https://github.com/pspdev/pspsdk/tree/master/src/samples/gu) finish psp ge driver hooking. test complete system. So what is needed is one PSP developer who knows psp hooking stuff to finish the ge driver.
Some information pertaining to bruteforcing NIDs on the PS VITA:
The algorithm would fall into two categories:
Category 1: The system used on the PSP was just a sha1 hash with the first few bytes selected and then byte swapped, there are a few libraries that follow this scheme on the PSV
SceDisplayForDriver SceFace SceFios2KernelForDriver SceIdStorageForDriver SceLedForDriver ScePower ScePowerForDriver SceSmart SceVoice SceVoiceQoS This means that any syscall within these libraries can be bruteforced with just sha1. Many of the names are shared with the PSP, however they have been already bruteforced.
I think there is another library called something along the lines HPRemote that can also be bruteforced, with most of the known ones being added to the henkaku wiki using this method.
I have also found that modules compiled with the official SDK also use this:
0x09D7D05B Thus, every module included in official games can have their function names bruteforced as long as they actually are exported. Ex: Unity modules and the modules included with PSO2.
You CANNOT bruteforce function names that are not exported such as internal functions or any function within the main eboot. This is how the mono NIDs I had posted earlier were found.
Category 2: These NIDs have a suffix which is concatenated to the end of the name before they are hashed. The methodology of obtaining these generating these suffixes are yet to be found.
0x935CD196 It is theorized that the majority of NIDs are generated using a suffix, however, again, the methodology of generating this suffix is unknown.
Special thanks to CelesteBlue and Princess of Sleeping. Further thanks to SocraticBliss and ChendoChap for working on a hashcat bruteforcer, and SilverSpring.
Visual Studio Code is the latest meme/botnet code editor from Microsoft that everyone is using to program now. It is similar to Visual Studios in allowing IntelliSense except more lightweight, cross-platform, and in an attempt attract neck beards to this botnet, offers more customization.
IntelliSense in action with VitaSDK (Code Auto-completion)
IntelliSense in action with VitaSDK (Code Parameter Information)
Of course, with this demographic comes the emulation of annoying configuration that doesn't work out of the box in order to give feed into a superiority complex that these neck beards so desire.
What Will This Tutorial Cover?: This will be a brief overview on getting VS Code to work with VitaSDK installed through msys2 on Windows. This includes building and setting up the headers. This is just what worked for me and may not apply to your system (ex: if you are using a dated 32 bit machine). I don't really know how to use this thing, so I'll just tell you everything I had to do.
Installing msys2 and VitaSDK: Since they have detailed steps on their respective websites, I will just give notes on installing. If you already have it installed, make sure you have the dependencies listed below.
Install msys2 first, downloading the 64bit version (ex: msys2-x86_64-*.exe). Install it then SCROLL DOWN and follow the remaining instructions on the website!
Then attempt to install VitaSDK through the Windows instructions on their website, except use the following dependencies instead:
pacman -Su make git cmake tar mingw64/mingw-w64-x86_64-libwinpthread-git python mingw-w64-x86_64-cmake mingw-w64-x86_64-toolchain For doing exports, if you don't know where the .bashrc file is:
This will open a text editor, paste the export information into there and restart your terminal.
After this, continue with the install of vdpm and hopefully it will work for you...
Make sure the following is in your Windows User PATH environment variable. I cannot give instructions for this since it is different for every version of Windows, a quick google search will tell you how to do this:
Setting up a Project (Part 1): Install and open VS Code.
Drag and drop the source folder of the desired project onto VS Code.
By source folder, the directory that contains the CMakeLists.txt file.
VS Code should automatically detect and prompt you to install the CMake Tools and C/C++ extensions by Microsoft.
If not, click on the Extensions button on the left side bar, search for C/C++ and CMake Tools (not CMake) and install them respectively (I already have them installed).
After both extensions are installed, it is now time to configure CMake Tool. Because CMake defaults to Unix Makefiles and Windows obviously does not use a Unix file system, errors will occur. Thus, the following section is dedicated to fixing this issue by using minGW, which uses Windows Paths. I think...
Hit the key combo CTRL+SHIFT+P to open the "Command Palette" and type Settings json and look for "Open Setttings (JSON)"
By doing this, we are changing the CMake generator type to MinGW to allow it to build within windows and we are using the MingW64 cmake. The rest is maybe optional. I don't know.
Be sure you have all your commas and keep the syntax proper.
Example settings.json:
Now open the Command Palette again, and type "cmake" and look for "Edit User-Local CMake Kits"
Add the following code to the now opened cmake-tools-kits.json:
"toolchainFile": "C:\\msys64\\usr\\local\\vitasdk\\share\\vita.toolchain.cmake", "preferredGenerator": { "name": "MinGW Makefiles" }, "environmentVariables": { "VITASDK": "C:\\msys64\\usr\\local\\vitasdk", "CMT_MINGW_PATH": "C:\\msys64\\usr\\local\\vitasdk\\bin" } }, With this config, we are setting the VitaSDK enviromental variables along with setting the path to locate the compiler binaries. We are also hard-coding the location of the toolchain cmake file (normally set by the cmake file in the project).
Be sure to mind your brackets, commas, and curly braces.
Example cmake-tools-kits.json:
Make sure you saved all your files and now CMake should be configured.
Look at the bottom left corner of the Window, you should see "No Kits Selected", click on that and change it to "VitaSDK".
You should be able to build now by clicking the "Build:" button in the same bottom bar area.
If it doesn't work the first time:
Navigate to the location of the source folder and look inside it.
Make sure there is no build folder.
Open the command palette and then type Developer Reload and reload the window
And with luck, it should configure CMake and allow you to build the project.
Setting up a Project (Part 2): You will have to do the following with every new opened project.
Open the command palette, then type c++, looking for "C/C++: Edit Configurations (UI)"
Add a new configuration called VitaSDK and set the compiler path to the following:
The nightmare is over and now you can enjoy using VS Code. You can try setting up other things like Davee's gdb thing, but it is not as stable as I would like it to be.
This tutorial will go over the basics of decompiling a vita binary in the self format. Xerpi has made a pretty good readme, but this tutorial was requested.
*sceutils requires more setup and will probably be covered in another tutorial, so we will use FAGDec in this one, assuming that your firmware can handle the modules you wish to decompile.
Using FAGDec to obtain a specimen. This is a must do step because most modules are encrypted and cannot be directly decompiled. You may skip this if you know how to use sceutils by Team Molecule
After downloading the VPK from the PSVita-RE-tools repository and installing it using Molecular shell/Vitashell, open it.
FAGDec will then list all common devices (ux0, vs0, and os0) and the games it has found. Click on any of these options to bring up a list of decyptable assets. It will take a while to search for all assets, wait for the DECRYPT ALL to say (DONE).
The home screen of FAGDec listing all common devices and games:
FAGDec currently searching for modules:
FAGDec when it is done searching for modules:
Scroll and find the desired module adding it to the list on the right.
Go back to the main menu and select either "Decrypt to ELF" or "Decrypt to SELF".
If you decrypt to SELF (in some cases such as using elf-injector this is desired: https://github.com/CelesteBlue-dev/PSVita-RE-tools#vita-elf-inject-usage), you must run though vita-unmake-fself. This can be done through command line, or on windows, just drag and drop your self on the application's executable and a elf will appear in the directory.
In the case of an ELF, you may use this directly with your decompiler of choice.
Note for modders, at the current time, YOU NEED SELF_AUTH.BIN. Please do not forget to include this file.
Your files will decrypt to "ux0:FAGDec"
Setting up GHIDRA: Download Ghidra and extract the zip file.
Download and place the yamlbeans jar in the root Ghidra folder that contains "ghidraRun". Download and place the VitaLoader.java in the same place as above in a folder called Scripts (create this folder). Download and place the db.yml in the Scripts folder.
Run Ghidra by double clicking ghidraRun.bat
Go to Edit > "Plugin Path..."
Hit "Add Jar..", navigate and find the yamlbeans jar adding it to the list.
Create a New Project (File > New Project) that is not-shared.
Go to File > "Import File..." Navigate to the ELF and import it. It should auto-detect the ELF type, press OK to both pop ups.
Double click the file in the list.
If you get a prompt asking to analyze the file, hit Yes. Then in the following prompt hit Analyze.
Be aware that on big files this may take a while. There is a status indicator in the bottom right. You may need to resize your window to see it.
Go to Window > Script Manager
Click on the Script Directories button (1. in the image) and then click on the add button (2. in the image).
Navigate to the Scripts folder containing VitaLoader.java. Then click OK.
Hit Dismiss. Refresh the scripts (3. in the image).
VitaLoader is now set up in Ghidra.
Running VitaLoader.java
These steps will have to be repeated for every new loaded vita ELF.
Go to Window > Script Manager (If you are not already in it)
Scroll down on the folder list until you find Vita. Click it.
Make sure VitaLoader.java is checked and double click it. It will now open a file open dialog, this is for the db.yml in order to resolved the NIDS/Syscalls.
Navigate to the Scripts folder and open the db.yml.
If no errors occur, then you can now examine the elf.
There are many homebrew that I see that do not make it on the news, VitaDB, or even get finished, so this is an attempt to shed some light on them. Many of the Playstation scene websites rather watch paint dry (the PS4 scene) than cover anything not TheFlow on the Vita scene.
Note: I have not personally played all, if not any, of the games on this list. They may be unknown for a reason... Besides not having quake in the title.
Please contribute if you come across any: Andromeda by DrakonPL - Many graphical experiments.
EDGE (Enhanced Doom Gaming Engine) - EDGE is an open source implementation of the DOOM engine with enhancements.
There seems to be a reference to the vita in its makefile, however I am not sure if there are any pre-compiled binaries for the vita. I may try to compile myself. If you do, please post a link. Thank you in advance.
Sqrxz 4 port by Rodolphe Boixel (Thor) - it seems this game has many installments with the 4th being ported to the vita. It looks like a very nice puzzle platformer that uses SDL allowing for it to be ported to many systems. The original Sqrxz was a DOS game made in 1996 by Marcus Vesterlund (Maze) and John Holmvall (Hojo) for DOS and Windows 9x.
xsystem35port by nunuhara - an open-source implementation of AliceSoft's System 3.x game engine in SDL that was ported to the vita. The author warns of many bugs. You can read about System 3 and the eroge games, such as Rance IV, utilizing it here. https://alicesoft.fandom.com/wiki/System
A Compiled History and Improvements (Skip to the end for a download and screenshots): TailTale, or Shippo no Puzzle – Tail Tale, is a fast paced Tetris Attack-like puzzle game created by notable Japanese developer rerofumi and artist pyonkey-matsuo of the doujin circle FumiFumikick (formed 1997). The game, made in 2002, is a “doujin fan application” using characters from the relatively obscure anime Angel Tales/Angel’s Tail. Maybe too obscure as seen with its inaugural release, which was burned onto CD-R’s and had 10 copies sold. Rerofumi decided to distribute online along with its source code. Thus started TailTale’s Tale in open source software, however there was a hurdle.
It was programmed originally in the not so popular FreePascal utilizing SDL4FreePascal. But in Oct 2005, with interest in PSP homebrew growing, rerofumi was compelled to convert his work to C utilizing the portability of the SDL library. Because of the combination of C and SDL, this version served as the basis for every port to come.
And they came. (Full list and Links at the end. If there are anymore or you can recover some of the files, let me know.)
You may notice Rikku2000 popping up a lot, rerofumi actually has a pretty funny statement regarding the developer. Maybe something was lost in Google Translation:
Quote
Martin Dieter [Rikku2000], who lives in Germany, is one of those who likes "tailing" strangely, and who emails me every time he's ported something hard.
Many of his ports were through the seemingly defunct BigVioSoft, based in Germany. I really hope it was not a result of rerofumi’s post.
However, Rikku2000 is not too crazy with his love for TailTale. With every port it has gained new fans who praise it for its fun, addictive nature and cute graphics. This so much that the GP2x version had to be accommodated with new controls, due to the dead zones of the joystick hindering its gameplay. Some even listed it as one, if not their, favorite homebrew for their respective system. Even the devs of these ports take a liking to it.
I personally have gained a probably unhealthy (and autistic) obsession with this game (as you can tell with this article) and it is probably the longest I’ve played on my PS Vita gaming wise. I like pretty much everything about it, not only gameplay wise, but also its overall aesthetics. The music and graphics are just wonderfully a product of its time. SonicMastr, who tested my port, liked it so much he experienced hand cramps from playing the game (I also did, even with my baby hands, I can’t understand how people play on the Vita now).
So, with this new found love for a randomly selected game I found on wiibrew, I have decided to try to restore its full resolution.
Because the original was written in FreePascal, every port (that I know of) is based off the PSP port. This meant that with the resolution limitations of the screen, changes were made. The resolution of the assets were cropped, and in the version I used the quality was reduced also. Along with this, the overall difficulty changed with amount of rows being reduced from 13 to 11/10.
Rerofumi has made the changes to scale the game down easily reversible and if they were not, the Pascal code was used. But in hindsight a lot of this work was due to using gameblabla’s port as a base (such as the issues with PNG alpha), his base may have also helped, who knows. However, I did learn some SDL stuff at least.
So this vita port is seemingly the first port to restore its full resolution, utilizing the original PC assets, all while maintaining the new features such as difficulty settings.
With more rows, I have moved the difficulty over 1 (example hard is now very hard, easy is now normal). So thus the resolution went from 480x360 -> 480x272 -> 320x240 -> 480x360.
Vita running the gameblabla's 320x240: (note the PSP version runs at 480x272 I believe, which had larger vertical resolution)
Vita running the restored 480x360:
Anyways, I hope you enjoy the game as much as I, the first 10 people who bought the CD, and the many other scenes did!
Princess of Sleeping has allowed us to release their logger which has must better performance (in memory management and speed) to finally replace the terrible ShipLog. This logger works similarly to ShipLog in that it captures all stdout with ease (with better accuracy also). Please upgrade to this if you have been using ShipLog.
Usage instructions: 1. Install NetLoggingMgrSettings.vpk. 2. Launch the application and configure your settings. Be sure to save. 3. Add net_logging_mgr.skprx to your config.txt 4. Run
Note: If the plugin is already installed and you wish to update the configuration, you may use Update Configuration (along with saving it) without rebooting your system.
Note: While being much faster than ShipLog, if there is massive amounts of logs the logger may not be able to process them completely and will freeze (ex: taiHEN hexdump). This is unlikely in normal usage.
FAPS Team is currently working on something that required better logs as the current "real-time" logging methods used, while well written, did not perform well enough for this. Thus, I looked into getting UART, a simple serial communication, out on the Vita. This is not a new hack and has been known forever thanks to the work of Yiffy and the vita scene lord Xerpi.
This article is just a compilation of their work and the steps I took to replicate it. If a brainlet like myself can do it, so can you!(Don't blame me if you are an omega brainlet and break something though)
If you are in EE, you can just stay for some laughs.
Also Disclaimer: I am not an EE and I do not claim to be and again am not responsible for what happens to your device. This is just what worked for me.
Making a plan:
I only have one Vita, so I only had one chance, so I did as much research as my patience would allow. From the information on the internet (henkaku wiki -https://wiki.henkaku.xyz/vita/UART_Console):
UART0 is obtainable on the PS TV and on OLED 1000 Vita models. On the PSV1000, there are two points to obtain UART0: On the multi-connector or in the metal can near the multi-connector. All points have easily solder-able test pads. However, the one directly on the multi-connector, you need to deal with that switch thing and they have a bit smaller pads.
On the multi-connector itself.
Furthermore, the 3G model has UART5 on it's PCIE connector but who cares you can get that with Yifan's PSVD.
The logic level is 1.8v!
It seemed that you can use both UART0 and UART5 them respectively. The number is the port.
After consulting with Celesteblue. I found that his Frankenvita, created by CentrinoUK, uses the one under the metal can (Kermit UART0). He said that the multi-connector one was not proven to be working (the one with the extra connections and the nonsense with the jumper).
So with this information, I decided to mod my PSV1000 to get Kermit UART0 using the test pads under the metal can because I could use the same applications as Celeste, there is a labeled points for 1.8v, and it is known to work thus removing uncertainty.
However, there comes the hurdle of actually having a device for communication. I don't like spending money and waiting, so I decided to use devices already have. I had just recently found an Arduino pro micro clone (I lost it right before I did my port of psp2048), so I used that.
Modding the Vita:
This is not a teardown, go to iFixit or something. However some tips if you are too lazy like me:
Do not remove the front facing camera from the mainboard (it is the one with the thick connector that goes into a ZIF socket) until you remove the mainboard. Do not remove the mainboard until you free the front facing camera from underneath the controller board. Watch out when removing the controller board as I broke one of the connectors, nothing a bit of tape can't fix... This probably wouldn't be a problem for careful people. Which I am not.
Click the images for larger versions:
Opening the metal can was probably the hardest part of dissembling the device, it's not soldered, just an annoyance to lift.
I used a solenoid's wires (thin wire with enamel) and soldered them to each of the necessary points. To remove the insulation off the wire, use a hot solder blob on the tip of the soldering iron or burn it with a lighter. For UART, you only need: TX, RX, GND, 1.8v. There are holes in the metal can that are big enough for these wires to escape. Please keep in mind that the Vita is a premium product, and these wires will turn them into a Nintendo DS.
I pushed the power related wires and the communication wires through different holes. This makes it so you can identify them with one color of tape. Speaking of tape, I covered the soldered points with tape to insulate from the metal can (especially that capacitor with the power wires). No, tx is not touching that capacitor... I think. Be sure before covering that you test the connections, obviously. These points were quite easy to solder to even with my shaky hands and terrible tools. I used a Michael's woodcraft soldering iron with a pitted conical tip with no magnification.
A hole was burned through using the same soldering iron, the vita plastic had a weird gritty feeling while melting it. It is pretty easy to form a desired exit for the header (just get any header and trim it down or use any connector you have lying around). I don't remember if I started burning from the inside or outside, sorry. Regardless, watch out for the battery.
There is also plenty of space internally which a header could easily fit. Zexceil was able to fit a USB port in his 3g model. I am wondering if you could another SD card slot maybe for an SD2Vita... If only I had not wasted so much space with this UART. Also, before putting hot glue don't be a tough guy like myself. I didn't test it before hot gluing and the first time it did not work so I had to rip it out.
I was going to put a disconnect header, but whatever. You can see I broke the battery connector (from repeatably testing the UART as you will see later)... You can also see I used blue tape to distinguish wire pairings, you could just get away with one color tape though. I used the following pinout: 1 1.8v 2 Tx -blue 3 Rx -black -blue 4 GND - black
Not a bad job for a brainlet, probably should have pushed the header in more though. I will write here (before I forget) that pin 1 is closer to the multi-connector, hopefully this site doesn't go down... You should mark yours with a pen or make some sort of key pin. This was a relatively simple mod to perform. All in all, I managed to only break the battery connector, one controller connector, and left only one screw out! This is good for me. The bulk of the issues came in testing it without a known working UART communicator...
The Pain of Getting UART
The rest of the process is dedicated to documenting getting 1.8v logic levels to work with the Arduino pro micro's 5v logic levels. Many devices use either 3.3v (Linux computers like odroid or Raspberry pi), ESP2866 or 5v (many Arduinos), thus you must have a logic level shifter or circuitry to compensate. Or you could just buy a UART communication device that supports 1.8v (again many cheap ones only support 3.3v and 5v).
I found some guy ran into the same issue and fixed it with the diagram in this post: https://forum.arduino.cc/index.php?topic=160716.msg1210677#msg1210677. Luckily I had a bags of assorted transistors and resistors from when I biked to Radio Shack as a kid one summer. I just say that because it sounds extremely boomer.
It was a great pain getting this to work because I did not know if it was my Vita, Arduino and its code, or the circuitry was at fault.
I confirmed the Vita connection worked and that UART on the Vita was initialized properly because I had originally had a broken Arduino nano with the ATMEL chip ripped off to use as a serial device (this route did not work btw) which exposed blinking RX lights when the Vita was sending data through a test application. The Vita also reacted when I removed the RX line connection from Vita. I switched to using a pro micro (again).
I am relatively new to the microcontroller memes, but I managed to code something to redirect Serial1 to Serial. After a while, I started to get weird symbols on the serial monitor. I messed with the baud rate (115200 recommended by Celeste), and restarted the pro micro a couple times. Then finally remembered you send characters not strings.
However, there was no sending (PC-> Vita) yet. I used a voltage divider, it didn't work. I tried inverting it, it didn't work. Then I realized I forgot to code the redirection of input... Then the characters came in wrong with "q" coming back as "G" on the Vita.
q 01110001 G 01000111 I'm sure you can now see the inverter is not necessary... So voltage divider only, it is.
Thus, here is the circuit I used (it's mostly that guys diagram redrawn to be more absolute with a voltage divider). Please keep in mind you will have to recalculate the voltage divider, easily googe-able or you can pay thousands of dollars and go to University.
Diagram for 1.8v to 5v logic levels:
UPDATE: I got the broken Arduino nano to work, thus do not need the script. This was accomplished by using a wire bypassing the resistors on the bottom of the board creating a direct line for the tx and rx line to the CH340G. The original diagram had a 1k resistor going to the Vita, however it is 10k in the build. I have updated the diagram to reflect that.
static tai_hook_ref_t SceLowio_kscePervasiveUartResetEnable_ref; static SceUID SceLowio_kscePervasiveUartResetEnable_hook_uid = -1; static tai_hook_ref_t SceLowio_ScePervasiveForDriver_81A155F1_ref; static SceUID SceLowio_ScePervasiveForDriver_81A155F1_hook_uid = -1; static int kscePervasiveUartResetEnable_hook_func(int uart_bus) { /* * We want to keep the UART enabled... */ return 0; }
/* * Returns ScePervasiveMisc vaddr, ScePower uses it to disable the UART * by writing 0x80000000 to the word 0x20 bytes past the return value. */ static void *ScePervasiveForDriver_81A155F1_hook_func(void) { static unsigned int tmp[0x24 / 4]; //LOG("ScePervasiveForDriver_81A155F1()\n"); return tmp; }
void setup() { // put your setup code here, to run once: Serial.begin(115200); Serial1.begin(115200);
}
void loop() { // put your main code here, to run repeatedly: if(Serial1.available()) { int c = Serial1.read(); Serial.write(c); } if(Serial.available()) { int c = Serial.read(); Serial1.write(c); } } Anyways, it was not a good idea to introduce so many places for errors without many knowns especially with no background in this. Hopefully this will help you also reduce your errors and learned something though. However, you could literally skip the second half if you just wait 2 days for Amazon prime and pay the 12 dollars. I apologize for the dirty objects in the pictures.
Vectoroids is a game created by Bill Kendrick based on Agendaroids in 2001. Agendaroids was based on the classic Asteroids. The readme packaged with the source provides more information. This version of Vectoroids was a port for the Wii by MiniK.
Thus the timeline is as follows: Asteroids -> Cloned into Agendaroids for Agenda VR3 by Bill Kendrick -> Recreated for SDL for a "SDL Game Under 1 Megabyte" contest held by No Starch Press / Loki Entertainment Software by Bill Kendrick-> Ported to Wii by MiniK -> Ported to Vita by me.
Screenshot:
CONTROLS
Hold the Vita (or controller) sideways
PS Btn Exit to loader Start Return to menu Cross Shoot Circle Thrust
Thanks New Breed Software MiniK Team Molecule VitaSDK and GCC authors rsn8887, Cpasjuste, xerpi for SDL-Vita The Vita homebrew community as a whole. (Especially CBPS)
Show Posts
