trencherfield

Did some more testing back on the 1.0 board with various chips. You can boot up say with 5035 bios on a genuine xenium chip, then once at a dashboard, lift that off and replace with a DuoX chip flashed with 5035 bios, and it will work and boot xbe's. Now if you do the reverse, boot with the DuoX on 5035, then lift that and fit say the Xenium with 5035 then that will not work. This is because the cpld and OS on the flash chip has bank control and is not a dumb chip (like the DuoX is) so it can't find the correct bank. Looking back at the R3dux X3 chip, this appears to be probably shutting off the bank register or access as I guessed. Either the code is missing for xbe calls back to it or its shutting down access. So the current status of Kekules code he put on the github is unfinished. Simple as that. If anyone wants the jed file for programming and building one for testing etc give me a shout here. I will look at trying the other code next. Other than that I'd say it's at a dead end, unless Kekule feels like releasing an update to the repo. Which by the look of it, he doesn't. So why setup the github in the first place begs the question. Make your own conclusions.

Just tested a V1.6 board with an openxenium boot using 5035 v1.6 bios. Booted to Unleash X dash, removed chip, tried to launch XBMC xbe = freeze, black screen. Reattached chip, cold booted to Unleash X, then XBMC, then removed chip again, tried to boot Halo off hard drive = freeze, same again. Reattached chip, cold booted again to EvoX dash, tried to launch Halo, freezes on launch screen as pictured. So, modchip needs to be on the LPC, even after loading BIOS up and to dash, else can't load any xbe, period. Additional: With just say a 'cheap mod' chip on the LPC, which functions correctly, without any other IC or CPLD present, then one can assume that the Xbox does in fact require to access the flash again for XBE launches, and of course LPC cold reboots.

No not at all. As I say, I have no idea why. I can only see what I test. The only reason I found out myself was seeing if I could get further by swapping chips on the LPC header. I tried another the other night (regular openxenium), same thing. Unless it's my 1.0 board or sommet. Will try another board and a 1.6 and see what that does I suppose. Since this happens on chips with a short 2x6 pinheader, then that ommits it being anything with the SMbus pins (13/14) as queried by Prehistoric on page 1, as far as I can see. Theoretically, if I can get past this and load an xbe, well then the r3dux chip would be a functional multibank chip, by using the switch panel which works, though without the config live. I guess the LCD would work, not tried that yet. Also the issue of flashing the chips to sort, as currently can only flash them before soldering them on. I was hoping to get this done and dusted, so I could just get it working then everyone can make their own chips.

Well, I have no idea why, but if you lift your chip (any that I've tested) after booting to the dash it won't boot anything else and freeze.

What you are describing and the vhdl code which obviously interfaces with these instructions, including the IO registers the X3 uses, are all way beyond my capabilities here. It's not just TX X3 though, all chips do it. That's because it loads the BIOS through the LPC, so the xbox will need access back to it just like a PC, which obviously its based on.

I've found this other repo as well... https://github.com/maximus64/OpenX3_GW Which is for the original X3, so might solder up to the test points on one of my purple x3's and program the cpld (4128V) will check that. Will have to lift that LAD0 cpld pin and solder a jumper wire over. Code loads up in the Lattice isp, so worth a shot on that one. If I can get that working, then I could design a new PCB to accommodate that in Eagle probably.

Yeah correct, only realised after that it has RC4 encryption. Was trying to add it to xblast. So then looked into unpacking bios in xbtool etc and got fed up setting that up with the key from complex bios etc. Just been looking at the r3dux HDL... as expected, means bugger all to me. Guess I could compare it with some of Ryzee's LPC code to see, but doubtful. Attached it here as a text file if anyones interested. Thanks for the suggestions. r3dux.txt

Yeah I looked up the PDF's and saw that, but this particular X3 chip, whatever they had done, does not match that pin 9 - wasted hours upon hours and thought sod it, it's of no use here anyway. Kekule specced his own for the board and code, but I was just interested to see. As I say it does read, and if you ignore that pin it will write, but does not match up. See pic attached - some say its AM29LV020B .... tried that, same result. Maybe Team Xecuter had a special, who knows.

Yes they are AM29F016D and the ID's are correct. I'm on about Kekules flashbios 3.1 (which is not Xecuters - well was, but that's besides the point) anyway yes they are the correct ID etc, checked all that. His flashbios returns the 0xFF status code errors and halts. Xecuter 3.0.3 won't boot... just frags. Hence I just went straight to flashing BIOS offboard first to bypass that for now. The 256 on an X3 is actually unknown in truth, it has an odd pin 9 and does not match up to any of the AMD devices in the software (and they are all there), though is similar to AM29F002BB used here. Again not important at this stage as its the backup anyway, but it does boot whatever I flash to it before soldering it on. It also appears that an original X3 uses a Lattice LC4128V (not the 4256 as used here), again not relevant in this application at the moment. The flashing is a secondary issue really, either the cpld code is blocking access or has the wrong ID's again. The main issue at the moment is after booting up say X3 2913 bios (besides no config live) once at any dash (bios path dependant of course) then you can navigate the dash, but can't load an xbe. So as above, its probably an early release of Kekules code and needs work. I haven't looked at it yet as I got tired of it after doing so much testing & soldering chips on/off etc. Will have a look at it when I feel like it. Did edit some hex of 3.1 which I thought the cpld might be looking for, but didn't work, just went bananas! (did say mention I can't code lol)

No, that pic was me just throwing all kinds at it to see if I could boot the original flash chips. I Have a range of chips, lots, so program various BIOS banks up for the 2mb flash chip for instance on an external flash programmer. This is how I got this far. I can get Kekules flashbios 3.1 up and running, menu works, flashing does not. Chip ID codes are incorrect in the release it appears. Also can't hot-swap flash and neither can XblastOS flash. So think there are major 'issues' in the code. Kekule said he'd send me a new jed file, so assume he knows whats wrong, but has not updated the Github. Not responded back to me, maybe he's too busy with work.

Simple test. Boot a working chip, Xenium... whatever brand, gets to dash, lift your chip off the lpc and try booting an xbe. So no, the chip is not doing its job after initial boot. If you read some of psyko_chewbacca's info regarding his xblast lpc mod you'll see he mentions about this regarding his 'logic1' for lframe for instance as an example. This is the limit of my knowledge as far as how the xbox communicates with the lpc after boot. The cheap mod for instance has no cpld on it, just the flash chip, so I gather from what I've read that it needs access back to the flash rom for each xbe launch etc. I'm no programmer, all I've worked with is the arduino IDE and getting the OLED 20x4 to work. So despite being able to look at the source for this, I have no idea what I'm looking at or for.

You can make them yourself from parts and pcb on the github here> https://github.com/Ryzee119/ogx360 I also make them, every week or so, and then list them on ebay. None listed at the moment, but I do have them. Usually 2 player, without 3d printed case or cables.

Yes, the OGX360. Will allow the use of various wireless controllers, even the Series x controller.

CPLD appears fine, though I have a couple more I could try, I have some duff purple X3's too I was hoping to fix which is why I bothered in the first place I could build a r3dux on a genuine purple x3 board too.

Aaron (Kekule) by the way saw my post on the group... said he'd try and remember to send me a new .jed file. So he probably needs to update the repo with a commit. Which I suggested, if it was easier. It's an expensive chip to make really so its not something that's going to take off like the Openxenium for instance.... it's just too much work and the parts cost make it not worth it really. You can pick up an X3 for less lol

The X3 start function works on the R3dux though, you know the hold of power button to disable chip - light goes red and boots stock bios, that works and so does purple recovery holding power + eject.

Yeah. My work xbox there has D0 to ground at the side, so didn't bother with the r3dux connector. I did end up soldering the D0 wire to the D0 pad on the r3dux though in case it was that... still the same. Don't think LAN or HD LED will have any bearing though. Yeah I've run out of ideas really.

Swapped on/off lots of variations inc 512k X5035... all the same - runs as well without the 256k backup chip on or off the board. Tried some bios on that as well.

Yeah tried that, have a couple working X3's... also removed the flash chips from the working X3CE and tried them on the r3dux. No joy unfortunately. I am using the genuine X3 eeprom from the X3CE chip on the r3dux which I also lifted. I do have some eeprom chips as well to program up but have not bothered, since I was lifting the flash chips at the time I lefted the eeprom too. Checked and read the 2mb flash chip - could not properly detect the 256k X3 backup chip - I don't think anyone has, I can read it. Tried xecuter 2 bios and others, all have the same issue, load to a dashboard (the X3 bios loads up Evox dash), but then freeze on launch again of any xbe. Also tried hot swapping on another Xenium after boot, that doesn't work either. So somethings up.

Thought I'd stick this up here - since I was nudged by a friend to do so. (I posted it on a group) Decided to have a go at making the Xecuter 3 clone (r3dux) chip. Used ispLEVER to load up the github code, seemed ok (nag about missing x3.txt) but ran fine. Ran the fitter and produced the jed. Programmed the cpld, in VM. Had to fiddle with the settings as got another nag. Wouldn't program in diamond so used the main VM. Tried the flashbios 3.1... flashing not working, ID's verified of my chips doubled checked - all fine, so something wrong there. So decided to make various bios packs in terminal command... some 8x256, 4x512, 2x1's and some debug's etc along with various 2x1 X3 bios. Can boot up some 256 x2 and the cromwell xblast etc to dashboard. Also boots X3 2913 1mb x2. Also tried 8x256 flashbios 3.0.3 (frags) so probably 3294 will frag too. Switch panel functions correctly for all these bios in relation to size and buttons - so bank switching is fine. No config live holding white on X3 bios. Anyway, upon loading up dash... can navigate dash etc, but soon as I try loading any xbe then the loading screen comes up and hangs. That's it. Call back to the lpc bios function seems out. Tried various drive combos/bios/settings/dash etc all result the same - freeze on xbe launch. That's where it's at. Can't flash the chips on X3. Either data line call error/ID register or maybe the pcb dunno yet, short on time. Have some dead purples to test up as well I suppose. So, anyway in case anyone wants to have a go, thought I'd post up my experience with it so far for info. (stutter on bios is just the usual no dvd connected in the video clip, have tried with one attached anyway)

As Kaos says, I would put X 5035 V1.6 on the other bank, since each bank will take 512k. Just as a side note for anyone who finds the thread, I have just repaired and old blue one of these, cpld had a couple of dry pins, but the main issue was the switch for bank select. The switch contacts go dry inside, hence why they get removed. A fast succession of back n forth movements of the switch can carbon clean the contacts to make it work as did mine (as it wasn't taking flashes properly) or better to replace the switch. It causes too great a resistance to the flash chip over time.

Short answer is yes it can be done. I have done it after a board went down mid build with a locked large drive, fixed the board later on but didn't have time on the spot and wanted the drive. The only thing that worked for me was psycho_chewbacca's tool to connect the drive in place of the dvd drive.

It's usually the character set & timing of the particular LCD you have installed. They are all a bit different. See the PDF of your LCD to check and see it meets the HD44780 specs okay. You might need to edit the code in the arduino to add a character set instruction for the LCD and possibly a timing delay on a few lines. This will be specific to each type of display.

Hi, Unfortunately I sold the Xbox and have no pictures of the wiring on the back. I just wired it up to the spec of the PDF suitable for the HD44780 spec even though the OLED doesn't say it's supports it, I just set it to the same bit spec. After that I opened up the spi2par2019 code in the IDE suite and added the OLED initialisation code and changed the existing header instructions and added more code instruction to set the display lines correctly. Then I made a final change to the LCD library in the Arduino suite for the 3rd & 4th lines register as it was different for the OLED. I just did it off-bat so to speak. I percivered until I got the 'Xenium OS 2.3.1' to display nicely centered. Then everythign was perfect. I've noticed others using just SDi like the diagram you posted don't seem to display the xenium os correctly at start. I went with the original HD44780 spec which avoided those issues. Regards.

Thanks!