AtoMMC 2.0

What's going on here then?



Let's see ... that's:

Acorn Atom Rev.4 with PL8 fitted +
Microchip PIC 16f77 +
74ls00 +
Custom firmware +
DScaler 4.1.15 +
Saleae Logic 1.0.21

An equation that = Joy.

Here's the trace of SPI activity whilst loading the above program from MMC. Click for a larger view. Go on. I know you want to.


That'll be ~5k of Galaxians loading in ... ooh let me see now...



Oh yes. 0.3 seconds.

The previous board sat cuddled up to the VIA and all of the SPI communication was performed by banging bits against one another. This board takes bytes at a time, like a man. These are then passed on to the inboard SPI hardware and the reply posted back.

Some PICs, like the one used here, have what's called a parallel slave port. You access it like any other bus-based device. It has /EN, /OE and /WR lines which directly control the state of one of its 8-bit data ports. With no valid control signals present the chip sits happily processing with the PS port data lines in a high impedance state. Enabling the chip and clocking /WR will latch the data found on the port at that time. Similarly asserting /OE with the chip enabled will take the port out of high impedance state and present latched data to the bus. There are separate latches for reading and writing. The reception and recovery of data can cause an interrupt. Very handy. Having been an AVR freak for a long time now since migrating away from PICs I'm starting to see their appeal once more. There. Ah sayed it. I Love PICs. Again. I don't know why I fell out of love with them, I suppose it was becasue they felt rough and ready. AVRs were sexier. With better development tools. I digress.

So with appropriate code written, and some neat decoding logic in place to translate the 6502's r/wr signal to separate /RD and /WR signals away we go. Fortunately I'm a reasonable programmer and the AtoMMC firmware that I wrote for the VIA interface was device independent. After as long as it took to recompile and burn a new EPROM, I had a new working driver for the new working hardware.

In all the round-trip time from presenting a byte to the chip to receiving a reply is as long as it takes to process the following 16 cycles:

;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~
;
; spi transfer
;
; on entry
;  A = byte to transmit
;
; on exit
;  A = received byte, Y preserved, X trashed
;
xferbyte:
    sta $b400
    nop
    nop
    nop
    nop
    lda $b400
    rts

Quite a big difference from the original code..

;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~
;
; spi transfer
;
; on entry
;  A = byte to transmit
;
; on exit
;  A = received byte, Y preserved, X trashed
;
xferbyte:
    stx XBTEMP
    sty XBTEMP+1

    ldy #8

xb_xferbit:
    sta XBTEMP+2      ; ZP write .. faster than PHA

    and #MOSI         ; present data, CS is low
    ora #CLK          ; bring clock high
    sta VIA

    ldx VIA           ; read data

    eor #CLK          ; bring clock low
    sta VIA

    txa               ; rx'd data into carry
    ror a

    lda XBTEMP+2
    rol a             ; 7<-next bit, 0<-rx'd data

    dey
    bne xb_xferbit

    ldy XBTEMP+1
    ldx XBTEMP
    rts

All this joy has happened relatively quickly since receiving my logic analyser. I don't know how I coped without it. Having a window onto the private world of your signals is more revealing than the televisual programme 'Katie and Peter'. Speaking of feeling dirty I must admit that I used to feel the idea of attaching a peripheral processor arguably more powerful than the host computer to be anathema. However now I'm over the initial revulsion I have to admit I quite like it. Again I digress. So for a perfect example of how having an analyser helps, let's look at the behaviour of the flip-flop that I programmed to change whenever a SPI transfer completes:

You might be able to see it in the thumbnail here, but click for more pixels. The top two signals are enable and write. Taking the falling edge of the write line, when data is latched from the bus and passed to the SPI hardware, we see that the third line, rdy, is flipped about 12 microseconds later indicating that data is ready for reading. The writes occur at about 16 microsecond intervals. Remember the 16 clock code earlier? Aah yes. That code was generating this trace. I could probably drop a couple of NOPs to push things a little faster but I want a small comfort zone. I could also use a faster SPI clock. I'll perhaps experiment with that another time.

Mmm. Katie and Peter. Dirty boy. Go to your basket.

Rapidly scribbled and then