I wonder whether it is feasible to use a high-performance 16-bit microcontroller as a DMA master in a (1Mhz) 6502 system with no extra hardware, directly driving the bus with general purpose I/O lines controlled by software. Has anyone given it any thought, or even done it?

If it were possible, it would open up some interesting homebrew possibilities for extending legacy 6502 systems.

It is absolutely possible. I was using DMA to implement the IPL circuitry for the Kestrel-1, and that just used 74ACT595 chips. It's definitely possible for a high-speed microcontroller to do DMA.


You'll need to implement a bus arbiter if you have multiple peripherals doing DMA. Otherwise, you can just follow these steps:

1. Negate RDY
2. Disable CPU drivers.
3. Mash on the bus all you want.
4. Enable CPU drivers.
5. Assert RDY again.

I had in mind something like a Commodore 64 or Apple II where you have to get on and off the bus in 1/2 cycle (to share it with the video DMA). The timing might be too critical to do it without external latches/buffers.

Oh, well, it's still doable, but you will need external devices to help out, I think, to guarantee phase locking. Basically, it amounts to putting the proper bus signals out from the microcontroller, and relying on external bus drivers to enable or disable the transceivers at the right time.

One way to do things entirely in software is to also drive the Phi0 signal too. If you drive that in software, then you can be assured of phase synchronization, and therefore can also do without the external drivers.

What controller are you planning on using to do this with?

EDIT If the controller is fast enough, you can update the state of the bus signals in the I/O registers, but then poll on the Phi1 or Phi2 input. When the state becomes correct, just alter the DDR bits for the appropriate microcontroller ports (also make sure you negate the main CPU's access to the bus too, since otherwise you'll have bus contention!). Then, either poll for the opposite clock phase or use a fixed delay in the form of NOP instructions to time when to reset the DDR bits to tri-state the line drivers.

Timing has to be critical. But it is possible, assuming a fast-clocked microcontroller. There is someone on this forum (LordSteve, I believe) who has knowledge of the "SX" microcontroller line, which looks like a very high-speed (circa 50MHz or so?) PIC implementation, which appears to be capable of this type of activity.

A 16MHz ATmega is probably the lowest end microcontroller that can do this sort of task, but even then, I'm sure you'll end up with wait-states periodically.

kc5tja said:

Yes, SX microcontrollers (rated up to @75MHz, easily overclocked to at least 80) are a good fit for this. I recently have had prototype 6502 boards made which use an SX28 microcontroller to clock the CPU and decode RAM chip select, /OE, and /WE signals. They are also dirt cheap at $2.79 in single-unit quantities (for any model).

_________________
Thanks for playing.
-- Lord Steve

Yes, and a latch for reads.

The thing that makes this idea interesting is that the microcontroller can do double duty as a coprocessor and DMA controller. Consider interfacing to a USB drive. You can offload all the work to the coprocessor, so the 6502 doesn't have to do anything besides say "go", and then wait. Besides being fast (theoretically, up to 1MB/s - about 12 times faster than the fastest possible programmed I/O), this reduces to a minimum the amount of 6502 code required.

Originally I was thinking in terms of a high-end 8-bit or 16-bit microcontroller, but a 32-bit ARM-based microcontroller would be more appropriate. They are quite cheap and available with a variety of I/O including USB.