Topic: T65 core bug

Might be of intest for other developers...
Now I think I found the bug in the T65 core, causing the c64 not working correctly:

When the "Rdy" is de-asserted while a RTS opcode is fetched, the core seems to take the return address from a totally wrong address (not even in the stack region) and the stack pointer is not incremented. So the control flow of any running software  is messed up completely when this happens.

Took me a while this night to track it down, couldn't fix yet and will take a while until I can continue with debugging.

/WoS

Re: T65 core bug

Good luck and good job!

Re: T65 core bug

Interesting about the T65 problems. I did notice that there were some later commits to the opencores branch, and I may have an instruction timing fix outstanding. May be worth mounting a real 6502 in the test rig and running against the soft cores. This was done for the T80, but never the T65.

We can also run the visual simulator from the die extraction to test specific behavior.
/Mike

4 (edited by WoS 2014-04-14 07:30:23)

Re: T65 core bug

MikeJ wrote:

Interesting about the T65 problems. I did notice that there were some later commits to the opencores branch, and I may have an instruction timing fix outstanding. May be worth mounting a real 6502 in the test rig and running against the soft cores. This was done for the T80, but never the T65.

We can also run the visual simulator from the die extraction to test specific behavior.
/Mike

I found the (public domain) Lorenz test suite, which seems to be a pretty good test for the CPU and partly the CIAs as well. This suite comes on 3 D64 files and they can run on the Replay core directly (as we have the 1541 included in the c64 setup). Sources exist as well, to easily check out what each test is doing.

Unfortunately the r6502 I am using now does not even pass the first opcode test because of the B flag - that's what I fixed already on the t65 as well. And that's the reason why I try to get the t65 working again (not to start over with yet another core). I posted the bug  found in the general lib section as it might concern other as well....

Alternatively it is possible to fit it on the FDIL v2 boards together with a CS instance to do further "in circuit" debugging running some "heavy" demos (same we can do for all other parts including CIA, VIC and SID - at least to check the digital interfaces). I set up and fixed my 6802 core for the Williams boards this way (ah, I need to do something there as well and check it in... wink )

/WoS

Re: T65 core bug

Moved the topic here to keep it together and collect further bugs / updates we may find wink

I checked the opencores SVN, the version there does not include anything new to the version in the lib folder on SVN here. It is (I think) the opposite, it misses the fix for the B flag I made, I saw smaller improvements you made and the code structuring is a little different (the version in the lib is sometimes better readable).

What I did was running the t65 against the r6500. With some tricky triggering I could capture the moment when the t65 runs "berserk" in this situation involving the ready signal (a badline from the VIC-II). This also helps to reconstruct the situation in a simpler simulation.

Post's attachments

t65_bug_vs_r6502.png
t65_bug_vs_r6502.png 204.86 kb, 6 downloads since 2014-04-15 

You don't have the permssions to download the attachments of this post.
/WoS

Re: T65 core bug

Nice, should be a piece of cake now to run up in the sim?
Looking in the T65 code, ready acts purely as a secondary clock enable. Difference is the R6800 core looks to execute one additional instruction before stopping.
    -- ehenciak : gate Rdy with read/write to make an "OK, it's
    --            really OK to stop the processor now if Rdy is
    --            deasserted" signal
    really_rdy <= Rdy or not(R_W_n_i);

Looks like r_w_n is low for that clock (hard to see the timing w.r.t the enable in that pic) - but instruction was not executed.
Then they are out of sync. This may not be the root cause - but should be fixed to progress. Which behaviour is correct?

/Mike

Re: T65 core bug

Yes, I'm trying... I made my simulation setup either too simple, or it is more than just the store/rts combination as the picture shows. Can't reproduce this problem yet...

The r6500 works and should be correct. In there you can see that after the write operation the r6500 does not fetch rts due to ready=low and processes it afterwards when ready is back, while the t65 seems to corrupt the rts instruction somehow and uses totally wrong stack addresses afterwards (I have no clue yet how this can happen) and thus jumps to a wrong return address.

And yes, the t65 in general seems not to process ready correctly at all. Could be because it was never used in a setup where DMA was used? In that aspect, the r6500 is cleaner but has quite some other issues which means it can not be used with a fast (gated) clock very well.

/WoS

8 (edited by foft 2014-04-15 21:39:07)

Re: T65 core bug

Is the PLP bug fixed too? I did an incorrect fix at some point and send it to Mike, followed by a correct one:-)

Pretty sure I fixed a couple of other minor things too - that I didn't merge back in. I switched to Peter W's core though in the A8 because it supports illegal ops 100% and a few other nice things...

edit: NB Peter's core is used with permission for the A8 core, if you want to use it you should contact him.

Re: T65 core bug

Peter's core is pretty good (very well written) but it's not fully open.
I would prefer to fix the bugs in the T65 which we "own", so to speak wink
I think the illegal op-code behaviour is fairly well understood from the die extraction, so we should add this to the T65 as well.
/Mike

10

Re: T65 core bug

mind you, even peters core (the "open" one anyway) still had a couple of nasty timing bugs - i am still spending considerable time on staring at testcode output to track one of them down =P

11

Re: T65 core bug

