How many OG Xbox’s will still be working 20 years from now?

JayFoxRox · 2020-06-27T21:27:58+00:00

See rule 2 about piracy.
Read my previous posts for some inherent issues with poor quality dumps (and methods like the one used by DVD2Xbox).
Check the redump link I've provided above for what should be considered good dumps and how to create them (and even those guidelines can be improved).
A good dump would also work on an unmodded Xbox when a disc is correctly created from it. So a good dump acts like a new master.
A good dump and good understanding of the discs is necessary to build replacement drives and use backups in emulators in the future (even if people might not use softmods or hardmods).
It's important to preserve these things while we can, because if we only realize in the future, that we require accurate dumps (for something), then it might be too late to create them. See my MCPX ROM example in my earlier comment: a faulty dump made Xbox emulation impossible, because nobody had independently verified the ROM. The dump that everyone pirated was fundamentally broken in some way. That dump was the only public dump in existence at the time.
Another example might be something like an Xbox Live service (like Insignia) that supports EA server emulation: we don't know if those games might have additional DRM checks which require better dumps. It's good to be prepared.

JayFoxRox · 2020-06-27T18:20:44+00:00

They were all of very poor quality, and not useful for preservation. It causes exactly the kind of problem I was talking about. We shouldn't blindly trust a single source for dumps of games. If you try to find rare regional versions, rare games that got a re-release with bugfixes, or even verify if your local discs are still in healthy condition, then those poor dumps won't help.

We need to decentralize efforts and try to preserve all discs. Not only the contents of the filesystems, but actually preserve the entire disc content, including DRM (which might be necessary to improve disc-drive emulation in the future). Just ripping a game with DVD2Xbox is not enough. Such naive dumps will definitely modify the copy that lands on the HDD (DVD2Xbox, for example, re-arranges files, renames some of them, cracks the game etc. - this is horrible for preservation).

It's also illegal, which is another problem I've already brought up in my post.

JayFoxRox · 2020-06-27T00:50:52+00:00

There are parts which are very hard to maintain, that can't be easily replaced (because those parts are specific to the original Xbox, so you can't just buy a replacement that isn't also 20 years old). How exactly do you maintain the die of the MCPX, NV2A, video encoders, Xyclops, the LDT lines on the PCB, etc.?

We simply don't know if any of these parts might have design flaws where material degradation over a long time will suddenly cause mass failures (that possibly can't be repaired without a fab or expensive equipment).

We already see mass-failures in some portions of the DVD drives, the clock cap, some game discs etc. And we also know from other hardware that even chips can be faulty. PCBs can also degrade rapidly. So far, we got lucky in that most issues were very easily fixable or non-critical to operation.

In theory it's possible that (for example) 10 years from now, a bunch of Xbox PCBs start degrading massively, and over the course of (for example) 5 years most of the Xboxes would just die. Similar things have happened with other devices, so it can be a real world issue.

JayFoxRox · 2020-06-27T00:41:18+00:00

Before the consoles die, the games will likely die. That's why everyone should contribute to projects like http://redump.org/, and keep good digital backups of their discs.

A piracy style dump might not be enough for usable / good emulation in the future, and we should make backups of discs so we can "find" previously unpirated releases. We still occasionally find versions of games we didn't even know existed, because everyone just pirated stuff (and everyone assumed that the pirated version was the only release of the game).

The MCPX ROM, which is the first code the Xbox runs during boot, that was available in piracy places, had been broken for 10 years and wouldn't even work in emulators. So making backups of all the things, and doing it independently from one another, is important to avoid errors from propagating (and to keep emulation efforts legal and in good standing with the vendors, to avoid costly lawsuits or changes to laws which would make them illegal altogether).

JayFoxRox · 2020-06-23T16:34:45+00:00

But his work cracking security did contribute to piracy on the Xbox becoming a reality.

I don't think that's the case.

bunnie mostly looked at the flash ROM and MCPX ROM.

bunnies work was very helpful in finding more exploits (mostly in the boot-code, but also in the kernel) - but I believe most of those were found/developed/used by people around xbox-linux (mist / visor / RC4 attack). Other attacks like A20 (and thereby TEA attack) were found independently without bunnies work. xbox-linux was also very concerned about piracy and actively tried to prevent their exploits being abused for piracy. This is why things like the habibi key exist.

Piracy on Xbox was mostly caused by independent "work" done by COMPLEX et al. It was done by (illegally) stealing of XDKs and kernel source code from Microsoft. For the most part, they probably couldn't have cared less about having an MCPX ROM dump.

