[cctalk] Re: Intel 4004

[Eric Smith via cctalk]

On Thu, Nov 23, 2023 at 12:46 AM Sellam Abraham via cctalk <
cctalk@classiccmp.org> wrote:

> The CADC had no program counter: since it was designed from its inception
> to be a multi-processing (multi-threading?) system, it made sense to build
> a program counter onto each ROM.  Therefore, when the CADC switched back to
> that ROM to continue executing instructions, the program counter on that
> ROM told the CADC where it was supposed to fetch the next instruction.
> Once it became clear to Ted that the CADC did not have an integrated
> program counter (though it easily could have) he pooh-poohed the entire
> thing as not qualifying as a single-chip microprocessor
>

The 4004, 4040, 8008, and 8080 have program counters, but if one is picking
nits, they have so much missing that has to be supplied by additional logic
that IMO it's hard to consider them single-chip microprocessors.

And if lack of a program counter is sufficient to disqualify a chip from
being a single-chip microprocessor, then the Fairchild F8 isn't one either.
The F8 CPU (3850) has no program counter or any other address source
on-chip. That's all provided by the ROM chip (3851 or 3856 PSU), or by the
SMI or DMI (static or dymanic memory interface chips). When the F8 CPU
wants to know the value of one of the program counter or data counter
registers, it has to ask the other chips for it! Unlike the CADC, though,
all of the ROMs and memory interfaces in an F8 system kept track of the
same program counter value, so it couldn't do the ultra-fast task switching
of the CADC.

On the other hand, if you don't consider an on-chip program counter as
necessary to be a single-chip microprocessor, then the Motorola MC14500
would qualify as a single-chip microprocessor, and probably the simplest
one ever made.

Eric

[cctalk] Re: Apple 1

[Eric Smith via cctalk]

On Thu, Aug 24, 2023, 20:51 Bill Degnan via cctalk 
wrote:

> The Jolt was the first 6502, how much is that worth?
>

Did the Jolt predate the KIM-1? I don't know their introduction dates.

[cctalk] Re: Apple 1

[Eric Smith via cctalk]

On Thu, Aug 17, 2023, 21:27 Chuck Guzis via cctalk 
wrote:

> The PACE itself was a re-cast of the NSC IMP-16 chipset.
>

The IMP-16 and PACE architectures were similar (and similar to the DG
Nova), but they weren't binary or source compatible. Apparently NS didn't
think there was enough of an existing IMP-16 software base to worry about
compatibility, and instead tried to take the opportunity to make (minor)
architectural improvements.

A few hobbyists built IMP-16 and PACE/INS8900 computers, and there were
even a few commercial products, e.g. the Pacer microcomputer from Product
Support Engineering.

The IMP-16 and PACE, and even the NMOS INS8900, are very slow. For most
workloads, a 2 MHz 8080 can outperform them.

I've run figForth on a PACE. The published listing had a small but serious
error. The original listing and my fix are on Bitsavers. The author of the
PACE implementation thinks that the listing sent to FIG was by mistake not
his up-to-date working version. Demonstrating the lack of popularity of
PACE, apparently no one ever complained about it until I discovered and
fixed the bug in 2009.

I'd like to modify PACE figForth to run on an IMP-16, but there's a
surprisingly large amount of work required.

[cctalk] Re: Apple 1

[Eric Smith via cctalk]

On Sat, Aug 5, 2023, 08:54 Bill Degnan via cctalk 
wrote:

> The Apple I is not historically significant enough alone to justify
> the prices they get
>

The first product sold by the first company to hit $1T market cap seems
historically significant to me.

AFAIK the Apple 1 was also the first inexpensive (somewhat subjective)
personal computer to include a composite video text display and a parallel
keyboard interface. Such was possible with the PDP-8 and PDP-11/05, but
they were very expensive, and it wasn't a normal configuration. Also
possible with an S100 system, cheaper than a PDP-anything, but still much
more expensive than Apple 1, and had to be configured out of a lot of
pieces.

There are a lot of "firsts" throughout the history of computing, and I'm
sure that there is disagreement over the significance of many, but I think
I'd have a very hard time justifying myself if I claimed the Apple 1 was
not historically significant.

Eric

[cctalk] Re: Wanted: Apple III 5MB Profile HD driver file

[Eric Smith via cctalk]

On Thu, Feb 23, 2023, 08:44 Will Cooke via cctalk 
wrote:

>
>
> > On 02/21/2023 10:48 PM CST Eric Smith via cctalk 
> wrote:
>
> >
> > Profile trivia:
> >
> > The firmware _inside_ the Profile is strange in that it doesn't actually
> > KNOW the size of the Profile it's installed into. At power up, when the
> > drive reads the home block, the drive size is stored there. That's done
> > when the drive is formatted. There is different formatter firmware for
> 5MB
> > and 10MB drives.
>
> I think that was rather common with early SASI/SCSI controller boards that
> were separate from the drive.
>

That was done because the controller manufacturer didn't make the drives. A
system integrator or even the end user was expected to use the controller
with some arbitrarily selected drive.

The Apple Profile was an entire preconfigured  subsystem in a box. Apple
bought the drive mechanism (only, no electronics, not even the normal drive
electronics), built the controller, packaged it, and nothing was
user-upgradeable. It wasn't even considered dealer-upgradeable. The
controller and drive mechanism were permanently associated. If the drive
mechanism failed, service replaced it with an identical mechanism.

The Profile controller could deal with drives with a varying number of
cylinders, hence the existence of both 5MB and 10MB models, but was not
designed to support more heads like a general-purpose SASI bridge.

[cctalk] Re: Wanted: Apple III 5MB Profile HD driver file

[Eric Smith via cctalk]

On Thu, Feb 16, 2023 at 11:28 AM David Schmidt via cctalk <
cctalk@classiccmp.org> wrote:

> Generally, a ProFile driver that is otherwise unspecified will be 5MB
> (i.e. https://apple3.org/iiisoftware.html#drivers ).  There is a
> different card (ROM?) as you found out that will matter for 5 vs. 10MB
> variants and driver files.
>

For the Apple ///, there isn't a different Profile interface card, and
there's no firmware on the card. It's all a matter of what SOS driver is
used. I thought the newer SOS driver supported both 5MB and 10MB drives,
but perhaps I'm mistaken. The drivers generally come from the Apple ///
System Utilities disk and System Utilities Data disks.

For the Apple II, there's an interface card that is used for either the
Profile 5MB or 10MB, but the early firmware 341-0271A, only knows about the
5MB Profile, and also doesn't work with interrupts, so it's not suitable
for the Apple IIgs. The same card, but with 341-0299B firmware, supports
both 5MB and 10MB Profiles and works on the Apple II, II+, IIe, and IIgs.

There are a bunch of places on the internet that claim that you have to use
341-0271A firmware on the Apple II card if you have a 5MB Profile, but that
is flat out wrong. The 341-0299B firmware should be used with both 5MB and
10MB Profiles. It will also work with third-party drives that support
Profile protocol but may have different sizes, potentially up to 32MB.

Profile trivia:

The firmware _inside_ the Profile is strange in that it doesn't actually
KNOW the size of the Profile it's installed into. At power up, when the
drive reads the home block, the drive size is stored there. That's done
when the drive is formatted. There is different formatter firmware for 5MB
and 10MB drives.

The Apple II Profile interface firmware contains a lot of dead code. Some
of it looks vaguely like reasonable code, but some of it is clearly junk.

[cctalk] Re: Bubble Memory

[Eric Smith via cctalk]

On Thu, Oct 20, 2022, 23:29 George Rachor via cctalk 
wrote:

> I remember a bubble memory card being advertise for the Apple ][ but never
> saw one.
>
> Were they ever made?
>

Yes. I have the Helix Labs card.

[cctalk] Re: datapoint 2200 programming

[Eric Smith via cctalk]

On Wed, Oct 12, 2022, 14:54 Steve Lewis via cctalk 
wrote:

> Datapoint 2200 [...] iinstruction set was said to be similar what became
> the
> 8008.
>

The instruction sets weren't similar, they was identical. The Intel 8008
(and TI TMX1795) were designed based on specifications from Computer
Terminal Corporation, maker of the Datapoint brand. CTC chose not to use
either chip in the Datapoint 2200 family, though.

The 8008 instruction set is basically the 8080 instruction set with the
best instructions removed and the opcodes reassigned.

[cctalk] Re: i860 vs. i960 WAS Intel's i860, Cray-On-A-Chip

[Eric Smith via cctalk]

On Fri, Sep 23, 2022, 21:50 Ali via cctalk  wrote:

> I always thought the i960 was an upgrade to the i860 (sort of like i386 to
> i486 upgrade). However, based on the info on wiki it seems as if the i960
> actually came first and although a RISC chip it was in no way in the same
> league as the i860. Anyone can clarify or verify this?


They're totally unrelated, except that they both came from Intel.

The i960 was the BiiN processor, stripped (in most versions) of the tagged
memory and capability architecture. The BiiN processor was an attempt to
keep the "good parts" of the iAPX 432, without the huge performance penalty
of the 432 as compared to "normal" processors (e.g., MC68000). So the i960
basically threw away the BiiN's vestiges of the 432, transforming it into a
"normal" processor. It was successful in embedded applications, such as
laser printer.

I don't know the development history of the i860, but it is not similar in
any way to the i960. There were some Unix workstations based on the i960,
but many sources claim that it didn't meet expectations because of the
exposed pipeline (making compiler development difficult), imprecise
exceptions, and expensive context switching.

[cctalk] Re: 8" disk question!

[Eric Smith via cctalk]

On Fri, Sep 2, 2022, 07:51 geneb via cctalk  wrote:

> The question I have is how did a contemporary system deal with the
> combination of a disk with both index windows and a drive with both index
> sensors?
>

They didn't deal with it at all. It didn't work. No normal 8-inch floppy
disks have both index holes in the jacket. If you convert a disk from SS to
DS, or vice versa, by punching the other index hole in the jacket, you have
to cover the original, unless you're going to use it in a drive that has
only one index sensor (typically an SS drive).

[cctalk] Re: IBM 5100 emulation

[Eric Smith via cctalk]

I've poked around inside the 5100 some years ago, but most of my
information came from the Maintenance Information Manual, and I only
verified a little of it relating to the executable ROS.

The executable ROS is split between a half card in slot H2, which is
required for all 5100 models, and an APL-only executable ROS half card in
slot H4. The most significant address bit (SAB 0) selects between the two.
The BASIC/IO/Diagnostic executable ROS starts at address , and the APL
executable ROS starts at 8000. It appears that the BASIC/IO/Diagnostic
executable ROS occupies most or all of the address space allocated to it,
..7fff space (32KB).

The non-executable ROS cards are:

slot E2 (full size): ROS control, and common and language ROS, all models -
it appears that this is addressed ABOVE (at higher addresses than) the
BASIC ROS
slot C4 (half card):  BASIC ROS
slots C2, D2, D4 (half cards): APL ROS

The MIM shows the non-executable ROS as divided into banks of 30720 bytes
(0x7800). I can believe that the amounts of memory on a particular card
might be related to that, e.g., 15 chips of 2KB each, but the decode on the
ROS Control card is shown as decoding consecutive ranges of that size,
rather than e.g. units of 0x8000. Two decodes go to each non-executable ROS
card, so it appears that the 0x7800 bytes of a bank are not actually
implemented on a single card. Something bizarre seems to be going on, or
possibly the documentation isn't 100% accurate.

I think the non-executable ROS is selected slightly differently than in the
5110. The non-executable ROS is device address 1. The MIM says in one place
that in a control operation, data bit 4 selects common and BASIC, while
data bit 5 selects APL. Bits 4 and 5 come from bits 12 and 13 of the
control microinstuction. I'm not convinced that the logic diagrams match
that description.

Re: Replacement for a DEC 7474 Chip

[Eric Smith via cctalk]

On Tue, May 17, 2022 at 12:35 AM ben via cctalk 
wrote:

> Did DEC not use a few Non TTL chips to reduce I/O loading on the bufferd
> lines?
>

DEC used non-TTL buffer chips for bus interface (Omnibus, Unibus, Qbus, and
external buses like Massbus). Most of the other SSI/MSI logic chips are TTL
or TTL-compatible. TTL buffers were usually used where higher fanout was
needed on a module, or on non-bus backplane connections.

Re: Replacement for a DEC 7474 Chip

[Eric Smith via cctalk]

On 2022-May-15, at 3:53 PM, Eric Smith wrote:
> I specifically said 74x74. Early TTL flipflops were very crude by
comparison.

On Mon, May 16, 2022 at 11:28 AM Brent Hilpert via cctalk <
cctalk@classiccmp.org> wrote:

> pre-TTL != early TTL
>

No, but 7470, 7472, 7473, and 74948  were _very_ early and were also very
crude, as were their later L and H variants. 7474 was slightly later, and
less crude.

It should also be noted that the 7400 series was NOT the first commerical
TTL integrated circuits. The earlier TTL flip-flops were even more crude,
but I imagine the engineers that used them were nevertheless delighted at
the advance over RTL and DTL.

Re: Replacement for a DEC 7474 Chip

[Eric Smith via cctalk]

I specifically said 74x74. Early TTL flipflops were very crude by
comparison.

On Sun, May 15, 2022, 13:03 Brent Hilpert via cctalk 
wrote:

> On 2022-May-15, at 1:16 AM, Eric Smith via cctalk wrote:
> > On Sat, May 14, 2022, 16:09 ben via cctalk 
> wrote:
> >> On 2022-05-14 11:50 a.m., Nigel Johnson Ham via cctalk wrote:
> >>> AFAIR LS can only drive one unit TTL load.
> >>>>paul
> >> LS is 4 TTL, 4 ma low.
> >> Was there a trick of forcing the output of D flip flip
> >> to clear it? I was wondering if this is what kills all
> >> the 7474's?
> >
> > I don't think that worked on any TTL (or CMOS) 74x74 flip flops, except
> > maybe by accident if you shorted the output enough to draw Vcc down (or
> > ground up) enough to disrupt the FF, and then you have other problems.
> >
> > Despite the logic diagram showing feedback from the outputs, all 74x74
> have
> > buffered outputs.
>
> Per TI schematics from 1969: 74 standard, H and L series flip-flops are
> unbuffered. Or at least many of them are/were, in their then-original form.
> Including 7475, 7490, etc. The output transistors connect both to the pins
> and wrap back to form the FF or other purposes.
>
> Collector-triggering was discussed a some years ago on the list in regards
> to a pdp8 front panel where DEC used collector-triggering on 74175's (IMO,
> bad design practice). From (my) empirical tests at the time, it turned out
> some 74S (Schottky) parts could be collector-triggered. However, between
> standard, LS, and S types, behaviour could vary with manufacturer and
> production date.
>
>
> > The recent TI data sheets show an equivalent schematic
> > only for the 74LS74. I can't at the moment find one for the 7474.
>
> > It seems likely to me that early pre-TTL logic families like RTL might
> have
> > had FFs with unbuffered outputs, but I haven't checked.
>
>

