Source is Version 1.3.0 and problem compiling the source

[zemzelett]

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

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

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

[trash80]

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]

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]

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]

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]

@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]

I can’t say exactly where i stopped working on it. But it is mostly done. I think i hesitated publishing it, because i never felt it was ready to. Vibrato is working in my version by GUI and CCs. Pitchbend is working smoother on my version, well, to my standards, that is. I added a wave shape editing tool to it… Made space and algorithms too save up too 255 wave shapes. 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. This enabled me to run quick tests. The whole codebase is assembly. I worked on it on and off for about 2 years. Altogether maybe like 4 to 5 months. I stopped working on it a little over a year ago. Do you have any specific question you’d like to be answered? BGB takes my sym files just fine. What are you developing with? I have no clue about GBDK though!

…

Am 04.02.2019 um 12:06 schrieb Greig Stewart ***@***.***>: @zemzelett <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALBq96jYiqkYHNOI-Qekpvz-4NWIHirTks5vKBQ8gaJpZM4FtepM>.

[cyberic99]

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]

@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]

I’ll think about what you said. Might do put it out for people to look at it. MidiToMGBA sounds just like my tool. Just for mGBA. It was initially done for BGB but they changed because BGBs TCP solution seemed unstable. I never had that problem. If i decide to put out my version of mGB, i’ll push this tool out as well. To answer your questions: Sym-Films are generated while building the rom file. I’m using RGBDS. Its linker has the option to output sym files. So it’s generated alongside the rom file. Mine starts like this (it’s got 400 lines, so…): ``` ;File generated by rgblink 00:0150 Start 00:0175 main 00:03E0 irqVBlank 00:0446 irqLyc 00:01BF buildScreen ``` The format of the sym file is pretty self explanatory i guess. I don’t know if i really understand your second question. I cannot remember having any issues triggering code blocks from the midi logic. Trash80s code is pretty solid regarding this already. I did only implement minor changes to this code to make it faster / use less cpu cycles. I can remember having problems with the MIDI data being faulty when writing the BGB link tool i mentioned. But this has nothing to do with mGB itself. Can you explain more what you mean with „causing instability"?

…

Am 04.02.2019 um 22:53 schrieb Greig Stewart ***@***.***>: @zemzelett <https://github.com/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 <https://github.com/0x0ade/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALBq9_Cbl1bQO2wP0Yh0jXsGcKqBkh7dks5vKKvFgaJpZM4FtepM>.

[greigs]

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.