Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

" LaddieAlpha in RequestReadBlock() looks like it would just send back a
0x10 0x00  response, but command.tdd notes the read should send an
EOF error if the file is finished."

Oh, you're talking about eof error, missed that.

Actually that sounds familiar. I'm pretty sure that I fixed a read-past-end
issue in my unreleased version. I think that was a bug I fixed while
working on getting STARDISK to work (NEC 8401A/8500). STARDISK was reading
past the end.

-- John.



On Wed, Sep 16, 2020 at 11:07 AM RETRO Innovations 
wrote:

> On 9/16/2020 2:43 AM, John R. Hogerhuis wrote:
>
>
>
> EOF character is ctrl-z. 0x1A
>
> "whereas LaddieAlpha and dlplus don't seem to
> support sending EOF on a read"
>
> I don't know what you mean by that. TPDD protocol is binary protocol. 0x1A
> characters are sent turning tx and rx, but it generally doesn't mean "EOF"
> it's just binary file content or binary packet content.
>
> I meant:
>
> "..LaddieAlpha and dlplus don't seem to  support sending an ERR_EOF on a
> read request that attempts to read past the end of the file."
>
> LaddieAlpha in RequestReadBlock() looks like it would just send back a
> 0x10 0x00  response, but command.tdd notes the read should send an
> EOF error if the file is finished.
>
> Jim
>
>
>

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/16/2020 2:43 AM, John R. Hogerhuis wrote:



EOF character is ctrl-z. 0x1A

"whereas LaddieAlpha and dlplus don't seem to
support sending EOF on a read"

I don't know what you mean by that. TPDD protocol is binary protocol. 
0x1A characters are sent turning tx and rx, but it generally doesn't 
mean "EOF" it's just binary file content or binary packet content.


I meant:

"..LaddieAlpha and dlplus don't seem to support sending an ERR_EOF on a 
read request that attempts to read past the end of the file."


LaddieAlpha in RequestReadBlock() looks like it would just send back a 
0x10 0x00  response, but command.tdd notes the read should send 
an EOF error if the file is finished.


Jim

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

Sorry, not "turning", meant "during."

On Wed, Sep 16, 2020 at 12:43 AM John R. Hogerhuis  wrote:

>
>
> On Tue, Sep 15, 2020 at 11:42 PM RETRO Innovations 
> wrote:
>
>> On 9/15/2020 12:38 AM, Brian K. White wrote:
>> > http://www.club100.org/library/libref.html
>>
>> Linked off this page: command.tdd, seems to have errors, but I'm not sure:
>>
>> https://ftp.whtech.com/club100/ref/comand.tdd
>>
>> It claims EOF is 0x30 (48), whereas LaddieAlpha and dlplus don't seem to
>> support sending EOF on a read, and the
>>
>> http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol
>>
>> wiki page has 0x3f for EOF.
>>
>> Jim
>>
>>
> EOF character is ctrl-z. 0x1A
>
> "whereas LaddieAlpha and dlplus don't seem to
> support sending EOF on a read"
>
> I don't know what you mean by that. TPDD protocol is binary protocol. 0x1A
> characters are sent turning tx and rx, but it generally doesn't mean "EOF"
> it's just binary file content or binary packet content.
>
> -- John.
>

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

On Tue, Sep 15, 2020 at 11:42 PM RETRO Innovations 
wrote:

> On 9/15/2020 12:38 AM, Brian K. White wrote:
> > http://www.club100.org/library/libref.html
>
> Linked off this page: command.tdd, seems to have errors, but I'm not sure:
>
> https://ftp.whtech.com/club100/ref/comand.tdd
>
> It claims EOF is 0x30 (48), whereas LaddieAlpha and dlplus don't seem to
> support sending EOF on a read, and the
>
> http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol
>
> wiki page has 0x3f for EOF.
>
> Jim
>
>
EOF character is ctrl-z. 0x1A

"whereas LaddieAlpha and dlplus don't seem to
support sending EOF on a read"

I don't know what you mean by that. TPDD protocol is binary protocol. 0x1A
characters are sent turning tx and rx, but it generally doesn't mean "EOF"
it's just binary file content or binary packet content.

-- John.

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/14/20 8:32 PM, John R. Hogerhuis wrote:



On Mon, Sep 14, 2020 at 3:47 PM Brian K. White > wrote:



    while(s[j] == 0x00) j--;            // seek from end to non-null
    if(s[j] == '/' && j > 0x00) j--;    // seek past trailing slash
    z = j;                              // mark end of name
    while(s[j] != '/' && j > 0x00) j--; // seek to next slash


Yipes, yeah... cowboy might want to keep an eye on 'j'.

-- John.



You're right about the bounds checking but I thought the main problem 
might be that it's only looking for '/' and not looking also for '\'.


Looks like I just copied that bit from Jimmy.

https://github.com/TangentDelta/SD2TPDD/blob/master/SD2TPDD.ino

--
void upDirectory(){ //Removes the top-most entry in the directoy path
  int j = sizeof(directory);

  while(directory[j] == 0x00){ //Jump to first non-null character
j--;
  }

  if(directory[j] == '/' && j!= 0x00){  //Strip away the slash character
directory[j] = 0x00;
  }

  while(directory[j] != '/'){ //Move towards the front of the array 
until a slash character is encountered...
directory[j--] = 0x00;  //...set everything along the way to null 
characters

  }
}
--

--
bkw

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/15/2020 12:38 AM, Brian K. White wrote:

http://www.club100.org/library/libref.html


Linked off this page: command.tdd, seems to have errors, but I'm not sure:

https://ftp.whtech.com/club100/ref/comand.tdd

It claims EOF is 0x30 (48), whereas LaddieAlpha and dlplus don't seem to 
support sending EOF on a read, and the


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

wiki page has 0x3f for EOF.

Jim

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/15/2020 12:38 AM, Brian K. White wrote:

On 9/15/20 1:18 AM, RETRO Innovations wrote:

All:

Is there a reference somewhere that describes the TPDD protocol is a 
bit more detail?


Several. Just for the main starters:
http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol
http://bitchin100.com/wiki/index.php?title=TPDD
http://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes
http://www.club100.org/library/libref.html
Well, that's just embarrassing.  I should have googled first. Abject 
apologies...


And the other better emulator implementations also serve as a reference:

