Another cause for DivIDE problems on 48K's

edited February 2015 in Hardware
The last months some topics were opened to discuss problems with 48K ZX Spectrums and DivIDE.

Sofar we found:
- Bad Z80's because of poor fanout (signal strength)
- Bad Z80's because of defective M1 line
- Bad PCB's or soldering contacts
- Potential bad ULA's

But today I found another cause: the ROM.

I have an almost fully socketed board to test parts that I sell.
I thought: let's check if after all this testing, a DivIDE will still work.
But it didn't (boots up fine, but NMI does nothing or reset the machine).

After swapping the ROM two times, I got a working one, and the DivIDE worked again.

So, what's this?
Are there incompatible ROM versions maybe?
Or is the ROM defective, not responding to the chip select correctly??

I'll read out the ROM and check differences lateron.
Post edited by bverstee on
«134

Comments

  • edited July 2012
    Wow Ben,

    thats a new one....

    Have you inspected the socket? possible corrosion / bad contact / dry solder fault?

    Although it wouldn't surprise me of some of these old ROM have reached the end of their useful - programmed - life.
  • edited July 2012
    My DivIDE wouldn't work with my original 48K speccy board. It only works with one I bought and overhauled with a few new transistors and capacitors. I never really looked into why it failed, though I'm cautious about upgrading the firmware of the DivIDE in case it stops working altogether. The original Speccy board doesn't seem to want to work now, anyway...
    Joefish
    - IONIAN-GAMES.com -
  • edited July 2012
    Just tried to read the ROM contents with my universal programmer, but I can't read out any of the original Spectrum ROM's (tried about 8 different ones).

    So I wrote this small BASIC program to create a checksum:
    10 LET B=0
    20 FOR A=0 TO 16383
    30 LET B=B+PEEK A
    40 PRINT AT 0,0; A'B
    50 NEXT A
    

    I tried this with FUSE as comparison, with a bad ROM (non completely functioning DivIDE) and with a good ROM on original ZX Spectrum.
    All give 1.926.175 as result.

    So it's not the contents.
    It must be something else, something with chipselect.

    But my diagrom (from Paul Farrow) in Interface 2 works great and pages as should.
    But of course that doesn't have an NMI function.
    Ow, of course: only the NMI function does not seem to work with this ROM problem!

    So it must be something with the NMI process and disabling the internal ROM (setting /CSROM high if I'm correct).
    Maybe it's possible to figure this out and try to modify a DivIDE to solve this.
    I'll try if I have time.
  • edited July 2012
    bverstee wrote: »
    Just tried to read the ROM contents with my universal programmer, but I can't read out any of the original Spectrum ROM's (tried about 8 different ones).
    The original ROM expects a LOW on pin 27, while an EPROM expects a HIGH there.
    Reading the orig ROM out as 32K or 64K EPROM should show the contents in one of the 16K blocks.
  • edited July 2012
    My DivIDE built by Velesoft works with both my Issue 4S 48k machine and my issue 2 48k machine (before failed upgrade that rendered it inoperable).
  • edited July 2012
    I just thought: maybe I can determine that it's a specific brand and model that causes the problems.
    But I'm not sure yet. Later.
  • edited November 2012
    As there are still problems with the original DivIDE (57c) in combination with 48K models, we should investigate this problem a bit more.

    So far we've found these reasons for DivIDE interfaces to fail on 48K models:
    - Poor Z80's fanout (signal strength) or a defective M1 line
    - Problems with the ZX ROM not paging out as described in this topic
    - Problems with soldering contacts or cupper wiring on the 48K board

    I think the ROM problem is a unique combination of DivIDE and ZX Spectrum.
    It seems that when a DivIDE fails due to this reason, a Multiface might still work.

    So the ROM problem must be caused by problems with the /CSROM signal on the DivIDE.
    First thoughts: it could be caused by the BC337 transistors or the GAL that controls the paging: signal strength or timing.

    The DivIDE must overrule the ULA control over the /CSROM.
    The ULA controls the /CSROM within the ZX Spectrum and passes a 680 ohm resistor so it can be overruled.

    The /CSROM change could be to slow, thus the internal ROM is not paged out quickly enough (on some ROMs, not all as proved above).

    I?m not sure if it?s possible to speed up the /CSROM change easily, by adding a resistor for example.

    Any thoughts?
  • edited November 2012
    Usually the /OE-to-Output time is much shorter than the /CE-to-Output time.
    So one might think about grounding /CE and doing the complete Eprom selection by means of /OE, when it indeed is a matter of timing.
  • edited November 2012
    kpuchatek wrote: »

    I've taken a look, but I'm not sure if the problems we are talking about would be solved by that solution.
    But maybe it will: the MREQ signal does concern the ROM paging.
    roko wrote: »
    Usually the /OE-to-Output time is much shorter than the /CE-to-Output time.
    So one might think about grounding /CE and doing the complete Eprom selection by means of /OE, when it indeed is a matter of timing.

    I'm trying to understand what you mean.
    At this moment the DivIDE ROM /OE is controlled by /ROMOE and /CE is controlled by /MREQ.
    Is it possible and wise to change something about that?
  • edited November 2012
    bverstee wrote: »
    At this moment the DivIDE ROM /OE is controlled by /ROMOE and /CE is controlled by /MREQ.
    Is it possible and wise to change something about that?
    The ROM normally must be 'switched on' by /CE and at about the same time DATA must be made available by means of /OE.
    The 'waking up' by /CE takes (say) 200 nsec, and enabling the outputs (/OE) about (say) 100 nsec. This is a notable difference.
    So in case of an expected 'too slow' ROM one could leave the chip 'awake' (by grounding /CE) and do the complete selection (= output enabling) by means of a new signal created by ORring the signals /ROMOE and /MREQ.
    I must add that I never worked with slow ROMs, but when the suspection has risen then the above could be done as a test.
    The 'Ingo-mod' seems to guarantee success, btw.
  • edited November 2012
    roko wrote: »
    The ROM normally must be 'switched on' by /CE and at about the same time DATA must be made available by means of /OE.
    The 'waking up' by /CE takes (say) 200 nsec, and enabling the outputs (/OE) about (say) 100 nsec. This is a notable difference.
    So in case of an expected 'too slow' ROM one could leave the chip 'awake' (by grounding /CE) and do the complete selection (= output enabling) by means of a new signal created by ORring the signals /ROMOE and /MREQ.
    I must add that I never worked with slow ROMs, but when the suspection has risen then the above could be done as a test.
    The 'Ingo-mod' seems to guarantee success, btw.

    Ok, so two more options ;)
    I think I will check out Ingo's solution first, but I do not have a known non working 48K model with DivIDE at this moment; have a stack ready to test by the way: one of them will fail ;)

    I'm curious if the 'quicker rom enabling' will help as the problem might not be the DivIDE rom paging in too slow, but the ZX rom paging out too slow.
    I only used AT28C64B EEPROMS on the DivIDE; are they 'slow'??
  • edited November 2012
    I had one divide with NEC 250ns. It was not always booting correctly. After change to Atmel 100 ns or less, problem was gone. However M1 issue cannot be solved that way - some ZXes simply don't work. Changing Z80 helps.
  • edited November 2012
    bverstee wrote: »
    .... I'm curious if the 'quicker rom enabling' will help as the problem might not be the DivIDE rom paging in too slow, but the ZX rom paging out too slow.
    I only used AT28C64B EEPROMS on the DivIDE; are they 'slow'??
    The datasheet says ATMEL and 150 and 75 nsecs, so you cannot call that slow, I think.
    Because in logic gear many logic functions are heavily interconnected, it is often difficult to find a direct route between the problem you believe to see and the remedy. Most of the time many kinds of tests must be made and interpreted...
    This reminds me of a little joke we had in the long gone days when I earned a living by repairing TV's. These were the early days of TV, so when people reported 'we have sound but no vision' we asked them if they already had tried turning the glass part in front.
  • edited November 2012
    Tried Ingo's mod this morning, but the boards which had problems with DivIDE still did not work after the mod.
    Replacing the Z80 solved the problem.
    Of course Ingo's mod can't help when the Z80 fails.

    I will use this sequence when I have DivIDE problems, using a modified DivIDE to rule out /MREQ problems:
    - Check edge contacts
    - Check ULA
    - Check power levels (some 7805's fail, causing problems with DivIDE)
    - Replace Z80

    After the board works again with a modified DivIDE, I will also test it with an unmodified DivIDE, to know if a new user of the board/machine will need a modified DivIDE.

    I can't think of any other problems causing DivIDE incompatibility, other than a bad ZX board or power problems.
    Anyone else has more ideas?
  • edited November 2012
    I've seen a picture of a Divide with a 10K pull-up resisistor on the reset line.
    Something to do with boosting the reset signal/level I believe.
    But I can't remeber where the information about this can be found.

    However, if you're testing anyway....
  • edited November 2012
    Knik wrote: »
    I've seen a picture of a Divide with a 10K pull-up resisistor on the reset line.
    Something to do with boosting the reset signal/level I believe.
    But I can't remeber where the information about this can be found.

    However, if you're testing anyway....

    Don't think that will cause imcompatibility.
    Maybe an unstable situation, but the DivIDE will run.

    I revised my DivIDE compatibility checklist:
    Using a DivIDE with Ingo's mod (to potentially rule out MREQ and ROM paging problems):
    1. Check power levels and circuit
    2. Check ULA (by swapping it)
    3. Check edge connector contacts
    4. Replace Z80
    5. If the DivIDE works again, test the ZX Spectrum with an unmodified DivIDE: if that fails, replace ROM of ZX Spectrum

    The last step is because of my experience I described in this topic.
    As you understand it's a fairly complex sequence, but I think this is the best way.

    Still I have other boards that keep having problems with DivIDE, but most of the time have problems otherwise too.
    It's just that those problems become more visible when you try some software, which is loaded easily from DivIDE.

    And power problems also will be more visible with a DivIDE attached, as it consumes a lot of energy (TTL parts).
    Bare in mind that a PlusD interface has it's own 7805, and consumes about the same amount of energy as a DivIDE.
  • edited November 2012
    bverstee wrote: »
    And power problems also will be more visible with a DivIDE attached, as it consumes a lot of energy (TTL parts).
    Bare in mind that a PlusD interface has it's own 7805, and consumes about the same amount of energy as a DivIDE.
    Not all PlusD disk drive interfaces use a 7805 voltage regulator, I have a non-original that uses the +5V line from the Spectrum.

    Mark
  • edited November 2012
    I took a 48K this week and it does not work with my divIDE 0.57c (divIDE works on my +2).
    But the divIDE 2K11 works fine on my 48K.
  • edited December 2012
    I tested another batch of roms, from disassembled ZX Spectrums.

    Again, some worked with DivIDE, and others didn't.
    So I'm sure the rom is one of the incompatibility causes between the ZX Spectrum 16/48K and DivIDE 57c.

    This time I got a bit more concrete: all NEC roms failes, the Sinclair ones worked:

    IMG_6064.JPG

    IMG_6067.JPG

    Next step is trying to influence the enable and chip select lines; maybe I can find an easy solution.

    If this is going to sort out, people who have a NEC rom and problems with DivIDE, can try the modification themselves.
  • edited December 2012
    Come to think of it I have only sinclair roms on my boards. Though I have not the 57C version of DivIDE either. How does it work with flashing a Xicor 28C256 eeprom and use it as ROM?
  • edited December 2012
    I tested some possible solutions today, but can't figure out what is causing the rom paging problems with the NEC roms.

    First I thought: maybe the ZX rom is not paging out quickly enough, so let's try a pullup resistor to /CSROM.
    That didn't work.

    Then I thought of the maybe the ZX rom is not paged out long enough or so, so let's try a capacitor to keep it paging out a little longer.
    Tried several values, none worked: the DivIDE rom just keeps paging in at the boot process (no ZX boot).

    It gets more complex when you think of that the DivIDE boots fine, and pages back in the ZX rom as it should, but can't get back to the DivIDE rom when the NMI button is pressed.

    I'm no expert in this I must admit.

    If the Sinclair version of the rom works with DivIDE, and the NEC do not, what can be the problem?
    Anyone can help?
  • edited December 2012
    This is where a digital storage 'scope comes in handy.

    The different ROMs are connected slightly differently. Sinclair would have only done this if there was a reason. Typically on some chips some /CE or /CS inputs put the chip in a low power state when deactived. Maybe you should temporarily add some external "glue" logic to only control the ROM via the /OE input and tie the /CE or /CS inputs to 0V.

    Just an idea (he said as he wrote this on a smartphone without access to a schematic diagram...)

    Mark
  • edited December 2012
    Almost there...

    rom_selection.jpg
  • edited December 2012
    I solved this problem recently when I put an eeprom as replacement for the rom. Simply added an Or gate that feeds the two signals MREQ and ROMCS to pin 20.

    But then you need more complex solution for original rom, to feed the right signal to pin 27 as well.
  • edited December 2012
    I'm having similar issues with my ULA replacement. As you know, the ULA is responsible for generating the ROMCS signal.

    With a standard ULA, my DivIDE works fine.
    With my replacement, strange things start to happen, all seem to be related with paging.
    With the Spectranet, no issues have been found.

    I asked Winston and he replied me that the main difference between the way ROMCS is pulled high on DivIDE and Spectranet is that DivIDE uses a BJT transistor in follower-emitter mode. Spectranet uses a MOSFET.

    So I've ordered some 2N7000 MOSFETS to replace both BC337 transistors in one of my DivIDE's. They are pin to pin compatible (for this application). The idea is to replace this section of the DivIDE...
    romcs_holder_divide.png

    To look like this (taken from the Spectranet schematic)
    romcs_holder_spectranet.png

    And see if it works ;)
  • edited December 2012
    Johan1973 wrote: »
    I solved this problem recently when I put an eeprom as replacement for the rom. Simply added an Or gate that feeds the two signals MREQ and ROMCS to pin 20.

    But then you need more complex solution for original rom, to feed the right signal to pin 27 as well.

    I had success too, but I solved it differently:
    I combined /CSROM and /RD to feed /OE (pin 22) of the NEC rom, using two NOR gates: first one to combine /CSROM and /RD and the second one to invert the output of the first.
    I left /MREQ on pin on pin 20; I added it to the triple NOR but it did not work.

    Here's my solution:
    IMG_6145.JPG

    It is not a great solution: adding more logic to solve problems with logic...

    But we know now that the NEC rom is causing DivIDE incompatibility, and how to solve it.

    What our solutions have in common is that pin 27 of the rom (that is /CS on the NEC rom) is grounded.
    That is normally connected to /CSROM.
    I think it's possible to solve this more easy.
    Let me try...
  • edited December 2012
    YIHAA!! 2 diodes and a resistor, and the DivIDE conquers the NEC rom 8)

    IMG_6147.JPG

    /RD and /CSROM are combined using two small signal diodes (1N4148 for example), resistor (10K) from there to ground, and from the diodes junction to /OE of the rom; pin 22.

    Of course cut the original signal on pin 22 first and..
    Cut the connection of /CSROM to pin 27, and connect pin 27 to ground.

    ANOTHER TOUGH PROBLEM SOLVED!
    Thanks for your support guys!

    Hurray! I'm getting a beer ;)
  • edited December 2012
    This is a further example prooving that divIDE is an interface working at the limits of Z80 technology.

    Greets Ingo.
  • edited December 2012
    You may want to check this:
    540x405

    You can click in it to edit/simulate within your browser. You will see that the output for the BJT option seems to not pull ROMCS high enough, and sometimes, low pulses from ULA make its way through the 680 ohm resistor (R33 in your schematic) and are interpreted by the input buffer (inside the ROM chip) as '0'. This isn't happening with the MOSFET.

    Although the BJT makes a stronger pullup than the MOSFET (so you can see if you run a time simulation and choose to see voltages at the input of both buffer instead of voltage at the output), the BJT seems to react a bit later, and sometimes a tiny low pulse "escapes" from the pullup, making the input buffer to see a '0'.
Sign In or Register to comment.