Super Aladdin Live

The final line is telling.
"
The information provided here (as it was from the beginning) is to provide awareness to a possible problem and one possible solution. Testing on these two chips was done due to the number of requests and confusion about them. It is not here to defame any particular modchip teams (as far as I am concerned they achieved that on their own with the manner they responded to the topic). Smartxx have released a product which apparently deals with this issue, so I have not tested it here. Aladdin chips do hold the line low and since this hasn't been disputed I havn't seen the need to spend time showing it.

As stated many times throughout the thread CUTTING THE TRACE IS DONE AT YOUR OWN RISK and can damage the motherboard if not done carefully."
POSSIBLE problem...
Cutting a trace is risky.
Basically we've got a risky solution to a problem we don't even know exists. (It's been quite a few years. We would know by now if it did.)

 

Or upgrade the Aladdin, which you can do for free. As I've said all along. No trace needs to be cut then.

 

Don't you have to use a JTAG programmer to flash the lattice?

 

You can make your own or buy one, benny gave the schematics for the programmer in the thread that he released the upgraded CPLD code. The USB ones are like £16 on ebay.

Also some universal programmers support SVF playback, assuming someone already has that. He released the code as a jed, but I could upload the converted SVF or VME file for playback.

I also offer the chips preflashed if someones just looking to buy a chip (xblast or just the stock 256kb with upgraded CPLD). Or you could even buy a programmer and offer them pre upgraded via your tutorial and do a public service (and make something from it while you are at it), seems win-win to me.

 

Now it all makes sense.
In no way is that free to anyone... but you sell it. I get it.

 

I sell maybe a couple a month tops at £6 per chip. You have cracked it, well done.

 

I'll gather up all my Canadian heritage here and try to bring back the situation to a friendly state here!

Even if the MCPX isn't breaking down on 1.6 with modchips, it's a electrical evidence that forcefully grounding a signal line sourced from a device not designed to provide current but rather logic levels on high impedance lines is very bad. There are varying degrees of quality and circuit protections on logic ICs. Maybe nVidia went all out when designing their south bridge and made that thing super robust but everything has a breaking point. Just like a car, even if the engine was designed to withstand constantly running at 7000RPM, we can all agree it's not a good idea to do so if you want to keep your car for a while. I feel this analogy is valid in our discussion here.

Back to the MCPX. The LPC bus is designed as an exclusively internal bus, unlike say Ethernet or the AVIP port. It's not cost effective to forge extra sillicon or add external circuit protection to such thing as it is not designed to be tampered with. I speak from experience here but you can witness this yourself when looking for high-end logic ICs like FPGA, CPLD and even most recent microcontrollers. Usually, they're designed to source very few mA max(but they can sink a bit more) and it's the PCB designer's job to ensure proper signal interface. In the Xbox and on revision 1.6(b) specifically, the IO lines of the LPC bus travel directly from the MCPX to the Xyclops chip.

Maybe it's nothing to be worried about but my money is on the fact that the MCPX does not have any type of protection on those lines. The output driver is simply saturated and this is a bad thing, speaking as an electrical engineer. Is it a cause for concern, I think so but there is no hard evidence this leads to breaking consoles. As I previously wrote, maybe there are no reported cases because the damage is very local and people just don't bother investigating when their Xbox either die completely or they are suddenly unable to boot stock ROM. It's not an issue that has been brought up very often in the past. Most likely because people with the knowledge about this that cared enough about it were mostly modchip makers. It's bad press to publicly infer that your devices can kill consoles in the long run and by the time most of them would start to show signs, those teams would have moved to the next generation. Only SmartXX made something about it because they released the OPX and the V3 when the 1.6 was in bloom and it was probably well known in the inner circle at that time. Xecuter most likely didn't do it on their X3CE and x2.6CE revisions because it would have pissed early adopters of their non-CE devices counterparts.

So, is it a cause for concern? Yes. From an electronic standpoint, it's a very bad setup and it's something to avoid at all cost.

Is it something to be overdramatic about? No. There is just no hard evidence of a console breaking down because of this.

The solution I implemented in my modchip code isn't perfect either but it's the best of the two, and by far. There's just no clean way of getting around this problem as I don't consider cutting traces on a PCB a clean way(as you introduce signal reflection, which is another kind of bad).

@bcfosheezy, it's a good thing to be skeptic but there are such thing as over skepticism. It's a recognized fact that the current LFRAME situation is bad but I understand you saying there is no cause for concern. But even so, it wouldn't be the right thing to do to hide this information to concerned people. Warning them but not be over dramatic about it seems like the sensible thing to do.

@Bad_Ad84, I understand your desire to make the right choice and steer people accordingly but the data on field isn't there. At least it's not tangible enough to "stop the presses". Sure there are better way to handle LFRAME but saying that grounding LFRAME is plain bad and should be avoided at all cost isn't necessary in my opinion.

EDIT: Oh and yeah, modding the Aladdin with my code isn't free for sure. You have to buy a flash chip which is a bit expensive. The JTAG programmer is also necessary but if you're in electronics and want to go a bit further, buying something like a FT2232H breakout board (which can program CPLDs using urJTAG software) will serve you immensly for other projects. If it's solely to mod 1 Aladdin XT, then yeah, it's not worth it that much.

 

Let's be fair, this all went off on a tangent when he was trying to be a smart ass when I stated there are reasons people might want to install a chip on a <1.6 console.

The lframe thing was secondary. I just take exception to posting a guide and claiming it's right because "it works for me" or even "me and everyone I know" as to the reason why it's accurate, when it's actually bad practice.

Sticking to specs is how things work for everyone and basically avoids people having issues. This is the standard guides should be written to. Look at all the crap video mod guides that get followed blindly and don't work or are too bright or what ever else. It then takes years before those guides impact finally get fixed when someone does it properly.

Modding circles are full of poor mods and only education will improve it. I get plenty of people asking why x or y mod/console doesn't work and it's because of some poor guide written by someone with no knowledge on the subject, but it "worked for them".

Yes, I could probably have handled this thread differently, but his first post trying to be a smart ass, then immediately calling someone a troll just because they disagree with you and all the "you are just wrong" posts had put me in the wrong frame of mind to be educational.

Edit:
No flash chip required for the other code you mentioned earlier in the thread - only xblast. Both of which I thank you for!

 

It went off on a tangent when you decided to attack me for provided information that is correct as we've just established. You have a problem with your ego, and all I've done is stand up for the truth. The truth is, there is a lot of alarmism, with no evidence to back up the claims. You stand corrected sir and your admission is not necessary. If you were correct, there would be piles of dead 1.6 consoles with grounded lframe. There aren't. As to the rest of the things you tried to reference, we're not debating those because you've already been proven wrong on them. That's why you're mad and still here trying to be correct about something... anything. The problem for you is that you're just not. You tried to drag a credible member in. Sure, he agrees with you more than me. That's not an issue though, because even he admits that there are no known issues. You're making a mountain out of a mole hill in an effort to be right about something. Get over yourself.

 

Sooooo....I personally like being able to boot into the M$ dash for certain reasons. So my best bet is to cut the trace to the xyclops and solder a resistor like seen in the chart posted earlier?

 

@bcfosheezy whoa there, I never said there was not known issue with the way LFRAME is handled on 1.6(b) boards. There is. The theory is there and i know from professional experience. No good electrical engineer would ever codone handling a logic signal the way it's currently done. It's just that it's the first and most popular way that was introduced and sticked around. It's by coincidence that it works and does not seem to harm consoles in the long run. It doesn't mean it's the best way to do it though. There are better alternatives to grounding. They're not perfect but they're better for sure.

It is true there is no cause for alarm. As you point out, we're not drowning in piles of dead motherboards. It doesn't mean this information is pointless and alarmist. People will do what they want with that information. Some won't care, like you. Others, who want to go the extra steps to prevent potential issues, like @Bad_Ad84 have the right to be informed of it.

And it's not about him selling modchips, seriously. The price he sells those modded Aladdin XTs is very reasonnable, taking into account the cost of the extra parts, time spent programming, testing and handling customers orders and inquiries.


I don't want to get dragged in this any further. This argument has already turned into a flame war.



@ToXZiN 1 You know you can still easily access the stock dashboard without having to boot from the stock ROM? The dashboard executable is located at C:\xboxdash.xbe. Most custom dashboards have dedicated mechanism to create a launch entry to it. Even so, there isn't much you can do in the MS dash that you cannot do in a custom dashboard. IMO the single reason to retain the ability of loading the stock ROM was to get on Xbox Live so it's quite pointless nowadays!

If you still want to do it, I suggest to "cut" the trace using a very small drill bit and turn it by hand square on the trace you want to cut. It's a safer approach to running a X-acto knife across and risk slipping onto other traces!

Before doing anything, ensure you can positively test the conductivity of the trace you're about to cut between 2 vias. Sometimes, the vias are partially covered by soldermask which prevents the multimeter probes from making good contact with the metal of the via, making you think you succesfully cut the trace when it's not the case. Get a base reading, start "drilling" and check periodically (visual inspection with magnifying tool and multimeter) if that did the trick. If not, drill a bit further. You don't want to drill too deep and risk shorting the inner layers of the boards together (don't worry, you've go a millimeter of fiberglass at least before getting there). A cut trace should give you a resistance reading of over 10 kohms at least but it's probably higher.

You can also try heating up the trace using a soldering iron and gently swiping over the trace when the area is nice and hot. The heat will help loosen the epoxy that olds the trace on the fiberglass board. I still prefer the drill method though as you can slip with the soldering iron as well and damage surrouding traces.

 

If you didn't want to be dragged into it, you would have not posted. Bad_Ad84 turned it into a flame war. I tried to avoid it, but he is insistent. Now you are too. You're saying you have no evidence to point at supporting that you're correct, but still insisting that you're correct. If you were, there would be something to show for it. The case is closed on that. It really doesn't matter what you say about it after that. I respect you and the work you've done, but logic is simply not on your side. If it were something worth cutting traces over, there would be some consequences if you didn't. There just aren't... and it's been over a decade. We would know by now. So your insistence that there is a better way is quite obviously nonsense. The argument from authority is a logical fallacy. "No good EE would". We don't have to be electrical engineers to see that if something has worked properly for 10+ years, that even though we've found something we think might be a flaw, it's not worth "fixing" in a non mission critical system. Once you get beyond theory and get into practice you'll realize that. That's the same reason Team Xecuter didn't actually fix it with their firmware. There were consequences to the "fix" after they had already launched their product that nullified fixing a problem that doesn't exist.
The problem you all have is, you're saying you're not alarmists, etc... but you're saying to cut traces potentially damaging the board, or to jtag program your chip which costs money, or to buy your products.... to fix a problem that nobody has any examples of having.
Bad_Ad84 has went as far as to attack me for pointing out that there are no known examples. Like if he attacks that first, that somehow it makes that a moot point. It's not. It's quite obviously the most significant point. There is simply no sense in solving a problem that doesn't exist. You both know better.