Creating a Development Kit (DVT-5)

[Bowlsnapper]

I figured, "Why not"? Maybe I can learn to code at least a little. I have a spare Halo Edition.

Need to build the serial debugger after I finish with the software side of this.

https://github.com/XboxDev/serial-usb-adapter

[corona2222]

nice work! What tutorial did you follow? (or are you writing a tut as you go we can follow?)
So far I've got the extra 64MB of chips ( which match the chip numbers on my xbox)
Is it just a case of solder each ram individually, load xblast on my OpenXenium and test?
Any other settings or hardware changes?

Edited March 31 by corona2222

[Bowlsnapper]

5 hours ago, corona2222 said:

nice work! What tutorial did you follow? (or are you writing a tut as you go we can follow?)
So far I've got the extra 64MB of chips ( which match the chip numbers on my xbox)
Is it just a case of solder each ram individually, load xblast on my OpenXenium and test?
Any other settings or hardware changes?

I'm probably gonna borrow from a few tutorials, one of them being the MVG video.

I will use the kernel debugger, since I have Cerbios installed on the TSOP and the LPC is free to attach the ribbon to. I will detail it here as much as possible. I will use a USB-C breakout and internalize the serial debugger, with USB-C out at the rear of the console. There is a case modification STL I have that will enable this.

The 128MB RAM upgrade is something you will want to do one chip at a time, carefully and methodically. That way if you have a FRAG, you will know it's the chip you just worked on, probably a bridge or lifted pin. Do NOT get solder into the vias around it. This has ALWAYS killed my motherboards and I do NOT know why. You can run XBlast at every chip installation. If XBlast does not boot from your chip and you FRAG, inspect your work. This happened a couple times on this board and there was a bridge on one and a lifted pin on another.

Stay tuned!

[Dempsey_86]

1 hour ago, Bowlsnapper said:

I'm probably gonna borrow from a few tutorials, one of them being the MVG video.

I will use the kernel debugger, since I have Cerbios installed on the TSOP and the LPC is free to attach the ribbon to. I will detail it here as much as possible. I will use a USB-C breakout and internalize the serial debugger, with USB-C out at the rear of the console. There is a case modification STL I have that will enable this.

The 128MB RAM upgrade is something you will want to do one chip at a time, carefully and methodically. That way if you have a FRAG, you will know it's the chip you just worked on, probably a bridge or lifted pin. Do NOT get solder into the vias around it. This has ALWAYS killed my motherboards and I do NOT know why. You can run XBlast at every chip installation. If XBlast does not boot from your chip and you FRAG, inspect your work. This happened a couple times on this board and there was a bridge on one and a lifted pin on another.

Stay tuned!

FYI: that video is from pre-cerbios. Now its much more easy. Just place your debug files on C and E like in the video. Change the cerbios ini so the debug line does say true and boot the console, it will boot the debug dash.

another option for cerbios is leave the ini with debug false, so the console boots like normal to your xbmc4gamers dash and make a seperate cerbios file with the cerbios tool with debug enabled and ini loading disabled. This bios then can be booted with the BFM method and be started from your main dash.

[Bowlsnapper]

11 hours ago, Dempsey_86 said:

FYI: that video is from pre-cerbios. Now its much more easy. Just place your debug files on C and E like in the video. Change the cerbios ini so the debug line does say true and boot the console, it will boot the debug dash.

another option for cerbios is leave the ini with debug false, so the console boots like normal to your xbmc4gamers dash and make a seperate cerbios file with the cerbios tool with debug enabled and ini loading disabled. This bios then can be booted with the BFM method and be started from your main dash.

Yes, looking at the kernel debugger page on github, I did see that I could basically just have Cerbios in debug mode on the TSOP and just hook up the ribbon straight to the LPC. Thank GOD I had no issues flashing the TSOP on this guy or putting in the RAM. I'm comfortable doing them, but sometimes those procedures go bad for seemingly no reason. The hardware modification is finished, at least with the mobo. I will work on modifying the case to get USB-C out on the back.

I was watching this video and went "oh SHIT" because I needed to sort out what to do and what NOT to do on the software side, but I think it'll be easy to figure out. Forget everything involving PBL and transfer the rest of the XDK files. No big deal. You said as much above.

