Here's a first draft proof of concept expanding on comments from the SPI bootloader discussion; moved to to allow comments without further cluttering that thread.

The parts are basically what I've got on hand at the moment, and so are not optimal; in particular the memory would be better as a single 64k part which would both increase speed and simplify the decoding.

The memory map uses the entire 64k for RAM with the exception of an I/O hole at 0xfe00-feff; the VIA is mapped into the lower half of that.

On boot, the STM holds ndisable low which prevents the RAM from outputing data and provides the boot code as a sequence of bytes on the databus in the form

and releasing the data bus to allow the processor to write the byte just delivered to the address requested. At the end of the boot sequence, ndisable is released high and the processor reset to allow normal operation from the contents of ram.

The STM provides eight bits of data, the ndisable control, and rst, ph0, irq and nmi to the system.

Power is provided via an FTDI USB/serial connector cable; regulated to 3v3 by a choice of either a linear or a switch mode supply (I want to play). This cable also carries serial data to and from the UART on the STM.
The VIA provides an interface to the STM's SPI1 port; the STM then acts as an SPI-UART adaptor (code still to be written but I expect to include a buffer or 32 or 64 bytes with CTS/RTS interfacing performed automatically by the STM.

Note that the STM is a 3v3 part; some of the I/O ports are 5v tolerant but I haven't investigated yet which so at the moment everything runs at 3v3.

Circuit parts are generic; expect 74HC and 3v3 ram.

Did I miss anything obvious? This is still likely to change, particularly around the 3v3/5v split.

Neil

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

Nice - I guess this is similar to what Michael was suggesting using a PIC for. It sounds like you have it running?

Rather than overriding the RAM's chip enable, another interesting option could be to use "lda $1234" and change the last bus cycle into a write operation, pushing the data you want onto the bus at that point. You could also use this trick during the reset to write the reset vector.

But it probably doesn't matter too much how compact the code is - avoiding adding complexity, delays, etc to the glue logic is probably more important, so if overriding the chip select is cleaner that way then it's a better solution.

Your design does seem similar in part to the blind interface method I'm using which I learned about from a Hardware SID Player article by Dr. Nicholas Fitzroy-Dale back in 2013. I hope my posts in the SPI thread were helpful.

Not running yet, not written any code but I'll probably order some PCBs in the next day or two, if no-one points out any obvious flaws in the logic.

Neil

First minor change: the ~OE signals to the two ram chips should come from O4 and O5 of the 138, no O0 and O1. RnW has to be high, of course...

Neil

It looks like you're already picking between the two RAM chips using their chip selects, so don't need A0 to go into that decoder at all. Maybe either the chip select logic or this decoder could be simplified.

I'm also not seeing any phi2 qualification for writes to RAM, it will not work well if you just let it write throughout the cycle like this. In particular RWB can go low before the address lines are completely stable, smearing your write operation across multiple addresses.

Like to see a generic thread about 6502 bootstrap by executing incoming 8-bit data as instructions. There are many implementations, just recently I’ve read about serial eprom and microcontroller assisted schemes. I myself have done USB-to-parallel (FT245) and compact flash FIFO schemes and proposed a serial port bootstrapping. What is a good name for such technique?
Bill

Cleared up some confusion and simplified the ram decoding - thanks to gfoot and Garth.

Here's the latest version. A recent update of kikad seems to have eaten all my footprints, which I need to investigate.

Neil

One tip I can give is to name your connectors.
They all come with the default "Conn_00x00_Odd_Even etc etc" name which I recommend you replace with the actual name of whatever you want to use it for.
That way you don't need a seperate text field to say what the connector is for and you get to see it's name on the PCB (though it defaults to the fabrication layer).

For example on my own SBC the expansion card connector is called EXPANSION, the connectors for the VIA pins are called PA and PB respectively, and the CPLDs JTAG connector is of course named JTAG.
It just looks a bit neater than leaving the default name IMO

It looks good. The VIA's IRQ pull-up (R5) is optional for W65C22S, but would be needed for the -N variant or older parts. In the case of the N-variant you could make the microcontroller's irq output be open-drain and remove U5C and U5D, but what you already have here is more appropriate for the -S variant that is more commonly-used, so may be a better compromise.

Another option is to chain the microcontroller's IRQ output through the VIA, e.g. on CB1. The VIA will set its IRQ flag on whichever edge you choose. You would need to clear it manually in software before servicing the microcontroller's request.

I also looked at the depth of the address decoding, which is sometimes a concern with such primitive gates - your longest path is four operations, between A8 and the RAM. One of those is after PHI2's rising edge though, and RAM is fast so that much is not a concern. You do require enough time after A8 is settled for U8's A1 pin to reach its final state, before PHI2 rises. I thought it is probably possible to shorten that path by one gate. However, I don't think it's necessary because the worst case I can imagine is that this pin may not stable when PHI2 rises, and the RAM starts executing a write. This seems fine though as the address being written is already stable, and lies within a region of RAM that is not accessible to the user, so a write to this location - even with the wrong data - is not going to cause any problems. Perhaps having a very short write pulse could upset the RAM enough to corrupt a different address, but I don't know whether that's likely.

An ATF16V8 could do all of that decoding plus the function of U8, and the IRQ combining logic, and still have a couple of pins to spare. (I think that would be 10 inputs and 3 outputs for address/IO decoding, and 2 inputs and 1 output for IRQ combining, so 12 in and 4 out overall, out of 18 total usable pins.)

Valid points about the decoding - but the whole point of this proof of concept is to use some chips I happen to have lying around the place, so I just need to order a PCB. An alternative would be something like the 688 8-way comparator, but again, it's no doubt got lots of gates internally, and I don't have one to hand.

Using the the STM at (probably) 16MHz would give the fastest clock at 8MHz, then other integer factors slower...

Neil

Take three... rev C below, along with a render of a proposed PCB - four layers, just for a change, though I think it would work with two with minimal changes.

Next task is to get onto a Nucleo and see if the basic signals will appear where I want them to; if they do, I'll get onto JLCPCB (or Aisler, the prices are about the same - JLC's cheaper production is offset by the shipping cost for the stencil).

The idea is that when disable is high, the 6522 and the ram chips are disabled; data is provided by the STM. On the last cycle of a STA abs instruction, disable is unasserted to allow the processor to place data in ram where it's just been told to. Once loaded, including the vector table at 0xfffa-0xffff then disable is unasserted, reset triggered, and ph2 provided by the STM.

Things I need to do before I spend money on this:

• Prove the outputs from the STM
• Build an SPI-UART bridge in the STM
• Build an SPI input/output via the 6522 from the 6502

Neil

And it turns out that the two-layer version is simpler; just needed a couple of tracks nudging and a load of unnecessary vias removing.

Neil

Some notes/ponderings...

Nice small board, surface mount, so compact. USB is a bonus if you can plumb that into the 6502 somehow?

I think it's a lot of ICs for what it's doing 9 plus a 3v3 regulator (or 2?) ... But I hear you saying it's what you have on-hand. Still... I guess we really can't get simple/small ROMs anymore...

On the clock, I see you're driving ph0 (pin 35) into the 6502 then phI2 (pin 37) out of it for the VIA - I'm under the impression that's deprecated in favour of just using ph2 everywhere - and pin 37 is an input on the 65C02 - looks like you're treating it as an output to the VIA? so connect PA15 on the STM to both 37 on the 6502 and 27 on the 6522 and the memory write qualify logic which it is anyway by the looks of it.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/