3 ms·
It's been a while since I've looked into it so I hope I won't be too far off the mark: - Regarding high impedance it might be relevant if you want to explain
by simias 8y ago
It's been a while since I've looked into it so I hope I won't be too far off the mark:
- Regarding high impedance it might be relevant if you want to
explain how the controller and memory card interface works, and
why you read full 1s when nothing is connected (high impedance
line with a pull-up resistor). More generally the issue will
crop up every time you have an interface that might be
floating, I think people who have no background in electronic
engineering might assume that unconnected wire == 0 on the
line.
- Regarding metastability it crops up in the timers. The PSX
timers can either run from the CPU clock or from signals
coming from the GPU (pixelclock and horizontal blanking). IIRC
this is used in some lightgun games to be able to synchronize
the signal coming from the gun ("I saw the lightbeam") with the
current position of the pixel in the frame currently being sent
to the TV set.
The problem with that is that the signals coming from the GPU
are not synchronous with the CPU and apparently are not
resynchronized. That creates metastability issues when the
value from these timers are read from the CPU and you may end
up reading bogus values from time to time. The software
workaround is to read the register values in a loop until you
get twice the same value in row. Now, you probably don't need
to emulate that but if you want to be thorough it's probably
worth pointing out.
So in summary you're right, you don't really need to know that
in order to write a proper PSX emulator but if you really want to
get into all the details you'll probably want to brush the
subject. At least these are concepts that anybody is sure to
encounter eventually is they spend time in bare-metal land...
- vardump 8y agoIt's conceivable that metastability issues could be used as a part of copy protection. Well, protection against emulation more like. Of course it's not the smartest choice for that purpose, because there might be chip-to-chip differences. And environmental factors like temperature could affect it as well. But who knows what people wrote after Bleem PS1 emulator was public? So have metastability issues (or other HW bugs) ever been used for copy/emulation protection?
- hcs 8y agoThere are copy protection schemes on magnetic disks that mess with the clock bits on the disk to produce an unstable value: https://retrocomputing.stackexchange.com/a/7853 https://retrocomputing.stackexchange.com/a/7853
- simias 8y agoMost (all?) copy-protection schemes on the PSX had to do with the CD subsystem. I think they were mainly attempting to defeat hardware "modchips" used to play non-original copies of games. Obviously those are trivial to bypass in an emulator. I'm not aware of any copy-protection scheme on the console that would target specifically emulators. I guess Bleem was not big enough a threat to warrant specific protections? Besides I expect that Bleem, in order to run full speed on the underpowered hardware of the time, must have had terrible accuracy and therefore must have employed a wealth of game-specific hacks to get around issues. As such I expect that if they had decided to emulate your game they wouldn't have had too many issues reverse-engineering any trivial metastability-detecting code to implement an ad-hoc hack.
- anyfoo 8y agoAh, thanks. Now that you mention it, high impedance data lines ("open bus") do play a role in other platforms as well. Even more so, on the C64 for example some undocumented instructions cause conflicting drivers to drive the same lines and produce randomish/unstable outcomes. And nice to know that there are indeed metastability issues that crop up very visibly in the PlayStation!