Re: Rack-mount or tabletop version of DEC RX50 floppy drive?

[Eric Smith via cctalk]

Thanks to Josh, Ethan, Bob, and Adrian for confirming that there were rack
and table-top RX50 drives. It would be nice to get one since I have an
RUX50, but having never seen one before, I won't hold my breath.

It would also be nice to find the RUX50 manual and print set.

Re: Ethernet names...

[Eric Smith via cctalk]

On Tue, Oct 2, 2018 at 7:38 PM Bill Degnan  wrote:

> On Tue, Oct 2, 2018 at 7:46 PM Eric Smith via cctalk <
> cctalk@classiccmp.org> wrote:
> I've never heard of an Alto being connected to an Aloha Network, nor of any
>
>> network inside Xerox being called "Aloha".
>>
> Well there you go, now you have
>

Thanks! I stand corrected.

Rack-mount or tabletop version of DEC RX50 floppy drive?

[Eric Smith via cctalk]

Did DEC offer a rack-mount or tabletop box version of the RX50 floppy
drive, as they did with e.g. the TU58 and TK50 tape drives? I'm wondering
how they expected the RX50 drive to be packaged when used with a Unibus
PDP-11 via the RUX50 controller.

Re: Ethernet names...

[Eric Smith via cctalk]

On Tue, Oct 2, 2018, 11:47 Bill Degnan via cctalk 
wrote:

> Ethernet was the name given to the Alto (XEROX) Aloha Network


It wasn't an Aloha Network.

created (?)
> by Bob Metcalff (sp?), which was based/inspired by an improved version of
> the ALOHANET used by the U of Hawaii.


In their CACM paper, Metcalfe and Boggs credit the Aloha Network, but
Ethernet was an entirely new network design, not an incremental improvement
to Aloha Network.

  I think Ethernet was a nickname,
>

I wasn't there, but I've never seen any source claim that it was a nickname.

eventually becoming the official name of what was originally the Alto Aloha
> Network.
>

I've never heard of an Alto being connected to an Aloha Network, nor of any
network inside Xerox being called "Aloha".

Re: Ethernet names...

[Eric Smith via cctalk]

On Tue, Oct 2, 2018, 11:35 Grant Taylor via cctalk 
wrote:

> Does anybody know names / terms that correspond to the original 3 Mbps
> Ethernet?
>
> I.e. 10 Mbps Ethernet is also knows as Ethernet II (2) and D.I.X. (for
> Digital, Intel, and Xerox).
>
> Was the first 3 Mbps Ethernet simply called "Ethernet" with an implicit
> "I" (1)?  Was there a name to differentiate it from D.I.X.?
>

3 Mbps Ethernet is _NOT_ Ethernet I. Both Ethernet I and II were 10 Mbps
DIX standards, with II having only minor differences from I.

3 Mbps was sometimes referred to as experimental Ethernet, but AFAIK the
only official name was "Ethernet".

The best way to refer to it is probably "3 Mbps Ethernet".

early ANSI C drafts, pre-1989 standard

[Eric Smith via cctalk]

I'm interested in looking at any published drafts prior to the C 1989
standard. I found X3J11-88-090 here:

https://yurichev.com/ref/Draft%20ANSI%20C%20Standard%20(ANSI%20X3J11-88-090)%20(May%2013,%201988).txt

That makes mention of the previous draft being X3J11-88-001. Does anyone
still have a copy of that draft, or other pre-89 drafts?

I'm not looking for any of the published standards (I've purchased them),
nor any drafts after the 1989 standard.

Eric

Re: SPACEWAR! Switch Boxes for a PDP-12

[Eric Smith via cctalk]

On Mon, Sep 24, 2018 at 11:23 AM, Robert Feldman via cctalk <
cctalk@classiccmp.org> wrote:

> >that is what the PDP-1 at CHM has been using for over 10 years
>
> https://na.suzohapp.com/products/pushbuttons/58-9166-L


Ken Sumrall built the Spacewar control boxes used at the museum, with some
suggestions from me. We originally intended these to be temporary, and to
build nicer control boxes later. Since they were intended to be used by
restoration team members, and possibly museum guests, we wanted them to be
reliable rather than authentic, and specifically did NOT want these
temporary boxes to themselves become historical artifacts. We chose
inexpensive but robust arcade pushbuttons. They can take a beating, and in
the event that the microswitch does break or wear out, it can easily be
replaced, though the complete button assembly with microswitch is not
expensive. The boxes are particle board. We used DE-9 connectors. On the
PDP-1, hyperspace is invoked by the CW and CCW rotate controls being
activated simultaneously, so the hyperspace button is wired via series
diodes to both rotate buttons.

After we built them, Steve Russell pointed out to us that although these
boxes don't look like at all like the originals, they actually are
authentic, in the sense that like the originals, these boxes were quickly
knocked together rather than carefully planned, and are functional rather
than pretty.

We positioned the individual buttons based on the layout used on one of the
Atari coinop games, "Space Duel" IIRC, on the because Atari had done a good
job of laying them out to be easy to use.

I'm not trying to discourage anyone from trying to make replicas of the
original Spacewar control boxes, but aside from some grainy photos and a
brief description, not much detail about them is actually known.

We do not know what controls were used when PDP-1 Spacewar was demonstrated
at the Computer Museum in Boston. We don't think they had the original
control boxes. Possibly they might have just used the PDP-1 console
switches, which is quite inconvenient and increases wear on those
switches.  When we restored the PDP-1, we discovered that some of the
console switches were flaky, and upon inspection, that they appeared to
have been replaced multiple times, with suboptimal craftsmanship.

Re: DEC H744 +5 supply

[Eric Smith via cctalk]

>
> * If you supply a link & location to a schematic I'll take a look, I don't
> feel like wading around in bitsavers pdfs to try to find it right now.


page 207 of:
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1140/PDP-1140_System_Engr_Drawings_Rev_P_Jun74.pdf

Re: DEC H744 +5 supply

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 1:38 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> My understanding is that, without using a transformer (which creates an
> independent circuit loop - more below), there's no way to increase the
> _amperage_ out of circuit over what's fed into it: since amps are
> electrons/second, the electrons/second out more or less have to equal
> electrons/second in, since one can't easily 'create' electrons - at least,
> in
> normal electonic gear!
>

No, a switching buck converter can definitely have more current out than
in. In fact, that's common. The buck regulator on your PC board may supply
100A at around 1V to your CPU, but doesn't draw anywhere near that many
amps from its 12V input.

Although it works differently than a stepdown transformer, it does the same
job, converting power at a higher voltage but lower current to a lower
voltage at a higher current.

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 12:06 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> Eric hasn't specified [and shouldn't have to] as to WHY,
> but here are some idle speculations:
>

Mostly #6, and a little bit of #5. I'd be delighted to offer "retaliation
in kind for the SS damage of drives of Steve Jackson Games", but I don't
think destroying my own drives provides that.


> 5) as a test suite for development of thermite  (Does Amazon sell pre-made
> thermite?)
>
> 6) Maybe Eric just wants to vent some anger over problems he had with them



On the other hand,

1) Reduce the likelihood that they will end up on eBay as "Seller
> Refurbished" or "New, other".
> 1b) to put on eBay as "New, other" or "seller refurbished", WITH PICTURES,
> as a commentary on eBay condition descriptions.


maybe after application of thermite I might sell them as "Seller
Refurbished".

Eric

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 11:28 AM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> Put it in a gift-wrapped box next to you on the bus.
> Whoever steals it will get just what they deserve.
>

:-)

But actually I wouldn't wish ST3000DM001 drives on my worst enemy!

Re: HP 2000 /2100 emulator ?

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 8:18 AM, Pete Lancashire via cctalk <
cctalk@classiccmp.org> wrote:

> emulate an HP 2000 or even in modern 2100 my goal is nothing serious I'd
> love to be able to do HP basic and find the version of Star Trek I think
>


> If I could have my dream come true the emulator would be on a little SBC
> running Linux t
>

SIMH can do that and runs just fine on a Raspberry Pi, or probably on any
other Linux SBC.

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 6:51 AM, systems_glitch via cctalk <
cctalk@classiccmp.org> wrote:

> Burning of potassium permanganate to manganese greensand will often get it
> going. You are on your own for figuring out how to do that.
>

Multiple sources, including Robert on this list, tell me just to use
magnesium ribbon. I just looked it up; it's inexpensive and should be very
easy to use.


> Thermite is not the ultimate destructive force some people seem to think it
> is. If you're trying to totally liquefy the platters you'll probably need
> to remove them from the drives and put them in something capable of
> containing the thermite for at least a little while (e.g. graphite
> crucible). The usual, "put it in a flower pot" will likely either result in
> a mess or a smallish hole through the platter, which really isn't any
> better than running a drill through it.
>

All the more reason to experiment with it!

Elsewhere it's been suggested that somewhere between 0.25 and 0.5 kg of
thermite ought to do the job without needing to disassemble the drive
first. I've got sixteen drives to experiment with.

Re: Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Eric Smith via cctalk]

On Fri, Sep 21, 2018 at 6:04 AM, Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> Or just throw it in the garbage.


That's way too good for these 

Advice requested on proper disposal of Seagate ST3000DM001 disk drives

[Eric Smith via cctalk]

Anyone have advice on making thermite? Ingredients, sources, proportions?

