51

Re: T65 core bug

You know fpga and one-hot state machines have issues (unless you tell the tool to go safe mode). But surely sync deassert ought to work. If you want to play with it, see if you can resolve why my nextstate function dosent seem to work.

Re: T65 core bug

Happy to, point me at the bit - or send an email. Do you have a synthesised version which goes wrong?

Not sure what you mean about FPGAs and state machines? If all inputs are synchronous and timing is closed it should be ok?

53

Re: T65 core bug

In the package, replace the T_lcycle type with the alternative type commented out, then in t65.vhd replace the mcycle increment with the line that does mcycle<=nextstate(mcycle) and it stops working.
But the code that required different seed is lost I think. Im far away from the pc this week so cant help much.

Re: T65 core bug

Ok, I'll have a play.

55

Re: T65 core bug

Can anyone explain or guide me to an explanation what the lorenz "trap" tests does?

56

Re: T65 core bug

it tests address wraparound/page boundary crossing boundary cases - the readme has some more details

57

Re: T65 core bug

gpz wrote:

it tests address wraparound/page boundary crossing boundary cases - the readme has some more details

Are you thinking of the "_TestSuite 2.15.txt"? That didnt make much sense to me..

58

Re: T65 core bug

https://sourceforge.net/p/vice-emu/code … e.txt#l124

other than that - as with so many other test programs - you will have to look at the actual code and see what it does

59 (edited by WoS 2014-11-30 17:19:54)

Re: T65 core bug

@ost, had a look to your fixes in the atari_2600 source directory already some time ago and use it for my cores. Well done! Works much better than the original one in the lib big_smile big_smile

There are still some issues, currently I am looking at the "arrb" Lorenz test (opcode $6B, works now properly with my setup). If I fix something, should I put it to my local core or should we put the latest version in the lib tree again? I think our cores are the only one using the 6502 for now, so we could join our efforts here?

By the way, I also take the sources from the Lorenz test, the doc at http://www.ataripreservation.org/websit … lopc31.txt and http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes to check what should be right. I can also verify on a "real" C64.

By the way: I set up a simple stand-alone simulation environment for the CPU in the lib/cpu/t65 directory:
"tb" contains a setup of CPU + test ROM (a small RAM yet missing, not required yet but easy to add)
"tb_code" contains the build for the test ROM (I am using the CC65 toolset to generate the ROM binary)

The testbench automatically stops with a "failure" assert when the CPU accesses address $1234, so a test can be executed with "run -all". The scripts are for msim, I can also fix them for isim.

Edit: just decided to override the old version in lib/cpu/t65/... by the new one from the atari_2600 core plus my fix.

Edit2: Lorenz tests: ARRB and ANEB now fixed and checked in.

/WoS

Re: T65 core bug

Is it possible to get the updated T65 core? I've ported Mike's vic20 to the MiST and got a weird problem. When using the T65 core provided in the vic20 archive I get some runtime problems with a few games. Using the T65 core from the bbc project by Mike Stirling fixes those problems but I'm not able to type "2" anymore. All other digits work hmm

Thanks,
Winni

https://github.com/wsoltys/mist-cores/tree/master/vic20

[url]http://ws0.org[/url]

Re: T65 core bug

Hi Wsoltys,

We'll be releasing sources as soon as possible.

Best,
Mike

62

Re: T65 core bug

wsoltys wrote:

Is it possible to get the updated T65 core? I've ported Mike's vic20 to the MiST and got a weird problem. When using the T65 core provided in the vic20 archive I get some runtime problems with a few games. Using the T65 core from the bbc project by Mike Stirling fixes those problems but I'm not able to type "2" anymore. All other digits work hmm

Sorry but I can't resist and such "leeching posts" really make me angry (as I also get a lot of private mail on this with "give me the code" and missing simple keywords like "please" and "thanks" - as you did use by the way - because this also seems to be too much work today to type...). My response is also addressed to all others just waiting for the sources, and I have to problem to state my point of view on that.  This beside the fact to ask about help on your MIST setup in a Replay forum, which is not my problem here... big_smile

Seriously: while waiting on our release, how about some debugging of your solution you have and sharing some clues what is wrong (in detail) with your version?

You neither need FPGA expertise to do that, nor you need the latest sources. You just need to do debugging on VIC-20 level and tell us what's wrong with the CPU and where the problems appear and why (please with a little more details than you gave, your problem description if fine if it comes from a user, but not if it comes from a developer or one trying to get one). You can do this even on any other FPGA hardware and prepare a simple test case you can share. It is very likely something which might still need some fixing on our actual setup and even if we fixed it, you might come up with a better solution. This I'd call sharing work and efforts in a win-win approach. If you think again, who wins except you if you get the code and it works?

