In PGB mode 2 the CPU is still able to run (within a limited address range) and can use register FF75 "PGBIO" for limited input and output on some cartridge pins (and/or the link port for IO).

https://gbdev.gg8.se/wiki/articles/Gameboy_and_Gameboy_Color...

Also related: "There oughta be GTA5 for the Game Boy" about a Wifi cartridge that can stream video (gameplay, etc) directly to the GB screen. https://there.oughta.be/gta5-for-the-game-boy

For GBDK-2020 we've been using the 6502 support in SDCC to support the NES as a target console for about 2 years alongside the existing Game Boy and SMS/Game Gear targets.

The 6502 port has been usable, but doesn't seem fully mature. There has been a lot of code churn for it during the last 12 months compared to the z80/sm83 ports as it gets improved. Recently (their recommended pre-release build 15614) this seems to have resulted in some breaking regressions that we haven't fully tracked down.

Perhaps this port is getting less testing coverage than the z80/sm83 port. Unsure. The majority of the 6502 work seems to be done by a newer member of their team, with the longer term members seeming to be somewhat hands-off. That might be an additional factor.

Edit: BTW, the 6502 port in SDCC at build 15267 (~4.5.0+) has been reasonably stable and usable, and is what we based our last GBDK-2020 release on (6 months ago).

https://github.com/DaveDuck321/gb-llvm

https://github.com/DaveDuck321/libgbxx

It seems to be first reasonably successful attempt (can actually be used) among a handful of previous abandoned llvm Game Boy attempts.

It can use a clone CPU that was manufactured (until recently?) for the "GBBoy Colour" (and could also be pulled from the sort of failed SGB-like clone called the "Extension Converter for GB").

  > I redesigned the Gameboy Color from the ground up 
  > based on the premise that it wouldn't require any 
  > components to be harvested from a real GBC, so it 
  > would be compatible with both the original GBC and 
  > clone hardware taken from a GB Boy Colour- since 
  > the KF2007 clone CPU from the GBBC is practically 
  > a drop-in replacement for the CGB CPU found in a
  > real GBC- no software compatibility issues at all.

In general for Game Boy games the constraining factors are most often CPU and ROM (for large worlds and lots of graphics) and less so RAM.

Some of GBStudio's core is in C and some is in asm. The underlying compiler (SDCC) has been making noticeable gains in recent years, which helps. Plenty of room for SDCC to improve still, but very usable for projects.

FWIW, There is a large Game Boy homebrew competition put on by the community that just started this past week and runs for 3 months. (disclaimer: I'm one of the organizers)

Many participants (of all skill levels) will submit games written in GBStudio, and some will also write games in ASM and C.

https://gbdev.io/gbcompo23.html

https://itch.io/jam/gbcompo23

I've never had to activate a Garmin watch or register it online in order to use it. Not connecting it to Garmin Services and apps may limit access to 3rd party apps, or at least make it harder to load them load though. (I haven't researched side loading since base features are fine for me).

MyTourBook supports FIT/GPX/TCX/etc, has maps, calendars, charts and activity classification. It's built with Java so can run at least on Windows and Linux. There may be other good programs now, but as of a couple years ago it appeared to be among the better options.

It's open source (and they were supportive of PRs for improving Garmin import).

https://mytourbook.sourceforge.io/mytourbook/index.php

Edit: It's also not limited to Garmin devices. There is support for formats from Suunto, Polar and some other companies. https://mytourbook.sourceforge.io/mytourbook/index.php/docum...

Edit 2: This is with syncing over USB btw.

I set up 2FA to use Yubikey hardware keys for a google account, and was then allowed to generated app passwords. No phone number has ever been attached to the account.

I do agree that not allowing app-passwords to be generated without setting up 2FA is coercive and seems hard to justify, and it is plausible that it is being used to push people into attaching their phone numbers to their accounts. If I recall right, the current language for the setup process skews heavily toward phone numbers and does not do a good job of highlighting other (more privacy oriented) alternatives (as may be evidenced at least in the case of OP).

And a C64 port: https://twitter.com/roysterini/status/1493540659352985602

A brief quote about compression in the NES port:

https://twitter.com/FG_Software/status/1491044035884371971 "Official #Wordle dictionary implemented, and the game can now select a solution from all those found in the original for the cost of 1 extra bit per word! Uncompressed size (Raw text files): 76060 bytes Compressed size: 26256 bytes"

https://twitter.com/FG_Software/status/1495298243668099073 "Words are stored in 2 bytes: 15 bits data, 1 bit to check if it's a solution. They're all sorted alphabetically, so I can algorithmically determine the first 2 letters with a lookup table, and stick the last 3 letters in 15 bits. Bit more to it but you can't fit it all in a Tweet"

I've been working on a Game Boy Color (and regular GB) fork that in current builds uses the compression by arpruss. https://github.com/bbbbbr/gb-wordle

The current published release uses a similar compression approach by zeta_two, but in current builds I've switched to the compression by arpruss since total data + decompression code size is now a couple hundred bytes smaller.

I did some profiling and code size measurements before switching over. https://github.com/bbbbbr/gb-wordle/blob/compress_arpruss/wo...

Speed (and code size somewhat) have improved more since then.

Just a few polished examples of that: https://tangramgames.itch.io/tobu-tobu-girl-deluxe

https://user0x7f.itch.io/black-castle

https://binji.itch.io/porklikegb

https://pocketpixel.design/super-jetpak-dx-game-boy-rom.html

https://aiguanachein.itch.io/powa

https://thegreatgallus.itch.io/cavern-mvm-9

https://user0x7f.itch.io/gunship

https://www.infinitygbc.com/

ASM will tend to be more efficient, especially if written by someone with experience and skill, but that isn't enough to prevent other tools from being used successfully. It's described in much more detail in the linked article.

Source: https://github.com/daid/rgbds-live

There was also a precursor to GB Studio which seemed headed in that direction. It was written by the same person who did GBStudio: https://www.chrismaltby.com/projects/gbdkjs

In order to filter out "Game Boy-like" material on itch.io, you can also use the tag "gamboy-rom". Then it should only show you entries that will run on actual hardware (such as a flash cart or in an emulator):

https://itch.io/games/tag-gameboy-rom

As for advice on starting: a great thing to do is figure out a simple, small project to start with, and dive in. That will help give you concrete tasks to focus your learning of the hardware and dev tools around, and keeping the scope modest will prevent it from being overwhelming. There are a handful of tutorials if you want to try that route, and plenty of support (forums & discord).

Agreed too, Game Boy development has been exploding in the last couple years. GBStudio's arrival really brought making GB games within reach of a much larger pool of people. The ability to make them was no longer limited only those able to write software (or those working with them). This brought in a TON of graphics, music, storytelling and creative talent.

https://gbdev.io/guides/tools.html

There was a big Game Boy homebrew jam / compo in 2021 with more than a 100 entries. A bunch of them are well polished and have solid gameplay :

https://itch.io/jam/gbcompo21/entries

https://gbdev.io/gbcompo21.html

A lot can be found on itch.io using the "gameboy-rom" tag: https://itch.io/games/tag-gameboy-rom

GBStudio has really changed the landscape and brought a lot of people into homebrew development who might otherwise have not joined for lack of programming and tooling experience. In addition to that, there are also a good number of non-GBStudio releases happening (ASM, GBDK-2020, ZGB engine).

Deadeus: Pretty much a new-classic homebrew: https://izma.itch.io/deadeus

Soul Void: Great graphics, gothic: https://kadabura.itch.io/soul-void

Genesis: Decent shmup: https://user0x7f.itch.io/genesis

Among Us fangame: https://lumpytouch.itch.io/super-impostor-bros

Black Castle: A solid Platformer: https://user0x7f.itch.io/black-castle

Cavern: has some metroid feels: https://thegreatgallus.itch.io/cavern-mvm-9

Powa: Platformer: https://aiguanachein.itch.io/powa

The Bouncing Ball: Simple yet fun: https://gamejolt.com/games/the-bouncing-ball-gb/86699

Dangan: Bullet hell on the GB: https://snorpung.itch.io/dangan-gb

Quartet: Puzzle game: https://makrill.itch.io/quartet

Death Planet: Impressive GB graphics, great music: https://makrill.itch.io/death-planet

* BGB - http://bgb.bircd.org

* Emulicious - https://emulicious.net

* SameBoy - https://sameboy.github.io

Can definitely see wanting to keep the compiler and code in a known state. Though modern SDCC generates code that's probably 50% faster in some cases and with 90% less bugs than versions from the early 2000s.

Lots of great Game Boy releases have been coming out.

Edit: add a little more.

If so, what approach are you taking for the toolchain? Keeping the existing version that had been used/modified? Updating to newer tools (and code changes that may go along with that)?

https://github.com/pokemium/gbdk-go