Bios needs to know what drives are installed. Bios sets up a special Diskette Parameters Table in Interrupt Vector Table (ram starting at 0) at offset 1Eh https://en.wikipedia.org/wiki/BIOS_interrupt_ … Interrupt_table that describes currently working FDD.

100000000 struct DPT // sizeof=0xB
200000000 {                                       // XREF: seg000:FDD_par_Table/r
300000000     unsigned __int8 step_rate_head_unload;
400000001     unsigned __int8 head_load_non_dma;
500000002     unsigned __int8 motor_off_delay;
600000003     unsigned __int8 bytes_per_sector;
700000004     unsigned __int8 sectors_per_track;
800000005     unsigned __int8 gap_length;
900000006     unsigned __int8 data_length;
1000000007     unsigned __int8 gap_length_format;
1100000008     unsigned __int8 fill_byte;
1200000009     unsigned __int8 head_settle_time;
130000000A     unsigned __int8 motor_start_time;
140000000B };

IBM in its infinite wisdom didnt expect to support more than one type of floppy in 5150 BIOS and later was already too late for extend this in a clean compatible manner. Thus a hack was born where BIOS is constantly tracking which FDD is being accessed and switches this ram entry on the fly.
Sounds like your BIOS is not configured for two different floppies and doesnt know it needs to switch DPT.

I thought that the ROM of all the super-16 series supported 720K drives, but maybe that's not the case with TE. You can use DRIVPARM in your config.sys to tell dos what your drive is.

konc wrote on 2026-04-19, 15:45:

I thought that the ROM of all the super-16 series supported 720K drives, but maybe that's not the case with TE. You can use DRIVPARM in your config.sys to tell dos what your drive is.

Back in the days i never used commands like these in my computers. Also because they had 360KB drives, and after that PC it became a 486 where 1.44 was the standard. So i really never used 720KB/1.2MB drives.

I made a command DRIVPARM=/D:0 /F:2 /T:30 /S:9 and after a reboot MSD also showed a 720KB drive
After that, i did format a 1.44 floppy succesfull to 720KB (with the hole covered)

Thanks for the help.

Another question
Since the board had the bad leaking varta, it has been removed.
But what is the benefit of placing a new battery, since the drives are not stored in the BIOS? Even the MFM works without any issues.
If it is only for day/time saving, i better can leave it without battery?

DOS Retro wrote on 2026-04-19, 17:55:

Another question Since the board had the bad leaking varta, it has been removed. But what is the benefit of placing a new batte […]
Show full quote

konc wrote on 2026-04-19, 15:45:

I thought that the ROM of all the super-16 series supported 720K drives, but maybe that's not the case with TE. You can use DRIVPARM in your config.sys to tell dos what your drive is.

Another question
Since the board had the bad leaking varta, it has been removed.
But what is the benefit of placing a new battery, since the drives are not stored in the BIOS? Even the MFM works without any issues.
If it is only for day/time saving, i better can leave it without battery?

Great to hear it's working!

You are correct about the battery, its only purpose is to keep the RTC running. You don't need to replace it. When there is no setup utility it's very rare to have some error thrown and usually when the RTC is on a separate card.

DOS Retro wrote on 2026-04-19, 14:17:

Hi people. […]
Show full quote

Hi people.

I have a little issues with my Hyundai SUPER-16TE PC

Floppy Drive A: 720KB? 3,5" - Ye Data YD-645C1545C at end of the cable (after twist)
Floppy Drive B: 360KB? 5,25" Panasonic JU-455-7 at the middle of the cable

I think the DS settings are correct, since it formats a 5,25" 360KB floppy correct with command: format b:
The issue is that if I insert a 3.5" 1.44MB in drive A, and placed some tape over the "720KB" hole, it still formats the disk also at 360KB

When i try the command:
format a: /f:720
it comes with "Parameters not compatible"

I think it's recognising the drive A: as a 5.25" 360KB drive.
Am i correct? How can i change this?

@DOS Retro if you're still around and interested in this, could you please tell me if you had an XT-IDE card in the PC when you experienced the issue with the 3.5" floppy? I'm tinkering with something similar currently and made a weird discovery.

konc wrote on 2026-06-30, 18:09:

@DOS Retro if you're still around and interested in this, could you please tell me if you had an XT-IDE card in the PC when you experienced the issue with the 3.5" floppy? I'm tinkering with something similar currently and made a weird discovery.

I would love to hear about your weird discovery if it is related to XUB.

_Krille_ wrote on 2026-07-14, 20:37:

konc wrote on 2026-06-30, 18:09:

@DOS Retro if you're still around and interested in this, could you please tell me if you had an XT-IDE card in the PC when you experienced the issue with the 3.5" floppy? I'm tinkering with something similar currently and made a weird discovery.

I would love to hear about your weird discovery if it is related to XUB.

Sure, here it is: I own a similar Hyundai model, the Super-16V, with a lo-tech xt-ide card. I wanted to update XUB because it had an old 2.0.0 beta 3 version from the time I bought it and the easiest way for me was to temporarily add a 3.5" floppy. I experienced the exact same behavior, the 720K disks were formatted to 360K with 720K being impossible unless I used DRIVPARM like I suggested to OP.

The thing is, this series of Hyundai XTs were sold by the local computer shop and I'm very familiar with them: they all support 720K drives in their ROM, we all had them as kids. So I went on with the XUB update with the intention to tackle the floppy issue afterwards, only to discover that after the update the drive was recognized properly as I remembered and as it should!

So I don't know if it's 1) something on these Hyundais 2) something on older XUB versions 3) some cards were sold with a badly configured BIOS or 4) a completely unrelated thing if OP wasn't using such a card

Oh, I bet that was a bug in XUB that I fixed in r618. It would affect calls to INT 13h with AH=15h to return with the carry flag set if AH was non-zero on return from the other BIOS (the floppy BIOS in this instance). Info about that BIOS call can be found here. When DOS got an error in return (the CF set) it probably assumed a 360K drive as a default option.

Thanks, that's great info and as you said most probably it was my case. Now if only OP would see this to satisfy my curiosity...