Issues on copying files from 1232k floppy disk to harddisk FAT on PC-98?

[tyama501]

Hello @ghaerr ,

I need to investigate more but it seems something is not working to copy files on PC-98 with the latest image. What I have seen is when xms enabled(xms buffer) PC sometimes get stuck when coping somefiles, when xms disabled(64KB ext bufffer) PC does not stuck but makes some files with missing EOF.

I am copying files from 1232k floppy disk 1024B/sector to the hard disk with 512B/sector.

Couldn't find files after copying it from the floppy disk so the boot from the harddisk failed.

Booting from the floppy disk and mounting the harddisk. Files are corrupted. It says FAT: delete past EOF, if I overwrite the file.

It seems that there are several changes in buffers/disk drivers/xms with in 1 or 2 years, but I don't know these are related to the issue yet.

Thank you.

[ghaerr]

Hello @tyama501,

It seems there may be multiple issues, but certainly FAT file corruption seems to be end result. I am wondering about the following:

1. is problem related to hard drive only, or occurs also on floppy?
2. does problem occur on Neko or DosBox-X, or just real hardware?
3. has it been 1-2 years since last test of copying files, this seems quite long?

I would suggest picking arbitrary commit 2-4 months ago and trying that to start, especially if problem can be repeated on emulator. We can then look more deeply at where problem may be. It would be good to start by only using floppy and keep HD out of testing for time being.

Thank you!

[tyama501]

Thank you. I haven’t noticed on emulator before but I will check it. I might be using 1440k, 512B/sector when installing to the emulator harddisk. Well, actually there still is possibility of the hardware issue. I will also check with copying from floppy to floppy.

3. has it been 1-2 years since last test of copying files, this seems quite long?

Maybe the last time I copied many files to this hardware are when releasing elks 0.8.1.

[ghaerr]

Ok. It will be good to know whether 1232k works on floppy on emulator, then check 1440k floppy on emulator. Agree that issue could be 1440k floppies or hardware since neither have been tested in a while. I did check PC98 1232k on emulator 1-2 months ago but can't remember if I did a file copy or not.

[ghaerr]

If everything works well on emulator but not on real hardware, then issue could be related to new LOADALL. In that case, turn off XMS completely for real hardware testing and start with 1232k floppy only, then add 1440k floppy then HD, then XMS.

[tyama501]

Hello @ghaerr

I got exactly same error on the emulator after installing to the harddisk from 1232 floppy disk. I will add some print code to debug.

[ghaerr]

Good to know it repeats on the emulator. How about floppy -> floppy 1232k copy, does that fail, or is this limited only to HD copy?

We did update the HD code recently with regards to unifying the ATA and BIOS driver, it is possible the issue might have something to do with 1K vs 512 byte sectors.

[tyama501]

Floppy 1232k -> Floppy 1232k looks good at least on the emulator.

[ghaerr]

Floppy 1232k -> Floppy 1232k looks good at least on the emulator.

Good. Perhaps try rolling back to a commit close to July 1, 2025. This would be before the ATA/HD changes. If that fixes things, I can take a deeper look.

[ghaerr]

@tyama501,

I think I may have found the problem, this change was made to makeboot which uses the bioshd.h header file to determine whether sys is being run on a floppy or hard drive. Bioshd.h looks like the following:

/* the following must match with /dev minor numbering scheme*/
#define NUM_MINOR       8       /* max minor devices per drive*/
#define MINOR_SHIFT     3       /* =log2(NUM_MINOR) shift to get drive num*/
#define MAX_DRIVES      8       /* <=256/NUM_MINOR*/
#define DRIVE_HD0       0
#define DRIVE_FD0       4       /* =MAX_DRIVES/2 first floppy drive*/

#define HD_DRIVES       4       /* max hard drives */
#ifdef CONFIG_ARCH_PC98
#define FD_DRIVES       4
#else
#define FD_DRIVES       2       /* max floppy drives */
#endif
#define NUM_DRIVES      (HD_DRIVES+FD_DRIVES) /* max number of drives (<=256/NUM_MINOR) */

