Re: [M100] New zebra strips for M100

[Jamie Nichol]

Peter,

Also, I’ll re-run my measurement to see if I was just not paying attention or 
something.  I have a surface plate and most of the metrology goodies available. 
 I’ll put some effort into a proper measurement and report back when I get a 
moment.

—Jamie
On Jul 15, 2021, 8:00 PM -0400, Peter Noeth , wrote:
> Since we don't know the uncompressed height of an OEM strip, we may have to 
> rely on the vendor's recommendation based on compressed height and their 
> materials / process. The clamping tabs on the metal frame do not allow for a 
> great deal of compression distance, so the tolerance of the strips may have 
> to be rather tight.
>
> On a M100, with a working LCD, that I have apart right now, I measure the 
> compressed height of 3.02 to 3.09mm at the accessible corners of the glass. 
> You should relay this measurement to your vendor to get their recommendation 
> for uncompressed height.
>
> Regards,
>
> Peter
>
> > >
> > > -
> > >
> > > Message: 4
> > > Date: Thu, 15 Jul 2021 18:37:14 -0400
> > > From: Jamie Nichol 
> > > To: "=?utf-8?Q?m100=40bitchin100.com?=" 
> > > Subject: Re: [M100] New zebra strips for M100
> > >         =?utf-8?Q?display=E2=80=94_?=any interest?
> > > Message-ID: <8845c77c-aa11-4eca-8280-9231abb52ee9@Spark>
> > > Content-Type: text/plain; charset="utf-8"
> > >
> > > Guys,
> > >
> > > 
> > >
> > > Based on testing so far, it looks like the manufactured height of the 
> > > zebra strips should be 0.3mm shorter than the first prototypes. It seems 
> > > like 3.4mm manufactured height is pretty close to right.
> > >
> > > Before placing a more serious order, I want to be sure the zebra strips 
> > > are generally likely to work, so I?m renewing a call for test displays.
> > >
> > > 

Re: [M100] New zebra strips for M100

[Jamie Nichol]

Peter,

Thanks for taking the time to take a measurement of your display.  You are 
right.  The clamping tabs don’t allow a great deal of adjustment (or clamping 
force — more on this).

The manufacturer recommends 10% compression, with 5% compression minimum.  This 
compression percentage has to take into account a +/- 0.127mm manufacturing 
tolerance for the zebra strip, as well as any tolerance stackup from the bezel 
and glass.

Unless someone has manufacturing drawings for the glass and bezel (could we be 
so lucky?)  The best we can do is measure a number of displays and see where 
they fall.

My display measured 3.3mm glass-to-board (measurements of individual parts 
disassembled, assembled dimension by averaging and subtraction).  After 
conversation with the manufacturer's technical guy, he suggested the 3.74mm 
dimension used for the first prototypes based on his experience and our 
application.

These first tests suggest we might need to be closer to a 5% squeeze, 
especially in light of the measurements you took of your display.

I’m optimistic we can find a dimension that hits the sweet spot for all or 
nearly all of displays in existence.  It will just some displays and some work.

I won’t place a full order until its pretty clear we’re on the right track.  
Thanks again for taking the time to take the measurements.

Out of curiosity, how did you take your measurement?  Is anyone else wiling to 
take the same measurement?

—Jamie
On Jul 15, 2021, 8:00 PM -0400, Peter Noeth , wrote:
> Since we don't know the uncompressed height of an OEM strip, we may have to 
> rely on the vendor's recommendation based on compressed height and their 
> materials / process. The clamping tabs on the metal frame do not allow for a 
> great deal of compression distance, so the tolerance of the strips may have 
> to be rather tight.
>
> On a M100, with a working LCD, that I have apart right now, I measure the 
> compressed height of 3.02 to 3.09mm at the accessible corners of the glass. 
> You should relay this measurement to your vendor to get their recommendation 
> for uncompressed height.
>
> Regards,
>
> Peter
>
> > >
> > > -
> > >
> > > Message: 4
> > > Date: Thu, 15 Jul 2021 18:37:14 -0400
> > > From: Jamie Nichol 
> > > To: "=?utf-8?Q?m100=40bitchin100.com?=" 
> > > Subject: Re: [M100] New zebra strips for M100
> > >         =?utf-8?Q?display=E2=80=94_?=any interest?
> > > Message-ID: <8845c77c-aa11-4eca-8280-9231abb52ee9@Spark>
> > > Content-Type: text/plain; charset="utf-8"
> > >
> > > Guys,
> > >
> > > 
> > >
> > > Based on testing so far, it looks like the manufactured height of the 
> > > zebra strips should be 0.3mm shorter than the first prototypes. It seems 
> > > like 3.4mm manufactured height is pretty close to right.
> > >
> > > Before placing a more serious order, I want to be sure the zebra strips 
> > > are generally likely to work, so I?m renewing a call for test displays.
> > >
> > > 

