Thanks for the tip re the silicon "cork". Just installed it on my MV today using the material you linked to and what a difference. The pads are now super sensitive and it's much easier to consistently hit them dynamically. The pads now respond more like Maschine pads which is a great thing in my book.

Great to hear, glad it worked well for you!

I'll have to skim back through the previous replies..
Here are my initial 'nice to haves' for the MV-8800:
1) 1GB ram Fully supported, recognised and stable & correctly displayed in all relevant modes.
2)  The Audio track capacity to be either 8 Stereo (Current arrangement) or splittable into 16 mono tracks (Or a mixture of both)...  each fully discrete, pan-able and fully supported across all bus & FX arrangement ... i think the original MV-8000 DID allow for 16 mono tracks, so why Roland dropped this on the 8800 is a proper thumb in the ass decision!
3) This will come down to the HW of the graphics & and how far it can be squeezed???., but if the display refresh latency could be brought down a bit more, that would be excellent..  Esp when displayed on an external monitor.. There is a noticeable lag in the scrolling, esp at higher tempos.. Which can be off putting sometimes.

For #3, are you running your external display at 60hz or 75hz?

Howdy everyone, just a little update.

The project saving/loading speed up is done and working (with some caveats).

What I implemented was, if a song is not in use, all of the files related to that song are not written when saving.  This speeds up project loading/saving by quite a bit (there are 23 files written out for each of the 16 potential songs).  So, if you only have 1 song in your project, 345 fewer files are written to disk.  Same goes for loading, 345 fewer files are opened and read.  If you add a song to your project, those files will show up when you save.  I've been doing a lot of testing of saving/loading/renaming etc.  A little more to do, but so far it's working like a champ.

In general the disk I/O is super slow on the MV.  I plan on looking at that in the future, both at the HW level w/ the IDE settings and the FAT filesystem code (which is hideous).

What took so long was trying to get the actual song *directories* to not be created.  This was a HUGE can of worms and I spent the past 4 or 5 months just on that.  In retrospect, it was a colossal waste of time.  I have OCD and it bothered me those directories were there.  To get that working entailed modifying a lot of different places in the existing code (which is super tedious due to the code not being position independent).  Just a ton of extra work for very little payoff.  I backed it all out.  I'll just ignore the empty directories.     If at some point in the future I discover an easier way to do this, I'll implement it.

The only thing I should add at some point is the removal of those files if you delete an existing song (other than the first one) from your project.  As of now, if you remove a song from your project, the files will stay, so project loading/saving will start to creep back to the original speeds with each additional song added/removed.  Worst case would be using all 16 songs and then removing all but 1.  The files can always be removed manually over USB, etc.

Additionally, copying existing projects will not remove unused files.  If you know your project doesn't use the files, they can be deleted and things will still work normally.

I am curious if anyone uses more than 1 song in a project, I never do so this is a huge workflow speed up for me.  It's 1 song per project for me.

There are more optimizations I can do here, but I'm going to move on to something more interesting for my next change.   

What's also good about my firmware changes is that I'm pretty confident it won't brick MV8800s.  You can very easily go back to the original firmware (I have done this hundreds of times over the past year or so).  The reason why is because I have not modified the bootloader at all which is what handles installs, etc.  I say all this but when I do make these changes available I will still have to make note that I can't guarantee things and can't be responsible.  But that's the usual way with custom firmware.      

I'll make another post when I've decided what to tackle next!  I really want to implement varispeed, but I have been talking with the fellow who makes the MV-OP1 ADAT card and it seem I may be able to build a circuit w/ MCU to do it in hardware with minimal software changes (if any).

Do you know what OS Roland are using?  I cant believe that they would develop the GUI framework and OS in house.  QNX was available at the time and supported the processor used.

It does not seem to use an OS, everything is pretty much bare metal, there is a notion of tasks, but I haven't been able to figure out if it is part of some library or OS primitive.  It'd expect to see some strings or sentinal signs of a particular OS.  QNX was great, I used to work with that.  Nice separation of micro kernel and user space processes. 

The libc used on the MV looks very much like newlib. Most of the std routines like malloc, etc are exactly the same, instruction for instruction.

The UI seems to be a home grown thing, but again not 100% sure.  The MC-909 has similar class names in its unpacked code.
I have yet to figure out how the UI stuff works other than knowing where the structures for all the dialogs are populated.  It's a pretty convoluted processes (even de-compiled).

An interesting thing I discovered poking around at the schematic when figuring out all the chip selects.  There is no code necessary for handling rendering to the external display.  The Epson chip they use natively supports this dual display feature.

Back to working on this on a semi-regular basis at night (but not too too much, don't want to get burned out again).  Thankfully the short break didn't cause me to forget everything.  Current focus is to finish the functionality of speeding up project load/save (which will shorten boot time as well).

It is working, but I'm also trying to not create/utilize the files if they are not used which is a bigger change.  Right now I'm fighting a bug where the temp folder/project TEMP____ is not cleaned up properly during a save which corrupts things.  Debugging this is a slow process, but due to the quarantine, I have lots of time @ night to test stuff out.   

What comes first ? Learning language ? Which one ?

The skills I'm using for this project are the C language, and Super H assembly.  Being able to reverse engineer from assembly as well as write new assembly code is a big chunk of the work.  There was a lot of electronics stuff in the beginning, but that stuff is all done now.

Have you made any progress recently ? This topic is so interesting !

Hi, thanks!

Yes, progressing a bit more slowly.  I burned myself out before the holidays and took a breather for other projects.  I was spending just about every waking moment on this project so needed one.  Back on it though and I hope to have the project load/save speedups wrapped up.  It is working, but I want to do it 100% correctly, not a hack... so it is taking longer.

Making changes is extremely tedious due to having to patch in large amounts of assembly code and handling all of the offsets etc.  I need to automate this or I'll go mad.