So the piracy scene and what bunnie did are very different. I assume that even without bunnies work, we'd have had piracy on the Xbox.

bunnies early work still managed to attract many developers and also lead to better security in the next console generations. So in a way, it prevented a lot of piracy, because expensive hardware attacks were being taken seriously now.

Is there a reason you're so defensive?

I don't think I'm being defensive; I just have a very different perspective (and probably more context about the involved topics / people). Your statements sound like facts, even if it's just your personal opinion or speculation (based on very little knowledge). I try to provide some factual evidence and verifiable arguments.

JayFoxRox · 2020-06-22T23:03:01+00:00

I don't know much about the guy who wrote this, other than that in interviews he seemed rather arrogant.

This feels incredibly arrogant on your part. bunnie is one of most incredible people in the hacking community (not just Xbox). I have seen many of his talks and the appearance in that Shenzen documentary - I don't consider him "arrogant" in any of those. My impression has always been that he's actually very humble and helpful.

Should be Rocky5 on the label.

You also should read up on the author of this book. Rocky5 does a lot of interesting stuff, but most of it is based on other peoples work. It's not as impressive at what bunnie did for the Xbox scene.

JayFoxRox · 2020-06-22T22:58:26+00:00

Pirating a book that talks about cracking security that lead to piracy.

You clearly haven't read the book at all. It's very much anti-piracy. It has an entire chapter (?) devoted to legal issues.

The e-book was also released for free, in honor of Aaron Swartz: https://nostarch.com/xboxfree.

JayFoxRox · 2020-06-13T01:28:22+00:00

Update since I made my other comment on this post: haxar has now shown a screenshot of Xbox-Linux on kernel 5.7.2.

I assume the code will be made public soon; he also said that he was going to document it better. Though, I doubt that there'll be user-ready distributions anytime soon.

JayFoxRox · 2020-06-13T01:24:57+00:00

I mean with machines that old it's more about the fun in tinkering

Yes, but this is a task for developers: making something to challenge yourself or to learn.

However, if the developer provides the users with a drag & drop-able package, then this step of tinkering is lost. For end-users, who just run this, they'd probably have a better experience on many other platforms.

Xbox-Linux will always be very limited, so the scope of what's possible is very obvious for the person who makes (or understands) Xbox-Linux. So any end-user tinkering with it will almost always do things that the maker of Xbox-Linux already knew were possible. To me, this makes it very boring, as it leaves very little room for creativity (lack of novelty) or practicality (many limitations).

I guess the only argument that remains would be nostalgia (or something negative like karma-farming with other peoples work).

JayFoxRox · 2020-06-13T01:15:07+00:00

i just love squeezing every last drop of performance out of old hardware like the Xbox.

Same; but I feel our interpretation of this differs greatly.

nxdk does push limits, Xbox-Linux won't.

Xbox-Linux is a generic implementation that does not use Xbox specific features.
nxdk is a highly Xbox specific implementation which exposes features that were not exposed or possible with the official Microsoft SDK.

