Hi, I'm brand new to vintage computing and would love any advice. I'm
thinking of putting together a SM EVM A131-10 and would appreciate any
advice/knowledge on the unit.?
Just posting this here in case it reaches eyes not in other forums I'm on.
I decided to embark on a project that involves burning a 2708 EPROM. I've
never messed with EPROMs before, so I decided to practice. What I have is a
Microworks 2708 'burner' that came with a SWTPC 6800 machine I have. I
figured I'd start by learning how to read 2708s.
I only had one 2708 lying around to use. It was installed on a homebrew
'Dynamicro' board (also known as Jon Titus' MMD-1). It's strange because
the MMD-1 doesn't use 2708s. This board also had a bunch of ICs on it that
are not what the MMD-1 design calls for. So I thought this'd be an
interesting EPROM to read anyway, since it might yield a hint as to what the
builder was doing with this board, or if they were just using it to store
random ICs.
Anyway, I fired up the 6800 with the chip in the ZIF socket of the
Microworks board and read the contents into memory. I then punched it back
out to my PC terminal as S records. That's as far as I got. I'm wondering
now how to actually dig into the contents a bit for clues as to what it is.
I've seen posts in the past from people who were able to find strings, etc
that sort of help as clues. Does anyone know how I'd go further here?
Really curious what was on this one.
Thanks!
Brad
> From: Paul Koning
> The only asynchronous computer I can think of is the Dutch ARRA 1
Isn't the KA10 basically asynchronous? (I know, it has a clock, but I'm
not sure how much it is used for.)
The thing is I recall reading (where, I don't now remember) that the CPU is
organized with 'go' pulses leading from one block of circuity to another, and
it uses delay lines to time out the passage of these pulses, so if you wanted
the CPU to be as fast as possible, you went around to each delay line and
tweaked them down until things started to fail, and then backed off a bit.
Other CPUs of that era might be the same. There's an amusing description
of the Multics CPU here:
http://www.multicians.org/mga.html#6180
"The 6180 processor was among the last of the great non-microcoded engines.
Entirely asynchronous, its hundred-odd boards would send out requests,
earmark the results for somebody else, swipe somebody else's signals or data,
and backstab each other in all sorts of amusing ways which occasionally
failed (the 'op not complete' timer would go off and cause a fault). Unlike
the PDP-10, there was no hint of an organized synchronization strategy:
various 'it's ready now', 'ok, go', 'take a cycle' pulses merely surged
through the vast backpanel ANDed with appropriate state and goosed the next
guy down."
Noel
> From: Mark J. Blair
> I wonder if it might also be useful in any of the QBUS MicroVAXen?
Hardwarewise, it should be fine. Softwarewise... well...
The issue is that we're currently only planning to emulate the RK11 and RP11,
because we're not up for the hassle involved in emulating more recent
controllers. (That's not an issue for the systems we want to run.)
We looked at the RP04, and _full_ emulation even of that one is a significant
amount of work. (I stress the 'full' because a partial, simple emulation
might not be too bad, but since we have no idea what various OS's will expect
to be there, it's not clear how much use such a partial emulation would be.)
However, that presents a problem. There are no 22-bit versions of either (in
fact, there's no QBUS RP11 at all; and the QBUS RK11 is restricted to Q16,
for reasons that surpass me). 22-bit operation is needed to make them really
useable as mass storage under Unix, for swapping (because all file system
access is buffered through low memory, purely file system use would be OK
without Q22 support) - at least on -11's with more than 256KB of memory.
(Probably DEC OS's too, but I know nothing of them.)
So, in addition to the dead-stock emulations of the two, we will also support
slightly 'adjusted' versions of the controllers, to have an 'address
extension' register (in exactly the same way the RLV12 has an extra register
over the RLV11).
(And we're also going to have an adjusted version of the RP11, which extends
the size of the disk, using unused bits/values in the disk address registers,
to allow up to 1TB on an 'RP11-D', as we're calling it. Hey, if you're going
to change the controller _at all_... But I digress.)
Anyway, you can see where this is going. For people who can tweak their
drivers, no biggie. The changes aren't major - a line or two. For people who
want to run stock software...
I don't know enough about how the QBUS VAX systems use their disks. Will uVAX
OS's run with only an RKV11-D for mass storage? Somehow I doubt it..
I assume on the later ones (the ones with the private memory bus so they can
have more than 4MB of memory) there's some sort of QBUS map, to map from the
QBUS' 22-bit address space, to the full memory. But does the hardware and
software expect to use the entire 22-bit address space, or are they prepared
to limit it (e.g. for working with an RKV11-D), or what?
I suppose we could add the RLV12 to the list of things we emulate; that's not
_that_ complicated a controller. The problem is that RL's aren't that big
(10MB), and that gets to be an issue with later OS's. And even then VAX OS's
might not run off an RLV12 - I just don't know.
Getting around this is all, of course, a SMOP (Small Matter of Programming),
since a new FPGA load, with support for more emulations, can be installed on
an existing QSIC at any time.
Now, whether Dave would be interested in supporting later devices, or whether
someone else could be convinced to emulate something more modern ... who knows?
Noel
> From: John Welch
> SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE WHICH DOES NOT RESPOND.
> HALTED.
> Does anyone have any hints on how I can guess what I need to add?
Well, Able made a thing called an 'Able ENABLE' which allowed use of more
than 256KB of physical memory on any UNIBUS -11 with memory mapping hardware
which wasn't an -11/70-44-24. That's probably what it's talking about.
We had one on our -11/45 at MIT, BITD. So I have the programming spec for it,
back-created from the source code for that machine. And Clem Cole was nice
enough to follow up on an old message in an email list archive, and dig up
some documentation and scan it in.
I was planning on doing a page for it on the Computer History wiki, haven't
got a round tuit yet, though.
They are, AFAIK, complete unobtainium in physical form; I've been looking for
years, never seen one.
If someone wanted to upgrade SIMH to support it, we do know enough to do that.
Noel
> From: John Welch
>>> SAV -- SOFTWARE CONFIGURED FOR ENABLE HARDWARE WHICH DOES NOT RESPOND.
> I can boot RSX from a different device (or RT-11, or unix maybe) and
> then mount this RL02 pack and go exploring through its contents. Is
> there a possibility that I may find what is missing that way?
Sorry, I'm confused by this? The message (above) seems to indicate there's
_hardware_ missing. How is looking through the disk contents going to help
with that?
Or is your point that you might be able to find a version of the system which
does not use that hardware? Perhaps; there's no way to know without looking.
Noel
Best wishes for 2018!
I have been busy trying to repair my dead 11/35.
The system was working, but there was one screw loose that mounts the
system units in the BA11 box ... that screw created a short circuit :-(
After powering the 11/35, ENA/HALT on HALT, and toggling the LOAD ADRS
switch, all DATA lamps go on, and after that the machine is totally
non-responsive.
I installed the KM11 replica from Guy Sotomayor (at last, after 7 years,
I have soldered one of the kits that I had since 2011-2012!). With the
KM11, I can step the microcode right from power up. When I toggle
LOAD ADRS I see that the SWITCH signal (via the 7474 flipflop) is set,
but when the microcode checks *which* toggle was activated it decides
that none was activated. I measured the signals that play a role here,
and all looks fine.
Now, what gets me puzzled.
If I toggle the LOAD ADRS switch *and hold it pressed down*, then, when
I step the microcode, the branch that handles the LOAD ADRS switch
actually does get executed, and the ADDRESS lamps on the console show
the switch register settings.
Anybody for clues how to proceed?
If you are interested, I made a write up of my testing in (way) more detail:
www.pdp-11.nl/pdp11-35/repair/repair35page.html<http://www.pdp-11.nl/pdp11-35/repair/repair35page.html>
Thanks for any advice,
Henk
> From: Jim Stephens
> I had a meeting with Ken Omohundro on 12/7 and will be having dinner
> with him again soon. I'll ask him about it. I know he doesn't have any
> records left, but I could take him your notes and see what he recalls.
Thanks very much for that offer; we do think we know more or less how it
works (software-wise we always knew, since I wrote the code for it on the MIT
system, and that, and some other code to run it, still survive; the hardware
details had faded from my memory, but the documentation that Clem Cole found
cleared the high-level details of that up, mostly); however, there are two
areas in which he might be able to help.
The first is some very low-level details of how it worked, in terms of the
UNIBUS interaction; we can surmise, from the way it's installed, how it more
or less has to work (details below), but it would be nice to have it
confirmed. The second is some details of how some of the optional stuff for
using existing memory, non-DMA devices, etc worked. (I honestly forget the
details of what I couldn't work out there; I'll have to go study it again.)
The first is that unlike my initial recollections, both the CPU and DMA
devices are on a single UNIBUS segment which feeds into the ENABLE. There are
two different 18->22 maps in the ENABLE, one for CPU cycles, one for DMA (the
latter perfectly emulates the UNIBUS map on the -11/70 and /44). So, more or
less by definition, it has to be able to distinguish CPU bus cycles from DMA
device bus cycles on the incoming UNIBUS segment.
But how, exactly? I can _theorize_ how it did it, but this is a topic not
covered in the still-extant documentation. I _surmise_ that it was something
like it watches NPR/SACK for a DMA cycle (it won't see the NPG, of course),
then waits for BBSY to cycle, at which point it knows it's a DMA cycle; if
not, the current cycle must be from the CPU. He may or may not remember the
details, but if he can, that would be great.
(For software emulation, we don't need to know this, but it would be good,
for completeness' sake, to know. Also, I have a fantasy that the UNIBUS
version of the QSIC will also include ENABLE-type functionality, and although
we could probably work it out on our own, it would be good to have the
benefit of anything he can recall - any not-so-obvious gotcha's, etc.)
It would also be interesting to know why he just didn't use a 3-bus design:
i) UNIBUS in from the CPU, ii) UNIBUS in from DMA devices, and iii) EUB to
the memory. I suspect that the answer is that they way they did it, they
could use a stock MUD backplane (being used in EUB mode), and only one
over-the-back connector into the ENABLE.
On the second, I'll have to go re-read the documentation, and get back.
(Although now that I think about it, I may have just figured out, not only
the question, but also the answer.)
> I hope to get a biography and history of his companies including Able,
> and figure somewhere to get it stored.
The Computer History wiki would seem an ideal place for this sort of content?
(Depending on how long the bio is; but the company info would _definitely_ be
very much on target for there.)
Noel
There probably aren't that many 120V versions of the Amstrad Joyce Word
processor, but I've got one here. I replaced the 3" CF floppy drive
with a 720K 3.5" drive and modified some boot disks.
The system now supports 3.5" double-sided media and is fully populated
with 512K of DRAM and runs CP/M 3.0.
Unit with keyboard only, free to good home; sorry but I don't have the
printer.
I need to get this thing out of the way; if it goes unclaimed by January
15, off it goes to NextStep recycling.
--Chuck
Did anyone ever succeed in repairing a stepper motor
Currently restoring a datapoint floppy drive that has been stored in a disastrous environment.
The head stepper has a loose wire, currently I cannot even see how to open the stepper motor.
It is a Warner Electric SM-024-0045-AS
Cannot see any marking as to who the druive supplier is, it might have been Datapoint themselves.
Jos
