Poorly BBC model B

[SiriusHardware]

I am spectacularly good at thinking of things for other people to do.

More seriously, making an Arduino project which would fully test just two or three peripheral ICs away from their host machine wouldn't be too difficult in firmware terms but if the hardware was hand built that would be a lot of wiring up for the sake of a project I myself might never, or would rarely use.

So ideally, it would need a specific PCB made for it so that it could be more easily shared with others. For simplicity I would envisage a socket custom wired for each individual device the tester can test so that there is no need for electronic 'routing' of the signals to relevant pins such as might be needed on a serious device tester - if the Arduino will use pin 'A0' to write to and read from PA0 on each device, there will be a track which sets out from '1' and visits the PA0 pin, whichever pin that happens to be, on each device's socket.

And so on and so forth.

One drawback with this approach is that the size of the PCB increases rapidly with the number of devices the tester can support - one 40-pin socket for each supported device - that then increases the cost of the PCB. Speaking of which, I have almost zero experience with PCB design, the whole design at home / get PCBs made cheaply in China phenomenon has completely passed me by and I can only admire those who are able to produce incredibly complex, and more impressively, working, designs.

It is therefore something which I might knock up, probably on veroboard or an Arduino Mega prototyping board, if I ever had a dire need for it myself. It could happen - I absolutely hate having to replace a 'big' chip just to know if it is faulty or not, I would always rather prove beyond doubt that the original chip was faulty.

One thing I didn't really consider yet is: Has this already been done? It would be surprising if there wasn't a 'big brother' version of the retro IC tester which does do the 10 or 12 most common peripheral ICs because there clearly is a need for something like that, but it wouldn't be cheap and it wouldn't be a cost effective purchase for someone who, like most of us here, only needs to test one or two of those types of chip once in a blue moon.

[Mark1960]

I made something similar for running nop tests on various processors on proto board. 40 pin zif with three rows of pin headers to allow shorting link of each pin to 0v or 5v, then each pin also has a 10k pull up and a 1k to a green led to ground. The leds also have a shorting link to pull down via the 1 k resistor.

For testing peripheral chips you would probably want a processor to run the tests, and with so many different pinouts it might be easier to use a solderless breadboard with a breadboard friendly processor board.

How to decide which processor though? Maybe one of the piggy back adapters to put ram and rom on an mk14 could be repurposed, but a 6502 or z80 might make more sense.

[SiriusHardware]

Using a 'legacy' CPU to drive the chips under test would be the best way to drive them at full operating speed but an Arduino would be more flexible and would be more robust in the case of say a stuck databus bit on the device, which with a conventional CPU would probably stop the tester from running code (I suppose that would be a result in itself, if you insert a suspect device and it actually stops the tester dead) or, you could insert buffers to isolate the CPU's data pins from the device's data pins, but then the complexity starts going up.

I'm thinking of the individual who may be trying to fix a fault on a single machine which they own, like wave_solder's case, and they only want to be able to test a single device (or in this case, two), just one time, ideally using a tool which they already have or which doesn't cost much and is a generally useful thing to have anyway.

I worked for a company which undertook to repair virtually any kind of circuit board even when the equipment it was from wasn't to hand - the method was to test eveything which could be tested and replace anything which couldn't. I built up a collection of small microprocessor PCBs each of which typically had a CPU and some of that CPU's peripheral family ICs on it, so if it had a 6522 VIA on for example I would wire port A to port B and write a bit of software which would 'exercise' all the pins of both ports and flash the result on a LED - these were useful in cases where, for whatever reason, we couldn't lay our hands on replacement chips - we could test them instead.

I may still have some of those PCBs in the garage, I should really have a look.

[Syrinx1]

Interesting video here, using an arduino mega to make a 6522 test harness...

https://www.youtube.com/live/YKZ4aYqWmx0?si=bjPJFDdhzlNmbNN7

[SiriusHardware]

That's very much as I imagined it but I would use a more hardwired approach to connecting the Mega to the 6522 - experience of doing similar things with PROMs and EPROMs has taught me that the plug-in wires and breadboard method just isn't stable enough, so I now put a socket on a Mega 'shield' prototyping PCB so that I can be sure every single connection between the Mega and the device is solid.

I only skimmed through it just now but it looks as though the presenter was being extremely diligent and testing every last function on the chip.

This is the kind of thing we are going to have get used to doing once the price of these once common chips hits £40-£50 or more.

[Syrinx1]

I must admit that I started to skim it too. It was a livestream and the presenter did make some errors along the way that he tried to correct, and although more useful to watch because of the fault finding, it didn't make it particularly slick.

Yes I think a PCB "shield" would definitely be the way to go, I imagine foe quick testing, everything wou6 be automated, though it would be useful to also be able to write to the registers etc. via the serial connection if you had very specific test cases.

Talking of beebs, I've just spent a good couple of hours sorting out a Master 128 PSU. It was working fine, then lost power and wouldn't power up. The internal fuse had gone, a small transistor and 4 rectifier diodes.

The PSU was in a grotty state when I received it, and amongst other things I'd taken the power on rocker switch apart to give it a good clean, I don't think it went back together quite right, and must have arced over taking out a few components along the way!

[SiriusHardware]

I looked a little closer at the ASTEC PSU from my other BBC 'B' (machine 'B') and surely enough the transparent outer casings on both of the RIFA-like components have long cracks in them. My best desoldering iron is the one I have at work so I'll take the PSU in there tomorrow if I remember, to dismantle it and remove those parts in readiness for the arrival of the replacements.

And then, we'll see if machine 'B' awakens from its long snooze.

[ortek_service]

Having a well equipped 'repair bench' with tools like long-nosed angled pliers and screwdrivers with screw-retaining clips to keep these in-place (Or 'pearl-catcher grabbers' to start the screws) - plus some good lighting etc. - does come in handy when servicing these.
All those earth-bonding wires are a bit of as pain, and I do often prefer to re-use the original cable ties that us possible if you release the plastic 'ratchet-pawl' bit of plastic with a very-small screwdriver then bend these back.
And getting the mains-switch out, by pushing all its plastic tabs towards it, is also a bit awkward - but unfortunately is required, in order to be able to slide the PCB out of one-side, even after removing the spade-receptacles on the short wires from the PCB Ass'y(Although you may get away with leaving the Brown and Blue mains cable wires attached, whilst pushing it back out of the rectangular slot for PCB Ass't to clear it).

Although at least it doesn't have those two-piece squeeze together plastic cables glands that I recall was in the Master one I fixed / that all had unusual cable ties with built-in peg bases, to run the DC output wires through.

[ortek_service]

Originally Posted by wave solder

The socketed (IC14) 74LS245 tested good in my T48 tester bus failed the test in the Retro Chip Tester. I only have a 74HC245 to hand and I know you should not mix types but now the cursor flashes 17 times, no activity on the keyboard LEDs though.

You can mix 74 TTL & CMOS types (The manufacturers often did)
- But with caution. An HCT device is designed to normally replace an LS type, as it has a lower 'High' level input voltage to work reliably with any TTL outputs (which don't go that close to 5V) feeding-it.
However, an HC type may not always switch reliably from a 74(LS) TTL output.

Both HC & HCT outputs go close rail-to-rail, but (like most CMOS) you do also have to ensure you don't leave inputs floating. Whereas 74 TTL inherently had a pull-up on the transistor emitters inputs, as needed a significant current to pull these low - So could get away with leaving them unconnected (as did some Manufacturers like recently-found when replicating battery-destroyed PCB's on still expensive vintage Simmons drum synths)
Although I believe it was not recommended to do so, or to tie straight to +5V? - But to use a 10k pull-up.

So maybe not having the right type(s) of 74xx245 here, could cause issues.

[ortek_service]

Originally Posted by SiriusHardware

Regarding the screws missing from my two machines, I have found that there are complete kits of replacement screws available so I've ordered one complete kit which I will 'share' between the two machines. I have to say these machines seem amazingly well supported by third party parts and accessory suppliers.

Yes, I think you can also get the original rubber-feet (I'm missing at least one, so it's a bit wobbly!). And some of the original screws weren't too standard (I think they may have used BA ones on the keyboard, and may differ on later brown Keyboard PCB that often had square nuts (without the star washers on the original Hex ones that were a bit fiddly, with me trying to glue these to the PCB so they didn't fall-off when undoing the screws to get to the ROM sockets).

[ortek_service]

Originally Posted by Syrinx1

I don't think this is relevant to this particular issue, but I wouldn't discard a 6522 out of hand if it didn't work in one of the via sockets. The shift register function of the via is only used in one if the two positions (I forget which one) in the BBC, and in some versions of the 6522 a shift register bug existed. It's quite possible for one of these to work happily in one socket, but not the other.

Originally Posted by SiriusHardware

Your info about the shift register problem in some 6522s is both interesting and alarming and could have implications where it is used in other machines, like PETs. I assume just one manufacturer had this problem, so is it possible to avoid this issue by avoiding one particular brand of 6522?

Well the User VIA wouldn't normally need the Shift Register function, unless using more specialist software with it, as most would just read / write to I/O lines. And (Model B only) User VIA doesn't need to be present to boot-up OK.
The System VIA does need to be present (and have Timer working, to produce 50Hz interrupts for display?), but not sure if the OS also used any Shirt Register functions (Maybe for the 'Slow Databus' it provides, to access the Sound IC & the Keyboard scanning etc).

[SiriusHardware]

This talk about a shift register in the 6522, which I've always thought of as a 2 x I/O port + 2 x timer peripheral IC - has been greatly puzzling me because shift registers are normally only associated with parallel-to-serial conversion or vice-versa. There's no UART in the 6522, or so I thought...

...Until I looked at the datasheet again and discovered that the IC can indeed 'do' primitive serial comms via the CB2 pin. This was complete news to me, I have never heard of it, or of it being used, before.

[ortek_service]

Originally Posted by SiriusHardware

For the avoidance of doubt, Owen, I did have the original controller in and out several times but the mere act of taking it out and putting it back in several times wasn't enough to fix it.

What is it that takes out these chips during the 'quiet' years - was it still OK until the moment I switched it on, then killed by the shock of the power-on inrush after all these years? Why just this chip? If I'd switched it on once a year, would it still be working?

Onwards now to Machine 'B'...

Congratulations on getting this one going - Where it seems 'Chip-swapping' would probably have also allowed fairly-quick diagnosis on this occasion.
It could be that manufacturing impurities defects in the IC's results in them eventually dying due to metallic etc migration? As they were probably being made close to the technology limits at the time and weren't designed to last >40years (Although it seems more-modern IC's might have more issues after that period, if pushing the atomic-level right to the limits with only a few atoms wide features).
Although the 6845 is usually very-reliable - I can't finding a faulty one, only missing ones that had been robbed of a surplus PCB / Beeb.
So maybe a bit more reliable than many Commodore-MOS IC's seem to be.

It seems that absence of MA4 signal may have meant it wasn't reading RAM contents correctly (although may have been other faults as to why it was outputting incorrect frequencies / wasn't getting configured right).
And maybe MA4 is a column rather than row address line, so h/w refresh still worked OK on memory if that just required Row-reads refreshing?

I did find my original 'A Hardware Guide For The BBC Microcomputer' (Wise Owl Publications) printed copy (original bought by Science Dept of a School in Dec 1985).
And I found this came with a glossy A2 size schematic (so rather larger than the one in the Advanced User Guide or even acorn's BBC Service Manual), but it's still quite difficult to follow exactly how the most-complex video RAM addressing logic circuitry operates to fully-implement this.
There is a hardware description for some of this (may have been mostly copied from Acorn's service manual), but this says the 6845 can address upto 32KB of RAM (The Beeb only uses upto 20KB, and there is some external logic to move this and the remaining 12KB around, for h/w scrolling to work?), yet the 6845 only has a total of 14 address lines (that aren't multiplexed for Rows & Columns that DRAM's are and so has 81LS95's etc for doing this / selecting whether 6502 or 6845 are addressing each 16KB bank.
But fortunately, I've never had to delve into this that deeply before, with it all usually still-working OK without fault after several decades.

[ortek_service]

Originally Posted by SiriusHardware

This talk about a shift register in the 6522, which I've always thought of as a 2 x I/O port + 2 x timer peripheral IC - has been greatly puzzling me because shift registers are normally only associated with parallel-to-serial conversion or vice-versa. There's no UART in the 6522, or so I thought...

...Until I looked at the datasheet again and discovered that the IC can indeed 'do' primitive serial comms via the CB2 pin. This was complete news to me, I have never heard of it, or of it being used, before.

Well it was called a Versatile Interface Adapter, so it did provide quite a few extra functions - even if they weren't often used.
But not sure if Commodore's 6526 'Complex Interface Adapter' provided this / even more features?

It may have been useful for bit-banging interfaces, getting h/w assisted speed without dedicated interface IC's.
And may have inspired the additional (Co-processor? like) h/w I/O accelerator / emulator in the RP2040 used in the RPi Pico modules.
With latest Pioc-2 also having further-enhanced h/w features to make I/O quicker?

[SiriusHardware]

it seems 'Chip-swapping' would probably have also allowed fairly-quick diagnosis on this occasion

Absolutely, but I wouldn't have needed to understand anything about the way the circuit works if I had done it that way. Now do know a little bit more about it than I did before, although it is still at the high end of complicated, especially WRT to the memory refreshing, for my liking.

I also wanted to have some assurance that the original CRTC had not been killed by some fault external to it, because putting the CRTC from the other machine only to damage that as well would have been a bit of a disaster.

[wave solder]

An update on my poorly machine, I have replaced both of the VIA IC's and the continuous tone has stopped and with the test ROM fitted an LED in the keyboard now flashes 17 times .
The machine does have video issues.

Out of interest I refitted the original OS ROM back in and the machine now makes the two tone startup sound, there is a diagonal row of "B"'s across the screen. with a flashing cursor. Pressing any key advances the cursor across the screen but no characters appear.

Pressing carriage return also moves the cursor down the screen by one row..

[ortek_service]

Well that seems like some good progress, in that it now all seems to be running OK (apart from the Video, with similar symptoms that Graham had - So maybe your 6845 could also be faulty?)
And so it would seem at least one of your original 6522's was faulty, when fitted for the System VIA.
I presume, with the original OS ROM refitted, you get a beep if you press Ctrl+G (or type VDU 7?)
And if you blindly-type *MOTOR 1 <Enter> (followed by *MOTOR 0 <Enter> you can get the Cassette Motor Relay to turn on & off?
If it is entering BASIC OK, then changing MODE / typing CLS may also have some affect on the screen.

In terms of diagnosing the video fault, then checking the 6845 pins with a 'scope is probably the best thing to do, in particular the Vsync & Hsync frequencies, as well as the MAn address pins and clock input + reset etc. - As Graham had done.
But if you do have another 6845 around, then maybe just try swapping that, to see if symptoms alter / try your Beeb's one in something else that does work OK.

[SiriusHardware]

Not quite the same as mine unfortunately but there is a positive to take from this and that is that the machine is clearly generating the vsync and hsync pulses at the correct frequencies, which is a function of the 6845 - that is one of its jobs, so that part of the 6845 is least working correctly.

Another positive is that the test EPROM when used in the IC51 (OS ROM) position is giving you the 17 flashes so it believes that the RAM is all OK.

A few things to try - with the machine configured as normal and turned on, what happens when you press / release CTRL and G together? (you should hear a short tone from the speaker, same pitch as the second tone you get at switch-on).

Also try Owen's earlier suggestion of blind-typing typing *MOTOR 1<enter> and *MOTOR 0<enter> to see if that activates and deactives the cassette motor relay and LED. If that works, then the machine is 90% working, save for a video output problem.

Try my earlier experiment of changing to a different video mode - the machine should be in Mode 7 by default, I believe, so try any other mode in the range 0 to 6, try blind-typing MODE 1<enter> or MODE 6<enter>. Does that have any effect?

Finally can I suggest you try fitting the 'Andre' test EPROM in place of the BASIC ROM (rather than in place of the OS ROM). When placed there it does additional tests on the two VIAs for a total of 19 flashes but it also changes the video mode from its default mode 7 to another mode, possibly mode 0, at an early stage during the tests. See what happens if you do that.

A question: Which brand / make of 6845 does the machine have fitted? Normally it will be a Hitachi ('HD' prefix) part but if someone has replaced it with some other manufacturer's version please let us know.

Edit: Cross posted with Owen, who has suggested many of the same things while I have been typing this.

[wave solder]

The motor command does turn the relay on / off and the CTRL+G does produce a bleep.

I have managed to obtain a working BBC machine and swap the 6845 over, both of the 6845's are working.

When running the original test ROM at the end of the 17 LED/Cursor flashes the screen mode does change for a while before resetting and running the test again.

I will try the test ROM in the basic socket and see what happens. (on the working machine as well so I can see how it should work too)

PS I have ME so sometimes trying to think describe things is not easy, thanks for bearing with me.

[Syrinx1]

With the OS ROM in place, if you type mode x where x is one of the other screen modes ( 0-6 not 7), and then return, do you still get similar display symptoms?