Re: LISP microcode for an 11/730? Was Re: Modifying microcode

[Steven M Jones via cctalk]

On 06/15/2018 08:28, Steven M Jones via cctalk wrote:
 

> I wasn't able to find a reference to back it up, but ...


Sorry for the delay - that was stuck in my Outbox over a two week 
business trip...

LISP microcode for an 11/730? Was Re: Modifying microcode

[Steven M Jones via cctalk]

On 06/02/2018 11:08, Robert Armstrong via cctalk wrote:


   I've heard a persistent rumor over the years that the WPS/8 and PDP-8 
software group at DEC had modified the 730's microcode to support a PDP-8 
emulation [...]


I wasn't able to find a reference to back it up, but if we're sharing 
faintly remembered rumors -- I recall hearing that some grad students 
had developed alternate microcode for the 11/730 to re-purpose it as a 
LISP machine.


I use the lowercase "M" on purpose, I don't recall that it emulated the 
various 36-bit machines known as LISP Machines specifically. Just that 
it was a native LISP execution environment of some kind.


That's all I've got. Not even an institution, though I have a very 
tenuous notion that UMass Amherst might have been mentioned...


--S.

RE: RC25 (was Re: Modifying microcode)

[Robert Armstrong via cctalk]

>Eric Smith  wrote:
>There's SDI protocol documentation?

  You know, after I wrote that I realized that I was wrong about SDI.  I've 
seen some electrical specs, but not the protocol.

Bob

Re: RC25 (was Re: Modifying microcode)

[Eric Smith via cctalk]

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

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

There's SDI protocol documentation?

Re: RC25 (was Re: Modifying microcode)

[Bill Gunshannon via cctalk]

On 06/05/2018 02:53 PM, Robert Armstrong via cctalk wrote:
>I too have heard that RC25s and PDP-11s were used in nuclear subs for some 
> kind of sonar thingie.  I've no idea how that worked, except that maybe DEC 
> gave all the good drives to the Navy and the rest of us got the crappy ones.
I used mine for more than 10 years and have no idea how long
or much the previous owners used it.  Never a problem.  I kept
the KLESI module to use with tape drives after I gave the disk
away.  Now that was a truly weird system. same controller but
the cable went one way for a disk and the other way for a tape.

>
>They worked as long as you didn't spin them down or try to change the 
> removable pack.  The removable part would crash at the drop of a hat and, of 
> course given the clever shared spindle design, if the removable part wouldn't 
> spin up then neither would the fixed part.
>
>I have (I think) three drives, or maybe just two.  Two are internal drives 
> for the 725 and one is in the table top enclosure.  None work.  If anybody 
> has any tips for fixing them, or even just a kludge to spin up the Winchester 
> part without needing the removable part to work too, I'm all ears.

Mine was the tabletop model.
>
>> Ethan Dicks  wrote:
>> I often wonder how hard it would be to develop some other storage
>> device for the KELSI
>AFAIK the LESI ("Low End Storage Interconnect") protocol is not documented 
> anywhere, unlike SDI or MASSBUS which are.  If it is, I've never found it.  I 
> have several UNIBUS KLESI boards and I've often thought the same thing, but 
> I'm not really interested in trying to reverse engineer the protocol w/o 
> documentation.
>

bill

RE: RC25 (was Re: Modifying microcode)

[Robert Armstrong via cctalk]

  I too have heard that RC25s and PDP-11s were used in nuclear subs for some 
kind of sonar thingie.  I've no idea how that worked, except that maybe DEC 
gave all the good drives to the Navy and the rest of us got the crappy ones.

  They worked as long as you didn't spin them down or try to change the 
removable pack.  The removable part would crash at the drop of a hat and, of 
course given the clever shared spindle design, if the removable part wouldn't 
spin up then neither would the fixed part.  

  I have (I think) three drives, or maybe just two.  Two are internal drives 
for the 725 and one is in the table top enclosure.  None work.  If anybody has 
any tips for fixing them, or even just a kludge to spin up the Winchester part 
without needing the removable part to work too, I'm all ears.

> Ethan Dicks  wrote:
>I often wonder how hard it would be to develop some other storage
>device for the KELSI 

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

Bob

Re: RC25 (was Re: Modifying microcode)

[Ethan Dicks via cctalk]

On Tue, Jun 5, 2018 at 2:53 PM, Robert Armstrong  wrote:
>   I too have heard that RC25s and PDP-11s were used in nuclear subs for some 
> kind of sonar thingie.  I've no idea how that worked, except that maybe DEC 
> gave all the good drives to the Navy and the rest of us got the crappy ones.

Hi, Bob,

Perhaps.

>   They worked as long as you didn't spin them down or try to change the 
> removable pack.

Ah... that may be part of it.  I never did.  I loaded one removable
pack and never swapped it out.

> The removable part would crash at the drop of a hat

