On 21/03/2024 22:03, Jonathan Stone wrote:
> What kind of VAX 4000? One with DSSI connectors on the "S:U", or the
> /VAX 4000-200/KA660, which has serial and Ethernet? IIRC you can
> klludge up the latter using a KA630 SLU, and either re-using the
> AUI/10base-2 part of the SLU,
> or kludging one from a DEQNA/DELQA to act like the AUI-select switch
> setting and AUI of the original
> Those come off the KA660 in a single IDC connector, 50 pin if memory
> serves.
>
> I have no idea about substituting for DSSI.
It's a VAX 4000-300 (KA670) in a BA440, so it has two DSSI, ethernet,
the usual switches and LED display. I can switch ethernet between AUI
and BNC (the green LEDs change) and I have known working DETPM
AUI<->RJ45 interfaces, so ethernet may be OK. I have found one panel for
a KA650 (uV 3500/3600) that has an OK connector but is otherwise a bit
toasty, so I'll try carefully removing that tomorrow. If that goes OK,
then I'll remove the MMJ socket from the VAX 4000 console SLU: it's dead
so there's not really much risk here as long as I'm careful with the
PCB. At least I could then tack on 6 wires and find a way of
interfacing. I do have at least one H8584-AC, which is an MMJ socket and
an RJ45 plug. So with a bit of measuring I could probably find an RJ45
socket and rig up some temporary franken-console. Or, if the KA650 donor
is really too far gone, and its socket survives half a dozen cable
insertion-removals with no harm, then I could just fit that in place.
If the console ethernet doesn't work, I think I can drop in the DELQA
with appropriate handles from the KA650 system ... I think that the
BA440 Q-bus metalwork and the BA213 metalwork are compatible. If not I
have one Q-bus DELQA panel and I'm sure that neither the VAX nor
anything else in there with it care too much about RF interference these
days!
I can find new MMJ plugs all over the place (admittedly I'm assuming
that Mouser and Farnell could actually supply them!!) but the
corresponding sockets seem to be lost to time. Or at least they remain
beyond my goolge-fu.
Antonio
--
Antonio Carlini
antonio(a)acarlini.com
Hi all,
Some of you may remember that I (Adam) and another chap (Chris) rescued two
IBM 360/20 systems out of an abandoned building in Nuremberg back in 2019
and brought them to the UK (our blog is here: https://www.ibm360.co.uk/).
We have since basically found ourselves unable to effectively progress the
project due to personal & professional commitments. For various reasons
(explained in our latest blog post) we are testing the waters for making
the machines available to the right sort of people.
We are therefore inviting proposals or offers focused around one of the
following core ideas:
1. A museum or preservation organisation takes the machines on permanent
loan or possibly as a donation depending upon exactly what the terms look
like
2. A private entity takes the machines on loan for display for a fix
period
3. A foreign museum takes the machines, with negotiation around coverage
of our costs
4. A private collector purchases the machines from us for a sum to be
negotiated at the time
If you have an alternate proposal we would also be open to hearing it.
We have three main systems in the collection, as detailed below:
*Red IBM 360 Model 20 System*
1 x IBM 360 Model 20 CPU in Red
1x 2203 System Printer
2x 2311 Disk Drives
1x 2152 System Console (possibly the last remaining example of this in the
world, though in poor condition)
1x 2560 Punched Card Reader/Punch/Sorter
1x 2501 Punched Card Reader
2x 2415 II Tape Drives (One master, one slave) (Possibly only remaining
examples of this model globally)
25x IBM Disc Packs
*Blue IBM 360 Model 20 System*
1 x IBM 360 Model 20 CPU in Blue
1x 2501 Punched Card Reader
1x 1403 Printer
*System 370/125*
1x 370/125 CPU – Unknown condition
1x 3504 Punched card reader (incomplete)
*Miscellaneous*
1x 029 Card Punch
1x 5471 System Console
Assorted other spares and unknown/incomplete components
Around 12 full boxes of brand new IBM punched cards
-----------
In an ideal world we would like to see everything go together, but we
understand that this is an enormous amount of kit and that might not be
possible. We are not willing to split up individual systems, but we are
willing to split things by the groupings above. For instance if there was
interest in only the red system due to its complete set of peripherals, we
would be willing to negotiate on that basis.
It is extremely rare that systems such as this become available, and these
are two of only a handful of privately held IBM 360’s in the world.
If you have an idea or a proposal, please email me directly at this
address. Please do NOT email me to suggest I contact X museum unless you
are a representative of that museum or hold a direct relationship with them
and know they are interested.
We are genuinely sad that we’ve been unable to work on this project and
take it where we wanted it to go. We set out with strong intentions, but
alas, as is often the case life took over and we were unable to push
forward in the way we wanted to. We hope that someone comes along who will
be able to keep the systems safe for future generations.
Kind Regards,
Adam Bradley
With great interest, I have seen that there are now scans for the Z23
(perhaps more coming soon :-) ).
But I have to admit that I am so much disappointed of the quality. I mean,
whoever scanned this all, did he have a single look at the output? I do
this, for each of the many scans, may they be only a single or many
hundred pages.
Example:
.../zuse/Z23/Zuse_Z23_Beschreibung_einschlie%c3%9flich_der_Zusazgeräte_Februar_1962.pdf
PDF pages 16/17:
this is a no-go. This must not happen in a document uploaded to bitsavers.
Pages 32-35 (and many others, too):
what the heck happened here??
And there appears to have been some "intelligent" post-processing of the
images that renders them very artificially.
Sorry for the rant, but that is not what I would accept as archiving
material. I'd offer to rescan them (guessing that the origin is from
Germany) reasonably.
Christian
All,
I'm looking for an image of the ROM or companion diskette for the Maxim MAX180 Evaluation Kit (MAX180EVKIT). I've got one that has a custom application ROM in it.
Thanks,
Jonathan
There is a printed version of this printed by Alpha Books, ISBN 1-56761-463-9. I bought it years ago (1998)
. Not sure if it’s 100% the same text, but it has a lot of nice pictures and was issued around the 25th anniversary of Apollo 11. It’s on Amazon right now for $7.12.
Rich
On 3/15/24, 8:14 PM, "Ethan Dicks via cctalk" <cctalk(a)classiccmp.org> wrote:
On Fri, Mar 15, 2024 at 6:49 PM Charles Dickman via cctalk
<cctalk(a)classiccmp.org> wrote:
> Voyager 1 is in the news recently because of communications problems and
> possible solutions. Is there an online source for documentation on the
> Voyager systems, especially the computers and navigation systems?
>
> I have enjoyed reviewing the Apollo systems documentation on the Virtual
> AGS Home Page and wondered if there were similar documents available for
> Voyager.
"NASA Contractor Report 182505 Computers in Spaceflight: The NASA Experience"
More of a top-level tour of a number of platforms, it covers, in quite
some detail, systems from Gemini to the Space Shuttle and mentions the
RCA 1802 numerous times. Samples of some NASA DSLs (HAL/S and GOAL).
Extensive citations and bibilography. Voyager and Galileo are covered
in Chapter 6.
Public domain. PDF link at: https://ntrs.nasa.gov/citations/19880069935
Excellent stuff in there.
-ethan
Voyager 1 is in the news recently because of communications problems and
possible solutions. Is there an online source for documentation on the
Voyager systems, especially the computers and navigation systems?
I have enjoyed reviewing the Apollo systems documentation on the Virtual
AGS Home Page and wondered if there were similar documents available for
Voyager.
-chuck
Hi,
I just wanted to provide a bit of a progress report on the SMD/ESDI
emulator project.
Now that I'm retired I have a bit more time to actually work on it.
Previously I was just doing a bunch of research and writing notes on the
design. I now have a solid design and I'm starting with the implementation.
I'm going to list some of the design goals and then sketch out a few of
the major issues and how they're being addressed.
Goals:
* Emulate any drive geometry
* Emulate a drive's performance characteristics
* Work across different interface types
* Fully built emulator cost below $500
Major Issues:
* SMD/ESDI have head switch times < 10 microseconds (basically the
time it takes for the read amplifiers to settle on a "real" drive).
Solving this issue drives the majority of the design
* Address marks on a "real" drive are implemented by writing a DC
signal on the track and the read circuitry detects that and
generates the address mark signal
When looking at the specifications for SMD and ESDI disks there aren't
really a lot of difference in how the drive behaves. The interfaces
differ in detail but in reality the differences are pretty minor. So
the current design should allow for 95+% code sharing between SMD and
ESDI emulators.
To solve the head switch performance, it is necessary to have an entire
cylinder in some sort of RAM. This allows for very fast head switch
times (e.g. the selected head just addresses a particular portion of the
RAM). However, this means that loading a cylinder (which in some cases
could be as much as 1MB) could take considerable time. It will take
even longer if some of the tracks in the cylinder are "dirty" due to
them having being written to prior to the seek.
Since I want the emulator to be able to faithfully emulate drives in all
respects, the limiting factor is the cylinder-to-cylinder seek time
(e.g. moving from one cylinder to another cylinder that is adjacent).
This is typically in the 4-8ms range. So doing the math, one must move
1MB in 4ms (that turns out to be ~250MB/sec of bandwidth...using 32-bit
transfers, this means over 60M transfers/sec).
The above implies that the cylinder RAM and where the storage holding
the cylinders of the image must be capable of at least 60M transfers/sec
between them. This is going to involve a complex FPGA that is able to
have large internal RAMs and a direct connection to some sort of DRAM to
hold the full image. I've chosen to use a SOM (System-On-Module)
version of the Xilinx Zynq 7020. This has dual 32-bit ARM cores (plus a
whole bunch of peripherals), 32-bit DDR3 memory interface, plus a fairly
large FPGA with enough block RAM to contain the maximum cylinder. The
calculations I've done should allow a new cylinder to be loaded from
DRAM into the cylinder RAM in 4-8ms (I think with a few tricks I can
keep it in the lower range).
I've looked a quite a few Zynq SOMs (and have acquired quite a few for
evaluation purposes). I finally found one that's ~$200 (most of the
others are in the $400-$1000+ range). This SOM brings out most of the
Zynq's I/Os (94 I/Os) in addition to having ethernet, USB, serial, SD
card, etc. as well as 1GB of 32-bit DDR3 DRAM. It also runs Linux which
means that developing the SW is fairly straight forward.
The next issue was how to emulate address marks. The emulated drive
will have a bit clock which is necessary for clocking out the data when
reading (or out when writing). The bit clock is always running (just
like a "real" drive when spinning). That will drive a counter (which
represents which bit is under the emulated "head"), that counter (along
with the head number) will be used to address the block RAM. The
counter is always running, so as to emulate the spinning disk. The
address marks are emulated by having a series of comparators (one for
each possible sector). They compare the bit counter with the value
associated with the comparator, if there's a match then that signals an
address mark. It's bit more complicated because writing address marks
(in the case of soft-sectors) has to be dealt with.
The emulator is composed of 4 major components:
1. Emulator application plus some utilities
I'm currently writing all of this code...since I'd been a SW
engineer for 50+ years, this is all "production" quality code and is
extremely well documented...still a ways to go.
2. Linux device driver which provides the interface between the
emulator application and the emulator HW
I haven't started on the driver yet but it should be fairly straight
forward as it really only provides an interface to the emulator HW
to the emulator application
3. Emulator HW RTL
I haven't started on this other than to do some basic blocks of
what's here. It mainly is the cylinder RAM, serdes (I *may* be able
to finesse this by having 32-bits on the AXI bus and 1 bit on the
interface side...a nice feature of the block RAM), address mark
logic, bit counter and some command decode/handling (it'll handle
the seek command all in the RTL...everything else will be handled by
the application.
4. Interface board
This should be a fairly simple board. It's a carrier for the SOM,
3.3v-to-5v level shifters, interface circuits for SMD or ESDI (they
use different interface ICs) and the interface to the cable.
I'm starting with SMD just to make the board layout easier (I can just
use 0.1" headers for interface cabling). I also have an SMD disk
exerciser that will make it easier to make sure it's working properly.
The idea is that once I have an SMD working reasonably well, I'll start
on ESDI.
Interacting with the emulator application can be any of the following:
* config file: indicates various emulator startup options including
which image (if any) to "mount" initially
* command line: same as the config file
* emulator utilities: these are mainly allow for changing which image
is mounted, changing write protect status, querying state of
emulator, etc. The utilities can be used locally by logging into to
Linux running on the Zynq 7020 or by using "host" versions if the
emulator is connected to a network via ethernet.
One of the key utilities is creating an "empty" (that is all tracks
contain all 0's) image. The image format has been finalized. It allows
for almost any geometry of disk (up to 32 heads and up to 65536
cylinders). The main restriction is the 1GB of DRAM on the Zynq 7020
SOM. I expect in reality that the largest drive that can be emulated
will be ~600-700MB due to DRAM.
I plan on providing some standardized "templates" (e.g. they'll describe
actual drive geometries and seek performance tables) so creating new
images won't be too onerous.
I'll be putting all of the source, RTL and board files on github under a
BSD license once I get further along.
--
TTFN - Guy
I picked up a keyboard for a Wyse terminal at a flea market the other
day. When I tried some of the keys, they couldn't be depressed.
I thought, at first, some dirt or debris had gotten stuck there, but on
closer look I saw something black below the keys that seemed to be
stuck. I pulled a key cap off and found a U shaped piece of black
plastic that was put there on purpose to prevent you from depressing the
key.
The question came to mind; "What sort of application would be so crude
that you would have to prevent the user from depressing certain keys?"
One of the keys was a Break key, which sort of made sense to me, because
it would halt a PDP-11 if that was the host machine.
This was the first time I had ever seen this kind of thing, was this
common long ago?
LINK:
https://www.kennettclassic.com/surplus-sale-starts-3-19/
If you can make it to Kennett Square, PA USA between now and April 19th
2024, stop in and browse our inventory of surplus vintage computing items.
The link above contains answers to questions. If you want to be added to
the mailing list, visit kennettclassic.com and submit a contact form.
Thanks
Bill Degnan
