blog:pc98_devtools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
blog:pc98_devtools [2020/08/14 11:19] – [Troubleshooting on Real Hardware] johnblog:pc98_devtools [2020/08/22 09:34] (current) – [Makefiles & Compiling] john
Line 29: Line 29:
    * https://github.com/techfury90/pc98stuff - Sample C code for interacting with the hardware/graphics    * https://github.com/techfury90/pc98stuff - Sample C code for interacting with the hardware/graphics
    * https://github.com/PC-98/devwiki - Short wiki about potential development tools for PC-98    * https://github.com/PC-98/devwiki - Short wiki about potential development tools for PC-98
 +   * http://darudarudan.syuriken.jp/kai/pc9821.htm - Some short examples of interacting with PC-98 hardware, in Japanese
 +   * https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=102975&page=all - Discussion about implementing PEGC packed-pixel support for PC-98 within MAME
  
 ==== Graphics Hardware Differences ==== ==== Graphics Hardware Differences ====
Line 485: Line 487:
 You also need to distribute with your application the DJGPP go32-v2.exe DOS extender, and a DPMI server, of which for the PC-9821 there are relatively few. Apart from the fact that [[https://virtuallyfun.com/wordpress/2016/06/21/ms-dos-5-0-dpmi/|there is one distributed along with PC-98 MS-DOS 5.00]]//!!!// You also need to distribute with your application the DJGPP go32-v2.exe DOS extender, and a DPMI server, of which for the PC-9821 there are relatively few. Apart from the fact that [[https://virtuallyfun.com/wordpress/2016/06/21/ms-dos-5-0-dpmi/|there is one distributed along with PC-98 MS-DOS 5.00]]//!!!//
  
-   * {{ :blog:pc98_dpmi_extender.zip |go32-v2.exe & dpmi32.exe}}+   * <del>go32-v2.exe & MS-DOS 5.00 dpmi32.exe</del> 
 +   * {{ :blog:go32_dpmi.zip|go32-v2.exe & MS-DOS 6.22 dpmi.exe}}
  
 You can of course optimise for //-mcpu=i586// and //-mcpu=pentium//, but they're a subset of the PC-9821 range. If you want your code to run on PC-9801 to PC-9821, your only real option is //-mcpu=i386//, though you may want to run two passes of your application to produce (for example) a generic 386 binary and one tuned for Pentium. You can of course optimise for //-mcpu=i586// and //-mcpu=pentium//, but they're a subset of the PC-9821 range. If you want your code to run on PC-9801 to PC-9821, your only real option is //-mcpu=i386//, though you may want to run two passes of your application to produce (for example) a generic 386 binary and one tuned for Pentium.
Line 522: Line 525:
 ===== Troubleshooting on Real Hardware ====== ===== Troubleshooting on Real Hardware ======
  
-First of all, **DPMI32.exe** (from the PC-98 DOS 5.00 disks) and **go32-v2.exe** (which we built from the patched sources, above) work on real PC-9821 hardware, just as they do within the NekoProject II Kai emulator, as long as you have a VCPI service running (either EMM386, VEMM486 or similar), the result is the same.+First of all, <del>**DPMI32.exe** (from the PC-98 DOS 5.00 disks)</del> **DPMI.EXE** (from the MS-DOS 6.22 distribution) and **go32-v2.exe** (which we built from the patched sources, above) work on real PC-9821 hardware, just as they do within the NekoProject II Kai emulator, as long as you have a VCPI service running (either EMM386, VEMM486 or similar), the result is the same.
  
 So boot with typical memory managers in place: So boot with typical memory managers in place:
Line 540: Line 543:
 {{:blog:img20200814120842.jpg?500|}} {{:blog:img20200814120842.jpg?500|}}
  
-... a simple 'make' command should find MAKEFILE, right:+... a simple 'make' command should find MAKEFILE, right?:
  
 {{:blog:img20200814120855.jpg?500|}} {{:blog:img20200814120855.jpg?500|}}
  
-Noooo!+//Noooo!// 
 + 
 +Even explicitly specifing the file, like: <code>make.exe -f MAKEFILE</code> doesn't seem to work, because if I go the belts-and-braces approach and rename MAKEFILE to something sane in the DOS world like //MAKEFILE.TXT//, and then capture the output: 
 + 
 +{{:blog:img20200814121409.jpg?500|}} 
 + 
 +You can see that make never actually finds the file. There's definitely something strange going on with the way the make.exe is interacting with the files on the PC-98 filesystem is being accessed, compared to the same make.exe accessing files within Dosbox. 
 + 
 +It's not the entire GNU toolchain, because calling gcc.exe and other commands manually works: 
 + 
 +{{:blog:img20200814122848.jpg?500|}} 
 + 
 +But //not a single variation of the make incantation// will make it find and run the makefile: 
 + 
 +{{:blog:img20200814124159.jpg?500|}} 
 + 
 +Argh!!!! //What is going on?// 
 + 
 +Disaster, as I've now found that the same stuff works fine within the emulator: 
 + 
 +{{:blog:pc98_make_emulated.png?500|}} 
 + 
 +==== The Real Problem Is... ==== 
 + 
 +So, I figured out that there's something broken in the DJGPP build of make **3.71**, if instead you use make **4.3**, it works perfectly, both in the emulator and on a FAT32 filesystem on the real hardware: 
 + 
 +{{:blog:img20200814165108.jpg?500|}} 
 + 
 +The upside is that nothing else needs changing, just the single **make.exe** binary. 
 + 
 +Here's an updated version of the GCC + DJGPP development environment, included the updated version of make: 
 + 
 +   * {{ :blog:pc-9801_gcc-v2.95.2_djgpp-v2.03.zip |}} 
 + 
 +Note that this version also includes renamed libreadline.a (libread.a), libstdc++ (libc++.a) and libhistory (libhist.a) libraries, as the defaults supplied with DJGPP are over the 8+3 filename length of non-Windows 95 systems. 
 + 
 +===== Next Steps ===== 
 + 
 +Go forth, create code for another obsolete computer platform, and be merry! 
 + 
 +Or, alternatively, [[:blog:pc98_devcode|have a look at my set of real-world programming examples for the NEC PC-9821 and its graphics hardware]].
  • blog/pc98_devtools.1597403979.txt.gz
  • Last modified: 2020/08/14 11:19
  • by john