22

Some programs notice if they are run on a real Commodore 64 or an emulator. For example, this demo from 2007 stops on VICE emulator 3.2 with the message "No VIC inside". How is this done?

I found some code to identify a Commodore 128 in Commodore 64 mode, but no code to identify emulation.

In particular, I would be interested in a solution to detect a real Commodore 64, THEC64, and VICE emulator in software.

Improve this question
8
  • Adding a link to a ziped file without any description doesn't seem like a good idea, does it?
    – Raffzahn
    Jan 4, 2021 at 23:36
  • 2
    As a case in point, note that this demo (Krestage3) works flawlessly in VICE 3.4 without any "No VIC inside" message. :)
    – Retrograde
    Jan 4, 2021 at 23:57
  • 2
    Sometimes, the difference is not actually detected, it is just a difference between emulation and real hardware, that makes a message on screen being visible or hidden. It simply means that the emulator does not implement a specific corner case how the real hardware works.
    – Justme
    Jan 5, 2021 at 7:13
  • According to the definition of program execution (which admits any execution engine that satisfies and implements the specification), you are trying to add a restriction to the engine's specification if you attempt to detect the actual execution engine. I.e. you are trying to work around the basic principle of software development (to depend only on specifications rather than implementations).
    – Aleksey F.
    Jan 15, 2021 at 23:23
  • @Aleksey I'm not trying to add a restriction but I want to add features to my prgs that make sense with the respective systems. For example, if the system is a THEC64mini, there is no keyboard, so functions need to be mapped onto Joystick functions or Return key. But that is a different topic.
    – Peter B.
    Jan 16, 2021 at 22:38

5 Answers 5

Reset to default
29

In general, no there is no reliable way to detect an emulator (if it's any good). Especially if it's actively developed.

The trick that worked yesterday probably don't tomorrow as emulation improves. Also, exploiting margins like ghost signals on floating bus lines may just lead to false positives as well, as there were quite a few differences between C64 boards in its life time. (This was a problem with some copy protections based on this scheme, for instance. Also, it could still be emulated if the developer's set their mind to it.)

There's a discussion of the topic over at lemon64 here. As commented, specifically for VICE it may be possible to detect if True Drive emulation is turned off. But the user can still just turn it on.

Earlier versions of VICE supported an emulator ID that was optionally mapped into the memory space to detect the presence but it was since removed.

Improve this answer
4
  • 1
    Any emulator detection that focuses on the drive will also very probably give a false positive on third party drives, or things like the SD2IEC, even though it's running on a real C-64.
    – Michael Graf
    Jan 4, 2021 at 22:15
  • Thanks, for the answer. I saw the topic on Lemon64 as well, but unfortunately, they did not come up with practical examples of usable code. While the argument "a good emulator cannot be detected" makes sense, I'm still impressed by some demos (where I forgot the names) doing such a detection. I had True Drive emulation enabled, so it must have been something else. So I think it might be still interesting learning about "yesterdays" (to today's) methods.
    – Peter B.
    Jan 4, 2021 at 22:17
  • 2
    If you have examples of currently working methods detecting VICE, there's a disassembly challenge ready for taking. :) With a little luck, you can even do it inside the VICE monitor. ;) Time will tell if the next VICE release his picked up the challenge.
    – Retrograde
    Jan 4, 2021 at 22:21
  • 1
    @Retrograde makes two of us ... that would be areal nifty task:)
    – Raffzahn
    Jan 4, 2021 at 22:39
12

Wouldn't it defy the purpose of an emulator, designed to mimic a machine as perfect as possible, if it can be detected? In general, every detectable difference must be considered a bug one would expect to be removed ASAP.

Some programs notice if they are run on a real C64 or an emulator.

It would be great if you could add some examples. Especially with notes if these programs do the detection reliably or only in certain configuration/situations.

How is this done?

Assuming that any of the named emulators is good enough to run most C64 software, I would look out for discrepancies in handling of external devices, most likely floppy disk drives. For example, by measuring the response time for various commands send to a drive. Measuring can be done by taking a CIA timer, put in PHI2 counting mode.

Three basic results can be measured:

  • Direct response to a transfer

    (i.e. reaction/round trip times)

  • Response to CPU only commands

    (i.e. answer given by the external device CPU without accessing the drive)

  • Response to positioning and read commands

    (i.e. mechanical response like moving 20 tracks)

Each of this will give indicators about having an unmodified or a modified C64. Modification in this sense can have many meanings

  • Faster drive electronics
  • Faster drives or solid state drives
  • Improved protocol (fastloaders/DOS)
  • Emulator usage

Differences are only gradual, not absolute. A real fast response may come from an emulation that does not care for being as slow in floppy operations as the original (or simply accept the faster operation of the host PC). It may respond almost instant.

But similar results may as well come from a genuine C64 equipped with solid state drives, SD2IEC for example. With increased processing power available such devices may at one point as well deliver instant response with the real C64.

