GB-303 Bug Fixes, Feature Requests, Open Source. (Page 3 of 11)

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

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?

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?

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.

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?

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

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

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.

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.