Dead TT030 Repair

[frank.lukas]

If the additional RAM board does not go down properly into the VG socket strip on the mainboard, some signals will not have/make contact. The two brass bolts must be properly seated or removed it as a test ...?

[grunwald]

Frank... I have deoxed and toned every line, on both connectors, back to their respective chips. I am fairly certain that the connectors on the board and memory card, are not the issue.

20240728_130454.jpg

[pakman]

It seems we have to look deeper into the configuration..

When attempting to boot into the cartridge with the board in and jumpers set, BNK5 cycles high and low producing the I5 error as shown prior.

BNK5 is toggling high and low? Which one? I am wondering.. since BNK5 is supposed to be an input for the MCU (see below).

Does anyone know how Configuration Register at FF8000 interacts with the BNK5/SEL lines to shift memory banks?

I don't know about the test cartrige, but here is what happens when booting TOS:
At first TOS is testing, whether 8x 1MEG or 8x 256K parts are installed. With 2MB (8x 256K parts) on both mainboard and extension board the CONFIG bit becomes 0, which will be written into both MCUs in parallel via pin 58.

The setting for the mainboard MCU will become:
- CONFIG = 0
- SEL = 0 (hardwired to GND)
- BNK5 = 1 (1k2 pullup, W2 on the extension board open)
Responding RAM address = xx000000 to xx1FFFFF

The setting for the extension board MCU will become:
- CONFIG = 0 (same for both MCUs)
- SEL = 1 (hardwired to VCC)
- BNK5 = 1 (jumpered to VCC via W1 1-2 on the extension board)
Responding RAM address = xx200000 to xx3FFFFF

I read that the onboard memory is shifted up top and replaced in low memory by the 2mb board when it is installed. Anyone know how this is facilitated and what hardware is impacted?

When installing an 8MB extension board, things will change:

The setting for the mainboard MCU will become:
- CONFIG = 1
- SEL = 0 (hardwired to GND)
- BNK5 = 0 (jumpered to GND via W2 2-3 on the extension board)
Responding RAM address = xx800000 to xx9FFFFF

The setting for the extension board MCU will become:
- CONFIG = 1 (same for both MCUs)
- SEL = 1 (hardwired to VCC)
- BNK5 = 0 (jumpered to GND via W1 2-3 on the extension board)
Responding RAM address = xx000000 to xx7FFFFF

[grunwald]

Thanks for the response! I will hook up the LA tonight and validate the SEL and BANK5 lines with a 2mg and a 8mg card, with and w/o the cartridge. I believe my previous comment about BANK5 cycling was caused by the system continually rebooting with the mem card jumper on, and the cartridge in.

[grunwald]

Got in late tonight so not much time to play... I checked the BANK5 line to the onboard MMU when booting without the cartridge. It took quite a few cycles for it to pull up and stabilize. This was with the 2mb board installed, jumping W1, 1-2. I checked RP100 for the pullup and it's right at 1.2k. I need to hook up the entire bus to see where it's at when it goes stable. I've attached the whole run.

BANK5
45 | 0
46 | 0
47 | 0
48 | 0
49 | 0
50 | 0
51 | 0
52 | 0
53 | 0
54 | 1
55 | 0
56 | 0
57 | 1
58 | 0
59 | 0
60 | 1
61 | 0
62 | 0
63 | 1
64 | 0
65 | 1
66 | 0
67 | 0
68 | 1
69 | 0
70 | 1
71 | 0
72 | 1
73 | 0
74 | 1
75 | 1
76 | 1
77 | 1
78 | 1
79 | 1

[grunwald]

I've been out of town for work so have not had time to continue troubleshooting the issue. What I did manage to do was trace the startup code on my LA and confirm that the memory board is being identified correctly during bootup. Memconf for the TT is as follows:


/* =========================================================================== */
/* ==== memconf for TT ======================================================= */
/* =========================================================================== */
/*
* The following configurations are valid for ST-RAM in a TT, listed as
* total RAM (motherboard RAM + optional daughterboard RAM):
* 2MB (2MB + 0MB), 4MB (2MB + 2MB), 10MB (2MB + 8MB)
* [According to the TT rev B MCU functional description, it is also
* possible to have 8MB (8MB + 0MB) and 10MB (8MB + 2MB) configurations,
* but I have not seen this.] When an 8MB board is present, it is always
* mapped to the first 8MB of memory.
*
* Systems with only 2MB boards require a memcntlr value of 0x05; systems
* with an 8MB board require a memcntlr value of 0x0a. We detect which
* size of board is in low memory by assuming an 8MB board, then checking
* for different memory addresses mapping to the same physical address.
*
* rfb (sep/2016)
*/
move.w #$0005,d6 /* assume 2MB board */
move.b #$0A,(memconf).w /* set memory controller for 8MB */
moveq.l #0,d0
move.l d0,($00001008).w /* zero out test addresses */
move.l d0,($0000100C).w
move.l #$06161964,d0 /* write test value #1 to an address */
move.l d0,($00000008).w /* that may be mapped into test address #1 */
cmp.l ($00001008).w,d0 /* did test address #1 get updated? */
bne.s set_8MB /* no, must be an 8MB board */
move.l #$04251987,d0 /* yes, repeat with test value #2 to be sure */
move.l d0,($0000000C).w /* did test address #2 get updated? */
cmp.l ($0000100C).w,d0 /* yes, use the 2MB memcntlr value */
beq.s set_2MB
set_8MB:
move.w #$000A,d6 /* set 8MB memcntlr value */
set_2MB:
move.b d6,(memconf).w /* update memcntlr */
#endif