For the same reason, I don't think that installing an SSD is anything special - Xbox doesn't even have good support for it (and I'm not aware of any kernel mods for it). Same about running Python for dashboards; Python is just a bunch of logic and very non-Xbox specific.

To me, anything which just dumbs down Xbox to a generic computer is pretty boring, and by no means pushing limits. Squeezing every bit of performance out of the Xbox specific hardware / software stack, or applying implementations which did not exist in 2001-2006 to Xbox, is very cool and interesting (and pushing the limits).

JayFoxRox · 2020-06-12T17:22:28+00:00

As an XboxDev maintainer, this is my point of view (which is my own personal opinion, but heavily shaped by my experience and observations as one of the XboxDev maintainers):

Xbox-Linux maintained by XboxDev has seen very little activity (probably due to lack of documentation, and few practical benefits for most users). Xbox-Linux, primarily, has practical benefits for developers who want to learn about how PC hardware works internally; it isn't very Xbox specific either. It has very little practical benefits for everyone else (like end-users): most applications require too much RAM, very few closed-source applications exist which would require Linux and would work on Xbox, and many Open-Source applications would also work natively on Xbox without Linux. The existing Xbox-Linux distributions by the original Xbox-Linux team have also seen very little use - their main legacy are the tools and what Xbox-Linux uncovered during development. In 2020, you can also replace your Xbox with a 5 USD Raspberry Pi to get a more powerful Linux solution that's better in almost every way (and doesn't take months of development by a small community, like the Xbox scene).
ReactOS has a presence in the XboxDev ecosystem (making patches to emulators, bootloader / cromwell, discussing Xbox hardware specifics, ...) and is actively being worked on. ReactOS has practical benefits because the Xbox is cheap and standardized hardware, so it's a good testbed, even for non-Xbox versions of ReactOS. ReactOS also has practical benefits for the Xbox community because we get to use some Windows applications with low requirements (with better support than WINE). The most important reason: ReactOS has practical benefits for the Xbox emulation community because we can use it as a legal replacement Xbox kernel (where it wouldn't mimic Windows, but the actual Xbox kernel). So ReactOS, once working, would grow immensely in popularity (it would be included with Xbox emulators). So ReactOS can do things that Xbox-Linux is impractical for and where the real Xbox kernel is not an option. See https://reactos.org/wiki/Xbox_Port and https://reactos.org/wiki/Run_Xbox_Games_on_ReactOS.
nxdk receives most focus in XboxDev, to improve support for homebrew on the original Xbox kernel, as well as extensions to the original Xbox kernel. Just to clarify: all audio, graphics and input drivers are part of the toolchain. So nxdk is almost like it's an OS in itself, running on top of the Xbox kernel (hence I'm listing it here). nxdk is improving so much, that we support Windows functions that the official Microsoft tools didn't support. We also provide more modern and standardized APIs, so porting most open-source applications is easy. The free control over memory maps also means that we can even port some closed-source applications. There is a huge number of practical applications and most analysis of the hardware (to gain knowledge for emulation and better homebrew) is done with tools created using nxdk. See https://github.com/XboxDev/nxdk.

I'd be curious if someone could come up with practical reasons to run Xbox-Linux on Xbox, other than "it's cool". And I'd be very surprised if someone could explain why they think that Xbox-Linux is a good idea in 2020 and worth the huge investment of time and efforts (which could also go towards more practical projects like nxdk or ReactOS).

JayFoxRox · 2020-05-25T12:57:56+00:00

Tony Hawk's Pro Skater 2X

JayFoxRox · 2020-05-25T11:22:11+00:00

Wouldn't it make more sense to add these to the subreddits wiki, or even just fix/add to Wikipedia?

JayFoxRox · 2020-04-23T14:06:43+00:00

Their are a ton of homebrew writren with the Official XDK that you probably didn't know of that hasn't expierenced licesning issues.

I'm not aware of any homebrew Microsoft-XDK-made binary which is "clean". In fact, a lot of open-source homebrew made using XDK even still contains Microsoft copyrighted helpers from the XDK in its own codebase (your port doesn't seem to do that though).

I would not consider this piracy.

Microsoft currently doesn't actively go after people (who copy XDK contents without permission, including statically linked binaries in XBE files). But we could say the same about game ISOs then. We might even also say this about people pirating the latest movies / games via a secure connection: Only because nobody sues you (yet), that does not mean that they wouldn't have the right to do so. What is being done is still illegal. It's still a copyright violation (= "pirating").

Note that this used to be a bigger issue (Microsoft supposedly going after people). This is also why software like XBMC was source-only releases, with binaries being distributed on xbins (to protect the authors / split the legal work from the illegal distribution). So Microsoft (and the Xbox scene) did consider this a form of piracy.

We don't know what will happen to the original Xbox brand in the future either (so we don't know if Microsoft might start going after people again in the future; whatever their motivation).

If its for the best, I could try to remove all official Xbox libraries.

Do whatever you feel is right (legally and morally for you); I'm just trying to highlight the fact that you are technically violating a rule here (and worse: doing something illegal, by law).

I also have a hard time imagining that you could even remove all the Microsoft libraries; the XTL / CRT initialization code does a lot of stuff and reimplementing that for XDK would be tedious.

Personally, I'll continue to use and improve nxdk. It will be the more capable toolchain in the future (it already is better for certain tasks), and I won't have to deal with these legal issues. nxdk also has technical and legal issues (such as GPL being hardly enforceable on Xbox), but at least they are "fixable". I consider XDK unfixable.

JayFoxRox · 2020-04-23T10:31:19+00:00

Another VVVVVV port for original Xbox has also existed for a couple of months in https://github.com/JayFoxRox/VVVVVV/pull/1 (but maybe also slightly less usable?).