This debugging and preparing valuable test cases to hunt down issues is the hard work and sharing such information on bugs is the key to collaboration based on open source and the basic idea! Taking code from others and just port it to some hardware is just another form of plagiarism and it will not improve anything - furthermore it is not even 1% of design expertise needed to do that, especially when the code does not use any FPGA-dependent coding. So you don't even learn anything useful from it, except than copying and building code...

You said you want to learn how to do FPGA design, so work with what you have is the best way and will help you improve your experience.  What about trying to learn how to set up some simulation or debug environment to check why the key "2" is not working? Asking how to do that this is a totally different questions showing you are really willing to work on this topic - and we can prepare answers which will also help others who are willing to work on this, which will lead to progress here. But this is probably better to ask on the Mist forum, as I have no idea what development environment it uses and if it provides some basic setup for it as we have on the Replay.

But you can try to fix issues and post your findings here - you don't even need at all to share any sources for that, usually when you know what is wrong fixes are usually a matter of minutes and just a few lines - and much less work that browsing through yet another project structure. If you can do this, you might be sooner or later brave and experienced enough to take code from others but actually create something new (= a totally new core) - there good debugging skills are mandatory to even start with such a project and evolve beyond a "copy some code and set up the build script" state....

No offence, but everything else (also an approach just try different versions "as is" and stop working on the first issue found) tells me you are just interested in a low-effort solution with your hardware based on code from others (and maybe finally put even you name on it)...?

Frankly, your post is exactly the reason why people like me are reluctant to share their work they spend in month and years of free time and I am not alone with this - many good projects I am aware of are not open source (at least not worth the latest releases), because of similar reasons. So don't come up now with some hollow "free/open software arguments and their advantages", please - the idea is not to share code on developers level to get then just responses on a level like "I tried it, it does not work"... wink

/WoS

Re: T65 core bug

I really thought twice before posting here because somehow the MiST might be seen as a competitor. I know your kind of postings as I wrote similar things for my former project (xbmc/kodi). The difference was that this project is open source and every one could share and use our code even though some tried to make money out of it ... so be it.
As you seemed to have read from my former postings I'm a beginner and I already debugged it to the state that the right scancode is send to the core and converted to the vic code. But when it comes to the cpu core I'm lost as this is beyond my knowledge and unfortunately also time as work starts next week and I can't spend the time I want to learn more about that stuff.
That said I have to say that I'm also disappointed from your post. I don't earn anything from the MiST sales nor do I game a lot. My fun was to port cores to it and beside what you said I learned a lot from that. My dream would be to implement an own core someday but I guess it will be a dream because it seemed to be that if I don't use the right hardware I won't get the answers I need.
That was one reason I just asked for the sources and please excuse me if I don't use the word "please". It might be in a personal message in our mother tongue but here I just forgot it.
Anyway, enough offtopic talk. Please ignore my former postings and my "plagiarism".

[url]http://ws0.org[/url]

64 (edited by WoS 2014-12-31 16:08:53)

Re: T65 core bug

Oh yes, I forgot the other argument "I did also share something some time whatever it was, so I have the right to get something here"... big_smile

As I said, it is NOT AT ALL about the MIST, it is about how to work on this topic and how people understand collaboration and sharing free code in a way it is also benificial and not only waste of storage space.  I also said you used this keyword. And of course you can get something, but as I said it seems obviously at all for me it that it is for the sake of learning enough to make own cores. But your post tells me that the board you are using seems to have no developer community if you have to seek help in this forum - so why did you buy it in the first place...?

No seriously again and back to the topic, I personally don't care at all about the Mist neither in positive nor negative way, it is just yet another board out there I can't connect on my (modern) monitor. (I assume there is a community as well and if someone asks for collaboration about common things of both setups I would be also happy to work together as it helps us both, why not...)

Please read throughly what I propose after the first few sentences where it seems you stopped reading because you did get upset...

