I'm having issues employing the PC parallel port to feed data from the Kestrel to the PC.

I found the PC to be entirely too slow in handling any reasonable SPI data throughput. Quite literally, with the PC as slave, and using all user-mode software (I'm not going to write a device driver for something like this, sorry), I could achieve a maximum data rate of about 6 bits per second before she started losing sync. Yikes!

So I decided to add a feedback to the SPI interface to implement fully-interlocked asynchronous data transfer. To trade a single bit on the port, the following steps are taken:

1. Master places next bit to send on MOSI.
2. Master asserts CLK.
3. Slave detects CLK, shifts in MOSI.
4. Slave puts next bit to send on MISO, then asserts ACK.
5. Master detects ACK, shifts in MISO.
6. Master negates CLK.
7. Slave negates ACK after seeing CLK negated.

As with SPI operating mode, the master must know, a priori, whether a device attached to a port is asynchronous or not. If not, ACK can be safely ignored.

It works remarkably well, sort of! Since making this change, I've *never* lost a single bit from the Kestrel, and the data rate (on average) seems to be in the mid-kbps range. Not bad for not having to write a device driver in a thoroughly non-real-time operating system, eh? (BTW, this is also while listening to MP3s, running in the X window system, and having several Internet clients running concurrently in the background. Did I mention how much I liked asynchronous interfaces?)

But, repeatability is flakey, and now, just plain doesn't work at all without "human intervention." What human intervention? Jiggling the CLK wire! For some reason, the PC parallel port *refuses* to see the state of CLK unless I actually jiggle the wire for some reason.

Now, I'm driving the CLK line with the 6522 directly. Is this an OK thing to do? Does the 6522 have the capacity to properly drive a PC parallel port input without the use of external buffering?

Note that it's not the cable, or the wire leading up to the cable. I've verified this is the case regardless of signal input, and regardless of which pin I attach it to on the parallel port.

NOTE: I suspect that it worked in the "synchronous" version because the VIA's output was always changing -- it probably was relying on capacitance somehow to get the same effect as jiggling the cable in asynchronous mode.

So, . . . I'm at a total loss. And if I can't get past this, then the Kestrel project is essentially dead. With no way to communicate to it, there is no further point in persuing its development.

no kiddin'-- so you don't have anything other than a PC to interface with? I'd suggest putting a 6551 and line driver/receiver IC on the Kestrel, but your PC may be too new to have an RS-232 port.

What kind of 6522 do you have? If it's CMOS, it definitely can drive the PC's port lines more than hard enough without buffering.

Was the PC doing fewer things at a time when it worked? I wonder if it doesn't get around to looking at the parallel port often enough.

W65C22SP-10.

I tried ganging multiple VIA pins in an attempt to drive the PC port with additional current. It failed, as corroborated by your reply.



I don't think you understand -- because it is a fully interlocked protocol, one and only one pin changes at a time. First CLK, then ACK, then CLK, and ACK again (00, 01, 11, 10, repeat). Each side waits until the other side changes its state. The whole purpose of this exercise is *precisely* to eliminate timing from the loop in any way, shape, or form. Once the Kestrel modifies CLK, it *waits* for the ACK. Likewise with the PC, once it adjusts the ACK, it *waits* for the CLK to change. Etc.

Regarding 6551s -- no can do. Besides it requiring me to invest more money, more wiring, running a whole different cable from the back of the PC, completely overhauling the address decoding circuitry, and additional time in the form of me waiting for parts to arrive, it also requires more breadboard space, which I don't have, and I'm not willing to spend another $15 for a 4th breadboard just to house one more chip.

I cannot and refuse to believe that the PC parallel port is dysfunctional.

I offered this up before, and I'll offer it again:

Way back when I built my SBC-1, I also used the parallel port for my terminal interface. I used a similar protocol to yours as well and it worked rather well with good speed. Here is a link to my rather basic web page.

http://www.softcom.net/users/darylr/sof ... cterm.html

I can provide you with the 65c02 code and the PC terminal code (MS Quick BASIC and also a C version)

This might help shed some light on your problem. Let me know if you are interested.

Either way, don't get discouraged. For every problem, there is a solution.
Hang in there!

Daryl

Thank you, but this is a hardware problem, not a software problem. The software works, provided I keep jiggling the wire.

That being said, I did temporarily find a sweet-spot where my ack-loop test code (code which repeatedly cycled through the full clock/ack cycle) went fast enough to pull off an equivalent speed of 23kbps. Now if only I can get the physical connection stable.

This sounds to me like a grounding problem. Are you sure that the ground on your 6522 is properly connected to the PC's parallel port ground? Some PC parallel ports fail to connect all the pins that ought to be ground, according to the spec. So make sure you connect all possible grounds (I think it's pins 18-25, but do check first) and not just a single ground wire.

As for the PC parallel port being dysfunctional, I think you may find that it is. Remember that you're using it in a mode that it wasn't designed for.

It works to drive the IPL circuitry just fine. The voltage swings are full, so the ground pins I've connected do function as grounds.



This isn't true; the parallel port has always just been a direct connection to an 8255 PIO chip, or its equivalent (port A is output, port B is input, and port CH/CL are both set to output). The EPP/ECP ports don't use an 8255, but do use a compatible replacement, as it preserves the data directions.

I'm still probing around. I hope I find the solution to this.

Well, I don't know what I did, but it apparently had something to do with the power to the circuit. Because I turned the circuit on today, re-uploaded the software, and ran the counter-part software on the PC.

The result was that it worked perfectly. Reliably. I nearly hit the connector with a hammer, and it didn't affect communications between the PC and the Kestrel at all. The speed was measured to be 5000bps on average, with peaks up to 6250bps.

So, my best guess is that it had something to do with the VIA chip itself. Somehow, PB6 got into some weird state where it wouldn't work right, until it was power cycled. It seems to be working fine now.

The nice thing about this is, I have a SPI port that can be used either asynchronously or synchronously. I'm working the system software around these capabilities.

Now, the next step is to write the one last proof-of-concept for this -- the infamous ECHO SERVER... ;D

Well, I'm glad to see that my parallel port isn't shot to hell and back -- I just made myself a very simple AVR ATmega8 programmer using the parallel port (it uses SPI port to program with), and it works like a champ, and is able to read back from the device without problems.

The difference here is I have 1K resistors in series with the parallel port pins for isolation, and it seems to work relatively well. Now that I have the adapter made, I can use it to talk to a future Kestrel if I didn't want to go USB (which is still my plan).

I expect the next Kestrel design to have a few ATmega8s in them.