Re: [M100] New zebra strips for M100 display— any interest?

[Daryl Tester]

On 16/7/21 8:53 am, Brian White wrote:


I am good for at least 2 pairs, more if you need to get rid of more to get
the investment back, up to say 10 pairs? I have 9 machines with the same lcd
but only one currently has any issues with the lcd. So that's one set to use
and one to stock, then a few more for stock wouldn't hurt.
But I also don't need to take them from anyone else from a limited run, so, 2 
pairs?


Likewise - happy to adjust my quantity on demand for the same reasons.

Cheers,
  --dt

Re: [M100] New zebra strips for M100

[Peter Noeth]

Since we don't know the uncompressed height of an OEM strip, we may have to
rely on the vendor's recommendation based on compressed height and their
materials / process. The clamping tabs on the metal frame do not allow for
a great deal of compression distance, so the tolerance of the strips may
have to be rather tight.

On a M100, with a working LCD, that I have apart right now, I measure the
compressed height of 3.02 to 3.09mm at the accessible corners of the glass.
You should relay this measurement to your vendor to get their
recommendation for uncompressed height.

Regards,

Peter


> -
>
> Message: 4
> Date: Thu, 15 Jul 2021 18:37:14 -0400
> From: Jamie Nichol 
> To: "=?utf-8?Q?m100=40bitchin100.com?=" 
> Subject: Re: [M100] New zebra strips for M100
> =?utf-8?Q?display=E2=80=94_?=any interest?
> Message-ID: <8845c77c-aa11-4eca-8280-9231abb52ee9@Spark>
> Content-Type: text/plain; charset="utf-8"
>
> Guys,
>
> 
>
> Based on testing so far, it looks like the manufactured height of the
> zebra strips should be 0.3mm shorter than the first prototypes. It seems
> like 3.4mm manufactured height is pretty close to right.
>
> Before placing a more serious order, I want to be sure the zebra strips
> are generally likely to work, so I?m renewing a call for test displays.
>
> 

Re: [M100] Sneak peak and small first offering of the new 'Backpack Drive'

[Jeffrey Birt]

Hi,

 

The bootstrapping works nice, albeit a bit slow. The Initial Program Loader 
figures out what computer you are using a sends a numerical code to the 
Backpack. It uses the number as an index into the boot sector table to know 
which bootstrap program to use. You can change these settings in the CLI so you 
can load TS-DOS for the M100, or Teeny, etc. The developer just came up with a 
smaller bootstrap that will load in the .CO version of TS-DOS directly which 
should work better for machines with less RAM. We’ll test it out a bit more and 
then add it to GitHub.

 

Jeff

 

From: M100  On Behalf Of Kevin Becker
Sent: Thursday, July 15, 2021 4:23 PM
To: m...@bitchin100.com
Subject: Re: [M100] Sneak peak and small first offering of the new 'Backpack 
Drive'

 

I got a chance to play with my Backpack Drive today for a little bit.  So far 
I'm really happy with it.  It's seems to work great and be pretty easy to use.  
I was only testing on a device with a REX, so I already have TS-DOS but I'm 
really thinking with the built-in bootstrapping, it will be nice for one of my 
other systems with no REX. I haven't tested that yet though.

 

 

 

On Sun, 2021-07-04 at 07:44 -0500, Jeffrey Birt wrote:

Hi all,

 

A friend and fellow list member has developed a SD card storage solution for 
the M100, T102, WP-2 NECs, etc. He sent me one a few months ago and I loved it 
so much I encouraged him to offer them up for sale. It is a small device, about 
25mmx40mmx75mm with the case on. It runs from a single AA battery with a 1025 
coin cell to run the RTC (the RTC allows for time/date stamping file). It works 
like a TPPD2 but ignores calls to change partitions. All TS-DOS commands are 
supported including directory navigation. It also has an extensive CLI 
interface which makes it easy to do things like set the time/date, update 
firmware, etc. 

Hi Everyone. We have a small number of the mini TPDD 'Backpack' drives ready 
for a new home. The documentation has been poured over by four of us, but I am 
sure there are still a few rough edges. Much thanks go out to @48kRAM and 
@Fezzler for helping to improve the documentation and being beta testers. There 
is a Git Hub page up now: https://github.com/Jeff-Birt/Backpack which has lots 
of images too.

I have offered to handle distribution as I am already set up to do so.

 

This first small batch is completely assembled, and it comes with a 3D printed 
enclosure. You will need an AA battery and a smallish SD card, i.e. 4GB, 8GB, 
etc. There are images of the enclosure colors at the link above. The main 
colors are white, grey, and ‘old computer beige’ I did print a case in black 
and one in a pearlescent color that is kind of interesting. The price is $60. 

 

If you want to use it with a WP2 you need a DB25F<->DB9F adapter, The developer 
of the 'Backpack' found a small number of NOS Belkin adapters on eBay and is 
selling them at his cost, $5 in case someone needs one. He also laid up a small 
PCB so folks can build their own if they want. The links to the PCB files will 
be available shortly.

 

Shipping in the USA is $5.50 for one unit, about $7.00 with the adapter by 
first class mail. By Priority Mail it will be $9 for a Small Flat Rate box.  
For international orders I’ll need to your address to get shipping rates.  To 
make thing easier email me directly with your email address, shipping address, 
color of case and if you want an adapter for the WP2. I'll send out a PayPal 
invoice.

 

Keep in mind we have a small number in this first batch let’s give everyone a 
chance to get one. A second small batch of hand assembled boards will be 
available in the near future.

Jeff Birt (Hey Birt!)

 

Re: [M100] New zebra strips for M100 display— any interest?

[Jamie Nichol]

Scott,

Thank you.  Will keep an eye out for lifted pins.

—Jamie
On Jul 6, 2021, 8:55 PM -0400, Scott McDonnell , 
wrote:
> On one the M100s I repaired earlier this year, it was not so much the zebra 
> strips, but that they seemed to have shrunk. I had to apply thick tape inside 
> of the metal LCD frame  to increase the pressure on the strip. I think new 
> zebra strips of the correct height would save quite a few M100s. I am 
> interested in buying 4 of them.
>
> I do not think it will help with missing horizontal lines. I am pretty sure 
> that would be broken traces or lifted pins on an IC. I only have experience 
> with the one that I repaired, so take that with a grain of salt.
>
> Scott M.
>
> From: Jamie Nichol
> Sent: Tuesday, July 6, 2021 8:50 PM
> To: m...@bitchin100.com; m...@bitchin100.com
> Subject: Re: [M100] New zebra strips for M100 display— any interest?
>
> Steve,
>
> Thanks for sharing your experience.  Depends on the display, I guess?
>
> New zebra strips were the answer for the display I have on hand — worked 
> better than adding tape between the glass and bezel.
>
> —Jamie
> On Jul 6, 2021, 8:25 PM -0400, Stephen Adolph , wrote:
>
> > quote_type
> > Jamie,
> >
> > Are the zebra strips a problem?  I guess you are saying that for at least 
> > some LCDs with missing lines, a new zebra strip would help?
> > For me it has usually been a pcb problem.
> >
> > Steve
> >
> >
> >
> >
> >
> > On Tuesday, July 6, 2021, Jamie Nichol  wrote:
> > > quote_type
> > > Hey All,
> > >
> > > I do consumer product R as my day job.  I’ve admired the M100 as a 
> > > brilliant product for the past decade or so, and just picked up a really 
> > > sad example that I’m trying to resuscitate.
> > >
> > > A couple of weeks ago I had a some fine-pitch prototype zebra strips made 
> > > up to fit the M100 LCD (see pic).  The first prototypes are about 0.3mm 
> > > too tall.  I’ll likely have another set of prototypes run with an 
> > > adjusted height.
> > >
> > > I have two questions:
> > >
> > > Is there enough interest here on the list to justify an order of 1000 
> > > pieces or so?  (Likely price is a few dollars each strip — more to come 
> > > on price.)
> > >
> > > Do any of you have dead LCDs that you would be wiling to sacrifice to the 
> > > testing gods?  I would like to see ten or so LCDs improved by an upgrade 
> > > to the new strips before placing a bigger order.
> > >
> > > —Jamie
> > >
>
>

Re: [M100] Sneak peak and small first offering of the new 'Backpack Drive'

[Kevin Becker]

I got a chance to play with my Backpack Drive today for a little bit.
 So far I'm really happy with it.  It's seems to work great and be
pretty easy to use.  I was only testing on a device with a REX, so I
already have TS-DOS but I'm really thinking with the built-in
bootstrapping, it will be nice for one of my other systems with no REX.
I haven't tested that yet though.



On Sun, 2021-07-04 at 07:44 -0500, Jeffrey Birt wrote:
> Hi all,
>  
> A friend and fellow list member has developed a SD card storage
> solution for the M100, T102, WP-2 NECs, etc. He sent me one a few
> months ago and I loved it so much I encouraged him to offer them up
> for sale. It is a small device, about 25mmx40mmx75mm with the case
> on. It runs from a single AA battery with a 1025 coin cell to run the
> RTC (the RTC allows for time/date stamping file). It works like a
> TPPD2 but ignores calls to change partitions. All TS-DOS commands are
> supported including directory navigation. It also has an extensive
> CLI interface which makes it easy to do things like set the
> time/date, update firmware, etc. 
> 
> Hi Everyone. We have a small number of the mini TPDD 'Backpack'
> drives ready for a new home. The documentation has been poured over
> by four of us, but I am sure there are still a few rough edges. Much
> thanks go out to @48kRAM and @Fezzler for helping to improve the
> documentation and being beta testers. There is a Git Hub page up now:
> https://github.com/Jeff-Birt/Backpack which has lots of images too.
> 
> I have offered to handle distribution as I am already set up to do
> so.
>  
> This first small batch is completely assembled, and it comes with a
> 3D printed enclosure. You will need an AA battery and a smallish SD
> card, i.e. 4GB, 8GB, etc. There are images of the enclosure colors at
> the link above. The main colors are white, grey, and ‘old computer
> beige’ I did print a case in black and one in a pearlescent color
> that is kind of interesting. The price is $60. 
>  
> If you want to use it with a WP2 you need a DB25F<->DB9F adapter, The
> developer of the 'Backpack' found a small number of NOS Belkin
> adapters on eBay and is selling them at his cost, $5 in case someone
> needs one. He also laid up a small PCB so folks can build their own
> if they want. The links to the PCB files will be available shortly.
>  
> Shipping in the USA is $5.50 for one unit, about $7.00 with the
> adapter by first class mail. By Priority Mail it will be $9 for a
> Small Flat Rate box.  For international orders I’ll need to your
> address to get shipping rates.  To make thing easier email me
> directly with your email address, shipping address, color of case and
> if you want an adapter for the WP2. I'll send out a PayPal invoice.
>  
> Keep in mind we have a small number in this first batch let’s give
> everyone a chance to get one. A second small batch of hand assembled
> boards will be available in the near future.
> 
> Jeff Birt (Hey Birt!)
>  

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

Had a myriad of crazy issues lashing together my test unit for this..
Somehow I ended up with a tape of level converters where the first three
were good all the rest (dozens) are counterfeit..

Anyway, the serial trace is identical to what I posted before, but here is
the behavior I am seeing shown with debug info:

This is debug information captured from the PDDuino attempting to load
DOS100.CO from UR2.

PDDuino with a cold boot, fails to load DOS100.CO. After loading TS-DOS,
listing a directory (OR making any FDC requests) DOS100.CO loads.

First half of the request is identical:

0 - 5A;Z

0 - 5A;Z

0 - 7

0 - 0

0 - F8

T:7|L:0.

command_status()

return_normal()

R:Norm 0

0 - D

0 - 5A;Z

0 - 5A;Z

0 - 0

0 - 1A

0 - 44;D

1 - 4F;O

2 - 53;S

3 - 31;1

4 - 30;0

5 - 30;0

6 - 2E;.

7 - 43;C

8 - 4F;O

9 - 20

A - 20

B - 20

C - 20

D - 20

E - 20

F - 20

10 - 20

11 - 20

12 - 20

13 - 20

14 - 20

15 - 20

16 - 20

17 - 20

18 - 46;F

19 - 0

1A - 88

T:0|L:1A.

command_reference()

SF:0

Ref: DOS100.CO

This is where the difference is. Left is cold boot PDDuino, right is after
a FDC command. Note the directory information, it seems to stay resident
once loaded but is not initialized on cold boot.

directoryAppend()*directoryAppend(DOS100.CO )*

directory[/] *directory[//]*

->   ->

directory[/] *directory[//DOS100.CO ]*

directoryAppend() end*directoryAppend(DOS100.CO ) end*

return_reference()   return_reference()

returnReference()returnReference()

R:RefR:Ref

upDirectory()upDirectory()

directory[/] *directory[//DOS100.CO ]*

directory[/] directory[//]

1A - 5A;Z1A - 5A;Z

1A - 5A;Z1A - 5A;Z

1A - 1   1A - 1

1A - 1   1A - 1

0 - 30 - 3

1 - FA   1- FA

T:1|L:1. *T:1|L:1D*

command_open()   command_open()

directoryAppend()*directoryAppend(DOS100.CO )*

directory[/] directory[/]

->   ->

directory[/] *directory[//DOS100.C0]*

directoryAppend() end*directoryAppend(DOS100.CO ) end*

directoryAppend(/)   *upDirectory()*

directory[/] *directory[//DOS100.CO ]*

->   *directory[//]*

directory[//]*return_normal()*

directoryAppend(/) end   R:Norm 0

R:Norm 0



Now to look at the code and figure out why...


Brian




On Tue, Jul 13, 2021 at 7:36 PM Brian Brindle  wrote:

>
>
> On Tue, Jul 13, 2021 at 6:18 PM Brian White  wrote:
>
>> Dang, TS-DOS is specifically requesting the name "ROOT", which means I
>> have to make PDDuino use that, and you can't have a real directory named
>> ROOT.
>>
>> There is a macro or const you can edit in the main .ino to change that
>> from "SD:   " to "ROOT  ".
>>
>> Probably won't affect UR2 but if it's baked into something like TS-DOS
>> since 35 years ago, then I just have to go along.
>>
>> Then again... TS-DOS is the one thing that actually works pretty well as
>> it is. So then, no I don't ???
>>
>> Anyway thanks for the captures.
>>
>
> I don't think that's the issue, in this case the capture was taken from
> the perspective of the TPDD so RX is what the TPDD is receiving and TX is
> what it is sending, so it sent ROOT - didn't ask for it and in this case it
> was actually correct.. That was the name of the dir. (Sorry,that was
> probably confusing.) Capture was done with a NADs box since it would be
> successful.
>
> What I was seeing during testing was loading DOS100.CO from the UR2
> didn't an FDC Emulation mode command (M1) and the PDDuino didn't seem to
> know how to proceed without having the dmeLabel set. If you run through
> one cycle with TS-DOS where it does check for FDC, everything works after
> that point. So I think there is something broken in the routine to allow
> for a non FDC Emulation request, although I haven't been able to nail it
> down yet and I did majorly screw everything up trying to "improve"
> debugging before..
>
> Lashing together a modular test setup now with the serial port broken out
> for capture. Should make it easier to get a full capture of the issue.
>
> Brian
>
>