PC-98 256-color planar mode

[joncampbell123]

Is your feature request related to a problem? Please describe. Add to PC-98 mode emulation of an older 256-color planar mode that once existed on PC-9821 systems.

This feature is sought after for use with Windows 3.1, who's 256-color driver defaults to this mode unless (somehow) it detects newer hardware that uses 256-color packed. Apparently Windows 3.1 with DOSBox-X attempts to use the planar mode instead.

Additional context I have little to no documentation on how this mode is set up, what the memory layout is or how pixels are written, how EGC/TDP/GRCG modes affect it, what Windows 3.1's 256-color driver expects to do with it or how it detects availability.

This issue is intended to be a discussion on the video mode, how it works, how to implement it, and how to incorporate it into DOSBox-X. It is intended to collect this information for anyone motivated to implement it and/or code to test it's implementation.

[joncampbell123]

For the record, I have a PC-9821 386SX laptop in which Windows 3.1 was already installed on it with the 256-color driver.

On this machine, the 256-color driver is clearly using the packed mode as determined by dumping A8000h-B7FFFh using DOSLIB's REMSRV.EXE utility, and the bank switching MMIO can be seen at E0000h as well.

Unlike DOSBox-X there is no linear framebuffer at F00000h on this system, though FA0000h-FFFFFFh appear to be a mirror of A0000h-FFFFFh.

If I copy the .DRV file to DOSBox-X and install it in the Windows 3.1 installation, the .DRV file attempts to use planar and misrenders in DOSBox-X. Clearly the driver can autodetect and support both 256-color planar and packed hardware. How it determines this is unknown at this time.

[joncampbell123]

Windows 3.1 is the only test case for the 256-color planar mode. No PC-98 games (as far as I know) use this mode. There is one game "battle skin panic 9821" that uses the packed 256-color mode and runs perfectly fine in DOSBox-X using bank switching, and there are ports of DOOM, DOOM II, and Wolfenstein 3D for PC-98 that use the 256-color packed mode and the linear framebuffer.

[joncampbell123]

I don't have any interest in pursuing this feature at this time, others are welcome to implement if they are motivated and they know more about this mode than I do.

[joncampbell123]

As always, if anyone submits patches to get this working I will credit them in the CHANGELOG and the source code as having implemented the 256-color planar mode.

[yksoft1]

For reference: https://github.com/AZO234/NP2kai/blob/master/mem/memvga.c https://github.com/AZO234/NP2kai/blob/master/io/pegc.c https://github.com/AZO234/NP2kai/blob/master/io/pegc.h

Neko Project 21/W and NP2kai implemented their planar mode PEGC support in those code files.

Also: http://nickle.shimbe.net/pegc.html http://www.satotomi.com/sl9821/sl9821_tec5.html

[yksoft1]

According to http://www.satotomi.com/sl9821/sl9821_tec5.html Port 09A8h switches between regular 640x400 mode and VGA 640x480 (31khz) mode.

MMIO at E0100h switches between PEGC packed and planar memory mode.

Starting from E0104h there are PEGC's own registers working like EGC's 04A0h~04AFh.

[joncampbell123]

@yksoft1 Thank you for posting that!

Writing 0x01 to E0100h does in fact seem to change how the 256-color mode behaves. It doesn't change how video memory is displayed, but it does change the video data you see at A8000.

I noticed through REMSRV.EXE that while Windows is running E0100h is constantly changing between 00h and 01h, which means the driver is using both packed and planar modes where convenient.

Also listed there is E0102h, which controls whether F00000h-F7FFFFh is the linear framebuffer or not. Apparently on this 386SX that is OFF by default, that's why it didn't show up, but if I wrote 0x01 to E0102h it appears.

[joncampbell123]

Apparently when Windows 3.1 isn't drawing, it leaves it at 00h which is why I thought it was packed mode at all times.

[joncampbell123]

DOSBox-X 0.82.19 TODO:

• F00000h-F7FFFFh should be mapped ONLY if PEGC E0102h is set to 0x01h, not all the time.
• If E0100h is 01h, add stub memory handler for 256-color planar (to develop later).
• Look into EGC-like registers at E0104h. How similar to EGC regs at 4A0h?

[joncampbell123]

Reference:

http://www.satotomi.com/sl9821/sl9821_tec5.html

English translation:

https://translate.google.com/translate?sl=ja&tl=en&u=http%3A%2F%2Fwww.satotomi.com%2Fsl9821%2Fsl9821_tec5.html

[yksoft1]

I think

DOSBox-X 0.82.19 TODO:

• F00000h-F7FFFFh should be mapped ONLY if PEGC E0102h is set to 0x01h, not all the time.
• If E0100h is 01h, add stub memory handler for 256-color planar (to develop later).
• Look into EGC-like registers at E0104h. How similar to EGC regs at 4A0h?

I think we should look for the code in the disassembly of pegcv8.drv for detecting whether planar mode is available, and claim that we don't support planar mode in our code for now.

[joncampbell123]

That works too.

I want to add a stub memory handler for 256-planar mode so that if Windows chooses it anyway, it can be written to the logfile that it was attempted.

[yksoft1]

Out of topic comment: pegcv8.drv may call INT 18h AH=30h with (AL=08h BH=21h) or (AL=0Ch BH=31h) or (AL=08h BH=01h) or (AL=0Ch BH=01h) , which is not implemented in our INT18 handler.

Neko Project 21/W code suggests that INT 18h AH=30h was used to switch between 24khz and 31khz, 640x400 and 640x480 modes.

[joncampbell123]

The 480-line mode support and 24/31khz support may come sooner than 256-planar. It will take me some time to figure this out, but I have real hardware to poke at and tools in DOSLIB to determine the behavior.

[joncampbell123]

Tonight's notes:

• The 256-color packed linear framebuffer at F00000 is not mapped by default [DONE]
• Writing 01h to E000:0102 (E0102) enables it, as documented [DONE]
• The linear framebuffer is mapped ONLY if 256-color mode is enabled. Writing 20h to port 6ah immediately unmaps the linear framebuffer at F00000h [DONE]
• The PEGC remembers that state even if 256-color mode switched off. If E0102h was 01h when 256-color mode was switched off, it will remain 01h and the linear framebuffer will reappear when you write 21h to port 6Ah [DONE]
• Print a warning if the guest application or OS attempts to use 256-color planar mode [DONE]
• Print a warning for PEGC MMIO writes we do not recognize [DONE]

[joncampbell123]

Also:

• The PC-98 build of HEXMEM (also in DOSLIB) will crash if EMM386.EXE is loaded and active and it calls the BIOS to read extended memory. Is that BIOS call emulated by EMM386.EXE on PC-98 in the same manner that IBM PC/AT versions of EMM386.EXE emulate the INT 15h call to access extended memory?

[joncampbell123]

TODO for next examination:

• If drivers and applications expect a linear framebuffer at 0xF00000 (the 15MB addressmark) then how do machines with more than 15MB of memory cope with this linear framebuffer? Do later systems maintain a 1MB hole there, using known configuration bits in the Intel motherboard chipsets? (known on IBM PC systems in the BIOS configuration screen as the 15MB "ISA hole" for ISA devices that used that region prior to EISA and PCI).

I'm aware from developing DOSBox-X that PC-98 counts extended memory using two variables in the BIOS data area: One for 286-era systems that counts up to 15MB, and another for 386-era systems that counts from the 16MB mark onward. So it's possible those variables could be set to represent a hole at the 15MB mark, but I need to check on real hardware.

[joncampbell123]

The PC-9821Lt2 laptop obviously does not support the 256-color planar mode (the other one I test does). The hardware signals that it does not support 256-planar by ignoring writes entirely to E0100h. The value read back is always 00h no matter what you write.

