TI-84 Payload Collection

[remainnameless]

Yes, Those are the ones im currently using, and so far the best ones ive tested with 3.15, i use hermv4 on my 3.41. I believe oldcripple had a payload based on hermv1 (koko315)
there too, the first one i found for 3.15 with bm but no bdemu. Strange as it sounds i find i have problems with ftp file server copying to /dev_hdd0 with the pl315pl3 but using koko315 i have no issue.

Good to know. You should move to Hermes v4b for your 3.41. Apparently, he copied the port1_config_descriptor.bin from Hermes v3 in that payload. He fixed it in Hermes v4b.

[alexsh]

Hi bro. I have a problem, the Hermes V4b not work for me. All others payloads work fine, but the V4b not work.

Sorry for my english

[PsP0327]

whats the difference between KaKaRoTos latest release and hermes v4 ?

[lodgechad]

Alright ill give v4b a try now and post back

Edit: I just gave hermv4b a try and it worked here, peek/poke, BM and BDEMU,

[remainnameless]

Hi bro. I have a problem, the Hermes V4b not work for me. All others payloads work fine, but the V4b not work.

Sorry for my english

Did you grab my compiled version from the first post? I tested it and it worked fine. What were you having a problem with?

[alexsh]

Ok bro. The first time, only not work. But now 3 times later, its ok!

I test 10 times more, and all good. Sorry bro, it is a great work.

Thanks for your post.

[remainnameless]

Ok bro. The first time, only not work. But now 3 times later, its ok!

I test 10 times more, and all good. Sorry bro, it is a great work.

Thanks for your post.

Don't worry about it. At least it works now.

[Kratos77]

Just wanted to reply back, yeah, I don't mind you removing the .bin files for this. I only included them because so many people were asking for a port1_config_descriptor.bin and, well, that's about as close as you can get with PL3. For a collection of TI files exclusively, indeed, there's no reason to keep them. Thanks for the credit.