You ONLY really learn from making mistakes (and/or check out mistakes of others) and try fixing them. This require to dig down into the design and does not require sharing code. What you think that it is a big achievement is just the beginning, you have to step further if you want to really develop your own code - and this is the big step. So I have to dissapoint you again - I train many students on ASIC design and most get disappointed after they see that taking some existing VHDL codes and run a successful build after several days/weeks of work is not even the beginning of real design work (when it is about to get the first task they can't simply copy somewhere from the internet). VHDL/Verilog (digital) design is also way more complicated than hacking some C code and get it working on a computer or a uC...

So please continue on what you have, try to come to the bottom of the problem and post it here! Ask concrete questions or give hints on some code why it might not work that way or why it was done that way. You can also share some waveforms of simulations or logic analyzers. I am sure everyone here - including me - is happy to share the own experience and help fixing things if possible in a productive way. Then we all have some benefit from your learning process as well (plus Replay and Mist will get an even better core which is perfectly fine).

Edit: just sent you some mail, I assume you can now work on the latest t65 core and post further issues you find here... big_smile

/WoS

65 (edited by vlait 2015-01-01 02:06:56)

Re: T65 core bug

adding fuel to flames big_smile
MikeJ is listed as one of the T65 core maintainers so this could be thought as sort of *the* place to ask since this seems to be the only place where further development is happening:)

I'm not at all trying to criticize Wolfgang's answer, just pointing out that it is often so difficult to work with a foreign module that it's really hard to resist asking for help from someone who is familiar with the source smile

