Comments
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference: Neko Project 21/W and NP2kai implemented their planar mode PEGC support in those code files. Also: |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to http://www.satotomi.com/sl9821/sl9821_tec5.html 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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DOSBox-X 0.82.19 TODO:
|
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reference: http://www.satotomi.com/sl9821/sl9821_tec5.html English translation: |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tonight's notes:
|
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also:
|
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO for next examination:
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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing with the PC-9821Np laptop (the 386SX that supports 256-color planar):
|
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some PC-9821s do have a BIOS option called "16MBシステム空間" (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. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
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.