Detecting if software is running on real hardware

[TMR]

After speaking with Avery/Phaeron, I can see that it's not a good thing to be checking if running in an emulator. I appreciate that an emulator writer wants to make a real Atari and an emulator as indifferent as possible. We can always give the power to the user though.

Relying on an emulator check only works up until the point that said check is defeated by the emulator devs; we've seen a few demos on the C64 over the years which would refuse to run or at least flag up if they were under emulation when released which happily work now.

[gozar]

Each of those flash cartridges has a way to open up the memory for write, so all someone will need to do is just that so a program is running from the original EPROM or has been ripped onto a flash cartridge. It may destroy the memory on the flash cartridge.

 

Whoa, I don't believe that peteym5 was ever saying that he would actually do this, he was just putting forward that information.

 

I don't know his motivation behind starting this thread, but disabling a game from running in an emulator doesn't make sense. In fact, since his software is only available on cartridges, emulator users can't be a lost sale because they would have never bought the cartridge in the first place.

 

Anyway, ROI for the Atari 8-bit market is smaller than working minimum wage, no one is going to get rich with the 8-bit market. Peteym5, concentrate on writing the best software, and stop worrying about your stuff being copied.

[peteym5]

Alright, I did not intend to scare anybody about by destroying their flash cartridges or turn this into another anti-piracy thread. If someone enabled the write on those MAX, SIC!, or Mega cartridges and wrote to a random location and a random byte, it would then be altered. Then whatever was there would be changed and not function the same way if not restored. It could serve as anti-piracy protection, but could also be used to save game information like high scores or the point of where you at in like an adventure game. All the bank switching schemes written to the $D5xx affect how the Cartridge ROM is mapped into main memory. Simply counting the number of bank changes could also be a way of checking.

 

One other thing I had problem emulating with Super-IRG, unless frame blending is turned on, there is no real way to have the emulator sync with the frequency of my PC monitor. Other running Windows programs and processes are being time shared with the emulator. This has not been an issue for prior games released on real hardware that used Super-IRG. Everyone is stating the game looks great on their real Atari and not reported any major issues. I am however reducing future use of Super-IRG or including options to disable it if it is an issue.

Edited January 7, 2016 by peteym5

[Rybags]

Flash memory doesn't work like that - for changing contents it's always at a record or block level. That applies if it's a SD card, an SSD or flash memory being used on a computer like Rom.

Also, people weren't worried so much for their flashcarts being altered as they were for inadvertant corruption to things like Ultimate 1 Meg or SIDE carts since the flash command process is similar.

[peteym5]

Testing to see if blocks can be written to the cartridge memory area probably be a check I will not be using to check if the game had been ripped. Probably be better to use that to save information for those longer playing games.

 

I am still not entirely sure why the AtariMax version Tempest Xtreem had issues, most likely it is not a programming fault. I recently went through all the source code and made sure values like $55 and $AA did not get written to the $D5xx area. These value are what causes the memory to be written. I made sure something like $07 was the constant value written to $D500 to $D50F. Other than that, it could be dirty pin or cartridge not seated properly. Just to let you know, Video61 had his equipment repaired and sent back to him so a new batch of Tempest Xtreem may be available for another run. Tempest Elite will soon follow.

[Keatah]

I see the point regarding running in emulation, CRT, old TVs... all look different... (or can look different)... I like the idea like modern games let people configure their ram settings and bank selection due to the many HW mods. now having similar for games and video output, why not... (need to ask my c64 friends how they deal with that, think of iFLI etc).

 

but checking if you are running in emulator because I as coder want do different things... is like "defeat device"... which we learned from VW scandal nowadays ;=).

 

and if I running in emulation and I do different things if so... the user always can mess up with other settings e.g. in Altirra? wrong memory, GTIA mode switches, NTSC vs PAL, Artifacting etc etc etc... I would spend more time on coding than on the "defeat device" routines.

 

It wouldn't be that difficult to make two versions of game X. One for real hardware, one for emulators. Furthermore, good practice says to code for the lowest common denominator to allow it to work on the largest installed base.

 

Most emulators are a moving target, what works today may not work tomorrow, because their quirks and corner cases are fixed over time in the quest to be identical to the original machine.

 

There is nothing wrong in foregoing detection logic and simply using a menu. Some Apple II software asked us if we had one or two drives, or 40/80 columns or a mockingboard synthesizer. Or what was in a certain slot. It was no big deal to manually select what we had. It was simple and it worked.

 

Some of the programs back then asked us each time they started. Others saved our choices as defaults.

 

 

I thought Petey said this was to make sure things ran under Altirra with no hiccups but I return to the thread and Petey's looking to try and flash a cart on the go just in case its his game on a flashcart, not only possibly damaging the cart but has been warned he could brick a real machine as well.

 

[..]

 

You are also worrying the very people you want to buy your product, will it harm my system, that's what happened to the CDRWIN guy, his program went from the No1 seller to no one wanting his products 'just in case' and as said I believe it cost him quite dearly.

 

Petey, you really are entering bad territory, sort it out before you make yourself unsellable please....There's protection and then there's more code protecting the game than game data.

 

Like I said earlier I would be displeased if my emulators blew up, of if my friends' systems got bricked. And I'm not going to take the chance of running such software.

 

Unsellable? I think we arrive there tomorrow. This sort of mindset doesn't know when to stop.

 

 

 

... I long for the days when everyone ran a stock machine on a CRT!

 

[..]

 

After speaking with Avery/Phaeron, I can see that it's not a good thing to be checking if running in an emulator. I appreciate that an emulator writer wants to make a real Atari and an emulator as indifferent as possible. We can always give the power to the user though.

 

Best thing to do is code for common hardware. Setups you know everyone has by default. When that's done, and only when that's done, you start making enhanced versions. They can be multiple versions on the same cart selectable by menu, or different executables on disk.

 

 

Much like selecting graphics cards in the early days of the PC. I once had a program that gave me close to 70 choices to pick from. 70 to cover all the bases and avoid the reliability issues with autodetect not getting it right. A little bit of configuring never hurt anyone. And remember the DOS games with himem/ems/xms memory requirements and irqs and dmas for the soundcard? ..And the games sold millions of copies!

 

 

I just don't get it, petey is designing for real hardware only so why is he worried about possible glitching caused by techniques on Altirra, as seen with Space Harrier you get flicker on real hardware but everyone knows why and thanks to the frame blending on Altirra its removed so the actual issue is the reverse of what petey is saying, technically he should be trying to reduce flicker on real hardware which we know will be impossible. But then bang in the middle we get the real reason, protection against Altirra and flashcarts yet are his previous games publicly circulated, are they even dumped?

 

This sort of personality typically remains this way and doesn't let up. Stranger things have happened and we shall see what we see!

[Irgendwer]

This is ridiculous.

 

Potential customers may get the impression, that somebody tries to implement an anti-piracy scheme, while not knowing what the impacts are.

 

When producing a cartridge, why not putting some highly complicated additional logic to it, working like a dongle or calculation speeder - making it even harder to reproduce it.

Lack of knowledge? No problem, somebody may help you to lock himself out.

Hardware will be more expensive? No problem, cart is more expensive than digital download anyway.

 

Here an idea:

Just drop an additional Raspberry PI Zero in the cart case and advise your customers to connect their display device to the video out of the cart.

I'm sure then you are some time ahead and "safe" until emulator programmers pick up on that feature.

You could even run a modified Atari emulator on the PI making things a little bit harder and add new unique features and screen modes...

 

Of course you should glue the whole thing, so that nobody knows where the 24 million flickering colours come from...

 

 

 

 

[flashjazzcat]

I am still not entirely sure why the AtariMax version Tempest Xtreem had issues, most likely it is not a programming fault. I recently went through all the source code and made sure values like $55 and $AA did not get written to the $D5xx area. These value are what causes the memory to be written. I made sure something like $07 was the constant value written to $D500 to $D50F.

