I was wondering why Windows is not on more ARM devices since Windows on ARM exists and Windows was ported manually to so many ARM devices now (Raspberry Pi for example). Turns out Qualcomm has an exclusivity deal for Windows on Arm licenses (which might soon expire).

https://www.theverge.com/2021/11/23/22798231/microsoft-qualc...

You might want to check out the Renegade Project: https://github.com/edk2-porting

Does Doom have it's own ISO Committee yet?

Because I swear Does It Run Doom? is becoming a requirement checkbox for any new project.

Be careful. Down this path lies "the ISO is asking us to formally specify the mechanics of DOOM" and then the only resulting end game of that is "we got DOOM running on the ISO committee!"

Naturally I agree with you though. (Because we need DOOM running on more platforms~)

And I'd suggest Bad Apple also needs similar treatment.

If it's capable of representing a two-dimensional array where each element can have at least 2 values, we will get Bad Apple playing on it.

Sound output would be a bonus.

I've seen plenty of videos where people just dubbed the music over it, but yeah, bonus points if you can get it running on whatever beeper you got. The best arrangement I've heard was for the Sound Blaster's OPL3 chip (though a little bit that's cheating since you get 18-note poly and stereo which is enough to create a decent soundscape): https://www.youtube.com/watch?v=2lEPH6Y3Luo

Then you can't implement Doom without paying a few grand for a spec.

There is a popular subreddit for it: https://www.reddit.com/r/itrunsdoom/

Sure, the standard is called ISO 666.

Thanks. Have you written up a long-form post on how you went about doing this?

I am also excited to see what booting multiple OSes means for the ecosystem around phh's (treble) builds, too.

Possibly, I might write a post and/or release tools to do it in the future.

Partly joke, partly true... the question that really matters for every AOSP developer out there: how much time did it take to "make clean/make dist"?

I'm still working with Android 11 and compile times are driving me insane. The ritual to compile, pack and flash super.img into the device is absurd.

Do you know if there is any improvement on that side?

> The ritual to compile, pack and flash super.img into the device is absurd.

I typically only do a full flash for the first build after a sync. Afterwards I just build the pieces I'm changing and use `adb sync` to push them to the device, skipping both the step that packs the image files and the flash. The `sync` target will build just the pieces needed for an `adb sync` if you don't know exactly what you need to build; I typically use it so I don't have to even think about which pieces I'm changing when rebuilding.

So typical flow goes something like:

``` // Rebase is only needed if I have existing local changes > repo sync -j12 && repo rebase

// I don't actually use flashall, we have a tool internally that also handles bootloader upgrades, etc. > m -j && fastboot flashall

// Hack hack hack... then: > m -j sync && syncrestart ```

Where `syncrestart` is an alias for:

``` syncrestart () { adb remount && adb shell stop && sleep 3 && adb sync && adb shell start } ```

Incremental compiles while working on native code are ~10 seconds with this method. Working on framework Java code can be a couple minutes still because of the need to run metalava.

This is really nice tip.

AFAIK, sync works on Linux only since it needs $ANDROID_PRODUCT_OUT. The problem is that I develop on a Windows machine (vscode with ssh extension) and my source code is on remote Linux machines (in premises), dedicated to building AOSP. Since I build at least for another 5 platforms, my working PC cannot cope with the current (and future) workload/space, so I asked to move all the source to dedicated hardware for building. Perhaps I can do it with ADB through Wifi...

I always thought sync worked with frameworks or packages, but since you mentioned "native" I guess it will also sync vendor stuff?

New versions of Android aren't open-source until their stable release, so I don't know. I've been running these VMs on the stock ROM.

I don't feel like incremental AOSP builds are that slow, and I don't think it's changed much from Android 11 to 12. It's highly dependent on good hardware though, and it probably also helps that I flash individual partition images instead of building dist or target-files.

Now that Windows 11 has 32- and 64-bit x86 emulation this has the potential to do some interesting things in the long tail of the market.

I honestly wonder if there's a monetary opportunity here?

(This used to read a little differently (https://i.imgur.com/yp95XxR.png - thought it would be funny) but it quickly became apparent some editing was in order. This comment will likely remain stuck at the bottom of this subthread... woops.)

Unexpected update: the parent comment has been downvoted further since being edited. I am officially lost.