:-(

> and, of course given the clever shared spindle design, if the removable part 
> wouldn't spin up then neither would the fixed part.

Right.

I have a different 11/725 now (long story but I screwed up and the old
one went away at a friend's company when they were purchased and shut
down)... I've had that replacement 11/725 for 10 years but it didn't
come with a removable pack so I mothballed it out at my farm.  I have
only gotten a couple of removable packs in the past year and have not
been able to spend time fiddling with it, but it's going to be a full
cleaning and overhaul (dust, fans, PSU test, TU58 roller...)

>   I have (I think) three drives, or maybe just two.  Two are internal drives 
> for the 725 and one is in the table top enclosure.  None work.

No fun.

> If anybody has any tips for fixing them, or even just a kludge to spin up the 
> Winchester part without needing the removable part to work too, I'm all ears.

I didn't want to bung up my only drive, but if I had 2, what about
this?  Put a foam or rubber wedge between the head arms of the
removable pack (to keep them from thwacking together) and defeat any
sort of interlock or removable cardridge sensor (I think there's a mag
sensor at one corner?)  The idea is to make the drive think there's a
pack loaded.  It might take doing something with a real pack housing
and removing the platter in case the lower mass screws up the spin
rate.

Of course, if the internal drive electronics lose their mind because
there's no signal coming from the removable pack heads, then it will
likely go into Fault and not work.  This is all just speculation on my
part but I can envision ways that it doesn't keep the drive
electronics happy.

>   AFAIK the LESI ("Low End Storage Interconnect") protocol is not documented 
> anywhere, unlike SDI or MASSBUS which are.  If it is, I've never found it.

Nor have I.

> I have several UNIBUS KLESI boards and I've often thought the same thing, but 
> I'm not really interested in trying to reverse engineer the protocol w/o 
> documentation.

Same.  That's what really slows me down - not wanting to start without
a single idea of how it works.

And then I think of how much work it would be to convert one of my
COMBOARDs from a 3rd-party comms controller into a 3rd-party disk
controller (I have full schematics and specifications and source for
all the COMBOARDs so that's not starting from zero) but between
designing and writing new firmware and writing drivers for every
possible OS (RT-11 and VMS at the absolute front of the list), before
I even get started, I just find something less insane to do.

-ethan

Re: RC25 (was Re: Modifying microcode)

[Bill Gunshannon via cctalk]

On 06/05/2018 01:08 PM, Ethan Dicks via cctalk wrote:
> On Mon, Jun 4, 2018 at 5:13 PM, Paul Koning via cctalk
>  wrote:
>>> On Jun 4, 2018, at 1:17 PM, Robert Armstrong via cctalk 
>>>  wrote:
>>>
>>> ... FWIW, I have a 725 complete and working.  Well, except for the RC25, 
>>> which never worked even when they were new.
> I had an 11/725 in the 80s and 90s and never had a problem with the
> RC25 but they are legendarily terrible.
>
>

I had one on a PDP-11 and never had a problem right up
until I gave it away.

bill

Re: RC25 (was Re: Modifying microcode)

[Ethan Dicks via cctalk]

On Tue, Jun 5, 2018 at 1:19 PM, Noel Chiappa via cctalk
 wrote:
> > From: Ethan Dicks
>
> > Mostly, what I need is affordable ($250 or less) Unibus storage with
> > modern media
>
> There's this:
>
>   http://www.retrocmp.com/projects/unibone

I would totally buy this.  I have some NOS DS8641s from my COMBOARD
days as well as crates of old boards I could do pulls from.

> Not quite there yet, but getting there.

I am more than a little intrigued.  I have a number of Unibus machines
from an 11/20 up to 11/70 and VAXen from 11/725 to 11/750... I would
likely buy more than one Unibone especially if available as a bare
board.

-ethan

Re: RC25 (was Re: Modifying microcode)

[Noel Chiappa via cctalk]

> From: Ethan Dicks

> Mostly, what I need is affordable ($250 or less) Unibus storage with
> modern media 

There's this:

  http://www.retrocmp.com/projects/unibone

Not quite there yet, but getting there.

Noel

RC25 (was Re: Modifying microcode)

[Ethan Dicks via cctalk]

On Mon, Jun 4, 2018 at 5:13 PM, Paul Koning via cctalk
 wrote:
>> On Jun 4, 2018, at 1:17 PM, Robert Armstrong via cctalk 
>>  wrote:
>>
>> ... FWIW, I have a 725 complete and working.  Well, except for the RC25, 
>> which never worked even when they were new.

I had an 11/725 in the 80s and 90s and never had a problem with the
RC25 but they are legendarily terrible.

> Hm.  I remember some RC25s on RSTS, and they seemed to be ok.  The fact that 
> they had two drives on one motor made it strange, especially if the fixed 
> platter was your system device.  We had to teach the OS how to deal with SY: 
> going away temporarily.

Oof, yeah.  When I used my 725, I didn't spin the RC25 up and down
except when booting and shutting down.  I also had devices like RL02s
for removable storage.

I often wonder how hard it would be to develop some other storage
device for the KELSI but then other projects push to the top of the
stack and I move on.

Mostly, what I need is affordable ($250 or less) Unibus storage with
modern media (Flash or IDE adapter or whatever).  I don't really care
what form it takes but Unibus SCSI cards are quite pricey and making a
new controller is even less affordable (I used to make and support
DMA-enabled Unibus communication controllers for a living so I have a
pretty good idea of the amount of effort required).

-ethan

Re: Modifying microcode

[Lars Brinkhoff via cctalk]

Rob Doyle wrote:

> Camiel Vanderhoeven wrote:
>> The microcode for the MicroVAX 2 (for which the MICRO2 assembler was
>> used) and the CVAX (which is the CPU in your 3800) is implemented as
>> a mask ROM on the CPU chip itself. No way to change it, and no way
>> you can use MICRO2 to assemble the microcode for the CVAX.
>
> Years ago I was playing the the microcode of the DEC Minnow (PDP-10)
> which was written in MICRO2 - but I don't think I ever found that
> assembler.
>
> Do MICRO2 executables exists?

In ITS, there are two versions of the microcode assembler.  The older
one was used for the KL10, and the newer one for KS10.  I suppose the
KL10 version came from DEC and was originally written in MACRO10, but
then rewritten for MIDAS by ITS hackers.  Then it was extended for the
KS10.

According to the comments above, MICRO2 would have been used for both
PDP-10 and VAX microcode.  So I wonder if it was written in MACRO10 or
MACRO32?

Re: Modifying microcode

[Paul Koning via cctalk]

> On Jun 4, 2018, at 1:17 PM, Robert Armstrong via cctalk 
>  wrote:
> 
> ... FWIW, I have a 725 complete and working.  Well, except for the RC25, 
> which never worked even when they were new. 

Hm.  I remember some RC25s on RSTS, and they seemed to be ok.  The fact that 
they had two drives on one motor made it strange, especially if the fixed 
platter was your system device.  We had to teach the OS how to deal with SY: 
going away temporarily.

It did make for nice compact systems, which was important when we got an order 
for a pile of RSTS systems that would be installed on board submarines.  Or so 
we were told.

paul

RE: Modifying microcode

[Robert Armstrong via cctalk]

> Ethan Dicks  wrote:
>We used to purchase 11/725s for parts to keep our 11/730 running.

  I remember when the 725 first came out.  I was working for DEC at the time, 
and up until then the only VAXes I'd ever seen were 780s.  Somebody rolled this 
little end table sized thing into the lab and said "Here - this is a VAX."  I 
was flabbergasted - a VAX?!?  In a box that small???  No way!!

  I kept it by my desk until the MicroVAX-II came out.  By then I was getting 
pretty tired of it.  Still, the 725 and 730 are the smallest UNIBUS VAXes ever 
made, which ought to earn them some kind of recognition.

  FWIW, I have a 725 complete and working.  Well, except for the RC25, which 
never worked even when they were new.  It needs the skins for the chassis, 
though - the previous owner used it as a test system.  He never put the cover 
back on it and eventually lost that part.  If anybody has a 725 chassis and 
would be willing to part with some of the sheet metal, let me know!

Bob

Re: Modifying microcode

[Rob Doyle via cctalk]

On 5/30/2018 7:34 AM, Camiel Vanderhoeven via cctalk wrote:

The microcode for the MicroVAX 2 (for which the MICRO2 assembler was
used) and the CVAX (which is the CPU in your 3800) is implemented as
a mask ROM on the CPU chip itself. No way to change it, and no way
you can use MICRO2 to assemble the microcode for the CVAX.


Years ago I was playing the the microcode of the DEC Minnow (PDP-10)
which was written in MICRO2 - but I don't think I ever found that assembler.

Do MICRO2 executables exists?

Rob.

Re: Modifying microcode

[Mark J. Blair via cctalk]

> On Jun 3, 2018, at 7:37 PM, Ethan Dicks via cctalk  
> wrote:
> 
> We used to purchase 11/725s for parts to keep our 11/730 running.
> Much cheaper because "nobody" wanted an 11/725 in the early 90s (I
> still have one.  I wish I could afford a Unibus controller to replace
> the KLESI/U and RC25).

Back around the early 1990s, a friend of mine had an 11/725 and an 11/730 in 
his apartment. One of then had a bad PROM chip, so he could only run one at a 
time.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Modifying microcode

[Ethan Dicks via cctalk]

On Fri, Jun 1, 2018 at 2:46 PM, Antonio Carlini via cctalk
 wrote:
> the 78032 chip. The VAX-11/730 was chosen because it was "an entirely 'soft'
> machine".
>
> (The VAX-11/725 is essentially the same hardware but in different
> packaging).

We used to purchase 11/725s for parts to keep our 11/730 running.
Much cheaper because "nobody" wanted an 11/725 in the early 90s (I
still have one.  I wish I could afford a Unibus controller to replace
the KLESI/U and RC25).

-ethan

Re: Modifying microcode

[Paul Koning via cctalk]

> On Jun 2, 2018, at 2:08 PM, Robert Armstrong via cctalk 
>  wrote:
> 
>> Tony Duell  wrote:
>> Incidentally, did DEC ever release any details (flowcharts, source listings,
>> etc) of the 11/730 microcode? And what about the control PROMs for the
>> memory system. The technical manual implies there was a listing of those,
>> but I've never found it.
> 
>  I thought that DEC had a whole microcode development suite for the 730 to 
> support customer written extensions to the microcode, but I've never seen it 
> nor any documentation for it.  If such a thing did exist then I seriously 
> doubt anybody ever bought it.  The 730 was never a super popular machine to 
> start with, and the market for a customized version would have been very 
> small.

Considering that the 730 was a 2901 based machine, and 2901s were widely used, 
presumably the tools were not a problem around DEC.  Perhaps they tweaked the 
UDA50 microcode toolchain?

>  I've heard a persistent rumor over the years that the WPS/8 and PDP-8 
> software group at DEC had modified the 730's microcode to support a PDP-8 
> emulation of some kind, and that they used that internally for development 
> 'cause it was faster than a real -8.  I've not idea if that's true, but it 
> would be cool if they did.  And no, I'm not talking about PDP-11 
> compatibility mode - even the stock 730 had that (all the 7xx VAXes did, I 
> believe).

The PDP-8 emulation used for internal PDP-8 software development was on an 
11/60 running RSTS/E, I remember that system in the lab in DEC Merrimack 
(MKO1-1).  I would imagine it could have been done on a 730 also but chances 
are the 11/60 was a whole lot faster.

paul

Re: Modifying microcode

[Al Kossow via cctalk]

On 6/3/18 11:17 AM, Antonio Carlini via cctalk wrote:

> From reading the DTJ article it seems as though there was no set of neatly 
> pre-packaged ucode development tools for the
> 730.


and the 730 started out in life as a PDP-10 (Minnow)

RE: Modifying microcode

[Robert Armstrong via cctalk]

On 02/06/18 15:17, allison via cctech wrote:
>
> It was my understanding from using the 730 that there was limited
> (really limited) microcode
> enough to load the WCS as the tu58 was a serial device (standard tu58)
> and the 730 had to
> unpack and stuff the WCS.� You need little to do that but far from even
> PDP11 instruction set.
> The Microcode was loaded was the "what made it a VAX stuff".
>
> Allison

  What you're describing is the 750, not the 730.  Unlike the 78x and 730/725, 
the 750 had no console front end processor.  The microcode did it all, 
including loading any additional microcode from TU58.  

  As others have said, the 730 had an 8085 CFE processor that loaded all the 
VAX microcode.  The main CPU had no ROMs and could do absolutely nothing until 
the CFE loaded the microcode.

  FWIW, the CFE in the 730 had a 2K ROM and (I think) about 8K of RAM.  The 
first thing the CFE did after power on, before it did anything with the VAX 
CPU, was to load the rest of the 8085 code from the TU58 into that CFE RAM.  
The 2K of ROM had just enough code to type characters on the console and to 
talk to the TU58, and even the CFE couldn't really do much until the rest of 
its code was loaded from the TU58.

  Once that was done, the CFE command line interpreter executed a script (one 
of four possible ones, depending on the HW configuration) and that script had 
the CFE commands to load the VAX microcode.

  FWIW, when you first turn on the 730 it types "CONV11" on the console, 
followed by the rest of the startup dialog.  If you pay attention, there's a 
tiny pause between the "CON" and the "V11".  That's because the first part was 
typed by the 8085 ROM just to let you know that the CFE was alive, and the 
version number was actually typed by the RAM part of the CFE code after it was 
loaded from the tape.

Bob

Re: Modifying microcode

[Antonio Carlini via cctalk]

On 02/06/18 19:08, Robert Armstrong via cctalk wrote:

Tony Duell  wrote:
Incidentally, did DEC ever release any details (flowcharts, source listings,
etc) of the 11/730 microcode? And what about the control PROMs for the
memory system. The technical manual implies there was a listing of those,
but I've never found it.

   I thought that DEC had a whole microcode development suite for the 730 to 
support customer written extensions to the microcode, but I've never seen it 
nor any documentation for it.  If such a thing did exist then I seriously doubt 
anybody ever bought it.  The 730 was never a super popular machine to start 
with, and the market for a customized version would have been very small.

   I've heard a persistent rumor over the years that the WPS/8 and PDP-8 
software group at DEC had modified the 730's microcode to support a PDP-8 
emulation of some kind, and that they used that internally for development 
'cause it was faster than a real -8.  I've not idea if that's true, but it 
would be cool if they did.  And no, I'm not talking about PDP-11 compatibility 
mode - even the stock 730 had that (all the 7xx VAXes did, I believe).

   Certainly if you had the right tools and the right knowledge, it would have 
been easy to modify and replace the 730's microcode with something of your own. 
 Just copy the binary images to the console tape and reboot.


There was "VAX-11/780 Microprogramming Tools User's Guide" but I don't 
know if there was ever one for the VAX-11/730.


From reading the DTJ article it seems as though there was no set of 
neatly pre-packaged ucode development tools for the 730.


Antonio


--

Antonio Carlini
arcarl...@iee.org

Re: Modifying microcode

[John Forecast via cctalk]

> On Jun 2, 2018, at 2:08 PM, Robert Armstrong via cctalk 
>  wrote:
> 
>> Tony Duell  wrote:
>> Incidentally, did DEC ever release any details (flowcharts, source listings,
>> etc) of the 11/730 microcode? And what about the control PROMs for the
>> memory system. The technical manual implies there was a listing of those,
>> but I've never found it.
> 
>  I thought that DEC had a whole microcode development suite for the 730 to 
> support customer written extensions to the microcode, but I've never seen it 
> nor any documentation for it.  If such a thing did exist then I seriously 
> doubt anybody ever bought it.  The 730 was never a super popular machine to 
> start with, and the market for a customized version would have been very 
> small.
> 
>  I've heard a persistent rumor over the years that the WPS/8 and PDP-8 
> software group at DEC had modified the 730's microcode to support a PDP-8 
> emulation of some kind, and that they used that internally for development 
> 'cause it was faster than a real -8.  I've not idea if that's true, but it 
> would be cool if they did.  And no, I'm not talking about PDP-11 
> compatibility mode - even the stock 730 had that (all the 7xx VAXes did, I 
> believe).
> 
That would be Ritchie Lary’s microcode implementation for the PDP-11/60 
with WCS.

  John.

>  Certainly if you had the right tools and the right knowledge, it would have 
> been easy to modify and replace the 730's microcode with something of your 
> own.  Just copy the binary images to the console tape and reboot.
> 
> Bob
> 

Re: Modifying microcode

[Jon Elson via cctalk]

On 06/02/2018 03:33 PM, Antonio Carlini via cctech wrote:

On 02/06/18 15:17, allison via cctech wrote:


It was my understanding from using the 730 that there was 
limited

(really limited) microcode
enough to load the WCS as the tu58 was a serial device 
(standard tu58)

and the 730 had to
unpack and stuff the WCS.  You need little to do that but 
far from even

PDP11 instruction set.
The Microcode was loaded was the "what made it a VAX stuff".

Allison



Well something has to load the ucode but whether that's a 
fixed part of ucode itself or whether
it's a hardware state machine (or something) that feeds 
the loaded ucode into the appropriate
RAM, I don't know. I've never delved that deeply into the 
relevant FMP sets.


Actually, the 8085 could load a small bootloader from 8085 
ROM to the 730 microcode.  That would be the most logical 
way to do it, assuming the microcode bootloader was really 
small.


The IBM 360/25 had all microcode in the top 16K of main core 
memory, and the emulator of your choice could be loaded from 
binary punch cards.  The microcode bootloader was 
hand-loaded through the front panel switches, and occupied 
16 16-bit words.


Jon

Re: Modifying microcode

[Tony Duell via cctalk]

> It was my understanding from using the 730 that there was limited
> (really limited) microcode
> enough to load the WCS as the tu58 was a serial device (standard tu58)
> and the 730 had to
> unpack and stuff the WCS.  You need little to do that but far from even
> PDP11 instruction set.
> The Microcode was loaded was the "what made it a VAX stuff".

I don't think so.

There's an 8085 'console processor' on one of the CPU boards (I am
not talking about the 8085 in the TU58, which is also there). This
processor runs a program from its ROM that talks to the console
port and also to the TU58. It loads the microcode from the TU58
and writes it to the VAX control store RAM, and then starts the
VAX runnng.

I can find no microcode ROMs in the printset, technical manual or
on the PCBs themselves.

-tony

Re: Modifying microcode

[Bill Gunshannon via cctalk]

On 06/02/2018 02:45 PM, Warner Losh via cctalk wrote:

On Sat, Jun 2, 2018 at 12:43 PM, Tony Duell via cctalk <
cctalk@classiccmp.org> wrote:



On Sat, Jun 2, 2018 at 7:37 PM, Alan Frisbie 

wrote:


Tony Duell  wrote:



until the 8085 CFE loaded the microcode.



Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
running at the moment. The hardware is fine, I've rebuilt the drive
rollers,
but as yet don't have a readable tape (not even blank, to write the
microcode onto).



