[cctalk] Re: ANSI-M (Mumps) and the VA

[Jay Jaeger via cctalk]

They can apply at epic systems in Verona, Wisconsin.  They are underlying 
infrastructure is based on mice and mumps.

Sent from my iPad

> On May 12, 2024, at 08:59, Bill Gunshannon via cctalk  
> wrote:
> 
> 
> With the VA dropping Vista what happens to that army of Mumps
> programmers they had?  Can't see much call for them in the IT
> world today.  Seems like a worse fate than COBOL Programmers.
> 
> bill

[cctalk] Re: Help request with fundraising campaign to save historic computers

[Jay Jaeger via cctalk]

On 5/3/2024 5:35 AM, Gianluca Bonetti via cctalk wrote:

Hello everyone


I am helping Museo del Computer with this fundraising effort in order to
save a large number of machines with significant historic value, including
some Sperry Univac systems.
Museo del Computer is a non-profit organization in northern Italy, run
solely by volunteer work and donors' money since governments are still not
interested in computer history.
Museo del Computer is one of the largest computer history museums
worldwide, with 4000 sqm between exhibition area and storage space, open to
the public upon booking.

This recovery expedition will go as far as 750km to load 100+ machines onto
3 lorries.
Gianluca Bonetti


Is there a list somewhere of the machines?

Also, if there are EXEC OS tapes there, make sure those are treated with 
care.  If they need help reading 7 track tapes and are willing to ship 
them to the US, I can recommend a contact who recently read a 7 track 
tape for me that dated back to the 1960s.


As far as vetting the legitimacy of the fund raising campaign, I did a 
little diggging.


First I saw that there is a website that folks may find useful.

http://www.museodelcomputer.org/

That website has a donations page, but the translation process makes it 
hard to find the link on that donation page, but I did see a link on the 
Italian version, and it does seem to point to the same place, so it 
seems legit.  (There is a link I found on that page near the end of this 
posting).


https://fundrazr.com/computermuseum?ref=ab_62Z1p5MB63862Z1p5MB638

Also, I followed a link from the above fundrazr that points back to 
their website donation page, which is reassuring:


http://www.museodelcomputer.org/index.php/nav=Informazioni.35/Language=ITA/MD=/SD=/Pagina=4

JRJ

[cctalk] Re: Help request with fundraising campaign to save historic computers

[Jay Jaeger via cctalk]

On 5/4/2024 11:46 AM, Sellam Abraham via cctalk wrote:

On Sat, May 4, 2024 at 9:28 AM Gianluca Bonetti via cctalk <
cctalk@classiccmp.org> wrote:


...
I am helping Museo del Computer with this fundraising effort in order to
save a large number of machines with significant historic value, including
some Sperry Univac systems.
...


I would want to know more of the story and also to see more photos before I
would consider donating.

Sellam


I'm on the same page with you, Sellam.  I would want to see a website, 
and a link to the donation page on that website before I would consider 
donating.


JRJ

[cctalk] Re: WTB: PSU for DEC PDP8F

[Jay Jaeger via cctalk]

On 1/12/2024 12:02 AM, Raymond Robinson via cctalk wrote:

Hi there,

I need a power supply for my PDP8F computer.
It is missing.

The PDP8F 19" chassis box came in 3 different depths,
600 mm (PSU front to back)
370 mm (PSU across the back)
300 mm (PSU front to back)

I need the shallow one, the 300 mm PSU front to back.
Do you have one available, or know where I can get one please.
Even if it is dead!

regards
ray



Did you ever find one?  If not, let me know - I *may* have one.

(Madison, WI, US)

JRJ

[cctalk] Re: EMP was: oscilloscopes

[Jay Jaeger via cctalk]

Paul, would you mind if I shared this on the Facebook EndFed Halfwave 
Antenna group?  Time and time again I see folks talk about putting in 
ground rods in for antennas and NOT bonding them to the electrical 
service ground rod.    In most (if not all) locations in the US, this 
kind of bonding is now a required part of the electrical code, and newly 
constructed houses (or ones that have their panels replaced) will 
typically have a "service ground' bus bar installed near the electrical 
panel.


(The ARRL book is a pretty good resource on this topic, too, but real 
life experience may convince some to think twice about what they are doing.)


https://www.arrl.org/grounding-and-bonding-for-the-amateur

JRJ

On 4/2/2024 10:13 AM, Paul Koning via cctalk wrote:



On Apr 2, 2024, at 11:01 AM, Jon Elson via cctalk  wrote:

On 4/2/24 00:03, Just Kant via cctalk wrote:

Accordimg to certain individuals on this list, going back a few years, 
electronics/computers can be damaged due to an electrical storm, presumably 
very intense activity, even while off. Go look through the archives.


I have had two incidents where nearby lightning strikes blew out components on 
gear I had.  Many years ago, I had two computers connected by a parallel port 
cable, and chips on both ends were popped by a strike that might have hit power 
lines about two blocks away.

About a decade ago, we had a lightning strike that hit trees half a block away. 
 It took out an ethernet port on one computer, and blew out a bunch of stuff on 
a burglar alarm I had built.  Both involved long wire runs.

Some years ago we had a lightning strike on the driveway next to the house.  It 
took out every single device directly or indirectly connected to the cable TV 
(also Internet) connection.  The reason was something I knew about but which I 
did not sufficiently understand: the cable TV connection came into the house at 
the opposite end from power and telephone, and was grounded there.

A lightning strike will set up a voltage gradient in the soil near the strike, so the "ground" seen 
by power and phone was at a very different voltage than the "ground" seen by the ground rod 
"protecting" the cable TV entry.  The resulting current actually evaporated the cable TV surge 
protector innards, and took out TV, printer, cable modem, Ethernet switch, PC, and a bunch of other things.

Lesson learned: I rerouted the cable TV to go first to the power entry point, 
and attached its protector to the same copper ground sheet that the other two 
protectors sit on.

A great reference for all this is the handbook "The grounds for lightning 
protection" by Polyphase Co., a maker of professional lightning protection devices.  
I haven't done everything they call for -- for example, our house doesn't have a 
perimeter ground.  But it does now have single point grounding, and as a result we've had 
no trouble even though there have been plenty of lightning strikes in the neighborhood.

paul

[cctalk] Sorbus Micro Handbook 1990 Update

[Jay Jaeger via cctalk]

I have been scanning in a lot of manuals that I have that relate to 
computers that are not in my collectiion, but which may be unique, or 
nearly so.


Today I scanned in the Sorbus Micro Handbook 1990 Update, which has 
information provided to Sorbus FEs who might service various microcomputers.


There is info in there on all sorts of stuff, including motherboard 
jumper/switch info up through a PS/2 model 80, for example, and lots of 
other manufacturer's computers and expansion cards, stuff like IOMEGA, 
AST, Zenith Tandon, etc. etc.


It can be found in my Google drive under my directory of things I have 
provided for bitsavers to snag:


https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU=0-Dg0IUkVNnWUSdzAWk9O4rQ=drive_fs

in subdirectory pdf/sorbus

JRJ

[cctalk] Re: Shelves / Rails for DEC Racks Questions

[Jay Jaeger via cctalk]

On 9/27/2023 3:53 PM, Paul Koning via cctalk wrote:



On Sep 27, 2023, at 12:25 PM, Jay Jaeger via cctalk  
wrote:

I have some open slots in some of my racks.  I do have some old DEC rails, but 
I have a fair amount of equipment, from both DEC and other manufacturers, for 
which those rails are not suitable.

Does anyone have any specific recommendations for shelving? (where equipment 
could just be slid on top of, if the equipment isn't too wide - some pieces are 
very close to 19 inches all by themselves, and were designed for front 
cantilever style mounting.)

Rack makers sell these; for example 
https://www.budind.com/racks-cabinets-accessories/ or 
https://www.dell.com/en-us/search/server%20rack%20shelves but I would expect 
any number of places that produce racks have them.

I have an H960 and needed a solution for a 3U 19 storage array that can attach 
in the front but needs more support and doesn't mate up with the H960 rear 
rails.  So rather than spend significant money on a shelf, I just installed a 
pair of angle irons from front to back (vertical flange down) and set the array 
on that.  Since it's close to 19 inches wide, that simple solution fully 
supports it.

For a heavy oscilloscope I wanted to install as well, I did something similar: 
angle iron supporting a sheet of plywood.  In that case, it has some additional 
angle irons running across, to keep the plywood from bowing under the load.

paul


Amazon has them at lower prices than those -- I was just wondering if 
anyone in their travels found a particular one that worked well in a DEC 
rack (e.g. H960)


JRJ

[cctalk] Shelves / Rails for DEC Racks Questions

[Jay Jaeger via cctalk]

I have some open slots in some of my racks.  I do have some old DEC 
rails, but I have a fair amount of equipment, from both DEC and other 
manufacturers, for which those rails are not suitable.


Does anyone have any specific recommendations for shelving? (where 
equipment could just be slid on top of, if the equipment isn't too wide 
- some pieces are very close to 19 inches all by themselves, and were 
designed for front cantilever style mounting.)


Would also be interested in specific recommendations for the following:

DEC VR14 (I have one on a PDP-12 with proper rails, but have another to 
mount and don't have proper rails for it)


HP 88780 (Perhaps a shelf is the best bet for these?)

JRJ

[cctalk] Re: Good C to FPGA/PLA compiler

[Jay Jaeger via cctalk]

On 9/22/2023 4:45 PM, ben via cctalk wrote:

On 2023-09-22 3:16 p.m., Mike Katz via cctalk wrote:

Martin,

The debug board will need to have the following functionality:

1. Read and write to/from memory when the CPU is running using one
    cycle data break (DEC's version of DMA for the PDP-8). Single Cycle
    DMA requires some interesting signaling, including putting the
    priority on the data bus during part of the cycle.
2. Read and write to/from memory when the CPU is halted using front
    panel emulation (something totally different than one cycle data
    break unfortunately)
3. Handle 4 breakpoints (based on address, data, R/W and count) and
    signal the cpu to stop.  I don't know, yet, if there will be enough
    time in the CPU's instruction cycle to top the CPU before the fetch
    of the next instruction.  If this cannot be done in hardware than a
    much more crude break point system can be done in software.
4. There are 96 active signals on the PDP-8/E's Omnibus.  I expect to
    need most or all of them for this project.
5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is
    a zero and -0.5 to +0.4V is a one.  I don't necessarily need a 5V
    tolerant gate array but what ever I use to interface to the bus will
    need to be.

A full description of the Omnibus can be found here: 
https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf


Coding the break point system in some kind of parallel C like 
language seems way easier to me than to write this in gates.  I don't 
have a clue how to design the count registers.


I need to get #'s 1 and 2 working first and then I can dive into #3.

Thanks.


Hexadecimal displays til311, (pulled DIS1417's) can be found on ebay 
for about $5 not counting shipping. This way you have easy to read hex 
or octal numbers.


As an alternative, perhaps consider basing a design on the PDP-11 
QBone/UniBONE boards, with bus interface chips to handle the 5V UNIBUS 
signalling and a Beagle Bone with it's attached processors (PRU) for the 
bus interface.  That would allow a lot of work to be done in plain old 
C/C++/Whatever, and the board could serve as a debug board, peripheral 
emulator, whatever based on whatever software was loaded onto BB.


Also, if one would want to do logic in an FPGA, VHDL and Verilog aren't 
*that* hard to learn if one has a background in hardware. Some resources 
include:


Logic and Computer Design Fundamentals, Mano/Kime, Prentice Hall

Digital Design using Digilent FPGA Boards (There are VHDL and Verilog 
editions)


Advanced Digital Design Using Digilent FPGA Boards

Even if one is not using Digitlent boards, the examples given for 
various typical uses cases for things are helpful (counters, state 
machines, multiplexers, selectors etc. etc.)


JRJ

[cctalk] IBM 1410 FPGA Status - 1401 Mode

[Jay Jaeger via cctalk]

My IBM 1410 FPGA project now features a working 1401 mode as well, with 
the flip of a switch, exactly like the original IBM 1410.


There are still a few real problems (e.g., Console I/O Input under 
program control doesn't seem to be working), a few minor issues 
involving console problems when doing control operations, and lots of 
changes I want to make to the PC console support program, which really 
should be done before tackling I/O devices.


There are posts relating to the debugging of the 1401 side of things 
towards the end of the list that appears on page:


https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/

JRJ

[cctalk] Re: IBM 1410 FPGA Status

[Jay Jaeger via cctalk]

FYI, I tried the 1401 mode diagnostic M011 today.  Results were 
encouraging, if not perfect:


- The 1410 mode console output for the instruction to the opertor to 
switch to 1401 mode quit after seeing a space character.  Should be an 
easy fix, especially if I can make it happen under simulation.  My first 
guess is that it was the space itself that caused the issue, but I 
forgot to simply try altering the space to something else when I tried.


- The 1401 mode tests get quite far, but then error out at location 
06029 with an Instruction check.  No idea what the issue is.  The 1401 
mode halt and branch (right at the beginning of test M011) also fails. 
That should be an easy one, too.


JRJ

On 7/11/2023 1:18 PM, Jay Jaeger wrote:

Yes, as it was part and parcel of every 1410.  but I have not tested it yet.

Sent from my iPad


On Jul 11, 2023, at 12:06, Van Snyder via cctalk  wrote:

On Mon, 2023-07-10 at 21:32 -0500, Jay Jaeger via cctalk wrote:

Over the past couple of months I have been working on my FPGA
implementation of the IBM 1410 1960's era pre System/360 system again.
I am pleased to share that the CPU now passes a significant diagnostic,
CU01, which tests almost all of the instructions, and also tests I/O
with overlap and the priority feature (interrupts).


Did you implement the compatibility feature, so it can run 1401
programs too?

[cctalk] Re: IBM 1410 FPGA Status

[Jay Jaeger via cctalk]

I/O is already (for the 1415 console) and will be (for tape, print, 
reader, disk, telegraph -- whatever) handled by a PC support program, 
communicating with the Digilent NEXSYS4 over its USB serial port.


This is covered in the following posts:

https://www.computercollection.net/index.php/2022/04/19/ibm-1410-fpga-serial-output-fifo-and-arbitration/

https://www.computercollection.net/index.php/2022/05/22/ibm1410-fpga-inputs/

And the plans moving forward include the info at:

https://www.computercollection.net/index.php/2023/07/10/ibm-1410-fpga-off-to-the-races/

JRJ


On 7/12/2023 12:06 PM, Robert Armstrong via cctalk wrote:

On Mon, 2023-07-10 at 21:32 -0500, Jay Jaeger via cctalk wrote:

Over the past couple of months I have been working on my FPGA
implementation of the IBM 1410 ...


   What are your plans for implementing I/O?  Are you going to emulate a card 
reader and line printer using an SD card and a FAT filesystem?  Or maybe an 
Ethernet connection?  It's a batch system; how will you submit jobs to it?

   Just curious...

Thanks,
Bob

[cctalk] Re: IBM 1410 FPGA Status

[Jay Jaeger via cctalk]

Yes, as it was part and parcel of every 1410.  but I have not tested it yet.

Sent from my iPad

> On Jul 11, 2023, at 12:06, Van Snyder via cctalk  
> wrote:
> 
> On Mon, 2023-07-10 at 21:32 -0500, Jay Jaeger via cctalk wrote:
>> Over the past couple of months I have been working on my FPGA 
>> implementation of the IBM 1410 1960's era pre System/360 system again. 
>> I am pleased to share that the CPU now passes a significant diagnostic, 
>> CU01, which tests almost all of the instructions, and also tests I/O 
>> with overlap and the priority feature (interrupts).
> 
> Did you implement the compatibility feature, so it can run 1401
> programs too?
> 
> 

[cctalk] IBM 1410 FPGA Status

[Jay Jaeger via cctalk]

Over the past couple of months I have been working on my FPGA 
implementation of the IBM 1410 1960's era pre System/360 system again. 
I am pleased to share that the CPU now passes a significant diagnostic, 
CU01, which tests almost all of the instructions, and also tests I/O 
with overlap and the priority feature (interrupts).  Also, it runs at 
generally the same speed as the original machine (comparing the IBM 
estimates for 1000 passes), using the same logic as the original machine 
(though no doubt optimized by the process of taking in VHDL logic 
statements and turning combinatorial logic into lookup tables (LUTs), 
and some additions of "D" flip flops to avoid race conditions in latches 
and logic loops.)


(The speed is the same because its "oscillator" - crystal controlled in 
the original - is now a clock divider/counter off of the FPGA chip clock.)


For more details, see

https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/

Mostly the ALD (Automated Logic Diagram) data capture seems to have been 
very accurate.  I really only had to do four things this year to get it 
to this point:


- Make the necessary logic gate deletions / changes for configuration
  option S40/$40 - 40K of core
- Add the ability to transfer a core image from the PC support program
  to the FPGA.
- Fix some issues in the Assembly Channel because while almost all of
  the ALDs are for a 1410 with the Accelerator feature, several pages of
  the very important Assembly channel were for the base 1410 model.
- Deal with a race condition during overlapped I/O

These are generally discussed in individual blog posts off the above link.

I really was quite happily surprised that when capturing the data on 
over two hundred ALDs with over 10,000 logic gates, over 4,200 
individual unique signals, more than 12,000 signal names on individual 
ALDs, and more than 32,000 interconnections that there were not a lot 
more problems than these.  (I may run into some as yet undiscovered 
errors involving the channels as I add I/O devices, though).


I suppose that there were not more problems because for most of the 
individual sheets and in many cases groups of sheets I wrote VHDL test 
benches using the Intermediate Logic Diagrams (ILDs) as a guide, and of 
course took considerable care during the data entry process from the 
ALDs, checking connection counts on each logic block, for example.


The last post ("Off to the Races") on the aforementioned web page also 
discusses the next expected steps: some more work on the PC/Console 
support program, more diagnostic tests, other support program 
enhancements, and figuring out how to go about I/O, especially since I 
don't have ALDs for the 1414 I/O Synchronizers.


But I no longer have any doubts about the viability of this process, so 
long as the FPGA logic clock is somewhere around 10x the logic clock of 
the simulated machine.  (I expect to try and "push it" by speeding up 
the 1410 logic clock to see at what ratio of the FPGA clock to the CPU 
clock things break down, as well).


JRJ

[cctalk] Re: Continental 50 Pin connector vs. AMP 200276 50 pin connector - same?

[Jay Jaeger via cctalk]

On 5/15/2023 12:36 PM, Brent Hilpert via cctalk wrote:


If it's of any help though, on my 2748 connector (the cord-plug-in end) the male pin 
diameter is 0.061 ~ 0.062" (measured with a cheap micrometer, perhaps the 
actual spec is 1/16=0.0625).

I understand the confusion - I have on hand 3 different examples of ~0.062" dia. 
male pins. Cursorily they look the same and plug into the same female pin, but are 
different in length and in the shoulder-housing-insert area. Then there are 
similar-looking pins that are ~0.040" diameter, which may be what you acquired.

These kind of look like they might be the 0.062 diameter:

https://www.ebay.com/itm/115573632341

whereas these look like they could be the 0.040 diameter:

https://www.ebay.com/itm/115573630849

But then you have to watch out to be getting the correct type of pin for the 
housing one is using, for as stated above they can differ in that section of 
the pin even though of the same mating diameter.



Just for completeness, for the AMP connector (200276-4) on which the 
pins are just a bit to small, the pins measure at .055" - close, but no 
cigar.  (1.4mm).


JRJ

[cctalk] Re: Paper Tape Reader Needed

[Jay Jaeger via cctalk]

I live in Madison, WI, and have a DEC PC05 on a PDP-11 that can also 
host a Unibone board to make file transfers easy.  I also have a 
recently restored HP 2748B, for which I have a simple Arduino interface 
with an Ethernet "hat" to read files into a PC.  Neither is available 
for loan, but I'd be happy to read tapes in for those willing to make a 
day trip or mail them to me.


The PC05 works well for fanfold tapes, but I have found it doesn't work 
well for larger spooled paper tapes, even though I made a couple of 3D 
printed inserts to provide a spool post on the input side and an 
extended guide on the output side.  The mass of a large spool puts quite 
a bit of drag on the sprocket feed.  But the HP 2748B works well for both.


I'd also point out that there are repositories of a lot of PDP-8 paper 
tapes around, including:


https://bitsavers.org/bits/DEC/pdp8/

which includes tape images from a couple of other repositories.  So, 
aside from installation specific tapes, there is a pretty good chance 
that someone somewhere already has images.


JRJ

On 5/18/2023 3:19 PM, Mike Katz via cctalk wrote:
I have just acquired a number of PDP-8 paper tapes.  My reader/punch is 
not working at the moment (neither is my PDP-8 but that's another story).


I am looking to beg, borrow or buy a paper tape reader or reader/punch 
(stand alone or PC04) so that I can archive these tapes as they are 
getting more and more rare.


I would prefer a serial (RS-232) reader or reader/punch but I could deal 
with a parallel and create my own parallel to serial converter or get 
some kind of USB to parallel adapter.


There are several "hand pull" types of readers out there (like the 
OP-80A) but I am afraid of damaging the very old fanfold paper tape by 
using my inconsistent hand rather than some kind of motor driven 
mechanism which is designed for smooth paper tape flow.


Does anyone have any ideas or something they have to sell or donate?

Please contact me by email directly.

Note:  This is also being posted to the VCF DEC Forum.

Thank you,

  Mike Katz
      bitwiz@12bitsbe

[cctalk] Re: Continental 50 Pin connector vs. AMP 200276 50 pin connector - same?

[Jay Jaeger via cctalk]

Will reply in answer myself on this one:

Firstly the paper tape reader is an HP 2748B - sorry about that typo 
(blush).


Secondly the AMP connector I acquired was NOT compatible with the 
Continental connector on the paper tape reader.  The pins on the AMP 
connector, while larger than those on the Winchester connector, were 
still a shade too small to make a reliable connection - the connector 
was clearly loose when mated.


Which brings up the question: does anyone have a spare cable or 50 pin 
male Continental connector that I could purchase/trade for?


Thanks.

JRJ

On 4/22/2023 6:14 PM, Jay Jaeger wrote:
I have an HP 2875B paper tape drive that I want to interface to.  It has 
a 50 pin block connector (using well under 1/2 the pins).  The connector 
manufacturer was Continental.


I have already discovered, the hard way, that it is not a winchester 
connector - the pins on the 50 pin Winchester connector I just obtained 
via ePay that otherwise fits are too small in diameter and won't make 
contact.  I *could* increase their diameter using solder - but -- yuck.


The other connectors of this sort I am familiar with that have the same 
general overall size and pinout were made by AMP.  Does any one know if 
the AMP connectors and the Continental connectors would be compatible?


Thanks.

JRJ

[cctalk] Continental 50 Pin connector vs. AMP 200276 50 pin connector - same?

[Jay Jaeger via cctalk]

I have an HP 2875B paper tape drive that I want to interface to.  It has 
a 50 pin block connector (using well under 1/2 the pins).  The connector 
manufacturer was Continental.


I have already discovered, the hard way, that it is not a winchester 
connector - the pins on the 50 pin Winchester connector I just obtained 
via ePay that otherwise fits are too small in diameter and won't make 
contact.  I *could* increase their diameter using solder - but -- yuck.


The other connectors of this sort I am familiar with that have the same 
general overall size and pinout were made by AMP.  Does any one know if 
the AMP connectors and the Continental connectors would be compatible?


Thanks.

JRJ

[cctalk] Re: mainframe vs mini

[Jay Jaeger via cctalk]

The 709x had data channels which ran asynchronously, and generated channel 
traps — i.e. interrupts.  I don’t think it had a, say, 60Hz clock, but I/O 
interrupts would allow a certain basic level of multiprogramming.  The IBM 1410 
also had I/O interrupts, and even had a rudimentary optional teleprocessing 
supervisor.  IBM turned some 1410s into a basic message switching system.

Sent from my iPad

> On Mar 15, 2023, at 19:23, Jon Elson via cctalk  wrote:
> 
> On 3/15/23 18:32, Paul Koning via cctalk wrote:
>> 
>> Apart from spooling, which uncouples slow I/O from execution, there is also 
>> "multiprogramming", which means being able to run more than one job 
>> concurrently.  Timesharing does that, of course, but I think 
>> multiprogramming was intended to refer to batch systems that did so.
>> 
> Yes, the IBM 709x ran in single-job fashion.  I don't think it had 
> interrupts, so breaking off one program to schedule another was not possible. 
>  Also, it had no memory protection.  We had a 7094 at Washington University 
> in the late 1960s, and it was the main computer resource on campus.  When the 
> moved up to a 360/50, they were able to benefit from multiprogramming, and 
> got a boost in throughput, although the 7094 was QUITE a bit faster than the 
> 360/50.
> 
> Jon
> 

[cctalk] Re: WTB Any storage for a PDP 8/A

[Jay Jaeger via cctalk]

Sounds a bit like SmallC or TinyC from back in the day. 

Sent from my iPad

> On Feb 25, 2023, at 08:46, silvercreekvalley--- via cctalk 
>  wrote:
> 
> Hi all,
> 
> I'm cooking up a new interpreter for the PDP 8. It uses a C like language 
> (C-) and is really a project to get my head round the PDP 8 architecture. 
> Note its an interpreter not compiler :-)
> 
> I have recently got my hands on a wonderful working PDP 8/a, but it would be 
> nice to have some actual storage e.g. a disk drive or tape of some kind. I'm 
> not a fan of using tape emulators etc, although thats all I have at the 
> moment. Happy to pay the going rate and will travel to collect. I'm in the UK 
> - so can do anywhere in the UK or Netherlands/Germany/France etc.
> 
> I would also like to have a go with the FPP8/A which is a floating point 
> option on the 8/A. If anyone has one for sale or would be prepared to do 
> medium term loan that would be a great help.
> 
> More details on the project once its in a workable form and I've set up a 
> website or whatever
> 
> Thanks
> 
> Ian

[cctalk] Re: AI applied to vintage interests

[Jay Jaeger via cctalk]

> On Jan 17, 2023, at 04:52, Peter Coghlan via cctalk  
> 
> How about translating code from Z80 which has several registers to 6502 with
> rather fewer?  That would seem to need some more intelligent thinking on
> how to simulate the unavailable registers without causing additional
> difficulties.
> 
> Regards,
> Peter Coghlan.

That would be not much different than compiling code (say, C) for the 6502.  
One need not “simulate” anything.  One could use the stack plus perhaps a bit 
of so-called heap
storage to manage register allocation, along with translating ( perhaps with 
optimization ) the instruction stream.  Dealing with changed 8080 stack offsets 
from the original code would be tricky.

[cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives?

[Jay Jaeger via cctalk]

On 11/28/2022 12:17 AM, Chuck Guzis via cctalk wrote:



If anyone cares, I've been working on a Pertec tape controller design.
The initial version worked remarkably well with only a few bodge wires.
I'm assembling the respin of the design and do not anticipate any issues.

It's basically a 4x6 inch PCB with a bunch of through-hole TTL hooked to
a piggyback MCU.  I've selected the STM32F407 Chinese boards as they're
inexpensive and easily available from Aliexpress, unlike a lot of the
other MCU boards which seem to have been hit by the chip shortage.



I very much care; indeed I had thoughts of maybe doing something 
similar, using a BeagleBone, but this sounds a lot easier.


Would like to know exactly what board you chose, so I can acquire one. 
I have a cipher drive and an HP 88780A that would be good candidates to 
use with this / use this to test.  I also have a DG drive that might 
well have a Pertec interface (haven't looked in a while).


JRJ

[cctalk] Re: 14 DZ11's for sale/whatever

[Jay Jaeger via cctalk]

For an awful lot of software, holding a line until there is an end of line is 
not practical. Text editors in particular simply won’t work that way. The UNIX 
shell wouldn’t work in that environment either.  So this character by character 
interrupt is pretty standard.

Sent from my iPhone

> On Oct 29, 2022, at 8:02 PM, Nigel Johnson Ham via cctalk 
>  wrote:
> 
> The performance of the DZ11 is not good.  It did an interrupt for every 
> character, just like a DL11. The Able DMAXes blocked until a carriage return 
> and then did a DNA, IIRC.
> 
> Not sure about the DH and DHV11 - its been a long time.  We used Able DMAXes 
> on the Canadian NAPLPS system, named Telidon, but that was back in the 
> 1200/300 baud days!
> 
> However for vintage computer purposes, that's probably not a concern.
> 
> cheers,
> 
> Nigel
> 
> Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
> Amateur Radio, the origin of the open-source concept!
> Skype:  TILBURY2591
> 
> 
>> On 2022-10-29 14:37, Tony Duell via cctalk wrote:
>>> On Sat, Oct 29, 2022 at 6:14 PM Bill Degnan via cctalk
>>>   wrote:
>>> Being lazy admittedly but can these be used for single serial interfacing?
>> They will not emulate a DL11 or any similar single serial port.
>> 
>> You don't have to use all 8 ports on the DZ11 card but you still need
>> the right software driver.
>> 
>> That said,it would be a pity to scrap these. Surely all Unibus cards
>> are getting hard to find now.
>> 
>> -tony
>> 
>> 
>> 
>>> Bill
>>> 
>>> On Sat, Oct 29, 2022, 11:01 AM Chris Zach via cctalk
>>> wrote:
>>> 
 I have a box here of 14 DZ11 Unibus 8 line serial port interfaces. And I
 have no clue why I have them.
 
 Anyone need some? Otherwise I'll Ebay/recycle them.
 
 CZ

[cctalk] Re: Data General Nova and Eclipse Hobbyist License...

[Jay Jaeger via cctalk]

Ray, I have quite a lot of material you do not have listed.  For a while 
I had it on my Google Drive (password secured), but not any longer.


The attached files should give you an idea.  Contact me off list if you 
want to pursue a transfer.  (I suppose the list may well not accept 
attachments...)


JRJ



On 10/24/2022 5:26 PM, Bruce Ray via cctalk wrote:


Wild Hare Computer Systems, Inc., is pleased to announce that a
"Hobbyist License" is now available for legacy Data General
Nova and Eclipse software.  This license allows educational, hobbyist,
non-commercial use of the vast amount of DG software - software
that changed the world in many ways.

The initial archives are currently available at:

www.NovasAreForever.org/dgsw

and includes documentation for the corresponding software.


This October announcement also honors the 54th anniversary of the original
Data General Nova. An international celebration of the Nova's 50th 
anniversary was

hosted by Wild Computer Systems in Colorado, USA.  Some of the festivities
can be seen at:

www.Nova-At-50.org

and

www.Nova-At-50.org/album/index.html


To complement this Hobbyist License, a Nova and Eclipse emulator that 
can run all of the

software will be introduced later this week.


Wild Hare Computer Systems is dedicated to preserving Data General's
significant contributions to computer history.  We seek DG hardware, 
software, documentation,

sales literature - basically "anything DG" - that can be added to the
archives for posterity.



Bruce Ray
Wild Hare Computer Systems, Inc.
Denver, Colorado USA
b...@wildharecomputers.com

...preserving the Data General legacy: www.NovasAreForever.org

www.WildHareComputers.com

www.NovasAreForever.orgKINDID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
FILENAMEMFG SERIAL  TRAYDATEAVAILABILI  ERRORS  
PREVIOUS_C
DGFHS   1001NOVANOVA DOS Starter DK W/O Mag Tape072-02-02 
(Copy)dg1001.img  DG  F50   
  
DGFHS   1002NOVANOVA DOS Starter DK Rev. 3.00   072-02-04   
dg1002.img  DG  F50 
DGFHS   1003NOVANOVA DOS Starter DK Rev. 3.00   072-02-04 (Copy)
dg1003.img  DG  F50 4/20/1979   

DGFHS   1004NOVANOVA DOS SYSGEN Diskette: W/O Mag Tape  072-03-01   
dg1004.img  DG  F50 
DGFHS   1005NOVANOVA DOS SYSGEN Diskette: W/O Mag Tape  072-03-02 
(Copy)dg1005.img  DG  F50   
  
DGFHS   1006NOVANOVA DOS UTILITY Diskette W/O Mag Tape  072-04-01   
dg1006.img  DG  F50 
DGFHS   1007NOVANOVA DOS UTILITY Diskette W/O Mag Tape  072-04-02 
(Copy)dg1007.img  DG  F50   
  
DGFHS   1008NOVANOVA DOS UTILITIES DK Rev. 3.00 072-04-04   
dg1008.img  DG  F50 
DGFHS   1009NOVANOVA DOS UTILITIES DK   072-04-?? (Copy, Revision 
not shown)dg1009.img  DG  F50 
4/20/1979   
DGFHS   1010NOVARTOS Mag Tape Support   072-06-01 (RTOS DOS Support 
not Mag?dg1010.img  DG  F50 

DGFHS   1011NOVANOVA DOS Starter Diskette With Mag Tape 072-09-00   
dg1011.img  DG  F50 
DGFHS   1012NOVACMSP (Communications Mux Software Pkg?) 072-18-00   
dg1012.img  DG  F50 
DGFHS   1013NOVAMicroNOVA Starter DK Rev. 3.00  072-35-03   
dg1013.img  DG  F50 
DGFHS   1014NOVADOS Update 2 for Rev 3.00   072-000241-01   
dg1014.img  DG  F50 
DGFHS   1015NOVANOVA RTOS   072-40-00   
dg1015.img  DG  F51 
DGFHS   1016NOVANOVA RTOS on Diskette   "072-40-02 (Rev 6)  
""3100"""   dg1016.img  DG  F51 

DGFHS   1017NOVARTOS Rev. 6.20  072-40-03   
dg1017.img  DG  F51 
DGFHS   1018NOVARTOS Update 1 ON Diskette   072-000322-00 (Rev 6)   
dg1018.img  DG  F51 
DGFHS   1019NOVAReal Time Input/Output System (RTIOS)   072-48-00   
dg1019.img  DG  F51 
DGFHS   1020NOVA

[cctalk] Re: Minicomputer front panel.

[Jay Jaeger via cctalk]

Well, as it turns out I have a full PDP-8/M front panel, including the 
board, which I *believe* is compatible with an 8/E, but has LED lights 
instead of incandescent ones (one might have to check to make sure that 
the pin with the lamp power isn't used on the baord.)


[It is a FULL front panel, in spite of what one sees on Doug Jones website.]

Looks like this one:

http://www.dvq.com/oldcomp/dec/pdp8m.html

It looks like this one - I didn't look closely to see if it had an OEM 
name at the top.


The board is missing two of the paddles, and the knob for the rotary switch.

Tom, if you are interested, contact me off list.

JRJ

On 9/22/2022 9:44 PM, Tom Hunter via cctalk wrote:

I cannot understand the mindset of people who buy up components desperately
sought by others who want to restore machines just to nail them to their
man cave or living room wall.
These same types of people vacuum up core memory boards, keyboards, disk
platters, 9-track tapes, etc just for bragging rights and as a result
depriving those who restore and preserve computer systems from doing so.
For some time I have been looking for a PDP-8/e front panel PCB needed to
make a machine complete. Until now I had no luck. No doubt there are dozens
of these hanging off people's walls.
Like Peter I don't care if the PCB is functional, but unlike Peter I can
and will repair it.
Peter please consider the negative impact of your hobby on historically
valuable computer systems.
Tom


On Fri, Sep 23, 2022 at 1:33 AM Peter Van Peborgh via cctalk <
cctalk@classiccmp.org> wrote:


I know this is sacrilege but I am looking for the front panel of a *Data
General Nova *and/or *a DEC PDP 8/11/12/15*.
Why? I collect artefacts from the days of the minicomputer and earlier and
I want them for my collection/display. They should be not too damaged and
of course do not need to be functional. I would be willing to pay
postage/freight.
Any offers? Any offers?
Peter

PS Please don't shout at me!

IBM 1410 FPGA Update

[Jay Jaeger via cctalk]

Resend (first one seems to have bounced)

My FPGA implementation of the IBM 1410 Data Processing System continues 
to progress.  There is now a console (with the console typewriter, 
keyboard, lights and switches) written in C# up on github.


With that addition several things now work:

- Address Set (including instruction counter)
- Memory Display and Alter
- Several instructions have been tried: set word mark, halt,
  add, subtract, jump on inquiry and unconditional jump

Several issues remain, the most important of which are:
- Addressing over 0 is not working correctly
- Console output with M%T0aW just endlessly repeats
  the first character (at address a) - no increment.

github projects include:

The C# SMS data gathering / entry / update application:
https://github.com/cube1us/IBM1410SMS

The FPGA implementation in VHDL:
https://github.com/cube1us/IBM1410FPGA

The newly added C# console application:
https://github.com/cube1us/IBM1410Console

A series of posts can be found from my website page at
https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/

An IBM 1410 puzzlement...

[Jay Jaeger via cctalk]

I have a puzzlement with my IBM 1410 FPGA implementation.

ALD page 42.10.10.1, ILD figure 89

The symptom is this:  The CPU runs and can execute instructions. So, 
stuff is generally working.


Starting the address set process, the console appropriately prints the 
"B" prompt (to set the instruction address into the IAR, B means 
"BRANCH") or the "#" prompt to set other addresses.  Normal stops print 
the "S" as expected, errors print the "E" as expected and single cycle 
or I/E mode print the "C" as expected.


However, starting a display operation (to display memory), which ought 
to print a "D", prints an invalid parity "F" character - Bit 2 is picked 
when it should not be.  I have verified that "-S Special Char B" is 
active (active low)


I first saw this on real FPGA hardware, and then confirmed it / did some 
troubleshooting under simulation.


Here is what I found:

Looking at the ALD, a "D" is printed when
+S ADDRESS SET ROUTINE is active
+S DISPLAY ROUTINE is active
The Console Matrix at position 30 or 35

All of those conditions are satisfied.  Address Set is appropriately 
active because a display operation starts off by entering an address 
(even though I don't have console input implemented yet, that is not 
involved at this point).  And, indeed "-S SPECIAL CHAR D" is active 
(active low), as expected.


Looking at the ALD, a "B" is printed when
+ +S ADDRESS SET ROUTINE is active
+ The console's address set select rotary switch is NORMAL (it is)
  (It will print '#' for other positions of this switch)
The Console Matrix at position 30 or 35

And, indeed, all of these conditions are satisfied as well, and indeed 
"-S SPECIAL CHAR B" is active (active low) as well.


The FE instructional materials confirm that ADDRESS SET ROUTINE should 
be active when starting a display operation, consistent with the ALD and 
the ILD - because both then proceed to allow the operator to input an 
address.


So, this feels like a bug - an implementation error that was later 
corrected.  The ALD I have is pretty early - 6-15-1961, with just one 
ECO, and that ECO ("B") isn't on any of the gates on that ALD (this is 
not unusual), so this is probably essentially the original ALD.


The fix would be pretty easy: to include "+S DISPLAY ROUTINE" onto the 
wired or / "DOT" at coordinate 1B (to inhibit "B") and also to add a 
wired or / "DOT" with "+S DISPLAY ROUTINE" at the output of gate 2I.


In both cases, the signal "+S DISPLAY ROUTINE" would then inhibit the 
"B" or "#" (depending upon how the relevant switch is set.)


But I'm just really surprised at the whole thing.  Not really asking 
anyone to do anything, necessarily, but if anyone wants to confirm I'm 
not nuts (or demonstrate to me that I am nuts), feel free.


[I am also experiencing it printing a "." when the mode switch is in CE, 
which isn't right either - but haven't looked at that.  It should be 
printing a "#", regardless of the setting of the Address Entry switch - 
I won't be surprised if the same kind of thing is going on there, as 
this also involves the "address set routine" and matrix position 35 - 
and a "." is a "#" plus bits B and A - so the evidence is pretty strong 
there]


The documents:

1415 Console CE:
http://bitsavers.org/pdf/ibm/1410/CE_Instruction_Reference_Maintenance/1415_Console/

ILD (see Figure 89, page 95 of the PDF below)  [ILDs read pretty much 
like modern logic diagrams]


http://bitsavers.org/pdf/ibm/1410/drawings/R23-2936-0_1410_InstructionalLogicDiagrams.pdf

The ALD 42.10.10.1 (page 60 of the PDF below) [ALDs are tricker, because 
of "DOT-ted" connections, and the logic family (RTL NAND *mostly*).


http://bitsavers.org/pdf/ibm/1410/drawings/1410_SYSTEM_VOL_X.pdf

JRJ

Re: Possibly going up to VCF, stuff I would like to sell/get to proper people pdp8/12/HP stuff

[Jay Jaeger via cctalk]

On 4/9/2022 2:42 PM, Chris Zach via cctalk wrote:

Hi all!

I'm thinking about going up to VCF in Wall next weekend. I haven't been 
to it since it was the Trenton Computer Fest (think late 1990's) so I'm 
not sure what the protocol is on tailgating, trading stuff or whatnot. 
Appears that they have a "sale room" you drop things off in with prices. 
Ok


Things I could "sell" if anyone's interested:
HP1000e computer, dead power supply, basic boards, no advanced memory.
HP9825B likewise does not power up, but it's there.
Microvax 2 boards, stuff like that.
Spare 11/24 CPU boards (I have a bunch, all work, no idea why I have all 
them)




My 11/24 wouldn't mind having a spare CPU and/or Unibus Map - but I 
won't be at VCF.


JRJ

Re: PDP 11/24 - A Step Backwards

[Jay Jaeger via cctalk]

On 4/2/2022 5:12 PM, Rob Jarratt via cctalk wrote:


Using tack soldered wires, I have traced back and I *think* I have found
something. There could be a fault in E52 (sheet K6, p157 of the PDF). While
K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with
50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641
(http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD
F) the logical 0 output should be 0.4V max and the logical 1 output should
be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it
thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may
be faulty. Trace here:
https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg.

Regards

Rob



Also, consider having a look at whatever E52 is driving - something may 
be pulling at it's output - a bad chip, a short somewhere in what it 
drives, etc. That looks to be E53 pin 13, and wherever else that signal 
might go.  And also look at K5 BUS DCLO L, pin 15 of E52, just in case.


JRJ

Re: PDP 11/24 - A Step Backwards

[Jay Jaeger via cctalk]

On 4/2/2022 5:49 AM, Noel Chiappa via cctalk wrote:

 > does [disabling the MCLK counter via DCLO, asserted by the two
 > E126 monostable chain from ACLO] happen just on power-down, or on
 > power-up too? I'd need to understand how that two monostable chain
 > works in both cases, which I currently don't. (I only understand
 > monostables when pulses trigger them, not edges, which is a big part of
 > why I don't completely understand it.)

So this was bugging me, so I hauled out my TI TTL databook and looked up the
LS123.



And, if that 'LS123 wasn't made by TI, it could be considered suspect 
until it has been checked out with a 'scope.  I remember, from somewhere 
back in the day, that not all '123s were created equal, and that TI's 
were demonstrably better than the others in terms of stability and 
trustworthiness.  I also recall *vaguely* one experience where replacing 
a '123 made by someone else with a TI one fixed the issue.


JRJ

Re: Installing an operating system on the 11/83 - update.

[Jay Jaeger via cctalk]

Sent from my iPad

> On Feb 22, 2022, at 22:59, Ethan Dicks  wrote:
> 
> On Tue, Feb 22, 2022 at 10:43 PM Jay Jaeger via cctalk
>  wrote:
>> Writing a 360KB or RX50 diskette with a 1.2MB drive is a path to a lot
>> of frustration.  Not only do you have to double step the drive (software
>> often takes care of that part), but the tracks written will be narrower
>> than a real RX50 / 306KB drive...
> 
> A real RX50 is an 80-track drive.  You are correct that writing a
> "360K" floppy on a high-density drive is not a good idea, but a real
> RX50 _is_ 80 tracks, just single-sided, for a total of 400KB per disk.
> 

Yeah, I had forgotten that.  

> -ethan

Re: cctalk Digest, Vol 89, Issue 21

[Jay Jaeger via cctalk]

On 2/22/2022 6:29 PM, Paul Koning via cctalk wrote:

You could boot a packaged Linux that doesn't need installation but runs 
directly from the boot device.  I haven't done this but I know they are out 
there and easy to use.



I use Clonezilla for standalone Linux stuff (including backups) - they 
have ready to run UEFI USB images and CD images.  You can get to a 
command prompt and enter "sudo bash" to get a root shell.  Useful for 
all sorts of stuff.


There are also Ubuntu "live" CD images out there, or at least were, a 
few years back.


JRJ

Re: Installing an operating system on the 11/83 - update.

[Jay Jaeger via cctalk]

On 2/22/2022 6:12 PM, js--- via cctalk wrote:


On 2/22/2022 7:00 PM, Ray Jewhurst wrote:
I read that you can indeed use a standard 1.2 Meg drive and that you 
can also use DSHD 5.25 disks in place of RX50s. Is there any truth in 
this? If there is it will be much easier and cheaper to make disks for 
my Rainbow.



As Chuck noted, I'd think you'd want to use 360K media -- not DSHD 
diskettes... and ensure that the 1.2MB drive is slowing down to 300RPM 
with a data rate of 250KHZ.


These features will depend on the 1.2MB drive you have, as well as your 
FDC and imaging software.


- John Singleton


Writing a 360KB or RX50 diskette with a 1.2MB drive is a path to a lot 
of frustration.  Not only do you have to double step the drive (software 
often takes care of that part), but the tracks written will be narrower 
than a real RX50 / 306KB drive, providing a smaller signal/noise ratio. 
 And, if you don't start with completely magnetically erased media, any 
left over junk in any data left over may be picked up by the RX50 head.


Been there, done that.

JRJ

Re: Greasweasel was Re: Installing an operating system on the 11/83 - update.

[Jay Jaeger via cctalk]

On 2/22/2022 12:29 PM, Ray Jewhurst via cctalk wrote:

I was wondering how well a Greaseweasel would write floppies for my Rainbow. 
Also, I saw that someone had images for Venix-86 Rainbow and I was wondering if 
they would be interested in sharing them.

Thanks
Ray

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android



I was certainly able to *read* them on my Greaseweazle, using a real 
RX50 drive, and compared them to images I had read earlier under MS-DOS 
with a driver on a 360K drive.  I see no reason offhand why they could 
not be written with a Greaseweazle as well, unless the actual sector 
encoding (as opposed to sector size) is weird - and I don't recall that 
it is.  BTW, I used a Greaseweazle to write some IBM DD floppies for 
someone with a System/36 (IIRC) using a DSDD drive I borrowed from my DG 
S/140, and they worked fine for him.


JRJ

Re: Installing an operating system on an 11/83

[Jay Jaeger via cctalk]

On 2/21/2022 6:55 PM, Glen Slick via cctalk wrote:

On Mon, Feb 21, 2022, 4:32 PM Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:


Hi

I have built an 11/83 in a BA23 box.

It has a KDJ-11B, 2mB PMI memory, an RQDX3 with an RX50 attached,

Plus a CMD CQD 220A Disk controller with a digital RH18A 2Gig SCSI drive
attached.

Diag sees drive as RA82.

It boots and runs the diag disk and XXDP+ just fine.

I do not have install distributions for any of the 11/83 operating systems.

Daily driver system is a Windows 10 PC.

So how do I install an operating system?

Suggestions please.

Thanks

Rod



Is the PC old enough to still have PCI slots? If it is, one option would be
to pick up a cheap PCI SCSI controller, e.g. an AHA-2940, that you can use
to write disk images to a SCSI hard drive. Then use SIMH to create disk
images of an OS of interest that can then be dumped to the SCSI hard drive.
Or pick up a SCSI2SD device to use with the CMD CQD-220A instead of a SCSI
disk drive. Then copy disk images created using SIMH on the PC to an SD
card.

Is the CQD-220A a /TM version, or an /E version? If it's a /TM version you
could also pick up a cheap SCSI tape drive, and create installation tapes
for RSTS/E or 2.11BSD and boot from those to install on a SCSI hard drive.
I've done that a few times just for the heck of installing from tape. If
you have the /E version (or /T/M version) instead of the /TM version you
can do either MSCP or TMSCP,  but not both at the same time.

For RT-11, that is small enough it wouldn't be difficult to install from
RX-50 disks, if you had a means to create disks from images.





Another alternative would be, after installing an OS under SimH using 
another program as was suggested here, to transfer the disk image (e.g. 
vtserver  https://github.com/chapmajs/vtserver ).


JRJ

Re: Is The M9312 Boot Module Essential?

[Jay Jaeger via cctalk]

My 11/24 does *not* have an M9312.  My UNIBUS out from the processor 
backplane goes to an RK611, and then to a VT11.  I have an M9301 at the 
end, in the VT11 UNIBUS OUT slot.  I didn't pull the map card, but I am 
99.% sure that my boot ROMs (RL11, RK611) are on my UNIBUS map card.


The UNIBUS MAP card has space for 5 ROMS: the console/diagnostic (which 
maybe isn't even socketed), and including the sockets 4 device ROMs.


You do want a terminator that provides a SACK turnaround capability so 
that the machine doesn't hang accessing an address that doesn't respond 
on the UNIBUS.  One option might be for you to build a UNIPROBE card, 
perhaps sans the LEDs to minimize the need for SMT devices to deal with.


I do have several spare M9312's and could sell you one - $50.  I can 
deal with shipping to the UK.  But I suspect you will be able to find 
someone from the UK on this list that has spare(s).


JRJ

On 2/19/2022 3:45 AM, Rob Jarratt via cctech wrote:

I saw this reply later than the previous one. It confirms that I don't
*need* it for booting, but it would be useful.

I suspect some of the other cards that were in the machine might do the
necessary termination stuff.

Thanks

Rob


-Original Message-
From: cctalk  On Behalf Of Noel Chiappa via
cctalk
Sent: 19 February 2022 09:18
To: cctalk@classiccmp.org
Cc: j...@mercury.lcs.mit.edu
Subject: Re: Is The M9312 Boot Module Essential?

 > From: Rob Jarratt

 > is the M9312 essential to ever get this machine to boot up an

operating

 > system?

Interesting question. I don't have my -11/24 running yet, so this reply is
theoretical, not tried in practice (and as we all know, the difference

between

theory and practice is even larger in practice than it is in theory), but

here

goes.

The M9312 basically provides two things: 1) UNIBUS termination, and 2)
boostrap ROM.

To further subdivide the former, it provides 1A) analog termination (i.e.

a

resistance at the end of a transmission line that prevents reflections of
signals passing down the otherwise un-terminated transmission lines of the
bus), 1B) pullups (so those transmission lines normally float at roughly

3V,

unless actively driven by one of the boards plugged into the bus) and 1C)
'SACK turnaround' (a start-up 'safety check' where an un-requested - and
thus 'un-grabbed' by any device - bus grant from the CPU on start-up is
'turned around' by the terminator; this verifies that the grant lines are

un-

broken between the CPU and the terminator - e.g. by someone forgetting to
plug in a grant jumper).

1A is not _absolutely_ necessary; this can be seen in small QBUS systems
(the QBUS is, at the analog level, sort of identical to the UNIBUS; this

an be

seen in the use of the same transceiver chips, such as 8641's, on both)

which

can get away without 1A in small configurations. Whether it's needed on

your

-11/24 is hard to predict, theoretically; the easiest thing is to just try

it and

see. Note: it may 'work' without it, but not be as _reliable_ as with it.

1B _is_ necessary, but can be provided anywhere on the bus; most
UNIBUS/QBUS CPUs have it built in, and so does the KDF11-U of the -11/24:
see pg.  of MP01028.

1C is required by _some_ UNIBUS CPUs (ISTR that the -11/04 won't run
without it), but the KDF11's in general don't; e.g. the -11/23 definitely

runs

without it. The KDF11-U might have outboard circuitry to require it, but

I'm

too lazy to grovel over the prints to see. Easiest to just try it and see.


For 2, it all depends on what you're booting from. E.g. the RK11 has a

simple

enough bootstrap that you can just enter it manually (although it gets old
after a while - I remember re-'programming' (think 'soldering iron' :-) a
castoff BM-792 someone gave us for our -11/40 so I wouldn't have to).

But if you're loading it over the console serial line, e.g. with PDP11GUI,

you

don't need any ROM bootstrap - the built in console ODT will be enough.
You can also load a bootstrap that way; I was booting off the QSIC RK11

with a

boostrap loaded over the console serial line; that was faster than the
bootstrap in the BDV11. This requires finding - or writing - a bootstrap,

which

for later DEC mass storage controllers is not trivial.

YMMV.


TLDR version - probably not!

Noel

Re: PDP-11/34 CPU PROMS

[Jay Jaeger via cctalk]

Looking at my inventory, I seem to have no less than four spare M8266 
(plus one in my 11/34 that runs, plus probably another in my 11/34 out 
in the garage.)


Rod, where are you located?

JRJ

On 2/9/2022 6:16 PM, Rod Smallwood via cctalk wrote:

Hi

     We have narrowed the problem down.

Its the instruction decode ROM's that are the issue.

The images of those are whats needed.

Regards Rod


On 09/02/2022 23:14, Sytse van Slooten via cctalk wrote:

On Tue, Feb 8, 2022 at 7:04 PM Warner Losh  wrote:
I found
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/08%20PDP-11/01%20PDP-1104-1134/05%20PDP-1104-1134%20Microcode/ 


which has the source code...

But I couldn't find the tools to use these files to create microcode
images.
Actually, the "m8266_ucode.v.txt" there seems to actually be the 
program that

produced the symbolic dump (which is also available at:

  http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt)

It looks like the program is in VHDL or something like that, but it 
doesn't

seem to have the actual microcode (was it stored/defined in another VHDL
file?); that raises the question of where the actual microcode that 
it was

dumping was.
It's Verilog (the 'other' hardware language besides VHDL), and indeed 
the rom images are in other files/modules - in some kind of straight 
binary format, I'd guess.


I'm properly intrigued why someone would choose to do this - which 
seems to be mostly listing the microcode in a readable format - in 
Verilog. Unless of course it would be with a long term goal of using 
that microcode in an emulator that is sufficiently like a 'real' 11/34 
to run it unchanged. I wonder if that is the case, and what became of 
the project - since the files are from 2014, it's probably safe to 
assume it got stuck somewhere along the way.


Somewhere way down on my list of things to explore is something 
similar but then for the 11/70 - to make a vhdl version that is 
microcode compatible with the original, unlike the current pdp2011 
that's 'only' functionally compatible. And this is about exactly the 
same way I would start - except I don't have the '70 rom images yet... 
If anyone has them and is willing to share, drop me a note ;-)


Cheers
Sytse

Re: Origin of "partition" in storage devices

[Jay Jaeger via cctalk]

Sent from my iPad

> On Feb 1, 2022, at 10:43, Jon Elson via cctalk  wrote:
> 
> On 2/1/22 00:38, Peter Corlett via cctalk wrote:
>> On Mon, Jan 31, 2022 at 07:51:28PM -0500, Paul Koning via cctalk wrote:
>> [...]
>>> Yes, RT-11 is a somewhat unusual file system in that it doesn't just
>>> support contiguous files -- it supports ONLY contiguous files. That makes
>>> for a very small and very fast file system.
> 
> Well, the IBM 360 CKD disks had all files contiguous, too.
> 
> Jon
> 

That is not accurate.  CKD files (and FBA files, for that matter) can have 
multiple *extents*.  An extent is contiguous by nature, but if a file has 
multiple extents it is not contiguous other than by coincidence.

Side note:  Intergraph made disk controllers for the PDP11 and Vaxen that 
required graphics files (IGDS) to be contiguous so that the on-board CPU could 
scan for graphic element characteristics (layer, type, etc.)

Re: mystery S-100 available

[Jay Jaeger via cctalk]

FYI, that "unpopulated board" is not and never was S100, and has clearly 
had some told contact fingers cut off.  Perhaps used as a source for 
parts at some point.


You might want to join and post this to the "s100computers" Google group.

JRJ

On 1/23/2022 1:42 PM, Stan Sieler via cctalk wrote:

Hi,

I have a mystery S-100 computer that I'm would like to sell, from the
estate of the late Ken Gielow (author of Z80DIS, a great Z80 disassembler).

The proceeds will be donated to a non-tax-deductible magic group Ken was a
long-time member of.

The computer is located in Cupertino, CA (aka "the heart of Silicon
Valley", in the S.F. Bay Area).   (If reopened, you can combine a pickup
with a visit to the Computer History Museum in nearby Mountain View, CA! :)

This would likely be quite expensive to ship.  I'd guess 30+ pounds.

Photos and some info at:
www.sieler.com/ken_photos

Some of the hardware (also listed on the above page):
ThinkerToys buss
unknown semi-transparent front panel
spare/uninstalled Ithaca Intersystems DPS-1 front panel
10 various boards inside
metal case (heavy)

There may be manuals on some of the boards and/or the Ithaca, but I'm not
sure yet.  (They would be included, if they exist.)

I wanted to take photos of each board, but having been seated for about 40
years, they don't come out if I tug gently.  None have integrated board
lifters, unfortunately
(I tried a boroscope, but could not get useful photos.)

Based on the labels on some EPROMS, there's a chance that it's a homebrew
TRS-80 clone, with both Level II BASIC and CBASIC, and may have Morrow
DISCUS software on it.

We're looking for an offer on either:

- the Ithaca Intersystems front panel;

- the computer with all the boards

or both.

Suggestions welcome, thanks!

Re: Source for replacement caps in H744 regulators

[Jay Jaeger via cctalk]

On 1/7/2022 2:35 PM, Nigel Johnson Ham via cctalk wrote:
I told the chief engineer that the problem was the same thing that 
caused planes to crash, and he suggested maybe the cargo door had fallen 
off!  (that puts it in 1972 since it was AA Flight 96 that had just 
happened!)




My uncle worked for McDonnell Douglass as an engineer and my dad told me 
that he got called back to work on that DC 10 door issue.


JRJ

Re: Source for replacement caps in H744 regulators

[Jay Jaeger via cctalk]

On 1/6/2022 7:03 PM, W2HX via cctalk wrote:

My 2c. I am not familiar with a "whine" but certainly a "hum." Sometimes if a power 
supply has seen a lot of heavy load over its lifetime, the heat generated can begin to do things to the 
transformer. And once that heat has done its "thing" to the transformer, it stays that way. And no 
replacing external components will change the hum. However, there are some transformers with bolts and nuts 
that hold the laminations together. Sometimes they can be tightened to reduce the hum. I don’t know this PS 
specifically and whether it falls into this category or not.

I don’t know if what you are hearing is transformer hum, but if it is, you may 
just have to live with it.

73 Eugene W2HX
Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos


This does not fall "into this category".  This is typically high 
frequency (in excess of 10KHz) whine, not 60 cycle, 120 cycle or even 
400 cycle "hum".


My experience with many PDP-11 machines going back to the mid 1970s, and 
those in my collection, is that this whine from the *switching* power 
supplies is very common. For some people, it may be above the frequency 
that they can hear.  For me it is not (I could also hear burglar alarms 
in excess of 20KHz back in the day, though I doubt I could now, at age 70.)


My *guess* is that it comes from the inductors in the switching circuit, 
and is *mechanical*, induced by the switching waveform, which in turn is 
dependent upon load.  If I had one that was really bad, I'd be tempted 
to put on a glove for insulation and hold those to see if the mechanical 
pressure made any difference.


JRJ

Re: TU56 DECtape takeup reel needed

[Jay Jaeger via cctalk]

On 12/12/2021 1:08 PM, Alan Frisbie via cctalk wrote:

I just unpacked the rack with my TU56 DECtape drive and discovered that
the movers managed to break the takeup reels.  This, despite many layers
of foam padding, stretch film, and warning signs.  On the other hand,
this was the only item that suffered any damage at all.  Not too bad for
three moving van loads!

Can anyone help me with an empty DECtape reel or two?

Thanks,
Alan Frisbie


Were they left on the drive during shipping?

Anyway, I can probably find one lying around that I could spare.  (Or, 
if you have a bunch of tapes, maybe sacrifice a scratch?)


Location?

JRJ

Re: RC11 controller (Was: Reproduction DEC 144-lamp indicator panels)

[Jay Jaeger via cctalk]

On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk wrote:


On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:


One could perhaps emulate the RS64 data stream using a fast-enough 
micro, ala the MFM emulator.


Why does everyone seem to want to emulate HW like this with a micro when 
a reasonable FPGA implementation with some external FRAM would do the job?




1)  Because not everyone has that kind of design experience and 
capability (I do, but that is beside the point).  In such a case, 
suggesting a FPGA might cause those readers to just skip it without 
further thought, whereas suggesting a micro is less likely to have that 
effect on someone who *does* have the design experience.


2)  Because the tooling on FPGAs is sometimes a pain and the parts 
themselves are always in flux, and the updated tools often don't support 
the older parts.  Over the last 20 years I have gone through at least 3 
different FPGA development boards and toolsets, where as my original 
Arduino is just as useful as ever.


3)  Because a highly flexible FPGA development board costs a lot more 
than a micro, and micros would be a lot cheaper on a stand-alone PCB 
than an FPGA part (or an FPGA through-hold carrier for those who are not 
up to doing something like an FPGA part on a PCB.)


4)  Because a micro form factor is smaller than an FPGA development board.

5)  For someone well versed in software but not as well versed in design 
(though enough that they could still do what you suggest), doing the 
software might only take a couple of days for something like a 64Kw disk 
(if it isn't too fast), and easier to debug/fix/enhance as well.


6)  Because it was just a *suggestion* that one might emulate the disk 
itself in hardware (see also point 1).


On the other hand, speed kills, and some disks are just too fast for a 
micro alone to do.


The SMD/ESDI emulator that I've been working on has to "brute force" the 
emulation because of BW concerns.  That is, it has to read the entire 
emulated disk image into DRAM because:


1. You need at least a track's worth of buffering to send/receive the
    data though the data interface (serial)
2. You don't have enough time to transfer tracks in/out of the track
    buffer to flash (or what ever) to meet the head switch times
3. You don't have enough time to transfer whole cylinders in/out of the
    cylinder buffer to flash (or what ever) to have reasonable
    track-to-track seek times

So it will require a micro, but that's mainly to manage what's going 
in/out of the (large) DRAM back to flash (it reads the entire emulated 
disk image into DRAM during boot).  All of the actual commands and data 
movement across the interface are all done by an FPGA.




Cool.  Would love an ESDI emulator for my Apollo DN3000 and SMD 
emulation for my VAXen and PDP-11/24.

Re: RC11 controller (Was: Reproduction DEC 144-lamp indicator panels)

[Jay Jaeger via cctalk]

On 12/9/2021 7:49 PM, Noel Chiappa via cctalk wrote:

 > From: Steven Malikoff

 > Was there ever an indicator panel for the RC11? .. I have a set of RC11
 > modules .. No backplane though. I've not found any docs for these, I 
suppose
 > they're probably on bitsavers and have overlooked them.

Looking at the manual and engineering drawings (at BitSavers, as you guessed), 
no lights.

I've added links to those to the CHWiki RC11 page:

   https://gunkies.org/wiki/RC11_disk_controller

The engineering drawings have the wirelist for the backplane, so it would be
possible to wire a new one. (I'm in the process of doing that for my KE11-A.)
Not sure it would be much use without an RS64 drive, though.

Noel



One could perhaps emulate the RS64 data stream using a fast-enough 
micro, ala the MFM emulator.


JRJ

Re: TU58 / DECtape II: Capstan goo

[Jay Jaeger via cctalk]

On 12/7/2021 4:38 PM, Jan-Benedict Glaw via cctalk wrote:

Hi!

Some time ago, I got my hands on a DECtape II, though no tapes.
That'll change after a long time and in a few days, even multiple
tapes will come in.

   With that drive, I started some first tests. It's PSU seems to be
all fine, providing stable 5 and 12 V.

   It's board's wire wrapping is in factory settings, so baud rate etc.
is all known.

   However, when I checked the two drives capstans, they're old. One
has a crack, and as things go, they feel partially either hard or
gooey. Are there recommendations to exchange these for new ones? I
also noticed that one of the two motors rotates quite freely
(both unconnected from the board, so I'm sure they're not magnetically
braked) while the other ... can be turned without any unreasonable
torque, but it won't continue to spin at all.



I made some up using some two layer rubber hose from Home Depot, 
sanded/ground down to the proper diameter.



   Also, when the tapes arrive, are there recommendations in case their
drive belts are gone?

   And a final question: There are three firmware versions archived for
the TU58 control board. It's a known version:

jbglaw@charon:~/customers/Glaw/VAX/DECtape II$ md5sum *.bin | sort
0e5f30a960e72c9d64174a4da8f48f50  23-294E2-00.bin
5e059396f779aef9cd80bc75a36c90b2  23-089E2-00.bin
5e059396f779aef9cd80bc75a36c90b2  jbglaw-DECtapeII-ROM.bin
a407fbb5aaa4823a92dd2bc374d1d3ae  23-389E2-00.bin



Interesting.  I have no idea which ones I have.  Maybe earlier versions 
came out for the PDP-11 before the VAXen?



I guess I got the oldest version? Were there board changes, or could I
put in a compatible 2Kx8 ROM with any of these versions?  I guess any
firmware will probably work "good enough", but if I'd avoid known
problems (are the differences known?), I'd rather avoid them.

   But after all, I'm quite happy that all the bits'n'pieces will come
together in a few days.  Yay!

MfG, JBG

Re: RK11-C indicator panel inlays?

[Jay Jaeger via cctalk]

I would be interested in an inlay - I have an RK11-C, but no indicator 
panel.


Also, if someone (else, presumably) does up a replica of the indicator 
panel board (perhaps with the option to use LEDs, with some resistor 
packs that could be bypassed for lamps), I'd be interested in that, too.


As a BTW, when I got my PDP-11/20 from the U Wisc. ECE dept. they had a 
home grown 11.5" high indicator panel that watched the bus signals and 
displayed the registers and PSW in LED's.  I disconnected it, but I 
think I left the connector in place on the 11/20 for it.


JRJ

On 12/5/2021 1:12 PM, Noel Chiappa via cctalk wrote:

Let me get this out before the list gets shut down _again_...


There is discussion of doing a run of indicator panel inlays:

   http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html

for the RK11-C (which is wired for an indicator panel, although as far as
I know, DEC never did the inlay).

If you're interested... you will need a standard DEC indicator panel light
panel (with flat cables with plug-in-cards on the ends). (I don't have any
insight on how to get one of those. It shouldn't be _too_ hard to make
replicas, but I'll leave that topic for the moment.)

All I am proposing to do is create the silk-screened inlay that turns a DEC
indicator panel into an RK11-C indicator panel (starting with a functional
indicator penel without the inlay).


All DEC indicator panels use the same actual light panel and flat
cables/plug-in-cards (which have one conductor per light in the light panel);
which light comes on is set by the way the backplane slots the
cables/plug-in-cards plug into are wired.

So from the prints, which give the wiring to the indicator panel slots, I
managed to work out what an RK11-C panel would look like, roughly (captions
are made up, but the light locations are accurate):

   http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/RK11-C_inlay.txt

Starting with that, Dave Bridgham managed to whip up a rough approcimation of
what the inlay would look like:

   http://pdp10.froghouse.org/qsic/inlay-rk11-c.pdf

We had put a certain amount of work into identifying a font which looks like
the one DEC used, back when; I worked with a member the UK to produce a bunch
of blank inlays (right size/shape, with the black paint on the back with the
holes for the lights). Dave then found someone who could print the white
lettering on the front, and this is what the result looked like, on an
'RK11-F' (the QSIC with RK emulation microcode) panel:

   http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/RK11F-F.jpg

You can compare with an original DEC inlay (TC08, IIRC) here:

   http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2F.jpg

That's on the same light panel, just the inlay is changed. (The lights in the
lower one are from the light panel Dave produced for use with the QSIC; it's
totally incompatible, electrically, with the DEC originals; 4 wires, IIRC, run
the whole thing (data, clock, latch and a ground), as opposed to the 'wire per
light' of the DEC originals. Looks _just_ like the originals (which Tech Sq
used to have a lot of, BITD), though.


Anyway, if anyone is interested, the next step would be to find out who all
wants an RK11-C inlay, and work out _exactly_ what would be printed on it.

Noel

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 12/5/2021 3:37 AM, Rob Jarratt via cctalk wrote:


Thanks for the tips. The transformer that drives the bricks is a real beast. 
Did you find an alternative more convenient way to power them on the bench?



From the schematics, some of them seem to want 20-30 VAC (some, like at 
least one of the -15v regulators, take DC inputs from other regulators)


For lower current initial testing I have some 24v 2A transformers lying 
around.  For higher current, I might use something like this guy:


https://www.digikey.com/en/products/detail/triad-magnetics/F-401U/5032226

JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 12/4/2021 5:57 PM, Rob Jarratt wrote:





What kind of load tester are you looking to buy? I have an 11/45 which I need 
to test the power supplies on too.



Oh just one off of amazon, I expect.  One could either get a nice one in 
a cabinet at all for around $280 - $350, depending upon capacity, or an 
less expensive unit for $100 or so.


This one seems intriguing: the price is modest, said to handle up to 
30V, 20A, 200W (could test 5v up to 20A, 15V up to 13A and at 30V, 
derate down to 6A.


https://www.amazon.com/T-king-Battery-Capacity-Tester-Electronic/dp/B07SFD8R4Y


Here is a slightly more capable unit in a nicer case for $300

https://www.amazon.com/Electronic-Tester-Programmable-Channel-Battery/dp/B091FFSHD5

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 12/1/2021 11:55 AM, Noel Chiappa via cctalk wrote:

 > From the blog of someone who got a KB11-A working

It's Fritz Mueller's blog; at about the top of this page:

   https://fritzm.github.io/category/pdp-116.html

he's just turned the machine on for the first time, and you can
follow as he chases, finds and fixes CPU problems. The KB11-C/D
of the -11/70 is _very_ similar to the KB11-A he was dealing with
(they are _basically_ the same CPU, with a cache, and other stuff
added on the other side from the CPU, on the KB11-C/D), so there
are probably some good lessons to be learned.



Very useful to see as I ponder trying to get my 11/45 (with a KB11-D in 
it) going again.  I think next time I work on this beastie I will roll 
it out from my main room where the lighting and access are just OK into 
my larger room where my PC is kept temporarily, for easier access. 
Going to want to buy a load tester and thoroughly check out the power 
supplies first - which are unfortunately really heavy (and may not be 
mounted quite properly, either), as it has been several years since I 
turned the thing on.


JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/30/2021 6:31 PM, Paul Koning wrote:




On Nov 30, 2021, at 7:17 PM, Jay Jaeger via cctalk  
wrote:

...
The issue is (I think) that the ExpressPCB software can only be used to create 
files to order boards from them - or can it now export ordinary gerbers?  
(Otherwise, to go with another fab. I presumably would re-enter the schematic, 
and re-route it - granted not all *that* hard, but still a day's work.


You're right, they say so in the FAQ.  And it is the reason I don't use them.

At one point I used PCB Pool (Beta layout) because they could take Eagle files 
directly.  But sending boards across the ocean isn't so economical.  And Eagle 
became less and less attractive over time.

My current answer is KiCAD which is open source and somewhat more powerful than 
Eagle (without the hassles).  Both do Gerbers, but there are also fabs that 
take the CAD files directly.  OSHPark is the one I've used for my most recent 3 
projects, they do nice work.  The color is odd, but what the heck, it still 
works.

paul



I have used KiCAD for several projects.  I like it, though the 
developers don't always seem to allow for the pain the cause when they 
make version changes that requires a lot of footprint re-hunting.  ;)


JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/30/2021 3:52 PM, Henk Gooijen via cctalk wrote:

Van: Fritz Mueller via cctalk
Verzonden: dinsdag 30 november 2021 22:43
Aan: General Discussion: On-Topic and Off-Topic 
Posts
Onderwerp: Re: PDP-11/70 Boards



I built mine from a layout on Tom Uban’s site: 
http://www.ubanproductions.com/museum.html



Did you use that directly with ExpressPCB and order from ExpressPCB or did you 
convert to more standard gerbers?


I just went with ExpressPCB for minimal hassle, but you could probably get it 
cheaper from other board houses these days.  For my KB11-A + FP11-B, which run 
asynchronously, it was handy to build up two of these.  Also useful for the 
RK11-C.

   —FritzM.

And useful for PDP-11/05, PDP-11/10, PDP-11/20, PDP-11/35, PDP-11/40 … more?
Henk, PA8PDP



The issue is (I think) that the ExpressPCB software can only be used to 
create files to order boards from them - or can it now export ordinary 
gerbers?  (Otherwise, to go with another fab. I presumably would 
re-enter the schematic, and re-route it - granted not all *that* hard, 
but still a day's work.


JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/30/2021 2:04 PM, Fritz Mueller via cctalk wrote:


On 11/30/21 10:06 AM, Noel Chiappa via cctalk wrote:
 From the blog of someone who got a KB11-A working, you'll really need KM11
cards...



On Nov 30, 2021, at 10:59 AM, Guy Sotomayor via cctalk  
wrote:
I do still have KM11 boards and some overlays (I'd have to check to see if I 
have the appropriate overlays for the 11/70).  I don't unfortunately have any 
light masks or full kits.


I built mine from a layout on Tom Uban’s site: 
http://www.ubanproductions.com/museum.html 
.  I have found the single long 
board form factor convenient, but they don’t have nice light dividers and overlays 
like Guy’s.

Agreed that at least one of these, as well as a hex extender card, are 
absolutely essential if you need to debug CPU/MMU/FPU cards (which, given their 
age, is nearly guaranteed unless you are getting them pre-checked/repaired from 
another restorer.)

  —FritzM.




Did you use that directly with ExpressPCB and order from ExpressPCB or 
did you convert to more standard gerbers?  (This thread has me 
motiviated to maybe get my 11/45 running again next year, and verify or 
fix my FP11-C)


[Note,  I have also been corresponding with the OP on purchase of my 4 
"spare" boards for an FP11-C]


JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/29/2021 7:32 AM, Ed C. via cctalk wrote:

Dear list, I'm currently restoring a PDP-11/70 system and need the
following boards to complete the CPU:

FP11-C slots:
M8127
M8128
M8129

Cache slots:
M8142
M8143
M8144
M8145

Any help finding these is appreciated. Thanks.



So, it turns out that I *do* have an FP11-C.  My PDP-11/45 with the 
KB11-D processor in it has an FP11-C.  So, at the least, I would need to 
try and figure out if the boards in it right now are the ones that came 
with it [This is what my notes from 1989/1990 say], or are my spares, 
and, at the least one of the two M8126 boards is marked "Bad".


JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/29/2021 7:32 AM, Ed C. via cctalk wrote:

Dear list, I'm currently restoring a PDP-11/70 system and need the
following boards to complete the CPU:

FP11-C slots:
M8127
M8128
M8129

Cache slots:
M8142
M8143
M8144
M8145

Any help finding these is appreciated. Thanks.



I presume you'd also need M8126, or is that one there already?

JRJ

Re: PDP-11/70 Boards

[Jay Jaeger via cctalk]

On 11/29/2021 7:32 AM, Ed C. via cctalk wrote:

Dear list, I'm currently restoring a PDP-11/70 system and need the
following boards to complete the CPU:

FP11-C slots:
M8127
M8128
M8129

Cache slots:
M8142
M8143
M8144
M8145

Any help finding these is appreciated. Thanks.



I have M8127, M8128, M8129 (in my basement for > 20 years, condition 
otherwise unknown).  I don't *think* I have an FP11-C in any machine, 
but I will need to check.


Contact me off list for further discussion.

JRJ

Re: LINCtape images

[Jay Jaeger via cctalk]

On 11/3/2021 12:25 PM, Christian Corti via cctech wrote:

On Wed, 3 Nov 2021, Jay Jaeger wrote:
It seems you didn't notice that I included two separate programs in my 
previous post:  XMTAPE and CMPTAP  ;)


I did, and I have found an error ;-)

0275  0361 7300  #WDFLSH CLA CLL
0276  0362 1073 0073 TAD XMCNT   [ IF COUNT==128.
0277  0363 1176 7600 TAD (0-128.
0300  0364 7450  SNA
0301  0365 5761 0361 JMP;WDFLSH  [ THEN JUST RETURN

The space for the return address is missing at the beginning of WDFLSH

Christian


Yes, in XMTAPE it looks like

0275  0361 7300  #WDFLSH CLA CLL

It should read

#WDFLSH  0
 CLA CLL

I *thought* I had tested it. ;)

But, as it turns out, WDFLSH is only called from one place, and is only 
called when the accumulator is 0 (and probably the link bit is zero 
two), so while this is definitely an error in coding, at first blush I 
don't think it affects operation of the program.


JRJ

Re: LINCtape images

[Jay Jaeger via cctalk]

On 11/2/2021 9:53 PM, Vincent Slyngstad via cctalk wrote:

On 11/2/2021 2:25 PM, Jay Jaeger via cctalk wrote:
Here is a program I wrote for reading/writing tape images via XModem 
protocol for my PDP-12, and another for comparing two linctapes.


Cool!  I was able to recover the code and convert it into a more modern 
PAL dialect.  Your listings also don't display the many literals that 
were generated on page zero (except sort of implicitly).


In making the page zero literals line up (so that the code matches the 
originals), I found two locations in xmtape which are coded as

 TAD    (16.
but the code references a new literal at location 0161, instead of the 
previously generated one at location 0166.  This is at location 0567 and 
again at 0666.


(In the PAL assemblers, the "(" must be a "[", you can't use "." to 
change radix, etc. etc.)


 Vince


I probably used LAP-6 or DIAL to do the assembly - I don't recall right 
now.


It seems you didn't notice that I included two separate programs in my 
previous post:  XMTAPE and CMPTAP  ;)


In XMTAPE we see:

0215  0315 1161 0020 TAD (16.
0540  0567 1161 0020 TAD (16.
0646  0666 1161 0020 TAD (16.

In CMPTAP - a separate program - we see:

0216  0336 1166 0020 TAD (16.

JRJ

Re: LINCtape images

[Jay Jaeger via cctalk]

On 11/3/2021 3:27 AM, Christian Corti via cctalk wrote:

On Tue, 2 Nov 2021, Jay Jaeger wrote:
Here is a program I wrote for reading/writing tape images via XModem 
protocol for my PDP-12, and another for comparing two linctapes.


This is fantastic, thanks :-)
I hope this will help us in bootstrapping the PDP-12. At least I would 
like to have a tape with all the diagnostics.
For now, we are at least able to load programs with the BIN loader over 
the serial line with currently 9600 Baud. We need to get the second line 
working for SerialDisk.


Christian


I have some LINCTape images with diagnostics.  Let me know if you need 
one and I can send you the image.


JRJ

Re: LINCtape images

[Jay Jaeger via cctalk]

On 10/29/2021 7:22 AM, Christian Corti via cctalk wrote:

Short question:
How do I transfer LINCtape images back to tape on a PDP-12? Ideally 
there is some binary program to load via papertape to format a tape and 
recreate it with data transfer over the console serial line.


Christian


Here is a program I wrote for reading/writing tape images via XModem 
protocol for my PDP-12, and another for comparing two linctapes.


JRJ

8L OF XMTAPE PAGE 01
LN=0001

0001 [ PROGRAM TO SEND A
0002 [ TAPE ON UNIT 1 TO
0003 [ A PC VIA XMODEM
0004 [
0005 [ CONSTANTS
0006 [
0007 XSOH=1
0010 XNAK=25
0011 XCAN=30
0012 XACK=6
0013 XEOT=4
0014 SRTAPE=1[ SR11 1 FOR OS/12 TAPE
0015 SRCMP=2 [ SR10 1 FOR COMPARE
0016 SRWRIT=4[ SR9 1 FOR WRITE
0017 [
0020 [ SPECIAL INSTRUCTIONS
0021 [
0022 AXO=1
0023 PDP=2
0024 TMA=23
0025 RDC=700
0026 WDE=706
0027 DKSF=6401
0030 DKCC=6402
0031 DKRB=6406
0032 DTLS=6416
0033 DTSF=6411
0034 [
0035 [ DATA
0036 [
0037 $70
0040  0070   #XMPTR  0   [ PTR INTO XMBUF
0041  0071   #XMBLK  0   [ XMODEM BLOCK #
0042  0072   #XMCKSM 0   [ XMODEM CHECKSUM
0043  0073   #XMCNT  0   [ WORK COUNTER
0044  0074   #XMACK  0   [ ACKNOWLEDGEMENT CHAR
0045  0075   #ROTCNT 0   [ WORK COUNTER FOR RAR
0046  0076   #WDCNTI 0   [ WORDS PER BLOCK
0047  0077   #BLKCNT 0   [ BLOCKS PER TAPE
0050  0100   #WDCNT  0   [ WORK COUNTER
0051  0101   #HNKCNT 0   [ WORK COUNTER
0052  0102   #HNKMEM 0   [ ADDRESS OF BLOCK
0053  0103   #XMWORD 0   [ XMODEM INCOMING WORD
0054  0104   #XMPROT 0   [ XMODEM PROTOCOL CHAR
0055 [
0056 [ INITIALIZATION
0057 [
0060 $200
0061  0200 7402  #START  HLT
0062  0201 7301  CLA CLL IAC [ XMODEM BLOCK=1
0063  0202 3071 0071 DCA XMBLK
0064  0203 1177 1155 TAD (XMBUF  [ XMPTR = ADDR(XMBUF)
0065  0204 3070 0070 DCA XMPTR
0066  0205 1176 7600 TAD (0-128. [ XMCNT = -128
0067  0206 3073 0073 DCA XMCNT








8L OF XMTAPE PAGE 02
LN=0070

0070  0207 7404  OSR [ IF SR11 == 0 THEN
0071  0210 0175 0001 AND (SRTAPE
0072  0211 7440  SZA
0073  0212 5220 0220 JMP INITP
0074  0213 1174 7400 TAD (0-256. [ WDCNTI= -256.
0075  0214 3076 0076 DCA WDCNTI
0076  0215 1173 7000 TAD (0-1000 [ BLKCNT = -01000
0077  0216 3077 0077 DCA BLKCNT
0100  0217 5225 0225 JMP INIT1   [ ELSE
0101  0220 7300  #INITP  CLA CLL
0102  0221 1172 7577 TAD (0-129. [ WDCNTI = -129.
0103  0222 3076 0076 DCA WDCNTI
0104  0223 1171 5000 TAD (0-3000 [ BLKCNT = - 03000
0105  0224 3077 0077 DCA BLKCNT
0106  0225 3254 0254 #INIT1  DCA BLOCK   [ BLOCK = 0
0107  0226 7404  OSR [ IF SR10==1 THEN COMPARE
0110  0227 0170 0002 AND (SRCMP
0111  0230 7440  SZA
0112  0231 5567 0500 JMP CMPINI  [ GO COMPARE
0113  0232 7404  OSR [ IF SR9==1 THEN WRITE
0114  0233 0166 0004 AND (SRWRIT
0115  0234 7440  SZA
0116  0235 5565 0603 JMP WTINI   [ GO WRITE
0117 [
0120 [ READ NEXT HUNK (1 FIELD)
0121 [ (16 BLOCKS) INTO MEM.
0122 [
0123  0236 7300  #RDHNK  CLA CLL
0124  0237 1164 7760 TAD (0-16.  [ HNKCNT = -16.
0125  0240 3101 0101 DCA HNKCNT
0126  0241 3102 0102 DCA HNKMEM  [ HNKMEM = 0
0127  0242 7300  #RDBLK  CLA CLL
0130  0243 1102 0102 TAD HNKMEM  [ TMA MEMORY ADDRESS
0131  0244 6141  LINC
0132  0245 0023  TMA
0133  0246 0002  PDP
0134  0247 7300  CLA CLL [ EXTENDED, FIELD 1
0135  0250 1163 1020 TAD (1020
0136  0251 6141  LINC
0137  0252 0001  AXO
0140  0253 0710  RDC 10  [ READ UNIT 1
0141  0254   #BLOCK  0
0142  

Re: PDP-11 Unix V7M-11 V1.0 under SIMH

[Jay Jaeger via cctalk]

On 10/4/2021 6:26 PM, Tony Nicholson via cctalk wrote:

*Neat*! I was thinking of trying to lay this down on a real 11/23+ here
at the house, then realized I didn't have two RD51's. Can it gen on an
RD53 by chance, I could upload one of those to a disk in a weekend or
immediately with the Dave Gesswin emulator (which I need to return but
we're just about to pull out those big Perqs)


Chris,

I doubt you'll be able to use anything other than a RD51 drive - as
this ancient V7M doesn't yet support newer drive types.  You might
be able to put some of the system files on an RL02 - but I haven't confirmed
there's a RL02 boot loader on this kit.

Back in 1983 the PDP-11/23-PLUS was a relatively *new* machine.  There's
later versions of Ultrix-11 (V2 and later) that added support for the 11/73
and bigger drives - look on the Unix Heritage Society site under Unix
Archive.  There's a downloadable installation tape for Ultrix-11 there.

https://www.tuhs.org

Tony



Once installed, one ought to be able to gen a system for other devices, 
at least for an RL01/RL02, but perhaps not for RD series beyond the RD51 
without


The drivers ought to be there for RL01, RL02, RK06, RK07, RP02/3/4/5/6, 
RM02/3/5, RA60 and RA80/81 and more, according to the installation 
manual - you just have to do a sysgen.


Might be good to do the contemplated work under SimH first, of course.

For later RQDX controllers, though, you presumably would need to change 
the driver.


JRJ

Re: PDP-11 Unix V7M-11 V1.0 under SIMH

[Jay Jaeger via cctalk]

On 10/3/2021 1:31 AM, Tony Nicholson via cctalk wrote:

Recently Al Kossow made available a zip file containing a Micro/PDP-11
installation kit for Unix V7M-11 V1.0 on bitsavers as RX50 disk images.

Tinkering away here in Covid lockdown, I've managed to get this running
under SIMH pdp11 emulating an almost historically accurate PDP-11/23 plus.

I've placed the SIMH initialisation file, a couple of RD51 disk images and
an "installation recipe" for making these disks on GitHub at -

https://github.com/agn453/V7M-11

While I mainly had exposure to later versions of Unix and Ultrix-11 on
a PDP-11/70 as an undergraduate - this one surely brings back memories!

Tony



Glad to hear that worked out for you.  I obtained those floppies from a 
friend doing some work for UW Madison back in the day.  I provided Al 
scans of the manuals, too, but they have not been put up on bitsavers yet.


JRJ

Re: PDP-11/05 Fault?

[Jay Jaeger via cctalk]

On 9/29/2021 6:31 PM, Matt Burke via cctalk wrote:


I've been restoring a PDP-11/05 recently and after replacing several
faulty ICs I have it mostly working. I've run into a bit of a problem
whilst running MAINDEC-11-D0NB (T14 TRAP TEST) though.

The failing instruction sequence is:

7200:   MOV #6340,R0
7204:   MOV R0,(R0)+
7206:   CMP 6340,#6342
7214:   BEQ 7220
7216:   HALT

This halts at 7216 with:
   R0 = 6342
   6340 = 6340

I tried this same set of instructions on a PDP-11/84 and also on Simh
and the result is:
   R0 = 6342
   6340 = 6342

which is what the diagnostic seems to expect.



Firstly, I think this is a documented processor difference.

My PDP-11/05S , 11/10S manual, DEC-11-H05SS-B-D, in table 4-8, 
programming differences reads:


OPR %R,(R)+
   11/20: Contents of R are incremented by 2 *before* being used as the
  source operand.
   11/05 & 11/10: Initial contents of R are used as the source operand
   11/35 & 11/40: (Same as 11/20)

So the halt would be expected on an 11/05.

Secondly, I have an original DEC listing of D0NB.  On it I have a 
written note (by me) "Bugs according to (UW Madison) ECE".   But there 
is no notation of that those bugs might be.


The source in my listing reads essentially the same as what you have 
written (comments abbreviated to fit on my lines):


7200  012700 006340  MOV#K11,%0 ; SRC and DST BOTH R0
7204  010020 MOV%0,(0)+ ; SRC No Mem Reference
7206  026727 177126 006342   CMPK11,+#K11+2 ; Dest Is Mem Reference
7214  001401 BEQ.+4
7216  00 HLT; Failed %(0),(0)+
7220  010700 SCOPE

JRJ

Re: Linux and the 'clssic' computing world

[Jay Jaeger via cctalk]

On 9/28/2021 2:15 PM, ben via cctalk wrote:

On 2021-09-28 11:43 a.m., Vincent Long standing via cctalk wrote:

The C standards are more liberal, and continue to require char types 
to be 8 or more bits.
Was PL/I the only language that would let you select data size for 
variables? Of course the fine print would not let you have more than 16

decimal digits, or 32 bit binary. You would think by now that a language
could handle any length data.



Hardly.

FORTRAN:  INTEGER*4 INTEGER*8 (and sometimes INTEGER*2 - e.g. Sun 
FORTRAN-77)  was common, though never adopted as a standard.  Also REAL 
vs. DOUBLE.


COBOL: COMP-1 and COMP-2 for floating point: single and double precision.

Pascal, Ada: specified range of values.  How that actually got 
implemented would be implementation dependent.


And more, I'm sure.

As for any length of data, that becomes a cost/return question.  Adding 
that capability would create no end of headaches for language 
implementation, so it isn't done.  Instead, if one actually needed that, 
one would define a type (with methods) or a set of functions to 
accomplish that - and no doubt many exist out on the 'net.



 Vince

Ben.


JRJ

Re: scanning a ton of documentation

[Jay Jaeger via cctalk]

> On Sep 22, 2021, at 14:05, devin davison via cctalk  
> wrote:
> 
> Hello,
> 
> The person that refered me to my present job  at a datacenter passed away
> this past monday. He was a hardware / software engineer for modcomp
> computers. He left me all of the computers and documents. there are too
> many books to keep, stuff concerning the modcomp computers that is not
> saved anywhere else that i can tell.
> 
> I have picked up storage containers for all the books, and i can scan it
> all. after that, its all probally going in the recycle bin, as i dont know
> where or how i would keep such a large pile of paper manuals on hand.
> 
> what is the prefered format to upload things to bitsavers in? is pdf
> acceptable?

If you go to bitsavers.org there is a short contributor’s guide.  For B/W, 
CCITT Group 4 tiffs at 400dpi is what I do, but then I also generate a PDF from 
them for my own use, and put both on my Google drive and notify Al Kossow of an 
available contribution.

> How can i create a pdf that is not too big on file size? Can the text be
> recognized  and be made searchable within the scanned pdf?

Bitsavers will post process and create a searchable PDF

> 
> any input would be appreciated, Thanks.
> 
> --Devin D.

Re: Classic sale/give-away Jefferson, WI USA

[Jay Jaeger via cctalk]

On 9/18/2021 12:25 PM, John Foust via cctalk wrote:


Given the hot real estate market, I've received an unsolicited
offer to purchase my office building and I'd like to accept it.



Real life.


This means disposing of a great deal of classic computer stuff in
the next 30 days.  I need to let go of what isn't sparking joy,
as they say these days.  At least I saved the pieces.  What will
best let me part with it is knowing that it went to someone who
also appreciates it.



Tough spot.  Even thinking about liquidating my stuff over the next 10 
*years* is daunting.



I'm located in Jefferson, WI, halfway between Madison and Milwaukee.
I'd prefer in-person pickup over shipping, as I have a shortage of
time and adequate shipping boxes for heavy stuff.



Nearby, in Madison but, unfortunately, essentially out of room.  8(


Sure, I'll take cash but I also realize I may need to be giving
it away.  I'm debating how to do it.  Facebook Marketplace?
eBay pick-up only?  Just here on CCC?  A web site?  I'll work on
a more detailed list and pics of what has to go and I'll figure out
the best way to post.  Yes, it's unfortunate that I didn't take
a van-load to VCF Midwest a few days ago.

Off the top of my head, a Microvax, a MicroPDP-11, an 11-23,
a Vaxstation, a Kaypro, two CBM PETs, a Tandy M-100 or two, a
Zilog development system, two PDQ-1, a Sage, some S-100 cards,
piles of other cards for various systems, probably a pile of Amiga
stuff (A500, A1000, A2000, A3000, Toasters, early developer docs),
some C-64 or C-128 and software, some Apple II and clone stuff,
Macs from classic on up, a great deal of 3D related software and
manuals from 80s/90s for Amiga/PC/Mac/SGI, several SGIs, a Play Trinity
video system, Palm handhelds and developer stuff, Compaq and HP
handhelds, a Pertec 9-track, an ASR-33, bare 8-inch drives
and cabling, a number of tube monitors of sizes from large and
SGI and Trinitron down to smaller terminals.  A serial terminal
or two.  A few dot-matrix printers and lasers and ink-jets.
A stack of Pentium Pro 200 chips, bags of other CPUs and older
memory chips.


I suggest listing the S100 stuff on the S100Computers Google Group. 
Would be happy to assist, given a list of stuff, in getting it posted there.


If you have any PDP-8 Omnibus cards, I'd be interested in learning what 
you have.


I'd also be interested in Q-Bus or UNIBUS SCSI, and Q-Bus RX01/RX02, 
RK05 (if such existed) and RL01/02 controllers.


If nobody else wanted the MicroPDP-11, I *might* take that as a spare 
unit to mine.




I have either the world's largest or second-largest collection of
Terak computers, on the order of a dozen, and nine or ten need to go.



Seriously tempting, but I'll have to stay away from the Teraks.  8(


Plus other interconnecting stuff, BNC cable, serial and parallel, etc.
  
Docs like a decade of SIGGRAPH proceedings, Inside Mac, years of

MSDN CD sets (Intel/MIPS/AXP era), sets of late-80s early-90s
computer magazines (inc. early BYTE and Kilobaud and Dr. Dobbs,
Amiga mags, video industry mags).

A pile of early WISP outdoor WiFi era antennas (dishes, panels,
directionals of various dB, N connector) and associated heavy coax.

Plus a fair pile of more "contemporary" PC stuff from the last 20 years.
Misc cards, VLB, EISA, etc.  A bunch of PCs, plus IDE and SATA drives.
Many misc. consumer firewalls.

Some odd laser and optical stuff.  A number of older lab-quality
microscopes like a projector scope, several desk microscopes,
a black Leitz Ortholux, an articulated standing Zeiss surgical scope.
A Leitz Focomat II photo enlarger and all the extras.
An AMRAY electron microscope.

And just to put fear in your heart, what doesn't go will go to you
will go to the electronics scrapper and the dumpster.

Send me an email...

- John



JRJ

Re: Unix or BSD for Dec PDP 11/34 and 11/45

[Jay Jaeger via cctalk]

On 9/17/2021 6:37 AM, devin davison via cctalk wrote:


Hello,

If possible too, id like to be able to telnet in to unix or bsd.I was also
curious if a ethernet interface exists for my unibus systems, or if i could
SLIP/PPP serial to another machine,so i could telnet in as well as use dumb
terminals.



A UNIBUS Ethernet interface does exist - the DEUNA.  It is two boards, 
and very power hungry.   I have a a couple of third party Ethernet 
boards from a VAX, but no documentation on them.   They are not in my 
inventory (they came from a couple of Intergraph VAX systems, and I 
didn't inventory any of those boards), so I'd have to hunt to find them. 
 I doubt very much they are standard DEC software compatible.


JRJ

FTGH: 19" Intergraph Monitors

[Jay Jaeger via cctalk]

I have an Interpro 2020 and a couple of HUGE 19" inch Intergraph 
monitors.  Frankly they are pretty lousy (fuzzy, not all that 
luminescent), heavy and awkward.


Free to a Good Home - cables included.  But I won't ship them, though 
one could pay someone to crate them up and ship them.


I really don't want them around, and so I just converted my Interpro 
2020 to use LCD flatpanels with a DB5w5 to VGA cable.


You can read more about my new cable setup for this machine, and see one 
of the old monitors, at:


https://www.computercollection.net/index.php/unix-workstations/#interpro2020

JRJ

Re: VAX4000 VLC diagnostics/console

[Jay Jaeger via cctalk]

On 9/5/2021 8:12 AM, Peter Corlett via cctalk wrote:

On Sat, Sep 04, 2021 at 09:34:30AM -0400, emanuel stiebler via cctalk wrote:

On 2021-09-04 08:30, Antonio Carlini via cctalk wrote:

"Digital Diggings" couldn't get BlueSCSI to work on either VAX or Alpha:
https://www.youtube.com/watch?v=zFEh7owqHxU=36s. That's a pity as it's
much cheaper than SCSI2SD.


Apparently not so much cheaper any more, since it's based on the dirt-cheap
"Bluepill" SBC which has basically vanished off the market, at least on this
side of the Pond. They seemed to be mainly distributed via AZ-Delivery in
Germany, who are out of stock. I guess they're waiting for the same boat
from China that everybody else is.



There is work going on BlueSCSI for the "Black Pill", using the F4 
variant of the STM32, which hopefully will be more available once the 
current semi crunch subsides (but that might take 6-12 months).


The current implementation for the "Black Pill" is, however NOT OPEN 
SOURCE at this point in time, though I have heard that there will be an 
F4 variant that will be open source in the future.


JRJ

Re: VAX4000 VLC diagnostics/console

[Jay Jaeger via cctalk]

On 9/4/2021 5:44 AM, Adrian Graham wrote:



On 4 Sep 2021, at 02:42, Jay Jaeger via cctalk <mailto:cctalk@classiccmp.org>> wrote:


On 7/14/2021 12:32 PM, Adrian Graham via cctalk wrote:
VT100 to the rescue, the VLC is fine talking to it so now I'm 
wondering why
my old faithful hardware UART in this PC I'm typing on now has let me 
down.
The BlueSCSI appears as 7 devices though, which is usually a 
termination or

ID problem so I now need to dig out an external terminator for the box
since it's never had one. The hard drive in there has been good at
providing its own TERMPWR which the BlueSCSI should too but I'll play by
the rules to test things properly.
Cheers,


I think BlueSCSI will only appear as the devices you have image files 
named for on its SD card.


What I meant was on a SHO DEV I got 7 Quantum Fireballs (DKA0-500, 
DKA700), in my VAX days this meant there was either an ID conflict with 
another device on the bus or a termination issue. I only had one image 
on the sdcard which was ID0 so there weren’t any other devices present, 
so it had to be a termination issue.




Or a bug.

I don't think that these boards will *provide* terminator power, but I 
haven't looked at the schematics carefully.  If the VAX does provide 
terminator power, it might not be enough to both do that and power the 
blue pill.  I power mine from the 4 pin molex drive power connector by 
using a 4 pin molex to Berg connector adapter to match the connector on 
the one on the BlueSCSI board.


BTW, a caveat:  There is a "Black Pill" version from Tech By Androda out 
there.  The blue.scsi site that points to it indicates that BlueSCSI is 
open source (which it is), but THAT one, the one I bought from Tech By 
Androda IS NOT OPEN SOURCE.  He won't provide the code.  Not even 
binaries on his web site.  (There IS a warning about that on the page 
for the Black Pill (F4) version.)


Also, I see that version 1.0c of the open source  Blue Pill version has 
a fix that involves TERMPOWER: "Fixed issue with external power and 
TERMPOWER".


JRJ

Re: VAX4000 VLC diagnostics/console

[Jay Jaeger via cctalk]

On 7/14/2021 12:32 PM, Adrian Graham via cctalk wrote:

VT100 to the rescue, the VLC is fine talking to it so now I'm wondering why
my old faithful hardware UART in this PC I'm typing on now has let me down.

The BlueSCSI appears as 7 devices though, which is usually a termination or
ID problem so I now need to dig out an external terminator for the box
since it's never had one. The hard drive in there has been good at
providing its own TERMPWR which the BlueSCSI should too but I'll play by
the rules to test things properly.

Cheers,



I think BlueSCSI will only appear as the devices you have image files 
named for on its SD card.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/28/2021 5:14 PM, Chuck Guzis via cctalk wrote:

On 8/28/21 3:01 PM, Jay Jaeger via cctalk wrote:


Back in 2005 I imaged both my Mod I and Mod II floppies using my Altair
and a program I wrote way way wayy back when for transferring floppy
images called "XMT".  But I like to image floppies two different ways,
and the Greaseweazle cannot (yet) deal with hard sectoring.


It can't---that's a surprise to me.   I used a MK III by the way--the
image is from 2007.



That is correct.  It can't.  I expect it is just a matter of software 
and firmware.  You can get a .scp file out of it by telling it to read, 
oh, 60 revolutions, but the .scp file is pretty useless.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/28/2021 3:06 PM, Chuck Guzis via cctalk wrote:

On 8/28/21 12:27 PM, Al Kossow via cctalk wrote:

On 8/28/21 12:12 PM, Jay Jaeger via cctalk wrote:


I have successfully read a couple of Mod I disks (143KB).  But some
have not read very well.


I played with one when they came out. The software wasn't ready for
prime time.

I had hoped it had gotten better since then. Even something basic like
^C out of a transfer
locked the board up.


I believe that I used an MPI 100 tpi drive when I processed the Vector 4
images.   Came off without a hitch using a Catweasel.

Raw decoded image was about 600K.

One of the first jobs was to decode the memorite disk itself.

Here's the disk image dump, if you're curious.

https://app.box.com/s/mw9pk2xmrcr8ageu2ueuutvk4b6iw721

--Chuck





Back in 2005 I imaged both my Mod I and Mod II floppies using my Altair 
and a program I wrote way way wayy back when for transferring floppy 
images called "XMT".  But I like to image floppies two different ways, 
and the Greaseweazle cannot (yet) deal with hard sectoring.


Of course, I could also use my catweasel with these drives directly - 
but kind of a pain to do.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/28/2021 2:27 PM, Al Kossow via cctalk wrote:

On 8/28/21 12:12 PM, Jay Jaeger via cctalk wrote:

I have successfully read a couple of Mod I disks (143KB).  But some 
have not read very well.


I played with one when they came out. The software wasn't ready for 
prime time.


I had hoped it had gotten better since then. Even something basic like 
^C out of a transfer

locked the board up.



And, still does, unfortunately.  I opened a ticket for that.  ;)

Re: Call for manuals and maybe floppies: IBM 8100

[Jay Jaeger via cctalk]

On 8/28/2021 2:25 PM, Al Kossow via cctalk wrote:

On 8/28/21 12:11 PM, Jay Jaeger via cctalk wrote:



 also looked at some field service material available on archive.org.



Was this different from the docs I have on bitsavers?
They have all of bitsavers, but changed the filenames and screwed up the 
directory heirarchy.


IA is a nightmare to search.



The are indeed the same - I missed them because I only searched my own 
mirror for the manual numbers when I went searching for 8100 stuff last 
week.  Should have looked in IndexByDate.txt (blush)


BTW, I have scanned the PoO and storage manuals yesterday, and they are 
in the usual hierarchy I put stuff to contribute within.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/27/2021 10:08 PM, Jay Jaeger via cctalk wrote:

On 8/26/2021 2:51 PM, Jay Jaeger via cctech wrote:



On 8/25/2021 5:58 PM, Mike Loewen via cctalk wrote:

On Wed, 25 Aug 2021, Dennis Boone via cctalk wrote:



    As a few of the signals on the 34-pin connector are different 
than the Shugart layout, I'm considering making up a custom cable and 
connecting it to my Catweasel MK4+. I have a utility from Andrew 
Lynch called "cwns", which is a modified version of "cw2dmk" to read 
Northstar hard-sector (10 SPT) diskettes. I might be able to modify 
that to read the VG 16 SPT diskettes, if the 1043-2 will work with 
the Catweasel.


It will not - but it has nothing to do with the cabling.  I already 
tried with my catweasel.  I was able to read flux, but between the 
hard sectoring and (possibly) different meta markers for the floppy 
sectors, the .scp file is useless.  I just got my Cypress board for a 
fluxengine in the mail yesterday, but haven't set it up yet - maybe 
tomorrow.  The website for fluxengine indicates it ought to work.




The fluxengine almost works with my Micropolis drives - but there are 
some problems.


1)  The drive select pins are different.  I am having *some* luck access 
one driver of my daisy-chained pair, but not the other.  The fluxengine 
setup and/or the drive also seem to get confused when I try to access 
the other drive.  I submitted an issue on github for more flexible drive 
selection / motor control capability.  One could work around this with 
suitable cabing / jumpering.


2)  So far I have not been able to read an entire Mod II disk 
successfully - lots of good sectors on two, but not all without errors 
on either one.  But I have not tried cleaning the heads on my drives, or 
trying the Mod I with different select jumpering.


3) The Micropolis drives are slow stepping, so I added multiple commands 
to seek to cylinder 0 to my script - not sure if that is actually 
working right.




Another update.  Without messing with the cable pinouts the fluxengine 
will only support a Micropolis drive strapped for DS2 (as fluxengine 
drive 0).


I have successfully read a couple of Mod I disks (143KB).  But some have 
not read very well.  Sometimes it goes "off the rails" and says there 
are 77 tracks, even when the input config specifies 35.  My guess is 
that at the least the decoder could probably need some improvement - a 
task I am not up for, at present.






Mike Loewen    mloe...@cpumagic.scol.pa.us
Old Technology    http://q7.neurotica.com/Oldtech/


JRJ


JRJ


JRJ

Re: Call for manuals and maybe floppies: IBM 8100

[Jay Jaeger via cctalk]

On 8/26/2021 7:54 PM, Paul Berger via cctalk wrote:


On 2021-08-26 6:48 p.m., Jay Jaeger via cctech wrote:
My next project once I finish my IBM 1410 FPGA implementation (so, a 
couple of years out, probably) would be to write an emulator for the 
boat anchor known as the IBM 8100.  I had exposure to these things 
back in the 1980s.  The project was not really a success: the DPPX 
operating system was way overkill for the underpowered machine, and 
wasn't reliable enough or capable enough to run them at remote 
locations with central administration.


The machine had some fairly sophisticated features:
   Two groups of 64 sets of registers with 8 32 bit registers each
   Auto increment and auto decrement indexed addressing
   Address translation - but not paging
   A primitive form of I/O channel


True story:  The early releases of DPPX were just awful buggy.  We 
ended up dedicating 3 conference rooms (with the dividers open) for a 
"warm room" for something like 3 months, housing our personnel and IBM 
personnel up from Texas.  At one point one of the IBM'ers was 
overheard on a public phone in the hallway of our public building 
telling someone he was there "to help the hicks from Wisconsin".  That 
got reported to our management and to IBM's management, and he was on 
the next flight back to Texas.  ;)


On the flip side, I was testing database recovery (it was my thing, 
back in the day - though we did not end up using the database / 
transaction manager).  I found some bugs in the database log journal 
recovery process.  I mentioned it to one of the IBM'ers in passing, 
also pointing out it wasn't urgent since we were not going to use DTMS 
anyway, at least not soon.  He pretty much begged me to report it - 
and anything else I found wrong.  Completely polar opposite attitude 
of the guy in the previous paragraph.


JRJ


The 8100 came out during my first stint in field service, most of the 
machines we saw where 8130s that ran the DPCX operating system and they 
where purchased to replace 3790 distributed processors. We had one 
customer who bought an 8140 and I helped with a model upgrade on it, 
which involved removing all the logic gates as one unit and replacing 
them with the upgraded one.  It would have been quicker and probably 
cheaper to ship an entire new machine, but they where advertised as 
field upgradeable so.   A few years later when I saw the inside of a 
S/38 I recognized the packaging of the system as being identical to the 
8140 except the 8140 did not have the built in CRT console or magazine 
diskette drive. This 8140 was running DPPX but I don't know how the 
customer got on with it as it was not my account.  It is said that the 
8100 processor is the Universal Controller (UC), but I am hoping it was 
a beefed up on from the UC engine that ran several of the "Industry 
Systems" controllers such as 3274 (NDS), 3601 (Banking), and 3651 
(retail store systems).


Paul.




I had a look at the UC information on 
bitsavers.org/pdf/IBM/microcontrollers, and also looked at some field 
service material available on archive.org.


The CPU comprises several boards, so it wasn't UC per se.  There was a 
ROS-driven micro controller that handled instruction fetch and 
branching, but it had 56 bit words per that field service material.


It may have had a similar software architecture to the UCs, but at 
present from what I have seen the similarity seems to end their.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/26/2021 2:51 PM, Jay Jaeger via cctech wrote:



On 8/25/2021 5:58 PM, Mike Loewen via cctalk wrote:

On Wed, 25 Aug 2021, Dennis Boone via cctalk wrote:



    As a few of the signals on the 34-pin connector are different than 
the Shugart layout, I'm considering making up a custom cable and 
connecting it to my Catweasel MK4+. I have a utility from Andrew Lynch 
called "cwns", which is a modified version of "cw2dmk" to read 
Northstar hard-sector (10 SPT) diskettes. I might be able to modify 
that to read the VG 16 SPT diskettes, if the 1043-2 will work with the 
Catweasel.


It will not - but it has nothing to do with the cabling.  I already 
tried with my catweasel.  I was able to read flux, but between the hard 
sectoring and (possibly) different meta markers for the floppy sectors, 
the .scp file is useless.  I just got my Cypress board for a fluxengine 
in the mail yesterday, but haven't set it up yet - maybe tomorrow.  The 
website for fluxengine indicates it ought to work.




The fluxengine almost works with my Micropolis drives - but there are 
some problems.


1)  The drive select pins are different.  I am having *some* luck access 
one driver of my daisy-chained pair, but not the other.  The fluxengine 
setup and/or the drive also seem to get confused when I try to access 
the other drive.  I submitted an issue on github for more flexible drive 
selection / motor control capability.  One could work around this with 
suitable cabing / jumpering.


2)  So far I have not been able to read an entire Mod II disk 
successfully - lots of good sectors on two, but not all without errors 
on either one.  But I have not tried cleaning the heads on my drives, or 
trying the Mod I with different select jumpering.


3) The Micropolis drives are slow stepping, so I added multiple commands 
to seek to cylinder 0 to my script - not sure if that is actually 
working right.






Mike Loewen    mloe...@cpumagic.scol.pa.us
Old Technology    http://q7.neurotica.com/Oldtech/


JRJ


JRJ

Call for manuals and maybe floppies: IBM 8100

[Jay Jaeger via cctalk]

My next project once I finish my IBM 1410 FPGA implementation (so, a 
couple of years out, probably) would be to write an emulator for the 
boat anchor known as the IBM 8100.  I had exposure to these things back 
in the 1980s.  The project was not really a success: the DPPX operating 
system was way overkill for the underpowered machine, and wasn't 
reliable enough or capable enough to run them at remote locations with 
central administration.


The machine had some fairly sophisticated features:
   Two groups of 64 sets of registers with 8 32 bit registers each
   Auto increment and auto decrement indexed addressing
   Address translation - but not paging
   A primitive form of I/O channel

I have a set of install floppies for the DPPX operating system and some 
of the associated software (but, sadly, not COBOL or Assembler), imaged, 
and verified to contain what the labels say (via dd conv=ascii), but am 
short on information.


(Of course, if someone else has floppies, all the better.  I can image 
them - they are 8" DSDD, with the first track single density, kinda like 
an RX02).


I do have the Principles of Operation GA23-0031 and
the DASD devices (including floppy) Description GA23-0053

But in order to manage an emulator and actually install DPPX I would 
need just a bit more hardware info - or I would be flying blind to some 
degree as far as the operator panel I/O interaction.)


Hardware Manuals:

8130 Processor Description GA27-3196 and/or
8140 Processor Description GA27-2880
(There was also an 8150, but I doubt the releases I have would run on it.)
8140 Processor Operators Guide GA27-3197 and  GA27-2879 (Expanded front 
panel)


8101/8102 Storage / I/O Unit  GA27-2882
Communications: Loop, Display, Printer: GA27-2883

(The "Loop" was a LAN like thing - kind of akin to the Apollo Domain 
ring, off of which one hung local terminals, such as the IBM 8775).


Distributed Processing Programming Executive (DPPX) Manuals

Installation Primer: G320-6048
Installation Guide: SC27-0401
IPO Planning Guide: GC20-1883

Assembler: SC27-0412
Assembler Messages: SC27-0416

(The machine also supported APL, PL/I, COBOL (which we used), FORTRAN...
But I don't have floppies for those - heck, if the assembler wasn't 
standard (I doubt it was), I don't even have that, even though we had it 
at our installation, along with COBOL)


DTMS (database, transaction mgmt.)
   Messages: SC26-3918
   Customization Guide (SC26-3937)
   Application Development Guide (SC26-3938)
   Administration Guide (SC26-3939)
   Operation Guide (SC26-3940)
   Reference (SC26-3941)

True story:  The early releases of DPPX were just awful buggy.  We ended 
up dedicating 3 conference rooms (with the dividers open) for a "warm 
room" for something like 3 months, housing our personnel and IBM 
personnel up from Texas.  At one point one of the IBM'ers was overheard 
on a public phone in the hallway of our public building telling someone 
he was there "to help the hicks from Wisconsin".  That got reported to 
our management and to IBM's management, and he was on the next flight 
back to Texas.  ;)


On the flip side, I was testing database recovery (it was my thing, back 
in the day - though we did not end up using the database / transaction 
manager).  I found some bugs in the database log journal recovery 
process.  I mentioned it to one of the IBM'ers in passing, also pointing 
out it wasn't urgent since we were not going to use DTMS anyway, at 
least not soon.  He pretty much begged me to report it - and anything 
else I found wrong.  Completely polar opposite attitude of the guy in 
the previous paragraph.


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/25/2021 5:58 PM, Mike Loewen via cctalk wrote:

On Wed, 25 Aug 2021, Dennis Boone via cctalk wrote:



    As a few of the signals on the 34-pin connector are different than 
the Shugart layout, I'm considering making up a custom cable and 
connecting it to my Catweasel MK4+. I have a utility from Andrew Lynch 
called "cwns", which is a modified version of "cw2dmk" to read Northstar 
hard-sector (10 SPT) diskettes. I might be able to modify that to read 
the VG 16 SPT diskettes, if the 1043-2 will work with the Catweasel.




It will not - but it has nothing to do with the cabling.  I already 
tried with my catweasel.  I was able to read flux, but between the hard 
sectoring and (possibly) different meta markers for the floppy sectors, 
the .scp file is useless.  I just got my Cypress board for a fluxengine 
in the mail yesterday, but haven't set it up yet - maybe tomorrow.  The 
website for fluxengine indicates it ought to work.


    It's been pointed out that I could write something for the Vector 1 
to read diskettes and transfer the contents out the serial port. I'd 
rather attack it from the point of my media imaging system, and there is 
a literal shoebox full of diskettes to image.




That was what I did back years ago.



Mike Loewen    mloe...@cpumagic.scol.pa.us
Old Technology    http://q7.neurotica.com/Oldtech/


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

On 8/25/2021 3:57 PM, Fred Cisin via cctalk wrote:

On Wed, 25 Aug 2021, Jay Jaeger via cctalk wrote:

I don't have that code, however a couple of points:
First of all, I think Vector Graphic actually used Micropolis drives 
(and I suspect yours are because of the hard sectoring).  I have 
Micropolis drives on my Altair.  Back in 2006 I imaged my floppies - 
by reading the sectors on my Altair and transferring the data over to 
my PC and saving an image file.
Note that at least for the 100 TPI Mod II model you'd have to use an 
actual Micropolis drive or the tracks won't line up.  I don't know if 
that is also true of the Mod I drives which have a more standard 
tracks per inch.


Important points!
Yes, Vector Graphics was 100tpi.  That was not the only unusual aspect 
to their format.


Yes, Micropolis ALSO made 48tpi single sided drives.  I don't remember 
whether they were 35 track or 40 track; I used one for years on a TRS80 
(which wass 35 track); it was an exceptionally reliable, albeit heavy 
and slow-steppping drive.




35 track. The aforementioned "Mod I" models.



For 100tpi, there also existed Tandon TM100-4M drives.  The M stood for 
"Micropolis".   One of the TM100-4M drives that I had did not have the 
'M' on the label.


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


JRJ

Re: CWVG

[Jay Jaeger via cctalk]

I don't have that code, however a couple of points:

First of all, I think Vector Graphic actually used Micropolis drives 
(and I suspect yours are because of the hard sectoring).  I have 
Micropolis drives on my Altair.  Back in 2006 I imaged my floppies - by 
reading the sectors on my Altair and transferring the data over to my PC 
and saving an image file.


Note that at least for the 100 TPI Mod II model you'd have to use an 
actual Micropolis drive or the tracks won't line up.  I don't know if 
that is also true of the Mod I drives which have a more standard tracks 
per inch.


Back in 2006 I modified some existing catweasel code I got from Jim 
Battle to handle Data General hard sector floppies, and if I remember 
correctly - this was all back in 2006 - also changed the code so that 
more stuff was in tables.  You can find a link to download the code at:


https://www.computercollection.net/index.php/specialized-interfaces/

It would require source code changes to read Micropolis floppies directly.

Another option might be the open-source fluxengine, which has 
dead-simple hardware that plugs into USB, and can also process catweasel 
cell capture files.  (Greaseweazle can't handle hard sector floppies yet)


http://cowlark.com/fluxengine/index.html
http://cowlark.com/fluxengine/doc/disk-micropolis.html

I am actually looking to re-image my Micropolis floppies (single sided, 
both Mod I and Mod II) to confirm my existing images, and have the 
requisite hardware on order from DigiKey which should arrive this week. 
 Fluxengine already has support for hard sectoring, so I will give that 
a try and report back in a few days.


JRJ


On 8/24/2021 6:00 PM, Mike Loewen via cctech wrote:


    Back in the 2007 time frame, Andrew Lynch had written a utility to 
read Vector Graphic hard-sectored diskettes on a Catweasel board. Called 
"CWVG", does anyone have a copy of the program?



Mike Loewen    mloe...@cpumagic.scol.pa.us
Old Technology    http://q7.neurotica.com/Oldtech/

Re: Extremely CISC instructions

[Jay Jaeger via cctalk]

On 8/23/2021 8:51 PM, Van Snyder via cctech wrote:

On Tue, 2021-08-24 at 01:38 +0100, Tom Stepleton via cctalk 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.


IBM 1401 was a character-by-character machine, so most operations had
costs proportional to field length.

One especially expensive (but very useful) operation was "move
characters and edit."

Assuming a 17-character control word has been loaded to the
destination, e.g.

"$   ,  0.  &**"

to edit a data field "00257426" with a "negative" zone bit on the low-
order digit, producing
"$  2,574.26 CR **"

requires 41 memory accesses (including seven to fetch the instruction)
-- 0.4715 milliseconds.

See pages 41-43
at http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Reference_Apr62.pdf

On a machine where  the "Expanded Print Edit Feature" was added, the
instruction cost even more. For example, the "Floating Dollar Sign"
moves the dollar sign to immediately to the left of the most
significant digit. This (and asterisk protection) was to prevent
somebody from adding digits between a left-justified dollar sign and
leading digits on printed checks. The above edit would cost two more
memory cycles. If the datum had had more leading zeroes, even more
cycles would have been required.


Useful for COBOL.  ;)



See pages 82-84.

Another expensive instruction was the simpler "move characters and
suppress zeros" instruction. See page 38.



Along those same lines, the IBM 1410 had what the 1401 had, plus:

http://www.bitsavers.org/pdf/ibm/1410/A22-0526-3_1410_princOps.pdf

- A very useful table lookup instruction (pp 29-31)
- At least 56 ways to move data, depending upon the "d" character
  (op modifier) specified (pp 25-28)
- A scan that could stop at various terminators without moving data
  (pp 26-27)


JRJ

Re: Ultrix-11

[Jay Jaeger via cctalk]

On 8/21/2021 10:50 PM, Jay Jaeger via cctalk wrote:

On 8/17/2021 1:39 PM, Paul Koning via cctalk wrote:

I thought V7M and Ultrix were entirely diferent and unrelated things.

At least on the Pro, DEC released a betal version of the one (which I 
tried when it came out) and then canceled it and replaced it by a 
release of the other.  I forgot which came first, other than that the 
beta was really clunky.  As in, a "vi" that didn't do real screen 
updates...


paul

On Aug 17, 2021, at 2:16 PM, Al Kossow via cctech 
 wrote:


images up under 
http://bitsavers.org/bits/DEC/pdp11/floppyimages/rx50/V7M-11-V1.0_6_USR_RX50-QJ083-H3.zip 





They are indeed different.  V7m is based on 7th edition A UNIX, 
whereas Ultrix was based in BSD.


JRJ


OOOPS.  Belay that.  Further reading of the SPD seems to imply that 
Ultrix-11 was simply an evolutionary step from V7m to support more 
hardware - notably the 11.73.


JRJ

Re: Ultrix-11

[Jay Jaeger via cctalk]

On 8/17/2021 1:39 PM, Paul Koning via cctalk wrote:

I thought V7M and Ultrix were entirely diferent and unrelated things.

At least on the Pro, DEC released a betal version of the one (which I tried when it came 
out) and then canceled it and replaced it by a release of the other.  I forgot which came 
first, other than that the beta was really clunky.  As in, a "vi" that didn't 
do real screen updates...

paul


On Aug 17, 2021, at 2:16 PM, Al Kossow via cctech  wrote:

images up under 
http://bitsavers.org/bits/DEC/pdp11/floppyimages/rx50/V7M-11-V1.0_6_USR_RX50-QJ083-H3.zip




They are indeed different.  V7m is based on 7th edition A UNIX, 
whereas Ultrix was based in BSD.


JRJ

Re: DEC UNIBUS and use of cassette

[Jay Jaeger via cctalk]

On 8/21/2021 3:44 PM, Bill Degnan via cctalk wrote:

On Sat, Aug 21, 2021 at 1:49 PM Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:


 > From: Bill Degnan

 > Was there a UNIBUS storage system that used a cassette player as the
 > storage device .., rigged to send receive signals via a serial card
 > connection.

Yes and no. There is the TA11 Magnetic Tape Cassette System, which used the
TU60 Dual DECasette Transport (I need to create a page for that in the
CHWiki), but it uses a special controller card, the TA11 Magnetic Tape
Cassette controller:

   https://gunkies.org/wiki/TA11_Magnetic_Tape_Cassette_controller

There is a small cheap tape system which used a stock serial interface to
talk
to the computer, the TU58, but those used DECtpe-II cartridges, not
standard
casettes.

 Noel



Thanks Noel.  I suppose if it was done it was a hack/not official system.
Bill



There were third party cassette systems, typically using some kind of 
digital cassette format, that you could hook up with a terminal.  One 
was made by Sykes that I played with once upon a time:


http://www.bitsavers.org/pdf/sykes/brochures/Sykes_3000_Cassete_Brochure.pdf

But not UNIBUS - it was just a standard serial port thing, not tied to 
any particular computer system.

Re: IBM PC diagnostics disks

[Jay Jaeger via cctalk]

On 8/10/2021 10:30 PM, Jay Jaeger via cctech wrote:

On 7/29/2021 1:22 PM, Mark Huffstutter via cctech wrote:

Yes, I sadly, learned that important lesson years ago, after finding My
"Original" Original PC DOS diskette set pretty much destroyed, left in
The folders in storage for too long.

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Al 
Kossow via cctalk

Sent: Thursday, July 29, 2021 10:15 AM
To: cctalk@classiccmp.org
Subject: Re: IBM PC diagnostics disks

On 7/29/21 10:08 AM, Mark Huffstutter via cctalk wrote:

Hi Richard,
 I could use them if they are still available, I 
have the very nice binder manual for them, minus the disks!




Don't store diskettes in vinyl sleeves.
The plasticiser leaches out of the vinyl onto the surface of the 
diskettes.





Interesting. The IBM ones that I have had in the clear 5 x 8.5 vinyl 
sleeves were in their paper-like material sleeves inside the vinyl. They 
have been mostly just fine - just read them in this past week.


On the other hand maybe 10% or so of my 3B2 floppies that were similarly 
stored, but in a somewhat different form of vinyl had more sector 
errors.  Fortunately I copied some of them (the most critical ones) some 
time ago, and those were stored separately, so I expect those will be 
fine, but I haven't yet read them in.


JRJ


Correction:  Out of  49 AT floppies that were in their paper envelopes 
inside vinyl exactly ONE turned out to actually be bad - and it had been 
bad many years ago (1997) when I got them.  So, to date I have not 
experienced any issues with vinyl holders - so long as the floppy is in 
its paper sleeve, at least.


The problem I actually discovered this week that I was not reading the 
3B2 floppies on a 96 TPI drive (they are 512 byte sectors, 80 tracks, 
two sides, 9 sectors "quad" density.)  Once I figured that out, all but 
the one read just fine.   On the other hand, several copies I made on a 
PC floppy drive (I think) back when were mostly bad (either that, or I 
made them on the 3B2, but used HD media, perhaps).


One final note:  why do I re-image stuff using different techniques? 
Well, here is a case in point.  The images that (I believe) I had made 
of these floppies in 1997 - I think using dd on the 3b2 itself to files 
on the hard disk, and then transferred using zmodem to my PC - were all 
ONE TRACK SHORT.  Now, there is a pretty good chance that that last 
track on most of those floppies didn't have any real data - but one 
never knows.  I did verify that the first 79 tracks of those images, and 
those I made the past couple of days were the same.


Using my new greaseweazle I have verified that images I made of PC 
floppies of various sorts (160, 360, 720, 1.2M (including RT/PC), 
1.44M), RX50 were all just fine.  Only the 3B2 images were off.


JRJ

Re: Ultrix-11

[Jay Jaeger via cctalk]

> On Aug 15, 2021, at 10:08, Bill Gunshannon via cctalk  
> wrote:
> 
> On 8/15/21 12:45 AM, Warner Losh via cctalk wrote:
>>> On Sat, Aug 14, 2021 at 2:36 PM Warner Losh  wrote:
>>> 
>>> 
>>> On Sat, Aug 14, 2021, 2:08 PM Douglas Taylor 
>>> wrote:
>>> 
 On 8/14/2021 1:54 PM, Warner Losh wrote:
 
 
 
 On Sat, Aug 14, 2021 at 10:19 AM Douglas Taylor via cctalk <
 cctalk@classiccmp.org> wrote:
 
> I ran into a YouTube video, that it is 5 years old, titled "Ultrix-11
> 3.1 on an emulated PDP-11/73" and I found it very interesting.
> It shows installation of Ultrix-11 under SIMH.  The fellow steps through
> the installation process and appears to be quite knowable.
> I wanted to replicate it but couldn't locate the *.tap file used in the
> video that was an image of the bootable TK50 distribution.
> Bitsavers and tuhs.org have Ultrix-11 files, but not the bootable tape
> image.
> Anyone know where the tape image is located?
> 
 
 https://www.tuhs.org/Archive/Distributions/DEC/Ultrix-3.1/
 has ultrix-3.1-bootape.tar.gz and seems to be, at first blush, the boot
 tape (or its files) that you are looking for.
 
 Warner
 
 I took a look at that file and don't exactly know what to do with it.  It
 is not a bootable image of a tape, but rather the files that are on that
 tape.  Have to do some more digging.  Its a learning experience.
 
>>> 
>>> There are several prep programs that take the tape files and make a .tap
>>> file.
>>> 
>> Distributions/DEC/Ultrix-11/Fred-Ultrix3 in the tuhs archive has complete
>> instructions as well as a program to build the ultrix tapes
> 
> It took a day because I wanted to test it but I have a TK50 image that
> works with SIMH.  I did an install on an 11/73 with 3M of memory and
> two RD54's.  Worked fine.  It's been a while since I did any Ultrix-11
> on real or simulated hardware.
> 
> Have no idea how to get this tape to anyone.  It's just shy of 4M. Not
> sure if it could be emailed.  The SIMH ini file is trivially simple but
> I could provide that as well.
> 
> I have nowhere I could put it up for download.  I don't do things like
> Google Drive.  Maybe we need a GITHUB site or something for Ultrix stuff.
> 
> bill
> 

Would presumably be a lot smaller gzip’d?

Re: Ultrix-11

[Jay Jaeger via cctalk]

On 8/14/2021 11:53 PM, Warner Losh via cctalk wrote:

On Sat, Aug 14, 2021 at 3:26 PM jim stephens via cctalk <
cctalk@classiccmp.org> wrote:


  > I'm running Ultrix V2 on Simh quite happily today and have a couple



I did some quick searching and couldn't find a Ultrix-11 V2 image out in
the interwebs...

Anybody have better google fu than me that can hook me up?

Warner



FYI, I have Images of the RX50 floppies for V7M.  Al - let me know if 
you want them, and I will put them up for you to snag - 33 floppies 
worth.  I have *not* tried to install from them.


I also have *part* of version 1 of Ultrix 32 (Vax) - but only the first 
tape.  (Version 1.1 is up on Bitsavers).  If anyone wants it let me 
know.  It is in AWS format, but it is trivial to make an image suitable 
for use with SimH.


ID: CC0003
EXTERNAL-LABEL: BB-BG41A-BE
DATE: 2000/07/23
SOURCE:
SOURCE-DATE:
DENSITY: 1600 BPI
LABEL: NL
DESCRIPTION: ULTRIX-32 V1 BIN 16MT9 1/2
FILE-COUNT: 5
PC-FILE-COUNT: 2
[FILE]
NAME:
FORMAT: 512 Byte Blocks
ERRORS: NONE
NAME:
FORMAT: 10240 Byte Blocks
ERRORS: NONE
NAME:
FORMAT: 10240 Byte Blocks
ERRORS: NONE
NAME:
FORMAT: 10240 Byte Blocks
ERRORS: NONE
NAME:
FORMAT: 10240 Byte Blocks
ERRORS: NONE
[PC-FILE]
FILENAME: ultrix.aws
FORMAT: AWS Tape image of tape

JRJ

Re: IBM PC diagnostics disks

[Jay Jaeger via cctalk]

On 7/29/2021 1:22 PM, Mark Huffstutter via cctech wrote:

Yes, I sadly, learned that important lesson years ago, after finding My
"Original" Original PC DOS diskette set pretty much destroyed, left in
The folders in storage for too long.

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Al Kossow via 
cctalk
Sent: Thursday, July 29, 2021 10:15 AM
To: cctalk@classiccmp.org
Subject: Re: IBM PC diagnostics disks

On 7/29/21 10:08 AM, Mark Huffstutter via cctalk wrote:

Hi Richard,
 I could use them if they are still available, I have the 
very nice binder manual for them, minus the disks!



Don't store diskettes in vinyl sleeves.
The plasticiser leaches out of the vinyl onto the surface of the diskettes.




Interesting. The IBM ones that I have had in the clear 5 x 8.5 vinyl 
sleeves were in their paper-like material sleeves inside the vinyl. 
They have been mostly just fine - just read them in this past week.


On the other hand maybe 10% or so of my 3B2 floppies that were similarly 
stored, but in a somewhat different form of vinyl had more sector 
errors.  Fortunately I copied some of them (the most critical ones) some 
time ago, and those were stored separately, so I expect those will be 
fine, but I haven't yet read them in.


JRJ

Re: DQ11 prints needed

[Jay Jaeger via cctalk]

On 8/10/2021 6:30 PM, Noel Chiappa via cctalk wrote:

 > From: Jay Jaeger

 > ROTFL - especially given the earlier case, and since Noel knows about
 > you folks quite well..

The joke's actually on you:

   DQ11_RevL_Engineering_Drawings_Aug75.pdf 2021-08-09 14:05

I'd actually looked in http://bitsavers.org/pdf/dec/unibus earlier that
morning (before I sent my request), and by chance I still had that
browser window open. I suppose I could have done a screen-shot...


 > From: Al Kossow

 >> You aren't by any chance sitting any DM11-AA manuals, are you? :-)

 > probably. there are still quite a few drawings to go through

That was mostly a joke. I mean, there are no DM11-AA documents of any kind
online, so it would be interesting to get some (there are still a few
un-answered questions); but there's a good DM11 entry in "pdp11 peripherals
and interfacing handbook", 1972 edition, that enabled me to produce a decent
entry:

   https://gunkies.org/wiki/DM11_asynchronous_serial_line_interface

which is probably more than good enough - the interface is actually
a dog, I doubt any still exist.

   Noel



Yeah, I figured that out later.  ;)

BTW, I have only the sales brochure for the DM11, near as I can tell. 
114X-00871-1715/J .  If you want me to drag the box of sales lit from 
the garage, and scan it, me know - could do it next week.


JRJ

Re: DQ11 prints needed

[Jay Jaeger via cctalk]

ROTFL - especially given the earlier case, and since Noel knows about 
you folks quite well..


Typically I search the "mirror" on my drive first (which I update about 
once/year), then if I come up empty, search the bitsavers site.


BTW I hope to scan the Xenix manuals tomorrow.  If not, it will have to 
be next week.


JRJ

On 8/9/2021 2:05 PM, Al Kossow via cctalk wrote:

On 8/9/21 11:32 AM, Noel Chiappa via cctalk wrote:

Anyone have a set of DQ11 prints? The DQ11 MM is missing some important
info, which is apparently only on the prints.

   Noel

http://bitsavers.org/pdf/dec/unibus/DQ11_RevL_Engineering_Drawings_Aug75.pdf 

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

On 8/6/2021 12:21 PM, John Foust via cctalk wrote:

At 11:45 AM 8/6/2021, Jay Jaeger via cctalk wrote:

On 8/5/2021 2:57 PM, Len Shustek via cctalk wrote:

On Aug 5, 2021, at 8:39 AM, Jay Jaeger via cctech  wrote:
I know Paul well (we were contemporaries at U. WI).


Where did Paul work at UW-Madison?  I don't recall him.  I was on campus
from 1981 to 1985.



He was a student here in Madison before that timeframe, as was I.



- John



JRJ

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

On 8/5/2021 2:57 PM, Len Shustek via cctalk wrote:
 > On Aug 5, 2021, at 8:39 AM, Jay Jaeger via cctech 
 wrote:
 > I know Paul well (we were contemporaries at U. WI).  He does not do 
that very often.  He did not indicate any issue with a fire at the 
building that contains his collection when I last spoke with him.

 >
 > He does not actually read "blocks".  He reads the tape in an *analog* 
fashion, and then processes the results with software.  That is how he 
recovered the IBM 1410 system tapes and diagnostics, for example.

 >
 > To be honest, I doubt that this content would be such that he would 
be likely to volunteer.


Some years ago, inspired by Paul Pierce's earlier program in Java, I 
wrote similar software in C to decode the analog waveforms from tapes in 
a variety of formats: 7-track NRZI, 9-track NRZI, PE, and 6250 BPI GCR, 
and 6-track NRZI for Whirlwind.

https://github.com/LenShustek/readtape


Cool!

For completeness, here is a link to Paul's 7 track recovery software 
info (which is what I believe you are referring to - there is also an 
older version.)


http://piercefuller.com/collect/a7tv.html



As a one-time physics major, I *am* interested in the Schoonschip 
content. I've offered to James Liu to give it a go if he can't get 
someone like Chuck to read it in a more straightforward fashion.




There is also this one for 9 track drives:

https://github.com/jakubfi/ninetracklab

(There is an article out on the 'net that points to this project, 
referencing use of a logic analyzer to capture the data, but today I am 
having trouble finding it with my searching spells.)


JRJ

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

On 8/5/2021 9:28 AM, James Liu wrote:

On Wed, Aug 4, 2021 at 10:25 AM Jay Jaeger  wrote:




Thanks, Jay (and others) for offering your assistance.  I've asked
Chuck to have a look at the tape, and we'll see how it goes.



Great!


Given the name "IEBUPDTX" this tape was certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).


I can't say I know much about IBM systems, but apparently Strubbe, who
was doing the port and who I got the tape from, was no fan of
IEBUPDTE.  I wonder if IEBUPDTX was his attempt at an improvement.



Sounds likely.



- jim



JRJ

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

Yeah, well, the first part is the hard part - setting it all up and 
making recording.  The second part is more or less trivial, once the 
software was done.


One of the 1410 tapes had a persistent parity error - that one I was 
able to figure out from knowledge of the machine, instruction set, etc.


JRJ

On 8/5/2021 8:14 AM, Paul Koning wrote:

Perhaps the work could be split up: reading the track waveforms is the one step 
that requires special hardware (and the skill to handle the tape with minimal 
damage).  Given a collection of recovered waveforms, the data recovery can then 
be done by anyone.

paul


On Aug 5, 2021, at 8:39 AM, Jay Jaeger via cctech  wrote:

I know Paul well (we were contemporaries at U. WI).  He does not do that very 
often.  He did not indicate any issue with a fire at the building that contains 
his collection when I last spoke with him.

He does not actually read "blocks".  He reads the tape in an *analog* fashion, 
and then processes the results with software.  That is how he recovered the IBM 1410 
system tapes and diagnostics, for example.

To be honest, I doubt that this content would be such that he would be likely 
to volunteer.

JRJ

On 8/4/2021 3:11 PM, Van Snyder wrote:

Paul Pierce mailto:p...@teleport.com>> read some 7-track and 9-track 
tapes for me about twenty years ago. He was in Portland, OR at the time. His "lab" was on 
the east side of the Willamette river, so maybe it didn't get burned down.
I don't know whether he still has a setup to read tapes. His software would 
read blocks forward and backward, including the parity frames, and make 
corrections.
Van Snyder
On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:

James, I am located in Madison WI.  I would need to fire up my SCSI 9
Track drive (software on Linux) and test it as I have not used in a
couple of years, but I have done recovery of old tapes from this era
before, and have a primitive setup for "baking" tapes before trying to
read them.

Assuming my HP 9 track is still happy, I can produce AWS format tape
images, raw block files and extract individual files (translated into
ASCII if that is desirable).

I don't remember exactly the time period when tape coatings were such
that reading them without "baking" them is very risky - this might be
before that era - Al Kossow would probably know - so I'd likely "bake"
it first before trying to read it.

Given the name "IEBUPDTX" this tape was certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).

So, if you haven't found somebody to read this thing yet, feel free to
contact me.

JRJ

On 8/2/2021 10:11 AM, James Liu via cctech wrote:

Thanks for feedback and offers to assist.  I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.

For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600.  My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.  The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.

In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
S/360 and S/370.  It was sort of a curious technique, as far as I
gathered.  The idea was to first translate CDC COMPASS source to an
intermediate PL/I like language.  But then, instead of using the IBM
PL/I compiler, a bunch of macros were developed to implement the PL/I
like language in IBM assembly.  This conversion was never fully
completed for reasons unknown to me.

Later on, when Tini joined the University of Michigan (that's where
I'm located), he realized that Schoonschip needed to be updated.  But
the update was ... instead of CDC assembly he decided on m68k
assembly.  (At this time, in the early 1980's, C probably would have
been the natural language of choice.)  Moreover, he insisted on
developing his own toolchain (assembler, linker, etc).  This was
before my time at Michigan, but basically he ported Schoonschip to
just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
NeXT, and others I am not familiar with).  We have a pretty good
collection of m68k code
(
http://www-personal.umich.edu/~williams/Vsys/index.html

), but nothing
earlier.

Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion.  It may also have CDC
source, but that is less obvious until we can see the contents.  The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.

- jim

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

Some thoughts

On 8/4/2021 4:14 PM, Chuck Guzis via cctech wrote:

Whoever does it, I have a few suggestions when it comes to 40+ year old
tapes.

1) Bake the thing at 58C for a day or two.  It might just prevent you
from staring at a tape stuck to the head and a pile of brown dust at the
bottom of the drive.  (Before you start, make note of the brand and type
of tape; some are much worse than others).  If you're uncertain, check
back here and I'll tell you what I know.



I have found that generally baking more than 12 hours has not made much 
 additional difference.  I have been baking mine at 120F/50C.



2) If you're determined to use a SCSI drive, initially turn off
automatic retries (shoe-shining).   With sticky tape, you can do a lot
of damage to the tape.  Retries can come later when you're confident
about the condition of the tape.



Good idea.  Also, if one notices it is sticking or squealing, STOP and 
evaluate the situation before letting it go further.



3)  Should the tape turn out to be sticky, don't try to clean it--it
will only foul up the cleaning equipment (I'm assuming a tape cleaning
machine here).   Coat the tape with cyclomethicone.  At least it won't
stick to anything and you'll get a chance to do a good read.



Folks are also doing that with floppies, though so few of my floppies 
have stuck (and those that did didn't have anything that wasn't already 
archived earlier file by file rather than image) that I haven't had to 
resort to that.



4) If you have a choice of read speeds, use the lowest speed to start
with.  Make sure that you can deal with tape errors.

5) Forget using a streamer--they're just not suited to dealing with
fragile tape.


My HP 88780B is a streamer, but also has a feed side tension arm.  I 
generally read good tapes end to end without any stopping.  I have had 
no problems with breaking or stretching tape - in the rare case where a 
tape did stick badly to a head even after baking (1980's era tape or two 
- they were just awful), the drive stopped immediately when it "overfed" 
from the feed side which stopped the drive, just as a "standard" drive 
(two tension arms or vacuum columns) would.




If you're not equipped to deal with this, don't attempt it.  A tape
written 10 years ago, is not the same as one written 40-60 years ago.
The 1980s, in particular, were responsible for some truly wretched
stock.  I thank my lucky stars that cellulose acetate never made it as
computer tape base.  Curiously, tapes from the 1960s and 70s can be less
of a problem than those from the 80s and 90s.



That timeframe has been my experience as well (but I'd add that the 
early to mid 1970's tapes have generally been no problem at all), 
generally, but I don't think that is curious at all.  It was a result of 
the coatings used during those latter eras by some manufacturers. 
Before that, those coatings were not used.  Somewhere I kept a record of 
which brands and series I found to be problematic, but I seem to have 
lost track of it.



My .02 for what it's worth.
--Chuck




Also, before starting (after baking and cool-down) I unspool maybe 25 
feet of tape onto a clean surface to make sure it isn't sticking.  If it 
does, I let it sit for a few hours, and then bake it again.  Have not 
had to bake for additional time very often, and in those cases, it ended 
up not helping as much as one might like.


JRJ

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

I know Paul well (we were contemporaries at U. WI).  He does not do that 
very often.  He did not indicate any issue with a fire at the building 
that contains his collection when I last spoke with him.


He does not actually read "blocks".  He reads the tape in an *analog* 
fashion, and then processes the results with software.  That is how he 
recovered the IBM 1410 system tapes and diagnostics, for example.


To be honest, I doubt that this content would be such that he would be 
likely to volunteer.


JRJ

On 8/4/2021 3:11 PM, Van Snyder wrote:
Paul Pierce mailto:p...@teleport.com>> read some 
7-track and 9-track tapes for me about twenty years ago. He was in 
Portland, OR at the time. His "lab" was on the east side of the 
Willamette river, so maybe it didn't get burned down.


I don't know whether he still has a setup to read tapes. His software 
would read blocks forward and backward, including the parity frames, and 
make corrections.


Van Snyder

On Wed, 2021-08-04 at 09:25 -0500, Jay Jaeger via cctech wrote:

James, I am located in Madison WI.  I would need to fire up my SCSI 9
Track drive (software on Linux) and test it as I have not used in a
couple of years, but I have done recovery of old tapes from this era
before, and have a primitive setup for "baking" tapes before trying to
read them.

Assuming my HP 9 track is still happy, I can produce AWS format tape
images, raw block files and extract individual files (translated into
ASCII if that is desirable).

I don't remember exactly the time period when tape coatings were such
that reading them without "baking" them is very risky - this might be
before that era - Al Kossow would probably know - so I'd likely "bake"
it first before trying to read it.

Given the name "IEBUPDTX" this tape was certainly intended to be used on
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).

So, if you haven't found somebody to read this thing yet, feel free to
contact me.

JRJ

On 8/2/2021 10:11 AM, James Liu via cctech wrote:

Thanks for feedback and offers to assist.  I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.

For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600.  My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.  The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.

In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
S/360 and S/370.  It was sort of a curious technique, as far as I
gathered.  The idea was to first translate CDC COMPASS source to an
intermediate PL/I like language.  But then, instead of using the IBM
PL/I compiler, a bunch of macros were developed to implement the PL/I
like language in IBM assembly.  This conversion was never fully
completed for reasons unknown to me.

Later on, when Tini joined the University of Michigan (that's where
I'm located), he realized that Schoonschip needed to be updated.  But
the update was ... instead of CDC assembly he decided on m68k
assembly.  (At this time, in the early 1980's, C probably would have
been the natural language of choice.)  Moreover, he insisted on
developing his own toolchain (assembler, linker, etc).  This was
before my time at Michigan, but basically he ported Schoonschip to
just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
NeXT, and others I am not familiar with).  We have a pretty good
collection of m68k code
(
http://www-personal.umich.edu/~williams/Vsys/index.html
 
), but nothing
earlier.

Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion.  It may also have CDC
source, but that is less obvious until we can see the contents.  The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.

- jim

Re: Help reading a 9 track tape

[Jay Jaeger via cctalk]

James, I am located in Madison WI.  I would need to fire up my SCSI 9 
Track drive (software on Linux) and test it as I have not used in a 
couple of years, but I have done recovery of old tapes from this era 
before, and have a primitive setup for "baking" tapes before trying to 
read them.


Assuming my HP 9 track is still happy, I can produce AWS format tape 
images, raw block files and extract individual files (translated into 
ASCII if that is desirable).


I don't remember exactly the time period when tape coatings were such 
that reading them without "baking" them is very risky - this might be 
before that era - Al Kossow would probably know - so I'd likely "bake" 
it first before trying to read it.


Given the name "IEBUPDTX" this tape was certainly intended to be used on 
a 360 or 370, as you described below (IBM has a utility IEBUPDTE).


So, if you haven't found somebody to read this thing yet, feel free to 
contact me.


JRJ

On 8/2/2021 10:11 AM, James Liu via cctech wrote:

Thanks for feedback and offers to assist.  I received the tape from
one of the maintainers of Schoonship at CERN, and it was probably made
around 1978 at SLAC.

For some background, Tini Veltman developed Schoonship in the 1960's
at CERN on the CDC 6600.  My understanding is that he more or less
insisted on coding in assembly since he thought FORTRAN or other high
level languages would just get in the way and slow things down.  The
code was maintained by Veltman and Strubbe well into the 1970's, but
its future was held back by being so closely tied to CDC hardware.

In the mid 1970's, Strubbe began a conversion of Schoonschip to IBM
S/360 and S/370.  It was sort of a curious technique, as far as I
gathered.  The idea was to first translate CDC COMPASS source to an
intermediate PL/I like language.  But then, instead of using the IBM
PL/I compiler, a bunch of macros were developed to implement the PL/I
like language in IBM assembly.  This conversion was never fully
completed for reasons unknown to me.

Later on, when Tini joined the University of Michigan (that's where
I'm located), he realized that Schoonschip needed to be updated.  But
the update was ... instead of CDC assembly he decided on m68k
assembly.  (At this time, in the early 1980's, C probably would have
been the natural language of choice.)  Moreover, he insisted on
developing his own toolchain (assembler, linker, etc).  This was
before my time at Michigan, but basically he ported Schoonschip to
just about all the m68k machines of that era (Sun, Atari, Amiga, Mac,
NeXT, and others I am not familiar with).  We have a pretty good
collection of m68k code
(http://www-personal.umich.edu/~williams/Vsys/index.html), but nothing
earlier.

Getting back to the tape, I'm pretty sure it has Strubbe's PL/I like
code as it is an archive of the PL/I conversion.  It may also have CDC
source, but that is less obvious until we can see the contents.  The
CDC source is historically the most relevant, and I am hoping it
exists on the tape.

- jim

Re: Sourcing Capacitors for my H7140 PSU

[Jay Jaeger via cctalk]

On 7/23/2021 11:48 AM, Rob Jarratt via cctalk wrote:


I gave up trying to repair this PSU myself and I have got someone to do it
professionally. It seems they have it working well but think that two
capacitors should still be replaced. I think these are the two big "Coke
Can" sized filter capacitors. The trouble is they seem to be unable to find
any. The spec for them is 4500uf 200v DxH 76mm x 145mm Qty. 2.



Some particular reason you want to replace them?  Perhaps instead 
measure their ESR and if that measures OK, maybe just reform them (I do 
realize that at 200v the reforming would be harder than for most.)


I had a capacitor fail in my H7140 many years go, but it was not one of 
the larger caps.  I generally turn on my 11/24 every few months to do 
something or other, so it tends to stay pretty happy.


My experience, aside from the bad capacitors from 1999-2003 swelling up 
and failing, and maybe two tantalums total (one recent one in a 3270 PC 
that decided to short and release its "magic smoke") I haven't had very 
many electrolytics fail - fewer than five - that actually needed 
replacing - one of which was a smaller cap in my H7140.


JRJ

Re: Items Wanted

[Jay Jaeger via cctalk]

On 7/20/2021 7:34 PM, Josh Dersch wrote:
On Tue, Jul 20, 2021 at 4:06 PM Jay Jaeger via cctalk 
mailto:cctalk@classiccmp.org>> wrote:


On 7/20/2021 6:59 AM, Eric Moore wrote:
 >
 >
 >      >> 11) ESDI disk emulator
 >      >
 >      > I am not aware of any such beasties in the wild.  MFM,
yes, but I
 >     haven't seen ESDI.   I would love for such a thing to exist,
 >     thinking of my Apollo, 3B2 and IBM RT/PC workstations.
 >
 >     I’d also love to have one of these, preferably using SD or CF
 >     cards.  The Webster WQESD/04 card is a fantastic card, it’s only
 >     downfall is that it works with ESDI drives, rather than SCSI, and
 >     they’re big and loud. :-)
 >
 >     Zane
 >
 >
 > http://www.datexdsm.com/ESDI.php
<http://www.datexdsm.com/ESDI.php> <http://www.datexdsm.com/ESDI.php
<http://www.datexdsm.com/ESDI.php>> is
 > what I was thinking of. There are a couple other commercial
models out
 > there on offer, no one seems to have one though in the discord or
 > apparently here :)
 >
 > -Eric
 >
 >

I fear these, as well as those shown on one or two other websites, are
vapor-ware.  The MFM emulators all seem out of stock, the ESDI emulator
(DWX750) "documentation" is not even a page - just a "blurb".


I had a similar experience with a set of emulators made by Arraid -- LCM 
inquired about one of their SMD emulators 
(https://www.arraid.com/data-storage-products/product/aem-1.html 
<https://www.arraid.com/data-storage-products/product/aem-1.html>) and 
the response we got was "we can no longer source the parts to 
manufacture these, we have a few remaining in stock that we will sell 
for $10,000 a piece."  We did not purchase one.


I suspect that even if you could find someone to sell you one of these 
emulators, they would be extremely expensive.  I have never seen one for 
sale on the used market.  If you find one, consider yourself lucky.  If 
anyone *DOES* have one of these SMD emulators and wants to find a new 
home for it, do drop me a line.


- Josh


JRJ



For SMD, this patent may have been a bit of a stumbling block at one 
time, though if it was approved, it would have expired long ago.


https://patents.google.com/patent/WO1990001193A1/en

JRJ