mmitch / gbsplay Goto Github PK

I cant find any instructions on how to build, and not knowing much about C, ive tried using cygwin make, mingw make and all sorts of things i'm probably doing wrong. I keep getting gbs.c:328:1: internal compiler error: in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 errors with cygwin make. Is there instructions to build on Windows, or am i missing something>?

The travis.yml file currently contains part of a code coverage tool at the end:

after_success:
  - bash <(curl -s https://codecov.io/bash)

This code snippet would upload the coverage results to codecov.io, but we don't create any coverage data during our test run.
The build log looks like this in the final step:

$ bash <(curl -s https://codecov.io/bash)

  _____          _
 / ____|        | |
| |     ___   __| | ___  ___ _____   __
| |    / _ \ / _` |/ _ \/ __/ _ \ \ / /
| |___| (_) | (_| |  __/ (_| (_) \ V /
 \_____\___/ \__,_|\___|\___\___/ \_/
                              Bash-20200629-ffaf297


==> Travis CI detected.
    project root: .
    Yaml not found, that's ok! Learn more at http://docs.codecov.io/docs/codecov-yaml
==> Running gcov in . (disable via -X gcov)
==> Python coveragepy not found
==> Searching for coverage reports in:
    + .
--> No coverage report found.
    Please visit http://docs.codecov.io/docs/supported-languages

Done. Your build exited with 0.

We should either generate coverage data and see what else is missing for codecov.io upload
or remove the after_success block altogether.

(also: piping curl to bash - yuck ;-)

What do we want configure to do, when somebody says --enable-this and libthis.h is not available?

With the new dsound plugin, configure says it can't find the include but does honor --enable-dsound and enables it in the config. This later fails during the build:

$ ./configure --enable-dsound
[…]
checking for alsa/asoundlib.h:  ok
checking for dsound.h:  not found
checking for dsound.h in /usr/local/include:  not found
checking for pulse/simple.h:  ok
[…]
optional modules: +contrib +test -xmmsplugin
optional features: +i18n -sharedlibgbs -regparm +ssp -debug +stdout +devdsp +alsa +nas +pulse +midi +dsound
EXTRA_CFLAGS=-Wdeclaration-after-statement -fstack-protector --param=ssp-buffer-size=4 -Os -pipe -fomit-frame-pointer
EXTRA_LDFLAGS=-fstack-protector

$ make
DEP gbsinfo.c -o gbsinfo.d
DEP plugout_dsound.c -o plugout_dsound.d
plugout_dsound.c:12:22: fatal error: initguid.h: No such file or directory
 #include <initguid.h>
                      ^
compilation terminated.

We could debate whether failing the build is okay or the configure script should already fail, but at least this is consistent: Telling configure to add something that is not there will fail.

The pulse plugout (and propably alsa, too) behaves differently: When the headers are missing and --enable-pulse is given, configure silently decided to go with --disable-pulse – despite being told the opposite:

$ ./configure --enable-pulse
[…]
checking for dsound.h in /usr/local/include:  not found
checking for pulse/simple.h:  not found
checking for pulse/simple.h in /usr/local/include:  not found
checking for audio/audiolib.h:  ok
[…]
optional modules: +contrib +test -xmmsplugin
optional features: +i18n -sharedlibgbs -regparm +ssp -debug +stdout +devdsp +alsa +nas -pulse +midi
EXTRA_CFLAGS=-Wdeclaration-after-statement -fstack-protector --param=ssp-buffer-size=4 -Os -pipe -fomit-frame-pointer
EXTRA_LDFLAGS=-fstack-protector

I consider this a bug.

In the gbsplay Debian package, I have --enabled all plugouts and wanted the configure script to tell me "hey, you're missing a build dependency" during a package build in a clean environment – but instead configure disabled everything that should have been enabled and carried on - without most of the plugins.

This seems to happen since commit 57d2f97:

commit 57d2f97b569c540153d0a144328daf1b91237357
Author: Christian Garbs <[email protected]>
Date:   Mon Dec 21 14:34:50 2020 +0100

    refactor: update subsong related status only on subsong change

 gbs.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

When using for instance

gbsplay DMG-TRA-0.gbs 4 4

gbsplay still plays song number 1

Thank you

When using the iodumper plugin on the following file, I get some strange register writes:

For instance:

0000d240 ffd0=01
00000100 ffd0=02
00000198 ffd0=03
000001b8 ffd0=04
00000138 ffd1=0a
000001b4 ffd5=02
00000074 ffdf=00
0000f850 ffd0=01

DMG-MLA.gbs.zip

is it expected to write to invalid registers or to registers not related to sound?

In this file, when playing track 1 in loop for 3 minutes, there are 14887 useful register writes, and 79897 invalid ones.

I wonder if gbsplay should filter them out.

Thanks

Trying to build fails on Fedora 23 x64 :

[sheepdestroyer@sheepora gbsplay] $ ./configure 
checking for working compiler:  ok
checking if OS is Cygwin:  no
checking for inttypes.h:  ok
checking for sys/soundcard.h:  ok
checking for alsa/asoundlib.h:  ok
checking for ESTRPIPE support:  ok
checking for pulse/simple.h:  ok
checking for audio/audiolib.h:  not found
checking for audio/audiolib.h in /usr/X11R6/include:  not found
checking for audio/audiolib.h in /usr/local/include:  not found
checking for audio/audiolib.h in /opt/local/include:  not found
checking for locale.h:  ok
checking for libintl.h:  ok
checking for gettext tools:  ok
checking if we need additional libs for i18n:  no
checking if cc supports -Wdeclaration-after-statement:  yes
checking if cc supports -Wl,-z,relro:  yes
checking if cc supports -Wl,-z,now:  yes
checking if cc supports -Wl,-pie:  no
checking if cc supports -pie:  yes
checking if cc supports -fstack-protector-strong:  yes
checking for regparm support:  ok
optional modules: +contrib +test -xmmsplugin
optional features: +alsa -debug +devdsp +hardening +i18n +iodumper +midi -nas +pulse +regparm -sharedlibgbs +stdout
EXTRA_CFLAGS=-Wdeclaration-after-statement -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wall -fsigned-char -Os -pipe -fomit-frame-pointer
EXTRA_LDFLAGS=-Wl,-z,relro -Wl,-z,now -pie -fstack-protector-strong

[sheepdestroyer@sheepora gbsplay] $ make -j 4
DEP plugout_midi.c -o plugout_midi.d
DEP gbsinfo.c -o gbsinfo.d
DEP plugout_pulse.c -o plugout_pulse.d
DEP plugout_iodumper.c -o plugout_iodumper.d
DEP plugout_stdout.c -o plugout_stdout.d
DEP plugout_alsa.c -o plugout_alsa.d
DEP plugout.c -o plugout.d
DEP plugout_devdsp.c -o plugout_devdsp.d
DEP util.c -o util.d
DEP gbsplay.c -o gbsplay.d
DEP crc32.c -o crc32.d
DEP cfgparser.c -o cfgparser.d
DEP gbs.c -o gbs.d
DEP gbhw.c -o gbhw.d
DEP gbcpu.c -o gbcpu.d
gbhw.c:18:21: fatal error: impulse.h: No such file or directory
compilation terminated.
CC gbcpu.c -o gbcpu.o
HOSTCC gen_impulse_h.c -o gen_impulse_h.ho
HOSTCC impulsegen.c -o impulsegen.ho
CC gbs.c -o gbs.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC cfgparser.c -o cfgparser.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC crc32.c -o crc32.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC gbsplay.c -o gbsplay.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC util.c -o util.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout.c -o plugout.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_devdsp.c -o plugout_devdsp.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_alsa.c -o plugout_alsa.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_stdout.c -o plugout_stdout.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_midi.c -o plugout_midi.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_pulse.c -o plugout_pulse.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
CC plugout_iodumper.c -o plugout_iodumper.o
CC gbsinfo.c -o gbsinfo.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
msgfmt -o po/en.mo po/en.po
msgfmt -o po/de.mo po/de.po
sed -f config.sed gbsplay.in.1 > gbsplay.1
sed -f config.sed gbsinfo.in.1 > gbsinfo.1
sed -f config.sed gbsplayrc.in.5 > gbsplayrc.5
TEST util.c TEST impulsegen.c CC test_gbs.c -o test_gbs.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
gcc -o gen_impulse_h gen_impulse_h.ho impulsegen.ho -lm
CC gbhw.c -o gbhw.o
which: no splint in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/sheepdestroyer/.local/bin:/home/sheepdestroyer/bin)
make: execvp: ./test: Text file busy
Makefile:416: recipe for target 'util.test' failed
make: *** [util.test] Error 127
make: *** Waiting for unfinished jobs....
 1 tests:
    test_gen_impulsetab: ok

plugout_io_fn prototype should be something like:
typedef int (*plugout_io_fn )(unsigned long cycles, uint32_t addr, uint8_t val);

also previous value:
static unsigned long cycles_prev = 0;

also gbhw.sum_cycles

or even better make it all 64bit.

Our automated builds using GitHub Actions ensure that gbsplay compiles on macOS:
https://github.com/mmitch/gbsplay/actions?query=workflow%3A%22macOS+Build%22

configure currently only detects these plugouts on macOS that don't actually play any sound:

• iodumper
• midi
• altmidi
• stdout

While gbsplay compiles, not having a useful sound output won't make it very useful.

We need somebody with knowledge of macOS and sound drivers that can tell us what to do:

• Are things like ALSA or PulseAudio available on macOS (natively or via brew etc.)? Would it be reasonable to expect the user to have one of our supported sound libraries installed?
• Do we need a new sound driver for macOS like the dsound driver for Windows? It would be nice if anybody could write the driver, but we'd need at least somebody with access to macOS hardware to test it if we were to write blindly implement such a driver.

preferrably optional; with ffmpeg support or something. Currently the only way to dump to file is something like this:
gbsplay -o stdout -E l -r 48000 in.gbs | ffmpeg -ac 2 -f s16le -ar 48000 -i - -c:a pcm_s16le out.wav

But it's kind of a hassle & it'd be much more convenient to just do something like this:
gbsplay -o ffmpeg in.gbs out.wav

The Code Coverage build workflow needs some extra flags to enable code coverage statistics.
These flags don't work with the generation of impulse.h (LDFLAGS seems to be ignored), so the workflow currently adopts a two-step build:

1. impulse.h is generated with default flags, thus impulsegen.c is not considered covered code
2. the remaining build is run again, this time with coverage enabled

Can we make this work in a single pass without changing the build flags in the middle?

I just stumbled over this - happens with current git master 0.0.94-123-g549023c:

When I run gbsplay in an Xterm under Linux and press space for pause, the cursor is flashing because it is redrawn in a tight loop. Fortunately, CPU usage does not reach 100%:

mitch@derpy:/tmp/gbsplay (master u=) $ ./gbsplay examples/nightmode.gbs 
GBSVersion:       1
Title:            "Nightmode"
Author:           "Laxity"
Copyright:        ""
Load address:     0x3000
Init address:     0x3800
Play address:     0x3290
Stack pointer:    0xfff4
File size:        0x00004600
ROM size:         0x00008000 (2 banks)
Subsongs:         1
Default subsong:  1
Timing:           59.7Hz VBlank

CRC32:            0xc2809587

commands:  [p]revious subsong   [n]ext subsong   [q]uit player
           [ ] pause/resume   [1-4] mute channel

Song   1/  1 (Untitled)
00:02/02:00  D-1 %%%#  ---       D-3 %%%   ---       [   #|#   ]

After some time (give it up to 10 seconds; seems to depend on the exact moment you pause), the screen gets garbled like this with the cursor running upwards:

mitch@derpy:/tmp/gbsplay (master u=) $ ./gbsplay examples/nightmode.gbs 
GBSVersion:       1
Title:            "Nightmode"
Author:           "Laxity"
Copyright:        ""
Load address:     0x3000
Init address:     0x3800
Play address:     0x3290
Song   1/  1 (Untitled)
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]
00:01/02:00  D-1 %     ---       D-3 %     ---       [ -%%|%%- ]

When trying to play or dump the registers of this .gbs file, I get this error after 4 seconds:

Unknown opcode d3.

I used this command:

gbsplay -o iodumper "Paragon 5 Music Album (2002)(Paragon 5).gbs"  11 11

Here is the file:

Paragon 5 Music Album (2002)(Paragon 5).gbs.zip

Thank you
Eric

If I have bisected correctly then with commit d141649 some files (eg. sml2.gbs and sml3.gbs) have stopped playing.
Every subsong plays only silence which in the default configuration means to skip to the next, also all silent subsong after 2 seconds.

@ranma any ideas about unwanted side-effects of the MBC1 mapping?

Using version 0.0.93-102-g33c5d71, the arguments specified in the help don't mute channels on startup. Muting channels manually still works, it's just the arguments that don't.

gbsplay -1 Jimmy\ White\'s\ Cueball.gbs

README has been renamed to README.md

I'd like to discuss a new idea I had which doesn't work as an issue

There are some files from the source tree that are not included in the tarball:

• BUGTRACKING - propably OK, because we don't use ditz any more. The file (along with the bugs subdirectory) should be deleted and the open issues should be imported to the git issue tracker. I'd volunteer to do that when I have some time.
• TESTSUITE - include it?
• gbsformat.txt - include it?
• libgbs.def - was checked in regarding Cygwin DLL build. Is this a build result that we forgot to make distclean or should this be in the tarball as well as it's needed for a Windows build?
• .gitgnore - include it?

when i try to run this command
run ~/Téléchargements//Smurfs.gbs -2 -3 -4 -o midi

it segfaults with the followin trace
(I obtain this with help. I'm a GB sound fan, but not a good linux user)
#0 __GI__IO_fwrite (buf=0x7fffffffdbf7, size=1, count=1, fp=0x0) at iofwrite.c:41
#1 0x000055555555d36a in midi_write_event.constprop ()
#2 0x000055555555d73a in midi_io ()
#3 0x000055555555d9df in io_put ()
#4 0x000055555555e522 in gbhw_init ()
#5 0x000055555555ef5a in gbs_init ()
#6 0x000055555555ba4d in main ()

I have a ROM which does kind of vibrato effect. It slightly changes the pitch. In the MIDI output, this is converted to separate notes, which sounds wrong. Is there some way to do rounding in the frequency->note conversion, so that it is still detected as the same note?

ROM: Wizards & Warriors Chapter X - The Fortress of Fear (E) [!].gb

Excerpt from the iodump:
0000002c ff13=4e
00000044 ff14=87
0000f10c ff13=4d
00000044 ff14=07
000116c0 ff13=4e
00000044 ff14=07
000116c0 ff13=4d
00000044 ff14=07

This is how it sounds on the Gameboy: https://soundcloud.com/idax303/gameboy-fortress-of-fear
And here you can find the MIDI file produced by gbsplay: https://www.dropbox.com/s/zx9xtaxlqi6htmy/gbsplay-1.mid?dl=0

Do you have an idea why this happens? https://buildd.debian.org/status/package.php?p=gbsplay

yeah well the title says it all.

Tested under MSYS2 (Windows).

When running the program, the first 1-2 seconds of the song start playing, after which the program starts "fast-forwarding". Then starts to play the next subsong. This continues until all subsongs are played.

since gbsplay already has silence detection via the silence-timeout option, i am hoping it would not be difficult to add an option to trim silence from the beginning of a subsong. this would be of great help when using the subsong-timeout option. right now i have to use -o stdout and pipe through sox's play command to trim the silence from the beginning of each subsong.

parseopts() in gbsplay.c sets myname = *argv[0]; and uses the variable later for the binary name in the help text shown by usage().
In the xgbsplay branch, myname will also be used for the version() output (-V parameter).

If you run gbsplay from your local build directory, myname will contain the directory and print it. This does not look very good:

$ ./gbsplay -V
./gbsplay 0.0.94-18-gfece946

$ $ ./gbsplay -h
Usage: ./gbsplay [option(s)] <gbs-file> [start_at_subsong [stop_at_subsong] ]

Available options are:
[…]

Use something like basedir() to remove the path from myname or just advance the pointer behind the last slash in argv[0] so no additional target buffer is needed.

any news on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977943 ?

The default subsong from GBS file is correctly read by gbsplay as it is shown in the gbs info output.
But the playback starts with track 1 regardless of the default subsong set in the GBS file.

Should pause handling be delegated to the player code and be removed from gbs.c and gbhw.c?

If a player plays multiple GBS files in parallel (which will be possible with issue #41) and pauses one of then, then the paused gbs core will call nanosleep() when paused. This will affect the other GBS files as well.

Is there any need for the pause code to be in the core?
The player code can just stop calling gbs_step() and the core is effectively paused – no code needed in the core for that.

Hello, what kind of environment do you need to build this into a Windows executable? I have the Windows Linux Subsystem, but I assume that if I use that, it will only be launchable from within a WSL command line, and I'm looking for something (that isn't an old WinAmp plugin) that I can associate with the .gbs file format, akin to NSFPlay.

The noise channel for certain tracks of Pokémon Red/Blue seems to be either excessively loud or too fast; this notably includes the tracks for the title screen, Route 4 and Indigo Plateau.

The pokered disassembly should help; audio/indigoplateau.asm and the macros used there may be worth a look.

I am building a new end-to-end testsuite against libgbs.h (see the testsuite branch for now).
Running the testsuite target thus depends on the libgbs in the Makefile – no need for a full gbsplay build as long as libgbs is available.

Running make clean then make testsuite failed with the message that impulse.h was missing.
Adding impulse.h to the dependencies of the testsuite target fixed this bug BUT this now runs a full gbs build instead of just generating the impulse.h file.
It turns out that the recipe for impulse.h contains a recursive call to $(MAKE) with the default target.
Not what I wanted…

• Check if the recursive call of make is actually needed – if not, remove it.
• Why is there a special handling of impulse.h at all? The default dependency generation lists impulse.h as a dependency of gbhw.o and this should be enough invoke the special recipe to create impulse.h.

Based on #72, #74 and others, new features have appeared in gbsplay.
They should be added to xgbsplay as well.
This list might be out of date, it is more of a general reminder:

• add single-song loop mode (shared code, -L works automatically)
• update xgbsplay help text (shared code, works automatically)
• add interactive loop-mode selection
• display loop mode
• display pause
• update xgbsplay manpage

When running with -v, the new register dump output garbles the screen after gbsplay quits.
The prompt reappears one line below the normal status line (time/channel notes/volume meter), while the lines CH2, CH3, CH4, MISC and WAVE are displayed below the prompt.

Example:

[…]
commands:  [p]revious subsong   [n]ext subsong   [q]uit player
           [ ] pause/resume   [1-4] mute channel

Song   1/  1 (Untitled)
00:01/02:00  D-1 %     ---       D-3 %     ---       [#%%%|%%# ]
mitch@hasi:~/git/gbsplay$ 
CH2: 00 3f 00 00 bf
CH3: 80 00 60 42 06
CH4: 00 ff 00 00 bf
MISC: 77 55 80
WAVE: 8acefdb9753124688acefdb9753124ff

Currently the tests are disabled for MINGW_32/MINGW64 in configure because activating them gives errors like this:

TEST util.c
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.text+0x51): undefined reference to `libintl_fprintf'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.text+0x92): undefined reference to `__printf__'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.text+0xc1): undefined reference to `__printf__'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.text+0xe5): undefined reference to `__printf__'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.test+0xb3): undefined reference to `__printf__'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.test+0xd3): undefined reference to `__printf__'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.test+0xeb): more undefined references to `__printf__' follow
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccKTOltY.o:util.c:(.test+0x153): undefined reference to `libintl_fprintf'
collect2.exe: error: ld returned 1 exit status

The reason seems to be that the LDFLAGS are not honored in the %.test build recipe (which runs the test embedded in util.c):

Simply adding $(GBSLDFLAGS) and/or $(GBSPLAYLDFLAGS) (plus -fpie and -fpic) does not work: While this will make the build pass under MINGW*, it will break the build on Linux configured with --enable-sharedlibgbs.

Can we have a seperate LDFLAGS for the host-only builds like the %.test and impulse.h targets?
This might also help with issue #47.

Hi,

First of all thanks for a great library!

I wonder if there are any plans on making the code thread-safe? My use case is that I want to support play more than one song at a time (examples being cross fading, multi decode of many files at the same time, etc)

The current problem is that esp gbhw.c has lots of global variables. On way to solve this would be to setup a "state object" as the first parameter to all gbhw_ functions could take that instead of using the global variables. That way several threads can have their own "hardware" without conflicting with each-other

I'd like to load a .gb file, simulate keypresses, and log the register writes.

is it possible or doable with the help of plugins?

Thx

This track

https://files.scene.org/get/parties/2016/riverwash16/music_chiptune/chipmsx_aceman_arpegger.zip

Isn't played correctly (using latest git, compiled on Linux x64 and played with gbsplay)

aceman_arpegger_syndrome_gbsplay.zip

https://youtu.be/GKO-q8wM-dE?t=31

If you listen you can hear things are missing compared to the youtube video and the mp3 included with the top zip file

Hello

I have a simple .gbs file created with deflemask tracker

It output 3 nites separated by 1 second of silence

When I run the iodumper on it, I obtain:

00000044 ff3f=00
00000044 ff1a=80
00000044 ff1d=00
00000044 ff1a=00
00000044 ff11=3f
00000044 ff12=f3
00000044 ff13=2c
00000044 ff11=3f
00000044 ff14=80
*003ff5ac ff13=16*
00000044 ff11=3f
00000044 ff14=84
*003fff7c ff13=0b*
00000044 ff11=3f
00000044 ff14=86

the lines beginning with a start should be played after a pause of 1 second before them.

I cannot find how to interpret this data in terms of cycles or in terms of time.

Can you help me?

The deflemask song and the gbs export are attached

gb 60bpm.zip

Thanks

Eric

it is rather simple. description is here: https://vgmrips.net/wiki/VGM_Specification
no need to support all the commands, "dmg reg write", "wait 1 frame"/"Wait n samples,", "end of sound data" will be more than enough, the simpler the better.
thank you.

Current state

• gbsplay (and to some lesser degree xgbsplay) use localized messages in their output
• gbsinfo uses localized messages in its output
• libgbs is localized as well

Current issues

With the players and interactive tools, l10n is good and useful, but I don't think libgbs should use l10n:

• libgbs should not directly write to stderr:
  • if stderr is redirected or used for something else, libgbs will mess it up
  • if stderr is closed, it will crash the whole process when trying to say something like "file not found"
• the user of the API must have l10n support installed (?)
  • I'm not sure on this one and if a lib built with l10n support would work on a system without l10n support.
  • libintl stuff on the Windows builds was quite a hassle, we don't want to put our users through this.
  • Worst case is that we would have to provide two versions of the library, one with l10n and one without.

Proposal

Don't use localization in libgbs.

• don't write to stderr or stdout in libgbs
• don't call the intl... functions
• refactor error handling in gbs_open() so that something like an error enum is returned to the caller
• optionally provide a thin wrapper outside of the API that returns localized strings for these error messages
  • if libgbs with l10n baked in also works on a system without l10n support, this gbs_get_errormessage() could be included as a function in the API – but we could still refrain from using stderr/stdout directly
• this looks like we might get different compiler and linker flags for the API and the tools, so we should perhaps split the source into different subdirectories
  • this might be a good idea regardless of any l10n issues ;-)

Please discuss!

Hello
Since commit 9593e46, I get an error while compiling:
My gcc is a bit old:
gcc version 4.9.2 (Debian 4.9.2-10)

I get this error:

CC gbhw.c -o gbhw.o
gbhw.c:85:1: error: initializer element is not constant
 static long vblankctr = vblanktc;
 ^
Makefile:419: recipe for target 'gbhw.o' failed
make: *** [gbhw.o] Error 1

This error is surprising, as vblanktc is declared as:

static const long vblanktc = 70224

Thanks

As a non-standard extension, it would be great if .gbs playback would support MBC5 bank switching, to allow for more than 256 ROM banks. What needs to be done then is to make sure that writes to $3000-$3FFFF control the high bit of the ROM bank number. This might be needed to fix jkotlinski/lsdpack#4 for the case where final ROM has more than 256 banks.

Issue #41 has our first "customer" that seems to use libgbs as a library. So we probably need a stable API from now on.
I don't know if our API was stable over the last years – and if it was, I don't know if it was deliberately stable or rather by accident. At least i have until now never thought "I should not change this", it was more like "if it needs refactoring, just do it".

I think this task includes at least two aspects:

• define our API (perhaps provider extra header files for libgbs that are different from the ones used internally)
• add tests or a demo application that ensures stable operation of this API

This task relates strongly to issue #41 because with that issue a lot if internal changes and refactorings happen.
We either have to provide an extra compatibility layer to support the older, historical API or we make a cut and define a new API (probably with a version change to 1.0.0) and ensure compatibility from then on.

This issue is an invite for discussion :-)

Hi everyone !
When I use this command "gbsplay -o midi myfile.gbs" the result is a midi file per song.
This is fine.
But there is not 4 midi instruments in each midi file, as result, I can't read the partition of the bass line, the solo, the chords... And it doesn't sound like when I use this command "gbsplay myfile.gbs".

(I hope my English here is good enough to be read)

Thanks for the attention.

I noticed there has been a lot of code changes since the last release was tagged. I've built the code using the master branch and it works great! It fixes an issue I had compared to the packaged version that's in the Debian repos. An opcode was not implemented (0xFF70) in that release as far as I can tell.

Is there anything planned to do before a new release is tagged?

Hello ranma,
If you have username moroboshi on OpenWrt forum please, comment on this message: https://forum.openwrt.org/viewtopic.php?pid=297299#p297299

The fact that this patch is useful for OpenOCD community I tried to integrate it in the program, but faced with the Copyright information.
If this patch is written by you, then please just keep your feedback on(please keep your email and full name):
http://openocd.zylin.com/#/c/3390/
(You may want to comment on your code)

Thanks, Dmytro

Checking out issue #19 I ran the midi plugout for the first time in a long time and found some small issues:

• The plugout name in gbsplay -o list says MIDI sound driver but it is a file writer like stdout. This should be a simple rename.
• The generated filename is gbsplay-1.mid. When you run it again, that file is silently overwritten. We should either output a warning, disallow the overwrite or sequentially name the output files (there is already a -1 in there, so using -2 and so on should not be too surprising to the user).
• Silence detection does not work properly: When running gbsplay -o midi examples/nightmode.gbs, output stops after 2 seconds because gbsplay runs into the default silence timeout. -T has to be set to export more than 2 seconds. I'd guess silence detection does not work because no waveform is generated.

Tested on latest OS X and the configure script had many errors that caused it to fail. I eventually got it to work with the following changes:

• compiler check (and many subsequent checks) fails because first parameter for the c main function needs to be int, not char
• $TEMPDIR is not portable (not defined on OS X). $TMPDIR is the POSIX standard that should be portable everywhere
• had to remove -O1, got ld: unknown option: -O1
• i had to add -lintl to GBSLDFLAGS
• had to add the paths where my package manager installs libraries and include files (-I/opt/local/include , -L/opt/loca/lib)

After 2 seconds with no sound, gbsplay considers the song is finished.

Spot (1990)(Software Creations, Arcadia).gbs.zip

With a player based on GME (https://bitbucket.org/mpyne/game-music-emu), I can play the first subsong successfully.

MiniGBS (https://github.com/baines/MiniGBS) plays the first subsong too.

Tested on Linux with gbsplay 0.0.94-6-g34652b0.

Thank you!

I would like to pass a track number to gbsinfo to get information only for that subsong. Mainly I want to know the duration for each subsong. I could extract each subsong as a separate audiofile to determine this, but it would be more efficient to not have to extract them if this can be determine using the header data.

Also, maybe gbsinfo should show the sum total duration of all subsongs.

Which version of GPL is it licensed under? It does not explicitly state, nor does it include the licence.

• GPL 2 only?
• GPL2 and any later version ?
• GPL3 ?

This affects compatibility with other licences.