Please test your ZX128+2 (grey model)

edited August 2011 in Hardware
Please reset your ZX128+2 (grey) and write in 128 basic (or in USR0 mode):
PRINT IN 32765

- if basic crash (black screen) then your ZX contain board ISSUE1 or ISSUE3. This models contain old chip HAL10H8 with incorrect firmware (after reading port 32765 your ZX crash)
hal-old.gif

- if basic show value on screen and return with OK message, then your ZX contain modern board type "Z70500 iss3". This version can contain same chip HAL10H8 with fixed firmware (reading from port 32765 are ignored, ZX no crash).
hal-new.gif
Post edited by velesoft on

Comments

  • edited August 2011
    Cool, even after all this time things like are interesting!
  • edited August 2011
    Thanks for info Velesoft, this I never knew of. What however is the effect on software compatability regarding this bug?
  • edited August 2011
    Hercules wrote: »
    Thanks for info Velesoft, this I never knew of. What however is the effect on software compatability regarding this bug?

    Some russian software (for example games with turbo 7MHz mode suppurt) use instructions IN x,(#7FFD) and IN x,(#1FFD). Walker game read port 7FFD then crash on ZX128 and +2 models. But on last +2(grey) version this software don't crash. Also some original games for ZX48 read from similar ports and crash but on this +2 models work correct :)
  • Bump.

    Did anyone really test this? I’m seeing comments suggesting this fixed HAL was only in Spanish machines although the trail has led back here, so I’m not sure if there’s any substance to that claim.

    It’d be nice to know whether the later HAL which fixes port 0x7ffd reads also changes the contention model to that of the +2A/+3, i.e. are pages 1, 3, 5 and 7 still contended, or pages 4–7, as was (mistakenly) documented in the 128K’s service manual?

    I guess the “rain” issue is still there as the /RFSH signal is needed to correct it?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • I am from that generation, when Pluto was still a planet, and the Earth is round.

    Bomb Munchies on WOS thread
    Bomb Munchies Ver1930 17th Nov 2017 (look for the blue download box ) If you get a time-out message and live in the UK then try after 9pm-3am.
    Send me a PM and I can email it to you too. Kent, UK
  • I get the same blank screen on my +2 (grey). When I hit reset, I see the Amstrad copyright message briefly, which I suppose is normal. Presumably the IN from port #7ffd causes the shadow screen to be displayed.

    Anyone else feel like testing this?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zub wrote: »
    I get the same blank screen on my +2 (grey). When I hit reset, I see the Amstrad copyright message briefly, which I suppose is normal. Presumably the IN from port #7ffd causes the shadow screen to be displayed.

    Anyone else feel like testing this?

    Yes that happens on mine too.

    I am from that generation, when Pluto was still a planet, and the Earth is round.

    Bomb Munchies on WOS thread
    Bomb Munchies Ver1930 17th Nov 2017 (look for the blue download box ) If you get a time-out message and live in the UK then try after 9pm-3am.
    Send me a PM and I can email it to you too. Kent, UK
  • zub wrote: »
    I get the same blank screen on my +2 (grey). When I hit reset, I see the Amstrad copyright message briefly, which I suppose is normal. Presumably the IN from port #7ffd causes the shadow screen to be displayed.

    Anyone else feel like testing this?

    Same thing happens on mine.
  • zub wrote: »
    I get the same blank screen on my +2 (grey). When I hit reset, I see the Amstrad copyright message briefly, which I suppose is normal. Presumably the IN from port #7ffd causes the shadow screen to be displayed.

    Anyone else feel like testing this?

    Same here too. My +2 is an UK-manufactured model distributed with a Dixons Exclusive Superdeal package.
  • Hmm, so i guess the later issue of HAL really must be quite rare. I’m not sure if we’ve only seen one of these, and if so, who has it, and also exactly what the new equations are!
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zub wrote: »
    Hmm, so i guess the later issue of HAL really must be quite rare. I’m not sure if we’ve only seen one of these, and if so, who has it, and also exactly what the new equations are!

    I have this PAL chip from my friend. :-)
  • velesoft wrote: »
    zub wrote: »
    Hmm, so i guess the later issue of HAL really must be quite rare. I’m not sure if we’ve only seen one of these, and if so, who has it, and also exactly what the new equations are!

    I have this PAL chip from my friend. :-)

    Awesome. This is really quite intriguing. Do you know which RAM paged are contended when using it?

    Would it be worth photographing, or maybe making a note of date codes etc.?

    I assume from which I have read elsewhere that it was found in a Spanish +2?

    Do we definitely know that it was programmed by Amstrad and not reprogrammed by others? I think a HAL is not reprogrammable, no?

    Any other differences with this HAL might be nice to document and perhaps emulate so it’s good to get things tied down.
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • Oh, you say it’s a PAL, so not a HAL. How certain are you that Amstrad made this?
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • I have a (buggy) PAL chip that came from my original grey +2. It's marked MMI PAL10H8CN, datecode 8605.

    B
    The Spectrum Resuscitation Thread - bringing dead Spectrums back to life
    zx-diagnostics - Fixing ZX Spectrums in the 21st Century (wiki)
    Sinclair FAQ Wiki
  • PAL chips can be programmed by the manufacturer or the computer manufacturer. The types in manufactured goods are normally write only devices so once programmed, that's it.

    If you have a large order, the chip manufacturer can make them ready configured. This type were known as HAL.

    The markings on the PAL chips will give no clue as to the date they were programmed. The date code (if present) will only give the chip manufacturers production date.

    But it may still be worthwhile collecting the data, as there may well be a clear difference in the date time line.

    More details here https://en.wikipedia.org/wiki/Programmable_Array_Logic

    Mark
  • zubzub
    edited October 2015
    1024MAK wrote: »
    PAL chips can be programmed by the manufacturer or the computer manufacturer. The types in manufactured goods are normally write only devices so once programmed, that's it.
    Right, I know, and therefore that’s not really helping me. Sorry.

    My concern is clearly that there’s nothing to say that the PAL was not programmed by someone with a decent knowledge of how the 128K/+2 worked who felt inclined to fix a few bugs whilst they were at it. I don’t see any evidence to suggest that this was programmed by Amstrad themselves or by a supplier of theirs.

    (FWIW, I worked at a consumer electronics company for a number of years and heard daily conversations regarding the programming of Flash chips by our suppliers.)
    Post edited by zub on
    FUSE: the Free Unix Spectrum Emulator, also for Windows, OS X and more!
    http://fuse-emulator.sourceforge.net/
  • zub wrote: »
    My concern is clearly that there’s nothing to say that the PAL was not programmed by someone with a decent knowledge of how the 128K/+2 worked who felt inclined to fix a few bugs whilst they were at it. I don’t see any evidence to suggest that this was programmed by Amstrad themselves or by a supplier of theirs.
    Yep, the software was available (there is some that runs under MSDOS...).

    Mark

  • edited May 2016
    Probably late to this party, but my +2 is an Z70500 ISS3 board, manufactured week 40 of 1986, and has a HAL10H8 with a datecode of 8631. It causes a crash when port 0x7FFD is read.

    The exact mechanism is that the HAL asserts BANK for both reads and writes. For a read, this causes all of the bits in IC6 to become set, which is what causes the crash (because ROM 1 becomes paged in) and the black screen (because the shadow screen gets selected). The lines are because bank 7 gets paged in at C000, and the 48K ROM's RAM test routine causes the pattern.

    The "Umbrella" GAL equations fix this by only asserting BANK if *IORQ and *WR are set, as opposed to just when *IORQ is.

    BANK = !WRL & RDL & !ZA01 & !IORQL & !ZA15

    edit: The +2 manual does explicitly state that port 7FFD must never be read :)
    Post edited by Peter Mulholland on
Sign In or Register to comment.