<![CDATA[FPGA Arcade — T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?id=291 Sun, 06 Sep 2015 19:32:27 +0000 PunBB <![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5646#p5646 Me too...   Yes, I am on it, just want to verify properly before I check it in.

]]>
Sun, 06 Sep 2015 19:32:27 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5646#p5646
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5645#p5645 hoglet wrote:

Hi all,

I'm not sure if this is the right place, but I've just stumbled across a bug in the latest version of the T65 core.

Dave

Sorry, I completely missed this post! WoS, u fixing this one?
Cheers,
Mike

]]>
Sun, 06 Sep 2015 19:27:57 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5645#p5645
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5644#p5644 Oh, thanks for that, Dave!

It's exactly the right place ;-)

I think it happend when I merged a new version out of the C64 and the Atari core. Will check it out and update afterwards...

]]>
Sun, 06 Sep 2015 18:44:42 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5644#p5644
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5600#p5600 Hi all,

I'm not sure if this is the right place, but I've just stumbled across a bug in the latest version of the T65 core.

The bug is that the interrupt flag is cleared on reset, rather than being set (to mask interrupts).

Looks like this bug got introduced late last year:

r978 | wolfgang.scherr | 2014-11-30 00:27:35 +0000 (Sun, 30 Nov 2014) | 1 line
Mortens atari_2600 version copied back to the lib tree (plus a fix for the undocumented ARR opcode).
Index: hw/replay/cores/lib/cpu/t65/T65.vhd
Code:
-          if RstCycle = '1' and Mode_r /= "00" then
-            P(Flag_1) <= '1';
-            P(Flag_D) <= '0';
-            P(Flag_I) <= '1';
+          if RstCycle = '1' then
+--            P(Flag_I) <= '0';
+--            P(Flag_D) <= '0';
+            tmpP(Flag_I) := '0';
+            tmpP(Flag_D) := '0';
           end if;

The old code sets the flag on reset, the new code incorrectly clears it.

I'm using the T65 core in a 6502 In-Circuit Emulator, and this bug caused an issue when it was used in an Acorn Electron.

Many thanks for all the great work on this core!

regards

Dave

]]>
Sat, 29 Aug 2015 20:14:36 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5600#p5600
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5009#p5009 Please also note that in the Replay library, the reset de-assert is synchronized to each clock domain where it is used.
This is a very standard in the ASIC world, where a sync reset on each flop is more expensive to implement. Perfectly safe if done correctly.

/MikeJ

]]>
Tue, 26 May 2015 09:41:20 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=5009#p5009
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4998#p4998 We had a discussion on this in general - especially about async. behaviour, it is always the question if you want an implementation close to the reality or optimal for the FPGA...

You are right, async. implementations are not optimal for FPGAs, but the mentioned async. reset works fine on Spartan 3E as used on the Replay, just costs a very little more ressources on the FPGA. Btw. the reset is not really anynchronous on the Replay, the timing is also derived from the clock (this is usually also the case if you get it e.g. from a DLL or similar block)... On the other hand there are only a few clock domains and everything is gated, which IMHO helps much, much more for proper timing closure (especially this helps the tools and reduces the interfaces between clock domains, which are hard to cover properly by checks).

On the replay the T65 core runs within a pure ~33MHz clock domain (divided from the DDR RAM clock) and I don't see a speed issue - so it should easily run with a 16MHz clock or a 8MHz clock as mentioned above as well. I also did a STA for my cores, the async. reset is not an issue.

Most people miss to set up proper clock and I/O timing constraints for their design and just take some tool defaults, which means they simply don't know why something fails, as the tools can't check anything.  It is simply not enough to take the code, put it in a design and download to the FPGA, like people are used from microcontrollers. FPGA design is much more than that. Thus, most of my work is without using a FPGA hardware at all, just a workstation (ok, I don't count the hours afterwards playing some games to check the stability of the setup big_smile )

The problem can also reside also outside the CPU core, especially on the bus to the peripherals and memories. Or it is a simple integration issue of the CPU core - e.g. some control signals are not correctly used, e.g. together with memories - here I had most issues to connect properly to the DRAM controller, which had nothing to do with the T65, although this guy got stuck all the time. You need a proper simulation and analysis setup, then you will find the errors and/or bottlenecks of the design. There you can also proof everything you think it could be an issue.

The T65 core is grown over time and the core got modified by several people, thus many things are for sure not optimal in the code. One day it really makes sense to clean up the whole thing, but for now it is working fine and I think it is not worth to spend the effort on it in this phase - I'd say it is better to use and test it thoroughly and fix remaining issues. Then it will be a very good "golden model" for a "fresh" implementation later on...

]]>
Fri, 22 May 2015 07:24:07 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4998#p4998
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4995#p4995 Yesterday, I downloaded the new T65 core, it works more or less fine.

But there are some issues that should be considered for updating. The main issue is the reset. It's like in all old version still unsynchronous, e.g. like in Line 287 and below:

  process (Res_n_i, Clk)
  begin
    if Res_n = '0' then
      Res_n_i <= '0';
      Res_n_d <= '0';
    elsif Clk'event and Clk = '1' then
      Res_n_i <= Res_n_d;
      Res_n_d <= '1';
    end if;
  end process;

It's often stated that altera has few problems with this construct, but this should not be used in xilinx and lattice tools.

A better style is:

  process (Res_n_i, Clk)
  begin