"open source" seems to be having ahard time at the moment with all the forks going on and with relatively few merges back from the forked projects. ( i'm doing it often enough to feel bad about it)

Happy New Year to each and all.

-V
(4am... grammar edit, no change to content afaik)

Re: T65 core bug

This is precisely why I can't stand "open source" projects.  I am glad that Mike is re-writing everything from scratch so he doesn't have to just give it away...

Re: T65 core bug

I think Wolfgang and I sorted it out via email. And please, I don't want to raise a discussion about open source here. It has it pros and cons. The pros are often only visible if you have enough skilled people around which might be easier in the c/c++ ecosystem than in hdl.
For the cons I only need to search for kodi/xbmc on ebay to see how many people sell stuff with our code but won't give anything back to us.

[url]http://ws0.org[/url]

68

Re: T65 core bug

I want to apologize that I did overreact here (I really got quite some PM lately exactly about that which caused my reaction as well), but I usually do not bite  big_smile   

I think it is a topic which requires continuous discussion - there are a lot of different opinions and solutions and different goals (especially commercial versus non-commercial ones). @wsoltys I am happy to take the blame for continuing the discussion smile   I do not yet have a license/solution I am really happy with. I can also say what I saw up to now does not satisfy me either. So I am interested in any constructive discussion about that and not just rephrasing some messages from the FSF site or wherever (I also know them and do not make me happy as well, although I do not say that I think they are bad in general).

Of course I benefit from code like t65 as well. And of course I want to pay this efforts back - but just put the code on a web site is neither an efficient way in my viewpoint (as this implies additional maintenance effort and usually such stuff quickly gets outdated - independent if put on a DM server or a simple web page e.g. also because of the branching issue vlait mentioned). I also know opencores and have an account there as well - but I am not working for/on opencores projects. The first code I used was from the fpgaarcade site and I did my modifications here in SVN - does not make sense to work in parallel on several repositories. Mike is t65 author as well and yes, I know he is set up there as maintainer, no problem if he finds the time to play back changes.

JimDrew wrote:

This is precisely why I can't stand "open source" projects.  I am glad that Mike is re-writing everything from scratch so he doesn't have to just give it away...

Not sure if this is really the motivation of Mike, it is definitely not mine wink 

We had some discussion on that and the goal is to open the sources somehow. But it is not so easy as one might think.  I just can say why I did rewrite parts like the VIC-II or the VIA code: not to allow setting up an own license (of course I have an own, but this is rather a side effect), but because I was not happy with the code I found (beside other good code which was simply closed source already or at least with unclear license). I also know that Mike has an other coding style than I like to use (e.g. if you compare the SID and the VIC-II implementations), but I think it is perfectly fine as long as it stays compatible and everyone can work most efficiently on his parts and it is still readable for others. I can remember someone had some complains we are using an ASIC coding style and not a FPGA coding style and he was/is of course right (I think it was about the asynchronous use of resets, which usually is a no-go on FPGAs). We are aware of that and can handle/check it properly (that's also the tradeoff between sticking on modern digital design guidelines and still keeping the functionality according to the original designs) - this also makes our projects not really the best reference for beginners trying to learn proper FPGA design... smile

There are also several t65 branches on the SVN server, simply because it is critical to change someting for the c64 to fix some issues causing that something breaks on the VIC or Atari. And I am sure as soon as I have some time left I will rewrite the 6502 completely to improve maintainability (at least for my taste, so to say) with the same style I am writing on a completely new 6802 core.

Releasing officially has also an other problem I see. From that time point it is more likely that several projects depend on and radical changes are harder to do, not to brake other code. Starting to generate branches will again have impact on maintability (to keep bugfixes synchonized between branches). Yes, data management like SVN can help here, nevertheless it is always required to be aware what the changes are to do merges properly and it does not help if it is required to do structural changes as such. But my feeling here is that the existing code is already in a state which contains most functions needed for new projects and is really stable already.

No doubt, there is also the threat of implementing something others use to make money and yes this is also one of my concerns somehow. But not really the money part which concerns me (as I don't make money out of it myself, it's just a hobby), but the missing collaboration to basically improve the code again this way - which should be the core benefit of any open source project.  Thus, if I release the source codes in such "one way" to the web and won't get anything useful back, why should I do it in the first place? It is just useless additional effort - what for? To show what a good guy I am? Providing binaries that way is something different, because users should get it in a simple way and they are not interested in the gory details. Thus my standpoint is against any "free beer" source approaches but to force people at least to ask for it and give someting back if they want to use it - at least to remind that this "bidirectional exchange" is the idea behind open source for me (and this is not necessarily the source code, as it is required by GPL, there are so many other ways of fruitful support such projects, e.g. like providing test cases or so). So I also have no problem at all (if others don't spend the effort to set up and maintain download links for each and every code like me) to simply ask for their work (and negotiate some way that we both benefit). Usually it is also needed that way, because I often have further questions to understand what/why someone did, as I also want to learn this way (and not just blindly use what I have got to come quickly to a solution I don't understand, but I can often see such a work style with others and I can also see how they struggle if something is then not working as expected), that's why I say the sources are for me only a small part in such a development process.

/WoS

Re: T65 core bug

History has shown that open source=theft=gain by others, and the only way to "fix" that is by not releasing your code at all.  I would even go as far as encrypting the .bit files so they could not be reverse engineered (which is possible now).   Yes, I have had code stolen (many times) that resulted in competing products and lawsuits.  Nobody wins, so I find it best just to prevent the possibility to begin with.

Re: T65 core bug

Most of what we build on is open source - the ARM toolchain, the programming software and some of the CPU cores are all open. While a lot of what we do here is taken by others and used for commercial gain, we also benefit in turn.

I will release the Replay framework and ARM code very soon. My cores and the libraries will follow once everybody concerned has agreed on timing and license terms etc etc.

Regarding the coding style - there is nothing at all wrong with using ASYNC resets as long as the de-assert of the reset is sync'd to the clock - in other words you know what you are doing wink Wolfgang and I use this out of habit from our ASIC work, where it's much more area efficient to have one reset synchroniser than one per flop as in the FPGA.

There are certainly advantages to using a sync reset in FPGA land, as there is the possibility of optimizing the logic, but it's not a big deal usually.
/MikeJ

71

Re: T65 core bug

I hope the stuff I added to the Atari2600's T65 is merged in to the main version?

72

Re: T65 core bug

Yes, all in so far and I continued from there. But I'll check again your last changes and when I did the merge back to the main lib - not to miss anything...

I just set up a new c64 core, most undocumented opcodes work now with the Lorenz test, only a few are left. You may give it a try with your Atari core as well?

I had a talk with Mike, he wants to push it back to the original branch. My proposal is to fix the few missing opocodes first, do a final cleanup, thoroughly check with our cores (I'll also run the 1541 core test and some critical games I know etc.) and then make an "official" t65 release out of it...

/WoS

Re: T65 core bug

Agreed wink

Re: T65 core bug

The only license that makes sense for stuff that recreates legacy cpu/hardware for this (hopefully soon collaborative outside the SVN clique) *hobby* is an open one that takes money out of the equation,   'shoot the hostage' so to speak for those that remember the movie Speed.

It worked for mame.

Re: T65 core bug

Totally agree - all my stuff has been open source from day one.
The concern Wolfgang and I have is the code being reused in commercial applications - before we have actually finished it - in some cases.
The other reason for the SVN "clique" is to reduce the support burden while we are developing - I get so many emails along the lines of
1 - What does XYZ do?
2 - Can you help my with my homework?
3 - Can you port XYZ to this other commercial board for me?
4 - I can't get XYZ to work, please fix it.
etc etc