6502 SO-Pin / Chuck-Peddle-Special-Pin

[Hobbit1972]

BigEd wrote:

The 74LS02 is a TTL part, a quite different process. Actually I'm not sure how good TTL is at pulling all the way up to the rail, but maybe it's fine.

Whoops - that points me to a little flaw in my breadboard design: no pull-ups, just TTL output of '02 into 6509... it seems to work... but maybe that's the reason for some quirks...

[JimDrew]

Interesting, I didn't think the 4040 was any different from the 8050/8250/1540/1541/1571/etc.

[GARTHWILSON]

Hobbit1972 wrote:

Using RDY would be 2 clocks faster for it is already waiting inside the LDA. Using WAI would have to load LDA instruction, address byte (and possibly second address byte if I/O not in ZP).

That's an interesting idea. It would work if the input is transparent during the read, but the next thing to find out is whether the VIA will transfer new data to the bus during the read time, ie, data that wasn't there yet at the beginning of the read time.

[Dr Jefyll]

GARTHWILSON wrote:

the next thing to find out is whether the VIA will transfer new data to the bus during the read time, ie, data that wasn't there yet at the beginning of the read time.

Maybe I've misunderstood the context here, but I don't see how this is necessary. After every wait state (caused by RDY being low), another whole new bus cycle occurs (albeit to the same address). Seems to me the VIA should have no trouble delivering new data in the new bus cycle.

[BigEd]

Hmm, are there reads of status registers which change the state, such that a repeated read isn't what you want?

I suspect the construction of the CS (or maybe the E input) to the VIA will determine whether it sees repeated reads or one looong read.

[Hobbit1972]

Dr Jefyll wrote:

Seems to me the VIA should have no trouble delivering new data in the new bus cycle.

I also would think so. VIA should sample data in phi1 and put the new data on the bus every phi2. But maybe somebody with a VIA could test it to be sure?

(If it would not work it should not be too difficult to find work around with RDY/CS logic.)

BigEd wrote:

Hmm, are there reads of status registers which change the state, such that a repeated read isn't what you want?

That could be the case, of course - one has to keep that in mind.

On the other hand: in this design VIA's read or write handshake features probably are not too useful here, for it either triggers an IRQ or has to be polled by software - both completely unnecessary when waiting is already performed through RDY. Other accesses than to data Port A/PortB also is not used or necessary.

[i_r_on]

You could use S.O. pin to do synchronous transfers. Trigger by hardware, use it in software type feature whereas RDY signal can only be used by hardware and you cant use it for synchronous transfers.

I guess the pin used initially for early testing & debugging of the design. And the least used flag is chosen as victim for this late addition to the design. (Just a guess)

[wayfarer]

could you use this as part of multiprocessing in bit slice form, ie:
6502 Lo has overflow, send Address or other Pin, to SO on 6502 Hi, and 6502 Hi can test this on certain operation chains.

[fachat]

Hobbit1972 wrote:

JimDrew wrote:

All of the CBM disk drives used the SO pin, connected to the data separator. When a byte of data has been converted from flux to GCR, the SO pin goes low which sets bit 6 (V) of the flags. This has to be cleared in software (CLV) or you won't see the next one occur. This was used from the late 70's (PET drives) until the early 90's when CBM stopped producing the 1571.

I know this quite well, because it is what I am currently working on - a cycle exact CBM disk drive emulator using a PIC micro. I am emulating the 6502, two 6522's, 2K of RAM, and the data separator hardware with the proper crazy memory map that mirrors and has invalid (undecoded) addressing.

This is... interesting. Schematics for 4040 show that SO is pulled up, no connection to data seperator:
http://www.zimmers.net/anonftp/pub/cbm/ ... 0806-1.gif

and ROM code doesn't use SO therefore:

Code: Select all

 FDB1  24 4D     iFDB1      BIT VIA_IFR    ; get the bytes, store in (BUFPT),y, update checksum, jmp DEND
 FDB3  10 FC                BPL iFDB1
 FDB5  A5 41                LDA VIA_DIN
 FDB7  91 16                STA (BUFPT),Y
 FDB9  45 08                EOR WORK
 FDBB  85 08                STA WORK
 FDBD  C8                   INY
 FDBE  D0 F1                BNE iFDB1 

"Byte ready" is tested via VIA. GCR decoding fully done in hardware. Checksum is generated within the loop.
Source: http://www.6502.org/users/andre/petinde ... s1fdc.html


SO came into use in later series, 8250 for sure (didn't check with 8050 yet):

Code: Select all

FD9F          LFD9F:
FD9F 50 FE      BVC LFD9F
FDA1          LFDA1:
FDA1 B8         CLV
FDA2 A5 41      LDA io_diskdata_read_fdc
FDA4 91 17      STA (bufpnt_fdc),Y
FDA6 C8         INY
FDA7 D0 F6      BNE LFD9F 

The guess would be that someone miscalculated the time available: 8250 has a higher data rate -- but still would leave plenty of time to do it the old way (no SO, test via VIA, checksum calculated later in a second loop), but the someone thought there would not be that plenty of time and tried to cut corners.

That's quite an interesting find! I didn't notice this before.

The 4040 (and 8x50) use a hardware GCR data encoder/decoder, reducing the data rate by 4/5. So there probably was enough time. The single CPU drives 2031/4031/1541/15x1 use software GCR en-/decoding, so the data rate was higher than the 4040. The 8x50 use a higher data rate in general even though still using the hardware GCR encoder. So they probably assumed that using SO was required to securely handle that increased data rate with the same 1MHz CPU clock.

André