Quest for Terminal Software that Works with the Quirky NanoPEB Serial Port

[TMA-1]

This is a more targeted continuation of the blatantly hijacked thread <here>.  Executive Summary of this go-forward:

 

The NanoPEB being periodically peddled on eBay is a wonderful little device, providing 3 virtual disk drives which map to a Compact Flash card, a 32K RAM expansion, and an RS232 serial port.  Unfortunately, the serial port was set up in such a way that virtually all existing Terminal Emulation software packages take one look at that serial port, and promptly throw their dish on the floor.  The technical details of that I leave to vaster minds than mine to explain.

 

Meanwhile, I have slapped together what I think is a toy many of us would like to have and use, a WiFi modem that is RS232 compatible and doesn't cost an arm and a leg.  The prototype has been proven with several IBM-ish 8088 machines, and I have been surfing Telnet BBS's with it.  I would like to test and use it with my TI-99/4A plus NanoPEB, but the terminal software always stops me, since none of them like my serial port.  My current quest is to find, make, beg, borrow, steal or barter a package into working with the NanoPEB. 

 

The ultimate goal is to publish details of this very simple modem, so that others in this community can make their own for less than $10 and a few minutes work, and go BBS surfing using their household WiFi, Telnet, and a T-99/4A with either an "original" serial port or a NanoPeb.  I'll explain how once it's tested, as I don't want folks clamoring to build one only to find that it doesn't work in this plane of existence.  The modem itself works in another environment, but I'm a firm believer in end-to-end systems testing.  Besides, I have a NanoPEB, so I'm greedy and want it to work with my TI-99/4A.

 

So that's the lay of the land.

 

In our last episode (thread) InsaneMultitasker had generously thrown me a software package thinking it might work.  I'm sorry to report that it doesn't.  It runs well up until the moment any byte is actually sent down the line, then it crashes.  (Cursor stops blinking, and no keys respond.)  To be thorough I connected a null modem cable between the NanoPeb and the modem, (they normally dock directly), but the behavior was the same.

 

The quest continues,...

 

Edited December 25, 2019 by TMA-1

[+InsaneMultitasker]

