Post by dshadoff on Mar 19, 2020 4:55:42 GMT
The next issue in my MiSTer implementation seems to be VRAM wait states, and understanding what causes them/how many there really are...
monstersgoboom has also noticed this as an issue in code currently being developed.
byuu is also running into this with his emulator under construction, and it seems that no emulator properly emulates them (and there is variance among emulators).
Basically, what we see is:
Real hardware wait states > Mednafen wait states > MiSTer wait states > 0. (Not sure where Ootake or other emulators fit into that list)
The first major piece of information on this topic is contained in the official Hudson documentation (see "PCEDOCS" download referred to by Elmer's programming links thread in the Homebrew development forum):
The "Hu6270 - CMOS Video Display Controller Manual" provides a major piece of information on page H7-8, "Memory Access Width Reigster (MWR R09)", where it lays out how access is rotated between CG/CPU/etc. based on timing settings.
However, this doesn't tell the whole story. If it did, most emulators would be pretty close but they aren't (as shown by Chris Covell's CPUTest program under "X-Cycle opcodes", TIA->VRAM, TAI<-VRAM).
I'm curious about other wait states which might be known to (or suspected by) other developers - and confirming them by writing tests.
Between COVID and a delay in start of my next project, I hope to get some time to look into this.
Specifically, there are a number of cases I am suspicious of (please feel free to add).
I may not know immediately how to test for them though, so suggestions (or sample code !) would be welcome.
1) HBlank period reads - CPU versus sprite - how to apportion the accesses ?
2) BURST period (when CG blank + sprite blank bits are both blank, per-scanline)
- Does burst mode start at the beginning of line (i.e. end of HSync), or at the start of the HDW period ? The start of the render pipeline ?
- How about the first post-display line, where VBLANK starts ?
3) Access by CPU during SATB DMA and/or VRAM-VRAM DMA.
- The documents seem to indicate that this would abort the DMA, but Mednafen seems to put the CPU into WAIT until done. Which, if any, is correct ?
4) Misalignment of clock domain between VDC (5 MHz, 7.16 MHz, 10MHz) and CPU (7.16MHz):
- On a write, does the VWR act as the buffer between clocks, permitting non-blocking writes ? (I don't think the CPU can outrun the VDC, except maybe a 4-cycle access, 5MHz dotclock situation) If there is blocking, how does one calculate it ?
- On a read, how would blocking work ? (It may also be buffered by look-ahead into the VRR once MARR is calculated, reducing wait)
5) How about access to VDC registers (as opposed to memory) during all this ? Do they ever cause wait states ?
Any other cases to consider ?
monstersgoboom has also noticed this as an issue in code currently being developed.
byuu is also running into this with his emulator under construction, and it seems that no emulator properly emulates them (and there is variance among emulators).
Basically, what we see is:
Real hardware wait states > Mednafen wait states > MiSTer wait states > 0. (Not sure where Ootake or other emulators fit into that list)
The first major piece of information on this topic is contained in the official Hudson documentation (see "PCEDOCS" download referred to by Elmer's programming links thread in the Homebrew development forum):
The "Hu6270 - CMOS Video Display Controller Manual" provides a major piece of information on page H7-8, "Memory Access Width Reigster (MWR R09)", where it lays out how access is rotated between CG/CPU/etc. based on timing settings.
However, this doesn't tell the whole story. If it did, most emulators would be pretty close but they aren't (as shown by Chris Covell's CPUTest program under "X-Cycle opcodes", TIA->VRAM, TAI<-VRAM).
I'm curious about other wait states which might be known to (or suspected by) other developers - and confirming them by writing tests.
Between COVID and a delay in start of my next project, I hope to get some time to look into this.
Specifically, there are a number of cases I am suspicious of (please feel free to add).
I may not know immediately how to test for them though, so suggestions (or sample code !) would be welcome.
1) HBlank period reads - CPU versus sprite - how to apportion the accesses ?
2) BURST period (when CG blank + sprite blank bits are both blank, per-scanline)
- Does burst mode start at the beginning of line (i.e. end of HSync), or at the start of the HDW period ? The start of the render pipeline ?
- How about the first post-display line, where VBLANK starts ?
3) Access by CPU during SATB DMA and/or VRAM-VRAM DMA.
- The documents seem to indicate that this would abort the DMA, but Mednafen seems to put the CPU into WAIT until done. Which, if any, is correct ?
4) Misalignment of clock domain between VDC (5 MHz, 7.16 MHz, 10MHz) and CPU (7.16MHz):
- On a write, does the VWR act as the buffer between clocks, permitting non-blocking writes ? (I don't think the CPU can outrun the VDC, except maybe a 4-cycle access, 5MHz dotclock situation) If there is blocking, how does one calculate it ?
- On a read, how would blocking work ? (It may also be buffered by look-ahead into the VRR once MARR is calculated, reducing wait)
5) How about access to VDC registers (as opposed to memory) during all this ? Do they ever cause wait states ?
Any other cases to consider ?