26

Re: T65 core bug

Wolfgang, does the lorenz test have a run option to start with a specific test?

27

Re: T65 core bug

just load and run the individual test manually

28

Re: T65 core bug

Yup, It continues from there as far as I can remember...

/WoS

29 (edited by JimDrew 2014-07-15 21:58:40)

Re: T65 core bug

ost wrote:

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

I have a version that I made that assembles to $C000 and becomes a 16K ROM, complete with the reset vector.  Let me know if you want it.   When reset, the 6502 runs the suite.  It sits in a forever JMP <-to self loop when done, but location $210 contains either $FF for success, or the number of the test routine that failed.  It needs RAM at $0000->$0400.  I am going to make ROM files with the Lorenz and Klaus test suites.  16K is the size of the 1541 drive ROMs, which is what I am working on right now with my 1541 drive emulator hardware.

30

Re: T65 core bug

JimDrew wrote:

I have a version that I made that assembles to $C000 and becomes a 16K ROM, complete with the reset vector.  Let me know if you want it.   When reset, the 6502 runs the suite.  It sits in a forever JMP <-to self loop when done, but location $210 contains either $FF for success, or the number of the test routine that failed.  It needs RAM at $0000->$0400.  I am going to make ROM files with the Lorenz and Klaus test suites.  16K is the size of the 1541 drive ROMs, which is what I am working on right now with my 1541 drive emulator hardware.

Sounds very interesting. It would be even more nice if you could write all char output to a fixed adr 0, cause I have a testbench that picks it up and saves it.
Please post it here smile

31

Re: T65 core bug

While Im at it.. The NOPAX seems to test the 1b opcode. My doc suggests this is a ASO/SLO, not a NOP or skip command.

ASO abcd,Y      ;1B cd ab    ;No. Cycles= 7

Weirdly enough, 1b is not in the sourcecode's opcode list..

opcodes  .byte $1c,$3c,$5c,$7c,$dc,$fc,0

Is the D64 (disk2) bugged?
Did I misunderstand the output? It says:

nopax
before 1b c6 00 6c nv0bdizc f6
after   1b 6c 00 6c nv0Bdizc f6
right   1b c6 00 6c nv0Bdizc f6

32 (edited by JimDrew 2014-07-16 03:13:40)

Re: T65 core bug

ost wrote:

Sounds very interesting. It would be even more nice if you could write all char output to a fixed adr 0, cause I have a testbench that picks it up and saves it.
Please post it here smile

Address $0210 contains the completion code.  If you look at the original source code (SuiteTestAll), you can see all of the test stages.   Attached is the ROM... 16K, so place it at $C000-$FFFF.  The code actually starts at $F000 and the reset vector is set to $F000.  The rest is empty.  Yeah, it's a waste, but it is a drop-in replacement for any 6502 system.  You need 4K of RAM start at the zero page (obviously).

edit: originally I had modified this code for using only 1K so I could test it in a limited setup.  This is the original code from the svn, so it needs 4K of RAM, starting at $0000.

Post's attachments

testrom.zip 1.35 kb, 2 downloads since 2014-07-16 

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

33 (edited by JimDrew 2014-07-16 02:32:33)

Re: T65 core bug

Here is the source code for the ROM.  I use CBMPrgStudio because I have helped with that project and I know it really well.  It's for Windows, and is designed for creating C64 programs.  You can get it here:

http://www.ajordison.co.uk/

Post's attachments

6502test.zip 3.87 kb, 3 downloads since 2014-07-16 

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

34 (edited by ost 2014-07-16 09:35:29)

Re: T65 core bug

Thanks JimDrew, Ill have a play with it. The PrgStudio is also new to me, Ill test it smile

Do you know any cycle count testing tools? I guess its rather easy to hack in some kind of clk counter interface that can be read between instructions for fast testing, but even the CIA's of the C64 could be setup to measure the time of a fixed number of same instructions in a row, to give the exact cycle count. Unfortunately its been too many years since I touched any timer's at this low level, but before I give it a try, I would like to ask if you know of any existing tools for cycle count verification.

35 (edited by JimDrew 2014-07-16 17:04:56)

Re: T65 core bug

I don't know of any cycle counting testing tools - but I should probably look into that to check my emulation.  I think mine should be ok because I use a timer with a fixed 1us resolution and set a timer compare to be the instruction length (ie 2us-7us).   At the beginning of execution for each instruction I pre-load the timer compare to the length for that instruction.  For those instructions that have variable timing (adding 1us if crossing a page boundary), that is determined as the instruction runs and bumps the compare by 1us if needed.  Of course, this is a microcontroller doing the 6502 emulation (not a FPGA), but I am sure you can do the same thing by waiting on the timer to toggle before the next instruction is fetched.  In my code, the main loop processes interrupts and handles the 6522's and data separator between instructions.  This gives the proper sub-cycle accuracy that is needed for the 1541 drive emulation. 

The CBMPrgStudio has a cycle counter built into the debugger.  So, you could create some code and execute it in the debugger and check the total number of cycles.

36 (edited by gpz 2014-07-16 16:58:25)

Re: T65 core bug

Is the D64 (disk2) bugged?

use the one from the VICE repository, that one is tested and proven to work on real hardware (the original one has a quirk or two, and doesnt work on machines with "new" CIA)

37

Re: T65 core bug

Can anyone point me to details about SR rules on undoc's? I can only find if the flags change or not, but not what they change to. Take the ASO instruction, does it update on ASL result or the OR?

Re: T65 core bug

Just a heads up... I found a couple of bugs (courtesy of all of this testing) in Arthur's CBMPrgStudio's debugger.  I was checking cycle time comparison and found that ROL $75,x twice in a row crashed the debugger.  Arthur has fixed that, but then I discovered a bug in his handling of any type of indexing of SBC instructions.  He is working on that right now.  We were a couple of days away from a new release anyways, so it was good to find these things now.

39

Re: T65 core bug

Great smile
I just committed the local Atari2600 T65 (work in progress!). It seems to handle all NOP* and some ASO's (and maybe a few more in that column) for now. I suspect I got a bit eager with the load acc+X logic, but I will look at it next.
I learnt to commit more often, cause its easy to damage something, and from one day to the other, my undo buffer gets cleared wink

40

Re: T65 core bug

That's very good! cool

As soon as I can I'll check it on the C64/VIC-20 as well (currently I am quite busy at work...).

/WoS

41 (edited by ost 2014-07-19 22:42:25)

Re: T65 core bug

I'll have to do a week break from monday, but I look fwd to commit some cleanups.. Im getting to know this core by now smile
I can see there is a few cycle count errors, but one thing at a time.
EDIT:I did have to implement it on C64 to run lorenz tests.. But Im not happy until all tests pass wink Then Ill check cycle counts..

Re: T65 core bug

I just added the remainder of the opcodes.  So, I now support the list below, using those naming conventions (ASO is actually SLO, etc.).

http://visual6502.org/wiki/index.php?ti … 56_Opcodes

Arthur has fixed the CBMPrgStudio's debugger to handle the test suite that was failing.  There should be a new release this weekend.

43

Re: T65 core bug

ost wrote:

EDIT:I did have to implement it on C64 to run lorenz tests.. But Im not happy until all tests pass wink Then Ill check cycle counts..

I just changed the build.bat to use the t65 you use in your source tree. Lorenz tests pass the "nop*" variants now and fail at the "aso*" opcodes on the 2nd disk, the first disk runs completely w/o issues.  wink

/WoS

Re: T65 core bug

ost, I am not sure what you are using for a reference to the undocumented opcodes, but I used this reference:

http://www.ataripreservation.org/websit … lopc31.txt

That information appears to be correct.

Re: T65 core bug

Hello,

I maintain the AtomFPGA project over at stardot:
http://www.stardot.org.uk/forums/viewto … amp;t=6313
https://github.com/hoglet67/AtomFpga

This project, started originally by Alan D, uses the T65 core as part of the implementation of an Acorn Atom.

I'd love to get my hands on the latest T65 core, so I can see what bugs have been fixed.

I don't currently have SVN access, so would be very grateful if someone who does could ZIP up the sources and attach them to this thread.

Many thanks,

Dave

Re: T65 core bug

Sure, I can do this. Mail me at admin at fpgaarcade dot com. Cheers,
Mike

47

Re: T65 core bug

OK, some progress after battling the wind (damaged PC psu, ISE screwing up some c64 builds;I had to change start seed of P&R!, are there ISE bugs, or code issues?).. Im going afk for a week again..
New updates committed to the Atari2600 T65 source..

Re: T65 core bug

Super stuff. What version of ISE are you using?

49

Re: T65 core bug

I use ise14. I see the t65 use async reset. Thats my first suspect of weird issues, especially when using state types, wich I do. In fact I could not get it to implement at all using the commented lcycle type. Not even when telling ise to use binary fsm encoding..

Re: T65 core bug

Strange. Make sure the reset de-assert is correctly sync'd to the clock.
This is an ASIC style I've picked up with async reset, but all the resets are clocked to ensure it's safe in the clock/reset module.

Check for any inputs which are not syncronized into a state machine, can cause havoc!
/Mike