The Disciple clone... doable?

edited May 2014 in Hardware
Hi.
As a spectrum user in the 80's this was the dream interface all-in-one for me.

I have a 48k+ and planning on get a 128K toast-rack later.
Anyway I've found a lot of information on the disciple interface, I got the schematics from WoS, downloaded a +D corrected schematic (The disciple schematic is missing severals pin labels and connections)

Anyway, most of the chips are nowadays available, the only issue could be the pal, but I've seen that gal's and a pal-to-gal conversion could do the trick. It worked for divide users for years.

Why not get a divide? Easier, cheaper, tested, etc. Well, I also would need kempston joystick interface. I have an old matrix printer that could be used, several FDD (3'5") laying around and in the foreseable future I will get a eprom/pal/gal programmer. For fun of course!
I'm building the schematich on Orcad and I will try using High resolution pictures of original disciple to make the layout/pcb design.
If anyone owns one and can make pictures of the sides, connectors style, etc this could be verry useful. I saw the "High resolution pics" in this forum, downloaded them and I will use it when making the pcb.
One improvement could be getting the 7905 out of the PCB and install a PSU for the disciple alone with a heatsink, etc. The ZX spectrum edge/disciple connection is hard to get angled as it was, I think a conversion to IDE-ish connectors from the zx edge and an expansion port on the pcb is the way to go in case of trying to connect more interfaces (I guess with the disciple I wouldn't need much anyway).

This is only an idea that I got after watching that someone made a +D clone succesfully, I know the disciple is way bigger and complex, I have time, and this will be a way of testing my design/debugging skills for the Superfo 128K clone that is projected on this site and on speccy.org and actually on first prototype stage.

Stuff that I (guess) I will need (both projects)

-Analog Oscilloscope (noise, clock signal checking, glitches, etc)
-Eprom and pal/gal programmer (on the way).
-Logic analyzer. Actually interested on the "open logic sniffer", 16 channels.
-Breadboard(s) for testing. Noise can be a problem.
-WD1772 chip, Eprom chip 27128, ram 6864, a bunch of 74LS chips.
-IC testing software/hardware, datasheets and of course, IC sockets.
-FDD drive. You can use HD floppys just by blocking the hole that identifies them or by disabling this internally on the FDD. In the past I used DD as HD by making a hole with a drill, the opposite is by far more likely and less prone to bugs.
-Being able to make snapshots from pc (SAMdisk software, fuse emulator, etc)
-Arduino and something like this could be very useful in debugging, using it for IC testing, programming input signals sequences and use the logic analyzer to get the readings.

Any additional documentation/help will be very useful besides the ones on WoS.

I'm building the schematic and will post it soon.

Wish me luck....I will need it.
Post edited by Severino on
«1345

Comments

  • edited February 2013
    Severino wrote: »
    Hi.
    ..
    Why not get a divide? Easier, cheaper, tested, etc. Well, I also would need kempston joystick interface. I have an old matrix printer that could be used,
    ..

    Hi,

    Just in case you may want to build a 'Interface 1bis', PCBs are available at cost.
    'Interface 1bis' for the Sinclair ZX Spectrum
  • zubzub
    edited February 2013
    Severino wrote: »
    I have a 48k+ and planning on get a 128K toast-rack later.
    Anyway I've found a lot of information on the disciple interface, I got the schematics from WoS, downloaded a +D corrected schematic (The disciple schematic is missing severals pin labels and connections)

    I'm puzzled by how a +D schematic would be of any really use. My understanding is that the +D and DISCiPLE are really quite different, besides sharing a WD1772.

    Sounds like an excellent project, though. If you got this working, and anyone made a batch of them, then I would certainly love to have a couple of DISCiPLE clones, that is, assuming the network would be emulated, too!
    -Being able to make snapshots from pc (SAMdisk software, fuse emulator, etc)

    Assuming Phil and Fred are okay with this, I will try to add support for writing +D/DISCiPLE snapshots to libspectrum at some point (and also reading/writing of SAM Messenger and SC_Speclone snapshots, if we can overcome some of the non-technical issues with supporting them), so Fuse and snapconv (from fuse-utils) are capable of this... but this will be after the next release.

    Note that although the +D and DISCiPLE do use the same snapshot format, there is a bug in GDOS's code for both loading *and* saving snapshots, causing AF to be saved/restored instead of AF'. The code was seemingly written with the assumption that EXX swaps AF and AF', but it does not! It might be worth fixing this.

    Fortunately, Rudy Biehold's commentary of the code is quite clear. Unfortunately, though, all of the RAM from #0000-#19FF is taken by code, and all of the RAM from #1A00-#1FFF is taken by bitmaps, buffers and variables, so we would need to be careful.

    If the DI at #008D really is unnecessary, then fixing saving of state should be a simple matter of removing the DI instruction and adding an EX AF, AF' at the same place as the EXX at #0084 (a mere nine POKEs). Otherwise, the code starts shuffling a bit more, but there seems to be a small amount of free space at #004A. To fix restoring of state, I imagine that the CP #00 instruction at #0211 could be replaced with an OR A, and an EX AF, AF' inserted. To do this with POKEs, this would be easiest by adding the EX AF, AF' at both #020E and #0236, and shortening the CP #00 at #0239, too (eight pokes in total).

    There are also other cases of CP 0, use of CP #FF where DEC A would have been okay (since A didn't need to be preserved... although actually, at #0F26, I'd have done LD A,H; AND L; INC A; RET Z instead, which is four bytes long rather than nine), as well as cases of LD A,0 which could be safely replaced with XOR A, and also ADD A,1 where INC A would have made more sense! I'm not a great Z80 programmer but even I can see lots of ways of making more space if needed... I guess M.G.T. (Bruce Gordon?) must have shrunk the code down to the required size and then not really bothered much after that. :-)
    Any additional documentation/help will be very useful besides the ones on WoS.

    Agreed! Even for emulation, I'd like a better understanding of how the DISCiPLE works, since we never got its paging (ROMCS handling, most likely) working under 128K emulation.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    Hi.
    Thanks for the Interface I link.
    Right now I'm interested on the disciple only.

    About the schematics I've found missing pins and mislabeled ones on the Schematic available in WoS.
    Details:
    IC 27128
    pin 22 (no label) from the +D corrected -> /RD or RD#

    pins 11-19 (no label) -> D0-D7

    IC6264
    pins 11-19 (no label) -> D0-D7

    IC11-74LS374 (printer)
    pins 4-7 are the same D4 -> pin7 is D3 (from the +D corrected)

    Beyond that, a lot of confusion about the power 9V and 5v. The GND is labeled 0V.
    I guess the disciple gets the 9V output from the speccy and puts it through a 7805 voltage regulator. This is (or at least I suspect) the 5V that goes to all the chips power connections and to give logical "1" to any input on the chips.
    All remaining connections from the speccy connector are on the "trough" connector of the disciple, though there are 4 extra "pins", 2 on each side of the PCB on the schematics. I will look into that.

    About the network connections there's a jumper on each jack socket that are implemented on the socket, when no jack is connected, a 680ohms resistor is on the "tip" of the jack socket, when connected this 680 ohms resistor is off.

    The pal's equations are available on WoS, they were "decrypted".

    I'm only drawing the schematic. I have a lot to read before even begin to understand the disciple OS; I'm printing a lot if stuff about the Z80 and its architecture.

    Have a nice week!
  • zubzub
    edited February 2013
    Severino wrote: »
    Thanks for the Interface I link.
    Right now I'm interested on the disciple only.

    FWIW, the Interface 1bis is a sort of modern take on the IF1. It's really not an IF1 at all, but it does provides storage (via USB and SD card), printing (USB), networking (Ethernet), as well as joystick and PS/2 ports. (You can't really beat a proper digital joystick for playing a good number of Spectrum games...) But I appreciate that this isn't what you want! Or at least, even if it is, I'm certainly still interested in finding out how the DISCiPLE works!
    About the schematics I've found missing pins and mislabeled ones on the Schematic available in WoS.

    Ahh, I see what you mean, now! Yes, I guess at the component level, there's a certain amount of similarity. Since you have the content of the PAL, I suppose this really is a matter of fixing the schematics, programming the GAL, making a board, getting the necessary components and then assembling it all? Or are there any old components that would need replacing? Whilst you're at it, it would make very good sense to integrate more of the logic onto ICs and shrink the layout, though!

    Before, I wasn't sure how hard this would be, but now, I can't really imagine that there'd be any real reason that you wouldn't be able to get this working! :-)
    Details:
    IC 27128
    pin 22 (no label) from the +D corrected -> /RD or RD#

    pins 11-19 (no label) -> D0-D7

    IC6264
    pins 11-19 (no label) -> D0-D7

    Can't argue with this! I guess they're pretty obvious, though. :-)
    IC11-74LS374 (printer)
    pins 4-7 are the same D4 -> pin7 is D3 (from the +D corrected)

    Agreed. I can confirm that apart from that one glaring error (presumably a typo), the way that IC11 is wired up in the DISCiPLE schematic looks correct. For a clone of the interface, I expect you'd pick whichever pins on IC11 are most convenient, i.e. the wiring used by the +D is equally valid and would work fine for a DISCiPLE clone — all that really matters is that the mapping between the Spectrum's data bus and the printer port is correct! It might actually be more convenient to provide a DB25F socket instead of the 26-pin header that I expect the DISCiPLE provided (and I this since that's exactly what the SAM Coup?'s comms interface provided).
    Beyond that, a lot of confusion about the power 9V and 5v. The GND is labeled 0V.
    I guess the disciple gets the 9V output from the speccy and puts it through a 7805 voltage regulator. This is (or at least I suspect) the 5V that goes to all the chips power connections and to give logical "1" to any input on the chips.

    At this point, I'll just try not to blow up your Speccy by saying anything. :-)
    All remaining connections from the speccy connector are on the "trough" connector of the disciple, though there are 4 extra "pins", 2 on each side of the PCB on the schematics. I will look into that.

    Curious! XA1 and XB1 are marked on the Spectrum bus, too, in that schematic, but I don't know what they're for. XA3 and XB3 appear in the schematic for the +D, too. I can imagine that XA2 and XB2 were for testing purposes, although I don't quite understand what EXT_A30 is. I can see that it's connected to IC5, which is another 74LS374, but with a variety of purposes — this IC5 is associated with what's called the control port (port #1F, on the DISCiPLE). The line in question is wired up to Q2 (pin 6) on that chip, which corresponds to D2 (pin 7) on the same IC, and according to the schematic, D5 on the Spectrum's data bus. Bit D5 of that port is documented in the Ramsoft DISCiPLE/+D technical guide as being "ext. select (?)", and I have no idea what that means! I can well imagine that it's just for testing, though.

    I also notice that "ext. select (?)" is listed by Ramsoft for the +D, but the schematic on WoS only shows D0, D1, D6 and D7 as hooked up to IC8, and I/O3 from the PAL isn't connected anywhere else, so I strongly suspect that this is nonsense for the +D.
    The pal's equations are available on WoS, they were "decrypted".

    I assume you're referring to bverstee's post in [thread=39450]thread 39450[/thread]?

    I can't see the equations anywhere, though! I've searched WoS and Googled, but can't find them. Can somebody point me in the right direction, please?

    Interesting, though. Seems the were not "encrypted" in the first place. (I assume the security really on the PALs really just involves blowing of a few fuses that prevent reading of its contents, though?)
    I'm only drawing the schematic. I have a lot to read before even begin to understand the disciple OS; I'm printing a lot if stuff about the Z80 and its architecture.

    I don't know how much you will really need to know to get this working. It probably depends on how much debugging you end up doing. I guess for the most part, you'd be interested in how the various Spectrum and Z80 control lines work (mainly /M1, /MREQ, /ROMCS, /IORQ, /RD and /WR, /INT, and /NMI, I expect).
    Have a nice week!

    And the same to you! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    zub wrote: »
    I can't see the equations anywhere, though! I've searched WoS and Googled, but can't find them. Can somebody point me in the right direction, please?

    Ahh, just found them! Apologies!
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • LCDLCD
    edited February 2013
    Dan Antohi wrote: »
    Hi,

    Just in case you may want to build a 'Interface 1bis', PCBs are available at cost.

    The "customisation" is not working, it crashes the Firefox plugin.
    Edit: Will it work together with +D?
  • edited February 2013
    It was on WoS ftp:

    ftp://ftp.worldofspectrum.org/pub/sinclair/technical-docs/DISCiPLEInterface+MGTPlusD_PAL-ICs.zip

    I'll keep onto the schematics.

    I have the schematics almost finished. PDF is OK? or a gif file?
  • edited February 2013
    Don't forget that both the Disciple and PlusD were test beds for SamCoupe technology and a way of generating revenue for the Sam development.

    Would be worth considering Sam schematics too? (Though I've never done a comparison, but I bet the peripheral/disc interfaces are very similar...)

    Edit: by the way, decoding pals involves generating a truth table by cycling through all input combinations and recording the outputs. Being unclocked, they don't have state (AfAIK - anyone?).
  • zubzub
    edited February 2013
    Severino wrote: »

    I'd already posted that link, but thanks anyway!
    I'll keep onto the schematics.

    I have the schematics almost finished. PDF is OK? or a gif file?

    I'd personally prefer SVG for that sort of thing, but maybe that's just me! :-)

    Pretty much anything should be better than the original gif, though.

    I am definitely concerned that given the obvious mistakes that you noticed, there might be a few less obvious ones in there, too. I'm also concerned that what we have might not be sufficient to get the interface working with the 128K. I have stepped through the emulation that we have under Fuse, and found that Fuse seemed to execute the code correctly, but it ended up running RS-232 related code in ROM1 during early initialisation. This is with Fuse paging the DISCiPLE ROM in and out in the way specified by the combination of the slightly hard to read schematics and the decoding of the PAL. I can't see anything in the DISCiPLE schematic/PAL decoding that looks like it's specifically to deal with 128K compatibility, though...

    Either the schematics are wrong in some important respect, the PAL decoding is wrong, there's a version of the ROM that's 128K-compatible that I haven't seen yet, or I've missed something fairly fundamental. I would guess that RealSpectrum, Z80 (the emulator) and X128's DISCiPLE emulation work in 128K mode, although I don't have a DOS/Windows installation to try this on. RealSpectrum and Z80 seem to have the same main part of the ROM (8K) as distributed with Fuse, though.

    By the way, I think there are some other mistakes in the schematic and PAL decoding, which would also be worth correcting:
    • Pin 9 (I8) of IC8-PAL20L8 is listed as ^NREQ. The line on the Spectrum's bus (and the Z80) in named MREQ. I imagine that NREQ was a typo or a font rendering problem. This has been dutifully copied into the DISCiPLE PALs document.
    • Pin 23 (I13) of IC9-PAL20L8 is listed as ^N1. The line on the Spectrum's (and the Z80) is named M1. Again, I imagine this a type or a rendering issue. Again, this occurs in the DISCiPLE PALs document.
    • Q4 in the DISCiPLE PALs document mentions addresses 0x0000, 0x0008, 0x0066 and 0x028E, but the equation for /O18 lists 0x0001, 0x0008, 0x0066 and 0x028E instead.
    csmith wrote: »
    Don't forget that both the Disciple and PlusD were test beds for SamCoupe technology and a way of generating revenue for the Sam development.

    Would be worth considering Sam schematics too? (Though I've never done a comparison, but I bet the peripheral/disc interfaces are very similar...)

    The SAM did use a WD1772, although it was actually supplied to user on board attached to their floppy drive, which they'd slot in to the SAM. This means that each drive had its own FDC, and I believe it was possible to read from one drive whilst writing to the other. There was also an external floppy interface, which plugged in to the back of the SAM, but I would expect this to be very similar (or possible even identical?) to the board for the internal drives. There might be a jumper to determine which set of ports to decode (drive 1 or drive 2) but apart from that, it would be almost the same.

    Most WD1772-based interfaces seem to be quite similar... the four WD1772 registers are made available, together with one or two control ports. The DISCiPLE is slightly unusual in its complexity, though. Since the SAM has no RAM/ROM attached to the floppy interface, and it therefore requires no paging circuitry, I expect that the electronics of the interface are much simpler than even the +D's. In actual fact, it only provides the four WD1772 registers, and has no control port at all! Side selection is determined by one of the address lines (A2, FWIW) upon access to the WD1772 I/O ports.
    Edit: by the way, decoding pals involves generating a truth table by cycling through all input combinations and recording the outputs. Being unclocked, they don't have state (AfAIK - anyone?).

    I'm puzzled by this, as there are two flip-flops provided by IC8-PAL20L8 — do these not count as state? (Apologies, I'm only a programmer, so I might struggle with subtleties of electronics terminology at times.)

    If you have read bverstee's post, then you'll have noted that he did say that "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".

    This would suggest to me that they were able to read the contents of the PAL by means other than cycling through all combinations, although provided there's no complex internal state (and I guess PALs of the time were generally unlikely to be programmed with any particularly complex logic), I imagine cycling through all input combinations would be quite sufficient.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    zub wrote: »
    By the way, I think there are some other mistakes in the schematic and PAL decoding, which would also be worth correcting

    Oops... I forgot to mention the most glaring error in the DISCiPLE PALs document: "Page out the speccy ROM and enable Disiciple ROM & RAM when an IO request is written to port 0x7B", should be 0xBB. The English description in the equations is correct, although I haven't checked the equations themselves.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    I believe the Disciple PALs were called DEE and DUM. I also believe I studied the inners of these as EQN files, long time ago. IIRC the (2?) latches (flipflops, whatever) were built by connecting the two PALs 'against' each other, and hard to grasp. IMHO the PlusD was a step forward....
    Will check my archives for DEE and DUM.
  • edited February 2013
    Hi.

    I don't know which version of the 128K is emulated and tried with the disciple. As the disciple was around in 1986 I guess the 128K that seems to be more compatible should be the "toast rack", maybe even the +2, but the +2A and the +3 as I recall it gave a lot of problems with hardware compatibility, this can extend to the +2 even, try the spanish 128K roms that are available on WoS. I tried them with fuse, I didn't try the disciple though.

    I will continue with the schematics and correct those typos.

    Taking a look at the SAM certainly wouldn't hurt, changing the printer socket is a very good idea too.

    About the 9V and 5V, I was saying that getting the 9V from the speccy is the 9V from the PSU, so you wouldn't blow the speccy, maybe the PSU...
    Anyway, a FDD will need +12V and 5V, so isolate the power and get it from the "new" psu is a good idea and no voltage regulator is needed.

    I'll correct the schematics then.


    Thanks.
  • edited February 2013
    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
    Thanked by 11024MAK
  • edited February 2013
    Very useful information. I printed all the details about mistakes on the schematic and sent an email to the owner of "The complete Disciple dissassembly" in case he has a paper or a small book covering all the aspects of the code and where It could be improved to maximize compatibility.

    I also found that most printers were not compatible with the interface.

    About the printer, It seems not all printers were compatible, I recall EPSON 750, but the dot matrix I own was made fom Amstrad looong ago and It must have a epson compatibility as all printers on that era (PC 8086/286).

    Anyway once I've completed the schematics I will try to make a block diagram and we will go from there.

    Besides the code, Is there anything poor designed on the disciple wich can be improved? I read that the pals where the chips that needed more service.

    Salud!
  • edited February 2013
    I figured out what are the extra connections on the "through" expansion port is, of course, Its connected to the ROM and must be a way to update the "BIOS" of the disciple. The last OS was Unidos. I'll keep going.
  • edited February 2013
    you couldnt update the chip in the disciple with unidos
    you actually had to fit a unidos chip into the disciple
  • zubzub
    edited February 2013
    Severino wrote: »
    I don't know which version of the 128K is emulated and tried with the disciple. As the disciple was around in 1986 I guess the 128K that seems to be more compatible should be the "toast rack", maybe even the +2, but the +2A and the +3 as I recall it gave a lot of problems with hardware compatibility, this can extend to the +2 even, try the spanish 128K roms that are available on WoS. I tried them with fuse, I didn't try the disciple though.

    I tried with British "toast rack" emulation. Here is a a trace of what I am seeing in Fuse's debugger:
    ROMs: D for DISCiPLE, 0 for the 128K ROM 0 (i.e. the one that's rather different to the 48K ROM).
    
    ROM PC   Instruction
    0   0000 DI
    D   0001 XOR  A
    D   0002 OUT  (31),A
    D   0004 JP   #02F2,POWER_UP2
    D   02F2 LD   A,02
    D   02F4 OUT  (254),A
    D   02F6 LD   A,#3F
    D   02F8 LD   I,A
    D   02FA NOP
    D   02FB NOP
    D   02FC NOP
    D   02FD NOP
    D   02FE NOP
    D   02FF NOP
    D   0300 XOR  A
    D   0301 OUT  (31),A
    D   0303 OUT  (251),A
    D   0305 LD   HL,#7FFF
    D   0308 LD   SP,HL
    D   0309 IM   1
    D   030B XOR  A
    D   030C LD   DE,65535
    D   030F LD   HL,#11CB,START/NEW
    D   0312 JP   #004F,UNPAGE_HL
    D   004F PUSH HL
    D   0050 OUT  (187),A
                          ; Here's where it starts going crazy, and we enter
                          ; this middle of the 128K error routine (which starts at 004A)
    0   0052 LD   E,H ; this is the second byte of LD (5B5C),A
    0   0053 LD   E,E ; the third byte of this three-byte instruction
    0   0054 EI
    0   0055 DEC  A
    0   0056 LD   (IY+00),A
    0   0059 JP   0321
    

    Under 48K emulation, returning to 0052 does something sensible (a RET, actually)... but the 128K emulation just gets into a mess, despite appear to do as instructed.

    Even if we change the handling of OUT (187),A so that it is deferred until after the next instruction is executed, this results in a jump to 11CB in ROM 0, which rather than being the START/NEW routine, is responsible for transmitting MIDI data!

    As far as I can see, the interface simply isn't 128K compatible... but that simply can't be the case, since MGT advertised it as being 128K compatible!
    I will continue with the schematics and correct those typos.

    Thanks! It would definitely be good to have tidier +D schematics too, if you thinking of doing that.
    Taking a look at the SAM certainly wouldn't hurt, changing the printer socket is a very good idea too.

    It probably wouldn't hurt, but keep in mind that there's unlikely to be much more than a WD1772 (or VL1772) mounted on a PCB with some side selection logic. There might be some components between the FDC and the drive, but I'm not sure of how much interest they would be. The port decoding is handled by the ASIC, which provides 'DISC1' and 'DISC2' outputs, and the side selection is determined by address line A2, as I mentioned previously. The DISC1 and DISC2 lines are even available on the expansion bus, so I doubt that the external interface will be any more complex, except it might have a drive 1 / drive 2 jumper to select between DISC1 and DISC2 as input for the WD177's chip select pin.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    A slightly crazy idea: a combined +D/DISCiPLE with a switch on the side to select between modes. There's enough in common that I would imagine there shouldn't be too much waste, but of course, you would need a radical redesign of the board, and the PALs/GALs would change substantially.

    The slightly tricky thing about this is that G+DOS and GDOS stay resident in RAM after a reset. You really wouldn't want to carry on using the wrong DOS after switching modes and resetting! ... but I'm not sure how the DISCiPLE and +D ROMs would handle this situation.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    About Unidos.
    I only made an observation about those extra pins on the schematics. I realize now I was wong, the pin that enables programming is pin 27 and is always a "1", the extra pins are from each enable input ram or rom so it can be a way of monitoring wich chip is being accessed at a certain time. I was wrong.

    About the schematics I'm having a bit of a problem with my WinXP installation, even with no ethernet connection I got a virus and It doesn't work well, even my beloved protel99SE doesn't get to work.. I'll keep on working.

    About the code... MIDI code? It makes no sense, The only way for a 128k to make midi code is through the ay-chip, from the "Derby" documents MIDI_SEND in 11EH Rom address.

    I'm still upset about WinXP, I'm on my way to finish the schematic.

    ?Salud! (Cheers)
  • zubzub
    edited February 2013
    Severino wrote: »
    About the code... MIDI code? It makes no sense, The only way for a 128k to make midi code is through the ay-chip, from the "Derby" documents MIDI_SEND in 11EH Rom address.

    Yeah, that's what I thought.

    Since that trace is based on the information in the DISCiPLE PALs document, we're clearly missing something important. It's possible that the equations are correct but the English description of them in the same document is not, but I worry very much that if you were to produce a DISCiPLE interface based on those equations, then it would not be 128K compatible. Either way, whether it's a matter of fixing Fuse, clarifying the DISCiPLE PAL document, or fixing the equations, it would be worth finding out the answer.

    Would anybody with a DOS/Windows installation to hand able to trace through under 128K emulation in RealSpectrum, X128 or Z80, and say which one they're using and whether they get the same instruction trace as I got?

    (It seems plausible to me that the DISCiPLE with the 128K might do crazy things on startup, but then recover by luck... but I wouldn't have expected such an interface to be sold as 128K compatible by a reputable company such as MGT...)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    Finally after fighting with winxp and how to create a gif from a dxf, here are the schematics.
    Keep in mind. These are the same schematics but with the typos corrected. There are some mistakes though. The printer connector is 28 instead of 26 and the extra pins are in a "dip4" instead.
    Next step?
    I have a winxp/dos installation. What exactly do you want me to try? I've read something on the zxatasp which gave problems in 128K and explained that It was something to do with A15 and A13, let's see If I can look up the page.

    8473260462_f049714d39.jpg
  • edited February 2013
    My memory says that Disciple worked with the 128K toastrack.
    Anyway there should be no real problem with hardware compatibility. The only problematic field I can see is the recognition of the different ROM/RAM pages.
    Writing this down makes me remember the 'BRUCE' flag. Something poked in RAM, so that that particular page could be retrieved. Must be in the 'Rudy Biesma' disassembly. Paging is only relevant on 128....
  • edited February 2013
    roko wrote: »
    My memory says that Disciple worked with the 128K toastrack.

    Yes it did, I had that combination.
  • edited February 2013
    Ok. I managed to make the schematic and even a raw pcb design from the high quality pictures from a thread in (I think) here in WoS.
    The schematic must have mistakes on purpose, or It's a different design / issue.
    In the schematic you can see that there are 5 electolytic capacitors. But in the pcb there are only three, C3, C1 and I guess C9 or C8. These capacitors are not crucial in the design since they're there for the 5v power supply filtering network, only C4, on the clock signal circuit is electrolytic.
    Anyway, putting a electrolitc before the 7805 doesn't make much. A smaller capacitor makes the job as stated on many 78xx designs.

    On the pcb I also don't know where to put R17-R19, D11, D17-19. The pictures seems to indicate these components are located between the pals and the angled connector.
    This PCB is really apparently big, I don't have real size and only made an estimate from the size of a 14 pin chip. It is 32cm x 10 cm.

    128K compatibility should be checked with a toast-rack speccy. If 48K works I should know plugging it to a pcb I have around, an Issue 4-something.

    I read that UniDos was developed for disciple, but I haven't found the dump rom anywhere.

    As you can see I'm only adressing this project from an "analog" way. I trust the pictures of the pcb more than the schematic, the bottom layer can be duplicated easily and the upper layer can be done if more pictures of a real disciple were available, a proper schematic of this interface can be done then with fewer mistakes. The images I have are from a ISS 102-2, this is the closest to a serial number I can imagine.

    Regards.
  • edited February 2013
    Your example must be of a different design, the manuals 1986 and 1987 both show a 26 p. printer connector (page 65). Adverts (pics) show the same.
    Electrolitic capacitors are not always the bulky ones, for the smaller values often the tantalium version is used. With dimensions in the 3 - 6 mm range ...
    The (german) diagram in the WOS archive has been shrunk which gave some letters a different shape, M becoming N etc.. Otherwise it is rather consistent.
  • edited February 2013
    I have now all the information except the unidos dump for disciple.

    I've decided to make a disciple "lite". The goal is to make the cirtuit fit in an stantard 16cm x 10cm PCB. The net jacks have been removed and the 7805 too, along with some capacitor asociated with this.
    I plan to get maybe 2 FDD units, so I will need a ATX PSU, the same psu will give power to the disciple and the FDD.

    The IC's are the same, the pal/gals, etc. I've read somewhere that the pals really run hot and there were some failures on that, usually replacing them.

    MGT did what I'm trying to do, the +D, but without joystick support. Another approach could be get the +D schematics and add the circuits for the joysticks.
    I have no knowlege of how, I know how to add a kemston, but the another one uses some signals that come from the pals, so some design must be done about it.

    I did removed the "through" connector. The pal and gals could be installed with a small heatsink in them and then put the disciple in a sinclair-like box and run 2 small 5v fan to proper refrigeration.

    I'm also interested on some micropics for the whole rom/ram, the limit is of course the working frecuency.

    I have the design in PCB with the "vintage" chips and ready to be made.

    I don't know how you make the pcb's, I use double sided light-sensible and
    always had good results. That is however with audio projects, the width of the tracks here are way too small for that.

    I've seen people using toner-transfer on simple PCB's, alignment is an issue easily resolved by drilling some guides and then align them on the drills.

    It's easier for me to make a PCB than making a protoboard, the tracks are there and debugging can be an issue, but at least the size is a standard one.

    Layout: (added c21-26) This is a preliminary version:

    [8485131128_0e1b3cb72e.jpg


    Regards.
  • zubzub
    edited February 2013
    Severino wrote: »
    I have a winxp/dos installation. What exactly do you want me to try? I've read something on the zxatasp which gave problems in 128K and explained that It was something to do with A15 and A13, let's see If I can look up the page.

    The first thing is to find out which (if any) of those emulators provide a debugger or some means of tracing execution. RealSpectrum's debugger is likely to be the best bet.

    If I remember, X128 provides Multiface emulation of some sort, but I'm not sure whether it would be capable of stepping through DISCiPLE emulation. Gerton Lunter's 'Z80' emulator allows a 'map' file to be saved, which is essentially a list of addresses that have been executed... but it's not a proper trace, as it contains no information about the order in which the instruction were executed. If you could save a map file for a very small window of execution, this might be better than nothing.

    Once you've got a trace of instructions, post it somewhere, and we can examine it.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    roko wrote: »
    My memory says that Disciple worked with the 128K toastrack.
    Anyway there should be no real problem with hardware compatibility. The only problematic field I can see is the recognition of the different ROM/RAM pages.
    Writing this down makes me remember the 'BRUCE' flag. Something poked in RAM, so that that particular page could be retrieved. Must be in the 'Rudy Biesma' disassembly. Paging is only relevant on 128....

    The "BRUCE" string is stored in GDOS, and used as a means of determining which RAM bank is paged in. The problems affecting Fuse's emulation of the DISCiPLE (which seems to be consistent with the equations and schematics that we have) occur on startup of the ROM, way before GDOS is loaded.

    It seems there was nothing to stop programmers from placing the text "BRUCE" at the beginning of the first bank of RAM, and then never selecting that bank, as a means of preventing DISCiPLE / +D snapshots from working...
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    The first thing is to find out which (if any) of those emulators provide a debugger or some means of tracing execution. RealSpectrum's debugger is likely to be the best bet.

    If I remember, X128 provides Multiface emulation of some sort, but I'm not sure whether it would be capable of stepping through DISCiPLE emulation. Gerton Lunter's 'Z80' emulator allows a 'map' file to be saved, which is essentially a list of addresses that have been executed... but it's not a proper trace, as it contains no information about the order in which the instruction were executed. If you could save a map file for a very small window of execution, this might be better than nothing.

    Once you've got a trace of instructions, post it somewhere, and we can examine it.

    Ok. Installed x128, but It has no debugging mode. However It runs a 128k (toast rack) and with the gdos-3b.rom and the usual system disk It works fine. When using the unidos.rom and trying to load any system disk, It says error on disk, I can't remember the error exactly, something like sector missing or something like that. I will try other emulators though.
  • edited February 2013
    Severino wrote: »
    [8485131128_0e1b3cb72e.jpg

    I reduced the inputs on the PCB to 34 from the expansion port, there are several (3) grounds on the speccy, i will check with an ohmeter and see if they're the same. Correct me if I'm wrong, the signals the disciple uses are:
    - A0-A15
    - /RD
    - /WR
    - /RESET
    - /MREQ
    - /ROMCS
    - /IORQ
    - NET
    - /M1
    - /WAIT
    - D0-D7
    - /NMI

    34 connections fit in a FDD cable and will require a expansion port-IDC34 pcb adpator, but this way the pcb is smaller and only the used signals are there.

    Reading about the inhibit and the nmi button and judging from the pictures I guess they're "latching" buttons, I mean one push ->on, another push ->off.

    Tried the x128 emulator, no debugging mode, I'll keep going.
Sign In or Register to comment.