Superbrain #2: The Board

Talk about non-Acorn classic computers/hardware/software here (including retro consoles)
User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 11:23 am

Hi

I have been rather busy of late, and after the RAM failure on Suberbrain #1, I decided to put it to one side for the time being and look at another one which is just the mainboard. It came from a member of the VCF community who is a genuine SB enthusiast and I wanted him to have a working machine so offered to fix it for him (he has a proper machine that's not working, plus this motherboard which is spare but obviously also broken.

The first test is to check the memory with the ICE. When the SB is powered on, the memory map comprises of:
  • 0000-3fff - Boot rom
  • 4000-7FFF - RAM bank 1
  • 8000-BFFF - RAM bank 2
  • C000-FFFF - RAM bank 3

RAM bank 0 is hiding at 0000 and paged out at startup.

Using the memory detect feature, I can see that the ROM is present, but the ICE can't detect any RAM. The first thing the SB does at boot is to copy a chunk of ROM from 400h to C000h (in RAM bank 3) and it checks a few bytes to ensure the copy was successful. If not, it loops and repeats. As the memory is defective in some way, this causes the machine to act dead.

Anyway, to get over this, I have replaced Bank 3 with fresh DRAM, but there is still no RAM visible to the ICE's detection routine, and the RAM test shows defects everywhere. I tried to fill a block of RAM with zeros and read it back. All good. Then, I tried the same test with FF and found that D3 appears to be not working. I located the corresponding RAM chip in Bank 3 and swapped it out, then retested. Still nothing.

I did notice one thing though.. Successive reads seemed to indicate that the state of D3 is variable. For example:

Code: Select all

(fill a chunk of Bank 3 with FF)
OK ===> f c000,cfff,ff

OK ===> d c000

C000   F7 F7 F7 FF F7 FF F7 FF-F7 F7 F7 F7 F7 F7 F7 F7    ................
C010   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 F7    ................
C020   FF F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 FF F7 F7    ................
C030   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 F7    ................
C040   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 FF F7 F7 F7 F7 F7    ................
C050   F7 F7 F7 F7 F7 F7 F7 F7-F7 FF F7 FF F7 FF F7 F7    ................
C060   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 FF F7    ................
C070   F7 F7 F7 F7 F7 F7 F7 F7-FF F7 F7 F7 F7 F7 F7 F7    ................

(ooh, looks like D3 is playing up, lets try again..)

OK ===> d c000

C000   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 FF    ................
C010   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 F7    ................
C020   F7 F7 F7 F7 F7 F7 F7 F7-FF F7 FF F7 F7 F7 F7 F7    ................
C030   F7 F7 FF F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 F7    ................
C040   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 F7 F7 F7 F7    ................
C050   F7 F7 F7 F7 F7 F7 FF F7-F7 F7 FF F7 F7 F7 F7 F7    ................
C060   FF F7 F7 F7 F7 F7 F7 F7-F7 FF F7 FF F7 F7 F7 F7    ................
C070   F7 F7 F7 F7 F7 F7 F7 F7-F7 F7 F7 F7 FF F7 FF F7    ................



Here we can see that (for example) the value in C003 has changed between successive reads. What is happening is that D3 is being held low, but occasionally we get a bit through (thus giving the correct value).

I can think of some things to try and none of them are going to be very quick:
  • Pull the D3 ram chips from the other banks. Maybe one of them is pulling D3 low.
  • Start pulling other chips connected to the data bus.