Personally, I think I'll keep compiling the DEV versions. The ability to edit RAM may make for some interesting game hacking possibilities that extend the replay value of old games, though it's unlikely since Peekpoke is currently not a TSR you can bring up in-game via a keyboard hotkey (which would probably be a good idea, to avoid interfering with controller functionality). Still, it's no extra work for me. I've written a batch file that automates the entire process (it's an old DOS user thing, we batch everything we do ). Besides, mine's an SE, it's not hurting for space and won't be regardless of how many payloads I throw at it. So, I might as well include them all.

Oh yeah, I called them UPD at the time because they were some of the first payloads to enable updates on 3.15, but it's a lot of arrowing over and that's not what the new versions are going to be fixing, so I think I've decided to go with DEF for default. Less arrowing over, more generic label that there's no need to change over and over to match a feature. It's your call what you do with your builds, of course, but I thought it might be good if we could agree on a naming standard for the sake of keeping it simple.

P.S. In case you might find it useful, I'll include the batch file in my next compile. It's name is "m8xv.bat" and it does it's job quite well. I'll include a complete "files used" folder, just to make sure that everyone who wants my automated "payloads to 8xvs" converter has a copy. Feel free to leave them out of the archive, of course, because anyone who doesn't compile PL3 won't have a use for them.

UPDATE: Decided not to wait for the next PL3 update to release my PL3 payloads to 8xvs automatic conversion tool. Just in case a new version comes out and we're not around to update, and you don't feel like waiting for us:

http://www.mediafire.com/?8k3d5931sagjbfd

This includes compiled copies of the latest payload bins, so people can readily check it out (double click m8xv.bat and observe as the files are created almost instantly). Keep in mind, you still have to compile PL3 on your own, we can't distribute the SDK after all. This just automates the process of turning the compiled binaries into 8xv files.

WARNING: This contains NO error correction code. It's going to generate all 8 .bin and 8 .8xv files regardless of whether or not you supply the correct payloads for them. So, don't forget to delete any bogus files generated, if any, especially before uploading (if you didn't include the dev payloads, delete the DEV files, or at least don't include them in an upload). If in doubt as to which is which, check the bin in a hex editor, if everything beyond the first 32 bytes is zeroes, it's a bad file. No one wants a payload that's shooting blanks

[teltras]

Thanks for compile Hermes4b

Now it´s all running fine

This thread should be a sticky

[remainnameless]

Just wanted to reply back, yeah, I don't mind you removing the .bin files for this. I only included them because so many people were asking for a port1_config_descriptor.bin and, well, that's about as close as you can get with PL3. For a collection of TI files exclusively, indeed, there's no reason to keep them. Thanks for the credit.

Personally, I think I'll keep compiling the DEV versions. The ability to edit RAM may make for some interesting game hacking possibilities that extend the replay value of old games, though it's unlikely since Peekpoke is currently not a TSR you can bring up in-game via a keyboard hotkey (which would probably be a good idea, to avoid interfering with controller functionality). Still, it's no extra work for me. I've written a batch file that automates the entire process (it's an old DOS user thing, we batch everything we do ). Besides, mine's an SE, it's not hurting for space and won't be regardless of how many payloads I throw at it. So, I might as well include them all.

Oh yeah, I called them UPD at the time because they were some of the first payloads to enable updates on 3.15, but it's a lot of arrowing over and that's not what the new versions are going to be fixing, so I think I've decided to go with DEF for default. Less arrowing over, more generic label that there's no need to change over and over to match a feature. It's your call what you do with your builds, of course, but I thought it might be good if we could agree on a naming standard for the sake of keeping it simple.

P.S. In case you might find it useful, I'll include the batch file in my next compile. It's name is "m8xv.bat" and it does it's job quite well. I'll include a complete "files used" folder, just to make sure that everyone who wants my automated "payloads to 8xvs" converter has a copy. Feel free to leave them out of the archive, of course, because anyone who doesn't compile PL3 won't have a use for them.

UPDATE: Decided not to wait for the next PL3 update to release my PL3 payloads to 8xvs automatic conversion tool. Just in case a new version comes out and we're not around to update, and you don't feel like waiting for us:

Payload To 8xv Converter.rar

This includes compiled copies of the latest payload bins, so people can readily check it out (double click m8xv.bat and observe as the files are created almost instantly). Keep in mind, you still have to compile PL3 on your own, we can't distribute the SDK after all. This just automates the process of turning the compiled binaries into 8xv files.

WARNING: This contains NO error correction code. It's going to generate all 8 .bin and 8 .8xv files regardless of whether or not you supply the correct payloads for them. So, don't forget to delete any bogus files generated, if any, especially before uploading (if you didn't include the dev payloads, delete the DEV files, or at least don't include them in an upload). If in doubt as to which is which, check the bin in a hex editor, if everything beyond the first 32 bytes is zeroes, it's a bad file. No one wants a payload that's shooting blanks

That's the EXACT same batch I created and have been using, lol. I guess great minds think alike. The only difference in mine is instead of "msdos resize 3840 DEF301.bin", I did "msdos resize 3840 *.bin" to do all 8 .bin files in one shot.

It's a really good idea to include the tool. If myself or you can't get to it, HOPEFULLY this will simplify the conversion. I COULD create a Linux script that would compile the latest PL3 code that would create the .bin files ready to use the batch script. I may get around to it later on tonight.

I think that there are some cool possibilities that can be done with Peek and Poke, but we haven't really seen any yet. If you want to compile them, it would be cool if you keep a copy of them, sorted kinda the same way I did in the first post. I'll just send people your way when they need the DEV payloads. If for some reason Peek and Poke become something we need, I'll start adding them to the first post.

I'm probably only going to keep the 5 latest PL3 payloads on the first post, seeing as there probably won't be a reason to go back more than 5 revisions for anything. I will keep them archived, and if someone wants a certain version, they can PM me.

As far as the naming scheme, I think we will go with DEF for the default payloads and DEV for the dev payloads. That's the only logical naming scheme. If we keep everything uniform like the PL3 payloads are going to be, it will be easier for people to find what they want.

Thanks a lot for your input. Keep the stuff coming.