I cannot recommend strongly enough doing a cheap bit-bang SPI interface and getting it working before designing and building custom hardware to assist you with SPI (unless perhaps that custom hardware is a microcontroller-level system that does all the work for you). Premature optimization without ...

/CE is the chip enable, or chip select. This is generated by the decoding circuitry.
/RD and /WR are the read and write lines. These are intel-style signals, but they're easy to generate from the 6502's phase-2 and R/W. They're the same signals your ROM and RAM almost certainly use.

Right. Thank ...

Thank you very much for the help! It seems like this is the best solution. One question, though: how should I activate the /CE, /OE, and /WE lines? And are they all necessary? I'm assuming they'd be input pins.

It seems more convenient to use the ATF750CL as I don't think I'd need more than one SPI device. However, I'm not very well informed when it comes to how SD cards work and how I'd program the ATF750CL to read/write the data. Are there any resources you know of that could assist me with that, and ...

But I'd also say that if you're already using a GAL for one thing, then you have everything you need to use a second one for something else. Most electronics parts vendors give discounts for volume orders, too (even if that volume is only ten, instead of one).

I suppose you have a good point ...

I'd prefer to avoid using any more programmable logic devices. I'm already using an FPGA as a video card, and a GAL for address decoding logic. Is there no available IC for either SD or USB that provides a simple interface?

I thought shift registers were unidirectional, so wouldn't I need 2 if I wanted bidirectional communication?

Well yes; sure. That's the plan. But bit-banging the protocol isn't going to give me fast enough speeds.

You should expect hardware to give you access to the raw blocks of data stored on device, if anything. The filesystem should be handled in software.

FAT isn't a very complex filesystem. Handling it shouldn't slow you down at all.
Well, if you say so. I'm not very knowledgeable when it comes to ...

This part has been discussed in other posts around here. Try searching for it and see what turns up.

I did, and apparently it seems like it's more of a way of getting UART via USB, not so much for reading/writing to mass storage. I can't seem to find very many ICs. Preferably the IC would handle ...

While this is not an SD card IC, I did find this on Mouser: https://www.mouser.com/datasheet/2/163/DS_FT240X-17703.pdf

It seems like it'd be an easy way to interface with USB mass storage, with a proclaimed speed of 1 MB/s.

What do you guys think? They're certainly very cheap, but would they be ...

We've been through a lot in a short time regarding this project, so forgive me if I'm forgetting something, like whether you were considering running SPI in programmable logic.

Well, it's certainly possible to run it in programmable logic. I'm sure the FPGA for my video generation would have some ...

Ultimately, I think you should set a goal to where you can get loads from and stores to mass storage up into the 200-300 KB/sec range in order to reduce the perception of lag to a minimum. At that speed, a 30KB load would be less than an eyeblink in length. It can be done with reasonable hardware ...

Hmm, I see. Thanks for the insight. I'm not fully sure how I'd solve this issue, because I do agree that 30KBps is way too slow for actual game loading, I just meant it's doable for testing.

A rough cycle count from my own SPI bit-banging code looks to yield a little over 30 kilobytes (not bits) per second receiving at 10MHz.

Hmm. 30 isn't too bad for bit-banging, honestly. If the program were 2MB, it'd take.. 66 seconds? A little slow I suppose, but doable for now. That's also ...