Hey guys, I'm new here and I was wondering about console verification of TAS's on the ps2. I would really like to try to set something up using either my arduino uno or mega. I was thinking about using the arduino as a controller with one of the following methods:
1) Have a controller plugged in, but tap into the data wire and send button presses to system with arduino.
2) Full emulation of controller using arduino (probably hardest?)
3) power a controller with arduino, but remove all buttons and pin them to digital outputs, then send power to each digital output as necessary (to simulate a button press).
I find 3 to be the easiest method in my opinion, only because it requires the least amount of encoding.
What do you guys think?
How will you handle for disk reads taking varying amounts of time to complete? (Or do you have a way around it?)
I have a potential idea for this, but I'm not sure if it will work yet. Obviously the controller sends data but more importantly it receives commands from the psx/ps2. My plan is to monitor controller I/O and see if there is any specific data sent during loading. If there is, it makes it as simple as pausing between loads. If this isn't the case, I will likely have to figure something else out. Another option might be sniffing the memory card I/O for some specific command that happens during loading (it uses essentially the same protocol as the controller port). If again I strike out, the only other thing I can think of is adding some wires to the ps2/psx so I can look for a "done loading" command, but this will be the hardest thing to do. I won't be able to do much physical work on capturing controller/memcard I/O until June when I'm home from college. Until then I'm going to be doing some more research on psx/ps2 protocol.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
You will still need to battle that RNG may turn out differently from load-time differences. The rest of the console does not stall as data is being loaded from the disc.
So even if you figure out how to wait for the disc to load, the run will still most likely desync on you.
Essentially you would need to replace the system's disc drive with a chip that emulates the disc drive and feeds the data to the console at a deterministic speed.
The problem I see with all this is that it starts becoming less of "console verification" and more of "how can be mod a console to make it run a TAS?"
The more modifications you do to a console to make it work, the less legit it feels. Optimally a TAS would be console-verified solely by connecting a device to the gamepad port, and make the device emulate a gamepad, and nothing else. This is how it works with the NES and the other older systems that can be run this way. But as we move to the systems with disc drives...
This reminds me of TheAxeMan's Final Fantasy console verification strategy:
http://tasvideos.org/4450S.html
Maybe a way forward for disc based runs is to develop TASing techniques that are robust to unknown RNG like TheAxeMan did.
The real world is messy and in my mind it seems better to have a robust run rather then doing extensive console modifications to make something work.
Although, the technical difficulty of this is probably much higher.
Here's an idea that would probably be the best method to go about running a tas on say a psx: re-write parts of the tas to run code based on the current rng. If we know how the rng is created then we can read whatever part of the console (say, clock cycles for instance) through the I/O port and use if-else statements to determine which button commands to send. I know this would be complex, but then there would still be no console modification, just data reading. Would this be possible?
Also I know that rng would be implemented in different ways for different games, so there would be no "single strategy" for collecting/utilizing I/O port data.
Side note, considering buying an xplorer fx from amazon U.K. So I can see what kind of goodies I can get from the psx I/o port
Oh and since I haven't formally introduced myself. Here's a little background info on me. Currently getting my bachelors in Mechanical Engineering. I've never done a speed run or written a TAS. I have some coding experience, and I have done some minor game modding in the past. I'm personally more of a hardware guy than a software guy. Most importantly though, I've recently grown more and more in love with C/C++, I love a good challenge, and I'm a quick learner. So I'm more than willing to spend a good amount of time this summer trying to get a psx tasbot set up, if you guys are willing to help get me going in the right direction! I love watching speedruns and my favorite part of every GDQ is the TASblock, and I want to do my part to contribute!
I don't think having someone redo the entire tas is an expandable scenario for console verification. I'd personally prefer modding the console, because that'd at least make it universal for all the runs that have a sync potential. Even though in the eyes of some it won't be as clean as untouched console, there's no way out that's equally reliable and legit (for the purists).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
so essentially it would be better to send game data directly to the console (possibly through the I/O port, possibly by removing the reader altogether and spoofing read data) and bypass the disc reader?
This reminds me of TheAxeMan's Final Fantasy console verification strategy:
http://tasvideos.org/4450S.html
Maybe a way forward for disc based runs is to develop TASing techniques that are robust to unknown RNG like TheAxeMan did.
The real world is messy and in my mind it seems better to have a robust run rather then doing extensive console modifications to make something work.
Although, the technical difficulty of this is probably much higher.
I agree, but it all depends on what the tas writers want.
so essentially it would be better to send game data directly to the console (possibly through the I/O port, possibly by removing the reader altogether and spoofing read data) and bypass the disc reader?
If it's possible to accomplish, it sounds like a perfect thing to try at the very least. Like, if someone comes up with a more legit way to console verify psx runs, be our guest, but until then, we aren't making it more legit by not running them on the console at all.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I'll do some research and see what kind of solution I can come up with. I know that data can be sent through the I/O port to the psx (usually used for debugging home brew stuff) so that could very well be a usable method. Also maybe run psx games off a ps2 with an internal hard drive? But I guess in a way that would still be "emulated"
Does PS2 emulate PSX games, or run them directly on hardware? It might be like GBA playing GB/GBC games which IIRC is directly run on hardware.
Just checked, early "fat" ps2s have ps1 hardware in them as well as ps2 hardware. And I happen to have a working softmodded ps2 right next to me (need to get the network adapter though to install a hard drive, but I was planning on going that anyway). I think that's the route I'm going to take. Seems like it will involve the least amount of fuss.
After some further research, the psx hardware in early PS2s is used to control IO/usb, so i will not be able to hdd load psx games on PS2s without emulation. However I also found a device (psio) that allows the loading of games through the psx io port. It works by emulating the disc drive. I'm going to work on sending control commands to the psx and will buy one of these when I can successfully stream controller commands to the console. (I would buy a psio now but they're back ordered and about $115USD).
If anyone is interested in psio check it out at http://ps-io.com
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
Patashu wrote:
Does PS2 emulate PSX games, or run them directly on hardware? It might be like GBA playing GB/GBC games which IIRC is directly run on hardware.
I think the only difference between the fat and slim PS2 is the IDE disk support.
All of them have hardware perfectly capable of running nearly all PS1 discs (apparently fat models have better compatibility).
There was an official PS1 software emulator called POPS-00001 and it was made to run a single game, Bishi Bashi Special 3 so the compatibility is terrible.
It requires the hard drive so it's only compatible with fat models (though there might exist hacks to make it run stuff from USB on the slim models).
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself.
It rests on the conviction that you — by your choices, effort and actions — have made yourself into the
kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional
functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success."
- Onkar Ghate
Bisqwit wrote:
So to utilize an arduino to control the psx what im going to do is essentially make a jumper between the controller and system that will allow me to read all pins. Im sure it will be hard to visualize but i will use a ps2 controller port assembly and some cables from extra controllers i have lying around to make it. I will be able to intercept and re-route controller port pins with the arduino as necessary. Also i will probably 3d print an enclosure for it (because style points matter!).
As far as the programming goes:
First what i'll do is connect a controller to the arduino and use existing libraries to gain a better understang of protocol.
Then, i will likely use these as a starting point to write a program that inputs button commands and sends hex values to the console through the data pin.
After this, i can figure out how to input a tas file to the arduino and send commands (I'm sure there are online articles on how to do this when making things like nes tasbots)
Joined: 10/12/2011
Posts: 6342
Location: The land down under.
I'm just gonna rehash my point from here about using the PSN/PSTV/PSP instead of a PS1/PS2.
Spikestuff wrote:
Just bit more on the PSN side of things.
The PlayStation allows users to purchase the Classics on the store and the loading times are consistent enough to warrant a run.
The PSTV is considered the fastest with fast disk speed enabled out of the bunch with the PSP behind in a close second.
So if you look into either one of the two (Both have games the other doesn't have... Oh yeah... PSP store is dead. Homebrew away~!) you'll have a more consistent result compared to the likes of an actual console.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
I'm just gonna rehash my point from here about using the PSN/PSTV/PSP instead of a PS1/PS2.
Spikestuff wrote:
Just bit more on the PSN side of things.
The PlayStation allows users to purchase the Classics on the store and the loading times are consistent enough to warrant a run.
The PSTV is considered the fastest with fast disk speed enabled out of the bunch with the PSP behind in a close second.
So if you look into either one of the two (Both have games the other doesn't have... Oh yeah... PSP store is dead. Homebrew away~!) you'll have a more consistent result compared to the likes of an actual console.
So long story short, I shouldn't have sold my psp...
What do you think would be the best way to setup a tasbot? Should I try to set something up for the PSP instead? Also if I went that route, would it be acceptable to load a cfw so i could connect a controller to it and run psx ISOs on it? What could I get away with without verified runs being rejected by the community?
Joined: 10/12/2011
Posts: 6342
Location: The land down under.
CheesusCrust wrote:
Should I try to set something up for the PSP instead? Also if I went that route, would it be acceptable to load a cfw so i could connect a controller to it and run psx ISOs on it?
Yes to all that.
CheesusCrust wrote:
What could I get away with without verified runs being rejected by the community?
In my opinion you should start with what was available in the store then go to the route of games that never came to the store.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
Should I try to set something up for the PSP instead? Also if I went that route, would it be acceptable to load a cfw so i could connect a controller to it and run psx ISOs on it?
Yes to all that.
Alright well my birthday is next week so I think I'll buy myself a psp (I've wanted to get another psp anyways). Also I still have an a/v cable, memory card, and some other misc psp stuff laying around.
I will report back once I decide how to control it with an arduino. I know with homebrew you can connect a PS3 controller to it through USB, but I would like to see if I can connect something like a MadCatz wired PS3 controller to it (in my mind it should be easier to modify).
