Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

A New Z80 Based WD2793 Floppy Disk Controller Board (FDC) for S-100 Bus systems

186 views
Skip to first unread message

monahanz

unread,
Feb 2, 2011, 1:49:59 PM2/2/11
to
For people that may be interested in building a new S-100 Floppy disk
controller (FDC) board that can be configured to work with most 8” and
5” (soft sectored) disks I have designed and built a new Z80 based
Western Digital 2793 FDC board. With Andrew’s help (3 prototype
boards later!) we now have a board that we are very happy with.

With its own independent Z80 on board, it is completely command driven
via 2 parallel ports (with strobe bits) to/from the S-100 bus. This
makes writing BIOS’es for any operating system very simple and easy.
For anybody that’s interested in obtaining a bare board we will be
ordering a batch real soon.

Please see here for a more complete description.

http://s100computers.com/My%20System%20Pages/ZFDC%20Board/ZFDC.htm

Chris

unread,
Mar 22, 2011, 1:58:32 AM3/22/11
to
A fascinating read of your FDC board design. Thanks for documenting it
so throughly. Just one important question: Are any of the 2793 vendors
listing the chip as still "active"? WD says the WD2793 is "obsolete".
If not, then there will come a day when even the surplus chip
merchants won't have any to sell. Am I correct in that even the NEC
765 FDC doesn't have the built-in PLL data separator that the 2793
includes?

Thanks,
Chris

Axel Berger

unread,
Mar 22, 2011, 11:16:00 AM3/22/11
to
Chris wrote on Tue, 11-03-22 06:58:

>Am I correct in that even the NEC 765 FDC doesn't have the built-in PLL
>data separator that the 2793 includes?

No, unless I'm very wrong the NEC didn't need any external extras. But
the literature at the time was full about how much harder it is to
program and it contains one bad and well documented bug, still present
in all modern successors:
After the index impulse it goes deaf and blind for a time. There were
many computers with WD controllers that started writing right after the
index, the Atari was one, and before Atari formatters were modified to
include a longish artificial pause there, its disks could not be read
by IBM compatibles.

glen herrmannsfeldt

unread,
Mar 22, 2011, 5:31:32 PM3/22/11
to
Axel Berger <Axel_...@b.maus.de> wrote:
(snip on FDD controllers)

> No, unless I'm very wrong the NEC didn't need any external extras. But
> the literature at the time was full about how much harder it is to
> program and it contains one bad and well documented bug, still present
> in all modern successors:

> After the index impulse it goes deaf and blind for a time. There were
> many computers with WD controllers that started writing right after the
> index, the Atari was one, and before Atari formatters were modified to
> include a longish artificial pause there, its disks could not be read
> by IBM compatibles.

That doesn't sound very good. Well, in normal read/write mode the
FDC mostly doesn't use the index pulse. For formatting, it starts
writing at the index, and stops at the next index. As the stop
won't be exact, there should be a gap before and after the index,
and I believe that there is in the IBM standards.

The gaps are necessary to allow for disk speed variation.
Gap3, which occurs between sectors, has to be long enough such
that disks formatted on a slow drive, and written on a fast drive,
won't overwrite the beginning of the next sector (header).

The main use of the index in read/write operations is to count
the number of revolutions in case the sector is never found.
(Such as a completely blank disk, or otherwise loss of the
sector header.)

-- glen

Axel Berger

unread,
Mar 23, 2011, 6:26:00 AM3/23/11
to
glen herrmannsfeldt wrote on Tue, 11-03-22 22:31:

>Well, in normal read/write mode the FDC mostly doesn't use the index
>pulse.

Quite, so it ought not to matter all. But the 765's problems are as
described, it can't read anything right after the pulse.

The Atari's floppy format was meticulously built exactly as per the
IBM's specification. When disks could not be exchanged it took some
time for people to find in what ways the real IBM differed from its own
spec. Another was that it ignored all the data in the root sector and
instead really used the unspecified media byte.

0 new messages