Offline
Australia

I'll let DSC answer that one. I don't yet have an arduinoboy myself

Offline

Makes sense to use mGB mode.
I use the same breakdown of the first three CC's off of the first midi channel using mGB.

MIDI CC 1 - Pot 1
MIDI CC 2 - Pot 2
MIDI CC 3 - Pot 3

Easy retrofit to an existing arduinoboy especially if you used one of the later Arduino pro mini's with the extra analog pins.
Even a new build would not cost very much now that Arduino's have come down in price so much.

Last edited by DSC (Jul 2, 2015 2:05 am)

Offline
Australia

Furrtek, your code is a maze!

EEPROM read and writes fully replaced, I've been finding little snippets of EEPROM code in random places that needed re-directing. Formatting is complete as is Saving songs and patterns to SRAM. Still need to work on the loading side of things but most of the hard work there is done.

Took the code for a spin on my flash cart, first boot throws an error due to un-formatted SRAM (which is formatted for you) Second and subsequent boots are all good.

Once the load routines are patched for SRAM I'll work out his save structure and if it isn't too hard coded I'll look at expanding the data saved. Worst case, I'll use the same addressing for the upper 16kbytes as the lower and replace it with all the settings that weren't saved in the original.

We're getting places!

For those playing at home, get the latest build here www.bennvenn.com/GB303_Snapshot1.rar

Files modified in that build include: main.s;eeprom.asm;pots.asm;gfxutil.asm;save.asm;input_loadsave.asm and params.asm

Offline

All this is great news!
Thanks for taking care of this, BennVenn!

I have cloned the code on github too and started to look at it, but I don't really know the GB hardware yet...
(I have the original hw too, and two of your flashers as well)

I would like to add more complete midi control if possible...
I tried to change some code, which kind of works... but I would like to get some advice....

Github is great to share, comment, or enter issues about the code, I think it is totally worth the effort, Benn.
Do you need some help to put every 'intermediate' version online?

Offline
Australia

I just had a poke around your fork. I can see how it can be a very helpful tool for a developer. It would be good to work with you on this, what are your goals on the midi expansion?

Offline
BennVenn wrote:

I just had a poke around your fork. I can see how it can be a very helpful tool for a developer. It would be good to work with you on this, what are your goals on the midi expansion?

Yes github is really great for seeing commits, and git really excels in branching and stuff. I don't know if you are familiar with it or not.
Each developer can focus on a feature, make individual commits, and when the feature is complete, it is merged into the main branch.

Concerning the MIDI expansion, in fact I don't really like the sound of the synth
But the drums are great.
So I would like to be able to trigger the drums with MIDI.

I have found the place were the incoming midi note is compared to the acceptable range of notes.
So instead of triggering the synth, I tried to trigger a drum instrument....

it is kind of working but... even with the original code, the synth was not always trigged by midi notes. It produces a sound one time out or four, roughly...

Did you notice a bug in this part?

BTW, we could also discuss this matter on github, and discuss every feature/bug in a separate issue...

Offline
Australia

I was looking through the serial handler routine a few days ago and noticed no real frame reconstruction. As you may know, MIDI isn't one byte per instruction; it uses a series of bytes. Furrtek's code looks for the start byte (This is all from memory, could be a lil bit off) and then processes it if it satisfies its filter. This is likely why it takes a few consecutive midi strings to re-sync. Should be an easy fix - Had to implement something similar in my linker code.

I tried installing the WinXP Github program that was linked earlier but no good. The installer wants some service pack that I'm not running. I think I'll give up with the whole Github thing. It would be very usefull but isn't necessary.

We can discuss the code dev here?

Offline
Brighton

You don't need their own tool to use github, there's other git clients.

Offline
Australia

Yes, I installed the Git 'client' and from that I can make commits to my fork but it seems to want to deal only with .git files. There is probably a simple way to roll my working folder into a .git file, or maybe its more of a change log. I'm not sure. If someone has set up an environment on an XP machine and would like to give me a quick run down on the procedure I'll adopt it. Otherwise, the focus should be on the task at hand.

Offline
BennVenn wrote:

I think I'll give up with the whole Github thing. It would be very usefull but isn't necessary.

I really think that a dev on github coukd ease the code sharing and discussions.
As radian says, you can use other clients, or simply use the command line: git commit, git push.
After that, your changes will be reflected automatically on github.
The issues tracker, even without git, could be useful to discuss several problems at once, and keep track of it.

Last edited by cyberic (Jul 2, 2015 10:28 pm)

Offline
Australia

OK, I'll read into it a little more. I might need to re-fork and apply my code changes again to satisfy the client.

How is it we can all work on the code at the same time and not step on each others toes? It seems the way Furrtek has coded the ROM a lot of modues are inter-connected and a change in one routine has consequences on others. We could leave the original code there and build around it but that would bloat the binary with unused routines and make it very confusing for new contributors.

I haven't worked in an environment where there are multiple contributors so this is new to me. I do comment almost every line or atleast function to make it easy for others to follow. In my mind, 2 people working blindly on one project will end in disaster. Ideas?