http://bitchin100.com/pub-git/laddiealpha.git/

http://www.club100.org/memfiles/index.php?&direction=0&order=&directory=Kurt%20McCullum/mComm%20Python 



https://github.com/bkw777/dlplus

http://bitchin100.com/files/linux/dlplus.zip  (dlplus before my 
questionable hacks)



Thanks.  I'm looking at them now.

I noticed all of them maintain a "system state", so adding that in now 
(no read of a file before opening, and the like).


Jim



--
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

Re: [M100] WTB: NASDBox

[Joshua O'Keefe]

On Sep 14, 2020, at 10:18 PM, RETRO Innovations  wrote:
> Is there a reference somewhere that describes the TPDD protocol is a bit more 
> detail?

I had pretty good luck with the original manual:  
https://archive.org/details/tandyportablediskdriveservicemanual263808stext

My understanding is that some clients do things outside the specification in 
the manual, but the manual is a fair place to start.

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

On Mon, Sep 14, 2020 at 10:18 PM RETRO Innovations 
wrote:

> All:
>
> Is there a reference somewhere that describes the TPDD protocol is a bit
> more detail?
>
>
Look in Bitchin100.com/wiki there's a lot of info but it's not all one page.

Also a good reference is the source for LaddieAlpha and DLPlus.


> I see references to DME Request in the code, is there a reference or
> link to learn more about that?
>

Those are well documented

http://bitchin100.com/wiki/index.php?title=Desklink/TS-DOS_Directory_Access


>
> Also, does the Model T BASIC support the TPDD at all?
>
>
Nope. Unless you have TS-DOS installed which has BASIC extensions.

-- John.

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/15/20 1:18 AM, RETRO Innovations wrote:

All:

Is there a reference somewhere that describes the TPDD protocol is a bit 
more detail?


Several. Just for the main starters:
http://bitchin100.com/wiki/index.php?title=TPDD_Base_Protocol
http://bitchin100.com/wiki/index.php?title=TPDD
http://bitchin100.com/wiki/index.php?title=TPDD_Design_Notes
http://www.club100.org/library/libref.html

And the other better emulator implementations also serve as a reference:

http://bitchin100.com/pub-git/laddiealpha.git/

http://www.club100.org/memfiles/index.php?&direction=0&order=&directory=Kurt%20McCullum/mComm%20Python

https://github.com/bkw777/dlplus

http://bitchin100.com/files/linux/dlplus.zip  (dlplus before my 
questionable hacks)



I see references to DME Request in the code, is there a reference or 
link to learn more about that?


It's a TS-DOS extension to support subdirectories. A real drive and the 
stock FLOPPY dos that came with it don't know anything about directories.



Also, does the Model T BASIC support the TPDD at all?


--
bkw

Re: [M100] WTB: NASDBox

[RETRO Innovations]

All:

Is there a reference somewhere that describes the TPDD protocol is a bit 
more detail?


I see references to DME Request in the code, is there a reference or 
link to learn more about that?


Also, does the Model T BASIC support the TPDD at all?

JIm

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

On Mon, Sep 14, 2020 at 5:52 PM B 9  wrote:

> Maybe I'm confused, but shouldn't that be s[j] > 0x00?
>
>
j is the index. It actually needs to be checked for underrun 0 in all of
the loops otherwise it can go off into la-la land.

But yeah comparing against 0x00 is misleading, as if it's a character value
and not an array index.

-- John.

Re: [M100] WTB: NASDBox

[B 9]

Oh, never mind, I thought you were traversing the string forward.

On Mon, Sep 14, 2020 at 5:52 PM B 9  wrote:

> Maybe I'm confused, but shouldn't that be s[j] > 0x00?
>
> On Mon, Sep 14, 2020 at 5:31 PM John R. Hogerhuis 
> wrote:
>
>>
>>
>> On Mon, Sep 14, 2020 at 3:47 PM Brian K. White 
>> wrote:
>>
>>>
>>>while(s[j] == 0x00) j--;// seek from end to non-null
>>>if(s[j] == '/' && j > 0x00) j--;// seek past trailing slash
>>>z = j;  // mark end of name
>>>while(s[j] != '/' && j > 0x00) j--; // seek to next slash
>>>
>>>
>> Yipes, yeah... cowboy might want to keep an eye on 'j'.
>>
>> -- John.
>>
>

Re: [M100] WTB: NASDBox

[B 9]

Maybe I'm confused, but shouldn't that be s[j] > 0x00?

On Mon, Sep 14, 2020 at 5:31 PM John R. Hogerhuis  wrote:

>
>
> On Mon, Sep 14, 2020 at 3:47 PM Brian K. White 
> wrote:
>
>>
>>while(s[j] == 0x00) j--;// seek from end to non-null
>>if(s[j] == '/' && j > 0x00) j--;// seek past trailing slash
>>z = j;  // mark end of name
>>while(s[j] != '/' && j > 0x00) j--; // seek to next slash
>>
>>
> Yipes, yeah... cowboy might want to keep an eye on 'j'.
>
> -- John.
>

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

On Mon, Sep 14, 2020 at 3:47 PM Brian K. White  wrote:

>
>while(s[j] == 0x00) j--;// seek from end to non-null
>if(s[j] == '/' && j > 0x00) j--;// seek past trailing slash
>z = j;  // mark end of name
>while(s[j] != '/' && j > 0x00) j--; // seek to next slash
>
>
Yipes, yeah... cowboy might want to keep an eye on 'j'.

-- John.

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/14/20 2:57 PM, RETRO Innovations wrote:

On 9/14/2020 1:49 AM, Brian White wrote:

You don't need loader.do.
That's OK.  I actually *DID* need it, because I didn't have ts-dos on my 
M100.  I also apologize, as it was right in the instructions. I was in a 
hurry to get going, and didn't read till the end :-)


Reboot normally just results in proceeding to the normal tpdd 
emulation main loop.
Since I replied to Brian off-list, I found that the issue was a long 
hidden directory name "System Volume Information" that Windows sticks on 
all removable media (you can delete, but Windows just adds it back next 
time you put in the card).  To address, I modified the code to not scan 
or send to the client any hidden files are directories.