I'm pretty sure that I have a complete set of 11/730 TU58 tapes in
my storage unit.   I might even have some brand new tapes.   If I
can find them, I would be happy to send them to you.   They have
been sitting in storage for probably 20 years, so there are no
guarantee that they are readable.



Thanks... I will certanly give them a go. I am pretty sure the problem
I am having is the tape, I get a low (and varying) amplitude signal at
the output of the read amplifier, it varies with different tapes, and it's
much the same both on the drive in the 11/730 and a standalone
TU58 I have.




Given the vagaries of tape, I'm surprised nobody has made a simple TU58
emulator that can feed the proper microcode bits to the 11/730...

Then again, maybe there's no market for that.



There are TU58 emulators:

https://www.torok.info/computing/pdp11/tu58/

https://www.ak6dn.com/PDP-11/TU58/tu58em/

retrocmp.com/tools/tu58fs

bill

Re: Modifying microcode

[Tony Duell via cctalk]

On Sat, Jun 2, 2018 at 7:45 PM, Warner Losh  wrote:

> Given the vagaries of tape, I'm surprised nobody has made a simple TU58
> emulator that can feed the proper microcode bits to the 11/730...
>
> Then again, maybe there's no market for that.

Oh, I think there are. I belive you can use something like an RPi, read
the files off an SD card. It's only an asynchronous serial interface between
the TU58 and the VAX after all.

