nesdev.com
http://forums.nesdev.com/

Kazzo USB rom dumper / dev cart programmer
http://forums.nesdev.com/viewtopic.php?f=9&t=7912
Page 4 of 36

Author:  kyuusaku [ Sun Jul 03, 2011 11:40 am ]
Post subject: 

Image

This is my solution I posted this a while back, it makes programming easy. Alternatively you can use a single gate, a 1-bit MUX for either polarity or a '157 if you have multiple clock sources.

Author:  infiniteneslives [ Mon Jul 04, 2011 5:56 pm ]
Post subject: 

Well I've got some decent progress made with this in the past day. I've managed to fit everything from my original kazzo plus a FC connector and an additional D flipflop for some of the EXP pins. Everythings on a 2"x4" board with some tiny ass 6 mil traces for the signals.

I've had some thoughts and questions I need your guy's feedback on though:

*AVR Programmer connection pinout: This isn't necessarily applicable to everyone. But if people are looking to play around with the firmware or if we came up with our own upgraded version of the firmware it might matter. The best standare I've found is like sparkfun's programmer: http://www.sparkfun.com/products/9825 I think thier pin out is similar to what I've seen most often in a 3x2 male header on our board. It's not what my programmer uses but it's something that's easily adaptable if it were a problem for someone outside of the norm like myself in the future.

The main thing I see that would require someone to have a firmware upgrade is making use of the EXP pins. I've provided access to them as I discuss below. But I haven't made any changes to the firmware to make use of them. It was easy for me to provide hardware that allowed improvements in the software to use said hardware. The only added cost is a 50cent Dflipflop that could be left out if one chose. I'm planning to also include IC socket strips for the MCU. That way someone could pull off the chip and send it to a freind who could flash it for them without shipping the whole board. The IC strips are cheap in larger quantities so I figure why not.

*CHR /A13 bug: I've talked about this earlier but here's the issue. I think the fix to use the /Q output instead of Q may backfire. It's kinda silly for the code not to address it as an active low signal, and we shouldn't be using hardware to fix code. Also if the code were to make it active low it would have allowed for using 1-2 74HC374 (octal single O/P tristate D flipflops) vice 3-4 74HC175 (quad dual O/P resetable D flipflops). I would have liked to use 2x 374's using the first for the same design as the official kazzo (upper Addr bits) And then use the second to reach all EXP pins.

I was going to play around with the source code but I wasn't sure of the extent of the bug without digging in deep and testing some things I currently don't have the ability to test. Is it just an issue with Dumping or is it Flashing too??? IDK... It puzzles me why this isn't an issue if the original schematic didn't have issues. Perhaps it's something to do with NES/FC differences but I don't see how.
* That gives me an idea though * I should go recompile the source code and make sure they aren't just distributing an old version of the .hex file that I used to quickly flash my MCU. I'll have to get back on that I guess.

My solution was to provide a jumper on the CHR /A13 line to allow the user to select between the active high or active low (Q or /Q output of the flipflop) That way it would work now with the firmware available and if/when the bug gets fixed it would be as simple as swapping over the jumper if one chose to upgrade to the new debugged firmware.

*EXP pins: So I had 5 free pins on the MCU and 10 EXP pins to play around with (2 unused sound pins on the FC)

Here's what I did:

AVR EXP FC
PD0 Directly to EXP0 pin 45
PD1 Directly to EXP1
PD6 Directly to EXP6 pin 46 (Sound out) My understanding is these pins are similar on both systems so I paired them)
PD7 Directly to EXP2
PC3 XHL: EXP high latch signal (similar to the current AHL:address high latch but for the EXP pins vice upper address pins)

