C64 - timing(?) problem in The Space is Broken demo #160
Comments
|
@gyurco thanks! |
|
should be fixed in upcoming unstable/nightly build |
|
Thanx a lot :) |
|
@gyurco @sorgelig @F-RX I was testing an our established list of demos before considering pushing this fix in the Mega65 C64 core (which is a port of the mister core). We have a few demos having visual glitches (the same as on mister). So i compared the behviour with and without this fix on mister, and it obviously introduces a regression in at least one demo : https://csdb.dk/release/?id=198283 in this XMAS mega demo we have a visual glitch on both Mister and Mega65 C64 core which you can see here : https://www.youtube.com/watch?v=OUUgmUE7avs&t=17s in the bottom right corner 4 black pixels are showing up during a few seconds, while the expected behaviour is the following : https://www.youtube.com/watch?v=p0ddV07WC8o&t=561s With your new fix, we now get an even more unexpected behaviour : The top and bottom borders which are supposed to be opened, now get closed and the Star at the top of the screen gets now half hidden :
Can you guess what could be the link between your fix and this unexpected behaviour ? Thanks, |
|
Try this: |
|
@sorgelig could you backport to mister so that i can test on mister ? thanks ! |
|
Thanks, this seems to fix the XMAS demo issue. |
|
@makigumo many thanks will ask the person generating the core for me to provide a fixed build |
|
i've pushed the changes |
|
@gyurco @sorgelig @F-RX @sy2002 Plush 1997 +H2K (https://csdb.dk/release/?id=11755)
The fix introduced another slight glitch :
On the picture, the 2 circled rectangles will shortly blink while it does not happen without the fix. I know that this demo is old, has already known glitches, but it's an additional one, and even it's not the best demo out there, we can't garantee for sure that it will no impact other demos. I also recognize it's probably very complex to figure out why we have another additional slight glitch. In such a situation it's quite complex to decide what to do and i won't have time to run our full 180 demos benchmark. If you have any idea about what could produce this additional glitch ... Olivier. |
|
@sorgelig @gyurco @makigumo @sy2002
Then +H2K was broken by FIX1. though it was not fixed by FIX2 as Xmas Mega demo was. Also, while so far i only tested our 180 demos bench on the Mega65 C64 core i will probably consider at some point to perform the same tests with Mister Core each time you provide a Fix. I just have to include this in my schedule. To be as much clear as possible : We have a huge milestone in the pipe for the Mega65 C64 core. We are currently refactoring it and we want to be sure that in case of regression it's only related to our refactoring and not related to this addional Fix you have provided. When the refactoring is done and we know we did not introduce regressions, then we will obviously test this Fix with the MEGA65 C64 core. I will have to run again an inspect each and every single demo of this 180 demos bench. I will do this for the Mega65 C64 core and the C64 Mister core. Olivier. |
|
This should fix the regression: The shaking at the beginning is a problem of a stable raster, I'm not sure how to fix it without breaking everything else (if the raster interrupt is fired one cycle earlier or later, then the scene is fixed, but a lot more is broken). |
pushed |
|
@sorgelig obviously there have been 2 consecutive commits (1hour interval between both) generated. I guess i have to use the very last one ? |
|
the last one is about NTSC sprites fix (for mario bros). |
|
@gyurco @sorgelig @sy2002 I got the core generated and H2K+ glitch introduced by previous fix is gone. Surprisingly (And frankly i don't have any clue), but the disk swap is now working. Basically here are the results of this "fix on top of fix" Fairlight 2023 The Space is broken => Fixed and no regression to as honest as possible, this last fix has probably amplified a bit the first glitch of +H2K, but this glitch has always existed, so i would say, no big deal. So far and considering This nice demo from fairlight is fixed and also other demos are not suffering from it, i think we can forget about the already existing glitches in +H2K (which are anyway hard to fix without impacting other demos). Because The core is pretty much really good when it comes to Demo accuracy, i would like to keep testing other demos with this very last fix and ensure they are not impacted. So @sorgelig @gyurco are you ok if
? If you are Ok, i will keep posting the results over time in this issue. Testing demos is quite time consuming (as i really watch them carefully from beginning to end) and if i suspect something is wrong i re-run it with the previous core to ensure what i see also existed in previous core. But if you are ok i will keep posting here on a regular basis. Olivier. |
|
On the topic of vic-ii inaccuracies. |
|
@makigumo this is where it becomes also tricky : I also have to admit that my knowledge when it comes to this whole topic is limited. A friend of mine has confirmed his VICII-Kawari is really accurate, but again, it's just a VICII implementation on top of the real hardware which in itself is perfectly timed. In the C64 core it's more that the VICII itself. Last but not the least, among these 180 demos i'm talking about a huge majority works perfectly. So i tend to believe that if the VICII fpga implementation was not accurate then we would have way more glitches than what we have now. That's why i'm talking about timings as a "whole", not from a VICII perspective only, but from a C64 perspective. |
|
The timing differences are probably only an issue on the hardware side, e.g. speaking to the other chips. So my uneducated guess would be that they don't really matter for our use-case. The current core itself is currently only switchable between PAL/NTSC (6569/6567R8) with no mention or support of the 8562/8565 variants. So we wouldn't lose any functionality. Testing the Kawari implementation might reveal if the (very few!) remaining graphical issues with the core are with the current VICII implementation or lie elsewhere. |
|
The timing differences are visual. This Vice test shows them: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VICII/vicii_timing/ Compare vicii_reg_timing.prg.png with vicii_reg_timing.prg-8565.png and you can easily spot them. As mentioned by the OP the C128 core didn't have the original issue probably because of the timing changes I made. I looked into these timing changes for the C128 core because the C128's VIC is an 856x and the changes were necessary to get the C128 demo, Risen from Oblivion, working, but there's still one small visual timing related glitch with that demo in the C128 core. gyurco's fix is different from mine, and better, so I'll update the C128 core's VIC with these changes soon. |
|
@eriks5 thanks for the insights and the clarification about the timing differences between both models. |
|
My (mostly) uneducated guess is that the timing changes are related to the change from NMOS to HMOS-II technology of the chips, so all transistors are of a different type with different timing characteristics. I read somewhere that the gray bar colour glitch you can see in the 856x reference pictures is temperature related. Some chips don't show them when they're hot, while other chips always show them, so to me this seems to be a transistor-speed related thing. |
|
The one-pixel glitches are not due to CPU, but the VIC-II has plenty of possibilities to use specific registers at the specific (pixel) time, which is shown by the vicII-reg-timing tests (in some videos, Bil Herd and Al Charpentier even said there are a lot of timing violations inside the chip, so a lot of signal delays are not even intentional). The glitch at the beginning of the demo is a problem of the raster interrupt. The demo uses the double raster interrupt method to have a stable raster, the one described here: As written: So at the end there are two possible outcome of the second interrupt, however only one of them makes the demo good, the other one introduces the glitch. I wonder why doesn't it happen on real HW. |
|
The gray bar colour glitches showing in the 856x timing reference picture I linked above are a perfect example of those internal timing violations: I suspect the colours are fetched from the databus while the internal bus is still high, causing the pixel to be colour 15 (gray) until the databus latches are stable one pixel later. I had to implement this glitch in the C128 because the Risen from Oblivion demo uses it for the starfield part. |
|
@gyurco It's stable on Real hardware, on Ultimate 64 (closed source fpga implementation), so i suspect the raster interrupt is in any case stabilized, otherwise don't you think it would glitch on real hardware ? What makes you think the code is not stable in itself ? But indeed this demo is really strange when it comes to its behaviour (like a few other ones). It's really surprising as it glitches a lot while many other "heavy" demos all relying a very precise timings perfectly work. It could also be related to the demo interracting with the 1541 and the loader used in it. If for any reason it's very sensible to 1541 behaviour that could explain. I've seen demos completely failing on very old 1541 true device (glitch, demo broken) simply because of it's sensitivity to 1541 device which of course changes over time when the hardware gets old. If the code cycle accuracy is dependant on 1541 device access then it can be a reason for the demo misbehaving. It's an old demo, and i guess unless we have the source code to understand what it's doing, it's going to be really hard to fix. I would say that we should not intend to have it work at any price. Meaning, what matters is the global stability and accuracy of implementation. |
|
I didn't imply the code is bad and not stable, but I just don't understand why does it work: If somebody with more C64 expertise can explain it, then it would be possible to fix. Here's the second interrupt handler code, from $afd0-$afe5 = 55 cycles ($afd5-$afd6 loop is 19 cycles). |
|
@gyurco i do not fully get you. Instr Cyc TotCyc |
|
updated the list of tested demos. |
When it comes to issues this is what we still have :
Coma / 1997 / Void [second disk swap not detected]
Onslaught / 2015 / 20 Years Onslaught When it comes to Disk swap issue, it's actually Random : Yesterday I've tested 11 old unstable cores with "+H2K" and thought i had found one of them for which the issue was solved. However, today, doing the same test, this "supposed to be working" core fails again with disk swapping with "+H2K". |
if it's on couple bottom visible lines then it's again blanking position. On CRT you can't see it due to overscan. |
Actually, when it comes to unexpected black line it's above the beginning of bottom border, so not sure that in this case it's related to blanking position. And blinking pixels, they usually happen in the visible part of the screen (meaning outside of borders and not towards the board). Anyway I will clarify this in a dedicated issue with pictures showing evidence of the glitches. |
I should not have switched to dual SDRAM on my mister since i do not have VGA output anymore. But we have the exact same visual glitches on Mega65 and i have a vga output with a vga to scart cable so i will be able to confirm on my CRT. |
|
With dual SDRAM you still can use DirectVideo mode with compatible HDMI-VGA converter and have the same VGA signal. |
* Fixes this issue from the MiSTer repo: MiSTer-devel#160 * VIC-II: reset rasterY to 0 one cycle later * Offers VIC-II selectable variant (NMOS/HMOS) * Adjust border size (HBlank shrunk by 2 pixels)
|
a very visible glitch in "Wonderland XII" [has obviously always existed] Happy new year! Where is this glitch? I didn't catch it. The garbage at the bottom and top in the 'cat' scene near to the start is just blanking issue, those lines are not designed for human eyes. |
Happy new year ! |
|
In this video you can see the same: Probably those lines are not visible on an old CRT. They can be blanked if annoying on LCDs. Upd.: link with timestamp: |
Many thanks for the link. Do you have an idea why this does not happen with all the demos which are opening the borders ? |
|
Why they put sprites only 2 lines below? Well, you should ask the demo authors about it. Probably those 'garbage' lines are also considered off-screen by them. |
|
Since CRTs never been the same, on some CRTs you could see border more, on some less. And some demos taking in account either larger or narrower border. Cutting border as much may hide some supposed to be visible part on other demo. May be simply disregard it. |
|
Yes, |
|
@sorgelig @gyurco I don't want to make any assumptions about the root cause for disk swapping not working for a few demos, but knowing a bit about how a demo is coded, i would not be surprised if at some point it's not just a matter of timing and interrupts used to check the disc change being bypassed for whatever reason (timing issue). Among the 190 demos more than 50% are multi disk demos and the disk swapping perfectly works. It's not heavy priority as it has always existed as far as i could check, and it's probably not trivial to fix. |
|
I think it's about some timings of open/close led/lid. Some demos are trying to be too smart to check the write protect LED to make sure disk was physically removed/inserted (not just lid opened/closed) with some timeouts added. So i believe the issue is around this. |
* Fixes this issue from the MiSTer repo: MiSTer-devel/C64_MiSTer#160 * VIC-II: reset rasterY to 0 one cycle later * Offers VIC-II selectable variant (NMOS/HMOS) * Adjust border size (HBlank shrunk by 2 pixels)
|
@paich64 As discussed and FYI: I merged this to the C64MEGA65 core and hardcoded "old HMOS" mode for now, because I understood that you did all the regression testing that you mentioned above in #160 (comment) using "old HMOS" mode: https://github.com/MJoergen/C64_MiSTerMEGA65/commits/92027e5cbc9612a3515db8f392b456f30bd8be79/ Huge THANK YOU to @gyurco and @paich64 for their hard and thorough work on this issue. |
I've pushed change to fix disk swap for these demos. |
|
Many thanks !!!! will test asap !!! |
I'd like to suggest to change the OSD selection from
to
For CIA and SID variant selection the chip number is also used, and emulators (Vice, Z64k) also use these numbers to select a VIC variant instead of NMOS/HMOS. |
Many thanks, the issue is perfectly fixed ! And I tested other demos which did not have the issue and disk swap keeps working as expected. Nice Fix, it really makes the difference and you have possibly fixed hundreds of other demos which i could not test (there are thousands) and which could be suffering from this disk swap issue. I'm still working on the .md file. I will provide it here asap. |
This fixes for example Coma/Void, +H2K/Plush, Royal Arte/Booze Design and Soiled Legacy/Resource. Ported from MiSTer's commit MiSTer-devel@8fa71ca MiSTer's GitHub issue 160 was "re-used" for this fix which is completely independent from the above-mentioned one, this is why we are linking to a specific comment: MiSTer-devel#160 (comment)
This fixes for example Coma/Void, +H2K/Plush, Royal Arte/Booze Design and Soiled Legacy/Resource. Ported from MiSTer's commit MiSTer-devel/C64_MiSTer@8fa71ca MiSTer's GitHub issue 160 was "re-used" for this fix which is completely independent from the above-mentioned one, this is why we are linking to a specific comment: MiSTer-devel/C64_MiSTer#160 (comment)
|
@sorgelig is there a way to find the list of included changes in each new unstable build ? Edit : never mind, i found it. |
|
@sorgelig attached is the .md file reflecting regression tests done with C64_unstable_20231223_1682a5.rbf. there are
Note1 : The visual glitches are very slight This is a WIP .md file : I have recorded all the videos to show evidence of issues but i still have to upload them on youtube. |
|
I think first column and sorting should be by demo name, IMHO |
|
I agree, it will be updated accordingly with the next version |
I found a C64 core synchronization problem in Space is Broken - great demo by FAIRLIGHT.
In some scenes, artifacts appear that are not visible on real hardware or in the VICE emulator.
https://csdb.dk/release/?id=234768
https://www.youtube.com/watch?v=M2fCRbLwU74
On C128 the demo works fine.
The text was updated successfully, but these errors were encountered: