Feb 15, 2010. | By: Dustin

[gallery ids=”461”]

Nothing much else to post for today. Jazz Jackrabbit makes it ingame now, but still having issues with the controller. If I can’t sort it out tonight then it’s back to work on XeDebug for abit.

Update

I’ve managed to sort out the controller issues. (Issue with threads, whoops ^_^). Now I’m down to two bugs. Dieing and beating the level both cause crashes. Not that huge of a bug, in terms of fixing. So hopefully if everything goes as planned then OpenJazz360 will be released tomorrow.

[gallery ids=”463,460,462”]

[Read More]

Feb 14, 2010. | By: Dustin

[gallery ids=”467”]

Well not too much to post today, but to keep with my goal of posting at least once a day I thought I would give everyone a little teaser. The screen capture above is from Xbox360 running through my capture card.

[Read More]

Feb 13, 2010. | By: Dustin

Well I’ve had more time to play around with my Skype Phone today. Pretty much all of the reverse engineering is done. Screen drawing, keypad input, and LED are all documented.

KEY_TopLeft1 = 00 01 01 00 01 01 01 01 01
KEY_TopRight1 = 00 01 0D 00 01 01 01 01 01
KEY_TopLeft2 = 00 01 02 00 01 01 01 01 01
KEY_TopRight2 = 00 01 0E 00 01 01 01 01 01
KEY_CenterUp = 00 01 13 00 01 01 01 01 01
KEY_CenterDown = 00 01 16 00 01 01 01 01 01
KEY_1 = 00 01 03 00 01 01 01 01 01
KEY_2 = 00 01 09 00 01 01 01 01 01
KEY_3 = 00 01 0F 00 01 01 01 01 01
KEY_4 = 00 01 04 00 01 01 01 01 01
KEY_5 = 00 01 0A 00 01 01 01 01 01
KEY_6 = 00 01 10 00 01 01 01 01 01
KEY_7 = 00 01 05 00 01 01 01 01 01
KEY_8 = 00 01 0B 00 01 01 01 01 01
KEY_9 = 00 01 11 00 01 01 01 01 01
KEY_Astk = 00 01 06 00 01 01 01 01 01
KEY_0 = 00 01 0C 00 01 01 01 01 01
KEY_Pad = 00 01 12 00 01 01 01 01 01
KEY_F = 00 01 1A 00 01 01 01 01 01
KEY_Mute = 00 01 1B 00 01 01 01 01 01
KEY_RELEASE = 00 01 00 00 01 01 01 01 01

Byte 1 - First Nibble
bit 4 = Backlight — Value 8
bit 2 = Red Light — Value 2

I started talking about the LCD in yesterday’s post, but seemed to have had a few mistakes in the documentation. These have been fixed in the first. I decided to draw up a little chart to help describe the block draw format of the Skype Phone even more.

[gallery ids=”471”]

Also I’ve managed to port a simple Chip8 emulator to the Skype Phone. Pretty much still an alpha version at the moment though. Due to it only draw to one fourth of the screen (64x32 the native resolution of the device.), but neither the less it’s a steps forward. Below are a picture of Blinky, PacMan clone, running. Sorry for the blurry photo. I’ll take a better one later

[gallery ids=”472”]
Source Code: http://www.digitalreality.co.nz/xbox360/dev/XeServer/USB_Phone.rar

[Read More]

Feb 12, 2010. | By: Dustin

Fuck.. I hate writing these. Ok well I’ve already written one blog introduction post straight up as hello, one as pretending to actually care about blogging, and the last one I was doing exactly this (Going on and on about how much I hate writing the first blog post).

So my handle is LoveMHz and I’m the lead programmer for XeLove. I also run a few other smaller groups outside of the Xbox Homebrew’ing scene, but that’s a story for a different day. Currently the only program I’ve released is XeDebug, but it won’t stay that way for long ;)

Well that seems like enough for an introduction post.. Now on to what I’ve been working on today. A few years back I purchased a USB Skype phone off of eBay, or simply named “USB PHONE” as printed on the device. Sadly since then I’ve managed to lose the drivers. No biggy right? Negative. Google’ing for the hardware ID and product vendor returned everything and anything but what I was looking for. That was pretty much the first half of my day.

The next few hours included resoldering the broken SMD mini USB port on the phone. Who’s idea was it to design a phone, use a SMD connector, and ONLY HOLD IT IN PLACE BY THE PINS.

Then the fun part, seriously. Reverse engineering the protocol. Now the way the phone works is quite simple. Included with the CD, remind you I lost this, is an application that draws the menus to the phone. So just a simple I/O situation. Too bad I don’t have the program. Would be as simple as capturing the USB data packets. So my idea was to bruteforce the first few bytes and see what happens.

After a few test runs I noticed that while the first byte was set to 3 it was only changing the LED and the screen’s backlight. Now while it was set to 4 it was changing the LCD data. After a few hours I came up with this.

OutputReport[0]  = 0x00; // Always 0.  
OutputReport[1]  = 0x03; // Type. 3 = Draw Screen. 4 = Control LEDs/Blacklight  
OutputReport[2]  = 0x00; // Unknown  
OutputReport[3]  = 0x07; // Offset Block Y 0 - 7\. 0 is bottom  
OutputReport[4]  = 0x40; // Offset Pixel X 0 - 0x70 or so. 0 is left side  
// To draw to the screen we must do it block by block.  
// A block is 7x8\. Each byte sent is a column. And each bit of that is a pixel.  
OutputReport[5]  = 0x00; // Pixel Data -- Left most column  
OutputReport[6]  = 0x00; // Pixel Data  
OutputReport[7]  = 0xFF; // Pixel Data  
OutputReport[8]  = 0xFF; // Pixel Data  
OutputReport[9]  = 0xFF; // Pixel Data  
OutputReport[10] = 0xFF; // Pixel Data  
OutputReport[11] = 0xFF; // Pixel Data  
OutputReport[12] = 0xFF; // Pixel Data  
OutputReport[13] = 0xFF; // Pixel Data -- Right most column

Now I haven’t exactly finished this since I still have to write up the docs for the keypad and the backlight/LED. More on that later and maybe some more source.

Postnotes Nothing much was found on the MCU, Holtek HT82A832R, besides the public datasheet.

[Read More]