VOGONS


First post, by konc

User metadata
Rank l33t
Rank
l33t

Here's a strange one for anyone interested in this kind of stories, and some questions I ended up with.

A humble PII PC that covers the late DOS era. Nothing special inside, Abit LX chipset m/b, 266MHz CPU, Geforce 2 MX, Voodoo1, NIC and of course a 3.5" floppy drive and the Audician 32 Plus sound card. Everything working fine. Then I find locally my favorite m/b of that era, the Intel SE440BX (Seattle), and for no reason other than using that, I swap motherboards. Everything else remains the same to the last screw. (Trying to keep this short) I discover that I cannot write to floppy disks, they appear write-protected. After the usual and the not-so-usual troubleshooting the issue is caused by the Audician's CTRL I/O port setting. Yes, you read this right: the default CTRL I/O port value "enables" write protection.

Proof I know I'd want myself: CTLR I/O port set to default 0x370, cannot write disk. CTRL I/O port set to something different, can write disk.

The attachment sound_card_config.jpg is no longer available
The attachment ctrl_base_io_370h.jpg is no longer available
The attachment ctrl_base_io_102h.jpg is no longer available

So I guess/deduce that I/O port 0x370 conflicts with the floppy controller?

The Phoenix BIOS has limited options (contributing to the stability of this m/b). Nothing regarding P'nP OS, clearing ESCD, switching slots, disabling unused COMs/LPT makes a difference. This the "Resources" page, the only page you can really configure such things, where I see nothing relevant.

The attachment bios_resources.jpg is no longer available

Questions/reason for this thread:
1. What on earth is this CTRL I/O port and what is it used for? I wasn't able to google it well enough to get answers. I haven't seen this value specified anywhere (in a SET BLASTER= for example) or asked in any software (unlike the Sound Blaster base I/O port for example). Does the value matter, or will it just work with every possible value that doesn't conflict with something else?
2. Isn't 0x370 the port for the secondary FDC? Why is my single on-board FDC & drive affected by the sound card using it? Is Intel (or Phoenix) doing weird and uncommon things using it for the primary/single FDC instead?
3. If my guess for a conflict with the FDC is correct and I'm not assuming something completely wrong, does some software exist that could have indicated this problem/conflict?

And lastly some general comments after playing for a while with the software of these cards:
-On the internet there is a version 2.20 of the initialization/setup utility SETUPSA.EXE. It doesn't work with one of my cards, the card appears initialized but outputs no sound. More common versions 2.09 and 2.11 always work.
-SETUPSA.EXE always overwrites file AUTOEXEC.BAK without any warning even if it already exists and has completely different content, to create its own backup of AUTOEXEC.BAT.

Reply 1 of 4, by konc

User metadata
Rank l33t
Rank
l33t

OK it looks like this was indeed a weird case! After investigating further I believe I can now answer #2 and #3 of my questions. I wasn't aware of ASTRA until this thread and it is an amazing piece of software that, among others, also shows the I/O ports of devices. I haven't seen all this information elsewhere.

  PnP Device 1
Vendor: Generic System Device
Device Name: Motherboard registers
PnP Device ID: PNP0C02
Class (08h): System Peripheral
SubClass (80h): Other
Node Size: 46 byte
Device Resources
I/O Port: 370h-371h
I/O Port: EAh-EBh
Memory Address: FFFC0000h-FFFFFFFFh - ROM 8-bit

<snip>

PnP Device 15
Vendor: Generic System Device
Device Name: PC standard floppy disk controller
PnP Device ID: PNP0700
Class (01h): Storage
SubClass (02h): Floppy
Node Size: 87 byte
Device Resources
I/O Port: 3F0h-3F5h
I/O Port: 3F7h
System IRQ: 6 - High True Edge
DMA Channel: 2 - Type 8237 (8-bit)

The FDC is using the usual port (duh, how did I even think it wasn't, nothing accessing it directly would work), but there is this "Motherboard registers" thing on 0x370!
So there was a conflict when assigning 0x370 to the soundcard, just not with the FDC. It all makes sense now, despite the very weird conflict result of floppy write-protect getting enabled.

Reply 2 of 4, by kmeaw

User metadata
Rank Member
Rank
Member

FDC on PIIX4 can use 370h-375h, 377h if FDC_DEC_SEL register is set (PIIX4, dword at offset 60h, bit 28). If that bit is unset, FDC is using the usual 3F0h-3F5h, 3F7h.

Reply 3 of 4, by Tiido

User metadata
Rank l33t
Rank
l33t

The CTRL IO is YMF71x control registers, those can be placed anywhere you want since it is specific to the YMF71x and nothing besides the drivers of it will do anything about these IO ports. My SETYMF software places them in Axx range so they're fully out the way of everything.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 4 of 4, by konc

User metadata
Rank l33t
Rank
l33t
Tiido wrote on 2024-10-25, 09:23:

The CTRL IO is YMF71x control registers, those can be placed anywhere you want since it is specific to the YMF71x and nothing besides the drivers of it will do anything about these IO ports. My SETYMF software places them in Axx range so they're fully out the way of everything.

Excellent, thanks! So problem solved and we have an explanation of why I was having this weird error.