Hi guys, I'm interested in options for booting a 6502 without a parallel EEPROM. I'm also not personally keen on using a microcontroller. SPI EEPROM is really appealing though, because it's ridiculously simple to get data out of, if all you want is a stream of bits.
I searched the forum for examples of booting this way, but couldn't find much - maybe I used the wrong search terms, but I wondered if you guys remembered any particular projects that worked this way for reference?
The main thing I did find was a really interesting technique refined by Dr Jeffyl 5 years ago to boot a 6502 with very few signal lines, which I think was based on streaming data out of SPI EEPROM to generate those signals, or possibly a microcontroller. Very neat, and more links in his post to past posts it was based on:
viewtopic.php?f=4&t=5231&hilit=spi+eeprom+spi+bootThere's also a nice effort to use a 22V10 PLD to provide a certain amount of virtual ROM - I think it was six bits of address space, so rather small, and only worked for certain data due to restrictions on product terms per output bit - I've lost the link I'm afraid so can't post it here.
I didn't find a lot else though, and I'm sure others have already taken this further so it would be great to hear of more examples.
For my purposes I'm not interested in addressable SPI ROM - I don't want to connect the address bus, my only interest is for boot-up, so there should be no need to serialise addresses and feed them into the ROM, we can just read the bytes sequentially. I want something that's not directly coupled to the CPU, or a particular address decoding technique. I don't need a lot of space, I think 256 bytes would be plenty to chain to loading a sector from SD card, which is 512 bytes and can easily take over from there.
Small size SPI EEPROMs seem very easy to use - based on the datasheets I think they can be read simply by feeding them a clock signal, activating chip select and bringing their data-in line high for two clocks then low permanently, and then after about 8 ticks you can start reading bits from the device's data-out line and presenting them to the CPU. I think you could even connect the clock to a 4-bit counter and drive the data-in line from one of the divided clock outputs, which would be high for two ticks then low for two ticks, then repeat that pattern - the EEPROM would start from a funny address, but should otherwise not care about the unwanted signal on its data-in line.
The EEPROM is essentially a bit-stream - byte boundaries don't really mean very much. You could tick the clock 8 times whenever the CPU tries to read from the device, to pull 8 bits, or just keep the clock running all the time and put dummy data in the EEPROM, but only write to the data bus when the CPU is performing a read operation; or just make sure the data you're putting on the data bus is the same data that the CPU will be putting on it. This way it would be fairly simple I think to have this device selected after reset, and serve all addresses above $8000 say, and it can provide the reset address of $8000 followed by a stream of instructions to load registers and save them to various RAM addresses, then jump to RAM. Perhaps the act of jumping to RAM also switches the address decoding into a runtime mode where the SPI EEPROM is no longer addressed.
Another option is to dump the EEPROM contents into RAM during reset, i.e. hold /RESET low while counters count up through all the RAM, writing bytes from the EEPROM using a shift register. I've done this before from parallel EEPROM and it was very effective - however it requires counters, which is a lot more ICs. Having the CPU drive the address bus instead is appealing, and allowing the reset circuit to "bus master" requires adding a lot of exceptions to existing circuits that could be a thorn in their side later on, not worth it just for the sake of handling the reset.
It strikes me that a simple PLD could be enough to gather the bits from the EEPROM and output them to the CPU, with tri-state operation so it can stay off the bus after that point; the PLD might also have resources to manage the data-in line appropriately. CPLDs can do much more, but I'm still interested in sticking to PDIP parts at the moment.
I guess it would be necessary to clock-stretch or arrange for the CPU clock to be 8x slower than the SPI clock, at least during boot-up. Perhaps this actually brings us back to Dr Jeffyl's solution which requires special control of the clock when booting. My "fast" PDIP system could probably do this through clock stretching though rather than having to provide the clock from the bootloader module, which would require something like a multiplexer on the clock line and that's the sort of thing I feel isn't worth compromising for the sake of a non-parallel boot-up.
Anyway this is getting deep into the weeds, there could be better ways that I'm not thinking of, so I'm interested to hear any thoughts or links.