Edit: @Dempsey_86 I read your post more carefully and I see that using the PBL will enable me to use the rest of the HDD normally, dash and all. I will have to think on that! Right now I have the standard 2TB with my image on it, so that may be overkill and I may be able to use a more regular drive.

[Bowlsnapper]

So I got the XDK dash installed, and PBL is listed, but when my retail Cerbios bios boots, it freezes at the boot animation. Anybody have ANY idea why? 

Edit: I think the HDD is gonzo. It got moved in the HDD bay while copying the XDK dash files over and unmounted. It has been unstable since. Guess I'll fuckin trash that and image another drive. Start over. 

[FrostyMaGee]

25 minutes ago, Bowlsnapper said:

So I got the XDK dash installed, and PBL is listed, but when my retail Cerbios bios boots, it freezes at the boot animation. Anybody have ANY idea why? @KaosEngineer @Rocky5

Classic case of Gremlins, Bowl! Lol. You’re not supposed to feed your Mogwai XDK after midnight. Little known fact Mogwai operate on EST where it’s after midnight.

I have no idea on your issue in all seriousness. Just wanted to post something stupid about gremlins.  

Edited April 2 by FrostyMaGee

[Bowlsnapper]

Sorry for bumping, but attempting to load Cerb retail as a BFM from the XDK launcher (So hardbooting with a debug = true flag in the ini) is causing a lockup during the boot animation XBE. Does anybody know why this might be? I had somebody else test and it is doing the same thing for them. The BFM is set to retail and to ignore the INI.

[NokSueCow]

Does it lockup if you delete the bootanim folder? When Rocky gave me the dashloader files for Softmod BFM, the bootanim folder was deleted and it booted straight into the dash.

[Bowlsnapper]

1 hour ago, NokSueCow said:

Does it lockup if you delete the bootanim folder? When Rocky gave me the dashloader files for Softmod BFM, the bootanim folder was deleted and it booted straight into the dash.

Damn, Now I have no boot anims folder. lol. Yes, it still locks up, just at the Xbox/Mircosoft logo. Somebody suggested that I need to use 2.3.1. I guess I'll try it...

Edit: Yes, 2.3.1 will work as BFM from the XDK dash. I will use this for now, but I assume it is a bug.
Edit 2: With the reintroduction of boot animations, the lockups are returning with 2.3.1 being loaded as BFM from the XDK dash. It was booting fine without them. NOW I'm getting pissed. @KaosEngineer

[TiZm]

16 hours ago, Bowlsnapper said:

So I got the XDK dash installed, and PBL is listed, but when my retail Cerbios bios boots, it freezes at the boot animation. Anybody have ANY idea why? 

Edit: I think the HDD is gonzo. It got moved in the HDD bay while copying the XDK dash files over and unmounted. It has been unstable since. Guess I'll fuckin trash that and image another drive. Start over. 

fyi that's an older xdk dash (4627), I normally grab 5849 even though its UI isn't as good (MS Orb dash went so hard!)

[Bowlsnapper]

7 minutes ago, TiZm said:

fyi that's an older xdk dash (4627), I normally grab 5849 even though its UI isn't as good (MS Orb dash went so hard!)

I have the newer one, It just looks so GOD awful... Lol. Is there any advantage to it?

[Kalpi]

Just throwing my hat into this; I always boot to xdk dash then have a shortcut xbe to a normal dash on f, had some issues doing that with xbmc4gamers, but the emu station variant works fine.

I'll add some pics of console/filesystemlayout once I'm home

[Kalpi]

Pics as promised:

Case is a mismash. black base like the DVT consoles, jewel swap to green, green paint on dvd cover lettering, also gave the controller a jewel swap as well. usual 80-wire + startech IDE->SATA

TSOP'd with cerbios 2.3.2 beta + udma6 patch.

lower part of the filesystem picture shows where to drop any apps/shortcuts to have them appear on the xdk dash on boot, also why there's an "A" at the start so it appears at the top of the list.

[Bowlsnapper]

I received the parts for the kernel debugger today. I will build it tonight.

