VICE / Bugs / #2123 Borderpolize @ GPZ

gpz - 2025-02-08

wtf.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gpz - 2025-02-08

status: open --> closed-invalid
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Querino - 2025-02-09

hm... why is this invalid?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Zibri - 2025-02-16
  
  Post awaiting moderation.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gpz - 2025-02-09

It works on C64. It works in x64sc. x64 is deprecated and shouldn't be used. I don't know the code of that program either, and i am not going to debug someones C64 setup, should it not run a certain program not written by me.

Last edit: gpz 2025-02-09

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Querino - 2025-02-09
  
  i do not have a real c64, soi canot do any testing.
  
  zibri was saying x64and x64sc are acting differently, but then:
  
  The real problem is not that, but Border Polizei shows up in the same way on my C64 (original breadbin).
  
  so my impression was that on his (original breadbin) it looks the same as on x64 but NOT x64sc.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - gpz - 2025-02-09
    
    Super rarely this may happen on "real" hardware - the only reports i have seen were non original C64s or somehow modified ones. In any case, this may warrant a bug report for that program - not for VICE.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

rice123 - 2025-02-09

I don't have a breadbin to test but there's a report from a source potentially more reliable than Zibri about problems on a real C64:

User Comment
Submitted by DeeKay on 9 June 2022
Am I the only one that just gets a garbled centipede like screen full of chars when he runs this? and yes, I have read the manual and tried both real HW and VICE....

VICE v3.1 x64 is stuck in this loop:

.C:0946 A9 3E LDA #$3E .C:0948 8D 04 DC STA $DC04 .C:094b A2 35 LDX #$35 .C:094d 9E 82 FF SHX $FF82,Y .C:0950 E4 01 CPX $01 .C:0952 D0 F2 BNE $0946

SHX $FF82,Y looks to be the primary suspect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gpz - 2025-02-09

Deekay was using his Matthias-infested portable C64 that was somehow not 100% compatible with real C64s. The same problem exists with all programs using that timer stabilization method. (One of Krills latest 4k Intros comes to mind). It was apparently fixed in a later version of that Hardware.

And sure - its those illegal opcodes which simply do not work correctly in x64. Do not use x64.

Last edit: gpz 2025-02-09

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

radius75 - 2025-02-10

I think I can get what the OP is talking about
on dtv in standard settings and on c64 ntsc

2.png

a.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- rice123 - 2025-02-11
  
  x64sc NTSC getting stuck in the loop is quite interesting. It should escape as soon as RDY goes low during the 4th cycle of SHX $FF82,Y, why would it never happen?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - gpz - 2025-02-11
    
    Find the thread on csdb (i dont have a link handy, sorry), there might be some details.
    
    Does it hang on a real NTSC machine too? Then all is fine :) (The program wont work on NTSC anyway, of course)
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - rice123 - 2025-02-11
      
      I dont have an NTSC C64 unfortunately. The success condition for the loop escape on PAL x64sc is: break 94d if ((RL & 7) == 3) && (CY == 8). I checked it on NTSC x64sc and due to timing of the loop (20 cycles if I count correctly) it was satisfied only on lines $b, $13, $103 where no bad lines occur . To see if there's any variation in that behavior I modified the breakpoint to break 94d if ((RL & 7) == 3) && (RL != $b) && (RL != $13) && (RL != $103) && (CY == 8) and ran the program a few times. After a few attempts the breakpoint was hit:
      
      #3 (Stop on exec 094d) 43/$02b, 8/$08 .C:094d 9E 82 FF SHX $FF82,Y - A:3E X:35 Y:7F SP:f6 ..-....C 15713108 (C:$094d) r ADDR A X Y SP 00 01 NV-BDIZC LIN CYC STOPWATCH .;094d 3e 35 7f f6 2f 10 00100001 043 008 15713108
      
      This time SHX $FF82,Y was executed on line $2b proving that there's some randomness, probably related to what line/cycle the loop starts with. After many more attempts I managed to run the program with SHX $FF82,Y triggered at line $3b causing the program to escape the loop and fail later. I wondered if that initial randomness could cause variable behavior on a PAL C64 but I couldn't ever get it to hang on the Centipede screen. If Zibri is serious about this problem he should write a test case where the loop is run starting with a configurable line/cycle and check the result.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gpz - 2025-02-11

If Zibri is serious about this problem he should write a test case

won't happen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Zibri - 2025-02-16
  
  Post awaiting moderation.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Borderpolize @ GPZ

Versatile Commodore Emulator

Version

Searches

Help

#2123 Borderpolize @ GPZ

Discussion