BBC Model B Issue 4 with Pi Zero and Pi 3 A+ Crashing

[pdsmart]

I have an issue which I am assuming is down to timing between the pitube<->BBC bus.

On a BBC Model B Issue 4 motherboard, fully populated with Econet, 1770 (Retroclinic) FD, Integra B and Retroclinic Pi external adapter I get a crash in Mode 0 on the 6502/Z80 processors (probably the others but I haven't tried them yet).

If I take all upgrades out, it is more reliable but still crashes eventually. I have changed obvious IC's like IC14 and run memory tests all seem fine.

Regardless of upgrades in-situ or removed, If I remove the Pitube (or FX151,230,14) the machine doesn't crash, runs faultlessly even in mode 0.

The symptoms are when running with the Pitiube enabled, say the BASIC CPU Timing example in mode 0 (NB. mode 1,2 work reliably) is that at some point, pixel bleed appears on screen and the program crashes. When booting CPM, same thing, you get CPM running then you type DIR and half way through the output it will crash. Sometimes it doesn't crash but most times it does. It is only in Mode 0 (and I guess mode 3).

Im thus thinking it is a timing issue between the pitube and model B issue 4 motherboard given Mode 0 has a higher bandwidth for the display and was wondering where would be the best place in the pitube code to delay (for debugging to see if this is the issue) the tube<->BBC transactions?

I searched the net but nothing like the above comes up hence raising an issue.

Many thanks in advance for any help.

[hoglet67]

This problem sounds quite unusual, but then so is your setup, esp. the Integra B (is this original?)

A bit more information would be helpful here:

1. What release of the PiTubeDirect software are you running?

2. Are bothe the Pi Zero and Pi 3A+ crashing in a similar fashion?

3. How is the Pi being powered (from the Tube or from a seperare power supply)

4. Is there any kind of a power switch involved?

5. What type of 6502 is being used in the Beeb?

Could you provide a couple of photos of your setup, as sometimes this reveals something unexpected?

Dave

[hoglet67]

Might also be worth you reading throught this thread: https://stardot.org.uk/forums/viewtopic.php?f=3&t=12987

[pdsmart]

Hi, thank-you,

In answer to the questions:

1. EggEater, latest release from the repository.
2. Both the Pi Zero and Pi 3A+ crash pretty much identically. I have tried different 40pin ribbon cables and have 2 Retroclinic pitube adapters, both are the same.
3. Normally it is powered by the Tube but I have wired a separate 5V supply direct to the Pi Zero/3A+ and it makes no difference. The main supply line is indicating 4.89V at the Pi, 4.93 at the point closest to the PSU.
4. No power switch, just hard wired (albeit the Retroclinic adapter has a jumper to disable the power but no voltage drop is seen).
5. The CPU is a MOS MPS6502- the original CPU had failed or doesn't work in this machine. I have, a new Rockwell 6502B but it doesn't work in this machine. I will try and source a new 6502A and see if this makes a difference.

I've attached photos showing the CPU Timing running in mode 1 which is has been happily doing for the last few hours ( I had it running Elite with the co-pro turned off but in-situ and it ran overnight flawlessly yet the enhanced Elite with co pro enabled will crash after about 10 minutes). I stopped it, switched to Mode 0 and almost immediately you get the crash. The third picture is the setup. The video proc is the 2023 variety.

As mentioned, I stripped out all the upgrades including removing the 6854 from the Econet and it is a bit more reliable but still eventually crashes, hence thinking it could be a timing issue as the extra loading on the data bus could be altering the rise and fall times, exacerbated with the extra loading. The vanilla machine just with the Pitube though still crashes in Mode 0 (only).

Hence thinking of slowing down the bus transactions in the pitube code to see if this was the issue (if indeed it is possible as I haven't studied the tube in detail).

Thank-you for the help,

Brgds, Phil

[dp111]

Something doesn't look right to me , the 6502 emulation is very slow.

Can you list the first few lines of Spheres ? this will enable us to check what version you are running.

On Wed, 5 Feb 2020 at 13:57, Philip Smart notifications@github.com wrote:

Hi, thank-you,

In answer to the questions:

1. EggEater, latest release from the repository.
2. Both the Pi Zero and Pi 3A+ crash pretty much identically. I have tried different 40pin ribbon cables and have 2 Retroclinic pitube adapters, both are the same.
3. Normally it is powered by the Tube but I have wired a separate 5V supply direct to the Pi Zero/3A+ and it makes no difference. The main supply line is indicating 4.89V at the Pi, 4.93 at the point closest to the PSU.
4. No power switch, just hard wired (albeit the Retroclinic adapter has a jumper to disable the power but no voltage drop is seen).
5. The CPU is a MOS MPS6502- the original CPU had failed or doesn't work in this machine. I have, a new Rockwell 6502B but it doesn't work in this machine. I will try and source a new 6502A and see if this makes a difference.

I've attached photos showing the CPU Timing running in mode 1 which is has been happily doing for the last few hours ( I had it running Elite with the co-pro turned off but in-situ and it ran overnight flawlessly yet the enhanced Elite with co pro enabled will crash after about 10 minutes). I stopped it, switched to Mode 0 and almost immediately you get the crash. The third picture is the setup. The video proc is the 2023 variety.

As mentioned, I stripped out all the upgrades including removing the 6854 from the Econet and it is a bit more reliable but still eventually crashes, hence thinking it could be a timing issue as the extra loading on the data bus could be altering the rise and fall times, exacerbated with the extra loading. The vanilla machine just with the Pitube though still crashes in Mode 0 (only).

Hence thinking of slowing down the bus transactions in the pitube code to see if this was the issue (if indeed it is possible as I haven't studied the tube in detail).

Thank-you for the help,

Brgds, Phil

[image: 1] https://user-images.githubusercontent.com/28005720/73847946-1dd66f80-481f-11ea-85c7-1fb28e005583.jpg [image: 2] https://user-images.githubusercontent.com/28005720/73847964-23cc5080-481f-11ea-8074-8923b9cf0f1f.jpg [image: 3] https://user-images.githubusercontent.com/28005720/73847976-275fd780-481f-11ea-824f-86db00e29fb2.jpg [image: 1 (1)] https://user-images.githubusercontent.com/28005720/73848008-33e43000-481f-11ea-9bf4-b2701a1e011e.jpg [image: 2 (1)] https://user-images.githubusercontent.com/28005720/73848015-35155d00-481f-11ea-9349-b2cddd4bc2b6.jpg [image: 3 (1)] https://user-images.githubusercontent.com/28005720/73848017-36df2080-481f-11ea-886d-d1af9485c0bb.jpg

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hoglet67/PiTubeDirect/issues/68?email_source=notifications&email_token=AEVVFIVANE7XZDC7AG555H3RBLATJA5CNFSM4KQJUEM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK3QF4Y#issuecomment-582419187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVVFIWORYI7D7Q224B435DRBLATJANCNFSM4KQJUEMQ .

[hoglet67]

The CPU is a MOS MPS6502- the original CPU had failed or doesn't work in this machine.

This CPU is very unusual, I haven't seen one marked like that before - where did it come from?

It's very likely to be a 1MHz part, which is only just working at 2MHz.

The timing for PiTubeDirect at 2MHz is quite tight, so if the CPU is in any way out of spec, then you'll see this kind of random crash.

I would start by replacing the CPU with a known-good 6502A.

It doesn't explain Dominic's observation about the CLOCKSP benchmark. What Pi was that, and which Co Pro was selected (with *FX 151,230,N).

Dave

[pdsmart]

Thank-you both. The Speed is because I was trying the various 6502 modes to (*FX151,230,1 to 3) to see if this helped, hence the slow speeds. The full speed can be seen below. It was N=3 running the test in the photos.

As you mention, the CPU - I have quite a repertoire of IC's being (originally) an electronic engineer and it was one from my bins. I will buy a new 6502A and see if that helps and update you accordingly. It is only in Mode 0 that the crash occurs and less often when all the upgrades are removed, so timing looks to be the issue and as I can't be certain on the MPS part will change that.

Thank-you also for the link, I will try the cmdlines.txt and add delays to see if this helps.

Many thanks,

Phil

[hoglet67]

Hence thinking of slowing down the bus transactions in the pitube code to see if this was the issue (if indeed it is possible as I haven't studied the tube in detail).

This isn't possible on the Tube.

I would try changing the CPU to an original 2MHz 6502A, and then if that doesn't work we can take stock.

[pdsmart]

Just an update.

I received the new 6502A and after inserting it made the system worse.

I stripped down the machine, pulled out all the upgrades so it was basic and still with the new 6502A the machine was unstable, in fact a lot more unstable with the new 6502A. I then tried various MOS (same as picture above but slightly different country of manufacture and numbering) and the new 6502A but the only stable system was with the MOS6502 I originally installed. I then looked at various IC14 versions, ie. 74LS245 from different manufacturers, and ALS, HCT and discovered that a 74HCT245 made the machine much more stable, so much so that the MOS6502 with a HCT245 and all the upgrades (except the 1770 disk I/f) will run stable with the PiCoPro running Elite or the timing tests for hours on end. If I install the 1770 then it becomes a little bit unstable, so adding the extra loading brings up this fault. The Integra-B board, wether installed or un-installed is causing no issue, it uses it's own data/control buffers so presents minimal electrical loading on the CPU signals.

So this issue, hazarding a guess, is going to be capacitance / inductance on the CPU data bus which is altering the timing, probably a dry joint, or the control line's and their driver IC's. I will have to re-solder all the joints and see if it makes a difference.

This machine from manufacture was unused (not just by the looks/packaging, the PSU hadn't got any tell tale marks of getting warm). As the original CPU didn't work and the XTAL was slightly faulty it was either faulty from new hence being stored for 35 years or age got to it.

Thank-you for your input, the CoPro timing was a red herring. An excellent piece of engineering though, it is the PiCoPro ability to provide alternative CPU's that is driving me to use the Beeb.

[hoglet67]

I received the new 6502A and after inserting it made the system worse.

Where did you source the 6502A from?

Can you post a photo?

It seems almost every 6502 being offered for sale on ebay is dodgy/fake/remarked.

[pdsmart]

Thank-you for the info, I sourced the 6502A from an ebayer nikkoelec, very high feedback rating but I wasn't aware there are dodgy chips around, could explain why the 6502B I bought from Hong Kong a while back doesn't work, completely dead - I would have expected some activity with a higher spec chip running at a slower clock rate.

In the last photo at the bottom is the original CPU from the Beeb which is dead. 2nd up is another of the MOS processors I have from 30 years ago this one made in Hong Kong and stamped B (the internet is full of ~ information, some rate these chips at 1, 1.5, 2 and 3Mhz), this one works in the machine but is slightly unreliable even with the 74HCT245 in place. The middle CPU is the one I just bought, it is very unreliable, sometimes the machine doesn't get to the > prompt even with all hardware updates removed.

The MOS MPS6502 unit I have installed (from Korea, over 30 years old from my parts bin) along with the 74HCT245 works flawlessly, I have had the machine running the PiCoPro version of Elite overnight and during the day a modified version of the BBC Timing program which loops through all the modes 0..6 and runs the timing test per mode. It even runs CPM flawlessly. Hence my conclusion, if a dry joint was causing a high resistance then possibly the combo I have in place has a higher source/sink and so overcoming the resistance but If it was introducing an inductive or capacitive element it could be enough to randomly skew the timing, again dependent on the various CPU's and 245 chips used. The other thought if this doesn't turn out to be the issue of a dry joint is one of the support IC's has degraded but finding it will be difficult!

Is there anyway to confirm a fake 6502?

[hoglet67]

The one with the large Rockwell Logo and date code 1429 (year 2014, week 29) is definitely a "fake" as Rockwell stopped making 6502's in 1999.

There are a couple of threads on 6502.org that you might want to read: http://forum.6502.org/viewtopic.php?f=12&t=5946 and http://forum.6502.org/viewtopic.php?f=12&t=5934

[hoglet67]

This was not a PiTubeDirect bug, so closing.