Apple //e with PAL composite video displaying issue

[XKSTEVE]

I have been working on this //e for a while now and after a Tantalum blow itself apart and I sorted a faulty DRAM out plus the obligatory PSU repairs, I thought I had a good main board until that is I plugged it into composite video as per the attached photo.

It’s fine via both my VGA card and HDMI card (A2VGA and A2DVI) and that is how I would normally run it. But when on composite i get ’incorrect / unexpected characters’ .

I have swapped out the Video ROM - no change . The keyboard encoder must be ok as the display via VGA is fine. It plays games ok and the keyboard maps fine to games.

6502 tests ok as does the DRAM. (Apple //e test software and built in test)

The VGA card reads data from RAM via the 6502 then encodes via a RPi Pico2 so that’s another test it passes.

The video circuit seems ok but was difficult to test as the only schematics I had were for the NTSC boards not the international ones although I have found a PAL diagram now. By tests ok I mean I can see voltages and signals being passed to the socket... but then I would wouldn't I?

Anyone else ever seen this or better still know what to test/try? Could this be a faulty 74LS166 or 175?

Screen shots are whilst duel heading the //e .

 

[joevt]

The Video ROM is where the Apple II keeps the character bitmap data - the Character ROM?

Which screen shot is from the VGA card and which is from the composite output? You said the VGA was OK so the screenshot on the right must be from composite.

The built-in video is not getting the correct Character ROM data. Bit 6 of the character select address is stuck at 1.

hex1=$(printf '1234567890-=QWERTYUIOP[]ASDFGHJKL;'"'"'`\ZXCVBNM,./ ' | xxd -p -c 48)
hex2=$(printf 'qrstuvwxypm}QWERTYUIOP[]ASDFGHJKL{g`\ZXCVBNMlno`' | xxd -p -c 48)
printf "before: " ; sed -E 's/(..)/\1 /g' <<< "$hex1"
printf " after: " ; sed -E 's/(..)/\1 /g' <<< "$hex2"
for ((i=0;i<48;i++)); do
	changedbits=$((0x${hex1:$i*2:2} ^ 0x${hex2:$i*2:2}))
	before=$((0x${hex1:$i*2:2} & changedbits))
	after=$((0x${hex2:$i*2:2} & changedbits))
	printf "changed:%02x before:%02x after:%02x\n" "$changedbits" "$before" "$after"
done | sort -u

before: 31 32 33 34 35 36 37 38 39 30 2d 3d 51 57 45 52 54 59 55 49 4f 50 5b 5d 41 53 44 46 47 48 4a 4b 4c 3b 27 60 5c 5a 58 43 56 42 4e 4d 2c 2e 2f 20 
 after: 71 72 73 74 75 76 77 78 79 70 6d 7d 51 57 45 52 54 59 55 49 4f 50 5b 5d 41 53 44 46 47 48 4a 4b 4c 7b 67 60 5c 5a 58 43 56 42 4e 4d 6c 6e 6f 60 
changed:00 before:00 after:00
changed:40 before:00 after:40

If the Character ROM is 256*8 = 2K, then bit 6 corresponds to address line 9 because there are 3 line select address bits? I guess it depends on how the Character ROM is arranged. I haven't looked at the schematics or the Character ROM data.

 

[joevt]

The VGA card reads data from RAM via the 6502 then encodes via a RPi Pico2 so that’s another test it passes.

Does the VGA card actually read from RAM or does it mirror the RAM by capturing writes? Probably the latter since it would be competing with both the 6502 and the video circuitry otherwise.

 

[XKSTEVE]

Which screen shot is from the VGA card and which is from the composite output?

Hi, Thanks for your reply.

Yes the image on the right is from Composite out (IMG5682.jpeg)

Does the VGA card actually read from RAM or does it mirror the RAM by capturing writes? Probably the latter since it would be competing with both the 6502 and the video circuitry otherwise.

I think it is mirrored from what I read (can't recall the website - probable A2DVI GitHub)

Below is the schematic for the PAL video from the book "Understanding the //e" Which I don't lol.

From what you said could this be an issue with the chip base as the ROM is fine in my other 2 Apple //e machines? if not might it be a trace.?

Again going by what you mentioned, am I right to assume then that the rest of the video circuit is mainly to do with getting the actual image to the monitor and has nothing to do with character generation. Is that right?

Thanks again for your help so far, appreciated.

 

[joevt]

Below is the schematic for the PAL video from the book "Understanding the //e" Which I don't lol.

I believe the problem occurs before the PAL circuit.

From what you said could this be an issue with the chip base as the ROM is fine in my other 2 Apple //e machines? if not might it be a trace.?

What does "chip base" mean?

I hopes it's just a problem with a trace.

Again going by what you mentioned, am I right to assume then that the rest of the video circuit is mainly to do with getting the actual image to the monitor and has nothing to do with character generation. Is that right?

Correct. You should be looking at these:

Figure 8.8: Apple IIe Video ROM Text Patterns​

To convert blank =0xA0 to `=0xE0, bit 6 (0x40) must be stuck high. You should check the text page memory (0x400..0x800) to verify that 0xA0 is stored to represent the blank character.

Figure 8.5: Schematic: Apple IIe Video Generation​

The Video ROM is accessed to get the bits for one of 8 lines of a text character. The address line being stuck high is probably A9 which comes from RA9 of the IOU. RA9 is a combination of other signals: VID6, VID7, GR+2, ALTCHRSET.

 

[XKSTEVE]

Correct. You should be looking at these:

Figure 8.8: Apple IIe Video ROM Text Patterns​

To convert blank =0xA0 to `=0xE0, bit 6 (0x40) must be stuck high. You should check the text page memory (0x400..0x800) to verify that 0xA0 is stored to represent the blank character

i am a little… no make that really rusty on my Apple II stuff. What is the best way to achieve this? Call-151? And then what. Sorry dumb question probably.

Figure 8.5: Schematic: Apple IIe Video Generation​

The Video ROM is accessed to get the bits for one of 8 lines of a text character. The address line being stuck high is probably A9 which comes from RA9 of the IOU. RA9 is a combination of other signals:

Some items on that schematic do not appear on my machines such as va1, and i have a capacitor C95 that is not shown but connects to the video circuits via pin14 of the tca650 but i have checked pin A9 as directed and it has data on it as in a variable signal so i checked the rest of the A pins and they show similar on my scope.

What does "chip base" mean?

Its also known as a IC socket or IC base in different region.

 

[joevt]

i am a little… no make that really rusty on my Apple II stuff. What is the best way to achieve this? Call-151? And then what. Sorry dumb question probably.

You can try AppleSoft Basic using the PEEK command. Something like this:

10 HTAB 1: VTAB 1:PRINT " ": PRINT PEEK(1024)
20 HTAB 1: VTAB 1:PRINT "A": PRINT PEEK(1024)

https://www.calormen.com/jsbasic/reference.html

 

[XKSTEVE]

umm, ok @joevt, that brought back memories I didn’t know I had. Lol

so here is the result of that test which results in the same outcome on all three of my //e computers.

so it looks like its generating the right characters and i also can’t immediately see and trace damage. Really at a loss where to go next.

 

[joevt]

This is a better test:
10 HTAB 1:VTAB 1: PRINT " `Aa": PRINT PEEK(1024) " " PEEK(1025) " " PEEK(1026) " " PEEK(1027)
I tested it at
https://www.scullinsteel.com/apple//e

The result is 160 224 193 225 which are 0xA0 0xE0 0xC1 0xE1

The problem you're trying to track down is why character 0xA0 is outputting pixels for character 0xE0 to the built-in composite output. The character pixels come from the Video ROM so you have to look around there.

Here's a slow method to erase the text screen:

10 FOR J=1 TO 24:VTAB J:FOR I=1 to 40:IF J <> 24 OR I <> 40 THEN PRINT " ";
20 NEXT:NEXT:GET A$

The fast method is to use HOME.

 

[XKSTEVE]

This is a better test:
10 HTAB 1:VTAB 1: PRINT " `Aa": PRINT PEEK(1024) " " PEEK(1025) " " PEEK(1026) " " PEEK(1027)
I tested it at
https://www.scullinsteel.com/apple//e

The result is 160 224 193 225 which are 0xA0 0xE0 0xC1 0xE1

Thats an excellent website that I hadn’t encountered before, so many thanks for the link.

my results were identical to yours on the VGA display but very peculiar on the composite.

I have also double checked the Video ROM by substitution and confirm that it is fine in the my other working machine but the known good ROM makes no difference on the faulty machine (as in, still displays odd characters).

This shows the VGA output (for clarity):



this is from the composite:


and confirmation of the Applesoft program (written out for ease of reading):


Does this prove that the keyboard and video ROMs are good? Should i try substitute of the IO ROM Next?

 

[joevt]

Does this prove that the keyboard and video ROMs are good?

I think so.

Should i try substitute of the IO ROM Next?

Do you mean the IOU at E5? I guess if you're done looking at all the traces to the Video ROM at F4 then sure, try the IOU chip.

You said all the traces had variable signals. Did you check the voltage levels to make sure that low is low enough and high is high enough?

 

[XKSTEVE]

I think so.

Phew, thats good to know.

Yes I do mean the IOU, Autocorrect seems to have deleted the ’U’ and I didn’t spot it.

For clarity:
on the international board. The IOU is C8/9 and the video ROM is E9 .

this kinda sums up my main issue in that so far all the schematics I have found (that are readable electronically) are for American boards, which is fair enough, it was developed there thankfully (if we had waited for europe they would still be deciding if it was safe and could they regulate it - so speaks a brit in the UK).

i will double check the traces between the Video ROM at F4/E9 again just to be sure and then try a IOU ROM if they prove to be ok.

low is low enough and high is high enough

Yes they look ok to me and very stable as in they are not bouncing or noisy on the oscilloscope display and are comparable to my other two machines.

ill also run a different diagnostic software from my usual go to one.

I’ll report back as soon as those tasks are completed and see if any findings point to the next area you think I should check.

thanks again for your help, its reassuring someone is out there with better knowledge of what i am dealing with.

 

[joevt]

Here's another test program. Change the value in line 5 to any bit pattern or character you think might be helpful.

5 TEST = 255-64
10 FOR Y = 0 TO 23
20 AB = INT(Y / 8)
30 CDE = Y - AB * 8
40 OFFSET = CDE * 128 + AB * 40
50 FOR X = 0 to 39 : POKE 1024+OFFSET+X,TEST : NEXT
60 NEXT
70 POKE 49168,0
80 IF PEEK(49152) < 128 GOTO 80

In this example, I've chosen 255-64 (0xBF). So all the bits are high except the problematic one (0x40). You should see ? from VGA and o from the problematic composite output.

You could try 0 - which has all the bits set to 0. It will appear as inverse @ in both VGA and composite but it might be useful in helping to see if the 0x40 bit is stuck. It might appear as mouse text closed-Apple character  🍎 if your ROM has mouse text and mouse text is enabled.

You could try 32+128 (0xA0) which sets the two bits surrounding the problematic bit. This is the same test as all spaces.

 

[XKSTEVE]

Here's another test program. Change the value in line 5 to any bit pattern or character you think might be helpful.

I ran this test and as suggested changed line 5 values. Sadly this did not seem to privide me with any clues as i already know that the composite will not fully match the VGA when accessing numbers or non alphabet characters.

I have spent an age tracing connections between. Video, IOU and CPU which is not easy given that my machine does not conform to the schematics i have.

I have swapped CPU, MMU, IOU, video and tested RAM (again) and there is no change.

Only fault found so far is a weak signal to Q8 but i don't know if this is important (SN3904)

this fault is driving me mad

 

[joevt]

Sadly this did not seem to privide me with any clues as i already know that the composite will not fully match the VGA when accessing numbers or non alphabet characters.

The point of setting all the bytes in the text to all the same value is so that you can find that byte value on the bus.
You're saying the VIDEO ROM is getting all the bits of the value correctly? That doesn't seem possible.
Did you compare VID6 to the IOU with A9 to the VIDEO ROM?
Do they match bit 6 of the value stored to the bytes of the text page?

Is the LS166 shift register that is connected to the VIDEO ROM outputting the bits of the characters that you see on the composite output (including when the incorrect character is being shown)? The bits are output at ≈7MHz. Each character is 7 bits wide. You should see 40 of the same 7 bits per line.

Maybe you can seek more help in another forum?
https://forum.vcfed.org/index.php?forums/early-apple-i-etc.32/