Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
blog:pc98_devcode [2020/08/22 09:19] – [Planar Video Modes] john | blog:pc98_devcode [2020/08/22 09:48] (current) – [PC-9821 PEGC 256 Colour Graphics Hardware] john | ||
---|---|---|---|
Line 3: | Line 3: | ||
So you've got your NP21Kai PC-98 emulator up and running, or you've resurrected an ancient NEC PC-9801 or PC-9821 and you've decided you want to do some C programming for it. | So you've got your NP21Kai PC-98 emulator up and running, or you've resurrected an ancient NEC PC-9801 or PC-9821 and you've decided you want to do some C programming for it. | ||
- | Where do you start? Well, first, get a working development environment up and running. [[blog: | + | Where do you start? Well, first, get a working development environment up and running. [[blog: |
Next you will want to figure out how to do some interesting things with the hardware, as otherwise it's just a normal command line DOS machine.... | Next you will want to figure out how to do some interesting things with the hardware, as otherwise it's just a normal command line DOS machine.... | ||
+ | |||
+ | ===== Pre-Requisites ===== | ||
+ | |||
+ | After [[blog: | ||
+ | |||
+ | * A VCPI memory mapper running (EMM386, VEMM486 or similar) | ||
+ | * A DPMI server running | ||
+ | * A copy of GO32-V2.exe in the same directory as your application | ||
+ | |||
+ | The VCPI memory mapper should be started at boot, but the DPMI server only needs to be run at the time your application starts. | ||
+ | |||
+ | A copy of DPMI.EXE and GO32-V2.EXE are including on the development tools page. | ||
===== Non-hardware Specific Examples ===== | ===== Non-hardware Specific Examples ===== | ||
Line 37: | Line 49: | ||
===== PC-9821 PEGC 256 Colour Graphics Hardware ===== | ===== PC-9821 PEGC 256 Colour Graphics Hardware ===== | ||
+ | There are several generations of custom graphics hardware on the PC-98: | ||
+ | |||
+ | * PC-9801, GDC: 640x400, 8 colour, 96KB VRAM (later 192KB) | ||
+ | * PC-9801VF, GC: 640x400, 16 colour, 96KB VRAM (later 192KB) | ||
+ | * PC-9801VX, EGC: 640x400, 16 colour, 256KB VRAM, added raster operation functions, bitblt and bit shift functions | ||
+ | * PC-9821AP, PEGC: 640x400, 256 colour, 512KB VRAM, added packed-pixel and planar addressing modes | ||
+ | |||
+ | The systems are // | ||
+ | |||
+ | My focus is on the later PEGC, 256 colour systems, since (a) this is the hardware I actually own, and (b), its most similar to DOS VGA or modern framebuffer hardware. | ||
==== Packed-Pixel or Chunky Video Modes ==== | ==== Packed-Pixel or Chunky Video Modes ==== | ||
Line 228: | Line 250: | ||
return 0; | return 0; | ||
</ | </ | ||
+ | |||
+ | It is this section of code which I used to test the functionality of the various DPMI services on PC-98 DOS. The only one which would correctly return all of the various dpmi calls was the **MS-DOS 6.22 DPMI.EXE**. There may be other third party DPMI services, but since this one comes with DOS itself, it's probably the easiest (and most reliable) one to obtain. | ||
//Note: You may want to create your DPMI memory info structure (__vram_dpmi__) and VRAM selector object (__vram_dpmi_selector__) as globals, since anything writing to the framebuffer (see next example, below) will need to access them.// | //Note: You may want to create your DPMI memory info structure (__vram_dpmi__) and VRAM selector object (__vram_dpmi_selector__) as globals, since anything writing to the framebuffer (see next example, below) will need to access them.// | ||
Line 241: | Line 265: | ||
* _farpokeb(), | * _farpokeb(), | ||
* _farpeekb(), | * _farpeekb(), | ||
- | * [[http:// | + | * [[http:// |
You //can//, therefore write directly to the framebuffer if you wish, but it's probably easier to create a local buffer which you write into first, compositing all of your display elements, and then transfer the entire buffer in one operation to the framebuffer hardware. | You //can//, therefore write directly to the framebuffer if you wish, but it's probably easier to create a local buffer which you write into first, compositing all of your display elements, and then transfer the entire buffer in one operation to the framebuffer hardware. |