[Bowlsnapper]

As you can see, Mouser fucked up and only sent me one resistor array, so now I need to wait for the other one... and C5 is crooked for some reason. I'm gonna fix that. But the Kernel debugger is basically done. I have ordered a USB-C breakout that will be mounted at the rear of the console and the debugger unit will be internalized, probably against the rear wall.

These LEDs actually fuckin melted, but I don't think you can see it. I will probably have to replace those too, unfortunately. Never seen that before.

... Actually, I have a MUCH cooler idea in mind for the LEDs

I bit the bullet and ordered this transparent green PLA for the case modifications so that they will match. I will also get transparent resin to match the Halo edition as well.

https://www.amazon.com/Printer-Filament-Transparent-Dimensional-Accuracy/dp/B08MT9M8Y8/ref=pd_ci_mcx_mh_mcx_views_0?pd_rd_w=Vx3Vg&content-id=amzn1.sym.8b590b55-908d-4829-9f90-4c8752768e8b%3Aamzn1.symc.40e6a10e-cbc4-4fa5-81e3-4435ff64d03b&pf_rd_p=8b590b55-908d-4829-9f90-4c8752768e8b&pf_rd_r=F83WH9VT78K92XKJPR02&pd_rd_wg=ESoQ6&pd_rd_r=29185145-f0d5-436d-804e-6997389abc7d&pd_rd_i=B08MT9M8Y8
 

@dtomcat Do you believe that 3MM LEDs can be driven with the Superio Debugger in place of the SMD LEDs used here?

 

[Bowlsnapper]

Looks like the LED idea is gonna work fine. Now I just need my transparent, green resin.

[Bowlsnapper]

https://www.prusa3d.com/en/cart/  -  I found this color in PETG I believe and I think it matches the color better than the PETG I have now...

That is the 6 LED clip I will be using. The color is WAY off and it WILL bother me. The above link is the only color that I think MIGHT be even close. What do you guys think?

@dtomcat Added the comparison pic. It's 50 bucks because of shipping from England...

[dtomcat]

Nice.  Too dark for my liking too

[dtomcat]

Yea seems a lot closer 

[Bowlsnapper]

In order to use the Super IO Kernel debugging unit, I will need to reconnect LFrame to the LPC/MCPX.

https://xboxdevwiki.net/LPC_Debug_Port

I seem to have pulled it off. I won't know for sure until I get the second resistor array for the debugger.

I have so many overly rich, green parts to install and I am jonesing.  This debugger needs to get done and these LEDs need to come in already.

I am using molex connectors to attach the status LED wires, so that if I ever need to do work on the motherboard, I can just unplug the LED wires going up front and pull out the board. I don't know why there is fuzz on one of the molexes. 

I will learn to code for the Xbox... Oh yes... I WILL learn to code for the Xbox.

[FrostyMaGee]

Nice work, Bowl! It’s looking really good. 

[dtomcat]

Looking nice  

[Bowlsnapper]

I saw you in this page here, Kaos... :
@KaosEngineer https://assemblergames.org/viewtopic.php?t=59850 - More info about serial/kernel debugging.

 It seems that the Debug Kit simply had 128MB of RAM and the only debugging came from the dashboard or bios and transferred through LAN. As far as I know nothing else is different from a stock/retail console. However...

If you go to 4:00, you will see what the SuperIO I am building and featuring in the build is taking the place of. It was featured in the DXT-3 and 4. This is Kernel level debugging. When using the simple, green Debug Kit, I don't think these consoles had this. They only could debug at a certain level, which was the software being run, but not any lower than that. This is pretty much the ultimate debugger, and you can actually see that it shares the same basic chipset and interfaces through the LPC, albeit with LFrame attached.

So what  is LFrame, anyway? What is it's purpose when kicking the MCPX over to the LPC in a 1.6? Why does it enable debugging through the LPC? Why did the Debug Kits (DVT-1 &2) not have kernel level debugging but the Development Kits (DVT-3&4) did? And what is the UART pin header for on this debugger?

I need to be straightened out here!

[applesauceman]

https://github.com/zatchbot/OGX_LPC_Breakout