I was able to run it with both a 2mb board and a 8mb board. The 8mb run resulted in line 264 = FFFF8001 0AOAOA0A. The following was with the 2mb board. BANK5 and the SEL lines are working correctly.



225 00E0011C 21C01008 1 1
226 FFFF8001 0A0A0A0A 1 1
227 00E00120 0A0A0A0A 1 1
228 00E00120 21C0100C 1 1
229 00001008 00000000 1 1
230 00001008 00000000 1 1
231 00001008 00000000 1 1
232 00E00124 20FFFFFF 1 1
233 00E00124 203C0616 1 1
234 0000100C 00000000 1 1
235 0000100C 00000000 1 1
236 00E00128 19FFFFFF 1 1
237 00E00128 196421C0 1 1
238 00E0012C 19FFFFFF 1 1
239 00E0012C 0008B0B8 1 1
240 00E00130 18FFFFFF 1 1
241 00000008 06161964 1 1
242 00000008 06161964 1 1
243 00000008 06161964 1 1
244 00001008 06161964 1 1
245 00001008 06161964 1 1
246 00E00134 26FF9FFF 1 1
247 00E00134 203C0425 1 1
248 00E00138 39FFFFFF 1 1
249 00E00138 198721C0 1 1
250 00E0013C 19FFFDFF 1 1
251 00E0013C 000CB0B8 1 1
252 00E00140 18FFFFFF 1 1
253 0000000C 04251987 1 1
254 0000000C 04251987 1 1
255 0000000C 04251987 1 1
256 0000100C 04251987 1 1
257 0000100C 04251987 1 1
258 00E00144 3CFFFFFF 1 1
259 00E00144 3C3C000A 1 1
260 00E00148 3FFFFFFF 1 1
261 00E0014C 11C68001 1 1
262 00E0014C 5FFFFFFF 1 1
263 00E0014C 4FF90000 1 1
264 FFFF8001 05050505 1 1
265 00E00150 05050505 1 1
266 00E00150 80002878 1 1


I will need to trigger the trace further along in order to catch where the error occurs. My old LA does not have the memory to pull the whole boot process. More to come.

[pakman]

Nothing strange so far.

I suggest to verify continuity of the signals at the ST-RAM connector once again, but this time with the ST-RAM extension board installed!
So the continuity measurement goes from the solder pad of the ST-RAM connector at the extension board to respective counterparts as listed below:

Check continuity from ST-RAM connector on the extension board to TT-RAM connector:
A0..A31
D0..D10 (goes to TT-RAM connector D16..D26)
FC0..FC2
SIZ0, SIZ1
XAS, XDS, XRW

Check continuity from ST-RAM connector on the extension board to other ICs:
XDS0 U116B (74F74) pin 12, or FPU pin 31
XDS1 U116A (74F74) pin 2, or FPU pin 32
RDY U408 (DMA Chip) pin 38
XBR U100 (68030) pin 1
XBG U100 (68030) pin 15
XBGA U100 (68030) pin 29

With the TT powered on, check
- CLK2, CLK16 for proper clock signals
- HSYNC, VSYNC, DE for activity

[grunwald]

I had a little time this evening to run the following tests:

Check continuity from ST-RAM connector on the extension board to TT-RAM connector:
A0..A31 - All lines tone out properly
D0..D10 (goes to TT-RAM connector D16..D26) - All Data lines also tone out properly
FC0..FC2 - Good
SIZ0, SIZ1 - Good
XAS, XDS, XRW - Good

Check continuity from ST-RAM connector on the extension board to other ICs:
XDS0 U116B (74F74) pin 12, or FPU pin 31 - Good
XDS1 U116A (74F74) pin 2, or FPU pin 32 - Good
RDY U408 (DMA Chip) pin 38 - Good to DMA Pin #41 per schematic
XBR U100 (68030) pin 1 - Good to PIN #20 per schematic
XBG U100 (68030) pin 15 - Good to pin #16 per schematic
XBGA U100 (68030) pin 29 - Good to pin #17 per schematic

With the TT powered on, check
- CLK2, CLK16 for proper clock signals

CLK2

Clock2.jpg

CLK16

Clock16.jpg

DE

DE.jpg

HSYNC

horzsync.jpg

VSYNC

vertsync.jpg

[pakman]

Ok, that all looks fine.

Back to YARTTT. What we can learn from 300_301er.txt so far:

1. The erratic output beyond address 0x00300ea6 is strange. It seems the memory space used by YARTTT (program and data) is somehow messed up during the test. Anyhow, this memory space is located in ST-RAM on the mainboard, and should not be affected by the test itself, which takes place on the memory space located on the extension board.

2. Reading from the extension board always shows 0xFFFF on D0..D15 (unfortunately we don't know about D16..D31). This is not enough information to draw conclusions.

Please try YARTTT again, this time with a smaller address range from 0x00300e90 to 0x00301010.
If YARTTT encounters the erratic output again, use an even smaller address range from 0x00300000 to 0x00300020.
I would like to see more tests results other than test #1, hopefully to have results from one full test pass at least.

[grunwald]

Been out of town for work almost every week for the last two months. I will likely get back to this project sometime next month. Thanks for the help!