UTF-16LE, no BOM?
No BOM needed; USB requires Unicode so there’s no need to mark that Unicode is coming. The language subset is hard coded for english, so I’d just stick to basic printable english/ascii characters with nulls in between for simplicity’s sake. All of my attempts to use non-english unicode have failed miserably.
Here’s the full breakdown of all 256 bytes:
0x00: ‘C’ character, always. It’s used as a flag to show that the eeprom has been properly programmed and contains valid data.
0x01: USB PID, high byte
0x02: USB PID, low byte. This ID should be changable, perhaps automatically hashed value from the USB string or a random value. If the USB string changes, this MUST change as well otherwise the new text wont be shown on PCs that its been plugged into before
0x03: unsigned byte for number of bytes in the USB string+2. Equals (( Num of ascii chars * 2)+2). So if the string is ‘Kitty’, value should be 12. Unsigned.
0x04: Should equal 0x03, always.
0x05-0x7E: Space for USB string. So if the string is ‘Kitty’, 0x05=‘K’, 0x07=‘i’, 0x09=‘t’, 0x0A=‘t’, 0x0C=‘y’, All of the rest in this range would be nulls/0x00.
0x7F: byte flag to indicate type of board. 0x01 for TE Kitty, 0x02 for VLX Kitty.
0x80-0x87: Button mapping for: Unused
0x88-0x8F: Button mapping for: PSX
0x90-0x97: Button mapping for: GC
0x98-0x9F: Button mapping for: NES
0xA0-0xA7: Button mapping for: TG-16
0xA8-0xAF: Button mapping for: Saturn
0xB0-0xB7: Button mapping for: SNES
0xB8-0xBF: Button mapping for: 3DO
0xC0-0xC7: Button mapping for: PS3/PC
0xC8-0xCF: Button mapping for: Unused
0xD0-0xD7: Button mapping for: Dreamcast
0xD8-0xDF: Button mapping for: Unused
0xE0-0xE7: Button mapping for: Unused
0xE8-0xEF: Button mapping for: Unused
0xF0-0xF7: Button mapping for: Unused
0xF8-0xFF: Button mapping for: Unused
The button mapping spots would get complicated to fully explain. For each batch of 8 bytes, just make them the pattern of 1, 2, 4, 8, 16, 32, 64, 128.
(for (i=0;i<8;i++)array*=(1<<i)
Just tested this during lunch and the Start + Back buttons do still functioned with Lock on the asian TE. Only the Guide button is locked.
Ordering very soon 
Prob should explain the button mapping eventually. Could add that feature to the app.
can you do this to regular MC Cthulhus? ;_;
should both the USB PID high byte and low byte be changeable or just the low byte?
update: I now have a “Jitty TE Edition” ! Managed to just change the K to an J, but hey that’s a start! BTW, should I be worried that it originally had TE in the string even tho it was a hex file for the VLX fix?
I’ll try it on my VLX tomorrow when I get a chance, but it looks right to my eyes.
There isn’t really a need; the USB string can already be altered using the command line program I put up a while ago.
They are put together to make a sixteen bit word, and that word value must change. If you change either or both, the word will change the the string will be read by the PC if that PID hasnt been used before.
whats the easiest way to know the starting point of the EEPROM in the hex file?
I know its right after “:0200000400F00A”, but I don’t know what that line is means and if its something that could just change in a future fw update.
The ‘:02’ is a command that says ‘change the bank I’m talking about’, and the one before the eeprom data “:0200000400F00A” will always be that exact line. You are safe to use it as the marker for where to start, just make sure to only pay attention to lines starting with ‘:10’, and don’t go past any other ‘:02’ that may be present below it.
But to be perfectly honest, I dont think the order of the entries in that hex file are going to change at all. Make it as hacky as you want.
Heh, right after I posted it I just figured out what it means.
I think I’ve read up enough on the intel hex format now to start getting things in gear.
Toodles…
What’s a step up converter that you would suggest to pair along with the TE Kitty board? I’m looking to install a step up converter to BOTH take advantage of the Turbo panel light up LEDs that do not currently work with the PSX/PS2 3.3 voltage (as I imagine they then would?), AND prime my TE for the nearly complete Sparks inductive?
I am using a plexi top replacement for my TE, and the version I use is without a bezel which reduces the space inside the stick a bit because the panel is not raised up by the bezel. Is the fit in a regular TE extremely tight? I probably have about 1/4 to 1/2 of an inch less to work with.
I have a friend that was asking me if I could mod his stick, but what he wants is a stick that has 360/PS3/DC support via a split at the end rather than seperate cables. So it would branch into USB for PS3/360 and a DC connector. What would be the easiest way to do this with a Kitty? Can you use the RJ45 jack for the PS3/360 support or do you have to do that through the screw terminals? If you can do it through the RJ45 can you simply share the necessary pins in the connector between both the USB and DC ends at the same time?
Hope that makes sense.
I installed a TE with spacers both underneath and between the Kitty board, which actually raised both the Kitty & mc PCB @ 3/8" higher than a normal Kitty install, and it clears just fine. In fact, both my boards sit completely recessed under the black shell, and still no clearance issues (however a tight fit). So installing a Kitty as is into a TE without a bezel is fine. Unless there was something you’re not mentioning, going without a bezel only lowers the panel 1/8" tops, not 1/4" & certainly not 1/2". You’ll be fine; go for it.
Thanks.
Umm…failed how? You mean as far as dealing with the characters in your CLI util? If you used this section for the USB string (contains Japanese) does something bad happen?
:0200000400F00A
:1000000043A082F603753059307E30AB55368320DD
:1000100000000000000000000000000000000000E0
:1000200000000000000000000000000000000000D0
:1000300000000000000000000000000000000000C0
:1000400000000000000000000000000000000000B0
:1000500000000000000000000000000000000000A0
:100060000000000000000000000000000000000090
:10007000000000000000000000000000000000027E
:100080000102040810204080010204081020408072
:100090000102040810204080010204081020408062
:1000A0000102040810204080010204081020408052
:1000B0000102040810204080010204081020408042
:1000C0000102040810204080010204081020408032
:1000D0000102040810204080010204081020408022
:1000E0000102040810204080010204081020408012
:1000F0000102040810204080010204081020408002
:00000001FF
I guess it might not display correctly if you lacked the necessary fonts, but I can read/write them from the USB string just fine.
> There isn’t really a need; the USB string can already be altered using the command line program I put up a while ago.
SAUCE ;__;
Making some headway. Got a simple app to load the hex , make changes to the string, and then save the new hex.
I’m using random values for the USB PID high and low values, but the name isnt changing in the game contorllers dialog. Any help?
I know the hex file is valid as it flashes to the MC just fine and is able to load correctly into a PIC programmer app.
Added the ability to update the firmware through the app. Although I don’t know if its effected by that admin stuff. It runs fine on my XP setup.
Can you explain the button mapping now?
Vista/Win7 has UAC, and that should cause a problem. If you’re running the firmware update app with ShellExecute I believe you can make Windows ask for elevated permissions on those platforms by using “runas” as the value for the lpVerb param.
Alternatively, write a manifest that’ll make the app itself cause the UAC prompt. See this for a bit more.
Tested on Win7 with UAC all the way up and it was able to run the firmware update app.