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 cd351fe

Reverting to June 30 commit also didn't work but made a little difference.
git checkout 22dcd69
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.