>
>Subject: Re: MFMulation? (Solid-state replacements for MFM drives)
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Sun, 15 Apr 2007 21:22:33 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 4/15/07, Roger Merchberger <zmerch-cctalk at 30below.com> wrote:
>> Ah, but the beauty of this is, if you make it IDE compatible, you already
>> *have* flash compatibility - just slap a CompactFlash module of your
>> preferred size into a CF->IDE adapter, and Bob's your uncle!
>
>Since desktop drives are moving to SATA, compatibility with PATA (and
>thus easily attached Compact Flash drives) isn't the obvious goal is
>once was. Yes, there will be large amounts of PATA drives for a
>number of years, but I can see that in a small number of years, they
>just won't bother to make them anymore, whereas, Compact Flash is
>Compact Flash - they may stop making that, too, but they aren't as
>mechanically fragile, so they may be easier to track down 10+ years in
>the future.
>
>
>> I doubt there were MFM drives (read: ST506) available that hit the
>> gigglebyte size
>
>There's an understatement - with a practical maximum number of
>platters and heads and tracks and sectors with the techniques of the
>times, no... they never got close to 1GB. They came out at 5MB
>(ST506) and peaked under 200MB. ESDI was the interface of choice for
>a short time if you wanted "large" drives on the desktop, then IDE
>(PATA) swept in and here it is, sweeping back out like the tide. As
>an aside, I happen to have a pair of 600MB ESDI drives on an SDI
>controller on my VAX8200, so ESDI isn't just for large PCs, but they
>were seen there.
What made the jump possible was RLL. MFM drives could do RLL and
those Xt2190 (153mb) drives now exceeded 200mb and climbing.
IDE was simple pushing the RLL controller onto the literal back of
the drive making the path clear for yet higher data rates to the platter.
Cobalt replaced ferrite for the surface media, data rates went up.
Better heads, amps and the like made even higher data rates possible
so that 1Gb and higher was possible. By then GCR and other techniques
were being applied to the problem of getting more into less.
MFM was a starting point and had limited use because it didn't pack the
maximum number of bits possible.
Allison
Warning: this is a long post.
Today I racked my TU56 and TC11. I connected the TC11 to the TU56 with the two interface cables. I hooked up an AC power cord to the TU56. After turning on my H720 power supply and checking the voltages, I hooked up the +5, -15, and ground wires from the H720 power supply to the spade connectors on the TU56 and the TC11.
I then opened up my 11/40, removed my M9312 bootstrap terminator from the last unibus slot (on my RK11-D), moved the M9312 to the unibus-out slot on the TC11, and ran a unibus cable from the slot on the RK11D (where the M9312 previously was located) to the unibus in slot on the TC11.
I then powered everything up (11/40, RL02, RK05, TU56, VT100). This configuration has two RL02 drives, an RK05, and the newly added TU56. I have the appropriate bootstrap ROMs in the M9312. IIRC, the RK05 ROM also contains the dectape bootstrap code.
I put a "never-used" DecTape on both drives, wrapped it around the take up reel 4 or 5 times, set the TU56 in local mode and pressed the forward switch to wind the tape a little more.
I then loaded the address of the M9312 and pressed the start button. The @ prompt appeared on the console. This showed that the unibus signals and the M9312 are working in the TC11. I then decided to boot RT11 from the RK05 drive. It booted fine. The system seemed to be working normally and adding the TU56/TC11 did not adversely affect anything.
Then I decided to test out the DecTape drive to see if it would respond to RT11 commands. Although there was nothing on the Dectapes, I did a DIR DT0:. The drive 0 reel began spinning and spun back to the beginning and the tape came off the take up reel and kept spinning. I flipped the unit 0 toggle switch from the REMOTE position to the OFF position, then wrapped the dectape back on the reel a few turns, set the switch to LOCAL, and wound it using unit 0's forward/reverse switch.
I did the same thing with unit 1 (DIR DT1:). Exact same results. The tape winds and goes off the reel.
If I attempt to do an INIT DK0: or INIT DK1:, the tapes run in forward motion until they are totally wound on the take up reels and then keep spinning. When it runs off the reel and I turn the DT0 or DT1 unit's REMOTE/LOCAL switch to the OFF position, RT11 returns an error message to the VT100 console.
If I attempt to boot off a Dectape (entering DT, DT0, or DT1 at the M9312 @ prompt), the drives spin in forward direction until they wind the tape all the way onto the take up reel and then keep spinning.
The indicator lights on the right side of the TC11 panel seem to be working fine, and when the tapes wind off the reel and I flip the REMOTE/LOCAL switch to OFF, the error light with come on.
So it seems that the TC11 and TU56 are communicating with the 11/40 system, and the system can send commands to either dectape unit 0 or unit 1, and the TU56/TC11 will respond.
My question now is:
If I want to initialize a blank, never-used Dectape so I can use it under RT11, am I doing the right thing by typing INIT DT0: or INIT DT1: ?
How is the dectape unit supposed to respond when I issue an INIT DT0: command? I would assume that it should not wind the tape until it winds it all the way off the reel.
Where do I go from here? It seems that I'm mighty close to LIFT-OFF!!!
I'll post some pics of the racked TU56/TC11 on my web site soon.
Ashley
http://www.woffordwitch.com
>
>Subject: Re: TU-58s (was Re: Some progress with my PDP-11/73 system)
> From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
> Date: Thu, 05 Apr 2007 16:35:21 -0400
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
> >Allison wrote:
>
>>So happens one of my "small" pdp-11s uses a Tu58. the system is a BA-11V
>>with an 11/23 256k of ram, DLV11J and MRV11 rom(boot). Takes 10 minutes
>>to boot, setup VM: then copy key files to and reboot. After that it's
>>pretty decent even if I have to access a file on tape.
>>
>>Everytime I runs it with a bunch of kids of the current PC generations
>>they go gaga and comment on how slow then I explain the amount of ram and
>>storage then they are amazed it can be a functional machine with so little.
>>They can't imagine a useful machine with 32kW of ram and 256kb of storage.
>>
>>
>Jerome Fine replies:
>
>At some time or other, I saw a VT103 with dual TU-58
>drives in the bottom. As noted, it took about the
>lunch break to boot.
Files in wrong order. I learned how to make a pdt11/130
boot faster and thats a LSI-11 no extra ram.
One trick was to put bad blocks at the end of each track
to fource files to be sequential without wraping around
to the beginning. Saved a lot of long rewind/seek operations.
>However, a VT103 can actually support a PDP-11/73
>with all 4 MBytes of memory if the backplane is
>upgraded to 22 bits. The other 2 quad slots can
>have items like a TQK70, a DHQ11 and an RQD11-EC
>which allows up to 4 * EDSI hard drives. In the
>case of ESDI hard drives, I STRONGLY suggest
>used a separate power supply. Otherwise, an
>RQDX3 with an RD51 can also be used and it is
>then possible to place the RD51 under the tube.
A RX180 (VT180) disk box with a floppy and a
st225 and a VT103, a sweet system with a 11/23 or
faster CPU and 4mb ram (run VM:!)
>At that point, you can play games with those PC
>generation of kids and tell that that you don't
>even need a computer, just a monitor and keyboard!
>
>If you use a dual PDP-11/73 or PDP-11/23 with a
>DLV11-J (and no boot ROMs on the CPU), then
>the SIGMA controllers are very handy, either
>a dual MFM (or ESDI) version or the quad ESDI
>version. Again, with the dual MFM version,
>an RD51 (ST412) can be placed under the tube
>and use the internal power supply of the VT103.
>
>It must be about 20 years ago that I did this
>conversion of the RD51 hard drive under the
>tube. I think I still have the backup VT103,
>but without any boards or a suitable controller.
>
>With any ESDI drives, limit the use of the internal
>power supply of the VT103 to a single drive for less
>than 10 seconds which would probably be enough to
>boot and copy any needed files to the VM: device.
Sounds nice. I have a few BA-11VA (four dual width slots)
and it's a challange to put enough boards to make a bootable
viable sytem in that. An 11/23, 256k ram, DLV11J and a Rom
card was full house and for storage the only choice was TU58
or Tu58 emulation (requires bukly balky PC). Though at one
time Sparetime Gizmos offered a TU58 emulator in hardware
using ram with battery backup (total of 512k or DD0/DD1).
I have one of them and that is remarkably fast as there are
no seek dealys and at 31k baud you can move enough to
appear decently fast.
There was also a third party TU58 like system that also
used serial and instead of a tape it was rx50 compatable
floppy. I'd love to find one or at least drawings and rom
code.
Allison
>Sincerely yours,
>
>Jerome Fine
>--
>If you attempted to send a reply and the original e-mail
>address has been discontinued due a high volume of junk
>e-mail, then the semi-permanent e-mail address can be
>obtained by replacing the four characters preceding the
>'at' with the four digits of the current year.
the IBM AT used two 64K piggybacked chips for a total of 128K. I don't have the chips is front of me right now, so I can not tell you if they were MOT chips or not.
As for possibilities, all one has to do is approach a chip mfg and ask them to create the bond out of the chips so they can be piggybacked. Not all that hard when you have money to throw at a company. I am sure that is what IBM did. All that would need to be done is swap an unused pin with a chip select pin. One line goes to the top chip and the other goes to the bottom chip. Power, RAS, CAS, address and data can all be connected together.
best regards, Steve Thatcher
By the way, I did not read any of the other posts on this topic, so please forgive my intrusion if not helpful.
-----Original Message-----
>From: Alexandre Souza <alexandre-listas at e-secure.com.br>
>Sent: Apr 11, 2007 7:19 AM
>To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>Subject: Re: MCM66128L20
>
>>>That's the first thing that puzzles me. It was my understanding that
>>>these were 128Kbit chips, so 18 of them would give you 256K bytes (+
>>>parity) of memory. Can you confirm, please, that 18 of them really are
>>>512K
>>>> The top chips are stamped MCM66128L20; the bottom chips have no part
>>>> number.
>
> Maybe the bottom chips are just EMI filters/pull ups??? :oO
>
> There are NO possibilities that memory can be piggybacked this way. When
>you piggyback two memory chips, at least ONE of the pins must be routed
>separately. At least this is what logic tells me.
>
> I never seen a 128K *D*ram chip. SRAM exists. This is something that is
>driving me crazy here, I cannot find any datasheets/pinouts on this part
>number, nor any kind of info. Crazy.
>
> IF the memory was 16-bit-word, maybe you could be using 256K chips
>
> What was the replacement part you got?
>
> Greetings,
> Alexandre
>
Hi,
> Will a CGA monitor be able to handle 320x200 lo-res? I wonder if
>people have tried hooking them up to Commodore 1902s or 1084s.
I used to use my 520STM+ (a 520STM factory upgraded to 1MB RAM, a UK only
thing I believe) on a Philips CM8833 monitor, it would handle both low and
medium res without a problem. I know STs can also drive CBM 1701s without a
problem.
However, unless the monitor output of the STacy is different to the normal
ST, it won't drive a CGA monitor. CGA monitors expect TTL RGBI, whereas the
ST outputs analogue RGB (albeit at TTL levels, hence the reason for having
to install dropper resistors in the RGB lines when driving a normal,
non-Atari colour monitor).
TTFN - Pete.
Hi,
> I know of a 260ST, not a 540. There was also talk of a 130ST.
Ah, that explains a few things - I really should go take a look at a few
Atari sites, it's been a while.
TTFN - Pete.
The SE is about the most useful desktop 68000 Macintosh. It supports
ADB, some internal expansion options, internal HDD and 2 internal
floppies (both with the right kind of HDD), external floppy port, ADB
... the list goes on. It's a bit noisier than the Plus, and not as fast
as a Portable or PB100, but it has its plusses. Especially when you
want to run old Mac software that has "issues" with newer (32-bit)
equipment.
Is there somewhere a good summary of daisy wheel information?
Not information for the printers, but rather for the wheels
themselves. In particular, character sets and spoke ordering. It
seems to me for what was once a very popular printing technology,
information is very difficult to come by.
C. Itoh, Brother, Smith-Corona, Xerox, Diablo, IBM, Wang, etc. Even
the NEC "thimbles" would be welcome.
Cheers,
Chuck
Thanks for your quick replies, everyone who helped.
I was trying to remotely help someone install Cromix in MSDOS
format from a Linux box and didn't remember whether cat needs
a switch for binary files as DOS does.
Too many OSs addle the brain...
m
------------------
>A simple question for the Linux gurus from a WIN/DOS simpleton:
>How do you concatenate two binary files into one?
>m