Did you know early CDi's support another video mode?

[cdoty]

While developing Frog Feast, I (well we, hello CD-I Fan!) stumbeld on a video mode only present on Mini MMC based boards.

There is a 320x224 (or 256 in PAL ) mode supported on the systems such as the 205/910, 350 and, 605. This may be present in other models, but it didn't show up, in the Frog Feast tests. This is what caused the corrupt display experience by a few people. This mode matches the resolution of game systems such as the Sega Genesis/CD and TurboGrafx 16 and, Amiga/Atari ST computer systems. I'm not sure this is a fully supported mode even on the Mini MMC based boards, as there was some pixel garbage in the lower border area, that could not be cleared out.

If the MCD212 chip was based on a previous chipset, it may've been left over functionality from the earlier chip.

There's a document somewhere that details the chips used in each CD-i model. Since the MCD212 was used in other models, the RTOS must not allow the bits to be left unset in other models.

[Bas]

cool bit of trivia, never knew that. How do you guys find out about stuff like that. I'm not familiar with hardware/software! I understand there is a limited amount of 'video modes' you can play a cd-i title in, now depending on what model you're using?

[cdoty]

cool bit of trivia, never knew that. How do you guys find out about stuff like that. I'm not familiar with hardware/software! I understand there is a limited amount of 'video modes' you can play a cd-i title in, now depending on what model you're using?

I started investigating why Frog Feast was not displaying correctly on my CD-I 605, and was able to determine the width and height, by drawing lines. Looking into the Balboa source I found both parts of the cause, but didn't put them together. CD-I Fan replied with an e-mail containing both pieces of information, which got me looking at the Green Book again. I noticed that I had overlooked the bit in the 'reload display parameter' instruction, I'd already noticed and corrected the bits in the 'image coding method' instruction.

Although Balboa isn't a good library for game development, it does provide source code that would help a programmer understand CD-I programming. It provides the correct way to interface with the CD RTOS.
Unfortunately for me, I found it too late in the process.

[cdifan]

Although Balboa isn't a good library for game development, it does provide source code that would help a programmer understand CD-I programming. It provides the correct way to interface with the CD RTOS.

I think you're giving Balboa a little too much c r e d i t (weird spelling to avoid spam detection), really. Most of the "how to interface" stuff is in the C bindings that come with the Microware C compiler, not with Balboa.

In the particular case above, the header file uch.h provides the definition

Code: Select all

#define _OP_ICM 0xC0001010 /* image coding method */

and then uses that to define a macro

Code: Select all

#define cp_icm(cm0,cm1,nm,ev,cs) (_OP_ICM + /* details omitted */)

This macro constructs a 32-bit value that tells the video chip about image codings. No programmer in his right mind would ever construct this value by hand; that's what the macro is for!

In assembly language it's quite a different matter, but even there... One of the sample source lines I provided was the following

Code: Select all

* Load Image Coding Method.
CP_ICM equ $C0000000

Like any good programmer, Charles duly used this constant to construct his 32-bit value; but note that two bits are missing (the 1010 part)!. It should have been (and now is)

Code: Select all

CP_ICM equ $C0001010

The same happened with the CP_DPRM instruction (one bit):

Code: Select all

* Reload Display Parameters.
CP_DPRM equ $78000000

versus the correct

Code: Select all

CP_DPRM equ $78000400

If you want more details about these 32-bit values, check the MCD212 documentation available from the ICDIA site.

The Green Book explicitly defines the above three bits as required to be set, but does not tell you what happens if you forget to set them. Well, Charles found out the hard way: on Mini-MMC hardware you get a different video resolution; on later hardware it has no effect. I suspect that on Maxi-MMC hardware (CD-i 18x series) the effect would have been similar.

Charles actually happened to confirm both my best hopes and worst fears about using CD-i Emulator for development. He found the various tracing and debugging aids (which are much more powerful then whatever was available at the time) invaluable, but also managed to get stuck on the differences between the emulator and "real hardware" in several cases (some of which were bugs in CD-i Emulator, but others where not).

The experience has been enlightening and got me thinking about ways to support developement with the emulator. Bitwise validation of the Display Control Program was easy to add and presto, out rolled the three bits! Of course, Charles had already noticed them by bitwise comparison of DCPs from various other CD-i titles including the early Balboa version of Frog Feast, which speaks volumes about the amount of effort he must have thrown at the problem. Hats off!

About the various hardware versions... Some of this is documented in the Technical Notes series which should appear on ICDIA sometime soon (hopefully; Devin?!). Early CD-i models used a separate decoding chip per video plane, called VSC (Video System Controller???) on Maxi-MMC and VSR (Video System Revised???) on Mini-MMC, with another chip called VSD (Video System Decoder???) used to combine the outputs of the two video planes. This chipset generation supports the weird resolutions in hardware, but I have not been able to find any software support for it. It may have been a holdover from early development or an attempt to make the chipset reusable for other purposes as well.

The Motorola MCD212 reimplemented the functions of these chips on a single chip called VDSC (Video Decoder and System Controller), and I guess in the reimplementation the "undocumented" functionality got dropped. The VDSC is used in all CD-i players from Mono-I on.

ICDIA has a Comparison table of all Philips and Philips-build consumer CD-i players listing the board types of each CD-i player; the Player Support section of the C-i Emulator website shows the board types of each CD-i player in the tooltips; the CDi-i Types section lists the chipsets used in each board type.

PS. Yesterday I started reading a new book where "Balboa" is an actual place where things happen. Mighty confusing...

[cdoty]

I think you're giving Balboa a little too much c r e d i t (weird spelling to avoid spam detection), really. Most of the "how to interface" stuff is in the C bindings that come with the Microware C compiler, not with Balboa.

I'm talking less about the actual instructions, and more about the sequence of operations needed to perform a task. For example, to use NVRAM, you could consult the code for the details of doing that.
I haven't looked at the code for this, so it could be a bad example. Balboa provides an example implementation of the Green Book standard, and it's mostly in C, rather than asm. It's not the most optimized way of doing it. Their 'control' structure take more time to process than the actual interfaces.

Charles actually happened to confirm both my best hopes and worst fears about using CD-i Emulator for development. He found the various tracing and debugging aids (which are much more powerful then whatever was available at the time) invaluable, but also managed to get stuck on the differences between the emulator and "real hardware" in several cases (some of which were bugs in CD-i Emulator, but others where not).

I learned pretty quickly to trust the output of the emulator. The Plane A palette wasn't working correctly at one stage in the project. I initially thought it might've been a problem in the emulator. Burning the disk showed the same problem on the CDi 450. There were a few areas, such as actual game performance, where the emulator isn't exactly the same as the real hardware, but it was close enough.

And the trace functionality was used to fix the last major bug in the program. It helped me track down a bad soundmap that was locking up on players with any additional ram or a DVC cartridge.

The debugger was vefy useful throughout the development. I wish I could've gotten symbols working correctly. But, a printf statement solved that problem. I could dump the address of the routine I was interested in to the console, and set it to run to that point.

the Player Support section of the C-i Emulator website shows the board types of each CD-i player in the tooltips; the CDi-i Types section lists the chipsets used in each board type.

That's the page I was looking for. I remembered the page, but not where it came from. There's a lot of information there.