But I don't want to have more components in the emulator than in the
rest of the CPU

-tony

Re: Modifying microcode

[Warner Losh via cctalk]

On Sat, Jun 2, 2018 at 12:43 PM, Tony Duell via cctalk <
cctalk@classiccmp.org> wrote:

> On Sat, Jun 2, 2018 at 7:37 PM, Alan Frisbie 
> wrote:
> > Tony Duell  wrote:
> >
> >> > until the 8085 CFE loaded the microcode.
> >>
> >> Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
> >> running at the moment. The hardware is fine, I've rebuilt the drive
> >> rollers,
> >> but as yet don't have a readable tape (not even blank, to write the
> >> microcode onto).
> >
> > I'm pretty sure that I have a complete set of 11/730 TU58 tapes in
> > my storage unit.   I might even have some brand new tapes.   If I
> > can find them, I would be happy to send them to you.   They have
> > been sitting in storage for probably 20 years, so there are no
> > guarantee that they are readable.
>
> Thanks... I will certanly give them a go. I am pretty sure the problem
> I am having is the tape, I get a low (and varying) amplitude signal at
> the output of the read amplifier, it varies with different tapes, and it's
> much the same both on the drive in the 11/730 and a standalone
> TU58 I have.
>

Given the vagaries of tape, I'm surprised nobody has made a simple TU58
emulator that can feed the proper microcode bits to the 11/730...

