|
Post by dshadoff on Oct 27, 2018 2:02:30 GMT
I'm doing some research into headseek timing of real PC Engine hardware, so that emulation (both hardware and software) can be improved.
In talking with the UperGrafx creator, he brought to my attention several games which suffered from the fact that CDROM headseek timing wasn't correct on his device - and that Mednafen has virtually identical problems, as it also has a too-short, fixed headseek delay.
I was hoping that this thread could be used for reporting other games, for the purpose of gathering more information. Sound bugs, bad sounds, and desynchronizations are all fair game to report. (You'll see below, based on my first 4 reports)
Here are the games I am already aware about:
Downtown Nekketsu Monogatari: - if you set the text print speed to "fast", then go in (and quickly out of) the bookstore in the first town, upon your exit the shopgirl will say her thing, but the ADPCM will continue to speak various additional messages in a stream (bug). (Text speed of normal is enough of a delay that this is no longer an issue)
Double Dragon II: - at the Title screen press run, and a voice will start to speak "Double Dragon", but it will be cut off before completion. Actually, this is almost certainly going to happen on a real console as well, but to a much smaller degree (because the head seek is longer, but still shorter than the programmers made allowance for).
Super Darius: - at title screen, press run, and the game will start. The CD music should follow the ADPCM intro, but instead they overlap and sound like noise because of a too-short delay.
Mugen Senshi Valis: - during the opening cinema, everything seems OK until the girl enters the schoolyard. Then, some CD data gets fetched - but when the cinema starts up again, there is a severe desynchronization because the emulator starts playing sound immediately (but real hardware would be about 1.5 seconds later).
Please let me know about other games - especially on Mednafen, as it is easy for me to test with - so that I can gather more information. My intention is to share this information, and any conclusions I can make, with the UperGrafx creator, the authors of Mednafen, and anybody else who wants it.
Separately, I have a HuC program (and disc image) I created in order to test heads seek time on my TurboDuo; if anybody else would like to gather some data on real hardware to add to the dataset, please let me know (especially if you have the original CDROM drive in good working order).
Dave
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 27, 2018 4:32:25 GMT
Send em over via PM but don't forget to post your conclusions here later
|
|
|
Post by spenoza on Oct 28, 2018 1:03:03 GMT
I have a JPN Duo I could test headseek times for. I don’t emulate so much these days, though, so I am only so much help there.
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Oct 28, 2018 2:17:33 GMT
Heya Dave. You should beam that program over to me. I can check a Duo-RX and a Super CD-ROM. The latter, if you recall, is recapped but still has a finicky lens, so it may return some strange results.
|
|
|
Post by dshadoff on Oct 28, 2018 19:56:11 GMT
OK, it seems there is some healthy interest in performing the tests. Cool ! This is the program I wrote. seek2.zip (652.01 KB) It asks for two parameters in hexadecimal - the starting head position, and the offset (the destination location will be calculated). I made the program limit the source and target locations to the range of 000000 - 04FFFF (640MB). If you rebuild this ISO without using a 640MB binary file to append (i.e. the ISO is less than 640MB), you may cause damage by seeking beyond the leadout, so be careful if you are not using the included ISO file. Note: I had to remove the dummy file from the zip in order to keep the attachment within the 1 MB limit for this board; however, the actual ISO file is included. After source/offset values are set, the program will then create a series of 10 head seek movements/measurements: - move to start position - wait a random period before initiating the movement - reposition to target location, measuring how many VSYNCs (1/60th's of a second) were required. (repeat) The output numbers are in VSYNCs; you will see some variation (which is why I take 10 measurements). Note: Mednafen always returns 3; UperGrafx (currently) always returns 2. I am also attaching a series of my own measurements on my original TurboDuo, here: seek_analysis.xlsx (18.38 KB) Other hardware- I also tried on an old PI-CD1 (Super CD-ROM "helmet"-like attachment for CoreGrafx), and the numbers were slower, but I don't really trust my unit... I am also hearing other people who also see theirs as slower (but are also unsure whether it's a design or deterioration issue). - I expect that the original CD-ROM (if anybody can still find one in working condition) is also slower than the Duo, but I don't know by how much. - I expect the Duo-R and Duo-RX are basically the same as the Duo - I don't know how much variation there is among machines of the same type; it seems plausible that age has slowed some of them down - or possibly that replacement parts have sped them up ! Surprises:- Even trivial movements take a minimum of around 10 VSYNCs (1/6 of a second). - There seems to be more variation (at least on my machine) in movements ending near the inner part of the disc (lower sector numbers) than the outer part. Here is a sample seek for Mugen Senshi Valis (which I reported earlier), to get a good sense of the timing measurments: -> Seek from 0x1608, offset 0x2CDDA (target 0x2E3E2) - the game is expecting this travel to take around 104 VSYNCs (give or take a few); anything else will result in a desynchronization between audio and the animation. - Mednafen completes it in 3 VSYNCs, so the desynchronization is about 100 SYNCs, or 1.6 seconds (very apparent). I'm especially interested about variation among real hardware on this game. Dave
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Oct 29, 2018 6:07:29 GMT
Hey Dave.
Only one measurement for today, but on both of my systems:
Mugen Senshi Valis 0x801 - 0x2E3E2 (0x2DBE1 sectors)
Duo-RX
90 103 103 89 102 101 103 88 102 88
Min. 88 Avg. 96
Super CD-ROM
107 109 106 121 108 107 120 121 106 107
Min. 106 Avg. 111
|
|
|
Post by dshadoff on Oct 30, 2018 4:52:49 GMT
Those are pretty good numbers - a little better than my Duo, which had: 95 96 97 97 110 95 127 110 98 110
Min. 95 Avg. 103
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Oct 30, 2018 7:24:47 GMT
The difference could be due to my Duo-RX having fresh capacitors, but it could also be due to the Taiyo Yuden disk I used. What brand are you using for your tests, Dave?
I'm a little astonished to see 50 packs of Taiyo Yuden disks currently going for over 10,000 yen, although perhaps I shouldn't be. It sure is a shame that they got out of the business.
|
|
|
Post by dshadoff on Oct 30, 2018 15:26:59 GMT
I'm also using Taiyo Yuden discs that I bought several years ago. I'm probably down to my last 15 or so though - I wasn't expecting to see them become so expensive.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 30, 2018 16:40:20 GMT
I'm still setting up my Pioneer 212 to burn the disc, my laptop burner is very unreliable even with 650 Taiyo Yudens.
|
|
|
Post by Arkhan on Oct 31, 2018 18:05:57 GMT
I can do some testing. I have a Beemer Repaired(TM) CDROM drive.
I also might be coming into another Duo.
|
|
|
Post by dshadoff on Nov 2, 2018 20:39:14 GMT
I did some more testing. The first round was based on fixed-offset (# of sectors) movement; however, this is not entirely realistic as the CDROM groove is a spiral, with more sectors per revolution near the outer edge than near the inner edge. So those seeks were not fixed linear distances. Based on the the following facts, I did some tests related to 'linear movement' as opposed to 'movement of an absolute # of sectors': - sector 0 is the innermost, which is approximately 23mm from center - the outer edge of the CDROM should be about 58.5 mm from the center (and I have tried to approximate it with the 640MB image) - because of the constant linear velocity of the CDROM standard, each sector is of uniform length, but a different angular arclength, depending on how far from center it is. - expectation is that each groove is about 1.6um from its neighbour. The area of the CDROM was divided into 16 parts, where the head-seek distance between two adjacent parts should be the same. Then I did some more tests to check whether the seek time was related only to the head-seek distance, and found that this wasn't exactly the case either (inner seeks are still faster than outer seeks) - but it was closer than the original tests. Here are my results: seek_analysis2.xlsx (16.62 KB) Trying to explain this lingering difference, I realized that rotational latency may play a role: At the innermost portion of the disc, the motor spins at 530 RPM (roughly 8.83 times per second), so one entire revolution = 6.8 VSYNCs. Since you can't predict where in the rotation that the read will start, the average impact of this would be half of this, or 3.4 VSYNCs For the outermost portion, the motor spins at 200 ROM (roughly 3.33 times per second), so one entire revolution = 18 VSYNCs Again, average impact would be 9 VSYNCs. So this can explain part, but not all, of the difference (roughly 6 VSYNCs). One more interesting gem: The innermost area seems to have much larger variance in read timings (than the outermost), and they seem to fall into strict 'bands'. Looking at the seek_analysis2 spreadsheet, tab 1 column 1, we find: group 1 = 30 VSYNCs group 2 = 38, 39, 39, 39 -> about 8 VSYNCs (~1 rotation) later than the shortest group group 3 = 47, 47, 47, 47 -> about 8 VSYNCs (~1 rotation) later than the second-shortest group group 4 = 55 -> yet another 8 VSYNCs different So, it looks like a failure to read on one revolution just forces it to try again on the next revolution. But, why did it encounter more failures near the center than the outside ? I don't have the answer to that. Dave
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Nov 4, 2018 17:13:10 GMT
That reminds me of some of the trouble elmer and I ran up against when doing the Zeroigar translation on the PC-FX. When we added hard-coded subtitles to the FMV sequences and re-formed the video data stream, we often pushed up against the limits of the drive's read-buffer. Whenever the system encountered an underrun, it would simply drop the video and load whatever was supposed to follow it - a rather undesirable outcome for such a story-intensive game. There were certain cases where it would sometimes play a subtitled video completely and sometimes fail, and what we (and by we, I mean elmer) figured out was that it was a matter of luck based on whether the drive would have to wait for the disc to make an extra revolution in certain spots. In the end, we tried to limit the amount of bandwidth that the subtitles took up so that the risk of the buffer underrunning was minimized.
Much to my regret as a translator, this meant simplifying certain lines so that fewer letters were used. The original draft of the script had quite a few more three-or-four syllable words in it than the final, and the modifications I had to make for the sake of the CD buffer made me feel like things got dumbed down just a bit. Not that I'm unsatisfied with the product overall, though - given the circumstances, I think the right choices were made.
|
|