The ifdef for CONFIG_ARCH_PC98 means that makeboot may not always be being built properly for PC-98, and sys may then be running makeboot built for IBM PC. I have not verified this yet, but you might roll back to just prior to this commit, rebuild everything, and see whether the problem still exists.

Thank you!

[tyama501]

Hello @ghaerr Thank you for the findings.

Since the boot code for the harddisk/1440k floppy and 1232k floppy are different, I usually do

sys /dev/hda1 makeboot -f fat.bin

when installing from 1232k.

It looks the difference of ibm and pc-98 bioshd.h is the number of FDs. I don't know how that affect but I will try reverting as you have mentioned.

[tyama501]

Reverting to the prior to the makeboot modification didn't worked. git checkout cd351fe1c5327ae0a3a19e7de52a8cc9e643b1ef

Reverting to June 30 commit also didn't work but made a little difference. git checkout 22dcd692bc921b322a2bbd90750550d9d146c17f Date: Mon Jun 30 12:52:37 2025 -0700

Fix build error when CONFIG_BLK_DEV_ATA_CF set by default

It get stuck before try to find init and sh.

It seems there are multiple issues. First time I noticed this issue, I think I wasn't using makeboot, just copying files.

I will roll back a little more.

[tyama501]

Hmm.... I got same stuck problem as above, using 0.8.1. Somehow it booted on PC-9801RX last year...(it might be 0.8.0 but I don't think that is difference)

[tyama501]

No difference with 0.8.0. I will try formatting from dos, instead of using mkfat on ELKS when I have another time. I may did that on the real hardware before the install.

[tyama501]

Note : I have noticed nx programs don't work after installing fd1232 floppy -> fd1232 floppy with latest elks/microwindow. It gets back to console without any display. nxlandmine is long filename and changed file name to nxlandmi while copying but I am not sure that is related.

[tyama501]

Hello @ghaerr

OK, ELKS 0.8.1 install to harddisk worked after format on DOS instead of the mkfat.

It seems that @drachen6jp found the latest makeboot destroy 201-3ff when doing makeboot -f fat.bin /dev.. (fat.bin is 512bytes), so probably there is one issue on the latest makeboot as you mentioned. (Thanks @drachen6jp ) https://x.com/drachen6jp/status/1974491521471939029

Thank you.

[ghaerr]

Hello @tyama501,

It seems that @drachen6jp has identified the problem, which is that the 2nd 512 bytes HD image is filled with 0's, which overwrites the beginning of where the FAT table should be, which starts on the next sector (the same sector being zeroed).

I think the reason for this is the CONFIG_ARCH_PC98 ifdef used in makeboot.c header, which I a guessing is causing the makeboot or ELKS to write 1024 bytes (the 512-byte boot block + 512 bytes of zeros) to the first HD sectors, rather than just 512 bytes. This could happen if makeboot or the system believes that the sector size is 1K rather than 512 bytes. I will look into it.

However, I wanted to ask what you think about why when you rolled back to before the makeboot fix, and earlier than that, the system still did not work.

Also, are you thinking that DOS format rathe than mkfat is required? Is that still true? That doesn't quite make sense, unless mkfat is also creating a FAT image in the wrong location.

I will post a PR fix for makeboot and we can go from there, I suppose.

Thank you!

[ghaerr]

@tyama501, how do you add a hard drive to DosBox-X's configuration file? I can only test PC-98 using DosBox-X, and have never done that. Their instructions say to use "imgmount" from the DOS prompt, but I was thinking another method would be needed for ELKS.

[tyama501]

Hello @ghaerr

I also haven't found a way to add pc-98 harddisk to DosBox-X when using external OS. Also PC-98 need to create partition that cannot create with elks.

I don't have time today but I can test it later if there is PR.

Thank you!

[ghaerr]

Hello @tyama501,

I've identified the problem in #2390. Basically, makeboot -f never worked with fat.bin, which is why none of your commit rollbacks worked, and the system only worked when makeboot was not run, that is, when DOS format was used to create the FAT partition. This should now all be working.

The makeboot program was reading the 512 bytes from fat.bin into an internal zero-filled 1024 byte buffer, then writing a full 1024 bytes to the destination, which ended up overwriting and corrupting the FAT table. Thus some FAT entries worked, but the first entries were invalidated.

The bioshd.h header file does have a CONFIG_ARCH_PC98 dependency, but it turns out that ifdef doesn't ever change the operation or compilation of makeboot, so no change is necessary there.

Thank you!

[tyama501]

Thank you for the PR, I will try that later.

I meant I used sys and makeboot -f after formatting with dos. This only works older version of elks.

So, I also still don't understand why mkfat does not work. I think it is less priority than copy problem but I may compare FAT information when I have time.

Thank you.

[tyama501]

Oh, it might be first FAT location is different with mkfat and the dos formatter.

[tyama501]

But that doesn't make sense, only older elks works. (Well, there might be another issue as I haven't using makeboot when I first found this copy problem)