Then again, maybe there's no market for that.

Warner

Re: Modifying microcode

[Bill Gunshannon via cctalk]

On 06/02/2018 02:37 PM, Alan Frisbie via cctalk wrote:
> Tony Duell  wrote:
>
> > > until the 8085 CFE loaded the microcode.
> >
> > Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
> > running at the moment. The hardware is fine, I've rebuilt the drive 
> rollers,
> > but as yet don't have a readable tape (not even blank, to write the
> > microcode onto).
>
> I'm pretty sure that I have a complete set of 11/730 TU58 tapes in
> my storage unit.   I might even have some brand new tapes.   If I
> can find them, I would be happy to send them to you.   They have
> been sitting in storage for probably 20 years, so there are no
> guarantee that they are readable.
>
> I'm cleaning out the storage unit right now, in preparation for
> moving, so I'll keep an eye out for them.
>

Ages ago I had a set as well (might still be here somewhere, but I doubt 
it).
I offered it various places and got no takers.  In most cases the 
conversations
merely morphed into discussions about what crap the physical tapes and
drives were.

bill

Re: Modifying microcode

[Tony Duell via cctalk]

On Sat, Jun 2, 2018 at 7:37 PM, Alan Frisbie  wrote:
> Tony Duell  wrote:
>
>> > until the 8085 CFE loaded the microcode.
>>
>> Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
>> running at the moment. The hardware is fine, I've rebuilt the drive
>> rollers,
>> but as yet don't have a readable tape (not even blank, to write the
>> microcode onto).
>
> I'm pretty sure that I have a complete set of 11/730 TU58 tapes in
> my storage unit.   I might even have some brand new tapes.   If I
> can find them, I would be happy to send them to you.   They have
> been sitting in storage for probably 20 years, so there are no
> guarantee that they are readable.

Thanks... I will certanly give them a go. I am pretty sure the problem
I am having is the tape, I get a low (and varying) amplitude signal at
the output of the read amplifier, it varies with different tapes, and it's
much the same both on the drive in the 11/730 and a standalone
TU58 I have.

You do realise that I am across the Pond, I hope :-).  I am happy to
cover postage and packing expenses, of course.

