The Disciple clone... doable?

124

Comments

  • edited February 2013
    This is solid reasoning sofar zub, good job.
    I see your problems but no loose ends.

    @ Stefan: Indeed for 128 SNAPs all RAM banks must be approached and Disciple contains the code to do so.

    @ zub: only read the first line of your latest post sofar, yes the code disassembled by Rudy at #2000 must be at #0000 during 'boot'.
  • edited February 2013
    zub wrote: »
    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 think the best way of putting it is "while the instruction at #0001 is fetched". That also is what the PAL equations say.
    I made tests with similar hardware, and the instruction LD HL, xxxx in bank 1 and LD BC,yyyy in bank 2. The result was LD HL,yyyy as expected.
  • zubzub
    edited February 2013
    FWIW, a trace of the beginning of execution if we assume that any traps and any OUTs to the patch port are delayed by one cycle:
    ROM PC   Instruction
    0   0000 DI
    0/D 0001 LD   BC,#31D3
    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
    D   0052 RET
                          ; Here's where it starts going crazy, and we enter
                          ; this middle of the 128K 'send MIDI data' routine...
    0   11CB OUT  (C),A
    0   11CD JR   #11CF
    0   11CF LD   E,#02
    0   11D1 DEC  E
    0   11D2 JR   NZ,#11D1
    

    Note that the beginning any the instruction trace is not affected in any serious way (okay, so an out instruction gets skipped, but it gets repeated at #0301 anyway)... but things go crazy at #11CB.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Stefan wrote: »
    Does this post from a certain Benjamin shed any light on things? http://compgroups.net/comp.sys.sinclair/disciple-and-spectrum-+2b-problems/1224756

    Quite possibly! We just need to know whether this also occurs on the toastrack and grey +2? Can someone with a DISCiPLE and a grey +2 or toastrack test this, please? (Keeping in mind of course that the +2 and +2a/b have more differences than just the ROM...)

    I wonder if MGT just 'got lucky' and found that the DISCiPLE more-or-less worked with the 128K, so just made some changes to the ROM, expecting users to toggle the inhibit switch as described? Still, I find it odd that there's no reference to this in the DISCiPLE user manual, that I could see.

    For Fuse, I guess I'd fix this by only allowing traps of ROM0 at 0x0066. I'd suggest that any clone of the interface should probably do the same (although I'm not sure how this would fit in with Uni-DOS), although I appreciate that this would probably replacing the two PALs and redesigning the board somewhat.

    I suppose MGT wouldn't have bothered with making such changes for a new revision of the DISCiPLE since they'd decided to make the +D instead, by that point. I can well imagine that the +D would have been an awful lot cheaper to make, with the lack of network ports/circuitry, joystick ports/circuitry, the passthrough connector, and with only one PAL, for a start...

    Other possible improvements that I can think of:
    • What would it take to add support for 1440 KiB ('1.44 Meg') floppy disks?
    • Could the interface be made smaller whilst retaining all of the DISCiPLE's ports, including the network port?
    • Perhaps handling of the passthrough connector could be improved for better compatibility with other peripherals?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    Other possible improvements that I can think of:
    • What would it take to add support for 1440 KiB ('1.44 Meg') floppy disks?
    • Could the interface be made smaller whilst retaining all of the DISCiPLE's ports, including the network port?
    • Perhaps handling of the passthrough connector could be improved for better compatibility with other peripherals?

    Hi there, I'm working with the pictures of the pcb and making "backwards" engineering from there.

    I've taken the schematic apart on 5 blocks:
    0 - The expansion port and the "Through" connector
    1 - The control logic, ram, rom, pals, ic5 and half of ic2.
    This block is the core of the disciple, interface almost the 34 signals
    from the speccy and generates 10 control signals to the rest of the circuit
    It also has the inhibit button and the nmi button.
    2 - The joysticks block, ic1 and ic10.
    3 - The FDD and printer block, this is the same as the +D and I've found
    different schematics that I'm checking, ic4, ic3, ic11 and the other half
    of ic2 which generates the clk signal for the wd1772.
    4 - The net, no ic's, the sockets and a transistor.

    The 1.44Mb FDD is a good upgrade.
    The rom/ram/logic can be done with a fast enough microcontroller.
    Adding mass storage cappabilities (such as usb, sd, etc) is a good idea too.
    The through connector is the main obstacle to reduce the pcb size.
    The net jacks don't have much use.

    As I see it we could have 3 ways of doing the disciple:
    A) A copy (which has to be done in the fist place to verify the design)
    B) A "lite" version; no net, no through, even no printer, essentially a +D with joysticks connectors.
    C) A completely different HW implementation keeping the original sockets but replacing all the logic with microcontrollers, cpld's etc.

    I'm on stage (A) right now, I think the goal is (c), but one step at a time.

    About the pal's I installed "palasm", which I didn't use from the 90's! and will make another set of jed files using the equations on the document. I will translate then into gal, but "fatbob" is working on that issue, this could solve our doubts on the equations issue.

    Regards.
  • edited February 2013
    I know the +D certainly worked on the original ("toastrack") 128K as I used that combination for a long time myself.

    The suggestion for using 1.44Mb floppies would need quite a rewrite of GDOS - as the structure was all geared around the 800K size and a bit-table based on that.
    No one important.
  • edited February 2013
    zub wrote: »
    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.
    The type of RAM used in a DISCiPLE is static RAM (SRAM). After power is applied, the memory will just contain random data until new data is written to it.

    Mark
  • edited February 2013
    zub wrote: »
    Other possible improvements that I can think of:
    • What would it take to add support for 1440 KiB ('1.44 Meg') floppy disks?
    Do you mean, could we use high density (HD) 3.5" floppy disks and store >800kiB of data on them?
    If yes, then the disk controller chip WD1772 has to run at double the normal speed when accessing HD disks. So you now need a 16MHz clock (for the HD disks), a circuit back from the floppy disk to detect the type of disk in the drive (some older HD drives have support for this, but most newer drives do not), and a selectable frequency divider to get 8MHz (so you can still use double density DD disks). All this is do-able.
    The harder part is, this will increase the transfer speed needed between the WD1772, the Z80 and RAM...
    zub wrote: »
    • Could the interface be made smaller whilst retaining all of the DISCiPLE's ports, including the network port?
    • Perhaps handling of the passthrough connector could be improved for better compatibility with other peripherals?
    If you move all the DISCiPLE's circuits, chips, connectors to one side of the board, you could have a flat PCB design, then the through-connector should not be a problem.
    If you drop the less useful interfaces, and / or use CPLD's, I think it could be made smaller.

    Mark
  • zubzub
    edited February 2013
    daveykins wrote: »
    I know the +D certainly worked on the original ("toastrack") 128K as I used that combination for a long time myself.

    Would you care to comment as to whether you remember having to toggle the inhibit switch on power-up to get it to work, please? :-)
    The suggestion for using 1.44Mb floppies would need quite a rewrite of GDOS - as the structure was all geared around the 800K size and a bit-table based on that.

    I was really just thinking that it also might be of some limited use to be able to produce utilities to read disks from other systems. There are apparently controllers similar to the WD1772 but with support for high density disks, although I'm not sure if extra components would be required. It don't know whether the high-density?capable controllers might generally be cheaper than the WD1772, anyway, though?

    I'm not sure whether any of the floppy disk interface peripherals for the Spectrum other than the MB-02 support high density disks, though?

    If we were to extend the DOS to support high density disks, then it might be less of a rewrite to follow the BDOS/HDOS approach, and divide the 1600 KiB disk (20 sectors/track, 80 tracks, two sides, 512-byte sectors) into two 800 KiB 'records'... It might also be possible to free up space for the larger SAM and BAM by removing networking code and the associated buffer... although that seems like a shame to me, since I feel that the Sinclair network support is what makes the DISCiPLE special.

    I haven't looked into GDOS all that thoroughly besides its early initialisation code and the snapshot code, but one thing that does occur is that the IF1 managed to work without any RAM of its own. The DISCiPLE does need its own RAM to hold one half of the software, but perhaps some of the buffer space (at least the network buffer) could be moved into the Spectrum RAM. That would presumably create some compatibility issues, but perhaps the change could be made optional...

    Another option might be to keep the same sized BAM and SAM but use 1024-byte sector-pairs for high density disks. In all cases, quite a lot of work would be required and I'm sure it would be either hard or impossible to do without changing the ROM ? perhaps more work than anyone would be interested in doing, but maybe it wouldn't hurt to ensure that the hardware can support high density disks, so that someone else can write the software at a later date if they so choose.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    Severino wrote: »
    Adding mass storage capabilities (such as usb, sd, etc) is a good idea too.

    Only if it doesn't create compatibility issues.
    The through connector is the main obstacle to reduce the pcb size.

    A bit of a shame, as it's also quite handy to have.
    The net jacks don't have much use.

    If you remove it, that really does seem like a shame... I'm not sure how many clones you were thinking of making, or what you'd do with them (presumably you'd make more than just one?)... but I tend to feel that the network support is what makes the DISCiPLE interesting. I'd love to have a DISCiPLE clone and an IF1 on a network, and perhaps have a few games converted to use the network. :-)
    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 think the best way of putting it is "while the instruction at #0001 is fetched". That also is what the PAL equations say.
    I made tests with similar hardware, and the instruction LD HL, xxxx in bank 1 and LD BC,yyyy in bank 2. The result was LD HL,yyyy as expected.

    I had meant that the ROM is paged in after the Z80 puts the address on the address bus (obviously) but before the Z80 samples the data bus for execution at that address. It seems you're saying that's not the case?

    I think what you're saying is that in your hardware test, you had the LD HL, xxxx and LD BC, yyyy instructions start at the same address ? let's say, 0x0001, for example.... and you also trapped execution at 0x0001, and found that the data retrieved by the Z80 for address 0x0001 was the original byte from bank 1 (which is paged in to start off with), but subsequent bytes read by the Z80 for execution of that instruction are obtained from bank 2... so you ended up with 'LD HL, yyyy', as a mixture of the two instructions?

    If that's the case, how similar was your test, timing wise, to the DISCiPLE and other peripherals? I seem to remember that for the Beta disk interface, the disk routines are invoked by through the 'USR' function, using addresses which in the Spectrum ROM contains RST #38 instructions ? I imagine that if the paging of the Beta interface's ROM were delayed at all, in the way that you seem to be suggesting, the interface would not work...

    The same probably goes for performing of an NMI with ROM0 paged in on the DISCiPLE attached to a 128K machine. As I mentioned, Lunter's Z80 has code in the 'ld e,e' instruction handler for dealing with NMIs ? what I might not have mentioned is that this occurs before the code for handling the 'ld e,e', meaning that the 'push af' instruction does get executed. This seems fairly crucial ? saving of snapshots with ROM0 paged in would certainly not work with a delay in the paging.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zubzub
    edited February 2013
    1024MAK wrote: »
    The type of RAM used in a DISCiPLE is static RAM (SRAM). After power is applied, the memory will just contain random data until new data is written to it.

    I guess under emulation, we should fill the emulated SRAM with random data upon startup... and perhaps on a hard reset? Out of interest, do you know whether the randomness would be of a uniform distribution with equal probability for a 0 and for 1 in each bit?

    For the Spectrum's DRAM (I guess 48K and 128K), do you know what the behaviour should be? (I know the 48K clears all of its RAM on startup, but not so sure about the 128K...)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited February 2013
    zub wrote: »
    Another option might be to keep the same sized BAM and SAM but use 1024-byte sector-pairs for high density disks. In all cases, quite a lot of work would be required and I'm sure it would be either hard or impossible to do without changing the ROM ? perhaps more work than anyone would be interested in doing, but maybe it wouldn't hurt to ensure that the hardware can support high density disks, so that someone else can write the software at a later date if they so choose.

    1024 byte sectors instead of 512 byte sectors is just genius. I would expect the software adjustments to be minimal.
  • edited February 2013
    zub wrote: »
    Quite possibly! We just need to know whether this also occurs on the toastrack and grey +2? Can someone with a DISCiPLE and a grey +2 or toastrack test this, please? (Keeping in mind of course that the +2 and +2a/b have more differences than just the ROM...)

    I wonder if MGT just 'got lucky' and found that the DISCiPLE more-or-less worked with the 128K, so just made some changes to the ROM, expecting users to toggle the inhibit switch as described? Still, I find it odd that there's no reference to this in the DISCiPLE user manual, that I could see.

    Strange. I had a Disciple and a toastrack 128K machine back in the days, and I cannot remember toggling the inhibit switch to make the machine boot.
  • edited February 2013
    zub wrote: »
    I had meant that the ROM is paged in after the Z80 puts the address on the address bus (obviously) but before the Z80 samples the data bus for execution at that address. It seems you're saying that's not the case?
    Remember it is about electric signals that are on or off. The result of a combination of signals (the equations) also is a signal that is just on or off. (Most often 'off' is the 'valid'). The addition of M1 makes the thing fire while the instruction is fetched. The PAL/GAL electronics will introduce a few nanoseconds delay, this is (very roughly) about the time that Z80 needs to complete the fetch that was started. And appearently things are settled when Z80 'returns' for more business. For added safety (and unambiguous coding?) the same instruction is used in both ROMs as you noticed already.
    zub wrote: »
    I think what you're saying is that in your hardware test, you had the LD HL, xxxx and LD BC, yyyy instructions start at the same address ? let's say, 0x0001, for example.... and you also trapped execution at 0x0001, and found that the data retrieved by the Z80 for address 0x0001 was the original byte from bank 1 (which is paged in to start off with), but subsequent bytes read by the Z80 for execution of that instruction are obtained from bank 2... so you ended up with 'LD HL, yyyy', as a mixture of the two instructions?
    I think the same. Additional explanation above.
    zub wrote: »
    If that's the case, how similar was your test, timing wise, to the DISCiPLE and other peripherals? I seem to remember that for the Beta disk interface, the disk routines are invoked by through the 'USR' function, using addresses which in the Spectrum ROM contains RST #38 instructions ? I imagine that if the paging of the Beta interface's ROM were delayed at all, in the way that you seem to be suggesting, the interface would not work...
    There are other systems, of which Divide is an example, that enter the result of the 'equations' as Data in a (static) data-flipflop, and then Clock that flipflop with a signal derived from the next instruction fetch (I think). The Data level appears on the output pin at the moment of the clocking. This may look controllable for some, but I am not able to see any profit. Others may help us here...
    Delayed. I do not see how 'patching' during a fetch would cause any delay. Z80 does some internal machine cycles when ROM is replaced.
    You may theoreticly loose the contents of a register, which you would have lost anyway when OUT (C),A was used. Plus the same switching moment would occur...
    zub wrote: »
    The same probably goes for performing of an NMI with ROM0 paged in on the DISCiPLE attached to a 128K machine. As I mentioned, Lunter's Z80 has code in the 'ld e,e' instruction handler for dealing with NMIs ? what I might not have mentioned is that this occurs before the code for handling the 'ld e,e', meaning that the 'push af' instruction does get executed. This seems fairly crucial ? saving of snapshots with ROM0 paged in would certainly not work with a delay in the paging.
    The NMI thing is different. When NMI is pressed then Z80 first must finish some of its current business. So the appearence of a following M1 (or other trigger) is not synchronous with pressing the button. So the button cannot do the 'patching', but the occurrence of the NMI address must be monitored.
  • edited February 2013
    I mapped the bottom side.
    For reference and for anyone with a disciple pcb, please point the mistakes:
    (pdf format) -> Bottom side (It's not even a "beta")

    http://www.mediafire.com/view/?6z4c5u0co54xxal

    I asked fatbob for pictures above r17 and above the 7805 UNDER the angled connector.
    Some tracks are hard to route, this is the job until now:

    http://www.mediafire.com/view/?yuuddoaa1p6vc5t

    He is also trying the gal equations to work on the disciple.

    The schematics are ok.. to a certain point, I took the Format magazine and took a peek because the pullups resistors on the disciple schematics didn't add up to my understanding, also the +D controller, a atari ST, all of them use the Format magazine schematics with some differences, but not these:

    Here is a picture from Format magazine issue 303 (I think):

    8516790408_fd20495531.jpg

    These are the correct ones, using them I was able to route the pcb as the pictures indicated.
    Pins 19,23,24 and 25 are the ones with a pull-up resistor.

    My concern on mapping the top layer is with the "dark zones", to make the pcb as close as possible to the original and test the HW. (Stage A)

    I noticed some strange ground configurations that makes "ground loops". I always designed my electronics to either "bus ground" or a "star-ground"; my favourite is star ground.
    I don't know If I'm biased by audio electonics on which I've been working for a while.

    I'm worried too about the way to make a home-made pcb with such tracks widths (0.25mm), (0,2mm gap) I will try both UV exposure and "tone transfer" on a small pcb and see the results.

    I will keep working and waiting for fatbob to post those "dark areas", even below the pals which are, of course in sockets.


    Regards.

    Severino.

    PD: A solution for the 7805 to work cooler is the same approach that the speccy, a big plate of aluminum on the base of the 7805 wich could cover all the "ground" plane available at the top layer. below the 7805. (This is for a real disciple and people that has to keep changing the regulator)

    PPD: I didn't think on make a lot of disciples, but If you're interested It will be Ok for me, I even can build the boxes, not in plastic, In wood, (lacckered in black and even some inlays with "MGT" or "Disciple" on them, my brother owns a carpentry.
    Anyway let me know what do you think.
  • edited February 2013
    Just had a quick glance at the Format drawing, Severino. What struck me is that the artist has forgotten to show that TR00, WRPR, RD and IP are 'negative valid' signals. (Maybe even 'open collector'.) You want to pull these up for getting a clearly determined 'valid'.
    This part of the 'power bus' therefore will be just +5V. You already noticed, for sure. Sorry for Mr. Format, this sounds much less powerfull but I can't help.
    The 'odd' side of the disk drive connector of course should be connected to Ground. The odd numbered wires act as shielding between the 'even' lines that carry the signals, in the normally used flatcable.
    I tend to think that those who know how to connect a shielding to 'the power bus' don't need this diagram :-)

    Edit: Also noticed the extremely differing values given for C4: 1uF (Format) and 220uF (german diagram).
    Again: 1 uF should do the job I think.
  • edited February 2013
    roko wrote: »
    Just had a quick glance at the Format drawing, Severino. What struck me is that the artist has forgotten to show that TR00, WRPR, RD and IP are 'negative valid' signals. (Maybe even 'open collector'.) You want to pull these up for getting a clearly determined 'valid'.
    This part of the 'power bus' therefore will be just +5V. You already noticed, for sure. Sorry for Mr. Format, this sounds much less powerfull but I can't help.

    Those schematics were done using spectrums or similar, I only showed them in order to point the pullups resistor.
    roko wrote: »
    The 'odd' side of the disk drive connector of course should be connected to Ground. The odd numbered wires act as shielding between the 'even' lines that carry the signals, in the normally used flatcable.
    I tend to think that those who know how to connect a shielding to 'the power bus' don't need this diagram :-)

    I use shielding on pcb's where audio signal is involved, ground planes are very useful for that, If that's what you mean, the power bus (5V-GND) is DC.
    Do you mean shield the power bus from the rest of the noisy logic?
    roko wrote: »
    VEdit: Also noticed the extremely differing values given for C4: 1uF (Format) and 220uF (german diagram).

    Those aren't the only different values. The critical C4 is the issue, the rest are only decoupling caps and the 33pF in series with the crystal. A list from:
    Format magazine / WoS Schematics / PCB
    R1-5 -> 2k2 330R 2k2
    R6 -> 3k9 3k9 3k9
    R7 -> 560R 680R 560R
    R8-9 -> 330R 330R 330
    R10 -> 560R 680R 560R
    R11-12 -> 2k2 2k2 2k2
    R13-17 -> 330R 330R 330R
    R18 -> 560R 680R 560R
    R19 -> 470R 470R Cant be seen yet
    C1 -> 220uF 16V 220uF 16V
    C2 -> 10nF 100nF
    C3 -> 22uF 35V 22uF 35V
    C4 -> 1uF 35V 220uF 16V !!!!!!
    C5 -> 33pF
    C6-7 -> 100nF 100 nF
    C8 -> 22uF 35V 22uf 35v
    C9 -> 1uF 35V 1Uf 35v
    C10 -> 100 nF

    The issue is C4, which generates the clock for the Wd1772, I will look into that later.

    Regards.
  • edited March 2013
    Severino wrote: »
    I use shielding on pcb's where audio signal is involved, ground planes are very useful for that, If that's what you mean, the power bus (5V-GND) is DC.
    Do you mean shield the power bus from the rest of the noisy logic?
    On PCBs most of the time a tree-like structure is used for ground and for +5. The closer to the trunk the wider the traces. That is why you sometimes find parallel connections. The major concern is whether 'ground' can drain all the H.F. current fluctuations, spikes. The same goes for +5, btw.
    I think that the best approach is to have a pcb layout that in general looks like other layouts. That way you will only meet the normal problems, if any.

    My concern is that you have difficulties finding valid and trustworthy information. In the Format picture you can see that the Spectrum signals /RD, /RESET are in 'negative logic' notation. And also the chip's /CE. So there really was no external obstacle blocking the use of that notation for /Tr00 etc. too....

    Nice pcb layout Rafa!
  • edited March 2013
    Hi there.
    I finished mapping the top of the disciple pcb, as I said, the schematic follows the pcb, I routed using the schematic Netlist and the modifications on the resistors R14-16, as I said:
    R13 -> Pin 23 of IC4 (IDC 34 pin 26)
    R14 -> Pin 19 of IC4 (IDC34 pin 30)
    R15 -> Pin 25 of IC4 (IDC34 pin 28 )
    R16 -> Pin 24 of IC4 (IDC34 pin 8 )

    Using this wiring and swapping R12-R11, the pcb pictures, the routing and the netlist from the schematics fits 100%.
    About the gnd and 5V routing, I've found 1 ground loop around the 8Mhz crystal, I still haven't checked the rest, I'm on my way to printing them.

    You will notice on the top layer a strange rat-maze on the angled connector, there's no more vias on the pcb, If I were to make this pcb It would be routing that signal (A12 I think) another way.

    If anybody with time left (and a magnifying glass) could check the top layer against a disciple pcb It will be very useful. Ok.
    Top layer (not mirrored)

    http://www.mediafire.com/view/?0e0yeee4hk8rbb2

    Bottom layer (mirrored):
    http://www.mediafire.com/view/?ivr41m15dyiy9er

    On my way to print on paper these tracks and keep checking.

    Regards.
    Severino.

    EDIT:
    There's another bug on the schematics, the RAM, a toshiba 5565 and the same 6264 by mosel have an additional CS2 that has to be at "1" in order to work (pin 26).
    It was easy from the pcb pictures and the datasheet, that connection is under the chip on the top layer and could have been missed by the author of the schematic.
  • zubzub
    edited March 2013
    roko wrote: »
    The NMI thing is different. When NMI is pressed then Z80 first must finish some of its current business. So the appearance of a following M1 (or other trigger) is not synchronous with pressing the button. So the button cannot do the 'patching', but the occurrence of the NMI address must be monitored.

    Actually, what you mean is that the NMI is not different. ;-)

    Agreed, the DISCiPLE can't trap pressing of the button itself, since this would result in a race condition. So instead, the DISCiPLE traps execution (i.e. M1 active) at address 0x0066. Since this is not a 'push af' instruction but an 'ld e,e' in ROM0, this would cause the stack pointer to be wrongly set (and contents of the AF register to be corrupted too) upon return from the NMI. This would be unfortunate for a peripheral that claimed 128K compatibility.

    Note the '?_ROMBANK' routine in Rudy's disassembly, which works by looking for the value 175 (0xaf, xor a) at address 0x0001, which would indicate that ROM1 is paged in. There's only any point in this routine existing if it is in fact possible to take a snapshot whilst ROM0 is paged in.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    zub wrote: »
    Actually, what you mean is that the NMI is not different. ;-)
    I stand corrected :-)
  • zubzub
    edited March 2013
    roko wrote: »
    I stand corrected :-)

    Oh, no you don't! ;-)

    Seriously, though... I've suggested to the Fuse team that we allow the DISCiPLE under 128K emulation, with a simple change so that the interface doesn't page in at 0x0001 unless ROM1 is paged in. The DISCiPLE still ends up getting paged in upon execution at 0x028e in ROM1 before the 128K's main menu is displayed, but I'm not sure if that's a bad thing.

    I'd like to recommend something similar for Severino's clone of the interface, but there's one problem ? in an emulator, we can tell which ROM is paged in, but for the real thing, although we can track writes to the paging register, there's no good way to tell whether the machine is a 128K, or not... certainly not without changing the ROM, in which case, we might as well change the paging to be more like that of the +D.

    I'm aware of certain lines on the expansion bus that could be used for this, but it seems like a very kludgey approach, and is pretty much guaranteed not to work with certain Spectrum clones, perhaps even including some legal clones in which the DISCiPLE might work?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    zub wrote: »
    Oh, no you don't! ;-)
    You're right, I stand corrected twice. Now I will aways lag behind, won't I?

    Straight from the Disciple manual:
    Connect the power and the normal introductory screen will appear (...)
    If you are using a Spectrum 128 or Plus2, go into the Edit mode,
    and then move the cursor to select Screen. Then press Enter.
    This has the effect of removing the logo from the bottom of the
    screen, and the commands that you enter will appear at the
    bottom of the screen instead of at the top.
  • zubzub
    edited March 2013
    roko wrote: »
    You're right, I stand corrected twice. Now I will aways lag behind, won't I?

    Okay — you win! :-)
    Straight from the Disciple manual:
    Connect the power and the normal introductory screen will appear (...)
    If you are using a Spectrum 128 or Plus2, go into the Edit mode,
    and then move the cursor to select Screen. Then press Enter.
    This has the effect of removing the logo from the bottom of the
    screen, and the commands that you enter will appear at the
    bottom of the screen instead of at the top.

    Argh! The OCRed version of this on WoS says "If you are using a Spectrum 12BK or Plus 2". I might try to fix this for the text version, but the PDF, I can't do anything about! :-(

    I presume the advice they give for the 128K and +2 is so that the user may still see a catalogue whilst typing in a command containing a filename from that catalogue.

    ... but the implication is that no fiddling around with the inhibit switch is needed for the 128K or +2. I now really am completely baffled by this. I can do no more — we really need the help of somebody with a DISCiPLE, a 128K/+2 Spectrum and a logic analyser.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    zub wrote: »
    Okay ? you win! :-)
    I can do no more ? we really need the help of somebody with a DISCiPLE, a 128K/+2 Spectrum and a logic analyser.

    Hi there, I've been busy last week, I adquired a 128K "toast rack" and a disciple. As for the logic analyser I'm on my way to adquire or even build one, but for now I'm tying to understand the gdos.
    Long story short, the 128K needs a capacitor replacement and a new membrane, but I tested the disciple tape (gdos 3a) in the 128 and It just froze when asking the typical questions about the disk configuration.
    Until I get that 128k working I can only make "experiments" on my 48k+, I use an "interface wire" to keep the disciple a bit far from the speccy and It doesn't get too hot, but I'm having problems with the NMI, on basic works fine, but when on a game or program running It frozes or even reset.
    Now that I have the pcb, the romV3 and the pals I will be able to verify the schematic and of course read the rom, the pals, try the gal's instead, etc. I ordered a gal/eprom burner and I'm waiting for them to arrive, I have the gal chips now.
    I'm sorry If right now I can't be of much help. Ideally how many channels would you need in the logic analyzer? 24? 30+? The disciple gets 34 signals from the expansion bus, but a logic analyzer for 34 channels could be hard to get.
    Anyway, when the eeprom and gal programmer gets here I will make a rom dump directly from the chip and try the pal equations on gal chips 20v8.
    I will inspect the pcb closely and make an accurate schematic, what I've seen so far is ok with the modifications on R14-R16 that I said.

    Kind regards.
    Severino.
  • zubzub
    edited March 2013
    Severino wrote: »
    Hi there, I've been busy last week, I acquired a 128K "toast rack" and a disciple. As for the logic analyser I'm on my way to acquire or even build one, but for now I'm tying to understand the gdos.

    Great news!

    I'd be interested in finding out a bit more about GDOS, G+DOS, UniDOS, BetaDOS, SamDOS and MasterDOS, too. Rudy's disassemblies have been very helpful so far, but I might try to disassemble the others...
    Long story short, the 128K needs a capacitor replacement and a new membrane, but I tested the disciple tape (gdos 3a) in the 128 and It just froze when asking the typical questions about the disk configuration.

    Shame... Sounds as though you're well on the way to getting it fixed, though. :-)
    Until I get that 128k working I can only make "experiments" on my 48k+, I use an "interface wire" to keep the disciple a bit far from the speccy and It doesn't get too hot, but I'm having problems with the NMI, on basic works fine, but when on a game or program running It frozes or even reset.

    The NMI routine in GDOS is buggy, so that's not entirely unexpected. It should be very easy for me to put together a fix, though.
    Now that I have the pcb, the romV3 and the pals I will be able to verify the schematic and of course read the rom, the pals, try the gal's instead, etc. I ordered a gal/eprom burner and I'm waiting for them to arrive, I have the gal chips now.

    Sounds great!
    I'm sorry If right now I can't be of much help. Ideally how many channels would you need in the logic analyzer? 24? 30+? The disciple gets 34 signals from the expansion bus, but a logic analyzer for 34 channels could be hard to get.

    The essential lines are M1 and A0-A15, to get a trace of the program counter. ROMCS would also be useful to determine when the ROM gets paged in. If you have the capacity, D0-D7, MREQ, IORQ, RD and WR could be useful, but not essential.

    It would probably also be possible (but harder) to piece things together from just M1, ROMCS and D0-D7.

    Depending on the result, we might need additional lines to make sense of what we're seeing... and I have no idea what that would involve!
    Anyway, when the eeprom and gal programmer gets here I will make a rom dump directly from the chip and try the pal equations on gal chips 20v8.
    I will inspect the pcb closely and make an accurate schematic, what I've seen so far is ok with the modifications on R14-R16 that I said.

    It's likely that the ROM will be the same as we've already seen, but it's worth checking anyway! Glad that the schematic is coming together... Not far to go, now! :-)
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • edited March 2013
    zub wrote: »
    Great news!
    Shame... Sounds as though you're well on the way to getting it fixed, though. :-)

    I finally was able to use the disciple, the nmi button, open snapshots, etc. The disciple didn't like to be away with this long connector, I will test all the solderings and contacts, but the disciple works great now. I couldn't tell It was the cable until I downloaded gdos 3d system tape and It gave some errors like "Out of Memoy", unplugged the interface-cable, plugged the disciple directly under the speccy, loaded gdos, formatted a disk and saved the system, later I loaded a tape and used the nmi button, works just fine now (on 48k+). We have a good disciple to test with, at least the disk drive.

    There wasn't much information about how to connect the newer PC drives to the disciple, but on WoS I found that the only modification that has to be made is a twist on the flat cable involving pins 12 and 10 to change the drive from ds1 to ds0. I still haven't used two drives but I will.
    Another funny thing is that back in the 90's I used DD disks in HD opening a hole with a drill..I know, but It worked back then. The opposite doesn't seem to work, even when I severed the HD connection wire on the disk drive, the drive thinks all disks are DD but formating them the disciple gave sector errors.

    About the capacitors on the disciple It seems that this one has only one electrolytic, the one below the floppy connector and is axial, the other ones are "tantalum" capacitors, no polarity. Once I know that this unit is working fully (I have to find a suitable printer and a IF1) I will make a accurate schematic and make the first pcb.

    I've found a 34 channels logic analyzer, It's the exact amount we need to monitor all signals 16 addresses, 8 bit data bus and still 10 signals to plug in.
    This analyzer will work for the clone and for the Superfo 128 testing. I'm still reading some books to understand better the z80 and the I/O.. I used to work on machine code but with the 68000 family, I still have a lot of work to do.

    Regards.
  • edited March 2013
    Severino wrote: »
    ...the other ones are "tantalum" capacitors, no polarity.
    Tantalum capacitors are polarised. Normally they have a small + sign marked on them.

    Mark
Sign In or Register to comment.