PlayStation Development Network

Great that you are still working on that beast! I'll need to implement your findings about the MDEC formulas (when I turn back to working on no$psx, at the moment (=next some months) I am busy with dsi support for no$gb).

Yes, "Not used (should be zero)" was meant that the bits are unused and they don't affect the result. But if you are writing to that registers, then you must put something into the unused bitfields - which should be filled with zeroes (just by convention, because Sony is doing that way, and because writing other/random values would look messy). And, using zeroes might become important in case Sony would release a "MDEC+" revision that uses that bits for extra functions (of course, that's extremly unlikely for 20 years old hardware).

no$: can chk also about EOR/EOF bit , for example Resedent Evil 1: after last cutscene before menu, it still play xa audio. i dont know what real cd dsp/hc05 does , but i just stop play xa sound. maybe if you will find new details, add please it on tech spec about Ps1)) ?

also: don't you know, combination of (SeekL + gelocL) or (SeekP + gelocP) - so does it update loc? or head stay around one possition and loc is +/- few frames?

cybdyn wrote:no$: can chk also about EOR/EOF bit

The cdrom HC05 firmware doesn't seem to process that bits at all.
Games can process that bits on the MIPS CPU side though (but, I am not sure if that would be good idea - if the audio/video streaming is done without error correction & without read-retries, then the EOR/EOF bits might never arrive at the MIPS CPU in case of read errors - I don't know if the PSX is really streaming without error handling though).

cybdyn wrote:also: don't you know, combination of (SeekL + gelocL) or (SeekP + gelocP) - so does it update loc? or head stay around one possition and loc is +/- few frames?

SeekL/SeekP are doing seeks. It doesn't matter if you combine them with getlocL or getlocP.
And that SeekL/SeekP stuff should be described quite well in current psx-spx version, or is there anything unclear?

i just thougth LC mechanism uses only combination seekl+getposP. but i see it uses read 1b.
just some games send getposP 10 times or so, after seekP, just wondring if i need update or increment pos. , or it stays on same pos, and only frame changes around last position of seeking..

about EOF flag, just idea. maybe this bit make from 0x64 to 0xE4 , and we need play as xa and send as data at same time (int1) to let know mips-cpu program "this is the end"?

Hey Akari, I'd like to help out more with the reversing and posted some stuff on the psxdev.ru board. Could you maybe have a look? That would be great.

LostTemplar wrote:Hey Akari, I'd like to help out more with the reversing and posted some stuff on the psxdev.ru board

I upload lastest researched data to svn. Most interesting are in 00_control.odg This is core control circuits. Still don't know exactly how they works.

LostTemplar wrote:Could you maybe have a look? That would be great.

look at what?

Do you plan to decap GPU, GTE, RAM and SPU later on? I think it'd be even more helpful for emulation than decapping CPU which was already pretty well known. Especially the texture cache is still mostly unknown.

They already decapped the GPU as far as I know. As for decapping the DRAM, I don't see any real reason to do so. The SPU might be an interesting one though if that hasn't been done already.

Shadow wrote:They already decapped the GPU as far as I know. As for decapping the DRAM, I don't see any real reason to do so. The SPU might be an interesting one though if that hasn't been done already.

Could you give me a link to this decapped GPU code? I only see CPU and MDEC in this thread.

PSXBA wrote:

Shadow wrote:They already decapped the GPU as far as I know. As for decapping the DRAM, I don't see any real reason to do so. The SPU might be an interesting one though if that hasn't been done already.

Could you give me a link to this decapped GPU code? I only see CPU and MDEC in this thread.

http://board.psxdev.ru/topic/7/

These are just pictures where is an actual code like the the code available for CPU and think GTE on Github.

PSXBA wrote:These are just pictures where is an actual code like the the code available for CPU and think GTE on Github.

Only photos of top level metal is available. This is not enough to start reverse of GPU. If you are interested we can asc our decaper to polish metal and take photo of M! and then polysilicon level.

By the way - I resume MDEC reversing process after few month of Xenogears sprite algorythm reversing )

Akari wrote:

PSXBA wrote:These are just pictures where is an actual code like the the code available for CPU and think GTE on Github.

Only photos of top level metal is available. This is not enough to start reverse of GPU. If you are interested we can asc our decaper to polish metal and take photo of M! and then polysilicon level.

By the way - I resume MDEC reversing process after few month of Xenogears sprite algorythm reversing )

Yes I am very interested thank you. Also do you plan to ever go back to GTE reversing, judging from the ogamespec/pops-gte repository it seems to be still incomplete.

PSXBA wrote:Also do you plan to ever go back to GTE reversing, judging from the ogamespec/pops-gte repository it seems to be still incomplete.

Noone ever tried to reverse CPU GTE. Org wanted to do this but he seems to be busy now. Pops-gte is his project too, I dont know if he ever will work on it again.

PSXBA wrote:Do you plan to decap GPU, GTE, RAM and SPU later on? I think it'd be even more helpful for emulation than decapping CPU which was already pretty well known.

The current theory is that the GTE is part of the CPU.
But the CPU is huge, and at the moment, Akari and org are having analyzed the MDEC section only.

nocash wrote:

PSXBA wrote:Do you plan to decap GPU, GTE, RAM and SPU later on? I think it'd be even more helpful for emulation than decapping CPU which was already pretty well known.

The current theory is that the GTE is part of the CPU.
But the CPU is huge, and at the moment, Akari and org are having analyzed the MDEC section only.

Only this part of cpu has been analised to date. A lot of unknown area still left untouched.

no$ : i found game like "Felony 11-79", whant it plays interleved xa stream from cd , it doesnt send any SetFilter command (to setup file/channel), and to play cdxa stream it uses mode = 0x40 (adpcm enable), the xa stream consist of 4 interlived files, not channels! ususally games use file...

Akari wrote:

nocash wrote:

PSXBA wrote:Do you plan to decap GPU, GTE, RAM and SPU later on? I think it'd be even more helpful for emulation than decapping CPU which was already pretty well known.

The current theory is that the GTE is part of the CPU.
But the CPU is huge, and at the moment, Akari and org are having analyzed the MDEC section only.

Only this part of cpu has been analised to date. A lot of unknown area still left untouched.

I see so GTE will be decapped sooner or later, but could you analyze the GPU too, that'd be invaluable.

nocash wrote:

PSXBA wrote:Do you plan to decap GPU, GTE, RAM and SPU later on? I think it'd be even more helpful for emulation than decapping CPU which was already pretty well known.

The current theory is that the GTE is part of the CPU.
But the CPU is huge, and at the moment, Akari and org are having analyzed the MDEC section only.

I think it's pretty much certain that the GTE is inside the CPU - the MIPS coprocessor interface is quite complicated, and none of the signals are present on external pins of the PSX CPU. In addition to this, mtc/mfc don''t generate any bus cycles, so you can't even sniff what's going on externally and emulate it.

I'm also pretty sure that the big block diagram of the PSX that Sony used in their early developer presentations had the GTE drawn as part of the CPU block, but I can't seem to find a copy of it online to check.