Some more info on NOP slides / Clock slides here as well: https://www.stardot.org.uk/forums/viewtopic.php?t=17465 (My God ... 6 years ago, time flies!)
If you want to get this working, unfortunately you will probably have to delve quite deeply into how the CRTC on the BBC Micro/Master works and what's actually happening when you set the CRTC registers and the ULA register. Essentially, you have several problems here, some more manageable than others, and they interact with each other!
- When your interrupts fire, there is a variable latency of somewhere between 1 and 7 cycles before your interrupt handler code actually gets to run. Now in some cases this is fine, but in others it can really matter. You can mitigate this using NOP slides, but they can be a pain to get working.
- When you change the ULA from 1MHz to 2MHz mode or back, you are literally changing the speed at which the CRTC operates (it is the ULA that generates the clock signal that drives the CRTC) ... which means that ideally you would carefully control how many CRTC characters there were on the line to make sure that you emitted <some number of characters at 1MHz> and <some other number at 2MHz> and the total added up to exactly 64 microseconds along the line. If you don't do that then you have effectively made the line take a longer or shorter time than it should have, so the whole frame is a bit too short or a bit too long ... if you do this enough times I can imagine that some TVs would get confused.
To start with dealing with this, it might be a good idea to get an emulator that lets you easily examine the CRTC state (e.g. B2) and take a look at what the counters are set to when your interrupts fire, and when your interrupt handler code is running. What is the horizontal and vertical counter set to at the point you change their latch values, etc? What happens when you change the ULA mode?
As I said, emulation is also unlikely to match real hardware in this case because exactly what happens when you change ULA 1/2 MHz mode isn't necessarily modelled accurately by emulators. On real hardware, I have been told that it does something a bit 'weird' ... the ULA clock signal wobbles a bit before settling into the new state, etc.
I don't want to discourage you, this stuff can be great fun and rewarding to dig into. But it can be challenging to get right!
If you want to get this working, unfortunately you will probably have to delve quite deeply into how the CRTC on the BBC Micro/Master works and what's actually happening when you set the CRTC registers and the ULA register. Essentially, you have several problems here, some more manageable than others, and they interact with each other!
- When your interrupts fire, there is a variable latency of somewhere between 1 and 7 cycles before your interrupt handler code actually gets to run. Now in some cases this is fine, but in others it can really matter. You can mitigate this using NOP slides, but they can be a pain to get working.
- When you change the ULA from 1MHz to 2MHz mode or back, you are literally changing the speed at which the CRTC operates (it is the ULA that generates the clock signal that drives the CRTC) ... which means that ideally you would carefully control how many CRTC characters there were on the line to make sure that you emitted <some number of characters at 1MHz> and <some other number at 2MHz> and the total added up to exactly 64 microseconds along the line. If you don't do that then you have effectively made the line take a longer or shorter time than it should have, so the whole frame is a bit too short or a bit too long ... if you do this enough times I can imagine that some TVs would get confused.
To start with dealing with this, it might be a good idea to get an emulator that lets you easily examine the CRTC state (e.g. B2) and take a look at what the counters are set to when your interrupts fire, and when your interrupt handler code is running. What is the horizontal and vertical counter set to at the point you change their latch values, etc? What happens when you change the ULA mode?
As I said, emulation is also unlikely to match real hardware in this case because exactly what happens when you change ULA 1/2 MHz mode isn't necessarily modelled accurately by emulators. On real hardware, I have been told that it does something a bit 'weird' ... the ULA clock signal wobbles a bit before settling into the new state, etc.
I don't want to discourage you, this stuff can be great fun and rewarding to dig into. But it can be challenging to get right!
Statistics: Posted by VectorEyes — Fri Jun 13, 2025 9:32 pm