PSX Hardware: CD-ROM

[Gamesoul Master]

firehawke said:

If I may be allowed to go into theoretical discussion, there's one possible other thing to add to the equation... my memory is a little shot, as I took a head injury about ten years ago, but I recall reading some interesting comments on disc read speeds causing issues on at least one PS1 game.

I'm going to digress for a moment on this topic, and I think by the end you'll understand where I'm going with this.

Recently a PS2 product called HDLoader was created, allowing one to install PS2 games to almost any IDE HD you can hook up to the network adaptor. One of the discoveries made shortly thereafter is that a certain (not extremely large, but enough to be noticible) percentage of games were highly sensitive to the read speeds and that delay mechanisms needed to be added as a compatibility feature for these games or they'd simply crash at various points and often randomly based on the HD used, the PS2 used, and various other factors.

If my recollection is correct, we may be seeing something similar to this on the PS1 side in terms of timing dependencies. I'm hoping I'm wrong, since it will be VERY difficult to get appropriate timing on a PC-based emulator for a couple of reasons: the PS1 drive doesn't have spindown (which seriously affects games that read infrequently on the PC-- the spinup time on each initial post-spindown read is going to add a noticible two or three seconds), and it's very difficult to accomplish speed limiting on an actual CD drive or Daemon Tools. You'd pretty much have to play with images and specially written handlers for those images to emulate the speed as closely as possible.

It's entirely possible I'm completely off base here, but it WOULD explain a lot of the variances I've seen in how PS1 games handle between originals, images, and DT even when using an image that is known to be 100% correct (and the original disc it is made from).

That wouldn't take into account bogus compatibility reports, though...

firehawke said:

Well, we know the drive is officially 2X, but there's still a lot of room for variance in there.

Going from memory (I doubleswapped before getting my modchip), the boot process starts at 2X, drops to 1X for the first security sector, goes back to 2X to read the boot info, drops back to 1X to read security info (different sector or same? I'm not sure.) before going to 2X for the finalization of the boot process and play.

[Gamesoul Master]

It's true that *most* of the drives are 2X, but the very original PSX (or maybe the first couple... I'm not sure) had a single-speed drive. So wouldn't it stand to reason that setting the drive to 1X would provide the best level of compatibility?

[Firehawke]

Have you got a source for that? I could have sworn they were all 2X drives, but I'll be more than glad to be proven wrong if you have data on that.

I'm going to suggest that 2X is probably the most compatible, considering that later PSX models (assuming you're right about the 1X original units) show no compatibility issues with any discs.

[Gamesoul Master]

I can't find the source anymore (which is more than a mild irritation), so I will just assume (unless I find otherwise) that the source was bad. The good side of my hunt was that I found growing speculation (sometimes stated as fact) that the precise disc-speeds used to read the TOC and other data when first loading the game is very important, and that a lack of precision can lead to problems, most notably sound problems related to timing.

I guess that means you've used the double-swap enough times to memorize it... nice. I can't help but feel, though, that something is off with your sequence.

[Firehawke]

How could I not? It was the only way I could boot Einhander at the time, and that RAPIDLY became my favorite game.

Let me find a link for the good old doubleswap, killer of PSX drives the world over... www.cdrom-guide.com/ubb/Archives/Archive-000019/HTML/20020204-9-027719.html

Method 4, to be exact. I'm a little off, but mostly on target considering I haven't used my actual PSX in about five years (not since PSX emulation got to be as good as the real hardware in most cases.)

[Gamesoul Master]

That page is actually one of the pages I found while trying to find my source. Reading it reminded me of the good 'ol days when I was a swapper myself...

Hey... how do you feel about reading through a ton of gathered official (not much) and trial-and-error discovered (mostly) documentation? I've been trying to read through it myself...

[Firehawke]

Well, if it wasn't already obvious, I'm a bit of a technical monkey-- I enjoy trying to figure out how things work as much as I do playing the games. What do you have? I'm interested.

[Gamesoul Master]

