Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
blog:pc98_devtools [2020/08/14 12:01] – [Troubleshooting on Real Hardware] john | blog:pc98_devtools [2020/08/15 14:12] – [Reference Material] john |
---|
* 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 ==== |
===== Troubleshooting on Real Hardware ====== | ===== Troubleshooting on Real Hardware ====== |
| |
First of all, **DPMI32.exe** and **go32-v2.exe** work on real PC-9821 hardware, just as they do within the NekoProject II Kai emulator: | 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. |
| |
| So boot with typical memory managers in place: |
| |
| {{:blog:img20200814120730.jpg?500|}} |
| |
| ... and then try to start DPMI server and the DJGPP go32 DOS extender: |
| |
{{:blog:img20200814115811.jpg?500|}} | {{:blog:img20200814115811.jpg?500|}} |
| |
| So, we have the same behaviour as on the emulated PC-98 system, and the emulated IBM PC system |
| |
| //However//, I struggle to get **make.exe** to actually run a Makefile. No matter what I try to do, make just will not detect the presence of a makefile in the current directory. |
| |
| Given a directory of files like this: |
| |
| {{:blog:img20200814120842.jpg?500|}} |
| |
| ... a simple 'make' command should find MAKEFILE, right?: |
| |
| {{:blog:img20200814120855.jpg?500|}} |
| |
| //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]]. |