For the platform selection,
I scrounged through all the board.txt and platform.txt files in the 
arduino IDE installation and found suitable IDE-supplied macros to 
detect at least the handful of boards currently specifically 
supported. I haven't pushed that yet because I'm still testing, but 
it's now detecting the platform at compile-time based on whatever 
board you chose in the IDE.


Cool, I hope you commit the changes back to the repo.  I'd like to 
update my repo and then I'd like to maybe ask if you have some more 
goals for the project beyond moving to esp32 and adding in the modem 
stuff.  The code is a bit tough for me to understand at present, so I'm 
considering refactoring some of it and moving some of it to other CPP 
files to make it easier to understand, but I'm also aware that would 
create issues for back porting, so thought I would see where the project 
is going.


Right now, the only issue I found (with the Uno) is that verbose 
debugging via software serial causes the main comms to have issues, 
which leads to ts-dos errors and such.  I think there are solutions, but 
have not dug into it.


Jim


Directories N levels deep and dot-files and long names and spaces and 
lack-of-extensions all work fine for me.


But I just noticed the the crude little loops that eat the filename 
arrays in a couple places... Well you tell me why this works for me on 
linux and not you on windows ;)


  while(s[j] == 0x00) j--;// seek from end to non-null
  if(s[j] == '/' && j > 0x00) j--;// seek past trailing slash
  z = j;  // mark end of name
  while(s[j] != '/' && j > 0x00) j--; // seek to next slash


--
bkw

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/14/20 2:57 PM, RETRO Innovations wrote:

On 9/14/2020 1:49 AM, Brian White wrote:

You don't need loader.do.
That's OK.  I actually *DID* need it, because I didn't have ts-dos on my 
M100.  I also apologize, as it was right in the instructions. I was in a 
hurry to get going, and didn't read till the end :-)


Reboot normally just results in proceeding to the normal tpdd 
emulation main loop.
Since I replied to Brian off-list, I found that the issue was a long 
hidden directory name "System Volume Information" that Windows sticks on 
all removable media (you can delete, but Windows just adds it back next 
time you put in the card).  To address, I modified the code to not scan 
or send to the client any hidden files are directories.



For the platform selection,
I scrounged through all the board.txt and platform.txt files in the 
arduino IDE installation and found suitable IDE-supplied macros to 
detect at least the handful of boards currently specifically 
supported. I haven't pushed that yet because I'm still testing, but 
it's now detecting the platform at compile-time based on whatever 
board you chose in the IDE.


Cool, I hope you commit the changes back to the repo.


Just pushed it.


  I'd like to
update my repo and then I'd like to maybe ask if you have some more 
goals for the project beyond moving to esp32 and adding in the modem 
stuff.  The code is a bit tough for me to understand at present, so I'm 
considering refactoring some of it and moving some of it to other CPP 
files to make it easier to understand, but I'm also aware that would 
create issues for back porting, so thought I would see where the project 
is going.


By all means. My copy has already done the same thing to Jimmy's 
original. I keep meaning to re-do some of the changes in isolation 
without any stylistic junk edits and not-strictly-needed refactoring to 
make sensible PR's to submit back to SD2TPDD, but instead I just keep 
changing it even more.


--
bkw

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/14/2020 1:49 AM, Brian White wrote:

You don't need loader.do.
That's OK.  I actually *DID* need it, because I didn't have ts-dos on my 
M100.  I also apologize, as it was right in the instructions. I was in a 
hurry to get going, and didn't read till the end :-)


Reboot normally just results in proceeding to the normal tpdd 
emulation main loop.
Since I replied to Brian off-list, I found that the issue was a long 
hidden directory name "System Volume Information" that Windows sticks on 
all removable media (you can delete, but Windows just adds it back next 
time you put in the card).  To address, I modified the code to not scan 
or send to the client any hidden files are directories.



For the platform selection,
I scrounged through all the board.txt and platform.txt files in the 
arduino IDE installation and found suitable IDE-supplied macros to 
detect at least the handful of boards currently specifically 
supported. I haven't pushed that yet because I'm still testing, but 
it's now detecting the platform at compile-time based on whatever 
board you chose in the IDE.


Cool, I hope you commit the changes back to the repo.  I'd like to 
update my repo and then I'd like to maybe ask if you have some more 
goals for the project beyond moving to esp32 and adding in the modem 
stuff.  The code is a bit tough for me to understand at present, so I'm 
considering refactoring some of it and moving some of it to other CPP 
files to make it easier to understand, but I'm also aware that would 
create issues for back porting, so thought I would see where the project 
is going.


Right now, the only issue I found (with the Uno) is that verbose 
debugging via software serial causes the main comms to have issues, 
which leads to ts-dos errors and such.  I think there are solutions, but 
have not dug into it.


Jim

Re: [M100] WTB: NASDBox

[Brian White]

You don't need loader.do.

I was only explaining how it would affect the timing and maybe create the
symptoms that you saw. If the dsr pin detection decided to invoke
sendLoader(), then sendLoader() would spend the next 20 or 30 seconds
reading the file from sd and writing to serial before rebooting. If the
file isn't there, it just reboots immediately.

Reboot normally just results in proceeding to the normal tpdd emulation
main loop.

To get a loader.do, you take the loader BASIC file for some tpdd client,
and name it LOADER.DO. If you had a NEC PC-8201a and wanted the
bootstrapper to install TS-DOS, you take the loader for for the NEC version
of TS-DOS and name it LOADER.DO

There are several loaders for different tpdd clients and for different
"Model T"s around in different places like in the M100SIG.zip archive,
club100, club100 member directories, web8201.net, etc.

I have collected all the ones I could find in https://github/bkw777/dlplus
in the clients directory. There are directions for each loader along side
them too. Normally dlplus displays those directions when those files are
used from dlplus, but they are just text files you can read manually as
well.


For the platform selection,
I scrounged through all the board.txt and platform.txt files in the arduino
IDE installation and found suitable IDE-supplied macros to detect at least
the handful of boards currently specifically supported. I haven't pushed
that yet because I'm still testing, but it's now detecting the platform at
compile-time based on whatever board you chose in the IDE.

-- 
bkw



On Sun, Sep 13, 2020, 2:13 PM RETRO Innovations 
wrote:

> On 9/13/2020 10:06 AM, Brian K. White wrote:
> >
> >
> > Probably we should talk on either your repo or mine, because this will
> > be 100% about Arduino and not at all about M100, until after it works
> > and you start trying to change actual features. But I'll reply at
> > least once here and let everyone else say if it gets too
> > uninteresting/off-topic.
> Well, hopefully, getting the board working is a quick fix, and then we
> can chat about more interesting things, but M100 stuff :-)
> >
> > Sounds like you might be winding up in sendLoader(), which has an
> > explicit reboot at the end. And if you don't have a LOADER.DO file on
> > the sd card, then that reboot will happen immediately. And that will
> > just happen over and over because the condition that got you there
> > won't have changed for the next reboot so it'll just do it again.
> OK, I do not have LOADER.DO on my card.  I guess I need to go find it...
> >
> > I only just last night realized it was going in to sendLoader() if
> > nothing was connected to the DSR pin at boot, which is when I added
> > the pullup on dsr, which fixed it for me. I see you have merged that
> > change, and I assume the uno has the same software-controllable
> > internal pullup feature available on the pin, and so you shouldn't be
> > tripping on that, but, the symptom does match. Maybe you didn't
> > actually test after that change? Or maybe it isn't enough to prevent
> > the behavior on uno, like maybe something else needs to change with
> > the code like maybe my "if (!digitalRead(...));" is backwards on uno
> > or you need to add a physical resistor or ???
> I merged your changes after I sent the message, and then I crashed for
> the night.  I'll test today, though it sounds like I need to find
> LOADER.DO first.  Uno does have pullups on the pins, as the AVR does, so
> all should be fine.
> >
> >
> > Actually I will pull your additions, add those ifdefs, and you can
> > pull that back so it makes a cleaner diff and simpler merge.
> Thanks.
> >
> > I'm currently also trying to get rid of that BOARD macro. I think it
> > can detect the platform automatically from macros set by the IDE like
> > #if defined(ARDUINO_AVR_UNO), etc.
>
> You can look at another Arduino project in my repo for ideas (HEXTIr,
> for example).  I stole an idea from the Commodore sd2iec project and
> created a config.h file that has all the board specific stuff in it.
> THere are two different types of customizations, though.   One if the
> type of board, and the other is the config of the board.  I think you'll
> continue to need the "BOARD" config setting, but you can change it a bit
> by moving all of the board type stuff out of it.  And, yes, on Arduino,
> things like:
>
> #if defined ARDUINO_AVR_UNO || defined ARDUINO_AVR_PRO || defined
> ARDUINO_AVR_NANO
>
> Cna be used to clean up stuff.
>
> >
> >
> >
> > ... and here is when I realized it was probably none of that ;)
>
> I think it's the missing LOADER.DO and the non pulled up DSR pin.
>
> Jim
>
>
> --
> RETRO Innovations, Contemporary Gear for Classic Systems
> www.go4retro.com
> store.go4retro.com
>
>

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/13/2020 10:06 AM, Brian K. White wrote:



Probably we should talk on either your repo or mine, because this will 
be 100% about Arduino and not at all about M100, until after it works 
and you start trying to change actual features. But I'll reply at 
least once here and let everyone else say if it gets too 
uninteresting/off-topic.
Well, hopefully, getting the board working is a quick fix, and then we 
can chat about more interesting things, but M100 stuff :-)


Sounds like you might be winding up in sendLoader(), which has an 
explicit reboot at the end. And if you don't have a LOADER.DO file on 
the sd card, then that reboot will happen immediately. And that will 
just happen over and over because the condition that got you there 
won't have changed for the next reboot so it'll just do it again.

OK, I do not have LOADER.DO on my card.  I guess I need to go find it...


I only just last night realized it was going in to sendLoader() if 
nothing was connected to the DSR pin at boot, which is when I added 
the pullup on dsr, which fixed it for me. I see you have merged that 
change, and I assume the uno has the same software-controllable 
internal pullup feature available on the pin, and so you shouldn't be 
tripping on that, but, the symptom does match. Maybe you didn't 
actually test after that change? Or maybe it isn't enough to prevent 
the behavior on uno, like maybe something else needs to change with 
the code like maybe my "if (!digitalRead(...));" is backwards on uno 
or you need to add a physical resistor or ???
I merged your changes after I sent the message, and then I crashed for 
the night.  I'll test today, though it sounds like I need to find 
LOADER.DO first.  Uno does have pullups on the pins, as the AVR does, so 
all should be fine.



Actually I will pull your additions, add those ifdefs, and you can 
pull that back so it makes a cleaner diff and simpler merge.

Thanks.


I'm currently also trying to get rid of that BOARD macro. I think it 
can detect the platform automatically from macros set by the IDE like 
#if defined(ARDUINO_AVR_UNO), etc.


You can look at another Arduino project in my repo for ideas (HEXTIr, 
for example).  I stole an idea from the Commodore sd2iec project and 
created a config.h file that has all the board specific stuff in it.  
THere are two different types of customizations, though.   One if the 
type of board, and the other is the config of the board.  I think you'll 
continue to need the "BOARD" config setting, but you can change it a bit 
by moving all of the board type stuff out of it.  And, yes, on Arduino, 
things like:


#if defined ARDUINO_AVR_UNO || defined ARDUINO_AVR_PRO || defined 
ARDUINO_AVR_NANO


Cna be used to clean up stuff.





... and here is when I realized it was probably none of that ;)


I think it's the missing LOADER.DO and the non pulled up DSR pin.

Jim


--
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/13/20 2:47 AM, RETRO Innovations wrote:

On 9/12/2020 12:00 AM, Brian K. White wrote:


For uno, or any other board besides Teensy or Feather 32u4 or Feather 
M0, you'd need to edit some #define's at the top.


Set #define BOARD Custom, then a few lines down see the section
#if BOARD == Custom

and edit all the values in that section for your board and your 
wiring, like which pins you hooked up your sdcard reader to etc.


Since UNO and the UNO SD shields are pretty mature, I created a UNO 
section and moved the SS pin to pin 10 (common for UNO shields).  LED 
stayed on 13, but I had to move CONSOLE to a Software Serial and add 
some code into the sketch to init a SoftwareSerial object and include 
the write header file.


Changes are in https://github.com/go4retro/PDDuino

When I start the app, it says it is opening the SD card, and it says OK, 
but then it tries to print the directory and then it just starts over. I 
tried a bunch of cards here.  I got one to work for a bit, but when I 
re-inserted it, it too stopped and went the same behavior as the rest. 
Not sure what I should be looking for.


