3DO Development Repo

“'240p” when used in context to classic videogame consoles refers to a hijacking or hacking of the NTSC standard to output 60 distinct fields of data but using only one field type (typically odd) rather than alternating as the standard expects. This is possible because the signal from the source device actually is indicating to the display what to do. So long as this request isn't too far out of spec it works. This was due to the unreasonable, for the time, memory and compute requirements needed for a full 480i output.

“240p” doesn't really say anything about actual resolution of the original digital content or the frequency the display is driven at.

Additional information:

• https://en.wikipedia.org/wiki/NTSC
• https://en.wikipedia.org//wiki/Low-definition_television
• https://junkerhq.net/xrgb/index.php/240p_video
• https://www.hdretrovision.com/240p

The 3DO Opera in general has an often misunderstood rendering pipeline and before getting into the details of how the “A-B switch” / “240p mode” affects the system and games it would be good to read over the official development docs to get an idea of how it works but we will summarize it here.

• The system has 1MB of dual ported VRAM.
• The MADAM chip contains the CEL engine which is the primary method for rendering to the VRAM.
• The CLIO chip contains the Display Generator which takes a 320×240@16bpp framebuffer from the VRAM and generates a 640×480@24bpp data stream which gets consumed by a video DAC. The scaling always happens and has 4 modes. Off (integer scaled 2x), horizontal only, vertical only, or both horizontal and vertical. The scaling or “interpolation” is done via a patented technique by CLIO (not by the video encoder as stated by some sources.)
• The DAC provides vertical and horizontal sync signals to the CLIO.
• The DAC takes the 640x480x24bpp data stream and generates Composite and S-Video signals. The field data provided by CLIO to the DAC is determined by the input signals to CLIO by the DAC.
• The CLIO can be fed 2 "screens" which represent each field but this was mostly intended for stereoscopic displays, would have not been truly practical given the compute and memory requirements, and led to interlace artifacting on a normal display.

[0] panasonic_fz-1_-_technical_guide_us.pdf
[1] Display Generator Components
[2] Introduction to the 3DO Graphics Systems

On some Japanese Panasonic FZ-1 units there is a switch labeled “MODE SELECT” with “A” on to the left and “B” to the right. This switch is connected to the VP536A Digital Video Encoder 's CTRLB1 pin which, in combination with CTRLB2, controls the mode of the encoding. Whether to generate NTSC or PAL and if they should be progressive or interlaced.

The same (or related) DAC exists in other units, such as the Sanyo Try IMP-21J, but they do not have a switch like some of the FZ-1. However, it is simple to add such a switch and some RGB mods, such as citris3000psi's 3DORGB project, also have a 240p mode. Other details can be found here.

When the “semi-NTSC” progressive mode is enabled it changes the signals sent back to CLIO. The DAC will request the same field data over and over and so the CLIO will provide that data but the DAC will always interpret it as mentioned above. Meaning if the switch is thrown on an even field the image will be interpreted incorrectly and becomes notably blurrier than when on the odd field. This progressive mode is not pushed further up the rendering pipeline and therefore not your traditional “240p”. The DAC is reading 60 fields per second but the input of those fields are not each unique. They are half of a 640×480 at ~30Hz frame read twice. Not an explicitly generated 320×240 at ~60Hz as most consoles of the era.

Let's break out a digital signal analyzer and see if and how the VSYNC and HSYNC differ between the two modes. While the 3DO's Portfolio OS abstracts away the vertical blank signal, and developers expressly told not to rely on such things for game logic timing, it is possible that some games are using the vblank to manage the pace of the game logic and if the vblank is coming in at an increased rate then that explains the perceived increases in speed in some games.

If we look at VSYNC and HSYNC coming off a Sanyo Try IMP-21J we see the expected VSYNC frequency of ~59.94Hz and HSYNC of ~15.734KHz. When both the VSYNC and HSYNC fall at the same time we know (according to the DAC docs) that it is an odd field and as we would expect the very next VSYNC we see the misaligned and therefore we know it is the even field.

When in progressive mode we see the VSYNC frequency increases slightly to ~60.046Hz to align with HSYNC. Every VSYNC pulse falls at the same time as the HSYNC pulse.

So how does this change affect the 3DO hardware and software? Initially we tested a number of high level functions in Portfolio that might be used for keeping pace in a game but everything worked as normal except the VBlank rate changed ever so slightly in line with what was seen from the logic analyzer. Meaning anything which waited on VBlank ran a bit faster but without a frame counter you'd not notice unless the counter showed down to the hundredths of a FPS. Not enough to explain the nearly 2x gameplay speed increase seen in Escape from Monster Manor and Wolf3D. After talking with developers of both games (ewhac and burgerbecky respectively) it was found that a vblank counter, provided by the OS, was being used to calculate time passed and therefore control the game logic. This was done via the global structure GrafBase. Particularly the member gf_VBLNumber. When Mode B is active (DAC set to progressive mode) and only odd field signaling sent back to CLIO that value is incremented twice as fast as it normally would be. Any software using that value as a measure of time will think twice as much time passed than did and run the game logic twice as fast. Interestingly this does not effect all vblank counters. GrafBase→gf_VBLNumber is defined graphics.h

There are 3 ways to get the vblank count. The one described above is the only one which exhibits this double pumped behavior. The following two (which might actually be two ways to access the same data) are NOT affected by progressive mode.

• Timer Device VBlankTimeVal
• struct TimerDevice->timerdev_VBlankCount

The DAC does not wait for a specific field to start using for the output. When you flip the switch it could pick up the even or odd field depending on the timing. If the even field is used you'll have a noticeable flicker and blurriness due to the display trying to draw a shifted picture due to the even field having half its 20th line visible. With the odd field you'll have a stable picture.

Theoretically “yes”, on some models. Practically “no”.

CLIO has 4 IO pins referred to as ADBIO0 through ADBIO3.

ADBIO0 is wired up on some systems as INTRLC and connects to what would be CTRLB1 on the VP536. In Portfolio OS ADBIO0 is simply defined as “ADBIO_BIT0” and say that it is unused with a comment suggesting it might be used in the future to switch between NTSC and PAL. There is code to modify that bit but it actually toggles the value if it were called instead of setting it but more importantly it isn't called or available to be called by any user facing libraries. It might be possible in homebrew to directly write to the CLIO register (0x84) but that needs to be tested.