> I'm cleaning out the storage unit right now, in preparation for
> moving, so I'll keep an eye out for them.

When I moved house 3.5 years ago, it took _5_ large removal
lorries to carry everything. Oh well...

-tony

Re: Modifying microcode

[Alan Frisbie via cctalk]

Tony Duell  wrote:

> > until the 8085 CFE loaded the microcode.
>
> Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
> running at the moment. The hardware is fine, I've rebuilt the drive rollers,
> but as yet don't have a readable tape (not even blank, to write the
> microcode onto).

I'm pretty sure that I have a complete set of 11/730 TU58 tapes in
my storage unit.   I might even have some brand new tapes.   If I
can find them, I would be happy to send them to you.   They have
been sitting in storage for probably 20 years, so there are no
guarantee that they are readable.

I'm cleaning out the storage unit right now, in preparation for
moving, so I'll keep an eye out for them.

Alan "Pack rat" Frisbie

Re: Modifying microcode

[Tony Duell via cctalk]

On Fri, Jun 1, 2018 at 6:08 PM, Robert Armstrong via cctalk
 wrote:
>>Eric Smith  wrote:
>
>>The control stores of the 11/785, 8600, and 8650 were entirely WCS.
>>
>>All other VAXen had (relatively) large ROM control store and tiny WCS or
>>patch store.
>
>   You forgot the 11/730 and 725.  The KA730 used 2901 bit slicers and the
> control store was entirely in RAM.  After power on it was a paperweight

Indeed. I think others mentioned that processor too.. For some reason the
control store was built from 16K DRAMs, and the CPU has to wait while
they are refreshed every few milliseconds.

> until the 8085 CFE loaded the microcode.

Loaded from a TU58 cartridge, which is the main reason my 11/730 is not
running at the moment. The hardware is fine, I've rebuilt the drive rollers,
but as yet don't have a readable tape (not even blank, to write the
microcode onto).

Incidentally, did DEC ever release any details (flowcharts, source listings,
etc) of the 11/730 microcode? And what about the control PROMs for the
memory system. The technical manual implies there was a listing of those,
but I've never found it.

-tony

RE: Modifying microcode

[Robert Armstrong via cctalk]

>Eric Smith  wrote:

>The control stores of the 11/785, 8600, and 8650 were entirely WCS.
>
>All other VAXen had (relatively) large ROM control store and tiny WCS or
>patch store.

  You forgot the 11/730 and 725.  The KA730 used 2901 bit slicers and the 
control store was entirely in RAM.  After power on it was a paperweight until 
the 8085 CFE loaded the microcode.

Bob

Re: Modifying microcode

[Antonio Carlini via cctalk]

On 01/06/18 18:40, Eric Smith via cctalk wrote:

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


Eric Smith  wrote:
The control stores of the 11/785, 8600, and 8650 were entirely WCS.

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

   You forgot the 11/730 and 725.  The KA730 used 2901 bit slicers and the
control store was entirely in RAM.  After power on it was a paperweight
until the 8085 CFE loaded the microcode.


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



In the Digital Technical Journal #2 (the one that describes the 
development of the MicroVAX II)


they say that they used the VAX-11/730 as a testbed

the 78032 chip. The VAX-11/730 was chosen because it was "an entirely 
'soft' machine".



(The VAX-11/725 is essentially the same hardware but in different 
packaging).



Antonio


--
Antonio Carlini
arcarl...@iee.org

Re: Modifying microcode

[Eric Smith via cctalk]

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

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


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

Re: Modifying microcode

[Eric Smith via cctalk]

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

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

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

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

Re: Modifying microcode

[Jon Elson via cctalk]

On 05/30/2018 11:48 AM, Paul Koning via cctalk wrote:



On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven via cctalk 
 wrote:

Depending on your definition of small, the MicroVAX 1, and the VAX 8000 series 
(not that small). In both cases though, the ROM chips are a custom DEC design.

Didn't the 780 get its microcode loaded by the console LSI-11?  And the 730 
used bit slice processors (AMD 2901) as I recall, so that had to have its 
microcode external.
The early 780 had most microcode in ROM, and had a small 
writable control store for special OS-required options and 
patches.  Later machines had more WCS, but I think they 
still had some non-writable control store.  I remember our 
early 780 had the WCS board replaced during a field upgrade, 
and maybe the fixed control store was replaced, too.


Jon

Re: Modifying microcode

[Tony Duell via cctalk]

On Wed, May 30, 2018 at 4:11 PM, Camiel Vanderhoeven via cctalk
 wrote:

>> Gotcha. Which small VAXes had external ROM/PALs for microcode store?
>>
>
>
> Depending on your definition of small, the MicroVAX 1, and the VAX 8000 series
> (not that small). In both cases though, the ROM chips are a custom DEC design.

The 11/730 (one 10.5" rack unit for the CPU, heavy, but I can lift one
fully assembled)
has (most?) of the microcode in RAM, it's loaded from the TU58 when
you start the
machine. And apart from the ECC gate arrays, it's all standard ICs in
the CPU, albeit
with a _lot_ of PALs.

-tony

Re: Modifying microcode

[Noel Chiappa via cctalk]

> From: Henk Gooijen

> My findings so far :
>   www.pdp-11.nl/pdp11-35/repair/repair35page.html
> Comments are very welcome!

I got a:

  You don't have permission to access to this document on this server. 
  Apache Server at pdp-11.nl

error message?

> I vaguely remember that there was a difference in the front console For
> the BA11-K and the BA11-F configuration. ... the two ribbon cables from
> the front panel are at the right side for a BA11-K box, and on the left
> side for the BA11-F box. Given the location of the CPU boards in both
> boxes, that makes sense.

They didn't do two different console PCBs, did they? It must be just cabling
routing? I couldn't find any manual/drawings for the BA11-K version, so I
can't tell for sure..