The internet seems to think that just using aluminum powder with ferric
oxide is relatively hard to ignite, and that some manganese dioxide would
help with that.

Without spending too much time shopping, it looks like I can get:
* aluminum powder, 5 micron, 2 lb for $34
* ferric oxide, 10 lb for $27
* manganese dioxide, 1 lb for $39

Re: Looking for two DEC H445 power bricks for PDP 11/40 project

[Eric Smith via cctalk]

On Tue, Sep 18, 2018 at 8:27 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> (Note that if you have an old
> machine/harness, there's a jumper you have to add if you have only a single
> H745; see the second paragraph on page 6-18 of DEC-11-H40SA-B-D.)
>

I totally missed that. It wasn't in the previous edition, DEC-11-H40SA-A-D.

However, now I see that both editions mention that the H744 in slot C is
optional, which I also was not previously aware of.

Although I've had a few 11/40 machines, I didn't often have to do anything
about the power supplies other than check the DC voltage and ripple.

Re: Looking for two DEC H445 power bricks for PDP 11/40 project

[Eric Smith via cctalk]

On Tue, Sep 18, 2018 at 2:11 AM, P Gebhardt via cctalk <
cctalk@classiccmp.org> wrote:

> As I don't have core memory modules available, I thought of using MS11
> memory,
> which, according to my research, seems to be an option for 11/40 systems.
> The system manual states on page 6-7 that the base power configuration
> consists
> of two H745 regulators and that one may be swapped with a H754 in case
> MF11-U
> memory is used.
> Does that mean that a single H745 regulator might be sufficient for my
> needs?
>

If you don't have core memory, you should have three H744 in slots A, B,
and C, and two H745 in slots D and E.

Re: Looking for two DEC H445 power bricks for PDP 11/40 project

[Eric Smith via cctalk]

On Mon, Sep 17, 2018 at 4:17 PM, dwight via cctalk 
wrote:

> I had a problem with brick power supplies a number of years back. I found
> an issue that caused them to fail. I had about ten of them on the same
> power switch. You'd think this would not be an issue but it is.
>
> You see it works like this, each one had a transformer in it. When you
> disconnect the power, with a switch, each of the transformers often has
> energy left in the cores. Normally for just one supply, this isn't an
> issue. When you have a bunch of these, only one supply absorbs all of the
> energy. When it does, it will blow some part of that supply up. On the ones
> I had, it'd take of the negative rail.
>
> I put a MOV on the power rail and didn't have any more issues with power
> cycling.


Interesting!

The DEC regulator modules under discussion (H744, H745, H754, etc) probably
don't have that particular problem. They are switchers, and run on 20-30VAC
input rather than directly on mains voltage. The H742 or H7420 bulk supply
which the regulator modules plug into has a large power transformer from
mains to the intermediate AC, and supports up to five regulator modules, It
also has a control module which includes one or two built-in linear
regulators (low-power compared to the plug-in switching regulators).

The PDP-11/40 has one H742 with five regulator modules. The PDP-11/70 has
two H7420s with three or four H744 regulator modules each.

Some of the regulator modules are rated for up to 150W output. The most
common, the H744, is rated for 125W (5V 25A). However, DEC designed
somewhat conservatively and didn't normally operate the regulators near the
maximum rated current. I don't think the H742 or H7420 can handle much more
than 500W total, hence the 11/70 needing two of them.

Re: Looking for two DEC H445 power bricks for PDP 11/40 project

[Eric Smith via cctalk]

On Mon, Sep 17, 2018 at 1:30 PM, Henk Gooijen via cctalk <
cctalk@classiccmp.org> wrote:

> As far as I know, the 11/40 uses only one H745.
> And vague memory seems te recall that the -15V brick is an “odd one”,
> because, unlike all other bricks, it needs the +15V from the regulator that
> is inside the H742 block. But I could be wrong ...
>

The D and E position regulators in the H742 of an 11/40 can be:
* both H745, if no MM11-U core memory is used
* one H745 in D and one H754 in E, if some core memory is used
* no H745, and two H754 in D and E, if a lot of core memory is used

The A, B, and C position are always H744 (+5V 25A).

I'm not clear on the distinction between "some" and "a lot" of MM11-U core
memory. It might be explained in the 11/40 manual, or one might have to
work it out from which memory backplanes are powered from which regulator
modules.

Re: cctalk Digest, Vol 48, Issue 17

[Eric Smith via cctalk]

On Mon, Sep 17, 2018 at 1:11 PM, Jeffrey S. Worley via cctalk <
cctalk@classiccmp.org> wrote:

> What kind of cores does it use?
>

Pretty ordinary core memory. Being an early system, the cores were rather
large, so high currents were needed for read and write. There was forced
air temperature control, vs. oil immersion used in the contemporary IBM
7302 core storage unit (later replaced by air-cooled 7302A).

Re: VT100's

[Eric Smith via cctalk]

On Thu, Sep 6, 2018 at 1:14 PM, Carlo Pisani  wrote:

> > > cause it's the simplest, I guess
> > The VT100 was quite complicated compared to contemporary terminals at the
> > time of its introduction.
>
> why do you say that?
> a vt100 terminal requires only a text VDU (video display unit) with
> hw-scrolling support, and a piece of software to support the VT100
> protocol (escape-codes decoded into action for the VDU).
>
> in fact, my Digital VT200 comes with an ASIC chip for the VDU, while
> the software side runs on an Intel 8051 MPU that directly interfaces
> the keyboard, the VDU, and the serial line
>
> this doesn't look complex
>

Not complex by today's standards, no.

Compare the VT100 circuitry to the circuitry of contemporary terminals
(1978). Compare the VT100 "programming information" to that for
contemporary terminals. There might have been some other terminals that
complex, but it was way more complex than common terminals of the day.

Re: VT100's

[Eric Smith via cctalk]

On 09/06/2018 09:37 AM, Carlo Pisani via cctalk wrote:

> cause it's the simples, I guess
>

The VT100 was quite complicated compared to contemporary terminals at the
time of its introduction.

On Thu, Sep 6, 2018 at 10:22 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I used to naively think that the VT100 was the lowest end Video Terminal.
> Then I subsequently saw references to VT50 and VT52.  So now I have no clue.
>

If you think those were crude, take a look at the VT05, DEC's first
standalone serial video terminal.

Re: Article on Gopher with Cam in it

[Eric Smith via cctalk]

I especially like the description of the UMN Shepherd Labs building having
no windows, placed directly beneath a photo of the building with around 150
windows visible.

Re: Datic 2000 / Ampex 844 Documentation ?

[Eric Smith via cctalk]

On Thu, Aug 23, 2018 at 2:37 PM, jos via cctalk 
wrote:

> First time I have seen a 14" drive on a CP/M system
>

There were some versions of CP/M on the Intel MDS development system (the
_original_ CP/M machine) with support for the Intel MDS 740 hard disk
system, which was an Intel SBC 206 controller with a CDC 9427H Hawk 14-inch
fixed/removable drive, with IBM 5440 style media.  I'm not sure whether the
CP/M support was provided by Digital Research, or required a third-party
BIOS.

Starting in 1979, IMSAI sold the CDC Hawk, with support in IMDOS II (a
licensed and modified CP/M 1.33).

Ohio Scientific offered hard disk systems fairly early on, using 14-inch
drives. They supported them in the OS-65U operating system, I suspect that
they had CP/M support for them on their systems that included a Z80
processor.

The first time I personally used a hard disk with CP/M was in 1981. It was
earliest model Corvus disk system that used an IMI 7710 8-inch drive
(smoked-plastic enclosure), connected to an Apple II, the latter containing
a Microsoft Z80 Softcard.

At one point I had to do a low-level format of the drive. You had to get
the formatter program from Corvus, and add a jumper to the drive backplane
to enable formatting.

Re: DTC TakeTen media?

[Eric Smith via cctalk]

On Thu, Aug 23, 2018 at 2:20 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> The thing that really brought Drivetec down was that you had to use
> their factory-preformatted embedded-servo floppy media.  It was
> expensive (about $15 each in 1986).
>

Same with Iomega ZIP disks (introduced 1994, initially $20 medium), but
those were wildly successful.

I don't think requiring factory-formatted media was really the problem. It
seems more likely that the Drivetec disk only having the capacity of seven
floppy disks was the problem.

Re: First 3.5 inch FDD [WAS: RE: Prototype IBM DemiDiskette drive]

[Eric Smith via cctalk]

On Thu, Aug 23, 2018 at 12:43 PM, Tom Gardner via cctalk <
cctalk@classiccmp.org> wrote:

> Well it all depends upon what u mean by "first"
>
> The Sony drive and cartridge were not compatible in many ways with what
> became the physical, magnetic and electrical interface standards for the
> 3.5-inch drive and cartridge.  The standards came out of the "Microfloppy
> Industry Committee" (Google it with quotes) organized by Shugart Corp.
> Either Shugart or Tandon was the first to ship drives compatible to the
> standard.  Tandon probably did the first such cartridge.
>
> The original Sony drive and cartridge died out and Sony didn't come out
> with
> a compatible set until well after Shugart and Tandon.  The early adopters
> of
> the Sony design like HP then changed to the industry standard design.
>

AFAICT, the only difference was that the pre-standard Sony 3.5-inch
diskettes had a manually operated shutter. The manual shutter and automatic
shutter 3.5-inch diskettes are interchangeable with some care.

For a while, diskettes were sold that had the automatic shutter, but also
had a way the user could latch the shutter open, so that they could be used
in early drives that didn't have the pin to open the automatic shutter.

I only ever saw the manual-shutter drives in Sony and HP equipment, though
I wouldn't be surprised if there were some other uses.

Re: Prototype IBM DemiDiskette drive

[Eric Smith via cctalk]

On Thu, Aug 23, 2018 at 12:51 PM, Tom Gardner 
wrote:

> It was the SA200 a 2/3rds height (51 mm) 5¼-inch FDD at $118 in quantities
> of 5,000 or more.  It was sold in 1982 but got killed by the true ½
> heights  which Shugart OEMed from Matsushita.
>

Hi Tom,

The SA200 came later, and just from the photographs I can tell that it was
a much better-engineered drive than the one I'm referring to.
http://www.computerhistory.org/collections/catalog/102677924

http://engineeringhistory.tumblr.com/post/92146695534/shugarts-sa200-525-minifloppy-disk-drive

The drives I saw in 1980 were prototypes or engineering samples, and didn't
look at all like the SA200.

Re: Prototype IBM DemiDiskette drive

[Eric Smith via cctalk]

On Wed, Aug 22, 2018 at 3:11 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> Are you sure that that was 750ms track to track step, not 75ms?
>

Yes. From innermost track back to track 0 was even slower.

Re: Prototype IBM DemiDiskette drive

[Eric Smith via cctalk]

On Wed, Aug 22, 2018 at 1:09 PM, Al Kossow via cctalk  wrote:

> I just picked up a Model 350 on eBay, just because I'd never seen
> a Shugart sub 5" drive.
>

Unfortunately I don't recall the model number, but there was a Shugart 5
1/4" drive that made it at least to prototype and field test around late
1980 or early 1981. It was supposed to be really inexpensive, but almost
plug-compatible with standard drives like the SA400. Unlike the SA390, it
did have electronics.

Instead of being built on an aluminum casting, it only had bent metal. The
head stepping mechanism worked like an 8-track tape. It used a solenoid to
advance one track inward; the only way to go outward was the next step from
the innermost track returned to the outermost (track 0). The single track
step time was incredibly slow; I think it was around 750ms, vs 40ms for an
SA400.

My employer at the time, Apparat, then famous for NewDOS-80 for the TRS-80,
had one for evaluation, but decided not to resell them. It would have
required special software support, which Apparat could have put in
NewDOS-80. Presumably patches could have been offered for other TRS-80
operating systems.

I wasn't told what the retail price of the drive would have been, but I
don't think it would have sold well even at 1/4 the price of an SA400.

Re: Single-height Qbus grant continuity PCB

[Eric Smith via cctalk]

On Tue, Aug 14, 2018 at 9:52 AM, Tony Duell via cctalk <
cctalk@classiccmp.org> wrote:

> But I have here a little square board (the same size as the older Unibus
> grant
> continuity card) with just 2 pairs of pins linked. In the etch is a
> Digital logo (so
> I assume it's a real DEC product) and :
>
> LSI11 Grant
> Continuity
> G7272
> 5012564B
> Side 2
>
> Has anyone come across that one before?
>

Yes. It's not as common as M9047, and not as convenient, but it works.
There's reportedly also an M9037, which I've never seen.

Re: German Translation, Serial Port?

[Eric Smith via cctalk]

On Thu, Aug 9, 2018 at 8:26 PM, Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> On 08/09/2018 09:39 PM, W2HX via cctalk wrote:
> > Hello friends. I need a translation from a German manual describing
> serial port parameters. I used google translate but it  doesn't quite give
> me the warm and fuzzy. Anyone here speak German? Here is what it says:
> >
> > Betriebsart:  Asynchron 16
>

Possibly they are referring to a UART that internally uses 16x
oversampling, which is quite common, but that information is not normally
needed in a description of communication parameters.

Re: RQDX3 formatter

[Eric Smith via cctalk]

On Fri, Aug 3, 2018 at 10:08 AM, Bob Smith via cctalk  wrote:

> http://www.vcfed.org/forum/showthread.php?38940-Patching-
> ZRQCH0-to-use-any-geometry-MFM-hard-disk-on-RQDX3
>

Is there some reason Lou doesn't want his document made publicly available
on a web page?

Re: RK05 spindle pulleys - trade 50Hz vs 60Hz?

[Eric Smith via cctalk]

On Wed, Jul 25, 2018 at 12:17 PM, Tony Duell  wrote:

> On Wed, Jul 25, 2018 at 5:48 PM, Eric Smith via cctalk
> > Some products were built using different transformers for 50 vs 60 Hz
> > models, and the 60 Hz models uses a transformer inadequate for 50 Hz
> > operation.
>
> This may well be true (I think it is), but the original question was about
> a
> particular device, the DEC RK05 disk drive. According to the maintenance
> manual (on bitsavers), the coversion between 50Hz and 60Hz involves
> changing
> the motor pulley. No comment about replacing the motor, the start
> capacitor,
> or anything else.
>

Right. I was just responding to a later, general comment about motors.
There are, however, DEC products other than the RK05 which had different
transformers for 50 Hz and 60 Hz. For example, the H771 power supply used
in the RX01 and RX02. There were three H771 models, The H771A for 90-132
VAC 60 Hz, The H771C for 90-132 VAC 50 Hz, and the H771D for 180-264 VAC 50
Hz. The H771A uses a transformer rated for 60 Hz. The H771C and H771D both
use the same 50 Hz rated transformer, with different wiring. The H771C and
H771D also require one of two different wiring harnesses to cover the
entire mains voltage range, e.g., 90-120 VAC vs 100-132 VAC for the H771C,
or twice those voltages for the H771D.

Re: RK05 spindle pulleys - trade 50Hz vs 60Hz?

[Eric Smith via cctalk]

On Wed, Jul 25, 2018 at 7:54 AM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> > On Jul 25, 2018, at 9:50 AM, GerardCJAT via cctech <
> cct...@classiccmp.org> wrote:
> >
> > Why don't you simply power it through an inverter that will output 60
> Hz, eventually even "down to" 120 V , true sine wave, of course ??? They
> are not that expensive by now.
>
> I wouldn't worry about "true sine wave".  That seems more of a marketing
> thing anyway, and motors don't care.  Just feed them with a variable
> frequency motor drive and all should be well.
>
> > And be carefull : motor designed for 60 Hz, running "under" 50 Hz, OR
> THE OPPOSITE, I do not recall  !!!, display a significant reduced life time.
> > I have to check which is which, but I know this is a question of
> saturated magnetic field. Better check first.
>
> That doesn't sound right.  If you run the frequency up high enough you
> might get into problems with magnetic materials not designed for it.  And
> much lower probably gives you reduced torque.  But 50 vs. 60 Hz is a
> trivial difference for a motor, I can't see any reasons for that to cause
> trouble.  I routinely run my lathe at half frequency if not less, and it
> doesn't complain.
>

I'm not sure about motors, but 60 Hz power transformers can't handle as
high a maximum power (or current) when used for 50 Hz. The maximum power
has to be derated. Some transformers are specified/sold with a single power
specification for both 50 and 60 Hz use, which just means that the vendor
has built the necessary derating into even the 60 Hz specification.

Some products were built using different transformers for 50 vs 60 Hz
models, and the 60 Hz models uses a transformer inadequate for 50 Hz
operation.

Re: how good is the data reliability with CD ROM and DVD RAM?

[Eric Smith via cctalk]

I wrote a lot of DDS2 and DDS3 tapes back in the day. When my DDS3 drive
broke, I got another drive. I found out that my first drive was seriously
out of calibration, and though it could read its own tapes, other drives
could not. All the data was gone.

I'm considering getting an LTO drive, but I won't do it unless either I buy
two drives, or find someone else with the same generation LTO drive who
would like to exchange encrypted backup tapes for verification.

Re: how good is the data reliability with CD ROM and DVD RAM?

[Eric Smith via cctalk]

On Mon, Jul 23, 2018 at 11:48 AM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> I think that the use of tapes in the 23rd century justifies their
> reputation for durability:
>
> http://memory-alpha.wikia.com/wiki/Microtape


Very impressive, since Microtape was first sold in 1963, as an enhancement
over the previous LINCtape (ca. 1961).

Re: GoTEK SFR1M44-U100...

[Eric Smith via cctalk]

On Tue, Jul 17, 2018 at 2:49 PM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I conceptually get that the GoTEK can't go any faster than the Floppy's
> IDE (I thought floppy was a derivative of IDE.) bus can carry the data.


IDE came much later and isn't very similar to the floppy interface. Here's
more history of it than you probably wanted:

IBM invented the 8-inch floppy drive and had a proprietary interface to it
(discussed here recently). Memorex made plug-compatible drives, but the IBM
interface did not become an industry standard.  With IBM's earliest floppy
drives (23FD "Minnow"), even the medium, rotation rate, data encoding, and
index hole locations weren't compatible with what became the industry
standard. Minnow was shipped to customers as part of IBM mainframes and
control units as a read-only device to load microcode, though obviously
internally IBM had equipment to write the disks.  IBM redesigned it as the
33FD "Igar", and that did set an industry standard for the media format,
but still did not standardize the electrical interface.

The Shugart SA-900/901 drive standardized a 50-pin interface for eight-inch
floppy drives. The Shugart SA-4000 series 14-inch winchester hard disk
drives used a similar but not identical 50-pin interface. The SA-1000
series 8-inch winchester hard drives moved the data to a "radial" interface
using separate connectors for each drive, while keeping the 50-pin
interface for control and status. The SA-4000 and SA-1000 series
established defacto standards for early winchester drives.

Shugart invented the 5.25-inch floppy drive. The Shugart SA-400 drive
standardized a 34-pin interface for 5.25-inch floppy drives, which was for
the most part a subset of the 50-pin interface, with the pins rearranged.
Most 5.25-inch floppy drives provided spindle motor on/off control over the
interface but had no head load solenoid, where previously most 8-inch
floppy drives gave the interface control over the head load solenoid but
had no spindle motor control. (Many of the later 8-inch half-height floppy
drives followed this trend.)

The Shugart Technology (a different company, later renamed Seagate) ST-506
drive standardized a 34-pin interface for 5.25-inch winchester hard drives,
which was in most regards a subset of the SA-1000 interface, with a
different pinout, and a different differential signalling standard (RS-422)
on the radial data connector.

When 3.5-inch floppy drives and hard drives were introduced, most used the
same 34-pin interfaces as their 5.25-inch counterparts.

All of the drives and interfaces previously described are bit serial, with
discrete control lines for all drive functions. The interfaces have no
parallel bus structures for either data or control.

There were third-party hard disk systems for the IBM PC, but the first
official IBM hard disks for PCs were for the PC/XT and PC/AT. The PC/AT
controller in particular was based on a Western Digital design.The IDE hard
disk interface was essentially the host interface of the Western Digital
hard disk controller. As such, it uses a parallel data bus for both data
and commands. There are no discrete drive control signals.



> I was hoping to avoid some timings of the physical aspects of spinning the
> disk and seeking.
>

Unfortunately not. A floppy drive doesn't have any way to know what sector
the host wants, so a drive emulator has to simulate the rotation process.
Most floppy interfaces, including those used on PCs, don't have buffered
seek, so there's no easy way for the emulator to short-circuit the step
process either, though you could possibly tell the computer to configure
the floppy disk controller chip for a faster seek rate.

Re: GoTEK SFR1M44-U100...

[Eric Smith via cctalk]

On Mon, Jul 16, 2018 at 4:58 PM, Fred Cisin  wrote:

> On the Lisa "Twiggy" diskettes, they made special provision to get more
>>> thumb prints.
>>>
>>
> On Mon, 16 Jul 2018, Eric Smith wrote:
>
>> I imagine you're aware of the actual reason for the two diametrically
>> opposing jacket cutouts for the read/write heads.
>>
>
> I'm NOT sure.  I speculate:
> 2) To have two sets of heads.  Either performance, or simply two single
> sided heads, to have felt pad instead of head to head pressure
>

The latter, two single single-sided heads, each opposed by a pressure pad.

Aside from the provision for extra fingerprints, a problem with this scheme
was that they varied the rotation rate depending on the position of the
head in use. Unfortunately since there was only a single actuator, when the
top head was near the inside, the bottom was near the outside, and vice
versa. Except for the middle few tracks, it was never fast to switch from
one head to the other without seeking. The logical disk organization was
all of side zero followed by all of side one, rather than by cylinder.

Re: GoTEK SFR1M44-U100...

[Eric Smith via cctalk]

On Mon, Jul 16, 2018 at 4:17 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> On the Lisa "Twiggy" diskettes, they made special provision to get more
> thumb prints.
>

:-)

I imagine you're aware of the actual reason for the two diametrically
opposing jacket cutouts for the read/write heads.

Eric

Re: GoTEK SFR1M44-U100...

[Eric Smith via cctalk]

On Sat, Jul 14, 2018 at 10:22 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> So has any of the firmware writers for the GoTek implemented the Victor
> 9000 scheme (zoned+GCR) yet?  Just curious.
>

I have a Victor 9000, so I've been meaning to add support to fluxtoimd to
be able to extract Victor 9000 data from flux transition images (DiscFerret
and KyroFlux stream file) into ImageDisk images, which are then easily
manipulated. Which reminds me, I'm way behind in merging some contributed
bug fixes.

Eric

Null program (was Re: ITS DDT anecdote)

[Eric Smith via cctalk]

That reminds me of one of my favorite computer trivia questions:

What is the shortest useful CP/M program?

Re: Another DCJ11 oddity

[Eric Smith via cctalk]

