Hi John,

This would be a challenge considering cheap SD card readers are USB and there is nothing to drive USB from the Model T. So to use such a device, a custom board with controller, software, etc. woud need to be developed. This is exactly what NADSBox is, except instead of controlling and SD card through a USB port, it just controls it directly.

The problem I see is that everyone seems to want / expect "cheap". There are plenty of cheap ways to establish connectivity for anyone with the skill and time to develop it. But then you almost always end up with some bare board device connected to your Model T which is not protected or very portable. Plus this approach doesn't work for the non-technical members on the list.

If it made financial sense, I might consider making another run of NADSBoxes, but it just doesn't. With all the setup costs with machining the enclosures, PCB fab NRE, etc., plus component costs, my up-front cash expenditure the last time was $12,000, and that was before selling a single NADSBox. Sadly, while there is demand for additional NADSBoxes, there doesn't seem to be *enough* demand to even cover the expense of building them.

Ken

On 11/26/15 4:02 PM, John Martin wrote:
Hiraghm,

Please keep me posted. I did find mu old Radio Shack CCR-82 cassette player / recorder and it cables to plug into the M100. But I have to look for documentation on how to save and load files to and from cassette player / recorder that is plugged into my TRS 80 Mode M100.

It would be nice if some one can invent a SD card reader / writer that can be used with the Model 100. SD cards arr cheap now days and so are the readers / writers.

I have not used this cassette unit since the early 1990's

John M

Message: 5
Date: Thu, 26 Nov 2015 10:33:47 -0600
From: Hiraghm <[email protected] <mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Subject: Re: [M100] Is it possible to use a USB flash drive with a
        Model 100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; format=flowed

I'm still working on getting my Android devices to talk to my M100 via
the BlueM module.
They talk, but I'm working on creating a service and a broadcaster which
would allow one to use the M100 as a keyboard for the Android device.

I want to learn to implement the TPDD protocol, but it doesn't look
easy. Once I do that, my ambition is still to be able to connect to your
phone via the BlueM and use it for storage w/o even taking the phone out
of your pocket (a variation on "cloud" computing...)

I'm also hoping to allow Android devices to "share" their internet
connection with the M100 as a kind of filtering proxy.
I'd love to use my M100 for twitter messages (which are limited to 140
chars, anyway). An idea I thought would be cool would be if, when
viewing a tweet with an attached image, the text would appear on the
M100s screen, and the image on the Android device's screen. Or a link
would take you to a website on the Android device while still
reading/writing tweets on the M100.

I've also got SMAUG MUD sitting on my desktop. I've been toying with the
idea of running a SMAUG-based MUD, maybe writing a custom mud client for
the M100, and maybe a graphical mud client for DOS/Win/Android/etc
Dunno if possible, but it'd be nice to be able to flow seamlessly from
using one device to using another.
The M100 client could even be semi-graphical, I think.

I still wonder what could be done with the M100 via the expansion port.
I read somewhere recently that the expansion port allows for direct
access to memory. It made me wonder if someone clever could come up with
a memory management device (small, of course) plugged into the expansion
port, allowing it to semi-automatically bank-switch the memory in a
Quad, effectively expanding the "ram" of the M100 to 128k. Or,
theoretically, using a swap file system like DOS, have virtual ram as
large as your storage allows. I confess I've almost no technical
expertise, so this could be a laughable idea. To be backwards
compatible, it'd have to be able to, on the fly, change the absolute
addressing into some kind of relative addressing and back again. Of
course, then, with DMA, it could serve not just as a MMU, but
math-coprocessor, GPU, etc, since almost any such device would be
faster/more powerful than the M100's 8085...

It's interesting, I always thought the slow screen refresh would be the
most frustrating limitation on my M100, but I'm finding that it's the
limited RAM that's more frustrating.



Reply via email to