STM interface for 6502 boot and uart - PoC

[barnacle]

Thanks Gordon,

- the USB is just the FTDI USB/UART cable, which conveniently provides 5v from the host usb. Used as serial comms only.
- ph0 etc... oops, I learned ph0 in ph1/2 out too long ago. They will be corrected; thanks for spotting that show stopper. Funny, got it right on the last one... I'll just use ph2 everywhere.
- yes, I could have done it in fewer chips by accepting a simpler memory map (and by using a single 32k ram reflected twice in the map) but I wanted to keep that big largely contiguous ram and small I/O hole.
- there are two 3v3 regulators simply because I wanted to play. Fit one and the appropriate zero ohm resistors.

Corrections are in hand. I do appreciate that people like you are willing to cast an eye over designs like this.

Neil

[barnacle]

Is there a cycle by cycle guide to the reset sequence of the wdc65c02? The datasheet merely indicates that the reset pin must be held low (active) for at least two clock cycles after the clock is stable, and that there is a reset sequence lasting seven clocks.

Is it a fair assumption that on the eighth clock the processor is about to execute an instruction read?

Neil

[gfoot]

I'm not sure if it was ever documented, but it's basically running an interrupt sequence at that point, except that in the WDC 65C02 the stack writes are turned into reads for some reason. So you should see two cycles fetching junk from memory (in the interrupt context, these would be an ignored opcode and the byte after it, I believe); then three cycles reading from consecutive stack locations (pushing the return address and flags, except they'll show as reads rather than writes); then two cycles reading the reset vector from $FFFC and $FFFD, followed by the first instruction fetch.

[John West]

The 65816 does document the reset sequence, and that is exactly what it says (except there's an extra write for PBR in 65816 mode).

I looked at BRK on an NMOS 6502 many years ago, and that was the same. I'm as certain as I can be without getting the logic analyser out that reset, IRQ, and NMI on a 65C02 will be the same too.

[Michael]

barnacle wrote:

Is there a cycle by cycle guide to the reset sequence of the wdc65c02? The datasheet merely indicates that the reset pin must be held low (active) for at least two clock cycles after the clock is stable, and that there is a reset sequence lasting seven clocks.

Is it a fair assumption that on the eighth clock the processor is about to execute an instruction read?

Neil

It's just as gfoot described. Here's what I've used for WDC and Rockwell 65C02 devices. Note that the uPull() function waits 500-nS, takes the CLK pin lo, waits another 500-nS, then takes the CLK pin hi.

The eighth clock cycle is an instruction 'fetch' from the address that you 'pushed' to the 6502 during clocks 6 & 7.

Code: Select all

  /******************************************************************************
   *  core 'blind interface' functions                                          *
   *                                                                            */
   void uReset()                      // ****************************************
   { clk(1);                          // clock = 1                              *
     res(0);                          // reset = 0  ~~~~~~~~~~~~~~~~~~~~~~~~~~  *
     _delay_us(100);                  //                                        *
     uPull(ram);                      //                                   (1)  *
     uPull(ram);                      //                                   (2)  *
     res(1);                          // reset = 1  ~~~~~~~~~~~~~~~~~~~~~~~~~~  *
     uPull(ram);                      //                                   (1)  *
     uPull(ram);                      //                                   (2)  *
     uPull(ram);                      //                                   (3)  *
     uPull(ram);                      //                                   (4)  *
     uPull(ram);                      //                                   (5)  *
     uPush(lo(0xF000));               // address $FFFC (reset vector lo)   (6)  *
     uPush(hi(0xF000));               // address $FFFD (reset vector hi)   (7)  *
   }                                  // ****************************************

[barnacle]

Thank you all - exactly what I needed.

Michael even answered the question I didn't ask, about the relationship between the rising edges of nrst and the clock.

Neil

[Michael]

barnacle wrote:

Thank you all - exactly what I needed.

Michael even answered the question I didn't ask, about the relationship between the rising edges of nrst and the clock.

Neil

For some reason it takes eight clock cycles for the reset sequence instead of seven clock cycles if the clock pin is low when you raise the reset pin.

[gfoot]

Michael wrote:

For some reason it takes eight clock cycles for the reset sequence instead of seven clock cycles if the clock pin is low when you raise the reset pin.

In the datasheet RESB is classed as a "processor control" signal along with IRQB, RDY, etc, and the timing diagram shows them being sampled near the falling edge of the clock, so I think it does make sense that if the clock is already low you need to wait for the end of the cycle before the processor will react to RESB going high.

[Chromatix]

If you want to be extra robust about the reset timing, you should sample /VP to see when the reset vector is being fetched. All the CMOS 6502s and the '816 should have this, not sure if all the NMOS ones do. /VP is pulled low during both cycles of the vector fetch. After that point, the cycle timing is entirely predictable.

I'm curious as to why you are attaching an SPI device to the GPIO pins of the VIA. The VIA's shift register is ideally suited to attaching an SPI RAM or ROM directly, as the VIA operates equivalently to SPI mode 0, and these devices tristate the MISO pin during exactly the same cycles as the MOSI pin carries valid data (so you can just tie them together). Only if you want to attach a more general type of SPI device, in which MISO and MOSI need to be used simultaneously, should you need to use bit-banged GPIO.

[barnacle]

Basically because it's about forty years since I last used a 6522... by bit bashing the pins I can use the pins exactly in states that I expect - one less thing to worry about. I do plan to use MOSI and MISO at the same time eventually, I think: for example when sending data to the UART the first byte sent will be a status register select, the next byte a dummy write that reads the register, then either an RX register which just reads an incoming byte, or a TX register which both writes the output byte and reads the status register. I haven't fully thought this through yet.

As always, real life gets in the way of things I want to do, but I am looking at this again; I'm trying to sort out the sequencing for the STM to change between the ph0 output as a driven IO pin and as an automatically toggling output. The documentation - a mere thousand pages or so - is less than clear about the sequence of operations required to set a counter in CTC mode with a toggling output on a pin. As this will be the processor's system clock that's quite important to get right.

(reset: since I will be driving both the clock and the reset line, I can make that do as I want for a consistent sequence and don't need to ask the processor what it's doing: it gets told!)

Neil

[barnacle]

Found a little time to write some code (why do I never have any time now I'm nominally retired?) and can generate the ph0 signal from the STM32L073 at 1MHz, 2MHz, 2.3MHz, 2.7MHz, 3.2MHz, 4MHz, 5.3MHz and 8MHz and all sorts of frequencies below 2MHz. I don't expect the board to work at 8MHz but 4 or 5.3 might be possibilities; we'll see.

A note: it turns out that the pin speed on the STM needs to be set to at least high speed to get usable outputs; the slew rate limiting causes higher frequency signals to fail to approach ground. With medium speed setting, the output at 2MHz was fine but at 4MHz the signal was only half a volt... between 2.8 and 3.3v!

I also have a bit-banged SPI master using some spare pins on the C port which I can loop through to the SPI1 (configured as a slave) to test my SPI-UART bridge and buffer.

So it's probably about time to order a PCB.

Neil