Re: Replacement for a DEC 7474 Chip

[Eric Smith via cctalk]

On Sat, May 14, 2022, 16:09 ben via cctalk  wrote:

> On 2022-05-14 11:50 a.m., Nigel Johnson Ham via cctalk wrote:
> > AFAIR LS can only drive one unit TTL load.
> >> paul
> LS is 4 TTL, 4 ma low.
> Was there a trick of forcing the output of D flip flip
> to clear it? I was wondering if this is what kills all
> the 7474's?
>

I don't think that worked on any TTL (or CMOS) 74x74 flip flops, except
maybe by accident if you shorted the output enough to draw Vcc down (or
ground up) enough to disrupt the FF, and then you have other problems.

Despite the logic diagram showing feedback from the outputs, all 74x74 have
buffered outputs. The recent TI data sheets show an equivalent schematic
only for the 74LS74. I can't at the moment find one for the 7474.

It seems likely to me that early pre-TTL logic families like RTL might have
had FFs with unbuffered outputs, but I haven't checked.

Re: Replacement for a DEC 7474 Chip

[Eric Smith via cctalk]

Those should be fine. Only the more complex parts had issues, not the
simple gates.

On Sun, May 15, 2022, 02:04 Rob Jarratt via cctalk 
wrote:

> Oh dear, while I was ordering an original 7474 I ordered some other parts
> that were connected to the same bad chip in case other chips are damaged,
> and I ordered a Fairchild 74LS08! I will ask them to change it for a
> Motorola part they also have.
>
> > -Original Message-
> > From: cctalk  On Behalf Of dwight via
> cctalk
> > Sent: 14 May 2022 23:36
> > To: Paul Koning via cctalk 
> > Subject: Re: Replacement for a DEC 7474 Chip
> >
> > What ever you do, don't use a Fairchild part. When I worked for Intel in
> the
> > 80's, we finally band using Fairchild for any latching device. They
> failed
> on
> > pullup current, even when the parts were sent back and they claimed they
> > were good. We just gave up on them, we couldn't hold production while
> > they figured it out.
> > We had a similar problem with PowerOne, a manufacture of power supplies.
> > Since it was a custom supply, we had to send someone to their plant to
> fix
> > their final test.
> > Dwight
> >
> >
> > 
> > From: cctalk  on behalf of Nigel Johnson
> > Ham via cctalk 
> > Sent: Saturday, May 14, 2022 10:50 AM
> > To: Paul Koning via cctalk 
> > Subject: Re: Replacement for a DEC 7474 Chip
> >
> > AFAIR LS can only drive one unit TTL load.
> >
> > I may have some 7474, even of that vintage, if you cannot find any
> anywhere
> > else.
> >
> > cheers,
> >
> > Nigel
> >
> >
> > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio,
> > the origin of the open-source concept!
> > Skype:  TILBURY2591
> >
> >
> > On 2022-05-14 13:48, Paul Koning via cctalk wrote:
> > >
> > >> On May 14, 2022, at 1:41 PM, John Robertson via
> > cctalk  wrote:
> > >>
> > >> On 2022/05/14 10:11 a.m., Rob Jarratt via cctalk wrote:
> > >>> Hello,
> > >>>
> > >>> I have found a bad DEC 7474 chip on my M7133 board. Clearly it is a
> > >>> 7474 D flip flop. The problem is I don't know which
> > >>> modern series would be the best one to replace it with. I am sure I
> > >>> have seen a list somewhere of modern equivalents for some DEC chip
> > >>> numbers, but I can't remember where.
> > >>>
> > >>> If it helps at all, on the PDP 11/24 printset it is E78 on page K6
> > >>> of the schematic (p157 of the PDF).
> > >>>
> > >>> Picture of the failed chip here:
> > >>> https://rjarratt.files.wordpress.com/2022/05/damaged-dec-7474-4_li.j
> > >>> pg
> > >>>
> > >>> Can anyone tell me what the best modern equivalent is likely to be?
> > >>>
> > >>> Thanks
> > >>>
> > >>> Rob
> > >>>
> > >> You are stuck with using an original 7474 family assuming this is
> driving
> > other early TTL. 74LS74, and others simply don't have the drive
> capability
> to
> > work.
> > > I know LS has less fanout, but is it not able to drive plain 74xx at
> all?  That
> > doesn't sound right.  If the circuit in question runs near the fanout
> spec
> of
> > plain 74 the yes, 74LS won't work.
> > >
> > > Spec sheets and the actual schematic will give a definitive answer.
> > >
> > >paul
> > >
> > >
>
>

Re: HP 54200D oscope practically worthless?

[Eric Smith via cctalk]

On Thu, May 12, 2022 at 12:25 PM Alexander Huemer via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, May 12, 2022 at 02:01:50PM -0400, William Sudbrink via cctalk
> wrote:
> > I picked up one of these in a batch of electronics.  Is it worth
> > repairing/investigating?
>
> The scope does what it is supposed to, you get a time-domain
> visualization of voltage.
> Though, they are awkward to use due to the lack of rotary encoders.
> Scaling horizontally or vertically requires you to go into a menu,
> navigate to the right option, do the actual scaling and go back.
> It's better than no scope at all, but not exactly the model you'd hunt.
>

These appear to be derived from the 1630/1631 logic analyzers, some models
of which have 'scope capability, which works as you've described. They must
have decided to offer models with only the scope and without the logic
analzyer (except for a digital triggering option), which seems like a bad
idea. Probably why I'd never heard of these before.

At the time they were current (early 1980s), the 1630/1631 family were
fairly reasonable logic analyzers, but the 1650/16500, 1660, 1670/16700,
etc. are far better. I wouldn't recommend that anyone _buy_ a 1630/1631
family logic analyzer at this late date, but if someone is giving one
away...

Re: cleaning up edge connectors

[Eric Smith via cctalk]

On Thu, Apr 28, 2022, 15:03 Peter Cetinski via cctalk 
wrote:

>
> TRS-80 guru Ian Mavric sells those gold connectors for the TRS-80.
>
> https://www.ebay.com/itm/164568343523 <
> https://www.ebay.com/itm/164568343523>
>

They're made by Sullins, and may be orderable from Digi-Key and other
distributors. I've bought them from Digi-Key in the past, but I think
Digi-Key may have stopped stocking them.

new Z80 monitor ROM works with no RAM

[Eric Smith via cctalk]

I wrote a new monitor ROM for the Z80, called umonz, which can provide some
basic monitor functionality even if there is no working RAM. In other
words, it doesn't use a stack or store any variables in RAM. It supports
reading and writing memory, I/O ports, and loading and dumping Intel hex
format.

https://github.com/brouhaha/umonz

It's tricky to write any non-trivial Z80 code without a stack. I used IX
and IY as subroutine return address registers, allowing two levels of
subroutines, though a subroutine that uses IX can't call another subroutine
using IX, and similarly for IY.

The background is that John Doran built a custom Z80 (equivalent) computer
system which he calls the Z80/M. It doesn't use an actual Z80 CPU; there is
an Altera (now Intel) MAX 10 FPGA on the control panel board, and a
Z80-equivalent core, along with the front panel logic, is in the FPGA.
There is a 16-slot expansion bus using 96-pin DIN 41612 connectors. The
cards are Eurocard 3U x 220mm.


https://www.flickr.com/photos/_brouhaha_/52032832163/in/album-72177720298429134/

There's an expansion card that provides 512K of flash, 512K of SRAM, page
mapping, a Z80 SIO for two serial ports, and a CF card, all compatible with
the equivalent RC2014 cards.

He expected that ROMWBW and CP/M or ZSystem would "just work". However we
had to track down several minor hardware design issues to get it to work.
After writing a few simple one-off test programs, I got tired of the
assemble, sneakernet, program flash chip, test in target loop, so I decided
to write a monitor. That definitely sped up the debug process.

Re: Memory Tech you don't see very often

[Eric Smith via cctalk]

On Thu, Jan 6, 2022, 01:20 Joshua Rice via cctech 
wrote:

>
> Not cost effective at nearly $10,000! I understand they're very rare,
> given they were only used for a few years in industry and they're
> clocking on 3/4 of a century old, but even then, that seems an order of
> magnitude or two off the real value.
>

The rarity wasn't that only one _model_ of computer used it. Only one
_unit_ used it. It used 80 tubes at a cost of around $500 each, in
mid-20th-century dollars.

Given that they'd have needed some spares and replacements, the production
run would have been more than 80 pieces, but I'd think it unlikely that
more than 250 production units were ever made.

If someone wants one and is able to purchase it for $10,000, I think they
are very lucky.

Re: Memory Tech you don't see very often

[Eric Smith via cctalk]

On Thu, Jan 6, 2022, 08:45 Mike Katz via cctalk 
wrote:

> There was also a 1K by 4 version of this tube.
>

I've never seen any info on a 1K*4 Selectron, but they weren't even able to
make the 4K*1 work, and the only production tubes were 256*1.

Re: 3-phase power

[Eric Smith via cctalk]

On Tue, Jan 4, 2022 at 8:36 PM Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> My limited understanding is that VFDs simulate / emulate various
> frequencies by turning the output on and off (at full input voltage)
> such that the (sliding) /average/ of the output looks like it's a at a
> lower voltage.


That's how all buck switching power supplies work. It's just a question of
how much low-pass filtering you do on the output. A switching power supply
to power sensitive electronics that requires good voltage regulation and
low ripple contains electrolytic capacitors on the output. A VFD may or may
not. The specs on the VFD should tell you about the output characteristics.

If you're just going to power a three-phase synchronous motor, then no
filtering is needed. The inductance of the motor windings and the
mechanical characteristics of the motor will filter it just fine.

Re: VAX 780 on eBay

[Eric Smith via cctalk]

On Sat, Jan 1, 2022, 12:33 Paul Koning via cctalk 
wrote:

> Largely true, but some disk drives (RP06?  RP04?) use 3-phase spindle
> motors.
>

The RP06 has 3-phase power input (and output, phase-rotated, for a second
drive), but uses a single phase spindle motor. The US version runs the
spindle between two phases, nominally 208V, but the motor is rated for
operation on a range that spans 208V and 240V.

Re: Overclocked TI Silent 703 at 1200 bauds?

[Eric Smith via cctalk]

On Mon, Nov 1, 2021 at 8:21 AM Curious Marc via cctalk <
cctalk@classiccmp.org> wrote:

> Yes, I have ruined a few printouts using the isopropanol method ;-) . On
> that subject, can anyone recommend a source for the thermal paper used in
> the Silent?
>

I was able to get suitable thermal paper at Office Max or Office Depot, I
forgot which. I had to ask an employee for "thermal fax paper".

DEC DHU11 (M3105) wanted

[Eric Smith via cctalk]

A friend and I are trying to get a PDP-11/70 running, and we'd like to get
a DHU11 async mux board. Anyone have an extra?

There's an Ebay listing claimed to be a DHU11, but that one is actually a
Qbus M3104.

Prototype new Apple /// memory board

[Eric Smith via cctalk]

I've been working on a new memory board for the Apple ///, using (somewhat)
modern and still-in-production components, especially CMOS static RAM
rather than DRAM. Last night I soldered the connectors, sockets, and
passives of my first prototype:

https://flickr.com/photos/_brouhaha_/albums/72157719738576267

I need to do some testing for shorts, etc. before I attempt to actually use
it in an Apple ///. I expect that some debugging of the design will be
required.

The Apple /// design is _much_ more complex that the Apple II and IIe. I
intended this board to provide 512KiB of RAM, but I've already determined
that some design changes will be required for that, so this prototype will
only support 256KiB.

The early Apple /// design, as documented in US patents, would have
supported up to 512KiB of RAM, but the actual shipped design reduced that
to 256KiB. There was a third-party 512Kib emory board from "On Three",
which required pulling various chips from the motherboard and running
cables from those to the memory board.

The SOS operating system, as shipped, only supported 256KiB. On Three
modified the SOS bootloader to detect and use 512KiB. Some Apple ///
application software also had trouble with 512KiB, and On Three patched
some of those.

Re: C.mmp OS

[Eric Smith via cctalk]

On Mon, Aug 23, 2021, 03:15 Liam Proven via cctalk 
wrote:

> On Sun, 22 Aug 2021 at 23:42, Fred Cisin via cctalk wrote:
> > If "drugs, sex, and rock'n'roll" is not the answer,
> > then you are asking the wrong question.
>
> While I cannot disagree with my learned friend's proposition, I
> increasingly find that my drug of choice is ibuprofen these days. :-/
>

At USENIX conferences, at some point the "sex, drugs, and Unix" buttons
gave way to "condoms, aspirin, and POSIX" buttons.
:-(

>

Re: Extremely CISC instructions

[Eric Smith via cctalk]

On Wed, Aug 25, 2021, 09:50 ben via cctalk  wrote:

> On 2021-08-25 1:25 a.m., Eric Smith via cctalk wrote:
> >
> > 432 GDP instructions were bit-aligned in an instruction object, and
> > occupied anywhere from 6 to 344 bits.
>
> Did not the IBM 7030 try a similar idea.
> All this work to replace a punched card.
> Funny how records where simple on decimal computers
> and are mess on binary ones.
>

The IBM 7030 "Stretch" and the TI TMS34010 and 34020 processors support
integer data on arbitrary (unaligned) bit boundaries, but instructions and
floating point data are required to be aligned.

The 432 GDP uses unaligned, variable bit length instructions, but requires
data to be byte-aligned, and access descriptors (which are object pointers
and capabilities) to be 32-bit aligned

Anyone remember Kel-Am connectors?

[Eric Smith via cctalk]

When I worked at Apparat around 1981, we used a lot of *male* IDC edge card
connectors. I've almost never seen any since, and I couldn't remember the
name of the vendor. I just found out that it was Kel-Am, but the internet
knows almost nothing about them.

Here's an example:
https://www.elliottelectronicsupply.com/connectors/card-edge/male-card-edge-idc-connector-34-position-kel-am-idc34m.html

That photo doesn't show the Kel-Am logo, which is just a stylized "KEL-AM".
There are some eBay auctions of the corresponding female connector (which
other vendors did make), some of which show the logo.

I wonder what happened to Kel-Am. Maybe they were acquired, maybe they went
under. It would be nice to find a copy of their catalog.

Speaking of which, it would also be nice to see some Robinson Nugent
connector catalogs from the late 1970s and early 1980s. I am especially
interested in seeing specs for their bottom-entry square-pin receptacles,
which I think _might_ be the ones used on Apple /// memory boards.

Re: Extremely CISC instructions

[Eric Smith via cctalk]

On Mon, Aug 23, 2021 at 6:38 PM Tom Stepleton via cctalk <
cctalk@classiccmp.org> wrote:

> For the sake of illustration to folks who are not necessarily used to
> thinking about what computers do at the machine code level, I'm interested
> in collecting examples of single instructions for any CPU architecture that
> are unusually prolific in one way or another.
>

The Intel iAPX 432 General Data Processor was, for its time (1981), one of
the CISCiest processors, though these days the x86 has far outpaced it for
sheer architectural complexity.

A single GDP instruction could allocate a new object, which required
dealing with a two-level object table as well as a storage resource object
(SRO) and memory claim object (MCO). Another instruction could send a
message object to a port object. The latter, in particular, could result in
an arbitrary number of additional message sends, because each time a
message is sent to a port, it could unblock a processor or a surrogate
waiting to receive from that port, which would then cause a send of that
object to its dispatching or forwarding port, which could cause another
send, etc. Each send could only cause one additional send, so it was tail
recursion and didn't require a stack or consume additional storage.

432 GDP instructions were bit-aligned in an instruction object, and
occupied anywhere from 6 to 344 bits.

The 432 GDP was too complex to be implemented on a single chip using ~1979
fab technology, so it was split into two chips, the 43201 Instruction Unit
and the 43202 Execution Unit.

In the 432's timeframe (1981-1985), I think only the IBM System/38
processor and perhaps the Fairchild Symbol might reasonably have been
considered CISCier than the 432. The Fairchild Symbol was a one-off system
that implemented a high level language compiler in HARDWARE (not
microcode!).

The 432 was a dismal failure. The P7 (code name) processor was to some
degree a successor to the 432, though it was much different. The P7
processor became the BiiN processor, which was mostly a RISC but with some
microcoded object instructions similar to those of the 432, and with tagged
memory to provide a capability architecture. BiiN failed as well, but
stripped of the object operations and memory tagging, the processor became
the i960, which was successful as an embedded processor. (Later there were
a few i960 variants that added back the memory tagging, and perhaps the
object operations, and were sold for military use.)

Although there are many reasons for the failures of both the 432 and the
P7/BiiN processor, one they had in common was that their advanced
architectural features were especially suited to high level languages, such
as Ada, and very poorly suited to low level languages, such as C. As
everyone knows, the world chose to standardize on C. The P7, and later the
i960, could run C code perfectly well, but C code couldn't easily take
advantage of the advanced architectural capabilities of the P7/BiiN
processor.

Re: DEC PDP-11/45 backplane +5 ECO

[Eric Smith via cctalk]

On Sat, Apr 24, 2021 at 9:28 PM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> I had a look at my /45 (a later KB11-D - although I think the backplanes
> for
> the -A and -D are identical),
>

I did not think they used the same backplane, but 11/45 maintenance manual
(EK-11045-MM-007) confirms that they are. Tables 1-2 for the KB11-A and
table 1-3 for the KB11-D confirm that the backplane for both is the
70-08871.

It's possible that the KB11-D requires a higher rev of the backplane than
the minimum for a KB11-A.  That's the case for the 11/70. The KB11-B
(original 11/70) and KB11-C (later 11/70) have essentially the same changes
as from the KB11-A to KB11-D, and the 11/70 maintenance manual
(EK-11070-MM  says that both use the 70-11051 backplane, but that for a
KB11-C, the backplane must be revision D or later.

It sure would be nice to get backplane wirelists for all four (KB11-A, -B,
-C, and -D).

Also, I'm looking for a Field Maintenance Print Set for the RH70.

Re: Need a BASIC expert

[Eric Smith via cctalk]

On Wed, Apr 21, 2021 at 5:19 AM Bill Degnan via cctalk <
cctalk@classiccmp.org> wrote:

> It is not too hard to imagine a professional programmer who took a copy of
> Dartmouth BASIC and adapted it for this flavor of BASIC, but I personally
> dont have any reference docs about it or proof.
>
[...]

> so it may
> simply be MINICAL BASIC would have been just as easy for a period
> programmer to whip up from scratch.
>

The latter seems far more likely. From what little is known about it, the
MINCAL architecture is apparently very dissimilar to the GE-225/235/265 or
GE-635, e.g. the MINCAL being a BCD machine, so I'd expect it would have
been much easier to write a new BASIC interpreter for the MINCAL from
scratch than to adapt it from actual Dartmouth BASIC.

Are there any known actual "ports" of Dartmouth BASIC to non-GE/Honeywell
machines, as opposed to scratch reimplementations?

Re: Lisa Source Code

[Eric Smith via cctalk]

On Wed, Apr 7, 2021 at 2:33 PM Chuck Guzis via cctalk 
wrote:

> Okay, I've got a WORM disc here--how do they propose to archive that?
> (recall that unwritten sectors can't be read).
>

Same for Apple DOS 3.1, 3.2, and 3.2.1 (13-sector format). The formatter
only writes the address fields, but no data fields. Apple fixed that (if
you consider it a defect) in the 16-sector format (DOS 3.3, Pascal, SOS,
ProDOS, GS/OS).

Re: PDP-10 I/O notes

[Eric Smith via cctalk]

On Tue, Mar 16, 2021 at 12:04 AM Lars Brinkhoff via cctalk <
cctalk@classiccmp.org> wrote:

> Interesting to see the DECtape file structure format.
>

IIRC, the DECtape file structure is documented in the Monitor Calls manual.
The disk file structure is not, though there are many references to
Retrieval Information Blocks (RIBs) and such.

Re: DF32?

[Eric Smith via cctalk]

On Tue, Mar 9, 2021 at 4:04 PM Chris Zach via cctalk 
wrote:

> There's a DF32 on Ebay. I've got a bid in on it, will see what happens.
>

Always wanted on, to set up a TSS/8. I hope one of you guys gets it and can
put it to good use.

Re: [simh] RSTS processor identification

[Eric Smith via cctalk]

On Fri, Mar 5, 2021 at 6:33 PM Paul Koning via cctalk 
wrote:

> I would have liked better comms.  The USART has such a tiny FIFO that you
> can't run it at higher than 9600 bps even with the J-11 CPU.  At least not
> with RSTS; perhaps a lighter weight OS can do better.  The printer port is
> worse, that one can't run DDCMP reliably at more than 4800 bps.  I normally
> run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual
> UART chips (2681?) with reasonable FIFO.
>

There seem to be a great many models of Unibus and Qbus multi-port async
serial boards, which present different register-level interfaces, e.g. for
Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best",
for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+?

Re: Massbus - was: Re: VAX 11/750

[Eric Smith via cctalk]

On Wed, Feb 24, 2021 at 7:06 AM Chris Zach via cctalk 
wrote:

> Yes, the TM02 and TM03 formatters allowed MASSBUS to connect to Pertec
> drives, but I don't think you could run a tape drive and a disk drive on
> the same MASSBUS channel anyway. Wonder why, technically the MASSBUS
> cable is just an extension of the Unibus, so it shouldn't matter much
> what combination of cables you used. Maybe they just wrote different
> drivers or something.
>

There's nothing in the hardware that prevents it from being done, but DEC
OSes don't support it, and it's generally not a good idea. Tape activity
would block disk activity, because it doesn't have anything like modern
"tagged command queuing".

archive of DEC Notes

[Eric Smith via cctalk]

Does anyone have contact information for the proprietor of this site:
http://www.activityclub.org/decnotes/
The site has an index of messages archived from DEC's internal "Notes"
(kind of their equivalent of UseNet).

It appears from the "Download this site" page that at one time it was
possible to download an archive of the actual content, but the hosting used
for that only provides one week of free hosting, which has expired.

I don't need the entire archive (though I'd like to get it), but I'd
especially like to get messages from milkwy::23class_semiconductor and
ricks::decschips.

Re: DEC backplane power connectors

[Eric Smith via cctalk]

On Wed, Jan 27, 2021 at 10:51 AM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> https://gunkies.org/wiki/DEC_power_distribution_connectors#Connectors
> I'm not sure why I bothered to write all this stuff up; it was clearly a
> waste
> of time.
>

I've used that writeup before. Thank you!

Re: APL\360

[Eric Smith via cctalk]

On Fri, Jan 15, 2021 at 4:41 PM Fred Cisin via cctalk 
wrote:

> A viewpoint opposed to mine:
> "The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offense."  - Edsger Dijkstra
>

As much as I generally highly respect Dijkstra, I agree with Fred, not
Dijkstra, on this one. COBOL was a remarkably good language for the problem
domain for which it was intended. As with all tools, it is less good for
other problem domains.

Learning and using any programming language will cause some language
specific habits to become ingrained, and you may have to "unlearn" some
when you learn a new language. That doesn't necessarily make either
language bad.

Re: Got DSM-11 running, any manuals online?

[Eric Smith via cctalk]

On Fri, Jan 8, 2021 at 6:17 PM Paul Koning  wrote:

> Yes, but also to hide bad blocks.  So the difference between a raw sector
> dump and a SIMH container file is, minimally, the spare sectors.  What that
> looks like depends on the format; I have no idea what MSCP controllers did.
>

MSCP controllers do the bad block mapping, so AFAIK the disk _always_ looks
to the host like a linear array 0..n-1 of 512-byte blocks.

When accessing an MSCP disk, the host should not, unless running special
diagnostics, be able to distinguish what kind of disk is in use, aside from
that it has a particular block count.

Re: Got DSM-11 running, any manuals online?

[Eric Smith via cctalk]

On Fri, Jan 8, 2021 at 6:16 PM Chris Zach  wrote:

> True, however SIMH has to write things to a "real" file that emulates
> something of a disk.
>

I thought the SIMH representation of an MSCP disk was just a linear array
of 512-byte blocks, from block 0 to block n-1, in which case, it's still
not at all surprising that any RQDXn, or any other MSCP disk with the
standard Unibus/Qbus MSCP port interface would "just work".

If I'm wrong about how the disk is represented by SIMH, then maybe it could
be more surprising.

Re: Got DSM-11 running, any manuals online?

[Eric Smith via cctalk]

On Thu, Jan 7, 2021 at 7:38 PM Chris Zach via cctalk 
wrote:

> Oddly enough SIMH seems to read a raw RQDX1/2 disk pretty well.
>

That's good to know, but not really all that odd. Arguably the main purpose
of MSCP was to abstract away drive and controller differences.

Re: Rod Coleman's personal history of founding, building & running SAGE

[Eric Smith via cctalk]

Apparently someone wrote:

> Thanks for the link as didn't realize 68000 was
>  used for home systems before I ran into Mac.
>

The SAGE certainly wasn't a "home system" in the sense that the Macintosh
was. I mean, sure, there were undoubtedly a few people that bought one for
home use, but it was certainly not at all marketed for that. There were
many other pre-Macintosh 68000 systems that were marketed primarily for
developer or business use, for example the Sun 1, Corvus Concept, TRS-80
Model 16, Altos ACS 68000, and Fortune 32:16.

Re: PDP-11/70 backplane wire list

[Eric Smith via cctalk]

On Fri, Jan 1, 2021 at 10:04 PM Josh Dersch via cctalk <
cctalk@classiccmp.org> wrote:

> Discovered a broken wirewrap wire on the 11/70 I'm slowly working on, it's
> on the last slot (44), and runs from BD2 to ??.  White wire, part of a
> white/black twisted pair.  I've been looking but haven't found a wire list
> for the backplane
>

There would be two different 11/70 backplane wirelists, depending on
whether your CPU is a KB11-B or a KB11-C. Unfortunately I don't have either
wirelist.

If your 11/70 has an M8133 and an M8138, it's a KB11-B.
If it has an MB8123 and MB8138-YA, it's a KB11-C.

You're undoubtedly aware that the A/B section of slot 44 is for the Unibus
cable or terminator, so BD2 is signal BR4 L. It should probably go to the
BR4 L pin of the slot 44 SPC, which would be pin DH2, which would be bussed
through DH2 of the other SPC slots (40-43).

RH70 Massbus controllers normally use BR5 L, but I suspect that the BR4 L
line would be wired to their slots as well. I don't have an RH70 print set,
so I don't know the details. From the RH70s (or slot 40, if BR4 L doesn't
go to the RH70s), I would expect it to go to the Trap & Msc Control board
(TMCB) in slot 11, pin FP1.

Best regards,
Eric

Re: misc stuff - free

[Eric Smith via cctalk]

On Mon, Dec 14, 2020 at 2:52 PM Don Stalkowski via cctalk <
cctalk@classiccmp.org> wrote:

> ll items are as-is and free. Pickup only here in London, ON.
>
[...]

> Microprocessor Data Package - International Electronics Unlimited booklet
>  on IMP MM5750, MM5751 CPU set
>

I can't pick up in ON, unfortunately, but if someone who is in the area
could please pick up this "Microprocessor Data Package" and ship it to me,
I'd be willing to pay anything reasonable, or maybe slightly unreasonable.

Re: Radio Shack 8MB hard disk for Model II

[Eric Smith via cctalk]

On Mon, Nov 30, 2020 at 6:22 PM dwight via cctalk 
wrote:

> Is there a terminator on both ends. If not it is a static 15 ma.
>

There's a 220/330 terminator to +5V at both ends. The thevenin equivalent
of one of these terminators  is 132 ohms to +3V. A driver trying to pull
this to 0V is going to have to provide 22.7 mA for a single terminator, but
since it's doubly terminated, it will be 45.5 mA.

They're only using 24mA rated drivers, which would be within spec if it
wasn't doubly-terminated.

SCSI uses double termination, but it also specifies minimum 48 mA drivers.

Radio Shack 8MB hard disk for Model II

[Eric Smith via cctalk]

I had occasion to look at the service manual for the Radio Shack 26-4150
8MB hard disk which was used with the Model II (and potentially could be
used on 12, 16, 16B or 6000). Note that this drive is not compatible with
the Model I, 3, or 4, and the cable wiring between the computer and the
controller (inside the drive box) is entirely different than what was used
on the later 5, 12, 15, 35, and 70 MB drives.  The Model II host adapter
for the 8MB drive thus is only useful with the 8MB drive, and vice versa.
There were later Model II host adapters that could be used with the 12, 15,
35, and 70 MB drives, which were also useful on the Model I, 3, and 4.

Anyhow, I discovered that according to the documentation, the 8 bit data
bus between the host interface and controller uses 8T26 bidirectional
buffers at each end, which are rated to sink up to 24 mA, but the
schematics show that Radio Shack put 220/330 ohm terminators on the data
bus lines at BOTH ends of the cable! That requires the 8T26 to sink as much
as 55 mA, which means that its logic zero output voltage is likely to
exceed its normal rating. At the very least, this will result in reduced
noise immunity.

I don't have an 8MB host interface or drive in hand to confirm, but the
photos I've found online do show the resistor networks on both ends.

The controller (inside the drive box) is a modified version of a WD1000,
configured for use with the 8-inch SA1004 drive, which operates at 4.34
Mbps, NOT 5.00 Mbps like 5 1/4" drives. Aside from that, it has a different
host pinout than a normal WD1000 (or than the later Tandy controllers), and
has extra circuitry for dealing with write protection. Electrically, the
host interface is otherwise the same as the WD1000. Normally the data bus
for the WD1000 would only be single-terminated at the controller end. That
is in fact what Radio Shack did on all of the later host adapters.

Re: The weird stuff I keep finding: 19 bit core memory?

[Eric Smith via cctalk]

On Fri, Oct 23, 2020 at 11:57 AM Eric Smith  wrote:

> On Wed, Oct 21, 2020 at 6:22 AM Pontus Pihlgren via cctalk <
> cctalk@classiccmp.org> wrote:
>
I have seen PDP-15 core memory and it is not that format. It looks like
>>
> the memory modules from a PDP-8/I or -8/L
>>
>
> The ME15 memory for the PDP-15 used that kind of memory [H215/H216], but
> it normally used an 18-bit H215. I think there was another variant that
> offered parity that would have used the 19-bit H216.
>
> There might have been PDP-15 memory earlier than the ME15, but at the time
> of the PDP-15 introduction (1970), H21x core planes were used in most DEC
> machines, so it would have been surprising for them to use something else.
> Perhaps some PDP-15 systems were upgrades from the PDP-9, which used memory
> modules similar to the PDP-8/I.
>

The PDP-15 print set on Bitsavers shows that the original PDP-15 memory was
the MM15, which was in fact very similar to the PDP-8/I memory, and was
available with or without parity.

The ME15 must have been developed for later PDP-15 systems, and used the
newer H215 core stack. I can't find any evidence of a parity version of
that, which if it existed would have used the H216.

Re: The weird stuff I keep finding: 19 bit core memory?

[Eric Smith via cctalk]

On Wed, Oct 21, 2020 at 6:22 AM Pontus Pihlgren via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, Oct 20, 2020 at 11:26:22PM -0400, Chris Zach via cctalk wrote:
> > > Or maybe a PDP-15?  18 bits plus parity.
> >
> > Possible, did the pdp15 use that type of board?
> >
>
> I have seen PDP-15 core memory and it is not that format. It looks like
> the memory modules from a PDP-8/I or -8/L
>

The ME15 memory for the PDP-15 used that kind of memory, but it normally
used an 18-bit  H215. I think there was another variant that offered parity
that would have used the 19-bit H216.

There might have been PDP-15 memory earlier than the ME15, but at the time
of the PDP-15 introduction (1970), H21x core planes were used in most DEC
machines, so it would have been surprising for them to use something else.
Perhaps some PDP-15 systems were upgrades from the PDP-9, which used memory
modules similar to the PDP-8/I.

Re: The weird stuff I keep finding: 19 bit core memory?

[Eric Smith via cctalk]

On Tue, Oct 20, 2020 at 10:02 PM Chris Zach  wrote:

> Ok, so the MF10 would have been hooked up to a KI10.
>

The ME10 was the first core box for the PDP-10 memory bus that supported
22-bit addressing, and could be used on the KA10, KI10, or KL10 (with a
DMA20 memory bus interface, not available on DECSYSTEM-20 configurations).
It has a toggle switch to select 18-bit or 22-bit addressing. The later
core boxes (MF10, MG10, and MH10) also supported 18-bit and 22-bit
addressing.

The MA10, MB10, and MD10 only supported 18-bit addressing, so typically
wouldn't have been used on the KI10 or KL10.

Re: The weird stuff I keep finding: 19 bit core memory?

[Eric Smith via cctalk]

On Tue, Oct 20, 2020 at 8:06 PM Chris Zach via cctalk 
wrote:

> The real weird one is a quad board H216. I thought it was a Unibus core
> memory board,


Most of the DEC core plane boards were not specific to any particular bus.
though there are some exceptions.


> but it's 8k*19 bits, which means it came from one place:
> An MA10 memory box. The only one I may have been exposed to was AI (the
> original KA10).
>

I'm pretty sure the H216 was too new to have been used in an MA10 or MB10,
but I don't know which core planes or other modules were used. They might
have still been using core modules made by external vendors like Ferroxcube.

The much later MF10 does use the H216, while the MG10 uses the H217 and the
MH10 uses the H224.

The H216 also might have been used in memory systems for a PDP-9 (late in
its life) or the PDP-15. The ME15 normally used the H215 18-bit core
planes, but I think there was a parity option, which would have used the
H216.

Re: Control Data 449 Special Miniature Computer from 1967?

[Eric Smith via cctalk]

On Fri, Oct 16, 2020 at 7:04 AM Gavin Scott via cctalk <
cctalk@classiccmp.org> wrote:

> Or was it really just a calculator?
>

No, it was a real computer.

Re: 9 track tapes and block sizes

[Eric Smith via cctalk]

On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk 
wrote:

> Actually, they're neither.  I append the metadata after the EOI marker
> on mine.   Doesn't seem to bother the emulators.
>

Some programs (but probably very few) that use various so-called .tap files
assume that they can seek to the EOF (of the container file) and read
records backwards (supported by lengths being at both ends of blocks in the
container). Tacking metadata on the end breaks that. I'm not criticizing,
mind you. It's just something that people may need to be aware of.

The .tap file formats are horrible. Originally there was at least the
virtue of simplicity, but because they've diverged we don't even have that.

Al wrote:

> Bordynuik's at least had some provisions for reporting a bad block,
> as I'm sure yours does.
>

Aeons ago when I was doing stuff with tape images, I made a proposal for
representing bad blocks of either known or unknown length. I don't know
whether anything other than some of my own unpublished code adopted that
particular proposal. IIRC, I proposed using a record length of 0x
to designate any kind of "metadata" record, with the real length of the
metadata record in the next word in on both ends (to still support
backwards reading), and the third word at the beginning only being a tag of
what kind of metadata it was, etc.

Of course, that scheme breaks programs that use tape images but don't
expect enormous or "negative" record lengths.

I contributed to the morass by still calling my files .tap files.

Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives

[Eric Smith via cctalk]

On Thu, Oct 1, 2020 at 11:54 AM dwight via cctech 
wrote:

> It is going to need a lot of contact cleaning.
> The one thing I like is the carry design the Zuse used. Really fast for
> relays but not of much use for solid state.
>

Where is that circuit described?

Re: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff.

[Eric Smith via cctalk]

On Sun, Sep 27, 2020 at 3:22 PM Gavin Scott via cctalk <
cctalk@classiccmp.org> wrote:

> APL on the 3000 was a project started at HP Labs
> in Palo Alto in the early 1970s.

[...]

> This would be the first
> full APL implementation on a "small" (non-mainframe) computer.
>

There was IBM APL\1130 version 2, introduced in 1969. Maybe that can't
considered "full"? I don't know all of what's missing; some accounts claim
that it almost had feature parity with APL\360, except the circle function,
which admittedly is a rather significant omission. I would be surprised if
the circle function didn't make an appearance in later releases.

In any case, that's awesome work resurrecting it!

I used a 3000 a little bit in school from 1982 to 1984, but unfortunately
it was mostly used for RJE to a System/370 elsewhere, so I didn't learn too
much about the 3000.

Re: Thoughts on restricted distribution documents (Dec Professional 350)

[Eric Smith via cctalk]

On Tue, Sep 29, 2020 at 6:11 PM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> TIFF compression is lossless.
>

TIFF is only a container format ("Tagged Image File Format"). TIFF does not
define any one compression. It in fact can contain either lossy or lossless
compression, or even uncompressed images.

For black-and-white documents (text and line art, no grey scale), it used
to be somewhat common to use TIFF Class F Group 3 or Group 4 fax format,
which is lossless, but TIFF can also contain DCT-compressed images
(equivalent to JPEG).

Re: Exploring early GUIs

[Eric Smith via cctalk]

On Sun, Sep 20, 2020 at 3:24 PM Mike Begley via cctalk <
cctalk@classiccmp.org> wrote:

> There's also the windowing system used on the AT 3B1 (AKA Unix PC, AK
> PC7300), which I think was called MGR.  It may have also been ported to
> other systems as well.  When I had one of these machines it was adequate,
> although terribly slow on a 512K system.
>

