Print

[flattspott]

I just had an idea for my installer.

How about this, I'll make it so XSelector Boots, then have options for Pheonix BIOS Loader, MXM Installer Retail HD, MXM Installer Upgrade HD and EvolutionX. This way everthing can be in its own area. Might be somewhat cumbersome though. I'll have to see.

[BenJeremy]

QUOTE (diffident @ Sep 21 2003, 06:07 PM)

I've been playing a bit more with the 20th Sept WIP, and I have a couple of comments on the revised FTP. Firstly, it seems slightly faster for me which is nice (average of 9.9M/s over a 3GB transfer to the xbox as opposed to about 9M/s under 0.9n4). I've had a couple of odd things,though. With the new code, when I log onto the xbox via FTP I get a long list of partitions I don't actually have (no memory cards etc involved). The disk was formatted via EvoX, and has CDEFXYZ partitions (I've only ever looked at it via FTP, but FTP served by both 0.9n4 and EvoX gives only CDEFXYZ). With the WIP FTP server I get CDEFGHIJKLMNOXYZ. Trying to access any of the extra partitions gives a 'directory not found' error. I don't think it has anything to do with the FTP client, as I get the same list via Interarchy on MacOSX, Internet Explorer on OSX and Internet Explorer on XP. Also, I've always had trouble with uploads to the 0.9n4 FTP server stalling after about 2GB - it's never been a big deal as listing a directory has always caused the transfer to resume at full speed, with no need restart the upload. FTP priority set to highest, nothing else going on on the xbox (no music, no video). This is via Interarchy on OSX, but again I don't think it's a client issue as the same uploads run all the way through with EvoX's FTP server. I was hoping the new code would fix that (BJ mentioned 'no more hangups' with the new code, which I thought might be this problem), but I got the same thing today with the WIP - the transfer stalled at about 2Gb, but listing a directory resumed the transfer at full speed. I'll do some more tests (switch to an internal skin, for example), and post more if anything changes.

I don't know... there are several odd lines in your log, which is definitely an odd thing for the client to do:

QUOTE

Cmd: CWD EEPROMBackup.bin 553: Requested action not taken. Directory not found Cmd: TYPE I 200: Mode is set to I. Cmd: SIZE EEPROMBackup.bin 502: Command not implemented. Cmd: REST 1 350: Restart okay. Cmd: REST 0 350: Restart okay. Cmd: PASV 227: Entering Passive Mode (XXXXXXXXX). Cmd: RETR EEPROMBackup.bin 150: Opening BINARY mode data connection for file transfer. 226: Transfer complete. Cmd: CWD /C/backup/cm_backup/ 226: Transfer finished successfully. Data Connection Closed. Cmd: PWD 250: "/C/backup/cm_backup/" is current directory. Cmd: CWD /C/backup/cm_backup 257: "/C/backup/cm_backup/" is current directory. Cmd: CWD EEPROMBackup.cfg 250: "/C/backup/cm_backup/" is current directory. Cmd: TYPE A 553: Requested action not taken. Directory not found

Earlier, it reports the listing it got:

QUOTE

Cmd: LIST 150: Opening ASCII mode data connection for ls. 226: Transfer finished successfully. Data Connection Closed. drw-r--r--   1 XBOX      XBOX        0 Oct 26 10:03 .. -rw-r--r--   1 XBOX      XBOX        256 Sep 21 17:49 EEPROMBackup.bin -rw-r--r--   1 XBOX      XBOX        420 Sep 21 17:49 EEPROMBackup.cfg -rw-r--r--   1 XBOX      XBOX        579 Sep 21 17:49 EEPROMBackup.TXT -rw-r--r--   1 XBOX      XBOX        256 Sep 21 10:14 EEPROMBackupBeforeLock.bin -rw-r--r--   1 XBOX      XBOX        420 Sep 21 10:14 EEPROMBackupBeforeLock.cfg -rw-r--r--   1 XBOX      XBOX        579 Sep 21 10:15 EEPROMBackupBeforeLock.TXT

So why does it think those two files are directories? This is very strange.... can you try changing the "site type" from "automatic" to Unix, or something similar?

[BenJeremy]

Well, the "WIP" Binaries have been updated.... look at the scripts in internal.xml for what I've been working on.

More tomorrow.... I'm trying to "refresh" the drive I was using to test, to get the drives wiped to "unformatted" condition.

Basically, I designed some scripts to activate when the C or E drives are not formatted. It is designed to format the partitions, and copy over the contents of backup directories... or if they are not present, to at least copy over MXM as xboxdash.xbe, worst case scenario.

It's not pretty at the moment, and I'll take recommendations as I tweak it for release.

This release is getting VERY close, and I apologize for the delays. Testing "Slayer's Install Disc" type functionality is tedious, and takes a long time to get right.

[diffident]

