|
Post by elmer on Jan 22, 2019 21:43:01 GMT
Placeholder for indexing.
|
|
|
Post by elmer on Jan 22, 2019 21:43:19 GMT
Placeholder for indexing.
|
|
|
Post by elmer on Jan 22, 2019 21:43:37 GMT
; *************************************************************************** ; PC ENGINE VCE TIMING ; *************************************************************************** ; ; 21.47727MHz VCE clock crystal / 4 -> 5.36MHz VDC clock (186ns) ; 21.47727MHz VCE clock crystal / 3 -> 7.16MHz VDC clock (140ns) ; 21.47727MHz VCE clock crystal / 2 -> 10.74MHz VDC clock ( 93ns) ; ; 63.556us /hsync to /hsync total line time, i.e. 15734.2Hz NTSC ; ; 1365 VCE clocks @ 21.47727MHz ; ; -> 341.25 VDC cycles @ 5.36MHz (42.7 chr) ; -> 455.00 VDC cycles @ 7.16MHz (56.9 chr) ; -> 682.50 VDC cycles @ 10.74MHz (85.3 chr) ; ; 11.035us /hsync duration ; ; 237 VCE clocks @ 21.47727MHz ; ; -> 59.25 VDC clocks @ 5.36MHz ; -> 79.00 VDC clocks @ 7.16MHz ; -> 118.50 VDC clocks @ 10.74MHz ; ; Note : In the 5.36MHz mode, the 1st cycle in the hblank ; has an extra 1/4 cycle added (1 clock @ 21.47MHz). ; ; 16.651ms /vsync to /vsync total frame time, if VCE CR bit2 is 0 ; ; 357,630 VCE clocks @ 21.47727MHz ; ; -> 119,210 CPU clocks @ 7.16MHz ; ; 16.715ms /vsync to /vsync total frame time, if VCE CR bit2 is 1 ; ; 358,995 VCE clocks @ 21.47727MHz ; ; -> 119,665 CPU clocks @ 7.16MHz ; ; 1.907ms /vsync duration ; ; 4,095 VCE clocks @ 21.47727MHz ; ; -> 1,365 CPU clocks @ 7.16MHz ;
; *************************************************************************** ; PC ENGINE VDC SPRITES-PER-LINE LIMITS ; *************************************************************************** ; ; This is caused by the VDC running out of time to load the pixel data for ; the next line's sprites during the blank time after it is done displaying ; the current line's pixel data. ; ; ; VDC @ 5.36MHz -> width = total # chr on line = 42 chr ; VDC @ 7.16MHz -> width = total # chr on line = 56 chr ; VDC @ 10.74MHz -> width = total # chr on line = 85 chr ; ; Sprites-per-line shown (@ 1-clk-per-access) = (width - 2 - (hdw + 1)) * 2 ; Sprites-per-line shown (@ 2-clk-per-access) = (width - 2 - (hdw + 1)) ; ; ; VDC @ 5.36MHz, MWR=$x0 (1-clk-per-access) ; ; hds $02 hdw $1F -> 32 chr = 256 pxl -> 16 sprites ; hds $02 hdw $20 -> 33 chr = 264 pxl -> 14 sprites ; hds $02 hdw $21 -> 34 chr = 272 pxl -> 12 sprites ; ; ; VDC @ 7.16MHz, MWR=$x0 (1-clk-per-access) ; ; hds $06 hdw $25 -> 38 chr = 304 pxl -> 16 sprites ; ... ; hds $03 hdw $2B -> 44 chr = 352 pxl -> 16 sprites ; hds $03 hdw $2C -> 45 chr = 360 pxl -> 16 sprites ; hds $03 hdw $2D -> 46 chr = 368 pxl -> 16 sprites ; hds $03 hdw $2E -> 47 chr = 376 pxl -> 14 sprites ; hds $03 hdw $2F -> 48 chr = 384 pxl -> 12 sprites ; ; ; VDC @ 7.16MHz, MWR=$xA (2-clk-per-access) ; ; hds $06 hdw $25 -> 38 chr = 304 pxl -> 16 sprites ; hds $05 hdw $26 -> 39 chr = 312 pxl -> 15 sprites ; hds $05 hdw $27 -> 40 chr = 320 pxl -> 14 sprites ; hds $04 hdw $28 -> 41 chr = 328 pxl -> 13 sprites ; hds $04 hdw $29 -> 42 chr = 336 pxl -> 12 sprites ; hds $03 hdw $2A -> 43 chr = 344 pxl -> 11 sprites ; hds $03 hdw $2B -> 44 chr = 352 pxl -> 10 sprites ; ; ; VDC @ 10.74MHz, MWR=$xA (2-clk-per-access) ; ; hds $0B hdw $3B -> 60 chr = 480 pxl -> 16 sprites ; ... ; hds $0B hdw $3F -> 64 chr = 512 pxl -> 16 sprites ; hds $0B hdw $40 -> 65 chr = 520 pxl -> 16 sprites ; hds $0B hdw $41 -> 66 chr = 528 pxl -> 16 sprites ; hds $0B hdw $42 -> 67 chr = 536 pxl -> 16 sprites ; hds $0B hdw $43 -> 68 chr = 544 pxl -> 15 sprites ; hds $0B hdw $44 -> 69 chr = 552 pxl -> 14 sprites ;
; *************************************************************************** ; PC ENGINE VDC RCR INTERRUPT TO BYR SHADOWED TIMING ; *************************************************************************** ; ; ; 5.36MHz (with MWR = $x0) ; ; Safe to write BYR @ 100 cpu cycles if width=240 hdw=$1D ; Safe to write BYR @ 90 cpu cycles if width=248 hdw=$1E ; Safe to write BYR @ 79 cpu cycles if width=256 hdw=$1F ; Safe to write BYR @ 67 cpu cycles if width=264 hdw=$20 ; ; ; 7.16MHz (with MWR = $x0) ; ; Safe to write BYR @ 106 cpu cycles if width=320 hdw=$27 ; Safe to write BYR @ 98 cpu cycles if width=328 hdw=$28 ; Safe to write BYR @ 90 cpu cycles if width=336 hdw=$29 ; Safe to write BYR @ 82 cpu cycles if width=344 hdw=$2A ; Safe to write BYR @ 74 cpu cycles if width=352 hdw=$2B ; ; ; 10.74MHz (with MWR = $xA) ; ; Safe to write BYR @ 112 cpu cycles if width=480 hdw=$3B ; Safe to write BYR @ 107 cpu cycles if width=488 hdw=$3C ; Safe to write BYR @ 101 cpu cycles if width=496 hdw=$3D ; Safe to write BYR @ 96 cpu cycles if width=504 hdw=$3E ; Safe to write BYR @ 91 cpu cycles if width=512 hdw=$3F ; Safe to write BYR @ 85 cpu cycles if width=520 hdw=$40 ; Safe to write BYR @ 79 cpu cycles if width=528 hdw=$41 ; Safe to write BYR @ 75 cpu cycles if width=536 hdw=$42 ; Safe to write BYR @ 69 cpu cycles if width=544 hdw=$43 ; ; ; Note: The VDC's hde,hsw, & hds settings have *NO* effect!!! ; ; Note: These cycle timings are to the write-cycle within the ; instruction, and not to the start of the instruction. ; ; Note: The VDC shadows/locks the BYR register a cycle before ; the BXR register, so write BYR first. After BXR, the ; CR register is shadowed/locked next. ;
|
|
|
Post by elmer on Jan 22, 2019 23:40:36 GMT
Placeholder for content (this is a big subject!).
|
|
|
Post by elmer on Jan 23, 2019 1:43:43 GMT
Continuing on from the Why are PCE games that use >= 320 horizontal res so rare? thread ... What is the point to use more than 344 pixels in 7.16mhz ? To guarantee completely filling the TV screen right up to the edges, even in the middle of the screen where the edge-to-edge distance on the TV-tube is the largest? Kinda pointless IMHO, but if you aren't setting the VDC into 2 clocks-per-cycle mode, then there isn't any downside to running with 352 pixels instead of 344 pixels. Anyway, I'm reading the documentation and I think I kinda get it now. This is not as hard as I thought it would be but I still have some questions: If we stick to the Access Width = 1 setting in R09 the VDC has enough time to do everything on valid scanline settings? Short answer ... yes. Longer answer ... run the numbers yourself, and you'll still get "yes". How about hi-res 512 horizontal pixels? If it's 10MHz then VRAM access width = 1 is too fast? Do you have to actually set it to 2 for everything to work properly? Well, the VRAM is specified for a 120ns cycle time, and at 10.7MHz the cycle time is 93ns, which would be a 30% overclock. So, the answer would be "yes", you should definitely set the VDC into 2-clock mode when using high-resolution. Now ... in practice, my PCE hardware seems to work perfectly OK in 1-clock mode when using high-resolution, but now that I know, I'll switch it into 2-clock mode instead and avoid the overclocking. There's no downside to using the 2-clock mode, because even with a 512-wide screen, the hardware has plenty of time to load/display all 16 sprites. What changes the VDC's internal clock, the setting itself? Huh? What do you mean? The VDC uses an external clock, it comes from the VCE. VDW is 9 bits, what stops us from having a 512 vertical res signal, the hardware or the NTSC standard? The VCE ... in order to provide a standard (or close-enough-to-standard) NTSC signal so that the TV will display it correctly and not freak-out. Is HSW the horizontal blanking interval? Yes ... and no. Yes it is. But it is mostly ignored in the PC Engine because VCE is in charge of the overall NTSC display timing, and the VCE sends hsync and vsync signals to the VDC that override the VDC's own internal timings. The VDC's HSW and HDE timings seem to be mainly there for use if the VDC is controlling the display output directly, presumably for use in arcade machines with an RGB arcade monitor. I believe that Hudson were planning ahead for the future. If I set the horizontal resolution to 240, the formula on the manual claims that there's only time to fetch 63 out of 64 sprites from SAT when in width = 1 , is that correct? You've got the right idea, but your math is wrong. 240 resolution means an HDW setting of 29, not 30, so it is actually only 61 sprites, not 63. It's kinda odd that reducing the number of characters to be displayed horizontally also reduces the time to find stuff in the SAT. Not really, it just tells us how the VDC design works internally. The VDC scans its internal SATB sprite list during the time that the previous line is being displayed, and then, during the blank period, when the VDC doesn't need to read background pixels from VRAM anymore, it loads up the actual pixel data for the sprites that are going to be displayed on the next line. It's a simpler and (IMHO) more elegant way of deciding what to draw than constructing a line-buffer the way that the SNES and Genesis do. BUT ... it does have its downside. It's not as flexible a technique as having a line-buffer, or later on, from the 5th-generation machines onwards, a full frame-buffer. I think that's it for now. Thank gawd, I'm tired from all this typing!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 23, 2019 2:33:46 GMT
Placeholder for thanks and further questions.
(You got us hyped with how many posts you reserved ^^ thanks for the answers)
|
|
|
Post by ccovell on Jan 23, 2019 4:17:42 GMT
I look forward to the detailed explanation by Elmer. Until then, people can test out screen sizes / resolutions on real hardware using my Screen Dimension Test prog: www.chrismcovell.com/data/Screen_Dimension_Test.zipI had made a newer version a couple of years ago showing 64 sprites on-screen (squares in lower-left corner) because I was also surprised to hear how narrowing the screen started dropping sprites.
|
|
|
Post by dshadoff on Jan 23, 2019 4:24:14 GMT
Very cool Chris !!
|
|
|
Post by elmer on Jan 23, 2019 6:24:13 GMT
Thanks for that Chris, it's an absolutely wonderful test program! I used it again yesterday to confirm that changing the HDE and HSW settings basically had no effect on the TV's display (unless they're so tiny that the VDC starts spitting out pixel data when it shouldn't!). That clearly shows (IMHO) that the VCE is overriding the VDC's HDE & HSW settings, and that the VDC starts its HDS period when the VCE raises the /hsync input at the start of the line. Which makes sense when you look at the EX bits in the VDC's CR register, which all games set to %00, meaning that the VDC's /vsync and /hsync pins are set as inputs controlled externally by the VCE. I look forward to the detailed explanation by Elmer. Hudson's official docs are quite clear in what is happening, but I'm writing a simple test program so that we can all confirm this stuff on real hardware and make sure that the docs aren't wrong. This is all just weird edge-cases that Charles MacDonald didn't discover/document when he was doing his magnificent investigations that helped kick off the whole PCE emulation & homebrew scene.
|
|
|
Post by ccovell on Jan 23, 2019 7:38:43 GMT
Hey, Dave! Quote / insert this image to complete the effect!
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jan 23, 2019 8:10:40 GMT
It' a strange choice because all pixels over 344 are in the overscan and non visible . 336 pixels is considered as a safe resolution, and from my tests 344 is the classic one for a 7.16 dot clock .
My SGX works fine too,i think we can thanks the SRAM memories.
Good to know that .
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Jan 23, 2019 8:53:19 GMT
It' a strange choice because all pixels over 344 are in the overscan and non visible . 336 pixels is considered as a safe resolution, and from my tests 344 is the classic one for a 7.16 dot clock . My guess on one reason for using such high resolution was with arcade ports where the source materials used a relatively high horizontal resolution(R-Type, Capcom games, etc.) to make them more "faithful", even though there was no benefit in doing so.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jan 23, 2019 9:09:06 GMT
i understand, but here setting your screen at 352 or 336/344 pixels change nothing in the aspect ratio because the dotclock remain the same .
A quick question which come in mind is, how this can works ??,a 30% overclock is massive and should cause some (many ?) artifacts on screen, and however i don't have any such of things on my SGX,even with a 1 cycle access .
|
|
|
Post by dshadoff on Jan 23, 2019 14:15:08 GMT
i understand, but here setting your screen at 352 or 336/344 pixels change nothing in the aspect ratio because the dotclock remain the same . A quick question which come in mind is, how this can works ??,a 30% overclock is massive and should cause some (many ?) artifacts on screen, and however i don't have any such of things on my SGX,even with a 1 cycle access . By today's standards, perhaps. But back then, it was not uncommon to be able to double-speed something.... the parts just weren't warranted for it, so "you may cause damage". There was no speed-binning, no spec revisions on step-updates... Heck, there were many cases where the manufacturer went to a new process (die shrink) for cost reasons, and only verified that the previous operational specs were still met. No new part number, no new timing specs... because the previous part number was so popular. The downside of this is that you will have no idea how many of the units "in the wild" will be able to support the overclock. Dave
|
|
|
Post by dshadoff on Jan 23, 2019 15:08:46 GMT
Hey, Dave! Quote / insert this image to complete the effect! Sorry, I don't get the reference... is that from one the Madness videos ? My alternate thought was to use an animated GIF of "the Rimmer experience" (from Red Dwarf) as an avatar, but I felt that reference might be a little too obscure... Dave
|
|