It is currently Mon May 20, 2019 11:26 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Thu May 09, 2019 10:59 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8366
Location: Seattle
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).


Top
 Profile  
 
PostPosted: Thu May 09, 2019 12:07 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 101
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.


Top
 Profile  
 
PostPosted: Thu May 09, 2019 1:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8366
Location: Seattle
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)

Quote:
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.


Top
 Profile  
 
PostPosted: Thu May 09, 2019 4:00 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 101
lidnariq wrote:
Quote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group