There is no doubt the address move up to FF9090 makes a difference to the good, I did jump up to FF9890 for a quick test and it responded the same as it does at FF9090.
I've returned it to FF9090, I didn't waste time trying to refine it further at this point.
As for submode 00 or 80, they work the same for me.
[03:28:49:253] TX: 3680051CFF9090 ... Wacked data off.
[03:28:50:548] RX: 6D F0 10 76 00 78
[03:28:50:549] Found response, Success
[03:28:50:549] Kernel upload 100% complete.
[03:28:50:555] TX: STPX H:6C10F0, R:1, D:3D00
[03:28:53:853] Empty response to receive. That's not OK.
[03:28:53:968] TX: STPX H:6C10F0, R:1, D:3D00
[03:28:54:020] RX: 6C F0 10 7F 3D 00 11
[03:28:54:030] Kernel Version: 00000000
[03:28:54:038] kernel uploaded to PCM succesfully. Requesting data...
[02:54:39:066] TX: 3680051CFF9000 ... Wacked data off.
[02:54:43:651] Empty response to receive. That's not OK.
[02:54:43:660] Sending 'test device present' notification.
[02:54:43:667] TX: STPX H:8CFEF0, R:0, D:3F
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
damn you gampy beat me to it, what did you modify to get it to read kernel
yeah going to end up needing a read kernel and a write kernel. once things get rolling kernels can always be rewritten to shrink them down and be more efficient
if we could move chip id away from kernel and use the osid to identify it that would defiantly free up some kernel space. As the program expands pcms we are going to have to start using different kernels and ID methods for different pcms. I like the pcminfo.cs since it allows for alot of that easily changed for different pcms just need to add more variables into it.
Good work! I think we need a kernel that implements mode 36 with 00 and 80, so that we can use it to send more segments. If it gets 36 00 it should just load, and if it gets 36 80 it should load and jump to it. That would be the smallest kernel we can upload, and we can then send more chunks for larger kernels. How small we can make that first kernel will be the minimum packet size required for P04.
Vampyre wrote:if we could move chip id away from kernel and use the osid to identify it that would defiantly free up some kernel space. As the program expands pcms we are going to have to start using different kernels and ID methods for different pcms. I like the pcminfo.cs since it allows for alot of that easily changed for different pcms just need to add more variables into it.
NSFW i love how modular you made the program
The problem with this, as far as chip id is concerned, is we dont have all the data to do it by OSID. We are relying on users sending us debug logs with the information from the kernel. We can probably figure a lot of it out based on hardware IDs but its going to be hard with the number of OS and different hardware out there.
Before we decide to cut too much from the kernel, I think we need to figure out how much ram in the P04 - we may only need to slightly optimise the kernel. But I do think we should fork the P01/P59 kernel and keep trees for different kernels in the project. One code base for all isnt going to work well.
Hardware wise only 2 dif hardware numbers for P01 files are interchangable
P59 same 2 hardware numbers files not interchangeable
P04 2 hardware numbers ive ever seen all files interchangeable.
Ive got a tech2 if you want I can load different OS into pcms and see if it changes anything
beat me to it, what did you modify to get it to read kernel