I'd consider myself pretty advanced for AVR programming, and so-so on 
Arduino, but I thought I'd at least ask before tearing too much into the 
code.


Is there a specific list you'd like these sent to, or posted as issues 
to your repo?


Jim



Probably we should talk on either your repo or mine, because this will 
be 100% about Arduino and not at all about M100, until after it works 
and you start trying to change actual features. But I'll reply at least 
once here and let everyone else say if it gets too uninteresting/off-topic.


Sounds like you might be winding up in sendLoader(), which has an 
explicit reboot at the end. And if you don't have a LOADER.DO file on 
the sd card, then that reboot will happen immediately. And that will 
just happen over and over because the condition that got you there won't 
have changed for the next reboot so it'll just do it again.


I only just last night realized it was going in to sendLoader() if 
nothing was connected to the DSR pin at boot, which is when I added the 
pullup on dsr, which fixed it for me. I see you have merged that change, 
and I assume the uno has the same software-controllable internal pullup 
feature available on the pin, and so you shouldn't be tripping on that, 
but, the symptom does match. Maybe you didn't actually test after that 
change? Or maybe it isn't enough to prevent the behavior on uno, like 
maybe something else needs to change with the code like maybe my "if 
(!digitalRead(...));" is backwards on uno or you need to add a physical 
resistor or ???


Otherwise, easy enough to just ifdef out the whole thing. The DSR & DTR 
setup at the beginning of setup(), the DTR setting and DSR reading at 
the end of setup(), and the entire reset() and sendLoader() functions. 
Then if that fixes the reboot, then it should be simple enough to fix 
that feature for uno. maybe "if(!digitalRead());" is backwards or you 
need a physical pullup resistor or something.


Actually I will pull your additions, add those ifdefs, and you can pull 
that back so it makes a cleaner diff and simpler merge.


I'm currently also trying to get rid of that BOARD macro. I think it can 
detect the platform automatically from macros set by the IDE like #if 
defined(ARDUINO_AVR_UNO), etc.


Next is turn some of those compile-time options into run-time 
configurable via config file on the sd card. Like LOADER_FILE.


Before I realized what was probably happening, I initially looked at 
every platform-specific setting for any possible effects and problems, 
which I'll leave just so you have more leads to follow, but I think the 
problem is above not below.


--

At first glance I would try,
First a copy of the template so we can see right here in the email what 
the options are supposed to do, the names themselves are too generic, IE 
you can't tell from the name of a constant if it turns something on or 
off, or asserts a value you get to choose, or documents a value you 
don't get to choose.



  // User-defined platform details
  #define CONSOLE Serial// where to send debug 
messages, if enabled
  #define CLIENT Serial1// what serial port is the TPDD 
client connected to

  #define DTR_PIN 5 // pin to 
output DTR
  #define DSR_PIN 6 // pin to input 
DSR
  #define SD_CS_PIN 4   // sd card reader chip-select pin #
  //#define SD_CD_PIN 7   // sd card reader card-detect 
pin #

  #define DISABLE_SD_CS 0   // disable CS on SD_CS_PIN pin
  #define USE_SDIO 0// sd card reader communication 
method false = SPI (most boards), true = SDIO (Teensy 3.5/3.6)
  #define ENABLE_SLEEP 1// sleep() while idle for power 
saving
  #define WAKE_PIN 0// CLIENT R

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 9/12/2020 12:00 AM, Brian K. White wrote:


For uno, or any other board besides Teensy or Feather 32u4 or Feather 
M0, you'd need to edit some #define's at the top.


Set #define BOARD Custom, then a few lines down see the section
#if BOARD == Custom

and edit all the values in that section for your board and your 
wiring, like which pins you hooked up your sdcard reader to etc.


Since UNO and the UNO SD shields are pretty mature, I created a UNO 
section and moved the SS pin to pin 10 (common for UNO shields).  LED 
stayed on 13, but I had to move CONSOLE to a Software Serial and add 
some code into the sketch to init a SoftwareSerial object and include 
the write header file.


Changes are in https://github.com/go4retro/PDDuino

When I start the app, it says it is opening the SD card, and it says OK, 
but then it tries to print the directory and then it just starts over.  
I tried a bunch of cards here.  I got one to work for a bit, but when I 
re-inserted it, it too stopped and went the same behavior as the rest.  
Not sure what I should be looking for.


I'd consider myself pretty advanced for AVR programming, and so-so on 
Arduino, but I thought I'd at least ask before tearing too much into the 
code.


Is there a specific list you'd like these sent to, or posted as issues 
to your repo?


Jim

Re: [M100] WTB: NASDBox

[Brian K. White]

On 9/11/20 1:13 AM, RETRO Innovations wrote:

On 8/13/2020 7:36 AM, Brian K. White wrote:

On 8/12/20 10:46 PM, RETRO Innovations wrote:

On 8/12/2020 9:30 PM, Tom Wilson wrote:
Maybe we can build a new NADS using Arduino? A Teensy with built in 
SD socket is fairly inexpensive; we would just need a level 
converter and to port the program to Arduino platform.


Is the program open sourced somewhere?

Alternatively, is there some available C code for this functionality?

Jim




Jimmy Petit wrote an arduino implementation.
I added a little to that.

I have it running on a few different boards that have an sd card 
reader built in.


http://tandy.wiki/PDDuino
https://github.com/bkw777/PDDuino

Just the other day I found a cheaper & simpler ttl-rs232 module 
instead of the Schmart one in that video.
With this one, it's already got a male plug, and is wired DTE, so you 
just use the same cable that you use to connect a M100 to a PC, and 
powered with a short usb cable and a BCR-USB adapter.


Links to all those items in the readme on github.

Does the project work on an Arduino UNO already?  I forked, cloned, and 
tried to build, but didn't have immediate success, so thought I'd just 
confirm before I started changing stuff in the code.


For uno, or any other board besides Teensy or Feather 32u4 or Feather 
M0, you'd need to edit some #define's at the top.


Set #define BOARD Custom, then a few lines down see the section
#if BOARD == Custom

and edit all the values in that section for your board and your wiring, 
like which pins you hooked up your sdcard reader to etc.


