search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
208 stars 32 forks source link

#220: uartmon update (so xemu communicates better with m65/mega65_ftp/m65dbg) #267

Closed gurcei closed 3 years ago

gurcei commented 3 years ago

Work done in relation to card #220.

There may be aspects that you're not too keen on (such as the two tcp ports opened), it was handy for me while debugging xemu <--> m65 and xemu <--> mega65_ftp conversation, but perhaps won't have a much wider audience than me (at the moment).

So I don't mind reverting that bit out, or perhaps other sections you make note of in your review.

lgblgblgb commented 3 years ago

Are you sure you want to send this against merger branch? I am not even sure if umon in works in merger since the main loop was seriously touched, and no possibility anymore to have paused emulation without serious issues, unlike in next. I thought you want to do against next till somehow umon has some remedy in merger, to be honest.

gurcei commented 3 years ago

Aah, I think I initially tried next, but then it didn't have the 'hot-registers' stuff in there (needed by 'm65', if I recall right), but then I noticed that 'hot-registers' stuff was inside merger, so opted for that one.

I guess I don't recall the backstory on the 'next' and 'merger' branches, and perhaps that 'hot-register' stuff will make its way into the 'next' branch eventually (or perhaps it has already happened already and I didn't realise).

Anyways, those were the motivations on choosing 'merger' at the time. But if 'hot-registers' has made its way into 'next' branch already, then I'm happy to jump ship to 'next' branch.

lgblgblgb commented 3 years ago

"Huston, we have a problem!"

Hmm, it's a hard decision then ... merger is intended only for the VIC-IV changes merged not anything else (in fact, any other material there is just to make it easy to see differences compared to next in some regards). At the other hand, hot registers stuff is the scope of recent/decent VIC-IV changes (thus only in merger).

The other problem that I intended to fix the breakdown of umon (in merger) in some respects because of the work done in merger first.

Also note, that merger will lose any contribution information on long term (we have some business with Hernan to avoid this in his contribution at least since it's very huge amount of this project! and even that it's kinda hard to play back the important and sane commits one more time for real in the future ...), as it's so full of small and stupid (not from your side!!!) commits, that it won't be merged to next ever in this form, "polluting" the commit log of the main project with all the non-sense (again, it's not meant about your work, but in VIC-IV based try&error kind of commits all the time). That is, merger is kind of "let's play with it" material, and the final move will be to delete merger without any really literal continuation there in terms of history of the code. I just say this, since I really don't want to hurt anybody's feeling who has the nice effort to contribute which then ends with commit in the final branches with my name anyway and without getting the well deserved contribution acknowledges.

Thus in nutshell: I'm really unsure now, what to do in this situation :-( Especially I do value of your work and effort (and to be clear: thank you!), so I wouldn't like you feel I don't care, or I don't want to deal with this. Honestly, the best would be to wait, but it's really awkward to always have this answer especially given the amount of effort you put into this deserving better answer.

Let's talk this on Discord, if you have any comment/idea, as it feels more like a current-situation kind of discussion than sane reason to write here novels (as I do now hehe ....).

lgblgblgb commented 3 years ago

In addition to my previous comment: one solution can be (but it requires work from you, and not so "nice" solution) to resolve the problem I've described, is adopting your changes from the next only leaving out the VIC-IV branch specific needs (ie: hot registers) and applying those later, when merger is in the next already. I just try to figure out something sane here in this impossible situation :-/

gurcei commented 3 years ago

Yep, I'm ok with rebasing my branch onto 'next' branch and re-do the PR from there, to assure those pieces of the puzzle are in place and await the hot-register stuff to come later.

I'm wondering if though, in the interim period, maybe I could keep the effort branched off 'merger' too, just in-case there are other commits and improvements that could be made (beyond what is covered already).

lgblgblgb commented 3 years ago

Well, you can fork anything as you want ;) Just beware, that merger is very hot stuff (not in the sense of hot registers hehe, but about changing rapidly) and you may have hard time to always adjust your work for it. That's why merging into merger is problematic as well, as even the main emulation loop is subject it be changed where all the things happening in terms of umon handler call also the problem of "pause" mode, and so on.

gurcei commented 3 years ago

Okidoke, will take the following path with it: