Currently Being ModeratedDec 12, 2012 8:17 AM (in response to YirWaffy)Re: Feature Request: MD5 firmware checksum for Monkey or Workbench
You can send your feature request directly to the Line 6 product developers here:
(This link is kind of hidden under the Contact Us button at the foot of this page.)
Currently Being ModeratedDec 12, 2012 3:42 PM (in response to silverhead)Re: Feature Request: MD5 firmware checksum for Monkey or Workbench
Thanks, Silver. I'll use that. I'd hoped to generate some discussion on the necessity of this feature here too.
I'd expect that the devs monitor their own product forum... but I've been wrong before
Currently Being ModeratedDec 13, 2012 12:35 PM (in response to YirWaffy)Re: Feature Request: MD5 firmware checksum for Monkey or Workbench
In a spirit of keeping the discussion going...
How certain are we that this is the exact cause? It certainly seems that there's some kind of corruption, but we might possibly be missing something subtle (though I don't know exactly what that would be).
A year or two ago, on my Vax 300 while I was wrestling with a dirty contact issue that got in the way of MIDI communication, Line6 Monkey kept reporting errors during the firmware flashing process. I don't recall exactly, but I think they were checksum errors. If I'm remembering correctly, that means that there's at least some sort of error checking going on already.
Looking at that other thread, I see numerous people seeing the problem fixed after flashing between various firmware versions, but it seems most likely to me that it's simply something that has a *chance* of being fixed on any particular re-flash (of any version), and it's probably a coincidence which versions, or which versions in a row, they were flashing.
What do we know so far about this issue for sure, and what is still an uncertain hypothesis, or pure conjecture?
Currently Being ModeratedDec 13, 2012 12:53 PM (in response to mdmayfield)Re: Feature Request: MD5 firmware checksum for Monkey or Workbench
Also, though I'm not an embedded systems programmer, I do have some assembly language programming experience, and one fairly decent analogy to firmware corruption is the Game Genie on the old 8-bit NES.
Each "code" you'd enter on the Game Genie alters one byte in the system's RAM or in (what the CPU sees as) the cartridge ROM. So for example, in the game program code there's some value that says every time Mario jumps, increase his Y position until it reaches, say, 50 pixes above the ground, and once it reaches that, make him fall downwards.
So you'd enter YAUVIO or whatever the heck it was, and that would translate to the hardware as "replace the value in (location) with (#)." Let's say it replaced a 50 in that spot in the jump code with 255. Then, when you played the game, you could jump all the way off the top of the screen.
Bringing it back to the Variax, I'm suspicious of the idea of firmware corruption being to blame because it's such a specific symptom (the mixing of altered and original tunings), and general firmware corruption would mean that random spots in the firmware are getting altered - like entering completely random Game Genie codes. It's unlikely that a bunch of people are getting *exactly* the same bytes in the firmware corrupted in the same way. It's more likely the Vax would simply refuse to boot, lock up in certain situations, or have some incredibly subtle error in a random model or two, such that you'd never notice it. (The equivalent of what always seemed to happen when I entered random Game Genie codes. )
My instincts tell me that there might possibly be something that sometimes happens upon initialization of new firmware that is curing/causing the problem, instead the reflash process itself. I'm not sure, of course, and the firmware corruption could still be it, but the idea tickles my brain.
Currently Being ModeratedDec 13, 2012 5:03 PM (in response to mdmayfield)Re: Feature Request: MD5 firmware checksum for Monkey or Workbench
An interesting perspective, thanks. I was curious why the corruption wouldn't lead to crashes or a failure to boot. On reflection, it seems likely that the corruption is in the area around writing the models emulation code / parameters rather than the underlying boot up location. Still, it seems to me if there was a checksum for each firmware version that could be compared to the reading system contents and standard NVRAM data on the guitar, that would help with diagnosing these types of problems.