I'm still in the midst of testing for my PIC-based MC6850 replacement, but my thoughts have started to turn to leveraging the work done on that project to create another bus-based peripheral to provide SPI connectivity.

Since this is not being based on any existing piece of hardware like the MC6850 replacement was, there is some room for planning here. Here are the high level details for what I'm considering at the moment:

• One 8-bit control register (write only)
• One 8-bit status register (read only)
• One 8-bit data register (bidirectional)
• One or two 8-bit clock divider register(s) (bidirectional)

The SPI protocol is bidirectional and always initiated by the master, so the CPU would use it as follows:

1. Configure the hardware by writing to the control register and the divider register(s) to establish operating parameters
2. Spin on the status register until the idle bit goes high
3. Write to the data register
4. (optional if reading) Spin on the status register until the idle bit goes high
5. (optional if reading) Read from the data register
6. Loop back to step 2 until all bytes have been written/read

For write-only devices, steps 4 and 5 may be safely omitted.

Here's some sample 6502 code for operating in polled mode:



An interrupt mode would also be provided as well.

I/O would be byte oriented, making it difficult to communicate with devices that expect a non-byte-aligned number of bits. However, I do not believe such devices are common. If I am wrong, then some accommodation can be made with the control register.

For the status register, I'm thinking of allocating the bits something like this:

• 1 bit for idle status
• n bits for additional status (errors)
• m bits for device ID (to identify interrupting device)

For the control register, I'm thinking of allocating the bits something like this:

• 1 bit for clock polarity
• m bits for up to 2^m chip selects (only 1 can be active at a time)

There are a lot of SPI devices out there and I've only used a small number of them. If there is any functionality I've left out which would be useful to have for a general purpose SPI interface, please let me know your suggestions and I'll try to incorporate them into the final design. Given that I already have a test system and framework (PIC-UART) to build this on, I'm hoping it will come together pretty quickly. I'll plan to test the completed system out with some serial memory in order to exercise the hardware for both sending and receiving.

This would be a great addition to the IO device list. My 65SPI works well but the Xilinx 95xx chips are getting harder to find. If you are looking for some ideas for features, download the datasheet for the 65SPI and take a look. The features I included were the result of comments from 6502.org users back when I was creating it. There's probably some discussions in the group here somewhere as well.

https://sbc.rictor.org/65spi1.html

Good luck!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Suggestion: make the status register "idle" bit bit 7 so the BIT instruction can be followed by a BMI if the bit is set or BPL if the bit is cleared. The code will slightly shrink and be nore efficient. For example:

Code:

SPI      =$C400
;
;
;   setup...
;
         LDA #CONFIG
         STA SPI               ;config register
         LDA #<CLKDIV
         STA SPI+2             ;LSB of clock divider
         LDA #>CLKDIV
         STA SPI+3             ;MSB of clock divider
;
;
;   you forgot to initialize .X
;
         LDX #0
;
;
;   main loop...
;
NEXT     BIT SPI               ;check idle bit
         BPL NEXT              ;busy
;
         LDA INPUT,X           ;SPI transmit buffer
         STA SPI+1
;
L1       BIT SPI               ;check idle bit
         BPL L1                ;no data
;   
         LDA SPI               ;get datum & store in...
         STA OUTPUT,X          ;SPI receive buffer
         INX
         CPX #LEN
         BCC NEXT
;

You really need to do this with interrupts, since transmission and reception are two unrelated activities. The same principles used in UART driver code will work here.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

In addition to a bit for clock polarity, you also need a bit for clock edge. See https://en.wikipedia.org/wiki/Serial_Pe ... de_numbers

And for read/write or read-only devices, step 2 may be omitted, because the device was idle in previous step 4.

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

Thank you everyone for the comments and suggestions.

I've setup a wiki page for the specifications and temporarily hosted it here: https://github.com/jason6502/pic-uart/wiki/PIC-SPI-Specification

Once I setup a new repository for the pic-spi project, I'll move the page there.

For the initial implementation, I'm going to support master mode only. However, I'm keeping slave mode in mind and attempting to plan for it. Since the PIC includes an SPI peripheral built-in, I'm not going to try to support anything more general at this time. More general shift-register support could be implemented with bit-banging, however this would be quite a bit slower than what the hardware SPI peripheral is capable of. While its true that the PIC could be programmed to use the SPI peripheral when SPI mode was enabled, and switch to bit-banged mode when it was not enabled, I prefer to get to the finish line quickly with the key functionality working and then let others expand on my work if they desire.

