Next vs. Disciple

Allen Albright
Cesare Falco
People have had the later versions of the disciple running. Tim's very early one can probably be made to run as well but it is different so there is likely something else being missed.
The problem is in i/o conflicts and Ben V wrote a short bit about it that I found while googling the disciple:
https://www.bytedelight.com/?p=5261
It's not an in-depth write up but maybe it's good enough to convey the issues.
In short, peripherals respond to lots more i/o ports than they should and that makes it likely that different peripherals will conflict by using the same i/o ports. On the Spectrum Next, this is very likely because it has a lot of peripherals inside, maybe around 30 compared to three or four on a standard spectrum. Almost nothing would work if the zx next's expansion connector was a simple pass through like on all other spectrums.
So the next has done something new that (on paper) allows all peripherals to work somehow. The expansion bus is not a pass-through, instead there is logic in the machine that hides i/o intended for internal peripherals from appearing on the expansion bus. This way if you talk to a peripheral inside the machine, an outside peripheral will not accidentally be activated. If you want to talk to the outside peripheral, then you have to turn the conflicting internal peripheral off first. Then the i/o will not be hidden.
These OUTs are about turning off certain peripherals so that i/o intended for the disciple, eg, is not hidden. What peripherals are those? If there were no conflicts, no OUTs would be necessary. The fact that it doesn't work without OUTs means there are conflicts. And to know what OUTs to do, what peripherals to turn off inside, you need to know a bit about the disciple hardware. We'll be collating that kind of information and trying to make it automatic in the future, possibly through a dot command, but for now it's manual.
A nuclear bomb approach is to turn everything off. You would be turning the Next into a plain stock 48K machine:
(A)
OUT 9275,137: OUT 9531,128
OUT 9275,136: OUT 9531,0
OUT 9275,135: OUT 9531,0
OUT 9275,134: OUT 9531,1 ;; on newer cores 0
The control registers being written to are the "expansion bus decoding enables" https://gitlab.com/.../master/cores/zxnext/nextreg.txt...
If you want to try to enable some things like AY chip, mouse, etc you can experiment with changing those OUTs.
I couldn't immediately find the disciple info online but it would be better to disable the minimum set of peripherals if that is available.
The OUTs above only apply when the expansion bus is on and it's not on yet. The control register is 128 https://gitlab.com/.../master/cores/zxnext/nextreg.txt...
Let the disciple see a reset by setting up the machine to enable the expansion bus after the next reset.
(B)
OUT 9275,128: OUT 9531,8
Generate a soft reset by pressing the reset button for less than ~1s. You can also do this with:
OUT 9275,2: OUT 9531,1
But that may not work on earlier cores as it's relatively new.
The disciple should work after the above. If not, it could be because you are on an earlier core where setting up the expansion bus does not survive a soft reset. (The core is being improved all the time and that means you can be out of sync with me as I am always on the latest one).
If the above doesn't work because of an older core then instead of (A) change the internal port decodes:
(C)
OUT 9275,133: OUT 9531,0
OUT 9275,132: OUT 9531,0
OUT 9275,131: OUT 9531,0
OUT 9275,130: OUT 9531,1 ;; on newer cores 0
and then enable the expansion bus with (B). The difference is that these internal port decodes take immediate effect and they will persist through a soft reset on all core versions.
We haven't hidden this stuff behind software yet so it may seem a bit daunting, sorry. The hardware does allow you to switch between esxdos (sd card) and disciple, eg, but only on recent development cores.