[ghaerr]

Can you please give me more information and/or screenshots about mkfat not working, as well as what you mean only working with older versions of ELKS? I can then debug mkfat problem in more detail.

Also probably a good idea to close this issue for makeboot and open a new issue for mkfat, we can then work on mkfat problem in new issue.

[drachen6jp]

Hello.@ghaerr Hello.@tyama501.

You can use HDD image in dosbox-x. when it starts DOS command prompt, ask this command z:>imgmount c hogehoge.img (https://www.dosbox.com/wiki/IMGMOUNT)

& I've tested new makeboot.c OK good. work fine. https://x.com/drachen6jp/status/1974638835360526757

thank you.

[tyama501]

Hello @drachen6jp , Good to see mkfat -> sys -> makeboot worked. Thank you.

Hello @ghaerr , It seems that bootopts is unrecognizable from kernel after installing to the harddisk from 1232k. It can open with cat and looks good. Do you have any idea why this happen?

[ghaerr]

It seems that bootopts is unrecognizable from kernel after installing to the harddisk from 1232k.

The most common reasons that /bootopts isn't recognized are that it is > 1024 bytes size, or that it isn't in the first 8 root directory entries. makeboot is run by sys first and copies /linux then /bootopts, so this is usually correct, but perhaps something else is/was on the FAT disk prior, or after formatting?

You can use ls -lU / to get an unsorted listing of the root directory to help look at what is happening.

Is this occurring after DOS format, or ELKS mkfat?

[tyama501]

Hello @ghaerr ,

Is this occurring after DOS format, or ELKS mkfat?

Both. Here is the ls -lU / It looks the bootopts is in 8 root directories.

[tyama501]

Also nx programs don't work after copying as I wrote before.

[ghaerr]

Also nx programs don't work after copying as I wrote before.

That is quite strange, can run ls -l /bin/nx* to see if they are zero-length? This, combined with the /bootopts failure makes me think it's related to continued filesystem corruption. Also perhaps run chmem /bin/nx* to see if the headers look OK. If the nx files are not zero-length, you can determine if they are readable using hd /bin/nxstart | more.

Good to see mkfat -> sys -> makeboot worked.

Since this worked for @drachen6jp, can you post the exact commands being used to create and copy the filesystem from 1232k to HD? I probably won't be able to recreate this since I am assuming that the hard drive is SCSI rather than IDE, but could try it on IBM PC or PC-98 on DosBox-X using IDE HD.

It also might be good to try running DOS chkdsk on the HD FAT filesystem, if possible.

[tyama501]

Hello @ghaerr ,

mkfat /dev/hda1/ 31000 (sync, shutdown) sys sync makeboot -f fat.bin /dev/hda1 sync

I will check file size of nx again later but nx problem also occurs installing from 1232k floppy to clean 1232k floppy just using sys.

Maybe you can try that on DosBox-X.

Thank you.