Re: Possible PUTR bug?

[allison via cctalk]

My Solution is easier, least for me.

I have a few Z80 CP/M machines with 765A in it and if it can't read it
its likely due to being hard sectored or M2FM.  I has 3.6, 5.25 and 8"
and  the 5.25 are Teac FD55gfh which are dual speed and can do all
modes. With my own software and utilities it does whatever even RX180,
RX50, RX33, and RX22/23 formats from the DEC pool.

The PC machine for when that stuff is needed is a DELL pizza box that
has 32mb of ram and 486dx/66 (ISA/ISA16) and can run dos though NT4 as
needed as I have a buttload of ST3660As as media for them (have two as a
spare).  That machine uses a combo IO controller for the FDC seems to do
what I ask of it.  Also an old Compag with similar features and PII and
32MB and also does Ethernet but the disk controller is a newer ISA16
using a combo chip and most of the combo chips after late 90s-ish seem
to have an even shorter VFO sync window (flash blindess).

I neither expect nor desire modern machine with anything past NT4 to
behave well with old disks.  Though Mini-ITX boards all seem to support
everything and anything and have all the legacy ports.  They all run
linux and if needed a partition (60mb of disk is trivial) for MSdos
6.22 or freedos.

Oh, unless its under threat the OS is linux, freedos, or if required XP
Though the latter is usually under VMware or Virtualbox on Linux..  I
just got tired of all the winders hassles and requirements for insane
hardware needs every few years.  Most stuff runs fine under dosemu or wine.

As to RT11, I have run mostly V5.0x and as needed if a device required
it a later driver borrowed from V5.04 or later.  It just seems to work
with out much pain.

As to running a RX50 on a PC...  That drive was a neat thing but its
mostly the interface is incompatible with most standard floppies and
a FD55A/B or any of the 48tpi 40 track drives will read and write the
media.  I make a point of only using it on PDP-11 as transfer media,
its low density so its marginal for much.  Keep in mine that drive
select is used to select the A or B drive of a RX50 there is no side.
They had a terrible track record for reliability.  I can put Two RX33
[teac fd55gfh] in the same space and store more.  Some to think of it
most Late PC 5.25 and 3.5 inch drives are incompatable with old standard
[TM100 and that era] as many do not have a 1 of 4 drive select jumper
and use the funky PC only twist cable.

I neatly sidestep all of the cruft and hacks needed for super wizbang
winXP and later machines.  I figure if I'm going to play with old
hardware I need to retain the old hardware to maintain them.  So I
retained the best of the best old PCs as they bulk of them are crap.
I buy new hardware that is not neutered.  Mini/Micro-ITX board with
atom or celeron CPUs (really all that's needed) are cheap and easily
built up into linux boxes or if you must any of the older 32 bit
winders incantations.


Allison



]On 05/11/2019 11:22 AM, Douglas Taylor via cctech wrote:
> I understand your frustration, because all I really wanted to do was
> read/write RX33 and RX50 5-1/4" floppies to move data in and out of my
> microPDP11.  Once, I wanted to write an RX23 3-1/2" floppy with OpenVMS
> PAK files that could be read on an DEC Alpha.
> 
> Finding a PC that supports the 5-1/4" floppy drive is difficult, the
> BIOS or FDC chips only support 3-1/2" floppies in many late model PC's. 
> It appeared only a few of the older PC's that supported the 5-1/4"
> drives could actually change the spindle speed so you could read/write
> RX50 format.
> 
> I dedicated a DELL XPS 233H to this task, 32MB memory, Pentium II cpu. 
> Boots from 3GB hard disk, DOS and Win 3.1 (if you so need it).  I also
> have an IDE to CF card adapter standing by when the hard disk dies. 
> Love to have something with a smaller form factor, but it gets the job
> done.
> 
> Doug
> 
> 
> On 5/11/2019 10:35 AM, Charles via cctalk wrote:
>> Just an update... I spent an entire long afternoon wrestling with that
>> old PC, trying to find some combination of HDD jumpers and BIOS
>> settings that would allow the XP hard drive to boot with another drive
>> attached (either on the slave connector or the secondary channel with
>> the CD-ROM removed). No dice.
>>
>> So I had the bright idea to use Minitool's Partition Wizard, and
>> shrink my Windows partition so there'd be room for a  newDOS partition.
>> But it won't even run (probably because I have only 64 MB RAM on that
>> box). Grrr. It's unbelievably slow anyhow, so more SDRAM on order,
>> which is really cheap these days.
>> I'd get a newer PC for the workbench, but need to keep the old
>> motherboard because there are a couple of devices (including a PB-10
>> PROM programmer) which are ISA slots.
>>
>> So, this has become a Windows/PC (ugh) project instead of just being
>> able to play with my PDP-11...
>>
> 

Re: Possible PUTR bug?

[Fred Cisin via cctalk]

I wish that I were to have met you 40 years ago!
Learning that stuff by error, error, error, trial, and error was 
inefficient.


--
Grumpy Ol' Fred ci...@xenosoft.com

On Sat, 11 May 2019, allison via cctech wrote:

My Solution is easier, least for me.

I have a few Z80 CP/M machines with 765A in it and if it can't read it
its likely due to being hard sectored or M2FM.  I has 3.6, 5.25 and 8"
and  the 5.25 are Teac FD55gfh which are dual speed and can do all
modes. With my own software and utilities it does whatever even RX180,
RX50, RX33, and RX22/23 formats from the DEC pool.

The PC machine for when that stuff is needed is a DELL pizza box that
has 32mb of ram and 486dx/66 (ISA/ISA16) and can run dos though NT4 as
needed as I have a buttload of ST3660As as media for them (have two as a
spare).  That machine uses a combo IO controller for the FDC seems to do
what I ask of it.  Also an old Compag with similar features and PII and
32MB and also does Ethernet but the disk controller is a newer ISA16
using a combo chip and most of the combo chips after late 90s-ish seem
to have an even shorter VFO sync window (flash blindess).

I neither expect nor desire modern machine with anything past NT4 to
behave well with old disks.  Though Mini-ITX boards all seem to support
everything and anything and have all the legacy ports.  They all run
linux and if needed a partition (60mb of disk is trivial) for MSdos
6.22 or freedos.

Oh, unless its under threat the OS is linux, freedos, or if required XP
Though the latter is usually under VMware or Virtualbox on Linux..  I
just got tired of all the winders hassles and requirements for insane
hardware needs every few years.  Most stuff runs fine under dosemu or wine.

As to RT11, I have run mostly V5.0x and as needed if a device required
it a later driver borrowed from V5.04 or later.  It just seems to work
with out much pain.

