Current state of programmable logic

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

lidnariq
Posts: 8703
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Current state of programmable logic

Post by lidnariq » Thu May 09, 2019 10:59 am

Hijacking OAMDMA is guaranteed to safely handle any analog timing issues, because it's only running at the same data rate as the CPU, not twice the rate as the CPU.

I don't know of any useful repository of analog timing measurements. I've recorded a very short list of random things: PPU A12 vs MMC3 IRQ and M2 vs Mclk.

As far as digital bits:
The 2A03 runs off two synchronous biphase clocks; the standard 6502 50% φ1/φ2 for everything internal (visual2a03 node "clk0"), and a 15/24 (revision E and newer) duty M2 for everything external (visual2a03 node 11200). We've seen several bugs come from M2 being asserted before φ2 on write cycles.

We used to think that the original letterless 2A03 had a 18/24 duty cycle, but looking more closely at the die shots it looks like it might be 17/24 instead.

The 2C02 runs off a single 50% biphase clock at the pixel clock, which I've personally taken to calling "left half dot" and "right half dot"; Visual2C02 calls it "pclk0" and "pclk1". Normal PPU fetch cadence during rendering is {ALE idle AssertRD doRead}.

I don't think we know anything beyond the divider ratios for the 2A07 (16 master clock cycles/instruction cycle) and 2C07 (5 master clock cycles/pixel).

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Current state of programmable logic

Post by supercat » Thu May 09, 2019 12:07 pm

lidnariq wrote:Hijacking OAMDMA is guaranteed to safely handle any analog timing issues, because it's only running at the same data rate as the CPU, not twice the rate as the CPU.
I was under the impression that the weird controller-port interactions with DMA were caused by the fact that DMA cycles didn't use the same timing as normal CPU accesses.

There are byte-stuffing approaches that run at one byte of data per two CPU cycles (make opcode fetches get NOPs, and use the dummy operand fetch for data transfer using the CPU address), which would allow the low-order address bits to be used by the memory directly. I don't see any advantage of OAM-DMA over such approaches sufficient to justify the extra address latching that would be required to do anything useful during the second cycle. If one wanted to use OAM-DMA to feed data that would be meaningless to the OAM and then later send meaningful data, that would be possible, but one would lose the ability to extend the "useful" part of vblank by disabling background rendering and ensuring that no sprites are too high on the screen.

lidnariq
Posts: 8703
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Current state of programmable logic

Post by lidnariq » Thu May 09, 2019 1:06 pm

supercat wrote:I was under the impression that the weird controller-port interactions with DMA were caused by the fact that DMA cycles didn't use the same timing as normal CPU accesses.
Only when DMA preempts normal execution, for the DPCM fetch. OAMDMA is triggered directly by the CPU itself, so its timing is guaranteed safe. (it works extremely similar to 2600 WSYNC)
If one wanted to use OAM-DMA to feed data that would be meaningless to the OAM and then later send meaningful data, that would be possible, but one would lose the ability to extend the "useful" part of vblank by disabling background rendering and ensuring that no sprites are too high on the screen.
Writing to $2004 after rendering has started seems to have only temporary (within those scanlines) effects, no changes to the contents of primary OAM DRAM.

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Current state of programmable logic

Post by supercat » Thu May 09, 2019 4:00 pm

lidnariq wrote:
If one wanted to use OAM-DMA to feed data that would be meaningless to the OAM and then later send meaningful data, that would be possible, but one would lose the ability to extend the "useful" part of vblank by disabling background rendering and ensuring that no sprites are too high on the screen.
Writing to $2004 after rendering has started seems to have only temporary (within those scanlines) effects, no changes to the contents of primary OAM DRAM.
Using OAM-DMA to fetch data that isn't meaningful to the OAM would corrupt the OAM if done at any time when the system isn't rendering the frame. If 1- or 2-cycle-per-byte CPU-based transfer methods don't work, OAM-DMA might be usable as a substitute, but relying upon the OAM to ignore transfers would seem hokey unless there was no other way to get good transfer speeds. If one wants a 20-line top border, having to wait until the end of vblank before starting a transfer would forfeit about half of one's potential update window.

Post Reply