Hi,
I have a growing interest in working with the PC Engine, and having read the most common documentation out there (MagicKit, MagicEngine, etc.) I have a few fairly specific questions that I could not find the answers to. I suspect that the system has not been torn to shreds as much as the NES, so there are still some unknown, very specific behaviors in the box. Hopefully I can learn some of those answers here.
- Transfer instructions:
+ What I'd need to know is how the transfer instructions are built up, especially since it might be the case that the TIMER or a VDC IRQ fires during the transfer instruction. Is the IRQ delayed until the transfer finishes (similarly to how OAM DMA blocks IRQ on the NES) or is the transfer interrupted and some point? Perhaps between two iterations?
- VDC Horizontal Sync and draw length registers:
+ I have once read that since the programmer can decide the screen layout and the usage of VRAM in a "tug of war" fashion between tile data and nametable data, a 512x240 virtual screen size is perfectly normal operation. However, the draw length register can allow you to set the speed of the pixel clock and actually show a 512x240 image on the screen. Sprites have a 9th X coordinate bit that helps with sprite-related issues if you do that, but apparently the VRAM is not supposed to be able to react fast enough to reads if the pixel clock speed is above a certain threshold. Is this actually true, and are there any known long-term consequences for showing the full 512 pixels wide image on the screen?
- VDC data access
+ Is the bus shared between the VDC and the HuC6280 in a manner that is similar to the NES architecture? Meaning that accessing VRAM outside of VBlank scanlines is discouraged and can result in potentially corrupting / writing to an unknown VRAM address?
- Detecting the end of VBlank / extending VBlank
+ Is there a VDC flag that can help you detect when VBlank ends, so that your main code can stay in sync with the VDC? (Starting game logic when VBlank is ended) Otherwise, is it possible to force blanking to make sure your NMI handler never spills out of VBlank and corrupts VRAM data, without NES-style sprite ram decay?
Thank you!
I have a growing interest in working with the PC Engine, and having read the most common documentation out there (MagicKit, MagicEngine, etc.) I have a few fairly specific questions that I could not find the answers to. I suspect that the system has not been torn to shreds as much as the NES, so there are still some unknown, very specific behaviors in the box. Hopefully I can learn some of those answers here.
- Transfer instructions:
+ What I'd need to know is how the transfer instructions are built up, especially since it might be the case that the TIMER or a VDC IRQ fires during the transfer instruction. Is the IRQ delayed until the transfer finishes (similarly to how OAM DMA blocks IRQ on the NES) or is the transfer interrupted and some point? Perhaps between two iterations?
- VDC Horizontal Sync and draw length registers:
+ I have once read that since the programmer can decide the screen layout and the usage of VRAM in a "tug of war" fashion between tile data and nametable data, a 512x240 virtual screen size is perfectly normal operation. However, the draw length register can allow you to set the speed of the pixel clock and actually show a 512x240 image on the screen. Sprites have a 9th X coordinate bit that helps with sprite-related issues if you do that, but apparently the VRAM is not supposed to be able to react fast enough to reads if the pixel clock speed is above a certain threshold. Is this actually true, and are there any known long-term consequences for showing the full 512 pixels wide image on the screen?
- VDC data access
+ Is the bus shared between the VDC and the HuC6280 in a manner that is similar to the NES architecture? Meaning that accessing VRAM outside of VBlank scanlines is discouraged and can result in potentially corrupting / writing to an unknown VRAM address?
- Detecting the end of VBlank / extending VBlank
+ Is there a VDC flag that can help you detect when VBlank ends, so that your main code can stay in sync with the VDC? (Starting game logic when VBlank is ended) Otherwise, is it possible to force blanking to make sure your NMI handler never spills out of VBlank and corrupts VRAM data, without NES-style sprite ram decay?
Thank you!