Search results

And back up to 3.8V, with (rare) glitches up to 4.98V. So it's not really getting worse, just switching between stable levels.

I've been monitoring the machine all afternoon. For most of the afternoon the /SYS_PWR line settled down to 3.6V (with a few glitches up to 4V). I then booted from floppy and shutdown and it returned to 3.6V, but with more times at 4V. However, after a few quick cycled of sleep-wake-sleep...

I've added a 10K ohm resistor on top of R142 now as a test. /SYS_PWR is now mostly ~4V. A lot of the time the output is stable, but then there are bursts where it changes, which looks a lot like some sort of leakage from another logic line somewhere: Video of /SYS_PWR The thing is, what...

Can someone measure the resistance (in circuit) between the two sides of R142 on their machine? This should at least give me a baseline of what I should expect. (Given the logic I would think probably close to the 100K pull-up.)

Nope. I put another 100K resistor over the top (making it 50K effectively) and the voltage rose slightly. However, this means that it must be some other component dragging the line down. As far as I can see, /SYS_PWR only goes to the power manager, video chip, CPU GLU,  MISC GLU, a AC244...

I replaced both Q10 and Q11. Q10 shouldn't make any difference as it's just controlling power on the IDS connector as seems to be bypassed by as couple of diodes anyway. No change. So, I just put a 'scope on the /SYS_POWER line and it's floating very close to the 2.7V value. This would why the...

I just picked it up over the years. Most of it actually in the last few fixing old computers and reading up on-line, helped by Google. My first degree is in Geology. ;-)

Indeed, but most of the heavy lifting is being done by the 74HC154 to be honest. The GAL is just doing bus arbitration/flow control.

It's mostly electronic logic Lego really.

A slight bodge required to get it to fit in the case, using a bus extension cable... But it fits securely.

A couple of bad solder joints fixed and...

I can tweak the GAL code. Actually I've been thinking about cleaning it up a bit anyway. I think the thing is almost working. It looks like a may have a broken trace connecting the A15 line with the 240 inverter, so that might be an easy fix. I've not looked too far at the A16 issue other than...

OK, I've stably got into the debugger. It seems as if address lines A15 and A16 aren't working, so I'm going to have to check the soldering again. (0x100000 is duplicated at 0x108000 and 0x110000 but not at 0x120000) A15 goes to one of the 74AC240s and A16 to the new board.

They're mostly set up for prototyping and the small number of boards I think.

Oh, the GAL's /RAM_OE line seems to be glitching, according the logic analyser. As you can see it's sometimes logic '1' when /154_OE is logic '0' which it should never be able as they share one of their enabling conditions. It's almost as if it needs a pull-up resistor. You should never give...

Deleted erroneous result... Bad JED file.

P.P.S. Of course, /DELAY_CS was causing the device to be disabled, so no wonder it wasn't seeing the RAM. So, I've changed the GAL programming to ignore /DELAY_CS and I think it may be seeing the RAM now but it gets to a certain part of the boot process (loading System 6) and then crashes with...

It's got to be my GAL programming: No GAL: system boots. Blank GAL: system boots. Programmed GAL with A20 connected: hang. Programmed GAL with A20 disconnected: hang. This suggests the logic for the 245 is wrong as obviously the system data lines are being corrupted. Definitely time for...

I've just done a first test. No magic smoke! :-) However, the machine doesn't even start to boot. The floppy twitches once as usual and then the display comes on with random garbage but that's it. I'll have to get the logic analyser out. P.S. Swapping the original chip with my PCB...

Could it be Q11 breaking down? That's the only component I can see which controls that power rail.