bbbbbr
Joined 6 years ago
Karma
73
Submissions
31
Member since
Feb 7
Recent submissions
Comment · 5 months ago
Comment · 6 months ago
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).
Comment · 6 months ago
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
Comment · 11 months ago
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).
Comment · 11 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.
Comment · 11 months ago
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.
Comment · 2 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 4 years ago
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).
Comment · 4 years ago
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
Comment · 4 years ago
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.
Comment · 4 years ago
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
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.
Comment · 4 years ago
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
Comment · 4 years ago
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.
Great project btw