PS Hard Disk Drive

interface board between the psx and the pc, practically a freewing/ar combo.

the mcu's were just for the interface board, we understand that if we choose to emulate the cd-rom we will need an fpga, were thinking of an altera cyclone II.

useful-ness: 1

The pio port has access to the entire local bus, its proven that a memory device can be mounted from there,
next step:
iso (or similar) emulator.
after:
sd/ide controller.

I doubt that that they access the cdrom controller directly, but even if they do, there is definitely a work around without modifying games.

your first worthless post was before either of us had replied to any direct obstacle to our current approach. no one has so far even said definitely any of our approaches won't work, there has been a load of might's/i think's on one approach,but also positive responses on the same thing.

i must stress the point that this is a long term project (again apparently), if there's something we need to learn to implement a function/feature, were happy to learn it, when the time comes to when we've reached an obstacle like dropping memory, were happy to hear others opinion/truths as to why its happening/not working.

 

However you guys approach this, it sounds like an awesome idea.

Keep us up-to-date.

 

^^yeh cheers i discussed that with haunted, theres one that i know of that goes via pio port and another via serial, i know that the serial one requires some extra wiring on the ps1 mobo.
whats also pretty cool is that the gamax ps1 vcd adapter includes a Infrared remote and receiver which goes into a memory card slot, odd how the slot doubles as a controller input aswell.
other pio/serial stuff of interest:
http://www.gocybershopping.com/customer/product.php?productid=1506&cat=161&page=1

http://www.gocybershopping.com/customer/product.php?productid=1507&cat=164&page=1

http://www.gocybershopping.com/customer/product.php?productid=66&cat=164&page=1

 

I have managed to play VCD's off of a CD-ROM with a modchip with a boot loader on the CD. Took me so long to learn how and I did it when I was maybe 16. Searching the internet high and low for answers finally figuring it out...

Sucks because you can only fit 700 MB, but then again - maybe it is even possible to play longer VCD's VIA the HDD or SD Card mod once it is going...

Maybe even DVD quality. Again, all programming once the hardware has been built...

 

I'd like to see a drop-in solution to replace the CDROM. It would be very nice to eliminate the least reliable piece of the PS1. But as with all things of this nature, if it doesn't atleast equal the original then it is far less attractive. If a large amount of games do not function then it is far less attractive unless it were something using the parallel port which meant you could easily switch between it and other means for the games that it didn't support.

 

Thanks for the offer but this is something I wouldn't spend too much more time thinking about. It's not only very difficult, CDROM emulation would make it pretty non-repeatable so few people would be able to appreciate it, or in the chance that games will tolerate hooks there's no way there will be full compatibility...

If you use the "Comms" interface that's pretty bad, but Comms via a MCU is horrible. You might want to look into a FTDI FIFO chip since it doesn't need firmware and you can always switch it out for something non-proprietary. This would simplify your interface to a 74'139, FTDI, Flash and maybe a SRAM.

CDROM emulators for development hardware use debug libraries naturally so it's irrelevant.

Yeah you can decode some slow memory using a ton of wait-states. If you could disable the CDROM controller that would be something since you could then functionally emulate it, but I don't think that's an option.

Hooking the code on each and every game a la AR cheats? That's all I can think of. It'd reduce game performance, require lots and lots of manual work and still be prone to various problems.

 

Yea but it would require changing Sonys IC's with custom ones I think. I mean, I was going to look into the PSone and PS and see if I can find any shortcuts that match where the PIO port used to be.

I will have to see how things go I guess...

But originally I was going to replace the CD-ROM drive - but it was a bigger challenge.

 

If it is well made I don't think there's a need for any hooks as the interface will just emulate the register set of the CD controller. After all, it is what emulators already do, and games do not need any hooks on emulators. The problem at that point is the extent to which the hdd interface emulates the cd controller. Obviously for an HDD interface to be real good, it also has to have its own register set at a base address different to the CD controller's one to exploit its advanced capabilities.

I have very little electronics experience on the other hand and I have never programmed any microcontroller, despite that being one of my desires as of lately, but I think I've a little grasp of how things could be due to the fact I have done quite a bit of low-level programming.

I have offered to help the team (with my newer nick nextvolume) in case they need help on the software side. There's no need for staunch arguments or anything like that. If the projects delivers, then it does. If it does not, it does not. Not like anybody was hurt.

 

Well said. Updates will be posted here SLOWLY for you guys, then if it is made a success - it will be launched and sold to the world as the PS lasers are slowly dying. Above that, not using the laser deck to play games will make your console last much longer.

:dance:< WOO! look at this emoticon go!

 

Um of course you need hooks, how else are you going to redirect data from the CD registers to your your emulation functions? Your logic is completely irrational, do you know how an emulator works?? Games don't need hooks on emulators because emulators emulate the CD controller out of system, the same as every other component and memory decoding itself, not with hardware constrained MIPS code :banghead:

Again, software emulating the CD controller in real-time would be ridiculous. Even if you mapped a FPGA to the address space and snooped writes, you'll still have to hook reads at another address since you can't have bus conflicts and that alone I suspect will keep it from being "real good".

I think I'm done here, it's clear at least some of you guys have more than a long way to go and the first step is to stop deluding yourselves and defending that delusion. Sorry for the harshness, but that's what I see; read up and take some EECS classes if you're old enough.

 

