PIAs (6520): They are not made the same, after all...

[Faicuai]

...At a first glance, they all look alike, same suppliers and even close-enough manufacture dates... They will even PASS SuperSalt tests (with external HW fixture, not the dumb-ass stand-alone cart)!

 

...In short, all fine-and-dandy UNTIL... you hook them up to the XEP80, and drive them with Avery's turbo-driver, and that's when they poop-out!

 

So here's the summary:

 

1. Rockwell R6520AP, DateCode 8052: craps out at high-speed.

2. Rockwell C014795-12, R6520-26, DateCode 8308 (on brand-new, spare 800 MoBo): craps out at high-speed.

3. My 2nd 800XL (Rev. C MoBo, ALPS keyboard, HongKong, identical to my first 800XL): craps out at high speed (have not opened it yet).

4. My 1st 800XL (Rec C, MoBo, ALPS keyboard, HongKong): Rockwell C014795-12, R6520-26, Date Code 8336: WORKS at high speed (!!!)

5. Spare #1 from my spare-back, Rockwell CO14795-12, R6520-26, DateCode 8334: WORKS at high speed!

6. My Made-in-USA 800 / Incognito, late 1983 (unknown PIA): WORKS at high speed!

 

Since I noticed that I was running short on PIA spares, I ordered a pair of Motorola's MC68B21P and will test those upon arrival. Let's see how the Motos do under high-speed transfer.

 

So there you have it. There are unexpected variances in performance, when pushed to their limits!

Edited June 3, 2020 by Faicuai

[Rybags]

High speed - is this referring to bit-banged serial comms?

 

For analysing the Atari video signal I used PIA output as a trigger.  I found fairly quickly that 1 > 0 transitions were fine but 0 -> 1 transitions had lag and possibly inconsistent timing.

Likely external resistors cause ramp up delay (or maybe the PORT outputs rely on external pullups to begin with?)

[Faicuai]

43 minutes ago, Rybags said:

High speed - is this referring to bit-banged serial comms?

 

For analysing the Atari video signal I used PIA output as a trigger.  I found fairly quickly that 1 > 0 transitions were fine but 0 -> 1 transitions had lag and possibly inconsistent timing.

Likely external resistors cause ramp up delay (or maybe the PORT outputs rely on external pullups to begin with?)

I also thought, at first, about possible variances on the passives linked to the lines used as input / output (that would have been really bad, indeed)... I even thought that Antic timings may have been involved, since Avery's high-speed XEP80 driver does require timed-data / events from Antic itself.

 

...but you may be surprised to know that Test #1 AND Test #5 above were actually performed on the same (and pretty old) 800 MoBo, circa 1980... with a partially DEFECTIVE Antic... As soon as PIA was replaced, BANG! High-speed traffic worked like a charm with the XEP80. You will not see this with standard-speed XEP drivers, though... they will ALL work on all PIAs (!!!)

 

