bbbbbr · HackerTrans

2 miesiące temudiscuss

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

bbbbbr

3 miesiące temudiscuss

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

bbbbbr

3 miesiące temudiscuss

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

bbbbbr

8 miesięcy temudiscuss

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

bbbbbr

8 miesięcy temudiscuss

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.

bbbbbr

8 miesięcy temudiscuss

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.

bbbbbr

3 lata temudiscuss

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.

https://www.reddit.com/r/Gameboy/comments/w0wrt5/no_this_isn...

bbbbbr

3 lata temudiscuss

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

bbbbbr

3 lata temudiscuss

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.

bbbbbr

4 lata temudiscuss

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

bbbbbr

4 lata temudiscuss

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

bbbbbr

4 lata temudiscuss

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.

bbbbbr

4 lata temudiscuss

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.

bbbbbr

4 lata temudiscuss

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

bbbbbr

4 lata temudiscuss

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.

bbbbbr

5 lat temudiscuss

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

bbbbbr

5 lat temudiscuss

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

bbbbbr

5 lat temudiscuss

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

bbbbbr

5 lat temudiscuss

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.

bbbbbr

5 lat temudiscuss

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