Now that I'm at work and can't do anything about it, I realise I should have done the same two file FTP test under 0.9n4 and uploaded the logs for comparison with the WIP logs. I'll do that when I get home.

[diffident]

BJ, I've uploaded a full comparative set of FTP logs to your server (six logs, a screenshot and an explanation of what's what. Hope they help.

[BenJeremy]

QUOTE (diffident @ Sep 23 2003, 02:31 PM)

BJ, I've uploaded a full comparative set of FTP logs to your server (six logs, a screenshot and an explanation of what's what. Hope they help.

I'll take a look in a while... busy trying to wrap up the ActionScript stuff.  

[BenJeremy]

Well, another update for the "WIP" binaries...

I added a context menu for actions. You'll be able to define 10 items using ActionScripting (and later, BASIC programs), and have access to the directory, executable, so forth... Currently, the items are defined in the internal xml, but I will likely add support to read them from the skin and mxm.xml files.

[BenJeremy]

Oh, I thought about doing a minor update, after finding a small, but painful bug in my "Preparation" scripts... but I thought I might make it interesting for the beta testers who are into scripting to FIND the bug and report it here.

Who will be first?

It's a pretty obvious, and stupid bug. Fortunately I have fixed it, and tested the script.

While it's a little rough around the edges, it worked. The script will check the Xbox's hard drive on boot up when running from a DVD drive, and if the partitions are not formatted, offer to format them, then attempt to restore files form backup directories. Basically, it's a VERY SIMPLE "Slayer's" disc. As an added bonus, users an extend the existing scripts and override the current scripts with more refined, targeted setups.

[cubist77]

Am i correct in assuming the "backup" directories would be

d:cbackup
d:ebackup, etc?

[BenJeremy]

QUOTE (cubist77 @ Sep 23 2003, 11:14 PM)

Am i correct in assuming the "backup" directories would be d:cbackup d:ebackup, etc?

Yes. There needs to be a few more tweaks - the script is just intended as a quick-and-dirty means to create a restore disc. I expect others (i.e. you guys) to lilkely come up with some very sophisticated scripts with full choices presented for the user.

The bad thing about my testing was that it depends on the drives being unformatted - meaning EACH TEST I had to load up the Xbox drive in a PC, use WinHex to erase the starting sectors of each partition, then re-install the drive in the Xbox. Long and tedious, with my 11 year old son asking "will it be ready to play soon?"

Currently the script supports CBackup, EBackup and FBackup, though GBackup could be added easily enough.
It also insures that regardless of the backup data restored, it creates a TDATA and UDATA directory on E:, and also copies over MXM's "default.xbe" over to the C: as "xboxdash.xbe" BEFORE restoring from CBackup (in case that fails - you at LEAST have MXM booting, if nothing else is available)

I'd like to scan the BIOS to check the booting order and actual dash names, as well as G: support and raw hard drive size. Probably in the next release.

I'm giving you guys the tools to knock out some really awesom add-ons.

Don't forget, the scripts in the internal.xml file can be overridden by scripts in MXM.xml - just use the same name, and MXM will use those instead.

[BenJeremy]

QUOTE (cubist77 @ Sep 24 2003, 08:40 PM)

I'm having terrible luck with your install script.  I get drive mot present errors both from your auto prepare script and when i try to use _PerfRestore from menu.xml.  I tried removing the IF %BackPresent% != 1 GOTO BACKNOTPRESENT check, but still no luck.  Any ideas? BTW i called _PerfRestore using <action> _PerfRestore F </action>

Have you looked at the latest? I uploaded one this morning, with the correct script. It worked on my hard drive test last night.

It assumes C: is "unformatted" - you have to zero out the first sector of the partition (Offset 0x8ca80000) - I used WinHex to do so, with a removable disk drive tray. I got pretty good at it  

[BenJeremy]

Added "DVD Player Preference" to select a preferred player (Default, X2, or M$)

Users can add "Context menus" for games. These are actionscripts defined in a <Context> node in MXM.xml - (See Internal.xml for examples)
The scripts have some awareness of the currently selected game, and can act on them.

Added "TimeSynch Offset" in hours for those using non-local time servers.

Nothing done to the FTP Server tonight. Had to clean up some of the nagging issues first.

[BenJeremy]

QUOTE (DBZRacer @ Sep 25 2003, 03:15 AM)

I just bought a new 160gb hd cuz of a super deal I found and now need to learn how to burn a bootable MXM CDRW disk! Anyone want to share their installer scripts for us to use yet?

Well, the "Internal.xml" that's included in the "WIP" Binaries contains a script for basic installing.... it's already set up to do just that if you run MXM from a CD/DVD on an Xbox with an unformatted drive.

[DBZRacer]

 I think I'm gonna do a little more research here on this whole lba48 thing as I'm not fully comfortable on how best to set everything up partition wise....