touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jan 23, 2019 15:27:06 GMT
Ok, i'll use the 2 cycles access for the 10.76 mhz dotclock now,i don't thought you can damage something.
|
|
|
Post by dshadoff on Jan 23, 2019 16:13:56 GMT
Ok, i'll use the 2 cycles access for the 10.76 mhz dotclock now,i don't thought you can damage something. These were the manufacturers' words of the era. What we've learned in the years since then is that such "damage" really doesn't happen often; however they wanted to ensure that they were not liable if it did happen. The classic overclock issues that one would encounter would be dropouts as you mention, or system lockups. Dave
|
|
|
Post by ccovell on Jan 23, 2019 23:20:01 GMT
Sorry, I don't get the reference... is that from one the Madness videos ? At least in Japan, Madness (and their 'walk') was always associated with the Honda City ads & TV commercials in the early '80s.
|
|
|
Post by dshadoff on Jan 24, 2019 0:37:08 GMT
Sorry, I don't get the reference... is that from one the Madness videos ?
At least in Japan, Madness (and their 'walk') was always associated with the Honda City ads & TV commercials in the early '80s.
Gotcha ! That's why I didn't get the reference - I wasn't in Japan at the time Even here, it was still high school days for me... I expect car ads were targeting people who actually had money to spend. Dave
|
|
|
Post by elmer on Jan 24, 2019 19:56:24 GMT
Does anyone know if there were any logic-analyzer/oscilloscope tests done to confirm the PCE's *exact* hsync timing?
I've only just realized that we have the pinout for all of Hudson's proprietary PCE chips in the "TurboGrafx 16 Service Manual" that I found online sometime ago.
That information is missing from Hudson's official Development docs.
One thing that seeing the pinout confirms is that the CPU has a RDY input, and the VDC has a BUSY output, and so (presumably) the VDC can halt the CPU to extend bus-cycles when necessary (such as when the CPU tries to read/write VRAM while the VDC is reading the pixel data for the next line of sprites).
|
|
|
Post by dshadoff on Jan 24, 2019 21:14:37 GMT
Does anyone know if there were any logic-analyzer/oscilloscope tests done to confirm the PCE's *exact* hsync timing? I've only just realized that we have the pinout for all of Hudson's proprietary PCE chips in the "TurboGrafx 16 Service Manual" that I found online sometime ago. That information is missing from Hudson's official Development docs. One thing that seeing the pinout confirms is that the CPU has a RDY input, and the VDC has a BUSY output, and so (presumably) the VDC can halt the CPU to extend bus-cycles when necessary (such as when the CPU tries to read/write VRAM while the VDC is reading the pixel data for the next line of sprites). While I'm not the authoritative source, I've been around a while - and unless Charles MacDonald did some, I'm not aware of any... in our "Western" pcedev community. Most of the people who have worked hard to emulate the system are more on the software side, and probably don't even own an oscilloscope. (On second thought, it's possible that Tomaitheous was playing with something like this for a brief period about 5-7 years ago...) Having said that, it is the kind of thing that may be possible among Japanese enthusiasts. If there is a very specific question (i.e. a specific test for example), I may be able to ask one of the people I know - however, but vague questions are not likely to be answered. "*exact* hsync timing" sounds like it's dependent on VDC/VCE register values (i.e. lots of tests, lots of answers), which might be too much to ask. Or, perhaps one of our wonderful repair enthusiasts can help run a test or two... Dave
|
|
|
Post by elmer on Jan 24, 2019 22:32:04 GMT
Having said that, it is the kind of thing that may be possible among Japanese enthusiasts. If there is a very specific question (i.e. a specific test for example), I may be able to ask one of the people I know - however, but vague questions are not likely to be answered. "*exact* hsync timing" sounds like it's dependent on VDC/VCE register values (i.e. lots of tests, lots of answers), which might be too much to ask. Unless I'm going off into some fantasy-land, the VDC seems to be taking its hsync reference timing from an external signal (i.e. the VCE), and not relying on its own internal hsync timing (from the HSW register). The games that I've looked at are definitely setting the VDC's EX register to external mode, and so the VDC is NOT outputting hsync or vsync information to the VCE when the VCE is creating the TV signal that is output. Unlike the VDC, the VCE doesn't have any user-settings to change the screen mode, just the one setting to control the pixel-clock that is sent to the VDC. So, if the VCE is generating the hsync and vsync signals, then the hsync signal should be either at a fixed rate or a variable rate that depends upon the resolution (i.e. the pixel-clock). If it is fixed, then I'm *guessing* that it would be 342 pixel-clocks @5.36MHz, for a 15699.8KHz hsync rate, but it *could* be 341.25 pixel-clocks @ 5.36MHz, which is the standard NTSC rate of 15734.2Hz ... or it could vary depending upon the pixel-clock, say 341 pixel-clocks @ 5.36MHz for 15745.8Hz, just like the NES, but with different value, say 455 pixel-clocks @ 7.16MHz for 15734.2Hz. This could be checked by testing the hsync pin on the VCE/VDC and using Chris's Screen Dimension program to change resolutions. This all goes into getting a better understanding of exactly how the VCE and VDC interact with each other ... because it has an effect upon programming the system. Where this whole rabbit-hole is leading, is that the CPU is *probably* delayed if it is trying to read/write VRAM in the non-display period while the VDC is reading the pixel data for the next line's sprites, and that delay is going to change depending upon the VCE's pixel-clock, the VDC's clocks-per-access setting, and the number of sprites that are going to be displayed on the next line. That has a potential effect upon the timing of raster interrupts, and it could help to explain *why* programmers like TheOldRover have found some seemingly "random" instability in HuC's raster-interrupt-driven splitscreen functionality. I'll be able to test *if* this delay exists with a test program.
Stable interrupt-handling was one of the core banes of game developer's work on early consoles, and I'd really like to get this timing understood so that I can write a rock-solid system for the community's future development use.
|
|
|
Post by ccovell on Jan 24, 2019 23:47:10 GMT
So, if the VCE is generating the hsync and vsync signals, then the hsync signal should be either at a fixed rate or a variable rate that depends upon the resolution (i.e. the pixel-clock). If it is fixed, then I'm *guessing* that it would be 342 pixel-clocks @5.36MHz, for a 15699.8KHz hsync rate, but it *could* be 341.25 pixel-clocks @ 5.36MHz, which is the standard NTSC rate of 15734.2Hz ... or it could vary depending upon the pixel-clock, say 341 pixel-clocks @ 5.36MHz for 15745.8Hz, just like the NES, but with different value, say 455 pixel-clocks @ 7.16MHz for 15734.2Hz. This could be checked by testing the hsync pin on the VCE/VDC and using Chris's Screen Dimension program to change resolutions. I don't know if this proves or disproves it, but between resolution changes, the horizontal start of the active (pixel) display is different between the 3 resolutions, and can never be aligned perfectly. The 7.16Mhz mode I can understand, but with the 10Mhz mode being a double of the 5 Mhz one, the 512-pixel resolution should at least start at the same position of the 256-pixel one, just with twice the horizontal granularity settable by the HDS register... only this is not the case.
Has anyone else noticed this?
|
|
|
Post by dshadoff on Jan 25, 2019 0:52:29 GMT
Maybe I misunderstood the original question - were you asking about the duration of one scan-line (hsync frequency) - i.e. from pixel #1 of scan line #1 to pixel #1 of scan line 2 ?
Because for some reason, I had interpreted the question as to whether the horizontal blanking period was fixed or variable (i.e. how long does the HSYNC signal stay active then delay before pixels). i.e. from last pixel on scan line 1 to first pixel of scan line 2.
Something tells me that you would need to answer both questions.
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Jan 25, 2019 1:53:53 GMT
Does anyone know if there were any logic-analyzer/oscilloscope tests done to confirm the PCE's *exact* hsync timing? Tim Worthington, aka viletim and the creator of the NES RGB board, did just this back when I was bugging everyone under the sun to help me learn why PCE sync doesn't get along with certain broadcast monitors. This archive contains both the data he recorded and two versions of the program necessary to view it. If the newer version doesn't work, try the older one. He took his readings directly from the PCE's internal HSYNC, VSYNC, CSYNC and OSC lines. www.dropbox.com/s/tap7ksk8vyyvz1o/pce%20sync.rar?dl=1Note that I have no idea what game he was looking at. This Japanese blog might also be of interest: poorcore.blog.fc2.com/blog-entry-10.htmlThere are two images you can view by scrolling down: one of Dragon Spirit and another of R-Type. The red line is the output of an EL1883 sync separator that was being fed the PCE's composite video output; orange is the dot clock, and yellow is HSYNC.
|
|
|
Post by elmer on Jan 25, 2019 2:49:50 GMT
Has anyone else noticed this? Yep, it's an interesting mystery, isn't it? Maybe I misunderstood the original question - were you asking about the duration of one scan-line (hsync frequency) - i.e. from pixel #1 of scan line #1 to pixel #1 of scan line 2 ? Because for some reason, I had interpreted the question as to whether the horizontal blanking period was fixed or variable (i.e. how long does the HSYNC signal stay active then delay before pixels). i.e. from last pixel on scan line 1 to first pixel of scan line 2. Something tells me that you would need to answer both questions. The figure that we can't really get accurately from a programming test, is the start-of-hsync to start-of-next-hsync timing, and whether that changes in the different resolutions. That should be easy for someone with the right hardware to test. The start-of-hsync to start-of-display is going to depend upon both the hsync width itself, generated by the VCE, and the HDS setting in the VDC ... and it is not something that we need massively high-precision accuracy on. We just need to know when it is safe to write the scroll registers, and that is something that we can determine (with enough practical accuracy) by doing some programming tests. It would certainly be very *nice* to know how long the VCE holds the hsync pin low (in nanoseconds, i.e. clocks), and whether the hsync width is dependent upon the resolution (i.e. the clock speed), but we can muddle by without that information and just rely on the empirical results from programming tests if we need to. Tim Worthington, aka viletim and the creator of the NES RGB board, did just this back when I was bugging everyone under the sun to help me learn why PCE sync doesn't get along with certain broadcast monitors. ... Thanks, Sam!!! I'll take a look to see what is in the archive, but the blog post itself provides useful data, in that there is that fixed delay in there (counted in 21MHz cycles) that doesn't depend upon the current pixel-clock. Fascinating stuff!
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Jan 25, 2019 3:40:38 GMT
Glad I could help. Let me know what you find!
|
|
|
Post by elmer on Jan 25, 2019 8:13:26 GMT
Something tells me that you would need to answer both questions. Luckily for me, the information that SamIAm has provided has given me the data what I wanted, so we won't need to pester your friends in Japan! Let me know what you find! OK, here you go! The raw logic-analyzer data from Tim Worthington gives us the horizontal line timing and hsync duration, and the Japanese blog that you link to confirms Tim's data, and it also confirms that the hsync duration is constant whatever the pixel resolution is. Here are the logic-analyzer pics from the blog, merged together to show that the timing is the same with both the 5.36MHz and 7.16MHz pixel clocks. Note that in the 5.36MHz timing on the bottom, the 1st clock pulse after the /hsync is lowered (the yellow line) is extended by 1/4 cycle (== 1 clock @21.47MHz) to make the timing work. And here is the collated data ... ; *************************************************************************** ; PC ENGINE VDC TIMING ; *************************************************************************** ; ; 21.47727MHz clock crystal / 4 -> 5.36MHz VCE clock (186ns) ; 21.47727MHz clock crystal / 3 -> 7.16MHz VCE clock (140ns) ; 21.47727MHz clock crystal / 2 -> 10.74MHz VCE clock ( 93ns) ; ; Confirmed : 63.556us /hsync to /hsync total line time, i.e. 15734.2Hz NTSC ; ; 1365 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) ; ; Confirmed : 11.035us /hsync duration ; ; 237 clocks @ 21.47727MHz ; ; -> 59.25 VDC cycles @ 5.36MHz ; -> 79.00 VDC cycles @ 7.16MHz ; ; Note : In the 5.36MHz mode, the 1st cycle in the hblank ; has an extra 1/4 cycle added (1 clock @ 21.47MHz).
|
|
|
Post by elmer on Jan 26, 2019 2:15:42 GMT
Again ... thanks for that Chris, it's an incredibly useful test progam! To save myself some time, I just hacked your program to set the PCE into 2-clocks-per-cycle mode instead of its normal 1-clock-per-cycle. Anyone can do that, and run their own tests, just by changing the byte at offset $2679 in the ROM from $20 to $2A. I tested things on a SuperGrafx and a CoreGrafx II (using my TurboEverdrve), and I have updated the other thread with the results for all of the games that I tested. The results show that switching into the 2-clock-per-cycle mode for medium-resolution displays loses us even more sprites-per-line than predicted by Hudson's official PCE documentation. I believe that the difference can be explained by the documentation being written for when the VDC is in complete control of the display timing, rather than having the VDC being under the control of the VCE's hsync and vsync signals, the way that the PCE is actually designed. But beyond that, I'm still trying to figure out what else the results tell us.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 26, 2019 2:52:33 GMT
I guess the whole lesson here is: USE WIDTH 1 ALWAYS. That really hurts, and I used to think the flicker in R-Type (US) was just due to poor sprite composition...
The 10 mhz dotclock is thus reserved only to bg layer only games. RIP.
|
|