I know perfectly how emulators work. At this point it's you that do not know what you're talking about. By your logic, the software does a write to that address and then... "emulation functions" are executed by the PSX CPU that handle those writes??? Absolutely absurd. No interrupts are generated when a write to that region is done, and due to that, it is impossible to do that, because the PSX CPU has no MMU to speak of. Even if this was possible, is that worth the case for an hardware interface like this? No. That technique is used by emulation software like executing MS-DOS programs on Windows which do direct memory address writes on VGA memory, for example.
Ideally the MIPS cpu inside the PSX writes to that region, the MCU/FPGA gets that, and then does its work by interpreting the writes. Nothing changes for the PSX CPU and all code is unchanged! This is done by the PCI/ISA/whataver add-on cards in your computer as well.

As I said before my electronics knowledge is pretty limited, but on the software side what you said doesn't look feasible.

 

Ive put my raincoat on for the forthcoming pissing contest but from a basic hardware point of view:

A game that hits the CD registers directly will not run on a CD replacement setup unless you do one of two things.

1. Hook up your hardware to be accessed at the same IO adress(s)as the cd mech, at the same time disabling the original registers.

2. Patch your game code to access the cd mech registers from a different range (your replacement hardware)

My money would be on 2.

 

the Gamecube dvd drive was emulated by an fpga, it was very un-ridiculous
that is all
calpis you are wayyyy to assertive for someone that actually hasn't tested/tried this for themselves, cold hard evidence when the time is right please or in future just end your posts with "imo" so we know to ignore it.
cheers

 

Holy hell, it's not my logic, it's my understanding of your logic in your first post. Now you're accusing me of it. I'm sorry we're having a failure to communicate, but honestly that's not my problem, my reading comprehension is more than adequate here. And I quote: "Games don't need hooks on emulators because emulators emulate the CD controller out of system, the same as every other component and memory decoding itself, not with hardware constrained MIPS code "

You are putting words in my mouth. The analogy isn't correct though.

Yes, exactly what I wrote in the last post How do you propose to handle *READS*? The CD controller and FPGA can't contend for the bus at the same time.

Pissing contest? Pshh you're reinforcing my case. In this system the only way to disable the original registers is to remove the chip (and possibly rest of the CD system which may freak out).

The Gamecube DVD drive emulation project interfaced directly to the DVD controller, the same way I presented in my first post. You were the one claiming that it wasn't necessary.

I'm assertive because everyone argues with me. I don't need to try this project for myself, my arguments in this thread are based on common principles, I only assert fact and not my opinion. My only opinion expressed here are the judgments of those in this thread.

If there's any confusion I understand how to attack this project from all angles (reiterating AGAIN):

Software methods:
-AR style patching of game code, CD registers are hooked to functions allocated on the heap
-BIOS rewrite (requires games to exclusively use system calls, and most do)

Both of these methods will use the CPU to emulate the hardware functions of the CD controller, the only hardware will be the PC server interface or hard drive/SD registers. This is not a ridiculous notion, but it will have an impact on game performance. This is how the Dreamcast SD project works.

Hardware methods:
-CDROM emulation (FPGA connected to the CD controller past the RF stage), this obviously will have full compatibility and no impact on game performance. It also requires the most skill as the protocol has to be reverse engineered from scratch.

-CD controller emulation (FPGA in parallel with the original controller), most straight forward approach since everything is already documented, but the FPGA can only snoop writes, when it comes to reads you are in trouble as either you must contend with the original CD controller (overpower the bus), or you must use the first software method to redirect reads to another address the FPGA can freely decode to (with performance loss).

-CD controller emulation (NOT in parallel), allows full compatibility but requires significant reworking of the PS...

As I said if you are going with a hardware approach a FPGA is a NECESSITY, a MCU really has no place in the project except as a PC/SD interface if you must reuse other people's implementations.

 

..erm , yeah. That was reason for my reply. I was trying to sum up in less than a thousand words why i thought your point was valid. :thumbsup:

 

This pretty much sums it up. EECS courses will whip you guys into shape.

 

I was going to buy an Altera DE2 FPGA board and wire the CD-ROM and PIO port and see the data.

Thats how / what they do right?

 

i taught myself AVR assembly with ebooks alone.
walking through C for avr's with ebooks atm,
know any good literature for fpga's?

i think calpis is confused by my definition of software/hardware?
if this is what his posts after the last two pages have been about im going to shoot myself.
using an fpga would be software emulation IMO, yes it's a piece of hardware, but you program it (imo definition of sorftware) to perfrom functions/procedures/programs.

i am not knowledgeable (spell check says yes?) enough to explain in detail how my proposed method will work yet, this is where the self-taught part comes in, but here is the basic idea:

Ps1, unmodified.
ps1, running a bootloader flashed via pio port by <enter magic device here>
ps1, <enter magic device here> mount sd/ide memory/flash/etc drive
ps1, load game off <enter magic device here> mounted sd drive.

seeing as the pio port has access to the entire local bus, i see no reason to open up my ps1 and crack out the soldering iron on it.
i should be able to interface with everything through the port.

<enter magic device here>

is where the mountain is,

Also, does anyone here know if that czech programmer for runix ever completed the cd driver, i know he managed to do the gpu/memory card but cant find much conclusive stuff about the cd drive.

 

The ADE2 (FPGA) will be wired to the PIO (eventually, CD-ROM maybe) and used as a Action Replay at first so the thing is working like an Action Replay...

Once thats done, it will then be edited (code) to load games via yes. Software emulation (technically hardware).

Then, the FPGA gets 'ported' to a stand alone chipset or 'flash card' type device with a boot loader.


So the FPGA (ADE2) acts like a protyping board and a Action Replay and a Hard Drive (well, an SD Card type device)