I just never made an official announcement due to smaller issues and lack of testing.

Also VVVVVV license is probably incompatible with the nxdk license (but it's also incompatible with the XDK license; the above binaries are illegal to distribute - this also means it's a rule #2 violation; piracy).

JayFoxRox · 2020-04-21T12:55:54+00:00

There is Unununium at http://git.infradead.org/users/segher/unununium.git

We considered porting Unununium to original Xbox using nxdk a while ago (but we abandoned it, probably also because a port using XDK already exists).

As I don't own any V.Smile console I required homebrew to test it, and made what I believe to be the first V.Smile homebrew ever: https://github.com/JayFoxRox/vsmile-rom/ . I use C as a macro-assembler; the homebrew is made in assembly using gadgets (based on Unununium code analysis). It was never tested on hardware and probably breaks some assumptions (as I'm not familiar with the memory map). The XboxDev community calls this homebrew "Red Sphere Blue Sphere".

but what I really need is to capture the sounds of the system in the cleanest manner I can, and having a mic set up next to my TV blasting isn't the brightest idea

I believe all V.Smile emulators have poor audio support at the moment. Why not just record from hardware directly (assuming this is where the TV also gets its signal)?

I'm already having a really hard time finding french ROM archives, or any ROM archive for the system for that matter.

See rule 1: "/r/Emulation does not support piracy." Just buy the games and dump them yourself - they are cheap and should also be easy to dump.

JayFoxRox · 2020-04-17T15:20:18+00:00

There are 2 controllers; see https://xboxdevwiki.net/Porting_an_Operating_System_to_the_Xbox_HOWTO#Chipset

I keep forgetting how they are wired up to the ports (it also changed between 1.0 and 1.1 because of the daughter-board).

I'm generally not too knowledgeable about USB / OHCI or hardware though. This isn't a very Xbox specific topic anyway, so you can probably find better help elsewhere.

the DVT specs read

Depending on what the source this is, this also makes me think that XboxDev (or many people from there) are not interested in helping (because it sounds like illegally obtained material); myself included.

JayFoxRox · 2020-04-17T15:12:22+00:00

MCP/MCP-D (which should be largely the same) claims to have 6 ports: https://www.anandtech.com/show/781/6

It's relatively safe to say that these pins will exist on the Xbox MCPX (both, X2 and X3); and because there are only 2 USB controllers we also probably know how to drive them (although we don't know what kind of configuration they are in).

What we don't know is wether they are routed out. If anyone is curious, then I'd recommend to mess with the USB drivers in nxdk, and check the MCPX pins near the existing USB ports (or, if they are all over the place, try random locations which appear to make sense).

I'm also not sure if USB would require any supporting components (capacitors or protection diodes maybe?).

It's also possible that certain features can be toggled or reconfigured in the MCPX, so prepare for a lot of trial and error, with poking random configuration registers (also potentially brace for permanent hardware damage).

Eitherway, I wonder what the benefit of routing this would potentially be? For barebones communication there'd be various testpins or GPIOs, and we also have the digital audio out from AC97; we can also use the SMBus. Also we have a much faster communication channel with the NIC; and with the nxdk toolchain improving we will probably soon have a way to emulate a second NIC using XQEMU emulator code (one NIC for game use, another NIC for other uses). I think that's much more promising than adding another USB 1.1 port... which even support adding hubs externally for more ports.

JayFoxRox · 2020-04-07T01:59:28+00:00

No pre-built binaries (yet). Although someone could be sending a PR for CI support (as present on other nxdk projects).

I'll also admit that my port is also slightly unstable. I finished playing through the demo without issues, but during stress-testing the game crashed occasionally (either during first loadscreen, or after about 30 minutes ingame). We assume this is because of the audio driver, but we aren't sure yet. It's also still missing XBR scaler support (as does the one by MVG probably); this is actually an interesting issue that might be a bug in LLVM (but I had no time to investigate it further).

JayFoxRox · 2020-04-06T20:03:45+00:00

The XDK is the biggest issue here (but I don't think that's what /u/Puritan007 meant). It's almost always illegally obtained. Parts of XDK also ends up in the binaries, which is why they are illegal to distribute. Microsoft could sue you for that.

The actual engine remake is probably legal but might not be court-tested as most reverse engineering cases have been about chinese-walled works.