As to running a RX50 on a PC...  That drive was a neat thing but its
mostly the interface is incompatible with most standard floppies and
a FD55A/B or any of the 48tpi 40 track drives will read and write the
media.  I make a point of only using it on PDP-11 as transfer media,
its low density so its marginal for much.  Keep in mine that drive
select is used to select the A or B drive of a RX50 there is no side.
They had a terrible track record for reliability.  I can put Two RX33
[teac fd55gfh] in the same space and store more.  Some to think of it
most Late PC 5.25 and 3.5 inch drives are incompatable with old standard
[TM100 and that era] as many do not have a 1 of 4 drive select jumper
and use the funky PC only twist cable.

I neatly sidestep all of the cruft and hacks needed for super wizbang
winXP and later machines.  I figure if I'm going to play with old
hardware I need to retain the old hardware to maintain them.  So I
retained the best of the best old PCs as they bulk of them are crap.
I buy new hardware that is not neutered.  Mini/Micro-ITX board with
atom or celeron CPUs (really all that's needed) are cheap and easily
built up into linux boxes or if you must any of the older 32 bit
winders incantations.


Allison

Re: How were 32-bit minis built in the 70s/80?

[Chuck Guzis via cctalk]

On 5/11/19 9:52 PM, ben via cctalk wrote:
> On 5/11/2019 10:12 PM, Chuck Guzis via cctalk wrote:
> 
>> Personally, I preferred "the Naked Mini"
> Used for porn world wide.:)
>> --Chuck
>

Maybe--it was an 8 bit mini, so not very powerful.  Mostly used in what
we'd call "embedded" applications.  Pre-microprocessor days.

I can remember back in the early 70s picking up some surplus PCBs with
plain 7400 (not LS) logic, including a couple of 74181 ALUs and a 74199
shift register, both in 0.600" 24 pin DIPS--and lots of SSI TTL logic. I
was mostly interested in scavenging ICs from the thing, so I never
figured out what the PCBs belonged to.

On the other hand, I have a couple of Eurobus wire-wrap boards outfitted
with lots of 10K series ECL.  It appears to be a 12-bit CPU, complete
with memory and registers.   The clock on it is 40MHz.  I don't know
what it could have been.  Mostly, I consider the boards to be a source
of gold-plated wire-wrap pins.

--Chuck

Re: How were 32-bit minis built in the 70s/80?

[ben via cctalk]

On 5/11/2019 10:12 PM, Chuck Guzis via cctalk wrote:


Personally, I preferred "the Naked Mini"

Used for porn world wide.:)

--Chuck

Re: How were 32-bit minis built in the 70s/80?

[ben via cctalk]

On 5/11/2019 9:28 PM, allison via cctalk wrote:

On 05/11/2019 09:30 PM, ben via cctalk wrote:

On 5/11/2019 6:28 PM, allison via cctalk wrote:


Not all were 74181 based, Thats an early 1972 part and but 1975 it was
already getting old though useful as it evolved to 74S and 74F series.
The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
series was getting long in the tooth. Mask programable gate arrays were
in the 1000 and up gate level by 1980 and growing by doubles every 6
months to a year. Don't got get programmables like PAL/GAL logic.
There was a lot of designs and even inside DEC you might see several
approaches depending on what machine and the specific date.  For example
the 780, 750 and 730 used very different technology.  I will not go into
those that also went the ECL {10K, 100K, 1M families] route.


74181 is FAST, but I disagree with the way most computer architecture is


TTl in general is slow a ALU based on 181 is hitting the wall at 5mhz
with 12 or 32 but carry lookahead.


No BUT's

I have my cpu designed for 1976, with NO pipeline and a 6900 memory 
cycle @ .75 us. I suspect about half the speed and half the price

had it been built in that era compared to a pdp 11.


designed. You have a fast micro code cycle, that is out of sync with
main memory, that tries to emulate a Harvard? Memory model.
It looks fast only on paper or demo programs sadly.
The few schematics I have seen (PDP 8/11) have 74H logic hidden
inside so you can't say they are pure TTL logic.


Yes, they are mostly TTL and the typical 8efm use MSI ttl such as
7481, a bunch of them.

I'm likely one of the few that took a 8E and ran semiconductor ram then
pushed the clock up to the breaking point and you get to about 4x and
you start getting timing errors and critical path delays that mess with
the logic.  However at 4X you doing a lot and decently fast but you
needs a faster generation of logic.



  A cpu instruction has 4 parts in general
  a) getting the instruction and literal data from memory
  b) calculating the the effective address
  c) fetching the data from memory  c) ouputing data
  d) using the data d) saving to memory.




Many of those things can be done in parallel.

Or pipe lining, I don't mind tricks being used to
speed up a system,but knowing how slow a instruction
is, or what side effects can be very important.


The name for that is system overhead and PDP-8 had little and what it
did have was written in assembler for speed and compact code as it was
also space constrained.


I don't know, I suspect 3-4 users would bog down a 8 time sharing.
mind you time sharing meant back then meant 4 people editing files
not like to day, where 3 or 4 windows are running with 30 back ground tasks.

It was a marvel how the machines worked with so little core.


Allison, have the shirt.

I have the paper tape. :)
Ben.

Re: How were 32-bit minis built in the 70s/80?

[Chuck Guzis via cctalk]

On 5/11/19 8:52 PM, Nigel Williams via cctalk wrote:
> Marketing at the time even had a catchy name for the 32-bit minicomputer:
> 
> https://en.wikipedia.org/wiki/Superminicomputer
> 


Personally, I preferred "the Naked Mini"

https://www.computerhistory.org/revolution/minicomputers/11/359

--Chuck

Re: How were 32-bit minis built in the 70s/80?

[Nigel Williams via cctalk]

Marketing at the time even had a catchy name for the 32-bit minicomputer:

https://en.wikipedia.org/wiki/Superminicomputer

Re: How were 32-bit minis built in the 70s/80?

[allison via cctalk]

On 05/11/2019 09:30 PM, ben via cctalk wrote:
> On 5/11/2019 6:28 PM, allison via cctalk wrote:
> 
>> Not all were 74181 based, Thats an early 1972 part and but 1975 it was
>> already getting old though useful as it evolved to 74S and 74F series.
>> The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
>> series was getting long in the tooth. Mask programable gate arrays were
>> in the 1000 and up gate level by 1980 and growing by doubles every 6
>> months to a year. Don't got get programmables like PAL/GAL logic.
>> There was a lot of designs and even inside DEC you might see several
>> approaches depending on what machine and the specific date.  For example
>> the 780, 750 and 730 used very different technology.  I will not go into
>> those that also went the ECL {10K, 100K, 1M families] route.
> 
> 74181 is FAST, but I disagree with the way most computer architecture is

TTl in general is slow a ALU based on 181 is hitting the wall at 5mhz
with 12 or 32 but carry lookahead.


> designed. You have a fast micro code cycle, that is out of sync with
> main memory, that tries to emulate a Harvard? Memory model.
> It looks fast only on paper or demo programs sadly.
> The few schematics I have seen (PDP 8/11) have 74H logic hidden
> inside so you can't say they are pure TTL logic.