That, plus the fact that my brand-new-and-pristine spare 800 MoBo (Test #2) failed the high-speed test, drove me to conclude that PIA performance-variances are at the heart of this... (I have been testing for quite some time, already).

 

Will report on those Moto bad-boys, and see how they do under stress...

Edited June 3, 2020 by Faicuai

[chevymad]

I believe Dropcheck's Eprom burner also requires certain PIA's to function correctly. 

[phaeron]

3 hours ago, Faicuai said:

I also thought, at first, about possible variances on the passives linked to the lines used as input / output (that would have been really bad, indeed)... I even thought that Antic timings may have been involved, since Avery's high-speed XEP80 driver does require timed-data / events from Antic itself.

It only synchronizes to ANTIC to ensure precise timing, and systems are not known to have variance in ANTIC timing anyway (presumably because such variance typically results in not working).

 

It is true that high-speed XEP80 operation puts more stress on the PIA to let its output lift high more quickly, which is limited by capacitance and the pull-up resistor. It may be possible to apply precompensation to start 1 bits earlier and give better margin.

 

I have a symmetric 31.5KHz version in the works that would be interesting to try in this scenario too. Have not scoped the input line, but I wouldn't be surprised to see similar effects in the receive direction as well.

 

[Faicuai]

25 minutes ago, phaeron said:

It only synchronizes to ANTIC to ensure precise timing, and systems are not known to have variance in ANTIC timing anyway (presumably because such variance typically results in not working).

 

It is true that high-speed XEP80 operation puts more stress on the PIA to let its output lift high more quickly, which is limited by capacitance and the pull-up resistor. It may be possible to apply precompensation to start 1 bits earlier and give better margin.

 

I have a symmetric 31.5KHz version in the works that would be interesting to try in this scenario too. Have not scoped the input line, but I wouldn't be surprised to see similar effects in the receive direction as well.

 

 

Sounds like a plan!

 

Are you sampling input-signals on PIA pins, directly? (FORGOT: it may be good to be able to test BOTH ports #1 and #2!)

 

I may grab my little stash of parts (and MoBos) for testing....

 

 

We should be well covered in case we find unexpected snafus.... (extra offending PIAs are not shown there...)

 

 

Edited June 3, 2020 by Faicuai

[thorfdbg]

15 hours ago, Faicuai said:

So there you have it. There are unexpected variances in performance, when pushed to their limits!

That's really due to the way how the PIA ports work. PIA has two ports, port A and port B, where the A side handles the joysticks, and B which handles the MMU (or the joystick on the old machines). The difference is that Port A has a single ended output driver where a single transistor can pull the signal to 0, but there is only a resistor to drive it up to 1. Thus, if there is capacity as load on the line, it takes longer to transition from 0 to 1 than from 1 to 0, and the time depends on the internal resistor. Port B is an active push-pull output, with transistors switching in both directions.

 

Looking back, it would have been better to use Port B for the joysticks and Port A for the MMU, but it is too late to fix that, and it is a historic accident as the A side reads the first two joysticks of the old model which are identical to the joysticks of the XL series.

[_The Doctor__]

ports 3 and 4 were used for many wonderful things, hard drives, networks, loaders, electrostatic art pads, you name it. so it was great the way it was on the 800 it just sucks for the XL/XE's

[ChildOfCv]

15 hours ago, Rybags said:

Likely external resistors cause ramp up delay (or maybe the PORT outputs rely on external pullups to begin with?)

Port A on a 6520 uses pull-ups on each pin that provide 1.6mA, and can sink 1.6mA each.  That's considered to be one TTL load, so not a lot.  Port B uses full drive, but has similar current handling.  Additionaly, it claims that port B can only output 2.4V.  At 1.6mA, it drops to 1.5V output.

 

Clearly, if you plan to use this as a serial port, you need a buffer on the output pin(s).

 

6521 provides about double the current of the 6520, so at least there should be some improvement.

[ChildOfCv]

16 hours ago, Faicuai said:

So there you have it. There are unexpected variances in performance, when pushed to their limits!

When pushed to the limits, there will always be unexpected differences.  They have a defined envelope of required functionality.  Outside of that, you are at the mercy of the design differences, manufacturing variances, etc.  It's best not to design beyond the chip's well-behaved specs for general use.  For 1-offs, well try a few and have fun.

[Faicuai]

2 hours ago, _The Doctor__ said:

ports 3 and 4 were used for many wonderful things, hard drives, networks, loaders, electrostatic art pads, you name it. so it was great the way it was on the 800 it just sucks for the XL/XE's

You bet.

 

Other things were already great on my 800... and also ended up sucking on my XLs, I'll have to admit.

[Faicuai]

1 hour ago, ChildOfCv said:

When pushed to the limits, there will always be unexpected differences.  They have a defined envelope of required functionality.  Outside of that, you are at the mercy of the design differences, manufacturing variances, etc.  It's best not to design beyond the chip's well-behaved specs for general use.  For 1-offs, well try a few and have fun.

Well, I am not really sure about that, as I have not seen any document or file, yet, that clearly states the (bit-wise rated / tested) serial-throughput specs of PIA.

 

Furthermore, it seems that everything else on the system (except d-RAM refreshing) can be put to work to its nominal clock-soeed limit, with no hiccups... except PIA (?)

Edited June 3, 2020 by Faicuai

[_The Doctor__]

6521 from the manufacturer... I think they go for 7'ish retail...

http://westerndesigncenter.com/wdc/w65c21-chip.cfm

perhaps the s series...

 

oh and here's an old R6520xxx sheet from '93

rockwellR6520xxxpia.pdf

Edited June 3, 2020 by _The Doctor__

[drac030]

I think I stumbled upon this issue once, long time ago (1992?). I connected two Ataris via a cable connected to the joystick port 0 of both machines. I used an asynchronous protocol to send data: out of the 4 bits available, I used two as data bits and the two others for handshaking. I was testing it sending GR.8 bitmaps from the one Atari to the other.

 

Everything worked fine until I decided, to save (IIRC) 2 cycles in the handler on either side, that I should use 0 instead of 1 as the handshaking value (previously 0 on the handshaking line meant that no data is available on the data lines, 1 that it is). And then the receiver started to lose "1"s which were set onto the data lines together (one STA) with the zeros on the handshaking lines by the sender. Some 1s sent were received as 0s.

 

My conclusion then was that apparently the zeros are transmitted faster than ones via the PIA port

 

[phaeron]

1 hour ago, Faicuai said:

Well, I am not really sure about that, as I have not seen any document or file, yet, that clearly states the (bit-wise rated / tested) serial-throughput specs of PIA.

 

Furthermore, it seems that everything else on the system (except d-RAM refreshing) can be put to work to its nominal clock-soeed limit, with no hiccups... except PIA (?)

You won't find such a direct spec, because it depends on the PIA and whatever's connected to it. The PIA will happily drive the port lines cleanly at 1MHz+ if an appropriate load is connected to it. The joystick port circuitry, on the other hand, is designed for protection and noise immunity rather than speed. Doing high-speed I/O through it is like driving a fully loaded car with a trailer attached -- it will not respond as quickly as usual.

 

Also, there are other systems in the Atari that are affected by similar analog effects. POKEY and GTIA, for instance, have issues with their analog outputs where the output does not always transition cleanly within one cycle or pixel time. It's just that in those cases it results in barely noticeable artifacts instead of something not working.

 

27 minutes ago, drac030 said:

My conclusion then was that apparently the zeros are transmitted faster than ones via the PIA port

This is actually true, due to the much slower pull-up. Signal at the joystick port when driving the XEP80 at 15KHz:

 

 

A 1 bit is sensed once the signal rises above the threshold for the receiver, for which there is also some variation. Typically the receiver samples the serial line at 1/2 bit cell offset from the leading edge of the start bit, so there is a difference between using 0->1 and 1->0 as the start bit transition. The curve seen here is an exponential decay curve -- a type of curve which shows up everywhere in analog signals.

 

[Faicuai]

1 hour ago, phaeron said:

You won't find such a direct spec, because it depends on the PIA and whatever's connected to it. The PIA will happily drive the port lines cleanly at 1MHz+ if an appropriate load is connected to it. The joystick port circuitry, on the other hand, is designed for protection and noise immunity rather than speed. Doing high-speed I/O through it is like driving a fully loaded car with a trailer attached -- it will not respond as quickly as usual.

 

Is 1Mhz the clock-speed at which they are driven on the Atari-8bits?

 

In any case, your comments gave me a simple idea:

 

Assuming we can run a directed, controlled loop-back test from (say) J-port 1 to J-port 2 (or viceversa, or, even better, by crossing Tx and Rx on the very same port we test), would it be possible to code a small pogram that would start with a default set of timing parameters, fire 8-bits under such set, read whatever PIA receives back, compare intent-vs.-actual (maybe 1,000 times per comparison-cycle), and if equal, move on to another set of timing parameters, and repeat whole cycle until it blows up?

 

In this way, we could auto-tune effective port performance (resident PIA + passives) on any given host, and possibly feed resulting timing parameters to XEP80 driver before or after it is installed and relocated... This would also allows us to find precise performance differences between PIAs, assuming everything else (e.g. host) constant...

 

Just a thought...

 

(I have the Port-to-Port jumpers from SuperSalt HW kit, but these could be very easily built by cannibalizing and old Joystick cable...)

 

 

Edited June 3, 2020 by Faicuai

[_The Doctor__]

sort of,

in the loop back configuration instead of using a test set, you will see how fast you can go with the cumulative affects of the ports their circuitry as well as full loading both in and out on the PIA... I think the 800 would give the best results going from adapter side a to b, as in port 1 to 3 or 2 to 4 etc....

 

doing the same as a test set, the best measure is to bit bang data out and capture the stream until you see errors.

then do the same going in to the Atari.

 

[_The Doctor__]

there's also this to consider, it's doubtful the XEP80's wire is shielded or twisted and it's interface might be limited as well...

[ChildOfCv]

So, this is the definitive reason for the speed problem:

 

 

A resistor, capacitor, and inductor on each pin.  Likely to protect the hardware from abuse, but it has the effect of limiting the throughput of the 6520 if used as a serial comm

[Rybags]

I'm fairly sure I discovered it because it wasn't consistent.  I was just using PA output as a trigger to be able to view a scanline worth of luma on a CRO.

There was jitter which made it hard to view so I changed to a 1->0 transition and as illustrated in the previous capture pic, worked fine.

 

For comms, a workaround could be to use a clock pulse that goes 1->0, realistically you'd probably want a few cycles to allow for jitter + reasonable amount for the receiving device to detect and read the data.  Given it's a CPU driven thing and affected by DMA, the limit on how much data you could bit-bang or send in parallel probably wouldn't be greatly affected.

[Faicuai]

15 hours ago, ChildOfCv said:

So, this is the definitive reason for the speed problem:

 

 

A resistor, capacitor, and inductor on each pin.  Likely to protect the hardware from abuse, but it has the effect of limiting the throughput of the 6520 if used as a serial comm

Clearly different than the 800. In facts, it does sound (as Doc's suggested) that Ports 3 and 4 could do better on the 800 than anything else (may be a good idea trying higher speeds with XEP80 there, maybe a special Colleen-only version of it):

 

 

This of course we knew in advance, and we understand how they impose a ceiling to how fast we can move things there.

 

However, when it comes  to performance variance (on the same MoBo, same passives, same external device, just different PIA), that is a pretty different story (as evidence on my Tests #1 and #5)...

 

Motos are still on their way from Cali. Also a pair of late '84 or '87s brand-new Mexican Rockwell-s shipped from Europe are on the way, as well... We will see how they all do in the next few days....

Edited June 4, 2020 by Faicuai

[ChildOfCv]

3 hours ago, Faicuai said:

Clearly different than the 800.

Look at R138-R153, C143-C150 and C153-C160.  Those are resistors and capacitors that will limit your throughput.  The only thing missing is the inductors.

[_The Doctor__]

still dislike all those chokes on everything to this day, many of them could have been toroid beaded jumpers... but that's another story...

[Mathy]

Hello Faicual

 

7 hours ago, Faicuai said:

.. may be a good idea trying higher speeds with XEP80 there ...

 

Most of the slowness of target XEP80 is caused by programming.  Check out what Erhard found out on my special stuff page.

 

Sincerely

 

Mathy

[_The Doctor__]

10 minutes ago, Mathy said:

Hello Faicual

 

 

Most of the slowness of target XEP80 is caused by programming.  Check out what Erhard found out on my special stuff page.

 

Sincerely

 

Mathy

um, using Phaerons super duper fast drivers. trying to see what the limits will be, I think....