nesdev.org

DMA on the other hand, may be used for purposes far beyond graphics transfer. I think it's a much more elegant design than then NES custom mapper chaos.

SNES has a general purpose DMA controller. It can be used for way more.

Isn't DMA also used by the SNES Powerpack for very short loading times?

I was under the impression that the SNES' DMA (if you're talking about the 8 channels at $42xx/$43xx) only could transfer data between the CPU and PPU. I.e. either the source or destination has to be $21xx. I don't see how that would be useful for the PowerPak when loading ROMs.

$21xx hits everything on the B bus, which includes the PPU, WRAM, expansion, and cart edge. The A bus hits the cart edge and S-APU.

WRAM has two sets of pins on it, one for talking to it via the A bus, and others for talking to it via the B bus at $80..$83 with the streaming reads/writes. If both are enabled, the A bus pins take precedence, and the B side is tristated (CPU sees open bus).

Thus, carefully managed DMA can blast from {ROM, WRAM, SAPU, anything that pipes up on the cart} <-> {VRAM, WRAM, anything that pipes up on the cart}

tomaitheous wrote:6502freak: Wow, that is really petty. Nerd rage is never a pretty thing.

Honestly? This is a nerd forum, the whole topic of the thread is nerdy, and sorry, but you also started (and continued) by being nerdy. Glass house, stone.

I'm not going to even touch that reply (too bad, there is some good stuff/topics to talk about there and you're obviously a pretty intelligent guy). You need to seriously calm down/take a chill pill (and you're presumptions about me couldn't be more wrong, not that you care though). ;>_>

And you are obviously a pretty intelligent guy, too. However, I was under the impression you took some things I said out of context in order to make your point look stronger, or implying things which I never said.

Plus, I am also right now losing my hair over the Cell Broadband Architecture. One really nasty memory bug in my code I can not find.

I am sorry if I offended you. Nevertheless, I hope you realize it often takes two to make a debate heated.

mic_ wrote: I don't see how that would be useful for the PowerPak when loading ROMs.

Transferring sectors from Compact Flash card into RAM. With DMA, you can come very close to 2.68MB/s transfer speed. With the CPU polling the CF registers, it would be much less. I also think that the SDRAM controller is hooked to the DMA in the Powerpak.

I always figured the reason the PCE/TG16 was so much faster was because it was by NEC, and they also make memory chips. What if Nintendo wasn't always able to get a competitive pricing/availability on fast memories? If they need to have them in every cartridge, they could basically get screwed over at any minute.

It is a shame though that they didn't bring the PPU bus to the cartridge port, other than extra connector cost (either because of size or smaller pitch) I guess it's just too many pins. Could have been just like the NES, where the /CE line for the internal memory comes out to the cartridge port. The NES cartridge port has plenty of wasted pins, and they seem to have done just fine regardless of that.

The TG16 ran at 7MHz, and packed all sorts of instructions that should have been on the 6502 to begin with, and had some block move instructions to cover for DMA.

Only the PRG made it to the cart there IIRC, and it was a vram based console more like the snes, though with fewer colors, only one BG layer, one sprite layer (with switchable priority a la the NES), and 64 sprites.

I've heard that the 65816 requires memory clocked twice as fast because it only accesses memory for half a cycle instead of the whole cycle like the majority of other cpus, forcing 5.37 Mhz memory to be used like 2.68 Mhz, and 7.16 Mhz to be used like 3.58 Mhz. I don't understand why Nintendo/Ricoh didn't fix the problem for the Snes.

5.37 Mhz dma would be really helpful at sprite animation, so I wouldn't have to rely on stupid tricks like "every enemy walks with synchronized footsteps" and "alternate between animating the giant robot's front legs and back legs."

That would be due to how the clocking works on the 6502 and 65816. The input clock is turned into two mutually exclusive clocks, phi1 and phi2. phi1 controls the address bus and data out latches, instruction register, and most of the internal control signals, including the various register loads. phi2 controls the data input latches (one for the main dbus, one for the instruction decoder), the program counter, and precharges all the internal busses to +5V.

External devices see a stable address while phi2 is high, and must have data valid before phi2 goes low. "Fixing" this would have required a more complex bus cycle, akin to the z80 probably, where it takes 4+ cycles to access memory.

In addition, some of the expansion chips took advantage of this. The SA-1 accesses the ROM in the dead time in between 5A22 accesses, but only works when the 5A22 is running at SlowROM speeds.

ReaperSMS wrote: External devices see a stable address while phi2 is high, and must have data valid before phi2 goes low. "Fixing" this would have required a more complex bus cycle, akin to the z80 probably, where it takes 4+ cycles to access memory.

PCE's 65x variant runs 1:1 (processor speed to data bus). It isn't anything like the z80 address system. Having a non multiplexed address scheme would have fixed the problem on the '816, unless there's something else I'm missing? I also had an idea of a next byte prefetch system (like a linear burst), for running memory at the same speed (processor divide clock speed) instead of the required 2x requirements. Though I didn't work out all the details. (This wasn't for snes, but a MCU project)

Haven't seen timing diagrams for the 6280, but I'm betting the address bus didn't quite work like that. Clock speed isn't really the right term for these memories anyways, since they're all async. It's more likely it still had the 2x requirement, and used the off-duty half of the CPU cycle for refresh. I would be rather suprised if it turned out they redid the entire inner workings of the core, rather than the tweaked up 65C02 it looked like.

The 5A22 doesn't multiplex the bus, at least, it doesn't appear to from the pinout. It's possible the 816 inside is multiplexed, and part of the DMA/external bolt-ons hide that.

Really it comes down to the basic issue of things not happening instantly. The memory needs to have a stable address, and the CPU needs to have a reliable point to latch the incoming data. If the CPU has to compute the next address from the incoming data, there's going to be some dead time on the address bus between the ROM providing data and the new address showing up. A prefetch system might pull that off, but then you need more logic to have the next address computed in time, and the only "benefit" you get is theoretically cheaper ROM chips, in a world where the bulk of the chips avaliable are going to be fast enough, given the competition.

ReaperSMS wrote:Haven't seen timing diagrams for the 6280, but I'm betting the address bus didn't quite work like that. Clock speed isn't really the right term for these memories anyways, since they're all async. It's more likely it still had the 2x requirement, and used the off-duty half of the CPU cycle for refresh. I would be rather suprised if it turned out they redid the entire inner workings of the core, rather than the tweaked up 65C02 it looked like.

Not sure what you mean by using the off-duty cpu cycle for fresh. And I shouldn't have said 1:1 for the 6280, because it needs a rom/ram/bus device to be a little faster than the CPU cycle of 140ns. 120ns is found for the internal ram and is what I've used for external (rom zif board).

The 5A22 doesn't multiplex the bus, at least, it doesn't appear to from the pinout. It's possible the 816 inside is multiplexed, and part of the DMA/external bolt-ons hide that.

I just assumed the kept it (internally, wouldn't be much of a problem to have the 8bit latch in the same chip) because of the address being setup on the first half of the phase and the data bus window on the second phase like that of the stock '816.

What about the SA-1. Were any changes made in regards to that '816 variant? Regarding memory timings and such.

The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

As for the SA-1, the rom there was 90-100ns, 10.7MHz access cycle, or 2 master clocks. The 5A22 gets two cycles for one access, the SA-1 then gets two cycles for two accesses, though I think it's an x16 rom and they're cheating a bit. The 5A22 runs at 2.68MHz (21.5/8), SA-1 at 10.7, and if the access requests collide, the SA-1 waits.

ReaperSMS wrote:The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

Well, how long after the starting point of phase 1 is are the address lines valid, on the original 6502 and the NES variant? I can't imagine it being at the end of phase 1.

tomaitheous wrote:

ReaperSMS wrote:The 6280 is probably using a rather skewed duty cycle for access then, or they went with overlapping phases and hoped for the best.

Well, how long after the starting point of phase 1 is are the address lines valid, on the original 6502 and the NES variant? I can't imagine it being at the end of phase 1.

6502 timing info is in this PDF, skip to page 3:
http://archive.6502.org/datasheets/mos_ ... v_1985.pdf

Thanks, I see it. 1/4th in on Tcycle, or 1/2 in on phase 1. Thanks for the link