Yeah I agree that it was possible to upload and run software on the regular CD-i players in the same way, although we rarely used that capability except when we were developing something somewhat hardware specific, for example when I was developing the interface for displaying information on the LED front panel displays for the CD-i players. You are also correct that we had to renumber the SCSI IDs to avoid addressing conflicts and proper bus termination was always tricky. I had written software for the PC side to deal with keeping the cache updated - you mainly had to make sure you weren't hitting the drive from both sides at once to keep from corrupting the FAT. I also have the hard drive emulator hardware system which attaches to the 605 system (which is actually another OS9 based package). That was always a bit of a pain to use, so would find alternatives wherever possible. Once the I2Ms were available we used those most of the time for development as that made it much easier to deal with overall. Before the 605's were available I used the CDI-18x series players for development.
A lot of the development on the professional side focused on titles that made extensive use of the DVC, as we were essentially replacing touch screen / videodisc-pc combination systems with cd-i players and video was an essential part of that equation. There was quite a bit of development that went into dealing with proper encoding, mastering and playback of FMV, and we developed code to allow us to enter and exit FMV streams at specific I frame entry points and in some cases cache-ahead streams being switched between that allowed for seamless switching of fmv streams on the disc. I also developed a lot utilities for extracting and color-match-converting frames from the encoded FMV streams to DYUV/RGB888 and which allowed us to seamlessly transition to and from FMV between graphic frames for interactions. I also had developed capabilities for overlay popup controls for FMV which allowed forward/reverse scan, slow/fast motion, step, pause/play, and branching (i.e. back/next) within titles. I mentioned some other things I think in a post in another forum. I included some of these capabilities in CD-i capability demo discs we developed for Philips Professional Media.
I wonder if Philips would be ok with posting cd-i images here of demo discs they produced that were not sold but rather given away? I wouldn't think there should be a problem with that. They may be good images for testing system capabilities, and some people may be interested in seeing them. I've been having some discussions with Devin on posting some CD-i utilities, code, etc.
One of the original demo discs that Philips produced for the FMV card had some source code embedded (intentionally, although not documented anywhere) as files in the file system that gave a leg up to developers who were developing code for the DVC cards. The Green Book extensions were not really very helpful always in terms of practical issues surrounding use of DVC capabilities. We also repurposed allocated FMV buffers when they were not in active use to be able to maximize the memory utilization/capabilites of the system for interactive/graphic content in FMV titles.
beneath a steel sky?
fmv demo
Yes but it gave a lot of insights at the time as to how to at least start to achieve some of the results of the impressive demos on that disc. I think that disk probably was not graceful in terms of whether or not the FMV card was present. Were you a CD-i developer at the time? I'm in the process of going through my cd-i floppies, disks and exabyte tape archives to get some of the more important materials backed up to DVD before they cease to be readable anymore... Do you need documented image / source code samples to work with in testing or modeling the fmv card functionality?
- cdifan
- CD-i Emulator Author
- Posts: 923
- Joined: Fri Jun 24, 2005 6:19 am
- Location: The Netherlands
- Contact:
I have been developing for CD-i from early 1993; in a sense I still am
At the time I was hired specifically for investigating the "seamless jump" feature of the FMV cartridge; later this morphed into more general CD-i support programming.
I still have a full set of CD-i documentation: OS-9 manuals, Green Books (several, including chapter IX "Full Motion Extension"), TechNotes, what have you, and more then enough FMV programming samples.
So I really don't need anything, except time![Confused :?](./images/smilies/icon_confused.gif)
![Smile :-)](./images/smilies/icon_smile.gif)
At the time I was hired specifically for investigating the "seamless jump" feature of the FMV cartridge; later this morphed into more general CD-i support programming.
I still have a full set of CD-i documentation: OS-9 manuals, Green Books (several, including chapter IX "Full Motion Extension"), TechNotes, what have you, and more then enough FMV programming samples.
So I really don't need anything, except time
![Confused :?](./images/smilies/icon_confused.gif)
programming
Well I'd be happy to help if I you need it - I'm pretty expert at OS9/68000 assembler, am intimately familiar with all the ins and outs of CD-i hardware/software issues, and have a large amount of embedded/OS Linux/Unix experience and C/C++/C#/etc... I know you're collaborating with the MAME folks as well on their effort by providing code and maybe getting contributions back from them - not sure if you're concentrating on more of an HLE approach than them rather than trying to emulate all of the chips exactly, especially if you're intent is to concentrate on having a true "green-book" spec emulator rather than necessarily dealing with all the idiosyncracies (and "features") in the individual players, although I can see some of the reasons for that as well since you have to somewhat rely on the ROMS. I was initially doing mastering engineering at a videodisc plant when I first was introduced to CD-i when Philips released the "Green Book" in 1986 and was fascinated. When I left there and went into consulting I eventually bought into development software towards the end of the 80's and subsequently nurtured a pretty large professional application to apply it to which led to being snapped up. I have an interest in that I have a pretty large library of titles with FMV content that I developed or managed that I'd like to be able to demo. IMHO some of it is still pretty impressive even by todays standards in terms of what was possible to do on such a cheap/consumer package.
- cdifan
- CD-i Emulator Author
- Posts: 923
- Joined: Fri Jun 24, 2005 6:19 am
- Location: The Netherlands
- Contact:
Re: programming
I share most of that background, although my embedded experience is more limited. Since I wrote my 68070 and 68341 emulator from scratch I'm now also pretty expert in 68000 assemblersfetchit wrote:Well I'd be happy to help if I you need it - I'm pretty expert at OS9/68000 assembler, am intimately familiar with all the ins and outs of CD-i hardware/software issues, and have a large amount of embedded/OS Linux/Unix experience and C/C++/C#/etc...
![Smile :-)](./images/smilies/icon_smile.gif)
I don't quite understand what kind of hardware/software issues you're referring to, though?
I've provided the MESS/MAME people with some code to illustrate the workings of the undocumented CDIC and SLAVE chips, and we've collaborated on finding and fixing some compatibility issues. At the current time both emulators use the same approach: full low-level emulation of the CPU and VDSC but high-level emulation for the CDIC and SLAVE chips (both of which have internal microcode). The next step for MESS seems to be decapping the SLAVE and implementing low-level emulation for it (it's an 68H05 which MESS already supports); that doesn't help CD-i emulation much but it's their way of doing these thingssfetchit wrote:I know you're collaborating with the MAME folks as well on their effort by providing code and maybe getting contributions back from them - not sure if you're concentrating on more of an HLE approach than them rather than trying to emulate all of the chips exactly, especially if you're intent is to concentrate on having a true "green-book" spec emulator rather than necessarily dealing with all the idiosyncracies (and "features") in the individual players, although I can see some of the reasons for that as well since you have to somewhat rely on the ROMS.
![Smile :)](./images/smilies/icon_smile.gif)
For the present time MESS is concentrating on the Mono-I chipset whereas CD-i Emulator also handles Mini-MMC (60x players, VSC/VSD instead of VDSC) and the other Mono chipsets (DSP/SLAVE or CIAP/IKAT instead of CDIC/SLAVE) and derivatives such as Roboco (450/550 players). At this point CD-i Emulator supports every Philips CD-i player based on the 68070 and it has rudimentary support for 68000 and 68341 based players (the latter is the so-called "CD-i Engine" chip which has no actual on-chip CD-i functionality, just basic system stuff like DMA/UART/I2C/TIMER, much like the 68070).
So both CD-i Emulator and the MESS/MAME CD-i driver are not just somewhat but totally relying on the ROMs. CD-Ice uses the "pure green-book" type of emulation (no ROMs) although it of necessity mostly low-level emulates the processor and the video hardware as well, but it hasn't seen active development for a long time (this could change, of course).
I share the fascination and amen very much to the impressiveness and especially ease of (consumer) use. The contrast is remarkable when you compare it to PCs, today and even more at the time.sfetchit wrote:I was initially doing mastering engineering at a videodisc plant when I first was introduced to CD-i when Philips released the "Green Book" in 1986 and was fascinated. When I left there and went into consulting I eventually bought into development software towards the end of the 80's and subsequently nurtured a pretty large professional application to apply it to which led to being snapped up. I have an interest in that I have a pretty large library of titles with FMV content that I developed or managed that I'd like to be able to demo. IMHO some of it is still pretty impressive even by todays standards in terms of what was possible to do on such a cheap/consumer package.
programming
Well I'm glad there is some collaboration going on to move it all forward regardless of the difference in paths. I was really referring to player idiosyncracies in the software/hardware interfaces referenced to the green book but if you're pretty much directly emulating the roms then that shouldn't be an issue since those behaviours should be pretty much replicated (other than figuring out expected behavior of the "black-box" circuitry). Anyway, it sounds like you have it pretty much in hand in terms of the hardware emulation other than ironing out miscellaneous issues.