XHL clocks an additional 175 D flipflop to provide addressing below:
Data bit EXP (the order is a little messed up from providing EXP6 with it's direct pin to the MCU so I just picked up the slack here)
D0 EXP3
D1 EXP4
D2 EXP5
D3 EXP7

EXP pins 8 and 9: I didn't have a direct use for these. I figured it might be nice to have a way to get high voltage on the board for some EPROM programming abilities. So I provided some pads off to the side of the board with EXP 8, 9 and GND in one continent location.

Writing this all out I'm starting to wonder if this would make more sense if EXP were being used as a bus, you would just mask the proper bits with everything matched up in order: (from an avr coding standpoint you would just write the byte to both ports and toggle the XHL pin to get your byte on the EXP bus simply)

AVR EXP FC
PD0 Directly to EXP0 pin 45 (Sound in)
PD1 Directly to EXP1
PD6 Directly to EXP6 pin 46 (Sound out)
PD7 Directly to EXP7
PC3 XHL: EXP high latch signal (similar to the current AHL:address high latch but for the EXP pins vice upper address pins)

XHL clocks an additional 175 D flipflop to provide addressing below:
Data bus EXP (now the order is straightened up a bit)
D3 EXP3
D4 EXP4
D5 EXP5
D7 EXP7

There's no good reason not to do it this way so I think I'll make the simple change. Unless someone has a better suggestion.


One last thing: I was thinking it would be nice to have this thing in a case. I picked up a little black project box from radio shack for around $5. http://www.radioshack.com/product/index.jsp?productId=2062281 It's 5"x2.5"x2" LxWxH. I wish it was only 1" high but I won't have to mess with the board much to fit it in there with proper mounting holes. A cart would be a little deep in there ~1.7" due to the depth of the box but it looks like the best choice. Then if you wanted to use the lid all you'd need was a slot for the cart and a hole in the side for the USB cord. I figured these would be easy for people to pick up themselves. I could resell them for $5 as is or I might think about pre cutting them for people (w/ drill and dremel) for an extra $5 a box.

The only issue I see with it is use of a FC cart. you would have to chop off 2 of the 4 drill posts that are used to screw down the lid. It would still work well, or you could come up with your own solution but the mounting holes would be designed for that box specifically.

I've yet to reroute the board with the components moved around to make best use of the box but I don't suspect much trouble. I'm also waiting to hear back from the board supplier to find out some more details on his minimum requirements. But I think it's entirely possible to make an order by the end of the week still. The only thing that may hold me back is receiving my own repropaks from retrozone. I would like to test them in the connectors if possible and it doesn't appear that my stuff got shipped before the weekend.

I'm not in any real time crunch here other than saving you guys $5 on the board cost if I place the order by the end of the week. But it also doesn't look like we've met the 6 required to get the lower rate yet anyways... I've yet to get any emails which is okay because I'm not quite ready to bill people but here's my current list of interested people:

People Interested:
qbradq (and possible coworkers)
OldNESJunkie
Memblers
Tepples (would like devcart as well, still much work to be done here)

Board only:
SkinnyV

So in conclusion while it may be possible to order them this week and save everyone $5, it may be better in the long run to wait another couple weeks before making an order. I'll let you guys drive this decision though, if you give me your input.

Author:  Memblers [ Mon Jul 04, 2011 8:42 pm ]
Post subject: 

You should try to put a bootloader in there, I couldn't find one on Atmel's site, but there is this one: http://www.fischl.de/avrusbboot/. Maybe my Willem can program it, but the board's existing USB connection should be enough.

I'm not sure why the MCU would connect to the audio pins, it seems like only an ADC and/or DAC would be usable.

Please try to keep this pinout in mind, too:
http://nesdev.com/bbs/viewtopic.php?t=7313
Other than the audio and CopyNES mapper disable pins, nothing ever used expansion port. So I proposed that standard, there is still time to revise it if needed. I'm just saying, I don't want to see the cart interface done in a way that could possibly damage stuff later. The same situation could arise if carts were made to a different standard and plugged into an NES that had an expansion board connected.

I'm not in any big hurry to get it, really I'd rather have it when the firmware is finished (or includes a bootloader), so I don't have to bother with more programming adapters.

Author:  infiniteneslives [ Mon Jul 04, 2011 11:49 pm ]
Post subject: 

I like the idea of the bootloader. Looks like that would only use up one more pin. (Used to tell the MCU to switch to bootloader mode.

So if we started from scratch we would have 4 pins left. Then assuming we have one used as XHL to I/O extend, we've got 3 pins left that we can run directly to the EXP pins.

Memblers wrote:
I'm not sure why the MCU would connect to the audio pins, it seems like only an ADC and/or DAC would be usable.


I didn't really intend for it to be used for sound. Since how the FC carts don't have any extra pins hanging around and most games don't use the sound pins I figured a developer may want to use the sound pins for other features like mapper disable which would seem highly desirable for someone developing on UNROM or whatnot. We could connect them to ADC into the AVR and that wouldn't take a pin since how we weren't using that one anyways. You're the only one that was asking for FC connector though Memblers, so I'll most likely do it how you see best. One free option could be to provide solder jumper for selection of analog or digital input to the MCU.

Now for everything else here's what you've came up with previously:

Memblers wrote:
Regarding the expansion pins on NES cartridges, that normally aren't used. It's time to use them, here is what I'm proposing:

Code:
EXP0: in - CopyNES mapper disable
EXP1: I/O - CAN bus H
EXP2: out - A0 (PRG)
EXP3: out - A1
EXP4: out - A2
EXP5: out - /CE for parallel port device
EXP6: out - audio out
EXP7: Ground
EXP8: I/O - CAN bus L
EXP9: out - PRG R/W


Originally I thought I would use EXP7 for audio in (from the NES), it'd be nice to have but I'm not sure it's needed. So I put another ground there, to give the CAN bus some help (and maybe hope for higher speeds).

This standard would apply to both expansion port devices, and NES cartridges (and requires both to work, of course). So I'm curious if anyone has any thoughts on it, or other alternatives.


I think we're all agreed to make EXP0 mapper disable, and since I see this as a common "multiuse" pin I think it would be good to give it one of the 3 pins we have left. Leaving us with 2. (This is what I also wanted to assign to FC "audio in" pin 45)

If someone were actually making use of the CAN bus then you'd like it to be I/O for the MCU. So those could be the last two free pins. (EXP1 and EXP8)

And if you were thinking EXP7 as an additional ground then it would be a good candidate for not being assigned. Just leave a connection for it on the side of the board for the user to do whatever they please.

This leaves EXP2,3,4,5,9 and EXP6 which is already made use of with Audio out, but that doesn't mean someone couldn't want to use it for something else.

So I'm trying to see how to best integrate what I have with what you have in mind here with what we're doing here. By "out" I'm assuming you mean out of the cart and "in" whatever's connected to the EXP bus. Your assignments are all OUT when I was thinking of them as more of an IN. The real difference here would be using a shift register vice d flipflops (or just tieing them to the data bus which sounds like a bad idea)

While I can see why it would be OUT for use in a console, I can't see why they would be anything but IN for a dev cart. I'm thinking of using a octal D flipflop with tristate outputs. That way we could reach the rest of the pins and have some flipflops left over for something else possibly. The use of tristate outputs would allow them to be invisible to the cart, to prevent any issues if the user wanted to do something completely different there wouldn't be any damage. Granted the /OE of the flipflops would then need something to drive it (MCU pin, switch, or jumper) I would lean toward just placing pads on the board that we would plan to solder bridge for now, but could be used to implement a switch or something else in the future.

I know it may seem like we're scope creeping a lot here. But these EXP pins are really of little to no cost right now, aside from talking. If we're smart with them now a few of these simple things would really open up possibilities for what someone could do with this thing in the future. So if you've got an idea/opinion lets hear it! I have a feeling we'll end up pushing a few weeks until I can test out the retropak boards and bootloader anyways which I think would be fairly important to most of us.

Author:  Memblers [ Wed Jul 06, 2011 4:06 pm ]
Post subject: 

Previously I've used bootloaders that always check for active communications when powering up, but using a switch for it sounds OK too. The former method I've done over RS232, I don't know if going through USB would affect things.

Quote:
I didn't really intend for it to be used for sound. Since how the FC carts don't have any extra pins hanging around and most games don't use the sound pins I figured a developer may want to use the sound pins for other features like mapper disable which would seem highly desirable for someone developing on UNROM or whatnot.


Problem is that they are always used. When there's not a sound expansion, the audio in and out pins are shorted together to pass the audio through.

But yeah, if there's an ADC pin free, then connecting the audio out couldn't hurt anything. Anyways, if I make an FC dev board, the mapper registers aren't going to overlap memory, so nothing special will be needed.

Quote:
While I can see why it would be OUT for use in a console, I can't see why they would be anything but IN for a dev cart.


Right, there are a lot of outputs from the cart. You probably know that the data bus is shared with the exp port, so when the cart is in the NES there is plenty of I/O since this standard provides the /CE and even some address lines. Other than the mapper disable, I just can't imagine what kind of input a cart could possibly use though, when it's outside the NES. Maybe in-circuit programming for an MCU or CPLD, but stuff like that I believe is better served by adding a dedicated connector to the cart and leaving the EXP pins free. Such as the programming voltage you mentioned, it makes more sense (IMHO) to have it on another connector instead of through the EXP connector. Mostly since it's all more of a one-time use thing (when initially building the cart) that is pretty boring for normal users. But programming voltages are a thing of the past, that would have been more useful 20 years ago instead of today, heheh. In fact, I believe there were some Atari 2600 carts (I wouldn't call them dev carts, more like homemade OTP bootlegs) where the cart does plug into a stand-alone programmer to burn an onboard ROM.

No big deal what happens with the exp pins on this interface really I suppose, sounds safe enough with the tri-state buffer. If there are some I/Os from the MCU left over, I'd hook them up to some status LEDs or something. Everyone can appreciate some blinkenlights. :)

Main reason I'm so concerned over the EXP port, is that no one else has yet to use it for anything (other than CopyNES in rare cases, and PowerPak sound more commonly, and that dumb unreleased gambling modem thing). The cheap dev cart I'm making will use them however, I just want to make sure if people want to use it with an interface like this I don't have to give them special firmware to do it, or tell them to move jumpers around, etc, sorta defeats the convenience of it all. I don't think people would be too thrilled if the first real use of the expansion port includes multiple standards :/

And yeah maybe that GND connection could be unassigned. I'm just overly paranoid about getting noise in the audio, so I put it next to that. Keep in mind these EXP port signals are planned to come out (with the rest of the EXP signals) on a 50-pin IDC cable (with multiple ends!), which could be kinda long-ish. Since we can't easily fit a board underneath the NES without some kind of fancy physical supports.

Author:  SkinnyV [ Wed Jul 06, 2011 5:29 pm ]
Post subject: 

At this point I will probably change my mind and go for a full kit instead of just a PCB so you can put me down for one.

Author:  infiniteneslives [ Thu Jul 07, 2011 12:02 am ]
Post subject: 

Memblers wrote:

Problem is that they are always used. When there's not a sound expansion, the audio in and out pins are shorted together to pass the audio through.

But yeah, if there's an ADC pin free, then connecting the audio out couldn't hurt anything. Anyways, if I make an FC dev board, the mapper registers aren't going to overlap memory, so nothing special will be needed.

No big deal what happens with the exp pins on this interface really I suppose, sounds safe enough with the tri-state buffer. If there are some I/Os from the MCU left over, I'd hook them up to some status LEDs or something. Everyone can appreciate some blinkenlights. :)




Yeah I agree with what you're saying here. I didn't really see a large use for the EXP pins aside from mapper disable. But I figured if there was board space why not atleast provide the pads on the board for someone to make use out of the EXP pins.

I was kinda thinking along the lines of MCU/CPLD programming too. And you've got a good point about an external connector being better suited. I don't think it would necessarily have to be a one time use though. If someone were using it as a dev cart they may want to program things often. I just thought the idea of using the EXP pins would be nifty, atleast to be available anyways.

Quote:
Main reason I'm so concerned over the EXP port, is that no one else has yet to use it for anything (other than CopyNES in rare cases, and PowerPak sound more commonly, and that dumb unreleased gambling modem thing). The cheap dev cart I'm making will use them however, I just want to make sure if people want to use it with an interface like this I don't have to give them special firmware to do it, or tell them to move jumpers around, etc, sorta defeats the convenience of it all. I don't think people would be too thrilled if the first real use of the expansion port includes multiple standards :/


I'm onboard with the multiple standards. Maybe the best answer is to only standardize the pins already used with copyNES, powerpak, and sound.

Then the standard for the rest of the pins should be more of "rule" like the pins should be able to be grounded without damage. So something like the use of tristate outputs would satisfy this.

I like the blinkly lights idea... I'll have to think about how that could be set up. Maybe if there one were able to have LEDs on the outputs of the Dflipflop I was already using for the EXP pins. I don't know if I want to devote board space to this especially if someone were to mount it in a box they wouldn't want them on the board anyways. Maybe just provide a row of pads on the board for all the EXP pins. Then that would make it easy to add whatever you wanted LEDs, programmers, external devices, whatever your heart pleased.

@SkinnyV I'll plan to get you the full kit.

Well no one's had any gripes about delaying the Kazzo board order, so it looks like the delay and $5 isn't a deal breaker for anyone. So I want to wait until my retrozone boards show up to test the connectors and play around with a simple Flash/dev cart amongst other things left to play around with. My goal is to order everything by the end of the month. I'm expecting a couple weeks turn around time so I'd be looking at shipping kits mid August. Feel free to bump the post if you want an updated status.

And if others becomes interested in a kit the price may be able to come down based on the components. I suspect more people may be attracted with a little devcart testing, so I'll post up my progress as it happens.

Author:  qbradq [ Thu Jul 07, 2011 5:29 am ]
Post subject: 

Wow, there's a lot to miss in six days :D

FYI my co-workers are a no-go. They did like the idea, but I get the distinct impression they'll be borrowing mine :)

I am confused on the CHR /A13 bit. Shouldn't this be high when accessing CHR-ROM? This should always be the inverse of CHR A13.

Please do include an ISP header on the board. That way folks like me can easily work on the firmware. Here are the standard Atmel Pinouts. The six-pin header is used in current products. The ten-pin header is pretty old. Also, please do not include actual pin headers soldered onto the board, just leave plated-through holes. That way we can solder on male or female headers to match our programmer hardware.

Please check out BootloaderHID. This is a USB-only self-programming boot loader using the same USB library that Kazzo uses (and therefore can be made compatible with Kazzo's hardware arrangement). Better still it communicates as a standard HID so there are no drivers to install.

Author:  infiniteneslives [ Thu Jul 07, 2011 7:27 am ]
Post subject: 

qbradq wrote:

I am confused on the CHR /A13 bit. Shouldn't this be high when accessing CHR-ROM? This should always be the inverse of CHR A13.


Yes exactly it's an active low signal. Now I'm not sure it it's always the inverse of CHR A13, because I don't know enough about where those signals are coming from. But the Kazzo gave CHR /A13 a separate signal from A13. Presumably because it uses A13 for the PRG memory also, so for the Kazzo atleast CHR /A13 is not always the inverse of A13 because it's basically CHR /CE.

The issue is when I wired everything up like the schematic asked CHR /A13 was acting as an active high signal. So my easy fix was just swap the signal to the inverted output of the flipflop. I've yet to spend time finding the bug location in the firmware source code to properly fix this.

As far as the 6pin header that was my plan and thanks for bringing up V-USB's bootloader, that's probably the one I'll be implementing.

Author:  infiniteneslives [ Sun Jul 17, 2011 6:04 pm ]
Post subject: 

Okay so I've made some forward progress here guys.

CHR A13 "bug" turned out to not be a bug at all. Really it was just an error in the labeling on some documents mixing up CHR A13 and /A13. Thanks to Farid for posting up his FC NROM schematic I raised the question and coincidentally found my error and fixed my board. I tested out after the fix and it works great. So that will give some more board space which will be nice.

We also were able to write a dumping script for NROM because there wasn't one. So it was nice to sucessfully write a dumping script even though it was a simple one.

We've also been researching on the Flash cart abilities. I found a guy who made a CNROM flash cart and he has a link to "backflips" NROM flash cart.
site: http://ponrevival.blogspot.com/2010/05/3.html
poor google translation: http://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Fponrevival.blogspot.com%2F2010%2F05%2F3.html

With this I was able to figure out some of the details about the flashing scripts and commands. I guess there was no need for mapper disabling because NROM and CNROM don't need it. With the CNROM he must have had CHR banks swapping all over the place while he was programming the PRG rom but when programming the CHR rom he must have switched the banks as needed via the normal PRG controlled bankswitching.

I still have testing out the bootloader, I've only been able to look into it thus far. But I hope have that working by the end of the week.

So aside from the bootloader the big thing left to iron out is testing out the dev cart programming abilities of this thing. I think I've got all the script details and wiring needed to be able to atleast test out a NROM devcart. I've got ideas of how to make a mapper disable to be able to support U/A/C/BNROM also making use of EXP0 as a mapper disable. Originally I though I might be able to use the repropak to do this. While it would be possible, it's really not wired up like I need it to be specifically for the /WR signals and making use of EXP0 and what ever hardware I add for mapper disabling.

I'm planning on making myself a "discrete mapper" devcart that would incorporate all this stuff supporting N/U/C/A/BxROM layouts. I would probably use a bunch of dip switches or jumpers to allow for all those layouts somewhat similar to the repropak. I was thinking about using battery backed SRAM because I need SRAM for A/UxROM and it would have to be battery backed for NROM etc. Now I could use Flash for the PRG rom but to keep things simple and similar on both sides I think I'll just stick with SRAM these could be in various sizes as well. I'm thinking 256KB for PRG and 32KB for CHR to support CNROM.

I'm basically looking at this as sort of a lite version of the NESDEV1 that we'll be working on over the next school year.

I was wondering if there was any interest in having me make up more of these to go with the Kazzo (or separatley if you had another use) Really I think Tepples was the only one who expressed interest but he may have been referring to the NESDEV1 with the large mapper capabilities making use of a CPLD.

I'm not certain on the cost of such a cart but the memory should be less than $10 and the board should be $15. A few dollars for discrete parts and shipping and we'd be looking at around $30 as a kit (WITHOUT cart plastics) and with the Kazzo kit included like $75 all together. But really this is around the target cost of the NESDEV1 without all the mapper capabilities. I don't want people to think I'm trying to sell this for my own gain. I don't really expect anyone to buy a simple devcart and dumper especially when most of you already have copyNES and the Powerpak which are vastly more capable than the Kazzo and simple descrete dev cart. I didn't really expect people to ask for the kazzo kit but you have, so I figure I may as well ask if anyone's interested in a dev cart to go with it since how I'm going through all the effort of making one myself it'd be simple enough to order stuff for more of them.

As far as schedule goes, I plan to use the next week to work on the bootloader and some simple devcart stuff. So I should be ready to order kits at the end of the month, as soon as I've got most everyone's money I'll order so assuming that doesn't take long we'd be looking at delivery around mid August.

One thing I was still wondering though, was anyone besides Memblers interested in the FC connector? (there is always the option of a 60 to 72 pin converter) Or any interest in the ability to put the kazzo in the box I found from Radioshack? I think I can make it work now that I can use smaller Dflipflops and only leaving pads for a programmer, but last time I tried to wire a board with a FC connector and clearance to put everything in the box I had issues. So I'd appreciate feedback on this and also the ideas about the EXP bus and everything. I'm leaning towards my earlier idea I posted of just leaving pads so you could wire up LEDs, jumper over to whatever EXP pin you wanted, or whatever your heart desired. But that comes at the cost of board space as well. So let me know what you guys value most.

Author:  SkinnyV [ Mon Jul 18, 2011 5:25 am ]
Post subject: 

I would be interested in having the space to solder a famicom connector. I always end up with pirate FC cart that I would be happy to have some way of connecting to the dumper without the use of an adapter. If you can find the space I think it would be useful for some. Look at Farid, he almost only deal with FC cart, so i'm sure some people would use it.

Author:  FARID [ Mon Jul 18, 2011 10:44 am ]
Post subject: 

SkinnyV wrote:
I would be interested in having the space to solder a famicom connector. I always end up with pirate FC cart that I would be happy to have some way of connecting to the dumper without the use of an adapter. If you can find the space I think it would be useful for some. Look at Farrid, he almost only deal with FC cart, so i'm sure some people would use it.


Thanks for backup :) yes I am only working on Famicom. By the way my name is Farid not Farrid :D

Author:  SkinnyV [ Mon Jul 18, 2011 1:18 pm ]
Post subject: 

Sorry, it was typo, I corrected it :lol:

Author:  infiniteneslives [ Fri Jul 22, 2011 1:00 am ]
Post subject: 

Good news!

I got the USB bootloader working just now. It works beautifully! Thanks for the input on adding this guys. I think I'll be including a bootloader on all my projects from now on!

For those unaware what this means: It's super easy to upgrade the firmware on the kazzo. You just plug it in via USB and close a jumper. It enters boot mode and then you're able to use a GUI to select new firmware and load it onto the device. So now you won't need a AVR Programmer in order to make use of any firmware changes. I don't really expect a need for this if you're just using it as a dumper. But it's especially nice if you're looking to do special things with the EXP pins or something like that with a customized dev cart.

Author:  SkinnyV [ Fri Jul 22, 2011 9:24 am ]
Post subject: 

I can see it was definitly worth the extra wait!

Page 4 of 36 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/