The odd thing is that the ROM seems unaffected by this, which makes me think the issue may be one of the D3 RAM chips (it's a guess, of course).

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 12:04 pm

Well, it's not the D3 RAM chips (Z13, Z21, Z29). Drat... but I did notice something else.

With these three chips out, I thought I'd have a play with the other banks, by setting D3 on them and reading the value back. Hence:

Code: Select all

OK ===> f 8000,8fff,08

OK ===> d 8000

8000   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8010   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8020   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8030   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8040   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8050   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8060   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................
8070   00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00    ................


There are no spurious 1s in there (and I got the same result repeatedly, and with the other banks). Maybe the problem lies in the control signals going to these four RAM chips that implement D3 for the four banks, because we only see a problem if a chip is present. On the other hand, if some other component was dragging D3 low, we would expect to see a zero all the time (as we do here).

A bit of a conundrum, what?

I know from past experience that the keyboard decoder IC has a failure mode that affects the data bus. I could remove it, but it's one of the 40 pin chips that is soldered directly to the board, so I am reluctant. That said, both machines I have repaired so far (my own, and SB #1) suffered from a damaged keyboard encoder, so there are grounds for suspicion.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 12:28 pm

OK, this is interesting.. I managed to desolder pin 11 of the keyboard decoder fully, and isolate it from the board (it is the D3 output). Yes, it is possible! Who knew?

Anyway, it's not the problem, so on to the next candidate, unless anyone's got a better idea?

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 1:21 pm

I pulled the 8255 (Z45) and it looks like we have a winner!

Code: Select all

OK ===> md

0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
RRRRRRRRRRRRRRRR                                RRRRRRRRRRRRRRRR
OOOOOOOOOOOOOOOO                                WWWWWWWWWWWWWWWW
0000000000000000                                3333333333333333
0101010101010101                                0123456789ABCDEF



Those gaps are caused by the missing DRAM chips. Next up, whack 'em back in, full memory test, resolder the KBD encoder's D3 pin, whack a new 8255 in there and proceed to boot testing.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 1:56 pm

Well, a new 8255 hasn't solved it. I'm back where I started from, with all sorts of holes in the memory map.

To make matters slightly worse, my own Superbrain board is playing up!

Hmmm... :-k

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 3:20 pm

Seems I spoke too soon regarding my SB. There was a loose component causing the screen to play up, but it's fixed now. What a relief....

Anyway, back to this motherboard. With the 8255 in place, there are memory holes. Without it, the memory looks OK. Substituting a known working 8255 has no effect, so I reckon that removing the chip masks problems that arise when it's in place.

Let's consider what the 8255 is used for in the Superbrain. It's an Intel PPI chip with three bi directional parallel ports A-C and a control word.
  • Port A controls the video chip
  • Port B's lines are 0,1 (kbd encoder); 2 CRTC vertical blank; 3 not used; 4 Caps lock; 5 Disk ready statu; 6 Main R.I. (don't know what that is); 7 CPU2 BUSAK
  • Port C's lines are 0 Bank 0 disable (allows access to CRTC); 1 Character blanking; 2 ROM switch into Bank 0; 3 CPU2 reset; 4 enable CPU2 access to Bank 2; 5 CPU2 bus request; 6 Bell; 7 KBD data ready

That's quite a bit of stuff, but I think we should consider the memory switching outputs first. These are
  • PC0 - Affects bank 0.
  • PC2 - Affects Bank 0 (switches the ROM in / out).
  • PC4 - Affects Bank 2 (switches access between CPU 1 and CPU 2 for disk buffer transfers).

Now here's a funny thing. When the machine starts up, it has Bank 0 paged out and the ROM is visible at 0000. Running the memory detect results in a full house of RAM, plus the first 16k as ROM, which is correct:

Code: Select all

OK ===> md

0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
OOOOOOOOOOOOOOOOWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
0000000000000000111111111111111122222222222222223333333333333333
01010101010101010123456789ABCDEF0123456789ABCDEF0123456789ABCDEF


When the ROM is paged out (using OUT 6B,82 followed by OUT 6A,B0) all is good and we see a full 64k RAM.

Code: Select all

OK ===> o 6b,82

OK ===> o 6a,b0

OK ===> md

0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF


(This OUT also switched out the ROM.)

Maybe the circuitry around PC4 is playing up, so let's try to trigger it and see what happens. I think it's OUT 6A, A0 to do this.

Code: Select all

OK ===> o 6a,a0

OK ===> md

0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR                RRRRRRRRRRRRRRRR
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW                WWWWWWWWWWWWWWWW
00000000000000001111111111111111                3333333333333333
0123456789ABCDEF0123456789ABCDEF                0123456789ABCDEF


Well that is very odd indeed. I would have expected to see some spurious gaps appearing in the memory at this point, but instead the whole of Bank 2 is paged out as expected.

