Serial ??

[okwatts]

Hi, Not sure if this is you or David but trying to send files (in CP/M65) by Xrcv complains there is no serial available, will the use of the second USB allow for this? I've ordered boards for the nanocomp so I hope so. Other than that I am trying out CP/M65 and look forward to more updates.

[venomix666]

Hi!

I submitted a pull request with a serial driver for CP/M-65 yesterday and it was merged last night, so if you get the latest build of CP/M-65 together with the latest bitstream file for nano6502 you will have a serial driver - it is however not connected to the USB UART used for keyboard input but instead to the UART header on the nanoComp board.

The interface on that header is just a 3.3V UART. The pinout is made to work out of the box with the TTL-232R-3V3 cable from FTDI, but any USB to 3.3V UART cable will work if you connect the pins up correctly.

I did it this way mainly because I wanted a general purpose UART which can be connected to any computer (or microcontroller board etc.) and not just be used for file transfer, and I wanted to keep the USB UART keyboard input capability.

It would be possible to write a serial driver which allows file transfer over the USB UART, but the CP/M-65 driver model only allows for one serial port currently so I can't add this while keeping the driver for the other UART. David has mentioned that this may change at some point in the future, but that requires a bit of an overhaul of the serial driver specification.

So, for now the most straight forward way is hooking up a TTL-232R-3V3 cable to the UART header on the nanoComp if you want to use the serial port from CP/M-65.

It's nice to see this project being used by someone, let me know if you have any issues or ideas for future updates.

[okwatts]

Thanks for the explanation. The boards have shipped, now just waiting for them and to get a few parts. I'll let you know how I make out..

On Thu, Sep 5, 2024 at 11:37 PM Henrik Löfgren @.***> wrote:

Hi!

I submitted a pull request with a serial driver for CP/M-65 yesterday and it was merged last night, so if you get the latest build of CP/M-65 together with the latest bitstream file for nano6502 you will have a serial driver - it is however not connected to the USB UART used for keyboard input but instead to the UART header on the nanoComp board.

The interface on that header is just a 3.3V UART. The pinout is made to work out of the box with the TTL-232R-3V3 cable from FTDI, but any USB to 3.3V UART cable will work if you connect the pins up correctly.

I did it this way mainly because I wanted a general purpose UART which can be connected to any computer (or microcontroller board etc.) and not just be used for file transfer, and I wanted to keep the USB UART keyboard input capability.

It would be possible to write a serial driver which allows file transfer over the USB UART, but the CP/M-65 driver model only allows for one serial port currently so I can't add this while keeping the driver for the other UART. David has mentioned that this may change at some point in the future, but that requires a bit of an overhaul of the serial driver specification.

So, for now the most straight forward way is hooking up a TTL-232R-3V3 cable to the UART header on the nanoComp if you want to use the serial port from CP/M-65.

It's nice to see this project being used by someone, let me know if you have any issues or ideas for future updates.

— Reply to this email directly, view it on GitHub https://github.com/venomix666/nano6502/issues/3#issuecomment-2333348499, or unsubscribe https://github.com/notifications/unsubscribe-auth/APALSONPHRURQEWJIH2G3PTZVFEQ5AVCNFSM6AAAAABNXQBTP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZTGM2DQNBZHE . You are receiving this because you authored the thread.Message ID: @.***>

[okwatts]

Ok I tried just using a FTDI on the breadboard using 0.3 and the CP/M-65 from the last dev build. I'm using picocom on linux (Mint20.3) with the sx plugin. XSEND seems to work but XRECV doesn't seem to ACK the blocks. The first block actually looks correct and is repeated partly then it aborts. Also it appears that the arrow keys aren't recognized in QE which I'm pretty sure worked before this latest. Not sure if the driver switch affected this or it's a CP/M-65 problem. Also noted that occasionally if I check things like a DIR B: and then even though the prompt indicates A> if I try say DINFO i get DINFO? as a response as if the drive is still set to B; If I type A:DINFO then it operates and correctly indicates the drive in the following prompt. The xmodem transfer issue is a bigger deal. I also tried with TeraTerm in windows but the send never starts (it uses Checksum) maybe CP/M uses CRC?

[venomix666]

Thanks for testing, I'll look into the xmodem issues. I have just tested it quickly and it worked, but it may be something marginal with the timing as the UART is running at 115200 with a one byte buffer. When I have time I'll test lowering the baudrate or adding more buffer space in the FPGA and see if that makes it more stable.

Regarding the arrow keys, there currently is no support for arrow keys in CP/M-65 so that cannot have worked before. There is an open issue discussing adding this to the SCREEN driver on the CP/M-65 github. You have to use the good old vi navigation keys (h,j,k,l).

There were a lot of changes to the multidrive support code just recently, see this issue, so it is not unlikely that there are still some bugs there.

[okwatts]

Thanks for the reply, I guess I did hallucinate about the arrow keys. I looked at the qe.c source and found the key assignments, now I just need to train my fingers(and brain. It's been awhile since I used a terminal! not a PC.) In regards xmodem, it appears that xrecv doesn't wait for the start of transmission, so I have to setup the send first then initiate xrecv. I'll try and compare to other xmodem transfers on CP/M and DOS/65.

[venomix666]

I found the problem, it was a combination of timing with the baudrate being too high, and needing to put in a small delay in the non-blocking read routine in the bios when there was no data available. Running at 9600 BPS and with the delay I can send large files in both directions without any issues. Before this fix it worked more sporadically and only for smaller files.

The issue with xrecv having to be run after setting up the send remains, so that problem is most likely in the xrecv code and not in the serial driver for nano6502.

I need to do some more testing and cleanup before committing, but there should be updated images of both the bitfile and CP/M-65 in the coming days.

[okwatts]

Thanks for the quick response. I await the updates!

On Sat, Sep 7, 2024, 8:29 a.m. Henrik Löfgren @.***> wrote:

I found the problem, it was a combination of timing with the baudrate being too high, and needing to put in a small delay in the non-blocking read routine in the bios when there was no data available. Running at 9600 BPS and with the delay I can send large files in both directions without any issues. Before this fix it worked more sporadically and only for smaller files.

The issue with xrecv having to be run after setting up the send remains, so that problem is most likely in the xrecv code and not in the serial driver for nano6502.

I need to do some more testing and cleanup before committing, but there should be updated images of both the bitfile and CP/M-65 in the coming days.

— Reply to this email directly, view it on GitHub https://github.com/venomix666/nano6502/issues/3#issuecomment-2335516885, or unsubscribe https://github.com/notifications/unsubscribe-auth/APALSOLNZB5MMFPZFUIXC6TZVMLWNAVCNFSM6AAAAABNXQBTP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZVGUYTMOBYGU . You are receiving this because you authored the thread.Message ID: @.***>

[okwatts]

Hi since David has not yet incorporated the latest pull request, I tried just using 0.3.2 for sending with xmodem at 9600. I still don't get successful transfers. I only see the first block in the received file and all the sends are NAKed. I have been using picocom with the sx addin. May I ask what you used to test the transfers? xsend seems to work correctly.

[venomix666]

Hi,

You need the updated CP/M-65 BIOS for it to work.

I added the CP/M-65 binaries from my build to the nano6502 so that you can try them even though the pull request isn't merged yet. Please try one of the img-files from here and see if it works better: https://github.com/venomix666/nano6502/releases/tag/v0.3.2

[okwatts]

Thanks works fine at 9600.

[okwatts]

okay spoke too soon, it worked the first time. Then tried upping the baud rate 19200 worked but 38400 didn't. thereafter going back to 9600 didn't work. If I power down for a minute and retry then 9600 works again.

EDIT: I tried on windows with Teraterm and it seems to work just fine there.This is a real pain because I prefer to work in linux and while I have had trouble in the past with some systems using the sx plugin to picocom I have yet to find another terminal program for linux that is like Teraterm.

[venomix666]

Thanks for testing!

I added a small fix, clearing the rx-buffer on open/close of the UART, and now it works fine for me with sx on Linux all the way up to 115200 bps with several consecutive transfers. I have updated the image files in the release, give it a try and see if it works for you as well: https://github.com/venomix666/nano6502/releases/tag/v0.3.2

[okwatts]

Thanks works for me at 9600 I'll try other bauds soon. Works for me at 115200. Thank you!

[venomix666]

Great! Then I'll mark this issue as closed.