trash80/mGB

Source is Version 1.3.0 and problem compiling the source

Closed this issue · 10 comments

zemzelett commented

Hi there,

first off, thanks much for hosting the source!

The version of the source seems to be not 1.3.3 as in the mgb.h file it turns out to be 1.3.0:

unsigned char versionnumber[10] = 
{ 
     32,81, 
     2,81, 
     4,81, 
     1, 
     0,0,0 
};

Also i am having issues compiling the source. Some of the issues are easy to fix but some are not because i can not be certain.

  1. double declaration of the following in mgb.h: UBYTE midiDataReadPosition;
  2. referencing a function from gb.h that's commented out in gdbk 2.94 and 2.95: add_SIO(asmUpdateSerial); (mgb.c - line 61) > I used 2.95-3 instead 2.95, my bad
  3. mGBASMMidiFunctions.s refers to _io_in which is not declared anywhere ld hl,#_io_in (I assumed, that it is _update_port_io in mgb_serial_io.s but i can't be sure - also read next point)
  4. mgb_serial_io.s is not referenced during assembly (in make_mgb.bat)

So i think there is something wrong with the source. Might it be possible to check that and upload the correct files? I'd appreciate that much.

Also, changing everything to my assumption doesn't give me a Rom that is working properly, visuals are weird: > Visual are due to point 2 above
mgb_01 mgb_02

The tiles are in the Rom, but are referenced wrong?
mgb tiles

Also, it would be nice to know, which version of gbdk to use, when compiling the source.

trash80 commented

Thanks for the info. Re: reference to _io_in, I believe the version of GBDK I was using had been modified. I'll need to either put in the old version of GBDK, or rewrite this to work with the GBDK currently on Github and make it a module. (This is probably better). As for fixing it for now: _io_in is just the current byte from the serial interrupt, you could use the example code from the GBDK communication example. I'll be fixing this issue shortly. (Never enough time in the day)

trash80 commented

Should compile okay now. Added GBDK-n as a submodule from a modified fork. I had to add some stuff to crt0.s (serial buffering) as well as updated code to compile with the newest version of SDCC. Code was originally written for a very very old version of SDCC for GBDK. I think they stopped supporting gbz80 for a number of years. Glad it works! :)

zemzelett commented

Hi Trash80,

i'm in the process of rewriting mGB in full assembler since almost 2 months now as you didn't reply. I'm almost done. Just adding a few new features and thinking about implementing some that are not really there although they should be? (vibrato?)

Would you be up for a little explaining of why you did to some things the way you did and clearing some question of a few things i might just not understand properly?

trash80 commented

Like what? Send an email to trash80@gmail. Some quirks are because of compiler issues and such. SDCC is not very friendly, especially when we were using a version dated about 14 years old. ;) The key to the whole operation is using a buffer for serial data in the sio interrupt, and then reading that buffer at some point later in the loop. Also being careful of midi data that doesn't include a command byte, since they don't have to be sent if the last command is the same as the next. Trap for young players. :)

greigs commented

@zemzelett Any luck with that rewrite? I've been looking at getting the existing vibrato code hooked up to a CC input. That was simple enough - the code was all there and seemed to work (maybe just un-optimised). Next I'm looking at adding portamento, but I'm having difficulty debugging the code - bgb doesn't seem to accept the SYM file to make this easier.

zemzelett commented
  • 👍1
cyberic99 commented

I wrote a tool (Chrome plugin) too properly debug the program with BGB. I can hook up a midi device to my Mac / PC and connect to a BGB instance running on it to test actual MIDI input without burning the ROM to a physical cart all the time

Whow that it amazing!

Do you plan to share your tools?

greigs commented

@zemzelett the wave editing tool sounds fantastic, as are the other changes and chrome plugin. If there is any danger of this project being left unfinished / abandoned, I'd suggest putting it all up on github maybe with some alpha builds of the roms. By making the project more visible it might help motivate you as well - plus I'd like to try it out, even in its current state!

Also you might not be aware of MidiToMGBA which included a working release for BGB before it moved to only supporting MGBA, it seems similar to your chrome plugin (but very CPU intensive).

Questions:
How do you generate SYM files with your toolchain and what do they look like (don't worry about GBDK)? A small sample might be of use - the incompatibility I'm seeing is hopefully a minor one.

Have you encountered issues where jumping to a code block works fine when it is triggered by a button press but when the jump to that same block originates from the processing of a midi message it causes instability? Just in case there are any gotchas. It is probably a noob level issue. I can hopefully trace it through once I have symbols loaded.

Good luck with your project, I can only imagine the effort involved writing that much assembly.

zemzelett commented
greigs commented

Thanks for considering it.
That was useful. I found the info I needed to get symbols loaded from SDCC (they are in the wrong format apparently).

In 3.0.0 sdldgb and sdldz80 don’t support generation of rrgb (Game Boy simulator) map file and no$gmb symbol file formats. The as2gbmap utility can be used to convert sdld map format to rrgb and no$gmb file formats. - sdccman.pdf

I'll get debugging rather than trying to explain the issue! I'll be in the gbdev discord as ThereminHero until I have something working.