Would anybody be interested in experimenting and modifying (read: arseing around) with a PS2, to make something like the GSCube, or a debug station that actually debugs etc? If you have an idea for a project, or plans, or just want to help please say so underneath!
The PCMCIA on the ps2, is it still on the later versions? where can i find more info on that ? or what is the Expesionport on the back of the ps2 exactly? pinout?
It does, at least for the EE. IOP DECI2 is pretty unstable, which I think comes from how I load the DECI2 modules, as well as how the communication works. The modules are really meant to be loaded as part of IOP startup (via IOPBTCONF), and I am still amazed that the dirty hack I used for Kermit (DECI2POLL) works at all :very_drunk:. But more importantly, the IOP DECI2 debugger seems not to follow the officially-documented restrictions of Sony's DECI2 API (regarding buffer alignment, partial sends and so on). It can easily disrupt EE<->IOP communication if such packets (proto=ISDBGP) are sent over the SIF link. The TOOL's PIF link apparently does not have these problems, or IOP debugging on it would be impossible. That's why I use a custom DECI2SIF in Kermit, which at least tries to prevent such problems. However, I know it is not perfect, but unfortunately I lack the time to correct it. I still wish to rewrite the IOP DECI2 manager from scratch, but unfortunately that's not going to happen anytime soon... :disgust: No, it is not. Later models use a different SSBUS controller which does not have a PCMCIA interface, but the proprietary "expansion port" instead. As for the pinout, you can find it in the leaked service manuals (referenced in my thread in the Technical Documents and Software forum, kindly re-uploaded by pool7 and others :encouragement. By the way: even though it looks like PCMCIA (and the controller can probably handle PCMCIA just fine), it is not, at least not all the time. The thing starts as PCMCIA, but after verifying that the special card is inserted, it actually uses a different operating mode. It is kind of a hybrid, with some signals the same as PCMCIA, but using a synchronous bus clocked at ~38MHz (PCMCIA is asynchronous). And it is no CardBus as well, because that one uses a multiplexed bus very similar to PCI.
Its diferent, very difirent from a PC side. But its still many MCU's and other ic's connected on busses to some CPU and GPU. LOL but Ive seen some SOny hardware and they make it look dificult at first. Buts awesome aswell. So maybe its posible to do some low tech hacks and with help of some fpga here and there something might be done question is, what you wanna where on the mobo do and if its posible hard/software wise? I need to do a Serialpost install first then look at service manuals for more nice tricks. (and dont kill it in doing stuff)
Also, as far as I know, the TEST's hardware is nearly exactly the same as the retail console's (Unlike a TOOL). I don't remember whether it has got more RAM though (e.g. 128MB for the EE and 8MB for the IOP, like a TOOL can have).
The changed needed to make a ps2 to a test, and the limitations of the test due to needing the dev flag on the discs makes this a dead end proposition. A well designed mod chip offers far more use given no one will ever be using the crash dumps to do anything, ever. Say you find a beta disc, and it crashes. You use a test unit to get the crash data. Then what? Disassemble / decompile? Then what? I think it would be far better to focus on things like the very important HDD hacking going on right now by olivera, which will yield a lot of benefits for years to come. Ps2 with dead dvd? No worries, as HDD adapter plus hacks will equal every game ever made available by hdd. This is very exciting times right now for ps2 hacking.
I believe that if you are an active developer of Playstation 2 software, a debugger is a necessity. Since I started work on PS2ESDL in 2008, I have been going without one. And I can say that it's been a really painful and time-consuming experience. :mad-new: Modchipping is a valid way of giving the retail console development functionalities, but what if you do not want to modify your console? AFAIK the retail PS2 can have debugging functionality if loaded with the right software, and Silverbull has already more-or-less achieved creating a system for doing that anyway. I feel that I need one that can be launched without a screen and controlled remotely via Ethernet connection - as my development console is never connected to a screen. I think that we are already long had the necessary information to install software to the HDDOSD. The only problem is the installer - it's not Sony-grade (As in it lacks the professional feel due to the lack of UI decoration and features). I'm still working on the SMAP drivers for faster and more reliable ethernet support again - since I don't think that those of us using the older Playstation 2 models (e.g. SCPH-10000) will be willing to use the drive to install games. (And I can't anyway - most of my legit games are NTSC-U, even though the PS2s here are all NTSC-J due to Sony screwing up.) It'll be great if there are people who will be willing to help me to test, debug and improve on the installer thoroughly. I can't commit constant time for it, and I think that I have too many ongoing projects to complete this one soon. l_Oliveira says that I can do what I want with the installer as it's mine, so I feel that getting some others to help will probably be beneficial for everone. We started work on this in 2011 - so you can see how long this has been going due to the lack of resources. Work on the HDD-version of FMCB and integrating this new version with the MC-side of FMCB will be great too. I have decided that I totally can't commit time for doing that, and have publicly told everyone this on PSX-scene. How would not loading the DECI2 modules during the IOP reset cause instability? Is it because this hack you used involves patching module dependencies? Interesting. But doesn't DECI2 on the TEST use SIF2? Why would that affect normal EE<->IOP communications, as that should be using only SIF0 and SIF1?
I'm quite sure the hardware is identical, apart from three things: the DVD Player ROM ("rom1"), the Mechacon's control program and (possibly) the MagicGate decryption inside the Mechacon. TESTs cannot execute the DVD Player, but I'm not sure sure whether that's because they fail decryption, or the software tries to access some nonexistent areas in ROM. I had the same problem, just the other way around :congratulatory:. That's why I added ODEM to Kermit, so I could debug CDVD emulation. Would a special "non-GUI" Kermit help? You are right, the truth is out there... The information, I mean :love-struck:. The partition format is known, the APA driver even from old ps2sdks works quite well, and almost everything else we need is hidden inside the HDDOSD. Combine that with ODEM's HDD installer code, and it should be possible to make arbitrary partitions bootable. I'm not quite sure where the documentation on the image/icon format is, but at least there is a program we can use to build static ones. Is there some problem with the Ethernet drivers for the 10k series that I don't know of? Do you know if anyone's working on this project right now? I got something running that may be suitable as a first-stage loader for HDD partitions. It is based on the old ODEM partition loader, but massively extended. No, I don't patch the DECI2 modules on the IOP, only the support routines inside the EE kernel (and that's pretty stable, I think). The problem is that DECI2 (as in rom0ECI2, the IOP DECI2 manager from the TOOL) registers a delayed initialization callback, that is invoked by the IOP kernel once all modules from IOPBTCONF have been started. That callback repeatedly invokes sceDeci2Poll to get the DECI2 communication running; if it is missing, the DECI2 manager will not react to anything, which I think is related to it disabling all related interrupts for the communication devices. It uses some kind of special interrupt mask, managed by INTRMAN through an otherwise (seemingly) unused export. I also seems to disable some other interrupts, and I have no idea how the retail IOP kernel reacts to that. On the TOOL, the delayed callback will just work as expected. On the retail unit, after loading DECI2 after normal IOP kernel startup, it won't. The callback is invoked immediately after DECI2's _start returns, but with a parameter indicating that the module has been loaded later. That parameter causes the callback to just return and do nothing. That's why I use DECI2POLL, which just performs the continuous calls to sceDeci2Poll. The TESTs I have seen so far do not have DECI2 modules. The only official means I know of to get these modules onto a non-TOOL machine's IOP is to use the SCPH-10020 TDB startup card, but that one also uses a trick: an IOP replacement image, stored in EE memory, with a special IOPBTCONF inside. And that IOPBTCONF lists some of the DECI2 modules, so they also get started as part of IOP (re)boot. DECI2 communication between the EE and IOP uses SIF2, on any machine you load the modules. The endpoint on the EE side is the EE kernel itself; on the IOP, its DECI2DRS. The problem occurs when you try to invoke the IOP Debugger (which implements DECI2 protocol ISDBGP, and is located inside the DECI2 manager) over the SIF2 link. The ISDBGP implementation uses the official DECI2 API, but in a non-standard way that conflicts with Sony's specification. For example, it uses partial reads when receiving packets, which is something that DECI2DRS does not support (either that, or the TOOL's hardware does and my retail 39k's doesn't). This crashes the DECI2 link between the EE and IOP, so no further packet can be sent or received by either side. But more importantly, if you manage to get the IOP into the halt state (for example by sending a BREAK request), it won't react to RPC calls as well. With no means to tell the debugger to continue, and no means to react to SIF0/1 interrupts (its a kernel debugger on the IOP, so it blocks really everything), the IOP is clinically dead.
That is probably the best thing to do, if possible. It probably would. I would like such a special version of Kermit for use. But if you don't already have something like that, I won't mind making one out of the full version of Kermit at my own time. The icon is a normal Playstation 2 save icon. Tools exist for manipulating and creating icons, and it's not a very cryptic format from what I remember. Yes, there is. Other than the lack of performance due to a lack of DMA support, the driver screws up when my (both previous and current) SCPH-10000 is connected to a Gigabit network port. The LINK and ACT LEDs will keep blinking, and the console will not get a valid connection. It turns out that auto negotiation is failing when the SCPH-10190 is plugged into a Gigabit port, and the homebrew SMAP driver isn't as fast and intelligent as the Sony SMAP driver is at detecting this fault and quickly reverting to manual configurations (10M HDX or 100M HDX). Thanks, but unless Jimmikaelkael already had his own plans for a "Free HD Boot", probably nobody has ever worked on it. I was working on my own boot loader too, but it had to be frozen due to a lack of time as well. I did disassemble the Sony MBR, and got to learn what sort of integrity checks they are performing on the HDD. Oh dear. That is bad. Do you know whether the Sony modules have the same problem? I know that the TEST has debugging functionality, but I don't believe that anyone has mentioned how good the debuggers (Especially the IOP-side debugger) were.
There is partial support for that already built in: it can save the full settings to an ODEM partition, and they are automatically restored when that partition is launched via the HDDOSD. I'll think of a way to implement something similar via a configuration file on the memory card. Okay, thank you. I haven't looked into this myself, yet; only used sjeep's old program to create the icon for ODEM partitions. That's strange. I could have sworn that the card I'm using in my DTL-H10000 works correctly with the GBit switch here. I got both an MBR and a partition loader running, and I'm seriously considering taking on a "FHDB" project. I did not try running the loaders on retail machines yet, but so far everything works correctly on the TOOL (when loading the programs via the debugger). Any ideas or wishes for FHDB? I'm thinking of using an MBR very similar to Sony's, but of course region-free and not needing (but still supporting) encrypted main files on the HDD; probably with some sort of (optional) auto-ATAD-patch :love_heart:. As for the partition loader, there are also some ideas, but I would like to hear what other users would want it to be capable of :cool-new:. What "debugging functionality" of the TEST are you talking about? There are absolutely no traces of IOP DECI2 modules in the TEST's BIOS ROM, and its EE kernel contains the exactly same DECI2 debugger stub than on retail machines. Infact, the only official means to get DECI2-related stuff running on the TEST seems to be the SCPH-10020 TDB startup card. Speeking of the TDB, here is a quote from its documentation that hopefully answer some questions: Actually, some of these restrictions make sense. The TDB has no EE-memory resident part that could intercept IOP resets, so every attempt at doing so leaves the system in an undefined state. The communication code is located on the IOP and uses the regular dev9 driver stack. This works as long as the system is running normally, but as soon as the IOP kernel debugger halts everything, the drivers are never invoked again and the system just hangs. To be honest, I didn't understand what the second-to-last entry is supposed to mean. Is it possible to completely disable the RESET button in software? I thought it can just be reprogrammed to generate a special CDVD interrupt, when being pressed for a short while; this gives other code a chance to clean up (like flush file system buffers). However, I thought when that button is pressed for a few seconds, it will always turn off the system. The last point is actually a restriction (or safeguard) of Sony's SDK libraries: the EE-side file I/O library refuses to work if the IOP is running a different version that what the EE library expects. That's a check the homebrew library is missing, and this lack can result in very odd problems if one tries to run it against an updated IOP kernel :disgust:.
Alright, thank you very much. That is strange... but I'm quite sure that the network adaptor almost never connects properly to my network and my notebook if I don't set the link speed and duplex to anything below 1Gbit. Perhaps you have a PCMCIA network card that works differently from the retail SCPH-10190 - I think that I read somewhere that there was a Gigabit PCMCIA card for TOOLs. Well, if you do embark on such a project, I certainly won't mind contributing! Those are great ideas. As for me, I was thinking of patching the OSD - so that users can install their own programs without needing to tinker with the Sony KELF stuff. I knew that the TEST/debug was capable of debugging Playstation 2 games and it has an architecture that is similar to the retail console's, but I don't actually know what it's debugging environment is like. Ah, well... I re-read your original message, and I think that I was mistaken (I'm now quite brain-dead D. I thought that you meant that your IOP-side debugger will most certainly cause the IOP to enter a deadlock as all the SIF channels will be blocked by the BREAK operation. If I'm not wrong, you actually meant that the entire IOP might become 'dead' when SIF2 gets stalled by requests that violate the design of the retail console's SIF2 channel and since the RPC interface over SIF0 and SIF1 is not functional when the IOP debugger has halted the IOP during a BREAK request. Thank you very much. Yes, today I have learned much about the TEST and how debugging is supposed to be done on one. I believe that it might be a language barrier that we are experiencing. What you said is probably what Sony actually meant, unless the TEST has additional functionality hardwired to the RESET button. Ah yea, that has been another thorn in my side for too long too. :X By the way, I was working on documenting the IOP-side modules in web pages. But I haven't gotten back to working on that project for quite some time already. I do intend to complete it though, since it seems like nobody will be doing that. If you have anything that you would like to get documented, I don't see why it would be a bad idea for us to publish everything together.
On Expansion Bay consoles, when the SYSCON registers are toggled by poweroff.irx the button acts like a ATX PC power button instead of just a reset button when the console is playing a DISC and the HDD is not enabled. That allows the kernel to flush any buffered HDD data before shutting down. That's impossible on PCMCIA consoles as turning the HDD on does not affect the SYSCON behavior. It just resets as it would before. On a EXP BAY console if you have the HDD active and EE crashed, the only way to shut down the system is hold the power/reset button 3 seconds or turn off the switch on the back. Edit: Regarding my PS2 hiatus, I am taking a time off due to a stupid incident at PSX-SCENE. Regarding FMCB HDD and related stuff.
Its currently in storage, but I'm sure its an ordinary DTL PCMCIA card for use with TOOLs. The exact same card works with retail 10k as well. Did you ever try it against a different brand of Laptop/mainboard or switch? FMCB-style? I would like to do something similar, especially to the HDDOSD. Exactly. Although as I said, I'm not sure whether its really a limitation of the TEST's SIF2 channel. I think that this situation can simply never occur on the TOOL, so they didn't bother to correct or even test for it. On the TOOL, there is a special device visible in IOP memory that functions as a communication channel to the host. This device is interfaced to the IOP DECI2 manager via DECI2DRP. So when debugging IOP code, the data is simply forwarded between the ISDBGP implementation (inside rom0ECI2), the IOP DECI2 manager (again, inside rom0ECI2), and the special device via DECI2DRP. The ISDBGP implementation uses partial reads for its packets, and these simply seem to work with the DECI2DRP backend. On the retail machine with Kermit, it works a bit differently. All communication is handled on the EE, including DECI2. The resident part of Kermit actually "virtualizes" the SIF2 channel: normally (unchanged retail or even TOOL EE kernel), the EE kernel is connected directly, and IOP-side communication is performed via DECI2DRS (which acts just like DECI2DRP as a DECI2 channel driver). With Kermit, I also use DECI2DRS on the IOP, but the EE kernel is patched to call into my own code instead; which also does what the EE kernel would otherwise do, interface to SIF2. That way, I get two pseudo-channels on the EE: one "virtual SIF2" connecting to the EE kernel debugger, and the "physical SIF2" that connects to the IOP. The problem on retails is now the following: if accessing ISDBGP, the packet arrives (via the Kermit-proprietary PC communication mechanism, either serial or 1394) on the EE, then is sent over the physical SIF2 channel to the IOP. There, it is taken by DECI2DRS and forwarded to the DECI2 manager, which then forwards it to ISDBGP. The debugger implementation then uses the official DECI2 API, but in a way that violates Sony's published specification (it does not read complete packets). DECI2DRS notices the partial read, and copies only as much data as requested. However, the SIF2 channel on the EE side always signals "transfer complete" afterwards; that is, it signals an interrupt and notifies the EE's DMA controller that the transfer is finished, even if less bytes were read from the IOP than programmed for the transfer. The excess bytes simply seem to vanish into thin air. Result is that, once the IOP wants to read the remaining data, DECI2DRS tries to read more data, but the EE cannot send anything; technically, the channel is free, but the interface automatons on both sides are confused and disagree about its state. This leads to neither side being able to send anything, until the next reset. Thank you, I think you are right. I would actually be interested in a thorough documentation on the CDVD subsystem: SCMD+NCMD with parameters, state diagrams (including stuff like "door open" or "waiting for spindle to reach stable speed"), and a full documentation of the various CDVDMAN exports. Like which function does what, in which context ("Can be called in interrupt context", "Is only safe to call if the following semaphore is held/not held by the caller" and so on) and so on. It would be especially interesting to see the full private interface between CDVDMAN and CDVDFSV; there is a single CDVDMAN export that provides access to a lot of internal state, like a certain CDVD event flag, and I would really love to see how that fits together. The IOP somehow seems to track whether a request originated on the EE or on the IOP, and even (at least with newer CDVDMAN versions) provides means to wait for one, but not the other to finish. Thank you, that makes it a lot more clear. I didn't know they introduced that behavior later (or should I say: forget about it in the first version? :tongue.
Honestly I think it has more to do with the fact that the original PS2 design never had HDD planned as a storage medium. I believe SCPH-18000 keeps that behavior only to stay in line with 10000 and 15000 units.
I don't remember for sure, but I'm somewhat sure that I did try that too with my newer Lenovo Z460 laptop. :/ I don't have another network router to test with, as my other network equipment are older Megabit devices - they were all previously used by my family. I'll perform another series of tests again soon. There is, however, a chance that my adaptor is defective. It appears to belong to a BBNAV unit, as the HDD is from 2005 and had the BBNAV installed on it. That HDD seems to be faulty after all, and the reason why it 'pauses' with the HDD activity LED on is because the SMART ENABLE command is failing (The disk just aborts the command and no interrupt is asserted). :/ I did get another HDD unit set (SCPH-10210), but the SCPH-10190 PCMCIA card is missing as stated by the Japanese seller. I do, however, have a console's dummy PCMCIA card! So some console on this planet probably has a SCPH-10190 wedged in it's PC CARD slot. By the way: I just remembered why I wanted to rewrite the SMAP driver. Other than a lack of performance, we have: 1. The SMAP driver might not work properly if the Ethernet cable was not connected to the console when the driver is loaded. 2. The SMAP driver might not work properly if a valid link was not established when the driver is loaded. 3. Disconnecting the Ethernet cable might cause the SMAP driver to malfunction. It's all because the SMAP driver cannot detect the change in link states and does not handle them. Plus it's interesting to know that the Sony retail SMAP driver has revealed that the SMAP's DP83846A has got a hardwired default configuration, which will be used if not configured by software. Those auto negotiation sync hacks in the homebrew SMAP driver are not needed anymore - the auto negotiation sync code isn't even in the Sony driver to begin with! Uh. I should have been a bit clearer on this. :nightmare: I meant to say that I would like to patch the HDDOSD, to allow users to install their own homebrew software onto the HDD... but without needing the developers to ever touch the KELF stuff. (In other words - they can use a regular ELF in place of the KELF) Thank you very much. This is quite a detailed explanation of the problem. Have you checked out the pseudo code of CDVDMAN and CDVDFSV by romz? I found it quite informative when I was developing PS2ESDL. His site went down somewhere last year, I think. But there is a mirror here: http://lukasz.dk/mirror/cdvdmania The downloads page is here: http://lukasz.dk/mirror/cdvdmania/downloads.html A proper and complete documentation of all CDVDMAN functions and the behaviour of the CD/DVD hardware does not exist though. :sorrow:
