Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 35

Thread: Nascom2 Sending/Receiving data over serial to/from Linux

  1. #1
    Join Date
    Jan 2020
    Location
    South of England
    Posts
    26

    Default Nascom2 Sending/Receiving data over serial to/from Linux

    Has anyone had any success transferring data over serial to and from a Linux system?

    In an earlier post I said I had problems communicating with a Linux system over RS232. My thanks to Neal and David with resolving this. A mixure of baud rate, bits and parity issues. I can now send text by entering X on the N2 and receive text by typing into minicom on the Lx system.

    Saving memory from N2 to LX
    By entering "X" on the N2 then "T <xxxx> <yyyy> 0 0 01", I can dump memory blocks as "address 8 bytes" (in 7bit ascii) and use minicom on LX to "Capture" and store the text.

    Loading memory from LX to N2
    I haven't tried this yet, but I suspect I can send the text captured above via a shell script to convert each line to "M <address><CR><8 bytes><eol>".

    However I'm sure this method is rather obtuse. Is there a simpler method such as the N2 "W <start> <end>" command with something to receive it on the LX side.
    After receiving incoming data, it will also need to be sent back.

    I have tried capturing data from the N2 "W" command and reading the serial port to a file but not had any success sending it back by using "R" on the N2 and using "cat <file> > <serialport>" on the LX side.Nascom

    Any thoughts?

  2. #2

    Default

    Terminal programs like Minicom usually have a 'file send' facility which, in addition to the usual 'binary' file transfer modes (Kermit / Xmodem / Ymodem / Zmodem), also usually includes the ability to load and send out an ASCII text file, with a degree of flexibility such as the ability to specify whether CR / LF should or should not be sent after each line end, and whether characters sent to the serial port should also be echoed to the screen. Have you looked at that or are you specifically trying to come up with something which works from the Linux command line?

  3. #3
    Join Date
    Jan 2020
    Location
    South of England
    Posts
    26

    Default

    Thank you.
    Most of my testing and parameter adjustments (baud, parity, bits, stop) has been with Minicom at the LX end. Aside from flow control (HW or SW) I'm fairly confident any typed text (at either end) is sent and received correctly.
    Unfortunately I haven't had any success with sending data from the N2 using "W" and receiving matching data by Minicom to a file using "L=Capture" or "R=Receive". I do receive some information, however it doesn't appear correct when I use "od -x". If I turn the file around and try to send it from Minicom using "S=Send" the N2 cannot read it using "R".
    Ideally I would prefer to use the LX CLI. I am using the "stty" command on LX to set up the serial port and tried capturing data from the N2 "W" command using "cat <serialport> > <file>" at the LX end, however this data also appears incorrect and also cannot be received when sent back.
    Testing continues....

  4. #4
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,548

    Default

    lrzsz is a package on Linux that provides command line x,y, and zmodem send/receive.

    Also if you just need to cat plain ASCII text, you can uuencode files and cat/cut/copy/paste them into terminal windows etc and use the inverse tool on the other-side to re-encode binary.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  5. #5
    Join Date
    Jan 2020
    Location
    South of England
    Posts
    26

    Default

    A bit of extra info to my own post.
    I know that the N2 scans the keyboard and serial port, hence I can send text characters from LX to N2. A key test has been to input (and save somehow) the Ram Test program listed in the Ram board manual.
    To do this I entered the source on my Lx system and compiled it with a Z80 assembler. I took the binary output and converted it to text using "od -x" this output I then processed and sent to the Lx serial port "cat <file> > <serial>".
    Although the Baud rate is quite slow at 2400 some characters were missed. Keeping the speed to 2400 but slowing the data feed rate gave a better result.
    I suspect there may be a general fault with the N2 design not using HW or SW flow control. To test this I intend to create a programable clock to vary the Uart rate.

  6. #6

    Default

    A limiting factor on the nascom is the softwaee-controlled scroll. When your incoming data reaches the end of the bottom line it will scroll the screen and during that time it stops polling for incoming data. The 6402 uart has no rx buffer so it will overflow and drop characters.

    Neal

  7. #7
    Join Date
    Jan 2020
    Location
    South of England
    Posts
    26

    Default

    Thanks Neal,
    I believe you are correct.
    The data from my Lx system acts like the input from the keyboard modifying memory. eg. The stream starts with "M C80<cr>byte1 byte2 byte3...byte8<cr>byte9....byte16 <etc>" and "." to end modify memory. If I reset the N2 (cursor to top) and stream data from the Lx, then T(ab) through the memory, the first 16 lines x 8 bytes are correct however the next lines have the first byte per line with the top nibble set to 0. ie. Modify memory is ok until the screen scrolls up. If the cursor is at the bottom of the screen and I stream data, the "first byte-top nibble set to 0" corruption occurs immediately.
    As I mentioned above (21st) I've slowed my 2400 baud data stream by adding a 0.05 delay between sending bytes, the data is then pushed into memory without missing nibbles. I also need to try this with sending data, created by the "W" command, back to the N2 "R" command.

    Unfortunately I haven't found a way to set the serial port (using stty) to 2400 baud with a inter-character delay. As mentioned I think the N2 has a design fault by not being able to give HW or SW handshaking to hold up data flow. (Although this was unlikely to have been an issue with cassette decks and it wouldn't have been possible to pause the flow from a cass deck).

    I'm setting up a programmable clock generator so that I can try slower and faster baud rates.

    Chris

  8. #8
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,564

    Default

    Don't forget though that the 'X' command and the NAS-SYS functions are not designed to be suitable for large scale file transfers to/from the NASCOM at high speed.

    If you want to do this, you would need to write a dedicated program (i.e. read from the serial stream and store the data directly in memory without echoing to the screen).

    The limitation is the size of the DEBUG monitor...

    Dave

  9. #9

    Default

    Even when there are hardware flow control lines physically present it is usually the job of the processor, under the control of the OS low-level serial receive routines, to maintain a receive buffer in RAM and set or clear the hardware handshaking lines accordingly. I don't think any UART of that era (that I know of) has a large internal buffer and handles the hardware flow control entirely independently - on those UARTS which do have provision for RTS / CTS / DTR etc they are usually simple input or output flags which can be read or set by the microprocessor via one of the UART's registers.

    Typical Windows terminal programs including the veteran 'Hyperterminal' have a lot of control over how they send out text files, including adjustable inter-character spacing and adjustable inter-line spacing specifically for cases like this where the target has no reception flow control and unbuffered reception and needs time to deal with each character before the next one is sent. I'm sure equivalent Linux terminal programs will have similar adjustments for ASCII file output.

    However, you've indicated that you would prefer to work with the Linux command line. I don't know how to do exactly what you want to do in pure command line (bash?) script but it might not be too difficult to write a stand-alone script in the Python language (included in most Linux distros) which, when properly prepared, could be executed from the command line just by typing the name of the script (plus any necessary parameter, like a filename) and pressing <enter>, just like any other command line command.

    Python is well equipped for file handling, generating fixed small delays and sending and receiving serial data. Of course you could also do something similar in 'C', if you are familiar with that language.

  10. #10
    Join Date
    Jan 2020
    Location
    South of England
    Posts
    26

    Default

    Hi SH,
    Your right. I hadn't thought it throu. As you say, with flow control a buffer controlled by the proc is required (FIFO). Via the Lx CLI I have a bash script that reads a z80 object file and sends it a byte at a time with a 50ms intercharacter delay, I'm quite familiar with Bash, C, Perl & Awk but not so much with Python, however if I capture a stream created by the N2 "W" command using "cat <serial> > file" then send it back (with intercharacter delays) and try to read it via the N2 "R" command, the read back fails (N2 just hangs).
    I have just finished testing a clock generator, in a couple of days I'll clock the Uart at different speeds so that I can match the Lx baud rate at slow speeds and try to receive/send files with having to add intercharacter delays.
    Thaks for your comments.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •