IDISP and ACSOURCE branches

Juergen Buchmueller pullmoll at t-online.de
Mon Jun 25 15:50:31 PDT 2007


I finally found out how to descramble the BPROM 2kctl.u3, which is
responsible for the branches that are in the Emulator IDISP and ACSOURCE
late functions for all cases except the arithmetic opcodes, i.e. for all
branches where IR[0] is 0.

Here's the comment I wrote about this section of the schematics:

/**
 * @brief 2k control PROM u3 - 256x4
 *
 * PROM u3 is 256x4 type 3601-1, looks like SN74387, and it
 * controls NEXT[6-9]', i.e. the outputs are wire-AND to NEXT
 *
 *           SN74387
 *         +---+-+---+
 *    A6  -|1  +-+ 16|-  Vcc
 *    A5  -|2      15|-  A7
 *    A4  -|3      14|-  FE1'
 *    A3  -|4      13|-  FE2'
 *    A0  -|5      12|-  D0
 *    A1  -|6      11|-  D1
 *    A2  -|7      10|-  D2
 *   GND  -|8       9|-  D3
 *         +---------+
 *
 *
 * It is enabled whenever the Emulator task is active and:
 *	both F2[0] and F[1] are 1	F2 functions 014, 015, 016, 017
 *	F2=14 is 0			not for F2 = 14 (load IR<-)
 *	IR[0] is 0			not for arithmetic group
 *
 * This means it controls the F2 functions 015:IDISP<- and 016:<-ACSOURCE
 *
 * Its address lines are:
 *	line	pin		connected to		load as
 *	-------------------------------------------------------------------
 *	A0	5		F2[2] (i.e. MIR[18])	IR[07]
 *	A1	6		IR[01]			IR[06]
 *	A2	7		IR[02]			IR[05]
 *	A3	4		IR[03]			IR[04]
 *	A4	3		IR[04]			IR[03]
 *	A5	2		IR[05]			IR[02]
 *	A6	1		IR[06]			IR[01]
 *	A7	15		IR[07]			F2[2]
 *
 * Its data lines are:
 *	line	pin		connected to		load as
 *	-------------------------------------------------------------------
 *	D3	9		NEXT[06]'		NEXT[06]
 *	D2	10		NEXT[07]'		NEXT[07]
 *	D1	11		NEXT[08]'		NEXT[08]
 *	D0	12		NEXT[09]'		NEXT[09]
 * 
 * Its address lines are reversed at load time to make it easier to
 * access it. Also both, address and data lines, are inverted.
 *
 * 0000: 000,000,013,016,012,016,014,016,000,001,013,016,012,016,016,016,
 * 0020: 010,001,013,016,012,016,015,016,010,001,013,016,012,016,017,016,
 * 0040: 004,001,013,017,012,017,014,017,004,001,013,017,012,017,016,017,
 * 0060: 014,001,013,017,012,017,015,017,014,001,013,017,012,017,017,017,
 * 0100: 002,001,013,016,012,016,014,016,002,001,013,016,012,016,016,016,
 * 0120: 012,001,013,016,012,016,015,016,012,001,013,016,012,016,017,016,
 * 0140: 006,001,013,017,012,017,014,017,006,013,013,017,012,017,016,017,
 * 0160: 017,001,013,017,012,017,015,017,017,001,013,017,012,017,017,017,
 * 0200: 011,001,013,016,012,016,014,016,011,016,013,016,012,016,016,016,
 * 0220: 001,001,013,016,012,016,015,016,001,001,013,016,012,016,017,016,
 * 0240: 005,001,013,017,012,017,014,017,005,013,013,017,012,017,016,017,
 * 0260: 015,001,013,017,012,017,015,017,015,014,013,017,012,017,017,017,
 * 0300: 003,001,013,016,012,016,014,016,003,001,013,016,012,016,016,016,
 * 0320: 013,001,013,016,012,016,015,016,013,001,013,016,012,016,017,016,
 * 0340: 007,001,013,017,012,017,014,017,007,001,013,017,012,017,016,017,
 * 0360: 016,001,013,017,012,017,015,017,016,015,013,017,012,017,017,017
 */

