C64 Core

[slingshot]

Great! I'll test it. Didn't you try just to remove "enable" from the int firing logic? That way it still would not have the interrupt delayed by 2 enable cycles, and no need to use the falling edge.

No didn’t try that, I’m not that familiar with HDLs in general so I don’t know of those types of implications. Just learning as I go. Good to know though, thanks for the knowledge sharing.

Well it's not HDL speciality. Currently the code does:

....clocks...enable(flag interrupt)-clock(flag registered)...clocks...enable(flag noticed, int fired)-clock(int registered)....clocks...enable(CPU notices the int).

You can see it's 2 cycles where enable ='1' elapsed from the int fireing to the time when the CPU noticed it. Seems from your fix, this delay is too much, so there must be no enable cycle between the interrupt flagging and when the cpu notice it. If the interrupt firing is not in the enable cycle, then

enable(flag interrupt) - clock(flag registered, flag noticed, int fired)...clocks...enable(cpu notices the int)

Using the negative edge just makes two events in one cycle, which effectively doubles the clock frequency (it's ok here, but at higher frequencies this can cause timing problems).

enable(flag interrupt) - clock(flag registered)...clocks...enable negedge(flag noticed, int fired), enable posedge(cpu notices the int)

So in theory the end of both approach is the same.

[yellperil]

Yep that makes sense, thanks for elaborating.

[Sorgelig]

That fix with falling_edge is too hacky.

[yellperil]

That fix with falling_edge is too hacky.

Yes I know but I took the time to find it and at least I tried.
Now someone else better than I can implement it properly.
That’s all that matters, isn’t it.

[yellperil]

Thanks for updating the core, I look forward to studying all of your latest updates.

[Mic184]

I noticed a glitchy row of pixels on the right side of the screen kinda reacting to the screen image after the last update.
It appears the C64_20180831.rbf core isn't affected from this pixel row problem.

Nevertheless thanks for updating the core.

[yellperil]

In the source for the 8580 sid_voice.v, if you set default to triangle in the waveform selector, then the music plays for GUTZ and Hysteria with one slightly odd voice.

[SegaMan]

I noticed a glitchy row of pixels on the right side of the screen kinda reacting to the screen image after the last update.
It appears the C64_20180831.rbf core isn't affected from this pixel row problem.

Nevertheless thanks for updating the core.

Same here.
Vertical Line on the right side of the screen.

New Scaler looks great!
Great work

[remowilliams]

Just noted the extra pixels on the right hand side in the C64 core as seem to be showing in the Amiga core - posted picture in the Amiga core thread.

[JimDrew]

I just tested the latest C64 core. Although the 1541 emulation now passes all instructions, it still fails some part of every "VIAxx" test (where xx is a number). So there are still VIA issues.

[redmist]

Not sure if this has been asked before...Is it possible to output a synced ~50Hz via HDMI similar to the Ultimate64 board? I would like this for smooth scrolling in PAL software.

From https://ultimate64.com/Ultimate-64

"Video

What resolution does the HDMI output use?

• The output resolution is 720 x 576 at 50 Hz (for the PAL version), also noted as 576p50. This is a standard resolution that all HDMI capable screens are supposed to support, according to the CEA-861 standard. However, to meet the exact timing of a C64, the timing parameters of this video mode are slightly modified. I have not come across screens that do not accept the generated HDMI signal."

[Sorgelig]

Not sure if this has been asked before...Is it possible to output a synced ~50Hz via HDMI similar to the Ultimate64 board? I would like this for smooth scrolling in PAL software.

Option vsync_adjust is supported long time already. Study the forum study the Wiki for more info.

[SegaMan]

@ redmist

vsync_adjust=1 (mister.ini) should do what you want

[Flausch]

But there must be a difference, because my Ultimate64 works flawlessly with my display, while the MiSTer C64 core only produces an "out of sync" message since the last update when vsync is activated?

[Shazz]

Hi,
I just tried the core's OPL2 option and 4mat's FMX Music Demo, it "works" but that's weird, I would say some volume issues, not sure, some sounds overlap.
On my C64 and my FM-YAM cart, that''s pretty like the youtube video.

Can somebody check if my ears have a problem ? (I start to get old ^^)

Thanks

[vanfanel]

@ redmist

vsync_adjust=1 (mister.ini) should do what you want

Thing is, contrary to other 50Hz cores like Minimig, vsync_adjust=1 seems to be not working on the C64 core: I can clearly see smooth-scrolling sequences stutter for a frame, every 15 seconds or so (like Remember cracktros for an easy example).
This is the only core where I see this happen, so I guess something is not the same regarding vsync_adjust in this core...

[DanyPPC]

I found another game where is no sound: it's West Bank from Gremlin Graphics.

[yellperil]

Hi Slingshot, you probably already know, but new CIA has the old trouble with the Turbo Outrun Intro music.
Dogey @negedge workaround fixes it again. CIA passes heaps of Tests now . . . amazing!

[slingshot]

Hi Slingshot, you probably already know, but new CIA has the old trouble with the Turbo Outrun Intro music.
Dogey @negedge workaround fixes it again. CIA passes heaps of Tests now . . . amazing!

Will test it. Interesting if it really fixes it.

[yellperil]

Hi Slingshot, you probably already know, but new CIA has the old trouble with the Turbo Outrun Intro music.
Dogey @negedge workaround fixes it again. CIA passes heaps of Tests now . . . amazing!

Will test it. Interesting if it really fixes it.

Yeah I had a crack at it already as I was curious and it worked for me.

Code: Select all

diff --git a/mos6526.v b/mos6526.v
index 2bacc00..1baed99 100644
--- a/mos6526.v
+++ b/mos6526.v
@@ -471,7 +471,7 @@ reg [7:0] imr_reg;
 always @(posedge clk) begin
   if (!res_n) begin
     imr       <= 5'h00;
-    irq_n     <= 1'b1;
+    //irq_n     <= 1'b1;
     int_reset <= 0;
   end
   else begin
@@ -485,10 +485,21 @@ always @(posedge clk) begin
 
     if (phi2) begin
       imr <= imr_reg[7] ? imr | imr_reg[4:0] : imr & ~imr_reg[4:0];
-      irq_n <= irq_n ? ~|(imr & icr) : irq_n;
-      if (int_reset) irq_n <= 1;
+      //irq_n <= irq_n ? ~|(imr & icr) : irq_n;
+      //if (int_reset) irq_n <= 1;
     end
   end
 end
 
+// Move irq_n to the negedge so Turbo Outrun music works.
+always @(negedge clk) begin
+  if (!res_n) begin
+    irq_n     <= 1'b1;
+  end
+  else begin
+      irq_n <= irq_n ? ~|(imr & icr) : irq_n;
+      if (int_reset) irq_n <= 1;
+   end
+end
+
endmodule


[slingshot]

Tried it, and yeah, some samples are there. Then I realized it breaks the Lorenz tests, so I investigated further:
Seems there were 2 CIA versions, the original (6526) which is implemented now, and has the 1-cycle IRQ delay. Then there's the 8521 (not the 8520, which has a different TOD, and it's in the Amiga), which is the HMOS version, and it doesn't have the 1-cycle IRQ delay.

