Here's the stardot forum thread about this: stardot.org.uk/forums/viewtopic.php?p=330703#p330703 And a link to the circuit diagram for the BBC Micro: mdfs.net/Info/Comp/BBC/Circuits/BBC/bbc.gif The address decode logic is in the top centre of the diagram, and IC23 in particular is gathering up all the chip select signals for "slow" I/O devices in order to decide whether or not to stretch the clock, so that's a good place to look if you want to know whether something is fast or slow. The 6522 VIA that I removed from the machine is IC69 (looks like 59 in the diagram!) in the centre left, connected to the printer and user ports, and IC73 in the centre right is the ADC. The floppy disc controller that was already missing is IC70 in the top left. In the video I referred to a transceiver between the CPU data bus and the RAM data bus - the RAM chips are in a 4x4 grid at the bottom centre of the diagram, and the transceiver is IC14, just up and right from there. You can also see the pull-down resistors next to that.
I'd say the fact that TTL logic inputs are emitters of common base connected transistors might mean that if the bus is left floating it will tend to go towards VCC.
I too am a bit mystified as to what's going on there. I've certainly seen data bus capacitance hold values that get read back when reading unmapped address space, but I think in my case this was on machines that were not sharing the bus with video on the off-cycles. You might get a bit more insight by adding the tranceiver direction and enable on two more channels on your 'scope so you can see when the memory side of the bus is being disconnected and reconnected. You could also, with careful selection of the memory you're using, monitor an address pin to see when the I/O address is being read: you just need to make sure the code is running from memory where that address pin is always the opposite of what it is for the I/O address. (The easiest way to do this would be to write a small program that runs entirely in the lower 32K of the address space and then monitor A15: when that goes high you know you're accessing the I/O port.)
Yes. The video system is isolated by the transceiver, so when the clock is low the video/RAM is cut off and the main data bus floats down a bit before the next cycle starts. That much seems to be occurring as expected. I'd like to probe the chip selects for all the devices still on the data bus really to see if any might be active around that time. The ROM was a really promising possibility because it technically overlaps these address ranges. The really weird thing though is the sequence of levels I'm seeing on this data bus pin. I don't know which one I was reading or exactly what the basic interpreter is executing, but it's not what I expected for sure - all those low cycles just before the actual read are very odd! I should have used my own assembly code really to remove that variable.
It's funny, I haven't seen a BBC for literally decades... But that keyboard, the layout of the internals, everything about just seems so very very very familiar. I love a bit of assembly language on the BBC. These days I do assembly on AVR, MIPS, perhaps a bit of ARM and I always wish that I still had an assembler where I could do a bit of precalculation and stuff like that with the sheer ease of having an assembler built into BBC BASIC.
I agree with your conclusion. I think there is some capacitance on the other side of a multiplexer/transceiver IC. Looking at the schematic, I'd probe around each side of IC14 (74LS245). Perhaps probe both sides of D0 along with the /OE or similar. I'd also try probing the bus with the main clock stopped - see if anything is dragging the bus high, low, or some half-rail level.
I'm not sure there's a good way to stop the clock. I need to probe more things anyway though. My main suspicions are the transceiver (because the last thing it did should have been to output FE) and the CPU itself (in case its input has enough capacitance to recharge the data bus if nothing else is driving it).
@@GeorgeFoot Does the behaviour change if you parallel a 1k across, say D7 to ground? Id scope both sides of the main transceiver. And to stop the clock, I'd try shorting the crystal's output side (oscillator circuit input) to ground. That should stop it without damaging anything.
My eye sees a minor spike just before the slowly falling low(0) at _exactly_ the same point as when a normal _high_ is generated (based on the comparison of the previous bits in relation to the clock cycle), and _vaguely_ indicates (to me) a _reflection_ (?) from something else driving high at that point, the _wierd_ part just being where and what you are looking at on the scope, and the _clock stretch_ version is that difference between reading a 0 and 254 (as you described earlier). If the bus is not being accessed on the side you are looking at, then something else "on the other side" (?) where you _are not looking_ is driving it high. You say the video and RAM are "on the other side" (of a transceiver) but is there a single line going around _both sides_ of the transceiver, and you only get to see the result _after_ "this side" _stops_ driving that line _low_ .
Are the components CMOS? I've seen the capacitance of non driven lines persistently reading as a high after a high signal. Surprisingly long decay on CMOS pins. A short lived high glitch ( that does no harm to normal operation) will quickly charge the bus up to 5v and decay slowly. I've seen the decay last seconds on lightly attached busses. A sharp right side edge would be possibly something asserting low and so draining the charge
No I don't think the original BBC Micro used any CMOS parts. It's mostly LS, with some F and S series components, and the monolithic ICs are all NMOS I think.
Does the VIA also have pull down resistors? If the bus is pulled down, but the VIA input is not (and other chips are not) would they not report floating or possibly default values, or interference from something nearby? Just thinking out loud, really.
I've removed the user VIA from the system completely anyway, in this test, so anything that happens inside it or on the other side of it should be excluded.
@@GeorgeFoot I just had a thought. I don’t remember if you covered this or not. What if the logic that enables the VIA or other chips is slightly off, so that the data is actually coming from somewhere else, but the VIA data overrides it when active?
Yes, that's the idea here - we're putting the bus into a state where nothing should be driving it, and seeing a rather consistent residual charge on the bus. I'm just curious where it's coming from. The theory was that it was the last thing that was on the bus, and I was trying to verify that with the scope, but the period of low levels just before this read was unexpected and contrary to the theory. The charge must be coming from somewhere else though as you say, I'm planning to probe the address decode logic and see if I see any activity there that would account for it.
I thought it was a great video. To me, it looks like the loading on the data and address buses is pretty high. When I designed my 6502 computer in the 70's, I isolated the 6502 chip data bus with bus transceivers and lazy data wasn't a problem. You can get a hint that they had loading issues because there are pull down resistors on the data bus. I'm not a professional designer, but that sounds a little kludgy to me.
See what the official hardware designer has to say about it here: ua-cam.com/video/y4WG549i3YY/v-deo.html I think he's alluding to problems with writes rather than reads though.
@@GeorgeFoot As you know, the BBC Micro wasn't in the States. That's interesting that Professor Furber discussed the "finger in the air engineering". That's the same experience I had in the late 70's. Sometimes I would put in a one shot just to make something work. And my scope (not high end) had just enough capacitance that it would affect the signal so sometimes it would work with the scope attached and sometimes it wouldn't.
They had a lot of trouble getting it ready for the States, it wasn't designed to meet the regulations there - he talks about it in this interview at around 24 minutes in: ua-cam.com/video/Q5BcbwkCSsM/v-deo.html
Here's the stardot forum thread about this: stardot.org.uk/forums/viewtopic.php?p=330703#p330703
And a link to the circuit diagram for the BBC Micro: mdfs.net/Info/Comp/BBC/Circuits/BBC/bbc.gif
The address decode logic is in the top centre of the diagram, and IC23 in particular is gathering up all the chip select signals for "slow" I/O devices in order to decide whether or not to stretch the clock, so that's a good place to look if you want to know whether something is fast or slow.
The 6522 VIA that I removed from the machine is IC69 (looks like 59 in the diagram!) in the centre left, connected to the printer and user ports, and IC73 in the centre right is the ADC. The floppy disc controller that was already missing is IC70 in the top left.
In the video I referred to a transceiver between the CPU data bus and the RAM data bus - the RAM chips are in a 4x4 grid at the bottom centre of the diagram, and the transceiver is IC14, just up and right from there. You can also see the pull-down resistors next to that.
I'd say the fact that TTL logic inputs are emitters of common base connected transistors might mean that if the bus is left floating it will tend to go towards VCC.
Wearing headphones, I can really hear the BBC's SMPS whining away!
It's such a distinctive sound, it reminds me of my childhood - I think it's the speaker though, not the power supply.
I too am a bit mystified as to what's going on there. I've certainly seen data bus capacitance hold values that get read back when reading unmapped address space, but I think in my case this was on machines that were not sharing the bus with video on the off-cycles.
You might get a bit more insight by adding the tranceiver direction and enable on two more channels on your 'scope so you can see when the memory side of the bus is being disconnected and reconnected. You could also, with careful selection of the memory you're using, monitor an address pin to see when the I/O address is being read: you just need to make sure the code is running from memory where that address pin is always the opposite of what it is for the I/O address. (The easiest way to do this would be to write a small program that runs entirely in the lower 32K of the address space and then monitor A15: when that goes high you know you're accessing the I/O port.)
Yes. The video system is isolated by the transceiver, so when the clock is low the video/RAM is cut off and the main data bus floats down a bit before the next cycle starts. That much seems to be occurring as expected.
I'd like to probe the chip selects for all the devices still on the data bus really to see if any might be active around that time. The ROM was a really promising possibility because it technically overlaps these address ranges.
The really weird thing though is the sequence of levels I'm seeing on this data bus pin. I don't know which one I was reading or exactly what the basic interpreter is executing, but it's not what I expected for sure - all those low cycles just before the actual read are very odd! I should have used my own assembly code really to remove that variable.
It's funny, I haven't seen a BBC for literally decades... But that keyboard, the layout of the internals, everything about just seems so very very very familiar.
I love a bit of assembly language on the BBC. These days I do assembly on AVR, MIPS, perhaps a bit of ARM and I always wish that I still had an assembler where I could do a bit of precalculation and stuff like that with the sheer ease of having an assembler built into BBC BASIC.
I agree with your conclusion. I think there is some capacitance on the other side of a multiplexer/transceiver IC. Looking at the schematic, I'd probe around each side of IC14 (74LS245). Perhaps probe both sides of D0 along with the /OE or similar. I'd also try probing the bus with the main clock stopped - see if anything is dragging the bus high, low, or some half-rail level.
I'm not sure there's a good way to stop the clock. I need to probe more things anyway though. My main suspicions are the transceiver (because the last thing it did should have been to output FE) and the CPU itself (in case its input has enough capacitance to recharge the data bus if nothing else is driving it).
@@GeorgeFoot Does the behaviour change if you parallel a 1k across, say D7 to ground? Id scope both sides of the main transceiver. And to stop the clock, I'd try shorting the crystal's output side (oscillator circuit input) to ground. That should stop it without damaging anything.
My eye sees a minor spike just before the slowly falling low(0) at _exactly_ the same point as when a normal _high_ is generated (based on the comparison of the previous bits in relation to the clock cycle), and _vaguely_ indicates (to me) a _reflection_ (?) from something else driving high at that point, the _wierd_ part just being where and what you are looking at on the scope, and the _clock stretch_ version is that difference between reading a 0 and 254 (as you described earlier). If the bus is not being accessed on the side you are looking at, then something else "on the other side" (?) where you _are not looking_ is driving it high. You say the video and RAM are "on the other side" (of a transceiver) but is there a single line going around _both sides_ of the transceiver, and you only get to see the result _after_ "this side" _stops_ driving that line _low_ .
Are the components CMOS? I've seen the capacitance of non driven lines persistently reading as a high after a high signal. Surprisingly long decay on CMOS pins. A short lived high glitch ( that does no harm to normal operation) will quickly charge the bus up to 5v and decay slowly. I've seen the decay last seconds on lightly attached busses.
A sharp right side edge would be possibly something asserting low and so draining the charge
No I don't think the original BBC Micro used any CMOS parts. It's mostly LS, with some F and S series components, and the monolithic ICs are all NMOS I think.
Does the VIA also have pull down resistors? If the bus is pulled down, but the VIA input is not (and other chips are not) would they not report floating or possibly default values, or interference from something nearby? Just thinking out loud, really.
I've removed the user VIA from the system completely anyway, in this test, so anything that happens inside it or on the other side of it should be excluded.
@@GeorgeFoot I just had a thought. I don’t remember if you covered this or not. What if the logic that enables the VIA or other chips is slightly off, so that the data is actually coming from somewhere else, but the VIA data overrides it when active?
Yes, that's the idea here - we're putting the bus into a state where nothing should be driving it, and seeing a rather consistent residual charge on the bus. I'm just curious where it's coming from. The theory was that it was the last thing that was on the bus, and I was trying to verify that with the scope, but the period of low levels just before this read was unexpected and contrary to the theory.
The charge must be coming from somewhere else though as you say, I'm planning to probe the address decode logic and see if I see any activity there that would account for it.
nice video. im more of a c64 user but still fun to watch.
I thought it was a great video. To me, it looks like the loading on the data and address buses is pretty high. When I designed my 6502 computer in the 70's, I isolated the 6502 chip data bus with bus transceivers and lazy data wasn't a problem. You can get a hint that they had loading issues because there are pull down resistors on the data bus. I'm not a professional designer, but that sounds a little kludgy to me.
See what the official hardware designer has to say about it here: ua-cam.com/video/y4WG549i3YY/v-deo.html
I think he's alluding to problems with writes rather than reads though.
@@GeorgeFoot As you know, the BBC Micro wasn't in the States. That's interesting that Professor Furber discussed the "finger in the air engineering". That's the same experience I had in the late 70's. Sometimes I would put in a one shot just to make something work. And my scope (not high end) had just enough capacitance that it would affect the signal so sometimes it would work with the scope attached and sometimes it wouldn't.
Also, one chip's read is another chip's write. Bus loading issues can go both ways.
They had a lot of trouble getting it ready for the States, it wasn't designed to meet the regulations there - he talks about it in this interview at around 24 minutes in: ua-cam.com/video/Q5BcbwkCSsM/v-deo.html
@@GeorgeFoot Thanks for the info.