Re: [M100] Failed "," key

[Brian White]

102 has carbon impregnated silicone rubber domes like calculator or remote
buttons.

With care it's possible to lift the top of the key switch body off and lift
out the rubber dome, and see if the contacts or button are dirty. Maybe use
some deoxit with a q-tip to clean the contacts, maybe clean the carbon pad.

I had a stuck T key where everything looked fine but the carbon pad maybe
just looked worn. I swapped the rubber dome with the right-shift key (a key
that I don't use as much, and has a duplicate on the left anyway, and was
much less worn because all the previous owners probably used it less than T
also) and afterwards not only did the T work, the right shift still worked!

To get the keyswitch apart, I don't know how to verbally describe
everything clearly. I made a video

https://youtu.be/n_oyDYRDYzs


bkw

On Sun, Mar 17, 2024, 10:47 PM Ronald Hudson  wrote:

> Hi Everyone--
>
>
> My 102 has a failed "," key - all the other keys seem to work so I am
> guessing it is a bad key or broken trace.
>
> What say ye?
>
>
> Thanks!
>
> Ron.
>
>

Re: [M100] is there a Model 100 Capacitor kit available (2024)

[Brian White]

These are very nice. Thank you.

bkw

On Sun, Mar 17, 2024, 2:01 PM  wrote:

> I made a color-coded capacitor map 4-5 years ago. It shows you where the
> various caps are, their values and physical size. I am in the process of
> updating it to be more like the newer maps I have created which also show
> polarity and a few of the part numbers shown are obsolete but with the info
> give it is easy to find a replacement.
>
>
> http://www.soigeneris.com/document/vintcom/TRS-80_Model_100_Cap_order_list.pdf
>
>
>
> Jeff Birt (Hey Birt!)
>
>
>
> *From:* M100  *On Behalf Of *Will Senn
> *Sent:* Sunday, March 17, 2024 9:14 AM
> *To:* Model 100 Discussion 
> *Subject:* [M100] is there a Model 100 Capacitor kit available (2024)
>
>
>
> All,
>
> I went hunting today and couldn't find one, but is there a kit available
> still?
>
> Is this still the list I need (https://wiki.console5.com/wiki/TRS80) and
> are they all electrolytic?
>
> C49 10uF16v
>
> C50 10uF16v
>
> C52 1uF 50v NP
>
> C54 10uF16v
>
> C55 10uF16v
>
> C75 47uF16v NP
>
> C76 47uF16v NP
>
> C77 47uF16v NP
>
> C78 3.3uF   50v
>
> C82 4.7uF   25v
>
> C83 470uF   10v
>
> C84 470uF   6.3v
>
> C85 33uF10v
>
> C86 100uF   10v
>
> C90 1uF 50v
>
> C92 0.47uF  50v
>
> C103220uF   10v
>
>
>
> Thanks,
>
>
>
> Will
>
>

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian White]

It should definitely at least be opened and looked at, and really
especially in the case of a 100 vs the other models, it should just be
preemptively recapped and new battery regardless, even if it looks perfect
today.

Because there is no getting around the passage of time. The batt and caps
WILL leak eventually, and in both cases the fluid corrodes all the traces
all around them, and by now the bulk of that theoretical maximum
"eventually" time has already passed. If your machine is somehow still
clean, then you are lucky and now is the time, not after corrosion starts.

It's not a "if it aint broke" situation.

I know it's not convenient and not appealing if the machine is working fine.

In particular, the 100 (vs 102 or 200) are known to have caps that all go
bad by now. 102 and 200 seem to be holding up better on average, as
reported by people that do a lot of repairs. All my own machines had some
level of corrosion started already, but that's only a few machines.

They can be leaking and corroding while still looking fine from a cursory
glance too. No bulging tops or anything. But they leak and it makes an
invisible thin film that spreads far and wide on the surfaces of
everything, and travels under the solder mask sometimes, and the pcb can
sometimes look fine until you look real close and see sort of dark areas,
and when you touch the soldermask there, it flakes up and you see the dark
area is all corroded copper sometimes eaten all the way through. The
machine runs perfectly with no hint of a problem right up until some trace
finally gets the last connecting copper atom oxidized, unless one of the
caps also goes out of spec enough to make the machine unstable. And then
you discover it's not just one trace but a bunch all over the place.

The good news is it's actually all fixable even in really bad cases. Big
old through-hole stuff, even densely packed, is big and easy by todays
standards.

bkw

On Sat, Mar 16, 2024, 11:52 PM Will Senn  wrote:

> This sounds important. So far as I know, mine's original equipment. Do I
> need to be worried?
>
> Will
>
> On 3/16/24 8:21 PM, Doug Jackson wrote:
>
> Every time I see one of those evil NiCad batteries, I replace it with a
> 0.5F supercap.
>
> I have never had an issue with my M100, or with the Olivetti equivalent
> (number escapes me at the moment)
>
> Having said that, the oldest would have been 8 years ago, so I don't have
> the same 30years of experience regarding leaking characters.
>
> Doug
>
> On Sun, 17 Mar 2024, 11:44 am Brian K. White, 
> wrote:
>
>> You can run plugged in to the wall for all normal random on/off
>> operating times without worrying about it too much, IE, all day long for
>> 8 to 12 hours or whatever, and for multiple days in a row, if unplugged
>> when turned off.
>>
>> And you can leave it plugged in turned on or off overnight for one night
>> to a few days.
>>
>> And you can even get away with exceeding those pretty badly once in a
>> while.
>>
>> What you want to avoid is plugging it in and leaving it plugged in 24/7
>> for weeks or months or years, whether it's on or off.
>>
>> The harm is the charging circuit that charges the internal nicd battery
>> soldered on the motherboard. The battery is not a lead/acid or gel cell
>> that has a float value where it can just stay floating at a certain
>> value forever, and the charging circuit is not a smart modern battery
>> manager that knows how to stop charging when the battery is full, it
>> just keeps on supplying a bit higher voltage than the the cells own
>> voltage, and current just keeps on flowing backwards through the cell,
>> and sooner or later this kills the battery by a couple different
>> possible mechanisms from plain heat & pressure making it leak and cook
>> off all the electrolyte, to things like the electrolysis process like
>> electroplating, eating away all of one plate and building gunk up on the
>> other.
>>
>> It's pretty forgiving so you don't have to be super careful. You can
>> *mostly* never even think about it, and a normal random usage pattern
>> will just naturally be fine. Just don't plug it in and forget about it
>> for a year.
>>
>> It doesn't touch the AA's and it doesn't matter if the machine is turned
>> on or turned off.
>>
>> Now that you make me run through it all like that, I realise this might
>> finally be be an actual valid useful reason to install a supercap
>> instead of a new nimh cell.
>>
>> Mostly there is no point, because both a cap and a battery will only
>> last about the same number of years, and both will start to leak
>> corrosive juice after about the same number of years. A cap is not
>> harmed by being allowed to go all the way dead (which a battery is), nor
>> by being allowed to stay dead for a long time (extra especially bad for
>> a battery), but even a battery that has been so badly treated still
>> supplies more standby time than a brand new perfect cap. All in all, no
>> point.
>>
>> But one difference that 

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian White]

Same.

bkw

On Sat, Mar 16, 2024, 11:12 PM Gregory McGill 
wrote:

> Is the same behavior with nimh as with NiCAD?
>
> On Sat, Mar 16, 2024, 6:46 PM Brian K. White  wrote:
>
>> One problem with batteries for sure is you can't tell a junk future
>> leaker by just looking at it. Even if the actual cells are stamped with
>> a quality manufacturer name, they could be fake or they could be real
>> but rejects, or they could be illegitimate extra production "after hours
>> runs" from the same plant in china or wherever that makes the real ones,
>> or real but aged-out old stock repackaged and sold as new etc.
>>
>> And there is essentially no way to detect or prove any of that by
>> examining the battery in your hand. If it's visibly corroded or doesn't
>> take a charge or something, you can tell that obviously, but if it
>> visually looks perfect, and functions within spec, that doesn't prove
>> anything except that it looks good and works today. It could be utter
>> garbage that dies and leaks in 1 year or 5 years.
>>
>> The only hope that it will actually last the promised number of years
>> before starting to leak, is to buy it from a source that you can trust
>> to be very careful with their own sources. No ebay, no amazon, certainly
>> no aliexpress, it must be someone who will actually care if any
>> customers ever start giving them a bad reputation.
>>
>> I guess all that is true for caps too really, so maybe no difference on
>> that front.
>>
>> --
>> bkw
>>
>> On 3/16/24 21:21, Doug Jackson wrote:
>> > Every time I see one of those evil NiCad batteries, I replace it with a
>> > 0.5F supercap.
>> >
>> > I have never had an issue with my M100, or with the Olivetti equivalent
>> > (number escapes me at the moment)
>> >
>> > Having said that, the oldest would have been 8 years ago, so I don't
>> > have the same 30years of experience regarding leaking characters.
>> >
>> > Doug
>> >
>> > On Sun, 17 Mar 2024, 11:44 am Brian K. White, > > > wrote:
>> >
>> > You can run plugged in to the wall for all normal random on/off
>> > operating times without worrying about it too much, IE, all day long
>> > for
>> > 8 to 12 hours or whatever, and for multiple days in a row, if
>> unplugged
>> > when turned off.
>> >
>> > And you can leave it plugged in turned on or off overnight for one
>> > night
>> > to a few days.
>> >
>> > And you can even get away with exceeding those pretty badly once in
>> > a while.
>> >
>> > What you want to avoid is plugging it in and leaving it plugged in
>> 24/7
>> > for weeks or months or years, whether it's on or off.
>> >
>> > The harm is the charging circuit that charges the internal nicd
>> battery
>> > soldered on the motherboard. The battery is not a lead/acid or gel
>> cell
>> > that has a float value where it can just stay floating at a certain
>> > value forever, and the charging circuit is not a smart modern
>> battery
>> > manager that knows how to stop charging when the battery is full, it
>> > just keeps on supplying a bit higher voltage than the the cells own
>> > voltage, and current just keeps on flowing backwards through the
>> cell,
>> > and sooner or later this kills the battery by a couple different
>> > possible mechanisms from plain heat & pressure making it leak and
>> cook
>> > off all the electrolyte, to things like the electrolysis process
>> like
>> > electroplating, eating away all of one plate and building gunk up on
>> > the
>> > other.
>> >
>> > It's pretty forgiving so you don't have to be super careful. You can
>> > *mostly* never even think about it, and a normal random usage
>> pattern
>> > will just naturally be fine. Just don't plug it in and forget about
>> it
>> > for a year.
>> >
>> > It doesn't touch the AA's and it doesn't matter if the machine is
>> > turned
>> > on or turned off.
>> >
>> > Now that you make me run through it all like that, I realise this
>> might
>> > finally be be an actual valid useful reason to install a supercap
>> > instead of a new nimh cell.
>> >
>> > Mostly there is no point, because both a cap and a battery will only
>> > last about the same number of years, and both will start to leak
>> > corrosive juice after about the same number of years. A cap is not
>> > harmed by being allowed to go all the way dead (which a battery is),
>> > nor
>> > by being allowed to stay dead for a long time (extra especially bad
>> for
>> > a battery), but even a battery that has been so badly treated still
>> > supplies more standby time than a brand new perfect cap. All in
>> all, no
>> > point.
>> >
>> > But one difference that matters, a cap should not be harmed by the
>> > crudeness of the charging circuit. A cap will just charge up and
>> stop
>> > conducting and won't care about the charging supply at all. No
>> current

Re: [M100] Tandy Portable Disk Drive 2 service manual PDF now available.

[Brian White]

I had that thing about request format 0x47  backwards. Tpdd1 ignores 0x47,
tpdd2 responds to it, which makes more sense, since it's just like several
other commands on tpdd2. Doesn't matter to anyone but just for the record
to correct saying it backwards before.

bkw

On Wed, Jan 10, 2024, 11:49 AM Brian K. White  wrote:

> Curiouser, I added support for request 0x47, including the detail that
> it only works if dl2 is in strict tpdd1 mode.
> In default or explicit tpdd2 mode, it ignores the command the same as a
> real TPDD2 does.
>
> When I run with strict tpdd1 emulation, PAKDOS sends the 0x47 status
> command once per directory list. As expected.
>
> When I run without that, which defaults to enabling TPDD2 features, and
> ignores 0x47 as unrecognized, PAKDOS tries 0x47, only waits a few ms for
> the response and then sends a normal 0x07.
>
> So, it's not the case that James just mistakenly thought that 0x47 was
> the status command. He sends it, and then only if that fails, then does
> 0x07.
> So it was even more deliberate than it already looked. Don't ask me why!
>
> --
> bkw
>
> On 1/10/24 10:49, Brian K. White wrote:
> >> The TPDD2 service manual in all of its glory...
> >
> > While going through starting to update dl2 with all this new info, I
> > also tried a new (old) DOS I recently found called PAKDOS by James Yi.
> > http://tandy.wiki/TPDD_client:PAKDOS
> >
> > And it tries to use a command 0x47 every time it does a directory
> > listing.
> >
> > Well that's a new one. Never saw request format 0x47 anywhere before.
> >
> > I figured out what it is and it's weird.
> >
> > PAKDOS apparently expects no-response might be possible since it
> > doesn't care that dl2 ignores it, and the directory listing works with
> > no hint of any problem on the portable side.
> >
> > The command is given with no parameters or payload data, and wrapped
> > in a valid Operation-mode packet, IE, the packet has all components
> > and is consistent.
> > format byte is 0x47
> > there are no params or data, and the len byte is 0x00, so that fits,
> > and there is a checksum byte 0xB8 after that, which is correct.
> > So, it's not just random data.
> >
> > The first guess maybe it's a synonym for drive_status, because:
> > * 0x07 is drive status
> > * drive status has a payload length of 0
> > * for TPDD2, some commands do have an alternate version that is the
> > normal format code plus 0x40 to make the command operate on bank1
> > instead of bank0.
> >
> > all checks out and adds up
> >
> > But a real TPDD2 does not respond to this command.
> >
> > ... BUT a TPDD1 DOES, and it indeed does the drive status command.
> > It doesn't just respond with a valid standard 0x12 return format for
> > "ok" but for instance if the disk is ejected it says so.
> >
> > Whatever! Easy enough to handle, just completely unexpected that a
> > tpdd1 would respond to a 0x4n request and a tpdd2 does not!
> >
>
>

Re: [M100] Tandy TPDD-1 Drive

[Brian White]

There are a few different options.

1 You don't really need the disk. There are several tpdd clients that do
the same job the same or better than that particular one. From windows you
can use github.com//bkw777/tsend or from mac or linux you can use
github.com//bkw777/dl2 to install ts-dos.

2 You can create the disk with github.com//bkw777/pdd.sh from a disk image
(included). It does require linux or mac and an uncommon serial adapter to
connect the drive to a pc, but there are links to a few sources.

3 I think at least arcadeshopper.com sells copies.

What you really want though is to get a rex# which includes an rom version
of ts-dos, so you get the nicest dos without using any ram and you never
have to bother with the serial installer process. Google bitchin100 rexsharp

If the previous owner hasn't replaced the belt then you need that too.
Available from many sources, just gooogle frw8.5 belt.

It's pretty finnicky getting a tpdd1 apart and back together but I think
Jeff Birt has a youtube video showing it. yt channel is "hey birt"

-- 
bkw

On Thu, Jan 11, 2024, 1:47 PM Scott Joyce  wrote:

> Hello Everyone,
> I recently acquired a TDPP1 drive and just purchased a cable but am now
> finding I need the Utility/Boot disk.  I would appreciate any help in
> getting a copy of the disk so I can get this little gem functioning
> properly again.  I'm located in Belmont New Hampshire USA.
> Thanks,
> Scott
>

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[Brian White]

Absolutely.

I've also wanted to dump the roms from all the fb100 clones someday just to
see if they're identical or not. They're probably all the same code, but it
is possible.

By now I have one each of tpdd1 (a few actually), tpdd2, fb100, fdd19, and
purple computing d103. So if I could manage to follow your recipe I am in a
position to dump them all.

bkw

On Tue, Jan 9, 2024, 6:54 PM Darren Clark  wrote:

> TPDD2 firmware dumping - breaking this into a new thread.
>
> It would be interesting to see if we can use the command 'Request Block'
> from page 89 to read the ROM of the CPU...
>
> I dumped the ROM of the TPDD1 and got a good start at reverse
> engineering it and documenting it here
> https://github.com/BiggRanger/Tandy_PDD/tree/master can't believe that
> was over 7 years ago!
>
> Looking at the schematic in the PDF, the HD6301V1 starts up in mode 6
> just like with TPDD1, that places the firmware/ROM between 0xF000 and
> 0x in memory.
>
> Is there anybody with a TPDD2 willing to try and dump 4K of data from
> 0xF000 to 0x and send it to me so I can start reverse engineering
> and documenting it? It should look somewhat similar to this
> https://github.com/BiggRanger/Tandy_PDD/blob/master/PDD1.HEX if it is
> outputting good data.
>
>  From page 89 GET THE DATA FROM THE DRIVE'S MEMORY
>
> Request Block - 5A5A 32 04 01 F000 40 (checksum) and see what block of
> 64 bytes comes out.
>
>
> Darren Clark
>
>
> Here is a memory map of the TPDD1 from my reverse engineering earlier:
>
> ;--
> ;Memory Map of PDD (using mode 6):
> ;--
> ;-001FInternal Registers (see below)
> ;0080-00FFInternal RAM
> ;4000-4003CPLD (Glue Logic + Hardware IO Control)
> ;8000-87FFExternal RAM (2K)
> ;F000-Internal ROM (4K)
> ;--
> ;I/O ports
> ;Port.BitI/OPin#IDFunction
> ;--
> ;Port1.B0InputPin18P10CTS
> ;Port1.B1InputPin19P11DSR
> ;Port1.B2OutputPin20P12RTS
> ;Port1.B3OutputPin22P13DTR
> ;Port1.B4OutputPin23P14PS Alarm (Low Battery LED)
> ;Port1.B5OutputPin24P15LED101 (Drive Access LED)
> ;Port1.B6OutputPin25P16To MA7340
> ;Port1.B7OutputPin26P17SCAN
>
> ;Port2.B0InputPin11P20Mode (pulled Low)
> ;Port2.B1InputPin12P21Mode (pulled Hi)
> ;Port2.B2InputPin13P22(SCI) CLKOUT from CPLD for BAUD rate
> ;Port2.B3InputPin14P23(SCI) /RXD
> ;Port2.B4OutputPin15P24(SCI) /TXD
> ;--
>
>
>
>

Re: [M100] MiniNDP 512 (was Re: FlexROM with REX#)

[Brian White]

https://gist.github.com/bkw777/52d85d89eeff8445cc667685d05ea94d

includes some links to sources as well as specs

26 awg or 0.4mm


bkw

On Tue, Nov 28, 2023, 8:59 PM Mike Stein  wrote:

> I probably missed it and can't easily find the previous discussion,
> but what diameter wire do you suggest? I see the hole size 0.6mm/24
> mil but not the wire gauge.
>
> Thanks!
>
> On Tue, Nov 28, 2023 at 7:56 PM Brian K. White 
> wrote:
> >
> > You have lost me.
> >
> > If you want to dump or re-write the flexrom, you can just do it it it's
> > programming adapter.
> >
> > I thought you wanted to dump the original rom?
> >
> > And if you want to avoid all the hardware actions while changing the
> > main rom, that's exactly what REX Classic allows. It's purely software
> > once you set that up, and even if you botch both primary and secondary
> > images, you only need to open the option rom compartment instead of the
> > whole machine to revert to the internal eeprom.
> >
> > If you have a soic-28 test clip, you *might* be able to program the
> > eeprom without removing from the machine. Mostly it should be ok, the
> > board allows the programmer to drive /WE for instance, it's definitely
> > ok to program the chip directly with a test clip if the board is not
> > installed in the machine. But but one thing I don't know is, if the
> > board is installed in the machine, all the pins are connected to the
> > bus. Mostly that should be ok but one thing I don't know is what happens
> > when the programmer tries to provide power on the vcc pin? Does it power
> > up the whole machine? Even with the memory power switch turned off,
> > which normally kills everything, this would be injecting power to the
> > rail from a point "inside the walls".
> >
> > If you're worried about the legs, and you're right that it would be a
> > pain to repair a loose one after the frame was cut away, I now actually
> > prefer gold plated plain brass wire.
> > https://gist.github.com/bkw777/52d85d89eeff8445cc667685d05ea94d
> >
> > The advantages are,
> > - just wire, no special shapes to cut off or anything, no single special
> > supplier
> > - a few feet makes hundreds of 6mm legs
> > - the wire is round, so there is no problem with it rotating when
> > loosened and resoldered
> > - gold plated
> > - repair/replacement of a broken leg is trivial
> >
> > The disadvantages are,
> > - each leg has to be soldered individually, no one-piece connector or
> > frame like with a normal pin header
> > - no simple supplier to point to, it's such a generic thing that there
> > is no part number or such, except in large quantities from bulk
> > suppliers. The various suppliers (for small quantities) I've found have
> > all been transient like Etsy or Ebay links that don't work a year later.
> > And it's easy to end up with gold colored aluminum wire or brass wire
> > that isn't gold plated (which starts tarnishing within a year), since no
> > one selling the stuff is writing their descriptions for electronics use.
> > I have also gotten wire from aliexpress that was thinner than claimed,
> > which ends up being too thin and weak despite you buying the correct awg
> > or mm number.
> >
> > But if you do get some, then you have a lifetime supply after that.
> >
> > The preloaded bom carts with the pcbs have the sil leadframes just
> > because it's an actual part that can be ordered normally along with
> > everything else, and is both a little cheaper and a little more
> > convenient to solder than the MillMax or Keystone micro pins which could
> > also be ordered as part of the bom.
> >
> > --
> > bkw
> >
> > On 11/28/23 13:32, runrin wrote:
> > > This is a good idea, but I've already got my new EEPROM in there and
> > > every time I remove it and put it back in, I get worried I'll break off
> > > one of the legs and have to resolder it.
> > >
> > > The leadframes used to make DIP pins on Brian's FlexROM adapter board
> > > work well, but I really don't want to have to replace them when I
> > > inevitably break one off.
> > >
> > > Would you use a BASIC script to do this Mike? Just a loop to PRINT each
> > > byte to the COM port?
> > >
> > > On Tue, Nov 28, 2023 at 11:45:10AM -0500, Mike Stein wrote:
> > >> Why not just dump it out of the M100 directly?
> > >>
> > >> On Tue, Nov 28, 2023 at 9:50 AM Brian K. White 
> wrote:
> > >>>
> > >>> On 11/27/23 11:48, runrin wrote:
> >  Do you know if it's possible to dump the original ROM using the
> >  programming adapter for the FlexROM 100?
> > >>>
> > >>> Maybe.
> > >>>
> > >>> There are two things to worry about and I'll just think out loud
> right here.
> > >>>
> > >>> 1
> > >>> The programming adapter presents a pinout for a 28C256, not a 27C256
> or
> > >>> mask rom. Those are only a couple wires different, but then again,
> since
> > >>> it's just for reading, and the read cycle is the same, you could just
> > >>> tell the programmer that it's reading a 28C256 (force it, override
> chip
> > >>> id 

[M100] breadboard node datapac

[Brian White]

I am absolutely certain that every one of these connections is correct.

https://photos.app.goo.gl/mzJbKM3cWJ8AgGic8


This is essentially a MiniNDP (which is essentially a Node Datapac but with
a single large sram), minus the battery stuff, in the form of all
through-hole dip parts on a breadboard.

I think I deduced how the 2-bank 512k rampac is supposed to work by a
combination of studying the single bank 256k datapac and capturing bus
traffic from ram100.co when it tries to access the 2nd bank.

I already drew up an updated schematic and pcb and ordered some pcbs, but
still I figured since I actually have dip versions of all the chips, and
it's only 5 chips plus the sram, I'd try to breadboard the whole thing and
use that to see if it works first. Start with a simple copy of the
known-working 256k circuit, then once that is verified, add my guess at the
few changes to support bank1 and 512k.

For some strange reason I hesitate to actually try it now. Might have
something to do with the 3 or 4 errors I already found and corrected along
the way.

-- 
bkw

Re: [M100] Model T clock doubler

[Brian White]

Hah, all of my own boards get to about v 12 before I'm mostly happy, and
then continue polishing for several more. It's almost like software, never
really done.

bkw

On Sun, Nov 19, 2023, 7:56 PM Stephen Adolph  wrote:

> I jumped the gun a bit, needed to redo the boards and change the circuit.
>
> On Sunday, November 19, 2023, Brian K. White  wrote:
>
>> None of the file links work, but I'm sure it *will* be awesome.
>> Sounds super.
>>
>> On 11/18/23 10:54, Stephen Adolph wrote:
>>
>>> Hi everyone,
>>>
>>> I've been working towards finishing off my project for increasing the
>>> speed of the Model T laptops.  The idea is to create a (relatively) easy to
>>> make and install solution that allows the user to switch the clock rate
>>> from 2.5 MHz to 5 MHz.
>>> This is really nice on the 40x8 LCD machines.
>>>
>>> The universal software command to switch clock rate is
>>> OUT 85,1 for 2x mode and
>>> OUT 85,0 for 1x mode.
>>>
>>> Of course the Model T is not designed for this, but in my experience so
>>> far, it seems reliable.  I really like the upgrade and plan to install in
>>> all my laptops. Being able to operate in nominal clock mode is of course
>>> very useful because you may find some software to be incompatible.
>>>
>>> Models I have upgraded to date:
>>> * M100 (NA, early variant, not UK)
>>> * T102
>>> * T200
>>> * NEC PC-8201/8201a
>>> * Olivetti M10
>>>
>>> I am publishing all the information needed to DIY this upgrade. I don't
>>> have any plans to make these upgrades.  Consider this upgrade only if you
>>> are comfortable with soldering surface mount parts, and with making minor
>>> modifications to your laptop.
>>>
>>> Upgrades that are done and in the process of documentation are M100,
>>> T200, NEC.  Upgrades that need a new PCB design still are T102 and M10.
>>> All information will be at this site:
>>>
>>> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T <
>>> https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T>
>>>
>>> I am publishing
>>> * PCB designs for the clock doubler board (there are a few variants)
>>> * schematic
>>> * bill of materials for parts you need
>>> * documentation for building the clock doubler
>>> * installation documentation per laptop
>>>
>>> Things I have discovered while developing this;
>>> 1.  Power consumption goes up by about 20% when you run at 2x clock.
>>> 2.  Depending on the speed of your SRAM,  you may need to implement a
>>> modification to speed that up.  Each model has a specific mod you need.
>>> 3.  In M100 with the custom socket pinout, in most cases you need to
>>> upgrade your Main ROM to something faster.  This usually involves an
>>> adapter board and an EPROM.
>>> 4.  In the Tandy 200, one must slow down the machine temporarily to
>>> access the RTC.  There is a specific change for that.
>>>
>>> Anyhow, as I complete a particular laptop, I'll post the needed files.
>>>
>>> Hopefully this will be of some interest for those inclined to play
>>> around with hardware.  I have no problem if anyone wants to take the design
>>> and improve it or change it.
>>>
>>> Feel free to contact me directly with questions.
>>>
>>> cheers
>>> Steve
>>>
>>>
>>>
>>>
>>>
>> --
>> bkw
>>
>>

Re: [M100] PBBS in BASIC - for Model T

[Brian White]

Could use a dvi or a rampac/datapac at the same time. They both do file
storage via system bus.

bkw

On Wed, Nov 1, 2023, 11:57 AM Alex ...  wrote:

> It's not that surprising. The machine has a built in modem and battery
> backup. You could just hook it up in a telco closet and have a BBS up in no
> time.
>
> Don't know how you'd use a TPDD at the same time since it hogs the serial
> port. Support for saving files to cassette would probably be more useful.
>
> On Wed, Nov 1, 2023, 01:04 Hiraghm  wrote:
>
>> I was just visiting a website of BBS links by platform, when I was
>> shocked to come across an entry for PBBS... for the Model 100... in BASIC.
>>
>> here's a link to the site's entry on the M100 PBBS:
>>
>> http://software.bbsdocumentary.com/TANDY/MODEL100/PBBS/
>>
>> it is not surprisingly very limited.. but it's written in BASIC...
>>
>> There's also a CP/M version of PBBS, but it appears to be written in
>> assembler, not BASIC:
>>
>> http://software.bbsdocumentary.com/AACPM/CPM/PBBS/
>>
>>
>> I thought some on here might be interested in toying with it. Maybe
>> customizing it to work with the REX or TDDP drive to expand its
>> capabilities.
>>
>> I'm just boggled that someone wrote a BBS for the Model 100.
>>
>>

Re: [M100] file storage, still

[Brian White]

http://tandy.wiki/Model_T_Serial_Cable

Any of those. I suggest the pccables one right at the top, only for the
*slight* differences that it's only 6ft instead of 10ft, and connects the
dcd pin while a couple others don't.

If you're not sure about your usb-serial adapter, any of the ones linked
there are good too.

But for instance the startech one, even though it doesn't connect the dcd
pin, and is 10ft, is available on amazon for only $5 and maybe you have
free shipping. (follow the link from their site to "buy from reseller")
It's a bit nicer of a cable physically, like maybe will take longer to wear
out, and the dcd thing will probably never *actually* matter.

ok getting into the weeds about something that will never matter...

Definitely tpdd doesn't look at dcd. That pin is used by some things to
detect if a device is on-line or not. You may never use anything that cares
about that pin, but why not have it if you have the opportunity to choose
anything? But an example would be, you are running some kind of bbs server
software on the m100, and using a comm program like procomm plus on a pc,
the dcd pin makes the bottom of the screen status display say "on-line" as
if you had dialed up with a modem, and the modem established a good
carrier, dcd = carrier detect.

That's what I mean by, it's a thing, technically, but really, never gonna
matter, shrug, and yet, if you have to pick something and they all seem the
same, that is a slight difference.

-- 
bkw

On Thu, Oct 12, 2023, 4:25 PM Peter Vollan  wrote:

> Well TS-DOS says "communication error" instead of just "drive not ready"
> when I connect it to my Linux box running dl-plus. You said that means I
> have an inadequate null modem cable. I know you did this already but I
> can't find the reference: where could I get the cable or just an adaptor
> that connects the right pins?
>

[M100] REXCPM battery

[Brian White]

Took some measurements

This is with the BAT54C diodes.

While not installed in 100:
BATT  2.99v
RAM_RST  2.91v 7uA
SRAM VCC  2.76v


While installed in 100, power on, wall power, original tandy 6v adapter:
RAM_RST  4.85v
BATT, installed  3.0v
BATT, not installed  3.65v 0.5uA



bkw

Re: [M100] NODE DATAPAC

[Brian White]

Should be no problem. I wasn't sure how best to do a case yet so that's why
it has holes in the corners. One basic option is just a cover on the out
side held on your only by glue or mounting tape, and using the holes for
registration or alignment, and maybe also for glue, or just friction, make
the pin large enough to fit tightly. But the problem there is the pin would
be weak if FDM printed. It would break right off because of layer lines.

The cover would be flush with the perimeter of the PCB, not wrapping around
it.

Or there is enough space between the PCB and the computer to get case
material all the way around, and still not interfere with the printer or
serial ports either. For that, for simplicity I was thinking of a single
piece that slides over from the top and uses the holes to snap in place
with little bumps inside. This would need to be printed vertically so that
the  which might not look the best or be the easiest to print successfully,
but will make the layer lines perpendicular to the PCB, the lines would
make solid loops around the PCB and the front side will not break apart
from the back side.

 Or maybe a 2 piece clam shell where each half is like the front-only piece
I described above. Each side would have little bumps to register in the
holes but not go all the way through.

The problem with the glued parts is it complicates the battery. The part
either needs to be removable to expose the battery, or it needs some kind
of opening, including some way to eject the battery.

The one-piece idea could be totally enclosed and you access the battery by
just sliding the entire cover back off. It would use only the detents to
hold itself in place no glue or mounting tape.

I haven't really tried to figure out a case yet, these are just the hazy
pre-ideas.

The holes might possibly be usable with M2 or M2.5 screws too but honestly
I figured everything would be a bit too small for screws. They make screws
that small but there isn't much material to screw *into*.

Another possibility I though I'd try is maybe just the outside cover with
M3 screws to bite into the PCB itself. But the PCB is so thin that that
would only be a couple threads and then the screw would poke out the back,
and I don't want any sharp pokies on the back.

Maybe yet another idea is the one-piece slide over cover, with two screws
at the top that all they do is retain the cover acting as pins, instead of
relying on bumps acting as detents in the holes, since those might simply
grind away after a few cycles.

bkw

On Tue, Sep 12, 2023, 12:40 PM Ben Wiley Sittler 
wrote:

> That's great work! Is there enough clearance around the modern version
> that a 3d-printed case could fit?
>
> On Tue, Sep 12, 2023, 01:47 Brian K. White  wrote:
>
>>
>> The unverified schematic I arrived at from beeping out an original NODE
>> DATAPAC is now verified.
>>
>> Based on that best guess original schematic I made a new schematic that
>> uses 1 256k sram instead of 8 32k sram, but otherwise replicates the
>> original circuit with the way the binary counters and bus latch works.
>>
>> And the new device works!
>>
>> https://github.com/bkw777/NODE_DATAPAC#minindp
>>
>> This is kind of a pointless device today because in most cases a
>> Backpack is more useful and practical.
>>
>> But here are a few distinguishing points:
>> * The driver software is only 1.4k on a 100, 1.2k on a 200, vs ts-dos
>> over 5k. Teeny is only 0.75k but lacks features (can't format a disk or
>> even list the directory)
>> * The DATAPAC or MiniNDP uses the system bus, leaving the serial port
>> available for other use.
>>
>> --
>> bkw
>>
>

Re: [M100] Tandy 200 RAM banks and TS-DOS

[Brian White]

The doc I linked has all the instructions for teeny.

You'll have to be more specific about what you tried before anyone can say
what's wrong, because the doc is correct. Just a bit flowery.

Wait the only custom main rom I know of with teeny built in is LibROM, so
for that you have to consult both the normal original teeny docs, and the
LibROM page for her modifications.
https://sarahkmarr.com/retromodel100.html

and before that, do you actually know if you have a proper serial
connection and tpdd server working? (By using some other tpdd client and
having it work on the same machine).

bkw

On Tue, Aug 15, 2023, 1:42 PM Lee Osborne  wrote:

> Does anyone have instructions for TEENY? I've got a custom (on board, not
> option) ROM in my Model 100 that has it built in, and using it to load/save
> to/from my Backpack would be very handy. I assume it's all command line
> interface, but my attempts to guess the commands have been unsuccessful.
>
> Googling has drawn blanks so far.
>
> Lee
>
> On Tue, 15 Aug 2023, at 13:32, CopyP wrote:
>
> This is incredibly helpful, so thanks! I was trying to work out how to
> load TEENY rather than TS-DOS and was wondering if I was just missing it
> from the BackPack manual. I probably was! But that explanation gives me a
> good base to work from, not least because I really only need very basic
> functions for saving onto the BackPack, and TEENY can do that.
>
> The extra RAM means that in fact I should be able to break most of what I
> am using the 200 for down into two pieces of work instead of three or more
> - which makes it all rather easier to work with!
>
> And that is a fascinating way of working with data between RAM banks.
> That’s not a method I would have thought of at all. I had been considering
> a rather more basic form of RAM usage for document storage, I know, for
> example, that I could simply use the RAM banks to store parts of my work
> and copy each over to (say) bank 1 just to save. I could live with that as
> long as bank 1 has enough space!
>
> Thanks again!
> Andy
>
>
>
> -
>
>
>
> A few things:
>
> --
>
> I believe backpack allows you to put any loader you want on the sd card.
>
> I don't know the exact mechanism, but for example a similar project I
> have https://github.com/bkw777/PDDuino
> lets you bootstrap anything you want by just saving it to a special file
> name on the sd card.
>
> You get any of the loader files from here
> https://github.com/bkw777/dlplus/tree/master/clients
> in your case, anything named *.200, specifically:
> https://github.com/bkw777/dlplus/raw/master/clients/teeny/TEENY.200
> And just save it to the sd card as LOADER.DO
> and then PDDuino will use that file for bootstrap.
>
> I think backpack has a fancier bootstrap process with an initial stage
> that autodetects if the attached client is a 100 or 200 the same way a
> real TPDD2 utility disk does, but otherwise a similar idea where the
> device comes pre-loaded with a ts-dos loader, but it's just the default
> not permanent and you can replace it.
>
> --
>
> Simply using TEENY in place of TS-DOS will get you from 6k down to 1.5k,
> but you can go further by getting tricky with how you install and invoke
> TEENY. The TEENY docs go into some detail about it but the gist is you
> get the TEENY code installed into high memory, and then delete the .CO
> file and replace it with a smaller trigger file. If you get this right,
> then TEENY only consumes about 750 bytes. It's more delicate. If you run
> any other .CO program that overwites the high memory area, that wipes
> out TEENY, and then you no longer have the .CO file to reinstall from,
> so you have to load from serial again. Which, with a backpack is not
> much of a chore, especially if you customize the loader.do a little to
> make it do a high-ram-trigger-file install instead of saving a .CO file.
>
> I find the original teeny doc hard to follow but one thing it does is
> cover all points, except, maybe not, I think there is model 100-specific
> basic code in there in the trigger file section.
>
> https://bitchin100.com/wiki/index.php?title=TEENY.CO_MANUAL#Trigger_File_Creation
>
> --
>
> This claims to copy files from bank to bank on 200:
>
> https://bitchin100.com/wiki/index.php?title=Tandy_200_RAM
>
>
> --
> bkw
>
> On 8/10/23 17:21, CopyP wrote:
>
> Hi all,
>
> I have just received a Tandy 200 to go with my 100 and 102. It seems
> functional, but leaves me with an odd question:
>
> I have one of Birt?s Backpack drives, which works perfectly with my 100
> and 102, using the TS-DOS loader included on the SD card, and referenced in
> the Backpack manual. Unfortunately, I don?t have an option ROM with TS-DOS,
> so I loose 6K or RAM. On the 100/102 that isn?t too bad, but on the 200, it
> leaves insufficient RAM for the documents I am producing.
>
> So, I thought, why not load TS-DOS into one RAM bank, and the documents in
> another? Except that I 