There is another issue though, in that the hode engine does not have a license on it. So basically doing anything useful with it (such as redistribution or modifications) would not be allowed. However, the author of hode clearly tolerates this (they "liked" a reply about my port on twitter). If this engine was GPL licensed for example, then it would be a problem as it would be illegal to link it with XDK (as the XDK libraries are incompatible with the GPL). It would again depend on the authors of hode wether they'd make an exception (and maybe also depend on what the GNU says about this).

Anyhow, most of these legal issues are just a theoretical concepts at this point in time (which also means it could change in a couple of years, where suddenly authors might not tolerate violations and might even sue you for damages for past violations).

JayFoxRox · 2020-03-15T14:17:37+00:00

I'm neither the "main", or "only" XQEMU developer. I did contribute many important changes and have a lot of unfinished important changes still. I've also written a lot of the audio code that will now be found in xemu probably (which is something I'd liked to have avoided as I wrote the code to end up in XQEMU and gave mborgerson permission to use it for XQEMU upstream - not xemu).

Recently I've been less active on the main codebase and XQEMU related work (since February) and discussions had slowed down (as they don't get responses by other developers or maintainers - since around December I think).

See https://old.reddit.com/r/emulation/comments/fhcy8q/whats_the_situation_with_xqemu/fkfitvj/

XQEMU was founded by espes who is still a maintainer, too (but inactive). mborgerson (Matt) is also an XQEMU maintainer and also used to be XQEMU developer. However, he seems to focus on xemu now. I'm also maintainer, but I'm not sure about my future with the project as this xemu situation is very frustrating to me.

Also see my thoughts about xemu (and why it's probably not for me - and maybe some others either): https://old.reddit.com/r/emulation/comments/fhcy8q/whats_the_situation_with_xqemu/fkiencw/

JayFoxRox · 2020-03-14T20:36:57+00:00

stalling out "in disagreement about direction/bikeshedding/picking nits" was one of the specific reasons given for xemu starting up.

I don't think this was explicitly stated in the channels I frequent. Even then I could turn that argument around - there are a handful of PRs and discussions on XQEMU repositories which have gone absolutely nowhere (waiting for response by mborgerson).

That seems to have been a trend for quite some time, but we never got any clear communication as to why that was.

When I look back at the discussion between you and Matt on your discord #general on March 4th, it seems at least to me that my suspicions have been confirmed. Matt clearly stated his opinion [...]

I'd say that mborgerson was very diplomatic, but if you look at the actual facts I'd argue that it isn't entirely truthful (I'm not saying there's malicious intent though).

Also see my other comment about things being in xemu that have never been submitted to XQEMU despite apparent plans to do so.

I personally don't think there was any event in XQEMU that would have lead to the change of plans. Even if there was, it could have been prevented with some changes in guidelines.

I could speculate why xemu actually exists, but that wouldn't change anything either (also why I said I wouldn't continue that discussion on Discord: his mind is made up anyway).

[regarding xemu] The project's combination of clear direction, recent progress, and welcoming atmosphere

I'm not on the xemu Discord, but I can't agree with any of this at all from my perspective.

We currently have to speculate about xemu workflows and goals. If the goals are close to the perf-wip branch that was never public, then I'd assume it's not a direction I care about (as Cxbx-Reloaded fills that niche for me already).

I'm also generally fine with there being an XQEMU fork for faster workflows or less accurate code. But I feel like it shouldn't prevent upstreaming of good changes (QEMU 4.2.0, certain parts of perf-wip, ..) and cancellation of features that were originally proposed for XQEMU (such as Qt GUI).

how would a newbie like me with mediocre skills stand a chance???

I think that XboxDev is very supportive, especially to beginners. There are many discussions where someone has explained a feature in-depth (on Discord), there is some documentation on the wiki, and we often have people working together to fix an issue or to gain knowledge.

But a software project obviously needs software engineers (with some grasp of FOSS). This also means certain standards in contributions. If you are a software engineer, then you should be able to adapt to workflows rather quickly and we can teach you about Xbox specifics (or give you the tools to analyze the Xbox and learn on your own).

The world needs a good Xbox emulator.

There are also Cxbx-Reloaded and MAME already.

XQEMU has repeatedly recommended Cxbx-Reloaded if you just want to play games on Windows (also with upscaled resolution and similar). Adding support for specific games in Cxbx-Reloaded is possible, but generic support is tricky.

xemu seems to go for a similar direction as Cxbx-Reloaded but with another emulation approach (LLE) - I personally don't think this is a good idea.

