| |
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. |
|
... 33 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 896 |
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: 896 |
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: 896 |
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: 896 |
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: 896 |
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.
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