Please take a moment to read up on JEDEC flash programming protocols. Writing $55 and $AA to CCTL does not put the flash ROM into autoselect mode. The unlock sequences are written to locations in the flash ROM itself, although it might be unwise to go into further detail. In any case, I'd steer clear of any kind of JEDEC programming until you have some idea what you're talking about.

[Synthpopalooza]

 

One other thing I had problem emulating with Super-IRG, unless frame blending is turned on, there is no real way to have the emulator sync with the frequency of my PC monitor. Other running Windows programs and processes are being time shared with the emulator. This has not been an issue for prior games released on real hardware that used Super-IRG. Everyone is stating the game looks great on their real Atari and not reported any major issues. I am however reducing future use of Super-IRG or including options to disable it if it is an issue.

 

 

That is probably the best approach: Allowing the user to select the option of Super IRG (or other ICE modes) or not. Having developed many demos and pictures using these ICE modes, I can tell you that they look good on NTSC systems, and on modern LCD TV's where the frame-blending happens automatically, but on PAL (especially on CRT's) the slower frame rate can be murder, especially when you rely on full-frame changes. I have often wondered if there is a hardware modification that can be made to the Atari video board itself, to allow for automatic frame-blending, and make these sorts of display modes more feasible for PAL users?

 

With Super IRG there are techniques which will reduce the flicker and make it more bearable (i.e. checkerboard dithering, and keeping the luminance within one step of each other) but there is no magic bullet which will eliminate it completely on real hardware, without either hardware modifications, or using modern LCD TV's or monitors with scan-doublers (which not everyone is going to have access to).

 

Sheddy's Space Harrier did a reasonable job with this technique, I thought ...

Edited January 7, 2016 by Synthpopalooza

[peteym5]

 

 

That is probably the best approach: Allowing the user to select the option of Super IRG (or other ICE modes) or not. Having developed many demos and pictures using these ICE modes, I can tell you that they look good on NTSC systems, and on modern LCD TV's where the frame-blending happens automatically, but on PAL (especially on CRT's) the slower frame rate can be murder, especially when you rely on full-frame changes. I have often wondered if there is a hardware modification that can be made to the Atari video board itself, to allow for automatic frame-blending, and make these sorts of display modes more feasible for PAL users?

 

With Super IRG there are techniques which will reduce the flicker and make it more bearable (i.e. checkerboard dithering, and keeping the luminance within one step of each other) but there is no magic bullet which will eliminate it completely on real hardware, without either hardware modifications, or using modern LCD TV's or monitors with scan-doublers (which not everyone is going to have access to).

 

Sheddy's Space Harrier did a reasonable job with this technique, I thought ...

 

One issue with disabling SuperIRG, is you only see like the first font that will be checkboard dithered. Unless you have enough space for a 3rd alternate font. I ran into the issue of not having enough extra space with Secretum Labyrinth. What I did was just blank out all the background (floor) characters, walls and foreground objects still used flickering characters.

Edited January 7, 2016 by peteym5

[TMR]

It wouldn't be that difficult to make two versions of game X. One for real hardware, one for emulators. Furthermore, good practice says to code for the lowest common denominator to allow it to work on the largest installed base.

Personally, i've always felt it best to code for real hardware and, if you do produce something that doesn't work correctly under emulation, leave it that way; it means that the folks behind the emulators have a test case to work with in order to improve their code and in the long run everybody benefits. That's why the C64 emulators are constantly improving, every now and then a demo coder comes along with a new, creative abuse for the video hardware and one or more of the emulators needs an update.

[Synthpopalooza]

 

One issue with disabling SuperIRG, is you only see like the first font that will be checkboard dithered. Unless you have enough space for a 3rd alternate font. I ran into the issue of not having enough extra space with Secretum Labyrinth. What I did was just blank out all the background (floor) characters, walls and foreground objects still used flickering characters.

 

 

You would only need 1K for the additional font, if it's not going to be interleaved. Another possible solution, would be to use one frame of the checkerboard dithered Super IRG font, but shift the scanline up and down every VBLANK. The colors will mix with the ones below then in that case. Maybe have this as an option ... it will still look a little blurry but might be a better alternative than 2-frame flicker.