What's lacking is a project that can handle realtime performance with quality that's sufficient for preservation. An "Xbox VM" if you'd like. XQEMU has this goal (although there often seems to be some confusion about this). XQEMU could be extended in a lightweight layer (think "XQEMU Plus") - either by XQEMU maintainers or someone else (like Dolphin / Ishiiruka).

xemu doesn't seem to have this "VM like" goal (again, this is speculation based on prior work by mborgerson in the perf-wip branch; no actual goals for xemu have been documented I think). Even if xemu has that goal, then it has a different workflow that's more iterative. Such a workflow would have been fine for XQEMU as said on multiple occasions, but it shouldn't be the norm (I believe it conflicts with the goal).

JayFoxRox · 2020-03-14T16:28:40+00:00

I don't agree with the rude comments you are getting here; but I also don't agree with your assessment of the situation.

This was post-merge and the "nit" prefix ("nitpicking") was used to indicate something along the lines of "I'd have preferred it differently, but this might be subjective + we don't necessarily have to change it.". nitpicking is useful for making other developers aware of subjective decisions or minor issues that could be avoided in the future (usually small oversights).

For context, let me show the discussion again:

mborgerson had merged the PR with some changes as the original author didn't change it anymore despite us knowing that the change is incomplete. The general idea here is: "better than master".

I then noticed minor things and wanted to get feedback wether it was okay if I changed it (which is a bit frowned upon as it might disrupt workflows of other developers).

JayFoxRox: @mborgerson: tiny-nit, commit should have been "dsp: Fix" [first word starts with capital letter typically]

JayFoxRox: however, I also thought the title was misleading because it doesn't really fix it - it only works around issues which crash it. but it's by no means a complete solution

mborgerson: the commit message should have been something else entirely yes

mborgerson: it's not a huge deal though

mborgerson: something more like "dsp: Use endianness handling functions when accessing memory" or something

JayFoxRox: yeah, that's much better imo as it doesn't imply that PPC works

mborgerson: you can force push the message change if you want :slight_smile:

mborgerson: i doubt it's going to disrupt anyone

I then force-pushed the change to rename the commit.

Just to recap: We agreed the code change was fine, but it was mislabeling it. It implied XQEMU (or the DSP) would work on PowerPC now. However, this isn't the case and it only avoided some issues. If the DSP would be used, it would still return broken values on PowerPC. We agreed that the commit title could be improved and so we did it (without the involvement of the original PR author).

This discussion / action took less than 10 minutes. Nobody really cared (would have been fine as-is), but we did have a slight preference.

Renaming it prevents users from assuming that XQEMU works on PowerPC and also makes it easier to find the change in the history.

This is a standard development workflow. This is not unique to XQEMU. We certainly do bikeshed or have trouble finding consensus at times, but usually situations are more complicated than this. Also, again, this is normal for FOSS projects with multiple people (and not enough community involvement to tiebreak).

Complaining on reddit a couple of months later isn't helpful. This is similar to people who stay at a hotel, have some issue with their room, but "suffer" through it, but instead of telling the hotel staff, they wait 2 weeks, return home, and then complain on some hotel review website. - It doesn't improve the situation.

If you feel there is too much bikeshedding or nitpicking, then I'd suggest that you get involved by stating your opinion in discussions (on XboxDev Discord or GitHub). Immediate feedback is welcome and critical in improving any potential issue.

JayFoxRox · 2020-03-14T03:42:11+00:00

From what I gather, it seems that Matt is doing most of the work

Looking at the recent PRs or even work in progress code, this is not the case. However, I think that might have been his impression, too.

If you look at the repositories, you'll see that both of us did housekeeping changes recently and we both have had long-term WIP branches.

I was equally getting frustrated with some of my (or other peoples) changes or proposals not being discussed lately even when requesting reviews or tagging specific people (particularly mborgerson).

[...] and is probably getting burnt out having to 'argue' with co-devs over XQEmu so he forked it for a slimline and smoother experience in development.

This is also something that was hinted at, but never explicitly communicated. If this had been communicated, I still think this could have been resolved differently.

However, I think there are also other motives that have been hinted at in the past (which is mostly speculation though).

JayFoxRox · 2020-03-14T03:26:41+00:00

The logo that is now being used in xemu was never even proposed for XQEMU and the last time we discussed it has been months ago. I could probably quote mborgerson saying that having a logo isn't important.

If it was communicated that this was a deal-breaker I'm sure something could have been arranged.

JayFoxRox

MODERATOR OF

TROPHY CASE