8 ms·
Detecting a PS2 Emulator: When 1*X does not equal X
- deleted 2y ago[deleted]
- SomeoneFromCA 2y ago[flagged]
- noman-land 2y agoWhy would someone want to detect a PS2 emulator?
- MereInterest 2y agoA PS2 developer may want to do so as a type of copy protection. Somebody today, when implementing a PS2 emulator would want to know about these techniques in order to archive and document these games.
- jsheard 2y agoFor current systems, sure, a developer might want to make it difficult to run their game in an emulator to deter piracy. There were a handful of Wii games which did that since Dolphin matured while new Wii games were still being released. Nobody is making new commercial PS2 games anymore though, so any anti-emulator trick that wasn't deployed back in the day is never going to matter in practice.
- sroussey 2y agoIf you knew of the bug at the time of development, you could “future-proof” your copy protection, I suppose…
- dehrmann 2y agoIn that era, wasn't emulation so far behind the real hardware that you wouldn't have to worry about emulators until at least 5 years after the console came out?
- vundercind 2y agohttps://en.m.wikipedia.org/wiki/Bleem https://en.m.wikipedia.org/wiki/Bleem!
- lupire 2y agoHN doesn't include! In URLs. Wikipedia hasa redirect to help. I enjoyed reading how the promptly developed proprietary copy-protection circumventing software had copy protection that was promptly circumvented.
- refactor_master 2y ago“Sony had accused Bleem! of engaging in unfair competition by allowing PlayStation BIOSs to be used on a personal computer (…) The Judge had rejected the notion, and issued a protective order to "protect David from Goliath".” “(As) Bleem! had (…) to deal with defense costs of $1 million per patent” The irony.
- FMecha 2y agoGBA emulation started right after the console's release; any checks against emulation around that time were primarily targeting bootleg/flash carts. Some PSP games also have anti-CFW (custom firmware) checks that will also trip emulators that haven't yet coded to deal with that.
- 0xcde4c3db 2y agoFun fact: GBA emulation and homebrew development actually started before the system's release [1]. IIRC, the official devkit was leaked, then someone wrote a summary of the low-level documentation and started circulating that, which (since the CPU had an off-the-shelf ARM core) was enough to start making rudimentary emulators and tech demos. [1] https://web.archive.org/web/20001214040900/http://www.zophar.net:80/gba.html https://web.archive.org/web/20001214040900/http://www.zophar...
- unleaded 2y agoenabling enhancments that don't slow down high level emulators (e.g. more draw distance, i think some mario 64 hacks do this) and working around bugs
- TillE 2y agoInteresting example of the kind of thing it's probably not worth caring about in software emulation. Emulating the bug would be considerably slower. Some day replicating the PS2 on an FPGA will be feasible, and then figuring out how this worked will be a fun project for someone.
- saagarjha 2y agoDepends on whether the bug breaks games or not.
- jonhohle 2y agoFPGA implementations are often implemented based on code or documentation from software emulation projects. An FPGA version of a PS2 has no guarantee of not implementing the same or similar bug.
- crote 2y agoThe point here is that it is actually viable to reimplement such bugs without incurring significant performance penalties. A software emulator has to be able to execute a single PS2 instruction in the same amount of wall time as it'd take on the original hardware. With a regular multiplication that's fairly easy: x86 also has multiplication, so you can do a 1:1 translation and be fairly certain it's within your time budget. With a bugged multiplication you need to do a regular x86 multiplication, and wrap that in a few dozen other instructions to add the buggy behaviour to it. There's a pretty decent chance it's simply too expensive! When you're writing an FPGA emulator you are able to recreate the buggy multiplication directly in hardware. There's no additional wrapping needed, so (beyond figuring out intended behaviour) it's not any more costly than emulating a non-buggy multiplication. It's far easier to do a cycle-accurate emulation because you have direct control over the transistors!
- gamepsys 2y ago> There's a pretty decent chance it's simply too expensive! I doubt the 24 year old, 300Mhz RISC, 32MB Ram, PS2 instruction set is too expensive to do a cycle perfect replication.
- qbane 2y agoThat is why emulating, when targeting 100% accuracy, is a craftsmanship in our industry. Not only do you need to know each and every quirk the original hardware/software has, but you also need to replicate it, however peculiar it is. Consider the potential performance impact if itself is not challenging enough.
- jsheard 2y agoEmulators have to be pragmatic about accuracy, when emulating more modern systems it's generally not feasible to target 100% hardware accuracy and usable performance, so they tend to accept compromises which are technically deviations from the real hardware but usually don't make any observable difference in practice. Anything that uses a JIT recompiler is never going to be perfectly cycle-accurate to the original hardware but it usually doesn't matter unless the game code is deliberately constructed to break emulators. Dolphin had to reckon with that balance when a few commercial Wii games included such anti-emulator code, which abused details of the real Wii CPUs cache behavior. Technically they could have emulated the real CPU cache to make those games work seamlessly, but the performance overhead (likely a 10x slowdown) would make them unplayable, so they hacked around it instead. https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-report-january-2017/ https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-rep...
- deleted 2y ago[deleted]
- bobmcnamara 2y agoI once wrote something that would hard lock cortex-A8 but not the cortex-A9 we shipped on. To my knowledge, nobody tracked down why our app, once exfiltrated from our device, would crash slightly older phones.
- pm215 2y agoWere you exploiting an A8 erratum, or detecting "this is an A8" somehow and then making it barf in a less processor specific way?
- mattbee 2y agoThe simplest trick for detecting old ARM emulation - ISTR was used on some Gameboy Advance copy protection: store a booby-trap instruction at PC+4 (i.e. the very next one). A real ARM has a pipeline that reads PC+8, while decoding PC+4 and while executing at PC. So the newly-stored instruction should have no effect. An emulator (which didn't emulate the hardware pipeline) would execute it. edit: described in more detail here, among other emulation-busting measures from 2004 https://mgba.io//2014/12/28/classic-nes/ https://mgba.io//2014/12/28/classic-nes/
- ithkuil 2y agoSome pipelined CPUs have retained compatibility with self-modifying code and detect when you overwrite an instruction that is on the pipeline and flush it. X86 has that machinery although I'm not sure if they dropped it eventually on the 64-bit variant.
- BeeOnRope 2y agoThe rules and mechanisms for SMC detection are essentially the same in both modes as far as I am aware. Both Intel and AMD implement SMC detection that is a bit stronger than required by the specification as well.
- ekidd 2y agoThe Texas Instrument TI320C40 digital signal processor had even weirder pipeline issues: - Branch delay slots (https://en.wikipedia.org/wiki/Delay_slot https://en.wikipedia.org/wiki/Delay_slot), where one or more instruction(s) after a branch would be executed before the branch actually occurred. - Load delay slots, where values stored into registers weren't guaranteed to appear until some later instruction. I believe the the value in the register was undefined for several cycles? Writing tightly-optimized assembly code for these chips was pretty horrible, sort of like playing an unusually tasteless Zachtronics clone.
- londons_explore 2y agoIt was also kinda awesome because, as long as you were willing to spend days to optimize one page of code, you could get so much performance out of it. Things like deliberately using the fact that multiplies only write the results into a register ~6 cycles later, means you can use that register for a bunch of other stuff in the meantime, and then on the 6th cycle the results would magically appear. Basically, for those 6 cycles, you had no registers in-use for either the source operands or destination of the multiplication. Obviously this is also pipelinable - you can start more multiplies while the first is running, using the same source and destination registers, but meanwhile you've used other instructions to load more data into the inputs and do something else with the outputs.
- notfed 2y agoDon't tell Terrence Howard...
- dudeinjapan 2y agoTerrence Howard was right!
- wsintra2022 2y agoI came for this comment and there you are! Bravo
- froh 2y agowhat's the reference?
- blharr 2y agoTerrence Howard (actor in Ironman, Empire TV show, etc) believes he has discovered "a new math" where 1x1=2. I believe he has gained recent notoriety because he was on the Joe Rogan podcast, where he got a platform to say his beliefs to many people, but he has had these beliefs for many years. As far as I can tell, his reasoning is literally that 2x2=4, so if you divide both sides by 2, you get 1x1=2.
- huygens6363 2y agoThanks, there went my morning. That was quite the rabbit hole. I’m now confused and sad.
- deleted 2y ago[deleted]
- claudex 2y agoAnyone else was lost with the title asking why a mouse or a keyboard should do math ? I spent to much time to find this about Playstation 2, not about Personal System/2 ports used to connect mouse and keyboard.
- stavros 2y agoNo, one is PS2, the other is PS/2.
- NohatCoder 2y agoTo all the downvoters: Just because something is obvious to you doesn't mean that it is obvious to everyone else. Three character abbreviations can make context discovery really difficult as simply plopping the abbreviation into Google will quite often produce mostly unrelated results.
- purple-leafy 2y agoHow do people get into emulation? It seems like an incredibly challenging niche within software. You basically have to understand electronics and deep programming wizardry
- PartiallyTyped 2y agoI tried to get into it many moons ago, and the guidelines were to start from something very simple and well documented, and build your skills from there. I still have the itch but lack the time :(
- OnlyMortal 2y agoIt depends what you mean by emulation. For instance, I ported a 6502 interpreter from UNIX to Classic Macintosh back in the day. This was to play SID music files. So long as it ran fast enough, clock cycle accuracy wasn’t important. It worked by calling C code from the interpreter.
- immibis 2y agoGame Boy emulator tutorials are all over the web.
- purple-leafy 2y agoThis might have to be my next project then cheers
- anthk 2y agoCPU's are emulated on a high level way. If you can shift bits, you can understand a Z80 or a 6502 in no time.
- xcv123 2y agoYou start by reading hardware documentation and you don't need to understand the machine at an electronic level. It's not a simulation of digital circuits. It doesn't need to be that complicated. An 8-bit CPU is a simple state machine with only a few bytes of state (registers). You can read the program one byte at a time and simulate whatever operation the CPU would do after reading that byte. They are very simple operations like adding and subtracting numbers, loading and storing bytes. http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/registers.html http://www.6502.org/users/obelisk/6502/instructions.html http://www.6502.org/users/obelisk/6502/instructions.html Your 6502 CPU emulator would read the next few bytes of the program, interpret the bytes as an instruction, execute the instruction, which involves updating a couple of registers/counters in the CPU, doing some arithmetic or bitwise operations, and possibly loading or storing a byte of data from one location to another. This process is then repeated in an endless loop. It is a simulation of the fetch-decode-execute cycle. https://en.wikipedia.org/wiki/Instruction_cycle https://en.wikipedia.org/wiki/Instruction_cycle