ZX Spectrum 48k reboot loop

[CC911]

hi there,
I bought my first spectrum 38 years ago from my first earned money.
now a bought a NOS issue 3b (the board says issue 4???) on ebay.
the first time I powered it up it showed the copyright message.
After i hit a key it didn't work. from that moment on it tries to reboot
in a loop but never get's to the copyright.
I already recapped al the blue Cs. the voltages are all fine according to
the service manual. I exchanged TR6 same behaviour.
maybe someone can push me in the right direction?
thanks in advance,

christoph



recapped




original






first startup

[Ast A. Moore]

It would be great if you could post a video of the “reboot loop.” Ideally, from a cold start.

[1024MAK]

Not always, but often a 48K machine looping at startup is often due to a upper memory fault (one or more DRAM chips are faulty).

Mark

[CC911]

thanks for answering.

here's the video:
https://youtu.be/fJg4GdVgW18

I already tested with upper ram disabled,
same thing.
what I have to mention: C1 was only soldered on one side,
fixed this.

thanks,
christoph

[HappyLittleDiodes]

How did you disable upper RAM?

[1024MAK]

If you watch the video, you can see that in the black area there are thin vertical red lines. This is the result of the ROM code testing to see how much RAM is available.

So it is likely that the ULA, Z80 and ROM are fine, as all of them appear to be working. However there could still be a problem with a partial fault with the Z80 or the ROM.

The most unreliable parts in a ZX Spectrum are the 4116 (or equivalent) DRAM chips used to make up the ‘lower’ RAM.

On power up, or reset, or whenever the Z80 executes code from ROM memory location 0 (0x0000), the code in the ROM sets the border to white, it then does a RAM check. It is only really looking to work out how much RAM is available, it’s not a proper test to find faulty RAM. Although if it does detect a problem, it will appear to freeze the machine.

The cause of a looping fault is in most cases, due to a RAM fault not being detected by the ROM code, the ROM code then sets up the Z80 stack pointer to point to a location in RAM. If this area of the RAM is not working correctly, then return addresses stored in this area of RAM will be corrupted. Often a corrupted return address will result in the Z80 ending up back at ROM memory location 0 (0x0000) (or an equivalent point that carries out a similar function, like the BASIC NEW command), whereupon it starts the “reset” sequence all over again.

So if the upper DRAM has been correctly disabled, the likely suspects are:

• A fault with one of the lower RAM chips, or the multiplexer chips (IC3, IC4 for board issues 1 to 4S, IC27 for issue 5 and 6A boards) that feed the address lines to these DRAM chips
• A fault with one of the higher address lines (short between PCB tracks, or maybe an open circuit fault)
• One of the chips has a fault that affects the higher address inputs or outputs

What test gear apart from a multimeter do you have?

See also this post of mine on test gear.

Mark

[CC911]

thanks for your answers.

I disabled the upper ram like this:
"To disable the "upper" 32k of RAM, take a piece of wire and connect pin 5 on IC23 (a 74LS32) to +5V"

1024MAK thanks for the very good explanation

I have a brand new:
https://www.rohde-schwarz.com/uk/produc ... 66306.html
I also have a older issue 2 speccy wich I can use for parts.

so let's get this party started.

christoph

[1024MAK]

So with that ‘scope, you can monitor the address bus and some of the bus controls signals.
Use /MREQ (active low) to only see actual memory accesses (including the DRAM refresh address) (as opposed to input/output port accesses).
The DRAM refresh is indicated by /RFSH going low.
/RD goes low to indicate a read (including instruction fetches).
/M1 goes low to indicate that the first part of an instruction is being fetched.

Then compare with the disassembly of the ROM code... That’s just for fun

The simpler test is to see if the logic levels on each address bus line are okay.

If the DRAM chips are not in sockets, the quickest and easiest way is to plug in an expansion that has an on board ROM (or equivalent) so that you can run a diagnostic program. As per the links in the other thread that I linked to.

Mark

[CC911]

hi mark,

I checked all the signals and they seem to be ok.
also 14 and 3,5 MHz clock.
I think the lower ram is the problem like you said.

Now tying to find an expansion with ram test.

the retroleum is out of stock, I found another one on ebay
(Spectrum Diagnostic board) but the seller will not ship to germany
(at the moment).
I will pause the project until I have the extension to do a proper test
without desoldering chips.
maybe someone here has one he wants to sell?

have a nice weekend,

christoph

[CC911]

SOLVED

with the help of the retroleum smart card V2
I could identify a faulty IC6 (lower RAM).
changed it yesterday and now everything works fine

thanks for all your help,

christoph

[1024MAK]

Well done

Mark