> From: Jon Elson

> I'd get an FPGA development board and download Xilinx's webpack
> software. It would not take real long to design the basic microcode
> engine, and then you could develop some application microcode in
> parallel with the hardware

That approach worked really well for Dave B and I on the QSIC. IIRC, we
bounced around the uengine design concepts for a couple of days, and then
once we decided to go, he had the hardware working in a day or so. It's in
Verilog, so perfect for an FPGA devel board; I think it's in his Github
repository:

  https://github.com/dabridgham/QSIC

If you go this route, I have that config-file driven uassembler written in
portable C (compiles on 3 different systems that I know of) which uses only
standard I/O library which you can use for the ucode; it should handle most
any uengine design, unless it has something really wierd.

Noel

Re: Modifying microcode

[Guy Sotomayor Jr via cctalk]

> On May 30, 2018, at 6:51 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Kyle Owen
> 
>> I do have an 11/45, though... so with this modification, I suppose one
>> could have some fun:
> 
> That's for the -11/40 - very different machine, one couldn't use the same
> technique on the /45; the /40 is prepared to accept additional ucode on
> additional CPU boards, that's how the EIA works:
> 
>  http://gunkies.org/wiki/KE11-E_Extended_Instruction_Set
> 
> And it's custom boards, the design for which is no longer extant (pity, as
> I'd love to play with one myself).
> 
> Finally, I have this vague memory that they had to put a few minor mods on
> some of the existing CPU boards (details also lost), although my memory may
> be misleading me on that.
> 

I’m *very* familiar with the 11/40E as all of our 11/40’s at CMU had been 
“upgraded”
to 11/40Es (including all of the ones on C.MMP).

I recall the updated micro-code board but I can’t recall if the main CPU boards 
needed
any mods.  I’ll look over the CMU docs again and see if what might be required.

Did a little bit of micro-programming on the 11/40E but quickly found it was 
better to
concentrate on efficient algorithms.  ;-)  But to speed up kcalls in Hydra 
there was at
one point a lot of custom micro-code on the 11/40Es on C.MMP.

TTFN - Guy

Re: Modifying microcode

[Kyle Owen via cctalk]

On Wed, May 30, 2018 at 12:05 PM, Jon Elson  wrote:

> On 05/30/2018 08:19 AM, Kyle Owen via cctalk wrote:
>
>>
>> I'm thinking about trying to find a microcoded architecture to play with
>> before I design something around the Intel 3000 series.
>>
> Intel 3000?  WHY!
>

Well, the Tesla clones were cheap and readily available on eBay! :)

>
> I'd get an FPGA development board and download Xilinx's webpack software.
> It would not take real long to design the basic microcode engine, and then
> you could develop some application microcode in parallel with the hardware,
> adding whatever feature to the hardware you needed when the need came up in
> the microcode.


Yup, I've played around a lot with my Basys 3 board. But I like the idea of
writing microcode for an existing design (one that has a software
simulation as well as real hardware would be preferable), even though it
could likely run much faster on an FPGA.

>
> I've got a MicroVAX 3800, so I suppose I could run MICRO2 to assemble the
>> aforementioned microcode. But then what? I assume PALs would have to be
>> burned to implement the new microcode. Or is it more complicated than
>> that?
>>
>> PALs?  I don't think the 3800 microcode was in PALs.  I think it was in
> the CPU chip.  There may have been a patch array that allowed a very small
> number of microcode words to be overridden.


Yes, you appear to be correct; it's all internal.

Kyle

Re: Modifying microcode

[Jon Elson via cctalk]

On 05/30/2018 08:19 AM, Kyle Owen via cctalk wrote:

Has anyone attempted to reassemble and update the microcode on a MicroVAX?

Seems like there's enough stuff here to possibly do it:
http://simh.trailing-edge.com/semi/ucode/

I'm thinking about trying to find a microcoded architecture to play with
before I design something around the Intel 3000 series.

Intel 3000?  WHY!

I'd get an FPGA development board and download Xilinx's 
webpack software.  It would not take real long to design the 
basic microcode engine, and then you could develop some 
application microcode in parallel with the hardware, adding 
whatever feature to the hardware you needed when the need 
came up in the microcode.

I've got a MicroVAX 3800, so I suppose I could run MICRO2 to assemble the
aforementioned microcode. But then what? I assume PALs would have to be
burned to implement the new microcode. Or is it more complicated than that?

PALs?  I don't think the 3800 microcode was in PALs.  I 
think it was in the CPU chip.  There may have been a patch 
array that allowed a very small number of microcode words to 
be overridden.


Jon

Re: Modifying microcode

[Eric Smith via cctalk]

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

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


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

RE: Modifying microcode

[Henk Gooijen via cctalk]

Van: Paul Koning via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 30 mei 2018 18:49
Aan: Camiel Vanderhoeven<mailto:camiel.vanderhoe...@vmssoftware.com>; General 
Discussion: On-Topic and Off-Topic Posts<mailto:cctalk@classiccmp.org>
Onderwerp: Re: Modifying microcode



> On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven via cctalk 
>  wrote:
>
> Depending on your definition of small, the MicroVAX 1, and the VAX 8000 
> series (not that small). In both cases though, the ROM chips are a custom DEC 
> design.

Didn't the 780 get its microcode loaded by the console LSI-11?  And the 730 
used bit slice processors (AMD 2901) as I recall, so that had to have its 
microcode external.

paul

I always thought (…) that the TU58 cassette “in” the front of the VAX-11/730
contained the microcode. For ease, that cartridge was kept in the drive so
that it is available at boot time. Causing a lot of “D”shaped rubber rollers …
Henk, PA8PDP

Re: Modifying microcode

[Paul Koning via cctalk]

> On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven via cctalk 
>  wrote:
> 
> Depending on your definition of small, the MicroVAX 1, and the VAX 8000 
> series (not that small). In both cases though, the ROM chips are a custom DEC 
> design.

