3DO Development Repo

The 3DO doesn't have a general video mode like many other systems. There is a VDLP (video display list processor) which drives a DAC which is abstracted by the OS.

• The user's understanding of the VDL is not that of the hardware but of the software abstraction that massages the hardware interface.
• The OS hardcodes the number of user usable scanlines in the VDL validation.
• The OS / ROM has a list of supported modes (still searching for their locations) and validates requests based on those hard coded values.
• The VDL can theoretically drive PAL / NTSC but it appears to be hard coded by the OS to manage what the DAC actually supports (or to simply limit the DAC from sending PAL to NTSC sets or NTSC to PAL.)

• Patent 5,502,462 - Display List Management Mechanism: Table 6 on page 12 describes the DMA Control Word “display-path reconfigure word”. Bit 27's described function is “Selects the NTSC or PAL transmission standard for the output. 1=PAL 0=NTSC.”

• In Patent 5,502,462 it describes and shows in code the OS (via SubmitVDL) forbidding PAL (or NTSC if in the European region) an incompatible flag being set. Same with “selection of PAL line width.”
• Listed in Patent 5,502,462 is the function ProofVDLEntry (page 64) which shows the number of scanlines being hard coded to 240 (not even a #define). The development docs on the VDL indicate that setting the number of lines in the VDL to 0 means to finish out the field but it appears that's not a hardware feature but a manipulation of the VDL by the ProofVDLEntry function. It tracks the number of lines processed and replaces the 0 with a count of the lines left.
• DisplayInfo *GetFirstDisplayInfo(void): Can be used to get a list of DisplayInfo structures which contain a tag array of display features and values.
• Err QueryGraphics(int32 tag, void *ret): Used to look up information about the graphics environment.