bbbbbr

It's after the fact now, but I maintain a list of 32K Game Boy games on itch.io here: https://itch.io/c/3521183/game-boy-32k-roms

Great project btw

That CPU halting only applies for PGB mode 1.

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

I don't think it's widely known (only found and documented somewhat recently) that there is a way for cartridges to directly drive the Game Boy Color LCD, bypassing the CPU/PPU (PGB Modes). At that point though it becomes even less of a Game Boy game than what the Wolfenstein and other carts are doing.

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

Not the parent, but I have a take. :)

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

With regard to code size in this comparison someone associated with llvm-mos remarked that some factors are: their libc is written in C and tries to be multi-platform friendly, stdio takes up space, the division functions are large, and their float support is not asm optimized.

There is a similar project for the Game Boy (sm83 cpu) with a fork of LLVM.

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.

There is a variation on the new-pcb and components approach called the "Ultra Boy Colour" which doesn't require any parts from an OEM Game Boy Color.

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.

GBStudio does use cart ROM banking (for code and assets), but extensible cart RAM (SRAM) is typically only used for save data if I remember correctly.

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

Garmin watches work well with the desktop sports tracking program MyTourBook.

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.

This is correct. A phone number is NOT required to enable 2FA, at least in my experience within the last few months.

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

There is also a NES port in the works: https://twitter.com/FG_Software/status/1495400042722897925

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 linked GBC version is my fork with some improvements (and more in the works).

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.

Plenty of games are being written in C for the Game Boy on a regular basis.

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.

RGBDS-live may be just what you had in mind. I can't remember exactly, but there may have been some experiments with a SDCC based C version of that as well. https://daid.github.io/rgbds-live/

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

Great recommendations.

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.

Here's a guide which helps select tools for Game Boy homebrew development based on skill, experience and project scope:

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

Here's a bunch, a mix of ASM, GBStudio, GBDK and ZGB

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

The GB emulators most commonly for homebrew development are the following. They all have debuggers and a high level of accuracy. Emulicious has C source debugging when using VSCode (or Sublime Text, though that's not yet released.)

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

* Emulicious - https://emulicious.net

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

Thanks for the reply. It'll be interesting to follow the progress.

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.

Are you participating in the re-launch of development for Infinity? (great to see it happening)

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

How about using (experimental) Go on the Game Boy :)

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

Aside from some a couple performance critical parts of code or if you're trying to push the hardware to it's maximum limits with effects or complex mechanics, C is totally sufficient for writing entire (and performant) games on the Game Boy. Many polished homebrew GB games have been (and are being) written and completed using C.

Of course, now the number of games now being made with GB Studio completely eclipses the number written in C and assembly.

Most of the GBDK/GBDK-2020 API used for C development is written in assembly, so if you use C you get some benefits of using assembly anyway.

Here's a more nuanced guide for choosing which development tools to use. https://gbdev.io/to_c_or_not_to_c.html

And a couple recent-ish examples of polished games:

GB Studio:

https://lumpytouch.itch.io/super-impostor-bros

C/GBDK:

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

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

https://tangramgames.itch.io/tobu-tobu-girl-deluxe

C/GBDK + ZGB:

https://aiguanachein.itch.io/powa

(edit: line breaks)

GBDK went mostly unmaintained for around ~20 years, and so it stagnated a bit. It has recently been upgraded to a modern version of the SDCC compiler with better optimization, and has seen bug fixes and a bunch of other improvements.

https://github.com/gbdk-2020/gbdk-2020

Also handy for smooth palette fades using only integers.

It makes it easy to do linear interpolation (lerp) between two RGB colors (or in another color space if you want better color consistency during transition). The transition between each component gets be spaced out over a constant duration regardless of how little integer difference there actually is.

I used this approach to add a color fade transition effect for a Game Boy color puzzle game (made using GBDK). GIF of the effect here: https://twitter.com/0xbbbbbr/status/1350982144450027525

Yes, this ^^^

While posting new builds in a not easily discoverable location is technically compatible with the statement of:

For license holders, we've actually been shipping new dev builds every one to two weeks.

In practice the result is that (by stated design) the majority of sublime text license holders will not be aware of new builds for several years at a time until they are announced in the easily discoverable public location again.

I think it's good for them to pursue whatever development and community engagement model feels most sustainable, but it is disingenuous to claim that both users have access to the current dev builds while also trying to hide those builds from most users.

(edit: grammar)

I hadn't heard of this carrier before and it made me curious what the rest of their privacy was like, and whether this part of a overall policy. I didn't see explicit mention of opting out of the systems you mentioned. Is that stated anywhere officially, or is it just unofficial?

Their privacy stance overall looks just ok, maybe somewhat above average.

It does make me wonder how strong of a privacy stance Purism will take, or will be able to take as a service provider.

Some emphasis added, and some info trimmed (noted with ellipses ...)

https://www.visible.com/legal/privacy/

... I. COLLECTION OF INFORMATION We collect information when you use our service. This includes information about the calls you make and receive, text messages you send and receive, ___websites you visit, mobile applications you use___, and wireless network and device information, including location, Internet protocol (IP) address and connection speed, mobile telephone number, ___device and advertising identifiers___, browser type, and operating system. Some Visible devices include Verizon-provided system applications that collect information about network and device conditions, which is used to secure and improve our network and services. ...

II. USE OF INFORMATION

... * Determine products and services that may interest you and market them to you, including on Visible sites and apps and on others’ sites, services, apps and devices as described in Section V below ...

III. DISCLOSURE OF INFORMATION

* Authorized service providers and partners. We share your information with service providers and partners that help us with a variety of things, including development and delivery of our sites, apps and service. ... ... * Aggregated and De-identified Information. We may aggregate or otherwise de-identify information and use it for our own purposes or share it with third parties for their own purposes. ...

... Your Right to Say “Do Not Sell”

The CCPA gives you the right to say no to the sale of personal information.

We do not sell information that personally identifies you such as your name, telephone number, mailing address or email address.. We allow Verizon Media and third-party advertising companies to collect information about your activity on our website and in our app, for example through cookies and similar technologies, mobile ad identifiers, pixels, web beacons and social network plugins. These ad entities use information they collect to help us provide more relevant Visible advertisements and for other advertising purposes. This activity may be considered a sale under the CCPA. Visit the Digital Advertising Alliance's Consumer Choices page to learn more about how you can limit this type of advertising. App users can opt out by using your device settings to “Limit Ad Tracking” (for iOS devices) or “Opt out of Ads Personalization” (on Android devices) ...

(edit: formatting)

While not official, there is a script posted to the Garmin forums which allows for bulk download/export of FIT/TCX/etc data.

https://forums.garmin.com/apps-software/mobile-apps-web/f/ga...

Here's a version I've improved a little + adding export of "wellness" data. This thread was a good reminder to push my changes out to github. https://github.com/bbbbbr/garmin-connect-bulk-export

Edit, add:

Lastly, while the UI has some quirks and it doesn't have a social component, My Tourbook is a solid offline, cross-platform alternative to the online fitness repositories. There is something to be said for having complete control over your data (make sure to do backups). http://mytourbook.sourceforge.net/mytourbook/

That bugged me enough the first time it happened that I immediately stopped what I was doing and worked on disabling it.

If you use greasemonkey/tampermonkey then the script below will disable the post-episode playback (along with a couple other UI changes)

https://github.com/bbbbbr/netflix-disable-auto-play-and-more

I wrote a greasemonkey/tampermonkey script to do this.

And to disable auto-play of next episodes (now happily obsolete, perhaps) and "promoted post-play preview content".

There is no UI so you'd have to toggle the script on/off if you wanted to resume watching intros and recaps.

https://github.com/bbbbbr/netflix-disable-auto-play-and-more