I'll try it with my nanopeb this week.  I'm guessing my test cable would have consisted of transmit, receive, and ground.  If you connect other signals if may or may not work, especially if one of this signals on the modem side is configured opposite of what is expected.  (Edit: See Stuart's post as the nanopeb may require more than tx/rx/gnd to be connected for proper operation)

[arcadeshopper]

I'm thinking you have flow control issues.. do you enable hardware flow control on your modem?  If not you may need to wire the cable to loop back dtr/dce etc. 

 

Greg

[TMA-1]

Not sure if there was a typo in that last post, or how to reconcile it with the previous one.

 

Additional info:

• The MT74 software crashes upon a data traffic attempt even with no modem attached.
• The DB9 interface of the modem is connected to a MAX3232 (level converter) chip, which passes ONLY transmit data, receive data, and ground.  There is no opportunity to know or respect hardware flow control within the modem.
• For that reason, software flow control is activated in the modem, and desired of the terminal emulator.

 

[arcadeshopper]

I did the same basic thing here, pretty sure the cable is straight through and im using TIMXT of course to get 80columns on a 4a. 

 

[+InsaneMultitasker]

1 hour ago, TMA-1 said:

Not sure if there was a typo in that last post, or how to reconcile it with the previous one.

 

Additional info:

• The MT74 software crashes upon a data traffic attempt even with no modem attached.
• The DB9 interface of the modem is connected to a MAX3232 (level converter) chip, which passes ONLY transmit data, receive data, and ground.  There is no opportunity to know or respect hardware flow control within the modem.
• For that reason, software flow control is activated in the modem, and desired of the terminal emulator.

 

I set up my nano a few minutes ago. Using a standard PC 9-to-25 pin modem cable (i.e., NO modifications) I connected the nano 9-pin serial port to my 14.4k modem's DB25 connector.

 

Fortunately, the MT74 disk was still mounted from the last time I used the nano.  So... I loaded MT74 via Editor Assembler, set the baud rate to 4800, typed AT and was greeted with "OK".  AT&V displayed the full modem profile.  

 

As Arcadeshopper mentions earlier you may have a flow control issue or some other signaling issue to work through.  (2400 bps also worked just fine)

 

Found the old topic from 2017; looks like I had originally distributed the files via Heatwave BBS.

 

[TMA-1]

4 hours ago, InsaneMultitasker said:

So... I loaded MT74 via Editor Assembler, set the baud rate to 4800, typed AT and was greeted with "OK".  AT&V displayed the full modem profile.

The fact that your experiment works right-off-the-bat has me back to thinking my particular NanoPEB just happens to have a bad 9902 UART chip.

 

Narry a whisper has ever left this port's lips.

 

I have had situations where characters typed on my laptop would appear on the TI's screen.  Attempting the reverse, however, brings instant death.

 

I even tried turning on "Remote Echo" in MT74, but then those same characters typed on my laptop crash the TI99 when it attempts to echo them back down the line.  "Sending data" is apparently fatal to this machine.

 

I have tried, as "partners" hooked-up to the NanoPEB RS232:

• The WiFi modem, a 3-wire special which works perfectly well on any PC's RS232 serial port.
• The WiFi modem piped through a null modem cable, just for the grins because it really doesn't make sense.
• A serial partner laptop, through a null modem cable.
• A serial partner laptop through a straight cable instead, again just to get the T-shirt.
• Nothing at all.  (It still crashes the system to try to "send" a byte.)

And I have tried each of the above scenarios with:

• Terminal Emulator II.
• Fast-Term.
• Telco.
• TIMXT ("blind", since the video is designed for the F18A which I don't have.)
• And now finally MT74, which is now known to work with a suitable (9902 I think)  NanoPEB.

At NO TIME in the history of this NanoPEB, has 1 data byte ever been sent from this port.  At Each and every attempt, the first byte instantly crashes/hangs the TI-99/4A, forcing a power cycle reboot.

 

I'd be happy if someone can talk me out of just waiting for my replacement UART chip, but this is the only conclusion I can come to at this point.

Regarding the stated method for LOADing MT74, I unfortunately do not have Editor/Assembler.  I have been making do by hacking the LOAD program from Telco to run MT74 instead.  I'm not sure how well the shoes fit, but it does seem to launch MT74 successfully.  I just hope I'm not creating any address collisions or similar bad karma.

 

By the way InsaneMultitasker, I have visited HeatWave in the recent past.  Very nice board--it's what made me want to get this working on my TI-99/4A!

 

Thank-you all for your ongoing support, and have a Merry Holiday.

Ian

[Stuart]

If you've got only transmit, receive and ground connected to the modem, have you got pins 7 (RTS) and 8 (CTS) connected together in the connector at the NanoPEB end? I believe the 9902 waits until CTS is active when transmitting, so any software that loops until the character is transmitted will appear to hang unless CTS is connected. (The NanoPEB is different to the TI Serial PEB card in that CTS is brought straight out to the serial connector rather than being connected to DSR(?) on the card.)

 

NanoPEB                 Lantronix
9-way D-type Male       25-way D-type Female
Pin                              Pin
 2 (RX)  ------<<------ (RX out)  3
 3 (TX)  ------>>------ (TX in)   2
 5 (GND) -------------- (GND)     7
 7 (RTS) -->>--+
 8 (CTS) --<<--+ (pins 7 and 8 connected together)

 

Edited December 25, 2019 by Stuart

[TMA-1]

Stuart you're a genius!  What a great Christmas Day present.  Shorting the RTS and CTS pins worked on my NanoPeb with the customized version of MT74!

 

We're just on our way out the door to family, so I haven't had a proper look at much yet, but I am getting traffic to and from the modem now.  Thank-you.

 

I guess this begs the question, "Why does InsaneMultitasker have a different result?"  Perhaps the design of the 9902 NanoPEB changed at some point, or perhaps that's the job of 1 of the 2 jumpers that I see on the device but have never known what they control.  Likely the latter.  Either way, thanks to you both I'm a happy camper.

 

I'll test at an appropriate baud rate and with several of my software packages at the first opportunity.  Looking forward to visiting Heatwave BBS on the real deal.

 

[arcadeshopper]

likely he shorts those pins also and just doesn't remember  

[+InsaneMultitasker]

Agree with Arcadeshopper - I'm sure I just don't remember correctly and/or conflated my memories of the nano serial port with those of the ubergrom cart's UART - the latter  only requires tx/rx/gnd.   Just another reason to be thankful for this community.  

 

(I was still recovering from some surgeries back then so anything is possible.  For example, I don't remember modifying MT74 or posting about it even though I recognize the code and comments).

 

[Stuart]

2 hours ago, TMA-1 said:

Stuart you're a genius!  What a great Christmas Day present.  Shorting the RTS and CTS pins worked on my NanoPeb with the customized version of MT74!

 

We're just on our way out the door to family, so I haven't had a proper look at much yet, but I am getting traffic to and from the modem now.  Thank-you.

 

I guess this begs the question, "Why does InsaneMultitasker have a different result?"  Perhaps the design of the 9902 NanoPEB changed at some point, or perhaps that's the job of 1 of the 2 jumpers that I see on the device but have never known what they control.  Likely the latter.  Either way, thanks to you both I'm a happy camper.

 

I'll test at an appropriate baud rate and with several of my software packages at the first opportunity.  Looking forward to visiting Heatwave BBS on the real deal.

 

In Insane's post #6 he said he was using a standard modem cable, where the NanoPEB CTS and RTS would be connected through to the relevant pins on the modem. So CTS on the NanoPEB wouldn't be left disconnected like with your Tx/Rx/Gnd-only cable.

 

[+InsaneMultitasker]

I disassembled Telco and took a stab at nanopeb compatibility.  I overwrote some of the spooler code (useless with nanopeb) with modified RS232 routines that enable/disable the RS232 card during serial port setup and character transmission.  Unfortunately, Telco freezes on startup in the below 'transmit character' section of code.  If I eliminate the "JNE EO" Telco starts and it is usable in terminal mode however, sending multiple characters in rapid succession (i.e., file transfers or conference mode) results in dropped transmission/buffer overrun.   I tried testing bit 16 to mirror Mass Transfer without success.  Feels like I'm missing something simple but I can't put my finger on it.

 

; Transmit character

       MOV  @CX,R12                     >C320,>D1C6        '. ..'         AA00  (base + port, i.e. >1340)
EO     TB   >17    xmit?                     >1F17              '..'           AA04
       JNE  EO                          >16FE              '..'           AA06
       SBO  >10                         >1D10              '..'           AA08
       LDCR @>0002(R13),8               >322D,>0002        '2-..'         AA0A
       SBZ  >10                         >1E10              '..'           AA0E

       RT

 

;--------------------------------

; set RS232 parameters

CP     MOV  *R10,R12                    >C31A              '..'           A856
       LIMI >0000                       >0300,>0000        '....'         A858
       SBO  >1F                         >1D1F              '..'           A85C
       LDCR R8,8                        >3208              '2.'           A85E

       SBZ  >0D                         >1E0D              '..'           A860
       LDCR R9,12                       >3309              '3.'           A862
       SBO  >12          18               >1D12              '..'           A864
       SBZ  >15          21               >1E15              '..'           A866
       SBZ  >14          20               >1E14              '..'           A868
       SBZ  >13          19               >1E13              '..'           A86A
       LIMI >0001                       >0300,>0001        '....'         A86C
       RTWP                             >0380              '..'           A870

 

(While digging around the code I looked at updating Telco to use the F18A 80 column mode. Unfortunately, Telco seems to use VRAM beyond the standard 16K addressable by the 9918/F18a.  Modifying a complex, modular program like Telco without source code is nigh impossible.    )

[Omega-TI]

5 minutes ago, InsaneMultitasker said:

(While digging around the code I looked at updating Telco to use the F18A 80 column mode. Unfortunately, Telco seems to use VRAM beyond the standard 16K addressable by the 9918/F18a.

Maybe the future Mk2 with color ANSI?  (Full on fantasy mode)

 

5 minutes ago, InsaneMultitasker said:

Modifying a complex, modular program like Telco without source code is nigh impossible.    )

Bummer!

[TMA-1]

Something simple, like the option of using XON/XOFF "software flow control"?

 

My understanding is limited, but I think it works by sending a Cntl-S down the main data line when the receive buffer is approaching full.  Cntl-Q signals to resume.  It can be used instead of, or in addition to, hardware flow control with a respecting partner.

 

The WiFi modem firmware supports it.  (I use it successfully in the 8088 realm, because the 3-wire RS232 simplicity of the hardware design demands it.)

 

MT74 doesn't seem to support it at all.

 

On a separate but related note, I tried accessing Heatwave with my newly "working" setup using MT74. 4800 baud drops chunks of transmission due to, (wait for it,...) complete lack of flow control.  (No hardware flow control in the hardware; no software flow control in the software.  Well darn.)

 

It seems happier at 2400 baud, but I wouldn't rely on it to pay my VISA bill.  I haven't tried file transfer to see if I can "get away with that" yet.

 

What about Fast-Term?  Fast-Term seems pretty nifty, and already supports the option to use software flow control.  Could IT be reverse engineered to support the flaky NanoPEB?

 

Edited December 26, 2019 by TMA-1

[atrax27407]

TELCO was designed to use the extra 192K VRAM in the v9938.

[Stuart]

9 hours ago, InsaneMultitasker said:

I disassembled Telco and took a stab at nanopeb compatibility.  I overwrote some of the spooler code (useless with nanopeb) with modified RS232 routines that enable/disable the RS232 card during serial port setup and character transmission.  Unfortunately, Telco freezes on startup in the below 'transmit character' section of code.  If I eliminate the "JNE EO" Telco starts and it is usable in terminal mode however, sending multiple characters in rapid succession (i.e., file transfers or conference mode) results in dropped transmission/buffer overrun.   I tried testing bit 16 to mirror Mass Transfer without success.  Feels like I'm missing something simple but I can't put my finger on it.

 

; Transmit character

       MOV  @CX,R12                     >C320,>D1C6        '. ..'         AA00  (base + port, i.e. >1340)
EO     TB   >17    xmit?                     >1F17              '..'           AA04
       JNE  EO                          >16FE              '..'           AA06
       SBO  >10                         >1D10              '..'           AA08
       LDCR @>0002(R13),8               >322D,>0002        '2-..'         AA0A
       SBZ  >10                         >1E10              '..'           AA0E

       RT

 

;--------------------------------

; set RS232 parameters

CP     MOV  *R10,R12                    >C31A              '..'           A856
       LIMI >0000                       >0300,>0000        '....'         A858
       SBO  >1F                         >1D1F              '..'           A85C
       LDCR R8,8                        >3208              '2.'           A85E

       SBZ  >0D                         >1E0D              '..'           A860
       LDCR R9,12                       >3309              '3.'           A862
       SBO  >12          18               >1D12              '..'           A864
       SBZ  >15          21               >1E15              '..'           A866
       SBZ  >14          20               >1E14              '..'           A868
       SBZ  >13          19               >1E13              '..'           A86A
       LIMI >0001                       >0300,>0001        '....'         A86C
       RTWP                             >0380              '..'           A870

 

(While digging around the code I looked at updating Telco to use the F18A 80 column mode. Unfortunately, Telco seems to use VRAM beyond the standard 16K addressable by the 9918/F18a.  Modifying a complex, modular program like Telco without source code is nigh impossible.    )

 

With your transmit routine, the code in TI docs usually has things in a slightly different order and tests a different bit. See if the following is any better; it tests for character transmission complete while the transmitter is enabled.

 

    MOV  @CX,R12
    SBO  16         (>10) Bit 16 - turn on transmitter
EO  TB   22         (>16) Bit 22 - test transmit buffer register empty *** Testing different bit to your code ***
    JNE  EO         Loop until it is
    LDCR @>0002(R13),8
    SBZ  16         (>10) Bit 16 - turn off transmitter
    RT

 

[+InsaneMultitasker]

Thanks, Stuart.  Your snip of code mirrors what is currently implemented in Mass transfer.  I replaced the Telco routine with your suggested code and it still hangs.  Later today I will double check what I entered.

[TMA-1]

Some gratuitous eye-candy,...

 

[+InsaneMultitasker]

On 12/26/2019 at 6:00 AM, Stuart said:

 

With your transmit routine, the code in TI docs usually has things in a slightly different order and tests a different bit. See if the following is any better; it tests for character transmission complete while the transmitter is enabled.

 

Today I spent my day in the kitchen while the subconscious poked at this problem.   Question: why does the same routine fail in one program and work in the other?  I figured the routine is valid so there must be an outside influence.  The RS232 init is correct so that left interrupt handling.  I've copied an expanded excerpt from my disassembly - notice the LIMI 1 just before the xmit routine. 

 

I added a LIMI 0 to the "new" xmit routine; Telco now appears to work fine and successive bytes are sent properly, at least while in terminal mode.  I'm not sure if the ISR or Telco's int handler is mucking up the works and at the moment, I don't care   I'll do a little more playing around and if things hold, I can share the modified program files for testing purposes.

 

       LIMI >0001                       >0300,>0001        '....'         A9F4
       MOV  @EM,@EM                     >C820,>D14E,>D14E  '. .N.N'       A9F8
       JNE  EN                          >1608              '..'           A9FE

; TRANSMIT SERIAL BYTE  (see D030 for new code)

       MOV  @CX,R12                     >C320,>D1C6        '. ..'         AA00
EO     TB   >17    xmit?                     >1F17              '..'           AA04
       JNE  EO                          >16FE              '..'           AA06
       SBO  >10                         >1D10              '..'           AA08
       LDCR @>0002(R13),8               >322D,>0002        '2-..'         AA0A
       SBZ  >10                         >1E10              '..'           AA0E

; CIB buffer
EN     MOV  @EP,@EP                     >C820,>D1B2,>D1B2  '. ....'       AA10
       JEQ  EQ                          >1310              '..'           AA16
       LIMI >0000                       >0300,>0000        '....'         AA18
       AB   @BI,@>8304                  >B820,>A0CB,>8304  '. ....'       AA1C
       MOV  @>8300,R0      cibbuf       >C020,>8300        '. ..'         AA22
       AB   @>8304,@ER     cibwrt       >B820,>8304,>A2CB  '. ....'       AA26
       BL   @BA                         >06A0,>AC2E        '....'         AA2C
       MOVB @>0002(R13),*R9             >D66D,>0002        '.m..'         AA30
       LIMI >0001                       >0300,>0001        '....'         AA34
EQ     RTWP

 

 

[Ed in SoDak]

How did I miss seeing this thread till yesterday? What good was a Nano with crippled RS232? Amazing stuff!

-Ed

[Omega-TI]

This thread is so gratifying to read!  It's nice to see Nano users having viable options available for calling the BBSes.  So who's going to start making plug Plug-N-Play WifI modules for all the Nano owners?  We also don't want Heatwave to shut down.  More users, the greater the odds it remains online.

 

It would be cool if Nano users could buy a gadget like the Commodore users have.  Simply plug it in and run the software.  K.I.S.S. sells!

 

[TMA-1]

I soooo love that last post Kwisatz Haderach!  That's exactly what I'm trying to do here!

 

I have a buddy who is going to manufacture a limited number (initially) of RS232 WiFi Modems with a cosmetically improved design.  He is also into 3D printing, so there may even be a case option for his modems in the future.

 

Meanwhile, I'm just putting the finishing touches on a paper that documents how to do one up yourself, for the many DIY'ers in the community.

 

Stay tuned!

[Omega-TI]

4 hours ago, TMA-1 said:

I have a buddy who is going to manufacture a limited number (initially) of RS232 WiFi Modems with a cosmetically improved design.  He is also into 3D printing, so there may even be a case option for his modems in the future.

I'm looking forward to seeing this project come to fruition!  One of the major drawbacks with the NANO has been it's limited ability to work with pre-existing comm programs.  Knowing that this will be overcome with some style and flair is going to make many NANO users happy. 

[atrax27407]

It is (or should be) a requirement for developers of "new" hardware to make the device compatible with previously-existing software standards. Otherwise, all they have developed is an expensive "paper weight" Newer is not better if you can't use it.