Re: [M100] model 200 dvi cable
Huh. That may be the most practical recipe using parts available today. On Sat, Nov 11, 2017 at 2:29 PM, Mike Steinwrote: > Boy, there's just no pleasing some people ;-) > > OK, so how about plugging a female IDC plug into the back of that solder > tab male with a dab of glue to keep them from separating (note that some > 40-pin male box headers have pin 20 removed): > > > > m > > - Original Message - > *From:* Brian White > *To:* m...@bitchin100.com > *Sent:* Thursday, November 09, 2017 2:57 AM > *Subject:* Re: [M100] model 200 dvi cable > > That doesn't fit. That's the only kind I can find so far too. Sometimes in > black, but always the same shape. > > It does just barely fit in a 102, but it's not even close in a 200. Not a > matter of shaving or wiggling etc. > > The one you pictured before has a minimal shroud that hugs the pins > closer, which today I can only find in pcb solder form, not idc crimp on. > > I would love to find that today. Directions that say to seperate and > solder 40 individual wires, *in the correct order*, or assemble 2 > connectors on a dumb little adapter pcb just to hold 2 connectors... blech. > > On Nov 8, 2017 11:53 PM, "Mike Stein" wrote: > >> Something like this? >> >> https://www.ebay.ca/itm/5Pcs-2-54mm-0-1-Pitch-2x20-Pin-40-Pi >> n-IDC-Male-Box-Header-Flat-Cable-Connector/182237978492?hash >> =item2a6e3adf7c:g:IVQAAOSw1QpZ9dl~ >> >> m >> >> *From:* Brian White >> >> *To:* m...@bitchin100.com >> *Sent:* Wednesday, November 08, 2017 11:00 PM >> *Subject:* Re: [M100] model 200 dvi cable >> >> Found it. Thanks. So it looks like a part that once was off the shelf, >> but now is not common, but maybe still available with enough looking, or if >> you simply knew a magic part number. Thanks again for the pic for reference. >> >> -- >> bkw >> >> > I sent a picture on Oct. 17. >> > Normal crimp-on male header plug with twisted wires. >> >> >> Does anyone have a picture of a real original dvi cable for model 200? >> >> Specifically, the plug that goes in the 200? >> >> ... >> >> ...what did they give customers originally? >> >> >>
Re: [M100] REX 4.9 Revision 236 bug
well that does sound like a bug! On Sat, Nov 11, 2017 at 4:31 PM, Brian Brindlewrote: > Yes, I do see a progress bar in the bottom right when it happens. > > I know it's a buggy revision but I'm just having fun playing with it. > Other than this oddity I've had great success with it. > > Thanks, > Brian > > On Nov 11, 2017 2:16 PM, "Stephen Adolph" wrote: > >> Ok. >> thanks for the report. >> When REX writes to flash you always get the progress bar. >> Do you see the progress bar when you suspect rex is writing the RAM to >> the backup image? >> >> >> >> On Sat, Nov 11, 2017 at 1:10 PM, Brian Brindle >> wrote: >> >>> Thanks for the reply Stephen, >>> >>> Short version is if you follow the steps above REX will overwrite a RAM >>> image before prompting you to ask if it's ok and when you first launch >>> REXMGR before you've selected any options. >>> >>> >>> >>> On Nov 11, 2017 11:36 AM, "Stephen Adolph" wrote: >>> Brian can you more clearly lay out the issue? On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle wrote: > Found an interesting little condition today utilizing the Quick Menu > Features with REX to backup RAM. If you do things in this order REX will > write over the current RAM image before asking permission. I doubt this > would cause any major issues for anyone but it's interesting none the > less. > > Select a RAM image, let's call this RAM-A. Do a total wipe / reset of > the M100 then reload REXMGR but this time select a different RAM image so > say RAM-B. > > If you at any time hit CTRL-B to backup RAM the image will be written > immediately then you will be prompted for confirmation. If you say no - > too > bad, it already happened. > > So I tested a few more times just loading REXMGR and noted that the > progress bar did it's thing in the right corner of the screen when loading > REXMGR. So started over, switched to a different RAM image again and > created a file. Verified that indeed just going into REXMGR was causing a > write to the RAM image without selecting it or requesting a backup. > > Seems to be somehow related to REX remembering the last image you were > in? The one with the asterisk? If I do a refresh of the one with the > asterisk everything works as it should. > > Just figured I'd throw that out there in case it wasn't known. > > > Thanks, > Brian > > >>
Re: [M100] REX 4.9 Revision 236 bug
Yes, I do see a progress bar in the bottom right when it happens. I know it's a buggy revision but I'm just having fun playing with it. Other than this oddity I've had great success with it. Thanks, Brian On Nov 11, 2017 2:16 PM, "Stephen Adolph"wrote: > Ok. > thanks for the report. > When REX writes to flash you always get the progress bar. > Do you see the progress bar when you suspect rex is writing the RAM to the > backup image? > > > > On Sat, Nov 11, 2017 at 1:10 PM, Brian Brindle wrote: > >> Thanks for the reply Stephen, >> >> Short version is if you follow the steps above REX will overwrite a RAM >> image before prompting you to ask if it's ok and when you first launch >> REXMGR before you've selected any options. >> >> >> >> On Nov 11, 2017 11:36 AM, "Stephen Adolph" wrote: >> >>> Brian can you more clearly lay out the issue? >>> >>> >>> >>> On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle >>> wrote: >>> Found an interesting little condition today utilizing the Quick Menu Features with REX to backup RAM. If you do things in this order REX will write over the current RAM image before asking permission. I doubt this would cause any major issues for anyone but it's interesting none the less. Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the M100 then reload REXMGR but this time select a different RAM image so say RAM-B. If you at any time hit CTRL-B to backup RAM the image will be written immediately then you will be prompted for confirmation. If you say no - too bad, it already happened. So I tested a few more times just loading REXMGR and noted that the progress bar did it's thing in the right corner of the screen when loading REXMGR. So started over, switched to a different RAM image again and created a file. Verified that indeed just going into REXMGR was causing a write to the RAM image without selecting it or requesting a backup. Seems to be somehow related to REX remembering the last image you were in? The one with the asterisk? If I do a refresh of the one with the asterisk everything works as it should. Just figured I'd throw that out there in case it wasn't known. Thanks, Brian >>> >
Re: [M100] REX 4.9 Revision 236 bug
236 revision is probably not a good thing to use. On Sat, Nov 11, 2017 at 2:16 PM, Stephen Adolphwrote: > Ok. > thanks for the report. > When REX writes to flash you always get the progress bar. > Do you see the progress bar when you suspect rex is writing the RAM to the > backup image? > > > > On Sat, Nov 11, 2017 at 1:10 PM, Brian Brindle wrote: > >> Thanks for the reply Stephen, >> >> Short version is if you follow the steps above REX will overwrite a RAM >> image before prompting you to ask if it's ok and when you first launch >> REXMGR before you've selected any options. >> >> >> >> On Nov 11, 2017 11:36 AM, "Stephen Adolph" wrote: >> >>> Brian can you more clearly lay out the issue? >>> >>> >>> >>> On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle >>> wrote: >>> Found an interesting little condition today utilizing the Quick Menu Features with REX to backup RAM. If you do things in this order REX will write over the current RAM image before asking permission. I doubt this would cause any major issues for anyone but it's interesting none the less. Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the M100 then reload REXMGR but this time select a different RAM image so say RAM-B. If you at any time hit CTRL-B to backup RAM the image will be written immediately then you will be prompted for confirmation. If you say no - too bad, it already happened. So I tested a few more times just loading REXMGR and noted that the progress bar did it's thing in the right corner of the screen when loading REXMGR. So started over, switched to a different RAM image again and created a file. Verified that indeed just going into REXMGR was causing a write to the RAM image without selecting it or requesting a backup. Seems to be somehow related to REX remembering the last image you were in? The one with the asterisk? If I do a refresh of the one with the asterisk everything works as it should. Just figured I'd throw that out there in case it wasn't known. Thanks, Brian >>> >
Re: [M100] model 200 dvi cable
Boy, there's just no pleasing some people ;-) OK, so how about plugging a female IDC plug into the back of that solder tab male with a dab of glue to keep them from separating (note that some 40-pin male box headers have pin 20 removed): m - Original Message - From: Brian White To: m...@bitchin100.com Sent: Thursday, November 09, 2017 2:57 AM Subject: Re: [M100] model 200 dvi cable That doesn't fit. That's the only kind I can find so far too. Sometimes in black, but always the same shape. It does just barely fit in a 102, but it's not even close in a 200. Not a matter of shaving or wiggling etc. The one you pictured before has a minimal shroud that hugs the pins closer, which today I can only find in pcb solder form, not idc crimp on. I would love to find that today. Directions that say to seperate and solder 40 individual wires, *in the correct order*, or assemble 2 connectors on a dumb little adapter pcb just to hold 2 connectors... blech. On Nov 8, 2017 11:53 PM, "Mike Stein"wrote: Something like this? https://www.ebay.ca/itm/5Pcs-2-54mm-0-1-Pitch-2x20-Pin-40-Pin-IDC-Male-Box-Header-Flat-Cable-Connector/182237978492?hash=item2a6e3adf7c:g:IVQAAOSw1QpZ9dl~ m From: Brian White To: m...@bitchin100.com Sent: Wednesday, November 08, 2017 11:00 PM Subject: Re: [M100] model 200 dvi cable Found it. Thanks. So it looks like a part that once was off the shelf, but now is not common, but maybe still available with enough looking, or if you simply knew a magic part number. Thanks again for the pic for reference. -- bkw > I sent a picture on Oct. 17. > Normal crimp-on male header plug with twisted wires. >> Does anyone have a picture of a real original dvi cable for model 200? >> Specifically, the plug that goes in the 200? >> ... >> ...what did they give customers originally?
Re: [M100] REX 4.9 Revision 236 bug
Ok. thanks for the report. When REX writes to flash you always get the progress bar. Do you see the progress bar when you suspect rex is writing the RAM to the backup image? On Sat, Nov 11, 2017 at 1:10 PM, Brian Brindlewrote: > Thanks for the reply Stephen, > > Short version is if you follow the steps above REX will overwrite a RAM > image before prompting you to ask if it's ok and when you first launch > REXMGR before you've selected any options. > > > > On Nov 11, 2017 11:36 AM, "Stephen Adolph" wrote: > >> Brian can you more clearly lay out the issue? >> >> >> >> On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle >> wrote: >> >>> Found an interesting little condition today utilizing the Quick Menu >>> Features with REX to backup RAM. If you do things in this order REX will >>> write over the current RAM image before asking permission. I doubt this >>> would cause any major issues for anyone but it's interesting none the less. >>> >>> Select a RAM image, let's call this RAM-A. Do a total wipe / reset of >>> the M100 then reload REXMGR but this time select a different RAM image so >>> say RAM-B. >>> >>> If you at any time hit CTRL-B to backup RAM the image will be written >>> immediately then you will be prompted for confirmation. If you say no - too >>> bad, it already happened. >>> >>> So I tested a few more times just loading REXMGR and noted that the >>> progress bar did it's thing in the right corner of the screen when loading >>> REXMGR. So started over, switched to a different RAM image again and >>> created a file. Verified that indeed just going into REXMGR was causing a >>> write to the RAM image without selecting it or requesting a backup. >>> >>> Seems to be somehow related to REX remembering the last image you were >>> in? The one with the asterisk? If I do a refresh of the one with the >>> asterisk everything works as it should. >>> >>> Just figured I'd throw that out there in case it wasn't known. >>> >>> >>> Thanks, >>> Brian >>> >>> >>
Re: [M100] REX 4.9 Revision 236 bug
Thanks for the reply Stephen, Short version is if you follow the steps above REX will overwrite a RAM image before prompting you to ask if it's ok and when you first launch REXMGR before you've selected any options. On Nov 11, 2017 11:36 AM, "Stephen Adolph"wrote: > Brian can you more clearly lay out the issue? > > > > On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle > wrote: > >> Found an interesting little condition today utilizing the Quick Menu >> Features with REX to backup RAM. If you do things in this order REX will >> write over the current RAM image before asking permission. I doubt this >> would cause any major issues for anyone but it's interesting none the less. >> >> Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the >> M100 then reload REXMGR but this time select a different RAM image so say >> RAM-B. >> >> If you at any time hit CTRL-B to backup RAM the image will be written >> immediately then you will be prompted for confirmation. If you say no - too >> bad, it already happened. >> >> So I tested a few more times just loading REXMGR and noted that the >> progress bar did it's thing in the right corner of the screen when loading >> REXMGR. So started over, switched to a different RAM image again and >> created a file. Verified that indeed just going into REXMGR was causing a >> write to the RAM image without selecting it or requesting a backup. >> >> Seems to be somehow related to REX remembering the last image you were >> in? The one with the asterisk? If I do a refresh of the one with the >> asterisk everything works as it should. >> >> Just figured I'd throw that out there in case it wasn't known. >> >> >> Thanks, >> Brian >> >> >
Re: [M100] REX 4.9 Revision 236 bug
Brian can you more clearly lay out the issue? On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindlewrote: > Found an interesting little condition today utilizing the Quick Menu > Features with REX to backup RAM. If you do things in this order REX will > write over the current RAM image before asking permission. I doubt this > would cause any major issues for anyone but it's interesting none the less. > > Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the > M100 then reload REXMGR but this time select a different RAM image so say > RAM-B. > > If you at any time hit CTRL-B to backup RAM the image will be written > immediately then you will be prompted for confirmation. If you say no - too > bad, it already happened. > > So I tested a few more times just loading REXMGR and noted that the > progress bar did it's thing in the right corner of the screen when loading > REXMGR. So started over, switched to a different RAM image again and > created a file. Verified that indeed just going into REXMGR was causing a > write to the RAM image without selecting it or requesting a backup. > > Seems to be somehow related to REX remembering the last image you were in? > The one with the asterisk? If I do a refresh of the one with the asterisk > everything works as it should. > > Just figured I'd throw that out there in case it wasn't known. > > > Thanks, > Brian > >
[M100] REX 4.9 Revision 236 bug
Found an interesting little condition today utilizing the Quick Menu Features with REX to backup RAM. If you do things in this order REX will write over the current RAM image before asking permission. I doubt this would cause any major issues for anyone but it's interesting none the less. Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the M100 then reload REXMGR but this time select a different RAM image so say RAM-B. If you at any time hit CTRL-B to backup RAM the image will be written immediately then you will be prompted for confirmation. If you say no - too bad, it already happened. So I tested a few more times just loading REXMGR and noted that the progress bar did it's thing in the right corner of the screen when loading REXMGR. So started over, switched to a different RAM image again and created a file. Verified that indeed just going into REXMGR was causing a write to the RAM image without selecting it or requesting a backup. Seems to be somehow related to REX remembering the last image you were in? The one with the asterisk? If I do a refresh of the one with the asterisk everything works as it should. Just figured I'd throw that out there in case it wasn't known. Thanks, Brian