DMA guidelines

Lorin Millsap · Post by **Lorin Millsap** » Sun Jul 12, 2020 3:13 pm

None of this matters. The bus cycles are locked to your 8MHz system clock and DMA controllers are required to match the 65C02 protocol. The internals of the DMA card have nothing to do with what a bus cycle looks like.

Actually that doesn’t matter. Yes they are locked to a degree, but once a DMA access is started the system clock is not entirely relevant. The initial setup and the final release matters of course, but that actual access doesn’t do long as it doesn’t violate component timing. So the fact that a Z80 takes multiple cycles to complete an access is not necessarily a problem. Granted we haven’t tested it. But it should still work. However I will agree that problems will be much less likely if they run on some type of synchronization.

Sent from my iPhone using Tapatalk

picosecond · Post by **picosecond** » Sun Jul 12, 2020 5:26 pm

1 hour ago, Lorin Millsap said:

The initial setup and the final release matters of course, but that actual access doesn’t do long as it doesn’t violate component timing.

Well that's the real trick, isn't it? I think we are mostly saying the same thing but I will elaborate anyway.

The 6502 bus is fully synchronous and there is no concept of an idle cycle. Every cycle does something. There are four "regular" cycles: read, write, read but discard the result, and wait. Read/discard serves as an idle cycle from the 6502's point of view, but the addressed target has no idea of this.

So while a DMA controller can take as many bus clock cycles as it wants to do its business, every signal needs to follow legal 6502 timing on every cycle. Whatever target happens to be addressed will do as it is told on every cycle. Mostly this means address and RWB need to be set to safe values with correct timing on every bus clock. So a hypothetical Z80 doesn't have to run synchronously with the system bus, but some logic between the Z80 and the system bus definitely does.

Shadowfire · Post by **Shadowfire** » Sat Mar 20, 2021 3:44 pm

Picosecond is correct, some sort of hardware arbitration *needs* to be implemented here. Even if its some ridiculously simple priority allocation system where slot#0 is highest priority, this should be decided upon before the machine is finished.

Otherwise, you are in for a world of incompatibilities if you try to make a DMA card, where it works fine when its in your system, but the moment someone else tries to put two DMA cards in... you're really going to let the software driver authors hash this out among themselves??? There are NO winners in this situation, only losers (the user).

Wing Tang Wong · Post by **Wing Tang Wong** » Thu Apr 01, 2021 2:48 pm

On 3/20/2021 at 8:44 AM, Shadowfire said:

Picosecond is correct, some sort of hardware arbitration *needs* to be implemented here. Even if its some ridiculously simple priority allocation system where slot#0 is highest priority, this should be decided upon before the machine is finished.

Otherwise, you are in for a world of incompatibilities if you try to make a DMA card, where it works fine when its in your system, but the moment someone else tries to put two DMA cards in... you're really going to let the software driver authors hash this out among themselves??? There are NO winners in this situation, only losers (the user).

Didn’t the ISA bus make use of just something like this? Ie. Priority encoders and multiple interrupt lines?

Is there a way to implement these protective features without hardware changes?

Lorin Millsap · Post by **Lorin Millsap** » Thu Apr 01, 2021 3:28 pm

This is already finished. You have software arbitration. I’m simply explaining how it works not asking how we should do it. So DMA is allowed but needs hardware devs to design it such that it has to be enabled in software and that each DMA system is only enabled when it’s needed. Sent from my iPhone using Tapatalk

Wing Tang Wong · Post by **Wing Tang Wong** » Thu Apr 01, 2021 5:10 pm

*facepalms* Sorry, my bad.

Lorin Millsap · Post by **Lorin Millsap** » Thu Apr 01, 2021 5:48 pm

So not to get to particular but often looking at use cases can be helpful.

A network card can be a good example. Say someone makes a Wifi card that is capable of higher speeds. It could handle the heavy loads of tcp/up stacks and security and even some decompression and decryption. It could then put the raw data in its own buffer and send the system an IRQ. The IRQ handler would then see what it needs to do and set up a DMA transfer. The card then takes over the system, copies its buffer to system memory then returns control back to the X16 main cpu. This could allow much faster speeds than would be possible with bit banging or even using a dedicated UART.

The same could be true of a SD expansion card, if you wanted to save a file it could just send the parameters to the controller card and then when the appropriate control register is activated the expansion card can take over a memory dump to file operation.

Sent from my iPhone using Tapatalk

Cyber · Post by **Cyber** » Fri Apr 02, 2021 3:29 am

On 7/8/2020 at 9:48 PM, Lorin Millsap said:

I figured now that I let out some information about the expansion bus and I’m sure there will be hardware enthusiasts eager to develop expansion cards, j figured some guidelines need to be laid out.

Thank you! Will all the info from this topic be included in manual?

Lorin Millsap · Post by **Lorin Millsap** » Fri Apr 02, 2021 3:34 am

Thank you! Will all the info from this topic be included in manual?

Yes, absolutely.

Sent from my iPhone using Tapatalk