Offline
Unsubscribe

The way git works you should be able to have a bunch of admin level users who can review and accept revisions to the branch. A user that wants to work on it will fork the branch, make changes and push a change. Then people can accept or not, or just use the fork.

Offline
Australia

How does the actual interface work on the PC side of things, does it only work on specific .git files?

Offline
vancouver, canada

depends on the specific tool you use to Do Git Things.  One thing that may be useful to you is to use a GUI client like SourceTree (https://www.sourcetreeapp.com/) that helps visually illustrate the various branches created by others, so that maintainers can work towards consolidating divergent revisions back into the main branch (typically called "master").

You can reduce code you deem redundant at the point where you merge branches, to per-line granularity if you wish.

not sure what you mean by "specific .git files" but any files you might need to keep under version control should be supported by git.  you can also create a .gitignore file that specifies files or file types that you _don't_ want to include in the repository (for instance, binaries that you compile from from the source, or other temp files).

https://www.atlassian.com/git/tutorials/ i find is a good no-nonsense tutorial for gleaning the basics.

Offline
settle
bryface wrote:

not sure what you mean by "specific .git files" but any files you might need to keep under version control should be supported by git.  you can also create a .gitignore file that specifies files or file types that you _don't_ want to include in the repository (for instance, binaries that you compile from from the source, or other temp files).

https://www.atlassian.com/git/tutorials/ i find is a good no-nonsense tutorial for gleaning the basics.

Ditto what bryface said. I've used git in my projects at school, and it's designed for collaboration with multiple developers. I agree though that it's not very intuitive; I've had to explain it to group members multiple times tongue

Personally I've used the command line ('git status', 'git pull origin master', 'git add', 'git commit -m', 'git push origin master', etc.) and I've found it pretty straightforward; it may or may not be good for you on XP.

BennVenn wrote:

...maybe its more of a change log...

The .git files that are being generated are just what you said: they keep a local record of the changes and incremental "commits" you've made. Whenever you do a "commit" the .git file is updated; syncing with the server ('git push…') brings both local and remote copies up to date. Actually you can use git without an external server (that's all that Github is) to track your changes, but you then don't have a remote record of your previous changes (and of course, other people can't look at what you've done).

Branching is for other (admin) developers working in the same group and repository, either as personal workspaces for each person before changes get dumped into the main perfect version ('master'), or for developing and testing out new features without breaking the current perfect version.

Forking is designed for random outside people who walk up, want to check out your code, and maybe fiddle around with it; it's more of a "hard copy." Later on if they think their changes are awesome and would make the original better, they contact you for a "pull request" to combine their changes with the current perfect version. Then you go through the merge process, by which you decide which changes of theirs to keep, which are redundant or outdated, and which to throw out. It's a good way to collaborate without giving others too much control.

As for collaboration: honestly you'll want to talk with other people you're working with to split up tasks and make sure you're not stepping on toes. Once you've done that, though, git allows you to work separately on the same code base and then come together later to combine your changes and work out any conflicting differences.


Haha sorry for the long post! ^_^ Hopefully that makes sense. If you have any other questions I'd be happy to help. I haven't done GB programming, but at least I can help out with this sort of thing.

Offline
BennVenn wrote:

How is it we can all work on the code at the same time and not step on each others toes? It seems the way Furrtek has coded the ROM a lot of modues are inter-connected and a change in one routine has consequences on others. We could leave the original code there and build around it but that would bloat the binary with unused routines and make it very confusing for new contributors.

I haven't worked in an environment where there are multiple contributors so this is new to me. I do comment almost every line or atleast function to make it easy for others to follow. In my mind, 2 people working blindly on one project will end in disaster. Ideas?

To summarize, here is a possible workflow when you work with git:
- create a branch, like 'fix_serial'
the current code will be "branched", so you will have a branch containing exactly the same code as before
- you make a small change
-  you commit it even if the feature is not complete. you include a descriptive changelog of what you did
- you make another small change
-  you commit it
- now, the feature is complete
during all this time, the master branch was unaffected by your changes, and other developers could develop other features independently
- you (and git) will now merge the feature into the master branch
this can be hard because the master branch could have changed
but git is smarter enough to notice if you renamed some files, or if another developer inserted some code in a place you touched.
Git tries to merge automatically, but sometimes it fails.
In this case, you get "conflicts": a part of code that you changed, and a part that another developer changed, are conflicting.
You have to solve it by hand, and once this is done, you commit the conflict resolution.

After that, on github, or with another tool, you are able to browse every commit one by one, and see what code was changed.
You can easily read the changelog to see what happened, then inspect the changes.

So for now, if you are only beginning with git, and if you will be the most active contributor, try to make only small changes, and commit them one by one.

you have to get a clone of a repository, with "git clone"
then "git status" than "git add" for every file you want to commit
then "git commit"
wrtie the changelog
and git push
And your changes should appear immediately on github

If someone else want to develop, he/she can clone your repository, make changes, and make a "pull request".
You will have to read his/her code, and accept it or not.
This is how other developers will be able to help as well.

I hope I was clear enough, if not...
just ask