EDIT: In fact the memory region documented to control access plane and 8-plane EGC-like functions also do not respond to writes (E0104h-E0120h).

EDIT: Even if E0100h, E0104h-E0120h are not writable the 256-color Windows driver tries to use it anyway! XD

[joncampbell123]

Testing with the PC-9821Np laptop (the 386SX that supports 256-color planar):

• E0102h bits 0 and 1 are writeable, not just bit 0. The PC-9821Lt2 that doesn't support planar only allows writing bit 0. What does bit 1 do?
• E0100h only bit 0 is writeable
• 256-color planar mode only affects memory access at A8000h-B7FFFh. The linear framebuffer at F00000h is still packed pixels.

[yksoft1]

TODO for next examination:

• If drivers and applications expect a linear framebuffer at 0xF00000 (the 15MB addressmark) then how do machines with more than 15MB of memory cope with this linear framebuffer? Do later systems maintain a 1MB hole there, using known configuration bits in the Intel motherboard chipsets? (known on IBM PC systems in the BIOS configuration screen as the 15MB "ISA hole" for ISA devices that used that region prior to EISA and PCI).

I'm aware from developing DOSBox-X that PC-98 counts extended memory using two variables in the BIOS data area: One for 286-era systems that counts up to 15MB, and another for 386-era systems that counts from the 16MB mark onward. So it's possible those variables could be set to represent a hole at the 15MB mark, but I need to check on real hardware.

Some PC-9821s do have a BIOS option called "１６ＭＢシステム空間" (16MB System Space), worked basically the same as "Memory Hole At 15M-16M". Check the BIOS setup (System Settings Menu) in your PC-98s for that.

[joncampbell123]

• PEGC MMIO registers do not repeat within the E0000h-E7FFFh range.
• Windows 3.1's 640x400 16-color driver reprograms the GDC to 5MHz if you enter COMMAND.COM from the Program Manager, then programs the graphics GDC as if a 5MHz mode. The change is unexpected for DOSBox-X, so the screen is squeezed vertically. The 2.5MHz/5MHz setting affects only the graphics layer. The 5MHz layer requires 80 active display columns for 5MHz and 40 for 2.5MHz.
• The "memory hole at 15M-16M" hole is definitely there on a PC-9821Lt2, though the laptop does not have enough memory to test how system memory wraps around it.

[joncampbell123]

• Windows 3.1 reads port 9A0h to determine whether the GDC is actually running at 5MHz or not. But, it likes to program it to 5MHz when it changes modes anyway. If you exit back to DOS, the GDC is left in 5MHz mode regardless of the initial setting.

[HyabusaBadge]

PC-98 256-color planar mode is used in Windows 3.0B and Windows NT 3.x.

[joncampbell123]

@HyabusaBadge Correct. Windows for PC-98 is apparently the only software for the platform to use the 256-color planar (PEGC) mode.

[HyabusaBadge]

PC-98 version OS/2 is also a concern, but I don't know the details.

[joncampbell123]

The linear framebuffer exists in the "memory hole" at FF0000, which DOSBox-X does not yet implement. If it were implemented, the linear framebuffer could be available even if 16MB or more of RAM were present.

The memory hole can be detected by the BIOS data area in which one value counts up to 15MB, and the other count of memory past 16MB continues normally, but the two values imply a hole.

It was just brought to my attention there is an I/O port that can be read to detect the memory hole as well. I/O port 43Bh.

See also: http://hackipedia.org/browse.cgi/Computer/Platform/PC%2c%20NEC%20PC%2d98/Collections/Undocumented%209801%2c%209821%20Volume%202%20%28webtech.co.jp%29/io%5fmem%2etxt

This homebrew code uses it:

https://github.com/gameblabla/dosplayground/blob/master/video/pc9821/pc98.c#L53