The tool "NHC" can convert the HDI format in other hard disk image formats.
http://euee.web.fc2.com/tool/nhc.html#nhc

Actually, I was able to find documentation (or, well, scraps of source code in Neko Project iI) describing the HDI format header and I was able to add support for directly mounting HDI images in DOSBox-X.

Converting won't help, because most HDI images I've tested with aren't formatted in a way the plain DOSBox project would support.

Some HDI images I've found seem to be formatted as 256 bytes per sector.

Some are formatted 512 bytes per sector, but the FAT filesystem is formatted as if 1024 bytes per sector. Some are even 256 byte per sector HDIs with a 1024 byte per sector FAT filesystem!

HDI images do not use the standard IBM partition table, but a proprietary IPL1 partition table defined by NEC for the PC-98.

My work in DOSBox-X has made it possible for IMGMOUNT to read PC-98 IPL1 partitions and handle FAT filesystems with 256, 512, or 1024 byte per sector formatting, therefore HDI images can now be mounted directly in DOSBox-X.

https://github.com/joncampbell123/dosbox-x/releases

An additional note: I was wrong about the one MBR partition. There is no IBM compatible partition table. Most OSes (including Linux even!) will mistake the PC-98 boot sector as having one partition that starts at sector 0, but it's not valid. Most OSes could validate that if they were to note the partition type field is 0x00.

TheGreatCodeholio wrote:

Actually, I was able to find documentation (or, well, scraps of source code in Neko Project iI) describing the HDI format header […]
Show full quote

Actually, I was able to find documentation (or, well, scraps of source code in Neko Project iI) describing the HDI format header and I was able to add support for directly mounting HDI images in DOSBox-X.

Converting won't help, because most HDI images I've tested with aren't formatted in a way the plain DOSBox project would support.

Some HDI images I've found seem to be formatted as 256 bytes per sector.

Some are formatted 512 bytes per sector, but the FAT filesystem is formatted as if 1024 bytes per sector. Some are even 256 byte per sector HDIs with a 1024 byte per sector FAT filesystem!

HDI images do not use the standard IBM partition table, but a proprietary IPL1 partition table defined by NEC for the PC-98.

My work in DOSBox-X has made it possible for IMGMOUNT to read PC-98 IPL1 partitions and handle FAT filesystems with 256, 512, or 1024 byte per sector formatting, therefore HDI images can now be mounted directly in DOSBox-X.

If you're wondering, I was able to find some scraps of information on the IPL1 partition table by poking around the source code to GNU parted.

https://github.com/joncampbell123/dosbox-x/releases

Dear TheGreatCodeholio,

you wrote:
IMGMOUNT now supports .HDI disk images. You can now directly mount most HDI images PC-98 games are distributed in to a drive letter.

Is it possible to give me an example for the dosbox.conf?
As I said, I have no experiences to use dosbox.

Thanks a lot.

Anna

DOSBox-X emulates IBM PC/AT mode by default.

To get PC-98 mode, you will need:

[dosbox]
machine=pc98

Then

imgmount d: image.hdi

Which will attach the contents of the HDI image to drive D:

HDI images have a header that describes the geometry, so the -size option is not needed.

Thanks a lot for the help. Just see the booting from PC-98 mode is not supported yet.

DOSBox-X currently boots into IBM PC/AT mode to switch to PC-98 mode, but as emulation develops eventually DOSBox-X will start up and boot in PC-98 mode from the BIOS if machine=pc98.

I had to do the transitional design to ensure that a stable framework was laid before moving the "switch point" closer to startup.

BOOT was fixed not to boot PC-98 disks because too much is missing still from the emulation. There still remain a lot of BIOS calls to implement before I can reenable BOOT.

There's no sense booting a disk if the BIOS interrupt to read disk sectors doesn't do anything, right?

Wonderful, today is my first time to hear the nice FM 86-board sound on DOSBox-X in PC98 mode.
I edit the startup lines.

1[autoexec]
2# Lines in this section will be run at startup.
3# You can put your MOUNT lines here.
4imgmount d: "c:\Emulator\PC DOS\DOSBox-X\Software\Hard Disk\Marble_Cooking.hdi"
5d:
6autoexec.bat

Thanks again, TheGreatCodeholio 😊

Thanks for all the effort you've put into Dosbox-X, TheGreatCodeholio! I've about finished loading up a single DOSBox-X virtual PC with all my favorite games and applications I used to play as a kid, such as Alleycat, King's Quest, WordPerfect, WFW 3.11, and Turbo Assembler.

Two things I noticed today I wanted to make you aware of:

1. output=opengl doesn't seem to work - it always activates openglnb instead. Also, when output=opengl and fullscreen=true, it doesn't start truly fullscreen, but rather it starts sorta maximized (and a bit off center, at that). Alt-Enter twice fixes the problem. (There is no problem when output=direct3d)

2. fpu=true doesn't seem to emulate an authentic fpu from that era. Specifically, in MS PDS QuickBasic 7.1, this code returns 0 (false) instead of -1 (true) only when fpu=true:

1PRINT VAL("1") = 1

This can be seen in the game NIBBLES.BAS (included with MS-DOS 5), which won't accept an answer to "number of players?". You can also test the game Operation Neptune, which is not playable with the fpu enabled, as any numeric calculation in its calculator results in a "the answer you have calculated is too large for the calculator." error message, and direct entry for a correct answer is refused as being incorrect. Changing core and cputype settings have no effect. Of course, these programs don't need a fpu at all, as they will simulate a fpu when none exists, but in the interest of making DOSBox-X more accurate, you may want to implement a software fpu emulator that mimics the behavior of 486DX era PCs (at least when core=simple). Or leave the fpu disabled in your default config, as even Win95 doesn't require a fpu. Note that I have not tested these games on a 486 recently, but I don't ever remember an issue with them.

I'd also suggest you implement a 'default loadfix' so EXEs never load below the 64K mark, or automatic detection of exepack'd files (like W95 does) but I understand if that's not your goal. I just put loadfix in my autoexec prior to my menu (Direct Access) which seems to work jolly.

I'm running DosBox-X 0.82.1 64-bit on Windows 10 on a Core i7-7567U processor. I'd be happy to share details and my config settings with you if you'd like.

No big deal, but if you can reproduce these issues, you may want to log them in your buglist.

Have a great new year!
Thanks,
Shane

FPU emulation is a bit problematic right now for QuickBasic because the codebase inherited the main DOSBox problem of using "double" to emulate the FPU registers when the FPU registers would be better described as "long double". The difference between the two is about 13 bits of precision in the mantissa, which is irrelevant when playing Quake but enough to cause problems with QuickBasic programs. While I could work around it here in Linux (where GCC offers "long double" as the full 80-bit float datatype) there's nothing I can do about it on the Windows side (where Microsoft C has treated "long double" as an alias to "double" since the jump to 32-bit back in the Windows 95 days).

My short-term workaround for QuickBasic stuff so far has been to set fpu=false instead to emulate a system without the FPU so that QuickBasic uses it's own floating point emulation.

On Github I have an issue open already in which I do intend to add EXEPACK detection and write code within the DOSBox EXE loader to do the EXEPACK decompression natively by itself so that LOADFIX isn't necessary. I recall that MS-DOS has had EXEPACK detection built-in since MS-DOS 5.0, in fact.

I am curious though about the OpenGL issue, I'll look into that.

Thanks for the explanation! I see your dilemma - trying to emulate 80-bit registers with 64-bit variables. Looks like you'd have to write a FPU register emulation library separately and compile it with Intel's C++ compiler, or inline some assembly, or something similar to get it to work. Which of course is a bigger issue when you're trying to maintain the codebase across multiple compilers. Sounds like quite a pain. Well, I'd still suggest you disable fpu by default, or any app that assumes that 1=1 (inside the fpu) will have a problem, and I'd error on the side of compatibility. But that's up to you. Thanks!!

By the way, after DOSBox-X is started, you can use the menus to change output=opengl, which works fine. It just doesn't accept the setting from the conf file.

I also stumbled on a exepack'd readme program which is giving me problems with loadfix. If I execute "loadfix readme.exe", the readme viewer runs, but the read.me text file it is displaying is garbage. (!!) However, if I run loadfix first, and then readme.exe, it works perfectly. It's the readme program included with Direct Access 5.1. Other exepack'd files seem fine when executing "loadfix program.exe". Again, I normally start loadfix in the autoexec, so it's not an issue for me, but I wanted you to be aware of it.

Dear TheGreatCodeholio,

some PC-98 games need a switch to 2.5Mhz.
Please can you tell me what I have to add (dosbox.conf)?

AnnaWu wrote:

Dear TheGreatCodeholio,

some PC-98 games need a switch to 2.5Mhz.
Please can you tell me what I have to add (dosbox.conf)?

There are two ways to set the GDC speed.

One way is in dosbox.conf

[dosbox]
pc-98 start gdc at 5mhz=false

You can also change it at runtime using the PC98UTIL tool on drive Z:

Z:\PC98UTIL /gdc50

Sorry, you want the GDC at 2.5MHz:

Z:\PC98UTIL /gdc25

TheGreatCodeholio wrote:

Sorry, you want the GDC at 2.5MHz:

Z:\PC98UTIL /gdc25

Thank you, TheGreatCodeholio!

Adding support for pc98 (PC-9801? PC-9821?) really opens a world of Asian software!

But I really didn't understand the difference between pc98 and DOS/V software: there were a lot of Japanese games released in both formats. Some users in game collecting forums claim there are some Windows games made for pc98 machines that are not compatible with standard (like this. Examples like this game really confuse me!

DOS/V is an extension of DOS and BIOS calls on standard IBM PC hardware (with VGA) to render Japanese text at the DOS console. That works already in DOSBox/DOSBox-X.

PC-98 is it's hardware entirely. The only thing common between IBM PC and PC-98 is the MS-DOS system call interface. Beyond that the I/O ports, interrupts, and BIOS interfaces are entirely different.