PS Hard Disk Drive

Hi. Now this is my first post here, but I have a team going at the moment helping me build and develop the worlds first, PlayStation 1 Hard Disk Drive modification.

If you have skills or even knowledge in this area (you should know what I mean), then please ask to join the dev team at http://haunted360.com/.

Please send me a message, or whatever you want that will help me. Credit will be given if you help A LOT.

I have been reading, and it also seems that some of you still have the original dev. (DTL-xxxx) boards in your computers. NEVER, thrown them. Even if they break.

They are rare collectors items that can never be replaced or reproduced. They also sell for a very high amount of money...


So if you want to help out or are interested (PLEASE. Only skilled people who know how to program, or know their electronics or know a lot about PS1/X's) can join or ask...


Thanks, Haunted360.

 

Haha, I had a feeling you would reply. You seem to be 'on top' of the PS development. haha.

I was going to intercept the CD-ROM but it was to hard. I needed to replace the IC's and uh. Huge mess... Above that, the PS game are programmed to command the drive. So stop, start etc... I would not know how to begin! The drive, also runs at a MAX rate of 353 KB/s. I just would not know where to begin...

Instead, I decided to go through the PIO port.

The Parallel Input Output port runs at 3 MB/s and has FULL control and access to the PS local BUS.

WAIT. Psygnosis did not use a CD-ROM drive but emulated it?!?!? Any details or images etc?!?!?!

If you are interested in helping us, PLEASE join the development of it - if not, any help is appreciated :thumbsup:

 

Oh man, thats awesome. :dance:

There's the proof I guess that the PIO port has access to the BUS. haha. If it can read/write to the cards via the PIO port then yea. Awesome.



If you don't mind, could you go onto MSN so I can chat and ask you some more questions. This is a little slow going back and forward...



Thanks for your help - appreciated.

 

If you're using the parallel port, then it won't work on SCPH-9xxx and newer consoles.
So making a WODE-like device would have the best compatibility for all versions I would think.

 

So basically you need someone to join your team and do the work for you? >_<

Also you're going to have to actually interface with hardware, that's how this kind of thing works. I'm pretty sure the PIO port can NOT be used to emulate a CDROM, at the very least without a new BIOS and debug library linked to code. For compatibility with existing games (I assume loading games is the idea) you'll have to directly encode the serial data after the RF stage (laser -> RF -> controller). If RF and controller are in one package then it's time to give up unless you are lucky enough to find that all games use the BIOS interfaces.

 

That was my first reaction too.

 

I can't efford too much help, but there is arcade board's exist, which are based on PSOne hardware and have HDD connected. If my memory doesn't lie to me, it has Am53CF96 based SCSI controller.
By the way, wouldn't it be much simpler to build native CD-ROM interpreter? Connect HDD to internal PSOne bus (using some sort of 16>8 bit data bus converter), PSOne CD-ROM commands will be converted to HDD by some microcontroller stuff or something...
But there will be a lot of trouble - you can't just connect HDD to PIO or even internal bus - you'll need some logic to get PCM stream (games used AudioCD tracks say hello to you^_^) and send it in I2S format to synthesizer. And in any case you'll need to write some sort of OS to manage and run images on HDD. And don't forget about multi disc games - how do you want to switch between images if game already running?

 

No. We have already got a chip with microcontrollers already made to interface the PS to a PC VIA Parallel Cable...

I am asking if anyone has great skill and would like to help or join the dev team on it. Be part of the worlds first, PS HDD mod.

 

No dont worry. I did not forget about multi-disc games. I would have to look into that, but my option is that the lid close sensors button would have to be wired to a controller that will detect code that the programmers send.

All the advanced stuff comes later.

It is just getting it to work first or get some sort of a prototype built...

 

:facepalm:
he was looking for members on this site to contribute because this seems to have a few members with original ps1 debug units/hardware/manuals. the information these members may be able to provide is invaluable.

the pio port isn't hardware????????
from your post it seems you don't know how
"this kind of thing works"

why would we have to emulate the cd-rom? and even if we did choose to do it that way its VERY possible without a new bios.

Cool story, i hope not all 5000 of your posts are of that quality.

This is a long term project, not like its being done overnight. if you generally have a valuable input then feel free to post. but responses like
For compatibility with existing games (I assume loading games is the idea) you'll have to directly encode the serial data after the RF stage (laser -> RF -> controller). If RF and controller are in one package then it's time to give up unless you are lucky enough to find that all games use the BIOS interfaces.

are ahead of the curve and worthless at this moment.

The simple matter of this project is that it can be done, we intend on doing it, we have started gathering parts and gathering information, not started to implement a cd rom emulator or solution for a ps1 to mount a 3mb/s storage device via the pio.

cheers

 

*EDIT* Someone edited my post (admin / moderator) and removed whatever I said here...

 

Attaching to the parallel port should allow you to achieve the goal to some extent.

You might be able to dma the red book audio to the SPU, you can definately read the audio that is playing from there.

Switching disc games can be handled by going into a menu, caetla style (controller button combination ).

libcrypt games will be a bit of a challenge, they use subcode errors. However it's doable as long as they go through the BIOS. If the games don't go through the BIOS then you'll need to do runtime patching of the code.

First thing to do would be getting homebrew demos running off the hard drive, ridge racer is a good first game to try as it's a single load and only accesses the cd during game play for music.

 

Thank you! Thats very helpful. I was going to use Crash Bandicoot 3 to do advanced testing as it is very heavy on the processing side, followed by Oddworld: Abe's Exodus as that is a multidisk...

As for the libcrypt, those are only prominent on the newer games. So yes. Ridge Racer, Oddworld, Hercules (all on DEMO 1 as known in Europe/Australia where you and I are located) will be fine.

Again, all in testing and slow development :dance: (< I do like this emoticon, haha)

 

So prove me wrong - I'd love to be wrong in this instance. So far though it sounds like you're saying "we'll worry about that later" when people are telling you why your current approach won't work, which doesn't bode well.

 

agreed.

i like the sony forum here because it's not like the 360 forum.
don't make it so :/

 

You mean parallel port? Multiple microcontrollers?

If you do end up having to emulate the CDROM you'll have to move up to a FPGA since MCU are far too slow.

Off-topic but actually so called debug units are useless for this project, and pretty useless for anything else related to PS development except testing QA coasters.

From your post it's clear you didn't understand that I meant "intercept the CDROM". The PIO port can have memory and registers decoded to it (yes hardware :-0), and you can use it to bootstrap code, but that's it. It can't magically intercept and override the CDROM controller since they are at best in parallel.

In the context of my post I meant "emulate a CDROM" as in run commercial games, not serialize raw disc data to directly feed the CDROM controller....

You may have to do exactly that however because (beating a dead horse here) games may access the CDROM controller directly and directly modifying games for your project would obviously be impractical. Trying to software-emulate CDROM functions will require games to use BIOS interfaces or some other hookable code (like modifying the linked library), and your code will steal CPU cycles (a significant amount with PIO wait-states) and memory leading to instability. Since MCU was spoken this is what I presume you guys are planning and I'm not confident it's "VERY possible". What do you plan? To allocate memory on the heap like an Action Replay? I don't think so.

I hope at the very least you guys chose a MCU with a slave parallel port you can decode to the PIO because otherwise it's worthless, you cannot use a MCU for address decoding, PC interfacing and real-time work all at once. A MCU under the best conditions already innately fails at address decoding and emulating simple hardware interfaces.


This stuff is all common digital engineering sense so it doesn't sound like either of you two are ready == you require the requested help.

 

So uh, did you want to join the dev team then?

We have 4 members so far so dunno. Someone just joined from here, so it is up to you.

You seem to be on the hardware side of things so we could use another hardware 'engineer'. :thumbsup:

Would help get the project done faster and better too.


If so, send us an email from my website asking.


However, thank you for that detailed info. Very helpful Calpis:dance: (< again, awesome emoticon!)