> From: Paul Birkel
> Unfortunately there's not much documentation for the MS11.
??? We're actually pretty well off, there; we have:
- MS11 Maintenance Manual (DEC-11-HMSAA-D-D)
- MS11 MOS Memory Troubleshooting Guide (DEC-11-HMSTS-A-D)
- MS11-B Engineering Drawings
About all we're missing are the MS11-A/C data board engineering drawings.
(The control board is in the MS11-B prints.)
> From: Mattis Lind
> This could mean that 16 bit data is in the L chips while the faster
> chips are used for a 10 bit cache tag.
Sounds plausible.
> And of course those two I/O connectors don't belong on a cache.
> ...
> Those IO connectors are connected to two double height boards in 26 /27
> AB. They are also made by ACT and contain a few TTL chips.
If the board is a cache, how does it get filled? It would have to listen to
the UNIBUS the memory is on. So I'm guessing that's that those connectors and
boards are for.
Note that there has to be a signal from FastBus (anyone know the correct
capitalization for that?) which tells the CPU if the MS11 has a given address
or not (given the way the MS11 can be configured as to size and address), so
the cache board could use that line to tell the CPU whether or not the
location in question is in the cache.
Noel
Is there ANY interest in Courier 56K V.92 modems?
Laserjet IIP printers?
Parallel port and/or SCSI flatbed scanners? (home office, NOT
professional)
Oversized PC cases with MANY drive bays?
Generic 386? PCs?
Is it worth even hauling that kinda stuff to VCF?
How feasable is it to compile and run SDL for SunOS? My main reason for
doing this is to play Z-machine games on Sparcstations using Frotz
(https://gitlab.com/DavidGriffith/frotz) using the SDL interface to play
V6 games.
--
David Griffith
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Does somebody know how to set the IACK and BG backplane jumpers for the MVME188 CPU? Remove them all? Leave them in behind the memory and/or cpu board(s)? Something else? All the documentation I can find are for the normal VME SBCs, which the 188 isn't.
Thanks!
ok
bear.
--
until further notice
> Message: 1
> Date: Sun, 22 Jul 2018 09:22:25 -0400 (EDT)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: Strange third party board in PDP-11/45
> Message-ID: <20180722132225.49A0B18C096 at mercury.lcs.mit.edu>
>
> > From: Paul Birkel
>
> > ABLE Computer Technology. Their first product was PN 10001 ... the
> > A.C.T. Univerter
>
> This board is not shown in any of the Able brochures we have:
>
> http://bitsavers.trailing-edge.com/pdf/able/brochures/
>
> However, Able info is _very_ thin on the ground, now...
>
> Noel
There was a Univerter and Qniverter (sp) which were used to
translate from unibus to qbus.Very useful boards and used one
to translate from vax730, vms 4.3 to a qbus expansion box, so
I could use an RQDX3 and RD53 as vms boot. Just set up the
dipswitches and it works automagically at power on.
May have docs somewhere, but not sure where...
Chris
I have been recovering dozens of old Tektronix 4050 series tapes and found
one with Fast Graphics software for the 4051. This software program jumped
into 6800 assembly code and retrieved three bytes per vector from a tape
file. Apparently this tape is a duplicate - and it appears that all the
files bigger than 1KB have corrupt data.
Apparently from the 4014 programmers guide - they had a set of demo picture
files including a list with R2-D2.
I have found Jos Dreesen's ftp tar file with some 4014 pictures - but I'm
looking for an R2-D2 picture file that is on the tape I have but corrupt.
I also discovered that Tektronix made a 4052/4054 R12 Graphics Enhancement
ROM pack which included the Fast Graphics program in ROM. I would love to
find one of those ROM packs - hint/hint :)
I did recover one of the shorter picture files of Snoopy - but since I
don't have a 4051, I can't run the Fast Graphics program on my 4052 or
4054. One of my buddies threw a C program together to convert the data
file into Tek 4050 PRINT statements.
I've posted the SNOOPY basic program and screenshots of running it on vcfed
in a new thread:
http://www.vcfed.org/forum/showthread.php?64726-Tektronix-4051-4052-4052A-4…
I'm also still looking for a 4051/4052 Display Board. Mike Haas posted
pictures here in Oct 2016 of lots of Tektronix boards including a Display
Board - but I don't have any direct contact info for him.
Monty
Greetings to the List -
Carlo, I have been using IDE68K out of Norway for about five years
and it is excellent: http://home.kpn.nl/pj.fondse/ide68k/
It includes the 68020 instructions such as bit instructions etc -
also floating point.
I only use the assembler and download S-records to the MVME177-005
boards that I use.
I have never found any bugs etc.
Best,
Jack
At 12:46 PM 7/20/2018, Carlo Pisani via cctalk wrote:
>hi
>does anyone happen to use Avocet Development Tools for m68k?
>how good/bad is it?
----------------------------------------------------------------------------------
Jack Harper, President
Secure Outcomes Inc
2942 Evergreen Parkway, Suite 300
Evergreen, Colorado 80439 USA
303.670.8375
303.670.3750 (fax)
http://www.secureoutcomes.net for Product Info.
>
> I have a lot of backup here stored in CDs, and I have recently bought
> an SCSI DVDRAM unit to create new backups in caddies DVD-RAMs (of
> 4.2Gbyte each)
what is your experience?
I recently disposed of a couple hundred DVD and CD backups I'd made. As
mentioned in a previous comment, it's simply too impractical to store
terabytes of information in 4.7GB segments, plus they take up a LOT of
space. HDDs aren't the most reliable, but this is what I use now for that
reason. I make sure to keep the previous backup in case something happens.
I'll only use optical backups now with the most important data.
Backblaze has some interesting stats regarding HDD reliability (they are a
data center using thousands of drives running constantly):
https://www.backblaze.com/blog/hard-drive-stats-for-q1-2018/
As noted previously, beyond storage conditions, disc longevity depends on
the types of dyes used in the discs. Gold is supposed to be best. Early on,
they experimented with a wide variety of dye types, and the silver dyes
were least reliable, oxidizing in only about 10 years.
The thing is, no media format is going to last forever. The only really
reliable way of keeping data around is multiple backups and data migration.
Basically, for your really important stuff, you'll want a couple of
backups, stored in different geographical locations (one local, one on
cloud works, too). You'll want to periodically refresh the backups by
migrating the data onto fresh media.
In the preservation business, the ideal is to refresh after the cost of
storage media is 1/2 of the initial investment. So, if you paid $1 a GB for
the initial storage media, you'll want to migrate once the new format is
$0.50 a GB, and then again when it is $0.25 and so on. This way, the total
cost is double what you initially invested.
Of course, while the cost per GB might drop steadily, the total amount on a
particular media format will increase as well, such that the $150 HDD you
bought 5 years ago will have twice the storage for...$150. Definitely open
to other suggestions.