--    if Clk'event and Clk = '1' then
    if rising_edge(Clk) then
      if Res_n = '0' then
        Res_n_i <= '0';
        Res_n_d <= '0';
      else
        Res_n_i <= Res_n_d;
        Res_n_d <= '1';
      end if;
    end if;
  end process;

"Res_n" is only used in this process, but this formulation should be used for "Res_n_i" and "Res_n_d"
in all other processes.

I can't proof it, but I believe that this unsync. Reset causes problems whith higher clock rates.

]]>
Fri, 22 May 2015 04:07:05 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4995#p4995
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4990#p4990 scott451 wrote:

Can someone please tell me the relationship between clk and Enable on the T65 core?   Most of the examples I've seen use a 12Mhz clock and a 1.5Mhz enable.  So does that mean the clock to enable ratio needs to be 8:1?  So if I want a 2Mhz enable, I assume I need a 16Mhz clock?   I would actually prefer to use 4:1  so an 8Mhz clock for a 2Mhz enable.

Thanks,

-Scott

This "Enable"-signal can be used for different jobs:
1. as Clock-Enable-signal (divide the clock edges/slows the design down)
2. Enable/Disable the Core
(1. and 2. can be used in conjuction)
This signal is one of my most beloved T65 features.

scott451 wrote:

..  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.  Any chance I could get a tarball of the latest update to the T65 vhdl?   

Thanks for the help.

-Scott

To understand this problem you have to take a closer look into MOS's 6502 timings. A typical read-cycle is: Set the address at rising edge "E0" and receive the memory data at the next rising edge "E1", so you have no room for any register stages used by most memory controller.
Simple example: An internal RAM (always with registered address as input and optional registered output data) need a minimum of 1 clock cycle, what means the data is valid after "E1" and not before.

To solve this problem, you can introduce a second clock, 2 or 3 times faster than the T65-clock or use this "Enable"-signal as ClockEnable. The second solution is the better one, because this results in only one clock domain. (and: this approach runs on most Altera's Cyclones and Xilinx' Spartans with more than 100MHz).

]]>
Thu, 21 May 2015 12:16:22 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4990#p4990
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4491#p4491 I can update the opencores page.

]]>
Mon, 02 Feb 2015 20:32:58 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4491#p4491
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4488#p4488 scott451 wrote:
wolfgang wrote:

It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...

Thanks for the info.  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.

Depends on the cpu_clk, the used FPGA and the connected stuff on the CPU bus, of course. There is for sure no generic answer to this. Maybe from experience: 1...2MHz on cpu_clk should easily work on any FPGA you can currently buy with a few I/O, RAM and ROM connected. But a 16...20MHz cpu_clk could be already quite a challenge on some, to give an example (without gated clock, means ena=>'1'). Using 16MHz clock and a divide-by-8 enable is quite the same as just run it directly with 2MHz...

scott451 wrote:

Any chance I could get a tarball of the latest update to the T65 vhdl?

Got no feedback how it works on the other cores, but still works nicely for the C64/VIC-20 (and I did quite some other tests recently). So I don't see a reason to wait any longer, attached as intermediate (and "inofficial") solution until Mike got the chance to push back to opencores. If you have any issues/improvements related to this code, please post them here again...

]]>
Mon, 02 Feb 2015 19:22:54 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4488#p4488
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4486#p4486 wolfgang wrote:

It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...

Thanks for the info.  clk=>cpu_clk and Ena =>'1' did not work for me.  But clk to enable ratios of 8:1 and 4:1 worked just fine.  Any chance I could get a tarball of the latest update to the T65 vhdl?   

Thanks for the help.

-Scott

]]>
Mon, 02 Feb 2015 11:00:23 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4486#p4486
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4485#p4485 I'll be giving it a test in Asteroids shortly wink

]]>
Mon, 02 Feb 2015 09:19:15 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4485#p4485
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4484#p4484 Credits have to go to ost as well. He also did quite some fixes.   As said, I did still some "brute-force solutions" for some of the undoc stuff, I am sure there is also a more efficient way when looking hard enough for it (but I assume noone really cares for now as long as it does what it should do - so it is a Pareto-like solution wink ).

It still has a lot of flaws in the cycles usually not important for "normal use" (e.g. what the address bus shows in certain cycles without explicit bus access) when comparing to a real 65xx. So sooner or later I will definitely write a whole new implementation of such a core, opcode by opcode. I see it similar to the software world, you need to really throw away stuff and re-code to get closer to an optimum and get rid of burdens from earlier assumtions which might not work out well enough.... Most work is setting up proper test sequences and do verification, not at all the coding, though...

]]>
Mon, 02 Feb 2015 08:03:26 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4484#p4484
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4482#p4482 Wow, just diff'd it. You have been busy!

]]>
Sun, 01 Feb 2015 23:14:03 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4482#p4482
<![CDATA[Re: T65 core bug]]> https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4474#p4474 It's just clock gating, you can take any ratio you want (and even just set to constant 1, if clk in = cpu clk, when e.g. used on a FDIL or so...).

I think the Replay c64 core uses ~32MHz and divides by 32 (4*8) and the Replay VIC-20 core uses ~26MHz and divides by 24 (4*6) to generate the enable. I did the setup quite some time ago and I would need to have a closer look if you need exact numbers, but as I said it does not matter what ratio you use (the upper limit depends more on the performance of the used FPGA)...

]]>
Mon, 26 Jan 2015 20:10:07 +0000 https://www.fpgaarcade.com:443/punbb/viewtopic.php?pid=4474#p4474