Interested in developing a simple DMA controller

[StephenHorn]

The FPGA doesn't know or care about the full 16-bit address. Remember how binary addressing works; the card only decodes the lower 5 bites on the address bus. The upper 11 bits don't matter, because IO3-IO7 guarantees that the address is already in a specific range.

That makes sense, but then I don't understand what StephenHorn meant by this?

As for how to go about assigning a specific address range, I'm sure that could be done easily enough in Verilog, but it would probably be ideal to rely on external logic to select the DMA controller for the appropriate range of addresses and assert a pin. A problem for someone else, or for me whenever I would get around to testing it. Which is why, way back on the first post, I was thinking it would need a "chip enable" pin, or equivalent, to indicate when it's been selected.

It seems like the alternative that makes the address range configurable would be to rely on more pins that are permanently tied high or low (either with traces or DIP switches), to select the appropriate address range the controller should respond to.

That was me speculating about parts of the implementation that I hadn't considered or begun researching. I have a lot of open questions that will eventually need to be answered, I'm still way back on fundamental tasks like "can I program some hardware in Verilog to behave according to my basic design, outlined in my original post, in an entirely theoretical context devoid of reality?"

Frankly, I haven't even begun to consider details like "when the FPGA detects a triggering signal edge (which I'm pretending is PHI2 for the moment, even though that may prove ridiculous), can I even trust the signals on the address and data pins yet?"

I hadn't even looked at the hardware documentation to consider topics like "IO range selection". They're completely irrelevant to where I'm at.

And honestly, I'm having a hard time understanding whether you're asking a whole lot of questions because you're hoping to learn from me, or develop the design in my stead, or what, so I'm trying my best to parse your questions from the assumption that you know what you're doing better than I do. Please do not look to me for guidance. That would be the blind leading the blind. Instead, please assume that I'm an idiot and will need course correction, and/or grab a box of popcorn to enjoy while I careen into brick walls and generally make a glorious trainwreck out of my journey of discovery.

I mean, I wouldn't be surprised if I've made at least one completely idiotic technical assumption in every post I've made in this thread, including this one.

[TomXP411]

That makes sense, but then I don't understand what StephenHorn meant by this?

As for how to go about assigning a specific address range, I'm sure that could be done easily enough in Verilog, but it would probably be ideal to rely on external logic to select the DMA controller for the appropriate range of addresses and assert a pin. A problem for someone else, or for me whenever I would get around to testing it. Which is why, way back on the first post, I was thinking it would need a "chip enable" pin, or equivalent, to indicate when it's been selected.

It seems like the alternative that makes the address range configurable would be to rely on more pins that are permanently tied high or low (either with traces or DIP switches), to select the appropriate address range the controller should respond to.

That's another way to implement it.

This approach requires the FPGA to decode the IO pins, whereas my approach just sends in the one IO pin actually required. they are two different ways of doing the same thing. Stephen's approach just moves the 5:1 switch inside the FPGA instead of externally on a jumper header.

Although reading his reply above (which I didn't see before I wrote this), he's still in the "spitballing" or brainstorming stage. This is when you consider a lot of things, most of them not seriously, to figure out what sticks out in your head as valuable and useful.

[TomXP411]

Stephen, here's as simple an explanation as I can find, after looking at the timing diagram and reading up a little more:

When Φ1 rises, the address bus is valid.
When Φ2 rises, the data bus is safe to write.
when Φ2 falls, the data bus is safe to read.

So the action is always on the rising edge or the falling edge. This is also how you get 4 t-states from a single clock pulse.

Sources:
Page 4: https://www.princeton.edu/~mae412/HANDO ... s/6502.pdf
https://lateblt.livejournal.com/88105.html for a super succinct explanation.

[Dacobi]

And honestly, I'm having a hard time understanding whether you're asking a whole lot of questions because you're hoping to learn from me, or develop the design in my stead, or what, so I'm trying my best to parse your questions from the assumption that you know what you're doing better than I do. Please do not look to me for guidance. That would be the blind leading the blind. Instead, please assume that I'm an idiot and will need course correction, and/or grab a box of popcorn to enjoy while I careen into brick walls and generally make a glorious trainwreck out of my journey of discovery

I'm sorry, but I'm just trying to learn. While I have some experience with Verilog I don't have any when it comes to working with a brand new computer architecture.
The reason I replied to your original post is that it's similar to an idea I had myself.
But not one that I'm currently fully qualified to implement.
But that doesn't mean I wouldn't be able to learn. I usually get the idea first and then learn how to do it secondly.
I'm the kind of person that learns by doing, but right now I don't know how to proceed without the actual hardware.
I would think I could implement it on my Arty board, but would have to wait for a x16 board to test it.

[StephenHorn]

Well, it's not my intention to shut you down, I was just getting confused and a little anxious, because of all these questions about how things will work when I'm not confident on many of the answers.

[Dacobi]

Well, it's not my intention to shut you down, I was just getting confused and a little anxious, because of all these questions about how things will work when I'm not confident on many of the answers.

I was just worried that you might have been thinking that I was wasting your time, but no worries : )

