The Disciple clone... doable?

135

Comments

  • zubzub
    edited February 2013
    Okay, some slightly bad news, I'm afraid...

    The changes that I was experimenting with to get DISCiPLE emulation working with the 128K break support for keeping GDOS in memory after a soft reset. I'm also not confident that they won't introduce other problems.

    This means it is definitely not a simple matter of going along with the changes that I mentioned. We either need to get the GAL dump, or reverse engineer a PAL again.

    It is just about plausible that the equations are correct but that the English language description of them is not... but I think this is unlikely.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I'm sorry I may have not read this thread correctly, what GAL are you guys referring to? My Disciple has PAL's. Are you also saying the PAL's are protected from reading, because I've successfully read my PAL's and burned replacement PAL's for my other Disciple (which was probably the one bverstee has photographed because he has one of mine). Anyway, would those files be useful?
  • edited February 2013
    zub wrote: »
    I really wonder whether the problem is that half of the ROM is missing... and the half that is missing detects whether the machine is a 128K, and does something different if that is the case.
    Just consider the DOS as 16K, of which 8K is burnt in ROM and 8K is loaded in RAM from the required boot diskette. Both parts look alike but are no copies.
    As the 128k detection happens in Disciple-RAM it cannot be found in ROM.

    You may also realise that GMTs 'next model' the SAM came on the market without boot function from disk, that the patch ment to solve that did not work, and that all ROMs had to be replaced. No further comment...
  • edited February 2013
    Severino wrote: »
    In the +D they used a bigger rom and hard wired to "0" A13 and A14.

    The web where I read that said that could be that MGT had stock of those roms and had to use them.

    Maybe mgt had in mind more code for the rom, maybe the only thing that lacks the disciple, a RS-232 and... well I don't know.

    Have you tried the simulation with 2 copies of the same rom?

    48k emulation? 128k?

    Regards.

    what year was it? 1986 the 128 had rs232, so maybe mgt was past by some how???
    my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
  • zubzub
    edited February 2013
    roko wrote: »
    Just consider the DOS as 16K, of which 8K is burnt in ROM and 8K is loaded in RAM from the required boot diskette. Both parts look alike but are no copies.
    As the 128k detection happens in Disciple-RAM it cannot be found in ROM.

    Please avoid encouraging people to think of the ROM and the DOS as two halves of the same thing! I'm not sure, but there's evidence to suggest they're owned by different parties, and emulators should be careful about pre-loading the RAM, in any case. They really aren't that much alike, although they do (obviously) share a few entry points.

    The original comment was regarding my suspicion that we had 8 KiB of ROM (not RAM) missing from the dump, which resulted from me believing the incorrect schematics on WoS. It now seems likely that no DISCiPLE ever came with a 16 KiB ROM. There is nothing more to discuss.
    You may also realise that GMTs 'next model' the SAM came on the market without boot function from disk, that the patch ment to solve that did not work, and that all ROMs had to be replaced. No further comment...

    I'm quite aware of this, although my recollection is that the POKEs that MGT sent out did succeed in getting SamDOS to load. I hardly see the point you're making, though.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Cameraman wrote: »
    I'm sorry I may have not read this thread correctly, what GAL are you guys referring to? My Disciple has PAL's. Are you also saying the PAL's are protected from reading, because I've successfully read my PAL's and burned replacement PAL's for my other Disciple (which was probably the one bverstee has photographed because he has one of mine). Anyway, would those files be useful?

    My apologies, I've got my wires crossed, slightly. bverstee simply used a GAL to replace one of the DISCiPLE PALs. Quoting from bverstee's blog: "MGT enabled security on the PAL chips so it was not possible to read the contents and clone them back then" and "Fortunately someone once received a repaired Disciple interface with PAL chips that did not have that security, and he was able to read the contents and publish it on the net". Is there any chance that this someone was you? :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    roko wrote: »
    I not only studied DUM and DEE, but it appears that I even wrote a report of it.
    Find it here: http://www.biehold.nl/roelof/disciplePAL-analysis.rtf

    Thanks! I've taken a closer look at this and found that the traps are in the same place as documented elsewhere (0x0001, 0x0008, 0x0066 and 0x028e), so I'm still struggling to see how we would avoid the rather crazy path of execution that I posted earlier...

    Perhaps the DISCiPLE really does go through that crazy path of execution when plugged into a 128K machine... but in that case, I would need to find out why the emulation goes wrong later on. If it really does do this, then this could just be a simple bug in Fuse.

    It seems RealSpectrum doesn't trap 0x0001 or 0x0008, and doesn't page the DISCiPLE in or out upon reset! So clearly, even RamSoft(!) couldn't get it working properly, so we have a problem. I'm still not quite sure why I observed subtly different behaviour each time I did a reset under 128K emulation, though!
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    Please avoid encouraging people to think of the ROM and the DOS as two halves of the same thing!
    In my view this even is the only way of getting grips. But I encourage all approaches that help people understand things.
    Apart from that I really cannot see why the code in ROM, which is Operating the Disk System (even does the formatting!) should not be the DOS. If not DOS, then what should it be called in your opinion?

    Could the problems with emulators that you describe be explained by assuming that both 8kROM and 8kRAM are in one 16k 'ROM' and that the two banks are not in correct position for a proper 'boot'? Just a thought....
  • edited February 2013
    zub wrote: »
    It seems RealSpectrum doesn't trap 0x0001 or 0x0008, and doesn't page the DISCiPLE in or out upon reset! So clearly, even RamSoft(!) couldn't get it working properly, so we have a problem. I'm still not quite sure why I observed subtly different behaviour each time I did a reset under 128K emulation, though!
    I think it is a 'sign of the times' that we have to query the action of an emulator, let alone the original hardware/firmware. ;-)]
    roko wrote: »
    In my view this even is the only way of getting grips. But I encourage all approaches that help people understand things.
    Apart from that I really cannot see why the code in ROM, which is Operating the Disk System (even does the formatting!) should not be the DOS. If not DOS, then what should it be called in your opinion?

    Could the problems with emulators that you describe be explained by assuming that both 8kROM and 8kRAM are in one 16k 'ROM' and that the two banks are not in correct position for a proper 'boot'? Just a thought....

    I think that the distinction is a 'grey line'. What we clearly thought of as a '"D"OS' back in the '80s, '90s has been taken over by the modern device-independent OS. Similarly, I suspect there is no conciousness as to where the the OS of the DISCIPLE should completely reside - lower 8K ROM or 16K combined firmware.
  • edited February 2013
    Thanks for the pictures!
    I was checking the Format magazine against the schematics. I was reading the diskette controller article and found a difference with the schematic. I checked with the +D "corrected" schematic.
    I know they're completely differrent, but the differences are found in the output of the WD1772, R13-R16 are connected from Vcc(5v) to output pins on the Wd1772, some goes to the IC3 and some directly to the IDC34 connector. In the schematic R16 is connected to pin 20 (motor) of the 1772, but in Format magazine this pin is never connected to a resistor, this resistor goes to pin 25 (/WRPT), in both the Format article and the corrected +D schematic that someone built and worked.
    Thanks to the pictures under the connector I can locate those diodes. It's funny that under R17 "330K" can be read and the color code of the resistor indicates 330 ohms.
    Regards.
  • edited February 2013
    zub wrote: »
    "Fortunately someone once received a repaired Disciple interface with PAL chips that did not have that security, and he was able to read the contents and publish it on the net". Is there any chance that this someone was you? :-)

    I never had mine repaired however, one of the two Diciples I owned had unprotected Pal's. Maybe I was just lucky. Same for one of my Multiface 3's. Also an unprotected Pal.
  • zubzub
    edited February 2013
    roko wrote: »
    In my view this even is the only way of getting grips. But I encourage all approaches that help people understand things.
    Apart from that I really cannot see why the code in ROM, which is Operating the Disk System (even does the formatting!) should not be the DOS. If not DOS, then what should it be called in your opinion?

    You're absolutely right that the DISCiPLE's 'system file' cannot be understood without referring to the DISCiPLE ROM, but to a limited extent, you also need the Spectrum ROM to make sense of everything!

    On the other hand, the DISCiPLE ROM can be understood on its own. It would be quite possible to use the 8K of RAM in the DISCiPLE to implement alternative hooks, allowing use of a FAT filesystem, or loading/saving of snapshots to tape, in Mirage Microdriver?style. Alternatively, with a simple enough serial interface connected to the passthrough connector, I imagine something like a the SAM Messenger could be produced... or snapshots could be loaded/saved over the Sinclair network, instead! On the +D, there was also BetaDOS, but I wouldn't be surprised if it would be impossible to port this to the DISCiPLE due to lack of space in RAM (since the DISCiPLE needs 275 bytes for its network channel buffer, alone).

    I'll also accept that some code that is in GDOS on the DISCiPLE is found in ROM on the +D, such as the core of the NMI handling. Actually, it's fortunate that this wasn't in ROM on the DISCiPLE since it means it can be fixed without replacing the ROM!

    ... but I still believe it to be a mistake to distribute the two together as one single binary, or to read the DISCiPLE ROM without an understanding that the system file might ever have been changed (it was).

    Note that the DISCiPLE RAM contains more than just code. It also contains the sector buffer (which might be left containing personal information, if anybody still used the DISCiPLE for such things!), as well as printer and disk drive settings. Emulators certainly shouldn't pre-load these settings without giving the user the option to use their own.
    Could the problems with emulators that you describe be explained by assuming that both 8kROM and 8kRAM are in one 16k 'ROM' and that the two banks are not in correct position for a proper 'boot'? Just a thought....

    I'm not sure quite what you mean. If the RAM should end up as write-protected, the interface would be very clearly broken, even under 48K emulation, since the DISCiPLE's system variables and buffers (including the per-file bit address map, whole-disk sector address map and individual sector buffer) are held in the DISCiPLE RAM.

    If you're asking whether starting with a preinitialised DISCiPLE RAM could be a problem... probably not, since this is equivalent to loading GDOS, and then resetting the machine. The DISCiPLE ROM will detect that GDOS is already loaded, and will then hardly do anything on reset... but that should be okay. If there's corruption in the DISCiPLE RAM, that would almost certainly cause problems. Ruling this out would just be a matter of modifying the 16K image so that the RAM section is pre-initialised with 0xff or 0x00, although I must confess, I'm not altogether sure which of those values (if any) the RAM would contain on a cold boot on real hardware.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Cameraman wrote: »
    I never had mine repaired however, one of the two Diciples I owned had unprotected Pal's. Maybe I was just lucky. Same for one of my Multiface 3's. Also an unprotected Pal.

    Interesting! It seems you were. I've seen comments from several sources saying that th PALs were usually protected.

    Either way, though, I guess we need to set about comparing the various reverse engineered and dumped PALs, to see whether the equations are complete. So far I've seen two sets of fusemaps and equations: those from roko (Roelof Koning) that he's kindly reminded us of, and those from Alan Pearson, dating from 1995 and 2003, respectively. Cameraman, would you mind contributing what you have, too? :-)

    Alan stated that his information was obtained from reverse engineering performed by Rudi Biesma. roko, were yours also from Rudy, or did you dump the PAL directly or perform your own reverse engineering, independently? I can see the fusemap, but can't tell whether that's what you started with, or whether it's what you finished with!

    It's possible that there's a gap in my understanding of the 128K, especially concerning ROMCS. My understanding is that 'ROM 0' will be paged in at first, and handling of ROMCS is independent of whether ROM 0 or ROM 1 would otherwise be paged in. That means that peripherals can override access to either page of the ROM, and must therefore snoop on bit 4 of OUTs to port #7ffd to determine which ROM is in use, if they should only trap execution in one of the ROMs. As far as I know, nobody has said that the DISCiPLE does this, but it looks to be required to avoid a rather crazy path of execution.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Okay, I'm rapidly stepping outside of my area of expertise here, but I've compared various files in Alan Pearson's DISCiPLE PALs archive with the fusemaps in roko's document, and don't really understand what I'm seeing.

    Alan's 'PAL9.jdc' appears identical to roko's fusemap for IC9 (DEE). Alan's palic9.jed is quite a bit different, though:
    --- PAL9.jdc
    +++ palic9.jed
    ...
    -L1320 0111100101111111111110110111101101010111
    -L1360 1010101010111111101101110111101110101011
    -L1400 0110011010111111101101111011011101101011
    -L1440 1001101001111111101101110111011101101011
    -L1480 1010101010111111101101111011101110100111
    +L1320 1010101010111111101101110111101110101011
    +L1360 1010101010111111101101111011101110100111
    +L1400 1001101001111111101101110111011101101011
    +L1440 0110011010111111101101111011011101101011
    +L1480 0111100101111111111110110111101101010111
    

    Alan's 'al.jed' appears identical to roko's fusemap for IC8 (DUM). al.jed and al.jdc are virtually identical ? presumably these are just subtly different file formats. al.jed and palic8.jed have a single-bit difference, though:
    --- al.jed
    +++ palic8.jed
    ...
    -L0120 1111101010111011111111111011101110101010
    +L0120 1111101010111011111111111011111110101010
    

    Are these genuine differences, or possibly a different representation of the same logic? If they are genuine differences, do the files relate to two different issues of the DISCiPLE, or is one set of fusemaps incorrect?

    Alan only links to palic8.jed and palic9.jed from DisciplePals.html page, which worries me, as these are the ones that are different to roko's fusemaps. (Well, he links to alice4.jed, too, but that's for the +D...) He doesn't mention al.jed, al.jdc or PAL9.jdc, so why are they even there? Have they just been left in by accident? In which case, is one set of equations based on incorrect fusemaps?

    I presume 'jdc' and 'jed' are both just abbreviations of 'JEDEC' (Joint Electron Devices Engineering Council) and the only differences between files should just be in the form of metadata.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    zub wrote: »
    --- PAL9.jdc
    +++ palic9.jed
    ...
    -L1320 0111100101111111111110110111101101010111
    -L1360 1010101010111111101101110111101110101011
    -L1400 0110011010111111101101111011011101101011
    -L1440 1001101001111111101101110111011101101011
    -L1480 1010101010111111101101111011101110100111
    +L1320 1010101010111111101101110111101110101011
    +L1360 1010101010111111101101111011101110100111
    +L1400 1001101001111111101101110111011101101011
    +L1440 0110011010111111101101111011011101101011
    +L1480 0111100101111111111110110111101101010111
    

    On closer inspection, I notice that this is a rearrangement of rows:
    PAL9.jdc | palic9.jed
    ---------------------
    L01320   | L1480
    L01360   | L1320
    L01400   | L1440
    L01440   | L1400
    L01480   | L1360
    

    Given this, is it possible for both PAL9.jdc and palic9.jed to be valid?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    The fuse table for GAL (JED file) is generated from a number of equations written down in an EQN file. Suppose an equation which describes an multiple OR function, and realise that the sequence in which the terms are written down does not matter. Like a+b equals b+a. So identical equations can be written down in different ways.
    The EQN2JED program will move all in a blind 'linear' way into the fuse map. That is why 100% equivalent equations can result in different fuse maps.
    No need to worry, but checking (I use JED2EQN from the OPAL suite) never hurts.

    My PALs were secretly taken from mrs. roko's Disciple very early and read by the same friend who also (later, I believe) read Rudy's. PALs were new in those days, and discussed between Rudy and me during hundreds of hours, I am afraid.

    Indeed most programming devices need a somewhat decorated JED, so you find slightly different files.
  • zubzub
    edited February 2013
    roko wrote: »
    The fuse table for GAL (JED file) is generated from a number of equations written down in an EQN file. Suppose an equation which describes an multiple OR function, and realise that the sequence in which the terms are written down does not matter. Like a+b equals b+a. So identical equations can be written down in different ways.
    The EQN2JED program will move all in a blind 'linear' way into the fuse map. That is why 100% equivalent equations can result in different fuse maps.
    No need to worry, but checking (I use JED2EQN from the OPAL suite) never hurts.

    Thanks! I was wondering if that might be the case. However, I expected the fuse maps to be dumped from the MGT PALs, and therefore not to vary? Unless they've been converted to equations and back again, for some odd reason?
    My PALs were taken from mrs. roko's Disciple and read by the same friend who also read Rudy's.

    Okay, then I suppose that would suggest that the fuse maps in your analysis are correct.

    When you said "My memory says that Disciple worked with the 128K toastrack", I presume that would have been with Mrs. roko's DISCiPLE? (Sorry to be paranoid, just want to be sure we're not going down any blind alleys.)

    So, I suppose one has to suspect the schematics and perhaps the English language commentary accompanying the equations... and if they both turn out to be correct, this raises interesting questions. The next step would be to examine behaviour of a real Spectrum 128K with a DISCiPLE attached, or to try to debug X128!

    I wonder if anyone has a logic analyser that they can use to determine what addresses are fetched on a 128K with DISCiPLE, with M1 active after a reset?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    @Zub, regarding ROM/RAM.
    We're almost there: Of course I ment Disciple ROM and Disciple RAM, sorry if I was'nt clear enough.
    I can go along with the idea that NMI menus and Snapshots are not part of DOS. If you like, then consider low level Read-Write-Sector routines as part of a Disciple BIOS. But the actual routines needed for a running a DOS are found in both (Disciple) ROM and RAM. Several of them identical. Though part of RAM is used for tables and (I suppose) hardware identifying flags, like you say.

    I do not know the situation in emulating. But I can imagine that saving the 16k Disciple Rom/Ram to disk might result in a file that, although reflecting the situation during saving, does not reflect the situation during a cold start. In the sense that the 8k Rom- and the 8k Ram-code might have changed place.
    See 'Rudy', Appendix 4, "port #7B ROM/RAM flip (called BOOT by MGT)"
  • edited February 2013
    zub wrote: »
    Thanks! I was wondering if that might be the case. However, I expected the fuse maps to be dumped from the MGT PALs, and therefore not to vary? Unless they've been converted to equations and back again, for some odd reason?
    It is possible that the equations were rewritten for clarity, or to suite the taste of the employee on duty. I have found 3 versions of PusD's Alice.
    zub wrote: »
    When you said "My memory says that Disciple worked with the 128K toastrack", I presume that would have been with Mrs. roko's DISCiPLE? (Sorry to be paranoid, just want to be sure we're not going down any blind alleys.)
    Yes, that is correct. I just remember that there were no problems. I myself had (still use) Opus Discovery.
    Indeed, trusting is good but verifying is better.
    zub wrote: »
    So, I suppose one has to suspect the schematics and perhaps the English language commentary accompanying the equations... and if they both turn out to be correct, this raises interesting questions. The next step would be to examine behaviour of a real Spectrum 128K with a DISCiPLE attached, or to try to debug X128!
    You probably point to problems around the 128k.
    My simple line of thinking is this: The 'patch' addresses completely match with the addresses/functions in the standard ('48k') ROM bank. So switching happens when this ROM bank is active at the Spectrum side. For 'standard activities' the other bank ('128k') of Spectrum ROM is not used at all. So my suspicion would go towards emulator.
    I remember a visit of Gerton Lunter, who was informed by Rudy about Disciple hardware and as result added these functions to his Z80 emulator.
    Never heard of any (128k) problems. It might be worth reading the Z80 emulator manual.
  • zubzub
    edited February 2013
    roko wrote: »
    I do not know the situation in emulating. But I can imagine that saving the 16k Disciple Rom/Ram to disk might result in a file that, although reflecting the situation during saving, does not reflect the situation during a cold start. In the sense that the 8k Rom- and the 8k Ram-code might have changed place.
    See 'Rudy', Appendix 4, "port #7B ROM/RAM flip (called BOOT by MGT)"

    By pre-initialising the emulated RAM with the ROM contents, and using an image of the DISCiPLE RAM with GDOS loaded for the emulated ROM, you'd end up with something completely broken. Loading/saving to disk under 48K emulation would not work.

    Note that in the disassemblies, "OUT (123),r" appears which pages DISCiPLE RAM into #0000–#1FFF and DISCiPLE ROM into #2000–#3FFF. It even appears in the system file, despite being useless there. (For the code in question to execute, the DISCiPLE RAM would already have to be paged in at #0000... so there's no need to try to page it in again!) No "IN r,(123)" instruction appears in either of the disassemblies.

    If the RAM (containing a ROM image) started off at #0000, then both INIT_SYS and KSCAN_RES would keep the ROM image (in RAM) at #0000 (instead of paging it in at #2000), preventing the content of the system file from ever being executed.

    If the ROM (containing a RAM image) started off at #0000, then the sector buffer would then reside in ROM, so it would be impossible to save files... and that's assuming that the code would survive long enough to to use the sector buffer, which seems unlikely!

    I'm not sure whether you're suggesting that this could be the source of the emulation problems, but it would be such a fundamental and obviously noticeable error, even under 48K emulation, that it's simply not worth even considering.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    roko wrote: »
    You probably point to problems around the 128k.
    My simple line of thinking is this: The 'patch' addresses completely match with the addresses/functions in the standard ('48k') ROM bank. So switching happens when this ROM bank is active at the Spectrum side. For 'standard activities' the other bank ('128k') of Spectrum ROM is not used at all. So my suspicion would go towards emulator.
    I remember a visit of Gerton Lunter, who was informed by Rudy about Disciple hardware and as result added these functions to his Z80 emulator.
    Never heard of any (128k) problems. It might be worth reading the Z80 emulator manual.

    It's a little hard for me not to get a bit frustrated here, but I'll do my best! :-)

    Regarding handling of 'patch', I'm not aware that the 128K handles 'ROM 0' in any special manner. That is to say that it will place all of the usual signals (and I'm thinking of MREQ, RD, M1, A14 and A15 in particular) on the bus and respect ROMCS, just as it would for any access to 'ROM 1'. If you know otherwise, then please correct me! Neither set of equations mentions anything regarding the snooping on port #7FFD that would be required (in absence of any special handling of ROM 0 by the Spectrum) to implement this, either.

    I can certainly accept that is a problem with the emulation ? it clearly doesn't work! ? but my belief is that Fuse's emulation is based on exactly the same understanding of the hardware that you possess. Any suspicion really should be based on evidence that can be explained in terms of the equations and schematics. I can't be entirely sure that at least the start of the 'crazy' instruction trace isn't in some way normal, but for the time being, it seems reasonable to assume that it is not.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    A continuation of the instruction trace:
    SRC — memory source:
      0 for the 128K 'ROM 0'
        (i.e. the one that's rather different to the 48K ROM)
      R for uninitialised RAM
    
    SRC PC   Instruction
    0   0059 JP   #0321
    0   0321 LD   SP,(#5CB2)
    0   0325 INC  SP
    0   0326 LD   (#5B81),HL
    0   032C HALT
    0   0038 PUSH HL
    0   0039 LD   HL,#0048
    0   003C PUSH HL
    0   003D LD   HL,#5B00
    0   0040 PUSH HL
    0   0041 LD   HL,#0038
    0   0044 PUSH HL
    0   0045 JP   #5B00
    R   5B00 NOP
    R   5B01 NOP
    R   5B02 NOP
    R   5B03 NOP
    R   5B04 NOP
    ...
    R   5B80 NOP
    R   5B81 RST  38
    
    
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    By pre-initialising the emulated RAM with the ROM contents, and using an image of the DISCiPLE RAM with GDOS loaded for the emulated ROM, you'd end up with something completely broken. Loading/saving to disk under 48K emulation would not work.
    O.K.
    zub wrote: »
    Note that in the disassemblies, "OUT (123),r" appears which pages DISCiPLE RAM into #0000?#1FFF and DISCiPLE ROM into #2000?#3FFF. It even appears in the system file, despite being useless there. (For the code in question to execute, the DISCiPLE RAM would already have to be paged in at #0000... so there's no need to try to page it in again!) No "IN r,(123)" instruction appears in either of the disassemblies.
    This does not surprise me. It were things like this that kept my interest in the software rather limited.
    zub wrote: »
    If the RAM (containing a ROM image) started off at #0000, then both INIT_SYS and KSCAN_RES would keep the ROM image (in RAM) at #0000 (instead of paging it in at #2000), preventing the content of the system file from ever being executed.
    Where my understanding differs from your picture is that not only the hardware devices change place in address space, but that they take their contents with them.
    zub wrote: »
    If the ROM (containing a RAM image) started off at #0000, then the sector buffer would then reside in ROM, so it would be impossible to save files... and that's assuming that the code would survive long enough to to use the sector buffer, which seems unlikely!
    Its unlikely that ROM at any moment will hold an image of RAM, if that is what you mean.
    zub wrote: »
    I'm not sure whether you're suggesting that this could be the source of the emulation problems, but it would be such a fundamental and obviously noticeable error, even under 48K emulation, that it's simply not worth even considering.
    My thought was based on the note in the disassembly (page 1) "On power up or when the (disciple) reset button is pressed, the ROM is paged in at address #0000". (And then the routine described at #2001 is run, jumping towards #22F2 etc.! See p.89, p.100)
    This differs from paging the disciple in automaticly via the known addresses, because then the filled RAM will be at address #0000 and a.o. the routine at #0008 will be run.
    This then means that a loosely saved 16k 'ROM' will have the ROM code at #2000, while 'cold start' ('booting'?) expects this ROM code at #0000.
  • edited February 2013
    zub wrote: »
    It's a little hard for me not to get a bit frustrated here, but I'll do my best! :-)

    Regarding handling of 'patch', I'm not aware that the 128K handles 'ROM 0' in any special manner. That is to say that it will place all of the usual signals (and I'm thinking of MREQ, RD, M1, A14 and A15 in particular) on the bus and respect ROMCS, just as it would for any access to 'ROM 1'. If you know otherwise, then please correct me!
    I'm old school zub, stay calm. :-)
    As I understand it, the M1 line is added into the decoding to make sure that patching ONLY takes place when the particular address is reached for reading an instruction. And therefore not during other moments (other ROMs...) when the particular addresses appear on the address bus. That is, as I see it, why only standard ROM will make the Disciple, monitoring the signals, 'patch in'.
  • zubzub
    edited February 2013
    roko wrote: »
    I'm old school zub, stay calm. :-)
    As I understand it, the M1 line is added into the decoding to make sure that patching ONLY takes place when the particular address is reached for reading an instruction. And therefore not during other moments (other ROMs...) when the particular addresses appear on the address bus. That is, as I see it, why only standard ROM will make the Disciple, monitoring the signals, 'patch in'.

    In the 48K, the M1 line comes straight from the Z80, and reflects whether the Z80 was in the 'M1' state ? which effectively means, at the start of executing an instruction (although if I remember correctly, there's a little more to it than that).

    Blocking M1 for ROM 0 would be a rather kludgey way to do things. It would mean that other ROMs couldn't be paged in by trapping execution (assuming M1 is actually used by the device, which it should be, but wasn't always), but once they are paged in (perhaps using an OUT instruction), they would be accessible.

    What one might expect would be for A14 or A15 to be driven high on the expansion bus, so that peripherals would see access to ROM 0 as actually being RAM accesses.

    Either way, I've not come across any reference to the 128K doing anything like this.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    Sorry zub, I can't understand.
    Are you seriously stating that in both ROM banks of 128K there are instructions found on the specific 'patch' addresses? I believe this specificly was avoided in the 'extra' ROM. Like it also is avoided in Disciple ROM (like in other interfaces) to prevent the intf from getting in a loop.
    I find blocking M1 in this way the simplicity of genius, but that's a matter of taste. I just aimed at helping you to get your journey into the unknown on the road, not at a competition. :-)
  • zubzub
    edited February 2013
    roko wrote: »
    Sorry zub, I can't understand.
    Are you seriously stating that in both ROM banks of 128K there are instructions found on the specific 'patch' addresses? I believe this specificly was avoided in the 'extra' ROM.

    Yes, at 0x0001! ROM0 contains the start of a 'ld bc,0x692b' instruction at that addresses, whereas ROM1 contains an 'xor a' instruction. The instruction in ROM0 will be executed upon reset, and the instruction in ROM1 will be executed upon running 'USR 0'.

    If I modify the emulation to trap 0x0002 instead of 0x0001, and I have the DISCiPLE ROM and RAM be paged out upon reset, then I appear to get working emulation under the 128K, and the 48K follows exactly the same code paths as before. However, I've now deviated from the equations, and don't know whether anything might be subtly wrong under 128K emulation. It could well be that the DISCiPLE ROM really does need to be paged in on bootup, for whatever reason.

    I also get working emulation if I disable trapping of 0x0001 entirely, and don't replace it with another address. I'm not sure whether this would adversely affect 48K emulation (or even emulation of the 128K in 48K mode).

    It is true that ROM0 holds the middle of an instruction at 0x0008, 0x0066, and 0x028e. I can well believe that this may not be entirely down to coincidence, as I can imagine Sinclair being careful to ensure M1 cycles don't occur at addresses that peripheral developers (and existing peripherals — especially Sinclair's own IF1) would be likely to trap, and I can imagine that peripheral developers would either snoop on port 0x7ffd or rely upon M1 cycles only occurring for a specific ROM at certain addresses, or otherwise test the contents of ROM by some means to determine whether to immediately page themselves out (although this requires that they don't simply assert /ROMCS whenever any address in the low 16 KiB of the address space is read).
    Like it also is avoided in Disciple ROM (like in other interfaces) to prevent the intf from getting in a loop.

    Once the DISCiPLE is paged in, it is paged in. There is no need to avoid execution at the addresses that the DISCiPLE traps, but there is also no need for the code to ever loop back to those addresses, so it does not do so.
    I find blocking M1 in this way the simplicity of genius, but that's a matter of taste.

    I'd be all in favour of peripherals taking M1 and ANDing it with some other line to determine whether to trap certain addresses, dependent on which of the Spectrum ROMs is paged in... but if Sinclair had masked the M1 line on the expansion bus in this way, then it would mean that peripherals would not be able to trap execution within ROM 0, at all, which would probably be worse than the alternative. I guess that's why Sinclair didn't do this! :-)

    I've looked at the grey +2 schematics (the toastrack schematics I've found aren't quite so readable, and AFAIK, the grey +2 and toastrack are the same in all respects that I care about)... and get the impression that MREQ, M1, A14, A15, RD, WR and IOREQ are all passed straight from the Z80 to the expansion bus.

    I'm not sure about ROMCS (and ROMSEL?), though... but since I know the Beta 128 and Multiface had to do special things for 128K compatibility, I'm reasonably confident that the 128K doesn't do anything different for ROMCS than the 48K did. Perhaps there could be some sort of resistor trickery here (as per the ULA side of the bus) such that a peripheral could put data on the bus, that the ROM would then override...? (TBH, I find hardware schematics hard to follow.) In any case, though, the line from pin 12 of IC6 to A14 of the ROM does not seem to be used for any other purpose.
    I just aimed at helping you to get your journey into the unknown on the road, not at a competition. :-)

    My apologies! Knowing a bit about the emulation (well, I wrote it... :)), and knowing the sort of mistakes that would result in truly broken emulation (even on the 48K), I just felt that I was being sent on a wild goose chase on occasion — but I realise that you are making helpful suggestions, and even if they don't always tie in with how the Spectrum and DISCiPLE software actually works, you are forcing me to think about things that I'd simply taken for granted until now. :-)

    My suspicion now has to be that either some contradictory logic that I (or we?) should prevent the paging in at 0x0001 from working... or alternatively, there's a simple mistake in the equations somewhere... the fact that both sets of equations agree concerns me... but at the moment, I just can't see how they can be right, even if they do agree...
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    The difference of contents at address 0001 between ROM0 and ROM1 should (based on Rudy's opening remark) not matter:
    When address #0001 (NOT #0000!) is reached the DISCiPLE hardware pages in the
    DISCiPLE RAM/ROM. (RAM at #0000) NOTE: On power up or when the reset button is
    pressed the ROM is paged in at address #0000.

    A subsquent USR 0 will also not matter since the execution is always from ROM1?

    EDIT: hmm... I seem to be reading the last sentence how I want to read it - and face value it simply only states that the ROM is located at 0000 instead of RAM. Sorry, nothing to see here, please move along.

    EDIT2: but what does reached mean? Does this mean paged in when the instruction at 0001 is fetched or after the instruction at 0001 is fetched - if the former, then there is no issue? If the latter - how the heck is this supposed to work on a 128k? (I had a 128k toastrack with a disciple).

    EDIT3: I am not mad, the manual also documents the extra screen selection you needed to do when creating a 128k snapshot
    Press key 5 on the Spectrum for a 128K PROGRAM to be saved to disk. Every time
    you save a 128k file, 128K of memory space will be used on the disk (= 258
    sectors). Again, the borders will flash for a few moments, but then the
    program will appear to be frozen again. If the picture on your screen (the
    picture - not the border) has changed, press key Y (= yes) on the Spectrum; if
    the picture has not changed, press the key N (= no) on your Spectrum. The
    borders will then continue to flash until your 128K save is complete, You will
    then be able to resume from the point at which you left the program.
  • zubzub
    edited February 2013
    roko wrote: »
    Where my understanding differs from your picture is that not only the hardware devices change place in address space, but that they take their contents with them.

    Ah! So on bootup, the ROM would contain the ROM image, but start at #2000, and the RAM would contain 'a' RAM image, and start at #0000?

    I guess it's a bit of a moot point, since Fuse loaded the entire 16 KiB image as though it were a ROM image. The high 8 KiB would only be accessible by means of an appropriate write to the DISCiPLE control port (0x1f). The RAM was initialised to 0x00 upon a reset, although I would not be surprised if 0xff would be more accurate. (I'd like to know, as much out of curiosity as anything else! Unless perhaps there's a bug in the DISCiPLE, whereby a double reset could still leave RAM in a state that would prevent the interface from working properly, in which case, getting this right might actually matter.)

    It would still be a potential mixup for other emulator authors... and quite honestly, at an early stage, I experimented with all sorts of things to try to get the emulation working, including exactly what you're suggesting (although this was for the +D, not the DISCiPLE). I found that it didn't work very well, so kept on experimenting. In the end, I found that I just needed to trap 0x028e on the +D, just as per the DISCiPLE. The confusion was caused by RamSoft's +D/DISCiPLE Technical Guide, of which revision 8c (30th January, 2004) states:
    (***) +D memory is also paged in whenever the Z80 fetches an 
          instruction from the following addresses:
          0x0000, 0x0008, 0x003A, 0x0066.
    

    This was in some ways an improvement on revision 8 (9th September 1999), which stated
    (**) DISCiPLE and +D memories are also paged in whenever the Z80 fetches an 
         instruction from the following addresses:
         0x0000, 0x0008, 0x0066, 0x028E.
    

    In actual fact, the +D seems to be paged in at 0x0008, 0x003a, 0x0066 and 0x028e. I'm still not sure about 0x0000.

    Seriously, the amount of grief that this caused me... but anyway, as it's potentially of interest, I'll try my best to answer.

    Well, okay... as far as emulation is concerned, it's worth keeping in mind that the 'boot' flipflop won't be a flipflop anymore! In Fuse, it's simply a 'disciple_memswap' variable that is:
    • Reset by a reset of the machine.
    • Set/reset by a pair of port I/O handler functions, named disciple_boot_read() (for INs) and disciple_boot_write() (for OUTs) (although perhaps they should be renamed to disciple_set_boot_read() and disciple_reset_boot_write()).
    • Tested upon any change that affects the way memory is mapped under the emulated machine (such as alteration of 128K paging, or setting/resetting of patch or boot, even if they are already set/reset and their values therefore remain the same).

    The equivalent of the 'patch' flipflop in Fuse is a 'disciple_active' variable that is:
    • Set by a reset of the machine — although perhaps it should be reset instead?
    • Set by code in the Z80 emulation loop (the start of which corresponds exactly to the situations where an M1 cycle would have been initiated by real hardware), which checks PC against a set of addresses if the DISCiPLE is being emulated and then sets the 'disciple_active' variable if any one of them matches.
    • Set/reset by a pair of port I/O handler functions, named disciple_patch_read() (for INs) and disciple_patch_write() (for OUTs) (although perhaps they should be renamed to disciple_set_patch_read() and disciple_reset_patch_write()).
    • Tested in the same situations as the 'disciple_memswap' variable.

    Virtually all emulators will handle peripherals in much the same, the exception being Gerton Lunter's Z80 (at least for version 2 of the emulator), which takes the fantastic approach of placing the code to page in the DISCiPLE in the handlers for the instructions that occur at the addresses that are to be trapped.

    For example, ROM0 contains the instruction 'ld hl,(0x5b58)' at address 0x0064. The last byte of this three-byte instruction is 0x5b, which resides at address 0x0066, the entry point for an NMI. The opcode 0x5b corresponds to an 'ld e,e' instruction, so Lunter's Z80 tests whether PC is 0x0066 and whether DISCiPLE emulation is enabled in the handler for 'ld e,e' instructions.

    This has the advantage that it avoids a very costly set of tests at the begin of the execution of every single instruction (and allows for a technique similar to just-in-time compilation, which I believe Z80 adopted — certainly, JPP did), but has the disadvantage that it makes Z80 dependent on a particular set of ROM images, which cannot be changed by the user.

    ... but in any case, Fuse does what it does, so the potential mistakes might be:
    1. Having disciple_active set incorrectly on startup.
    2. Having the setting of disciple_active in the port I/O handlers reversed.
    3. Having inverted logic in the test for disciple_active when applying memory mappings.
    4. A combination of the above. All three together would cancel out. Any pair of the above would be equivalent to just the other of the three. Actually, there's no 'right' way to set disciple_active, so long as it's consistent with how it's used when applying memory mappings.
    5. Having the ROM image loaded into RAM and a RAM pre-load image loaded into ROM.

    Very simply, though, if the two halves were reversed in all situations, meaning that we started off with RAM at #0000 and ROM at #2000, then things might be okay for a brief period... but if the system even survived long enough to execute the extraneous 'OUT (123),a' which would put DISCiPLE RAM at #0000 (even though it's already there!), then we would actually end up placing the DISCiPLE RAM at #2000, and the ROM at #0000. I can't imagine this working well. Even if we were really, really lucky, the interface would attempt to write to buffers at addresses occupied by ROM. What's more likely is that it would attempt to jump to RAM routines at locations where the ROM has been paged, and crash rather severely.
    Its unlikely that ROM at any moment will hold an image of RAM, if that is what you mean.

    That would be quite a serious mixup... but possible, I suppose, if loading pre-initialised RAM and ROM from the same file. As I say, the resulting emulation would be completely unusable, though.
    My thought was based on the note in the disassembly (page 1) "On power up or when the (disciple) reset button is pressed, the ROM is paged in at address #0000". (And then the routine described at #2001 is run, jumping towards #22F2 etc.! See p.89, p.100)
    This differs from paging the disciple in automaticly via the known addresses, because then the filled RAM will be at address #0000 and a.o. the routine at #0008 will be run.
    This then means that a loosely saved 16k 'ROM' will have the ROM code at #2000, while 'cold start' ('booting'?) expects this ROM code at #0000.

    Agreed... but to be honest, there's no real concept of having things the 'right' way round, here. Fuse worked quite well for a while with the first 8 KiB of the ROM file being a RAM dump which ended up not getting used, and disciple_rombank defaulting to 1. I've since replaced the 16 KiB image with an 8 KiB one, and removed the disciple_rombank variable that we had entirely. Saving the DISCiPLE RAM contents to disk should be perfectly valid, since the DISCiPLE should really be able to recover from a reset in the middle of any disk activity (not that I'd recommend it...), and shouldn't re-use buffer contents from before a reset. Whether that's true in reality, I'm not sure, though.

    You are right that if you do SAVE the 16 KiB starting at address 0 to disk with the DISCiPLE, then you get a dump of the RAM followed by the ROM... and the various dumps I've seen do contain different data in various buffers, especially the sector buffer, sector address map and bit address map. It's still possible that some of the 16 KiB images that are out there were created under emulation, though, and I expect these buffers would be filled with data simply by loading the system file.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Stefan wrote: »
    EDIT2: but what does reached mean? Does this mean paged in when the instruction at 0001 is fetched or after the instruction at 0001 is fetched - if the former, then there is no issue? If the latter - how the heck is this supposed to work on a 128k? (I had a 128k toastrack with a disciple).

    I interpreted that as meaning 'executed by the Z80', and meaning that the DISCiPLE memory is paged in before the data for address 0x0001 is fetched.

    I suppose you've made the observation that for every address that the DISCiPLE traps (or at least 0x0001, 0x0008, 0x0066 and 0x028e), the DISCiPLE ROM contains the same initial instruction as the 48K Spectrum ROM. Interesting. Could the fact that the 128K ROM0 has different contents explain anything, here? Are any of the DISCiPLE's paging operations delayed by a cycle? I already partially considered this previously, but found that it didn't help me to obtain a sensible trace of execution... but we can have a closer look if you think it's worthwhile.
    EDIT3: I am not mad, the manual also documents the extra screen selection you needed to do when creating a 128k snapshot

    Yeah, it does that... I find it curious that the +D also requires the user to press 'Y' or 'N' in this manner. It would seem fairly straightforward to me to snoop on bit 3 of port 0x7ffd to see which screen is selected, but I guess there wasn't space in the PAL for this...
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
Sign In or Register to comment.