I've taken a few days off from CD-i work, mainly to catch some sleep. So there is only a small amount of progress to report today.
Yesterday I wrote and debugged proper IFF reading code. Well, it turns out the IFF reader itself was pretty much "obviously" correct but there were major bugs in the interaction of buffering and the SetPosition / SetLimit functions of my CArchive class.
Once finished, I added rudimentary IFF dump code (just chunk header info) to cdifile and proceeded to use that to test the IFF code against some "real" files (mainly WAVE and AVI).
Using my "bad" Burn:Cycle AVI from before I found the cause of the badness: the dwLength field of the audio 'strh' chunk was ridiculously large. Turns out I misread Media Player: the AVI claimed an audio length of 33 minutes although in reality it was only about 6. It had to be some bug in the aviio.c file that I've taken from MESS/MAME (this is allowed by the license for that file, which is now BSD).
I did come code reading and tried some "obvious" fixes, but not until I added tracing code today did I find the culprit: the total number of samples was being incremented way too much on each audio buffer flush. The fix was an obvious oneliner that I've also submitted to MAME and MESS.
You can download the fix here.
Tuesday, November 24, 2009
Thursday, November 19, 2009
Burn:Cycle on YouTube
It turns out that Ultra MP4 Video Converter could handle my "bad" AVI file, although the trial version only does the first five minutes. That's all right as the video contained no interesting stuff after that :-)
You can see it here.
You can see it here.
AVI writing fixed and some fast machine issues
In a new attempt to get a usable Burn:Cycle movie out of CD-i Emulator, I decided to add multiple PNG writing as a poor substitute for AVI writing. After all, if you have the images and audio, you can always postprocess them into a movie!
I hooked up the PNG writing code from MESS/MAME, which seemed simple enough. There was the small matter of adding 24 bits per pixel bitmap support (their code handles 16 and 32 but not 24 which is however the internal format of CD-i Emulator; I had already partially added such support for the AVI writing code).
However, the resulting PNG files would not display in Explorer or any other image tool, giving messages like 'Bad file format' and 'Cannot read'. In exploring the cause for this, I was looking at memory buffers being filled and suddenly noticed that they where being filled in little-endian byte order, which is definitely wrong as PNG is a big-endian byte order file format.
The source of the problem turned out the be a configuration error with the MESS/MAME code: it needs a macro LSB_FIRST so it knows that it's running on a little-endian machine, and I had forgotten to give it one. When I fixed this, the PNG files came out right. And even better, the AVI files suddenly also seemed correct (not surprisingly, as they use the same byte order flipping macros as the PNG writing code).
So now I have both PNG writing and AVI writing hooked up in CD-i Emulator. I proceeded to do some timing tests and in the process added a few new writing options. The -writesilent option writes AVI files without audio; the -writerate option sets the framerate for the AVI files.
Full framerate AVI files still play "jumpy" on my machine but that's caused by their uncompressedness (is that even a word?); if you convert them to MP4 for uploading they play perfectly.
I uploaded a first test to YouTube; you can see it here.
If you set the AVI framerate low enough, you can do real-time movie captures. On my slow home machine I can do real-time capturing with -writerate 2 or less (which gives very jumpy AVI files, but the audio is correct).
To do non-realtime movie rendering you need to use the input recording and playback options. I did that for one of my Burn:Cycle recordings (not a very good one, but it's hard to play on my machine as the framerate it really too low and as a result the mouse gets jerky, which makes you overshoot your targets, which results in easy death at the hands of the security people).
The rendering proceeded at about 15% real-time speed while I was typing the above and is now finished; it gave me an AVI file of 27 GB for a nearly 7 minute session. There's something wrong with that file; Media Player claims it's only 33 seconds but proceeds to play all 7 minutes of it. Huh?
I also have problems converting it to MP4, probably caused by the same problems. Currently testing conversion programs to find one that can handle it...
During all of the fast machine testing yesterday, I also noticed that after a few minutes the audio begins to lag behind when it shouldn't. This is probably caused by the audio not being decoded at exactly 44.1 kHz relative to the PC timers (or something like that). When audio is playing, it really needs to be taken as the master clock for emulation speed control but that is somewhat hard with the current speed control code. Not for this beta. To ameliorate the problem, I've added a "Flush Audio" option (keyboard shortcut Ctrl-F) that allows you to manually flush the lagging audio so that it regains emulation sync.
Yesterday I also started adding proper IFF reading code, as opposed to the basic version handling only a single large data chunk that is currently used by the input playback code. This is needed so I that can properly finish the recording and playback functionality.
The beta release seems to be coming nearer...
I hooked up the PNG writing code from MESS/MAME, which seemed simple enough. There was the small matter of adding 24 bits per pixel bitmap support (their code handles 16 and 32 but not 24 which is however the internal format of CD-i Emulator; I had already partially added such support for the AVI writing code).
However, the resulting PNG files would not display in Explorer or any other image tool, giving messages like 'Bad file format' and 'Cannot read'. In exploring the cause for this, I was looking at memory buffers being filled and suddenly noticed that they where being filled in little-endian byte order, which is definitely wrong as PNG is a big-endian byte order file format.
The source of the problem turned out the be a configuration error with the MESS/MAME code: it needs a macro LSB_FIRST so it knows that it's running on a little-endian machine, and I had forgotten to give it one. When I fixed this, the PNG files came out right. And even better, the AVI files suddenly also seemed correct (not surprisingly, as they use the same byte order flipping macros as the PNG writing code).
So now I have both PNG writing and AVI writing hooked up in CD-i Emulator. I proceeded to do some timing tests and in the process added a few new writing options. The -writesilent option writes AVI files without audio; the -writerate option sets the framerate for the AVI files.
Full framerate AVI files still play "jumpy" on my machine but that's caused by their uncompressedness (is that even a word?); if you convert them to MP4 for uploading they play perfectly.
I uploaded a first test to YouTube; you can see it here.
If you set the AVI framerate low enough, you can do real-time movie captures. On my slow home machine I can do real-time capturing with -writerate 2 or less (which gives very jumpy AVI files, but the audio is correct).
To do non-realtime movie rendering you need to use the input recording and playback options. I did that for one of my Burn:Cycle recordings (not a very good one, but it's hard to play on my machine as the framerate it really too low and as a result the mouse gets jerky, which makes you overshoot your targets, which results in easy death at the hands of the security people).
The rendering proceeded at about 15% real-time speed while I was typing the above and is now finished; it gave me an AVI file of 27 GB for a nearly 7 minute session. There's something wrong with that file; Media Player claims it's only 33 seconds but proceeds to play all 7 minutes of it. Huh?
I also have problems converting it to MP4, probably caused by the same problems. Currently testing conversion programs to find one that can handle it...
During all of the fast machine testing yesterday, I also noticed that after a few minutes the audio begins to lag behind when it shouldn't. This is probably caused by the audio not being decoded at exactly 44.1 kHz relative to the PC timers (or something like that). When audio is playing, it really needs to be taken as the master clock for emulation speed control but that is somewhat hard with the current speed control code. Not for this beta. To ameliorate the problem, I've added a "Flush Audio" option (keyboard shortcut Ctrl-F) that allows you to manually flush the lagging audio so that it regains emulation sync.
Yesterday I also started adding proper IFF reading code, as opposed to the basic version handling only a single large data chunk that is currently used by the input playback code. This is needed so I that can properly finish the recording and playback functionality.
The beta release seems to be coming nearer...
Tuesday, November 17, 2009
Fast machines, file writing and some bits
Today I used my work PC to examine CD-i Emulator on a fast machine.
It turns out that cpu throttling was already there; titles run at the right speed. However, the frame skip detection logic is too sensitive: it will skip frames even on fast hardware, just because of a momentary slowness (I think). I added an option -noskip to turn off frame skipping altogether; beter autodetection is too much for this beta.
Likewise, for people who always want to run full-speed, I've added an option -nowait to turn off cpu throttling. This can make your CD-i title unplayably fast and it will also cause the audio to lag behind if the title plays continuous audio (most games do).
On the AVI writing front I was less lucky. I cannot get decent write performance and this is not caused by the AVI writing code; just writing the raw data to a file will already cause very "skippy" emulation. Perhaps using a separate thread would solve this (especially on a multicore machine).
And what's worse, the resulting AVI files seem to have timecode problems because they are also skippy, which should not be the case. This is really weird as I've previously been able to write AVI files correctly. It needs more work, obviously.
On the other hand, the AVI files contain the correct audio data: if I extract the audio stream with avidemux, it's identical to a separately written WAV file.
In the process of testing all of this (with Burn:Cycle, what else?) I also fixed the audio crackling problem; it turns out that Burn:Cycle opens all four audio attenuators (L-R, L-L, R-L, R-R) and for this possibility I hadn't accounted in the mix scaling.
I also added the two keyboard emulations that I mentioned yesterday: Backspace for button 2 and Esc for button 3 (buttons 1 and 2 together). This works well for The Apprentice and Dimo's Quest and these are my reference titles anyway :-) I will ultimately add a UI for changing the keyboard map, of course.
It turns out that cpu throttling was already there; titles run at the right speed. However, the frame skip detection logic is too sensitive: it will skip frames even on fast hardware, just because of a momentary slowness (I think). I added an option -noskip to turn off frame skipping altogether; beter autodetection is too much for this beta.
Likewise, for people who always want to run full-speed, I've added an option -nowait to turn off cpu throttling. This can make your CD-i title unplayably fast and it will also cause the audio to lag behind if the title plays continuous audio (most games do).
On the AVI writing front I was less lucky. I cannot get decent write performance and this is not caused by the AVI writing code; just writing the raw data to a file will already cause very "skippy" emulation. Perhaps using a separate thread would solve this (especially on a multicore machine).
And what's worse, the resulting AVI files seem to have timecode problems because they are also skippy, which should not be the case. This is really weird as I've previously been able to write AVI files correctly. It needs more work, obviously.
On the other hand, the AVI files contain the correct audio data: if I extract the audio stream with avidemux, it's identical to a separately written WAV file.
In the process of testing all of this (with Burn:Cycle, what else?) I also fixed the audio crackling problem; it turns out that Burn:Cycle opens all four audio attenuators (L-R, L-L, R-L, R-R) and for this possibility I hadn't accounted in the mix scaling.
I also added the two keyboard emulations that I mentioned yesterday: Backspace for button 2 and Esc for button 3 (buttons 1 and 2 together). This works well for The Apprentice and Dimo's Quest and these are my reference titles anyway :-) I will ultimately add a UI for changing the keyboard map, of course.
Monday, November 16, 2009
Soundmap cleanup, file writing, beta preparation
Today I started with the planned cleanup of the revised soundmap playback code. This took some time but I had it finished my mid-afternoon (please note that I have small children around, which can sometimes make the progress quite slow).
By way of final test I did a 10 minute Burn:Cycle game session; there's still an audio decoding issue there because some parts of the music crackle heavily.
Then I continued working on the WAV / AVI writing front. I have this essentially working now; both types of files are correctly written (the AVI files now include both audio and video). There are new options -writewav and -writeavi to invoke these functions from the command line.
I used the WAV writing feature to check out the Burn:Cycle audio decoding issue. The audio samples go way out of range at the point of the crackles (they actually clamp against the minimum/maximum values). There is probably something wrong in the scaling or something.
One generic issue with WAV file writing is that silent periods (where the CD-i application doesn't play any audio) do not show up in the recorded audio. For the moment, I've decided that this is a feature :-)
There is also some kind of audio timing issue in AVI file writing; the recorded files sometimes sound "skippy". However, this may also be related to the speed of my PC; these are uncompressed AVI files which take 61.5 MB per second for the CD-i video data alone (50 x 3 x 768 x 560 bytes per second). Compared to this, audio is only a measly 172 KB per second :-)
I've found that real-time AVI writing is nearly impossible on my hardware; the framerate drops below 2/50 sometimes (I've lowered the previous 10/50 limit) which makes the titles unplayable. Tomorrow I'll try my work PC which is much faster. That should also give me an opportunity to add frame rate throttling; on fast PC's the emulator currently runs too fast.
However, non-realtime AVI writing also gives the "skippy" sound, so it may be unrelated. Sometimes the audio also gets way out of sync...
One worrying generic issue is that CD-i Emulator seems to have become slower as of late, for no good reason that I can think of. It may be that some debugging code somewhere is slowing things down, but I haven't found it yet. Or it could be that the titles I'm currently running are simple more demanding...
During testing, I also fixed a recent bug where mouse input and keyboard input interfere with each other. I also took out the use of the Shift key for button 2, as it is prone to generate false button presses when using Alt-Tab / Shift-Alt-Tab to switch between windows. You can still use the numeric "+" key for button 2, though, but that is too far away for generic use: I need an alternative closer to the space bar. Perhaps Backspace for button 2, and Esc for button 3 (buttons 1 and 2 together)?
Finally, I've started putting together the first v0.5.3 beta distribution. It will be mostly identical to a v0.5.2 one, with some updates in the sys directory, updated cdiroms.ini and cditypes.rul files and of course an updated executable which will be named wcdiemu-v053b1.exe (for beta 1) to avoid accidentally overwriting an existing v0.5.2 executable. I've also taken a first crack at a release notes document (very descriptively named BETA1).
By way of final test I did a 10 minute Burn:Cycle game session; there's still an audio decoding issue there because some parts of the music crackle heavily.
Then I continued working on the WAV / AVI writing front. I have this essentially working now; both types of files are correctly written (the AVI files now include both audio and video). There are new options -writewav and -writeavi to invoke these functions from the command line.
I used the WAV writing feature to check out the Burn:Cycle audio decoding issue. The audio samples go way out of range at the point of the crackles (they actually clamp against the minimum/maximum values). There is probably something wrong in the scaling or something.
One generic issue with WAV file writing is that silent periods (where the CD-i application doesn't play any audio) do not show up in the recorded audio. For the moment, I've decided that this is a feature :-)
There is also some kind of audio timing issue in AVI file writing; the recorded files sometimes sound "skippy". However, this may also be related to the speed of my PC; these are uncompressed AVI files which take 61.5 MB per second for the CD-i video data alone (50 x 3 x 768 x 560 bytes per second). Compared to this, audio is only a measly 172 KB per second :-)
I've found that real-time AVI writing is nearly impossible on my hardware; the framerate drops below 2/50 sometimes (I've lowered the previous 10/50 limit) which makes the titles unplayable. Tomorrow I'll try my work PC which is much faster. That should also give me an opportunity to add frame rate throttling; on fast PC's the emulator currently runs too fast.
However, non-realtime AVI writing also gives the "skippy" sound, so it may be unrelated. Sometimes the audio also gets way out of sync...
One worrying generic issue is that CD-i Emulator seems to have become slower as of late, for no good reason that I can think of. It may be that some debugging code somewhere is slowing things down, but I haven't found it yet. Or it could be that the titles I'm currently running are simple more demanding...
During testing, I also fixed a recent bug where mouse input and keyboard input interfere with each other. I also took out the use of the Shift key for button 2, as it is prone to generate false button presses when using Alt-Tab / Shift-Alt-Tab to switch between windows. You can still use the numeric "+" key for button 2, though, but that is too far away for generic use: I need an alternative closer to the space bar. Perhaps Backspace for button 2, and Esc for button 3 (buttons 1 and 2 together)?
Finally, I've started putting together the first v0.5.3 beta distribution. It will be mostly identical to a v0.5.2 one, with some updates in the sys directory, updated cdiroms.ini and cditypes.rul files and of course an updated executable which will be named wcdiemu-v053b1.exe (for beta 1) to avoid accidentally overwriting an existing v0.5.2 executable. I've also taken a first crack at a release notes document (very descriptively named BETA1).
Sunday, November 15, 2009
Soundmap interrupt timing (II)
Yesterday I did some thinking about the Lemmings sound issue and concluded that the soundmap interrupt timing of the hardware was very different from the one in CD-i Emulator (and MESS CD-i). Today I set out to correct this.
After the timing was right (which turned out to be two separate issues) there was still a sound issue, because every other Lemmings sound buffer was silent. This turned out to be caused by a misassumption on my part: a hardware register that I had assumed was the actual sound playback address turned out to be just the starting address for a new play operation (I concluded this because the register keeps getting reset to the same value, even though sound is active and the DMA buffer addresses keep properly alternating).
A whole lot of CD-i titles suddenly work much better or even apparently perfect:
- Lemmings now has background music and appears to play perfectly.
- Burn:Cycle appears to play perfectly.
- The professional title that was my 05140000 crash testcase plays perfectly.
- Sargon plays much better (it has frameskip issues).
- Escape from CyberCity menu screens now work (the actual game doesn't start).
And several other soundmixing titles still appear to work okay!
The code is still a bit messy and needs to be cleaned up, but I'm spent for today so it will have to wait a bit.
After the cleanup I will continue working on the WAV and AVI writing functions; these and input record/playback are the last issues holding up the beta release.
After the timing was right (which turned out to be two separate issues) there was still a sound issue, because every other Lemmings sound buffer was silent. This turned out to be caused by a misassumption on my part: a hardware register that I had assumed was the actual sound playback address turned out to be just the starting address for a new play operation (I concluded this because the register keeps getting reset to the same value, even though sound is active and the DMA buffer addresses keep properly alternating).
A whole lot of CD-i titles suddenly work much better or even apparently perfect:
- Lemmings now has background music and appears to play perfectly.
- Burn:Cycle appears to play perfectly.
- The professional title that was my 05140000 crash testcase plays perfectly.
- Sargon plays much better (it has frameskip issues).
- Escape from CyberCity menu screens now work (the actual game doesn't start).
And several other soundmixing titles still appear to work okay!
The code is still a bit messy and needs to be cleaned up, but I'm spent for today so it will have to wait a bit.
After the cleanup I will continue working on the WAV and AVI writing functions; these and input record/playback are the last issues holding up the beta release.
Friday, November 13, 2009
Soundmap interrupt timing (I)
On the MESS board, attention was called to Lemmings not properly playing background music, with a plea for help.
So I started out trying to check this out in CD-i Emulator. There were some obstacles along the way, however.
The first obstacle was that the Lemmings menu screen would not display. This turned out to be very easy to fix, CD-i Emulator simply wasn't handling the CLUT4 display mode. I would have sworn this was implemented long ago, but at least it is now. I've also added RL3 display for the future.
Next, the main game would "hang" after issuing a SEEK command. Weird, as I've seen the SEEK command working in other titles. It turned out that the BIOS expected a certain bit to abort the incoming sectors and CD-i Emulator didn't honor that; it does now.
After that I got the exact same failure mode that MESS CD-i has currently: the "Let's go!" sound effect plays, followed by the sound effect that corresponds to the door opening, then background music starts to play, but dies.
Looking at a DMA trace I concurred with the MESS people that the cause was almost certainly the timing of "soundmap done" interrupts, but experiments in varying it have been unsuccesful so far.
At least Lemmings is now playable in CD-i Emulator, though without background music or sound effects :-(
Yesterday I also did some more work on AVI and WAV writing but it still isn't finished yet (too much infrastructure needed writing). I hope to finish it tomorrow.
So I started out trying to check this out in CD-i Emulator. There were some obstacles along the way, however.
The first obstacle was that the Lemmings menu screen would not display. This turned out to be very easy to fix, CD-i Emulator simply wasn't handling the CLUT4 display mode. I would have sworn this was implemented long ago, but at least it is now. I've also added RL3 display for the future.
Next, the main game would "hang" after issuing a SEEK command. Weird, as I've seen the SEEK command working in other titles. It turned out that the BIOS expected a certain bit to abort the incoming sectors and CD-i Emulator didn't honor that; it does now.
After that I got the exact same failure mode that MESS CD-i has currently: the "Let's go!" sound effect plays, followed by the sound effect that corresponds to the door opening, then background music starts to play, but dies.
Looking at a DMA trace I concurred with the MESS people that the cause was almost certainly the timing of "soundmap done" interrupts, but experiments in varying it have been unsuccesful so far.
At least Lemmings is now playable in CD-i Emulator, though without background music or sound effects :-(
Yesterday I also did some more work on AVI and WAV writing but it still isn't finished yet (too much infrastructure needed writing). I hope to finish it tomorrow.
Wednesday, November 11, 2009
IFF writing and DYUV color keying
Today I implemented proper IFF writing with two new classes: CIffIoBase and CIffWriter. I will need this to write WAV files for the new -writewav option, as WAV files use the Microsoft RIFF format which is a variation of Electronic Arts IFF (Interchange File Format).
The new -writewav option will be a companion to -writepng and -writemng that I can mostly implement using MESS source code (just like -writeavi); the license for the MESS WAV writing code does not allow me to use it and reuse would not be feasible on technical grounds anyway because this code is not as modularly written as the MESS PNG/MNG and AVI writing code.
Proper IFF writing will also be useful for savestates, but that is not for the current beta.
Microsoft says that RIFF stands for Resource Interchange File Format but my source code calls it "Reversed IFF" which is also a correct description :-)
I tested the new IFF writer code by rewriting the CInputStream::Record functions to use it. These functions already wrote IFF format, but now they properly fill in the chunk sizes (previously I left them at 0xFFFFFFFF which limited the file to a single data chunk).
Debugging it took more time then I expected because my binary CArchive class turned out to have bugs in its Position() / SetPosition() functions for file i/o. So I didn't get to the WAV file writing but that is not hard.
Also faithfully emulated a hardware "quirk" that allows Jeopardy to properly display its menu screens, it makes assumptions about the color key bit when using DYUV mode; this was uncovered by the MESS guys. I've implemented this by adding a transparancy test against black which matches the Jeopardy DCP and seems more "correct" then the simple MESS fix of always forcing color key to true. To know this for sure a test program would have to be written but I didn't feel like it.
The new -writewav option will be a companion to -writepng and -writemng that I can mostly implement using MESS source code (just like -writeavi); the license for the MESS WAV writing code does not allow me to use it and reuse would not be feasible on technical grounds anyway because this code is not as modularly written as the MESS PNG/MNG and AVI writing code.
Proper IFF writing will also be useful for savestates, but that is not for the current beta.
Microsoft says that RIFF stands for Resource Interchange File Format but my source code calls it "Reversed IFF" which is also a correct description :-)
I tested the new IFF writer code by rewriting the CInputStream::Record functions to use it. These functions already wrote IFF format, but now they properly fill in the chunk sizes (previously I left them at 0xFFFFFFFF which limited the file to a single data chunk).
Debugging it took more time then I expected because my binary CArchive class turned out to have bugs in its Position() / SetPosition() functions for file i/o. So I didn't get to the WAV file writing but that is not hard.
Also faithfully emulated a hardware "quirk" that allows Jeopardy to properly display its menu screens, it makes assumptions about the color key bit when using DYUV mode; this was uncovered by the MESS guys. I've implemented this by adding a transparancy test against black which matches the Jeopardy DCP and seems more "correct" then the simple MESS fix of always forcing color key to true. To know this for sure a test program would have to be written but I didn't feel like it.
Sunday, November 8, 2009
Beta licensing
Today I finished up the licensing implementation for the upcoming v0.5.3 beta releases.
Each beta release will contain a single CD-i Emulator executable; it will act as a limited edition unless you have already activated an unlimited edition v0.5.2 on your machine or (at least for the initial releases) you're using a Mono-I player system ROM (BIOS).
The former exception has two purposes: it delivers the promised free compatibility updates to my existing customers, and it should encourage new customers as well (several people have promised to buy CD-i Emulator as soon as keyboard support was working).
The latter exception is mainly intended to allow for full compatibility tests against the MESS CD-i driver; I haven't decided yet for how long this will be maintained.
It will not be possible to directly activate beta releases, for that you will need an unlimited v0.5.2 edition (which will remain available). However, when the beta cycle is over, I will do a full unlimited release that can be activated directly (for paying customers only, of course).
After that I fixed a few bugs, including an outright crash that turned out to be caused by a small array misdeclaration in the signal tracking code (used only when you turn on Traps tracing using the debugger "et trp" command, but I often do this when tracking some bug). I had been looking for this for ages, but today it finally "clicked" that the crash only happened (sometimes) while tracing.
Also slightly extended the input record/playback functionality; the recording now includes the CD-i player model and title and the disc image being emulated. Next step is to automatically select these on playback and to account for a few options such as -playcdi that significantly impact the input.
Need to add input dump support to cdifile sometime...
Created a new title screen; this is a complex exercise as the screen is actually using a CLUT7 overlay over a DYUV background. When I get proper CD-i IFF support finished (also needed for save states) I will allow the title screen to be loaded from an external file, possibly customized per player model and/or CD-i title. Not for the first beta.
Proper CD-i IFF support would also allow a frame to be saved in about 250K (actual CD-i data including DCP) instead of the 1.2 MB for a full RGB dump. This would potentially make movie file generation faster, and it would allow offline inspection of video data and control information (useful to catch bugs).
Each beta release will contain a single CD-i Emulator executable; it will act as a limited edition unless you have already activated an unlimited edition v0.5.2 on your machine or (at least for the initial releases) you're using a Mono-I player system ROM (BIOS).
The former exception has two purposes: it delivers the promised free compatibility updates to my existing customers, and it should encourage new customers as well (several people have promised to buy CD-i Emulator as soon as keyboard support was working).
The latter exception is mainly intended to allow for full compatibility tests against the MESS CD-i driver; I haven't decided yet for how long this will be maintained.
It will not be possible to directly activate beta releases, for that you will need an unlimited v0.5.2 edition (which will remain available). However, when the beta cycle is over, I will do a full unlimited release that can be activated directly (for paying customers only, of course).
After that I fixed a few bugs, including an outright crash that turned out to be caused by a small array misdeclaration in the signal tracking code (used only when you turn on Traps tracing using the debugger "et trp" command, but I often do this when tracking some bug). I had been looking for this for ages, but today it finally "clicked" that the crash only happened (sometimes) while tracing.
Also slightly extended the input record/playback functionality; the recording now includes the CD-i player model and title and the disc image being emulated. Next step is to automatically select these on playback and to account for a few options such as -playcdi that significantly impact the input.
Need to add input dump support to cdifile sometime...
Created a new title screen; this is a complex exercise as the screen is actually using a CLUT7 overlay over a DYUV background. When I get proper CD-i IFF support finished (also needed for save states) I will allow the title screen to be loaded from an external file, possibly customized per player model and/or CD-i title. Not for the first beta.
Proper CD-i IFF support would also allow a frame to be saved in about 250K (actual CD-i data including DCP) instead of the 1.2 MB for a full RGB dump. This would potentially make movie file generation faster, and it would allow offline inspection of video data and control information (useful to catch bugs).
CD-i keyboards
Today I spent some time adding limited CD-i keyboard support to CD-i Emulator. It wasn't very hard to do because all the pieces were already there.
I had to disassemble the keyboard drivers for the SLAVE and IKAT processors to figure out the SLAVE/IKAT commands but after that it was smooth sailing. Luckily these are very small drivers.
This has limited utility because there are only a very few titles out there that support a CD-i keyboard. I know of the following ones:
- Philips/Standaard Interactieve Encyclopedie (to enter search terms)
- Philips Medische Encyclopediedisc (to enter search terms)
- CD-Online discs (to enter URLs)
All of these require a DV cartridge and are thus not (yet) supported by CD-i Emulator.
However, there is (very rudimentary) keyboard support in the Philips player shells, just enough to verify that your CD-i keyboard is actually working.
The "old player shell" (found on CD-i 60x, CD-i 200, CD-i 210 F2 and below, CD-i 220 F3 and below and CD-i 350) supports the "p" key (lowercase only!) as equivalent to clicking the "PLAY CD-I" button.
CD-i 605 with old player shell
The "new player shell" (found on CD-i 210 F3 and up, CD-i 220 F4 and up, CD-i 4xx, CD-i 615, CD-i 660 and CD-i 740) supports any key to abort the introductory animation.
CD-i 210 with new player shell
The above now also works in CD-i Emulator.
Supposedly one or both player shells also support the keyboard for naming favorite track selections, but I haven't verified this.
Most people will think of the "CD-i KeyControl" (22ER9042) when they hear the term "CD-i keyboard", but there also exists a true "CD-i Keyboard" (22ER9041). The former was introduced in 1996 with the CD-Online discs but the latter is much older, its specification was published in May 1993.
CD-i KeyControl, photo courtesy of http://www.freetimeweb.nl
CD-i Keyboard, photo taken by myself (click to enlarge)
CD-i Keyboard backside, photo taken by myself (click to enlarge)
The "CD-i Keyboard" is a full PC-AT style keyboard (without a "Windows" key, and using the term "SuperShift" for what is usually called "Alt") that connects to a CD-i player just like any other peripheral. It was intended for the professional market (specifically, the so-called "CD-IX" configuration) and is colored accordingly (whitish). This is the keyboard that the original CD-i keyboard protocol (later called "K-mode" because of it's ASCII "K" device identifier byte) was written for. It transmits key events in two-byte packets at 1200 baud.
The CD-i KeyControl also supports a so-called "T-mode" which uses a different protocol. The keyboard actually masquerades as a graphical tablet with a device identifier byte of ASCII "T". This protocol transmits key events in four-byte packets at 1200 baud.
Why was the "T-mode" introduced when there was already a perfectly usable keyboard device protocol? The reasons for this are arcane, to say the least, and provide a very nice "horror" story about product design and compatibility; it also illustrates the lengths that Philips went to in order to maintain the "All CD-i titles can be used with all CD-i players" principle.
First we need a little background. Most CD-i players have two input ports, usually one on the back and one on the front. Newer players support the use of a splitter cable to connect two peripherals to the front port, in reality these players have two "front" ports that are smartly wired together in a single connector (dual front port support is a feature of the IKAT coprocessor in the newer CD-i players, specifically Mono-III and later).
However, front and back ports are not functionally identical. Back ports are fully bidirectional RS232 ports supporting both serial input and serial output; they are invariably connected directly to the on-chip UART port of the 68070 processor. Front ports are unidirectional; they can only receive serial input and are connected via the SLAVE or IKAT coprocessor (an 68HC05).
The SLAVE processor fully supports the "K" protocol on its single input port, but the IKAT processor only supports it on its secondary port (the one that only becomes accessible when a splitter cable is used). There is no good technical reason for this limitation as far as I know: both ports are supported by software in the IKAT and it should have been easy to support the "K" protocol on both.
Hence the following requirement from the CD-i KeyControl manual:
There is however a complication with the CD-i 450 and FW 380i players (and their variations the CD-i 550 and Magnavox CDI 5000 and CDI 9000): they do not have a back port! Instead one of the two "ports" that make up the front port is connected to the 68070 and thus bidirectional, the other is unidirectional. For some reason the secondary port was chosen to be the bidirectional one, possibly to lessen the load in the main 68070 processor in the usual case or for fail-safety reasons (if a user blows up a port it would tend to be the primary one, which would leave the 68070 port accessible for diagnostics).
The CD-i modem has to be connected to a bidirectional input port, otherwise the CD-i player would not be able to send out data. This means the back port on those players that have it, or the secondary front port on those that do not.
From the above you can deduce that this leaves players without a back port without the possibility to connect a K-mode keyboard while also using a modem! That means that the CD-i 450 and FW 380i players (and their variations) could not be used in the modem + keyboard configuration, which was unacceptable for both marketing and philosophical reasons.
So a workaround was devised. By having the CD-i KeyControl masquerade as a graphical tablet, it could be supported on the primary input port of the IKAT. The coprocessor dutifully reports the "tablet" data to the main processor, which then (using a custom driver that was included on the application disc) transforms it back into keyboard data that the CD-i application can process in the normal way.
When both a modem and a CD-i KeyControl are connected to a CD-i 450 or the FW 380i player, there is no possibility for connecting a wired pointing device (both input ports are in use). These players have no remote (infrared) capability which would make it impossible to "point and click". To remedy this, another workaround was devised. In the T-mode, the function keys F3 to F6 act as cursor keys while the F1 and F2 keys act as button and button 2, respectively
I had to disassemble the keyboard drivers for the SLAVE and IKAT processors to figure out the SLAVE/IKAT commands but after that it was smooth sailing. Luckily these are very small drivers.
This has limited utility because there are only a very few titles out there that support a CD-i keyboard. I know of the following ones:
- Philips/Standaard Interactieve Encyclopedie (to enter search terms)
- Philips Medische Encyclopediedisc (to enter search terms)
- CD-Online discs (to enter URLs)
All of these require a DV cartridge and are thus not (yet) supported by CD-i Emulator.
However, there is (very rudimentary) keyboard support in the Philips player shells, just enough to verify that your CD-i keyboard is actually working.
The "old player shell" (found on CD-i 60x, CD-i 200, CD-i 210 F2 and below, CD-i 220 F3 and below and CD-i 350) supports the "p" key (lowercase only!) as equivalent to clicking the "PLAY CD-I" button.
CD-i 605 with old player shell
The "new player shell" (found on CD-i 210 F3 and up, CD-i 220 F4 and up, CD-i 4xx, CD-i 615, CD-i 660 and CD-i 740) supports any key to abort the introductory animation.
CD-i 210 with new player shell
The above now also works in CD-i Emulator.
Supposedly one or both player shells also support the keyboard for naming favorite track selections, but I haven't verified this.
Most people will think of the "CD-i KeyControl" (22ER9042) when they hear the term "CD-i keyboard", but there also exists a true "CD-i Keyboard" (22ER9041). The former was introduced in 1996 with the CD-Online discs but the latter is much older, its specification was published in May 1993.
CD-i KeyControl, photo courtesy of http://www.freetimeweb.nl
CD-i Keyboard, photo taken by myself (click to enlarge)
CD-i Keyboard backside, photo taken by myself (click to enlarge)
The "CD-i Keyboard" is a full PC-AT style keyboard (without a "Windows" key, and using the term "SuperShift" for what is usually called "Alt") that connects to a CD-i player just like any other peripheral. It was intended for the professional market (specifically, the so-called "CD-IX" configuration) and is colored accordingly (whitish). This is the keyboard that the original CD-i keyboard protocol (later called "K-mode" because of it's ASCII "K" device identifier byte) was written for. It transmits key events in two-byte packets at 1200 baud.
The CD-i KeyControl also supports a so-called "T-mode" which uses a different protocol. The keyboard actually masquerades as a graphical tablet with a device identifier byte of ASCII "T". This protocol transmits key events in four-byte packets at 1200 baud.
Why was the "T-mode" introduced when there was already a perfectly usable keyboard device protocol? The reasons for this are arcane, to say the least, and provide a very nice "horror" story about product design and compatibility; it also illustrates the lengths that Philips went to in order to maintain the "All CD-i titles can be used with all CD-i players" principle.
First we need a little background. Most CD-i players have two input ports, usually one on the back and one on the front. Newer players support the use of a splitter cable to connect two peripherals to the front port, in reality these players have two "front" ports that are smartly wired together in a single connector (dual front port support is a feature of the IKAT coprocessor in the newer CD-i players, specifically Mono-III and later).
However, front and back ports are not functionally identical. Back ports are fully bidirectional RS232 ports supporting both serial input and serial output; they are invariably connected directly to the on-chip UART port of the 68070 processor. Front ports are unidirectional; they can only receive serial input and are connected via the SLAVE or IKAT coprocessor (an 68HC05).
The SLAVE processor fully supports the "K" protocol on its single input port, but the IKAT processor only supports it on its secondary port (the one that only becomes accessible when a splitter cable is used). There is no good technical reason for this limitation as far as I know: both ports are supported by software in the IKAT and it should have been easy to support the "K" protocol on both.
Hence the following requirement from the CD-i KeyControl manual:
Splitter cable is required for models CDI 210/40, CDI210/60 and CDI 470/00 and up.(you can see the full manual here).
There is however a complication with the CD-i 450 and FW 380i players (and their variations the CD-i 550 and Magnavox CDI 5000 and CDI 9000): they do not have a back port! Instead one of the two "ports" that make up the front port is connected to the 68070 and thus bidirectional, the other is unidirectional. For some reason the secondary port was chosen to be the bidirectional one, possibly to lessen the load in the main 68070 processor in the usual case or for fail-safety reasons (if a user blows up a port it would tend to be the primary one, which would leave the 68070 port accessible for diagnostics).
The CD-i modem has to be connected to a bidirectional input port, otherwise the CD-i player would not be able to send out data. This means the back port on those players that have it, or the secondary front port on those that do not.
From the above you can deduce that this leaves players without a back port without the possibility to connect a K-mode keyboard while also using a modem! That means that the CD-i 450 and FW 380i players (and their variations) could not be used in the modem + keyboard configuration, which was unacceptable for both marketing and philosophical reasons.
So a workaround was devised. By having the CD-i KeyControl masquerade as a graphical tablet, it could be supported on the primary input port of the IKAT. The coprocessor dutifully reports the "tablet" data to the main processor, which then (using a custom driver that was included on the application disc) transforms it back into keyboard data that the CD-i application can process in the normal way.
When both a modem and a CD-i KeyControl are connected to a CD-i 450 or the FW 380i player, there is no possibility for connecting a wired pointing device (both input ports are in use). These players have no remote (infrared) capability which would make it impossible to "point and click". To remedy this, another workaround was devised. In the T-mode, the function keys F3 to F6 act as cursor keys while the F1 and F2 keys act as button and button 2, respectively
Thursday, November 5, 2009
Keyboard stuff
Today I finally added keyboard support to CD-i Emulator, in preparation for the upcoming v0.5.3 release.
You can now use the arrow keys and the numeric keypad for movement (the latter allows diagonal movement as well). The default movement rate is 4 (high-resolution) pixels per frame, but you can modify this with the new "keydelta" option.
You can use Space bar and both Enter keys for button 1 and the Shift and numeric keypad "+" keys for button 2; the numeric keypad "-" key acts as button 3 (both buttons simultaneously). I'm not sure yet if the numeric keypad button assignments aren't too easy to hit accidentally.
Internally this is all implemented with a full key mapping but there is currently no UI for changing the mapping.
I've tested a few games and it seems to work okay; compat testing will learn if the default keydelta is right. It might also be necessary to delay the movement actions until the keys have been pressed for a few frames; right now you need to do a VERY quick keypress to get a single delta movement. Or possibly a multistage delta array so that movement accelerates if you press the keys longer.
I've also added automatic Windows cursor hiding, the thing becomes annoying if you're not using it. You can regain the Windows cursor by pressing the Ctrl key, which now also temporarily disables the "cursor grabbing" done by CD-i Emulator (previously this could only be done by pressing Alt or F10 which also paused the emulation).
You can now use the arrow keys and the numeric keypad for movement (the latter allows diagonal movement as well). The default movement rate is 4 (high-resolution) pixels per frame, but you can modify this with the new "keydelta" option.
You can use Space bar and both Enter keys for button 1 and the Shift and numeric keypad "+" keys for button 2; the numeric keypad "-" key acts as button 3 (both buttons simultaneously). I'm not sure yet if the numeric keypad button assignments aren't too easy to hit accidentally.
Internally this is all implemented with a full key mapping but there is currently no UI for changing the mapping.
I've tested a few games and it seems to work okay; compat testing will learn if the default keydelta is right. It might also be necessary to delay the movement actions until the keys have been pressed for a few frames; right now you need to do a VERY quick keypress to get a single delta movement. Or possibly a multistage delta array so that movement accelerates if you press the keys longer.
I've also added automatic Windows cursor hiding, the thing becomes annoying if you're not using it. You can regain the Windows cursor by pressing the Ctrl key, which now also temporarily disables the "cursor grabbing" done by CD-i Emulator (previously this could only be done by pressing Alt or F10 which also paused the emulation).
Tuesday, November 3, 2009
Roadmap
No CD-i activity today, except reading Interactive Dreams and letting Bas know about this blog. As I expected, he announced it immediately :-)
I've also just announced this blog on the MESS CD-i WIP topic, the CD-i Emulator Support forum and added links to the CD-i Emulator site.
So for the new visitors (all four of you :-) a little roadmap of my current CD-i activities. You could say it's a To Do list except that I'm not that structured in my hobby activities.
1. CD-i Emulator programs
- I've been working on support for the Digital Video cartridge. It can currently play the Philips "bumper" movie of a few discs and play some MPEG audio; subsequent MPEG plays have a tendency to crash. This is currently for Gate Array MPEG cartridges only, but the IMPEG/VMPEG cartridges look to be highly similar. It needs to be made more reliable.
- I've also been fixing quite a bit of video and CDIC (Mini-MMC/Mono-I) bugs in conjuction with or triggered by the MESS CD-i work. This work continues.
- Support for chd (compressed hunks of data) disc images has been added using source code from MESS/MAME. Proper handling of subcode data needs to be added.
- Support for AVI movie saving has been added using source code from MESS/MAME. This needs a bit of polishing and doesn't currently save audio.
- Primitive support for input recording and playback has been added; needs a bit of polishing.
- DirectX support promises some performance improvements; I have skeleton code but it needs to be looked into.
- I've drafted a new video combining pass that should be substantially faster and should easily handle non-RGB24 display formats as used by DirectX; it needs to be fleshed out.
- Some new player types are partially emulated, in particular those using the 68341 so-called "Integrated CD-i Engine" (which is a great misnomer). These players tend to use a fourth CD interface chip that I've dubbed RCHIP.
- Needs savestate support to be added (partially drafted).
- Needs emulation bugs fixed (mostly on Mono-II and higher).
- Command-line version needs to be revived for movie rendering from recorded input.
2. CD-i File programs
The first version of the CD-i File Extractor (command-line tool) has been released as a CD-i disc image conversion tool (converts image to raw/cue and creates chd).
- Needs extension with "dir" and "chd" options to extract particular files within the CD-i disc image.
- Needs an interactive mode to browse the CD-i disc image.
- Needs header and sector map dumps to analyze CD-i realtime files.
- Needs to be extended with channel/sector selection to support data extraction.
- Needs to be extended with audio and video decoding to support data extraction.
- Needs to be extended with CD-i IFF parsing to support data extraction.
- Needs to be repackaged as CD-i File Player (graphical UI tool) for actual playback and display of audio and video data; should also support graphical sector maps and disc image browsing.
3. CD-i Base library
Announcement has been accidentally released by a recent website update. It is supposed to be a support library for CD-i application development.
- Needs to be started with basic initialization framework (has been drafted).
- Needs to incorporate the initialization code that I supplied to Charles Doty for Frog Feast, supporting access of the CSD (Configuration Status Descriptor) file from NVRAM and video and pointer hardware access.
- Needs to have disc playback code added (specs have been drafted).
- Needs to have sound playback code added (not even drafted).
- Sound mixing, blitting, sprite compilation, MPEG playback, etc.
4. CD-i Bits blog
The blog gremlins need to be kept fed :-)
5. CD-i Full Functional Specification (Green Book) document
The Green Book (often abbreviated FFGB) is the "bible" of CD-i application development; it incorporates the OS9 documentation (available on the ICDIA site) by reference.
There are now public links to the Green Book on the Internet. These are plaintext versions which are quite faithful renditions of the originals except that most of the ASCII art is messed up and there is no proper indexing and only rudimental cross referencing.
- Write a program to restore the ASCII art and convert to hyperlinked HTML with index and cross-reference links so that the digital Green Book becomes more useful.
And probably lots of things I forgot to mention...
I've also just announced this blog on the MESS CD-i WIP topic, the CD-i Emulator Support forum and added links to the CD-i Emulator site.
So for the new visitors (all four of you :-) a little roadmap of my current CD-i activities. You could say it's a To Do list except that I'm not that structured in my hobby activities.
1. CD-i Emulator programs
- I've been working on support for the Digital Video cartridge. It can currently play the Philips "bumper" movie of a few discs and play some MPEG audio; subsequent MPEG plays have a tendency to crash. This is currently for Gate Array MPEG cartridges only, but the IMPEG/VMPEG cartridges look to be highly similar. It needs to be made more reliable.
- I've also been fixing quite a bit of video and CDIC (Mini-MMC/Mono-I) bugs in conjuction with or triggered by the MESS CD-i work. This work continues.
- Support for chd (compressed hunks of data) disc images has been added using source code from MESS/MAME. Proper handling of subcode data needs to be added.
- Support for AVI movie saving has been added using source code from MESS/MAME. This needs a bit of polishing and doesn't currently save audio.
- Primitive support for input recording and playback has been added; needs a bit of polishing.
- DirectX support promises some performance improvements; I have skeleton code but it needs to be looked into.
- I've drafted a new video combining pass that should be substantially faster and should easily handle non-RGB24 display formats as used by DirectX; it needs to be fleshed out.
- Some new player types are partially emulated, in particular those using the 68341 so-called "Integrated CD-i Engine" (which is a great misnomer). These players tend to use a fourth CD interface chip that I've dubbed RCHIP.
- Needs savestate support to be added (partially drafted).
- Needs emulation bugs fixed (mostly on Mono-II and higher).
- Command-line version needs to be revived for movie rendering from recorded input.
2. CD-i File programs
The first version of the CD-i File Extractor (command-line tool) has been released as a CD-i disc image conversion tool (converts image to raw/cue and creates chd).
- Needs extension with "dir" and "chd" options to extract particular files within the CD-i disc image.
- Needs an interactive mode to browse the CD-i disc image.
- Needs header and sector map dumps to analyze CD-i realtime files.
- Needs to be extended with channel/sector selection to support data extraction.
- Needs to be extended with audio and video decoding to support data extraction.
- Needs to be extended with CD-i IFF parsing to support data extraction.
- Needs to be repackaged as CD-i File Player (graphical UI tool) for actual playback and display of audio and video data; should also support graphical sector maps and disc image browsing.
3. CD-i Base library
Announcement has been accidentally released by a recent website update. It is supposed to be a support library for CD-i application development.
- Needs to be started with basic initialization framework (has been drafted).
- Needs to incorporate the initialization code that I supplied to Charles Doty for Frog Feast, supporting access of the CSD (Configuration Status Descriptor) file from NVRAM and video and pointer hardware access.
- Needs to have disc playback code added (specs have been drafted).
- Needs to have sound playback code added (not even drafted).
- Sound mixing, blitting, sprite compilation, MPEG playback, etc.
4. CD-i Bits blog
The blog gremlins need to be kept fed :-)
5. CD-i Full Functional Specification (Green Book) document
The Green Book (often abbreviated FFGB) is the "bible" of CD-i application development; it incorporates the OS9 documentation (available on the ICDIA site) by reference.
There are now public links to the Green Book on the Internet. These are plaintext versions which are quite faithful renditions of the originals except that most of the ASCII art is messed up and there is no proper indexing and only rudimental cross referencing.
- Write a program to restore the ASCII art and convert to hyperlinked HTML with index and cross-reference links so that the digital Green Book becomes more useful.
And probably lots of things I forgot to mention...
Monday, November 2, 2009
Bugs galore
Worked on three things today, mainly so I wouldn't go crazy...
Looking for RGB555 discs I found an old professional title that provides a simple testcase for the "DMA to 05140000" problem manifesting in both MESS and CD-i Emulator. I've been backtracing this through the ROMs and trying to find out how to solve it, but no luck so far.
When I got nearly crazy from staring at the disassembly listings I'd switch to fixing another bug: CD-i Link no longer works with CD-i Emulator, and there is someone urgently needing this. I've made some progress here (it downloads the stub okay, but still cannot upload) but it's not finished.
To escape from all the frustration I also did some new development: I extended the disc path table and directory sector parsing in preparation for more CD-i File functionality (specifically, the "dir" and "chdir" options). But here I also hit weird bugs in memory allocation.
It just wasn't my day, I guess...
Looking for RGB555 discs I found an old professional title that provides a simple testcase for the "DMA to 05140000" problem manifesting in both MESS and CD-i Emulator. I've been backtracing this through the ROMs and trying to find out how to solve it, but no luck so far.
When I got nearly crazy from staring at the disassembly listings I'd switch to fixing another bug: CD-i Link no longer works with CD-i Emulator, and there is someone urgently needing this. I've made some progress here (it downloads the stub okay, but still cannot upload) but it's not finished.
To escape from all the frustration I also did some new development: I extended the disc path table and directory sector parsing in preparation for more CD-i File functionality (specifically, the "dir" and "chdir" options). But here I also hit weird bugs in memory allocation.
It just wasn't my day, I guess...
Sunday, November 1, 2009
Some fixes
Triggered by messages on the MESS CD-i WIP topic, I fixed a few CD-i Emulator bugs today.
I implemented the CDIC "seek" command which for some reason I never got around to; it allows International Tennis Open and Flashback to progress past their intros (they would hang otherwise). The SS_Seek API which is what triggers this command is just a (possible) performance optimization and very few CD-i titles use it (every read operation has an implied disc seek anyway).
Also fixed the CDIC sector dispatching logic so that it only handles audio sectors specially during a mode2 read (it could otherwise cause bugs with mode1 reads and seeks).
Fixed a region control bug (the region flags values were set from the lowest coordinate bit instead of the proper operation bit); this surfaced when trying to fix Zenith (it had no visual effect there but did show up in the video traces).
And finally todays biggie: fixed a transparancy control bug that caused planes to never go transparent, even when they should, as soon as any region flag got set. This was caused by a very subtle macro definition bug that caused the transparency control masks to get bad values for transparency cases i > 4, which are the cases where one or both region flags are set.
I'm frankly amazed the last one slipped through for so long; it even had a visible effect in the intro sequence of The Apprentice (when the little horse riding knight rides accross the screen, you could briefly see it in black in the left and right margins, whereas it should have been transparent, and now is). And I actually knew this was wrong but never got around to figuring it out...
But with the above changes, Zenith finally renders fully correct, Flashback and International Tennis Open boot okay (they have sound and gameplay issues, though), and The Apprentice also renders fully correct (as far as I know).
I have to figure out a way to get all these fixes out there...
I implemented the CDIC "seek" command which for some reason I never got around to; it allows International Tennis Open and Flashback to progress past their intros (they would hang otherwise). The SS_Seek API which is what triggers this command is just a (possible) performance optimization and very few CD-i titles use it (every read operation has an implied disc seek anyway).
Also fixed the CDIC sector dispatching logic so that it only handles audio sectors specially during a mode2 read (it could otherwise cause bugs with mode1 reads and seeks).
Fixed a region control bug (the region flags values were set from the lowest coordinate bit instead of the proper operation bit); this surfaced when trying to fix Zenith (it had no visual effect there but did show up in the video traces).
And finally todays biggie: fixed a transparancy control bug that caused planes to never go transparent, even when they should, as soon as any region flag got set. This was caused by a very subtle macro definition bug that caused the transparency control masks to get bad values for transparency cases i > 4, which are the cases where one or both region flags are set.
I'm frankly amazed the last one slipped through for so long; it even had a visible effect in the intro sequence of The Apprentice (when the little horse riding knight rides accross the screen, you could briefly see it in black in the left and right margins, whereas it should have been transparent, and now is). And I actually knew this was wrong but never got around to figuring it out...
But with the above changes, Zenith finally renders fully correct, Flashback and International Tennis Open boot okay (they have sound and gameplay issues, though), and The Apprentice also renders fully correct (as far as I know).
I have to figure out a way to get all these fixes out there...
Subscribe to:
Posts (Atom)