I've made an initial draft of a Verilog x16 DMA module. It's not meant as a suggestion for a final design, but a way to show my current thinking.

CS is for IO3-7 DIP switches and transfer would begin when any value is written to reg 8, including zero, so reg 9 would have to be written first, when needed.
Also all regs read back as zero.

I don't know when the data bus is valid on the x16 so I've made a 1 clock delay between setting the address and reading/writing the data bus.

https://github.com/dacobi/x16dma

Please bear in mind, it's about 2 years since I've done any work in Verilog and I've never made a design that had to interface with an existing architecture.

Right now I'm concerned that it may enter an endless loop where RDY never returns to High.

Synthesis completes without any warnings, but during implementation I'm getting some warnings about addr pins not being buffered. But it only happens for the top 8 pins, so it's probably something with my constraints file.
(Edit) Turns out it happens for all addr pins, but not for data pins. Don't know how to set buffers for pins in Verilog.

[BruceRMcF]

Stephen, here's as simple an explanation as I can find, after looking at the timing diagram and reading up a little more:

When Φ1 rises, the address bus is valid.
When Φ2 rises, the data bus is safe to write.
when Φ2 falls, the data bus is safe to read.

So the action is always on the rising edge or the falling edge. This is also how you get 4 t-states from a single clock pulse.

Sources:
Page 4: https://www.princeton.edu/~mae412/HANDO ... s/6502.pdf
https://lateblt.livejournal.com/88105.html for a super succinct explanation.

Note, however, that Phi1O will not be on the expansion slot, and the Phi2 on the expansion slot will be the bus master clock that is an input to the CPU, not the Phi2O CPU output clock.

Phi1O and Phi2O are for legacy designs, but it is not advised to use the Phi output pins for new designs, though the datasheet rather implies that rather than coming out and saying so. From Page 10 of the datasheet (emphasis added):

3.8 Phase 2 In (PHI2), Phase 2 Out (PHI2O) and Phase 1 Out (PHI1O)

Phase 2 In (PHI2) is the system clock input to the microprocessor internal clock. During the low power Standby Mode, PHI2 can be held in either high or low state to preserve the contents of internal registers since the microprocessor is a fully static design. The Phase 2 Out (PHI2O) signal is generated from PHI2. Phase 1 Out (PHI1O) is the inverted PHI2 signal. An external oscillator is recommended for driving PHI2 and used for the main system clock. All production test timing is based on PHI2. PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.

... the key phrase is bolded: literally none of the timing specifications in the datasheet refer to PHI1O and PHI2O, so using them puts you squarely in, "if it works, it works, if it doesn't, oh well" territory.

__________________
Regarding:

... I don't know when the data bus is valid on the x16 so I've made a 1 clock delay between setting the address and reading/writing the data bus. ...

Yes, it will be nice when there are timing diagrams for the X16 bus, but if the FPGA is running at an internal quadrupled clock:

     Phi2=0        Phi2=1
__             ___________
  \___________/           \___

__    __    __    __    __    __
  \__/  \__/  \__/  \__/  \__/
   PhiA  PhiB  PhiC  PhiD

... it sure seems like a good first crack would be to attempt to have address valid at the start pf PhiB. If it is 70ns EEPROM and at 31.25ns per quarter clock cycle, so 93.75ns for PhiB-PhiD, that would give 23ns for the ROM select logic to complete through to driving /ROM_CS.

[Dacobi]

Note, however, that Phi1O will not be on the expansion slot, and the Phi2 on the expansion slot will be the bus master clock that is an input to the CPU, not the Phi2O CPU output clock.

Yes, it will be nice when there are timing diagrams for the X16 bus, but if the FPGA is running at an internal quadrupled clock:

Phi1=0 Phi1=1
__ ___________
\___________/ \___

__ __ __ __ __ __
\__/ \__/ \__/ \__/ \__/
PhiA PhiB PhiC PhiD

I'm getting confused by all these PHIs. Are you saying that PHI2 on the expansion bus is the same as Phi1 in your diagram? Which is basically the input clock of the 6502?

[BruceRMcF]

I'm getting confused by all these PHIs. ...

I got confused by them first ... I had just looked up the language in the datasheet on the two Phi output lines that they no longer give timings for, and typed Phi1 when I meant Phi2. It's fixed above.

"Phi1O" (the "Phi1" output pin, pin 3 in the DIP package) and "Phi2O" (the "Phi2" output pin 39 in the DIP package) are legacy features, not for use in new designs, and so it is not surprising that the expansion bus does not bring either out, but brings out the bus signal that is input into the Phi2 pin, pin 37 in the 65C02 DIP package.

[TomXP411]

I'm getting confused by all these PHIs. Are you saying that PHI2 on the expansion bus is the same as Phi1 in your diagram? Which is basically the input clock of the 6502?

Sort of... The important thing is that Φ1 and Φ2 are inverted, but also delayed. Rather than cross each other, Φ1 is supposed to fall completely before Φ2 rises.

You can think of Φ0 and Φ2 as generally the the same thing, but they're not exactly the same thing - otherwise, we would not need Φ2 at all.