T65 core bug (Page 3 of 4)

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?

Ok, I'll have a play.

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

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

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

Thanks,
Winni

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

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

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

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

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

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

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     

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

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

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

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.

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

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

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.