Greetings,

I built a DB25 cable as described in the ref manual but I get the same behavior as with standard db25-db9 cables and DB25-DB25 cables with 25 to 9 adapters, also with and without a null modem but I get an error when attempting to communicate with the SYM-1. It accepts a Q and returns a dot but any attempt to enter a command, such as M 200, results in returning the M and an ER 13 (I assume the error references a CR, either missing or not).

Do I need to have a negative voltage supplied for modern PC com ports?

I've tried various baud rates with 8N1, no handshaking, and have changed other parameters in the terminal program as well.

Thanks,
John

It'll be helpful if you can post (or link to) all the pertinent info. For example, I'd like to see this reference manual, as well as the wiring of the cables you mentioned. Does the SYM-1 even have a D-shell connector? I thought it just used pins on the edge connector.

If the SYM-1 has the same serial interface as the KIM-1 -- and I seem to recall it does -- then it's a current loop, not RS-232. But I don't trust my memory when it comes to these details.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The manual is here: http://www.6502.org/trainers/synertek/m ... refman.pdf

The Sym-1 has both current loop and RS232. For the RS232 connection to a PC it needs a negative voltage.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Update and clarification.

I got it working. I had a wire wrap female db25 connector that I soldered into the Sym-1 board and made a serial db25-db25 cable according to the sym-1 reference manual (available here at 6502.org) and connected it to a PC com port through a db25-db9 adapter (I also tested a standard db25 to db9 cable and it works fine as well).

I initially used the "Termite" terminal program with the com port and serial cable connection with issues and errors. Overnight (I do a lot of mindstorming in bed before, during, and after sleep) I figured I'd try a different terminal program so I downloaded and tested Tera Term - this solved my problem.

Bottom line is the solution of adding a db25 connector to the Sym-1 board and using a standard db25-db9 cable with Tera Term works fine. I did NOT have to add a negative supply and no jumper changes were needed.

My next step will be to add Basic and RAE ROMs. I suspect the hurdle there will be in getting modern ROMs to work with an adapter and getting the jumper settings just right.

Thanks for your feedback and attention.

John - N0HJ

Thanks Klaus. For the PC I am using, I did not need to supply a negative voltage. I'll report back if I discover other PCs that do require the negative input.

Hi Jeff,

As mentioned, the ref manual is here and has the wiring diagram for the serial cable. I ended up not actually needing to wire a cable as a standard 25-9 cable works well. The Sym-1 has pinouts to directly solder in a db25 connector as well as a separate 14-pin header connection that can be used as well. - john

Some have apparently bent the rules to accept somewhere near 0V as a "mark;" but the RS-232 (then EIA-232 and now TIA-232-F) specifications say that the receiver must accept anything from -3 to -25V as a mark, and +3 to +25V as a space, and that -3 to +3V is "no-man's land." The transmitter is to put out between -5 and -15V for a mark, and put out between +5 and +15V for a space.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Good to know. I'll look for a dual supply and see if it works out.


John

I do this all the time with several different PC/laptops and several different old 6502 computers (SYM, OSI) and have never needed to add a negative supply. As far as I can tell, the typical PC style RS232 port has never conformed to the EIA standard.

_________________
Bill

Recognizing 0 as mark is not outside of the standard. As was mentioned, -3 to +3 is "no man's land", i.e. undefined by standard.

That doesn't mean a compliant implementation can not recognize it as a mark -- it's undefined, the implementation can do anything it wants with "undefined". The burden is placed on the transmitter, someone SENDING data with those values have no expectation (by standard) of it working.

It's the message on the wire that's not compliant with the standard, not the PC (in this case).

I don't really want to get into an argument here, but if the PC is recognizing 0 as mark, then it is recognizing "undefined" and treating it as something defined. That is contrary to the standard. Standards mean something, that is why they are standards. Something we can all agree on and live with. Undefined = undefined ... undefined <> defined, or mark, or space.

I agree, the signal is non-standard too. However, if you do the opposite and send -5V as mark and 0V as space, the PC interface will not work.

_________________
Bill

How, then, should the PC react to a voltage in the undefined range? What value should it return when the program on the PC tries to read the port?

See, that's the game. If there's an answer to that question, then it's not "undefined".

When a standard is implemented, there's no such thing as "undefined". The implementation has to do something. Return a value, throw an error, catch fire, something. The realm of "somethings" that can be done when the result is undefined is broad. But just as much as an implementation can behave badly, send random values, etc. for undefined behavior, it can equally rigidly define what happens when something "undefined" happens. Undefined by standard doesn't mean undefined by implementation. No matter how the implementation behaves, it can conform to the standard, as the standard can not test undefined behavior.

Since the characteristic behavior of a conforming implementation to undefined behavior is undefined, the implementation can do anything it wants, including returning consistent values. As a consumer of the implementation, if you want your work to be portable, you should not rely on any guarantees provided by the implementation for undefined behavior.