trencherfield

Yeah I was wanting to pick up a small CRT just for that nice retro look. The problem I found was that the RGB out from the xbox (for most UK crt tv's) is 480i, won't do the 480p on rgb. So that means you have to use the (much better) component video out from the Xbox (480p/720p) where applicable (game dependant), which then means for a CRT you are looking at the JVC and SONY range of PVM etc.... this = ££££'s So, gave up looking at those silly prices. You might find one where you are located cheaper, luck of the draw, but getting harder to find one without burn. There's a reddit crt group for gaming. Lots of pics on there of peoples setups for eye candy.

I concur. For the motherboard to boot up and give you an error screen means the problem is most likely as sweetdarkdestiny describes. Install a new hard drive and boot the installer up as he said.

Thanks for verifying that. Appreciated.

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.