exxos's Atari, Amiga & retro forum

exxos wrote: 11 Dec 2022 20:49

stween wrote: 11 Dec 2022 19:22 But between 19 (VMA) and (E), I read 0.
Is this significant, or is this normal?

That is not normal no. I think all the address lines seem OK, but VMA and E should not be shorted. But finding the short could be a problem..

Ah, hah, well I decided to check again and:

I was wrong. My multimeter reads "0.L", which I now realise is an open loop, so infinite resistance, not zero. So, no shorts at all on the bus.

Do you have AS,LDS,UDS wired to 0v when testing FC0000 ?

Plus when you are testing the address bus on the GLUE are you using your scope on the socket pins directly ? As if there is a bad socket, you won't actually know..

Also I would make sure you test the ROMx lines after reset.. I assume not, but I don't know if GLUE would disable ROMx lines on a BERR state.

But it is like the GLUE chip is faulty again.. But I think you said you tested it on another machine ?

My only other suggestion Is to remove the GLUE and touch a 0v wire on ROM0,1,2 (One at a time) and make sure ROM_CS goes low. It would double check the connections are fine and the AND-gate is working correctly.

exxos wrote: 12 Dec 2022 09:43 Do you have AS,LDS,UDS wired to 0v when testing FC0000 ?

Yup.

Plus when you are testing the address bus on the GLUE are you using your scope on the socket pins directly ? As if there is a bad socket, you won't actually know..

I'm usually going for the exposed part of the pin at the top of the socket; I figured that would at least get the path from the expansion ports, and what I read matches what I set on the bus. I can't get down to the exposed leg on the chip itself while it's in there.

Also I would make sure you test the ROMx lines after reset.. I assume not, but I don't know if GLUE would disable ROMx lines on a BERR state.

But it is like the GLUE chip is faulty again.. But I think you said you tested it on another machine ?

Yeah, I have this and a spare GLUE. I just tried for my own sanity, and both boot another TOS 1.4 STFM to desktop.

I've put the other GLUE into the H5 board and it shows the same symptoms.

My only other suggestion Is to remove the GLUE and touch a 0v wire on ROM0,1,2 (One at a time) and make sure ROM_CS goes low. It would double check the connections are fine and the AND-gate is working correctly.

Yeah that works. Touching the ROM0/1/2 legs on the top of the socket makes ROM_CE go low on the pin on the TOS socket.

It's very perplexing.There is nothing wrong exactly ,and yet it doesn't boot. GLUE just refuses to decode ROM space.

Do you have any of my TOS decoder boards ?

I wonder if the socket is bad. They are all 3M brands if you got them pre-fitted.

Try placing many 2 or 3 layers of cornflakes box card inside the GLUE socket to lift the IC up a bit..

exxos wrote: 13 Dec 2022 09:56 It's very perplexing.There is nothing wrong exactly ,and yet it doesn't boot. GLUE just refuses to decode ROM space.

Do you have any of my TOS decoder boards ?

Nope. Should I grab one and try TOS2.06?

I wonder if the socket is bad. They are all 3M brands if you got them pre-fitted.

Yeah, pre-fitted. I'll probably spend some time focussing on that socket, looking for shorts and the correct connectivity.

Try placing many 2 or 3 layers of cornflakes box card inside the GLUE socket to lift the IC up a bit..

Ah! Good idea :D

I'll be out of town from before christmas until after new year, so I don't think I'll land this before 2023. Even if this one never flies, I've learned a ton about how the system hangs together, so it's not a lost cause :)

stween wrote: 13 Dec 2022 16:04 Nope. Should I grab one and try TOS2.06?

If you don't have one already then I would not bother at this point..

I'll be out of town from before christmas until after new year, so I don't think I'll land this before 2023. Even if this one never flies, I've learned a ton about how the system hangs together, so it's not a lost cause :)

Certainly very perplexing to say the least.This is why I don't tend to bother repairing machines because it never ends :lol: :roll: Not exactly so simple with a H5 though. Is rather ironic that the H5 should be the simplest machine to get running out of all other boards and yet people seem to have the most problems with it somehow :shrug: Only problems I ever had was a couple of large SMT caps shorted out.

anyway, I would also remove the DMA and MFP just in case they are causing anything to go wonky with the GLUE.

exxos wrote: 13 Dec 2022 16:13anyway, I would also remove the DMA and MFP just in case they are causing anything to go wonky with the GLUE.

What's the minimum set of chips for a bootable machine?

stween wrote: 13 Dec 2022 16:18 What's the minimum set of chips for a bootable machine?

You need them all really. If something is missing, TOS won't boot fully.

At this point I'm just trying to figure out if some chip on the board is telling GLUE not to decode ROM address for some reason. But that is getting outside my area of expertise at this point. I can only really think that the CPU,MFP,DMA might be sending out signals to the GLUE confusing it. But it is only a guess /speculation.

But even going back to this...

stween wrote: 11 Dec 2022 04:53
When selecting address 0xfc0000:

• on the glue, all ROM pins are high
• BERR is bouncing high/low pretty consistently at around 62kHz
• DTACK is low
• AS is low
• on TOS, ROM_CE is high
• data lines all high

Why does GLUE issue DTACK if the address is invalid and its not decoding ROM space. But this condition I have not actually tried on a working machine. So I assume the DTACK should be high at this point.

If you remove the GLUE does DTACK go high ?

exxos wrote: 13 Dec 2022 16:30Why does GLUE issue DTACK if the address is invalid and its not decoding ROM space. But this condition I have not actually tried on a working machine. So I assume the DTACK should be high at this point.

If you remove the GLUE does DTACK go high ?

A quick check between festive tasks: with no glue, no CPU, address fc0000: DTACK is low.

(Poking a few extra pins on the exposed socket: BERR is high; AS and the ROM lines all read low.)