I have followed the last days discussion on the vmsnet.pdp11 newsgroup and
the info-pdp11@village.org mail list with interest. I posted some first
order comments to the newsgroup yesterday, however I infer that the
discussion has occurred on the mail list. Therefore please forgive any
reiteration of yesterdays post - I am presuming most have not seen it.

I have an interest in sourcing legacy disks. In particular RD54s for use
with RQDX3s, where I have a disk deficit. My inclination is to design a
plug compatible "disk" to interface at the controller / disk (MFM)
interface; but, I am interested both in not reinventing the wheel and
learning from others experience.

The attraction of plug compatible "disks" is that existing operating
systems, in my case VMS, and their drivers will continue to work without
modification. Additionally, the RQDX3/MFM interface appears the simplest
available, is fully exposed for reverse engineering and permits validation
of the replacement "disk" by the standard exerciser utilities.
Consequently, I see my options as SecondUser RD54s, refurbished RD54s and
DIY RD54s; with a provisional decision in favour of the DIY RD54. Perusal
of the RQDX3, RD54(XT-2190) and RX50 print sets suggests a simple interface,
with substantial (but by no means complete) commonality with other pre IDE /
SCSI drives (I have skimmed the RLV12 and RXV21 schematics). Which suggests
the potential for reuse of an RD54/RX50 solution for other drives (RX02,
RL02, ..).

In outline 'all' that one need do is:
- interface the RQDX3 signals to modern logic (say 3V3 CMOS)
-- 422 (e.g. 9637 & 9638) for Rd/Wr Data to/from the RD54
-- TTL 7438 to 74LS14 for the discrete control signals
- program (in VHDL) an FPGA to emulate the RD54/RX50 interface
-- emulating the disks drive, cylinder and head select logic
-- generating the disk timebase and data: zero, sector pattern, MFM Rd
stream
-- phase locking to the MFM Wr stream, bit and word sync, and data
extraction
-- moving data for the current cylinder to / from local memory (512kby SRAM)
- program a microcontroller to interface the FPGA to a laptop PC
-- for example a Cypress FX2 with a fifo at one end and USB 2 at the other
-- the disk image would be held on the PC

Refinements/alternatives include:
- holding the disk image in DRAM for access by the FPGA
- sniffing Rd/Wr traffic through the FPGA to USB 2 to the PC
(which is of course part of the development process)

Design issues which will dominate the (RD54) design include:
- the read data rate is 625 kby/s (5Mb/s)
-- for all bytes of a 10,416(U) byte track (every revolution)
-- for all bytes of a 156,240(U) byte cylinder (at 30 us notice)
-- only local RAM under hardware control will provide this capability
- the cylinder refresh rate (during the seek interval) is ~52Mby/s (412
Mb/s)
-- i.e. 156240(U) bytes in 3.1 ms (min seek time)
-- obviously the controller would accommodate longer transfer (seek) times
-- remarkable how hard you have to run to keep up with obsolete disks
- the underlying issue is that all the sectors in each track are output
-- the controller only reads the few it wishes, but you don't know which


Moving on, some comments on points raised yesterday:

Flash memory cards could be used as the bulk memory, 128Mby to 1Gby cards
are affordable. However, localised wear is their Achilles heel. While they
would be fine for read only disks, their use for working drives (e.g. paging
or swap files) would either be short on the scale of days or would require
considerable ingenuity to spread the wear (my understanding is that the
inherent mechanisms would not cut the mustard). Which is a pity, but
perhaps there is a way.

USB 2 is my preference for peripheral to PC interfacing as it is likely to
be about for a fair number of years, is adequately fast, has a range of
(Microsoft maintained ;-) class drivers which get you talking and Cypress do
some nice chips. Also, the cylinder refresh rate is a bit high for 100Mb
Ethernet; but the best cure is a lump of DRAM on the FPGA.

A fair amount of information is readily available on the web, viz:
- RQDX3 prints
- XT2190 (RD54) prints and handbooks
- RX50 prints
- RXV21 & RLV21 Prints

Information on disk formatting, formatters and exercisers is an area in
which I would welcome some pointers. For example to: XXDP(+) sources, RD54
format information, etc.

The non-DEC Q-Bus and Uni-Bus interface chips are now, please correct me,
obsolete. While some are available from aftermarket suppliers, for the
usual prices; a simple approach is to salvage them from unwanted boards.
Nonetheless, at the risk of being wrong, the parts were / are:
- open collector
-- N8T38N, DS7838, DS8838, DS8641
- tristate transceivers
-- DC021(octal), DC005(quad), Am2908
Substitution of alternate parts is unlikely to work; the receiver thresholds
are non-standard, and the slew rates very slow by today's standards.


Finally, may I offer the following questions for a straw poll:
- what disks/controllers/processor/OS do you wish to rejuvenate ?
- what ways ahead would you commend / assist ?


Responses are invited.

Martin

----------
To unsubscribe (or subscribe) from (to) this list, send a message to
info-pdp11-request@village.org, with the first line of the message
body being "unsubscribe" or "subscribe", respectively (without the quotes).