Re: [M100] model 200 dvi cable

2017-11-11 Thread Brian White
Huh. That may be the most practical recipe using parts available today.

On Sat, Nov 11, 2017 at 2:29 PM, Mike Stein  wrote:

> 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

2017-11-11 Thread Stephen Adolph
well that does sound like a bug!

On Sat, Nov 11, 2017 at 4:31 PM, Brian Brindle  wrote:

> 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

2017-11-11 Thread Brian Brindle
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

2017-11-11 Thread Stephen Adolph
236 revision is probably not a good thing to use.

On Sat, Nov 11, 2017 at 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] model 200 dvi cable

2017-11-11 Thread Mike Stein
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

2017-11-11 Thread Stephen Adolph
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

2017-11-11 Thread Brian Brindle
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

2017-11-11 Thread Stephen Adolph
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
>
>


[M100] REX 4.9 Revision 236 bug

2017-11-11 Thread Brian Brindle
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