Hi there,
I think I've got the write precompensation stuff figured out (finally!) :)
Back in 1983, Control Data (via their Magnetic Peripherals Inc.
subsidiary) released an application note called "PLO and Write
Precompensation for 5.25-inch FDDs". This has since been scanned and
uploaded to Bitsavers (thanks again, Al!):
<http://www.bitsavers.org/pdf/cdc/discs/floppy/77653447_5inchPrecomp_Aug83.p…>
The interesting stuff starts on PDF page 31 ("real" page 28). There's a
really good explanation of why peak shift occurs and why precompensation
is needed. This includes diagrams of problematic bit patterns (both the
original data bits and the MFM-encoded transitions) and shows which bit
needs shifting.
These patterns are:
x011
x110
1000
0001
Which encode to MFM as:
Input MFM coded Shifts Correction
----- --------- ------ ----------
x011 --> xx00101x --> Early --> Delay 250ns
1000 --> 01001010 --> Early --> Delay 250ns
x110 --> xx10100x --> Late --> Advance 250ns
0001 --> 10101001 --> Late --> Advance 250ns
*
"Input" is the data before MFM encoding
"MFM coded" is after MFM encoding has been applied
"Shifts" is the direction in which peakshift will shift the transition
The asterisk denotes the transition which must be shifted
If you're working on raw bits, that's fine -- and indeed, this matches
up perfectly with what's in the Western Digital FD179x-01 application
notes (Figure 6: "Internal Write Precomp Algorithm") and Jean
Louis-Guerin's WD1772 documentation.
But what if we choose to feed the data to an MFM encoder (which converts
every bit into two bits) and then process the output of that in a
bit-serial manner? Well, in that case, we only need to match two bit
patterns:
00101 --> Early --> Delay 250ns
10100 --> Late --> Advance 250ns
*
And thus this precompensation code was born:
uint8_t shiftreg = 0;
int n = 0;
for (vector<bool>::iterator bit = bits.begin(); bit != bits.end(); bit++) {
shiftreg = ((shiftreg << 1) | (*bit ? 1 : 0));
// The shift register delays the output by 2 bits
if (n < 2) {
n++;
continue;
}
switch (shiftreg & 0x1F) {
case 0x05: // 00101 (MFM x011 or 1000) - causes early shift
printf("Early Shifted %d\n", shiftreg&4?1:0);
break;
case 0x14: // 10100 (MFM x110 or 0001) - causes late shift
printf("Late Shifted %d\n", shiftreg&4?1:0);
break;
default:
printf("Normal %d\n", shiftreg&4?1:0);
break;
}
}
Typical precompensation for 5.25-inch floppies, by the way, is 250
nanoseconds. I'm not sure what it is for 3.5-inch, or indeed for other
data rates (if data rate has a bearing on peak shift).
Enjoy!
--
Phil.
philpem at philpem.me.uk
http://www.philpem.me.uk/
I picked up a Deskpro/286 the other day. It passes POST, and the hard disk
(an IBM 0665 30MB F/H ST-412 unit) spins up and makes encouraging noises,
but then it stops (after apparently trying to boot via floppy) with a "non
system disk or disk error" message.
IIRC, there's a setup utility on the Compaq DOS disks - does this include
configuration of the hard disk? I wonder if the system's simply lost NVRAM
settings and so the disk controller is trying to talk to the drive using
the wrong geometry (although of course it could just as easily be a faulty
or formatted drive). There's no obvious manufacturer of the combined
floppy/hard disk controller board, but it's perhaps reasonable to assume
that it's whatever was originally shipped with the system.
If I do need the Compaq DOS floppies, does anyone have images available
(3.5" preferred, but I think I have some spare 5.25" HD floppies and could
put the Compaq's drive into my desktop PC temporarily to write them)
thanks
Jules
List members in that vicinity, of a soldering-iron-wielding
disposition, might be interested to know that tomorrow is Open Day at
London Hackspace.
http://wiki.london.hackspace.org.uk/view/2013_August_Open_Day
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884
I've been able to successfully install openstep 4.2 on a dell gx110 by adding a matrox millennium II, 3C905b-tx for Ethernet and a soundblaster 16 pci. So with those 3 cards you should be able to install openstep 4.2 on any old pc. It supports up to 512mb ram and is super super fast. Compiling is crazy fast. So if you want to mess with openstep/ nextstep on the cheap this is the way to do it.
I've also had it running on numerous thinkpads. A 570E 380ed and a 760 Ed.
Sent from my iPhone
Hi there,
I think I've got the write precompensation stuff figured out (finally!)
Back in 1983, Control Data (via their Magnetic Peripherals Inc.
subsidiary) released an application note called "PLO and Write
Precompensation for 5.25-inch FDDs". This has since been scanned and
uploaded to Bitsavers (thanks again, Al!):
<http://www.bitsavers.org/pdf/cdc/discs/floppy/77653447_5inchPrecomp_Aug83.p…>
The interesting stuff starts on PDF page 31 ("real" page 28). There's a
really good explanation of why peak shift occurs and why precompensation
is needed. This includes diagrams of problematic bit patterns (both the
original data bits and the MFM-encoded transitions) and shows which bit
needs shifting.
These patterns are:
x011
x110
1000
0001
Which encode to MFM as:
Input MFM coded Shifts Correction
----- --------- ------ ----------
x011 --> xx00101x --> Early --> Delay 250ns
1000 --> 01001010 --> Early --> Delay 250ns
x110 --> xx10100x --> Late --> Advance 250ns
0001 --> 10101001 --> Late --> Advance 250ns
*
"Input" is the data before MFM encoding
"MFM coded" is after MFM encoding has been applied
"Shifts" is the direction in which peakshift will shift the transition
The asterisk denotes the transition which must be shifted
If you're working on raw bits, that's fine -- and indeed, this matches
up perfectly with what's in the Western Digital FD179x-01 application
notes (Figure 6: "Internal Write Precomp Algorithm") and Jean
Louis-Guerin's WD1772 documentation.
But what if we choose to feed the data to an MFM encoder (which converts
every bit into two bits) and then process the output of that in a
bit-serial manner? Well, in that case, we only need to match two bit
patterns:
00101 --> Early --> Delay 250ns
10100 --> Late --> Advance 250ns
*
And thus this precompensation code was born:
uint8_t shiftreg = 0;
int n = 0;
for (vector<bool>::iterator bit = bits.begin(); bit != bits.end(); bit++) {
shiftreg = ((shiftreg << 1) | (*bit ? 1 : 0));
// The shift register delays the output by 2 bits
if (n < 2) {
n++;
continue;
}
switch (shiftreg & 0x1F) {
case 0x05: // 00101 (MFM x011 or 1000) - causes early shift
printf("Early Shifted %d\n", shiftreg&4?1:0);
break;
case 0x14: // 10100 (MFM x110 or 0001) - causes late shift
printf("Late Shifted %d\n", shiftreg&4?1:0);
break;
default:
printf("Normal %d\n", shiftreg&4?1:0);
break;
}
}
Typical precompensation for 5.25-inch floppies, by the way, is 250
nanoseconds. I'm not sure what it is for 3.5-inch, or indeed for other
data rates (if data rate has a bearing on peak shift).
Enjoy!
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
Random question of the day:
I recently acquired a brand-new, shrinkwrapped copy of the System/370 Principles of Operation.
Unfortunately it was sans binder.
Anyone have an appropriate-era genuine IBM 3-ring binder they'd be willing to sell me?
Thanks in advance!
-Ben
Hi all,
Who else owns one of these development systems? Herb Johnson and I have
been dumping the ROMs of our two systems, only to discover a lot of partial
(and one total) erasure of our 1702As. My ROMs have lacked a sticker over
the window since it left the Intel factory, but only one of them is
completely erased, or perhaps it's defective. But there are many other
inconsistencies in our ROMs, hinting at possible partial erasure over time.
Herb has been writing up some of our discussion and findings here:
http://www.retrotechnology.com/restore/intl4_roms.html
It would be great to get some others with these systems to dump the ROMs.
The listing for the monitor for the 8 MOD 80 is available, if I recall, but
not for the 4 MOD 40.
It's only a 2kB monitor, so it would be very limited on what it could do.
My guess is that it could talk with a teletype and do some basic reading of
paper tape into RAM. One thing to note is that the entire asynchronous
translation is done without a UART! The 4040 decodes it directly by reading
and writing from two pins on two different ports for keyboard and printer,
and a third pin on a third port for reader run. That certainly takes some
software to control.
If anyone could help Herb and I out, we would appreciate it greatly.
Kyle
W4GNU
On 2013-08-15 19:00, Ian King<IanK at LivingComputerMuseum.org> wrote:
> On 8/12/13 10:05 PM, "Eric Smith"<spacewar at gmail.com> wrote:
>
>> >On Aug 12, 2013 9:22 PM, "Paul Anderson"<useddec at gmail.com> wrote:
>>> >>Does anyone have or know of any available anywhere?
>> >
>> >The only intact KA and KI processors known to exist have recently been
>> >accessioned by the Living Computer Museum in Seattle. It's perhaps not
>> >impossible that another one might be out there somewhere, but if so, it
>> >will be difficult to find, and even more difficult to pry loose.
>> >
>> >Eric
>> >
>> >
> We have a KI and multiple KLs and KSs. We really want a KA, too.:-) --
Well, I know of at least one more KA, which is fully functional. But
it's not likely to be handed out. The same person have one of ever type
of PDP-10 built (with the exception of the PDP-6 and F-1, I think, and
all more or less functional).
Pontus Pihlgren<pontus at Update.UU.SE> wrote:
> On Thu, Aug 15, 2013 at 04:12:31AM +0000, Ian King wrote:
>> >We have a KI and multiple KLs and KSs. We really want a KA, too.:-) --
> How many KA was made?
I think it was a couple of hundred? But I might be misremembering. I
think the information is available online somewhere.
Johnny
On 2013-08-15 19:00, "E. Groenenberg"<quapla at xs4all.nl> wrote:
> Hello.
>
> I need some help, as I'm struggling with some pieces of old
> code of which I have only the macro-11 object files of.
>
> So, I'm looking for a disassembler which can read the .obj
> file and create a .mac file from it.
> I tried Google to find something, but alas, nothing to be found:(
>
> So, it there someone who has such a program?
>
> (BTW, I'm using RSX-11M V4
If you have access to DECUS tapes, you have both DOB and ORC which does
what you are looking for. You should also be able to find them at
ftp://ftp.update.uu.se/pub/pdp/rsx
Johnny
