7 Sep
2013
7 Sep
'13
3:57 p.m.
Hello.
Unfortunately I don't have a RK05, even if I REALLY would to know
somebody in willing to sell one...
Anyway, I followed the former and the latter post about PLL to sync
12-sector cartridges as 16-sector,
but I have some question about how the circuit should work.
In the hardware sectoring, the pulses is needed to identify in precise
way the physical boundary between
one sector and the neightbors.
Clearly the 12-sectors will have 12 dents, while the 16 -sectors 16
dents.. plain.
Now I could take a signal coming from a 12-sectors cartridge sensor,
pass it through a
PLL and produce a signal with 16/12 times the frequency, that is
synchronized with the original
signal... could it work?
Maybe I missing something, but I think is not that easy...
In fact, you expect to produce 4 pulses every 3 pulses of the reference
signal.
As the 4/3 ratio is not an integer multiple, only 1 every 4 pulses will
be aligned with the hardware pulses,
thus we would have a phase uncertain of 1/3 of physical hardware sector.
Probably, if the cartridge is started and synchronized, it could
continue to work correctly until the
whole stuff is stopped and restarted. In this situation it could work in
33% of the cases,
being misaligned of 1/3 or 2/3 of sector in remaining cases..
To fix it all, there would be a way to generate a secondary pulse to
identify a particular dent.
In this way, the regenerated sectors would always synchronize to the
very same phase,
removing the phase uncertain...
Does it sound correct?
Andrea
7 Sep
7 Sep
5:55 p.m.
On 09/07/2013 12:57 PM, shadoooo wrote:
As the 4/3 ratio is not an integer multiple, only 1
every 4 pulses
will be aligned with the hardware pulses, thus we would have a phase
uncertain of 1/3 of physical hardware sector. Probably, if the
cartridge is started and synchronized, it could continue to work
correctly until the whole stuff is stopped and restarted. In this
situation it could work in 33% of the cases,
I think perhaps that you do not understand how a PLL really operates.
In every case that I've ever worked with, the PLL center frequency is a
multiple of the reference. (That, for example, is why having a 3GHz CPU
clock on your personal computer that the reference frequency is always
much lower than that 3GHz.
Basically, a PLL operates by comparing the *phase* of the reference
frequency with the PLL oscillator and correcting the PLL oscillator
(almost always a VCO) accordingly.
So, running a PLL at 4x the 12-sector frequency and dividing it by 3
will give you 16 sector timing that closely follows the speed variations
of the spindle motor.
Wikipedia has a good section on "Phas Locked Loop", including an example
of one coded in software.
--Chuck
8 Sep
8 Sep
1:15 p.m.
On Saturday (09/07/2013 at 03:44PM -0700), Al Kossow wrote:
On 9/7/13 12:57 PM, shadoooo wrote:
I think your micro has to be a little smart and isolate the index
pulse from all the others and become synchronous with it. Then it
can synthesize the 12- or 16- sector pulses by simple "dead reckoning"
timing after using the leading edge of the index pulse as the trigger.
The sector to sector duration will be one value but the sector to index
duration will be half of that and then you know you just found the
index mark.
The micro then generates an outbound index pulse and the 12- or 16-
synthetic sector pulses, the first of which comes sooner than the others,
and then goes back to finding the next inbound index pulse... rinse
lather repeat.
Use a decent stability crystal or oscillator (as opposed to some on die
RC osc) to clock your micro and you should have it.
I have done something very similar to emulate 10- and 16-hole hard-sector
floppies with 3.5" soft-sector media and it works very well.
http://sebhc.lesbird.com/storage/storage.html#HARD_SECTOR_FLOPPY_EMULATOR
Chris
--
Chris Elmquist
Clearly the 12-sectors will have 12 dents, while
the 16 -sectors 16 dents
Slots in the hub ring.
There are actually 13 and 17, one extra midway between the 12'th and 1'st for the
index. 
1:43 p.m.
On Sep 8, 2013, at 1:15 PM, Chris Elmquist <chrise at pobox.com> wrote:
On Saturday (09/07/2013 at 03:44PM -0700), Al Kossow
wrote:
That's actually not too far off from how digital TVs/monitors generate
the pixel clock from incoming sync lines; the assumption is that the
frequency of the pixel clock is an integer multiple of the horizontal
scan frequency (generally a safe assumption), so it multiplies the
horizontal scan up by the active pixels plus the effective blanking
pixels.
So just taking the index pulse time and dividing that time constant by
240, you'd have a time constant that could then be multiplied up by 15
(16-sector), 20 (12-sector) or even 10 (24-sector). Ideally, you'd go
for a multiplier of 480 instead, since it would let you get exactly
half a sector time off for the 16-sector case. Handy. You'd probably
need a higher-precision timer than most PICs offer, but it's been a
while since I've looked at the things they offer because I find them
to be rather distasteful, personally.
Either way, you could probably get it done with a very small amount of
code.
- Dave
On 9/7/13 12:57 PM, shadoooo wrote:
I think your micro has to be a little smart and isolate the index
pulse from all the others and become synchronous with it. Then it
can synthesize the 12- or 16- sector pulses by simple "dead reckoning"
timing after using the leading edge of the index pulse as the trigger.
The sector to sector duration will be one value but the sector to index
duration will be half of that and then you know you just found the
index mark.
The micro then generates an outbound index pulse and the 12- or 16-
synthetic sector pulses, the first of which comes sooner than the others,
and then goes back to finding the next inbound index pulse... rinse
lather repeat. Clearly the 12-sectors will have 12 dents, while
the 16 -sectors 16 dents
Slots in the hub ring.
There are actually 13 and 17, one extra midway between the 12'th and 1'st for the
index.
1:47 p.m.
On 09/08/2013 10:15 AM, Chris Elmquist wrote:
Use a decent stability crystal or oscillator (as opposed to some on die
RC osc) to clock your micro and you should have it.
I'm with Tony on this one, however. There's a "mystery" aspect to using
an MCU for this sort of thing (i.e., code, programming). Index can be
isolated from sector pulses with a simple one-shot (as is done on old 8"
drives with separate sector and index lines). The rest is a simple PLL
setup with a divider. Robust, contemporaneous with no mystery at all.
It could just as well have been designed and implemented in 1972 as today.
Note that no crystal is necessary for a PLL, as the sector pulses
themselves serve as the reference. I suspect that the "capture ratio"
would be quite large also and quite tolerant of long term speed variations.
If this were a modern device, then I'd probably go with an MCU.
FWIW,
Chuck
2:23 p.m.
On 9/8/13 10:47 AM, Chuck Guzis wrote:
I'm with Tony on this one, however. There's a
"mystery" aspect to using an MCU for this sort of thing (i.e., code,
programming). Index can be isolated from sector pulses with a simple one-shot (as is
done on old 8" drives with separate sector and index lines). The rest is a simple
PLL setup with a divider. Robust, contemporaneous with no mystery at all. It could just
as well have been designed
and implemented in 1972 as today.
example patent
3898690_Pertec
under pertec/patents
2:48 p.m.
It is possible to create non-integer ratios. They do have
to be rational ratios though. Still, it wouldn't take much code
to detect the index pulse and use that as a starting location
If one knew the actual sector pulse timing, one could use that
to correct a software DLL while it was rotating and not even have
to wait for a complete revolution.
As chuck says, this could be done with a simple PLL as well.
Not rocket science in either case.
For the H89 Heathkit, there is a simple uP board available
( or at least it was available ) to create sector pulses so one
could use a soft sector disk and drive with the H89 hard sectored
controller.
It's been done.
Dwight
Date: Sun, 8 Sep 2013 11:23:57 -0700
From: aek at bitsavers.org
To: cctalk at classiccmp.org
Subject: Re: Soft Sectoring a RK05
On 9/8/13 10:47 AM, Chuck Guzis wrote:
I'm with Tony on this one, however.
There's a "mystery" aspect to using an MCU for this sort of thing (i.e.,
code, programming). Index can be isolated from sector pulses with a simple one-shot (as
is
done on old 8" drives with separate sector and index lines). The rest is a simple
PLL setup with a divider. Robust, contemporaneous with no mystery at all. It could just
as well have been designed
and implemented in 1972 as today.
example patent
3898690_Pertec
under pertec/patents
2:34 p.m.
Hello.
Unfortunately I don't have a RK05, even if I REALLY would to know
somebody in willing to sell one...
Anyway, I followed the former and the latter post about PLL to sync
12-sector cartridges as 16-sector,
but I have some question about how the circuit should work.
In the hardware sectoring, the pulses is needed to identify in precise
way the physical boundary between
one sector and the neightbors.
Clearly the 12-sectors will have 12 dents, while the 16 -sectors 16
dents.. plain.
Now I could take a signal coming from a 12-sectors cartridge sensor,
pass it through a
PLL and produce a signal with 16/12 times the frequency, that is
synchronized with the original
signal... could it work?
Maybe I missing something, but I think is not that easy...
In fact, you expect to produce 4 pulses every 3 pulses of the reference
signal.
As the 4/3 ratio is not an integer multiple, only 1 every 4 pulses will
be aligned with the hardware pulses,
thus we would have a phase uncertain of 1/3 of physical hardware sector.
Probably, if the cartridge is started and synchronized, it could
continue to work correctly until the
whole stuff is stopped and restarted. In this situation it could work in
33% of the cases,
being misaligned of 1/3 or 2/3 of sector in remaining cases..
To fix it all, there would be a way to generate a secondary pulse to
identify a particular dent.
In this way, the regenerated sectors would always synchronize to the
very same phase,
removing the phase uncertain...
WHat you have to sassuem (and I think it is reasoanble) is tht the
rotational speed of the platter does not change during 1/4 of a
revolution (or even an entire revolution).
The disk has considerable inertia, so I think that it is goign to be a
cosntant speed.
At which point you basically do generate a signal 4/3rd the fequency of
the sector pulses and pahse lock it to every 3rd pulse (1/4 of a
revolution). Assuming that nothing drifts, the pulses produced by said
new signal are i nthe rignt places.
And thining about it, the accuracy does not have tbe be as good as you
might think. From waht I rememebr, each sector starts with a preamble and
ends wit ha postamble, which are essentally all 0's. Agains, IIRC <the
preamble ends with a '1' bit, this is a signal to the cotnroller to start
readign and decoding the header.
So if the sector pulse is a few bit-times off, it doesn't matter. The
controlelr will not see the 'right' number of 0's, but it doesn't count
them anyeway. I'll recgnise the '1' and start reading the header as normal.
-tony
6:33 p.m.
On 09/08/2013 11:34 AM, Tony Duell wrote:
So if the sector pulse is a few bit-times off, it
doesn't matter. The
controlelr will not see the 'right' number of 0's, but it doesn't count
them anyeway. I'll recgnise the '1' and start reading the header as normal.
Anent that, I once did a project that attempted to synthesize sector
pulses using soft-sector 5.25" media on old belt-driven drives (e.g.
Shugart SA400) that used very primitive speed controls. Since you had
only the index pulse to sync an entire rotation from, the speed
variations (particularly ISV) were entirely too large to do this
reliably. Direct-drive floppies (e.g. Teac FD55) were considerably
better, but a random sampling of various brands of 5.25" media pointed
up reliability to be less than ideal.
--Chuck
9 Sep
9 Sep
8:59 a.m.
On Sunday (09/08/2013 at 03:33PM -0700), Chuck Guzis wrote:
On 09/08/2013 11:34 AM, Tony Duell wrote:
Yup. But 3.5" drives and media are plenty stable and so my emulator
uses those and every email I get asking if someone can use the board
with a 5.25" drive gets a reply they weren't hoping for :-(
I can understand wanting to make something "period correct" for sure.
But I went for small size and ease of reproducability by multiple
different skill sets. My board has two DIPs on it and the code is maybe
100 lines of C on an ATMEL AVR. It installs between the drives and the
controller-- as a "bump" in the ribbon cable and it supports emulation
of two drives at the same time. I would think a similar approach could
be used for RK05... or, of course, you could build it inside the drive
or onto the controller itself.
Chris
--
Chris Elmquist
So if the sector pulse is a few bit-times off, it
doesn't matter. The
controlelr will not see the 'right' number of 0's, but it doesn't count
them anyeway. I'll recgnise the '1' and start reading the header as normal.
Anent that, I once did a project that attempted to synthesize sector
pulses using soft-sector 5.25" media on old belt-driven drives
(e.g. Shugart SA400) that used very primitive speed controls. Since
you had only the index pulse to sync an entire rotation from, the
speed variations (particularly ISV) were entirely too large to do
this reliably. Direct-drive floppies (e.g. Teac FD55) were
considerably better, but a random sampling of various brands of
5.25" media pointed up reliability to be less than ideal.
9:39 a.m.
Of course, a last way to deal with it would be to
soft sector that data on the disk and use a data
buffer between the disk and the computer.
You'd emulate the complete disk, sector marks and
data.
Dwight
Date: Mon, 9 Sep 2013 07:59:01 -0500
From: chrise at pobox.com
To: cctalk at classiccmp.org
Subject: Re: Soft Sectoring a RK05
On Sunday (09/08/2013 at 03:33PM -0700), Chuck Guzis wrote:
> On 09/08/2013 11:34 AM, Tony Duell wrote:
>
> >So if the sector pulse is a few bit-times off, it doesn't matter. The
> >controlelr will not see the 'right' number of 0's, but it
doesn't count
> >them anyeway. I'll recgnise the '1' and start reading the header as
normal.
>
---snip---
12:06 p.m.
On 09/09/2013 06:39 AM, dwight elvey wrote:
Of course, a last way to deal with it would be to
soft sector that data on the disk and use a data
buffer between the disk and the computer.
You'd emulate the complete disk, sector marks and
data.
Dwight
Another possibility would be to slightly modify the packs by painting
(using a stencil) 17 dots on the hub and using an optical pickup to
read them. Almost no hardware involved.
Just saying that there's definitely more than one way to skin a cat.
--Chuck
12:43 p.m.
Why no get someone to make new rings.
Could these be turned from a pipe size?
Dwight
Date: Mon, 9 Sep 2013 09:06:19 -0700
From: cclist at sydex.com
To:
Subject: Re: Soft Sectoring a RK05
On 09/09/2013 06:39 AM, dwight elvey wrote:
Of course, a last way to deal with it would be
to
soft sector that data on the disk and use a data
buffer between the disk and the computer.
You'd emulate the complete disk, sector marks and
data.
Dwight
Another possibility would be to slightly modify the packs by painting
(using a stencil) 17 dots on the hub and using an optical pickup to
read them. Almost no hardware involved.
Just saying that there's definitely more than one way to skin a cat.
--Chuck
1:06 p.m.
On Sep 9, 2013, at 9:43 AM, dwight elvey <dkelvey at hotmail.com> wrote:
Why no get someone to make new rings.
Could these be turned from a pipe size?
The problem isn't necessarily machining the rings. It'll be mounting
them so that they meet the concentricity requirements. I would also
suspect that some post mounting balancing would be required.
There may be a few folks on this list that have the capability to
perform the conversion but I doubt the average person on this list
would be able to accomplish this given a supply of rings.
I think the easiest thing would be as has been discussed here
to modify the drive. Ideally I would think that if you're using a
PLL to generate a 16 sector pack from a 12 sector pack, it should
also detect a 16 sector pack and just pass the pulses through
unmolested.
TTFN - Guy
Date: Mon, 9 Sep 2013 09:06:19 -0700
From: cclist at sydex.com
To:
Subject: Re: Soft Sectoring a RK05
On 09/09/2013 06:39 AM, dwight elvey wrote:
Of course, a last way to deal with it would be
to
soft sector that data on the disk and use a data
buffer between the disk and the computer.
You'd emulate the complete disk, sector marks and
data.
Dwight
Another possibility would be to slightly modify the packs by painting
(using a stencil) 17 dots on the hub and using an optical pickup to
read them. Almost no hardware involved.
Just saying that there's definitely more than one way to skin a cat.
--Chuck
1:16 p.m.
On Sep 9, 2013, at 1:06 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
I think the easiest thing would be as has been
discussed here
to modify the drive. Ideally I would think that if you're using a
PLL to generate a 16 sector pack from a 12 sector pack, it should
also detect a 16 sector pack and just pass the pulses through
unmolested.
Or, if it generates the pulses as described using a PLL based on
the index pulse, it should be generating the same pulses as the
rings (if not, you're doing something wrong).
- Dave
3:23 p.m.
I can understand wanting to make something
"period correct" for sure.
It's not jsut that, it could be easier to build and repair too...
But I went for small size and ease of reproducability by multiple
different skill sets. My board has two DIPs on it and the code is maybe
If you can solder well enough to fit 2 DIPs (and associated components, I
gurss), then you can solder 100 DIPs. It's the same skill.
And to assemble a PCB of TTL all you need is a soldering iron and solder.
100 lines of C on an ATMEL AVR. It installs between
the drives and the
But to built the AVR solution you need the C compiler, something that can
run the C compiler, the AVR programmer (or JTAG cable, perhaps), something
to run the software for that, etc. Rather more than just a soldering iron.
(which you need anyway to built the board with the AVR on it).
-tony
3:58 p.m.
On Mon, Sep 9, 2013 at 3:23 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
avr-gcc
100 lines of C
on an ATMEL AVR. It installs between the drives and the
But to built the AVR solution you need the C compiler something that can run the C compiler
I don't know the specific minimum specs for what can run avr-gcc, but
it's entirely within the ability of a Raspberry Pi, so an 800MHz 32-bit
CPU with 512MB of RAM is "enough". Don't know how far down (or
old) you can take it.
the AVR programmer (or JTAG cable, perhaps),
something
to run the software for that, etc.
You can build an ICSP cable that attaches to a PC parallel port,
or a different one (PonyProg) that attaches to a serial port, with
the right connector (DB25 or DE9) and some passives, or you
can spend $22 (plus some shipping), U.S. cost, for a USBtinyISP
that can also be used to load bootloaders or do bare-metal
programming on dozens of models of AVR MCU. The machine
that can run the C compiler can also run avrdude, so you don't
need a special machine or specific OS.
Rather more than just a soldering iron.
(which you need anyway to built the board with the AVR on it).
If you can read this message, it's likely that you already have
a computer that has a text editor to edit code and enough
resources to run the C compiler and the programmer. It's
*possible* to read this message without that, but it's
unlikely.
Anything can be made more difficult than it has to be. My
strawman can set fire to your strawman.
-ethan
4:29 p.m.
But I went for
small size and ease of reproducability by multiple
different skill sets. My board has two DIPs on it [...]
If you can solder well
enough to fit 2 DIPs (and associated
components, I gurss), then you can solder 100 DIPs. It's the same
skill. 100 lines of C
on an ATMEL AVR.
But to built the AVR solution you need the C compiler, something
that
can run the C compiler, the AVR programmer (or JTAG cable, perhaps),
something to run the software for that, etc.
4:43 p.m.
On Sep 9, 2013, at 1:29 PM, Mouse <mouse at rodents-montreal.org> wrote:
Yes and no.
It's the same basic skill. But someone who can pretty much mostly
solder OK but, let's say, creates a bad joint 1% of the time has a
pretty good chance of making the small board work first time, and
probably has a decent chance of finding and fixing the bad joint if
there's an issue.
True. But a lot of people already have much of that and don't mind
picking up the rest.
Different solutions for different people....
I also think that Tony's comparison is a bit bogus. If someone has put
together the design, it's likely the case that they'll also provide the binaries
or even pre-programmed parts. It's not unlike someone providing the raw
PCBs.
I think a more accurate description for Tony's comparison is that for the
100 DIP board, the person would only get the Gerber (and related) files and
they'd have to get the PCB built.
TTFN - Guy
But I went for small size and ease of reproducability
by multiple
different skill sets. My board has two DIPs on it [...]
If you can solder well
enough to fit 2 DIPs (and associated
components, I gurss), then you can solder 100 DIPs. It's the same
skill. 100 lines
of C on an ATMEL AVR.
But to built the AVR solution you need the C compiler,
something that
can run the C compiler, the AVR programmer (or JTAG cable, perhaps),
something to run the software for that, etc.
10 Sep
10 Sep
3:05 p.m.
I also think that Tony's comparison is a bit
bogus. If someone has put
together the design, it's likely the case that they'll also provide the binaries
or even pre-programmed parts. It's not unlike someone providing the raw
PCBs.
I think a more accurate description for Tony's comparison is that for the
100 DIP board, the person would only get the Gerber (and related) files and
they'd have to get the PCB built.
I think I would equate the source files with the scheamtics of the
device. The Gerber files would be more akin to the binaries of the
firmware, useful for making that device only, not for modification.
Given a scheamtic (and since this resectoring device does not run that
first), you don't have to be able to make the PCB. You could hardwire it
on stripboard. Or wire-wrap it, or...
Incidentally, I learnt the hard way not to provide pre-programmed devices
for such designs. People buy them, make a right mess of wiring them up,
and then expect free replacements. I did it a few times, never again.
-tony
3:01 p.m.
But I
went for small size and ease of reproducability by multiple
different skill sets. My board has two DIPs on it [...]
If you can solder well
enough to fit 2 DIPs (and associated
components, I gurss), then you can solder 100 DIPs. It's the same
skill. pretty good chance of making the small board work
first time, and
probably has a decent chance of finding and fixing the bad joint if
there's an issue.
Maybe, maybe not. It probably depends on their skill at faultfidnign, and
the test gear they ahve, but it might well be easier to find a bad
connection in a board of simple components where that bad connection
causes a specific fault than in the microcontrolelr-based system when
that bad joint ause random misbehaviour of the microcontroller.
-tony
12 Sep
12 Sep
4:40 a.m.
On Mon, 9 Sep 2013, Chris Elmquist wrote:
But I went for small size and ease of reproducability
by multiple
different skill sets. My board has two DIPs on it and the code is maybe
100 lines of C on an ATMEL AVR. It installs between the drives and the
Hm, isn't it quite pathetic to program something as simple and elegant as
an AVR in C instead of assembly? ;-)
Christian
3999
days inactive
4004
days old
24 comments
12 participants
participants (12)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
chrise＠pobox.com -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
ggs＠shiresoft.com -
mouse＠Rodents-Montreal.ORG -
ploopster＠gmail.com -
shadoooo＠gmail.com