After the address line reversal and address and data line inverting, it
looks like this:

PROM: 2kctl.u3 (256x4)
0000: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0020: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0040: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0060: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0100: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0120: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0140: 002 016 003 016 016 016 016 016 016 004 004 016 016 016 001 016
0160: 016 016 016 016 016 016 016 016 016 016 016 016 016 016 016 017
0200: 000 000 000 000 000 000 000 000 001 001 001 001 001 001 001 001
0220: 002 002 002 002 002 002 002 002 003 003 003 003 003 003 003 003
0240: 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004
0260: 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004
0300: 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
0320: 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
0340: 001 000 002 003 004 005 016 007 010 011 012 013 014 015 006 017
0360: 001 000 002 003 004 005 016 007 010 011 012 013 014 015 006 017

Now for the funny part. I hacked up some code to turn the current
implementation of the F2s idisp and acsource of Altogether, and also Salto,
back into the table format, and then into the PROM format. There are three
differences in both outputs, Altogether and Salto, compared against the
PROM. They're marked with an asterisk instead of the first 0 digit.

branch PROM 2kctl.u3 according to Altogether and SALTO.
(table)
0000: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0020: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0040: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0060: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0100: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0120: 000 000 000 000 001 001 001 001 000 000 000 000 001 001 001 001
0140: 002 *05 003 *06 *07 016 016 016 016 004 004 016 016 016 001 016
0160: 016 016 016 016 016 016 016 016 016 016 016 016 016 016 016 017
0200: 000 000 000 000 000 000 000 000 001 001 001 001 001 001 001 001
0220: 002 002 002 002 002 002 002 002 003 003 003 003 003 003 003 003
0240: 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004
0260: 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004 004
0300: 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
0320: 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
0340: 001 000 002 003 004 005 016 007 010 011 012 013 014 015 006 017
0360: 001 000 002 003 004 005 016 007 010 011 012 013 014 015 006 017

(PROM)
0000: 000 000 013 016 012 016 014 016 000 001 013 016 012 016 016 016
0020: 010 001 013 016 012 016 015 016 010 001 013 016 012 016 017 016
0040: 004 001 013 017 012 017 014 017 004 001 013 017 012 017 016 017
0060: 014 001 013 017 012 017 015 017 014 *11 013 017 012 017 017 017
0100: 002 001 013 016 012 016 014 016 002 001 013 016 012 016 016 016
0120: 012 001 013 016 012 016 015 016 012 001 013 016 012 016 017 016
0140: 006 001 013 017 012 017 014 017 006 013 013 017 012 017 016 017
0160: 017 001 013 017 012 017 015 017 017 *12 013 017 012 017 017 017
0200: 011 001 013 016 012 016 014 016 011 016 013 016 012 016 016 016
0220: 001 001 013 016 012 016 015 016 001 001 013 016 012 016 017 016
0240: 005 001 013 017 012 017 014 017 005 013 013 017 012 017 016 017
0260: 015 001 013 017 012 017 015 017 015 014 013 017 012 017 017 017
0300: 003 001 013 016 012 016 014 016 003 001 013 016 012 016 016 016
0320: 013 001 013 016 012 016 015 016 013 *10 013 016 012 016 017 016
0340: 007 001 013 017 012 017 014 017 007 001 013 017 012 017 016 017
0360: 016 001 013 017 012 017 015 017 016 015 013 017 012 017 017 017

Now I'm wondering if either the documentation of the IDISP and ACSOURCE is
wrong, or at least no longer valid for the AltoII where this PROM dump comes
from, or if the PROM dump was bad in these three locations?

It looks like these could be the 'if' lines for the RAMTRAPs of ACSOURCE,
where IR [3-5] is 1, 3 or 4. So it may well be the microcode is just
handling them all in one section... there's always the same value for the
tree addresses in the dumped PROM.


More information about the Altogether-devel mailing list