I am wondering if there is any possible way to flash the PSX DVR (DESR-XXXX BIOS) onto a PS2? I already have PSBBN on a Fat PS2 with a 250GB SATA HD (IDE Converted) I would certainly appreciate any help or direction, thank you.
Hah, it's impossible. It's a read only memory, it cannot be flashed. Moreover, the PSX has got slighty different hardware than PS2 (more EE and IOP RAM, third processor for extra DVR work). Personally, I don't understand the hype about PSX. It's in Japanese, supports abandoned Japanese analog TV system, PSBBN is discontinued. And finally, if you mess up with HDD you will get fancy unusable 6kg piece of trash under your TV. Really be happy with your Fat PS2. I really would like to get one, after my old system died, but it's hard to find one with good condition. Now I've got only V15 with no HDD capabilities. ;/
Well, from the image I have burned onto my hard drive I have noticed that the BIOS becomes different. Therefore, and image flashed onto the PlayStation 2 hard drive can actually change the BIOS without writing it. I was thinking that it would be possible to have a custom version of the PSX DVR system emulated. I am just bored with the psbbn menu as well as the free HDBoot. And if anything I could throw up a listing on eBay if you're in the US for a really cheap fat PS2 if you'd like.
There is a difference between updating a ROM to add new features, which is what the HDD image does, and completely replacing the ROM, which is what would be required for the DVR BIOS to function, not to mention the fact that things are in different places or completely different between the two
Awe, that sucks. I figured it would need more hardware, plus a rewrite would be quite extensive if even possible. Thank you !
The ROM is read-only. You may have seen that the update disc contains a firmware, but that is for the DVRP (which has its own flash ROM chip). Firstly, this isn't a BIOS; it doesn't perform Basic I/O. It is just a boot ROM, so it was designed to be forward and backward compatible with (nearly) all software of the PlayStation 2. Therefore replacing the ROM won't give you better functionality, other than making it incompatible with your board. Since the PSX has got a different hardware configuration, the boot ROM has slightly different executables for supporting the hardware. For example, the EE kernel has an extra syscall for setting the memory mode (32MB mode is emulated with TLB). There is also support for the 8MB on-board flash storage and for controlling the remote-control. It may be possible to get the XMB to boot on the regular PlayStation 2 because the hardware is largely similar, minus the DVR stuff and the amount of memory. The XMB isn't stored in ROM, but on the HDD. It's why the PSX becomes a very expensive and heavy brick after the HDD fails. But it will likely not be a simple thing because it was made to expect the PSX's hardware (i.e. DVRP, dual-mode DVD writer).
Yeah, the XMB is the only one interesting option in case of porting it to PS2. Personally, I love the XMB, it's very intuitive for me as a lazy user. The PSBBN sucked very much, even when I first heard about it a decade or so ago I thought it was revolutionary. But the PS2 is not suitable for serving as multimedia system nowadays. There are more important things to maintain today, such as Open PS2 Loader. It's great that the homebrew scene is still alive. In my opinion much better than the PS3 one. Wish I had still the fatty PS2 to fire up some games on HDD.
Is there something that absolutely prevents you from recovering from a failed hard drive, or is it just that there is little interest in doing it? I've often thought about buying one because of the extra memory.
Like with all removable PlayStation 2 software, it appears that the DVRP's firmware requires a SONY HDD that will respond to their DRM commands. Fitting in a generic ATA disk will not work. You can fit in a SCPH-20401, but then you'll likely lose the DVR functionality due to it being a much smaller disk. It's not easy to get the XMB files back onto a replacement disk too. So I believe that one way to free all PSX consoles from needing a SONY disk is to crack the DVRP's firmware, which @l_oliveira said is actually stored within its own flash chip. You could perhaps say that there is a lack of interest here too, since nobody has done that yet.
A PSX would still be very useful as debugging unit even without a functioning harddrive, since it has full IOP RAM (8MB) and half the amount of RAM a TOOL has on EE (64MB).
I myself had the same idea awhile back seeing as it does have double the ram to work with. However from what I've read it has two separate modes that it switches between the first one being rainbow mode_64mb while the second one being ps2 mode_32mb. I've lurked around the forum, but I was unable to find any information regrading how to create a custom boot loader to enter into rainbow mode. So my question for l_oliveria is how were you able to successfully modify ulaunchelf to set the EE kernel to enable 64mb instead of 32mb? I ask this because by default ulaunchelf is programmed to only see 32mb of ram. Assuming you can start with 64mb of ram available than I'm sure this would make a nice alternative to using a test unit with less memory. I imagine if you were able to use something like RDB with dsnet it would be of tremendous use when compared to a retail console. Another thing it would be awesome for is a custom usb version of linux it could even help out with the more intense applications that eat up more resources. Though I'm not sure how practical all this would be since I do have some concerns that is hardware degradation and reliability because I'm not sure how well this would fair against a long session of debugging. Note; I am aware about the 8mb of ram the IOP has and yes it can be used for either custom modules or openps2loader when streaming your games over a network with SMB.
SP193 did it when he was researching for the FHDB program design... Actually the PSX defaults to 64MB and there's a kernel function which toggles into 32MB mode using the CPU TLB. The PSX has that much RAM so it can be used to open and view JPEGs from still cameras and also embed them on videos which can later then be burnt as DVD videos with pictures collections.
I see I was just reading a post where SP193 was explaining how the PSX functions here it is; I do wish I had found his post sooner because it would've answered my question earlier. Oh well it is always good to have another knowledgeable person involved in the conversation. Interesting it's just like I thought that's why ps2ident only reported 32mb rather than 64mb. I'm not sure what the solution would be than for your software to be able to benefit from the extra ram added. Other than to specify how it can take advantage of the increased ram by modifying the kernel's parameters. I'm just guessing though I'll be honest I am a little baffled by this. I did not know that. If you have any other insightful facts about this device please do share. I am always willing to learn as I will always be the student even when I'm a master.
SONY seemed to have a policy of not changing the runtime environment of old PlayStation 2 software. This may be different from how they handle patches/updates to their kernels and SDKs on newer platforms. For example, their alarm-management functions within the EE kernel is bugged on all CEX and DEX consoles. But newer software will avoid using these functions, even though the patch is installed into kernel memory and its functions are registered as syscalls (under different IDs). This will effectively allow older software to retain the use of the old behaviour. It is a good idea, when you consider that some behaviour may have allowed some bugged software to work. For example, Marvel vs Capcom 2's CRI ADXI driver dereferences a NULL pointer at boot, but dereferencing a NULL pointer on the IOP doesn't cause an exception. But as a result, changing the value at 0x00000000 causes that bugged CRI ADXI driver to malfunction. There's also Super Robot Wars Impact, which suffers from race conditions around some of its variables. It works, when the CD/DVD subsystem has its natural delays, but starts to break down when the CD/DVD subsystem is emulated.
Out of curiosity, since you are referring to the x-App (x-アプリ) software for enhancing/producing video/photos/music, I wonder if the late 7700 and 5700 contain more RAM, or more powerful components, than their predecessors? Indicated by the fact that above mentioned x-App software was introduced with the V 2.11 update for 7700 & 5700 units (and with less features in update V 2.06 for 7500 & 5500), but never for the 7000/7100 & 5000/5100 units.
No, not more powerful hardware. Just different. But the x500 and x700 units that use the newer motherboard series do have extra hardware for the ilink port (5500/7500/5700/7700) and for encoding PSP format videos on memory sticks (5700/7700)
Thanks for the swift reply! So in theory Sony could have released the x-App software suite with even fewer features than V 2.11 and V 2.06 respectively (e.g. no ilink/PSP features, no dubbing to memory stick function, and so forth) for the older units with XPD-001 mainboards?
The original SCPH-10000 PS2 could play progressive scan DVD videos just fine (if we remove the SCPH-50K checks out of the DVD driver update elf) if that answers your doubts.
