9 Dec
2021
9 Dec
'21
8:49 p.m.
From: Steven Malikoff
Was there ever an indicator panel for the RC11? .. I
have a set of RC11
modules .. No backplane though. I've not found any docs for these, I suppose
they're probably on bitsavers and have overlooked them.
Looking at the manual and engineering drawings (at BitSavers, as you guessed), no lights.
I've added links to those to the CHWiki RC11 page:
https://gunkies.org/wiki/RC11_disk_controller
The engineering drawings have the wirelist for the backplane, so it would be
possible to wire a new one. (I'm in the process of doing that for my KE11-A.)
Not sure it would be much use without an RS64 drive, though.
Noel
9 Dec
9 Dec
11:15 p.m.
On 12/9/2021 7:49 PM, Noel Chiappa via cctalk wrote:
One could perhaps emulate the RS64 data stream using a fast-enough
micro, ala the MFM emulator.
JRJ
From: Steven
Malikoff
Was there ever an indicator panel for the RC11?
.. I have a set of RC11
modules .. No backplane though. I've not found any docs for these, I suppose
they're probably on bitsavers and have overlooked them.
Looking at the manual and engineering drawings (at BitSavers, as you guessed), no
lights.
I've added links to those to the CHWiki RC11 page:
https://gunkies.org/wiki/RC11_disk_controller
The engineering drawings have the wirelist for the backplane, so it would be
possible to wire a new one. (I'm in the process of doing that for my KE11-A.)
Not sure it would be much use without an RS64 drive, though.
Noel
10 Dec
10 Dec
12:06 a.m.
On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:
One could perhaps emulate the RS64 data stream using a fast-enough
micro, ala the MFM emulator.
Why does everyone seem to want to emulate HW like this with a micro when
a reasonable FPGA implementation with some external FRAM would do the job?
The SMD/ESDI emulator that I've been working on has to "brute force" the
emulation because of BW concerns.? That is, it has to read the entire
emulated disk image into DRAM because:
1. You need at least a track's worth of buffering to send/receive the
data though the data interface (serial)
2. You don't have enough time to transfer tracks in/out of the track
buffer to flash (or what ever) to meet the head switch times
3. You don't have enough time to transfer whole cylinders in/out of the
cylinder buffer to flash (or what ever) to have reasonable
track-to-track seek times
So it will require a micro, but that's mainly to manage what's going
in/out of the (large) DRAM back to flash (it reads the entire emulated
disk image into DRAM during boot).? All of the actual commands and data
movement across the interface are all done by an FPGA.
--
TTFN - Guy
9:21 a.m.
On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk wrote:
On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:
1) Because not everyone has that kind of design experience and
capability (I do, but that is beside the point). In such a case,
suggesting a FPGA might cause those readers to just skip it without
further thought, whereas suggesting a micro is less likely to have that
effect on someone who *does* have the design experience.
2) Because the tooling on FPGAs is sometimes a pain and the parts
themselves are always in flux, and the updated tools often don't support
the older parts. Over the last 20 years I have gone through at least 3
different FPGA development boards and toolsets, where as my original
Arduino is just as useful as ever.
3) Because a highly flexible FPGA development board costs a lot more
than a micro, and micros would be a lot cheaper on a stand-alone PCB
than an FPGA part (or an FPGA through-hold carrier for those who are not
up to doing something like an FPGA part on a PCB.)
4) Because a micro form factor is smaller than an FPGA development board.
5) For someone well versed in software but not as well versed in design
(though enough that they could still do what you suggest), doing the
software might only take a couple of days for something like a 64Kw disk
(if it isn't too fast), and easier to debug/fix/enhance as well.
6) Because it was just a *suggestion* that one might emulate the disk
itself in hardware (see also point 1).
On the other hand, speed kills, and some disks are just too fast for a
micro alone to do.
One could perhaps emulate the RS64 data stream using a fast-enough
micro, ala the MFM emulator.
Why does everyone seem to want to emulate HW like this with a micro when
a reasonable FPGA implementation with some external FRAM would do the job?
The SMD/ESDI emulator that I've been working on
has to "brute force" the
emulation because of BW concerns.? That is, it has to read the entire
emulated disk image into DRAM because:
1. You need at least a track's worth of buffering to send/receive the
?? data though the data interface (serial)
2. You don't have enough time to transfer tracks in/out of the track
?? buffer to flash (or what ever) to meet the head switch times
3. You don't have enough time to transfer whole cylinders in/out of the
?? cylinder buffer to flash (or what ever) to have reasonable
?? track-to-track seek times
So it will require a micro, but that's mainly to manage what's going
in/out of the (large) DRAM back to flash (it reads the entire emulated
disk image into DRAM during boot).? All of the actual commands and data
movement across the interface are all done by an FPGA.
Cool. Would love an ESDI emulator for my Apollo DN3000 and SMD
emulation for my VAXen and PDP-11/24.
12:57 p.m.
On 12/10/21 6:21 AM, Jay Jaeger via cctalk wrote:
Yes, it's on my project list...I have it mostly designed but other stuff
has pushed in front of it.? The big issue is the SW (HW is fairly
straightforward)..which is funny because I'm a system SW guy.? ;-)? I'm
using a Xilinx Zynq FPGA mainly because I need:
* A reasonably fast processor for handling the run-time management of
buffers (one version has 4 ARM Cortex-A9 CPUs running at 1+GHz and
the other has 4 ARM Cortex-A53 CPUs running at 1.5GHz).
* Lots of DRAM (has to contain the entire emulated disk image).
Smaller Zynq FPGA will support 1GB of DRAM and the larger one (at
least the one that I'm using) supports 4GB of DRAM.
* Lots of internal RAM (has to contain the maximum sized cylinder)
* A *fast* connection between the DRAM and internal RAM (this
determines the track-to-track latency).? Cylinders can be up to 1MB
(32KB/track, 32heads per cylinder) so when seeking, up to 2MB (1MB
in, 1MB out) has to be moved to/from DRAM.? I'm trying to keep the
seek times < 10ms (ideally ~4ms) so that means my data rate has to
be on the order of 200-500MB/s.
I'm doing this for my Symbolics machines (ESDI and SMD) and 11/70 (SMD).
--
TTFN - Guy
On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk
wrote:
All valid points.? My frustration has been where I see projects that use
a RPi for something that a simple HW circuit/CPLD/FPGA could have done
it simpler and more efficiently.
I've lost count of the FPGA boards that I have.? I also typically don't
use eval boards for actual projects other than testing a few "flows".?
Everything gets done with a custom board because I typically need other
components and it gets too messy if I'm just using an "off the shelf"
eval board (and more than likely the eval board doesn't have enough I/Os).
I should also note that the Beagle Bone MFM emulator isn't actually fast
enough.? It works OK if you only have one drive but it's not fast enough
to handle the drive select signal when you have more than one.
On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:
1)? Because not everyone has that kind of design experience and
capability (I do, but that is beside the point).? In such a case,
suggesting a FPGA might cause those readers to just skip it without
further thought, whereas suggesting a micro is less likely to have
that effect on someone who *does* have the design experience.
2)? Because the tooling on FPGAs is sometimes a pain and the parts
themselves are always in flux, and the updated tools often don't
support the older parts.? Over the last 20 years I have gone through
at least 3 different FPGA development boards and toolsets, where as my
original Arduino is just as useful as ever.
3)? Because a highly flexible FPGA development board costs a lot more
than a micro, and micros would be a lot cheaper on a stand-alone PCB
than an FPGA part (or an FPGA through-hold carrier for those who are
not up to doing something like an FPGA part on a PCB.)
4)? Because a micro form factor is smaller than an FPGA development
board.
5)? For someone well versed in software but not as well versed in
design (though enough that they could still do what you suggest),
doing the software might only take a couple of days for something like
a 64Kw disk (if it isn't too fast), and easier to debug/fix/enhance as
well.
6)? Because it was just a *suggestion* that one might emulate the disk
itself in hardware (see also point 1).
One could perhaps emulate the RS64 data stream using a fast-enough
micro, ala the MFM emulator.
Why does everyone seem to want to emulate HW like this with a micro
when a reasonable FPGA implementation with some external FRAM would
do the job?
On the other hand, speed kills, and some disks are just too fast for a
micro alone to do.
Project below.? ;-)
The SMD/ESDI emulator that I've been working
on has to "brute force"
the emulation because of BW concerns.? That is, it has to read the
entire emulated disk image into DRAM because:
1. You need at least a track's worth of buffering to send/receive the
??? data though the data interface (serial)
2. You don't have enough time to transfer tracks in/out of the track
??? buffer to flash (or what ever) to meet the head switch times
3. You don't have enough time to transfer whole cylinders in/out of the
??? cylinder buffer to flash (or what ever) to have reasonable
??? track-to-track seek times
So it will require a micro, but that's mainly to manage what's going
in/out of the (large) DRAM back to flash (it reads the entire
emulated disk image into DRAM during boot).? All of the actual
commands and data movement across the interface are all done by an FPGA.
Cool.? Would love an ESDI emulator for my Apollo DN3000 and SMD
emulation for my VAXen and PDP-11/24. 
1:23 p.m.
On Dec 10, 2021, at 12:57 PM, Guy Sotomayor via cctalk
<cctalk at classiccmp.org> wrote:
All valid points. My frustration has been where I see projects that use a RPi for
something that a simple HW circuit/CPLD/FPGA could have done it simpler and more
efficiently.
I've lost count of the FPGA boards that I have. I also typically don't use eval
boards for actual projects other than testing a few "flows". Everything gets
done with a custom board because I typically need other components and it gets too messy
if I'm just using an "off the shelf" eval board (and more than likely the
eval board doesn't have enough I/Os).
I've done some pretty large VHDL designs (though not structured in the most
conventional manner). It's definitely one option. It's a good one for large
designs, or ones with severe performance requirements.
FPGA (VHDL or Verilog) work requires learning not just a new language but a way of looking
at design that's unfamiliar to software people. It's interesting and rewarding
but not a simple thing to do. And even "simple CPLD" projects aren't
necessarily simpler done that way, at least not for people like me.
To pick an example: I have a rudimentary software-defined radio I built around 1998 (using
Harris SDR chips) which uses a Lattice CPLD to interface to an EPP mode parallel printer
interface. That's conceptually a simple task but it turned out to be surprisingly
hairy. At the time it was the best answer; if I were to attempt a similar project today I
would most likely pick a Raspberry Pico to do the interfacing.
The Pico is in fact a good example to point to. While a Pi is a full Linux system, a Pico
is a deep-embedded device, tiny and dirt cheap even by Arduino standards. I've seen
low end FPGA boards but I don't know if you can beat $4 as the price tag. And add to
that the fact that FPGA development software often only runs on *gag* Windows, while
embedded software boards such as RPico offer open IDE systems that run on real host
operating systems.
I should also note that the Beagle Bone MFM emulator
isn't actually fast enough. It works OK if you only have one drive but it's not
fast enough to handle the drive select signal when you have more than one.
I haven't run into that, it's rather puzzing why that would be so given that MFM
does one drive at a time. In any case, the original comment was about RC11, which is
massively slower than MFM disks.
paul
9:57 a.m.
On Dec 9, 2021, at 11:15 PM, Jay Jaeger via cctalk
<cctalk at classiccmp.org> wrote:
On 12/9/2021 7:49 PM, Noel Chiappa via cctalk wrote:
One could perhaps emulate the RS64 data stream using a fast-enough micro, ala the MFM
emulator.
Quite easily, I'm sure. The RC11 runs at a word per 16 microseconds, a megabit per
second. The RF11 transfer rate is the same. So either one could easily be emulated: a $4
Raspberry Pico is more than enough for the task (the BeagleBone of the MFM emulator would
be massive overkill).
paul
From:
Steven Malikoff
Was there ever an indicator panel for the RC11? .. I have a set of RC11
modules .. No backplane though. I've not found any docs for these, I suppose
they're probably on bitsavers and have overlooked them.
Looking at the manual
and engineering drawings (at BitSavers, as you guessed), no lights.
I've added links to those to the CHWiki RC11 page:
https://gunkies.org/wiki/RC11_disk_controller
The engineering drawings have the wirelist for the backplane, so it would be
possible to wire a new one. (I'm in the process of doing that for my KE11-A.)
Not sure it would be much use without an RS64 drive, though.
Noel
904
days inactive
904
days old
6 comments
4 participants
participants (4)
-
cube1＠charter.net -
ggs＠shiresoft.com -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net