Hi all,

I am trying to get SPI working on an interface card I am creating for my Apple ][ (actually an Apple IIgs). I am trying to use the implementation by André for his CS/A65, rev 1.1A. I had to re-create the PHI2 signal, as the Apple ][ bus doesn't include it, by using a 74HCT74 as per Apple's TIL #494 info.

I had to rewrite the driver by André, as I use indexed I/O to the card (using /DEVSEL), but it was almost a complete copy-and-paste action.
However it seems the SCLK is out-of-sync with the MOSI/MISO signal(s), but I am at a lost right now of where the culprit would be....

I have attached both the screenshot of my logic analyzer (Bitscope micro/Bitscope Logic combo) and the source, written for ca65.

Does anyone know what might be solution to my 'problem'? I have this issue while both shifting under T2 and PHI2

Thanks in advance!

I'm very curious about this. I've been exploring SPI a teeny bit recently, and I've seen the things Andre has done. I will admit I didn't understand much of it.

It seems that SPI is, in essence, really quite simple: chip select the chip, put the value you want on the data pin, and toggle the clock pin. Rinse and repeat.

If I had two output ports A and B, and had pin 0 of A set to the clock, and pin 0 of B set to the data out line, shouldn't this "just work"?



Assuming that the device is fast enough to keep up, and yea, not the most efficient use of the ports, but… shouldn't this "just work"? Maybe I have the clock backward, but, on principle, isn't it supposed to be "this simple"?

Given that base understanding, I didn't grok the extra complexities and difficulties that Andre was talking about.

_________________
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?

I'll go slightly OT here and expand on Garth's point. It's definitely worth paying attention to which bits are assigned for the various functions!

Yes, by all means attach the SPI clock to bit0 of the port, because INC<port> (or DEC<port>) is usually faster than the instructions it would take to set (or clear) the clock if it were attached to some other bit. As for MISO (which requires testing when the Master is inputting), I recommend attaching it to bit7. Bit6 is special only if you use the BIT instruction -- and it turns out the BIT instruction can be optimized away! I didn't quite believe it at first, and had to give my head a shake. But I've successfully tested code equivalent to the following. Here's how the port bits are used in the snippets below. Bit1 (MOSI) was chosen arbitrarily; the other two not.

• bit7 of VIAPORT is in input mode -- attaches to MISO
• (bits available for other uses, especially as inputs)
• bit1 of VIAPORT is in output mode -- attaches to MOSI
• bit0 of VIAPORT is in output mode -- attaches to Ck

The snippets are written as if part of a subroutine, but I omitted details managed by the caller or preceding inline code -- the critical portion is the loop. Firstly we have code for inputting a byte from SPI. As noted in the comments, the INC instruction does two things -- it performs input as well as output. This makes a BIT instruction unnecessary -- and, in a loop this tight, omitting one instruction means a substantial speedup, percentage-wise. I've marked the cycle counts for the instructions which execute repeatedly. (If your VIA is mapped in zero-page subtract 2 cycles per bit from the times shown.)

Edit: here is an improved version, described in my subsequent post. BTW both of these input routines treat the output data as don't-care (MOSI is held at 0).

And here (below) is the routine for outputting a byte to SPI. These routines are the fastest I've managed to achieve so far, but suggestions are welcome of course. (I guess I could unroll the loops... )



In another post I talk about driving a 16is750 UART with this code. Even a 1 MHz 6502 can bit-bang fast enough to achieve 19.2 or even 34.8 kbaud on the asynch connection -- and of course faster CPU's exceed this figure.

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

So, in the first routine, A is set to the byte that it read, correct?

In the second routine, A contains the byte to be sent out. The SEC acts as a sentinel for when the byte is done. The ROL A shifts the first bit to send in to Carry.

Ok, I see how this works. This is very clever.

On an older 6502, you can use X = 0 in place of the STZ, yes?

The initial attraction to SPI was that it seems pretty bone simple, and easy to implement, even badly. And you can get reliable mass storage out of it in the end. Because with the SD cards, you can operated on them with 512 byte blocks, and not worry about leveling or any of those other Flash issues. I saw an article using a 8 pin SPI 1MB flash chip, but you have to manage the 4K page erases yourself and, ostensibly, manage the leveling and block use yourself as well. Having to dedicate 4K to a storage buffer just to write a single 512 byte block seemed excessive.

_________________
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?

_________________
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?

Well my complaint was less about the leveling (because of what you mentioned), but more of "if I want to write a 512 byte block, I need to read in 4K first, copy my block in, then erase it from flash, and write it back", meaning I need a 4K buffer (and arguably the original 512 byte block as well) to write the block.

4K just seems like..a lot, especially on a 64K (or less: 32K) machine since it's ostensibly empty 99% of the time. A large gaping hole Just In Case.

The SD card manages all of that for me.

Of course, nowadays, you could probably get a tiny uController for $1 to act as a surrogate to the host and manage that aspect for you. That's effectively what's on a SD card already anyway. Stream 512 bytes to the surrogate, and use it's 4K of RAM to manage the Flash device.

But cost and part count aren't my primary concern.

Thanks for the feedback on the code, fellas. Here's the input routine, replacing CLC / ROL with ASL as Garth suggested. FWIW I also flipped the sense of the branch, because "one" bits ended up 3~ slower than "zero" bits, and I think I'd prefer the timing to be more uniform.

As before,

• bit7 of VIAPORT is in input mode -- attaches to MISO
• (bits available for other uses, especially as inputs)
• bit1 of VIAPORT is in output mode -- attaches to MOSI
• bit0 of VIAPORT is in output mode -- attaches to Ck

Yes -- and your inferences about register usage are also correct. I got a little lazy about commenting that!

Doing as you say will avoid disturbing those other bits, so it's a valid suggestion. But it slows the loop down by 2~ per bit, so let's only use it as a last resort. Depending on circumstances, there may be as many as three ways to avoid having writes such as STZ disturb the other bits.

• there's no problem if the other bits are inputs
• there's no problem if the other bits are outputs which remain low by default
• there's no problem if the other bits are outputs that have pullup resistors attached and are controlled by the DDR

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

_________________
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?

I think that works fine for logging if all you're doing is appending, since you can "write over" the FF's of the erased bits, but if you need to overwrite and update data, then you need to erase the entire page and rewrite it. That's what I was talking about.

_________________
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?

Interesting optimisation challenge! How about this version - put MOSI on bit 2, with bit 1 being an unconnected output pin, and then:

That's 15 cycles per loop, I think, plus a few cycles of setup code.

Though I think for SD cards you're meant to be sending set bits - not clear bits - on MOSI when reading data. You could load #$06 into X or Y and use STX or STY instead of STZ.

Which board of the CS/A are you actually referring to? Maybe I'm getting old and forget stuff, but the main board using SPI was using a CPLD for that and no bit banging.

In fact even the Commodore userport USB was using the VIA shift register and no bit banging.


IMHO bit banging is a waste of CPU cycles that can easily be avoided by using a shift register...

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I guess phi2 needs to be recreated not because it is not included ( it isn't but phi0 should work just as well) but because the leading edge needs to be delayed.

The VIA is a latching in the register select lines when phi2 goes high. Systems with shared busses typically have video during phi2 low, so when phi2 goes high the register select is not ready yet. The C64 has this problem and it seems the Apple II also.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/