Yes, they are mostly TTL and the typical 8efm use MSI ttl such as
7481, a bunch of them.

I'm likely one of the few that took a 8E and ran semiconductor ram then
pushed the clock up to the breaking point and you get to about 4x and
you start getting timing errors and critical path delays that mess with
the logic.  However at 4X you doing a lot and decently fast but you
needs a faster generation of logic.

> 
>  A cpu instruction has 4 parts in general
>  a) getting the instruction and literal data from memory
>  b) calculating the the effective address
>  c) fetching the data from memory  c) ouputing data
>  d) using the data d) saving to memory.
> 
Many of those things can be done in parallel.

Whoever RMW cycles on memory even with very fast memory will slow the
system as you have cycles that cannot be interrupted mostly in the
slow memory.

> It is very hard to speed up this cycle because this has
> sync to extenal memory. Memory is the bottleneck
> is the true speed limit in any sytem. Add in virtual
> memory and in multitasking and graphics
> no wonder the PDP 8 at with TTL gives better response
> time.

Memory is often the bottleneck then IO especially block IO.

The response time of PDP8 was mostly due to a simple OS and nothing to
get in the way.

The name for that is system overhead and PDP-8 had little and what it
did have was written in assembler for speed and compact code as it was
also space constrained.

Allison, have the shirt.

> Ben.
> PS: this message was delayed for about a minute as
> background program froze the sytem.
> 

Re: How were 32-bit minis built in the 70s/80?

[Jon Elson via cctalk]

On 05/11/2019 06:14 PM, Warren Toomey via cctalk wrote:

I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
how were 32-bit minis built in the late 70s and early 80s? In particular,
how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
reading A Soul of a New Machine) that PALs were also used.

Did companies get custom chips fabricated, or was it all off-the-shelf chips
with a few PALs sprinkled in?


There were also the AMD2901, 2903, 29203 family of bit-slice 
components, with the 2910 sequencer.  I built a 32-bit basic 
microengine in about 1982, but the software development 
effort eventually led me to stop work on it.  I was planning 
to implement the IBM 360 instruction set, with extensions, 
as it was very easy to implement with microcode.


See http://pico-systems.com/stories/1982.html  for some 
description and photos.


Apollo built some machines which I think were programmed at 
the microinstruction level, without microcode, using 2903's, 
I think.


The VAX 11/780 used 74S181 ALU chips, I think.  There were 
not all that many 32-bit minis.
I can think of Interdata 7/32 and 8/32 models that were 
32-bit.  SEL also made a 32-bit mini.
The VAX 11/780 was completely done with off-the-shelf ICs.  
Later VAXes went to semi-custom ICs, and the MicroVAX line 
used full-custom ICs.  I suspect many other makers were so 
small, they could only use off the shelf parts.


Jon

Re: Possible PUTR bug?

[Fred Cisin via cctalk]

On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:

Add to that, that really good "C" compilers for the x80/x86 took some
time to mature.  My first C on an 8086 was Lattice; compiled on a
floppy-based system.


DeSmet was in my price range,  . . .


But then Microsoft MASM 1.0 was terrible in its
own right as well--the list of errata was quite long.


"To make a file of that list, you are going to need more disk space."


I remember mumbling to myself "that's not what I wrote!".


Version 5.0? was the first to come with materials that could even be 
called "documentation".
But, I had been playing confusedly with MASM 1.0 since the day that it 
came out.

Re: How were 32-bit minis built in the 70s/80?

[Charles Dickman via cctalk]

On Sat, May 11, 2019 at 8:50 PM Steve Malikoff via cctalk <
cctalk@classiccmp.org> wrote:

> I could be remembering incorrectly but I think the Gould PN6080 mini we
> had exclusively for third year
> comp sci at Macquarie Uni in the mid/late 80s was 32-bit made up of
> AMD2900 family logic (2901 ALU's).
>

Purdue EE had I think 2 Gould PowerNode 9080s. I don't know anything about
the internals, but Purdue EE was doing development or testing for them. It
might have been a port of 4.3 BSD. As an undergraduate you could get an
account on en.ecn.purdue.edu for the asking and it was significantly faster
than the overloaded Dual VAXen. It also crashed from time to time.

-chuck

Re: How were 32-bit minis built in the 70s/80?

[Chuck Guzis via cctalk]

On 5/11/19 4:14 PM, Warren Toomey via cctalk wrote:
> I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
> how were 32-bit minis built in the late 70s and early 80s? In particular,
> how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
> reading A Soul of a New Machine) that PALs were also used.

What logic family?  There were some minis built with ECL for example.

--Chuck

Re: Possible PUTR bug?

[Chuck Guzis via cctalk]

On 5/11/19 2:00 PM, Fred Cisin via cctalk wrote:

> Although I enjoyed DeSmet C, I used Microsoft C for all subsequent high
> level language progams that I wrote.  For example, I wrote the screen
> capture TSR of "XenoFont" in MASM, and the printing program in Microsoft
> C; I wrote "Sales tax Genie" (TSR) in MASM, but then later renamed the
> .COM file to .EXE to use it as the "stub" program of a Microsoft C
> Windoze program, to have a single file that could load the TSR in DOS,
> AND be able to run as a Windoze program.  I never got around to redoing
> the TSR formats to be able to ALSO load them as device drivers (lets you
> get them into lower memory!); I intended to eventually create a single
> executable file format that could be loaded by CONFIG.SYS, CMD.COM, AND
> Windows.

My first FILES-11 RX01 read-conversion tool was written in PL/M and ran
on an MDS800.

My second FILES-11 RX01 reading/conversion utility was written largely
in FORTRAN.  System was an 8080 S100 box with a WD1771 controller.

C on an 8080/85 system seems like a horrible waste of hardware, owing to
the need for procedure-local variables.  Stack-based addressing isn't
pretty.  Basically to load a 16-bit stack-based integer into BC you have
to do something like this:

   LXI  H,offset
   DAD  SP
   MOV  C,M
   INX  H
   MOV  B,M

Add to that, that really good "C" compilers for the x80/x86 took some
time to mature.  My first C on an 8086 was Lattice; compiled on a
floppy-based system.  But then Microsoft MASM 1.0 was terrible in its
own right as well--the list of errata was quite long.  I remember
mumbling to myself "that's not what I wrote!".

--Chuck

Re: How were 32-bit minis built in the 70s/80?

[ben via cctalk]

On 5/11/2019 6:28 PM, allison via cctalk wrote:


Not all were 74181 based, Thats an early 1972 part and but 1975 it was
already getting old though useful as it evolved to 74S and 74F series.
The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
series was getting long in the tooth. Mask programable gate arrays were
in the 1000 and up gate level by 1980 and growing by doubles every 6
months to a year. Don't got get programmables like PAL/GAL logic.
There was a lot of designs and even inside DEC you might see several
approaches depending on what machine and the specific date.  For example
the 780, 750 and 730 used very different technology.  I will not go into
those that also went the ECL {10K, 100K, 1M families] route.


74181 is FAST, but I disagree with the way most computer architecture is
designed. You have a fast micro code cycle, that is out of sync with
main memory, that tries to emulate a Harvard? Memory model.
It looks fast only on paper or demo programs sadly.
The few schematics I have seen (PDP 8/11) have 74H logic hidden
inside so you can't say they are pure TTL logic.

 A cpu instruction has 4 parts in general
 a) getting the instruction and literal data from memory
 b) calculating the the effective address
 c) fetching the data from memory  c) ouputing data
 d) using the data d) saving to memory.

It is very hard to speed up this cycle because this has
sync to extenal memory. Memory is the bottleneck
is the true speed limit in any sytem. Add in virtual
memory and in multitasking and graphics
no wonder the PDP 8 at with TTL gives better response
time.
Ben.
PS: this message was delayed for about a minute as
background program froze the sytem.

Re: How were 32-bit minis built in the 70s/80?

[Steve Malikoff via cctalk]

Warren said
> I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
> how were 32-bit minis built in the late 70s and early 80s? In particular,
> how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
> reading A Soul of a New Machine) that PALs were also used.
>
> Did companies get custom chips fabricated, or was it all off-the-shelf chips
> with a few PALs sprinkled in?
>
> Thanks, Warren

I could be remembering incorrectly but I think the Gould PN6080 mini we had 
exclusively for third year
comp sci at Macquarie Uni in the mid/late 80s was 32-bit made up of AMD2900 
family logic (2901 ALU's).

I can't verify that now as it's hard to find anything much at all about the 
Gould mini's on the web (they
advertised them as superminis back then) but our machine running UTX/32 was 
pretty easy to bring to a
complete crawl with students all trying to get their Prolog assignments running 
before deadlines.

The lecturer didn't like us using 'cut' so the stack used to grow enormous and 
things would go downhill
from there. That, and the two disks - one good one that had the system and 
staff accounts filesystem and
the other chronically dodgy one that held the student accounts and temp - is 
about all I remember of it.

Steve

Re: How were 32-bit minis built in the 70s/80?

[ben via cctalk]

On 5/11/2019 5:14 PM, Warren Toomey via cctalk wrote:

I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
how were 32-bit minis built in the late 70s and early 80s? In particular,
how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
reading A Soul of a New Machine) that PALs were also used.

Did companies get custom chips fabricated, or was it all off-the-shelf chips
with a few PALs sprinkled in?

Thanks, Warren



8 bit computers are EVIL. REPENT DEAR BROTHER.
I WILL PRAY FOR YOU.
24 bit computers are HOLY AND DIVINE.
Building a  12/24 BIT CPU with 8 bit I/O.
(back on topic)

Early 70's computers other than IBM used TTL, and fast
core memory with mostly a 16 bit word width. Other than
the PDP 11, most computers where adapted from the transistor
era with tweaks added for banks of memory.When the late 70's
came around commercial customers had a large main frame computer
or small control computer from a few years earlier with FAST
TTL (S)logic, PDP 11's, IBM 360's or clones,or TTL standard/H like
PDP 8 or NOVA computer.

Bit slice logic like the 2901 alu, (1975) would make for
nice low cost 16/32 bit cpu with byte load/store.
The market for 32 bit computers was decided however
to sell FAST LARGE systems (floating point/64K+ memory)
like the VAX (S TTL) or upgrade other designs like the NOVA computer with
Custom or semi-custom (PAL logic) logic.
INTEL being slow with the forgotten APX 432 design
came out with 8086 leaving us with the defective CPU's
of today.

Ben's view point.

I am doing  my computer with a FPGA development system
for design logic and testing and later using 2901's
and LS TTL with 3 proms used for the alu/control cards.
 I have A nice 8/16/32 cpu design with 512KB of memory
(2901 alu )but I can't get it to route correctly. The 12/24 bit
cpu just fits with the FREE develpment software.
For a few K $ I can get the better version with being able
route by hand my logic to meet timing specs.
Once hardware SD card/serial port and software are working
I then will port the design to TTL.
I may need to write my own tiny langage to boot strap
my system.

Ben.
PS:
16 bit computer format

[op 3..1][ac 3..1][mode 3..1][ix 3..1][aux][k 3..1]
The tricky part is K is the upper 3 address bits
to extend 16 bit offset to 19 bits or a auto indexing
mode. This would be valid memory for the late 70's
early 1980's but not for today.

Re: How were 32-bit minis built in the 70s/80?

[Dennis Boone via cctalk]

 > I'm building my own 8-bit CPU from TTL chips, and this caused me to
 > think: how were 32-bit minis built in the late 70s and early 80s? In
 > particular, how was the ALU built? I know about the 74181 4-bit ALU,
 > and I know (from reading A Soul of a New Machine) that PALs were also
 > used.

I'd be curious to know how many designs used the 74181 instead of
scratch logic in the early 70s.  I doubt many custom chips were done
until mid-late 80s.

Prime used 74181 chips for some of their CPUs.  I have a 150 CPU board
(1980, though it was likely a relatively minor rehash of an older
board), for example.

Prime and Data General both used AMD2901 (1975) family stuff in some of
their designs.

Prime definitely had a lot of the logic into VLSI chips on their CPU
boards in the late 80s time frame.  By the end (early 90s), a CPU board
was one or two big CMOS chips and a lot of empty space.

De

Re: How were 32-bit minis built in the 70s/80?

[allison via cctalk]

On 05/11/2019 07:14 PM, Warren Toomey via cctalk wrote:
> I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
> how were 32-bit minis built in the late 70s and early 80s? In particular,
> how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
> reading A Soul of a New Machine) that PALs were also used.
> 
> Did companies get custom chips fabricated, or was it all off-the-shelf chips
> with a few PALs sprinkled in?
> 
> Thanks, Warren
> 

Lets see the VAX 11/780 hit the street in 78 and DG followed with theirs
soon after and of course the IBM 360 was 32bit so the number can be
fairly large.  Soul of a new machine was more romantic but it was of
early VAX era and the Eclipse was the result.

Reading the following woould be better as it compared and contrasts DEC
hardware and instill an idea of ISA design and then its hardware
implementation.  Its a good read and free!

http://www.bitsavers.org/pdf/dec/_Books/BellComputerEngineering.pdf

Building now is more based on what you have or can get not what was used
then as most were pushing for speed vs price and the available parts
were never fast enough and cost too much.

Not all were 74181 based, Thats an early 1972 part and but 1975 it was
already getting old though useful as it evolved to 74S and 74F series.
The 82s100 and 105 series were out there and even by 1980 the AMD 2900C
series was getting long in the tooth. Mask programable gate arrays were
in the 1000 and up gate level by 1980 and growing by doubles every 6
months to a year. Don't got get programmables like PAL/GAL logic.
There was a lot of designs and even inside DEC you might see several
approaches depending on what machine and the specific date.  For example
the 780, 750 and 730 used very different technology.  I will not go into
those that also went the ECL {10K, 100K, 1M families] route.

Your question has to be based on a specific date window and narrow at
that as keep in mind by 1978 16bit CPUs on silicon were a fact
(Ti9900, SBP9900, F11, T11, Nova, 8086).

How were 32-bit minis built in the 70s/80?

[Warren Toomey via cctalk]

I'm building my own 8-bit CPU from TTL chips, and this caused me to think:
how were 32-bit minis built in the late 70s and early 80s? In particular,
how was the ALU built? I know about the 74181 4-bit ALU, and I know (from
reading A Soul of a New Machine) that PALs were also used.

Did companies get custom chips fabricated, or was it all off-the-shelf chips
with a few PALs sprinkled in?

Thanks, Warren

Earlier microfilm retrieval systems (Was: What is this?

[Fred Cisin via cctalk]

On Fri, 10 May 2019, Chuck Guzis via cctalk wrote:

Reading about WALNUT, it was more than a little unusual for its time.
The idea was the setup stored (photographically) almost a million images
using a non-silver process.  The images were indexed digitally and the
index was searchable.   The output appears to be a standard  aperture
card.  Although both of the references that I found mention
Kalfax/Kalvar media, WikiP says that the systems delivered to the CIA
used a different diazo process that was apparently more stable than the
Kalvar process.


There have been quite a few systems for computerized retrieval of 
photographic images.
Besides "aperture cards" there were a number of earlier systems that 
encoded an ID on the microfilm.


Lest we be overly concerned with that using too much of the microfilm 
physical space, keep in mind that soundtrack was often included on 
16mm and 35mm movies.  Maurer, and others?, had up to EIGHT parallel 
analog audio tracks in the margin of movie film.  Eight bit parallel!?!


90 years ago, Emmanuel Goldberg built a system:
http://people.ischool.berkeley.edu/~buckland/statistical.html
http://people.ischool.berkeley.edu/~buckland/goldberg.html
http://people.ischool.berkeley.edu/~buckland/goldbush.html
One of several reasons why Goldberg is largely unknown is that he was 
working in Germany (Zeiss) when the Nazis came into power, and Zeiss 
had to systematically wipe the records of existence of Jewish engineers.
His optical reading of the metadata was done by "complement" or 
"extinction".



Vannevar Bush's speculative article "As We may Think" (Atlantic Monthly 
1945, although first written in 1939) suggested possibilities for the 
"Memex".
It used "coindcident" templates, instead of "extinction" for the matching. 
It also talked about the microfilm remaining in motion, with a Xenon 
flash tube to "stop" the motion.  The level of magnification and the 
speed that he talked about moving the film were not consistent with the 
speed of the flash tubes that were actually AVAILABLE at the time, nor in 
the 1950s.


Vannevar Bush did not reference the work of predecessors, such as Goldberg 
and a few others, although there is some evidence that he had at least 
heard about Goldberg's work.  Atlantic Montlhly was popular press, not a 
"peer-reviewed" academic journal, so policies of citations were lax.


Bush seems to have not been a believer in hierarchical information 
storage, and used examples of flipping from documents to other documents 
in "trails".

Ted Nelson credits that with inspiration for "hypertext".
Berners-Lee credits Ted Nelson's hypertext with inspiration for WWW.

"As We May Think" has caused Bush to often be considered the "father of 
Information Science", which frankly, I don't feel is much more accurate 
than some of the modern crediting of Steve Jobs and Bill Gates with 
"inventing" the computer.

Re: Extra copy of "LSI-11, PDP-11/03 User's Manual"

[Todd Goodman via cctalk]

Hi Noel,

If you don't get any takers, I'm interested and will happily reimburse 
you your entire ebay cost (including shipping to you) as well as 
shipping to me.


Thank you!

Todd

On 5/10/2019 2:23 PM, Noel Chiappa via cctalk wrote:

As a result of an inventory error on my part, I wound up with an extra copy
of "LSI-11, PDP-11/03 User's Manual" (EK-LSI11-TM-003).

I'd like to pass it along to someone, provided I'm reimbursed _most_ of
my eBait expenditure on it (it was not, alas, cheap). Anyone interested?

Noel

Re: Possible PUTR bug?

[Fred Cisin via cctalk]

In the case of RX50 on the PC, it doesn't matter.  The format is 10
sectors of 512 bytes, which isn't supported by the PC BIOS in any
regular sense (9 sectors is the norm).  So most packages that deal with
FILES-11 RX50 floppies on a PC use direct hardware (chip) access and
bypass the BIOS completely.  PUTR is one such package.

If the only problem is that there are 10 sectors per track, that can
still be done WITH THE BIOS, using Int1Eh in conjunction with Int13h,
except for the potential problems with 765 index "flash blindness".  For
formatting tracks, you can use Int1Eh to alter the sector gaps.



On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:

But that isn't the only issue, even assuming that you have a
well-behaved BIOS. Many are not.

The other gotcha is that if you want to run a 5.25" HD drive declared as
a "1.2M" in the BIOS, the assumption made by the BIOS is that you want
to double-step.  That's a harder one to defeat, although it can be done
by tinkering with the flags in 0490h and 0491h, but due to BIOS
implementation differences, this is not perfectly reliable.

Of course, you can, as mentioned, modify a 1.2M drive to run at 300 RPM
and tell the BIOS that it's a 720K unit, but you won't be able to handle
48 tpi disks without a device driver to do the double-stepping for you.
Telling potential customers how to modify a drive that you've never seen
is even more entertaining, particularly in the pre-web world. So you're
back in the same boat.

All in all, using the BIOS to do RX50 work was a support nightmare for
me--there was always *someone* out there with a no-name PC using a
strange BIOS that wouldn't work.

I found that doing direct access was far more reliable in the long run.
(see SIMTEL20 RAINDOS for my implementation of a DOS device driver for
Rainbow 100 floppies, circa 1990).


Oh, SO TRUE!

It is FUNNY (not "ha-ha") that although the stated purpose of having the 
BIOS separate from the file system and command processor was to cover over 
incompatabilities ("DOS est omnis divisa in partes tres"), the hardware 
was sometimes more compatible than the "compatability layer" made up of 
the BIOS!


I always advised everybody not to use a 96tpi drive for wwriting to 48tpi 
disks.  Too many people refused to understand that you had to format a 
virgin (or bulk-erased) disk in the 96tpi as the only way to avoid the 
failure to completely RE-write the full width of the track on disks that 
would later go through attempts to read on a 48tpi.


I always tested everything thoroughly on real IBM hardware.  Not that I 
could comfortably afford that premium, but it let me make the 
sanctimonious statement "It works on REAL IBM.  If it doesn't work on YOUR 
after-market machine, that means that it is not TRULY compatible.  That's 
not necessarily BAD, if they wanted to do things in a BETTER WAY, but we 
can't guarantee that all "compatible" machines are "compatible ENOUGH". 
Please provide us as much detail as you can of any problems, and we will 
make a good faith effort to make changes to be able to include your 
systems."



PC-WORLD once used Xeno-Copy as "the acid test of compatability"!  They 
failed to mention that they used a much earlier version than what was 
being sold, and that the current version at the time that they used the 
early version for testing would work on every one of the machines that 
they said could not run it.
I considered [and started] writing a PC TEST program called "XenoProbe : 
The Acid Test" that would seek out and identify differences between 
machines, starting with exploiting side effects to identify the 
processor, etc.


The reason for the early incompatability, as many of you have figured out, 
was that what little assembly/machine language that I know, I learned 
working on XenoCopy. I do not expect to live long enough to ever catch up 
with the knowledge and abilities of many on this list.  (Chuck and ARD are 
not the only ones)


In fact, the FIRST version (as used by PC-World) was written in BASIC, and 
compiled with BASCOM, using Int1Eh and a call to Int13h.  As suggested by 
Brett Salter, I passed the return value back through the Floating Point 
Accumulator!  THAT was what made it incapable of running on anything other 
than REAL IBM 5150.  The title screen SAID that it would not work on 
anything other than IBM.
I also had a trivial piece of self-modifying code, 
and that is how I found out about the change in the pre-fetch buffer size 
from 8088 to 80286.


I rewrote version 2.00 in DeSmet C, with cleaned up calls from high level 
to machine language functions, saving and restoring screens, etc.


Although I enjoyed DeSmet C, I used Microsoft C for all subsequent high 
level language progams that I wrote.  For example, I wrote the screen 
capture TSR of "XenoFont" in MASM, and the printing program in Microsoft 
C; I wrote "Sales tax Genie" (TSR) in MASM, but then later renamed the 
.COM file to .EXE to use it as the "stub" program of a Microsoft

Re: Possible PUTR bug?

[Chuck Guzis via cctalk]

On 5/11/19 11:40 AM, Fred Cisin via cctalk wrote:
> On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:
>> In the case of RX50 on the PC, it doesn't matter.  The format is 10
>> sectors of 512 bytes, which isn't supported by the PC BIOS in any
>> regular sense (9 sectors is the norm).  So most packages that deal with
>> FILES-11 RX50 floppies on a PC use direct hardware (chip) access and
>> bypass the BIOS completely.  PUTR is one such package.
> 
> If the only problem is that there are 10 sectors per track, that can
> still be done WITH THE BIOS, using Int1Eh in conjunction with Int13h,
> except for the potential problems with 765 index "flash blindness".  For
> formatting tracks, you can use Int1Eh to alter the sector gaps.

But that isn't the only issue, even assuming that you have a
well-behaved BIOS. Many are not.

The other gotcha is that if you want to run a 5.25" HD drive declared as
a "1.2M" in the BIOS, the assumption made by the BIOS is that you want
to double-step.  That's a harder one to defeat, although it can be done
by tinkering with the flags in 0490h and 0491h, but due to BIOS
implementation differences, this is not perfectly reliable.

Of course, you can, as mentioned, modify a 1.2M drive to run at 300 RPM
and tell the BIOS that it's a 720K unit, but you won't be able to handle
48 tpi disks without a device driver to do the double-stepping for you.
Telling potential customers how to modify a drive that you've never seen
is even more entertaining, particularly in the pre-web world. So you're
back in the same boat.

All in all, using the BIOS to do RX50 work was a support nightmare for
me--there was always *someone* out there with a no-name PC using a
strange BIOS that wouldn't work.

I found that doing direct access was far more reliable in the long run.
(see SIMTEL20 RAINDOS for my implementation of a DOS device driver for
Rainbow 100 floppies, circa 1990).

--Chuck

RE: What is this?

[Tom Gardner via cctalk]

There is a section in Bashe et al, Early IBM Computers that suggests Walnut 
only went to the CIA.

 

The follow on project was  Cypress beginning in 1962:

“The main Cypress system, designed to store all information in digital form, 
was sometimes called the Trillion-bit File. This system was very exploratory 
and expensive; it necessitated mastery over several technologically advanced 
engineering fields, among them electron- beam recording. (The project continued 
for several more years and five systems were delivered—three to AEC 
laboratories and two to NSA.)101

It became the 1360 Photo Digital Store

“101. Kean, 1977: pp. 79-80. Under the name IBM 1360 Photo-Digital Storage 
System, the first system was delivered on 30 September 1967 to the Lawrence 
Radiation Laboratory, Livermore, California; see R. M. Furman, 15 May 1968: 
“IBM 1360 Photo-Digital Storage System,” IBM Technical Report. For a technical 
description of the 1360, see J. D. Kuehler and H. R. Kerby, 1966: “A 
Photo-Digital Mass Storage System,” Proceedings of the Fall Joint Computer 
Conference, pp. 735-742. A simpler system, which stored images on microfilm, 
was announced as the IBM 1350 Photo Image Retrieval System in May 1966 and soon 
withdrawn for lack of sufficient acceptance.”

Tom

 

-Original Message-
From: Chuck Guzis [mailto:ccl...@sydex.com] 
Sent: Friday, May 10, 2019 1:13 PM
To: Donald via cctalk
Subject: Re: What is this?

 

On 5/10/19 12:45 PM, Donald via cctalk wrote:

>   
> http://www.myimagecollection.com/webpics/unknownmachine.jpg

> 

>  

> 

> The model number looks like 9603.  Can't tell for sure.  The box in 

> back has the 14xx flavor.

 

IBM 9603 WALNUT - Microfilm image storage and retrieval system.   Read

about it on PDF page 13 here:

 

 

 
http://nopr.niscair.res.in/bitstream/123456789/28351/1/ALIS%2014%282%29%2062-75.pdf

 

Circa 1960.

 

There's more on the web; just search on "IBM WALNUT"

 

--Chuck

 

Re: PDP-11/40 available, Arizona

[Fred Cisin via cctalk]

On Sat, 11 May 2019, ED SHATTNER wrote:

JUST   DOWN THE   ROAD A  FEW  HOURS  FROM  US HERE!
ED#


You should go check it out.  Even if there isn't anything that you want, 
you might be able to help, or store things for those who can't transport 
right away.

Re: Possible PUTR bug?

[Fred Cisin via cctalk]

On Sat, 11 May 2019, Chuck Guzis via cctalk wrote:

In the case of RX50 on the PC, it doesn't matter.  The format is 10
sectors of 512 bytes, which isn't supported by the PC BIOS in any
regular sense (9 sectors is the norm).  So most packages that deal with
FILES-11 RX50 floppies on a PC use direct hardware (chip) access and
bypass the BIOS completely.  PUTR is one such package.


If the only problem is that there are 10 sectors per track, that can still 
be done WITH THE BIOS, using Int1Eh in conjunction with Int13h, except 
for the potential problems with 765 index "flash blindness".  For 
formatting tracks, you can use Int1Eh to alter the sector gaps.

Re: Possible PUTR bug?

[Fred Cisin via cctalk]

On Sat, 11 May 2019, Douglas Taylor via cctalk wrote:
Finding a PC that supports the 5-1/4" floppy drive is difficult, the BIOS or 
FDC chips only support 3-1/2" floppies in many late model PC's.  It appeared 
only a few of the older PC's that supported the 5-1/4" drives could actually 
change the spindle speed so you could read/write RX50 format.


{Written in a hurry; making a list of all of the errors is left as an 
exercise for the reader]


You can fool the computer in software. 
Most of those problems are with DOS/Windoze.
There is little or no problem with the FDC (other than as detailed in #3 
below). 
The main change that you are referring to was that some companies 
cut corners and stopped supporting a 300K bits per second data transfer 
rate that had been needed to use "360K" floppies in SOME early "1.2M" 
drives.   Don't use THOSE "1.2M" drives on THOSE computers for reading 
5.25" 96TPI "720K"/"800K" floppies.


1) the computer can't tell the difference between a "720K" 3.5" drive and 
a "720K" 5.25" drive, such as Tandon TM100-4, Teac 55F, Mitsubishi 4853, 
or Shugart/Panasonic/Matsushita 465.  My favorite was the 465, since it 
didn't have the "NEED for index" mentioned in #3 below.
The methods of being able to figure out which kind of drive it REALLY is 
are hardly never implemented in PCs.  (cf. undocumented algorithms to 
identify which processor is present)
If you are concerned about the menus in the CMOS SETUP or the choices in 
the DOS FORMAT program, LIE TO IT!  (Tell it that the tax increase is 
TEMPORARY, that the check is in the mail, that the current software 
release is completely bug-free)


When 3.5" drives and disks came out (also 3" and 3.25"), they were usable 
in ALL of the 5150s, 5160s, and 5170s.  With 5170s, you just had to LIE 
to the CMOS SETUP and tell the BIOS that your "720K" 3.5" drive was a 
"360K" 5.25" drive. 
FDC and BIOS couldn't tell the difference.  But, now, you need to lie in 
the other directions.
DOS support of "720K" was finally included in certain OEM versions of 
MS-DOS 2.11; and then got full support in MS/PC-DOS 3.20.  For use of the 
DOS formats of those drives, you were instructed to use DRIVER.SYS, or 
the partially undocumented DRIVPARM (present, but not documented in 
PC-DOS, because it did not work with some "real" IBM BIOS'es and would 
give an "UNRECOGNIZED" error, although the same boot disk would work with 
after-market BIOS!)



2) There did exist briefly, some "1.2M" 5.25" drives that could only run 
at 360 RPM, and required a 300K bits per second data transfer rate for 
handling "360K" and "720K" floppies in the "1.2M" drive.  Support for that 
data transfer rate might not be present in cut-corner "modern" PCs.
On those machines, you need to either use a "720K" 5.25" drive, or, if you 
need to use a "1.2M" drive, it needs to be one that can run at 300 RPM. 
Check the jumper settings.



3) However, SOME "400K" and "800K" floppies do still have a problem. 
WD style disk controllers, such as the 179x series and some other custom 
disk controllers are capable of writing closer to the index pulse than the 
NEC 765 style FDCs can handle.  The NEC style needs a little time after 
the index pulse before it can read.  Some compare that to "flash 
blindness", where a human can not see anything immediately after a photo 
flash.


There are numerous kludges to get around that.  On most drives (NOT 
including most TEAC 55), you can successfully read those diskettes by 
physically blocking the index hole of the floppy, using a SOLIDLY applied 
write-protect tab. (Do I really need to tell you to make sure that it 
won't fall off in the drive?)


OR, by fashioning a floppy drive data cable with a SWITCH in series with 
the INDEX signal.


Both of those approaches have a very minor problem that many unrelated 
disk errors will be mis-reported as being "DRIVE NOT READY" (error code 
80h), since the FDC doesn't see an index pulse.


Some people have had some success by slightly reducing the motor speed 
(nominally 300 RPM) of the drive!


If you still have access to the machine whose disks you want to read, you 
can FORMAT a disk with an adequate index gap (using software on your PC), 
take THAT disk back to the alien machine, copy the files onto it, and then 
bring it back to the PC to read.  That also works for a few other minor 
incompatabilities, such as formats that use an incorrect value in any of 
the sector header fields.


--
Grumpy Ol' Fred ci...@xenosoft.com
XenoSofthttp://www.xenosoft.com

Re: Possible PUTR bug?

[Chuck Guzis via cctalk]

On 5/11/19 8:22 AM, Douglas Taylor via cctalk wrote:

> Finding a PC that supports the 5-1/4" floppy drive is difficult, the
> BIOS or FDC chips only support 3-1/2" floppies in many late model PC's. 
> It appeared only a few of the older PC's that supported the 5-1/4"
> drives could actually change the spindle speed so you could read/write
> RX50 format.

I have to admit that I don't follow this one.  Although I'll admit the
possibility that some odd chipset doesn't support the 300Kbps data rate
needed to use normal "360K" floppies in a 5.25" HD drive spinning at 360
RPM, I've yet to run across one.  Finding a modern PC with legacy floppy
support is a different issue.   Either using a 5.25" DD-only drive (such
as a Teac FD55F) or jumpering a 5.25" HD drive to use 300 RPM are both
options.  From the standpoint of the hardware, there's no difference
between a "720K" 3.5" drive and a 5.25" one so configured.

In the case of RX50 on the PC, it doesn't matter.  The format is 10
sectors of 512 bytes, which isn't supported by the PC BIOS in any
regular sense (9 sectors is the norm).  So most packages that deal with
FILES-11 RX50 floppies on a PC use direct hardware (chip) access and
bypass the BIOS completely.  PUTR is one such package.

The real issue is that the need for *writing* RX50 FILES-11 format
diskettes is virtually non-existent.  With the exception of PUTR, the
packages that I've seen (dating from 1984) are all for *reading* them.
Heck, I've written a couple myself, including one for CP/M-80.

--Chuck

Re: Possible PUTR bug?

[Douglas Taylor via cctalk]

I understand your frustration, because all I really wanted to do was 
read/write RX33 and RX50 5-1/4" floppies to move data in and out of my 
microPDP11.  Once, I wanted to write an RX23 3-1/2" floppy with OpenVMS 
PAK files that could be read on an DEC Alpha.


Finding a PC that supports the 5-1/4" floppy drive is difficult, the 
BIOS or FDC chips only support 3-1/2" floppies in many late model PC's.  
It appeared only a few of the older PC's that supported the 5-1/4" 
drives could actually change the spindle speed so you could read/write 
RX50 format.