Of course, this is all Good News, but doesn't get me closer to a proper diagnosis and fix, other than to (partially) eliminate the memory switching logic.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 19, 2017 4:00 pm

OK, so the boot sequence has it doing:

  • OUT 6B,82 (this sets up the ports on the PPI chip), followed by
  • OUT 6A,2A

At this point the memory map goes bad.

When you do that last OUT, the effect is:
  • PC0=0 - Normal RAM addressing
  • PC1=1 - screen character blanking
  • PC2=0 - Page ROM out; Page Bank 0 RAM in
  • PC3=1 - CPU2 reset
  • PC4=0 - Give CPU2 access to Bank 3 (CPU1 will not see it)
  • PC5=1 - Enable CPU2 bus request
  • PC6=0 - No beep / bell
  • PC7=0 - Keyboard encoder reset

I guess the problem is with the bus request, as CPU2 is always in reset at start up (so the OUT is maintaining that). Yet when I try these two output instrictions directly from the ICE, the map

(I just remembered that the MD (memory detect) command on the ICE is destructive (at the first 16 bytes of each page) so stepping through the startup code and checking to see if the memory map is intact with MD is not the right way forward. #-o )

More oddness: When you do OUT 6B,82 you get a weirdness in Bank 3:

Code: Select all

OK ===> o 6b,82

OK ===> md

0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF00000000000000000123456789ABCDEF


What it is saying is that the first page of RAM is being duplicated repeatedly across the whole of Bank 3. The OUT 6A,2A doesn't fix this, but OUT 6A,B0 does.

Hmm, gotta be that CPU2 bus request signal. The disk buffer memory page out seems to work in isolation.

alan8086
Posts: 2
Joined: Mon Jul 17, 2017 1:19 pm

Re: Superbrain #2: The Board

Postby alan8086 » Tue Aug 22, 2017 10:25 pm

Hello Jon - thought I'd reply to your PM on VCFED here. I've just bothered to look at my Gmail account so I've just seen your message. I appreciate your time and concern spent on my SB board, fascinating process of diagnosis as usual! I cant pretend to understand in great detail, only that it looks as if there is plenty of life in this board, just not quite enough and of the right kind for it to work! Let me know if any of the spare chips I have would be of use? I have multiple spares of all the socketed ones.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Wed Aug 23, 2017 6:08 am

I'm not at that stage yet, although I nearly ordered a new PPI for it.

You can perhaps see where this is going? We need to get CPU1 running and have all the memory working along with its paging mechanisms first. I think we're nearly there, but for this seemingly random corruption. It's most odd, but I am thinking it's similar to what the SB#1 is doing.

User avatar
1024MAK
Posts: 6786
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Superbrain #2: The Board

Postby 1024MAK » Wed Aug 23, 2017 8:37 am

Before you go off on a hunt, have you either confirmed that the 74LS245 fitted in Z62 position is properly driving the data bus within spec or tested by replacement or swap? Just in case one of the output drivers is a bit weak and not always managing to drive to the correct voltage for the logic level.

If Z62 is good, the RAM is good, and the copy from ROM to RAM is good, then that leaves either a RAM refresh problem, or a address decoding/control logic failure which is allowing writes (directed elsewhere, maybe even "OUTs") to cause the corruption.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Wed Aug 23, 2017 8:41 am

Hi Mark. I have assumed the 245s are fine because the LDIR seems to be working OK, and I can also use the ICE to copy it across. The corruption is occurring after the copy operation. Read on..

I was trying to trace the boot code to see at what point the memory got corrupted. Look at this output from a session with the Z80-ICE. The startup routine has successfully copied 400 bytes from the ROM at 0400h to C000h using LDIR, and jumped to C006. The code from that point is interacting with the PPI chip (see the OUT instructions):

Code: Select all

C006 F3             DI
C007 31 FF F3       LD SP,F3FF
C00A 3E 82          LD A,82
C00C D3 6B          OUT (6B),A
C00E 3E 2A          LD A,2A
C010 D3 6A          OUT (6A),A
C012 3E 03          LD A,03
C014 32 22 C3       LD (C322),A
C017 D3 68          OUT (68),A
C019 3E 08          LD A,08
C01B D3 6B          OUT (6B),A
C01D 3E 55          LD A,55
C01F 32 00 88       LD (8800),A
C022 3E AA          LD A,AA
C024 32 01 88       LD (8801),A
C027 3E B2          LD A,B2
C029 D3 6A          OUT (6A),A
C02B 3E C3          LD A,C3
C02D 32 38 00       LD (0038),A
C030 21 DA C0       LD HL,C0DA
C033 22 39 00       LD (0039),HL
C036 21 00 00       LD HL,0000
C039 22 DE C2       LD (C2DE),HL
C03C 22 E0 C2       LD (C2E0),HL
C03F 22 E2 C2       LD (C2E2),HL
C042 22 E4 C2       LD (C2E4),HL
C045 21 E9 C2       LD HL,C2E9
C048 06 19          LD B,19
C04A 3E 00          LD A,00
C04C 77             LD (HL),A
C04D 23             INC HL
C04E 05             DEC B
C04F C2 4C C0       JP NZ,C04C
C052 21 02 C3       LD HL,C302
C055 06 19          LD B,19
C057 3E 00          LD A,00


What I was doing was to step past each OUT and check that the memory at C000 was still intact. I got to C017h and this happened:

Code: Select all

OK ===> l
C02B 3E C3          LD A,C3
C02D 32 38 00       LD (0038),A
C030 21 DA C0       LD HL,C0DA
C033 22 39 00       LD (0039),HL
C036 21 00 00       LD HL,0000
C039 22 DE C2       LD (C2DE),HL
C03C 22 E0 C2       LD (C2E0),HL
C03F 22 E2 C2       LD (C2E2),HL
C042 22 E4 C2       LD (C2E4),HL
C045 21 E9 C2       LD HL,C2E9
C048 06 19          LD B,19
C04A 3E 00          LD A,00
C04C 77             LD (HL),A
C04D 23             INC HL
C04E 05             DEC B
C04F C2 4C C0       JP NZ,C04C
C052 21 02 C3       LD HL,C302
C055 06 19          LD B,19
C057 3E 00          LD A,00

OK ===> l
C059 FF             RST 38
C05A 00             NOP
C05B FF             RST 38
C05C 00             NOP
C05D FF             RST 38
C05E 00             NOP
C05F FF             RST 38
C060 00             NOP
C061 FF             RST 38
C062 00             NOP
C063 FF             RST 38
C064 00             NOP
C065 FF             RST 38
C066 00             NOP
C067 FF             RST 38
C068 00             NOP
C069 FF             RST 38
C06A 00             NOP
C06B FF             RST 38


The delay between these two list instructions was a couple of seconds. Nothing was being executed. Yet the memory in Bank 3 got wiped somehow, including the next address the CPU was about to execute. This is an extreme case - at other times I am seeing the odd bit here and there getting corrupted. I can't see how it is occurring, and it isn't happening at the same place all of the time. The board is being tested with a known good power supply so I do not think a brownout in the RAM area is the cause. The RAM at Bank 3 (C000-FFFF) is testing good, repeatedly.

Does the pattern FF 00 FF 00 (etc) indicate anything in particular?

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Wed Aug 23, 2017 8:51 am

1024MAK wrote:Before you go off on a hunt, have you either confirmed that the 74LS245 fitted in Z62 position is properly driving the data bus within spec or tested by replacement or swap? Just in case one of the output drivers is a bit weak and not always managing to drive to the correct voltage for the logic level.

If Z62 is good, the RAM is good, and the copy from ROM to RAM is good, then that leaves either a RAM refresh problem, or a address decoding/control logic failure which is allowing writes (directed elsewhere, maybe even "OUTs") to cause the corruption.

Mark


  • Does my testing indicate Z62 is OK? I think so.
  • The RAM is good according to the ICE. I've tested it many times.
  • How to detect RAM refresh or decoding failure? I could put a probe on the write line of the affected bank and watch for signals, but the refresh triggers it?

Maybe Z33 is playing up? Trouble is, it is so complicated I am having difficulty getting my head round it.

SB memory.JPG
One of these ICs, perhaps (ringed)?

User avatar
1024MAK
Posts: 6786
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Superbrain #2: The Board

Postby 1024MAK » Wed Aug 23, 2017 10:09 am

A basic RAM refresh test can be done by HALTing the Z80 CPU.

Whenever a software HALT instruction is executed, the CPU executes NOPs until an interrupt is received (either a non-maskable or a maskable interrupt while the interrupt flip-flop is enabled).

The purpose of executing NOP instructions while in the HALT state is to keep the memory refresh signals active. Each cycle in the HALT state is a normal M1 (fetch) cycle except that the data received from the memory is ignored and a NOP instruction is forced internally to the CPU. The HALT acknowledge signal is active during this time indicating that the processor is in the HALT state.

So apart from the memory location that the PC currently points to, the remaining RAM in the system will only be refreshed by the CPU refresh cycle or alternatively by whatever refresh system is used if not based on the CPU refresh.

The following assumes that the refresh address is using the address from the CPU output during the refresh cycle.
Test that the DRAM is getting the correct /RAS and /CAS signals (normally for older DRAM, it's /RAS going active while /CAS is kept high, unlike a normal read or write where /RAS goes low, then /CAS goes low, then they both go high). These should occur on the DRAM chips even with the Z80 HALTed.
Use the /RFSH pin on the CPU to synchronise your 'scope.
After you are happy with the tests on /RAS and /CAS, check that the address lines A0 to A6 are counting up, bits A0 to A6 count. Bit A7 to A15 do not change (and could be any number).

If the CPU now receives a interrupt, it will exit the HALT state. If memory is now read back, it should still contain valid data.

I think your ICE can do the equivalent of the above, when idle. But please check.

Note that /WR should never be active during refresh.

To test for unwanted writes, you need to run a simple routine that only reads from memory and does port inputs, then loop back. Monitor the /WR line on the DRAM with a 'scope (use this to trigger, so that you can see the change of state).

Testing during port writes depends on how the circuit has been designed....

You last results where bank 3 is filled with FF, 00, FF, 00, FF etc is very strange indeed :?

That's not a refresh fault. It's not a brown out either. As both these leave much more random data. It looks like somehow data got written to the RAM :shock: :?
Maybe the CPU encountered a block copy instruction???

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 6786
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Superbrain #2: The Board

Postby 1024MAK » Wed Aug 23, 2017 10:21 am

Z35 selects and routes the /RAS and /CAS signals for each bank. Z34 selects (switches between) the /RAS signals from Z35 (normal RAM access) and all four lines being active during the Z80 refresh (controlled by the Z80 /RFSH signal to pin 1).

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Thu Aug 24, 2017 5:24 pm

The ICE runs in Quit mode most of the time when I am testing.

From the manual:

When the ICE is in Quit mode, the Z80 executes bursts of NOP instructions to provide for refresh of any DRAM
present in the target system. This takes up about 25% of the processor’s time, so if you know that your system
doesn’t use DRAM, you may want to disable refresh to speed up instruction tracing. In Go mode, the Z80 is
executing at full speed, so no extra refresh provision is needed.


Using a logic probe:

  • When the ICE is in Quit mode prior to beginning to run the startup code, there are pulses at REFSH, RAS1,2,3.

  • After running the first part of the startup code (copy 400 bytes of ROM from 400h to C000h RAM) there is no refresh signal on Z35 Pin 1 - it is high - but there is pulsing on Pin 12 (RAS3) but nothing on 4,7,9 (RAS0, 1, 2 respectively).

    This is before any OUT instructions have been altering the memory paging, and I have Bank 0 as ROM and the rest as RAM.

  • When it is running normally we get pulses on REFSH and all RAS lines, although I don't know what it is doing. Probably looping round with a RST38 or some such.

  • With the Z80 HALTed, we get pulses on REFSH and all RAS lines, but RAS3 seems to be running at a different speed to 0,1,2. The amber LED is pulsing slower.
Last edited by jonb on Thu Aug 24, 2017 6:13 pm, edited 1 time in total.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Thu Aug 24, 2017 6:03 pm

Scope traces.

This is running in Quit mode (contrary to what I said previously, it is showing Refresh and RAS on 0,1,2):
DS1Z_QuickPrint33.png
Y=/REFSH, C=RAS0, M=RAS1, B=RAS2


The other Quit mode (which I noted):
DS1Z_QuickPrint34.png
Y=/REFSH, C=RAS0, M=RAS1, B=RAS3

Blue is RAS3 which is running, whereas the other signals are oddly dead. I can't remember how I got here!

DS1Z_QuickPrint35.png
Y=/REFSH, C=RAS0, M=RAS1, B=RAS3

Zoom out on the first condition (having started the ICE and run some instructions via trace), we can see the refresh pulses grouped together (I'm guessing that the groupings are the individual refresh pulses corresponding to the address bus counting per refresh cycle), but the RAS3 line is going all the time. This looks a bit odd to me - it happens when the CPU jumps to C006 immediately after the copy operation, and goes away when I set the PC to 0.

This also happens when setting the PC to a different bank, so 4000 affects RAS1, 8000 affects RAS2. As RAS0 isn't in use (ROM is paged in) there is no point testing it, but I expect I would see the same thing if I paged the ROM out and set PC=0.

Maybe it is normal Z80 behaviour?

User avatar
1024MAK
Posts: 6786
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Superbrain #2: The Board

Postby 1024MAK » Thu Aug 24, 2017 6:33 pm

Whichever bank is pointed to by the PC will also have normal instruction fetch cycles (so /RAS will be active) as well as the refresh cycle. If the CPU is HALTed, the CPU still fetches the instruction, it just ignores the byte it has just received.

If the ICE is causing the CPU to execute NOPs, then a normal refresh cycle will take place. Depending on how the ICE controls the CPU, it may still be carrying out an instruction fetch (and so the relevant /RAS will be active if the PC points to RAM). The ICE may then prevent the received data from going to the CPU and instead substute the code for a NOP.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Thu Aug 24, 2017 6:48 pm

Oh, scratch that idea then. :(

What about the middle trace?

Meanwhile..

Code: Select all

OK ===> q

S..V..  A=C0  BC=2000  DE=0000  HL=C3A2  S=F3FF  P=C338  RRA
...... A'=00  B'=0000  D'=0000  H'=0000  X=0000  Y=0000  I=00

OK ===>  l c333

Err ===> l c000
C000 00             NOP
C001 FF             RST 38
C002 00             NOP
C003 FF             RST 38
C004 00             NOP
C005 FF             RST 38
C006 00             NOP
C007 FF             RST 38
C008 00             NOP
C009 FF             RST 38
C00A 00             NOP
C00B FF             RST 38
C00C 00             NOP
C00D FF             RST 38
C00E 00             NOP
C00F FF             RST 38
C010 00             NOP
C011 FF             RST 38
C012 00             NOP


Arggh! It did it again! :evil:

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Thu Aug 24, 2017 7:17 pm

Thinking perhaps it is the kooky DRAM I replaced Bank 3 with (they are those U256D chips floating round eBay), I switched the original RAM chips back into the bank. The good news is that these appear to be OK. I'd switched them after discovering failures in the memory tests that occur after the startup code has run. If I run the memory test immediately though (before starting execution, I get a clean bill of (memory) health. Which will save Alan8086 a few bob.

However, I am no nearer to fixing the darned thing.. it is still playing these stupid tricks.

alan8086
Posts: 2
Joined: Mon Jul 17, 2017 1:19 pm

Re: Superbrain #2: The Board

Postby alan8086 » Sat Aug 26, 2017 11:16 am

I assume you can return the 'kooky memory chips' to the eBay seller? It will still have cost you money even if you don't end up using them in my board?

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Sat Aug 26, 2017 7:30 pm

No need to. Remember I have three others to restore, and these are always handy to have around.

User avatar
jonb
Posts: 2081
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England

Re: Superbrain #2: The Board

Postby jonb » Wed Sep 20, 2017 2:00 pm

Does anyone have any suggestions as to what I might try next?

..before I break out the DSO and start cursing the 8-bit gods...


Return to “other vintage computer hardware, software and games”

Who is online

Users browsing this forum: No registered users and 1 guest