Jump to content

Photo

Project: DMA Board

DMA PBI CPU

14 replies to this topic

#1 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • 182 posts

Posted Fri Feb 24, 2012 6:13 PM

This is a project idea we were chatting about on ##Atari today. The basic idea is that we make it possible for PBI devices to take over the system bus to perform DMA transfers at up to 1.7 megabytes per second. This is done by hooking into the way that ANTIC stops the CPU with a small riser board, and connecting /HALT and a new /DMA signal to two currently unused pins on the PBI.

The device protocol would work like this: when a DMA transfer is desired, the device asserts /DMA. Every cycle that starts with /DMA asserted is a DMA cycle for the device *unless* /HALT was asserted before the cycle began, in which case the device has to relinquish to ANTIC. Devices can use the presence of /HALT at a high level during a read of the device's registers to detect whether DMA is present; if not, devices can fall back to programmed I/O.

I whipped up a quick board layout for this; the board is also designed to generate a "clean" phi2 output as well as allowing the use of a W65C02 or W65C816 instead of 6502C. It does not support other 6502s or 65C02s which do not have the /BE input.

DMA Board.png

Thoughts?

#2 mikey OFFLINE  

mikey

    Star Raider

  • 52 posts

Posted Fri Feb 24, 2012 6:21 PM

well, missing the GAL part and equations?

#3 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Fri Feb 24, 2012 6:22 PM

Details, details :) Yeah it'd be a 22V10. Equations are in my head somewhere. Maybe they'll come out if I rattle it a little.

#4 sloopy ONLINE  

sloopy

    River Patroller

  • 2,396 posts
  • lookin for bits, i like bits...
  • Location:in my cave of despair, surrounded by toys...

Posted Fri Feb 24, 2012 6:27 PM

which reminds me... wormfood... i need to kick someone...

:')

sloopy.

#5 Mathy OFFLINE  

Mathy

    Stargunner

  • 1,780 posts
  • Location:Heerlen, NL

Posted Fri Feb 24, 2012 6:28 PM

Hello dmlloyd

The 130XE and it's European derivates already have the /Halt signal on the PBI (read: ECI). The XL has EXTSEL and EXTEN (the XE only has EXTSEL). One of those is in input signal. What would be the difference between that one and your /DMA?

Mathy

#6 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Fri Feb 24, 2012 6:30 PM

The CPU's /HALT input would be the logical-and of ANTIC's /HALT and the /DMA input. In other words EXTSEL and EXTEN are useful for remapping your device into RAM but they are not useful for gaining bus mastery. The /DMA signal lets devices control the address and data bus directly, either for transferring data into and out of RAM or a device like POKEY or GTIA, or even to support an external CPU.

#7 sloopy ONLINE  

sloopy

    River Patroller

  • 2,396 posts
  • lookin for bits, i like bits...
  • Location:in my cave of despair, surrounded by toys...

Posted Fri Feb 24, 2012 6:30 PM

Hello dmlloyd

The 130XE and it's European derivates already have the /Halt signal on the PBI (read: ECI). The XL has EXTSEL and EXTEN (the XE only has EXTSEL). One of those is in input signal. What would be the difference between that one and your /DMA?

Mathy


If your asserting /HALT, then how would you know Antic is asserting it, and needs to do video DMA?

sloopy.

#8 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Fri Feb 24, 2012 6:39 PM

Because /HALT from ANTIC goes out to the PBI and into the GAL, where it is combined with the /DMA input from the PBI to feed the /HALT input of the 6502C and the flip-flop circuit which locks phi2 and /BE for the other two CPUs. The GAL also has to set R/W to true when ANTIC halts and tri-state it when the PBI device halts.

#9 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Fri Feb 24, 2012 6:40 PM

.... and so the PBI device knows that ANTIC wants to halt by watching the /HALT output on the PBI.

#10 candle OFFLINE  

candle

    River Patroller

  • 2,762 posts
  • Location:Lublin, Poland

Posted Fri Feb 24, 2012 7:01 PM

there is another way of doing dma without stopping cpu
first presented on apple computers - it will require a bit more than this,, but it will be rewarding (hint - use sync line)
as for antic halt - there is no easy way out to know when it happends
halt is asserted one cycle ealier than antic taking over the bus
you could assume, there is no two halt cycles one after another without any cpu cycle in between, but you can't be sure of anything

actually.. its even worse...

DMA Viewer
Antic DMA timings

