Enable Disciple Support on 128K and +2 models

[alandpearson]

Hi for historical reasons (folks not understanding the Disciple PAL logic behaviour fully, longer thread below), Disciple has been disabled on FUSE on the 128k and +2 models.
The Disciple logic is now fully understood (I'm the author a document describing it), and I very politely request it is (re)enabled in FuseX for these models.

Here's the full text of the issue on the FUSE list .. Hoping you can apply the relevant patch to FuseX.

On 23 Mar 2024, at 06:08, Sergio Baldoví <serbalgi@gmail.com> wrote:

Thank you for your feedback. Unfortunately the guy that worked on DISCiPLE emulation is not active these days.

DISCiPLE ROM is by default located at 0x0000 except when memory is swapped by 0x7b port. Maybe you have detected a situation where it shouldn't be swapped.

I've disabled the trap at 0x0001 and DISCiPLE seems to work on a 128K, at least with FORMAT and CAT commands, but I think we can do something clever to enable trap 0x0001 when the machine hasn't been reset. See patch 441:
https://sourceforge.net/p/fuse-emulator/patches/441/

El dom, 17 mar 2024 a las 0:02, Alan Pearson (<alandpearson@gmail.com>) escribió:
Replying to my own post in case anyone is listening.

There are two questions that need answered to get disciple working on 128K:

1. Does the Disciple ROM get paged in when PC hits 0001 ? If so, this undoubtedly runs code that won't work when on 128K and ROM0 (128 editor) is in, and ends up calling a 48K ROM NEW routine.
2. Does the Disciple ROM get paged in on RESET ?

Answers

1. I can conclusively say YES, the Disciple ROM gets paged in when PC hits 0001 - EXCEPT when machine is RESET. I've proven this two ways - (1) Recheck the PAL decoding - this is correct and there is no way it won't get paged in when address bus hits 0001 and (2) on a REAL 128K machine by running machine code which pages in EDITOR ROM and then JP to location 0. With Disciple not attached the machine initialises as expected back to the menu system. With the Disciple attached the machine crashes. With Disciple inhibited machine goes back to menu system as expected. This proves beyond a shadow of a doubt that the Disciple is paged in when PC=0001

2. The Disciple gets PAGED OUT on a RESET. The PAL equations prove this, and I've updated the doc with this correction. In RESET the Disciple never sees or reacts to PC=00001 as I'm guessing the reset line stays LOW longer than it takes the PC to advance past 0001, keeping the Disciple OUT via PAL logic. This is obviously a race condition and I've no reason to believe this would be different on a 48K machine.

I also noticed FUSE puts the Disiple ROM at 0x2000 and RAM at 0x0000 which is incorrect - in normal operation ROM should be at 0x0000, and if the Disciple Boot Flip Flop flips them, then it means System needs reloaded,
Described here by RAMSOFT:
3.1 DISCiPLE PORT 7Bh AND MEMORY ADDRESSES ==========================================
Port 7Bh (123 decimal) is available only on the DISCiPLE and has a flip flop attached to it. It can be used to swap the RAM/ROM addresses in this way:
Access ROM RAM Purpose
IN 0x0000 0x2000 reset ff OUT 0x2000 0x0000 set ff
This feature is used by GDOS to know if it necessary to load the system
file from disk on boot or after two consecutive resets without any DOS command between them; UNIDOS ignores this feature, so any swap attempt will result in a system crash.
In GDOS there is a variable located in RAM at offset 0x1DE4 that is set to
0x44 ('D') after a BASIC syntax check (i.e. after a RST 08h with a code lower than 1Bh) and after a bootstrap: this variable indicates that the DOS services have been called almost once. Whenever the user resets the computer, the flip flop attached to port 7Bh is reset, so the ROM will be placed at 0x0000. When the first interrupt occurs, the keyboard scanning routine is called at 0x028E
and the DISCiPLE memory is automatically paged in. At offset 0x028E in the DISCiPLE's ROM there's a routine that checks if the variable we said above holds 0x44: if it's the case, then the same routine puts 00h in there to say
that DOS services haven't been called since last reset; otherwise the routine
sets the variable to 0x53 ('S') and copies the first 2335 (0x091F) bytes of
ROM in the RAM: in this case the system file has to be loaded again.
When all is finished, the memories will be swapped again (i.e. the flip flop
will be set) by OUTing to port 7Bh, the DISCiPLE paged out by OUTing to port BBh and the keyscan routine is finally executed.
INning from port 7Bh has the same meaning of a system reset for the DOS, so after reading 2 times from port 7Bh without typing a DOS command between them the system file needs to be reloaded.
NOTE that since all this is based on the keyscan routine in the Spectrum's ROM, nothing will happen by INning from port 7Bh if the call is not performed (i.e. if interrupts are disabled in IM 1 or we're not in IM 1 or keyboard is scanned in a custom way); however the last operation with port 7Bh must be an OUT before the routine in the ROM is executed if you want to keep the system safe by resetting once.

So to get this working under emulation in 128K mode, we need to do things:

1. Not page the disciple in when it hits location 0001 (easiest not to do it in any circumstances)
2. Change the ROM to be located at 0x0000 and observe the function of the flip flop as described above.

[Haroldo64]

Great, Thank you !