On Tue, Jul 10, 2018 at 1:38 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Jerry Weiss
> > In addition to above, there is a bypass cache bit in the PDR (section
> > 1.5.6.2) for finer control.
>
> Yes, I only found that out last night (or maybe I saw it on a previous scan
> of the manual, but its importance didn't register). The -11/70 doesn't have
> that! Very useful for my application (a memory tester program)...
>

IIRC, there are jumpers in the 11/70 that can be used for cache bypass. It
wasn't considered necessary or useful for normal system operation. Software
control of cache bypass was added to the KB11-Cm used in the ill-fated
PDP-11/74 multiprocessor system. Also the KB11-Cm had interlocked ASRB like
the J11; the memory bus from the cache to the MKA11 multiport memory had an
additional signal to interlock the ASRB read/modify/write. Unfortunately
there's no public documentation on the KB11-Cm or the MKA11 from which to
inspect the details. I think the KB11-Cm _might_ have forced ASRB
instructions to always bypass the cache, to avoid the need to dedicate an
entire uncached page to semaphores, but I'm not certain.

Re: Who is eBay's customer was RE: SMS floppy disk controller

[Eric Smith via cctalk]

On Mon, Jul 9, 2018 at 1:57 PM, Ali via cctalk 
wrote:

> Yeah, well that is the age old argument. As far as I am concerned he who
> ponies up the cash is the customer. The sellers may be "customers" for eBay
> store front ends or advertising but the main business/revenue model is the
> fee on sale of items and that is paid by the buyers when all is said and
> done.
>

You know that, and I know that, but eBay apparently chooses to ignore it.

Re: SMS floppy disk controller

[Eric Smith via cctalk]

On Sun, Jul 8, 2018 at 10:12 PM, Ali via cctalk 
wrote:

> Yeah, I hate it when ebay gets creative. It usually ends up screwing the
> customers/buyers.
>

I don't think eBay considers the buyers to be their customers.

Re: ok I have to ask...confirm direction of GRANT continuity cards please

[Eric Smith via cctalk]

On Thu, Jun 28, 2018 at 8:26 PM, Bill Degnan via cctech <
cct...@classiccmp.org> wrote:

> I have always pointed my grant continuity cards in the same direction as a
> NPG card, with the traces to the left/facing the last slot of the
> backplane.  I am 99% sure this is right but I was asked and I just want to
> be 100%...am I right?  In particular the traces point away from the CPU
> cards, at least on an 11/40 and 11/05.  Please just tell me I am not losing
> it.
>

If your system works properly, the grant cards are in the right way. If the
grant cards are installed wrong, or missing, it will cause serious
problems, and you're unlikely to be able to boot anything.

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Thu, Jun 28, 2018 at 8:39 PM, Jon Elson via cctalk  wrote:

> On 06/28/2018 12:22 PM, Liam Proven via cctalk wrote:
>
>> What amazed me is that none of the NICs blew, none of the machines failed
>> or died. Once the cabling was sorted, it was OK. Who knew that BNC Ethernet
>> ports could handle 100V or more flowing through them and mostly work?
>>
> They are galvanically isolated, good for several thousand Volts.
>

Where "several thousand Volts" is 1500V minimum according to IEEE 802.3.
Since more isolation costs more money, don't count on any normal product to
have more than 1500V isolation. In fact, given that it's all made as
cheaply as possible, I'm not sure you should really even count on 1500V.

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Fri, Jun 29, 2018 at 7:31 AM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> People have used RS232 over longer distances, of course, and gotten away
> with it.
>

And I would have gotten away with it, too, if it hadn't been for those
meddling ground potential differences!

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Thu, Jun 28, 2018 at 2:20 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> So, on a TIA/EIA/RS-232C DB-25 connector, what's the official position
> on pin 1?  The standards calls it PGND = Protective ground and most
> reference seem to indicate that this is chassis/earth ground at both
> ends of a cable.
>

Which is exactly why this kind of problem routinely happens with
TIA/EIA-232 and RS-232. People try to run it hundreds of feet to somewhere
with a significantly different ground potential, and if they're _lucky_, it
only works badly, but often equipment gets damaged.

Since -232 doesn't have any galvanic isolation, even if you don't ground
pin 1 at one end, it will still have the same problem on signal lines,
because ultimately they're referenced to ground at both ends. If you _must_
run a long -232 cable, you should use some kind of isolator at one end.

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Thu, Jun 28, 2018 at 7:18 AM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> > On Jun 28, 2018, at 4:52 AM, Peter Coghlan via cctalk <
> cctalk@classiccmp.org> wrote:
> > On a slightly different point, didn't the thickwire spec call for the
> outer
> > conductor of the cable to be earthed at exactly one point, presumably for
> > safety reasons in case the cable contacted something at high voltage?
>
> Yes, Ethernet spec section 7.6.3.  Also for static discharge, though it
> doesn't say that explicitly.
> [...]
> Looking at 802.3, it says that a Thinwire segment MAY be grounded at one
> point, but not at multiple points.  It also requires a static discharge
> path at each transceiver, 1 Mohm to ground.
>

In case it may not be obvious to some readers, the reason you should NEVER
ground an Ethernet cable (of any kind) at two points is that the ground
potential at two different points is unlikely to be the same, so that will
cause a DC current flow through the cable.  If there was a DC flow of a
only a few mA, it might not be a big problem, but in practice the resulting
DC flow could be _many_ amps, and could both damage equipment and be a
safety hazard for personnel.

Of course, this isn't specific to Ethernet. It can happen with e.g.
TIA/EIA-232 (formerly RS-232) as well, and in fact that is even more common
in practice, because Ethernet is transformer-isolated at each station, but
TIA/EIA-232 is usually not.

It's perfectly fine to have the 1 Mohm static discharge path at multiple
points, because the 1 Mohm resistance prevents there from being any
significant current. If the cable is not grounded at all, having at least
one such static discharge path is important to ensure that no static charge
builds up on the cable.

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Wed, Jun 27, 2018 at 12:39 PM, Paul Koning 
wrote:

> This reminds me of a research project done at DEC that at one point was
> discussed as a possible product but didn't happen: an Ethernet segment
> mapping device.  It was called "packet voltmeter".  The idea was that you'd
> have one at each end of the cable (it replaced the terminator).  It would
> build a table of source addresses and packet signal amplitude.  You could
> then combine the measurements at the two endpoints, plus the known cable
> attenuation, to make a physical map (with tap placement) of each Ethernet
> node.
>

HP made that, and sold it as the 4990S "LANProbe Network Analysis System",
which consisted of a 4991A "LANProbe" Cable Segment Analyzer, which you put
at one end of the 10BASE-2 segment, and a 4992A "node locator", for the
other end. There was also HP 4990A ProbeView software for Windows 3.0, but
the 4991A and 4992A together could do what you describe, even without the
the 4990A.

I bought a 4991A from a surplus store cheap 20 years ago, but I've never
found the 4992A, and the 4991A offers only a tiny subset of the
functionality if you don't also have the 4992A.

The Internet doesn't know much about the HP 499x products. They are
mentioned in an HP Journal article "Design Challenges for Distributed LAN
Analysis" in February 1992 (vol 43 no 1 page 66 ff.).

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Wed, Jun 27, 2018 at 10:59 AM, Paul Koning 
wrote:

> > On Jun 27, 2018, at 12:36 PM, Eric Smith via cctalk <
> cctalk@classiccmp.org> wrote:
> > Collision detection was the reason (or at least _a_ reason) why the
> spacing
> > of taps on the 10BASE-5 "thick" Ethernet cable was required to be an
> exact
> > multiple of 2.5m. It was never clear to me why this was not also a
> > requirement for 10BASE-2 "thin" Ethernet.
>
> Yes, to avoid false alarms.  The purpose of the spacing rule is to ensure
> that there is enough signal integrity that you do not get spurious
> collision indications due to reflections off the impedance variations along
> the cable.  On a segment with few transceivers, there is enough margin that
> the rule doesn't matter.  This is why 10Base-2 doesn't have that rule: the
> station count limit is low enough that it isn't needed.
>

Interesting! I won't disagree with what you're saying, since I'm ignorant
of these details, but in my experience 10BASE-2 networks usually had far
_more_ nodes on a network than any 10BASE-5 network I saw. I routinely saw
over 100 nodes on a 10BASE-2, but I never saw more than 20 or so on a
10BASE-5. (There certainly may have been larger 10BASE-5 networks; I only
ever saw about a dozen 10BASE-5 networks.)

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Tue, Jun 26, 2018 at 8:13 PM, Jon Elson  wrote:

> On 06/26/2018 06:20 PM, Eric Smith via cctalk wrote:
>
>> On 06/26/2018 03:15 PM, Grant Taylor via cctalk wrote:
>>
>>> I can only guess that having a terminator too close interferes with or
>>>> weakens the signal too much in some way.
>>>>
>>>
>>> No, I think it may have something to do with properly detecting all
> collisions.  There are a whole bunch of special cases, where short packets
> have crossed in the middle of a segment.  This causes a collision at the
> nodes in the center of the segment, but the nodes at the ends see their own
> transmissions without interference.


Collision detection was the reason (or at least _a_ reason) why the spacing
of taps on the 10BASE-5 "thick" Ethernet cable was required to be an exact
multiple of 2.5m. It was never clear to me why this was not also a
requirement for 10BASE-2 "thin" Ethernet.


> Possibly, having the terminator too close to (one of) the sending nodes
> might make this detection less reliable.   Hmmm, but really, anything that
> goes past the last tap toward the terminator ought to just DISAPPEAR, so
> that the length beyond the tap should not matter.


Yes. I don't recall that that 10BASE-5 had any restrictions on the length
between the last tap and the terminator.

Ethernet trivia: the DIX Ethernet standard (predecessor of IEEE 802.3)
would have used a 20 Mbps data rate, but the available CRC-32 chips didn't
run that fast.

Re: Thicknet/10base5 Test Segment: The Cable is In!

[Eric Smith via cctalk]

On Tue, Jun 26, 2018 at 4:37 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> On 06/26/2018 03:15 PM, Grant Taylor via cctalk wrote:
>
> > I can only guess that having a terminator too close interferes with or
> > weakens the signal too much in some way.
>
> Exactly what would the effect be?  I recall putting terminators on
> 10base2 coax just hanging off one leg of a BNC tee.  Really, no distance
> at all.  Didn't seem to affect speed or distance.


If the termination resistance matches the characteristic impedance of the
cable, there should be no difference. When terminated properly, there is no
reflection from the terminator, so it looks equivalent to an infinitely
long cable, though in practical terms with less leakage than an "actual"
infinitely long cable would have.

Of course, in reality it will never be terminated perfectly, so there will
always be a small reflection, which can be seen with a TDR. If the
termination resistance is pretty close, the reflection will be small enough
not to matter at all for Ethernet.

Re: 6800 fig-FORTH?

[Eric Smith via cctalk]

On Sat, Jun 23, 2018 at 1:16 PM, Stephen Pereira via cctech <
cct...@classiccmp.org> wrote:

> Has anyone here ever seen or ever had fig-FORTH for the 6800 working?
>

In the mid-1980s I know someone with a WaveMate 6800 system. He had
fig-Forth running on FLEX.  At the time I was only interested in the Apple
II, DEC PDP-10, and BSD 4.x on VAX, so I didn't pay much attention to his
system.

I had problems similar to what you describe when I was bringing up the PACE
version of fig-Forth, and tracked down and fixed a serious bug in the
published listing. AFAICT, I am the only person other than the author who
ever ran the PACE version. I found it far easier to debug on a simulator
rather than the real hardware.

The 6800 version must surely have been far more popular than the PACE
version, so it seems somewhat unlikely that there would be a huge defect in
the published listing, but it's not impossible.

I wrote some 68HC11 assembly professionally in the late 1980s, but the only
actual 6800 code I've writen was a 6800 version of the Apple I monitor.
Writing 6800 code after being used to the 68HC11 and 6809 was a huge step
backward; I kept trying to use newer instructions and addressing modes that
the 6800 did not have.  I have a non-working Electronic Product Associates
Micro 68; maybe someday I'll fix it up.

Eric
N2ES

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Tue, May 29, 2018 at 1:10 AM, Eric Smith  wrote:

> On Fri, May 25, 2018 at 3:30 PM, Adrian Graham via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Wow, good spot! This one isn’t badged but we just assumed it had fallen
>> off. Just as I’m typing this he’s messaged me to say it’s actually the
>> ADM-3A ‘10th Anniversary edition’. The manual is on bitsavers:
>>
>
> It might have _started_ its life as an ADM-3A 10th Anniversary Edition,
> but it isn't one any more. The PCB in the photo is the Zentec ADM3 Retrofit.
>

I may have been completely wrong about that. When I wrote that, I wasn't
aware that Zentec bought the terminal product line from Lear Siegler in
1986, and continued making some of the terminals, including the ADM-3A,
under the Zentec name. Since the LSI ADM-3A was introduced in 1976, It's
possible that Zentec introduced the ADM-3A 10th Anniversary Edition with
the NS405-based logic board.

Eric

Re: Lots of old DEC stuff

[Eric Smith via cctalk]

On Fri, Jun 15, 2018 at 1:15 PM, Ethan Dicks via cctalk <
cctalk@classiccmp.org> wrote:

> I have one but have never found a source of patch cables/bare pins.
>

IIRC, mini-banana (2.6mm) plugs and patch cables are suitable.

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Wed, Jun 6, 2018 at 12:42 PM, Kyle Owen via cctalk  wrote:

> I have this development board with an NS405 on it. Checked through my docs
> and don't seem to have anything for it. Would dumping the EPROM be of
> interest?
>

>From the hand-written label on the EPROM, I suspect that it's not the
original code the development board shipped with, but sure, it would still
be interesting to look at the code.

Re: CDC 6600 display character generation

[Eric Smith via cctalk]

On Wed, Jun 6, 2018 at 9:20 AM, Toby Thain via cctalk  wrote:

> On 2018-06-06 9:48 AM, Noel Chiappa via cctalk wrote:
> > (BTW, the VT11 in DEC's GT40 used bit maps for its built-in character
> geneator,
> > and the hardware did tiny raster zones to display them!)
>
> As does the PDP-1 (point plotting, 5x7 I think).
>

Some variants of the Type 30 display, used on the PDP-1 and other early DEC
computers, included a Type 33 character generator option, which works as
you describe. The computer sends two 18-bit words, which are interpreted as
a 5x7 bitmap, with the leftover bit used to shift the character slightly
for a subscript.

The Type 30G display has the Type 33 character generator as a standard
feature. The PDP-1 at the Computer History Museum has a 30G, but the
character generator is not completely working.  I suspect that most PDP-1
installations did not have the character generator.  There is not known to
be any surviving PDP-1 software that used the character generator; I wrote
simple test programs we used to attempt to debug the hardware.

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Tue, Jun 5, 2018 at 7:38 PM, Jon Elson  wrote:

> I wrote a disassembler for the NS405/NS455 in Pascal on my CP/M system, in
> 1985.
> If this code would be of any use, I can let you have it.  I'm guessing
> this was written for the UCSD Pascal system as run under CP/M.  I have no
> idea how easy it would be to get it running on a modern Pascal compiler.  I
> have had really good luck bringing up some old Pascal programs from Borland
> Turbo pascal and VAX Pascal with the Linux FPC (Free Pascal Compiler).
>
> I also have a cross-assembler for the NS405/455 written in Pascal.


Sure, if you've got them handy, I'll try compiling them with FPC. Are you
willing to release them as open source?

Do you have any actual NS405/NS455 code that would be of interest?

Re: Parts help - need flight SRAMs

[Eric Smith via cctalk]

On Tue, Jun 5, 2018 at 8:47 AM, Tapley, Mark via cctalk <
cctalk@classiccmp.org> wrote:

> I have a need at work for an unusual SRAM chip (related to the New
> Horizons mission).
> if you have a source or supply of these parts:
> Part #=5962H9954103QXC
>

That's not a chip, it's a hybrid multi-chip module. Probably just about
unobtanium now. If a datasheet is available, it wouldn't be hard to
engineer a form/fit/function replacement, if it's for ground support and
you don't need radiation-hardened or mil-spec.  If no datasheet, could
design from schematics of board it is used on.  If no datasheet and no
schematics...

Re: RC25 (was Re: Modifying microcode)

[Eric Smith via cctalk]

On Tue, Jun 5, 2018 at 12:53 PM, Robert Armstrong via cctalk <
cctalk@classiccmp.org> wrote:

>   AFAIK the LESI ("Low End Storage Interconnect") protocol is not
> documented anywhere, unlike SDI or MASSBUS which are.  If it is, I've never
> found it.  I have several UNIBUS KLESI boards and I've often thought the
> same thing, but I'm not really interested in trying to reverse engineer the
> protocol w/o documentation.
>

There's SDI protocol documentation?

Re: Modifying microcode

[Eric Smith via cctalk]

On Fri, Jun 1, 2018 at 11:08 AM, Robert Armstrong  wrote:

> >Eric Smith  wrote:
>
> >The control stores of the 11/785, 8600, and 8650 were entirely WCS.
> >
> >All other VAXen had (relatively) large ROM control store and tiny WCS or
> >patch store.
>
>   You forgot the 11/730 and 725.  The KA730 used 2901 bit slicers and the
> control store was entirely in RAM.  After power on it was a paperweight
> until the 8085 CFE loaded the microcode.


Thanks for the correction! I've never used those models.

Re: M6809E/63C09E databus behavior question

[Eric Smith via cctalk]

On Thu, May 31, 2018 at 10:48 PM, Jim Brain via cctalk <
cctalk@classiccmp.org> wrote:

> I agree this is very specific, but I thought perhaps someone could help.
>
> As I look at the '09 datasheets, I can't tell when the data lines become
> valid on a write cycle.
>

In the MC68x09E datasheet, that is parameter 20, which is the from the
rising edge of the Q clock to write data valid. In the HD68x09E datasheet,
it is t(DDW)

MC6809E:  maximum 200ns
MC68A09E:  maximum 140ns
MC68B09E: maximum 110ns
HD63B09E: maximum 110ns
HD63C09E: maximum 70ns

Note that these times guarantee that as long as your clock timing is within
specifications, the write data will be valid at least slightly before the
rising edge of the E clock.

If you need to know the specifically how much time the write data is valid
before the rising edge of the E clock, you can derive that based on the
clock frequency you're using.

Either of the modified equations works, but I don't know if can safely
> place data on the external databus during the entire cycle, like the
> address lines, or if I need to be off the bus for some small portion of the
> cycle.  I was hoping the datasheets could help, but I am missing the key
> portion of the timing diagrams.
>

If you drive the data bus too soon after the falling edge of E, you might
have contention with whatever chip was driving the data bus in the previous
cycle.

I have never seen a design using a 6800/6500-style bus that depends on the
write data being valid more than a few ns before the rising edge of E
(phase 2 for 65xx).

Best regards,
Eric

Re: Hams and old computer stuff (Re: old DEC stuff)

[Eric Smith via cctalk]

On Thu, May 31, 2018 at 8:13 AM, Jon Tabor via cctalk  wrote:

> A bit unrelated, and I'm fairly new to this list, but interesting to see
> so many ham radio operators pop up.
>

Boat anchors have always been popular with hams!

Re: Modifying microcode

[Eric Smith via cctalk]

On Wed, May 30, 2018, 20:26 Jon Elson via cctalk 
wrote:

> The early 780 had most microcode in ROM, and had a small
> writable control store for special OS-required options and
> patches.  Later machines had more WCS, but I think they
> still had some non-writable control store.
>

The control stores of the 11/785, 8600, and 8650 were entirely WCS.
Probably the so-rare-as-to-be-almost-nonexistent 9000 series had entirely
WCS as well.

All other VAXen had (relatively) large ROM control store and tiny WCS or
patch store.

Re: Modifying microcode

[Eric Smith via cctalk]

On Wed, May 30, 2018 at 10:48 AM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> Didn't the 780 get its microcode loaded by the console LSI-11?


Only the small microcode patch store was loaded. Most of the 11/780
microcode was in bipolar PROMs. The later 11/785 had all of the microcode
in RAM loaded by the LSI-11.

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Fri, May 25, 2018 at 3:30 PM, Adrian Graham via cctalk <
cctalk@classiccmp.org> wrote:

> Wow, good spot! This one isn’t badged but we just assumed it had fallen
> off. Just as I’m typing this he’s messaged me to say it’s actually the
> ADM-3A ‘10th Anniversary edition’. The manual is on bitsavers:
>

It might have _started_ its life as an ADM-3A 10th Anniversary Edition, but
it isn't one any more. The PCB in the photo is the Zentec ADM3 Retrofit.

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Fri, May 25, 2018 at 1:58 PM, Adrian Graham via cctalk <
cctalk@classiccmp.org> wrote:

> Hi folks,
>
> A friend of mine has said ADM-3A and is baffled by the tiny board it
> contains, not the usual ‘covering entire base’ discrete logic board they
> normally have. Centre of this board is the Nat Semi NS405 ‘display
> processor on a chip’ which is obviously why the board is so small but
> neither of us have seen this before in a 3A.
>
> Anyone else? Pic at http://www.binarydinosaurs.co.uk/tonyADM3a.jpg <
> http://www.binarydinosaurs.co.uk/tonyADM3a.jpg>
>

That's the Zentec ADM3 retrofit:
http://bitsavers.trailing-edge.com/pdf/zentec/Zentec_ADM3_Retrofit/

Re: Weird Lear-Siegler ADM-3A board

[Eric Smith via cctalk]

On Sun, May 27, 2018 at 3:10 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> I decided I'd do an article about the Term-Mite for the CHWiki; I found
> Ciarcia's long article about the Term-Mite (in his book, which Google books
> has); it talks throughout the article about the NS455 - but it also says
> "[t]he Term-Mite actually uses a NS405 chip which is a specialized version
> of
> the generic NS455".
>

