Ed's Diary 2016 06 02

Ed at Dave's again

Dave had noticed that the ISR sometimes fires again immediately after a write cycle. This seems to be harmless, but investigation shows that it's probably a bounce on the nTube line. A bit of capacitance at the Pi end helped. Possibly better shielding of the tube cable will help - we're not presently grounding all the grounds.

Oddly, clearing the event register at the end of the ISR doesn't stop the double ISR - perhaps the interruptedness has latched... we are using FIQ, which is a bit like NMI on 6502.

Dave tried swapping in the Tube Silencer and that was better - did the double ISR less often - but not perfect.

Dave ran a number of different emulated CPUs, and we saw a few LATE messages which indicate that the user might have trouble... this means the event handler was taking too long?? If so, that could be due to cache misses on the main application side. Or LATE can just mean a mistriggered ISR - it means nTube is low in the sample passed to the event and yet nTube was low at the beginning of the ISR.Possibly the ISR saw very high latency or saw a short nTube? Or, if we were sampling a read, waiting for the falling edge of the clock, and we'd already missed the relevant clock edge and spun until the following one.

But Dave does believe that first boot (of, say, PanOS) is likely to see a LATE when a subsequent boot won't. Which sounds like cache misses. And yet the ISR should be locked in!

(Dave now has a choice of 80286, 6502, ARM, ns32k on the PiTube)

Dave also ran up the Project A simulator on the emulated ARM eval system - it has an ARM crash. Perhaps this early Basic isn't quite right? Dave says he's previously run the program on BAS135 on a later ARM. So maybe this early BASIC isn't bomb proof. The crash happens on both Pi and Matchbox, so not a specific issue for Pi.

(Dave now has extended the read behaviour, it waits an extra half-cycle in case the read was a dumy read preceding a write. This causes a bit of a performance loss, but allows use of *FX to poke at the Tube config registers.)

(Dave has recently added in a clock gating of the buffer direction, so the Pi drives later into the Beeb and is less likely to contend. This turns out not to be necessary - his troubles on the Master were resolved when he removed the serial resistors and damping capacitors. All that remains is the Reset low pass filter.)

We then had a bit of a play with a beeb816

• issue 7, quite expanded, boots OK and seems to work

We tried to load boot816 support ROM into an SWRAM and eventually succeeded but only by replacing the original 6502. So the 816 is unable to write correctly to the swram. It's OK with the datacentre. But it hangs ADFS at init time. And is unhappy to coexist with RAMFS (which belongs to the datacenter.) We tried hooking up to the 8MHz from pin 7 of U6, the video ULA. After HIPOKE 800003 8 the machine hung. So we can run with the 816 on this machine but we can't run at high speed. Having unplugged the datacentre we got a little echo and output but the machine misbehaved: like a spurious BRK repeatedly so impossible to type anything. We didn't try to run a program at normal clock speed, so we don't know how stable it was... except no, we think we did run CLOCKSP and got the expected 2MHz result. (And we reran it, so that was OK) We do see just a little video noise in mode 7.

Let's try with an older machine: issue 3 Boots fine with the 816 in. But then later it didn't boot at all. So we only got one try. (We have no utility ROM here anyway)

Had a look at Ed's beeb, an issue 4. Video wasn't syncing quite right - consistent with experience at Rev's - turned out to be a missing jumper at S31 - West position. We were seeing video RAM glitches and colour glitches too - that turned out to be the video ULA heatsink shorting against resistors to the West. Put some tape on the heatsink and bent the resistors away. Dave also took out a RAM chip and cleaned the contacts but they didn't turn out to look as if they needed that.

And the beeb816 boots happily!

Some video noise in Mode 7 - black specs. If we REP.V.255:U.FA. then we see lots of black streaks turning to cyan - only in Mode 7. And we see that with the 816, not with the 6502. What about a 65C02? Machine won't boot. With a modern UMC 6502 it boots OK. Is the CPU socket dodgy? I might have stretched it with the turned-pin stacked socket. (Dave is using a little block of PCB cleaner to clean up pins) Dave offered to make up an MMFS ROM, so Ed can hook up an SDcard to the userport for solid state storage. With that in place, we could easily try CLOCKSP And it's not good: sometimes it finds a completely spurious syntax error. It's possible that sometimes RAM is being misread - at least in Ed's beeb. But replacing the CPU makes the machine fine again - it runs Planetoid.

Back to Dave's issue 7.

Dave noticed that spaces on screen were never noisy. So we poked values into the MODE 7 screen memory, looking for video noise. We only saw it with some values:

0x23

0x25
0x26
0x27

0x2B
0x2E
0x2F

0x42
0x43

0x45
0x46

And we can't see any pattern there.

What did we learn:

• issue 3 - barely worked/didn't work
• issue 7 (ed) - worked, some spurious errors, lots of mode7 video noise
• issue 7 (dave) - worked, no odd errors, a little mode7 noise.

On Dave's issue 7, issuing *OVERLAYOFF caused a garbage screen and machine death. So it must be copying the wrong data, or copying it incorrectly, or the data we expected to be a clean and current image of low memory was no such thing.

Perhaps we defaulted to OVERLAYON mode?? No, it seems not.

It seems that OVERLAYOFF always crashes the machine.

Although we maybe did see it work once!

Back to Development Diary