2 Nov
2013
2 Nov
'13
10:25 a.m.
I have been mulling a project to emulate MFM disks (DEC RD53 and RD54 in
particular) at the disk-to-controller interface. Before anyone asks, I don't
want to interface to Qbus (or any other bus) because I want to emulate the
least possible hardware and keep my RQDX3 cards working. And yes, I know
this has been talked about many times before, but I want to actually start
trying this out.
My idea is to use some kind of MicroController, talking to specific
interfacing logic that drives the lines, and using SD memory for the actual
storage. I am considering two approaches:
1. Just record the flux transitions in memory and play them back. This
needs me to be able to sample and drive the data lines from the
microcontroller at 25ns intervals because the pulse width of the flux
transitions is 50ns. This would need a pretty fast microcontroller, but is
my preferred solution as it seems the most general.
2. Build custom logic that does the sampling and encodes/decodes the
data in 8-bit bytes, so that the microcontroller would only need to read
data at a rate of 1 byte every 1.6us. I'd prefer not to do this as it
requires me to understand the encoding (not too hard I suppose) and build
custom logic, and makes the solution possibly a little less general.
I would need a development board that makes it easy to interface to the SD
memory on one side and to the custom interfacing logic on the other side
(perhaps with a serial interface for debugging too), remembering that there
is a 50-pin connector, although only 20 of these are signals, the rest are
either reserved or ground. I would need enough onboard memory to store a
whole cylinder which is just over 150Kbytes on the RD54.
If I am successful I would then like to be able to make several more of the
devices, so I would need something that is not too expensive to replicate. I
am not sure at this point whether development boards are a good idea for the
replication or if I would need to then source the actual microcontroller
chips myself and make my own boards. If I have to make my own boards then I
would need a microcontroller that is available as a DIP because I am pretty
sure surface mounting is going to be beyond me; it would also have to be
simple enough for me, who is not an expert in electronic design, to build
the other components like the volatile and non-volatile memory, SD interface
etc.
Looking for recommendations for a suitable microcontroller that does not
cost the earth ...
Thanks
Rob
2 Nov
2 Nov
10:36 a.m.
You have lots of options. I'd use something AVR or ARM. And there are
the "Arduino" boards which can be used with the Arduino ecosystem, or used
with a generic C/asm/basic/whatever compiler. If I were you I'd use an
Arduino mega 2560 or the new arduino due, with an ARM processor. Or the ST
(or NXP?)
processors, there are new ARM processors (very fast and powerful) in DIP-28
package.
---
Enviado do meu Motorola PT550
Meu site: http://www.tabalabs.com.br
----- Original Message -----
From: "Robert Jarratt" <robert.jarratt at ntlworld.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, November 02, 2013 3:25 PM
Subject: Looking for a MicroController Recommedation
I have been mulling a project to emulate MFM disks (DEC
RD53 and RD54 in
particular) at the disk-to-controller interface. Before anyone asks, I
don't
want to interface to Qbus (or any other bus) because I want to emulate the
least possible hardware and keep my RQDX3 cards working. And yes, I know
this has been talked about many times before, but I want to actually start
trying this out.
My idea is to use some kind of MicroController, talking to specific
interfacing logic that drives the lines, and using SD memory for the
actual
storage. I am considering two approaches:
1. Just record the flux transitions in memory and play them back.
This
needs me to be able to sample and drive the data lines from the
microcontroller at 25ns intervals because the pulse width of the flux
transitions is 50ns. This would need a pretty fast microcontroller, but is
my preferred solution as it seems the most general.
2. Build custom logic that does the sampling and encodes/decodes the
data in 8-bit bytes, so that the microcontroller would only need to read
data at a rate of 1 byte every 1.6us. I'd prefer not to do this as it
requires me to understand the encoding (not too hard I suppose) and build
custom logic, and makes the solution possibly a little less general.
I would need a development board that makes it easy to interface to the SD
memory on one side and to the custom interfacing logic on the other side
(perhaps with a serial interface for debugging too), remembering that
there
is a 50-pin connector, although only 20 of these are signals, the rest are
either reserved or ground. I would need enough onboard memory to store a
whole cylinder which is just over 150Kbytes on the RD54.
If I am successful I would then like to be able to make several more of
the
devices, so I would need something that is not too expensive to replicate.
I
am not sure at this point whether development boards are a good idea for
the
replication or if I would need to then source the actual microcontroller
chips myself and make my own boards. If I have to make my own boards then
I
would need a microcontroller that is available as a DIP because I am
pretty
sure surface mounting is going to be beyond me; it would also have to be
simple enough for me, who is not an expert in electronic design, to build
the other components like the volatile and non-volatile memory, SD
interface
etc.
Looking for recommendations for a suitable microcontroller that does not
cost the earth ...
Thanks
Rob
11:43 a.m.
Hmm... sadly all of those options seem a bit too slow when you consider that
I would need to sample at 40MHz. The Arduino Due clocks at 84MHz, the Mega
2560 only 16MHz, and the NXP in the DIP is 50MHz. Pity about the NXP that
otherwise looks like just what I would need in terms of packaging.
Have I missed something?
Regards
Rob
start
are
replicate.
build
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Alexandre Souza
Sent: 02 November 2013 17:37
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
You have lots of options. I'd use something AVR or ARM. And there are
the
"Arduino" boards which can be used with the
Arduino ecosystem, or used
with a generic C/asm/basic/whatever compiler. If I were you I'd use an
Arduino mega 2560 or the new arduino due, with an ARM processor. Or the
ST (or NXP?) processors, there are new ARM processors (very fast and
powerful) in DIP-28 package.
---
Enviado do meu Motorola PT550
Meu site: http://www.tabalabs.com.br
----- Original Message -----
From: "Robert Jarratt" <robert.jarratt at ntlworld.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, November 02, 2013 3:25 PM
Subject: Looking for a MicroController Recommedation
>I have been mulling a project to emulate MFM disks (DEC RD53 and RD54 in
> particular) at the disk-to-controller interface. Before anyone asks, I
> don't
> want to interface to Qbus (or any other bus) because I want to emulate
the
least possible
hardware and keep my RQDX3 cards working. And yes, I
know
> this has been talked about many times before, but I want to actually > trying this out.
>
>
>
> My idea is to use some kind of MicroController, talking to specific
> interfacing logic that drives the lines, and using SD memory for the
> actual
> storage. I am considering two approaches:
>
>
>
> 1. Just record the flux transitions in memory and play them back.
> This
> needs me to be able to sample and drive the data lines from the
> microcontroller at 25ns intervals because the pulse width of the flux
> transitions is 50ns. This would need a pretty fast microcontroller, but
is
> my preferred solution as it seems the most
general.
>
> 2. Build custom logic that does the sampling and encodes/decodes
the
> data in 8-bit bytes, so that the microcontroller
would only need to read
> data at a rate of 1 byte every 1.6us. I'd prefer not to do this as it
> requires me to understand the encoding (not too hard I suppose) and
build
custom logic,
and makes the solution possibly a little less general.
I would need a development board that makes it easy to interface to the
SD
> memory on one side and to the custom interfacing logic on the other side
> (perhaps with a serial interface for debugging too), remembering that
> there
> is a 50-pin connector, although only 20 of these are signals, the rest either
reserved or ground. I would need enough onboard memory to store
a
> whole cylinder which is just over 150Kbytes on the RD54.
>
>
>
> If I am successful I would then like to be able to make several more of
> the
> devices, so I would need something that is not too expensive to I
am not sure at this point whether development boards are a good idea for
the
replication or if I would need to then source the actual microcontroller
chips myself and make my own boards. If I have to make my own boards
then
> I
> would need a microcontroller that is available as a DIP because I am
> pretty
> sure surface mounting is going to be beyond me; it would also have to be
> simple enough for me, who is not an expert in electronic design, to > the other components like the volatile and
non-volatile memory, SD
> interface
> etc.
>
>
>
> Looking for recommendations for a suitable microcontroller that does not
> cost the earth ...
>
>
>
> Thanks
>
>
>
> Rob
>
2:11 p.m.
On 11/02/2013 11:43 AM, Robert Jarratt wrote:
Hmm... sadly all of those options seem a bit too slow
when you consider that
I would need to sample at 40MHz. The Arduino Due clocks at 84MHz, the Mega
2560 only 16MHz, and the NXP in the DIP is 50MHz. Pity about the NXP that
otherwise looks like just what I would need in terms of packaging.
Consider a Microchip PIC32--the "framed" SPI will run at 80MHz, so 40MHz
is easier. I did enough work with one, to prove that it was a viable
approach--then lost interest as I had no application for the idea.
--Chuck
10:52 a.m.
On 11/2/13 10:25 AM, Robert Jarratt wrote:
I have been mulling a project to emulate MFM disks
(DEC RD53 and RD54 in
particular) at the disk-to-controller interface.
you may want to work with Reinhard Heuberger on this
http://fafner.dyndns.org/~heuberger/indexE.html#file:///E:/homepage/indexE.…
1:19 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Al Kossow
Sent: 02 November 2013 17:53
To: cctalk at classiccmp.org
Subject: Re: Looking for a MicroController Recommedation
On 11/2/13 10:25 AM, Robert Jarratt wrote:
Thanks, I will contact him. I see he is doing it with an FPGA. That was my
first thought, but I think a microcontroller would be more flexible, if I
could find one that is fast enough and affordable.
Regards
Rob
I have been mulling a project to emulate MFM
disks (DEC RD53 and RD54 in
particular) at the disk-to-controller interface.
you may want to work with Reinhard Heuberger on this
http://fafner.dyndns.org/~heuberger/indexE.html#file:///E:/homepage/ind
exE.html
4:54 p.m.
On 02/11/2013 20:19, Robert Jarratt wrote:
I think you underestimate the FPGA,as I said the other night you can
always implement an embedded CPU in the FPGA. Alternatively you could
use something like the Elektor FPGA board
http://be.eurocircuits.com/shop/Offtheshelf/product.aspx?&ano=120099-91…
with embedded CPU but I am not sure this is fast enough, or has enough
capacity in the FPGA as its a cut-down starter kit...
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Al Kossow
Sent: 02 November 2013 17:53
To: cctalk at classiccmp.org
Subject: Re: Looking for a MicroController Recommedation
On 11/2/13 10:25 AM, Robert Jarratt wrote:
Thanks, I will contact him. I see he is doing it with an FPGA. That was my
first thought, but I think a microcontroller would be more flexible, if I
could find one that is fast enough and affordable. I have been mulling a project to emulate MFM
disks (DEC RD53 and RD54 in
particular) at the disk-to-controller interface.
you may want to work with
Reinhard Heuberger on this
http://fafner.dyndns.org/~heuberger/indexE.html#file:///E:/homepage/ind
exE.html
Regards
Rob
3 Nov
3 Nov
8:49 a.m.
Stupid question, but relevant:
Are you simply after an ND emulation for a limited number of platforms?
If so, it might be far simpler to program each platform specifically.
This is the way it's done with the inexpensive Chinese floppy
emulators and they work quite well for their purpose. One popular one
uses a STM32 ARM and little else. The larger benefit is that the flash
drive used to hold the data in its native form (i.e. not MFM pulses).
One variation I've seen even uses a USB connection to change the program.
I'm guessing that the primary consumer of this device will be the DEC
community. The personal computer community has had various devices
(such as IDE or flash drive) as replacements.
--Chuck
10:14 a.m.
On 03/11/2013 16:49, Chuck Guzis wrote:
Stupid question, but relevant:
Are you simply after an ND emulation for a limited number of
platforms? If so, it might be far simpler to program each platform
specifically. This is the way it's done with the inexpensive Chinese
floppy emulators and they work quite well for their purpose.
Floppy is about 0.5Mhz Hard Disk is 10MHz
One popular one uses a STM32 ARM and little else. The
larger benefit
is that the flash drive used to hold the data in its native form (i.e.
not MFM pulses). One variation I've seen even uses a USB connection to
change the program.
I'm guessing that the primary consumer of this device will be the DEC
community. The personal computer community has had various devices
(such as IDE or flash drive) as replacements.
--Chuck
I think there are lots of folks with odd-ball systems with MFM drives. I
have IBM3174 screen controllers....
Dave
11:08 a.m.
On 11/03/2013 10:14 AM, Dave wrote:
Floppy is about 0.5Mhz Hard Disk is 10MHz
ST506-type hard disk? My manuals way 5MHz; RLL 7.5Mhz. Perhaps ESDI,
but that's a different kettle of fish.
Point being that it's possible to emulate a HD 500Khz floppy using an
8MHz AVR; an 80MHz ARM is quite tame.
--Chuck
2:12 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: 03 November 2013 19:08
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
On 11/03/2013 10:14 AM, Dave wrote:
So, according to the manual I have, the data rate is 5megabits/sec. But, the
pulse width that you need to detect (and generate) is 50ns, requiring the
signal to be sampled at 25ns intervals, or 40MHz. Someone suggested to me
that even 40MHz may not be enough, but I have not had a reply back when I
asked what a better sampling frequency might be.
Regards
Rob
Floppy is about 0.5Mhz Hard Disk is 10MHz
ST506-type hard disk? My manuals way 5MHz; RLL 7.5Mhz. Perhaps ESDI,
but that's a different kettle of fish.
Point being that it's possible to emulate a HD 500Khz floppy using an 8MHz
AVR; an 80MHz ARM is quite tame.
--Chuck
3:05 p.m.
On 11/03/2013 02:12 PM, Robert Jarratt wrote:
So, according to the manual I have, the data rate is
5megabits/sec. But, the
pulse width that you need to detect (and generate) is 50ns, requiring the
signal to be sampled at 25ns intervals, or 40MHz. Someone suggested to me
that even 40MHz may not be enough, but I have not had a reply back when I
asked what a better sampling frequency might be.
No, I don't agree--the pulse that comes from the drive is used as input
to an edge-triggered T-type flip-flop; the pulse width itself is
irrelevant--only the time between pulses.
--Chuck
3:13 p.m.
On 11/03/2013 02:12 PM, Robert Jarratt wrote:
So, according to the manual I have, the data rate is
5megabits/sec. But, the
pulse width that you need to detect (and generate) is 50ns, requiring the
signal to be sampled at 25ns intervals, or 40MHz. Someone suggested to me
that even 40MHz may not be enough, but I have not had a reply back when I
asked what a better sampling frequency might be.
No, I don't agree--the pulse that comes from the drive is used as input
to an edge-triggered T-type flip-flop; the pulse width itself is
irrelevant--only the time between pulses.
Edit: I should probably say that a T-edge-triggered FF will get you the
original DC signal applied to the write head. You could also trigger on
the leading edge of each pulse. The point is that the width of the
pulse has no particular significance.
--Chuck
4:29 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: 03 November 2013 23:14
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
On 11/03/2013 02:12 PM, Robert Jarratt wrote:
an
So, according to the manual I have, the data rate
is 5megabits/sec.
But, the pulse width that you need to detect (and generate) is 50ns,
requiring the signal to be sampled at 25ns intervals, or 40MHz.
Someone suggested to me that even 40MHz may not be enough, but I
have
not had a reply back when I asked what a better
sampling frequency might
be.
No, I don't agree--the pulse that comes from the drive is used as input to edge-triggered T-type flip-flop; the pulse width
itself is
irrelevant--only the
time between pulses.
Edit: I should probably say that a T-edge-triggered FF will get you the
original
DC signal applied to the write head. You could also
trigger on the
leading
edge of each pulse. The point is that the width of
the pulse has no
particular
significance.
--Chuck
I am going to have re-learn all that stuff I learned 30 years ago all over
again. I had completely forgotten about edge-triggered flip flops.
Thanks
Rob
2:37 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: 03 November 2013 16:50
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
Stupid question, but relevant:
Are you simply after an ND emulation for a limited number of platforms?
If so, it might be far simpler to program each platform specifically.
This is the way it's done with the inexpensive Chinese floppy emulators
and
they work quite well for their purpose. One popular
one uses a STM32 ARM
and little else. The larger benefit is that the flash drive used to hold
the data
in its native form (i.e. not MFM pulses).
One variation I've seen even uses a USB connection to change the program.
I'm guessing that the primary consumer of this device will be the DEC
community. The personal computer community has had various devices
(such as IDE or flash drive) as replacements.
--Chuck
Sorry if I am being dumb, but what does ND stand for?
Regards
Rob
3:21 p.m.
On 03/11/2013 22:37, Robert Jarratt wrote:
Did they mean HD?
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: 03 November 2013 16:50
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
Stupid question, but relevant:
Are you simply after an ND emulation for a limited number of platforms?
If so, it might be far simpler to program each platform specifically.
This is the way it's done with the inexpensive Chinese floppy emulators
and
they work quite well for their purpose. One
popular one uses a STM32 ARM
and little else. The larger benefit is that the flash drive used to hold
the
data
in its native form (i.e. not MFM pulses).
One variation I've seen even uses a USB connection to change the program.
I'm guessing that the primary consumer of this device will be the DEC
community. The personal computer community has had various devices
(such as IDE or flash drive) as replacements.
--Chuck
Sorry if I am being dumb, but what does ND stand for? Regards
Rob
2 Nov
2 Nov
10:59 a.m.
On Sat, Nov 02, 2013 at 05:25:05PM -0000, Robert Jarratt wrote:
I have been mulling a project to emulate MFM disks (DEC
RD53 and RD54 in
particular) at the disk-to-controller interface.
You're part of a long tradition of mulling!
Looking for recommendations for a suitable
microcontroller that does not
cost the earth ...
I never miss a chance to gush about the XMOS XS-1 chips. They're great
for this kind of thing -- once you're down into things that happen a few
dozen ns apart you'll definitely want to use assembly language, but it's
not a bad architecture once you get over how C-centric it is. The main
down side is that XMOS is proud of their tiny packages so you'll need
paste solder. But oshpark.com is cheap and a toaster oven works nicely
for soldering. The chips themselves are mostly under US$20 and have a
very nice architecture for handling events. And they're hyperthreaded
in hardware so you can have one thread watch the RQDX3 side and another
handle the SD card and they both execute instructions no worse than once
every two clocks (if you're fully loaded at 8 threads -- faster if not),
so it's easy to keep up w/o driving yourself crazy.
Someone (was it Emanuel maybe?) suggested doing the emulation at the
level of the HD controller chip (I forget, is it an SMC part?) on the
RQDX3 board. Assuming you can find the data sheet, doing a register-level
emulation might *really* loosen up the timing quite a lot (hundreds of
nanoseconds to respond). Plus then you'd be dealing with cooked bytes
instead of raw flux transitions so you might be able to put something
more useful on your SD card (like plain old .DSK files, so it'd be easy
to insert/extract files with the SD card plugged into another computer
w/o having to hack the low-level format).
John Wilson
D Bit
1:17 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of John Wilson
Sent: 02 November 2013 17:59
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
On Sat, Nov 02, 2013 at 05:25:05PM -0000, Robert Jarratt wrote:
:-)
I have been mulling a project to emulate MFM disks
(DEC RD53 and RD54
in
particular) at the disk-to-controller interface.
You're part of a long tradition of mulling! Looking for recommendations for a suitable
microcontroller that does
not cost the earth ...
I never miss a chance to gush about the XMOS XS-1 chips. They're great this kind of thing -- once you're down into things
that happen a few dozen
ns
apart you'll definitely want to use assembly
language, but it's not a bad
architecture once you get over how C-centric it is. The main down side is
that
XMOS is proud of their tiny packages so you'll
need paste solder. But
oshpark.com is cheap and a toaster oven works nicely for soldering. The
chips themselves are mostly under US$20 and have a very nice architecture
for handling events. And they're hyperthreaded in hardware so you can
have one thread watch the RQDX3 side and another handle the SD card and
they both execute instructions no worse than once every two clocks (if
you're fully loaded at 8 threads -- faster if not), so it's easy to keep
up
w/o
driving yourself crazy.
I had a look and it seems close to what I would need, but possibly not
quite. It says it will do 400mips, which for a sampling frequency of 40MhZ
would give me 10 instructions per sample (crude assumption I know), but it
is not clear to me if each core does 400mips, or if that is 400mips
aggregated across 8 cores (which seems more likely), which would give my
just 1 instructions per sample. Do you know which it is?
There is a nice little affordable starter kit board, the XK-1A, which is
even available in the UK, but it doesn't have enough on board memory to
store a cylinder (which I now realise would need to be up to 500Kbytes per
cylinder if I am storing samples at 40Mhz, it could store a track though),
and I can't see any SD card addons on the xmos site, so I would have to
build all that. That may be a bit much for me.
Someone (was it Emanuel maybe?) suggested doing the emulation at the
level of the HD controller chip (I forget, is it an SMC part?) on the
RQDX3 board. Assuming you can find the data sheet, doing a register-level
emulation might *really* loosen up the timing quite a lot (hundreds of
nanoseconds to respond). Plus then you'd be dealing with cooked bytes
instead of raw flux transitions so you might be able to put something more
useful on your SD card (like plain old .DSK files, so it'd be easy to
insert/extract files with the SD card plugged into another computer w/o
having to hack the low-level format).
Yes, I have seen this suggestion. I don't really like it because I want my
RQDX3 to work "intact" and it is not very general for other controllers.
My thought was that if I can get this to work it wouldn't then be a big step
to modify it to work in the opposite direction and use it to image old disks
before they finally die.
Regards
Rob
2:13 p.m.
On Sat, Nov 02, 2013 at 08:17:47PM -0000, Robert Jarratt wrote:
I had a look and it seems close to what I would need,
but possibly not
quite. It says it will do 400mips, which for a sampling frequency of 40MhZ
would give me 10 instructions per sample (crude assumption I know), but it
is not clear to me if each core does 400mips, or if that is 400mips
aggregated across 8 cores (which seems more likely), which would give my
just 1 instructions per sample. Do you know which it is?
It's the second one, so I was picturing a little hardware help. If something
outside helps measure pulse lengths, shoveling those into the chip isn't so
bad, and then the receiver thread can hand off to a mark-detection thread or
whatever and keep the main code path short.
XMOS went insane about a year ago and replaced all the plain English on
their website with severe market-talk so you can't tell what anything really
is. The actual point is that on a 100 MHz clock, or maybe 125 MHz or
possibly 175 MHz with newer chips, the processor executes one instruction
from each of the next four threads in line, and then
moves them to the back
of the line (which is still the front of the line if
you're only using <= 4
threads).
There is a nice little affordable starter kit board,
the XK-1A, which is
even available in the UK,
You mean it's even available outside the UK. It's *from* the UK!
but it doesn't have enough on board memory to
store a cylinder (which I now realise would need to be up to 500Kbytes per
cylinder if I am storing samples at 40Mhz, it could store a track though),
The 64 KB limit can be a problem. OK sounds like not a good fit for this.
Sorry! I've been using them for reading floppies with all software and it's
worked great, so I was figuring a little hardware would bridge the gap to the
HD (5x faster than 2.88 MB FDs isn't *such* a huge jump with HW help, and if
you're the drive the timing can be a bit more approximate than a controller
which needs to write media that will still interchange).
My thought was that if I can get this to work it
wouldn't then be a big step
to modify it to work in the opposite direction and use it to image old disks
before they finally die.
Absolutely. A device that helps you start using itself will get used! Nice.
John Wilson
D Bit
5:03 p.m.
Why don't you guys just run the MFM signal through a shift in and shift out register.
Then you could read the input and write output data at a byte wide port level. Would cut
the interrupt rate way down and let you use a lesser MCU.
Sent from my iPhone 4S
5:31 p.m.
On 11/02/2013 05:03 PM, Alan Hightower wrote:
Why don't you guys just run the MFM signal through a shift in and
shift out register. Then you could read the input and write output
data at a byte wide port level. Would cut the interrupt rate way
down and let you use a lesser MCU.
What do you think ISP is? Just a shift register. The PIC32 even has
32-bit wide DMA from its SPI ports and lots of fast SRAM
onboard--128K-192K isn't unsual. Other than your non-volatile (e.g.
SDHC card) memory interface and the ST506 signal (differential and TTL),
an emulator should be pretty small in terms of real-estate. Many PIC32s
also have 5V-tolerant inputs.
Nowadays, there's not a lot of payoff in adding external logic to enable
use of a lesser MCU. I did a floppy emulator design using an AVR
ATMega, external SRAM and miscellaneous glue and the price for the BOM
came to *more* than a simple low-end ARM. Silicon is cheap.
--Chuck
6:07 p.m.
On Nov 2, 2013, at 17:13, John Wilson <wilson at dbit.com> wrote:
You could probably pair it with a small CPLD or FPGA to help
with the shifting (if, as Chuck pointed out, the SPI hardware won't
do the trick). That could add as little as $5 to your BOM, even in
single-unit quantities.
- Dave
On Sat, Nov 02, 2013 at 08:17:47PM -0000, Robert
Jarratt wrote:
I had a look and it seems close to what I would need, but possibly not
quite. It says it will do 400mips, which for a sampling frequency of 40MhZ
would give me 10 instructions per sample (crude assumption I know), but it
is not clear to me if each core does 400mips, or if that is 400mips
aggregated across 8 cores (which seems more likely), which would give my
just 1 instructions per sample. Do you know which it is?
It's the second one, so I was picturing a little hardware help. If something
outside helps measure pulse lengths, shoveling those into the chip isn't so
bad, and then the receiver thread can hand off to a mark-detection thread or
whatever and keep the main code path short.
XMOS went insane about a year ago and replaced all the plain English on
their website with severe market-talk so you can't tell what anything really
is. The actual point is that on a 100 MHz clock, or maybe 125 MHz or
possibly 175 MHz with newer chips, the processor executes one instruction
from each of the next four threads in line, and then moves them to the back
of the line (which is still the front of the line if you're only using <= 4
threads). 
3 Nov
3 Nov
2:36 a.m.
On 2013-11-02 18:59, John Wilson wrote:
Someone (was it Emanuel maybe?) suggested doing the
emulation at the
level of the HD controller chip (I forget, is it an SMC part?) on the
RQDX3 board.
I'm not sure I can take credit for it, but we talked about it so many
times ;-)
Assuming you can find the data sheet, doing a
register-level
emulation might *really* loosen up the timing quite a lot (hundreds of
nanoseconds to respond). Plus then you'd be dealing with cooked bytes
instead of raw flux transitions so you might be able to put something
more useful on your SD card (like plain old .DSK files, so it'd be easy
to insert/extract files with the SD card plugged into another computer
w/o having to hack the low-level format).
I still think it is the easiest approach, but I went away from it, as
there are to many different controllers out there. So the version which
stores the flux transitions should be the most general, and would help
on pretty much every system which used MFM/RLL drives ...
Cheers
1:05 a.m.
On Sat, 2 Nov 2013 17:25:05 -0000
"Robert Jarratt" <robert.jarratt at ntlworld.com> wrote:
I would need a development board that makes it easy to
interface to the SD
memory on one side and to the custom interfacing logic on the other side
Get a
Beaglebone Black:
http://beagleboard.org/Products/BeagleBone+Black
http://www.ti.com/tool/beaglebk
It gives you a 1GHz ARM Cortex-A8 based SOC, 512 MB RAM and 2 GB eMMC
for 45 US$ / 45,- EUR. It has Ethernet, USB host and device, HDMI, a
MicroSD slot and lots of GPIOs, UARTs, I2C, SPI, ... on a easy to
access connector.
It comes with Linux preinstaled. Of course you can skip The Penguin and
run your own code on the bare metal. You can implement your stuff as a
Linux kernel driver. Thats what I recommend. Using Linux as a host will
give you drivers for the other hardware for free. (SD card controler,
filesystem for SD storage, ...) Or you can build your stuff as a module
for the UBoot / barebox boot loader. This will get you closer to the
hardware, but still provide convenient access to things like the SD card
and file system drivers.
If you want a FPGA consider the ZedBoard. It is much more expensive
(starting at 199 US$) but will give you a dual core Cortex-A9 and a
FPGA on one chip.
http://www.zedboard.org/
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
3:06 a.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Jochen Kunz
Sent: 03 November 2013 08:05
To: cctalk at classiccmp.org
Subject: Re: Looking for a MicroController Recommedation
On Sat, 2 Nov 2013 17:25:05 -0000
"Robert Jarratt" <robert.jarratt at ntlworld.com> wrote:
MicroSD
I would need a development board that makes it
easy to interface to
the SD memory on one side and to the custom interfacing logic on the
other side
Get a Beaglebone Black:
http://beagleboard.org/Products/BeagleBone+Black
http://www.ti.com/tool/beaglebk
It gives you a 1GHz ARM Cortex-A8 based SOC, 512 MB RAM and 2 GB eMMC
for 45 US$ / 45,- EUR. It has Ethernet, USB host and device, HDMI, a slot and lots of GPIOs, UARTs, I2C, SPI, ... on a easy
to access
connector.
It comes with Linux preinstaled. Of course you can
skip The Penguin and
run
your own code on the bare metal. You can implement
your stuff as a Linux
kernel driver. Thats what I recommend. Using Linux as a host will give you
drivers for the other hardware for free. (SD card controler, filesystem
for SD
storage, ...) Or you can build your stuff as a module
for the UBoot /
barebox
boot loader. This will get you closer to the hardware,
but still provide
convenient access to things like the SD card and file system drivers.
I have not written a driver before, that is a possibility but I feel that
bare metal is probably the way to go.
one chip.
http://www.zedboard.org/
That is too expensive :-(
Regards
Rob
5:10 a.m.
On Sun, 3 Nov 2013 11:06:39 -0000
"Robert Jarratt" <robert.jarratt at ntlworld.com> wrote:
I wonder if bare metal access to GPIO on the
beaglebone would be any better
than the Raspberry Pi? I have had a quick look at the docs and I can't find
anything about the speed of GPIO. I found one post which suggests you can
achieve 1.5MHz
Just using GPIOs is the wrong aproach anyway, IMHO. You really want
some hardware to preprocess the signals somewhat. Also keep in mind
that those ARM SOCs as used on the RPi or Beaglebone Black have some
rather sophisticated DMA capable SPI, PWM, ... peripherals. You did
somthing wrong when you didn't get faster then 6 ms.
BTW: Microchip has some PICs with a build in "Configurable Logic Cell".
AFAIK that is somthing similar to a GAL / CPLD. Probably enough to do
the (de)serializing of the bitstream. Then the PIC could hand over the
data via some DMA capable interface to a Beaglebone Black that cares
about storing it on its SD card...
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
5:36 a.m.
On Nov 3, 2013, at 8:10, Jochen Kunz <jkunz at unixag-kl.fh-kl.de> wrote:
Just using GPIOs is the wrong aproach anyway, IMHO. You really want
some hardware to preprocess the signals somewhat. Also keep in mind
that those ARM SOCs as used on the RPi or Beaglebone Black have some
rather sophisticated DMA capable SPI, PWM, ... peripherals. You did
somthing wrong when you didn't get faster then 6 ms.
It was probably due to the overhead of the Linux GPIO layer.
BTW: Microchip has some PICs with a build in
"Configurable Logic Cell".
AFAIK that is somthing similar to a GAL / CPLD. Probably enough to do
the (de)serializing of the bitstream. Then the PIC could hand over the
data via some DMA capable interface to a Beaglebone Black that cares
about storing it on its SD card...
I think the biggest advantage of an FPGA/CPLD handling the bit
stream is in handling any write precomp effects. That's an example
of something that's really unpleasant to do in software, but trivial to do
at a bit-serial level in hardware.
I wouldn't try to decode much in hardware, since there are a number
of different encoding schemes (IIRC). Storing the raw bitstream (possibly
after undoing write precomp) is probably a good way to go.
- Dave
5:30 a.m.
On Nov 3, 2013, at 6:06, "Robert Jarratt" <robert.jarratt at ntlworld.com>
wrote:
The new batch of SoC FPGAs from Alter and Xilinx are really quite
compelling, and I have a few projects in mind for them if I ever get the
time and money. You don't need the performance they give you for
this, though; it's like putting a Mustang engine in a golf cart.
I would recommend a small FPGA coupled with a small micro that
has a parallel bus available (or very fast SPI). You can push the
cylinder data to the FPGA for replay during your "seek" time and write out
the contents of the current track at the start of the seek time (a very
simple write-back cache). I'd recommend the STM32F4DISCOVERY
board, because it's cheap and I'm rather fond of it, but it doesn't
have an SD connector. There are lots of third-party breakout boards
you could use to attach one, e.g. from AdaFruit or SparkFun.
Add a DE0-Nano for the FPGA and you're set.
As you mentioned, you'll need a level converter because no one speaks
5v anymore. That's also pretty easy to overcome; try some of the '244
and '245 variants from the 74LVC family. They're very cheap.
- Dave
Yes, I was looking at this and I have to say it does
look promising. I then
realised that I already have a Raspberry Pi, so I had a quick go at some
bare metal programming on it, but the sampling rate I got on the GPIO pins
was woeful. I wrote a program just to turn one of the GPIO pins on and off
as fast as possible, but only seemed to get a pulse period of 6ms, which is
5 or 6 orders of magnitude too slow. At that rate even if I use a shift
register externally it would be way too slow. I could have been doing
something wrong, has anyone else ever tried this?
Well, running through Linux's GPIO layer is going to be pretty slow.
Linux in General is MASSIVE overkill for this, and I think directly
manipulating GPIO in general (even on bare metal) is going to be
problematic and slow. With a fast enough CPU (or at least some
good DMA magic), you might be able to make SPI do the trick.
I wonder if bare metal access to GPIO on the
beaglebone would be any better
than the Raspberry Pi? I have had a quick look at the docs and I can't find
anything about the speed of GPIO. I found one post which suggests you can
achieve 1.5MHz
(http://www.supermicros.org/1/post/2013/07/beaglebone-gpio-musings.html). If
that is right then a shift register would be needed, but wider than 8 bits I
think.
GPIO in general is probably going to be too slow. I'd definitely
recommend some sort of shift register, whether it's SPI or something
in external custom logic. GPIO should be fine for control pins.
The beaglebone SPI support looks like it might be an
alternative. Although I
am not clear how fast this can go and whether I could get the timing to be
accurate enough. I would need to build some custom hardware that sends data
to/from the SPI interface on the beaglebone. That might not be too bad, but
I don't really know what is involved at the moment, probably an FPGA to make
prototyping easy.
Well, SPI is just a shift register, and you have a rich set of PLLs on
modern micros to drive the clocking. You might not have enough flex
in the divider ratios to make the timing exact with the crystals
on the board, but I'm not familiar enough with the drives in question
to say what that would require. My assumption, since MFM is self-
clocking, is that you don't need an exact frequency so much as a
consistent, low-jitter clock. Is that correct?
I have not written a driver before, that is a
possibility but I feel that
bare metal is probably the way to go.
I agree. Linux adds a ridiculous amount of overhead to this. It
does, of course, give you a software base with a file system and
drivers for things like the SD card, but you're still killing flies with
orbital bombardment.
If you want a
FPGA consider the ZedBoard. It is much more expensive
(starting at 199 US$) but will give you a dual core Cortex-A9 and a FPGA
on
one chip.
http://www.zedboard.org/
That is too expensive :-(
5:53 a.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of David Riley
Sent: 03 November 2013 13:31
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
On Nov 3, 2013, at 6:06, "Robert Jarratt" <robert.jarratt at
ntlworld.com>
wrote:
manipulating
Yes, I was looking at this and I have to say it
does look promising. I
then realised that I already have a Raspberry Pi, so I had a quick go
at some bare metal programming on it, but the sampling rate I got on
the GPIO pins was woeful. I wrote a program just to turn one of the
GPIO pins on and off as fast as possible, but only seemed to get a
pulse period of 6ms, which is
5 or 6 orders of magnitude too slow. At that rate even if I use a
shift register externally it would be way too slow. I could have been
doing something wrong, has anyone else ever tried this?
Well, running through Linux's GPIO layer is going to be pretty slow.
Linux in General is MASSIVE overkill for this, and I think directly GPIO in general (even on bare metal) is going to be
problematic and slow.
With a fast enough CPU (or at least some good DMA magic), you might be
able to make SPI do the trick.
Looks like you missed the bit where I said I did this using bare metal, no
Linux involved at all. So bare metal on the Pi, I could only achieve a
period of 6ms using GPIO. I know the BeagleBone Black has SPI, so I may be
able to do it with that. Looks like Raspberry Pi also has SPI, I will
experiment with that a bit later today.
I wonder if bare metal access to GPIO on the
beaglebone would be any
better than the Raspberry Pi? I have had a quick look at the docs and
I can't find anything about the speed of GPIO. I found one post which
suggests you can achieve 1.5MHz
(http://www.supermicros.org/1/post/2013/07/beaglebone-gpio-
musings.htm
l). If that is right then a shift register would
be needed, but wider
than 8 bits I think.
GPIO in general is probably going to be too slow. I'd definitely recommend
some sort of shift register, whether it's SPI or something in external logic. GPIO should be fine for control pins.
modern
The beaglebone SPI support looks like it might be
an alternative.
Although I am not clear how fast this can go and whether I could get
the timing to be accurate enough. I would need to build some custom
hardware that sends data to/from the SPI interface on the beaglebone.
That might not be too bad, but I don't really know what is involved at
the moment, probably an FPGA to make prototyping easy.
Well, SPI is just a shift register, and you have a rich set of PLLs on micros to drive the clocking. You might not have
enough flex in the
divider
ratios to make the timing exact with the crystals on
the board, but I'm
not
familiar enough with the drives in question to say
what that would
require.
My assumption, since MFM is self- clocking, is that
you don't need an
exact
frequency so much as a consistent, low-jitter clock.
Is that correct?
You may well be right. I am concerned about delays when switching the data
in the shift register from one byte to the next that could cause
inconsistent timing.
I have not written a driver before, that is a
possibility but I feel
that bare metal is probably the way to go.
I agree. Linux adds a ridiculous amount of overhead to this. It does, of
course, give you a software base with a file system and drivers for things the SD card, but you're still killing flies with
orbital bombardment.
The new batch of SoC FPGAs from Alter and Xilinx are really quite
compelling,
If you
want a FPGA consider the ZedBoard. It is much more expensive
(starting at 199 US$) but will give you a dual core Cortex-A9 and a
FPGA
on
one chip.
http://www.zedboard.org/
That is too expensive :-( and I have a few projects in mind for them if I ever
get the time and
money.
You don't need the performance they give you for
this, though; it's like
putting a Mustang engine in a golf cart.
I would recommend a small FPGA coupled with a small micro that has a
parallel bus available (or very fast SPI). You can push the cylinder data
to the
FPGA for replay during your "seek" time and
write out the contents of the
current track at the start of the seek time (a very simple write-back
cache).
I'd recommend the STM32F4DISCOVERY board, because
it's cheap and I'm
rather fond of it, but it doesn't have an SD connector. There are lots of
third-
party breakout boards you could use to attach one,
e.g. from AdaFruit or
SparkFun.
Add a DE0-Nano for the FPGA and you're set.
As you mentioned, you'll need a level converter because no one speaks 5v
anymore. That's also pretty easy to overcome; try some of the '244 and
'245
variants from the 74LVC family. They're very
cheap.
Thanks for those suggestions, I will take a look.
Regards
Rob
7:19 a.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Steven Hirsch
Sent: 03 November 2013 14:21
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Looking for a MicroController Recommedation
Wouldn't it be possible to use Discferret for this application?
--
I had thought this was for floppies only, but prompted by your email I went
to check. It would seem capable of handling MFM, but I am not at all clear
on what you would need to do to make it emulate the disks I am interested
in. I will ask.
Regards
Rob
9:45 a.m.
On Sun, 3 Nov 2013, Robert Jarratt wrote:
> Wouldn't it be possible to use Discferret for
this application?
I had thought this was for floppies only, but prompted
by your email I went
to check. It would seem capable of handling MFM, but I am not at all clear
on what you would need to do to make it emulate the disks I am interested
in. I will ask.
Discferret was originally conceived to read MFM hard disks. Not sure if
there's a path to emulating one, but Philip should be able to tell you
straight out.
--
10 Nov
10 Nov
1:51 a.m.
As you mentioned, you'll need a level converter
because no one speaks 5v
anymore. That's also pretty easy to overcome; try some of the '244 and
'245
variants from the 74LVC family. They're very
cheap.
I have had a look at the datasheets for the 74LVC244 and 74LVC245 and,
although I can see how to use them to convert from 5V to 3.3V, I am not sure
I understand how to use them for the opposite conversion from 3.3V to 5V.
The datasheet (http://www.farnell.com/datasheets/1635559.pdf) for the 245
does include the statement "5-V Input/Output Voltage With 3.3-V Vcc ", but I
can't see how the device "knows" the output is 5V or 3.3V.
Also, and here my lack of electronic design knowledge shows through, it says
"OE should be tied to VCC through a pullup resistor; the minimum value of
the resistor is determined by the current-sinking capability of the driver".
I have no idea how to determine the "current-sinking capability of the
driver" so don't know how to calculate the value of the resistor.
Any advice appreciated.
Thanks
Rob
3:05 a.m.
[...] although I can see how to use them to convert
from 5V to 3.3V,
I am not sure I understand how to use them for the opposite
conversion from 3.3V to 5V.
Depending on what you're driving with them, this "conversion" may be a
no-op. AIUI 3.3V outputs normally swing rail-to-rail, and 3.3V is well
above the TTL "high" input threshold, so you can just feed a 3.3V
output directly to a TTL input, provided they share GND.
While I daresay there are exceptions (I know of none, but I'd be
surprised if there weren't), I imagine most 5V logic families stay
reasonably close to TTL's input thresholds and thus work equally well
with null conversion here. I'm sure someone will correct me if this
guess is wrong....
I have no idea how to determine the
"current-sinking capability of
the driver"
Perhaps I've just misunderstood something, but I would expect to find
this on its datasheet.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:34 p.m.
On Sun, Nov 10, 2013 at 06:05:40AM -0500, Mouse wrote:
Depending on what you're driving with them, this
"conversion" may be a
no-op. AIUI 3.3V outputs normally swing rail-to-rail, and 3.3V is well
above the TTL "high" input threshold, so you can just feed a 3.3V
output directly to a TTL input, provided they share GND.
Yes -- I've had fine luck talking to 74LS using 74LVC parts (which are
impossibly wonderful -- cheap, low power, familiar pinouts, and wicked fast).
The only danger is that the rail-to-rail thing becomes much less true with
loading ... so ... don't load it! I.e. keep fanout (of outputs to 74LS)
to a minimum and everything will be groovy.
John Wilson
D Bit
8:39 p.m.
New subject: My Micro problems
I'm working on a project of reuse of uPs. With all the talk of
uPs for different things I thought I'd tell my story.
I've located a number of nice stepper motors and controllers.
These have L298 H-bridge and L297 stepper chips.
It is run by a 68HC711E9 chips.
I look this up and it is a neat processor. All kinds of timer
functions and such.
First problem is that most of these are OTP ( One Time Programmable ).
I can live with that but the part is also obsolete. Well
to cut part way to the end, I've found some un-programmed parts to work
with and one windowed device.
Along the way to find good ones, I thought I'd try the china chips.
It was not a good idea as I thought. These were all previously programmed.
Not exactly what I was looking for.
I considered these chips to be worthless for my project ( 4 of these
controllers ).
Oh, I should mention, the controllers were originally intended for controlling
valves. The firmware was only designed to stop in 12 positions ( out of 400
possible for the stepper motor ). This means, even if I setup a program to
talk to the original code is not useful.
Now back to the used ones I got. I figured, maybe there is a way to use
them. A careful check shows that they'd only used 4K of the 12K available.
Now all I need to do is find a way to get it to boot my code instead of
the original.
Scanning the first bytes, I found 3 0FF's in a row. Just enough to put
a JMP instruction. It is only 1A hex from the original reset code.
The OTP part can be programmed from 1 to 0 so I can reprogram
this part. I figure for less than 10 clocks, I can jump into unused OTProm.
The interrupt vectors are a little tougher but by the time I need
them, I should be able to put vectors in the RAM with low number addresses
that I can setup the vectors too. As long as 8K is enough for my code,
I can work around a partly used part. I've still got code to write but I can now
play with these and not worry as much about new revs to fix any bugs.
Dwight
8:50 p.m.
New subject: My Micro problems
On 11/10/2013 10:39 PM, dwight elvey wrote:
I'm working on a project of reuse of uPs. With all
the talk of
uPs for different things I thought I'd tell my story.
I've located a number of nice stepper motors and controllers.
These have L298 H-bridge and L297 stepper chips.
It is run by a 68HC711E9 chips.
I look this up and it is a neat processor. All kinds of timer
functions and such.
First problem is that most of these are OTP ( One Time Programmable ).
I can live with that but the part is also obsolete. Well
to cut part way to the end, I've found some un-programmed parts to work
with and one windowed device.
Along the way to find good ones, I thought I'd try the china chips.
It was not a good idea as I thought. These were all previously programmed.
Not exactly what I was looking for.
I considered these chips to be worthless for my project ( 4 of these
controllers ).
Oh, I should mention, the controllers were originally intended for controlling
valves. The firmware was only designed to stop in 12 positions ( out of 400
possible for the stepper motor ). This means, even if I setup a program to
talk to the original code is not useful.
Now back to the used ones I got. I figured, maybe there is a way to use
them. A careful check shows that they'd only used 4K of the 12K available.
Now all I need to do is find a way to get it to boot my code instead of
the original.
Scanning the first bytes, I found 3 0FF's in a row. Just enough to put
a JMP instruction. It is only 1A hex from the original reset code.
The OTP part can be programmed from 1 to 0 so I can reprogram
this part. I figure for less than 10 clocks, I can jump into unused OTProm.
The interrupt vectors are a little tougher but by the time I need
them, I should be able to put vectors in the RAM with low number addresses
that I can setup the vectors too. As long as 8K is enough for my code,
I can work around a partly used part. I've still got code to write but I can now
play with these and not worry as much about new revs to fix any bugs.
Dwight
Have fun....
But, I have before me 5 68HC711E9 parts, with quartz windows.
They are from long ago when I did HC11 development. I have long ago
sold the EVB and EVM, but these remain (along with 268HC24 port
replicators and a couple E2s and an A1 MCU
I need them no longer. Any interest?
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
1:16 p.m.
On 2013 Nov 10, at 1:51 AM, Robert Jarratt wrote:
Some general issues about level conversion are presented here (this
doc may have been mentioned on the list in the past):
http://www.newark.com/pdfs/techarticles/microchip/
3_3vto5vAnalogTipsnTricksBrchr.pdf
Sometimes you don't need anything (other than a bare wire) for the
3.3->5V direction.
As an example, I'm working with an RPi right now and driving TTL
directly from RPi GPIO outputs. (In the other direction I worked the
design so there only one 5->3.3 conversion needed, and just used 5
diodes in series (a tad ugly, but it was what was on hand) as a clamp
with a current limiting resistor. Might not be too great for high
speed.)
As you
mentioned, you'll need a level converter because no one
speaks 5v
anymore. That's also pretty easy to overcome; try some of the '244
and
'245
variants from the 74LVC family. They're very
cheap.
I have had a look at the datasheets for the 74LVC244 and 74LVC245 and,
although I can see how to use them to convert from 5V to 3.3V, I am
not sure
I understand how to use them for the opposite conversion from 3.3V
to 5V.
The datasheet (http://www.farnell.com/datasheets/1635559.pdf) for
the 245
does include the statement "5-V Input/Output Voltage With 3.3-V Vcc
", but I
can't see how the device "knows" the output is 5V or 3.3V. Also, and here my lack of electronic design knowledge
shows
through, it says
"OE should be tied to VCC through a pullup resistor; the minimum
value of
the resistor is determined by the current-sinking capability of the
driver".
I have no idea how to determine the "current-sinking capability of the
driver" so don't know how to calculate the value of the resistor.
They're referring here to the output (from somewhere else in the
system) which may be driving the nOE control input of the 244/45. The
idea is to help ensure the 244/45 outputs are disabled (nOE=high/V+)
until the system has stabilised during power-up (and down), so you
don't get multiple outputs on the same line driving it in opposite
states with a resultant low-impedance path between V+ and GND.
It's probably not an issue if you're only using the 244/45 in one
direction (DIR input is fixed), on the other hand if you don't need
the bidirectional capability it's arguably preferable to use unidir
converters.
3 Nov
3 Nov
2:32 a.m.
On 2013-11-02 18:25, Robert Jarratt wrote:
I have been mulling a project to emulate MFM disks
(DEC RD53 and RD54 in
particular) at the disk-to-controller interface. Before anyone asks, I don't
want to interface to Qbus (or any other bus) because I want to emulate the
least possible hardware and keep my RQDX3 cards working. And yes, I know
this has been talked about many times before, but I want to actually start
trying this out.
Pops up every year. Reoccurring subject. And a lot has been written about it
on this very list. So just check the archives ...
I'm not innocent either ;-)
I made myself more than two designs already, but never had the time
to write the software for it, or even finish it. At the end, the job
came in between :(
My idea is to use some kind of MicroController,
talking to specific
interfacing logic that drives the lines, and using SD memory for the actual
storage. I am considering two approaches:
[..]
What I tried was to simply record the signal from the drive controller,
and play it back. Like a digital version of analog tape.
some remarks to it, 40 MHz is probably not enough. So you need a nice
controller which can also handle the 4-bit mode of the sd-flashes.
check the write-precompensation chapters on disk drives. Some headaches
are hiding there.
think about buffering a cylinder, so you need some memory.
My last approach to it, was an FPGA which contains the shift register,
has local memory. The supervisor on the side is a stm32f4, which handles
the upload of FPGA, and storing the data on the sd-flash.
Just my .0005 cents ;-)
Cheers,
3:15 a.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of emanuel stiebler
Sent: 03 November 2013 10:33
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
On 2013-11-02 18:25, Robert Jarratt wrote:
it
I have been mulling a project to emulate MFM
disks (DEC RD53 and RD54
in
particular) at the disk-to-controller interface. Before anyone asks, I
don't want to interface to Qbus (or any other bus) because I want to
emulate the least possible hardware and keep my RQDX3 cards working.
And yes, I know this has been talked about many times before, but I
want to actually start trying this out.
Pops up every year. Reoccurring subject. And a lot has been written about
on this very list. So just check the archives ...
I'm not innocent either ;-)
I made myself more than two designs already, but never had the time to
write the software for it, or even finish it. At the end, the job came in
between :(
and
My idea is to use some kind of MicroController,
talking to specific
interfacing logic that drives the lines, and using SD memory for the
actual storage. I am considering two approaches:
[..]
What I tried was to simply record the signal from the drive controller, play it back. Like a digital version of analog tape.
some remarks to it, 40 MHz is probably not enough. So you need a nice
controller which can also handle the 4-bit mode of the sd-flashes.
What frequency do you think is needed? According to the RD53 manual the
pulse width is 50ns.
check the write-precompensation chapters on disk drives. Some headaches
are hiding there.
Thanks I will check this.
think about buffering a cylinder, so you need some memory.
Yes, that is my thinking, to store a whole cylinder in memory and indeed to
record/playback the flux transitions as that is the most general thing to
do.
My last approach to it, was an FPGA which contains the shift register, has
local memory. The supervisor on the side is a stm32f4, which handles the
upload of FPGA, and storing the data on the sd-flash.
Indeed, it is looking like some kind of microcontroller talking to custom
logic is what will be needed. As per another reply a BeagleBone Black might
be a good controller. Not sure on the FPGA front, but Reinhard Heugerger is
using a DE0-Nano. The annoyance is that the BeagleBone uses 3.3V, ST-506 is
5V and the DE0-Nano is 3.3V, so some level conversion somewhere would be
needed.
Just my .0005 cents ;-)
Cheers,
7:59 a.m.
On 11/3/2013 3:32 AM, emanuel stiebler wrote:
On 2013-11-02 18:25, Robert Jarratt wrote:
An SDHC card will transfer data at 25 Mbps in single-bit SPI mode
although I've only done it at 12.5 Mbps.
FYI - If you haven't found it yet, the SD Card Specification (and
protocol) is available from:
https://www.sdcard.org/downloads/pls/simplified_specs/
You're looking for "SD Specifications Part 1 Physical Layer
Simplified Specification" and the SPI mode interface is defined in
Section 7.
Rob.
I have been mulling a project to emulate MFM
disks (DEC RD53 and RD54 in
particular) at the disk-to-controller interface. Before anyone asks, I
don't
want to interface to Qbus (or any other bus) because I want to emulate
the
least possible hardware and keep my RQDX3 cards working. And yes, I know
this has been talked about many times before, but I want to actually
start
trying this out.
Pops up every year. Reoccurring subject. And a lot has been written
about it
on this very list. So just check the archives ...
I'm not innocent either ;-)
I made myself more than two designs already, but never had the time
to write the software for it, or even finish it. At the end, the job
came in between :(
My idea is to use some kind of MicroController,
talking to specific
interfacing logic that drives the lines, and using SD memory for the
actual
storage. I am considering two approaches:
[..]
What I tried was to simply record the signal from the drive controller,
and play it back. Like a digital version of analog tape.
some remarks to it, 40 MHz is probably not enough. So you need a nice
controller which can also handle the 4-bit mode of the sd-flashes.
check the write-precompensation chapters on disk drives. Some headaches
are hiding there.
think about buffering a cylinder, so you need some memory.
My last approach to it, was an FPGA which contains the shift register,
has local memory. The supervisor on the side is a stm32f4, which handles
the upload of FPGA, and storing the data on the sd-flash.
Just my .0005 cents ;-)
Cheers,
9:45 a.m.
On Sat, Nov 02, 2013 at 05:25:05PM -0000, Robert Jarratt wrote:
I have been mulling a project to emulate MFM disks
(DEC RD53 and RD54 in
particular) at the disk-to-controller interface. Before anyone asks, I don't
want to interface to Qbus (or any other bus) because I want to emulate the
least possible hardware and keep my RQDX3 cards working. And yes, I know
this has been talked about many times before, but I want to actually start
trying this out.
I was playing in the same area. I am using the beaglebone.
http://beagleboard.org/Products/BeagleBone+Black/
The PRU have a 200 MHz clock so you can measure the edge to 5 ns though
you can't respond to the next edge for a while depending on how many
instructions. I have the PRU writing the transition times to main memory
and the ARM doing the decoding. I was planning to make it a drive emulator
after getting reading working well.
I made by own cape to convert signals to proper level and drive. 4
chips wirewrapped.
I have it reading MFM disks. One disk I had around I get about twice as
many sectors with CRC errors as the labels says. The other disk has a
lot of errors. The rest of the disks don't go ready. Next was to hook
them up to the proper controller and see if the errors are real or my MFM
decoder needs more work.
Its been stalled for a little while since some DECtapes and LINCtapes came by
to be read before forwarding them on. I modified my cape to talk to my
TU56 (using the G888's in the drive) to read/write DECtapes & LINCtapes. That
now is working pretty well and the tapes are read so I may have some time
for this again.
I can put my stuff online if you think you wish to use the beaglebone. It
really needs some more time to clean it up.
10:20 a.m.
I'm amazed by how many folks independently come up with the same approaches after
mulling over things like this. Many of the ideas already bounced around in this thread are
very, very similar to what I've been mulling over myself.
Personally, I'd use an FPGA to do anything timing-sensitive. I'm probably biased
to think that way since I'm a hardware guy with FPGA experience, so it's just what
comes naturally to me. I've considered various things to give the FPGA some
intelligence, including STM32F series processors, Raspberry Pi boards, etc., but most
recently I settled on the idea of using a BeagleBone Black with my own FGPA-based board
sandwiched between it and a small LCD cape. My imaginary hardware would be applied towards
both interfacing to physical drives to copy vintage media and write downloaded images to
blank media, and replacing physical drives with a hardware emulation. In the latter case,
the LCD would provide a user interface for choosing media images and so forth.
I may or may not ever get around to beginning a never-to-be-finished project to implement
this, but it sounds like I'll have plenty of company either way!
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
3:39 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Mark J. Blair
Sent: 03 November 2013 18:20
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Looking for a MicroController Recommedation
I'm amazed by how many folks independently come up with the same
approaches after mulling over things like this. Many of the ideas already
bounced around in this thread are very, very similar to what I've been
mulling
over myself.
Personally, I'd use an FPGA to do anything timing-sensitive. I'm probably
biased to think that way since I'm a hardware guy with FPGA experience, so
it's just what comes naturally to me. I've considered various things to
give the
FPGA some intelligence, including STM32F series
processors, Raspberry Pi
boards, etc., but most recently I settled on the idea of using a
BeagleBone
Black with my own FGPA-based board sandwiched between
it and a small
LCD cape. My imaginary hardware would be applied towards both interfacing
to physical drives to copy vintage media and write downloaded images to
blank media, and replacing physical drives with a hardware emulation. In
the
latter case, the LCD would provide a user interface
for choosing media
images and so forth.
I may or may not ever get around to beginning a never-to-be-finished
project to implement this, but it sounds like I'll have plenty of company
either way!
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
BeagleBone is certainly looking like a good candidate. If I need to
supplement with a FPGA, what is the smallest/cheapest development board
option? DE0-Nano seems to be the cheapest I have found so far.
Regards
Rob
5:26 p.m.
On Nov 3, 2013, at 15:39 , Robert Jarratt <robert.jarratt at ntlworld.com> wrote:
BeagleBone is certainly looking like a good candidate.
If I need to
supplement with a FPGA, what is the smallest/cheapest development board
option? DE0-Nano seems to be the cheapest I have found so far.
I haven't looked into off the shelf dev boards much since I expected to make my own
PCB anyway. My first impulse is to try a Xilinx Spartan 6, out of force of habit. The
largest one available in a TQFP package costs around $15 at Digi-Key and has 64kx9 of
dual-ported RAM blocks if I recall correctly. I haven't thought things out far enough
to determine if the gate count is large enough.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
10 Nov
10 Nov
4:45 a.m.
On 11/3/13 8:26 PM, Mark J. Blair wrote:
On Nov 3, 2013, at 15:39 , Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
I'm on the same path. The "Mojo fpga" board is very cool and cheap.
I'm about to crank it into a few interface boards to see how it works.
The question for is whether or not the AVR <-> FPGA SPI interface is
fast enough to do disk & tape transfers over USB. I think the
limitation is the AVR's clock speed. It might be simplest to just put
a 4 wire MMC port off the FPGA and put a simple cpu inside the fpga to
do basic i/o work. Any simple core should do the job.
-brad
BeagleBone is certainly looking like a good
candidate. If I need to
supplement with a FPGA, what is the smallest/cheapest development board
option? DE0-Nano seems to be the cheapest I have found so far.
I haven't
looked into off the shelf dev boards much since I expected to make my own PCB anyway. My
first impulse is to try a Xilinx Spartan 6, out of force of habit. The largest one
available in a TQFP package costs around $15 at Digi-Key and has 64kx9 of dual-ported RAM
blocks if I recall correctly. I haven't thought things out far enough to determine if
the gate count is large enough.
3 Nov
3 Nov
3:37 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of David Gesswein
Sent: 03 November 2013 17:45
To: cctech at classiccmp.org
Subject: Re: Looking for a MicroController Recommedation
On Sat, Nov 02, 2013 at 05:25:05PM -0000, Robert Jarratt wrote:
and
I have been mulling a project to emulate MFM
disks (DEC RD53 and RD54
in
particular) at the disk-to-controller interface. Before anyone asks, I
don't want to interface to Qbus (or any other bus) because I want to
emulate the least possible hardware and keep my RQDX3 cards working.
And yes, I know this has been talked about many times before, but I
want to actually start trying this out.
I was playing in the same area. I am using the beaglebone.
http://beagleboard.org/Products/BeagleBone+Black/
The PRU have a 200 MHz clock so you can measure the edge to 5 ns though
you can't respond to the next edge for a while depending on how many
instructions. I have the PRU writing the transition times to main memory the ARM doing the decoding. I was planning to make it
a drive emulator
after
getting reading working well.
I made by own cape to convert signals to proper level and drive. 4 chips
wirewrapped.
I have it reading MFM disks. One disk I had around I get about twice as
many
sectors with CRC errors as the labels says. The other
disk has a lot of
errors.
The rest of the disks don't go ready. Next was to
hook them up to the
proper
controller and see if the errors are real or my MFM
decoder needs more
work.
Its been stalled for a little while since some DECtapes and LINCtapes came
by
to be read before forwarding them on. I modified my
cape to talk to my
TU56 (using the G888's in the drive) to read/write DECtapes & LINCtapes.
That now is working pretty well and the tapes are read so I may have some
time for this again.
I can put my stuff online if you think you wish to use the beaglebone. It
really
needs some more time to clean it up.
Hello David,
I am going to do a little bit more research, but this looks like a promising
avenue. If I do go down this route I may take you up on your offer to take
the stuff you have done so far, if that is OK.
Regards
Rob
3841
days inactive
3850
days old
47 comments
19 participants
participants (19)
-
aek＠bitsavers.org -
alan＠alanlee.org -
alexandre.tabajara＠gmail.com -
brad＠heeltoe.com -
brain＠jbrain.com -
cclist＠sydex.com -
dave.g4ugm＠gmail.com -
djg＠pdp8online.com -
dkelvey＠hotmail.com -
emu＠e-bbes.com -
fraveydank＠gmail.com -
hilpert＠cs.ubc.ca -
jkunz＠unixag-kl.fh-kl.de -
mouse＠Rodents-Montreal.ORG -
nf6x＠nf6x.net -
radioengr＠gmail.com -
robert.jarratt＠ntlworld.com -
snhirsch＠gmail.com -
wilson＠dbit.com