> From: Douglas Taylor
> Sure is nice looking and expensive...
I can't figure out if that price ($5K) is reasonable or not. I have
previously dealt with that seller on another item, a dead/banged-up 11/05
that another list member wound up buying; the seller's asking price on that
was a little high (based on the average of sales since then for that class of
machine), but not an integral factor high, as often seen on eBay (or an order
of magnitude high, also to be seen on eBay).
My guess, given how rare they are now, the fact that it's complete (including
all cables - often cut/removed), etc, etc is that this is once again in the
ballpark, if on the high end. Am I confused?
Noel
> From: Evan Koblentz
> Hackaday sponsored our Friday "VCF East University" classes and they
> wrote many articles about us before, during, and after the show:
Apparently Christopher Parish's RL02<->USB adapter went viral, e.g.:
http://www.techspot.com/news/60442-world-largest-usb-thumb-drive-has-10mb-s…
Noel
> from what I've seen so far, the code tends to loop on error, not halt.
So I lied: it turns out that some of the later tests (in the extended tests -
JSR, memory) do in fact halt on error.
I realize it's not needed immediately now (Josh having solved his problem),
but I've got the low part (diagnostics and TA11 boot) done, working on the
top part now. Here's what I have so far:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/M9301-YA.mac
I haven't densely commented the CPU tests as they seemed, at first glance,
pretty non-complicated. The memory diagnostics are pretty inscrutable, I
don't really understand them yet (may not bother).
The top part (console and othr boots) - hoo boy, talk about 'sphagetti
code'!! I think there's a picture of this in the dictionary when you look
that term up. Very, very ugly code. That part may take a while...
Noel
> From: Charles Dickman
> You can find a dump and partial disassembly
So I decided, just for grins (this may be duplicative of what's on a fiche
somewhere) to complete the disassembly, and there was something that was
puzzling me.
There a bunch of entry points (for auto-booting from different devices) which
all are of the form:
BR foo
where foo is the same location. The code doesn't save anything before the
branch, it just does it right off. So how does it know, when it gets there,
which entry point was used?
Well, it turns out that the answer, I am pretty sure, is that with the M9312,
location 773024 is even more magic than it first appears.
(Slight digression, for those who didn't get the reference: the way the M9312
forces the 11/04 or /34 CPU into the ROM, on power-fail or manual restart, is
that when the CPU tries to fetch the PC/PS pair from location 024 - the
power-fail/restart vector - the card jams the high UNIBUS address lines to
773000 for two bus cycles, directing the fetch of the new PC/PS to locations
773024-6. Next, when the CPU fetches the contents of location 773024, the
basic contents of that location, in the ROM - 173000 - are or'd with switch
S1-3 (bit 8, 4xx) through S1-10 (bit 1, 2). So that's how the code jumps to
different entry points, based on the contents of S1.)
However, from reading the code (yet to verify this on prints, but it _has_ to
work this way, the code doesn't make any sense otherwise), it appears that
_any_ reference to location 773024, at _any time_, produces the contents of
ROM location 773024 or'd with the contents of switch S1!!
In other words, location 773024 is effectively a hacky register that allows
S1 to be read. (And the M9312 Maint Manual does _not_ make this clear. It
talks about how the contents are modified during the power-on PC/PS fetch
cycle, but _not_ about the later references part.)
Very clever, though!
Noel
PS: Josh, from what I've seen so far, the code tends to loop on error, not
halt. So if your machine's halting...
While turning out my attic I unearthed obsolete *discs for a 1980s
Amstrad computer *which has long been disposed of. One disc is, as far
as I know, in mint condition but a further twelve contain programmes.
Another six discs contain long forgotten person data which I can't
access. I am intrigued to know what they contain. Also in my searches
I have found a *Microsoft Works manual* complete with system discs, and
an *Amstrad user's manual*. Also about a*dozen 5" discs* containing
stock records of warehouse long demolished. Again, I am curious to see
what I recorded 30 years ago.
I am reluctant to consign these items to the dustbin if a) the discs can
be deciphered, and b) they are are of use to someone else. Your
organisation has been suggested as a possible home for at least some of
these items. Are they of interest? If not, do you know any
organisation that might be?
R.J. Rickard.
Edinburgh.
For those that might be interested
http://www.classic-computers.org.nz/blog/2015-04-28-recap-se30.htm
I guess a lot more classic computer enthusiasts will be doing SMD work for
repair in the future as "vintage computing" starts to encompasses machines
>from the 1990s.
Terry (Tez)
The 11/34 seems to be pretty healthy, I've punched in some code to do
some basic testing and the CPU seems to be capable of running simple
programs and the RAM seems capable of holding data. So that's good.
I've also verified that the console SLU is at the right address and
vector (it wasn't initially, due to a pair of bad DIP switch blocks),
and I can read/write characters from/to it. Huzzah.
The bootstrap ROM doesn't seem to be executing properly, however. After
power-on or a BOOT/CTRL It'll run for a fraction of a second and then
halt, leaving me at address 0 with 161721 displayed. ROM Data appears
at the expected addresses (773000-773777, 765000-765777) but I don't
know if it's at all correct.
I need to scare up a second SLU so I can get an emulated TU-58 hooked up
to try booting XXDP, but in the meantime I thought I'd see if I could
verify the ROM contents manually (it's only 512 bytes long). I can't
find a listing, however -- the operator / maintenance manual doesn't
contain it and I haven't found it anywhere else. I've found a reference
to a microfiche, "EP-M9301-RL-A" that supposedly contains these
listings, but it doesn't appear to be archived anywhere. Anyone have
this, or have dumps of the M9301-YB PROMs?
Thanks,
Josh
I have not seen an IMSAI except for photos, so I'm guessing here - I suspect the finish it has is a spatter or blobby texture?
If that is the case why not ask on a Board where people know all about such things. A bit of googling found this one which has
amongst others a 'Specialty Coatings' and a 'Commercial and Industrial Painting' forum:
http://www.painttalk.com
I'm sure they could figure it out if a close-up photo was posted.
Steve.
---------------------------- Original Message ----------------------------
Subject: RE: IMSAI chassis color/texture...
From: "Bill Sudbrink" <wh.sudbrink at verizon.net>
Date: Sat, April 25, 2015 12:50 am
To: "'General Discussion: On-Topic Posts'" <cctech at classiccmp.org>
--------------------------------------------------------------------------
> Al Kossow wrote
>> On 4/24/15 1:22 AM, Philip Lord wrote:
>> > https://365pantone.wordpress.com/2013/12/02/pantone-7690/
>> >
>>
>> It's not the color so much as correctly duplicating the texture.
>
> Exactly. I'm talking with a couple of local (to me) paint shops.
> They all have high tech color scanning and can scan my good chassis
> for the color. The debate over whether the texture was accomplished
> by some kind of powder coating or air brushing is the big thing. The
> original documentation talks about "IBM Blue" which is also a pantone
> color. Neither look "right" to me... on my computer screen anyway.
> I have not seen an actual paint chip.
>
> Bill S.
>
>
>
>
