From: Alan P. <ala...@gm...> - 2024-03-05 23:02:07
|
Hi All, I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode. https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1 What an interesting thread , and i was shocked to see my doc referenced. I haven’t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something…. so I came here. First, the document: 1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created. 2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly) 3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey). 4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does. The code path just doesn't make sense on a 128K machine at reset time. Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in. How does the plusD then work under FUSE ? It's very weird. It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion. The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. Relevant routines below, but as I said they are NOT called when the system resets. From Rudy's +D disassembly : THE 'UNPAGE 128 ROM' SUBROUTINE This routine pages out the +D system and returns to the 128K ROM at address #0049. That address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged in. 0046 UNPAGE_BC PUSH BC Stack return address. 0047 UNPAGE_0 OUT (231),A Page out +D system. 0049 RET ? This statement is not reached from above. 004A DEFB #00,#00,#00,#00,#00 Unused locations. THE 'NEW' PATCH When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a a selection is made for 48K or 128K 'NEW' 3137 TO_NEW BIT 4,(IY+1) Jump if not in 128K mode HL contains 313B JP Z,#004F,UNPAGE_HL #11B7, the address of 48K 'NEW'. 313E CALL #5B00,SWAP Call the paging subroutine of the 128. 3141 DI 3142 LD BC,#00C7 Address of 128 'NEW' routine. 3145 JP #0046,UNPAGE_BC Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in 128K mode?? I'm not sure how to do this myself. It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register) I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ? Any thoughts ? Alan |