So for sure timing can only reveal relative differences to a genuine setup, not how they are achieved (*1). For this method I would give the response time within a single transmission the highest chance to find something.

I found some code to identify a C128 in C64 mode, but no code to identify emulation.

Detection of a C128 vs. a C64 is a different issue, as these machines do differ in certain details.

*1 - Not to mention that these measurements are only valid within the reference system given, so an emulation delivering the right relative timing may still run faster or slower.

Improve this answer
14
  • 4
    "In general every detectable difference must be considered a bug one would expect to be removed ASAP" On x86, it is quite normal for virtualisation (VirtualBox,etc) and emulation platforms (QEMU,Bochs,DOSBox,etc) to expose their identity to the software they are emulating (through DMI data, strings in the BIOS, PCI configuration data, etc). Now, it is generally possible to configure those platforms to hide themselves, but their default configuration is to be open about who they are. I wouldn't call that a bug. But maybe the expectations for C64 emulators are different from those for x86.
    – Simon Kissane
    Jan 5, 2021 at 10:41
  • 7
    @SimonKissane Well, exactly, expectations on a C64 are different. The C64 is, unlike the PC, a single definition that didn't change over time. Any difference from that expectation can screw execution of a program. The PC is a way more loose definition. There were not only many different extensions, but manufacturers as well. And the definition changed over time. So for all emulation purpose the C64 must be seen as a game console.
    – Raffzahn
    Jan 5, 2021 at 12:40
  • 2
    "Not to mention that these measurements are only valid within the reference system given, so an emulation delivering the right relative timing may still run faster or slower." - for example the drive emulator could give off instant response, but also calculate how long it should take and advance the system clock by that much.
    – John Dvorak
    Jan 5, 2021 at 13:51
  • 1
    @Tommy Aren't these even more about emulation of the drive? Detecting sync bytes only works if the emulator provides a 1541 emulation low enough to even come to that point. So we're again way past the C64 and into characteristics of peripherals - things that already may go different on real machines, so a detection does not always indicate an emulator.
    – Raffzahn
    Jan 5, 2021 at 14:52
  • 1
    @SimonKissane these virtualization platforms, however, are meant as a productivity/performance/consolidation tool, often used to run state of the art software, not to run software that is completely foreign to the host platform. Optimized to allow separation of stuff with AS LITTLE emulation as possible.
    – rackandboneman
    Jan 6, 2021 at 18:46
2

One thing that can give emulators away (not reliably, but it might be good enough in practice) is how predictable the results are when you do something that is supposed to yield an undefined result. One thing that comes to mind is what you read from a bus when there is actually nothing writing to it, or using hardware in a way that is known to cause glitches some times but not all the time.

Improve this answer
5
  • You got an example of "what you read from a bus when there is actually nothing writing to it,", like what could that be on a C64. You mean like bits 4-7 of color RAM or something like that?
    – Героям слава
    Jan 6, 2021 at 12:14
  • 2
    On 8/16 bit machines with a multiplexed A/D bus, you often actually could read back your address on the data bus (capacitive effect I guess) when reading from an address where physically no memory or I/O device is mapped. Not sure if you can with the C64.
    – rackandboneman
    Jan 6, 2021 at 13:06
  • But is it really reliably unreliable?
    – Peter Mortensen
    Jan 6, 2021 at 15:49
  • @rackandboneman: On the 6502, any data fetch which doesn't involve a page crossing, isn't an interrupt-vector fetch, and is outside the range $0x0000-0x01FF, will be preceded by on the bus by MSB of the address. This fact can be handy when doing a custom-cartridge design on the Atari 2600 which doesn't connect the top five address wires on the processor die to anything (they aren't even wired to pins on the package).
    – supercat
    Jan 6, 2021 at 18:39
  • Disconnected wires like that should either behave like an accidental register, or read back noise. I would not expect an emulator to ... well, emulate whatever the behaviour is in practice, unless explicitly implemented.
    – rackandboneman
    Jan 7, 2021 at 15:14
2

The only way to detect an emulator that doesn't use emulator ID (all modern ones) is to exploit a difference between that emulator and real hardware. This only works until the emulator gets fixed.

Writing such code is useful only insofar as it helps emulators improve, by providing a test case.

The floating line test has false positives when used to detect emulators. Relying on behavior that is undefined on real hardware is NOT a valid trick. Instead, do tests that are consistent on real hardware, but different on emulators, but realize that the emulator may get fixed. If you can't find one, then you don't need to know it's an emulator.

Demos usually do this because they really push the hardware, and often run into crazy edge cases that the emulator authors haven't implemented yet, and that no one eve expected to even work on a real c64.

Improve this answer
0

Most — if not all — CSDB demos expect a PAL C64. VICE or TheC64 (which should be referred to as “Hall of Shame VICE”) typically start up as NTSC.

This demo seems to run adequately in VICE 3.5 for me when invoked with:

x64sc --model pal KRESTAGE3.D64
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .