Re: [M100] 3D Printable replacement battery cover for M200

[Lee Olivares]

Resident 3D Printer repair guy here: that’s expensive, you’re looking at .50c 
in material for an FDM PET print. 

It’s about an hour on a Prusa MK3S @ .2mm, I’m fairly certain my buddy gifted 
me an M200 so maybe I can do some comparison shots. 

Printer is hot and ready so I’ll just crank out a sample as a reference, wait 
2hrs before making any purchases.

 - Lee
 - 909.437.0250
 - Destroying technology problems. 

> On Jun 28, 2020, at 20:04, B 9  wrote:
> 
> 
> Very awesome! One of my M200s is missing the battery cover and looks a bit 
> janky with the flexible plastic I cut to fit in its place. I got cost 
> estimates from xometry and shapeways to see how much it'd be and it seemed 
> the cheapest options were $15 to $20 bucks. For example, here's Shapeways' 
> prices, but you have to add $3 for black plastic and then there's shipping on 
> top of that.
> 
> 
> 
> —-b9
> 
>> On Sun, Jun 28, 2020 at 7:15 PM Steve Glenner  
>> wrote:
>> The M200 I just got was missing the battery cover, so I designed up a 
>> replacement and 3D printed it. I donate the model to the community in case 
>> anyone else needs one: https://www.thingiverse.com/thing:4508352
>> 
>> Tandy Model 200 Battery Cover by SteveGlenner
>> I bought a second hand Tandy Model 200, but it was missing the battery 
>> cover. So here is a replacement battery cover. It should be printed with 
>> supports as there are some overhangs but otherwise the settings probably 
>> aren't critical. I printed mine in black ABS so it matches the rest of the 
>> bottom case.
>> www.thingiverse.com
>> 
>> 

Re: [M100] 3D Printable replacement battery cover for M200

[B 9]

Very awesome! One of my M200s is missing the battery cover and looks a bit
janky with the flexible plastic I cut to fit in its place. I got cost
estimates from xometry and shapeways to see how much it'd be and it seemed
the cheapest options were $15 to $20 bucks. For example, here's Shapeways'
prices, but you have to add $3 for black plastic and then there's shipping
on top of that.

[image: image.png]

—-b9

On Sun, Jun 28, 2020 at 7:15 PM Steve Glenner 
wrote:

> The M200 I just got was missing the battery cover, so I designed up a
> replacement and 3D printed it. I donate the model to the community in case
> anyone else needs one: https://www.thingiverse.com/thing:4508352
> 
> Tandy Model 200 Battery Cover by SteveGlenner
> 
> I bought a second hand Tandy Model 200, but it was missing the battery
> cover. So here is a replacement battery cover. It should be printed with
> supports as there are some overhangs but otherwise the settings probably
> aren't critical. I printed mine in black ABS so it matches the rest of the
> bottom case.
> www.thingiverse.com
>
>
>

Re: [M100] 3D Printable replacement battery cover for M200

[Hank Riley]

 Steve,
If possible, please try to take and upload a picture or two of the actual copy 
part you did in black ABS.  Prefer at least one pic to be NOT installed in its 
place on the M200.  Looking for a good shot of the inside where all the tabs 
are and all the performance of your printer will be revealed.
Second, what type of printer do you have and do you like it?  Is it your first 
3D printer what you have now?
Thanks very much for sharing the design with us.
Hank__
   
 On Sunday, June 28, 2020, 10:15:41 PM EDT, Steve Glenner  wrote:  
  The M200 I just got was missing the battery cover, so I designed up a 
replacement and 3D printed it.  

[M100] 3D Printable replacement battery cover for M200

[Steve Glenner]

