| |
madcrow
Account closed
Registered: Oct 2003
Posts: 39 |
Emulator checks are evil
Seriously. I'm stuck in NTSC-land, so all this cool PAL stuff you Euros code is inaccessible to me on real hardware. When you add emulator checks/blocks, you keep "casual" fans who enjoy seeing C64 demos, but don't care to import a PAL '64 and monitor and associated high-end transformers to turn 110V/60Hz into 220V/50Hz from ever seeing cool stuff. So PLEASE ignore the advice in the emulator bugs document and keep on making no-check demos.
--------------------------------------
please have pity on the n00bish emu kiddie responsible for the post above. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
agreed. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
doh,i expected another piece of smart code detecting all emus!:(
a routine looking for the presence of an emulator does NOT have to go hand in hand with stopping the execution of the program if an emulator is detected. you can use it to display an informative message telling the audience that some effects in the demo maight be displayed incorrectly or fail. you can use it to tell the user to buy a real C64 (Tense Years by Onslaught). you can use it to force the user to press RUN STOP or rather ESC (Aurora by Level 64). harmless possibilities are countless,preventing the program from running is the extreme option.
so if you find a piece of code that works/displays different in emulators and on the real thing,make an emucheck out of it. you will help the devs of the emulators to improve the accuracy of the emulated C64. to tell one example,emufuxxor v2 was the major cue to implement a cycle exact sprite emulation in Hoxs64. |
| |
madcrow
Account closed
Registered: Oct 2003
Posts: 39 |
Well as long as emulator-routines are "nice routines" (used to warn people that they may not be getting a true experience, but allow the demo to run anyway) they're not evil, but merely annoying. Emufuxxor is evil because of its artificial nature: it deliberately breaks programs that would otherwise work fine on an emulator and offers no way for them to run. While it did have a side effect of driving Hox64 to become the most accurate emulator ever, that wasn't its intent: its intent was merely to annoy and discriminate against those lacking real PAL C64 hardware. That is evil.
--------------------------------------
please have pity on the n00bish emu kiddie responsible for the post above. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
Quote:
its intent was merely to annoy and discriminate against those lacking real PAL C64 hardware.
sorry to say so, but no. noone gives a damn about ntsc, demos are usually made for pal. and emufuxxor is there to annoy those using emulators. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
well i cant recall any serious production protected with emufuxxor. i only know 2 really,Jeroen Kimmel Collection by Tropyx and Logosland2 by Draco. the community must have been really pissed off to miss out on these top quality productions when they came out,lol.
Demus interruptus and Krestage3 required that the particular VIC-II features necessary for the effects in these demos to look correctly are emulated. i guess that these demos wouldnt run on an NTSC machine anyway |
| |
fade
Account closed
Registered: Mar 2002
Posts: 290 |
will ntsc for cards & bbs kthxbi :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Emu-detections only work on emulators which still lack emulation quality. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote: Emu-detections only work on emulators which still lack emulation quality.
speaking of the detection routines available now-very true. but if someone with solid coding skills was determined enough to devise a long lasting and effective way of detecting an emulator he would succeed. afew bizzare VIC-II effects i`ve seen arent emulated in any emulator in the world including Hoxs64. Rubi of Vice Team says that even the CPU6510 emulation is prone to failing on some test suites although I havent found any affected software yet so i cant confirm it. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
what, there are still new VIC effects? bring them on. |
| |
madcrow
Account closed
Registered: Oct 2003
Posts: 39 |
Quote: Quote:
its intent was merely to annoy and discriminate against those lacking real PAL C64 hardware.
sorry to say so, but no. noone gives a damn about ntsc, demos are usually made for pal. and emufuxxor is there to annoy those using emulators.
I know most demos only work on PAL. Thus, my comment/assumption that emulators are the only way for people in the NTSC part of the world to watch PAL demos without shelling out huge ammounts of money for hardware. (High-end transformers, shipping of equipment from Europe, etc)
--------------------------------------
please have pity on the n00bish emu kiddie responsible for the post above. |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: what, there are still new VIC effects? bring them on.
Yes, there are some, but they're not really useful to make anything nice. At least, nothing that I could think of anyway :)
I could maybe add a small emulator test to the next demo based on one of those effects :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I could release my EMU-checked based on the analog properties in the serial cable between the disk drive and the c64. It's really simple and would be quite hard to emulate because it would require the emulators to correctly emulate pull up and pull down time when driving the cables.
However it's just a curiosity and wouldn't lead to better emulation imo, just slower emulation so what the fuck...
|
| |
yago
Registered: May 2002
Posts: 333 |
The current emuchecks only check for bugs in the emu.
It would be much nicer, if the emulator tells "voluntary" about his settings, like framerate,sounddelay etc pp
The current emudetection-scheme which doesnt rely on bugs is very bad, because its in one of the io-areas, has way too few infos and is switched off by default on all emus.
If e.g. the hoxs+vice folks could come up with a new standard for that, these evil emulator checks would be much less evil.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote: I know most demos only work on PAL. Thus, my comment/assumption that emulators are the only way for people in the NTSC part of the world to watch PAL demos without shelling out huge ammounts of money for hardware. (High-end transformers, shipping of equipment from Europe, etc)
--------------------------------------
please have pity on the n00bish emu kiddie responsible for the post above.
All you need is a PAL VIC-II and a 17.734475 MHz clock from a PAL C64 (and VERY little soldering skills).
You can also simply try to get a PAL C64 without anything else (no PSU etc).
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:what, there are still new VIC effects? bring them on.
as WVL said nothing you could possibly find useful in demo coding so dont hold your breath.
Quote:I could maybe add a small emulator test to the next demo based on one of those effects :)
please do. every emu detector leads to a better emulation.
Quote:It would be much nicer, if the emulator tells "voluntary" about his settings, like framerate,sounddelay etc pp
If e.g. the hoxs+vice folks could come up with a new standard for that, these evil emulator checks would be much less evil.
wont happen,atleast in Hoxs64. the reason is the C64 doesnt do that and the only aim is to replicate the real thing. |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: Quote:what, there are still new VIC effects? bring them on.
as WVL said nothing you could possibly find useful in demo coding so dont hold your breath.
Quote:I could maybe add a small emulator test to the next demo based on one of those effects :)
please do. every emu detector leads to a better emulation.
Quote:It would be much nicer, if the emulator tells "voluntary" about his settings, like framerate,sounddelay etc pp
If e.g. the hoxs+vice folks could come up with a new standard for that, these evil emulator checks would be much less evil.
wont happen,atleast in Hoxs64. the reason is the C64 doesnt do that and the only aim is to replicate the real thing.
So if i make my demo only work with AR plugged in, David will finally emulate that? ;) In the _REAL_ world, c64's have AR or FC, you know? ;)
Oswald : some missing VIC effects mainly have to do with the registers taking effect not exactly between cycles, but somewhere halfway after some pixels. I bet those will be nasty to emulate. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:{emulator feedback} won't happen, at least in Hoxs64. the reason is the C64 doesnt do that and the only aim is to replicate the real thing. Only if the emulator is EXACTLY emulating the real thing and the developers have nothing else to do... they could start making 'emulated cartridges' that read parameters from within the emulator and return them through actualy registers on any of the emulated ports. ;-)
But only when they're done... 100% emu has priority! |
| |
yago
Registered: May 2002
Posts: 333 |
Quote: Quote:what, there are still new VIC effects? bring them on.
as WVL said nothing you could possibly find useful in demo coding so dont hold your breath.
Quote:I could maybe add a small emulator test to the next demo based on one of those effects :)
please do. every emu detector leads to a better emulation.
Quote:It would be much nicer, if the emulator tells "voluntary" about his settings, like framerate,sounddelay etc pp
If e.g. the hoxs+vice folks could come up with a new standard for that, these evil emulator checks would be much less evil.
wont happen,atleast in Hoxs64. the reason is the C64 doesnt do that and the only aim is to replicate the real thing.
The C64 also dont have sounddelay or stutters when windows like to swap stuff.
If you emulator-folks dont provide friendly, voluntary information, thats just hubris.
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote: So if i make my demo only work with AR plugged in, David will finally emulate that? ;) In the _REAL_ world, c64's have AR or FC, you know? ;)
Oswald : some missing VIC effects mainly have to do with the registers taking effect not exactly between cycles, but somewhere halfway after some pixels. I bet those will be nasty to emulate.
in reality there are many more possibilities than AR or FC. if it was only a matter of AR and FC i think it would have been already emulated in Hoxs64.
about the VIC effects occuring between cycles afaik they are emulated correctly in Hoxs64 to the best of the knowledge of David. for instance Pinball Dreams required a shift of a VIC register delay of 2 pixels (1 quarter of a clock cycle).
Quote:Only if the emulator is EXACTLY emulating the real thing and the developers have nothing else to do...
But only when they're done... 100% emu has priority!
i doubt that any emu will ever reach the absolute accuracy.
edit:
Quote:The C64 also dont have sounddelay or stutters when windows like to swap stuff.
The sound delay in a correctly written emulator is kept to a minimum and hardly observable. if your emu stutters when your windows swaps stuff its not a fault of the emulator. the are multiple solutions to the problem including closing any other interfering apps,assigning high priority to the "emu.exe" process in your task manager or just expanding memory in your PC and disabling the swap file. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:i doubt that any emu will ever reach the absolute accuracy. In theory or practice?
If the quirks aren't detectable by any routine, it's good enough for me, even if in theory there might be a difference with the hardware.
|
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: in reality there are many more possibilities than AR or FC. if it was only a matter of AR and FC i think it would have been already emulated in Hoxs64.
about the VIC effects occuring between cycles afaik they are emulated correctly in Hoxs64 to the best of the knowledge of David. for instance Pinball Dreams required a shift of a VIC register delay of 2 pixels (1 quarter of a clock cycle).
Quote:Only if the emulator is EXACTLY emulating the real thing and the developers have nothing else to do...
But only when they're done... 100% emu has priority!
i doubt that any emu will ever reach the absolute accuracy.
edit:
Quote:The C64 also dont have sounddelay or stutters when windows like to swap stuff.
The sound delay in a correctly written emulator is kept to a minimum and hardly observable. if your emu stutters when your windows swaps stuff its not a fault of the emulator. the are multiple solutions to the problem including closing any other interfering apps,assigning high priority to the "emu.exe" process in your task manager or just expanding memory in your PC and disabling the swap file.
LoL! Didnt know I already forced David to change the emulation :D Is it the writes to $d01c in the display-area? |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:In theory or practice?
If the quirks aren't detectable by any routine, it's good enough for me, even if in theory there might be a difference with the hardware.
a perfect emulator would display EVERY software released for the C64 pixel exact. if it doesnt then the probability is high that it can be detected by a clever ASM routine. such emulator doesnt exist and i doubt it will ever exist as its plain impossible to test all C64 software in the existence. even if it could be done some details are so tiny it takes a good eye to spot them,many would be overlooked. you must note that several flaws of the emulation havent been exploited yet,creative coders going beyond the standards are likely to stumble upon them.
Quote:LoL! Didnt know I already forced David to change the emulation :D Is it the writes to $d01c in the display-area?
correct |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Just to show that neither Hoxs nor Vice are anywhere close :
Real Thang, Vice or Hoxs?
This will discriminate nicely between a real machine, hoxs 1.0.5.19 and vice 1.22.
You see how easy it is to tell what is what.
Anyway, since the trend seems to be to exclude emulators from running the demos (in the hope that the authors will improve them), I'm seriously thinking to exclude Hoxs to run my next demo, simply by requiring an Action Replay to run.
OOPSIE :D apparently new VIC's seem to behave the same way as Hoxs, but I have no way to test a new VIC.. Anyway, old CMOS VIC should be the standard ;) Since HOXS doesnt emulate new VIC, as there are no grey dots. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
I will have to resort to watch your demo on a youtube cap then or something :) anyways whats good in shrinking your audience, even putting efforts into it ? |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:You see how easy it is to tell what is what.
not that easy as you already know. the 4 pixel shift on $d016 writes introduced in Hoxs64 v1.0.5.19 seems to behave in a slightly different manner on the 8565 compared to the 6569. Ive seen software that displays a 4 pixel glitch on the breadbin while no glitch atall is shown on the C64C. Hoxs64 displays no glitch in v1.0.5.19. you've probably exploited this difference and your real VIC detector became a 6569 detector in effect.
one thing needs a further investigation though- heres how the glitch would look on my C64C:
Hoxs64:
this will need to be corrected if David decides to go further down the 8565 route.
you wrote in the comments that the screenshot from VICE looks wrong. how does it differ from the breadbin ? i have no breadbin to check my self.
Quote:Anyway, old CMOS VIC should be the standard ;) Since HOXS doesnt emulate new VIC, as there are no grey dots.
not really,the VIC-II in Hoxs64 is quite like the 8565 but without the grey dots. other tiny differences between the old and the new VIC exist,your detector fails on one of them. |
| |
enthusi
Registered: May 2004
Posts: 677 |
ec64:
How is it supposed to look after all? |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: Quote:You see how easy it is to tell what is what.
not that easy as you already know. the 4 pixel shift on $d016 writes introduced in Hoxs64 v1.0.5.19 seems to behave in a slightly different manner on the 8565 compared to the 6569. Ive seen software that displays a 4 pixel glitch on the breadbin while no glitch atall is shown on the C64C. Hoxs64 displays no glitch in v1.0.5.19. you've probably exploited this difference and your real VIC detector became a 6569 detector in effect.
one thing needs a further investigation though- heres how the glitch would look on my C64C:
Hoxs64:
this will need to be corrected if David decides to go further down the 8565 route.
you wrote in the comments that the screenshot from VICE looks wrong. how does it differ from the breadbin ? i have no breadbin to check my self.
Quote:Anyway, old CMOS VIC should be the standard ;) Since HOXS doesnt emulate new VIC, as there are no grey dots.
not really,the VIC-II in Hoxs64 is quite like the 8565 but without the grey dots. other tiny differences between the old and the new VIC exist,your detector fails on one of them.
There's the white one-pixel sprite at the right top. In your vice screenshot, there's 3 yellow pixels around it and those shouldnt be there..
Anyway, the major difference is also in the 2nd set of orange 'bars'. Mine looks like your shot from the real c64.
I didnt know there was a difference between the NMOS and CMOS VICS regarding these things :P Is there any document about it? |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: ec64:
How is it supposed to look after all?
OMG! that looks even more wrong :D
I see green in your screenshot, and that definately should not be there. Also the bottom 'mess' looks 1 cycle shifted to the right. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:There's the white one-pixel sprite at the right top. In your vice screenshot, there's 3 yellow pixels around it and those shouldnt be there..
hmmm im puzzled now. these 3 yellow pixels are present in Hoxs64 upto v1.0.5.18 where a real C64 is detected. in v1.0.5.19 these pixels have disappeared (cant see any other difference) and it is now detected as Hoxs. what does your routine check for if not these yellow pixels ? i thought the logic was: if the 3 yellow pixels are present then report it as a real C64.
EDIT:
Quote:I didnt know there was a difference between the NMOS and CMOS VICS regarding these things :P Is there any document about it? no,its undocumented afaik. |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: Quote:There's the white one-pixel sprite at the right top. In your vice screenshot, there's 3 yellow pixels around it and those shouldnt be there..
hmmm im puzzled now. these 3 yellow pixels are present in Hoxs64 upto v1.0.5.18 where a real C64 is detected. in v1.0.5.19 these pixels have disappeared (cant see any other difference) and it is now detected as Hoxs. what does your routine check for if not these yellow pixels ? i thought the logic was: if the 3 yellow pixels are present then report it as a real C64.
EDIT:
Quote:I didnt know there was a difference between the NMOS and CMOS VICS regarding these things :P Is there any document about it? no,its undocumented afaik.
Let me think.
Yellow pixels are %01, so they count as background. The should not give a detection. As you can see in the hoxs screenshot you posted, the pixel below my sprite pixel is now orange-colored. -> orange is a %1 pixel, so does give a hit (hoxs detected). Vice has a yellow pixel there -> no hit == vice detected (or real machine).
On the left there's an area which looks the same, i have a red sprite pixel there. In your Hoxs screenshot, there's a yellow pixel underneath -> no hit. So the combination of left = no hit and right = hit tells me it is Hoxs.
My old vic seems to have no hit on the right OR left side.. Basically there's %0 beneath my white sprite pixel.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
WVL: U naughty boy, have you turned my PD-display code into an emufuxx0r? ;D |
| |
DeeKay
Registered: Nov 2002
Posts: 363 |
Quote:You can use it to tell the user to buy a real C64 (Tense Years by Onslaught).
*cough*DeusExMachina?*cough* <:-)))
Anyway, having done a little Sideborder coding with my quite limited coding skills recently I was astonished how quickly I made something that VICE did not emulate properly (there was an extra black line at the right border where the upper border goes into the screen on c64 and not in VICE). Some days later, Widdy showed me a simple stable raster he made on the real c64 - which was not quite so stable in VICE! This is all quite simple and generic code, the original SB-code I worked with was even from 1988!
I thought It would take a lot more skills to actually make something that does not show correctly in VICE... Still some way to go with emus it seems!
I somehow have a feeling there's still alot more ways where emus go wrong, only that they're never used in any program, because they just show black or garbage on c64! So you never see how these "effects" fuck up on an emu...
You know, simple stuff like switching on multicolor in ECM, only on a much higher level! ;-)
On a slightly more optimistic note: Oliver Achten (MMC64/Replay) said after he made that Amiga-on-a-chip, that the c64 already probably is the most accurately emulated and well-known computer on the planet, and that Amiga coders have never even come close to that level of sophistication, because they never coded as much pedal to the metal as c64 guys did, with their C compilers, blitters, bitplanes and all that fancy stuff they got by default! ;-) He said with the timing knowledge he got through making that FPGA Amiga it would now be a walk in the park for him to fuck UAE & Co thrice over before sunrise with some emufuxxor! 8)
So... when will emus finally be able to do drivesounds and PWM-dimming of the drive-LED, like 1541u does? 8) |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quoting DeeKay*cough*DeusExMachina?*cough*
i was trying to give more recent examples than that:)
Quoting DeeKayI thought It would take a lot more skills to actually make something that does not show correctly in VICE... Still some way to go with emus it seems!
VICE is not the role model for accurate emulation,its known to sacrifice accuracy for speed optimization (line based sprites etc). only Hoxs64 emulates everything on a cycle basis.
Quoting DeeKaySo... when will emus finally be able to do drivesounds and PWM-dimming of the drive-LED, like 1541u does? 8)
the drive sounds are implemented in the german emulator Emu64. also Micro64 (not released) emulates them but they dont sound atall like my real 1541II would do. does 1541u emulate the click of opening/closing the latch when a disk image is attached/detached ?:)
Quoting WVLAnyway, the major difference is also in the 2nd set of orange 'bars'. Mine looks like your shot from the real c64.
Hoxs64 is fixed in the latest beta to display it correctly (as per an 8565 VIC):
 |
| |
DeeKay
Registered: Nov 2002
Posts: 363 |
assiduous: Sorry, I don't do Windows, so HoXS64 is no option for me! <:-/
You can say what you want about VICE, but they're the only crossplatform c64 emulator there is (that Java-based one notwithstanding, I'll just ignore Frodo for now, since AFAIK it hasn't been updated in years - But what about that ec64, enthusi? That's an X window! 8)... I'll just assume those other Emus you quoted are Windows-only, too..
Crossplatform, people! It's not rocket science! SDL is more than sufficient for a c64 emulator! Why the fuck can e.g. CCS not be done in SDL, it has its own c64-based config screens anyway! |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
have you tried Wine ? Hoxs64 is reported to work fine on Linux in the environment of Wine,dunno about CCS. |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote:
Crossplatform, people! It's not rocket science! SDL is more than sufficient for a c64 emulator! Why the fuck can e.g. CCS not be done in SDL, it has its own c64-based config screens anyway!
Was there not, in fact, a linux version of ccs 0.9?
Quote:
have you tried Wine ? Hoxs64 is reported to work fine on Linux in the environment of Wine,dunno about CCS.
hoxs works for me (use it under wine a lot) but ccs did not. last i checked. I can try again now if anyone cares. |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:hoxs works for me (use it under wine a lot) but ccs did not. last i checked. I can try again now if anyone cares.
please do. btw,do you use the latest Hoxs64 (or any directX9 version) ? Im wondering if Wine comes with the directX9 libs. afaik Hoxs64 v1.0.5.0+ requires that d3dx9_31.dll is present either in the directory of Hoxs or in the system. |
| |
enthusi
Registered: May 2004
Posts: 677 |
Deekay:
ec64 uses sdl but for now compiles only under UNIX.
it should be not problemto have it fully portable.
BUT it can not at all match other EMUs yet. I hope this will change in the future. Alot. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
enthusi: Is Nic ( / The Dreams) getting active with ec64 again or are you taking over? :) BTW fully portable may not be that easy, as it contains some x86-assembly. |
| |
enthusi
Registered: May 2004
Posts: 677 |
well portable as in win/unix :) Sorry that wasnt very specific. Its fully x86-asm. Only SDL + frame are C.
NO, Im not in there. Im just a user though Id love to see it grow. There are some enhancements done yet by him recently. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
Quote:
Its fully x86-asm.
fail |
| |
DeeKay
Registered: Nov 2002
Posts: 363 |
Yeah, fail! 8) And so is WINE for that reason.... Linux does not only run on x86, you know?... |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Most MAC's are corrupted now with that Intel chip in them :-)
There just gearing up for the whole M$ takeover.... Remember sometime back good ol' Billy boy "invested" yea thats the word. Some odd thousands or was it in the MILLIONS? To uh... Help out this company ;-)
|
