4 Feb
2001
4 Feb
'01
9:25 a.m.
From: Clint Wolff (VAX collector) <vaxman(a)qwest.net>
Heh... I was pondering this morn (whilst making
lasagne) about building
a RD52 replacement out of flash memory... I have previously looked at
emulation with a modern IDE hard drive, but gave it up as infeasible...
If that was too hard, emulating the RD52 itself is worse.
Each track occupies 2^n bytes from a 128MB (or larger
flash rom).
The step-in (step-out) signal increments (decrements) a counter
that drives the upper address bits.
You also need track 0000 indication so you can home to a
known point.
After a suitable delay (can anyone say 555 timer) the
seek complete
bit is set, and the bits are transmitted in serial fashion from a
fixed clock running at 5MHz (i think).
It's serial but there are embedded clock and little bits of data like
address marks, sync marks and data marks. The format looks
a little like Sync HDLC with MFM or FM encoding added.
If your recording it like a wav or image then expect to waste a
few bits per "bit" stored. I'd shoot for 8:1.
then there are things like INDEX and aligning data with it.
If write gate is asserted, the bits are latched, at
written to the
flash 16 bits at a time, thus giving a write cycle time of 3.2 uS
bytes are sent serial and the default is 8bits.
which should be fast enough. An improvement would be to
cache the
write data in a small RAM (32Kx8 is smallest I know of), then write
the whole thing at once during a seek. The tricky part here is
maintaining synchronization with the controller, probably requiring
a PLL of some sort...
Yep you need that too plus a lot more. Keep in mind the FDC (9224
on the RQDX3 is not fully compatable with RQDX1 ) runs at it's
internal clock for writing and you keep up or loose data. Also data
is sent at the physical sector level of single or groups of multiple
sector transfers.
Alternately, the data could be de-MFM-ed, and stored
just as data,
but this requires re-MFM-ing, and adding address/data marks as well.
It also breaks any diagnostic that wants to write long to force an
ECC error.
Yep your starting to see how complex it is. Believe it or not running
two FDCs back to back will work but the CPU intelligence needed
on the emulator side will not be trivial.
Really the simplest way out is an IDE or DRAM and a bus interface
of some sort. Sure this means a new driver is needed and that has
it's headaches. However from a hardware perspective the IDE is point
blank
simple with a Ramdisk being harder. What complicates the issue is
when someone wants to run V7 or Rt11 and wants a standard driver to work.
MSCP is common enough but requires a cpu to manage the protocal and
the sticky problem of copyright/patents.
I'd think the effort should start at the nuts and bolts level. IE: what
widely used
PDP-11 software driver do we have the most docs for and can modify
easily.
then build an IDE to match that. FYI: there is one that come to
mind...TU58!
The answer is yes it can be done but if you can't conceive of the
difficulties
you not likely to be able to make it work. For it to be useful for most
everyone
it would have to be simple enough to use (PCB and assembled) and
reliable
(means tested under all OSs and diags) or it would be a very expensive
science fair project.
Allison