I dedicated a DELL XPS 233H to this task, 32MB memory, Pentium II cpu.  
Boots from 3GB hard disk, DOS and Win 3.1 (if you so need it).  I also 
have an IDE to CF card adapter standing by when the hard disk dies.  
Love to have something with a smaller form factor, but it gets the job done.


Doug


On 5/11/2019 10:35 AM, Charles via cctalk wrote:
Just an update... I spent an entire long afternoon wrestling with that 
old PC, trying to find some combination of HDD jumpers and BIOS 
settings that would allow the XP hard drive to boot with another drive 
attached (either on the slave connector or the secondary channel with 
the CD-ROM removed). No dice.


So I had the bright idea to use Minitool's Partition Wizard, and 
shrink my Windows partition so there'd be room for a  newDOS partition.
But it won't even run (probably because I have only 64 MB RAM on that 
box). Grrr. It's unbelievably slow anyhow, so more SDRAM on order, 
which is really cheap these days.
I'd get a newer PC for the workbench, but need to keep the old 
motherboard because there are a couple of devices (including a PB-10 
PROM programmer) which are ISA slots.


So, this has become a Windows/PC (ugh) project instead of just being 
able to play with my PDP-11...

Re: PDP-11/40 available, Arizona

[ED SHARPE via cctalk]

JUST   DOWN THE   ROAD A  FEW  HOURS  FROM  US HERE!


ED#
In a message dated 5/11/2019 2:33:48 AM US Mountain Standard Time, 
cctalk@classiccmp.org writes:
Great! Good luck with the visit. The other day I wrote to Kristina to express 
interest.

> On 11 May 2019, at 04:38, Fritz Mueller via cctalk  
> wrote:
> 
> 
>> On 5/10/19 6:42 PM, Adam Thornton via cctech wrote:
>> I have been invited out to the site tomorrow morning to take an inventory of 
>> what’s there (I live near the machines).
>> I imagine that I may well have a lot of photos that I bring to the list and 
>> say “what is this?”
> 
> Standing by to help out!  Go get it, Adam -- (come on, you can _make_ room! 
> :-))

Re: Possible PUTR bug?

[Charles via cctalk]

Just an update... I spent an entire long afternoon wrestling with that old 
PC, trying to find some combination of HDD jumpers and BIOS settings that 
would allow the XP hard drive to boot with another drive attached (either on 
the slave connector or the secondary channel with the CD-ROM removed). No 
dice.


So I had the bright idea to use Minitool's Partition Wizard, and shrink my 
Windows partition so there'd be room for a  newDOS partition.
But it won't even run (probably because I have only 64 MB RAM on that box). 
Grrr. It's unbelievably slow anyhow, so more SDRAM on order, which is really 
cheap these days.
I'd get a newer PC for the workbench, but need to keep the old motherboard 
because there are a couple of devices (including a PB-10 PROM programmer) 
which are ISA slots.


So, this has become a Windows/PC (ugh) project instead of just being able to 
play with my PDP-11...

Re: PDP-11/40 available, Arizona

[Eduardo Cruz via cctalk]

Great! Good luck with the visit. The other day I wrote to Kristina to express 
interest.

> On 11 May 2019, at 04:38, Fritz Mueller via cctalk  
> wrote:
> 
> 
>> On 5/10/19 6:42 PM, Adam Thornton via cctech wrote:
>> I have been invited out to the site tomorrow morning to take an inventory of 
>> what’s there (I live near the machines).
>> I imagine that I may well have a lot of photos that I bring to the list and 
>> say “what is this?”
> 
> Standing by to help out!  Go get it, Adam -- (come on, you can _make_ room! 
> :-))

PDP-11/40 available, Arizona

[Adam Thornton via cctalk]

I have been invited out to the site tomorrow morning to take an inventory of 
what’s there (I live near the machines).

I imagine that I may well have a lot of photos that I bring to the list and say 
“what is this?”

The owner has assured me the machines will not be sent to the scrapper and that 
there are multiple interested parties, which is good, because I really don’t 
have a good place to put 8 cabinets of PDP-11.  Not that having an 11/40 
running Sixth Edition Unix wouldn’t be cool.

I’ll report back once I have an inventory.

Adam

Re: PDP-11/40 available, Arizona

[Fritz Mueller via cctalk]

On 5/10/19 6:42 PM, Adam Thornton via cctech wrote:

I have been invited out to the site tomorrow morning to take an inventory of 
what’s there (I live near the machines).
I imagine that I may well have a lot of photos that I bring to the list and say 
“what is this?”


Standing by to help out!  Go get it, Adam -- (come on, you can _make_ 
room! :-))

RE: HP 1000 A900 ("Magic") Questions

[Paul Birkel via cctalk]

>-Original Message-
>From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Glen Slick 
>via cctech
>Sent: Friday, May 10, 2019 1:34 PM
>To: General Discussion: On-Topic Posts
>Subject: Re: HP 1000 A900 ("Magic") Questions
>
>On Fri, May 10, 2019 at 4:14 AM Paul Birkel via cctech
> wrote:
>>
>> Aficionados;
>>
>> I'm interested in acquiring an HP1000 A900, in any form-factor.
>> (http://www.hpmuseum.net/display_item.php?hw=594)



>Another hard part is the 1 memory frontplane. Maybe it wouldn't be
>too hard to build an equivalent PCB if the proper connectors can be
>acquired. They are 3-row 96-pin connectors. Maybe common DIN 41612
>connectors would work, I haven't looked at that closely.

I can confirm that DIN 41612 connectors should work fine, along with a 4-layer 
PCB.  HP doesn't seem to have gone "odd-ball" in that particular design choice. 
 I'd need to get someone to buzz out the connections to ensure that they are 
1:1 all the way across before designing a PCB to fit.



>At a minimum you need either a 12005 serial card or a 12040 serial mux
>for a console interface. Both of those are fairly common, although you
>might pay more for cables than the boards if you don't build cables
>yourself. There are several firmware versions for the 12040 mux. If
>you have a D mux you need need VCP firmware 4020 or higher on the
>12203A cache controller.

Cables, and those specialized HP connectors, are always a pain.  I would need 
to make up my own, given my budget, I expect.  I do have one or two possible 
spares from a 21MX I/O environment that probably could be repurposed assuming 
that the edge-connectors match up ... which they may not.  We'll see.  Thanks 
for the notes about the firmware version issue.

>As you also said you need a 12009 HPIB card for a storage interface.
>Running HPDrive on a PC to emulate disk and tape drives works well if
>you don't have any real HPIB disk and tape drives. I managed to pick
>up a 12016 SCSI card. Those are rare and expensive.

I'll bet!  Yes, I was assuming that HPDrive would be the way to proceed; it's 
good to get confirmation on that point.  Also the availability of a suitably 
configured RTE.

paul