Initializing the PlayStation 2 from cold boot

Is there a way to avoid sceCdForbidDVDP being called on a dev/test system? I'm wondering whether the DVD playback trick can work on a dev/test system, or whether we'd have to use master disks.

 

The OSDSYS program will boot any memory card-based update before doing anything (including calling sceCdForbidDVDP). The exception to this is the PSX, if I remember correctly.

I believe that @kHn noted that DVD Video playback is disabled by default on power-on, within the hardware. So the call to sceCdForbidDVDP is to re-disable it at every boot (including soft resets).

He also noted that it is possible to use a master disc as a DVD Video disc. So it seems that the DVD Player does not actually use scdCdReadDVDV(which does not work on a DEX).

 

Changelog for v0.93 beta:

• Added code for allowing ROM 0100J and 0101J to boot DVD players, even though these consoles do not have a DVD ROM.
• Added substitute code for S-command 0x27, for booting PlayStation discs on the Chinese console (SCPH-50009).
• Changed some buffers from being global to local, to save on runtime footprint.
• Increased alignment to 64 bytes for the memory card table structure (used with sceMcGetDir), since the structure is directly transferred there via DMA and it involves a D-cache writeback.

Known Limitations:

• Booting PlayStation and PlayStation 2 discs on the Chinese console (SCPH-50009) has not been tested.

Download Link:
OSD Initialization Sample Package: http://www.mediafire.com/file/jk5jm1nejgi4as6/[180210]osd.7z

 

Happy Chinese New Year to my friends and everyone ! @sp193 @AlGollan84 @kHn .

 

新年快樂!

 

Changelog for release v0.93 beta

• Renamed the "unknown02", "unknown03", "unknown04" and "unknown05" fields to RcEnabled, RcGameFunction, RcSupported and DVDPProgressive respectively.
  • Please read the limitations section about the "RcEnabled" field.
• Corrected definition for OSDConfigSave.
  • invalid = 1: OSD configuration is not initialized (browser will show the first boot screen).
  • invalid = 0: OSD configuration is initialized & valid.
• Added sample code for enabling diagnosis.
• Added sample code for clearing the DVD Player progressive setting.
  • In the browser, the menu option for this is only available if the user enabled it with the DVD player.
    
  • The DVD Player progressive setting is usually cleared (when specified by the user) by the browser upon booting the DVD player, but that is likely because Sony wanted that behaviour.
• Added sample code for testing for hardware support for the remote control.
  • If sceCdRcBypassCtl() fails, then RcSupported and RcEnabled will be set to 0.

Known Limitations for this release:

• Booting of PlayStation and PlayStation 2 discs on the Chinese console (SCPH-50009) is untested.
• Remote Control management does not actually do anything (sceCdBypassCtl not implemented).
• The actual purpose of OSDConfigGetRcEnabled & OSDConfigSetRcEnabled is not clear.
  • I am not entirely sure what this is.
  • In ROM v2.20, it seems to have a relationship to a menu that is labeled "Console" and has the text "Remote Control,Off,On".
  • However, I could not find the necessary conditions for accessing this menu.
  • In the HDD Browser, the "Remote Control,Off,On" menu text exists, but does not seem to be used.
  • On my SCPH-77006, this setting is disabled, although the other two remote control-related settings are enabled.
• Valid values for the timezone setting are currently unknown.
  • Likely 0x00-0x7F are valid values, but what do they really represent?
• It is not clear why some checks on some libcdvd function status fields seem to vary between browser versions.
  • As of now, this demo follows the HDD Browser (since it was made to work with all PlayStation 2 models).

I have tried very hard, but could not figure out what the "RcEnabled" field is for. I only know that it seems to be related to a menu option that reads "Remote Control", and has the options "No" and "Yes.
However, I have never seen this menu appear before and could not figure out when it would be shown.
Hence I named this field "RcEnabled" because of "Remote Control,Off,On", although it does not seem to be used by any browser for processing anything.

Download Link:
OSD Initialization Sample Package (2018/02/12): https://www.sendspace.com/file/uj2vgb

***

Happy Chinese New Year!
新年快乐!

 

I don't think anybody has mentioned this before, but if anybody builds software that makes the SIF subsystem very busy, do not busy-loop on the EE-side!

The EE is so fast that it seems like a cycle of quickly enabling/disabling interrupts can actually cause the interrupt handlers to not run at all.

This seems to have caused a hang under specific conditions:

Code:

    //Transfer to IOP RAM
   ...
   while(SifSetDma(&dmat, 1)==0){};