I'm looking at Daryl's 65SPI datasheet now (nicely done, BTW). There are some hardware differences between the PIC and the CPLD Daryl used which will impact compatibility between the two devices. In particular, the PIC will only support a maximum of 4 slave devices due to the limited number of pins on the 28-pin device (as opposed to 8 slave devices for Daryl's 65SPI). Also, I plan to support slave mode in the future. Where we have bits in common in the status and control registers, I will go ahead and align them to minimize any code changes required. I'll also look carefully at any differences between what I'm planning and what Daryl already has and consider whether to incorporate these differences as well.

If high 6502/65816 bus speeds are to be used with this device, I expect using it in interrupt mode will be mandatory. In polled mode, I expect to see limits of about 6-8 MHz unless steps are taken to reduce the rate the registers are polled. This has to do with the maximum rate at which the PIC can update its state internally not being high enough to keep up with a fast 6502/65816.

Finally, I'll try to put together a nice datasheet like Daryl has done in PDF format for the PIC-SPI when the design has stabilized a bit.

Congrats, very nice project. Now I have question to the hardware, how do you now interface the 6502 to the PIC? I have continuously read the thread with the PIC as UART, but at the end it was not clear to me which circuit you are currently using as the GLUE. Do you have a schematic?

Have you had a look here: http://forum.6502.org/viewtopic.php?f=4&t=3476

That shows the schematic of the test system I'm using. I'm connecting the PIC to the 6502 almost the same way that the MC6850 is connected. The exceptions are that the PIC does not need a clock source and that I'm currently using voltage conversion circuitry (a 74LVX4245) to convert from 5V to 3.3V on the data lines.

To be more specific, the following connections are made between the 6502 and the PIC:

A0-A1: address lines
RWB: read strobe
WRB: write strobe
D0-D7: data lines (currently via a 74LVX4248)
CS: chip select
IRQ: interrupt line

That is the sum total of all of the connections between the 6502 and the PIC at present.

As part of the datasheet which I will put together for the PIC-SPI, I will include some "application information" showing the specifics of connecting the PIC to a "typical" 8-bit CPU bus (of course I'll use a 65C02 as the typical 8-bit CPU).

P.S. If anything still isn't clear, let me know and I can draw you a schematic of the relevant connections.

No wait states?

Depends on your bus speed. I've found they are not necessary with the PIC PMP peripheral at speeds up to approximately 8 MHz (the highest I've tested so far).

There are two timing-related limits to be aware of.

The first is the bus timing limitations. This is the maximum speed at which the PMP peripheral on the PIC can safely operate. Specifications notwithstanding, I've had no problems running up to 8 MHz here.

The second limitation is the rate at which the PIC system software can update internal state. So, for example, if you are writing to the PIC-UART and polling the status in between each write to see if the PIC-UART is ready for another character, the maximum rate at which you can do this is limited to the maximum rate at which the PIC software can update the register you are reading to reflect the new status. At least for my PIC-UART implementation, this occurs around 5 MHz right now. Adding wait states does not noticeably affect this number. Reducing the rate at which you poll (e.g. by adding NOPs) will resolve the problem, as will using interrupts because then the PIC controls the timing not the CPU. I expect similar limits will exist on the PIC-SPI, though somewhat higher because the system state is simpler too.

I will update the schematics for my 6502 Test System thread this evening for you and include the wait state generator I'm sometimes using with it. I think the only changes are to the second page of the schematic. It still shows an MC6850 in the system, but the differences are minimal for the PIC connection as in my previous post.

Well, it looks like properly updating the schematics for the 6502 Test System is going to be a bigger job than I expected. Instead, I refer you to what is up on the test system thread http://forum.6502.org/viewtopic.php?f=4&t=3476 along with this schematic of the wait state generator I'm using (well, I'm actually using a 74HC107, but the circuit is nearly the same):



I will eventually put the schematics for the test system into Altium Designer when it has stopped changing weekly. Actually, I've just ordered several tubes of GALs to replace most of the 74HC chips with. Had I realized these were still available in DIP form earlier, I would have saved myself a lot of headaches with the 74HC logic, but I guess using them is a sort of right-of-passage. I just hope the GALs don't cause the same kinds of ground bounce problems some other non-HC logic families do on breadboards.

Note that GALs are power hungry. A 7ns GAL22V10 draws almost 100mA. I use GALs a lot and never had any issues on breadboards with them. I think you are in a better situation than with AC logic. As for my question regarding wait states. I was actually thinking that you have implemented some sort of variable wait state generator that automatically adopts to different clock speeds of the 6502 and the MCU. In other words some wait-state generator that starts when the PIC-IO is selected and stops when PIC gives out some "done" signal. The reason is that I would also like to use MCUs that do not have a PMP and much higher clockrates on the 6502 side. So I think I have to come up with my own solution for this.

I'm sticking with 15ns 22V10s. I'm aware that they are a bit power hungry, and will avoid them for battery operation.


The PIC-SPI should work at much higher clock rates (14 MHz+) so long as you use it with interrupt driven I/O. Or if you really want to use it with polled mode, you'll need to add some NOPs to your polling loop to account for the latency involved in updating the state machine. If you use an MCU without something like the PMP, I think you'll find that you'll need to add a LOT of wait states which will seriously impact processor performance while doing I/O at high speeds.

If you use 15ns GALs then you could look for Quarter Power GALs they are quite efficient and consume only 55mA worst case. I really doubt that the performance impact of many wait states for the IO register data cycle is relevant to the overall system performance. I'd really want to measure that and compare it to a solution that uses a 65C22 as interface between the 6502 bus and the AVR and needs to poll for ready. On the other hand I still have this idea in mind to convert Daryls SPI using Xilinx 95xx to an ATF1504AS. That would be definitively the fastest solution.