30 May
2018
30 May
'18
6:19 a.m.
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&context=comp…
Thanks,
Kyle
30 May
30 May
7:34 a.m.
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"
<cctalk-bounces at classiccmp.org on behalf of cctalk at classiccmp.org> 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&context=comp…
Thanks,
Kyle
8:02 a.m.
On Wed, May 30, 2018 at 9:34 AM, Camiel Vanderhoeven <
camiel.vanderhoeven at 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
8:11 a.m.
On 5/30/18, 5:03 PM, "Kyle Owen" <kylevowen at gmail.com> wrote:
On Wed, May 30, 2018 at 9:34 AM, Camiel Vanderhoeven <camiel.vanderhoeven at
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?
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.
9:48 a.m.
On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven via
cctalk <cctalk at classiccmp.org> 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
9:53 a.m.
Van: Paul Koning via cctalk<mailto:cctalk at classiccmp.org>
Verzonden: woensdag 30 mei 2018 18:49
Aan: Camiel Vanderhoeven<mailto:camiel.vanderhoeven at vmssoftware.com>; General
Discussion: On-Topic and Off-Topic Posts<mailto:cctalk at classiccmp.org>
Onderwerp: Re: Modifying microcode
On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven via
cctalk <cctalk at classiccmp.org> 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
9:54 a.m.
On Wed, May 30, 2018 at 10:48 AM, Paul Koning via cctalk <
cctalk at 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.
7:26 p.m.
On 05/30/2018 11:48 AM, Paul Koning 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. I remember our
early 780 had the WCS board replaced during a field upgrade,
and maybe the fixed control store was replaced, too.
Jon
On May 30, 2018, at 11:11 AM, Camiel Vanderhoeven
via cctalk <cctalk at classiccmp.org> 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.
31 May
31 May
8:28 a.m.
On Wed, May 30, 2018, 20:26 Jon Elson via cctalk <cctalk at classiccmp.org>
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.
1 Jun
1 Jun
10:08 a.m.
Eric Smith <spacewar at gmail.com> 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
10:40 a.m.
On Fri, Jun 1, 2018 at 11:08 AM, Robert Armstrong <bob at jfcl.com> wrote:
Thanks for the correction! I've never used those models.
Eric Smith
<spacewar at gmail.com> 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. 
11:46 a.m.
On 01/06/18 18:40, Eric Smith via cctalk wrote:
On Fri, Jun 1, 2018 at 11:08 AM, Robert Armstrong
<bob at jfcl.com> wrote:
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
arcarlini at iee.org
Eric
Smith <spacewar at gmail.com> 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. 
2 Jun
2 Jun
7:17 a.m.
On 06/01/2018 02:46 PM, Antonio Carlini via cctech wrote:
On 01/06/18 18:40, Eric Smith via cctalk 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
On Fri, Jun 1, 2018 at 11:08 AM, Robert Armstrong
<bob at jfcl.com> wrote:
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
Eric
Smith <spacewar at gmail.com> 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. 
9:28 a.m.
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
1:33 p.m.
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.
Antonio
--
Antonio Carlini
arcarlini at iee.org
4:23 p.m.
On 06/02/2018 03:33 PM, Antonio Carlini via cctech wrote:
On 02/06/18 15:17, allison via cctech wrote:
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
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.
3 Jun
3 Jun
10:58 a.m.
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
7:37 p.m.
On Fri, Jun 1, 2018 at 2:46 PM, Antonio Carlini via cctalk
<cctalk at classiccmp.org> 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
8:31 p.m.
On Jun 3, 2018, at 7:37 PM, Ethan Dicks via cctalk
<cctalk at classiccmp.org> 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 <nf6x at nf6x.net>
http://www.nf6x.net/
4 Jun
4 Jun
10:17 a.m.
Ethan Dicks <ethan.dicks at gmail.com> 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
2:13 p.m.
On Jun 4, 2018, at 1:17 PM, Robert Armstrong via
cctalk <cctalk at classiccmp.org> 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
2 Jun
2 Jun
3:35 a.m.
On Fri, Jun 1, 2018 at 6:08 PM, Robert Armstrong via cctalk
<cctalk at classiccmp.org> wrote:
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.
Eric Smith
<spacewar at gmail.com> 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.
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
11:08 a.m.
Tony Duell <ard.p850ug1 at gmail.com> 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.
Bob
3 Jun
3 Jun
8:32 a.m.
On Jun 2, 2018, at 2:08 PM, Robert Armstrong via
cctalk <cctalk at classiccmp.org> wrote:
That would be Ritchie Lary?s microcode implementation for the PDP-11/60 with
WCS.
John.
Tony Duell <ard.p850ug1 at gmail.com>
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.
Bob
11:17 a.m.
On 02/06/18 19:08, Robert Armstrong via cctalk wrote:
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
arcarlini at iee.org
Tony Duell
<ard.p850ug1 at gmail.com> 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. 
5:36 p.m.
On Jun 2, 2018, at 2:08 PM, Robert Armstrong via
cctalk <cctalk at classiccmp.org> wrote:
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?
Tony Duell <ard.p850ug1 at gmail.com>
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).
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
15 Jun
15 Jun
8:28 a.m.
New subject: LISP microcode for an 11/730? Was Re: Modifying microcode
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.
3 Jun
3 Jun
7:36 p.m.
On Fri, Jun 1, 2018 at 1:08 PM, Robert Armstrong via cctalk
<cctalk at classiccmp.org> wrote:
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.
And one of the big optimizations was to cut a fresh console boot tape
with all the required files in sequential order because the 8085 would
cache the directory block (thankfully!) so it didn't have to rewind
between reading each file. The stock tape was rather random and could
take 20-30 min of shoeshining. Putting the files in order brought the
boot times down to 10 min or less of console load - i.e. - essentially
the serial transfer speed of that many kbytes, or close to it.
Today, of course, I would seriously think about a TU58 emulator.
There are several projects.
-ethan
30 May
30 May
10:51 a.m.
On Wed, May 30, 2018 at 4:11 PM, Camiel Vanderhoeven via cctalk
<cctalk at classiccmp.org> wrote:
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
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. 
3 Jun
3 Jun
11:38 p.m.
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.
4 Jun
4 Jun
10:15 p.m.
Rob Doyle wrote:
Camiel Vanderhoeven wrote:
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?
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?
30 May
30 May
10:05 a.m.
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
10:22 a.m.
On Wed, May 30, 2018 at 12:05 PM, Jon Elson <elson at pico-systems.com> wrote:
On 05/30/2018 08:19 AM, Kyle Owen via cctalk wrote:
Well, the Tesla clones were cheap and readily available on eBay! :)
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.
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
Yes, you appear to be correct; it's all internal.
Kyle
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.
2146
days inactive
2162
days old
34 comments
17 participants
participants (17)
-
a.carlini＠ntlworld.com -
aek＠bitsavers.org -
allisonportable＠gmail.com -
ard.p850ug1＠gmail.com -
bob＠jfcl.com -
camiel.vanderhoeven＠vmssoftware.com -
classiccmp＠crash.com -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
henk.gooijen＠hotmail.com -
john＠forecast.name -
kylevowen＠gmail.com -
lars＠nocrew.org -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
radioengr＠gmail.com -
spacewar＠gmail.com