Re: [M100] Intermittent problem at higher baud rates on RS-232 interface

[Brian White]

The receive buffer on m100 is small and tge screen updates in telcom take
so much time that, even with xon/off enabled, you can't go over 600 baud
reliably. The in-band software flow control has a minimum round trip time
that means that by the time the 100 sends the "stop sending" and the other
side gets it and stops, there are too many bytes already in flight and it
overflows the 100s receive buffer. It can keep up with 600, 1200 it almost
manages but not quite.

With the screen updates turned off you can go higher but 9600 may still be
too high. It depends on the software being used on the 100 and the size of
any continuous transmissions.

TPDD uses 9600 and 19200 reliably only because it operates in small packets
and no screen updates. TPDD clients have small fast machine language
routines to process the bytes in as few cpu cycles as possible, with no
screen updates in the inner loop, and the largest possible packet in the
protocol is still under 256 bytes. So even with no flow control, the
protocol itself stops transmission anyway and waits for an ack before
sending the next packet.

You may be able to use 9600 for tnc but only if the software is not also
drawing on the screen at the same time it's receiving, and especially if it
naturally operates in small chunks with breaks.

Using TELCOM, with the screen enabled, and possibly arbitrarily long
continuous downloads, you're limited to 600 baud.

The machine physically has rts/cts hardware, but nothing in the system rom
(including telcom) enables rts/cts. The only software known to use rts/cts
is HTERM and I think TBACK, which you can find on bitchen100.
That can reliably go over 600 because it has it's own machine language code
to operate the uart. Anything else will be limited to xon/xoff.


bkw

On Sun, Jul 9, 2023, 6:20 PM Jesse Bertier  wrote:

> First time getting my hands on a model T.  I am attempting to connect to a
> TNC at 9600 baud.  I have both matched for 8,N,1 and 9600 baud.  TNC works
> with other PCs.  I’m using TELCOM and set the parameters correctly.  What
> happens at 9600 baud is the text coming into the m100 is garbled mostly and
> on occasion some valid words come across.  When I set both to 300 baud,
> works perfectly.   It seems to be problematic if there’s a solid block of
> text coming in, like a string of 20-30 words for example.
>
> Before I dig into the problem with the service manual and get out the
> scope, does anyone know if these are supposed to work well at 9600 or up to
> 19,200 ?  Or, does the buffer or machine get overloaded at higher rates?
> Is TELCOM the issue?
>
> Sent from my iPhone

Re: [M100] - Text Sweet 2.3 Release

[Brian White]

basic is parsable, obviously the interpreter has to do it, but the
difference is to parse basic you pretty much need a state machine, pretty
much the same way the actual interpreter works.

You can't really determine what any given digit or double-quote or almost
anything is, except by starting from the beginning and keeping track of
what you have encountered one byte at a time all along the way.

You enter and exit modes or states serially, at least within a line, and
the rules are the weird rules of basic not any generic rules, ie how a
string of text might be several different things packed together, only
recognized as separate things by recognizing that IFA is not a keyword but
IF is, and so A must be an argument, but not if this all doesn't appear in
the main context outside of quotes or comments or a data statement.

Or how a THEN or ELSE branch ends at the end of the line, which is no
different than the end of any other line, not with some explicit ENDIF or
braces.

bkw

On Fri, Mar 3, 2023, 3:47 AM B 9  wrote:

> On Wed, Mar 1, 2023 at 11:00 PM John R. Hogerhuis 
> wrote:
>
>> Well, for ANSI C 99 lex is probably the best way. C doesn't (didn't?)
>> have any regex engine. I don't know what's in modern C, it might have
>> libraries for regex.
>>
>
> I've used the PCRE library in C, which works but is not as nice as a
> language which is designed from the ground up to use regular expressions.
> While the modern languages that I know technically have regular
> expressions, most of them treat regexes as a weird string which can be used
> in a function call, no different than a library in C. Perl and Python are
> noteworthy here: Perl for being surprisingly good at integrating regular
> expressions into the design of the language and Python for failing quite
> badly when they should have known better. I don't know if there are any
> modern languages that put regular expressions at the heart in the way lex,
> awk, and sed do. I'd love to learn if anyone knows.
>
> If someone is using Python, Perl, C#, Java, Javascript, etc... my
>> minimalist tendency would be to forgo the dependency on a lexer library
>>
>
> If you are speaking of how the compiled executable can literally depend
> upon the lexer library to run, it turns out that is not necessary. But,
> yes, I do see your broader point of wanting to write directly in a language
> instead of using a meta-language.
>
>
> and just use the regex language feature to do the work. Since you can
>> create one being expression with a named line number token, followed by a
>> series of BASIC lexemes as one big list of "|"'s
>>
>
> If the language's regex features made doing so easy, I'd be all for it.
> Unfortunately, as far as I know, they don't. Consider "mini-scanners" where
> part of the input is syntactically different from the rest. For example,
> how do you handle REM or double quotes? It is totally possible to do it in
> a giant regex, but not by me. I mean, I could probably come up with
> something that seems to work, but I'm not sure I have enough skill (or
> patience) to do it right. I would end up kludging it with extra code that
> might work, but certainly would offend anyone's sense of minimalism.
>
> With lex, mini-scanners are trivial. For example, here is the entirety of
> the code needed to handle REM in my tokenizer:
>
> %x remark /* remark is an exclusive start condition */REM 
> putchar(142);   BEGIN(remark);
> <*>\n putchar('\0');  BEGIN(INITIAL);
>
> I simply defined an exclusive start condition named  and have the
> REM statement enter into it. Lex automatically copies verbatim any text
> that doesn't match any rules. The only rule that matches  is
> newline, which returns the scanner to the normal start condition. Double
> quotes are just as easy.
>
>
>
>> For a given line you need to lex the line number first. That can be its
>> own regex.
>> Then you need to lex BASIC tokens one after another. Pretty much that's
>> just one giant regex of alternative lexemes.
>>
> As you extract them you may enter modes for handling expressions, strings,
>> REM content depending on what you're doing (tokenizer, syntax checker,
>> pretty printer, renumber, etc.) . That's your own code and variables, lex
>> doesn't really help with that anyway since it's not a parser.
>>
>
> You are correct about lex not handling expressions. The syntax for REM and
> strings in BASIC is not recursive and doesn't need a parser. That makes lex
> perfect as a BASIC tokenizer, but not so great for any of the other
> examples you listed, at least not on its own. While my tokenizer can
> ~kinda~ pack the .BA file by removing comments and whitespace, the sort of
> optimizations Brian is talking about (merging lines) or that I'm
> considering (removing lines that only contain a remark) are beyond it.
>
>
> Now if you're into trying a proper parser/context free grammar then I can
>> see using lex+yacc or equivalents, even in a higher level language.
>>
>
> I'm 

Re: [M100] Removing DVI Disk Basic

[Brian White]

In my first post in this thread I linked DVI.CAT and the directory it sits
in, the peripherals dir in m100sig, and pointed to a couple files described
in DVI.CAT, then just noticed more files from the same place that apply to
this question.


bkw

On Thu, Mar 2, 2023, 9:18 PM MikeS  wrote:

> What and where is SWITCH.DSK?
>
> - Original Message -
> From: "Brian K. White" 
> To: 
> Sent: Thursday, March 02, 2023 10:33 AM
> Subject: Re: [M100] Removing DVI Disk Basic
>
>
> > Ah, and SWITCH.DSK must be what I thought I remembered seeing before
> > about switching between dvi and other.
> >
> >
> > On 3/2/23 10:29, Brian K. White wrote:
> >> See L-DVI.100
> >>
> >> On 3/2/23 10:18, grima...@gmail.com wrote:
> >>> Just tried out BOOT.BA  and it works pretty well.
> Only
> >>> thing I don't love about it, is that you need to re-enter the
> >>> Time/Date after removing Disk-BASIC.
> >>>
> >>> I think I'm going to modify it to store the current date/time in
> >>> ALTLCD before clearing the ram, as I think that location ought to be
> >>> protected.
> >>>
> >>> -George
> >>>
> >>> On Thu, Mar 2, 2023 at 9:48 AM Brian K. White  >>> > wrote:
> >>>
> >>> I never noticed that, but I just tried it and you're right, the dvi
> >>> needs the system disk on every power-on, not just for installation.
> >>>
> >>> -- bkw
> >>>
> >>> On 3/2/23 09:20, grima...@gmail.com 
> >>> wrote:
> >>> > I guess the need to pack the Disk BASIC away is pretty limited,
> >>> since
> >>> > when the DVI starts up, it loads software into it's RAM from the
> >>> system
> >>> > disk, the same disk which you can use to load Disk BASIC to the
> >>> M100. So
> >>> > even if you were to pack and reload Disk BASIC, the DVI will be
> >>> useless
> >>> > without the system disk. (unless there is a way to load the DVI
> >>> software
> >>> > into the DVI from the System Bus connector of the M100.)
> >>> >
> >>> > That would be great if possible, you could bootstrap a DVI
> >>> without the
> >>> > original disk.
> >>> >
> >>> > -George
> >>> >
> >>> > On Thu, Mar 2, 2023 at 9:11 AM Brian K. White
> >>> mailto:b.kenyo...@gmail.com>
> >>> > >>
> >>> wrote:
> >>> >
> >>> > On 3/2/23 07:37, grima...@gmail.com
> >>>   >>> > wrote:
> >>> > > Hi Brian,
> >>> > >
> >>> > > Just reading the descriptions in your link and they seem
> >>> to be
> >>> > exactly
> >>> > > what I need.
> >>> >
> >>> > Looks like also D100.BA   >>> > and DISABL.DVI
> >>> >
> >>> > I would have sworn I saw directions in the user manual, but I
> >>> don't see
> >>> > anything like that now.
> >>> >
> >>> > There may be yet other programs or texts elsewhere in the
> >>> m100sig
> >>> > besides these too.
> >>> >
> >>> > I thought I saw some that don't just unload the dvi software
> >>> but pack
> >>> > it away for restoring later, and did the same for other
> >>> dosses like for
> >>> > chipmunk or tpdd, and let you flip back & forth between them.
> >>> >
> >>> > Here's something cool, search the entire m100sig using the
> >>> search
> >>> > box on
> >>> > github:
> >>> >
> >>> >
> >>>
> >>> https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo
> >>> 
>  https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo>>
> >>> >
> >>> > Whoa Nelly!
> >>> >
> >>> > --
> >>> > bkw
> >>> >
> >>>
> >>> -- bkw
> >>>
> >>
> >
> > --
> > bkw
>

Re: [M100] - Text Sweet 2.3 Release

[Brian White]

127 or 128 so is the limit that the interactive editor can handle, while
the interpreter can handle up to 254 or 255 if you're just executing and
not editing.

bkw

On Wed, Mar 1, 2023, 8:15 PM B 9  wrote:

> On Wed, Mar 1, 2023 at 6:39 AM Brian K. White b.kenyo...@gmail.com
>  wrote:
>
>> I also wrote a renumberer and packer in bash (actually in awk too before
>> that, still in the repo in the "attic")
>>
>> https://github.com/bkw777/BA_stuff
>>
>
>
> Okay, that’s freaking awesome. I can imagine doing it in AWK, but making
> that work in Bash is impressive.
>
>
> I was trying [...]
>>
>> ONAGOSUB310,311,312316,317,318,319
>>
>> and reseq didn't handle that right. I don't know what other renumberers
>> do because I decided at least for what I was working on it would be more
>> convenient to renumber on the host than on the 100.
>>
>
>
> Tricky! I don’t know about other renumberers, but a bit ago I wrote
> something similar: a program to remove all unnecessary comments from a
> program. Part of it was a Bash script, jumpdestinations
> ,
> which identifies the lines which are referenced by other lines and thus
> shouldn’t be removed even if they only contain a REM statement. Until
> today, I used this regular expression:
>
> egrep -io 
> '(GO\s*TO|GOSUB|THEN|ELSE|RESTORE|RESUME|RETURN|RUN)(\s*,?\s*[0-9]+)+'
>
> As you can see, I had missed exactly the same subtlety as reseq.
>
>
>> The packer might be slightly wrong in one aspect. It converts all prints
>> to ?s and rems to 's, which does make the ascii file smaller, but I have
>> since read somewhere that one or both of those may actually result in
>> slightly more ram usage on the 100? I haven't performed a test to find out.
>> So the packer could maybe use an option for that.
>>
>
>
> I analyzed the BA format
> 
> and both ? and PRINT are encoded the same way and make no difference once
> the program is loaded. However, REM and ' are not. If you are looking to
> save space in the ASCII file, then the packer was correct to use ', but
> if you want to save space in the BA file, the packer should have used REM.
>
>
> I am not sure there’s a good use case for minimizing the ASCII file these
> days. Back when 7-bit transfers via TELCOM or LOAD “COM:98N1” were the
> norm, maybe it was worth it, but it seems like a mistake given that the
> ASCII file is only needed briefly while the BA file will remain on the
> computer as long as the program is used.
>
>> I might try to add line-unwrapping to the packer next. There are some
>> unwrapping that would be too involved to try to do, like keeping track of
>> broken but recombinable prints and other literals.
>>
>
>
> Yeah, a proper BASIC parser would be pretty much necessary. But, once you
> had that, you might be able to do fancier things, like unwrapping
> subroutines that are only reachable from one location. For example, lines
> 31000–31020 could be merged into line 23000 in TSWEEP.DO:
>
> 23000 GOSUB 24000:GOSUB 31000:KEY(8) STOP: 
> PRINT@3*YO%+35,"Quit?";:PRINT@4*YO%+35,"(y/n)";:GOSUB2:KEY(8) ON:IF YN%=1 
> THEN CLS:MENU ELSE GOSUB 17200 : GOSUB 17300 : RETURN
> ⋮30090 PRINT@7*YO%+PO%, CHR$(237)+STRING$(38,232)+CHR$(238);:KEY(8) 
> ON:RETURN31000 FOR TY = 0 TO 7 'subroutine: Clear Right Pane31010 PRINT @ 
> TY*YO%+32,STRING$(8,32);31020 NEXT : RETURN
>
>
> But it should be no problem to at least do some combining where if the end
>> of one line is not something like a THEN branch, and the next line number
>> is not a jump target anywhere else in the file, and the total new combined
>> line would be under either the 127 or 254 threshold (whichever you want)
>> it's ok to combine.
>>
>
> Nice. Every line you can remove from the source code will save five bytes
> from the .BA file.
>
> I'm not familiar with the 127 character limit. Is that for the NEC PCs?
> —b9
>
> P.S. What’s the character limit in the .BA format? A quick test of
>
> 10???
>
> shows that I can have a program in memory which is larger than EDIT can
> handle. Perhaps it would be a useful addition to my tokenizer to be able to
> pack lines at the token level.
>
>
>

Re: [M100] - Backpack

[Brian White]

I don't think it's ts-dos, it's the main rom. The main rom and all the tpdd
clients basically have to trust the file name. If it's declared as a .ba,
then the bytes are copied verbatim and then later interpreted according to
the rules of parsing a .ba. If the contents are not .ba, kablooey.

bkw

On Tue, Feb 28, 2023, 8:11 PM  wrote:

> I did some more testing and discovered that John is absolutely correct.
> Previously when I had tried to load a .BA which was really a .DO it made it
> about 3-4 line in and then stopped. This led me to believe it was an issue
> I have seen on other computer; when loading an ASCII file over serial the
> computer will tokenize the line when the CR is encountered. Just like it
> had been typed in on the keyboard. For these systems you have to add a 2
> second or so delay after each line to allow for tokenization.
>
> TSDOS does its own thing, like John says, and really makes a mess of it.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Saturday, February 25, 2023 7:40 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] - Backpack
>
>
>
> A side note but the reason files misnamed as BA cause a problem is that
> tsdos will load them into the BASIC program region verbatim and  treat the
> ASCII bytes as parts of binary formatted line numbers and tokens among
> other problems, ultimately causing a corrupted RAM file system.
>
>
>
> It was the convention on the old Club100 library  to name them this way
> but it's now a bad practice.
>
>
>
> -- John.
>
>
>
>
>
>
>
> On Sat, Feb 25, 2023, 5:30 PM  wrote:
>
> Yes, someone already wrote such a program and shared it. If you just got a
> Backpack Drive Plus it is already on the SD card. You can also download it
> from: https://github.com/Jeff-Birt/Backpack/tree/main/User_Programs
>
>
>
>

Re: [M100] - Backpack

[Brian White]

oh yeah... looking at the schematic again I forgot the actual function of
the 3 /OE pins is still a question until actually tried.

So it's not quite time yet to claim 200 has this option that 100 and 102
have had for a few years.

