How's the compatibility of the h2000 with most retail games? unlike the tool in theory from what I can tell it should support almost everything out there... I was FINALLY able to get it to cdexec wipeout1 cd, but I'm getting a lot of fmv stutter and very slow read speeds- other games appear to read the header, etc, but then give up like the disc is unreadable- I decided to try wo1 after reading some docs on the emu that suggested it (for some reason) is the pot adjustment applicible on a dev drive, or should i use more traditional cleaning means on the lens to remove airborne films etc built up on the lens? any suggestions? YAY for working boards at least! thanks everyone up to this point!
ok never mind that... after fooling around with it i managed to get it going better.. it seems that the read head gearing had frozen up pretty bad.. manually working the gearing to soften the grease seems to have helped a lot- still getting a few hiccups but it looks like it's getting better with continued playback of games with lots of seeking
I never had issues running retail games, as long as the usual reset/patch/exec cycle is used. At one point I even wrote a starter application to read system.cnf and execute the game, as I was too lazy to get the game code and change+recompile cdexec for each disk . Drop me a PM if you are interested in the program. On a side note: make sure not to plug/unplug anything into the cards while they are powered on. I fried a PIO2 board this way when testing a self-made controller adapter (D-Sub 25 to retail port); prevented the PC from powering on until the fuse was replaced OH:.
interesting- I am interested to see what you mean by a starter app- currently I made the following (at least this is what i remember- i'll check it when i get home tonight if anyone cares): playstation.bat: echo off resetps 1 run /w5 c:\ps\bin\snpatch run /w5 c:\ps\bin\setcd cls echo Please insert game disc into DTL-H2010 now. pause run /w5 c:\ps\bin\cdexec I inserted the pause because I've had a few discs that will hang the resetps 1 if they're still in the drive when resetps is executed. Also, my boards DO NOT autoboot games on resetps 0 even though the disc spins up, slows down for header or whatever reading, then speeds up again. I assume, by the documentation in the H2000 pdf that "many H2000 and H2500 boards can run games..." etc means that my board roms are too old to boot natively. I've tested a pile of games with no issues, and as I say, the grease had frozen up pretty bad, so the read head wasn't traversing very well. I ran it overnight on wipeout 3se letting it do heavy seeks back and forth and although it had frozen at some point, this morning when I left for work, it seemed quite free of fmv hiccups. Another thought regarding the H2000- I have a sneaking suspicion that the empty jumper holes behind the d15 multiav port are directly connected - I'm thinking of making a simple pci filler board with a proper multiav port included - do any of the other cards have these pin holes populated, and is it for this purpose? another thing- what the heck are AV-22K and YS-75 on that port?
As far as I know, cdexec simply invokes LoadExec for PSX.EXE and a fixed stack pointer (which are the default values if system.cnf is not used). However, if the game disk contains a system.cnf, it might specify another boot executable, stack pointer, or number of event or task blocks, so cdexec won't be able to start it. To circumvent this problem, my program reads system.cnf, calls SetConf with appropriate parameters (evcb, tcb, stack) before starting the main executable via LoadExec. Seems fine to me, although I never got a hang at resetps with a disk inserted. There is a FAQ entry somewhere stating that "resetps 0" is completely useless on the H2000. The reason is that the kernel from its ROM image is too different from the retail kernel (missing fonts, missing system calls and so on), so basically no game would be able to execute. That's why "resetps 1" is used: it puts the system into debug mode, so the run command can be issued to patch the kernel to retail (snpatch.cpe or one its cousins). Afterwards, the games shouldn't notice any different from a retail machine. Did you clean the drive mechanism and applied some new grease? These drives are extremely old and usually haven't been used for quite some years, so it is no wonder if the old grease resinifies. I had the same problem with one of my CDW-900E units, which wouldn't close its drive tray until one forced it in manually. Sorry, I don't know. I always use original cables to connect to these cards; or 1-to-1 adapters, as the PC case they are currently installed in doesn't have enough space on the outside of the PCI slots for using the original cables :banghead:.
I'll see if i can find the game that did that again- it was strange- i think it was either persona2 or slap happy rhythm busters... I haven't gone to that extent yet- I commonly deal with old macs from the late 80's and early 90's and never ran across one with this problem- I might do a full disassembly down the road. On the other hand, my new CDU-948 worked right out of the box for burning ps/ps2 and reading discs, loading the caddy... Fair enough- Ended up finding a cheapy ITOX (didn't want to spend a lot for a supermicro) p4 board with 3x ISA in addition to a whole complement of PCI and AGP slots, so my case is has to be freaking huge... I wanted at least P4 support so I could consolidate my 3d modeling, ps2, and ps1 stuff together.. even if i end up having to run multiple os to pull it off... (was hoping not though)
All I know is that it works for a PSX EXE stored on a CD. Cdexec does something like this: _96_remove() _96_init() LoadExec("cdrom:...", ...) If you insert some code between _96_init and LoadExec to load and parse SYSTEM.CNF, you can easily any game disk, even if it does not use the default main file name. LoadExec might also work for other devices (maybe even "host"), but I have never tried it. However, I'd expect you had to initialize the other device first, similar to how _96_init initializes the ISO 9660 file system ("cdrom") device.
well.. i find it interesting that yes, the sony supplied code for cdexec is indeed that, but the actual dos utility must scan the config for the exe and flags as it boots any disc... easy enough to replicate however. I've also noticed that once _96_init's been passed once without a full power down, it doesn't need to be sent again... got me in trouble when i was working on coding up a quick little test app in cw. sad that no one else uses cw- I'm having a few problems I can't quite figure out - oh well
SilverBull --> yes, it's works from CD. But I meant directly from hdd, like cpe files. And on sony docs we can read that : "Information about PS-X EXE format details and the execution method are contained in the following document. Related manual: DTL-D21 40 Library Reference Version 2.0 Vol.1"