[Shawn Jefferson]

I see little point verifying that a flashcart is real and not emulated.

I think Pete's intention/suggestion was to have code that actually erases the flashcart, so that if a program is "pirated" from the EPROM version to a flashcart, the program would erase the flashcart.

 

His quote:

Each of those flash cartridges has a way to open up the memory for write, so all someone will need to do is just that so a program is running from the original EPROM or has been ripped onto a flash cartridge. It may destroy the memory on the flash cartridge.

Perhaps he had already implemented such code in Tempest Extreme or one of his other programs? I wouldn't be surprised after some of his comments here on the board, but I don't own any of his software to check myself.

[Shawn Jefferson]

Testing to see if blocks can be written to the cartridge memory area probably be a check I will not be using to check if the game had been ripped. Probably be better to use that to save information for those longer playing games.

Good to hear, I don't think it's worth the effort to build copy protection. Using the flashcart for saving is great, I've done several conversions with saving, and the latest project I'm working on saves to flash.

 

I am still not entirely sure why the AtariMax version Tempest Xtreem had issues, most likely it is not a programming fault. I recently went through all the source code and made sure values like $55 and $AA did not get written to the $D5xx area. These value are what causes the memory to be written. I made sure something like $07 was the constant value written to $D500 to $D50F.

It's a pretty specific set of writes you need to do, I'd be surprised if you hit it randomly. From the source of Moria for 8Mb Atarimax (borrowed from source that Steve sent me ages ago:)

 

cmd_unlock:     lda #$AA 
		jsr wr5555 
		lda #$55
		jmp wr2AAA

wr5555: 	sta $d542 
		sta $b555
		rts 
wr2AAA: 	sta $d541 
		sta $aaaa 
		rts

and there's an additional store you need, to erase or program (at least that's my understanding of the Atarimax flashcart.)

[peteym5]

I think Pete's intention/suggestion was to have code that actually erases the flashcart, so that if a program is "pirated" from the EPROM version to a flashcart, the program would erase the flashcart.

 

Perhaps he had already implemented such code in Tempest Extreme or one of his other programs? I wouldn't be surprised after some of his comments here on the board, but I don't own any of his software to check myself.

This Game will self-destruct in 5 seconds.... No game for you....

 

The issue with doing anything like destroying your own program if it had been pirated to a larger flash cartridge, you can alter other banks on those cartridges that your program is not using, could belong to another program, so anyone will need to be careful.

 

The investigation of what happened to a few Tempest Xtreme AtariMax cartridge is ongoing, the other technique I mentioned had been implemented with a recent batch of AtariMax cartridges with Tempest Xtreme and Tempest Elite. We will be trying to burn the games onto XEGS cartridges before anything else.

[Kyle22]

Pete, why don't you spend your time optimizing code for efficiency instead of bloating and obfuscating it in some paranoid psychotic episode?

[Heaven/TQA]

To be honest... His time his code...his life...

[sack-c0s]

everything gets cracked, life's too short for this. Most of the time those crackers aren't even your customers because they wouldn't have paid for the game anyway.

 

Best copy protection I can think of is to say clearly 'I need to support this, and playing fair by buying the game does that. If you screw me over then there will be no more'.

I reckon people will just get it.

[xxl]

We release games on the cartridge and at the same time electronic versions for free... and we sold all the copies on cart. nowdays it's about an hour to crack any game on atari...

[peteym5]

The first line of my last post was a joke. I currently have two games completed that we are beta testing along preparing labels, manuals, box art, etc for release. One of them is Tempest Elite that had been floating around for over 2 years. Some other games like Megaoids and Laser Blast probably won't be ready for beta testing until later this year. I had been brainstorming on how to enhance those simpler games and have them show off what the Atari 8-bit can do. I already have Megaoids with a starfield background and multiplexing player/missile sprites for the extra stuff that floats around the screen. Laser Blast, I am working on having it with extra enemies on the screen to battle with. That is all I am prepared to state for now, for what will be in the final game we all have to wait and see.