The NS455 has firmware in masked ROM, which it uses if the EA pin is low.
If EA is high (min spec 3.8V, normally tied directly to Vdd), external
memory (usually ROM or EPROM) must be used instead.

The NS405 has the masked ROM disabled, so external firmware must be used,
and EA must be tied high. It is actually the same die with unspecified ROM
content, so it probably would execute some sort of internal firmware if EA
was low, but that might or might not be the same as the standard NS455
firmware; it could be firmware from a custom version of the NS455, or test
firmware, or (less likely) any of the above but with some errors due to
mask defects.

I've been searching for the NS405 manual (not the datasheet) for a very
long time.

Re: HP Series 9000 early 1980’s computer hardware

[Eric Smith via cctalk]

On Thu, May 17, 2018, 17:57 Ed Sharpe via cctalk 
wrote:

> Is HP UX that it  runs similar  to what is on the HP INTEGRAL ?
>

No, the fake-Unix-on-HP-Sun-OS HP-UX was only on the 9000/500 series. All
the other HP-UX versions are "normal".

Re: Unknown CDC unit , looks like a drum memory ?

[Eric Smith via cctalk]

On Thu, May 17, 2018 at 12:47 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> If your email program is crapping, it is not the responsibility of
> everybody else to "adjust" their mail readers to filter out the crap.
> This group has been remarkably tolerant of NON-ASCII content.
>

