Additionally, I had to turn off the UART debug log as it was blasting data into the serial stream.
This was on a very vanilla RC2014 Pro system with the SIO/2 serial board.
Also, I would suggest using PuTTY "RAW" mode as I described in my other post "RC2014 on the Network" (the 2nd half of that post)
This way the correct CR/LF combinations are sent (or not sent) as well as sending each character as it is typed, and not after each Enter (or Line At A Time Mode)
Let me know if anyone has further questions and I will try to help. Cheers!
-Randal (at CubeCentral)
Chris –
I have a few questions:
Hopefully we can sort this out! It looks so very close to being up and running!
-Randal (at CubeCentral)
From: rc201...@googlegroups.com [mailto:rc201...@googlegroups.com] On Behalf Of Chris Scullion
Sent: Monday, April 9, 2018 05:41
To: RC2014-Z80 <rc201...@googlegroups.com>
Subject: [rc2014-z80] Re: ESP8266 Wifi Module setup and additional settings
Thanks for this. With these changes I was able to get a more stable connection. However, I'm now getting this problem (see transcript below): after pressing "X", the monitor won't accept "y" or "Y" to boot into CP/M. Any ideas?
Press [SPACE] to activate console
Press [SPACE] to activate console
Z80 SBC Boot ROM 1.1 by G. Searle
RC2014 port by Mitch Lalovic
Type ? for options
>
telnet> mode character
>?
R - Reset
BC or BW - ROM BASIC Cold or Warm
X - Boot CP/M (load $D000-$FFFF from disk)
:nnnnnn... - Load Intel-Hex file record
>
>x
Boot CP/M?
>Y?
>
On Sunday, April 8, 2018 at 12:49:52 PM UTC-4, Cube Central wrote:
I wanted to write this up as I found an additional setting in the ESP-Link setup that was needed in order for my RC2014 system to successfully transmit and receive data.
I followed the guide here: https://rc2014.co.uk/modules/esp8266-wifi-module/esp-link-setup/
and I was having difficulties with being able to have the WiFi module send data over the WiFi link. I was able to transmit data to it ok.
While in the setup, on the home screen, I had to disable the RX pull-up.
Additionally, I had to turn off the UART debug log as it was blasting data into the serial stream.
This was on a very vanilla RC2014 Pro system with the SIO/2 serial board.
Also, I would suggest using PuTTY "RAW" mode as I described in my other post "RC2014 on the Network" (the 2nd half of that post)
This way the correct CR/LF combinations are sent (or not sent) as well as sending each character as it is typed, and not after each Enter (or Line At A Time Mode)
Let me know if anyone has further questions and I will try to help. Cheers!
-Randal (at CubeCentral)
--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/9e44773c-1852-42c4-a9c0-5d978662de68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
- This is not the SIO2 board. My setup is using the original 6850 board.
- Yes, this is the output form a telnet session running on Linux (which is running under crouton on a Chromebook).
- The FTDI cable is disconnected for this test. (the FTDI cable works fine without the ESP8266 board)
- I believe the "mode character" command sets telnet into the "raw" mode you are referring to.
- I subsequently tried Putty on the same Linux machine and everything works perfectly. In Putty, I have local echo and local line editing turned off.
I guess it's mostly academic at this point since I have a working environment. But if others are trying to get regular linux telnet to work, we can continue troubleshooting.
I tried "toggle crlf" in telnet with no improvement, though there are additional spurious characters displayed occasionally. By the way, I also have a home-built Altair 8800 clone that uses telnet for the main terminal, and that works perfectly from this same linux box. (that is, I don't currently suspect telnet itself)