(Yet another) Memory Question

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
marcusjambler
Posts: 403
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: (Yet another) Memory Question

Post by marcusjambler » Sat Jun 23, 2018 9:09 pm

If the Mode 7 screen is corrupt then it could be IC5 SAA5050 Teletext Character Generator causing issues.

JannievanZyl
Posts: 188
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: (Yet another) Memory Question

Post by JannievanZyl » Sun Jun 24, 2018 1:05 pm

marcusjambler wrote:
Sat Jun 23, 2018 9:09 pm
If the Mode 7 screen is corrupt then it could be IC5 SAA5050 Teletext Character Generator causing issues.
Was wondering about that.

Could it also be that the 1KB of RAM Mode 7 use could have some issue? Does it sit as the 1st 1KB of the bottom 16KB block?

Coeus
Posts: 957
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: (Yet another) Memory Question

Post by Coeus » Sun Jun 24, 2018 1:34 pm

JannievanZyl wrote:
Sun Jun 24, 2018 1:05 pm
Could it also be that the 1KB of RAM Mode 7 use could have some issue? Does it sit as the 1st 1KB of the bottom 16KB block?
It ahoukd be the top part of the highest bank in use.

Referring back you your post viewtopic.php?f=3&t=15265&start=30#p206704 the picture for S25 north shows an area at the bottom that looks very different to the rest. Could this correspond to the mode 7 RAM? Is the logic to display mode 7 part of the problem, I.e. causing visible corruption in mode 0?

User avatar
tricky
Posts: 2700
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: (Yet another) Memory Question

Post by tricky » Sun Jun 24, 2018 5:22 pm

That is probably the start of the second bank of 16KB as the top matches the middle.
MODE 7 is at the end of the second bank, so when in MODE 0 with the top 1/5th different to the rest, it is at the very bottom of the screen (two and a bit character rows).
Getting a dodgy memory in the last 1KB would mean all eight chips had the same fault.
I've just remembered that I think there is some 74 series chips that control whether the same data is supplied for each row of a character (mode 7) or different for each (the others). This logic only affects memory from &7C00..&7FFF in a model B by default and &3C00..&7FFF on a Model A (B can also use this).

Coeus
Posts: 957
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: (Yet another) Memory Question

Post by Coeus » Sun Jun 24, 2018 8:54 pm

tricky wrote:
Sun Jun 24, 2018 5:22 pm
...MODE 7 is at the end of the second bank, so when in MODE 0 with the top 1/5th different to the rest, it is at the very bottom of the screen (two and a bit character rows).
I was looking at this bit:
Screenshot from 2018-06-24 21-41-29.png
As I can't see the bottom border in the picture I wonder if the picture is truncated and if that is indeed two and a half rows that are different from the regular pattern above.
tricky wrote:
Sun Jun 24, 2018 5:22 pm
...
I've just remembered that I think there is some 74 series chips that control whether the same data is supplied for each row of a character (mode 7) or different for each (the others). This logic only affects memory from &7C00..&7FFF in a model B by default and &3C00..&7FFF on a Model A (B can also use this).
I didn't know what exactly is different but I know mode 7 is odd. Isn't there also a odd-ball case for the memory wrap around logic for mode 7 too, i.e. the bit that allows you to set a start of display address in the CRTC that causes the final address to have gone off the end of memory, so some logic has to make it wrap back round to the bottom of the display.

User avatar
marcusjambler
Posts: 403
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: (Yet another) Memory Question

Post by marcusjambler » Mon Jun 25, 2018 8:17 am

The dead bits show up as vertical lines in the diagonal sequence.
Put it in 16k mode ( S25 ) south. This will let you see the upper 16k block.
Run Tricky's test OS ROM.... Let it cycle through..
Take some quality close up photos of the right hand side of the screen, when the diagonal test is running. ( Post the photos )
The data bits run right to left. Bit '0' is the very right hand bit... All I do is count from that side using a high res photo.

This memory map from vanekp is really useful :
MemoryLayout.png
Last edited by marcusjambler on Mon Jun 25, 2018 8:18 am, edited 1 time in total.

User avatar
MartinB
Posts: 4898
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: (Yet another) Memory Question

Post by MartinB » Mon Jun 25, 2018 10:33 am

This test program is often worth a whirl in these situations. It’s nothing particularly clever but it does help highlight video-related problems and if there is a ram fault, it will tell you which chip or chips are misbehaving.

Initially, just answer N (North) and N (No) for a standard 32k Beeb and then you can start messing with S25 and inverters if any faults show up.

Kazzie
Posts: 185
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: (Yet another) Memory Question

Post by Kazzie » Mon Jun 25, 2018 10:57 am

JannievanZyl wrote:
Sat Jun 23, 2018 1:48 pm
DutchAcorn wrote:
Sat Jun 23, 2018 1:29 pm
That looks like progress! Any variation between S25 north / south / removed settings?
Not on the 'Frogger' screen, no.

But I can see changes in the bit patterns being displayed with S25 moving.

This is in North:
north.jpg

This is in South:
south.jpg

And this is Open
open.jpg
.
It looks like I've got RAM problems in both banks, so I thought to maybe first get 16K working. Does this makes sense?

If so, am I right in leaving S25 South and then look for any problems in CAS1?

Or leave S25 open and look for problems in CAS0?
Are these pictures with the Test ROM fitted, or without (and trying to boot as per normal)? I'm presuming the Test ROM is out.

Looking at the top left of the North and Open pictures I see the horizontal line of the cursor, but it's black on white rather than white on black. You may have put the S26 inversion jumper in the wrong place. It seems to be in place and uncorrupted, unlike the rest of the screen.

Does the cursor blink on and off? Does it show up when S25 is South? (It's not in the picture, but if it's blinking, then it might have been "off" when you snapped the picture.)

The cursor location information is generated by IC2 and passed directly to IC6 (see diagram on page 12 of the Service Manual), whereas the data flow for the rest of the display goes through the teletext/hi-res buffers (IC8-11), the DRAM, and optionally IC15 and IC5 for Mode 7.

As others have suggested, RAM faults would normally give vertical blocks, not diagonal. This is making me suspect something other than the RAM is at fault (or also at fault).

Have you tried setting the jumpers on the keyboard to tell the Beeb to boot in a mode other than Mode 7? See this page for more info on how to do this. You said you've already tested a known good 74LS273 in IC15, but this would also allow us to eliminate IC10/11 and IC5 from our investigations.

(I also have a theory that one of the buffers IC8-13 may be incorrectly asserting their R-/W line (pin 17) and resulting in the Beeb writing to its RAM when it's actually trying to read from it: ordinarily only IC13, fed by the address bus, should be able to drive R-/W low, but if one of the video buffers were doing it then that could result in RAM corruption and failure to boot, as the beeb writes to the RAM as it reads from it. I'm not sure yet whether it would lead to the diagonal pattern you see. I'll give it some more thought.)
Last edited by Kazzie on Mon Jun 25, 2018 10:58 am, edited 2 times in total.
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)
Acorn System 1 home-made replica

JannievanZyl
Posts: 188
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: (Yet another) Memory Question

Post by JannievanZyl » Mon Jun 25, 2018 10:15 pm

Kazzie wrote:
Mon Jun 25, 2018 10:57 am

As others have suggested, RAM faults would normally give vertical blocks, not diagonal. This is making me suspect something other than the RAM is at fault (or also at fault).
Thanks Kazzie and others. I'll get back to this machine in the next day or so and think I'll retake some good quality photos of the screens (with a now working Test ROM :( )and follow all the suggestions above. Been ill so did not really had proper time to sit and focus on this unit. I'm really enjoying learning about the architecture of this machine and desperately want to narrow the fault down with logic and not just start ripping and replacing chips. :)

BTW, Tricky's Test ROM does write diagonal lines as one of the test patterns. When correct they form a nice solid diagonal line from top left to bottom right of the display area. In my pics you can see some horisontal rows missing from the diagonal lines.

The one thing I'm still searching through the documentation is how the memory map of the display RAM maps to the physical screen, i.e. what is the address of the top left corner and the bottom right corner?

HIMEM starts at different locations depending on the Mode and always end at 7FFF. Would EFFF always be bottom right, with the start address top left?

If I understood Marcus correctly, the bit order in a displayed byte is B7->B0, i.e. bit-7 is the leftmost bit in the displayed byte?

User avatar
tricky
Posts: 2700
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: (Yet another) Memory Question

Post by tricky » Tue Jun 26, 2018 6:00 am

There is a nice picture in the user guide or maybe the advanced user guide.
Basically when most of the screen is the same except a bit at the bottom, 0..&4fff is displayed and when the bit at the top is different, a normal mode 0 screen is displayed &3000..&7fff.
When not in mode 7, memory is displayed in character rows, with eight bytes going down before moving to the next character across (modes with more than two colours need more than one column of bytes for a character)

Code: Select all

&3000 &3008 &3010 ...
&3001 &3009 &3011 ..
&3002 &300a &3011 ..
...
&3007 &300f &3017 ..
&3280 &3288 &3290 ...
&3281 &3289 &3291 ...
...


Post Reply