Re: [M100] No otg on new phone

[Mike Stein]

My old Moto Android phone (if I ever find it again) is too old for OTG but I 
finally broke down last week and bought a cheap tablet (two in fact) so 
although it's not high on my list maybe one of these days I'll see what all the 
fuss is about ;-)

m
  - Original Message - 
  From: Willard Goosey 
  To: Model 100 List 
  Sent: Wednesday, March 23, 2016 3:24 PM
  Subject: [M100] No otg on new phone


  Someday I will learn to do my research... Got a new Android phone last week 
and can now confirm the Samsung Galaxy Grand Prime does not have USB-OTG 
support. No mComm over usb on this phone :-(


  Maybe time for me to spring for bluem...


  Willard
  Sent from Samsung tablet

[M100] No otg on new phone

[Willard Goosey]

Someday I will learn to do my research... Got a new Android phone last week and 
can now confirm the Samsung Galaxy Grand Prime does not have USB-OTG support. 
No mComm over usb on this phone :-(

Maybe time for me to spring for bluem...

Willard
Sent from Samsung tablet

Re: [M100] Mcomm 1.2

[Kurt McCullum]

Thanks Steve,

I have tested it quite a bit and it seems to work fine as long as the 
TS-DOS delays are in place. It's definitely slower than a cable though.


Kurt

On 3/23/2016 11:21 AM, Stephen Adolph wrote:

Kurt,
I recently got a new android phone, running 4.4.2  I believe.
I should be able to now test MCOMM with BLUEM.
will try it out soon.
Steve


On Wed, Mar 9, 2016 at 4:07 PM, Kurt McCullum  wrote:

Sort of. The H register delay in the original source is 20 which according
to Ken gives a 3ms delay. I've had to set it between 80 or 90 which is a
little over 4 times that delay. When I transfer a 6k file through the serial
port it takes between 6 and 7 seconds. Over Bluetooth its just over 9
seconds. So it is definitely slower but surprisingly reliable. I have not
found the best delay value yet so I'm still trying to get as much speed as I
can out of it.

That's a good tip about tweaking the adapter itself. I may be able to reduce
the packet size.

It's the small packets back and forth on the directory listing that really
show the delay. And if you have two pages worth of files it's painful.


Kurt


Interesting. So increasing packet size wouldn't help because the directory
enumeration would still be small messages.

We could design an extension where multiple directory entries are packed
into a single response.

Barring that I suspect Bluetooth is buffering small packets to make larger
messages. The directory traversal message is very short so the Bluetooth
device may be waiting to see if we're going to send any more so it can build
up a larger packet. We're not so we end up incurring that batching wait
every time.

That might be configurable in the Bluetooth device so that it will wait
less time to batch a message.  Assuming that's what's happening

-- John.

Re: [M100] Mcomm 1.2

[Stephen Adolph]

Kurt,
I recently got a new android phone, running 4.4.2  I believe.
I should be able to now test MCOMM with BLUEM.
will try it out soon.
Steve


On Wed, Mar 9, 2016 at 4:07 PM, Kurt McCullum  wrote:
> Sort of. The H register delay in the original source is 20 which according
> to Ken gives a 3ms delay. I've had to set it between 80 or 90 which is a
> little over 4 times that delay. When I transfer a 6k file through the serial
> port it takes between 6 and 7 seconds. Over Bluetooth its just over 9
> seconds. So it is definitely slower but surprisingly reliable. I have not
> found the best delay value yet so I'm still trying to get as much speed as I
> can out of it.
>
> That's a good tip about tweaking the adapter itself. I may be able to reduce
> the packet size.
>
> It's the small packets back and forth on the directory listing that really
> show the delay. And if you have two pages worth of files it's painful.
>
>
> Kurt
>>
>>
>> Interesting. So increasing packet size wouldn't help because the directory
>> enumeration would still be small messages.
>>
>> We could design an extension where multiple directory entries are packed
>> into a single response.
>>
>> Barring that I suspect Bluetooth is buffering small packets to make larger
>> messages. The directory traversal message is very short so the Bluetooth
>> device may be waiting to see if we're going to send any more so it can build
>> up a larger packet. We're not so we end up incurring that batching wait
>> every time.
>>
>> That might be configurable in the Bluetooth device so that it will wait
>> less time to batch a message.  Assuming that's what's happening
>>
>> -- John.
>>
>>
>

[M100] Is there a NADSbox alternative

[Duane Adrian]

 As an owner of a TRS 80 Model 100. Is there another alternative than using a 
NADSBox.
I am sure there can be another alternative in storing files, besides floppy 
disk and tape media.
Any suggestions. Alot of Model 100 users do not have the MONEY to buy the 
NADSBox. Plus it is hard to get one if someone needs to get one. 

Ken is a regular of this list, but has busy periods and life intrusions like 
the rest of us.

 I think the NADS run has completed, and it was deemed uneconomical to make 
another run.  Probably best to consult the list archive for that reasonably 
recent discussion.

Re: [M100] Question about TS-DOS/Desklink loaded files corrupted

[Joseph Remy]

USB Serial to null modem to db9-db25 adapter.

Wow, I feel kind of silly not even thinking about the emulator.  I'm a
SysAdmin of many years for Doc McCoy's Sake!

~Joe


On Tue, Mar 22, 2016 at 5:04 PM, John R. Hogerhuis  wrote:
>
>
> On Tue, Mar 22, 2016 at 1:28 PM, Mike Stein  wrote:
>>
>>
>>
>> BTW, it is sometimes necessary to rename the file itself, e.g. when there
>> already is a .DO file containing documentation; another issue is different
>> versions named .100 and .200 for the respective models.
>
>
> Good point.
>
> -- John.