Now I'm not using a regular ttl-rs232 module like in the mail you quoted 
any more myself.

I'm using http://github.com/bkw777/MounT
The pcb takes the place of a serial cable and the whole things sticks 
right on the serial port. You just stick the teensy or feather right on 
it, and it provides the serial connection and the rs232 level shifter. 
There's a video in the readme. Now it doesn't even need sockets soldered 
on like in the video.

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


Just today I started playing with a couple ESP boards (instead of AVR), 
one essentially ESP-12E, Heltec WiFi-Kit-8, and one ESP-32, Heltec 
WiFi-Kit-32. I just git Zimodem running on the 8266 board (wifi-kit-8), 
with debug messages printing to the on-board oled screen. Not fully 
working yet though. I can see output on the serial port but not type 
into it.


Allan Huffman has a writeup of using Zimodem on esp-8266 with a Coco, 
and I'm doing essentially the same thing.


https://subethasoftware.com/2018/02/28/wire-up-your-own-rs-232-wifi-modem-for-under-10-using-esp8266-and-zimodem-firmware/

https://subethasoftware.com/2019/05/02/cocowifi-fork-of-zimodem-updated-to-current/

It should be no problem to run the tpdd code on esp the same as on avr, 
and then the idea is to have both wifi modem and tpdd at the same time, 
and then, unlike WiModem, the source code is open.


--
bkw

Re: [M100] WTB: NASDBox (RETRO Innovations)

[Al Alkadi]

Good evening, 

I would be interested in a NASDBox as well (or a similar device), anybody
has one available? I understand they were discontinued.

Al.

-Original Message-
From: M100  On Behalf Of
m100-requ...@lists.bitchin100.com
Sent: Friday, September 11, 2020 4:43 PM
To: m100@lists.bitchin100.com
Subject: M100 Digest, Vol 117, Issue 8

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. Re: WTB: NASDBox (RETRO Innovations)


--

Message: 1
Date: Fri, 11 Sep 2020 00:13:21 -0500
From: RETRO Innovations 
To: m100@lists.bitchin100.com
Subject: Re: [M100] WTB: NASDBox
Message-ID: <0d77e440-dd82-2dc9-bfe7-667f491ea...@go4retro.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 8/13/2020 7:36 AM, Brian K. White wrote:
> On 8/12/20 10:46 PM, RETRO Innovations wrote:
>> On 8/12/2020 9:30 PM, Tom Wilson wrote:
>>> Maybe we can build a new NADS using Arduino? A Teensy with built in 
>>> SD socket is fairly inexpensive; we would just need a level 
>>> converter and to port the program to Arduino platform.
>>
>> Is the program open sourced somewhere?
>>
>> Alternatively, is there some available C code for this functionality?
>>
>> Jim
>>
>>
>
> Jimmy Petit wrote an arduino implementation.
> I added a little to that.
>
> I have it running on a few different boards that have an sd card 
> reader built in.
>
> http://tandy.wiki/PDDuino
> https://github.com/bkw777/PDDuino
>
> Just the other day I found a cheaper & simpler ttl-rs232 module 
> instead of the Schmart one in that video.
> With this one, it's already got a male plug, and is wired DTE, so you 
> just use the same cable that you use to connect a M100 to a PC, and 
> powered with a short usb cable and a BCR-USB adapter.
>
> Links to all those items in the readme on github.
>
Does the project work on an Arduino UNO already?? I forked, cloned, and
tried to build, but didn't have immediate success, so thought I'd just
confirm before I started changing stuff in the code.

Jim




--

Subject: Digest Footer

___
M100 mailing list
M100@lists.bitchin100.com
http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com


--

End of M100 Digest, Vol 117, Issue 8

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 8/13/2020 7:36 AM, Brian K. White wrote:

On 8/12/20 10:46 PM, RETRO Innovations wrote:

On 8/12/2020 9:30 PM, Tom Wilson wrote:
Maybe we can build a new NADS using Arduino? A Teensy with built in 
SD socket is fairly inexpensive; we would just need a level 
converter and to port the program to Arduino platform.


Is the program open sourced somewhere?

Alternatively, is there some available C code for this functionality?

Jim




Jimmy Petit wrote an arduino implementation.
I added a little to that.

I have it running on a few different boards that have an sd card 
reader built in.


http://tandy.wiki/PDDuino
https://github.com/bkw777/PDDuino

Just the other day I found a cheaper & simpler ttl-rs232 module 
instead of the Schmart one in that video.
With this one, it's already got a male plug, and is wired DTE, so you 
just use the same cable that you use to connect a M100 to a PC, and 
powered with a short usb cable and a BCR-USB adapter.


Links to all those items in the readme on github.

Does the project work on an Arduino UNO already?  I forked, cloned, and 
tried to build, but didn't have immediate success, so thought I'd just 
confirm before I started changing stuff in the code.


Jim

Re: [M100] WTB: NASDBox

[Brian K. White]

I finally got off my butt and made a little pcb to attach an Adafruit 
Feather board directly to the back of the M100, where the db25 directly 
on the board takes the place of a serial cable, and a max3232 chip and 5 
caps on the board takes the place of a separate ttl-rs232 module. Any 
Adafruit Feather board could be plugged in, but for starters, only the 
TX/RX pins are connected, and it's mostly just good for running PDDuino 
on either of the two versions of Adalogger boards. There is an Adalogger 
board based on a 32u4, and one based on a M0. Even the 32u4 works fine 
for just doing TPDD.


https://github.com/bkw777/PDDuino/tree/master/PCB

Which fits either of these,
https://learn.adafruit.com/adafruit-feather-32u4-adalogger
https://learn.adafruit.com/adafruit-feather-m0-adalogger


Not Yet Tested, do not order. I have already ordered everything to test.

The layout also works on T102 even though the T102 and Olivetti M10 
serial port is upside down.


The Adalogger boards have a built-in lipo battery manager, so I included 
a power switch which uses the "En" enable pin which disables the voltage 
regulator. The digikey BOM includes a neat little lipo cell that plugs 
in to the JST connector and tucks in the space created between the 
Adalogger board and this adapter board.


The battery is totally optional. You don't need a battery because you 
can run just fine off the BCR port. But, one thing I want to do is use a 
wand to read the UPC codes on all my laserdiscs, so, even if you build a 
BCR power adapter you still sometimes need to run on other power. And if 
you have a battery plugged in, it's annoying to unplug that tiny JST 
plug, so you want the power switch so you can just leave the battery 
connected all the time.