I have established that this causes a hang, since putting a printf() within the parenthesis inhibited the freezing (and it's returning -E_SIF_PKT_ALLOC):

Code:

    while(SifRpcGetOtherData(...) < 0){}

I believe other SIFRPC functions like SifCallRpc are also affected because it will use _rpc_get_packet() internally. _rpc_get_packet() will suspend interrupts to protect itself, but the packets can only be freed if SIFCMD can complete...

So for my project, using nopdelay() to slow down the enabling/disabling of interrupts seems to be sufficient (since we currently do not have DelayThread() implemented):

Code:

    //Transfer to IOP RAM
   ...
   while(SifSetDma(&dmat, 1)==0)
        nopdelay();

 

So the idea is that the EE core runs so fast (compared to the EE INTC logic) that after enabling interrupts they won't trigger for a few cycles, in which the EE might execute all the instructions to the next interrupt-disabling instruction, effectively causing interrupts to never get enabled.
From what I know, a CPU polls the interrupt flags every few cycles - this is also how DECKARD emulates the MIPS IOP. So the EE might be made in such a way that after enabling interrupts there is some significant delay to the point interrupts are actually enabled, causing this. Such delay is most likely added as a work-around for other potential bugs. There may not only be a delay, but also a prevention of interrupts activating while the EE is executing certain instructions, so that they never get interrupted.
Isn't the code in the looped functions a lot longer than a nopdelay()? ...but I guess, if the interrupts are disabled near the beginning of the function and enabled near the end, there would be only a few instructions over which interrupts will remain enabled. Some of those instructions will be branches and jumps, and the EE probably has interrupts disabled over the jump and the branch-delay slot. Due to the short-loop bug fix, the loop would have a few NOPs inside, but those seem not sufficient. I would also guess this might be related to the short-loop bug, or more specifically, to its cause. Maybe the EE behaves differently than usual around branches, so interrupts might be disabled for a few cycles before and after a branch (keeping in mind the 5-stage pipeline). Interrupts may also be disabled near other instructions.
(This is a guess, so I hope I haven't written anything wrong.)
Do you have a rough idea how many NOPs are needed to prevent this behaviour?

 

It felt that way because I would lose control of the EE and IOP via RDB, whenever it hung. It used to most frequently hang around SifRpcGetOtherData, which was part of a new test.
I checked that function before for problems (it wasn't working in 2014), so it should be fine.

It also seems to happen on the IOP, when I busy-loop around sceSifCallRpc. But on a lesser degree.

Yup, it just goes into the allocation function, which totally runs with interrupts disabled. Since allocation fails when there are no packets available, it exits immediately.

It doesn't need to be at least 5 NOPs, but can be even none if there is some instruction that isn't a NOP, in the branch-delay slot.

Alas, only Sony would know what really happened.

No, sorry. nopdelay() results in a lot of NOPs, so it isn't in my control.

 

This is a very strange problem .
Since syscall may need lots of cpu cycles, I think it is a software problem not hardware .

 

The syscall handler runs with interrupts disabled too.

But, it is possible that it's just the problems within RDB getting triggered off. It's bugged, like with all my software.

I was just very upset about how long I was taking. Not only did it burn nearly a whole day of my free time, I couldn't complete what I wanted either. The system did not work in the end.
So maybe it is best to just keep this as a minor note.

 

After searching , I found this
ee side SifSetDma
iop side
iop side has a check , but ee do not .
Why ee do not need this check ? This is a bug or feature ?

Code:

u32 SifSetDma(struct sifman_DMA *psd, int len){
...
if (32-vars.index < len) return 0; //no place

 

I found these also:
nopdelay
This seams a very large delay .
Maybe we can replace nopdelay with SifDmaStat.

Code:

 //Transfer to IOP RAM
   ...
   while(SifSetDma(&dmat, 1)==0)
     {
       while(SifDmaStat(3) >= 0);
   }

There are lots of code , call SifSetDma without check return value.
eg this.
Ah , lots of bugs
(Finally , I get ps2 sdk from other post)

 

The PCSX2 code may not be correct because not everything was completed (and so they probably never tested it). However, I think it is still a very useful resource.

I disassembled SifSetDma from ROM v1.01J (similar to v1.00J) and it seems like there is missing code from the PCSX2 EE kernel.
It should return 0 (failed to queue) around this point.

Yes, but you need to know the transfer ID for the other transfer(s).

CDVDFSV also does this, although not always:

Code:

          for (;;)
          {
           CpuSuspendIntr(&oldstate);
           r = sceSifSetDma(&cdvdfsv_rdp2sdd, 1);
           CpuResumeIntr(oldstate);
           DelayThread(500);
          }

(This was extracted from romz's CDVDFSV module, previously hosted on cdvdmania.ru).

Indeed. So they have to be slowly found and fixed. But before that:

...this function is not an official function. And so I wasn't sure if we should keep them or not.
fileXio was also based on the old FILEIO module, but we extended its functionality:

• Supports the newer functions (e.g. devctl, ioctl2, rename, mount, umount) after chstat.
• Utilizes 64-byte alignment instead of 16-bit alignment, since it uses SifWriteBackDCache() - since the cache lines are 64-bytes in length. Otherwise, this can cause cache coherency issues when cache writeback is mixed with accesses through the uncached memory segment.
• Semaphore locking works correctly. The original could cause a deadlock if SifCallRpc failed.

However, the fileXio RPC is not a multi-threaded RPC like the new FILEIO that Sony distributed for games. That one allows multiple accesses to different devices, at once.
So there was also this question, of whether fileXio should be reworked entirely.

 

Actually ,we do not .
Since transfer ID are a number between 1-31. We can give a random number
If one dma transfer has done , we can queue another .

maybe the code should be :

Code:

count = _SifDmaCount();
lenloop:
-------------------------------------------
lenloop:
count = _SifDmaCount(); 

Please do not ...
Maybe we can use a hacked version of sceSifSetDma which will always wait before return .

 

The fps2bios code that is in PCSX2 is unfinished. Also, there is no clear license, preventing inclusion in free software repositories, so I'm probably not going to fix it any further than for it to compile on gcc 3.2.3.

 

I ran the code on my DTL-T10000H and there were no problems (without adding more delays anywhere on both the IOP and EE). So this might be just causing some issue with RDB...

I regret talking about this issue in the first place. Please ignore it.

The "return 0" (queuing failed) is missing. This code never worked correctly and there may be more problems with it.
If you really want to know what it does, please disassemble SifSetDma on your own.

But without the newer FILEIO design, one cannot access two devices at once. This is a performance bottleneck, when you copy files from one device to another.

Sony likely did not consider this a problem in 1999. Either because they initially designed each device to have their own I/O libraries (libmc, libcdvd etc) or they did not consider that anybody will need to copy files (PS2 games do data streaming with only libcdvd).

However, rewriting FILEIO (EE RPC client + IOP RPC server) involves a lot of work, which is why I never completed it.
Currently, things do already work anyway.

I'm trying to avoid hacks, since they are hacks. When you work around a problem, the problem wasn't actually solved and it may still cause problems in other ways.

But thank you for trying to help.

 

@sp193
I have some question about _SifSendCmd
1) Is this a bug when multiple thread call SifSendCmd simultaneously ,
since iopbuf maybe overwrited before it is processed ?
2) what is these flags mean ?

Code:

      SIF_DMA_ERT | SIF_DMA_INT_O
   

----------------------------------
if flag SIF_DMA_ERT | SIF_DMA_INT_O is set , sif dma will stop automated after the transfer is done ?
But when it is reenabled and how ?

 

No, this does not happen due to how the SIF channels work. I cannot seem to find where I read about it, but ERT disables the DMA channel. The DMA channel has to be enabled with sceSifSetDChain(), which is why it is called after the packet has been copied out of the SIFCMD receive buffer: https://github.com/ps2dev/ps2sdk/blob/master/ee/kernel/src/sifcmd.c#L146

The IOP side probably has something similar, but for SIF0 (IOP->EE) instead.

SIF_DMA_INT_O enables the IRQ option of the QWC register, which causes an interrupt to be asserted upon transfer completion, on the IOP side.
This will cause the SIFCMD handler on the IOP side to be run.

The IOP side probably does something similar, but for SIF0 (IOP->EE) instead.

 

There is some info about the SIF DMA in the IOP_DMAC document in the archive attached to the first post here: http://psx-scene.com/forums/f167/speed-iop-dma-relaying-156928/
If I remember correctly, when a new command packet is added, it gets appended to the list of packets to transfer over SIF DMA and the ERT (End of Reference Table) tag is removed from the last but one packet and added to the last packet.
The ERT tag (from the EE) only marks the end of the current (IOP destination chain) reference table (i.e. it will clear the CHCR.start/busy bit), so sending a new one will just start the next transfer as usual. Calling SifSendCmd() or calling SifSetDma() either, multiple times will not cause problems, because the SIF channels have to be enabled from both IOP and EE for a transfer on a given channel to start. The IOP has to set a bit in 0xBD000040 to enable transfer-starting. There is a separate bit for each channel. The bits from the EE CHCR registers can also be read from the 0xBD000040 register (0xB000F240 on EE side). The IOP DMA channel CHCR start bit is separate from this system. When the ERT flag is encountered, I think the IOP side bit of 0xBD000040, together with the IOP DMAC CHCR start bit will be cleared, effectively preventing further transfers on that channel. (I am not entirely sure if I am remembering this correctly.)
There is more information on the 0xB000F240 register in the SIF_SBUS document, but I haven't yet organized it... but if anyone happens to need it, I might try to prepare it and attach it.
The SIF DMA functions from the EE kernel can be seen here: https://github.com/PCSX2/pcsx2/blob...fee8/unfree/fps2bios/kernel/eeload/eekernel.c