I generally agree, but at least "quoted-printable" is a _standard_
encoding, and not some totally random brokenness.

Re: Intel 3000 series

[Eric Smith via cctalk]

On Fri, May 4, 2018, 20:39 allison via cctalk  wrote:

> On 05/04/2018 09:16 PM, dwight via cctalk wrote:
> > I'm not sure how much good a 2900 assembler would be for a 3000 series
> part. The 2900 has an address controller more like a typical micro
> computer, while the 3000 is more like playing a game of chess.
>

There seems to be the presumption the bit slices have a uniform organization
> like a micro.  They generally don not.


AMDASM is a metaassembler; it has no such presumption.

  The

 opcodes and micro code are
> assigned
> and created by the developer and their minions along the lines of some
> architecture they wish to create.  they tend to have a pattern and thats
> about it.
>

AMDASM works fine with that. It can even support bitfields that are
discontiguously stored in the microword.

Re: Intel 3000 series

[Eric Smith via cctalk]

On Fri, May 4, 2018 at 2:10 PM, Kyle Owen  wrote:

> I assume it's one of these? http://www.bitsavers.org/bits/AMD/AM29/
>
Any tips on how to get it running in SimH or the like? I don't see any text
> file describing the system or format.
>

Should be in there somewhere. The IMD files are ImageDisk format. The ZIP
files contain the extracted CP/M files.  I ran it some years ago but don't
recall the details.

Some time ago I started working on an AMDASM clone written in Python 3, but
>> it's not yet far enough along to be useful.
>>
>
> Sweet! I wonder if there is enough in the way of microcoded stuff that a
> microdisassembler wouldn't be handy as well. Does something like that
> already exist?
>

I haven't heard of a general-purpose microcode disassembler. I wrote a
custom disassembler for the Atari Am2900-based "Math Box" used in
Battlezone, Red Baron, and Tempest, and a few others for even more obscure
machines.

Re: Intel 3000 series

[Eric Smith via cctalk]

On Fri, May 4, 2018 at 8:49 AM, Kyle Owen via cctalk 
wrote:

> Does anyone have any software for developing for the Intel 3000 series? I
> bought some parts on eBay and am contemplating a bit-slice PDP-8 or DG Nova
> for fun.
>
> Bitsavers has some 3000 series manuals, but I can't seem to find any "bits"
> of software. Looks like CROMIS is the cross microprogram assembler, which
> looks like it would've run on an MDS-800.
>

Signetics also had a microassembler for the 3000 series, "Signetics Micro
Assembler", also written in FORTRAN, and not compatible with CROMIS.

If CROMIS doesn't still exist, I'd suggest AMDASM on CP/M. It's on
Bitsavers. It is a general-purpose metaassembler, not in any way
specialized for AMD parts (e.g., 2900 series).

Some time ago I started working on an AMDASM clone written in Python 3, but
it's not yet far enough along to be useful.

Re: TRS-80 Fragmentation

[Eric Smith via cctalk]

On Thu, Apr 26, 2018, 15:59 Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> I believe the Z-80 was subordinate to the M68K.


In high-level conceptual term, maybe, depending on the software.

In term of the actual capabilities of the hardware, the Z80 was firmly in
control of _everything_ in the machine, including control over the MC68000,
while the MC68000 had no direct control over anything but its MMU (built
from TTL) and memory. If code running on the MC68000 wants to talk to
anything at all, disk, tape, console, printer, serial ports, etc., all it
can do is politely request that of the Z80. In that sense it's like the CPU
of a CDC 6600, which can't do anything without the PPUs

The Model 16 was developed
> independently of the Model II.


The Model 16 was developed as an expansion of the already-existing Model
II, with a few other changes like half-height floppy drives that were later
implemented on the Model 12 also.

Re: Rick Dickinson, ZX Spectrum designer, RIP

[Eric Smith via cctalk]

On Thu, Apr 26, 2018 at 3:11 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, 26 Apr 2018, Eric Smith via cctalk wrote:
>
>> Those Microdrives were such a Cheese design.
>>
>
> The American Cheese Society (industry association) would probably resent
> that comparison


I was referring to a different, non-comestible Cheese. What I stated about
the Microdrives was literally true, not a metaphor.

Re: Rick Dickinson, ZX Spectrum designer, RIP

[Eric Smith via cctalk]

