BitWrangler wrote on 2023-11-04, 23:33:

Hmmm, what happens if you plug an IDE HDD jumpered to 8 bit XT mode into a 16 bit controller in an 8 bit slot? Nothing because it's using the wrong IRQ??

AFAIK, in the XT (5160) mainboard, ports below 200h are not fully functional for ISA expansion cards. This means a 16-bit controller with base address 1F0h is incompatible with the original XT mainboard, which is an additional complication to the IRQ14 line that leads nowhere. Furthermore, I'm not that sure that "8 bit XTA" is identical to the "8-bit mode" of Compact Flash cards. ATA tries to imitate IBM AT hard drive controller, and CF inherits the "imitate AT hard drive controller" requirement. On the other hand, it would make a lot of sense if XTA drives imitate the WD XT hard disk controller, which is conceptually different.

mkarcher wrote on 2023-11-04, 23:42:

BitWrangler wrote on 2023-11-04, 23:33:

Hmmm, what happens if you plug an IDE HDD jumpered to 8 bit XT mode into a 16 bit controller in an 8 bit slot? Nothing because it's using the wrong IRQ??

AFAIK, in the XT (5160) mainboard, ports below 200h are not fully functional for ISA expansion cards. This means a 16-bit controller with base address 1F0h is incompatible with the original XT mainboard, which is an additional complication to the IRQ14 line that leads nowhere. Furthermore, I'm not that sure that "8 bit XTA" is identical to the "8-bit mode" of Compact Flash cards. ATA tries to imitate IBM AT hard drive controller, and CF inherits the "imitate AT hard drive controller" requirement. On the other hand, it would make a lot of sense if XTA drives imitate the WD XT hard disk controller, which is conceptually different.

There was actually a debate about this over at VCFed. Someone says that an 8-bit capable CF card hooked up to a 16-bit Multi I/O card, then put into an 8-bit slot* with the 16-bit portion overhanging, did work with an appropriately configured XT-IDE Universal BIOS (i.e., despite the I/O ports looking like an AT disk controller, it knows to use polling instead of interrupt-driven, and 8-bit accesses to the data port)

*I don't remember if they tried it in an actual 5160 given the I/O port issue you just mentioned, or just stuck it in an 8-bit slot of a 386/486 board.

mkarcher wrote on 2023-11-04, 23:20:

The CompatiCard thus needs to contain a standard AT-type floppy controller with rate-switching support, and a BIOS extension that cares about rate set-up.

Yep ! Do not know about the Compaticard v1 as it has no bios but in another thread we did talk about 8bit DD/HD controllers with BIOS (like Joincom JC-1100 and a few others) that existed back in early 90's...
Very rare and expensive if you ever find one....

I got this one earlier this year, yet to test it, not in "XT mode" at the moment, don't have any machines ready. At the same time got a Seagate ST-02 SCSI/Floppy but that one is reputed only to have the SCSI BIOS and not have floppy code so motherboard dependant.

Nice ! Kouwell made a few diff 530's with BIOS that I know of, yours is a later model. All support DD and HD on a XT afaik. There is not much on the D rev, if you have time to save the bios, take some pics of the manual would be a great add to Vogon's Library.

For 3.5inch floppy drives, typically you can just plug a 1.44meg drive into an XT class computer (or any other computer with only a DD controller) and it will work perfectly as a 720kb drive.

So it is kinda redundant to go out and buy a 720kb DD drive just for this purpose. 3.5inch DD floppies have the same number of tracks as 3.5inch HD floppies, so you don't get issues with track width written.

Alternatively, if you use a HD floppy controller (virtually any 16bit ISA controller is fine with only the 8bit portion connected) and a suitable replacement floppy BIOS on an XT, they too will be able to use 1.44meg disks.

For 5.25inch floppy drive, 1.2meg drives have a thinner head as it writes more tracks to the HD disks (80 of) than a DD drive (40 tracks). You will sometimes see issues if you try to write a DD disk in a HD drive which has previously been written by a DD drive. The DD drive will write a wider track and the HD drive will have difficulty properly erasing and writing new content on it. If you only have HD drives, then you typically won't see issues, as none of the written tracks will be too wide to overwrite. Only in mixed environments of HD and DD drives where you are using DD disks in both for writing.

The ST-02 manual on minus zero degrees, provides this useful summary of what you can expect on various machines with this type of 8 bit, high density capable, but no floppy BIOS support expansion card.