With the one pin being connected directly to A15 according to the service
manual, I implemented that pin as active high. But until I actually try it,
who knows? The schematic claims it's an active low /CE by labelling it that
way. Yet... A15.   `\_(oo)_/'


bkw

On Sun, Feb 26, 2023, 4:56 AM Brian White  wrote:

> It still works. I use it. And anyone can build themselves a new one any
> time from my re-spin plans, it just hasn't changed and probably never will
> because I am not up to picking apart the firmware to hack on it nor write a
> new one. It's Steve's last version.
>
> The only advancement is I made adapter boards for model 200 recently like
> I had for 100 & 102 already, where the board includes a copy of a standard
> rom so that it functions just like the original rom, but also provides a
> solderless connection out to rex and back so that you can boot from the rex
> or boot from internal without having to open the case again. And the
> connections are all dupont jumper wires, so installable/removable without
> soldering, and without blocking the original socket preventing having an
> internal main rom.
>
> Some weeks ago when we were talking about the weird 8k chip in the 200, I
> made a board for that. So now 200 also has this option to keep an internal
> rom and still boot from rex. For the main 32k chip in the 200, you just use
> the same one as 102. At the time we all decided based on the data sheets
> that if all you wanted to do was replace that 8k chip, you should be able
> to just use a normal 27C64, but I decided to actually implement the extra
> control pin with a few gates just to be sure.
>
> I have built and programmed that new board so I at least know the
> programing jumper setting works, but have not tried installing it yet.
> github.com/bkw777/aDIPters#flexrom_200_m13
>
> It's kind of wildly impractical. These small eeprom are getting stupid
> expensive. I'm afraid to add up the cost of all the bits to make a rex
> classic and these two rom adapter boards to make a 200 with rex classic and
> still usable internal main rom. I mean I have already got all those bits,
> but I just mean I don't want to find out explicitly just how dumb it is. ;)
>
> But I do love my 100 and 102 with the same option. I switch between stock
> internal main rom with no rex, like when testing that ram+ or pgdesigns
> ram, rex classic software main rom, rexcpm, and back etc any time without
> opening the case any more. I love it.
>
> And it's all just sockets and dupont pin connectors. I could put the
> original stock rom back in any time. I could also ditch the jumper wires to
> rex yet still use the non-original main rom by just installing a jumper on
> the pins on the board in place of the wires. I could also still update the
> rom on the board. That would require opening the case again but no
> soldering.
>
> bkw
>
> On Sun, Feb 26, 2023, 12:46 AM Mike Stein  wrote:
>
>> Yeah, the XR4 would certainly expand the options (pun intended) but I
>> never quite figured out how they selected among the images; I did work out
>> another solution and started building a 16MB RAM expansion but never
>> actually finished or tested any of it. Things like REX, the Backpack and
>> the Dial-a-ROM are a lot easier ;-)
>>
>> The issue is that when TS-DOS is in (the single) ROM space it would get
>> clobbered by loading another ROM image there; I'll have to have another
>> look at it all, including the EME tools, to see how it might work. Am I
>> missing something?
>>
>> BTW, I haven't used my REX in years; AFAIR it's the original version with
>> the System ROM replacement option and I guess there's not much support for
>> that these days?
>>
>> m
>>
>> On Sun, Feb 26, 2023 at 12:14 AM Stephen Adolph 
>> wrote:
>>
>>> Mike, not sure I follow.
>>> You know you can have multiple ram spaces in option locations.  Like xr4.
>>> Could an xr4 do what you want?
>>>
>>> Xr4 was a tidy solution.  Needed a few wires to make it work.
>>>
>>> I guess I don't understand why tsdos is not compatible with option ram?
>>> Seems like it is, just like any other rom program?
>>>
>>>
>>>
>>> On Sunday, February 26, 2023, Mike Stein  wrote:
>>>
>>>> As you may remember, years ago I designed an adapter that let you put
>>>> both the system image and an option ROM image into a single chip that
>>>> 

Re: [M100] - Backpack

[Brian White]

It still works. I use it. And anyone can build themselves a new one any
time from my re-spin plans, it just hasn't changed and probably never will
because I am not up to picking apart the firmware to hack on it nor write a
new one. It's Steve's last version.

The only advancement is I made adapter boards for model 200 recently like I
had for 100 & 102 already, where the board includes a copy of a standard
rom so that it functions just like the original rom, but also provides a
solderless connection out to rex and back so that you can boot from the rex
or boot from internal without having to open the case again. And the
connections are all dupont jumper wires, so installable/removable without
soldering, and without blocking the original socket preventing having an
internal main rom.

Some weeks ago when we were talking about the weird 8k chip in the 200, I
made a board for that. So now 200 also has this option to keep an internal
rom and still boot from rex. For the main 32k chip in the 200, you just use
the same one as 102. At the time we all decided based on the data sheets
that if all you wanted to do was replace that 8k chip, you should be able
to just use a normal 27C64, but I decided to actually implement the extra
control pin with a few gates just to be sure.

I have built and programmed that new board so I at least know the
programing jumper setting works, but have not tried installing it yet.
github.com/bkw777/aDIPters#flexrom_200_m13

It's kind of wildly impractical. These small eeprom are getting stupid
expensive. I'm afraid to add up the cost of all the bits to make a rex
classic and these two rom adapter boards to make a 200 with rex classic and
still usable internal main rom. I mean I have already got all those bits,
but I just mean I don't want to find out explicitly just how dumb it is. ;)

But I do love my 100 and 102 with the same option. I switch between stock
internal main rom with no rex, like when testing that ram+ or pgdesigns
ram, rex classic software main rom, rexcpm, and back etc any time without
opening the case any more. I love it.

And it's all just sockets and dupont pin connectors. I could put the
original stock rom back in any time. I could also ditch the jumper wires to
rex yet still use the non-original main rom by just installing a jumper on
the pins on the board in place of the wires. I could also still update the
rom on the board. That would require opening the case again but no
soldering.

bkw

On Sun, Feb 26, 2023, 12:46 AM Mike Stein  wrote:

> Yeah, the XR4 would certainly expand the options (pun intended) but I
> never quite figured out how they selected among the images; I did work out
> another solution and started building a 16MB RAM expansion but never
> actually finished or tested any of it. Things like REX, the Backpack and
> the Dial-a-ROM are a lot easier ;-)
>
> The issue is that when TS-DOS is in (the single) ROM space it would get
> clobbered by loading another ROM image there; I'll have to have another
> look at it all, including the EME tools, to see how it might work. Am I
> missing something?
>
> BTW, I haven't used my REX in years; AFAIR it's the original version with
> the System ROM replacement option and I guess there's not much support for
> that these days?
>
> m
>
> On Sun, Feb 26, 2023 at 12:14 AM Stephen Adolph 
> wrote:
>
>> Mike, not sure I follow.
>> You know you can have multiple ram spaces in option locations.  Like xr4.
>> Could an xr4 do what you want?
>>
>> Xr4 was a tidy solution.  Needed a few wires to make it work.
>>
>> I guess I don't understand why tsdos is not compatible with option ram?
>> Seems like it is, just like any other rom program?
>>
>>
>>
>> On Sunday, February 26, 2023, Mike Stein  wrote:
>>
>>> As you may remember, years ago I designed an adapter that let you put
>>> both the system image and an option ROM image into a single chip that
>>> replaced the System ROM, both the standard (new) or non-standard (old)
>>> version; some folks on here may even still have one in their M100, probably
>>> loaded with TS-DOS.
>>>
>>> In another M100 I replaced the option ROM with RAM and load/save/copy
>>> etc. various ROM images using the EME extRAM tools, but of course I can't
>>> have TS-DOS in the same memory area as the option ROMs.
>>>
>>> The Dial-a-ROM and REX are certainly excellent solutions, but I'd still
>>> like to make the Option RAM concept compatible with TS-DOS, even if I have
>>> to add or reuse a physical switch to select between RAM and ROM. Any other
>>> ideas?
>>>
>>> m
>>>
>>>
>>>
>>> On Sat, Feb 25, 2023 at 11:26 PM John R. Hogerhuis 
>>> wrote:
>>>


 On Sat, Feb 25, 2023, 8:18 PM Mike Stein  wrote:

> Yeah, I guess everybody has TS-DOS in ROM one way or another these
> days; I've thought about putting it in the system ROM instead of the
> Scheduler and Address Book, but removing them doesn't really free up much
> space; maybe Teeny would fit...
>
>
 Scheduler 

Re: [M100] VIDEO - Dial-A-ROM for the Model T computers (and others)

[Brian White]

Gratuitous use of another chip just for 2 OR gates to implement a 4:2
encoder. It's all less efficient and less practical than the dial-a-rom, in
that the dar holds 16 roms and doesn't need another ic, and the dar
programming connection is even simpler and more robust.

But it just amused me to have a direct selector without manually binary
encoding dip switches because why not? And I didn't want it to require a
tool to use either like a screwdriver. And of course I always want an open
source option, and I'm not up to the task of coming up with an open source
rex-alike but using a Lattice part and the open source toolchain.

It's unfortunate timing but I had already started this at least 3 years ago
but just never finished it. A non-working version has been sitting in that
github since 2019. A few weeks ago I finally dusted it off and corrected my
bonehead pinout error, dialled-in the programming connection so it works
well (the holes are slightly closer together than the pins, and the pattern
and amount of offset took some trial & error) and replaced dip switches
with the slide switch & or gates. I had no idea the dar was in the works.
Not that it would have stopped me, but I just mean to say this isn't a
reaction.

It's no competition anyway because only a very few people ever build these
diy-only things. I want them to exist so the option is there, but almost no
one actually employs it. So this is not touching anyone's sales. Besides,
*16* roms. And of course really it's even sillier when rex exists which
doesn't even need a programmer or adapter to load it's, what, 30? slots?
But for other platforms 4 is plenty. There's only 2 roms total for the 600
for example. Still leaves 2 free slots for hacking.

I just added the browser-friendly render of the schematic to the readme so
you can see the bank-select.

-- 
bkw

On Sat, Feb 25, 2023, 8:18 PM Mike Stein  wrote:

> How do you select among the 4 images?
>
> On Sat, Feb 25, 2023 at 6:50 PM Brian K. White 
> wrote:
>
>> On 2/25/23 10:31, bir...@soigeneris.com wrote:
>> > Morning all,
>> >
>> > I just made this video live this AM. The DARs for the Model T computers
>> > have sold out already but my friend is making more.
>> >
>> > In this video we take a look at the ‘Dial-A-ROM’ a spiffy new multi-ROM
>> > for vintage portable computers. It was designed by the same guy who did
>> > the Backpack drive. First, we’ll learn how to use the Dial-A-ROM with
>> > the ROM images that come preinstalled on it. Then we’ll see how to add
>> > our own ROM images if we so desire.
>> >
>> > *https://youtu.be/CejyLsI0HIw 
>> >
>> > Jeff Birt (Hey Birt!)*
>> >
>>
>> And for the diy-er, I finally vetted these last week:
>> https://github.com/bkw777/Teeprom/blob/master/4ROM.md
>>
>> --
>> bkw
>>
>>

Re: [M100] stupid move = expected results

[Brian White]

Wow. That is a bit ridiculous. Well 91% is ok. You just may want to heat
the whole thing with a hair dryer because 91% will leave a little moisture
especially in all the corners and trapped spaces. Heat will drive the last
bit out. And a hair dryer isn't hot enough to worry about harming anything
even when it gets too hot to touch.


bkw

On Sat, Feb 18, 2023, 8:40 PM Daniel L  wrote:

> I got the distilled water from rite aid. Then went to home depot to get
> the alcohol. The paint department supervisor told me that California banned
> the sale of denatured alcohol five years ago and it carries a $5000 penalty
> if caught with it without a contractor's permit. They don't sell it.
>
> They also don't carry 99% alcohol in store, it has to be ordered online
> for home delivery.
>
> I found 91% at the drug store so I'll use that.
>
>
> On 2/10/23 00:14, Gregory McGill wrote:
>
> Also harbor freight has 99%
>
> On Fri, Feb 10, 2023, 12:05 AM Brian K. White 
> wrote:
>
>> At any hardware store in the paint section, or any paint store, it's
>> called denatured alcohol not isopropyl.
>>
>> If you asked for isopropyl specifically, maybe you just got someone who
>> didn't know enough, they might have looked for Drygas in the automotive
>> section or actual isopropyl in the cleaning supplies or seasonal because
>> they might have actually carried it just for the pandemic even though
>> they normally don't carry that.
>>
>> Denatured isn't isopropyl, it's either ethanol or methanol, but it's a
>> lot more readily available and cheaper and works fine for cleaning
>> electronics.
>>
>> You can find 99.9% isopropyl for more $$ at electronics supply shops,
>> which you may not have any near by. Micro Center usually has it in their
>> maker section if you have one of those around. It's much more expensive.
>>
>> --
>> bkw
>>
>> On 2/9/23 20:10, Daniel L wrote:
>> > OK, just got home from home depot. Had ammonia already in the garage,
>> > and have purchased cleaning vinegar. Home depot couldn't seem to have
>> > alcohol on hand and nor does lowes. Gonna try harbor freight next.
>> > Distilled water from rite aid next.
>> >
>> > On 2/9/23 16:23, bir...@soigeneris.com wrote:
>> >>
>> >> You want to use at least 90% alcohol. No rubbing alcohol with stuff
>> >> added to it. I use denatured alcohol from the hardware store 99.9%.
>> >>
>> >> Resolder the joints you need to. Don’t go crazy. Every joint you touch
>> >> is a chance to mess something up. I have been soldering for 40 years
>> >> and I live by this advice.
>> >>
>> >> Ammonia is available from any grocery in the cloths washing detergent
>> >> isle.
>> >>
>> >> Jeff Birt
>> >>
>> >> *From:* M100  *On Behalf Of
>> *Daniel L
>> >> *Sent:* Thursday, February 9, 2023 5:36 PM
>> >> *To:* m100@lists.bitchin100.com
>> >> *Subject:* Re: [M100] stupid move = expected results
>> >>
>> >> On 2/9/23 05:17, bir...@soigeneris.com wrote:
>> >>
>> >> There are two different causes of corrosion here. The battery has
>> >> an alkaline electrolyte, after removing the battery neutralize the
>> >> electrolyte left on the PCB with a mild acid like vinegar or
>> >> citric acid. Then clean well. I like to remove the solder from
>> >> components that have been affected and resolder. The corrosion
>> >> will wick through the solder joint making it to the other side of
>> >> the PCB and eating the via.
>> >>
>> >> Good thing I have citric acid. Can I use normal alcohol you get from
>> >> the drug store? I will be re-soldering as many joints as possible to
>> >> refresh them after forty years.
>> >>
>> >>
>> >> The capacitor corrosion is much, much worse on the M100. Every
>> >> M100 that has not already been recapped needs done. It is one of
>> >> the few machines I always recap. The electrolyte in capacitors is
>> >> acidic. After removing the capacitors scrape the worst of the
>> >> corrosion off and then treat the area with a mild alkaline
>> >> solution to neutralize any remaining acid (ammonia, etc.) Clean
>> >> and repair damaged traces.
>> >>
>> >> Where do you get ammonia?
>> >>
>> >> I have covered this procedure in several videos. Go to YouTube and
>> >> search for ‘HeyBirt!’. And from my channel page search for ‘Model
>> >> 100’.
>> >>
>> >> I love your channel and have been a subscriber since before I got my
>> >> first m100. Actually, I called and left you a voicemail the other day.
>> >>
>> >
>>
>> --
>> bkw
>>
>>
>

Re: [M100] One Tiny Battery Pack (Cryptronics, RAM+ expansion)

[Brian White]

If Sean doesn't claim the other one within a few days you can have it.


bkw

On Thu, Feb 16, 2023, 4:26 PM Gary Weber  wrote:

> Brian,
> I've got one of those RAM modules that also needs a replacement battery
> pack as well.  Would be nice for it to hold its contents again!
>
> Gary
>
> On Thu, Feb 16, 2023 at 1:46 PM Brian K. White 
> wrote:
>
>> No prob, I'll pm off list.  x-.
>> --
>> bkw
>>
>> On 2/16/23 10:14, Mike Stein wrote:
>> > If we're speaking, I could use one ...
>> >
>> >
>> >
>> > On Wed, Feb 15, 2023 at 8:53 PM Brian K. White > > > wrote:
>> >
>> > On 2/10/23 10:13, Brian K. White wrote:
>> >  > Oh you sure don't want to solder to the cells.
>> >  > I did not mean to suggest buying individual cells, just to
>> identify
>> >  > them for reference for searching for packs made with them.
>> >  >
>> >  > Battery packs are often named after the cells.
>> >  > The memory battery inside the 100 is called "3/V80H 2-pin"
>> because
>> >  > it's made of 3 V80H cells, etc.
>> >  >
>> >
>> > The new batteries worked perfect.
>> >
>> > https://photos.app.goo.gl/68qSfxdPD9WwdhzHA
>> > 
>> >
>> > The only thing is it is a tight fit between the rom socket and the
>> edge
>> > of the cryptonics board, and I think that tightness pushing
>> sideways on
>> > the edge of the board maybe caused some of the bus pins to not make
>> > good
>> > connection and made the machine crash and no boot after reset.
>> Fiddling
>> > with the cell pack a little flipping it over different directions I
>> > found an orientation that felt slightly better and now it's running
>> > again. Or maybe that was just alcohol not fully dried yet trapped
>> under
>> > chips. I think maybe the trick is lay the battery in position first
>> and
>> > then the pcb.
>> >
>> > The tight fit is the same as the original pack anyway.
>> >
>> > The lead wires fish right in between the female bus sockets like the
>> > original wires. I fished them in end-wise, not mashed from the top,
>> and
>> > they fit with no resistance, no mashing of the insulation at all.
>> >
>> > If you look at the pics here, before soldering, I flush-cut 4 of the
>> > pins that poke up right under the red & black wires, and then
>> touched
>> > them with flux and fresh solder so they made smooth domes so they
>> don't
>> > pierce the battery wires. I did that before installing the new
>> battery.
>> >
>> > The old battery wire was stuck by super glue, so it took a little
>> care
>> > to scrape up most of the insulation and super glue without
>> scratching
>> > any traces on the pcb.
>> >
>> >
>> > If you want you can have one of the 2 extra packs I got.
>> >
>> > --
>> > bkw
>> >
>>
>> --
>> bkw
>>
>>

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[Brian White]

There are also font replacements that make more rows & columns on the
existing lcd by making the glyphs smaller. I forget the name but I think
one of the option roms has one.

bkw

On Tue, Feb 14, 2023, 8:29 PM B 9  wrote:

> On Tue, Feb 14, 2023 at 6:00 AM grima...@gmail.com 
> wrote:
>
>> If someone wants to branch my repo and mod it to add graphics, I suppose
>> they could. However, I would advise against it. I plan to do
>> continuous development on Text Sweeper for a while, and will be releasing
>> updates more frequently. Additionally, I can't guarantee that my changes to
>> how things are done behind the scenes will work with those modifications.
>> In fact, I suspect that as I make changes to how the screen gets drawn, it
>> will not work with ASCII PIXELS as it did before.
>>
>
> Thanks for clarifying that.
>
>
> I have a new feature(implemented in BASIC) that detects if the screen
>> isn't drawn properly, and I do it by checking the LCD RAM location for
>> specific characters. If they aren't there, it redraws the screen. This is
>> to try and prevent a situation where someone presses LABEL. and eliminates
>> the bottom row of the screen. I'm guessing either the RAM layout is
>> different for the T200.
>>
>
> Yup. The Tandy 200's memory layout is different. But if the concern is
> that someone might accidentally hit LABEL, why not just send the escape
> sequence to turn labels off?
>
> PRINT CHR$(27)"U"
>
> or (less portably),
>
> SCREEN ,0
>
>
>
>> Is there any quick way to detect T200 ROM vs M100/T102 ROM?
>>
>
> PEEK(1) 
> will usually work. Here's a table I made for various Model-T machines when
> I was trying figure out the address of the RAM Directory:
>
> Model PEEK(1) RAM Directory Address SAVEM bug? KB Count Address
> Kyocera Kyotronic-85 225 63849 Yes 65387
> TRS-80 Model 100 51 63842 No 65450
> Tandy 102 167 63842 No 65450
> Tandy 102 (UK) 167 63842 No 65450
> Tandy 200 171 62034 No 64799
> NEC PC-8201 148 63567 Yes 65128
> NEC PC-8201A 148 63567 Yes 65128
> NEC PC-8300 148 63567 Yes 65128
> Olivetti M10 (Italy) 35 63849 Yes 65389
> Olivetti M10 (US) 125 ? ? ?
>
>
>
>> I currently also redraw the minefield the same way when switching between
>> the Game screen and the Help screen. This is relatively slow, as I need to
>> calculate the display value of every tile, concatenate into a string to
>> represent a row, since it isn't stored. This is mostly so that I minimize
>> the amount of times I call PRINT.
>>
> My plans here are to Copy LCD to ALTLCD when switching, and then print
>> ALTLCD back to the screen when switching back. Then I will update my redraw
>> routine to just populate ALTLCD via POKE, and invoke the ML subroutine the
>> draws prints ALTLCD. Still a work in progress however.
>>
>
>>- Improve speed when switching between Game and Help.
>>
>> I like that you are adding builtin instructions and it sounds like a fun
> optimization to make it faster. If you're using the TELCOM back page
> (ALTLCD) to store an actual page of text, maybe investigate how TELCOM is
> able to switch so fast between the two pages. I suspect it is doing
> something more clever than simply copying the data.
>
>
>>
>>- Improve speed of mine revealing algorithm.
>>
>> If it's still the same speed as TSWEEP 2.0, improving that would
> certainly help playability.
>
>
>>- Support larger displays of both T200 and DVI (might be a stretch).
>>In my mind, I would have the Help screen permanently displayed beneath the
>>game screen. Alternatively, I could make a larger minefield and option, 
>> but
>>that would break a lot of assumptions in the code today, and require a ton
>>of rework.
>>
>>
> It would be fabulous if TextSweeper allowed for different size screens.
> The Tandy 200 has 16 rows, which should make for a more fun game of
> minesweeper.
>
> If you plug your Model 100 into the DVI monitor
>  you mentioned, you get an
> additional screen with 80 (or 40) columns by 25 rows. I do not believe the
> DVI provides an ALTLCD area for TELCOM, but you can show the help screen on
> the LCD and switch to the CRT for the actual game.
>
> —b9
>
> P.S. Just for fun, I wrote a little BASIC routine that should be able to
> detect the screen size:
>
> 1 REM Test detecting screen size 2 REM for M100, T200, DVI, etc.
>
> 10 E$=CHR$(27)20 CLS30 PRINT  "Detecting screen size"100 PRINT "   with 
> labels on: ";110 SCREEN,1120 GOSUB 500130 PRINT CO "x" RO200 PRINT "   
> with labels off:";210 SCREEN,0220 GOSUB 500230 PRINT CO "x" RO499 END
> 500 REM Return number of rows in RO501 REM   and columns in CO.505 
> AR=CSRLIN: AC=POS(0)509 REM Go to furthest screen address.510 PRINT 
> E$"Y~~";520 RO=CSRLIN+1: CO=POS(0)+1530 PRINT E$"Y"CHR$(32+AR)CHR$(32+AC);540 
> RETURN
>
>

Re: [M100] Conflict with Backpack SD drive

[Brian White]

You don't really have to reinstall ts-dos. You can keep a copy of dos100.co
in ram and run it with a small basic file that has a clear statement in it.
This just consumes a lot of ram so it's usually not advised. The .ba is
only one or two lines, but you end up with 2 copies of ts-dos in ram, one
in the filesysyem in the form of the .co file, and one in high memory that
is actually executed. That's about 10 to 12k out of only 29 or so.

Or tsload can load it from disk on the fly similar to what ultimate rom 2
does.

There are also a bunch of different utils of varying quality in the m100sig
and on club100 that try to help manage machine language apps and dosses in
particular by loading and unloading them. Copying them out of high memory
and removing any other bits like hooks elsewhere, and remembering what they
were and being able to put them all back later.

What you really want is ts-dos in rom, and if you want to use any other rom
like multiplan, then you really want a rex# so you can switch between
multiple roms at will.

bkw

On Tue, Feb 14, 2023, 10:01 PM Comcast  wrote:

> Update for everyone on my conflict issue.
>
>
>
> I can now at least uninstall TS-DOS from high memory using the clear
> 256,maxmem command. Once I do that multiplan runs fine.
>
>
>
> The downside is then I have to re install TS-DOS, which takes a bit of
> time. But at least I don’t have to remove my ROM and no cold restart so no
> files lost.
>
>
>
> Next thing I want to try is one of the other disk manager programs to see
> if one doesn’t conflict. I just need to figure out how to load those vs the
> current SD card setup to load TS-DOS
>
>
>
> mike
>
>
>
> *From: *M100  on behalf of <
> bir...@soigeneris.com>
> *Reply-To: *
> *Date: *Tuesday, February 14, 2023 at 4:03 PM
> *To: *
> *Subject: *Re: [M100] Conflict with Backpack SD drive
>
>
>
> Look on the SD card that came in the Backpack, The user’s manual is on
> there and has all the directions, all of the various TSDOS clients are
> already installed on the card too. On Github:
> https://github.com/Jeff-Birt/Backpack/tree/main/BPD%2B%20Files there are
> three main folders: Documentation, Firmware and SD Card. The ReadMe in each
> describe what the files are.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Tuesday, February 14, 2023 3:36 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Conflict with Backpack SD drive
>
>
>
> Thanks Jeff
>
>
>
> Can you advise where I can find tenet on your GitHub site as well as
> instructions for what I need to change on the SD card to use this vs
> DOS100.co
>
>
>
> Mike
>
> Sent from my iPhone
>
>
>
>
> On Feb 14, 2023, at 10:12 AM, bir...@soigeneris.com wrote:
>
> 
>
> Talking to friend who created Backpack and he suggested trying Teeny.co as
> it does not hook into anything. You could use the CLI to change directories
> if needed. Let us know if it works.
>
>
>
> Jeff Birt
>
>
>
> *From:* bir...@soigeneris.com 
> *Sent:* Tuesday, February 14, 2023 8:27 AM
> *To:* 'm...@bitchin100.com' 
> *Subject:* RE: [M100] Conflict with Backpack SD drive
>
>
>
> I don’t know if they will behave differently or not. It would not hurt
> anything to try.
>
>
>
> Jeff
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Tuesday, February 14, 2023 8:02 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Conflict with Backpack SD drive
>
>
>
> Thanks, will do!
>
>
>
> Did you see my note/question on if the other (non TS-DOS) disk managers
> listed in your manual might also be worth trying?
>
>
>
> Mike
>
> Sent from my iPhone
>
>
>
> On Feb 14, 2023, at 7:56 AM, bir...@soigeneris.com wrote:
>
> 
>
> The bootstrap program is just a bit of BASIC that loads TSDOS, it does
> nothing else and does not stay resident/running so there is nothing to
> uninstall.
>
> It might be that part of TS-DOS is being installed in high memory and this
> is conflicting with Multiplan? Go to:
> http://club100.org/library/libdoc.html  , look on the right center of
> page and download TSDOS.PDF ‘The Best On’. There are a lot of TSDOS tips
> and tricks in there including how to uninstall it.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Tuesday, February 14, 2023 7:28 AM
> *To:* m...@bitchin100.com
> *Cc:* M100 
> *Subject:* Re: [M100] Conflict with Backpack SD drive
>
>
>
> Thanks Jeff,
>
>
>
> I tried that - nope
>
>
>
> Do the other disk manager softwares you speak of install differently,
> worth trying?
>
>
>
> What is the method to “uninstall” the bootstrap? Couldn’t find that
> anywhere, so just did a cold reset
>
>
>
> Mike
>
> Sent from my iPhone
>
>
>
>
>
> On Feb 14, 2023, at 7:22 AM, bir...@soigeneris.com wrote:
>
> 
>
> I’m just guessing here but suspect that TS-DOS is hooking into some of the
> same resources that Multiplan tries to hook into. You might try the ‘DOS
> OFF’ button before trying to run Multiplan.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Comcast
> *Sent:* Monday, February 13, 

Re: [M100] Romulus Chess for T200 (REX# RAM images)

[Brian White]

This means it should be possible to do the same from laddie or dlplus. You
do still need ts-dos to be in rom, and so you do still need a rex of any
flavor or an actual plain rom.

-- 
bkw

On Sat, Jan 7, 2023, 10:24 AM Stephen Adolph  wrote:

> https://www.mail-archive.com/m100@lists.bitchin100.com/msg07337.html
>
> I had forgotten about this.  TS_DOS provides a means to load and run .CO
> directly.
>
> Kurt sent an earlier email about how to load the CHESS.CO and CHESSX.CO
> binaries that are here:
>
> http://www.club100.org/memfiles/index.php?=0==Steve%20Adolph/Romulus%20chess
>
> Here's the key part:
>
> With TS-DOS running in rom and DOS active, I go to  BASIC and try to run it 
> from the
> virtual TPDD device.
> RUNM "0:CHESSX.CO"
>
> What I get  is the following
> Top: 42312
> End: 56000
> Exe: 42312
> ?OM Error
>
> The Error means that you have an out of memory problem. BASIC can't
> run the program until you clear the space for it to run. So I do
> the following
> Clear 0, 42312
> RUNM "0:CHESS.CO"
>
>
>
> On Sat, Jan 7, 2023 at 10:06 AM Stephen Adolph 
> wrote:
>
>> Hello all you T200 REX# owners!
>>
>> Attached is a couple of RAM images that contain the ROMULUS Chess
>> program!  They are compatible with REX# running Release 2.1.  I don't know
>> if they will also work with REX.  Perhaps someone can give it a try!
>>
>> Instructions on how to load the RAM images and run the game are included
>> in the attachment.
>>
>> Does NOT work in VirtualT.
>>
>> Let me know if you find any problems.
>>
>> If anyone is interested, it is would be possible to make a binary RAM
>> image that could be loaded with some new utility.
>> I can supply clean raw images, if someone wants to write a loader that
>> could read the binary data into the T200 over serial.
>>
>> A loader in the style of Wilson Van Alst would be good.  Read from TPDD
>> directly into RAM, and restart.
>>
>> cheers
>> Steve
>>
>>
>>
>>

Re: [M100] Detokenizer source published to Bitbucket

[Brian White]

Thank you.

-- 
bkw

On Sat, Dec 24, 2022, 2:09 AM John R. Hogerhuis  wrote:

> https://bitbucket.org/jhoger/detoke100/src/master/
>
>
> Definitely quick and dirty... not much to it. Has worked fine on stuff
> I've tried so far.
>
> -- John.
>

Re: [M100] ongoing support for REX#, REXCPM.

[Brian White]

Man, I can't even get my bluetooth speakers working and start a book
playing in 15 minutes. I haven't even cleared away a spot to work in 15
minutes.

-- 
bkw

On Fri, Dec 23, 2022, 2:04 PM Stephen Adolph  wrote:

> As some of you may know, in the last couple of years since the pandemic,
> the price and availability of chips has been very challenging.
>
> I really want to keep REX# both available and affordable! To that end, I
> have been searching for sources for parts.  The great news is that I have
> been able to buy fairly large quantities of CPLDs and Flash memory to
> support REX#, and I am now very very well stocked.  In other words, REX#
> will be available for quite a while.  Also, I've invested in better test
> setups, and my cycle time to produce a REX# from parts to finished tested
> module is ~15min.
>
> REXCPM has different challenges.  The CPLD used for this design is larger,
> and harder to find.  Even worse, the price of SRAM has really shot up.  For
> those modules, I'm actively looking for reasonably priced supply.  So,
> still a bit of an ongoing struggle.   The original voltage regulator was a
> part from Texas Instruments, and it appears to be no longer available.  I
> recently found a new part that actually works a bit better, and this new
> part is readily available.  So that's good.  Also, I have found some
> acceptable 4MB SRAMs, and I've ordered a quantity of those.
>
> Happy holidays to all.
> Steve
>
>
>
>

Re: [M100] QWERTZ ROM for T102

[Brian White]

rex classic main rom feature still requires desoldering the main rom for
T102. It only makes it possible to modify roms purely from software *after*
that one-time hardware mod. 100 is socketed from the factory.

You should be able to harmlessly desolder any chip by using ChipQuick or
FastChip desoldering alloy.

It's a special kind of solder that melts at a very low temperature, and
mixes with the existing solder and the chip just falls right out without
risk of damaging the pads.

Just search "chipquick" on youtube to see how it works.

-- 
bkw

On Fri, Dec 23, 2022, 9:51 AM Georg Käter <
georg.kae...@gk-engineering-services.de> wrote:

> Steve,
>
>
>
> thank you for the details of how REX works. This makes it now more clear
> for me.
>
> REX classic works properly with my T102 version w/o modem and so far all
> OPTION ROM
>
> I´ve tried (i.e. TS-DOS, MULTIPLAN) are working w/o any issue.
>
> Desoldering the main ROM is not an option for me anymore, I killed
> already a PCB
>
> on one of my T102 :-( (I own 5 in total) . Maybe "main ROM replacement" 
> feature
> of REX classic,
>
> might be the way to go for QWERTZ conversion for me.
>
>
> Thanks again for your support
>
>
>
> Kind regards
>
> Georg
>
>
> Georg Käter
> Gangolfsweg 44
> D-52076 Aachen
> Tel.: +49  2408 7194987
> Fax.: +49  2408 7196758
> Mobil: +49  171 4839954
> E-Mail   :
> georg.kae...@gk-engineering-services.de
>
> == Ihre Nachricht ==
>
> *von*  : Stephen Adolph 
> *gesendet* : Freitag, 23. Dezember 2022, 14:43
> *an*   : m...@bitchin100.com
> *Betreff*  : [M100] QWERTZ ROM for T102
>
> __ Originalnachricht ___
>
> Georg,
>
> After looking at this over and over I understand now.
> What you are saying is (let me repeat it back)
>
> * your T102 requires an option ROM to enable the use of the QWERTZU
> keyboard. (that option ROM is what you attached)
> * running this option ROM works well for you.
> * but this option ROM occupies the same place as REX, which prevents both
> from being used
> * so now you want to run this keyboard fixing ROM from inside REX
>
> Unfortunately, this cannot work.  I recently went through this with
> Cedric, who has a T200 with AZERTY keyboard.
> The problem is that the ROM program that fixes the keyboard does so by
> using the timer interrupt to intercept the keystrokes and convert them.
>
> REX# also uses the timer interrupt, and is fundamental to REX#
> operation.   This conflict can't be resolved.
>
> Also, because your T102 has no modem, the ROM is likely very incompatible
> with REX, and with option ROMs.
> So, you should probably be also trying to convert your T102 to use the USA
> main ROM so that option ROMs will work.
> (I don't know this for sure, however.  It depends on your exact main ROM).
>
> Secondarily (optionally) I also recommend however that you carefully study
> what Sarah Libman developed for the UK modem-less M100.
> http://sarahkmarr.com/retromodel100.html
> Sarah started from the stock M100 ROM, and modified it heavily to add
> functionality, while maintaining compatibility with M100 option ROMs.  Very
> cool.
>
> So your starting point could be Sarah's work, or it could be the Stock
> T102 ROM image.
> What you need to do is as follows:
>
> 1) you need to develop a patched main ROM for your TANDY 102 that is
> natively QWERTZU, and compatible with REX and Option ROMs.
> 2) you need to de-solder or otherwise remove your "factory" T102 Main
> rom.  (recommend capturing your original ROM Binary first!)
> 3) install a socket
> 4) burn a 27C256 with your patched T102 main ROM, install, verify keyboard
> works
> 5) then install REX#
>
> The good news is that you can follow the process I did for Tandy 200, and
> remap the T102 keyboard.
> I'm attaching the following:
>
> 1) the stock USA T102 ROM binary, which could be your starting point.  Or
> use Sarah's.  Or some hybrid.
>
> 2)  the T200 AZERTY spreadsheet that I used to compute the new keyboard
> matrix.  You would have to rework this to be T102 based, and to correct for
> QWERTZU.
>
> 3)  the disassembled portion of the T102 keyboard mapping starting at 7BF1H
> - this is the table of ascii codes that you need to modify, to convert
> from QWERTY to QWERTZU
>
> Once you have a prototype, you could try your new main ROM in VirtualT and
> see if it does what you want.
>
> Good luck.  A few hours of work and you will have this solved.
> Let me know if you have any questions.
>
> Steve
>
>
>
>
> On Fri, Dec 23, 2022 at 6:21 AM Georg Käter <
> georg.kae...@gk-engineering-services.de> wrote:
>
>> Dear all,
>>
>>
>>
>> by luck I got a very late T102 (build 1989) "German version" w/o modem
>> with installed QWERTZU ROM
>>
>> and it works like expected. Then I copied the ROM to REX to try similar
>> what is written in the installation
>>
>> description, loading QWERTZU ROM from REX is ok and can be enabled by a
>> CALL63012, 

Re: [M100] TS-DOS Option ROM

[Brian White]

The main REX info page has a large link that says "ordering information"

So far so good.

Following that link presents you with text that says "orders are accepted
via email".

It's not a big "buy!" button but it's hardly unclear.

At that point I think any sensible person is now on the lookout for an
email address. Yes, it's annoying that there wasn't a mailto: link right
there in that line.

And a few lines further down is something that is perhaps slightly cryptic,
but also cannot be explained any other way than by being an email address,
and it is far from uncommon to obfuscate email addresses on publicly
scrape-able web sites.

All in all, the prior text explaining that you need to send an email, and
the page as a whole, provides sufficient direction.

There is no store or cart system, but there absolutely is ordering
information as advertised.

It's at *worst*, ever so slightly 90's. Oh the baffling horror.

But there is no way it's actually any sort of minimum requirement or
obligation for an individual operating at this hobby scale to operate a
full shopping cart web site, or even an Etsy or ebay store, even if some
others do. "Order by email" is perfectly reasonable, and obfuscating that
email from scrapers is also reasonable, whether you happen to think it's
necessary or not.

You could always build your own classic REX
http://tandy.wiki/REX but I promise it's not as convenient as decrypting
that order page.

-- 
bkw

On Wed, Dec 21, 2022, 11:01 AM Wayne Lorentz  wrote:

> No, there isn't an ordering link on the Rex page.  Clicking on "Ordering
> information" just brings you to a page that lists prices and methods of
> payment.
>
> Perhaps it's my fault for not knowing that "twospruces / gmail" after the
> sign-off was supposed to be an e-mail address, and that I'm supposed to
> write a letter to someone at that e-mail address asking for information
> about how I can order their product.  My Little Orphan Annie Secret Decoder
> Ring is in the shop.  What I expected was a link to a PayPal, or other
> service ordering and payment page.  He already has a PayPal account.
> Making a proper, secure payment link only takes a few clicks.
>
> Gmail has the second-best spam protection on the planet (after FastMail).
> It's not perfect, but there's no reason to obfuscate a gmail address online
> anymore.  That hasn't worked for years.  Spambots know all the clever
> tricks already.
>
> While it's nice that everyone in this community is happy to vouch for him,
> how is someone who is not part of this mailing list supposed to know that
> he's not some fly-by-night scam artist?  Or perhaps dead, which happens all
> too often in retro computing?  Decode and send an e-mail, then wait six
> months for a reply that may never come?  Asking someone to send $100 to
> another country requires establishing a basic level of trust.
>
>
> On Dec 20, 2022, at 3:03 PM, m100-requ...@lists.bitchin100.com wrote:
>
> There's a ordering link on the Rex page
>
> https://bitchin100.com/wiki/index.php?title=REX
>
>
> https://bitchin100.com/wiki/index.php?title=Ordering_Information
>
> Steve's email is on that page but he encoded it so he doesn't get spam.
> Point is you can send him emails through that or he is also on this list.
>
>
>
>

Re: [M100] M100 Digest, Vol 144, Issue 18

[Brian White]

One thing you might try is, there are several tpdd clients that run on
ms-dos.

tandy.wiki/TPDD_client

There are 4 possible tpdd clients there that run on dos, plus some gwbasic.

Since Backpack is a tpdd server, it should work with any of those, although
there are often compatibility issues between particular clients and
particular servers, since neither is ever perfect. So until someone just
tries it, any or none of those might work completely.

All of those clients presumably work with a real drive. Some are only for
tpdd1, some only for tpdd2, but for normal file access both tpdd1 and 2
have the same set of commands, so most tpdd1 clients actually still work on
tpdd2, and Backpack advertises itself as a tpdd2 emulator, so in both cases
there is reason to just try everything that says ms-dos or gwbasic
regardless of drive type and that's 5 chances there for a client that works.

-- 
bkw

On Tue, Dec 20, 2022, 6:20 AM Hiraghm  wrote:

>
> Would that backpack also work with older DOS laptop computers, such as
> the Tandy 1400LT or Tandy 1100FD?
> > Original Message
> >
> > Message: 9
> > Date: Mon, 19 Dec 2022 09:17:01 -0600
> > From: 
> > To: 
> > Subject: [M100] Backpack drives are back!
> > Message-ID: <01c001d913bc$f27c92d0$d775b870$@soigeneris.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi all,
> >
> >
> >
> > A lot of folks have been asking when more Backpack drives will be
> available.
> > As you know the chip shortage has made some parts impossible to obtain,
> > including the microcontroller used in the original Backpack. My friend
> that
> > designed the original Backpack found a newly released AVR processor that
> was
> > actually available and designed the Backpack Drive Plus, or BPD+ if you
> > prefer. It looks the same and works the same with a slightly lower
> current
> > draw from the battery. He also made a number of adapters to use the
> Backpack
> > with computers like the WP2, Sinclair Z88, Epson HX-20, Epson PX-8. The
> > Epson's have a separate firmware to simulate the original Epson disk
> drives.
> >
> >
> >
> > We had a waiting list of folks who had asked for one and have worked
> through
> > that list so now ordering is open to the public. We are still 3D printing
> > cases and finishing the units up. If the stock level shows zero, try
> again
> > in a few days. When we run out, I will note that on the webpage.
> >
> >
> >
> > https://www.soigeneris.com/tandy-tpdd-2-backpack-drive-2
> >
> >
> >
> > Jeff Birt
> >
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <
> http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221219/459f6b05/attachment-0001.htm
> >
> >
> > --
> >
>

Re: [M100] TS-DOS Option ROM

[Brian White]

I'd suggest get a REX#, which comes with ts-dos pre-loaded.
http://www.bitchin100.com/wiki/index.php?title=REX

You could build a plain rom with only ts-dos,
http://tandy.wiki/Teeprom
but it ends up costing almost the same as a REX# anyway plus more work.

--
bkw

On Sun, Dec 18, 2022, 8:46 AM Wayne Lorentz  wrote:

> Does anyone know if TS-DOS option ROMS are still being sold anywhere?  I'd
> like to use one with TPDD Backpack.
>
> All the online searches point to the Bitchin' 100 web site, which doesn't
> appear to have been updated in 15 years.

Re: [M100] Model 102 - Help needed: OPTION ROM stopped working

[Brian White]

Sounds like likely a simple mechanical problem of bent pins not making good
contact.
Do all the pins in the socket make good contact with the rom?

You obviously didn't do anything too bad like kill the 5v supply in the
102 or kill the chip if both the 102 still runs and the chip still works
in other machines.

One thing you can do just to verify the mechanical contact between the
socket and the rom is, just insert the rom and continuity test each pin
from the socet to the rom adapter. There is enough socket pin
still exposed to touch a meter probe to the socket pin whike the rom is
plugged in, and you should be able to get
the other meter probe to touch the pad on the rom adapter without touching
the
socket pin if you're careful, or touch the pin on the chip but remember
to account for the pin re-mapping for some pins. Basically individually
test the continuity from the socket to the chip adapter for each pin.


Another thing you can do to test the electronics feeding most pins
inside the 102 without taking everything apart, is check with a
continuity tester setting on a multimeter, between equivalent pins on
the option rom socket and the system bus connector on the back. Only a
couple
pins like /CS and /OE are going to be isolated just to the socket. vcc,
gnd, address and data lines are all shared.

Get the pinouts for both ports from the service manual
https://archive.org/details/tandy102servicemanual/page/n27/mode/2up
Wow, Never noticed the 102 service manual barely even mentions the
option rom socket. No pinout or interface description like all the other
ports. But you can get the pinout from the schematic, top center page
68, and the system bus over to the right same page. So you can see AD0
is pin 11 on the optrom and pin 5 on the bus connector.

The ALE, /CS, and /OE pins won't have any copy but the rest will. To test
those few pins you'll need more than a meter, you'll need a scope to tell
if they pulse while you try to access the opt rom. But at least a cheap toy
scope is good enough for these speeds. But that's getting fancy and you can
do the simpler stuff first.

-- 
bkw


On 11/27/22 08:31, Georg Käter wrote:
> Dear all,
>
> one of my Model 102 does not recognize OPTION ROM or REX anymore. I´ve
> tried the moduls
>
> in a M100 and an other M102 and the modules are working as expected.
>
> What I did before was trying a self assembled ROM adapter in the OPTION
> ROM socket which might
>
> have cause a shortcut or something else and might finally has destroyed
> something.
>
> Except from this the M102 runs fine so far, but after a CALL63012 the
> system just hangs and needs a reset
>
> Now my question: Which part or pins I can check easily to identify and
> solve the problem.
>
> Thanks in advance for any hints
>
> Regards
>
> Georg
>
> Georg Käter
> Gangolfsweg 44
> D-52076 Aachen
> Tel.: +49  2408 7194987
> Fax.: +49  2408 7196758
> Mobil: +49  171 4839954
> E-Mail   :
>
> georg.kae...@gk-engineering-services.de
> 
>
> *Vertraulichkeitsinformation:
> *Diese Nachricht ist vertraulich. Die Informationen dieser Nachricht
> sind ausschließlich für die persönliche
> und vertrauliche Verwendung durch den/die oben genannten Empfänger
> bestimmt. Wenn Sie kein beabsichtigter
> Empfänger sind, bitte lesen, kopieren und verwenden Sie die Nachricht
> nicht. Machen Sie sie nicht anderen
> zugänglich. Bitte informieren Sie uns umgehend über den Zustellfehler
> und senden Sie die Originalnachricht
> per E-Mail an uns zurück.
>
> *Confidentiality Notice:
> *This message is confidential. The information contained in this message
> is intended only for the personal
> and confidential use of the recipient(s) named above. If you are not the
> intended recipient, please do not
> read, copy, or use it and do not disclose it to others. Please inform us
> immediately of the delivery error
> and return the original message to us via e-mail.

bkw

Re: [M100] custom key mapping generator for Tandy 200

[Brian White]

"We're never going to resolve this problem you have."

-- 
bkw

On Thu, Nov 17, 2022, 10:34 PM Mike Stein  wrote:

> And you too never disappoint ;-) Obviously you and I will never resolve
> whatever your problem is with me (and John?)
>
> The discussion in question was indeed a total waste of time (as a few
> others in the past) and I think I'm entitled to choose how to spend my
> time; life's getting shorter all the time...
>
> I rarely contribute anything anyway, certainly nothing that smarter folks
> won't also come up with, so as I said, I'll leave it up to them while I
> spend more time elsewhere; you've certainly contributed an impressive
> amount of knowledge and hardware to the community and I'll definitely
> continue to follow this list for useful information and just the sense of
> community.
>
> m
>
>
>
> On Thu, Nov 17, 2022 at 6:56 PM Brian K. White 
> wrote:
>
>> On 11/17/22 16:23, MikeS wrote:
>>
>> > I think in future I'll refrain from wasting time
>>
>> Promise?
>> I was ready to acknowledge and apologize because you're right, I didn't
>> really get that at first and did replicate something already said. But
>> then you went and remained the same MikeS as always. So by all means
>> refrain away in the future.
>>
>> --
>> bkw
>>
>>

Re: [M100] Bitchin' 100 on Bing

[Brian White]

I don't know whether to thank you more for fixing the error or for
providing the unheard of fantasy of actually getting an answer about
something involving a huge faceless uncaring machine!

My mental model of this was like, bitchin100 is like a little sandcastle
someone built next to the ocean, and the ocean flattened it. There's
nothing you can do about that except build your sandcastle somewhere else
or not out of sand. What is unimaginable is complaining to the ocean and
the ocean responds!


bkw

On Mon, Nov 14, 2022, 7:00 AM Ken St. Cyr  wrote:

> Hi folks –
>
>
>
> Long time reader, first time poster 
>
>
>
> I work at Microsoft, so I reached out to the Bing team internally to see
> if they could help. It looks like some of the wiki pages were triggering a
> block on our end. I don’t know the specifics, but one of the engineers
> removed the block this morning and he told me that it will be a few days
> before it takes effect. Bing is a large product, so I’m sure whatever they
> did needs time to propagate. Give it until the end of this week, and if
> search results still aren’t coming back, then I’ll circle back around with
> the Bing team again.
>
>
>
> I appreciate you all – the conversations and information shared here
> within this community are absolutely amazing!
>
>
>
> //Ken S.
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Sunday, November 13, 2022 3:54 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Bitchin' 100 on Bing
>
>
>
> " So would it be of benefit to contact the owner of 'Bitchin'100' to
> update their web indexing per the different search engines such as Bing?"
>
> I did, it has made no difference yet.
>
> I submitted a support request through the webmaster tools, I guess we'll
> see.
>
>
>
> It would be much better if they provided public, searchable reasons for
> content removal. They do have some kind of removal records but they make no
> effort to help you find your needle in that haystack.
>
> And given they're a "search engine" I assume this is the way they want it.
>
>
>
> -- John.
>

Re: [M100] custom key mapping generator for Tandy 200

[Brian White]

The datasheet says to rest vpp at vcc. Most do, even if elsewhere they also
say that writing is disabled as long as vpp is below vpp and the only low
limit is pretty much the same as for any other pin, like 0.5 or 0.7 below
vcc.

I never saw a reason why, but it's definitely a consistent suggestion in
datasheets to hold vpp at vcc rather than gnd.

Maybe holding it at gnd wastes a little power or stresses a gate somewhere
through reverse leakage and vcc is closer to where that gate is when
running. So, it may still be true that any voltage from gnd to vcc is legal
and functional, yet one is still better than the other.


bkw

On Mon, Nov 14, 2022, 12:19 AM Mike Stein  wrote:

> Too bad I don't have a 200; you're probably right but since it's not
> clearly defined in the data sheet I'll have to dig out one of my other
> systems using a 2764 and check it for myself ;-)
>
> But I have to ask: why pull pin 27 to Vcc? What happens if you pull it low?
>
> On Sun, Nov 13, 2022 at 9:06 PM Brian K. White 
> wrote:
>
>> 27C64 can't be used as-is.
>> pin 27 is A15 and needs to needs to go to a non-existing 2nd OE or CE.
>>
>> You'd need an adapter board that combines pin 27 (A15) from the socket,
>> with pin 22 /CE0 (/BANK#1) from the socket, to produce a single /CE to
>> pin 22 of the chip.
>>
>> You could do that with a single 2-gate NAND part the same as in this
>> model 200 RAM
>> https://github.com/bkw777/TANDY_200_RAM#single-bank---sop
>>
>> https://raw.githubusercontent.com/bkw777/TANDY_200_RAM/main/TANDY_200_RAM.svg
>>
>> That is using one nand gate just to invert /CS1 to CS1,
>> then ANDing those to make a single CS, and inverting that to make a
>> single /CS output to the chip's /CE
>>
>> The point is getting the job done with only 2 gates of the same type so
>> it's all from a single part.
>> They even make little 8-leg parts with just the 2 needed gates.
>>
>> For 27C64 you'd need to do that with /CE0 from bus pin 22 and CE1 from
>> bus pin 27, to produce a single /OE to chip pin 22. And chip pin 27
>> pulled to VCC by anything from 100k to a plain trace. All other pins
>> including /CS would go 1:1 socket to chip.
>>
>>
>> On 11/13/22 19:38, Mike Stein wrote:
>> > Duh; shoulda looked more carefully; it really IS A15 (not A13) and it
>> > goes to /CE1 (or CE1); double duh! Thanks, Brian.
>> >
>> > So it looks like the only non-standard pin is pin 27, since 26 is not
>> > used. Has anyone actually tried a JEDEC standard  27C64?
>> >
>> > Pin 27 is the Program pin which looks like it might effectively be an
>> > active high OE (since there is no program voltage.
>> >
>> > m
>> >
>> >
>> >
>> > On Sun, Nov 13, 2022 at 5:27 PM Brian White > > <mailto:b.kenyo...@gmail.com>> wrote:
>> >
>> > 8k.
>> >
>> > HN61364 = 8k
>> > A15 is connected to a chip select to enable/disable the whole chip
>> > (really just output enable not chip enable despite the /CEx labels),
>> > and the actual address lines are only A0-A12
>> >
>> > It's mostly like 27C64 but with 3 OE lines, customer programmable to
>> > be either active high or low as part of the mask programming.
>> > Although the schematic labels them as /CE0 /CE1 /CE2, really they
>> > are all OE not CE, and it appears that /CE1 should be shown as
>> > active-high, so really: /OE0, OE1, /OE2 , and /CS is a normal actual
>> > whole chip enable, active low.
>> >
>> > I was just now in the middle of drawing up an adapter for that chip
>> > like FlexROM_102 but for that chip, to facilitate using the main rom
>> > replacement feature of REX Classic in a 200 the way I have already
>> > for 100 and 102.
>> >
>> > But it may be simpler to make a different kind of adapter that
>> > replaces both chips with a single larger chip on a single adapter in
>> > the main rom socket and simply remove the 8k chip. The /BANK1 line
>> > goes to both chips the same, and A15 ends up activating one or the
>> > other exclusively at any given moment.
>> >
>> > bkw
>> >
>> > On Sun, Nov 13, 2022, 4:48 PM Mike Stein > > <mailto:mhs.st...@gmail.com>> wrote:
>> >
>> > Looking at the schematic, are you sure it's 8K and not 16
>> (27x128)?
>> >
>> > Looks standard except for pins 26 & 27
>> >
>> > On Sun, Nov 13, 2022 at 

Re: [M100] custom key mapping generator for Tandy 200

[Brian White]

On Sun, Nov 13, 2022, 5:27 PM Brian White  wrote:

> 8k.
>
> HN61364 = 8k
> A15 is connected to a chip select to enable/disable the whole chip (really
> just output enable not chip enable despite the /CEx labels), and the actual
> address lines are only A0-A12
>
> It's mostly like 27C64 but with 3 OE lines, customer programmable to be
> either active high or low as part of the mask programming. Although the
> schematic labels them as /CE0 /CE1 /CE2, really they are all OE not CE, and
> it appears that /CE1 should be shown as active-high, so really: /OE0, OE1,
> /OE2 , and /CS is a normal actual whole chip enable, active low.
>
> I was just now in the middle of drawing up an adapter for that chip like
> FlexROM_102 but for that chip, to facilitate using the main rom replacement
> feature of REX Classic in a 200 the way I have already for 100 and 102.
>


To clarify, for 200, you would use a FlexROM_102 in the main rom socket,
with it's /CS_out going to the REX's TP1, same as for a 102.

And the new adapter in the 8K socket, with it's /OE0 (pin 22) going to the
REX's TP2

And both of those would have their own return wires also going to the
optrom compartment, so that you could remove the REX and connect the wires
to each other in the optrom compartment to boot from the internal roms
instead of REX without having to open the 200's case any more.






> But it may be simpler to make a different kind of adapter that replaces
> both chips with a single larger chip on a single adapter in the main rom
> socket and simply remove the 8k chip. The /BANK1 line goes to both chips
> the same, and A15 ends up activating one or the other exclusively at any
> given moment.
>
> bkw
>
> On Sun, Nov 13, 2022, 4:48 PM Mike Stein  wrote:
>
>> Looking at the schematic, are you sure it's 8K and not 16 (27x128)?
>>
>> Looks standard except for pins 26 & 27
>>
>> On Sun, Nov 13, 2022 at 4:23 PM Stephen Adolph 
>> wrote:
>>
>>> Georg,
>>> What type of ROM chips did you use, when you replaced your ROMs with
>>> patched versions?
>>> I've been pondering what the simplest way to do that is.
>>> The 8K M13 socket is wired oddly, and doesnt seem compatible with a
>>> 27C64.
>>> thx
>>> Steve
>>>
>>> On Sun, Nov 13, 2022 at 12:30 PM Georg Käter <
>>> georg.kae...@gk-engineering-services.de> wrote:
>>>
>>>> Hello together,
>>>>
>>>>
>>>>
>>>> I own a M200 "German/EU Version" (Art.Nr. 26-3860H) w/modem, for German
>>>> market it was delivered with set of keyboard
>>>>
>>>> caps and a data tape including driver for keyboard and printer. I tried
>>>> this in VirtualT and it seems to work so far. To run REX
>>>>
>>>> on my M200 I replaced original ROM by ROM from VirtualT patched to
>>>> serve german keyboard mapping.
>>>>
>>>> For your reference I´ve added original ROM files and files from tape
>>>> for your reference.
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> Georg
>>>>
>>>>
>>>> Georg Käter
>>>> Gangolfsweg 44
>>>> D-52076 Aachen
>>>> Tel.: +49  2408 7194987
>>>> Fax.: +49  2408 7196758
>>>> Mobil: +49  171 4839954
>>>> E-Mail   :
>>>> georg.kae...@gk-engineering-services.de
>>>>
>>>> == Ihre Nachricht ==
>>>>
>>>> *von*  : Cedric Amand 
>>>> *gesendet* : Sonntag, 13. November 2022, 15:37
>>>> *an*   : m...@bitchin100.com
>>>> *Betreff*  : [M100] custom key mapping generator for Tandy 200
>>>>
>>>> __ Originalnachricht ___
>>>>
>>>> My point exactly Brian !
>>>> How did they come up with that idea ? It makes no sense. It really
>>>> prevents you from using the option rom socket.
>>>> The docs does not talk about removing it.
>>>>
>>>> And even if you could remove it ; the installation procedure of that
>>>> ROM is not easy at all, requires to type two "calls" with the freaking
>>>> keyboard inverted.
>>>> OK - us nerds 40 years later can do it easily, just type "CQLL", but
>>>> imagine explaining that to a random journalist in 1984 ?!
>>>> Especially as the french doc (which I happen to have) says to type
>>>> "CALL"

Re: [M100] custom key mapping generator for Tandy 200

[Brian White]

8k.

HN61364 = 8k
A15 is connected to a chip select to enable/disable the whole chip (really
just output enable not chip enable despite the /CEx labels), and the actual
address lines are only A0-A12

It's mostly like 27C64 but with 3 OE lines, customer programmable to be
either active high or low as part of the mask programming. Although the
schematic labels them as /CE0 /CE1 /CE2, really they are all OE not CE, and
it appears that /CE1 should be shown as active-high, so really: /OE0, OE1,
/OE2 , and /CS is a normal actual whole chip enable, active low.

I was just now in the middle of drawing up an adapter for that chip like
FlexROM_102 but for that chip, to facilitate using the main rom replacement
feature of REX Classic in a 200 the way I have already for 100 and 102.

But it may be simpler to make a different kind of adapter that replaces
both chips with a single larger chip on a single adapter in the main rom
socket and simply remove the 8k chip. The /BANK1 line goes to both chips
the same, and A15 ends up activating one or the other exclusively at any
given moment.

bkw

On Sun, Nov 13, 2022, 4:48 PM Mike Stein  wrote:

> Looking at the schematic, are you sure it's 8K and not 16 (27x128)?
>
> Looks standard except for pins 26 & 27
>
> On Sun, Nov 13, 2022 at 4:23 PM Stephen Adolph 
> wrote:
>
>> Georg,
>> What type of ROM chips did you use, when you replaced your ROMs with
>> patched versions?
>> I've been pondering what the simplest way to do that is.
>> The 8K M13 socket is wired oddly, and doesnt seem compatible with a 27C64.
>> thx
>> Steve
>>
>> On Sun, Nov 13, 2022 at 12:30 PM Georg Käter <
>> georg.kae...@gk-engineering-services.de> wrote:
>>
>>> Hello together,
>>>
>>>
>>>
>>> I own a M200 "German/EU Version" (Art.Nr. 26-3860H) w/modem, for German
>>> market it was delivered with set of keyboard
>>>
>>> caps and a data tape including driver for keyboard and printer. I tried
>>> this in VirtualT and it seems to work so far. To run REX
>>>
>>> on my M200 I replaced original ROM by ROM from VirtualT patched to serve
>>> german keyboard mapping.
>>>
>>> For your reference I´ve added original ROM files and files from tape for
>>> your reference.
>>>
>>>
>>>
>>> Regards
>>>
>>> Georg
>>>
>>>
>>> Georg Käter
>>> Gangolfsweg 44
>>> D-52076 Aachen
>>> Tel.: +49  2408 7194987
>>> Fax.: +49  2408 7196758
>>> Mobil: +49  171 4839954
>>> E-Mail   :
>>> georg.kae...@gk-engineering-services.de
>>>
>>> == Ihre Nachricht ==
>>>
>>> *von*  : Cedric Amand 
>>> *gesendet* : Sonntag, 13. November 2022, 15:37
>>> *an*   : m...@bitchin100.com
>>> *Betreff*  : [M100] custom key mapping generator for Tandy 200
>>>
>>> __ Originalnachricht ___
>>>
>>> My point exactly Brian !
>>> How did they come up with that idea ? It makes no sense. It really
>>> prevents you from using the option rom socket.
>>> The docs does not talk about removing it.
>>>
>>> And even if you could remove it ; the installation procedure of that ROM
>>> is not easy at all, requires to type two "calls" with the freaking keyboard
>>> inverted.
>>> OK - us nerds 40 years later can do it easily, just type "CQLL", but
>>> imagine explaining that to a random journalist in 1984 ?!
>>> Especially as the french doc (which I happen to have) says to type
>>> "CALL" not CQLL.
>>>
>>> I also wonder if other markets are affected by this plague,
>>> If anyone here lives in germany and owns a qwertz (or other keyboard
>>> variant) of the M200 : do you have a "stock option ROM" as well ?
>>>
>>> I also wish to thank Stephen publicly for the time he invested into
>>> helping me, as indeed, you can't use an option ROM (and even less a REX#)
>>> in those non-qwerty  M200s, and I think this research might help some other
>>> people at some stage (this hobby is booming right ? :) )
>>>
>>> We're (and I am) in the process of replacing the main rom + 8KB rom with
>>> a 27C512 flashed with a custom "native Azerty" firmware
>>> Which should free up to option socket, for a REX#
>>>
>>> I also plan to make other modifications to that custom ROM, but we'll
>>> see if I get there.
>>>

Re: [M100] custom key mapping generator for Tandy 200

[Brian White]

Nice.

So the point would be to make the main rom natively azerty to match the
hardware, free up the option rom slot for normal use, without otherwise
changing the main rom so that it becomes incompatible with application
software? I guess you might even be able to make a dvorak version and move
the keycaps around?

I'm just trying to imagine the sales pitch for that azerty 200 that needs
the option rom, thus preventing the use of any other option rom (or at
least making it pretty inconvenient by having to swap them on every reset I
guess?)

"Here's your new model 200. It's only half as useful as others with no
modem and no option rom but you can still pay full price please."

-- 
bkw

On Sun, Nov 13, 2022, 8:28 AM Stephen Adolph  wrote:

> hi folks,
>
> Thought I would share this work.  It is a spreadsheet for computing the
> keyboard table in the T200 so you can make native custom keyboards for T200.
>
> Why?
> The AZERTY keyboard in Europe was accommodated using an option ROM that
> kinda hacked the keyboard.  Keystrokes get intercepted and corrected to be
> AZERTY even though the main ROM is set up for QWERTY.
>
> An alternative is to have the main rom directly support AZERTY.
> To do this, there are 6 keyboard mapping tables that start at 9763h.  Each
> table are 44 bytes long.
>
> This spreadsheet lets you assign the ascii codes for each of the 44
> affected keys, for all 6 tables. (unshifted, shifted, GRAPH, shift GRAPH,
> CODE, Shift CODE).
>
> It is an excel spreadsheet that included the analysis add it so that
> certain needed functions are present.
>
> Once you make the correct keyboard mapping, the spreadsheet provides the
> 6x44 bytes in assembly compatible form, so you can compile and patch the
> tables with a hex editor.
>
> This approach could be used for other machines also.
> Note - the AZERTY keyboard did NOT modify the actual character set, so
> that is out of scope.  Of course it is possible to patch the main ROM to
> change the bitmaps as well.  Not handled by this spreadsheet.
>
> Comments welcome.
> Steve
>
>

Re: [M100] Bitchin' 100 on Bing

[Brian White]

Turning safe search off does not produce links to bitchin100.com .


bkw

On Sun, Nov 13, 2022, 8:01 AM  wrote:

> This is a case of RTFM. It all has to do with how one has their ‘Safe
> Search’ settings configured. The default is ‘Strict’ which seems to set up
> to block many things including grade school naughty words like ‘bitchin’.
> If you set ‘Safe Search’ to ‘Moderate’ then your search for ‘bitchin100’
> will show you results.
>
>
>
> If the ‘net nannies’ at your employer insist on asserting on control over
> every possible setting you may not be able to change the ‘Safe Search’
> setting. I can’t on my work computer. This is a problem with your IT
> overloads though, not BING.
>
> A few months ago, many folks were having problems sending email from other
> domains to Gmail accounts. Google would seemly randomly, and silently,
> block them. You could send the same email 15 minutes apart and one would be
> blocked but not the other. If you send the same email from Gmail to Gmail
> account it was fine. After configuring my email to be signed, etc. and the
> burning of sage it finally started working better. I have also randomly had
> a few ISPs around the world block my domain even though it has never been
> on any blacklist. In these cases, I have had to contact my host, who
> contacts them, and problem resolved.
>
> None of the above instances were capricious or arbitrary they are all
> actions automatically taken by some ‘algorithm’ which by its very nature is
> imperfect. It is imperfect as it was coded by humans who are imperfect.
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Saturday, November 12, 2022 8:00 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Bitchin' 100 on Bing
>
>
>
> It's happening to me.
>
> Try this search on Bing versus Google
>
>
>
> model 100 rex site:bitchin100.com
>
>
>
> On bing it says "Some results have been removed'
>
> Actually it produces not results, so ALL results have been removed.
>
> On Google you get what you're looking for.
>
> And clearly this is on purpose, but they don't give any clear recourse for
> correcting it.
>
>
>
> -- John.
>
>
>
>
>
> On Sat, Nov 12, 2022 at 5:11 PM Peter Noeth  wrote:
>
> I have never had Bing searches exclude results from bitchen100.com. I
> have had the default DNS server that my ISP loads when I start my web
> browser (MS New Edge on Win7), fail to find known webpages, by name. I
> switched the browser DNS server to Google, and haven't had any more
> problems.
>
>
>
> Regards,
>
> Peter
>
>
>
>

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[Brian White]

I just can't get over some of that stuff from Bing about "we like quality
sites..."

who the what the ever loving F , where do you even begin with that

bkw

On Sat, Nov 12, 2022, 3:20 AM Brian White  wrote:

> wow, that article and the others linked from there are quite enlightening.
>
> I hate to help create a monoculture and single supplier and overlord, but
> it looks like Bing and all of it's resellers should just not be used.
>
> That really sucks because I really hate how much power g already has.
>
> You'd think Bing or any search engine should want to accept reports from
> any random user not just site owners, and it shouldn't matter if a site
> owner is willing to satisfy them. It is valuable to some site owners to be
> listed, so for some there may be that power dynamic where the engine may
> dictate to sites and sites will perform.
>
> But what about the users? The engine purports to be providing a service of
> search results to me a searching user. So in the apparently polyanna
> fantasy world I should be able to say to Bing "hey, bug report, here is
> some stuff on the net that you're failing to show" and they should consider
> that a problem just based on that logic, regardless whether the site owner
> cares to have any special relationship with Bing.
>
> It's almost like Bing doesn't show you what exists, it just shows you the
> sites that pay to be seen. Not literally in money but in cooperation in
> whatever kind of user manipulation game they are playing.
>
> I know google exerts the same sort of editorial control themselves though,
> so, it's not like they're really any better in principle.
>
> --
> bkw
>
> On Sat, Nov 12, 2022, 1:16 AM John R. Hogerhuis  wrote:
>
>>
>>
>> On Fri, Nov 11, 2022 at 7:21 PM Brian K. White 
>> wrote:
>>
>>> On 11/11/22 18:59, B 9 wrote:
>>> > On a tangent: I need to work on my searching skills. It occurred to me
>>> a
>>> > while ago that the Tandy 200 schematic looked like the RTS/CTS lines
>>> > were fully wired, but when I searched for things like "model 100
>>> serial
>>> > port rts cts", I never saw that page... Oh! Wait. The problem may have
>>> > been that I was googling with DuckDuckGo. I'm able to get
>>> bitchin100.com
>>> > <http://bitchin100.com> as the first result when I search for "model
>>> 100
>>> > uart", but only on Google.
>>>
>>>
>>> I have noticed this for probably 2 or more years now. I've been meaning
>>> to say something but never did. It's like bitchin100 is blacklisted on
>>> DDG, (and thus, probably on Bing too). Not only do none of the wiki
>>> pages show up, even if you search for literally "bitchin100.com", you
>>> can scroll for pages and pages of results forever and never get a single
>>> link to any bitchin100.com url, only references to it in other pages,
>>> mostly archived mail list posts on Narkive.
>>>
>>>
>> I don't know. I only ever search on Google. The progression for me was
>> Gopher, then Altavista, Yahoo, and now Google. Each better than the last,
>> haven't felt any compelling need to switch again. Privacy? That ship has
>> sailed, went into orbit, crashed into the an asteroid, merged with
>> alien spores and is sentient.
>>
>> And DDG/Bing already don't like me, so...
>>
>> Maybe Dreamhost IPs are the issue?
>>
>> As to spammers, some spam was loaded onto the wiki at some point, but it
>> wasn't there very long and I cleaned it up. I think it probably predates
>> DDG and Bing, and Google has never cared. But that spam attack is why I
>> make accounts upon request from members.
>>
>> URL rewriting... I could do that. But I don't see how it would help.  I
>> cannot think of a URL scheme that you could easily infer article titles.
>>
>> Most of Bitchin100 is the wiki. To link, I type bitchin100.com/wiki into
>> my url bar, then search in the mediawiki search, find the result, and then
>> copy and paste the URL.
>>
>> "tandy.wiki/REX"
>>
>> Most of the articles on bitchin100 have longer titles.
>>
>> B100 links are like
>>
>> bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface
>>
>> rewriting I guess could skip the "wiki/index.php?title=" boilerplate.
>>
>> But you'd still need memorize the exact article title... 9/10 I'd end up
>> having to search anyway... so I don't see the difference.
>>
>>
>> Here's an interesting article on Bing/DDG
>>
>>
>> https://www.jessesquires.com/blog/2022/03/25/my-website-disappeared-from-bing-and-duckduckgo/
>>
>> Sounds like Bing is the way to get your site into DDG.
>>
>> -- John.
>>
>

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[Brian White]

wow, that article and the others linked from there are quite enlightening.

I hate to help create a monoculture and single supplier and overlord, but
it looks like Bing and all of it's resellers should just not be used.

That really sucks because I really hate how much power g already has.

You'd think Bing or any search engine should want to accept reports from
any random user not just site owners, and it shouldn't matter if a site
owner is willing to satisfy them. It is valuable to some site owners to be
listed, so for some there may be that power dynamic where the engine may
dictate to sites and sites will perform.

But what about the users? The engine purports to be providing a service of
search results to me a searching user. So in the apparently polyanna
fantasy world I should be able to say to Bing "hey, bug report, here is
some stuff on the net that you're failing to show" and they should consider
that a problem just based on that logic, regardless whether the site owner
cares to have any special relationship with Bing.

It's almost like Bing doesn't show you what exists, it just shows you the
sites that pay to be seen. Not literally in money but in cooperation in
whatever kind of user manipulation game they are playing.

I know google exerts the same sort of editorial control themselves though,
so, it's not like they're really any better in principle.

-- 
bkw

On Sat, Nov 12, 2022, 1:16 AM John R. Hogerhuis  wrote:

>
>
> On Fri, Nov 11, 2022 at 7:21 PM Brian K. White 
> wrote:
>
>> On 11/11/22 18:59, B 9 wrote:
>> > On a tangent: I need to work on my searching skills. It occurred to me
>> a
>> > while ago that the Tandy 200 schematic looked like the RTS/CTS lines
>> > were fully wired, but when I searched for things like "model 100 serial
>> > port rts cts", I never saw that page... Oh! Wait. The problem may have
>> > been that I was googling with DuckDuckGo. I'm able to get
>> bitchin100.com
>> >  as the first result when I search for "model
>> 100
>> > uart", but only on Google.
>>
>>
>> I have noticed this for probably 2 or more years now. I've been meaning
>> to say something but never did. It's like bitchin100 is blacklisted on
>> DDG, (and thus, probably on Bing too). Not only do none of the wiki
>> pages show up, even if you search for literally "bitchin100.com", you
>> can scroll for pages and pages of results forever and never get a single
>> link to any bitchin100.com url, only references to it in other pages,
>> mostly archived mail list posts on Narkive.
>>
>>
> I don't know. I only ever search on Google. The progression for me was
> Gopher, then Altavista, Yahoo, and now Google. Each better than the last,
> haven't felt any compelling need to switch again. Privacy? That ship has
> sailed, went into orbit, crashed into the an asteroid, merged with
> alien spores and is sentient.
>
> And DDG/Bing already don't like me, so...
>
> Maybe Dreamhost IPs are the issue?
>
> As to spammers, some spam was loaded onto the wiki at some point, but it
> wasn't there very long and I cleaned it up. I think it probably predates
> DDG and Bing, and Google has never cared. But that spam attack is why I
> make accounts upon request from members.
>
> URL rewriting... I could do that. But I don't see how it would help.  I
> cannot think of a URL scheme that you could easily infer article titles.
>
> Most of Bitchin100 is the wiki. To link, I type bitchin100.com/wiki into
> my url bar, then search in the mediawiki search, find the result, and then
> copy and paste the URL.
>
> "tandy.wiki/REX"
>
> Most of the articles on bitchin100 have longer titles.
>
> B100 links are like
>
> bitchin100.com/wiki/index.php?title=Model_100_Serial_Interface
>
> rewriting I guess could skip the "wiki/index.php?title=" boilerplate.
>
> But you'd still need memorize the exact article title... 9/10 I'd end up
> having to search anyway... so I don't see the difference.
>
>
> Here's an interesting article on Bing/DDG
>
>
> https://www.jessesquires.com/blog/2022/03/25/my-website-disappeared-from-bing-and-duckduckgo/
>
> Sounds like Bing is the way to get your site into DDG.
>
> -- John.
>

Re: [M100] Keep getting DS ERROR when loading via serial.

[Brian White]

Oh yeah, that too.

And unix LF-only line-endings.
BASIC (on these machines) can take either CRLF or CR-only, but not LF-only.
But I think in most cases pasting into a terminal program would probably
generate new line-endings, so even if the original file had LF, the term
program may output CRLF to the remote end depending on it's settings.

-- 
bkw

On Sat, Oct 22, 2022, 9:09 AM Joshua O'Keefe 
wrote:

> > On Oct 21, 2022, at 10:32 PM, r Gi  wrote:
> > 
> > I am repeatedly getting a DS ERROR most of the time when I try to load a
> program. It happens a short time after starting the upload. Any help would
> be appreciated
>
> Nearly all of the DS ERRORs I have received while reading BASIC programs
> over serial have been victims of formatting errors.  There are many on the
> internet, particularly in the CompuServ archive, that have been line
> wrapped.  I've run into this with programs OCRed from books as well.
>
> Just as if you were typing the program, hitting Enter too early and then
> continuing to type would execute a direct statement.  Doing so is not
> allowed while you're LOADing.  That's what happened to me while loading
> these various files.
>
> Fixing the line wrapping solves the issue.

Re: [M100] Keep getting DS ERROR when loading via serial.

[Brian White]

For loaing into BASIC, use a bootstrapper to send the file, which inserts a
delay in between each byte exactly to avoid that problem.

http://github.com/bkw777/tsend for windows
or http://github.com/bkw777/dlplus for anything else.

Loading a file directly into BASIC is not like a normal plain data transfer
that merely copies data, it's essentially typing into the interactive
interpreter, which means the interpreter does work on each byte entered,
and the amount of work varies depending on the code being entered, what
part of a line it is in, what part of a statement it is in, and what kind
of statement, etc.

So some bytes are simply stored and takes no time and it's ready for the
next byte quickly. Some bytes trigger some work behind the scenes and it's
not ready for the next byte for several ms. But the sending side has no way
to know that (the software-only flow control doesn't work well enough) and
just sends bytes without stopping or pausing.

Some serial comm programs have an advanced setting for inserting a delay
between each byte, but only some, and even some that have it, don't apply
it consistently. TeraTerm has a setting for that, but it only applies to
the terminal window, not to file transfers. If you set that setting, and
then used the file transfer dialog to do an ascii transfer, it does not
apply the per-byte sleep. You have to paste the file into the terminal
window to mimic typing it.

I think another way to handle it is just send the file at a lower baud rate
like 4800 or 1200 instead of 19200. But for some reason I've never actually
tried that for loading into BASIC, just when using TELCOM to access another
machine like a bbs, so I can't say for sure if that actually eliminates the
problem reliably.

For loading into BASIC I always use a bootstrapper which is designed just
for that.

Both programs above include a little helper/reminder prompt showing you the
exact RUN:.. command to type in BASIC to receive the file and run it on the
spot, but you can just use LOAD in place of RUN.

And really, I only use a bootstrapper when I want to run-and-discard the
program, generally for installers.

If I just want to copy a file to the 100, I use TPDD. Use the boostrapper
just to install TS-DOS or TEENY or DSKMGR, then use dlplus (link above) or
LaddieAlpha (link below)on the pc side and ts-dos etc on the 100 to
transfer any kind of file in either direction with no worries about baud
rates or corruption or errors.

And really, the even better answer is to get a REX# and have ts-dos in rom
instead of in ram. Installing ts-dos in ram consumes 5k or so of ram. TEENY
is smaller but less convenient.

http://bitchin100.com/wiki/index.php?title=LaddieCon#LaddieAlpha

http://bitchin100.com/wiki/index.php?title=REXsharp

-- 
bkw

On Sat, Oct 22, 2022, 1:33 AM r Gi  wrote:

> I am repeatedly getting a DS ERROR most of the time when I try to load a
> program. It happens a short time after starting the upload. Any help would
> be appreciated
>

Re: [M100] Planning out some weekend projects.

[Brian White]

I didn't read that as in any way negative.
Basically you just created the only negativity.

bkw

On Wed, Oct 19, 2022, 2:47 PM John R. Hogerhuis  wrote:

>
>
> On Wed, Oct 19, 2022 at 11:03 AM Peter Vollan 
> wrote:
>
>> 36 dollars just for that?! For god's sake, you should have asked us
>> first, there's lots of other places.
>>
>>>
>>>
> Please keep the discussion positive. In any event I think he was
> discussing potential ideas for his next projects.
>
> I have no idea what that resistor should cost but no matter what it's his
> money to spend if he wants to. No call to hassle/tease.
>
> -= Model T's Forever =-
>
> -- John.
>
>
>

Re: [M100] RexCPM install

[Brian White]

It actually works from cygwin? I've actually never even tried it. (dlplus I
mean, I used to use cygwin all the time but not in the last several years).
I figured if WSL doesn't work then not even worth trying cygwin.

I will try it and update the readme because this would be great.


bkw

On Sun, Oct 16, 2022, 5:33 PM Ben Wiley Sittler  wrote:

> I regularly use dlplus from a Cygwin command-line shell interface in
> Windows too, but I realize that's not everyone's cup of tea
>
> On Sun, Oct 16, 2022, 14:29 Brian K. White  wrote:
>
>> On 10/16/22 14:17, Stephen Adolph wrote:
>> > Hi Robert, couple of comments.
>> >
>> > 1) test your REXCPM.  you can always test it yourself and see if you
>> > have a hardware problem
>> > https://bitchin100.com/wiki/index.php?title=REXCPM
>> > 
>> > read up on how to load and run REXCPM.
>> > I would not do this if you are happy with the REX# part of the
>> install.
>> > In fact if that is working, likely no hardware problem.
>> > There is only one memory chip and it is used for both REX# and CPM.
>> >
>> > 2)  Philip's routines more or less rely on LaddieAlpha to operate.  I
>> > would recommend you use LaddieAlpha as the TPDD client.
>>
>> Laddie is a server not a client. You confuse things by insisting on
>> using the wrong terminology in what are supposed to be reference
>> documents.
>>
>> I routinely use dlplus to reload rexcpm. But that's only available from
>> linux or mac. In fact thanks to the fact that you have packaged up
>> rxcini as a loader.do it makes it super convenient to use the
>> bootstrapper to directly run rxcini in one shot. Same for REX#. Thanks
>> much for that.
>>
>> You can get that same convenience from Windows with a combination of
>> tsend.ps1 and laddie. Basically:
>> tsend.ps1 rxcini.DO ;laddiealpha.exe laddie-options-I-don't-remember
>> all one commandline.
>>
>> github.com/bkw777/tsend.ps1
>>
>> For Robert, I would make sure you're following the points about clearing
>> ram before trying to run cpmupd, and definitely use tpdd to copy cpmupd
>> to the machine in case you're not.
>>
>> I think you'll have to list out all the actual steps you're performing
>> when you say doesn't work because "it works for me". But it doesn't
>> always work the first time just from memory.
>>
>> The directions are somehow confusing to read and get the bullet points
>> that matter. Even though I've done it several times and have tried to
>> write down my own more direct version, I still end up having to pull up
>> the bitchin100 pages and refer to some points after it doesn't work the
>> first time just from memory. Usually I forget one of the two times you
>> should issue a clear statement.
>>
>> > This is because the files are binary files with a .BK extension.
>> > Also, make sure you load and run CPMUPD.CO  after
>> you
>> > power off, power on.  This is to ensure you are in the default RAM
>> config.
>>
>> There you go, exactly the kind of step I skip or forget the importance of.
>>
>> But when I go back to the wiki page and don't skip anything, it always
>> works.
>>
>> --
>> bkw
>>
>>

Re: [M100] is the m100 a trs-80? In walks like a, not is categorized as a

[Brian White]

I think I've seen BASIC 80 before but couldn't say where so it might be
imagination. But the main system rom on the 8201 or 8300 or both does say
N82 on it. I think the manuals say it too.

bkw

On Thu, Oct 6, 2022, 10:12 AM B 9  wrote:

> It is definitely an "Operating System", not just "BASIC".
>
>- It hides device drivers behind nice interfaces. For example, just by
>changing the filename prefix one can save a file to a RAM disk filesystem,
>the serial port, a cassette tape, or even the printer.
>- As a file grows in the RAM disk,  behind the scenes, the system is
>constantly moving other files around in memory to make room.
>- Memory is dynamically partitioned so that the RAM disk coexists with
>the RAM used as working memory by programs.
>- And of course it has all the nice utilities like the point-and-click
>file browser, serial terminal, and an editor which isn't half bad even by
>today's standards.
>
> I've been wondering what this Model T / Kyotronic / NEC operating system
> was called. I saw somebody referring to it as "BASIC-85", but I'm pretty
> sure that's wrong. Recently, Bill Gates' Model 100 was auctioned
> 
> and the details referred to the firmware system he and Jey Suzuki wrote as 
> *"Microsoft’s
> N82 BASIC 80 programming software"*. That's a term I've never heard
> before. Has anyone else?
>
> —b9
>
> On Thu, Sep 29, 2022 at 5:04 PM Brian K. White 
> wrote:
>
>> On 9/29/22 17:52, Tommy Phillips wrote:
>> > A BASIC operating environment doesn't really meet the definition of
>> > "operating system".
>>
>> It is literally, the operating system of that device. There is no
>> particular set of features that defines "operating system". The literal
>> and only definition of operating system is the system that operates the
>> device.
>>
>>
>> > But maybe I am being too pedantic. It wouldn't be the first time.
>> >
>> > On 9/29/2022 2:29 PM, Peter Vollan wrote:
>> >> Huh? The Model 100 says "Copyr. 1983 Microsoft" when you go into
>> >> basic. It is common knowledge that Bill wrote the OS himself.
>> >>
>> >> On Thu, 29 Sept 2022 at 09:08, Tommy Phillips
>> >>  wrote:
>> >>
>> >> ... and if I recall correctly, the Model 16 ran Xenix, thus being
>> >> the only TRS-80 to run an O/S from Microsoft.
>> >>
>> >> This, of course, was years before Linux.
>> >>
>> >>
>> >> On 9/29/2022 9:04 AM, Chris Trainor wrote:
>> >>>
>> >>> But still mostly a brand… the basis for the 80 was the Z80 in
>> >>> their early stuff, but like the Model 16 had a 68k in it. 
>> >>> Plus even tho the II had a Z80 like the I, III & IV, I thought
>> >>> operationally it was substantially different and none of the
>> >>> I/III/IV stuff would work on it? (never used one, remember my
>> >>> grandfather having one at work, but that’s it) .Plus the 2 &
>> >>> 12 were very similar, but the 16, meant to be an ‘upgrade’ from
>> >>> the 12 was way different (being 68k based like Apple/Amiga
>> >>> products, but not as ‘hip’ as those  )
>> >>>
>> >>> --Chris
>> >>>
>> >>> *From:* M100 
>> >>>  *On Behalf Of *Justin
>> >>> Poirier
>> >>> *Sent:* Thursday, September 29, 2022 8:04 AM
>> >>> *To:* m100@lists.bitchin100.com
>> >>> *Subject:* Re: [M100] is the m100 a trs-80? In walks like a, not
>> >>> is categorized as a
>> >>>
>> >>> TRS-80 starts for "Tandy Radio Shack" and "Z80 microprocessor."
>> >>> The M100/T102/T200 have an Intel 80C51 microcontroller, not a
>> >>> Zilog Z80, like the Model I, II, III, IV had, and even worse the
>> >>> TRS-80 Color Computers have a Motorola 6809, so even in
>> >>> themselves, they were not consistent in sticking to their own
>> brand.
>> >>>
>> >>> --Justin
>> >>>
>> >>> On Wed, 2022-09-28 at 17:09 -0400, chri...@macross.com wrote:
>> >>>
>> >>> TRS80 is a brand.  There are substantial differences between
>> >>> the different models for the most part.  Especially ones like
>> >>> the Model II.  The 1, 3 and 4 had some limited compatibility
>> >>> but stuff written for one wouldn't necessarily work in the
>> >>> other.  (Except that in theory you could boot a 4 into 3 mode
>> >>> to run 3 apps, but that wasn't really 'compatible' ).   So
>> >>> the 100 and 102 (where brand changed to Tandy) are like the
>> >>> rest and different :).
>> >>>
>> >>> Oh and don't forget the whole color computer series was
>> >>> vastly different from the gray box models :)
>> >>>
>> >>> --Chris
>> >>>
>> >>>
>>  
>> >>>
>> >>> *From:* M100  on behalf of
>> >>> Will Senn 
>> >>> *Sent:* Wednesday, 

Re: [M100] transferring files both directions

[Brian White]

I've documented some all-in-one correctly wired serial cables, and what
makes them special, to go from a pc to a 100 here:
http://tandy.wiki/Model_T_Serial_Cable

And the most convenient way to move files is with a tpdd emulator, or at
least a bootstrapper. It's not convenient that you have to install a tpdd
client, but it addresses a couple major points:

1 There is no binary-safe way to transfer data in the stock rom except
cassette tape. You need some other added software to do it. You could
install an xmodem app but tpdd is more convenient and the smallest tpdd
client is smaller.

2 Even for plain text data, nothing in the stock rom really does this in a
way that cleanly begins and ends a file. You just manually start capturing
in telcom or in basic, and then stop capturing, and it's up to you to
ensure there is not a single byte of extra junk before or after the actual
file contents.

tpdd is a file transfer protocol and handles binary or text data equally,
and the file is always a clean verbatim copy like you expect from any other
file transfer method. It also checksums each 128-byte packet during the
transfer which again a plain text telcom transfer does not do. (TPDD is a
disk peripheral that connects by serial, which we now just emulate on the
server side and use the existing disk operating software on the client side)

So all in all, it's invaluable to install a tpdd client and run a tpdd
server on your pc.

There is another process for doing a one-time transfer which is usually
used to bootstrap installing a tpdd client, since a tpdd client app is
itself a binary program that needs to be transferred somehow, before you
have it installed to do exactly that job...

Bootstrapping just simplifies the serial port stuff as much as possible so
there is less room for the user to get some detail wrong, and relies on the
binary payload being packaged up into a loader, which is a BASIC program
that contains a text encoded version of the binary as a big data payload
and a small program that knows how to create the binary from the data.

Bootstrapping is most commonly used to install a tpdd client but it's
generically useful to transfer and run (or just transfer and save) any
BASIC program, because the sending side is very simple and the receiving
side doesn't require anything extra not part of the system rom on the 100.
IE you can do it even right after a hard reset that wipes everything.

And for ultimate quality of life, just get a REX#. It allows to have the
best tpdd client in rom where it survives resets, does not consume precious
ram, and doesn't even consume the single option rom slot, becuase REX# is
an on-board option rom library not just one rom. So you can have all the
option roms.

Now to define all those terms...

For tpdd servers, there are several, but the two you are interested in are
LaddieAlpha and dlplus, as they are both current and usable on mac.
http://tandy.wiki/TPDD_server


For tpdd clients, there are several, but the 2 most interesting are TS-DOS
and TEENY. TS-DOS is most full featured and user friendly, but it also
consumes a lot of ram if you need to use the ram version. TEENY is teeny,
but also the very definition of the absolute minimum necessary
functionality.
http://tandy.wiki/TPDD_client 

For bootstrapping from mac, dlplus includes a bootstrap function and also
comes bundled with all the tpdd client loaders. There is also a bootstrap
function in pdd.sh which is a tpdd client bash script, but on mac it needs
a newer bash from macports or homebrew etc. Or, the function is simple so
it could be extracted out to a simple standalone script and be compatible
with the stock osx bash.

Everything I said that works from mac also works from linux and even
freebsd.

Links to everything I mentioned are on those two pages above, and REX# is
http://bitchin100.com/wiki/index.php?title=REXsharp
-- 
bkw

On Mon, Sep 26, 2022 at 8:24 PM Will Senn  wrote:

> So, I've read up and looked around for this and haven't found quite the
> answer I was looking for, so I'm asking here (don't worry, I'm not gonna
> eternally spam y'all, but I've got these initial questions...).
>
> I've got a Mac Pro (big honking Mac machine from 2010 with 6, 3 ghz intel
> xeon processors, and a boatload of ram along with a 30 inch display)
> running Monterey (latest -1). I'm entirely comfortable with the Unix that
> lies underneath and have several FreeBSD and Linux boxes around the house.
>
> I'm using Minicom to talk with my PAL-1 (a KIM-1 clone), my Raspberry Pi,
> and my beaglebone black. So, I'm reasonable comfortable, but by no means
> expert, on talking to devices over serial.
>
> I believe that I ought to be able to hook up a Male DB-25 to the M100,
> connect that to a null modem cable  and that to a DB-9 to USB adapter that
> is attached to my Mac Pro's usb port and fire up Minicom to send and
> receive ascii files to and from the M100... but, 

Re: [M100] Questions about tokenizing BASIC in UNIX

[Brian White]

I don't believe this is enough to ensure clean data. I must have a dozen
real ftdi adapters from different manufacturers and I keep having to
increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and
PDDuino as I discover new basic programs to feed in.

Some programs will ingest fine at 5ms/byte, some will fail on some
particular part of one line, always the same spot, unless the sleep is
increased to 6ms.

Then I discover some other code that fails at 6 but succeeds at 7.

Some of the problem code I just found in the M100SIG, some were new things
like the REX setup utils, some I created the new problem by refactoring
existing tpdd client loaders to make them smaller. This made them
apparently more difficult to ingest, but they are still legal correct
BASIC, so any procedure needs to be able to handle the worst case or else
it's no good.

For an example, one of the loaders I re-worked, used to work fine before,
and then the reworked version would always be missing a : in the middle of
one long line of code. Always the same byte missing. And it didn't cause
the transfer to fail immediately, it tokenized on the fly without apparent
error. But the program was broken and didn't work when you try to run it.

This is all with real ftdi adapters and with xon/off enabled on both ends.

It may work at 1200 or something where the low baud rate does the same job
as a sleep between bytes, but no way at 19200.

I will put together a few test cases that expose the problem. And if this
method does somehow work then that would indeed be pretty interesting and
good to know.

I believe all the right chip does is help, and make more code more likely
to make it through, but not actually guarantee it. It probably does make a
large improvement, and you can probably show numerous examples of data that
fails on one adapter and succeeds on an ftdi chip.

-- 
bkw

On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis  wrote:

>
>
> On Thu, Sep 22, 2022 at 5:32 PM B 9  wrote:
>
>>
>> Of particular note for troubleshooting is that, if some of the data gets
>> transferred, but it is garbled or you get a ?DS ERROR, then the problem
>> is that your PC's serial port does not support "ON CHIP SOFTWARE FLOW
>> CONTROL".  One solution is to buy a serial card or USB cable with an FTDI
>> chip in it. (Other companies make ICs that support on chip software flow
>> control, I even have a cheap Prolific 2303 device that does, but FTDI is
>> the only company I know of whose chips are supposed to always work. )
>>
>>
> I've never heard of this on-chip software flow control.All I knew was that
> software flow does not work under Linux. My experience is software flow
> control with a Model T *does* work on Windows.
>
> Is that something you have to enable? Seems awfully strange to have the
> chip interceding in-band. Automatic hardware flow control I have heard of.
>
> This failure on Linux is why I made HTERM to use hardware flow control
>
> If there's a consistent way to make it work on Linux, it would be good to
> know. Even just with FTDI chipset. Windows prolific drivers are trash. I
> don't know about Prolific on Linux.
>
> Is the stty command you put supposed to enable on-chip software flow
> control? Which part?
>
> *s**tty -F /dev/ttyUSB0 ixon ixoff  stop ^S start ^Q  -onlcr -icrnl  eof
> ^Z  19200*
>
> -- John.
>
>>

Re: [M100] T200 and the Year

[Brian White]

omg

bkw

On Sat, Aug 20, 2022, 6:57 PM Stephen Adolph  wrote:

> It is a timer interrupt hack to check/ redraw the date 250 times a
> second!  Which works fine.
>
>
> On Saturday, August 20, 2022, Brian White  wrote:
>
>> There is a pure ram way to do it.
>>
>> I don't have a link handy but I remember the way it was described it
>> poked a little routine into ram that ends up getting called every time some
>> rom routine gets called, it detours through this added routine along the
>> way to modify the result.
>>
>> It sounded terrible except for the fact that there is no better way
>> without editing the rom.
>>
>> I think what I saw was made for 100 or NEC, but I would be surprised if
>> the same thing wasn't possible on 200.
>>
>> --
>> bkw
>>
>> On Sat, Aug 20, 2022, 10:48 AM Greg Swallow  wrote:
>>
>>> How Do,
>>>
>>> The 19, of 19xx, is in ROM. ROM images are available that have the 19
>>> patched to 20. This makes the MT good through 2099. The date routines in
>>> the MT only use the trailing two digits. Burning a single ROM can be a bit
>>> much if you do not already have the tools. Easiest way would be, check me
>>> on this Steve, a REX#. The REX has the Y2K patch built in. Greg (Arcade
>>> Shopper) should have some. If you'd like just a ROM, there's probably some
>>> here that could do it for you. I have some 27c256 blanks, but my burner is
>>> blown.
>>>
>>> Anyone?
>>>
>>> GregS <><
>>>
>>> Aug 19, 2022 7:05:53 AM Spencer :
>>>
>>> Hello!
>>>
>>> Can anyone tell me if it's possible to update an issue with the T200
>>> year not being able to be set beyond 1999?  I've searched but nothing so
>>> far.
>>>
>>> Thanks
>>>
>>>

Re: [M100] T200 and the Year

[Brian White]

There is a pure ram way to do it.

I don't have a link handy but I remember the way it was described it poked
a little routine into ram that ends up getting called every time some rom
routine gets called, it detours through this added routine along the way to
modify the result.

It sounded terrible except for the fact that there is no better way without
editing the rom.

I think what I saw was made for 100 or NEC, but I would be surprised if the
same thing wasn't possible on 200.

-- 
bkw

On Sat, Aug 20, 2022, 10:48 AM Greg Swallow  wrote:

> How Do,
>
> The 19, of 19xx, is in ROM. ROM images are available that have the 19
> patched to 20. This makes the MT good through 2099. The date routines in
> the MT only use the trailing two digits. Burning a single ROM can be a bit
> much if you do not already have the tools. Easiest way would be, check me
> on this Steve, a REX#. The REX has the Y2K patch built in. Greg (Arcade
> Shopper) should have some. If you'd like just a ROM, there's probably some
> here that could do it for you. I have some 27c256 blanks, but my burner is
> blown.
>
> Anyone?
>
> GregS <><
>
> Aug 19, 2022 7:05:53 AM Spencer :
>
> Hello!
>
> Can anyone tell me if it's possible to update an issue with the T200 year
> not being able to be set beyond 1999?  I've searched but nothing so far.
>
> Thanks
>
>

Re: [M100] Writing binary files from BASIC

[Brian White]

There must be a reason every single do2co/loader/hexfer util does this by
poking into memory.  They determine or are hardcoded with a starting
address, poke the bytes, and then savem the start & length. You probably
just found that reason.

On Mon, Aug 15, 2022, 4:49 AM B 9  wrote:

> I was attempting to write a binary data file using BASIC's OPEN and PRINT
> # commands and found that there are three bytes that are not allowed: 0,
> 26, and 127. I had expected CHR$(26) might be a problem as that is the
> End Of File character, but the other two were a surprise. Is this
> limitation documented somewhere? It's not in the BASIC manual from Radio
> Shack.
>
> Here's an example of what doesn't work:
>
>  10 open "foo.do" for output as #1
>  20 for t=0 to 255
>  30 print #1, chr$(t);
>  40 next t
>  50 close #1
>  80 open "foo.do" for input as #1
>  90 x=0
> 100 if eof(1) then 200
> 110 c = asc(input$(1,1))
> 120 if c<>x then print x
> 130 x=c+1
> 140 goto 100 h
> 200 close #1
> 210 end
>
> I can think of various workarounds, but they are ugly. What is the best
> way to write binary files with arbitrary data from BASIC on a Model T?
>
> Thanks for any guidance.
>
> —b9
>

Re: [M100] TRS-80 Model 100 schematic transcribed to KiCAD

[Brian White]

This is wonderful, thank you!

bkw

On Fri, Jul 29, 2022, 10:12 PM Henner Zeller  wrote:

> Hi,
>
> I recently got a TRS-80 Model 100 and for fixing the the main-board I
> poured over various scans of the original schematic found on
> archive.org; and while it is great that these exist, the original
> schematic is still somewhat hard to read, so I decided to transcribe
> them to a modern schematic format - KiCAD
>
> I put the schema and symbols file as well as a generated PDF on github
> https://github.com/hzeller/trs80-100-schematic
>
> Status: Transcribed the full main-board (not the LCD board). All BOM
> entries (number+value) match with the list found in the documentation,
> all pin-assignments are accurate. Even deduced some values that are
> missing in the schematic (R162, 100Ohm discharging C78 in the reset
> circuit, as well as the designator for the 10n capacitor near the
> primary in the power supply .. C62). Schematic passes electrical rule
> check, so at least there are no obvious mistakes in there.
>
> I tried to keep the original layout as much as possible for easy
> recognition, but did slight changes to improve readability.
> For instance, I added a gap between the 'analog' and 'digital' part so
> that it is possible to print out on two sheets and glue together
> without losing content (or simply folding a large print-out without
> damaging important stuff). Also using IEC resistor symbols for
> readability and changed capacitor units where nanofarad is better
> (3300pF -> 3.3nF; 0.047μF -> 47nF); they didn't seem to use 'Nano'
> back in the day. Renamed some signals to be more useful, so `Ⓐ*` is
> now `RDRW*`. Used color encoding for the different buses on the system
> to easier see what is going on at a glance.
>
> If you find any mistakes (I am sure I missed something), please file
> an issue in the github's issue tracker.
>
> Cheers,
>   Henner.
>

Re: [M100] mcomm android issue

[Brian White]

In the case of Windows, I made a powershell script for windows if you want
to try that.

github.com/bkw777/tsend

get TS-DOS.100 from github.com/bkw777/dlplus/tree/master/clients/ts-dos

, and then use laddiealpha for the tpdd server.
http://bitchin100.com/wiki/index.php?title=LaddieCon#LaddieAlpha

-- 
bkw

On Sun, Jul 17, 2022, 2:36 PM Gregory McGill 
wrote:

> Kurt,
>
> any updates for 10?  I am trying to get a current box working
>
> Greg
>
> On Tue, Mar 2, 2021 at 7:30 PM Kurt McCullum  wrote:
>
>> Greg,
>>
>> I was able to do some testing with and Android 9 phone. Bad News, it
>> doesn't work on Android 9. I'm not certain as to why but the first giveaway
>> was when I installed it and I got a message that said it was designed for
>> an older version of Android and may not work under 9. I'll have to see what
>> can be done. It may be a matter of upgrading all my code, or just a
>> re-compile with a new target OS. Either way I have some work to do.
>>
>> Just wanted you to know.
>>
>> Kurt
>>
>> On Tue, Mar 2, 2021, at 10:29 AM, Kurt McCullum wrote:
>>
>> Alright. Should be an easy test now that I have all the equipment. The
>> only difference will be I am using a phone rather than a tv box but the OS
>> version will be the same. I'll let you know what I find.
>>
>> Kurt
>>
>> On Tue, Mar 2, 2021, at 10:05 AM, Gregory McGill wrote:
>>
>> correct, push ts-dos from mcomm android 181 on a android 9 tv box i just
>> got. whenever i hit ok to send the file it just seems to crash mcomm and
>> jumps out of it..
>>
>> On Tue, Mar 2, 2021 at 9:32 AM Kurt McCullum  wrote:
>>
>>
>> Not yet Greg, but I did get the cables needed at I have access to an
>> android 9 phone. I'll do my best to wrestle it out of my wife's hands
>> tonight and test it (Not always easy to do). As I recall it was the TS-DOS
>> injection you were having issues with.
>>
>> Kurt
>>
>>
>> On Tue, Mar 2, 2021, at 9:28 AM, Gregory McGill wrote:
>>
>> Glad to hear it! I grew up in 1000 oaks, my mom's still in Camarillo at
>> the village
>>
>> lmk if you get a chance to test that newer android issue
>>
>> On Sun, Feb 28, 2021 at 8:51 PM Kurt McCullum  wrote:
>>
>>
>> Yes, I am finally settled in my new place in Camarillo. Still unpacking
>> but life is back to normal.
>>
>> Kurt
>>
>> On Fri, Feb 26, 2021, at 3:09 PM, Gregory McGill wrote:
>>
>> Is it winter yet? :)did you ever escape?
>>
>> Greg
>>
>> On Fri, Jul 31, 2020 at 12:30 PM Kurt McCullum 
>> wrote:
>>
>>
>> :) thanks. A lot more body surfing going on rather than web surfing. It
>> will definitely be a summer to remember.
>>
>> On Fri, Jul 31, 2020, at 12:27 PM, John R. Hogerhuis wrote:
>>
>> Congratulations to Kurt McCullum on the list Quote of the Month
>>
>> "*I'm still stuck in a beach house with only one model-t*"
>>
>> :-)
>>
>> -- John.
>>
>>
>>
>>
>>
>>

Re: [M100] A MicroDrive

[Brian White]

Oh and apparently the tape is narrower than cassette, so there will be no
cobbling up any kind of home made cart using tape from a regular cassette.

-- 
bkw

On Fri, Jul 15, 2022, 8:10 PM Brian White  wrote:

> There are some exatron tapes on ebay right now but those are only the same
> in essence, not actually the same.
>
> That video showing the Rotronics drive also shows a drive for Commodore
> that is a similar overall configuration like mine, just the case looks like
> abs while the a is extruded aluminum. And other videos that show the
> insides remove all doubt. This drive mechanism is the same as the Rotronics
> and at least a couple others, but not the Sinclare microdrive or the
> Exatron stringy floppy.
>
> --
> bkw
>
> On Fri, Jul 15, 2022, 5:49 PM David Anderson  wrote:
>
>> The A Microdrive was made by a company spun off from Exatron, who made
>> the “stringy floppy” cassettes. The Wafadrive is the same mechanism, but
>> made by BSR, who had a stake in Exatron, I think. It’s been a while.
>>
>> Anyway, the drives and cassettes are kind of hard to come by. They show
>> up on the bay once in a while.
>>
>> David
>>
>

Re: [M100] A MicroDrive

[Brian White]

There are some exatron tapes on ebay right now but those are only the same
in essence, not actually the same.

That video showing the Rotronics drive also shows a drive for Commodore
that is a similar overall configuration like mine, just the case looks like
abs while the a is extruded aluminum. And other videos that show the
insides remove all doubt. This drive mechanism is the same as the Rotronics
and at least a couple others, but not the Sinclare microdrive or the
Exatron stringy floppy.

-- 
bkw

On Fri, Jul 15, 2022, 5:49 PM David Anderson  wrote:

> The A Microdrive was made by a company spun off from Exatron, who made
> the “stringy floppy” cassettes. The Wafadrive is the same mechanism, but
> made by BSR, who had a stake in Exatron, I think. It’s been a while.
>
> Anyway, the drives and cassettes are kind of hard to come by. They show up
> on the bay once in a while.
>
> David
>

Re: [M100] Robotics projects with the M100

[Brian White]

There are TWO people with these robots???

Haha that does make the most sense since it fits.

 It's a different situation with the M100 because although there is room
for a normal socket (not zif) with a dip chip in it, the pinout is
non-standard, and there is no room for a socket plus a pinout adaper with
it's own socket. Plus there are old commercial roms and new accessories
like REX that only fit in the original socket with the original pinout that
you want to remain compatible with.

-- 
bkw

On Sun, Jul 3, 2022, 5:45 PM Scott McDonnell 
wrote:

> Yes that was me. I ordered the boards and the 3D printed parts, but I
> ended up just installing a ZIF socket in both of my RB5X robots as that was
> more convenient both for programming the parts and using them. After I had
> disassembled the robot, I realized that the footprint for the custom molex
> socket was compatible with a regular DIP socket and the cutout in the panel
> was big enough for a ZIF socket.
>
> A friend did use your 3D printed DIP adapter without any issue since he
> did not want to modify his robot.
>
>
> Date: Sun, 3 Jul 2022 16:53:09 -0400
> From: Brian White 
> To: m...@bitchin100.com
> Subject: Re: [M100] Robotics projects with the M100
>
> Hello! Was it you that I spoke with a few times about the 28-pin version of
> the Molex carrier and eeprom adapter pcb? How did you ever make out with
> that? Did you try it and did it work? I couldn't actually test it myself so
> I was worried there could be some trivial mistake.
>
> --
> bkw
>

Re: [M100] Robotics projects with the M100

[Brian White]

Hello! Was it you that I spoke with a few times about the 28-pin version of
the Molex carrier and eeprom adapter pcb? How did you ever make out with
that? Did you try it and did it work? I couldn't actually test it myself so
I was worried there could be some trivial mistake.

-- 
bkw

On Sun, Jul 3, 2022, 3:23 PM Scott McDonnell 
wrote:

> I have probably mentioned this before. My main hobby interest is 80s
> robotics.
>
> I am curious if anyone knows of, has references to, etc... any robotics
> projects using the M100.
>
> I originally bought my first M100 to control an RB5X and Heathkit Hero
> robot via the serial port. The plan was to use wireless serial interfaces
> to keep it portable. While I have achieved that (not really difficult or
> challenging), I had wondered why I had not seen an M100 become the brains
> or system controller for a robot before. It seems like it would have been a
> great choice at the time. However, I had completely missed on the entire
> Tandy product line in the 80s and was definitely not plugged in to the
> community and news. I was a Commodore fanboy at the time. So I was never
> aware of any hardware projects people were doing with their laptops.
>
> Have there been any articles and or projects for robotics, industrial
> control, automation, etc... using the M100?
>
>
> Scott
>
>

Re: [M100] the function of A* in M100/T102

[Brian White]

That sure does sound reasonable. I love all the tricks and hacks old
designers used to do like that.

bkw

On Sat, Jun 18, 2022, 9:46 AM Stephen Adolph  wrote:

> I've often wondered about the purpose of the A* signal on the M100.
>
> A* is used to control the internal RAM.  It drives the timing for the RAM
> chip selects.  Also, since the RAM are wired with OE grounded, whenever A*
> is high, the RAM will try to immediately output data, unless the processor
> is writing data to it.
>
> A* is logically the NAND of /WR and /RD.  A* is '1' whenever a read or
> write is happening. So the ram chip selects never get enabled until well
> into the processor cycle, far later than it could be based on IO/M and
> address lines.
> To me this has always been a bit peculiar.  Chip selecting, and the
> function of reading or writing have separate timings and can be done
> separately.
>
> Also, I think A* is used to enable "external RAM" on the M100.  I think
> that is how the PG Designs ram bank products work for example - by
> controlling A*.
>
> So, why did the M100 designers choose to delay the chip select for the RAM?
>
> As I have been playing around with 5MHz hacking on these things I have
> found that, in order to speed up the computer, one has to fiddle with A*.
> Generally, A* has to be enabled EARLIER in the processor cycle in order to
> give the RAM time to respond at the higher speed.
>
> I've noticed that the computer power consumption is quite sensitive to the
> actual timing of A*.  The earlier I enable A*, the higher the current.
>
> Here's some numbers:
> At 2.5 MHz (stock speed) the RAM in my M100 consumes about 2.3 mA out of
> the 50 mA of the machine overall.  This is with a "stock" A* signal.
>
> In the extreme case of setting A* permanently on (hard wired to 5V) , at
> 5MHz the RAM current shoots up to 20mA!  and the M100 is consuming   85 mA.
> (not great right?)
>
> If I do a bit of work, I can generate an A* signal that minimizes RAM
> current to 4.3 mA while operating at 5MHz.  Much better!  this keeps the
> overall M100 power to <70mA @5MHz.
>
> Re-reading various datasheets, and thinking about memory power ... I think
> the M100 hardware designers were using A* to significantly limit the amount
> of time that the RAM chips were enabled.  By doing so, they dramatically
> reduced the overall memory power.  This of course makes sense for a battery
> powered computer.
>
> This was an interesting ah-hah.  In retrospect, it makes perfect sense
> once you realize that "on" time is driven by chip-select and that drives
> power.
>
> And the result of all this twiddling is that my 5MHz hacks are quite a bit
> lower power.
>
> I have some new PCBs on the way.  These boards piggy back on the CPU, and
> provide the faster clock.  Now they also generate a new A* signal for the
> RAM.
>
> In terms of computer power, I expect the following.
> 1) for a FIXED (ie permanent) 5MHz conversion, the increase in current
> should be 18mA
> 2) for a SWITCHABLE conversion, the increase in current should be 3mA in
> 2.5M mode and 21 mA in 5M mode.
>
> Standard system RAM is usable in both T102 and M100.
> The only memory part that needs to be changed is the M100 ROM, which is
> very very slow.  So 5MHz must have an EPROM conversion or similar.
>
>
>
>
>
>
>
>

Re: [M100] is the list actually working?

[Brian White]

I didn't see either one.

I can only say I have only tried to use mcomm for windows to test it's
bootstrapper to document how to use it and to verify what it can or can't
do (like can you supply an arbitrary payload, and if not what exactly is
built in) and I couldn't get it to work. It runs, but doesn't work.

I assume it probably used to work under earlier versions of Windows but I
couldn't get it to work by using compatibility modes or
run-as-administrator either. I didn't try actually digging out a Win7
machine because what's the point even if that does work, other than just to
document the fact? No source so I stopped worrying about it. On Windows I
use Laddie for tpdd and wrote tsend.ps1 for bootstrap.

If you mean mcomm for python, it required a little manual fixing but only a
bit. It has no bootstrapper, but otherwise worked fine, and it would be
simple to add a bootstrapper. I don't remember the details but it was
simple and I bet this wasn't what you meant anyway because I think you
would have had no problem either.

-- 
bkw

On Tue, May 3, 2022, 8:53 PM Peter Vollan  wrote:

> I'd appreciate if someone could respond to my messages just so I know they
> got through. I have posted about the weird error I am getting with Kurt
> McCullum's Mcomm twice without a peep, and I don't want to bore people to
> death if they have already seen it.
>
> On Tue, 3 May 2022 at 11:03, Gregory McGill 
> wrote:
>
>> A good way to tell is the discord email list channel, it has 99% of the
>> messages except the ones that exceed 2000 characters.. those are skipped
>> due to limitations on the importer
>> Greg
>>
>

Re: [M100] is it just me , or..

[Brian White]

The original that Josh is replying to here , just like Steve's original
earlier, is not even in my spam folder. Filtering or diverting or holding
is happening in places we have no control over.

-- 
bkw

On Tue, Apr 26, 2022, 11:11 AM Joshua O'Keefe 
wrote:

> On Apr 26, 2022, at 7:50 AM, Chris Trainor  wrote:
> > it's super important you flag it as not spam to train Google that it's
> not junk.
>
> My personal experience over the past 18 years of using Google mail systems
> is that it's completely untrainable and learns absolutely nothing from end
> user flagging.  Whatever signals it's mis-training on are massively
> outweighing end user input.

Re: [M100] is it just me , or..

[Brian White]

This very message is like that for me.
I just got Josh's reply but still have not seen Steve's original, and it's
not in the spam folder either.

-- 
bkw

On Tue, Apr 26, 2022, 10:08 AM Joshua O'Keefe 
wrote:

> On Apr 26, 2022, at 4:39 AM, Stephen Adolph  wrote:
> > Mail from the mailing list really seems to be out of sync these days.
> > I'm seeing replies to emails that I have never seen the original post
> for.
>
> This has been a sporadic issue for me that seems to be getting worse.
> Previously the missing messages were primarily from Yahoo addresses and
> getting incorrectly marked as spam for what appeared to be SPF reasons.
> This is a Google header parsing/spam routing bug (even if you have rules to
> deliver these messages anyway!) and I still have to go retrieve those
> periodically although less often lately.
>
> Currently some replies are being delivered hours or days before the
> originating message.  Sometimes the originating message is not delivered at
> all.  I'd have to see John's MTA logs to know why but as someone whose
> professional responsibilities include deliverability of messages with
> rewritten headers I've seen comparable problems when the receiving MTA is
> greylisting delivery attempts due to bad heuristics.
>
> Both you and I are using Google mail infrastructure so that might be the
> commonality to start pointing fingers.
>
>
>

Re: [M100] 27C256 pin 1 VPP - can it float?

[Brian White]

I always tie it to vcc, with a pullup so that a programmer can still
override it.

As you saw yourself, every datasheet always says to pin to vcc or lower,
usually preferring vcc.

I think the harm is just the risk of reaching vpp randomly if left
flapping, so you might corrupt the data. Probably *almost* never happens,
but  the datasheet directions implies that there is no equivalent of a
built-in pullup, which means the pin is free to spike even from say, static.

Seperately, I would always nail down *any* input just on principle, and
especially any control input.

-- 
bkw

On Thu, Mar 10, 2022, 3:32 PM Mike Stein  wrote:

> Don't know about the 27C256 but experience with 2732s was that with some
> manufacturers you could get away with leaving it to float whereas on others
> you had to explicitly pull it high (which would be my recommendation).
>
> m
>
> On Thu, Mar 10, 2022 at 2:20 PM Stephen Adolph 
> wrote:
>
>> Quick one for the crowd.
>> On a 27C256, I have always thought you could ignore Vpp for normal use,
>> and only use it for programming.
>>
>> So, you could plug a 27C256 where the main rom lives in a T102 or T200,
>> or UK M100, or KC-85, or M10. whew.
>>
>> However, when I look at datasheets for 27C256, they all say normal
>> condition on pin 1 is VCC!!!
>>
>> What gives?
>> Is it ok to float pin 1, or really should we be connecting pin 1 to plus
>> 5V?
>>
>> thanks
>> Steve
>>
>

Re: [M100] Chipmunk Drive Utility Disk (img)

[Brian White]

When you say cdos rom, do you mean that you have an option rom that has
cdos on it? Or do you mean a rom in the drive?

If you have an option rom, then it will almost certainly be installed the
same way as any other option rom. CALL 63012  (or 63012,1 or 63013 or
63013,1).

The reset or CALL0 directions are for triggering the drive to install cdos
in ram from a disk via the bus connection like the Disk/Video Interface
does. call0 is supposed to be more bulletproof because reset doesn't
necessarily install, it just checks a flag in ram to see if it needs to
install, and that could be wrong if memory or an installed cdos got
corrupted.

But if you have a rom, then you have a rom. That will take the place of the
normal way. It probably does still install ram components, because I
believe cdos modifies BASIC and TELCOM etc, but that doesn't change how any
option rom is activated. The initial kick off will be by activating that
rom, which will be the same as any other.

The only difference will be that you also have a rom expander in the mix.
So first you will have to know how to operate the expander to select
different roms and activate them and switch between them, THEN do that to
select the cdos rom.

Myself, since I have all the stuff and it would be convenient, I would
start by removing variables by starting without the rom expander and moving
the cdos rom from the expander to the m100 directly. Temporarily just to
remove variables and figure out one thing at a time.

Those expanders usually have some rom sockets that are like the m100 and
some that are standard.

If the cdos rom happens to be fitted with a pinout adapter and installed in
a molex socket like what the m100 has, then it's easy, just remove the
expander and pop the cdos rom directly in the m100 and CALL 63012.

If the cdos rom is a standard eprom without a pinout adapter and installed
in a standard dip-28 socket, Then you'd need an eprom programner and a rex
or teeprom to try to use the rom by itself without the expandet. So in that
case just make sure you've mastered the expander first by loading and
switching between other roms before trying the same with cdos.

And just bear in mind the possibility that the cdos manual may be slightly
wrong in your case, since it may only describe the normal disk-based
install method and your rom may be taking the place of part of that. You
probably don't need any reset or CALL0.

I have a Sardine rom in a PG Designs / Tavelling Software expander that's
like that. The manual only describes the normal disk install method. The
expander has it's own special directions for installing that version of
Sardine. In that case those directions were essentially to select rom slot
#5 in the expander and launch that rom the same as any other rom. 'select
#5' in that case meant to execute a BASIC instruction or two which affects
the expander. I think the pcsg expander has a thumb wheel?

-- 
bkw

On Mon, Feb 28, 2022, 8:18 PM Greg Swallow  wrote:

> I have a PDF of the manual and as best I can figure the included Chipmunk
> power supply is around the same current as the M100 PS as the M100 PS will
> power the drive, but it will not properly charge the Chipmunk battery. The
> manual even notes the Chipmunk PS should not be used to power the M100 as
> the Chipmunk PS is 1.5 volts greater (7.5VDC) than the M100 PS (6VDC) and
> the Chipmunk PS would certainly damage the M100. Some pictures show a
> Chipmunk with a 7.5VDC 400ma PS. The Chipmunk takes a 5.5mm OD x 2.1mm ID
> plug with a Negative (-) center. The PS I have (DMD-8201500) is adjustable
> up to 24VDC with a max of 1.5A. It does not have a breakdown of amps vs VDC
> or anything about watts/power. So I am unsure if current at 7.5VDC is the
> same/less than at 24VDC.
>
> When I turn everything on and RESET (hard/soft) the M100 the Chipmunk
> lights up as if a boot process is attempting to find something. The CDOS
> Menu does not appear and the M100 goes on unaware of the process. I thought
> I read somewhere that the CDOS ROM can be run with a CALL 0 from BASIC, but
> this has done nothing that I can note. There is evidently a RAM portion of
> CDOS and I am hoping this is what the Chipmunk is trying to find on the
> drive. Possibly the CDOS ROM is like a BIOS and needs something from the
> CDOS Utility disk to complete the process of loading CDOS Menu to RAM. Once
> loaded, the CDOS Menu, can be turned On/Off in a similar fashion as TS-DOS.
>
> Thanks for the help y’all. I will check out the M100SIG files and see if I
> can find more clues.
>
>
> God Bless,
>
> GregS <><
>
>
> > On Feb 28, 2022, at 4:11 PM, Brian K. White 
> wrote:
> >
> > On 2/28/22 17:51, Brian K. White wrote:
> >> I have a manual for the chipmunk drive I can scan.
> >
> > Also there's a bunch of info in the M100SIG
> >
> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/CHIPMK.CAT
> > No disk image though.
> >
> > --
> > bkw
> >
>
>

Re: [M100] hardware scrolling patch

[Brian White]

incredible!

bkw

On Thu, Feb 24, 2022, 12:52 AM Stephen Adolph  wrote:

> ...and found some more savings.  *now down to 85 bytes*!  Leaving 65
> bytes for more patch fun.
>
>
> On Wed, Feb 23, 2022 at 1:24 PM Stephen Adolph 
> wrote:
>
>> In T200, the video subsystem was really reworked to take advantage of
>> hardware scrolling.
>> From a quick scan, it seems like the basic operation is the same for M100
>> and T200 (upper and lower portions of the LCD), so the same "organization"
>> should be applicable to the M100.
>>
>> Could T200 video subsystem be back ported to M100?  Perhaps a much deeper
>> dive into the code could make the M100 truly work as well as the T200 from
>> this perspective, but I would worry that the end result would be so
>> substantially different that software compatibility may become an issue.
>>
>> I guess they got away with software scroll on M100, but T200 would have
>> been completely unacceptable with such a slow scroll across 16 lines rather
>> than 8.
>>
>> Anyhow, I have streamlined the patch now to only 95 bytes, leaving 55
>> bytes for more stuff.  I may try to augment what is there with coverage for
>> some of the additional scroll corner cases.
>>
>> Steve
>>
>> On Wed, Feb 23, 2022 at 10:48 AM Joshua O'Keefe 
>> wrote:
>>
>>> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
>>> wrote:
>>> > I did a write up on the two patches that are needed.
>>>
>>> Steve, I remember seeing you mention this a while back and I'm glad you
>>> were able to get back to it.  Your write-up was clear, informative and
>>> interesting.  Thanks for sharing it.
>>>
>>> I wonder why this controller feature was never exploited.  Was there
>>> perhaps a similar, earlier part lacking the feature that was swapped out
>>> late in the design cycle?  Simple time constraints like every engineer in
>>> history has faced?  I can imagine all kinds of scenarios and it's a shame
>>> we'll never know the real story of why the ROM is the way it is.
>>
>>

Re: [M100] Model 200 with LCD all black from power on

[Brian White]

There is also the beep test, which tells you if the machine is running and
the problem is only the lcd, or if the machine is not running, which means
the lcd is probably fine.

Cold reset, then press enter, then type "beep" (without quotes), and press
enter.

If the cpu is running and the rom loaded and ram is working, then it will
beep. If you don't get a beep, then the cpu is probably not running.

bkw

On Thu, Feb 17, 2022, 3:47 PM Gsvacances Free  wrote:

> Hi Brian !
>
> Thanks for your reply.
>
> I tried CTRL + BREAK (PAUSE) + RESET or POWER but although I hear clicks
> in the speaker nothing else occurs and no change on the LCD (= still black).
>
> I’ll check the reset line in various places and bus activity on the memory
> PCB tomorrow.
>
>
>
> Gilles
>
>
> *From:* Brian White
> *Sent:* Thursday, February 17, 2022 7:02 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Model 200 with LCD all black from power on
>
> Did you ever actually do the cold reset 3-finger salute? I didn't see you
> say that you did.
> I don't remember what the keys are for 200 but it's in the manual and
> probably on club100 and bitchin100 too.
>
> ctrl + break + reset or something like that.
> Mere power-cycle isn't good enough, you have to do that reset hot-key once
> after any crash or full memory power loss etc. Then after that you can use
> the power button normally.
>
> bkw
>
> On Thu, Feb 17, 2022, 9:35 AM Gsvacances Free  wrote:
>
>> Thank you for your reply Jeff !
>>
>> The reset switch seems to work as I hear a click in the speaker but
>> nothing changes on the LCD.
>> So I’ll check that the reset line is going wherever it needs to.
>>
>> As for bus activity, I only checked at the CPU but not on various RAM and
>> ROM chips.
>> So will do it too and keep you updated !
>>
>>
>> Thanks again for your quick reply !
>>
>>
>>
>> Gilles
>>
>>
>>
>> *From:* bir...@soigeneris.com
>> *Sent:* Thursday, February 17, 2022 2:22 PM
>> *To:* m...@bitchin100.com
>> *Subject:* Re: [M100] Model 200 with LCD all black from power on
>>
>>
>> It sounds like you are on the right track. The first three things I
>> check: PCR - Power, Clock, Reset. It seems you have already checked the
>> first two. If the reset circuit is not working the machine will not start
>> up in a known state and many strange things can happen.
>>
>>
>>
>> The next few checks: BADS - Bus, Address Decoding, chip Selects. You have
>> already checked for bus activity but double check that you are getting all
>> the bus signals to all the main chips. I had a PC-8201 recently where I
>> checked bus activity at the RAM which was fine, but there was a broken
>> trace to the ROM. If I had checked in both places at first it would have
>> saved me much time. If any off the address decoding/chip selects are
>> wrong/missing all manner of strangeness will occur.
>>
>>
>>
>> The black screen at power up is the classic symptom of the computer not
>> booting up. When powered up the LCD drivers will turn on every pixel.
>> During the boot process the computer will reset the LCDE drivers which
>> turns all the pixels off. Being stuck in this not booting state can be
>> anything from bad RAM, ROM, address decoding chips, etc.
>>
>>
>>
>> Jeff Birt
>>
>>
>>
>> *From:* M100  *On Behalf Of *Gsvacances
>> Free
>> *Sent:* Thursday, February 17, 2022 6:31 AM
>> *To:* m...@bitchin100.com
>> *Subject:* [M100] Model 200 with LCD all black from power on
>>
>>
>>
>> Hi everyone,
>>
>>
>>
>> Gilles here (male name in France).
>>
>>
>>
>> I have a model 200 which shows an all black LCD screen.
>>
>>
>>
>> I replaced the battery and fully charged it, no change.
>>
>>
>>
>> I checked the voltage at the battery when the model 200 is unplugged and
>> it’s about 3.4-3.5v.
>>
>>
>>
>> I can hear a click noise in the speaker when I switch the 200 on and also
>> when I press the reset button.
>>
>>
>>
>> But, appart from that, nothing seems to occur.
>>
>>
>>
>> I checked the CPU clock and it is fine.
>>
>>
>>
>> I also checked the buses and nothing seems stuck.
>>
>>
>>
>> Power supply for all the chips seems to be correct.
>>
>>
>>
>> On the LCD connector, I also have some AC voltages of various frequencies.
>>
>>
>>
>> On very rare occ

Re: [M100] Model 200 with LCD all black from power on

[Brian White]

Did you ever actually do the cold reset 3-finger salute? I didn't see you
say that you did.
I don't remember what the keys are for 200 but it's in the manual and
probably on club100 and bitchin100 too.

ctrl + break + reset or something like that.
Mere power-cycle isn't good enough, you have to do that reset hot-key once
after any crash or full memory power loss etc. Then after that you can use
the power button normally.

bkw

On Thu, Feb 17, 2022, 9:35 AM Gsvacances Free  wrote:

> Thank you for your reply Jeff !
>
> The reset switch seems to work as I hear a click in the speaker but
> nothing changes on the LCD.
> So I’ll check that the reset line is going wherever it needs to.
>
> As for bus activity, I only checked at the CPU but not on various RAM and
> ROM chips.
> So will do it too and keep you updated !
>
>
> Thanks again for your quick reply !
>
>
>
> Gilles
>
>
>
> *From:* bir...@soigeneris.com
> *Sent:* Thursday, February 17, 2022 2:22 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Model 200 with LCD all black from power on
>
>
> It sounds like you are on the right track. The first three things I check:
> PCR - Power, Clock, Reset. It seems you have already checked the first two.
> If the reset circuit is not working the machine will not start up in a
> known state and many strange things can happen.
>
>
>
> The next few checks: BADS - Bus, Address Decoding, chip Selects. You have
> already checked for bus activity but double check that you are getting all
> the bus signals to all the main chips. I had a PC-8201 recently where I
> checked bus activity at the RAM which was fine, but there was a broken
> trace to the ROM. If I had checked in both places at first it would have
> saved me much time. If any off the address decoding/chip selects are
> wrong/missing all manner of strangeness will occur.
>
>
>
> The black screen at power up is the classic symptom of the computer not
> booting up. When powered up the LCD drivers will turn on every pixel.
> During the boot process the computer will reset the LCDE drivers which
> turns all the pixels off. Being stuck in this not booting state can be
> anything from bad RAM, ROM, address decoding chips, etc.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Gsvacances
> Free
> *Sent:* Thursday, February 17, 2022 6:31 AM
> *To:* m...@bitchin100.com
> *Subject:* [M100] Model 200 with LCD all black from power on
>
>
>
> Hi everyone,
>
>
>
> Gilles here (male name in France).
>
>
>
> I have a model 200 which shows an all black LCD screen.
>
>
>
> I replaced the battery and fully charged it, no change.
>
>
>
> I checked the voltage at the battery when the model 200 is unplugged and
> it’s about 3.4-3.5v.
>
>
>
> I can hear a click noise in the speaker when I switch the 200 on and also
> when I press the reset button.
>
>
>
> But, appart from that, nothing seems to occur.
>
>
>
> I checked the CPU clock and it is fine.
>
>
>
> I also checked the buses and nothing seems stuck.
>
>
>
> Power supply for all the chips seems to be correct.
>
>
>
> On the LCD connector, I also have some AC voltages of various frequencies.
>
>
>
> On very rare occasions (2-3 times not in a raw), the M200 LCD screen is
> greyish and the contrast pot adjustment seems to work.
>
>
>
> But when the M200 is black from the start, the contrast pot does nothing.
>
>
>
> I disconnected and reconnected both the keyboard and the LCD flex cables
> without any change and the symptoms.
>
>
>
> I don’t see any traces of corrosion nor breakage on the PCBs.
>
>
>
> There is no option ROM inserted in the memory board and if I put the
> switch on the OFF position, the LCD screen does nothing and I also hear no
> click noise in the speaker.
>
> If I switch it ON, the LCD goes black again.
>
>
>
> I’ve read the mails related to the same symptoms and used them to check
> things here and there but, well, no joy !
>
>
>
> I have a multimeter and an oscilloscope but don’t know what else I could
> check.
>
>
>
> Any suggestions ?
>
>
>
> Thanks in advance for your help !
>
>
>
>
>
> Gilles
>

Re: [M100] Model 102 keys

[Brian White]

That isn't as safe as a puller with flat wires that cross the corners and
lifts on 4 points.

2 hooks means 2 points which means it's always at risk of pulling off
center, even sliding all the way to one side and doing exactly the damage
you're trying to avoid.

It's better than prying from the side, and I'm sure you can do it 100 times
with no problem, but keycap pullers are designed the way they are for a
reason.

If you're going make one from a paper clip, there are youtube videos that
show how to make a proper one from paper clips, or you can even use a
binder clip without even having to modify it.

-- 
bkw

On Wed, Feb 16, 2022, 5:55 PM R Oaks  wrote:

> I have a bunch (couple dozen) of original NEC 8201A that I still use.
> I took a sturdy paper clip, straightened it.
> Use plyers to make VERY short 90 degree hook/tab on each end.
> Bend in center with 'hooks' 'facing' each other.
> Slip between the keys and then pull perpendicular to the plane of the
> keyboard.
> This pulls STRAIGHT up instead of 'prying' on the sides
> ...easy and worked for me.
> Regards
> 
>
>
> --
> *From:* M100  on behalf of
> m100-requ...@lists.bitchin100.com 
> *Sent:* Wednesday, February 16, 2022 17:02
> *To:* m100@lists.bitchin100.com 
> *Subject:* M100 Digest, Vol 134, Issue 11
>
> Send M100 mailing list submissions to
> m100@lists.bitchin100.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com
> or, via email, send a message with subject or body 'help' to
> m100-requ...@lists.bitchin100.com
>
> You can reach the person managing the list at
> m100-ow...@lists.bitchin100.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of M100 digest..."
>
>
> Today's Topics:
>
>1. Model 102 keys (Brad Grier)
>2. Re: Model 102 keys (Brian K. White)
>3. Re: Model 102 keys (Brad Grier)
>
>
> --
>
> Message: 1
> Date: Tue, 15 Feb 2022 22:01:21 -0700
> From: Brad Grier 
> To: m...@bitchin100.com
> Subject: [M100] Model 102 keys
> Message-ID:
> <
> camxs_2tbz7lbwemdjrdhxdqsqcrut0+rqhp_jt76o198c0_...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all, I've got a couple of dead keys on a Model 102. I understand they're
> the rubber dome type of keys. I'm thinking I can pop the keys, check and
> clean the contacts.
>
> But.
>
> They seem to be quite firmly affixed (haven't pulled too hard yet) so was
> wondering if there's something 'different' going on there regarding the way
> the keys are mounted and the best way to remove them.
>
> It doesn't look like an ALPS board that the others use...
>
>
> --Brad
>
>
> --
> --
> Brad Grier
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20220215/fb7a67d2/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Wed, 16 Feb 2022 04:49:03 -0500
> From: "Brian K. White" 
> To: m...@bitchin100.com
> Subject: Re: [M100] Model 102 keys
> Message-ID: <7298b690-bffa-f1bb-ac09-188247eff...@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Get a sharp bent-tip a dental pick and watch this.
>
> https://youtu.be/n_oyDYRDYzs
>
> It's not too obvious what the point was from the video I guess but the T
> key was almost dead, and so I swapped the rubber dome with the one from
> the right-shift key because I can live with the right-shift being dead
> if I have to.
>
> In the end, it not only fixed the T key, the right-shift still works
> fine. Both keys now work fine. Go figure.
>
> --
> bkw
>
>
> On 2/16/22 00:01, Brad Grier wrote:
> > Hi all, I've got a couple of dead keys on a Model 102. I understand
> > they're the rubber dome type of keys. I'm thinking I can pop the keys,
> > check and clean the contacts.
> >
> > But.
> >
> > They seem to be quite firmly affixed (haven't pulled too hard yet) so
> > was wondering if there's something 'different' going on there regarding
> > the way the keys are mounted and the best way to remove them.
> >
> > It doesn't look like an ALPS board that the others use...
> >
> >
> > --Brad
> >
> >
> > --
> > --
> > Brad Grier
> >
> >
>
>
> --
> bkw
>
>
> --
>
> Message: 3
> Date: Wed, 16 Feb 2022 06:34:44 -0700
> From: Brad Grier 
> To: m...@bitchin100.com
> Subject: Re: [M100] Model 102 keys
> Message-ID:
> <
> camxs_2uxzacjc956sv7fkx56warlge0xmourgax03-1hbwx...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Interesting. Glitch in the Matrix -- Brian, I didn't get your reply via
> email but did see it on the Discord mailing list roll-up (nice to have
> that!!).
>
> Thanks for posting that link to the video. It looks like you had no problem
> removing the key caps from the 

Re: [M100] dev system filenames

[Brian White]

if it was me I'd probably make it m100, t102, t200, but I can't justify
that based on consistency. Would the olivetti then be "om10"? yeck, and
what would pc-8201a be? just lop off the "pc-" and the "a"?

I'd probably end up just making the names longer. Even that would end up
looking inconsistent, because 100 would have the word "model" in the name,
maybe 102 and 200 too, but not any of the rest. You can't win :)

-- 
bkw

On Wed, Jan 5, 2022, 1:07 AM Willard Goosey  wrote:

>
> Should it be m200.def or t200.def?
>
> (yes im still alive)
> (yes i think this is actually happening soon)
>
> Willard
>
> Sent from my Galaxy Tab® A
>

Re: [M100] TPDD Client in pure bash

[Brian White]

Should. It has nothing in it that cares what the cpu architecture is, and a
pi running the standard raspian it comes with has bash.

It's cavalier with ram, but even that is nothing today, even on a pi zero
(512M) and might not even be noticeably slower.

I'll probably do a few things to reduce the ram usage sooner or later just
on principle, like walk the image file in chunks instead of loading the
whole thing, contiguous strings instead of arrays, less copying of large
things just to get small effects as a byproduct.

But the hex pairs and arrays are very convenient to work with and easy to
conceptualize how they map to the binary data. It reduces the mysteries a
lot while debugging.

--
bkw

On Sat, Aug 21, 2021, 10:02 AM Stephen Adolph  wrote:

> So would this run on a raspberry pi?  I would guess so?
>
>
> On Friday, August 20, 2021, Brian K. White  wrote:
>
>>
>> I've been working on this for a few weeks and I just hit the main
>> milestone that not only all the normal file access functions work, but the
>> FDC-mode functions work, including, dumping and restoring a whole disk
>> works. I just bootstrapped from a restore from a dump of a factory tpdd1
>> utility disk.
>>
>> https://github.com/bkw777/pdd.sh
>>
>>
>> So, it's now possible to create a TPDD1 Utility Disk from a download,
>> with no exotic hardware, just the TPDD1 drive itself and serial connection,
>> and the software, aside from this script itself, is just bash.
>>
>> And the special challenge I set myself because I just knew it was
>> possible: It's not only all done just in bash, it's all done right in the
>> initial single process. No subshells, let alone external programs like awk
>> etc, not even tr/cp/rm etc, not even other instances of bash from
>> FOO=$(function... ).
>>
>> It's all in-memory ops and all in the single initial instance.
>>
>> Of course every absolute statement has to have exceptions...
>> It has to call "stty" once at startup, and it has to run "mkfifo" once at
>> startup if the fifo doesn't happen to be still lyng around from a previous
>> run. In both cases, the external doesn't constitute much of a dependency
>> because they are both so standard. I even addressed a pretty wide range of
>> platform differences for the stty command so it should work out of the box
>> on all the bsds, osx, as well as linux. And sine they are just run once at
>> start up, not many times in the middle of some loop or in an aft-used
>> function, they dont constitute an inefficiency either.
>>
>> It was quite a challenge figuring out a way to collect, store,
>> manipulate, & reproduce binary data including NUL without resorting to an
>> external utility but there turns out to be a way to do it with read() and a
>> kind of brute force read-one-byte-at-a-time method where it is possible to
>> tell the difference between "the variable is empty because there was no
>> data", vs "the variable is empty because read() ate a nul byte as a
>> delimiter, by looking at the exit value from read(). That's enough to let
>> you store the information where the null byte existed, which is all you
>> need. to re-create it later in a file or tty.
>>
>> Then there is sleep that actually sleeps not a cpu eater poll, without
>> /usr/bin/sleep, and generally every bashism in the book.
>>
>> To be clear, my goal was to leverage bash for all it's worth, not to to
>> try for something like compatibility with ancient posix sh. The idea is
>> that bash is no longer new and exotic, and actually has a lot of powerful
>> tricks available built right in. It's possible to make actually performant
>> things in bash if you just do it right. Of course "do it right" is pretty
>> context sensitive. In order to satisfy the goal of avoiding forks, you have
>> to violate a lot of other good practices like, this thing is a sea of
>> global state and side effects. Fine, might as well wallow in it then.
>>
>> And now that that's working well enough that a restore of the tpdd1 util
>> disk works, What I really wanted was to see if I could successfully copy
>> this Disk Power for KC-85 disk I have. This is a TPDD client for KC-85,
>> that I got a working original disk and tape with an ebay purchase , and it
>> turns out that it does not include a way to back itself up, and when you
>> try to back it up some other way using Floppy on a 100 or PDD210.EXE in
>> dosbox etc, the copy looks fine, but the install doesn't work. You need
>> both the cassette and the singular irreplaceable original disk to install
>> it, which is a situation I refuse to accept. ;)
>>
>> I *believe* I can now make a copy that's thorough enough thanks to the
>> FDC-mode functions, that the copy would work... and *just* when I reached
>> this point where I'm finally ready to try it... My KC-85 stops working
>> Well it's marginal. Sometimes it comes on and works, but if I cold-reset,
>> the screen goes blank and stays that way. "beep" doesn't beep.
>>
>> Here a few pics of the Disk Power disk & tape.
>>

Re: [M100] Cassette woes

[Brian White]

The 40mv was legit. Olivetti M10 is different than Model 100. My own
machine and the manual itself both agree. I only get a out 30mv  myself.


bkw

On Tue, Jul 27, 2021, 11:37 PM Tom Wilson  wrote:

> I checked out my M102 on my scope, and the Peak to Peak is 624 mV. So
> definitely "line" level territory. (And the person who got 50mV PP on
> Facebook was probably using a 10x probe.)
>
>
> On Tue, Jul 27, 2021 at 6:33 PM Brian K. White 
> wrote:
>
>> Just discovered not all the machines are the same on this point. The
>> Model 100 manual does clearly state to use the AUX jack.
>>
>> But the Olivetti M10 manual says to use the MIC jack. And someone on
>> facebook just measured only 40mv p-p output, although he's diagnosing a
>> problem so it's not clear if that's normal or if his unit is off. But
>> the manual states clearly, in two different places with no ambiguity and
>> even with drawings that include the AUX jack, to use the MIC jack. And I
>> just scoped my M10's CSAVE output at 30mv p-p.
>>
>> --
>> bkw
>>
>> On 7/23/21 11:35 AM, Brian White wrote:
>> > What do you mean?
>> > aux is a line-in, so the 2 bigger plugs go in ear and aux, and mic is
>> > not used.
>> >
>> > Earlier I said you used ear and mic, and aux not used, which was
>> > wrong. I mis-remembered and thought aux was a line-out. I've actually
>> > been using a tape recently with no problem, but only for playback, so
>> > I had it hooked up wrong without knowing.
>> >
>> > bkw
>> >
>> > On Fri, Jul 23, 2021, 2:03 AM Peter Vollan > > <mailto:dprogra...@gmail.com>> wrote:
>> >
>> > so, there is no alternative to the mic jack, if I understand you
>> > correctly?
>> >
>> >
>> > On Thu, 22 Jul 2021 at 21:22, Brian K. White > > <mailto:b.kenyo...@gmail.com>> wrote:
>> >
>> > >
>> > > When you record a program, it is important to use the 'AUX'
>> > or 'Line'
>> > > input, not the MIC input, as the levels are radically
>> different.
>> >
>> >
>> > Sorry I was wrong about the AUX jack. I was really trying to
>> > say you
>> > don't use it for the ear, as though it were a line-out vs a
>> > line-in.
>> > So, ear, aux, rem. And for the black & grey cable, it's the
>> > black one
>> > that goes in ear.
>> >
>> > --
>> > bkw
>> >
>>
>>
>> --
>> bkw
>>
>>

Re: [M100] Cassette woes

[Brian White]

What do you mean?
aux is a line-in, so the 2 bigger plugs go in ear and aux, and mic is not
used.

Earlier I said you used ear and mic, and aux not used, which was wrong. I
mis-remembered and thought aux was a line-out. I've actually been using a
tape recently with no problem, but only for playback, so I had it hooked up
wrong without knowing.

bkw

On Fri, Jul 23, 2021, 2:03 AM Peter Vollan  wrote:

> so, there is no alternative to the mic jack, if I understand you correctly?
>
>
> On Thu, 22 Jul 2021 at 21:22, Brian K. White  wrote:
>
>> >
>> > When you record a program, it is important to use the 'AUX' or 'Line'
>> > input, not the MIC input, as the levels are radically different.
>>
>>
>> Sorry I was wrong about the AUX jack. I was really trying to say you
>> don't use it for the ear, as though it were a line-out vs a line-in.
>> So, ear, aux, rem. And for the black & grey cable, it's the black one
>> that goes in ear.
>>
>> --
>> bkw
>>
>

Re: [M100] Cassette woes

[Brian White]

Then perhaps the reason it sometimes makes a difference is from some other
effect, like draining the power rail on an old unit that's marginal or
injecting noise into the power rail or some other line. Regardless, it
happens in reality, which means any theories that disagree are simply
missing something.

bkw

On Tue, Jul 20, 2021, 9:23 PM Stephen Adolph  wrote:

> sound on/ sound off is a software function purely.  look at the schematic.
>
>
> On Tue, Jul 20, 2021 at 8:30 PM you got me  wrote:
>
>> I have 'seen' SOUND ON/SOUND OFF have an impact on the computer detecting
>> an input signal. It does happen, but may be due to degraded components
>> (capacitors?) within the input path as the analog signal gets turned into
>> TTL.
>> --
>> *From:* M100  on behalf of Stephen
>> Adolph 
>> *Sent:* Wednesday, July 21, 2021 12:19 AM
>> *To:* m...@bitchin100.com 
>> *Subject:* Re: [M100] Cassette woes
>>
>> " Yes "sound on" can rob some of the signal and/or make it less distinct,
>> so the computer has more trouble reading it.  "
>>
>>   ah... I disagree.  Sound "on" has no impact.
>> The SID input of the CPU is used solely to detect zero crossings, and
>> that info is used to toggle the PIO that drives the buzzer.
>>
>>
>> On Tue, Jul 20, 2021 at 8:03 PM Brian K. White 
>> wrote:
>>
>> Yes "sound on" can rob some of the signal and/or make it less distinct,
>> so the computer has more trouble reading it. That was just for initial
>> testing to verify that the signal is actually reaching the 100. Once you
>> have verified that there is nothing obviously wrong with the signal like
>> it's missing entirely or has scratchy corruption like from dirty
>> contacts or broken wires or dirty volume pot, or is very muffled and
>> dull like from excessively dirty read head or missing felt pad in the
>> cassette itself, then you no longer want sound on for actual reading.
>>
>> In there I just reminded myself something to check: The felt or foam pad
>> in the cassette that presses the tape to the head. They are very often
>> fallen off and lost from the adhesive drying out after 20-30 years.
>>
>> If you got "file found" but the file was ignore, I think that might just
>> be a matter of matching up the file name at CSAVE time and at CLOAD time.
>>
>> When you CLOAD you specify a filename, and it ignores any files on the
>> tape that don't match.
>>
>> In general, I've had perfectly expected results with tape. Meaning,
>> there is a bit of trial & error dialing-in the right volume setting to
>> get it working the first time, and with every new tape or tape player,
>> but it's really been no problem, on several different machines and tape
>> players.
>>
>> It just doesn't work all by itself like a disk drive does. You just have
>> to be aware of a few things and you are a little more a part of the
>> process. Like you the human are one of the components in the system,
>> detecting and adjusting for several potential sources of variation in
>> other parts of the system.
>>
>> Like checking the sound quality with SOUND ON, and testing a few
>> different volume levels to figure out that "this particular player, with
>> most tapes, with fresh batteries, and talking to this particular M100,
>> the best volume setting is 7." and you find "7" by testing methodically
>> from definitely too-low like 5, all the way to 10, and noting the lowest
>> and the highest settings that still work, and using a setting from the
>> middle of that range most of the time. And then deviating from that
>> sometimes if some particular tape is recorded a little softer or louder
>> or is worn from being played a lot, or maybe the sweet spot is a little
>> different on rechargeable batteries (1.2v), vs alkoline batteries
>> (1.5v), vs using the wall power for the player, or for the 100 too for
>> that matter. One M100 might be a little more of less sensitive than
>> another due to slight variations in some of the components and things
>> like caps aging over time, and things like how one M100 might come from
>> a an early manufacturing run and another might come from much later
>> after some revisions and component supplier changes, or one may have
>> spent the last 35 years in a hot environment or in an environment that
>> cycles hot & cold a lot, and another might have spent the last 35 years
>> in a very stable and cool environment.
>>
>> But even with all those sources of potential variation, it still
>> actually works pretty well. So I think there is just some relatively
>> simple thing you just haven't found yet. It still might be anything like
>> maybe you're still doing something wrong, or some problem with the
>> player that you don't realize because you don't have 5 other players to
>> compare against. The first player I got off ebay  didn't work either
>> (but it didn't work at all, no sound at all), and by now I've gotten 4
>> or 5 more and at least one of those was bad too. They are all very old
>> by now and so every 

Re: [M100] Why an incorrect COM configuration string still works on the M100/T102

[Brian White]

The same thing is in the TPDD1 manual too, just at 9600 instead of 19200,
and they don't word it as a suggestion in either one, it is just the
directions full stop.

I think the way to stop thinking it's "wrong" is to realize, simply, these
are not directions for how to operate your com port, they are directions
for how to operate a peripheral.

Those are two different jobs.

It's ok that the directions for the disk drive says something slightly
different than the manual for the 100. The disk drives directions job is
only to make the disk drive work. It's not telling you "here is how your
com port works, do this every time you want to use the com port" and it
doesn't say anything like that, so the only error is in reading anything
else into that.

bkw

On Tue, Jul 20, 2021, 9:00 AM Jeffrey Birt  wrote:

> A few eagle-eyed viewers noticed I used a slightly incorrect configuration
> string in the Backpack Quick Start video. This generalized configuration
> string was used as it works on the model 100, 102, and 200 and in fact was
> suggested in the TANDY TPDD2 manual. But how can it still work if it’s
> wrong? In this video we take a quick look at why using an incorrect COM
> configuration string on the TRS-80 Model 100 / Tandy 102 still works. Join
> us and find out.
>
>
>
> https://youtu.be/auUjU8hdyJo
>
>
>
> Jeff Birt (Hey Birt!)
>

Re: [M100] Howdy! New to list, need some parts…

[Brian White]

Same thing for the memory switch.

Just hit it with deoxit at work it several times. It should be perfect in a
few seconds (No potential 2 weeks drying time because it's not a tightly
closed enclosure, plus it's a crude power circuit not a super sensitive
signal like the contrast pot. It works fine even while still drenched).
Never heard of the switch actually being bad other than just dirty or
oxidized.

If you removed the memory battery but didn't put a new one back in it's
place, get a new one and install it. Google/ebay "3/v80h 2p" or go to
arcadeshopper.com


bkw

On Sat, Jul 17, 2021, 12:13 AM Brian White  wrote:

> Usually DeoxIt clears up the contrast pot. Just spray it, don't worry
> about overspray, operate it a few times, wait an hour, operate a few more
> times, then possibly wait some more for the interior to dry. Can possibly
> take as long as a couple weeks if it was really drenched.
>
> The entire screen may go faint while it's wet but it comes back as it
> dries, don't worry if you see that.
>
> Also check for bad solder joints since the pot is subject to mechanical
> force from outside. Always possible it took a hit somewhere along the way
> in 35 years.
>
> bkw
>
> On Fri, Jul 16, 2021, 10:28 PM Earl Baugh  wrote:
>
>> Howdy!
>>
>> I’m new to the list and recently picked up a model 100 that needed some
>> restoration.  A friend helped me get the bad caps replaced, cleaned the
>> power plug and we diagnosed a bad member switch and bad pot for the lcd
>> contrast adjustment.  It’s working again (hurrah), with a solder bridge on
>> the switch and some resistors temporarily in place of the pot.  ( we also
>> removed the battery before any leakage or damage )
>>
>> Is there anyplace where I can get replacement parts for the pot and
>> switch without digging thru a Mouser or Digikey catalog? (  or the part
>> numbers at least to save a number of mis orders? )
>>
>> Earl
>>
>>
>> Sent from my iPhone
>
>

Re: [M100] Howdy! New to list, need some parts…

[Brian White]

Usually DeoxIt clears up the contrast pot. Just spray it, don't worry about
overspray, operate it a few times, wait an hour, operate a few more times,
then possibly wait some more for the interior to dry. Can possibly take as
long as a couple weeks if it was really drenched.

The entire screen may go faint while it's wet but it comes back as it
dries, don't worry if you see that.

Also check for bad solder joints since the pot is subject to mechanical
force from outside. Always possible it took a hit somewhere along the way
in 35 years.

bkw

On Fri, Jul 16, 2021, 10:28 PM Earl Baugh  wrote:

> Howdy!
>
> I’m new to the list and recently picked up a model 100 that needed some
> restoration.  A friend helped me get the bad caps replaced, cleaned the
> power plug and we diagnosed a bad member switch and bad pot for the lcd
> contrast adjustment.  It’s working again (hurrah), with a solder bridge on
> the switch and some resistors temporarily in place of the pot.  ( we also
> removed the battery before any leakage or damage )
>
> Is there anyplace where I can get replacement parts for the pot and switch
> without digging thru a Mouser or Digikey catalog? (  or the part numbers at
> least to save a number of mis orders? )
>
> Earl
>
>
> Sent from my iPhone

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

[Brian White]

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.

-- 
bkw

On Tue, Jul 13, 2021, 4:21 AM Brian Brindle  wrote:

> >> That is strange. Remember, UR2 works with a real tpdd which has no such
> thing as a current directory label, and as well, the whole point of the UR2
> stub on-demand loader is that you don't have TS-DOS installed, either ram
> or rom.
>
> I'm probably not articulating what I'm trying to say right, it's
> sometimes impossible for me to talk without a whiteboard. I'd explain why,
> but we'd need a whiteboard.
>
> Here is the behavior I have observed:
>
> TS-DOS seems to always use M1, or at least does when loading a directory
> anyway. UR2 does not when asking for DOS100.CO.
>
> (Working Dev)
> UR2:
> RX: 5A 5A 07 00 F8 0D - ZZ
> TX: 12 01 00 EC 0D 0A 3E 20 - >
>
> RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20
> 20 20 20 20 20 46 00 - ZZ..DOS100.CO  F
> TX:  11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20
> 20 20 20 46 FF FF 9D - DOS100.CO F
> RX: 5A 5A 01 01 03 FA - ZZ
> TX: 12 01 00 EC
> RX: 5A 5A 03 00 FC - 
>
> TS-DOS:
> RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ
> TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
> RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ
> TX: 12 01 00 EC
> RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ
> TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
> RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ
> TX: 12 01 00 EC
> RX: 5A 5A 08 00 F7 - ZZ
> TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
> RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20
> 20 20 20 20 20 46 00 - ZZ DOS100.CO F
> TX: 11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20
> 20 20 20 46 FF FF 9D - DOS100.C0 F
>
> So, in my playing it looks like when you swap back to TS-DOS, load a
> directory it runs the PDDuino through the M1 routine, sets the dmeLabel then
> when you flip to the UR2, do the load DOS it takes the ZZ DOS100.CO F
> without any issue. Do just the ZZ DOS100.CO F without dmeLabel set it
> just looks at you.
>
> - Brian
>
>
>
> On Mon, Jul 12, 2021 at 11:26 PM Brian White  wrote:
>
>>
>>
>> bkw
>>
>> On Mon, Jul 12, 2021, 9:48 PM Brian Brindle  wrote:
>>
>>>
>>>
>>> On Mon, Jul 12, 2021 at 5:34 PM Brian K. White 
>>> wrote:
>>>
>>>>
>>>>
>>>> master actually? or latest default branch which is not master but 0.4.1?
>>>> I didn't have master marked as default currently because I thought I
>>>> had
>>>> made it worse, you know like the partly-broken point mid-way in a
>>>> refactor, so I made the last-known at least basically-minimally-working
>>>> version default.
>>>>
>>>> But if you're actually using the master branch that's great and I'll
>>>> switch that to default. That is where I started porting Jim's main loop.
>>>>
>>>
>>> I'm using the Master. I had a lot of issues with the current default.
>>> Granted I didn't improve my situation by mucking with it, but I stumbled on
>>> the Master, saw the changes you made and liked them so went with it. It's
>>> been working pretty well since.
>>>
>>> Biggest thing I saw was the PDDuino would wander off looking for
>>>
>>>> > label information and not respond to drive commands. Like when trying
>>>> to
>>>> > load TS-DOS from the UR2 it would fail unless you could force the
>>>> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a
>>>> directory,
>>>> > then it would happily go on to the load step. It is somewhat working
>>>> now
>>>> > so I took a break from it, although my M0 still doesn't work and I'm
>>>> not
>>>> > 100% sure why but I think it's the guy from SdFats fault..
>>>>
>>>> I'd love to know the fix for that. I wrote a whole paragraph in the
>>>> front page readme about it just as a bug description to be figured out
>>>> sometime.
>>>>
>>>
>>> I did a lo

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

[Brian White]

bkw

On Mon, Jul 12, 2021, 9:48 PM Brian Brindle  wrote:

>
>
> On Mon, Jul 12, 2021 at 5:34 PM Brian K. White 
> wrote:
>
>>
>>
>> master actually? or latest default branch which is not master but 0.4.1?
>> I didn't have master marked as default currently because I thought I had
>> made it worse, you know like the partly-broken point mid-way in a
>> refactor, so I made the last-known at least basically-minimally-working
>> version default.
>>
>> But if you're actually using the master branch that's great and I'll
>> switch that to default. That is where I started porting Jim's main loop.
>>
>
> I'm using the Master. I had a lot of issues with the current default.
> Granted I didn't improve my situation by mucking with it, but I stumbled on
> the Master, saw the changes you made and liked them so went with it. It's
> been working pretty well since.
>
> Biggest thing I saw was the PDDuino would wander off looking for
>
>> > label information and not respond to drive commands. Like when trying
>> to
>> > load TS-DOS from the UR2 it would fail unless you could force the
>> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory,
>> > then it would happily go on to the load step. It is somewhat working
>> now
>> > so I took a break from it, although my M0 still doesn't work and I'm
>> not
>> > 100% sure why but I think it's the guy from SdFats fault..
>>
>> I'd love to know the fix for that. I wrote a whole paragraph in the
>> front page readme about it just as a bug description to be figured out
>> sometime.
>>
>
> I did a lot of debugging on this, both with a serial monitor and with the
> debug options on the pdduino. I came to the conclusion that it had
> something to do with dmeLabel not getting set. When watching the
> interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and
> that's it. TS-DOS did a little dance that gave it the root dir first and
> set dmeLabel.
>


That is strange. Remember, UR2 works with a real tpdd which has no such
thing as a current directory label, and as well, the whole point of the UR2
stub on-demand loader is that you don't have TS-DOS installed, either ram
or rom.

Ken Pettit has a TS-DOS disassembly in his directory on club100 that we can
consult too when it comes to nailing down a real mystery.

Maybe it's something where IF the server says it supports directory
extensions (by acknowledging one of the commands that should be unknown to
a real tpdd), THEN the label must actually be supplied at various times,
and I'm missing some.

We had discussed here not too long ago the idea of having a tpdd server at
least have an option to treat some filenames specially, like having
DOS100.CO always work regardless of current directory. It sounds pretty
sensible to me, but if the UR2 loader always cds to root first, then that
means there is no point.

That would also mean the root label is not free to be whatever I think it
should be, but has to be whatever UR2 cds to or looks for (or else we hack
UR2, or else we recognize UR2 requests and fake whatever makes it happy.) I
don't like "ROOT" as the root dir label. I will not use it unless forced to
by something like ur2 just requires it or something. Similarly for "PARENT".

I always had the idea that there could be a whole raft of virtual files
that don't actually exist but that could be used to issue commands or
return data like RTC time etc, like /proc /sys etc. They could even be in
their own virtual sub dir. The dir could even be invisible where it isn't
listed in  the root directory listing, but never the less works if you
request the right dir and filenames.

I like the idea that, at least for some things, you might be able go use
them by just opening the "file" in TEXT. Or sched or addr for that matter.
You could have a 2 MB address book for real, but a virtual addr.do that
only sees a 5k window of it at any given time.

I don't actually know what all the useful uses might be but it just seems
obvious to provide the facility simply because you can, and maybe someone
else comes up with functions that are made possible by using the facility.


I mucked with this quite a bit but stupidly went down the route of trying
> to make DOS100.CO found no matter what the current directory was but
> regretted that after I started thinking it was short-sighted for other
> things not DOS100.CO. I'll have some more time here soon to keep playing.
>
>
>>
>> So far, actually the lowly 32u4 feather board is actually my favorite.
>> The teensy's have gobs more power obviously, but for this task the 32u4
>> does the job so the extra power doesn't matter until we start adding
>> features beyond straight tpdd. Either feather is better than the teensy
>> (until you start needing the horsepower) for the sake of:
>> * asymmetrical pin headers for polarity enforcement,
>> * built-in lipo manager
>> * card detect switch,
>> * ...which an interrupt can be assigned to
>> * extra on-board led for the card slot
>>
>> I'm with you 

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

[Brian White]

On Sun, Jul 11, 2021, 8:14 AM Brian Brindle  wrote:

> > I didn't think anyone else was actually trying them out.
>
> BKW - I just assumed the MountT was wildly popular based on how simple and
> awesome it was. I'm genuinely jealous that I didn't think of it.. I'll be
> honest, there is something in my training/experience that was like DO NOT
> HOOK THINGS UP WITHOUT BUFFERING/PROTECTION/ETC!
>

You are not wrong of course. But little diy toys like this have to be
compromises to make them doable.


Then you go and pop a USB jack on the BC port and the world didn't end and
> it's worked great.
>


That IS a bit risky. Ideally there should be some sort of current limit to
avoid drawing more than 50 or 60 ma. But I don't know how to do that in a
small practical way.

At least I made sure the BOM has a plastic plug and stressed in the docs
why this is important even though that plug is uncommon and expensive while
normal metal shell plugs are dirt cheap.

(the metal shell of normal de9f shorts the power and ground pins, you
should never use a metal shell de9f in the bcr port)





> I'm a daily carrier of my Model-T, I write a lot but 90% of what I do with
> it is useless tinkering to make it do stuff similar to what my phone and
> readily available laptop can do. In fact, in most instances my laptop is
> hooked up and running to debug the thing that isn't working right on the
> M100. That being said, the PDDuino provided weeks of endless debugging
> entertainment.
>

Yes that does still need a lot of debugging sorry ;)

Jim Brain did some work on it and the idea didn't work out, but there is a
lot he did that are good ideas that I'd been meaning to cherry pick.
Actually I already did some of that.

It's still not quite all the way there yet. It still doesn't work with
other clients like WP-2. I think it's still limited to TS-DOS.

My problem last time I was working on it was I think enabling debugging is
screwing it up. Things work without debugging, and break with debugging,
well great now what? haha


I checked out your latest code for it recently with the new main loop and
> it works very well now and is my "daily-driver" for storage.
>
> I very much respect all of you guys who can not only do this stuff but
> document it where others can play along. I seem to fail miserably at that.
> I do have a current project in the works that I hope to change that with..
> We will see.
>
> After 20+ years of using M100s I stumbled on an M102 cheap and snatched it
> up. I worked at Radio Shack back in the 90s as a teen and remember lusting
> after the discontinued M102 but hadn't touched one since then. I much
> prefer the size/weight and keyboard to my M100. I also like the system bus
> being accessible like it is so built a little jig for my project. I
> followed your example and added a USB port to it to power my PDDuino, once
> I get a real board made for it I'll get the right length USB cord and it
> will look as awesome as the M100 does with the MountT, but here it is:
>
> http://niedobry.com/mod100/images/bus_jig.jpg
>
> Brian
>


Nice.

Yeah The upside down ports on 102 are annoying. IOlivetti is the same. For
those I just decided to rely on right-angle usb cables rather than multiple
versions of the pcb. Half the point was to remove all the ways to get
things wrong like with the wrong serial wiring etc. Though, at least for
the Feather boards, since they have asymetrical pins, you could safely have
two sets of holes on the same board. For teensy boards, you can already
plug them in wrong now, but at least with only a single set of holes, you
can have a single silkscreen showing the single correct way.

For that bus board, if you use a vertical usb port, it can be moved below
or above the system bus so that it doesn't block the printer port, and you
can include a pass through pin header so the system bus is still usable for
DVI. Though the port would stick out then. Maybe a horizontal port could
still be used just in some other position.

Well thank you for the kind words. I think everything I've done so far has
actually been pretty low hanging fruit. I could not have designed REX for
instance. And I have yet to manage even a hello world in machine language.
I didn't write either dlplus or pdduino just picked them up and did a
little work on them, etc.




> On Sat, Jul 10, 2021 at 4:08 AM Brian K. White 
> wrote:
>
>> On 7/9/21 4:21 PM, Peter Vollan wrote:
>> > You'll have to explain what that is past the printer and serial ports.
>> https://github.com/bkw777/MounT
>> https://github.com/bkw777/BCR_Breakout
>> https://github.com/bkw777/PDDuino
>>
>> I didn't think anyone else was actually trying them out.
>>
>> --
>> bkw
>>
>>
>> > On Fri, 9 Jul 2021 at 13:01, Brian Brindle > > > wrote:
>> >
>> > I found this thing called a "Laptop Foot" at the checkout of my
>> > local Barnes and Noble the other day. I am slightly embarrassed to
>> > admit that I paid $12 for it but also 

Re: [M100] Question on TEENY.EXE

[Brian White]

> LAPTAP.EXE's way is better, you should try that, I think you'll like it.
>

I'll check it out.

-- 
bkw

Re: [M100] Question on TEENY.EXE

[Brian White]

Laddie works great as a tpdd emulator, but it just doesn't include a
bootstrapper to install a client. If you have a REX or an actual TS-DOS
option rom (or build a Teeprom, but you can buy a much more useful REX# for
the same or less cost) then Laddie is great. But if you need to install the
client then you need mComm or teeny.exe or dlplus in addition just to use
it's bootstrapper.

You CAN transfer the same loader.ba file manually with a comm program and
TELCOM to install a client manually, but it's more complicated, more
error-prone, and silly to bother since dedicated utils exist specifically
to remove all the variables, moving parts, and pitfalls, and reduce the
number of steps and special instructions of that process.

There is also an mp3 of the cassette version of TS-DOS which you can
install using the cassette cable and a phone with a headphone jack. That's
simpler and more reliable than the manual telecom process but again,
pointless, because if you're installing a tpdd client, it's probably to use
a tpdd emulator, in which case you need the same serial and usb cable
anyway. The cassette/mp3 installer would be useful in the theoretical
old-days situation where you need a way to install a tpdd client to use
with an actual tpdd drive. The drive comes with a special disk for that so
that you can bootstrap with nothing but the drive, but that only provides
the basic tpdd client called FLOPPY, not TS-DOS. So, if you had your 100
and TPDD and a cassette player, and modern machines didn't exist yet, you
could recover from a reset and install TS-DOS using the cassette. Today
that's just an unnecessary excersize.

-- 
bkw

On Tue, May 4, 2021, 10:35 AM Jerry Davis  wrote:

> Hello, Steve
>
> Good question.  Sometimes I'm not quite sure how I got where I am on a
> given solution.  I began by reading through the M100 mail archive starting
> at the bottom.  I found many, many references to TEENY in one form or
> another.  References to LaddieCon and LaddieAlpha from about the middle on
> up.  I think I even ended up reading a good interview article written about
> the operators of the bitchin100.com site and the author of LaddieCon.
> Don't remember how I got there.
>
> What I did was pick a solution and go with it, i.e. TPDD emulator and a
> TPDD client, and then adapt from there.  At the time, TEENY seemed to be a
> good place to start.  Part of the fun for me is learning how to do things,
> seeing how much experience I can pick up by trying different things, and
> asking a question or two when I get stuck.  Which sometimes means I end up
> traveling on a dead end street.  But that's OK because I like to drive.
> With one question I've gotten a lot of great advice just this morning
> which is clearing up some of the information fog for me.
>
> Your suggestion for LaddieAlpha is on my list to explore.  I had
> originally thought that LaddieCon wasn't recommended and LaddieAlpha was
> for Linux only, but after you mentioned it I read the information you
> directed me to more carefully and it's cross-platform.  So I'm now going
> "Ah Ha"!  Not sure how I missed that.  Probably too many late nights, I
> guess.  It's hard to read when I'm trying to see things.
>
> Thanks for your help on this.
>
> Jerry
>
> On Tue, May 4, 2021 at 8:27 AM Stephen Adolph 
> wrote:
>
>> Jerry, why are you not using LaddieAlpha?  it is the most mature solution
>> in my opinion, and it runs native on Windows 10?  I use it a lot.
>>
>> I would separate the "bootstrap" from the "usage".  Bootstrap is pretty
>> easy. I just transfer a text version of Teeny..BA.  I don't bother with the
>> injection aspect of Teeny.EXE on a PC at all anymore.
>>
>> ..Steve
>>
>> On Tue, May 4, 2021 at 9:20 AM Jerry Davis  wrote:
>>
>>> Justin, Georg, and Brian.  Many thanks for your assistance on this.
>>> I'll get the cable up to spec and verify physical layer is the way it's
>>> supposed to be, try again, and report back.  I'll also test with mComm as
>>> that appears to be a better way to get the client installed.
>>>
>>> Thanks again!
>>>
>>> Jerry
>>>
>>>
>>> On Tue, May 4, 2021, 7:45 AM Brian K. White 
>>> wrote:
>>>
 On 5/4/21 7:20 AM, Justin Poirier wrote:
 > Just a quick reply, but when troubleshooting serial, I always start
 slow
 > and work my speed up. Don't start at 19.2k. Start at 300, and work
 your
 > way up. I've had mixed results across my Model 102/200 machines when
 I
 > go much past 2400.

 In general yes, but not for this.

 TEENY.EXE is hardcoded to run at the same speed as the TPDD which
 itself
 is hardwired to run at 19.2k. TEENY.EXE has it's own small delay
 between
 each character to dribble the bytes in slow enough even though the
 serial port is set to 19.2k, and,it uses a BASIC command to read the
 port raw without any screen updates.

 The most likely problem here is that TPDD requires more than just
 TX/RX/GND.

 At the very 

Re: [M100] club100 member uploads

[Brian White]

Thanks much. I see an old post from Rick mentioning that now that you gave
me a pointer. And even without macdos, that reminded me of lapdos and some
other msdos emulator pdd.exe? . 2 more chances to find something that works
even if they are both for msdos. Plus maybe possibly windows mcomm.

bkw

On Sat, Apr 17, 2021, 3:09 AM John R. Hogerhuis  wrote:

> There's a program called MacDOS II, I believe it's a TPDD emulator for
> older macs. Not sure what vintage. I don't know where to find it.
>
> If he can find development tools for the machine, dlplus might be the best
> bet.
>
> -- John.
>

Re: [M100] M100 DVI cover panel

[Brian White]

Nice, thank you.

bkw

On Thu, Apr 15, 2021, 7:20 PM Peter Noeth  wrote:

> I fixed my Thingiverse files for the Model 100 Option ROM Covers. When I
> accessed them, all the notes and instructions were missing. Thingiverse
> must have had a data crash and lost it.
>
> The STL files are in millimeters, which seems the default of slicers. The
> finished dimensions are now listed in the summary sectionals are the basic
> settings I used.
>
> Good Luck!
>
> Regards,
>
> Peter
>
>>
>> Message: 1
>> Date: Mon, 12 Apr 2021 17:55:05 -0700
>> From: Peter Noeth 
>> To: Model 100 Discussion 
>> Subject: Re: [M100] M100 DVI cover panel
>> Message-ID:
>> > hw0g4...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Scale all dimensions by 25.4. It was done in "AutoCAD units". If your
>> slicer is expecting millimeters, then it will be too small. STL files do
>> not include a "units=xxx" command. There is a note in the Thing about
>> this.
>> When I get some time, I will convert to 1:1 scale in millimeters, which
>> seem to be what other slicers use as default (mine is set to "inches" so I
>> don't have any problem).
>>
>> Regards,
>>
>> Peter
>>
>> >
>> > Message: 5
>> > Date: Sun, 11 Apr 2021 21:51:42 -0400
>> > From: "Brian K. White" 
>> > To: m...@bitchin100.com
>> > Subject: Re: [M100] M100 DVI cover panel
>> > Message-ID: 
>> > Content-Type: text/plain; charset=utf-8; format=flowed
>> >
>> > On 4/11/21 5:11 PM, James Zeun wrote:
>> > > Does anyone know what the dimensions should be for this DVI cable
>> > > cover panel?
>> > >
>> > >
>> >
>> https://www.thingiverse.com/thing:4616079?fbclid=IwAR2HDDXRl06ow3DkbfWGutJGhVC6RFW9hzy9PIJUMKAi7IttJ8jZXLVyxWo
>> > > <
>> >
>> https://www.thingiverse.com/thing:4616079?fbclid=IwAR2HDDXRl06ow3DkbfWGutJGhVC6RFW9hzy9PIJUMKAi7IttJ8jZXLVyxWo
>> > >
>> > >
>> > >
>> >
>> >
>> > Good question. The STL file is somehow scaled wrong or drawn in units of
>> > feet or even yards or something.
>> >
>> > Even when I load it in FreeCAD with the units set to inches, the part
>> > comes out with dimensions like 0.1205 inches on the longest side, which
>> > is ridiculous.
>> >
>> > Measuring a real cover:
>> > The main rectangle is 77.7mm x 57.8mm
>> > Maybe you can figure out how to scale the model correctly based on that
>> > to get all the other dims.
>> >
>> > If you're drawing a new model from scratch, a 40-pin ribbon cable is
>> > 51mm wide, make the slot whatever you want based off that starting
>> point.
>> > There's no immediate lip or other obstruction on the edge of the opening
>> > where the ribbon cable needs to come out, so the notch for the cable
>> > doesn't have to be any particular depth. 3 or more mm should be fine.
>> >
>> > The two rear tabs (not on the side with the finger pull)
>> > 4.04mm wide each, 59.9 mm apart inside edge to inside, 3.0mm stick out,
>> > 1.6mm thick, resting on the bottom (inside) surface not extending the
>> > main flat rectangle.
>> >
>> > The front tabs, on the side with the finger pull
>> > 6.06mm wide each, 43.85mm apart inside edge to inside edge
>> > The hook part is complicated to describe without a drawing. The part
>> > that hooks in front only sticks out about 0.5mm and starts about 1.3mm
>> > off the bottom (inside) surface of the main flat part.
>> >
>> > --
>> > bkw
>>
>>

Re: [M100] TPDD service manual

[Brian White]

Nope.

I think it's Mark J. Blair, aka Stardust on OSHPark, who has posted about
these similar boards once or twice here on the list. It doesn't look like
it's one of these boards, but a new version that isn't public. The new one
uses a through hole db25 mounted flat on the pcb like MounT. And none of
these are like that.

https://oshpark.com/profiles/Stardust/

So it looks like he's aiming to sell these so there are no plans or code,
and if it's not quite ready for sale yet then there is no purchase site yet
either.

Which now that think about it, when he posted about it to the list before,
he said he started with dlplus and then highly modified it. Which means
he's obligated to post his code somewhere because dlplus is gpl.

-- 
bkw

On Sat, Mar 20, 2021, 11:03 PM Kurt McCullum  wrote:

> That is very cool! Do you have a link to the actual project.
>
> On Sat, Mar 20, 2021, at 5:25 PM, Brian K. White wrote:
>
> Someone else is just finishing a different approach where he designed a
> custom board with everything including the mcu.
>
>
> https://www.facebook.com/groups/Model.T.Computers/permalink/4297639010296577
>
> --
> bkw
>
>
>

Re: [M100] TPDD service manual

[Brian White]

ah ok thanks

On Sat, Mar 20, 2021, 9:59 AM Jeffrey Birt  wrote:

> It is not that it is just ‘less sensitive’. I’m really stretching my
> memory from the research I did on the subject here but as I recall the
> composition of the coating of the disk is different (something like the
> particle size of the ferrous material being smaller). To flip the domain on
> this new HD coating requires a stronger magnetic field. The DD drive cannot
> output a strong enough magnetic field to properly magnetize the new HD
> coating.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Brian
> White
> *Sent:* Saturday, March 20, 2021 8:49 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> Not that it changes anything, but I thought the problem with the density
> difference was that the lower density drive would put out a stronger signal
> needed for the less sensitive media, and so the problem with using hd media
> in a dd drive would be that the dd drive would overdrive the media making a
> distorted signal?
>
>
>
> Is it actually  the opposite, that the way they achieved higher density is
> by using less sensitive media driven by a stonger head?
>
>
>
> On Sat, Mar 20, 2021, 8:35 AM Jeffrey Birt  wrote:
>
> Oh, sorry I misread what you wrote. But to your point, that could be done.
> I use a SuperCard Pro to image floppies which is just a PIC uC with
> supporting HW and some spiffy firmware/software. It can image TPDD1/2 disks
> easily using a standard 3.5” 1.44MB drive. The software does know how to
> interpret the data, it is just a flux map. The .SCP format is well
> documented though so one could figure out how to recreate the disk file
> structure from it.
>
> There is a similar device called the Flux Engine that has already done the
> file system decoding and can image/interpret TPDD disks using a standard
> 3.5” 1.44MB drive.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 7:28 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> not exactly the point I was trying to make.
>
> pretty clearly a TPDD1 cannot use an HD floppy.
>
> but a small microcontroller that speaks TPDD protocol and has integrated
> FDC function could interface with a modern FDD.
>
> ..steve
>
>
>
> On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt 
> wrote:
>
> High density disks, both 3.5 and 5.25, require a much higher flux level to
> write. A system designed for DD disks will not be able to write to them
> reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for
> example only to find that it reads for a while but after a few weeks or
> months it no longer does. You can generally write to lower density disks
> with a HD drive. The exception being that it is best to write 360K
> 5.25”disks with a 360K drive as the head on these drives was physically
> larger and the narrower track written by a higher density drive may not
> work well on all 360K drives.
>
> My take on the TPDD is that it was designed to be cheap (simple) and
> portable. Thus, they used a simple 8-bit micro to control everything and
> not one of the floppy disc controller ASICs that were available at that
> time. But, they wound up with something that would run on AA batteries and
> use standard media at the time even if the storage capacity was limited.
>
>
>
> Jeff Birt
>
>
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 5:59 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> this is quite interesting, and nice detective work.
>
> It would seem like an interesting use case here could be to modify this
> firmware to make it target a standard 1.44MB floppy disk drive.
>
> Maybe it would seem a bit backwards because SD cards are more mainstream,
> but still interesting to think about.
>
>
>
> I see you have the disassembly in place.
>
>
>
>

Re: [M100] TPDD service manual

[Brian White]

Not that it changes anything, but I thought the problem with the density
difference was that the lower density drive would put out a stronger signal
needed for the less sensitive media, and so the problem with using hd media
in a dd drive would be that the dd drive would overdrive the media making a
distorted signal?

Is it actually  the opposite, that the way they achieved higher density is
by using less sensitive media driven by a stonger head?

On Sat, Mar 20, 2021, 8:35 AM Jeffrey Birt  wrote:

> Oh, sorry I misread what you wrote. But to your point, that could be done.
> I use a SuperCard Pro to image floppies which is just a PIC uC with
> supporting HW and some spiffy firmware/software. It can image TPDD1/2 disks
> easily using a standard 3.5” 1.44MB drive. The software does know how to
> interpret the data, it is just a flux map. The .SCP format is well
> documented though so one could figure out how to recreate the disk file
> structure from it.
>
> There is a similar device called the Flux Engine that has already done the
> file system decoding and can image/interpret TPDD disks using a standard
> 3.5” 1.44MB drive.
>
>
>
> Jeff Birt
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 7:28 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> not exactly the point I was trying to make.
>
> pretty clearly a TPDD1 cannot use an HD floppy.
>
> but a small microcontroller that speaks TPDD protocol and has integrated
> FDC function could interface with a modern FDD.
>
> ..steve
>
>
>
> On Sat, Mar 20, 2021 at 8:20 AM Jeffrey Birt 
> wrote:
>
> High density disks, both 3.5 and 5.25, require a much higher flux level to
> write. A system designed for DD disks will not be able to write to them
> reliably. Some folks have tried HD 3.5” disks in an Amiga or Mac for
> example only to find that it reads for a while but after a few weeks or
> months it no longer does. You can generally write to lower density disks
> with a HD drive. The exception being that it is best to write 360K
> 5.25”disks with a 360K drive as the head on these drives was physically
> larger and the narrower track written by a higher density drive may not
> work well on all 360K drives.
>
> My take on the TPDD is that it was designed to be cheap (simple) and
> portable. Thus, they used a simple 8-bit micro to control everything and
> not one of the floppy disc controller ASICs that were available at that
> time. But, they wound up with something that would run on AA batteries and
> use standard media at the time even if the storage capacity was limited.
>
>
>
> Jeff Birt
>
>
>
>
>
> *From:* M100  *On Behalf Of *Stephen
> Adolph
> *Sent:* Saturday, March 20, 2021 5:59 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] TPDD service manual
>
>
>
> this is quite interesting, and nice detective work.
>
> It would seem like an interesting use case here could be to modify this
> firmware to make it target a standard 1.44MB floppy disk drive.
>
> Maybe it would seem a bit backwards because SD cards are more mainstream,
> but still interesting to think about.
>
>
>
> I see you have the disassembly in place.
>
>
>
>

Re: [M100] molex ic socket

[Brian White]

Sure no problem. We'll work out the details off list.

On Tue, Mar 16, 2021, 6:35 AM Doug Jackson  wrote:

> Hi Brian,
>
> Years ago when I was a trainee, I replaced my Molex socket with a DIP
> machined pin one so I could use it for a project i was working on- I am
> sorely regretting that nowadays.   It excludes me from the REX/CPM
> stull for example.
>
> I would have purchased that set of 10, but they don't ship to Australia -
> so I would have to use my forwarder there at $40 odd  and that get
> stupidly expensive.
>
> Would you be willing to sell me one and put it in a padded envelope for
> shipping down under?
>
> Kindest regards,
>
> Doug Jackson
>
> em: d...@doughq.com
> ph: 0414 986878
>
> Check out my awesome clocks at www.dougswordclocks.com
> Follow my amateur radio adventures at vk1zdj.net
>
>
>
> On Tue, 16 Mar 2021 at 19:42, Brian K. White  wrote:
>
>> There's some new sockets on ebay
>> https://www.ebay.com/itm/153988317907
>>
>> I still have a bunch and will give or sell cheap a few to whoever needs
>> a them for repairs & spares, but still, I figured this should be pointed
>> out.
>>
>> Anyone doing repairs should probably go scoop some up.
>>
>> --
>> bkw
>>
>

Re: [M100] low profile pcb pins

[Brian White]

My initial proof of concept test with copper wire, shakey start but I think
it will work. I think in the end it will merely be an equivalent option,
not necessarily a slam dunk killer most practical option, unless you can
source the wire cheaper.

I tried to film the process but all I got was 12 minutes of the back of my
hand. ;)

The wire I'm testing with is thicker than the wire I intend to use for
real, and the pcb I'm testing with was not designed specifically for this,
it was designed for TE Connectivity leadframes or millmax/keystone micro
pins. So a couple of the holes were tight and the wire was hard to push
through. Obviously that's just a matter of getting the sizes right for the
holes and the wire, not a problem with the concept.

Next problem was 4 out of 28 pins soldered themselves into the socket. That
IS a fundamental problem with the concept, but maybe addressable by just
throwing a piece of painters tape across the bottom of the board, and punch
the wires through the tape. Or use a lot less flux. Or be more consistent
with heat time. Or all of the above. This was bare copper wire too, and
maybe gold won't wick quite as aggressively as bare copper. Maybe no extra
flux, just rely on what's inside the solder?

Practicality? All in all, it took several minutes to insert & cut the pins
and then solder them, but this was the first attempt. I'm sure it will get
quite a bit quicker even the 2nd time. I had to stop and figure things out
several times, like the tight holes, and I didn't cut a long enough length
of wire and ran out 3/4 of tye way through, and I had to work out a good
way to grip the wire to push down into the socket. Even with all that it
wasn't too bad and I can see how a lot of that was just first-time-bumbling.

The basic process of poke the wire in with one hand and flush-cut with the
other actually went about as easily as I imagined. I did the corner pins
first and that was enough to hold the pcb in place so I didn't even have to
rig up some way to hold the pcb down. I had a round pins socket in a large
breadboard to make a stable base to hold the socket.

However if the cost of the wire is going to work out to just over 6 cents
per pin (buying in short 5ft lengths from ebay or amazon in the US) then
the idea isn't much of an advantage over just buying the fancy mill-max
pins at 10 cents per pin. And the TE leadframes are only 3 cents per pin.
The time to assemble & solder the mill-max pins is about the same or less
than the wire even assuming some practice working out a good procedure for
doing the wire.

I have some wire from different sources coming in that I'll just have to
see if they work when they arrive. Some are much cheaper than others yet
still claim to be real gold on half-hard brass or half-hard copper, in 26
and 24 gauge, so, as long as that description turns out to be true, then
you can get much lower than 3 cents per pin and the idea is worth doing.
Maybe it's even worth it at 6 cents just because all else being equal, it's
better not to depend on some special manufactured product (just look at the
option rom socket for a lesson on why). Gold plated brass wire is a little
uncommon, but it's still just wire.

-- 
bkw

On Sun, Feb 28, 2021, 7:01 AM Brian K. White  wrote:

> On 2/28/21 2:43 AM, Brian K. White wrote:
> >
> >> https://www.amazon.com/dp/B07S9JFK2V gold plated brass, 300ft, $14
> >> or
> >> https://www.amazon.com/dp/B07H9RBTPF   gold plated copper, 60ft, $5
> >
> > It's actually kind of hard to tell for sure what many of the Amazon
> > links are really made of. But this Aliexpress item at least explicitly
> > says copper wire and real gold plating.
> > https://www.aliexpress.com/item/1005002047296739.html
> >
> > I think brass would be a little better but maybe copper is strong enough.
>
> Found some gold on brass half-hard. 26 and 24 awg. Much more gold than
> necessary, and costs more, but it's available in a few days.
> $16 for 5ft = 254 legs = $0.063/leg. Not that much better than the fancy
> machined Mill-Max or Keystone ones.
> https://www.ebay.com/itm/273191001282
>
> There's others like that. Looks like the ones with varnish usually say
> so somewhere, or they say "tarnish resistant".
>
> --
> bkw
>
>

Re: [M100] low profile pcb pins

[Brian White]

Not just difficult. You can always jam them in, at least into leaf style
sockets.

The real problem is it's bad for the socket and that is an unconscionable
thing to do to unwitting users.



On Fri, Feb 26, 2021, 1:52 PM Greg Swallow  wrote:

> Steve,
>
> I can agree on the square pins being difficult to fit. Have a packe of
> some 1x40 I never used because of it.
>
> God Bless,
>
> GregS <><
>
> Feb 26, 2021 11:42:40 AM Stephen Adolph :
>
> thanks for the suggestion Jeff.  Those look like square pins right? I
> don't think those will engage nicely with the typical DIL socket you would
> see used with an IC though.
> Am I wrong?  Ive tried to stuff those pins into sockets before and... it
> doesn't seem right to do that.
>
> Steve
>
> On Fri, Feb 26, 2021 at 1:37 PM Jeffrey Birt 
> wrote:
>
>> For the MOS8701/HB I produce I use the long tail stackable headers
>> commonly used for Arduinos. You want the type that has a rectangular but
>> not square profile with the thin side less than 0.5mm. These work well in
>> normal leaf sockets and seem to work well in machine pin sockets as well.
>>
>>
>>
>> The trick is you need a fixture to solder them. For example, if you set
>> your PCB down on a breadboard and push the headers through you can top
>> solder and trim the excess away. The plastic part of the header is only
>> serving as a carrier to hold the pins in place in this case.
>>
>> Jeff Birt
>>
>>
>>
>>
>>
>> *From:* M100  *On Behalf Of *B4 Me100
>> *Sent:* Friday, February 26, 2021 10:27 AM
>> *To:* m...@bitchin100.com
>> *Subject:* Re: [M100] low profile pcb pins
>>
>>
>>
>> I have used the following two strips with the M100 SysBus socket for
>> quite a few projects - not sure it is the same format as the NEC socket.
>> The strips are very low profile which means the modules easily clear the
>> cover, even with tall components on the top side.  But they are expensive
>> which is OK for one or two modules but perhaps not for mass production.
>>
>>
>>
>> Samtec TS-120-T-A  20 pins = $2.83
>>
>>
>> https://www.digikey.com/en/products/detail/TS-120-T-A/SAM1112-20-ND/1105474?itemSeq=356013488
>>
>>
>>
>> Mill-Max Manufacturing Corp. 335-40-120-00-16 20pins = $6.83
>>
>>
>> https://www.digikey.com/en/products/detail/335-40-120-00-16/ED5932-20-ND/4455921?itemSeq=356013724
>>
>>
>>
>>
>>
>

Re: [M100] low profile pcb pins

[Brian White]

At least some are rectangular. I think they're still a bit thick but maybe
thin enough not to abuse the socket too bad.

With the leadframes, there are 2 potentially fiddly/random that can be made
nice and repeatable and practical by just procedure or technique.

I start with the leadframes by cutting the "busy" end off with scissors,
leaving a simple comb.

I hold the busy side in my left hand while cutting with my right, so I can
see both the shoulders where the pins widen and the scissor blade at the
same time. I just keep the scissors aimed about 2 mm away from the
shoulders as I go. The end result is good enough. The pins only need to be
roughly the same length. A little freehand wandering along the right line
doesn't hurt.

Or if you want you can make up some kind of jig like just cut a slot in a
piece of wood, drop the frame in, score the pins with a knife or flush cut
or draw a line with a fine tip sharpie. That would still be pretty simple
but I don't think even that much is necessary.

Either way, now you have a simple "comb" and it didn't take all day.

The next fiddly part is setting the depth of how far to put the comb into
the pcb to get legs that aren't too long or too short or slanted at an
angle, without having to trim them after soldering.

Probably the simplest way is just use a socket or a breadboard under the
pcb and just push the pins in untill they stop. Doing this, you have to be
careful the solder doesn't run down the leg and solder itself to the
socket. The tin leadframe legs rly love solder and it wets right down
the whole length easily.

Another way might be to stick a couple of objects like toothpicks or
something in between leadframe pins on top of the pcb, which stops the
frame from going all the way down.

Solder. Then flush-cut away the top frame.

Done.

There's a few things I like about Bert's idea.

The pins are already cut perfectly neatly on the free end.

And the pins are just normal gold plated and the solder won't instantly wet
itself down the whole pin. It will pretty much just stay where you put it.
That means there's no problem using a socket as a jig to set the depth and
hold the pins while soldering.

I also like that the end result is a gold plated pin instead of tin.

But I don't like the thickness of the pins, but maybe I need to take
another look, maybe it's no worse than machined round pins.

The more I think about it, the more I like Bert's idea.

-- 
bkw

On Fri, Feb 26, 2021, 1:45 PM Stephen Adolph  wrote:

> thanks for the suggestion Jeff.  Those look like square pins right? I
> don't think those will engage nicely with the typical DIL socket you would
> see used with an IC though.
> Am I wrong?  Ive tried to stuff those pins into sockets before and... it
> doesn't seem right to do that.
>
> Steve
>
> On Fri, Feb 26, 2021 at 1:37 PM Jeffrey Birt 
> wrote:
>
>> For the MOS8701/HB I produce I use the long tail stackable headers
>> commonly used for Arduinos. You want the type that has a rectangular but
>> not square profile with the thin side less than 0.5mm. These work well in
>> normal leaf sockets and seem to work well in machine pin sockets as well.
>>
>>
>>
>> The trick is you need a fixture to solder them. For example, if you set
>> your PCB down on a breadboard and push the headers through you can top
>> solder and trim the excess away. The plastic part of the header is only
>> serving as a carrier to hold the pins in place in this case.
>>
>> Jeff Birt
>>
>>
>>
>>
>>
>> *From:* M100  *On Behalf Of *B4 Me100
>> *Sent:* Friday, February 26, 2021 10:27 AM
>> *To:* m...@bitchin100.com
>> *Subject:* Re: [M100] low profile pcb pins
>>
>>
>>
>> I have used the following two strips with the M100 SysBus socket for
>> quite a few projects - not sure it is the same format as the NEC socket.
>> The strips are very low profile which means the modules easily clear the
>> cover, even with tall components on the top side.  But they are expensive
>> which is OK for one or two modules but perhaps not for mass production.
>>
>>
>>
>> Samtec TS-120-T-A  20 pins = $2.83
>>
>>
>> https://www.digikey.com/en/products/detail/TS-120-T-A/SAM1112-20-ND/1105474?itemSeq=356013488
>>
>>
>>
>> Mill-Max Manufacturing Corp. 335-40-120-00-16 20pins = $6.83
>>
>>
>> https://www.digikey.com/en/products/detail/335-40-120-00-16/ED5932-20-ND/4455921?itemSeq=356013724
>>
>>
>>
>>
>>
>

Re: [M100] Serial-to-WiFi Converters and Rechargeable Batteries

[Brian White]

I said the modem is the telnet client.

Telnet is a tcp/ip protocol and there is no such thing as tcp/ip on a 100.
No networking hardware and not enough cpu or ram to do anything useful if
there were such a thing as a network card.

The modem has it's own cpu and ram and tcp/ip stack software, and the
computer just talks plain serial tty to it, just like ordinary phone modems.

If you mean is there a better terminal emulator, there might be. For
starters at least there is a whole directory devoted to telcom apps in the
M100SIG archive, including some apps that seem to be vt52 and vt100
emulators, and some archived discussion threads about them. I haven't gone
through it all to see what's what.
https://archive.org/details/M100SIG
There seems to be at least one vt100 emulator app on club100
http://club100.org/library/libtel.html

A terminal or terminal emulator is a separate thing from a telnet or ssh
client. They are often bundled together in typical windows or mac apps, but
really the telnet part is a separate job from the terminal emulator part.

So in this case, the modem does the physical network connection (the wifi)
and the tcp/ip and telnet protocol, and provides a plain tty interface on a
serial port. And the computer only needs a terminal app to read text from
the serial port and display on the screen, and read text from the keyboard
and send to the serial port. There is no ethernet or tcp/ip or telnet
knowledge or code in the computer, that's all in the modem. The computer
only needs a serial comm program just like with any other modem.

The built-in telcom app is very basic and does not emulate ansi or vt100,
so you could do with a better terminal app if there is one. Especially if
there is one that can work with the Disk/Video Interface to use a full
80x25 screen.

But the built-in telcom app does the basic job.

-- 
bkw

On Sun, Feb 21, 2021, 4:03 PM Jeff Gonzales  wrote:

> So would you still use the built-in terminal or is there an actual telnet
> client available for the m100 now?
>
> On Sun, Feb 21, 2021 at 1:58 PM Brian K. White 
> wrote:
>
>> On 2/20/21 5:22 PM, Jeff Gonzales wrote:
>> > How do you connect to remote BBS' with this?  I have only done it with
>> > telnet on a computer.  How do AT commands work on wifi?  Does the
>> > device have a SIM card and, of so, are the remote BBS' still using
>> > modems??
>>
>> The remote side is a telnet server running bbs software. You can telnet
>> to it using any telnet client.
>>
>> On the client side, the device connects to wifi, not the cell network,
>> so no sim card.
>>
>> And the device is essentially a telnet client, meaning the device does
>> the tcp/ip and the telnet protocol with the telnet server, just like how
>> a regular modem does all the v.42bis handshaking and error correction
>> and compression with the other modem.
>>
>> You control the device with AT commands, both to get connected to wifi
>> and to "dial" some telnet server.
>>
>> How exactly the AT commands work is what the manual is for. You just use
>> them the same as with any other modem. There's commands to list all wifi
>> networks in the area, supply a password to join a network, set static IP
>> settings or dhcp, even to control the led. The ATDT command accepts an
>> ip or hostname and tcp port number like "hostname:port" instead of a
>> phone number.
>> https://www.cbmstuff.com/downloads/wimodem/wimodem232_manual.pdf
>>
>> Every modem ever made had it's own special AT commands for various
>> functions. This is no different.
>>
>> --
>> bkw
>>
>>

Re: [M100] Serial-to-WiFi Converters and Rechargeable Batteries

[Brian White]

Yup you just use TELCOM. Or any terminal app but the built-in telcom is all
you need.

-- 
bkw

On Sun, Feb 21, 2021, 4:03 PM Jeff Gonzales  wrote:

> So would you still use the built-in terminal or is there an actual telnet
> client available for the m100 now?
>
> On Sun, Feb 21, 2021 at 1:58 PM Brian K. White 
> wrote:
>
>> On 2/20/21 5:22 PM, Jeff Gonzales wrote:
>> > How do you connect to remote BBS' with this?  I have only done it with
>> > telnet on a computer.  How do AT commands work on wifi?  Does the
>> > device have a SIM card and, of so, are the remote BBS' still using
>> > modems??
>>
>> The remote side is a telnet server running bbs software. You can telnet
>> to it using any telnet client.
>>
>> On the client side, the device connects to wifi, not the cell network,
>> so no sim card.
>>
>> And the device is essentially a telnet client, meaning the device does
>> the tcp/ip and the telnet protocol with the telnet server, just like how
>> a regular modem does all the v.42bis handshaking and error correction
>> and compression with the other modem.
>>
>> You control the device with AT commands, both to get connected to wifi
>> and to "dial" some telnet server.
>>
>> How exactly the AT commands work is what the manual is for. You just use
>> them the same as with any other modem. There's commands to list all wifi
>> networks in the area, supply a password to join a network, set static IP
>> settings or dhcp, even to control the led. The ATDT command accepts an
>> ip or hostname and tcp port number like "hostname:port" instead of a
>> phone number.
>> https://www.cbmstuff.com/downloads/wimodem/wimodem232_manual.pdf
>>
>> Every modem ever made had it's own special AT commands for various
>> functions. This is no different.
>>
>> --
>> bkw
>>
>>

Re: [M100] Serial-to-WiFi Converters and Rechargeable Batteries

[Brian White]

The post you quoted showed how it's connected, so I don't know what you
mean.

Do you mean how do you connect to your wifi? Or how do you connect to a
remote BBS?

It's all done by AT commands described in the manual like any other modem.

On Sat, Feb 20, 2021, 11:21 AM Jeff Gonzales  wrote:

> How does connectivity work for these devices?
>
> On Tue, Jan 12, 2021 at 1:45 PM Steve Baker 
> wrote:
>
>> Yep, exactly. I ordered two of this 25-pin M:M gender changer (one for my
>> WiModem232 and one for the GuruModem, ‘cos I didn’t want to keep swapping
>> them in and out).
>>
>> https://smile.amazon.com/gp/product/B00066HP5G/
>>
>> Here are photos of both modems connected to my Tandy 102:
>>
>> https://imgur.com/a/e4BppYA
>>
>> (And it looks like I have a firmware update for the WiModem232, per the
>> on-screen message… how fun!)
>>
>> Cheers and thanks,
>> SB
>>
>> --
>> Greetings from Steve Baker
>> “Gravity brings me down…”
>>
>>
>>
>> On Jan 12, 2021, at 1:26 PM, Brian White  wrote:
>>
>> This thing helps with attaching the WiModem232 to a 100/200/NEC
>> https://github.com/bkw777/WiModem_to_100
>> https://photos.app.goo.gl/hjoC3vnfZxWbFPRW6
>>
>> The serial port on 102 is upside down, so you can't use this on 102, but
>> on 102 you can use a generic mini gender-changer.
>> The wimodem232 sticks straight out the back instead of up, but at least
>> the led and/or screen faces up.
>> https://duckduckgo.com/?q=db25+mini+gender+changer+male
>>
>> --
>> bkw
>>
>> On Sat, Jan 9, 2021 at 3:02 PM Steve Baker 
>> wrote:
>>
>>> Fantastic, welcome Jim!
>>>
>>> I’m pretty new around here too, just got my first T102 late-spring and
>>> have been having a blast. This community is nothing short of amazing and I
>>> learn stuff every single day.
>>>
>>> I'd greatly appreciate hearing anyone's experiences with serial-to-WiFi
>>> converters connecting their M100s to networks, and where they've found the
>>> best prices.  Is it simply a matter of using TERM on the M100 set to a
>>> particular bit-rate, number of bits per character, parity, etc., and then
>>> connecting to another computer by specifying the IP address of the
>>> converter via a terminal program on the remote system, such as PuTTY,
>>> HyperTerm, etc.?
>>>
>>>
>>> Regarding Serial-to-WiFi connections, I have both of these (they both
>>> should work on the M100):
>>>
>>> https://www.cbmstuff.com/proddetail.php?prod=WiModem232OLED
>>>
>>> https://www.arcadeshopper.com/wp/store/#!/Gurumodem/p/134166147/category=28313042
>>>
>>> The first is the WiModem232 and the second is the GuruModem. I love them
>>> both in different ways, but usually use WiModem because of the screen (it’s
>>> really fun to use). The GuruModem has a microSD card slot but I haven’t
>>> learned how to receive or send files to/from the onboard storage. When I
>>> figure that out, I might use it a lot more.
>>>
>>> Both of them generally operate the same way, using an expanded Hayes
>>> command set to get out and about. Yep we use Term, set the stat as
>>> appropriate, and then issue the atdt domain.com:port command to connect
>>> (IP addresses work too). Cmds like ati (information), at*b (set baud rate),
>>> ath (hangup), etc. are pretty well documented.
>>>
>>> I've heard that rechargeable batteries can be used in M100s by changing
>>> a resistor inside a unit, but I can't find any details about the value of
>>> the new resistor, which one it is on the PCB, etc.  Also, is the resistor
>>> value dependent on which battery chemistry is involved (NiCd, NiMH, LiH,
>>> LiPoly, LiFePO4, etc.)?
>>>
>>>
>>> Regarding the use of rechargeable batteries, quite honestly I’ve only
>>> used rechargeable batteries since I got my first T102 (OK thus far). This
>>> probably won’t help but someone posted technical bulletins for the Model
>>> 200 on installing a nicad upgrade (I uploaded copies of these to my files
>>> area in Club100); not sure if that’d work for the M100.
>>>
>>> Cheers and have a great weekend,
>>> SB
>>>
>>> --
>>> Greetings from Steve Baker
>>> “Gravity brings me down…”
>>>
>>>
>>>
>>> On Jan 9, 2021, at 1:28 PM, Jim Manley  wrote:
>>>
>>> Hi everyone,
>>>
>>> I just joined the flock and I'm an Orig

Re: [M100] Just checking

[Brian White]

Some known-good low power & extra low power part numbers:
http://tandy.wiki/Model_102_RAM

On Sun, Feb 7, 2021, 9:57 AM Charles Hudson  wrote:

> Model 102 acquired recently has M7 occupied by Hitachi HM6264LP-15 8k
> static RAM IC; M6 is open.  I can add a similar IC to M6 to bring RAM up to
> 32k, correct?  No other special procedure involved?
>
> -CH-
>
> PS:  Mapped!
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-7795354545030129835_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: [M100] mConm v1.81 vs ioGear GBC232A (BT)

[Brian White]

A few things:

1: A bluetooth link will not work for TPDD, or at least not consistently,
because of the unexpected delays in the connection. Kurt does have a
specially modified copy of TS-DOS but I don't know if it actually fully
solves the problem or if it was just an attempt that helps somewhat. At the
very least you need to be using that specific copy of TS-DOS, and even then
maybe it will and maybe it won't be 100%. I don't know if the loader in
mcomm provides that version. Maybe it does, and so maybe you're already
doing this part.

2: "Disk not ready" usually means the 100 is not seeing DSR. Does the BT
device provide the DSR & DTR lines? If not, you need to short DSR to DTR on
the 100 side of the connection.

I would get this working perfectly with a normal serial connection before
even thinking about bluetooth. If you fail to get a regular serial
connection working, the next steps will not be to try BT instead, but to
figure out why the normal serial isn't working. Almost always it's simply
getting the serial wiring correct.

Have you verified the serial port is good in the 100 with a loopback plug?

I can't quite make sense of the last part of your post. It seems like maybe
you're talking about an Android device. No com port found means the app
needs a serial port, and you don't have one plugged in (or the os doesn't
have a driver for it, or there is some setting in the os that must be
switched to enable usb otg devices) . I don't know if mcomm for android
supports using bluetooth directly, but I do know it normally expects to use
a usb-serial adapter connected by an "OTG" cable. If it does support bt
directly, I imagine there must be directions and settings somewhere in the
app to pair the phone with the other device and then select that device in
the app. Again I would start with a usb-serial adapter and a serial cable
and get that working 100% before moving to bluetooth.

For reference, here is an off-the-shelf serial cable (a few actually but
the first one is cheapest) with fully correct wiring to go from a 100 to a
pc com port or a usb-serial adapter, and on the bottom of the page is a few
known-good usb-serial adapters. With those, all doubts have been removed.
The cable is good and the usb-serial is good.

You can get just the serial cable and use that with your old full pc with a
real comm port.

For use with an Android device, get the serial cable, the Sabrent
usb-serial adapter, and a usb OTG cable. I don't have a link for one there
but just go on ebay or amazon and search "otg cable" and get one that has
the right connector for your phone or tablet. Most likely you need
micro-usb, but new devices are now using usb-c so at least those two types
will turn up and you need to watch out to get the kind that fits your
device.

http://tandy.wiki/Model_T_Serial_Cable

-- 
bkw


On Sun, Feb 7, 2021, 10:23 AM Greg Swallow  wrote:

> Kurt,
>
> Updated mComm vs BT.
>
> Have been working on this on my days off F-S-S. Setup a P4 with XP to
> dedicate to M100 task as the MB has serial. Parallel et al.
>
> Have been able to inject TS-DOS via cable with mComm 2.5. It works in that
> I can see files on Disk [F4]. Loading [F1] is not happening. I am able to
> use Term between XP and the M100, but sending a file to the M100 is not
> working using modem, kermit or modem (default).
>
> BT has at least given some new messages. When connecting to the M100 via
> BT and mComm 2.5 TS-DOS gives a “Disk not ready” message after pressing
> Disk [F4]. mComm 1.8.x on the w/ A9 has progressed in that it gets to
> Connection Successful before giving a message of “No Com Ports Found.”
>
> Please let me know and hints or thoughts you might have.
>
> Thanks,
>
> GregS <><
>
> On Jan 2, 2021, at 4:54 PM, Greg Swallow  wrote:
>
> Kurt,
>
> Cool. I've had other apps (Music Folder Player) that had/have issues w/ A9.
>
> Take your time. I was hoping to get more done over the holidays myself. My
> keyboard drawer project got delayed two days. I moved a fan after brushing
> on a second coat of stain and it blew particals on to the surface.
>
> God Bless,
>
> GregS <><
>
> Jan 2, 2021 4:35:11 PM Kurt McCullum :
>
> Greg,
>
> I've been moving into my new home these past few days. Finding a new place
> took far longer than I anticipated. I'll take a look at the Bluetooth
> connection in v1.81 when I find my Retro computer boxes. I suspect that
> your problem has something to do with Android 9 and above not playing nice
> with mComm. Google made some big changes with either version 8 or 9 and I
> may end up having to get a newer Android device to test out my code
> against.
>
> Kurt
>
> On Sat, Jan 2, 2021, at 1:17 PM, Greg Swallow wrote:
>
> All:
>
> Didn't want to get a handful of BlueSMirF Gold boards and put one in each
> of my M100/T102 computers. Picked up this ioGear GBC232A (seller posted it
> on eBay as a GBS301). Anyway, I'm hoping to get it working and connect to
> my motoG6 (Android 9) using mComm.
>
> I've been able to 

Re: [M100] DVI character set

[Brian White]

oh right. I thought you were making a standalone font.

On Thu, Jan 28, 2021, 9:03 PM Tom Wilson  wrote:

> It doesn't matter - all that actually matters is the format the terminal
> firmware expects in the font file. The terminal will decide the aspect
> ratio of the pixels based on the number of columns and rows and the display
> resolution.
>
>
> Tom Wilson
> wilso...@gmail.com
> (619)940-6311
>
>
>
> On Thu, Jan 28, 2021 at 4:34 PM Brian White  wrote:
>
>> The rom bit patterns are only 1/2 the story. The other half is the shape
>> of a pixel, which probably isn't square.
>>
>> On Thu, Jan 28, 2021, 4:53 PM Jim Anderson  wrote:
>>
>>> > -Original Message-
>>> > If you're going to do that much, then I will grab some more pics with a
>>> > better camera and a tripod so my hand isn't moving, and manual focus.
>>> > Maybe even a good straight-on centered shot without glare from the room
>>> > lights. Maybe with manual controls I can get a shot in the dark without
>>> > the text blooming.
>>>
>>> You know what, I realize that I went straight to that screen photo image
>>> because I was looking for a clear image that had my XX pattern in
>>> 80-column mode... and it's really not so blurry, but the capture in
>>> "Snapshot_20210127_233755.jpg" is sharper and does have the full character
>>> set showing.  Even though they're flanked by square brackets I think I can
>>> work with it.  (the square brackets don't go to the full left and right
>>> extent of the character cell, that's why I used X.)  Don't worry about
>>> going to any trouble for a sharper screen photo.  For my cleanup/rescaling
>>> of the original font I've been working off a handheld iphone photo of my
>>> monitor.
>>>
>>> I also whipped something up to display the ROM data as large block
>>> pixels for an absolute reference to the original intended shapes so I think
>>> I've got everything I need (except time) :)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> jim
>>>
>>

Re: [M100] DVI character set

[Brian White]

The rom bit patterns are only 1/2 the story. The other half is the shape of
a pixel, which probably isn't square.

On Thu, Jan 28, 2021, 4:53 PM Jim Anderson  wrote:

> > -Original Message-
> > If you're going to do that much, then I will grab some more pics with a
> > better camera and a tripod so my hand isn't moving, and manual focus.
> > Maybe even a good straight-on centered shot without glare from the room
> > lights. Maybe with manual controls I can get a shot in the dark without
> > the text blooming.
>
> You know what, I realize that I went straight to that screen photo image
> because I was looking for a clear image that had my XX pattern in
> 80-column mode... and it's really not so blurry, but the capture in
> "Snapshot_20210127_233755.jpg" is sharper and does have the full character
> set showing.  Even though they're flanked by square brackets I think I can
> work with it.  (the square brackets don't go to the full left and right
> extent of the character cell, that's why I used X.)  Don't worry about
> going to any trouble for a sharper screen photo.  For my cleanup/rescaling
> of the original font I've been working off a handheld iphone photo of my
> monitor.
>
> I also whipped something up to display the ROM data as large block pixels
> for an absolute reference to the original intended shapes so I think I've
> got everything I need (except time) :)
>
>
>
>
>
>
>
> jim
>

Re: [M100] DVI character set

[Brian White]

I've put some snapshots from a video capture device up in the same
directory with the rom dumps.

The image is scaled from composite 4:3 input to 1080p 16:9 hdmi output, but
not stretched. The aspect ratio is preserved.

On Wed, Jan 27, 2021, 4:37 PM Jim Anderson  wrote:

> > -Original Message-
> > Hey DVI owners,
> >
> > Would someone mind doing a bit if information mining?
> >
> > I would love to get the font bitmap for the DVI.  Jim Anderson is
> > working on improvements to MVT100 firmware and it would be cool to copy
> > and use these fonts.
>
> Something which would also be very useful would be a photo of the DVI
> character set as displayed on-screen so I can get a sense of the relative
> size and displayed shape of each character, since the raw bitmap will
> likely need to be modified (at least to fit the proportions of the new
> bitmap).
>
> If it's not too much trouble, a sharp photo of the DVI screen (in WIDTH 80
> mode) displaying the output of the following program would be really
> helpful (just email the photo directly to me as I will want the full
> resolution copy and it'll be at least a few mb).
>
> 10 screen 1,1
> 20 width 80
> 30 for c=32 to 255
> 40 print "X";chr$(c);"X ";
> 50 next c
>
>
>
>
>
>
>
> jim
>