Didn't the 780 get its microcode loaded by the console LSI-11?  And the 730 
used bit slice processors (AMD 2901) as I recall, so that had to have its 
microcode external.

paul

RE: Modifying microcode

[Henk Gooijen via cctalk]

Van: Noel Chiappa via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 30 mei 2018 17:17
Aan: cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>
CC: j...@mercury.lcs.mit.edu<mailto:j...@mercury.lcs.mit.edu>
Onderwerp: Re: Modifying microcode

> From: Kyle Owen

> So the same technique would work on the 11/35, then?

Yes, the /35 and /40 are completely identical, except for the number
painted on the inlay on the front console.

(Well, the /35 was often sold in a BA11-K box, and the /40 in a BA11-F, but
that's just physical configuration, and is just a 'usually' - there are
/35's in BA11-F's [for sure], and probably /40's in BA11-K's.)

  Noel


I vaguely remember that there was a difference in the front console
For the BA11-K and the BA11-F configuration. When standing in front
of the console, the two ribbon cables from the front panel are at the
right side for a BA11-K box, and on the left side for the BA11-F box.
Given the location of the CPU boards in both boxes, that makes sense.
I do have an 11/35 in BA11-F box (on the system manual cover this
is indicated as the 21“ model).
I also have an 11/35 in BA11-K box, so yes, both configs exist(ed).

Henk, PA8PDP

Re: Modifying microcode

[Camiel Vanderhoeven via cctalk]

On 5/30/18, 5:03 PM, "Kyle Owen"  wrote:

 

On Wed, May 30, 2018 at 9:34 AM, Camiel Vanderhoeven 
 wrote:

The microcode for the MicroVAX 2 (for which the MICRO2 assembler was used) and 
the CVAX (which is the CPU in your 3800) is implemented as a mask ROM on the 
CPU chip itself. No way to change it, and no way you can use MICRO2 to assemble 
the microcode for the CVAX.

 

Gotcha. Which small VAXes had external ROM/PALs for microcode store?

 

Depending on your definition of small, the MicroVAX 1, and the VAX 8000 series 
(not that small). In both cases though, the ROM chips are a custom DEC design.

Re: Modifying microcode

[Kyle Owen via cctalk]

On Wed, May 30, 2018 at 9:34 AM, Camiel Vanderhoeven <
camiel.vanderhoe...@vmssoftware.com> wrote:

> The microcode for the MicroVAX 2 (for which the MICRO2 assembler was used)
> and the CVAX (which is the CPU in your 3800) is implemented as a mask ROM
> on the CPU chip itself. No way to change it, and no way you can use MICRO2
> to assemble the microcode for the CVAX.


Gotcha. Which small VAXes had external ROM/PALs for microcode store?

Thanks,

Kyle

Re: Modifying microcode

[Kyle Owen via cctalk]

On Wed, May 30, 2018 at 8:51 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Kyle Owen
>
> > I do have an 11/45, though... so with this modification, I suppose
> one
> > could have some fun:
>
> That's for the -11/40 - very different machine, one couldn't use the same
> technique on the /45; the /40 is prepared to accept additional ucode on
> additional CPU boards, that's how the EIA works:
>

Ah, I got confused! Thanks for the clarification! So the same technique
would work on the 11/35, then?

Kyle

Re: Modifying microcode

[Camiel Vanderhoeven via cctalk]

The microcode for the MicroVAX 2 (for which the MICRO2 assembler was used) and 
the CVAX (which is the CPU in your 3800) is implemented as a mask ROM on the 
CPU chip itself. No way to change it, and no way you can use MICRO2 to assemble 
the microcode for the CVAX.

On 5/30/18, 3:19 PM, "cctalk on behalf of Kyle Owen via cctalk" 
 wrote:

Has anyone attempted to reassemble and update the microcode on a MicroVAX?

Seems like there's enough stuff here to possibly do it:
http://simh.trailing-edge.com/semi/ucode/

I'm thinking about trying to find a microcoded architecture to play with
before I design something around the Intel 3000 series.

I've got a MicroVAX 3800, so I suppose I could run MICRO2 to assemble the
aforementioned microcode. But then what? I assume PALs would have to be
burned to implement the new microcode. Or is it more complicated than that?

I don't have a PDP-11/60, unfortunately. I do have an 11/45, though...so
with this modification, I suppose one could have some fun:
http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241=compsci

Thanks,

Kyle

Re: Modifying microcode

[Noel Chiappa via cctalk]

> From: Kyle Owen

> I do have an 11/45, though... so with this modification, I suppose one
> could have some fun:

That's for the -11/40 - very different machine, one couldn't use the same
technique on the /45; the /40 is prepared to accept additional ucode on
additional CPU boards, that's how the EIA works:

  http://gunkies.org/wiki/KE11-E_Extended_Instruction_Set

And it's custom boards, the design for which is no longer extant (pity, as
I'd love to play with one myself).

Finally, I have this vague memory that they had to put a few minor mods on
some of the existing CPU boards (details also lost), although my memory may
be misleading me on that.

Noel

Modifying microcode

[Kyle Owen via cctalk]

Has anyone attempted to reassemble and update the microcode on a MicroVAX?

Seems like there's enough stuff here to possibly do it:
http://simh.trailing-edge.com/semi/ucode/

I'm thinking about trying to find a microcoded architecture to play with
before I design something around the Intel 3000 series.

I've got a MicroVAX 3800, so I suppose I could run MICRO2 to assemble the
aforementioned microcode. But then what? I assume PALs would have to be
burned to implement the new microcode. Or is it more complicated than that?

I don't have a PDP-11/60, unfortunately. I do have an 11/45, though...so
with this modification, I suppose one could have some fun:
http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241=compsci

Thanks,

Kyle