1The ST02 supports up to two 3.5-inch or 5.25-inch floppy diskette
2drives.
3
4Table 1:  ST02 Diskette Support
5
6   -------------------------------------------------------------
7   |    Diskette    |    Capacity     |     Transfer Rate      |
8   -------------------------------------------------------------
9   |    5.25-inch   |    360 KBytes   |     250 Kbits/sec      |
10   -------------------------------------------------------------
11   |    5.25-inch   |    1.2 MBytes   |   300/500 Kbits/sec    |
12   -------------------------------------------------------------
13   |    3.5-inch    |    720 KBytes   |     250 Kbits/sec      |
14   -------------------------------------------------------------
15   |    3.5-inch    |   1.44 MBytes   |   300/500 Kbits/sec    |
16   -------------------------------------------------------------
17
18Diskette support in IBM PC-compatible systems depends upon the
19operating system used and the BIOS installed on the system board.
20The user may have to upgrade either the BIOS or operating system
21in order to obtain the desired diskette support.
22
23Table 2 outlines the operating system requirements for the
24various diskette drive types.
25
26
27                                                               4
28
29Table 2:  PC/MS-DOS Support for Diskette Drives
30
31  -------------------------------------------------------------
32  |  DOS Version  | 360 KByte| 1.2 MByte| 720 KByte|1.44 MByte|
33  -------------------------------------------------------------
34  | PC/MS-DOS 2.1 |    X     |          |          |          |
35  -------------------------------------------------------------
36  | PC/MS-DOS 3.0 |    X     |    X     |          |          |
37  -------------------------------------------------------------
38  | PC/MS-DOS 3.1 |    X     |    X     |          |          |
39  -------------------------------------------------------------
40  | PC/MS-DOS 3.2 |    X     |    X     |    X     |          |
41  -------------------------------------------------------------
42  | PC/MS-DOS 3.3 |    X     |    X     |    X     |    X     |
43  -------------------------------------------------------------
44
45IBM offers drive support starting at PC-DOS 3.2 for the 720 KByte
46diskette and at version 3.3 for the 1.44 MByte drive. The
47DRIVER.BIN module is installed via the CONFIG.SYS module at boot
48time.
49
50Microsoft offers driver support starting at MS-DOS 3.2 for the
51720 KByte drive through use of the DRIVPARM and DRIVER.SYS
52programs.
53
54MS-DOS 3.3 supports both the 720 KByte and 1.44 MByte drives
55using the DRIVER.SYS program.
56
57The MS-DOS DRIVER.SYS and DRIVPARM modules are installed via the
58CONFIG.SYS file at boot time.
59
60In addition to the requirement that the operating system support

61a particular diskette drive, the ROM BIOS installed on the system
62board must also provide compatibility.
63
64Table 3 indicates the diskette drives supported by the ROM BIOS
65installed in the most common IBM systems.
66
67PC compatibles that do not use an original IBM BIOS should
68consult the Operations Manual supplied with their system to
69determine the diskette drive support offered.
70
71
72                                                              5
73
74Table 3:  IBM ROM BIOS Support for Diskette Drives
75
76  -------------------------------------------------------------
77  |   IBM System  | 360 KByte| 1.2 MByte| 720 KByte|1.44 MByte|
78  -------------------------------------------------------------
79  |   PC, PC XT   |    X     |          |          |          |
80  -------------------------------------------------------------
81  |   PC XT 286   |    X     |    X     |    X     |          |
82  -------------------------------------------------------------
83  | PC AT (6 MHz) |    X     |    X     |          |          |
84  -------------------------------------------------------------
85  | PC AT (8 MHz) |    X     |    X     |    X     |          |
86  -------------------------------------------------------------
87  | PS/2 Model 30 |    X     |    X     |    X     |          |
88   -------------------------------------------------------------
89  |  PS/2 Model   |          |          |          |          |
90  |   50/60/80    |    X     |    X     |    X     |    X     |
91  -------------------------------------------------------------
92
93Note: The ST02 Host Adapter does not contain any ROM BIOS
94extensions for diskette drive support.

mkarcher wrote on 2023-11-04, 23:42:

I'm not that sure that "8 bit XTA" is identical to the "8-bit mode" of Compact Flash cards. ATA tries to imitate IBM AT hard drive controller, and CF inherits the "imitate AT hard drive controller" requirement. On the other hand, it would make a lot of sense if XTA drives imitate the WD XT hard disk controller, which is conceptually different.

Indeed - compactflash 8 bit mode is almost what an XTIDE-the-interface outputs and "only" needs appropriate drivers (option ROM) to work on an 8-bit bus, "standard" XTA (Commodore/Olivetti/Tandy/Seagate A-X) is logically different like that and with a somewhat different pinout, and of course IBM XTA just had to be further different...

Personally, I think that approach is the wrong way round.
You're treating the symptoms, rather than the cause.
But that's just me, of course.

The problem, I think, is the 8-Bit IBM PC, not the CF card or IDE interface.
Fixing the IBM PC design first by making it fully 16-Bit is more reasonable, maybe.

Either use a bus expander chip and widening it from 8-Bit to full 16-Bit i/o (with the 20 bit address range sadly being still in place).

Or, fix the motherboard and use an 8086/V30 proccesor?

The multiplexing issue (8088 and 8086 do differ here) surely is a bit of an issue, but maybe a CPU daughtercard holding the 8086/V20 can hold some glue logic and the RAM?

Or maybe, just include an IDE interface on the 8086 daughtercard, so it has full 16-Bit i/o?

Edit: Here's a commercial solution to fix an IBM PC. Orchid Tiny Turbo 286.

Source: https://www.computinghistory.org.uk/det/70883 … Tiny-Turbo-286/

While it's still not upgrading the PCs 8-Bit design to 16-Bit, it does have a real 80286, at least.

By tapping the pins on the 286 socket, it might be possible to wire on a real IDE host adapter/network card+XUB.

Edit: There's another card. The pin bar next to the 286.. Is that carrying ISA/AT bus signals?

Source: https://forum.vcfed.org/index.php?threads/tal … elerator.80428/

Thinking too small Jo, how you gonna run Windows XP unless you put this i it? https://web.archive.org/web/20020210063027/ht … cts/Ren370S.htm
Which at least has a floppy drive controller on board.

BitWrangler wrote on 2023-11-05, 13:45:

Thinking too small Jo, how you gonna run Windows XP unless you put this i it? https://web.archive.org/web/20020210063027/ht … cts/Ren370S.htm
Which at least has a floppy drive controller on board.

😂 YMMD!! 😃👍

Jo22 wrote on 2023-11-04, 13:48:

The only thing that should be taken care of is that overformatting a DD floppy to a HD floppy might not be reliable.
Back when 720 KB floppy disks were plentiful and cheap, many users formatted them to 1,44 MB.
It worked, yes. But it's not clear how reliable this was on the long run.

That required people to drill a hole in the corner, so that high density drives would indeed detect them as high density disks. That was indeed popular earlier on, when DD disks were cheaper, and indeed, even then, the longer term reliability of disks modified and formatted that way was questionable.

I remember doing the exact opposite at some point. My cousins were visiting us, and they had brought some 1.44MB high density floppy disks with them, hoping I could share some, uhm, "freeware" games with them. However, our M24 didn't support high density disks. I knew I could format those disks as 720 KB disks, but then their 386sx computer wouldn't be able to read them.

So I covered those rectangular holes with stickers, hoping that would fool their computer into recognizing them as DD disks. I gave them the disks along with instructions for when they got home: copy the games to the hard drive and then remove the stickers from the diskettes and reformat them as 1.44 MB disks again. If I remember correctly, it worked. 😁

by the way, Tech Tangents released a video a few weeks ago about the history of the 3.5" disk drive. It's an interesting and entertaining watch. 🙂

With 3.5" floppies, the difference of coercivity between DD and HD isn't great: 665 vs. 720-750 Oe, so yes, usually it's possible to substitute one with the other.
With 5.25", however, it's 300 vs. 600 Oe... don't even try!

Jo22 wrote on 2023-11-05, 11:04:

The problem, I think, is the 8-Bit IBM PC, not the CF card or IDE interface.
Fixing the IBM PC design first by making it fully 16-Bit is more reasonable, maybe.

The CF card is not a problem at all. A standard CF card will work perfectly with 8-bit I/O cycles only. This is an optional feature in the ATA standard, but a mandatory feature for CF cards.

The IBM PC is not a problem, it is an 8-bit architecture which works fine for what it is supposed to do. It did not really age well, but as a "professional level personal computer", one tier above the standard home computers, the architecture is fine.

The IDE interface is not a problem too. It makes a lot of sense in an AT to transfer the hard disk data using REP INSW / REP OUTSW in a 286-based system.

The problem thus is not any of the components, but the misguided attempt to combine them together. The 16-bit IDE interface is unfit for a the PC/XT 8-bit architecture.

Jo22 wrote on 2023-11-05, 11:04:

Either use a bus expander chip and widening it from 8-Bit to full 16-Bit i/o (with the 20 bit address range sadly being still in place).

The issue, especially with IDE, is that you must perform 16-bit transfers on the system bus, because the usual IDE hard drive can not deliver data in 8-bit chunks. On the other hand, the 8088 can not issue 16-bit transfers. When you perform an IN AX,DX instruction on an 8088 with DX=1F0, the 8088 will perform an 8-bit port read from port 1F0, followed by an 8-bit port read from port 1F1. There is no way for a bus expander to recognize whether the 8-bit access to 1F0 is the first half of a 16-bit access to 1F0, or it is a genuine 8-bit cycle. I generic bus extender is thus impossible. A specific bus expander for IDE is possible, and that's exactly what the XT-IDE hardware is foing.

Jo22 wrote on 2023-11-05, 11:04:

Or, fix the motherboard and use an 8086/V30 proccesor?

When you do that, it's not an IBM PC/XT anymore. You can build compatible systems using the 8086, like the PS/2 model 30 or the original Compaq Deskpro, but as they predate the IBM AT, they do not have a 16-bit expansion bus.

Jo22 wrote on 2023-11-05, 11:04:

Or maybe, just include an IDE interface on the 8086 daughtercard, so it has full 16-Bit i/o?

Edit: Here's a commercial solution to fix an IBM PC. Orchid Tiny Turbo 286.

There are multiple processor replacement solutions, for example the Intel Inboard 386, which is likely the most sophisticated one. When you build a retro system with a 286 or 386 processor, though, why would you pick an XT (or compatible) as base today? Starting with a 286 AT-type mainboard makes more sense than plugging an AT-on-a-card into an XT mainbaord...

Edit: There's another card. The pin bar next to the 286.. Is that carrying ISA/AT bus signals?

I guess that's for a piggyback 16-bit memory expansion card.

BitWrangler wrote on 2023-11-05, 13:45:

Thinking too small Jo, how you gonna run Windows XP unless you put this i it? https://web.archive.org/web/20020210063027/ht … cts/Ren370S.htm
Which at least has a floppy drive controller on board.

This thing seems to require an AT board. This thread is about the limitations of an XT board, so that solution is "thinking too large".

It doesn't actually need a board really apart from mechanical support. You could put it on a board that blew all it's caps or caught fire.

mkarcher wrote on 2023-11-05, 20:45:

The IBM PC is not a problem, it is an 8-bit architecture which works fine for what it is supposed to do. It did not really age well, but as a "professional level personal computer", one tier above the standard home computers, the architecture is fine.

Personally, I'm not sure about this one.
The IBM PC and PC/XT has always been under criticism, even back in the 1980s.

By contrast, I can't remember the same about other popular 8-Bit PC systems of its time, often based on Z80 and running CP/M.
They always ran rather snappy.

These MSX computers, too, which had up to 512KB of RAM if memory serves.

The only notable exception that comes to mind is the original TRS-80, maybe, which was nicknamed "Trash 80".
And the slow Z80 machine mode of the Commodore 128, maybe.

-

I mean, the problem isn't the XT design per se. PC BIOS, controller chips, graphics system and memory map can be left unchanged no problem.
It's the bottleneck problem, rather, I think. The interface of RAM and ROM on the motherboard, especially.
It should be natively 16-Bit or 8-Bit interleaved (with 8086 at the heart).

The 8088 has an 16-Bit ALU internally, just like the 8086, but hast to squeeze i/o through an 8-Bit infrastructure.
To compensate the bottleneck a bit, FiFo buffers and/or a high transfer speed would be needed.

Say, by using twice the current PC bus speed, then use a clock divider to get the PC bus back to normal.
That way, the 8088 will be always "ahead" and not slowed down by PC peripherals.

- I'm just a layman here, of course. The ET4000 VGA card has a FiFo that helps to improve bus communication, though.

-

In theory, it's possible to build an PC XT with an 8086/V30 at its heart and use 16-Bit i/o for the system bus (at the very least).

The 16-Bit part of the ISA connector can be interfaced, even, providing limited upwards compatibility with AT era ISA cards.
(Really basic stuff that merely uses 16-Bit i/o transfers and nothing fancy.)

It's mainly the 286 and IBM AT-specific things that are missing. Second DMA controller, second IRQ controller, 24-Bit address bus etc.

- Because, these are features considered to be AT specific, rather than XT specific.
Adding them would be possible, maybe, but likely requires some modification to the PC BIOS.

Things like PIT, PIC and DMA controller and serial port are historically 8-Bit devices.
These must be somehow interfaced on the 16-Bus. Maybe by using things like buffers (FiFos/LiFos), shift registers et cetera pp.

Examples of such 16-Bit XT class PCs are the Amstrad PC1512/1640 and the Olivetti M24.
The latter has an 16-Bit slot extension, too.

Jo22 wrote on 2023-11-05, 21:37:

Examples of such 16-Bit XT class PCs are the Amstrad PC1512/1640 and the Olivetti M24.
The latter has an 16-Bit slot extension, too.

Any particular reason why such an "8086 AT" wasn't a more common thing?
Was it simply not worth the trouble to go to all of the trouble to provide an AT board and peripherals and then cheap out on the CPU, by the time it made sense for clone vendors to create a 16-bit bus budget system?
Or more simply, how would it be "IBM compatible" when there wasn't a comparable brand-name IBM system.

jakethompson1 wrote on 2023-11-05, 22:20:

Any particular reason why such an "8086 AT" wasn't a more common thing?
Was it simply not worth the trouble to go to all of the trouble to provide an AT board and peripherals and then cheap out on the CPU, by the time it made sense for clone vendors to create a 16-bit bus budget system?

Sorry, I don't know. To me, it would be irrational to not to address these things from a purely rational point of view.

However, I'm looking at the situation from a 1990s point of view, also.

The IBM PC was designed before my time, so I can't really follow the design decisions made back then.

I guess back then it made sense to build the IBM PC as an 8-Bit PC (8-Bit by a hardware designer's point of view).

Probably because chips couldn't run at high frequencies (8 Mhz) or because the already slow DRAM chips needed additional waitstates, anyway.

The use of Z80 era support chips like the 8257, 8259, 8253, 8250 (SIO was better IMHO) was tempting, too.
Many home computers and S100 computers used them, they were readily available.

By going that route, it was possible to quickly establish a platform/a product family.

Later on, it could be replaced by the "real deal", an all 16-Bit system (16-Bit software, 16-Bit hardware).

So by setting the bar low at first, it was easy for IBM to improve with little effort, too.

Unfortunately, the 80186/80286 were somewhat of an improvement that the 8086 wasn't enough to be bothered with anymore, maybe.

Other third-party manufacturers shared a similar point of view, apparently.

To my knowledge, there are neither CPU accelerator cards for 8086 PCs, nor 8086-based CPU accelerator cards for 8088 PCs.

Rather, there are a dozen of 80286 and 80386 CPU accelerator cards for 8088 PCs.

So XT users must have been somewhat thirsty for improved performance.
Otherwise, there wouldn't have been so many cards of that kind being made.

-

The only exception I can think of were PC emulator boards for Atari ST and Amiga, maybe.
They not seldomly did contain a NEC V20/V30 or higher CPU on a daughtercard, to be interfaced with Motorola 68000 (a 16/32Bit hybrid).

-

Edit: There kind of were "80186 AT" like PCs, at least. Or rather, Enhanced XTs.
The BBC Master 512 and the Tandy 2000 come to mind.
And the Siemens PC-D PCs from the mid-80s.

They used the 80186 as a quicker alternative to the 8086 processor.
However, the 80186 was more of a microcontroller
(or SOC, System-On-a-Chip by nowadays terminology) which integrated some standard peripherals.
Unfortunately, these internal circuits weren't very IBM PC compatible. 🙁

So the resulting PCs weren't fully compatible, unless the designers ignored these internal "goodies" and attached the 80186 to the usual support chips, as with an 8086.

-

Anyway, there were quite a few DOS capable 16-Bit PCs based on an 8086.

There was the West German c't 86 PC, for example, which comes to mind (not IBM compatible).

As well as some 8086 based PCs made by East Germany (Robotron EC 1834 etc).

Quite a few PCs from ex USSR used 8086 CPUs, too.
https://en.wikipedia.org/wiki/K1810VM86#Applications

jakethompson1 wrote on 2023-11-05, 22:20:

Or more simply, how would it be "IBM compatible" when there wasn't a comparable brand-name IBM system.

Good question. In principle, it's just about removing the bottlenecks by using the full 16-Bit parts where possible.

At its heart, it would still be an PC/XT. The PC BIOS would work like before, the 8-Bit PC bus expansion cards would see same DMA/IRQ controllers as expected.

I mean, of course, on the electric level there would be small differences, yes. Duty cycles, timings of falling/rising edges etc. Those things.

There was a Microsoft MACH10 8086-10MHZ Overdrive card for pcxt

The trouble with the 8086 is that it cost almost as much as a 286 and lacked extended memory while still using slow multiplexed address pins.
It also lacked IRQs/DMAs so you would only get 1 16bit XTISA slot, more and it could only be accessed with ports.

They WEREN'T rare, IBM, Compaq and generic beige box places used them, Tandy used them in the last XT 1000'S but they were always stuck in a wierd mid range place that was hard to market early on. (Some early pcxt software broke due to timing even on an 8086) Later the 8086 was a low end CPU that was slightly faster than an 8088 and again hard to market