Hi,
Who can help me with a source (not IBM) for logic probe tips
used with IBM MST and SLT backplanes.
See: http://home.hccnet.nl/h.j.stegeman/IBM_logic_probes.jpg
Prefably the lower one (P/N 453826).
Thanks for your replies.
Regards Henk
This may be common knowledge here, but I was unaware of it (and, AFAIK, the
DEC documentation doesn't point this out), so here goes...
It turns out one doesn't need the fancy cab-kit to connect up to an 11/23+'s
console. The headers on the card are completely compatible with standard
DLV11-J connectors, and a DLV11-J cable can be used to connect up to an
11/23+ card. (One has to select the desired baud rate with the DIP switches
on the card, of course.) I have verified this by trying it, and it worked.
The cabkits merely allow one to select the baud rate at the console connector
(via a clock generator on the cabkit, and the 'external clock' input on the
serial interface). This implies that one should be able to plug a cabkit into
an appropriately configured DLV11-J (external serial clock select), and
select the baud rate via the switch on the cabkit. I haven't tried that,
though.
Noel
Sorry got really sick. Below is the model numbers. I will supply more info if anybody is interested
Pricing is open due to shipping weight is included
CRT monitors working with cables
HP A4033A 65lbs
HP A45764 75lbs
servers/workstations
HP Visualize C180 30lbs
HP Apollo 400 MOD#A2193A 90lbs
Mentor Graphics HLN5065W 100lbs
I clan also be contacted via cell 7607030986
This was a screen driver I'd written to do pseudo windowing on green
screen terminals. I thought it would have made more sense and been
cleaner in C, but it wasn't.
On 2/17/2015 9:27 PM, Mouse wrote:
>> I've rewritten cobol into C a few times when I was a big enthusiast
>> of C and the C code was longer and harder to maintain.
>>
> That is no surprise to me. If you were to take code written in C and
> translate it into COBOL, I'd generally expect the COBOL code to be
> longer and harder to maintain, too.
>
> Indeed, I'd expect that for pretty much any pair of languages;
> translating code out of the idiom it was written for generally makes it
> larger and harder to understand.
>
> /~\ The ASCII Mouse
> \ / Ribbon Campaign
> X Against HTML mouse at rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>
>
I have a box of old HP paper tapes to read, and am having an awful time
trying to build the right serial cable to connect a GNT-4601 reader/punch
to a Linux PC. Does anyone have a known good cable diagram and stty
settings that will work? Thank.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://q7.neurotica.com/Oldtech/
On Fri, Feb 20, 2015 at 7:22 AM, Shiresoft <ggs at shiresoft.com> wrote:
>
>
> > On Feb 19, 2015, at 11:35 PM, Chuck Guzis <cclist at sydex.com> wrote:
> >
> >> On 02/19/2015 08:23 PM, Guy Sotomayor wrote:
> >>
> >> Nope. It was (and still is) how I write code (sit down and compose at
> >> the keyboard). One of my old bosses at IBM once said "Yea, Guy just
> >> waves his hands over the keyboard and programs come out".
> >
> > That would have been impossible in my case, unless I had the most
> prodigious eidetic memory in history.
> >
> > Writing code almost always involved using an on-disk or -tape source
> code library. Even if it was new code, there were significant advantages
> to creating a library then modifying it as one progressed.
> >
> > One would typically work with a bound listing or listings and work out
> the control system directives to update the existing code base. Remember,
> this was in the day of batch processing with almost no access to
> terminals. Everything happened on the keypunch.
> >
> > So for one to remember all of the correction set IDs and sequence
> numbers for a group of programs or system programs would be more than
> impressive--it'd probably merit a vivisection.
>
> ;-)
>
> I never said that I didn't / don't use references while I write code.
> It's just that I don't write my code down first. Of course most of what I
> do is new (from scratch) rather than modifying existing code.
>
> When I first started at IBM because build time for our software was about
> a week, we'd fix bugs and such with patches. Folks in the lab would stop
> looking up the instruction encodings and would just ask me...I could do the
> assembly in my head...I'm sorely out of practice now. :-/
> >
>
My first (paid) programming job was in 6800 assembler, using the Motorola
EXORCISER system. It took hours (as in a major part of a day, longer than
the work day) to reassemble the entire code base, so we would patch the
program in the PROM programmer. We would, of course, back port the changes
in symbolic assembler to the source, and every few days just take the
downtime hit to rebuild the code base. Keep in mind that this was natively
hosted on a 6800 system.
Another interesting tidbit: its simple filesystem did not segment files and
reuse blocks, so you had to purge old versions of files, preferably before
a dozen or so files were lined up after it. In that case, it would tie up
the system for way too long while an old file was purged and all the new
files were packed into the recovered space, block by block. It was barely
a step above magtape.
One other note: there was a bug in certain mask sets that required a NOP
before you could set the interrupt mask. Since the ENTIRE memory/IO space
was 64k bytes, every byte was sacred, every byte was great, and if a byte
was wasted?.
--
Ian S. King, MSIS, MSCS
Ph.D. Candidate
The Information School
University of Washington
There is an old Vulcan saying: "Only Nixon could go to China."
I was just informed that the "new manufacture" mounting brackets for the
7970E are ready. I saw them at about 90% of the fabrication process being
complete and they looked really good. Today I'm going to stop at the
hardware store and buy a set of bolts/nuts/washers that match the originals
(got them there before so I know they have the right ones) so that I can
ship each one with a baggie of the "right stuff". I will probably have them
shipped out to the people that wanted one by the end of next week-ish.
If you were one of those people that confirmed you needed one or two, please
email me your shipping address.
Best,
J
> From: Guy Sotomayor
> I'm using FRAM. They have unlimited write cycles
Although I hear the latest flash have very, very large numbers of write
cycles. But if you can get large enough FRAMs, yeah, they seem like a better
alternative.
> I didn't want to have any sort of removable media as that bring its own
> sets of challenges.
Oh well, back to loading all the bits in over a serial line (although I
suppose if one has some other removable media drive, e.g. a RX02, one could
get the bits in that way).
>> (Or perhaps even a front-end running on a PC which is connected to
>> the MEM11 over the serial line.)
> That was my original thought (command front end) but that would mean
> writing/supporting a bunch of different programs for different
> OS/platforms
Well, probably only at most two (Windoze and Linux), and maybe only one (since
there are Windows emulation packages for Linux). Although if one stuck to a
line-oriented interface, something like CygWin would allow one to have only
one version.
> and I want the MEM11 to pretty much stand on its own
Oh, I agree that that's a worthy goal - the front-end would only be to make it
'user-friendly', instead of cryptic and terse.
> the realistic limit will be on the Unibus interface ICs. I have (at
> last inventory) enough for ~25 boards. After that I'll have to see if I
> can either source additional parts or re-design that part of the board
> to use something else.
Yes, that _is_ a problem...
Noel