Edited by candle, Fri Feb 24, 2012 7:06 PM.


#11 bob1200xl OFFLINE  

bob1200xl

    River Patroller

  • 2,042 posts

Posted Fri Feb 24, 2012 10:43 PM

I have thought about DMA, but what use would it be? Video? With PBI devices running > 50KBS, it seems like a lot of work for little gain.

Notwithstanding, it would be pretty easy. HALT is asserted right around the time 02 rises and is latched at 02 falling. It doesn't matter who is gating HALT since the CPU is dropped off the bus by BE in either case. Where HALT originates is only of concern to who will have control of the bus.

The main design issue is: what will be driving the DMA cycles? You need some kind of intelligent controller that can deliver data and addresses at a high rate. Can't be a 65816 at 1.79MHZ... you might as well use the system CPU. So, you're looking at a CPLD with some regs, clocks and logic in it. And, a 24-bit (or more) bus that can be tri-stated.

Now, if you had the system 65816 running at 14MHZ, you wouldn't need any of that stuff. You could clock at 1.79MHZ when MPD was inactive and 14.32MHZ when it was asserted, if you wanted. Move a lot of data, really fast.

Bob

#12 Rybags OFFLINE  

Rybags

    Quadrunner

  • 12,887 posts
  • Location:Australia

Posted Fri Feb 24, 2012 10:47 PM

If it works, there'd be some good applications besides storage devices such as blitter with shifting/masking, digital audio playback, fast colour register changing.

What'd be nice is a passthrough device so we can still use our IDE storage devices on the PBI.

#13 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Sat Feb 25, 2012 9:47 AM

For memory <-> I/O DMA, the controller device needs only to do two things: (1) generate the RAM address to read/write from, and (2) select the I/O device to write/read from (with the appropriate device register address selected).

There are some devices which "know" about DMA already for which you don't need (2), but I think for the most part it's not avoidable. So, what this means is, in order to do DMA to an external I/O device, you need to be able to generate two addresses, one for the system RAM and one for the external device. The system RAM address has to be a counter clocked on phi2's falling edge in order to do full-speed DMA.

To do DMA to an internal I/O device, you have to keep the device address on the bus for each byte transferred (in many cases you'd just do one at a time), but this means the data has to be transferred to external memory which doesn't use the system address bus for the transfer. One application I've thought of is using FIFO RAM, clocking it at some fixed rate (22KHz or 15KHz whatever), and every clock doing 4 (or 8) transfers to load bytes from the FIFO to each POKEY volume register. The CPU just loads up the FIFO every vblank period or so. In this way you have basically a hardware mod player. Likewise you could even have simple hardware waveform generators to do this instead of pulling the data from RAM, and thus be able to generate nice instrument sounds. Since it's /HALT driven, if you sync to the hsync rate it might skew a few clocks at first but eventually it would "fit in" to the spare non-ANTIC cycles on any mode line. You could have a POKEY tone generator which also allows concurrent usage of all POKEY timers... even SIO, probably.

The application I'm really hoping to utilize this with though is networking i.e. high-speed downloads via a DMA-enabled PBI ethernet device. Anyway it seems like there are lots of interesting things you could do with this type of circuit.

#14 dmlloyd OFFLINE  

dmlloyd

    Chopper Commander

  • Topic Starter
  • 182 posts

Posted Sun Feb 26, 2012 12:41 PM

Here's my second revision at board layout. Metalguy66 pointed out that I'd be bumping the keyboard on my 600XL since that front row is so close. So I assembled some spare perfboard and header pins and a socketed 6502C and did some testing of how it would all fit, and this is what I came up with:

Posted Image
Also, I have what I believe are correct GAL equations. Though I wouldn't mind if someone wanted to sanity-check them: http://www.flurg.com...d rev 2 GAL.txt

#15 ivop OFFLINE  

ivop

    Chopper Commander

  • 220 posts
  • Location:The Netherlands

Posted Tue Feb 28, 2012 4:02 AM

I have been thinking about something similar, but a little different. I thought about replacing the RAM with high-speed SRAM and use the first half of the cycle to do the DMA. That way you won't have to halt the CPU. If you buffer the ANTIC bus, you could even get your refresh cycles back by disconnecting the HALT line and bus in case of refresh cycles. It's all just thoughts though, nothing concrete, but it might give you/others some inspiration ;)





Also tagged with one or more of these keywords: DMA, PBI, CPU

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users