Picked up this core memory trainer yesterday. Seems pretty obscure.
http://imgur.com/a/TIOvt7r
Has anyone seen one before? Would love to find some documents someday.
Thanks,
Kyle
I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've
got vertical lines appearing on the screen, but not everywhere on the
screen; that seems to hint at an issue with one buffer having bad memory.
It was especially evident in the flight simulator demo, where alternating
frames flashed with and without lines.
The ever helpful self test says, "ERROR: Failure detected in the
Electronics Module (graphics). press <Enter> to continue".
The system is equipped with the ZB3 and BP4 on a GR1.2.
How can I better diagnose this issue? There are so many RAM chips soldered
on these three boards. Tracking it down to a single chip sure would be
nice.
Thanks!
Kyle
telephone? gear?
ed#
In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
Bringing up a bit of an old thread here, as I just picked up one of these
yesterday. Typed in some example programs, which took far too long thanks
to a bouncy keypad. But hey, at least it works!
Were there any real applications for the MAC-8? Haven't been able to find
much.
Thanks,
Kyle
there should be a yellow covered 8x11 manual out there if not.. let me know...
Sent from AOL Mobile Mail
On Sunday, January 13, 2019 Jason T via cctalk <silent700 at gmail.com; cctalk at classiccmp.org> wrote:
On Sun, Jan 13, 2019 at 7:47 PM ED SHARPE via cctalk
<cctalk at classiccmp.org> wrote:
>
> If any the? group? gets the? bell mac? we would love? a scan? or? hi? res? photo of that multi? colored? sheet. It? would? look? nice? printed in the? back? of? a? display? of? ? one of these units? here.We? have? 3 of these units as? I remember...? and? actually? when I? get my hands around them one? will be? up? for? grabs. Please? advise? ------Ed# SMECC
Seconded - I have one of these boards (without the fancy case) but I
have zero docs for it, save for what little is online.? The auction
seemed to have a few booklets, as well as the poster.
j
Been catching up on a backlog of scanning, grab what you like. Manuals
indicated with an asterisk are available for cost of packing+shipping
if you want something printed. This offer will expire in about a week
so please indicate interest early.
Burroughs [1]
* B2000_B3000_B4000 Work Flow Language Reference Manual Oct-1980
* B4000_B3000_B2000 Series BPL Reference Manual Jul-1978
* B4000_B3000_B2000 Series Data Management System II Users Manual Mar-1979
* B4000_B3000_B2000 Series DMS II DASDL Reference Manual May-1979
* B4000_B3000_B2000 Series DMS II Host Language Reference Manual May-1979
BJ-8-B8500 System Reference Manual May 1967
Various B6700 manufacturing documents
Burroughs TD700 manuals [2]
TD700 Central Control Schematic
TD700 Display Assembly (Head Unit) A2
TD700 Keyboard Assembly A1
TD700 Logic and Power Supply Assembly
TD700 Power Supply schematic
TD700 PW Board Assembly driver (interim)
TD700 Unit Travel Log
Misc [3]
* Freedom 220 USERS MANUAL Preliminary Edition
* Microsoft utility software package reference manual for 8080
microprocessors 8102-343-04
* The COPS Programming Manual National Semiconductor Feb 1985 [2]
* Users Manual for the VG-920 Terminal (Tentative)
* CPL is a First Aid Kit by Dr AA Grainger UTAS CC
[1] https://drive.google.com/drive/folders/1GXEU_kWWKo4btixnrQLRa5qFjZm9uqCM
[2] https://drive.google.com/open?id=1iihVNRfkd_zX_PwV30gKQTNLzLcnMEvm
[3] https://drive.google.com/drive/folders/1VEiZs1j11VPBYaZrNUaDxSpKWiZasfCC
> From: Al Kossow
> I have a source tape. I'm trying to figure out why modern tar doesn't
> understand it.
I had an issue reading some TAR's of Unix V7 stuff; I brought up an older
version of TAR under Windoze and they read fine with it. I don't recall if I
figured out what the problem was, or if I just wanted the bits, and as soon as
I had them, dropped it.
Noel
> From: Bill Gunshannon
> What about all the cross compilers that ran on PDP-11's?
Good point; by coincidence, I just found the stuff about the 68K
cross-compiler from Alcyon (in San Diego) which we used at Proteon;
it ran on an -11/73 running Ultrix.
According to the ad sheet, it also ran on VAXen, HP9000s, Textronix 8560s,
etc; OS's were various Unix flavours, VMS, VersaDOS, and Regulus.
I have the man pages for it, the assembler and linker, the c.out format it
produced, etc if those are any use/interest.
Noel
> From: Fritz Mueller
> This seems the best place to start with the LA this weekend then.
I'm going to respectfully semi-disagree! I think that at this point there's a
good chance we can localize to within a gate or two before we start applying
test instuments.
My thinking starts with two pieces of data; i) your discovery that when the
MM trap happens, the end of the pure text segment contains a fragment of code
>from 04000 lower in the text, and ii) the data that the location in main
memory where that _should_ have been is full of zeros - i.e. never been
written into.
The latter is, I think, due to the fact that Unix clears all of main memory
on startup; I think it's just chance that that memory hasn't been used yet
for something else, and is still 0's. (Unix does clear main memory in a few
places during regular operation - e.g. when expanding the stack, the newly
added area is 0'd - but in general, e.g. when swapping in a pure text, it
doesn't seem to bother, which makes sense since it's all about to be
over-written anyway.)
Anyway, those two, together with my previous analysis that this was unlikely
to have happened when the text was first being read in from the file, block
by block, lead me to believe that the likely cause is that the BAR on the
RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it
was reading the pure text back in from the swap, and skipped writing into
that zero-filled block of main memory, putting the stuff that should have
gone there up 04000, instead.
(Why it's swapping the text back in is too complicated to be worth explaining
here; anyone who _really_ wants to know should look here:
http://gunkies.org/wiki/Unix_V6_internals
in the last section, "exec() and pure-text images".)
It's easy to confirm all these suppositions/deductions fairly easily, without
having to connect up, configure, etc the LA: we can just stop the machine
after the text is first read in (in xalloc()) from the file-system, and
confirm that the text looks good there; if so, either the swap-out (albeit
unlikely, since that doesn't account for the 0's) or subsequent swap-in had
an issue. The latter would be easy to confirm: just halt the machine after
the text is swapped in, and see what the RK registers contain.
At that point, as I said, we'll know to within a few gates where the issue
is, and then it'll be time to bring out the LA.
Actually, a plain oscilloscope would do; it's interesting to recollect that
these machines were designed and maintained without benefit of a LA, purely
with an oscilloscope! We're so spoiled now! :-)
Noel
> From: Fritz Mueller
> is it possible for you deduce where Unix _should_ be placing these "bad"
> bits (from file offset octal 4220)?
Yes, it's quite simple: just add the virtual address in the code to the
physical address of the bottom of the text segment (given in UISA0). The VA
is actually 04200, though: the 04220 includes 020 to hold the a.out
header at the start of the command file.
So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
obviously an interesting number.
> Maybe a comparison of addresses where the bits should be, with
> addresses where the "bad" copy ends up, could point us at some particular
> failure modes to check in the KT11, CPU, or RK11...
Here's where it gets 'interesting'.
Executing a command with pure text on V6 is a very complicated process. The
shells fork()s a copy of itself, and does an exec() system call to overlay
the entire memory in the new process with a copy of the command (which sounds
fairly simple, at a high level) - but the code path to do the exec() with a
pure text is incredibly hairy, in detail. In particular, for a variety of
reasons, the memory of the process can get swapped in and out several times
during that. I apparently used to understand how this all worked, see this
message:
https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html
but it's so complicated it's going to take a while to really comprehend
it again. (The little grey cells are aging too, sigh...)
The interesting point is that when V6 first copies the text in from the file
holding the command (using readi(), Lions 6221 for anyone who's masochistic
enough to try and actually follow this :-), it reads it in starting from the
bottom, one disk block at a time (since in V6, files are not stored
contiguously).
So, if it starts from the bottom, and copies the wrong thing from low in the
file _up_ to VA:010200, when it later gets to VA:010200 in the file contents,
that _should_ over-write the stuff that got put there in the wrong place
_earlier_. Unless there's _another_ problem which causes that later write
to _also_ go somewhere wrong...
So, I'm not sure when this trashage is happening, but because of the above,
my _guess_ is that it's in one of the two swap operations on the text (out,
and then back in). (Although it might be interesting to look at PA:165600 and
see what's actually _there_.) Unix does swapping of pure texts in a single,
multi-block transfer (although not always as an integral number of blocks, as
we found out the hard way with the QSIC :-).
So my suspicions have now switched back to the RK11... One way to proceed
would be to stop the system after the pure text is first read in (say around
Lions 4465), and look to see what the text looks like in main memory at
_that_ point. (This will require looking at KT11 registers to see where it's
holding the text segment, first.)
If that all looks good, we'll have to figure out how to stop the system
after the pure text is read back in (which does not happen in exec(),
it's done by the normal system operation to swap in the text and data
of a process which is ready to run).
We could also stop the system after the text is swapped out, and key in
a short (~ a dozen words) program to read the text back in from the
swap device, and examine it - although we'd have to grub around in the
system a bit to figure out where it got written to. (It might be just
easier to stop it at, say, Lions 5196 and look at the arguments on the
kernel stack.)
> a suggestion here to check the KT11 address translation adders ... A
> bug in one of the carry lookahead generators used between the bit
> slices of that adder could cause a mistranslation on only a fairly
> selective subset of virtual addresses
This could be happening, but from the reasoning above about the order that
the blocks of the text are read in, something would have to interfere with
the later read of the higher memory blocks, too, no? So I'd discount the KT11
_for the moment_.
> *IF* that's the case and we can chase the IR trace upstream to the
> place of an unlucky mistranslation, it will be pretty easy to track
> down then in the hw and fix.
It'll be interesting to look at the text after it's read in (i.e. before it's
swapped out). If it's OK there, that's pretty conclusive that it _can't_ be
the KT11 - because from then on, the kernel doesn't _do anything_ to that
binary, except swap it out and in with the RK11. And since those are both
single I/O operations (with swapping on the RK11, at least, which can do
multi-block transfers), _and_ the bottom of the text segment comes in OK (so
the RK11 is being set up with correct disk and main memory addresses for both
the out and in), I can't think of a fault _elsewhere_ in the system that
could cause that 'stuff winds up in the wrong place' error.
I know this is complicated, but look at the bright side: we started with
three apparently un-connected problems:
* R5 trashage
* an 'impossible' MM fault
* bad text data
The first one turned out to be non-existent (my fault in interpreting the
kernel stack in the process core dump), the second was also not really there
(although a hardware fault in the console gave us bad data, so there really
was a hardware issue there), and now we're down to one - albeit a tricky one.
So we were dealing with two un-related hardware problems - now we're down to
one, and hopefully soon will have it isolated to a single sub-system!
(And thanks to whoever gave us the voltage tip, that fixed the first one.)
Noel
On Fri, 2019-02-08 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Re: Looking for: 68000 C compilers
There is a GNU OS for the Atari 68k-based ST, TT, and Falcon computers
which might be fun to play with. It is called MiNT. FreeMiNT and
SpareMiNT are two distros. They are available. Aranym/Afros are
current projects. Of course tools are available within.
Best regards,
Jeff