On Thu, Apr 26, 2018 at 3:03 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> Apple][ was $1298, and discounts were very rare.
> TRS-80 at $599 was less than half the price.
> Pet at $795 was barely more than half the price.
>

By connecting a CCTV monitor, I got my TRS80 new for $399.
>

The Apple II at $1298 didn't include a monitor, either, so it was actually
closer to $1500 when compared to the $599 TRS-80 or $795 PET.  One could
argue that the buyer did get significant additional value with the Apple II
in some regards, but if you were on a tight budget, the Apple II wasn't the
right machine.

By the US govt's figures, $1298 back then is equivalent to $5310 today.
Even if it was mostly better than the competition, how many of us would be
able to buy a $5300 computer today?

Re: Rick Dickinson, ZX Spectrum designer, RIP

[Eric Smith via cctalk]

On Thu, Apr 26, 2018 at 2:37 PM, Liam Proven via cctalk <
cctalk@classiccmp.org> wrote:

> The QL was a weird machine. It predated the Mac by a matter of weeks and in
> crude spec terms was comparable -- 128 kB RAM, 68008 vs 68000, 2 x 100 kB
> Microdrives versus 1 x 400 kB floppy. The QL did sound and colour, mind.
>

Those Microdrives were such a Cheese design.

new disassembler vs IDA (was Re: 8085 Dissasembly?)

[Eric Smith via cctalk]

On Wed, Apr 18, 2018 at 8:17 PM, Mark J. Blair via cctech <
cct...@classiccmp.org> wrote:

> Some of the future reverse engineering projects I have on my to-do list
> involve the CDP1802 processor, which IDA presently doesn't support. When I
> get to them I'll have to decide whether to use dismantler vs. learning how
> to add CDP1802 support to IDA. I'm leaning towards the latter, because IDA
> is so much fancier than dismantler is.


I'd vote for adding it to dismantler.

I had an IDA Pro license at one point, but I seem to have misplaced it, and
it is too old to get me any discount on a new release.  I imagine that IDA
has probably improved a lot since back then, but at the time it had a
pretty awful user interface.

If I had an actual business need to reverse-engineer something using a
processor that IDA supported, I'd certainly buy a new IDA license, but I
wouldn't personally invest any time in building add-ons for expensive
commercial software, when there are open source alternatives that may not
be as good, but are generally good enough.

For the 1802, I've used a really crude disassembler written in C. The 1802
instruction set isn't very complicated, so a disassembler for it isn't
either.  It's been so many years since I actually disassembled 1802 code
that I'm not sure I still have the disassembler around.

Re: Intel HEX formats

[Eric Smith via cctalk]

On Thu, Apr 19, 2018 at 1:45 PM, Dennis Boone via cctalk <
cctalk@classiccmp.org> wrote:

>  > Based on what I find in format83.c, this shouldn't be too much
>  > trouble, but I really want to know what "Intel HEX 83" is supposed to
>  > mean.
>
> The easily findable specification document for "intel hex", which has
> intel branding and copyright, is revision A and dated 1988, so perhaps
> "83" is a reference to the original version's year of publication.
>

The format is much older than that, and although it's possible that there
may have been a 1983 edition of that document, it seems more likely that
the author of the software in question chose 83 because that was the format
number that Data I/O assigned for use with their device programmers. Data
I/O refers to it as "Intel Intellec 8/MDS". Here's a list of Data I/O
formats recognized by the UniSite/2900/3900 family programmers:

http://ftp.dataio.com/main/Manuals/UniFam/Translation%20Formats.pdf

Re: Speed now & then

[Eric Smith via cctalk]

On Tue, Apr 17, 2018 at 8:18 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> thousands of movies and TV episodes will fit on a 2TB drive.
> I am anxiously awaiting higher capacity thin 2.5" SATA.
>

You can get an 8TB drive in 2.5" form factor, but it doesn't contain
spinning rust, and it costs around $6000.

Re: 8085 Dissasembly?

[Eric Smith via cctalk]

On Tue, Apr 17, 2018 at 9:12 AM, allison via cctalk 
wrote:

> Looked at 8086 and decided it was a 8080 with a bag on the side.
> It was and still is irrational.
>

With the 386 architecture (32-bit), they actually cleaned it up quite a
bit.  I won't go nearly so far as to say that 386 is elegant, but when
running in 32-bit mode with flat addressing it's nowhere near as awful as
16-bit 8086 and 286.  AMD did a pretty good job of further extending that
to 64-bit.  However, it does keep accumulating ever more bags on the side.

I hope RISC-V eventually drives a stake through it.

Re: 8085 Dissasembly?

[Eric Smith via cctalk]

On Mon, Apr 16, 2018 at 7:29 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> Disassembly is never lots of fun,
>

Some of us might disagree.
But then, some of us might be masochists.

Re: motorola's chip page

[Eric Smith via cctalk]

On Mon, Apr 16, 2018, 06:35 David Griffith via cctalk 
wrote:

>
> Does anyone know where Motorola's current production chips are described?
> http://www.motorola.com/General/prodport.html only partially works and
> search is entirely broken because http://search.motorola.com no longer
> exists.
>

Motorola isn't in the semiconductor business, and hasn't been for many
years!

The semiconductor business was spun off as Freescale Semiconductor, which
spit out the discrete and logic business as On Semiconductor. Since then,
NXP (formerly Philips) bought Freescale, and On merged with Fairchild (spun
off from National).

Re: Speed now & then (Space and time?)

[Eric Smith via cctalk]

On Wed, Apr 11, 2018 at 6:04 PM, ben  wrote:

> On 4/11/2018 5:21 PM, Eric Smith wrote:
>
>> On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk > > wrote:
>>
>> The FREE fpga development software is only under windows.
>>
>> Xilinx and Altera (now Intel) FPGA development software, including the
>> "free" editions, have run under Linux for many years now. I routinely use
>> them on Fedora and CentOS.
>>
>

> Any PCB designs I build will use through the hole parts, thus 22V10's will
> be my biggest programable device.


Sorry, I thought we were talking about FPGAs.

Re: Speed now & then (Space and time?)

[Eric Smith via cctalk]

On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk 
wrote:

> The FREE fpga development software is only under windows.
>

Xilinx and Altera (now Intel) FPGA development software, including the
"free" editions, have run under Linux for many years now. I routinely use
them on Fedora and CentOS.

The Xilinx Vivado WebPack software supports the entire Artix-7 product
line, which covers a pretty wide range of device sizes. Xilinx ISE WebPack
supports Spartan 3, Spartan 6, and CPLD devices.

5.25- inch alignment disk needed

[Eric Smith via cctalk]

I find myself in need of a 5.25-inch alignment disk. A few years ago
someone mentioned a source for those, but I can't seem to find it. Is there
still a source, or does anyone have one they'd be willing to sell?

I could use an 8-inch alignment disk also, but don't need that as urgently.

Re: CXY08 and DELQA compatible with 2.11bsd?

[Eric Smith via cctalk]

On Fri, Mar 30, 2018 at 1:08 PM, Glen Slick via cctalk <
cctalk@classiccmp.org> wrote:

> Are there any hardware differences between the M7516 non-turbo and the
> M7516-YM turbo versions of the DELQA, or only firmware differences?
> Can you convert a non-turbo version into a turbo version just be
> replacing the firmware EPROM?
>

The non-turbo I've seen use an AMD Lance ethernet chip (Am7990), while the
turbo I've seen use a DEC chip in its place. Could be important, or could
be coincidence.

Re: PATA hard disks, anyone?

[Eric Smith via cctalk]

On Tue, Mar 27, 2018 at 10:19 AM, Ethan via cctalk 
wrote:

> and well... let's just say that "newer" used disks with 4 years on them
> aren't very reliable.
>

If anyone wants some Seagate ST3000DM001 drives (3TB SATA), I've got extras!
:-(

Re: LSI11 CPU Microm

[Eric Smith via cctalk]

On Sat, Mar 24, 2018 at 1:31 PM, Douglas Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I was trying to put together a minimal PDP-11/03 using a quad width M7264
> CPU and got nothing, no ODT prompt.  I'm not sure the board is working.
> [...]
> Quoting the page; "Using a logic analyser showed that the MICROM without
> label is not behaving well."
> Anyone know how a logic analyser would be used to determine this?  Other
> hints to debug this board?
>

I don't know an easy way. I built a custom MICROM reader a few years ago
that I've used to dump the LSI-11, WD16 (Alpha Micro AM100) and WD Pascal
Microengine MICROMs.

Re: R.I.P. Robert T. "Doc" Suding

[Eric Smith via cctalk]

http://m.legacy.com/obituaries/denverpost/obituary.aspx?n=robert-suding=187748166

R.I.P. Robert T. "Doc" Suding

[Eric Smith via cctalk]

I just learned from the April 2018 issue of QST that Robert T. "Doc"
Suding, W0LMD, has died. Suding cofounded and was chief design engineer of
The Digital Group, an early microcomputer company in Denver (1974-1979).

Re: FS: Early Revision Commodore 64 computers

[Eric Smith via cctalk]

On Mon, Mar 19, 2018 at 12:55 AM, Sellam Ismail via cctalk <
cctalk@classiccmp.org> wrote:

> In the continuing saga of sorting through a big batch of Commodore stuff
> from my collection, I've listed 6 different early revision Commodore 64
> computers for sale.
>

What?!

Don't tell me you've given up on making supercomputing cluster out of C64s?

Re: XT/370 microcode

[Eric Smith via cctalk]

On Mon, Mar 12, 2018 at 10:54 AM, emanuel stiebler via cctalk <
cctalk@classiccmp.org> wrote:

> On 2018-03-12 15:49, Eric Smith via cctalk wrote:
> > As the most obvious example of the impedance mismatch between 370
> > architecture and 68000 microarchitecture, the 68000 is hardwired to have
> > eight each data and address registers, not sixteen GPRs, and microcode
> > can't easily paper over that.
>
> I wouldn't bet on that ...
>

I'm fairly sure of it, based on microarchitectural details in the US
patents on the 68000 design.

Re: XT/370 microcode

[Eric Smith via cctalk]

As the most obvious example of the impedance mismatch between 370
architecture and 68000 microarchitecture, the 68000 is hardwired to have
eight each data and address registers, not sixteen GPRs, and microcode
can't easily paper over that.

Similarly, the 8087 microarchitecture has hardwired support for binary
floating point normalization, and microcode can't efficiently force that to
do radix 16 normalization.

Both problems could be surmounted (inefficiently) with enough microcode,
but the chips were designed with no significant extra microcode ROM and PLA
capacity.

Re: XT/370 microcode

[Eric Smith via cctalk]

On Mon, Mar 12, 2018, 05:13 Dave Wade via cctalk 
wrote:

> . Wikipedia says there were/are
> 2x68000 CPU's..
>

One Motorola chip was the custom one, the other was normal (as indicated by
mask code). There was also an Intel math co, presumably derived from 8087.

I used to have an AT/370, which had the same chipset, but I was never able
to obtain the software.

I very strongly suspect the modified 68000 and 8087 have more than just
microcode differences, and that full reverse-engineering of the die would
be necessary to accomplish anything useful with the microcode. Neither chip
was designed to be a general-purpose microcode engine; both were very
heavily tailored for their exact visible architecture, and 370 architecture
is enough different that it couldn't be implemented by microcode only
changes with no data path changes; the microcode ROMs and PLAs just aren't
big enough to work around the data path issues.

Re: WTB Intel 7110 Bubble Memory Subsystem or Chipset

[Eric Smith via cctalk]

On Fri, Feb 23, 2018 at 10:23 AM, Jon Elson via cctalk <
cctalk@classiccmp.org> wrote:

> The original bubble memories were sort of dead end, but applying more
> advanced semiconductor lithography to them, going to vertical Bloch-line
> memory architecture, and such could have given them a lot more life, at
> least.  But, when IBM pulled out of the advanced research on it,
> development just stalled


I don't know what "vertical Block line memory architecture" is, but more
advanced lithography wasn't sufficient, because the size of useful magnetic
domains couldn't be scaled down much smaller than what was used in the
4Mbit devices, no matter how fine your lithography was. The lithography was
not the limiting factor. That's why Intel spun off their magnetics division
to continue manufacture and sales of what they recognized as a dead-end
product line.  It was still viable for some years as a niche product in
applications where the requirement for physical robustness was far more
important than either density or price.

Re: WTB Intel 7110 Bubble Memory Subsystem or Chipset

[Eric Smith via cctalk]

On Thu, Feb 22, 2018 at 3:39 PM, Mark J. Blair via cctalk <
cctalk@classiccmp.org> wrote:

>
> I've seen those instructions. As I understand it, I may need to do that to
> restore a module to operation if it's lost its seed. But if that has
> happened to either of the two modules in my firmware cartridge already,
> then it's all over.
>

Yes. However, unless someone deliberately tried to erase the module,
there's no particular reason to think that such a problem has occurred. The
things are very robust, which is exactly why the military liked them so
much.

Re: WTB Intel 7110 Bubble Memory Subsystem or Chipset

[Eric Smith via cctalk]

On Thu, Feb 22, 2018 at 2:28 PM, Mark J. Blair via cctalk <
cctalk@classiccmp.org> wrote:

> Is my understanding correct that removing the entire 7110 module as a unit
> (whether socketed or soldered in) should be somewhat safe, but any attempt
> to disassemble the module would likely disturb the bias field and destroy
> the data?
>

Yes, you can safely remove the entire 7110 without altering the data
within, as long as you don't subject it to strong external magnetic fields.

Re: WTB Intel 7110 Bubble Memory Subsystem or Chipset

[Eric Smith via cctalk]

On Thu, Feb 22, 2018 at 2:23 PM, dwight via cctalk 
wrote:

> Do not remove the chip from the bias magnets. All will be lost if you do.
>

That's true, but AFAIK all commercially produced bubble memory devices,
including Intel (7110 1Mbit, 7114 4Mbit) and TI, the bias magnets are
integral to the packaging of the device, so there's no danger of that
unless you pry apart the device packaging.