You don't really need the socket headers either. The Adalogger comes 
with a set of male pins, and the shoulder is taller than the components 
in the middle of the adapter. You could solder the Adalogger right to 
the adapter.


The aim here is mostly just low hanging fruit. This should be easier to 
build than those amazing microtpdd / nanotpdd boards, and, the source is 
available for this, both the kicad schematic & pcb files, and the 
SD2TPDD code to run on the arduino. You just buy the off-the-shelf 
Adalogger board which has all the complicated bits already done, and the 
adapter board just has a few larger simple parts to install that you can 
do with an iron.


Next the same thing for Teensy. Teensy now has 3 boards with sd card 
reader built in. 3.5, 3.6 and 4.1. The 3.5 is interesting because it's 
5v tolerant.


--
bkw




On 8/13/20 8:36 AM, Brian K. White wrote:

On 8/12/20 10:46 PM, RETRO Innovations wrote:

On 8/12/2020 9:30 PM, Tom Wilson wrote:
Maybe we can build a new NADS using Arduino? A Teensy with built in 
SD socket is fairly inexpensive; we would just need a level 
converter and to port the program to Arduino platform.


Is the program open sourced somewhere?

Alternatively, is there some available C code for this functionality?

Jim




Jimmy Petit wrote an arduino implementation.
I added a little to that.

I have it running on a few different boards that have an sd card 
reader built in.


http://tandy.wiki/PDDuino
https://github.com/bkw777/PDDuino

Just the other day I found a cheaper & simpler ttl-rs232 module 
instead of the Schmart one in that video.
With this one, it's already got a male plug, and is wired DTE, so you 
just use the same cable that you use to connect a M100 to a PC, and 
powered with a short usb cable and a BCR-USB adapter.


Links to all those items in the readme on github.


I want to see if it'll work on an OpenLog board, which is way tinier, 
yet still has a microcontroller, rs232(ttl), and sdcard reader, which 
is about all you need for a TPDD.
https://www.aliexpress.com/wholesale?SearchText=OpenLog&SortType=price_asc 


Amazon & ebay etc have them too.

Though with that, I think you probably have to provide 3.3v power, 
while the adalogger/teensy boards have usb inputs and on-board 
regulators. Adalogger even has it's own lipo manager built-in too, 
though, this code is drawing so little current that the BCR port is 
fine and you don't have to worry about any batteries. (2-3ma when 
idle, 20ma briefly just while actively reading or writing)


Next step is get rid of the ttl-rs232 module and cable, and make a pcb 
with a 25 pin plug and the max3232 & caps, and the adalogger or 
teensy, and get power from the bcr port with the usb adapter.


There is a now a new Teensy 4.1 which has a sd card reader to add to 
the list, but it's pretty ridiculous overkill for this. Teensy 3.5 is 
already overkill. I haven't ordered a 4.1 yet, and so the code doesn't 
support it explicitly yet, though I'm sure it requires almost nothing 
to do so. I'm more interested in going the other way and try to use 
one of those OpenLog boards.





--
bkw

Re: [M100] WTB: NASDBox

[Brian K. White]

On 8/12/20 10:46 PM, RETRO Innovations wrote:

On 8/12/2020 9:30 PM, Tom Wilson wrote:
Maybe we can build a new NADS using Arduino? A Teensy with built in SD 
socket is fairly inexpensive; we would just need a level converter and 
to port the program to Arduino platform.


Is the program open sourced somewhere?

Alternatively, is there some available C code for this functionality?

Jim




Jimmy Petit wrote an arduino implementation.
I added a little to that.

I have it running on a few different boards that have an sd card reader 
built in.


http://tandy.wiki/PDDuino
https://github.com/bkw777/PDDuino

Just the other day I found a cheaper & simpler ttl-rs232 module instead 
of the Schmart one in that video.
With this one, it's already got a male plug, and is wired DTE, so you 
just use the same cable that you use to connect a M100 to a PC, and 
powered with a short usb cable and a BCR-USB adapter.


Links to all those items in the readme on github.


I want to see if it'll work on an OpenLog board, which is way tinier, 
yet still has a microcontroller, rs232(ttl), and sdcard reader, which is 
about all you need for a TPDD.

https://www.aliexpress.com/wholesale?SearchText=OpenLog&SortType=price_asc
Amazon & ebay etc have them too.

Though with that, I think you probably have to provide 3.3v power, while 
the adalogger/teensy boards have usb inputs and on-board regulators. 
Adalogger even has it's own lipo manager built-in too, though, this code 
is drawing so little current that the BCR port is fine and you don't 
have to worry about any batteries. (2-3ma when idle, 20ma briefly just 
while actively reading or writing)


Next step is get rid of the ttl-rs232 module and cable, and make a pcb 
with a 25 pin plug and the max3232 & caps, and the adalogger or teensy, 
and get power from the bcr port with the usb adapter.


There is a now a new Teensy 4.1 which has a sd card reader to add to the 
list, but it's pretty ridiculous overkill for this. Teensy 3.5 is 
already overkill. I haven't ordered a 4.1 yet, and so the code doesn't 
support it explicitly yet, though I'm sure it requires almost nothing to 
do so. I'm more interested in going the other way and try to use one of 
those OpenLog boards.


--
bkw

Re: [M100] WTB: NASDBox

[RETRO Innovations]

On 8/12/2020 9:30 PM, Tom Wilson wrote:
Maybe we can build a new NADS using Arduino? A Teensy with built in SD 
socket is fairly inexpensive; we would just need a level converter and 
to port the program to Arduino platform.


Is the program open sourced somewhere?

Alternatively, is there some available C code for this functionality?

Jim

Re: [M100] WTB: NASDBox

[Tom Wilson]

Maybe we can build a new NADS using Arduino? A Teensy with built in SD
socket is fairly inexpensive; we would just need a level converter and to
port the program to Arduino platform.

On Wed, Aug 12, 2020 at 4:23 PM Chris Fezzler  wrote:

>
>
> Nice!
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, August 12, 2020, 07:18:43 PM EDT, Josh Malone <
> josh.mal...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> Android phone w/ USB serial cable is all of that, and Wi-Fi
>
> On Wed, Aug 12, 2020 at 6:57 PM Chris Fezzler  wrote:
>
>
>
> I seem to recall I connected my Model T to an old Palm Pilot 500.
>
> Batteries.  Check.  Simple.  Check.  Portable. Check.  Power-efficient.
> Check.
>
> https://www.ebay.com/b/Palm-M500/38331/bn_7023339442
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, August 12, 2020, 04:52:13 PM EDT, Wayne Lorentz <
> wa...@lorentz.me> wrote:
>
>
>
>
>
>
>
>
>
> Thanks for the advice, John.  Unfortunately, I'm looking for something
> better than an Android device.  Too many wires, and too much complication.
> And I liked that the NASDBox ran of off AA batteries, so I don't have to
> think about whether the Android device is charged or not.
>
> I guess I was looking for something more in line with the philosophy of
> the 100, itself: simple, portable, power-efficient.
>
> Maybe someone will put a used one on fleaBay some day.
>
> > On Aug 11, 2020, at 1:40 PM, m100-requ...@lists.bitchin100.com wrote:
> >
> > If you need a completely portable solution for a TPDD emulator, I'd go
> for mComm on an Android device.
>
>
>
>
>
>
>
>
> --
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ

Re: [M100] WTB: NASDBox

[Chris Fezzler]

 Nice!
On Wednesday, August 12, 2020, 07:18:43 PM EDT, Josh Malone 
 wrote:  
 
 Android phone w/ USB serial cable is all of that, and Wi-Fi
On Wed, Aug 12, 2020 at 6:57 PM Chris Fezzler  wrote:

 I seem to recall I connected my Model T to an old Palm Pilot 500.
Batteries.  Check.  Simple.  Check.  Portable. Check.  Power-efficient.  Check.
https://www.ebay.com/b/Palm-M500/38331/bn_7023339442





On Wednesday, August 12, 2020, 04:52:13 PM EDT, Wayne Lorentz 
 wrote:  
 
 Thanks for the advice, John.  Unfortunately, I'm looking for something better 
than an Android device.  Too many wires, and too much complication.  And I 
liked that the NASDBox ran of off AA batteries, so I don't have to think about 
whether the Android device is charged or not.

I guess I was looking for something more in line with the philosophy of the 
100, itself: simple, portable, power-efficient.

Maybe someone will put a used one on fleaBay some day.

> On Aug 11, 2020, at 1:40 PM, m100-requ...@lists.bitchin100.com wrote:
> 
> If you need a completely portable solution for a TPDD emulator, I'd go for 
> mComm on an Android device.
  
  

Re: [M100] WTB: NASDBox

[Josh Malone]

Android phone w/ USB serial cable is all of that, and Wi-Fi

On Wed, Aug 12, 2020 at 6:57 PM Chris Fezzler  wrote:

> I seem to recall I connected my Model T to an old Palm Pilot 500.
>
> Batteries.  Check.  Simple.  Check.  Portable. Check.  Power-efficient.
> Check.
>
> https://www.ebay.com/b/Palm-M500/38331/bn_7023339442
>
>
>
>
>
>
> On Wednesday, August 12, 2020, 04:52:13 PM EDT, Wayne Lorentz <
> wa...@lorentz.me> wrote:
>
>
> Thanks for the advice, John.  Unfortunately, I'm looking for something
> better than an Android device.  Too many wires, and too much complication.
> And I liked that the NASDBox ran of off AA batteries, so I don't have to
> think about whether the Android device is charged or not.
>
> I guess I was looking for something more in line with the philosophy of
> the 100, itself: simple, portable, power-efficient.
>
> Maybe someone will put a used one on fleaBay some day.
>
> > On Aug 11, 2020, at 1:40 PM, m100-requ...@lists.bitchin100.com wrote:
> >
> > If you need a completely portable solution for a TPDD emulator, I'd go
> for mComm on an Android device.
>

Re: [M100] WTB: NASDBox

[Chris Fezzler]

 I seem to recall I connected my Model T to an old Palm Pilot 500.
Batteries.  Check.  Simple.  Check.  Portable. Check.  Power-efficient.  Check.
https://www.ebay.com/b/Palm-M500/38331/bn_7023339442





On Wednesday, August 12, 2020, 04:52:13 PM EDT, Wayne Lorentz 
 wrote:  
 
 Thanks for the advice, John.  Unfortunately, I'm looking for something better 
than an Android device.  Too many wires, and too much complication.  And I 
liked that the NASDBox ran of off AA batteries, so I don't have to think about 
whether the Android device is charged or not.

I guess I was looking for something more in line with the philosophy of the 
100, itself: simple, portable, power-efficient.

Maybe someone will put a used one on fleaBay some day.

> On Aug 11, 2020, at 1:40 PM, m100-requ...@lists.bitchin100.com wrote:
> 
> If you need a completely portable solution for a TPDD emulator, I'd go for 
> mComm on an Android device.
  

Re: [M100] WTB: NASDBox

[Wayne Lorentz]

Thanks for the advice, John.  Unfortunately, I'm looking for something better 
than an Android device.  Too many wires, and too much complication.  And I 
liked that the NASDBox ran of off AA batteries, so I don't have to think about 
whether the Android device is charged or not.

I guess I was looking for something more in line with the philosophy of the 
100, itself: simple, portable, power-efficient.

Maybe someone will put a used one on fleaBay some day.

> On Aug 11, 2020, at 1:40 PM, m100-requ...@lists.bitchin100.com wrote:
> 
> If you need a completely portable solution for a TPDD emulator, I'd go for 
> mComm on an Android device.

Re: [M100] WTB: NASDBox

[John R. Hogerhuis]

On Mon, Aug 10, 2020 at 2:29 PM Wayne Lorentz  wrote:

> Does anyone know where I can buy a NASDBox?
>
> The Club100 web page for it states that orders are no longer being taken.
> But the page also indicates that it was last updated in 2011.
>
> Does anyone know if someone else has taken up this project in the last
> nine years, or is it abandoned?
>
>
Hello Wayne,

Ken Pettit is the engineer who designed NADSBox but he is not making any
more.

If you need a completely portable solution for a TPDD emulator, I'd go for
mComm on an Android device.

If you're always near a PC there are multiple options.

-= Model T's Forever =-

-- John.