MGR was not the Unix PC's native GUI environment; I'm not sure what that
was named. MGR was an open source environment that could be installed on
the Unix PC. For best performance, it was necessary to replace a PAL chip
on the motherboard ("VIDPAL") to allow user-space access to the frame
buffer. The native GUI environment did not require or benefit from that.

The linked photos are of the native GUI environment.

Since the Unix PC was developed by Convergent, and the SVR2 it runs is
derived from Convergent CTIX, I suspect that the native GUI environment was
from Convergent as well. It might be derived from Convergent WGS/Desktop,
but I've never seen that.

Re: Computer stores

[Eric Smith via cctalk]

On Tue, Aug 25, 2020 at 10:28 PM Hagstrom, Paul via cctalk <
cctalk@classiccmp.org> wrote:

> The circuit boards say "Apple Computer 1" on them.  So they had the
> optimistic "1" in the name originally.
>

The user manual, schematic, and some but not all advertisements also say
"Apple 1" or "Apple-1".

I haven't seen any official documents or communication that used the roman
numeral "I", though some third-party material does.

Re: Adventures online

[Eric Smith via cctalk]

On Thu, Jul 23, 2020 at 11:47 AM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> Infocom's games were based on Crowther, after all.


Inspired by, not "based on".

ADVENT was written in Fortran 66. I'm not sure what Crowther used
originally, but Don Woods version was developed on a DECsystem-10 running
TOPS-10.

The original Zork/Dungeon was written in MDL on a PDP-10 running ITS, and
only later "translated from MDL into FORTRAN IV by a somewhat paranoid DEC
engineer who prefers to remain anonymous."

Infocom games were written in ZIL (based on MDL), and developed on a
DECSYSTEM-20. Presumably Infocom had a ZIP for the -20, but they didn't
publicly release that.

Wanted Sun 3/80

[Eric Smith via cctalk]

I'd like to buy a Sun 3/80 machine. I'm not too interested in other models.
I'm willing to pay a fair price plus shipping, but not a L@@K RARE price.

Re: Small C ver 1.00 source?

[Eric Smith via cctalk]

On Tue, Jul 14, 2020 at 10:42 AM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> The term "p-code" comes from the 1973 Pascal-P version of UCSD Pascal.
>

"p-code" does come from Pascal-P, but Pascal-P wasn't a version of UCSD
Pascal. Pascal-P was developed on the CDC 6600 in 1972.

UCSD Pascal didn't come about until 1977, so the term p-code predates UCSD
Pascal by five years.

Re: Small C ver 1.00 source?

[Eric Smith via cctalk]

On Tue, Jul 14, 2020 at 9:37 AM dwight via cctalk 
wrote:

> I'm curious as to where the term P-code came from and what defined it.
>

There's no formal definition of "p-code". Although other similar
"bytecodes" existed before, the term "p-code" or "pcode" came from the
earliest implementations of Pascal, ncluding Pascal/S (subset) and
Pascal-P, starting around 1972. Those originally ran on the CDC 6600,
though the Pascal-P series of compilers were ported to many other machines,
and served as the inspiration for UCSD Pascal.

Re: Getting files off a 7300

[Eric Smith via cctalk]

> One oddity: The system came up but was faulting out on ports tty1 and 2.
>
Editing /etc/inittab fixed that, but the system *does* have a two serial
> port card expansion module. Wonder if the modules have to be in specific
> slots or something...
>

