A few questions for CDifan :
I won't beg you if you won't answer them, but well...
1. What was the most difficult thing to code for your CDi emulator ?
2. About the CDi File Player (well this is not CDI Music Player ^^), does it can extract many types of pictures (pictures of backgrounds, pictures used for cutscenes, etc...) ?
3. What gives you the idea of making a CD-i emulator, and why ?
4. I really don't want to beg you, but my friends wants to show that question : About the CD-i emulator, how is it going ?
It was the last, my english can be bad so i hope your understand them.
Just a few questions...
-
- Burn:Cycle Activated
- Posts: 5
- Joined: Thu Jul 03, 2008 5:30 pm
i guess although im not cifan that
1-the hardest thing to code was the lock in the non free version, i can almost bet on that xD
2-question number two is a tough one since im never in my life going to be so bored to use the cdi file player
3-again not sure and guessing but the idea must have come from a dead mockingbird and the why is a question that only a shrimp may answer
4-is it going? still? u prankster xD
1-the hardest thing to code was the lock in the non free version, i can almost bet on that xD
2-question number two is a tough one since im never in my life going to be so bored to use the cdi file player
3-again not sure and guessing but the idea must have come from a dead mockingbird and the why is a question that only a shrimp may answer
4-is it going? still? u prankster xD
- cdifan
- CD-i Emulator Author
- Posts: 923
- Joined: Fri Jun 24, 2005 6:19 am
- Location: The Netherlands
- Contact:
I'd like to thank mr. Tekkenlord for his most insightful comments, but would like to provide a more informative answer myself.
Here are some answers to Luigi's questions (I assume that is your first name, yes?):
1. The hardest things to code for CD-i Emulator were and still are the emulations of the undocumented hardware that controls the CD and audio interface and the MPEG hardware. The public API's of these things are well-specified in the Green Book, but the actual hardware that provides the functionality is not documented anywhere that I've been able to find. And I looked pretty hard...
So it had to be done by reverse-engineering the ROM drivers and watching the I/O generated by API traces. This work was somewhere between doubled and tripled by the fact that there are several generations of these interface chips, sometimes with radically different interfaces.
The video hardware is almost documented (and in the case of one chip, the VDSC, actually IS documented) and the emulation of this part of the hardware was also made much easier because the Green Book API for it pretty much matches the actual hardware (it specifies the memory formats of images and control tables in details; the only undocumented part is how the hardware knows where to find this data in memory).
The emulation for things like pointing devices, NVRAM and timers is almost trivial compared to the above.
Initially I had some trouble getting my 68070 emulation fast enough (it is entirely coded in mostly portable C++) but those troubles are long over, not in the least because the PC's have been getting steadily faster![Smile :-)](./images/smilies/icon_smile.gif)
2. The CD-i File Player would be able to extract any data (audio, video) stored on disc in a "standard" (that is, Green Book specified) format. The Green Book allows application-specific coding, e.g. custom run-length encoding, compiled sprites, etc and these cannot be extracted without full emulation. For that I would like to include some support in a future version of CD-i Emulator.
3. The basic motivation behind CD-i Emulator was that I didn't want to lose my CD-i title collection (part of which I programmed myself or contributed to significantly) because of aging hardware. When I started this work around 1997 the "demise" of CD-i was still quite fresh and it seemed quite urgent to get things going while there was still functioning hardware around. Of course, it now seems that the hardware is going to last much longer then one might expect from a system abandoned more then ten years ago.
4. There has been some development since the last public release in 2005, in particular on the front of development support and MPEG emulation. It has been going very slow, however, lately mostly because we've just had our second child last week (a beautiful girl). But emulation work like this is agonizingly boring until you get something actually working (just a lot of staring at traces and disassemblies, trying something, followed by more staring; see point 1). And then you need to root out bugs which means more tracing and more staring![Smile :-)](./images/smilies/icon_smile.gif)
One thing I would like to achieve with the CD-i File Player is to get some visible development work out there, but it hasn't borne fruits yet. It would be free (no payments) and probably use some form of open source.
I hope this answers most of your questions?
Here are some answers to Luigi's questions (I assume that is your first name, yes?):
1. The hardest things to code for CD-i Emulator were and still are the emulations of the undocumented hardware that controls the CD and audio interface and the MPEG hardware. The public API's of these things are well-specified in the Green Book, but the actual hardware that provides the functionality is not documented anywhere that I've been able to find. And I looked pretty hard...
So it had to be done by reverse-engineering the ROM drivers and watching the I/O generated by API traces. This work was somewhere between doubled and tripled by the fact that there are several generations of these interface chips, sometimes with radically different interfaces.
The video hardware is almost documented (and in the case of one chip, the VDSC, actually IS documented) and the emulation of this part of the hardware was also made much easier because the Green Book API for it pretty much matches the actual hardware (it specifies the memory formats of images and control tables in details; the only undocumented part is how the hardware knows where to find this data in memory).
The emulation for things like pointing devices, NVRAM and timers is almost trivial compared to the above.
Initially I had some trouble getting my 68070 emulation fast enough (it is entirely coded in mostly portable C++) but those troubles are long over, not in the least because the PC's have been getting steadily faster
![Smile :-)](./images/smilies/icon_smile.gif)
2. The CD-i File Player would be able to extract any data (audio, video) stored on disc in a "standard" (that is, Green Book specified) format. The Green Book allows application-specific coding, e.g. custom run-length encoding, compiled sprites, etc and these cannot be extracted without full emulation. For that I would like to include some support in a future version of CD-i Emulator.
3. The basic motivation behind CD-i Emulator was that I didn't want to lose my CD-i title collection (part of which I programmed myself or contributed to significantly) because of aging hardware. When I started this work around 1997 the "demise" of CD-i was still quite fresh and it seemed quite urgent to get things going while there was still functioning hardware around. Of course, it now seems that the hardware is going to last much longer then one might expect from a system abandoned more then ten years ago.
4. There has been some development since the last public release in 2005, in particular on the front of development support and MPEG emulation. It has been going very slow, however, lately mostly because we've just had our second child last week (a beautiful girl). But emulation work like this is agonizingly boring until you get something actually working (just a lot of staring at traces and disassemblies, trying something, followed by more staring; see point 1). And then you need to root out bugs which means more tracing and more staring
![Smile :-)](./images/smilies/icon_smile.gif)
One thing I would like to achieve with the CD-i File Player is to get some visible development work out there, but it hasn't borne fruits yet. It would be free (no payments) and probably use some form of open source.
I hope this answers most of your questions?
-
- Softech Recruit
- Posts: 63
- Joined: Sat May 20, 2006 4:08 pm
Congratulations to the new heir!cdifan wrote:we've just had our second child last week (a beautiful girl).
Extracting application-specific coding data is that makes the CD-i File Player more than a ordinary file player ! Is it possible to use full emulation without writing custom rules for each CD-i software to extract those custom formats ?cdifan wrote:2. The CD-i File Player would be able to extract any data (audio, video) stored on disc in a "standard" (that is, Green Book specified) format. The Green Book allows application-specific coding, e.g. custom run-length encoding, compiled sprites, etc and these cannot be extracted without full emulation. For that I would like to include some support in a future version of CD-i Emulator.
- cdifan
- CD-i Emulator Author
- Posts: 923
- Joined: Fri Jun 24, 2005 6:19 am
- Location: The Netherlands
- Contact:
How would this be different from recording emulated audio/video output, which the current beta already supports?opt_fr_ wrote:Extracting application-specific coding data is that makes the CD-i File Player more than a ordinary file player ! Is it possible to use full emulation without writing custom rules for each CD-i software to extract those custom formats ?
The problem with application-specific coding is that in general only the application knows how to decode the data, so you have to run or reverse-engineer it, i.e. emulate it or write custom rules!