I have the feeling that many distribute their stuff with the T65 and use "privately" Peter's one, so noone really worked on the T65.  tongue

I'd love to use Peters core and improve this one as well, but as long as the license is that weird... sad

I agree with Mike, it makes much more sense to stick on an "real open" one, the chances that bugs get fixed is higher (at least thats still my hope).

Mike, did you take a look at the r6500 you can find in the c64 source directory? Any opinion on that? Unfortunately it was set up with some GUI coder, so the sources are not really good to maintain and fix plus some issues with timing. Tons of states without proper names, ...

/WoS

12

Re: T65 core bug

I think/hope I found the issue. Checked in a version with the fixed T65. Can successfully load d64 files to run further tests.

Now running the Lorenz tests on the t65 - first opcodes look good, but will take a while to finish...
Removed the r6500 directory again. wink

/WoS

13

Re: T65 core bug

Ive been attacking the T65 core lately, and put some readable names to all the magic constants, so now it starts to be "simulatable". Im looking at getting some undoc'ed opcodes in for the 6502 (mode=00) for the Atari 2600 core but I get mixed messages what these do.
Can anyone with experience point me to a trustworthy spec of the undoc's, including cyclecount?

Re: T65 core bug

Not really, although I do remember it being discussed. I'll keep looking.
Some links which may be useful.
Note, the visual 6502 is a simulation from the die extracted netlist and apparently does handle all the undocs correctly.


http://visual6502.org/wiki/index.php?ti … stPrograms
http://forum.6502.org/viewtopic.php?f=2&t=2241
https://github.com/mist64/perfect6502
http://www.righto.com/2013/01/a-small-p … ained.html

15

Re: T65 core bug

Btw, do you know the details about the B flag? According to the old doc, it gets set at PLP instruction, not PHP as unofficial doc says (and T65 does).. Not sure if current impl is just a practicality... There is obviously some traces of "don't really care" in there smile

16

Re: T65 core bug

MikeJ wrote:

Note, the visual 6502 is a simulation from the die extracted netlist and apparently does handle all the undocs correctly.

I think I read differently, but it does most. Some side effects related to "floating" internal level, are not handled as far as I understood.

Anyway, the T65 doesnt relate to the die, so I just need the result of the instructions...

17

Re: T65 core bug

no, the netlist simulation doesnt handle all undocs correctly - most noteably those marked as "unstable" in a bunch of documents. those arent terribly important though (as they are not stable anyway)

and ofcourse PLP would set the flags, and PHP only reads them (and writes them to the stack)

Re: T65 core bug

gpz, agreed. I was only referring to the stable ones - those which vary from chip to chip probably are not useful.
Do you have a list of the stable ones?

19

Re: T65 core bug

grahams list is fine, it should be linked on visual6502.org

20 (edited by ost 2014-07-13 20:12:34)

Re: T65 core bug

Some info, as I notice greater interest in the T65.

I have changed some of the binary magic constants into vhdl-types, so their value has a readable meaning when debugging. I also added some debug integers to each of these types, so you can easily find where they get set in the sourcecode (I wish there was a way to put the sourcecode linenumber into an integer.. For now its just an unique number pr assignment)

I also changed the behaviour of the BRK flag so it looks more like described in docs, but I really doubt it has any practical meaning. In short, it became a SR bit thats ALWAYS set, but the SR pushed to the stack can have the B flag cleared if executed from an interrupt.

I've recently had some success with supporting the DCP/DCM undoc'ed instruction at least for 2 adressing modes. I need to test the other modes. I have also prepared some of the other opcodes, but thats wip.

Next, I plan to look at other opcodes. I'd be happy to take suggestions to what opcode to look at next.

So far, I don't want to push it into the lib/T65, but will probably make a copy on the Atari2600 folder. To be able to diff it with the library version, I will push that code first, then the altered.
EDIT:Also, I may have damaged some 65c02/65C816 stuff, wich I don't really test.

21 (edited by JimDrew 2014-07-14 04:54:35)

Re: T65 core bug

I just got done writing a 6502 emulation for the 1541 drive.  There are some interesting quirks in the flags, especially during interrupts.  I also had to support all of the undocumented opcodes to support the various copy protections that used them.  I will take a look at the T65 VHDL to see what's missing.

Re: T65 core bug

You might to take a peek at this:

https://code.google.com/p/hmc-6502/

It's done in Verilog, but has complete microcode-level emulation.  I have used the 6502 test suites for checking my emulation.

23

Re: T65 core bug

I ran the SuiteATests from that repo, but it wasnt able to detect - by sim - a bug I have introduced causing a mess on C64 boot.. Trying to nail it down..

24

Re: T65 core bug

The Lorenz suite (I pushed it on SVN in .../cores/c64/sdcard/test/Lorenz) I used to check the CPU on the C64 setup on the replay run already quite far and got stuck somewhere on the second floppy, I think it was the BRK opcode behaviour you mentioned...

/WoS

Re: T65 core bug

I have Klaus' test suite too, but I don't have C65 installed to assemble it to $C000 as a normal 16K ROM (like the 1541 drive ROMs).  I will look at how much work it is to assemble it under CBMPrgStudio.