Ive been following this project and i am finished with all the wiring and the last step was programming the 6502 to deal with the hardware problem of the 65C51 UART in transmitting. I have finally reached the point of the UART working (a search for a wiring error took forever). Maybe someone can help with my understanding. I am using Teraterm as the terminal emulator (which has some limitations) previously used PuTTy. I was able to receive the message transmitted by the 6502 but i was not able to send from Teraterm to the 6502. Tried lots of software amendments without success. Eventually traced it to the comport not being connected, enabled, or maybe just disinterested. Corrected this and everything works. What intrigues me is that Teraterm was able to receive the message transmitted by the 6502 with the same comport problem, but the terminal could not send characters back to the CPU .

What exactly did you do to fix the problem? It wasn't clear from your message.

I have had odd behaviours like this from USB FTDI adaptors, I'm not sure whether it's because I accidentally shorted it out or something like that - but it has happened a couple of times, and disconnecting and reconnecting the USB adaptor has fixed the issue.

Regarding PC-side software, personally I used Teraterm at first, but wanted something Linux-commandline-based, using "screen" for a while as I use that all the time anyway. But eventually I moved to my own custom terminal program written in Python, as it gave me the most flexibility in configuring the port (arbitrary baud rates) and also allows me to write more bespoke server software, to automatically stream files with checksums in a format that's easy for the 6502 to read and check. I've only scratched the surface of what's possible, but would recommend it if you're familiar with Python as it is quite easy to use and, being a programming language, easy to implement custom functionality.

At the risk of running off-topic, I also have my own custom Linux terminal for my Ruby project boards, but for all else, I use minicom - easy to change baud, create profiles for different systems, etc.

And in you are running multiple USB serial ports, then, if you've not already discovered it, /dev/serial/by-id/... is a good way to keep track of multiple devices rather than /dev/ttyUSB0,1,2 or /dev/ttyACM0,...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I also landed on python with the 'serial' library for serial communication. I was looking for a simple efficient way to send binary data to the 6502 machine from the command line (MacOS) and after trying several different things which had one problem or another, python did the job.

Like George I created a simple data format for transfers, mine comprising a 2 byte length, followed by data, followed by a 2 byte checksum using an ancient BSD algorithm that is simple to implement.

Python supports manipulating the serial control lines and I have a serial to TTL that exposes a DTR signal which I use to trigger a reset of the 6502 machine prior to starting the transfer. The 6502 machine boots into a state where it's ready to receive a program upload, so I have a single command that will compile code, reset the 6502 machine, upload and then run the binary all within a few seconds. A huge improvement over pulling out and reprogramming the EEPROM every time.

The main challenge I encountered was data getting lost when the python transfer script exited. Despite writing all the data and calling the python serial 'flush' command, if the python script exited before all data had been transferred, remaining data would be lost. I couldn't find a way in python to check whether all data has been sent and I only have one-way data transfer implemented so am not able to send back an acknowledgement from the 6502 machine. In the end I resorted to calculating how long the transfer will take - based on baud rate, number of bytes and bits per byte including start and stop bits - and then waiting until that much time (plus a 2% buffer) has elapsed after starting to send, before exiting the script. This approach to ensure all data is sent has been reliable, but I'd be happy to replace with something that's less of a hack.

-Phil

Nice, thanks for the details! In my system the 6502 sends the checksum back, and the Python code checks it. The 6502 returns to a mode where it can accept another data block or be told to start execution, so the server can resend blocks of necessary. My checksum is literally adding each data byte to a memory location, then adding that result to another memory location, without clearing the carry at any point during the block of 256 bytes, and both memory locations form the resulting checksum. It is not very good but is very cheap in code size.

After sending an execute command to the 6502 my server entered a standard two-way terminal mode. So it doesn't need to exit the script until I press Ctrl-C.

Mine is much more primitive but achieves the same aim
- assemble to hex image
- convert to binary blob (so it's in something the lvc5183's can understand)
- set the serial port to 19k2
- manually reset the 6502
- cat the blob to the serial port
- start minicom, which resets the serial port to 115k2

Each of these is a single line in the linux console (except the reset; that requires an extra finger ). I really ought to wrap a script around it, but the up arrow makes it no issue.

Neil

Seems like a lot of effort to write your own terminal program, IDK. I've been fighting with ANSI codes on my project for a while so I can have a decently working line editor though so who knows.

I'd personally like to use Teraterm simply because from what I understand implementing X-Modem (or Y-Modem) would be pretty straight forward.

My friend is teasing me a bit about how I'm basically writing a BBS of sorts for my hacked together 6502, and I suppose I am to some degree. XD

The transmit and receive channels on the serial port are separate, so it's possible to have an issue in just one direction. It's even possible to connect just one of those channels for one-directional data transfer (I do this for sensors that periodically report a value to the computer but don't accept any commands). Based on your description, the TX of the 6502 system was making it to the RX of the PC, but the TX of the PC was not making it to the RX of the 6502 system.

It's also possible that the data lines are connected but one side is not transmitting because of handshaking signals telling it not to. If hardware handshaking is turned on, those lines are used to tell the other side "hang on - I'm not ready right now so don't send data to me right now" or "OK - I'm ready for you to send me data" using extra pins on the serial port (such as RTS and CTS). If you have hardware handshaking turned on in your terminal software (either Teraterm or PuTTY), then you need to make sure the hardware pins are wired correctly (best solution) or wired in a way that disables them (essentially saying that it's always OK to send data). When working with 6502 systems, handshaking is often implemented in one direction only because the PC is capable of accepting data at full speed but the 6502 system may need time to process the data it just got before more is accepted.

If you want the PC to ignore the handshaking lines and always transmit, make sure the "Flow Control" setting is set to "none" in the Teraterm serial port setup. This allows you to use a setup with only RX/TX and GND connected between the 6502 system and the PC.

It depends on your personal knowledge and "done that before" sort of thing. In my case I've been writing serial handlers for some 4 decades now so it's relatively easy as I've done it many times before. At the simplest level it's a very small loop taking characters from the serial input and throwing then at the screen and taking characters from the keyboard and throwing them at the serial output. A modern Linux terminal will do all the ANSI stuff for you so there's little to do in that department.

For me, I wanted a terminal that understood Acorn/BBC Micro codes rather than ANSI codes - and do graphics. I already had the graphics and serial code left over from another project (A BASIC interpreter than ran under Linux) so my first try was actually a BASIC program before I simply removed the BASIC part, leaving me the serial and keyboard+graphics part...

Then I added in a "hidden" file transfer means - I request a file from the 6502 side and it comes over the serial line without me going any other keyboard fiddling like telling my terminal program to send because the 6502 told it for me.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks to you and the others. All clearly in a higher orbit than I am. I will ponder your collective wisdom.