[yellperil]

Hmm that explains why the VICE test suite for the CIA has Old CIA and New CIA tests in it.
I’m guessing the Lorenz tests were only written for an old Breadbin. Maybe these tests would be a better benchmark.

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/

[Indcsion]

Does the c64 core support gmod2 crt games? I guess I bought a game that only works on vice or I'm doing something wrong. Its the Hunter's Moon Remaster game.

[vanfanel]

Not sure if this has been asked before...Is it possible to output a synced ~50Hz via HDMI similar to the Ultimate64 board? I would like this for smooth scrolling in PAL software.

Option vsync_adjust is supported long time already. Study the forum study the Wiki for more info.

Sorgelig, please, could you double-check that vsync_adjust=1 or 2 DOES really work on this core? It's the only 50Hz core where I'm having occasionar frame desync, Amiga core 1-pixel scrolling is PERFECT always, for example, in every situation. But this C64 core has a small framerate hiccup every 25 seconds or so, same as vsync_adjust=0.

[Sorgelig]

Tried it, and yeah, some samples are there. Then I realized it breaks the Lorenz tests, so I investigated further:
Seems there were 2 CIA versions, the original (6526) which is implemented now, and has the 1-cycle IRQ delay. Then there's the 8521 (not the 8520, which has a different TOD, and it's in the Amiga), which is the HMOS version, and it doesn't have the 1-cycle IRQ delay.

So it looks like need an OSD option to switch between versions?