The M200 I just got was missing the battery cover, so I designed up a 
replacement and 3D printed it. I donate the model to the community in case 
anyone else needs one: https://www.thingiverse.com/thing:4508352
[https://cdn.thingiverse.com/assets/a6/77/57/bf/c5/featured_preview_M200_Battery_Cover.png]
Tandy Model 200 Battery Cover by 
SteveGlenner
I bought a second hand Tandy Model 200, but it was missing the battery cover. 
So here is a replacement battery cover. It should be printed with supports as 
there are some overhangs but otherwise the settings probably aren't critical. I 
printed mine in black ABS so it matches the rest of the bottom case.
www.thingiverse.com

Re: [M100] scored a M200 off craigslist, works except for quote key

[Josh Malone]

Most key problems that I've encountered have either been resolved with
deoxit, or required extensive trace repair on the keyboard PCB due to
corrosion. The key caps come off w/ a standard keycap puller. I'm not sure
if the switches are the same as the 100 keyboard or not; if they are, I
have a parts machine I could pull one from.

On Sun, Jun 28, 2020 at 7:52 PM Steve Glenner 
wrote:

> I found a listing on craigslist for two M100s and one M200 for a really
> good price, so I met the owner and brought 12 AA batteries and quickly
> tested them. Both M100s had ancient batteries in them that were all
> corroded, but with new batteries one of the M100s booted up ok. The m200
> thankfully did not have corroded batteries in it, and when I put in 4 fresh
> AAs it actually powered right up so I was delighted. The M200 is missing a
> battery cover, but I have quickly modeled one and it is printing out right
> now on my 3D printer.
> After I started testing the M200 further, I realize that the quote key
> doesn't seem to be working at all, and the 9 key is mostly not working but
> occasionally registers a 9 if I press hard enough. But nothing for the
> quote key.
> Can anyone recommend how to try and get the quote key working? Can the key
> caps be pulled right off? How much disassembly is needed to get to the key
> switches, and if I can't revive the key switch are they still available?
>

[M100] scored a M200 off craigslist, works except for quote key

[Steve Glenner]

I found a listing on craigslist for two M100s and one M200 for a really good 
price, so I met the owner and brought 12 AA batteries and quickly tested them. 
Both M100s had ancient batteries in them that were all corroded, but with new 
batteries one of the M100s booted up ok. The m200 thankfully did not have 
corroded batteries in it, and when I put in 4 fresh AAs it actually powered 
right up so I was delighted. The M200 is missing a battery cover, but I have 
quickly modeled one and it is printing out right now on my 3D printer.
After I started testing the M200 further, I realize that the quote key doesn't 
seem to be working at all, and the 9 key is mostly not working but occasionally 
registers a 9 if I press hard enough. But nothing for the quote key.
Can anyone recommend how to try and get the quote key working? Can the key caps 
be pulled right off? How much disassembly is needed to get to the key switches, 
and if I can't revive the key switch are they still available?

Re: [M100] VT100 Source / Fonts.h

[John R. Hogerhuis]

Ah, I knew they could be redefined on the NEC 8201A but I didn't realize
they were blank.

I agree it makes more sense to just go with the m100/102 set.

-- John.

Re: [M100] VT100 Source / Fonts.h

[Gary Weber]

Mean to say CHR100.CO implements 131-255.

On Sun, Jun 28, 2020 at 2:24 PM Gary Weber  wrote:

> Thanks, perhaps it might make sense to do a conditional compile for 100
> vs. 102 graphic characters to handle people's preferences.
>
> As far as the NEC goes, on the NEC PC-8201A & 8300, only 3 graphics
> characters are defined (128-130), the rest are blank, which is why my
> CHR100.CO implements 130-255 from the Model 100 so that Model 100-->NEC
> converted programs are pleasant to look at.  Now on the original Japanese
> version of the PC-8201 (note this is without the "A"), it has about half of
> the graphic characters taken up by Kata-kana characters from ROM, but since
> the 8201A & 8300 were the only ones widely sold in the Western world I
> probably wouldn't spend the extra time pulling in all that Kata-kana
> character data.
>
> Gary
>
>
>
> On Sun, Jun 28, 2020 at 2:11 PM John R. Hogerhuis 
> wrote:
>
>>
>>
>> On Sun, Jun 28, 2020, 1:37 PM Gary Weber  wrote:
>>
>>> Let's say someone hypothetically had the gumption (I love that word) to
>>> add the additional font data to the VT100 Terminal source file known as
>>> "Fonts.h", in order to define the additional characters from 128-255 with
>>> the Model T's graphics characters...
>>>
>>> If someone were going to do this, which of the graphics character sets
>>> would be the most desirable, Model 100, or the slightly tweaked Model 102?
>>>
>>
>> Probably 102.
>>
>> But they're almost the same so with enough gumption you could conditional
>> compile both ways.
>>
>> Are you thinking about doing NEC too?
>>
>> -- John.
>>
>

Re: [M100] VT100 Source / Fonts.h

[Gary Weber]

Thanks, perhaps it might make sense to do a conditional compile for 100 vs.
102 graphic characters to handle people's preferences.

As far as the NEC goes, on the NEC PC-8201A & 8300, only 3 graphics
characters are defined (128-130), the rest are blank, which is why my
CHR100.CO implements 130-255 from the Model 100 so that Model 100-->NEC
converted programs are pleasant to look at.  Now on the original Japanese
version of the PC-8201 (note this is without the "A"), it has about half of
the graphic characters taken up by Kata-kana characters from ROM, but since
the 8201A & 8300 were the only ones widely sold in the Western world I
probably wouldn't spend the extra time pulling in all that Kata-kana
character data.

Gary



On Sun, Jun 28, 2020 at 2:11 PM John R. Hogerhuis  wrote:

>
>
> On Sun, Jun 28, 2020, 1:37 PM Gary Weber  wrote:
>
>> Let's say someone hypothetically had the gumption (I love that word) to
>> add the additional font data to the VT100 Terminal source file known as
>> "Fonts.h", in order to define the additional characters from 128-255 with
>> the Model T's graphics characters...
>>
>> If someone were going to do this, which of the graphics character sets
>> would be the most desirable, Model 100, or the slightly tweaked Model 102?
>>
>
> Probably 102.
>
> But they're almost the same so with enough gumption you could conditional
> compile both ways.
>
> Are you thinking about doing NEC too?
>
> -- John.
>

Re: [M100] VT100 Source / Fonts.h

[John R. Hogerhuis]

On Sun, Jun 28, 2020, 1:37 PM Gary Weber  wrote:

> Let's say someone hypothetically had the gumption (I love that word) to
> add the additional font data to the VT100 Terminal source file known as
> "Fonts.h", in order to define the additional characters from 128-255 with
> the Model T's graphics characters...
>
> If someone were going to do this, which of the graphics character sets
> would be the most desirable, Model 100, or the slightly tweaked Model 102?
>

Probably 102.

But they're almost the same so with enough gumption you could conditional
compile both ways.

Are you thinking about doing NEC too?

-- John.

[M100] VT100 Source / Fonts.h

[Gary Weber]

Let's say someone hypothetically had the gumption (I love that word) to add
the additional font data to the VT100 Terminal source file known as
"Fonts.h", in order to define the additional characters from 128-255 with
the Model T's graphics characters...

If someone were going to do this, which of the graphics character sets
would be the most desirable, Model 100, or the slightly tweaked Model 102?

-- 
Gary Weber
g...@web8201.com

Re: [M100] Annotated disassemble of T102 rom

[Brian White]

This is great. Thank you very much.

-- 
bkw

On Sun, Jun 28, 2020, 2:45 PM Erik van der Tier  wrote:

> Hi All,
>
> I was getting a bit tired of all the manual work on cleaning up the
> disassembly, labeling, merging the rest of the comments… So I wrote a small
> Rust program to do all the work for me. I ended up having it clean up the
> layout as well, so everything is really nicely laid out in columns.  Anwaw,
>  now I’ve got a fully labeled and cleanup up assembler file for the T102
> os-rom: https://github.com/eriktier/RomT102Disassembly.
> The files ‘t102rom.asm’ and ‘member.inc’ contain the rom image code. I’ve
> not yet processed all the mem-variables yet.
> I want to keep it fairly ‘authentic’ so I’m limiting myself to 6 character
> labels.
>
> Of course the next step now is to try an assemble it using the VirtualT
> (or alternative) assembler. This is where I’m currently running into some
> issues. I’ve created a project, added the files, also added a linker file
> that defines only a single .aseg (from H to 7FFH). However, when I try
> to build it, nothing happens. No errors, mostly … nothing. So I’m sure I”m
> doing something terribly wrong, but I can’t figure out what. Anyway, I’m
> sure there will still be issues with the asm files themselves.
>
> But… I’m really happy with how this is turning out so far. The code looks
> nice and clean. Once it builds there is mostly a lot of work left to test
> if it actually produces identical output and to start renaming all the
> ‘LH: labels to reasonable names and to finish the mem-variables
> (which is the least of the work).
>
> Cheers,
>Erik
>
>
>

Re: [M100] Annotated disassemble of T102 rom

[Erik van der Tier]

Hi All,

I was getting a bit tired of all the manual work on cleaning up the 
disassembly, labeling, merging the rest of the comments… So I wrote a small 
Rust program to do all the work for me. I ended up having it clean up the 
layout as well, so everything is really nicely laid out in columns.  Anwaw,  
now I’ve got a fully labeled and cleanup up assembler file for the T102 os-rom: 
https://github.com/eriktier/RomT102Disassembly 
.
The files ‘t102rom.asm’ and ‘member.inc’ contain the rom image code. I’ve not 
yet processed all the mem-variables yet.
I want to keep it fairly ‘authentic’ so I’m limiting myself to 6 character 
labels.

Of course the next step now is to try an assemble it using the VirtualT (or 
alternative) assembler. This is where I’m currently running into some issues. 
I’ve created a project, added the files, also added a linker file that defines 
only a single .aseg (from H to 7FFH). However, when I try to build it, 
nothing happens. No errors, mostly … nothing. So I’m sure I”m doing something 
terribly wrong, but I can’t figure out what. Anyway, I’m sure there will still 
be issues with the asm files themselves.

But… I’m really happy with how this is turning out so far. The code looks nice 
and clean. Once it builds there is mostly a lot of work left to test if it 
actually produces identical output and to start renaming all the ‘LH: 
labels to reasonable names and to finish the mem-variables (which is the least 
of the work).

Cheers,
   Erik