Hello, all,

This is my first post here, but I've been lurking and learning from the forum for a while, so I thought I would share something I've done in case it's helpful to other newbies. Thank you to the community for all of the amazing information and code that's so generously shared!

For my first 6502 build, I built Jonathan Foucher's Planck6502, which runs Tali Forth 2 as its native OS. This has opened a whole world of new things to me: Forth, 6502 assembler, hardware debugging, etc. It's been a blast.

Right now, I'm trying to learn how to create ROMs and I'm also trying to troubleshoot why my Planck doesn't always reliably accept pasted text from my terminal program. The Planck is built around a WDC 65C51 for its console and so I've been catching up on years of posts about that ACIA and its challenges. As part of this learning process, I've ported Floobydust's MicroMon to work on the Planck. Thank you to Floobydust for writing the Micromon and also sharing how to adapt it to work with a delay-loop based send in place of the original interrupt-driven one.

I also converted the assembly code to compile with ca65. I've posted the project on Gitlab in case it might be useful to other beginners.

Best wishes,

Ben

Welcome - and thanks for sharing your work!

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

Hi Ben,

Thanks for trying out my Micromon code... it's pretty simple and does work best using a properly functioning 6551 or 65C51. I would urge you to try and find an older NOS 65C51 from Rockwell or other sources. Using the current WDC chip does result in some coding limitations and such.

Looking at the Plank schematics, the serial port is not wired for CTS/RTS handshaking... but ties CTS active (gnd) and uses DSR to the Serial-to-USB adapter. My code is setup to use CTS/RTS handshaking for flow control. That might be part of the problem. Also, you're not describing the setup you're using to interface with, nor the terminal program. Doing a drag to paste text to the terminal window can be sketchy from a timing standpoint. Most terminal programs will allow you to add a pacing value, i.e., it will only push characters at a limited rate, which can help with overruns.

Also note that is such cases, the monitor code is echoing these characters back to the screen, which is limited via the delay routine to send characters, in which case everything is slowed down. My older SBC system uses a 65C22 and 65C51 I/O running at 4MHz... and can handle Xmodem transfers without issue.... setup is for CTS/RTS flow control.

Hope this helps.

_________________
Regards, KM
https://github.com/floobydust

Hello BDD and Floobydust,

Sorry for the delay in responding. I think I'm finally making progress. I've been attempting to add the delay-driven send/interrupt-driven receive code back into the Planck's software over the last few days and I've finally had some success. I'm now able to paste in a 200+ line Forth program without errors. The Planck is running at 6Mhz and the baud rate is currently set to 112500. I do have to use a 3ms intra-character delay and a 10ms end-of-line delay. Still this is progress!

The ACIA is a WDC 65C51. Jonathan's design is intended to run at 12Mhz and I think these speeds rule out 6551s other than WDC. I did buy a used Rockwell 2Mhz chip (I didn't see any 4Mhz parts on Ebay when I was looking); not surprisingly, it didn't work. I've also just received some 16550s and I hope to put together an add-on card for the Planck that uses one of those at some point.

I imagine that this would all have been easier if I hadn't chosen such a fast machine as my first build! Also, I should mention that Jonathan has not seen the same character dropping issues in his build, so there may be other factors at play.

BDD, thank you for your welcome! In response to your question about trying with slower baud rates; I had experimented with slower baud rates although I did not go down to 1200 baud. I also experimented with character delays on send. For error-checking, I was just sending formatted blocks of text that made it easy to spot when a character was dropped (this was after not being able to reliably paste source code into the Planck).

Floobydust, my main computer is a MacBook Air running the latest version of MacOS. I'm currently using a communications program called tio (https://github.com/tio/tio), which I like quite a bit as it's small and mostly stays out of the way. It does support intra-character and end-of-line delays. I currently have it set to 3 ms between characters and 10 ms at end of line, and this is now successful, as mentioned above. I have also used CoolTerm and minicomm. Communication is via a USB to TTL cable. I highlight text in VIM, copy it to the system clipboard and paste into the terminal window. I run tio inside of terminal.app on the Mac.

The send/receive software setup that I have now is mostly based on this post from SamCoVT in which he adapts Garth Wilson's interrupt tutorial. Of course, Sam has the use of a working Rockwell 6551, so I subbed in your delay loop and a simple delay-based send in the transmit section. It uses a 256 byte circular receive buffer.

I have attached a stripped-down version of the current (mostly-working) code that I'm adding back into Jonathan's software for his Planck computer, just so you can see where I'm at.

Thanks for noticing the lack of CTS/RTS on the Planck design. I might try wiring that up, because currently, if the receive buffer gets too full, it seems to just freeze and it definitely freezes with no character delays in between characters. I soldered a couple of bodge wires between pin 8 and rts and pin 9 and dsr, but it's late for me here and I'll have to have another go tomorrow.

Thanks for taking an interest!

Ben

I use RTS/CTS handshaking on my board (I've built three of them now) and it's been rock-solid at 38400bps (using an overclocked (3.6864MHz) Rockwell R65C51) with no interchar delays, no line-ending delays, and with either a 4MHz or 7.3728MHz system clock. If your handshaking is working properly, you just shouldn't need any software delays - the hardware will do the delays if they are needed and only when they are needed.

The fact that you don't have CTS/RTS wired helps to explain the writing of a #1 into ACIA_COMMAND in your source that you changed to #0 to indicate your buffer is getting full - I'm using RTS/CTS and not using DTR for handshaking, so I leave DTR (controlled by bit 0 in ACIA_COMMAND) asserted all the time.

(Sorry, this is now pretty far off my original post)

I've now modified my Planck to support RTS/CTS flow control. I've attached a graphic with a shot of the before and after schematics. I used SamCoVT's SBC schematic as a guide. When using CoolTerm, I can see it blinking the RTS light as the buffer fills with data. I'm connecting at 19,200 N81.

I've also written a very basic test file generator in Python. It creates a file with lines of random text along with a per-line checksum (Thanks for the idea of test files, BDD!). The idea is to read these pasted-in lines using a Tali Forth program on the Planck. That code calculates a checksum and compares it to the checksum supplied on each line. I've attached those in case they are of interest. I was able to paste a 2000 line test file into the SBC and there were no checksum errors, even with no intra-character or end-of-line delays inserted.

There is still significant display corruption as the screen cannot be redrawn fast enough to keep up with the data. I can live with that if the data is loaded correctly. Also, given that I'm a Forth and 6502 newbie, I'm sure the code could have been written more efficiently. And ... I can always add in a new ACIA on down the road.

Thanks, everybody -- there is so much to learn!

Because it's your thread, you are 100% allowed to meander. If you think it appropriate, you can edit the subject of your first post to "relabel" the entire conversation.

It sounds like you have working handshaking, so I think you are 95% of the way there.

There shouldn't be any corrupted characters - your serial routines should be able to echo all of the characters just fine, and the handshaking should pause RX if you need more time handling TX. I believe you have a WDC 65C51, so you will want to make sure you have a proper delay of at least 10 bit times after sending each character. It takes 10 bits to send a byte (start bit + 8 data bits + stop bit), assuming you are not using parity. Your description sounds like your delay is not long enough.

What speed are you using for serial now, and how are you creating the delay?