Well, it may very well be useless (or you may have already seen all this), but at this linked page ( www.classicgaming.com/aec/css/html/psx_development.html ), there are many links that lead to some interesting information. Decide for yourself its value to us (as it may be beyond our use).

[Firehawke]

Some very interesting stuff there already-- I wasn't aware that games are supposed to ignore controllers that aren't what they're expecting (making the neGcon, for instance, all but useless except when playing one of the rare titles that support it.)

hitmen.c02.at/files/docs/psx/cdinfo.txt pretty much clears up that the thing is definitely only dual-speed-- although it seems it's actually code-controllable. This could have major implications on CD access timing. I'll keep reading and see what pops up. We already knew subchannel reading was possible (later copy protections on PSX use it frequently), but it appears that it is low-level controllable.

Now, from what I remember reading.. (can't find the link right now) developers complained about how the PS1 didn't give a lot of low level access (everything was SDK-based) and that's why the PS2 allowed for low-level code (which in turn pissed off some developers for being too hard-- some days you just can't win.)

So, it's debatable on how many games actually USE the speed adjustments. If I had access to the source of pSX, I'd put a debug message any time a speed change call was detected-- that'd be the easiest way to actually figure out how important it is.

pSX Author, if you're actually reading this, any insight on if I'm completely off track or what? To be honest, my understanding on the PSX hardware is fairly limited, but I'm definitely interested in learning more about the whole thing.

As I read further into this, I'm getting an idea for an interesting feature. We know the parallel port on the PSX maps to RAM at 0x1f000000 and goes on for an unknown amount of space (this could be an issue, but I suspect it shouldn't be a problem-- the memory map itself shows the hard limits of where you SHOULDN'T be able to overwrite. The total contiguous empty space between the beginning of the parallel port RAM location and the internally used locations is about 8 megs, but as far as I've been able to tell AR and the like never use more than 128K)

Anyway, if one had a proper RAM dump of a Gameshark-- as far as I understand, the Gameshark pretty much just has program code that is immediately executed on boot before it can even get into the normal boot process, and in some cases a hardware button (and a parallel cable port) that I'm not sure how it interfaces to the program code-- but I digress, having gotten off topic-- If you had a proper RAM dump of a Gameshark, you could insert it into the proper hole in the memory map and it SHOULD work just like it would on the real hardware. Unless, of course, there's bankswitching.. that would require some additional handling on the emulator side to map RAM to parallel port accordingly.

I'm pretty sure ROM dumps (of a usable kind) exist for all of the Gameshark variants out there; it's important to note that almost ALL of them (exception of Gameshark Pro, I believe) used a single standardized piece of hardware design.. the SOFTWARE.. well... Hah.

The software is amusing in that EVERYONE was ripping one another off on that side. Every time someone'd pick up a new trick, everyone else would reverse engineer it.

Still, I'm not entirely sure it'd be ALL that hard to implement-- at the very least, any of the earliest versions of the Gameshark and clones are PROBABLY non-bankswitched (just a guess...) and likely to be easy to just "cram in there" and see what happens.

------

Edit: I found a copy of Caetla (Hooboy, isn't THAT a nice can of worms?) after digging through the remains of a number of PSX sites-- it's amazing how many of the sites are gone-- and it looks like my assessment of 128K is pretty much on target. Since the total direct space is 8MB, there won't be any bankswitching involved.

I still don't know how the hardware switch affects things, to be honest. There's practically no information on the actual internal workings of an AR-- I'm thinking nobody was particularly interested in documenting specifics since the general rules are already well-known.

There's one other quirk I need to look into. The AR units had eeprom to allow for upgrades and saving of codes. How exactly they handle THAT I can't say, but I can state that it wouldn't be too difficult to trace code in execution and see what it does when you enter a new code.

In the end, it looks like doing AR support is feasible at least. I wouldn't expect perfection out of it (full feature support, saving, etc) but the basics look like they should work.

Haven't found anything new on the CD stuff yet, but I'm still digging through tech documents as best as I can (web.archive.org is your friend!) and hopefully SOMETHING will pop up.