The UnixPC uses geographic addressing (like an Apple II, unlike an IBM PC),
so the I/O address of the hardware (Z8530 chip) is determined by the slot.
I thought the UnixPC kernel/drivers were smart enough to automatically
detect the serial card(s) in any slot, but it's been almost thirty years
since I dealt with that, so perhaps I'm misremembering.

The built-in serial port is one port of an NEC uPD7201 (or Intel 8274) at a
fixed address, so the driver for that should always be present.

Re: Future of cctalk/cctech (comment on address fields) , capturing Discord server traffi

[Eric Smith via cctalk]

On Thu, Jun 25, 2020 at 2:27 PM jim stephens via cctalk <
cctalk@classiccmp.org> wrote:

> The current message
> "From" field contains the name of the original sender but with the
> encoded address of the list as the email address
>

Unfortunately now there's no practical way for a mailing list to avoid
rewriting the From header to indicate that the messages are sent from the
list. If you don't do that, many (or most) mail servers (MTAs) will
silently drop the mail due to DKIM/SPF/DMARC failures.

If I send mail from f...@example.com to a classiccmp.org list, and then the
list sends it to all the subscribers _without_ rewriting the From header,
many (or most) receiving MTAs will find that the message fails origin
verification because classiccmp.org can't be validated as a legitimate SMTP
originator for email from example.com.

I'm surprised that use of an "X-Original-From" header or similar isn't
commonly used to work around this. Possibly people may think that it would
help spammers harvest email addresses, but it wouldn't make the harvesting
problem any worse than it was before From rewriting.

Some list software puts the entire original From address in the comment
part of the rewritten From header, rather than only the comment part of the
original.

Re: Schematic for DEC H7441 (not the H744!)

[Eric Smith via cctalk]

DEC MK11-B Field Maintenance Print Set, October 1977

http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/MK11-B_Field_Maintenance_Print_Set_Oct77_part2.pdf

pages 27 to 36 of the PDF file

Re: TU58 dump tool on Linux?

[Eric Smith via cctalk]

On Thu, Jun 11, 2020 at 8:18 AM Jan-Benedict Glaw  wrote:

> I don't have a TU58, but using nbdkit[1] or BUSE[2] (which seems to
> hook up as a NBD device as well) it should be quite easy to make it
> avaliable as a block device. For reading and writing, this should be
> pretty straight forward.
>

Yes, that could certainly be done, but it's a fair bit more work than just
writing a tape dump program.

Re: TU58 dump tool on Linux?

[Eric Smith via cctalk]

On Wed, Jun 10, 2020 at 3:30 PM John Forecast via cctalk <
cctalk@classiccmp.org> wrote:

> You could try my “fsio” utility  from the SIMH simtools repository:
> 

I originally wrote it to read/write SIMH disk images in various formats
> (including RT11). I’ve
> never tried it with a tape drive but if it looks like a block device it
> should work.
>

I get a 404 when I click on that link. I think you may have meant:
https://github.com/simh/simtools/tree/master/converters/fsio
That looks like it would be useful to me for a lot of other things, but
probably not for reading from actual TU58 drives.

A real TU58 drive hooked up to a system running Linux does not look
anything like a block device. Linux has no idea what it is; it's just
something hooked up to a serial port. To read tape blocks, it would be up
to a user space program to send the TU58 the right MRSP commands and
interpret the responses.

There are a number of programs that solve the opposite problem, and make a
PC pretend to be a TU58, but those don't help when what you want to do is
talk to an actual TU58. I haven't seen a program for that. Perhaps some
code from the NetBSD kernel could be useful, but I'm guessing that dealing
with that would be more trouble than just writing a new program.

There are some undocumented MRSP commands, but the documented commands
should be sufficient to read a tape.

Re: Ever seen a Cromemco Cyclops in the wild?

[Eric Smith via cctalk]

On Tue, Jun 9, 2020 at 6:14 PM William Sudbrink 
wrote:

> No, I'm afraid not.  I can tell you from both personal experience and from
> the
> designer (Terry Walker) that the chip is either a Mostek MK4008P-9 or an
> AMI
> S4008-9.  I have used both chips.  See my web page:
>
> http://wsudbrink.dyndns.org:8080/cyclops/index.html


You obviously must be correct, and use of a DRAM makes much more sense than
an SRAM. It's possible that an SRAM could be made to work as an image
sensor, but it would not be anywhere near as sensitive as a DRAM. When,
back in 1975, I compared the pinout to the data books I had on hand, and
observed that it exactly matched the 2102, and didn't search any further. I
had no idea that the MK4006 and MK4008 dynamic RAMs happen to have the same
pinout as the 2102 static RAM.  Intel's own 1K DRAMs (1103 PMOS, 2105 NMOS)
do not share that pinout.

Re: Ever seen a Cromemco Cyclops in the wild?

[Eric Smith via cctalk]

On Tue, Jun 9, 2020 at 4:53 PM Boris Gimbarzevsky via cctalk <
cctalk@classiccmp.org> wrote:

> so probably read the Cyclops article, decided that $25 was way
> too much for one chip and never bothered.


In 1975 the B2102 or C2102 in the lidded ceramic package was more expensive
than the D2102 (CERDIP, frit seal, no die cavity lid), and far more
expensive than the P2102 (plastic). The B2102 or C2102 in low volume sold
for over $10 at the time, so $25 for one that had been manually de-lidded
then fit with a transparent lid doesn't seem like it was too unreasonable.

If you wanted to save a few bucks you could have bought a normal C2102 and
replaced the lid yourself.

Of course, the article didn't say that it was a 2102, but that was evident
from the pinout. The A/B/J/K jumpering was needed because the topology of
the 2102 and 2102A were different, which didn't matter in normal RAM
applications.

Re: PC Fortran (Was: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Sun, May 31, 2020 at 5:50 PM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> On 5/31/20 2:24 AM, Eric Smith via cctalk wrote:
> >
> >
> > On the other hand, Intel also had a FORTRAN-80 product, which was
> unrelated
> > to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development
> > systems under the ISIS-II operating system, and the compiler was written
> in
> > PL/M.
> >
>
> Which is even funnier when you realize that the PL/M compiler
> was written in Fortran.
>

In at least the more recent versions, Intel FORTRAN-80 on ISIS-II was
compiled with the ISIS-II PL/M compiler, which was itself written in PL/M.

The ISIS-II PL/M compiler was bootstrapped from the PL/M cross-compiler
that was written in FORTRAN, and it's entirely possible that early versions
of Intel FORTRAN-80 were developed that way as well.

Re: PC Fortran (Was: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Sat, May 30, 2020 at 3:27 PM Fred Cisin via cctalk 
wrote:

> >> One reaason why you don't hear much about that is because the first
> >> version of Microsoft Fortran for the PC wasn't real great.
> >> It was written in Microsoft Pascal.
>
> On Sat, 30 May 2020, John Foust via cctalk wrote:
> > Really!
> > How does this connect to Microsoft's FORTRAN-80 for CP/M circa 1977?
>
> unrelated product, with no apparent connections, that I'm aware of.  The
> 8080/Z80 FORTRAN-80 would have been a better starting point!
> Bob Wallace wrote the original Microsoft Pascal; I don't know who wrote
> the Fortran, other than being told that it was written in Microsoft
> Pascal, and to avoid the run-time library.
>

I assume you mean that Microsoft Fortran for the PC was written in Pascal.

I did some reverse-engineering of the Microsoft FORTRAN-80 compiler, and it
appears to be hand-written in 8080 assembly.

On the other hand, Intel also had a FORTRAN-80 product, which was unrelated
to Microsoft FORTRAN-80. Intel FOTRAN-80 ran on their MDS development
systems under the ISIS-II operating system, and the compiler was written in
PL/M.

Re: history is hard

[Eric Smith via cctalk]

On Fri, May 29, 2020 at 3:30 PM Jon Elson via cctalk 
wrote:

> On 05/29/2020 02:38 PM, Noel Chiappa via cctalk wrote:
> >  > From: Jon Elson
> >
> >  > As far as I know, there was no VM/360. There WAS VM/370, which
> was out
> >  > in the early 1970's
> >
> > CP/67, which was a semi-product, and ran only on 360/67's, was basically
> the
> > same functionality as VM/370. (I get the impression that the code was
> > descended from CP/67, but I can't absolutely confirm that
> I think it was, too.  But, only a /67 could run this.  Any
> other 360 would have big security/reliability problems if
> they tried to implement this kind of virtualization.
> Low-level machines did not even have storage protection
> keys, and on the /40 and /50 (I think) it was an option,
> although I'd guess almost any /50 had it installed.  And,
> the storage protection keys were a very coarse/crude tool,
> although you could set up
> sharable read-only areas.
>

The issue wasn't whether the machine had storage keys (protection, SSK and
ISK instructions). AFAIK CP/67 didn't use that even when available. What
CP/67 and VM/370 required was Dynamic Address Translation (DAT), and the
360/67 was the ONLY 360 model for which that was available. Contrary to
popular belief, DAT wasn't even available on every 370 model, as it was an
optional feature of the 370 architecture.

CP/40 was developed on a modified 360/40 that had DAT (with the addition of
a "CAT box"), but was never available as a product.

Re: CHM software

[Eric Smith via cctalk]

On Thu, May 28, 2020 at 4:05 PM Randy Dawson via cctalk <
cctalk@classiccmp.org> wrote:

> Follow up to the Living Computer Museum discussion...
> I can understand why CHM does not allow access to the hardware,
> But what about the software?
> It should all be downloadable.
>

CHM is in the United States. Ever hear of Title 17 of United States Code?

Re: Early Nubus history

[Eric Smith via cctalk]

On Thu, May 28, 2020 at 12:15 AM Mark Linimon via cctalk <
cctalk@classiccmp.org> wrote:

> But just imagine what
> the tech world would have looked like with interchangeable cards for
> PCs and Apples.
>

We have that now, and it really doesn't seem to be of all that much benefit.

Re: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Thu, May 28, 2020 at 2:54 PM Jim Brain via cctalk 
wrote:

> I see the 16A and the 12/16B as different sublines, as the II/16A used a
> passive backplane with cards, while the 12/16B/6000 had a motherboard
> with the z80 on it, and the card cage was for extensions (and the 68K
> card).
>
> Both sublines merged back together with the 6000
>

Merged in what sense? AFAICT, aside from branding, the only difference
between the 16B and 6000 was that the latter used the newer 8 MHz version
of the 68000 card, which was also available as an upgrade for the 16B.  If
you consider the II/16A as a "subline", I don't see how the 6000 "merged
back" with that subline in any way.

Re: Living Computer Museum

[Eric Smith via cctalk]

On Thu, May 28, 2020 at 2:20 PM Chris Hanson via cctalk <
cctalk@classiccmp.org> wrote:

> This is one of the things that disappointed me most about the Computer
> History Museum in Mountain View, CA. Sure you can’t let the public interact
> with *everything*, but since so much of computing since its inception has
> been about interaction with active systems, just displaying them is leaving
> out a large amount of what really makes them interesting. The CHM does a
> lot of great preservation, archival, and curatorial work, but this really
> feels like a glaring omission.
>

When we restored the PDP-1 at CHM, we *really* wanted to make sure that the
public could interact with it, though in a limited fashion. Ken Sumrall and
I built quick-and-dirty Spacewar control boxes out of particle board and
arcade switches, which were intended for restoration team use, and we
originally thought that we would later build some "more authentic" control
boxes. (The control boxes used in Boston had disappeared, and in any case
we don't know whether they were "original".) However, Steve Russell (author
of the Spacewar game) pointed out that our hastily knocked together control
boxes actually were "authentic" in the sense that the originals were also
hastily knocked together out of whatever was at hand.

It would certainly be nice if there was a practical way to allow more
hands-on use of the PDP-1, but I can't think of any way of doing that which
CHM would be likely to approve, and I don't disagree with them. It's
somewhat difficult to keep the machine in good working order even when only
a few skilled people operate it.

Eric

Re: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Tue, May 26, 2020 at 1:52 PM Jim Brain via cctalk 
wrote:

> FOlks know about IBM,
> but most don't know they still make mainframes and midrange (OS400 or
> whatever it is called now) machines, and Burroughs, Wang, Amdahl,
> Hitachi are missed. , Super computer is forever linked with Cray, but
> Control Data, Thinking Machines, Silicon Graphics, and even Sun are no
> more remembered.
>

Oh, IBM, DEC, and Honeywell; HP, DG and Wang
Amdahl, NEC, and NCR, they don't know anything
They make big bucks for systems, so they never want it known
That you can build a mainframe from the things you find at home

- Bill Sutton, "Do It Yourself"
https://lyrics.fandom.com/wiki/Bill_Sutton:Do_It_Yourself
https://www.youtube.com/watch?v=3R4sBnbp33U

Re: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Fri, May 22, 2020 at 1:56 PM Fred Cisin via cctalk 
wrote:

> On Fri, 22 May 2020, Boris Gimbarzevsky wrote:
> > Thanks for posting the timeline of various Basic interpreters.  I wasn't
> > aware that Gates/Allen also wrote Basic for C64.
>
> Microsoft did a BASIC for the Commodore PET.  I wasn't aware that they did
> the C64.
>

Microsoft wrote a 6502 BASIC that was used on many vendor's machines,
including Commodore, Ohio Scientific, and Apple, but I'm not sure whether
Microsoft did the work that was needed to adapt it to the PET; that could
have been done by either Microsoft or Commodore.

AFAICT, all later Commodore 6502 (etc.) based machines, including the
Commodore 64, reused the BASIC from the PET with additional hacks by
Commodore as needed to adapt to hardware changes, and I don't think
Microsoft was involved in any of that. In 1983 I studied a disassembly of
C64 BASIC, which was pretty much identical to VIC20 BASIC, and not much
different than later versions of PET BASIC. I compared it to an actual
listing of the early Microsoft 6502 BASIC source code, which can today be
readily found on the internet, but in 1983 was quite difficult to come by,
and at the time I couldn't publicly admit to having such a thing, and I
still won't publicly describe how I obtained it.

The changes that were added to C64 BASIC as compared to "standard' MS 6502
BASIC, e.g. having some routines vector through RAM, were clearly done by
someone who didn't have a good grasp of how Microsoft BASIC worked. For
example, some of those vectors were intended to allow adding statements and
functions, and they could in fact be used for that, but they didn't vector
the _optimal_ subroutines for that.

Re: Microsoft open sources GWBASIC

[Eric Smith via cctalk]

On Fri, May 22, 2020 at 1:54 PM ben via cctalk 
wrote:

> On 5/22/2020 1:38 PM, Rod Smallwood via cctalk wrote:
> > I remember sittig in the DEC Ealing (London) Office in 1975 watching a
> > programmer work on TOPS 10
> >
> > That was DEC's mainframe operating system.
> >
> > A foot high of printout all in assembler!!!
> But remember mainframes after 1960 (compared to the 50's)
> where a joy to use with assembly.
> Only afer 1975 came out did you have the extra memory
> (4K drams) and languages like C with structures did O/S's
> change.Ben.
>

"did O/S's change" in what way?

The IBM PL/I F compiler was available in 1966 and PL/I has structures. It
was usable on all "real" System/360 machines configured with 64KB or more
of memory, so even a 360/30 could be used, but not a 360/20, which isn't
actually a 360.

There was a PL/I D compiler that would run under DOS/360 with only 16KB of
memory, but it was a very restricted subset of PL/I; I dodn't know whether
it had structures.

ALGOL W also appeared in 1966 and had structures, known as records.

Of course, COBOL is even older and also had structures.

Most sensible people did not wait until 1975 to start using high-level
languages, unless they had either tiny machines or real-time requirements
that couldn't be met with a high-level language.

Re: (V)HDL Toolsets

[Eric Smith via cctalk]

On Thu, May 21, 2020 at 10:07 AM Jon Elson via cctalk 
wrote:

> (I also use Coolrunner II and XC9500XL devices in some of my
> products.)
>

I used to use XC9500XL series (mostly XC9572XL) quite a bit, but I have
switched to Lattice LC4000ZE series because they are less expensive and
lower power, and (like the XC9500XL) have 5V tolerant inputs.

I'm not thrilled with having to use yet another different toolset, but
c'est la vie.

Re: Keyboard inverters/converters for terminals

[Eric Smith via cctalk]

On Thu, May 21, 2020 at 9:37 AM Electronics Plus via cctalk <
cctalk@classiccmp.org> wrote:

> https://www.vecmar.com/products/search.asp
> Type in keyboard
> The first result allows a terminal keyboard to be used on a PS/2 port.
> The second result allows a PS/2 keyboard to be used on a terminal.
>

>From the limited information available (almost none), it appears that they
are selling passive adapters that work with ADDS 4000 terminals that use
PS/2 protocol on a modular jack.

As has been noted earlier in this thread, there are a huge number of
computers that use modular plugs and jacks for keyboard interfaces, and
there is NO standard for their electrical or protocol characteristics.
Plugging in the wrong combination can result in damage to either or both
devices. Even using the wrong modular cable can do that, because common
4P4C modular cables are wired with a flip (1 to 4, 2 to 3, etc), while
modular cables for computers are sometimes (e.g. Macintosh 128/512/Plus)
wired straight through (1 to 1, 2 to 2, etc.)

IMNSHO, there's a special place in hell reserved for those who have
designed equipment to (ab)use modular connectors other than for telephone
lines and 10BASEx Ethernet, and I really think a better connector should
have been chosen for 10BASEx.

DEC using MMJ may get a pass because they at least attempted to prevent
connecting the wrong stuff together.

Re: Pdp11/05 boot media

[Eric Smith via cctalk]

On Sat, Apr 25, 2020 at 5:43 PM Jay Jaeger via cctalk 
wrote:

> RX01's are, IIRC, just standard IBM 3740 format, yes?
>

Yes.

The RX02 double density format is the one that's incompatible with
everything else.

Re: Pdp cpus

[Eric Smith via cctalk]

On 5/2/20 5:10 PM, Kevin Lee via cctalk wrote:
> Interesting stuff
> https://github.com/1801BM1/cpu11

On Sun, May 3, 2020 at 4:23 AM Al Kossow via cctalk 
wrote:

> Eric Smith's work on the WD CP1600 chipset's
> various microcode

[links]


I've verified that the microcode dumps of the Soviet 581 LSI-11 clone* are
identical to the DEC microcode. That's not particularly surprising, but it
does give me confidence that the control chip PLAs should be identical as
well. Since they have decoded the control chip PLAs, I should be able to
use that to update my LSI-11 microcode disassembly.

John took photos of the LSI-11 control chip for me, but I had somewhat more
difficulty reading the PLA bits than I did with the WD9000 (Pascal
Microengine) control chip, so I didn't complete transcribing the LSI-11
PLAs.  I haven't really looked at the WD16 microcode or PLAs yet.

* The multi-chip clone. The 1801BM* single-chip PDP-11 microprocessors are
not directly based on any DEC design.

Re: [ancient thread] HP 1820-1584 IC replacement?

[Eric Smith via cctalk]

Back in 2013, Bob Rosenbloom asked:
> I have an HP 9872 plotter that just died. According to the internal self
> test (very nice!)
> one of the bib (MOS to TTL) drivers has failed.

Tony Duell wrote:
> the devie is very simple (it's simialr to the 74LS245) but the problem is
that one side of it does not work with TTL levels. It's a level shifter too.

Although the BIB functioned as a level shifter, in later devices using the
1818-2500 standalone 40-pin BPC Binary Processor Chip, including the 9872C
and 9872T, HP actually used the 74LS245 instead of the BIB. The only thing
they did to meet the MOS level input requirements of the BPC was to put a
10Kohm pullup resistor to +5V on each data line on the MOS side of the
buffer.

As noted elsewhere, the 74LS245 isn't pin compatible with the BIB, so an
adapter would be needed to substitute it.

The 9872A, which uses the BPC with the BIB chip, does not have pullups on
the MOS side. It also uses the HP 16-bit NMOS ROM directly on the MOS side,
and it's remotely possible that adding 10K pullups could be a problem with
the ROM.

Re: VAXmate PSU

[Eric Smith via cctalk]

On Fri, Apr 10, 2020 at 10:14 AM Rob Jarratt via cctalk <
cctalk@classiccmp.org> wrote:

> D12 is an MBR3045PT. It tests correctly as a common cathode diode network.
> However, the forward voltage seems to be 0.19V. The datasheet (
> https://pdf1.alldatasheet.com/datasheet-pdf/view/53622/FAIRCHILD/MBR3045PT.html)
> would suggest it should be 0.76V at room temperature. I can see no physical
> damage to it though.
>

Even when they are good, the forward drop of a diode can be FAR lower than
the typical forward drop (around 0.7 for normal silicon diodes) if you're
putting significantly less that the rated current through it. 0.19V forward
drop is only slightly lower than typical characteristic at e.g. 10mA
current. See figure 3. I've seen more than enough variation of diodes from
typical curves for that alone to convince me that the diode is bad (though
obviously it may be).

The real test is how much it conducts in reverse. All diodes will pass a
small amount of reverse current. This one shouldn't pass more than 1 mA in
the reverse direction at room temperature, even with near the rated reverse
voltage (45V) applied.

Re: pdp11/05 key?

[Eric Smith via cctalk]

On Thu, Apr 9, 2020 at 11:35 AM Norman Jaffe via cctalk <
cctalk@classiccmp.org> wrote:

> I hope that you mean 'hardware porn', not 'hardcore porn'... :)
>

Trivia: for a while in the mid-to-late 1990s, a Google search for "computer
porn" had as the number one result one of my web pages, of that title,
containing images of computers with covers removed. I could see from the
server log that the search was fairly popular, but nevertheless I believe
that most of the people doing the search were not satisfied with the result.

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctalk]

On Wed, Apr 8, 2020 at 2:54 PM Eric Smith  wrote:

> That stands for "data field too big", i.e., too much data to fit in 4KW.
> That's as opposed to "instruction field", which if too big would mean that
> there's too much code.
> Although I used OS/8 Fortran in the distant past, I never tried to compile
> large Fortran programs or programs that used much data, so I don't know
> what it takes to solve that problem. Maybe there is some way to get Fortran
> to use more than one 4KW field for data, issuing the necessary CDF
> instructions to switch data fields?
>

Checking the OS/8 Language Reference Manual reveals that I was totally
incorrect.
That stands for Data File too big.
"Product fo number of record times number of blocks per record exceeds
number of blocks in file."
So I have no idea how to fix that.

Re: DEC OS/8 Question (getting an error TOO BIG INIT)

[Eric Smith via cctalk]

On Wed, Apr 8, 2020 at 1:34 PM Bill Degnan via cctech 
wrote:

> D.F. TOO BIG INIT  
> I'd really like to understand what this error means if
> anyone knows.
>

That stands for "data field too big", i.e., too much data to fit in 4KW.
That's as opposed to "instruction field", which if too big would mean that
there's too much code.
Although I used OS/8 Fortran in the distant past, I never tried to compile
large Fortran programs or programs that used much data, so I don't know
what it takes to solve that problem. Maybe there is some way to get Fortran
to use more than one 4KW field for data, issuing the necessary CDF
instructions to switch data fields?

Re: Monroe 7860

[Eric Smith via cctalk]

On Thu, Apr 2, 2020 at 11:27 AM dwight via cctalk 
wrote:

> You might dump the ROM and look for ascii strings.
> I've wondered if it was possible to glue strops of tape wide enough to
> cards for these card readers.
> Of course, if they were preformatted, it will be a bit more difficult.
>

I have a few reels of two-inch video tape which I've used to make crude
magnetic cards for old HP desktop machines.

Re: APL-11

[Eric Smith via cctalk]

On Mon, Mar 30, 2020 at 10:24 AM Guy Sotomayor via cctalk <
cctalk@classiccmp.org> wrote:

> I have a DEC Writer III with the APL character set ROM and the APL
> keyboard!  Just need to hook it up to something that has APL on it
> and will generate the correct character sequences.  ;-)
>

Cool!  When you get a chance, could you please dump the DECwriter III ROMs?

Re: MSV11-Q info and interesting observation

[Eric Smith via cctalk]

On Sat, Mar 14, 2020 at 2:12 PM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> the MSV11-Q
> sends a 'write' signal to _all_ the banks, and selects the one to
> _actually_
> use by use of the RAS signal.
>
[...]

> Has anyone else seen this trick used anywhere else?
>

Yes, that's very common.

If you have multiple banks, you have to do some form of address decode for
/RAS [*]. If you're doing that, there's no point to having another decode
system for /WR.

Eric


* Alternately, /RAS could be common and /CAS decoded. That effectively does
a refresh cycle on all non-selected banks, but using whatever the row
address just happens to be, so unless you add a LOT of additional
complexity, it's not very helpful, and increases power dissipation. I've
only seen a few designs that did this, and there didn't seem to be any good
reason for it.

Re: HPE OpenVMS Hobbyist license program is closing

[Eric Smith via cctalk]

On Sat, Mar 7, 2020 at 4:32 PM John H. Reinhardt via cctalk <
cctalk@classiccmp.org> wrote:

> I would think that those that already have legal VAX PAKs/licenses could
> still run them. It's just no *NEW* PAKs could be legally generated.
>

The hobby PAKs _and_ the licenses have a one-year expiration.

Re: Parasitic Engineering Altair Clock Fix Kit...

[Eric Smith via cctalk]

On Sat, Feb 22, 2020 at 1:37 AM Mike Douglas via cctalk <
cctalk@classiccmp.org> wrote:

> I scanned my Parasitic clock mod documents and put them at the link below.
>
> https://deramp.com/downloads/altair/hardware/altair_8800_computer/Parasitic%20Clock%20Mod.pdf
>

Thanks for that!

Does anyone have a datasheet for the "94618" dual non-retriggerable
monostable that Parasitic used to replace the 74123? At first I thought the
P/N was likely to be Fairchild, but I couldn't find either a 94618, nor a
dual non-retriggerable with similar pinout from Fairchild. 94618 doesn't
show up in the IC Master editiions of that era, either, nor can I find it
from any of the usual internet sources. A photo of the chip from the actual
Parasitic clock mod might help identify the vendor.

The 74221 and 74LS221 are dual non-retriggerable monostables with the same
pinout as the 74123/74LS123, but require the reverse capacitor polarity (if
using polarized capacitors), and require different RC values than the
74LS123. With appropriate RC values it might make a suitable clock fix if
the 94618 can't be found. It's possible that it might use the same RC
values as the 94618, but without the datasheet for the 94618 it's hard to
tell.

Parasitic mentioned that the 94618 has temperature -compensation and
schmitt trigger inputs, and the 74221/74S221 do have both of those
features. The 74LS221 doesn't have as much input hysteresis for the schmitt
trigger inputs, so the 74221 might be preferred.

Re: IBM BSC CRC?

[Eric Smith via cctalk]

On Tue, Jan 28, 2020 at 8:20 AM Jon Elson via cctalk 
wrote:

> Soem years ago I needed to crack the CRC on a Fanuc serial
> encoder. Luckily, the CRC value
> was just 5 bits.  I built a device to read out and store the
> data from the encoder on a PC.
> Then, I wrote a little c program that had a "universal" CRC
> implementation, where the polynomial
> was supplied as a command line parameter.
>

I did basically the same thing in the 1990s to reverse-engineer the 10-bit
CRC used in HP series 30 ("Spice") calculators (from the late 1970s) for
their ROM test.
The series 30 calculators implemented the ROM self-test as a single CPU
instruction that took 1025 clock cycles to execute, verifying the CRC of
1024 words of ROM, and returning a pass/fail indication.

Later HP calculators did away with the CRC hardware. The HP-41C doesn't
have a ROM self-test built in, though there was a diagnostic ROM used
within HP, and it used a simple checksum rather than a CRC. The series 10
calculators ("Voyager") had a built-in ROM self-test, which used a simple
checksum.

Re: KCC and parenthesis in preprocessor lines

[Eric Smith via cctalk]

On Tue, Jan 7, 2020 at 8:25 PM David Griffith via cctalk <
cctalk@classiccmp.org> wrote:

> I'm having some trouble getting Frotz 2.50 ported to TOPS20.  Version 2.32
> with dumb interface compiles fine under KCC.  With 2.50, there are several
> preprocessor lines that include parentheses.  For instance:
>
> #if UINT_MAX == (1UL<<32)-1UL
> typedef unsigned int  uint32;
> #else
> typedef unsigned long  uint32;
> #endif
>

I haven't used KCC, but I'm guessing that even if parenthesis worked, the
expression would always be false, because  UINT_MAX is not likely to be
2^32-1 on a PDP-10. I would not expect KCC to offer _any_ 32-bit integer
type, and that would expect int to be 36 bits. I'm not sure whether to
expect long to be 36 bits or 72 bits.

Assuming that Frotz doesn't have problems with using a 36-bit integer type
where it expects 32-bit, just replace the whole #if block with the
appropriate typedef, or nest it inside another #ifdef for some KCC- or
PDP-10-specific macro. Or perhaps test CHAR_BIT? An ISO 9899 compliant C
compiler for the PDP-10 would have CHAR_BIT of 9, 12 or some multiple
thereof, but if KCC isn't 9899 compliant that might not be the case.

Re: Design flaw in the SCSI spec?

[Eric Smith via cctalk]

On Wed, Jan 8, 2020 at 4:57 PM Bill Gunshannon via cctalk <
cctalk@classiccmp.org> wrote:

> And then you have DEC.  I have often heard DSSI described as
> SCSI done right


That's reportedly what DEC thought of it, but in practice it was SCSI done
differently so as to be incompatible. The only technical "advantage" of
DSSI was that it better matched some of DEC's other proprietary storage
standards, thus enhancing vendor lock-in and profitability.

If you were another company trying to decide whether to use SCSI or DSSI in
your products, even if licensing and related cost weren't at issue, the
_only_ reason to use DSSI would be to interoperate with DEC.

I was a fan of DEC, but they did plenty of things for vendor lock-in rather
than technical reasons.

Re: Design flaw in the SCSI spec?

[Eric Smith via cctalk]

On Wed, Jan 8, 2020 at 4:44 PM jim stephens via cctalk <
cctalk@classiccmp.org> wrote:

> The electronics of the SCSI interface were designed initially by the
> precursor to Adaptec.  At the time that the SCSI committee was formed,
> there was work by a number of companies.  Among them were HP, and the like.
>

There was no one common electronic design for SCSI. The electronic designs
were unique to many companies. The earliest implementations were
board-level interfaces consisting mostly of TTL. Early single-chip
implementations included those from NCR and Adaptec, though many others
came later.

While there were many companies involved in the standardization of SCSI,
the original SCSI 1 specification, ANSI X3.131-1986, was a relatively minor
elaboration on SASI, which had been developed exclusively by Shugart
Associates, hence the name SASI being an acronym of Shugart Associates
System Interface. Shugart Associates was an early maker of 8 inch floppy
drives and invented the 5 1/4 inch floppy.

Re: Design flaw in the SCSI spec?

[Eric Smith via cctalk]

On Wed, Jan 8, 2020 at 10:55 AM Liam Proven via cctalk <
cctalk@classiccmp.org> wrote:

> With his express permission, I'm forwarding a mail from a public list.
> I am interested in Gene's comments about the design of SCSI, but I
> don't know enough electronics to judge.
>


> And all that pickityness can be laid at the feet of a bean counter
>> between the interface card designer, who specified a $2.00 schotkey
>> diode for buss isolation, which had a maximum voltage drop across it of
>> perhaps .1 volts, and changed to have an 8 cent Si diode with .666 volts
>> drop across it, thereby lowering the logic one voltage by .45 volts.
>>
>
The complaint is with the design of a specific host adapter, not of SCSI
itself, and specifically with the diode that host adapter uses to provide
termination power.

The complaint is only relevant to the use of passive termination, though
the specific host adapter might include passive termination on board. The
problem can be solved by removing the on-board passive termination and
using an active terminator.

A schottky diode will have a minimum drop around 0.3V (not 0.1V!), and
typical with an actual termination load the drop will be closer to 0.4V to
0.5V. Better than a normal silicon rectifier, but not hugely better.

Using real-world values of 5V termination power, 220/330 ohm passive
terminator, 0.45V for the schottky diode drop, and 0.7V for a silicon diode
drop, the resulting termination voltages are 2.73V with a schottky diode
((5.0 - 0.45) * 0.6) and 2.58V with a silicon diode ((5.0 - 0.7) * 0.6).
While 2.73V is clearly better than 2.58V, the difference isn't as huge as
Gene suggests.

The SCSI data lines are normally actively driven, so during data transfer
the termination voltage is not the only thing pulling the line up to a
logic high.

Even in the 1980s, a schottky diode cost under ten cents, not $2. It was
maybe a few pennies more than a silicon diode. It is highly unlikely that a
"bean counter" was involved in this decision at all. An engineer made the
decision, presumably believing that the slightly higher voltage drop of the
silicon diode didn't make a big difference.

Is a schottky diode better for powering a bus terminator? Certainly. Is it
a disaster to use a silicon diode in stead? In my opinion, no.

I suspect that the Amiga SCSI host adapter had other issues that are much
more significant with regard to system reliability.

Eric

Priam 3450/7050 schematic wanted (Priam interface)

[Eric Smith via cctalk]

Bitsavers has a schematic of the ANSI interface version of the Priam
3450/7050 eight-inch hard drives, but does anyone happen to have the
schematics of the "normal" version (Priam interface, as opposed to SMD or
ANSI)?