T65 core bug (Page 4 of 4)

Finally - just checked in a new version of the t65 core (plus a c64 build using it). The core supports all undocumented opcodes and runs with the correct timing (also for NMI/IRQ interrupts) as far as these can be checked with existing test suites. I also did some clean up and improved the comments especially in the instruction decoder section, this should make it easier to check the decoding for specific opcodes. The toughest thing yet was hunting down out the last fail of the Lorenz CPU test: how the real core handles NMI requests while a BRK command is executed. Had to do quite some tests on real 6510 using a FDIL as test harness and compare with simulations (thus it took a little longer). I have to admit I solved this on the t65 core somehow in a brute-force way, but it works now and can be build properly so far - and it opens up some room for improvements later on

Currently I checked with the C64+C1541 core:
- passes all Lorenz v2.15 CPU tests (also IRQ, NMI  and instruction function/timings; memory map; CPU port) on disk 1 + 2
- passes some initial CIA tests on disk 2 (until the "cia1tab" tests, which shows some wrong register readouts)
- passes 1541 testsuite v0.33 (CPU tests running on the 1541 core)
- and I checked some games, just to be sure it is ok

I'll run also some games - ah, mean tests ... - with the VIC20.  Of course there is still the chance that there are still some issues with situations not tested by these suites. But I'd say if ost has some chance to check it with his core as well and it is fine, we can prepare a new release out of it...

Soon time to toss a random new demo at it again then!

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

Wow, just diff'd it. You have been busy!

I'll be giving it a test in Asteroids shortly

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...

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...

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.

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).

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 )

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...

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

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